Chapter 1

Project, so ware project management, Need of so ware project management, Advantages of

so ware project management
Impotence of Software Project Management
1. Proper Planning: It helps in organizing tasks, setting timelines, and managing resources so
that the work is well-structured from the beginning.
2. Easier Development: Breaking the project into smaller, manageable steps makes it easier to
build the software without confusion or delays.
3. Tracking Progress: It allows you to monitor how the project is going and make adjustments if
things are not on track.
4. Saving Time and Money: By planning and managing resources effectively, it reduces
unnecessary costs and ensures the project is completed on time.
5. Handling Risks: It helps identify potential problems early and prepares solutions to avoid
delays or failures.
6. Ensures Quality: Clear goals and standards are set, so the final software meets expectations
and works as intended.
7. Improves Teamwork: It ensures good communication between team members and
stakeholders, keeping everyone on the same page.

Activity covered by Software Project Management

P RSE RSC C
 Different between methods and Methodologies

Aspect Methods Methodologies

Defini on Methods are specific steps or techniques to Methodologies are frameworks of methods
complete a task. and principles to guide the overall project
process.
Scope Methods are focused on individual tasks or Methodologies cover the en re project
ac vi es. lifecycle or process.
Purpose Methods focus on execu ng specific tasks Methodologies focus on planning and
effec vely. managing the en re project.
Focus Methods emphasize how to perform specific Methodologies emphasize why and what
tasks. approach should be followed.
Applica on Methods apply to specific tasks or a single Methodologies apply to the en re structure
Level phase of work. of a project.
Flexibility Methods are rigid and task-specific. Methodologies are flexible and adaptable to
project needs.
Examples Examples of methods include tes ng or Examples of methodologies include Agile,
coding a feature. Waterfall, or Scrum.
Output Methods deliver results for specific tasks or Methodologies ensure the project progresses
ac ons. toward its overall goal.
Detail Level Methods provide detailed, step-by-step Methodologies give high-level guidance with
instruc ons. room for task-specific adjustments.

Ways of Categorizing So ware

1. Compulsory vs Voluntary Systems
 Compulsory Systems:
These are systems that users are required to use to complete specific tasks, often mandated by
an organization.
Example: Payroll system or attendance management system.
 Voluntary Systems:
These are systems that users willingly to use voluntarily for personal or non-essential purposes.
Example: Gaming applications or school projects.
2. Information Systems vs Embedded Systems
 Information Systems:
These systems are used by employees to manage office processes and operations like data
handling or workflow management.
Example: Stock control system in warehouses.
 Embedded Systems:
These are systems designed to control specific hardware or machinery and are embedded within
devices.
Example: Systems controlling elevators or home automation systems.
3. Objective-Based vs Product-Based Systems
 Objective-Based Systems:
The focus of these projects is to achieve specific objectives or goals. The implementation
approach can vary.
Example: A project to enhance customer satisfaction metrics.
 Product-Based Systems:
These projects aim to create a specific product as per client specifications. The product's
requirements and features are predefined.
Example: Developing an e-commerce platform for a retail business.
By categorizing software projects, it becomes easier to plan, develop, and manage them according to
their specific requirements and goals.
Phases of project management life cycle
The project management life cycle comprises four distinct phases that guide a project from inception to
completion. These phases ensure that all aspects of the project are systematically planned, executed,
and finalized.
Four phases of project management life cycle
1. Initiation: Nature and scope of the project
The initiation phase is the very first phase of the project management life cycle. During this phase, a
project manager must develop a business case for the project. Whether they undertake a feasibility
study or establish a project charter, making sure the rest of the team understands the importance of
the project is key. During this phase, a project team is appointed.
2. Planning: Time, cost, resources, and scheduling
As you may have already guessed, a lot of planning takes place during this phase. Depending on the
specifics of your project, you may need to complete all (or just a few) of the following:
 Project plan
 Resource plan
 Financial plan
 Quality plan
 Risk plan
 Acceptance plan
 Communications plan
 Procurement plan
3. Execution: Processes used to complete the project
Two things happen during the execution phase:
1) deliverables are built, and
2) the project is monitored and controlled.
In some cases, this means going through time management procedures step-by-step, and in others,
it could mean performing a risk assessment so you can identify any risks you could expect throughout
the life of the project. Depending on your project, you may need to perform all (or just a handful) of
the following:
 Time management
 Cost management
 Quality management
  Change management
 Risk management
 Issue management
 Procurement management
 Acceptance management
 Communications management
4. Closure: Formal end of project
The closing phase signifies what is project management.
During this phase, project managers wrap the project up into any loose ends and perform any project
closure activities.
Once the project is closed, the project manager should review the project completion with their team.
During this review, the benefits and objectives should be measured, the project spend should be
compared to the budget, and final deliverables should be assessed.
At this time, you should be able to identify key project achievements and milestones, document any
lessons learned for future projects, and communicate the success of the project to stakeholders and
executives.

Stakeholders of a project and their objec ves

1. Internal Stakeholders
These are individuals or groups directly involved in the project’s execution and development.
Examples include:
 Project Manager: Oversees the project, ensuring it is delivered on time, within budget,
and meets quality standards.
 Project Team: Performs the tasks required to complete the project, including
development, testing, and deployment.
 Company (Organization): Provides resources (personnel, infrastructure) and ensures
alignment with business goals.
 Funders: Provide financial support to ensure the project progresses smoothly.
Objectives:
 Ensure timely and quality delivery of the project.
 Achieve alignment with organizational goals.
 Efficiently use resources and meet budget constraints.
2. External Stakeholders
These are individuals or groups indirectly involved in the project but significantly affected by its
outcome. Examples include:
 Customers: Receive the end product or service. Their goal is to meet their needs and
expectations.
 Suppliers/Vendors: Provide materials, tools, or services essential for the project.
 Government/Regulatory Bodies: Ensure compliance with laws, regulations, and
standards.
 Consultants: Offer expertise or advice to improve project quality.
Objectives:
 Ensure the project delivers a usable and beneficial output.
 Gain value from the product or service created.
 Achieve compliance with standards and regulations.
Chapter 2

Project Planning

Project Planning Steps:

1. Initiation:
o Before the project officially starts, the initiation phase determines the project's need and
feasibility. The team develops a business case that explains why the project is important
and what problems it will solve. Afterward, a feasibility study is conducted to evaluate
whether the project is viable in terms of cost, time, and potential benefits.
o Example: For a software development project, the business case might explain the need
for a new customer support system and its expected benefits in improving response
times.
2. Stakeholder Involvement:
o In this step, you identify key stakeholders such as project sponsors, team members, and
clients. Engage with them to understand their expectations and requirements. It’s
crucial to ensure everyone is aligned on the project’s scope, budget, and timeline, and to
secure their buy-in.
o Example: Meeting with stakeholders early on ensures that any concerns or additional
requirements are addressed, reducing the chances of conflicts later in the project.
3. Prioritizing Goals:
o A project often has multiple objectives. Prioritizing these goals helps the team stay
focused on what is most important. Not all goals can be accomplished equally, so
focusing on key objectives, like completing the core functionalities of a software product
before adding additional features, is essential.
 o Example: In a project to build a mobile app, prioritizing goals might mean focusing first
on the app’s functionality over aesthetic design.

4. Identifying Deliverables:
o This step involves defining the specific outputs or results expected from the project. Each
deliverable should have a clear deadline and set of success criteria. Metrics can be
established to track the quality and timeliness of each deliverable.
o Example: For a website development project, a deliverable could be "a fully functional
homepage," and success is defined as "loads within 3 seconds and is responsive across
all devices."
5. Scheduling:
o Based on the previous steps, a timeline is created for the project. Tasks are broken down
and assigned deadlines. Scheduling involves mapping out when each task needs to be
completed, considering task dependencies and resource availability.
o Example: Using a Gantt chart or project management tool to visually represent the
project timeline helps ensure that the team stays on track and meets deadlines.
6. Developing a Project Plan:
o A project plan consolidates all the information from previous steps into a structured
format. It details the activities, resources, timelines, and workflow needed to complete
the project. The project plan acts as the roadmap for the project’s execution.
o Example: A software development plan would include timelines for coding, testing, and
deployment phases, with assigned team roles for each task.
7. Bake in Contingency Plans:
o No project goes perfectly, so it’s essential to anticipate potential risks and challenges. A
contingency plan prepares the team for unforeseen issues by providing alternative
strategies for managing problems like budget overruns or delays.
o Example: If a key resource becomes unavailable, a contingency plan could involve
reallocating tasks to other team members to prevent project delays.

So ware Development Life Cycle Model

Work Breakdown Structure (WBS)
A Work Breakdown Structure (WBS) is a project management tool that breaks down a project
into smaller, manageable tasks or components. It provides a hierarchical decomposi on of the
work required to complete the project, ensuring alignment with project scope, schedule, and
cost baselines.

Importance of WBS
1. Improved Planning: By dividing the project into manageable pieces, WBS facilitates
be er planning, scheduling, and execu on.
2. Resource Alloca on: It helps in alloca ng resources efficiently to specific tasks and
deliverables.
3. Cost Tracking: The cost of each task can be iden fied, aiding in budget management.
4. Progress Monitoring: Task dependencies, start and end dates, and task statuses can be
tracked easily.
5. Clear Communica on: A WBS ensures clarity among team members and stakeholders
regarding deliverables and expecta ons.
Types of WBS structure
Work Breakdown Structures (WBS) can be categorized into Deliverable-Based WBS and Phase-
Based WBS, each designed to suit different project needs. Below is an explana on of these
types, accompanied by their advantages.
1. Deliverable-Based WBS
A Deliverable-Based WBS organizes the project work around the final deliverables of the
project, such as products, services, or results. Each level of the WBS represents a breakdown of
the deliverables into smaller components un l the tasks needed to complete each deliverable
are clearly iden fied.
Example Structure (for a House Construc on Project):
 Level 1 (Main Deliverables):
o Internal Work
o Founda on
o External Work
 Level 2 (Sub-deliverables):
o Internal Work: Electrical, Plumbing
o Founda on: Excava on, Steel Erec on
o External Work: Masonry, Finishes

Advantages:
 Clear linkage between project scope and deliverables.
 Makes it easy to track progress for specific deliverables.
 Ideal for projects with clearly defined outputs.
2. Phase-Based WBS
A Phase-Based WBS organizes tasks based on the phases of the project lifecycle. These phases
typically include ini a on, planning, execu on, monitoring and control, and closure. This
approach is par cularly useful for projects that follow a sequen al or itera ve development
process.
Example Structure (for a House Construc on Project):
 Level 1 (Project Phases):
o Ini a on
o Planning
o Execu on
o Closure
 Level 2 (Tasks within Phases):
o Execu on: Founda on, Framing, Plumbing
o Closure: Inspec on, Final Approval

Advantages:
 Focuses on project management processes, ensuring each phase is completed.
 Useful for projects with itera ve development or requiring phase-by-phase progress
tracking.
 Simplifies planning and resource alloca on for each project phase.
Product Breakdown Structure (PBS) vs Work Breakdown Structure (WBS)
Both Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS) are essen al
tools in project management, but they serve different purposes. While the PBS focuses on
breaking down the end product into its components, the WBS emphasizes breaking down the
work required to create those components. Below is an explana on of these structures with
examples.
1. Product Breakdown Structure (PBS)
A Product Breakdown Structure (PBS) is a hierarchical diagram that breaks down the final
product into smaller, more manageable components or sub-products. It helps teams visualize
the deliverables required to complete the project.
Key Features of PBS:
 Focuses solely on the product and its components.
 Represents the physical or func onal parts of the product.
 Does not include the tasks or processes needed to create the product.
Example: For a project to build a Car, a PBS might look like this:

Advantages of PBS:
1. Provides a clear understanding of the product structure.
2. Helps iden fy all required components for the final product.
3. Facilitates cost es ma on and procurement of materials.
4. Focuses teams on product-related deliverables.
2. Work Breakdown Structure (WBS)
A Work Breakdown Structure (WBS) is a hierarchical decomposi on of all the work required to
complete a project. It breaks the project into smaller work packages, each represen ng a task or
set of tasks.
Key Features of WBS:
 Focuses on the tasks or work needed to create the product.
 Includes all processes, ac vi es, and deliverables required to complete the project.
 Ensures alignment between project scope, schedule, and budget.
Example: For the same Car Construc on Project, a WBS might look like this:

Advantages of WBS:
1. Helps manage the project by breaking it into smaller, manageable tasks.
2. Facilitates resource alloca on, scheduling, and cost tracking.
3. Ensures all necessary work is accounted for, reducing the risk of missing tasks.
4. Makes progress tracking and repor ng easier.
how to choose process model
A Process Model is a structured framework that defines the ac vi es, tasks, and steps required
to develop so ware. It provides a systema c approach to plan, implement, test, deliver, and
maintain so ware, ensuring the process is organized and efficient. Process models help manage
complexity, improve quality, and align development with business objec ves.
Examples of process models include:
 Waterfall Model: A sequen al approach with fixed phases like requirements, design,
development, tes ng, and deployment.
 Agile Model: An itera ve and flexible approach allowing changes at any stage.
 Spiral Model: Combines itera ve development with risk management.
 Incremental Model: Breaks development into smaller, deliverable increments.
 V-Model: Focuses on valida on and verifica on at every stage of development.
Choosing the right process model for a project is crucial to its success. Below are the factors and
their explana ons point-wise:
1. Project Requirements
 "Before you choose a model, take some me to go through the project requirements."
 If the requirements are clear and fixed:
o Use the Waterfall Model because it provides a structured approach for well-
defined requirements.
 If the requirements are unclear or evolving:
o Use the Agile Model for flexibility in adap ng to changes.
o Use the Spiral Model for itera ve development combined with risk management.
2. Project Size
 Consider the size of the project you will be working on. Larger projects mean bigger teams,
so you’ll need more extensive and elaborate project management plans.
o For small projects:
 Use the Waterfall Model for its simplicity.
 Use the Agile Model if there is a need for quick itera ons and feedback.
o For large projects:
  Use the Spiral Model, as it allows for risk assessment and itera ve
development.
 Use the Incremental Model, as it divides the project into manageable
phases and delivers parts of the product incrementally.
3. Project Complexity
 Complex projects may not have clear requirements. The requirements may change o en,
and the cost of delay is high.
o For highly complex projects:
 Use the Spiral Model, as it handles risks and complexity effec vely.
 Use the Agile Model, as it provides adaptability for managing changing and
complex requirements.
o For less complex projects:
 Use the Waterfall Model, as it is straigh orward and suitable for well-
understood projects.
4. Cost of Delay
 Is the project highly me-bound with a huge cost of delay, or are the melines flexible?
o If me-to-market is cri cal:
 Use the Agile Model, as it delivers incremental results quickly.
 Use the Incremental Model, which enables early delivery of func onal
components.
o If melines are flexible:
 Use the Waterfall Model, as it is methodical and ensures a complete
product before release.
5. Customer Involvement
 Do you need to consult the customers during the process?
o If frequent customer feedback is needed:
 Use the Agile Model, as it involves regular interac on and adaptability.
o If customer involvement is minimal:
 Use the Waterfall Model or V-Model, as they follow a more rigid,
predefined process.
6. Familiarity with Technology
 This involves the developer’s knowledge and experience with the project domain,
so ware tools, language, and methods needed for development.
o If the team has strong exper se:
 Use any process model, depending on other factors like requirements and
complexity.
o If the team lacks exper se:
 Use a simpler model like the Waterfall Model or Incremental Model to
minimize technical risks.
7. Project Resources
 This involves the amount and availability of funds, staff, and other resources.
o If resources are limited:
 Use the Agile Model, as it is lightweight and focuses on delivering results
quickly.
o If resources are abundant:
 Use the Spiral Model, as it allows thorough planning, risk analysis, and
phased delivery.

Prototype process model

The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models). This model is used when the customexrs 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.
Steps of Prototyping Model
Step 1: Requirement Gathering and Analysis: This is the initial step in designing a prototype
model. In this phase, users are asked about what they expect or what they want from the system.
Step 2: Quick Design: This is the second step in the Prototyping Model. This model covers the
basic design of the requirement through which a quick overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype from the knowledge
gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strengths and
weaknesses of the design, which was sent to the developer.
Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase of the Prototyping
Model where the final system is tested and distributed to production, here the program is run
regularly to prevent failures.
Advantages of the Prototyping Model:
1. Improved Customer Satisfaction: Customers can see a working model early, ensuring
their feedback shapes the final product.
2. Flexibility in Requirements: Accommodates new or changing requirements easily.
3. Early Detection of Errors: Identifies design flaws and missing functionalities early, saving
time and cost.
4. Enhanced Communication: Facilitates better understanding among developers,
customers, and stakeholders through tangible prototypes.
5. Risk Reduction: Helps identify potential issues and validate design decisions before
committing significant resources.
Disadvantages of the Prototyping Model:
1. High Cost and Time: Iterative development can be expensive and time-consuming.
2. Uncertain Iterations: Difficulty in predicting the number of iterations needed to finalize
the product.
3. Risk of Unrealistic Expectations: Early prototypes may create false expectations about
the final product's delivery timeline or features.
4. Suboptimal Solutions: Developers may prioritize speed over quality in prototype
development, leading to design compromises.
5. Documentation Challenges: Frequent changes can result in poor or incomplete
documentation.
Extreme Programming (XP)
Extreme Programming (XP) is an Agile software development methodology designed to improve
software quality and responsiveness to evolving customer requirements.
It emphasizes frequent releases, iterative development, and strong collaboration between
developers, customers, and stakeholders.
XP is especially suitable for projects with dynamic requirements, tight deadlines, or a need for
high-quality software.

Key Practices of Extreme Programming

1. Continuous Planning
XP uses user stories to capture requirements in a concise and value-focused manner.
Planning is iterative, with frequent adjustments based on feedback and project progress.
Development is organized into short iterations, typically lasting one to two weeks,
allowing for regular evaluation and reprioritization.
2. Small Releases
XP emphasizes delivering small, functional increments of the software to users frequently.
These small releases ensure continuous delivery of value, provide opportunities for
feedback, and allow developers to adapt quickly to new requirements.
3. Test-Driven Development (TDD)
In TDD, developers write automated tests before writing the actual code. This practice
ensures that the code meets predefined requirements and reduces the likelihood of
defects. TDD helps maintain high-quality software and supports easier refactoring.
4. Pair Programming
 Pair programming involves two developers working together on the same task at one
workstation. One developer writes the code while the other reviews it in real time. This
practice improves code quality, enhances team collaboration, and facilitates knowledge
sharing within the team.
5. Collective Code Ownership
In XP, the entire team takes collective responsibility for the codebase. Any team member
can make changes to any part of the code at any time. This practice prevents bottlenecks,
encourages shared knowledge, and promotes consistent code quality.
6. Continuous Integration
Developers frequently integrate their code into a shared repository, often multiple times
a day. Automated tests are run after each integration to identify and fix issues early.
Continuous integration helps maintain a stable and functioning codebase throughout the
project.
7. Refactoring
Refactoring involves continuously improving the internal structure of the code without
altering its external behavior. This ensures that the code remains simple, clean, and easy
to maintain over time.
8. Sustainable Pace
XP emphasizes working at a sustainable pace to avoid burnout. Teams are encouraged to
maintain consistent productivity without overworking, ensuring long-term effectiveness
and morale.
9. On-Site Customer
XP requires an on-site customer or customer representative to be part of the
development team. This individual provides constant feedback and clarifies
requirements, ensuring the software aligns closely with user needs.
10. Simplicity
XP advocates for developing the simplest solution that works for the current
requirements. By avoiding unnecessary complexity, teams can focus on delivering value
quickly and efficiently.
Core Values of Extreme Programming
Extreme Programming is guided by five core values:
1. Communication: Team members and stakeholders engage in continuous, open
communication to ensure shared understanding and alignment.
2. Simplicity: The simplest solution that works is prioritized, reducing waste and focusing on
immediate needs.
3. Feedback: Frequent feedback from users, stakeholders, and automated tests guides the
development process and ensures alignment with requirements.
 4. Courage: Developers are encouraged to make necessary changes, even if it means
refactoring or adjusting earlier decisions, to maintain quality and adaptability.
5. Respect: All team members value each other’s contributions, fostering a collaborative
and supportive environment.

Advantages of Extreme Programming

 XP allows teams to respond effectively to changing requirements.
 The methodology fosters strong customer involvement, ensuring the software meets actual
user needs.
 Practices like TDD and pair programming significantly reduce defects and improve software
quality.
 XP encourages teamwork and knowledge sharing, creating a more cohesive and adaptable
team.
Disadvantages of XP
 XP requires a high level of commitment and discipline from all team members to adhere to
its practices effectively.
 The approach depends heavily on the availability of the customer for constant feedback and
clarification.
 Pair programming and frequent testing may initially seem time-consuming, though they lead
to long-term quality improvements.
 XP may not be well-suited for projects with rigid or well-defined requirements where
flexibility is less critical.

Difference between Scrum and Extreme programming project models:

Aspect Scrum Extreme Programming (XP)
Focus Focuses on managing work through Focuses on improving code quality
sprints and team roles. and customer collaboration.
Iteration Duration Sprints are 2-4 weeks long. Iterations are 1-2 weeks long.
Roles Roles include Product Owner, Scrum Roles are informal with all
Master, and Development Team. members working closely.
Customer Customer is involved indirectly Customer works directly with the
Involvement through the Product Owner. team throughout the process.
Planning Planning happens through backlog Planning happens at the start of
refinement and sprint meetings. each iteration.
Core Practices Includes stand-ups, backlog Includes TDD, pair programming,
management, and sprint reviews. and frequent code refactoring.
 Flexibility Changes to requirements are only Allows changes to requirements
allowed between sprints. even within iterations.
Communication Team communicates through stand- Team and customer collaborate
ups and sprint reviews. continuously for feedback.
Documentation Minimal documentation tracked via Minimal documentation, focusing
backlogs and artifacts. on the code itself.
Testing Testing is usually done after Testing is done continuously
development is complete. through TDD.
Delivery Deliverables are provided at the end Deliverables are provided more
Frequency of each sprint. frequently during iterations.
Suitability Best for projects with a stable and Best for projects with dynamic and
defined scope. changing requirements.
Key Metrics Uses metrics like velocity and sprint Focuses on metrics like code
burndown charts. quality and test coverage.
Team Size Works best with small-to-medium Works best with small,
teams. collaborative teams.
Code Ownership Developers have individual Encourages collective ownership
ownership of their tasks. of the code.

Incremental delivery model

First, a simple working system implemen ng only a few basic features is built and then that is
delivered to the customer. Then therea er many successive itera ons/ versions are implemented
and delivered to the customer un l the desired system is released.

Phases of incremental model

Requirements of Software are first broken down into several modules that can be incrementally
constructed and delivered.
1. Requirement analysis: In Requirement Analysis At any time, the plan is made just for the next
increment and not for any kind of long-term plan. Therefore, it is easier to modify the version
as per the needs of the customer.
2. Design & Development: At any time, the plan is made just for the next increment and not for
any kind of long-term plan. Therefore, it is easier to modify the version as per the needs of
the customer. The Development Team first undertakes to develop core features of the
 system. Once the core features are fully developed, then these are refined to increase levels
of capabilities by adding new functions in Successive versions. Each incremental version is
usually developed using an iterative waterfall model of development.
3. Deployment and Testing: After Requirements gathering and specification, requirements are
then split into several different versions starting with version 1, in each successive increment,
the next version is constructed and then deployed at the customer site. in development and
testing the product is checked and tested for the actual process of the model.
4. Implementation: In implementation After the last version (version n), it is now deployed at
the client site.
When to use the Incremental Process Model
1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
2. When Requirements are known up-front.
3. When Projects have lengthy development schedules.
4. Projects with new Technology.
 Error Reduction (core modules are used by the customer from the beginning of the
phase and then these are tested thoroughly).
 Uses divide and conquer for a breakdown of tasks.
 Lowers initial delivery cost.
 Incremental Resource Deployment.
5. Requires good planning and design.
6. The total cost is not lower.
7. Well-defined module interfaces are required.
Advantages of the Incremental Process Model
1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support, because of its iterations.
5. Adjusting the criteria and scope is flexible and less costly.
6. Comparing this model to others, it is less expensive.
7. The identification of errors is simple.
Disadvantages of the Incremental Process Model
1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.
3. Issues may arise from the system design if all needs are not gathered upfront throughout
the program lifecycle.
4. Every iteration step is distinct and does not flow into the next.
 5. It takes a lot of time and effort to fix an issue in one unit if it needs to be corrected in all
the units.

Difference between Spiral and Iterative model:

Aspect Spiral Model Iterative Model
Focus Combines risk management with Builds the system incrementally with
iterative development cycles. repeated iterations.
Phases Has planning, risk analysis,
Repeats development cycles until the
engineering, and evaluation phases. final product is ready.
Risk Handling Focuses heavily on identifying and Addresses risks through iterative
reducing risks at every phase. testing and feedback.
Iteration Iterations can vary in length based onIterations are typically shorter and
Duration risk and project needs. time-boxed.
Customer Customers provide feedback after Customers give feedback at the end of
Involvement each spiral cycle. each iteration.
Flexibility Highly flexible, allowing changes after
Moderately flexible, with changes
each risk analysis phase. incorporated in future iterations.
Documentation Requires detailed documentation for Uses lightweight documentation for
progress and risk management. each iteration.
Testing Testing happens during and after each Testing occurs at the end of each
spiral cycle. iteration.
Focus on Risk Risk assessment is a key part of everyRisk is managed indirectly through
spiral cycle. regular testing.
Delivery Delivers prototypes after each spiral Delivers a working version at the end
Frequency cycle. of each iteration.
Suitability Suitable for large, high-risk, and Best for smaller projects with clear but
complex projects. evolving requirements.
Cost Higher costs due to extensive risk More cost-effective due to shorter
management efforts. cycles.
Scalability Scales well for large, critical projects.
Better suited for small to medium-
sized projects.
End Goal Produces a refined product after Provides incremental working versions
several spirals. throughout the project.
COCOMO Model
Chapter 3

Func on Point Analysis

Func onal Point Analysis (FPA) is a so ware measurement technique used to assess the size and
complexity of a so ware system based on its func onality. It involves categorizing the func ons of the
so ware, such as input screens, output reports, inquiries, files, and interfaces, and assigning weights to
each based on their complexity. By quan fying these func ons and their associated weights, FPA provides
an objec ve measure of the so ware’s size and complexity.
Purpose:
 Project Es ma on: Func on points are used to es mate the size and complexity of a so ware
project, which in turn helps in determining the effort, me, and cost required to complete the
project.
 Produc vity Measurement: By calcula ng the func on points, organiza ons can track the
produc vity of development teams.
 Benchmarking: Func on points allow comparison between projects, teams, or organiza ons by
providing a standardized way of measuring so ware func onality.

Measurement Parameters

1. External Inputs (EI): Inputs provided by the user to the system, such as forms or data entered into the
applica on.
2. External Outputs (EO): Outputs generated by the system and presented to the user, like reports or
error messages.
3. External Queries (EQ): Requests for informa on or data retrieval made by the user.
4. Internal Logical File (ILF): A user-iden fiable group of logically related data or control informa on
maintained within the boundary of the applica on.
5. External Interface File (EIF): A group of users recognizable logically related data allusion to the
so ware but maintained within the boundary of another so ware.

Benefits of Func on Points:

 Language-independent, meaning they can be applied across different programming languages.

 Objec ve measurement of func onality.
 Helps in effec ve project planning and es ma on.
Steps in Function Point Analysis
1. Identify System Functions: Determine the number of inputs, outputs, inquiries, logical
files, and interface files.
2. Classify Functions: Assign complexity (Low, Average, or High) to each function based on
criteria like data size, processing logic, or user interaction.
3. Assign Function Points: Use predefined weights for each function type and complexity
level (as per IFPUG standards).
4. Calculate Unadjusted Function Points (UFP): Multiply the number of functions by their
respective weights and sum the results.
5. Apply the Value Adjustment Factor (VAF): Adjust the UFP by considering general
system characteristics (e.g., performance, usability).
6. Calculate Total Function Points: Multiply UFP by the VAF to get the final function point
count.
Example of Function Point Analysis
Let’s calculate the function points for a Library Management System.
Step 1: Identify Functions
 External Inputs (EI):
o Add new books (Low complexity): 10
o Add members (Low complexity): 10
 External Outputs (EO):
o Generate reports (Average complexity): 5
 External Inquiries (EQ):
o Search for books (Average complexity): 5
 Internal Logical Files (ILF):
o Books database (Average complexity): 7
o Members database (Average complexity): 7
 External Interface Files (EIF):
o External catalog database (High complexity): 10
Step 2: Assign Weights
Weights for function types based on complexity (example weights):
 EI: Low = 3
 EO: Average = 5
 EQ: Average = 4
 ILF: Average = 7
 EIF: High = 10
Step 3: Compute Unadjusted Function Points (UFP)
 Function Type Count Complexity Weight UFP
EI 2 Low 3 2×3=6
EO 1 Average 5 1×5=5
EQ 1 Average 4 1×4=4
ILF 2 Average 7 2 × 7 = 14
EIF 1 High 10 1 × 10 = 10
Total UFP 39
Step 4: Apply Value Adjustment Factor (VAF)
Assume a VAF of 1.15 (adjusted for system-specific factors like usability and performance).
Step 5: Calculate Total Function Points
Total FP = UFP × VAF = 39 × 1.15 = 44.85 (rounded to 45).

Advantages of FPA
1. Provides a reliable and objective measurement of software functionality.
2. Allows comparison of productivity across projects or organizations.
3. Enables early effort and cost estimation, aiding better project planning.
4. Encourages a focus on user requirements rather than technical implementation.
5. Language-independent, meaning they can be applied across different programming languages.
6. Objec ve measurement of func onality.
7. Helps in effec ve project planning and es ma on.

Gan Chart
A Gan chart is a visual project management tool that displays tasks or ac vi es along a meline. It shows
the start and end dates of tasks, task dependencies, and overall project progress. Each task is represented
as a bar on the chart, with its length corresponding to the task's dura on.

Features:

 Task Scheduling: Visualizes start and end dates of tasks.

 Dependencies: Shows rela onships between tasks, ensuring proper task sequence.

 Progress Tracking: Allows monitoring of task comple on and project milestones.

Benefits:

 Clarity: Provides a clear visual overview of the project meline.

 Time Management: Helps in managing deadlines and preven ng delays.

 Coordina on: Enhances team coordina on by highligh ng task dependencies and roles.
PERT
Example:
A project consists of three activities with their time estimates (in weeks) as follows:

Activity Optimistic (tₒ) Most Likely (tₘ) Pessimistic (tₚ)

1→2 1 4 7

2→3 2 5 8

3→4 3 6 15
Critical Path Model
Project Status Report
A Project Status Report is a formal document used in project management to provide a summary
of the current progress, status, and overall health of a project. It is shared with stakeholders,
team members, and management to ensure transparency, maintain alignment, and support
decision-making throughout the project lifecycle. The report helps track whether the project is
proceeding as planned, highlights any challenges or risks, and outlines the next steps.
Key Components of a Project Status Report:
1. Project Overview: This section provides a brief description of the project, its objectives,
and its scope. It ensures that all stakeholders are reminded of the project's purpose and
goals.
2. Current Status: The report includes an assessment of the project's overall status, such as
whether it is on track, delayed, or at risk. It may also include a completion percentage to
give a clear picture of progress made so far.
3. Milestones and Deliverables: This section outlines the milestones achieved since the last
status update. It highlights key deliverables and how they align with the planned timeline.
4. Challenges and Risks: Any issues encountered during the project are detailed here,
including potential risks and challenges that might impact timelines, budget, or
deliverables. The report may also include mitigation strategies being implemented to
address these risks.
5. Budget and Resource Updates: The report provides an update on the project's financial
status, including whether it is within the allocated budget. It also covers resource
utilization, availability, and any potential variances from the original plan.
6. Next Steps: This section outlines the upcoming tasks, deadlines, and priorities for the
project team. It ensures clarity regarding what needs to be done to keep the project
moving forward.
Importance of a Project Status Report:
1. Improved Communication: The report ensures that all stakeholders are updated on the
project's progress and aligned with the ongoing work.
2. Supports Decision-Making: By highlighting risks, challenges, and progress, the report
provides the necessary information to help stakeholders and management make
informed decisions to keep the project on track.
3. Accountability: It ensures that team members are aware of their responsibilities,
deadlines, and tasks, fostering a sense of accountability.
 4. Enhances Transparency: Regular updates build trust among stakeholders and ensure
there are no surprises regarding the project's progress or challenges.
Example:
In a weekly project status report for a website development project, the team might
communicate:
 "The project is 75% complete, with the design phase fully completed and the development
phase nearing completion. Testing is scheduled to begin next week. However, a delay in
receiving content from the client is a potential risk, which we are addressing by setting a
revised deadline for submission. The project remains within the allocated budget."
In summary, the Project Status Report is a critical tool for tracking progress, ensuring alignment,
and fostering effective communication among all stakeholders involved in the project.

Project Metrics
Project metrics are quantitative measures used to assess, track, and monitor the performance,
progress, and overall health of a project. These metrics provide data-driven insights into various
aspects of a project, such as timelines, budgets, resource utilization, quality, and risks.
Significance of Project Metrics in Project Management
1. Performance Monitoring: Metrics help evaluate whether the project is meeting its goals
and staying on track in terms of time, cost, and quality. For example, tracking schedule
variance ensures that tasks are completed on time.
2. Informed Decision-Making: By providing accurate and real-time data, metrics enable
project managers and stakeholders to make well-informed decisions, such as reallocating
resources or adjusting timelines.
3. Risk Management: Metrics help identify potential risks early by highlighting deviations or
anomalies in project performance, allowing for timely corrective actions.
4. Accountability: Metrics create transparency, ensuring team members and stakeholders
are accountable for their responsibilities by measuring individual and team contributions.
5. Continuous Improvement: Metrics provide insights into project outcomes, which can be
used to refine processes and improve efficiency in future projects.
Examples of Project Metrics
 Schedule Variance (SV): Measures the difference between planned and actual progress.
 Cost Performance Index (CPI): Indicates whether the project is within budget.
 Defect Density: Evaluates the quality of deliverables by measuring defects per unit.
Earned Value Analysis (EVA)
Earned Value Analysis (EVA) is a project management technique used to measure project
performance and progress objectively. It integrates project scope, cost, and schedule data to
assess whether a project is on track in terms of budget and timeline. EVA provides a
comprehensive view of the project’s current status and forecasts its likely future performance.
Methods of Earned Value Analysis
EVA uses several key metrics and methods to analyze project performance:
1. Planned Value (PV):
o The estimated cost of the work planned to be completed by a specific point in time.
o Also known as the Budgeted Cost of Work Scheduled (BCWS).
2. Earned Value (EV):
o The estimated value of the work actually completed by a specific point in time.
o Also called Budgeted Cost of Work Performed (BCWP).
3. Actual Cost (AC):
o The actual cost incurred for the work completed by a specific time.
o Also known as Actual Cost of Work Performed (ACWP).
4. Variance Analysis:
o Cost Variance (CV): CV=EV−AC Indicates whether the project is under or over budget.
Negative value of CV indicates that the project is over the Budget.
o Schedule Variance (SV): SV=EV−PV Indicates whether the project is ahead of or
behind schedule. Negative value of SV indicates that the project is behind the
schedule.
Features of Earned Value Analysis
1. Integrated Performance Measurement: EVA combines scope, cost, and schedule metrics
into a single system for better project evaluation.
2. Real-Time Monitoring: Provides continuous monitoring of project performance and
identifies deviations early.
3. Forecasting Capabilities: Helps predict future performance trends, such as total project
costs and time required for completion.
 4. Quantitative Insights: Offers data-driven insights into project efficiency and
effectiveness.
5. Variance Analysis: Helps identify the root causes of cost and schedule variances, enabling
corrective actions.
Importance of Earned Value Analysis in Project Management
EVA is crucial for effective project management because:
1. Objective Measurement of Progress: It quantifies progress in monetary terms, making it
easier to assess performance against the baseline.
2. Early Warning System: By highlighting variances, EVA helps identify risks and problems
early, allowing for timely corrective measures.
3. Improved Decision-Making: EVA provides actionable insights to adjust schedules,
budgets, or resource allocation based on current trends.
4. Transparency and Accountability: Ensures clear reporting to stakeholders by presenting
concise and accurate performance data.
5. Forecasting and Planning: EVA enables project managers to forecast the likely cost at
completion (Estimate at Completion or EAC) and remaining work (Estimate to Complete
or ETC).
Chapter 4
Risk Management Approaches
Risk Avoidance

 Descrip on: This approach involves completely elimina ng the poten al for a risk to occur by
avoiding ac vi es or decisions that could expose the organiza on to that risk. Instead of dealing
with a risk, the company chooses to sidestep it altogether.

 How It Works: When a company iden fies a risk that it deems too dangerous or costly to handle,
it may avoid the situa on en rely. For example, if expanding into a vola le market carries the risk
of major financial losses, the company might decide not to enter that market at all.

 Example: A company may choose not to invest in a country with unstable poli cal condi ons to
avoid the risk of na onaliza on or poli cal unrest.

 Pros: No chance of facing the risk since the exposure is eliminated.

 Cons: Avoiding risks can also mean missing out on poten al opportuni es for growth or profit.

2. Risk Mi ga on

 Descrip on: Mi ga on involves taking steps to reduce the likelihood or impact of a risk. Instead
of avoiding the risk completely, this approach minimizes its effect should it occur.

 How It Works: Risk mi ga on typically includes implemen ng controls, safeguards, or

con ngency plans to lessen the damage. For example, if a business faces the risk of cybera acks,
it can mi gate that risk by inves ng in cybersecurity measures.

 Example: Installing fire suppression systems in a building reduces the risk of fire damage, or
implemen ng backup systems to mi gate data loss in case of system failure.

 Pros: Reduces the overall impact or probability of risks, o en providing a balance between safety
and opportunity.

 Cons: It doesn’t eliminate the risk completely, and can be costly in terms of resources or me.

3. Risk Acceptance

 Descrip on: In this approach, the risk is acknowledged, and the organiza on decides to take no
ac on, accep ng the poten al impact. The risk may be considered minor, or the cost of mi ga ng
it may outweigh the benefits.

 How It Works: With risk acceptance, the organiza on calculates that the poten al consequences
of a risk are manageable or too insignificant to warrant any costly ac on. For example, a company
may accept the risk of a minor system outage, as the impact on its opera ons is low.

 Example: A startup may accept the risk of ini al financial losses when entering a compe ve
market, believing that long-term growth will outweigh short-term issues.
  Pros: It’s cost-effec ve since no ac on is taken to mi gate the risk, allowing resources to be used
elsewhere.

 Cons: If the risk occurs, the organiza on must bear the full consequences, which could some mes
be greater than an cipated.

4. Risk Transference

 Descrip on: Risk transference involves shi ing the risk to another party, typically through
mechanisms like insurance, outsourcing, or partnerships. The risk remains, but another en ty
takes on the responsibility.

 How It Works: This approach is common in situa ons where a company wants to protect itself
from major losses but doesn't want to bear the burden of mi ga on. For example, companies
o en transfer the risk of poten al damages from accidents to an insurance provider, so if an
incident occurs, the insurer pays for the damages.

 Example: Purchasing business insurance to transfer the financial risk of property damage, or hiring
a third-party vendor to handle logis cs, transferring the risk of opera onal delays to them.

 Pros: Reduces the organiza on’s liability for significant risks, and can provide financial protec on
in case of disaster.

 Cons: Risk transfer usually comes at a cost, such as insurance premiums or fees for outsourced
services. It also doesn’t eliminate the risk, but just shi s the responsibility.
Chapter 5
Chapter 6
Chapter 7
Chapter 8