Unit 5

3640003 - Software Engineering (SE)
Unit - 5
1

Product Metrics and
Software Project Estimation
2

Software cost and effort estimation will never be an exact science. Too many
variables—human, technical, environmental, political—can affect the ultimate
cost of software and effort applied to develop it.
However, software project estimation can be transformed from a black art to a
series of systematic steps that provide estimates with acceptable risk.
To achieve reliable cost and effort estimates, a number of options arise:
1. Delay estimation until late in the project (obviously, we can achieve 100
percent accurate estimates after the project is complete!).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and
effort estimates.
4. Use one or more empirical models for software cost and effort estimation.
3

Unfortunately, the first option, however attractive, is not practical. The second
option can work reasonably well, if the current project is quite similar to past
efforts and other project influences (e.g., the customer, business conditions, the
software engineering environment, deadlines) are roughly equivalent.
Unfortunately, past experience has not always been a good indicator of future
results. The remaining options are viable approaches to software project
estimation.
Decomposition techniques take a divide-and-conquer approach to software
project estimation. By decomposing a project into major functions and related
software engineering activities, cost and effort estimation can be performed in a
stepwise fashion.
Empirical estimation models can be used to complement decomposition
techniques and offer a potentially valuable estimation approach in their own
right. A model is based on experience (historical data) and takes the form
d = f (vi) where d is one of a number of estimated values
(e.g., effort, cost, project duration) and vi are selected independent parameters
(e.g., estimated LOC or FP). 4

Automated estimation tools implement one or more decomposition techniques
or empirical models and provide an attractive option for estimating. In such
systems, the characteristics of the development organization (e.g., experience,
environment) and the software to be developed are described. Cost and effort
estimates are derived from these data.
Each of the viable software cost estimation options is only as good as the
historical data used to seed the estimate. If no historical data exist, costing rests
on a very shaky(unstable) foundation.
5

Decomposition Techniques
Software project estimation is a form of problem solving, and in most cases, the
problem to be solved (i.e., developing a cost and effort estimate for a software
project) is too complex to be considered in one piece. For this reason, you
should decompose the problem, recharacterizing it as a set of smaller (and
hopefully, more manageable) problems.
Estimation uses one or both forms of partitioning i.e. decomposition of the
problem and decomposition of the process. But before an estimate can be
made, you must understand the scope of the software to be built and generate
an estimate of its “size.”
1. Software Sizing :
The accuracy of a software project estimate is predicated on a number of things:
(1) the degree to which you have properly estimated the size of the product to
be built; (2) the ability to translate the size estimate into human effort, calendar
time, and dollars (a function of the availability of reliable software metrics from
past projects); (3) the degree to which the project plan reflects the abilities of
the software team; and (4) the stability of product requirements and the
environment that supports the software engineering effort. 6

Software Sizing cont..
If a direct approach is taken, size can be measured in lines of code (LOC). If an
indirect approach is chosen, size is represented as function points (FP).
Four different approaches to the sizing problem:
1.“Fuzzy logic” sizing : This approach uses the approximate reasoning
techniques
that are the cornerstone of fuzzy logic. To apply this approach, the planner must
identify the type of application, establish its magnitude on a qualitative scale,
and then refine the magnitude within the original range.
2. Function point sizing : The planner develops estimates of the information
domain characteristics
3.Standard component sizing : Software is composed of a number of different
“standard components” that are generic to a particular application area. For
example, the standard components for an information system are subsystems,
modules, screens, reports, interactive programs, batch programs, files, LOC, and
object-level instructions. The project planner estimates the number of
occurrences of each standard component and then uses historical project data
to estimate the delivered size per standard component.
7

Software Sizing cont..
4. Change sizing : This approach is used when a project encompasses the use of
existing software that must be modified in some way as part of a project. The
planner estimates the number and type (e.g., reuse, adding code, changing
code, deleting code) of modifications that must be accomplished.
Problem-Based Estimation
Lines of code and function points were described as measures from which
productivity metrics can be computed.
LOC and FP data are used in two ways during software project estimation:
(1) as estimation variables to “size” each element of the software and
(2) as baseline metrics collected from past projects and used in conjunction with
estimation variables to develop cost and effort projections.
8

Problem-Based Estimation cont..
LOC and FP estimation are distinct estimation techniques. Yet both have a
number of characteristics in common. LOC or FP (the estimation variable) is then
estimated for each function. Alternatively, you may choose another component
for sizing, such as classes or objects, changes, or business processes affected.
Baseline productivity metrics (e.g., LOC/pm or FP/pm) are then applied to the
appropriate estimation variable, and cost or effort for the function is derived.
Function estimates are combined to produce an overall estimate for the entire
project.
In general, LOC/pm or FP/pm averages should be computed by project domain.
That is, projects should be grouped by team size, application area, complexity,
and other relevant parameters.
The LOC and FP estimation techniques differ in the level of detail required for
decomposition and the target of the partitioning.
9

When LOC is used as the estimation variable, decomposition is absolutely
essential and is often taken to considerable levels of detail. The greater the
degree of partitioning, the more likely reasonably accurate estimates of LOC can
be developed.
For FP estimates, decomposition works differently. Rather than focusing on
function, each of the information domain characteristics—inputs, outputs, data
files, inquiries, and external interfaces—as well as the complexity adjustment
values are estimated. The resultant estimates can then be used to derive an FP
value that can be tied to past data and used to generate an estimate.
Regardless of the estimation variable that is used, you should begin by
estimating a range of values for each function or information domain value.
Using historical data or (when all else fails) intuition, estimate an optimistic,
most likely, and pessimistic size value for each function or count for each
information domain value. An implicit indication of the degree of uncertainty is
provided when a range of values is specified.
10

A three-point or expected value can then be computed. The expected value for
the estimation variable (size) S can be computed as a weighted average of the
optimistic (sopt ), most likely (sm), and pessimistic (spess) estimates.
Once the expected value for the estimation variable has been determined,
historical LOC or FP productivity data are applied.
11

Process -Based Estimation :
The most common technique for estimating a project is to base the estimate on
the process that will be used. That is, the process is decomposed into a
relatively small set of tasks and the effort required to accomplish each task is
estimated.
Like the problem-based techniques, process-based estimation begins with a
delineation of software functions obtained from the project scope. A series of
framework activities must be performed for each function.
Once problem functions and process activities are melded, you estimate the
effort (e.g., person-months) that will be required to accomplish each software
process activity for each software function.
Costs and effort for each function and framework activity are computed as the
last step. If process-based estimation is performed independently of LOC or FP
estimation, we now have two or three estimates for cost and effort that may be
compared and reconciled. 12

Estimation with Use Cases :
However, developing an estimation approach with use cases is problematic for
the following reasons :
• Use cases are described using many different formats and styles—there is no
standard form.
• Use cases represent an external view (the user’s view) of the software and can
therefore be written at many different levels of abstraction.
• Use cases do not address the complexity of the functions and features that are
described.
• Use cases can describe complex behavior (e.g., interactions) that involve many
functions and features.
13

Reconciling (Integration) Estimate:
The estimation techniques discussed result in multiple estimates that must be
reconciled to produce a single estimate of effort, project duration, or cost.
The total estimated effort for the CAD software ranges from a low of 46
person/months (derived using a process-based estimation approach) to a high
of 68 person/months (derived with use-case estimation). The average estimate
(using all four approaches) is 56 person-months. The variation from the average
estimate is approximately 18 percent on the low side and 21 percent on the high
side.
Widely divergent (different) estimates can often be traced to one of two causes:
(1) the scope of the project is not adequately understood or has been
misinterpreted by the planner, or (2) productivity data used for problem-based
estimation techniques is inappropriate for the application, obsolete or has been
misapplied. You should determine the cause of divergence and then reconcile
the estimates.
14

Empirical Estimation Model
The empirical data that support most estimation models are derived from a
limited sample of projects. For this reason, no estimation model is
appropriate for all classes of software and in all development environments.
Therefore, you should use the results obtained from such models judiciously.
An estimation model should be calibrated to reflect local conditions. The
model should be tested by applying data collected from completed projects,
plugging the data into the model, and then comparing actual to predicted
results. If agreement is poor, the model must be tuned and retested before it
can be used.
The Structure of Estimation Models :
A typical estimation model is derived using regression analysis on data
collected from past software projects.
15

The Structure of Estimation Models cont..
The overall structure of such models takes the form where A, B, and C are
empirically derived constants, E is effort in person-months, and ev is the
estimation variable (either LOC or FP).
In addition to the relationship noted in Equation, the majority of estimation
models have some form of project adjustment component that enables E to be
adjusted by other project characteristics (e.g., problem complexity, staff
experience, development environment).
Among the many LOC-oriented estimation models proposed in the literature are
16

The Structure of Estimation Models cont..
FP-oriented models have also been proposed. These include
A quick examination of these models indicates that each will yield a different
result for the same values of LOC or FP. The implication is clear. Estimation
models must be calibrated for local needs!
17

The COCOMO II Model :
A hierarchy of software estimation models bearing the name COCOMO, for
COnstructive COst MOdel. The original COCOMO model became one of the
most widely used and discussed software cost estimation models in the
industry. It has evolved into a more comprehensive estimation model, called
COCOMOII .
Like its predecessor, COCOMO II is actually a hierarchy of estimation models
that address the following areas:
Application composition model :
Used during the early stages of software engineering, when prototyping of
user interfaces, consideration of software and system interaction,
assessment of performance, and evaluation of technology maturity are
paramount
18

The COCOMO II Model cont..
Early design stage model :
Used once requirements have been stabilized and basic software
architecture has been established.
Post-architecture-stage model : Used during the construction of the
software.
Like all estimation models for software, the COCOMO II models require
sizing information. Three different sizing options are available as part of the
model hierarchy: object points, function points, and lines of source code.
Like function points, the object point is an indirect software measure that is
computed using counts of the number of (1) screens (at the user interface),
(2) reports, and (3) components likely to be required to build the
application.
Each object instance (e.g., a screen or report) is classified into one of three
complexity levels (i.e., simple, medium, or difficult) 19

Once complexity is determined, the number of screens, reports, and
components are weighted. The object point count is then determined by
multiplying the original number of object instances by the weighting factor in
the figure and summing to obtain a total object point count.
When component-based development or general software reuse is to be
applied, the percent of reuse (%reuse) is estimated and the object point count is
adjusted:
where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, a
“productivity rate” must be derived. Productivity rate for different levels of
developer experience and development environment maturity.
20

An estimate of project effort is computed using :
The Software Equation :
The software equation is a dynamic multivariable model that assumes a specific
distribution of effort over the life of a software development project. The model
has been derived from productivity data collected for over 4000 contemporary
software projects. Based on these data, we derive an estimation model of the
form
21

The Software Equation cont..
Typical values might be P = 2000 for development of real-time embedded
software, P = 10,000 for telecommunication and systems software, and
P = 28,000 for business systems applications.
You should note that the software equation has two independent parameters:
(1) an estimate of size (in LOC) and
(2) an indication of project duration in calendar months or years.
A set of equations derived from the software equation. Minimum development
time is defined as :
22

Estimation For Object Oriented Projects
It is worthwhile to supplement conventional software cost estimation methods
with a technique that has been designed explicitly for OO software.
Some Approaches :
1. Develop estimates using effort decomposition, FP analysis, and any other
method that is applicable for conventional applications.
2. Using the requirements model , develop use cases and determine a count.
Recognize that the number of use cases may change as the project progresses.
3. From the requirements model, determine the number of key classes.
4. Categorize the type of interface for the application
and develop a multiplier for support classes:
Multiply the number of key classes (step 3) by the
multiplier to obtain an estimate for the number of
support classes. 23

Estimation For Object Oriented Projects
5. Multiply the total number of classes (key + support) by the average number of
work units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.
6. Cross-check the class-based estimate by multiplying the average number of
work units per use case.
24

Overview of Project Scheduling
Although there are many reasons why software is delivered late, most can be
traced to one or more of the following root causes:
• An unrealistic deadline established by someone outside the software team
and forced on managers and practitioners.
• Changing customer requirements that are not reflected in schedule changes.
• An honest underestimate of the amount of effort and/or the number of
resources that will be required to do the job.
• Predictable and/or unpredictable risks that were not considered when the
project commenced.
• Technical difficulties that could not have been foreseen in advance.
• Human difficulties that could not have been foreseen in advance.
• Miscommunication among project staff that results in delays.
• A failure by project management to recognize that the project is falling behind
schedule and a lack of action to correct the problem.
25

How to overcome from this situation :
1. Perform a detailed estimate using historical data from past projects.
Determine the estimated effort and duration for the project.
2. Using an incremental process model, develop a software engineering strategy
that will deliver critical functionality by the imposed deadline, but delay other
functionality until later. Document the plan.
3. Meet with the customer and (using the detailed estimate), explain why the
imposed deadline is unrealistic. Be certain to note that all estimates are based
on performance on past projects. Also be certain to indicate the percent
improvement that would be required to achieve the deadline as it currently
exists
4. Offer the incremental development strategy as an alternative
26

Project Scheduling :
Software project scheduling is an action that distributes estimated effort across
the planned project duration by allocating the effort to specific software
engineering tasks. It is important to note, however, that the schedule evolves
over time. During early stages of project planning, a macroscopic schedule is
developed.
This type of schedule identifies all major process framework activities and the
product functions to which they are applied. As the project gets under way, each
entry on the macroscopic schedule is refined into a detailed schedule. Here,
specific software actions and tasks (required to accomplish an activity) are
identified and scheduled.
Scheduling for software engineering projects can be viewed from two rather
different perspectives. In the first, an end date for release of a computer-based
system has already (and irrevocably) been established.
27

Basic Principles :
Like all other areas of software engineering, a number of basic principles guide
software project scheduling:
Compartmentalization : The project must be compartmentalized into a number
of manageable activities and tasks. To accomplish compartmentalization, both
the product and the process are refined.
Interdependency : The interdependency of each compartmentalized activity or
task must be determined. Some tasks must occur in sequence, while others can
occur in parallel. Some activities cannot commence until the work product
produced by another is available. Other activities can occur independently.
Time allocation : Each task to be scheduled must be allocated some number of
work units (e.g., person-days of effort). In addition, each task must be assigned a
start date and a completion date that are a function of the interdependencies
and whether work will be conducted on a full-time or part-time basis. 28

Basic Principles cont..
Effort validation : Every project has a defined number of people on the software
team. As time allocation occurs, you must ensure that no more than the
allocated number of people has been scheduled at any given time. For example,
consider a project that has three assigned software engineers (e.g., three
person-days are available per day of assigned effort). On a given day, seven
concurrent tasks must be accomplished. Each task requires 0.50 person-days of
effort. More effort has been allocated than there are people to do the work.
Defined responsibilities : Every task that is scheduled should be assigned to a
specific team member.
Defined outcomes : Every task that is scheduled should have a defined
outcome. For software projects, the outcome is normally a work product (e.g.,
the design of a component) or a part of a work product. Work products are
often combined in deliverables.
29

The Relationship Between People and Effort
In a small software development project a single person can analyze
requirements, perform design, generate code, and conduct tests. As the size of a
project increases, more people must become involved
30

The Relationship Between People and Effort cont..
Curve provides an indication of the relationship between effort applied and
delivery time for a software project. A version of the curve, representing project
effort as a function of delivery time, is shown in Figure.
The curve indicates a minimum value to that indicates the least cost for delivery
(i.e., the delivery time that will result in the least effort expended). As we move
left of to (i.e., as we try to accelerate delivery), the curve rises nonlinearly.
Although it is possible to accelerate delivery, the curve rises very sharply to the
left of td.
31

Effort Distribution :
A recommended distribution of effort across the software process is often
referred to as the 40–20–40 rule. Forty percent of all effort is allocated to
frontend analysis and design. A similar percentage is applied to back-end
testing. You can correctly infer that coding (20 percent of effort) is
deemphasized.
This effort distribution should be used as a guideline only. The
characteristics of each project dictate the distribution of effort. Work
expended on project planning rarely accounts for more than 2 to 3 percent
of effort. Customer communication and requirements analysis may comprise
10 to 25 percent of project effort. A range of 20 to 25 percent of effort is
normally applied to software design. Time expended for design review and
subsequent iteration must also be considered.
Range of 15 to 20 percent of overall effort can be achieved for software design
and coding and testing and subsequent debugging can account for 30 to 40
percent of software development effort.
32

Scheduling
Scheduling of a software project does not differ greatly from scheduling of any
multitask engineering effort. Therefore, generalized project scheduling tools and
techniques can be applied with little modification for software projects.
Program evaluation and review technique (PERT) and the critical path method
(CPM) are two project scheduling methods that can be applied to software
development.
Both techniques are driven by information already developed in earlier project
planning activities: estimates of effort, a decomposition of the product function,
the selection of the appropriate process model and task set, and decomposition
of the tasks that are selected.
Interdependencies among tasks may be defined using a task network. Tasks,
sometimes called the project work breakdown structure (WBS), are defined for
the product as a whole or for individual functions.
33

Scheduling
Both PERT and CPM provide quantitative tools that allow you to
(1) determine the critical path—the chain of tasks that determines the duration
of the project,
(2) establish “most likely” time estimates for individual tasks by applying
statistical models, and
(3) calculate “boundary times” that define a time “window” for a particular task.
Time Line Charts :
When creating a software project schedule, you begin with a set of tasks (the
work breakdown structure). If automated tools are used, the work breakdown is
input as a task network or task outline. Effort, duration, and start date are then
input for each task.
In addition, tasks may be assigned to specific individuals. As a consequence of
this input, a time-line chart, also called a Gantt chart, is generated. A time-line
chart can be developed for the entire project. Alternatively, separate charts can
be developed for each project function or for each individual working on the
project. 34

Scheduling
Time Line Charts cont..
35

Scheduling
Time Line Charts cont..
Time-line chart depicts a part of a software project schedule that emphasizes
the concept scoping task for a word-processing (WP) software product. All
project tasks (for concept scoping) are listed in the left hand column. The
horizontal bars indicate the duration of each task.
When multiple bars occur at the same time on the calendar, task concurrency is
implied. The diamonds indicate milestones.
Once the information necessary for the generation of a time-line chart has been
input, the majority of software project scheduling tools produce project tables—
a tabular listing of all project tasks, their planned and actual start and end dates,
and a variety of related information. Used in conjunction with the time-line
chart, project tables enable you to track progress.
36

Tracking the Schedule
If it has been properly developed, the project schedule becomes a road
map that defines the tasks and milestones to be tracked and controlled
as the project proceeds. Tracking can be accomplished in a number of
different ways:
• Conducting periodic project status meetings in which each team
member reports progress and problems
• Evaluating the results of all reviews conducted throughout the
software engineering process
• Determining whether formal project milestones (the diamonds shown
in Figure 27.3) have been accomplished by the scheduled date
•Comparing the actual start date to the planned start date for each
project task listed in the resource table (Figure 27.4)
• Meeting informally with practitioners to obtain their subjective
assessment of progress to date and problems on the horizon
• Using earned value analysis (Section 27.6) to assess progress
quantitatively 37

• In reality, all of these tracking techniques are used by experienced
project managers.
• Control is employed by a software project manager to administer
project resources, cope with problems, and direct project staff. If
things are going well (i.e., the project is on schedule and within
budget, reviews indicate that real progress is being made and
milestones are being reached), control is light. But when problems
occur, you must exercise control to reconcile them as quickly as
possible. After a problem has been diagnosed, additional resources
may be focused on the problem area: staff may be redeployed or the
project schedule can be redefined.
• When faced with severe deadline pressure, experienced project
managers sometimes use a project scheduling and control technique
called time-boxing. The time-boxing strategy recognizes that the
complete product may not be deliverable by the predefined deadline.
Therefore, an incremental software paradigm (Chapter 2) is chosen,
and a schedule is derived for each incremental delivery. 38

Tracking Progress for an OO Project
• Although an iterative model is the best framework for an OO
project, task parallelism makes project tracking difficult. You
may have difficulty establishing meaningful milestones for an
OO project because a number of different things are happening
at once. In general, the following major milestones can be
considered “completed” when the criteria noted have been
met.
Technical milestone: OO analysis completed
• All classes and the class hierarchy have been defined and
reviewed.
• Class attributes and operations associated with a class have been
defined and reviewed.
• Class relationships (Chapter 6) have been established and
reviewed.
• A behavioral model (Chapter 7) has been created and reviewed.
• Reusable classes have been noted. 39

Technical milestone: OO design completed
• The set of subsystems has been defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and reviewed.
• Responsibilities and collaborations have been identified.
• Attributes and operations have been designed and reviewed.
• The communication model has been created and reviewed.
Technical milestone: OO programming completed
• Each new class has been implemented in code from the design model.
• Extracted classes (from a reuse library) have been implemented.
• Prototype or increment has been built.
40

Technical milestone: OO testing
• The correctness and completeness of OO analysis and design models
has been reviewed.
• A class-responsibility-collaboration network has been developed and
reviewed.
• Test cases are designed, and class-level tests have been conducted for
each class.
• Test cases are designed, and cluster testing is completed and the
classes are integrated.
• System-level tests have been completed.
41

Scheduling for WebApp Projects
• WebApp project scheduling distributes estimated effort across the
planned time line (duration) for building each WebApp increment.
• This is accomplished by allocating the effort to specific tasks. It is
important to note, however, that the overall WebApp schedule
evolves over time.
• During the first iteration, a macroscopic schedule is developed.
• This type of schedule identifies all WebApp increments and projects
the dates on which each will be deployed. As the development of an
increment gets under way, the entry for the increment on the
macroscopic schedule is refined into a detailed schedule. Here,
specific development tasks (required to accomplish an activity) are
identified and scheduled.
42

• As an example of macroscopic scheduling, consider the
SafeHomeAssured.com WebApp. Recalling earlier
discussions of SafeHomeAssured.com, seven increments
can be identified for the Web-based component of the
project:
• Increment 1: Basic company and product information
• Increment 2: Detailed product information and downloads
• Increment 3: Product quotes and processing product orders
• Increment 4: Space layout and security system design
• Increment 5: Information and ordering of monitoring
services
• Increment 6: Online control of monitoring equipment
• Increment 7: Accessing account information
43

• The team consults and negotiates with stakeholders
and develops a preliminary deployment schedule
for all seven increments. A time-line chart for this
schedule is illustrated in Figure.
44

• It is important to note that the deployment dates
(represented by diamonds on the time-line chart)
are preliminary and may change as more detailed
scheduling of the increments occurs. However, this
macroscopic schedule provides management with
an indication of when content and functionality will
be available and when the entire project will be
completed.
• As a preliminary estimate, the team will work to
deploy all increments with a 12-week time line. It’s
also worth noting that some of the increments will
be developed in parallel (e.g., increments 3, 4, 6
and 7). This assumes that the team will have
sufficient people to do this parallel work.
46

• Once the macroscopic schedule has been developed, the team is
ready to schedule work tasks for a specific increment. To accomplish
this, you can use a generic process framework that is applicable for all
WebApp increments. A task list is created by using the generic tasks
derived as part of the framework as a starting point and then
adapting these by considering the content and functions to be
derived for a specific WebApp increment.
• Each framework action (and its related tasks) can be adapted in one
of four ways:
• (1) a task is applied as is, (2) a task is eliminated because it is not
necessary for the increment, (3) a new (custom) task is added, and (4)
a task is refined (elaborated) into a number of named subtasks that
each becomes part of the schedule.
47

• To illustrate, consider a generic design modeling action for
WebApps that can be accomplished by applying some or all
of the following tasks:
• Design the aesthetic for the WebApp.
• Design the interface.
• Design the navigation scheme.
• Design the WebApp architecture.
• Design the content and the structure that supports it.
• Design functional components.
• Design appropriate security and privacy mechanisms.
• Review the design.
48

• As an example, consider the generic task Design the
Interface as it is applied to the
• fourth increment of SafeHomeAssured.com. Recall that
the fourth increment implements the content and function
for describing the living or business space to be secured by
the SafeHome security system. Referring to Figure 27.5, the
fourth increment commences at the beginning of the fifth
week and terminates at the end of the ninth week.
• There is little question that the Design the Interface task
must be conducted.
• The team recognizes that the interface design is pivotal to
the success of the increment and decides to refine
(elaborate) the task. The following subtasks are derived for
the Design the Interface task for the fourth increment:
49

• Develop a sketch of the page layout for the space design page.
• Review layout with stakeholders.
• Design space layout navigation mechanisms.
• Design “drawing board” layout.10
• Develop procedural details for the graphical wall layout function.
• Develop procedural details for the wall length computation and
display function.
• Develop procedural details for the graphical window layout function.
• Develop procedural details for the graphical door layout function.
• Design mechanisms for selecting security system components
(sensors, cameras, microphones, etc.).
• Develop procedural details for the graphical layout of security system
components.
• Conduct pair walkthroughs as required.
50

• These tasks become part of the increment
schedule for the fourth WebApp increment and
are allocated over the increment development
schedule. The can be input to scheduling
software and used for tracking and control.
51

Unit 5

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Unit 5

Similar to Unit 5 (20)

More from Jignesh Kariya

More from Jignesh Kariya (17)

Recently uploaded

Recently uploaded (20)

Unit 5