How to hear this lecture

1. How to hear this lecture Click on the icon: to hear the narration for each slide. Partnership for Performance

2. fisher.osu.edu Fisher logo Software Engineering Process Dr. Rajiv Ramnath Director Collaborative for Enterprise Transformation and Innovation (CETI) Department of Computer Science and Engineering, College of Engineering The Ohio State University Ramnath.6@osu.edu http://www.ceti.cse.ohio-state.edu Partnership for Performance Partnership for Performance

3. How we got here … • Enterprises do things in order to compete and survive • IT can help them in specific ways, depending upon the enterprise • IT must be aligned with the business • How IT professionals work – i.e. their “process” must therefore also align with the business • So now - software engineering processes Partnership for Performance

4. Table of Contents • Software Engineering Processes • Structured Processes • Agile Processes • Agile vs. Structured Comparison Partnership for Performance

5. What is a Software Process • A set of partially ordered steps intended to reach a goal; in software engineering the goal is to build a software product or enhance an existing one1. • My definition: A systematic way of developing and maintaining software systems 1www.cs.wpi.edu/~gpollice/cs562-s03/ExamDefinitions.html Partnership for Performance

6. Why follow a process? • Repeatability • Predictability • Traceability • Improved quality through standardization • Permits continuous improvement • Enables systematic training • Builds confidence 1www.cs.wpi.edu/~gpollice/cs562-s03/ExamDefinitions.html Partnership for Performance

7. Process Activities Are Grouped By Kinds of Activities – or Phases • Requirements Identification • The problem to be solved • The features of the solution (functional and non-functional) • The business case (why solve the problem) • Acceptance criteria (a.k.a success criteria) • Analysis • Understanding the domain (domain analysis) • Understanding the problem (problem analysis) • Understanding the solution (solution analysis) • Architecture and Design • Overall structure • Detailed construction plan • Implementation • Building the system • Deployment • Putting the solution to work • Maintenance • Keeping the system working and useful Phases are groupings of activities in a process clustered around a common intent. Phases are not intended to be done in the order shown! Discussion: How should these phases be “weighted” with respect to importance? Partnership for Performance

8. Software Engineering Steps are Ordered in Time by Stages • Inception Stage • Approximate vision, business case, scope, high-level estimates • Elaboration Stage • Refined vision, iterative implementation of the core architecture, resolution of high risks, requirements identification, more realistic estimates • Construction Stage • Iterative implementation of remaining features, preparation for deployment • Transition Stage • Beta test, deployment Ref: Applying UML and Patterns – An Introduction to Object Oriented Analysis and Design, Craig Larman: Safari Partnership for Performance

9. There are 2 Broad Categories of Software Processes • Structured (Waterfall, CMM, CMMI, RUPP) • Agile (XP, Scrum) 1www.cs.wpi.edu/~gpollice/cs562-s03/ExamDefinitions.html Partnership for Performance

10. Structured Processes

11. A Baseline Structured MethodologyThe Iterative, Incremental, Workbook Centered, Object Oriented Software Development Process • Integrative (for its time) • Took the best elements of several practices that were existing at the time • Incremental • Build in pieces. Pros and cons? • Iterative • Get it right the next time. Repeat all phases. Pros and cons? • Scenario-driven • User-visible increments. Driven by value to the customer • Workbook centered, work-product oriented • Removes process rigidity • Object-oriented • Abstraction, Classes, Objects, Methods, Attributes, Inheritance, Polymorphism, Templates Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

12. Notion of Separate Roles • Customer • Business Developer • Planner (high-level) • Project Manager (detailed) • Team leader (technical) • Architect (responsible for high-level system design, shared across multiple projects) • Analyst (interface to business or customer) • Domain Expert (proxy for the customer, identifies the product line) • Developer (does low level design and writes the code) • Information developer (writes the documentation) • Human factors engineer (designs the UI, and also analyzes the interactions of the user with the system) • Tester • End user (Note: Different from the customer) • Product manager (is an Architect and a Domain Expert) • Engagement manager (is a Project Manager and a Business Developer) • Field Engineer (is a Architect and is a Developer) Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

13. Project workbook • What is it? • A logical repository of all the work products • How is it constructed? • HTML, Document, Text files etc. • How is it organized? • Hierarchically by subsystem • Linearly by increment Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

14. Work-products • What are they? • All the artifacts (“things”) that need to be created for a software development project • Each work-product captures a separate concern • Where are they kept? • In a work-book • Key concept – “Work-product orientation” • Constraint-driven - Address the right “concern” at each time • Process is tailored to project • The software is the “side-effect” not the documents! Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

15. Example Work Products • Requirements: • Problem statement (why – from a function point of view) • Business case (why – from the business point of view) • Storyboard (Narrative by users and other stakeholders) • Use cases (what the system is supposed to do) • Non-functional requirements (how the system is supposed to do it) • Prioritized requirements (when) • Acceptance plan (validation by the customer) • Project management: • Intended development process (overview of how the process should be conducted) • Resource plan (what resources – human as well as system – are available to the project) • Project schedule (the timeline of the project) • Release Plan (when features are given to the end-users) • Iteration Plan (what will be done in each development cycle) Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

16. Example Work products contd. • Analysis: • Guidelines (instructions on how to do the analysis) • Scenarios and Sequence diagrams (dynamic behavior) • Class model and descriptions (static structure) • User interface: • Guidelines (principles that the UI should follow) • Screen flows (transition from screen to screen) • Screen layouts (appearance) Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

17. Example Work products contd. • Design: • Guidelines • System architecture (high-level view of how the system meets the functional and non-functional requirements) • Target environment (a view of the System Architecture that shows what the system will be deployed on) • Subsystem model (a view of the System Architecture that shows the partitioning of the system into smaller systems) • Design object model and design class descriptions (detailed static structure of the system components) • Design scenarios and sequence diagrams (detailed dynamic behavior of the system components) • Design Alternatives • Implementation: • Guidelines (such as coding standards) • Source code • Testing: • Guidelines • Unit test cases • System test cases Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

18. Key Messages of Structured Processes • Scenario-driven • Discussion: What might be other drivers? • Work-products and work-product orientation • Management of risks • Incremental, Iterative • Scenario-driven – what might be others? • Separation of concerns: • Separable work-products. WHY? • Traceable • Discussion: Why maintain a traceability chain? • Verification (are things being done correctly) • Validation (is the right thing being done) Developing Object Oriented Software – An Experience-Based Approach, IBM Press - Handout Partnership for Performance

19. Agile Processes

20. An Agile Software Process - XP • Assumptions behind XP: • The cost of change is low • Everyone is always available, including the customer • Built around values, not techniques: • Communication (through sharing of tacit knowledge) • Simplicity (simple design and refactoring) • Feedback (immediate testing, planning after each short cycle) • Courage (buildthe simplest thing, program collaboratively and visibly) • Respect (value everybody’s input) eXtreme Programming – Beck et. Al. - Safari Partnership for Performance

21. Has Roles • Customer • Developer • Iteration Manager • Project Manager • Tester eXtreme Programming – Beck et. Al. - Safari Partnership for Performance

22. XP Activities,Categorized by Goals • Rapid feedback • Pair Programming • Retrospective session right after each iteration and release • Test Driven Development (WRITE TESTS FIRST and test a lot) • Planning right before every iteration and release • Continuous process ata sustainable pace • Continuous Integration (nightly builds) • Design by Improvement (no big upfront design) • Short Development Cycles (iterations and releases) • Shared understanding • Coding Standards • Collective Code Ownership • Joint Design • Whole team involvement in planning eXtreme Programming – Beck et. Al. - Safari Partnership for Performance

23. XP Work-products • Requirements: • User Stories • Tests • Analysis: • Informal diagrams (mostly in UML) • Design • Code • Unit tests • Project Management • Releases (1-3 months) • Iterations (2 weeks) eXtreme Programming – Beck et. Al. - Safari Partnership for Performance

24. Agile vs. Structured: A Comparison

25. Both Have Similar Elements – Goals, Work-Products, Concerns, Roles etc. • Problem and solution identification • Customer sign-off • Problem structure and dynamic behavior • Solution structure and dynamic behavior • Architecture • Detailed design • Traceability • Verification (is it done right?) • Validation (is the right thing being done?) • Risk management • Roles • Discussion: Compare the2 approaches with respect to the above Partnership for Performance

26. The Approaches Are Not Adversarial, but Have Tradeoffs: • Agile: • Goals: Monitor and adapt • Tacit knowledge and communication • Co-located, expert, trusted customer • Small size skilled teams • Dynamic team culture • Planning is a means to an end – but THERE IS LOTS OF PLANNING • Adds steps as needed • Planned: • Goals: Be predictable and guarantee assurance • Explicit, formal knowledge and communication • Contractual relationship with customer • Large teams with a range of skills • Comfort with stability • Process maturity and formal planning used to build trust • Handles non-functional requirements better • Subtracts steps if appropriate Balancing Agility and Discipline, Boehm et. al. - Safari Partnership for Performance

27. Here’s Where They Work Best (Agile vs. Structured) • Application: • Responding to change vs. high assurance and stability • Small teams vs. large teams • High-change, project-focused vs. Low-change and organization-focused • Management: • On site customers vs. scheduled-as-needed interactions • Internalized plans and qualitative control vs. documented plans and quantitative control • Tacit knowledge and informal communication vs. explicit documented knowledge • Technical: • Informal, unforeseeable requirements, vs. foreseeable evolution • Simple design on known architecture vs. extensive design, and importance given to architecture • Executable test cases as requirements vs. Documented test plans • Personnel • Experienced, co-located personnel vs. not always co-located personnel • Thriving on dynamism vs. thriving on order Partnership for Performance

28. You Decide By Discovering the Project “Shape” Balancing Agility and Discipline, Boehm et. al. - Safari Partnership for Performance

29. Risks in Planned and Agile Processes • Environmental risk (risks that result from the project's general environment) that apply to both kinds of processes: • The technology to be used has many uncertainties • Many diverse stakeholders need to be coordinated • Complex system of systems • Agile risks: risks that are specific to the use of agile methods • Scalability needs and criticality are high • Use of simple design might not work • There is too much personnel turnover or churn • There are not enough people skilled in agile methods • Plan-driven risks: risks that are specific to the use of plan-driven methods • There is rapid change, making long-term planning useless • Need for rapid results • There are emergent requirements • There are not enough people skilled in plan-driven methods Balancing Agility and Discipline, Boehm et. al. - Safari Partnership for Performance

30. Conclusion: The Software Process Should be Tailored to the Project! • One type of process does not fit all projects • Tailoring must be based on project “shape” • Requirements • System architecture • Development organization • Customer • Environment • Use a Mix of agile and structured methods, work-products and principles • Use risks to refine the tailoring Partnership for Performance

31. Thank you!