1. 1 Phase Implementation

2. Janice Regan, 2008 2 Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards For each unit Implement Methods in class/es Code review Unit test Create integration Test plan Create unit Test plans Release unit for integration Integration Testing System Testing Create system Test plan For each group of units

3. Janice Regan, 2008 3 Today  Class Skeleton  Internal Comments  Programming Style  Code Standards  Validation & Verification  Code reviews

4. Janice Regan, 2008 4 Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards For each unit Implement Methods in class/es Code review Unit test Create integration Test plan Create unit Test plans Release unit for integration Integration Testing System Testing Create system Test plan For each group of units

5. Janice Regan, 2008 5 Validation & Verification of Implementation Phase  Validation: trace functional requirements  Verification:  perform code review (code inspection)  test

6. Janice Regan, 2008 6 Verification  Verification Technique:  Static Verification  Analysis and check representations of software system i.e., diagrams, documents  Examples of static techniques walk-through and inspection For implementation phase -> code review (inspection) and formal program verification

7. Janice Regan, 2008 7 Verification  Dynamic Verification  Exercise representations of software system  Example of dynamic technique  For implementation phase -> test the code  It is cheaper to find and fix errors using inspection (static verification) than using testing (dynamic verification)

8. Janice Regan, 2008 8 Formal Program Verification  Pre condition :  Condition(s) that must be met (be true) prior to invocation of an operation  Establish the range of the input parameters over which the method should behave  Post condition :

9. Janice Regan, 2008 9 Formal Program Verification  Pre condition :  Post condition :  Condition(s) that must be met (be true) after the execution of an operation  Could include side effects of method as part of Post condition

10. Janice Regan, 2008 10 Code Review  Verification technique  Goal: Inspect code before it is tested  Looking for errors, emphasizing on error detection not correction  Although corrections may be suggested, they are left to author of code  Formal (i.e., scheduled)  Small group of software developers  Moderated by author of the code under review or by group lead

11. Janice Regan, 2008 11 Code Review  Advantages:  Why not only compile and run the code?  Finds syntax and runtime errors, can miss logic errors  Decrease number of errors, → decrease testing time  Because we are poor at seeing problems in our own work (too close to it), having new (several) eyes increase error detection

12. Janice Regan, 2008 12 Code Review  Advantages:  Promote “quality culture” in company  Use of code standards to produce consistent product  Scheduled opportunities to formally pass on skills, experience, and corporate culture to newer employees  Mechanism for feedback, sharing of knowledge and experience

13. Janice Regan, 2008 13 Code Review  Disadvantages:  Can be seen as time-consuming activity  Reviewing code well takes time for each reviewer  Keep the number of reviewers low (usually 2-4), the code review load on each member should be minimized.

14. Janice Regan, 2008 14 Code Review  Disadvantages:  Hard on the ego  Be open to constructive suggestions of corrections and improvements  You don’t have to take all suggestions, you should usually take most suggestions.  If you have good reason not to implement a suggestion explain why in the review, the person making the suggestion may agree with you!!

15. Janice Regan, 2008 15 About Ego  Because software design and implementation involves creativity, it is difficult for a software developer not to be “attached” to her/his “creation” and be objective about it  The point of code reviews is to highlight errors and point out improvements not to criticize software developers. Therefore, you must keep process positive  W hen pointing out errors, be careful how you phrase your comments  D o not take comments personally

16. Janice Regan, 2008 16 About Ego  To alleviate such situation, some companies promote “egoless programming” where software developers are encouraged to think of the design and the code as belonging to the team as opposed to the individual  Pair-programming