UNIT 3 SOFTWARE PROJECT MANAGEMENT, SCHEDULING AND QUALITY

ASSURANCE
(Weightage- 16 , Hrs- 08)

3.1 The Management Spectrum: The people, The product, The Process, The project

The Management Spectrum:

In software engineering, the management spectrum describes the management of a software
project.

The management of a software project starts from requirement analysis and finishes based on
the nature of the product, it may or may not end because almost all software products faces
changes and requires support.

It is about turning the project from plan to reality.

The management spectrum focuses on the four P’s; people, product, process and project.

Here, the manager of the project has to control all these P’s to have a smooth flow in the
progress of the project and to reach the goal.

The four P’s of management spectrum are

1. People
2. Product
3. Process
4. Project

The four P’s of management spectrum has been described briefly in below.
The People:

 People of a project includes from manager to developer, from customer to end

user.
 But mainly people of a project highlight the developers.
 It is so important to have highly skilled and motivated developers that the Software
Engineering Institute has developed a People Management Capability Maturity Model
(PM-CMM),
The Product:
The product is the ultimate goal of the project.
This is any types of software product that has to be developed.
To develop a software product successfully, all the product objectives and scopes should be
established, alternative solutions should be considered, and technical and management
constraints should be identified beforehand.
Lack of these information, it is impossible to define reasonable and accurate estimation of
the cost, an effective assessment of risks, a realistic breakdown of project tasks or a
manageable project schedule that provides a meaningful indication of progress.
The Process:
A software process provides the framework from which a comprehensive plan for software
development can be established.
A number of different tasks sets— tasks, milestones, work products, and quality assurance
points—enable the framework activities to be adapted to the characteristics of the software
project and the requirements of the project team.
Finally, umbrella activities overlay the software process model. Umbrella activities are
independent of any one framework activity and occur throughout the process.
The Project:
The project is the complete software project that includes requirement analysis, development,
delivery, maintenance and updates. The project manager of a project or sub-project is
responsible for managing the people, product and process. The responsibilities or activities of
software project manager would be a long list but that has to be followed to avoid project
failure.

A software project could be extremely complex and as per the industry data the failure rate is
high. Its merely due to the development but mostly due to the steps before development and
sometimes due to the lack of maintenance.

Decomposition Techniques-LOC and FP based estimation, COCOMO model

Decomposition Techniques:
 Decomposition techniques works on “Divide and Conquer” approach in
software project estimation.
 By decomposition a project is divided into different components and related
software engineering activities.
 Cost and effort estimation can be performed step by step on each component.
 Software cost estimation is a form to solve the problems.
 Most of the times problem to be solved is too complex to be solve in a single
step.
 Than the problem is decomposed in to number of components in order to
achieve an accurate cost estimate.

There are two approaches in decomposition technique:

1. Problem based estimation

2. Process based estimation

Estimation is the process of finding an estimate, or approximation, which is a value

that can be used for some purpose even if input data may be incomplete, uncertain,
or unstable.
Estimation determines how much
 money,
 effort,
 resources,
 time
it will take to build a specific system or product.

What to Estimate?

Estimation is based on −

 Past Data/Past Experience

 Available Documents/Knowledge
 Assumptions
 Identified Risks

The four basic steps in Software Project Estimation are −

 Estimate the size of the development product.

 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

LOC-based Cost Estimation

The LOC (Line of Code) is a product size metric in software engineering.

Here, the number of lines in the code are counted and based on the number of lines
the cost is calculated.
 There is no definite clear picture of how to count number of lines because the length
and complexity of the code is different in different languages.
It only depends on the length but not on complexity and functionality.

Consider one more example with code snippet:

From the above example we have

• 2 physical lines of code.
• 2 logical line of code (printf statement and for statement)
• 1 comment line

The same code snippet can be written in a different style

There are
• 5 physical line of code.
• 2 non statement lines
• 1 comment line.

The problems of lines of code (LOC)

 Different languages lead to different lengths of code
 It is not clear how to count lines of code
 A report, screen, or GUI generator can generate thousands of lines of code in minutes
 Depending on the application, the complexity of code is different.

 FPA provides a standardized method to functionally size the software work

product.
 This work product is the output of software new development and improvement
projects for subsequent releases.
  It is the software that is relocated to the production application at project
implementation. It measures functionality from the user’s point of view i.e. on the
basis of what the user requests and receives in return.
 Function Point Analysis (FPA) is a method or set of rules of Functional Size
Measurement.
 It assesses the functionality delivered to its users, based on the user’s external
view of the functional requirements.
 It measures the logical view of an application, not the physically implemented view
or the internal technical view.
 The Function Point Analysis technique is used to analyze the functionality delivered
by software and Unadjusted Function Point (UFP) is the unit of measurement.

Steps to compute function point:

• When function is invoked, read some input data and transform it to

corresponding output data.

Example the issue book feature of a library automation software takes the name

of the book as input and displays its location and the number of copies available.

• Beside using the number of the input and output data values function point

metric computes the size of a software product (in unit of function points or FPs.)

Objectives of FPA:
 The objective of FPA is to measure the functionality that the user requests and
receives.
 The objective of FPA is to measure software development and maintenance
independently of the technology used for implementation.
 It should be simple enough to minimize the overhead of the measurement
process.
 It should be a consistent measure among various projects and organizations.

Types of FP Attributes

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces Shared databases and shared

(EIF) routines.

 All these parameters are then individually assessed for complexity.

Types of FPA:

 Transactional Functional Type –

 External Input (EI): EI processes data or control information that
comes from outside the application’s boundary. The EI is an
elementary process.

 External Output (EO): EO is an elementary process that generates

data or control information sent outside the application’s boundary.

 External Inquiries (EQ): EQ is an elementary process made up of an

input-output combination that results in data retrieval.

 Data Functional Type –

 Internal Logical File (ILF): A user identifiable group of logically
related data or control information maintained within the boundary
of the application.

 External Interface File (EIF): A group of users recognizable logically

related data allusion to the software but maintained within the
boundary of another software.

Benefits of FPA:
  FPA is a tool to determine the size of a purchased application package by
counting all the functions included in the package.
 It is a tool to help users discover the benefit of an application package to their
organization by counting functions that specifically match their requirements.
 It is a tool to measure the units of a software product to support quality and
productivity analysis.
 It s a vehicle to estimate the cost and resources required for software
development and maintenance.
 It is a normalization factor for software comparison.

The drawback of FPA:

 It requires a subjective evaluation and involves many judgements.
 Many cost and effort models are based on LOC, so it is necessary to change the
function points.
 Compared to LOC, there are less research data on function points.
 Run after creating the design spec.
 With subjective judgement, the accuracy rate of the assessment is low.
 Due to the long learning curve, it is not easy to gain proficiency.
 This is a very time-consuming method.

COCOMO model:

Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.

COCOMO is one of the most generally used software estimation models in the
world. COCOMO predicts the efforts and schedule of a software product based on
the size of the software.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded
1.Organic: A development project can be treated of the organic type, if the project
deals with developing a well-understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar methods of projects.

Examples of this type of projects are simple business systems, simple

inventory management systems, and data processing systems.

2. Semidetached: A development project can be treated with semidetached type if

the development consists of a mixture of experienced and inexperienced staff.
Team members may have finite experience in related systems but may be unfamiliar
with some aspects of the order being developed.

Example of Semidetached system includes developing a new operating

system (OS), a Database Management System (DBMS), and complex inventory
management system.

3. Embedded: A development project is treated to be of an embedded type, if the

software being developed is strongly coupled to complex hardware, or if the
stringent regulations on the operational method exist.

For Example: ATM, Air Traffic control.

Risk Management: Software risk, Risk Identification, RMMM (Risk Mitigation,
Monitoring and Management)

What is Risk?

"Tomorrow problems are today's risk."

Hence, a clear definition of a "risk" is a problem that could cause some loss or
threaten the progress of the project, but which has not happened yet.

These potential issues might harm cost, schedule or technical success of the project
and the quality of our software device, or project team morale.

Risk Management is the system of identifying addressing and eliminating these

problems before they can damage the project.

Risk Management

A software project can be concerned with a large variety of risks.

In order to be adept to systematically identify the significant risks which might affect
a software project,

it is essential to classify risks into different classes. The project manager can then
check which risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks- Project risks concern various sorts of monetary funds,

schedules, personnel, resource, and customer-related issues.
 2. Technical risks-Technical risks concern potential style, implementation,
interfacing, testing, and maintenance issues.
3. Business risks- This type of risk embodies the risks of building a
superb product that nobody needs, losing monetary funds or personal
commitments, etc.

A risk management technique is usually seen in the software Project plan.

This can be divided into Risk Mitigation, Monitoring, and Management Plan
(RMMM).
In this plan, all works are done as part of risk analysis.
As part of the overall project plan project manager generally uses this
RMMM plan.
In some software teams, risk is documented with the help of a Risk
Information Sheet (RIS).
This RIS is controlled by using a database system for easier management of
information i.e creation, priority ordering, searching, and other analysis. After
documentation of RMMM and start of a project, risk mitigation and monitoring
steps will start.

Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.

1. Finding out the risk.

2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout
the project.
Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task
is done by Project manager when risk becomes reality and causes severe
problems.
If the project manager effectively uses project mitigation to remove risks
successfully then it is easier to manage the risks.
This shows that the response that will be taken for each risk by a manager.
The main objective of the risk management plan is the risk register.
This risk register describes and focuses on the predicted threats to a
software project.
 Project Scheduling - Basic principles of scheduling

Project Scheduling :-
•Project scheduling is an activity that distributes estimated effort across the planned
project duration by allocating the effort to specific software engineering tasks.
•One view is that the end-date for the software release is set externally and that the
software organization is constrained to distribute effort in the prescribed time frame.
•Another view is that the rough chronological bounds have been discussed by the
developers and customers, but the end-date is best set by the developer after carefully
considering how to best use the resources needed to meet the customerʼs needs.
Software Project Scheduling Principles:-
•Compartmentalization - the product and process must be decomposed into a
manageable number of activities and tasks.
• Interdependency: - tasks that can be completed in parallel must be separated from
those that must completed serially.
• Time allocation - every task has start and completion dates that take the task
interdependencies into account.
• Effort validation - project manager must ensure that on any given day there are enough
staff members assigned to completed the tasks within the time estimated in the project
plan.
• Defined Responsibilities - every scheduled task needs to be assigned to a specific team
member.
• Defined milestones - a milestone is accomplished when one or more work products
from an engineering task have passed quality review.

Project Tracking- Timeline chart, Gantt chart

 Gantt chart is a type of a bar chart that is used for illustrating project schedules.
 Gantt charts can be used in any projects that involve effort, resources, milestones
and deliveries.
 At present, Gantt charts have become the popular choice of project managers in
every field.
 Gantt charts allow project managers to track the progress of the entire project.
 Through Gantt charts, the project manager can keep a track of the individual tasks
as well as of the overall project progression.
 In addition to tracking the progression of the tasks, Gantt charts can also be used
for tracking the utilization of the resources in the project. These resources can be
human resources as well as materials used.
 Gantt chart was invented by a mechanical engineer named Henry Gantt in 1910.
Since the invention, Gantt chart has come a long way. By today, it takes different
forms from simple paper based charts to sophisticated software packages.

As it's in a bar chart format it is possible to check on progress with a quick

glance. You can easily see:

 a visual display of the whole project,

 timelines and deadlines of all tasks,
 relationships and dependencies between the various activities,
 project phases

Timeline Gantt Chart

Start and end date of
yes yes
the project
Milestones yes no
Responsibilities no yes
Dependencies of
no yes
tasks
Budget no no
if you want to show the complexity of
a brief overview and your project is your project and which tasks depend
Examples very simple and straightforward, a on others to be completed first, a
timeline would be enough Gantt chart is the best way to
showcase this.
ISO 9000 Certification
Six Sigma in Software Engineering
 Six Sigma is the process of producing high and improved quality
output.
 This can be done in two phases – identification and elimination.
 The cause of defects is identified and appropriate elimination is done
which reduces variation in whole processes.
 A six sigma method is one in which 99.99966% of all the products to be
produced have the same features and are of free from defects.

Characteristics of Six Sigma:

The Characteristics of Six Sigma are as follows:
1. Statistical Quality Control:
Six Sigma is derived from the Greek Letter ? which denote Standard
Deviation in statistics. Standard Deviation is used for measuring the
quality of output.
2. Methodical Approach:
The Six Sigma is a systematic approach of application in DMAIC and
DMADV which can be used to improve the quality of production.
DMAIC means for Design-Measure- Analyze-Improve-Control. While
DMADV stands for Design-Measure-Analyze-Design-Verify.
3. Fact and Data-Based Approach:
The statistical and methodical method shows the scientific basis of
the technique.
4. Project and Objective-Based Focus:
The Six Sigma process is implemented to focus on the requirements
and conditions.
5. Customer Focus:
The customer focus is fundamental to the Six Sigma approach. The
quality improvement and control standards are based on specific
customer requirements.
6. Teamwork Approach to Quality Management:
 The Six Sigma process requires organizations to get organized for
improving quality.

Six Sigma Methodologies:

Two methodologies used in the Six Sigma projects are DMAIC and DMADV.
 DMAIC is used to enhance an existing business process.
 The DMAIC project methodology has five phases:
1. Define
2. Measure
3. Analyze
4. Improve
5. Control
 DMADV is used to create new product designs or process designs.
The DMADV project methodology also has five phases:
1. Define
2. Measure
3. Analyze
4. Design
5. Verify