Lecture 2

Software Development
Life Cycle
MAIN CONTENT

 Lifecycle & process models

 Agile methods
 Software project management
 Software product lines
Software Development Lifecycle

 Development of a program forms part of a

natural lifecycle. New solutions are designed
due to:
o A system failing
o Users needs change over time
Software Development Lifecycle

Feasibility Study

Requirements
Analysis

Design Design may

change if
application
Code Development does not
work as
expected
Testing

Deployment/
Implementation

Maintenance
Software Development Lifecycle
Determine the
scope of the
problem

Review and Gathering

maintain requirements

Writing the
Writing specification
documentation

Testing Designing a
solution

Coding the
design
Stage 1 – Determine the scope of the problem

 What are the boundaries of the problem?

(Scope).
 It is important to note what is and also what
is not covered by the program, and who is
affected by it.
 Understanding all of these elements combined
help understand the nature of the program.
Stage 2 – Gather requirements

 What is wanted from the program off your

stakeholders, so that it can specify what the
program is going to do (looking at the function
requirements)
 A high number of commercial solutions fail
because not enough research is done in this stage.
 They are often collected describing individually
how each task is going to be achieved.
Stage 3 – Writing the specification

 Make a list of all the elements which cover:

o Inputs and outputs
o Processing
o Storage
o User interface
o Constraints
Stage 4: Designing the solution

 Solution is built using suitable design tools (it

shows a set of procedures)(pseudocode and
flow diagrams)
 Can be paper or electronic
 Without correct planning and design a lot of
time is wasted from mistakes made!
Stage 5 & 6 – coding & testing

 Convert the design into code. It is important

that stage 6 is mostly done simultaneously by the
program being tested in smaller sections the same
way as each broken down element is coded.
 Testing is vital. Two main methods for testing
are the black box and white box testing
methods….
Stage 6 – Testing (Continued)

White Box Testing

Black Box testing
Examines the performance of the code
AFTER the functionality is working
Does it meet the list of its functional
requirements? Is there a better way to do the task?
Does it do what it is supposed to do? Does it allow for flexibility?
Is it robust?
e.g. Area = height * width Is the use of language clear for the end
user?
Is the solution displayed in a logical
order?

ALL Boundaries should be tested thoroughly….

Stage 7 – Writing Documentation

 There are 3 types of documentation:

o Internal documentation
o Technical documentation
o User documentation
Internal Documentation

 Use correct naming conventions especially

when naming your variables
 Good use of comments, describing the purpose
of the bits of code
 Use a tidy layout, complete with indentation
and blocking correctly
Technical Documentation
 Written by developers for other developers to read
 Often uses jargon and programming terminology, but it must also
be backed up with a clear and concise explanation!
 Should cover:
o Requirements
o Design
o Flow charts
o DFD
o Data type list
o Testing
o Corrective actions for errors
o Copy of documented code
o Recommendations for future improvements/enhancements
User documentation
 Technical terms and jargon are avoided!
 Installation
 How to use the program
 Troubleshooting
 Help
 Examples of program working

This can be paper format, text files or

screencast/video animations.
Stage 8 - Review and Maintain

 Reviewing is reflective by comparing this to the

original stakeholder requirements – does it do
what you want it to do, how well does it work?
 Maintenance is ongoing, fixing minor errors as
they occur and making small adjustments as you
feel they are necessary, adding extra features
and extra functionality
Software lifecycle models

Describe an overall distribution of the software

construction into tasks, and the ordering of these tasks

They are models in 2 ways:

 Provide an abstracted version of reality

 Describe an ideal scheme, not always
followed in practice
Lifecycle: the waterfall model

Feasibility
study

Requirements

Specification

Global
Succession of steps, with possibility design

at each step to question and update Detailed

design

the results of the preceding step Implemen-

tation

V&V

Distribution

V&V: Verification & Validation

A V-shaped variant

FEASIBILITY STUDY DISTRIBUTION

SYSTEM
REQUIREMENTS VALIDATION
ANALYSIS

SUBSYSTEM
GLOBAL DESIGN VALIDATION

UNIT
DETAILED DESIGN VALIDATION

IMPLEMENTATION
Problems with the waterfall
 Late appearance of actual code. Feasibility
study
 Lack of support for
Requirements
requirements change — and more
generally for extendibility and Specification

reusability Global
design
 Lack of support for the
Detailed
maintenance activity (70% of design

software costs?) Implemen-

tation
 Division of labor hampering Total
V&V
Quality Management

 Impedance mismatches Distribution

 Highly synchronous model

Lifecycle: “impedance mismatches”

As Management requested it As the Project Leader defined it As Systems designed it

As
Programming
developed it
As Operations installed it What the user wanted
A modern variant
The Spiral model (Boehm)

Apply a waterfall-like approach to successive prototypes

Iteration 3

Iteration 1

Iteration 2
The Spiral model
“Prototyping” in software

The term is used in one of the following meanings:

1. Experimentation:
•Requirements capture

•Try specific techniques: GUI, implementation (buying information)

2. Pilot project

3. Incremental development

4. Throw-away development
The problem with throw-away development

o Software development is hard because of the need

to reconcile conflicting criteria, e.g. portability
and efficiency
o A prototype typically sacrifices some of these
criteria Risk of shipping the prototype
Seamless, incremental development

 Seamless development:
 Single set of notation, tools, concepts,
principles throughout
 Continuous, incremental development
 Keep model, implementation and
documentation consistent
 Reversibility: can go back and forth
Seamless development
Example classes:

PLANE, ACCOUNT,
 Single notation, tools, Analysis TRANSACTION…

STATE,
concepts, principles Design COMMAND…

 Continuous, incremental Implemen- HASH_TABLE…

development tation

 Keep model, implementation V&V

TEST_DRIVER…

and documentation consistent

Generali-
TABLE…
 Reversibility: go back and zation

forth
Generalization A D I V G

Prepare for reuse. For example: A*

 Remove built-in limits
 Remove dependencies on
specifics of project
 Improve documentation, B
contracts...
 Abstract
X
 Extract commonalities and
revamp inheritance
hierarchy

Y Z
Few companies have the guts to
provide the budget for this
Reversibility

Analysis

Design

Implemen-
tation

V&V

Generali-
zation
AGILE METHOD
Agile Software Development

Agile software development is a conceptual framework for

software engineering that promotes development iterations
throughout the life-cycle of the project.

Software developed during one unit of time is referred to

as an iteration, which may last from one to four weeks.

Agile methods also emphasize working software as the

primary measure of progress
Agile Software Development
Characteristics of Agile Software Development

o Light Weighted methodology

o Small to medium sized teams
o vague and/or changing requirements
o vague and/or changing techniques
o Simple design
o Minimal system into production
Characteristics of Agile Software Development

o Modularity

o Iterative

o Time-bound

o Incremental

o Convergent

o People-oriented

o Collaborative
Existing Agile Methods

o Extreme Programming

o Agile Unified Process

o Scrum
Extreme Programming (XP)

o Most prominent Agile Software development method

o Prescribes a set of daily stakeholder practices

o “Extreme” levels of practicing leads to more

responsive software.

o Changes are more realistic, natural, inescapable.

XP
Agile Unified Process (AUP)

o AUP is a simplified version of RUP

o Phases of AUP

 Inception
 Elaboration
 Construction
 Transition
Disciplines of AUP
o Model

o Implementation

o Test

o Deployment

o Configuration Management

o Project Management

o Environment
Scrum
o It is an Agile Software development method for
project management

o Characteristics:
 Prioritized work is done
 Completion of backlog items
 Progress is explained
 Agile Software Development
Scrum
 SOFTWARE
PROJECT MANAGEMENT
Software Project Management
o Software project management is perhaps the most
important factor in the outcome of a project

o Processes for the various aspects of project

management should not be looked at in isolation. In a
balanced process, the practices integrate smoothly.

o Processes of an organization should encapsulate its

best practices so as to help new projects replicate
past successes and avoid failures.
Software Project Management
o At the top level, the project management process
consists of three phases: planning, execution, and
closure.

o For effective execution of projects, project managers

should be supported through the help of an SEPG in
executing processes; senior management monitoring
and issue resolution; and good training.

o Many key process areas at all maturity levels of the

CMM (Capability Maturity Model) for software focus
directly on project management.
Context Diagram
 SOFTWARE
PRODUCT LINES
Software product lines
Software product lines or application families are
applications with generic functionality that can be
adapted and configured for use in a specific context.

A software product line is a set of applications with a

common architecture and shared components, with each
application specialized to reflect different requirements.

Adaptation may involve:

Component and system configuration;

Adding new components to the system;

Selecting from a library of existing components;

Modifying components to meet new requirements.

Base systems for a software product line
Base applications
Core components that provide infrastructure support.
These are not usually modified when developing a new
instance of the product line.

Configurable components that may be modified and

configured to specialize them to a new application.
Sometimes, it is possible to reconfigure these components
without changing their code by using a built-in component
configuration language.

Specialized, domain-specific components some or all of

which may be replaced when a new instance of a product line
is created.
Application frameworks and product lines
Application frameworks rely on object-oriented features
such as polymorphism to implement extensions. Product
lines need not be object-oriented (e.g. embedded software
for a mobile phone)

Application frameworks focus on providing technical

rather than domain-specific support. Product lines embed
domain and platform information.

Product lines often control applications for equipment.

Software product lines are made up of a family of

applications, usually owned by the same organization.
Product line architectures

Architectures must be structured in such a way to

separate different sub-systems and to allow them to be
modified.

The architecture should also separate entities and their

descriptions and the higher levels in the system access
entities through descriptions rather than directly.
The architecture of a resource allocation system
The product line architecture of a vehicle dispatcher
Vehicle dispatching
A specialised resource management system where the aim is
to allocate resources (vehicles) to handle incidents.

Adaptations include:

At the UI level, there are components for operator display and
communications;

At the I/O management level, there are components that handle
authentication, reporting and route planning;

At the resource management level, there are components for

vehicle location and despatch, managing vehicle status and incident
logging;

The database includes equipment, vehicle and map databases.

Product line specialisation
Platform specialization

Different versions of the application are developed for different

platforms.

Environment specialization

Different versions of the application are created to handle different

operating environments e.g. different types of communication
equipment.

Functional specialization

Different versions of the application are created for customers with

different requirements.

Process specialization

Different versions of the application are created to support

different business processes.
Product instance development
Product instance development
Elicit stakeholder requirements

Use existing family member as a prototype

Choose closest-fit family member

Find the family member that best meets the requirements

Re-negotiate requirements

Adapt requirements as necessary to capabilities of the

software

Adapt existing system

Develop new modules and make changes for family member

Deliver new family member

Document key features for further member development

Product line configuration

Design time configuration

The organization that is developing the software modifies a
common product line core by developing, selecting or adapting
components to create a new system for a customer.

Deployment time configuration

A generic system is designed for configuration by a customer
or consultants working with the customer. Knowledge of the
customer’s specific requirements and the system’s operating
environment is embedded in configuration data that are used by
the generic system.
Deployment-time configuration
 THANK YOU
FOR LISTENING !