Quality Content for Outcome based Learning

Software Project Management

Unit -2
Project Life Cycle and Effort Estimation

Ver. No.: 1.1 Copyright © 2021, ABES Engineering College

 Course Content
• Software process and Process Models
• Choice of Process models
• Rapid Application development
• Agile methods
• Dynamic System Development Method
• Extreme Programming
• Managing interactive processes
• Basics of Software estimation
• Effort and Cost estimation techniques
• COSMIC Full function points
• COCOMO II : a Parametric Productivity Model
2
Copyright © 2021, ABES Engineering College
 Software Process and Process Models
A Software product development process usually starts when a request for the product is received from the
customer.

1. Starting from the inception stage:

• A product undergoes a series of transformations through a few identifiable stages.
• Until it is fully developed and released to the customer.

2. After release:
• the product is used by the customer and during this time the product needs to be maintained for fixing
bugs and enhancing functionalities. This stage is called Maintenance stage.

This set of identifiable stages through which a product transits from inception to retirement form the life cycle
of the product.

Life cycle model (also called a process model) is a graphical or textual representation of its life cycle.

3
Copyright © 2021, ABES Engineering College
 Choice of Process models
• The word "process* is sometimes used to emphasize the idea of a system in action. This idea can be
applied to the development of computer-based systems where a number of interrelated activities have to
be undertaken to create a linal product. These activities can be organized in different ways and we can
call these process models.

• A major part of the planning will be the choosing of the development methods to be used and the slotting
of these into an overall process model.

• Any software process must include the following four activities:

o Software specification (or requirements engineering): Define the main functionalities of the software
and the constrains around them.
o Software design and implementation: The software is to be designed and programmed.
o Software verification and validation: The software must conforms to it’s specification and meets the
customer needs.
o Software evolution (software maintenance): The software is being modified to meet customer and
market requirements changes.

4
Copyright © 2021, ABES Engineering College
 The various Process Models are : -

• Water Fall Model

• Spiral Model

• Prototype Model

• Incremental Delivery

5
Copyright © 2021, ABES Engineering College
 1.Waterfall Model

6
Copyright © 2021, ABES Engineering College
 1.Waterfall Model

• The waterfall model is a sequential approach, where each fundamental activity of a

process represented as a separate phase, arranged in linear order.

• In the waterfall model, you must plan and schedule all of the activities before starting
working on them (plan-driven process).

• Plan-driven process is a process where all the activities are planned first, and the
progress is measured against the plan.

7
Copyright © 2021, ABES Engineering College
 1.Waterfall Model
Suitability of waterfall model:

• There are no ambiguous requirements (no confusion).

• It is good to use this model when the technology is well understood.
• The project is short and cast is low. Risk is zero or minimum.

When to use water fall model?

• Requirements are clear and fixed that may not change.

• There are no ambiguous requirements (no confusion).
• It is good to use this model when the technology is well understood.
• The project is short and cast is low.
• Risk is zero or minimum.
8
Copyright © 2021, ABES Engineering College
 1.Waterfall Model
Advantages of waterfall Model:
• It is simple and easy to understand and use.
• It is easy to manage.
• It works well for smaller and low budget projects where requirements are very well understood.
• Clearly defined stages and well understood.
• It is easy to arrange tasks.
• Process and results are well documented.

Disadvantages of waterfall Model:

• It is difficult to measure progress within stages.

• Poor model for long and ongoing projects.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for long and object oriented projects.
• Cannot accommodate changing requirements.

9
Copyright © 2021, ABES Engineering College
 2.Spiral Model

10
Copyright © 2021, ABES Engineering College
 2.Spiral Model

11
Copyright © 2021, ABES Engineering College
 2.Spiral Model

• The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis.
• The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.
• A software project repeatedly passes through these phases in iterations (called Spirals in
this model).
• The baseline spiral, starting in the planning phase, requirements is gathered and risk is
assessed.
• Each subsequent spiral builds on the baseline spiral. It is one of the software development
models like Waterfall, Agile.

12
Copyright © 2021, ABES Engineering College
 2.Spiral Model

• Planning Phase: Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications.

• Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found during
the risk analysis then alternate solutions are suggested and implemented.

• Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.

• Evaluation phase: This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.

13
Copyright © 2021, ABES Engineering College
 2.Spiral Model

Suitability of spiral model:

• Expensive: Spiral Model is not suitable for small projects as it is expensive.

• Too much dependability on Risk Analysis: The successful completion of the project is very
much dependent on Risk Analysis.

• Without very highly experienced experts, it is going to be a failure to develop a project using this
model.

14
Copyright © 2021, ABES Engineering College
 2.Spiral Model
Advantages of Spiral Model:-
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral Model:-

• 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.

15
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model

What is Prototyping?
• Prototyping is the process of quickly putting together a working model (a prototype) in order to
test various aspects of a design, illustrate ideas or features and gather early user feedback.
• Prototyping is often treated as an integral part of the system design process, where it is
believed to reduce project risk and cost.
• The Prototyping model suggests that before carrying out development of actual software, a
working prototype of the system is built.

16
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model
Prototyping Model:
• Often one or more prototypes are made in a process of incremental development where each
prototype is influenced by the performance of previous designs, in this way problems or
deficiencies in design can be corrected.
• When the prototype is sufficiently refined and meets the functionality, robustness,
manufacturability and other design goals, the product is ready for production.

What is a Prototype?
1. A prototype is a toy implementation of a system having:
• limited functional capabilities
• low reliability
• inefficient performance
2. An important purpose for the use of prototype is:
• To illustrate the input data formats messages, reports
• The interactive dialog to the customer
17
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model
Why Prototyping?
1. A developed prototype can help engineers to critically examine technical issues associated with
product development:
• response time of a hardware controller,
• efficiency of a sorting algorithm, etc.
2. The next reason for developing a prototype is:
• it is impossible to ``get it right'' the first time,
• we must plan to throw away the first productif we want to develop a good product.

18
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model
How prototyping model is built?
• Start with approximate requirements.
• Carry out a quick design.
• Built a prototype:
1.The developed prototype is submitted to the customer for his evaluation:Based on the
user feedback, requirements are refined.
2.This cycle continues until the user approves the prototype.
• The actual system is developed using the iterative waterfall approach.

19
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model

20
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model
Advantages of Software Prototyping Model:
Reduced time and costs:
• Prototyping improves the quality of the specifications and requirements provided to
customers.
• With prototyping, customers can anticipate higher costs, needed changes and
potential project hurdles, and most importantly, potential end result disasters.
• Strong prototyping can ensure product quality and savings for years to come.
• Prototyping improves the quality of requirements and specifications provided to customers.
• Needed changes detected later in development cost exponentially more to implement.
• With prototyping, you can determine early what the end user wants with faster and less
expensive software.

21
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model(Adv.)
Improved and increased user involvement:
• Most customer want to feel like they are involved with the intricate details of their project.
• Prototyping requires user involvement and enables them to see and interact with a working
model of their project.
• With prototypes, customers can give their immediate feedback, request project changes
and alter model specifications.
• Prototyping most importantly helps eliminate misunderstandings and miscommunications
during the development process.

22
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model

Disadvantages of Software prototyping model:

Insufficient analysis:
• A focus on a limited prototype can distract developers from properly analyzing the complete
project.
• The potential end result:
• A potential overlooking of better solutions, incomplete specifications or the conversion of limited
prototypes into poorly engineered and developed final projects that are hard to maintain.
User confusion:
• The worst-case scenario of any prototype is customers mistaking it for the finished project.
• Customers seeing a rough prototype may not understand it merely needs to be finished or
polished. Also, customers can wrongly perceive the prototype to accurately model the
performance of the final system. Customers may also grow fond of prototype features that are
not part of the final system.

23
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model (Dis-Adv.)
• Developer misunderstanding of user objectives: For every project to be successful,
developers and customers must be on the same page and share the same project objectives.
If customers require all proposed features of a prototype be included in the final product, this
can lead to team and mission conflicts.

• Excessive Development Time: Remember, prototypes are by nature designed to be

developed quickly. If a developer spends too much time developing a complex prototype, the
project can run into roadblocks (especially if there are disagreements over prototype details)
and run over both time and cost budgets.

24
Copyright © 2021, ABES Engineering College
 3.Software Prototyping Model

When to use Prototype model?

• Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model. It might take a while for a system to be built that
allows ease of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system.
• They are excellent for designing good human computer interface systems.

25
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery

26
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
• Incremental delivery is an approach to software development where some of the developed
increment are delivered to the customer and deployed for use in an operational environment.
• In an incremental delivery process, customers Identify, in outline, the services to be provided by
the system. They identify which of the services are most important and which are least
important to them.
• Once the system increments have been identified, the requirement for the services to be
delivered in the first increment are defined in details and that increment is developed.
• During development, further requirement analysis for later increments can take place but requirement
changes for the current increment are not accepted.
• Once an increment is completed and deliverd, customer can put it into service.
• This means that they take early delivery of part of the system functionality.

27
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
Advantages of Increment Delivery :
• Customers can use the early increments as prototype and gain experience that inform their
requirements for later system increment. Unlike prototypes, these are part of the real system so
there is no re-learning when the complete is available.
• Customers do not have to wait until the entire system is delivered before they can gain value from it.
The first increment satisfies their most critical requirements so they can use the software
immedietly.
• The process maintains the benefits of incremental development in that it should be relatively easy
to incorporate changes into the system.
• As the highest-priority services are deliverd first and increments then integrated, the most important
system services receive the most testing. This means that the customer are less likely to encounter
software failures in the most important parts of the system.

28
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
Dis-Advantages of Increment Delivery :
• Most systems require a set of basic facilities that are used by different parts of the system.
• Iterative development can also be difficult when a replacement system is being developed.
• The essence of iterative processes is that the specification is developed in conjunction with the
software.

29
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
Incremental Delivery Plan:
• The content of each increment and the order in which the increments are to be delivered to the
users of the system have to be planned at the outset.
• Basically the same process has to be undertaken as in strategic planning but at a more detailed
level where the attention is given to increments of a user application rather than whole applications.
The elements of the incremental plan are the system objectives, incremental plan and the
open technology plan.

1. Identify system objectives: The purpose is to give an idea of the 'big picture', that is, the overall
objectives that the system is to achieve. These can then expanded into more specific functional
goals and quality goals. Functional goals will include:
• objectives it is intended to achieve;
• computer/non-computer functions to achieve them.

30
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
2. Incremental Plan: Having defined the overall objectives, the next stage is to plan the increments
using the following guidelines:
• steps typically should consist of 1 % to 5% of the total project;
• non-computer steps may be included - but these must deliver benefits directly to the users;
• ideally, an increment should take one month or less and should never take more than three months;
• each increment should deliver some benefit to the user;
• some increments will be physically dependent on others;
• value-to-cost ratios may be used to decide priorities (see below).

31
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
Very often a new system will be replacing an old computer system and the first increments may use parts of the
old system. For example, the data for the database of the new system may initially be obtained from the old
system's standing files.

Which steps should be first? Some steps might be prerequisites because of physical dependencies but others
can be in any order. Value-to-cost ratios can be used to establish the order in which increments are to be
developed. The customer is asked to rate each increment with a score in the range 1-10 in terms of its value. The
developers also rate the cost of developing each of the increments with a score in the range 0-10. This might
seem a rather crude way of evaluating costs and benefits, but people are often unwilling to be more precise. By
then dividing the value rating by the cost rating, a rating which indicates the relative 'value for money' of each
increment is derived.

The value to cost ratio = V/C where V is a score 1-10 representing value to customer and C is a score 0-10
representing cost.

32
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery
Table : Ranking by value to cost ratio

Step Value Cost Ratio Rank

Profit reports 9 I 9 (2nd)
Online database 1 9 0.11 (6th)
Ad hoc enquiry 5 5 I (4th)
Production 2 8 0.25 (5th)
sequence plans
Purchasing profit 9 4 2.25 (3rd)
factors
Clerical procedures 0 7 0 (7th)
Profit based pay for 9 0 oo (1st)
managers

33
Copyright © 2021, ABES Engineering College
 4.Incremental Delivery

3. Create Open Technology Plan:

If the system is to be able to cope with new components being continually added then it has to be built so that it
is extendible, portable and maintainable.
As a minimum this will require the use of:
• a standard high level language;
• a standard operating system;
• variable parameters, for example, items such as organization name, department names and charge rates are
held in a parameter file that can be amended without programmer intervention;
• a standard database management system.

These are all things that might be expected as a matter of course in a modern IS development environment.

34
Copyright © 2021, ABES Engineering College
 5. Rapid Application Development Model

• RAD model is Rapid Application Development model.

• It is a combination of iterative and prototype model.
• In RAD model the components or functions are developed in parallel as if they were mini
projects.
• The developments are time boxed, delivered and then assembled into a working
prototype.
• This can quickly give the customer something to see and use and to provide feedback
regarding the delivery and their requirements.

35
Copyright © 2021, ABES Engineering College
 5. Rapid Application Development Model

36
Copyright © 2021, ABES Engineering College
 5. Rapid Application Development Model

• Business modeling: The information flow is identified between various business functions.

• Data modeling: Information gathered from business modeling is used to define data objects
that are needed for the business.

• Process modeling: Data objects defined in data modeling are converted to achieve the
business information flow to achieve some specific business objective. Description are
identified and created for CRUD of data objects.

• Application generation: Automated tools are used to convert process models into code and
the actual system.

• Testing and turnover: Test new components and all the interfaces.

37
Copyright © 2021, ABES Engineering College
 5. Rapid Application Development Model
RAD Model Phases Activities performed in RAD Modeling

•On basis of the flow of information and distribution between various

Business Modeling
business channels, the product is designed

•The information collected from business modeling is refined into a set of

Data Modeling
data objects that are significant for the business

•The data object that is declared in the data modeling phase is transformed
Process Modeling
to achieve the information flow necessary to implement a business function

•Automated tools are used for the construction of the software, to convert
Application Generation
process and data models into prototypes

•As prototypes are individually tested during every iteration, the overall
Testing and Turnover
testing time is reduced in RAD.

38
Copyright © 2021, ABES Engineering College
 When to use RAD Methodology??

 When a system needs to be produced in a short span of time (2-3 months)

 When the requirements are known

 When the user will be involved all through the life cycle

 When technical risk is less

 When there is a necessity to create a system that can be modularized in 2-3 months of time

 When a budget is high enough to afford designers for modeling along with the cost of
automated tools for code generation

39
Copyright © 2021, ABES Engineering College
 Advantages of RAD Model

• Reduced development time.

• Increases reusability of components

• Quick initial reviews occur

• Encourages customer feedback

• Integration from very beginning solves a lot of integration issues.

40
Copyright © 2021, ABES Engineering College
 Dis-Advantages of RAD Model

• Depends on strong team and individual performances for identifying business

requirements.

• Only system that can be modularized can be built using RAD

• Requires highly skilled developers/designers.

• High dependency on modeling skills

• Inapplicable to cheaper projects as cost of modeling and automated code generation is

very high.

41
Copyright © 2021, ABES Engineering College
 Difference b/w Various Software Process Models

42
Copyright © 2021, ABES Engineering College
 Difference b/w Various Software Process Models

43
Copyright © 2021, ABES Engineering College
 Why Agile??

• Agile software development refers to software

development methodologies centered round the
idea of iterative development, where
requirements and solutions evolve through
collaboration between self-organizing cross-
functional teams.
• The ultimate value in Agile development is that it
enables teams to deliver value faster, with
greater quality and predictability, and greater
aptitude to respond to change.

44
Copyright © 2021, ABES Engineering College
 Agile Methodologies

• Agile methodologies are approaches to product development that

are aligned with the values ​and principles described in the Agile
Manifesto for software development.

• Agile methodologies aim to deliver the right product, with

incremental and frequent delivery of small chunks of functionality,
through small cross-functional self-organizing teams, enabling
frequent customer feedback and course correction as needed.

• In doing so, Agile aims to right the challenges faced by the

traditional “waterfall” approaches of delivering large products in
long periods of time, during which customer requirements
frequently changed, resulting in the wrong products being
delivered.

45
Copyright © 2021, ABES Engineering College
 Agile Methodologies
• Agile is about being responsive to the market and to the customer by responding quickly to their needs and demands and
being able to change direction as the situation demands.
• Be it IT or software development or any other field where there is a flow of work and delivery of work products, Agile methods
are applicable.
• Agile methods attempt to maximize the delivery of value to the customer and minimize the risk of building products that do not
– or no longer – meet market or customer needs.
• They do this by breaking up the traditionally long delivery cycle (typical of the legacy “waterfall methods”) into shorter periods,
called sprints or iterations.
• The iteration provides the cadence for delivering a working product to the customer, getting feedback and making changes
based on the feedback.
• Thus, Agile methods have sought to reduce delivery times (delivering early, delivering often) to ensure that smaller vertical
chunks of the product get to the market, enabling customers to provide feedback early and ensure that the product they finally
get meets their needs.
• Agile has become an umbrella term for a variety of planning, management and technical methods and processes for
managing projects, developing software and other products and services in an iterative manner.
46
Copyright © 2021, ABES Engineering College
 Agile Methodologies

47
Copyright © 2021, ABES Engineering College
 Agile-Core Values

48
Copyright © 2021, ABES Engineering College
 Agile- Principles

49
Copyright © 2021, ABES Engineering College
 Key Agile Methodologies

50
Copyright © 2021, ABES Engineering College
 SCRUM Methodology- Agile
• Scrum methodology is a simple framework for working with complex projects, and it was created by Ken
Schwaber and Jeff Sutherland.
• Agile software development methodologies are iterative, meaning the work is divided into iterations, which
are called Sprints in the case of Scrum.
• Scrum is executed by small teams of between 7-9 people, including a Scrum Master and a Product Owner.
• In Scrum, projects are divided into cycles (typically 2 or 3 week cycles) called Sprints.
• The Sprint represents a timebox within which a set of features must be developed.
• Multiple sprints might be combined to form a Release – where formal software/ product delivery is made to
the customer/ market.

51
Copyright © 2021, ABES Engineering College
 SCRUM Methodology- Scrum

52
Copyright © 2021, ABES Engineering College
 SCRUM Methodology- Agile

• The overall product functionality is broken down by the Product Owner into smaller features (typically described as
Epics and User Stories – or just Stories).
• These Stories are prioritized and taken up in each Sprint or Iteration.
• The intent of the method is for the team to be able to demo at the end of each Sprint working pieces of the product
to the Product Owner, to make sure that the product is working as intended.
• Overall, the Scrum method breaks the long waterfall process delivery into smaller cycles, which enables product
teams and the end-customer to frequently review working software and ensure that it meets their business
requirements. This ensures that the end product also meets the final requirements of the customer.
• The Scrum method is characterized by specific ceremonies such as the Daily Standup meeting, the Sprint Review
Meeting, the Demo to the Product Owner and the Sprint Retrospective meeting.
• All of these meetings provide collaboration and review opportunities to the team to ensure that development is
progressing as intended, and any issues are resolved quickly.

53
Copyright © 2021, ABES Engineering College
 SCRUM Methodology- Scrum-Board

54
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Agile

• Extreme Programming (XP) is one of the numerous Agile frameworks applied by IT

companies. But its key feature — emphasis on technical aspects of software development
— distinguishes XP from the other approaches.
• Software engineer Ken Beck introduced XP in the 90s with the goal of finding ways to write
high-qualitative software quickly and being able to adapt to customers’ changing
requirements.
• XP is a set of engineering practices. Developers have to go beyond their capabilities while
performing these practices. That’s where the “extreme” in the framework’s title comes from.

55
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Values

•Communication: You can’t work together effectively without sharing knowledge, and you can’t share
knowledge without communication.
•Simplicity: Developers can save time and effort by writing simple, effective code that works properly. Ultimately,
the less complex code enhances product value.
•Feedback: Early, constant feedback is ideal for team members who release frequent software deliveries,
helping them to adjust as the project evolves and changes. The sooner programmers know that the product
requires changes, the easier it is to create those changes (and less painful).
•Respect: Every team member cares about their work, and everyone contributes.
•Courage: It takes guts to admit you're mistaken and that your idea didn't work and must be changed. Being
honest takes courage, and you need honesty in providing realistic estimates, even if stakeholders don't like the
truth.

56
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices

57
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices
• Planning Game

In XP the main planning process is called Planning Game. There are 2 levels of plans in XP; level one is release planning and level
2 is iteration planning
In both levels, there are 3 steps: exploration, commitment, and steering.
The first phase is release planning. The team and stakeholders/customers collaboratively decide what are the requirements and
features that can be delivered into production and when. This is done based on priorities, capacity, estimations and risks factor of the
team to deliver.
In Iteration planning the team will pick up the most valuable items from the list and break them down into tasks then estimates and a
committment to delivering at the end of the iteration.

• Simple Design

In the XP, the team will not do complex or big architecture and designs upfront; instead the team will start with a simple design and
let it emerge and evolve over a period of iterations. The code is frequently refactored so that it will be maintainable and free of
technical debt. Simple designs make the 'definition of done' easier.

XP teams conduct a small test or proof-of-concept workout called spike. The outcome of the spike helps the team to apprehend the
validity of the hypothesis, gauge the complexity of the solution and feel assured to estimate and build something primarily based on
the test.

58
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices
• Test-Driven Development (TDD)

In XP Developers write the unit test cases before starting the coding. The team automates the unit tests and it helps during the build
and integration stage. The main benefit of TDD is that programmers have to only write the code that passes the tests.

Basics steps of TDD,

•Write the unit test case first
•Write a minimal amount of code to pass the test.
•Refactor it by adding the needed feature and functionality, While continuously making sure the tests pass.

• Code Standard

Organizations want their programmers to hold to some well-described and standard style of coding called coding standards. It is a
guideline for the development team as in XP. Since there are multiple programming pairs at play coding standards are very useful to
make consistency in code, style, naming conversion, exception handling and use of parameters.

These standards must define and agreed before the team starts the coding.

It will make the code simple to understand and helps detect the problem or issues quickly and also increases the efficiency of the
software.

59
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices
• Refactoring

Refactoring as the word suggests, is restructuring or reconstructing existing things. In XP over a period of time the team produces
lots of working code and it increases the complexity and that contributes technical debt. To avoid this, we should consider the below
points,
Ensure code or functions are not duplicated.
Ensure all variables in scope, defined and used.
No long functions or methods
Removing unnecessary stuff and variables
Proper use of access modifiers etc.
By refactoring, the programmers look to improve the overall code quality and make it more readable without altering its behavior.

• Pair Programming

This is my favorite and most used practice. Pair programming consists of two programmers operating on the same code and unit tase
cases, on the same system (one display and one keyboard). One programmer plays the pilot role and focuses on clean code, and
compiles and runs. The second one plays the role of navigator and focuses on the big picture and reviews code for improvement or
refactoring.

Every hour or given a period of time this pair is allowed to switch roles so that the pilot will play the role of navigator and vice versa.
The pairs of pilots and navigators are also not fixed and they are frequently swapped, the main benefits of that over a period of time is
that everyone gets to know about the code and functionality of the whole system.
60
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices
• Collective Code Ownership

By following pair programming practices the XP team always takes collective ownership of code. Success or failure is a collective
effort and there is no blame game. There is no one key player here, so if there is a bug or issue then any developer can be called
to fix it.

• Continuous Integration

CI is Continuous Integration. In XP, Developers do pairs programming on local versions of the code. There is a need to integrate
changes made every few hours or on a daily basis so after every code compilation and build we have to integrate it where all the
tests are executed automatically for the entire project.

If the tests fail, they are fixed then and there, so that any chance of defect propagation and further problems are avoided with
minimum downtime.
The team can use CI tools like Jenkins, shippable, Integrity, Azure DevOps Pipelines, etc.

• Small Release

A cross-functional team in XP, releases Minimum Viable Product (MVP) frequently. Small releases also help to breakdown complex
modules in a small chunk of code. This helps the developer team as well as the on-site customer to demonstrate the product and
focus only on the least amount of work that has the highest priority.

61
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices
• System Metaphor

This is majorly connected with the user story, the story must be simple enough to be easily understood by user and developers
and to relate it with code.
It could be a naming conversion practice used in design and code to have a shared understanding between teams. For example
Order_Food() is easily explained -- this will be used to order food.

It easy for the team to relate to the functionality of the particular component by just looking at its name.

• Onsite Customer

This is a similar role as Product Owner in Scrum. Onsite customer plays a major role here and is responsible for crafting the vision,
defining user stories and acceptance criteria, the definition of done and release planning.
They are the experts who know the domain or product and know how to generate a return of investment (ROI) by delivering the
minimum viable product (MVP).
If the onsite customer role is not full time, the role can be filled with product managers, product owners, UI-UX designers and
business analysts who are called proxies.
The word “on-site” implies that the customers or their proxies sit together with the rest of the team to ensure that communication
flows freely.

62
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Practices
• Sustainable Pace

This is a people-centric practice. In XP practices like TDD, continuous integration and refactoring of code help to proactively improve
the quality and stability of the working software.

XP maintains a sustainable pace by introducing down time during the iteration. The team is not doing actual development at this time
but acts as a buffer to deal with uncertainties and issues. Teams can use the slack time to pay down technical debt by refactoring
code or do research to keep up the pace.

63
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Phases

64
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Phases

Planning
• The first phase of Extreme Programming life cycle is planning, where customers or users meet with the
development team to create ‘user stories’ or requirements.
• The development team converts user stories into iterations that cover a small part of the functionality or features
required.
• A combination of iterations provides the customer with the final fully functional product.
• The programming team prepares the plan, time, and costs of carrying out the iterations, and individual
developers sign up for iterations.
• One planning approach is the critical path method, grouping iterations essential for project progress in a linear
fashion, and arranging for completion of other iterations parallel to the critical path.

65
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Phases

Designing
An iteration of XP programming starts with designing.
The guiding principles of this stage are:
• Trust on simplicity by expressing a thing only once and not adding functionality in anticipation.
• Using systems metaphor or standards on names, class names and methods, and agreeing on uniform styles
and formats to ensure compatibility among the work of different team members
• Using Software Class Responsibilities and Collaboration (CRC) Cards that allow for a departure from the
traditional procedural mindset and make possible object oriented technology. Such cards allow all members of
the project team to contribute ideas, and collate the best ideas into the design
• Creating spike solutions or simple programs that explore potential solutions for a specific problem, ignoring all
other concerns, to mitigate risk

66
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-CRC Cards

67
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Phases
Coding
Coding constitutes the most important phase in the Extreme Programming life cycle. XP programming gives priority
to the actual coding over all other tasks such as documentation to ensure that the customer receives something
substantial in value at the end of the day.
Standards related to coding include:
• Developing the code based on the agreed metaphors and standards, and adopting a policy of collective code
ownership.
• Pair programming or developing code by two programmers working together on a single machine, aimed at
producing higher quality code at the same or less cost.
• Strict adherence to 40-hour workweeks with no overtime. This ensures the developers work in the peak of their
mental and physical faculties.
• Frequent integration of the code to the dedicated repository, with only one pair integrating at a time to prevent
conflicts, and optimization at the end.
68
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Phases

Testing
• Extreme program integrates testing with the development phase rather than at the end of the development phase. All codes have
unit tests to eliminate bugs, and the code passes all such unit tests before release.
• Another key test is customer acceptance tests, based on the customer specifications. Acceptance test run at the completion of
the coding, and the developers provide the customer with the results of the acceptance tests along with demonstrations.
Listening
• The basis of extreme programming is a continuous mechanism of customer involvement through feedback during the
development phase. Apart from the customer, the developer also receives feedback from the project manager.
• The basis of feedback is the customer acceptance tests. Each feedback of the customer that specifies revised requirement
becomes the basis of a new design, and the process of design-coding-tests-listening repeats itself. If the customer remains
satisfied with the test results the iteration ends there, and the design for the new iteration starts, which again follows the design-
coding-testing-listening cycle.

69
Copyright © 2021, ABES Engineering College
Extreme Programming (XP)-Advantages and Disadvantages

70
Copyright © 2021, ABES Engineering College
 Extreme Programming (XP)-Comparison

71
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Agile

72
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Agile

73
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Principles

74
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Principles

75
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Principles

76
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Life Cycle

77
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Life Cycle
• The Feasibility and Business Study
In the feasibility and study phase, the problem is defined and technical feasibility of the desired application is
verified. It is also checked whether the application is suitable for the Rapid Application Development (RAD) approach
or not.
Only if the RAD is found as a justified approach for the desired system, the development continues.

• Functional Model Iteration

The main focus in this phase is on building the prototype iteratively and getting it reviewed by the users to bring out
the requirements of the desired system.
The prototype is improved through demonstration to the user, taking the feedback, and incorporating the changes.
This cycle is repeated generally twice or thrice until a part of the functional model is agreed upon.
The end product of this phase is a functional model consisting of an analysis model and some software components
containing significant functionality.
78
Copyright © 2021, ABES Engineering College
 DSDM Methodology-Life Cycle

• Design and Build Iteration

This phase ensures that the prototypes are satisfactorily and properly engineered to suit their operational environment.
The software components designed during the functional modeling are further refined till they achieve a satisfactory standard.
The two phases, as a result, may simultaneously continue. The product of this phase is a tested system ready for implementation.
• Implementation
Implementation is the last and final development stage in this methodology.
In this phase, the users are trained, and the system is put into the operational environment.
At the end of this phase, there are four possibilities, as depicted:
Everything was delivered as per the user demand, so no further development is required.
A new functional area was discovered, so return to the business study phase and repeat the whole process.
A less essential part of the project was missed out due to time constraints. So development returns to the functional model
iteration.
Some non-functional requirements were not satisfied, so the development returns to the design and build phase.

79
Copyright © 2021, ABES Engineering College
 Kanaban Methodology-Agile

• Kanban is a framework that falls under the Agile methodology. It was developed in the late 1940s by a Japanese
engineer named Taiichi Ohno. Agile Kanban Framework focuses on visualizing the entire project on boards in
order to increase project transparency and collaboration between team members.
• Kanban is one of the simplest frameworks used as it allows project managers to efficiently manage and keep
track of their projects. A distinguishing feature of the Kanban framework among different agile methodologies is its
compatibility with the existing organizational setting.

80
Copyright © 2021, ABES Engineering College
 Kanaban Methodology-Agile

• Kanban methodology is an agile method that aims at continuous improvement, flexibility in task management,
and enhanced workflow. With this illustrative approach, the progress of the whole project can be easily
understood in a glance.
• Kanban was used in manufacturing settings to control inventory throughout the supply chain, using a practice
called just-in-time (JIT) manufacturing. In project management, the Kanban methodology adapts the same
concept by ensuring that the amount of required work is the same as the work capabilities of the team.

81
Copyright © 2021, ABES Engineering College
 How does Kanaban Work??

Kanban method revolves around the kanban board. It is a tool that visualizes the entire project to track the flow of
their project. Through this graphical approach of Kanban boards, a new member or an external entity can
understand what’s happening right now, tasks completed and future tasks.
Kanban board indicates
• the current tasks that are being performed
• the tasks to do in the future
• the tasks that are completed

82
Copyright © 2021, ABES Engineering College
 How does Kanaban Work??

• The divided columns are interconnected and tasks

are gradually pulled from the leftmost column (future
tasks) to the rightmost column (completed tasks).
• Kanban system measures the work cycle being
completed through the principle of Work in Progress
(WIP). WIP has certain limits and a pre-defined
specific status.
• Limiting WIP in order to maintain consistent
standards is one of the core principles that govern
the Kanban methodology in Agile. It is extremely
important for the team to complete the current tasks
in the prescribed order.

83
Copyright © 2021, ABES Engineering College
 Kanban Core Principles
1. Initiate with the existing workflow:
Kanban framework emphasizes on making small and gradual changes. Therefore, the team must start with the existing workflow
and continuously improve the process.
2. Limit the existing tasks:
It is important for the team to realize its own limits and cap the WIP accordingly. Taking on more than you can handle will only
waste time and negatively affect the project.
3. Respect existing roles and responsibilities:
An important reason for Kanban’s success is that it does not require organizations to completely overhaul the existing work
culture. Many organizations resist modern methodologies because they don’t feel comfortable with change.
With Kanban, efficiency is improved while staying in the confines of the existing setup.
4. Encourage leadership at all levels:
Project management methodologies such as the traditional method require approval from the project manager for even the
smallest tasks. Kanban gives the freedom of making decisions to the individual working on the task. This grooms future leaders
who continuously learn from their mistakes and improve their work.

84
Copyright © 2021, ABES Engineering College
 Kanban Core Practices
1. Visualization of workflow:
The whole concept of Kanban revolves around proper visualization of the entire project. Kanban board software is used
throughout the industry for this purpose. In the past, people used to get a whiteboard on wheels and use it with the help of
different columns and Kanban cards.
This method has now become obsolete as advanced project management tools are now readily available in the market that can
make your life much simpler.
2. Reduction of WIP:
WIP in the case of Kanban is supposed to be according to the capability of the team. Usually, a cap is applied to WIP in order to
ensure maximum efficiency. On the Kanban board, a limit is applied to the number of tasks that can be performed at once.
No new task can be pulled as long as the limit is achieved, this ensures that the whole team works together and completes all
related tasks around the same time.

85
Copyright © 2021, ABES Engineering College
 Kanban Core Practices
3. Efficient workflow management:

Measuring lead time and cycle time where lead time, the complete time spent on completing a task is an important
parameter that project teams must reduce as much as possible.
4. Explicit management policies:
It is important for the project team to know what they are trying to achieve. The reason behind is quite simple,
when someone has a clear project goal in front of them, they’ll try harder to achieve it.
5. Take feedback:
At the end of the day, the most important entity for any business is the client and implementing an effective
feedback system is extremely important.
On the Kanban boards, a column can be assigned for feedback from either an external evaluator or the customers
themselves. In this way, the quality of the delivered work can be constantly maintained.

86
Copyright © 2021, ABES Engineering College
 Kanban vs. Scrum

87
Copyright © 2021, ABES Engineering College
 Crystal Methodology-Agile

88
Copyright © 2021, ABES Engineering College
 FDD Methodology-Agile

89
Copyright © 2021, ABES Engineering College
 Lean Software Development-Agile

90
Copyright © 2021, ABES Engineering College
 Software Effort Estimation

91
Copyright © 2021, ABES Engineering College
 Why to Estimate??

92
Copyright © 2021, ABES Engineering College
 Challenges in Estimation

• Complexity and Invisibility: As software project are more difficult to monitor and are more
complex in nature.

• Subjective nature of estimating: For example some research shows that people tend to
underestimate the difficulty of small task and over-estimate the large ones.

• Political Implications: Forced to produce unrealistic estimates.

• Changing Technology: Where technology change rapidly, it is difficult to use experience

of previous projects on new ones.

• Lack of homogeneity of project experience: Even where technologies have not changed,
knowledge about typical task durations may not be easily transferred from one project to
another because of other differences between projects.

93
Copyright © 2021, ABES Engineering College
 Usefulness of Productivity of the Project

• Project Manager uses the Productivity data of the past projects to decide the effort
distribution for the new project.

• Programmer Productivity=SLOC / day

• Organizational Productivity is calculated based on it….

• But still it is difficult to predict because of uncertainities in their interpretation.

94
Copyright © 2021, ABES Engineering College
 Past Poject Data (effort in work-months)

95
Copyright © 2021, ABES Engineering College
 Past Poject Data (effort in work-months)
Calculate Productivity

• Project a: wm=16.7, SLOC= 6050 , hence the no. of days required will be 16.7 X 30=
501 days

Productivity= 6050/ 501 = 12.7 SLOC/ days

• Project e: wm=17.3, SLOC= 3315 , hence the no. of days required will be 17.3 X 30=
519 days

Productivity= 3315 / 519 = 6.7 SLOC/ days

• Project g: wm=10.1, SLOC= 38614 , hence the no. of days required will be 10.1 X 30=
303 days

Productivity= 38614 / 303 = 127 SLOC/ days

But the industry average is 10 SLOC / day….. Is it too low??

96
Copyright © 2021, ABES Engineering College
 Where are Estimates Done ??

• Strategic Planning: Project portfolio management involves estimating the costs and benefits of new
applications in order to allocate priorities. Such estimates may also influence the scale of development staff
recruitment.

• Feasibility Study: This confirms that the benefits of the potential system will justify the costs.

• System Specification: Most system development methodologies usefully distinguish between the definition of
the users’ requirements and the design which shows how these requirements are to be fulfilled.

• Evaluation of Supplier Proposals: Own estimates in order to estimate the worthiness of tender based system
benefits.

• Project Planning: As the planning and implementation of the project becomes more detailed, more estimates
of smaller work components will be made. These will confirm earlier broad-brush estimates, and will support
more detailed planning, especially staff allocations.

97
Copyright © 2021, ABES Engineering College
 Stepwise Project Planning-Framework

98
Copyright © 2021, ABES Engineering College
 Problems with Over Estimates

• Parkinson’s Law: “ Work expands to fill the time available”, that is, given in easy target staff will work less
hard.

• Brook’s Law: The effort of implementing project will go up disproportionately with the number of staff assigned
to the project. As the project team grows in size, so will the effort that has to go into magagement,
coordination and communication. This has given rise, in extreme cases , to the notion of Brooks’ Law : “
Putting more people on a late job makes it later”

99
Copyright © 2021, ABES Engineering College
 Problems with Under- Estimates

• Less severity than over-estimates.

• The danger is ---- quality

• Work produced may be with substandard only

• Reasonable targets- motivation and morale are enhanced.

• Unrealistic targets--- Motivation is reduced.

• An estimate is not really a prediction, but a management goal.

100
Copyright © 2021, ABES Engineering College
 The Basics for Software Estimating

• The need of historical data: Most estimating methods need information about past projects.However, care is
needed when applying past performance to new projects because of possible differences in factors such as
programming languages and the experience of staff.

• Parameters to be estimated: The project manager needs to estimate two project parameters for carrying out
project palnning. These two parameters are effort and duration. Duration is usually measured in months.
Work-month (wm) is a popular unit for effort measurement. The term person-month (pm) is also frequently
used to mean the same as work-month. One person-month is the effort an individual can typically put in a
month. The person-month estimate implicitily takes into account account the productivity losses that normally
occur due to time lost in holidays, weekly-offs, coffe-breaks, etc.

101
Copyright © 2021, ABES Engineering College
 The Basics for Software Estimating

• Measure of Work: Measure of work involved in completing the project is alo called the size of the project.

Let’s examine the meaning of the term ‘project size’.

The size of the project is obviously not the number of bytes that the source code occupies, neither is it the size of
the executable code. The project size is the measure of the problem complexity in terms of of the effort and time
required to develop the product.

Two metrics are at present popularly being used to measure size:

 Source lines of codes (SLOC): SLOC measure suffers various types of disadvantages , which are to a great
extent corrected in the FP measure. However SLOC measure is intuitively simpler, so it is still being widely
used.

 Function Points(FP)

102
Copyright © 2021, ABES Engineering College
 Shortcomings of SLOC Measure
• No precise definition: SLOC is a very imprecise measure. Unfortunately, researchers have not been consistent on points
like does it include comment lines or are data declarations to be included?

• Difficult to estimate at start of a project: From the project manager’s perspective, the biggest shortcoming of SLOC metric is
that it is very difficult to estimate it during project planning stage, and can be accurately computed only after the
development of the software is complete. SLOC count can only be guessed at the beginning of the project, often leading to
grossly inaccurate estimations.

• Only a code measure: SLOC is a measure of coding activity alone. A good problem size measure should consider the effort
required for carrying out all the lifecycle activities and not just coding.

• Programmer-dependent: SLOC gives a numerical value to the problem size that can vary widely with the coding style of the
individual programmer.

• Does not consider code complexity: Two software components with the same KLOC will not necessarily take the same time
to write, even if done by the same programmer in the same environment.

103
Copyright © 2021, ABES Engineering College
 Software Effort Estimation Techniques

104
Copyright © 2021, ABES Engineering College
 Bottom-up Estimating
• With the bottom –up approach the estimator breaks the project into its component tasks.

• With the large project, the process of breaking it down into tasks is iterative: each task is decomposed into its
component subtasks and these in turn could be further analysed.

• It is suggested that this is repeated until you get tasks an individual could do in a week or two.

• The bottom-up part comes in adding up the calculated effort for each activity to get an overall estimate.

• When a project is completely novel and there is no historical data available, yhe estimator would be forced to
use the bottom-up approach.

105
Copyright © 2021, ABES Engineering College
 Bottom-up Estimating
A procedural code-oriented approach
• Envisage the number and type of software modules in the final system: Most information systems are built from a small set
of opeartions e.g. insert, amend, update, display, delete, print , etc. The same principle should equally applied to embedded
systems, albeit with a different set of primitive functions.

• Estimate the SLOC of each identified module: One way to judge the number of instructions likely to be in a program is to
draw up a program structure diagram and visualize how many instructions would be needed to implement each identified
procedure .

• Estimate the work content, taking into account complexity and technical difficulty: The practice is to multiply the SLOC
estimate by a factor for complexity and technical difficulty. This factor will depend largely on the subjective judgement of the
estimator. For example, the requirement to meet particulary highly constrained performance targets can greatly increase
programming effort.

• Calculate the work-days effort: Historical data can be used to provide ratios to convert weighted SLOC to effort.

106
Copyright © 2021, ABES Engineering College
 The Top-down Approach and Parametric Models

107
Copyright © 2021, ABES Engineering College
 A Sample Excercise

108
Copyright © 2021, ABES Engineering College
 Expert Judgement

109
Copyright © 2021, ABES Engineering College
 Estimated by Analogy
• This is also called case-based reasoning.

• The esrimator identifies completed projects( source cases) with similar characterstics to the new project((the
target case).

• The effort recorded for the matching source case is then often used as a base estimate for the target.

• The esrimator then identifies differences between the target and the source and adjusts the base estimate to
produce an estimate for the new project.

• This can be the good approach where you have information about some previous projects but not enough to
draw generalized conclusions about what might be usual drivers or typical productivity rates.

• A problem is identifying the similarities and differences between applications where you have large number to
past projects to analyse.

• One attempt to automate this selection process is ANGEL software tool.

• This identifies the source case that is nearest the target by measuring the Euclidean distance between cases.

110
Copyright © 2021, ABES Engineering College
 Estimated by Analogy

Euclidean distance is calculated as:

111
Copyright © 2021, ABES Engineering College
 Estimated by Analogy- Example

112
Copyright © 2021, ABES Engineering College
 Estimated by Analogy- Exercise!

113
Copyright © 2021, ABES Engineering College
 Estimated by Analogy- Solution

114
Copyright © 2021, ABES Engineering College
 Albrecht Function Point Analysis

115
Copyright © 2021, ABES Engineering College
 Albrecht Function Point Analysis
This is the top-down method that was devised by Allan-Albrecht when he worked for IBM. Albrecht was investigating
programming productivity and needed to quantify the functional size of programs independently of their programming
languages. He developed the idea of function points (FP s).

The basis of function point analysis is that information systems comprise five major cmponents, or ‘ external user types’ in
Albrecht’s technology that are of benefit to the users.

• External Input Types: These are the input transactions which update internal computer files.

• External Output Types: These are the transactions where data is output to the user. Typically these would be printed
reports, as screen displays would tend to come under external inquiry types (see below).

• External Inquiry Types:These are the transactions initiated by the user which provide information but do not update the
internal files. The user inputs some information that directs the system to the details required.

• Logical Internal File Types: These are the standing files used by the system. The term ‘file’ does not sit easily with modern
information systems. It refers to a group of data items that is usually accessed together. It may be made up of one or more
record types.

116
Copyright © 2021, ABES Engineering College
 Albrecht Function Point Analysis
• External Interface File Types: These types allow for output and input that may pass to and from other computer
applications. Examples of this would be the transmission of accounting data from an order processing system to the main
ledger system or the production of a file of direct debit details on a magnetic or electronic medium to be passed to the
bankers Automated clearing system(BACS). Files shared between applications would also be counted here.

117
Copyright © 2021, ABES Engineering College
 Albrecht Function Point Analysis-Procedure

118
Copyright © 2021, ABES Engineering College
 Albrecht Complexity Multipliers

119
Copyright © 2021, ABES Engineering College
 Albrecht Complexity Multipliers

120
Copyright © 2021, ABES Engineering College
 Sample Exercise!!

121
Copyright © 2021, ABES Engineering College
 Other Considerations

122
Copyright © 2021, ABES Engineering College
 Function Points Mark II

123
Copyright © 2021, ABES Engineering College
 Model of Transaction

124
Copyright © 2021, ABES Engineering College
 Function Point Mark II Contd…

125
Copyright © 2021, ABES Engineering College
 Sample Exercise -1

126
Copyright © 2021, ABES Engineering College
 Sample Exercise-2

127
Copyright © 2021, ABES Engineering College
 COSMIC Full Function Points

128
Copyright © 2021, ABES Engineering College
 COSMIC Full Function Points-Contd…

129
Copyright © 2021, ABES Engineering College
 COSMIC Full Function Points-Contd…

130
Copyright © 2021, ABES Engineering College
 COSMIC Full Function Points-Contd…

131
Copyright © 2021, ABES Engineering College
 COSMIC Full Function Points-Contd…

Drawback:

132
Copyright © 2021, ABES Engineering College
 COSMIC Full Function Points-Example

133
Copyright © 2021, ABES Engineering College
 COCOMO

134
Copyright © 2021, ABES Engineering College
 COCOMO-I

• Effort= c(size)^k
• COCOMO-I is a parametric method( Formula based).
• Effort in person-months (152 working hours).
• Size in kdsi ( [ Kilo ] thousands of delivered source code instructions).
• Where c, k are constants.

135
Copyright © 2021, ABES Engineering College
 COCOMO-I

• Organic Mode: Softwares developed by small teams in a highly familiar in-house environment ;
small system ; interface requirments are flexible.
• Embedded Mode: System being developed had to operate within very tight constraints ;
changes to the system is costly.
• Semi-detached Mode: Combined elements of organic and embedded modes ; characterstics
that came between the two.

136
Copyright © 2021, ABES Engineering College
 COCOMO-I

137
Copyright © 2021, ABES Engineering College
 COCOMO-I Sample Excercise

138
Copyright © 2021, ABES Engineering College
 COCOMO-I Sample Solution

139
Copyright © 2021, ABES Engineering College
 COCOMO-I Exercise Solution

140
Copyright © 2021, ABES Engineering College
 COCOMO-I Sample Exercise 2

141
Copyright © 2021, ABES Engineering College
 COCOMO-I Solution

142
Copyright © 2021, ABES Engineering College
 COCOMO-II

143
Copyright © 2021, ABES Engineering College
 COCOMO-II

144
Copyright © 2021, ABES Engineering College
 COCOMO-II

145
Copyright © 2021, ABES Engineering College
 COCOMO-II

146
Copyright © 2021, ABES Engineering College
 COCOMO-II

147
Copyright © 2021, ABES Engineering College
 COCOMO-II

NOP is the object points that needs to be developed and differ from the object points count
because their may be reuse

148
Copyright © 2021, ABES Engineering College
 COCOMO-II

149
Copyright © 2021, ABES Engineering College
 COCOMO-II-Example

Example: Use the COCOMO II model to estimate the effort required to build software for a simple ATM that
produces 12 screens, 10 reports and will require approximately 80% as new software components. Assume
average complexity and average developer/environment maturity. Use the application composition model with
object points given below

150
Copyright © 2021, ABES Engineering College
 COCOMO-II-Example

Example: Use the COCOMO II model to estimate the effort required to build software for a simple ATM that
produces 12 screens, 10 reports and will require approximately 80% as new software components. Assume
average complexity and average developer/environment maturity. Use the application composition model with
object points given below

151
Copyright © 2021, ABES Engineering College
 COCOMO-II-Example

152
Copyright © 2021, ABES Engineering College
 COCOMO-II

153
Copyright © 2021, ABES Engineering College
 COCOMO-II

154
Copyright © 2021, ABES Engineering College
 COCOMO-II

155
Copyright © 2021, ABES Engineering College
 COCOMO-II

• Scale Factor Values….sf…..

156
Copyright © 2021, ABES Engineering College
 COCOMO-II

• Early Design Effort Multipliers.

157
Copyright © 2021, ABES Engineering College
 COCOMO-II
• Post Architectures Effort Multipliers.

158
Copyright © 2021, ABES Engineering College
 COCOMO-II
• Value for Multipliers.

159
Copyright © 2021, ABES Engineering College
 Thank You

160
Copyright © 2021, ABES Engineering College