Process. CMPUT 401 Module 04. Department of Computing Science University of Alberta Ken Wong, 2008

Transcription

1 Process CMPUT 401 Module 04 Department of Computing Science University of Alberta Ken Wong, 2008

2 Software Process How work in building software is done: e.g., waterfall process e.g., object-oriented development e.g., requirements inspection process institutes a set of rules 2

3 Software Process Typical elements: goal phases activities tasks roles work products like products, processes are also designed (planned) for a particular project guidelines measurement 3

4 Software life cycle * Process group * Process uses * Work Product * Phase * produces * Activity Task consumes * Resource Participant Time Money 4

5 Software Process Discussion: When would we need more discipline in constructing software? discipline, formality, maturity how to assess? 5

6 Software Process Example factors influencing formality : number of people involved size/complexity of software duration of the project level of quality needed regulations 6

7 Process Maturity Maturity levels: (1) initial ad hoc or chaotic, depends on heroism, ~60% (2) repeatable basic project planning, reviews, ~25% (3) defined process is documented, and institutionalized, ~13% (4) managed quality goals, measurement (5) optimizing process itself improves over time how is your company? 7

8 Capability Maturity Model Selected Key Process Requirements management Project planning Project monitoring and control Configuration management Measurement and analysis Process and product quality assurance Product integration Organizational process definition Organizational process focus Integrated project management Risk management Organizational process performance Causal analysis and resolution Area Engineering Project management Project management Support Support Support Engineering Process management Process management Project management Project management Process management Support Maturity [SEI] 8

9 Capability Maturity Model Issues: overhead process versus product focus suited for large, regulated organizations certifying organizational compliance 9

10 Process Design Issues: configure a process for the needs of the project no single specific process works right for every kind of product and level of quality extreme programming? configure a process based on the artifacts to be produced what is produced for requirements, design, etc. templates and tools 10

11 Process Design Prime directive: Only do those activities and produce those artifacts that directly lead to delivering value to your customers and stakeholders. G. Pollice et al. if we don t do, will something bad happen? e.g., architecture design, documentation 11

12 Process Enactment Issues: following a process does not always guarantee a quality product chosen process may be wrong for the project how to understand and follow a process process models, workflow engine? 12

13 Software Life Cycle End-to-end: what activities and tasks? what dependencies between activities? how to schedule activities? 13

14 Software Life Cycle Requirements Analysis System Design What is the problem? What is the solution? Problem Domain Program Design Program Implementation What are the mechanisms that best implement the solution? How is the solution constructed? Implementation Domain Testing Is the problem solved? Delivery Can the customer use the solution? Maintenance Are enhancements needed? 14

15 Life Cycle Models Many variations: waterfall model Royse (1970) V model Jensen & Tonies (1979) sawtooth model Rowen (1990) spiral model Boehm (1987) 15

16 Waterfall Model Requirements Specification Architectural Design Detailed Design Coding and Unit Testing Integration and Testing ingrained? Delivery and Installation Maintenance and Support 16

17 System Requirements Analysis V Model Operation Software Requirements Elicitation Client Acceptance Requirements Analysis System Integration & Test Preliminary Design Component Integration & Test Detailed Design Unit Test Implementation 17

18 Sawtooth Model System Requirements Analysis Prototype Demonstration 1 Prototype Demonstration 2 Client Client Acceptance Developer System Integration & Test Requirements Analysis Component Integration & Test Preliminary Design Detailed Design Unit Test Implementation 18

19 Spiral Model Each iteration has phases: define goals, alternatives, and constraints determine goals, alternatives, and constraints evaluate alternatives and assess risks evaluate alternatives, identify and resolve risks develop and test prototype plan next cycle plan develop and test 19

20 Spiral Model Iterations: concepts requirements determine goals, alternatives, and constraints evaluate alternatives and assess risks system design detailed design code test integration acceptance evolution plan develop and test two forms of iteration 20

21 Unified Process Life cycle model: proposed by Jacobson, Booch, Rumbaugh similar to the Boehm spiral model series of cycles ending with a release each cycle has four phases each phase may involve one or more iterations may be customized e.g., Rational Unified Process 21

22 Unified Process Four phases: inception e.g., requirements, planning elaboration e.g., architecture, unit tests construction e.g., design, implementation, testing transition e.g., beta release, postmortem cycles and iterations, similar to spiral model 22

23 Unified Process Deliverables Requirements Analysis/Design Implementation Test Management Inception scope and make case to build product vision/context features list use cases domain model glossary candidate architecture prototype plan risks list ROI Elaboration determine ability to build the product use cases domain model mockup UI architecture baseline subsystems classes code classes unit tests test plans integration tests system tests plan risks list defect tracking version control Construction build product that works successfully for customer use cases architecture code classes unit tests integration tests system tests defect tracking version control Transition deliver functional product to customer use cases architecture user documents beta tests acceptance tests defect tracking version control 23

24 Unified Process Outcomes of each phase: inception stakeholders agree on scope candidate architecture handles key requirements strong business case justifies continued development elaboration use cases are qualified, prioritized, and detailed architecture serves as foundation for construction project plan describes how construction will proceed 24

25 Unified Process Outcomes of each phase: construction use cases are updated architecture model is updated running, functional, tested prototype transition fully working, deployed system user documents (external deliverable) use cases and architecture (internal deliverable) 25

26 Unified Process Model-driven: domain model use case model realized by analysis model specified by design model distributed by deployment model architecture implemented by implementation model verified by test model 26

27 Unified Process Model domain use case analysis design deployment implementation UML domain-level class diagram use case diagram; use case package stereotyped class diagram; analysis package class, sequence, state, activity diagrams; design package deployment diagram; deployment package component diagram 27

28 UML Package DecisionSubsystem Criterion assesses Alternative * * * DesignProblem solvableby based-on SubTask * resolvedby Decision ActionItem Task subtasks implementedby 28

29 UML Packages Compiler SyntacticAnalyzer LexicalAnalyzer SemanticAnalyzer Optimizer CodeGenerator Repository ParseTree SymbolTable SourceLevelDebugger SyntacticEditor 29

30 UML Deployment Diagram mymac:mac :Netscape :UnixHost :WebServer apc:pc :IExplorer :UnixHost :Database software components and hardware nodes 30

31 UML Component WebServer HttpRequest File URL DBQuery DBResult GET POST 31

32 Agile Methods Valued More individuals and interactions working software customer collaboration responding to change Valued Less processes and tools documentation contract negotiation following a plan 32

33 Agile Methods Principles: individuals and interactions trust motivated individuals face-to-face conversation best work emerges from self-organizing teams team reflects on and adjusts their behavior promote constant, sustainable pace working software working software as the main measure of progress continuous, frequent delivery of value 33

34 Agile Methods Principles: customer collaboration satisfy customer early customers and developers work together responding to change welcome changing requirements, even late technical excellence and good design simplicity art of maximizing work not done 34

35 extreme Programming (XP) Practices for programmer welfare: 40-hour week work no more than 40 hours a week; never work overtime a second week in a row your experiences? 35

36 extreme Programming (XP) Practices for feedback: planning game determine scope of next release by combining business priorities and technical estimates testing write automated unit tests (first); customers write tests to show that features are finished pair programming have all production code written with two programmers at one machine on-site customer include real, live user on the team, full-time to answer questions 36

37 extreme Programming (XP) Practices for continuity: small releases put simple system into production quickly, then release new versions on a very short cycle refactoring restructure the system to improve its design, simplicity, or flexibility continuous integration integrate and build the system many times a day, every time a task is done 37

38 extreme Programming (XP) Practices for shared understanding: metaphor guide development with a shared story of how the system works simple design design the system as simply as possible; remove extra complexity when discovered collective ownership anyone can change any code anywhere in the system at any time coding standards write all code according to rules that enhance communication and understanding through code 38

39 extreme Programming (XP) Process practices: ~15 min standup meeting starts each day move people around write user stories use burndown chart [extremeprogramming.org] 39

40 extreme Programming Original XP project: at Daimler Chrysler, it took people 2 years to write and deploy a system that a team of 30 had failed to deliver in the prior 4 years Discussion: what s the controversy? 40

41 extreme Programming (XP) Controversies: all or nothing are subsets still effective? scalability teams of more than 20 members? reworking no real upfront design? pair programming effective? personality conflicts? ergonomics? customer on-site possible? 41

42 Unified versus Agile (XP) Discussion: What is common? What is different? both require discipline 42

43 Unified versus Agile (XP) Unified Process Extreme Programming Communication Design Iteration Project/Team Size UML / use cases top-down from models / architecture centric cycles of phases / iterations in each phase suited for large projects face-to-face / user stories / code bottom-up from code / metaphor / trials series of releases / iterations in each release suited for small projects 43

44 Agile Methods New product development game: environment of tight competition e.g., Japanese manufacturing (Fuji, Toyota) Nonaka and Takeuchi, 1986 assemble resources for cross-functional team best people in research, engineering, finance, support, sales, marketing, inventory, etc. tell team to create the next great thing must be a tangible product, not a proposal counting on team to finish in a few months not interrupted with reporting 44

45 Agile Methods Scrum: series of sprints, homing in on project goal each sprint is time-boxed, 2 to 4 weeks long work within each sprint is fixed each task in a sprint takes 1 to 16 hours each sprint ends in running, shippable version each is professionally done done stopping early still produces a high-value product 45

46 Agile Methods Scrum: product backlog all work to be done (requirements, defect fixes) reducing work in progress focus and bring work to closure, rather than starting new work and maximizing parallelism slowing down to go fast make estimates from actual completed work 46

47 Agile Methods Scrum: Scrum master role leader facilitates creativity and team involvement focuses on what to do, and planning, not how make quality compromises explicit between between upper managers and engineers teaches customer how to drive the team 47

48 Agile Methods Lots of variations: Dynamic System Development Method Faulkner et al. Adaptive Software Development Highsmith Crystal Clear Cockburn Lean Software Development Poppendieck Agile Unified Process Ambler 48

49 Agile Benefits Shine survey (131 respondents): productivity was better or much better 93% costs were reduced or much reduced 49% costs unchanged 46% quality was better or much better 88% bus. satisfaction was better or much better 83% 49

50 References Object-Oriented Software Engineering B. Bruegge & A. Dutoit Prentice-Hall, 2000 Software Development for Small Teams G. Pollice et al. Addison-Wesley,

51 References The Unified Process Explained K. Scott Addison-Wesley, 2002 Extreme Programmming Explained K. Beck Addison-Wesley,

52 References Scaling Software Agility D. Leffingwell Addison-Wesley, 2007 Pair Programming Illuminated L. Williams and R. Kessler Addison-Wesley,