2.3 Software Development Process Models

            For the software development process, the goal is to produce a high-quality software product. We just focuses on activities directly related to production of the software, for example, design, coding, and testing.The management process is often decided based on the development process.

            A project’s development process defines the tasks the project should perform, and the order in which they should be done. A process limits the degrees of freedom for a project by specifying what types of activities must be undertaken and in what order.

            Due to the importance of the development process, various models have been proposed. In this section we will discuss some of the major models.

2.3.1 Waterfall Model

           As the name implies, waterfall model is like a waterfall. Fall down and can't get up again. The process must be fully completed. A process must be completed before entry to the process, as well as so on. Because in this waterfall model we cannot go back to the previous stage. The waterfall Model is typically used for someone who is already adept, so she really know what will happen. And also this model can be used to create simple software. This Model is not recommended for beginners and complex software. The simplest process model is the waterfall model, which states that the phases are organized in a linear order.In this model, a project begins with feasibility analysis.The design starts after the requirements analysis is complete, and coding begins after the design is complete. 

            The following documents generally form a reasonable set that should be produced in each project:

– Requirements document

– Project plan

– Design documents (architecture, system, detailed)

– Test plan and test reports

– Final code

– Software manuals (e.g., user, installation, etc.)

         

2.3.2 Prototyping

            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, which can enable the client to better understand the requirements of the desired system. This results in more stable requirements that change less frequently.

          In the prototyping model, a prototype is built before building the final system, which is used to further develop the requirements leading to more stable requirements. This is useful for projects where requirements are not clear.

2.3.3 Iterative Development

            The basic idea is that the software should be developed in increments, each increment adding some functional capability to the system until the full system is implemented.
            In this model, the software is developed in iterations, each iteration resulting in work system software. This Model does not require all the requirements known at the beginning, can allow feedback from the beginning of the next iteration, and can reduce risk in delivering value as the project progresses.

2.3.4 Rational Unified Process (RUP)

            RUP proposes that development of software be divided into cycles, each cycle delivering a fully working system. Each cycle itself is broken into four consecutive phases:

– Inception phase

– Elaboration phase

– Construction phase

– Transition phase

            Phase may itself can be done iteratively. Subprocesses of the requirements, Design, coding, testing, etc. are considered active by the whole project, although their intensity vary from stage to stage. RUP is a flexible framework. Using traditional waterfall if you like, or let the prototype if it so wishes.

2.3.5 Timeboxing Model

            In the timeboxing model, the basic unit of development is a time box, which is of fixed duration. Since the duration is fixed, a key factor in selecting the requirements or features to be built in a time box is what can be fit into the time box..There is a team that is committed to every stage of iteration. A different iteration is then executed in a manner be pipelined. Each team works at different stages. Like a couple of iterations remaining active, this model reduces the average completion time per iteration. In this model is very suitable for a software that you would like made in a short time

            The timeboxing provides an approach for utilizing additional manpower to reduce the delivery time. It provides a way of shortening delivery times through the use of additional manpower.

2.3.6 Extreme Programming and Agile Processes

            There are many other rules in XP relating to issues like rights of programmers and customers, communication between the team members and use of metaphors, trust and visibility to all stakeholders, collective ownership of code in which any pair can change any code, team management, building quick spike solutions to resolve difficult technical and architectural issues or to explore some approach, how bugs are to be handled, how what can be done within an iteration is to be estimated from the progress made in the previous iteration, how meetings are to be conducted, how a day in the development should start, etc. 

2.3.7 Using Process Models in a Project

            As mentioned earlier, while developing (industrial strength) software, the purpose is not only to develop software to satisfy the needs of some users or clients, but we want that the project be done in low cost and cycle time, and deliver high-quality software. Let us illustrate this by a few examples.

            Suppose a small team of developers has been entrusted with the task of building a small auction site for a local university. The university administration is willing to spend some time at the start to help develop the requirements, but it is expected that their availability will be limited later. The team has been given 4 months to finish the project, and an extension of the deadline seems very improbable. It also seems that the auction site will have some features that are essential, but will also have some features that are desirable but without which the system can function reasonably well.       With these constraints, it is clear that a waterfall model is not suitable for this project, as the “all or nothing” risk that it entails is unacceptable due to the inflexible deadline.

            Consider another project, where a university wants to automate the registration process. It already has a database of courses and pre-requisites, and a database of student records. In this project, as the requirements are well understood (since registrations have been happening manually), the waterfall model seems to be the optimum.


Reference :
Software Engineering-London Springer-Verlag London (2008)