0% found this document useful (0 votes)

56 views

TMP3413 Software Engineering Lab: The Development Strategy

The document discusses the importance of developing a strategy before starting a software project. It explains that a strategy should include development increments, version content, integration and testing plans, and prototypes needed. It also discusses estimating size and time, revising estimates if needed, conceptual design, planning alternatives and risks, and documenting the selected strategy. The strategy script provides steps for teams to follow to develop their strategy.

Uploaded by

Nurfauza Jali

0% found this document useful (0 votes)

56 views

TMP3413 Software Engineering Lab: The Development Strategy

Uploaded by

Nurfauza Jali

You are on page 1/ 26

TMP3413

Software
Engineering Lab

Lecture 04:
The Development
Strategy
Development Strategy
 The development strategy is the “big picture” view of
the development effort.
 Development increments and builds.
 General version content and freeze points.
 Prototypes needed.
 Integration and test strategy.

 Devise strategy for doing the work that has been

planned in the launch step.
 Create a conceptual product design.
 Make a preliminary estimate of the product’s size.
 Estimate the development time.

 Revise the strategy if the estimated time exceeds the

available time until the work fits the available time.
 TSP
requires that you make a plan before you
produce the requirements.

How to
plan??
Planning Before Committing
 There are three reasons for planning before
starting a project:
1. In the process of developing a plan, teams gain
a common appreciation of the work they must
do.
2. The plan provides the basis for tracking the
work. This information helps teams to estimate
when they will finish and it provides early
warning of likely problems.
3. If they don’t start by making a plan and
reviewing it with their managers (or instructors),
teams end up committed to the managers’
date whether or not they believe they can
meet it.
Planning for This Course
 You have been given a product definition and a fixed
course schedule on which to build it.

What do you
think??

Can you do the

job or not??

 Developing a strategy is the first step to find out.

 Start by making a plan – examine the job and tell the

instructor what you can do and how long it will take.
Planning for This Course … cont
 The focus of this course is to expose
students to the methods needed for larger
projects.

 Thestrategy and planning steps will take a

larger proportion of this project.

 Therefore, students will get valuable

experience with the kind of schedule-
resource-requirements negotiations you will
face in the future.
 In TSP, we have already made a basic strategic
decision:
 We will develop the product with a cyclic process.

 The number of development cycles was decided by

the instructor when the course was scheduled, but
the content of the cycles is up to you(student).

 The development process starts with:

 First cycle – you design, implement and test a basic
product version;
 Second cycle – you enhance this product to produce
a second version;
 Finally, if there is time, you produce a third product
version.
 Conceptual design is the starting point for
project planning. The reason you need a
conceptual design is that you must make a plan
for building a product.

 To make a conceptual design, we need to ask

ourselves these four questions:
1. Based on what I know, how would I build this
product?
2. What are the principal components I will need to
build this product?
3. What functions must these components provide?
4. How big do I think these components will be?
 Must not be too detailed until it produce much
of the product design during planning.

 Should produce the design concept and

general product structure, but leave any real
design work until you have analysed and
inspected the requirements.

 Important info. on conceptual design:

 Can estimate the product size and time required
to develop it.
 Only a planning tool.
 In establishing a strategy, we must:

1. Define the strategy criteria.

2. Determine the possible alternative strategies.
3. Identify the risks and benefits of each
alternative strategy.
4. Make a comparative evaluation of these
alternatives.
5. Make the strategic decision.
6. Document the selected strategy.
Something Something
that may RISK that may not
happen happen

 Managing risks early in the project is

beneficial because most risks can be
avoided or controlled if you think about
them in advance and take adequate
mitigation steps.
Examples of Risks Students May
Face in This Course
Attempt to build too large a product, causing
student to run out of time.

Students encounter one or more functions

that they don’t know how to design.

Run into support systems problems that delay the

work.

The product may be so defective that

testing takes too long.

Students might lose control of the product or

product changes and waste time reconstructing
programs they have already developed.

The team may not be able to work

together effectively.
Managing Risk
 For the risks mentioned earlier, effective
mitigation actions might include the following:

1. Too large a product. Start with a small kernel

product and then add functions in later
development cycles.

2. Difficult or complex functions. Prototype these

functions at the beginning of the project, when
you have time to consider alternatives.

3. Support system problems. Build an early

prototype or small product version to make sure
that you know how the support system works.
Managing Risk … cont
4. Testing Time. If you consistently follow the TSP and
use disciplined PSP methods, your product will
have few defects and testing will not be a
problem.

5. Product Control. It is easy for teams to lose

control of their products. This is why TSP addresses
configuration management at the beginning of
the project.

6. Teamwork Problems. If your team is having

trouble working together, discuss the problems
openly to see whether you can resolve them. If
the problems persist, get help from the instructor.
Reuse Strategy
 Reuse @ Reusability – Definition:
 The likelihood that a segment of source code can
be used again to add new functionalities with
slight or no modification.

 Useful for managing risk in code growth of

software project, in which functions require
more code than expected.

 This strategy can reduce the required

development effort, implementation time and
testing time (assuming prior testing has been
conducted to eliminate bugs).
The TSP Strategy Script
Entry Criteria

 The instructor has reviewed and discussed

the TSP process.
 The instructor has described the overall
product objectives.
 Development teams have been formed
and roles assigned.
 The teams have agreed on goals for their
teams.
The TSP Strategy Script
Step 1: Strategy Overview

 The instructor describes the development

strategy:
 What the strategy is, how it is produced, and
how it is used.
 Criteria for an effective strategy.
 The need for and ways to produce the size
and time estimates.
The TSP Strategy Script
Step 2: Establish Strategy Criteria

 The development manager leads discussion

of strategy criteria.
 The meeting reporter (quality/process
manager) documents these criteria and
provides copies to the team members and
instructor.
The TSP Strategy Script
Step 3: Produce the Conceptual Design

 The development manager leads the team

in producing the conceptual design for the
overall product.
The TSP Strategy Script
Step 4: Select the Development Strategy

 The development manager leads the team

in producing the development strategy. This
involves:
 Proposing and evaluating alternative
strategies.
 Allocating product functions to each
development cycle.
 Defining how to subdivide and later integrate
the product.
The TSP Strategy Script
Step 5: Produce the Preliminary Estimate

 The planning manager leads the team

through producing the preliminary size and
time estimates, which must include:
 Size and time estimates for all the current-
cycle products.
 Rough estimates for the products of
subsequent cycles.
The TSP Strategy Script
Step 6: Assess Risks

 Identify
and assess project risks and
document them.
The TSP Strategy Script
Step 7: Document the Strategy

 The meeting reporter documents the

selected strategy.
The TSP Strategy Script
Step 8: Update the Development Strategy

 The support manager leads the team in

reviewing and updating the development
strategy.
The TSP Strategy Script
Exit Criteria

 A completed and documented development

strategy.
 Completed and documented size and time
estimates for all product elements to be
produced during the next cycle.
 Completed and documented estimates for the
products to be produced in the subsequent
development cycles.
 Documented risks and issues.
 Conceptual design.
 Updated project notebook.