Prologue: The Software Process

1
PrologueThe Software Process
2
Main Phases of Software Process

• Requirements Analysis (answers WHAT?)
• Specifying what the application must do
• Design (answers HOW?)
• Specifying what the parts will be, and how they
  will fit together
• Implementation (A.K.A. CODING)
• Writing the code
• Testing (type of VERIFICATION)
• Executing the application with test data for
  input
• Maintenance (REPAIR or ENHANCEMENT)
• Repairing defects and adding capability

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
3
Software Process Phases Personal Finance Example

• Requirements Analysis Text produced
• e.g., The application shall display
• the balance in the users bank account.
• Design Diagrams and text
• e.g., The design will consist of the classes
  CheckingAccount, SavingsAccount,
• Implementation Source and object code
• e.g., class CheckingAccount double balance
  
• Testing Test cases and test results
• e.g., With test case deposit 44.92 / deposit
  32.00 / withdraw 101.45 / the balance was
  2938.22, which is correct.
• Maintenance Modified design, code, and text
• e.g., Defect repair Application crashes when
  balance is 0 and attempt is made to withdraw
  funds.
• e.g., Enhancement Allow operation with Pesos.

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
4
Key Concept ? Software Process ?
-- a procedure followed by the development team
to produce an application.
5
The Waterfall Software Process
time
Milestone(s)
Release product X
Requirements Analysis
Two phases may occur at the same time for a short
period
Design
Implementation
Phases (activities)
Testing
Maintenance
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
6
Why a Pure Waterfall Process is Usually Not
Practical

• Dont know up front everything wanted and needed
• Usually hard to visualize every detail in advance
  
• We can only estimate the costs of implementing
  requirements
• To gain confidence in an estimate, we need to
  design and actually implement parts, especially
  the riskiest ones
• We will probably need to modify requirements as a
  result
• We often need to execute intermediate builds
• Stakeholders need to gain confidence
• Designers and developers need confirmation
  they're building whats needed and wanted
• Team members can't be idle while the requirements
  are being completed
• Typically put people to work on several phases
  at once

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
7
The Spiral Process
time
M I L E S T O N E S
Product released X
Intermediate version completed X
1
Iteration
2
3
Requirements analysis
1
2
3
Design
1
2
3
Coding
1
2
3
Testing
2
3
1
typically a prototype
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
8
Key Concept ? Waterfall Process ?
-- basic software process in which requirements
analysis, design, coding, testing, and
maintenance are performed in sequence, but with
some overlap.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
9
Key Concept ? Work Against the Product of Prior
Phase ?
In each phase of the software process, we design
and code within the specifications produced by
the prior phase.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
10
Key Concept ? Inspections ?
-- the process of reading meticulously through an
artifact. Authors inspect their code before
compiling it. Teams inspect when the author is
done.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
11
Key Concept ? Requirements Analysis ?
-- the process of understanding whats needed or
wanted, and expressing the results in writing.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
12
The Challenges of Requirements Analysis

• Express requirements in ordinary, clear English
• Non-technical
• From the users perspective
• Organize the requirements into logical groupings
  
• Make easy to access and change
• Challenging for real applications
• Arrange for the management of requirements
• A procedure must be developed in advance for
  keeping the requirements documents up to date
• Who, how, and when

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
13
Requirements For CustomFootnoter 1 of 3
1. Overview CustomFootnoter generates e-mail
footers to promote customer relationships.
Initial versions will produce simple courtesy
statements. Later versions will contain helpful
tips and offerings tailored to the recipient's
interests. This requirements specification is for
a prototype which accepts command-line input, and
generated console output.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
14
Requirements For CustomFootnoter 2 of 3

• 2. Detailed Requirements
• 2.1 Input
• CustomFootnoter will accept the first 10
  characters of the recipients first name as
  follows.
  
  Please type in the senders first name
• Abcd
• The application will accept a single middle
  initial with the following format.
• Please type in the senders middle initial
• M
• The application will accept the first 10
  characters of the recipients last name as
  follows.
• Please type in the senders last name
• Xyz

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
15
Requirements For CustomFootnoter 3 of 3
4) The application will accept the senders name
in the same manner 2.2 Output 5) CustomFootnoter
outputs the following text to the console if it
is less than or equal to 60 characters long

---- To A b c d M.
X y z from E r i c J. B r a u d e.
---- (the number and position of blanks as
indicated by the example) Otherwise the three
initials may be used, as in ---- To A. M. X.
from E. J. B. ---- 2.3 User Interface The
requirements in sections 2.1 and 2.2 will conform
to the I/O format in the following example.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
16
Input / Output Format for Requirement
Specifications
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
17
Design for CustomFootnoter
______________CustomFootnoter______________ sender
FirstName String senderMidInitial char
senderFirstName String recipientMidInitial
char recipientLastName String __________recipien
tLastName String___________ CustomFootnoter() mai
n() getSenderName() getRecipientName() createExpan
dedVersionOf( String aName ) String createFootnot
e() String
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
18
Tips on Coding

• Code only against a design
• This book explains how to express designs
• Specify precisely what each method accomplishes
• Chapter xx explains how to do this in comment
  sections
• Before compiling, satisfy yourself that the code
  you have typed is correct. Read it meticulously.
  
• correct means that is satisfies whats required
  of it
• This is author-inspection
• Build-a-little-Test-a-little
• Add a relatively small amount of code
  (build-a-little)
• (Again) Read what you have typed and correct it
  if necessary until you are totally satisfied its
  correct
• Compile
• Test the new functionality (test-a-little)

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
19
Key Concept ? Author-Inspect Before Compiling ?
Inspect and edit the block of code you have just
written until you are convinced it does exactly
what it is meant to do. Only then compile it.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
20
Types of Testing

• Informal developer tests
• Performed by individual developers documented
  informally in their notebooks
• Unit tests
• On parts such as methods or classes
• May be formally documented
• Intermediate tests
• System tests
• On whole application
• Thoroughly documented

• White box
• Black box

?
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
21
Output of a White Box Test
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
22
Tips on Testing

• Test early and often
• Test with extreme values
• Very small, very big, etc.
• Borderline
• Illegal values
• Vary test cases
• Dont repeat tests with same test data except
  when specifically intended

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
23
Key Concept ? Testing ?
Test early and often Note that passed all
tests doesnt equate to bug free.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
24
Types of Maintenance

• Defect Removal
• Finding and fixing all inconsistencies with the
  requirements document
• Enhancement
• Introducing new or improved capability

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
25
Summary of Software Process

• A way of going about the creation and upkeep of a
  software product
• Commonly based on the Waterfall process
• Specify requirements
• Create design
• Write code
• Test
• Maintain

In sequence with some overlap.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.