CHINHOYI UNIVERSITY OF TECHNOLOGY

SCHOOL/INSTITUTE ENGINEERING SCIENCE AND TECHNOLOGY

DEPARTMENT/ ICT AND ELECTRONICS

CENTER

PROGRAMME BSIT

LEVEL 2.1

Module TITLE Software Engineering and project management

Module CODE CUITM 220

FACILITATOR DR TAVENGWA MASAMHA

1
MODULE OVERVIEW The module aims to construct a solid foundation for
understanding and application of principles, techniques and
technologies utilized in the development of standard software
systems. Describe the nature of software engineering and
problems encountered by software engineers and engineering
organizations. The module develops a working knowledge of
the principles of project planning, initiation, project life cycle,
estimation and monitoring the project process.

MODULE AIMS The module enables students to be able to:

 Identify a problem in an organization
 Design a software solution to an identified problem
 Develop a software solution to the identified problem
 Carry out a software project successfully
 Manage people in a software project
 Maintain a software product

OBJECTIVES By the end of the module students should be able to

 Engineer software requirements
 Design software
 Test software
 Deploy software
 Design a project plan
 Schedule activities
 Team playing
 Cost a project
 Ability to function effectively in a team to accomplish a
common goal
 Ability to identify user needs for the selection, creation,
evaluation and administration of computer-based
systems.
 analyse user needs for the selection, creation, evaluation
and administration of computer-based systems
LEARNING OUTCOMES After completion of the module, students are expected to be
able to:
 Engineer software requirements

 Design robust software

 Develop software ethically

2
  Test software

 Deploy software

 Develop a project plan

 Schedule activities for a software project

 Fruitfully work as a team in developing/managing a

software project.

 Develop a viable budget for a software project

 Perform user needs analysis

Subject specific intellectual and research skills

Having successfully completed this module you should be able
to:
 Plan a software project
 Develop a software product
 Assure product quality
 Schedule tasks
 Select an optimal solution
 Test a software product
 Validate a software
Life skills
 Ability to work in teams
 critical thinking
 communicate
 using IT for research
 punctuality, responsibility and accountability

RESOURCES/ Computer, Bigbluebutton, text books, journal articles, design

TECHNOLOGY/ documents, lecture notes, self-notes.
TECHNICAL SUPPORT

ASSESSMENT Students are assigned through written assignments, oral

presentations, group mini-project, in-class test, and a three-
hour theory examination paper.

3
UNIT 1: Introduction to software engineering
The meaning of software engineering

Introduction
By now you are familiar with programming or coding from the modules covered so far.
Programming requires you to be sharp and fast in converting a written down solution into a
set of computer instructions. Basically, in coding, you learn the syntax and semantics of a
given programming environment and compile the program. In many cases, programmers
work in isolation at this level. In this module, you shall learn that software engineering
extends the task of programming into a discipline where you are supposed to work in teams
and be expected to plan, control, and monitor the software development process. We begin
by looking at what software engineering is.
Learning outcomes
By the end of this unit you shall be able to:
 Define the term software engineering.
 Define code of ethics.
 Explain components of the software engineering code of ethics.
 Relate the software engineering code of ethics to practice.

Abbreviations and Acronyms

SE – Software
SECE – Software engineering code of ethics

Definition of software engineering

Activity 1.1 Give your definition of software engineering
Software engineering is the branch of computer science that deals with the design,
development, testing, and maintenance of software applications. Software engineers apply
engineering principles and knowledge of programming languages to build software solutions
for end users. It is a systematic and disciplined approach to software development that aims
to create high-quality, reliable, and maintainable software. Usually, software engineering
teams work with very large and complex problems. This calls for teamwork and good people
management skills.

4
Activity 1.2 Discuss any characteristics of software engineering
Software engineering
1. includes a variety of techniques, tools, and methodologies, including requirements
analysis, design, testing, and maintenance.
2. is a rapidly evolving field, and new tools and technologies are constantly being
developed to improve the software development process.
3. By following the principles of software engineering and using the appropriate tools
and methodologies, software developers can create high-quality, reliable, and
maintainable software that meets the needs of its users.
4. is mainly used for large projects based on software systems rather than single
programs or applications.
5. The main goal of Software Engineering is to develop software applications for
improving quality, budget, and time efficiency.
6. ensures that the software that has to be built should be consistent, correct, also on
budget, on time, and within the required requirements.

Activity 1.3 Outline any four principles that are employed in software engineering
Key Principles of Software Engineering
The following are the major principles of software engineering. Every software engineer is
expected to encompass most of these principles during the software development process.

1. Modularity: Breaking the software into smaller, reusable components that can be
developed and tested independently.
2. Abstraction: Hiding the implementation details of a component and exposing only
the necessary functionality to other parts of the software.
3. Encapsulation: Wrapping up the data and functions of an object into a single unit,
and protecting the internal state of an object from external modifications.
4. Reusability: Creating components that can be used in multiple projects, which can
save time and resources.
5. Maintenance: Regularly updating and improving the software to fix bugs, add new
features, and address security vulnerabilities.
6. Testing: Verifying that the software meets its requirements and is free of bugs.

5
 7. Design Patterns: Solving recurring problems in software design by providing
templates for solving them.
8. Agile methodologies: Using iterative and incremental development processes that
focus on customer satisfaction, rapid delivery, and flexibility.
9. Continuous Integration & Deployment: Continuously integrating the code changes
and deploying them into the production environment.

Activity 1.4 Explain why maintenance is the most costly and longest phase of the software
development process.

Main Attributes of Software

Software Engineering is a systematic, disciplined, quantifiable study and approach to the
design, development, operation, and maintenance of a software system. There are four main
attributes that every well-engineered software must have.

Activity 1.5 Discuss any two properties that you think a well-engineered software must have.

The attributes of a well-engineered software are:

1. Efficiency: It provides a measure of the resource requirement of a software product
efficiently. The software should be able to offer the expected services with minimal
use of resources.
2. Reliability: It assures that the product will deliver the same results when used in
similar working environment given the same input.
3. Reusability: This attribute makes sure that the module can be used in multiple
software applications with fewer adjustments if any. .
4. Maintainability: It is the ability of the software to be modified, repaired, or
enhanced easily with changing requirements without grossly affecting the
functionality of the software.

Dual Role of Software

Activity 1.6 What do you think is the role of software in an organisation?

There is a dual role of software in the industry. The first one is as a product and the other
one is as a vehicle for delivering the product. We will discuss both of them.

6
1. Software as a Product
 It delivers computing potential across networks of hardware.
 It enables the hardware to deliver the expected functionality.
 It acts as an information transformer because it produces, manages, acquires,
modifies, displays, or transmits information.
2. As a Vehicle for Delivering a Product
 It provides system functionality (e.g., payroll system).
 It controls other software (e.g., an operating system).
 It helps build other software (e.g., software tools).
Objectives of Software Engineering
The objectives of software engineering it o develop software that adheres to the following:
1. Maintainability: It should be feasible for the software to evolve to meet changing
requirements.
2. Efficiency: The software should not make wasteful use of computing devices such as
memory, processor cycles, etc.
3. Correctness: A software product is correct if the different requirements specified in
the software requirements specification document (SRS) has been correctly
implemented.
4. Reusability: A software product has good reusability if the different modules of the
product can easily be reused to develop new products.
5. Testability: Here software facilitates both the establishment of test criteria and the
evaluation of the software concerning those criteria.
6. Reliability: It is an attribute of software quality. The extent to which a program can
be expected to perform its desired function, over an arbitrary time period.
7. Portability: In this case, the software can be transferred from one computer system
or environment to another.
8. Adaptability: In this case, the software allows differing system constraints and the
user needs to be satisfied by making changes to the software.
9. Interoperability: Capability of 2 or more functional units to process data
cooperatively.
What Careers Are There in Software Engineering?
A degree in software engineering and relevant experience can be utilized to explore several
computing job choices. Software engineers have the opportunity to seek well-paying careers

7
and professional progress, although their exact possibilities may vary depending on their
particular university, industry, and region.
Possible job choices in software engineering include:
 SWE (Software Engineer)
 SDE (Software Development Engineer)
 Web Developer
 Quality Assurance Engineer
 Web Designer
 Software Test Engineer
 Cloud Engineer ·
 Front-End Developer
 Back-End Developer
 DevOps Engineer.
 Security Engineer.
Tasks of a Software Engineers
The main responsibility of a software engineer is to develop useful computer programs and
applications. Working in teams, you would complete various projects and develop solutions
to satisfy certain customer or corporate demands.

Some of the key responsibilities of a software engineer are:

 Requirement Analysis: Collaborating with stakeholders to understand and gather the

requirements to design and develop software solutions.
 Design and Development: Creating well-structured, maintainable code that meets
the functional requirements and adheres to software design principles.
 Testing and Debugging: Writing and conducting unit tests, integration tests, and
debugging code to ensure software is reliable and bug-free.
 Code Review: Participating in code reviews to improve code quality, ensure
adherence to standards, and facilitate knowledge sharing among team members.
 Maintenance: Updating and maintaining existing software systems, fixing bugs, and
improving performance or adding new features.
 Documentation: Writing clear documentation, including code comments, API
documentation, and design documents to help other engineers and future
developers understand the system.

8
Activity 1.7: List the skills that a software engineer should posses in order to be effective in
comparison to a programmer.

Software Engineering code of ethics and professional practice

Activity 1.8: 1. What do you understand by the term code of ethics?
2. To what extent can a code of ethics help advance the profession of software
engineering?

Software Engineering Code of Ethics and Professional Practice (Version 5.2) was
recommended by the ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and
Professional Practices and jointly approved by the ACM and the IEEE-CS as the standard for
teaching and practicing software engineering.

Software engineers shall commit themselves to making the analysis, specification, design,
development, testing and maintenance of software a beneficial and respected profession. In
accordance with their commitment to the health, safety and welfare of the public, software
engineers shall adhere to the following Eight Principles:
1. PUBLIC – Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT – Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.
4. JUDGMENT – Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and
maintenance.
6. PROFESSION – Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.
8. SELF – Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the profession.

9
Summary
It is important that every software engineer understands the meaning of software
engineering as a branch of computer science that aims to produce valuable software for the
client in an ethical manner. Software engineers should make sure that they work in a
standard manner so as to promote the software engineering profession. A well-engineered
software should provide expected functionality in a secure, robust, and sustainable way.

References/ Reading sources /links

Ian Sommerville ( 2011) Software Engineering, 8th Edition, Pearson Education
Http://[Link]/code-of-ethics/software-engineering-code/
[Link]/software-engineering
[Link]/resources/articles/software-development/what-is-software-engineering

10
UNIT 2: Software Development Life Cycle (SDLC

Introduction
Software engineering uses engineering principles to develop reliable and secure software
products. Every software should aim to provide the intended functionality in a cost-effective
way. The software engineer therefore should have a systematic and widely acceptable way
of developing the software. Software engineers thus developed a standard way of
developing software known as the Software Development Life Cycle. This unit shall explore
the Software Development Life Cycle and its associated software development models.
Learning outcomes
By the end of the unit, you shall be able to:
 Define the term Software Development Life Cycle (SDLC)
 Explain the SDLC stages
 Relate the stages of the SDLC to real software development

Abbreviations and Acronyms

SDLC – Software development life cycle
DDS – Design Document Specification
SRS – Software Requirements Specification

Activity 2.1 Explain the significance of the L in SDLC. Justify the life aspect of a software.
Software development life cycle (SDLC) is a structured process that is used to design,
develop, and test good-quality software. SDLC, or software development life cycle, is a
methodology that defines the entire procedure of software development step-by-step.
The goal of the SDLC life cycle model is to deliver high-quality, maintainable software that
meets the user’s requirements. SDLC in software engineering models outlines the plan for
each stage so that each stage of the software development model can perform its task
efficiently to deliver the software at a low cost within a given time frame that meets users
requirements.
What is the Software Development Life Cycle?
SDLC is a process followed for software building within a software organization. SDLC
consists of a precise plan that describes how to develop, maintain, replace, and enhance
specific software. The life cycle defines a method for improving the quality of software and
the all-around development process.

11
What is the need for SDLC?
SDLC is a method, approach, or process that is followed by a software development
organization while developing any software. SDLC models were introduced to follow a
disciplined and systematic method when developing software. With the software
development life cycle, the process of software design is divided into small parts, which
makes the problem more understandable and easier to solve. SDLC comprises a detailed
description or step-by-step plan for designing, developing, testing, and maintaining the
software (Figure 2a).

Figure 2a: Stages of the Software Development Life Cycle

SDLC specifies the task(s) to be performed at various stages by a software engineer or
developer. It ensures that the end product meets the customer’s expectations and fits within
the overall budget. Hence, a software developer needs to have prior knowledge of this
software development process. SDLC is a collection of these six stages. The stages of SDLC
are as follows (Figure 2b):

12
Figure 2b: SDLC Stages

The SDLC Model involves six phases or stages for developing a software.
Stage-1: Planning and Requirement Analysis
Planning is a crucial step in everything, just as in software development. In this same stage,
requirement analysis is also performed by the developers of the organization. This is
attained from customer inputs, and sales department/market surveys.
The information from this analysis forms the building blocks of a basic project. The quality of
the project is a result of planning. Thus, in this stage, the basic project is designed with all
the available information. In planning you need to define the scope of the product, set
objectives or goals and plan your required resources as indicated in figure 2c.

Figure 2c: planning a software

13
Stage-2: Defining Requirements

Activity 2.2: Define the term software requirement.

In this stage, all the requirements for the target software are specified. These requirements
get approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a sort of
document that specifies all those things that need to be defined and created during the
entire project cycle. In defining requirements, there is the need to distinguish between
functional requirements, and technical requirements and then do requirements reviews and
get approval from the stakeholders.

Figure 2d: Stages in defining requirements

Activity 2.3:
1. What do you understand by the term architecture?
2. What is a design architecture with reference to a software product?
Stage-3: Designing Architecture
SRS is a reference for software designers to come up with the best architecture for the
software. Hence, with the requirements defined in SRS, multiple designs for the product
architecture are present in the Design Document Specification (DDS).

This DDS is assessed by market analysts and stakeholders. After evaluating all the possible
factors, the most practical and logical design is chosen for development. In designing you
need to develop the low level design architecture and the high level design architecture as
shown in figure 2e.

14
 Figure 2e: Architectural design

Activity 2.4: Read on the differences between low-level design and high-level design giving
examples of each.

Stage-4: Developing Product

At this stage, the fundamental development of the product starts. For this, developers use a
specific programming code as per the design in the DDS. Hence, it is important for the
coders to follow the protocols set by the association. Conventional programming tools like
compilers, interpreters, debuggers, etc. are put into use at this stage. Programming
languages used include C, C++, Python, Java, Visual Basic.
Activity 2.5: Categorise the listed programming languages into procedural, visual and object
oriented. Give justification.

Figure 2f: the development process

Stage-5: Product Testing and Integration

Activity 2.6: Give practical reasons why testing should be planned well before the
development of software starts.
After the development of the product, testing of the software is necessary to ensure it
meets customer requirements although, minimal testing is conducted at every stage of the
SDLC. At this stage, all the probable flaws are tracked, fixed, and retested. This ensures that
the product satisfies the quality requirements of SRS.

15
Documentation, Training, and Support: software documentation is an important part of the
software development life cycle. A well-written document acts as a tool and means to
information repository for software processes, functions, and maintenance. Documentation
also provides information about how to use the product. Training is an attempt to improve
the current or future employee performance by increasing an employee’s ability to work
through learning, usually by changing his attitude and developing his skills and
understanding.

Figure 2g: Software testing

Activity 2.7: Distinguish between manual testing and automated testing giving practical
examples.
Stage-6: Deployment and Maintenance of Products
After detailed testing, the final product is released as per the organization’s strategy. Then it
is tested in a real industrial environment. It is important to ensure its smooth performance.
After retrieving beneficial feedback, the company releases it as it is or with auxiliary
improvements to make it further helpful for the customers. However, this alone is not
enough. Therefore, along with the deployment, the product’s supervision.

Figure 2h: Deployment and maintenance

Software Development Life Cycle Models

There are several recognized SDLC models in use. But None of them is perfect, and each
brings its favourable aspects and drawbacks for a specific software development project or a
team.

Activity 2.8: Name as many examples of software development models as you can.

16
Now let us go through some of the models.
1. Waterfall Model
This is the fundamental model of the software development life cycle. It is a very simple
model. The waterfall model is not in practice anymore, but it is the basis for all other SDLC
models. Because of its simple structure, the waterfall model is easier to use and provides a
tangible output. In the waterfall model, once a phase seems to be completed, it cannot be
changed, and due to this less flexible nature, the waterfall model is not in practice anymore.

Figure 2i: The simple waterfall model

Activity 2.9: Suggest the type of projects where the waterfall model may be appropriate
indicating why the model is no longer the preferred model.

2. The Agile Model

The agile model in SDLC was mainly designed to adapt to changing requests quickly. The
main goal of the Agile model is to facilitate quick project completion. The agile model refers
to a group of development processes. These processes have some similar characteristics but
also possess certain subtle differences among themselves.

17
 Figure 2j: The agile model

Iterative Model
In the Iterative model in SDLC, each cycle results in a semi-developed but deployable
version; with each cycle, some requirements are added to the software, and the final cycle
results in the software with the complete requirement specification.

18
 Figure 2k: The iterative model

4. Spiral Model
The spiral model in SDLC is one of the most crucial SDLC models that provides support for
risk handling. It has various spirals in its diagrammatic representation; the number of spirals
depends upon the type of project. Each loop in the spiral structure indicates the Phases of
the Spiral model.

19
 Figure 2l: The Spiral model

5. V-Shaped Model
The V-shaped model in SDLC is executed in a sequential manner in V-shape. Each stage or
phase of this model is integrated with a testing phase. After every development phase, a
testing phase is associated with it, and the next phase will start once the previous phase is
completed, i.e., development & testing. It is also known as the verification or validation
model.

20
 Figure 2m: The V Model

6. Big Bang Model

The Big Bang model in SDLC is a term used to describe an informal and unstructured
approach to software development, where there is no specific planning, documentation, or
well-defined phases.

Figure 2n: The Big Bang Model

21
 7. The Incremental Development model
Incremental Model is a process of software development where requirements are broken
down into multiple standalone modules of software development cycle. Incremental
development is done in steps from analysis design, implementation, testing/verification,
maintenance.
Each iteration passes through the requirements, design, coding and testing phases. And
each subsequent release of the system adds function to the previous release until all
designed functionality has been implemented.
The system is put into production when the first increment is delivered. The first increment
is often a core product where the basic requirements are addressed, and supplementary
features are added in the next increments. Once the core product is analyzed by the client,
there is plan development for the next increment.

Figure 2o: The Incremental Development Model

8. Prototyping
Prototyping is defined as the process of developing a working replication of a product or
system that has to be engineered. It offers a small-scale facsimile of the end product and is
used for obtaining customer feedback. The Prototyping concept is described below:
The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models). This model is used when the customers do not know the exact
project requirements beforehand. In this model, a prototype of the end product is first
developed, tested, and refined as per customer feedback repeatedly till a final acceptable
prototype is achieved which forms the basis for developing the final product.
n this process model, the system is partially implemented before or during the analysis
phase thereby allowing the customers to see the product early in the life cycle. The process
starts by interviewing the customers and developing the incomplete high-level paper model.
This document is used to build the initial prototype supporting only the basic functionality as
desired by the customer. Once the customer figures out the problems, the prototype is

22
further refined to eliminate them. The process continues until the user approves the
prototype and finds the working model to be satisfactory.

Figure 2p: The prototyping Model concept

Steps of the Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a prototype
model. In this phase, users are asked about what they expect or what they want from the
system.
Step 2: Quick Design: This is the second step in the Prototyping Model. This model covers
the basic design of the requirement through which a quick overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strengths and
weaknesses of the design, which was sent to the developer.
Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here the
program is run regularly to prevent failures.

23
Types of Prototyping Models
There are four types of Prototyping Models, which are described below.

Rapid Throwaway Prototyping

Evolutionary Prototyping
Incremental Prototyping
Extreme Prototyping

1. Rapid Throwaway Prototyping

This technique offers a useful method of exploring ideas and getting customer feedback for
each of them.
In this method, a developed prototype need not necessarily be a part of the accepted
prototype.
Customer feedback helps prevent unnecessary design faults and hence, the final prototype
developed is of better quality.

24
2. Evolutionary Prototyping
In this method, the prototype developed initially is incrementally refined based on customer
feedback till it finally gets accepted.
In comparison to Rapid Throwaway Prototyping, it offers a better approach that saves time
as well as effort.
This is because developing a prototype from scratch for every iteration of the process can
sometimes be very frustrating for the developers.

25
3. Incremental Prototyping
In this type of incremental prototyping, the final expected product is broken into different
small pieces of prototypes and developed individually.
In the end, when all individual pieces are properly developed, then the different prototypes
are collectively merged into a single final product in their predefined order.
It’s a very efficient approach that reduces the complexity of the development process,
where the goal is divided into sub-parts and each sub-part is developed individually.
The time interval between the project’s beginning and final delivery is substantially reduced
because all parts of the system are prototyped and tested simultaneously.
Of course, there might be the possibility that the pieces just do not fit together due to some
lack of ness in the development phase – this can only be fixed by careful and complete
plotting of the entire system before prototyping starts.

4. Extreme Prototyping
This method is mainly used for web development. It consists of three sequential
independent phases:
In this phase, a basic prototype with all the existing static pages is presented in HTML
format.
In the 2nd phase, Functional screens are made with a simulated data process using a
prototype services layer.
This is the final step where all the services are implemented and associated with the final
prototype.

26
This Extreme Prototyping method makes the project cycling and delivery robust and fast and
keeps the entire developer team focused and centralized on product deliveries rather than
discovering all possible needs and specifications and adding necessitated features.

Advantages of Prototyping Model

 The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for refinement.
 Missing functionalities can be easily figured out.
 Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
 The developed prototype can be reused by the developer for more complicated
projects in the future.
 Flexibility in design.
 Early feedback from customers and stakeholders can help guide the development
process and ensure that the final product meets their needs and expectations.
 Prototyping can be used to test and validate design decisions, allowing for
adjustments to be made before significant resources are invested in development.
 Prototyping can help reduce the risk of project failure by identifying potential issues
and addressing them early in the process.
 Prototyping can facilitate communication and collaboration among team members
and stakeholders, improving overall project efficiency and effectiveness.
 Prototyping can help bridge the gap between technical and non-technical
stakeholders by providing a tangible representation of the product.
Disadvantages of the Prototyping Model
 Costly concerning time as well as money.
 There may be too much variation in requirements each time the prototype is
evaluated by the customer.
 Poor Documentation due to continuously changing customer requirements.
 It is very difficult for developers to accommodate all the changes demanded by the
customer.
 There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
 After seeing an early prototype, the customers sometimes demand the actual
product to be delivered soon.
 Developers in a hurry to build prototypes may end up with sub-optimal solutions.
 The customer might lose interest in the product if he/she is not satisfied with the
initial prototype.
 The prototype may not be scalable to meet the future needs of the customer.
 The prototype may not accurately represent the final product due to limited
functionality or incomplete features.

27
  The focus on prototype development may shift away from the final product, leading
to delays in the development process.
 The prototype may give a false sense of completion, leading to the premature release
of the product.
 The prototype may not consider technical feasibility and scalability issues that can
arise during the final product development.
 The prototype may be developed using different tools and technologies, leading to
additional training and maintenance costs.
 The prototype may not reflect the actual business requirements of the customer,
leading to dissatisfaction with the final product.
Applications of Prototyping Model
 The Prototyping Model should be used when the requirements of the product are
not clearly understood or are unstable.
 The prototyping model can also be used if requirements are changing quickly.
 This model can be successfully used for developing user interfaces, high-technology
software-intensive systems, and systems with complex algorithms and interfaces.
 The prototyping Model is also a very good choice to demonstrate the technical
feasibility of the product.
 For more software engineering models, refer to Classical Waterfall Model, Spiral
Model, and Iterative Waterfall Model.
Types of prototypes in Industry
he development of a product requires different types of prototypes at different stages. In the
early stages, companies and investors must quickly save money and prove their invention
concept. Prototypes can save you time and money if you know what they are and when to
use them. There are four types of prototype models in the industry:
Proof of Concept
Make reasonable assumptions about the cost of manufacturing by using existing materials,
parts, and components. A proof of concept device shows you that a feature or measurement
is possible, but the data captured may not be accurate and highly repeatable. In most cases,
proof of concept prototypes is created using simple materials like cardboard, and duct tape.
Visual Prototype
Visual Prototype demonstrates a proposed product's overall appearance, shape, and
dimensions. However, it usually does not have any working parts. But it is a mock-up of the
product often shown to investors and early customers. In most cases, visual prototypes are
created using simple materials like cardboard, foam, paper, or wood to quickly show the
concept in 3D. It is possible to create very realistic-looking prototypes today using 3D
printing. It is important to get feedback from trusted people on the visual representation.
Working Prototype

28
Product development requires the creation of a fully functional working prototype. Thus, it
is integral to testing, trials, pitches, and market research. It is best if this prototype is
engineered for manufacture, but sometimes it may not be fully designed. The image below
illustrates what a working prototype is.
Pre-Production Prototype
To ensure the quality and manufacturability of a product, the manufacturer provides a
prototype before full production begins. Typically, a pre-production or prototype version of a
product includes a preliminary, unqualified version that is not intended for resale.

Summary
There several types of models that can be used to develop software. Each one has its own
advantages and disadvantages. These models basically include the stages of problem
definition and requirements engineering, Design, Development and maintenance. Each
model is appropriate for certain types of products or organisations. It is therefore important
to ensure that the choice of a model is well-thought.

References/ Reading sources /links

[Link]/software-prototyping-model-and-phases/
[Link]/outsourcing/2022/05/[Link]
[Link]/blog/4-types-of-prototyping
Ian Sommerville

29
UNIT 3: Requirements Engineering
Introduction
For every software to be developed there is a client who needs that software. Therefore, it is
important that the developers seek to have a deep understanding of the client expectations.
This topic shall help you to explore methods that are used to gather and analyse software
requirements. The given software requirements guide the whole process of software
engineering.
Learning outcomes
By the end of this unit you should be able to:
 Define a requirement
 Describe the process of engineering requirements
 Engineer software requirements for a given client.

What is Requirements Engineering?

A systematic and strict approach to the definition, creation, and verification of requirements
for a software system is known as requirements engineering. To guarantee the effective
creation of a software product, the requirements engineering process entails several tasks
that help in understanding, recording, and managing the demands of stakeholders.

Requirements Engineering Process

Requirements Engineering Process

30
 1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management
Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below. Among
these Economic Feasibility Study is the most important part of the feasibility analysis and the
Legal Feasibility Study is less considered feasibility analysis.
1. Technical Feasibility: In Technical Feasibility current resources both hardware
software along required technology are analyzed/assessed to develop the project.
This technical feasibility study reports whether there are correct required resources
and technologies that will be used for project development. Along with this, the
feasibility study also analyzes the technical skills and capabilities of the technical
team, whether existing technology can be used or not, whether maintenance and up-
gradation are easy or not for the chosen technology, etc.
2. Operational Feasibility: In Operational Feasibility degree of providing service to
requirements is analyzed along with how easy the product will be to operate and
maintain after deployment. Along with these other operational scopes are
determining the usability of the product, Determining suggested solution by the
software development team is acceptable or not, etc.
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the
project are analyzed. This means under this feasibility study a detailed analysis is
carried out will be cost of the project for development which includes all required
costs for final development hardware and software resources required, design and
development costs operational costs, and so on. After that, it is analyzed whether the
project will be beneficial in terms of finance for the organization or not.
4. Legal Feasibility: In legal feasibility, the project is ensured to comply with all relevant
laws, regulations, and standards. It identifies any legal constraints that could impact
the project and reviews existing contracts and agreements to assess their effect on
the project’s execution. Additionally, legal feasibility considers issues related to
intellectual property, such as patents and copyrights, to safeguard the project’s
innovation and originality.
5. Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to
determine if it is realistic and achievable. Significant milestones are identified, and
deadlines are established to track progress effectively. Resource availability is
assessed to ensure that the necessary resources are accessible to meet the project
schedule. Furthermore, any time constraints that might affect project delivery are

31
 considered to ensure timely completion. This focus on schedule feasibility is crucial
for the successful planning and execution of a project.
2. Requirements Elicitation
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of the same type, standards, and other stakeholders of the
project. The techniques used for requirements elicitation include interviews, brainstorming,
task analysis, Delphi technique, prototyping, etc. Some of these are
discussed here. Elicitation does not produce formal models of the requirements understood.
Instead, it widens the domain knowledge of the analyst and thus helps in providing input to
the next stage.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the requirements
engineering process and it is critical to the success of the software development project. The
goal of this step is to understand the problem that the software system is intended to solve
and the needs and expectations of the stakeholders who will use the system.
Several techniques can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.
It’s important to document, organize, and prioritize the requirements obtained from all
these techniques to ensure that they are complete, consistent, and accurate.
3. Requirements Specification
This activity is used to produce formal software requirement models. All the requirements
including the functional as well as the non-functional requirements and the constraints are
specified by these models in totality. During specification, more knowledge about the
problem may be required which can again trigger the elicitation process. The models used at
this stage include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.

32
Requirements specification is the process of documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the
requirements for the software system. This document should be understandable by both the
development team and the stakeholders.
Several types of requirements are commonly specified in this step, including
1. Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
2. Non-Functional Requirements: These describe how well the software system should
do it. They specify the quality attributes of the system, such as performance,
reliability, usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered
when developing the software system.
4. Acceptance Criteria: These describe the conditions that must be met for the
software system to be considered complete and ready for release.
To make the requirements specification clear, the requirements should be written in a
natural language and use simple terms, avoiding technical jargon, and using a consistent
format throughout the document. It is also important to use diagrams, models, and other
visual aids to help communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the
stakeholders and development team to ensure that they are complete, consistent, and
accurate.
4. Requirements Verification and Validation
Verification: It refers to the set of tasks that ensures that the software correctly implements
a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been
built is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
1. The requirements should be consistent with all the other requirements i.e. no two
requirements should conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.

33
Requirements verification and validation (V&V) is the process of checking that the
requirements for a software system are complete, consistent, and accurate and that they
meet the needs and expectations of the stakeholders. The goal of V&V is to ensure that the
software system being developed meets the requirements and that it is developed on time,
within budget, and to the required quality.
1. Verification is checking that the requirements are complete, consistent, and accurate.
It involves reviewing the requirements to ensure that they are clear, testable, and
free of errors and inconsistencies. This can include reviewing the requirements
document, models, and diagrams, and holding meetings and walkthroughs with
stakeholders.
2. Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure that
they are valid and that the software system being developed will meet the needs of
the stakeholders. This can include testing the software system through simulation,
testing with prototypes, and testing with the final version of the software.
3. Verification and Validation is an iterative process that occurs throughout the software
development life cycle. It is important to involve stakeholders and the development
team in the V&V process to ensure that the requirements are thoroughly reviewed
and tested.
It’s important to note that V&V is not a one-time process, but it should be integrated and
continue throughout the software development process and even in the maintenance stage.
5. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing,
and agreeing on the requirement and controlling the communication with relevant
stakeholders. This stage takes care of the changing nature of requirements. It should be
ensured that the SRS is as modifiable as possible to incorporate changes in requirements
specified by the end users at later stages too. Modifying the software as per requirements in
a systematic and controlled manner is an extremely important part of the requirements
engineering process.
Requirements management is the process of managing the requirements throughout the
software development life cycle, including tracking and controlling changes, and ensuring
that the requirements are still valid and relevant. The goal of requirements management is
to ensure that the software system being developed meets the needs and expectations of
the stakeholders and that it is developed on time, within budget, and to the required quality.
Several key activities are involved in requirements management, including:
1. Tracking and controlling changes: This involves monitoring and controlling changes
to the requirements throughout the development process, including identifying the
source of the change, assessing the impact of the change, and approving or rejecting
the change.

34
 2. Version control: This involves keeping track of different versions of the requirements
document and other related artifacts.
3. Traceability: This involves linking the requirements to other elements of the
development process, such as design, testing, and validation.
4. Communication: This involves ensuring that the requirements are communicated
effectively to all stakeholders and that any changes or issues are addressed promptly.
5. Monitoring and reporting: This involves monitoring the progress of the development
process and reporting on the status of the requirements.
Requirements management is a critical step in the software development life cycle as it
helps to ensure that the software system being developed meets the needs and
expectations of stakeholders and that it is developed on time, within budget, and to the
required quality. It also helps to prevent scope creep and to ensure that the requirements
are aligned with the project goals.
Tools Involved in Requirement Engineering
 Observation report
 Questionnaire (survey, poll)
 Use cases
 User stories
 Requirement workshop
 Mind mapping
 Roleplaying
 Prototyping
Advantages of Requirements Engineering Process
 Helps ensure that the software being developed meets the needs and expectations
of the stakeholders
 Can help identify potential issues or problems early in the development process,
allowing for adjustments to be made before significant
 Helps ensure that the software is developed in a cost-effective and efficient manner
 Can improve communication and collaboration between the development team and
stakeholders
 Helps to ensure that the software system meets the needs of all stakeholders.
 Provides an unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.

35
  Helps to identify potential conflicts and contradictions in the requirements, which
can be resolved before the software development process begins.
 Helps to ensure that the software system is delivered on time, within budget, and to
the required quality standards.
 Provides a solid foundation for the development process, which helps to reduce the
risk of failure.
Disadvantages of Requirements Engineering Process
 Can be time-consuming and costly, particularly if the requirements-gathering process
is not well-managed
 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into
account
 It Can be challenging to ensure that the requirements are clear, consistent, and
complete
 Changes in requirements can lead to delays and increased costs in the development
process.
 As a best practice, Requirements engineering should be flexible, adaptable, and
should be aligned with the overall project goals.
 It can be time-consuming and expensive, especially if the requirements are complex.
 It can be difficult to elicit requirements from stakeholders who have different needs
and priorities.
 Requirements may change over time, which can result in delays and additional costs.
 There may be conflicts between stakeholders, which can be difficult to resolve.
 It may be challenging to ensure that all stakeholders understand and agree on the
requirements.
Stages in Software Engineering Process
Requirements engineering is a critical process in software engineering that involves
identifying, analyzing, documenting, and managing the requirements of a software system.
The requirements engineering process consists of the following stages:
 Elicitation: In this stage, the requirements are gathered from various stakeholders
such as customers, users, and domain experts. The aim is to identify the features and
functionalities that the software system should provide.
 Analysis: In this stage, the requirements are analyzed to determine their feasibility,
consistency, and completeness. The aim is to identify any conflicts or contradictions
in the requirements and resolve them.

36
  Specification: In this stage, the requirements are documented in a clear, concise, and
unambiguous manner. The aim is to provide a detailed description of the
requirements that can be understood by all stakeholders.
 Validation: In this stage, the requirements are reviewed and validated to ensure that
they meet the needs of all stakeholders. The aim is to ensure that the requirements
are accurate, complete, and consistent.
 Management: In this stage, the requirements are managed throughout the software
development lifecycle. The aim is to ensure that any changes or updates to the
requirements are properly documented and communicated to all stakeholders.
 Effective requirements engineering is crucial to the success of software development
projects. It helps ensure that the software system meets the needs of all stakeholders
and is delivered on time, within budget, and to the required quality standards.
Summary
As the project develops and new information becomes available, the iterative requirements
engineering process may involve going back and reviewing earlier phases. Throughout the
process, stakeholders in the project must effectively communicate and collaborate to
guarantee that the software system satisfies user needs and is in line with the company’s
overall goals.

References/ Reading sources /links

[Link]/software-engineering-requirements-engineering-process/
[Link]/software-engineering-requirements-engineering-process/
[Link]/software-engineering-requirement-engineering
[Link]/blog/software-requirements-engineering-the-driving-force-behind-
successful-and-efficient-it-projects/
[Link]/software_engineering/software_requirements.htm

37
UNIT 3: Software Design
Software Design Process – Software Engineering
Introduction
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a
programming language. The software design process can be divided into the following three
levels or phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design

Learning outcomes
By the end of this unit you should be able to:
 Explain the need for a design
 Develop an interface design
 Develop an architectural design
 Develop a detailed design for a software.

Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior, and
views of a system. We can use flowcharts to represent and illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
3. Components: This provides a particular function or group of related functions. They
are made up of modules.
4. Interfaces: This is the shared boundary across which the components of a system
exchange information and relate.
5. Data: This is the management of the information and data flow.

38
Software Design Process

Interface Design
Interface design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the inner
workings of the system i.e, during interface design, the internal of the systems are
completely ignored, and the system is treated as a black box. Attention is focused on the
dialogue between the target system and the users, devices, and other systems with which it
interacts. The design problem statement produced during the problem analysis step should
identify the people, other systems, and devices which are collectively called agents.
Interface design should include the following details:
1. Precise description of events in the environment, or messages from agents to which
the system must respond.
2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going out of
the system.

39
 4. Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.
Architectural Design
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them.
In architectural design, the overall structure of the system is chosen, but the internal details
of major components are ignored. Issues in architectural design includes:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
5. Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design
of the internals of the major components is ignored until the last phase of the design.
Detailed Design
Detailed design is the specification of the internal elements of all major system components,
their properties, relationships, processing, and often their algorithms and the data
structures. The detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility of
program elements.
7. Algorithms and data structures.

40
Unit 4: Verification and Validation
2.0 Introduction
As one develops a software, one has to make sure that the software is developed in the
correct manner for the intended outcomes and deliverables. To be able to do all these, the
developer has to use appropriate verification and validation techniques. These techniques
are the subject of this unit.
Learning outcomes
By the end of this unit you should be able to:
 Define verification
 Define validation
 Differentiate verification and validation.
 Verify software development
 Validate a software

Verification vs Validation: Definitions

Software testing is a process of examining the functionality and behavior of the software
through verification and validation.

Verification is a process of determining if the software is designed and developed as per the
specified requirements.
Validation is the process of checking if the software (end product) has met the client’s true
needs and expectations.
Software testing is incomplete until it undergoes verification and validation processes.
Verification and validation are the main elements of software testing workflow because
they:
 Ensure that the end product meets the design requirements.
 Reduce the chances of defects and product failure.
 Ensure that the product meets the quality standards and expectations of all
stakeholders involved.
Most people confuse verification and validation; some use them interchangeably. People
often mistake verification and validation because of a lack of knowledge on the purposes
they fulfill and the pain points they address.

Verification

41
As mentioned, verification is the process of determining if the software in question is
designed and developed according to specified requirements. Specifications act as inputs for
the software development process. The code for any software application is written based
on the specifications document.

Verification is done to check if the software being developed has adhered to these
specifications at every stage of the development life cycle. The verification ensures that the
code logic is in line with specifications.

Depending on the complexity and scope of the software application, the software testing
team uses different methods of verification, including inspection, code reviews, technical
reviews, and walkthroughs. Software testing teams may also use mathematical models and
calculations to make predictive statements about the software and verify its code logic.

Further, verification checks if the software team is building the product right. Verification is a
continuous process that begins well in advance of validation processes and runs until the
software application is validated and released.

The main advantages of the verification are:

 It acts as a quality gateway at every stage of the software development process.

 It enables software teams to develop products that meet design specifications and
customer needs.
 It saves time by detecting the defects at the early stage of software development.
 It reduces or eliminates defects that may arise at the later stage of the software
development process.
Let us take a walkthrough of verification of a mobile application
 There are three phases in the verification testing of a mobile application
development:
 Requirements Verification
 Design Verification
 Code Verification
Requirements verification is the process of verifying and confirming that the requirements
are complete, clear, and correct. Before the mobile application goes for design, the testing
team verifies business requirements or customer requirements for their correctness and
completeness.

42
Design verification is a process of checking if the design of the software meets the design
specifications by providing evidence. Here, the testing team checks if layouts, prototypes,
navigational charts, architectural designs, and database logical models of the mobile
application meet the functional and non-functional requirements specifications.

Code verification is a process of checking the code for its completeness, correctness, and
consistency. Here, the testing team checks if construction artifacts such as source code, user
interfaces, and database physical model of the mobile application meet the design
specification.

Validation
Validation is often conducted after the completion of the entire software development
process. It checks if the client gets the product they are expecting. Validation focuses only on
the output; it does not concern itself about the internal processes and technical intricacies
of the development process.

Validation helps to determine if the software team has built the right product. Validation is a
one-time process that starts only after verifications are completed. Software teams often use
a wide range of validation methods, including White Box Testing (non-functional testing or
structural/design testing) and Black Box Testing (functional testing).

White Box Testing is a method that helps validate the software application using a
predefined series of inputs and data. Here, testers just compare the output values against
the input values to verify if the application is producing output as specified by the
requirements.

There are three vital variables in the Black Box Testing method (input values, output values,
and expected output values). This method is used to verify if the actual output of the
software meets the anticipated or expected output.

The main advantages of validation processes are:

 It ensures that the expectations of all stakeholders are fulfilled.
 It enables software teams to take corrective action if there is a mismatch between
the actual product and the anticipated product.
 It improves the reliability of the end-product.

43
Let us take a walkthrough of validation of a mobile application
Validation emphasizes checking the functionality, usability, and performance of the mobile
application.

Functionality testing checks if the mobile application is working as expected. For instance,
while testing the functionality of a ticket-booking application, the testing team tries to
validate it through:

Installing, running, and updating the application from distribution channels like Google Play
and the App Store
Booking tickets in the real-time environment (fields testing)
Interruptions testing
Usability testing checks if the application offers a convenient browsing experience. User
interface and navigations are validated based on various criteria which include satisfaction,
efficiency, and effectiveness.

Performance testing enables testers to validate the application by checking its reaction and
speed under the specific workload. Software testing teams often use techniques such as
load testing, stress testing, and volume testing to validate the performance of the mobile
application.

Main differences between verification and validation

Verification and validation, while similar, are not the same. There are several notable
differences between these two. Here is a chart that identifies the differences between
verification and validation:

44
 Verification Validation

It is a process of checking if a It is a process of ensuring that the product

Definition product is developed as per meets the needs and expectations of
the specifications. stakeholders.

It tests the requirements,

What it tests It tests the usability, functionalities, and
architecture, design, and code
or checks for reliability of the end product.
of the software product.

It emphasizes executing the code to test the

Coding It does not require executing
usability and functionality of the end
requirement the code.
product.

A few activities involved in

The commonly-used validation activities in
verification testing are
Activities software testing are usability testing,
requirements verification,
include performance testing, system testing,
design verification, and code
security testing, and functionality testing.
verification.

Types of A few verification methods are A few widely-used validation methods are
testing inspection, code review, desk- black box testing, white box testing,
methods checking, and walkthroughs. integration testing, and acceptance testing.

Teams or The quality assurance (QA) The software testing team along with the QA
persons team would be engaged in the team would be engaged in the validation
involved verification process. process.

It targets internal aspects such

as requirements, design, It targets the end product that is ready to be
Target of test
software architecture, deployed.
database, and code.

Summary
A robust software is the one that has undergone rigorous verification and validation
processes appropriately. Such a software is most likely to bring value to the client.

References/ Reading sources /links

[Link]/software-engineering-verification-and-validation/
[Link]/software-verification-and-validation/?lang=en

45
[Link]/wiki/Software_verification_and_validation
[Link]/verification-and-validation
[Link]/blog/verification-vs-validation-in-software

46
UNIT 5: Systems Analysis

Introduction
Effective review of systems and processes can help organizations provide quality and
functional offerings that meet user needs. A systems analysis is one method technology
professionals can use to identify concerns and suggest improvements to the systems
businesses and organizations use in their operations. Learning what a systems analysis is and
how it works can help you better understand its importance and necessity. In this article, we
define a systems analysis, list some tools analysts can use to perform their analysis, explain
why this type of analysis is important and offer tips for conducting effective reviews.
Learning outcomes
By the end of this unit you should be able to:
 Define the term systems analysis
 Describe the process of analysing a system
 Carryout a proper systems analysis
 Develop a systems analysis report

What is a systems analysis?

System analysis is a review of a technological system, like a software package, for
troubleshooting, development or improvement purposes. Through in-depth analysis,
analysts can uncover errors in code, accessibility issues for end-users or design
incompatibilities. Performing an effective systems analysis often requires experts to have
knowledge of a software product's or package's requirements so that they can approach
their analysis effectively. Unlike systems administrators, who focus on day-to-day system
maintenance, systems analysts consider the viability and effectiveness of a product overall.
This allows them to suggest changes or make fixes that improve the system.
With a systems analysis, considering the goals of the system is important for solving
problems and creating efficiencies. From there, dividing a system into components can make
it easier to perform individual analyses that influence the complete system.

What processes and techniques can you use for a systems analysis?
There are many tools and techniques you can use to perform a systems analysis effectively.
Often, taking a systematic approach and viewing systems with their end users and end goals
in mind can help you find relevant and worthwhile solutions. Here are some techniques to
focus on as you begin your systems analysis:
Create user interface (UI) mockups

47
A UI mockup is a tool analysts can use to better understand how a user might interact with a
system. To accomplish this, you can download prototyping tools or simply do a dashboard
sketch to visualize the system from the user's perspective. UI mockups can also be a great
tool if you're performing an analysis with a team because they can help facilitate
communication and new ideas.
Define system usage patterns
When performing an analysis, it's often important to outline user actions and patterns
within the system. This can help you focus on important system aspects that may see a lot of
use. Consider the users who are going to use the system and what their goals might be. By
following their probable user paths, you can ensure the system functions smoothly and
supports user goals.
Perform a feasibility analysis
Feasibility analyses help test systems for their workability and impact on an organization. In
a feasibility study, you consider factors like cost, organizational impact, user experience and
resource use effectiveness. By examining these key areas, you can ensure your analysis is
comprehensive.

Why is systems analysis important?

A systems analysis is important for many reasons. Here's a closer look at a few:
Improves the user experience
Effective analysis often looks at a system from the end user's perspective. It's important for
providers to maintain accessible systems that are easy to navigate and meet user
requirements. Conducting a review from the end-users perspective can alert providers to
potential problems in a software or product offering. For example, an analyst might discover
an error that prevents users from completing specific actions successfully. By finding these
errors, they can make adjustments that ensure the system functions as it's meant to for
users.
Reduces errors or inefficiencies
A systems analysis can also help determine if a system is efficient or viable. By looking at the
overall architecture of the system, analysts can assess its performance and workability. From
there, they can make suggestions about ways to improve the system or enhance its
operation.
Identifies potential issues in code
Analysis usually requires an in-depth review of a system's code. Often, errors in a system's
functions originate from its source code. Bugs or improperly typed code can cause a system
to behave in a way that differs from its intended function. By finding these errors, it's easier
for system creators to remedy bugs and fix coding inconsistencies.

48
Helps businesses improve their systems
Sometimes, businesses hire analysts to review their systems. The improvements, changes
and recommendations analysts provide can help businesses improve efficiency and keep
their systems running effectively. This can lower costs associated with troubleshooting or
system downtime. It can also ensure businesses consider every factor associated with their
system, like usability, performance, scaling and business impact.

Here are some additional tips that can help ensure your systems analysis is successful:
Approach analysis from a user perspective
Ultimately, systems exist to serve set purposes and to support specific user activities. By
considering the user in your analysis, you can ensure you're prioritizing end-user goals and
the user experience. Usage patterns, user requirements and system functionality are all
important aspects to address when you take this perspective.
Consider system goals
Another important consideration when performing your analysis is the system's goals.
Approaching problem-solving efforts from this perspective is important for delivering a
product that accomplishes what the system's owners are looking for in their offering.
Ultimately, it's important to promote systems that are functional, efficient and viable for
meeting specific criteria. Start your process by outlining the top goals for the systems. By
approaching an analysis with a set framework, you can better focus your efforts and
facilitate the development of a better product.
Evaluate the functionality of specific solutions
Whenever you propose a new solution or suggest an improvement to the system, evaluate
the functionality of the solution against your system goals and user goals. Often, there are
multiple solutions to a set problem or concern, but only one or a few that best support the
system's objectives and intended use. Try to maintain a consistent perspective on the entire
system, even as you analyze specific components. This can help ensure your analysis efforts
contribute to a more functional system overall.

Summary
Systems analysis helps the software development team to understand the processes in the
client organization. This understanding will enable them to identify weaknesses and
strengths of that system paving way to solutions on improving the status quo. Once the
processes are known, the developers are better positioned to develop a system that
addresses the exact needs of the client.

References/ Reading sources /links

49
[Link]/blog/what-is-system-analysis-steps-importance-implementation
[Link]/images/documents/informatics-institute/Competitive_exam/
[Link]
[Link]/system_analysis_and_design/
system_analysis_and_design_overview.htm
[Link]/learn/lesson/[Link]
[Link]/career-advice/career-development/what-is-system-analysis

50
UNIT 6: Software project management
Introduction
Software engineering is a process which needs proper management. It is therefore not
enough for the developer to be able to build a software product. The engineer should be
able to use management principles and technique to ensure efficacy of the process. Because
of this, the software development process as a project needs proper management. This
brings us to the idea of software project management.
Learning outcomes
By the end of this unit you should be able to:
 Define software project management
 Outline main activities in managing a software project
 Articulate principles of proper project management.

Abbreviations and Acronyms

 PSP – Program system product
 ICT – Information communication technologies
We begin our expedition in software project management by taking a look at the three terms
that sound familiar at this stage of your programme. These terms are:
Software
Project and
Management
Software: We may all be familiar with software as computer programs which refer to the
instructions that are given to a computer for it to be able to perform a certain specific
function. With your exposure to programming, you are likely to think that software is coded
instructions. In software project management we expand the concept of program to program
system product (PSP).
A computer program is always complete by itself. You remember that in programming, we
write code, compile it and then run the program. Once the program is free of errors, we can
give it inputs and produce outputs. In other words, we do not need other programs to run it
other than the appropriate compiler. In PSP, we extend this concept to encompass other
programs. Each program is viewed as a component of an integrated system of programs
(Think of the relationship between software engineering and systems engineering). There
must be a well-defined interface to which all the programs in the unified system have to
comply. Each program should have a fair share of resources. We test each program together
with other programs.

51
Associated with the term program system products, we have program product. This comes as
an extension of the idea of a program - A program can be run, tested, repaired and extended
by anyone other than the author. A program product has the following characteristics:
 Runs on different platforms
 The product accommodates a wide range of data.
 The range and form of input should be generalized
 The product must test the validity of the inputs and provide reasonable response to
invalid input.
 Product documentation must be made available.
Program system product now includes all aspects of program system and program product.
Note: In software project management we have to think of program system product not just
programs. This way we can include critical aspects of software project management such as:
 Time
 Cost
 Schedule
 Quality e.t.c.

Next, let us look at the term project.

Project – A project can be defined simply as any undertaking. In SPM the meaning extends
to an undertaking that involves more than one person and is worthwhile undertaking.
A project is generally defined as a programme of work that brings about a beneficial change
and has the following:

 Start and end dates

 A multi-disciplinary team
 Constraints of cost, time and quality
 A unique scope that involves uncertainty.
A project differs from any other work in the sense that a project is not a continuous process
e.g. the development of an ICT policy is a project whereas the subsequent day to day
implementation of the policy is not a project.

Activity: List as many project examples as you can.

The last term to look at before we formally define software project management is
management.

Activity: attempt a definition for the term management

Management – Projects are not just carried out in any way one wants but rather are planned.
The plan contains at least the following:

52
  Specific work to be done
 Project deliverables
 Resources needed that include
 People
 Schedule
 Budget
Activity:
 Give the meaning of deliverable.
 Why do we need a schedule in developing a software product?
 What skills are needed to manage people?
 Why is it important to be prudent in managing a budget for a software project?

Any project therefore needs to be managed at least to open and maintain communication
between the people. The management function therefore makes sure that the project process
is smooth and within budget. Factors involved include:
 Control leads to quality
 Management ensures that what was promised is delivered.
 Proper allocation of resources
 Communicate and facilitate communication
Software project management definition
Massimo Felici (2006) defines software project management as part of software engineering
concerned with activities involved in ensuring that software is delivered on time and on
schedule and in accordance with the requirements of the organizations developing and
procuring the software. Hence the success of any project is usually measured using these
three criteria (budget, quality and time).

Activity: Read on the magic triangle of software project management and comment on it.

Software project management becomes of paramount importance because software

development is always subject to budget and schedule constraints that are set by the
organization developing the software.
Bad management always leads to project failure i.e. software delivered late, costs more than
originally estimated and failing to meet its requirements. On the other hand good
management does not guarantee project success.

Activity: Justify the statement that ‘good management does not guarantee project success but
bad management always leads to project failure’.

Poor management can decrease productivity more rapidly than any other factor.

53
The success of a software project is mostly attributed to the talent of the software project
manager.
Why software project management?
 Software products are intangible; it is easy to claim say 80% completion of a
software project even if there is no tangible evidence.
 They are uniquely flexible
 The software development process is not standardized
 Large software projects are often one-of projects (bespoke) hence it is difficult to
accrue experience.
 Technology changes so quickly. Most large software projects employ new
technology.
 Therefore it is difficult to measure progress in software projects

Software project management activities

 Project planning
 Project scheduling
 Risk management
 Managing people

Activity: In brief, explain what is done in each of the above activities.

Management activities
A software project manager is concerned with the following activities:
 Project proposal writing i.e. getting approval for the project.
 Selecting the leading team and setting individual objectives
 Ensuring proper feasibility study
 Ensuring project planning in detail
 Allocating and monitoring the work and cost
 Motivating the team
 Project monitoring and reviews
 Personnel selection and evaluations
 Report writing and presentations
 Helping the team to solve project problems
 Achieve the project goals through the team.
Fecili (2006) puts these activities as the role of the project manager as follows:
 Estimation of the project effort, time and cost
 Planning- scheduling deliverables, review points and allocation of staff to activites.
 Re-planning- re-estimating and rescheduling in the light of unfolding circumstances,
e.g. risks and quality assurance results..
 Organisation- the establishment of division of labour which is able to make the most
effective use of available skills and maximizing productivity potential in the context
of characteristics of the project.

54
  Quality assurance- planning and carrying out actions to ensure that the software
product meets required quality targets.
The project manager therefore must have or develop the following skills:
 Individual skills – good presentation skills, persuasive skills, good writing skills,
goal oriented, high energy (intellectual energy and commitment to deliver) and
credibility.
 Team skills – appreciate the different needs and potential of individuals at different
levels of the project. He/she must be aware of different team types.
 Technical skills.

Why do software projects fail?

Software projects like any other type of project may fail. The failure of projects has certain
factors in common. The following are some of the factors that can make a project fail.
• People begin programming before they understand the problem
– Everyone likes to feel that they’re making progress
– When the team starts to code as soon as the project begins, they see immediate gains
– When problems become more complex (as they always do!), the work gets bogged
down
– In the best case, a team that begins programming too soon will end up writing good
software that solves the wrong problem
• The team has an unrealistic idea about how much work is involved.
– From far away, most complex problems seem simple to solve
– Teams can commit to impossible deadlines by being overly optimistic and not
thinking through the work
– Few people realize the deadline is optimistic until it’s blown
• Defects are injected early but discovered late.
– Projects can address the wrong needs
– Requirements can specify incorrect behavior
– Design, architecture and code can be technically flawed
– Test plans can miss functionality
– The later these problems are found, the more likely they are to cause the project to fail
• Programmers have poor habits – and they don’t feel accountable for their work.
– Programmers don’t have good control of their source code
– Code written by one person is often difficult for another person to understand

55
 – Programmers don’t test their code, which makes diagnosing and fixing bugs more
expensive
– The team does not have a good sense of the overall health of the project.
• Managers try to test quality into the software.
– Everyone assumes that the testers will catch all of the defects that were injected
throughout the project.
– When testers look for defects, managers tell them they are wasting time.
– When testers find defects, programmers are antagonized because they feel that they
are being personally criticized.
– When testers miss defects, everyone blames them for not being perfect.
How can we make sure that our projects succeed?
• Make sure all decisions are based on openly shared information
– It’s important to create a culture of transparency, where everyone who needs
information knows where to find it and is comfortable looking at it.
– All project documents, schedules, estimates, plans and other work products should be
shared with the entire team, managers, stakeholders, users and anyone else in the
organization who wants them.
– Major decisions that are made about the project should be well-supported and
explained.
• Don’t second-guess your team members’ expertise
– Managers need to trust team members.
– Just because a manager has responsibility for a project’s success, it doesn’t mean that
he’s more qualified to make decisions than the team members.
– If you don’t have a good reason to veto an idea, don’t.
• Introduce software quality from the very beginning of the project
– Review everything, test everything.
– Use reviews to find defects – but don’t expect the review to be perfect.
– Use reviews to gain a real commitment from the team.
– It’s always faster in the long run to hold a review than it is to skip it.
• Don’t impose an artificial hierarchy on the project team
– All software engineers were created equal.
– A manager should not assume that programming is more difficult or technical than
design, testing or requirements engineering.

56
 – Managers should definitely not assume that the programmer is always right, or the
tester is always raising false alarms.
• Remember that the fastest way through the project is to use good engineering practices
– Managers and teams often want to cut important tasks – especially estimation,
reviews, requirements gathering and testing.
– If it were faster to build the software without these practices, we would never use
them.
– Every one of these practices is about saving time and increasing quality by planning
well and finding defects early. Cutting them out will cost time and reduce quality.
Who needs software?
• Most software is built in organizations for people with specific needs.
– A stakeholder is a anyone who has an interest (or stake) in the software being
completed
– A user is someone who will need to use the software to perform tasks.
– Sometimes stakeholders will be users; but often the stakeholder will not use the
software.
For example, a senior manager (like a CEO in a company) will usually have a stake in the
software that is built (since it affects the bottom line), even if she won’t ever use it.
Who builds software?
• Software is typically built by a team of software engineers, which includes:
– Business analysts or requirements analysts who talk to users and stakeholders, plan
the behavior of software and write software requirements
– Designers and architects who plan the technical solution
– Programmers who write the code
– Testers who verify that the software meets its requirements and behaves as expected

Vision and Scope Document

57
Activity: Give the relationship between a vision and a scope document in a software
project.

A typical vision and scope document follows an outline like this one:
1. Problem Statement
a) Project background
b) Stakeholders
c) Users
d) Risks
e) Assumptions

Activity: For each of the components listed above explain the content.

2. Vision of the Solution

a) Vision statement
b) List of features
c) Scope of phased release (optional)
d) Features that will not be developed

Activity: Give the reason why scoping phased releases is optional.

Project Planning
The project plan defines the work that will be done on the project and who will do it.
Project planning is the most time-consuming project management activity. Developing a
realistic project plan is very important if one has to gain an understanding of the resources
required in the project and how these should be applied.
Planning has to be continuous i.e. from the initiation phase to the delivery of the software
product. A reasonable plan must be regularly revised as new information becomes available.
A rigid plan is a good recipe for disaster.
• A project plan consists of:
– A statement of work (SOW) that describes all work products that will be produced and
a list of people who will perform that work

58
 – A resource list that contains a list of all resources that will be needed for the product
and their availability
– A work breakdown structure and a set of estimates
– A project schedule
– A risk plan that identifies any risks that might be encountered and indicates how those
risks would be handled should they occur
The project plan is made up of different types of plans all to be developed in a single project.
These types of plans include:
 Software development plan. This is the overall or central plan that describes how the
system will be developed.
 Quality assurance plan. This specifies the quality procedures and standards that are
to be used in the project.
 Validation plan. Defines how a client will validate the system that has been
developed. It consists of the approach, resources and schedule to be used during
validation.
 Configuration management plan. Describes how the system will be configured and
installed. It contains the configuration management procedures and structures to be
used in the installation.
 Maintenance plan. Explains how the system will be maintained. It predicts the
maintenance requirements of the system, maintenance costs and effort required. Types
of maintenance are also described in the same document.
 Staff development plan. A description of how the skills and experience of the
participants shall be developed.

Activity: Research on the actual structure of each of the above types of project plan

The software development plan

This is the major plan that every software project manager should develop. In most cases it is
the one that professionals refer to when they talk of a project plan. It specifies the order of the
activities that shall be carried out, resources, responsibilities and so on. The length and detail
of the project development plan depends on the size of the project. Normally large projects
require a more detailed plan so as to guide the development.

NB: The project plan forms the basis for signing contracts, making or breaking careers. This
means that the way you develop your project plan determines the future of your project.
In developing your project plan, it is important not to do the following:

 Overestimate your team’s capability. This will make you get to sign the contract but at
the end fail to deliver as expected. This does not only embarrass the project manager but
closes gates to future opportunities.
 Simply tell clients what they want to hear. It is very tempting for one to assure a client
that he/she can do whatever has been asked. But it is different when it comes to
delivering. So it better for you to be realistic and promise only what you are sure of
providing.
 Be pressured by developers. Developers may mislead you by boasting that they can do it
even in an unrealistic time frame.

59
Scoping your project

Every project has to have a scope so as to guide the development. For one to easily measure
the progress and success of the project, its scope must be clear enough. Scope defines the
boundary of the project, explaining what will be included in the system and what will not be
included. Another way of scoping the project or the problem to be solved is to specify
objectives. Objectives are expressed in general terms and in the language application domain.
In a project scope you need to identify the following:

 The customer.
 The system environment
 Necessary tools and
 Potential reuse and others.

Structure of software development plan

The project plan can variably take different forms. What is essential is that it must contain
most of the following content. Provided here is one way of structuring the document.
1. Introduction: refers to the requirements specification or system and user requirements.
2. Project organisation: provides a brief introduction of the organization, the people
involved and their specific roles.
3. Risk analysis: Specifies the key risks to the project in question.
4. Hardware and software resources: specifies the hardware and software resources that
are required for the project. Even if these or part of them are available in the
organization you still need to specify them. This makes the costing closer to realistic
and avoids resource competition and shortage at some point in the project process.
5. Work breakdown: the project is divided into activities, milestones, deliverables, and
dependencies between tasks and so on. This forms the basis of proper resource
allocation and scheduling.
6. Project schedule: Shows the activities and their time allocations (including real dates)
7. Reporting and progress measurement: specifies the mechanisms to monitor progress.

Work breakdown
A software project normally is divisible into minor activities that can be developed separately.
The project normally has to be broken down into activities. This is done in several different
ways. One of them is to break the project into;
 Work packages
 Tasks
 Deliverables
 Milestones

Work package: a work package is usually a large and logically distinct section of work. A
work package has the following characteristics:
 Has a duration of about 12 months

60
  May include multiple concurrent activities
 Independent of other activities
 It may depend on or feed into other activities
 It is typically allocated to a single team
Task: it is typically a much smaller piece of work. It is actually a part of work package that;
 Typically require about 3-6 person months effort,
 May or may not depend on other concurrent activities
 It is normally allocated a single person.
Deliverable: is an output of the project that can meaningfully be assessed. Examples of
deliverables are specification document, code and design document.
A deliverable is an indicator of progress. If you manage to produce the deliverable at the
stipulated time then you are on target.
Milestone: is a point at which progress on the project maybe assessed, it is typically a major
turning point in the project. A milestone may at times coincide with a deliverable.
It is easy to read project documentation when the following nomenclature is used;
 Numbering work packages as WP1, WP2…WPn
 Tasks as T1, T2, T3…Tn
 Deliverables as D1, D2, … Dn
 Milestones as M1, M2 … Mn
Each work package and task usually has
 A brief description
 Earliest start date
 Earliest end date
 Total person months effort
 Prerequisite WPs or tasks
 Dependent WPs or tasks
 Who is responsible

Estimation
Activity: What is estimation in software development and why is it necessary?

61
What is estimation?
• The project manager must set expectations about the time required to complete the
software among the stakeholders, the team, and the organization’s management.
• If those expectations are not realistic from the beginning of the project, the stakeholders
will not trust the team or the project manager.
Elements of a Sound Estimate
• To generate a sound estimate, a project manager must have:
– A work breakdown structure (WBS), or a list of tasks which, if completed, will produce
the final product
– An effort estimate for each task
– A list of assumptions which were necessary for making the estimate
– Consensus among the project team that the estimate is accurate
Assumptions Make Estimates More Accurate
• Team members make assumptions about the work to be done in order to deal with
incomplete information
– Any time an estimate must be based on a decision that has not yet been made, team
members can assume the answer for the sake of the estimate
– Assumptions must be written down so that if they prove to be incorrect and cause the
estimate to be inaccurate, everyone understands what happened
– Assumptions bring the team together very early on in the project so they can make
progress on important decisions that will affect development
Wideband Delphi
• Wideband Delphi is a process that a team can use to generate an estimate
– The project manager chooses an estimation team, and gains consensus among that
team on the results
– Wideband Delphi is a repeatable estimation process because it consists of a
straightforward set of steps that can be performed the same way each time

The Wideband Delphi Process

• Step 1: Choose the team

62
 – The project manager selects the estimation team and a moderator. The team should
consist of 3 to 7 project team members.
• The moderator should be familiar with the Delphi process, but should not have a
stake in the outcome of the session if possible.
• If possible, the project manager should not be the moderator because he should
ideally be part of the estimation team.
• Step 2: Kickoff Meeting
– The project manager must make sure that each team member understands the Delphi
process, has read the vision and scope document and any other documentation, and is
familiar with the project background and needs.
– The team brainstorms and writes down assumptions.
– The team generates a WBS with 10-20 tasks.
– The team agrees on a unit of estimation.
• Step 3: Individual Preparation
– Each team member independently generates a set of preparation results.
– For each task, the team member writes down an estimate for the effort required to
complete the task, and any additional assumptions he needed to make in order to
generate the estimate.
• Step 4: Estimation Session
– During the estimation session, the team comes to a consensus on the effort required
for each task in the WBS.
– Each team member fills out an estimation form which contains his estimates.
– The rest of the estimation session is divided into rounds during which each
estimation team member revises her estimates based on a group discussion.
Individual numbers are not discussed.
– The moderator collects the estimation forms and plots the sum of the effort from
each form on a line:

63
 • Step 4: Estimation Session (continued)
– The team resolves any issues or disagreements that are brought up.
• Individual estimate times are not discussed. These disagreements are usually
about the tasks themselves. Disagreements are often resolved by adding
assumptions.
– The estimators all revise their individual estimates. The moderator updates the plot
with the new total:

• Step 4: Estimation Session (continued):

– The moderator leads the team through several rounds of estimates to gain
consensus on the estimates. The estimation session continues until the
estimates converge or the team is unwilling to revise estimates.
• Step 5: Assemble Tasks
– The project manager works with the team to collect the estimates from the
team members at the end of the meeting and compiles the final task list,
estimates and assumptions.
• Step 6: Review Results
– The project manager reviews the final task list with the estimation team.

Other Estimation Techniques

• PROBE, or Proxy Based Estimating
– PROBE is based on the idea that if an engineer is building a component
similar to one he built previously, then it will take about the same effort as it
did in the past.
– Individual engineers use a database to maintain a history of the effort they
have put into their past projects.
– A formula based on linear regression is used to calculate the estimate for each
task from this history.

64
 • COCOMO II
– In Constructive Cost Model, or COCOMO, projects are summarized using a
set of variables that must be provided as input for a model that is based on the
results of a large number of projects across the industry.
– The output of the model is a set of size and effort estimates that can be
developed into a project schedule.
• The Planning Game
– The Planning Game is the software project planning method from Extreme
Programming (XP), a lightweight development methodology developed by
Kent Beck in the 1990s at Chrysler.
– It is a full planning process that combines estimation with identifying the
scope of the project and the tasks required to complete the software.
– The Planning Game is highly iterative. The scope is established by having
Development and Business work together to interactively write “user stories”
written on index cards to describe the scope. Each story is given an estimate of
1, 2 or 3 weeks. This process is repeated continuously throughout the project.

Critical Paths
The pre-requisites and dependencies of WPs and tasks determine a critical path: the sequence
of dependencies in the project.
A critical path is a sequence of activities that takes the longest time to complete.
Any delay to any activity in the critical path will always cause a delay to the overall project.
Delays to the activities not on the critical path need not necessarily cause overall delays.

Activity: Identify one method of determining a given project's critical path.

Demonstrate the process with a given or arbitrary project of your choice. Project
schedules

The definition of project scheduling

• The project schedule is a calendar that links the tasks to be done with the resources that
will do them.
– Before a project schedule can be created, the project manager must have a work
breakdown structure (WBS) and estimates.
– The schedule is part of the project plan.

Scheduling concepts

65
Effort vs. Duration
• Effort represents the work required to perform a task.
– Effort is measured in person-hours (or person-days, person-weeks, etc.)
– It represents the total number of hours that each person spent working on the task.
• Duration is amount of time that elapses between the time the task is started and the
time it is completed.
– Duration is measured in hours (or days, weeks, etc.)
– It does not take into account the number of people performing the task
Slack and Overhead
• Slack is the amount of time which any of the tasks can be delayed without causing the
due date of the final task in the sequence to be delayed as well.
– A tight schedule has very little slack; a delay in any task will cause a delay in the
due date
– Parkinson’s Law: “Work expands so as to fill the time available for its completion.”
• Overhead is any effort that does not go to the core activities of the task but is still
required in order for the people to perform it—a sort of “real world” cost of actually
doing the work.
– Two people performing a task will require more effort than one person doing the
same task
– Assigning two people to the task requires more effort, but the task has a shorter
duration
Building the project schedule
• Allocate resources
– For each task in the WBS, one or more resources must be assigned
– Choose person or people for each task based on qualifications, familiarity and
availability
– Take overhead into account when calculating the duration of each task
• Identify dependencies
– A task has a dependency if it involves an activity, resource or work product which
is subsequently required by another task
– Tasks may have dependencies because they require the same resource
• Identify dependencies (continued)

66
 – Every dependency has a predecessor, or a task that must be begun, in progress, or
completed, for another task to begin
– Identify the type of predecessor for each dependency

• Create the schedule

– Most project schedules are represented using a Gantt chart
– The Gantt chart shows tasks, dependencies and milestones using different shapes

• Reconcile the schedule with the organization’s needs

– Once resources are allocated to each task, a final date can be calculated
– If this date is unacceptable, the project plan must change
– Either additional resources must be allocated to the project or the scope must be cut
down

67
 – Brooks’ Law: “Nine women cannot have a baby in one month.”
• In other words, some tasks can only be done by one person, no matter
how critical they are.
• Add review meetings to the schedule
– Progress reviews are meetings held regularly to check the progress of a project
versus its scheduled progress.
– Milestone reviews are meetings which the project manager schedules in advance
to coincide with project events.
• The most common way for project managers to handle milestone reviews is
to schedule them to occur after the last task in a project phase (such as the
end of design or programming).
• Step 4: Optimize the schedule
– The critical path is the sequence of tasks that represent the minimum time
required to complete the project.
• If a task is only on the critical path when delaying that task will delay the
project.
• Allocating resources to tasks on the critical path will reduce the project
schedule; allocating them to other tasks will have less effect.
– A resource is over-allocated if more than 100% allocated to multiple tasks
simultaneously
• If any resource is over-allocated, it means that there is a dependency between
two tasks which was not discovered.
• When this happens, the schedule is guaranteed to be inaccurate. Find and fix
over-allocated resources.

Don’t abuse buffers

• A buffer is a task added to the schedule with no specific purpose except to account for
unexpected delays.
– This practice involves either adding extra tasks or padding existing tasks at
strategic points in the schedule where overruns are “expected”.
– Buffers can be useful:
• On a year-long project, every programmer will take two weeks of vacation
• Buffers can be used to account for this known delay
– Buffers are often abused

68
 • The idea that overruns are expected means that there is an implicit assumption
that the estimate is incorrect.
• Buffers should not be used to add time to compensate for an inaccurate
estimate.

Project metrics
• The baseline is the version of the schedule that has been approved
– The schedule will change based on the actual work done by the project team.
– When the deadline of the revised schedule is later than that of the baseline, the
project has slipped.
• Variance is the difference between the estimated effort in the baseline and the actual
effort performed by the team.
• Earned value management tracks the project by considering effort “earned” against a
budget only after it has actually been performed
– The budgeted cost for work scheduled (BCWS) is the estimated effort of the actual
tasks that appear on the schedule to date.
– The actual cost of work performed (ACWP) is the effort spent on the tasks in the
schedule that have actually been completed by the development team members.
– Variance = BCWS – ACWP
• The cost performance index is used to compare projects with each other or to compare
phases within a project
– CPI is calculated by dividing BCWS / ACWP (budgeted cost for work
scheduled/actual cost for work performed) and multiplying by 100 to express it as a
percentage.
– A CPI of 100% means that the estimated cost was exactly right and the project
came in exactly on budget.
– A CPI under 100%, the work cost less effort than planned; a CPI greater than 100%
means that the estimate was not adequate for the work involved.
• For example, if the programming tasks took twice as long as estimated but every
other type of task in the project took less time than estimated, the total variance
for the project might still be low. However, the problem can still be pinpointed
by calculating the CPI for each phase of development.

In software project management we normally use Gantt Charts and Activity network
diagrams to show project schedules.

69
Activity: Draw a Gantt Chart and the corresponding activity network for a selected
software project.

Reviews
• A review is any activity in which a work product is distributed to reviewers who
examine it and give feedback.
– Reviews are useful not only for finding and eliminating defects, but also for
gaining consensus among the project team, securing approval from stakeholders,
and aiding in professional development for team members.
– Reviews help teams find defects soon after they are injected making them cost less
to fix than they would cost if they were found in test.
– All work products in a software project should be either reviewed or tested.
• Software requirements specifications, schedules, design documents, code, test
plans, test cases, and defect reports should all be reviewed.

Types of Review

Activity: What is a review in software development? Name any types that you know.

Inspections
• Inspections are moderated meetings in which reviewers list all issues and defects they
have found in the document and log them so that they can be addressed by the author.
• The goal of the inspection is to repair all of the defects so that everyone on the
inspection team can approve the work product.
– Commonly inspected work products include software requirements specifications
and test plans.
• Running an inspection meeting:
– A work product is selected for review and a team is gathered for an inspection
meeting to review the work product.
– A moderator is chosen to moderate the meeting.
– Each inspector prepares for the meeting by reading the work product and noting
each defect.

70
 – In an inspection, a defect is any part of the work product that will keep an inspector
from approving it.
– Discussion is focused on each defect, and coming up with a specific resolution.
• It’s the job of the inspection team to do more than just identify the problems; they
must also come up with the solutions.
– The moderator compiles all of the defect resolutions into an inspection log
Desk checks
• A deskcheck is a simple review in which the author of a work product distributes it to
one or more reviewers.
– The author sends a copy of the work product to selected project team
members. The team members read it, and then write up defects and comments
to send back to the author.
• Unlike an inspection, a deskcheck does not produce written logs which can be
archived with the document for later reference.
• Deskchecks can be used as predecessors to inspections.
– In many cases, having an author of a work product pass his work to a peer for
an informal review will significantly reduce the amount of effort involved in
the inspection.
Walkthroughs
• A walkthrough is an informal way of presenting a technical document in a meeting.
– Unlike other kinds of reviews, the author runs the walkthrough: calling the
meeting, inviting the reviewers, soliciting comments and ensuring that
everyone present understands the work product.
– Walkthroughs are used when the author of a work product needs to take into
account the perspective of someone who does not have the technical expertise
to review the document.
– After the meeting, the author should follow up with individual attendees who
may have had additional information or insights. The document should then be
corrected to reflect any issues that were raised.
Code Review
• A code review is a special kind of inspection in which the team examines a sample of
code and fixes any defects in it.
– In a code review, a defect is a block of code which does not properly
implement its requirements, which does not function as the programmer
intended, or which is not incorrect but could be improved
• For example, it could be made more readable or its performance could
be improved

71
 – It’s important to review the code which is most likely to have defects. This
will generally be the most complex, tricky or involved code.
– Good candidates for code review include:
• A portion of the software that only one person has the expertise to
maintain
• Code that implements a highly abstract or tricky algorithm
• An object, library or API that is particularly difficult to work with
• Code written by someone who is inexperienced or has not written that
kind of code before, or written in an unfamiliar language
• Code which employs a new programming technique
• An area of the code that will be especially catastrophic if there are
defects
Pair Programming
• Pair programming is a technique in which two programmers work simultaneously at a
single computer and continuously review each others’ work.
• Although many programmers were introduced to pair programming as a part of
Extreme Programming, it is a practice that can be valuable in any development
environment.
• Pair programming improves the organization by ensuring that at least two
programmers are able to maintain any piece of the software.
• In pair programming, two programmers sit at one computer to write code. Generally,
one programmer will take control and write code, while the other watches and
advises.
 Some teams have found that pair programming works best for them if the pairs
are constantly rotated; this helps diffuse the shared knowledge throughout the
organization. Others prefer to pair a more junior person with a more senior for
knowledge sharing.
• The project manager should not try to force pair programming on the team; it helps to
introduce the change slowly, and where it will meet the least resistance.
• It is difficult to implement pair programming in an organization where the
programmers do not share the same nine-to-five (or ten-to-six) work schedule.
Note: Some people do not work well in pairs, and some pairs do not work well together.
Software Requirements
• Software requirements are documentation that completely describes the behavior that is
required of the software-before the software is designed built and tested.
– Requirements analysts (or business analysts) build software requirements
specifications through requirements elicitation.

72
 • Interviews with the users, stakeholders and anyone else whose perspective needs
to be taken into account during the design, development and testing of the
software
• Observation of the users at work
• Distribution of discussion summaries to verify the data gathered in interviews

Discussion Summary
• A requirements analyst can use a discussion summary to summarize information
gathered during elicitation and validate it through a review.
• Notes gathered during the elicitation should fit into the discussion summary template
• The discussion summary outline can serve as a guide for a novice requirements
analyst in leading interviews and meetings
Discussion Summary outline
1. Project background
a) Purpose of project
b) Scope of project
c) Other background information
2. Perspectives
a) Who will use the system?
b) Who can provide input about the system?
3. Project Objectives
a) Known business rules
b) System information and/or diagrams
c) Assumptions and dependencies
d) Design and implementation constraints
4. Risks
5. Known future enhancements
6. References
7. Open, unresolved or TBD issues
Use Cases

73
 • A use case is a description of a specific interaction that a user may have with the
system.
• Use cases are deceptively simple tools for describing the functionality of the software.
– Use cases do not describe any internal workings of the software, nor do they
explain how that software will be implemented.
– They simply show how the steps that the user follows to use the software to do his
work.
– All of the ways that the users interact with the software can be described in this
manner.

Activity: Draw a use case for a selected software development project

Functional Requirements
• Functional requirements define the outward behavior required of the software project.
– The goal of the requirement is to communicate the needed behavior in as clear
and unambiguous a manner as possible.
– The behavior in the requirement can contain lists, bullets, equations, pictures,
references to external documents, and any other material that will help the
reader understand what needs to be implemented.
Activity: identify at least two functional requirements for any project of your choice.
Nonfunctional Requirements
• Nonfunctional requirements define characteristics of the software which do not
change its behavior.
– Users have implicit expectations about how well the software will work.
– These characteristics include how easy the software is to use, how quickly it
executes, how reliable it is, and how well it behaves when unexpected
conditions arise.
– The nonfunctional requirements define these aspects about the system.
• The nonfunctional requirements are sometimes referred to as “non-
behavioral requirements” or “software quality attributes”
Activity: List at least two non-functional requirements for a chosen software project.

Software Requirements Specification

74
Activity: What is the meaning of requirements specification?
• The software requirements specification (SRS) represents a complete description of
the behavior of the software to be developed.
• The SRS includes:
– A set of use cases that describe all of the interactions that the users will have with the
software.
– All of the functional requirements necessary to define the internal workings of the
software: calculations, technical details, data manipulation and processing, and other
specific functionality that shows how the use cases are to be satisfied
– Nonfunctional requirements, which impose constraints on the design or
implementation (such as performance requirements, quality standards or design
constraints).

Requirements vs. Design

Activity: How do requirements affect the design of a software project?

• Many people have difficulty understanding the difference between scope,

requirements and design.
– Scope demonstrates the needs of the organization, and is documented in a
vision and scope document
– Requirements document the behavior of the software that will satisfy those
needs
– Design shows how those requirements will be implemented technically

Change Control
• Change control is a method for implementing only those changes that are worth
pursuing, and for preventing unnecessary or overly costly changes from derailing the
project.
– Change control is an agreement between the project team and the managers
that are responsible for decision-making on the project to evaluate the impact
of a change before implementing it.
– Many changes that initially sound like good ideas will get thrown out once the
true cost of the change is known.
• A change control board (CCB) is made up of the decision-makers, project manager,
stakeholder or user representatives, and selected team members.

75
 – The CCB analyzes the impact of all requested changes to the software and has
the authority to approve or deny any change requests once development is
underway.
– Before the project begins, the list of CCB members should be written down
and agreed upon, and each CCB member should understand why the change
control process is needed and what their role will be in it.
• Whenever a change is needed, the CCB follows the change control process to
evaluate the change:
– The potential benefit of the change is written down, and the project manager
works with the team to estimate the potential impact that the change will have
on the project.
– If the benefit of the change is worth the cost, the project manager updates the
plan to reflect the new estimates. Otherwise, the change is thrown out and the
team continues with the original plan.
– The CCB either accepts or rejects the change.

Design and Programming

Activity: How does design influence programming in a software project?

Review the Design

• Once the SRS has been approved, implementation begins. Programming teams have
many options:
– The programmers can simply start building the code and create the objects and
user interface elements.
– Designers can build a user interface prototype to demonstrate to the users,
stakeholders and the rest of the team. Any code used to develop the prototype
is typically thrown away once the design has been finalized.
– Pictures, flow charts, data flow diagrams, database design diagrams and other
visual tools can be used to determine aspects of the design and architecture.

76
 – An object model can be developed on paper, either using code, simple class
diagrams or Unified Modeling Language (UML) diagrams.
– A written design specification may be created, which includes some or all of
the tools above.
• Design tasks should always include reviews, even when there is no written design
specification.
• Any written documentation should be reviewed and, if possible, inspected.
– It is important that the reviews and inspections reach the correct audience.
– Many users who have important input for the user interface may be
uninterested or confused by object models and UML diagrams.

Version Control

Activity: What is a version in software development?

• A version control system allows programmers to keep track of every revision of all
source code files
– The main element of the version control system is the repository, a database or
directory that contains each of the files contained in the system.
– A programmer can pick a point at any time in the history of the project and see
exactly what those files looked like at the time.
– It is always possible to find the latest version of any file by retrieving it from
the repository.
– Changing a file will not unexpectedly overwrite any previous changes to that
file; any change can be rolled back, so no work will accidentally be
overwritten.
• There are two common models for version control systems
– In a copy-modify-merge system, multiple people can work on a single file at a
time.
• When a programmer wants to update the repository with his changes,
he retrieves all changes which have occurred to the checked out files
and reconciles any of them which conflict with changes he made
before updating the repository.
– In a lock-modify-unlock system, only one person can work on any file at a
time.

77
 • A programmer must check a file out of the repository before it can be
modified. The system prevents anyone else from modifying any file
until it is checked back in.
• On large projects, the team can run into delays because one
programmer is often stuck waiting for a file to be available.
Refactoring
• Refactoring is a programming technique in which the design of the software is
improved without changing its behavior.
– There are many choices that programmers make which do not affect the
behavior of the software but which can have an enormous impact on how easy
the code is to read and understand.
– Refactoring works especially well during code reviews.
– Because refactoring is a change to the design, it may impact the design review
process. If previously reviewed code is refactored, changes to that should be
distributed to the review team.
Unit Testing
• Before a build is delivered, the person or program building the software should
execute unit tests to verify that each unit functions properly.
– All code is made up of a set of objects, functions, modules or other non-trivial
units. The purpose of unit testing is to create a set of tests for each unit to
verify that it performs its function correctly.
– Programmers create suites of unit tests, where each test is a small block of
code which exercises a specific behavior of one unit.
– The most common (and effective) way for programmers to do unit testing is to
use a framework, a piece of software that automatically runs the tests and
reports the results.
Everyone is responsible for quality
• different kinds of testing serve different purposes.
– Programmers use unit tests is to verify that the software works exactly as the
programmer intended.
– Software testers are responsible for verifying that the software meets its
requirements (in the SRS) and the needs of the users and stakeholders (in the
Vision and Scope Document).
• Many defects arise when a programmer delivers software that worked
as he intended, but did not meet the needs of the users. Software testers
can catch these problems.
• Many programmers are confused about exactly what it is that software testers do.

78
 – All they know is that they deliver a build to the QA team. The QA people run
the program and find bugs, which the programmers fix.
– It is often hard for them to figure out where unit testing ends and functional
testing begins.
– The project manager should watch for this confusion, and help to clarify it by
making sure that the programmers understand what kinds of testing are
expected of them.
Project Automation
• Many quality problems happen because the team does not build the software
consistently, and loses track of the health of the code.
• Effective project automation reduces these errors. The team can adopt a tool which:
– Retrieves the latest build from the version control system, builds it, copies it to
a folder, and reports any build warnings or errors
– Runs unit tests, generating a test report and reporting critical failures
– Runs automated code review tools, reporting any warnings or rule violations
– Lists any changes which have been committed and by whom, including links
to code listings for the changes
Software Testing
Quality: Quality means “conformance to requirements”
– The best testers can only catch defects that are contrary to specification.
– Testing does not make the software perfect.
– If an organization does not have good requirements engineering practices then
it will be very hard to deliver software that fills the users’ needs, because the
product team does not really know what those needs are.
Test Plans
• The goal of test planning is to establish the list of tasks which, if performed, will
identify all of the requirements that have not been met in the software. The main work
product is the test plan.
– The test plan documents the overall approach to the test. In many ways, the
test plan serves as a summary of the test activities that will be performed.
– It shows how the tests will be organized, and outlines all of the testers’ needs
which must be met in order to properly carry out the test.
– The test plan should be inspected by members of the engineering team and
senior managers.
Test Cases

79
• A test case is a description of a specific interaction that a tester will have in order to test
a single behavior of the software. Test cases are very similar to use cases, in that they are
step-by-step narratives which define a specific interaction between the user and the
software.
– A typical test case is laid out in a table, and includes:
• A unique name and number
• A requirement which this test case is exercising
• Preconditions which describe the state of the software before the test case
(which is often a previous test case that must always be run before the current
test case)
• Steps that describe the specific steps which make up the interaction
• Expected Results which describe the expected state of the software after the test
case is executed
• Test cases must be repeatable.
– Good test cases are data-specific, and describe each interaction necessary to
repeat the test exactly.
Test Execution
• The software testers begin executing the test plan after the programmers deliver the
alpha build, or a build that they feel is feature complete.
– The alpha should be of high quality—the programmers should feel that it is
ready for release, and as good as they can get it.
• There are typically several iterations of test execution.
– The first iteration focuses on new functionality that has been added since the
last round of testing.
– A regression test is a test designed to make sure that a change to one area of
the software has not caused any other part of the software which had
previously passed its tests to stop working.
– Regression testing usually involves executing all test cases which have
previously been executed.
– There are typically at least two regression tests for any software project.
Defect Tracking
• The defect tracking system is a program that testers use to record and track defects. It
routes each defect between testers, developers, the project manager and others,
following a workflow designed to ensure that the defect is verified and repaired.
– Every defect encountered in the test run is recorded and entered into a defect
tracking system so that it can be prioritized.

80
 – The defect workflow should track the interaction between the testers who find
the defect and the programmers who fix it. It should ensure that every defect
can be properly prioritized and reviewed by all of the stakeholders to
determine whether or not it should be repaired. This process of review and
prioritization referred to as triage.
Smoke Tests
• A smoke test is a subset of the test cases that is typically representative of the overall
test plan.
– Smoke tests are good for verifying proper deployment or other non invasive
changes.
– They are also useful for verifying a build is ready to send to test.
– Smoke tests are not substitute for actual functional testing.
Test Automation
• Test automation is a practice in which testers employ a software tool to reduce or
eliminate repetitive tasks.
– Testers either write scripts or use record-and-playback to capture user
interactions with the software being tested.
– This can save the testers a lot of time if many iterations of testing will be
required.
– It costs a lot to develop and maintain automated test suites, so it is generally
not worth developing them for tests that will executed only a few times.
Postmortem Reports
• The postmortem report is an overall account of the team’s experience in building the
software, and of the experience of the users and stakeholders in working with the
team.
– The report should contain an honest assessment of how the team members,
users, and stakeholders perceived the end product, and assessed the decisions
made throughout the project.
– The purpose of the post-mortem report is to highlight the team’s successes and
identify any problems which should be fixed in future releases.

How to diagnose and fix a troubled software project

Lack of Leadership
• It takes more than a talented and motivated team to make a successful project.
• Lack of leadership manifests itself in the team members suffering from:

81
 – Tunnel vision
– Over-reliance on gut instincts
– Repeated false starts in the project
The Mid-Course Correction
• A change in project priorities throws the team into disarray
• This usually comes from a lack of understanding of the scope of the project
• When the engineers don’t understand the users’ and stakeholders’ needs, they build
the wrong software
– And they might not find out that there’s a problem until after the work is done!
The Detached Engineering Team
• There is an artificial wall between the people who build the software and those who
need it.
– The business people feel like the engineers are moving too slowly and don’t care
about their needs
– The engineers feel like they’re always shooting at a moving target because business
people don’t know what they want
Fixing Planning Problems
• Lack of Leadership, the Mid-Course Correction and the Detached Engineering Team
are project planning problems
– Use a vision and scope document to define the needs of the users and stakeholders
– Use a project plan to keep every informed about how those needs will be met
– Use risk planning to keep the plan realistic
Padded Estimates Generate Distrust
• Programmers add extra time to their estimates
– They may do this because of unknowns
– Often they have been late in the past, and “know” that they will need extra time
• Project managers and senior managers quickly figure this out, and start to question
individual estimates
– And the programmers don’t have good answers!

Self-Fulfilling Prophecy
• A project manager under pressure simply imposes a deadline, and creates unrealistic
estimates that meet it

82
 • The team works nights and weekends to meet the deadline
• The project manager feels vindicated
The team eventually gets frustrated and disillusioned.

Fixing Estimation Problems

• Padded estimates and the self-fulfilling prophecy are estimation problems
– Adopting a repeatable estimation process like Wideband Delphi can help fix them
– By writing down assumptions, the team can handle risks without padding their time –
and even avoid the risks altogether
– It reduces padding and increases honesty through transparency, by letting the team
correct each other in an open meeting

Working Backwards From a Deadline

• Project managers approach a non-negotiable deadline for a project by working
backwards
– They shorten the tasks in the schedule or cutting them entirely until everything fits
– When the schedule gets tight, any non-programming activities are cut and the
software is released before it’s finished

Misunderstood Predecessors
• The project manger does not take the time to understand how tasks depend on each
other
• Problems are discovered partway through the project one task can’t be started because
it depends on another
• Delays cascade through the project, getting increasingly worse
• Some programmers are stuck waiting with nothing to do, while others work overtime

Fixing Scheduling Problems

• Working backwards from a deadline and misunderstood predecessors are symptoms
of underlying scheduling problems
– They can be avoided by adopting good planning and estimation practices and
creating a project schedule
– Schedule techniques like critical path analysis can help spot problems early on

83
Problems Are Found Too Late
• There are preventable defects in the software that aren’t caught until late in the project
– The team may misunderstand a need, but that’s not discovered until delivery
– Requirements may be missed or incorrect
– The design may be difficult to use or fail to take all of the features into
account

Big, Useless Meetings

• A project manager who has previously been burned by problems that were found too
late is determined to avoid falling into the same trap
– He calls a big meeting with everyone who could possibly have input
– The meeting drags on for hours, without making any real progress
– Eventually, everyone gives up and goes back to the way they did things before

The Indispensable “Hero”

• One “critical” person is seen as the clear top programmer, and all important work is
sent through him
– He may have a unique skill or experience
– Sometimes he hoardes information so all tasks that rely on it must go through
him
– He is always working long hours – and causing bottlenecks
Fixing Review Problems
• Problems that are found too late, big useless meetings, and the indispensable “hero”
are problems which can be solved with reviews
– Reviews can catch defects early, when they are cheaper to fix
– A review meeting only includes the people necessary for the work to be done
– Reviews – especially code reviews – can help the “hero” spread his expertise
and knowledge

Iteration Abuse
• Iteration can be a useful tool, but it is often abused

84
 • The team uses iteration as a “guessing game”
– Programmers deliver build after build; users and stakeholders make small
changes to each build
– Programmers like it because they can dive in
– Users and stakeholders like it because they don’t have to read documents or
think about their needs
Scope Creep
• After the programming has started, users and stakeholders make changes
• Each change is easy to describe, so it sounds “small” and the programmers agree to it
• Eventually, the project slows to a crawl
– It’s 90% done – with 90% left to go
– The programmers know that if they had been told from the beginning what to
build, they could have built it quickly from the start

Fixing Requirements Problems

• When software requirements are not gathered and specified before the software is
developed, it causes scope creep and the team resorts to iteration abuse.
– The team can adopt software requirements engineering practices to write down
most of the changes before the work begins
– A change control process gives them a handle on the few changes that remain

Haunted by Ghosts of Old Problems

• Programmers find that old bugs suddenly reappear without warning
– As the code base grows, it becomes harder to keep control of the source code
– They may use a shared folder to store source code, but occasionally old copies
of files are copied over newer ones
Broken Builds
• The programmers deliver a build which does not work – and the testers can’t even
begin to test it
– The programmers get frustrated because they feel that they put a lot of effort
into testing the build
– “Isn’t it the job of the QA team to figure out the build is broken and tell them
what to fix?”

85
 – The testers spend hours or days setting up a test environment, only to redo it
for the next build.
Spaghetti Code
Maintaining old code is the least desirable programming job in many organizations
– Old, highly modified code turns into a twisted mess of execution paths and
patches
– Spaghetti code is often used as an excuse to do an unnecessary rewrite
Fixing Programming Problems
• When the team adopts good programming habits, they can avoid ghosts of old
problems, broken builds and spaghetti code.
– Get control of the source code with version control software like Subversion
– Use unit tests and test-driven development to increase the quality of the build
– Use refactoring to keep the code readable
1. Requirements Haven’t Been Implemented
• The team delivers software missing behavior or even entire features
– Software is complex, and even with good review practices, it’s difficult for
programmers to fully implement everything
– Missing requirements are difficult to spot because even the programmer
missed them when looking over his own work
2. Obvious Bugs Slipped Through
• Inexperienced testers are expected to just “bang on the software”
• Technical support staff, junior programmers, end users, outside temps and sales
people are drafted as “testers”
• Even when experienced testers are used, they are not given time to plan
• Decisions about release readiness are made based on the schedule, rather than the
quality
3. “But It Worked For Us!”
• When a product is not tested in all environments in which it will be used, the
tests will be thrown off
• Defects are missed when testers can’t adequately replicate the environment in
which the software will be used
• Test data may not resemble actual production data
4. Fixing Testing Problems

86
 • When code is delivered with too few requirements implemented and too many
bugs included, the team needs better testing practices.
– Software testers must be involved in every stage of development
– Test planning must be given adequate time on the schedule
– Sufficient budget must be provided for a testing environment.
5. Common Problems Can Be Avoided!
• Almost everyone has experienced at least a few of these problems.
• We know what causes them, and we have tools, techniques and practices that can
fix them.
• All it takes is good project management and sound software engineering… and
any project team can do it!
Understanding Change
Why Change Fails
• The short answer: politics
– Many project problems are bigger than just your project
– You have to make changes to the way people in your organization work
– Your ideas on how to improve the way work is done will not always be
evaluated rationally
Change is Uncomfortable
• Nobody likes to think that they make mistakes
• Making changes means talking about past mistakes – and admitting that they are
mistakes!
• You may make a great case for change, and still fail to convince people to do it.
• Because change is uncomfortable, people in organizations will resist it.
• Project managers who try to change their organizations run into several common
excuses when trying to implement tools, techniques and practices.
We Already Build Software Well
• “This is just the way software projects always go.”
– People know that there are problems with the schedule and quality, but think
that nobody ever does any better
• If you bring up past failures, you are trying to blame people
• This leads to an environment where it’s not possible to admit that projects go wrong

87
“Not Invented Here” Syndrome
• People intentionally avoid research or innovations that were not developed within the
organization
– Yes, NIH syndrome really happens!
• The idea that “we’re different” leads to immediate resistance to outside ideas
In some small organizations, it’s even worse: “Our ‘quirks’ mean we’re better.”
It’s “Too Theoretical”
• When ideas don’t make intuitive sense, they are dismissed as merely academic
• Many “hands-on” managers must personally see a practice in place before they will
accept its value
• Especially common in small teams facing growing pains
It Just Adds More Bureaucracy
• Any work other than programming is wasteful “busywork” that keeps the “real work”
from getting done.
– “If I just add more programmers, it will fix all of our schedule and quality
problems!”
• Planning the project, writing down requirements, and holding inspection meetings is
seen as just pushing paper around.
You Can’t Give Me More Work!
• Asking someone to review a document or make an estimate is asking them to do more
work.
• When you change the way other people work, they may just say no.
• For no good reason.
• And if they have more power than you, they may get their way.
It’s Too Risky
• A manager who backs a change puts his reputation on the line.
• It’s safer to let a project fail in a way it’s failed before than to make a change that
might not work.
– “Too risky” means risk to the manager, and usually not risk to the project.
How to Make Change Succeed
• Progress comes from making smart changes
• Understand how people in your organization think about and react to changes
– Prepare your organization

88
 – Sell your change
– Account for common excuses in your “pitch”
Prepare Your Organization
• “We’ve always done it like this.”
• Be positive about the work that’s already being done
• Take credit for the changes
• Make the changes seem straightforward
• Build support from the team
• Show that the changes will save time and effort
• Work around stragglers
• Stick to the facts
Plan for Change
• Create a vision and scope document
– Similar to the document for software projects, except it describes the scope of
the change
– Inspect and approve the document to build consensus
– Add the changes to the schedule
Push for Consensus
• Get project team members on board first.
– Managers are more likely to approve a change if the entire team (especially
the programming staff) is behind it.
• Help people recognize the problem, and then show that you have a solution.
• Organizations do not change overnight.
Management and Leadership
Responsibility, authority and accountability
• A person has responsibility for a task if:
– He is given sufficient authority to perform it
– He is accountable for its completion
• A person has authority to perform a task only if he is has adequate control over the
resources necessary to complete the task.

89
 • A person is accountable for a task if failure to adequately perform that task carries
professional consequences.
Delegation
• Delegation is assigning responsibility of a task to a team member.
• When delegating a task, the project manager must ensure that the team member has
the authority to perform it and is accountable for the results.
Transparency
When the project manager creates a document, holds a meeting of interest to others, or makes
an important project decision, all of the information produced should be shared and used with
everyone involved in the project.
• All work products should be public
– All team members, senior managers and stakeholders should have access to
every work product produced for the project.
– Project managers and team members benefit because they make more
informed decisions.
– Senior managers and stakeholders are always kept informed.
• Decisions should be made based on known guidelines
– Published standards documents help others understand the way certain roles
must be filled.
– Documents should be based on templates when possible.
– Process documents ensure that each project is done using a repeatable process.
– Use performance plans to set expectations for individual team members.
Manage the Organization
• Prevent senior managers from seeing software projects as a cost burden
– A project is successful if its costs are justified by its benefits.
– Establishing a track record of successful projects is the most effective way for
a project manager to reverse dangerous attitudes in senior management.
• Show senior managers the impact of their decisions
– Decisions are frequently made based on gut feelings instead of objective
analysis.
– The people making decisions about the project need to understand the details.
– Show senior managers that improving project management practices will help
them meet their goals.
• Don’t confuse flexibility with always saying yes

90
 – Don’t agree to an unrealistic schedule.
– Change your approach when necessary.
– Don’t confuse “easy to describe” with “easy to implement.”
Manage Your Team
• Avoid common management pitfalls
– Don’t manage from your gut.
– Don’t second-guess estimates.
• Remember Brooks’ Law: “Adding manpower to a late software project
makes it later.”
– Don’t expect consensus all of the time.
– Make your mistakes public.
– Accept criticism.
• Avoid micromanagement
– Don’t expect to review everything
– Don’t fall into the “hands-on manager” trap
– Use transparency to your advantage
– Don’t be afraid to let your team members make mistakes
• Address performance problems early
– Work with each team member to develop a performance plan.
– Set standards that are fair and attainable.
– Measure each team member’s progress against known and agreed-upon goals.
– Correct performance problems as early as possible.
Managing an Outsourced Project
Prevent Project Failure
• Don’t be a hands-off client
• Constantly communicate project goals
– The vendor’s goals always differ from the clients
– Don’t expect the team to ignore the vendor’s goals
– Work with the team to establish the goals of the project as an equal or greater
priority

91
 • Transparency is especially important in an outsourced project.
Estimate the Work
• Vendors often estimate the work as part of contract negotiation
– This happens before the team is assigned.
– When the project team is assembled, it may be necessary to re-estimate the
work.
– Unrealistic estimates cause projects to fail.
Actively Manage the Project
• A hands-off project manager is usually surprised when the software is delivered
– And the surprise is never a pleasant one.
• It’s not enough to just have weekly status meetings with no follow-up
– Project managers need to know the team.
– Just like an in-house project!
The Vendor’s Management
• Build a relationship with the vendor’s management
– If they don’t support the project manager’s goals or trust his decisions, the
project will likely fail.
– Don’t allow the vendor’s escalation process to interfere with the project.
– Make sure the management at the vendor recognizes and rewards good work.
The Project Team
• Build a relationship with the team
– A project manager doesn’t have the same kind of relationship with the team
that he would with a team in his own organization.
– The project manager isn’t always right! The team does not report to him.
– Gain credibility by making good decisions.
Collaborate With the Vendor
• Plan and manage the project scope
– The project starts with a scope and a budget.
• As opposed to an in-house project, which starts with a set of known
resources.
– Plan for knowledge transfer.

92
 – Recognize that success for the project manager and success for the vendor are
often two different things.

Maintain Tracking and Oversight

• Don’t depend on the vendor to maintain the project plan and project schedule
– When a project manager is responsible for the project, he must keep track of
its status himself.
• Hold reviews and inspections
– Use a collaborative inspection process that has been optimized for outsourced
projects.
Design and Programming
• Don’t delegate the entire design and programming of the project to the vendor
– Establish design constraints early on.
– If possible, design the software in-house, or in collaboration with the vendor.
– Monitor the code base using code reviews and project automation.
Software Quality
• Take responsibility for the quality of the software
– Quality is not just another deliverable that can be bought and paid for.
– Don’t make decisions that undercut the QA team.
– Ensure that adequate time and budget is allocated for test planning and
execution.
Don’t Blindly Trust the Vendor
• Even though individual team members may have certifications or degrees, it doesn’t
mean that they are competent.
• Just because the vendor’s organization is certified, that doesn’t guarantee that they
know better than you do how to run your project.
• Don’t be intimidated by the vendor’s pedigree. If something on the project looks
wrong, it probably is!
Process Improvement
Life Without a Formal Process
• Many process improvement experts see the world as black and white.
– They often feel that there are bad software teams without a formal process,
and good teams that have one in place.

93
 – But the world is not that simple!
• Teams can be effective without a formal software process
– Teams can consist of “jack-of-all-trades” programmers who understand the
business of the organization.
– “Skunk works” programmers may often take initiative and build useful
software without input.
– A highly capable development manager may be willing to put in an enormous
effort.
• An organization that produces software always has a software process
– It’s just not formal, or documented and repeatable
– And teams without a formal process can be happy and productive when they
can point to their successes!
– Except when their projects fail.
• A team without a formal process does not scale up easily.
– Programmers who used to produce lots of software find that their projects
have started to feel “bogged down.”
– This often happens when a small programming group with a good track record
is faced with having to build a project on a larger scale.
– It also happens when teams expand.
• If there are no complaints about the way the team is building software, then there’s no
reason to change!
– However, few teams are really in this situation for long.
• Expanding the team is not the only place a formal process is useful.
– It can also help in an organization where experts, users, or stakeholders are no
longer readily available to the programmers.
Software Process Improvement
• Software process improvement is the art and science of changing an organization’s
software process in order to build better software.
• Software process improvement always involves looking at the big picture.
– This means writing down the entire software process as a whole and making
sure that it is followed on each project.
– It involves looking at entire projects and identifying areas that can be
improved.
Frameworks and Methodologies

94
 • Models and certifications that help assess the state of the organization’s process and
serve as a framework for improving that process.
– CMM, ISO 9000 and Six Sigma are frameworks
• There are also methodologies that an organization can adopt that describe the
complete set of activities, roles, and work products needed to build software.
– Rational Unified Process and Extreme Programming are methodologies.
Capability Maturity Model
• The CMM defines the characteristics of a mature, capable process in a way that can
be measured and compared to processes at other organizations.
– The CMM consists of areas of improvement, goals that must be met for each
area, and specific practices to be implemented.
– A software engineering process group within the organization identifies
problems and inefficiencies and defines practices to address them.
– Independent assessors verify that an organization is in compliance with CMM
practices.
ISO 9000
• ISO 9000 is a family of quality management standards defined by the International
Standards Organization. It is based on core principles:
– Organizations must focus on their customers by understanding current and
future customer needs.
– Leaders within the organization must create and maintain an environment in
which people can become involved and fulfill the organization’s objectives.
– People at all levels are important to the organization.
– Activities and resources are best managed as a process.
– Organizations have many interrelated processes, which must be understood
and managed as a system.
– The organization should continually improve its performance.
– Decisions should be well informed and based on real data and information.
– An organization and its suppliers are in a mutually beneficial relationship.

Six Sigma
• Six Sigma is an approach to improving quality in manufacturing and business
processes.
– The Greek letter sigma refers to standard deviation—Six Sigma means “six
standard deviations from the mean.”

95
 • DMAIC is a five-phase approach to Six Sigma improvement
– Define opportunities, Measure performance, Analyze opportunity, Improve
performance, Control performance
Extreme Programming
• XP consists of a set of rules and practices that govern all areas of software
development: planning, designing, coding, and testing.
– The goal of XP is to lower the cost of change. To meet this goal, many XP
practices are highly iterative.
– XP is a disciplined and well-defined process.
– By making the stakeholders part of the project team, XP addresses the problem
of the hands-off customer.
Rational Unified Process
• RUP is a popular off-the-shelf process based on the idea of highly iterative
development
– One thing that makes RUP unique is that it is a product in addition to a
process.
• RUP includes a disciplined approach to requirements management that is based on the
idea of managing changes.
– RUP incorporates software design using the Unified Modeling Language
(UML), a visual modeling system for graphically representing the use cases,
class model, object interactions, and components of the software.
• One core element of RUP is the continuous assessment of the quality of the system.

References
Pankaj J (2008), Software Project Management in practice, Addison-
Wesley Professional.
• Andrew S, Greene J (2005) Applied Software Project Management.
O’Reilly Media Incl.
• Masamha T , Software project management module
• Ian Sommerville (2011) Software engineering 9th Edition
[Link]
need-to-know/
[Link]/software-development-life-cycle-sdlc/
[Link]/software-testing-life-cycle-stlc/

96
[Link]/blog/software-testing-life-cycle/
[Link]/blog/software-testing-life-cycle-stlc-phases/
[Link]/software-engineering-verification-and-validation/
[Link]/differences-between-verification-and-validation/
[Link]/verification-and-validation-testing
[Link]/software-engineering-software-review/
[Link]/software-engineering-software-review/
[Link]/software-technical-reviews-in-software-testing/

97