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

INFO 637 Lecture #3 1

Software Engineering Process IILaunching & Strategy

INFO 637

Glenn Booker


Start the TSP

Start the TSP by formally Launching the project, and defining the Strategy to be used to approach it


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


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


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


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


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


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


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


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)


Product Objectives

For each objective, determine how you will evaluate the final product to show that the objective has been met


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


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


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


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


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


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


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?


Conceptual Design

Don’t overdo the conceptual design!!!Don’t commit the project to the first

design idea you have for solving itExpect that you will ultimately deviate

from your initial designThink of this as a rough outline, like

describing the chapters of a book


Development Strategy

This is outlining the cycles you will needFirst 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


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!


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


Document Strategy

Document your development strategy using the STRAT form (p. 61)


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


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


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

Documents

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