INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker

INFO 637Lecture #32 Start the TSP Start the TSP by formally Launching the project, and defining the Strategy to be used to approach it

INFO 637Lecture #33 Launching a Team Project A formal launch is needed to:  Establish working relationships  Determine member roles  Agree on goals Even a little time establishing the team pays off nicely later on

INFO 637Lecture #34 Team Goals Goals need to be tough enough to be challenging, but not impossible either Need to define how goals will be measured, so can you know if you achieved them The TSP has many predefined goals for each activity and role, but these might not be quite right for your team

INFO 637Lecture #35 Setting Team Goals To set goals for your team  Write down the goals you have chosen  Describe how you will measure those goals  Describe why you selected those goals instead of the standard TSP goals  Give the goals to your team and the instructor  Have Team Leader put goals in your project notebook

INFO 637Lecture #36 General Team Goals The most basic TSP goals for the team are:  Produce a quality product  Run a productive and well-managed project  Finish on time From this foundation you need to define meaningful measures to determine if you accomplish these goals

INFO 637Lecture #37 General Team Member Goals Each team member, regardless of role, has common goals as well  Be a cooperative and effective team member  Do consistently disciplined personal work  Plan and track all your personal work  Produce quality products

INFO 637Lecture #38 Specific Role Goals Each leadership role has specific goals, which were covered two weeks ago So each person on a TSP team has goals from several sources, all at once:  General team goals  General team member goals  Specific role goals

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

INFO 637Lecture #310 Product Objectives The product objectives are the requirements your product should meet by the end of its development  Each objective needs a priority (required, desirable, or optional)  Each objective needs a cycle when it will be created (though you’ll only develop the first cycle)

INFO 637Lecture #311 Product Objectives  For each objective, determine how you will evaluate the final product to show that the objective has been met

INFO 637Lecture #312 First Team Meeting The first team meeting allows you to:  Discuss and choose team roles  Agree on cycle 1 goals  Establish when the team will meet (if done synchronously)  Agree when weekly data will be due to the planning manager

INFO 637Lecture #313 First Team Meeting Team meetings are held using the WEEK script (p. 44)  You won’t have plans for comparison yet, but you can report effort to date and share any issues you’ve identified Once tasks have been defined, the TASK and SCHEDULE forms will be used each week to prep for the weekly team meeting

INFO 637Lecture #314 Data Requirements In order to form a consistent basis for reporting progress, you need to agree on a time period for reporting weekly progress  Generally done a little before the weekly meeting, to give the planning manager time to consolidate results

INFO 637Lecture #315 Other Launch Issues Start the project notebook, per Appendix G  Identify inputs needed for the notebook Determine if you’ll use the TSPi support tool; and if not, determine how the data will be consolidated each week

INFO 637Lecture #316 Development Strategy This phase is the determining the approach and general scope for your project We need to plan our work in order to:  Share a common understanding of what will be done  Form a basis for tracking progress  Help ensure schedule commitments are realistic

INFO 637Lecture #317 Development Strategy Script Key steps in this phase are:  Create Conceptual Design  Define Development Strategy  Estimate Product  Assess Risks  Document Strategy  Define Configuration Management Plan

INFO 637Lecture #318 Conceptual Design The conceptual design is the roughest guess of what your product will be and how you could create it Given a rough idea of your product:  How might you build it?  What major components would be needed?  What would each component do?  How big would these components be?

INFO 637Lecture #319 Conceptual Design Don’t overdo the conceptual design!!! Don’t commit the project to the first design idea you have for solving it Expect that you will ultimately deviate from your initial design Think of this as a rough outline, like describing the chapters of a book

INFO 637Lecture #320 Development Strategy This is outlining the cycles you will need First cycle is what is needed to product a working non-trivial product; the framework for the rest of the product Each cycle after that is devoted to a set of objectives which can be grouped together by functionality and/or urgency

INFO 637Lecture #321 Estimate Product Based on the conceptual design, develop rough estimates of size and time to create each part of the current cycle, and subsequent cycles Use your PSP experience to guide your early estimates; and don’t expect them to be perfect!

INFO 637Lecture #322 Assess Risks Determine what risks your project might face Assign High/Medium/Low to the likelihood of that risk occurring, and to the impact it would have on the project Discuss significant risks at the next weekly meeting

INFO 637Lecture #323 Document Strategy Document your development strategy using the STRAT form (p. 61)

INFO 637Lecture #324 Configuration Management Plan Determine how support manager will manage your product’s configuration Need to maintain copies of all versions of each product Record all changes made to the product baseline (who, when, what, and why was something changed?)

INFO 637Lecture #325 Configuration Management Plan Good CM is critical to success, because you need to be able to back out of a failed new version, and go back to the last version that worked  Without clear configuration control, you can’t do this!  Don’t need to automate CM functions; just define how they are done

INFO 637Lecture #326 Configuration Management The core CM functions are:  When does a module first formally exist as part of the baseline?  How does someone get permission to change a module (check out)?  How are those changes incorporated into the product (check in)?  How is the product built? Will address testing later