Nerf Gun Experiment

1
Nerf Gun Experiment

• Never used that technology
• Target wasnt where you first thought it to be
• No practice aiming to hit the target
• Made human errors to aim and hit
• Target moved

2
Application to Software Development

• Resources are very tight
• Little margin for error
• Target is hard to get into focus
• Execution (process and technology) errors are
  unavoidable initially
• Target moves
• Remaining on a bad path can be devastating
• Immediate feedback and applied learning lead to
  quicker success

3
Waterfall Model
4
Waterfall Model Phases

• Feasibility
• Define a preferred concept for the software
  product, and determine superiority to alternative
  concepts
• Requirements
• Create a complete specification of the required
  functions, interfaces, and expected performance
  for the software product
• Product Design
• Create a complete specification of the overall
  hardware-software architecture, control
  structure, and data structures for the product,
  along with such other necessary modules as draft
  user's manuals and test plans.
• Detailed Design
• Create a complete specification of the control
  structure, data structure, interface relations,
  sizing, key algorithms, and assumptions of each
  program module
• Coding
• Create a complete set of program components
• Integration
• Construct a properly functioning software product
  composed of the software modules
• Implementation
• Construct a fully functioning, operational
  hardware-software system, including such
  objectives as program and data conversion,
  installation, and training
• Maintenance
• Perform a fully functioning update of the
  hardware-software system repeated for each update
• Phase-out
• Transition the functions performed by the product
  to its successors

5
Waterfall Model Assumptions

• 1. The requirements are knowable in advance of
  implementation.
• 2. The requirements have no unresolved,
  high-risk implications
• e.g., risks due to COTS choices, cost, schedule,
  performance, safety, security, user interfaces,
  organizational impacts
• 3. The nature of the requirements will not
  change very much
• During development during evolution
• 4. The requirements are compatible with all the
  key system stakeholders expectations
• e.g., users, customer, developers, maintainers,
  investors
• 5. The right architecture for implementing the
  requirements is well understood.
• 6. There is enough calendar time to proceed
  sequentially.

6
Short Vectors vs. Long Vectors

• Measurements
• Time Resources
• Scrap Rework

7
Measurements
Short Vectors
Time Resources
Long Vectors
Scrap Rework
8
Software Differences, Pt. 1

• Iterative Development
• Most important concept to emerge in software
  development
• Breaks away from the Waterfall model
• Grounded in risk mitigation, incremental
  construction, and measurable progress in code
• Difficulty is in keeping documentation current

9
Iteration Plan of the Construction Phase
Phases
Process Disciplines
Elaboration
Transition
Inception
Construction
Requirements
Analysis Design
Implementation
Test
Supporting Disciplines
Configuration Change Mgmt
Project Management
10
Risk Targeting

• Understanding the threats to your project
• Determine the most important risk and remove or
  reduce it on the next iteration
• Different from test taking strategies
• Be ready to alter iteration scope
• Expectation of length
• Expectation of tasks
• Use scientific method
• What do you want to find out
• What is the approach you will use
• How will you know if the iteration achieved the
  expectations
• Difference from throw-away prototyping
• Negativity testing
• If risk is removed or reduced, if technology is
  acceptable, then that piece of construction is
  part of the system

11
Business Implications

• Earlier cancellation of project
• Proven to be infeasible
• Less resource waste
• Documented risks and issues for a later attempt
• Less staffing early on
• You can add programmers, testers, and documenters

12
Justifying Iterative Development

• What you tell the development team
• Good to manifest
• Research and development needs
• Ambiguous requirements
• Risk of all types
• What you tell your manager
• Less up front cost for real feasibility
  assessment
• Less staff needed up front
• Early knowledge of stakeholder participation and
  commitment