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
Software Engineering
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
Software Engineering
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
work tasks work products QA points milestones
framework activity #2
SE action #2.1
task sets
work tasks work products QA points milestones
SE action #2.2
task sets
work tasks work products QA points milestones
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
Principles of Agility
•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
Principles of Agility
•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
Software Engineering
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?
Asking the First Questions – Contd.
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?
Asking the First Questions – Contd.
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
Collaborative Requirement Gathering
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
Collaborative Requirement Gathering
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
Flow-Oriented Modeling
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
Flow-Oriented Modeling
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
collaborat ion diagrams
design class realizat ions
subsyst ems
collaborat ion diagrams
ref inement s t o:
deployment diagrams
class diagrams
analysis packages
CRC models
collaborat ion diagrams
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
design class realizat ions
subsyst ems
collaborat ion diagrams
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
66
Interface Design Issues
• Response time
• Help facilities
• Error handling
• Menu and command labeling
• Application accessibility
• Internationalization
67
Interface Design Evaluation Cycle
Software Engineering
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.
The Management Spectrum
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.
The Management Spectrum
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
The Management Spectrum 1. The People contd…
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
The Management Spectrum 1. The People contd…
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
The Management Spectrum
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
The Management Spectrum
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
The Management Spectrum
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.
The Management Spectrum
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.
The Management Spectrum
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
The Management Spectrum
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
The Management Spectrum
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
Metrics for Software Quality
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
Metrics for Software Quality
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
Metrics for Software Quality
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.
Project Scheduling – The relationship
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)
Project Scheduling – The relationship
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.
Defining a Task Set for the Software
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.
Defining a Task Set for the Software
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.
Software Configuration Management (SCM) … contd
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 Management (SCM) … contd
• 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