INFO 631 Prof. Glenn Booker

1. INFO 631Prof. Glenn Booker Week 6 – Tools and Review INFO631 Week 6

2. Overview • This week examines software development tools, both for support of technical aspects of development and maintenance as well as management concerns • We’ll wrap up with a summary of software-related metrics INFO631 Week 6

3. Tools INFO631 Week 6

4. Scope • Tools (e.g. software applications) to support the development and maintenance of software cover a wide range of purposes, from very specific to nearly all-encompassing • Some focus on the technical development activities (the development life cycle) • Others focus on support activities (project management, CM, etc.) INFO631 Week 6

5. CASE Tools • The first tools for managing the software development process were called CASE tools (e.g. Computer-Aided Software Development) • Upper CASE tools support the earlier parts of development – concept definition, requirements analysis, early design • Lower CASE tools support implementation and testing INFO631 Week 6

6. CASE Tools • The CASE Tools terminology is a bit dated, but you’ll still see it here and there • A classic CASE tool (both upper and lower) is IBM’s Rational tool suite • The key idea is to have a set of applications that can capture requirements for a system, map them into design drawings, implement those designs in code, and automate the testing of that code INFO631 Week 6

7. Visual Studio • A major player is Microsoft’s Visual Studio, which can handle many functions, depending on which version you get: • Architecture and modeling • Database development • IDE, debugging and diagnostics • Testing tools • Lab management INFO631 Week 6

8. Compilers and IDEs • A compiler turns source code into object files, which are linked to produce an executable application (e.g. MSWord.exe) • An Integrated Development Environment (IDE) goes beyond that to help manage the source code for a project, and possibly automate testing • The line between IDE and lower CASE tool gets pretty fuzzy! INFO631 Week 6

9. Support tools • Other tools provide support for the development process, such as tools for • Project management • Risk management • Configuration management • Change management INFO631 Week 6

10. Project management • Project management tools support the definition of project tasks, assigning resources to them, tracking project costs, and monitoring project progress • Sadly, MS Project is the most common tool for this purpose • Not particularly good, it just has lots of market share to wipe out competition INFO631 Week 6

11. Project management • Major categories of activities include • Project planning • Resource planning • Project tracking, analysis, and reporting • Project collaboration INFO631 Week 6

12. Risk management • Risk management tools support the four major risk management activities • Risk identification; identify what risks might realistically affect your project • Risk analysis; assess each risk, determine its probability and likely impact on the project • Risk response planning; what will you do if the risk occurs? INFO631 Week 6

13. Risk management • Risk monitoring and control; how do you manage each risk after it has occurred? • There are many commercial tools for risk management • I haven’t seen any widely used • Many RM tools are developed in-house INFO631 Week 6

14. Configuration management • Configuration management (CM) tools support the four major areas of CM • Configuration identification; what stuff are you tracking, and how? • Configuration control; fits with change control processes • Configuration audits; do you really have what you think you have? • Configuration reporting; status updates INFO631 Week 6

15. Configuration management • CM tools help manage the detailed complexity of keeping track of all the stuff in your project • Many involve SCM (software CM) or VCS (version control system) in their names INFO631 Week 6

16. Change management • Closely related to CM, change management is the process of controlling the evolution of your product • Inputs to change control include problem reports (bugs) as well as new features • The process determines which bugs are fixed, and features implemented • Changes are tracked through their inclusion in a new baseline version of your system INFO631 Week 6

17. Change management • Change management tools provide support for identification of proposed changes, analyzing them, and tracking them through implementation • Many of these tools are developed in-house to meet specific project needs and workflow processes INFO631 Week 6

18. Tools and measurement • So how does this connect to measurement? • Tools can be measured in terms of their costs and benefits to the project • What costs are involved? • Purchase cost • Maintenance cost • Training costs • Reduced productivity during implementation INFO631 Week 6

19. Tools and measurement • Do we use the tools? • Measure tool usage – how many people? • How many modules/risks/changes/tasks/etc. are being managed with the tools? • How do they benefit the organization? • Hmm, how could you measure benefits for tools? INFO631 Week 6

20. Tool Metrics • Recall some basic tool metrics from INFO 630: • How much (time, labor effort, cost) did our tools cost? Does that include training? • How much are the tools being used? • Are the tools meeting our needs? • Are they providing unexpected benefits? • How has use of the tools affected our productivity? Rework? Defect rate? • What do we have to do before and after implementing new tools to measure these things? INFO630 Week 2

21. Review INFO631 Week 6

22. Software Measurement Overview • We have studied the kinds of measurement methods and characteristics needed for software development and maintenance • We’ve used SPSS to do the icky math parts for us, and emphasized understanding what kinds of techniques are used, and how to interpret their results INFO631 Week 6

23. Life Cycle Model • Most of our concepts are based on some variation of the key software development activities • Requirements analysis • High and low level design • Coding or implementation • Various levels of testing INFO631 Week 6

24. Motivation • Measurement is critical from a project management perspective, to give us an objective basis for making decisions and answering questions • It also helps fulfill objectives of various quality and process models (CMMI, ISO 9000, etc.) INFO631 Week 6

25. Foundation • We defined measurements for each aspect of a process • The product we create • The resources (people) we use to create it • The processes they follow • The tools they use INFO631 Week 6

26. Statistical Concepts • Key statistical concepts used include • Measurement scales (nominal, etc.) • Ratio, proportion, fraction, percent, and rate • Modeling to see if there’s a statistically significant relationship between two measures • And assess R squared and the T statistic to help make that judgment INFO631 Week 6

27. Normal Distribution • We reviewed the normal distribution • The 95% rule for deciding how close to the mean is ‘close enough’ to be important • Six Sigma INFO631 Week 6

28. Core Measurements • The most common foundation for measurement is • Product Size (LOC or function points) • Effort and cost • Schedule • Problems and defects, including the defect density (defects/KLOC) INFO631 Week 6

29. Development and Defect Models • We considered development models to relate various key measures to each other (COCOMO) • And examined defect removal effectiveness INFO631 Week 6

30. Quality Management • We looked at key aspects of a Quality Management System and key development and maintenance metrics often used • Defect arrival rate • Fix backlog • Fix response time • Etc. INFO631 Week 6

31. Earned Value • We looked to the earned value method for comparing the effort, schedule, and work accomplished during a project • ACWP, BCWP, BCWS, CPI, SPI • If you still remember what they mean, you deserve a cookie! • Cost and schedule variances, schedule slip, estimate at completion INFO631 Week 6

32. GQ(I)M • We used the goal, question, indicator, and measure methodology to: • Help understand why we are collecting the measures • Define exactly what they mean • Where they come from • How they will be presented (the indicators) INFO631 Week 6

33. Defect Analysis • Defect analysis looked at: • When a defect was created (“injected”) • When a defect was found (“detection”) • What caused a defect (type of defect, and/or orthogonal defect classification) • How a defect was found (triggers) INFO631 Week 6

34. Defect Removal Modeling • Defect removal modeling defined the defect removal effectiveness (DRE) for any set of adjacent life cycle phases • Then the Rayleigh model provided a mathematical expression to help predict how many more defects will be found during development INFO631 Week 6

35. Reliability Modeling • Static reliability models provide a detailed estimate of defects per module based on size and complexity metrics • Dynamic reliability models provide a broader estimate of the defects in the entire project, such as the Rayleigh model (from the Weibull model) INFO631 Week 6

36. Reliability Modeling • Lots of other types of reliability models were covered briefly • Exponential model for testing • Time Between Failure Models • Fault Count Models • Time Between Failures INFO631 Week 6

37. Customer Satisfaction • We discussed ways of conducting Customer Satisfaction Surveys • Statistical sampling methods • How to calculate simple random sample size • Analysis of customer satisfaction data INFO631 Week 6

38. Testing Measurements • We discussed approaches to testing • Testing measurements beyond just defects found • Structural and predicate testing • Integration testing strategies INFO631 Week 6

39. Object Oriented Measures • We covered six common OO metrics • Weighted methods per class (WMC) • Response for a class (RFC) • Lack of cohesion of methods (LCOM) • Coupling between objects (CBO) • Depth of inheritance tree (DIT) • Number of children (NOC) INFO631 Week 6

40. Complexity Metrics • We examined internal and external complexity metrics • Internal – size, the Halstead metrics, cyclomatic complexity, knots • External – data structure, fan in, fan out, Henry and Kafura, Shepperd • And looked at availability metrics INFO631 Week 6

41. Quality Assessment and Audit • We looked at quality assessments and quality audits, and their common structure • Preparation phase • Evaluation phase • Summarization phase • And examined the larger view of the Process Assessment Cycle INFO631 Week 6

42. CMMI Structure • We reviewed the structure of the CMMI process model • Staged versus continuous models • Process Areas and their goals • And examined the role of software development and management tools • And that’s it! INFO631 Week 6