James Nowotarski 16 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008 2 Topic Duration Recap Project planning30 minutes Software architecture45 minutes *** Break Current events15 minutes Software architecture (cont.)90 minutes Todays Agenda 3 Creating a project work plan Cust requirements 1 Negotiate reqts negotiated requirements 2 Decom- pose work breakdown structure 4 Estimate resources workmonths 3 Estimate size deliverable size 5 Develop schedule Iterate as necessary Copyright 2006 The McGraw-Hill Companies. All rights reserved. Deliverable-oriented WBS 5 1.Breaks project into a hierarchy. 2.Creates a clear project structure. 3.Avoids risk of missing project elements. 4.Enables clarity of high level planning. Sample WBS (activity- oriented) Copyright 2006 The McGraw-Hill Companies. All rights reserved. Activity-oriented WBS 7 Users requirements 1 Negotiate reqts negotiated requirements 2 Decom- pose work breakdown structure 4 Estimate resources workmonths 3 Estimate size deliverable size 5 Develop schedule Iterate as necessary productivity rate Planning process 8 Units of software size Lines of code (LOC) Function points (FP) Components 9 Estimation of LOC CAD program to represent mechanical parts Estimated LOC = (Optimistic + 4(Likely)+ Pessimistic)/6 Major Software Functions Opt- imistic Most Likely Pess- imistic Estimated LOC User interface and control facilitiesUICF1,5002,3003,1002,300 Two-dimensional geometric analysis2DGA3,8005,2007,2005,300 Three-dimensional geometric analysis3DGA4,6006,9008,6006,800 Database managementDBM1,6003,5004,5003,350 Computer graphics display featuresCGDF3,7005,0006,0004,950 Peripheral controlPC1,4002,2002,4002,100 Design analysis modulesDAM7,2008,30010,0008,400 Estimated lines of code 23,80033,40041,80033,200 10 LOC Lines of code is a useless measurement in the face of code that shrinks when we learn better ways of programming (Kent Beck) Computing Function Points Measurement parameterCount Sim- ple AvgCom -plex Number of user inputsX346= Number of user outputsX457= Number of user inquiries X346= Number of filesX71015= Number of external interfaces X5710= Count (Unadjusted Function Points) UFP Calculate Degree of Influence (DI) No influence IncidentalModerateAverageSignificantEssential 1.Does the system require reliable backup and recovery? 2.Are data communications required? 3.Are there distributed processing functions? 4.Is performance critical? 5.Will the system run in an existing, heavily utilized operational environment? 6.Does the system require on-line data entry? 7.Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8.Are the master files updated on-line? 9.Are the inputs, outputs, files, or inquiries complex? 10.Is the internal processing complex? 11.Is the code designed to be reusable? 12.Are conversion and installation included in the design? 13.Is the system designed for multiple installations in different organizations? 14.Is the application designed to facilitate change and ease of use by the user? The FP Calculation: Inputs include: Count Total DI = F i (i.e., sum of the Adjustment factors F 1.. F 14) Calculate Function points using the following formula: FP = UFP X [ X Fi ] In this example: FP = 177 X [ X ( ) FP = 177 X [ X (36) FP = 177 X [ ] FP = 177 X [1.01] FP = TCF: Technical complexity factor 14 Components SimpleMediumHard # Database tables # Reports Etc. 15 Users requirements 1 Negotiate reqts negotiated requirements 2 Decom- pose work breakdown structure 4 Estimate resources workmonths 3 Estimate size deliverable size 5 Develop schedule Iterate as necessary productivity rate Planning process 16 Bottom-up estimating Estimate = #units x time per unit For example, a report design task: 10 reports 3 hours per report Estimate = 30 person-hours (aka workhours Most projects are estimated in this way, once details are known about units Using FP to estimate effort: If for a certain project FP Estimated = 372 Organizations average productivity for systems of this type is 6.5 FP/person month Effort Estimated = ??? Burdened labor rate of $8000 per person month Total project cost $??? Cost per FP $??? 18 Other estimating techniques Expert judgment Analogy Algorithmic General model: E = A + B x (ev) c where E is effort in person months A, B, and C are empirically derived constants ev is the estimation variable (either in LOC or FP) 19 LOC-Oriented Estimation Models E = 5.2 X (KLOC) 0.91 Walston-Felix Model E = X (KLOC) 1.16 Bailey-Basili Model E = 3.2 X (KLOC) 1.05 Boehm simple model E = X (KLOC) Dot Model for KLOC > 9 FP-Oriented Estimation Models E = FPAlbrecht and Gaffney Model E = X X FP 3 Kemerer model E = FPMatson, Barnett, Mellichamp model Software size estimation formulae 20 Top-down vs. Bottom-up Communication project initiation requirements Modeling analysis design Construction code test Deployment delivery support Planning & Managing Top-down approximating: - Expert judgment - Analogy - Algorithmic Bottom-up estimating 21 Estimating accuracy improves over timeCOCOMOII/index.html Some famous words from Aristotle Aristotle ( B.C.) It is the mark of an instructed mind to rest satisfied with the degree of precision which the nature of a subject admits, and not to seek exactness when only approximation of the truth is possible. 23 Users requirements 1 Negotiate reqts negotiated requirements 2 Decom- pose work breakdown structure 4 Estimate resources workmonths 3 Estimate size deliverable size 5 Develop schedule Iterate as necessary productivity rate Planning process 24 GANTT Schedule View Project in Context of time. Critical for monitoring a schedule. Granularity 1 2 weeks. 25 Estimating Schedule Time Rule of thumb (empirical) Schedule Time (months) = 3.0 * person-months 1/3 26 One of the primary jobs of a project manager is to manage these tradeoffs 27 Some Courses at DePaul SE 468: Software Measurement and Estimation Software metrics. Productivity, effort and defect models. Software cost estimation. PREREQUISTE(S):CSC 423 and either SE 430 or CSC 315 or consent SE 477: Software and System Project Management Planning, controlling, organizing, staffing and directing software development activities or information systems projects. Theories, techniques and tools for scheduling, feasibility study, cost-benefit analysis. Measurement and evaluation of quality and productivity. PREREQUISTE(S):SE 465 or CSC 315 28 People trump process One good programmer will always outcode 100 hacks in the long run, no matter how good of a process or IDE you give thembad-agile_27.html 29 Topic Duration Recap Project planning30 minutes Software architecture45 minutes *** Break Current events15 minutes Software architecture (cont.)90 minutes Todays Agenda 30 Software Engineering Body of Knowledge Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE.What is SE? tonight 31 Architecture architecture n. An architecture depicts the overall structure of a man-made complex system Architectural beauties and beasts LOVELIEST Monadnock Building 53 W. Jackson UGLIEST Mr. Submarine 18 W. Jackson 32 Source: Chicago Tribune, July 28, 2004 33 System architecture 1.A formal specification for how a computer solution will be organized and how its components interact (Gartner Group) 2.A comprehensive framework that describes form and structure components and how they fit together (Jerrold Grochow) 3.The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution (IEEE) 4.An integrated set of technology choices used to guide the organization (MIT) 34 System architecture as a stack Applications and Data Middleware Hardware/Network System Software Workstations, Mobile Devices Servers, Storage Routers, Switches, Bandwidth Development tools, languages Web servers, App servers Database Management Systems Operating Systems CRM ERP Claims processing Payroll Application programming interfaces Transaction processing monitors 35 System architecture as a stack Applications and Data Middleware Hardware/Network System Software Vendors/Products Dell, HP, Sun, EMC, Cisco AT&T, MCI, Sprint Public Internet J2EE Apache BEA WebLogic DB2, Oracle, SQL Server Linux, Unix, Windows, z/OS Custom developed SAP, Peoplesoft, Oracle Salesforce.com ODBC BEA Tuxedo 36 System architecture as a stack Applications and Data Middleware Hardware/Network System Software System Architecture Scope is rather broad 37 Software architecture Applications and Data Middleware Hardware/Network System Software Presentation layer Application logic Data management 38 Software architecture is a level of design that involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. What is software architecture? 39 Architectural styles A set of design rules imposed on the entire system 40 Taxonomy of architectural styles Data-centered Data flow (aka pipes and filters) Call and return Object oriented architectures Layered Systems Online transaction processing Process control 41 Data centered 42 Examples: UNIX shell commands Compilers: Lexical Analysis -> parsing -> semantic analysis -> code generation Batch Processing Filter Pipe Data flow 43 Call and return 44 Call and return PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax) GET_DATA employee_data CALC_SALARY employee_ data salary CALC_TAX salary tax PRINT_CHECK employee_data salary tax 45 Object-Oriented (Component Structure) 46 Deriving a software architecture: Structured approach Derive architectural context diagram (ACD) Refine the DFD Map DFD to program structure: Transform mapping Transaction mapping 47 Architecture context diagram (ACD) 48 Transform mapping 49 Typical design resulting from transform mapping main program controller input controller processing controller output controller 50 Transaction Mapping a b t g h d e f i k j l m n Data flow model x1 b a t x2 x3 x4 d e f g h x3.1 l m n i j k mapping program structure 51 Transaction Example operator commands process operator commands fixture setting report robot control fixture servos display screen robot control software in reality, other commands would also be shown assembly record 52 Transaction Mapping a b t g h d e f i k j l m n Data flow model x1 b a t x2 x3 x4 d e f g h x3.1 l m n i j k mapping program structure These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 Isolate Flow Paths read command validate command determine type read record calculate output values format report produce error msg read fixture status determine setting format setting send control value command invalid command error msg status combined status raw setting fixture setting robot control start/stop assembly record values report valid command 54 Map the Flow Model 55 Refining the Structure Chart 56 Benefits of a well-done software architecture 57 Pinkys Pizza What architectural style(s)? Recall processes: Incoming calls Customer inquiry/maintenance Menu inquiry/maintenance Order inquiry/maintenance Management reporting 58 Small Group Activity Divide into small groups. Design an architecture to support an ambulance dispatch service. This service needs to receive incoming calls, track availability of ambulances, dispatch ambulances, deliver patients to hospitals. It also needs to track open/closed status of each hospital. Create a software architecture and identify any architectural styles you used. 59 Assignment 3 Read Pressman Chapter 27 Current event reports For October 23