Third Hour Lecture 10:30 – 11:20 am September 8

1. Third Hour Lecture10:30 – 11:20 am September 8 Improving Software Economics (continuing from Chapter 3 of Royce’ book)

2. Five Economy ImprovementDimensions • Reducing the size of the software. • Improving the development process. • Using more-skilled personnel and better teams. • Using better environments (tools) for software development. • Trading off, or backing off, on quality thresholds.

3. Productive activity Prototyping Modeling Coding Debugging Documentation Overhead activity Plan preparation Documentation Progress monitoring Risk assessment Financial assessment Configuration control Quality assessment Integration Testing Late scrap and rework Management Training Administration Improving Software Development Processes

4. Three Levels of Process

5. Three Dimensions for Schedule Improvement • In an N-step process, improve the efficiency of each step. • In an N-step process, eliminate some steps to create an M-step process. • In an N-step process use more currency in the activities.

6. Sequential Steps • Every instance of rework introduces a sequential set of tasks. • Start with analysis, design, coding, and testing of a feature. • Suppose then a fault is found. • Then we must repeat the analysis, design, etc… • These rework task sequences are the primary obstacle to schedule compression.

7. Improving Team Effectiveness • Four Team Management Maxims. • Five Project Staffing Principles. • Five Attributes of Successful Software Managers.

8. Four Maxims of Team Management • A well-managed project can succeed with a nominal engineering team. • A mismanaged project will fail, even with an expert team. • A well-architected system can built by a nominal team. • A poorly-architected system will flounder even with an expert team.

9. Five Attributes of Successful Software Project Managers • Hiring skills. • Right persons in the right jobs. • Customer-interface skills. • Avoiding adversarial relationships. • Decision-making skills. • Timely decisions, objective, unbiased and reasoned. • Team-building skills. • Trust, motivating, nurturing, tolerant of prima-donnas, synthesizes diverse opinions into team direction. • Selling skills. • Sell stakeholders, decision-makers, job candidates, sell changes of status-quo to disbelievers, sell achievements toward objectives. • Selling requires continuous negotiation, compromise, and empathy.

10. Five Staffing Principles • Principle of top talent. • Use better and fewer people. • Principle of job matching. • Fit the tasks to the skills and motivations of the people. • Principle of career progression. • Help people to self-actualize. • Principle of team balance. • Select people who will complement and harmonize. • Hire a mix of raw skills, intelligence, objectivity, creativity, analytical thinking, psychological makeup, leaders, followers, risk-takers, conservatives, visionaries and nitpickers, cynics and optimists, experience and youth. • Principle of phase-out. • Replace misfits early. • Phase down without delay.

11. Improving Automation through Software Environments • Tools • Planning tools, requirements management tools, visual modeling tools, compilers, editors, debuggers, quality assurance analysis tools, test tools, and user interfaces, configuration management tools. • Round Trip Engineering Environment • Forward engineering tools (compilers, linkers, etc. are common. • Round trip engineering tools are needed to support iterative development processes. • Requirements management, document automation, automated regression testing, continuous and integrated change management, and feature/defect tracking.

12. Achieving Required Quality • Five Key Practices • Focus on driving requirements. • Use of metrics and indicators to measure progress and quality of architecture. • Provision of integrated life-cycle configuration control and change management. • Use of visual modeling and higher level languages. • Early and continuous insight into performance issues through demonstration-based evaluations.

13. Quality Improvements with a Modern Process

14. Performance Assessment in a Typical Project • Project inception. Proposed design is asserted to be low risk with adequate performance margin. • Initial Design Review. Optimistic assessment based on paper analysis or rough simulation. Operating system overhead, database management overhead, etc., all underestimated. • Mid-life-cycle Design Review. Initial tests whittle away at margins. Early optimism exposed. • Integration and Test. Serious problems uncovered. Margins exceeded. Fundamental changes in software architecture needed. Additional hardware or reduced functionality often required.

15. Peer Inspections • Inspections accelerate transferring skills and knowledge to junior programmers. • Inspections are a good vehicle for holding authors accountable for quality projects. • Inspections are usually less helpful than primary quality mechanisms. • Major milestone demonstrations. • Environment tools (compilers, analyzers, automated test suites) that ensure representation rigor, consistency, completeness, and change control. • Inspections should focus on critical components only. • Inspections usually do NOT uncover three types of serious problems. • Performance bottlenecks. • Serious control issues - deadlocks, races, resource contention. • Architectural flaws – scalability, reliability, interoperability.

16. Assignment for Next Class Meeting • Finish reading Chapter 3 of Royce’ book, on Software Economics. • Learn the three schedule improvement dimensions. • Learn the four maxims of team management. • Learn the five staffing principles. • Learn the five successful software manager attributes. • Learn the five key practices for software quality. • Learn the four stages of typical project performance assessment. • Learn the three major problem area failures of peer inspections.