How to hear this lecture
Click on the icon:
to hear the
narration for each slide.
Partnership for Performance
Fisher logo
Software Engineering Process
fisher.osu.edu
Dr. Rajiv Ramnath
Director
Collaborative for Enterprise Transformation and Innovation (CETI)
Department of Computer Science and Engineering, College of Engineering
The Ohio State University
[email protected]
http://www.ceti.cse.ohio-state.edu
Partnership for Performance
Partnership for Performance
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
Table of Contents
• Software Engineering
Processes
• Structured Processes
• Agile Processes
• Agile vs. Structured
Comparison
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 one1.
• My definition: A systematic way of
developing and maintaining software
systems
1www.cs.wpi.edu/~gpollice/cs562-s03/ExamDefinitions.html
Partnership for Performance
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
Process Activities Are Grouped By Kinds of Activities – or Phases
•
Requirements Identification
•
•
•
•
•
Analysis
•
•
•
•
Building the system
Deployment
•
•
Overall structure
Detailed construction plan
Implementation
•
•
Understanding the domain (domain analysis)
Understanding the problem (problem analysis)
Understanding the solution (solution analysis)
Architecture and Design
•
•
•
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)
Putting the solution to work
Phases are groupings of activities in a
process clustered around a common
intent. Phases are not intended to be
done in the order shown!
Maintenance
•
Keeping the system working and useful
Discussion: How should these phases be “weighted” with respect to importance?
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
Partnership for Performance
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
Structured Processes
College of Engineering
The Ohio State University
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
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
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
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
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
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
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
Partnership for Performance
Developing Object Oriented Software – An Experience-Based
Approach, IBM Press - Handout
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
Agile Processes
College of Engineering
The Ohio State University
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 everybody’s input)
eXtreme Programming – Beck et. Al. - Safari
Partnership for Performance
Has Roles
•
•
•
•
•
Customer
Developer
Iteration Manager
Project Manager
Tester
eXtreme Programming – Beck et. Al. - Safari
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
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
Partnership for Performance
Agile vs. Structured: A Comparison
College of Engineering
The Ohio State University
Both Have Similar Elements – Goals, WorkProducts, 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
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
Partnership for Performance
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
You Decide By Discovering the Project “Shape”
Balancing Agility and Discipline, Boehm et. al. - Safari
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
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
Partnership for Performance
Thank you!
College of Engineering
The Ohio State University