Software engneering Module 2 Notes

Dept of Computer Science and Engineering CML

__________________________________________________________________________________________ CS010 605 /SOFTWARE ENGINEERING Page No:1 Prepared By: Merin Mary Philip

Module 2 Topics

1. Management: Functions

2. Project planning - Software productivity -Productivity metrics

3. Cost estimation - COCOMO & COCOMO II

4. Project control - Work breakdown structures, Gantt charts, PERT charts - Dealing with deviations

5. Team organization - centralized, de-centralized, mixed - An assessment of organizations

6. Risk management

7. Configuration Management

8. Introduction to project management and planning CASE tools.

1. Management: Functions

1.1 Management Functions

i. Software engineering projects involve many software engineers.

ii. Management is needed to coordinate the activities and resources involved in projects.

iii. The main job of Management is to enable a group of people to work towards a common goal.

iv. Management Functions can be broadly divided into these interrelated activities, the goal of which is to

achieve effective group work :-

1. Planning

2. Organizing

3. Staffing

4. Directing

5. Controlling

1. Planning

Planning involves determining the flow of information, people and products within the organization.

A Manager must decide what objectives are to be achieved , what resources are required to achieve the

objectives, how and when the resources are to be acquired , and how the objective are to be achieved.

2. Organizing

Organizing involves the establishment of clear lines of authority and responsibility for groups of activities

that achieve achieve the goals of the enterprise.

Organizing is necessary at the level of small group.

Choice of organizational structure affects the efficiency of enterprise.

3. Staffing

Staffing deals with hiring personnel for the positions that are identified by the organizational structure.

Staffing involves defining the requirements for personnel; recruiting and compensating , developing and

promoting employees.

4. Directing



Goal of directing is to guide the subordinates to undersatand and identify with the organizational structure and

goals of the enterprise.

Directing involves leading subordinates.

5. Controlling

Controlling consists of measuring and correcting activities to ensure that goals are achieved.

Controlling requires the measurement of performance against plans and taking corrective action when

deviations occur.

2. Project planning

Software project planning encompasses five major activities:-

1. Estimation

2. Scheduling

3. risk analysis

4. quality management planning

5. change management planning

Estimation determines how much money, effort, resources, and time it will take to build a specific system or product

The software team first estimates

o The work to be done

o The resources required

o The time that will elapse from start to finish

Then they establish a project schedule that

o Defines tasks and milestones

o Identifies who is responsible for conducting each task

o Specifies the inter-task dependencies

Task Set for Project Planning:-

1. Establish project scope

2. Determine feasibility

3. Analyze risks

4. Define required resources

a. Determine human resources required

b. Define reusable software resources

c. Identify environmental resources

5. Estimate cost and effort

a. Decompose the problem

b. Develop two or more estimates using different approaches

c. Reconcile the estimates

6. Develop a project schedule



a. Establish a meaningful task set

b. Define a task network

c. Use scheduling tools to develop a timeline chart

d. Define schedule tracking mechanisms

1. Establish project scope

The first activity in software project planning is the determination of software scope. Function and

performance allocated to software during system engineering should be assessed to establish a project

scope that is unambiguous and understandable at the management and technical levels. A statement of

software scope must be bounded. Software scope describes the data and control to be processed,

function, performance, constraints, interfaces, and reliability. Functions described in the statement of

scope are evaluated and in some cases refined to provide more detail prior to the beginning of

estimation.

2. Define required resources

The second software planning task is estimation of the resources required to accomplish the software

development effort. Figure 5.2 illustrates development resources as a pyramid. Three major categories

of software engineering resources

1. Human Resources

2. Development environment

3. Reusable software components



1. Human Resources

The planner begins by evaluating scope and selecting the skills required to complete development. Both

organizational position (e.g., manager, senior software engineer) and specialty (e.g.,

telecommunications, database, client/server) are specified. For relatively small projects (one person-

year or less), a single individual may perform all software engineering tasks, consulting with specialists

as required.

2. Reusable Software Resources

Component-based software engineering (CBSE) emphasizes reusabilitythat is, the creation and reuse

of software building blocks. Such building blocks, often called components, must be cataloged for easy

reference, standardized for easy application, and validated for easy integration. Bennatan suggests four

software resource categories that should be considered as planning proceeds:

Off-the-shelf components-Existing software that can be acquired from a third party or that has been

developed internally for a past project. COTS (commercial off-the-shelf) components are purchased

from a third party, are ready for use on the current project, and have been fully validated.

Full-experience components-Existing specifications, designs, code, or test data developed for past

projects that are similar to the software to be built for the current project. Members of the current

software team have had full experience in the application area represented by these components.

Therefore, modifications required for full-experience components will be relatively low-risk.

Partial-experience components- Existing specifications, designs, code, or test data developed for past

projects that are related to the software to be built for the current project but will require substantial

modification. Members of the current software team have only limited experience in the application

area represented by these components. Therefore, modifications required for partial-experience

components have a fair degree of risk.

New components-Software components that must be built by the software team specifically for the

needs of the current project.

3. Environmental Resources

The environment that supports the software project, often called the software engineering environment

(SEE), incorporates hardware and software. Hardware provides a platform that supports the tools

(software) required to produce the work products that are an outcome of good software engineering

practice.

3. Estimation of Project Cost and Effort

The accuracy of a software project estimate is predicated on



o The degree to which the planner has properly estimated the size (e.g., KLOC) of the product to be built

o The ability to translate the size estimate into human effort, calendar time, and money

o The degree to which the project plan reflects the abilities of the software team

o The stability of both the product requirements and the environment that supports the software

engineering effort

Project Estimation Approaches are:-

a) Decomposition techniques

o These take a "divide and conquer" approach

o Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major

functions and related software engineering activities.

b) Empirical estimation models

o Offer a potentially valuable estimation approach if the historical data used to seed the estimate is

good

4. Develop a project schedule

Software project scheduling is an activity 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 software engineering 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 tasks (required to accomplish an activity) are identified and scheduled.

principles guide software project scheduling:

I. Compartmentalization-The project must be compartmentalized into a number of manageable activities

and tasks.

II. Interdependency-The interdependency of each compartmentalized activity or task must be determined.

Some tasks must occur in sequence while others can occur in parallel.

III. Time allocation-Each task to be scheduled must be allocated some number of work units.

IV. Effort validation-Every project has a defined number of staff members. As time allocation occurs, the

project manager must ensure that no more than the allocated number of people have been scheduled at any

given time.

V. Defined responsibilities-Every task that is scheduled should be assigned to a specific team member.



VI. Defined outcomes-Every task that is scheduled should have a defined outcome.

VII. Defined milestones-Every task or group of tasks should be associated with a project milestone. A

milestone is accomplished when one or more work products has been reviewed for quality and has been

approved.

-----------------------------------------------------------------------------------------------------------------------------

2.1 Software productivity

Software Productivity can be measured in different ways. Software engineers spent up to half

their time spent in meetings, administrative matters and communication with team members. But

its important that productivity of the people and processes involved in software production is

measured.

2.1.1 Productivity metrics

An ideal productivity metric measure not lines of code, but the amount of value or functionality

produced per unit time. The problem that we have is no good way of quantifying the concept of

functionality. Because of the difficulty of the quantifying functionality , the search for a

productive metric has for the most part concentrated on the most tangible product of software

engineering; the actual code produced by the engineer. Uses of software product metrics are:-

Help software engineers to better understand the attributes of models and assess the quality of the

software

Help software engineers to gain insight into the design and construction of the software

Focus on specific attributes of software engineering work products resulting from analysis, design,

coding, and testing

Provide a systematic way to assess quality based on a set of clearly defined rules

Provide an on-the-spot rather than after-the-fact insight into the software development

Measurement Principles

Following are the measurement principles are:-

Formulation- The derivation (i.e., identification) of software measures and metrics appropriate

for the representation of the software that is being considered

Collection- The mechanism used to accumulate data required to derive the formulated metrics

Analysis-The computation of metrics and the application of mathematical tools



Interpretation-The evaluation of metrics in an effort to gain insight into the quality of the

representation

Feedback-Recommendations derived from the interpretation of product metrics and passed on to

the software development team.

Attributes of Effective Software Metrics

Attributes of Effective Software Metrics are:-

Simple and computable- It should be relatively easy to learn how to derive the metric, and its

computation should not demand inordinate effort or time

Empirically and intuitively persuasive- The metric should satisfy the engineers intuitive

notions about the product attribute under consideration

Consistent and objective- The metric should always yield results that are unambiguous.

Consistent in the use of units and dimensions- The mathematical computation of the metric

should use measures that do not lead to bizarre combinations of units.

Programming language independent- Metrics should be based on the analysis model, the

design model, or the structure of the program itself.

An effective mechanism for high-quality feedback- The metric should lead to a higher-quality

end product.

DIFFERENT KINDS OF PRODUCTIVITY METRICS ARE:-

1. Metrics for Requirements Model (Analysis Model)

Metrics for Requirements Model are:-

(i) Function Point-based metrics

1) Use the function point as a normalizing factor or as a measure of the size of the specification.

2) First proposed by Albrecht in 1979

3) Can be used effectively as a means for measuring the functionality delivered by a system

4) Derived using an empirical relationship based on

i. Countable (direct) measures of the softwares information domain.

ii. Assessments of the softwares complexity

5) Information domain values are defined in the following manner:

i. number of external inputs (EIs)



ii. number of external outputs (EOs)

iii. number of external inquiries (EQs)

iv. number of internal logical files (ILFs)

v. number of external interface files (EIFs)

vi. number of external inputs (EIs)

vii. number of external outputs (EOs)

6) Function Point Computation

i. Identify/collect the information domain values

ii. Complete the table shown below to get the count total.

a. Associate a weighting factor (i.e., complexity value) with each count based on criteria established

by the software development organization

b. Evaluate and sum up the value adjustment factors (VAF)

c. Fi refers to 14 value adjustment factors, with each ranging in value from 0 (not important) to 5

(absolutely essential).

d. Compute the number of function points (FP)

FP = count total * [0.65 + 0.01 * sum(Fi)]

Figure:-Computing Function Points

Fi are Value Adjustment Factors based on responses to the following questions. Each of the

questions is answered using a scale from 0 to 5:-

1) Does the system require reliable backup and recovery?

2) Are specialized data communications required to transfer information to or from the

application?



3) Are there distributed processing functions?

4) Is performance critical?

5) Will the system run in an existing, heavily utilized operational environment?

6) Does the system require on-line data entry?

7) Does the on-line data entry require the input transaction to be built over multiple screens or

operations?

8) Are the internal logical files updated on-line?

9) Are the inputs, outputs, files, or inquiries complex?

10) Is the internal processing complex?

11) Is the code designed to be reusable?

12) Are conversion and installation included in the design?

13) Is the system designed for multiple installations in different organizations?

14) Is the application designed to facilitate change and for ease of use by the user?

Example

SafeHome security Software

The SafeHome security function enables the homeowner to configure the security system when it

is installed, monitors all sensors connected to the security system, and interacts with the

homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC

is used to program and configure the system. Each sensor is assigned a number and type, a

master password is programmed for arming and disarming the system, and telephone number(s)

are input for dialing when a sensor event occurs.When a sensor event is recognized, the software

invokes an audible alarm attached to the system. After a delay time that is specified by the

homeowner during system configuration activities, the software dials a telephone number of a

monitoring service, provides information about the location, reporting the nature of the event that

has been detected. The telephone number will be redialed every 20 seconds until a telephone

connection is obtained. The homeowner receives security information via a control panel, the

PC, or a browser, collectively called an interface. The interface displays prompting messages and

system status information on the control panel, the PC, or the browser window.



Figure:- Data flow diagram evaluated to determine the key measures required for computation of

the function point metric

number of user inputs - password, panic button, and activate/deactivate

number of user outputs - messages and sensor status

number of user inquiries - zone inquiry and sensor inquiry

number of files - system configuration file

number of external interfaces - test sensor, zone setting, activate/deactivate, and alarm alert

FP = count total * [0.65 + 0.01 * sum(Fi)]

FP = 50 * [0.65 + (0.01 * 46)]

FP = 55.5 (rounded up to 56)

where count total is the sum of all FP entries and Fi (i = 1 to 14) are "complexity adjustment

values." For the purposes of this example, we assume that S (Fi) is 46 (a moderately complex

product).

Project team can estimate the overall implemented size of the SafeHome user interaction

function.

Assume:



Past data indicates that one FP translates into 60 lines of code (an object-oriented language

is to be used)

12 FPs are produced for each person-month of effort.

Assume:

Past projects have found an average of three errors per function point during analysis

design reviews.

Four errors per function point during unit and integration testing.

These data can help software engineers assess the completeness of their review and testing

activities.

(ii) Specification metrics

b. used as an indication of quality by measuring number of requirements by type.

c. A list of characteristics that can be used to assess the quality of the analysis model and the

corresponding requirements specification:

specificity (lack of ambiguity), completeness, correctness, understandability, verifiability,

internal and external consistency, achievability, concision, traceability, modifiability, precision,

and reusability. we assume that there are nr requirements in a specification, such that

nr = nf + nnf

where nf is the number of functional requirements and nnf is the number of nonfunctional .

d. we assume that there are nr requirements in a specification, such that

nr = nf + nnf

where nf is the number of functional requirements and nnf is the number of nonfunctional .

e. SPECIFICITY (lack of ambiguity) of requirements, a metric that is based on the consistency of

the reviewers interpretation of each requirement:

Q1 = nui/nr

where nui is the number of requirements for which all reviewers had identical interpretations. The

closer the value of Q to 1, the lower is the ambiguity of the specification.

f. COMPLETENESS of functional requirements can be determined by computing the ratio

Q2 = nu/[ni X ns ]



where nu is the number of unique function requirements, ni is the number of inputs (stimuli)

defined or implied by the specification, and ns is the number of states specified. The Q2 ratio

measures the percentage of necessary functions that have been specified for a system.

g. we must consider the degree to which requirements have been validated:

Q3 = nc/[nc + nnv ]

where nc is the number of requirements that have been validated as correct and nnv is the

number of requirements that have not yet been validated.

2. Metrics for design Model

Architectural Design Metrics- Architectural design metrics focus on characteristics of the

program architecture with an emphasis on the architectural structure and the effectiveness of

modules.

Fan out: the number of modules immediately subordinate to the module i, that is, the

number of modules directly invoked by module i

Structural complexity

S(i) = f2out(i), where fout(i) is the fan out of module i

Data complexity

D(i) = v(i)/[fout(i) + 1], where v(i) is the number of input and output variables that

are passed to and from module i

System complexity

C(i) = S(i) + D(i)

As each of these complexity values increases, the overall architectural complexity of the

system also increases. This leads to greater likelihood that the integration and testing effort will

also increase .

Shape complexity- size = n + a, where n is the number of nodes and a is the number of arcs.

Allows different program software architectures to be compared in a straightforward manner

Connectivity density (i.e., the arc-to-node ratio) , r = a/n . It may provide a simple

indication of the coupling in the software architecture. size = 17 + 18 = 35

depth = the longest path from the root (top) node to a leaf node. For the architecture shown in

Figure 19.5, depth = 4. width = maximum number of nodes at any one level of the architecture.



3. Metrics for Testing

Testing metrics fall into two broad categories: (1) metrics that attempt to predict the likely

number of tests

required at various testing levels and (2) metrics that focus on test coverage for a given

component. For example, the number of tests associated with the human/computer interface can

be estimated by (1) examining the number of transitions (TR) contained in the state transition

representation of the HCI and evaluating the tests required to exercise each transition; (2)

examining the number of data objects (OB) that move across the interface, and (3) the number of

data elements that are input or output.

4. Metrics for Maintenance

Metrics designed explicitly for maintenance activities have been proposed. IEEE suggests a

software maturity index (SMI) that provides an indication of the stability of a software product

(based on changes that occur for each release of the product). The following information is

determined:

MT = the number of modules in the current release

Fc = the number of modules in the current release that have been changed

Fa = the number of modules in the current release that have been added

Fd = the number of modules from the preceding release that were deleted in the current release

The software maturity index is computed in the following manner:

SMI = [MT -(Fa + Fc + Fd)]/MT

-------------------------------------------------------------------------------------------------------------------------



3 Cost estimation - COCOMO & COCOMO II

Cost Estimation is a part of the planning stage of engineering activity.

Software cost estimation has two uses in software project management:-

o For developing a schedule for the project.

o To monitor projects progress according to schedule.

Two widely used Cost estimation models are:-

1.1 COCOMO (Constructive Cost Model)

1.2 COCOMO II (Constructive Cost Model II)

1.1 COCOMO (Constructive Cost Model)

i. The COstructive COst Model (COCOMO) is the most widely used software estimation model in the

world.

ii. The COCOMO model predicts the effort and duration of a project based on inputs relating to the size of

the resulting systems and a number of "cost drives" that affect productivity.

iii. COCOMO model was developed by Boehm.

iv. Its a top-down multi-variable model. The model calculates the effort in terms of person-months.

v. The steps are:

Step 1

Obtain an initial estimate of the development effort from the estimate of thousands of delivered lines of

source code (KDLOC).

Step 2

Determine a set of 15 multiplying factors from different attributes of the project.

Step 3

Adjust the effort estimate by multiplying the initial estimate with all the multiplying factors.

Step 1

The initial estimate (also called nominal estimate) is determined by an equation of the form used in

the static single-variable models, using KDLOC as the measure of size.

To determine the initial effort Ei in person-months, the equation used is of the type

Ei = a * (KDLOC) b

The value of the constants a and b depend on the project type.

In COCOMO, projects are categorized into three types organic, semidetached, and embedded.

Organic projects are in an area in which the organization has considerable experience and

requirements are less stringent. Such systems are usually developed by a small team. Examples of

this type of project are simple business systems, simple inventory management systems, and data

processing systems. Projects of the embedded type are ambitious and novel; the organization has



little experience and stringent requirements for such aspects as interfacing and reliability. These

systems have tight constraints from the environment (software, hardware, and people). Examples

are embedded avionics systems and real-time command systems. The semidetached systems fall

between these two types. Examples of semidetached systems include developing a new operating

system (OS), a database management system (DBMS), and a complex inventory management

system. The constants a and b for different systems are given in Table 3.1.

Table 3.1:- a and b values for three different systems

Step 2

There are 15 different attributes, called cost driver attributes that determine the multiplying factors.

These factors depend on product, computer, personnel, and technology attributes (called project attributes).

Examples of the attributes are, required software reliability (RELY), product complexity (CPLX), analyst

capability (ACAP), application experience (AEXP), use of modern tools (TOOL), and required

development schedule (SCHD).

Each cost driver has a rating scale, and for each rating, a multiplying factor is provided. For example, for

the product attribute RELY, the rating scale is very low, low, nominal, high, and very high (and in some

cases, extra high). The multiplying factors for these ratings are .75, .88, 1.00, 1.15, and 1.40, respectively.

So, if the reliability requirement for the project is judged to be low then the multiplying factor is .75, while

if it is judged to be very high the factor is 1.40.

The attributes and their multiplying factors for different ratings are shown in Table 3.2.

The multiplying factors for all 15 cost drivers are multiplied to get the effort adjustment factor (EAF).



Table 3.2 Effort multipliers for different cost drivers.

Step 3

The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF:

E = EAF * Ei

Example

Suppose, a system for office automation must be designed. From the requirements, it was clear that there

would be four major modules in the system: data entry, data update, query, and report generator. It is also clear

from the requirements that project will fall in the organic category. The sizes for the different modules and the

overall system were estimated to be as follows:



From the requirements, the ratings of the different cost driver attributes were assessed. These ratings, along

with their multiplying factors, are:

All other factors had a nominal rating. From these, the effort adjustment factor (EAF) is

EAF=1.15 * 1.06 * 1.13 * 1.17 =1.61.

The initial effort estimate for the project is obtained from the relevant equations. We have:-

Ei = 3.2*31.05 = 10.14 PM.( Ei = a * (KDLOC) b,

since project is organic in nature a=3.2 and b=1.05)

Using the EAF, the adjusted effort estimate is

E =1.61 * 10.14 = 16.3 PM (E=EAF * Ei)

COCOMO II (Constructive Cost Model II)

COCOMO II is actually a hierarchy of estimation models that address the following areas:

i. 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.

ii. Early design stage model. Used once requirements have been stabilized and basic software

architecture has been established.

iii. 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

(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) using criteria suggested by Boehm. In essence, complexity is a function of the number

and source of the client and server data tables that are required to generate the screen or report and the

number of views or sections presented as part of the screen or report.

Once complexity is determined, the number of screens, reports, and components are weighted according to

Table 5.1. The object point count is then determined by multiplying the original number of object instances

by the weighting factor in Table 5.1 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:

NOP = (object points) x [(100 - %reuse)/100]

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.

Table 5.2 presents the productivity rate, PROD = NOP/person-month.

For different levels of developer experience and development environment maturity.Once the productivity

rate has been determined, an estimate of project effort can be derived as

estimated effort = NOP/PROD



------------------------------------------------------------------------------------------------------------------------------

Project control - Work breakdown structures, Gantt charts, PERT charts - Dealing with deviations

5.1 Project Control

The purpose of controlling a project is to monitor the progress of the activities against the plans.

Another aspect of control is to detect, deviations from the plan are occuring so that corrective action

may be taken.

5.2 Work breakdown structures (TASK NETWORK)

WBS is used as a basis for a number of processes in particular to produce the subsidiary plans of the

Project Management Plan.

The WBS is a deliverable-oriented hierarchy of decomposed project components that organises and

defines the total scope of the project.

The WBS is a representation of the detailed project scope statement that specifies the work to be

accomplished by the project.

The elements comprising the WBS assist the stakeholders in viewing the end product of the project.

The work at the lowest-level WBS component is estimated, scheduled, and tracked.

Work Breakdown Structures are also known as Task Network. The task network is a useful mechanism

for depicting intertask dependencies and determining the critical path.

Individual tasks and subtasks have interdependencies based on their sequence.

A task network, also called an activity network, is a graphic representation of the task flow for a project.

It is sometimes used as the mechanism through which task sequence and dependencies are input to an

automated project scheduling tool. In its simplest form (used when creating a macroscopic schedule),

the task network depicts major software engineering tasks.

Figure 7.3 shows a schematic task network for a concept development project. Figure 7. 4 shows an

Example task Network. Figure 7.5 shows an Example Task Network with Critical Path Marked. It

depicts task length, sequence, concurrency, and dependency. Points out inter-task dependencies to help

the manager ensure continuous progress toward project completion.

The details of critical path are:

A single path leading from start to finish in a task network.

It contains the sequence of tasks that must be completed on schedule if the project as a whole is to be completed on schedule.

It also determines the minimum duration of the project.



Figure 7.4 Example Task Network

Figure 7.5 Example Task Network with Critical Path Marked



5.3 Gantt Chart

A Gantt chart also known as time-line chart is a type of bar chart, developed by Henry Gantt that illustrates a

project schedule. Gantt chart features are:-

A timeline chart can be developed for the entire project. Separate charts can be developed for

each project function or for each individual working on the project.

Figure(i) illustrates the format of a timeline chart. It depicts a part of a software project schedule

that emphasizes the concept scoping task for a new word-processing (WP) software product.

All project tasks are listed in the left-hand column, horizontal bars indicate the duration of

each task and diamonds indicate milestones.

When multiple bars occur at the same time on the calendar, task concurrency is implied.

Once the information necessary for the generation of a timeline chart has been input, the

majority of software project scheduling tools produce project tablesa tabular listing of all

project tasks, their planned and actual start- and end-dates, and a variety of related information.

Figure(i) An example of Timeline chart



5.4 PERT charts

Program evaluation and review technique (PERT) and critical path method (CPM) are two project

scheduling methods that can be applied to software development.

PERT chart is a network of boxes(or circles) and arrows.

Each box represents an activity. Arrows are used to show the dependencies of activities on one another.

The activity at the head of an arrow cannot start until the activity at the tail; of the arrow is finished.

Some boxes can be designated as Milestones. A milestone is an activity whose completion signals an

importatnt accomplishment in the life of the project.

Figure 5.3 shows a PERT chart for the compiler project.

The Figure asumes that the project will start on January1.Taking holidays into account , we see that the

design work will start on January 3. Since the design activity is estimated to take 45 days, any activity

that follows the design may start on March7 at the earliest. The dependecy arrows help us compute

these earliest start dates on the basis of our estimates of the duration of each activity.

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.



start design build

parser

write

manual

build code

generator

build

scanner

integration

and testing

finish

Jan 1 Jan 3

March 7

March 7

March 7

March 7

Nov 14

Mar 17+

Figure 5.3 PERT chart for the compiler project.

Salient features of PERT chart are:-

i. It forces and helps managet to plan.

ii. It shows the interrelationship among the tasks in the project and identifies the critical path of the

project.

iii. It exposes all possible parallelism in the activities and thus helps in allocating resources.

iv. It allows scheduling and simulation of alternative schedules.

v. It enables the manger to monitor and contril the project.

PERT provide quantitative tools that allow the software planner to:-

(1) determine the critical paththe chain of tasks that determines the duration of the project.

(2) establish most likely time estimates for individual tasks by applying statistical models.

(3) calculate boundary times that define a time "window" for a particular task.

Boundary time calculations can be very useful in software project scheduling. Slippage in the design of one

function, for example, can retard further development of other functions. Riggs describes important

boundary times that may be discerned from a PERT or CPM network:



(1) the earliest time that a task can begin when all preceding tasks are completed in the shortest

possible time.

(2) the latest time for task initiation before the minimum project completion time is delayed.

(3) the earliest finishthe sum of the earliest start and the task duration.

(4) the latest finishthe latest start time added to task duration.

(5) the total floatthe amount of surplus time or leeway allowed in scheduling tasks so that the

network critical path is maintained on schedule. Boundary time calculations lead to a

determination of critical path and provide the manager with a quantitative method for evaluating

progress as tasks are completed.

Both PERT and CPM have been implemented in a wide variety of automated tools that are available for

the personal computer. Such tools are easy to use and make the scheduling methods described

previously available to every software project manager.

5.5 Dealing with deviations

Dealing with deviation deals with deviation from the project plan.

The manager should consult the chart at frequent intervals during the project to evaluate its status.

No matter how the deviations from the schedule are detected, the manager must decide how to handle them.

In activities where production is limited by raw human labor, it is usual to try to get back on schedule by

adding people or increasing overtime for existing people.

The manager has to examine the requirements and remove the ones that are not absolutely necessary.

Cutting out unecessary requirements is called requirements scrubbing.

--------------------------------------------------------------------------------------------------------------------------------

Team organization - centralized, de-centralized, mixed - An assessment of organizations

Team organization structure is used to structure the communication patterns among members of a team.

Traditional team organization is hierarchical with a manager supervising a group or groups of groups.

Other organizations have been tried in software engineering with some success.

Kinds of Team Organization are:-

1. Controlled Centralized(CC) or Chief-programmer team

2. Democratic decentralized (DD)

3. Controlled decentralized (CD) or Mixed Control Team Organization

1. Controlled Centralized(CC) or Chief-programmer team

i. In Controlled Centralized there is a Chief Programmer(CF) who is the Team Leader.



ii. Top-level problem solving and internal team coordination are managed by a team leader.

iii. Team Leader is responsible for:-

a. Top-level problem solving.

b. For administration

c. Internal team coordination.

d. Plans, coordinates and reviews all technical activities of team.

e. Analysis and development activities.

iv. Communication between the leader and team members is vertical.

v. Chief Programmer is supported by more people such as:-

a. Telecommunication Expert

b. Database Engineer

c. Technical writer

d. Clerical Personne

e. Software Librarian

Programmers Specialists

Chief programmer

Librarian

Figure:- Structure of Chief Programmers Team

vi. Software Librarian functions are:

1. Maintains and control all elements of software configuration.

2. Helps tp collect and format software productivity data.

3. Assist team in research,evaluation and document preparation.

4. Librarian acts as controller, coordinator and evaluation of software.

vii. Advantages of Controlled Centralized(CC) or Chief-programmer team are:-

a) Completes task faster.

b) Suitable for handling simple problems.

viii. Disadvantages of Controlled Centralized(CC) or Chief-programmer team are:-

a) Single point of failure may occur because too much responsibility and authority to Chief Programmer.



2. Democratic decentralized (DD) team

i. This software engineering team has no permanent leader. Rather, "task coordinators are appointed for

short durations and then replaced by others who may coordinate different tasks."

ii. Decisions on problems and approach are made by group consensus.

iii. Communication among team members is horizontal.

iv. Members review each others work and are responsible as a group for what every member produces.

v. This team doesnt have any team hierarchy.At different time, different members of group provide

technical leadership.

vi. Advantages of Democratic decentralized (DD) team are:-

a) Appropriate for less understood problems since group of engineers can invent better solutions than

single individuals as in a Chief programmers team.

vii. Disadvantages of Democratic decentralized (DD) team are:-

a) It can be applied to low modularity projects only because a high volume of communication is needed.

(a)(b)

Figure 2(a) Management Structure of Democratic decentralized team and 2(b) communication pattern in DD team

3. Controlled decentralized (CD) or Mixed-Control Team Organization

i. This software engineering team has a defined leader who coordinates specific tasks and secondary

leaders that have responsibility for subtasks.

ii. Attempts to combine the benefits of centralized and decentralized control

iii. Differentiates engineers into senior and junior.

iv. Senior engineer leads a group of juniors and reports to a project manager



v. Control vested in the project manager and senior programmers

vi. Communication decentralized among each set of individuals, peers, and their immediate supervisors

vii. Problem solving remains a group activity, but implementation of solutions is partitioned among

subgroups by the team leader.

viii. Communication among subgroups and individuals is horizontal. Vertical communication along the

control hierarchy also occurs.

Senior engineers

Project manager

Junior engineers

(a) (b)

Figure 3(a) Management structure of Mixed control team (b) communication pattern in Mixed control team

1.1 An assessment of organizations

We must content with the following general considerations:-

1. No team organization is appropriate for all tasks.

2. Decentralized control is best when communication is necessary to achieve a good solution

3. Centralized control best when development speed is key and problem is well understood.

4. An appropriate organization limits the amount of communication to what is necessary to achieve the

goalsno more and no less.

5. An appropriate organization may have to take acount goals other than speed of development.

--------------------------------------------------------------------------------------------------------------------------------

Risk management

A risk is a potential problem it might happen and it might not. Conceptual definition of risk:-

Risk concerns future happenings

Risk involves change in mind, opinion, actions, places, etc.

Risk involves choice and the uncertainty that choice entails

Two characteristics of risk

Uncertainty the risk may or may not happen, that is, there are no 100% risks (those,

instead, are called constraints)



Loss the risk becomes a reality and unwanted consequences or losses occur

Reactive risk strategies

"Don't worry, I'll think of something"

The majority of software teams and managers rely on this approach

Nothing is done about risks until something goes wrong

The team then flies into action in an attempt to correct the problem rapidly (fire fighting)

Crisis management is the choice of management techniques

Proactive risk strategies

Steps for risk management are followed (see next slide)

Primary objective is to avoid risk and to have a contingency plan in place to handle

unavoidable risks in a controlled and effective manner.

Steps for Risk Management

1. Identify possible risks; recognize what can go wrong

2. Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that

it will do if it does occur

3. Rank the risks by probability and impact

- Impact may be negligible, marginal, critical, and catastrophic

4. Develop a contingency plan to manage those risks having high probability and high impact.Risk

Mitigation, Monitoring, and Management.

1. Risk identification

It is a systematic attempt to specify threats to the project plan. By identifying known and

predictable risks, the project manager takes a first step toward avoiding them when possible and

controlling them when necessary.

Generic risks

Risks that are a potential threat to every software project

Product-specific risks

Risks that can be identified only by those a with a clear understanding of the technology, the

people, and the environment that is specific to the software that is to be built

This requires examination of the project plan and the statement of scope

"What special characteristics of this product may threaten our project plan?"

Risk Item Checklist

It is used as one way to identify risks. Focuses on known and predictable risks in specific

subcategories . Can be organized in several ways

A list of characteristics relevant to each risk subcategory

Questionnaire that leads to an estimate on the impact of each risk



A list containing a set of risk component and drivers and their probability of occurrence.

Categories of risk or Components of risk:-

Performance Risk

The degree of uncertainty that the product will meet its requirement and be fit for its

intended use.

Cost Risk(CU)

The degree of uncertainty that the project budget will be maintained.

Support Risk

The degree of uncertainty that whether the project is easy to correct, adapt and enchance.

Schedule Risk

The degree of uncertainty that the project schedule will be maintained and that the product

will be delivered on time.

Product Size Risk(PS)

Risk associated with overall size of the software to be built or modified.

Business Impact Risk(BU)

Risks associated with constraints imposed by management.

Technology to built risk(TE)

Risks associated with complexity of system to be built.

Development environment Risk(DE)

Risks associated with the availability and quality of the tools to be used to build the

product.

Staff and Experience Risk(ST)

Risks associated with the overall technical and project experience of the software engineers

who will do the work.

2. Risk Projection (Estimation)

Risk projection (or estimation) attempts to rate each risk in two ways

a. The probability that the risk is real

b. The consequence of the problems associated with the risk, should it occur

The project planner, managers, and technical staff perform four risk projection steps . The intent of

these steps is to consider risks in a manner that leads to prioritization. Be prioritizing risks, the software

team can allocate limited resources where they will have the most impact. Risk Projection/Estimation

Steps:-

1. Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high)



2. Delineate the consequences of the risk

3. Estimate the impact of the risk on the project and product

4. Note the overall accuracy of the risk projection so that there will be no misunderstandings

5. A risk table provides a project manager with a simple technique for risk projection

Contents of a Risk Table

Risk

Category

Probability

Impact (1-4)

RMMM

Size estimate

may be

significantly low

PS 60% 2

Larger number of

users than

planned

PS 30% 3

End users resist

system

BU 40% 2

Staff

inexperienced

ST 30% 3

Lack of training

on tools

DE 80% 1

It consists of five columns

a. Risks All kinds of risks are listed in this column.

b. Category Each risk is categorized in the second column.(eg-PS- project size risk, BU-

business risk).

c. Probability The probability of occurrence of each risk is entered in this column.

d. Impact Each risk is assessed and impact value is given as follows:-

1-Catastrophic

2-Critical

3-Marginal

4- Negligible



Once the first four columns are completed, the table is sorted by probability and by

impact. High probability, high-impact risks are now the top entries in the table and low-

probability risks drop to the bottom. A cutoffline is drawn horizontally which implies

that risks above the line will be given further attention.

e. RMMM All risks that lie above cutoff line should be managed. The column labeled

RMMM contains a pointer to a Risk Mitigation, Monitoring, and Management Plan.

RMMM are risk information sheets developed for risks that lie above cutoff line. Entries

in RMMM sheets are:-

Risk Information Sheet

RISK ID DATE PROBABILTY IMPACT

DESCRITION OF RISK

REFINEMENT/ CONTEXT

MITIGATION/MONITORING

MANAGEMENT/CONTIGENECY PLAN

CURRENT STATUS

Developing a Risk Table

List all risks in the first column (by way of the help of the risk item checklists)

Mark the category of each risk

Estimate the probability of each risk occurring

Assess the impact of each risk based on an averaging of the four risk components to determine an overall impact value

Sort the rows by probability and impact in descending order

Draw a horizontal cutoff line in the table that indicates the risks that will be given further attention.

3. Assessing Risk Impact

Three factors affect the consequences that are likely if a risk does occur

a. Its nature This indicates the problems that are likely if the risk occurs



b. Its scope This combines the severity of the risk (how serious was it) with its overall distribution (how much was affected)

c. Its timing This considers when and for how long the impact will be felt

The overall risk exposure formula is RE = P x C

a. P = the probability of occurrence for a risk

b. C = the cost to the project should the risk actually occur

Example

a. P = 80% probability that 18 of 60 software components will have to be developed

b. C = Total cost of developing 18 components is $25,000

c. RE = .80 x $25,000 = $20,000

4. Risk Mitigation, Monitoring, and Management

An effective strategy for dealing with risk must consider three issues

a. Risk mitigation (i.e., avoidance)

b. Risk monitoring

c. Risk management and contingency planning

Risk mitigation (avoidance) is the primary strategy and is achieved through a plan

d. Example: Risk of high staff turnover

During risk monitoring, the project manager monitors factors that may provide an indication of whether

a risk is becoming more or less likely

Risk management and contingency planning assume that mitigation efforts have failed and that the risk

has become a reality.

-----------------------------------------------------------------------------------------------------------------------

Configuration Management

Software configuration management (SCM) is an umbrella activity that is applied throughout the software

process. Because change can occur at any time, SCM activities are developed to (1) identify change, (2)

control change, (3) ensure that change is being properly implemented, and (4) report changes. Elements of a

Configuration Management System are:-

1. Configuration elements

a. A set of tools coupled with a file management (e.g., database) system that enables access

to and management of each software configuration item.

2. Process elements



a. A collection of procedures and tasks that define an effective approach to change

management for all participants

3. Construction elements

a. A set of tools that automate the construction of software by ensuring that the proper set of valid

components (i.e., the correct version) is assembled

4. Human elements

a. A set of tools and process features used by a software team to implement effective SCM

SCM has five tasks:

1. Identification Of Objects in the Software Configuration

2. Change Control

3. Version Control

4. Configuration Auditing

5. Status Reporting Task

Figure:- Elements of a Configuration Management System are:-

1. Identification of objects in the Software Configuration

To control and manage software configuration items, each must be separately named and then organized

using an object-oriented approach. Two types of objects can be identified basic objects and aggregate

objects.



2. Change Control

3. Change control is a procedural activity that ensures quality and consistency as changes are made to a

configuration object. A change request is submitted to a configuration control authority, which is

usually a change control board (CCB)

a. The request is evaluated for technical merit, potential side effects, overall impact on

other configuration objects and system functions, and projected cost in terms of money,

time, and resources.

An engineering change order (ECO) is issued for each approved change request

a. Describes the change to be made, the constraints to follow, and the criteria for review

and audit.

4. Version Control Task

Version control is a set of procedures and tools for managing the creation and use of multiple

occurrences of objects in the SCM repository. Required version control capabilities

a. An SCM repository that stores all relevant configuration objects

b. A version management capability that stores all versions of a configuration object (or

enables any version to be constructed using differences from past versions)

c. A make facility that enables the software engineer to collect all relevant configuration

objects and construct a specific version of the software

d. Issues tracking (bug tracking) capability that enables the team to record and track the

status of all outstanding issues associated with each configuration object.

5. Configuration Auditing

Configuration auditing is an SQA activity that helps to ensure that quality is maintained as changes are

made. It complements the formal technical review and is conducted by the SQA group. A configuration

audit ensures that

The correct CSCIs (by version) have been incorporated into a specific build

That all documentation is up-to-date and consistent with the version that has been built

6. Status Reporting Task

Configuration status reporting (CSR) is also called status accounting. Provides information about each

change to those personnel in an organization with a need to know. Sources of entries for configuration

status reporting

Each time a CSCI is assigned new or updated information

Each time a change is approved by the CCB and an ECO is issued

Each time a configuration audit is conducted

The configuration status report



Placed in an on-line database or on a website for software developers and maintainers to

read

Given to management and practitioners to keep them appraised of important changes to

the project CSCI.

------------------------------------------------------------------------------------------------------------------------------------

Introduction to project management and planning CASE tools

Introduction to project management

The Management Spectrum

Effective software project management focuses on the four Ps: people, product, process, and project.

1. The People

The people factor is so important that the Software Engineering Institute has developed a people

management capability maturity model (PM-CMM). People comprises of following components:-

1. Stakeholders

2. Team Leaders

3. Software Team

4. Agile Teams

1.1 Stakeholders

The software process is populated by stakeholders who can be categorized into one of five constituencies:

a) Senior managers define business issues that often have significant influence on the project.

b) Project (technical) managers plan, motivate, organize, and control the practitioners who do

the work

c) Practitioners deliver the technical skills that are necessary to engineer a product or

application.

d) Customers specify the requirements for the software to be engineered and other stakeholders

who have a peripheral interest in the outcome.

e) End users interact with the software once it is released for production use.

1.2 Team Leaders

Project management is a people-intensive activity, and for this reason, competent practitioners often make poor

team leaders. MOI (Motivation, Organization, Ideas)model of leadership suggests following things:

a) Motivation-The ability to encourage (by push or pull) technical people to produce to their

best ability.

b) Organization-The ability to mold existing processes (or invent new ones) that will enable the

initial concept to be translated into a final product.

c) Ideas or innovation-The ability to encourage people to create and feel creative even when they

must work within bounds established for a particular software product or application.



An effective project manager emphasizes four key traits:

a) Problem solving:-An effective software project manager can diagnose the technical and

organizational issues that are most relevant, systematically structure a solution or properly motivate

other practitioners to develop the solution, apply lessons learned from past projects to new

situations, and remain flexible enough to change direction if initial attempts at problem solution are

fruitless.

b) Managerial identity. A good project manager must take charge of the project.

c) Achievement. To optimize the productivity of a project team, a manager must reward initiative and

accomplishment and demonstrate through his own actions that controlled risk taking will not be

punished.

d) Influence and team building. An effective project manager must be able to read people; she

must be able to understand verbal and nonverbal signals and react to the needs of the people sending

these signals. The manager must remain under control in high-stress situations.

1.3. Software Team

There are almost as many human organizational structures for software development as there are organizations

that develop software. Four organizational paradigms for software development teams are:-

a) Closed paradigm traditional hierarchy of authority; works well when producing software similar

to past efforts; members are less likely to be innovative.

b) Random paradigm depends on individual initiative of team members; works well for projects

requiring innovation or technological breakthrough; members may struggle when orderly

performance is required.

c) Open paradigm hybrid of the closed and random paradigm; works well for solving complex

problems; requires collaboration, communication, and consensus among members.

d) Synchronous paradigm organizes team members based on the natural pieces of the problem;

members have little communication outside of their subgroups.

Five factors that cause team toxity (i.e., a toxic team environment)

i. A frenzied work atmosphere

ii. High frustration that causes friction among team members

iii. A fragmented or poorly coordinated software process

iv. An unclear definition of roles on the software team

v. Continuous and repeated exposure to failure

How to avoid these problems?

i. Give the team access to all information required to do the job

ii. Do not modify major goals and objectives, once they are defined, unless absolutely necessary

iii. Give the team as much responsibility for decision making as possible



iv. Let the team recommend its own process model

v. Let the team establish its own mechanisms for accountability (i.e., reviews)

vi. Establish team-based techniques for feedback and problem solving

1.4 Agile Teams

Agile Teams are highly motivated, small teams which adopts many of the characteristics of successful software

project teams. Many agile process models are there which give agile teams significant autonomy.

2. The Product

We must examine the product and the problem it is intended to solve at the very beginning of the project. The

topics discussed under product are:-

2.1 Software Scope

2.2 Problem Decomposition

2.1 Software Scope

The scope of the software development must be established and bounded. Scope is defined by answering the

following questions:-

1. Context How does the software to be built fit into a larger system, product, or business context, and

what constraints are imposed as a result of the context?

2. Information objectives What customer-visible data objects are produced as output from the software?

What data objects are required for input?

3. Function and performance What functions does the software perform to transform input data into

output? Are there any special performance characteristics to be addressed?

Problem Decomposition

Problem decomposition also referred to as partitioning or problem elaboration. It sits at the core of software

requirements analysis. Two major areas of problem decomposition

i. The functionality that must be delivered

ii. The process that will be used to deliver it

3. The Process

The generic phases that characterize the software processdefinition, development and supportare

applicable to all software.

3.1 Melding the Product and the Process

Project planning begins with the melding of the product and the process. Each function to be engineered by

the software team must pass through the set of framework activities that have been defined for a software

organization. Assume that the organization has adopted the following set of framework activities:-



Customer communicationtasks required to establish effective requirements

elicitation between developer and customer.

Planningtasks required to define resources, timelines, and other project related information.

Risk analysistasks required to assess both technical and management risks.

Engineeringtasks required to build one or more representations of then application.

Construction and releasetasks required to construct, test, install, and provide user support (e.g.,

documentation and training).

Customer evaluationtasks required to obtain customer feedback based on evaluation of the software

representations created during the engineering activity and implemented during the construction activity.

The team members who work on a product function will apply each of the framework activities to it. In

essence, a matrix similar to the one shown in Figure 3.2 is created. Each major product function (the figure

notes functions for the word-processing software discussed earlier) is listed in the left-hand column.

Framework activities are listed in the top row. Software engineering work tasks (for each framework

activity) would be entered in the following row. The job of the project manager (and other team members) is

to estimate resource requirements for each matrix cell, start and end dates for the tasks associated with each

cell, and work products to be produced as a consequence of each task.

1.2 Process Decomposition



Once the process model has been chosen, the common process framework (CPF) is adapted to it. In every

case, the CPFcustomer communication, planning, risk analysis, engineering, construction and release,

customer evaluationcan be fitted to the paradigm. Process decomposition commences when the project

manager asks, How do we accomplish this CPF activity? For example, a small, relatively simple

project might require the following work tasks for the customer communication activity:

1. Develop list of clarification issues.

2. Meet with customer to address clarification issues.

3. Jointly develop a statement of scope.

4. Review the statement of scope with all concerned.

5. Modify the statement of scope as required.

4. The Project

In order to manage a successful software project, we must understand what can go wrong and how to do it right.

Ten signs that indicate that an information systems project is in jeopardy:

1. Software people dont understand their customers needs.

2. The product scope is poorly defined.

3. Changes are managed poorly.

4. The chosen technology changes.

5. Business needs change [or are ill-defined].

6. Deadlines are unrealistic.

7. Users are resistant.

8. Sponsorship is lost [or was never properly obtained].

9. The project team lacks people with appropriate skills.

10. Managers [and practitioners] avoid best practices and lessons learned.

How does a manager act to avoid the problems just noted? A five-part commonsense approach to software

projects:

1. Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that

is to be solved and then setting realistic objects and expectations for everyone who will be involved in the

project. It is reinforced by building the right team and giving the team the autonomy, authority, and

technology needed to do the job.

2. Maintain momentum. Many projects get off to a good start and then slowly disintegrate. To maintain

momentum, the project manager must provide incentives to keep turnover of personnel to an absolute

minimum, the team should emphasize quality in every task it performs, and senior management

should do everything possible to stay out of the teams way.



3. Track progress. For a software project, progress is tracked as work products (e.g., specifications, source

code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality

assurance activity. In addition, software process and project measures can be collected and used to assess

progress against averages developed for the software development organization.

4. Make smart decisions. In essence, the decisions of the project manager and the software team should be to

keep it simple. Whenever possible, decide to use commercial off-the-shelf software or existing software

components, decide to avoid custom interfaces when standard approaches are available, decide to identify and

then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks.

5. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each

project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback

from team members and customers, and record findings in written form.

THE W5HH PRINCIPLE

WWWWWHH principle, after a series of questions that lead to a definition of key project characteristics and

the resultant project plan:

1. Why is the system being developed? The answer to this question enables all parties to assess the validity

of business reasons for the software work. Stated in another way, does the business purpose justify the

expenditure of people, time, and money?

2. What will be done, by when? The answers to these questions help the team to establish a project schedule

by identifying key project tasks and the milestones that are required by the customer.

3. Who is responsible for a function? Earlier in this chapter, we noted that the role and responsibility of each

member of the software team must be defined. The answer to this question helps accomplish this.

4. Where are they organizationally located? Not all roles and responsibilities reside within the software team

itself. The customer, users, and other stakeholders also have responsibilities.

5. How will the job be done technically and managerially? Once product scope is established, a management

and technical strategy for the project must be defined.

6. How much of each resource is needed? The answer to this question is derived by developing estimates

based on answers to earlier questions.

--------------------------------------------------------------------------------------------------------------------------------

9.2 Planning CASE tools

(a) WHAT IS CASE?

Computer-aided software engineering (CASE) tools assist software engineering managers and practitioners in every activity associated with the software process.

They automate project management activities, manage all work products produced throughout the process, and assist engineers in their analysis, design, coding and test work.

CASE tools can be integrated within a sophisticated environment. The workshop for software engineering has been called an integrated project support environment and the tools that fill the

workshop are collectively called computer-aided software engineering.

CASE provides the software engineer with the ability to automate manual activities and to improve engineering insight. Like computer-aided engineering and design tools that are used by engineers in other d

Documents

Software engneering Module 2 Notes