SPM

1. BE Sem – 7 SPM – 3171609 Unit – 2(1)
Unit – 2
Project Planning

2. Outline
• Project Planning
• Tasks in Project Planning
• Work Breakdown Structures (WBS)
• Planning Methods
• Selecting Project Approach
• Software Development Life Cycle (SDLC)
• Software Processes & Process Models
• Choice of Process Models
• A Generic Project Model
• Software Cost Estimation
• COCOMO Model
• Budgeting

3. Project Planning
• Project Planning is an aspect of Project Management that
focuses a lot on Project Integration.
• A Software Project is the complete methodology of
programming advancement from requirement gathering to
testing and support, completed by the execution procedures,
in a specified period to achieve intended software product.
• The project plan reflects the current status of all project
activities and is used to monitor and control the project.
• The Project Planning tasks ensure that various elements of the
Project are coordinated and therefore guide the project
execution.
• Project Planning helps in
– Facilitating communication
– Monitoring/measuring the project progress, and
– Provides overall documentation of assumptions/planning
decisions

4. Project Planning cont.
• The objective of software project planning is to provide a
framework that enables the manager to make reasonable
estimates of resources, cost, & schedule.
• In addition, estimates should attempt to define best-case &
worst-case scenarios so that project outcomes can be
bounded.
• Although there is an integral degree of uncertainty, the
software team get on a plan that has been established as a
consequence of these tasks.
• Therefore, the plan must be adapted & updated as the project
proceeds.
• Project Planning is an ongoing effort throughout the Project
Lifecycle.

5. Project Planning cont.
• The Project Planning Phases can be broadly classified as
follows:
– Development of the Project Plan
– Execution of the Project Plan
– Change Control and Corrective Actions
• Why is it important?
“If you fail to plan, you plan to fail.”
- Project planning is crucial to the success of the Project.
- Careful planning right from the beginning of the project
can help to avoid costly mistakes. It provides an assurance that
the project execution will accomplish its goals on schedule and
within budget.

6. Project Planning cont.
• Project planning is at the heart of the project life cycle, &
tells everyone involved where you’re going and how you’re
going to get there.
• The planning phase is when the project plans are
documented, the project deliverables & requirements are
defined, & the project schedule is created.
• It involves creating a set of plans to help guide your team
through the implementation & closure phases of the project.
• The plans created during this phase will help you manage
time, cost, quality, changes, risk, & related issues.
• They will also help you control staff & external suppliers to
ensure that you deliver the project on time, within budget, &
within schedule.

7. Project Planning cont.
The purpose of the project planning phase is to:
• Establish business requirements
• Establish cost, schedule, list of deliverables, and delivery
dates
• Establish resources plans
• Obtain management approval and proceed to the next
phase

8. Processes of project planning
• Scope planning – specifying the in-scope requirements for the project
to facilitate creating the work breakdown structure
• Preparation of the work breakdown structure – spelling out the
breakdown of the project into tasks and sub-tasks
• Project schedule development – listing the entire schedule of the
activities and detailing their sequence of implementation
• Resource planning – indicating who will do what work, at which time,
and if any special skills are needed to accomplish the project tasks
• Budget planning – specifying the budgeted cost to be incurred at the
completion of the project
• Procurement planning – focusing on vendors outside your company
and subcontracting
• Risk management – planning for possible risks and considering optional
contingency plans and mitigation strategies
• Quality planning – assessing quality criteria to be used for the project
• Communication planning – designing the communication strategy
with all project stakeholders

9. Task set for Project Planning
• Establish project scope
• Determine feasibility
• Analyze risks
• Define required resources
• Determine required human resources
• Define reusable software resources
• Identify environmental resources
• Estimate cost & effort
• Decompose the problem
• Develop two or more estimates using size, function points, process
tasks, or use cases
• Reconcile the estimates
• Develop a project schedule
• Establish a meaningful task set
• Define task network
• Use scheduling tools to develop a time-line chart
• Define schedule tracking mechanisms

11. BE Sem – 7 SPM – 3171609 Unit – 2(2)
Unit – 2
Project Planning

12. Outline
• Project Planning
• Tasks in Project Planning
• Work Breakdown Structures (WBS)
• Planning Methods
• Selecting Project Approach
• Software Development Life Cycle (SDLC)
• Software Processes & Process Models
• Choice of Process Models
• A Generic Project Model
• Software Cost Estimation
• COCOMO Model
• Budgeting

13. Work Breakdown Structures (WBS)
• Breaking work into smaller tasks is a common productivity
technique used to make the work more manageable and
approachable.
• For projects, the Work breakdown structure (WBS) is a
method for completing a complex, multi-step project. It's a
way to divide and conquer large projects to get things done
faster and more efficiently.
• “A Work Breakdown Structure (WBS) is a hierarchical
structure of things that the project will make or outcomes
that it will deliver”
• “A work breakdown structure defines all the things a project
needs to accomplish, organized into multiple levels, and
displayed graphically.”

14. Work Breakdown Structures (WBS) cont.
• The Project Management Institute (PMI) defines the Work
Breakdown Structure as a “deliverable oriented hierarchical
decomposition of the work to be executed by the project
team.”
• There are two types of WBS:
1) Deliverable-Based and
2) Phase-Based.
• The most common and preferred approach is the Deliverable-
Based approach. The main difference between the two
approaches are the Elements identified in the first Level of
the WBS.
• Goal - to make a large project more manageable. Breaking it
down into smaller chunks means work can be done
simultaneously by different team members, leading to better
team productivity and easier project management.

15. Deliverable-Based WBS
• A Deliverable-Based Work Breakdown Structure clearly
demonstrates the relationship between the project
deliverables (i.e., products, services or results) & the scope
(i.e., work to be executed).

16. Phase-Based WBS
• A Phase-Based WBS, the Level 1 has five Elements. Each of
these Elements are typical phases of a project. The Level 2
Elements are the unique deliverables in each phase.
Regardless of the type of WBS, the lower Level Elements are
all deliverables.

17. Work Breakdown Structures (WBS) cont.
• Work breakdown structure for each project can be different.
• As a project manager, you may have to experiment to see
which WBS works best for you and your team.
• The goal is to show the hierarchy of your projects & make
progress clear to everyone involved — whether they are a
team member or an external stakeholder.
• Here are some work breakdown structure examples - use any
of these to outline your WBS.
• WBS spreadsheet
• WBS flowchart
• WBS list
• WBS Gantt chart

18. Work Breakdown Structure example
• When created thoroughly, the work breakdown structure is a
roadmap that guides a team when completing projects —
whether simple or complex.

20. Selecting Project Approach
• The development of software in-house usually means that –
o the developers and the users belong to the same organization;
o the application will slot into a portfolio of existing computer-based
systems;
o the methodologies and technologies are largely dictated by
organizational standards and policies, including the existing enterprise
architecture.
• A software supplier could carry out successive development
projects for a variety of external customers.
• Need to review the methodologies and technologies to be
used for each individual project. This decision-making process
has been called technical planning by some, although here we
use the term project analysis.

21. BE Sem – 7 SPM – 3171609 Unit – 2(3)
Unit – 2
Project Planning

22. Ms. Zarana Gajjar (IT-ICT Department)
Outline
• Project Planning
• Tasks in Project Planning
• Work Breakdown Structures (WBS)
• Planning Methods
• Selecting Project Approach
• Software Development Life Cycle (SDLC)
• Software Processes & Process Models
• Choice of Process Models
• A Generic Project Model
• Software Cost Estimation
• COCOMO Model
• Budgeting

23. Selecting Project Approach cont.
• Even where development is in-house, any characteristics of
the new project requiring a different approach from previous
projects need to be considered.
• A wide range of system development methods exists, but
many organizations get along without using any of the
recognized approaches.

24. Analyse project characteristics
The selection
of a particular process
model could add new
products to the
Project Breakdown
Structure or new
activities to the
activity network. This
will generate inputs
for Step 4: Identify
the products and
activities of the
project

25. Software Processes & Process Models
• A software product development process usually starts when a
request for the product is received from the customer.
• For a generic product, the marketing department of the company is
usually considered as the customer. This expression of need for the
product is called product inception.
• From the inception stage, a product undergoes a series of
transformations through a few identifiable stages until it is fully
developed & released to the customer.
• After release, the product is used by the customer & during this
time the product needs to be maintained for fixing bugs &
enhancing functionalities. This stage is called the maintenance
stage.
• When the product is no longer useful to the customer, it is retired.
This set of identifiable stages through which a product transits from
inception to retirement form the life cycle of the product.
• The software life cycle is also commonly referred to as Software
Development Life Cycle (SDLC) & software process.

26. Modeling Creating models to
understand
requirements and shows
design of software to
achieve requirements
Construction Code Generation
(manual or automated)
& Testing
(to uncover errors in the
code)
Deployment
Deliver Software to Customer
Collect feedback from customer based on evaluation
Software Support
Planning
Communication Communication with
Customers /
stockholders to
understand project
requirements for
defining software
features
Software Project Plan
which defines workflow
that is to follow.
It describes technical task,
risks, resources, product to
be produced & work
schedule
Software Development life Cycle
Communication Planning Modeling Construction Deployment

27. Software Process Models :-
• Also known as Software development life
cycle (SDLC)
• Prescribe a distinct set of activities, actions,
tasks and milestones (deliverables) required
to engineer high quality software.
• Process models are not perfect, but provide
roadmap for software engineering work.
• Provide stability, control and organization to
a process that if not managed can easily get
out of control.
• Adapted to meet the needs of software
engineers and managers for a specific
project.
SDLC Phases

28. Choice of Process Models
• The word 'process' emphasizes the idea of a system in action.
• To achieve an outcome, the system will have to execute one
or more activities: this is its process.
• This applies to the development of computer based
applications.
• A number of interrelated activities have to be undertaken to
create a final product.
• These activities can be organized in different ways and we
can call these process models.
• The planner selects methods and specifies how they are to be
applied.

29. Different Process Models
• Selection of Process model is
based on different parameters
o Type of the project & people
o Complexity of the project
o Team size
o Expert people in team
o Working environment of team
o Software delivery deadline
Process Models
• Waterfall Model(Linear Sequential
Model)
o Classical Waterfall Model
o Iterative Waterfall Model
• Incremental Process Model
• Evolutionary Model
o Prototyping Model
o The Spiral Model
• Rapid Application Development
Model(RAD Model)
• Component Based Development
Model
• Agile Process Model

30. Classical Waterfall Model
When requirements for a problems are well understood
then this model is used in which work flow from
communication to deployment is linear

31. Advantages Disadvantages
• This model is very simple and
is easy to understand.
• Phases in this model are
processed one at a time.
• Each stage in the model is
clearly defined.
• This model has very clear and
well understood milestones.
• Process, actions and results
are very well documented.
• This model works well for
smaller projects and projects
where requirements are well
understood.
• Classical waterfall model
suffers from various
shortcomings, basically
we can’t use it in real
projects.
• No feedback path
• Difficult to accommodate
change requests
• No overlapping of phases

32. Iterative Waterfall Model

33. Advantages Disadvantages
• Feedback Path
• Simple to understand and easy
to implement.
• Most widely used software
development model
• Difficult to incorporate
change requests
• Incremental delivery not
supported
• Risk handling not supported
• Limited customer
interactions

34. Evolutionary Process Models
• When a set of core product or system requirements is well understood
but the details of product or system extensions have yet to be
defined.
• In this situation there is a need of process model which specially
designed to accommodate product that evolve with time.
• Evolutionary Process Models are specially meant for that which
produce an increasingly more complete version of the software with
each iteration.
• Evolutionary Models are iterative.
• They are characterized in a manner that enables you to develop
increasingly more complete versions of the software.
• Evolutionary models are
o Prototyping Model
o Spiral Model

35. Prototyping model
• Customers have general objectives of software but do not have detailed
requirements for functions & features.
• Developers are not sure about efficiency of an algorithm & technical
feasibilities.
• It serves as a mechanism for identifying software requirements.
• Prototype can be serve as “the first system”.
• Both stakeholders and software engineers like prototyping model
 Users get feel for the actual system
 Developers get to build something immediately
When to use ?

36. Prototyping model cont.
• Communicate with stockholders
& define objective of Software
• Identify requirements & design
quick plan
• Model a quick design (focuses on
visible part of software)
• Construct Prototype & deploy
• Stakeholders evaluate this
prototype and provides
feedback
• Iteration occurs and prototype is
tuned based on feedback
Prototype Model

37. Prototyping model cont.
• Customer demand that “a few fixes” be applied to make the prototype a
working product, due to that software quality suffers as a result
• Developer often makes implementation in order to get a prototype working
quickly; without considering other factors in mind like OS, Programming
language, etc.
• Incomplete application may cause application not to be used as the full
system was designed.
Problem Areas
Advantages
• Users are actively involved in the development
• Since in this methodology a working model of the system is provided, the
users get a better understanding of the system being developed
• Errors can be detected much earlier

38. The Spiral Model
• It provides the potential for rapid
development.
• Software is developed in a series of
evolutionary releases.
• Early iteration release might be
prototype but later iterations
provides more complete version of
software.
• It is divided into framework
activities. Each activity represent
one segment of the spiral
• Each pass through the planning
region results in adjustments to
 the project plan
 Cost & schedule based on feedback Spiral Model

39. The Spiral Model Cont.
• For development of large scale / high-risk projects.
• When costs and risk evaluation is important.
• Users are unsure of their needs.
• Requirements are complex.
• New product line.
• Significant (considerable) changes are expected.
When to use Spiral Model?

40. The Spiral Model Cont.
Advantages
• High amount of risk analysis
hence, avoidance of Risk is
enhanced.
• Strong approval and
documentation control.
• Additional functionality can be
added at a later date.
• Software is produced early in
the Software Life Cycle.
Disadvantages
• Can be a costly model to use.
• Risk analysis requires highly specific
expertise.
• Project’s success is highly dependent
on the risk analysis phase.
• Doesn’t work well for smaller
projects.

41. Incremental Process Model
• Many situations in which initial software requirements are reasonably
well defined, but the overall scope of the development effort
prevent a purely linear process.
• There may be a fascinating need to provide a limited set of software
functionality to users quickly and then refine and expand on that
functionality in later software releases.
• In such cases, there is a need of a process model that is designed to
produce the software in increments.
• It is a process of software development where requirements divided
into multiple standalone modules of the software development cycle.

42. Incremental Process Model cont.
• Each module goes through the Communication, Planning, Modeling,
Construction & Deployment phases.
• Every subsequent release of the module adds function to the previous
release.
• Process continues until the complete system achieved.
• A simple working system implementing only a few basic features is
built and then that is delivered to the customer.
• Thereafter many successive iterations/ versions are implemented and
delivered to the customer until the desired system is released.

43. Incremental Process Model cont.
• The incremental model combines elements of linear and parallel
process flows.
• Initially core working product is delivered.
• Each linear sequence produces deliverable “increments” of the
software.

44. • When the requirements are superior.
• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• Funding Schedule, Risk, Program Complexity, or need for early
realization of benefits.
• Projects with new Technology.
When to use ?
Incremental Process Model cont.

45. Incremental Process Model cont.
Advantages
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Lowers initial delivery cost.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
Disadvantages
• Requires good planning and design.
• Total cost is high.
• Well defined module interfaces are required.

46. Rapid Application Development Model
(RAD Model)
• First proposed by IBM in 1980’s.
• It is a type of incremental model.
• Components or Functions are developed in parallel as if they were
mini projects.
• A software project can be implemented using this model if the
project can be broken down into small modules wherein each module
can be assigned independently to separate teams.
• Modules can finally be combined to form the final product.
• Another striking feature of this model is a short time span i.e the
time frame for delivery(time-box) is generally 60-90 days.

47. RAD Model cont.

48. • When the system should need to create the project that modularizes
in a short span time (2-3 months).
• When the requirements are well-known.
• When the technical risk is limited.
• It should be used only if the budget allows the use of automatic code
generating tools.
When to use ?
RAD Model cont.

49. Advantages
• This model is flexible for change.
• Changes are adoptable.
• Each phase in RAD brings highest
priority functionality to the customer.
• Reduced development time.
• Increases the reusability of features.
• Feedback from the customer is
available at initial stages.
• Use of powerful development tools
results in better quality products in
comparatively shorter time spans.
• The progress and development of the
project can be measured through the
various stages.
Disadvantages
• It required highly skilled
designers.
• All application is not compatible
with RAD.
• For smaller projects, we cannot
use the RAD model.
• On the high technical risk, it's
not suitable.
• Required user involvement.
• The absence of reusable
components can lead to failure
of the project.
RAD Model cont.

50. Component Based Process Model
• Commercial off-the-shelf (COTS) software components, developed by
vendors who offer them as products, can be used when software is to be
built.
• Provides targeted functionality with well defined interfaces that enables
component to be integrated into software.
• Incorporates many characteristics of the spiral model.
• It is evolutionary in nature, demanding an iterative approach to the
software development.
• Modeling and construction activities begin with the identification of
components.
• Components can be designed as either conventional software modules or
object-oriented classes or packages of classes.

51. Component Based Process Model cont.
Component based development incorporates the following
steps :
1. Available component-based products are researched &
evaluated for software development.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the
components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper
functionality.

52. Agile Process Models
• Extreme Programming (XP)
• Dynamic Systems Development Method (DSDM)
• Scrum Process Model
• Feature Driven Development (FDD)

53. Extreme Programming (XP)
• Originally described by Kent Beck, has emerged as one of
the most popular and controversial Agile models.
• Lightweight, efficient, low-risk, flexible, predictable, scientific,
and fun way to develop a software.
• eXtreme Programming (XP) conceived and developed to
address the specific needs of software development by small
teams in the face of ambiguous and changing requirements.
• Disciplined approach for high-quality agile software
development, focused on speed and continuous delivery.

54. The XP Process
It considers 4 framework activities
• Planning
• Design
• Coding
• Testing

55. Design
User Stories
• Customers assigns value (priority)
• Developers assigns cost (number of development weeks)
Project velocity
• Computed at the end of first release
• Number of stories implemented in first release
• Estimates for future release
• Guard against over-commitment
Planning
• Keep-it-Simple (Design of extra functionality is
discouraged)
• Preparation of CRC card is work project
• CRC cards identify and organize object oriented classes
• Spike Solutions (in case of difficult design problem is encountered)
• Operational prototype intended to clear confusion
• Refactoring
• Modify internals of code, No observable change
CRC card

56. • Develops a series of Unit test for stories included in current release
• Complete code perform unit-test to get immediate feedback
• XP recommend pair-programming, “Two heads are better than
one”
• Integrate code with other team members, this “continuous
integration” helps to avoid compatibility & interfacing problems,
“smoke testing” environment to uncover errors early
Testing
Coding
• Unit test by developers & fix small problems
• Acceptance tests - Specified by customer
• This encourages regression testing strategy whenever code is modified

57. • Communication: To achieve effective communication, it
emphasized close & informal (verbal) collaboration
between customers and developers
• Simplicity: It restricts developers to design for immediate
needs not for future needs
• Feedback: It is derived from three sources the
implemented software, the customer and other software
team members, it uses Unit testing as primary testing
• Courage: It demands courage (discipline), there is often
significant pressure to design for future requirements, XP
team must have the discipline (courage) to design for today
• Respect: XP team respect among members
XP Values

58. XP Practices
• The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Refactoring
• Pair Programming
• Collective Code Ownership
• Continuous Integration
• Coding Standard
• Customer Acceptance Tests
• Test-Driven Development
• Sustainable Pace

59. Dynamic System Development Method (DSDM)
• Dynamic System Development Method / Atern is approach to
system development, which, as the name suggests, develops
the system dynamically.
• It an associate degree agile code development approach that
provides a framework for building and maintaining systems.
• An iterative & incremental approach that emphasizes
continuous user/customer involvement.
• Goal – to deliver projects on time & on budget while adjusting
for changing requirements along the way.

60. Dynamic System Development Method (DSDM)
• DSDM is a methodology that prioritizes schedule and quality
over functionality.
• It’s Straight forward framework.
• Simple & Extendible.

61. Model of Dynamic System Development Method
DSDM has five-phase life cycle
• Feasibility study
• Business study
• Functional model iteration
• Design & Build iteration
• Implementation

62. • Users are highly involved in the development.
• Basic functionality is delivered within very short time.
• Provides easy access for Developers to end-users.
• Projects are delivered On time within a specific budget.
Advantages
Disadvantages
• Sometimes it’s Costly.
• May not suitable for Small Organizations.
• Not suitable for one time projects.
• Users and Developers both need to be trained.

63. Scrum Process Model
• Scrum is an agile process model which is used for
developing the complex software systems.
• It is a software product development strategy that organizes
software developers as a team to reach a common goal —
creating a ready-for-market product.
• It uses Iterative process.
• Is light-weighted framework & simple to understand
• Scrum emphasizes self-organization
• Scrum framework help the team to work together

64. Scrum Process Model cont.
A scrum is a
method of
restarting play in
rugby that
involves players
packing closely
together with
their heads down
and attempting to
gain possession of
the ball.

65. Scrum Process Model cont.

66. Scrum Process Model cont.
Scrum is based on the following 3 Pillars-

67. There are three chief roles in Scrum Testing – Product Owner,
Scrum Master and The Development Team.
Roles in Scrum
Product Owner Scrum Master The Team
He/She defines features of
the product.
He/She manages the team
and look after the team's
productivity
The team is usually
about 5-9 members
Product Owner decides the
release date and
corresponding features
He/She maintains the block
list and removes barriers in
the development
It includes developers,
designer and sometimes
testers, etc.
They prioritize the features
according to the market
value and profitability of the
product
He/She coordinates with all
roles and functions
The team organizes and
schedule their work on
their own
He/She is responsible for the
profitability of the product
Invites to the daily scrum,
sprint review and planning
meetings
Actively participate in
daily ceremonies

68. A scrum process includes
• User stories: They are a short explanation of functionalities
of the system under test. Example for Insurance Provider is –
"Premium can be paid using the online system.“
• Product Backlog: It is a collection of user stories captured
for a scrum product. The product owner prepares and
maintains the product backlog. It is prioritized by the
product owner, and anyone can add to it with approval from
the product owner.
• Release Backlog: A release is a time frame in which the
number of iterations is completed. The product owner co-
ordinates with the scrum master to decide which stories
should be targeted for a release. Stories in the release
backlog are targeted to be completed in a release.
Scrum Artifacts

69. • Sprints: It is a set period of time to complete the user
stories, decided by the product owner and developer team,
usually 2-4 weeks of time.
• Sprint Backlog: It's a set of user stories to be completed in a
sprint. During sprint backlog, work is never assigned, and the
team signs up for work on their own. It is owned and managed
by the team while the estimated work remaining is updated
daily. It is the list of task that has to be performed in Sprint
• Block List: It is a list of blocks and unmade decisions owned
by scrum master and updated daily
• Burndown chart: Burn-down chart represents overall progress
of the work in progress and work completed throughout the
process. It represents in a graph format the stories and
features not completed
Scrum Artifacts

70. • Sprint Planning: A sprint begins with the team importing
stories from the release backlog into the sprint backlog; it is
hosted by scrum master. The Testers estimate effort to test
the various stories in the Sprint Backlog.
• Daily Scrum: It is hosted by scrum master, it last about 15
minutes. During Daily Scrum, the members will discuss the
work completed the previous day, the planned work for the
next day and issues faced during a sprint. During daily stand-
up meeting team progress is tracked.
• Sprint Review/ Retrospective: It is also hosted by scrum
master, it last about 2-4 hours and discuss what the team has
accomplished in the last sprint and what lessons were
learned.
Ceremonies (Processes) in Scrum

71. • Scrum framework is fast moving and money efficient.
• It works by dividing the large product into small sub-products.
• In Scrum customer satisfaction is very important.
• Scrum is adaptive in nature because it have short sprint.
• As Scrum framework rely on constant feedback therefore the
quality of product increases in less amount of time.
Advantages
Disadvantages
• Scrum framework do not allow changes into their sprint.
• Scrum framework is not fully described model. If you want to
adopt it you need to fill in the framework with your own
details like Extreme Programming(XP), DSDM.
• It can be difficult for the Scrum to plan, structure and
organize a project that lacks a clear definition.
• The daily Scrum meetings and frequent reviews require
substantial resources.

72. Feature Driven Development (FDD)
• It is an agile iterative and incremental model that focuses on
progressing the features of the developing software.
• It is a client-centric, architecture-centric, & pragmatic
software process.
• In FDD, reporting and progress tracking is necessary at all
levels.

73. Feature Driven Development (FDD) cont.

74. Feature Driven Development (FDD) cont.
• Develop overall model - The high-level walkthrough of scope
and detailed domain walkthrough are conducted to create
overall models.
• Build feature list - List of features is created and expressed
in the following form
<action> the <result> <by for of to> a(n) <object>
For Ex. “Display product-specifications of the product”
• Plan by feature - After completing the feature list the
development plan is created
• Design by feature - For each feature the sequence diagram
is created
• Build by feature - Finally the class owner develop the actual
code for their classes

75. • Reporting at all levels leads to easier progress tracking.
• FDD provides continuous success for larger size of teams and
projects.
• Reduction in risks is observed as whole model and design is
build in smaller segments.
• FDD provides greater accuracy in cost estimation of the
project due to feature segmentation.
Advantages
Disadvantages
• This agile practice is not good for smaller projects.
• There is high dependency on lead programmers, designers
and mentors.
• There is lack of documentation which can create an issue
afterwards.

76. Software Project Estimation
To achieve reliable cost and effort estimates, a
number of options arise:
• Delay estimation until late in the project (obviously, we
can achieve 100 percent accurate estimates after the
project is complete!)
• Base estimates on similar projects that have already
been completed
• Use relatively simple decomposition techniques to
generate project cost and effort estimates
• Use one or more empirical models for software cost and
effort estimation.

77. Empirical Estimation Models
• It is a technique or model in which empirically
derived formulas are used for predicting the data
that are a required & essential part of the software
project planning.
• Techniques are usually based on the data that is
collected previously from a project &U also based
on some guesses, prior experience with the
development of similar types of projects, &
assumptions.
• Uses the size of the software to estimate the
effort.

78. COCOMO
• Boehm proposed COCOMO (Constructive Cost
Model) in 1981.
• One of the most generally used software estimation
model.
• Predicts the efforts & schedule of a software
product based on the size of the software.
• In COCOMO, projects are categorized into 3 types :
• Organic
• Semidetached
• Embedded

79. Software Development Project Classification
• Organic :
o A development project can be treated of organic type, if the project
deals with developing a well understood application program, the size
of the development team is reasonably small, and the team members
are experienced in developing similar methods of projects.
o E.g. simple business systems, data processing systems
• Semidetached
o A development project can be treated with semidetached type, if the
development consists of a mixture of experienced & inexperienced
staff. Team members may have finite experience in related systems but
may be unfamiliar with some aspects of the system being developed.
o E.g. Developing a new OS, DBMS & complex inventory management
system
• Embedded
o A development project is treated to be of an embedded type, if the
software being developed is strongly coupled to complex hardware, or if
the strict regulations on the operational procedures exist
o E.g. ATM, Air Traffic control

80. Software Development Project cont.
Model Project
Size
Nature of Project Innovation Dead
Line
Development
Environment
Organic Typically
2-50
KLOC
Small Size Project,
Experienced developers in
the familiar environment,
E.g. Payroll, Inventory
projects etc.
Little Not
Tight
Familiar &
In-house
Semi
Detached
Typically
50-300
KLOC
Medium Size Project, Medium
Size Team, Average Previous
Experience, E.g. Utility
Systems like Compilers,
Database Systems, editors
etc.
Medium Medium Medium
Embedded Typically
Over 300
KLOC
Large Project, Real Time
Systems, Complex interfaces,
very little previous
Experience. E.g. ATMs, Air
Traffic Controls
Significant
Required
Tight Complex
hardware &
customer
Interfaces

81. COCOMO cont.
According to Boehm, software cost estimation should
be done through three stages :
• Basic Model - Small teams
• Intermediate Model – Intermediate deadlines with
innovations in between
• Detailed Model – Very large projects

82. Basic COCOMO Model
• Can be used for quick & slightly rough calculations of
software costs.
• Gives an approximate estimate of the project parameters
• The basic COCOMO estimation model is given by the
following expressions
• Effort = a1 + (KLOC) PM
• Tdev = b1 * (Effort) Months
• KLOC is the estimated size of the software product expressed
in Kilo Lines of source Code,
• a1, a2, b1, b2 are constants for different categories of
software products,
• Tdev is the estimated time to develop the software in
months,
• Effort is the total effort required to develop the software
product, expressed in person months (PMs).

83. Basic COCOMO Model cont.
Project a1 a2 b1 b2
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

84. Basic COCOMO Model cont.
• Insight into the basic COCOMO
model can be obtained by
plotting the estimated
characteristics for different
software sizes
• Figure shows a plot of estimated
effort versus product size
• From fig. we can observe that
the effort is somewhat
superlinear in the size of the
software product
• The effort required to develop a
product increases very rapidly
with project size

85. Basic COCOMO Model cont.
• The development time versus the
product size in KLOC is plotted in
figure
• From fig., it can be observed that
the development time is a
sublinear function of the size of
the product
• i.e. when the size of the product
increases by two times, the time
to develop the product does not
double but rises moderately
• From fig., it can be observed that
the development time is roughly
the same for all the three
categories of products

86. Example
Assume that the size of an organic type software product
has been estimated to be 32,000 lines of source code. Assume
that the average salary of software engineers be Rs. 15,000/-
per month. Determine the effort required to develop the
software product and the nominal development time
Effort = a1 + (KLOC) PM
= 2.4 + (32)1.05 PM
= 91 PM
Tdev = b1 * (Effort) Months
= 2.5 * (91)0.38 Months
= 14 Months
Cost required to develop the product = 14 *15000
= 2,10,000/- Rs.

87. Disadvantages
• It considers only KLOC to estimate effort
• It can’t be used for modern tools
• It doesn’t consider different parameters

88. Intermediate COCOMO Model
• The basic COCOMO model assumes that effort & development
time depends on product size alone.
• However, several parameters affect effort & development
time :
o Reliability requirements
o Availability of CASE tools & modern facilities to the
developers
o Size of data to be handled
• Therefore, in order to obtain an accurate estimation of the
effort and project duration, the effect of all relevant
parameters must be considered.
• The intermediate COCOMO model recognizes this fact &
refines the initial estimate obtained by the basic COCOMO by
using a set of 15 cost drivers (multipliers) based on various
attributes of software development

89. Intermediate COCOMO Model cont.
• Product attributes -
o Required software reliability
extent
o Size of the application
database
o The complexity of the product
• Computer attributes -
o Run-time performance
constraints
o Memory constraints
o The volatility of the virtual
machine environment
o Required turnabout time
• Personnel attributes -
o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language
experience
• Project attributes –
o Use of software tools
o Application of software
engineering methods
o Required development schedule

90. Intermediate COCOMO Model cont.
Cost Drivers Very Low Low Nominal High Very High
Product Attributes
RELY 0.75 0.88 1.00 1.15 1.40
DATA - 0.94 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30
Computer Attributes
TIME - - 1.00 1.11 1.30
STOR - - 1.00 1.06 1.21
VIRT - 0.87 1.00 1.15 1.30
TURN - 0.94 1.00 1.07 1.15

91. Intermediate COCOMO Model cont.
Cost Drivers Very Low Low Nominal High Very High
Personnel attributes
ACAP 1.46 1.19 1.00 0.86 0.71
PCAP 1.42 1.17 1.00 0.86 0.70
AEXP 1.29 1.13 1.00 0.91 0.82
VEXP 1.21 1.10 1.00 0.90 -
LEXP 1.14 1.07 1.00 0.95 -
Project Attributes
MODP 1.24 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83
SCED 1.23 1.08 1.00 1.04 1.10

92. Intermediate COCOMO Model cont.
• Intermediate COCOMO equation :
• E = ai (KLOC) * EAF
• D = ci (E)
Project ai bi ci di
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

93. Example
For a given project was estimated with a size of 300 KLOC.
Calculate the Effort, Scheduled time for development by
considering developer having high application experience and
very low experience in programming.
Given the estimated size of the project is: 300 KLOC
Developer having highly application experience: 0.82
Developer having very low experience in programming: 1.14
EAF = 0.82*1.14 = 0.9348
Effort (E) = a*(KLOC)b *EAF
= 3.0*(300)1.12 *0.9348
= 1668.07 MM
Scheduled Time (D) = c*(E)d
= 2.5*(1668.07)0.35
= 33.55 Months(M)

94. Detailed COCOMO Model
• Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s
impact on each step of the software engineering process.
• The detailed model uses different effort multipliers for each
cost driver attribute.
• In detailed COCOMO, the whole software is divided into
different modules and then we apply COCOMO in different
modules to estimate effort and then sum the effort.
• This approach reduces the margin of error in the final
estimate

95. Detailed COCOMO Model
The Six phases of detailed COCOMO are:
• Planning and requirements
• System structure
• Complete structure
• Module code and test
• Integration and test
• Cost Constructive model

96. Example
A Management Information System (MIS) for an
organization having offices at several places across the
country:
• Database part (semi-detached)
• Graphical User Interface (GUI) part (organic)
• Communication part (embedded)
Cost of the components are estimated separately:
• Summed up to give the overall cost of the system.

97. Budgeting
• The process of creating plans to spend and use money in an
organization makes up budgeting.
• Budgeting helps determine the spread of money available for
project consumption.
• The project manager holds responsibility for the streamlined
working of the project.
• This ensures that project efficiency, standards, time and
quality are not overlooked.
• Under project management, three important factors play a
role in success. These are:
• Budget
• Time
• Quality

98. Project Budget
• A good Project Budget sustains itself as a tool to estimate
project costs. All costs that are likely to incur in a project can
highlight in the planning stage. A good project budget would
include the following cost planning:
1. Labor costs
2. Material costs
3. Operating costs.
• Project Budgets can be of two main kinds:
1. Resource Budget (matters concerning cost allocation for
internal resources);
2. Financial Budget (matters concerning cash flow,
payments and external resources).

99. Steps to Create a Project Budget
• It is of utmost necessity to know how to plan, devise, create
and then finally, manage a Project Budget.
• Steps –
1. Create a task list to focus on requisite cost elements for the project.
2. Use historical data to research similar projects & the costing involved.
3. Estimate components based on project requirements, market research
& find cost-effective and efficient alternatives.
4. Use market references to understand how competitors & seasoned
companies manage budgetary control of their projects.
5. Take advise of experts to curb down doubts & obtain opinions to
improve decision making.
6. Confirm accuracy of report with internal research & discussion with
respective departmental heads.
7. Streamline the budget based on research & planning done in the above
steps.
8. Test the budget on pilot projects for sample usage to understand
efficiency & practicality.
9. Get approval from respective authorities.