Docsity
Log inSign up
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search Store documents

The best documents sold by students who completed their studies

Search through all study resources
Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

University Rankings

Discover the best universities in your country according to Docsity users

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

From our blog

Exams and Study
Go to the blog

Pressman ch 23 estimation for software projects, Slides of Software Project Management

Krishna UniversitySoftware Project Management

Decomposition Techniques

Typology: Slides

2014/2015

Uploaded on 09/18/2015

suhasini_chunduru
suhasini_chunduru 🇮🇳

1 document

1 / 37

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Chapter 23
Estimation for Software Projects
- Project planning
- Scope and feasibility
- Project resources
- Estimation of project cost and effort
- Decomposition techniques
- Empirical estimation models
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25

Partial preview of the text

Download Pressman ch 23 estimation for software projects and more Slides Software Project Management in PDF only on Docsity!

Chapter 23

Estimation for Software Projects

  • (^) Project planning
  • (^) Scope and feasibility
  • (^) Project resources
  • (^) Estimation of project cost and effort
  • (^) Decomposition techniques
  • (^) Empirical estimation models (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

Project Planning

Observations on Estimation

  • (^) Planning requires technical managers and the software team to make

an initial commitment

  • (^) Process and project metrics can provide a historical perspective and

valuable input for generation of quantitative estimates

  • (^) Past experience can aid greatly
  • (^) Estimation carries inherent risk, and this risk leads to uncertainty
  • (^) The availability of historical information has a strong influence on

estimation risk

(More on next slide)

Observations on Estimation

(continued)

  • (^) When software metrics are available from past projects
    • (^) Estimates can be made with greater assurance
    • (^) Schedules can be established to avoid past difficulties
    • (^) Overall risk is reduced
  • (^) Estimation risk is measured by the degree of uncertainty in the quantitative

estimates for cost, schedule, and resources

  • (^) Nevertheless, a project manager should not become obsessive about

estimation

  • (^) Plans should be iterative and allow adjustments as time passes and more is made certain "It is the mark of an instructed mind to rest satisfied with the degree of precision that the nature of the subject admits, and not to seek exactness when only an approximation of the truth is possible." ARISTOTLE

Example Project: Campus

Information Access Kiosk

  • (^) Both podium-high and desk-high terminals located throughout the

campus in all classroom buildings, admin buildings, labs, and

dormitories

  • (^) Hand/Palm-login and logout (seamlessly)
  • (^) Voice input
  • (^) Optional audio/visual or just visual output
  • (^) Immediate access to all campus information plus
    • (^) E-mail
    • (^) Cell phone voice messaging
    • (^) Text messaging

Scope and Feasibility

Software Scope (continued)

  • (^) After the scope has been identified, two questions are asked
    • (^) Can we build software to meet this scope?
    • (^) Is the project feasible?
  • (^) Software engineers too often rush (or are pushed) past these questions
  • (^) Later they become mired in a project that is doomed from the onset

Feasibility

  • (^) After the scope is resolved, feasibility is addressed
  • (^) Software feasibility has four dimensions
    • (^) Technology – Is the project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs?
    • (^) Finance – Is is financially feasible? Can development be completed at a cost that the software organization, its client, or the market can afford?
    • (^) Time – Will the project's time-to-market beat the competition?
    • (^) Resources – Does the software organization have the resources needed to succeed in doing the project? Another view recommends the following feasibility dimensions: technological, economical, legal , operational , and schedule issues (TELOS)

Resource Estimation

  • (^) Three major categories of software engineering resources
    • (^) People
    • (^) Development environment
    • (^) Reusable software components
      • (^) Often neglected during planning but become a paramount concern during the construction phase of the software process
  • (^) Each resource is specified with
    • (^) A description of the resource
    • (^) A statement of availability
    • (^) The time when the resource will be required
    • (^) The duration of time that the resource will be applied Time window

14

Categories of Resources

People

  • (^) Number required
  • (^) Skills required
  • (^) Geographical location Development Environment
    • (^) Software tools
    • (^) Computer hardware
    • (^) Network resources Reusable Software Components
  • (^) Off-the-shelf components
  • (^) Full-experience components
  • (^) Partial-experience components
  • (^) New components

The

Project

Development Environment

Resources

  • (^) A software engineering environment (SEE) incorporates hardware,

software, and network resources that provide platforms and tools to

develop and test software work products

  • (^) Most software organizations have many projects that require access to

the SEE provided by the organization

  • (^) Planners must identify the time window required for hardware and

software and verify that these resources will be available

Reusable Software Resources

  • (^) Off-the-shelf components
    • (^) Components are from a third party or were developed for a previous project
    • (^) Ready to use; fully validated and documented; virtually no risk
  • (^) Full-experience components
    • (^) Components are similar to the software that needs to be built
    • (^) Software team has full experience in the application area of these components
    • (^) Modification of components will incur relatively low risk
  • (^) Partial-experience components
    • (^) Components are related somehow to the software that needs to be built but will require substantial modification
    • Software team has only limited experience in the application area of these components
    • (^) Modifications that are required have a fair degree of risk
  • (^) New components
    • (^) Components must be built from scratch by the software team specifically for the needs of the current project
    • (^) Software team has no practical experience in the application area
    • (^) Software development of components has a high degree of risk

Factors Affecting Project Estimation

  • (^) The accuracy of a software project estimate is predicated on
    • (^) The degree to which the planner has properly estimated the size (e.g., KLOC) of the product to be built
    • (^) The ability to translate the size estimate into human effort, calendar time, and money
    • (^) The degree to which the project plan reflects the abilities of the software team
    • (^) The stability of both the product requirements and the environment that supports the software engineering effort

Project Estimation Options

  • (^) Options for achieving reliable cost and effort estimates
    1. Delay estimation until late in the project (we should be able to achieve 100% accurate estimates after the project is complete)
    2. Base estimates on similar projects that have already been completed
    3. Use relatively simple decomposition techniques to generate project cost and effort estimates
    4. Use one or more empirical estimation models for software cost and effort estimation
  • (^) Option #1 is not practical, but results in good numbers
  • (^) Option #2 can work reasonably well, but it also relies on other

project influences being roughly equivalent

  • (^) Options #3 and #4 can be done in tandem to cross check each other