Software process models

Chapter 4

Software process is a set of activities that leads to the production of a software product. There’s no, of course, ideal software process and every project needs different. Software processes are complex and, like all other intellectual and creative processes, rely on people making decisions and judgments.

Still, there are some common parts for almost any software process:

1. Software specification. Defining the functionality of the software and constraints on its operation.
2. Software design and implementation.
3. Software validation. Testing the product to ensure it meets all requirements.
4. Software evolution.

Software processes can be improved by process standardisation where diversity in software processes across an organisation is reduced.

Three process models covered in this chapter are:

1. Waterfall model. Dividing fundamental processes (specification, implementation etc) into phases.
2. Evolutionary development. An initial system is rapidly developed from abstract specifications.
3. Component-based software engineering. Development process is focused on integrating reusable components into a system rather than developing them from scratch.

In practice, of course, it is often impossible to work all the way trough within only one model. For example, sub-systems may be developed using different model than main system. Often, models are combined.

Principal stages of the waterfall model are:

1. Requirements analysis and definition.
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance.

The main principle is that the next phase cannot begin before previous is done. In practice, these stages may overlap and feed information to each other. During design, problems with requirements are identified. During coding design problems are found and so on. During the final life cycle phase (operation and maintenance) the software put into use. Errors and omissions in the original software requirements are discovered. The system must evolve to be useful.

The advantages of waterfall model are that documentation is produced at each phase and that it fits with other engineering process models. Its major problem is its flexible partitioning of the project into distinct stages. Commitments must be made at early stage in the process, which makes it difficult to respond to changing customer requirements.

There are two fundamental types of evolutionary development:

1. Exploratory development where the objective of the process is to work with the customer to explore their requirements and deliver a final system. The development starts with the parts of the system that are understood. The system evolves by adding new features proposed by the customer.
2. Throwaway prototyping where the objective of the evolutionary development process is to understand the customer’s requirements and hence develop a better requirements definition for the system.

This approach is often more effective than the waterfall approach in producing systems that meet the immediate needs of customers. However, there are two major problems with this model:

• The freelance writing jobs process is not visible. Managers need regular deliverable to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
• Systems are often poorly structured.

These problems are acute when the project is large, for the small systems (up to 500,000 lines of code) the author of the book thinks that the evolutionary process it the best choice.

In the majority of systems there is some software reuse. Pretty often this happens informally, when people working on the project know of designs or code which is similar to that required. The look at these, modify them and reuse in current project. It is often essential for rapid system development. Stages for software process using component-based model are:

1. Component analysis
2. Requirements modification
3. System design with reuse
4. Development and integration.

Change is inevitable in all large software projects. The system requirements change as the business procuring the system responds to external pressures. Management priorities change; new technologies become available, design and implementation change. This means that the software process is not a one-off process; rather, the process activities are regularly repeated as the system is reworked in response to change requests. There are two process models that have been designed to support process iteration:

1. Incremental delivery. The whole process of software development are broken down into a series of increments that are each developed in a turn. This process is something between the waterfall model and evolutionary model cell phone spy software. Customers identify the services to be provided by the system. They also identify which of the services are most important for them and which are less. After basic development, customers take early delivery of part of the system and then they can experiment with the system. This helps them clarify their requirements for later increments. New increments are developed and combined with the existing parts, so the system is getting better and more functional after each increment.loan modification
2. Spiral development. The development of the system spirals outwards from an initial outline through to the final developed system. This process may be represented as a spiral. Each loop represents a phase of the software process. Thus, the innermost loop might be concerned with system feasibility. Next loop – with requirement definition, etc. link building service

My thoughts:

I really think mixing different software process models can give better results than using just one model of bread machine. Even for such a small project as our Monopoly game, we started as a waterfall model: defining requirements and use-cases first, then – designing the system, components and signals. When coding takes place, I think it might be better to switch the process to something between waterfall model and evolutionary development. This sounds like incremental delivery, where customers are us, developers. We develop some part of a system, make it executable and testable and test this part as if we were end-customers. This kind of work will reduce some errors, which can be seen only while executing and testing.