Schach - Chapter 5 Page 104

1. SWE Tool: Stepwise Refinement Traditionally, a top-down approach is used to design software • Start with the initial problem statement • Break it into a few general steps • Take each "step", and break it further into more detailed steps • Keep repeating the process on each "step", until you get a breakdown that is pretty specific, and can be written more or less in pseudocode • Translate the pseudocode into real code Schach - Chapter 5 Page 104

2. Stepwise Refinement Example Problem: Determine the class average for a set of user-input test grades. (The number of grades is not known in advance, so the user will have to enter a special "sentinel" value to indicate the end of the input). • Initial breakdown into steps • Declare and initialize variables • Input grades (prompt user and allow input) • Compute class average and output result Doing all input before determining the sum and count would require having enough variables for every grade, but the number of grades is not known in advance, so the breakdown of "steps“ requires revision. • Breaking the "compute" step down further: • Compute: • add the grades • count the grades • divide the sum by the count • Revised breakdown into steps • Declare and initialize variables • Input grades (count & add as they are input)) • Compute class average and output result Schach - Chapter 5 Page 105

3. Stepwise Refinement Example (Continued) Breaking the steps into smaller steps: • Rough breakdown of the input step: • Loop until user enters sentinel value (e.g., -1) • Prompt user to enter a grade (-1 to quit) • Allow user to input a grade (store in a variable) • Add the grade into a “sum” variable • Add 1 to a counter to track # of grades • Breakdown for the declare/initialize step: • Initialize variables: • A grade variable (to store user entry) • A sum variable (initialized to 0) • A counter (initialized to 0) • Refinement (to look more like a loop): • Do • Prompt user to enter a grade (-1 to quit) • Allow user to input a grade (store in a variable) • Add the grade into a “sum” variable • Add 1 to a counter to track # of grades) • While user has NOT entered sentinel value • Breakdown for the compute/print step: • Divide sum by counter and store result • Print result Note that breaking the input step down first facilitates the later breakdown of the other steps • Further refinement (don’t add/count sentinel): • Do • Prompt user to enter a grade (-1 to quit) • Allow user to type in a grade (store in a variable) • If entered value is not the sentinel value • Add the grade into a “sum” variable • Add 1 to a counter to track # of grades • While user has NOT entered sentinel value The challenge with stepwise refinement is deciding which issues must be handled in the current refinement and which can be postponed until a later refinement Schach - Chapter 5 Page 106

4. SWE Tool: Cost-Benefit Analysis Decision-making in software development is often a case of weighing costs against benefits, but such cases are not always straightforward • Consider an established team of software developers, each with his/her own specialty: • Team leader Fred has extensive HCI and GUI experience • Team member Homer specializes in scientific computation • Team member Peter is the expert in database programming • All of the team’s recent projects have contained major database components, a decent interface, and virtually no heavy-duty math. To whom should Fred assign the DB components in the next project? To Peter, to ensure that deadlines are met? To Homer (under Peter’s supervision), to balance the division of labor on the team? To himself (under Peter’s supervision), to reflect what appear to be long-term trends in the industry, regardless of who is currently on the team? Schach - Chapter 5 Page 107

5. Software Metrics Measuring the quality of software is a difficult task, but efforts are being made to do so ISO 9126, an international standard for the evaluation of software, classifies software quality as a hierarchy of characteristics Schach - Chapter 5 Page 108

6. Task Prioritization As the project exits the planning stage and enters the implementation stage, tasks must be prioritized Traditional Pareto Prioritization Prioritize the project tasks with the notion that priorities shall remain basically unchanged Agile prioritization Revisit prioritization often, modifying as necessary Schach - Chapter 5 Page 109

7. Measuring Progress A variety of metrics may be used to determine how a project is progressing • Time invested • Lines of code • Reused lines of code • Changed lines of code • Number of modules • Size of database • Defect count Collecting measurements isn’t enough - reviewing them is essential to determining whether a project is on track Schach - Chapter 5 Page 110

8. Configuration Management, Integration, Builds With multiple developers on a software project, formal revision control becomes essential Subversionis a commercial revision control system (used at SIUE) that tracks integrated “trunk” systems, currently developing “branch” systems”, and milestone snapshots known as “tag” systems Schach - Chapter 5 Page 111

9. Check-Out/Check-In Focusing on version support for individual files, this type of configuration management system consists of two relatively independent tools • The repository tool stores versions of files and provides mechanisms for controlling the creation of new versions • The build tool automates the generation of derived files (e.g., object code, linked executables) Schach - Chapter 5 Page 112

10. Composition Developers repeatedly compose a system from its components and by selecting the desired version for each component By retaining multiple versions of individual software components, this configuration management model facilitates trying new approaches and reverting to old ones when necessary Schach - Chapter 5 Page 113

11. Change Set Another approach to configuration management is to keep track of the set of changes that have been made from configuration to configuration By focusing on the change sets instead of the overall components, the developers are often better able to determine logical dependencies within the system, as well as to ensure the system’s stability Schach - Chapter 5 Page 114