Prologue: Th S ft P The Software Process

(1)

Prologue:

Th S ft P

The Software Process

Main Phases of Software Process 1. Requirements Analysis (answers “WHAT?”)

Specifying what the application must do

2 Design (answers “HOW?”)

2. Design (answers HOW? )

Specifying what the parts will be, and how they will fit together

3. Implementation (A.K.A. “CODING”)

W iti th d Writing the code

4. Testing (type of VERIFICATION) 4. Testing (type of VERIFICATION)

Executing the application with test data for input

5. Maintenance (REPAIR or ENHANCEMENT)

Repairing defects and adding capability Repairing defects and adding capability

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

Software Process

Ph P l

Requirements Analysis: Text produced

Phases: Personal Finance Example e.g., “ … The application shall display

the balance in the user’s bank account. …”

Design: Diagrams and text

e g “ The design will consist of the classes e.g., … The design will consist of the classes

CheckingAccount, SavingsAccount, …”

Implementation: Source and object code

e.g., … class CheckingAccount{ double balance; … } … T ti T t d t t lt

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. …”p

e.g., Enhancement: “Allow operation with Pesos.”

K C t Æ S ft P Å

Key Concept: Æ Software Process Å -- a procedure followed by the development a procedure followed by the development team to produce an application.

(2)

The Waterfall Software Process

titime

Milestone(s) Release product X

Requirements

Analysis Two phases may

occur at the same time Analysis

Design

occur at the same time for a short period Design

Implementation Phases (activities)

Implementation

Testing Testing

Maintenance Maintenance

Why a Pure Waterfall Process is Usually Not Practical

Don’t know up front everything wanted and needed

o Usually hard to visualize every detail in advance o Usually hard to visualize every detail in advance

We can only estimate the costs of implementing i t

requirements

o To gain confidence in an estimate, we need to design and

ll i l i ll h i ki

actually implement parts, especially the riskiest ones o We will probably need to modify requirements as a result

We often need to execute intermediate builds

o Stakeholders need to gain confidenceg

o Designers and developers need confirmation they're building what’s needed and wanted

Team members can't be idle while the requirements are being completed

being completed

o Typically put people to work on several phases at once

The Spiral Process

_time

Product released X Intermediate version* completed X

M I L E S T O N E S

1

Iteration # 2 3

Product released X Intermediate version* completed X

Requirements ₁ Requirements

analysis ² ³

Design ¹ ² ³

Coding ¹ ² ³

Testing ¹ ² ³

*typically a prototype

Key Concept: y p Æ Waterfall Process Å -- basic software process in which

i t l i d i di

requirements analysis, design, coding, testing, and maintenance are performed

i b t ith l

in sequence, but with some overlap.

(3)

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. p p y p p

Key Concept: Æ Inspections Å -- the process of reading meticulously through an artifact Authors inspect through an artifact. Authors inspect their code before compiling it. Teams i t h th th i d

inspect when the author is done.

Key Concept: Æ Requirements Analysis Å Key Concept: Æ Requirements Analysis Å -- the process of understanding what’s needed -- the process of understanding what s needed or wanted, and expressing the results in writing.

The Challenges of Requirements Analysis

Express requirements in ordinary, clear English

o Non-technical

o From the user’s perspective o From the user s perspective

Organize the requirements into logical groupings

o Make easy to access and change o Challenging for real applications o Challenging for real applications

Arrange for the management of requirements g g q

o A procedure must be developed in advance for keeping the requirements documents up to date keeping the requirements documents up to date

• Who, how, and when

(4)

Requirements For CustomFootnoter 1 of 3

1 O er ie 1. Overview

CustomFootnoter generates e-mail footers to promote CustomFootnoter generates e-mail footers to promote customer relationships. Initial versions will produce simple

t t t t L t i ill t i h l f l ti 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 accepts command-line input, and generated console output.

2. Detailed Requirements Requirements For CustomFootnoter 2 of 3 2.1 Input

1) CustomFootnoter will accept the first 10

CustomFootnoter 2 of 3 1) CustomFootnoter will accept the first 10

characters of the recipient’s first name as follows.

Pl i h d ’ fi

Please type in the sender’s first name:

Abcd

2) The application will accept a single middle initial with the following format

with the following format.

Please type in the sender’s middle initial:

M M

3) The application will accept the first 10 characters ) pp p of the recipient’s last name as follows.

Please type in the sender’s last name: yp Xyz

4) The application will accept the sender’s name in the same manner

manner

2 2 Output Requirements For CustomFootnoter 3 of 3 2.2 Output

5) CustomFootnoter outputs the following text to the console if it ) p g 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 U I t f 2.3 User Interface

The requirements in sections 2 1 and 2 2 will conform to the I/O The requirements in sections 2.1 and 2.2 will conform to the I/O

format in the following example.

Input / Output Format for Requirement Specifications

(5)

Design for CustomFootnoter CustomFootnoter

______________CustomFootnoter______________

senderFirstName: String senderMidInitial: char senderMidInitial: char senderFirstName: String

recipientMidInitial: char p recipientLastName: String

__________recipientLastName: String___________p g CustomFootnoter()

main() getSenderName() getRecipientName()

createExpandedVersionOf( String aName ): String createFootnote(): String

Tips on

Code only against a design

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.

o ‘correct’ means that is satisfies what’s required of it o This is “author-inspection”p

Build-a-little-Test-a-little

1 Add a relatively small amount of code (“build-a-little”) 1. Add a relatively small amount of code ( build a little ) 2. (Again): Read what you have typed and correct it if

necessary until you are totally satisfied it’s correct necessary until you are totally satisfied it s correct 3. Compile

4 Test the new functionality (“test-a-little”) 4. Test the new functionality ( test-a-little )

Key Concept: Æ Author-Inspect Before Compiling Å Inspect and edit the block of code you have just written until you are convinced it does exactly written until you are convinced it does exactly what it is meant to do. Only then compile it.

Informal developer tests Types of

o Performed by individual developers; documented

Testing

developers; documented informally in their notebooks

Unit tests

o On parts such as methods or

White box

o On parts such as methods or classes

White box

Black box

o May be formally documented r

Intermediate tests

Black box

Intermediate tests

System tests

o On whole application o Thoro ghl doc mented o Thoroughly documented

(6)

Output of a White Box Test

Tips on Testing

Test early and often

Tips on Testing

Test early and often

Test with extreme values

o Very small, very big, etc.

o Borderline o “Illegal” values

V

Vary test cases

o Don’t repeat tests ith same test data o Don’t repeat tests with same test data

except when specifically intended p p y

Key Concept: Æ Testing Å Test early and often: Note that “passed all tests” doesn’t equate to “bug free.”

all tests doesn t equate to bug free.

Types of Maintenance

Defect Removal

o Finding and fixing all inconsistencies with the requirements document

requirements document

Enhancement

o Introducing new or improved capability

(7)

Summary of Software Process

A way of going about the creation and y g g upkeep of a software product

Commonly based on the Waterfall process

1 S if i t

1. Specify requirements

2. Create design In sequence

2. Create design 3. Write code

In sequence with some overlap 4. Test

5 Maintain

overlap.

5. Maintain