Prologue: The Software Process

1. Prologue:The 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 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.

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 • Don’t 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 what’s 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 Intermediate version* completed X Product released X Iteration # 1 2 3 Requirements analysis 1 2 3 Design 1 2 3 Coding 1 2 3 Testing 1 2 3 *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 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.

12. The Challenges of Requirements Analysis • Express requirements in ordinary, clear English • Non-technical • From the user’s 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 recipient’s first name as follows. Please type in the sender’s first name: • Abcd • The application will accept a single middle initial with the following format. • Please type in the sender’s middle initial: • M • 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 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 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. 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______________ senderFirstName: String senderMidInitial: char senderFirstName: String recipientMidInitial: char recipientLastName: String __________recipientLastName: String___________ CustomFootnoter() main() getSenderName() getRecipientName() createExpandedVersionOf( String aName ): String createFootnote(): 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 what’s 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 it’s 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. 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 Types of Testing  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 • Don’t 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” doesn’t 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.