Software Engineering At Glance

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

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

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

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

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

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

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)

Build and Fix Model Problems –No specifications –No design

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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