COMS309Process

COMS309Process - Process David Weiss...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Process David Weiss weiss@cs.iastate.edu Problems in so7ware development •  Knowing what the customers want; knowing the requirements •  Predic?ng ?me to develop •  Predic?ng resources needed to develop •  Managing change •  Knowing when you’re done •  Designing to enable distribu?on of work •  Coordina?ng work •  Knowing what the value is (how much will I make) •  Tracking ?me, resources, quality, produc?vity, effec?veness, etc. COMS 309 Fall 2010 Process 2 Solving the problems: So7ware development processes •  Process: A set of ar?facts, ac?vi?es, and roles – Ac?vi?es produce ar?facts and are performed by roles – A designer produces a design document as part of crea?ng the design COMS 309 Fall 2010 Process 3 Characterizing processes: The Waterfall Model •  Process viewed as a sequen?al set of ac?vi?es –  Determine requirements, analyze & design, code, test, release –  Prototyping could be part of requirements determina?on Winston Royce COMS 309 Fall 2010 Process 4 Characterizing processes: The Spiral Model •  Process viewed as repea?ng cycles of increasing scale –  Iden?fy risks & values & determine (next set of) requirements, build next version by extension, increasing scale each ?me –  Early itera?ons may be prototypes COMS 309 Fall 2010 Process 5 Characterizing processes: The Itera9ve Model •  Process viewed as a sequence of itera?ons, each building on the last •  Build minimal useful subset, test, release, build next version by extension •  Early itera?ons may be prototypes IBM COMS 309 Fall 2010 Process 6 Variability in Processes •  Emphasis may vary on ar?facts, types of ar?facts, rules governing ac?vi?es, ga?ng, roles –  Examples: •  Form of requirements, design, test plan – Wri_en document, conforming to standard template, reviewed by peers and users using standard review process, benchmarked and configura?on controlled – Notes on a web site – Knowledge in the heads of the development team – Formalized inspec?ons with criteria for passing, e.g., Fagan inspec?ons or ac?ve reviews – Informal peer review mee?ng – Office mate reads it over – None •  Review procedures for documents and code •  Release criteria •  Coding style •  Project manager, systems engineer, architect, develop, tester •  The larger the project, the more formalized the process •  The more cri?cal the project, the more formalized the process –  Avionics, medical so7ware, automobile control COMS 309 Fall 2010 Process 7 Process Complexity and Project Complexity/Scale •  On large projects and complex projects, process helps assure that: –  Requirements are feasible –  Requirements express what the customer/market wants, or what the organiza?on wants to build –  Work assignments are properly appor?oned –  Work assignments result in code that works •  Individual module correctly implements its interface –  Interface specifier may not be implementer –  Work assignments result in code that works together –  Teams at different sites understand the interac?ons among their work and the work at other sites •  Our code uses yours, your code uses ours, you test what we do, etc. •  Modules work together to produce the desired result, i.e., requirements are met –  Work assignments can be completed in ?me for the project to meet its release date(s) COMS 309 Fall 2010 Process 8 COMS 309 Fall 2010 Process 9 When Process Complexity & Project Complexity/Scale Mismatch •  Developers feel frustrated –  “I want to write code, not documents” –  “I can’t understand what I’m supposed to do” –  “I’m afraid to touch this code” •  Progress is slowed – “I have to wait for that other team to finish” –  “I have to wait for my code to be inspected” –  “We have an integra?on problem” COMS 309 Fall 2010 Process 10 Common Concerns •  Verifica?on –  How do I know when an ar?fact is correct and ready for use and distribu?on? •  Common approaches: reviews and tes?ng •  Uncommon approaches: theorem proving, model checking •  Progress measurement –  How do you es?mate how long it will take to produce an ar?fact, and how much effort is needed? (?me ≠ effort) •  Common approaches: subjec?ve es?mate by role, es?mate by experience and analogy •  Uncommon approaches: model ­based es?mate, Delphi es?mate COMS 309 Fall 2010 Process 11 Measurement •  Produc?vity –  Lines of code per day? Objects per week? Changes per month? •  Quality –  Defects per KLOC? Field errors per installa?on? •  Time & Effort •  Cost •  Developer quality –  Who are my best developers? COMS 309 Fall 2010 Process 12 Predic?ng So7ware Development (50 sampled projects) Project Es9mates At Gate 1 200% Project Es9mates at Gate 2 Median 150% Rela9ve Schedule Range 100% 75% 50% Plans and Requirements Feasibility Product Design Detailed Design Development and Test Launch COMS 309 Fall 2010 Process 13 Distributed development, innova?on, new features, legacy adapta?on all contribute to delays Average additional time to complete than committed at gate 1 80% 70% 60% 50% 40% 30% 20% 10% 0% Single Site Multiple Site (Single Product Group) Multiple Product Group External Partnership Average additional time to complete than committed at gate 1 70% 60% 50% 40% 30% 20% 10% 0% Incremental release with small feature set, Bug Fixes and Quality enhancements Many new features; some invention. Adaptation of legacy system to new architecture High degree of invention required COMS 309 Fall 2010 Process 14 How Does Produc?vity Change Over Time? Produc9vity Trend for a Sample Project Core Group: Developers who made 80% of changes COMS 309 Fall 2010 Process Project Moved Offshore To Inexperienced Group 15 Tracking Progress (1) •  Views – Tracking by ar?fact development •  Ar?fact, e.g., design document, dra7ed, completed, reviewed – Tracking by progress through phases •  Phase in progress, completed, e.g., requirements determina?on in progress, completed – Tracking by changes •  Changes in progress, completed, e.g., all changes needed to revise user interface completed COMS 309 Fall 2010 Process 16 Tracking Progress (2) •  Views – Tracking by effort (?me) •  Effort (?me) expended vs. effort needed, e.g., 75 person hours expended vs. 100 needed – Tracking by progress through features •  Features in progress, completed, e.g., user data query capability completed – Tracking by task comple?on •  Tasks not yet started, in progress, completed, e.g., tes?ng of user interface in progress COMS 309 Fall 2010 Process 17 Risks •  Risk: event that could cause project to be late or to fail – Examples •  Interface to new hardware not defined in ?me for so7ware to be tested •  Key developer leaves the company •  Major last ­minute requirements change •  Switch to a new configura?on control tool •  New protocol to be used, unfamiliar to team COMS 309 Fall 2010 Process 18 Risk Mi'ga'on •  Mi?ga?on: strategy for reducing risk either through preven?ve measures or through alterna?ve plans –  Examples •  Interface to new hardware not defined in ?me for so7ware to be tested: Iden?fy alterna?ve; work early with hardware developers •  Key developer leaves the company: Train backup so that truck number is always at least 2 •  Major last ­minute requirements change: Iden?fy poten?al areas for requirements changes early and design for them; es?mate impact of changes on schedule •  Switch to a new configura?on control tool: Train team in new tool; find experienced users of tool to consult •  New protocol to be used, unfamiliar to team: Develop prototype to test protocol; train team early in new protocol •  Cri?cal path item is delayed: Iden?fy addi?onal resources who could help (but beware of Brooks’s Law) 19 COMS 309 Fall 2010 Process Project Plan •  Tasks to be performed •  Person(s) to perform tasks •  Deadline for each task •  Sequencing among tasks •  Risks and mi?ga?on strategies •  Usually owned by project manager •  Updated as project proceeds COMS 309 Fall 2010 Process 20 Plans vs. Reality (Ra?onal vs. Irra?onal) Plan A B E H C F I D G J K L …... M … COMS 309 Fall 2010 Process Z 21 … Plans vs. Reality (Ra?onal vs. Irra?onal) Reality A B E A’ H C’ K A’’ B’ H’ COMS 309 Fall 2010 Process 22 C F I D G J …... M L … C’’ D’ Z … Plans vs. Reality Making The Reality Seem Ra?onal •  Document as if it had been ra?onal – Readers can follow a sequen?al story •  Explain significant changeable decisions – What alterna?ves were (are) there? – Why did we choose A’’ rather than A or A’ •  Later readers (maintainers) understand the trade ­offs and can be guided by them COMS 309 Fall 2010 Process 23 Plans vs. Reality Documen?ng The Decisions Plan A’’ (A,A’) B’ (B) E H’ (H) C’’ (C,C,’) D’ (D) …... M Z 24 F I G J K … … L COMS 309 Fall 2010 Process Example 1 Requirements Should PolyFlow support languages other than Java and C/C++? a.  Yes. CM asked for support for some unusual scrip?ng language. b.  No. We don’t have resources for other languages. c.  It doesn’t ma_er. If we design PolyFlow correctly, we can add addi?onal languages later, without having to make the decision now. Resolu?on: We should design for this possibility, but at present only do Java and C/C++. COMS 309 Fall 2010 Process 25 Example 2 Design How do we map from the preprocessed code to the source; par?cularly the line numbers? There are three possible ways: a.  Use the preprocessor from the source code environment. e.g. GNU, the parser needs to be able to handle the GNU line tags. This is easiest alterna?ve; however, it increases instrumenta?on overhead and requires all supplemental files. Write our own par?al preprocessor which evaluates preprocessing condi?onals but not macros. This is more suitable for a hosted environment since it does not require all supplemental files; but may incur inaccuracy in coverage analysis. Modify the parser to perform par?al preprocessing at parse ?me including macro expansion. This involves marking preprocessing condi?onals in the AST. This is the hardest to implement but preserves coverage accuracy to the degree possible. b.  c.  Resolu'on: Use approach c, which gives the most accurate coverage results and reasonable instrumenta?on overhead at the expense of adding complexity to the AST. COMS 309 Fall 2010 Process 26 Example 3 Interface Design •  Does there need to be deleteGraph, deleteNode, and deleteEdge methods? a.  Yes, if the module performs memory management and returns handles to the various objects. b.  No, if the module returns references to the objects and does not perform memory management. •  Resolu?on: No, references will be used for a cleaner interface and simplifica?on of the module. COMS 309 Fall 2010 Process 27 Process Summary •  Process: A set of ar?facts, ac?vi?es, and roles designed to deal with issues in so7ware development •  Variability in process depends on people, problems, environment, fashion •  Every project entails risk and should have risk mi?ga?on strategy •  Progress tracking depends on process view •  Process is not ra?onal, but can be made to appear ra?onal in retrospect COMS 309 Fall 2010 Process 28 Terminology •  •  •  •  •  •  •  •  •  Process Ar?fact Role Ac?vity Risk Risk mi?ga?on Waterfall model Spiral model Itera?ve model COMS 309 Fall 2010 Process 29 What Process Will We Use? •  So7ware Product Line Engineering: A Family Based Development Process •  Family: “We consider a set of programs to cons?tute a family whenever it is worthwhile to study programs from the set by first studying the common proper?es of the set and then determining the special proper?es of the individual family members.” •  Product Line: A family of products designed to take advantage of its common aspects and predicted variabili?es COMS 309 Fall 2010 Process 30 A FAST Process Domain Engineering" Feedback" Product Engineering Environment" Product Engineering" Payback Products" COMS 309 Fall 2010 Process 31 A FAST Process Project Manager Systems Engineer Architect Developer Tester & Integrator Project Plan Commonality/Variability Analysis Domain Engineering! Decision Model Architecture:  ­ Module Guide  ­ Uses Rela9on  ­ Process Structure  ­ Interface Specifica9ons Test Plan Code Measures Product Engineering Environment! Product Engineering! Products! COMS 309 Fall 2010 Process 32 Project Roles Role ! Number of team members taking on the role! 1 Artifacts for which the role is responsible ! Commonality/variability analysis, decision model, use cases, preliminary screenshots Module, uses, process structures, interface specifications Module implementation Module tests, System generation and verification plan, test results report Economic model, project plan, project measures, retrospective report, optional poster Systems Engineer Architect 1 Developer Tester & Integrator >1 >1 Project Manager 1 COMS 309 Fall 2010 Process 33 Terminology •  •  •  •  •  •  •  •  •  •  •  •  •  •  Process Ar?fact Role Ac?vity Risk Risk mi?ga?on Waterfall model Spiral model Itera?ve model Family Product Line Domain Engineering Product Engineering Environment Product Engineering (aka Applica?on Engineering) COMS 309 Fall 2010 Process 34 Those who ignore history are condemned to repeat it  ­ George Santayana COMS 309 Fall 2010 Process 35 COMS 309 Fall 2010 Process 36 ...
View Full Document

Ask a homework question - tutors are online