-1-

SOFTWARE ENGINEERING
What is computer software?
A computer software is a product that software engineers design and build. It is made of
programs that execute with in a computer of any size and architecture, documents that
encompass hard copy and vital forms and data that combines numbers and texts but also
includes representations of pictorials, videos, and audio information.

Software engineering is done by software engineers and virtually everyone in the

industrialized world uses it either directly or indirectly. A root of software engineering
can be traced in less industrialized countries.

Software engineering is important because it affects nearly every aspect of life and has
become pervasive in our commerce, culture and our everyday activities. Like Telephone
networks, mass Medias, banking etc. Computer software is built like you build any
successful product, by applying a process that leads to a higher quality, the result that
meets the needs of people who will use it. This can be achieved by applying the software
engineering approach.

In the view of software engineers, the work product can be taken to be the programs,
documents, and data that are computer software. However, in the view of the user the
work product is the resultant information that somehow makes the user’s world better.
Because of the expectation of the user/client, the engineer must make sure that he/she
does it right.

Evolving role of the software

Software can be viewed as a product and as a vehicle for delivering a product. As a
product, it delivers the computing potential embodied by the computer hardware or
network of computers that are accessibly by local hardware. It may be residing in a
cellular phone, or operates inside a mainframe computer. Software taken to be an
information transformer –producing, managing, acquiring, modifying, displaying or
transmitting information that can be as simple as a single bit or as complex as multi-
media presentation.

As a vehicle, software is used to deliver the product. The computer software acts as the
basis for the control of the computer (operating system), the communication of
information (networks) and creation and control of other programs (software tools and
environments).

Computer software has gone through a number of transformations due to mainly changes
in the hardware. The hardware performances, computer architecture, changes in memory
and storage capacities, input and output options, etc all have called for changes in the
computer based systems.

The one programmer of an earlier era has been replaced by a team of software specialists
each focusing on one part of the technology required to deliver a complex application.
Despite of this new development, the same questions as were asked before are still being
asked.
 Why does it take so long to get the software
 -2-

 Why are development costs so high

 Why can’t we find all the errors before we give the software to our customers
 Why do we continue having difficult in measuring progress as software is being
developed

Characteristics of computer software

To gain full understanding a computer software and software engineering at large, it is
important to understand the characteristics of computer software. Software is logical
rather than physical system elements. Because of this, software has characteristics that
are considerably different than those of the hardware.

1. Software is developed or engineered; it is not manufactured in the classical sense.

Though there are similarities between hardware manufacturing and software
development, the differences are fundamental especially in terms of design,
relationship between the people in the project and the work they do, and approach.

2. Software does not ware out but it does deteriorate

Fig 1. Failure curve for hardware

Infant
Failure rate

Mortality
Wear out

Time
The failure rate for the hardware is high at the beginning due to design or
manufacturing defects. These defects are corrected with time and failure rate declines
to a steady state level which is low for some time. However, with time the hardware
begins to fail due to wear and tear there by raise the failure rate again.

The failure rate of the software takes the idealized curve as shown in fig 2. Because
of the nature of software, there will always be undiscovered defects in the software
designed. These will raise the failure rate at the beginning. Assuming that no new
errors are introduced in the process of correcting the already identified ones, then the
failure rate is expected to fall with time thereby flattening the curve. Since the
software deteriorates, then this scenario may not happen. This then forces the
software failure curve to take the actual curve. Since software needs maintenance, it
will have to be modified/changed with time. As such changes are made; some errors
are expected to be introduced, causing the failure rates to spike. This can go on and
on so long as new changes are requested. Because of this, the minimum failure begins
to raise to the actual curve. Hence, one can say that the software will not suffer
wear/tear challenges but will deteriorate due to changes.
 -3-

Unlike the hardware where a failure of a component can require just a spare part to
fix it, the software has no spare part. A failure in the software introduces an error that
takes the designer back to the process though the design was introduced into machine
executable code, a process that is more complex than that of hardware.

Fig 2 Idealized and actual failure rates for software

Increased failure rate due

to side effects
Chan
ge
Failure rate

Actual curve

Idealized curve

Time

3. Although the industry is moving towards component based assembly, most

software continues to be custom built.
Unlike in the case of the hardware where the components can be ordered off the shelf
after the design has been made since the components are designed according to the
standard, this is not the case with software. In the software industry, this is something
that has just begun on the broader scale. Some reusable subroutine libraries so far
designed have limited domain of applications. The modern reusable components are
focusing on both data and processing that is applied to the data so that engineers can
develop new applications from reusable parts. Examples can be graphics utilize the
reusable components of graphics windows, pull-down menus etc.

Software applications
Software may be applied in any situation for which algorithm has been defined. To
understand the nature of software application one must understand the information
content that is relevant to it and its determinacy i.e predictability and timing of
information. The information content may refer to meaning and form of incoming and
outgoing information.
In general, the following show breadth of potential software applications:
 System software. This is a collection of programs written to service other
programs. Such software may include compilers, editors, file management
utilities, Operating system and drivers.
 Real –time software. These monitors/analyses/controls real world events as they
occur. These may collect and format information from surrounding environment
 -4-

(data gathering component), analyze and transform information as required by the

application (analysis component), controls/outputs information to external
environment (control component). The coordination of all other components to
ensure proper real-time response is done by the monitoring component
 Business software. These are normally single software applications. Discrete
systems like payrolls have evolved into management information systems MIS
software that access one or more large data bases containing business information.
 Engineering and scientific software. These have been characterized by number
crunching algorithms. These may handle astronomy, volcanology, space shuttles
orbital dynamics etc.
 Embedded software. These are embedded in the Read Only Memory and are
used to control products and systems for the consumer and industrial markets.
 Personal computer software. These may include word processing, spreadsheets,
computer graphics, data base management, personal/business financial
applications, ect
 Web-based software. The web-pages retrieved by a browser are software that
incorporates executable instructions like Java and data like hypertext and visual
and audio formats. Hence network becomes massive computer that gives
unlimited software resource to anyone with a modem.
 Artificial intelligence system. The Artificial Intelligence software makes use of
non-numerical algorithm to solve complex problems that are not straightforward
to analyze. Expert systems –Knowledge based systems, pattern recognition
(image and voice), artificial neural networks, game playing fall in this category.

Process of software development

In software development, the road map that the engineer follows is called a software
process. Such roadmap helps the engineer to be timely and have high quality product as it
shows the predictable steps that will have to be followed. It is the responsibility of the
software engineer and managers to adapt the software process to their needs and then
follow it. Additionally, the client has a big role to play in this software process since
consultations between the engineer and client are a must. A well thought through
software process is important because it provides stability, control, and organization to
any activity that can, if left uncontrolled, become quite chaotic.

It should be noted that this process is not exact duplicate of other processes. At a detailed
level, the process that the engineer adopts depends on the software that is being
developed.
A software process can be defined as framework for the tasks that are required to build
high quality software. Whereas the software process defines the approach taken as the
software is being engineered, the software engineering encompasses technologies that
populate the process – technical methods and automated tools.

Software engineering which can be defined as the establishment and use of sound
engineering principles in order to obtain economically a software that is reliable and
works efficiently on real machines can be taken as a baseline definition. This definition
should stimulate the following questions in the mind of an engineer;
 What are these sound engineering principles
 How can we build a reliable software
 -5-

 What is required for one to build a programs that work efficiently on all real
machines
Others have defined software engineering as 1) the application of systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software; that is
the application of engineering to software. 2) the study of approaches as in 1.

The software development process defines a framework for a set of Key Process Areas
that must be established for effective delivery of software engineering technology. These
Key Process Areas form a basis for effective management control of the software project,
and establish the basis for applying technical methods, work products (i.e. Models,
documents, data, reports, forms etc) are produced, milestones are established, quality is
ensured, and change is properly managed.

Software engineering methods provide the technical how to’s for building software.
These methods may include, requirement analysis, design. Program construction, testing
and support. These methods rely on basic principles that govern each area of the
technology.

The software engineering tools provide automated or semi-automated support for the
process and methods. The Computer aided software engineering system for the support of
software development is established when tools are integrated so that information created
by one tool can be used by another.

In general, engineering is taken to be the analysis, design, construction, verification and

management of technical/social entities. Regardless of which entity, the following
questions must be asked and answered by the engineer.
 What is the problem to be solved
 What are the characteristics of the entity that is used to solve the problem
 How will the entity (and solution) be realized
 How will the entity be constructed
 What approach will be used to uncover the errors that were made in the design
and construction of the entity
 How will the entity be supported over the long term, when corrections and
enhancements are requested by the users
The definition phase focus on what. The engineer at this phases focus on what
information is to be processed, what functions are desired, what design constraints exist,
what interface, what validation criteria for a successful system.

The development phase focuses on how. Examples could be how data are to be
structured, how functions are to be implemented, how procedural details are to be
implemented, how interface are to be characterized, how design is to be translated into
programming language, how testing will be performed. Those these methods may vary
from project to project, three things tend to be common; software project design, code
generation, and software testing.

The support phase focuses on change that is associated with error correction, adaptation
required as the software’s environment evolves, and changes due to enhancement due to
changes in customer’s requirements. Four common types of changes are encountered;
 Correction; these will be uncovered by the customer as he tries to use the system
 -6-

 Adaptation; Over time the original environment will change eg CPU, Operating
system, business rules etc for which the software was developed. Hence changes
in the software become a must.
 Enhancement; As the customer uses the product, he realizes additional functions
the software can be put to use profitably. Perfective maintenance extends the
software beyond the original scope/functional requirements.
 Prevention; As already noted, computer software deteriorates due to change,
hence preventative maintenance often called software reengineering must be
conducted to enable the software to serve the needs of its end users. This then
calls on the engineer to make changes in programs in a way that it can be easy to
correct, adapt and enhance.
The above discussed phases can be complemented by the following steps if they are to
come out the way they are expected;
 Software project tracking and controls
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Document preparation and production
 Reusability management
 Measurements
 Risk managements

The software process

A common process framework is established by defining a small number of

framework activities that are applicable to all software projects, regardless of their
size and complexity. The number of task sets i.e. project software engineering tasks,
project milestones, work products, and quality assurance points, all enable the
framework activities to be adapted to the characteristics of the specified project. The
Software Engineering Institute has the following as measures of project process
maturity. It is a model that uses the following 5 grading points to measure the process
maturity of organizations; The following Key Process Areas should be achieved at
each process maturity level shown below. Remember that Key Process Areas are
additive. For example, the maturity level number 3 has the elements of level 2.
Process maturity level 2.

 Level 1: Initial- Under this level, the software process is characterized as ad hoc
and chaotic. Few process are defined and success depends on individual effort.
Under this level, little or no effort is placed on the quality assurance and project
management. The project team will use any method, standards and procedures
they choose which may range from good to worst.

 Level 2: Repeatable – Basic project management processes are established to

track costs, schedules, and functionality. Some process disciplines are in place
and can be repeated n case similar projects are to be developed. On this level, the
developer may have defined activities like reporting of task completion, time and
effort reporting. The Key Process Areas present at this level can be summarized
as thus; 1) Software configuration management 2) Software quality assurance 3)
 -7-

Software subcontract management 4) Software project tracking and oversight 5)

Software project planning and 6) Requirements management.
 Level 3: Defined- The software process for both management and engineering are
developed activities is documented, standardized, and integrated into the
organization-wide software process. Hence all software projects use such
documented and approved version of the organizational process for developing
and supporting software. On this level where most software developers are, some
standards of management and technical may have been developed and enforced.
On this level of maturity, in addition to the Key Process Areas under level 2, the
following are expected to be covered; 1) Peer reviews 2) Inter group coordination
3) Software product engineering 3) Integrated software management 4) Training
program 5) Organization process definition 6) Organization project focus
 Level 4: Managed – Detailed measures of software process and product quality
are collected. On this level, both software process and products are quantitatively
understood and controlled using detailed measures. This level includes all those in
3 with the following Key Process Areas added; 1)Software quality management
2) Quantitative process management.
 Level 5: Optimizing – Continuous process improvement is enabled by
quantitative feedback from the process and testing innovative ideas and
technologies. Include all those in 4. This is the highest level and very few
software developers have reached this level. The following are the added Key
process Areas; 1) Process change management 2) Technology change
management and 3) defect prevention.

Software process models

The strategy which is put in place by the engineers which encompasses the process,
methods, and tools is called the process model. This model is chosen on the basis of the
nature of the project and application, the methods and tools to be used, and the controls
and deliverables expected. In general, software development can be taken a 4 stage
problem solving loop. The four stages are status quo (current state of affaires), problem
definition (identification of the specific problem to be solved), technical development
(problem solution through some form of technology), and solution integration (delivery
of results say documents, programs, data, new business function, new product etc to those
who requested the solution).

Fig 3 The phases of a problem solving loop

Problem
Definition

Status
Quo Technical
Solution development
Integration
 -8-

Since, cross-talk is needed at each stage and across the stages, at each stage, the status
Quo, problem definition, technical development and solution integration phases are
needed.

The Linear Sequential model

The linear sequential model, sometimes called classic life cycle, or waterfall model,
suggests a systematic sequential approach to software development which may begin at
the system level, to analysis, design, coding, testing and support.

Fig 4. A linear sequential model

System/info engineering

Code Test
Analysis Design

It is the oldest and most widely used model. It has the following activities;
 System/information engineering modeling; Since software is part of a large
system, the whole work begins by establishing requirements for all system
elements, and then establish the subsets of requirements. This is more so when
the system has to interface with other aspects like hardware, people, databases
etc. One does the top level analysis and design at this level.
 Software requirements analysis; To understand the nature of programs to be
built, the engineer must understand the information domain for the software, as
well as required functions, behavior, performance and interfacing.
 Design; Software design is a multi-step process that focus on four distinct
attributes of a program, namely; data structure, software architecture, interface
representations, and procedural/algorithm details. This process translates
requirements into representation of the software that can be assessed for quality
before coding begins.
 Code generation; This is translating the design into the machine-readable form.
If the design is well done to the required detail, then the code generation can be
mechanically generated.
 Testing: This is done after the code generation. It focus on internal logical flows,
assuring that all statements have been tested, and on functional externals. These
functional externals may include conducting tests to uncover errors, and make
sure that defined inputs will generate required outputs that agree with functional
requirements.
 Support; For sure, the software will undergo some changes after it has been
delivered to the customer as already discussed save for embedded –read-only
 -9-

software. These changes could be due to errors encountered, need to have it

adapted to accommodate changes in environment (eg new operating system etc),
or because of new functional requirements that need to be addressed by the
software.

The prototyping model

What is generally common in any software engineering projects, the customer defines a
set of general objectives for software, without identifying the details of inputs, processing
or output requirements. This leaves the engineer at a loss in terms of efficiency of the
algorithm, adaptability of an operating system, or form of human-machine interaction to
expect. In such a case, a prototyping model becomes appropriate.

Fig 5. The prototyping model

Build/revie
Listen to w mock-up
customer

Customer
test-drives
mock-up
This model, begins with requirements gathering, where the developer and customer meet
to agree on overall objective of the software, identify whatever requirements are known
to them, and outline areas that need further discussion. From this discussion, a quick
design is made. This design focus on areas which are visible to the customer/use e.g Input
and output approaches. In summary, prototype acts as a mechanism of identifying
software requirements. Under this model, the software developer identifies a working
prototype and attempts to make use of existing program fragments or apply tools like
report generators and window managers which can enable working programs to be
generated quickly. Indeed, in most cases, the first system developed is impossible to use
as it is too slow, too big, or awkward. The developer has to start again and make one
which is smarter. With prototypes, users get a feel for the actual system and developers
get to build something immediately. Unless the customer and developer agree on
prototype at the very beginning, then prototyping model may have some weaknesses such
as;
 Customer sees what appears to be a working version of the software, when he is
unaware that other aspects of quality are not yet in place. Upon realizing that, he
feels so let down and frustrated.
 The developer makes implementation compromises in order to get a prototype
quickly. Such compromises may be using a language that is available and known
to him, inefficient algorithm being used to show that you can program. The
danger with this arises when the developer keeps these choices and forgets the
reasons why they were inappropriate.
 - 10 -

The Rapid Application Development (RAD) Model

The RAD model is incremental model and emphasizes an extremely short development
cycle. It uses a component-based contraction approach there by appropriating the
elements of a linear sequential model.
Fig 6. The RAD model

Team 2
Team 1 Team 3
Business
Business
Business Modeling Modeling
Modeling
Data
Modeling
Data
Data Modeling Process
Modeling Modeling

Process Application
Process Modeling General

Modeling Testing and

Turnover
Applicati
Application on
General General

Testing
and
Testing and Turnover
Turnover

The success of this model is derived from a clear understanding of the functional
requirements and clear demarcation of the project scope. The RAD model has the
following phases;

 Business modeling:- The flow of information among the different business

function is modeled in such a way that the following questions are answered; 1)
What information drives the business process, 2) What information is generated
3) Who generates it 4) Where does information go 5) Who processes it.
 Data modeling:- The above information in business modeling is refined into data
objects that are needed to support the business. The attributes of each object are
identified and inter data relationship established.
 Process modeling:- The above data objects are transformed to achieve information
flow required to implement a business function. The processing descriptions are
for adding, modifying, deleting or retrieving a data object.
 Application generation:- RAD assumes that 4th generation techniques are used.
Other than using the 3rd generation conventional programming languages, RAD
tends to reuse existing program components
 Testing and turnover:- Since reuse is one of the key characteristics of RAD
model, a number of program components have been already tested. This therefore
reduces overall testing time. However, new components have to be tested. The
time constraint under RAD project demands for the scalable scope. When the
 - 11 -

business application can be modularized in such a way that major functions can
be completed in less than 3 months, then it is possible to think of using RAD. This
is because each major function can be addressed by a separate RAD team and
then integrated to form a whole project. The major setbacks of RAD model can be
summarized as thus;
 Large but scaleable projects, RAD requires sufficient human
resources to help create a right number of RAD teams.
 Developers and customers must be committed to the project if time
limits are to be met, else the RAD project may fail
 Not all types of projects can be implemented by RAD, especially if
the project can not be modularized.
 When technical risks are high, then do not use RAD. This may
arise when new technology is heavily used, or when new software
has a lot of linkages with existing computer programs etc.

Project Management Concepts

Introduction
Project management involves the planning, monitoring, and control of the people,
process, and events that occur as software evolves from preliminary concept to
operational implementation. Everyone in software development manages to some extent
but the scope of management activities varies with the person doing it. A software
engineer manages his day to day activities, planning, monitoring and controlling
technical tasks. Project managers plan, monitor and control the work of the team of
software engineers. Senior managers coordinate the interface between the business and
software professionals. Project management is important because building computer
software is a complex undertaking more especially if it involves many people who may
be required to work for a longer time.

For you to understand the steps in software project management, you must understand the
principle of P’s. These are People, Product, Process, and Project as we shall discuss later.
The People must be organized to perform the software project efficiently, communication
with customer must be well done so that product scope and requirements are well
understood, and an appropriate Process must be selected so that one can get required
Product. Under the project management, a project plan must be produced as management
activity commences. This plan must define the process and tasks to be conducted, the
people to do the work, and risk assessing mechanism be spelt out, controlling change and
quality evaluation procedures. The only way you can tell that your project plan and
management was good is when you deliver a good quality software/product on time and
within the budget. This can be achieved when the software manager encourages all the
people to work together as an effective team, focusing their attention on customer needs
and product quality.

The management spectrum

The management spectrum rotates around the 4 P’s: People, Product, Process and Project.
In case you ignore people in such management then you will have ignored the fact that
software engineering project is intensely human dependent hence no success is expected.
Likewise, when the manager fails to encourage comprehensive discussion with customer,
you end up with a good solution that solves a wrong problem. When you pay no attention
to the process, you end up placing technical people and tools into vacuum.
 - 12 -

The people:
The people management maturity model defines some practical areas for software people.
These areas are; 1) Recruiting, 2) selection 3) performance management 4) training 5)
Compensation 6) career development 7) organization and work design and 8) team and
culture development. The software process/project is done by players who may be;
 Senior managers: who define the business issues that often significantly influence
the project
 Project (technical) managers: who must plan, motivate, organize and control the
practitioners who do the software work
 Practitioners: who deliver the technical skills that are necessary to engineer a
product
 Customers: who specify the requirements for the software to be engineered and
other stakeholders who have interest in the outcome.
 End-users: who interact with the software once it is released for production use.
Any good team leader should have the skills to motivate (ability to encourage /push and
pull technical people to produce to their best ability), organize (ability to mould existing
process/or invent a new one, that will enable the initial concept to be transformed into a
final product), and create ideas or be innovative (ability to encourage people to create
and feel creative even when they must work within a boundaries established for particular
software project).
Good project manager should emphasize the following areas if he is to be successful;
problem solving (diagnose the technical and organizational issues that are most relevant,
systematically create a solution or motivate other team members to create solutions,
apply those solutions learnt from past projects, remain flexible enough to change
direction incase the earlier thought ideas don’t work). Managerial identity is displayed
by having confidence to assume control when necessary and assurance to allow good
technical people to follow their instinct. Achievements are realized when the manager
optimizes the productivity of the project team. This can be through rewarding initiatives
and accomplishments and control risks without punishing those were innovative. Lastly
there should be influence and team building done by the team leader. This can be
achieved by having a team leader than can read people, understand their verbal and non-
verbal signals, and react to the needs of people.

The product:
Before a project is planned, product (i.e. any software that can be developed at the
request of others) objectives and scope are established, alternative solutions are
established, and technical and management constraints are identified. Without this
information, realistic estimates of costs, effective assessment of risk, realistic project
breakdown, or a manageable project schedule which can be used to measure progress will
not be done. The project scope and objectives can be developed only when the customer
and software developers meet and discuss. Under scope, the following issues are
discussed; primary data, functions and behaviors of the product, and quantitative
description of these characteristics.
A software project manager is actively involved in determination of the software scope
by answering the following questions;
 Context- how does the software to be built fit into a large system, product or
business context and constrains are imposed
 - 13 -

 Information objectives – what customer visible data objects are produced as

outputs from the software and what data objects are required for the software?
 Function and performance – what functions does the software perform to
transform input data into outputs
Other than the software scope, the manager has to address the problem decomposition
challenges. Problem decomposition (sometimes called partitioning or problem
elaboration) is an activity that sits at the core of software requirements analysis.
Decomposition is applied in two major areas 1) the functionality that must be
delivered and 2) the process that will be used to deliver it

The Process
The software process provides a framework from which a comprehensive plan for
software development can be established. Note that many models have been developed
and it is a matter of adapting one to suit the project. The different tasks, milestones, work
products, and quality assurance points guide the adapting of model.
In generic phases that characterize the software process-definition, development and
support are applicable to all software. The problem is to select a software model that is
applicable to this particular project team. It is the role of the project manager to decide
which process model is most appropriate for 1) customers who have requested the
product and people who will do the work 2) the characteristics of the product itself and 3)
project environment in which the software team works. When the model has been
selected, then the team work out the software development plan based on set common
process framework activities and go on to decompose the process. The decomposed
process must then show a complete plan with work tasks required to populate the
framework activities.

There is a need to meld (combine) the product and the process developed and this is done
at the beginning of project planning. It should be noted that each function to be
engineered by the team must pass through a set of framework activities that have been
defined. Hence there must be 1) customer communication (tasks required to establish
effective requirements expected between the developer and customer) 2) Planning (tasks
required to define resources, timelines and other project related information) 3) Risk
analysis (tasks required to determine both managerial and technical risks) 4) engineering
(tasks required to build one or more aspects of the application) 5) construction and
release (tasks required to construct, test and install and provider user support) 6)customer
evaluation (tasks required to obtain customer feedback based on evaluation of the
software)
It will be after this, that process decomposition takes place. Process decomposition
commences when the project manager asks the following question “How do we
accomplish this common process framework –CPF activity?” For a small project, the
project might require the following work tasks for the customer communication activity:
Develop a list of clarification issues Meet with the customer to address the
clarification issues Jointly develop a statement of scope Review the statement of
scope with all concerned Modify the statement of scope as required.
For complex problems a broader scope and more significant issues are raised. Such
project may require the following work tasks for customer communication activity
Review the customer request plan and schedule a facilitated formal meeting with the
customer conduct research to define a proposed solution and existing approaches,
prepare a working document and an agenda for the formal meeting conduct the
 - 14 -

meeting jointly develop a min—doc that reflect data, function and behavioral features
of the software, Review each point raised for correctness, consistence, lack of
ambiguity. Assemble the min-doc into scoping documents review the scoping
document with all concerned and modify the scoping doc as required.

The Project
The software projects are supposed to be planned and controlled because it is the only
way one can ensure proper management of their complexity. In order to avoid project
failure, the software project manager and software engineers who build the product must
avoid a set of common warning signs; understand critical success factors that lead to
good product management, and develop a common sense approach for planning,
monitoring and controlling the project.

In order to manage a successful software project, we must understand what can go wrong
so that the problems can be solved in order to answer the question of how can I do it
right. Ten signs that indicate that an information system project is in jeopardy are when:
 Software people don’t understand the needs of the customer
 Product scope is poorly designed
 Changed are managed poorly
 Chosen technology changes
 Business needs change or are ill-defined
 Deadlines are unrealistic
 Users are resistant
 Sponsorship is lost or was not properly obtained
 The project team lacks people with appropriate skills and
 Managers and practitioners avoid best practices and lessons learnt
The following are suggestions for the manager if he is to avoid such problems as
mentioned above;
 Start at right foot by working hard to understand the problem, setting realistic
objects and expectations for everyone involved
 Maintain momentum. This is because many project get off to a good start and
then slowly disintegrate. Because of this, the project manager must provide
incentives to keep turnover of personnel to absolute minimum, team emphasize
quality in task performance, and senior managers keep out of way of the team
activities.
 Track progress: This is done by tracking the work products such as system
specifications, the source code and sets of test cases which should be produced
and approved using formal technical review systems as part of quality assurance.
 Make smart decisions: The decision of project manager and software team should
be to “Keep it simple”. If possible try to maximize the use of commercial off-the-
self software or existing software components, avoid custom interface when
standard ones are available, identify and hence avoid common/obvious mistakes.
 Conduct a postmortem analysis: Establish a consistent mechanism of extracting
lessons learnt from previous projects. Evaluate planned and actual schedule, get
feedback from software team members and customers and record findings in
written form.
 - 15 -

The W5 HH Principle
You need an organizing principle that scales down to provide simple plans for simple
projects an approach that addresses milestones and schedules, responsibilities,
management and technical approach, and the required resources. It is the WWWWWHH
principle, after a series of questions that lead to a definition of key project characteristics
and the resultant project plan.

Why is the system being developed? The answer to this question enables all parties to
assess the validity of business reasons for the software work. Stated in another way, does
the business purpose justify the expenditure of people, time and money?

What will be done by when? The answers to these questions help the team to establish a
project schedule by identifying key project tasks and the milestones that are required by
the customer.

Who is responsible for a function? It should be noted that the role and responsibility of
each member of the software team must be defined. The answer to this question helps
accomplish this stage.

Where are they organizationally located? Not all roles and responsibilities reside within
the software team itself. The customer, user, and other stakeholder also have
responsibilities.

How will the job be done technically and managerially? Once product scope is
established, a management and technical strategy for the project must be defined.

How much of each resource is needed? The answer to this question is derived from
developing estimates based on answers to the earlier questions.

The above questions provide an excellent planning outline for the project manager and
software team and this makes (W5HH) principle applicable to any software project
regardless of size and complexity.

Critical Practices
It is important that software projects take care of critical practices. To ensure that this
happens, Airlie council has developed a set of ‘Quick Look’ questions for a project as
discussed below;

i. Formal risk management: What are the top ten risks for this project? For each of the
risks, what is the chance that the risk will transition into a problem and what is the impact
if it does?
ii. Empirical cost and schedule estimation: What is the current estimated size of the
application software (excluding system software) that will be delivered into the
operation? How was it derived?
iii. Metric-based project management: Do you have in place a metric program to give an
early indication of evolving problems? If so, what is the current requirements volatility?
 - 16 -

iv. Earned value tracking. Do you report monthly earned value metrics? If so, are these
metrics computed from an activity network of tasks for the entire effort to the next
delivery?
v. Defect tracking against quality targets: Do you track and periodically report the
number of defects found by each inspection [formal technical review] and execution test
from program inception and the number of defects currently closed and open?
vi. People-aware program management. What is the average staff turn over for the past
three months for each of the suppliers/developers involved in the development of the
software for this system

SOFTWARE PROCESS AND PROJECT METRICS

Introduction
Like any other engineering project, measurement is fundamental discipline to any
software engineering project. Measurement enables us gain insight by providing a
mechanism for objective evaluation. One of the tools in measurement is a software
metrics. A software metrics refers to a broad range of measurement for the computer
software. Such measurements may be applied to software process with intension of
improving it continually. Measurements when done through out the software project, it
helps in estimation, quality control, productivity assessments, and project control. It also
helps to assess the quality of technical work products and help in tactical decision
making.

We can define ‘Software process and product metrics’ as quantitative measures that
enable software people to gain insight into the efficacy of the software process and the
projects that are conducted using the process as a framework. Basic quality and
productivity data are collected. These data are then analyzed, compared against past
averages, and assessed to determine whether quality and productivity improvements have
occurred. Metrics are also used to pinpoint problem areas so that remedies can be
developed and the software process can be improved.

Essentially, software metrics are analyzed and assessed by software managers, while
measures are often collected by software engineers. Metrics are very important because if
you do not measure, judgment can only be based on subjective evaluation. However, with
measurement, trends (either good or bad) can be spotted, better estimates can be made,
and true improvement can be accomplished over time. For you to be able to develop these
metrics, you begin by defining a limited set of process, project and product measures that
are easy to collect. These measures are often normalized using either size- or function
oriented metrics. The result is analyzed and compared to the past average for similar
projects performed with organization. Trends are assessed and conclusions are generated.

When we talk of work product, we refer to a set of software metrics that provide insight
into the process and understanding of the project. You can be sure that you have done
metrics well by applying, yet simple measurement scheme that is never to be used to
assess, reward, or punish individual performance.

Measures, Metrics and Indicators

A measure provides quantitative indication of the extent, amount, dimensions, capacity,
or size of some attribute of a product or process. Measurement on the other hand is the
act of determining a measure. To illustrate the difference, one can take the following
 - 17 -

example; when a single data point has been collected (e.g., the number of errors
uncovered in the review of a single module) a measure has been established.
Measurement occurs as a result of the collection of one or more data points (e.g., a
number of module reviews are investigated to collect measures of the number of errors
for each). A software metrics relates the individual measures in some way (e.g., the
average number of errors found per review or the average number of errors found per
person-hour expended on reviews).

A software engineer collects measures and develops metrics so that indicators will be
obtained. An indicator is a metric or combination of metrics that provide insights into the
software process, a software project, or the product itself. An indicator provides insight
that enables the project manager or software engineers to adjust the process, the project
or the process to make things better

Metrics in the Process and Project Domains

Metrics should be collected so that process and product indicators can be ascertained.
Process indicators enable a software engineering organization to gain insight into the
efficacy of an existing process (i.e., the paradigm, software engineering tasks, work
products, and milestones). They enable managers and practioners to assess what works
and what does not work

The intention of process metrics is to provide indicators that lead to long-term software
process improvements. Project indicators enable a software project manager to; 1) assess
the status of an on –going project; 2) track potential risks; 3) uncover problem areas
before they go ‘critical’; 4) adjust work flow or task; and 5) evaluate the project team’s
ability to control quality of the software work products. The same software metrics can
be used to determine both project and then process indicators.

Figure showing determinants for software quality and organizational effectiveness

Product

Customer Business Conditions

Characteristics

Process

People Technology
Development Environment
 - 18 -

Process metrics and software process improvement

The only rational way to improve any process is to measure specific attributes of the
process, develop a set of meaningful metrics based on the attributes ,and then use the
metrics to provide indicators that will lead to a strategy for improvement. A process is
one of a number of ‘controllable factors in improving software quality and organizational
performance’ PAU94

Referring to the figure above, process sits at the centre of a triangle connecting three
factors that have a profound influence software quality and organizational performance.
the skill and motivation of people has been shown[BOE81] TO BE THE SINGLE MOST
INFLUENCIAL FACTOR IN QUALITY AND PERFORMANCE. THE COMPLIXITY
OF THE PRODUCT CAN HAVE A SUBSTANTIAL IMPACT ON quality and team
performance. The technology (i.e., the software engineering methods) that populates the
process also has an impact. in addition ,the process triangle exists within a circle of
environmental conditions that include: the development environment (e.g., CASE
tools),business conditions (e.g., deadlines, business rules),and consumers
characteristics(e.g., ease of communication).

Glady [GRA92]argues that there are ‘private and public’ uses of different types of
process data .because its natural that individual software engineers might be sensitive to
the use of metrics collected on an individual basis ,these data should be private to an
individual and serve as indicator for the individual only. Examples of private metrics
include: defect rates(by individual) ,defect rates(by module),and errors found during
development.
The ‘private process data’ philosophy conforms well with the personal software process
approach.
1. The personal software process (PSP)is a structured set of process
descriptions,measurements,and methods that can help engineers to improve their
personal performance. It provides the forms, scripts, and standards that help them
estimate and plan their work. It shows them how to define processes and how to
measure their quality and productivity. A fundamental PSP principle is that every
one is different and that is effective for one engineer may not be suitable for
another.thePSP thus helps engineers to measure and track their own work so they
can find the methods that are best for them.
Public metrics generally assimilate information that originally was private to individuals
and teams. Project level defect rates (absolutely not attributed to an individual), effort,
calendertimes and related data are collected and evaluated in an attempt to un cover
indicators that can improve organizational process performance.
Software process metrics can provide significant benefit as an organization works to
improve its over all level of process maturity.however,like all metrics, these can be
misused ,creating more problems than they solve.Glady[GRA92]suggest ‘a software
metrics etiquette’ that is appropriate for both managers as they institute a process metrics
program:
 Use common sense and organizational sensitivity when interpreting metrics data
 Provide regular feedback to the individuals and teams who has worked to collect
measures and metrics
 - 19 -

 Do not use metrics to appraise individuals

 Work with practitioners and teams to set clear goals and metrics that will be used
to achieve them
 Never use metrics to threaten individual or teams
 Metrics data that indicate a problem area should not be considered ‘negative’
.these data are merely an indicator for process improvement
 Do not obsess on single metric to the exclusion of other important metrics.
o

As an organization becomes more comfortable with the collection and use of process
metrics, the derivation of simples indicators gives way to a more rigorous approach called
statical software process improvement (SSPI).in essence ,SSPI uses software failure
analysis to collect information about all errors and defects encountered as an application
,system ,or product is developed and used .failure analysis works in the following
manner:
-all errors and defects are categorized by origin (e.g., flaw in specification, flaw in logic,
nonconformance to standards)
-the cost to correct each error and defect is recorded
-the number of errors and defects in each category are counted and ordered in descending
order
-the over all cost of error and defects in each category is computed
-resultant data are analyzed to un cover the categories that result in highest cost to the
organization

SOFTWARE PROCESS AND PROJECT METRICS

DIAGRAM
-plans are developed to modify the process with the intent of eliminating or reducing the
frequency of occurrence of the class of errors and defects that is most costly.