Chapter 2 Summary

Software Engineering

Note: This summary is not sufficient for exam preparation. It doesn’t cover 100% of the material.
The best way to use it is for last day revision when time is very limited. A complete revision of
the slides is necessary in order to be ready for the exams.

PART I: The software processes

It is a structured set of activities that are required to develop a software system. Also called Software
Development Life Cycle (SDLC).

All software processes involve:

 Specification: defining what the system should do.

 Design and implementation: defining the organization of the system and implementing it.
 Validation: checking that it does what the customer wants.
 Evolution: changing the system in response to changing customer needs.

1- Plan-Driven and Agile Processes:

Plan-driven processes are processes where all of the process activities are planned in advance and
progress is measured against this plan.

In Agile processes, planning is incremental -> easier to change the process to reflect changing customer
requirements.

In practice, most practical processes include elements of both plan-driven and agile approaches.

2- Software Process Models:

• The Waterfall Process Model: Plan-driven model. Separate phases of specification and
development.

• Incremental Process Model: Plan-driven or agile model. Separate and distinct phases of
specification and development in increments.

• Evolutionary Process Model: An iterative model. It enables you to develop increasingly more
complete version of the software. Emphasis on risk management.

In practice, most large systems are developed using a process that incorporates elements from all of
these models.

3- The waterfall model:

 • Works for well understood problems with minimal or no changes in the requirements.

• Simple and easy to explain to customers.

• Mostly used for large systems engineering projects where a system is developed at several
sites. As the plan-driven nature of this model helps coordinate the work.

4- Waterfall model phases:

There are separate identified phases in the waterfall model:

a. Requirements analysis and definition

b. System and software design
c. Implementation and unit testing
d. Integration and system testing
e. Operation and maintenance

Each major phase is marked by milestones and deliverables (artifacts)

5- Waterfall drawbacks:

a. The main drawback of the waterfall model is the difficulty of accommodating change after the
process is underway. In principle, a phase has to be complete before moving onto the next phase. It is
often difficult for the customer to state all requirements explicitly from the beginning.

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

b. The customer must have patience. A working version of the program(s) will not be available until late
in the project time span.

c. A major mistake, if undetected until the working program is reviewed, can be disastrous.

6- The Incremental Process Model

There are many situations in which initial software requirements are reasonably well defined, but the
overall scope of the development effort prevents a purely linear process. In addition, there may be a
compelling need to provide a limited set of software functionality to users quickly and then refine and
expand that functionality in later software releases. In such cases, you can choose a process that
produces the software in increments.

The Incremental Process can use waterfall model in an iterative manner. It focuses on the delivery of an
operational product with each increment: the development and delivery is broken down into
increments, with each increment adding a part of required functionality

User requirements are prioritised, and the highest priority requirements are included in early
increments. Once the development of increment is started the requirements are frozen though
requirements for later increments can continue to evolve.

Early increments are simplified versions of the final product, but they are valuable to the business and
provide a platform for evaluation by the user.

As a result of use and/or evaluation of an increment, a plan is developed for the next increment. The
plan addresses the modification of the product to better meet the needs of the customer and the
delivery of additional features. This process is repeated until the complete product is produced.

7- Benefits of the incremental model:

a. Customer needs can be addressed with each system increment and most useful functionality is
available earlier.

b. Low risk of overall project failure.

c. The highest Priority system services tend to receive most system testing.

d. Incremental development is particularly useful when staffing is unavailable until the end of the
project.

e. Early increments can be implemented with fewer people. If the core product is well received, then
additional staff can be added to implement the next increments.

f. Increments can be planned to manage technical risks. For example, a major system might require
the availability of new hardware that is under development and whose delivery date is uncertain. It
might be possible to plan early increments in a way that avoids the use of this hardware, thereby
enabling partial functionality to be delivered to end users without inordinate delay.

g. The cost of accommodating changing customer requirements is reduced.

h. The amount of analysis and documentation that has to be redone is much less than is required with
the waterfall model.

i. It is easier to get customer feedback on the development work that has been done.

j. Customers can comment on demonstrations of the software and see how much has been
implemented.

8- Drawbacks of the incremental model:

a. The process is not visible: Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect every version of the system.

b. System structure tends to degrade as new increments are added: Unless time and money is spent on
refactoring to improve the software, regular change tends to corrupt its structure.

9- Evolutionary Process Models:

Software like all complex systems evolve over time. Business and product requirements often change as
development proceeds -> this makes a straight-line path to an end-product unrealistic; tight market
deadlines make completion of a comprehensive software product impossible.

We need a process model that has been explicitly designed to accommodate a product that meets
competitive or business pressure and evolves over time.

• Evolutionary models are iterative. They are characterized in a manner that enables to develop
increasingly more complete versions of the software in increments.

• They are used when some core system requirements are well understood and additional system
requirements have yet to be defined.

10- Prototyping

Often, a customer defines a set of general objectives for software but doesn’t identify details for the
functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm. In
such cases, the Prototyping approach may be useful.

• Although Prototyping can be used as a stand-alone process, it is more commonly used as a

technique with other processes.

• The Prototype can serve as “the first system”. Some prototypes are built as “Throw away” others
slowly evolve into the actual system.

• Prototyping begins with communication. You meet with other stakeholders to define the overall
objectives for the software, identify known requirements, and outline areas where further definition
is necessary.

• A prototyping iteration is planned quickly, and modelling occurs.

• A quick design focuses on a representation of those aspects of the software that will be visible to
end users (e.g., human interface layout or output display formats).
• The quick design leads to the construction of a prototype. The prototype is deployed and evaluated
by stakeholders, who provide feedback used to further refine requirements.

• Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the
same time enabling you to better understand what needs to be done.

11- Benefits and drawbacks of prototyping:

a. Benefits of Prototyping: Both stakeholders and software engineers benefit from prototyping. Users
get a feel for the actual system, and developers get to build something immediately and improve the
system before deployment.

b. Drawbacks of Prototyping: Stakeholders see what appears to be a working version of the software,
unaware that in the rush to get it working you haven’t considered overall software quality or long-term
maintainability. As a software engineer, you often make 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 some time, you may become comfortable 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.

12- The Spiral model (Evolutionary model)

The Spiral Model couples the iterative nature of prototyping with controlled and systematic aspects of
waterfall. It allows rapid development of increasingly more complete versions of the software.

The Spiral Model is a risk-driven process model. It has two main distinguishing features:

a. One is a cyclic approach for incrementally growing a system’s features while decreasing risks.

b. The other is a set of milestones for ensuring stakeholders commitment to feasible and useful system
solution.
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test
 • A spiral model is divided into a set of activities defined by the software engineering team. Each
of the activities represent one segment of the spiral path illustrated in the previous figure.

• As this process begins, the software team performs activities that are implied by a circuit around
the spiral in a clockwise direction, beginning at the center.

• Risk is considered as each revolution is made.

• Anchor point milestones are a combination of work products and conditions that are attained
along the path of the spiral.

• The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software.

• Each pass through the planning region results in adjustments to the project plan. Cost and
schedule are adjusted based on feedback derived from the customer’s feedback after delivery.
In addition, the project manager adjusts the planned number of iterations required to complete
the software.

• Unlike other process models that end when the software is delivered, the spiral model can be
adapted to apply throughout the life of the software.

• The spiral model is a realistic approach to the development of large-scale systems and software.
Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.

• The spiral model uses prototyping as a risk reduction mechanism.

• It uses the systematic stepwise approach suggested by the classic life cycle but incorporates it
into an iterative framework that more realistically reflects the real world.

13- Component-based development (approach based on software reuse)

Based on software reuse where systems are integrated from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf systems).

Reused elements may be configured to adapt their behaviour and functionality to user’s requirements.

Reuse is now the standard approach for building many types of business systems (ex: web stores, blogs).

• The best process to apply when reuse is a development objective.

• We can reuse components that are already made or we can make components that may be
reused.

• Used by vendors who offer the products that provide targeted functionality with well-defined
interfaces that enable the component to be integrated into the software to build.

• Modelling and construction activities begin with the identification of candidate components.
These components can be designed as either conventional software modules or object-oriented
classes or packages of classes.
 • Reusability provides software engineers with a number of measurable benefits including a
reduction in development cycle time and a reduction in project cost.

14- Key process stages (of component-based development)

a. Requirements specification: Identify the functional requirements.

b. Software discovery and evaluation: Available component-based products are researched and
evaluated for the application domain in question.

c. Requirements refinement: Refine requirements according to available features in the reused

component.

d. A software architecture is designed to accommodate the components.

e. Application system configuration

f. Component adaptation and integration: Components are integrated into the architecture.

g. Comprehensive testing is conducted to ensure proper functionality.

15- Advantages and disadvantages

a. + Reduced costs and risks as less software is developed from scratch

b. + Faster delivery and deployment of system
c. - But requirements compromises are inevitable so system may not meet real needs of users
d. - Loss of control over evolution of reused system elements

16- Types of reusable software

a. Stand-alone application systems that are configured for use in a particular environment.

b. Collections of objects that are developed as a framework such as .NET or JEE.

c. Web services that are developed according to service standards and which are available for remote
invocation.
PART II : Process activities:
1- The Requirements Engineering Process (The software specification):

It is the process of establishing what services are required and the constraints on the system’s
operation and development.

The Requirements engineering process:

a. Feasibility study: Estimate whether it is feasible develop of the software.

b. Requirements elicitation and analysis: What do the system stakeholders require from the
system?
c. Requirements specification: Define the requirements in detail.
d. Requirements validation: Checking the validity of the requirements.

2- Software Design and Implementation

The process of converting the system specification into an executable system.

a. Software design: Design a software structure that realises the specification;

b. Implementation: Translate this structure into an executable program;

The activities of design and implementation are closely related and may be inter-leaved.

Design activities:

a. Architectural design, where you identify the overall structure of the system, the principal components
(subsystems or modules), their relationships and how they are distributed.

b. Database design, where you design the system data structures and how these are to be represented
in a database.

c. Interface design, where you define the interfaces between system components.
d. Component selection and design, where you search for reusable components. If unavailable, you
design how it will operate.

System implementation:

The software is implemented either by developing programs or by configuring an application system.

Programming is an individual activity with no standard process.

Debugging is the activity of finding program faults and correcting these faults.

3- Software validation

Verification and validation (V & V) is intended to show that a system conforms to its specification and
meets the requirements of the system customer.

Involves checking and review processes and system testing.

System testing involves executing the system with test cases that are derived from the specification of
the real data to be processed by the system.

Testing is the most commonly used V & V activity.

Stages of testing

a. Component testing: Individual components are tested independently. Components may be functions
or objects or coherent groupings of these entities.

b. System testing: Testing of the system as a whole. Testing of emergent properties is particularly
important.

c. Customer/acceptance testing: Testing with customer data to check that the system meets the
customer’s needs.

4- Software evolution

As requirements change through changing business circumstances, the software that supports the
business must also evolve and change.