software engineering - pcpolytechnic · 2019-02-18 · software engineering program outcomes...

Software Engineering

Program Educational Objectives Mappimg: Preparation: To prepare students for placement in

reputed industries or to excel in higher studies or

entrepreneurship (1) Core Competence: To train students on application of

basic principles in Mathematics, Science and

Computer Engineering for solving Engineering/

Business problems, and designing systems and

products (2) Professionalism: To inculcate professional ethics as

the basic principle and soft skills to develop

professionalism among the students (4)

Software Engineering Program Outcomes Mapping: • an ability to apply knowledge of Mathematics,

Science, and Engineering (a).

• an ability to design and conduct experiments, as

well as to analyze and interpret data (b).

• an ability to design a system, component, or process

to meet desired needs within realistic constraints

such as economic, environmental, social, political,

ethical, health and safety, manufacturability, and

sustainability (c)

• an ability to identify, formulate, and solve

engineering problems (e)

Software Engineering Program Outcomes Mapping (Contd) : • an understanding of professional and ethical

responsibility (f)

• an ability to communicate effectively (g)

• the broad education necessary to understand the

impact of engineering solutions in a global,

economic, environmental, and societal context (h)

• a knowledge of contemporary issues (j)

• an ability to apply systems approach for problem

solving (n)

Software Engineering Contents Beyond Syllabus : • Program Educational Objectives : 1, 2, 4

• Defined Program Outcomes : a, b, c, e, f, g, h, j,

k, l, m, n

• Attainable Program Outcomes : a, b, c, e, f, g, h, j,n

• Gap between Defined & Attainable Program

Outcomes : k, l

• Contents Beyond Syllabus :

• Introduction to Software Engineering tools –

Rational Rose

• Case study


Unit I : Introduction to Software Engineering • Introduction : Nature of software, Software

Process, Software Engineering Practice, Software

Myths, Generic Process Model

• Process Models : Waterfall Model, Incremental

Models, Evolutionary Models, Concurrent Process

Model, Specialized process Models

• Personal & Team Process Models

• Agile process Models : Agile Process, Extreme

Programming (XP)

S

What is Software?

What are the characteristics of Software?

Nature of Software

Software Myths

Software Engineering Practice

Framework Activities

Umbrella Activities

What is Software?

Set of programs

Data Structures

Documentation :

What are the characteristics of Software?

Logical rather than Physical

Software is developed or engineered, it is not

manufactured (Quality, People, Process,

Cost)

Software does not wear out (Bathtub Curve)

Moving towards component based

construction, however most of the software is

custom built

9

Hardware vs. Software Hardware Software

Manufactured Wears out

Built using components

Relatively simple

Developed/Engineered

Deteriorates

Custom built

Complex

10

Manufacturing vs. Development

•Once a hardware product has been manufactured, it is difficult or impossible to modify. In contrast, software products are routinely modified and upgraded. •In hardware, hiring more people allows you to accomplish more work, but the same does not necessarily hold true in software engineering. •Unlike hardware, software costs are concentrated in design rather than production.

11

Wear vs. Deterioration Hardware wears out over time

12

Wear vs. Deterioration Software deteriorates over time

13

Software Complexity

“I believe the hard part of build ing software to be the specification, design, and testing of this conceptual

construct, not the labor of representing it and testing the

fidelity of the representation”. If this is true, build ing software will always be hard . There

is inherently no silver bullet.

- Fred Brooks, “No Silver Bullet”

http://www.computer.org/computer/homepage/misc/Brooks/

Nature of Software Systems Software Applications Software Engineering / Scientific software

Embedded Software Product Line Software

Web Applications Artificial Intelligence Software Ubiquitous Software

Net sourcing Open Source

Software Myths

Management Myths

Customer Myths

Practitioners Myth

Software Myths

Management Myths

We are already having a book that is full of

Standards & Procedures for building

software. It will provide my people everything

they need to know.

If we get behind schedule, we can add more

developers & catch up.

We can outsource the software project to a

third party. I can just relax & let that firm build

it.

Software Myths

Customer Myths

A general statement of objectives is sufficient to begin writing programs.

We can fill in the details later

Project requirements continually

change, but the change can be easily accommodated because software is flexible

Software Myths

Practitioners Myth

Once we write the program and get it to work our job is

done

Until I get the program running, I have no way of

accessing its quality

The only deliverable work product for a successful

project is the working program

Software Engineering will make us create voluminous

&

unnecessary documentation & invariably slow us down

Software Engineering – A layered Technology

• Software Engineering is the application of systematic, disciplined, quantifiable

approach to the development, operation and maintenance of software i.e. the application of engineering to software

[ IEEE definition ]

20

A Layered Technology


a “quality” focus

process model

methods

tools

Software Engineering Layers

Quality Focus : Organizational commitment to quality ( TQM, Six Sigma )

Process : Defines a framework (Foundation for Software Engineering) Methods : Ho to s for uildi g soft are (Tasks) Tools : Automated or semi-automated

support (Rational Rose, CASE tools)

Framework Activities

Communication

Planning

Modeling

Construction

Deployment

23

A Process Framework Process framework

Umbrella activities

framework activity #1

SE action #1.1

Software process

task sets

work tasks work products QA points milestones

SE action #1.2

task sets


framework activity #2

SE action #2.1

task sets


SE action #2.2

task sets


Umbrella Activities

Software Project Tracking & Control Risk Management

Software Quality Assurance Formal Technical Reviews Measurement

Software Configuration Management Reusability Management

Software Engineering Practice

• Practice is collection of Concepts, Principles,

Methods & Tools that a software engineer calls

upon on a daily basis.

• Practice allows Managers to manage software

projects & Software Engineers to build

computer programs.

The Essence of SE Practice

1.Understand the Problem – Communication

& Analysis 2.Plan a Solution – Modeling & Software

Design 3.Carry out the Plan – Code generation

4.Examine the Results – Testing & QA

Core Principles

1.The Reason it all Exists 2.Keep It Simple, Stupid (KISS!) 3.Maintain the Vision

4.What you Produce, others will Consume 5.Be Open to Future 6.Plan Ahead for Reuse

7.THINK

Software process model

•Attempt to organize the software life cycle by •defining activities involved in software production •order of activities and their relationships

•Goals of a software process –standardization, predictability, productivity, high product quality, ability to plan time and budget requirements

Code & Fix

The earliest approach

•Write code •Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features •Source of difficulties and deficiencies –impossible to predict –impossible to manage

Process Models

Prescriptive Process Models

• The Waterfall Model

• Incremental Model

• The RAD Model

Evolutionary Process Models

• The Prototyping Model

• The Spiral Model

• The Concurrent Development Model

31

The Waterfall Model

The Waterfall Model: (Payroll System) Merits :

• It is systematic sequential approach for

Software Development

Demerits • All Customer Requirements at the start of

project may be difficult • Problems remain uncovered until testing

phase • Customer patience is needed, working version

of the software is delivered too late.

33

Incremental Models: Incremental

Incremental Model: (Word Processor)

Merits :

• Less number of developers required • All the requirements need not be known at the

beginning of the project

• Technical risks can be managed

Demerits : • Problems remain uncovered until testing

phase • Customer patience is needed, working version

of the software is delivered too late.

35

Incremental Models: RAD Model

The RAD Model : (Very Large Projects)

Merits :

• Project cycle time is reduced

Demerits : • All Customer Requirements at the start of

project may be difficult • For large projects high human resources are

required • Risk of project failure if teams are not

committed to rapid fire action • Problems due to improper modularization of

system

• RAD approach may mot work if high is an issue • RAD maynot be appropriate if technical risks

are very high

Evolutionary Process Models: Need

• Software like all complex systems evolves over a period

of time.

• Target market deadlines make completion of a

comprehensive software product impossible, but a

limited version must be introduced to meet

competitive or business pressure. Some of the core

product or system requirements are well understood

but the details of product or system extensions have

yet to be defined.

• Solution is to adapt Evolutionary Model which is

Iterative

The Prototyping Model: (Need)

• Prototyping is used when customers requirements are

fuzzy.

• OR the developer may not be sure of the efficiency of

algorithm, the adaptability of an Operating System or

the form that Human Computer interaction should

take

• But we have to throw away the prototype once the

customer requirements are clear & met for better

quality. The product must be rebuilt using software engineering practices for long term quality.

39

Evolutionary Models: Prototyping

The Prototyping Model:

Merits:

• Prototyping helps in requirement gathering &

can be applied at any stage of the project.

Demerits:

• Customer insists to convert prototype in

o ki g e sio appl i g fe fi es

• Developer may become comfortable with the

o p o ises do e. The-less-than-ideal-

hoi e a e o e i teg al pa t of the s ste

Evolutionary Models: Spiral Spiral Model is an evolutionary software process model

that couples the iterative nature of Prototyping with

controlled & systematic aspects of the Waterfall Model

Merits:

• Risk is considered as each iteration is made

• Spiral Model can be applied throughout the life of

the computer software.

Demerits:

• It is difficult to convince customers that the

evolutionary approach is controllable

• Considerable risk assessment expertise required

• If major risk is uncovered, problems will occur

Concurrent Development Model: The concurrent Development Model, sometimes called

concurrent engineering can be represented schematically as a series

of framework activities, software engineering actions and tasks, &

their associated states. All activities exist concurrently.

Modeling activity (Example) :

Under Dev.

Awaiting Chng Under Review

Under Rev. Baselined

Done

None

Co u e t De elop e t Model: Co td…

Merits:

• Applicable to all types of S/W development &

provides an accurate picture of the current state of

the project.

Demerits:

• Problem to Project planning. How many No of

iterations are to be planned? Uncertainty…

• Process may fall in chaos if the evolutions occurs too

fast without a period of relaxation. On the other hand

if the speed is too slow productivity could be

affected. • S/W processes are focussed on flexibility &

extendability, rather than on high quality.

44

Risk Exposure

Specialized Process Models:

Specialized process models use many of the characteristics

of one or more of the conventional models presented so far,

however they tend to be applied when a narrowly defined

software engineering approach is chosen. They include,

Components based development

The Formal Methods Model

Aspect oriented software development

Components Based Development :

In this approach, Commercial Off-The-Shelf (COTS) S/W

components, developed by vendors who offer them as products are

used in the development of software. Characteristics resemble to

spiral model.

Merits:

Leads to software reuse, which provides number of

benefits

• 70% reduction in development cycle time

• 84 % reduction in project cost

• Productivity index goes up to 26.2 ( Norm : 16.9)

Demerits:

Component Library must be robust.

Performance may degrade

The Formal Methods Model: •The formal methods model encompasses a set of activities that

lead to formal mathematical specification of computer software.

• It consists of specifications, development & verification by applying

rigorous mathematical notation. Example, Clean Room S/W

Engineering (CRSE)

Merits: Removes many of the problems that are difficult to

remove using other S/W Engg. Paradigms. Ambiguity, Incompleteness & Inconsistency can be

discovered & corrected easily by using formal methods of

mathematical analysis.

Demerits:

Development is time consuming & expensive

Extensive training is required Difficult to use with technically unsophisticated customers

Aspect Oriented Software Development (AOSD):

• A set of localized features, functions & information contents are used while building complex software.

• These localized s/w characteristics are modeled as components (e.g. OO classes) & then constructed within the context of a system architecture.

• Ce tai o e s (Custo e e ui ed p ope ties o a eas of technical interest) span the entire architecture i.e. Cross cutting Concerns like system security, fault tolerance etc. Merits:

It is similar to component based development for aspects Demerits:

Component Library must be robust.

Performance may degrade

49

Unified Process Model A software process that is:

use-case driven

architecture-centric

iterative and incremental

Closely aligned with the

Unified Modeling Language (UML)

50

inception

The Unified Process (UP)

51

UP Work Products

inception

52

Common Fears for

Developers

•The project will produce the wrong product. •The project will produce a product of inferior quality. •The project will be late. •We’ll have to work 80 hour weeks. •We’ll have to break commitments. •We won’t be having fun.

53

The Manifesto for Agile

Software

Development

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan

-- Kent Beck et al.

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we value the

items on the left more.”

54

What is “Agility”? •Effective (rapid and adaptive) response to change

•Effective communication among all stakeholders

•Drawing the customer onto the team •Organizing a team so that it is in control of the work

performed

Yielding …

•Rapid, incremental delivery of software

55

An Agile Process •Is driven by customer descriptions of what is required (scenarios) •Recognizes that plans are short-lived •Develops software iteratively with a heavy emphasis on construction activities •Delivers multiple ‘software increments’ •Adapts as changes occur

56

Principles of Agility

•Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. •Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. •Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. •Business people and developers must work together daily throughout the project.

57


•Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. •The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. •Working software is the primary measure of progress. •Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

58


•Continuous attention to technical excellence and good design enhances agility. •Simplicity - the art of maximizing the amount of work not done - is essential. •The best architectures, requirements, and designs emerge from self-organizing teams. •At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

59

Extreme Programming (XP) •The most widely used agile process, originally proposed by Kent Beck •XP Planning

–Begins with the creation of user stories –Agile team assesses each story and assigns a cost –Stories are grouped to for a deliverable increment –A commitmentt is made on delivery date –After the first increment project velocity is used to help define subsequent delivery dates for other increments

60

Extreme Programming (XP) •XP Design

–Follows the KIS principle –Encourage the use of CRC cards (see Chapter 8) –For difficult design problems, suggests the creation of spike solutions — a design prototype –Encourages refactoring — an iterative refinement of the internal program design

•XP Coding –Recommends the construction of a unit test for a store before coding commences –Encourages pair programming

•XP Testing –All unit tests are executed daily –Acceptance tests are defined by the customer and executed to assess customer visible functionality

61

Extreme Programming (XP)

62

Other Agile Processes

•Adaptive Software Development (ASD) •Dynamic Systems Development Method (DSDM) •Scrum •Crystal •Feature Driven Development •Agile Modeling (AM)

PSP and TSP

• PSP is a high-maturity process framework for

individuals

•TSP addresses high-maturity practices for teams

of PSP-trained engineers

• P“P & T“P pro ide a set of Ho s to the CMM’s Whats

• PSP & TSP get individuals and teams more

involved in process improvement

• PSP & TSP are sometimes referred to as Level 5

processes for individuals and team

THE PSP PHILOSOPHY

• Use effective methods • Recognize strengths and weaknesses

• Practice, practice, practice • Learn from history

• Find and learn new methods • Practice software development as an engineering discipline rather than craft

What is the PSP?

• The PSP is a set of practices that engineers can apply

to most structured personal tasks to improve

predictability, quality, & productivity

• The PSP as taught contains one set of methods that

can be effective for many

– An excellent starting point, but not expected to

e a o e size fits all pro ess

• Currently, few engineers practice the best available

methods, negatively impacting chances of project

success—PSP addresses this

What does PSP Developer DO

• Tracks basic development process data

– Size, time, defects, and task completion

– Time & defects are tracked by phase, e.g., planning,

design, code, personal reviews, test, postmortem

• Uses data derived from the basic data for process

management and improvement

• Plans using historical data and tracks progress

– PROBE PRO Based Esti ati g esti ati g

– Ear ed Value s heduli g & tra ki g

– Quality planning

• Builds i Qualit

– Produces verifiable designs

– Conducts structured personal design and code reviews

• Improves development process using data

What is the TSP? The TSP strategy is to improve performance from the bottom up. This strategy

starts with PSP training.

Team Member Skills Process discipline Performance measures Estimating and planning skills Quality management skills Team Building Goal setting Role assignment Tailored team process Detailed and balanced plans Team Management Team communication Team coordination Project tracking Risk analysis

PSP TSP Make CMM Level 5 behavior normal and expected

What does TSP Developer DO

• Developers use PSP practices for their personal work

• For each development phase (2-4 months), the team

– Co du ts a tea lau h to o e to a o o

understanding of the project & to develop detailed

plans

– Tracks progress against schedule and quality weekly,

adjusts plans, and takes immediate action if necessary to

ensure commitments will be met

– Uses team-level data the same way as developers use

their individual data to assess schedule and quality

• Quality data, Software inspections, Time on Task,

Earned value , etc.

– Conducts Postmortems to improve development process

Process Patterns •A Process pattern provides us with a template

which provides a consistent method for describing

an important characteristics of the software

process • Thus software process can be defined as a

collection of patterns that define a set of activities,

actions, work tasks, work products and related

behaviors required to develop computer software. • By combining patterns, a software team can

construct a process that best meets the needs of a

project. • Patterns can be defined at any level of

abstraction – Complete process, framework

Activity, Umbrella activity, SE action or a task

Process Patterns Template

Item Contents

Pattern Name Meaningful Name of pattern

Intent Objective of pattern

Type Task, SE action, Framework activity, Umbrella

activity etc

Initial Context Applicable Pre-requisites

Problem Problem Definition

Solution Solution to the problem / process

Resulting Context S/W Engg. Info. & Project info. Generated

after completion

Related Processes A list of other related process patterns

Known Uses Where it is useful & Examples where it has

been used


Unit II : Requirement Engineering • Requirement Engineering : Initiating the Process,

Eliciting Requirements, Building the

Requirements Model, Negotiating, Validating

Requirements

• Requirements Analysis : Scenario Based Analysis

• Requirements Modeling Strategies : Flow

Oriented Modeling, Class based Modeling

• SRS : Software Requirements Specifications

S

REUIREMENTS ENGINEERING

• What it is?

• Who Does it?

• Why it is Important?

• It is not easy

• Bridge to Design & Construction

• Communication + Analysis

REQUIREMENT ENGINEERING TASKS

1. Inception : Basic Understanding

2. Elicitation : Clear Understanding

3. Elaboration : Refinement

4. Negotiation : Settlement of Conflicts

5. Specification : SRS

6. Validation : FTR Team Validates

7. Management : Changed Reqt. Mgmt.

INCEPTION

INITIATING THE REQUIREMENT ENGG. PROCESS

How Requirements are originated?

• Business Need is identified

• New market or service is discovered

• Working description of the project

Steps to initiate Requirement Engineering

1. Identifying the stakeholders

2. Recognizing multiple view points

3. Working towards collaboration

4. Asking the first questions

Identifying the stakeholders Stakeholder :

• Anyone who gets benefited directly or

indirectly from the system

• Stakeholders can be Business operations

Managers, Product managers, Marketing

people, Internal or External Customers,

End-users, Consultants, Product Engineers,

Software Engineers, Support &

Maintenance Engineers and many others .

• At inception, the requirement engineer

prepares a list of people who will contribute

input as requirements are elicited.

Recognizing multiple view points

• Each stakeholder explores the system

requirements from his point of view.

• As information from multiple view point is

collected, emerging requirements may be

inconsistent or conflicting.

• Categorize the information collected

Working Towards Collaboration

• Customers and other stakeholders should

collaborate among themselves and software

engineering practitioners for the success of

the project.

• requirements are to be sorted out as

commonly agreed and inconsistent or

conflicting requirements.

Asking the First Questions

• Questions asked at the inception of the

p oje t should e o te t f ee ith the following objectives:

• to establish communication between

software practitioners and the

customer

• to identify all the stakeholders

• to get the better understanding of the

problem

• to help to eak the i e a d i itiate the communication

Asking the First Questions – Contd.

First Set helps to identify all stakeholderswho will

have interest in the software solution and it

identifies measurable benefits of successful

implementation.

• Who is behind the request for this work?

• Who will use the solution?

• What will be the economic benefit of a

successful solution?

• Is there any other source for the solution you

need?


Next Set helps software team to gain a better

understanding of the problem

• Ho ould ou atego ize good output that will be generated by a successful solution?

• What problems this solution will address?

• Can you show me the business environment in

which the solution will be used?

• Will special performance issues or constraints

affect the way the solution is approached?


Final Set of questions focuses on the effectiveness of

the communication abilityitself.

• Are you the right person to answer these

questions

• Are your answers official?

• Are my questions relevant to the problem that

you have?

• Am I asking too many questions?

• can anyone else provide additional info?

•Should I be asking you anything else?

ELICITING REQUIREMENTS

Elicitation format consists of :

• Collaborative Requirement Gathering

• Quality Function Deployment

• User Scenarios (i.e Use Cases)

• Elicitation Work Products

Collaborative Requirement Gathering

Guidelines:

•Team of stakeholders & developers work together

• Meetings are conducted between them

• Rules for preparation & participation

• Formal Agenda – Topics, date, Time, Venue in advance

• A Facilitator must be appointed

• Definition Mechanism is to be used

• Goal must be to identify the problems/issues


Sequence of Events:

1. Product Request ( O/P of Inception Phase)

2. A Facilitator is chosen

3. Meeting is called – Product request & Reqt. List given

4. Attendees are asked to identify objects used/created,

processes, functions, constraints, performance etc.

5. Meeting day – Justification for the new system

6. Presentation by each participant – Definition

mechanism Used

7. Combined list of requirements is prepared by a group

8. Facilitator shortens/lenghens/modifies the list to

develop a consensus list identifying objects, services,

constraints & performance


Sequence of Events:

9. Team is divided in smaller groups to prepare

specifications a group of related requirements.

10. Presentation by each team – addition / deletion /

further elaborations are done. New objects, services,

constraints performances may get added to the

original list

11. Issues list is prepared- to be discussed in nest meeting

12. Each attendee makes a list of validation criteria for the

system/product

13. Draft Document is prepared.

QUALITY FUNCTION DEPLOYMENT • QFD is the technique that translates needs of the customer

into technical requirements of the software.

• QFD concentrates on maximizing customer satisfaction

• QFD identifies what is valuable to the customer and then

deploys these values throughout the engineering process.

• QFD used interviews, surveys, analysis of historical data &

creates Custo e Voice Ta le

• QFD identifies three types of requirements

1. Normal Requirement

2. Expected Requirements

3. Exciting Requirements

• QFD Concepts:

1. Function Deployment

2. Information Deployment

3. Task / Behavior Deployment

4. Value analysis

USER SCENARIOS

The Scenario often called as Use-Cases or use

sto ies , provide a description of how the system will

be used. As requirements are gathered, an overall

vision of system functions & features begins to

materialize. However it is difficult to move into more

technical software engineering activities until the

software team understands how these functions &

features will be used by different classes of end-users.

To accomplish this developers & users create a set of

scenarios that helps to identify a thread of usage for

the system to be constructed.

ELICITATION WORK PRODUCTS

• Statement of need and feasibility

• Bounded statement of scope

• A list of all stakeholders

• Description of System technical environment

•List of requirements /constraints (Function wise)

• Set of usage scenarios

• Any prototype developed to define

requirements

NEGOTIATING REQUIREMENTS

• Customer is asked to balance the

functionality, performance and other system

or product characteristics against cost &

time to market

• The intent of negotiations is to develop a

project plan

• The est egotiatio s st i e fo i - i result.

VALIDATING REQUIREMENTS • As each element of Analysis Model is created, it is examined for

consistency, omissions & ambiguity.

• The requirements represented by the model are priotorized by

the customer & grouped into requirement packages that will be

implemented as software increments & delivered to customer.

The review of Analysis model by FTR addresses:

• consistency of each requirement with the overall objective

• proper specifications of requirements

• necessity of requirement

• Is each requirement bounded & unambiguous?

• source of each reqt.

• check for conflicting reqt. * Info., function & Behavior.

• technical feasibility of reqt. * Model partitioning

• testability of reqt. * Usage of reqt. Pattern.

BUILDING THE ANALYSIS MODEL • However the written word is wonderful vehicle for

communication, but it is not necessarily the best way to

represent the requirement for computer software

• Analysis Modeling uses combination of text & diagrammatic

forms to depict requirements of data, functions & behavior in

a way that is easy to understand & more importantly,

straightforward to review for correctness, completeness &

consistency

• A software Engineer ( or a Systems Analyst) builds the model

using requirements elicited from the customer

• It is very important activity because to validate software

requirements , you need to view them from a number of

different points of view. Analysis model represents

e ui e e ts i ultiple di e sio s , the e i easi g the probability that errors will be found, that inconsistency

will surface and that omissions will be uncovered

ANALYSIS RULES OF THUMB

• The model should focus on the requirements that are vissible

within the problem or business domain

• The level of abstraction should be relatively high

• Each element of an analysis model should add to an overall

understanding of software requirements and provide insight

into the information domain, functionand behavior of the

system

•Delay consideration of infrastructure and other non-functional

models until design phase

• Minimize coupling throughout the system -

interconnectedness between classes and functions should be

low

• Keep the model as simple as it can be

ANALYSIS MODELIMG APPROACHES

• Structured Analysis : This considers data and processes

that transforms the data as separate entities. Data objects

are modeled in a way that defines their attributes and

relationships. Processes that manipulate data objects are

modeled in a manner that shows how they transform data

as data objects flow through the system. Flow oriented

modeling is predominantly used.

• Object Oriented Analysis : This approach focuses on the

definition of classes and the manner in which they

collaborate with one another to effect customer

requirements. UML and Unified process are predominantly

object oriented

Analysis Model

• Analysis Modeling leads to the derivation of

each of the modeling elements shown in the

following figure

• Only those modeling elements that add value

to the model should be be used

• The specific content of each element may

differ from project to project

Analysis Model

Elements of the analysis model

Scenario-Based Modeling • For the building of analysis and design models, it is

essential for software engineers to understand how end

users and other actors want to interact with the system

• Analysis Modeling with UML begins with the creation of

scenarios in the form of use-cases, activity diagrams and

swim-lane diagrams

• Use cases can be represented as a text narrative or as an

ordered sequence of user actions or by using a template

• Example, consider the use case Access Camera

Surveillance – Display Camera Views (ACS – DCV) of the

Safe Home Security System

Scenario-Based Modeling • Use case : (ACS – DCV) – User actions

1. The homeowner logs on to the safe home products

web-site.

2. The homeowner enters his / her user-id

3. The homeowner enters two passwords

4. The system displays all major function buttons

. The ho eo e sele ts the “u eilla e f o the

major function buttons

. The Ho eo e sele ts pi k a a e a [o all a e a ] utto

7. The system displays the floor plan [ or Thumbnail

s apshots of all a e as ] 8. The homeowner selects the camera icon

9. The ho eo e sele ts the ie utto

10. The system displays a viewing window that is identified by

camera-id

Scenario-Based Modeling - Use-case

Diagram

Use-case diagram for surveillance function

Alternative Actions

• Can the actor take some other action at this point?

• Is it possible that the actor will encounter some error

condition at this point? - Exceptions

• Is it possible that the actor will encounter behavior

i oked so e e e t outside the a to ’s o t ol?

Activity diagram for Access Camera

Surveillance—Display

Camera Views function

Swimlane

diagram

(ACS-DCV)

Flow-Oriented Modeling • Data Flow Modeling continues to be one of the most

widely used analysis technique today. Although Data

Flow Diagrams (DFDs) & other related diagrams and

information are not a formal part of UML, they can be

used to complement UML diagrams & provide

additional insight into the system requirement and flow

• DFD takes i put-process-output ie of a s ste i.e. Data Objects flow into the software & they are

transformed by processing elements & resultant data

objects flow out of the software

• Data objects are represented by labeled arrows .

Transformations are represented by bubbles (circles).

Primary external entities are represented by boxes, they

either produce information for use by system or

consume information generated by the system.

Flow-Oriented Modeling

Guidelines :

• Depict the system as single bubble in level 0.

• Carefully note primary input and output.

• Refine by isolating candidate processes and

their associated data objects and data stores.

• Label all elements with meaningful names.

• Maintain information conformity between

levels.

• Refine one bubble at a time.

Data Flow Diagram

Context-level DFD for SafeHome security function

Grammatical Parse

• The SafeHome security function enables the homeowner to configure the security

system when it is installed, monitors all sensors connected to the security system, and

interacts with the homeowner through the Internet, a PC, or a control panel.

• During installation, the SafeHome PC is used to program and configure the system.

Each sensor is assigned a number and type, a master password is programmed for

arming and disarming the system, and telephone number(s) are input for dialing when

a sensor event occurs.

• When a sensor event is recognized, the software invokes an audible alarm attached to

the system. After a delay time that is specified by the homeowner during system

configuration activities, the software dials a telephone number of a monitoring service,

provides information about the location, reporting the nature of the event that has been

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

connection is obtained.

• The homeowner receives security information via a control panel, the PC, or a

browser, collectively called an interface. The interface displays prompting messages

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

Homeowner interaction takes the following form…

Level 1 DFD

Level 2 DFD that refines the monitor sensors process

Flow-Oriented Modeling Creation of Control Flow Model – Need :

• For many types of applications, data model & DFD

are sufficient to obtain meaningful insight into

Software Requirements

• However large class of applications are driven by

e e ts athe tha data, p odu e o t ol information rather than displays or reports and

process information with heavy concern for time &

performance Such applications need Control Flow

Modeling in addition to data flow modeling

• Event or control item can be implemented as a

boolean value ( 0 or 1 OR True or False)

Flow-Oriented Modeling Creation of Control Flow Model – Guidelines :

• List all se so s that a e ead the soft a e

• List all i te upts o ditio s

• List all s it hes that a e a tuated a ope ato

• List all data o ditio s e pt , full, ja ed

• Review all control items w.r.t. noun/verb parse of

processing narrative. They are possible I/O for

control flow

• Describe the behavior of the system by identifying

it’s states : ide tif ho ea h stage is ea hed & define the transitions between states

• Focus on omissions – alternate way to reach or exit


Control Specifications [CSPEC] :

• CSPEC represents the behavior of

the system. It contains a state

diagram that is sequential

specification of behavior of the

system. It may also contains

Program Activation Table i.e. a

combinatorial specification of

behavior.

Control Flow Diagram

State diagram for SafeHome security function


Process Specifications [PSPEC] :

• PSPEC is used to describe all processes of DFD that

appear at the final level of refinement. It contains

narrative text and program design language (PDL)

description of the process algorithm, mathematical

equations, tables, diagrams or charts.

• By providing a PSPEC for each bubble in the data

flo odel a soft a e e gi ee eates a i i-spe that a se e as a guide fo desig of the software component that will implement the

process. For example, PSPEC for process password

Class-Based Modeling

Identifying Potential Analysis Classes :

• External entities that produce or consume

information • Things that are part of the information

domain • Occurrences or events • Roles played by people who interact with

the system • Organizational units • Places that establish context • Structures that define a class of objects

Class Selection Criteria

Inclusion of potential class in Analysis Model:

(Selection Characteristics) 1. Retained information 2. Needed services 3. Multiple attributes 4. Common attributes 5. Common operations 6. Essential requirements

After performing Grammatic parse on narrative of Safe Home Security system following potential classes are identified

Identifying Classes Potential class Classification Accept / Reject

homeowner role; external entity reject: 1, 2 fail

sensor external entity accept

control panel external entity accept

installation occurrence reject

(security) system thing accept

number, type not objects,

attributes

reject: 3 fails

master password thing reject: 3 fails

telephone number thing reject: 3 fails

sensor event occurrence accept

audible alarm external entity accept: 1 fails

monitoring service organizational unit reject: 1, 2 fail

Class Diagram

Class diagram for the system class

Class Diagram

Class diagram for FloorPlan

CRC Modeling

A CRC model index card for FloorPlan class

Class Responsibilities • Distribute system intelligence across

classes.

• State each responsibility as generally as

possible.

• Put information and the behavior related to

it in the same class.

• Localize information about one thing rather

than distributing it across multiple classes.

• Share responsibilities among related

classes, when appropriate.

Class Collaborations

• Relationships between classes:

– is-part-of — used when classes are

part of an aggregate class.

–has-knowledge-of — used when one

class must acquire information from

another class.

–depends-on — used in all other

cases.

Class Diagrams

Top: Multiplicity

Bottom: Dependencies

Behavioral Modeling Identifying Events :

• A use-case is examined for points of

information exchange.

• The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

State Diagram

State diagram for the ControlPanel class

Sequence Diagram

Sequence diagram (partial) for the SafeHome security function

SOFTWARE REQUIREMENTS SPECIFICATION

• A Software Requirements Specification [SRS] is a

document that is created when a detailed description

of all aspects of the software to be built must be

specified before the project is to commence.

• When a software is to be developed by a third party,

when a lack of specification would create severe

business issues, or when a system is extremely

complex or business critical, an SRS is prepared.

• Karl Wiegers has developed a worthwhile template at www.processimpact.com/process_assets/srs_template.doc


SRS TEMPLATE

Table of Contents :

1. Introduction

1.1 Purpose

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Project Scope

1.5 References

2. Overall Description

2.1 Product Perspective

2.2 Product Features

2.3 User Classes and Characteristics

2.4 Operating Environment


SRS TEMPLATE … contd. 2.5 Design and Implementation Constraints

2.6 User Documentation

2.7 Assumptions and Dependencies

3. System Features

3.1 System Feature 1

3.2 System Feature 2 (and so on)

4. External Interface Requirements

4.1 User Interfaces

4.2 Hardware Interfaces

4.3 Software Interfaces

4.4 Communications Interfaces


SRS TEMPLATE … contd. 5. Nonfunctional Requirements

5.1 Performance Requirements

5.2 Safety Requirements

5.3 Security Requirements

5.4 Software Quality Attributes

6. Other Requirements

Appendix A : Glossary

Appendix B : Analysis Model

Appendix C : Issues List

UNIT III – DESIGN ENGINEERING

• Design Process & Design Quality, Design

Concepts

• Design Model: Data Design, Architectural

Design , Interface Design & Component level

elements

• Architectural Design: Software Architecture,

Architectural Styles, Architectural Design

• User Interface Design : Rules, User Interface

Analysis & Design

• Applying Interface Design Steps, Issues

• Web Application Interface Design Principles

DESIGN ENGINEERING

1. Commences after 1st iteration of

Requirements Analysis

2. GOAL : To create design model that will

implement all customer requirements

correctly to his satisfaction.

3. INTENT: To devlop High Quality Software

by applying a set of principles, concepts

and practices

4. COMPONENTS:

• Data Structures Design

• Architectural Design

• Interface Design

• Component Level Design

GENERIC TASK SET FOR DESIGN

• Design appropriate Data Structures

• Select appropriate architectural style

• Partition Analysis Model into design sub-

systems

• Create a set of Design Classes using design

patterns

• Interface design

• Design User Interfaces

• Conduct component level design

• Design Deployment Model

DESIGN MODELING PRINCIPALS

• Traceability to analysis model

• Consider architecture of the system

• Data design as important as processing

• Interfaces (Int and Ext) must be designed

• HCI as per needs of end user

• Functionally Independent component design

• Low coupling and high cohesion

• KIS – easily understandable

• Design iterations for greater simplicity

5

Analysis Design

6

Design Principles • The design process should not suffer from ‘tunnel vision.’ • The design should be traceable to the analysis model.

• The design should not reinvent the wheel.

• The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world.

• The design should exhibit uniformity and integration.

• The design should be structured to accommodate change.

• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.

• Design is not coding, coding is not design.

• The design should be assessed for quality as it is being created, not after the fact.

• The design should be reviewed to minimize conceptual (semantic) errors.

7

Design and Quality • the design must implement all of the explicit

requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.

• the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

• the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

8

Quality Guidelines • A design should exhibit an architecture that (1) has been

created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion

– For smaller systems, design can sometimes be developed linearly.

• A design should be modular; that is, the software should be logically partitioned into elements or subsystems

• A design should contain distinct representations of data, architecture, interfaces, and components.

• A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.

9

• A design should lead to components that exhibit

independent functional characteristics.

• A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.

• A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

• A design should be represented using a notation that effectively communicates its meaning.

Quality Guidelines – contd.

Quality Attributes ( FURPS)

• Functionality : Feature Sets, Security

• Usability : easy to use, overall aesthetics,

consistency, documentation

• Reliability : frequency & severity of failure

• Performance : time and space complexity

• Supportability : extensibility, adaptability,

serviceability, maintainability,

compatibility, configurability

11

Design Concepts

• abstraction : data, procedure, control

• architecture : the overall structure of the

software

• patterns : co veys the esse ce of a proven design solution

• modularity : compartmentalization of data

and function

• information hiding : controlled interfaces

• functional independence : high cohesion and

low coupling

• refinement : elaboration of detail for all

abstractions

• refactoring : improve design without effecting

behavior

12

Design Concepts : Abstraction

• When we consider a modular solution to any problem, many levels of abstraction can be posted. At the highest level of abstraction, a solution is stated in broad terms using the language of problem environment. At lower levels of abstraction, a more detailed description of the solution is provided.

• There are two types of abstractions, procedural and data

• For example, procedural : compute result

sequence of instructions

Data : subject wise marks

obtained

13

Design Concepts : Abstraction

• Abstraction

– process – extracting essential details

– entity – a model or focused representation

• Information hiding

– the suppression of inessential information

• Encapsulation

– process – enclosing items in a container

– entity – enclosure that holds the items

14

Data Abstraction door

implemented as a data structure

manufacturer

model number

type

swing direction

inserts

lights

type

number

weight

opening mechanism

15

Procedural Abstraction open

implemented with a "knowledge" of the object that is associated with enter

details of enter algorithm

16

Design Concepts : Architecture “The overall structure of the software and the ways in

which that structure provides conceptual integrity for a

system.” [SHA95a] Structural properties : This aspect of the architectural design

representation defines the components of a system (e.g.,

modules, objects, filters) and the manner in which those

components are packaged and interact with one another. For

example, objects are packaged to encapsulate both data and the

processing that manipulates the data and interact via the

invocation of methods

Extra-functional properties : The architectural design

description should address how the design architecture

achieves requirements for performance, capacity, reliability,

security, adaptability, and other system characteristics.

Families of related systems : The architectural design should

draw upon repeatable patterns that are commonly encountered

in the design of families of similar systems. In essence, the

design should have the ability to reuse architectural build ing

17

Design Concepts : Patterns

• A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.

18

Patterns Design Pattern Template

Pattern name—describes the essence of the pattern in a short

but expressive name

Intent—describes the pattern and what it does

Also-known-as—lists any synonyms for the pattern

Motivation—provides an example of the problem

Applicability—notes specific design situations in which the

pattern is applicable

Structure—describes the classes that are required to implement

the pattern

Participants—describes the responsibilities of the classes that

are required to implement the pattern

Collaborations—describes how the participants collaborate to

carry out their responsibilities

Consequences—describes the “design forces” that affect the pattern and the potential trade-offs that must

be considered when the pattern is implemented

Related patterns—cross-references related design patterns

19

Design Patterns • The best designers in any field have an uncanny

ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution

• A description of a design pattern may also consider a set of design forces.

– Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied.

• The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems.

20

Patterns • An architectural pattern expresses a fundamental

structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

• A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context.

• An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

21

Modularity: Trade-offs

What is the "right" number of modules for a specific software design?

optimal number of modules

cost of

software

number of modules

module integration

cost

module development cost

22

Information Hiding

module

controlled

interface

"secret"

• algorithm

• data structure

• details of external interface

• resource allocation policy

clients

a specific design decision

23

Why Information Hiding?

• reduces the likelihood of “side effects”

• limits the global impact of local design decisions

• emphasizes communication through controlled interfaces

• discourages the use of global data

• leads to encapsulation—an attribute of high quality design

• results in higher quality software

24

Stepwise Refinement open

walk to door;

reach for knob;

open door;

walk through;

close door.

repeat until door opens

turn knob clockwise;

if knob doesn't turn, then

take key out;

find correct key;

insert in lock;

endif

pull/push door move out of way;

end repeat

25

Functional Independence

COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

26

Refactoring • Fowler [FOW99] defines refactoring in the following

manner:

– "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”

• When software is refactored, the existing design is

examined for – redundancy – unused design elements – inefficient or unnecessary algorithms – poorly constructed or inappropriate data

structures – or any other design failure that can be corrected to

yield a better design.

27

Design Classes • User interface classes – define

abstractions necessary for HCI.

• Business domain classes – refinements of analysis classes.

• Process classes – lower-level business abstractions that manage business domain classes.

• Persistent classes – data stores (databases) that persist beyond execution of the software.

• System classes – management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.

28Q

Well-formed Design Class

• Complete and sufficient – class should be a complete and sufficient encapsulation of reasonable attributes and methods.

• Primitiveness – each method should be focused on one thing.

• High cohesion – class should be focused on one kind of thing.

• Low coupling – collaboration should be kept to an acceptable minimum.

29

The Design Model

process dimension

archit ect ure

element s

int erface

element s

component -level

element s

deployment -level

element s

low

high

class diagrams

analysis packages

CRC models

collaborat ion diagrams

use-cases - t ext

use-case diagrams

act ivit y diagrams

sw im lane diagrams

collaborat ion diagrams dat a f low diagrams

cont rol- f low diagrams

processing narrat ives

dat a f low diagrams

cont rol- f low diagrams

processing narrat ives

st at e diagrams

sequence diagrams

st at e diagrams

sequence diagrams

design class realizat ions

subsyst ems



subsyst ems


ref inement s t o:

deployment diagrams

class diagrams

analysis packages

CRC models


component diagrams

design classes

act ivit y diagrams

sequence diagrams

ref inement s t o:

component diagrams

design classes

act ivit y diagrams

sequence diagrams


subsyst ems


component diagrams

design classes

act ivit y diagrams

sequence diagrams

a na ly sis mode l

de sign mode l

Requirement s:

const raint s

int eroperabilit y

t arget s and

conf igurat ion

t echnical int erf ace

design

Navigat ion design

GUI design

30

Design Model Elements • Data elements

– Architectural level databases and files

– Component level data structures

• Architectural elements

– An architectural model is derived from:

• Application domain

• Analysis model

• Available styles and patterns

• Interface elements

– There are three parts to the interface design element:

– The user interface (UI)

– Interfaces to external systems

– Interfaces to components within the application

• Component elements

• Deployment elements

31

Interface Elements

Cont rolPanel

LCDdisplay

LEDindicat ors

keyPadCharact er ist ics

speaker

wirelessInt erf ace

readKeySt roke()

decodeKey ()

displaySt at us()

light LEDs()

sendCont rolMsg()

Figure 9 .6 UML int erface represent at ion for Co n t ro lPa n e l

KeyPad

readKeyst roke()

decodeKey()

< < int erface> >

WirelessPDA

KeyPad

MobilePhone

32

Deployment Diagram

33

Architectural Design

Software Architecture

• The software architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them.

— Bass. et al.

34

Why Architecture?

• Architecture is a representation of a system that enables the software engineer to:

1. analyze the effectiveness of the design in meeting its stated requirements,

2. consider architectural alternatives at a stage when making design changes is still relatively easy, and

3. reduce the risks associated with the construction of the software.

35

Data Design

• Architectural level Database design

– data mining

– data warehousing

• Component level Data structure design

36

Architectural Styles

• Each style describes a system category that

encompasses:

1. a set of components (e.g., a database,

computational modules) that perform a

function required by a system,

2. a set of connectors that enable

co u icatio , coordi atio , a d cooperatio a o g co po e ts,

3. constraints that define how components can

be integrated to form the system, and

4. semantic models that enable a designer to

understand the overall properties of a system.

37

Specific Styles

• Data-centered architecture

• Data flow architecture

• Call and return architecture

• Object-oriented architecture

• Layered architecture

38

Data-Centered Architecture

39

Data-Flow Architecture

40

Call and Return Architecture

41

Object-Oriented Architecture

42

Layered Architecture

43

Architectural Patterns

• Concurrency

–operating system process management

–task scheduler

• Persistence

–database management system

–application level persistence

• Distribution

–broker

44

Architectural Design

• Architectural Context Diagrams (ACD) model

how software interacts with external entities

• Archetypes are classes or patterns that

represent an abstraction critical to the

system

• Architectural components are derived from

the application domain, the infrastructure,

and the interface.

• Instantiations of the system archtecture so

far represented to reveal additional

components if required

45

Arch. Context Diagram [ACD]

46

SafeHome ACD

47

SafeHome Archetype

48

Component Structure

49

Component Elaboration Instantiation

50

Interface Design

Easy to use?

Easy to understand?

Easy to learn?

51

Interface Design

lack of consistency

too much memorization

no guidance / help

no context sensitivity

poor response

Arcane/unfriendly

Typical Design Errors

52

Golden Rules

• Place the user in control

• Reduce the user’s memory load

• Make the interface consistent

53

Place the User in Control 1. Define interaction modes in a way that does not

force a user into unnecessary or undesired actions.

2. Provide for flexible interaction.

3. Allow user interaction to be interruptible and

undoable.

4. Streamline interaction as skill levels advance and

allow the interaction to be customized.

5. Hide technical internals from the casual user.

6. Design for d irect interaction with objects that

appear on the screen.

54

Reduce the User’s Memory Load 1. Reduce demand on short-term memory.

2. Establish meaningful defaults.

3. Define shortcuts that are intuitive.

4. The visual layout of the interface should be

based on a real world metaphor.

5. Disclose information in a progressive

fashion.

55

Make the Interface Consistent 1. Allow the user to put the current task into a

meaningful context.

2. Maintain consistency across a family of

applications.

3. If past interactive models have created user

expectations, do not make changes unless

there is a compelling reason to do so.

56

User Interface Design Models

• User model — a profile of all end users of the system

• Design model — a design realization of the user model

• Mental model (system perception) — the user’s mental image of what the interface is

• Implementation model — the interface “look and feel” coupled with supporting information that describe interface syntax

and semantics

57

User Interface Design Process

58

Interface Analysis

• Interface analysis means understanding

– (1) the people (end-users) who will

interact with the system through the interface;

– (2) the tasks that end-users must

perform to do their work,

– (3) the content that is presented as part

of the interface

– (4) the environment in which these tasks will be conducted.

59

User Analysis

1. Are users trained professionals, technician, clerical, or manufacturing workers?

2. What level of formal education does the average user have?

3. Are the users capable of learning from written materials or have they expressed a desire for classroom training?

4. Are users expert typists or keyboard phobic?

5. What is the age range of the user community?

6. Will the users be represented predominately by one gender?

60

User Analysis – contd. 7. How are users compensated for the work they

perform?

8. Do users work normal office hours or do they work until the job is done?

9. Is the software to be an integral part of the work users do or will it be used only occasionally?

10.What is the primary spoken language among users?

11.What are the consequences if a user makes a mistake using the system?

12.Are users experts in the subject matter that is addressed by the system?

13.Do users want to know about the technology the sits behind the interface?

61

Task Analysis and Modeling • Task Analysis answers the following questions …

– What work will the user perform in specific circumstances?

– What tasks and subtasks will be performed as the user does the work?

– What specific problem domain objects will the user manipulate as work is performed?

– What is the sequence of work tasks—the workflow?

– What is the hierarchy of tasks?

• Use-cases define basic interaction

• Task elaboration refines interactive tasks

• Object elaboration identifies interface objects (classes)

• Workflow analysis defines how a work process is completed when several people (and roles) are involved

62

Swimlane Diagram pat ient pharmacist physician

r e q u e st s t h at a

p r e scr ip t io n b e r e f ille d

no ref ills

remaining

ch e cks p at ie n t

r e co r d s

d e t e r m in e s st at u s o f

p r e scr ip t io n

ref ills

remaining

ref ill not

allowed

approves ref ill

e v alu at e s alt e r n at iv e

m e d icat io n

none

r e ce iv e s r e q u e st t o

co n t act p h y sician

alternat ive

available

ch e cks in v e n t o r y f o r

r e f ill o r alt e r n at iv e

out of stockr e ce iv e s o u t o f st o ck

n o t if icat io n

r e ce iv e s t im e / d at e

t o p ick u p

in stock

p icks u p

p r e scr ip t io n

f ills

p r e scr ip t io n

Figure 12.2 Swimlane d iagram for prescrip t ion refill funct ion

63

Analysis of Display Content 1. Are different types of data assigned to consistent

geographic locations on the screen (e.g., photos always appear in the upper right hand corner)?

2. Can the user customize the screen location for content?

3. Is proper on-screen identification assigned to all content?

4. If a large report is to be presented, how should it be partitioned for ease of understanding?

5. Will mechanisms be available for moving directly to summary information for large collections of data.

6. Will graphical output be scaled to fit within the bounds of the display device that is used?

7. How will color to be used to enhance understanding?

8. How will error messages and warning be presented to the user?

64

Interface Design Steps

• Using information developed during

interface analysis (SEPA, Section 12.3), define

interface objects and actions (operations).

• Define events (user actions) that will cause

the state of the user interface to change.

Model this behavior.

• Depict each interface state as it will actually

look to the end-user.

• Indicate how the user interprets the state of

the system from information provided

through the interface.

65

Interface Design Patterns

• Patterns are available for

–The complete UI

–Page layout

–Forms and input

–Tables

–Direct data manipulation

–Navigation

–Searching

–Page elements

–e-Commerce www.hcipatterns.org

http://www.hcipatterns.org/

66

Interface Design Issues

• Response time

• Help facilities

• Error handling

• Menu and command labeling

• Application accessibility

• Internationalization

67

Interface Design Evaluation Cycle


Unit IV : Software Testing • Testing Strategies: A strategic Approach to Software Testing, Strategic Issues, Test Strategies for Conventional Software • Testing Strategies for Object Oriented Software • Test Strategies for Web Applications • Validation Testing, System Testing, Validation & Verification, Debugging • Testing Tactics: Black Box Testing, White Box Testing, • Basis Path Testing, Control Structure Testing

2

Software Testing Testing is the process of exercising a program with the specific intent of finding

errors prior to delivery to the end user.

• to uncover errors that were made

inadvertently as it was designed &

developed • any strategy consists of test planning

(efforts & time), test case design, test

execution and resultant data collection & evaluation

• objective is to develop quality

software

3

Software Testing

• A strategy for S/W testing is

developed by project manager, S/W engineers & testing specialists

• Testing often accounts for more

project effort than any other software activity

• Test specifications document is the

output work product which describes test strategy followed, test plan and

tests that will be conducted

4

What Testing Shows

errors

requirements conformance

performance

an indication of quality

5

Who Tests the Software?

developer independent tester

Understands the system

but, will test "gently"

and, is driven by "delivery"

Must learn about the system,

but, will attempt to break it

and, is driven by “quality”

A Strategic approach to S/W testing

All testing strategies have following generic characteristics :

•Conduct FTRs to perform effective testing

• Testing begins “in-the-small” and progresses “to-the-large” •Use appropriate testing techniques • Testing is conducted by developer &

ITG 6

7

Validation vs Verification

Verification – Are we building the

product right?

Is the code correct with respect to its

specification?

Validation – Are we building the right

product?

Does the specification reflect what it should?

8

Testing Strategy

unit test integration test

validation test

system test

9

Testing Strategy

Begin with unit testing and work your way up to system testing.

Unit testing – test individual components (modules in procedural languages; classes in OO languages)

Integration testing – test collections of components that must work together

Validation testing – test the application as a whole against user requirements

System testing – test the application in the context of an entire system

10

Unit Testing

module to be

tested

test cases

results

software engineer

11

Unit Testing

interface

local data structures

boundary conditions

independent paths

error handling paths

module to be

tested

test cases

12

Unit Test Environment

Module

stub stub

driver

RESULTS

interface

local data structures

boundary conditions

independent paths

error handling paths

test cases

13

Integration Testing Strategies

Options:

• the “big bang” approach

• an incremental construction strategy

14

Top Down Integration

top module is tested with stubs

stubs are replaced one at a time, "depth first"

as new modules are integrated, some subset of tests is re-run

A

B

C

D E

F G

15

Bottom-Up Integration

drivers are replaced one at a time, "depth first"

worker modules are grouped into builds and integrated

A

B

C

D E

F G

cluster

16

Regression Testing

The selective retesting of a modified system to help ensure that no bugs

have been introduced during modification.

Fixing one part of the code can break

another

17

High Order Testing

Validation testing Focus is on software requirements

System testing Focus is on system integration

Alpha/Beta testing Focus is on customer usage

Recovery testing forces the software to fail in a variety of ways and verifies that recovery is properly performed

Security testing verifies that protection mechanisms built into a system will, in fact, protect it from improper

penetration

Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume

Performance Testing test the run-time performance of software within the context of an integrated system

18

What is a “Good” Test?

A good test is one that has a high probability of finding an error.

19

Test Case Design

"Bugs lurk in corners and congregate at boundaries ..."

Boris Beizer

OBJECTIVE

CRITERIA

CONSTRAINT

to uncover errors

in a complete manner

with a minimum of effort and time

20

Exhaustive Testing

loop < 20 X

There are 10 possible paths! If we execute one

test per millisecond, it would take 3,170 years to

test this program!!

14

21

Selective Testing

loop < 20 X

Selected path

22

Software Testing

Methods

Strategies

white-box

methods

black-box

methods

23

White-Box Testing

... our goal is to ensure that all statements and conditions have been executed at least once ...

24

Why Cover?

logic errors and incorrect assumptions are inversely proportional to a path's execution probability

we often believe that a path is not likely to be executed; in fact, reality is often counter intuitive

typographical errors are random; it's likely that untested paths will contain some

25

Basis Path Testing

First, we compute the cyclomatic complexity:

number of simple decisions + 1

or

number of enclosed areas + 1

In this case, V(G) = 4

26

Cyclomatic Complexity

A number of industry studies have indicated that the higher V(G), the higher the probability or errors.

V(G)

modules

modules in this range are more error prone

27

Basis Path Testing

Next, we derive the independent paths:

Since V(G) = 4, there are four paths

Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8

Finally, we derive test cases to exercise these paths.

1

2

3 4

5 6

7

8

28

Basis Path Testing Notes

you don't need a flow chart, but the picture will help when you trace program paths

count each simple logical test, compound tests count as 2 or more

basis path testing should be applied to critical modules

29

Black-Box Testing

requirements

events input

output

30

OOT Methods: Behavior Testing

empty

acctopen setup Accnt

set up

acct

deposit(initial)

working

acct

withdrawal(final)

deadacct close

nonworkingacct

deposit

withdrawbalance

credit

accntInfo

Figure 14.3 St at e diagram f or Account class (adapt ed f rom [ KIR94] )

The tests to be designed should achieve all state coverage [KIR94]. That is, the operation sequences should cause the Account class to make transition through all allowable states

UNIT - V

PROJECT MANAGEMENT

CONCEPTS

UNIT V – Project Management Concepts

• Management Spectrum: People, Product

Process, Project,

• Metrics in Process & Project Domains

• Software Measurement Metrics

• Metrics for S/W Quality

• Estimation for Software Projects: Project Planning

Process, Software scope & feasibility, Resources,

Decomposition Techniques

• Empirical Estimation Models

• Estimation for Object Oriented Projects

• Specialized Estimation Techniques

• The Make/Buy Decision

Project Management

• Planning, Monitoring & Control of the

People, Process and Events

• Sr. Manager, Project Manager & Software

Engineers manage the project

• Important since many people work

together for longer period (Cost & Quality)

• 4 Ps - People, Product, Process, Project

• Project Plan is the work product

• Project completion on time with quality &

within budget is the objective of project

management.

The Management Spectrum

1. The People

o Software Engineering work is an

intensely human endeavor.

o “People Factor” is so important that SEI has developed People – CMM model

in recognition of the fact that every

organization needs to continually

improve its ability to attract, develop,

motivate, organize, and retain the

workforce needed to accomplish its

strategic business objectives.


1. The People contd… o Key practices for People – CMM are staffing,

communication and coordination, work

environment, performance management,

training, compensation, competency analysis

and development , career development,

workgroup development, team/culture

development etc.

o People – CMM is a companion to the software

Capability Maturity Model Integration i.e.

CMMI, that guides organizations in the creation

of mature software process.


1. The People contd… o Most important contributor to a successful

software project. Contributors are all

stakeholders, Team Leaders, Project Manager &

software development team.

Stakeholder Taxonomy:

o Senior Managers define business issues

o Project Managers plan, motivate, organize &

control the practitioners

o Practitioners deliver the technical skills

o Customers specify requirements of software

The Management Spectrum 1. The People contd…

o Team Leaders maximize each persons skills &

abilities. Team leader’s abilities [MOI] are : • Motivation: ability to encourage tech. people to

produce to their best ability

• Organization: ability to mold existing processes

• Ideas or Innovation: ability to encourage creativity

o Project Manager – Four keys to be effective

• Problem solving – technical & organizational

• Managerial identity – in-charge, control

• Achievements – to optimize productivity of project

team

• Influence & team building – reading the people,

react to needs of people, handling high stress

situations etc


o Software Team : varies from org. to org. it depends on:

• Management Style of the organization

• Number of people & their skill level

• Complexity of the problem

o Planning the structure of S/W Engg. Team

Following factors are to be considered

• Complexity of the problem

• Size of the problem – LOC or FP

• Team lifetime – staying together

• Degree to which problem can be modularized

• Quality & Reliability of the system

• Delivery dates

• Degree of sociability - communication


o Organizational Paradigms:

• Closed Paradigm – Beurocratic – for repeated

projects

• Random Paradigm – Individual initiative – useful

for innovative projects where tech. breakthrough is

required

• Open Paradigm - mixture of some closed & most

random paradigm – good for complex projects

• Synchronous Paradigm – depends upon natural

compartmentalization of the problem, teams work

on pieces of problems with little active

communication among themselves

• Agile teams – customer satisfaction and early

increment delivery, small highly motivated teams


1. The People contd…

o Communication & co-ordination Issues:

• Very important for successful projects

• Scale, uncertainty & interoperability

• Effective means to coordinate the

people

• Formal / Informal communication

Formal : writing, structured meetings,

e-mails, SMS etc

Informal : personal, share ideas on ad-

voc basis, interact with one-another on

daily basis


2. The Product o Establishment of Product Objectives & Scope

Requirement Engineering which provides information about

estimates of time and cost may take weeks or months, further

requirements may be fluid. At a minimum the scope of the product

must be established & bounded.

o Alternative solutions to problem

o Identification of Technical & Management

constraints

o All above factors will help to define reasonable

estimates of the cost, risk and manageable project

schedule.

o SE + BPE -> Software Requirement Engineering

o Objectives -> Overall Goals of Product

o Scope -> data, function & behavior of product


3. The Process o Appropriate process model to be selected depend

upon following factors:

• Customers & Developers

• Characteristics of product

• Project Environment of S/W team

o A software process provides the framework from

which a comprehensive plan for software

development can be established

o Framework Activities containing number of different

task sets, milestones, work products and Quality

assurance points.

o Umbrella activities like software QA, SCM,

Measurement etc. which occur throughout the

process.


4. The Project o To manage complex software projects,

planning and controlling of them is essential

o For Projects between 1998 to 2004, only 10%

achieve their schedule, cost and quality

o 20 % have overruns below 35 %

o 70 % have major delays and overruns –

terminated without completion.

o Current situation has improved still project

failure rate is much higher.

o To avoid failures, a S/w Project & SEs who

build the product must avoid a set of common

warning signs & understand critical success

factors while planning & monitoring project.


4. The Project- 10 signs of project failure o S/W project people do not understand their

customer needs

o The product scope is poorly understood

o Changes are managed poorly

o The chosen technology changes

o Business needs change or ill defined

o Deadlines are unrealistic

o Users resist to change their mindset

o Sponsorship is lost or was not defined properly

o The project team lacks people with appropriate

skills

o Managers avoid best practices & lessons

learned


4. The Project- 90-90 Rule o First 90% of project absorbs 90% of alloted

time & effort and balance 10% of project takes

another 90% of alloted efforts and time.

o The seeds of 90-90 Rule are contained in the

signs of project failure mentioned above.

o To avoid this problem the way managers

should act is,

• Start on the right foot

• Maintain momentum

• Track progress

• Make smart decisions

• Conduct a postmortem analysis


4. The Project- The W5HH Principle o Why is the system being developed?

- Objectives & Scope (Product)

o What will be done? – Task Set

o When it will be done? – (Project) Schedule

o Who is responsible for a function?

- Role of individual practitioner (People)

o Where are they located organizationally?

- Developer & Customer

o How will be the job be done?

- Technically & Managerially (Processes)

o How much of each resource is needed?

- Esimation

Software Measurement • Measure : Within software engineering context, a measure

provides a quantitative indication of the extent, amount,

dimension, capacity or size of some attribute of a product or

process. Example, Number of errors uncovered within a

single software component

• Measurement : It is an act of determining a measure

Example, When a single data point has been collected, a

measure has been established. For each FTR or unit test,

number of errors uncovered are collected

• Metric : A quantitative measure of the degree to which a system

component or process possesses a given attribute.

Example, A software metric relates the individual measures in

some way, e.g. average number of errors per review or unit

test per component.

• Indicator : Collect measures -> develop metrics -> indicators

Example, Errors uncovered per KLOC

Software Metrics Following are the different types of metrics used in SE :

• Software Process Metrics

• Software Project Metrics

- Size oriented Metrics

- Function oriented (Function Points) based

metrics

- Object Oriented Metrics

- Use-case oriented Metrics

- Web application metrics

• Software Quality Metrics

Software Process Metrics • Process metrics are collected across all projects & over

long periods of time. Their intent is to provide a set of

indicators that lead to long term process improvement.

Examples of process metrics are,

- Errors uncovered per KLOC before release of

software

- Defects reported per KLOC by end users

- Work products delivered per person per month

- LOC per person per month

- Calendar time per KLOC

- Schedule Conformance Index (Plan vs Actual)

Software Project Metrics • Unlike process metrics are used for strategic

(improvement) purposes, software project measures

are tactical.

• Project metrics are used for estimation. By using

project metrics of past projects, estimation for new

projects can be derived (efforts & time)

• Project metrics are used by project manager to

optimize development time & to assess product

quality.

• As quality improves, defects are minimized & as

defects count go down, the amount of rework required

during the project is also reduced. This leads to a

reduction in overall project cost

Software Project Metrics – contd. • Project metrics enable the software project manager,

- assess the status of current project

- track potential risks

- uncover problem areas before they go ‘critical’ - adjust work flow or tasks

- evaluate project team’s ability to control quality of

s/w work products

• Project metrics can be used for process improvement

as well

• Measurements related to projects are, LOC, FP,

efforts, cost, Documentation pages, errors, defects,

people etc.

• Examples – Size oriented metrics (LOC)

Function oriented metrics (FP)

Size oriented Metrics

Following are some of the size oriented metrics for

s/w projects :

• Errors per KLOC

• Defects per KLOC

• Cost per KLOC

• Pages of documentation per KLOC

• Errors per person-month

• KLOC per person-month

• Cost of documentation per page

Size oriented Metrics – contd. Although LOC metric is used & it is quite common,

size oriented metrics are not universally accepted

because of following reasons :

• they are programming language dependent

• when productivity is considered, they penalize

well designed but shorter programs

• they cannot accommodate non-procedural

languages

• estimation of LOC is difficult when much

details are not available before analysis &

design

Function oriented Metrics – (FP) • Function oriented metrics use the functionality

delivered by the application as a normalization value

• FP is most widely used metric in software projects

• Computation of FP is based on characteristics of the

software to be delivered i.e. information domain &

complexity

• FP is programming language independent which

makes it ideal for both procedural & non-procedural

languages, and it is based on data that are most likely

to be known early in the evolution of project. This

makes FP more attractive approach for estimation of

software project

Function oriented Metrics – Drawbacks

Although FP is an attractive approach, it has few

drawbacks:

• It is based on subjective rather than

objective data

• It is difficult to collect counts of

information domain

• FP has no direct physical meaning, it is

just a number

Object Oriented Metrics

For Object Oriented software following metrics are used:

• Number of scenario scripts

• Number of key classes

• Number of support classes

• Average number of key classes / support

classes

• Number of sub-systems

Use-case Oriented Metrics

Following are few of the use-case oriented metrics:

• Number of use cases

• Number of actors in use cases

• Number of secondary actors in use cases

• Number of persistent data objects used in

use-cases

• Number of internal & external interfaces

• Average number of actors per use-case

• Average number of secondary actors per

use-case

Web application Project Metrics

Following are few of the web application project metrics:

• Number of static web pages

• Number of dynamic web pages

• Number of internal page links

• Number of persistent data objects

• Number of classes

• Number of collaborative classes

Metrics for Software Quality

• The overall goal of software engineering is to produce a

high quality system, application or a product within a

time frame that satisfies the customer needs at minimum

cost

• Product metrics are used to evaluate the quality of

software developed i.e. for each framework activity like

Requirement Engineering, Design, Coding, Testing etc.

• Primary thrust at the project level is to measure errors

and defects. Metrics derived from these measures provide

an indication of the effectiveness of individual & group

software quality assurance & control activities


Examples :

• Number of errors uncovered per FP

• Number of errors uncovered per review hour

• Number of errors uncovered per test hour

• Error data can be used to compute Defect

Removal Efficiency i.e. DRE for each

process framework activity


Measurement of software quality :

• Correctness : Defects per KLOC

• Maintainability : Mean Time To Correct the

defects depends upon ease with which program

is corrected

• Integrity : Threats from cyber terrorists &

hackers, integrity = sum of [1 – threat * (1 –

security)]

• Usability : ease in using the program –

minimum input from customer for query &

reports


Defect Removal Efficiency (DRE):

• DRE = E / (E + D)

where E is number of errors found before deployment

and D is number of defects reported after

deployment

• Ideal value of DRE is 1.

PROJECT MANAGEMENT

ESTIMATION FOR SOFTWARE

PROJECTS

ACTIVITIES OF SOFTWARE

PROJECT PLANNING

• After selection of the appropriate software process

and identifying all the tasks in each framework

activity, before starting the project following

major activities are to be performed

- ESTIMATION

– SCHEDULING

– RISK ANALYSIS

– QUALITY MANAGEMENT PLANNING

– CHANGE MANAGEMENT

ESTIMATION - OBSERVATIONS

• Estimation of resources, cost and schedule

for a s/w engineering efforts requires

experience, access to good historical

information (metrics) and the courage to

commit to quantitative predictions when

qualitative information is all that exists.

• Estimation carries inherent risk and this risk

leads to uncertainty.

ESTIMATION - RISKS

• Project Complexity – familiarity with past

efforts

• Project Size – affects the accuracy and

efficacy of estimates

• The degree of structural uncertainty –

degree to which requirements have been

solidified, ease of functional

compartmentalization & hierarchical nature

of information

THE PROJECT PLANNING PROCESS

• The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule.

• Estimates should attempt to define best-case & worst-case scenarios so that project outcomes can be bounded.

• Although there is an inherent degree of uncertainty, the software team attemps to adher to project plan.

• Plan must be adapted & updated as the project proceeds.

Software Scope & Feasibility

• Software Scope : Functions & Feachers to be

delivered to customer, Information Domain,

Contents, Performance, Constraints, Interfaces, &

Reliability that bounds the system. It is defined

using either narrative description after

communication with all stakeholders or by using a

set of use-cases – Decomposition of scope.

• After finalizing the scope feasibility whether such

a system can be developed must be examined.

Infeasible system will lead to project failure.

RESOURCES

• Human Resources – Evaluate s/w scope, decide skills required, team structure, efforts required, location of each human resource, man-months required.

• Reusable Software Resources – COTS, Full- experience components, Partial-experience components, New Components.

• Environmental Resources – SEE incorporates hardware that supports the software tools.

Software Project Estimation

• S/w cost & effort estimation will never be an exact

science because of too many factors like human,

technical, environmental and political. The options

are,

- Delay estimations until late in project

- Base estimates on similar projects completed

- Use decomposition techniques – D&C approach

- Use one or more Empirical Models

d = f(vi) (d – Cost, vi – LOC or FP)

DECOMPOSING TECHNIQUES • S/w project estimation is a form of problem solving.

• To get realistic estimates for a software, one must decompose scope & process

• For each function decide the “size” and add up “size” of each function to get the “size” of the project

• SOFTWARE SIZING :

Four different approaches to decide the “size”

- Fuzzy logic sizing – approx. reasoning

- Function Point sizing – Information Domain

- Standard Component sizing – sub-systems,

modules, screens, reports, interactive

programs, batch programs, files, LOC etc.

- Change sizing – Component Re-use

• Results of these approaches are to be combined to create three-point or expected-value estimate.

Problem-Based Estimation

• Suggested by Putnam and Myers

• Expected value or Three-point value ‘S’, based on Optimistic, Most likely and

pessimistic estimates

S = Sopt + 4Sm + Spess

6

Example of LOC based Estimation

CAD Software

Function Estimated LOC

User Interface & Control Facilities 2300

Two dimensional Geometric Analysis 5300

Three dimensional Geometric Analysis 6800

Database Management 3350

Computer Graphics Display Facilities 4950

Peripheral Control Function 2100

Design Analysis Module 8400

Estimated Lines Of Code 33200

Example of FP based Estimation

SAFE-HOME Security

Inf. Domain Opt.

Value

Most

Likely

Pess.

Value

Est.

Count

Wtg. FP

Point

# External Inputs 20 24 30 24 4 97

# External Outputs 12 15 22 16 5 78

# Extrnal Inquiries 16 22 28 22 4 88

# Internal Logical

Files

4 4 5 4 10 42

# External Interface

Files

2 2 3 2 7 15

COUNT TOTAL 320

Example of FP based Estimation ... Contd.

Estimated Number of FP

= count total * value adjustment factor

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

= 320 * [0.65 + 0.01* 52]

= 320 * 1.17

= 375

Example of FP based Estimation ... Contd. • Calculation of Value Adjustment Factor

FACTOR VALUE

Backup & Recovery 4

Data Communications 2

Distributed Processing 0

Performance Critical 4

Existing Operating Environment 3

Online Data Entry 4

Input Trans. Over Multiple Screens 5

Master Files Updated Online 3

Information Domain value Complex 5

Internal Processing Complex 5

Code Designed for reuse 4

Conversion / Installation in Design 3

Multiple Installations 5

Application Designed for Change 5

Process-Based Estimation

• Estimation is based on the process used, i.e.

the process is decomposed into relatively

small set of tasks & the effort required to

accomplish each task is estimated in terms

of person-months.

• Once problem functions & process activities

are melded, then the effort (person-months)

that will be required to accomplish each

software process activity are estimated

Process-Based Estimation … Contd. Activity -> CC Plannin

g

Risk

Analysis

Reqt. Engg. Constructi

on

C

E

Total

SE Actions-> Anal

ysis

Design Code Test

Functions

1

2

Total

% Effort

Estimation with Use Cases • Use cases provide a s/w team with insight

into s/w scope & requirements. However

estimation based on use-cases is

problematic due to following reasons.

1. No standard form of definition

2. Represent external view of the s/w &

hence can be written at different

abstract levels.

3. Do not address the complexity

4. Involves many functions & features

Empirical Estimation Models • An estimation model for computer software

uses empirically derived formulae to predict

effort as a function of LOC or FP.

• A typical estimation model is derived using

regression analysis on data collected from

past projects. It takes the form :

E = A + B*ev**C

A,B,C are empirical constants, E is efforts

in person-months, ev is estimation variable

(LOC or FP)

Empirical Models

For LOC based Models:

• Walston-Felix Model : E = 5.2 * (KLOC** 0.91)

• Bailey-Basili Model : E = 5.5 + 0.73* (KLOC** 1.16)

• Boehm simple Model : E = 3.2 * (KLOC** 1.05)

• DotyModel for KLOC > 9:

E = 5.288 * KLOC** 1.047

For FP oriented models: • Albrecht & gaffney Model : E = -91.4 + 0.355*FP

• Kemerer Model : E = -37 + 0.96*FP

• For small projectsRegression Model :

E = -12.88 + 0.405*FP

The Make / Buy Decision Decision Tree with Probability of each pat

can be constructed. Min. Cost option is

chosen.

• BUILD – Simple , Difficult

• REUSE : Minor Changes, Major Changes

Major Changes : Simple, Complex

• BUY : Minor Changes, Major Changes

• Contract: Without changes, With Changes

UNIT-VI PROJECT PLANNING

• Project Scheduling: Basic Principles,

Relationships between People & Effort,

• Defining a task set for S/W project, Defining

a task Network, Project scheduling,

• Earned value analysis

• Risk management: Reactive versus proactive

risk, S/W risks, Risk Identification, Risk

Projection

ACTIVITIES OF SOFTWARE

PROJECT PLANNING

• Risk Refinement, Risk Mitigation,

Monitoring & management, RMMM Plan

• Product Metrics: A framework for project

metrics, Software Quality: S/W Quality

factors, Software Configuration Management:

SCM, SCM Repository, SCM Process

PROJECT PLANNING • Once following steps are performed, i.e.

- Selection of appropriate process model

- Identification of the s/w Engg. Tasks

- Estimation of amount of work &

Number of people

- Deadline is known

- Risks are considered

• We create a network of s/w Engg. Tasks

that will enable us to get the job done on

time.

PROJECT PLANNING

• At Project Level planning is done by the

Project Managers using information

solicited from s/w engineers. And at an

individual level, s/w engineers do it.

• It is important because in order to build a

complex system, many s/w engineering.

Tasks occur in parallel and they are related

to another next task(s). These

interdependencies are difficult to

understand without a schedule.

BASIC CONCEPTS

• Few reasons why software projects are delivered late are,

- Unrealistic deadline forced on managers

- Changing customer requirements

- Underestimated efforts and resources

Predictable and/or unpredictable risks

- Technical difficulties unforeseen

- Human difficulties unforeseen

- Miscommunication among project team

- Failure by project management

- Hundreds of small tasks must occur to

accomplish a larger goal. Some of these tasks

lie on “Critical Path”

BASIC CONCEPTS … contd.

• Following steps are recommended

- Perform detailed estimate using historical

data from past projects

- Use incremental iterative process model

- Take customer in confidence & explain him

why the imposed deadline is unrealistic

- Offer incremental development strategy as

an alternative

PROJECT SHEDULING • Software projects fall behind schedule because

of “One day delay at a time”

• To avoid this, the objective of project manager is to define all project tasks, build a network, and then track their progress to ensure that delay is recognized “one day at a time”

• There are two s/w project scheduling perspectives,

1. End date is already established

2. End date is set by the s/w engineering

organization after discussing rough

chronological bounds.

Project Scheduling – Basic Concepts • Following basic principles guide s/w project

scheduling

1. Compartmentalization – Activities & Tasks

2. Interdependency - Activities & Tasks

3. Time allocation – person-days of effort

4. Effort validation – No more than the

allocated number of people at any point of

time

5. Defined responsibilities – defined outcome

6. Defined Outcomes for every task

7. Defined milestones

Project Scheduling – The relationship

Between People & Effort • For small projects may be only one person is

performing all the tasks of the project, whereas for large projects many people may be working for that project.

• Misbelief: “If we fall behind schedule, we can always add more programmers and catch up later in the project”. Fact is adding more people later further delays the project

• More people means more communication paths which increases the complexity of communication

• Project schedules are elastic : It is possible to compress a desired completion date by increasing resources to some extent and vice-versa.


Between People & Effort … contd. • The Putnam-Norden-Rayleigh (PNR) Curve

It provides an indication of relationship

between effort applied and delivery time for

a software project

Ea = m*(td / ta)**4

Ea = Effort in person-months

td = Nominal Delivery time for schedule

to = Optimal Developent time

ta = Actual Delivery time desired

tmin = 0.75 td (delivery time cannot be stretched beyond this

to = 2td = Optimal Delivery time (Project Cost optimal)


Between People & Effort … contd. Software Equation:

L = P*(E**(1/3))*(t**4/3)

where L is LOC

P = Productivity parameter

E = effort in person-years

t = project duration in months

i.e. E = (L**3)/((P**3)*(t**4))

For L = 33000, E = 12 person-years, t = 12

For 8 people – 1.3years, for t= 1.75 E = 3.8p-y

Effort Distribution: 40-20-40 Rule

Analysis & Design – 40 %

Construction - 20 %

Testing - 40 %

Defining a Task Set for the Software

Project • Regardless of the process model that is chosen,

the work that a s/w team performs is achieved

through a set of tasks that enable you to define,

develop and ultimately support computer

software.

• No single task set is appropriate for all

projects.

• The set of tasks appropriate for a large

complex project may overkill for a small,

relatively simple project.

• Task sets should meet the needs of different

types of projects.


Project … contd. • A task set is collection of s/w engineering

work tasks, milestones, work products and

quality assurance filters that must be

accomplished to complete a particular

project.

• In order to develop a project schedule, a

task set must be distributed on the project

time line. It depends upon the type of

project.

Types of projects

1. Concepts development projects : to explore new

business concept or application of some new tech.

2. New application development projects: Specific

customer request.

3. Application enhancement projects: major

modifications to function, performance or

interfaces that are observable by the end user.

4. Application maintenance projects: to correct, or

extend existing software.

5. Reengineering projects: to rebuild the existing

legacy system.

A Task Set Example

Project : Concept Development Project

1. Concept Scoping: determines the overall scope

2. Preliminary concept Planning: establishes the

organization’s ability to undertake the work

3. Technology Risk Assessment: Evaluates the risk

associated with the technology to be implemented

4. Proof of Concept: demonstrates the practcability of a

new technology in the software context

5. Concept Implementation: working representation of

the concept for the review by the customer

6. Customer reaction to the concept: feedback on new

technology concept and targets specific customer

application.

Refinement of s/w engineering actions

• S/W engineering actions defined can be

used to create macroscopic schedule for a

project. However the macroscopic schedule

must be refined to create a detailed project

schedule.

• Refinement of actions help in estimation of

work accurately.


Engineering Action

• Example : Concept Scoping

1. Identify need, benefits and potential

customers

2. Define desired output/control and input events

3. Define functionality/behavior for each major

function

4. Isolate those elements of technology to be

implemented in software

5. Research availability of existing software

6. Define technical feasibility

7. Make quick estimate of size

8. create a scope definition

Defining a Task Network

• Individual tasks and subtasks have

interdependencies based on their sequence

• More than one person is involved in a s/w

engineering project, it is likely that

development activities and tasks will be

performed in parallel

• Concurrent tasks must be coordinated so

that they will be complete when later tasks

require their work product(s)

Defining a Task Network … contd. • A task Network, also called as Activity

Network is a graphic representation of the task

flow for a project

• Example : Concept Development Project

Concept Scoping

Concept Planning

Tech Risk assessment – 3 in parallel

Proof of concept

Concept Implementation – 3

Integration

Customer reaction

SCHEDULING

• Program Evaluation and Review Technique

(PERT) and Critical Path Method (CPM) can

be applied for the scheduling of s/w

engineering projects too

• Both techniques are driven by

- Information available from past projects

- Estimation of efforts

- Decomposition of product functions

- The selection of appropriate process

- Task set

- Decomposition of the tasks

SCHEDULING … contd. • Interdependencies among tasks may be defined using

task network

• Tasks sometimes called the project Work Breakdown

Structure (WBS) are defined for the product as a whole

or for individual function

• Both PERT & CPM provide quantitative tools that

allow you

1. Determining critical path – duration of project

2. determine “most likely” time estimates for tasks

3. Calculate “boundary times” – time window

Time-line chart or Gantt Chart

Project schedule can be generated once

WBS as a task network is ready. Effort,

duration and start date is also input.

PERT/CPM generates time chart

Work Tasks Week 1 Week 2

Week 3

Week 4

Week 5

1.1

1.1.1

1.1.2

Project Table

Work

Task

Planned

Start

Actual

Start

Planned

Compl.

Actual

Compl.

Assigned

person

Effort

Allocate

Notes

1.1

1.1.1

1.1.2

1.1.3

Tracking the schedule

• If project schedule has been properly developed, it

becomes a road map that defines the tasks and milestones

to be tracked and controlled as the project proceeds.

• Tracking can be accomplished by number of ways:

1. Conducting periodic project status meetings

2. Evaluating the results of all reviews conducted

3. Determining whether formal project milestones

have been accomplished

4. Comparing actual start with planned start date

5.By subjective assessment – meeting practitioners

informally.

6. Using Earned Value Analysis

Earned Value Analysis

• It is quantitative measure to monitor the

progress of a project

• It enables you to assess the “percent of

completeness” of a project using

quantitative analysis rather than rely upon

on subjective information (gut feeling)

• To determine the Earned Value following

steps are performed

Earned Value Analysis … contd. 1. BCWS : Budgeted Cost of Work Schedule:

BCWSi is determined for each task (i) during

estimation. To determine progress at a given

point of time along the project schedule, the value

BCWS = sum of the BCWSi, values for all work

tasks that should have been completed by that

point in time on the project schedule

2. BAC : Budget At Completion

BAC = sum of all BCWS for all tasks in project

3. BCWP : Budgeted Cost of Work Performed

BCWP = sum of all BCWS for all tasks that have

actually been completed

Earned Value Analysis … contd. • SPI : Schedule Performance Index

SPI = BCWP / BCWS indicates efficiency with

which the project is utilizing scheduled resources, SPI = 1

means efficient execution of project schedule.

• SV : Schedule Variance

SV = BCWP – BCWS gives absolute indication

• Percent Scheduled for Completion

= BCWS / BAC indicates percentage of work

that should have been completed

• Percent Complete = BCWP / BAC gives % complete at a given point

of time

Earned Value Analysis … contd. • ACWP : Actual Cost of Work Performed

ACWP = sum of the effort actually expended on work

tasks that have been completed by a point in

time on the project schedule

• CPI : Cost Performance Index

CPI = BCWP / ACWP CPI = 1 indicates that

project is within it’s defines bugget

• CV : Cost Variance

CV – BCWP – ACWP indicates cost saving

Earned Value Analysis - Example

• Assume you are a software project manager

and that you have been asked to compute

earned value statistics for a small software

project. The project has 56 planned work

tasks that are estimated to require 582

person-days to complete. At the time that

you have been asked to do the earned value

analysis, 12 tasks have been completed.

However the project schedule indicates that

15 tasks should have been completed. The

following scheduling data (in person-days)

are available:

Earned Value Analysis – Example … contd

TASK PLANNED EFFORT ACTUAL EFFORT 1 12.0 12.0

2 15.0 11.0

3 13.0 17.0

4 08.0 09.5

5 09.5 09.0

6 18.0 19.0

7 10.0 10.0

8 04.0 04.5

9 12.0 10.0

10 06.0 06.5

11 05.0 04.0

12 12.0 14.5

13 16.0

14 06.0

15 08.0

Earned Value Analysis – Example … contd

• Compute the SPI, Schedule Variance,

Percent scheduled for completion, percent

complete, CPI and cost variance for the

project.

Software Configuration Management (SCM)

WHAT is SCM?

• When you build computer software, Change

happens. And because it happens, you need to

manage it effectively.

• SCM, also called as Change Management, is a set of

activities designed to manage change which consists

of,

- Identifying work products that are

likely to change

- Establishing relationships among them

- defining mechanisms for managing

different versions of these work

products

- Controlling the changes imposed

- Auditing & reporting on the changes made

Software Configuration Management (SCM) … contd

Who does it?

• Everyone involved in the software process is

involved with change management to some extent,

but specialized support positions are sometimes

created to manage the SCM process.

Why is it important?

• It is important because if you don’t control change, it

controls you which is never good. Uncontrolled

changes do turn a well-run software project into

chaos. Hence SCM is an essential part of quality

management.

What is the work product?

• SCM plan is the work product. SCM process generates

the change requests, reports and change orders.


What are the steps?

• Many work products like system specifications,

software requirements, analysis model, design

specifications source code, test plans, test

procedures, test data, operational system etc. are

produced when software is built and each must be

uniquely identified.

• Once these work products are base lined, mechanism

for version and change control can be established.

• To ensure that quality is maintained as changes are

made, the process is audited

• All concerned are informed about the changes i.e.

reporting is done.


• Software Configuration Consists of,

- Computer Programs (Source + Executables)

- Work products that describe computer programs

- Data or content internal or external to programs

• Origin of Changes:

- Changes in requirements by customer

- Changes by developers as they know more

details about the system

- New business or market conditions

- New stakeholder’s demands of information

- Reorganization or Business growth

- Budgetary or Scheduling constraints

SCM - Elements of Configuration Mgmt. System

• Elements of Configuration Mgmt. System

- Component Elements – set of tools coupled within a

file management system e.g. database that enables

access to and management of each software

configuration item.

- Process elements – collection of actions and Tasks

that define an effective approach to change

management for all constituencies involved in the

management, engineering and use of computer

software i.e. project management, software

engineering and customers.

- Construction elements – set of tools that automate

the construction of software e.g. compilers

- Human elements – set of tools & process features used

by the software team to implement effective SCM

SCM - Baseline

• Baselines:

- Change is a fact of life in software development.

Customers want to modify requirements,

Developers want to modify the technical

approach, & Managers want to modify project

strategy

- This happens because as time passes , all

constituencies know more about what they need.

- A Baseline is a software configuration

management concept that helps you to control

change without seriously impeding justifiable

change

SCM - Baseline… contd

• Baseline contd.

- Before a software configuration item (SCI –

information created as part of s/w engg. process)

becomes a baseline , changes may be done

quickly & informally. However once a baseline

is established, changes can be made , but a

specific, formal procedure must be applied to

evaluate & verify each change.

- Examples of baselines:

-System specifications, Software

requirements, Design specifications, Source

code, Test plans/Procedure/Data, Operational

system

SCM – Software Configuration Items

• Software Configuration Item (SCI) is

defined as information that is created as part

of the software engineering process.

• SCI could be considered to be a single

section of a large specification or one test

case in a large suite of tests

• SCI is all or part of work product e.g. a

document, an entire suite of test cases, a

named program component, software tools

like editors, compilers, browsers etc.

SCM – Software Configuration Items … contd.

• In reality SCIs are organized to form

configuration objects that may be cataloged

in the project database with single name

• Configuration object has a name, attributes,,

and is connected to other objects by

relationship

• Examples are, DesignSpecification,

DataModel, ComponentN, SourceCode,

TestSpecification etc.

• Single arrow -> Compositional relationship

• Double arrow -> Interrelationship

SCM - REPOSITORY

• Earlier in SE, SCIs were maintained as paper

documents or punched computer cards. This

approach was problematic for many reasons:

1. Locating SCI when needed was difficult

2. Finding which SCIs are changed when &

by whom was often challenging

3. Constructing a new version of an

existing program was time consuming

4.Describing detailed or complex relationships

between SCIs was virtually impossible

• Today, SCIs are maintained in Project Database or

Repository ( Refer diagram)

SCM – REPOSITORY - Role • The SCM repository is the set of mechanisms and data

structures that allow a software team to manage change in

an effective manner.

• It provides the obvious functions of a modern DBMS by

ensuring data integrity, sharing, and integration

• It provides a hub for the integration of software tools

• It is central to the flow of software process

• It enforces uniform structure and format for software

engineering products

• To achieve these capabilities, the repository is defined in

terms of meta-model. The meta-model determines how

information is stored in the repository, and how data can

be accessed by tools and viewed by software engineers

SCM – REPOSITORY - Contents

• Business contents : Business Rules, Business functions,

Organizational structure, Information architecture

• Project Management contents : Project estimates, Project

schedule, SCM requirements (Change requests, Change

reports), SQA requirements, Project report, Audit reports,

Project metrics

• Model Contents : Analysis Model, Design Model,

Technical metrics

• Construction contents : Source code, Object code, System

build instructions

• V & V content : Test cases, Test scripts, Test results,

Quality metrics

• Documents : Project plan, SCM/SQA plan, System specs,

Requirement specs, Design document, Test plan &

procedure, Support documents, User manual

SCM – REPOSITORY - Features • To support SCM, the repository must have tool set

that provides support for the following features:

1. Versioning - version control of products

2. Dependency Tracking & Change Management

- dependency among data elements

3. Requirement Tracing - forward tracing

- Backward tracing

4. Configuration Management

- keeps track of production releases

5. Audit Trails

- when, why and by whom changes are made

SCM – Process The software configuration process defines following

Objectives of SCM Process:

1. to identify all items that collectively define the

software configuration

2. to manage changes to one or more of these items

3. to facilitate the construction of different versions of

an application

4. to ensure that software quality is maintained as

configuration evolves over time.

Layers of SCM Process:

i) SCIs of version Vm.n,

ii) Identification

iii) Change control

iv) Version control

v) Configuration auditing

vi) Reporting

SCM – Process – Identification of objects

• To control and manage SCIs, each should be separately

named and then organized hierarchically using an object

oriented approach

• Two types of objects can be identified, Basic objects and

Aggregate objects

• Basic object might be a section of a requirement

specification, part of a design model, source code for a

component or suite of test cases that are used to exercise

the code.

• An aggregate object is a collection of basic objects, for

example DesignSpecification.

• Object identification can also consider the relationships

that exist between named objects.

SCM – Process – Version Control

• Version control combines procedures and tools to

manage different versions of configuration objects that

are created during the software process

• The version control system implements or is directly

integrated with four capabilities: 1. A project data base (repository) that stores all relevant

configuration objects

2. A version management capability that stores all versions of a

configuration object or enables any version to be constructed

using differences from past versions

3. A make facility that enables you to collect all relevant

configuration objects and construct a specific version of the

software.

4. It implements issue tracking capability that enables the team

to record and track the status of all outstanding issues

associated with each configuration object

SCM – Process – Change Control

The change control process consists of:

1. Need for change is recognized

2. Approval from Change control authority Change

request from user

3. Change request is evaluated by developer

4. Change report is generated

5. Approval from change control authority is sought

6. If not approved change request is denied and user is

informed about the same – stop –

7. Change request is queued for action by generating

Engineering Change Order (ECO)

8. Assign individuals to configuration objects

9. “check out” configuration objects (SCIs)

10. Make the changes

SCM – Process – Change Control

The change control process consists of:

11. Review (Audit) the change

12. “check in” the configuration items to project database that have been changed

13. Establish a baseline for testing

14. Perform QA and testing activities

15. “promote” changes for inclusion in next release (revision)

16. Rebuilt appropriate version of software

17. Review (audit) the change of all configuration items

18. Include changes in new version

19. Distribute the new version

SCM – Process – Configuration Audit

How can a software team ensure that the change has been

properly implemented?

The answer is twofold:

1. Technical Reviews

2. The software configuration audit

Technical Reviews: Technical review focuses on the

technical correctness of the configuration object that has been

modified. The Reviewers assess the SCI to determine

consistency with other SCIs, omissions or potential side

effects. The technical review should be conducted for all but

the most trivial changes

The software configuration audit: It complements the

technical review by assessing a configuration object for

characteristics that are generally not considered during review.

SCM – Process – Configuration Audit

Configuration Audit checks for the following:

1. Whether Changes are made as specified in ECO. Are

there any additional modifications incorporated?

2. Whether technical review has been conducted to assess

the technical correctness

3. Whether software process has been followed and

software engineering standard have been properly

applied

4. Whether the change has been “highlighted” in the SCI

and change date and change author has been specified

5. Whether all related SCIs been properly updated.

SCM – Process – Status reporting

• Configuration “status reporting”, sometimes called as “status

accounting” is an SCM task that answers the following

questions.

1. What happened?

2. Who did it?

3. When did it happen?

4. What else will be affected?

• The flow of information for configuration status reporting

is illustrated in steps followed in “change control process”.

At every stage completion CSR entry is made

• CSR report is generated on a regular basis to keep

management and practitioners appraised of important

changes.

Risk Management • What is it?

Risk analysis and management are actions that help a

software team to understand and manage uncertainty.

Many problems can occur in a software project. A risk is

a potential problem which may or may not occur. But

regardless of the outcome, it is really a good idea to

identify it, assess its probability of occurrence, estimate

its impact, and establish a contingency plan in case the

problem actually occurs.

• Who does it?

Everyone involved in software process – managers,

software engineers, and other stakeholders participate in

risk analysis and management.

Risk Management

• Why it is important?

Software is a difficult undertaking. Lots of things can

go wrong, and frankly many often do.

• Who does it?

Everyone involved in software process – managers,

software engineers, and other stakeholders participate

in risk analysis and management. Therefore it is

always better to “be prepared” i.e. understanding the

risks and taking proactive measures to avoid or

manage them. It is a key element of good software

project management.

Risk Management • What are the steps?

1. Recognition or Identification of what can go wrong.

2. Analysis of risks to determine probability of their

occurrence and their impact

3. Ranking of the risks by probability and impact

4. Development of a plan to manage and monitor those risks

that have high probability and high impact.

• What is the work product?

A Risk Mitigation, Monitoring, and Management plan (RMMM)

or a set of Risk Information Sheets is prepared.

• How to ensure that I have done it right?

The risks that are analyzed and managed should be derived from

thorough study of the People, the Product, the Process, and the

Project. The RMMM should be revisited as the project proceeds to

ensure that risks are kept up to date. Contingency plans for risk

management should be realistic

Risk Strategies - (Reactive vs Proactive)

• Reactive strategy for risk management means software

team does nothing until something goes wrong.

Whenever those risks occur, the team enters in “fire-

fighting mode” to correct the problem rapidly. At the

best it can be similar to “disaster management” –

monitoring the likely risks and keeping some resources

reserved to overcome the problems when they arise.

• Proactive strategy for risk management begins long

before technical work is initiated. Potential risks are

identified, their probability and impact are assessed, and

they are ranked by importance. Then software team

establishes a plan for managing risk. The primary

objective is to avoid risk, but all risks cannot be avoided.

The team works to develop a contingency plan.

Software Risks Following are the categories of software risks:

• Project Risks threaten the project plan causing the

project schedule to slip and increase in project cost.

They are associated potentially with budget, schedule,

personnel (staffing and organization), resources,

stakeholders and requirement problem and their impact

on software project.

• Technical Risks threaten the quality and timeliness of

the software to be produced which may lead to

implementation of the software impossible. They are

associated potentially with technical uncertainty,

specifications, design, implementation, interface,

verification, and maintenance problems. They occur

because the problem is harder to solve than you thought

it would be.

Software Risks • Business Risks threaten the viability of the software to

be built and often jeopardize the project or the product.

Top FIVE business risks are,

1. Market risks – excellent product but no one

wants it

2. Strategic risks – product no longer fits into any

business strategy of the organization

3. Sales risks – sales force does not understand

how to sell the product

4. Management risks – loosing the support of

senior management due to change in focus or

change in people

5. Budget risks – loosing budgetary or personnel

commitment

•

Software Risks It should be noted that simple categorization of risks will

not help since some risks are unpredictable: another

general categorization of risks proposed by Charette is,

• Known Risks that can be uncovered by the careful

evaluation of the project plan, the business and technical

environment in which the project is being developed,

and other reliable information sources like unrealistic

delivery date, lack of documented requirements or

software scope, poor development environment

• Predictable risks are extrapolated from past project

experience e.g. staff turnover, poor communication

with customer, dilution of staff effort as ongoing

maintenance request are serviced.

• Unpredictable risks do occur but they are extremely

difficult to identify in advance

Risk Identification

There are two distinct types of risks for each category of

risk:

• Generic risks are a potential threat to every software

project

• Product-specific risks can be identified only by those

with a clear understanding of the technology, the

people, and the environment that is specific to the

software that is to be built. To identify product-specific

risks, the project plan and the scope statement are

examined with the intention to find out any special

characteristics of the product to be built may threaten

the project plan.

Risk Identification Method of identifying the risks :

Create a risk item checklist which can be used for identifying

by using generic checklist for known and predictable risks

w.r.t. following sub-categories

• Product size – overall size of the product to be built

• Business impact – constraints imposed by management

or marketplace.

• Stakeholder characteristics - communication

• Process definition – software process definition

• Development environment – availability and quality of

tools to be used

• Technology to be built – complexity of the system to be

built and “newness” of the technology

• Staff size and experience – Technical and project

experience

Assessing Overall Project Risk The success of project depends on following factors which

are ordered by their relative importance:

1. Whether Software & Customer top managers are

committed to support the project

2. Whether End users enthusiastically committed to the

project

3. Whether requirements are fully understood by

developers and customers

4. Whether customers have been involved fully in the

definition of requirements

5. Whether end-users have realistic expectations

6. Whether project scope is stable

7. Whether software engineering team have the right mix

of skills

8. Whether project requirements are stable

Assessing Overall Project Risk – contd.

9. Whether the project team have the experience with the

technology to be implemented

10. Whether the project team size is adequate

11. Whether all customer / user constituencies agree on the

importance of the project and on the requirements for

the system / product

Risk Components and Drivers

The project manager should identify the risk drivers that affect

software risk components. Following are the risk components:

• Performance risk – the degree of uncertainty that the

product will meet its requirements and be fit for its

intended use

• Cost risk - the degree of uncertainty that the project

budget will be maintained

• Support risk - the degree of uncertainty that the

resultant software will be easy to correct, adapt, and

enhance

• Schedule risk - the degree of uncertainty that the

project schedule will be maintained and the product will

be delivered on time

Risk Components and Drivers

• The impact of each risk driver on the risk component is

divided into one of four categories – negligible,

marginal, critical or catastrophic:

• For each risk driver the impact category is chosen based

on the characterization (Ref Fig. 28.1, 7th edition, page

no 750) of the potential consequences of undetected

software errors or faults – Row number 1 or a failure to

achieve a desired outcome – Row number 2, that best

fits the description given in the table.

• This will help to prioritize the risks so that resources

can be allocated to them where impact is more

Developing a Risk Table

The risk table is developed for all the identified risks in

following format:

* Impact values : 1 – catastrophic

2 – critical

3 – marginal

4 - negligible

Sr. No.

Risks Category Probability Impact * RMMM

1 Size estimate

low

PS 60 % 2

2 Less reuse

than planned

PS 30 % 3

3 End users

resist system

BU 40 % 2

4 Staff turnover

will be high

ST 60 % 2

Risk Projection - Developing a Risk Table

Steps for prioritization:

1. The risk table is sorted in descending order of

probability and impact.

2. High probability and high impact risks percolate at the

top of the table and low probability and low impact

risks drop to the bottom of the table.

3. Then cut off line is drawn at some point in the table

implies that only risks that lie above the line will be

given further attention. Risks that fall below the line are

revaluated to accomplish second-order prioritization

4. Pareto principle (80:20 rule) may be used to draw a cut

off line

Risk Projection – Assessing Risk Impact

Risk Exposure (RE):

RE = P * C

where P is the probability of occurrence for a risk, and

C is the cost to the project should the risk occur

Example,

Risk identification : only 70% of the scheduled reusable

components can be integrated into the application. The rest

will have to be custom developed

Risk probability : 80 %

Risk Impact : 60 software reusable components were planned

Therefore 18 components must be developed

Average size per component = 100 LOC

Cost per LOC = Rs. 200

RE = P*C = 0.70* 18*100*200 = Rs. 252000

Risk Refinement

• During early stage of project planning, a risk may be

stated quite generally. As time passes and more is

learned about the project and the risk, 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 refinement is to represent the risk in

condition-transition-consequence [CTC] format:

Given that <condition> then there is a concern that

(possibly) <consequence> Example, Given that all reusable software components must conform to specific

design standards and some do not conform then there is concern that only 70

% of the planned reusable components may actually be integrated into the

system resulting in the need to custom engineer the remaining 30 % of

components.

Risk Refinement

This general condition can be refined in the following manner

• Sun-condition 1: Some reusable components were

developed by third party with no knowledge of internal

design standards

• Sun-condition 2: The standards for component

interfaces has not been solidified and may not conform

to certain existing reusable components

• Sun-condition 3: Certain reusable components have

been implemented in a language that is not supported on

the target environment

The consequences associated with these refined subconditions

remain the same (i.e. 30 % must be customized), but the

refinement helps to isolate the underlying risks and might lead

to analysis and response.

Risk Mitigation, Monitoring , and Management

•All the risk analysis activities presented to this point

have a single goal – to assist the project team in

developing a strategy for dealing with risk.

•An effective strategy must consider three issues : risk

avoidance (Mitigation), risk monitoring and risk

management

• If software team adopts a proactive approach to risk,

avoidance is always the best strategy. This is achieved

by developing a plan for risk mitigation

Risk Mitigation Example

For Example, assume that high staff turnover is noted as project risk r1, let

p1 be the probability of its occurrence = 0.70 and the impact projected as

critical. i.e. high turnover will have a critical impact on project cost and

schedule

To mitigate this risk project manager would develop a strategy for reducing

turnover. Possible steps are,

• Find out causes of turnover from existing staff – poor working

conditions, low pay, competitive job market

• Mitigate those causes that are under your control before project

starts

• Develop techniques to ensure continuity of project when people

leave

• Organize project teams so that information about each development

activity is widely dispersed

• Ensure all models & documents are developed in timely manner

• Conduct peer reviews so that more than one person knows about the

developments

• Assign a backup staff member for every critical technologist

Risk Monitoring

As the project proceeds Risk Monitoring activities commence.

The project manager monitors factors that may provide an

indication of whether the risk is more or less likely. In case of

staff turnover example, following factors are monitored ;

•The general attitude of team members based on project

pressures

•The degree to which the team has jelled

• Interpersonal relationships among team members

•Potential problems with compensation and benefits

•Availability of jobs within the company & outside it

In addition to monitoring these factors, a project manager

should monitor the effectiveness of risk mitigation steps.

Risk Management & Contingency Plan

Risk management & contingency planning assumes that

Mitigation efforts have failed and that the risk has become a

reality. Continuing with the above example, when many

people announce that they will be leaving. If the mitigation

strategy has been followed,

• Backup is available

• Information is documented

• Knowledge is dispersed across the team

In addition, project manager can temporarily refocus

resources and adjust the project schedule. Those individuals

who are leaving are asked to stop all work and spend their last

weeks in “knowledge transfer mode” by conducting meetings

with other members of the team.

RMMM – impact on project cost

•Risk Mitigation, Risk Monitoring and Risk

Management (RMMM) steps incur additional project

cost. Therefore it is important to see that benefits

accrued by RMMM steps are outweighed by the costs

associated with implementing them.

•For a large project, 30 to 40 risks may be identified. If

between 3 to 7 risk management steps are identified for

each risk, risk management may become a project itself!

•Therefore one should adapt the Pareto 80-20 rule to

software risk. Experience indicate that 80 % of the

impact of the overall project risks (i.e. 80 % of the

potential of project failure) can be accounted for by only

20 % of the identified risks (e.g. risks that lead to the

highest risk exposure). This approach will lead to keep

RMMM steps overheads to 3 to 5 % of the project cost.

The RMMM Plan

•Risk Management strategy can be included in the

software project plan or the risk management steps can

be organized into a separate RMMM plan

•The RMMM plan documents all work performed as part

of risk analysis and is used by the project manager as

part of the overall project plan.

•Sometimes formal RMMM document is not prepared,

rather each risk is documented individually using Risk

Information Sheet [RIS] which is maintained on

computer using database system so that creation,

information entry, priority ordering, searching and other

analysis can be accomplished easily. (Refer Fig. 28.4 on

page 758 of 7th edition of a test book)

The RMMM Plan

• Risk Information Sheet [RIS] contains the following

information :

1. Risk-id, Date, Probability and Impact category

2. Risk description

3. Refinement/context details

4. Mitigation / Monitoring details

5. Management / Contingency plan

6. Current status