prologue: the software process. main phases of software process 1. requirements analysis (answers...

Prologue:The Software Process

Main Phases of Software Process

1. Requirements Analysis (answers “WHAT?”)

Specifying what the application must do

2. Design (answers “HOW?”)

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

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

Writing the code

4. Testing (type of VERIFICATION)

Executing the application with test data for input

5. Maintenance (REPAIR or

ENHANCEMENT)

Repairing defects and adding capabilityAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Software Process Phases: Personal Finance Example

Requirements Analysis: Text produced

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

Key Concept: Software Process

-- a procedure followed by the development team to produce an application.

The Waterfall Software Process

time

RequirementsAnalysis

Design

Milestone(s)

Phases (activities)

Implementation

Testing

Maintenance

Release product X

Two phases may occur at the same time for a short period

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

Why a Pure Waterfall Process is Usually Not Practical

Don’t know up front everything wanted and neededo Usually hard to visualize every detail in advance

We can only estimate the costs of implementing requirements

o To gain confidence in an estimate, we need to design and 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 confidenceo Designers and developers need confirmation they're building

what’s needed and wanted Team members can't be idle while the requirements are

being completedo Typically put people to work on several phases at once


The Spiral Process time

1 Requirementsanalysis

Design

Coding

Testing

1Iteration #

1

1

2

2

2

3

3

3

Product released XIntermediate version* completed X

*typically a prototype

M I L E S T O N E S

2 3

2 3 1


Key Concept: Waterfall Process

-- basic software process in which requirements analysis, design, coding, testing, and maintenance are performed in sequence, but with some overlap.


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.


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.


Key Concept: Requirements Analysis

-- 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-technicalo From the user’s perspective

Organize the requirements into logical groupings o Make easy to access and change o Challenging for real applications

Arrange for the management of requirementso A procedure must be developed in advance for

keeping the requirements documents up to date• Who, how, and when


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.


2. Detailed Requirements

2.1 Input1) CustomFootnoter will accept the first 10

characters of the recipient’s first name as follows. Please type in the sender’s first name: Abcd

2) The application will accept a single middle initial with the following format. Please type in the sender’s middle initial: M

3) The application will accept the first 10 characters of the recipient’s last name as follows. Please type in the sender’s last name: Xyz



4) The application will accept the sender’s 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.



Input / Output Format for Requirement Specifications


Design for CustomFootnoter

______________CustomFootnoter______________senderFirstName: StringsenderMidInitial: char

senderFirstName: StringrecipientMidInitial: char

recipientLastName: String__________recipientLastName: String___________

CustomFootnoter()main()

getSenderName()getRecipientName()

createExpandedVersionOf( String aName ): StringcreateFootnote(): String


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.

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

Build-a-little-Test-a-little1. 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 correct3. Compile4. 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 what it is meant to do. Only then compile it.


Informal developer testso Performed by individual

developers; documented informally in their notebooks

Unit testso On parts such as methods or

classeso May be formally documented

Intermediate tests System tests

o On whole applicationo Thoroughly documented

White box

Black box

Types of Testing


Output of a White Box Test


Test early and often Test with extreme values

o Very small, very big, etc.

o Borderline

o “Illegal” values

Vary test caseso Don’t repeat tests with same test data

except when specifically intended

Tips on Testing


Key Concept: Testing

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


Types of Maintenance

Defect Removal o Finding and fixing all inconsistencies with the

requirements document

Enhancement o Introducing new or improved capability


Summary of Software Process

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

Commonly based on the Waterfall process 1. Specify requirements

2. Create design

3. Write code

4. Test

5. Maintain

In sequence with some overlap.}


prologue: the software process. main phases of software process 1. requirements analysis (answers...

Documents