Credits

Slides adapted from the slides for the book "Software Engineering: The Current Practice" by Václav Rajlich © 2012 by Václav Rajlich

Successful SE Course

Easy to teach a trivial software engineering course

• Must develop (in students) simple and straightforward basic viewpoint/world view/understanding
• As with many simple concepts, real implications can take a while to sink in

Misconceptions

Iterative approaches are all about planning, with not much doing

With the Big Bang approach, we concentrate on implementation (coding), not worrying about planning

• Both statements are incorrect
• Basically, developers spend more time planning using the Big Bang approach. The difference is when and how it integrates into the process

School vs. Real World

Role of Process

The size of the project can affect process requirements

• Small, short projects can use any process they want, and they may accidentally succeed, or nobody notices if they fail
• Large projects over a long time frame do not accidentally succeed

Studies Show

Standard Software Phases

• Requirements
• Analysis
• Design
• Implementation
• Testing & Validation
• Release
• Maintenance

Why break up into phases?

Requirements
Analysis
Design
Implementation
Testing
Validation
Release
Maintenance

• Phases match typical development activities
• Ensure completion of needed tasks
• Ensure generation of needed artifacts (documents)
• Measure and show progress
• Predict personnel and skillsets needed
• Record for future use

(Some) Phases and Deliverable Artifacts

Common Process Models

• Waterfall
• Prototyping
• Agile
• Extreme Programming (XP)
• Rational Unified Process

Characteristics of Process Models

• Heavyweight vs. Lightweight
• Planning vs. Doing
• Efficiency (skillset, personnel, time to market)
• Single Pass vs. Multiple Passes
• Role of Maintenance
• View of Evolution

Waterfall Model

• Heavyweight, single-pass, heavy planning-based approach
• Each phase is completed and verified before the next phase begins
• The "Big Bang" approach described in Head First book exhibits similar characteristics
• Requires extreme amounts of planning to be successful

Waterfall Model Effects

Heavyweight, single-pass, heavy planning-based approach

• Detailed and very formal documents are required for each phase
• Personnel become experts in individual phases

Role of Waterfall

• Original attempt to solve the software crisis
• Very appealing, especially to those in other disciplines, appears to be common sense
• The predominant process taught in SE for many years
• The predominant process for other engineering disciplines
• Maintenance is handled very differently than the initial development

Criticisms of Waterfall

• Prescriptive rather than descriptive
• Assumes "pure" phases
• Some estimates assign 80% of overall costs to the maintenance phase, but maintenance is handled very differently than the initial development
• Not proved to be successful
• Note: Waterfall thinking can permeate all aspects, e.g., BDUF (Big Design Up Front)

Requirement Volatility

Requirements are almost always not fully known in advance and often added during the other phases

• E.g., Microsoft found that 30% of requirements originated after requirements gathering
• Any design based on requirements documents must be considered temporary

Anomaly

"Anomaly" is an important fact that directly contradicts the old paradigm

• The Waterfall process is not successful at solving the software crisis or produces low-quality results
• The solution was to propose band-aid approaches

Band-Aid Approach: Design for Change

Since requirements are volatile, design to allow for future changes

• Commonsense, but does require predicting the future, which we cannot always do
• Very useful for low-level design: named constants, good method abstractions, good class abstractions
• Increases flexibility, but that often increases complexity
• Increases cost of the initial software

Problem: Unexpected Changes

Since requirements are volatile, design to allow for future changes

• Company mergers that require IT unification, e.g., Daimler Chrysler
• Changes in the law, e.g., record keeping (or lack thereof)
• Changes in technology, e.g., the Internet, mobile applications, smartwatches

Band-Aid Approach: Prototyping

It is difficult to determine requirements without a running system, so build a prototype to get requirements, e.g., "Build one to throw away."

• Develop the first version cheaply: Very high-level languages, fewer features (particularly non-functional requirements of speed, robustness, quality)
• It is still necessary to gather all requirements during the prototype
• Issue: perception of a prototype as a completed system

Studies Show

Why should companies care?

• Money lost due to wasted development effort (somewhat important)
• Money lost due to inability to use the developed software (much more important)
• Provide an opportunity for other companies to take over and for disruption to occur