Computer Science

K. Macleish

Requirements

Specifications Software Engineering Life Cycle Model

The following is a description of the traditional Software Development Lifecycle Model, which attempts to formalize
software development into a series of well-understood phases that “flow” from one to another. Maintenance accounts for
over 70% of time spend in developing software. The rule of thumb is to spend more time in the early phases to reduce time
spent in the later phases.

The last column is a review of the Lifecycle Model, an approximation of what I look for in a homework assignment (put in
context of the Software Development Lifecycle Model), and the current updated version – “stepwise refinement.”

1. Requirements Phase For our class

Help the customer determine what he/she Are directions understood and followed?
wants! - what the program is supposed to do
Sometimes have to help the customer! - input/output requirements
- formatting required
Document it, including - correct name for program
- I/O requirements Is it handed in on the due date?
- Hardware requirements
- Speed (throughput) requirements
- Software requirements
- Functionality desired
 Implementation
High Level Design
2. Design Phase
Detailed
1. Design
High Level Design
Based on Req/Spec Document!
Design overall logic
Break up project into classes (ie,
subprojects) that can be
individually coded, tested, and
integrated. Try to use existing Java
classes or make subclasses.
2. Detailed Design
Design each individual module or class
Should have correct functionality and
interfaces, but implementation is
“hidden” (does not affect anything else)
3. Implementation (Coding)
Based on Detailed Design Documents!
Coding...
Have code reviews
Computer Science
K. Macleish
For our class
Is there overall logic to the program?
(Work out on paper, flow chart?)
Are data structures correct?
Is it partitioned into classes correctly?
Are global variables used rarely, if at all?
Is information and functionality “hidden” –
not external but rather
localized to classes as much
as possible with well-defined
assess through methods?
Are constants used so that ranges can
be easily changed?
Are loops used in the right places?
Are system functions used when
appropriate?
For our class
Are loops called, terminated correctly?
Are there any obvious bottlenecks?
 Computer Science
Maintenance K. Macleish
Unit Testing

4. Testing Phase Integration Testing For our class

Does it do what the customer wants? Does it work with the sample input that
(Validation) System Testing was handed out?
Does it do what it is supposed to? Does it work with additional input?
(Verification) Does it work with “border cases?”
“Black Box” Testing - - null input
just input --> output - large amounts of data
“White Box” Testing - look at internal - handle errors as specified
code - handle decision points

Unit Testing - for module individually

Integration Testing - do they work
Together?
System Testing - Test everything together
in real environment

5. Maintenance Phase For our class

Is the program maintainable for the Are there adequate comments?

purposes of: Are the names (for methods, classes,
- fixing bugs instances, constants, variables,
- making future enhancements as types) meaningful?
requirements change Is “hard-coding” minimized
- optimizing Is it indented so it is easily understandable?
- porting to another platorrm Is white space used to break it up into
- resuming all or part of it in another “sections”?
project

NOTE – The Design/Code/Test phases are often combined into a single iterative phase called “stepwise refinement”
- also known as “design a little, code a little, test a little”
 Computer Science
K. Macleish

- can do this because of good software development tools, like Borland’s Interactive Development Environment.
- good because the customer can see progress and also refine requirements before too far along.