1. Software Engineering At Glance

2. Why We Need Software Engineering? The aim of software engineering is to solve the software crisis Software is delivered –Late –Over budget –With residual faults

3. Standish Group Data Data on 9236 projects completed in 2004 Stephen R. Schach

4. Software Engineering A discipline of software production whose aims are to produce a software that is: –Fault-free, –Delivered on time and within budget, –Satisfying client’s needs –Easy to modify when the client’s needs change

5. Software Lifecycle Requirements phase Specification phase Design phase Implementation phase Integration phase Maintenance phase Retirement

6. Why Maintenance? Bad software is discarded Good software is maintained, for 10, 20 years or more Different types of maintenance –Corrective maintenance –Enhancement Perfective maintenance Adaptive maintenance

7. Time (= Cost) of Maintenance (a) Between 1976 and 1981 (b) Between 1992 and 1998 Stephen R. Schach

8. Importance of Early Phases To correct a fault early in the life cycle –Usually just a document needs to be changed To correct a fault late in the life cycle –Change the code and the documentation –Test the change itself –Perform regression testing –Reinstall the product on the client’s computer(s)

9. Build and Fix Model Problems –No specifications –No design

10. Waterfall Model Characterized by –Feedback loops –Documentation-driven Advantages –Documentation –Maintenance easier

11. Rapid Prototyping Model Do not turn the rapid prototype into the product Three Key Points Rapid prototyping may replace the specification phase—never the design phase Comparison: –Waterfall model—try to get it right the first time –Rapid prototyping—frequent change, then discard

12. Incremental Model Divide Project into Builds Potential Problem -> Build-and-fix danger

13. Spiral Model Simplified form Waterfall model plus risk analysis preceding each phase

14. Simplified Spiral Model If all risks cannot be resolved, the project is immediately terminated

15. Synchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis: interview potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams working in parallel At the end of the day: synchronize (test and debug) At the end of the build: stabilize (freeze build) Components always work together –Get early insights into the operation of the product

16. Teams Brooks’s Law –Adding additional programming personnel to a team when a product is late has the effect of making the product even later

17. Teams Communication paths between 3 computer professionals, and when a 4th professional joins them.

18. Democratic Team Basic concept is “team of egoless programming”. Group of 10 egoless programmers with no single leader. Every programmer must encourage others to find faults in his/her code. Presence of a fault should not be considered something bad (rather asked for advice.)

19. Classical Chief Programmer Team Chief Programmer Programming Secretary Back-up Programmer

20. Modern Programming Team Team Manager Team Leader Programmer Technical management Nontechnical management

21. Structure for larger projects Team Leader Programmer Technical management Programmer Team Leader Team Leader Project Leader

22. Decentralized decision-making Team Leader Programmer Technical management Programmer Team Leader Team Leader Project Leader

23. Synchronize-And-Stabilize Team (Utilized by Microsoft) Each of 3 or 4 sequential builds is constructed by a small parallel teams led by a program manager with 3-8 developers and 3-8 testers, working as one-to-one. Team is provided with specifications of their overall task, then team members are free to design and implement their task. Partially completed components are tested and debugged on a daily basis (Synchronized). Stabilization is performed at the end of each of the builds (build is frozen). Programmers are encouraged to be creative and innovative. (Characteristic of a democratic team.)

24. Extreme Programming Team Pair programmers: one draws up test cases for task, other implements. If one leaves, other continues with new pair programmer. Working as pair: less experienced one can acquire skills from the more experienced member. All computers are placed in middle of large room: –promotes group ownership of code and positive feature of egoless team.

25. Testing Two types of testing –Execution-based testing –Nonexecution-based testing Who should perform exectution-based testing? –Programming is constructive –Testing is destructive A successful test finds a fault –So, programmers should not test their own code artifacts