Presentation is loading. Please wait.

Presentation is loading. Please wait.

Devon M. Simmonds Computer Science Department, CSC550 1 1 Devon M. Simmonds Overview of Software Engineering CSC 550.

Similar presentations


Presentation on theme: "Devon M. Simmonds Computer Science Department, CSC550 1 1 Devon M. Simmonds Overview of Software Engineering CSC 550."— Presentation transcript:

1 Devon M. Simmonds Computer Science Department, CSC550 1 1 Devon M. Simmonds Overview of Software Engineering CSC 550

2 Devon M. Simmonds Computer Science Department, CSC550 2 2 Outline Process models Project management SE Code of ethics

3 Devon M. Simmonds Computer Science Department, CSC550 3 3 What is a software process? A set of activities whose goal is the develop or evolve software. A series of steps involving activities, constraints, and resources that produce an intended output. A sequence of steps required to develop or maintain software. (Watts Humphrey) Why do we need software processes?

4 Devon M. Simmonds Computer Science Department, CSC550 4 4 Process models An abstract representation of a process presented from a specific perspective. – The Circulatory System perspective Flow of blood in CS Blood vessels of the CS Role of circulatory system in digestion. Components of the Circulatory System

5 Devon M. Simmonds Computer Science Department, CSC550 5 5 Software process models An abstract representation of a software process presented from a specific perspective. – Workflow perspective represents inputs, outputs and dependencies. – Data-flow perspective represents data transformation activities. – Role/action perspective represents the roles/activities of the people involved in software process.

6 Devon M. Simmonds Computer Science Department, CSC550 6 6 Generic Software Process Models Code and Fix The waterfall model – Separate and distinct phases of specification and development Incremental & iterative models – Specification and development are interleaved RAD, Spiral, Unified Process, etc. Evolutionary models Formal models – A mathematical system model is formally transformed to an implementation Component-based software development – The system is assembled from existing components The Unified Process

7 Devon M. Simmonds Computer Science Department, CSC550 7 7 Process – code, test, debug Problems – requirements analysis and design ignored – code does not evolve gracefully – debugging is difficult (why?) “Code and Fix” Model

8 Devon M. Simmonds Computer Science Department, CSC550 8 8 Waterfall Model Systems Engineering Requirements Analysis Software Design Implementation and Testing Operation and Evolution Proposed by Royce in response to desire to structure software development process. Phases similar to phases used to develop hardware.

9 Devon M. Simmonds Computer Science Department, CSC550 9 Systems Engineering Requirements Analysis Software Design Implementation and Testing Operation and Evolution 9 Problems with Waterfall Model Treats development as a manufacturing process – Model is optimized for hardware development. – Does not take into consideration problem-solving nature of development. – Does not support design a little, code a little problem solving strategy (Takes static view of requirements). Lack of feedback between phases (Boehm introduced feedback) Hard dates on phases Lack of completion criteria for analysis and design No insight given into how each activity transforms an intermediate product into another. Little guidance on how to handle changes to products and activities. -Summary: Has d ifficulty accommodating change after the process is underway

10 Devon M. Simmonds Computer Science Department, CSC550 10 10 Waterfall model usage Waterfall model describes a process of stepwise refinement  Based on hardware engineering models  Widely used in military and aerospace industries Systems Engineering Requirements Analysis Software Design Implementation and Testing Operation and Evolution Model is appropriate when the requirements are well- understood

11 Devon M. Simmonds Computer Science Department, CSC550 11 The V Model Requirements Analysis Architectural Design Subsystem Design Detailed Design Implementation Acceptance Test System Test Integration Test Module TestUnit Test

12 Devon M. Simmonds Computer Science Department, CSC550 12 12 Incremental and Iterative Models Build 1 Release 1 Build 2 Release 2 Build 3 Release 3 DEVELOPERS USERS

13 Devon M. Simmonds Computer Science Department, CSC550 13 13 Incremental/Iterative Development Incremental Development – add new features each iteration Iterative Development – edit, modify, refactor, even if no new features are added

14 Devon M. Simmonds Computer Science Department, CSC550 14 14 Incremental development User requirements are prioritised and the highest priority requirements are included in early increments Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve

15 Devon M. Simmonds Computer Science Department, CSC550 15 15 Evolutionary Models: Prototyping

16 Devon M. Simmonds Computer Science Department, CSC550 16 16 Evolutionary Models: The Spiral Model Sector

17 Devon M. Simmonds Computer Science Department, CSC550 17 17 Spiral Model II

18 Devon M. Simmonds Computer Science Department, CSC550 18 18 Component-based Software Development (CBSD) Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Process stages – Component analysis – Requirements modification – System design with reuse – Development and integration Approach becoming more important – Experience still limited

19 Devon M. Simmonds Computer Science Department, CSC550 19 The Unified Process 19

20 Devon M. Simmonds Computer Science Department, CSC550 20 20 inception The Unified Process (UP) inception elaboration

21 Devon M. Simmonds Computer Science Department, CSC550 21 21 UP Work Products

22 Devon M. Simmonds Computer Science Department, CSC550 22 22 Formal systems development Based on the transformation of a mathematical specification through different representations to an executable program Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification

23 Devon M. Simmonds Computer Science Department, CSC550 23 23 Formal systems development Problems – Need for specialised skills and training to apply the technique – Difficult to formally specify some aspects of the system such as the user interface Applicability – Critical systems especially those where a safety or security case must be made before the system is put into operation

24 Devon M. Simmonds Computer Science Department, CSC550 24 24

25 Devon M. Simmonds Computer Science Department, CSC550 25 25 Project management is a set of principles and tools for –Defining –Planning –Executing –Controlling... and –Completing a PROJECT What is Project Management?

26 Devon M. Simmonds Computer Science Department, CSC550 26 Software Project Management 26 Software project management is the organization and management of project resources to create or evolve software within specified, budgetary, time and scoping constraints. – A software project is a set of activities that use resources to realize specified software development objectives.

27 Devon M. Simmonds Computer Science Department, CSC550 27 Project Management Activities 27  Planning  Description of tasks to be done  Estimating resources  People, time, hardware, software, money, etc.  Acquiring resources  Assemble project teams  Assigning tasks & organizing work  Allocating resources  Assessing and mitigating risks (i.e., Risk Management)Risk Management  Controlling project execution  Tracking and Reporting progress  Analyzing results  Forecasting future trends in the project  Quality Management

28 Devon M. Simmonds Computer Science Department, CSC550 28 The 4 P’s of Software Project Management 28 People — the most important element of a successful project Product — the software to be built Process — the set of framework activities and software engineering tasks to get the job done Project — all work required to make the product a reality

29 Devon M. Simmonds Computer Science Department, CSC550 29 People: Who builds software? 29 Software is typically built by a team of software engineers, which includes: – Business analysts or requirements analysts who talk to users and stakeholders, plan the behavior of software and write software requirements – Designers and architects who plan the technical solution – Programmers who write the code – Testers who verify that the software meets its requirements and behaves as expected

30 Devon M. Simmonds Computer Science Department, CSC550 30 Software Teams 30 How to lead? How to organize? How to motivate? How to collaborate? How to create good ideas?

31 Devon M. Simmonds Computer Science Department, CSC550 31 Team Leadership 31 The MOI Model [Weinberg] – Motivation. The ability to encourage technical people to produce to their best ability. – Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. – Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

32 Devon M. Simmonds Computer Science Department, CSC550 32 Traits of an effective project manager 32  Problem solving  Must be able to diagnose technical and managerial issues  Must be able to realize a solution the coordinating personal skills with skills of the team  Must be flexible enough to change directions when initial attempts at realizing solution are fruitless  Managerial identity  Must take charge of project  Must have the confidence to take control when necessary  Must allow competent persons to follow their own initiatives  Achievement  Must reward initiative and accomplishment  Influence and team building  Must be able to “read” people  Must be able to understand verbal and non-verbal signals  Must remain under control in high-stress situations

33 Devon M. Simmonds Computer Science Department, CSC550 33 Organizational Paradigms 33 closed paradigm—structures a team along a traditional hierarchy of authority – E.g. chief programmer team random paradigm—structures a team loosely and depends on individual initiative of the team members open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm – Democratic teams synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

34 Devon M. Simmonds Computer Science Department, CSC550 34 Agile Teams 34 Team members must have trust in one another. The distribution of skills must be appropriate to the problem. Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. Team is “self-organizing” – An adaptive team structure – Uses elements of random, open, and synchronous paradigms – Significant autonomy

35 Devon M. Simmonds Computer Science Department, CSC550 35 Software Teams 35 the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime) the degree to which the problem can be modularized the required quality and reliability of the system to be built the rigidity of the delivery date the degree of sociability (communication) required for the project How well people know each other Factors to be considered

36 Devon M. Simmonds Computer Science Department, CSC550 36 36 Devon M. Simmonds Estimation for Software Projects An Overview

37 Devon M. Simmonds Computer Science Department, CSC550 37 37 Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

38 Devon M. Simmonds Computer Science Department, CSC550 38 38 The Software Lifecycle General activities – Project management metrication – Software estimation & scheduling – Training – Verification & validation (V & V) Requirements Analysis Software Design Implementation Testing Deployment Evolution Systems Engineering Lifecycle Models

39 Devon M. Simmonds Computer Science Department, CSC550 39 Software Project Management 39 Software project management is the organization and management of project resources to create or evolve software within specified, budgetary, time and scoping constraints.

40 Devon M. Simmonds Computer Science Department, CSC550 40 40 Five Phases of Project Management Scoping the Project Adapted from Weiss, J.W., and Wysocki, R.K. 1992. 5-Phase Project Management: A Practical Planning and Implementation Guide. Reading, MA: Addison Wesley. Developing the Project Plan Scoping the Project Launching the Plan Monitoring & Controlling Closing Out the Project

41 Devon M. Simmonds Computer Science Department, CSC550 41 41 Developing The Plan Construct/Analyze Project Schedule Prepare the Project Proposal Identify Project Tasks (WBS) Estimate Task Duration Estimate Resource Requirements

42 Devon M. Simmonds Computer Science Department, CSC550 42 The Scenario Imagine that you are part of a team of persons whose responsibility it is to develop a software product.

43 Devon M. Simmonds Computer Science Department, CSC550 43 The Problem How do you determine the required resources for the project?

44 Devon M. Simmonds Computer Science Department, CSC550 44 44 The Make-Buy Decision

45 Devon M. Simmonds Computer Science Department, CSC550 45 45 Computing Expected Cost (path probability) x (estimated path cost) (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost = 0.30 ($380K) + 0.70 ($450K) similarly, expected cost = $382K expected cost = $267K expected cost = $410K build reuse buy contr expected cost = = $429 K

46 Devon M. Simmonds Computer Science Department, CSC550 46 Still a Problem If you decide to build the product – How do you determine the required resources for building the product? or How do you estimate the cost of developing the software.

47 Devon M. Simmonds Computer Science Department, CSC550 47 47 Functional Decomposition functionaldecomposition StatementofScope Perform a Grammatical “parse” Functional Decomposition produces a WBS which is refined into to required granularity. Estimates for separate modules are computed and aggregated.

48 Devon M. Simmonds Computer Science Department, CSC550 48 Work Breakdown Structure Software Project System Engineering Analysis Design Testing Architectural Design Detailed Design Procedural Design Database Design User Interface Design … Algorithm Design Test Case Design Determine Work Patterns Design Interface Design Review … … Define Operational Signatures Define Pre/post Conditions

49 Devon M. Simmonds Computer Science Department, CSC550 49 49 Estimation Estimation of resources, cost, and schedule for a software engineering effort requires – experience – access to good historical information (metrics – the courage to commit to quantitative predictions when qualitative information is all that exists Estimation carries inherent risk and this risk leads to uncertainty

50 Devon M. Simmonds Computer Science Department, CSC550 50 50 Estimation Techniques Past (similar) project experience Conventional estimation techniques – task breakdown and effort estimates – size (e.g., FP) estimates Empirical models Automated tools

51 Devon M. Simmonds Computer Science Department, CSC550 51 51 Estimation Accuracy Predicated on … – the degree to which the planner has properly estimated the size of the product to be built – the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects) – the degree to which the project plan reflects the abilities of the software team – the stability of product requirements and the environment that supports the software engineering effort.

52 Devon M. Simmonds Computer Science Department, CSC550 52 52 Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical data to build estimates for the project

53 Devon M. Simmonds Computer Science Department, CSC550 53 53 Function-Based Metrics The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity Information domain values are defined in the following manner: – number of external inputs (EIs) – number of external outputs (EOs) – number of external inquiries (EQs) – number of internal logical files (ILFs) – Number of external interface files (EIFs) FP = count-total * (0.65 +.01 * ∑ (F i ) ) Sum of information domain values Value Adjustment Factor

54 Devon M. Simmonds Computer Science Department, CSC550 54 54 Function Points: Information domain values 4 5 4 10 7

55 Devon M. Simmonds Computer Science Department, CSC550 55 55 Function Points: Information domain values 4 5 4 10 7 4 5 4 10 7 20 24 30 EV = (opt + 4*likely + pess)/6 24.3 97 78 88 42 15 320

56 Devon M. Simmonds Computer Science Department, CSC550 56 56 Example: Computing FP The estimated number of FP is derived: FP estimated = count-total * [0.65 + 0.01 * ∑ (F i )] i.e FP estimated = 320 * [0.65 + 0.01 * ∑ (F i )] i.e FP estimated = 320 * [0.65 + 0.01 * ∑ (F i )] Need to compute Value Adjustment Factor 320

57 Devon M. Simmonds Computer Science Department, CSC550 57 Computing the Value Adjustment Factor Each factor is assessed on a scale from: 0  not important to 5  absolutely essential 57 52

58 Devon M. Simmonds Computer Science Department, CSC550 58 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 58 Example: Computing FP The estimated number of FP is derived: FP estimated = count-total [0.65 + 0.01 3 S (F i )] FP estimated = 320 * [0.65 + (0.01 * 52)] = 320 * (0.65 + 0.52) = 320 * 1.17 = 375 so FP estimated = 375 Now that we have computed the number of function points, how do we estimate the cost of developing the software?Now that we have computed the number of function points, how do we estimate the cost of developing the software? organizational average productivity = 6.5 FP/pm  duration = 375/6.5 = 58 person- months.organizational average productivity = 6.5 FP/pm  duration = 375/6.5 = 58 person- months. the cost per FP is approximately $1230 (based on burdened labor rate = $8000 per month,)  total project cost = 1230 * 375 = $461,250.the cost per FP is approximately $1230 (based on burdened labor rate = $8000 per month,)  total project cost = 1230 * 375 = $461,250. 320

59 Devon M. Simmonds Computer Science Department, CSC550 59 59 Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. The cost per line of code is = 8000/620 = $13 ( Based on burdened labor rate of $8000 per month ). Estimated effort = 33,200 / 620 = 54 person-months. Project Cost = (13 * 33,200) OR (54 * 8000) = $431,000. Estimated LOC = (opt + 4*likely + pess)/6

60 Devon M. Simmonds Computer Science Department, CSC550 60 60 Empirical Estimation Models General form: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project usually LOC but may also be function point empirically derived

61 Devon M. Simmonds Computer Science Department, CSC550 61 61

62 Devon M. Simmonds Computer Science Department, CSC550 62 62 Scheduling Similarity to other activities Historical data Expert advice

63 Devon M. Simmonds Computer Science Department, CSC550 63 63 Resource Activity Identify all the resources required for each activity Estimate the duration of each activity Software Project System Engineering Analysis Design Testing Architectural Design Detailed Design Procedural Design Database Design User Interface Design … Algorithm Design Test Case Design Determine Work Patterns Design Interface Design Review … … Define Operational Signatures Define Pre/post Conditions

64 Devon M. Simmonds Computer Science Department, CSC550 64 64 Dependencies Linkage between and among activities/tasks Dependencies create the backbone of the project network

65 Devon M. Simmonds Computer Science Department, CSC550 65 65 Dependencies Predecessor Task: A Successor Task: B Arrow head indicates dependency relationship: Task B cannot begin until Task A is complete AB

66 Devon M. Simmonds Computer Science Department, CSC550 66 66 Gantt Chart Visual scheduling tool Graphical representation of information in WBS Show dependencies between tasks, personnel, and other resources allocations Track progress towards completion Developed by Engineer, Henry L. Gant, 1917. Henry Laurence Gantt (1861-1919)

67 Devon M. Simmonds Computer Science Department, CSC550 67 67 Building a Gantt Chart Activities: Create box the length of each activity time duration –E.g., activity one is scheduled from day1-day3 Milestones: Create a diamond on the day the milestone is scheduled to be completed Activity 1 Activity 2 Milestone Time Frame: day 1 day 2 day3

68 Devon M. Simmonds Computer Science Department, CSC550 68 68 Building a Gantt Chart Dependencies: Show dependencies between activities with arrows –E.g., activity 2 cannot start until activity 1 is complete Activity 1 Activity 2 Milestone Time Frame: day 1 day 2 day3… day 23

69 Devon M. Simmonds Computer Science Department, CSC550 69 69 Gantt Chart – Example Estimated time to complete a task Tasks

70 Devon M. Simmonds Computer Science Department, CSC550 70 Scheduling: Critical Path Method (CPM) 70 CPM developed in 1956/57 by Kelly & Walker for DuPont Goal – Shut down chemical plants for maintenance, restart plants when maintenance was completed.

71 Devon M. Simmonds Computer Science Department, CSC550 71 Scheduling: Critical Path Method (CPM) 71 CPM models the activities and events of a project as a network. Activities are depicted as nodes on the network Events that signify the beginning or ending of activities are depicted as arcs or lines between nodes

72 Devon M. Simmonds Computer Science Department, CSC550 72 Tasks, durations, and dependencies TaskEffort (person- days) Duration (days)Dependencies T11510 T2815 T32015T1 (M1) T4510 T5510T2, T4 (M3) T6105T1, T2 (M4) T72520T1 (M1) T87525T4 (M2) T91015T3, T6 (M5) T102015T7, T8 (M6) T1110 T9 (M7) T122010T10, T11 (M8)

73 Devon M. Simmonds Computer Science Department, CSC550 73 73

74 Devon M. Simmonds Computer Science Department, CSC550 74 Summary

75 Devon M. Simmonds Computer Science Department, CSC550 75 TheEnd CSC550, Devon M. Simmonds, Computer Science Department, University of North Carolina Wilmington ??????????????? CSC550 2012 Q u e s t i o n s ?

76 Devon M. Simmonds Computer Science Department, CSC550 76 76

77 Devon M. Simmonds Computer Science Department, CSC550 77 How do I estimate the cost of developing a software product? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 77

78 Devon M. Simmonds Computer Science Department, CSC550 78 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 78 Functional Decomposition functionaldecomposition StatementofScope Perform a Grammatical “parse” Functional Decomposition produces a WBS which is refined into to required granularity. Estimates for separate modules are computed and aggregated.

79 Devon M. Simmonds Computer Science Department, CSC550 79 Work Breakdown Structure Software Project System Engineering Analysis Design Testing Architectural Design Detailed Design Procedural Design Database Design User Interface Design … Algorithm Design Test Case Design Determine Work Patterns Design Interface Design Review … … Define Operational Signatures Define Pre/post Conditions

80 Devon M. Simmonds Computer Science Department, CSC550 80 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 80 Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical data to build estimates for the project

81 Devon M. Simmonds Computer Science Department, CSC550 81 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 81 Function-Based Metrics The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity Information domain values are defined in the following manner: – number of external inputs (EIs) – number of external outputs (EOs) – number of external inquiries (EQs) – number of internal logical files (ILFs) – Number of external interface files (EIFs) FP = count-total * (0.65 + ).01 * ∑ (F i ) Sum of information domain values Value Adjustment Factor

82 Devon M. Simmonds Computer Science Department, CSC550 82 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 82 Function Points: Information domain values 4 5 4 10 7

83 Devon M. Simmonds Computer Science Department, CSC550 83 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 83 Function Points: Information domain values 4 5 4 10 7 4 5 4 10 7 20 24 30 EV = (opt + 4*likely + pess)/6 24.3 97 78 88 42 15 320

84 Devon M. Simmonds Computer Science Department, CSC550 84 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 84 Example: Computing FP The estimated number of FP is derived: FP estimated = count-total * [0.65 + 0.01 * ∑ (F i )] i.e FP estimated = 320 * [0.65 + 0.01 * ∑ (F i )] i.e FP estimated = 320 * [0.65 + 0.01 * ∑ (F i )] Need to compute Value Adjustment Factor 320

85 Devon M. Simmonds Computer Science Department, CSC550 85 Computing the Value Adjustment Factor Each factor is assessed on a scale from: 0  not important to 5  absolutely essential 85 52

86 Devon M. Simmonds Computer Science Department, CSC550 86 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 86 Example: Computing FP The estimated number of FP is derived: FP estimated = count-total [0.65 + 0.01 3 S (F i )] FP estimated = 320 * [0.65 + (0.01 * 52)] = 320 * (0.65 + 0.52) = 320 * 1.17 = 375 so FP estimated = 375 Now that we have computed the number of function points, how do we estimate the cost of developing the software?Now that we have computed the number of function points, how do we estimate the cost of developing the software? organizational average productivity = 6.5 FP/pm  duration = 375/6.5 = 58 person- months.organizational average productivity = 6.5 FP/pm  duration = 375/6.5 = 58 person- months. the cost per FP is approximately $1230 (based on burdened labor rate = $8000 per month,)  total project cost = 1230 * 375 = $461,250.the cost per FP is approximately $1230 (based on burdened labor rate = $8000 per month,)  total project cost = 1230 * 375 = $461,250. 320

87 Devon M. Simmonds Computer Science Department, CSC550 87 87 Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. The cost per line of code is approximately $13 ( Based on burdened labor rate of $8000 per month ). Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months. Estimated LOC = (opt + 4*likely + pess)/6

88 Devon M. Simmonds Computer Science Department, CSC550 88 Summary

89 Devon M. Simmonds Computer Science Department, CSC550 89 TheEnd CSC550, Devon M. Simmonds, Computer Science Department, University of North Carolina Wilmington ??????????????? CSC550 2012 Q u e s t i o n s ?


Download ppt "Devon M. Simmonds Computer Science Department, CSC550 1 1 Devon M. Simmonds Overview of Software Engineering CSC 550."

Similar presentations


Ads by Google