Software Engineering

Module 4: Introduction to Project Management

-Anuradha Pai
Assistant Professor
BTI College of Engineering
1. Introduction to Software Project
Management
• All projects are about meeting objectives. The main aim of the project
management is to ensure all the objectives of the projects are met.
• Project Management is the discipline of defining and achieving the targets while
optimizing the use of resources(time, money, people etc.) over the course of project
( a set of activities of finite duration)
2. Why is Software Project Management
important?
• Large amount of money are spent on ICT(Information and Communication
Technology) Projects. Eg: UK government has spent 2.3 billions on contracts of
ICT project and 1.4 billions on road building
• Projects often fail. According a survey around 82% projects failed because they
were delivered late and 43% exceeded budget. Poor project management is the
main reason for the projects to fail.
3. Job Versus Project

Fig: Job versus Project

• A project is a planned activity. A software project may be developed from scratch or by
customizing an existing project.
• A project developed on an existing system will have large number of routine
jobs(repetitive tasks which are well defined and well understood)
• A non-routine project in software development refers to a project that involves tasks
and challenges that are not part of the regular, repetitive processes.
4. Characteristics of a project
• Non-routine tasks are involved.
• Planning is required.
• Aiming at a specific target
• Carried out for a customer
• Carried out by temporary work groups
• Made up of several different phases
• Constrained by time and resources
• The project can be large and/or complex
5. Why Software Project Management is
different from General Project Management?
1. Invisibility: Progress made in software projects is not immediately visible.
Software project management can be seen as a process of making invisible
visible.
2. Complexity: Software projects have more complexity when compared with
other engineered projects
3. Conformity( in accordance with): Software developers have to conform to the
requirements of the client. Due to mis communication or ineffective decisions
by organisations can lead to defective product.
4. Flexibility: In general a product after delivery is not subjected to changes. But
in software project management, software that can be easily changed is seen as
a strength. A software is expected to accommodate changes with the underlying
hardware but vice-versa is not expected.
6. Activities covered by Software Project
Management
A software project involves more than just writing the code. The following three
steps will aid in delivering a new software.
1. Feasibility Study
• This study asses whether this project will have a valid business case. The
developmental, operational cost and the value of the benefits of the new
system will be estimated.
2. Planning
• Once the project is deemed feasible, the planning phase begins. An outline
plan for the project is developed.
• For larger projects, only a small portion of the planning is completed initially,
with much of it deferred to later stages.
6. Activities covered by Software Project
Management(Contd..)
3. Project Execution
• The project can now be executed. The
execution of a project contains design
and implementation sub-phase.
• Design is making decisions about the
form of the product to be created.
This could relate to external
appearance of the product i.e. user
experience or the internal architecture.
Fig: The feasibility study/plan/execution cycle
• Planning involves a set of activities to
be carried out to deliver the final
product.
7. The Software Development Life Cycle(SDLC)
SDLC is a set of activities to be carried out to deliver a software. It encompasses
these steps:
1. Requirement Analysis: Understanding and documenting the software
requirements from stakeholders. These requirements are to be organised and
translated in a form that developers can understand.
2. Architecture Design: The components(software, hardware etc) of the new
system will be identified.
3. Detailed Design: This involves the following steps
a) Coding and testing: Writing code according to the design specifications and
performing unit tests.
b) Integration: Putting the components together
c) Qualification Testing: Testing the whole system
d) Installation: Installing the software on operational hardware.
e) Acceptance support: Includes maintenance and enhancements
7. SDLC (Contd..)

Fig: Software Development Life Cycle

8. Contract Management
9. Plans, Methods and Methodologies
• A method relates to a type of activity, a plan takes that method and converts it into
real activities. Eg: Software testing is an activity. The plan for testing a software
involves
• 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 expected results and identify discrepancies.
• The output from one method can be an input to another method. Group of methods
or techniques together form methodologies.
10. Categorizing Software Projects

Fig: Categorizing Software Projects

10. Categorizing Software Projects(Contd..)
1. Compulsory versus Voluntary users
• There are systems that staff have to use if they want to do something, such as
recording a sale.
• Computer games is an example for voluntary users
2. Information systems versus embedded systems
• Information systems which enable staff to carry out office processes. Eg: a stoc
control system
• Embedded systems control machines. Eg: Air conditioning system
3. Object Driven Development
• Projects may be distinguished by whether the aim is to produce a product or meet a
objective. A project might be to create a product, the details of which have bee
specified by the client.
• A project might be to meet certain objectives which could be done in number o
ways
10. Categorizing Software Projects(Contd..)
3. Software products versus services
• A software product development project focuses on creating software that
meets the needs of a broad customer base. The resulting software is typically
sold off the shelf to a large number of customers.
• Software services on the other hand cover different types of software projects
such as customisation, outsourcing, maintenance, testing and consultancy.
4. Outsourced projects
• While developing large projects, a company might decide to outsource some
part of the work to other organizations.
11. Project Charter
12. Stakeholders
These are the people who have interest in the project. We need to identify the
stakeholders during the initial stage of the project in order to setup adequate
communication channels. Stakeholders can be categorised as:
1. Internal to project team
2. External to project team but within the same organisation.
3. External to both the project team and the organisation. Eg: Customers
Boem and Ross proposed a “Theory of W(win-win)” of software management
where the manager concentrates on creating situations where all the parties benefit
from the project.
13. Setting Objectives
• The objectives should define what the project team must achieve for the project
success.
• A project authority has to be identified who will have an overall authority on the
project. This authority is called “Project Steering Committee” who is responsible
for setting, monitoring and modifying the objectives.
13. Setting Objectives (Contd.. )
Objectives should be SMART
1. S - Specific
Concrete and well-defined
2. M - Measurable
Ensure there are criteria to measure progress and success.
3. A - Achievable
While defining the objectives, the time and the skill set of the team is to be
considered. The objective must be achievable by the team in the given time frame.
4. R - Relevant
The objective must be relevant to the true purpose of the project
5. T - Time Constrained
Objectives must be time bound
13. Setting Objectives(Contd..)
Measure of Effectiveness
• Measures of effectiveness provide practical methods of checking whether an
objective is met.
• Example: “mtbf(Mean Time Between Failures)” metric. This metric will help in
measuring the performance of the system(the longest duration for which the
system was in working state, time duration between the failures etc.)
14. Business Case
• Projects needs to have a valid business case i.e. the effort and expense of
developing the project should be beneficial. This should be defined during the
feasibility study of the project. A cost-benefit analysis will often be a part of the
projects feasibility study.
• A business model should be created which will clearly depict the claimed benefits
• Example: Developing a web application that allows you to order the firm’s
products
15. Project Success and Failure
• The project plan should be designed to ensure project success by preserving the
business case for the project. The project is successful when project objectives are
met. The project objectives are the targets that the project team is expected to
achieve.
• Generic summary of the project objectives:
1. Delivering the agreed functionality
2. Delivering the required level of the quality
3. Delivering on time
4. Delivering within the budget
• Business objectives are different from the project objectives. In business terms a
project is considered successful if the value of benefit from the project exceeds the
cost of developing it.
15. Project Success and Failure (Contd..)
• Even though the project managers have complete control over the development
cost of the project, the profit of the project is dependent on the external factors
such as the number of customers.
• A project can be success on delivery but can be a business failure. This can be due
to late delivery of the project. Nevertheless a project could be late and over-budget
but still could generate benefits over the period of time
16. Management aspect in Software Project
Management
Software Project Management involves the following activities
16. Management aspect in Software Project
Management(Contd..)
• Project Managers time is spent on only three of the eight identified activities:
Project planning, monitoring and control. The time period during which these
activities are carried out is shown in the below figure.

Fig: Principal(Main) project management process

16. Management aspect in Software Project
Management(Contd..)
• Go through project initiation and planning from “Project Management Life Cycle”
Slide.

• Project Monitoring and control activities are undertaken after the initiation of
development activities
17. Management Control
Management involves setting objectives for a system and then monitoring the
performance of a system. Figure in the real world shows that the data is unstructured
or formless.
17. Management Control: Fig Project Control
Cycle is explained
17. Management Control(Contd.. )
18. Software Development versus Project
Management Life Cycles
• During SDLC, developers carry out several development
methodologies to deliver fully functional software.
• In contrast to SDLC, project management life cycle(PMLC) typically
starts well before the SDLC and continues for the entire duration of
SDLC. During PMLC, project managers carry out project
management activities
18. SDLC versus PMLC

Fig: Project Management Life Cycle versus SDLC

19. Project Management Life Cycle(PMLC)
The different phases in Project Management Life Cycle are
“Project Initiation, Project Planning, Project Execution and Project Closure”

Fig: Different phases of Project Management Life Cycle and SDLC

19. Project Management Life Cycle:
Initiation(PMLC)
19.1 PMLC: Initiation
W5HH Principle: Boem suggested that during the project initiation, the following
questions pertaining to the project needs to be answered
19.1 PMLC: Initiation
In the context of software project bidding, three common documents are
often used:
1. Request for Proposal (RFP)
2. Request for Information (RFI)
3. Request for Quotation (RFQ).
Each serves a distinct purpose in the procurement process.
19.1.1 Project Initiation: Request For Proposal
• An RFP is a formal document issued by an organization to gather proposals from
potential vendors or service providers.
• Purpose: To select the best vendor based on a comprehensive proposal that
outlines their approach, capabilities, and cost.
Components present in RFP Description
Project Overview Background information about the organization and the project
Objectives Clear goals and expected outcomes of the project
Scope of Work Detailed description of the tasks, deliverables, and timelines.
Requirements Technical, functional, and business requirements that must be met.
Evaluation Criteria How the proposals will be evaluated, including scoring or ranking
systems.
Submission Guidelines Instructions on how and when to submit proposals, including
formatting requirements and deadlines.
Budget Often includes budget constraints or expectations
19.1.2 Project Initiation: Request For Information
• An RFI is a preliminary document used to gather general information from
vendors about their products, services, and capabilities.
• Purpose: To gather information that helps shape a future RFP or RFQ, and to
create a shortlist of potential vendors
Components in RFI Description
Introduction Overview of the organization's needs and objectives.
Information Requested Specific questions or areas where information is needed, such as
company background, experience, and capabilities
Response Format Guidelines on how to structure responses, including any forms
or templates to be used.
Submission Details Instructions on how and when to submit the RFI response
19.1.3Project Initiation: Request for Quotation
• An RFQ is a document used to request price quotes for specific products or
services.
• Purpose: To obtain detailed pricing information from vendors to compare costs
and select a supplier based on price and terms.
Components in RFQ Description

Detailed Specifications Exact requirements for the products or services needed, often including
quantities, technical specifications, and quality standards.
Terms and Conditions Contract terms, delivery expectations, payment terms, and other conditions.

Submission Guidelines Instructions on how to submit the quotation, including deadlines.

19.2 PMLC: Planning
During the project planning phase, the project manager creates the following
documents
19.3 PMLC: Execution
• Involves implementing the project plan by developing, testing, and deploying the
software.
• This phase includes coding, integrating components, performing quality
assurance, and managing resources.
• Effective communication and coordination among team members are crucial.
• Progress is monitored to ensure alignment with project goals and timelines.
19.4 PMLC: Closure
• Project Closure involves completing the release of all the required deliverables to
the customer along with the necessary documentation
• All the project resources are released, supply agreements with the vendors are
terminated and all the pending payments are completed.
• Postimplementation review is undertaken to analyse the project performance and
list the lessons learnt for use in the future projects.
20. Traditional versus Modern Project
Management Practices(Intro)
• Hardly any software is being developed from scratch. Software
development today is either based on tailoring some existing product
or re-using certain pre-built libraries.
• Two important goals of recent software development are maximisation
of code reuse and compression of project duration. Other goals include
accommodating client feedback and incremental delivery of the
product.
20. Traditional v/s Modern Project Management
Planning Incremental Delivery Change Management (Configuration
• Traditional: Management)
• Long-term planning • Traditional: Formal, structured
process with significant
• Single Delivery at the end of the documentation and slower
project to the customer implementation.
• Modern: • Modern: Dynamic and continuous
• Short-term planning process, emphasizing flexibility,
• Extreme Project Management: stakeholder collaboration, and
Incremental project delivery with quick adaptation.
evolving functionalities to the Existence of a large number of version
customer of a product and the need to support
these has made the change management
crucial responsibility of the project
manager
20. Traditional v/s Modern Project Management
Quality Management Requirement Management
• Traditional: • Traditional: Requirements are gathered
• Quality management is a more distinct during the initial phase of the project and
and sequential process, often the scope of the project is fixed. Change
separated from the development requests from the customer after the start
phases. of the project is discouraged.
• No incremental delivery of the • Modern: Iterative and incremental
product to the customer. Hence requirement gathering with lightweight
quality feedback can be obtained only documentation and evolving scope.
after the final delivery of the product. As the requirements are changing
• Modern: continuously, requirement management has
• Quality Management is an integral become a systematic approach for
part of development process controlling changes, documenting,
• Continuous feedback from customers analyzing, prioritizing the requirements etc.
is gathered regarding the product
quality
20. Traditional v/s Modern Project Management
Release Management Risk Management
Release management concerns planning, • Traditional: Risks are identified and
prioritizing and controlling the different planned for upfront with a
releases of a software. comprehensive risk management plan
• Traditional: A single, comprehensive • Modern: Risks are identified
event with extensive planning, testing, continuously, with an adaptive risk
and documentation, resulting in higher- management approach
risk releases.
• Modern: Releases are frequent, often at
the end of each iteration or sprint,
providing continuous delivery of new
features and improvements.
20. Traditional v/s Modern Project Management
Scope Management
• Traditional: The project scope is defined comprehensively and in detail at the
beginning of the project. This includes detailed requirements, deliverables, and
project boundaries.
• Modern: The project scope is defined at a high level initially and is refined
iteratively throughout the project. Detailed requirements are elaborated as the
project progresses.
THANK YOU