Objectives:
understand the concepts of software processes and software process models;
■ have been introduced to three generic software process models and when they might be used;
■ know about the fundamental process activities of software requirements engineering, software
development, testing, and evolution;
■ understand why processes should be organized to cope with changes in the software requirements
and design;
■ understand how the Rational Unified Process integrates good software engineering practice to
create adaptable software processes.
Definition:
A software process is a set of related activities that leads to the production of a software product.
These activities may involve the development of software from scratch in a standard programming
language like Java or C.
There are many different software processes but all must include four activities that are
fundamental to software engineering:
1. Software specification the functionality of the software and constraints on its operation must be
defined.
2. Software design and implementation the software to meet the specification must be produced.
3. Software validation The software must be validated to ensure that it does what the customer
wants.
4. Software evolution The software must evolve to meet changing customer needs.
For business systems, with rapidly changing requirements, a less formal, flexible process is likely to
be more effective
Agile vs plan drive:
software processes are categorized as either plan-driven or agile processes.
Plan-driven processes are processes where all the process activities are planned in advance and
progress is measured against this plan.
In agile processes planning is incremental and it is easier to change the process to reflect changing
customer requirements.
As Boehm and Turner (2003) discuss, each approach is suitable for different types of software.
Generally, you need to find a balance between plan-driven and agile processes. Although there is no
‘ideal’ software process, there is scope for improving the software process in many organizations.
Software process models
1.The waterfall model
2. Incremental development
3.Reuse-oriented software engineering
These models are not mutually exclusive and are often used together, especially for large systems
development. For large systems, it makes sense to combine some of the best features of the
waterfall and the incremental development models
The waterfall model
The waterfall model is an example of a plan-driven process—you must plan and schedule all of the
process activities before starting work on them.
The principal stages of the waterfall model directly reflect the fundamental development activities:
1. Requirements analysis and definition The system’s services, constraints, and goals are established
by consultation with system users. They are then defined in detail and serve as a system
specification.
2. System and software design The systems design process allocates the requirements to either
hardware or software systems by establishing an overall system architecture. Software design
involves identifying and describing the fundamental software system abstractions and their
relationships.
3. Implementation and unit testing During this stage, the software design is realized as a set of
programs or program units. Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have been met. After testing,
the software system is delivered to the customer.
5. Operation and maintenance Normally (although not necessarily), this is the longest life cycle
phase. The system is installed and put into practical use. Maintenance involves correcting errors
which were not discovered in earlier stages of the life cycle, improving the implementation of system
units and enhancing the system’s services as new requirements are discovered.
The following phase should not start until the previous phase has finished
. In practice, these stages overlap and feed information to each other.
During design, problems with requirements are identified. During coding, design problems are found
and so on. The software process is not a simple linear model but involves feedback from one phase
to another.
Documents produced in each phase may then have to be modified to reflect the changes made
Because of the costs of producing and approving documents, iterations can be costly and involve
significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of the
development, such as the specification, and to continue with the later development stages.
Problems are left for later resolution, ignored, or programmed around. This premature freezing of
requirements may mean that the system won’t do what the user wants. It may also lead to badly
structured systems as design problems are circumvented by implementation tricks.
During the final life cycle phase (operation and maintenance) the software is put into use. Errors and
omissions in the original software requirements are discovered. Program and design errors emerge
and the need for new functionality is identified. The system must therefore evolve to remain useful.
Making these changes (software maintenance) may involve repeating previous process stages.
This makes the process visible so managers can monitor progress against the development plan. Its
major problem is the inflexible partitioning of the project into distinct stages. Commitments must
be made at an early stage in the process, which makes it difficult to respond to changing customer
requirements
the waterfall model should only be used when the requirements are well understood and unlikely to
change radically during system development.
Incremental development
**Incremental Development:**
- **Concept:** Developing a software system by building an initial version and then evolving it
through several iterations based on user feedback.
- **Interleaved Activities:** Unlike the waterfall model where specification, development, and
validation are separate, incremental development combines these activities with rapid feedback.
- **Suitability:** Ideal for most business, e-commerce, and personal systems. Aligns with problem-
solving approaches involving step-by-step progress and occasional backtracking.
- **Benefits Over Waterfall:**
1. **Cost Reduction:** Accommodating changing customer requirements is cheaper, as less
analysis and documentation need redoing compared to the waterfall model.
2. **Customer Feedback:** Easier for customers to provide feedback by evaluating working
software rather than design documents.
3. **Rapid Delivery:** Allows for the early delivery and use of useful software, even if all
functionality isn't complete.
- **Common Approach:** Incremental development is now the most common approach for
application systems, often combining both plan-driven and agile methods.
- **Management Challenges:**
1. **Lack of Visibility:** Incremental progress can be less visible to managers, who typically rely on
regular deliverables for measuring progress.
2. **Structural Degradation:** Software structure can deteriorate over time with new increments,
necessitating refactoring to maintain quality.
- **Challenges in Large Systems:** Incremental development may face greater challenges in large,
complex, and long-lifetime systems. Clear architectural planning and coordination between
development teams become essential.
- **Incremental Delivery vs. Deployment:** Incremental development allows exposing the system to
customers for feedback without necessarily delivering it for operational use. Incremental delivery
and deployment in operational processes may disrupt business as usual and require careful
consideration.
- **Advantages and Disadvantages of Incremental Delivery:** Detailed discussion on the pros and
cons of deploying software incrementally is found in Section 2.3.2.
**Boehm's Spiral Model:**
- **Framework:** Proposed by Boehm in 1988, it's a risk-driven software process framework
depicted as a spiral, not a linear sequence of activities.
- **Spiral Structure:** The spiral has loops, each representing a phase of the software process (e.g.,
feasibility, requirements, design).
- **Change Management:** Combines change avoidance and tolerance, assuming changes result
from project risks. Includes explicit risk management activities to reduce these risks.
- **Four Sectors in Each Loop:**
1. **Objective Setting:** Define specific objectives for the phase, identify process and product
constraints, and create a detailed management plan. Identify project risks and plan alternative
strategies based on these risks.
2. **Risk Assessment and Reduction:** Analyze each identified project risk in detail and take steps
to reduce it. For instance, if requirements are risky, develop a prototype system.
3. **Development and Validation:** Choose a development model based on risk evaluation. For
example, use throwaway prototyping for user interface risks or formal transformations for safety
risks. The chosen model guides development.
4. **Planning:** Review the project and decide whether to continue with the next spiral loop. If
continuing, create plans for the next phase.
- **Explicit Recognition of Risk:** The primary distinction from other software process models is its
explicit consideration of risk. The spiral starts by defining objectives and identifying ways to achieve
them while dealing with constraints. Each alternative is assessed against objectives, and project risks
are identified.
- **Risk Resolution:** After risk assessment, development occurs, followed by planning for the next
phase. Risk minimization is vital to avoid project problems like schedule and cost overruns.
- **Risk Management:** Risk management is a crucial part of project management within this
model, as addressing risks is essential to project success. Detailed risk management is covered in
Chapter 22 of the model's framework.
