Identify and discuss at least 3 systems development models .. discuss each phases ...
A Process Model
Software process models are universal approaches to organize projects into actions. Regularly represents a system series of activities, objects, transformations, and events that symbolize strategies for accomplishing software evolution. These models can be used in developing more precise and formalized descriptions of software life cycle activities.
The Traditional Process Models
Based on the resources that I have read there the traditional process models are the following:
1. The Classic Software Life Cycle (Waterfall Model)
• Frequently embodied 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). Going back to the previously finished phase, as well as skipping a phase are not allowed on this model.
2. Stepwise Refinement Model
• Developing software systems through the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili1986). However, the choice and order of which steps to choose and which refinements to apply remain unstated.
3. The Incremental Release Model
• Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals (Basili 1975). This model combines the classic software life cycle with iterative enhancement at the level of system development organization.
4. Military Standards Based Model
• Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices (Royce 1970, Boehm 1976, Distaso 1980, Humphrey 1985, Scacchi 1984, Somerville 1999). Such standardization is often motivated by needs to simplify or eliminate complications that emerge during large software development or project management.
5. Build-and-fix Model
• Adopted from an earlier and simpler age of hardware product development. The product’s overall quality is never really addressed, even though some of the development issues are ultimately corrected. Also, there is no way to feed back to the design process any proactive improvement approaches.
6. Spiral Model
• An enhancement of the waterfall/rapid prototype model, with risk analysis preceding each phase of the cascade. This model has been successfully used for the internal development of large systems and is especially useful when software reuse is a goal and when specific quality objectives can be incorporated. Like the other extensions of and improvements to the waterfall model, it adds feedback to earlier stages.
7. Iterative Development Model (Evolutionary Model)
• The most realistic of the traditional software development models. Rather than being open-loop like build-and-fix or the original waterfall models, it has continuous feedback between each stage and the prior one.
Rapid prototyping and extreme programming are processes that have more recently augmented the waterfall model.
• Rapid Prototyping- long been used in the development of one-off programs, based on the familiar model of the chemical engineer’s pilot plant. More recently it has been used to prototype larger systems in two variants—the “throwaway” model and the “operational” model, which is really the incremental model. This development process produces a program that performs some essential or perhaps typical set of functions for the final product.
• Extreme Programming - recent development of the incremental model that puts the client in the driver’s seat. Each feature or feature set of the final product envisioned by the client and the development team is individually scoped for cost and development time. This development model is distinguished by its flexibility because it can work in the face of a high degree of specification ambiguity on the user’s part.
• Object-Oriented Programming (OOP) technology- not a software development model. However, OOP does enhance the effectiveness of earlier software development models intended for procedural programming languages, because it allows the development of applications by slices rather than by layers. The central ideas of OOP are encapsulation and polymorphism, which dramatically reduce complexity and increase program reusability.
Each of these models uses comprehensive characterizations when describing software evolution. These models are independent of any organizational development setting, choice of programming language, software application domain, etc. To be brief, 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, they are referred as the traditional models, and characterizes each in turn.
Process Models in Recent Times
1. Rational Unified Process
• Characterized by a set of software best practices and the extensive application of use cases. Its most important advantage is its iterative process that allows changes in functional requirements also to be accommodated as they inevitably change during system development. Not only do external circumstances reflect changes to the design, but also the user’s understanding of system functionality becomes clearer as that functionality develops.
2. Capability Maturity Model
• An organizational maturity model, not a specific technology model. Maturity involves continuous process improvement based on evaluation of iterative execution, gathering results, and analyzing metrics. As such, it has a very broad universe of application.
Strengths/Weaknesses of the Process Models
Software process models are universal approaches to organize projects into actions. Regularly represents a system series of activities, objects, transformations, and events that symbolize strategies for accomplishing software evolution. These models can be used in developing more precise and formalized descriptions of software life cycle activities.
The Traditional Process Models
Based on the resources that I have read there the traditional process models are the following:
1. The Classic Software Life Cycle (Waterfall Model)
• Frequently embodied 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). Going back to the previously finished phase, as well as skipping a phase are not allowed on this model.
2. Stepwise Refinement Model
• Developing software systems through the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili1986). However, the choice and order of which steps to choose and which refinements to apply remain unstated.
3. The Incremental Release Model
• Developing systems through incremental release requires first providing essential operating functions, then providing system users with improved and more capable versions of a system at regular intervals (Basili 1975). This model combines the classic software life cycle with iterative enhancement at the level of system development organization.
4. Military Standards Based Model
• Industrial firms often adopt some variation of the classic model as the basis for standardizing their software development practices (Royce 1970, Boehm 1976, Distaso 1980, Humphrey 1985, Scacchi 1984, Somerville 1999). Such standardization is often motivated by needs to simplify or eliminate complications that emerge during large software development or project management.
5. Build-and-fix Model
• Adopted from an earlier and simpler age of hardware product development. The product’s overall quality is never really addressed, even though some of the development issues are ultimately corrected. Also, there is no way to feed back to the design process any proactive improvement approaches.
6. Spiral Model
• An enhancement of the waterfall/rapid prototype model, with risk analysis preceding each phase of the cascade. This model has been successfully used for the internal development of large systems and is especially useful when software reuse is a goal and when specific quality objectives can be incorporated. Like the other extensions of and improvements to the waterfall model, it adds feedback to earlier stages.
7. Iterative Development Model (Evolutionary Model)
• The most realistic of the traditional software development models. Rather than being open-loop like build-and-fix or the original waterfall models, it has continuous feedback between each stage and the prior one.
Rapid prototyping and extreme programming are processes that have more recently augmented the waterfall model.
• Rapid Prototyping- long been used in the development of one-off programs, based on the familiar model of the chemical engineer’s pilot plant. More recently it has been used to prototype larger systems in two variants—the “throwaway” model and the “operational” model, which is really the incremental model. This development process produces a program that performs some essential or perhaps typical set of functions for the final product.
• Extreme Programming - recent development of the incremental model that puts the client in the driver’s seat. Each feature or feature set of the final product envisioned by the client and the development team is individually scoped for cost and development time. This development model is distinguished by its flexibility because it can work in the face of a high degree of specification ambiguity on the user’s part.
• Object-Oriented Programming (OOP) technology- not a software development model. However, OOP does enhance the effectiveness of earlier software development models intended for procedural programming languages, because it allows the development of applications by slices rather than by layers. The central ideas of OOP are encapsulation and polymorphism, which dramatically reduce complexity and increase program reusability.
Each of these models uses comprehensive characterizations when describing software evolution. These models are independent of any organizational development setting, choice of programming language, software application domain, etc. To be brief, 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, they are referred as the traditional models, and characterizes each in turn.
Process Models in Recent Times
1. Rational Unified Process
• Characterized by a set of software best practices and the extensive application of use cases. Its most important advantage is its iterative process that allows changes in functional requirements also to be accommodated as they inevitably change during system development. Not only do external circumstances reflect changes to the design, but also the user’s understanding of system functionality becomes clearer as that functionality develops.
2. Capability Maturity Model
• An organizational maturity model, not a specific technology model. Maturity involves continuous process improvement based on evaluation of iterative execution, gathering results, and analyzing metrics. As such, it has a very broad universe of application.
Strengths/Weaknesses of the Process Models
| Model | Strength | Weakness |
| Classic Software Lifecycle (Waterfall) | Disciplined, document-driven | Result may not satisfy client |
| Stepwise Refinement Model | Effective and widely applied in helping to teach individual programmers how to organize their software development work | Choice and order of which steps to choose and which refinements to apply remain unstated |
| Incremental Release Model | Promotes maintainability | Can degenerate build-and-fix |
| Military Standards Based Model | Simplify or eliminate complications that emerge during large software development or project management. | Organized software development activities according to succession of military software standards |
| Build-and-fix Model | Okay for small one-off programs | Useless for large programs |
| Spiral Model | Ultimate Waterfall Model | Large system in-house development only |
| Iterative Development Model | Can be used by OOP | May allow overiteration |
| Rapid Prototyping | Guarantees Client Satisfaction | May not work for large applications |
| Extreme Prototyping | Early return on software development | Has not yet been widely used |
| OOP Technology | Supported by IDE tools | May lack discipline |
| Rational Unified Process | -Well supported by tools -Supports OOP development | -Expensive to maintain - High training costs |
| Capability Maturity Model | -Provides process guidelines -Documentation facilitated, comprehensive, detailed | - Some firms may seek to gain certification without process redesign |
References:
Anon, 199?. Software Development Methodology Today[Online] Available at: http://ptgmedia.pearsoncmg.com/images/0131872508/samplechapter/0131872508_ch01.pdf
John Wiley and Sons, Inc, New York, December 2001. Process Models in Software Engineering[Online](Updated October 2001) Available at: www.ics.uci.edu/~wscacchi/Papers/SE.../Process-Models-SE-Encyc.pdf
No comments:
Post a Comment