Topic 13: The Software Development Process
Synopsis
- Designing, building and maintaining
large software products...
- ...in a timely fashion...
- ...and in a reliable process...
- ...and cost-effectively
- No! You are used to...
- ...writing small programs
(i.e. less than 100,000 line of code)
- ...getting detailed instructions and clear feedback
- ...skimping on error-checking and recovery
("throw-away" code)
- Identified in the late 60's and still going on!
- One in four systems projects fail to deliver
- 20% staff turnover normal
- Large systems take 3 to 5 years to develop
- Hence, many are obsolete before they're available
- Software maintenance is the single largest computer-related
cost for most companies
- Investigate user requirements (analysis)
- Clearly set out necessary features of system (specification)
- Create (or adapt) a suitable solution (design)
- Develop the proposed solution (implementation¤)
- Ensure that the solution solves the original problem (testing)
- Ensure that the solution works in context (integration)
- Modify the working solution as new requirements are
identified (maintenance)
- Most (all?) users don't know exactly what they want
- Because most don't know exactly what they currently do
- Hence analysis requires the software developer to
become consciously expert in the user's domain
- Phase 1: Discovery (listen and observe)
- Phase 2: Refinement (interrogate and clarify)
- Phase 3: Modelling (suggest and verify)
- Outcome is: sufficient understanding of the problem
to write a requirements specification document
- Last phase of the analysis task
- Need to write down unambiguously what the
required behaviour¤ is
- Formal notations
- Structured documents
- Examples
- Outcome is: a requirements specification that
unambiguously communicates the required features of
the system to the designer
- Develop a solution meeting requirements
- Draw on past experience (and standard techniques)
- Often need to innovate at some level
- May generate many possible solutions
- Hence may need yardsticks (metrics) to select amongst them
- Outcome is: a design document that unambiguously
communicates the design to the implementor(s)
- Writing code
- Documenting code
- Debugging code
- Preparing code for testing
- Feedback to designer and/or analyst
- Feed-forward to tester and/or integrator
- Outcome is: working code and documentation, ready
to be tested
- Need to check that implementation¤ matches design
(i.e. that it works)
- Need to check that implementation¤ meets requirements
(i.e. that it works correctly)
- Must test individual modules and then complete system
- Then test interaction with existing environment/
software/data/etc.
- Outcome is: tested code, "in situ", working correctly
- Users' requirements change over time
- Even "exhaustive" testing may not uncover all problems
before delivery
- Hence software must also change over time
- Changes in requirements may necessitate extra implementation¤
and testing, or additional design work, or even a new analysis
- We can study the general process of creating software
and model it
- Such software development process models give us a way of thinking
about the development of software in the abstract
- Thinking about the software process may allow us to
improve how we actually go about it
- The simplest possible model
- ...and therefore the least likely to be correct!
- Model the software development process as a stately
and sequential progression through the previously
mentioned phases
- The model is orderly, simple to understand, and
represents a process that is easy to manage and measure
- The problem is that not even the simplest systems
actually get built that way
- Exploratory programming
- Prototyping
- Incremental development
- Formal transformation
- Extreme programming
- Very High Level (Fourth Generation) Languages (VHLL's, 4GL's)
- Component Reuse
- Fountain Model
- Spiral Model
- Madhavji Model, Redwine Model, etc. etc. etc.
- Variations on the theme of
"build something and see if that's what's wanted"
- May be entire development process (exploratory programming)
- ...or merely replace the early design-implement cycle
- ...or may take an evolutionary approach (Gall's dictum)
- Based on the waterfall model
- But observes that the sequence always contains
cycles
- Reflects the fact that some phases cannot begin
before others
- ...and that some phases are poorly delineated
- A mental image to help visualize what actually
happens in many real software development projects
- Suggested by Boehm in 1988
- Still regarded as one of the best models
- Categorizes the many (and repeated) phases of
software development into a number of cyclically
repeated sectors
- Determining objectives/alternatives/constraints
- Risk analysis
- Prototyping
- Simulation/modelling/benchmarking
- Specification and design
- Planning
- System complexity and size grows with increasing
radius, as do investment and risk
- Each of these models is just a theory...
- ...a simplification to explain what actually happens
- ...or to suggest what should happen
- They are, at very best, only approximations to reality
- They are based on assumptions about the types of
problems that are usually solved, about the expectations
of users, about the resources available, about time-frames,
tools, task complexity, etc. etc.
- None of those assumptions may be valid in a particular
case
- Hence there is no "silver
bullet" or "panacea" which
is always guaranteed to make the development of large
systems easy.
- Pressman: Chapter 1 and 2
- Schach: Chapter 2 and 3
- Fowler: Chapter 1 – 3
This material is part of the CSE2305 - Object-Oriented
Software Engineering course.
Copyright © Jon McCormack & Damian Conway, 1998–2005. All rights
reserved.