Edward Hasted. (2005).

Software That Sells : A Practical Guide to Developing and

Marketing Your Software Project.

John W. Horch (2005). "Two Orientations On How To Work With Objects." In: IEEE
Software. vol. 12, no. 2, pp. 117-118, Mar., 1995.

Karl E. Wiegers (2005). More About Software Requirements: Thorny Issues and
Practical Advice.

Robert K. Wysocki (2006). Effective Software Project Management.

Unit 2:Software Development Life Cycle Model

1.0 Introduction

35
The last unit exposed you to the overview of software development. In this unit you
will learn about the various lifecycle models (the phases of the software life cycle) in
general. You will also specifically learn about the requirement and the design phases

2.0 Objectives

By the end of this unit, you should be able to:

 Define software life cycle model
 Explain the general model
 Explain Waterfall Model
 Explain V-Shaped Life Cycle Model
 Explain Incremental Model
 Explain Spiral Model
 Discus the requirement and design phases

3.0 Definition of Life Cycle Model

Software life cycle models describe phases of the software cycle and the order in which
those phases are executed. There are a lot of models, and many companies adopt their
own, but all have very similar patterns. According to Raymond Lewallen (2005), the general,
basic model is shown below:

3.1 The General Model

General Life Cycle Model

Fig 1 the General Model

Source: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx.

Each phase produces deliverables needed by the next phase in the life cycle.
Requirements are converted into design. Code is generated during implementation that is
driven by the design. Testing verifies the deliverable of the implementation phase against
requirements.

3.2 Waterfall Model

This is the most common life cycle models, also referred to as a linear-sequential life
cycle model. It is very simple to understand and use. In a waterfall model, each phase
must be completed before the next phase can begin. At the end of each phase, there is

36
always a review to ascertain if the project is in the right direction and whether or not to
carry on or abandon the project. Unlike the general model, phases do not overlap in a
waterfall model.

Waterfall Life Cycle

Fig 2 Waterfall Life Cycle

Source: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx.

3.2.1 Advantages

 Simple and easy to use.

 Easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.

3.2.2 Disadvantages

 Adjusting scope during the life cycle can kill a project

 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Poor model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Poor model where requirements are at a moderate to high risk of changing.

3.3 V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of
processes. Each phase must be completed before the next phase begins. Testing is
emphasized in this model more so than the waterfall model The testing procedures are

37
developed early in the life cycle before any coding is done, during each of the phases
preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before
development is started, a system test plan is created. The test plan focuses on meeting the
functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration
test plan is created in this phase as well in order to test the pieces of the software systems
ability to work together.

The low-level design phase is where the actual software components are designed, and
unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test plans
developed earlier are now put to use.

Fig 3 V-Shaped Life Cycle Model

Source: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx.

3.3.1 Advantages

38
  Simple and easy to use.
 Each phase has specific deliverables.
 Higher chance of success over the waterfall model due to the development of test
plans early on during the life cycle.
 Works well for small projects where requirements are easily understood.

3.3.2 Disadvantages

 Very rigid, like the waterfall model.

 Little flexibility and adjusting scope is difficult and expensive.
 Software is developed during the implementation phase, so no early prototypes of
the software are produced.
 Model doesn‘t provide a clear path for problems discovered during testing phases.

3.4 Incremental Model

The incremental model is an intuitive approach to the waterfall model. It is a kind of a

―multi-waterfall‖ cycle. In that multiple development cycles take at this point. Cycles are
broken into smaller, more easily managed iterations. Each of the iterations goes through
the requirements, design, implementation and testing phases.

The first iteration produces a working version of software and this makes possible to have
working software early on during the software life cycle. Subsequent iterations build on
the initial software produced during the first iteration.

Incremental Life Cycle Model

Fig 4 Incremental Life Cycle Model

Source: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx.

3.4.1 Advantages

 Generates working software quickly and early during the software life cycle.

39
  More flexible – inexpensive to change scope and requirements.
 Easier to test and debug during a smaller iteration.
 Easier to manage risk because risky pieces are identified and handled during its
iteration.
 Each of the iterations is an easily managed landmark

3.4.2 Disadvantages

 Each phase of an iteration is rigid and do not overlap each other.

 Problems as regard to system architecture may arise as a result of inability to
gathered requirements up front for the entire software life cycle.

3.5 Spiral Model

The spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases namely Planning, Risk Analysis, Engineering
and Evaluation. A software project continually goes through these phases in iterations
which are called spirals. In the baseline spiral requirements are gathered and risk is
assessed. Each subsequent spiral builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a
process is carried out to discover risk and alternate solutions. A prototype is produced at
the end of the risk analysis phase.

Software is produced in the engineering phase, alongside with testing at the end of the
phase. The evaluation phase provides the customer with opportunity to evaluate the
output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component denotes progress, and the radius of the spiral
denotes cost.

Spiral Life Cycle Model

40
Fig 5 Spiral Life Cycle Model

Source: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx.

3.5.1 Merits

 High amount of risk analysis

 Good for large and mission-critical projects.
 Software is produced early in the software life cycle.

3.5.2 Demerits

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project‘s success is highly dependent on the risk analysis phase.
 Doesn‘t work well for smaller projects.

3.6 Requirements Phase

41
Business requirements are gathered in this phase. This phase is the main center of
attention of the project managers and stake holders. Meetings with managers, stake
holders and users are held in order to determine the requirements. Th general questions
that require answers during a requirements gathering phase are: Who is going to use the
system? How will they use the system? What data should be input into the system?
What data should be output by the system? A list of functionality that the system should
provide, which describes functions the system should perform, business logic that
processes data, what data is stored and used by the system, and how the user interface
should work is produced at this point. The requirements development phase may have
been preceded by a feasibility study, or a conceptual analysis phase of the project. The
requirements phase may be divided into requirements elicitation (gathering the
requirements from stakeholders), analysis (checking for consistency and completeness),
specification (documenting the requirements) and validation (making sure the specified
requirements are correct)

In systems engineering, a requirement can be a description of what a system must do,

referred to as a Functional Requirement. This type of requirement specifies something
that the delivered system must be able to do. Another type of requirement specifies
something about the system itself, and how well it performs its functions. Such
requirements are often called Non-functional requirements, or 'performance requirements'
or 'quality of service requirements.' Examples of such requirements include usability,
availability, reliability, supportability, testability, maintainability, and (if defined in a way
that's verifiably measurable and unambiguous) ease-of-use.

3.6.1 Types of Requirements

Requirements are categorised as:

 Functional requirements which describe the functionality that the system is to

execute; for example, formatting some text or modulating a signal.
 Non-functional requirements which are the ones that act to constrain the solution.
Nonfunctional requirements are sometimes known as quality requirements or
Constraint requirements No matter how the problem is solved the constraint
requirements must be adhered to.

It is important to note that functional requirements can be directly implemented in

software. The non-functional requirements are controlled by other aspects of the system.
For example, in a computer system reliability is related to hardware failure rates,
performance controlled by CPU and memory. Non-functional requirements can in some
cases be broken into functional requirements for software. For example, a system level
non-functional safety requirement can be decomposed into one or more functional
requirements. In addition, a non-functional requirement may be converted into a process
requirement when the requirement is not easily measurable. For example, a system level

42
maintainability requirement may be decomposed into restrictions on software constructs
or limits on lines or code.

3.6.2 Requirements analysis

Requirements analysis in systems engineering and software engineering, consist of

those activities that go into determining the needs or conditions to meet for a new or
altered product, taking account of the possibly conflicting requirements of the various
stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements

must be actionable, measurable, testable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system design.

3.6.3 The Need for Requirements Analysis

Studies reveal that insufficient attention to Software Requirements Analysis at the
beginning of a project is the major reason for critically weak projects that often do not
fulfil basic tasks for which they were designed. Software companies are now spending
time and resources on effective and streamlined Software Requirements Analysis
Processes as a condition to successful projects that support the customer‘s business goals
and meet the project‘s requirement specifications.
3.6.4 Requirements Analysis Process: Requirements Elicitation, Analysis And
Specification
Requirements Analysis is the process of understanding the client needs and expectations
from a proposed system or application. It is a well-defined stage in the Software
Development Life Cycle model.
Requirements are a description of how a system should behave, in other words, a
description of system properties or attributes. Considering the numerous levels of
dealings between users, business processes and devices in worldwide corporations today,
there are immediate and composite requirements from a single application, from different
levels within an organization and outside it
The Software Requirements Analysis Process involves the complex task of eliciting and
documenting the requirements of all customers, modelling and analyzing these
requirements and documenting them as a foundation for system design.
This job (requirements analysis process) is dedicated to a specialized Requirements
Analyst. The Requirements Analysis function may also come under the scope of Project
Manager, Program Manager or Business Analyst, depending on the organizational
hierarchy.

3.6.5 Steps in the Requirements Analysis Process

43
3.6.5.1 Fix system boundaries
This is initial step and helps in identifying how the new application fit in into the business
processes, how it fits into the larger picture as well as its capacity and limitations.
3.6.5.2 Identify the customer
This focuses on identifying who the ‗users‘ or ‗customers‘ of an application are that is to
say knowing the group or groups of people who will be directly or indirectly impacted by
the new application. This allows the Requirements Analyst to know in advance where he
has to look for answers.

3.6.5.3 Requirements elicitation

Here information is gathered from the multiple stakeholders identified. The Requirements
Analyst brings out from each of these groups what their requirements from the
application are and what they expect the application to achieve. Taking into account the
multiple stakeholders involved, the list of requirements gathered in this manner could go
into pages. The level of detail of the requirements list depends on the number and size of
user groups, the degree of complexity of business processes and the size of the
application.

3.6.5.3.1 Problems faced in Requirements Elicitation

 Ambiguous understanding of processes
 Inconsistency within a single process by multiple users
 Insufficient input from stakeholders
 Conflicting stakeholder interests
 Changes in requirements after project has begun
3.6.5.3.2 Tools used in Requirements Elicitation
Tools used in Requirements Elicitation include stakeholder interviews and focus group
studies. Other methods like flowcharting of business processes and the use of existing
documentation like user manuals, organizational charts, process models and systems or
process specifications, on-site analysis, interviews with end-users, market research and
competitor analysis are also used widely in Requirements Elicitation.
There are of course, modern tools that are better equipped to handle the complex and
multilayered process of Requirements Elicitation. Some of the current Requirements
Elicitation tools in use are:
 Prototypes
 Use cases
 Data flow diagrams
 Transition process diagrams

44
 User interfaces

3.6.5.4 Requirements Analysis

The moment all stakeholder requirements have been gathered, a structured analysis of
these can be done after modeling the requirements. Some of the Software Requirements
Analysis techniques used are requirements animation, automated reasoning, knowledge-
based critiquing, consistency checking, analogical and case-based reasoning.
3.6.5.5. Requirements Specification
After requirements have been elicited, modeled and analyzed, they should be
documented in clear, definite terms. A written requirements document is crucial and as
such its circulation should be among all stakeholders including the client, user-groups,
the development and testing teams. It has been observed that a well-designed, clearly
documented Requirements Specification is vital and serves as a:
 Base for validating the stated requirements and resolving stakeholder conflicts, if any
 Contract between the client and development team
 Basis for systems design for the development team
 Bench-mark for project managers for planning project development lifecycle and
goals
 Source for formulating test plans for QA and testing teams
 Resource for requirements management and requirements tracing
 Basis for evolving requirements over the project life span
Software requirements specification involves scoping the requirements so that it meets
the customer‘s vision. It is the result of teamwork between the end-user who is usually
not a technical expert, and a Technical/Systems Analyst, who is expected to approach the
situation in technical terms.
The software requirements specification is a document that lists out stakeholders‘ needs
and communicates these to the technical community that will design and build the
system. It is really a challenge to communicate a well-written requirements specification,
to both these groups and all the sub-groups within. To overcome this, Requirements
Specifications may be documented separately as:
 User Requirements - written in clear, precise language with plain text and use cases,
for the benefit of the customer and end-user
 System Requirements - expressed as a programming or mathematical model, meant
to address the Application Development Team and QA and Testing Team.
Requirements Specification serves as a starting point for software, hardware and database
design. It describes the function (Functional and Non-Functional specifications) of the
system, performance of the system and the operational and user-interface constraints that
will govern system development.

45
3.7 Requirements Management
Requirements Management is the all-inclusive process that includes all aspects of
software requirements analysis and as well ensures verification, validation and
traceability of requirements. Effective requirements management practices assure that all
system requirements are stated unmistakably, that omissions and errors are corrected and
that evolving specifications can be included later in the project lifecycle.

3.7 Design Phase

The software system design is formed from the results of the requirements phase. This is
where the details on how the system will work are produced. Deliverables in this phase
include hardware and software, communication, software design.

3.8 Definition of software design

A software design is a meaningful engineering representation of some software product

that is to be built. A design can be traced to the customer's requirements and can be
assessed for quality against predefined criteria. In the software engineering context,
design focuses on four major areas of concern: data, architecture, interfaces and
components.

The design process is very important. As a labourer, for example one would not attempt
to build a house without an approved blueprint so as not to risk the structural integrity
and customer satisfaction. In the same way, the approach to building software products is
no unlike. The emphasis in design is on quality. It is pertinent to note that, this is the only
phase in which the customer‘s requirements can be precisely translated into a finished
software product or system. As such, software design serves as the foundation for all
software engineering steps that follow regardless of which process model is being
employed.

During the design process the software specifications are changed into design models that
express the details of the data structures, system architecture, interface, and components.
Each design product is re-examined for quality before moving to the next phase of
software development. At the end of the design process a design specification document
is produced. This document is composed of the design models that describe the data,
architecture, interfaces and components.

3.9 Design Specification Models

 Data design – created by changing the analysis information model (data

dictionary and ERD) into data structures needed to implement the software. Part
of the data design may occur in combination with the design of software
architecture. More detailed data design occurs as each software component is
designed.

46
  Architectural design - defines the relationships among the major structural
elements of the software, the ―design patterns‖ that can be used to attain the
requirements that have been defined for the system, and the constraint that affect
the way in which the architectural patterns can be applied. It is derived from the
system specification, the analysis model, and the subsystem interactions defined
in the analysis model (DFD).
 Interface design - explains how the software elements communicate with each
other, with other systems, and with human users. Much of the necessary
information required is provided by the e data flow and control flow diagrams.
 Component-level design – It converts the structural elements defined by the
software architecture into procedural descriptions of software components using
information acquired from the process specification (PSPEC), control
specification (CSPEC), and state transition diagram (STD).

3.10 Design Guidelines

In order to assess the quality of a design (representation) the yardstick for a good design
should be established. Such a design should:

 exhibit good architectural structure

 be modular
 contain distinct representations of data, architecture, interfaces, and components
(modules)
 lead to data structures that are appropriate for the objects to be implemented and
be drawn from recognizable design patterns
 lead to components that exhibit independent functional characteristics
 lead to interfaces that reduce the complexity of connections between modules and
with the external environment
 be derived using a reputable method that is driven by information obtained during
software requirements analysis

These criteria are not acquired by chance. The software design process promotes good
design through the application of fundamental design principles, systematic methodology
and through review.

3.11 Design Principles

Software design can be seen as both a process and a model.

―The design process is a series of steps that allow the designer to describe all aspects of
the software to be built. However, it is not merely a recipe book; for a competent and
successful design, the designer must use creative skill, past experience, a sense of what
makes ―good‖ software, and have a commitment to quality.

47
The set of principles which has been established to help the software engineer in directing
the design process are:

 The design process should not suffer from tunnel vision – Alternative
approaches should be considered by a good designer. Designer should judge
each approach based on the requirements of the problem, the resources
available to do the job and any other constraints.
 The design should be traceable to the analysis model – because a single
element of the design model often traces to multiple requirements, it is
necessary to have a means of tracking how the requirements have been
satisfied by the model
 The design should not reinvent the wheel – Systems are constructed using a
suite of design patterns, many of which may have likely been encountered
before. These patterns should always be chosen as an alternative to
reinvention. Design time should be spent in expressing truly fresh ideas and
incorporating those patterns that already exist.
 The design should reduce intellectual distance between the software and the
problem as it exists in the real world – This means that, the structure of the
software design should imitate the structure of the problem domain.
 The design should show uniformity and integration – a design is uniform if it
appears that one person developed the whole thing. Rules of style and format
should be defined for a design team before design work begins. A design is
integrated if care is taken in defining interfaces between design components.
 The design should be structured to degrade gently, even with bad data, events,
or operating conditions are encountered – Well-designed software should
never ―bomb‖. It should be designed to accommodate unusual circumstances,
and if it must terminate processing, do so in a graceful manner.
 The design should be reviewed to minimize conceptual (semantic) errors –
there is sometimes the tendency to focus on minute details when the design is
reviewed, missing the forest for the trees. The designer team should ensure
that major conceptual elements of the design have been addressed before
worrying about the syntax if the design model.
 Design is not coding, coding is not design – Even when detailed designs are
created for program components, the level of abstraction of the design model
is higher than source code. The only design decisions made of the coding level
address the small implementation details that enable the procedural design to
be coded.
 The design should be structured to accommodate change
 The design should be assessed for quality as it is being created

With proper application of design principles, the design displays both external and
internal quality factors. External quality factors are those factors that can readily be
observed by the user, (e.g. speed, reliability, correctness, usability). Internal quality
factors have to do with technical quality more so the quality of the design itself. To
achieve internal quality factors the designer must understand basic design concepts.

48
3.12 Fundamental Software Design Concepts

Over the past four decades, a set of fundamental software design concepts has evolved,
each providing the software designer with a foundation from which more sophisticated
design methods can be applied. Each concept assists the soft ware engineer to answer the
following questions:

 What criteria can be used to partition software into individual components?

 How is function or data structure detail separated from a conceptual

representation of software?

 Are there uniform criteria that define the technical quality of a software
design?

The fundamental design concepts are:

 Abstraction - allows designers to focus on solving a problem without being

concerned about irrelevant lower level details (procedural abstraction - named
sequence of events, data abstraction - named collection of data objects)
 Refinement - process of elaboration where the designer provides successively
more detail for each design component
 Modularity - the degree to which software can be understood by examining its
components independently of one another
 Software architecture - overall structure of the software components and the
ways in which that structure provides conceptual integrity for a system
 Control hierarchy or program structure - represents the module organization
and implies a control hierarchy, but does not represent the procedural aspects of
the software (e.g. event sequences)
 Structural partitioning - horizontal partitioning defines three partitions (input,
data transformations, and output); vertical partitioning (factoring) distributes
control in a top-down manner (control decisions in top level modules and
processing work in the lower level modules).
 Data structure - representation of the logical relationship among individual data
elements (requires at least as much attention as algorithm design)
 Software procedure - precise specification of processing (event sequences,
decision points, repetitive operations, data organization/structure)
 Information hiding - information (data and procedure) contained within a
module is inaccessible to modules that have no need for such information

Activity G 1 What are the steps in requirement Analysis process?

2 What are the fundamental design concepts ?

49
4.0 Conclusion
Software life cycle models describe phases of the software cycle and the order in which
those phases are executed.

5.0 Summary

In this unit, we have learnt that:

 Software life cycle models describe phases of the software cycle and the order
in which those phases are executed. .
 In general model, each phase produces deliverables required by the next phase
in the life cycle. Requirements are translated into design. Code is produced
during implementation that is driven by the design. Testing verifies the
deliverable of the implementation phase against requirements.
 In a waterfall model, each phase must be completed in its entirety before the
next phase can begin. At the end of each phase, a review takes place to
determine if the project is on the right path and whether or not to continue or
discard the project. Unlike what I mentioned in the general model, phases do
not overlap in a waterfall model.
 Just like the waterfall model, the V-Shaped life cycle is a sequential path of
execution of processes. Each phase must be completed before the next phase
begins. Testing is emphasized in this model more so than the waterfall model
though. The testing procedures are developed early in the life cycle before
any coding is done, during each of the phases preceding implementation.
 The incremental model is an intuitive approach to the waterfall model.
Multiple development cycles take place here, making the life cycle a ―multi-
waterfall‖ cycle. Cycles are divided up into smaller, more easily managed
iterations. Each iteration passes through the requirements, design,
implementation and testing phases.
 The spiral model is similar to the incremental model, with more emphases
placed on risk analysis. The spiral model has four phases: Planning, Risk
Analysis, Engineering and Evaluation. A software project repeatedly passes
through these phases in iterations (called Spirals in this model). The baseline
spirals, starting in the planning phase, requirements are gathered and risk is
assessed. Each subsequent spirals builds on the baseline spiral.
 In requirement phase business requirements are gathered and that the phase is
the main focus of the project managers and stake holders.
 The software system design is produced from the results of the requirements
phase and it is the phase is where the details on how the system will work is
produced

6.0 Tutor Marked Assignment

50