Chapter 2: Software Process Models
Overview
Definition
- Overview: A short list of topics covered in the lecture notes: definition of process and its characteristics; examples of software process models; characteristics of software process models; Agile and its characteristics.
Causes
- Not specified in notes
Goals / Objectives
- Present the main topics students must learn about software process models.
Importance
- Establishes scope and roadmap for chapter study.
Procedures
- Not specified in notes
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Orients reader to what will be learned; frames expectations for the chapter.
Examples
- Not specified in notes
Key Takeaways
- The chapter covers definitions, characteristics, model examples, and Agile features.
- Use the overview to locate deeper subtopics in the chapter.
What is a Process?
Definition
- Process: A series of steps taken to produce an intended output.
Causes
- Not specified in notes
Goals / Objectives
- Explain what constitutes a process and its components.
Importance
- Helps understand how work is organized to produce predictable outcomes.
Procedures
- Steps involved in a process include:
- Activities
- Constraints
- Resources
- Process also involves:
- Tools
- Techniques
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Clarifies what must be considered when designing or following a process (activities, resources, constraints, tools, techniques).
Examples
- Not specified in notes (the notes list categories rather than concrete real-world examples).
Key Takeaways
- A process is a step-by-step path to an output.
- Processes require activities, resources and are supported by tools and techniques.
Characteristics of Process
Definition
- Characteristics of a process: key properties that a process should have as listed in the notes.
Causes
- Not specified in notes
Goals / Objectives
- Define what to expect from a well-formed process.
Importance
- Ensures processes are usable, testable, and maintainable.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Processes that meet these characteristics enable clearer planning, execution and handover.
Examples
- Not specified in notes
Key points from notes (all items preserved)
- Prescribes all major process activities.
- Uses resources subject to constraints (e.g., schedule, number of people).
- Produces intermediate and final products.
- May be composed of sub-processes with hierarchy or links.
- Each process activity has entry and exit criteria.
- Activities are organized in sequence so timing is clear.
- Each process has guiding principles, including goals of each activity.
- Constraints may apply to an activity, resource, or product.
Key Takeaways
- Processes should be structured, measurable and constrained.
- Entry/exit criteria and sequencing make timing and control possible.
Why Processes Are So Important
Definition
- Explanation of the value of having processes.
Causes
- Not specified in notes
Goals / Objectives
- Show benefits of using processes across activities.
Importance
- Processes impose consistency and structure, and help capture and pass on experience.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Advantages (as listed in notes):
- Impose consistency and structure on activities.
- Guide understanding, control, examination, and improvement of activities.
- Enable capture and transfer of experience to others.
Impact / Effect
- More consistent outputs, improved ability to control and improve work, and easier knowledge transfer across teams.
Examples
- Not specified in notes
Key Takeaways
- Processes make work predictable and improvable.
- They help organizations keep and share experience.
Advantages of Using Software Process Model
Definition
- Not specified in notes (this section lists advantages)
Causes
- Not specified in notes
Goals / Objectives
- Outline benefits organizations gain when they adopt SPMs.
Importance
- Shows why teams adopt software process models.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Advantages (from notes):
- Increased development speed
- Increased product quality
- Improved tracking & control
- Improved client relations
- Decreased project risk
- Decreased project management overhead
Impact / Effect
- Faster, higher-quality delivery with lower visible project risk and overhead.
Examples
- Not specified in notes
Key Takeaways
- Using SPMs improves speed, quality and control.
- SPMs reduce risk and management costs.
Perspectives (How different stakeholders see the lifecycle)
Definition
- Different viewpoints on the development life cycle as perceived by stakeholders (customer, project leader, analyst, developers, QA, documenters, consultants, billing/support).
Causes
- Differences arise because each role has different responsibilities and focus.
Goals / Objectives
- Illustrate why misunderstandings occur and why a process helps align perspectives.
Importance
- Demonstrates that stakeholders may describe and experience the same project very differently.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Misalignment between perspectives can lead to gaps between “what the customer really needed” and delivered product.
Examples (as listed in notes)
- How the customer explained it
- How the Project Leader understood it
- How the Analyst designed it
- How each developer integrated with others
- How QA got the 1st, 2nd, and 3rd build
- How the project was documented
- How the Business Consultant described it
- How the customer was billed
- How it was supported
- What the customer really needed
Key Takeaways
- Different stakeholders produce different views of the same lifecycle.
- A clear process helps align these views toward the real customer need.
How to Select the Right Software Process Model
Definition
- Guidance on selecting an appropriate SDLC/SPM for a project.
Causes
- Selection is needed because projects vary by requirements, team, technology and constraints.
Goals / Objectives
- Provide steps to choose the right SPM: learn about SDLC models, assess stakeholder needs, define selection criteria.
Importance
- Choosing a suitable model reduces risk and increases chance of project success.
Procedures
- Selection steps from notes:
- Learn about SDLC models and be familiar with candidate SPMs.
- Assess needs of stakeholders: study business domain, stakeholder concerns and priorities, technical capability, and technology constraints.
- Define selection criteria, including suitability for team size/skills, selected technology, stakeholder concerns, geographic distribution, software size/complexity, project type, engineering capability, and project risk/quality needs.
Advantages & Disadvantages
- Not specified in notes (this section is procedural)
Impact / Effect
- A structured selection process increases the chance of choosing an SPM that matches project realities.
Examples
- Not specified in notes
Key Takeaways
- Know models, assess stakeholders, and define criteria to select the right SPM.
- Use criteria such as team size, technology, distribution, and risk profile.
List of Several SPM Models
Definition
- A catalog of common software process models listed in the notes.
Causes
- Not specified in notes
Goals / Objectives
- Provide students with names and variations of SPMs they should study.
Importance
- Awareness of available models helps match approach to project needs.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Knowing options helps tailor processes to projects.
Examples (complete list preserved)
- Waterfall Model
- Iterative Model
- Spiral Model
- Agile Model
- V-Model
- Rapid Application Development (RAD)
- Scrum
- Extreme Programming (XP)
- Adaptive Software Development (ASD)
- Feature Driven Development (FDD)
- Crystal Clear
- Dynamic Software Development Method (DSDM)
- Rational Unified Process (RUP)
Key Takeaways
- Many SPMs exist; each fits different project contexts.
- Study the list to choose a model appropriate for your project.
SDLC Revisited (Basic SDLC activities)
Definition
- Software life cycle (SDLC): the process of building software organized into key phases.
Causes
- Not specified in notes
Goals / Objectives
- List classic SDLC phases used across models.
Importance
- Forms the backbone of many SPMs and clarifies recurring activities.
Procedures
- SDLC steps (as listed):
- Requirements analysis and definition
- System (architecture) design
- Program (detailed/procedural) design
- Writing programs (coding/implementation)
- Testing: unit, integration, system
- System delivery (deployment)
- Maintenance
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Provides consistent structure for producing, testing and maintaining software.
Examples
- Not specified in notes
Key Takeaways
- SDLC breaks development into distinct phases from requirements to maintenance.
- These phases appear in many process models, sometimes iteratively.
Basic Software Process Activities
Definition
- Four basic key process activities that produce a software product.
Causes
- Not specified in notes
Goals / Objectives
- Identify essential activities for software creation and evolution.
Importance
- Highlights the core work areas every software project must cover.
Procedures
- The four activities and descriptions:
- Software Specifications — detailed description of system with functional and non-functional requirements.
- Software Development — designing, programming, documenting, testing, and bug fixing.
- Software Validation — evaluating the software to ensure it meets business and end-user needs.
- Software Evolution — updating the software over time for various reasons.
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- These activities produce the software product and enable its lifecycle from creation through maintenance.
Examples
- Not specified in notes
Key Takeaways
- Specifications, development, validation, and evolution are the core activities in software engineering.
- Each activity focuses on a distinct part of the product lifecycle.
SDLC Models (Overview list)
Definition
- A compact list of SDLC model names present in the notes.
Causes
- Not specified in notes
Goals / Objectives
- Show model variants students should know.
Importance
- Helps students map SDLC principles to concrete models.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes (individual models are treated later)
Impact / Effect
- Identifies model choices available for projects.
Examples (preserved)
- Linear Sequential Model / Waterfall Model
- Incremental model
- Spiral model
- Prototyping Model
- Rapid Application Model (RAD)
- Agile Software Development (XP, FDD, Scrum XP)
Key Takeaways
- SDLC models vary from strict sequential to highly iterative and adaptive.
Predictive vs Adaptive Methodologies
Definition
- Two main software development approaches: predictive and adaptive.
Causes
- Differences in predictability of requirements and schedule.
Goals / Objectives
- Distinguish when each approach is appropriate.
Importance
- Selecting a methodology depends on how well requirements/schedule are known.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes beyond definitions
Impact / Effect
- Predictive suits known requirements; adaptive suits changing or unknown requirements.
Examples
- Predictive = plan-driven approach (e.g., Waterfall)
- Adaptive = Agile-driven approach
Key Takeaways
- Use predictive methods when requirements are known early.
- Use adaptive methods when requirements or schedule are uncertain.
Difference between Agile and Plan-driven (table content preserved)
Definition
- A side-by-side comparison of typical properties of Agile methods and Plan-driven methods.
Causes
- Not specified in notes
Goals / Objectives
- Help students compare characteristics to choose an approach.
Importance
- Shows practical trade-offs between adaptability and upfront assurance.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Comparison highlights pros/cons across dimensions such as requirements, refactoring cost, primary objective, customer involvement, development style, architecture, and team/product size.
Impact / Effect
- Guides selection of approach based on team size, customer availability, and requirement stability.
Examples (table content, each preserved as a bullet)
- Requirements: Agile — Largely emergent, rapid change; Plan-driven — Knowable early, largely stable.
- Refactoring: Agile — Inexpensive; Plan-driven — Expensive.
- Primarily objective: Agile — Rapid value; Plan-driven — High assurance.
- Customers: Agile — Dedicated, knowledgeable, collocated, collaborative, representative, and empowered; Plan-driven — Access to knowledgeable, collaborative, representative, and empowered customers.
- Development: Agile — Agile, knowledgeable, collocated, and collaborative; Plan-driven — Plan-oriented, adequate skills, access to external knowledge.
- Architecture: Agile — Designed for current requirements; Plan-driven — Designed for current and foreseeable requirements.
- Size: Agile — Smaller teams and products; Plan-driven — Larger teams and products.
Key Takeaways
- Agile fits changing requirements and smaller, collaborative teams.
- Plan-driven fits stable requirements and larger, assurance-focused projects.
Waterfall Model
Definition
- Waterfall Model: A linear sequential flow where progress flows steadily downward through phases and each phase begins only when the previous completes.
Causes
- Used historically when requirements are fixed and well-known.
Goals / Objectives
- Provide structured, phase-by-phase development with clear milestones.
Importance
- Oldest, well-known model; useful when changes are unlikely.
Procedures
- Phases and descriptions (all preserved):
- Requirements: Analyze potential requirements, deadlines, guidelines into a formal requirements/functional specification.
- Analysis: Generate product models and business logic; audit financial and technical feasibility.
- Design: Create design specification document covering programming language, hardware, data sources, architecture, services.
- Coding and implementation: Develop source code in smaller units then integrate.
- Testing: QA, unit, system and beta tests; may require returning to coding for fixes.
- Operation and deployment: Deploy to live environment when deemed functional.
- Maintenance: Carry out corrective, adaptive and perfective maintenance indefinitely (patches, updates, new versions).
Advantages & Disadvantages
- Advantages (from notes):
- Enables large or changing teams to move toward a common, defined goal.
- Forces structured, disciplined organization.
- Simplifies understanding, following and arranging tasks.
- Enables early system design and specification changes to be easily done.
- Clearly defines milestones and deadlines.
- Disadvantages (from notes):
- Design isn’t adaptive; flaws may force starting over.
- Delays testing until the end of the lifecycle.
- Not ideal for complex, high-risk ongoing projects.
- No working product until later stages.
Impact / Effect
- Predictable for stable projects but risky when requirements change; late testing increases chance of late discovery of major defects.
Examples
- Projects that do not focus on changing requirements, e.g., responses for Request for Proposals (RFPs).
Key Takeaways
- Waterfall is sequential and best when requirements are fixed.
- It provides structure and clear milestones but is inflexible to change.
When to Use Waterfall Model
Definition
- Conditions under which the waterfall model is appropriate.
Causes
- Not specified in notes
Goals / Objectives
- Help decide when waterfall is the right choice.
Importance
- Choosing waterfall for the right context avoids project risk.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- Using waterfall in the right conditions gives predictable delivery; using it incorrectly increases risk.
Examples / Conditions (from notes)
- Fixed requirements
- Ample resources
- An established timeline
- Well-understood technology
- Unlikely to require significant changes
Key Takeaways
- Use waterfall for stable, well-understood projects with clear timelines and resources.
V-Shaped Model
Definition
- V-Model: An extension of the waterfall where steps bend upward after coding to form a V shape, emphasizing early test planning.
Causes
- Used when requirements are clearly defined and development tools/techniques are known.
Goals / Objectives
- Provide verification and validation with early test planning aligned to development stages.
Importance
- Improves early test planning and traceability between requirements and tests.
Procedures
- Phases (as listed):
- Requirements Gathering and Analysis
- Design (high-level and detailed)
- Implementation (coding)
- Testing
- Deployment
- Maintenance
Advantages & Disadvantages
- Advantages (from notes):
- Verification and validation occur in early stages.
- Easy to use; stages and activities are well defined.
- Higher chance of success than waterfall because test plans develop early.
- Each phase has specific deliverables.
- Works well where requirements are easily understood.
- Disadvantages (from notes):
- Assumes requirements can be frozen from the start.
- Does not handle dynamic changes well.
- Inflexible; scope adjustments are difficult and expensive.
- Costly and time-consuming.
- Needs very proper and detailed planning.
- No continuous customer involvement.
Impact / Effect
- Better test alignment than waterfall but still rigid and expensive when requirements change.
Examples
- Not specified in notes
Key Takeaways
- V-Model adds early test planning to waterfall.
- It is useful for well-understood requirements but not for dynamic projects.
Incremental Model
Definition
- Incremental Model: Breaks requirements into multiple standalone modules or builds; each module goes through requirements, design, implementation and testing.
Causes
- Used to deliver working software early and evolve the system by successive builds.
Goals / Objectives
- Deliver functional increments quickly, allow flexibility and easier testing/debugging per iteration.
Importance
- Supports early market delivery and risk management by delivering core features first.
Procedures
- Stages (from notes):
- Requirement analysis — plan for the next increment only; easier to modify.
- Design & Development — develop core features first; refine with new functions in successive versions.
- Deployment and Testing — construct and deploy each successive version; test each increment.
- Implementation — after last version, deploy complete system to client site.
Advantages & Disadvantages
- Advantages (from notes):
- Generates working software quickly and early.
- More flexible; less costly to change scope/requirements.
- Easier to test and debug in smaller iterations.
- Customer can respond to each build.
- Lowers initial delivery cost.
- Easier risk management; identify and handle risky pieces during iteration.
- Disadvantages (from notes):
- Needs good planning and design.
- Needs a clear and complete definition of the whole system before breaking it down.
Impact / Effect
- Faster early functionality delivery and better risk containment; requires upfront understanding of major requirements.
Examples / When to use (from notes)
- Use when:
- Complete system requirements are clearly defined/understood.
- Major requirements defined but details may evolve.
- Need to get product to market early.
- New technology is used.
- Resources with needed skills are not available early.
- There are high-risk features and goals.
Key Takeaways
- Incremental builds deliver early value and reduce risk.
- It needs good planning and a clear view of overall system scope.
Spiral Model
Definition
- Spiral Model (also called the cyclic model): Software developed as a series of incremental releases with emphasis on risk analysis; four high-level phases: Planning, Design, Construct, Evaluation.
Causes
- Chosen when projects are large, requirements unclear/complex, or frequent delivery is required.
Goals / Objectives
- Manage risk through repeated cycles that include risk analysis and evaluation.
Importance
- Suited to large, high-budget, complex projects where risk must be controlled.
Procedures
- Phases (preserved from notes):
- Objectives Defined — clarify functional and non-functional goals.
- Risk Analysis — identify and evaluate project risks.
- Engineering — develop software for the iteration.
- Evaluation — evaluate if software meets customer requirements and quality.
- Planning — plan next iteration based on evaluation results.
Advantages & Disadvantages
- Advantages (from notes):
- Risk handling at every phase.
- Good for large and complex projects.
- Flexibility to incorporate requirement changes.
- Customer can see early product versions and habituate to system.
- Iterative and incremental approach improves adaptability.
- Improved communication via regular evaluations and reviews.
- Improved quality via multiple iterations.
- Disadvantages (from notes):
- Complex.
- Expensive; not suitable for small projects.
- Heavy dependence on risk analysis and experienced experts.
- Difficulty in time management; number of phases unknown at start.
- Time-consuming due to multiple evaluations and reviews.
Impact / Effect
- Strong risk mitigation and evolving product maturity but with higher complexity, cost and time overhead.
Examples / When to use (from notes)
- When delivery must be frequent.
- For large projects.
- When requirements are unclear and complex.
- When changes may be required at any time.
- For large and high-budget projects.
Key Takeaways
- Spiral is iterative with strong risk focus.
- Use it for large, risky, or unclear-requirement projects; expect higher cost and complexity.
Prototyping Model
Definition
- Prototyping Model: Build a working prototype (a toy implementation) before developing the actual software; iterative trial-and-error between developers and users.
Causes
- Used when project requirements are not known in detail ahead of time.
Goals / Objectives
- Explore requirements, get early user feedback, refine requirements until acceptable prototype is achieved.
Importance
- Reveals missing functionality early, increases customer comfort, and helps define unclear requirements.
Procedures
-
Steps / phases (preserved):
- Requirement Gathering and Analysis
- Quick Decision (quick design)
- Build a Prototype
- Assessment or User Evaluation (initial user evaluation)
- Prototype Refinement
- Engineer Product / Implement product and maintain
-
Prototype phases detailed:
- Step 1: Ask users what they expect/want.
- Step 2: Quick design to cover basic requirement visualization.
- Step 3: Build actual prototype.
- Step 4: Initial user evaluation for strengths/weaknesses.
- Step 5: Refine prototype using feedback.
- Step 6: Implement final product and maintain it.
Advantages & Disadvantages
- Advantages (from notes):
- New requirements easily accommodated.
- Missing functionalities discovered early.
- Early error detection saves effort and cost and improves quality.
- Developed prototype can be reused for complex projects.
- Flexibility in design.
- Customers see partial product early, increasing satisfaction.
- Disadvantages (from notes):
- Too much variation in requirements on repeated evaluations.
- Poor documentation due to continuous change.
- Difficult for developers to accommodate all customer changes.
- Uncertain number of iterations needed.
- Customers may demand final product quickly after seeing prototype.
- Developers in a hurry may deliver sub-optimal solutions.
- Customer might lose interest if not satisfied with early prototype.
Impact / Effect
- Rapid clarification of requirements and customer buy-in, but risks scope creep, documentation gaps and unrealistic customer expectations.
Examples / When to use (from notes)
- When customers do not know exact requirements.
- When developers are new to the domain.
- Use prototype as basis for final product after repeated refinement and acceptance.
Types of Prototyping Models (each preserved)
Rapid Throwaway Prototype
- Quickly developed representation based on preliminary requirements; discarded after requirements are baselined; useful for idea exploration and instant feedback.
Evolutionary Prototyping
- Prototype incrementally refined based on feedback until accepted; useful when new technology is not well understood or requirements are unstable.
Incremental Prototyping
- Final product split into small prototypes developed individually and later merged; reduces feedback time.
Extreme Prototyping
- Mostly used for web development; three sequential phases: Requirements Gathering and Analysis; Design and Prototype Development; Implementation and Refinement; focuses on user feedback and rapid prototyping.
Key Takeaways
- Prototyping uncovers unknowns early and supports iterative refinement.
- It risks repeated changes and documentation problems; choose it when requirements are unclear.
Agile Methodology
Definition
- Agile: An approach that seeks continuous delivery of working software in rapid iterations.
Causes
- Not specified in notes
Goals / Objectives
- Deliver useful software rapidly and adapt to changing requirements.
Importance
- Encourages customer involvement, frequent releases and responsiveness to change.
Procedures
- Not given as a single procedure, but includes principles and frameworks (XP, FDD, RAD mentioned).
Advantages & Disadvantages
- Advantages (from notes):
- Customer satisfaction via frequent releases and feedback.
- Frequent meetings before release.
- Better interaction between development and testing teams.
- Customers can change/add requirements at any stage.
- Focus on expert team members for processes.
- Disadvantages (from notes):
- Documentation could get lengthy.
- Not useful for small projects.
- Requires expert decision-makers in meetings.
- Can cost more compared to waterfall or iterative models.
Impact / Effect
- Enables rapid value delivery and adaptability but can increase documentation overhead and cost for some contexts.
Examples
- Agile variants listed: Extreme Programming (XP), Feature Driven Development (FDD), Rapid Application Development (RAD).
Key Takeaways
- Agile emphasizes frequent working releases and customer collaboration.
- It trades off some upfront planning for adaptability and speed.
Principles of Agile Development
Definition
- Twelve principles listed in the notes that guide Agile practice.
Causes
- Not specified in notes
Goals / Objectives
- Provide foundation for Agile behaviors and decisions.
Importance
- Forms the ethical/operational basis for Agile teams.
Procedures
- Not applicable to this topic
Advantages & Disadvantages
- Not specified in notes
Impact / Effect
- When followed, they create regular delivery, adaptability and team sustainability.
Principles (preserved in full)
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily co-operation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity — The art of maximizing the amount of work not done — is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
Key Takeaways
- Agile values working software, customer collaboration and adaptability.
- Teams should be motivated, co-located (when possible) and focus on technical excellence.
Extreme Programming (XP)
Definition
- Extreme Programming (XP): A specific Agile framework focusing on software practices to produce high-quality software and make the process easier on the team; values communication, feedback, simplicity, courage, and respect.
Causes
- Not specified in notes
Goals / Objectives
- Produce high-quality software through iterative coding, continuous testing and strong team practices.
Importance
- XP provides concrete practices for Agile teams, improving code quality and team skills.
Procedures
- XP phases (from notes):
- Planning — gather user stories, estimate, prioritize and create tasks.
- Design — design code architecture, choose language, environment, libraries.
- Coding — write code iteratively in small chunks and test regularly.
- Testing — developers write automated tests to catch bugs early.
- XP process elements illustrated: Planning, Design, Release, Testing, Coding, Refactoring.
Advantages & Disadvantages
- Advantages (from notes):
- Simple code that’s easy to improve.
- The XP cycle is visible.
- Constant testing increases agility.
- Uplifts team talent.
- Disadvantages (from notes):
- More attention on code and less on design.
- Not suited for remote teams.
- If issues aren’t documented properly, they can repeat.
Impact / Effect
- XP improves code quality and team capabilities but may under-emphasize formal design and struggle with distributed teams.
Examples / When best applied (from notes)
- Best applied when:
- Requirements constantly change
- Teams have tight deadlines
- Stakeholders want to reduce risk under deadlines
- Teams can automate unit and functional tests
Key Takeaways
- XP enforces frequent testing and iterative coding to handle changing requirements.
- It relies on strong team practices and automation; may not suit distributed teams.
Feature Driven Development (FDD)
Definition
- Feature Driven Development (FDD): A client-centric Agile methodology focusing on incremental development and frequent feature delivery, with strong status reporting.
Causes
- Not specified in notes
Goals / Objectives
- Deliver small client-valued features frequently (every 2–10 days) to improve tracking and onboarding.
Importance
- Scalable for large teams and long projects; provides frequent measurable progress.
Procedures
- FDD phases (from notes):
- Develop the overall model — determine scope and merge proposed models.
- Build the features list — outline customer-focused small functions.
- Plan by feature — order features and assign them.
- Design by feature — chief programmer chooses features for the period; create design package and review.
- Build by feature — develop and test feature code before finalizing.
Advantages & Disadvantages
- Advantages (from notes):
- Clear picture of project scope.
- User-centric approach.
- Works well with long projects and large teams.
- Decreased need for meetings.
- Disadvantages (from notes):
- Not good for small projects.
- Dependence on lead developers.
- No written documentation to the client.
Impact / Effect
- FDD provides frequent feature delivery and clarity for large teams, but it depends on leadership and may omit client documentation.
Examples
- Example feature: create an automatic reminder for subscription renewal (as an illustration in notes).
Key Takeaways
- FDD structures work around small, client-valued features and is scalable for large projects.
- It needs strong technical leads and may not suit small teams.
RAD Model (Rapid Application Development)
Definition
- RAD (Rapid Application Development): Based on prototyping and iterative development with minimal upfront detailed planning; the act of development includes necessary planning.
Causes
- Chosen when quick development of modular systems is required and requirements are relatively well-known.
Goals / Objectives
- Build systems quickly by iterative prototyping and user collaboration.
Importance
- Speeds up delivery and emphasizes reusable components and user involvement.
Procedures
- RAD phases (from notes):
- Requirements Planning — stakeholders collaborate to define scope and objectives.
- User Design — developers and users co-create detailed models and prototypes, iterating until interfaces and functionality match needs.
- Rapid Construction — develop the application using prototypes and design models.
- Cutover/Implementation — final deployment, testing, and transition to production.
Advantages & Disadvantages
- Advantages (from notes):
- Flexible to change.
- Changes are adoptable.
- Each phase brings highest-priority functionality to the customer.
- Reduces development time.
- Increases reusability of features.
- Disadvantages (from notes):
- Requires highly skilled designers.
- Not all applications are compatible with RAD.
- Not suitable for smaller projects.
- Not suitable for high technical risk projects.
- Requires user involvement.
Impact / Effect
- Rapid delivery and user-centered refinement but requires skill, budget and appropriate project types.
Examples / When to use (from notes)
- When system can be modularized within a short span (2–3 months).
- When requirements are well-known.
- When technical risk is limited.
- When budget allows use of automatic code-generating tools.
Key Takeaways
- RAD speeds development via prototyping and user collaboration.
- Use it for short, modular projects with available skilled designers and budget.
Exercise (Preserved Problem Statement)
Definition
- A project scenario for applying SPM selection knowledge.
Causes
- Not specified in notes
Goals / Objectives
- Task: Recommend an appropriate process model for the described e-learning project and justify the selection (assumptions allowed).
Importance
- Tests application of model-selection criteria to real constraints.
Procedures
- Problem summary (all details preserved):
- You are project manager for a 12-member team building an e-learning system for an established local college.
- During requirement analysis:
- Some requirements are not confirmed/finalized by the client.
- Some hardware needed must be ordered from overseas vendors with uncertain early availability.
- Client wants confirmed areas of the system delivered within two months for marketing use for the new academic intake.
Advantages & Disadvantages
- Not applicable to this topic (exercise expects student’s recommendation)
Impact / Effect
- The scenario stresses partial requirements, external hardware delays, short delivery window for confirmed features.
Examples
- Not applicable (this is itself the example)
Key Takeaways
- The exercise asks students to choose and justify an SPM given: partial requirements, hardware uncertainty, and a short deadline for partial deliverable delivery.
Final Key Points Across the Chapter
Definition
- Software processes organize activities (specification, development, validation, evolution) to produce software.
Causes
- Not specified in notes
Goals / Objectives
- Teach the range of SDLC/SPM options and how to choose them based on project characteristics.
Importance
- Selecting the right process affects schedule, quality, cost, and customer satisfaction.
Procedures
- Selection procedure summary:
- Learn candidate SPMs.
- Assess stakeholder needs (business domain, priorities, technical constraints).
- Define selection criteria (team size/skill, technology, distribution, complexity, risk, etc.).
- Match project context to model strengths and weaknesses.
Advantages & Disadvantages
- Each model lists its advantages and disadvantages in the chapter; preserve model-specific trade-offs when choosing.
Impact / Effect
- Proper alignment of model to project reduces risk, controls costs, and improves deliverables.
Examples
- Models to consider (complete list preserved):
- Waterfall, V-Model, Incremental, Spiral, Prototyping variants, RAD, Agile family (XP, FDD, Scrum), ASD, DSDM, RUP, Crystal Clear, etc.
Key Takeaways
- No single SPM fits all projects; choose based on requirement stability, team size/skill, technology familiarity, delivery frequency and risk profile.
- Understand each model’s steps, advantages and limitations before applying it to a real project.