Prologue: The Software Process (Part II)

1. Prologue:The Software Process (Part II) COSC 4346: Software Engineering I Dr. Lappoon R. Tang

2. Overview • Requirement Analysis • Design • Coding • Testing • Maintenance

3. Reading • Section 0.2 • Section 0.3 • Section 0.4 • Section 0.5 • Section 0.6

4. Key Concept: Requirements Analysis -- the process of: a) understanding what’s needed or wanted, and b) expressing the results in writing. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

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

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

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

9. Input / Output Format for Requirement Specifications Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

10. The meaning of software design • A design is produced from requirements • Essentially a “blueprint” of the application • The purposes of a design • Express how the application is to be constructed • Describe the parts involved and how they should be assembled

11. The meaning of software design • The components of a design • A set of documents – usually diagrams • Explanation of the diagrams • A design should ideally be expressed in some formal notation • The Unified Modeling Language (UML) • Flowcharts

12. Design for CustomFootnoter ______________CustomFootnoter______________ senderFirstName: String senderMidInitial: char senderLastName: String recipientMidInitial: char recipientFirstName: 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.

13. Tips on Coding • Code only against a design We focus on how one can express designs • Specify precisely what each method accomplishes Chapter 1 explains how to do this in comment sections • Before compiling, inspect to yourself that the code you have typed is correct. Read it meticulously. • ‘correct’ means that it 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.

14. 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. Note: Although this principle seems intuitive, programmers don’t necessarily follow it and it is why they end up painfully debugging their programs.  Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

15. 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 On collections of classes only 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.

16. Black Box vs. White Box Testing • Black Box Testing • Treat the unit of code to be tested as a “black box” • Test cases are designed given only the interface of the unit • Test the unit against each pre-designed input case and see if the output produced is correct • Cannot tell if output is produced according to the design • White Box Testing • Test cases are designed to verify correctness of specific design features (e.g. branching, loops, interfaces between modules …) • Similar to black box testing except that test cases are designed with details of the code available (e.g. number of cases in if-then-else statements)

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

18. Key Concept: Testing Test early and often: Note that “passed all tests” doesn’t equate to “bug free.” Testing can only reveal the presence of bugs – NOT the absence of them.  Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

19. Key Concept: Maintenance Maintenance refers to the work done on an application after it has been delivered.  Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

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

21. 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, usually repeated in cycles  } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.