1 / 14

Software Engineering

Software Engineering. Software Project Planning. Objectives. To introduce project planning. To examine the stages of project planning: scoping, estimation, risk analysis and scheduling. To focus on the tools available to a project planner. Software Project Planning.

Download Presentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Engineering Software Project Planning

  2. Objectives • To introduce project planning. • To examine the stages of project planning: scoping, estimation, risk analysis and scheduling. • To focus on the tools available to a project planner.

  3. Software Project Planning • The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. • Must deal with: • Project complexity: has a strong effect but is heavily influenced by past practitioner experience. • Project size: as size increases the interdependency of elements also grows. Watch out for scope creep (when customers change requirements mid-cycle). • The degree of structural uncertainty: the degree to which requirements are solidified and the ease of functional decomposition. • The purpose of project planning is to ensure that the end result is completed on time, within budget, and exhibits quality!

  4. Steps in Project Planning • Scope—understand the problem and the work that must be done. • Estimation—how much effort? how much time? • Risk—what can go wrong? how can we avoid it? what can we do about it? • Schedule—how do we allocate resources along the timeline? what are the milestones? • Control strategy—how do we control quality? how do we control change? Project Scope Estimates Risks Schedule Control strategy Software Project Plan

  5. Scope • A bounded description of the data and control, function, performance, constraints, interfaces and reliability sufficient to determine project feasibility and create an initial plan. • Scoping Techniques: • Preliminary meeting or interview • FAST (Facilitated Application Specification Technique) • Understanding Scope: • customers needs • business context • project boundaries • customer’s motivation • likely paths for change • “Even when you understand, nothing is guaranteed!”

  6. Estimating Resources • Human Resources: • Select skills required (both position and specialty, e.g. database software engineer). Requires an effort estimate. • Reusable Software Resources: • Off-the-shelf components (existing software acquired from 3rd party with no modification required) • Full-experience components (previous project code is similar and team members have full experience in this application area) • Partial-experience components (existing project code is related but requires substantial modification and team has limited experience in the application area) • New components (must be built from scratch for this project) • Environmental Resources: • The hardware and software tools required to develop the project. Planner needs to provide a time window for booking these resources.

  7. Estimating Cost and Effort • Project scope must be explicitly defined. If not, the project may be infeasible. • Task and/or functional decomposition is necessary. • Historical measures (metrics) are very helpful. • Triangulation: At least two different techniques should be used. • Remember that uncertainty is inherent in early estimates. • Techniques: • Delay estimation until late in the project (not advisable) • Base estimates on similar projects that have already been completed. • Use relatively simple decomposition techniques (LOC or FP). • Use one or more empirical models for software cost.

  8. Example: CAD Software • Statement of Software Scope: • The CAD software will accept 2D and 3D geometric data from an engineer through a user interface that exhibits good HCI. All geometric data will be maintained in a database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will interact with peripheral devices including a mouse, digitizer, laser printer and plotter. • Functional Decomposition: • User interface and control facilities (UICF) • Two-dimensional geometric analysis (2DGA) • Three-dimensional geometric analysis (3DGA) • Database management (DBM) • Computer graphics display facilities (CGDF) • Peripheral control function (PCF) • Design analysis modules (DAM)

  9. Example: LOC • Three LOC estimates (optimistic , most likely , pessimistic ) are developed for each function. • Each final function estimate is: • Use historical data for projects of this type (LOC/pm and R/LOC) to obtain effort and cost estimates. • Example: • avg. productivity = 620 LOC/pm (pm = person month). Based on burdened labour rate of R8000 pm, avg. cost = 13 R/LOC. • Total estimated project cost = R431000. Total estimated effort = 54 person months.

  10. Example: FP • Similarly, FP estimates can be derived. • Unlike LOC, concentrate on information domain rather than software functions. • Useful as a triangulating measure. • Example: • avg. productivity for systems of this type = 6.5 FP/pm. Based on a burdened labour rate of R8000, R/FP = R1230. • Total estimated cost = R461000, total estimated effort = 58 pm.

  11. Process-Based Estimation • The SE Process is decomposed into a small set of tasks and cross referenced against the functions. Planner estimates the effort (in person months) required to accomplish each task for a particular function. • Creating a task matrix: framework activities application functions Effort required to accomplish each framework activity for each application function

  12. Example: Process-Based Estimation CC = customer communication, CE = customer evaluation

  13. Empirical Estimation Models • Use empirically derived formulae to predict effort as a function of LOC or FP. Do not need your own historical data. • Structure: • where A, B, C are empirical constants, E is effort in person months and ev is the estimation variable (LOC or FP). • Some Examples: • These models yield different results. Estimation models must be calibrated for specific applications. Best if they have been sourced from many projects.

  14. Triangulating • Do not expect that all estimates will agree within a percent or two. If estimates are within a twenty percent band, they can be reconciled into a single figure. • But, if agreement between estimates is poor: • The scope of the project is not adequately understood or has been misunderstood by the planner. • Productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete or has been misapplied. • Planner must determine the cause of deviation and then reconcile the estimates.

More Related