Unit II

SELECTION OF AN APPROPRIATE PROJECT APPROACH,

SOFTWARE EFFORT ESTIMATION
Selection of an Appropriate Project Approach

Introduction:
Here we are concerned with choosing the right approach to a particular project:
variously called technical planning, project analysis, methods engineering and
methods tailoring
In-house: means that the developers and the users of the software are in the same
organization.
Often the methods to be used dictated by organizational standards
Suppliers: : means that the developers and the users of the software are in the
different organization.
Need for tailoring as different customers have different needs
Developing a new IT application in-house:
Time is needed to develop the software
Would often require the recruitment of new technical staff to do the
job
Usually, the new staff won’t be needed after the project is
completed
Sometimes due to the novelty of the project there may be lack of
executives to lead the effort
Outsourcing
Contracting the project out to an external IT development company
(outsourcing):
Time is needed to develop the software
The conducting company will have technical and project expertise
not readily available to the client
The client would still do management effort to establish and
manage the contracts
Steps of Project Analysis
Identify project as either objective driven or product driven.
 Analyze other project characteristics by asking:–
 Will we implement a data-oriented or a process oriented system?
 Will the software to be produced be a general tool or application specific?
 Are there specific tools available for implementing the particular type of
application?
 E.g.: – does it involve concurrent processing?
 Is the system knowledge-based?
 Will the system to be produced makes heavy use of computer graphics?
Is the system to be created safety critical?
 Is the system designed to carry out predefined services or to be
engaging and entertaining?
 What is the nature of the hardware/software environment in which
the system will operate? Identify high-level project risks.
 The more uncertainty in the project the more the risk that the
project will be unsuccessful.
 Recognizing the area of uncertainty allows taking steps towards
reducing its uncertainty.
 Uncertainty can be associated with the products, processes, or
resources of a project.
Product uncertainty:
 How well are the requirements understood.
 The users themselves could be uncertain about what the system is
to do.
 Process uncertainty:
 For the project under consideration, the organization will use an
approach or an application building-tool that it never used before.
 Resource uncertainty:
 The main area of resource uncertainty is the availability of the staff
with the right ability and experience.
General approach
Look at risks and uncertainties e.g.
 are requirement well understood?
 are technologies to be used well understood?
 Look at the type of application being built e.g.
 information system? embedded system?  criticality? differences
between target and development environments?
 Clients’ own requirements
 need to use a particular method
The Waterfall Model

The waterfall model is a software development model used in the context

of large, complex projects, typically in the field of information technology.
It is characterized by a structured, sequential approach to project
management and software development.
The waterfall model is useful in situations where the project requirements
are well-defined and the project goals are clear.
It is often used for large-scale projects with long timelines, where there is
little room for error and the project stakeholders need to have a high level
of confidence in the outcome.
Let us now learn about each of these phases in detail which include
further phases
Feasibility Study:
The main goal of this phase is to determine whether it would be
financially and technically feasible to develop the software.
The feasibility study involves understanding the problem and then
determining the various possible strategies to solve the problem.
These different identified solutions are analyzed based on their
benefits and drawbacks,
The best solution is chosen and all the other phases are carried out as
per this solution strategy.
1. Requirements Analysis and Specification:
The requirement analysis and specification phase aims to understand
the exact requirements of the customer and document them properly.
This phase consists of two different activities
Requirement gathering and analysis: Firstly all the requirements
regarding the software are gathered from the customer and then the
gathered requirements are analyzed.
Requirement specification: These analyzed requirements are
documented in a software requirement specification (SRS) document.
SRS document serves as a contract between the development team
and customers.
2. Design:
The goal of this phase is to convert the requirements acquired in the
SRS into a format that can be coded in a programming language. It
includes high-level and detailed design as well as the overall software
architecture.
3. Development
In the coding phase software design is translated into source code
using any suitable programming language. Thus each designed
module is coded.
4. Testing :
The testing phase aims to check whether each module is working
properly or not.
5. Deployment:
Once the software is developed and tested then it is deployed to the
customer.
6. Maintenance :
Maintenance is the most important phase of a software life cycle.
maintenance is carried out to correct errors that were not discovered
during the product development phase. maintenance is carried out to
enhance the functionalities of the system based on the customer’s
request.
The Spiral Model
The Spiral Model is a Software Development Life Cycle (SDLC)
model that provides a systematic and iterative approach to software
development.
In its diagrammatic representation, looks like a spiral with many
loops.
The exact number of loops of the spiral is unknown and can vary
from project to project.
Each loop of the spiral is called a phase of the software development
process.
The spiral model for software development is the best-chosen
software model for risky, extensive and complicated projects.
the spiral model consists of multiple phases that are executed in a
cyclic or spiral fashion, with each iteration referred to as a "spiral."
•Planning
•Risk Analysis
•Engineering
•Evaluation
One of the main advantages of the Spiral Model is its ability to
accommodate changes and address risks proactively.
Overall, the Spiral Model is a valuable approach for managing
software development projects that require a flexible and risk-aware
methodology.
Phase Of Spiral Model Software Development Life Cycle
1. Planning (Requirement Gathering)
The primary purpose of the planning phase in the spiral model SDLC
is to collect, understand and identify the core objectives and set some
alternative solutions.
Moreover, it also gathers elaborative details of every small
requirement
2. Risk Analysis (Risk Management)
In this phase of the spiral model for software development, the
developer term will identify all the potential risks that will arise
during the software development process.
After the developer is done with problem identification, the software
engineer will plan a list of strategies to mitigate the risks.
After the risk identification process, the developer team will release a
prototype, which will be a risk-free demographic version of the
software.
After the software engineering is done designing the software, they
will start coding, testing and the deployment process.
3. Engineering (Designing and Coding Phase)
This phase starts with designing the leading software by idolizing the
prototyped design from the baseline spiral. The prototype design will
be a guideline for software architecture, logic, front-end and final
design.
4. Evaluate (Review And Deployment)
After the launch of a software project on the client’s site, the client is
open to sharing feedback and insightful observations about the
software. All the correction lists will be sent to the development
team,
Again, a new baseline will begin to fix all the bugs, and after fixation
of all requirements, the final product will be ready for final launch.
Software prototyping
A prototype is a working model of one or more aspects of the
projected system.
It is constructed and tested quickly and inexpensively in order to test
out assumptions.
Prototypes can be classified as throw- away or evolutionary.
Throw- away prototypes:
The prototype tests out some ideas and is then discarded when thetrue
development of the operational system is commenced.
Evolutionary prototypes:
The prototype is developed and modified until it is finally in a state
where it can become the operational system.
Some reasons that have been put forward for prototyping follow:
1. Learning by doing
2. Improved communication
3. Improved user involvement.
4. Clarification of partially known requirements
5. Demonstration of the consistency and completeness of a
specification.
6. Reduced need for documentation
7. Reduced maintenance cost
8. Feature constraint: If an application building tool is used , then the
prototype will tend to have features that are easily implemented by
that tool.
9. Production of expected results
Drawbacks of software prototyping
1. User can misunderstand the role of the prototype
2. Lack of project standard possible.
3. Lack of control
4. Additional expense
5. Machine efficiency
6. Close proximity of developers
Incremental Delivery
This approach breaks the application down into small components which
are then implemented and delivered in sequence.
Each component delivered must give some benefit to the user.
Time-boxing is often associated with an incremental approach.
Here the scope of deliverables for an increment is rigidly constrained by an
agreed deadline.
This deadline has to be met ,even at the expense of dropping some of the
planned functionality.
Omitted features can be transferred to later increments
 Identify system objectives

Create open technology plan

Plan increments

Design increment

Build increment
Repeat for each Feedback

increment Implement the increment

Evaluate the results

Advantages of this approach
1. Feedback from early increments improves the later stages.
2. The possibility of changes in requirements is reduced because of
the shorter time span between the design of a component and its
delivery.
3. Users get benefit earlier than with a conventional approach.
4. Early delivery of some useful components improves cash flow,
because you get some return on investment early on
5. Smaller sub-projects are easier to control and manage.
6. Gold-plating i.e the requesting of features that are unnecessary and
not in fact used, is less as users know that if a feature is not in the
current increment then it can be included in the next
7. The project can be temporarily abandoned if more urgent work
emerges
8. Job satisfaction is increased for developers who see their labours
bearing fruit at regular, short intervals.
Disadvantages:
1. Later increments might require modifications to earlier increments,
this is known as software breakage.
2. Software developers may be more productive working on one large
system than on a series of smaller ones.
3. Grady Booch suggests that “ Conceptual integrity sometimes
suffers because there is little motivation to deal with scalability,
extensibility, portability or reusability beyond what any vague
requirements might imply.
He also suggests there could be tendency towards a large number of
discrete functions with little common infrastructure.
Atern / Dynamic Systems Development Method.
SSADM (Structured Systems Analysis and Design Method) has been
a predominant methodology.
A consortium has developed guidelines for the use of such techniques
and packaged the overall approach as the (DSDM) Dynamic Systems
Development Method this has been re-badged as Atern.
It is possible to attend courses on the method and to become an
accredited Atern practitioner.
8 core atern principles have been enunciated.
1. Focus on business need : Every decision in the development
process should be taken with a view to best satisfying business needs.

2. Delivery on time : Time-boxing is applied . Every deadline will see

the delivery of valuable products, even if some less valuable ones are
held over.
3. Collaborate : A one- team culture should be promoted, where user
representatives are integrated into the delivery team.
4. Never Compromise Quality : Realistic quality targets are set early
in the project.
5. Develop iteratively: prototyping approach should be used.
6. Build incrementally from firm foundations .
7. Communicate continuously
8. Demonstrate control
Atern methodology has a range of plans and reports that can be used
to communicate project intentions and outcomes to project sponsors
and other management stakeholders
Figure outlines the general approach . The main life cycle phases are as
shown below.
1. Feasibility/ foundation: Among the activities undertaken here is
derivation of a business case and general outlines of the proposed
architecture of the system to be developed.
2. Exploration Cycle :
This investigates the business requirements.
These requirements are translated into a viable design for the
application .
This could be an iterative process that could involve the creation of
exploratory prototypes.
A large project could be decomposed into smaller increments to assist
the design process.
3. Engineering Cycle: This takes the design generated in the
exploration cycle and converts it into usable components of the final
system that will be used operationally .
4. Deployment : This gets the application created in the engineering
cycle into actual operational use.
Atern encourages the use of time-boxes.
The relative importance of requirements can be categorized using the
MoSCoW classification.
 Must have : that is essential feature
 Should have : these would probably be mandatory if you were using
a conventional development approach. But the system can operate
without them.
 Could have: these requirements can be delayed with some
inconvenience.
 Won’t have : these features are wanted , but their delay to a later
increment is readily accepted.
The possibility of requirements being reallocated to different
increments means that project plans will need to be constantly updated
if the project is to be successfully controlled.
Software Effort Estimation
Introduction:
Effort estimation is a crucial aspect of project management, playing a
significant role in setting realistic timelines and allocating resources
efficiently. It involves predicting the amount of time and effort required to
complete a particular task or project.
Effort estimation is the process of forecasting how much effort is required
to develop or maintain a software application. This effort is traditionally
measured in the hours worked by a person, or the money needed to pay for
this work.
Effort estimation is used to help draft project plans and budgets in the early
stages of the software development life cycle.
Where are estimates done?
Estimates are carried out at different stages of a software project for a variety of
reasons.
 Feasibility study
Estimates here conforms that the benefits of the potential system will justify the
costs
 Strategic planning
Project portfolio management will involve:
 Estimating benefits and costs of new applications (projects) to allocate priorities.
 Such estimates may also influence the scale of development staff recruitment
System specification
 Design shows how user requirements will be fulfilled.
 Estimating The efforts needed to implement different design
proposals.
 Estimates at the design stage will also confirm that the feasibility
study is still valid.
Evaluation of suppliers proposals
 A manager could consider putting development to tender
 Potential contractors would examine the system specifications and
produce estimates (their bid).
 The manager can still produce his own estimates why?
 To question a bid that for instance that seems too low which could
be an indication of a bad understanding of the system specifications.
 Or to compare the bids to in-house development
 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 estimates
 And support more detailed planning (e.g. staff allocation)
Problems with Over and Under Estimates
An over-estimate is likely to cause project to take longer than it would
otherwise
 This can be explained by the application of two laws:
 Parkinson’s Law: ‘Work expands to fill the time available’
 Thus, e.g. for an easy task over estimating the duration required to
complete it will cause some staff to work less hard to fill the time.
 Brook’s Law: putting more people on a late job makes it later
 So overestimating the effort required to perform a task (activity) means
more staff assigned to it than needed
Underestimating a project: Can cause the project to not be delivered
on time or cost
 but still could be delivered faster than a more generous estimate
 On the other side the danger of underestimating a project is the
effect on the quality
 Zeroth law of reliability: if a system doesn't have to be reliable it
can meet any other objective
Basis for software estimating
A. The need for historical data.
 Most estimating methods need information about past projects
 Care has to be considered when applying past performance to new
projects because of possible differences in factors such as:
 Different programming languages
 Different experience of staff
 Different terminology There are international Data Base containing
data about thousands of projects that can be used as reference
B. Measuring work.
 The time and cost to implement software depends on:
 The developer’s capability and experience
 The technology that will be used
 The usual practice is to start by expressing work size independently of
the effort, using measures such as:
( a) S LOC OR KLOC: Source lines of code or thousands of lines of code
(b) Alternative size measure is Function Points (FP)
Software Effort estimation techniques.
Barry Boehm, in his classic work on software effort models,
identified the main ways of deriving estimates of software
development effort as:
 alogorithmic models, which use ‘effort drivers’ representing
characteristics of the target system and the implementation
environment to predict effort
 expert judgement based on the advice of knowledgeable staff.
 analogy, where a similar, completed , project is identified and its
actual effort is used as the basis of the estimate.
 Parkinson, where the staff effort available to do a project becomes
the estimate.
Price to win where the estimate is a figure that seems sufficiently low
to win a contract.
 top-down, where an overall estimate for the whole project is broken
down into the effort required for component tasks
 bottom-up ,where component task are identified and sized and these
individual estimates are aggregated
Bottom Up Estimating
It is the form of project estimating for cost, resource and duration.
Definition:
Estimate derived by first estimating the cost of the project’s elemental
tasks at the lower level of WBS and then aggregating those estimates
at successively higher levels.
The bottom up approach is best at the later, more detailed stages of
project planning. If this method is used earlier assumptions about the
characteristics of the final system and project work methods will have
to be made.