1 / 36

CS 594 Software Engineering

CS 594 Software Engineering. Lecture 2 Dr. Thomas E. Potok potokte@ornl.gov 865-574-0834. Agenda. Review Requirements, JAD, and Use Case Modeling Project Size Estimates Software Development Life-Cycles Software Development Productivity. Admin. Power point files accessible?

demont
Télécharger la présentation

CS 594 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. CS 594Software Engineering Lecture 2 Dr. Thomas E. Potok potokte@ornl.gov 865-574-0834 T. E. Potok - University of Tennessee

  2. Agenda • Review Requirements, JAD, and Use Case Modeling • Project Size Estimates • Software Development Life-Cycles • Software Development Productivity T. E. Potok - University of Tennessee

  3. Admin • Power point files accessible? • Articles accessible? • AMI - American Magnetics • Main requirements • Estimate how much time the project will take • Estimate the cost of the project T. E. Potok - University of Tennessee

  4. What is relevant? • Test are open book and open notes • Know CMM • What are the benefits to a company adopting CMM? • Know requirements modeling • What is the fundamental difference between the output of a JAD session and use cases? T. E. Potok - University of Tennessee

  5. Review T. E. Potok - University of Tennessee

  6. Entity Relationship Modeling • Entities represent things • Attributes represent characteristics of the things • Relationship represent associations between things • Entities: Cat, Dog, Person, Car, Building • Attributes: name, age, height, weight • Relationships: owns, drives, pets, builds T. E. Potok - University of Tennessee

  7. Project Size Estimations T. E. Potok - University of Tennessee

  8. Metrics • Measuring the output of a process is the first step to analyzing the process. • Automobile companies measure how many manufacturing hours go into producing a car. • As with any measurement, there are problems. You are trying to summarize a great deal of information into a single or small number of values. • How much does the high and low temperatures really tell you about the weather, or the barometric pressure, or the wind direction. • Looking at any one of these measures it is easy to find flaws, and short comings. • Should the temperature be recorded at ground level? or a top a central tower? in the shade or in the sunlight. T. E. Potok - University of Tennessee

  9. Lines-of-code • What unit of measure should be used to measure software output? • The traditional and much maligned metric is called lines-of-code or LOC. • A summary of concerns with LOC: • Capers Jones notes: • 1) should the code count include non-executable code, such as comments, or explanatory information. • 2) how are differences between high-level and low-level languages represented. • 3) Whether non-delivered code should be represented in a LOC count. • So, it appears that LOC counts may not be the best way to measure software development output. T. E. Potok - University of Tennessee

  10. Function Points • If not LOC, then what?? • Many other metrics have been developed. Most of these metrics have major flaws. • Albrecht developed Function Point Analysis (FPA) in the late 70’s • This method assumes that “the amount of function to be provided by the application (program) can be estimated from an itemization of the major components of data to be used or provided by it”. • Albrecht believes that the complexity of a software project is determined by the functions of the software. T. E. Potok - University of Tennessee

  11. More on Function Points • FPA breaks the functionality of a software project into five areas. • Then for each area, the number of simple, average, and complex functions is determined, followed by a technical complexity factor calculated from 14 software system characteristics. • These 14 characteristics are tied to Halstead’s Software Science Metrics which are tied to Putnam’s cost estimation models, which are based on Norden’s Rayleigh Curve model first published in the late 50’s based on computer hardware development. T. E. Potok - University of Tennessee

  12. So LOC is not so bad after all • A big problem with Rayleigh Curves is that for early software development data, the curves appear to fit, but no one can explain why. • Beside that fact that function points have a shaky theoretical background, it is much harder to generate function points than LOC, therefore few use them. • Like the imperial measurement system, it is clearly inferior to the metric system, however, until people use the metric system, it will be of little relevance to most people. • Therefore, we will proceed with using line-of-code, being careful to minimize Jone’s issues T. E. Potok - University of Tennessee

  13. How long will the project take? • Estimate of the size of a project • Lines of code • Function points • Person-months • Based on requirements and experience or mathematical model T. E. Potok - University of Tennessee

  14. Software Development Life-cycle T. E. Potok - University of Tennessee

  15. Typical Life-cycle • Requirements • Design • Code • Test • Maintenance T. E. Potok - University of Tennessee

  16. Software Development Effort • A team of programmers puts effort into developing software • Ideally measured in person-months, with distinctions made for the type of effort • Design • Programming • Testing • Training • Often all that is available is the calendar time spend on developing software T. E. Potok - University of Tennessee

  17. Productivity • Team Productivity = Project Output/Project Effort • Programmer productivity = Programmer Output/Programmer Effort • Productivity typically measured in LOC/Person-month T. E. Potok - University of Tennessee

  18. Productivity Example • Need to produce 10,000 LOC, 10 KLOC. • Average programmer productivity = 200 LOC/Person-month (US average) • How many people do I need? • How long will it take? T. E. Potok - University of Tennessee

  19. Productivity Example T. E. Potok - University of Tennessee

  20. Productivity Example T. E. Potok - University of Tennessee

  21. People vs Months T. E. Potok - University of Tennessee

  22. Results • We can develop 10 KLOC in one month with 50 people, or • 2 People in 25 months • Assumes that the interaction among people does not results in a productivity penalty • Total of 50 Person-months of effort needed T. E. Potok - University of Tennessee

  23. Productivity Loading Curve Assumes two people can start immediately and work full-time on the project T. E. Potok - University of Tennessee

  24. Software development life-cycle • Early researchers found that labor distribution of hardware and software development follows a Rayleigh distribution Where t = month, tD = month at peak effort T. E. Potok - University of Tennessee

  25. Rayleigh Curves Peak effort at 7 months - Requiring 5 People 50 total person-months of effort required T. E. Potok - University of Tennessee

  26. Life-Cycle Requirements Design Code Test Maintenance T. E. Potok - University of Tennessee

  27. Putnam’s Slim Model Where S is the number of lines of code PR is the average productivity y is the Rayleigh loading curve t is time C is the state of technology K is the effort applied T. E. Potok - University of Tennessee

  28. Effort Comparisons T. E. Potok - University of Tennessee

  29. Productivity Studies T. E. Potok - University of Tennessee

  30. Background • Statistical Model • Little knowledge of the underlying system • Given there is sufficient data, and that the data is normally and independently distributed! • Regression provides a linear model that provides a least squares fit to the data T. E. Potok - University of Tennessee

  31. Linear Regression Where is an estimate of the mean of Y, and are numerical estimated of the parameters T. E. Potok - University of Tennessee

  32. Multiple Regression Similar processing to linear regression Provides the ability to determine what factors are most significant T. E. Potok - University of Tennessee

  33. Many early studies applied regression • Data gathered from multiple software project • Log-linear relationship found between project size and effort • Where PM are person-months, KLOC is thousands of lines of code T. E. Potok - University of Tennessee

  34. Typical Effort Vs Project Size Curve T. E. Potok - University of Tennessee

  35. Some interesting results • Diseconomy of scale - larger projects need proportionately more effort • Many factors influencing productivity • Early studies show people are the major factor in productivity • High productivity project have experienced, well trained people T. E. Potok - University of Tennessee

  36. Summary • Project Size Estimates • Software Development Life-Cycles • Software Development Productivity T. E. Potok - University of Tennessee

More Related