UNIT 1

The term software refers to the set of computer programs, procedures, and associated documents (flow charts, manuals,
etc.) that describe the programs and how they are to be used. To be precise. software means a collection of programs
whose objective is to enhance the capabilities of the hardware.
"A project is a series of activities or tasks that have a specific objective to be completed within ertain specifications, have
defined start and end dates, have funding limits (if applicable), and consume -Harold Kerner resources (i.e., money, people,
equipment)."
Management involves the following activities :
1. Planning : Deciding what is to be done.
2. Organizing : Making arrangement.
3. Staffing : Selecting the right people for the job etc.
4. Directing : Giving instructions.
5. Monitoring : Checking on progress.
6. Controlling : Taking action to remedy hold-ups.
7. Innovating : Coming up with new solutions.
8. Representing : Liasing with clients, users developers, suppliers, and other
Software Project:
1. A Software Project is the complete procedure of software development from requirement gathering to testing and
maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended
software product.
Management:
2. The process of dealing with or controlling things or people is called management.
3. Management is a set of principles relating to the functions of planning, organizing, directingand controlling a process or job
to complete successfully within the time period.

Software Project Management:

1. Software project management is the art of science of planning and leading software projects. It is sub discipline of
project management in which software projects are planned, monitored and controlled.
2. Software Project Management is the process of planning, organizing, staffing, monitoring.controlling and leading a
software project.
3. Software Project Management is a discipline of project is which software projects are planned, motivated and
controlled.
There are three needs for software project management. These are:
1. Time
2. Cost
 3. Quality

The image above shows triple constraints for software projects. It is an essential part of the software organization to deliver
a quality product, keeping the cost within the client’s budget and deliver the project as per schedule.
There are various factors, both external and internal, which may impact this triple factor. Any of three-factor can severely
affects the other two.

SOFTWARE PROJECTS V/S OTHER TYPES OF PROJECTS

Software projects have several properties that make them very different to other kinds of engineering project :

1. Invisibility/the Product is Intangible. It's hard to claim a bridge is 90% complete if there is not 90% of the bridge there. It
is easy to claim that a software project is 90% complete, even if there are no visible outcomes.

2. We don't have Much Experience. Software engineering is a new discipline, and so we simply don't have much
understanding of how to engineer large scale software projects.

3. Complexity. Software products contain more complexity than other engineered artifacts (such as bridge or road). We can't
measure the complexity of a software project until we actually work on it.

4. Large Software Projects are Often "Bespoke". Most large software systems are one-off, with experience gained in one
project being of little help in another.

5. The Technology Changes Very Quickly.

6. Working. Software projects are based on logical work while others are based on physical work.

7. Flexibility. The ease with which software can be changed is usually seen as one of its strength. Software projects are flexible.
Customer only wants final results, so rest of things are in control of the programmer he can modify software at any stage while
this thing is not in other projects, as everything is in front of customers, he is aware about progress, he can view what work is
being done by project manager and team, so it is not in the hands of project team to make changes at any stage of the project.

8. Conformity. The traditional engineer is usually working with physical systems and materials like cement and steel. These
physical systems can have some complexity but are governed by physical laws that are consistent.

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 in
'off the shelf, there may be no software writing as such. This is still fundamentally a software project because so many of other
elements are associated with this type of project are present. Usually there are three successive processes that bring a new
system into being.

How do we do ? Plan Project execution Do i Fig. 1.2 The feasibility study/plan/execution cycle.

1. The feasibility study. :- A feasibility study is an analysis conducted to assess the viability and potential success of a proposed
project or endeavor. It helps stakeholders evaluate whether the project is technically, financially, and operationally feasible,
and if it aligns with the organization's goals and objectives.

2. Planning. If the feasibility study produces results which indicate that the prospective project appears viable, then planning
of the project can take place.
3. Project execution. The project can now be executed. The execution of a project often contains design and implementation
sub-phases. The plan lays down the activities that have to be carried out in order to create these products. Planning and design
can be confused because at the most detailed level, planning decisions are influenced by design decisions.

1.Requirements analysis. This is finding out in tail what the users require of the system that the project to implement. Some
work along these lines will almost certainly have been carried out when the project was valuated but now the original informe
obtained re o be updated and supplemented. Several different pproaches to the users' requirements may be explored.

2.Specification. Detailed documentation of what the proposed system is to do.

3.Design. A design that meets the specification has to be drawn up. This design activity will be in two stages. One will be the
external or user design. This lays down what the system is to look like to the users in terms of menus, screen and report layouts
and so on. The next stage produces the physical design, which tackles the way in which the data and software procedures are
be structured internally.

4.Coding: This might refer to writing code in a procedural language such as C or Ada, or might refer to the use of a high level
application builder. Even where software is not being built from scratch, some modification to the base application might be
required to meet the needs of the new application.

5.Verification and validation: Whether software is developed specially for the current application or not, careful testing will
be needed to check that the proposed system meets its requirements.

6.Implementation/installation: Some system development practitioners refer to the whole of the project after design as
'implementation' (that is, the implementation of the design) while others insist that the term refers to the installation of the
system after the software has been developed. In this case it encompasses such things as setting up data files and system
parameters, writing user manuals and training users of the new system.

7.Maintenance and support: Once the system has been implemented there will be a continuing need for the correction of
any errors that may have crept into the system and for extensions and improvements to the system. Maintenance and support
activities may be seen as a series of minor software projects. In many environments, most software development is in fact
maintenance.
 Objectives of SPM

The project objectives define the target status at the end of the project. The abbreviation S.M.A.R.T. is sometimes
used to describe well defined objectives :

1. Specific. Effective objectives are concrete and well defined. Vague aspirations such as "to improve customer
relations" are unsatisfactory. Objectives should be defined in such a way that it is obvious to all whether the project
has been successful or not.

2. Measurable. Ideally there should be measures of effectiveness which tell us how successful the project has been.
For example, "to reduce customer complaints' would be more satisfactory as an objective than to improve customer
relations. The measure can, in some cases, be an answer to simple yes/no question, eg. did we install the new
software by 9 May

3. Achievable. It must be within the power of the individual or group to achieve the objective. Agreement with all
the stakeholders what the goal should be. Is there a realistic path to achievement?

4. Relevant. The objective must be relevant to the true purpose of the project.

5. Time constrained. There should be a defined point in time by which the objective should have been achieved
 THE PROJECT AS A SYSTEM

A project is concerned with creating a new system and/or transforming an old one and is itself a system.

Systems, subsystems and environments : A simple definition of the term system is a set of interrelated parts'. A
system will normally be part of a larger system and will itself comprise subsystems. Outside the system there will
be the system's environment. This will be made up of things that can affect the system but over which the system
has no direct control.

Open versus closed systems: Open systems are those that interact with the environment. Nearly all systems are
open. One reason that engineered systems and the projects to construct them often fail is that the technical staff
involved do not appreciate the extent to which systems are open and are liable to be affected by outside changes.

Sub-optimization : This is where a subsystem is working at its optimum but is having a detrimental effect on the
overall system. An example of this might be where software developers deliver to the users a system that is very
efficient in its use of machine resources, but is also very difficult to modify.

Sociotechnical systems: Software projects belong to this category of systems. Any software project requires both
technological organization and also the organization of people. Software project managers therefore need to have
both technical competence and the ability to interact persuasively with other people.

MANAGEMENT CONTROL

In software project management, management control refers to the processes and techniques used to monitor and
regulate the progress, quality, and outcomes of a software project. It involves establishing mechanisms to ensure
that the project is executed effectively and efficiently, and that it meets its defined objectives and targets.

Here are some key aspects of management control in software project management:

1. Planning and goal setting: Management control begins with setting clear project goals and objectives. This
involves defining project scope, identifying deliverables, estimating resources, and establishing a project plan.

2. Monitoring progress: Once the project is underway, management control involves continuously monitoring the
progress of various activities and tasks. This includes tracking milestones, assessing work completed, and comparing
it against the planned schedule.

3. Quality assurance: Management control includes measures to ensure the quality of the software being
developed. This involves defining quality standards, establishing quality assurance processes, conducting reviews
and inspections, and implementing testing and validation techniques.

4. Risk management: Management control encompasses identifying, assessing, and mitigating risks associated with
the project. This involves conducting risk assessments, creating risk mitigation strategies, and monitoring risk
throughout the project lifecycle.

5. Resource management: Management control includes managing project resources efficiently. This includes
allocating personnel, equipment, and other necessary resources appropriately, and ensuring their availability when
needed.

6. Change management: Management control involves handling changes in project scope, requirements, or
objectives. This includes assessing the impact of changes, making decisions regarding their implementation, and
managing any resulting modifications to the project plan.
7. Communication and reporting: Management control requires effective communication and reporting
mechanisms. This includes regular progress updates, status reports, and performance metrics to keep stakeholders
informed about the project's status and achievements.

8. Decision-making: Management control involves making informed decisions based on the project's progress and
performance. This may include revising plans, adjusting resource allocations, resolving conflicts, and taking
corrective actions when necessary.

By implementing management control practices, software project managers can monitor the project's progress,
identify deviations from the plan, and take appropriate actions to keep the project on track and ensure successful
delivery.

Project schedule simply means a mechanism that

is used to communicate and know about that
tasks are needed and has to be done or
performed and which organizational resources
will be given or allocated to these tasks and in
what time duration or time frame work is needed
to be performed. Effective project scheduling
leads to success of project, reduced cost, and
increased customer satisfaction. Scheduling in
project management means to list out activities,
deliverables, and milestones within a project that
are delivered. It contains more notes than your
average weekly planner notes. The most
common and important form of project schedule
is Gantt chart.

Process :

The manager needs to estimate time and resources of project while scheduling project. All activities in project must be
arranged in a coherent sequence that means activities should be arranged in a logical and well-organized manner for easy to
understand. Initial estimates of project can be made optimistically which means estimates can be made when all favorable
things will happen and no threats or problems take place.

The total work is separated or divided into various small activities or tasks during project schedule. Then, Project manager will
decide time required for each activity or task to get completed. Even some activities are conducted and performed in parallel
for efficient performance. The project manager should be aware of fact that each stage of project is not problem-free.

Problems arise during Project Development Stage :

1. People may leave or remain absent during particular stage of development.

2. Hardware may get failed while performing.
3. Software resource that is required may not be available at present, etc.
4. The project schedule is represented as set of chart in which work-breakdown structure and dependencies within
various activities are represented. To accomplish and complete project within a given schedule, required resources
must be available when they are needed. Therefore, resource estimation should be done before starting
development.
Resources required for Development of Project :
 1. Human effort
2. Sufficient disk space on server
3. Specialized hardware
4. Software technology
5. Travel allowance required by project staff, etc.

A task set
In software project management, a task set refers to a collection of individual tasks that need to be completed within a project.
These tasks are typically related to the development, testing, deployment, and maintenance of the software product. Each
task in the set has a defined objective, a set of activities to be performed, and a specific timeline or deadline for completion.

A task network, on the other hand, is a representation of the dependencies and relationships between tasks in a project. It
helps visualize the order in which tasks should be executed and the dependencies between them. A task network allows
project managers to understand the critical path of the project, identify potential bottlenecks, and allocate resources
effectively.

Task Set:
Task Network:
1. Requirements gathering
1. Requirements gathering
2. Design software architecture
3. Develop user interface 2. Design software architecture
4. Implement core functionality 3. Develop user interface
5. Conduct unit testing 4. Implement core functionality
6. Integrate modules 5. Conduct unit testing
7. Perform system testing 6. Integrate modules
8. Bug fixing and debugging 7. Perform system testing
9. User acceptance testing 8. Bug fixing and debugging
10. Documentation and user manuals 9. User acceptance testing
11. Deployment and release 10. Documentation and user manuals
11. Deployment and release

In this example, tasks such as "Develop user interface" and "Implement core functionality" can start once the
preceding tasks, such as "Requirements gathering" and "Design software architecture," are completed. Similarly,
tasks like "Conduct unit testing" and "Perform system testing" depend on the completion of their parent tasks.

By visualizing the task network, project managers can understand the sequential and parallel execution of tasks,
identify critical paths where delays can impact the overall project timeline, and allocate resources accordingly to
ensure successful project completion.
A work breakdown structure (WBS) is a hierarchical decomposition of the project deliverables, tasks, and subtasks. It helps
project managers organize and manage the project's scope, schedule, and resources effectively. Here are some examples of a
work breakdown structure in project management:
 1. Construction Project:
Phase 1: Site Preparation
• Task 1: Obtain necessary permits
• Task 2: Clear the construction site
• Task 3: Install temporary fencing
• Phase 2: Foundation
• Task 1: Excavate the foundation area
• Task 2: Pour concrete for the foundation
• Task 3: Cure the foundation
• Phase 3: Framing
• Task 1: Construct exterior walls
• Task 2: Install roof trusses
• Task 3: Install windows and doors

2. 2. Software Development Project:

3.Marketing Campaign Project:
• Phase 1: Requirements Gathering • Phase 1: Planning
• Task 1: Conduct stakeholder interviews • Task 1: Define campaign objectives and target audience
• Task 2: Analyze existing systems • Task 2: Conduct market research

• Task 3: Document functional and non-functional • Task 3: Develop campaign budget

requirements • Phase 2: Execution
• Phase 2: Design and Prototyping • Task 1: Design marketing materials (brochures, banners, etc.)
• Task 1: Develop system architecture • Task 2: Execute social media and online advertising
• Task 2: Create wireframes and UI/UX designs • Task 3: Coordinate with influencers for endorsements
• Task 3: Build a functional prototype • Phase 3: Evaluation
• Phase 3: Development and Testing • Task 1: Analyze campaign performance metrics
• Task 1: Write code and develop software • Task 2: Gather customer feedback
modules • Task 3: Prepare a post-campaign report
• Task 2: Conduct unit testing
• Task 3: Perform integration testing

Selecting a Project:
1. Identify potential projects: Brainstorm and generate a list of project ideas based on organizational needs,
market demands, customer requirements, or other relevant factors.
2. Evaluate project feasibility: Assess the feasibility of each project idea by considering factors such as available
resources, budget, timeline, expertise, and potential risks.
3. Prioritize projects: Rank the project ideas based on strategic alignment, return on investment, risk factors, and
other relevant criteria.
4. Select the project: Choose the project that best aligns with organizational goals, has the highest potential for
 success, and is feasible given available resources and constraints.
Identifying Project Scope and Objectives:
1. Define project scope: Clearly outline the boundaries of the project by specifying what is included and what is
excluded.
2. Gather requirements: Collect and document the project requirements by engaging with stakeholders,
conducting interviews, surveys, or workshops to understand their expectations and needs.
3. Prioritize objectives: Identify and prioritize the project objectives based on their importance, strategic
alignment, and feasibility.
4. Set SMART goals: Develop Specific, Measurable, Achievable, Relevant, and Time-bound (SMART) goals that
align with the project objectives.
Identifying Project Infrastructure:
1. Determine resource requirements: Identify the resources needed for the project, including personnel,
equipment, technology, and facilities.
2. Establish project team: Form a team with the required skills and expertise to execute the project successfully.
3. Define communication channels: Establish effective communication channels to facilitate collaboration and
information sharing among project team members, stakeholders, and other relevant parties.
4. Set up project management tools: Identify and implement appropriate project management tools and software
to support planning, tracking, and monitoring project progress.
Analyzing Project Characteristics:

1. Conduct a SWOT analysis: Assess the project's strengths, weaknesses, opportunities, and threats to understand
its internal and external factors that may impact its success.
2. Identify project constraints: Identify any constraints or limitations that may affect the project, such as budget
constraints, time constraints, resource constraints, or regulatory requirements.
3. Assess project risks: Identify potential risks and uncertainties associated with the project and develop a risk
management plan to mitigate or address them.
4. Analyze dependencies: Identify any dependencies between project activities, tasks, or stakeholders to ensure
smooth execution and coordination.
Identifying Project Products and Activities:

1. Define project deliverables: Identify the tangible and intangible outputs or products that will be produced as a
result of the project.
2. Breakdown project into activities: Decompose the project into smaller, manageable activities or tasks that
need to be completed to achieve the project objectives.
3. Sequence activities: Determine the logical sequence and dependencies among project activities to create an
activity schedule or project timeline.
4. Define milestones: Identify key milestones or checkpoints in the project timeline to measure progress and
ensure alignment with project objectives.
5. Remember that these steps are general guidelines, and the specific approach may vary depending on the nature
of the project and the organization's processes and preferences.
 UNIT 2

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life
cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before
the next phase can begin and there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

1. 1.Requirements analysis and specification phase: The

aim of this phase is to understand the exact
requirements of the customer and to document them
properly. Both the customer and the software
developer work together so as to document all the
functions, performance, and interfacing requirement
of the software. It describes the "what" of the system
to be produced and not "how."In this phase, a large
document called Software Requirement Specification
(SRS) document is created which contained a detailed
description of what the system will do in the common
language.

2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a suitable form which
permits further coding in a programming language. It defines the overall software architecture together with high
level and detailed design. All this work is documented as a Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is implemented. If the SDD is complete, the
implementation or coding phase proceeds smoothly, because all the information needed by software developers
is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small modules are tested in isolation initially. After
that these modules are tested by writing some overhead code to check the interaction between these modules
and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end product is determined by
the effectiveness of the testing carried out. The better output will lead to satisfied customers, lower maintenance
costs, and accurate results. Unit testing determines the efficiency of individual modules. However, in this phase,
the modules are tested for their interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user once the software has
been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

1. When the requirements are constant and not changed regularly.
2. A project is short
3. The situation is calm
4. Where the tools and technology used is consistent and is not changing
5. When resources are well prepared and are available to use.
 Advantages of the Waterfall Model:
1. Before the next phase of development, each phase must be completed.
2. Suited for smaller projects where requirements are well defined.
3. They should perform quality assurance test (Verification and Validation) before completing each stage.
4. Elaborate documentation is done at every phase of the software's development cycle.
5. Project is completely dependent on project team with minimum client intervention.
Disadvantages of the Waterfall Model:
1. Error can be fixed only during the phase.
2. It is not desirable for complex project where requirement changes frequently.
3. Testing period comes quite late in the developmental process.
4. Documentation occupies a lot of time of developers and testers.
5. Client’s valuable feedback cannot be included with ongoing development phase.
6. Small changes or errors that arise in the completed software may cause a lot of problems.
RAD (Rapid Application Development) Model:
RAD or Rapid Application Development process is an adoption of the waterfall model; ittargets at developing software
in a short span of time. RAD follow the iterative
SDLC RAD model has following phases:
1. Business Modeling
2. Data Modeling
3. Process Modeling
4. Application Generation
5. Testing and Turnover

It focuses on input-output source and destination of the information. It emphasizes on delivering projects in small pieces; the
larger projects are divided into a series of smaller projects. The main features of RAD model are that it focuses on the reuse
of templates, tools, processes, and code.

The phases in the rapid application development (RAD) model are:

1. Business modeling: On basis of the flow of information and distribution between various business channels, the product is
designed.
2. Data modeling: The information collected from business modeling is refined into a set of data objects that are significant for
the business.
3. Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve
some specific business objective. Description are identified and created for CRUD of data objects.
4. Application generation: Automated tools are used for the construction of the software, to convert process and data models
into prototypes.
5. Testing and turnover: As prototypes are individually tested during every iteration, the overall testing time is reduced in RAD.
When to use RAD Methodology?
• When a system needs to be produced in a short span of time (2-3 months).
• When the requirements are known.
• When the user will be involved all through the life cycle.
• When technical risk is less.
• When there is a necessity to create a system that can be modularized in 2-3 months oftime.
• When a budget is high enough to afford designers for modeling along with the cost ofautomated tools for code
generation.
Advantages of the RAD model: Disadvantages of RAD model:
➢ Reduced development time.
1. Depends on strong team and individual
➢ Increases reusability of components performances for identifying businessrequirements.
➢ Quick initial reviews occur 2. Only system that can be modularized can be built
➢ Encourages customer feedback using RAD
➢ Integration from very beginning solves a lot of integration issues. 3. Requires highly skilled developers/designers.
Spiral Model: 4. High dependency on modeling skill
1. Spiral Model is a combination of a waterfall model and
iterative model.
2. Each phase in spiral model begins with a design goal and ends with the client reviewing theprogress.
3. The spiral model was first mentioned by Barry Boehm in his 1986 paper.
4. The development team in Spiral-SDLC model starts with a small set of requirement and goesthrough each
development phase for those set of requirements.
5. The software engineering team adds functionality for the additional requirement in every-increasing spirals
until the application is ready for the production phase.

Each cycle in the spiral is divided into four parts:

1. Objective Setting(First quadrant):
➢ Each cycle in the spiral starts with the identification of purpose for that cycle, the various alternatives that are possible for
achieving the targets, and the constraints that exists.
2. Risk Assessment And Reduction(Second quadrant):
➢ The next phase in the cycle is to calculate these various alternatives based on the goals and constraints. The focus of
evaluation in this stage is located on the risk perception forthe project.
 3. Development and validation(Third quadrant):
➢ The next phase is to develop strategies that resolve uncertainties and risks. This process may include activities such as
benchmarking, simulation, and prototyping.
4. Planning and Review(Fourth quadrant):
1. Finally, the next step is planned. The project is reviewed, and a choice made whether to continue with a further period of
the spiral. If it is determined to keep, plans are drawn up for the next step of the project.
2. The development phase depends on the remaining risks. For example, if performance or user-interface risks are treated
more essential than the program development risks, the next phase may be an evolutionary development that includes
developing a more detailed prototype for solving the risks.
3. The risk-driven feature of the spiral model allows it to accommodate any mixture of aspecification-oriented, prototype-
oriented, simulation-oriented, or another type of approach.
4. An essential element of the model is that each period of the spiral is completed by a reviewthat includes all the products
developed during that cycle, including plans for the next cycle.
5. The spiral model works for development as well as enhancement projects.

When to use Spiral Model?

• When deliverance is required to be frequent. Disadvantages:
• When the project is large 1. Can be a costly model to use.
• When requirements are unclear and complex 2. Risk analysis needed highly particular expertise
• When risk and costs evaluation is important. 3. For its smooth operation spiral model protocol
• When changes may require at any time needs to be followed strictly.
• Large and high budget projects 4. Doesn't work well for smaller projects.
Advantages:
➢ Additional functionality or changes can be done at a later stage.
➢ Cost estimation becomes easy as the prototype building is done in small fragments.
➢ Continuous or repeated development helps in risk management.
➢ Development is fast and features are added in a systematic way.
➢ There is always a space for customer feedback.
What is software project estimation?

Software project estimation in software project management refers to the process of predicting the effort, time, resources,
and cost required to complete a software project. It involves analyzing various project parameters and making educated
guesses or calculations to determine the overall scope and scale of the project.

Estimation is an essential activity in project management as it helps stakeholders, such as project managers, clients, and
developers, to plan and make informed decisions. Accurate estimation enables effective resource allocation, budgeting, and
scheduling, which ultimately contribute to project success.

The estimation accuracy is crucial because the client needs to feel confident that they can fund the project before
committing to it. Also, there are many side effects of poor project estimates, like:

1. Going over budget

2. Cutting corners to avoid going over an unrealistic budget
3. Running out of funds
4. The developing team has low morale due to unrealistic expectations
What are the types of estimation?

1. Scope of the project – How much work is to be estimated?

2. Estimation technique – How to estimate the project?
3. Schedule – How much time will it take to finish the project?
4. Resources – Who will be working on the project?
5. Cost – What is the required budget? 6.Risks – What blocking points might appear?
 Decomposition Technique
● Decomposition Technique is divide & conquer approach of Software Project Estimation. By decomposition a
project into major functions like software engineering related activities, cost, schedule & efforts estimation can
be performed in stepwise manner.
Decomposition Techniques are :
1. Software Sizing
2. Problem based Estimation
3. Process based Estimation
1. Software Sizing
● Sizing represents the project planner's first major challenge.
The accuracy of a software project estimate is predicated on a number of things :
1. The degree to which the planner has properly estimated the size of the product to be built.
2. The ability to translate the size estimate into human effort, calendar time and dollars.
3. The degree to which the project plan reflects the abilities of the software team.
4. The stability of product requirements & environment that supports software engineering effort.
➤Approaches of Software Sizing compre
1. "Fuzzy Logic" Sizing
2. Function Point Sizing
3. Standard Component Sizing
4. Change Sizing
1. "Fuzzy Logic" Sizing :

● To apply this approach, the planner must identify the type of application.
● Although personal experience can be used, the planner should also have access to historical database of
projects so that estimates can be compared to actual experience.
2. Function Point Sizing : • The planner develops estimates of the info domain characteristics.
3. Standard Component Sizing :
• Standard components for an information system。are subsystems, modules, screens, reports, interactive
programs, batch programs, files, LOC and object-level instructions.
• Uses historical project data to determine the delivered size per standard component.
4. Change Sizing :
• This approach is used when a project encompasses the use of existing software that must be modified in some
way as part of a project.
• The planner estimates reuse, adding code, changing code, deleting code of modifications that must be
accomplished.
Using an "effort ratio” for each type of change, the size of the change may be estimated.
2. Problem based Estimation
● Lines of code and function points were described as measures from which productivity metrics can be
computed. (LOC/pm & FP/pm)

● LOC and FP data are used in two ways during software project estimation :
1. As an estimation variable to "size" each element of the software.
2. As baseline metrics collected from past projects and used in conjunction with estimation variables to
develop cost and effort projections.
A three-point or expected value can then be computed
Pic mein se formula likhna hai
3. Process based Estimation
a. Most common technique for estimating project is to estimate on the process that will be used.
b. The process is decomposed into a relatively small set of tasks and the effort required to accomplish each
task is estimated.
c. Once problem functions & process activities are decided, the planner estimates the effort (e.g., person-
months) that will be required to accomplish each software process activity_for each software function.
Average labor rates (cost/unit effort) are then applied to the effort estimated for each process activity.
d. It is very likely the labor rate will vary for each task. Senior staff heavily involved in early activities are
generally more expensive than junior
Cost estimation
Cost estimation simply means a technique that is used to find out the cost estimates. The cost estimate is the
financial spend that is done on the efforts to develop and test software in Software Engineering. Cost estimation
models are some mathematical algorithms or parametric equations that are used to estimate the cost of a
product or a project.

Various techniques or models are available for cost estimation, also known as Cost Estimation Models as shown
below :

Empirical estimation models in software project management are used to predict various aspects of a software
project, such as effort, duration, cost, and resource allocation, based on historical data and statistical analysis. These
models rely on empirical evidence and past project data to make estimates and predictions for future projects. Here are
a few commonly used empirical estimation models:

1. COCOMO (COnstructive COst MOdel): COCOMO is one of the oldest and most widely used estimation models. It
was developed by Barry Boehm in the 1980s and has evolved over time. COCOMO estimates the effort and cost of a
software project based on various project attributes, such as size, complexity, development environment, and team
experience.
2. Function Point Analysis (FPA): Function Point Analysis is a technique for estimating the size and complexity of a
software project based on the functionality it provides to the end-users. The estimation is derived by assigning a
weight to different functions and components of the software based on their complexity. FPA can be used to
 estimate effort, cost, and duration.
3. Use Case Points (UCP): Use Case Points is another estimation technique that focuses on the functional requirements
of a software project. It assigns points to different use cases based on their complexity and estimates effort and cost
based on these points. UCP is particularly useful for estimating projects developed using object-oriented
methodologies.
4. Wideband Delphi: Wideband Delphi is a consensus-based estimation technique where a group of experts, including
developers, project managers, and domain experts, provide their individual estimates for various project
parameters. The estimates are collected, analyzed, and discussed in multiple rounds until a consensus is reached.
Wideband Delphi helps in reducing biases and achieving more accurate estimates.
5. Monte Carlo Simulation: Monte Carlo Simulation is a probabilistic estimation technique that uses historical data to
create a model of the project's behavior. It considers uncertainties and variability in various project parameters and
runs simulations to generate multiple possible outcomes. Monte Carlo Simulation provides a range of estimates
along with their probabilities, helping project managers make informed decisions.

The heuristic technique is a technique or model that is used for solving problems, learning, or discovery in the practical
methods which are used for achieving immediate goals. These techniques are flexible and simple for taking quick
decisions through shortcuts and good enough calculations, most probably when working with complex data.

Analytical Estimation Technique :-In this technique, firstly the task is divided or broken down into its basic component
operations or elements for analyzing. Second, if the standard time is available from some other source, then these
sources are applied to each element or component of work.

Estimation for Object-oriented projects

Object-oriented projects: In object-oriented projects, estimation is based on the size and complexity of classes and
objects. A common technique used for estimation in object-oriented projects is Function Point Analysis (FPA), which
takes into account the number of inputs, outputs, inquiries, files, and interfaces in the system. Other techniques used for
estimation in object-oriented projects include Object Points, Use Case Points, and Feature Points.

Estimation for Agile development

Estimating the duration and effort required for Agile development projects can be challenging, as Agile methodologies
prioritize flexibility and responsiveness to change. However, there are a few common techniques that Agile teams use to
estimate project timelines and effort. Here are three popular estimation techniques:

Story Points: Agile teams often use story points to estimate the relative size and complexity of user stories or product
backlog items. Story points are a unitless measure that reflects the effort and complexity involved in completing a
particular task or feature. Team members assign story points based on their collective understanding and experience.
The team can then use historical data to estimate the velocity, which is the average number of story points they can
complete in a given time frame. This allows them to estimate the effort required to complete future work based on the
team's velocity.

Planning Poker: Planning Poker is a collaborative estimation technique where team members collectively estimate the
effort required for each user story or backlog item. Each team member privately selects a card representing their
estimate and then reveals it simultaneously with the rest of the team. If there are significant discrepancies, the team
discusses the reasons behind their estimates and repeats the process until a consensus is reached. This technique
promotes team collaboration and helps align everyone's understanding of the work.

Dot Voting: In Dot Voting Techniques all the user stories along with their description are posted on the board. Each
member out a dot in front of those stories that they consider most important. This way the stories are sorted according
to their priorities. This is done to select the most important stories that should be taken forward.

T-Shirt Size: This technique helps in open and mutual collaborative discussions. In this technique t-shirt sizes -XS (Extra
Small), S (Small), M (Medium), L (Large), XL (Extra Large) are used. User stories are given t-shirt sizes according to the
member understanding. This technique gives rough estimation very fastly.
 Estimation for Web engineering projects

1. Three-Point Estimation: This estimation method involves considering three estimates for each web project task: the
optimistic estimate, the most likely estimate, and the pessimistic estimate. These three values are used to calculate the
expected effort or duration using techniques like the PERT formula.
2. The primary purpose of WFPA is to determine the functional size of a web application by quantifying the functionality it
provides to its users. Function points are a unit of measurement used in this analysis, representing the functionality
provided by the application. By considering the number and complexity of function points, software developers and
project managers can estimate various factors such as development effort, cost, and duration
Cost-benefit analysis
Cost-benefit analysis is a decision-making technique used in software project management to determine the economic
feasibility of a project by comparing the costs of implementing the project with the benefits it will generate. It involves
identifying and quantifying all costs and benefits associated with a project and then analyzing them to determine if the
benefits justify the costs.

The importance of cost-benefit analysis in software project management is that it helps project managers to make
informed decisions about whether to proceed with a project or not. By analyzing the costs and benefits of a project,
project managers can identify the potential risks and rewards associated with the project. They can also determine if the
project is financially feasible and whether it will generate a positive return on investment. This information is crucial for
making informed decisions about whether to proceed with the project or not, and if so, how to manage it effectively to
achieve the desired outcomes.

steps involved in conducting a cost-benefit analysis in software project management:

1. Identify project objectives: Clearly define the goals and objectives of the software project or decision under
consideration. This provides a basis for evaluating the benefits that can be achieved.
2. Identify costs: Identify and quantify the various costs associated with the project. These costs may include
development resources, software licenses, hardware, maintenance, training, and ongoing operational costs.
3. Identify benefits: Determine the potential benefits that the project can deliver. These may include increased
productivity, cost savings, improved customer satisfaction, enhanced efficiency, or competitive advantage.
4. Assign a monetary value: Assign a monetary value to each identified cost and benefit. This step involves estimating
the financial impact of each item in terms of dollars. Some benefits may be straightforward to quantify, while others
might require more estimation or comparison to industry benchmarks.
5. Calculate the net present value (NPV): Calculate the net present value of the project by subtracting the total costs
from the total benefits. NPV accounts for the time value of money by discounting future cash flows to their present
value.
6. Evaluate the results: Analyze the calculated NPV to determine whether the project is financially viable. A positive
NPV indicates that the benefits outweigh the costs, suggesting that the project is potentially worthwhile.
Conversely, a negative NPV suggests that the costs exceed the benefits, indicating that the project may not be a
wise investment.
7. Consider intangible factors: While cost-benefit analysis primarily focuses on financial aspects, it is important to
consider intangible factors that may influence the decision-making process. These can include strategic alignment,
long-term goals, technological advancements, and other non-financial factors that may impact the overall value of
the project.
Cash flow forecasting

Cash flow forecasting is the process of estimating and projecting the inflows and outflows of cash within a business over
a specific period of time. It helps businesses anticipate their future cash position and make informed financial decisions.
Cash flow forecasting is crucial for effective financial management and planning, as it allows businesses to identify
potential cash shortages or surpluses and take appropriate actions to address them.

Here are some key steps involved in cash flow forecasting:

Gather historical data: Begin by collecting and analyzing past financial records, including cash flow statements, income
statements, and balance sheets. This data will provide insights into past cash flow patterns and serve as a starting point
for forecasting.
Identify cash flow sources: Determine the various sources of cash inflows for your business, such as sales revenue,
investments, loans, or any other sources of income.

Estimate cash inflows: Project the expected amounts and timing of cash inflows based on factors like sales forecasts,
customer payment terms, and any other anticipated revenue streams. Consider different scenarios and factors that may
impact cash inflows, such as seasonal fluctuations or changes in market conditions.

Identify cash flow uses: Identify and categorize the different types of cash outflows your business will encounter,
including expenses such as payroll, rent, utilities, inventory, loan repayments, taxes, and other operating costs.

Estimate cash outflows: Project the expected amounts and timing of cash outflows based on factors like historical data,
vendor payment terms, contractual obligations, and other anticipated expenses. Consider any potential changes in costs,
such as inflation or planned investments.

Calculate net cash flow: Determine the net cash flow for each period by subtracting cash outflows from cash inflows.
This will give you an indication of the surplus or deficit in your cash position.

Monitor and revise: Regularly review and update your cash flow forecast as new information becomes available or as
circumstances change. Compare your actual cash flow with the forecasted figures to identify any variances and adjust
your future projections accordingly

Cost-benefit evaluation techniques

Cost-benefit evaluation techniques are used to assess the financial feasibility and effectiveness of projects, investments,
or policy decisions. These techniques help decision-makers weigh the costs of implementing a particular action against
the expected benefits it would bring. Here are some commonly used cost-benefit evaluation techniques:

Net Present Value (NPV): NPV calculates the present value of all projected cash flows associated with a project or
investment. It takes into account the time value of money by discounting future cash flows to their present value using a
specified discount rate. If the NPV is positive, the project is considered financially viable.

Return on Investment (ROI): ROI is a simple and widely used technique that compares the expected return from an
investment to its cost. It is calculated by dividing the net profit or benefit generated by the investment by the initial
investment cost, and then expressed as a percentage. A higher ROI indicates a more favorable investment.

Cost-Benefit Analysis (CBA): CBA compares the total costs of a project or policy decision to its total benefits, both
quantifiable and non-quantifiable. Costs and benefits are assigned monetary values whenever possible, and then
aggregated and compared. If the benefits outweigh the costs, the project is considered economically viable.

Payback Period: The payback period measures the time required to recover the initial investment through cash inflows.
It is a simple calculation that divides the initial investment by the expected annual cash inflows. Shorter payback periods
are generally preferred, as they indicate quicker cost recovery.

Cost-Effectiveness Analysis (CEA): CEA is similar to cost-benefit analysis, but it focuses on comparing the costs of
achieving specific outcomes or objectives. It is often used in situations where benefits are difficult to quantify in
monetary terms. CEA calculates the cost per unit of effectiveness, allowing decision-makers to compare alternative
interventions or strategies.

Internal Rate of Return (IRR): IRR is the discount rate that makes the net present value of a project's cash flows equal to
zero. It represents the project's rate of return and is often used to evaluate the attractiveness of an investment. If the IRR
is higher than the required rate of return or the cost of capital, the project is considered financially viable.

Explain the process of risk evaluation in software project management.

The process of risk evaluation in software project management involves identifying and analyzing potential risks
that could impact the project schedule, budget, or quality of the final product. This process helps project
managers to anticipate and mitigate potential problems before they occur, minimizing the negative impact on
the project. The steps involved in risk evaluation include:
Identifying potential risks: This involves brainstorming with the project team and other stakeholders to identify
potential risks that could impact the project.

Analyzing risks: Once potential risks have been identified, the project team analyzes each risk to determine the
probability and impact of its occurrence.

Developing risk mitigation strategies: Based on the analysis, the project team develops strategies to mitigate
the risks and reduce their impact on the project.

Monitoring and controlling risks: Once risk mitigation strategies have been developed, the project team
monitors the risks to ensure that they are under control and that new risks are identified and addressed in a
timely manner

8. Describe the selection of an appropriate project report and its importance.

A project report is a document that summarizes the project status, progress, and outcomes. The report provides
stakeholders with a comprehensive understanding of the project and its impact on the organization. The
selection of an appropriate project report is important because it helps to ensure that stakeholders have access
to accurate and timely information about the project. The selection of a project report will depend on factors
such as the scope of the project, the intended audience, and the level of detail required. Some common types
of project reports include status reports, progress reports, and final project reports. The project manager should
select the appropriate type of report based on the needs of the stakeholders and the stage of the project.

Explain the choice of a process model in software project management.

The choice of the process model is an important decision in software project management as it determines the
approach and methods that will be used to develop the software. The process model provides a framework for
planning, designing, implementing, and testing the software. Various types of process models are available,
each with its own strengths and weaknesses.

Some common process models used in software project management include the waterfall model, spiral model,
and agile model. The waterfall model is a linear sequential approach where each phase of the project is
completed before moving on to the next phase. A spiral model is an iterative approach where the project is
developed in cycles, with each cycle adding new functionality. The agile model is a flexible and adaptive
approach where the project is developed in iterations, with a focus on delivering working software quickly and
responding to changes in requirements.

The choice of process model will depend on factors such as the size and complexity of the project, the level of
uncertainty and risk, and the team's expertise and experience. It is important to select a process model that is
appropriate for the project's specific needs and to ensure that the team is trained and equipped to use the
selected model effectively.

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further modified by the
International Function Point Users Group (IFPUG). FPA is used to make estimate of the software project, including its
testing in terms of functionality or function size of the software product. However, functional point analysis may be used
for the test estimation of the product. The functional size of the product is measured in terms of the function point,
which is a standard of measurement to measure the software application.

Objectives of FPA

The basic and primary purpose of the functional point analysis is to measure and provide the software application
functional size to the client, customer, and the stakeholder on their request. Further, it is used to measure the software
 project development along with its maintenance, consistently throughout the project irrespective of the tools and the
technologies.

Types of FP Attributes

All these
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 Prompts and interrupts.

(EQ)

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

5. Number of external interfaces Shared databases and shared routines.

(EIF)
parameters are then individually assessed for complexity.

The FPA functional units are shown in Fig:

Measurement Parameter Low Average High

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10

3. Number of external inquiries (EQ) 3 4 6

4. Number of internal files (ILF) 4 5 7

5. Number of external interfaces (EIF) 3 4 6

Weights of 5-FP Attributes

EI − The number of external inputs. These are elementary processes in which derived data passes across the boundary
from outside to inside. In an example library database system, enter an existing patron's library card number.
EO − The number of external output. These are elementary processes in which derived data passes across the boundary
from inside to outside. In an example library database system, display a list of books checked out to a patron.

EQ − The number of external queries. These are elementary processes with both input and output components that
result in data retrieval from one or more internal logical files and external interface files. In an example library database
system, determine what books are currently checked out to a patron.

ILF − The number of internal log files. These are user identifiable groups of logically related data that resides entirely
within the applications boundary that are maintained through external inputs. In an example library database system,
the file of books in the library.

ELF − The number of external log files. These are user identifiable groups of logically related data that are used for
reference purposes only, and which reside entirely outside the system. In an example library database system, the file
that contains transactions in the library's billing system.

The Prototyping Model

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.

Prototyping Concept

In this process model, the system is partially implemented before or during the analysis phase thereby giving the
customers an opportunity 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 further
refined to eliminate them. The process continues until the user approves the prototype and finds the working model to
be satisfactory.
 Advantage of Prototype Model
1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model
1. An unstable/badly implemented prototype often becomes the final product.
2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement analysis, design, customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

UNIT 3

Network planning models

Network planning models in software project management refer to project scheduling techniques that use graphical
representation to depict the activities and dependencies of a software project. These models are commonly used in the
context of the Critical Path Method (CPM) and the Program Evaluation and Review Technique (PERT).

The network planning model represents a project as a network of activities, where each activity represents a task or a set
of tasks required to complete the project. The model consists of nodes and arrows, where nodes represent the activities
and arrows represent the dependencies between activities. Activities are connected in a sequential order, showing the
flow and relationships between them.

Critical Path Method (CPM)

Critical Path Method (CPM) is a method used in project planning, generally for project scheduling for the on-time
completion of the project. It actually helps in the determination of the earliest time by which the whole project can be
completed. There are two main concepts in this method namely critical task and critical path. Critical task is the
task/activity which can’t be delayed otherwise the completion of the whole project will be delayed. It must be completed
on-time before starting the other dependent tasks.

Critical path is a sequence of critical tasks/activities and is the largest path in the project network. It gives us the minimum
time which is required to complete the whole project. The activities in the critical path are known as critical activities and
if these activities are delayed then the completion of the whole project is also delayed.
 To determine the critical path and project duration, CPM uses the following steps:

1. Identify all the activities and their dependencies: List all the activities required to complete the project and determine their
dependencies. Activities with a dependency cannot start until their predecessor activities are completed.

2. Create a network diagram: Represent the activities and their dependencies using nodes and arrows. Nodes represent the
activities, and arrows represent the dependencies between them.

3. Determine activity durations: Estimate the time required to complete each activity. This can be based on historical data,
expert judgment, or other estimation techniques.

4. Calculate the earliest start time (EST) and earliest finish time (EFT) for each activity: Starting from the first activity, calculate
the earliest possible start and finish times for each activity by considering the durations and dependencies.

5. Calculate the latest finish time (LFT) and latest start time (LST) for each activity: Starting from the last activity, calculate the
latest possible finish and start times by working backward through the network.

6. Calculate the total float or slack: The total float represents the amount of time an activity can be delayed without delaying
the project's overall duration. It is calculated by finding the difference between the LST and EST or LFT and EFT for each
activity.

Identification of the critical path

For this, you need to determine four parameters of each activity of the network.
• Earliest start time (ES) - The earliest time an activity can start once the previous dependent activities are over.
• Earliest finish time (EF) - ES + activity duration.
• Latest finish time (LF) - The latest time an activity can finish without delaying the project.
• Latest start time (LS) - LF - activity duration.

7. Identify the critical path: The critical path is the longest path through the network diagram, consisting of activities with zero
float. Any delay in activities on the critical path will directly impact the project's duration.

8. Determine the project duration: The project duration is the sum of the durations of activities on the critical path. It
represents the minimum time required to complete the project.

Following are advantages of critical path methods:

• Offers a visual representation of the project activities.
• Presents the time to complete the tasks and the overall project.
• Tracking of critical activities.
 Bar charts

Bar charts, also known as Gantt charts, are commonly used in project management to visually represent project schedules
and activities. They provide a timeline view of tasks, their start and end dates, and their dependencies. Here's an example of
how a bar chart can be used in project management:

Let's consider a software development project to create a mobile application. The project has five major tasks: requirements
gathering, design, development, testing, and deployment.

● Advantages –
1. Easy to prepare –
2. Easily understood by all parties –
3. Involved in the construction process
4. Good communication tool

Disadvantages:-
1. Do not show interrelationships between activities
2. Managing projects becomes difficult without those relationships between activities
3. It is difficult to judge the impact of an unexpected event on the rest of the construction process
 PERT chart
A PERT chart, which stands for Program Evaluation and Review Technique chart, is a project management tool used to visually
represent the tasks, dependencies, and timelines of a project. It is particularly useful for complex projects with multiple
interdependent tasks and activities.

In a PERT chart, tasks are represented as nodes, and arrows represent the dependencies between tasks. The chart is typically
drawn from left to right, with the start of the project on the left and the end of the project on the right.

Each task in the PERT chart is associated with the following information:

1. Task name: A unique identifier for the task.

2. Duration: The estimated time required to complete the task.
3. Dependencies: The tasks that must be completed before the current task can start.
4. Milestones: Key points or events in the project.
PERT charts also include additional information such as critical path analysis, which identifies the longest path of dependent
tasks and helps determine the minimum time needed to complete the project.

PERT charts are valuable for project managers as they provide a visual representation of the project's schedule,
dependencies, and critical paths, allowing for better planning, coordination, and decision-making throughout the project's
lifecycle.

What Are the 4 Steps to Create a PERT Chart?

To create a PERT chart, a project management team should follow these steps.
Step 1: Identify all of the project’s activities.
First, define all of the major phases, milestones, and tasks needed to complete the project.

Step 2: Identify dependencies

If you determine some tasks or activities have dependencies, you will want to depict those tasks with
directional arrows. This will ensure your team knows the sequence they need to tackle each task.

Step 3: Draw your chart.

The next step is to take the events and milestones (numbered nodes) you’ve identified and draw them out.
Then write out the tasks and activities that the team must complete between each node, using directional
arrows or divergent arrows accordingly.

Step 4: Establish timelines for all activities.

You should now set a timeframe when the team will need to complete those tasks along with all arrows. For
example, in our mockup above, you can see the “Train sales” activity has a timeframe of 1 day. This can
represent the estimated timeframe and/or deadline you set for the activity.
 Precedence network

In software project management, a precedence network is a graphical representation of the project's

activities and their dependencies. It is also known as a network diagram or a project network. The precedence
network helps project managers visualize the sequence of activities and understand the relationships and
dependencies among them.

The precedence network is typically created using a technique called the Precedence Diagramming Method
(PDM). In this method, activities are represented as nodes, and the dependencies between activities are
represented as arrows or links connecting the nodes. The nodes can also include additional information such
as activity duration, resource requirements, and milestones.

The relationships between activities in a precedence network are defined using different types of
dependencies, including:

1. Finish-to-Start (FS): The successor activity cannot start until the predecessor activity has finished.
2. Start-to-Start (SS): The successor activity cannot start until the predecessor activity has started.
3. Finish-to-Finish (FF): The successor activity cannot finish until the predecessor activity has finished.
4. Start-to-Finish (SF): The successor activity cannot finish until the predecessor activity has started.

"forward pass" and "backward pass

In software project management, the terms "forward pass" and "backward pass" are often used in the context of
project scheduling and critical path analysis. These concepts are part of the critical path method (CPM), a technique
used to determine the minimum time required to complete a project.

1. Forward Pass: The forward pass is the initial calculation performed during project scheduling. It involves determining
the earliest possible start and finish dates for each activity in the project network. The forward pass starts at the
project's beginning and progresses through the network until it reaches the end.
During the forward pass, each activity's start date and finish date are calculated based on the dependencies and
durations of preceding activities. The forward pass considers the activity's duration and the earliest start and finish
times of its preceding activities to calculate its own earliest start and finish times. By calculating these values, the
forward pass establishes a "forward" direction of scheduling through the project network.

The key outputs of the forward pass include the earliest start and finish times for each activity, as well as the project's
overall duration.

2. Backward Pass: The backward pass is the subsequent calculation performed after the forward pass. It determines the
latest possible start and finish dates for each activity in the project network. The backward pass starts at the project's
end and works backward through the network.
During the backward pass, each activity's latest start and finish dates are calculated based on the dependencies and
durations of its succeeding activities. The backward pass considers the activity's duration and the latest start and finish
times of its succeeding activities to calculate its own latest start and finish times. By calculating these values, the
backward pass establishes a "backward" direction of scheduling through the project network.
 Risk Breakdown Structure (RBS)
In project management, a Risk Breakdown Structure (RBS) is a hierarchical representation or classification of project
risks. It is similar to a Work Breakdown Structure (WBS), which breaks down project work into smaller, manageable
components. However, the RBS focuses on identifying and categorizing potential risks that could impact the success of
the project.

The main purpose of a Risk Breakdown Structure is to systematically identify, analyze, and manage risks throughout the
project lifecycle. It provides a framework for understanding the types of risks that may arise and helps project managers
and teams proactively plan and mitigate those risks.

The RBS typically consists of multiple levels or tiers, with each level representing a different level of detail or
granularity

Risk Breakdown Structure Example – IT Project

You can use a similar work breakdown structure (WBS) for developing a risk breakdown structure (RBS). A risk
breakdown structure organizes the risks that have been identified into categories using a chart with 3 different
levels: Risk Topic / Risk Categories / Risk factors). For example, the business category can be subdivided into
different types of risks associated with it, including Competitors, Suppliers, and Cash flow.

Breakdown Structure Example – IT Project

You can use a similar work breakdown structure (WBS) for developing a risk breakdown structure (RBS). A risk
breakdown structure organizes the risks that have been identified into categories using a chart with 3 different levels:
Risk Topic / Risk Categories / Risk factors). For example, the business category can be subdivided into different types of
risks associated with it, including Competitors, Suppliers, and Cash flow.

Benefits of a risk breakdown structure

A risk breakdown structure details project uncertainties in hierarchical order, which can help you understand the distribution of risk
within a project. Other reasons an RBS is a popular tool are because it allows you to:

• Present risks in a structured way that's easy to understand

• Summarize the risk management process
• Identify parts of the project with higher risk potential
• Detect areas requiring special attention
• Find out whether there are recurring risk themes
• Determine the total risk exposure of your project
•
How to create a risk breakdown structureHere are the steps you can take to create an RBS for a project:

2. Identify risk categories

3. Environmental
4. Political
5. Weather
6. Contractual
7. Client
8. Management
9. Technical
10. Financial 11. Schedule

Create subcategories:
For example, a construction company that lists "environmental hazards" as a risk category may create
subcategories for severe weather and extreme heat to help them create separate plans for each.

Identify each subcategory's specific risks

For instance, under the client category, you can divide it into smaller topics, such as the project team, the
client team, funding, targets and tactics.

Score the risk and impact:

After you divide the risks, you can assign scores to them to identify which might have the greatest impact on
the project.

Probability of risk occurrence:

High probability: Between 80% and 100%

Medium-high probability: Between 60% and 79%

Medium-low probability: Between 30% and 59%

Low probability: Less than 30%

Create a chart
Your last step is to create a risk breakdown chart for the categories and subcategories. This allows you to organize risks,
giving you a comprehensive overview of all risks related to the project. It can also make it easier for you and your team
to understand.

Risk
Risk in software project management refers to the potential for undesirable events or circumstances that can
impact the success or outcome of a software project. These risks can arise from various sources, including
technical, organizational, environmental, or human factors. Managing and mitigating risks is crucial to ensure
project success.

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

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-
related problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to
monitor and control a software project. It is very tough to control something which cannot be identified. For
 any manufacturing program, such as the manufacturing of cars, the plan executive can recognize the product
taking shape.

2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and
maintenance issue. It also consists of an ambiguous specification, incomplete specification, changing
specification, technical uncertainty, and technical obsolescence. Most technical risks appear due to the
development team's insufficient knowledge about the project.

3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing
budgetary or personnel commitments, etc.

Other risk categories

1. Known risks: Those risks that can be uncovered after careful assessment of the project program, the
business and technical environment in which the plan is being developed, and more reliable data sources
(e.g., unrealistic delivery date)

2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g., past turnover)

3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify in advance.

Risk Management Activities

Risk Assessment

The objective of risk assessment is to division the risks in the condition of their loss, causing potential. For risk
assessment, first, every risk should be rated in two methods:

o The possibility of a risk coming true (denoted as r).

o The consequence of the issues relates to that risk (denoted as s).

Based on these two methods, the priority of each risk can be estimated:

p=r*s
 Where p is the priority with which the risk must be controlled, r is the probability of the risk becoming true, and
s is the severity of loss caused due to the risk becoming true.

1. Risk Identification: The project organizer needs to anticipate the risk in the project as early as possible so
that the impact of risk can be reduced by making effective risk management planning.

A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project. It is
necessary to categories into the different risk of classes.

There are different types of risks which can affect a software project:

1. Technology risks: Risks that assume from the software or hardware technologies that are used to develop the
system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment where the software is being
developed.
4. Tools risks: Risks that assume from the software tools and other support software used to create the system.
5. Requirement risks: Risks that assume from the changes to the customer requirement and the process of
managing the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the resources required to build the
system

2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and make a
perception of the probability and seriousness of that risk.

There is no simple way to do this. You have to rely on your perception and experience of previous projects and
the problems that arise in them.

It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk.
Instead, you should authorize the risk to one of several bands:

1. The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%), high (50-75%) or
very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would cause
significant delays), tolerable (delays are within allowed contingency), or insignificant.

Risk Control

It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a plan are
determined; the project must be made to include the most harmful and the most likely risks. Different risks
need different containment methods. In fact, most risks need ingenuity on the part of the project manager in
tackling the risk.

There are three main methods to plan for risk management:

1. Avoid the risk: This may take several ways such as discussing with the client to change the requirements to
decrease the scope of the work, giving incentives to the engineers to avoid the risk of human resources turnover,
etc.
2. Transfer the risk: This method involves getting the risky element developed by a third party, buying insurance
cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For instance, if there is a risk that
some key personnel might leave, new recruitment can be planned.
 Risk Leverage: To choose between the various methods of handling risk, the project plan must consider the
amount of controlling the risk and the corresponding reduction of risk. For this, the risk leverage of the various
risks can be estimated.

Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.

Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of reduction)

1. Risk planning: The risk planning method considers each of the key risks that have been identified and develop
ways to maintain these risks.

For each of the risks, you have to think of the behavior that you may take to minimize the disruption to the plan
if the issue identified in the risk occurs.

You also should think about data that you might need to collect while monitoring the plan so that issues can be
anticipated.

Again, there is no easy process that can be followed for contingency planning. It rely on the judgment and
experience of the project manager.

3. Risk Monitoring: Risk monitoring is the method king that your assumption about the product, process,
and business risks has not changed.

UNIT 4

Project resources simply mean resources that are required for successful development and completion of
project. These resources can be capital, people, material, tool, or supplies that are helpful to carry out
certain tasks in project. Without these resources, it is impossible to complete project. In project planning
phase, identification of resources that are required for completion of project and how they will be allocated
is key element and very important task to do. In project management, some resources that are required are
assigned to each task of project to get job done.

There are three types of resources that are considered and are very essential for execution of project and
completion of project on time and on budget. These resources can be denoted by pyramid which is also
known as Resource Pyramid. At base of pyramid i.e. last layer, hardware and software tools are present,
then at middle layer, reusable components are present, and at top of pyramid i.e. top layer, human
resources are present. This is shown in following diagram :

resources, they specify it using four characteristics :

• Description of resource
• Resource availability
• Time of resource when it will be available
• Duration of resource availability

Human Resource –
positions are according to their skills and specialty.
For small project only, single individual can perform all these roles. But for large project, team of people
works on it. The total number of people that are required for project is estimated by calculating
development effort inters of person-months.
Reusable Components –
For bringing ease in software development process or to accelerate develmt process software, industry
prefers to use some ready s/w components. The components can be defined as the s/w building blocks that
can be created and reused in s/w develmt process

Hardware and Software tools –

actually material resources that are part of project. This type of resource should be planned before starting
development of project otherwise it way causes problems

Identifying resource

Identifying resource requirements is an essential step in software project management to ensure that the necessary
people, tools, and infrastructure are available to successfully complete the project. Here are some key considerations
and steps to follow when identifying resource requirements:

1. Project Scope: Start by understanding the project scope, objectives, and deliverables. This will help you determine the
type and quantity of resources needed.

2. Project Plan: Review the project plan, including the timeline, milestones, and tasks. Break down the project into smaller
components to identify the specific resource requirements for each phase or task.

3. Roles and Responsibilities: Identify the roles and responsibilities required for the project. This includes project
managers, developers, testers, designers, subject matter experts, and other team members. Define the skills,
experience, and expertise needed for each role.

4. Resource Types: Determine the types of resources required. This includes human resources (e.g., project team
members, stakeholders, contractors), hardware (e.g., servers, workstations), software (e.g., development tools, testing
tools), and any other resources specific to your project (e.g., specialized equipment, licenses).

5. Resource Availability: Assess the availability of resources within your organization or externally. Consider factors such
as the availability of skilled personnel, their workload, and their availability during different project phases. Determine if
any resources need to be acquired or hired externally.

6. Resource Quantities: Estimate the quantities of resources needed based on the project plan, timelines, and work
breakdown structure. Consider the number of team members required, the number of workstations, licenses, and any
other resources needed.

7. Resource Constraints: Identify any constraints or limitations that may impact resource availability or allocation. These
could include budget constraints, physical space limitations, legal or regulatory requirements, or limitations imposed by
external stakeholders.

8. Resource Allocation: Once you have identified the resource requirements, allocate the resources based on the project
plan and priorities. Consider factors such as resource availability, skillsets, and workload distribution.

9. Resource Management: Continuously monitor and manage the resources throughout the project lifecycle. Ensure that
resources are utilized effectively, identify and resolve any resource conflicts or bottlenecks, and make adjustments as
needed to meet project objectives.
10. Contingency Planning: Develop contingency plans for any potential resource risks or issues that may arise during the
project. This includes identifying alternative resources or backup plans to mitigate any adverse impacts on the project.

Visualizing progress

Visualizing progress in software project management is crucial for tracking and communicating the status of a project
effectively. It helps stakeholders understand the project's current state, identify bottlenecks, and make informed
decisions. Here are a few common techniques for visualizing progress in software project management:

1. Gantt Charts: Gantt charts provide a visual representation of project tasks, their dependencies, and the overall timeline.
They use horizontal bars to represent tasks and their durations. Gantt charts allow you to track the progress of each
task, identify critical paths, and adjust schedules accordingly.

2. Kanban Boards: Kanban boards are commonly used in Agile project management methodologies like Scrum. They
visually represent project tasks as cards that move across different stages or columns, such as "To Do," "In Progress,"
and "Done." Kanban boards provide a clear view of work in progress, bottlenecks, and overall workflow efficiency.

3. Burn-Down Charts: Burn-down charts show the remaining work (backlog) plotted against time. They help teams track
progress and visualize if they are on track to complete the project within the desired timeline. Burn-down charts can be
used at different levels, such as for the overall project or specific iterations/sprints.

4. Cumulative Flow Diagrams: Cumulative flow diagrams (CFDs) provide a visual representation of work items in different
stages over time. They show the flow of work through different states, such as backlog, in progress, and completed.
CFDs help identify bottlenecks, predict project completion, and measure the overall efficiency of the development
process.

5. Release Burndown Charts: Release burndown charts track the completion of project features or user stories over time.
They show the remaining work for each feature plotted against time. Release burndown charts help teams monitor
progress, make adjustments, and estimate when they will complete the planned features.

6. Velocity Charts: Velocity charts are used in Agile methodologies to measure the amount of work a team can complete
within a given time frame (e.g., sprint). They show the historical data of completed user stories or story points over
several iterations. Velocity charts help teams understand their average productivity, plan future iterations, and make
informed commitments.

7. Dashboards and Reports: Software project management tools often provide dashboards and reports that consolidate
project data and metrics into visual formats. These visualizations can include progress indicators, task status, resource
allocation, and team performance. Dashboards and reports offer a comprehensive view of the project's health and allow
stakeholders to assess progress at a glance.

Project tracking

Project tracking is an essential component of software project management. It involves monitoring and documenting
the progress of a project to ensure that it stays on schedule and within budget. By tracking various aspects of the
project, such as tasks, milestones, resources, and risks, project managers can effectively manage and control the
project's execution.

Here are some key elements and techniques commonly used in project tracking within spm :-

1. Work Breakdown Structure (WBS): Start by creating a WBS, which breaks down the project into smaller, manageable
tasks and sub-tasks. Each task should have a clear deliverable and defined start and end dates.

2. Project Schedule: Develop a project schedule that outlines the planned start and end dates for each task. It helps in
visualizing the overall project timeline and dependencies.

3. Task Assignments: Assign tasks to team members and track their progress. You can use project management tools like
Asana, Jira, or Trello to assign tasks, set due dates, and monitor their status.
4. Milestones: Define key milestones that mark significant stages or achievements within the project. Milestones provide
checkpoints to assess progress and evaluate whether the project is on track.

5. Progress Reporting: Regularly review and update the status of tasks and milestones. Team members should report their
progress, and project managers should consolidate this information to track overall project progress.

6. Gantt Charts: Gantt charts are useful visual representations of project schedules. They display tasks as horizontal bars
along a timeline, allowing project managers to visualize task dependencies, durations, and overlaps.

7. Resource Management: Track resource allocation and utilization to ensure that team members are appropriately
assigned to tasks and have the necessary resources to complete their work.

8. Risk Management: Identify potential risks and track them throughout the project. Maintain a risk register to document
risks, assess their impact and probability, and define mitigation strategies. Regularly review and update the risk register
as the project progresses.

9. Budget Tracking: Monitor project expenditures and compare them against the planned budget. Regularly review and
adjust financial plans as needed.

10. Communication: Maintain open and transparent communication channels with the project team and stakeholders.
Regularly provide updates on project progress, discuss any issues or challenges, and seek feedback.

11. Agile Approaches: If following an agile methodology, use techniques like user stories, burndown charts, and Kanban
boards to track progress, prioritize tasks, and manage work in an iterative and incremental manner.

Status reports

Status reports in project management are regular updates that provide information about the progress,
accomplishments, issues, and challenges of a project. These reports help project managers, stakeholders, and team
members stay informed and make informed decisions. Here are some key elements typically included in a status report:

1. Project Summary: Begin the report with a brief overview of the project, including its objectives, scope, and key
milestones.

2. Key Accomplishments: Highlight the significant achievements and milestones reached since the last report. This could
include completed tasks, deliverables, or any other noteworthy progress.

3. Work Completed: Provide a detailed breakdown of the tasks and activities that have been completed during the
reporting period. Include information such as start and end dates, effort expended, and any dependencies or constraints
encountered.

4. Work in Progress: Describe the ongoing tasks and activities currently being worked on, along with their estimated
completion dates and any potential challenges or risks.

5. Issues and Challenges: Identify any problems, obstacles, or risks that have been encountered during the project. Explain
their impact on the project timeline, budget, or scope, and outline any mitigation strategies or actions being taken.

6. Changes or Deviations: If there have been any changes to the project plan or scope, or if the project is deviating from
the original plan, document those changes and their implications.

7. Budget and Resources: Provide an update on the project's financial status, including budget utilization, any variations
from the initial budget, and resource allocation and utilization.

8. Next Steps: Outline the upcoming tasks, milestones, and activities planned for the next reporting period. This helps
stakeholders understand the project's future direction and anticipate potential challenges.

9. Risks and Mitigation: Identify and assess any potential risks or issues that could impact the project's success. Discuss
mitigation strategies or actions taken to address these risks.
10. Stakeholder Communication: Briefly summarize any important communication or interactions with project
stakeholders, such as clients, team members, or senior management.

11. Conclusion: Summarize the overall status of the project, highlighting key achievements, challenges, and upcoming
milestones. If additional support or resources are needed, mention them here.

Status reports can be created on a weekly, bi-weekly, or monthly basis, depending on the project's duration and
complexity. They should be concise, informative, and easily understood by all relevant stakeholders. The format and
level of detail may vary depending on the specific requirements of the project and the preferences of the project
manager and stakeholders.

Milestone Analysis

Milestone Analysis is a technique used in project management to identify and track significant events or achievements
within a project. It involves the identification of specific points in a project's timeline that represent important
deliverables, outcomes, or decision points.

The primary purpose of milestone analysis is to provide a clear visual representation of the project's progress and to
help project stakeholders understand the key events and their respective timelines. By setting milestones, project
managers can break down the project into manageable phases and track progress against those milestones.

Milestone Analysis provides several benefits to project management, including:

• Improved project planning: By breaking down the project into milestones, it becomes easier to plan and allocate
resources effectively.
• Progress monitoring: Milestones serve as reference points for measuring progress and enable project managers to
identify any delays or issues early on.
• Enhanced communication: Milestone analysis helps in facilitating effective communication among project stakeholders,
as it provides a clear overview of the project's progress.
• Decision-making support: Milestones act as decision points where project managers can assess the project's
performance and make informed decisions about future actions.
•
 comparison between actual effort and schedule
In project management, there is often a comparison between actual effort and schedule against the estimated effort
and schedule. This analysis helps assess the performance of the project, identify any discrepancies or variances, and
make informed decisions for future projects. Here's a breakdown of the actual versus estimated analysis in project
management:

1. Actual Effort: This refers to the actual amount of work that has been put into the project. It can be measured in terms of
hours, days, or any other unit of time. The actual effort is typically recorded by team members who log their time spent
on various project activities.

2. Estimated Effort: This is the initial estimation of the effort required to complete project tasks. It is determined during
the planning phase based on factors such as the scope of work, complexity, available resources, and team expertise. The
estimated effort serves as a baseline for comparison throughout the project.

3. Actual Schedule: The actual schedule reflects the actual timeline in which project tasks were completed. It takes into
account any delays or accelerations that may have occurred during the project execution. The actual schedule is usually
tracked using project management software or tools, with tasks and milestones marked as completed or delayed.

4. Estimated Schedule: The estimated schedule is the initial timeline or project plan developed during the planning phase.
It outlines the sequence of tasks, their durations, and dependencies. It serves as a reference to compare against the
actual schedule and identify any deviations.

5. Variance Analysis: Once the project is underway, a variance analysis is performed to compare the actual effort and
schedule against the estimated values. This analysis involves calculating the differences or variances between the actual
and estimated effort and schedule.

a. Effort Variance: Effort variance measures the difference between the actual effort and the estimated effort. It helps
identify if the project is over or under budgeted in terms of time spent. Positive variance indicates less effort than
expected, while negative variance suggests more effort.

b. Schedule Variance: Schedule variance compares the actual schedule with the estimated schedule. It provides insights
into whether the project is ahead of or behind schedule. Positive variance indicates that the project is ahead of
schedule, while negative variance implies delays.

6. Performance Evaluation: Based on the variance analysis, project managers and stakeholders can evaluate the project's
performance. They can identify the root causes of any deviations, assess the impact on project objectives, and take
corrective actions if necessary. This evaluation helps in managing project risks, making adjustments to future planning,
and improving estimation accuracy.

software quality attributes in software project management

In software project management, software quality attributes refer to the characteristics or properties of a
software system that determine its overall quality. These attributes help measure and evaluate the
performance, reliability, maintainability, and other aspects of the software. Here are some commonly
recognized software quality attributes:

Functionality: This attribute measures the degree to which the software satisfies the specified functional
requirements and performs its intended tasks accurately and efficiently.

Reliability: Reliability refers to the ability of the software to perform its intended functions consistently and
predictably over a specific period or under specific conditions, without failure or errors.

Usability: Usability relates to how easily and effectively users can interact with the software. It includes
aspects such as user interface design, user experience, intuitiveness, and learnability.
Performance: Performance focuses on the speed, responsiveness, scalability, and efficiency of the software in
terms of executing its functions and handling workload or user interactions.

Maintainability: Maintainability refers to the ease with which the software can be modified, extended,
repaired, or adapted over time. It includes factors like code readability, modular design, documentation, and
overall ease of understanding and modifying the software.

Portability: Portability measures the ease with which the software can be transferred or adapted to different
hardware, operating systems, or environments. It involves considerations such as platform independence,
compatibility, and adaptability.

Security: Security ensures that the software system is protected against unauthorized access, data breaches,
or malicious attacks. It includes aspects such as data encryption, user authentication, access controls, and
vulnerability management.

Testability: Testability refers to the ease with which the software can be tested and verified to ensure that it
meets the specified requirements. It involves factors such as the availability of testing tools, the ease of
setting up test environments, and the observability of the software's internal state.

Scalability: Scalability measures the software's ability to handle increasing workloads, user demand, or data
volume without sacrificing performance or stability. It includes factors like the software's architecture,
resource utilization, and capacity planning.

Interoperability: Interoperability relates to the software's ability to interact and exchange data with other
systems or components seamlessly. It includes standards compliance, data formats, and protocols used for
integration.

ISO/IEC 9126
ISO/IEC 9126 is an international standard proposed to make sure ‘quality of all software-intensive
products’ which includes a system like safety-critical where in case of failure of software lives will be in
jeopardy. ISO i.e. International Organization for standardization and IEC i.e. International Electrotechnical
Commission have developed ISO/IEC 9126 standards for software engineering –> Product Quality to
provide an all-inclusive specification and evaluation model for the quality of the software product.
The standard is divided into 4 parts as depicted in the following figure :

Part-1 Software Engineering – Product Quality “Quality model” :

It describes quality model framework which explains relationships between different approaches to quality
as well as identifying quality characteristics and sub-characteristics of software products.
Part-2 Software Engineering – Product Quality “External Metrices” :
It’s use is to describes external metrices that are used to measure characteristics and sub-characteristics
which are identifies in part 1.
Part-3 Software Engineering – Product Quality “Internal Metrices” :
It’s use is to describes internal metrices that are used to measure characteristics and sub-characteristics
which are identifies in part 1.
Part-4 Software Engineering – Product Quality “Quality in use metrices” :
It’s use is to identify metrices which are used to measure effects of combined quality characteristics for
user.
 As from above discussion, it is concluded that first three parts are concerned with describing and measuring
quality of software product and fourth part concerned about quality of software product from user point of
view.
Furthermore, first part i.e. Quality model is concerned classified into two categories as depicted in the
following figure :

Project closure
Project closure in software project management refers to the formal process of bringing a software project to
an end. It involves completing all remaining activities, documenting the project's outcomes, and formally
transferring the project to its stakeholders. Project closure is an essential phase that helps ensure a smooth
transition from the project to the operational phase or the next project.

Here are the key steps involved in project closure in software project management:

1. Deliverables review: Evaluate all project deliverables against the defined requirements and quality criteria.
This includes reviewing the software code, documentation, test results, and any other artifacts produced
during the project.

2. User acceptance testing: Conduct user acceptance testing (UAT) to validate that the software meets the
intended functionality and user requirements. UAT involves involving end-users or representatives to test the
software and provide feedback.

3. Defect resolution: Address any outstanding defects or issues identified during the testing phase. Fixing these
defects ensures that the software meets the required quality standards before closure.

4. Documentation and knowledge transfer: Document all project-related information, including technical
specifications, user manuals, configuration details, and any other relevant documentation. Additionally,
transfer knowledge to the stakeholders who will be responsible for maintaining and supporting the software
after the project closure.

5. Lessons learned: Conduct a lessons learned session to capture the project team's experiences, challenges
faced, and best practices identified during the project. This information can be valuable for future projects
and can help improve processes and decision-making.

6. Financial closure: Review and finalize the project's financial aspects, including budget utilization, expenses,
and any outstanding financial obligations.

7. Stakeholder communication: Communicate the project closure to all relevant stakeholders, including the
project team, management, clients, and end-users. Provide them with a summary of the project's
achievements, outcomes, and any remaining tasks or responsibilities.

8. Project review and evaluation: Evaluate the project's performance against its initial objectives, timelines, and
budget. Assess the success criteria, identify areas for improvement, and document recommendations for
future projects.
9. Project handover: Transfer the project's deliverables, documentation, and responsibilities to the relevant
stakeholders, such as the operations or maintenance team. Ensure that all necessary training and support are
provided to facilitate a smooth handover.

10. Formal closure: Obtain formal sign-off or approval from the project sponsor or client to signify the official
closure of the project. This may include documenting the closure in a project closure report or a final project
review document.

11.
Metrices for Project Closure:
Metrices Significant

1. Size variance How much did the estimate size of the workProducts vary from its actual
size.
2. Effort variance How much did the estimated effort on the projectVary from actual effort.
3. Schedule variance How much did the estimated schedule on the projectVary From the actual
schedule.
4. N4.Number of changes made tothe Process changes could be any of the following:
project (i)Change in the method of estimation of size or effort.(ii)Change in the
organizational structure.
(iii)Change in the operational procedure.(iv)Change in the work load
distribution.
5. S/W tool enhancement If new tooling is supported/suggested changes are that thisWould lead to
higher productivity.
6. Employee Satisfaction It can be estimated by formal & informal survey.

1. Role of Closure Analysis The objective of Closure Analysis Report is :

2. Determine what went wrong -
3. What went right –
4. What worked –
5. What did not work –
6. How to make it better next time .
7. Relevant information needs to be collected from the project, for future projects. •
8. Also this analysis throws light on performance of the process on project and its capability.