Software Process In The Real World

1
Software Process In The Real World

• Chris Platner

2
Questions

• Why Should I Care?
• What is Software Process?
• How is it used in the Real World?

3
Why Should I Care?
4
Why Should I Care?
if (you_write_software) you_have_a_software_pr
ocess TRUE
5
Do You Know Enough?

• For any software project, you must know at least
  the following
• Where are the files going to be stored?
• Will you complete the design first, then code, or
  use some iterative approach?
• How will you handle defects?
• Once more people are added, a whole host of
  coordination issues arise
• but, will this really make me a better software
  developer?

6
You dont have time to fit it all in

• time people features quality 3.0
• Example .95 .9 .75 .4 3.0

7
Can You Communicate?

• Most software is developed by teams, where
  individuals must communicate in a technical
  manner.
• Fun Exercise

8
What is Software Process?
9
What is Software Process?

• A way for successfully getting work done
• A way to avoid fears and mitigate risks
• A way to (hopefully) feel good about what you do

10
What is Software Process?

• Questions that software process should answer
• Low-Level
• When is the next build of the product?
• How do we handle defects?
• When do we branch our code?
• How do we communicate
• With developers in other divisions?
• Amongst ourselves
• Must we have status meetings?
• High-Level
• When is it time to ship the product?
• How and when do we communicate with other
  internal departments, like sales, marketing,
  technical support?
• What artifacts are important to keep for future
  reference?

11
Risks

• What is the most damage that failure of our
  product could cause?
• Loss of comfort
• Loss of discretionary money
• Loss of essential money
• Loss of life
• Each of these requires a different amount of
  process, because extra work may need to be done
  to reduce the chance of loss.
• (Risks are from Alistair Cockburns Crystal
  Methodologies)

12
Fears

• What if people cant or wont communicate?
• What if code gets too messy to be maintained?
• What if the system architecture deteriorates into
  a big ball of mud?
• . . .
• All methodologies are based on fear. Kent Beck

13
Outside of the Software Process

• Business Issues and Processes
• What customers should we target (market
  segments)?
• Idea generation (new product ideas)
• Market windows
• Development Issues
• What language should be used?
• People Issues
• Who will be on my team?

14
Software Processes

• Waterfall
• Capabilities Maturity Model (CMM)
• Extreme Programming (XP)
• Crystal
• SCRUM
• Open Source
• Others

15
Waterfall

• A Linear Development Methodology
• Each of the steps performed in order, with
  minimal feedback between each step
  Requirements, Analysis, Design, Implementation,
  Test, Maintenance
• Even though it has a lot of disadvantages, it is
  still
• Advantages
• Emphasis on planning
• Sometimes used on fixed-price contracts where
  estimates must be given up front.
• Disadvantages
• Requires knowing all the requirements up front,
  with no allowance for change.
• Problems with phases are often caught too late,
  such as requirements problems detected during
  coding.
• Dont use it!

16
Capabilities Maturity Model (CMM)

• From the Software Engineering Institute at
  Carnegie Mellon
• Really a process framework that encompasses 5
  levels of process maturity
• Initial Ad hoc, chaotic - Success depends on
  heroics.
• Repeatable Basic cost, schedule, and
  functionality tracking. Can repeat earlier
  successes on projects with similar applications.
  
• Defined Software process for management and
  engineering activities is documented,
  standardized, and integrated into a standard
  software process for the organization. All
  projects use an approved, tailored version of the
  organization's standard software process for
  developing and maintaining software.
• Managed Detailed measures of the software
  process and product quality are collected. Both
  the software process and products are
  quantitatively understood and controlled.
• Optimizing Continuous process improvement is
  enabled by quantitative feedback from the process
  and from piloting innovative ideas and
  technologies

17
Capabilities Maturity Model (CMM)

• Focuses on 18 Key Process Areas (KPAs)
• Repeatable (Level 2) Requirements Management,
  Software Project Planning, Software Project
  Tracking and Oversight, Software Subcontract
  Management, Software Quality Assurance, Software
  Configuration Management
• Defined (Level 3) Organization Process Focus,
  Organization Process Definition, Training
  Program, Integrated Software Management, Software
  Product Engineering, Inter-group Coordination,
  Peer Reviews
• Advantages
• Respected in the industry
• Tailorable to each business and project
• Drawbacks
• Tends to involve more ceremony (more writing,
  etc.)
• Assumes the rate of change in many areas is low
• Requirements, schedule pressure, quality, etc.
• See http//www.sei.cmu.edu for more information

18
Extreme Programming (XP)

• Grew out of experiences at Chrysler (Kent Beck,
  et al)
• The primary target was small teams in one
  location, coding to requirements that may be
  changing
• Many of the recommendations are familiar, but
  depend on high-quality communication
  (face-to-face), rather than high-overhead modes
  (documents)

19
Extreme Programming (XP)

• XP Requirements
• Team
• The whole team must be small and be able to sit
  and work in a single room with the customer
• Planning
• Customer Stories, Release Planning, Iteration
  Planning (2 week iterations), Small Releases,
  Simple Design, Automated Customer/Acceptance
  tests
• Development
• Test-Driven Development (automated unit tests),
  Continuous Integration (multiple builds per day),
  Refactoring (design improvement), Coding
  Standards
• Collective Code Ownership, Pair Programming
• See http//www.xprogramming.com,
  http//www.extremeprogramming.org

20
Extreme Programming (XP)

• Advantages
• Works great for small co-located teams
• Teams using XP can be extremely productive,
  perhaps more so than those using any other
  methodology
• Drawbacks
• QA departments see it as too light
• No documentation artifacts after projects are
  done
• Wont work well for large teams, distributed
  teams, or teams not willing to pair program

21
Crystal

• A family of methodologies designed by Alistair
  Cockburn
• There are different methodologies for different
  sizes and kinds of projects, each corresponding
  to a type of crystal Clear, Yellow, Orange, Red
• Clear 3-8 people in one office
• Yellow 8-20 people, same building
• Orange 25-40 people, same building
• http//alistair.cockburn.us/

22
SCRUM

• Iterative, Incremental, Adaptive
• Uses 3 to 8 time periods called Sprints that each
  last about a month. Design and implementation
  tasks are broken up over the sprints.
• A short daily scrum meeting is held each morning
  to find out what happened the day before, resolve
  blocking issues, and to plan for the next day.
• At the end of a sprint, there is a demo to show
  progress.
• See http//www.controlchaos.com/

23
Open Source Process

• GNU.org See http//www.gnu.org/prep/maintain.htm
  l
• Mozilla.org See http//www.mozilla.org/hacking/
• The Cathedral and the Bazaar (http//en.wikipedi
  a.org/wiki/The_Cathedral_and_the_Bazaar)

24
What About?

• Agile Methodologies (http//www.agilealliance.org)
  
• Personal Software Process (PSP) and Team Software
  Process (TSP)
• From Watts Humphrey and the crew that developed
  the CMM.
• ISO 12207
• Grew out of Department of Defense software
  standards - MIL-STD-1679, DoD-STD-2167A,
  MIL-STD-498
• Rational Unified Process (RUP)
• From Grady Booch, Jim Rumbaugh, and Ivar Jacobson
  (The Three Amigos)
• It is a process framework

25
The Real World
26
Why Should I Care?

• Do you like to code? The kind of process used
  affects the amount of non-programming work you
  do.
• You may find yourself in meetings and writing
  documents
• For very large projects, the total output of
  debugged code can be as low as 10 lines per day
• Do you want projects you work on to be
  successful?
• Making projects work requires management and
  software process

27
The Real World

• Processes may not be strictly followed.
• Different managers will like different processes
• New processes may be enforced mid-project
• An outspoken team member may hijack the process

28
Fears and Risks Revisited

• What if we lose key team members?
• What if the defect insertion rate runs away?
• What if management cant see progress?
• What if people cant or wont communicate?
• What if code gets too messy to be maintained?
• What if the system architecture deteriorates into
  a big ball of mud?
• What if management changes?
• What if were working on the wrong solution?

29
There Is Hope

• Must we be shackled to process?
• No! People are more important. (See Facts and
  Fallacies of Software Engineering, Fact 1, by
  Robert L. Glass).

30
References

• The Mythical Man-Month, Fred Brooks, 1995
  (anniversary edition)
• Fact and Fallacies of Software Engineering,
  Robert L. Glass, 2003
• A reminder of what works and what doesnt in
  software engineering.
• Dynamics of Software Development, Jim McCarthy,
  1995
• Extreme Programming Explained Embrace Change,
  Kent Beck, 2000
• Ruminations on C, Andrew Koenig, Barbara Moo,
  1997
• Excellent discussion of why small projects are
  often successful, while larger ones are not.
  Read all of chapter 2.
• Agile Software Development, Alistair Cockburn,
  2002
• Great introduction to agile development.

31
References

• Debugging the Development Process, Steve Maguire,
  1994
• Software Project Survival Guide, Steve McConnell,
  1998
• If you want to be a manager, or understand
  managers, Steves books are must-haves.
• Rapid Development Taming Wild Software
  Schedules, Steve McConnell, 1996
• Martin Fowlers Writings Many interesting
  articles on agile methodologies. See
  http//www.martinfowler.com, http//thoughtworks.c
  om/library/newMethodology.pdf

32
QA