Assignment # 01

Subject: Topic: Submitted To: Mr. Abid Rafiq Submitted By:

Ehtesham Ahsan BSIT-F07-M036

Software Engineering
Software Process Models

Department of CS & IT University of Sargodha

.
Date: /10/2009

Software Process Model

Software process model is an abstract representation of software process. Each process model represents a process from a particular perspective, and thus provides only partial information about that process. Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker" or corporate IT bureaucrat (which is probably ten times dangerous then undisciplined hacker). The process model which are covered here are: Waterfall model Prototyping model Incremental model Built & fix model Spiral model

Waterfall model
The least flexible of the life cycle models. Still it is well suited to projects which have a well defined architecture and established user interface and performance requirements. The waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and

unlikely to change significantly over the course of development.

Advantages
1. Clear project objectives. 2. Stable project requirements. 3. Progress of system is measurable. 4. Simple and easy to use 5. Easily manageable 6. The phase of the model are processed and completed one at a time. 7. Works very well for smaller software projects 8. It needs very few resources to implement.

Disadvantages
1. Problems are not discovered until system testing. 2. Requirements must be fixed before the system is designed - requirements evolution makes the development method unstable. . 3. System performance cannot be tested until the system is almost coded; under capacity may be difficult to correct. 4. Project may miss functionality if not all requirements were captured in the requirements stage. 5. It is often difficult for the customer to state all the requirements explicitly. 6. The model is not suitable for long time software projects

7. Estimating time and costs is difficult for each stage.

Usage
Where Requirements are full. No change in requirements. Having proper skills.

Prototyping model
It was advocated by Brooks. Useful in "proof of concept" or situations where time, cost are limited and requirements and user's needs are unclear or poorly specified. The approach is to construct a quick and dirty partial implementation of the system during or before the requirements phase. Typical implementation language is scripting language and UNIX shell (due to availability huge amount of components that can be used for construction of the prototype. Prototyping consists of developing a partial implementation of the system to give the users a feel for what the developer has in mind. The users then give feedback on what they think of the prototype - what works and what doesnt - and the developer can make changes more easily and efficiently than if the changes were to be made later on in development. Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration. Prototyping is a technique that provides a reduced functionality or limited performance version of the eventual software to be delivered to the user in the early stages of the software development process. If used judiciously, this approach helps to solidify user requirements earlier, thereby making the waterfall approach more effective. What is done is that before proceeding with design and coding, a throw away prototype is built to give user a feel of the system. The development of the software prototype also involves design and coding, but this is not done in a formal manner. The user interacts with the prototype(sample) as he would do with the eventual system and would therefore be in a better position to specify his requirements in a more detailed manner. The iterations occur to refine the prototype to satisfy the needs of the user, while at the same time enabling the developer to better understand what needs to be done.

Advantages

May take longer to develop using this method because of the long process of developing prototypes which may be radically altered or thrown-away. Requires a pretty good knowledge of the problem domain in order to create a prototype in the first place.

Customers can see steady progress. This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when no one fully understands the application area. 1. Strong Dialogue between users and developers 2. Missing functionality can be identified easily 3. Confusing or difficult functions can be identified 4. Requirements validation, Quick implementation of, incomplete, but functional, application 5. May generate specifications for a production application 6. Environment to resolve unclear objectives 7. Encourages innovation and flexible designs

Disadvantages

Since it takes longer to get to the implementation stage, not all project resources are needed at the beginning of the project. Allows for less understanding of the overall requirements and for.

It is impossible to know at the outset of the project how long it will take. There is no way to know the number of iterations that will be required

Contract may be awarded without rigorous evaluation of Prototype 2. Identifying non-functional elements difficult to document 3. Incomplete application may cause application not to be used as the full system was designed 4. Incomplete or inadequate problem analysis 5. Client may be unknowledgeable. 6. Approval process and requirement is not strict 7. Requirements may frequently change significantly

Incremental model
Generates working software quickly and early during the software life cycle. * More flexible - less costly to change scope and requirements. * Easier to test and debug during a smaller iteration. * Easier to manage risk because risky pieces are identified and handled during its iteration. * Each iteration is an easily managed milestone In an Incremental development, the system is developed in different stages, with each stage consisting of requirements, design, development, and test phases. In each stage, new functionality is added. This type of development allows the user to see a functional product very quickly and allows the user to impact what changes are included in subsequent releases.

Advantages
System is developed and delivered in increments after establishing an overall architecture. Requirements and specifications for each increment may be developed. Users may experiment with delivered increments while others are being developed. Intended to combine some of the advantages of prototyping but with a more manageable process and better system structure. Incremental development is especially useful when staffing us unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people

Disadvantages
* each phase of an iteration is rigid and do not overlap each other. * Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. There must be little requirements volatility because it is expensive to go back and redesign something that has already been tested in a previous increment

Built & fix model

In this most simple model of software development, the product is constructed with minimal requirements, and generally no specifications nor any attempt at design, and testing is most often neglected. This is a representation of what is happening in many software development projects. Note that this way of doing is not only a counterexample: it has its benefits in some situations.

Advantages
Cost efficient for very small projects of limited complexity.

Disadvantages
Unsatisfying approach for products of reasonable size. Cost is higher for larger projects. Product will not be delivered on time most of the times. Often results in a product of overall low quality. No documentation is produced. Maintenance can be extremely difficult without specification and design document.

Spiral Model

This model proposed by Barry Bohem in 1988, attempts to combine the strengths of various models. It incorporates the elements of the prototype driven approach along with the classic software life cycle. Is also takes into account the risk assessment whose outcome determines taking up the next phase of the designing activity. Unlike all other models which view designing as a linear process, this model views it as

a spiral process. This is done by representing iterative designing cycles as an expanding spiral. Typically the inner cycles represent the early phase of requirement analysis along with prototyping to refine the requirement definition, and the outer spirals are progressively representative of the classic software designing life cycle. At every spiral there is a risk assessment phase to evaluate the designing efforts and the associated risk involved for that particular iteration. At the end of each spiral there is a review phase so that the current spiral can be reviewed and the next phase can be planned. Spiral Model for software development was designed in order to overcome the disadvantages of the Waterfall Model. The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model.
For projects with risky elements, it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle.

The Spiral model of development is risk-oriented. Each spiral addresses a set of major risks that have been identified. Each spiral consists of: determining objectives, alternatives, and constraints, identifying and resolving risks, evaluating alternatives, developing deliverables, planning the next iteration, and committing to an approach to the next iteration. (Barry Boehm, "A Spiral Model of Software Development and Enhancement", Computer, May 1988) Six major activities of each designing spirals are represented by six major tasks: 1. Customer Communication 2. Planning 3. Risk Analysis 4. Software Designing Engineering 5. Construction and Release 6. Customer Evolution
1. 2. 3. 4.
Determine objectives, alternatives and constraints. Identify and resolve risks. Evaluate alternatives. Develop the deliverables for that iteration and verify that they are correct. 5. Plan the next iteration. 6. Commit to an approach for the next iteration.

Applications
The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003 - 2009), it had a 2 year iteration (spiral) length. FCS should have resulted in 3 consecutive prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009

Advantages 1. It facilities high amount of risk analysis. 2. This software designing model is more suitable for designing and managing large software projects. 3. The software is produced early in the software life cycle. The spiral model promotes quality assurance through prototyping at each stage in systems development. 4.The Software is produced early in the software life cycle.
5.It facilitates high amount of risk analysis.

1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the (nearly inevitable) changes that software development generally entails. 3. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier Risk reduction mechanisms are in place Supports iteration and reflects real-world practices Systematic approach
1. Avoidance of Risk is enhanced. 2. Strong approval and documentation control. 3. Implementation has priority over functionality. 4. Additional Functionality can be added at a later date

Early iterations of the project are the cheapest, enabling the highest risks to be addressed at the lowest total cost. This ensures that as costs increase, risks decrease. 2. Each iteration of the spiral can be tailored to suit the needs of the project. Since it takes longer to get to the implementation stage, not all project resources are needed at the beginning of the project. Allows for a very complex project with incomplete initial understanding of requirements since development is done in small, spiral phases where each phase consists of requirements, risk analysis, and design. Allows for high requirements volitility Disadvantages
1. Risk analysis requires high expertise. 2. It is costly model to use 3. Not suitable for smaller projects.

4. There is a lack of explicit process guidance in determining objectives, constraints and alternatives.. 5. This model is relatively new. It does not have many practioners unlike the waterfall model or prototyping model

Requires considerable expertise in risk evaluation and reduction Complex and relatively difficult to follow strictly Applicable only to large systems Risk assessment could cost more than development Need for further elaboration of spiral modelsteps (milestones, specifications, guidelines and checklists) 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Requires expertise in risk evaluation and reduction Complex, relatively difficult to follow strictly Risk of not meeting budget or schedule 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Possibility to end up implemented as the Waterfall framework
It is complicated and requires attentive and knowledgeable management to pull it off.

Requires good knowledge of the problem domain