Course Code: 20CS11P1 PRINCIPLES OF SOFTWARE PROJECT MANAGEMENT

UNIT-I (12 Lectures)

Introduction to software project management: Introduction, What is a project? Software
projects versus other types of project, Activities covered by software project management ,Plans,
methods and methodologies , Some ways of categorizing software projects.
 INTRODUCTION

Software project management involves planning, organizing, and overseeing the development and
delivery of software projects. It includes managing resources, timelines, and the overall project
scope to ensure successful completion.

Key Objectives

1. Delivering Software on Time: Ensuring the project meets deadlines.

2. Staying Within Budget: Managing resources to avoid cost overruns.
3. Meeting Requirements: Delivering a product that meets the client's needs and
specifications.
4. Maintaining Quality: Ensuring the software is reliable and performs as expected.

Why is Software Project Management Important?

Firstly, there is the question of money. A lot of money is at stake with ICT projects. In the
United Kingdom during the financial year 2002 -2003. The central government spent more on
contracts for ICT projects than on contracts related to roads (about $2.3 billion as opposed to
$1.4 billion). The biggest departmental spender was the department for work and Pensions,
who spent over $800 million on ICT. Mismanagement of ICT projects means that there is
less to spend on good things such as hospitals.

Projects are not always successful. In a report published in 2003 , the Standish Group in the
United States analysed 13,522 projects and concluded that only a third of projects were
successful; 82% of projects were late and 43% exceeded their budget.

The reason for these project short comings is often the management of projects. The National
Audit Office in the U.K, For example , among other factors causing project failure identified ‘
Lack of skills and proven approach to project management and risk management’.

Ensures Project Success

1. Meeting Deadlines: Effective project management helps ensure that software projects are
completed on time by organizing tasks, schedules, and resources efficiently.
2. Staying Within Budget: Proper management prevents cost overruns by meticulously planning and
controlling expenses throughout the project lifecycle.
3. Quality Assurance: By adhering to quality standards and practices, project management ensures
that the final software product is reliable, functional, and meets user requirements.
  WHAT IS PROJECT?

In software project management, a "project" is a temporary endeavor undertaken to create a

unique product, service, or result. The term "temporary" signifies that every project has a definite
beginning and end. The "unique product, service, or result" means that the deliverable is different
in some distinguishing way from all other products, services, or results.

Key characteristics of a software project include:

1. Objectives: Specific goals to be achieved, such as developing a new software application,

implementing a system update, or improving an existing software feature.
2. Scope: The boundaries of the project, including the work that must be done to deliver a
product, service, or result with the specified features and functions.
3. Resources: The people, equipment, and materials needed to complete the project.
4. Timeframe: A schedule that outlines when tasks will be performed and milestones
achieved.
5. Budget: The financial plan for the project, detailing the costs associated with the resources
and activities.
6. Risks: Potential issues that might arise and affect the project's success, which need to be
identified and managed.
7. Stakeholders: Individuals or groups with an interest in the project's outcome, including
project

 SOFTWARE PROJECTS VERSUS OTHER TYPES OF PROJECT

Many techniques of general project management also apply to Software Project Management.
Fred Brooks identified some characteristics of software projects which make them particularly
difficult:
1. Invisibility
With Software, progress is not immediately visible since work is logical; however, for
physical artifacts like bridges, work progress can be seen from time to time. In Software
Development, there is a level of uncertainty.

It isn't easy to accurately define detailed requirements for software projects before starting the
development. However, with the introduction of approaches like Agile and Scrum, we can
overcome this limitation.

2. Complexity
Software projects contain more complexity than other engineered artifacts. For example, in a
bridge, there is a clear structural relationship between parts, whereas software component
relationships are much more complicated. We can't measure the complexity of a software
project until we work on it.

3. Conformity
Physical systems are governed by consistent physical law, while Software developers have to
conform to the requirements of human clients.
4. Flexibility
Software systems are particularly subject to change. A bridge has to be built in a specific
order, whereas We can make Software much more flexibly and restructure parts quite freely.

Apart from the above-mentioned, Software Projects are intangible, and managing a software
project is more managing interpersonal communication and less about administration. Also, it
would be best if you had a highly skilled team of developers, QA, and another stakeholder to
develop a software project, unlike making a bridge where skills can be less or more.

 ACTIVITIES COVERED BY SOFTWARE PROJECT MANAGEMENT

A Software project is not only concerned with the actual writing of software. In fact, where a
software application is bought ‘off the shelf’ , there may be no software writing as such, but
this is still fundamentally a software project because so many of the other activities associated
with software will still be present.

Feasibility study

How do
Is it worth we do it?
doing?

Plan

Do it!

Project Execution

The Feasibility Study/Plan/Execution Cycle

1. The Feasibility Study:

 It Assess whether a project is worth starting-that it has a valid business case.
 Information is gathered about the requirements of the proposed application.
 Requirements elicitation can at least initially, be complex and difficult.
 The stakeholders may know the aims they wish to pursue, but not be sure about
the means of achievement.
 The development and operational costs and the value of the benefit of the new
system, will also have to be estimated.
  With a large system, the feasibility study could be a project in its own right with
its own plan.
2. Planning:
 If the feasibility study indicates that the prospective project appears viable, then
project planning can start.
 For larger projects, there is no detailed planning at the beginning.
 An outline map for the whole project and a detailed one for the first stage.
 More detailed and accurate project information after the earlier stages of the
project have been completed , planning of later stages is left with their start stage.
3. Project Execution:
 The project can now be executed.
 The execution of a project often contains design and implementation sub-phases.
 New to project planning often find the boundary between design and planning can
be hazy.
 Design is making decisions about the form of the products to be created.
 That is relate to the external appearance of the software i.e., the user interface , or
the internal architecture.
 The plan details the activities to be carried out to create these products.
 Planning and design can be confused because the most detailed level, planning
decisions are influenced design by decisions.
 Thus a software product with five major components is likely to require five sets of
activities to create them.
a)Requirement Analysis
Requirements analysis or requirements engineering is a process used to determine the
needs and expectations of a new product. It involves frequent communication with the
stakeholders and end-users of the product to define expectations, resolve conflicts, and document
all the key requirements
b)Architecture Design
The components of the new system that fulfil each requirement have to be identified.
Existing components may be able to satisfy some requirements. In other cases , a new component
have to be made. These components are not only software they could be new hardware or work
processes. The design of the system architecture is thus an input to the software requirements and
second architecture design process then takes place that maps the software requirements to
software components.
c)Detailed Design
Each software component is made up of a number of software units that can be separately
coded and tested. The detailed design of these units is carried out separately.
d)Code and Test
It refers to writing code for each software unit. Initial testing to debug individual software
units would be carried out at this stage.
e)Integration
The components are tested together to meet the overall requirements. Integration could
involve combining different software components, or combining and testing the software element
of the system in conjunction with the hardware platforms and user interactions.
f)Qualification Testing
The system, including the software components, has to be tested carefully to ensure that all
the requirements have been fulfilled.
g)Installation
This is the process of making new system operational. It would include activities such as
setting up standing data(for example , the details for employees in a payroll system). Setting
system parameters, installing the software onto the hardware platforms and user training.
h)Acceptance Support
This is the resolving of problems with the newly installed system, including the correction
of any errors, an implementing agreed extensions and improvements. Software maintenance can
be seen as series of minor software projects. In many environments, most software development is
in fact maintenance.
  PLANS, METHODS AND METHODOLOGIES
A Plan for an activity must be based on some idea of a method of work. For example, if you
were asked to test some software , you may know nothing about the software to bes tested ,
but you could assume that you would need to:
 Analyse the requirements for the software;
 Devise and write test cases that will check that each requirement has been satisfied;
 Create test scripts and expected results for each test case;
 Compare the actual results and the expected results and identify discrepancies.
While a method relates to a type of activity in general, a plan takes that method(and perhaps
others) and converts it to real activities, identifying for each activity:

 Its start and end dates;

 Who will carry out;
 What tools and materials-including information-will be needed.
The output from one method might be the input to another . Groups of methods or techniques
are often grouped into methodologies such as object-oriented design.

 SOME WAYS OF CATEGORIZING SOFTWARE PROJECTS

Projects may differ because of the different technical products to be created. Thus need to identify
the characteristics of a project which could affect the way in which it should be planes and managed. Other
factors are discussed below:
Compulsory versus Voluntary Users

 In workspaces there are systems that staff have to use if they want to do something, such as
recording a scale.
 However, use of a system is increasingly voluntary , as in the case of computer games.
 Here it is difficult to elicit precise requirements from potential users as could with a business
system.
 What the game will do will thus depend much on the informed ingenuity of the developers, along
with techniques such as market surveys, focus groups and prototype evaluation.
Information Systems versus Embedded Systems

 A traditional distinction has been between information systems which enable staff to carry out
office processes and embedded systems which control machines.
 A stock control system would be an information system.
 An embedded, or process control, system might control the air conditioning equipment in a
building.
 Some systems may have both where for example, the stock control system also controls an
automated warehouse.
Outsourced Projects

 While developing a large projects, sometimes, it makes good commercial sense for a company to
outsource some parts of its work to other companies.
 There can be several reasons behind such decision.
  For example, a company may consider outsourcing as a good option, if it feels that it does not
have sufficient expertise to develop some specific parts of the product or if it determines that some
parts can be developed cost effectively by another company.
 Since an outsourced project is a small part of some project, it is usually small in size and needs to
be completed within a few months.
 Considering theses differences between an outsourced project and a conventional project,
managing an outsourced project entails special challenges.
 Indian Software companies excel in executing outsourced software projects and have earned a fine
reputation in this field all over the world.
 Of late, the Indian companies have slowly begun to focus on product development as well.
 The type of development work being handled by a company can have an impact on its
profitability. For example, a company that has developed a generic software product usually gets
an uninterrupted stream of revenue over several years.
 However, outsourced projects fetch only one time revenue to any company.

Objective-driven development

 Projects may be distinguished by whether their aim is to produce a product or to meet certain
objectives.
 A project might be to create a product, the details of which have been specified by the client.
 The client has the responsibility for justifying the product.
 On the other hand, the project requirement might be to meet certain objectives which could be met
in a number of ways.
 An organization might have a problem and ask a specialist to recommend a solution.
 Many software projects have two stages:
 First is an objective-driven project resulting in recommendations. This might identify the
need for a new software system.
 The next stage is project actually to create the software product.
 This is useful where the technical work is being done by an external group and the user needs are
unclear at the outset.
 The external group can produce a preliminary design at a fixed fee.
 If the design developers can then quote a price for the second, implementation, stage based on an
agreed requirement.