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
[email protected]://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!