Identify and discuss at least 3 systems development models
Software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.
Software process networks can be viewed as representing multiple interconnected task chains (Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).
Software process networks can be viewed as representing multiple interconnected task chains (Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. Winograd and others have referred to these units of cooperative work between people and computers as "structured discourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).
Task chains can be employed to characterize either prescriptive or descriptive action sequences. Prescriptive task chains are idealized plans of what actions should be accomplished, and in what order. For example, a task chain for the activity of object-oriented software design might include the following task actions:
_ Develop an informal narrative specification of the system.
_ Identify the objects and their attributes.
_ Identify the operations on the objects.
_ Identify the interfaces between objects, attributes, or operations.
_ Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.
Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990). Thus, any software production web will in some way realize only an approximate or incomplete description of software development.
The classic software life cycle is often represented as a simple prescriptive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order (Royce 1970). Such models resemble finite state machine descriptions of software evolution. However, these models have been perhaps most useful in helping to structure, staff, and manage large software development projects in complex organizational settings, which was one of the primary purposes (Royce 1970, Boehm 1976). Alternatively, these classic models have been widely characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should occur. Figure 1 provides a common view of the waterfall model for software development attributed to Royce (1970).
Waterfall
-Linear sequence of stages/phases
-Requirements – HLD – DD – Code – Test – Deploy
-A phase starts only when the previous has completed; no feedback
-The phases partition the project, each addressing a separate concern\
-Linear ordering implies each phase should have some output
-The output must be validated/certified
-Outputs of earlier phases: work products
-Common outputs of a waterfall: SRS, project plan, design docs, test plan and
reports, final code, supporting docs
-Linear ordering implies each phase should have some output
-The output must be validated/certified
-Outputs of earlier phases: work products
-Common outputs of a waterfall: SRS, project plan, design docs, test plan and reports, final code, supporting docs
-Conceptually simple, cleanly divides the problem into distinct phases that can be performed independently
-Natural approach for problem solving
-Easy to administer in a contractual setup – each phase is a milestone
-Has been used widely
-Well suited for projects where requirements can be understood easily and technology decisions are easy
-I.e. for familiar type of projects it still may be the most optimum
Strength
Simple, Easy to execute, Intuitive and logical, Easy contractually
Weakness
All or nothing – too, risky, Require frozen early, May chose outdated hardware/tech, Disallows changes, No feedback from users, Encourages requirements bloating
Types of Projects
Well understood problems, short duration projects, automation of existing manual systems
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.
Development of prototype- Starts with initial requirements. Only key features which need better understanding are included in prototype. No point in including those features that are well understood. Feedback from users taken to improve the understanding of the requirements.
Cost can be kept low- Build only features needing clarification. “quick and dirty” – quality not important, scripting etc can be used. Things like exception handling, recovery, standards are omitted. Cost can be a few % of the total. Learning in prototype building will help in building, besides improved requirements.
Advantages: requirements will be more stable, requirements frozen later, experience helps in the main development.
Applicability: When required to elicit and confidence in reqs is low; i.e. where reqs are not well understood. Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987). In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping can more directly accommodate early 10 user participation in determining, shaping, or evaluating emerging system functionality. Therefore, these up-front concentrations of effort, together with the use of prototyping technologies, seeks to trade-off or otherwise reduce downstream software design activities and iterations, as well as simplify the software implementation effort. (see Rapid Prototyping) Software prototypes come in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes (Hekmatpour 1987). Increasing functionality and subsequent evolvability is what distinguishes the prototype forms on this list. Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model (described later) and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well as overall software development.
1.People who actually work at a job have the best understanding of that job.
2.People who are trained in software development have the best understanding of the
possibilities of that technology.
3. Software-based information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
4.The best information systems are designed when all of these groups work together on a project as equal partners. Following these ideas, it should be possible for JAD to cover the complete development life cycle of a system. The JAD is usually a 3 to 6 month well-defined project, when systems can be constructed from commercially available software products that do not require extensive coding or complex systems integration. For large-scale projects, it is recommended that the project be organized as an incremental development effort, and that separate JAD's be used for each increment (Wood and Silver 1995). Given this formulation, it is possible to view open source software development projects that rely on group email discussions among globally distributed users and developers, together with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), as an informal variant of JAD.
- Each iteration is a mini waterfall – decide the specs, then plan the iteration
- Time boxing – fix an iteration duration, then determine the specs
- Divide iteration in a few equal stages
- Use pipelining concepts to execute iterations in parallel
- General iterative development – fix the functionality for each iteration, then plan and execute it
- In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it
- Completion time is fixed, the functionality to be delivered is flexible
- This itself very useful in many situations
- Has predictable delivery times
- Overall product release and marketing can be better planned
- Makes time a non-negotiable parameter and helps focus attention on schedule
- Prevents requirements bloating
- Overall dev time is still unchanged
- What if we have multiple iterations executing in parallel
- Can reduce the average completion time by exploiting parallelism
- For parallel execution, can borrow pipelining concepts from hardware
- This leads to Timeboxing Process Model
- With this type of time boxes, can use pipelining to reduce cycle time
- Like hardware pipelining – view each iteration as an instruction
- As stages have dedicated teams, simultaneous execution of different iterations is possible
Advantages: Shortened delivery times, other adv of iterative, distr. execution
Applicability: When short delivery times v. imp.; architecture is stable; flexibility in feature grouping
- Software development is divided into cycles, each cycle delivering a fully working system
- Each cycle executed as separate project
- Execution of a cycle is broken into four consecutive phases, each phase ending with a milestone achievement
- Phases in a project
- Inception phase: ends with Lifecycle Objectives milestone; vision and high level capability of system defined
- Elaboration phase: Lifecycle architecture milestone; most requirements defined and architecture designed
- Construction phase: Initial operational capability milestone
- Transition phase: Product release; transition product from development to production
- Each phase itself can be done in multiple iterations, each iteration having an external/internal customer
- Generally construction has multiple iterations; elaboration can also be meaningfully done in multiple iterations
- Engineering tasks are called core process workflows
- These sub processes correspond to tasks of requirements, design, implementation, testing, project management, etc
- Many sub processes may be active in a phase, the volume of activity generally differs depending on the project
- Sub processes are active in all phases
- Volume of activity in each phase differs depending on the project
- Hence, a project can use RUP to implement waterfall by having requirements process be active only in the elaboration phase
- Or prototyping by having a lot of construction activity in the elaboration phase
- RUP is therefore a flexible framework
Strength
All benefits of iterative
Provides a flexible framework for a range of projects
Weakness
For each project, one has to design the process
Types of Projects
Can be applied to a wide range as it allows flexibility
- Most agile approaches have some common principles
- Working software is the measure of progress
- Software should be delivered in small increments
- Even late changes should be allowed
- Prefer face to face commn over documentation
- Continuous feedback and customer involvement is necessary
- Prefer simple design which evolves
- Delivery dates are decided by the empowered teams
- Many agile methodologies have been proposed; extreme programming (XP) is one of the most popular
- An XP project starts with user stories, which are short descr of user needs
- Details are not included
- Each user story written on a separate card so they can be combined in diff ways
- Team estimates how long it will take to implement a user story
- Estimates are rough
- Release planning is done
- Defines which stories are to be built in which release, and dates for release
- Frequent and small releases encouraged
- Acceptance tests also built from user stories; used to test before release
- Bugs found in AT are fixed in next release
- Development done in iterations of a few weeks each
- Iteration starts with planning, in which stories to be implemented are selected – high risk high value are chosen first
- Details of stories obtained during the development and implemented
- Failed AT of previous iteration are also fixed
- Well suited for situations where volume and pace of requirements is high
- Customer is willing to engage heavily with the team
- The team is collocated and is not too large (less than 20 or so)
- Requires strong capability in team members
Strength
Agile and responsive
Short delivery cycles
Continuous feedback can lead to better acceptance
Weakness
Can tend to become ad-hoc
Lack of documentation can be an issue
Continuous code change is risky
Types of Projects
Where requirements are changing a lot, customer is deeply engaged in development, and where the size of the project is not too large
References:
Process Models in Software Engineering
Walt Scacchi, Institute for Software Research, University of California, Irvine
February 2001
J.J. Marciniak (ed.), Encyclopedia of Software Engineering, 2nd
Edition, John Wiley and Sons, Inc, New York, December 2001.
_ Develop an informal narrative specification of the system.
_ Identify the objects and their attributes.
_ Identify the operations on the objects.
_ Identify the interfaces between objects, attributes, or operations.
_ Implement the operations.
Clearly, this sequence of actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.
Task chains join or split into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncratic foul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi 1990). Thus, any software production web will in some way realize only an approximate or incomplete description of software development.
Waterfall
The classic software life cycle (or "waterfall chart") and stepwise refinement models are widely instantiated in just about all books on modern programming practices and software engineering. The incremental release model is closely related to industrial practices where it most often occurs. Military standards based models have also reified certain forms of the classic life cycle model into required practice for government contractors. Each of these four models uses coarse-grain or macroscopic characterizations when describing software evolution. The progressive steps of software evolution are often described as stages, such as requirements specification, preliminary design, and implementation; these usually have little or no further characterization other than a list of attributes that the product of such a stage should possess. Further, these models are independent of any organizational development setting, choice of programming language, software application domain, etc. In short, the traditional models are context-free rather than context-sensitive. But as all of these life cycle models have been in use for some time, we refer to them as the traditional models, and characterize each in turn.The classic software life cycle is often represented as a simple prescriptive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order (Royce 1970). Such models resemble finite state machine descriptions of software evolution. However, these models have been perhaps most useful in helping to structure, staff, and manage large software development projects in complex organizational settings, which was one of the primary purposes (Royce 1970, Boehm 1976). Alternatively, these classic models have been widely characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should occur. Figure 1 provides a common view of the waterfall model for software development attributed to Royce (1970).
Waterfall
-Linear sequence of stages/phases
-Requirements – HLD – DD – Code – Test – Deploy
-A phase starts only when the previous has completed; no feedback
-The phases partition the project, each addressing a separate concern\
-Linear ordering implies each phase should have some output
-The output must be validated/certified
-Outputs of earlier phases: work products
-Common outputs of a waterfall: SRS, project plan, design docs, test plan and
reports, final code, supporting docs
-Linear ordering implies each phase should have some output
-The output must be validated/certified
-Outputs of earlier phases: work products
-Common outputs of a waterfall: SRS, project plan, design docs, test plan and reports, final code, supporting docs
-Conceptually simple, cleanly divides the problem into distinct phases that can be performed independently
-Natural approach for problem solving
-Easy to administer in a contractual setup – each phase is a milestone
-Has been used widely
-Well suited for projects where requirements can be understood easily and technology decisions are easy
-I.e. for familiar type of projects it still may be the most optimum
Strength
Simple, Easy to execute, Intuitive and logical, Easy contractually
Weakness
All or nothing – too, risky, Require frozen early, May chose outdated hardware/tech, Disallows changes, No feedback from users, Encourages requirements bloating
Types of Projects
Well understood problems, short duration projects, automation of existing manual systems
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.
Prototyping
Prototyping addresses the requirement specification limitation of waterfall. Instead of freezing requirements only by discussions, a prototype is built to understand the requirements. Helps alleviate the requirements risk. A small waterfall model replaces the requirements stage.Development of prototype- Starts with initial requirements. Only key features which need better understanding are included in prototype. No point in including those features that are well understood. Feedback from users taken to improve the understanding of the requirements.
Cost can be kept low- Build only features needing clarification. “quick and dirty” – quality not important, scripting etc can be used. Things like exception handling, recovery, standards are omitted. Cost can be a few % of the total. Learning in prototype building will help in building, besides improved requirements.
Advantages: requirements will be more stable, requirements frozen later, experience helps in the main development.
Applicability: When required to elicit and confidence in reqs is low; i.e. where reqs are not well understood. Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987). In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping can more directly accommodate early 10 user participation in determining, shaping, or evaluating emerging system functionality. Therefore, these up-front concentrations of effort, together with the use of prototyping technologies, seeks to trade-off or otherwise reduce downstream software design activities and iterations, as well as simplify the software implementation effort. (see Rapid Prototyping) Software prototypes come in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes (Hekmatpour 1987). Increasing functionality and subsequent evolvability is what distinguishes the prototype forms on this list. Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstration systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model (described later) and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well as overall software development.
Spiral Model
The Spiral Model. The spiral model of software development and evolution represents a riskdriven approach to software process analysis and structuring (Boehm 1987, Boehm et al, 1998). This approach, developed by Barry Boehm, incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. It does so by representing iterative development cycles as an expanding spiral, with inner cycles denoting early system analysis and prototyping, and outer cycles denoting the classic software life cycle. The radial dimension denotes cumulative development costs, and the angular dimension denotes progress made in accomplishing each development spiral. See Figure 3. Risk analysis, which seeks to identify situations that might cause a development effort to fail or go over budget/schedule, occurs during each spiral cycle. In each cycle, it represents roughly the same amount of angular displacement, while the displaced sweep volume denotes increasing levels of effort required for risk analysis. System development in this model therefore spirals out only so far as needed according to the risk that must be managed. Alternatively, the spiral model indicates that the classic software life cycle model need only be followed when risks are greatest, and after early system prototyping as a way of reducing these risks, albeit at increased cost. The insights that the Spiral Model offered has in turned influenced the standard software life cycle process models, such as ISO12207 noted earlier. Finally, efforts are now in progress to integrate computer-based support for stakeholder negotiations and capture of trade-off rationales into an operational form of the WinWin Spiral Model (Boehm et al, 1998). (see Risk Management in Software Development)(JAD)
Joint Application Development (JAD) is a technique for engaging a group or team of software developers, testers, customers, and prospective end-users in a collaborative requirements elicitation and prototyping effort (Wood and Silver 1995). JAD is quintessentially a technique for facilitating group interaction and collaboration. Consultants often employ JAD or external software system vendors who have been engaged to build a custom software system for use in a particular organizational setting. The JAD process is based on four ideas:1.People who actually work at a job have the best understanding of that job.
2.People who are trained in software development have the best understanding of the
possibilities of that technology.
3. Software-based information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
4.The best information systems are designed when all of these groups work together on a project as equal partners. Following these ideas, it should be possible for JAD to cover the complete development life cycle of a system. The JAD is usually a 3 to 6 month well-defined project, when systems can be constructed from commercially available software products that do not require extensive coding or complex systems integration. For large-scale projects, it is recommended that the project be organized as an incremental development effort, and that separate JAD's be used for each increment (Wood and Silver 1995). Given this formulation, it is possible to view open source software development projects that rely on group email discussions among globally distributed users and developers, together with Internet-based synchronized version updates (Fogel 1999, Mockus 2000), as an informal variant of JAD.
Timeboxing
- Iterative is linear sequence of iterations- Each iteration is a mini waterfall – decide the specs, then plan the iteration
- Time boxing – fix an iteration duration, then determine the specs
- Divide iteration in a few equal stages
- Use pipelining concepts to execute iterations in parallel
- General iterative development – fix the functionality for each iteration, then plan and execute it
- In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it
- Completion time is fixed, the functionality to be delivered is flexible
- This itself very useful in many situations
- Has predictable delivery times
- Overall product release and marketing can be better planned
- Makes time a non-negotiable parameter and helps focus attention on schedule
- Prevents requirements bloating
- Overall dev time is still unchanged
- What if we have multiple iterations executing in parallel
- Can reduce the average completion time by exploiting parallelism
- For parallel execution, can borrow pipelining concepts from hardware
- This leads to Timeboxing Process Model
- With this type of time boxes, can use pipelining to reduce cycle time
- Like hardware pipelining – view each iteration as an instruction
- As stages have dedicated teams, simultaneous execution of different iterations is possible
Advantages: Shortened delivery times, other adv of iterative, distr. execution
Applicability: When short delivery times v. imp.; architecture is stable; flexibility in feature grouping
RUP Model
- Rational Unified Process is another iterative model- Software development is divided into cycles, each cycle delivering a fully working system
- Each cycle executed as separate project
- Execution of a cycle is broken into four consecutive phases, each phase ending with a milestone achievement
- Phases in a project
- Inception phase: ends with Lifecycle Objectives milestone; vision and high level capability of system defined
- Elaboration phase: Lifecycle architecture milestone; most requirements defined and architecture designed
- Construction phase: Initial operational capability milestone
- Transition phase: Product release; transition product from development to production
- Each phase itself can be done in multiple iterations, each iteration having an external/internal customer
- Generally construction has multiple iterations; elaboration can also be meaningfully done in multiple iterations
- Engineering tasks are called core process workflows
- These sub processes correspond to tasks of requirements, design, implementation, testing, project management, etc
- Many sub processes may be active in a phase, the volume of activity generally differs depending on the project
- Sub processes are active in all phases
- Volume of activity in each phase differs depending on the project
- Hence, a project can use RUP to implement waterfall by having requirements process be active only in the elaboration phase
- Or prototyping by having a lot of construction activity in the elaboration phase
- RUP is therefore a flexible framework
Strength
All benefits of iterative
Provides a flexible framework for a range of projects
Weakness
For each project, one has to design the process
Types of Projects
Can be applied to a wide range as it allows flexibility
Extreme Programming or Agile Process Model
- Agile approaches developed in 90s as a reaction to document driven approaches- Most agile approaches have some common principles
- Working software is the measure of progress
- Software should be delivered in small increments
- Even late changes should be allowed
- Prefer face to face commn over documentation
- Continuous feedback and customer involvement is necessary
- Prefer simple design which evolves
- Delivery dates are decided by the empowered teams
- Many agile methodologies have been proposed; extreme programming (XP) is one of the most popular
- An XP project starts with user stories, which are short descr of user needs
- Details are not included
- Each user story written on a separate card so they can be combined in diff ways
- Team estimates how long it will take to implement a user story
- Estimates are rough
- Release planning is done
- Defines which stories are to be built in which release, and dates for release
- Frequent and small releases encouraged
- Acceptance tests also built from user stories; used to test before release
- Bugs found in AT are fixed in next release
- Development done in iterations of a few weeks each
- Iteration starts with planning, in which stories to be implemented are selected – high risk high value are chosen first
- Details of stories obtained during the development and implemented
- Failed AT of previous iteration are also fixed
- Well suited for situations where volume and pace of requirements is high
- Customer is willing to engage heavily with the team
- The team is collocated and is not too large (less than 20 or so)
- Requires strong capability in team members
Strength
Agile and responsive
Short delivery cycles
Continuous feedback can lead to better acceptance
Weakness
Can tend to become ad-hoc
Lack of documentation can be an issue
Continuous code change is risky
Types of Projects
Where requirements are changing a lot, customer is deeply engaged in development, and where the size of the project is not too large
References:
Process Models in Software Engineering
Walt Scacchi, Institute for Software Research, University of California, Irvine
February 2001
J.J. Marciniak (ed.), Encyclopedia of Software Engineering, 2nd
Edition, John Wiley and Sons, Inc, New York, December 2001.
No comments:
Post a Comment