Toward so)ware engineering in prac0ce Claire Le Goues 15-214 April 27, 2017 1
Learning Goals • Broad scope of so;ware engineering • Importance of nontechnical issues • IntroducCon to key challenges 2
So)ware is Everywhere So)ware is Important (duh) 3
4
Gov’t example: So)ware is integral to DoD systems. QuoCng an Air Force lieutenant general, “The only thing you can do with an F- 22 that does not require so;ware is take a picture of it.” Crouching Dragon, Hidden So;ware: So;ware in Dod Weapon Systems (Ferguson, IEEE So;ware, 2001) 5
Failed So)ware Projects • SAGE (Semi-AutomaCc Ground Environment); started 1951, almost obsolete when finished in 1963; higher costs than Manha]an project • FBI Virtual Case File stopped in 2005 a;er 3 years and 170 M$ • London stock exchange stopped Taurus project 1993 a;er 11 years when 13200% over budget 6
7
8
9
10
“But we’re CMU students and we are really, really smart!” 11
What is engineering? And how is it different from hacking/ programming? So)ware Engineering ? 12
1968 NATO Conference on So)ware Engineering • ProvocaCve Title • Call for AcCon • “So;ware crisis” 13
Envy of Engineers • Producing a car/bridge – EsCmable costs and risks – Expected results – High quality • SeparaCon between plan and producCon • SimulaCon before construcCon • Quality assurance through measurement • PotenCal for automaCon 14
So)ware Engineering? „The Establishment and use of sound engineering principles in order to obtain economically so4ware that is reliable and works efficiently on real machines.” [Bauer 1975, S. 524] 15
16
What happened with HealthCare.gov? • Poor team and process coordinaCon. • Changing requirements. • Inadequate quality assurance infrastructure. • Architecture unsuited to the ulCmate system load. 17
Process 18
How to develop so)ware? 1. Discuss the so;ware that needs to be wri]en 2. Write some code 3. Test the code to idenCfy the defects 4. Debug to find causes of defects 5. Fix the defects 6. If not done, return to step 1 19
So)ware Process “The set of acCviCes and associated results that produce a so;ware product” What makes a good process? Sommerville, SE, ed. 8 20
100% Percent of Effort 0% Project Project Time beginning end 21
100% Trashing / Rework Percent of Effort ProducCve Coding 0% Project Project Time beginning end 22
100% Trashing / Rework Percent ProducCve Coding of Effort Process: Cost and Time esCmates, WriCng Requirements, Design, Change Management, Quality Assurance Plan, Development and IntegraCon Plan 0% Project Project Time beginning end 23
100% Trashing / Rework Percent of Effort ProducCve Coding Process 0% Project Project Time beginning end 24
Trashing / Rework 100% Percent of Effort ProducCve Coding Process 0% Project Project Time beginning end 25
Example process issues • Change Control: Mid-project informal agreement to changes suggested by customer or manager. Project scope expands 25-50% • Quality Assurance: Late detecCon of requirements and design issues. Test-debug-reimplement cycle limits development of new features. Release with known defects. • Defect Tracking: Bug reports collected informally, forgo]en • System IntegraCon: IntegraCon of independently developed components at the very end of the project. Interfaces out of sync. • Source Code Control: Accidentally overwri]en changes, lost work. • Scheduling: When project is behind, developers are asked weekly for new esCmates. 26
Process Costs n ( n − 1) / 2 communicaCon links 27
Process Costs 28
Large teams (29 people) create around six Cmes as many defects as small teams (3 people) and obviously burn through a lot more money. Yet, the large team appears to produce about the same mount of output in only an average of 12 days’ less Cme. This is a truly astonishing finding, through it fits with my personal experience on projects over 35 years. - Phillip Amour, 2006, CACM 49:9 29
Conway’s Law “Any organizaCon that designs a system (defined broadly) will produce a design whose structure is a copy of the organizaCon's communicaCon structure.” — Mel Conway, 1967 “If you have four groups working on a compiler, you'll get a 4-pass compiler.” 30
Congruence Module A Module C Module B 31
Microso)'s Small Team Prac0ces • Vision statement and milestones (2-4 month), no formal spec • Feature selecCon, prioriCzed by market, assigned to milestones • Modular architecture – Allows small federated teams (Conway's law) • Small teams of overlapping funcConal specialists Windows 95: 200 developers and testers, one of 250 products 32
Microso)'s Small Team Prac0ces • Feature Team – 3-8 developers (design, develop) – 3-8 testers (validaCon, verificaCon, usability, market analysis) – 1 program manager (vision, schedule communicaCon; leader, facilitator) – working on several features – 1 product manager (markeCng research, plan, betas) 33
Microso)'s Small Team Prac0ces • "Synchronize and stabilize" • For each milestone – 6-10 weeks feature development and conCnuous tesCng • frequent merges, daily builds – 2-5 weeks integraCon and tesCng (“zero- bug release”, external betas ) – 2-5 weeks buffer 34
Agile Prac0ces (e.g., Scrum) • 7+/-2 team members, collocated • self managing • Scrum master (potenCally shared among 2-3 teams) • Product owner / customer representaCve 35
Planning 36
Measuring Progress? • “I’m almost done with the X. Component A is almost fully implemented. Component B is finished except for the one stupid bug that someCmes crashes the server. I only need to find the one stupid bug, but that can probably be done in an a;ernoon?” 37
Almost Done Problem planned actual • Last 10% of work -> % completed 90% 100% 40% of Cme (or 20/80) reported progress • Make progress measureable • Avoid depending enCrely on developer esCmaCons Cme 38
Measuring Progress? • Developer judgment: x% done • Lines of code? • FuncConality? • Quality? 39
Project Planning Check progress Budget, IdenCfy constraints Personal, Deadlines Done? yes EsCmate project no parameters new ReesCmate project feature parameter requests acCviCes begin Define milestones Refine schedule no Create schedule Problem? yes renegoCate Technical review constraints Abort? 40
Reasons for Missed Deadlines • Insufficient staff (illnesses, staff turnover, ...) • Insufficient qualiCcaCon • UnanCcipated difficulCes • UnrealisCc Cme esCmaCons • UnanCcipated dependencies • Changing requirements, addiConal requirements • Especially in student projects – UnderesCmated Cme for learning technologies – Uneven work distribuCon – Last-minute panic. 41
Recognize Scheduling Issues Early • Monitoring and formal reporCng necessary – Establish who, when, what – Compare planned/actual data • Measurable milestones • Outdated schedules no meaningful management mechanism 42
Team produc0vity • Brook's law: Adding people to a late so;ware project makes it later. 43
Es0ma0ng Effort 44
45 π
Task: Es0mate Time • A: Java version of the Monopoly boardgame with Pi]sburgh street names – (you) • B: Bank smartphone app – (you with team of 4 developers, one experienced with iPhone apps, one with background in security) • EsCmate in 8h days (20 work days in a month, 220 per year) 46
Anda, Bente CD, Dag IK Sjøberg, and Audris Mockus. "Variability and reproducibility in so;ware engineering: A study of four companies that developed the same system." IEEE TransacLons on So4ware Engineering 47 35.3 (2009): 407-429.
Development Process 48
Risk and Uncertainty 49
Innova0ve vs Rou0ne Projects • Most so;ware projects are innovaCve – Google, Amazon, Ebay, Ne{lix – Vehicles and roboCcs – Language processing, Graphics • RouCne (now, not 10 years ago) – E-commerce websites? – Many control systems? – RouCne gets automated -> innovaCon cycle 50
Sources of Uncertainty • Unpredictable operaCng environment – Cybersecurity threats, device drivers – UnanCcipated usage scenarios • Limited predicCve power of models – HalCng, abstract interpretaCon, tesCng • Bounded raConality of humans – Designers, developers – Customers, users 51
Risk management • Key task of a project manager • IdenCfy and evaluate risks early • If necessary, plan miCgaCon strategies • Document results of risk analysis in project plan • Project risks: scheduling and resources – e.g., staff illness/turnover • Product risks: Quality and funcConality of the product – e.g. used component too slow • Business risks: – e.g., compeCtor introduces similar product 52
So)ware Architecture 53
Requirements Miracle / Architecture genius developers ImplementaCon 54
Recommend
More recommend
