prologue: the software process. main phases of software process 1. requirements analysis (answers...
TRANSCRIPT
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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.
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.
Key Concept: Requirements Analysis
-- the process of understanding what’s 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.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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
Requirements For CustomFootnoter 2 of 3
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Requirements For CustomFootnoter 3 of 3
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Input / Output Format for Requirement Specifications
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Design for CustomFootnoter
______________CustomFootnoter______________senderFirstName: StringsenderMidInitial: char
senderFirstName: StringrecipientMidInitial: char
recipientLastName: String__________recipientLastName: String___________
CustomFootnoter()main()
getSenderName()getRecipientName()
createExpandedVersionOf( String aName ): StringcreateFootnote(): String
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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”)
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Output of a White Box Test
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Key Concept: Testing
Test early and often: Note that “passed all tests” doesn’t equate to “bug free.”
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Types of Maintenance
Defect Removal o Finding and fixing all inconsistencies with the
requirements document
Enhancement o Introducing new or improved capability
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.}
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.