Software Process Models

Prepared By: Deepak Gurung Ganesh Oli Kamal Raj Dhamaniya Siraj Timalsina

Evolutionary Software Process Models

There is growing recognition that software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds, making a straight path to an end product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure; a set of core product or system requirements is well understood, but the details of product or system extensions have yet to be defined. In these and similar situations, software engineers need a process model that has been explicitly designed to accommodate a product that evolves over time. Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.

Concurr ent activities Specification Initial version

Outline description

Development

Intermediate versions

Validation

Final version

The linear sequential model is designed for straight-line development. In essence, this waterfall approach assumes that a complete system will be delivered after the linear sequence is completed. The prototyping model is designed to assist the customer (or developer) in understanding requirements. In general, it is not designed to deliver a production system. The evolutionary nature of software is not considered in either of these classic software engineering paradigms.

Advantages
Increased risk analysis (especially for Spiral). Good for large and mission-critical projects. Software is produced early and often in the lifecycle, with customer evaluation.

Disadvantags Can be costly to use. Risk analysis requires highly specific expertise. Projects progress is highly dependent upon the risk analysis phase. Does not work well for smaller projects.

Applicability For small or medium size interactive systems. For parts of large systems (e.g.the user interface). For short life time systems.

Spiral Model:
The spiral model of software development and evolution represents a risk-driven approach to software process analysis and structuring. This approach, developed by Mr. Berry Boehm(Boehm 1987, Boehm et al, 1998), incorporates elements of specification driven, prototype-driven process methods, together with the classic software life cycle. . It is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of linear sequential model. An important feature of this model is that it has risk analysis as one of its framework of activities. Therefore, it requires risk assessment expertise. An Example of Spiral Model

Different Tasks in Spiral Model

 Customer communicationtasks required to establish effective communication between developer and customer. Planningtasks required to dene resources, timelines, and other project related information. Risk analysistasks required to assess both technical and management risks. Engineeringtasks required to build one or more representations of the application. Construction and releasetasks required to construct, test, install, and provide user support (e.g., documentation and training ). Customer evaluationtasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Main Characteristics of Spiral Model: Also a hybrid model that support process iteration The process is represented as a spiral, each loop in the spiral representing a process phase Four sectors per loop: objective setting, risk assessment and reduction, development and validation, planning Risk is explicitly taken into consideration

Advantages of Using Spiral Model: Realistic model-It is a realistic model for development of large scale software system. Customer & developer under stand the requirement & risks more clearly. Risk reduction- Prototyping is done at any stage in the product development Risks-risks are analyzed at every stage It maintains systematic approach of waterfall model and applies it in an iterative manner. This represents the real world closer.

Disadvantages of Using Spiral Model: It is not a complete solution for every situation. Expertise is required for risk analysis Difficult to convince customers about the evolutionary nature. If a risk is not analyzed or found in early cycles, it may become a major problem later on. It is not as widely used as water fall and prototyping models. Applicability of Spiral Model: Internal development of large systems

Prototyping Model
A prototype is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. Rapid, iterative development of the prototype is essential so that costs are controlled and system stakeholders can experiment with the prototype early in the software process. A software prototype can be used in a software development process to help anticipate changes that may be required: 1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements. 2. In the system design process, a prototype can be used to explore particular software solutions and to support user interface design.

System prototypes allow users to see how well the system supports their work. They may get new ideas for requirements, and find areas of strength and weakness in the software. They may then propose new system requirements. Furthermore, as the prototype is developed, it may reveal errors and omissions in the requirements that have been proposed. A function described in a specification may seem useful and well defined. However, when that function is combined with other functions, users often find that their initial view was incorrect or incomplete. The system specification may then be modified to reflect their changed understanding of the requirements.

Phases of Prototyping Model

Figure: The process of prototype development

A process model for prototype development is shown in above Figure. The objectives of prototyping should be made explicit from the start of the process. These may be to develop a

system to prototype the user interface, to develop a system to validate functional system requirements, or to develop a system to demonstrate the feasibility of the application to managers. The same prototype cannot meet all objectives. If the objectives are left unstated, management or end-users may misunderstand the function of the prototype. Consequently, they may not get the benefits that they expected from the prototype development. The next stage in the process is to decide what to put into and, perhaps more importantly, what to leave out of the prototype system. To reduce prototyping costs and accelerate the delivery schedule, we may leave some functionality out of the prototype. Error handling and management may be ignored unless the objective of the prototype is to establish a user interface. Standards of reliability and program quality may be reduced. The final stage of the process is prototype evaluation. Provision must be made during this stage for user training and the prototype objectives should be used to derive a plan for evaluation. Users need time to become comfortable with a new system and to settle into a normal pattern of usage. Once they are using the system normally, they then discover requirements errors and omissions.

The prototype can serve as "the first system." It is true that both customers and developers like the prototyping paradigm. Users get a feel for the actual system and developers get to build something immediately. Yet, prototyping can also be problematic for the following reasons: 1. The customer sees what appears to be a working version of the software, unaware that the prototype is held together with chewing gum and baling wire, unaware that in the rush to get it working no one has considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high levels of quality can be maintained, the customer cries foul and demands that "a few fixes" be applied to make the prototype a working product. Too often, software development management relents. 2. The developer often makes implementation compromises in order to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is available and known; an inefficient algorithm may be implemented simply to demonstrate capability. After a time, the developer may become familiar with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system.

Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is to define the rules of the game at the beginning; that is, the customer and developer must both agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part) and the actual software is engineered with an eye toward quality and maintainability.

Rapid Application Development (RAD) Model

This process is a linear sequential software development process that emphasizes an extremely short development cycle. It is achieved through a modular based construction approach. It is best used for software projects where requirements are well-understood, project scope is properly constrained, and big budget with resources are available. Everybody is expected to be committed to a rapid approach to development. In this process model, the software project is defined based on functional decomposition of the software. Functional partitions are assigned to different teams, and are developed in parallel.

Figure: The RAD Model RAD model has the following phases:

1. Business Modeling: The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on. 2. Data Modeling: The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined. 3. Process Modeling: The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object. 4. Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques. 5. Testing and Turn over: Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised.

The advantages of this model are: A fully functional system is created in a short span of time. It encourages the development of program component reusable. Constant integration isolate problems and encourage customer feedback.

The disadvantages of this model are: For large but scalable projects, this process requires a sufficient number of developers to have the right number of development teams. Developers and customers must be committed to the rapid-fire of activities necessary to develop the software in a short amount of time. It is not a good process model for systems that require high performance. It is not a good process model for systems that make use of new technology or high degree of interoperability with existing computer programs such as legacy systems.