INFO 637Lecture #101 Software Engineering Process II Review INFO 637 Glenn Booker

INFO 637Lecture #102 TSP Overview The TSP is designed for teams of up to 20 people  Here we used TSPi, which uses the same concepts, but designed for a team of 4-8 people TSPi is based on a waterfall-like life cycle model, adapted for cyclical development  Features are developed in cycles, which each build on previous cycles

INFO 637Lecture #103 TSP Steps Within Each Cycle Strategy Plan Requirements Design Implementation Test Postmortem

INFO 637Lecture #104 TSP Structure The structure of the TSP is designed to avoid most common problems associated with team formation and lack of peer review  Everyone is assumed to be a software developer (Development Engineer), and also take on an additional role

INFO 637Lecture #105 TSP is Implementation-Independent TSP doesn’t assume any type of development methodology  Object oriented  Procedural development Any kind of analysis techniques or models could be used  Use cases, formal specification, ERD, DFD, class diagram, interaction diagrams, etc.

INFO 637Lecture #106 TSP Roles Team Leader Development Manager Planning Manager Quality and Process Manager  May be two separate roles Support Manager

INFO 637Lecture #107 TSP Activities The management of activities is similar to version 2.0 of the PSP  Time is logged for all activities  Defects are logged  Tasks are planned, and actual times recorded  Size of work products is estimated, and compared to actuals  Risks and issues are identified and tracked

INFO 637Lecture #108 TSP Activities TSP also introduces a peer review process, which allows estimation of defects missed during inspection A change control process is added to prevent conflicting changes to the same artifact (code, documentation, etc.)

INFO 637Lecture #109 Typical Scripts for one Cycle We used the scripts for one project cycle  Launch & Development Strategy  Development Plan  SRS and System Test Plan  Design and Integration Test Plan  Implementation Script  Test Script (conduct integration & system test)  Post Mortem

INFO 637Lecture #1010 Launch Script The launch script includes:  Course overview  Assigning roles  Describing the objectives of your product How will you know if it’s been created correctly?  Hold the first team meeting  Review of data reporting requirements

INFO 637Lecture #1011 Development Strategy Script Key steps in this phase are:  Create Conceptual Design of the product  Define Development Strategy What features go into each cycle?  Estimate Product size and development effort  Assess Risks  Document the Development Strategy  Define Configuration Management Plan

INFO 637Lecture #1012 Development Plan Script Based on the conceptual design  Identify specific products to be produced, and estimate their sizes  Record STRAT data in SUMS Produce task plan using TASK form Produce team’s schedule plan using SCHEDULE form, including expected weekly hours per person

INFO 637Lecture #1013 Development Plan Script Produce the quality plan using estimated SUMP and SUMQ plans Break out individual plans based on the team TASK and SCHEDULE plans Balance workload, then reconsolidate the team TASK and SCHEDULE plans Send TASK, SCHEDULE, SUMS, SUMP, and SUMQ to team members and instructor

INFO 637Lecture #1014 SRS Script The development script for creating the SRS includes:  Reviewing and clarifying the system needs  Allocating parts of the SRS to be done by each team member  Developing the system test plan  Inspecting the SRS and test plan  Refining the SRS and test plan

INFO 637Lecture #1015 Design Scripts Conduct high level design to identify and name the major components  Capture the design using one or more methods mentioned earlier Define design standards (like in the PSP) Allocate design tasks to team members

INFO 637Lecture #1016 Design Scripts Prepare parts of the SDS separately Prepare the integration test plan Inspect the draft design document and test plan Update and agree upon the final SDS, and prove that it is traceable to the SRS

INFO 637Lecture #1017 Implementation Script Plan implementation tasks using SUMP and SUMQ Allocate tasks to team members Conduct detailed design  Do design review using LOGD and LOGT Create unit test plan, test cases, procedures, and test data

INFO 637Lecture #1018 Implementation Script Inspect the detailed design for each component using INS and LOGD Create the code, and review it using code checklist  Record defects using LOGD and LOGT Do formal code inspection using INS and LOGD

INFO 637Lecture #1019 Implementation Script Have quality manager verify every component Release accepted components Hence the outputs from this script are:  Completed code  Forms INS, SUMP, SUMQ, LOGD, and LOGT  Test plans and materials (test cases, etc.)  Updated project notebook

INFO 637Lecture #1020 Test Scripts Test script includes:  Develop build, integration test, and system test procedures  Determine size, time, and materials needed for each test  Build the product  Conduct integration testing  Conduct system testing

INFO 637Lecture #1021 Test Scripts  Produce user documentation, review and fix it Outputs include  An integrated and tested product for this cycle  Completed LOGD and LOGTEST forms for all tests  Completed user documentation  Time, size, and defect data in TSP system

INFO 637Lecture #1022 Post Mortem Scripts The post mortem is started when the team has completed, tested, and documented this cycle’s product Review the SUMP and SUMQ forms from this cycle  Which processes worked, and which didn’t?  How did product quality compare to previous cycles (if any) or expectations?

INFO 637Lecture #1023 Post Mortem Scripts  Did process efficiency change much (e.g. the productivity measures)?  Were the roles successfully executed?  Were there any problems with any roles? Look for improvement ideas, and submit them on PIP forms Prepare a cycle report

INFO 637Lecture #1024 Cycle Report Each team member writes a description of  What did you produce?  What processes did you use?  What roles did you perform?  What worked, and what didn’t?  How well did your role work with the team?  How were you as a developer?

INFO 637Lecture #1025 Waterfall Similarities Notice that the combination of test planning with development phases is straight from classic waterfall structure  The system test plan is written with the system requirements  The integration test plan is written with the high level design  The unit test plan is written with detailed design (in the implementation phase)

INFO 637Lecture #1026 Continuous Evaluation and Improvement As each cycle progresses, earned value is tracked, and measures of quality, productivity, and defect removal effectiveness are made This forms, over many cycles, an objective basis for predicting future development efforts and truly understanding the caliber of work produced by your team

INFO 637Lecture #1027 That’s it! And that is the Team Software Process