Merged Document

Software Engineering Unit 1

Sikkim Manipal University Page No.: 1

Unit 1 The Product and The Process

Structure:

1.1 Introduction

Objectives

1.2 The Product

The Evolving Role of Software

Software

Software Characteristics

Software Applications

Software: A Crisis on the Horizon

Software Myths

1.3 The Process

The Software Process

Software Process Models

The Linear Sequential Model

The Prototyping Model

The Incremental Model

The Spiral Model

The RAD Model

1.4 Fourth Generation Techniques

1.5 Summary

1.6 Terminal Question(s) (TQs)

1.7 Multiple Choice Question(s) (MCQs)

1.8 Answers to SAQs, TQs, and MCQs

1.1 Introduction

The world today is growing at a very fast pace. Most of the activities related

to business and various applications are computerized. Computerization has

led to the development of various types of software. Software has become

the basis for various decision-making. Software helps in solving day to day

problems and also helps in systematic production. It has become an integral

part of service industry today. Software has penetrated various other sectors

in applications of forecasting, scientific applications, animation, film making,

inventory etc. Software has greatly impacted our society and culture. Its

significance has no bounds and has led to rapid development of



technologies across the globe. This has also created a competition amongst

various companies. The thirst for developing better and better software

continues to increase day by day. There is also a need to develop areas of

importance like hospitals, crime detection, chemical lab tests, astronomic

research etc where quality is of prime importance. Software enables one to

have a quality system. The technologies aim at specific applications like

Web-Site development, technology domain like object-oriented systems,

artificial intelligence, expert systems etc. There is not one software which

can do everything.

Software is an embodied knowledge and is a social learning process. It is a

dialogue in which the knowledge becomes the software. This has resulted in

processes, which provides an interaction between users and designers, and

between designers and evolving technology. It is repetitive in nature, where

the tool itself serves as the medium for communication. It is enriched with

more and more rounds of the interaction where plenty of useful knowledge

from the people is involved.

Objectives

In this Unit you will learn about:

What is computer software . . . really?

Why do we struggle to build high-quality computer-based systems?

How can we categorize application domains for computer software?

What myths about software still exist?

What is a “software process”?

Is there a generic way to assess the quality of a process?

What process models can be applied to software development?

How do linear and iterative process models differ?

What are their strengths and weaknesses?

What advanced process models have been proposed for Software

Engineering work?

1.2 The Product

1.2.1 Software Evolutionary Role

Software has a dual role. First it acts as a product, and secondly it acts as a

delivery model. It provides the facility of computing the various needs of

computer hardware like network of computers to be made accessible by



local hardware. A software acts as an information transformer. It transforms

one or more of production, management, acquisition, modification,

displaying, or transmitting information in simple as a single bit. Software is

the basis and a driver to deliver the product. It acts as a controller of the ther

entire systems of communication of information. Transformation of data is

done by software. By transformation data becomes information which is

then more useful in various contexts of business and scientific application. It

helps in enhancing competitiveness; providing gateway to worldwide

information networks, and as a means to acquire information. Along with the

growth of the software industry there has been a drastic growth in the

development of new hardware components and devices.

Self Assessment Question(s) (SAQs)

1. Today software takes on a ______________ role.

2. Software helps in transferring personal information. (T/F)

1.2.2 Software

A software refers to instructions which when executed provide desired

function and performance and data structures that enable the programs to

adequately manipulate information, and documents describing the operation

and the use of the software. It refers to a set of instructions also known as

program.


1. What is software?

1.2.3 Characteristics of a Software

Software is a logical element. Software has the following characteristics:

1. Software is not a manufactured component but it is developed or

engineered.

2. Software does not undergo wear out which is seen in many

manufactured components.

3. Most of softwares today are custom built which means the software are

customized to meet the user needs. It is developed keeping in mind the

requirements of delivery process and finished product.


1. What are the characteristics of software?



1.2.4 Software Applications

The application of software is based on the nature of instructions in a

particular area. If the set of instructions are structured well it is appropriate

to develop software for such application. Development becomes easy and

convenient depending on the degree of structure. Higher the degree better it

is to develop the software for such applications. Information content and

determinacy play an important role in determining the nature of a software

application. Content means the form of incoming and outgoing information.

Information determinacy refers to the predictions of the order and timing of

information. It is difficult to develop generic categories for software

applications. The following software areas indicate potential applications:

System software - It is a collection of programs written to serve other

programs. e.g., Compilers and Interpreter. Other systems applications like

the operating system components, drivers, telecommunication processors

process largely indeterminate data.

Real-time software: Events that are real world based if possible to be

controlled by programs are referred to as programmable events. Such

programs control the entire event and act as a monitor or as an analyzer of

the real-world events. Such software are known as real time software. It

includes data gathering components and formats information from an

external environment, an analysis component that transforms information, a

responder component that responds to the changes in the external

environment, and a monitoring component coordinating all other

components.

Business software: Business software refers to applications in the areas of

business. Such software is mainly useful in decision making and

transactions that facilitates business operations or management decision

making. In addition to conventional data processing applications, business

software applications also encompass interactive computing.

Engineering and scientific software: Engineering and scientific software

have been developed mainly to deal with "number crunching" algorithms.

Applications range from astronomical science to seismology to molecular

biology to automated manufacturing. Computer-aided design, system

simulation, and other interactive applications have gained prominence.



Personal software: The personal computer software like the word

processing, spreadsheets, computer graphics, multimedia, entertainment,

database management, personal and business financial applications,

external network, and database access are some of the applications.

Web-based software: The Web pages are a software application page that

incorporates executable instructions performing one or more tasks.

Artificial intelligence software: It uses non-numerical algorithms to solve

complex problems. Expert systems, also called knowledge based systems,

pattern recognition, artificial neural networks, and game playing are

representative of applications within this category.


1. What do you mean by Web-based software?

2. Write on personal computer software.

1.2.5 Software Crisis

The success rate of software people is high. Last two to three decades

never one has seen a serious software crisis. A crisis may indicate either a

downfall of a set and well established activity or activities of software. It may

signify a change in the software which is considered healthy for the growth

of the software and its improvement. The set of problems that are

encountered in the development of computer software is not limited to

software that malfunctions. Rather, it may be extended to the stages of the

development of the software. Also it is based on how we support a growing

volume of existing software, and how one can keep pace with a growing

demand in the industry. In the other hand we can say that, the selection of

the software from total market availability is the software crisis.


1. What do you mean by crisis?

1.2.6 Myths about Software

Most of the knowledgeable professionals understand myths as misleading

attitudes that have caused serious problems for managers and technical

people. It is not possible to easily change the old attitudes and habits.

Myth about Management - Managers are often under pressure to maintain

budgets, work towards objectives and accomplish task within deadline, keep

control schedules from slipping, and improve quality.



Myth: A book that's full of standards and procedures for developing

software is available. Is that enough to provide people with everything they

need to know?

Reality: The question is whether the book of standards was ever used or

not? Are managers aware of the availability of such codes? Is it complete?

Is it streamlined? Most of the times, the answer to all of these questions is

"no."


1. What do you mean by myths?

2. What are the different types of myths?

1.3 The Process

1.3.1 The Software Process

A lot of focus is on process maturity. Software Engineering Institute (SEI)

based on a software engineering capabilities, have developed a model, to

address the various levels of maturity levels present in an organization. SEI

used a five point grading scheme to assess the maturity level. The five

levels are as follows -

Level 1: Initial level – It is to address the initial processes where there is a

tendency of one or more processes getting chaotic. Some of the issues are

identified and steps are taken to bring in clarity in the initial processes.

Level 2: Repeat level – Based on the successes of certain processes in the

past, processes are reviewed and revised. Some of the processes which are

tracked are the process on costing, scheduling and various other related

functions.

Level 3: Documentation – Organizations follow a streamed line of software

development activities. These activities are documented procedures

developed over years which are used by both the management and

development team. Modules developed are integrated into existing

organization software processes.

Level 4: Managing the processes - It is necessary to measure various

product features and processes associated with the software process.

Measures are taken to collect data from various processes on various

parameter of the software and each one is measured. The quantification of



all such measures is done and used in the performance evaluation of the

process and the product.

Level 5: Optimization – Continual improvement is one of the major

objectives of organization today. It is achieved by means of some

predefined characteristics which is expected from the processes. The

measurement methodology can be different for different processes. A

quantitative feedback is obtained for various processes and measured. The

measurements are made under constraints under which a process is

expected to perform. Hence the measurements have to be optimized

measurements. This helps in taking decisions on the improvement of the

process on a continual basis.

The five levels defined by SEI are on the basis of the evaluation responses

from the assessment questionnaire based on CMM. Associated with each

process level is the key process area (KPA). It defines various functions

associated with each process which reflect the qualitative aspect of the

process.

KPA is based on the following characteristics –

Goals – goals refer to the overall objectives to be achieved

Commitments – commitments are the requirements to be adhered to

meet the goals.

Abilities – abilities refer to those aspects necessary to meet the

commitments.

Activities – it signifies task necessary to achieve a particular KPA.

Monitoring – it refers to the ways and methodologies of monitoring a

particular activity or a process.

Verification – it refers to the ways of verifying the methodologies of the

KPA


1. What are the different CMM Levels?

1.3.2 Software Process Models

A development strategy for each process has to be developed to solve

various types of problems associated with a process.



Problem solving can become very troublesome if not attempted to solve

properly. It may run into repeated process of corrections and trouble

shooting.

The stages normally encountered are: status quo, problem definition,

technical development, and solution integration. These stages are

represented in the figure 1.1.

Current state is represented by Status quo; identifying specific problem

needed to be solved is problem definition; technical development refers to

application of technology to solve the problem; and solution integration

gives results. This technique may be applied at macro level or at micro level

of processes.

The stages may also exist in the form of nesting one consisting of the other

similar block of stages.

Fig. 1.1: Stages of problem solving in software process model


1. Software process model is used as ________________ level.

Problem

Definition

Technical

Development Status Quo

Integrating

Solution



1.3.3 Linear Sequential Model

Linear Sequential Model is also known as the waterfall model. It indicates a

systematic and sequential approach to software development. It

encompasses the following in a sequential order – modeling, analysis,

design, coding, testing, and support.

Modeling: Modeling is done based on the various characteristics and

relevant parameters which affect the performance of the software. The

requirements are identified for each system element and the related

constraints. The view of the system indicating the interaction of various

elements of the system helps in modeling the system. The elements are the

hardware, people, and databases.

Requirements analysis: The information domain is understood for the

software and the related functions and behavior of the various elements.

The requirements for software are well documented. The requirements are

reviewed for time to time with the customer.

Design: The design of software is based on the following steps –

understanding data structure, the software architecture, the interface

representations, and algorithms. The process of design transforms the

requirements into a representation of the software which is then assessed

for quality.

Code generation: The code generation refers to the translation of design

into a machine code. Code generation can be done systematically if the

design steps are listed in detail.

Program Testing: After the development of the program it is subjected to

testing. Testing is done on the logics of the program and the functionality.

During the process of testing, errors if any are identified and then necessary

steps are taken to rectify the error.

Support: Customers who are the end users of the software may come

across certain points while using the software for their business

applications. Such points are communicated to the developer who in turn

incorporates the changes in the software. This is recorded as a revision.

Software goes through a number of revisions during its lifetime of service.




1. What do you mean by linear sequential model?

2. What are the features of sequential model?

1.3.4 The Prototyping Model

Detailed input requirements, processing requirements, and output

requirements are not identified easily by the customer but states the general

objectives. Also there is always a doubt about the efficiency of an algorithm.

A prototype model on the requirements stated by the customer is developed

which will enable the developer to understand the requirements more clearly

and implement those requirements in the system. The customer evaluates

the prototype which becomes the basis to refine the requirements.


1. The prototyping paradigm begins with ____________ gathering.

2. What are the features of the prototyping model?

1.3.5 The Incremental Model

The incremental model has the elements of linear sequential model and the

prototype model.

While using the incremental model, it is observed that the first increment is a

core product. A basic requirement is addressed, but many of the

supplementary features are undelivered. Core product is used by customer ,

who in turn suggests he changes which is reflected as in increment. This is

repeated, till such a time that the entire product is completely finished for its

intended use. Incremental model focuses on the delivery. This methodology

is very useful in situation when there is shortage of staff but a progress is

required. An incremental progress is possible then with limited staff. It can

be then developed further depending upon the acceptance of the product by

the customer and can be very useful in handling technical risks.


1. The incremental model combines elements of the __________________

model.

1.3.6 The Spiral Model

The spiral model was proposed by Boehm. It combines the repetitive aspect

of prototyping and systematic and controlled aspect of linear sequential

model. It helps in rapid development of versions of the software through



various incremental forms. Early iterations of the incremental release might

be a paper model or prototype. Iterations done later are more in complete

versions form. A spiral model is divided into six task regions:

Customer Communication – it refers to the setting up of a

communication channel between the developer and the customer.

Planning – Resources and other project-related information are

organized in a definite manner to achieve the intended results within the

timeframe is achieved through planning.

Risk Analysis – Risks related to technical and management are

analysed.

Engineering – engineering refers to the set of tasks necessary to build

one or more application forms.

Construction and Release – This refers to the tasks required to

construct, test, install, and provide user support.

Customer Evaluation – Various feedback question types are prepared on

the different types of processes of the system. The feedbacks are inputs to

the data on the software from the customers. The feedbacks are evaluated

which in turns determines the level of acceptance of the software by the

customer.

The system of feedback is a repetitive process aimed at continual

improvement of the product and its services. The software team moves

around the spiral in a clockwise direction, beginning at the center leading to

the development of product specification and subsequent repetitions of the

process leads to development of the prototype and hence the product. Each

pass through the planning region results in improvements. Cost and

schedule are adjusted depending upon the customer needs. The new

product will evolve over iterations around the spiral. The spiral model is a

realistic approach to develop large-scale systems and software. The spiral

model demands attention of the risks involved at various stages of the

project and tend to minimize such risks.


1. ___________ provides the potential for rapid development of

incremental versions of the software.

2. What are the features of the spiral model?



1.3.7 The RAD Model

Rapid application development (RAD) is similar to incremental software

development process model. It focuses on short development cycle. The

model is constructed based on the components or rapid development form

linear sequential model. RAD approach covers the phases listed below:

Business modeling phase – in this phase the flow of the information

through various business functions is considered. Certain questions to

generate the model would be on - What drives the business process? What

is generated? Who has generated it? Who is responsible to processes it?

Data modeling phase – Business data objects are modeled based on the

information flow and the functionality of the business module which is

needed to be incorporated into the system.

Process modeling phase – The objects developed in the above phase are

transformed into the form necessary to be implemented in the systems as a

function of the business. This will enable the smooth flow of the information

through the various business processes. Processes are described to add,

modify, delete, retrieve objects.

Application generation phase - RAD uses fourth generation techniques for

creating software. The focus of RAD process is to reuse existing program

components. Automated tools may be used to develop the software.

Testing and turnover phase – The overall testing time is reduced in RAD

since it emphasizes on the reusability of the components. In case of new

components, testing will have to be done. In case the projects are large and

scalable, RAD requires sufficient human resources to form the right team.

Developers and customers are needed to the rapid-fire activities necessary

to get a system complete. RAD is not appropriate to all types of business

applications. RAD becomes troublesome if the if a system cannot be

properly modularized. If the technical risks are high then RAD is not

appropriate.


1. What is the full form of RAD?

2. What is the drawback of the RAD model?



1.4 Fourth Generation Techniques

It refers to software tools that enable the software engineer to specify some

characteristic of software at a higher level. Based on the developers

specifications the tool generates the codes automatically. A software

development environment that supports 4GT includes one or more of the

following tools: data manipulation tools, nonprocedural languages,

interactions, screen generation, code generation; high-level graphics

capability; Web-site creation, etc. For applications of smaller size moving

from requirements gathering step to implementation a non procedural 4GL

may be used. For applications of larger size a design strategy along with the

use of 4GL. 4GL is advantages in reducing the development time of the

software and has a little disadvantage in it being not too simple to use.


1. What do you mean by 4GT?

1.5 Summary

In the evolution of computer based systems, software has become the key

element. Over the past few decades, software has evolved from a problem

solving tool and information analysis tool to an industry in itself. Software

has become a limiting factor. Software consists of programs, data, and

documents. These elements comprise a configuration that is created as part

of the software engineering process. The aim of software engineering is to

build high quality software. Software engineering integrates processes,

methods, and tools for the development of software. A number of different

process models have been proposed for software engineering. Each has

some strength and some weakness.


1. Software is the differentiating characteristic in many computer-based

products and systems. Provide examples of two or three products and at

least one system in which software, not hardware, is the differentiating

element.

2. Provide five examples of software development projects that would be

amenable to prototyping. Name two or three applications that would be

more difficult to prototype.



3. The RAD model is often tied to CASE tools. Research the literature and

provide a summary of a typical CASE tool that supports RAD.


1. Which model incurs more cost?

(a) Prototyping model (b) RAD (c) Spiral Model (d) None of these

2. Which model is used at the time of risk?

(a) Incremental model (b) Spiral model (c) Prototyping model

(d) none of these.


1.8.1 Answers to Self Assessment Questions (SAQs)

1.2.1 : 1. dual 2. true

1.2.2 Refer to 1.2.2

1.2.3 Refer to1.2.3

1.2.4

1. The Web pages retrieved by a browser are software that incorporates

executable instructions (e.g., CGI, HTML, Perl, or Java

2. Word processing, spreadsheets, computer graphics, multimedia,

entertainment, database management, personal and business

financial applications

1.2.5 "the turning point in the course of a disease, when it becomes

clear whether the patient will live or die

1.2.6 Refer to 1.2.6 for both question 1 and 2

1.3.1 Refer 1.3.1

1.3.2 Macro

1.3.3

1. The linear sequential model suggests a systematic,

sequential approach to software development, that begins at

the system level and progresses through analysis, design,

coding, testing, and support.

2. Refer to 1.3.3

1.3.4

1. Requirements

2. Refer to1.3.4

1.3.5 Linear sequential



1.3.6

1. Spiral model

2. Refer to1.3.6

1.3.7

1. Rapid application development

2. Refer to 1.3.7

1.4 The term fourth generation techniques (4GT) encompasses a

broad array of software tools that have one thing in common:

each enables the software engineer to specify some

characteristic of software at a high level.

1.8.2 Answers to Terminal Questions (TQs)

1. Refer to section 1.2.2



1.8.3 Answers to Multiple Choice Questions (MCQs)

1. a

2. b



Unit 2 Project Management Concepts,

Process and Project Metrics

Structure

2.1 Introduction

Objectives

2.2 The Management Spectrum

People

Coordination and Communication Issues

The Product

2.3 Software Process and Project Metrics

Measures, Metrics, and Indicators

Metrics in the Process and Project Domains

Software Measurement

Metrics for Software Quality

Measuring Quality

Defect Removal Efficiency

2.4 Process Decomposition

2.5 Summary




2.1 Introduction

Project management/Software Project Management is an area of

management in which the people, processes and control are monitored and

controlled according to the plan. This is an ongoing process throughout the

evolution of software from a preliminary concept to an operational

implementation. A software engineer is responsible in managing day-to-day

activities of planning, monitoring, and controlling.

Project managers plan, monitor, and control the work of software

engineering team members. Managers at senior level look after the interface

between the business and the software professionals. The entire process of

software development becomes complex as and when conditions changes

and forces a revision in the software. The process involves contribution from

number of people working for a long time on the development. In a software



project the management is essentially the management of people, product,

project and process.

People have to work in a coordinated manner and make their contributions

effective towards the development of the software. Another important aspect

in the successful development of software is the communication.

Communication is a process used for imparting information from a source –

sender to a destination – receiver with the use of some medium of

communication. Communication helps in establishing the requirements of

the customer clearly and also define the scope of the project software. The

development should be appropriate to the people and the product.

Effort required for the completion of the project and the time required to

complete the project has to be properly estimated through the use of

suitable estimation models. The planning must encompass definitions of

products, quality checkpoints, and mechanisms to monitor and control

activities defined in the plan of the project.

Objectives

In this unit we will study:-

How must the people, process, and problem be managed during a

software project?

What are software metrics and how can they be used to manage a

software project and the software process?

How does a software team generate reliable estimates of effort, cost,

and project duration?

What techniques can be used to formally assess the risks that can have

an impact on project success?

How does a software project manager select the set of software

engineering work tasks?

How is a project schedule created?

How is quality defined so that it can be controlled?

What is software quality assurance?

Why are formal technical reviews so important?

How is change managed during the development of computer software

and after delivery to the customer?



2.2 The Management Spectrum

The four P’s: people, product, process, and project are the main points to

focus on during the management of a software project. Software project

manager has to pay attention to the risks involved in the processes of the

project. Else the manager runs the risk of inducting competent technical

methods and tools into the project process. This will decide the fate of the

success of the software project.

(1) The People: For people, recruitment, selection, performance, training,

compensation etc play a key role in the maturity model. It is also

important to note that organizations that achieve high levels of maturity

in people management models have been effectively implementing

software engineering.

(2) The Product: The product objectives and scope are defined by

customers and the software managers/engineers. This follows the steps

of initial software engineering process establishment and development.

This enable the manager to do an effective software requirements

analysis. Product relevant objectives have to be stated. The product

scope defines the functions and the primary data. It indicates the

relationship and behavior. Alternative solutions are developed. The

managers work on the alternatives and select the best alternative under

the limitations of deadlines, personnel availability, budgetary restrictions,

technical interfaces, etc.

(3) The Process: Based upon the complexity of the processes involved in a

project development, the entire development process can be broken

down into number of small processes which can all be set with a

framework of overall software development. Different tasks and

products, along with quality assurance points enable the framework of

activities to be adapted to the characteristics of the software project.

(4) The Project: the only way to manage complex software projects is to go

about it in a planned and a controlled manner. The success rate of the

project depends a lot on the planning and the contribution by people

working on the project. In order to avoid project failure, a software

project manager, and the software engineers who build the product must

avoid warning signs, understand the critical success factors, and



develop a commonsense approach for planning, monitoring and

controlling the project.


1. What is the different management spectrum?

2.2.1 People

There are a number of people working on a software project. They are

known as players. A player participates in the software processes and

perform effective software engineering.

(1) The Player

The software process has players categorized as follows :

1. Project manager plans, motivate, organizes, and controls the

practitioners who work on various processes of the software.

2. Senior manager defines the business issues that has a significant

influence on the project and its related processes.

3. Practitioners deliver the technical skills necessary for the product or

application.

4. Customers specify the software requirements.

5. End-users are the ones who interact with the system.

The software project team has to be very effective and for being effective

they have to work in a coordinated manner. The teamwork should be such

that one gives the best for obtaining good results from the software project.

Team Leader

Software project management is an area where lots of people are involved

in various processes of the project. The one who manages these people in

the team and works toward the success of the software project is the team

leader.

Motivation: It refers to the act of encouraging the people working on the

software project development.

Ideas or innovation: the organization should encourage people to create

and feel creative. They must work within bounds established for a particular

software product or application. A software project manager should

concentrate on understanding the problem, managing the ideas, letting

everyone on the team understand the importance of quality in the service



and product. The aspects of ideation and innovation may be phased in the

following manner :

Problem solving: Based upon the problems faced in the past and the

solutions derived to solve such problems it becomes easy to the software

engineer to device methods to avoid such problems in future. A scheme of

handling such situations by means of some techniques and tools and then

develop the software reflects effective problem solving.

Managerial identity: A project manager must establish good authority on

the project development processes. The manager must take into confidence

the abilities of the project members and maintain a stable and competitive

environment in order to effectively develop the project. In all these activities

the project manager establishes the identity of his or her being a successful

leader.

Achievement: Managers have to take initiatives to encourage the team

members to optimize the productivity of a project team.

Influence and team building: A project manager must understand the

attitude of the people and understand their signals in terms of satisfaction or

dissatisfaction. Even if the situation is tough the manager must keep calm

and handle the situation.


1. What do you mean by people?

2. What is the different category of player?

2.2.2 Issues regarding Coordination and Communication

Software projects are disturbed because of various reasons. One of the

reasons is the scale of the project. Scale refers to the size of the project, the

magnitude of the effort, complexities involved in the project and the size of

the team working on the project or a part of the project. Another reason is

the Uncertainty because of the changes in the project characteristics.

Interoperability ie. Communication between the old modules of the software

and the new modules could be another reason.

To deal with these factors the team members can work in a coordinated

manner. As per Kraul and Streeter, project coordination techniques are

categorized in the following manner:



Formal, impersonal approaches include software engineering documents

and deliverables (including source code), technical memos, project

milestones, schedules, and project control tools, change requests and

related documentation, error tracking reports, and repository data.

Formal, interpersonal procedures focus on quality assurance activities

applied to software engineering work products. These include status review

meetings and design and code inspections.

Informal, interpersonal procedures include group meetings for

information dissemination and problem solving and “collocation of

requirements and development staff.”

Electronic communication encompasses electronic mail, electronic

bulletin boards, and by extension, video-based conferencing systems.

Interpersonal networking includes informal discussions with team

members and those outside the project who may have experience or insight

that can assist team members. To assess the efficacy of these techniques

for project coordination, Kraul and Streeter studied 65 software projects

involving hundreds of technical staff; this expresses the value and use of the

coordination techniques just noted. Referring to the figure, the perceived

value (rated on a seven point scale) of various coordination and

communication techniques is plotted against their frequency of use on a

project. Techniques that fall above the regression line were “judged to be

relatively valuable, given the amount that they were used”. Techniques that

fell below the line were perceived to have less value. It is interesting to note

that interpersonal networking was rated the technique with highest

coordination and communication value. It is also important to note that early

software quality assurance mechanisms (requirements and design reviews)

were perceived to have more value than later evaluations of source code

(code inspections).


1. What are the different project coordination techniques?

2.2.3 The Product

A software project manager has to work on quantitative estimates and

suitable plan to deliver the intended product. Analysis pertaining to the



requirements of the software has to be done to get proper estimates on the

product and its performance. Time is the major constraint. A minimum scope

of the product has to be established.

(1) Software Scope

Determination of software scope is the first step. By answering the

following questions it becomes easy to determine the scope:

Context: Understand the software product under the framework of the

various constraints in the system and the requirements of the system in

which the product is expected to work.

Information objectives: It refers to object visible to the customers. What

are the outputs from the software and what are the inputs to the software?

Function and performance: Understand the functions of the software.

Understand the transformation job of each function of the software. The

functions should be clearly stated so that the management and technical

people can understand it easily.

(2) Decomposition of the Problem

It is also known as partitioning. It is the core software requirement analysis

step. Decomposition is done with respect to the functionality of the software

and the process. It means a complex problem is partitioned into smaller

problems. Smaller problems are easy to manage.


1. What are the software scopes?

2. Problem decomposition are sometimes called _________________ or

________________.

2.3 Software Process and Project Metrics

Software metrics refers to various methodologies of measurements for

software. For continual improvement in the software, it is necessary to have

a measurement done for the software with respect to its functionality and

utility. Measurements are used in a software project for various estimations,

quality controls, assessment of productivity, and various controls.



2.3.1 Measures, Metrics, and Indicators

The necessity of measuring a software product process is to evaluate, to

predict, or to improve. For the measurements it is necessary to understand

the processes, products, resources, and environment in which the software

works, and establish a reference to track the progress. Status should be

brought out to review the progress. This will help identify the deviations and

thereby control the project. These measurements helps in predictions and

predictions in turn will help in setting up various plans.


1. What do you mean by metrics?

2. What do you mean by an indicator?

2.3.2 Metrics in the Process and Project Domains

There is always a dilemma as to which metrics is appropriate and which is

not in software engineering. The question is whether it could have been

better than what it is now? Obtaining a suitable measurement indicator is

always a challenge before the software engineer and the software manager.

An indicator is a metric or a combination of metrics on the software process.

An indicator enables the project manager or software engineer to improve

the process through adjustments.

1) Process Metrics and Improvement of Software Process: The best

way to develop and improvised metric process is to concentrate on

specific process attributes, and provide indicators leading to adoption of

a methodology for improvement. Measure the efficiency of every

process based on the outcomes. Outcomes may be assessed based on

the error rate, defect rate, human effort, time required and conformance

to schedule.

2) Software Metrics

Software process metrics are meant for analyzing strategic issues and

are used for the work flow in the project and related technical activities.

To estimate time and effort for current activities, details of metrics and

outcomes are collected from past identical projects. It helps in

understanding the variances in the ongoing project if any. The project

manager monitors and controls the progress of the project based on the

indicators on each attribute of the process. One process output



performance affects the input of another process. It is a chain reaction.

Hence every process becomes significant in terms of quality delivery.


1. What do you mean by software metrics?

2.3.3 Software Measurement

Software measurements are of two types (a) direct measurements include

cost and effort pertaining to the software leading to measurement of number

of lines of codes, speed, size of memory, error rate and (b) Indirect

measurements includes functionality, quality, reliability, efficiency,

complexity and maintainability of the product.

1) Size oriented metrics:

Normalizing quality and productivity measures can be done by

considering the size of the software. To indicate the size of the software

a simple record of the size or a table of information on the size may be

maintained by the organization for the last few years. The effort and cost

recorded in the table represents all activities.

2) Function oriented metrics:

It refers to the functionality delivered by the software application.

Functionality cannot be measured directly. Function-oriented metrics

were first proposed by Albrecht, who suggested a measure called the

function point. Function points are derived using an empirical

relationship.

3) Extended Function Point Metrics:

The function point measure was inadequate for many engineering

applications but was suitable in most of the cases for business

applications.


1. What are the different types of software measurement techniques?

2.3.4 Metrics for Software Quality:

The software engineers have to work towards achieving a good quality

system and good product. For this purpose they have to resort to good

techniques along with suitable software process. They along with the

managers of the project have to evaluate quality at every stage of the



project. The main objective in doing so should be to measure and control

errors and defects. Effectiveness has to be measured.

2.3.5 Measuring Quality

As per Gilb the following are the definitions and measures of quality:

Correctness: A program must operate correctly or it provides little value to

its users. Correctness is the degree to which the software performs its

required function. The most common measure for correctness is defects per

KLOC.

Maintainability: Software maintenance accounts for more effort than any

other software engineering activity. Maintainability is the ease with which a

program can be corrected if an error is encountered, adapted if its

environment changes, or enhanced if the customer desires a change in

requirements. A simple time-oriented metric is mean-time-to-change

(MTTC), the time it takes to analyze the change request, design an

appropriate modification, implement the change, test it, and distribute the

change to all users. Hitachi has used a cost-oriented metric for

maintainability called spoilage – the cost to correct defects encountered

after the software has been released to its end-users. When the ratio of

spoilage to overall project cost (for many projects) is plotted as a function of

time, a manager can determine whether the overall maintainability of

software produced by a software development organization is improving.

Actions can then be taken in response to the insight gained from this

information.

Integrity: Software integrity has become increasingly important in the age of

hackers and firewalls. This attribute measures a system's ability to withstand

attacks (both accidental and intentional) to its security. Attacks can be made

on all three components of software: programs, data, and documents. To

measure integrity, two additional attributes must be defined: threat and

security. Threat is the probability (which can be estimated or derived from

empirical evidence) that an attack of a specific type will occur within a given

time. Security is the probability (which can be estimated or derived from

empirical evidence) that the attack of a specific type will be repelled.

Usability: The catch phrase "user-friendliness" has become ubiquitous in

discussions of software products. If a program is not user-friendly, it is often



doomed to failure, even if the functions that it performs are valuable.

Usability is an attempt to quantify user-friendliness and can be measured in

terms of four characteristics: (1) the physical and or intellectual skill required

to learn the system, (2) the time required to become moderately efficient in

the use of the system, (3) the net increase in productivity (over the approach

that the system replaces) measured when the system is used by someone

who is Moderately efficient, and (4) a subjective assessment (sometimes

obtained through a questionnaire) of users attitudes toward the system.


1. What are the different quality measurement techniques?

2.3.6 Defect removal efficiency (DRE)

DRE is a measure of the filtering ability of quality assurance and control

activities. When considered for a project as a whole, DRE is defined in the

following manner:

DRE = NE/(NE + ND)

Where NE is the number of errors identified before the delivery of software

and ND is the number of defects found after delivery. Value of DRE is 1

under ideal situations. This happens when there are no errors.


1. What do you mean by defect removal?

2.4 Process Decomposition

While dealing with any software project, one must look into the flexibility

options available to deal with the project. If a project is similar to an earlier

executed project, then a simple linear sequential approach may be adopted

to deal with the project. If the constraints are severely imposed on the

project specially the time constraint, then RAD (Rapid Application

Development) model is more appropriate. Incremental strategy would be the

best if the deadlines are very tight. Once the process model is chosen, CPF

(common process framework) involving customer communication, planning,

risk analysis, etc may be applied. Process decomposition involves

decomposing a task into number of small tasks to accomplish the task, one

by one by means of various events leading to the main task. The sub task



list varies from project to project depending upon the complexities of the

project.

2.5 Summary

Software project management is an umbrella activity within software

engineering. It begins before any technical activity is initiated and continues

throughout the definition, development, and support of computer software.

Four P’s have a substantial influence on software project management –

people, product, process, and project. People must be organized into

effective teams, motivated to do high-quality software work, and coordinated

to achieve effective communication. The product requirements must be

communicated from customer to developer, partitioned (decomposed) into

their constituent parts, and positioned for work by the software team. The

process must be adapted to the people and the problem. A common

process framework is selected, an appropriate software engineering

paradigm is applied, and a set of work tasks is chosen to get the job done.

Finally, the project must be organized in a manner that enables the software

team to succeed. The pivotal element in all software projects is people.

Software engineers can be organized in a number of different team

structures that range from traditional control hierarchies to “open paradigm”

teams. A variety of coordination and communication techniques can be

applied to support the work of the team. In general, formal reviews and

informal person-to-person communication have the most value for

practitioners. The project management activity encompasses measurement

and metrics, estimation, risk analysis, schedules, tracking, and control. Each

of these topics is considered in the chapters that follow.


1. The Software Engineering Institute’s people management capability

maturity model (PM-CMM) takes an organized look at “key practice

areas” that cultivate good software people. Your instructor will assign

you one KPA for analysis and summary.

2. You have been appointed as project manager for a major software

products company.

Your job is to manage the development of the next generation version of

its widely used word-processing software. Because competition is



intense, tight deadlines have been established and announced. What

team structure would you choose and why? What software process

model(s) would you choose and why?

3. Describe the difference between process and project metrics in your

own words.

4. What is an indirect measure and why are such measures common in

software metrics work?


1. Different Management Spectrum

(a) People (b) Project (c) All the above (d) none of these

2. What are the different software practices and projects?

(a) Measure (b) Metrics (c) All the above (d) none of these

2.7 Answers to SAQs, TQs and MCQs

2.7.1 Answers to Self Assessment Question(s) (SAQs)

2.2 People, project, product, process

2.2.1

1. Refer to 2.2.1

2. Software team, team leader, end user, customer etc.

2.2.2 Formal impersonal approaches, interpersonal procedures, Informal

interpersonal procedures, Electronic communication etc

2.2.3

1. Context, inform objective, function and performance

2. Partitioning, problem elaboration

2.3.1

1. Refer to 2.3.1

2. Refer to 2.3.1

2.3.2

Software process metrics are used for strategic purposes.

Software project measures are tactical.

2.3.3 Specific oriented, Function Oriented, Extend function

2.3.5 Correctness, Maintainability, Integration, Usability

2.3.6 A quality metric that provides benefit at both the project and process

level is defect removal efficiency (DRE).



2.7.2 Answers to Terminal Question(s) (TQs)

refers 2.3.1

refers 2.2.1

refer 2.3.2

2.7.3 Answers to Multiple Choice Question(s) (MCQs)

1. c

2. c



Unit 3 Software Project Planning, Scheduling,

Tracking and Risk Management Structure:

3.1 Introduction

Objectives

3.2 Observation and Estimation

Project Planning Objectives

Software Scope

Resources

Software Project Estimation

Decomposition Techniques

Empirical Estimation Models

The Make/Buy Decision

3.3 Risk Analysis and Management

Reactive versus Proactive Risk Strategies

Software Risks

Risk Identification

Risk Projection

Risk Refinement

Risk Mitigation, Monitoring, and Management

3.4 Project Scheduling and Tracking

The Relationship between People and Effort

Defining a Task Set for the Software Project

Selecting Software Engineering Tasks

Defining a Task Network

Earned Value Analysis

Error Tracking

The Project Plan

3.5 Summary






3.1 Introduction

Software project management begins with project planning. The work to be

done and the planning of the resource have to be done keeping in mind the

various objectives of the project work and the constraints on the resources

that are going to be utilized. Another important factor is the time factor which

needs to be estimated well in advance to control the progress of the project.

The entire planning has to be done vey systematically and scientifically.

Project of identical nature to the current project which has been executed in

the past should be studied and understood to bring in necessary control in

the ongoing project. Past experience on the project will always add value to

the execution of the current project. Any past experience will help in

developing the software easily.

Objectives

In this unit you will learn:

The software planning process

The risk management planning

The software tracking and scheduling

3.2 Observation and Estimation

There will be risks associated with every project. The nature and magnitude

of the risk depends upon the various forces that affect the project modules

and the project as a whole. Hence there is a need to estimate the resources

and prepare appropriate schedule for a software engineering effort. This

requires a lot of experience and also the support of historical data will

strengthen the process. Estimations are subjected to some risks and such

risks leads to uncertainty. Uncertainties increase the project complexity

thereby affecting the project plan. A number of methods are available today

to measure complexities in the system. Most of the methods are applicable

at the design level of the software. At the planning stage it is not convenient

to apply such methods. Another factor that affects the accuracy of the

estimates is the Project size. One should not forget the Murphy's law which

states that “What can go wrong will go wrong” – and if there are more things

that can fail, more things will obviously fail.




1. ___________ increase the project complexity thereby affecting the

project plan.

2. _________ is another important factor that can affect the accuracy and

of estimates.

3.2.1 Project Planning Objectives

There are a number of project planning objectives. Though there are a

number of objectives in a software project the most important one is the

objective which is focused on planning. It emphasizes on the framework

enabling the manager to make estimates of resources, cost, and schedule.

These estimates serve as checkpoints for monitoring the entire project

during the course of its progress from start to finish. Also check point must

reflect on the extreme values of the outcome of each stage so that the entire

development process remains under control within the extreme values.

These checkpoints on extreme values serve as boundaries which can help

the manager to validate the outcomes of each stage.


1. What is the objective of any project planning?

3.2.2 Software Scope

Determination of software scope is the first activity in software planning. To

determine the scope one has to understand the functionality and

performance of the module in the software. The scope statement should be

bounded. Software scope must include data, controls, functions,

performance, constraints, interfaces, and reliability. Based on the software

metrics of the completed projects, estimates and schedules can be prepared

with greater accuracy leading to reduction in risks. Risk is measured by the

degree of uncertainty in the quantitative estimates pertaining to resources,

costs and schedule. The software planner must achieve completeness of

function, performance, and interface definitions.

A preliminary discussion between the software engineer/manager with the

customer can be structured enough to narrow the focus on to the

determination of the software scope else it may take number of meetings to

actually determine and define a proper scope. After this phase a feasibility

study will have to be conducted on the initial system design and

requirements.




1. The first activity in software project planning is the determination of

_______.

2. Based on the _________ of the completed projects, estimates and

schedules can be prepared with greater accuracy leading to reduction in

risks.

3.2.3 Resources

The second activity in software planning is the estimation of the resources.

Resources for software projects are the hardware and software tools. They

provide the infrastructure to support the development of the software.

Reusable software components are found at higher levels of the

development process governed by people. It is possible to determine the

number of people required for a software project only after an estimate of

development effort has been made. Unit of development effort is generally

expressed as person-months. It may become useful to identify the software

components from the past projects that may be reused. Reusability leads to

optimization of the software resources.

Self Assessment Questions

1. What are the different resources?

3.2.4 Software Project Estimation

In estimating the software cost and effort the software engineer will have to

consider variables like human, technical, environmental and political. These

variables are found to affect the ultimate cost of software and effort. If the

estimates are based on projects completed in the past which are identical to

current one then the chances of errors creeping in reduces. One may even

use a decomposition technique to estimate the project. A number of

empirical estimation models may also be used with a fare degree of

accuracy.


1. Software ____ and _____ are affected by variables like human,

technical, environmental and political.

3.2.5 Decomposition Techniques

While dealing with software project estimation for large size software, it is

convenient to estimate after decomposing the entire project process into



number of smaller process and then estimate. The entire software project

problem can also be broken down into number of smaller problems and then

each smaller problem could be solved easily. Software project estimation is

a form of problem solving.

3.2.1.1 Software Sizing

The prediction of accuracy of software project estimate is based on size of

the product to be built, ability to translate size into human effort, time and

money and the environment that supports the effort of software engineering.

3.2.1.2 Problem-Based Estimation

Lines of code (LOC) and function points (FP) are used as estimation

variables to "size” elements of the software. LOC and FP are used in

conjunction with estimation variables to develop cost and effort predictors

for various projections. As mentioned earlier the software scope is

considered and various functions are listed out. For each of the functions

LOC and FP are estimated.

Example of estimation – Process Based:

Estimation is done by considering the various activities and tasks involved in

a project. A list of functions involved in operating the various elements of the

software and the corresponding standard requirements are stated and

points are assigned to each function. There may be a list of parameters for

each function for the purpose of estimation. The points are converted into

percentages and expressed as effort. The data may be collected through a

customer process by way of feedback on the functions.

3.2.1.3 Software Equation:

Based on the productivity data collected for over thousands of contemporary

software projects and estimation model may be considered in the form of a

software equation as given below:

EPM = ( L x Sk(1/3) /PP)3 x(1/d4)

Where

EPM – effort in person months

L – number of code line

Sk – factor of special skills

PP – parameter of productivity

d – duration



3.2.1.4 A decision tree

A decision tree is helpful in analyzing a software problem which has multiple

decision stages. Each stage is represented by a node (rectangle). The

multiple options available at this node are represented as branches of this

node in the form of straight lines. Each branch of the tree represents

alternatives and it may further lead to some probable events/outcomes.

Each such event is associated with a probability value and some cost

(– utile) / gain (+ utile). A utile is a monetary value. Nodes which represent

probable outcomes are known as chance nodes and are represented by

circles. A connection of such nodes and branches constitute a decision tree.

Problems associated with risks can be well represented by a decision tree.

3.2.1.5 Automated Estimation Tools

Automated estimated tools are useful to estimate cost and effort and to

perform what-if analysis for variables in projects such as staffing and

delivery rate. They exhibit characteristics like – sizing of the deliverable,

proper selection of activities, estimation of staffing levels and software

effort/cost and schedules.


1. What are the different decomposition techniques?

3.2.6 Empirical Estimation Models

An estimation model used for estimation of software is used to predict effort

as a function of LOC or FP. Number of sample projects considered to derive

such models are small. Hence the reliability on such small sample data

based empirical relations is less.. For this reason, no estimation model is

1

A

B

2

Str-1

Str-2

Str-3

Str-4

P-1

P-2



appropriate for all classes of software and in all development environments.

Therefore, one must judiciously use the results obtained from such models.

(i) The Structure of Estimation Models

A regression analysis is used to derive the model based on data

collected from past software projects. Most of the forms follow the

pattern Y = a + bX, where a and b are the regression constants

In addition to the above relationship, majority of estimation models

have some form of project adjustment component.

Among the many LOC-oriented estimation models proposed in the

literature are E = 5.2 x (KL) 0.91 Walston-Felix model E = 5.5 + 0.73 x

(KL)1.16 Bailey-Basili model

E = 3.2 x (KL)1.05 Boehm simple model E = 5.288 x (KL)1.047 Doty

model for KL > 9 FP-oriented models have also been proposed. These

include E = 13.39 + 0.0545 FP Albrecht and Gaffney model

E = 60.62 x 7.728 x 10-8 FP3 Kemerer model E = 585.7 + 15.12 FP

Matson, Barnett, and Mellichamp model

Estimation models needs to be calibrated before actually it is used.

(ii) The COCOMO Model

Barry Boehm in his book on “Software Engineering Economics“ has

introduced a number of software estimation models known as

COCOMO, for COnstructive COst Model which has evolved into

COCOMO II. COCOMO II addresses the following:

Application composition model: This model is useful in the intitial

stages of software engineering when prototyping of user interfaces,

interactions of software and system are considered, assessment of

performance is done and the evaluation of maturity of technology.

Early design stage model: Once the requirements have been listed

out and stabilized this model becomes useful.

Post-architecture-stage model: Useful during the process of

construction of the software.


1. What are the different Empirical Estimation Models?



3.2.7 The Make/Buy Decision

It is observed that buying a software application is more cost effective than

getting the entire software developed. This is one of the challenges before

every software engineer/ manager. In addition to this a number of options as

listed below makes it difficult to the software engineering managers.

1) software purchased off-the-shelf,

2) “full-experience” or “partial-experience” software components may be

subjected to changes

3) software may be custom built

The acquisition of software is governed by the criticality of the software to be

purchased and the end cost. For expensive software products, the following

guidelines may be considered:

1. Develop specifications for function and performance.

2. Define measurable characteristics.

3. Estimate the internal cost

Various make/buy decision techniques are :

Constructing Decision Trees.

Outsourcing.

Automated Estimation Tools.


1. What are the different make/buy decision techniques?

3.3 Risk Analysis and Management

3.3.1 Reactive versus Proactive Risk Strategies

A majority of software teams work on a structured framework of risk

strategy. The framework consists of only the likely risks which are

anticipated during the process of development of software. Whenever there

is a problem outside the framework then the software team adopts

measures on a case to case basis to solve the problem which is referred to

as fire fighting. When fire fighting doesn’t help then “crisis management”

takes over, and the project gets into real stiff situation.


1. What do you mean by fire fighting mode?



3.3.2 Software Risks

Software risks are analyzed and managed by careful consideration of all the

forces that act on the software processes. It is derived from thorough study

of the people, the product, the process, and the project. Contingency plans

have to be prepared to manage risks in software development processes

which should be realistic. Risk may or may not be there in a project or

project process. But if it does exist then it may result in severe losses to the

project. Project risks always poses a threat to the project plan. If project

risks become real, it is likely that project schedule hampers and results in

increased project costs. Project complexity, size, and the uncertainties of

the project are factors contributing to project risks.


1. What are the different Software risks?

3.3.3 Risk Identification

A project manager is always on the lookout for risks which might hamper the

progress of the project work. The main two types of risks are generic risks

and product specific risks. Generic risks are always a threat to every

software project. Product-specific risks are specific to the product

characteristics and can be identified only by those who have a clear

understanding of the technology, the people, and the environment. To

identify product-specific risks, the project plan and the software statement of

scope are examined. A checklist of risk items are prepared to systematically

identify the risks in a project which can be used in the following categories:

Product size – risks associated with the overall size of the software to be

built or modified. They pertain to -

Business impact – risks associated with market constraints

Customer characteristics – risks associated with the characteristics

identified and listed by the customer

Process definition – risks associated with the degree to which the

software process has been defined

Development environment – risks associated with the availability and

quality of the tools

Technology to be built – risks associated with the complexity of the

system



Staff size and experience – risks associated with the overall technical

and project experience of the software engineers.

3.3.4 Assessing risks, components, drivers, safety risks and hazards:

Risks can be assessed overall by taking risk data through surveys. A

number of questions as part of questionnaire can be framed as a tool to

collect data, which can then be used to analysis and assess risks in

software projects. The project may be at risk depending upon the number of

negative responses obtained during the survey.

Manager has to identify the risk drivers that affect the risk components in a

project. One must identify the software performance costs and the relevant

controls.

Safety risks and hazards can occur during installation of software or even

after its installation. These are associated with the software failure. These

are the quality assurance activities which can affect performance of the

software and hence the overall software. If it is possible to identify the risks

at an early stage of the development, then automated functions can be

incorporated to eliminate if encountered in future.

3.3.5 TSS value, Timeline and Tracking

A TSS – Task set selector is a selector used to select a set of tasks, which

would be appropriate to a project. The task set will be different for different

projects. It is a collection of software work tasks, deliverables which are to

be completed to compete the project. For an effective development of the

software one must a well defined task set. Different degrees of rigor may be

considered in selecting a set of task for a project. Some of them are

structured, casual, strict and reaction. The task set becomes the basis for

the preparation of task network. It is also known as activity network. The

monitoring the such a network of tasks is done with the help of a time line

chart which indicates the start time of an activity, its duration and its finish

time followed by the next activity and so on till the last activity is reached

and completed. The project map which reflects the entire project schedule is

the basis for tracking the project and its performance. Tracking can be done

through project meetings and reviews, measuring the progress of each

activity, evaluating the performance, comparing performances, and

understanding the gaps for future course of action to be decided.




1. _________________ is a systematic attempt to specify threats to the

project plan.

3.3.6 Risk Projection

Risk projection rates each risk in two ways – the likelihood that the risk is

real and the consequences of the problems associated with the risk, should

it occur. Risk projection is also known as risk estimation.

The risk projection activities are:

1) establish a scale to indicate the likelihood of a risk,

2) list out the consequences of the risk,

3) estimate the impact of the risk and

4) determine the overall accuracy of the risk projection


1. Risk projection is also called _____________

3.3.7 Risk Refinement

After the commencement of the project, during the initial stages the

statements on risks appear to be vague and general. Only after some

progress of the project does it become possible to clearly state the risks.

it may be possible to refine the risk into a set of more detailed risks, each

somewhat easier to mitigate, monitor, and manage. One way to do this is to

represent the risk in condition-transition-consequence (CTC) format [GLU].

The condition can be refined in the following manner:

Subcondition 1: Certain reusable components were developed by a third

party with no knowledge of internal design standards.

Subcondition 2: The design standard for component interfaces has not

been solidified and may not conform to certain existing reusable

components.

Subcondition 3: Certain reusable components have been implemented in a

language that is not supported on the target environment. The

consequences associated with these refined sub conditions remains the

same, but the refinement helps to isolate the underlying risks and might lead

to easier analysis and response.




1. What are the different conditions for risk refinement?

3.3.8 Risk Mitigation, Monitoring and Management

The risk analysis activities help the software team to develop strategy to

deal with risks. An effective strategy is generally based on the following

issues of risk:

avoidance

monitoring

contingency planning

Risk management

Avoidance is the best strategy if the team adopts a proactive approach. The

following steps may be followed :

Meet current staff to determine causes for turnover.

Mitigate causes of risks as quickly as possible

Assume turnover will occur

Organize project teams so that information is communicated well among

each member

Define documentation standards and their requirements

Establish mechanisms to ensure proper upkeep of the documents

Conduct peer reviews of all work


1. What is the main goal of risk analysis?

3.4 Project Scheduling and Tracking

In the process of development and delivery of the software it is found that

most of the time the delivery of the finished product is delayed. There are

many reasons that could be attributed to the delayed delivery of the product.

Some of the reasons which leads to the delay of the project are listed below:

Very often the requirements are not clearly stated by the customer and

this leads to further changes in the developments which on the whole

causes a delay in the project completion.

Setting up of deadlines which are unrealistic based on the inputs from

agencies outside the software development group.



Improper or underestimated amount of the effort and the number of the

resources required to do the job.

Inaccurate tools to monitor and track the project progress

Certain risks that were not considered during the planning process

leading to development of bottlenecks in the project.

Also there could be one or more problems related to the technicalities in

the project

Improper communication systems within and outside the development

area of the software.

3.4.1 People and Effort - Relationship

It is a well known fact that for small projects less number of people are

required and for large projects more people are required. The team working

on the project understands the requirements of the projects, analyze the

constraints and the conditions under which the product has to be developed.

They have to have a strong design and analytical mind to execute the

project as per the plan. As the requirements increases or as the complexity

in the project increases there might be a need to add more people into the

team to share the work. Sometimes it is successful and sometimes not.

Since more people would either gel well in the system team or add

confusion in the team. It is necessary to carefully assess the need to add

more people in the team by means of proper estimation of the effort and

load involved. Empirical relationships may also be used to estimate the

project completion in terms of the code lines to be delivered in the product

completion. Similarly the effort distribution in the project can be streamed. It

is believed that the effort distribution in a project generally follows a 40-20-

40 rule. This means about 40% of effort is towards front end and design

aspect. 20% of effort goes towards coding and the remaining 40% is

towards back end tasks.


1. Explain the relationships between people and effort.

3.4.2 Defining a Task Set for the Software Project

It is not always possible to define a unique set of task which would be

appropriate for all types of projects. It is dependent on the size of the

project, complexities involved in the project, constraints of the projects and

the skill set and capabilities of the team members working on the project.



The task set is defined based on the category of the project which is dealt

with by the development team.

The categories of project work that are normally encountered are:

1. Projects dealing with development of new concepts in business.

2. Projects dealing with development of new applications in business as

indicated in the requirements list stated by the customer.

3. Projects dealing with the enhancement of existing facilities in the

product.

4. Project dealing with maintenance aspects of the business modules or

applications.

5. Project dealing with total new structure or restructuring an old system

into a new system or application leading to reengineering.


1. It is not always possible to define a ________ set of task which would be

appropriate for all types of projects.

3.4.3 Selecting Software Engineering Tasks

1. A task has to be properly distributed according to the needs of the

project deadlines and set targets. Each project may result in product

flow into another type. After completion of one project it leads to another

phased project to work on the enhancements. To develop a project

schedule, a task set must be distributed on the project time line.

Sometimes the projects may lead into what is known as Concept

Development instead of enhancements. The trigger for concept

development is the necessity of a new technology in a particular area.

determines the overall scope of the project. Concept Scoping determines

the overall scope of the project. Following tasks are performed leading to

Concept development projects:

1. Determine the scope of the project

2. Concept planning which establishes the organizations ability to work as

defined in the project scope.

3. Technology risk assessment is done to evaluate the risk associated with

the technology.

4. A proof or evidence of the concept to justify the feasibility of the

technology in the project.



5. Implement the concept in such a manner that the customer would

understand it and review it and based on this react.


2. In order to develop a project schedule, a task set must be _______on

the project time line.

3. ____________determines the overall scope of the project.

3.4.4 Defining a Task Network

Tasks and Subtasks are related to each other in the sequence of project

network. When there are more people working on the project there is a

chance of people working parallel on different tasks. Under this situation, a

good control system has to be established to monitor the parallel tasks.

Task network is also known as Activity network. Activity network can be

represented graphically. Sometimes it is used as a methodology through

which sequence of tasks and dependencies are input.

3.4.5 Earned Value Analysis

Earned value analysis is a quantitative technique to assess the progress in

the project activities. The assessment is somewhat difficult as it involves

qualitative analysis of various factors affective the progress of the project.

There is an element of subjectivity which is difficult to measure. Hence

earned value analysis is considered very important in assessments of

activities in a project.

As per Humphrey, the earned value system provides a common value scale

for every project task, regardless of the type of work being performed. The

total hours to do the whole project are estimated, and every task is given an

earned value based on its estimated percentage of the total. Earned value is

a measure of progress expressed as percentage of completed project. As

per Fleming and Koppleman earned value analysis “provides accurate and

reliable readings of performance from as early as 15 percent into the

project.”

Earned value can be determined as follows: [Source : Software

Engineering- By Roger S Pressman]

1. The budgeted cost of work scheduled (BCWS) is determined for each

work task represented in the schedule. The work (in person-hours or

person-days) of each software engineering task is planned. Hence,



BCWSi is the effort planned for work task i. To determine progress at a

given point along the project schedule, the value of BCWS is the sum of

the BCWSi values for all work tasks that should have been completed by

that point in time on the project schedule.

2. The BCWS values for all work tasks are summed to derive the budget at

completion,

BAC. Hence, BAC = – (BCWSk) for all tasks k

3. Next, the value for budgeted cost of work performed (BCWP) is

computed. The value for BCWP is the sum of the BCWS values for all

work tasks that have actually been completed by a point in time on the

project schedule.


1. What do you mean by earned value analysis?

2. ____________________enables us to assess the “percent of

completeness” of a project using quantitative analysis rather than rely on

a gut feeling.

3.4.6 Error Tracking

A team that works on a project to deliver the product or the services might

end up committing an error. The errors introduced could be at different

levels associated with different processes. If a record of such errors over

number of projects is maintained, it can become a useful source of

information to take decisions on similar errors in future. The manager may

even develop a process to manage such errors based on an appropriate

decision model to tackle the errors. Suitable metrics and measure may be

used to handle errors of similar nature if errors recurs. This process can

become one of the useful sources of information to report the status of the

project progress.


1. _______________can be used as one means for assessing the status

of a current project.

3.4.7 The Project Plan

A Project plan refers to a blue print of the project plan and its execution. A

plan has to indicate clearly the scope of the project , resources required,

risks associated and the corresponding risk management techniques,

management review plan, cost aspects and the methods and measure to



ensure quality in the project. The project plan is represented in different

forms dependent on the type of user of the document of plan. The project

plan on the whole acts as a source of information to planner and executers.

The executers benefit from the project plan in the sense that they will have

the idea of how to monitor and control the progress of the project and to

ensure that the project throughout is kept on track.


1. What do you mean by project plan?

3.5 Summary

The software project planner estimates (i) time the project will take for

completion, effort required and the manpower needed. The project planner

must also know how to analyze future requirement of the project in terms of

manpower and other related resources. The scope of the project enables

the project manager to develop suitable estimates.

The estimates involves understanding (1) the number of Lines of codes

(2) values within the information domain, (3) manpower size or (4) the

number of person-months required. Empirical techniques and automated

tools may be used to predict project quantities. The time spent identifying,

analyzing, and managing risk results in stabilizing the project progress,

guiding the project smoothly towards its completion, along with tools and

techniques to track and control a project.


1. Develop a list of software characteristics (e.g., concurrent operation,

graphical output) that affect the complexity of a project. Prioritize the list.

2. Performance is an important consideration during planning. Discuss how

performance can be interpreted differently depending upon the software

application area.

3. Provide five examples from other fields that illustrate the problems

associated with a reactive risk strategy.


1. What are the different ways of creating project schedule?

(a)Time Line Chart (b) Gantt Chart (c) all the above (d) none of these

2. Which of the following are the project scheduling methods?

(a) PERT (b) CPM (c) All the above (d) none of these





3.2.1

1. Uncertainty 2. Project size.

3.2.2 The objective of software project planning is to provide a framework

that enables the manager to make reasonable estimates of

resources, cost, and schedule.

3.2.3

1. Software scope 2. Software metrics

3.2.4 Refer to section 3.2.4

3.2.5 Cost and effort

3.2.6 Software sizing, problem based estimation

3.2.7 The Structure of Estimation Models, COCOMO model

3.2.8 Creating a Decision Tree, Outsourcing, Automated Estimation Tools


3.3.2 Uncertainty, loss

3.3.3 Risk identification

3.3.4 Risk estimation


3.3.6 To assist the project team in developing a strategy for dealing with

risk.

3.4.1 Refer to 3.4.1

3.4.2 Unique

3.4.3 Distributed, Concept scoping

3.4.4 Refer to section 3.4.4, Earned Value Analysis

3.4.5 Error tracking







1. c

2. c



Unit 4 Software Quality Assurance

Structure

4.1 Introduction

4.2 Software Quality Assurance

Quality Concepts

The Quality Movement

Software Reviews

Formal Technical Reviews

Software Reliability

Background Issues

Software Quality Assurance – Activities

SQA plan

4.2 Summary




4.1 Introduction

The main objective of software engineering is to produce high quality

software. But the question is – What is meant by software quality ?

According to Philip Crosby - The problem of quality management is not what

people don't know about it. The problem is what they think they do know . . .

Most of the software engineers believe that the quality of software begins

only after the software has been developed and implemented. In many

cases the software engineers start anticipating the quality issues that are

likely to be of importance and work towards development in that direction.

Irrespective of nature of approach it is the Software quality assurance (SQA)

that is applied throughout the software development process.

Objectives

In this chapter you will learn:

What is software quality assurance?

How does it work?

What is work product?

How is it important?



4.2 Software Quality Assurance

4.2.1 Quality Concepts

It is a well known fact that all engineered and manufactured parts exhibit

some or the other variation. The variations may not be clearly visible always.

The variations are sometimes microscopic which can be identified by means

of some equipment necessary to measure the geometrical attributes,

electrical characteristics etc.

Quality

Designers specify the characteristics of the quality of a product. The grade

of materials used in the product development and product characteristics,

permissible tolerances, and performance specifications contribute to the

quality of design. For higher-grade of materials the tolerances are very

small. When the tolerance is set to a very low level the expected design

characteristics would be of high quality. When greater levels of performance

are specified, there is an increase in the design quality of a product and the

manufacturing processes and the product specification are set according to

the specified quality norms.

Quality of conformance is expressed as the degree to which the design

specifications are followed during the process of manufacturing. If the

degree of conformance is high then the level of quality of conformance is

also deemed as high.

Quality of conformance is mainly focused on the implementation of the

software.

Quality Control

Quality is the buzz word of every organization today. But how does one

work towards achieving quality in the organization and within the

organization at various process levels. There are a number of ways of

achieving quality. One can consider the fundamental step of quality where

the variations are measured with respect to the expected values in any

process or characteristics of the product. The first step towards quality is to

see that the variations are minimized. Controlling quality can be done by

means of measuring various characteristics of the product and

understanding the behavior of the product towards changes in the product

characteristics. It involves a series of inspections, reviews, and tests on the

software processes. A feedback mechanism in the process list will help in



constantly reviewing the performance and enhancement in the performance.

A combination of the measurement and the feedback allows the software

developer to refine the software process and tend to approach perfection.

It is possible to automate these steps in the quality control process of the

software system. One of the concepts of quality control is that every process

can be measured. The measurement will tell as to whether there has been

any improvement in the process or not.

Quality Assurance

Quality assurance is a process of auditing various areas and identifying the

non conformances in such areas. A non conformance is reported if a

deviation is observed in the actual performance when compared with the

planned performance against certain expectation. The expectations are

listed out based on the requirement of certain standards norms. The non-

conformances are reported area wise or process wise. The report based on

the audit provides the management with the information that is necessary

for them to take suitable actions.

Cost of Quality

There are many activities involved in a software project leading to the

completion of the intended service or the product. Every such activity is

associated with some cost. And associated with every process is the quality

which again comes with certain cost. The total cost of quality means the

sum total of all the costs involved in setting up a quality process or a quality

activity and additional resources procured towards maintaining and running

the quality process. The main categories under which the quality costs may

be listed are the ones dealing with processes towards prevention, processes

towards appraisal, and processes towards maintenance. The main

components contributing towards the cost are the cost component of quality

planning, cost component of formal technical reviews and the cost

component pertaining to the test equipment.


1. _____________ is a process of auditing various areas and identifying

the non conformances in such areas.

2. ______________involves the series of inspections, reviews, and tests

used throughout the software process to ensure each work product

meets the requirements placed upon it



3. The _________________includes all costs incurred in the pursuit of

quality or in performing quality-related activities.

4.2.2 The Quality Movement

The quality movement started in the 1940s with a major contribution on

quality aspects from W. Edwards Deming. One of the major benefit of

quality has been the saving in the overall cost of production. A system of

continuous improvement helps in achieving good quality. Kaizen, refers to a

system of continuous process improvement. The purpose of kaizen is to

develop a process that is visible, repeatable, and measurable. After Kaizen

it is atarimae hinshitsu, which refers to examination of intangibles that affect

the process and works to optimize their impact. Both kaizen and atarimae

hinshitsu focuses on processes. The next stage is kansei which leads to

improvement in the product itself and, potentially, to the process that

created it. The final stage is miryokuteki hinshitsu which broadens the

management concern beyond the immediate product.


1. The first step of quality movement is known as___________.

4.2.3 Software Reviews

[Source: Software Engineering – Roger S Pressman] Software reviews are

a "filter" for the software engineering process. That is, reviews are applied at

various points during software development and serve to uncover errors and

defects that can then be removed. Software reviews "purify" the software

engineering activities that we have called analysis, design, and coding.

Freedman and Weinberg discuss the need for reviews this way:

Technical work needs reviewing for the same reason that pencils need

erasers: To err is human. The second reason we need technical reviews is

that although people are good at catching some of their own errors, large

classes of errors escape the originator more easily than they escape anyone

else. The review process is, therefore, the answer to the prayer of Robert

Burns:

O wad some power the giftie give us to see ourselves as other see us



A review – any review – is a way of using the diversity of a group of people

to:

1. Point out needed improvements in the product of a single person or

team;

2. Confirm those parts of a product in which improvement is either not

desired or not needed;

3. Achieve technical work of more uniform, or at least more predictable,

quality than can be achieved without reviews, in order to make technical

work more manageable.

Cost Impact of Software Defects

The primary objective of formal technical reviews is to find errors during the

process so that they do not become defects after release of the software.

The obvious benefit of formal technical reviews is the early discovery of

errors, so that they do not propagate to the next step in the software

process.

A number of industry studies (by TRW, Nippon Electric, Mitre Corp., among

others) indicate that design activities introduce between 50 and 65 percent

of all errors (and ultimately, all defects) during the software process.

However, formal review techniques have been shown to be up to 75 percent

effective in uncovering design flaws. By detecting and removing a large

percentage of these errors, the review process substantially reduces the

cost of subsequent steps in the development and support phases.

Defect Amplification and Removal

A defect amplification model can be used to illustrate the generation and

detection of errors during the preliminary design, detail design, and coding

steps of the software engineering process. A box represents a software

development step. During the step, errors may be inadvertently generated.

Review may fail to uncover newly generated errors, and errors from

previous steps, resulting in some number of errors that are passed through.

In some cases, errors passed through from previous steps are amplified

(amplification factor, x) by current work. The box subdivisions represent

each of these characteristics and the percent of efficiency for detecting

errors, a function of the thoroughness of the review.




1. What is the use of using review?

4.2.4 Formal Technical Reviews

Software engineers participate in all the reviews of the technicalities of the

software. A technical review is a software quality assurance activity. The

main objectives of the Formal Technical Reviews are :

a) to bring out the nature and type of errors related to function, logic or

even with respect to the implementation of the software;

b) to check that the software development is as per the expectations

expressed in the plan;

c) to ensure conformance to standards stated with respect to the software

under considerations ;

d) to manage the project more conveniently and easily.

FTR also acts as a forum to provide orientation to members in the team to

work on the developments, provide facts leading to new ideas and

generation of approaches that could be adopted in the development of the

software.

The Review Meeting

The review meeting is also referred to as executive committee review

meeting or the management review. The frequency of the meeting is

decided by the review leaders of various functions in the organization. The

meeting is structured by the representative of the organization and the

review team by means of well defined agenda. The meeting is attended by

all the members and leaders of the various functions. There is an in-charge

to record the proceedings of the meeting. The in-charge is known as the

recorder. The FTR commences with an introduction of the members,

welcoming of new members to the meeting, and introduction of the agenda.

The meeting then begins agenda wise. The agenda is read out by the

representative and discussions on the agenda begin. A report on the

agenda is presented by the representative or by the function heads. If any

problems are encountered in a particular area, it is discussed at length by

the members of the meeting. Suitable corrective actions and preventive

actions are decided for implementation. Such action plans are recorded by

the recorder. After the completion of the review meeting the members of the



review committee would have understood and accepted the action plan

resulting in the following :

1) product is accepted without any modification,

2) product is to be rejected because of major errors,

3) product modifications accepted with a clear understanding of the

deadlines and the in-charge who would be responsible for the change.

i) Review Reporting and Record Keeping

The meeting discussions are recorded and the minutes of the meeting are

circulated to all the members of the review committee. The minutes are

sometimes referred to as the key notes for various reports generated based

on the agenda. The contents of the reports are important as it will enable

one to understand the areas of strengths and weaknesses in the

organization.

Review Guidelines

Various guidelines are framed with respect to the review agenda and

communicated to all the concerned in the organization. The following are

some of the minimum guidelines for formal technical reviews:

1. While reviewing the product, errors should be pointed out gently in order

not to hurt anybody. The meeting discussion should be taken up

positively and should be constructive in suggestion. Once the review

session has commenced the members should follow the agenda. The

discussion should be related to the agenda. At no point of time during

the review should the focus be lost from the agenda. Any clarifications

on the agenda should be sought preferably in advance so as to ensure a

smooth conduct of the review. The review convener or the head should

throughout keep track of the time and the agenda and make

arrangements to support the discussions by means of arranging

necessary documents, equipments, demonstrations, statistics, reports

etc.

2. Recording points for further adjournment : Whenever there is any

discussion leading to some kind of debate or arguments or dissent, the

convener of the FTR can pitch in and moderate the discussion as the

case may be. But if the convener feels that certain points may not be

possible to be discussed during the ongoing session then the convener

may list out such points as agenda to be discussed in the next meeting



or even adjourn the discussion of FTR to another mutually agreeable

date and time as per the convenience of the FTR members.

3. Areas of Problems : Areas which have reported problems during the

past performance may be highlighted by the convener so that the such

areas can become major areas of discussion. This would enable the

members of other similar areas to check upon their activities and control

recurring of such problem in their areas.

5. Limiting the members : It is a good practice to keep the FTR members

limited to the heads of the functions in the organization. Much before the

FTR members of various functions can organize meeting at their

functional level and come out with concreted points for the main

discussion in the FTR by the Function head. This would create a great

impact on the overall outcome of the FTR. The discussion in FTR if

limited to only the key persons or the heads it becomes easy to focus on

the key points pertaining to the agenda, as otherwise opinions and ideas

expressed by many members would lead to confusion and chaos in the

FTR. Also the focus on the agenda would get diluted.


1. What are the different steps for reviewing guidelines?

4.2.5 Software Reliability

The need for quality is there in the minds of everybody associated with the

software project. One of the key issues pertaining to the quality aspect is the

reliability of the software product. There are number of methods to ensure

reliability of the product which depends upon the characteristics of the

product and its features and the expectations from the product and its

services. One of the task before the software engineer or the software

manager is to establish the relevant reliability measures well in advance

before the implementation so that the quality is assured. A series of audits

may be conducted to keep a tab on the deviations if they tend to occur.

Statistically the software reliability may be defined as the probability of an

operation of a computer program which is free from error or has not failed

during the operation time, tested under a specified environment and for

specified time. Failure refers to nonconformance to the requirements of the

software stated. One of the simple measures of reliability is the express it as

the meantime between failure (MBF) which is the sum of mean time of



occurrence of failure (MTF) and mean time towards repair (MTR). It is

necessary to identify and assess the hazards in software projects that affect

the software performance. If it is possible to identify the hazards in the early

stages of the software project then a module to counteract such hazards

could be developed or built in to the software which will then be able to

rectify errors leading to hazards. Suitable models could be used to achieve

this safety.

Background Issues

The quality assurance processes are very vital in establishing quality

features in the product. Various standard mechanisms are developed in the

companies to focus on the quality of the product. These mechanisms have

to undergo improvements time to time in order to maintain the competition in

the market. The product has to be viewed from the user point of view. A

satisfaction note on the various features of the product is necessary to be

reviewed to bring a change in the product to enhance it and to make it a

quality product.

4.2.6 Software Quality Assurance – Activities

The quality assurance has a number of activities. A number of people are

involved in these activities from software engineers to software managers to

quality controllers. The activities ranges from selecting a suitable method to

maintain the quality of the product, monitor the processes control the

processes, testing and validating various process and to ensure that the

performances of such processes are within certain prescribed quality norms.

The objective of the team members working on the SQA activities is to

achieve high degree of satisfaction on the quality front from the customers.

4.2.7 SQA plan

A plan pertaining to the software project is prepared and reviewed by

various experts before actually it is implemented. Everybody involved in the

project are bound to be governed by the plan. The plan indicates (a) various

types of assessments to be done (b) periodic reviews to be done

(c) conformance to standards (d) relevant documents and (e) proper

feedback mechanism which will enable to collect sufficient data which is

used for analysis.



4.3 Summary

Quality is the buzz word of every organization today. But how does one

work towards achieving quality in the organization and within the

organization at various process levels. A feedback mechanism in the

process list will help in constantly reviewing the performance and

enhancement in the performance. Quality assurance is a process of

auditing various areas and identifying the non conformances in such areas.

There are many activities involved in a software project leading to the

completion of the intended service or the product. A technical review is a

software quality assurance activity. FTR also acts as a forum to provide

orientation to members in the team to work on the developments, provide

facts leading to new ideas and generation of approaches that could be

adopted in the development of the software. The need for quality is there in

the minds of everybody associated with the software project. One of the key

issues pertaining to the quality aspect is the reliability of the software

product. Failure refers to nonconformance to the requirements of the

software stated. The quality assurance processes are very vital in

establishing quality features in the product. A plan pertaining to the software

project is prepared and reviewed by various experts before actually it is

implemented. Data about the software engineering process should be

collected, evaluated, and disseminated to smoothly conduct a SQA.

Statistical SQA is helpful in improving the quality of the product and the

software process. Software reliability models along with suitable metrics, are

considered which leads to the identification of the appropriate data and data

collection methodologies making the process simpler and easier.

4.4 Terminal Questions (TQs)

1. Quality and reliability are related concepts but are fundamentally

different in a number of ways. Discuss them.

2. Can a program be correct and still not be reliable? Explain.

3. Can a program be correct and still not exhibit good quality? Explain.

4.5 Multiple Choice Questions (MCQs)

1. What is the full form of MTBF

(a) meantime- between-failure (b) Max time between failure (c) all the

above (d) none of these.





4.2.1 Quality assurance, Quality control, cost of quality

4.2.2 Kaizen




1. refer to section 4.2.2




1. a



Unit 5 Software Configuration Management

Structure:

5.1 Introduction

5.2 Software Configuration Management

Software Configuration Management

The SCM Process

Identification of Objects in Software Configuration

Version Control

Change Control

Configuration Audit

SCM Standards

5.3 Summary




5.1 Introduction

It is not possible to avoid changes in software that has been developed

based on the specifications laid down by the customer. Changes may come

from customer or from a third party who is using the software module for

some or the other application. Changes can lead to lot of confusion amongst

various users if not perceived and analyzed properly. Changes have to be

understood and should be documented for all future references. It is a good

practice to keep a log of all such reviews and discussion leading to the

changes in the software. Configuration management is the management of

all such activities that require proper coordination of members and the

changes required in the software. It is an activity of the software

development. Its main objective is to minimize confusions in bringing about

a change in the software and thereby the software development activity.

This will lead to maximization of the productivity of the software. Software

configuration management (SCM) is applied throughout the software

process and it is applied as and when the change is required because

changes can occur during any stage. The main reason to develop SCM

activities are (1) to identify the changes, (2) to control the changes,



(3) ensure proper implementation of changes and (4) reporting the changes

to the concerned.

Objectives

In this chapter you will learn :-

What is software configuration?

What are the steps in software configuration?

Why is it important?

5.2 Software Configuration Management

5.2.1 Software Configuration Management

It is well known that the output of most of the software process is the

information. This information is divided into three broad categories –

programs, documents and data. The list of items that consists of all the

information produced by one or more processes of the software are together

known as software configuration. As more and more processes are

executed more and more items are generated and the information list grows

along with the number of software configuration items (SCI).The software

project plan and the software requirements specifications are laid forth each

time the software configuration items builds up. This leads to creation of

hierarchy of information. The systems engineering law states that in the

systems life cycle, the system will undergo a change if not there will be a

tendency to change. This tendency will persist throughout the life cycle of

the software project development activity.

Baseline

A baseline is a concept of the software configuration management that is

useful in controlling the changes in the software process based on certain

guidelines.

Software Configuration Items

Configuration objects are formed out of clusters of software configuration

items. The objects are listed in the project database under a title. The object

has all applicable attributes and is connected by means of arrows indicating

relationships amongst objects in the system. An arrow indicates

compositional relation. A compositional relation means a data model and a

specific component are held together as a part of the object design



specification. Interrelationships are indicated by means of doubled headed

straight arrows.


1. What do you mean by Baselines?

5.2.2 The SCM Process

A software project has to go through a set of processes. Each process has

to be well defined according to the output it is expected to generate. The

outputs are dependent on the inputs fed to the process. These processes

have to be developed keeping the quality aspect in mind. The processes are

expected to deliver quality output. The assurance on the quality front has to

be made at every process level in the overall development of the product

and the related services. One of the important elements of the software

quality assurance is the software configuration management. It is mainly

concerned with the control of the changes that are required in the processes

and maintaining different versions of the changes. These changes are

audited periodically to have a proper control on the changes and qualitative

control on the changes. Proper documentation is necessary for the audits to

be successful. A set of questions can become a part of periodic audit

process within each function of the software process like the ones listed

below :

What are the documented procedures to bring about a change in the

process and the product ?

How are the changes identified ?

What are the reasons for the change ?

Who has approved the change ?

What are the deadlines and who is responsible to bring about the

change?

How are the change s controlled ?

Upon bringing about the change is it communicated to others associated

with the project ?

The key five SCM task that could be brought out based on the above

questions are identification of change, change control, change version

control, auditing, and reporting.




1. Software configuration management is an important element of

_________.

5.2.3 Identification of Objects

The software configuration items have to be managed and controlled. The

management of the items and their control is possible only if they are named

and identified depending upon the category to which they belong to. Object

oriented approach may be adopted for this task. There are two categories

generally – basic objects and aggregate objects. A unit of text is the basic

object. It is created by a software engineer during the stages of analysis,

design, coding and testing. Whereas aggregate objects are collection of

basic objects. Sometimes aggregate objects may also contain other

aggregate object.


1. What are the different types of objects?

5.2.4 Version Control

A number of configuration objects are created during the software process.

The changes resulting because of the process specification changes and

the tools are held together and combined into a single version control

number.

Clemm describes version control in the context of SCM as – Configuration

management allows a user to specify alternative configurations of the

software system through the selection of appropriate versions. This is

supported by associating attributes with version number and allowing a

configuration to be specified by describing the set of desired attributes.


1. ______________combines procedures and tools to manage different

versions of configuration objects that are created during the software

process.

5.2.5 Change Control

The change control in software engineering context as per James Bach is:

Change control is vital. But the forces that make it necessary also make it

annoying. We worry about change because a tiny perturbation in the code

can create a big failure in the product. But it can also fix a big failure or



enable wonderful new capabilities. We worry about change because a

single rogue developer could sink the project; yet brilliant ideas originate in

the minds of those rogues, and a burdensome change control process could

effectively discourage them from doing creative work.


1. What do you mean by change control?

5.2.6 Configuration Audit

A software developer can maintain records pertaining to identification label,

change version control, and change control in order to avoid confusion

because changes if any in future. But the question is how can one ensure

that the change has been implemented properly or not? The answer is

(1) formal technical reviews and (2) the software configuration audit. To

determine the consistency with all SCIs, the reviewers have to assess the

omissions and the side effects of omission. It is a good practice to conduct

FTR for every change but however the size of the FTR committee may be

restricted depending upon its significance to other functions related to the

software project.


1. What do you mean by Configuration Audit?

5.2.7 SCM Standards

Over the past two decades a number of software configuration management

standards have been proposed. Many early SCM standards, such as MIL-

STD-483, DODSTD- 480A and MIL-STD-1521A, focused on software

developed for military applications. However, more recent ANSI/IEEE

standards, such as ANSI/IEEE Stds. No. 828-1983, No. 1042-1987, and

Std. No. 1028-1988 [IEE94], are applicable for nonmilitary software and are

recommended for both large and small software engineering organizations.

[Source : Software engineering – by Roger S Pressman]

5.3 Summary

Configuration management is the management of all such activities that

require proper coordination of members and the changes required in the

software. It is an activity of the software development. Its main objective is

to minimize confusions in bringing about a change in the software and

thereby the software development activity. As more and more processes are



executed more and more items are generated and the information list grows

along with the number of software configuration items (SCI). The software

project plan and the software requirements specifications are laid forth each

time the software configuration items builds up. Configuration objects are

formed out of clusters of software configuration items. The objects are listed

in the project database under a title. A software project has to go through a

set of processes. Each process has to be well defined according to the

output it is expected to generate. The outputs are dependent on the inputs

fed to the process. The software configuration items have to be managed

and controlled. The management of the items and their control is possible

only if they are named and identified depending upon the category to which

they belong to. A software developer can maintain records pertaining to

identification label, change version control, and change control in order to

avoid confusion because changes if any in future.


1. Why is the First Law of System Engineering true? How does it affect our

perception of software engineering paradigms?

2. Discuss the reasons for baselines, in your own words.

3. Assume that you're the manager of a small project. What baselines

would you define for the project, and how would you control them?


1. Which of the following are the types of objects?

(a) Basic Objects (b) Aggregate objects (c) All the above

(d) None of these

2. Software Configuration belongs to which of the following activities?

(a) Umbrella activity (b) Economic Activity (c) All the above

(d) None of these.



5.2.1 A baseline is a software configuration management concept that

helps us to control change without seriously impeding justifiable

change

5.2.2 Software quality assurance



5.2.3 Basic objects and aggregate objects

5.2.4 Version control

5.2.5 Refer to 5.2.5







1. c

2. a



Unit 6 System Engineering

Structure

6.1 Introduction

Objectives

6.2 System Engineering

Computer Based Systems

The System Engineering Hierarchy

Requirements Engineering

6.3 Summary




6.1 Introduction

One of the main reasons for the software engineering to get initiated is the

process called system engineering. Systems engineering deals with

software and also other related elements of the software pertaining to a

business. It deals with analysis, design and organization of the various

elements into the business system. The system ultimately has to give the

end result in the form of a product or a service. This process of systems

engineering is known as business process engineering. If a product with

certain characteristics is to be built the process is called product

engineering. The two processes business process and the product process

are responsible for the development of computer based systems.

Objectives

In this chapter you will study:-

What is System Engineering?

What is the importance of System Engineering?

What are the steps of System Engineering?

6.2 System Engineering

6.2.1 Computer Based Systems

There are so many types of systems namely political systems, educational

systems, avionics systems, manufacturing systems, banking systems,

subway systems, control systems, traffic systems, quality systems, etc. A



system refers to a systematic style of doing things. The system works

according to the predefined rules and procedure. People working with the

systems have to follow the guidelines of the systems and strictly follow the

procedures in order to smoothly run the system. Only then it is possible to

get good results from the system. Any such system which takes the support

of the electronic computer is a computer based system. According to

Webster's definition, a computer-based system is ‘A set or arrangement of

elements that are organized to accomplish some predefined goal by

processing information’.


1. What do you mean by system?

6.2.2 The System Engineering Hierarchy

Systems engineering can be seen in any software development domain

irrespective of its application. It basically works on the top down approach or

the bottom up approach. These approaches are useful to navigate various

elements of the system. The system engineering process begins with a

‘word view’. To ensure proper business or technology context the entire

business domain is tested and inspected. The product domain also is

inspected. The purpose of the word view is to fully focus on a specific

domain of the business enterprise. Within each domain of the business, the

need for the systems engineering elements is analyzed. The elements that

are focused during the analysis are World view, Domain view, Element view,

Detailed view, Domain of interest, System element, the system engineering,

hierarchy, and design. A detailed description of the entire analysis is

provided. The broad context of the entire analysis is provided at the top of

the document hierarchy and technical details of various technical activities

are provided at the bottom.

System Modeling

System engineering is also a modeling process. The systems engineer

creates the model based on the requirements and the forces acting in the

domain in which the application is to be developed. The various steps in the

modeling that the systems engineer follows are:

1. Process Definition: In this step the system engineer identifies the needs

and specifications pertaining to the applications and clearly defines each



process one by one with appropriate linkages and relationships between

each process.

2. Process Behavior: The systems engineer represents the process

behavior and the related assumptions for each process.

3. Process Input – The systems engineer defines the exogenous and

endogenous input to the model.

4. Process Linkages: the process linkages have to be well established so

that the engineer can understand the relationships better.

System Simulation

Whenever there is a need to develop an application to cater to the real world

problems, a model has to be prepared. The model has to be developed

based on the parameters identified to solve the problem and then to

sensitize the model towards any changes in the external forces that affect

the model. A model is an abstraction of the reality. There are different

computers that interact with the real world in different manner. Real world

events are monitored by automated systems and the programs that control

the activities through hardware and related software. The hardware and the

software together constitutes the computer based systems. Based on the

inputs and the information provided to the systems, the computer based

systems controls the machines and the processes. Lack of knowledge and

experience of the software engineer leads to inefficient performance of the

systems in which they work and also the outputs that are delivered by these

systems. It has been difficult to predict the performance, efficiency, and

behavior of such systems.


1. What do you mean by system stimulation?

2. What do you mean by system modeling?

6.2.3 Requirements Engineering

As discussed in the earlier paragraphs the computer based system is the

outcome of an engineering process and the specification pertaining to the

business domain application. But the main question is whether the

specifications have been stated clearly or not, or is it adequately stated, so

that the system engineer will not have to go through any major amendments

in future. The amendments if any may be restricted to a small proportion.

There is no unique solution to this question. The best thing is to work on a



solid requirements engineering process. Requirements engineering will

provide necessary mechanism to understand what the customer wants and

what the customer needs are. The best way to tackle this is to have a solid

requirements engineering process. The process has to validate the

specification stated and manage other requirements as they are

transformed into a active operational system. The requirements engineering

process can be stated in five steps as follows:

Requirements description

Analysis of requirements

Specification of requirements

Modeling of the system

Validation of the system

Management the various requirements


1. What are the various steps of requirements engineering?

6.3 Summary

Systems engineering deals with software and also other related elements of

the software pertaining to a business. It deals with analysis, design and

organization of the various elements into the business system. Any such

system which takes the support of the electronic computer is a computer

based system. According to Webster's definition, a computer-based system

is ‘A set or arrangement of elements that are organized to accomplish some

predefined goal by processing information’. The system engineering process

begins with the with a ‘ word view’. To ensure proper business or technology

context the entire business domain is tested and inspected. The product

domain also is inspected. The purpose of the word view is to fully focus on a

specific domain of the business enterprise. The systems engineer creates

the model based on the requirements and the forces acting in the domain in

which the application is to be developed. Whenever there is a need to

develop an application to cater to the real world problems, a model has to

be prepared. The model has to be developed based on the parameters

identified to solve the problem and then to sensitize the model towards any

changes in the external forces that affect the model. A model is an

abstraction of the reality.




1. Find as many single-word synonyms for the word system as you can.

Good luck!

2. Build a hierarchical "system of systems" for a system, product, or service

with which you are familiar. Your hierarchy should extend down to

simple system elements (hardware, software, etc.) along at least one

branch of the "tree."

3. Select any large system or product with which you are familiar. Define

the set of domains that describe the world view of the system or product.

Describe the set of elements that make up one or two domains. For one

element, identify the technical components that must be engineered.


1. Which of the following are the steps in system engineering?

(a) Requirements elicitation

(b) Requirements analysis and negotiation

(c) All the above (d) none of these



6.2.1 A set or arrangement of things so related as to form a unity or organic

whole.

6.2.2



6.2.3 Requirements elicitation, Requirements analysis and negotiation,

Requirements specification, System modeling, Requirements

validation, Requirements management






1. c



Unit 7 Analysis Concepts and Principles

Structure:

7.1 Introduction

Objectives

7.2 Analysis Concepts and Principles

Requirements Analysis

Requirements Elicitation for Software

Analysis Principles

Software Prototyping

7.3 Summary




7.1 Introduction

A step towards building a good and a stable software platform for the user

requires the software team of engineers and managers to concentrate on

the processes of discovery, refinement, modeling, and specification. The

system engineer has to establish the system requirements and role

allocated to software in detail. The software engineer has to then create

various models to indicate the need of specific data, information and

controls. The needs are translated into suitable formats represented by the

models. For the purpose of detailed analysis models are created and

alternative solutions are analyzed. Donald Reifer describes the software

requirement engineering process in the following way:

Requirements engineering is the systematic use of proven principles,

techniques, languages, and tools for the cost effective analysis,

documentation, and on-going evolution of user needs, and the specification

of the external behavior of a system to satisfy those user needs. Notice that

like all engineering disciplines, requirements engineering is not conducted in

a sporadic, random or otherwise haphazard fashion, but instead is the

systematic use of proven approaches.

The effectiveness of the operations of the software depends upon the

degree of involvement of the software engineer and customer. The



involvement refers to how much the software engineer and customer take

an active role in software requirements engineering. Software requirements

engineering is a set of activities known as analysis. The role of the software

engineer as a software developer is to act as an interrogator, consultant,

problem solver, and negotiator.

Objectives

In this unit you will study:

What is concept analysis and principle?

What is the work product?

What is the work product of concept analysis and principle?

7.2 Analysis Concepts and Principles

7.2.1 Requirements Analysis

A software is developed based on the requirements stated by the customer.

The requirements stated are sometime not very clear. The interpretation of

the requirements in the initial outlay may change as the interaction between

the developer and the customer goes on and on with respect to the

software. It is very difficult to perfectly predict the customer’s expectation

from the software hence there is always a gap between the software system

level requirements engineering and the software design. A process is

therefore necessary to bridge the gap. Requirements analysis is a software

engineering process which helps in bridging the gap between system level

requirements engineering and software design. It results in the specification

of software’s operational characteristics with respect to function, data, and

behavior. It also acts as an indicator that indicates software's interface with

other system elements and the various constraints within which the software

developed must work.

As a step in requirements analysis, the software engineer refines the

software allocation, and build models of the data, functional, and behavioral

domains. Requirements analysis provides the software designer with a

representation of the following :

i) information,

ii) function, and

iii) behavior



The three representations can be translated to data, architectural, interface,

and component-level designs. Requirements specification is stated. It

provides the developer and the customer with the means to assess quality

of the software. The five areas of software requirements analysis are:

1) problem recognition,

2) evaluation and synthesis,

3) modeling,

4) specification, and

5) review.

The commencement of the software requirements analysis and the

development activity is marked by the studies and reports on the System

Specification and the Software Project Plan. For the software development

team it is important to understand the software in the context of a system.

They should be able to review the software scope that was used to generate

planning estimates. Communication of the analysis details to the customer

is very important. This will lay the foundation to the development of a good

software system for the customers.


1. ____________is a software engineering task that bridges the gap

between system level requirements engineering and software design.

7.2.2 Requirements Elicitation for Software

The requirements have to be analyzed and modeled. The details are

gathered through an elicitation process. The problem a customer has may

be possible to be solved by a computer-based solution technique.

For the communication of the details between the developer and the

customer one has to make it clear by taking necessary steps to ensure that

the communication is proper. Once the communication begins there will be

lots of points which may be not very clear or is misunderstood. A proper

communication process may be established and the following stages in the

process may be followed :

Initiating the Process – This basically involves asking a few general

questions pertaining to the software process, and on the personnel

involved in the process. It can act as an ice-breaker which is very

necessary for a successful completion of a project.



Facilitated Application Specification Techniques – It helps in grouping of

customers and enable people to work together to understand the

problem identified, discuss various techniques to solve the problem, and

the related methodologies.

Quality Function Deployment- it is one of the main steps which enables

the team to understand the customer requirements and translate them

into technical forms.

Use-Cases- Based on the above points it is possible to link the

requirements stated by the customer to situations and scenarios already

faced and bring out the performances to the notice of the customer to

enable him to understand the process in a better way. At this stage the

customer will be in a position to bring about changes to the stated

requirements.


1. What are the different steps in requirement elicitation for software?

7.2.3 Analysis Principles

A large number of analysis models have been developed over the last few

decades of research in the software development area. Analysis problems

and their causes have been identified and developed by the researchers.

Each of the model is unique in its own way to deal with the software

problem. However, the analysis methods are all related by various

operational principles which are as follows:

1. The information domain of a problem should be well represented and

understood.

2. Definition of the functions that the software is to perform.

3. Representation of the behavior of the software.

4. The models used to predict information, function, and behavior must be

partitioned. The analysis process migrates from essential information

towards implementation details.

By applying these principles, the analyst will be able to systematically

approach a problem. A systematic approach consists of four steps –

information domain, modeling, partitioning, essential and implementation

views. Examination of the information domain leads to clear understanding

of the model and its application clearly. The use of appropriate models

characteristics the function and behavior which is then communicated to the



customer. Partitioning can be applied to reduce complexity. Implementation

views of the software are necessary to accommodate the logical constraints

that are imposed by the processing requirements as explained below:

1) The Information Domain

Software applications are a set of processes. Software applications are

collectively called data processing. Software is built to process data, to

transform data from one form to another. It accepts inputs in one form

and processes it or manipulates it to generated information of another

form which is then the output of that process. This is applicable to batch

software for a payroll system or real-time embedded software to control

fuel flow to an automobile engine. A software also processes events. An

event represents some system control and is a boolean data.

2) Modeling

Functional models are created in order to understand the actual entity of

software clearly. A model should be able to take different forms

depending upon the area of application. The model must be capable of

representing the information that software transforms, the functions that

enable the transformation to occur, and the behavior of the system as

the transformation is taking place.

3) Partitioning

Problems are sometimes very large and complex. Such problems are

difficult to understand in the first attempt. To manage such situation

partitions may be made. Problems are broken down in to small parts that

can be easily understood and interfaces could be established between

such small parts. For this reason, we tend to partition (divide) such

problems into parts that can be easily understood and establish

interfaces between the parts. This will lead to overall achievement of

the function. Partitioning decomposes a problem into its constituent

parts. A hierarchical representation of function and the partition

according to the hierarchy will lead to the following -

i) increased visibility of the function vertically in the hierarchy,

ii) decomposing the problem horizontally in the hierarchy, and

iii) increased clarity of the relationships between various functions



4) Essential and Implementation Views

The functional aspect of the software and the information to be

processed forms the essential view of software requirements. Options

can be open in the early stages of the development. The focus of the

development can then be on one or more options which tend to appear

more feasible than the rest. Implementation details to a large extent are

then clear in the minds of the development team.

The implementation view of the software requirements exhibits the real

world attributes of processing functions and the information structures. The

analyst has to recognize the constraints imposed by predefined system

elements. They have to consider the implementation view of function and

information when such a view is appropriate.


1. A/an _______of software requirement presents the functions to be

accomplished and information to be processed without regard to

implementation details.

7.2.4 Software Prototyping

Analysis should be conducted independent of the software engineering

approach. The form of analysis will vary according to the area of analysis..

In some cases, operational analysis principles are applied and a model is

derived. In such situations requirements elicitation is conducted. Various

analysis principles are applied, and a model of the software to be built,

called a prototype, is developed. the construction of a prototype at the

beginning of analysis is desired. The model is the only means through which

requirements can be effectively derived. The model evolves into production

software.

Selecting the Prototyping Approach

Prototyping Methods and Tools


1. What do you mean by software prototyping?

7.2.1 Elements of analysis model

An analysis model consists of data dictionary at the center of three main

segmented diagrams – (i) ERD-entity relationship diagram, (ii) DFD - data

flow diagram and (iii) STD - state transition diagram. The construction of the



three diagrams is based on the inputs from data objects designed on

customer requirements, their controls specified and the necessary

processes.

7.2.2 ERD, Functional and Behavioral modeling and the Control

Specification

ERD indicates relationships between data objects. The attributes of each

such object is described by object description. The DFD provides indication

of transformation of data from one stage to another and the functions

responsible for such transformation. This is essentially based on the

functional modeling and its specifications. Based on the functionality the

relationship and the behavioral aspect of the objects entities are described

and detailed. Description of each function of the DFD is indicated in PSPEC-

process specification. The STD indicates the behavior of the systems to

external changing forces. The description of each is listed out in the Data

dictionary. Necessary controls are then described in order to control the flow

of data at various functional modules and the way it needs to be formatted

for further processing.

Additionally, information on the control features of the system can be stated

in specification known as CSPEC- control specification.


1. The ________ indicates the behavior of the systems to external

changing forces.

2. The _________ provides indication of transformation of data from one

stage to another and the functions responsible for such transformation.

7.3 Summary

The system engineer has to establish the system requirements and role

allocated to software in detail. The software engineer has to then create

various models to indicate the need of specific data, information and

controls. The effectiveness of the operations of the software depends upon

the degree of involvement of the software engineer and customer. The

involvement refers to how much the software engineer and customer take

an active role in software requirements engineering. A software is

developed based on the requirements stated by the customer.

Requirements analysis provides the software designer with a representation



of the information, function, and behavior. The commencement of the

software requirements analysis and the development activity is marked by

the studies and reports on the System Specification and the Software

Project Plan. The requirements have to be analyzed and modeled. The

details are gathered through an elicitation process. The problem a customer

has may be possible to be solved by a computer-based solution technique.

A proper communication process may be established and the following

stages :

Initiating the Process, Facilitated Application Specification Techniques,

Quality Function Deployment, Use-Cases. A systematic approach to

requirement analysis consists of four steps – information domain, modeling,

partitioning, essential and implementation views. Various analysis principles

are applied, and a model of the software to be built, called a prototype, is

developed. the construction of a prototype at the beginning of analysis is

desired.


1. Software requirements analysis is unquestionably the most

communication intensive step in the software process. Why does the

communication path frequently break down?

2. There are frequently severe political repercussions when software

requirements analysis (and/or system analysis) begins. For example,

workers may feel that job security is threatened by a new automated

system. What causes such problems? Can the analysis task be

conducted so that politics is minimized?

3. Discuss your perceptions of the ideal training and background for a

systems analyst?


1. Software Analysis is divided into the following areas.

(a) one (b) three (c) five (d) 6




7.6.1 Answers to Self Assessment Questions

7.2.1 Requirements analysis

7.2.2 Initiating the Process, Facilitated Application Specification

Techniques, Quality Function Deployment, Use-Cases

7.2.3 Essential view


7.2.5 i) STD, ii) DFD






1. c



Unit 8 Design Concepts and Principles

Structure:

8.1 Introduction

Objectives

8.2 Design Concepts and Principles

Software Design and Software Engineering

The Design Process

Design Principles

Design Concepts

Effective Modular Design

Design Heuristics for Effective Modularity

8.3 User Interface Design

The Golden Rules

User Interface Design

8.4 Component-Level Design

Structured Programming

8.5 Summary




8.1 Introduction

The goal of the designer is to produce a model of an entity that will later be

developed. The process by which the design model is developed is

described by Belady There are two major phases to any design process:

diversification and convergence. Diversification is the acquisition of a

repertoire of alternatives, the raw material of design: components,

component solutions, and knowledge, all contained in catalogs, textbooks,

and the mind. During convergence, the designer chooses and combines

appropriate elements from this repertoire to meet the design objectives, as

stated in the requirements document and as agreed to by the customer. The

second phase is the gradual elimination of all but one particular

configuration of components, and thus the creation of the final product.



Objectives

In this chapter you will study:

What is Design concept and principles?

What is the work product?

What is the work product of Design Concept and principles?

8.2 Design Concepts and Principles

8.2.1 Software Design and Software Engineering – Its evolution and

hierarchy

Software design is present at the technical kernel of software engineering.

Software design is applied regardless of the software process model that is

used. After the software requirements are stated and analyzed, software

design is the first of three technical activities – design, code generation, and

test. These three technical activities are required to build and verify the

software. Each activity transforms the information into a form which is a

validated computer software. Each of the elements of the analysis model

provides information necessary to create the four design models required for

a complete design specification. Software requirements which are stated

usually comes with a stream of data, functional, and behavioral models,

which is the basis for design task. The design task produces a data design,

an architectural design, an interface design, and a component design.

The information domain model is transformed by the data design into a

suitable data structure .this data structures is necessary to create the

software. Entity relationship diagram represents the relationships between

entity and the data objects. The data content in the data dictionary provide

the basis for the data design activity. This may happened in conjunction with

the design of software architecture. As each component of the software is

designed, more and more detailed data design occurs. The interface design

describes how the software communicates within itself. It also describe how

the software communicate with systems that interoperate with it, and with

the people who are the end users. An interface signifies the flow of

information and a specific type of behavior.

The component-level design is responsible for the transformation of the

structural elements of the software architecture into a procedural description

of software components. The basis for a component design in the software

is the information that is obtained from the PSPEC, CSPEC, and STD.



During the process of the software design, decision have to be taken at

various stages which is mainly responsible for the overall success of the

software and the convenience with which the software could be maintained.


1. The ___________transforms the information domain model created

during analysis into the data structures that will be required to implement

the software.

2. The _________________ transforms structural elements of the software

architecture into a procedural description of software components.

8.2.2 The Design Process

Software design is type of a repetitive process also referred to as an

iterative process. Through this iterative process the requirements are

translated into a “blueprint” for constructing the software. Initially, the

blueprint represents a holistic view of software. This means that the design

is represented at a high level of abstraction. The highest level of abstraction

can be directly traced to the specific system objective, and more detailed

data, functional, and behavioral requirements. As more and more iterations

takes place the software undergoes refinement in its design leading to

design representations at much lower levels of abstraction. It can still be

traced to the requirements, but the connection is more elusive.

i) Design and Software Quality- It is necessary that the quality of the

design process is maintained and monitored throughout the design

process. The entire design process is broken down into modules,

distinct data structures to present the data and interfaces and

independent functional modules. This will enable easy control of the

software quality.

ii) The Evolution of Software Design- It is a continuous process. Various

technological developments in the design has lead to the evolution of

various improved methodologies in the software design and its

architecture. It is necessary to apply basic principles and concepts to the

pertinent data and interfaces at component level.


1. What is the design process?



8.2.3 Design Principles

Software designing involves both modeling and designing processes. Hence

software design is both a process and a model. All the aspects of the

software design are possible to be represented in the form of a sequence of

steps. The sequenced steps enable the designer to describe and

understand all the aspects for the software module in the design. To

develop a good software it is necessary to have experienced developers in

the software team who are capable of anticipating likely problems under

specific conditions. They will be well conversant with the critical success

factors which are necessary to develop competent software. The design

model that is created for software provides number of views. The software

developer will be able to navigate the entire software process based on the

basic principles of the software design.

Davis suggests a set of principles for software design, which have been

adapted and extended in the following list:

The design process should not suffer from “tunnel vision.” A good

designer should consider alternative approaches, judging each based on

the requirements of the problem, and the resources available to do the

job.

The design should be traceable to the analysis model. Because a

single element of the design model often traces to multiple

requirements, it is necessary to have a means for tracking how

requirements have been satisfied by the design model.

The design should not reinvent the wheel. Systems are constructed

using a set of design patterns, many of which have very likely been

encountered before. These patterns should always be chosen as an

alternative to reinvention. Time is short and resources are limited!

Design time should be invested in representing truly new ideas, and

integrating those patterns that already exist.

The design should “minimize the intellectual distance” [DAV95]

between the software and the problem as it exists in the real world.

That is, the structure of the software design should (whenever possible)

mimic the structure of the problem domain.

The design should exhibit uniformity and integration. A design is

uniform if it appears that one person developed the entire thing. Rules of

style and format should be defined for a design team before design work



begins. A design is integrated if care is taken in defining interfaces

between design components.


1. What are the different Design principles?

8.2.4 Design Concepts

A number of design concepts have evolved over the past few decades.

Each concept is strong in its foundation that enables the designer to work

conveniently on various models both simple and complex. Each of the

concept provides the software engineer with knowledge to answer the

following questions:

What is the criteria that will help in partitioning a software?

How is it possible to separate the function or data structure from a

conceptual representation of the software?

What are the criterions that define the quality of the software design?

Abstraction and Refinement

Abstraction refers to the process of formulating general concepts by

abstracting common properties of instances. Data abstraction refers to a

collection of data that describes a data object taken from a real world

problem. The process of program refinement proposed by Wirth is

analogous to the process of refinement and partitioning that is used during

requirements analysis. The differentiation of the data abstraction is created

at the level of implementation. At different levels of the software design

process, refinement is done. It is actually a process of elaboration.

At the beginning the statement of function is made. The statement is defined

at a high level of abstraction. The statement describes the function and the

information conceptually. It is also very important to hide certain design

details in a software program specially the functions. It is necessary to hide

the design details because some of the functional aspects in the program

would undergo a change during the course of its development based on

changes indicated by the customer. This would also enable the security of

the other parts of the software as each change would be local to the function

in which the change is expected to be incorporated. It provides no

information about the internal workings of the function or the internal

structure of the information. Refinement requires the designer to work on the

elaborate details of the function statement. It provides more and more detail



as each successive refinement occurs. Refinement is very effective if the

following points are considered and are taken into the process of

decomposing and understanding the function problem of the software.

1. Modularity

2. Software Architecture

3. Control Hierarchy

4. Structural Partitioning

5. Data Structure

6. Software Procedure

7. Information Hiding


1. A ________is a named collection of data that describes a data object.

2. What do you mean by refinement?

8.2.5 Effective Modular Design – Cohesion and Coupling

Most of the concepts revolve around the idea of modularity, as mentioned in

earlier sections. Modularity is one of the most accepted idea in most of the

practical areas. The benefit of modularity is derived in the form of simplicity

in solving complex problems, easy approach to maintain the systems, and

permits parallel development and implementation of various other modules

in the system. The modularity induces functionality in the modules. Each

module of the system is independent of the other and the functional

independence can be either of coupling type or cohesion type. Coupling

refers to the degree of interaction between two or more modules in a

system. Cohesion is the term used to describe how well the contents of a

module in the system are bonded together. It is good to have a high degree

of cohesion and low degree of coupling. Cohesion and coupling support the

reuse of a code and easy maintenance. The design aspects of the

modularity focus on maximizing cohesion and minimizing coupling.

A cohesive module is generally meant to perform a single task in a system

with little interactions with other modules in the system. Cohesion can be of

any of the three types : coincidental, logical, communication type. Coupling

can be of the following types :

i) data coupling – used for passing parameters and interaction

with data



ii) control coupling – used for the purposed of sharing related

control data

iii) common coupling – for the purposed of sharing common data

iv) content coupling – for linking one module to another content in

another module.


1. What are the different parts of effective modular design?

8.2.6 Design Heuristics for Effective Modularity

It is possible to achieve effective modularity by careful study of the entire

systems and meticulously planning the modules. Also the design could be

made effective by thoroughly understanding the relationships between

different modules in the system and their interdependencies. The program

structure for modularity can be adjusted according to the following

heuristics:

Meyer defines five criteria to evaluate a design method or the steps in terms

of its ability to define an effective modular system:

i) Modular decomposability: it refers to a mechanism where a problem is

decomposed in to sub problems, as this will help reduce the

complexity in the problems and make the entire big complex problem

in to smaller simpler problems.

ii) Modular composability: it refers to a design methodology that enables

existing components of the design modules to be assembled in to new

ones.

iii) Modular understandability: it refers to the understanding ability of the

developer of the modules as a single standalone modules as this

enables the developer to build the module further and makes it easier

to change the module.

iv) Modular continuity: it refers to the flexibility offered to bring in changes

in the modules without bringing in major changes in the entire system

modules.

v) Modular protection: it refers to the security of the modular content from

getting modified accidentally.

Modules may be exploded to improve module independence once the

program structure has been developed. In the final structure an exploded

module becomes two or more modules. An imploded module is the result of



combining the processes of the modules. The scope of a module is defined

based on the effect of the decision changes on all other modules. If one of

the module makes a decision that affects another module it refers to

violation of this heuristic. The main cause of software errors is the module

interface complexity. Interfaces should be designed to pass information.

Interfaces should be consistent. Unrelated data passed via an argument list

is an indication of low cohesion. The module in question should be

reevaluated.

A module is said to be predictable when it is treated as a black box. This

means the same external data will be produced irrespective of internal

processing details. Modules that have internal "memory" can be

unpredictable. Software is easier to understand and therefore easier to

maintain.


1. What are the Design Heuristics for Effective Modularity?

8.2.1 Design Model Implementation and Documentation: A design model

for the development of software should be stable. The various design issues

are considered based on the requirements specification and each one of the

issue is review at full length and then a evaluation is made. The evaluation

of the design aspects is based on the experience of the team members and

the ability to lay down criteria for such evaluation.

Criteria for each of the module in the software and its modularity is listed

module by module, considering the modules interface and the various object

interface to the module and the corresponding actions that are expected by

the objects on other such modules or objects. It can be made stable by

adopting a suitable model of stability like a pyramid model. The design

model should not get toppled even with the slightest of the changes in the

system or factors external to the system. The designing aspects with

respect to the specifications have to be documented, indicating all relevant

procedures, algorithms, data structures, data tables etc. Appropriate

instruction manuals may be prepared to indicate the usage of the

application.

8.2.2 Architecture and its importance – Architecture refers to the

structure of the system. It consists of various components and their



relationships in the system. The components can be considered as software

program module. It enables one to easily communicate various aspects of

the module under development and the one which is already developed. It

also helps to build successive modules based on the development of the

modules already done by means of proper architectural documents.

8.2.3 Data concepts – Objects pertaining to data are designed from the

ERDs. Data structure has been the main component of the design in the

past. But today the challenges are different which has led to the emergence

of concepts like data mining and data warehouse apart from the

conventional databases. The purpose of data mining is to provide a means

to search through the databases to abstract business information suitable to

a business environment. In a data warehouse, large amount of databases

are stored holding the business information on a day to day basis. Some of

the key aspects of data warehouse are its orientation to the subject of

interest, consistent naming conventions, and non-changing nature of the

data in the database.

8.2.4 Style, Mapping and Flow – software that is developed may exhibit

certain style which is unique to its purpose and application. The style

describes categorically the components and the connectors of the

components. It also describes the limitations and the semantics pertaining to

the overall characteristics of the software. The different styles that exist in

different software architectures have to make to adhere to a uniform

standard style. This can be achieved by means of mapping. For an effective

mapping to be implemented one has to have an effective information flow

from module to another. The data that has to move from one module of a

particular style to another module of a different style will have to flow

through a transforming module which transforms it to the form needed. The

flow in and the flow out to and from the transforming module is controlled in

a sequential manner. Each of the tasks has to follow a defined design step.

8.2.5 Interface Object and Actions-In any design objects which interface

have to be defines and the actions on them have to be clearly stated.

Objects are then classified depending upon their type. The objects may be

of target type, source type or application type. Actions on the stored data

could be sorting, merging etc., followed by screen layout.



8.2.6 Design Issues, Implementation, Evaluation and Notation – The

commonly considered design issues are systems response time, help to the

user, handling of error information and labeling of command. Response time

refers to the time from the point user enter the response till the time system

responds to the user. A design model is implemented as a prototype. The

prototype is checked by users and they are then modified.

A number of interface design and tools of prototyping are used to create

windows, menus, command, messages etc. For implementing the tools

provide support to manage various devices, validation of inputs, error

handling etc. The user then evaluates the interfaces keeping in mind its

usage. User then provides a feedback on the interface either to modify, or to

change, or in the form of few suggestions to change the outlook etc. The

user comments are then reviewed by the designer and takes action to

implement the changes. In the design, various notations are used to

graphically represent a task or an instruction. Sequence is represented by

means of two connected boxes. If – then – else is represented by means of

rhombus, repetition can be indicated by means of closed sequential

connected boxes and rhombus. Another notation is to use the graphical box

design, developed by Nassi and Shneiderman and extended by Chapin also

know as N-S charts or Chapin charts. Another notation is to use a decision

table to indicate multiple conditions and multiple actions based on

conditions. The table consists of four parts – list of conditions, list of actions,

condition combinations and action on conditions. Another form is a PDL-

program design language also known as pseudo-code. It uses the simple

language for indicating the steps with some parts written in the syntax of the

language of programming. A PDL should include subroutine definitions,

description of all interfaces, data definition, structures etc.

8.3 User Interface Design

8.3.1 The Golden Rules

Theo Mandel states three “golden rules”:

1. Place the user in control.

2. Reduce the user’s memory load.

3. Make the interface consistent.

These golden rules form the basis for a set of user interface design

principles that guide this important software design activity.




1. What are the different golden rules?

8.3.2 User Interface Design

Different Models of system function are created to design a user interface.

The human and computer oriented tasks are then delineated; design issues

pertaining to the interfaces are considered; prototyping tools are used and

ultimately implement the design model. The results are then evaluated for

the purpose of quality.


1. What is the first step of user interface design?

8.4 Component-Level Design

8.4.1 Structured Programming and PDL

Various concepts towards component level designs were developed in the

early 1960s and during late 1960s, Dijkstra and others proposed

constrained logical constructs from which any type of logical program could

be developed. These constructs mainly focused on functional domain. The

constructs are used as descriptions for writing down the detailed design

method and the related documentation needed. The methods for designing

and documentation as acceptable in any standards is written down to

explain the details of the software under consideration. It may also contain

certain pseudo-codes indicating the closeness of the programming language

to the documented procedure which is known as PDL or the program design

language.

Example :

Drawing a line:

Select a tool to draw the line. Indicate the start point on the screen. Start

point could be selected based on the coordinate of the pixels on the screen

where a line is to be drawn. Use command “LINE”. Select point using a

mouse or enter co-ordinate in the text command box available in the tool

box. Select another point to which the line is required to be connected to.

Call the two points “From Point” and “To Point”.



The constructs are mainly sequence, condition, and repetition. Sequence

refers to algorithmic approach presenting the processing steps in sume

order.

Condition provides the facility for selected processing. Repetition allows for

looping.

These three constructs are the core fundamentals of structured

programming. Structured constructs limits the procedural design of software

to a small number of predictable operations. The use of a limited number of

logical constructs leads to understanding of the processes. Various

notations :

Graphical Design Notation

Tabular Design Notation

Program Design Language


1. What are the different structured programming languages?

8.5 Summary

Software design is present at the technical kernel of software engineering.

Software design is applied regardless of the software process model that is

used. After the software requirements are stated and analyzed, software

design is the first of three technical activities – design, code generation, and

test. The information domain model is transformed by the data design into a

suitable data structure .this data structures is necessary to create the

software. Entity relationship diagram represents the relationships between

entity and the data objects.

The component-level design is responsible for the transformation of the

structural elements of the software architecture into a procedural description

of software components. Software design is type of a repetitive process also

referred to as an iterative process. Through this iterative process the

requirements are translated into a “blueprint” for constructing the software. It

is necessary that the quality of the design process is maintained and

monitored throughout the design process. Software designing involves both

modeling and designing processes. Hence software design is both a

process and a model. All the aspects of the software design are possible to

be represented in the form of a sequence of steps. Abstraction refers to the



process of formulating general concepts by abstracting common properties

of instances. Data abstraction refers to a collection of data that describes a

data object taken from a real world problem. Component-level design

depicts the software at a level of abstraction that is very close to the code.

At the component level, the software engineer must represent data

structures, interfaces, and algorithms in sufficient detail to guide in the

generation of programming language source code. Intent of structured

programming is to assist the designer in defining algorithms that are less

complex and therefore easier to read, test, and maintain. The benefit of

modularity is derived in the form of simplicity in solving complex problems,

easy approach to maintain the systems, and permits parallel development

and implementation of various other modules in the system. Modules may

be exploded to improve module independence once the program structure

has been developed.


1. Develop two additional design principles that “place the user in control.”

2. All modern programming languages implement the structured

programming constructs. Provide examples from three programming

languages.


1. Which of the following is the structured programming language

a) Graphical Design Notation

b) PDL

c) All the above

d) None of these



8.2.1 1. Data design, 2. Component-level design

8.2.2 Design and software Quality, The Evolution of software Design


8.2.4 Data abstraction , refer section 8.2.4

8.2.5 Functional dependency, Cohesion, Coupling





8.3.2 The creation of different models of system function

8.4.1 Graphical Design Notation, Tabular Design Notation, Program

Design Language


Refer to section 8.3.2



1. b



Unit 9 Software Testing Techniques and

Technical Metrics Structure:

9.1 Introduction

Objectives

9.2 Software Testing Techniques

Software Testing Fundamentals

White-Box Testing

Basis Path Testing

Controlling Structure Testing

Black-Box Testing

Testing for Specialized Environments, Architectures, and Applications

9.3 Introduction to Technical Metrics

9.4 Technical Metrics for Software

Software Quality

A Framework for Technical Software Metrics

Metrics for the Analysis Model

Metrics for the Design Model

Metrics for Source Code

9.5 Summary




9.1 Introduction

Software testing and its implications with respect to software quality should

be well understood. The development of software systems involves a series

of production activities. Every process is prone to errors. The software

development should be subject to quality assurance process. Software

testing represents the ultimate review of specification, design, and code

generation. The visibility of software system and the costs associated with a

software failure are the main forces for software testing.



Objectives

In this chapter we will study:

o What is testing?

o What are the different testing techniques?

o Where and how to use this testing techniques?

9.2 Software Testing Techniques

9.2.1 Software Testing Fundamentals and Comparison

During the process of software development the software development team

goes through the stages of the development based on the principles of the

developmental models and the requirements stated. The engineer attempts

to build software from an abstract concept to what is known as tangible

product. To check upon the development testing is done. Testing is one step

in the software process that could be viewed psychologically as a

destructive process rather than constructive process though there is no such

damage done to the system as may be perceived in the general sense.

i) Testing Objectives

Glen Myers states a number of rules that can serve well as testing

objectives:

1. Testing is a process of executing a program with the intent of finding an

error.

2. A good test case is one that has a high probability of finding an as return

discovered error.

3. A successful test is one that uncovers an as-yet-undiscovered error.

ii) Testing Principles

Davis suggests a set of testing principles that have been adapted in this

book:

All tests should be traceable to customer requirements: As we have

seen, the objective of software testing is to uncover errors. It follows that

the most severe defects (from the customer’s point of view) are those

that cause the program to fail to meet its requirements.

Tests should be planned long before testing begins: Test planning

can begin as soon as the requirements model is complete. Detailed

definition of test cases can begin as soon as the design model has been



solidified. Therefore, all tests can be planned and designed before any

code has been generated.

The Pareto principle applies to software testing: Stated simply, the

Pareto principle implies that 80 percent of all errors uncovered during

testing will most likely be traceable to 20 percent of all program

components. The problem, of course, is to isolate these suspect

components and to thoroughly test them.

Testing should begin “in the small” and progress toward testing

“in the large”: The first tests planned and executed generally focus on

individual components. As testing progresses, focus shifts in an attempt

to find errors in integrated clusters of components and ultimately in the

entire system.

Exhaustive testing is not possible: The number of path permutations

for even a moderately sized program is exceptionally large. For this

reason, it is impossible to execute every combination of paths during

testing. It is possible, however, to adequately cover program logic and to

ensure that all conditions in the component-level design have been

exercised.

To be most effective, testing should be conducted by an

independent third party- By most effective, we mean testing that has

the highest probability of finding errors (the primary objective of testing).

For reasons that have been introduced earlier in this unit, the software

engineer who created the system is not the best person to conduct all

tests for the software.

iii) Testability

James Bach describes testability in the following manner. Software

testability is simply how easily [a computer program] can be tested. Since

testing is so profoundly difficult, it pays to know what can be done to

streamline it. Sometimes programmers are willing to do things that will help

the testing process and a checklist of possible design points, features, etc.,

can be useful in negotiating with them. There are certainly metrics that could

be used to measure testability in most of its aspects. Sometimes, testability

is used to mean how adequately a particular set of tests will cover the

product. It's also used by the military to mean how easily a tool can be

checked and repaired in the field. Those two meanings are not the same as

software testability.




1. What are the different testing objectives?

2. What are the different testing principles?

9.2.2 Test Case Design

The tests for software have to be designed depending upon the nature of

the system and the working of the processes. Designing of the test model

can be as challenging as the initial design of the product itself.

Testing can be done in two ways:

1) Knowing the specified function that a product has been designed to

perform.

2) Knowing the internal workings of a product.


1. _______testing of software is predicated on close examination of

procedural details.

2. A ________test examines some fundamental aspect of a system with

little regard for the internal logical structure of the software.

9.2.3 White-Box Testing

White-box testing is also known as glass-box testing. It uses the control

structure of the procedural design to derive test cases. Using white-box

testing methods, the software engineer can derive a number of test cases.

The test case checking for (1) all independent module paths have been

exercised at least once, (2) check all logical decisions for being true or false,

(3) execute all loops within their operational bounds, and (4) exercise

validity of internal data structures.


1. White box testing is also known as ______________

2. What is white box testing?

9.2.4 Basis Path Testing

Basis path testing is the same as white-box testing. The technique first

proposed by Tom McCabe. It enables the test case designer to derive a

logical complexity measure of a procedural design. It uses this measure as

a guide to define the basis set of execution paths. Test cases execute every

statement in the program at least one time during testing.



i) Flow Graph Notation

The flow graph depicts the logical flow of the control. Each structured

construct has a corresponding flow graph symbol.

ii) Cyclomatic Complexity

Cyclomatic complexity is software metric that provides a quantitative

measure of the logical complexity of a program. In basis path testing, the

value computed for cyclomatic complexity defines the number of

independent paths in the basis set of a program and provides with an upper

bound for the number of tests. An independent path is any path through the

program. Independent path introduces at least one new set of processing

statements.

iii) Deriving Test Cases

The basis path testing method is generally applied to a procedural design or

to source code. The following steps can be applied to derive the basis set:

1. Draw flow graph: Flow graph is created using the symbols and

construction rules which are based on the design foundation.

2. Determination of cyclomatic complexity : The cyclomatic complexity,

V(G) can be determined without developing a flow graph by counting all

conditional statements in the PDL (Program design language).

iv) Graph based testing – Graph Matrices

A graph matrix is a data structure and is considered as a software tool that

assists in basis path testing. A graph matrix is a square matrix. The size of

the square matrix is equal to the number of nodes on the flow graph. Each

row and column pertains to a node. The entries in the matrix correspond to

the connections between nodes and the associated link weight. In its

simplest form, the link weight is 1 (a connection exists) or 0 (a connection

does not exist). Link weights can be used to indicate :

The probability of execution of the link.

The processing time to traverse the link.

The memory required during link traversal.

The resources required to traverse the link.




1. A ________is a square matrix whose size (i.e., number of rows and

columns) is equal to the number of nodes on the flow graph.

2. An ____________is any path through the program that introduces at

least one new set of processing statements or a new condition.

9.2.5 Controlling Structure Testing

Although basis path testing is simple and highly effective, there arises a

number of other variations on control structure that broaden the testing

coverage and improve quality of white-box testing.

i) Condition Testing

Condition testing refers to a test case design method that exercises the

logical conditions contained in a program module.

ii) Data Flow Testing

The data flow testing method selects test paths for testing based on the

locations of definitions and uses of variables in the program.

iii) Loop Testing

Loop testing is a white-box testing technique focusing mainly on the validity

of loop constructs. Four different classes of loops that could be tested are:

simple loops, concatenated loops, nested loops, and unstructured loops.


1. ___________is a test case design method that exercises the logical

conditions contained in a program module.

2. The ____________method selects test paths of a program according to

the locations of definitions and uses of variables in the program.

9.2.6 Black-Box Testing

Black-box testing is also known as behavioral testing. It focuses on the

functional requirements of the software. Black-box testing helps to derive

sets of input conditions to handle and test all functional requirements for a

program. Black-box testing is complementary to white-box techniques to

uncover different class of errors. Black-box testing finds errors in the

following categories:

1) Incorrect functions,

2) Errors in the Interface

3) Data structure errors



4) Performance errors

5) Errors due to initialization and termination.

Graph-Based Testing Methods – This is the starting point of software

testing. A graph is created for important objects along with t heir

relationships with each other. A series of tests are conducted on the

objects and the errors are identified. This is then rectified.

Equivalence Partitioning – this divides the input of program into classes

of data from which tests are devised. It helps in uncovering the errors.

Boundary Value Analysis – this is used to identify errors which occurs on

the periphery of the classes and not at the centre of the object.

Comparison Testing – Real time comparison is done with respect to

items to be tested through new version software. The same old data is

put through the new software to check whether it produces identical

results or not?

Orthogonal Array Testing- It is applicable to testing of software where

the input set is very small. It is useful to find errors which are connected

with the faulty logics of the software.


1. Black box testing is also known as ________________

2. What are the different black boxes tests?

9.2.7 Testing for Specialized Environments, Architectures, and

Applications

The white-box and black-box testing methods discussed are applicable

across all environments, architectures, and applications. Testing guidelines

for specialized environments, architectures, and applications that are

commonly encountered by software engineers are :

Testing GUIs – Complexities of GUI increases depending upon its utility

and usage. To address the issues related to specific data and objects, finite

state graphs may be used. Testing is done with automated tools.

Testing of Client/Server Architectures – This environment is distributed

hence on different machines the performance issues are different. These

issues are more complicated to deal with than on standalone machines. It

requires more time and is a costly process.



Similar is the case in testing under the following categories:

i) Testing Documentation and Help Facilities

ii) Testing for Real-Time Systems

Challenges of Technical Metrics: It is always a challenge to the

researches to develop a model of testing, one which will be comprehensive

covering all the aspects of testing software. In the process various

complexities have been dealt with for measurements. These measurements

on the program attributes like modularity, independence etc can be used as

indicators of quality.

Attributes of Effectives software metrics:

The various attributes which may be considered in testing software

effectively are –

i) Simplicity in understanding the metric

ii) Satisfaction about the various attributes should be experienced

iii) Metric should be yielding results

iv) The metric should have uniform and consistent used of dimensions

v) Metrics should be program independent

vi) Metric should be capable of providing quality information for further

developments.

Interface Design Metrics: There is shortage of metrics which could be

used for providing insight into the quality and usability of the interface.

Different methodologies have been used in such measurements. The

methods have been based on the appropriateness of the application and the

interface.

Metrics for Testing and Maintenance: Most of the metrics are developed

on the process of testing and not on the technicalities of the tests. The tests

rely mainly on the design characteristics and the analysis characteristics of

the software. Metrics which are function based are also found to be

effective. These metrics enable to measure the effort of testing, time

required to test and errors of testing if found.

Almost every metrics can be used to measure the maintenance aspects of a

software. IEEE has suggested SMI-Software maturity index that indicates

the stability of the product software. Based on the mean time required to



produce software, empirical models can be considered for maintenance

models.


What do you mean by testing GUI?

9.3 Introduction to Technical Metrics

Measurement is the key element of any engineering process.

Measurements are used to understand the attributes of the models.

Measurements are used to assess the quality of the engineered products.

Fenton states that measurement is the process by which numbers or

symbols are assigned to the attributes of entities in the real world in such a

way as to define them according to clearly defined rules.

9.4 Technical Metrics for Software

9.4.1 Software Quality

The following three points are emphasized while defining a software quality:

1. The foundation from which the quality is measured the software

requirements. Lack of quality is nothing but the lack of conformance to

requirements.

2. Specified standards guide the manner in which software is engineered.

3. If software conforms to its explicit requirements but if it fails to meet

implicit requirements, software quality is doubtful. Software quality is a

complex mix of factors that will vary across different applications and the

customers who request them.

i) McCall’s Quality Factors

The software quality factors can be categorized in two groups:

1) Directly measurable factors

2) Indirectly measurable factors.

McCall, Richards, and Walters propose a useful categorization of factors

that affect software quality. These software quality factors focus on three

important aspects of a software product: operational characteristics, ability

to undergo change, and adaptability to new environments.

McCall and his colleagues provide the following descriptions:



Correctness: The extent to which a program satisfies its specification and

fulfills the customer's mission objectives.

Reliability: The extent to which a program can be expected to perform its

intended function with required precision. [It should be noted that other,

more complete definitions of reliability have been proposed.

Efficiency: The amount of computing resources and code required by a

program to perform its function.

Integrity: Extent to which access to software or data by unauthorized

persons can be controlled.

Usability: Effort required to learn, operate, prepare input, and interpret

output of a program.

Maintainability: Effort required to locate and fix an error in a program. [This

is a very limited definition.]

Flexibility: Effort required to modify an operational program.

Testability: Effort required to test a program to ensure that it performs its

intended function.

Portability: Effort required to transfer the program from one hardware and/or

software system environment to another.

Reusability: Extent to which a program [or parts of a program] can be

reused in other applications – related to the packaging and scope of the

functions that the program performs.

Interoperability: Effort required to couple one system to another.

ii) FURPS

Hewlett-Packard developed a set of software quality factors that has been

given the acronym FURPS – Quality Factors functionality, usability,

reliability, performance, and supportability. The FURPS quality factors

define the following attributes for each of the five major factors:

Functionality is assessed by evaluating the feature set and capabilities

of the program, the generality of the functions that are delivered, and the

security of the overall system.

Usability is assessed by considering human factors, overall aesthetics,

consistency, and documentation.



Reliability is evaluated by measuring the frequency and severity of

failure, the accuracy of output results, the mean-time-to-failure (MTTF),

the ability to recover from failure, and the predictability of the program.

Performance is measured by processing speed, response time,

resource consumption, throughput, and efficiency.

iii) ISO 9126 Quality Factors

The ISO 9126 standard was developed in to identify quality attributes for

computer software. There are six key quality attributes which are as follows:

Functionality: The degree to which the software satisfies the requirements

against the attributes: suitability, accuracy, interoperability, compliance, and

security.

Reliability: Based on sub-attributes: maturity, fault tolerance, recoverability,

it is the time of availability of the software.

Usability: The degree to which the software is easy to use indicated by the

understandability, learn ability, operability of the software.

Efficiency: The degree to which the software makes optimal use of system

resources as indicated by time and resource behavior.

Maintainability: It refers to the ease with which repair may be made to the

software indicated by sub-attributes : analyzability, changeability, stability,

testability.

Portability: The ease with which the software can be transposed from one

environment to another indicated by adaptability, install ability,

conformance, and replace ability.

iv) The Transition to a Quantitative View

According to Cavano and McCall there is no such thing as absolute

knowledge, one should not expect to measure software quality exactly, for

every measurement is partially imperfect. The metrics represent indirect

measures. The complicating factor refers to the precise relationship

between the variable that is measured and the quality of the software.


1. __________ is the degree to which the software makes optimal use of

system resources as indicated by the following sub-attributes: time

behavior, resource behavior.



2. ____________is the amount of time that the software is available for

use as indicated by the following sub-attributes: maturity, fault tolerance,

recoverability.

9.4.2 A Framework for Technical Software Metrics

A framework for the technical software metrics is established based on the

principles of technical metrics for software. The framework may be well

understood under the following points:

1) The Challenge of Technical Metrics

Over the past three decades, many researchers have attempted to develop

a single metric that provides a comprehensive measure of software

complexity. Complexity takes a somewhat different view of what is expected

from quality metrics. Consider a metric for evaluating an attractive

motorcycle. Some emphasize body design, others might consider

mechanical characteristics, or performance, or fuel economy, or the ability to

recycle when the motorcycle is scrapped. It is very difficult to obtain a single

value for “attractiveness.” A similar problem is seen with the computer

software.

2) Measurement Principles

Technical metrics assist in the evaluation of the analysis and design models.

It provides an indication of the complexity of procedural designs and source

code, and facilitates the design of more effective testing, it is important to

understand basic measurement principles. Roche suggests a measurement

process that can be characterized by five activities:

Formulation. The derivation of software measures and metrics that is

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 results in an effort to gain

insight into the quality of the representation.

Feedback. Recommendations derived from the interpretation of

technical metrics transmitted to the software team.




1. __________is the computation of metrics and the application of

mathematical tools.

2. _____________is the mechanism used to accumulate data required to

derive the formulated metrics.

9.4.3 Metrics for the Analysis Model

Analysis model is the starting point of all technical work in software

engineering. At this stage, requirements are derived and a foundation for

design is established. Therefore, technical metrics that provide insight into

the quality aspect of the analysis model are desirable. It is possible to adapt

metrics for use in this context. There is a possibility of the two size and

design complexity being correlated directly.

i) Function-Based Metrics

The function point metric is used for predicting the size of a system. The

function can manage the interactions between users, accept user password,

to activate or deactivate systems, and allows inquiries on various security

sensors.

The function displays messages and sends control signals to various

components of the security system. The data flow diagram is evaluated to

determine the key measures of the function point metric on the following

point : number of user inputs, outputs, inquiries, files and external interfaces.

ii) Metrics for Specification Quality

Davis and his colleagues propose a list of characteristics useful 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. These characteristics

are qualitative in nature; Davis et al. suggest that each can be represented

using one or more metrics.


1. ___________is the number of user observable states in the state

transition.

2. _____________is the number of state transitions in the state transition.



9.4.4 Metrics for the Design Model

The design of complex software systems does not have any measurement

to start with. The design metrics for software are available, but most of the

software engineers are unaware of the metrics. Design metrics for computer

software are not perfect. There is always a scope for debating on this issue.

Design without measurement is an unacceptable alternative. Some of the

common design metrics to be considered are:

1) Architectural Design Metrics

Architectural design metrics focus on architectural characteristics of the

software and the effectiveness of modules. These metrics do not require

any knowledge of the inner workings of a particular software component.

2) Component-Level Design Metrics

Component level design metrics focus on internal characteristics like

module cohesion, coupling, and complexity. These measures can help a

software engineer to judge the quality of design. Suitable metrics may

be applied once a procedural design has been developed.


1. __________assigns quantitative laws to the development of computer

software, using a set of primitive measures that may be derived after

code is generated or estimated once design is complete.

9.5 Summary

The primary objective for test case design is to derive a set of tests that

have the highest likelihood for uncovering errors in the software. The

development of software systems involves a series of production activities.

Every process is prone to errors. The software development should be

subject to quality assurance process. During the process of software

development the software development team goes through the stages of the

development based on the principles of the developmental models and the

requirements stated. Davis suggests that All tests should be traceable to

customer requirements, Tests should be planned long before testing begins,

The Pareto principle applies to software testing, Testing should begin “in the

small” and progress toward testing “in the large”, Exhaustive testing is not

possible.



To be most effective, testing should be conducted by an independent third

party. The tests for software have to be designed depending upon the

nature of the system and the working of the processes. Designing of the

test model can be as challenging as the initial design of the product itself.

White-box testing is also known as glass-box testing.

It uses the control structure of the procedural design to derive test cases.

Using white-box testing methods, the software engineer can derive a

number of test cases. Basis path testing is the same as white-box testing.

The technique first proposed by Tom McCabe. The flow graph depicts the

logical flow of the control. Each structured construct has a corresponding

flow graph symbol. Cyclomatic complexity is a software metric that provides

a quantitative measure of the logical complexity of a program. In basis path

testing, the value computed for cyclomatic complexity defines the number of

independent paths in the basis set of a program and provides with an upper

bound for the number of tests. The basis path testing method is generally

applied to a procedural design or to source code. Black-box testing is also

known as behavioral testing. It focuses on the functional requirements of the

software.

Black-box testing helps to derive sets of input conditions to handle and test

all functional requirements for a program. Measurement is the key element

of any engineering process. Measurements are used to understand the

attributes of the models. Measurements are used to assess the quality of

the engineered products. Software quality may be defined as conformance

to explicitly state functional and performance requirements. It may also be

conformance to explicitly documented development standards, and implicit

characteristics that are expected of all professionally developed software. A

framework for the technical software metrics is established based on the

principles of technical metrics for software.

Analysis model is the starting point of all technical work in software

engineering. At this stage, requirements are derived and a foundation for

design is established. The function point metric is used for predicting the

size of a system. The function can manage the interactions between users,

accept user password, to activate or deactivate systems, and allows

inquiries on various security sensors.




1. What do you mean by Basic Path Testing?

2. What are the differences between black box and white box testing?

3. Write a detailed note on Technical Metrics for Software.


1. Which of the following is a Basic path Testing?

(a) Flow graph (b) Graph metrics (c) all the above (d) none of these.

2. Which of the following are ISO 9126 Quality Factors?

(a) Reliability (b) Usability (c) both a & b (d) none of these




9.2.2 1. White-box, 2. black-box

9.2.3 1. Glass box Testing, 2. Refer to section 9.2.3

9.2.4 1. Graph matrix, 2. Independent path

9.2.5 1. Condition testing, 2. Data flow testing

9.2.6 1. Behavioral testing, 2. Refer to section

9.2.7 Refer text 9.2.7

9.4.1 1. Efficiency 2. Reliability

9.4.2 1. Analysis 2. Collection

9.4.3 1. State 2. Transition

9.4.4 1. Software Science




Refer to section 9.4


1. c

2. c



Unit 10 Object-Oriented Concepts and

Principles Structure:

10.1 Introduction

Objectives

10.2 Object-Oriented Concepts and Principles

Object Oriented Concept

Identifying the Elements of an Object Model

Management of Object-Oriented Software Projects

10.3 Object-Oriented Analysis

Object Oriented Analysis

Domain Analysis

Generic Components of the OO Analysis Model

The OOA Process

The Object-Behavior Model

Identification of Events with Use Cases

Representation of State

10.4 Summary




10.1 Introduction

A real world feature can be represented as an object. The details of the real

world feature are abstracted into objects. Objects can be categorized,

described, organized, combined, manipulated, and created. An abstraction

enables us to model the world. An object-oriented development was

proposed first during the 1960s. One can derive a number of benefits from

the object technologies. Both the management and technical level people

have benefited from object techniques in dealing with real world business

problems.

Object-oriented techniques provide a number of strategies in software

based on practical methodologies. Most of the object techniques have been

implemented and tested. The techniques are proven. The strategies are



designed to deal with complex natural and man-made system. The

strategies are very fundamental.

Objectives

In this Chapter you will learn:

What is Object Oriented Concept?

What is Object Oriented Analysis?

What are Object Oriented Techniques?

10.2 Object-Oriented Concepts and Principles

10.2.1 Object Oriented Concept

Object oriented approach can be understood well if the knowledge of the

real world entity is clear. A simple approach has to be considered to analyze

any object. Consider an example of a car. A car is an automobile. Car

belongs to the category of automobiles. Therefore we can say that car is an

instance of automobile. Car is treated as an object and automobile is treated

as a class. Every class of objects will have certain attributes and functions.

In case of the automobile, an automobile has engine, fuel system, ignition

system, exhaust system, wheels, seat for driver etc. These attributes can be

seen in any object belonging to the class of automobiles. Ex. A car, a bus, a

truck etc. The objects are said to inherit all the properties of the class to

which it belongs to.

i) Classes and Objects

Object oriented approach and concepts used in object oriented technology

lead to effective modularity. A class encapsulates the data and procedural

abstractions required to describe the content and behavior of a real world

entity. The data abstractions are also referred to as attributes. The attributes

are controlled and manipulated by abstraction procedures known as

operations or methods. These methods are also referred to as services.

There is only way to access and operate the attribute of any object and that

is through one of the operations. A class encapsulated both data and the

processing function on the data. It is known as encapsulation. Classes can

of two main types : super-class and subclass.

A super-class refers to a collection of classes, and a subclass is referred to

as a specialized instance of a class.



ii) Attributes

Real world entities have features such as shape, weight, color, and type of

material. These are abstracted as attributes of the object representing the

real world problem. A person is considered to have attributes like date of

birth, parents, name, and eye color. A domain is simply a set of specific

values. For example, assume that a class named automobile has an

attribute say - color. The domain for color could be {white, black, silver,

gray, blue, red, yellow, green}. Under some situations, the domain can be a

set of classes. The domain values can be supported with a default value for

an attribute.

iii) Messages

Messages are the means by which objects communicate with each other.

The message triggers some behavior to occur in the object that receives the

message. The behavior is seen when an operation is executed.

iv) Encapsulation, Inheritance, and Polymorphism

Encapsulation refers to the data and the methods on the data which are

held together in a class by means of specifications stated for the class.

Inheritance refers to the condition of acquiring all the properties by an object

from the class to which it belongs to and also from the class which is

superior to its parent class. Polymorphism refers to the behavior of the

object and its ability to behave in more than one form depending upon the

method specification.

This provides a number of benefits:

The internal implementation details of data and procedures are hidden

from the outside world.

Data structures and the operations that manipulate them are merged in

a single class. This enables it to be reused.

An object that sends a message is controlled based on the specification

of the internal data structure.


1. ________ are the means by which objects interact.

2. What is a class?



10.2.2 Identifying the Elements of an Object Model

The main elements of an object model are the classes and objects,

attributes, operations, and messages. To identify the various elements from

a given problem or a case one should concentrate to determine the

following:

Identifying the nouns in the case problem

Specifying Attributes

Defining Operations

Finalizing the Object Definition

Identifying the actions verbs in the problem


1. What are the elements of an object model?

10.2.3 Management of Object-Oriented Software Projects

Modern software project management can be divided as :

1. Establish a common process framework .

2. Use framework to develop effort and time estimates.

3. Establish deliverables and milestones to enable measurement of

progress.

4. Define checkpoints for risk management, quality assurance, and control.

5. Manage the changes.

6. Tracking, monitoring, and controlling the progress.

The technical manager who is faced with an object-oriented project applies

these six activities.

i) The Common Process Framework (CPF)

It defines an organization’s approach to software engineering. It identifies

the paradigm that is applied to build and maintain software. It establishes

the degree of rigor necessary to approach different kinds of projects. The

CPF can meet the individual needs of a project team.

ii) Project Metrics and Estimation

Conventional software project estimation techniques require the estimates

of lines-of code (LOC). It may also require function points (FP) for

estimation. FP estimates is effective because the information domain counts

that are required are readily obtainable from the problem statement. FP

analysis provides value for estimating Object Oriented projects. The FP

measure does not provide enough granularities for the schedule and effort.



According to Lorenz and Kidd, the following points on project metrics may

be followed:

Number of scenario scripts. A scenario script is a detailed sequence of

steps that describe the interaction between the user and the application.

Each script is organized into triplets of the form {initiator, action,

participant} where initiator is the object that requests some service (that

initiates a message); action is the result of the request; and participant is

the server object that satisfies the request. The number of scenario scripts is

directly correlated to the size of the application and to the number of test

cases that must be developed to exercise the system once it is constructed.

Number of key classes. Key classes are the “highly independent

components” that are defined early in OOA. Because key classes are

central to the problem domain, the number of such classes is an indication

of the amount of effort required to develop the software and also an

indication of the potential amount of reuse to be applied during system

development.

Number of support classes. Support classes are required to implement

the system but are not immediately related to the problem domain.

Examples might be GUI classes, database access and manipulation

classes, and computation classes. In addition, support classes can be

developed for each of the key classes. Support classes are defined

iteratively throughout the recursive/ parallel process. The number of support

classes is an indication of the amount of effort required to develop the

software and also an indication of the potential amount of reuse to be

applied during system development.

Average number of support classes per key class. In general, key

classes are known early in the project. Support classes are defined

throughout. If the average number of support classes per key class were

known for a given problem domain, estimating would be much simplified.

Lorenz and Kidd suggest that applications with a GUI have between two and

three times the number of support classes as key classes. Non-GUI

applications have between one and two times the number of support

classes as key classes.

Number of subsystems: A subsystem is an aggregation of classes that

supports a function that is visible to the end-user of a system. Once



subsystems are identified, it is easier to lay out a reasonable schedule in

which work on subsystems is partitioned among project staff.

iii) An OO Estimating and Scheduling Approach

Software project estimation remains more of an art than a science.

However, this in no way precludes the use of a systematic approach. To

develop reasonable estimates it is essential to develop multiple data points.

That is, estimates should be derived using a number of different techniques.

Effort and duration estimates used for conventional software development

are applicable to the OO world, but the historical database for OO projects is

relatively small for many organizations. Therefore, it is worthwhile to

supplement conventional software cost estimation with an approach that has

been designed explicitly for OO software. Lorenz and Kidd suggest the

following approach:

1. Develop estimates using effort decomposition, FP analysis, and any

other method that is applicable for conventional applications.

2. Using OOA, develop scenario scripts (use-cases) and determine a

count. Recognize that the number of scenario scripts may change as the

project progresses.

3. Using OOA, determine the number of key classes.

4. Categorize the type of interface for the application and develop a

multiplier for support classes.

iv) Tracking Progress for an OO Project

Although the recursive/parallel process model is the best framework for an

OO project, task parallelism makes project tracking difficult. The project

manager can 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.


1. What are the different activities of modern software management?

10.3 Object-Oriented Analysis

10.3.1 Object Oriented Analysis

The main objective of object-oriented analysis is to develop a model that

describes computer software. The model should work to satisfy a set of



customer-defined requirements. The model used for the purpose of

analysis depicts information, function, and behavior within the context.

i) Conventional vs. OO Approaches

Fichman and Kemerer address the question head-on: a unified modeling

language (or some other method). What is the work product? An object-

oriented analysis model is created. The OO analysis model is composed of

graphical or language-based representations. These representations define

class attributes, relationships, and behaviors, as well as interclass

communication and a depiction of class behavior over time. At each stage,

the elements of the object-oriented analysis model are reviewed. The review

is done with respect to clarity, correctness, completeness, and consistency

with customer requirements.

Fichman and Kemerer suggest “modeling dimensions” that may be used to

compare various conventional and object-oriented analysis methods:

1. Identification/classification of entities

2. General-to-specific and whole-to-part entity relationships

3. Other entity relationships

4. Description of attributes of entities

5. Large-scale model partitioning

6. States and transitions between states

7. Detailed specification for functions

8. Top-down decomposition

9. End-to-end processing sequences

10. Identification of exclusive services

11. Entity communication

ii) The OOA Landscape

The OOA approach lead to development of number of concepts in object

technologies during the late 1980s and into the 1990s. Each of these

introduced a process for the analysis of a product. A number of process

diagrams were developed during the analysis stage. The diagrams drawn

were based on the standards accepted universally and hence the notations

used enabled the software engineer to create the analysis model in a

consistent manner. Among the most widely used were:

The Booch method. The Booch method encompasses both a “micro

development process” and a “macro development process.” The micro level



defines a set of analysis tasks that are reapplied for each step in the macro

process. Hence, an evolutionary approach is maintained. Booch’s OOA

micro development process identifies classes and objects and the

semantics of classes and objects and defines relationships among classes

and objects and conducts a series of refinements to elaborate the analysis

model.

The Rumbaugh method. Rumbaugh and his colleagues developed the

object modeling technique (OMT) for analysis, system design, and object-

level design. The analysis activity creates three models: the object model (a

representation of objects, classes, hierarchies, and relationships), the

dynamic model (a representation of object and system behavior), and the

functional model (a high-level DFD-like representation of information flow

through the system).

The Jacobson method. Also called OOSE (object-oriented software

engineering), the Jacobson method is a simplified version of the proprietary

objectory method, also developed by Jacobson. This method is

differentiated from others by heavy emphasis on the use-case. A description

or scenario that depicts how the user interacts with the product or system.

The Coad and Yourdon method. The Coad and Yourdon method is often

viewed as one of the easiest OOA methods to learn. Modeling notation is

relatively simple and guidelines for developing the analysis model are

straightforward. A brief outline of Coad and Yourdon’s OOA process follows:

Identify objects using “what to look for” criteria.

Define a generalization/specification structure.

Define a whole/part structure.

Identify subjects (representations of subsystem components).

Define attributes.

Define services.

The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner do not make

a clear distinction between analysis and design tasks. Rather a continuous

process that begins with the assessment of a customer specification and

ends with design is proposed. A brief outline of Wirfs-Brock et al.'s analysis-

related tasks follows: Evaluate the customer specification.

Extract candidate classes from the specification via grammatical

parsing.



Group classes in an attempt to identify super-classes.

Define responsibilities for each class.

Assign responsibilities to each class.

Identify relationships between classes.

Define collaboration between classes based on responsibilities.

Build hierarchical representations of classes.

Construct a collaboration graph for the system.

iii) A Unified Approach to OOA

Over the last few decades, Grady Booch, James Rumbaugh, and Ivar

Jacobson have collaborated to combine the best features of their individual

object-oriented analysis methods. Analysis methods along with design

methods were combined into a unified method of modeling language. The

resulting language was called the Unified Modeling Language (UML). UML

allows a software engineer to express an analysis model. The analysis

model is expressed based on the standards notation of UML, governed by

a set of syntactic, semantic, and pragmatic rules. Eriksson and Penker

explain these rules in the following way: The syntax tells us how the

symbols should look and how the symbols are combined. The syntax is

compared to words in natural language; it is important to know how to spell

them correctly and how to put different words together to form a sentence.

The semantic rules tell us what each symbol means and how it should be

interpreted by itself and in the context of other symbols; they are compared

to the meanings of words in a natural language.

The pragmatic rules define the intentions of the symbols through which the

purpose of the model is achieved and becomes understandable for others.

This corresponds in natural language to the rules for constructing sentences

that are clear and understandable. In UML, a system is represented using

five different “views” that describe the system from distinctly different

perspectives. Each view is defined by a set of diagrams. The following views

are present in UML:

User model view- This view represents the product as a system. The view

is from the user’s perspective. The use-case is the modeling approach of

choice. This important analysis representation mainly describes a scenario

for usage from the perspective of the end-user.



Structural model view- Data and functionality are viewed. The view is

internal and is view from within the system. Static structure is modeled

based on the data and functionality.

Behavioral model view- This part of the analysis model represents the

dynamic aspects of a system. The dynamic aspect refers to the behavioral

aspects of the system. It depicts the interactions or collaborations between

various structural elements.

Implementation model view- The structural and behavioral aspects of the

system are developed and assembled depending upon the requirements

and built according to the end user needs.

Environment model view- The structural and behavioral aspects of the

environment are represented. UML analysis modeling focuses on the user

model and structural model views. One of the task of UML design modeling

is to address the behavioral model, implementation model, and

environmental model views.


1. Name any two views used in UML.

10.3.2 Domain Analysis

At the business or enterprise level, the techniques associated with OOA can

be coupled with a business process engineering approach.

At the business area level, an object model that describes the workings of a

particular business area an be defined.

At an application level, the object model focuses on specific customer

requirements as those requirements affect an application to be built.


1. What various levels of domain analysis?

10.3.3 Generic Components of the OO Analysis Model

Rumbaugh et al. states that Analysis is concerned with devising a precise,

concise, understandable, and correct model of the real world. . . . The

purpose of object-oriented analysis is to model the real world so that it can

be understood. To do this, you must examine requirements, analyze their

implications, and restate them rigorously. You must abstract real-world

features first, and defer small details until later.



To develop a “precise, concise, understandable, and correct model of the

real world,” a software engineer must select a notation that implements a set

of generic components of an OO analysis model. Monarchi and Puhr define

a set of generic representational components that appear in all OO analysis

models.6 Static components are structural in nature and indicate

characteristics that hold throughout the operational life of an application.

These characteristics distinguish one object from other objects. Dynamic

components focus on control and are sensitive to timing and event

processing. They define how one object interacts with other objects over

time. The following components are identified

Static view of semantic classes: A taxonomy of typical classes was

identified. Requirements are assessed and classes are extracted (and

represented) as part of the analysis model. These classes persist

throughout the life of the application and are derived based on the

semantics of the customer requirements.

Static view of attributes. Every class must be explicitly described. The

attributes associated with the class provide a description of the class, as

well as a first indication of the operations that are relevant to the class.

Static view of relationships. Objects are “connected” to one another in a

variety of ways. The analysis model must represent these relationships so

that operations (that affect these connections) can be identified and the

design of a messaging approach can be accomplished.

Static view of behaviors. The relationships just noted define a set of

behaviors that accommodate the usage scenario (use-cases) of the system.

These behaviors are implemented by defining a sequence of operations that

achieve them.

Dynamic view of communication. Objects must communicate with one

another and do so based on a series of events that cause transition from

one state of a system to another.

Dynamic view of control and time. The nature and timing of events that

cause transitions among states must be described.


1. What are the various generic component of object oriented analysis?



10.3.4 The OOA Process

The OOA process begins with an understanding of the manner in which the

system will be used. The modeling of the software begins only after the

scenario of usage has been well understood and defined. The following

points may be followed to gather customer data to model the system:

i) Use-Cases

This refers to the model of the system from the end-user’s point of view. It is

created during elicitation of user requirements. The following objectives

have to be borne in mind with respect to use-cases:

Define the functional and operational requirements of the system

Provide a clear and unambiguous description of the interaction between

the end-user and the system.

Provide a basis to validate the testing

ii) Class-Responsibility-Collaborator Modeling

After having developed the usage scenarios, dentify candidate classes and

indicate their responsibilities and collaborations. Class-responsibility-

collaborator (CRC) modeling provides a simple means for identifying and

organizing the classes that are relevant to system or product requirements.

Ambler describes CRC modeling in the following way:

A CRC model is really a collection of standard index cards that represent

classes. The cards are divided into three sections. Along the top of the card

you write the name of the class. In the body of the card you list the class

responsibilities on the left and the collaborators on the right.

Classes

Identify classes and objects based on the following guidelines: Identify from

the cases and problem under consideration, the variety of forms an object

may assume, external entities, things, occurrences, or events, roles,

organizational units, places etc. Perform a grammatical parse on the

processing aspects of the system. List of all the identified nouns become

potential objects. The following are the characteristics of selection :

1. Retained information- During analysis the potential object will be useful

only if it is necessary to remember the information

2. Needed services- The operations have to identified wrt the potential

object.



3. Multiple attributes- The focus should be on "major" information

pertaining to the object, this may result in multiple attribution of the

object.

4. Common attributes- A set of attributes defined may appear to be

common when compared with other object in the system.

5. Common operations- There can be a common set of operations on the

object which are identified as potential object

6. Essential requirements- External entities be defined as objects in the

requirements model.

iii) Defining Structures and Hierarchies

Once classes and objects have been listed out with the help of CRC model,

the analyst then focuses on the structure of the class model. The analyst

then determines the hierarchies with respect to each object and classes.

Class diagrams are created with the help of UML.

iv) Defining Subjects and Subsystems

Group of all classes are referred to as subsystems or packages. A

subsystem can be treated as a black box when it is viewed from outside. A

subsystem implements one or more contracts. A contract is a specific list of

requests made on the subsystem. Subsystems can be represented with the

by creating a subsystem index card. The subsystem index card indicates the

name, contracts, and classes of the subsystems that support the contract.

Packages can be referenced by a single icon. Package references can be

created for multiple objects structure.


1. ________models the system from the end-user’s point of view.

2. Generalization/specialization class structures can be created for

___________ classes.

10.3.5 The Object Relationship and Behavior Model

The CRC and the object-relationship model represent static elements the

Object analysis model. To incorporate dynamic behavior into the model,

consider the behaviour of the system as function of specific events and time.

The object-behavior model is sensitive to external events. To model the

functionality the following steps may be considered:

1. Evaluate all use-cases

2. Identify events



3. Create an event trace

4. Build a state transition diagram

5. Review the object-behavior model

10.3.5.1 Identification of Events with Use Cases

The methodology of going through the various sequences of activities and

understanding the process helps in easy identification of the events. Any

such case will be looked into to capture information. The performer actor is

to be identified in the case scenario. Conditions and limitations if any are

identified and listed. After identifying the events in the scenario, they are to

be allocated to objects.

10.3.5.2 Representation of State

There are two different aspects of the state to be considered. The first is the

state of the object and the second is the state of the system in which the

object functions. The state of object can be active or passive. The object is

said to be in active state if it is undergoing a transformation through a

process. Event is responsible to bring about a change in the object whereas

the passive state indicates the status of all the attributes of the object.


1. What are the steps followed in object-behavior model?

10.4 Summary

An abstraction enables us to model the world. An object-oriented

development was proposed first during the 1960s. One can derive a number

of benefits from the object technologies.

Object oriented approach can be understood well if the knowledge of the

real world entity is clear. A class encapsulates the data and procedural

abstractions required to describe the content and behavior of a real world

entity.

The data abstractions are also referred to as attributes. The attributes are

controlled and manipulated by abstraction procedures known as operations

or methods. A super-class refers to a collection of classes, and a subclass is

referred to as a specialized instance of a class.

Real world entities have features such as shape, weight, color, and type of

material. These are abstracted as attributes of the object representing the



real world problem. Messages are the means by which objects

communicate with each other.

Encapsulation refers to the data and the methods on the data which are

held together in a class by means of specifications stated for the class. The

main elements of an object model are the classes and objects, attributes,

operations, and messages. Software project estimation remains more of an

art than a science. To develop reasonable estimates it is essential to

develop multiple data points. That is, estimates should be derived using a

number of different techniques.

The main objective of object-oriented analysis is to develop a model that

describes computer software. The model should work to satisfy a set of

customer-defined requirements. The model used for the purpose of

analysis depicts information, function, and behavior within the context.

The use-case is the modeling approach of choice. This important analysis

representation mainly describes a scenario for usage from the perspective

of the end-user.


1. Develop a classroom presentation on one static or dynamic modeling

diagram used in UML. Present the diagram in the context of a simple

example, but provide enough detail to demonstrate most important

aspects of the diagrammatic form.

2. In your own words describe the difference between static and dynamic

views of an OO system.

3. Using your own words and a few examples, define the terms class,

encapsulation, inheritance, and polymorphism.


1. Which of the following are the features of object oriented approach?

(a) Polymorphism (b) inheritance (c) all the above (d) none of these

2. Which of the following are the elements of object model?

(a) classes and objects (b) attributes (c) all the above (d) none of these





10.2.1 1. Message 2. Refer section 10.2.1

10.2.2 Classes and objects, attributes, operations, and messages


10.3.1 Implementation model view, environment model view


10.3.3 Static view of semantic classes , Static view of attributes ,Static view

of relationships, Static view of behaviors, Dynamic view of control

and time, Dynamic view of communication

10.3.4 1. Use-cases 2. Identified







1. c

2. c

Documents

Merged Document