Slide 1

Slide 2

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

Slide 3

Partnership for Performance 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.eduhttp://www.ceti.cse.ohio-state.edu Partnership for Performance

Slide 4

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

Slide 5

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

Slide 6

Partnership for Performance 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 one 1. My definition: A systematic way of developing and maintaining software systems 1 www.cs.wpi.edu/~gpollice/cs562-s03/ExamDefinitions.html

Slide 7

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

Slide 8

Partnership for Performance 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 Discussion: How should these phases be weighted with respect to importance? Phases are groupings of activities in a process clustered around a common intent. Phases are not intended to be done in the order shown!

Slide 9

Partnership for Performance 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

Slide 10

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

Slide 11

College of Engineering The Ohio State University Structured Processes

Slide 12

Partnership for Performance A Baseline Structured Methodology The 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

Slide 13

Partnership for Performance 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

Slide 14

Partnership for Performance 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

Slide 15

Partnership for Performance 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

Slide 16

Partnership for Performance 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

Slide 17

Partnership for Performance 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

Slide 18

Partnership for Performance 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

Slide 19

Partnership for Performance 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

Slide 20

College of Engineering The Ohio State University Agile Processes

Slide 21

Partnership for Performance 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 (build the simplest thing, program collaboratively and visibly) Respect (value everybodys input) eXtreme Programming Beck et. Al. - Safari

Slide 22

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

Slide 23

Partnership for Performance 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

Slide 24

Partnership for Performance 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

Slide 25

College of Engineering The Ohio State University Agile vs. Structured: A Comparison

Slide 26

Partnership for Performance 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 the 2 approaches with respect to the above

Slide 27

Partnership for Performance 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

Slide 28

Heres 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

Slide 29

You Decide By Discovering the Project Shape Balancing Agility and Discipline, Boehm et. al. - Safari

Slide 30

Partnership for Performance 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

Slide 31

Partnership for Performance 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

Slide 32

College of Engineering The Ohio State University Thank you!