Software Development Models

4. Software Development Process 3 hours

4.1 Software development process models,

4.2 Organizing the process.

Software Development Process

A software development process, also known as a software development life cycle (SDLC) or software life cycle or software process, is a structure imposed on the development of a software product. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. It aims to be the standard that defines all the tasks required for developing and maintaining software.

Software development process models

The major software development process models are:

1. Waterfall model

2. Evolutionary/Increment model

a. Prototyping model

b. Spiral model

3. Transformation model

Waterfall model

Advantage of waterfall model

· Disciplined approach

· Careful checking by the Software Quality Assurance Group at the end of each phase.

· Testing in each phase.

· Documentation available at the end of each phase

Waterfall model problems:

· It is difficult to respond to changing customer requirements.

· Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

· Few business systems have stable requirements.

· The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

· The customer must have patience. A working version of the program will not be available until late in the project time-span

· Feedback from one phase to another might be too late and hence expensive.

Evolutionary/Incremental model

The traditional waterfall model is applicable for software products that do not change very much once they are specified. However, for software products that have their feature sets redefined during development because of user feedback and other factors, the traditional waterfall model is no longer appropriate. For such type of software development, the incremental/evolutionary model is appropriate.

The incremental model or EVO model uses small, incremental product releases, frequent delivery to users, and dynamic plans and processes. Although EVO is relatively simple in concept, its implementation included both significant challenges and notable benefits. The EVO development model divides the development cycle into smaller, incremental waterfall models in which users are able to get access to the product at the end of each cycle. The users provide feedback on the product for the planning stage of the next cycle and the development team responds, often by changing the product, plans, or process. These incremental cycles are typically two to four weeks in duration and continue until the product is delivered to the end user.

Some evolutionary models are:

1. Prototyping model

2. Spiral model

Advantages

- Customers can be involved at an early stage.

- Each increment/evolution delivers a functionally operational product and thus customers can get to see the working version of the product at each stage.

- The biggest benefit of the evolution model is significant reduction in risk for software project.

Prototyping model

The goal of prototyping based development is to remove the limitations of the waterfall model. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

Prototyping is useful for complicated and large systems for which there is no manual process or existing system to help determining the requirements. It is also an effective method to demonstrate the feasibility of a certain approach. The process model of the prototyping approach is shown in the figure below.

Fig: prototyping model of software development  The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. The prototypes are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality. In addition, the cost of testing and writing detailed documents are reduced. These factors help to reduce the cost of developing the prototype

Advantages of Prototyping

- Users are actively involved in the development

- It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.

- Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

- Errors can be detected much earlier as the system is made side by side.

- Quicker user feedback is available leading to better solutions.

Disadvantages

1. Leads to implementing and then repairing way of building systems.

2. Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.  

Spiral model

The spiral model, also known as the spiral lifecycle model, is a system development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

Fig: spiral model of software development.

1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

2. A preliminary design is created for the new system.

3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

4. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.

5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

7. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

8. The final system is constructed, based on the refined prototype.

9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages

 Emphasis on alternatives and constraints supports the reuse of existing solutions.

 Targets testing by treating it as a risk, which has to be addressed.

 Maintenance is just another phase of the spiral model. It is treated in the same way as development.

 Estimates (budget and schedule) get more realistic as work progresses, because important issues are discovered earlier.

 It is more able to cope with the (nearly inevitable) changes that software development generally entails.

 Software engineers, who can get restless with protracted design processes, can get their hands in and start working on a project earlier.

Disadvantages

 Only intended for internal projects (inside a company), because risk is assessed as the project is developed. Hardly suitable for contractual software development.

 In case of contractual software development, all risk analysis must be performed by both client and developers before the contract is signed and not as in the spiral model.

 Spiral model is risk driven. Therefore it requires knowledgeable staff.

 Suitable for only large scale software development. Does not make sense if the cost of risk analysis is a major part of the overall project cost.

Advantages

· High amount of risk analysis

· Good for large and mission-critical projects.

· Software is produced early in the software life cycle.

Disadvantages

· Can be a costly model to use.

· Risk analysis requires highly specific expertise.

· Project’s success is highly dependent on the risk analysis phase.

· Doesn’t work well for smaller projects.

· 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. Disadvantages

1. Risk analysis requires high expertise. 2. It is costly model to use  Requirements analysis and specificationOptimizationRequirementsFormal specificationsVerification Tuning Lower level specificationsRecording of developmental historyReusable componentsDecisions & rationale

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 practitioners unlike the waterfall model or prototyping model.

Transformation model

Another model that is used in software development is the transformation model. This model consists of two main stages:

- Requirement analysis and specification

- Optimization

The first statge provides a formal specification of requirements, which is fed into the optimization process that does the performance tuning, until a satisfactory optimized result is produced. The initial specification may not be executable. It is then refined and becomes executable and efficient. The transformation process is controlled by the software engineer and may take the advantage of the availability of reusable components. The specifications are validated against the user’s requirements to check whether they capture the real requirements. The validation of the requirements is done in a variety of ways such as proving formal properties, animating the specification or executing it.

The transformation-based life cycle may be supported by a suitable computer aided software development environment. The environment provides tools for validating requirements, handling reusable components, performing optimizations according to some existing catalogue or following directives from the software engineer and storing the history of the development of the software. Maintaining a history of the development is an important feature for supporting future requests for changes. An ideal transformation-based process model is given below.

Fig: An ideal transformation-based process model.  A fileAdatatransformerAn output deviceAn input device.The transformation approach is not a practical approach for software production process models. It is still a research oriented approach and only experimental environments are available to support it.

Organizing the process

The organization of the software process is a critical activity which includes everything from the management of people to the management of all products produced during the software life cycle. It also involves the definition of appropriate methods and their combination within methodologies. There are well-known methodologies that are used to organize the process, they are:

- Structured analysis/ Structured design (SA/SD)

- Jackson’s system development (JSD)

- Unified software development process (UP)

Structured analysis/ Structured design (SA/SD)

Structured analysis/design (SA/SD) is methodology that suggests the use of three major conceptual tools for constructing system models. They are: data flow diagram (DFD), a data dictionary (DD) and structured English (SE).

The data flow diagram is a graphical design notation that is used to organize the software process. The DFD describes the functional specification of the software. The main components of the DFD are shown in figure:

A data dictionary is a centralized collection of definitions of all data flowing among functions and to or from data stores. Centralizing all definitions in the dictionary removes the danger of duplications and inconsistencies. Structured English is any highly constrained subset of natural language used to describe the data transformation performed by each elementary model.

SA/SD uses the DFD as specification of the behavior (i.e. functional requirements) of the application. The design that is the decomposition of the system into modules is based directly on the DFD and is documented using structured diagram. An SD is a directed acyclic graph in which nodes represents modules. The direction of arrow is not shown explicitly and is assumed. Each module represents a functional abstraction, to be implemented later by a subprogram.

Jackson’s System Development

Jackson System Development (JSD) is a method of system development that covers the software life cycle either directly or, by providing a framework into which more specialized techniques can fit. The basic principle of operation of JSD is that:

 Development must start with describing and modeling the real world, rather than specifying or structuring the function performed by the system. A system made using JSD method performs the simulation of the real world before any direct attention is paid to function or purpose of the system.

 Main aim is to map progress in the real world on progress in the system that models it.

 The way of implementing the system is based on transformation of specification into efficient set of processes. These processes should be designed in such a manner that it would be possible to run them on available software and hardware.

According to JSD, software development proceeds through the sequence of three stages. They are

1. Modeling Stage (Analysis)

2. Network Stage (Design)

3. Implementation Stage (Realization)

Modeling Stage

In the modeling stage the designer creates a collection of entity structure diagrams and identifies the entities in the system, the actions they perform, the time-ordering of the actions in the life of the entities, and the attributes of the actions and entities. Entity structure diagrams use the diagramming notation of Jackson Structured Programming structure diagrams. Purpose of these diagrams is to create a full description of the aspects of the system and the organization.

Network Stage

In the network stage a model of the system as a whole is developed and represented as a system specification diagram (SSD) (also known as a network diagram). Network diagrams show processes (rectangles) and how they communicate with each other, either via state vector connections (diamonds) or via datastream connections (circles). In this stage, the functionality of the system defined. Each entity becomes a process or program in the network diagram. External programs are later added to the network diagrams. The purpose of these programs is to process input, calculate output and to keep the entity processes up-to-date. The whole system is described with these network diagrams and is completed with descriptions about the data and connections between the processes and programs.

Implementation Stage

In this stage, the network of the processes is transformed into an implementation. That is the concurrent network of processes is transformed into sequential system that is executable by a conventional machine.

Unified software development process

The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The Unified Process divides the project into four phases:

 Inception

 Elaboration

 Construction

Transition

Fig: Unified software development process

Inception

This phase also known as feasibility study phase. Its goal is to document a vision of the product and a business analysis that justifies why the development should be undertaken. The document should address the following questions:

- Who are the expected users of the system and why should they be willing to use it?

- What is the preliminary architecture of the system?

- What is the development plan and what are the expected development costs?

Elaboration

The primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, class diagrams and architectural diagrams.

Construction

Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one becomes the start of a new iteration. Common UML (Unified Modeling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams.

Transition Phase

The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations. The Transition phase also includes system conversions and user training.