Wash%20U%20DARPA%20PCES%20%20PI%20Meeting%20Report

1
CSE 436Personal Software Processes, Software
Development Models
Ron K. Cytron http//www.cs.wustl.edu/cytron/cse
436/
9 October 2006
2
Today

• Personal Software Processes
• Groups present requirements (postponed to next
  week)
• How did you elicit the requirements?
• How are the requirements structured?
• What interactions do you require with the
  customer to firm up the requirements
• Software development processes
• Break
• Groups discuss architecture
• Break down project into pieces
• Articulate integration and demonstration points
• Plan schedule
• Present architecture ideas to class

3
PSPPersonal Software Process

• What is this?
• Self-improvement process
• Managing time and other spare resources
• Becoming more effective, productive, valuable
• Increased awareness
• Productivity enhancement
• Feasibility
• Quality issues
• Why?
• How do you know where you are?
• How do you know where to go?
• How do you know how to get there?

4
Baseline Personal Process (PSP0)

• Planning
• Summary and overview
• Get or develop requirements
• Fill out plan summary
• Entry in time recording log
• Development
• Design the program
• Implement the design
• Compile, fix and log all defects
• Test, fix and log more defects
• Entry in time recording log
• Post Mortem
• Complete project plan summary
• Estimated and actual data
• Complete time and defect logs
• Today Planning

5
PSP0 Plan Summary
6
PSP0 Planning-Phase Script

• Requirements
• Elicit
• Elaborate
• Validate
• Resource estimation
• Best estimate
• Will serve as area of personal improvement
• Exit criteria
• Documentation
• Summary and Overview
• Requirements tabulated
• Estimated time for the project
• Entry in time log for this phase

7
Software Process Models

• Distinct set of activities, actions, tasks,
  milestones, work products
• Agreed upon by management and engineers
• Adds stability, control to an organization
• Steps vary by method
• Work products are code, documentation, data
• This is an area where WU students are deemed
  deficient by interviewers.
• Take note
• Waterfall
• Spiral
• XP (Extreme Programming)

8
Waterfall Model

• Also called classic life cycle, proposed by
  Winston Royce in 1970
• Original proposal allowed for feedback and loops
• In practice, strictly linear
• Called a prescriptive process model

9
Waterfall Model

• Communication
• Initiation, requirements gathering
• Planning
• Estimating, scheduling, tracking mechanisms
• Modeling
• Analysis and design
• Construction
• Code and test
• Deployment
• Delivery, support, feedback

10
Waterfall Model

• Real projects find it difficult to be so linear
• Customers have trouble stating requirements
  consistently, accurately, minimally.
• Model does not account for uncertainty
• Working version of program not realized until end
  of model
• Tracking functional and nonfunctional properties
  is hard
• Customer confidence can become weak
• Model may work in the small but fails in the
  large

11
Incremental Models

• All perform some kind of iteration over waterfall
  model
• Waterfall becomes a pipeline, with next iteration
  starting when requirements change or become more
  clear

functionality

1. Communication
2. Planning
3. Design/Modeling
4. Construction
5. Deployment

time
12
RADRapid Application Deployment

• Breaks problem into pieces
• Utilizes concurrent design and construction
• Huge integration exercise at the end
• Alleged 60-90 day time span

Communication
Planning
Deployment
13
RAD drawbacks

• Requires sufficient human resources
• Must commit to rapid development process
• Vision of design must remain consistent among
  teams
• Tends to fade or become chaotic over time
• Requires a project that can be componentized
• Levels of abstraction and insulation between
  teams can cause performance issues
• Use of cutting-edge technology in one team can
  sink the whole project if it fails

14
Evolutionary Models

• Examples
• Prototyping
• Spiral
• Concurrent Development
• Iterative approaches
• Increasingly more complete versions of the
  product are generated
• Articulated deliveries can help planning
• Revising design delivers a more on-target product
• Revisiting implementation can remedy a bad
  initial approach
• Must avoid urge to begin over completely

15
Prototyping Model
Communication
Quick plan
Quick design
Deployment, delivery, feedback
Construction of prototype
16
Prototyping Model

• Useful when
• Insufficient requirements exist at start
• Behavior of some components unknown
• New or strange OS
• Hardware in progress
• HCI (Human-Computer Interface) factors not yet
  firm
• Algorithmic uncertainties speed, space
• However
• Testing may be minimal
• Not intended for ultimate delivery of longevity
• Little or no documentation is produced
• Customer and team must agree on this approach
  up-front
• Expectations should not be overly high on either
  side

17
Schedule

• No group meetings this (Oct 13) or next Friday
  (Oct 20,fall break)
• In class 16 October, prepare to present
  requirements and refined architecture
  decomposition