You are on page 1of 56

SOFTWARE ENGINEERING AND PROJECT MANAGEMENT

UNIT-II

PROJECT MANAGEMENT
Project management is a carefully planned and organized effort to accomplish a specific (and usually) one-time objective, for example, construct a building or implement a major new computer system.

Project management includes developing a project plan, which includes defining and confirming the project goals and objectives, identifying tasks and how goals will be achieved, quantifying the resources needed, and determining budgets and timelines for completion.

SOFTWARE MEASUREMENT
There are two types: Direct Measures and Indirect Measures. Direct Measures of the software engineering process include cost and effort applied. Direct measures of the product include lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time. Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other "-abilities". The quality and functionality of software or its efficiency or maintainability are more

Organizing . Controlling . 4. They relate to the four functions of management as follows: 1.Metrics serve as a basis of cost estimating. 3.Metrics are used as a tool for process improvement and to identify where improvement efforts should be concentrated and measure the effects of process . scheduling. Planning . resource planning.Size and schedule metrics influence a project's organization. training planning. and budgeting. Improving .SOFTWARE METRICS Metrics strongly support software project management activities.Metrics are used to status and track software development activities for compliance to plans. 2.

. . Examples of Private Metrics: 1) Defect rates by Individual 2) Defect rates by Module 3) Errors found during development Public Metrics assimilate information that originally was private to individuals and teams. Hence Private metrics are used to measure the efficiency of an individual.PRIVATE AND PUBLIC METRIC It is natural that individual software engineers might be sensitive to the use of metrics collected on an individual and serve as an indicator for the individual only. Project level defect rates (absolutely not attributed to an individual). calendar times. effort. and related data are collected and evaluated in an attempt to uncover indicators that can improve organizational process performance.

Identify Metrics Customers Who needs the information? Who’s going to use the metrics? If the metric does not have a customer -do not use it.Step 1 . .

Target Goals Organizational goals  Be the low cost provider  Meet projected revenue targets Project goals – Deliver the product by June 1st – Finish the project within budget Task goals (entry & exit criteria) – Effectively inspect software module ABC – Obtain 100% statement coverage during testing .Step 2 .

    Project manager: our estimated project schedules always end up being way off. Functional manager: if we have another late delivery. Engineer: too much overtime -. finishing the project within budget or delivering software with the required level of quality or performance.Frustrations Goals Target Goals: These goals typically reflect the project success factors like on time delivery...not enough time to do things right Test manager: no time left to test product before it is scheduled to ship .

Step 3 .Ask Questions Goal: Maintain a high level of customer satisfaction   What is our current level of customer satisfaction? What attributes of our products and services are most important to our customers? How do we compare with our competition?  .

Turning Questions into Lower Level Goals High level goal: • Ship only defect free software Is software adequately tested? How many defects are still undetected? Are all known defects corrected? Ensure all known defects are corrected before shipment Questions: • • • Lower level goal: • .

Select Metrics Select metrics that provide information to help answer the questions    Be practical. realistic.Step 4 . pragmatic Consider current engineering environment Start with the possible Metrics don’t solve problems -.people solve problems Metrics provide information so people can make better decisions .

Products & Services Evaluate Predict .Role of Measurement Understand Control Processes.

Metric: % defects corrected % defects found & To evaluate the corrected during testing ensure all known defects in order are corrected to before shipment .Metrics Objective Statement Template understand attribute evaluate in order of the To the goal(s) control to entity predict Example .

Benefits Clearly defined metric objectives:  Ensures a well defined metric based on customer goals Eliminates misunderstandings Communicates need Provides requirements statement    .

Step 5 .Standardize Definitions Developer User .

Standardize Definitions Select definitions from the literature that match your organizational goals  Use them as a basis for creating your own definitions Apply them consistently Include them in an appendix to each metrics report   .

Choose a Model Models for code inspection metrics • Metric Primitive Models: – – – – Lines of Code Inspected = loc Hours Spent Preparing = prep_hrs Hours Spent Inspecting = in_hrs Discovered Defects = defects • Other Metric Models: – – – Preparation Rate = loc / prep_hrs Inspection Rate = loc / in_hrs Defect Detection Rate = defects / (prep_hrs + in_hrs) .Step 6 .

Keep It Simple If you are miles away from your target -.it doesn’t make sense to measure in millimeters. Questions:  Does it give us more information than we have now?  Is that information of practical benefit?  Does it tell us what we want to know? .

check sheets for criteria Advice: use a tool .Step 7 .Establish Counting Criteria Lines of Code • • • • Variations in counting No industry accepted standard SEI guideline .

Effort What is a Software Project? • When does it start / stop? • What activities does it include? • Who works on it? .Counting Criteria .

. cost.Step 8 .Decide On Decision Criteria Establish Baselines • Current value – – Problem report backlog Defect prone modules • Statistical analysis (mean & distribution) – – – – Defect density Fix response time Cycle time Variance from budget (e. schedule) .g.

Establishing Goals Deciding “what’s good”  Customer requirements  Metrics literature  Benchmarking  Own best results Avoid the roller coaster effect .

Step 9 .Define Reporting Mechanisms 100 Open Jan-97 Feb-97 Mar-97 Apr-97 160 120 Fixed 23 27 18 12 Resolved 13 3 24 11 26 15 18 27 100 80 60 40 20 0 Jan 80 60 40 20 0 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr 80 40 Mar May July 0 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr 120 80 40 0 0 20 40 60 80 100 120 1 2 3 4 5 6 7 8 9 10 11 12 .

Metrics Reporting  Timing Metrics Database Data Extraction Data Snapshot 1 2 3 4 5 6 7 8 9 10 11 12 Data Reporting • Delivery – Mechanism – Distribution – Availability .

Step 10 .Determine Additional Qualifiers A good metric is a generic metric Additional qualifiers:  Provide demographic information   Allow detailed analysis at multiple levels Define additional data requirements .

Additional Qualifier Example Metric: software defect arrival rate   Release / product / product line Module / program / subsystem     Reporting customer / customer group Root cause Phase found / phase introduced Severity .

Step 11 – Collect Data What data to collect? • • Metric primitives Additional qualifiers Who should collect the data? • The data owner – – – – Direct access to source of data Responsible for generating data Owners more likely to detect anomalies Eliminates double data entry .

Examples of Data Ownership Owner • Management Examples of Data Owned • Schedule • Budget • Engineers • Time spent per task • Inspection data including defects found • Root cause of defects • Testers • Test Cases planned / executed / passed • Problems • Test coverage • Configuration management • Lines of code specialists • Modules changed • Users • Problems • Operation hours .

  How measures affect people How people affect measures “Don’t underestimate the intelligence of your engineers.Step 12 – Consider Human Factors The People Side of the Metrics Equation.” [author unknown] . they will find at least two ways to beat it. For any one metric you can come up with.

Don’t Measure individuals Use metrics as a “stick” Use only one metric Quality Cost Schedule Ignore the data .

Do Select metrics based on goals Goal 1 Goal 2 Question 1 Question 2 Question 3 Question 4 [Basili-88] Metrics 1 Metric 2 Metric 3 Metric 4 Metric 5 Provide feedback Data Data Providers Feedback Metrics Processes. products & services . Products & Services Obtain “buy-in” Focus on processes.

Identify Metrics Customers Step 2 .Decide On Decision Criteria Step 9 .Target Goals Step 3 .12 Steps to Useful Software Metrics Step 1 .Select Metrics Step 5 .Define Reporting Mechanisms Step 10 .Determine Additional Qualifiers Step 11 .Ask Questions Step 4 .Establish Counting Criteria Step 8 .Choose a Model Step 7 .Collect Data Step 12 .Consider Human Factors .Standardize Definitions Step 6 .

planned durations Provides visibility into the contributions of Actual vs. planned staffing Effort staffing on project costs. planned costs Cost estimated costs and predicts future costs. planned task Provides information on how well the project is Progress completions performing with respect to its schedule. etc. Status of trouble reports Provides insight into product and process quality Number of trouble reports Trouble Reports and the effectiveness of the testing. during reporting period . closed. Actual vs. opened. Provides tracking of actual costs against Actual vs. Cost and schedule variances Provides status of action items from life-cycle Review Results Status of action items review.Metrics Set Recommended Metrics Set for a Project Indicator Category Management Insight Indicators Actual vs. profiles and product quality. schedule adherence.

planned number of personnel attending classes . Provides information on how well the Computer Resource project is meeting its computer resource Utilization utilization goals/requirements. planned profiles of computer resource utilization Actual vs. Provides information on the training Training program and staff skills. Actual vs.Metrics Set Recommended Metrics Set for a Project Indicator Category Requirements Stability Management Insight Provides visibility into the magnitude and impact of requirements changes. Indicators Number of requirements changes/clarifications Distribution of requirements over releases Size growth Distribution of size over releases Provides insight into the completeness and stability of the requirements and into the Size Stability ability of the staff to complete the project within the current budget and schedule.

This enables the engineer to discover and correct potential problems before they become catastrophic defects. these are concerned with the structure of the source code. Generally. rather than after – the – fact insight. They also provide the software engineer with on-the –spot. .PRODUCT METRIC Product metrics are metrics that can be calculated from the document independent of how it was produced.

System Size: Measures of the overall size of the system defined in terms of information available as part of the analysis model. the following outline addresses the most important metrics areas: Metrics for the Analysis Model: These metrics address various aspects of the analysis model and include: Functionality delivered: Provides an indirect measure of the functionality that is packaged within the software. Specification quality: Provide an indication of the specificity and completeness of a requirements .PRODUCT METRIC LANDSCAPE Although wide variety o f metrics taxonomies have been propose.

Metrics include: Architectural Metrics: Provide an indication of the quality of the architectural design.PRODUCT METRIC LANDSCAPE Metrics for the Design Model: These metrics quality design attributes in a manner that allows a software engineer to assess design quality. Specialized OO design Metrics: Measure characteristics o classes and their communication and collaboration characteristics. Interface Design Metrics: Focus primarily on usability. . Component-level Metrics: Measure the complexity of software components and other characteristics that have a hearing on quality.

PRODUCT METRIC LANDSCAPE Metrics for Source Code: These metrics measure the source code and can be used to assess its complexity. Complexity Metrics: Measures the logical complexity of source code. . maintainability and testability among other characteristics: Halstead metrics: controversial but nonetheless fascinating. these metrics provide unique measures of a computer program. Length Metrics: Provide an indication of the size of the software.

Statement and branch coverage metrics: Lead to the design of test cases that provide program coverage.PRODUCT METRIC LANDSCAPE Metrics for testing: These metrics assist in the design of effective test cases that provide program coverage. Testing Effectiveness: Provide a real-time indication o f the effective of tests that have been In-process Metrics: Process related metrics that can be determined as testing is conducted. Defect-related Metric: Focus on bugs found. rather than on the tests themselves. .

FUNCTION POINT– BASED METRICS: The function point metric can be used to Estimate the cost or effort required to design code and test the software.  . Size is sometimes an indicator of design complexity and is almost always an indicator of increased coding.  Predict the number of errors that will be en-countered during testing.METRICS FOR THE ANALYSIS MODEL These metrics examine the analysis model with the intent of predicting the size of the resultant system. integration and testing effort. and  Forecast the number of components and /or the number of projected source lines in the implemented system.

METRICS FOR THE ANALYSIS MODEL. Information domain values are defined in the following manner. Weighted factor Information Domain Value Count Simple Average Complex = Number of External Inputs (EIs). Number of External Outputs(E0s) Number of External inquiries: (Eqs) Number of internal logical files(ILFs) Number of external interface files(EIFs) x x x x x = = = = = . Function points are derived using an empirical relationship based on countable measures of software’s information domain and assessments of software complexity.

the following relationship is used: FP=count total x [0.01 x (Fi)] Where count total is the sum of all FP entries obtained from table given earlier. To compute the function of FP.METRICS FOR THE ANALYSIS MODEL.65 + 0. . The Fi (i= 1 to 14) are value adjustment factors (VAF) based on responses to the following questions.

Are specialized data communication s required to transfer information to or from the application? 3.METRICS FOR THE ANALYSIS MODEL.Is the code designed to be reusable? 12. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. Are the inputs. files or inquiries complex? 10.Is the internal processing complex? 11. . Are the ILFs updated on –line? 9. Will the system run in an existing. heavily utilized operational environment? 6.Is the application designed to facilitate change and for ease of use by the user? 1. Does the system require on-line data entry? 7.Is the system designed for multiple installations in different organizations? 14. outputs. Is performance critical? 5.Are conversion and installation included in the design? 13. Does the system require reliable backup and recovery? 2. Are there distributed processing functions? 4.

METRICS FOR THE ANALYSIS MODEL. .

 External Outputs: Messages. External Inputs are: Password. Alarm Set.METRICS FOR THE ANALYSIS MODEL. Activate / Deactivate. 3 Number of External Outputs(E0s) 2 Number of External inquiries: (Eqs) 2 Number of internal logical files(ILFs) 1 Number of external interface files(EIFs) 4 Total: Weighted factor Averag Comple Simple e x 3 4 6 4 5 7 3 4 6 7 5 10 7 15 10 = = = = = = 9 8 6 7 20 50 .  External Interface Files: Test Sensor. Zone Setting.  Information Domain Value Count x x x x x Number of External Inputs (EIs). Activate /Deactivate. Panic Button.  Internal Logic file: System Configuration file.  External Inquires: Zone Inquiry. Sensor Status. sensor inquiry.

And Fi(i=1 to 14) are the value adjustment factors for purpose we assume Fi=46. the project team can estimate the overall implemented size of the software user interaction function. Assume that past data indicate that one FP translates into 60 lines .METRICS FOR THE ANALYSIS MODEL. The count total shown in the table must be adjusted using equation.01 x 46)] = 56 Based on the projected FP value derived from the analysis model.65 + 0.01 x (Fi)] Where count total is the sum of all FP entries obtained from the table.65 + 0. Therefore FP=50 x [0. FP=count total x [0.

PROCESS METRICS     Process metrics are collected across all projects and over long periods of time They are used for making strategic decisions The intent is to provide a set of process indicators that lead to long-term software process improvement The only way to know how/where to improve any process is to Measure specific attributes of the process  Develop a set of meaningful metrics based on these attributes  Use the metrics to provide indicators that will lead to a strategy for improvement  .

PROCESS METRICS  Some notable process attributes are:           Rate of programmer errors Rate of software failure events Rate of software fault introduction Number of software change request Number of pending trouble reports Measures of developer productivity Cost information Software process improvement costs. Return on investment The above list is not intended to be .

PROCESS METRICS .

Etiquette of Process Metrics 52       Use common sense and organizational sensitivity when interpreting metrics data Provide regular feedback to the individuals and teams who collect measures and metrics Don’t use metrics to evaluate individuals Work with practitioners and teams to set clear goals and metrics that will be used to achieve them Never use metrics to threaten individuals or teams Metrics data that indicate a problem should not be considered “negative”  Such data are merely an indicator for process improvement  Don’t obsess on a single metric to the exclusion of other important metrics .

Project Metrics 53  Project metrics enable a software project manager to      Assess the status of an ongoing project Track potential risks Uncover problem areas before their status becomes critical Adjust work flow or tasks Evaluate the project team’s ability to control quality of software work products   Many of the same metrics are used in both the process and project domain Project metrics are used for making tactical decisions  They are used to adapt project workflow and technical activities .

modeling. other project metrics become important   Production rates are measured (represented in terms of models created. function points. the amount of time and effort expended are compared to original estimates As technical work commences.Use of Project Metrics 54  The first application of project metrics occurs during estimation  Metrics from past projects are used as a basis for estimating time and effort  As a project proceeds.e. review hours. deployment) are measured  (More on next slide) . planning. and delivered source lines of code) Error uncovered during each generic framework activity (i. communication. construction.

the overall project cost is reduced   In summary    . to modify the technical approach to improve quality As quality improves. when necessary. defects are minimized As defects go down.55  Use of Project Metrics (continued) Project metrics are used to  Minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks Assess product quality on an ongoing basis and. the amount of rework required during the project is also reduced As rework goes down.

there are six criteria:        Project Time Line Project Cost Management Project Resources Project Scope Management Project Quality Management Project Action Items . As an analogy.Project Metrics – Performance 56 metrics There is a way to provide a project management status report.

90/ 84:7.47 90 3:2-07 41 5740.0 308 3 90 25020390/ 88902 .

943 54398 .4:39.8:708 41 8419.42509 31472.70 .%#$ #%$$   :3.70 /0130/ 3 90 1443 2.3307 J – €fn °€¯f°¯f°If -¯ € °f°½¾%¾%  -¯ € °f½¾%¾% -¯ € °f° ¾ %¾% -¯ €° °f–nf€ ¾%¾% -¯ €  °f° €fn  € ¾%¾% . 70.943 /42.3 .8808820398 41 8419.-0 20.70 8 31472.3 ..943 /42.80/ 43 .0/ :83 .94385 -.3 0257.70 /07..:08 .3/ .

°      ¯½  f– .

¯½        .

   %  ( 070.-0.80/ 43708543808949014436:089438 .:0.4:39949.%#$ #%$$  %4.9478 ' -.70.!0397084-9..943858 :80/ !.707 %0 94 .425:90901:3../:8920391.30/1742 9.94341!90144370.030.8908:241.4:39949.

.3.-0  70..9.0397  4089043 30/.38070/:83.3/1470.09.8.30893 0....9439447 174290.03.07  70850.-0-.07843.943.9438706:70/9497.4250  890.:5.97..4250  89039073.:/0/390/083  89088902/0830/1472:950389.07 2:9508.:90/4507.9.7432039  4089088902706:7043 30/.3/70.9.943  709070/897-:90/574.38.9..0...9433.  90889027:33.3.55.43.70038474507.9438  890.0//..79.94383/110703947.4.943/0830/941....9438  85071472.4190806:0894388.08831:3.%#$ #%$$  4089088902706:7070.0397706:709035:997.90/43 30  709035:98 4:95:98 1084736:708.90.8041:80-90 :807 .3/389.55.4/0/0830/94-070:8.30..3810731472.422:3.94394-0-:94.3081742 94  ..9438  70908:5/.0883.574.

%#$ #%$$  .

3.35:98.:9943 ..8847/ !.9.70 !.%#$ #%$$  9073.90.

08 $03847$9.9:8 9073..39071.10 $8902431:7.. :95:98 088.94310 9073.36:708 43036:7 80384736:7 39073.9.4..008 %089$03847 430$0993 .90 9073..9.90.0.

39071..0                 31472.35:98 8  :2-07419073.0108 8  %49.3'..36:708 68 4:39                     :2-074139073.07.9. :95:98  8 :2-07419073.:0 :2-07419073..4.94342.. .947 4250 $250 .72$09 090/1..0.108 8  :2-074109073.90 .

   %  ( 070.0/174290.3.07.9430!97..3/.990..2.80/43905740.38..-0  3/ 94 .4:39949..89/./:8920391..943  88:209.:0/07.25020390/8041908419.4:39949.8908:241.8433909.4/0.94781475:754800 .90/!.4:39949.8824/0 90 5740..-02:89-0.9.30892.88:20 %0701470 !     ( .30/1742909.!0397084-9.%#$ #%$$  %0.908394 30841 .507843 243941011479 .943 !.9431:3.:0.0/1470.9!8.909./:890/:8306:.7090.90904.3/9.95.70 :8073907.70574/:..

0882574.70574.98.0882097. /0.94344.7488.0883/.90.94789.3897.90./ 9443 90728419.40.5740.!# $$%#$ !74.90/.70:80/1472..70./0.80941574.02039 %043.8.07 435074/841920 %0.3/4..8438 %039039894574.

045..8094120.9478 9.088 V 0.8 -.997-:908 V &80902097.8:70850..894574./94.0.80/439080.997-:908 4190574.070942574.1./03/.90147 2574.0888 94 0.3574.331:2097.90.02039 V .897.

04507574/:.-4.0882574.9 48931472.90415747.997-:908.!# $$%#$ $420349.4898 #09:73433.701..943 $419.088.70574.:93974/:.8:70841/0.-0574.02039.90418419.:700.70 V V V V V V V V V V #.0892039 %0.943 :2-07418419.9.2207077478 #.701.90418419.08983493903/0/94-0 .30706:089 :2-0741503/3974:-07054798 0.70.0398 #.

!# $$%#$ .

0902 0.9033/.0.07:802097.702070.8:708.90.9-0:80/94.8 43 9:802097.3.84790.9943078.9.2894809.088097.93/.3/2097.9.02039 43 94-808843.947147574.8 9.3/2097.94900.903/.8940.9../:.7100/-.438/070/ 30.8 ..8. !74.40.33/.8.94903/..8/.96:099041!74.0.8/.74./.0882574.:.28 097./070:.0 V $:.80389.943.903390757093 2097.8302097../:.4224380380.9.3/90.574-0284:/349 -0.9./:..8  &80.284.8 47957.:84341490725479.39 2097..3/90.894970.9 20.3/47..

8  !740.8-0147090789.8.70:80/1472.0794 V V V V V 880889089.9:8-0.07574-02.202097.:.88 .3.90905740.705740.4208..9.!740. /:894714479.908 .92097.9 %7.788 &3.803..-994.990.8.92097.8419.439746:.7047 574/:...39../.79.343435740.595740.70:80/3-4990574.9097..9:841.92.-0.94714.98 ..4.9.341908. /0.9418419.3.088.3/5740.70:80/94..2 8.549039.8438 V %0.70.3 !740.3/90.9 /42.

943  5.7020.895740.39 V !74/:.817425.0892.3/0114790503/0/.17.4/0 7747 :3.42025479.422:3.92097.070//:730..8.333 24/03 .070/84:7.0 4:78 1:3.2047.55.90/ 70.3//0.-.9.00/8 90.9  0 .08 49075740.8-0.3..70.84..92097.908 .42203.9097.8:70/ 7057080390/3907284124/08.943 V 097.&8041!740.8:70/ V 470433098/0 .94354398 .0307..030841.8  %01789.93920 .943415740.70:80/.24:3941920.9437.3/011479 8.5740..943 /0542039 .:78/:730892.70/ 94473.908 890.9574.47.7020.425..4.881470892.43897:.70.98.

088../:892039830.0/ 87047408/43 904.0/ V 38:22.08 /010.98.088.489870/:.34343-.06:.84 70/:.70:80/94 V 32090/0..8.9 86:.3/788 88088574/:.98.5574.92574..9..7 V V V .3/ 0330.3.8.07.574-028.984/43 90.390.5740.04520398.4/ /0.24:39417047706:70//:73905740.4393:0/  !740.702320/ 8/010.3/29.8 .&8041!740.9097.7 9424/190 90.0/:0-2.88.96:.943.942574.794.92097.90549039.

9439028 .9097.5740.02039 !740.08 !740.450.3.708.!740.9.8 %0708.3.02097.9489.3.9#084:7.3.02039 !740.9.02039 !740.9:8705479 8 .0203989.94574.3.9$.4 9070. V V V V V V !740./0.9":.3.7907..3.9%2030 !740.92.8  !071472.