Evaluation of Individual Projects

Software project mgnt
module 2
Evaluation of individual projects
A high level assessment of the project
to see whether it is worthwhile to proceed with the project
to see whether the project will fit in the strategic planning of the whole organization
Project Evaluation What
Strategic assessment
Technical assessment
Economic assessment
Project Evaluation How
Cost-benefit analysis
Cash flow forecasting
Cost-benefit evaluation techniques
Risk analysis
Strategic Assessment
Used to assess whether a project fits in the long-term goal of the organization
Usually carried out by senior management
Needs a strategic plan that clearly defines the objectives of the organization
Evaluates individual projects against the strategic plan or the overall business objectives
Programme management
suitable for projects developed for use in the organization
Portfolio management
suitable for project developed for other companies by software houses
Technical Assessment
Functionality against hardware and software
The strategic IS plan of the organization
any constraints imposed by the IS plan
module 2
Economic Assessment
Why?
Consider whether the project is the best among other options
Prioritise the projects so that the resources can be allocated effectively if several projects are
underway
How?
Cost-benefit analysis
Cash flow forecasting
Various cost-benefit evaluation techniques
NPV and IRR
EA Cost-benefit Analysis
A standard way to assess the economic benefits
Two steps
Identify and estimate all the costs and benefits of carrying out the project
Express the costs and benefits in a common unit for easy comparison (e.g. $)
Cost-Benefit Evaluation Techniques
Return on investment (ROI)
or Accounting rate of return (ARR)
Compares investment required with net profitability
ROI= average annual profit / total investment x 100
ROI for project 1 = 10,000 / 100,000 x 100 = 10%
module 2
ROI is Project 1 = 10% Project 2 = 2%

Project 3 = 10%
Project 4 = 12.5%
Cost-benefit Evaluation Techniques NPV

Net present value (NPV)
It is the sum of the present values of all future amounts.
Present value is the value which a future amount is worth at present
It takes into account the profitability of a project and the timing of the cash flows
Discount rate is the annual rate by which we discount future earning
e.g. If discount rate is 10% and the return of an investment in a year is $110, the present
value of the investment is $100.
module 2
Let n be the number of year and r be the discount rate, the present value (PV) is given by
PV
value in year n
(1 r ) n
Discount factor
Discount factor = 1/(1+r)t
r is the interest rate (e.g. 10% is 0.10)
t is the number of years
In the case of 10% rate and one year
Discount factor = 1/(1+0.10) = 0.9091
In the case of 10% rate and two years
Discount factor = 1/(1.10 x 1.10) =0.8294
Applying discount factors
Year
Cash-flow
Discount factor
Discounted cash flow
-100,000
1.0000
-100,000
10,000
0.9091
9,091
10,000
0.8264
8,264
10,000
0.7513
7,513
20,000
0.6830
13,660
100,000
0.6209
62,090
NPV
618
Cost-Benefit Evaluation Techniques
Return on investment (ROI)

4
module 2
or Accounting rate of return (ARR)
Compares investment required with net profitability
ROI= average annual profit / total investment x 100
ROI for project 1 = 10,000 / 100,000 x 100 = 10%
Net profit + payback period + ROI
ROI is
Project 1 = 10% Project 2 = 2%

Project 3 = 10%
Project 4 = 12.5%
Selection of an appropriate project approach

Choosing methodologies and technologies
module 2
Methodology describes a collection of methods.
Techniques tend to involve the application of scientific, mathematical or logical principles to

resolve a particular kind of problem.
Methods and technologies will affect:
the training requirements for development staff
the types of staff to be recruited;
the development environment - both hardware and software;
system maintenance arrangements.
Choice of process models
"The word 'process' emphasizes the idea of a system in action.
In order to achieve an outcome, the system will have to execute one or more activities: this is its
process.
A number of interrelated activities have to be undertaken to create a final software product. These
activities can be organized in different ways and we can call these as process models.
The planner selects methods and specifies how they are to be applied.
By changing the process model, we can improve and/or tradeoff:

Development speed (time to market)
Product quality
Project visibility
Administrative overhead
Risk exposure
Customer relations, etc.
The Waterfall Model
The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential
approach to software development .
In Waterfall model, typically, the outcome of one phase acts as the input for the next phase
sequentially.
module 2
Used when requirements for a problem are well understoodwhen work flows from
communication through deployment in a reasonably linear fashion.
The sequential phases in Waterfall model are:
Requirement Gathering and analysis: All possible requirements of the system to be developed
are captured in this phase and documented in a requirement specification doc.
System Design: The requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and system requirements
and also helps in defining overall system architecture.
Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and tested
for its functionality which is referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are integrated into
a system after testing of each unit. Post integration the entire system is tested for any faults and
failures.
Deployment of system: Once the functional and non functional testing is done, the product is
deployed in the customer environment or released into the market.
Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are:
Requirements are very well documented, clear and fixed.

7
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.
module 2
Pros
Simple and easy to understand and use
Easy to manage due to the rigidity of the model .
Each phase has specific deliverables and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.
Cons
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Cannot accommodate changing requirements.
The Vmodel-Variation in the representation of WFM
module 2
Depicts the relationship of assurance actions to the actions associated with communication,
modeling, and early construction activities.
As a software team moves down the left side of the V, basic problem requirements are refined
into progressively more detailed and technical representations of the problem and its solution.
Once code has been generated, the team moves up the right side of the V, essentially performing
a series of tests (quality assurance actions) that validate each of the models created .
In reality, there is no fundamental difference between the classic life cycle and the V-model.
The V-model provides a way of visualizing how verification and validation actions are applied to
earlier engineering work.
Incremental Process Models
Combines elements of the waterfall model applied in an iterative fashion
Each linear sequence produces deliverable increments of the software
The first increment is often a core product
That is, basic requirements are addressed but many supplementary features (some known, others
unknown) remain undelivered.
The core product is used by the customer (or undergoes detailed evaluation)
Based on evaluation results, a plan is developed for the next increment
The plan addresses the modification of the core product to better meet the needs of the customer
and the delivery of additional features and functionality.
module 2
This process is repeated following the delivery of each increment, until the complete product is
produced.
The incremental process model focuses on the delivery of an operational product with each
increment.
Early increments are stripped-down versions of the final product, but they do provide capability
that serves the user and also provide a platform for evaluation by the user
The incremental process model, like prototyping and other evolutionary approaches, is iterative in
nature
But unlike prototyping, the incremental model focuses on the delivery of an operational product
with each increment
Particularly useful when

Staffing is unavailable
Advantages of Incremental model:

Generates working software quickly and early during the software life cycle.
This model is more flexible less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
Lowers initial delivery cost.
Disadvantages of Incremental model:

`Needs good planning and design.
10
module 2
Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
Spiral Model
Proposed by Barry Boehm .
SM is an evolutionary software process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the waterfall model.
It provides the potential for rapid development of increasingly more complete versions of the
software.
Using the spiral model, software is developed in a series of evolutionary releases.
During early iterations, the release might be a model or prototype.
During later iterations, increasingly more complete versions of the engineered system are
produced.
A spiral model is divided into a set of framework activities defined by the software engineering
team.
Each of the framework activities represent one segment of the spiral path.
As this evolutionary process begins, the software team performs activities that are implied by a
circuit around the spiral in a clockwise direction, beginning at the center.
11
module 2
The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the software.
Each pass through the planning region results in adjustments to the project plan.
Cost and schedule are adjusted based on feedback derived from the customer after delivery.
In addition, the project manager adjusts the planned number of iterations required to complete the
software.
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.
Projects success is highly dependent on the risk analysis phase.
When to use Spiral model:
When costs and risk evaluation is important
For medium to high-risk projects
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)
Prototyping
PROTOTYPE -An early approximation of a final system or product
Works best in scenarios where not all of the project requirements are known in detail ahead of
time.
12
module 2
An iterative, trial-and-error process that takes place between the developers and the users.
Evolutionary prototyping
An approach to system development where an initial prototype is produced and
refined through a number of stages to the final system
Throw-away prototyping
A model of the system is produced to help client and then discarded. The system
is then developed using some other development process
The prototyping paradigm begins with communication where requirements and goals of Software
are defined.
Prototyping iteration is planned quickly and modeling in the form of quick design occurs.
The quick design focuses on a representation of those aspects of the Software that will be visible
to the customer Human interface.
The quick design leads to the Construction of the Prototype.
The prototype is deployed and then evaluated by the customer.
Feedback is used to refine requirements for the Software.
Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while enabling the
developer to better understand what needs to be done.
Controlling Changes During Prototyping
A major problem with prototyping is controlling changes to the prototype following suggestions
by the users.
One approach has been to categorize changes as belonging to one of three types:
13
module 2
Cosmetic (about 35% of changes)

Local (about 60% of changes)
Global (about 5% of changes)
Cosmetic (about 35% of changes)

These are simply changes to the layout of the screen.
They are:
(a) Implemented.
(b) Recorded.
Local (about 60% of changes)

These involve changes to the way the screen is processed but do not affect other parts of
the system.
They are:
(a) Implemented.
(b) Recorded.
(c) Backed-up so that they can be removed at a later stage if necessary.
(d) Inspected retrospectively.
Global (about 5% of changes)

These are changes that affect more than one part of the processing.
All changes here have to be the subject of a design review before they can be
implemented.
Other ways to categorizing prototypes
What is being learnt?
The most important reason for prototyping is a need to learn about an area of uncertainty.
Thus it is essential to identify at the outset what is to be learnt from the prototype.
When using this model,

specify what they hope to learn from the prototype;
plan how the prototype is to be evaluated;
14
module 2
report on what has actually been learnt.
Different projects will have uncertainties at different stages.
Prototypes can therefore be used at different stages.
A prototype might be used, for instance, at the requirements gathering stage to pin down
requirements that seem blurred and shifting.
A prototype might, on the other hand, be used at the design stage to test out the users' ability to
navigate through a sequence of input screens.
To what extent is the prototyping to be done?
It would be unusual for the whole of the application to be prototyped.
The prototyping usually simulates only some aspects of the target application.
For example there might be:

Mock-ups :As when copies of input screens are shown to the users on a terminal, but the
screens cannot actually be used.
Simulated interaction :For example, the user can type in a request to access a record and
the system will show the details of a record, but the details shown are always the same
and no access is made to a database.
Partial working model:
Vertical Some, but not all, features are prototyped fully.
Horizontal All features are prototyped but not in detail - perhaps there is not full
validation of input.
What is being prototyped?
The human-computer interface :

With business applications, business process requirements have usually been
established at an early stage.
Prototyping tends, therefore, to be confined to the nature of operator interaction.
The functionality of the system :

Here the precise way the system should function internally is not known.
For example, a computer model of some real-world phenomenon is being
developed.
15
module 2
The algorithms used might need to be repeatedly adjusted until they satisfactorily
imitate real-world behaviour.
Agile Methods
Atern (formerly DSDM)
Extreme Programming (XP)
Scrum
Atern/ Dynamic Systems Development Method
DSDM (Dynamic Systems Development Method) is a robust Agile project management and
delivery framework that delivers the right solution at the right time.
Atern is an agile project delivery framework that delivers the right solution at the right time.
The right business solution is delivered because:

The project team and other significant stakeholders remain focused on the business
outcome
All people involved with the project work collaboratively to deliver the optimum solution
Work is prioritized according to business need and the ability of users to accommodate
changes in the agreed timescale
Atern does not compromise on quality, i.e. the solution is not over- or under-engineered
Importantly, Atern harnesses the knowledge, experience and creativity of end users.
Atern principles
Aterns eight Principles are:

1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control
16
module 2
Focus on business need.

1. Every decision in the development process should be taken with a view to best satisfying
business needs
Deliver on time
1. Delivering products on time is a very desirable outcome for a project and is quite often
the single most important success factor.
2. In order to fulfill this principle, Atern teams will:
Timebox the work (Roles are clearly defined and work is divided into Timeboxes
with immoveable deadlines and agreed outcomes.)
Focus on business priorities
Always hit deadlines
Collaborate
Teams that work in a spirit of active cooperation and commitment will always outperform groups
of individuals working only in loose association.
In order to fulfil this principle, Atern teams will:

1. Involve the right stakeholders, at the right time, throughout the project
2. Ensure that the members of the team are empowered to take decisions on behalf of those
they represent
3. Actively involve the business representatives
4. Build a one-team culture
Never compromise quality
In Atern, the level of quality to be delivered should be agreed at the start.
All work should be aimed at achieving that level of quality.-No more and no less.
In order to fulfill this principle, Atern teams will:

1. Set the level of quality at the outset
2. Ensure that quality does not become a variable
3. Design, document and test appropriately
4. Test early and continuously
17
module 2
Build incrementally from firm foundations

1. In order to deliver real business benefit early, Atern advocates incremental delivery.
2. This encourages stakeholder confidence and is a source of feedback for use in subsequent
increments.
3. Increments which are deployed into operational use may lead to the realization of early
business benefit.
Develop Iteratively
In order to converge on an accurate business solution Atern uses iterative development to deliver
the right solution.

1. Do enough design up front to create strong foundations
2. Take an iterative approach to building all products
3. Build customer feedback into each iteration
Communicate continuously and clearly
Poor communication is often cited as the biggest single cause of project failure.
Atern techniques are specifically designed to improve communication effectiveness for both
teams and individuals

1. Run daily team stand-up sessions
2. Use rich communication techniques such as modelling and prototyping
3. Encourage informal, face-to-face communication at all levels
Demonstrate control
It is essential to be in control of a project at all times.
In order to fulfill this principle, Atern teams, especially the Project Manager and Team Leader,
will:
Use an appropriate level of formality for tracking and reporting
Make plans and progress visible to all
Measure progress through focus on delivery of products rather than completed activities
18
module 2
The relative importance of requirements can be categorized using the 'MoSCoW classification:
Must have: that is, essential features.
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.
DSDM/Atern Lifecycle
The Atern lifecycle is both iterative and incremental
The project process has five phases:

Feasibility,
Foundations,
Exploration, Engineering
And Deployment
These are preceded by the Pre-Project phase and followed by the Post-Project phase.
Pre-project:
Initiation of the project, agreeing the Terms of Reference for the work
The work of the pre-project phase simply formalises a proposal for a project
Objectives
19
module 2
To describe the business problem to be addressed.

To identify a Business Sponsor and Business Visionary.
To confirm that the project is in line with business strategy.
To scope, plan and resource the Feasibility phase.
Feasibility:
Typically a short phase to assess the viability and the outline business case (justification).
Used,
To identify the benefits likely to arise from the delivery of the proposed solution.
To describe the organization and governance aspects of the project.
To state first-cut estimates of timescale and costs for the project overall.
To plan and resource the Foundations phase.
Foundations:
The Foundations phase is aimed at establishing firm and enduring foundations for the
project.
Used,
To identify information used, created and updated by the proposed solution.
To describe the strategies for all aspects of solution deployment.
To detail the Business Case for the project
To start designing the solution architecture and identifying the physical or

infrastructural elements of the solution.
To define technical implementation standards.
To describe how quality will be assured.
Exploration:
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.
20
module 2
Engineering:
The Engineering phase is used iteratively and incrementally to evolve the preliminary
solution.
This takes the design generated in the exploration cycle and converts it into usable
components of the final system that will be used operationally.
Deployment:
The primary purpose of the Deployment phase is to get the solution into live use.
For each Increment (set of timeboxes) of the project the solution is made available.
Where applicable, to train the end users of the solution and/or provide necessary
documentation to support the live operation of the solution in the business environment.
Post project:
The Post-Project phase takes place after the last planned deployment of the solution.
Assesses the accrued benefits.
Extreme Programming (XP)
The most widely used approach to agile software development.
Extreme Programming (XP) was conceived and developed by Kent Beck to address the specific
needs of software development conducted by small teams.
Extreme Programming nominates coding as the key activity.
The programmer is the heart of XP.
The approach is called 'extreme programming' because, according to Beck, 'XP takes
commonsense principles to extreme levels'.
Five core values are presented as the foundations of XP.
Communication.
Feedback.
Simplicity.
Respect.
Courage.
Communication
21
Is argued that the best method of communication is face-to-face communication.
module 2
Use simple designs and common metaphors
Formal documentation is avoided.
Feedback.
From the system: Unit tests
From the customer: Acceptance tests
From the team: Estimate the time to implement new requirements
Simplicity.
XP restricts developers to design only for immediate needs, rather than consider future
needs
The simplest design that implements the users' requirements should always be adopted.
Extreme Programming encourages starting with the simplest solution and refactoring to
better ones.
Respect
The respect value includes respect for others as well as self-respect.
Members respect their own work by always striving for high quality and seeking for the
best design for the solution at hand through refactoring.
Adopting the four earlier values leads to respect gained from others in the team.
Nobody on the team should feel unappreciated or ignored.
Courage.
This is the courage to throw away work in which you have already invested a lot of effort, and to
start with a fresh design if that is what is called for.
It is also the courage to try out new ideas
The courage to communicate and accept feedback
The courage to throw code away (prototypes)
The courage to refactor the architecture of a system
Twelve XP Practices
XP Practices
22
The Planning Game
Small Releases
Metaphor
Simple Design
Test-driven development
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-Hours a Week
On-Site Customer
Coding Standards
module 2
The Planning Game/exercise
Customer comes up with a list of desired features for the system
Each feature is written out as a user story

Describes in broad strokes what the feature requires
Typically written in 2-3 sentences on 4x6 story cards
Developers estimate how much effort each story will take, and how much effort the team can
produce in a given time interval (iteration)
Development proceeds in very short iterations, typically 1-2 weeks in duration.
Stories are estimated by developers and then chosen by stakeholders based on their estimated
cost and business value.
Small and simple
Small releases
Start with the smallest useful feature set
Release early and often, adding a few features each time
Releases should take a month or two.
23
module 2
Simple design
Always use the simplest possible design that gets the job done
The requirements will change tomorrow, so only do what's needed to meet today's
requirements
Metaphor
Names within code and other work artifacts are chosen to be indicative of the system
being created.
A payroll application will calculate and record payments to employees.
The terms used to describe the corresponding software elements should, as far as
possible, reflect real-world terminology
Test-driven development
Test first: before adding a feature, write a test for it!
When the complete test suite passes 100%, the feature is accepted
Tests come in two basic flavors
Unit Tests
Each unit test typically tests only a single class, or a small cluster of classes
Acceptance Tests (or Functional Tests) are specified by the customer to test that the overall
system is functioning as specified
When all the acceptance tests pass, that user story is considered complete
Pair programming
Two programmers work together at one machine
Driver enters code, while navigator critiques it
Periodically switch roles
Research results:
Pair programming increases productivity
Higher quality code
More XP practices
Refactoring-restructuring existing code

24
module 2
Refactor out any duplicate code generated in a coding session

Code, and other work artifacts, are continuously reviewed and kept as clean as possible.
It is not sufficient that code works; it must also be clean.
Collective code ownership

No single person "owns" a module
The team as a whole take collective responsibility for the code in the system.
A unit of code does not 'belong' to just one programmer
Any developer can work on any part of the code base at any time
Continuous integration
This is another aspect of testing practice.
As changes are made to software units, integrated tests are run regularly - at least once a
day - to ensure that all the components work together correctly.
40-hour work week

Programmers go home on time
In crunch mode, up to one week of overtime is allowed
More than that and theres something wrong with the process
On-site customer
Fast and effective communication with the users is achieved by having a user domain
expert on-site with the developers.
Coding standards
Everyone codes to the same standards
If code is genuinely to be shared, then there must be common, accepted, coding standards
to support the understanding and ease of modification of the code.
Advantages/Disadvantages
ADVANTAGES
The focus on small, incremental release decreases the risk on your project:
by showing that your approach works and
25
module 2
by putting functionality in the hands of your users, enabling them to provide timely
feedback regarding your work.
Continuous testing and integration helps to increase the quality of your work
XP is attractive to programmers who normally are unwilling to adopt a software process, enabling
your organization to manage its software efforts better.
DISADVANTAGES
XP is geared toward a single project, developed and maintained by a single team.
XP is particularly vulnerable to developers who:

don't work well with others
who think they know it all, and/or
who are not willing to share their "superior code
XP will not work in an environment where a customer or manager insists on a complete

specification or design before they begin programming.
XP will not work in an environment where programmers are separated geographically.
XP has not been proven to work with systems that have scalability issues (new applications must
integrate into existing systems).
26

Evaluation of Individual Projects

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Evaluation of Individual Projects

Transféré par

Droits d'auteur :

Formats disponibles

Software project mgnt