Software Engineering Notes
Software Engineering Notes
UNIT - I:
Introduction to Software Engineering: The evolving role of software, Changing Nature of
Software, Software myths.
A Generic view of process: Software engineering- A layered technology, a process
framework, Process patterns, process assessment.
Process models: The waterfall model, Incremental process models, Evolutionary process models, The Unified
process, Agility and Agile Process model, Extreme Programming, Other process models of Agile Development
and Tools
UNIT - II:
Software Requirements: Functional and non-functional requirements, User requirements, System
requirements, Interface specification, the software requirements document.
Requirements engineering process: Feasibility studies, Requirements elicitation and
analysis, Requirements validation, Requirements management.
System models: Context Models, Behavioral models, Data models, Object models, structured methods. UML
Diagrams.
UNIT - III:
Design Engineering: Design process and Design quality, Design concepts, the design model.
Creating an architectural design: Software architecture, Data design, Architectural styles
and patterns, Architectural Design.
Object-Oriented Design: Objects and object classes, An Object-Oriented design process,
Design evolution.
Performing User interface design: Golden rules, User interface analysis and design,
interface analysis, interface design steps, Design evaluation.
UNIT - IV:
Testing Strategies: A strategic approach to software testing, test strategies for conventional software, Black-
Box and White-Box testing, Validation testing, System testing, the art of Debugging.
Product metrics: Software Quality, Metrics for Analysis Model, Metrics for Design Model, Metrics for source
code, Metrics for testing, Metrics for maintenance.
Metrics for Process and Products: Software Measurement, Metrics for software
quality.
UNIT - V:
Risk management: Reactive vs. Proactive Risk strategies, software risks, Risk identification,
Risk projection, Risk refinement, RMMM, RMMM Plan.
Quality Management: Quality concepts, Software quality assurance, Software Reviews,
Formal technical reviews, Statistical Software quality Assurance, The Capability Maturity
Model Integration (CMMI), Software reliability, The ISO 9000 quality standards.
TEXT BOOKS :
1. Software Engineering A practitioner’s Approach, Roger S Pressman,
6th edition. McGrawHill International Edition.
2. Software Engineering, Ian Sommerville, 7th edition, Pearson education.
SOFTWARE ENGINEERING
UNIT-I
INTRODUCTION TO SOFTWARE ENGINEERING
Software: Software is
Instructions (computer programs) that provide desired features, function, and performance, when
executed
Data structures that enable the programs to adequately manipulate information,
Documents that describe the operation and use of the programs.
Characteristics of Software:
Software is developed or engineered; it is not manufactured in the classical sense.
Software does not ―wear out‖
Although the industry is moving toward component-based construction, most software continues
to be custom built.
Software Engineering:
The systematic, disciplined quantifiable approach to the development, operation and maintenance
of software; that is, the application of engineering to software.
The study of approaches as in (1)
The role of computer software has undergone significant change over a span of little more than 50 years
Dramatic Improvements in hardware performance
Vast increases in memory and storage capacity
A wide variety of exotic input and output options
Page 1
SOFTWARE ENGINEERING
Later 1990s:
Yourdon reevaluated the prospects of the software professional and suggested ―the rise
and resurrection‖ of the American programmer.
th
The impact of the Y2K ―time bomb‖ was at the end of 20 century
2000s progressed:
Johnson discussed the power of ―emergence‖ a phenomenon that explains what happens when
interconnections among relatively simple entities result in a system that ―self-organizes to form
more intelligent, more adaptive behavior‖.
Yourdon revisited the tragic events of 9/11 to discuss the continuing impact of global terrorism
on the IT community
Wolfram presented a treatise on a ―new kind of science‖ that posits a unifying theory
based primarily on sophisticated software simulations
Daconta and his colleagues discussed the evolution of ―the semantic web‖.
Today a huge software industry has become a dominant factor in the economies of the industrialized world.
The 7 broad categories of computer software present continuing challenges for software engineers:
System software
Application software
Engineering/scientific software
Embedded software
Product-line software
Web-applications
Artificial intelligence software.
System software: System software is a collection of programs written to service other
programs. The systems software is characterized by
heavy interaction with computer hardware
heavy usage by multiple users
concurrent operation that requires scheduling, resource sharing, and sophisticated
process management
complex data structures
multiple external interfaces
E.g. compilers, editors and file management utilities.
Application software:
Application software consists of standalone programs that solve a specific business need.
It facilitates business operations or management/technical decision making.
It is used to control business functions in real-time
E.g. point-of-sale transaction processing, real-time manufacturing process control.
Page 2
SOFTWARE ENGINEERING
Ubiquitous computing: The challenge for software engineers will be to develop systems and application
software that will allow small devices, personal computers and enterprise system to communicate across vast
networks.
Net sourcing: The challenge for software engineers is to architect simple and sophisticated applications that
provide benefit to targeted end-user market worldwide.
Open Source: The challenge for software engineers is to build source that is self descriptive but more
importantly to develop techniques that will enable both customers and developers to know what changes
have been made and how those changes manifest themselves within the software.
The ―new economy‖: The challenge for software engineers is to build applications that will facilitate mass
communication and mass product distribution.
SOFTWARE MYTHS
Beliefs about software and the process used to build it- can be traced to the earliest days of computing
myths have a number of attributes that have made them insidious.
Management myths: Manages with software responsibility, like managers in most disciplines, are often
under pressure to maintain budgets, keep schedules from slipping, and improve quality.
Myth: We already have a book that‘s full of standards and procedures for building software - Wont that
provide my people with everything they need to know?
Reality: The book of standards may very well exist but, is it used? Are software practitioners aware of its
existence? Does it reflect modern software engineering practice?
Myth: If we get behind schedule, we can add more programmers and catch up.
Reality: Software development is not a mechanistic process like manufacturing. As new people are added,
people who were working must spend time educating the new comers, thereby reducing the amount of time
spend on productive development effort. People can be added but only in a planned and well coordinated
manner.
Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm built it.
Reality: If an organization does not understand how to manage and control software projects internally, it
will invariably struggle when it outsources software projects.
Page 3
SOFTWARE ENGINEERING
Customer myths: The customer believes myths about software because software managers and practitioners
do little to correct misinformation. Myths lead to false expectations and ultimately, dissatisfaction with the
developer.
Myth: A general statement of objectives is sufficient to begin with writing programs - we can fill in the
details later.
Reality: Although a comprehensive and stable statement of requirements is not always possible, an
ambiguous statement of objectives is recipe for disaster.
Myth: Project requirements continually change, but change can be easily accommodated because software
is flexible.
Reality: It is true that software requirements change, but the impact of change varies with the time at which
it is introduced and change can cause upheaval that requires additional resources and major design
modification.
Practitioner’s myths: Myths that are still believed by software practitioners: during the early days of
software, programming was viewed as an art from old ways and attitudes die hard.
Myth: Once we write the program and get it to work, our jobs are done.
Reality: Someone once said that the sooner you begin writing code, the longer it‘ll take you to get done.
Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended
after it is delivered to the customer for the first time.
Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many elements.
Documentation provides guidance for software support.
Myth: software engineering will make us create voluminous and unnecessary documentation and will
invariably slows down.
Reality: software engineering is not about creating documents. It is about creating quality. Better quality
leads to reduced rework. And reduced rework results in faster delivery times.
Tools
Methods
Process
A quality focus
Page 4
SOFTWARE ENGINEERING
Software engineering is a layered technology. Any engineering approach must rest on an organizational
commitment to quality. The bedrock that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. Software engineering process is the glue that
holds the technology layers. Process defines a framework that must be established for effective delivery
of software engineering technology.
The software forms the basis for management control of software projects and establishes the context
in which
- technical methods are applied,
- work products are produced,
- milestones are established,
- quality is ensured,
- And change is properly managed.
Software engineering methods rely on a set of basic principles that govern area of the technologyand
include modeling activities.
Software engineering tools provide automated or semi automated support for the process and the
methods. When tools are integrated so that information created by one tool can be used by another, a system
for the support of software development, called computer-aided software engineering, isestablished.
A PROCESS FRAMEWORK:
Software process must be established for effective delivery of software engineering technology.
A process framework establishes the foundation for a complete software process by identifying a small
number of framework activities that are applicable to all software projects, regardless of their size or
complexity.
The process framework encompasses a set of umbrella activities that are applicable across the entire
software process.
Each framework activity is populated by a set of software engineering actions
Each software engineering action is represented by a number of different task sets- each a collection of
software engineering work tasks, related work products, quality assurance points, and project milestones.
In brief
"A process defines who is doing what, when, and how to reach a certain goal."
A Process Framework
establishes the foundation for a complete software process
identifies a small number of framework activities
applies to all s/w projects, regardless of size/complexity.
also, set of umbrella activities
applicable across entire s/w process.
Each framework activity has
set of s/w engineering actions.
Each s/w engineering action (e.g., design) has
Page 5
SOFTWARE ENGINEERING
work tasks
project milestones.
Software process
Process framework
Umbrella activities
Framework activity #1
Work tasks
ask sets
Software engineering action T Work products
Quality assurance points
Project milestones
Framework activity #n
Software engineering action
Work tasks
Work products
Task sets Quality assurance points
Project milestones
Work tasks
Work products
Software engineering action
Quality assurance points
Project milestones
Page 6
SOFTWARE ENGINEERING
Communication: This framework activity involves heavy communication and collaboration with
the customer and encompasses requirements gathering and other related activities.
Planning: This activity establishes a plan for the software engineering work that follows. It
describes the technical tasks to be conducted, the risks that are likely, the resources that will be
required, the work products to be produced, and a work schedule.
Modeling: This activity encompasses the creation of models that allow the developer and customer
to better understand software requirements and the design that will achieve those requirements. The
modeling activity is composed of 2 software engineering actions- analysis and design.
Analysis encompasses a set of work tasks.
Design encompasses work tasks that create a design model.
Construction: This activity combines core generation and the testing that is required to
uncover the errors in the code.
Deployment: The software is delivered to the customer who evaluates the delivered product and
provides feedback based on the evolution.
These 5 generic framework activities can be used during the development of small programs, the
creation of large web applications, and for the engineering of large, complex computer-based systems.
Page 7
SOFTWARE ENGINEERING
Measurement - define and collects process, project and product measures that assist the team in
delivering software that needs customer‘s needs, can be used in conjunction with all other
framework and umbrella activities.
Software configuration management - manages the effects of change throughout the software
process.
Reusability management - defines criteria for work product reuse and establishes mechanisms
to achieve reusable components.
Work Product preparation and production - encompasses the activities required to create
work products such as models, document, logs, forms and lists.
Intelligent application of any software process model must recognize that adaption is essential for success
but process models do differ fundamentally in:
The overall flow of activities and tasks and the interdependencies among activities and tasks.
The degree through which work tasks are defined within each frame work activity.
The degree through which work products are identified and required.
The manner in which project tracking and control activities are applied.
The overall degree of the detailed and rigor with which the process is described.
The degree through which the customer and other stakeholders are involved with the project.
Page 8
Level 5: Optimized. All level 4 criteria have been achieved. In addition, the process area is adapted and
optimized using quantitative means to meet changing customer needs and to continually improve the efficacy
of the process area under consideration‖
Page 9
SOFTWARE ENGINEERING
The CMMI defines each process area in terms of ―specific goals‖ and the ―specific practices‖ required to
achieve these goals. Specific practices refine a goal into a set of process-related activities.
The specific goals (SG) and the associated specific practices(SP) defined for project planning are
SG 1 Establish estimates
SP 1.1 Estimate the scope of the project
SP 1.2 Establish estimates of work product and task attributes
SP 1.3 Define project life cycle
SP 1.4 Determine estimates of effort and cost
SG 2 Develop a Project Plan
SP 2.1 Establish the budget and schedule
SP 2.2 Identify project risks
SP 2.3 Plan for data management
SP 2.4 Plan for needed knowledge and skills
SP 2.5 Plan stakeholder involvement
SP 2.6 Establish the project plan
SG 3 Obtain commitment to the plan
SP 3.1 Review plans that affect the project
SP 3.2 Reconcile work and resource levels
SP 3.3 Obtain plan commitment
In addition to specific goals and practices, the CMMI also defines a set of five generic goals and related
practices for each process area. Each of the five generic goals corresponds to one of the five capability levels.
Hence to achieve a particular capability level, the generic goal for that level and the generic practices that
correspond to that goal must be achieved. To illustrate, the generic goals (GG) and practices (GP) forthe
project planning process area are
Page 10
SOFTWARE ENGINEERING
PROCESS PATTERNS
The software process can be defined as a collection patterns that define a set of activities, actions,
work tasks, work products and/or related behaviors required to develop computer software.
A process pattern provides us with a template- a consistent method for describing an important
characteristic of the software process. A pattern might be used to describe a complete process and a task
within a framework activity.
Pattern Name: The pattern is given a meaningful name that describes its function within the
software process.
Initial Context: The conditions under which the pattern applies are described prior to the initiation of
the pattern, we ask
What organizational or team related activities have already occurred.
What is the entry state for the process
What software engineering information or project information already exists
Resulting Context: The conditions that will result once the pattern has been successfully implemented
are described. Upon completion of the pattern we ask
What organizational or team-related activities must have occurred
What is the exit state for the process
What software engineering information or project information has been developed?
Known Uses: The specific instances in which the pattern is applicable are indicated
Process patterns provide and effective mechanism for describing any software process.
The patterns enable a software engineering organization to develop a hierarchical process description
that begins at a high-level of abstraction.
Once process pattern have been developed, they can be reused for the definition of process variants-that is,
a customized process model can be defined by a software team using the pattern as building blocks for the
process models.
Page 11
SOFTWARE ENGINEERING
PROCESS ASSESSMENT
The existence of a software process is no guarantee that software will be delivered on time, that it
will meet the customer‘s needs, or that it will exhibit the technical characteristics that will lead to long-term
quality characteristics. In addition, the process itself should be assessed to be essential to ensure that it meets
a set of basic process criteria that have been shown to be essential for a successful software engineering.
Software
Software
Lead
Software Capability
Motivat
A Number of different approaches to software process assessment have been proposed over the past few
decades.
Standards CMMI Assessment Method for Process Improvement (SCAMPI) provides a five step process
assessment model that incorporates initiating, diagnosing, establishing, acting & learning. The SCAMPI
method uses the SEI CMMI as the basis for assessment.
CMM Based Appraisal for Internal Process Improvement (CBA IPI) provides a diagnostic technique for
assessing the relative maturity of a software organization, using the SEI CMM as the basis for the assessment.
SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessments. The intent
of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined
software process.
ISO 9001:2000 for Software is a generic standard that applies to any organization that wants to improve the
overall quality of the products, system, or services that it provides. Therefore, the standard is directly
applicable to software organizations &companies.
The best software process is one that is close to the people who will be doing the work.Each software engineer
would create a process that best fits his or her needs, and at the same time meets the broader needsof the team
and the organization. Alternatively, the team itself would create its own process, and at the same time meet
the narrower needs of individuals and the broader needs of the organization.
Page 12
SOFTWARE ENGINEERING
The PSP process model defines five framework activities: planning, high-level design, high level design
review, development, and postmortem.
Planning: This activity isolates requirements and, base on these develops both size and resource estimates.
In addition, a defect estimate is made. All metrics are recorded on worksheets or templates. Finally,
development tasks are identified and a project schedule is created.
High level design: External specifications for each component to be constructed are developed and a
component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.
High level design review: Formal verification methods are applied to uncover errors in the design. Metrics
are maintained for all important tasks and work results.
Development: The component level design is refined and reviewed. Code is generated, reviewed,
compiled, and tested. Metrics are maintained for all important task and work results.
Postmortem: Using the measures and metrics collected the effectiveness of the process is determined.
Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
PSP stresses the need for each software engineer to identify errors early and, as important, to
understand the types of errors that he is likely to make.
Team software process (TSP): The goal of TSP is to build a ―self-directed project team that organizes
itself to produce high-quality software. The following are the objectives for TSP:
Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams(IPT) of 3 to
about 20 engineers.
Show managers how to coach and motivate their teams and how to help them sustain
peak performance.
Accelerate software process improvement by making CMM level 5 behavior normal and expected.
Provide improvement guidance to high-maturity organizations.
Facilitate university teaching of industrial-grade team skills.
self-directed team defines
roles and responsibilities for each team member
tracks quantitative project data
identifies a team process that is appropriate for the project
a strategy for implementing the process
defines local standards that are applicable to the teams software engineeringwork;
continually assesses risk and reacts to it
Tracks, manages, and reports project status.
-
TSP defines the following framework activities: launch, high-level design, implementation, integration and
test, and postmortem.
TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in
their work.
Scripts define specific process activities and other more detailed work functions that are part of the team
process.
Each project is ―launched‖ using a sequence of tasks.
Page 13
SOFTWARE ENGINEERING
PROCESS MODELS
Prescriptive process models define a set of activities, actions, tasks, milestones, and work products that are
required to engineer high-quality software. These process models are not perfect, but they do provide a useful
roadmap for software engineering work.
A prescriptive process model populates a process framework with explicit task sets for software
engineering actions.
Advantage:
It can serve as a useful process model in situations where requirements are fixed and work is to
proceed to complete in a linear manner.
The problems that are sometimes encountered when the waterfall model is applied are:
Real projects rarely follow the sequential flow that the model proposes. Although the linear model
can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the
project team proceeds.
It is often difficult for the customer to state all requirements explicitly. The waterfall model requires
this and has difficulty accommodating the natural uncertainty that exist at the beginning of many
projects.
The customer must have patience. A working version of the programs will not be available until late
in the project time-span. If a major blunder is undetected then it can be disastrous until the program
is reviewed.
Context: Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early increments can be
implemented with fewer people. If the core product is well received, additional staff can be added to
implement the next increment. In addition, increments can be planned to manage technical risks.
Page 14
SOFTWARE ENGINEERING
increment # n
d e l i v e ry
deliv ery of
nt h increment
increment # 2
sdesign code
deliv ery of
The incremental model combines elements of the waterfall model applied in an iterative fashion.
The incremental model delivers a series of releases called increments that provide progressively
more functionality for the customer as each increment is delivered.
When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed. The core product is used by the customer. As a result, a plan is
developed for the next increment.
The plan addresses the modification of the core product to better meet the needs of the customer
and the delivery of additional features and functionality.
This process is repeated following the delivery of each increment, until the complete product is
produced.
For example, word-processing software developed using the incremental paradigm might deliver basic file
management editing, and document production functions in the first increment; more sophisticated editing,
and document production capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment.
Difference: The incremental process model, like prototyping and other evolutionary approaches,is
iterative in nature. But unlike prototyping, the incremental model focuses on delivery of an operational
product with each increment
Rapid Application Development (RAD) is an incremental software process model that emphasizes
a short development cycle. The RAD model is a ―high-speed‖ adaption of the waterfall model, in which rapid
development is achieved by using a component base construction approach.
Context: If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a ―fully functional system‖ within a very short time period.
Page 15
SOFTWARE ENGINEERING
Team # n
M o d e lin g
business m odeling
dat a m odeling
process m odeling
Co n st ru ct io n
com ponent reuse
Team # 2 autom at ic code
Communicat ion generation
Mo d eling
business m odeling
dat a m odeling
process m odeling
Planning
De ployme nt
Team # 1 int egrat ion
deliv ery
Mode ling feedback
business modeling
dat a modeling
process modeling
6 0 - 9 0 days
Evolutionary process models produce with each iteration produce an increasingly more complete version
of the software with every iteration.
Evolutionary models are iterative. They are characterized in a manner that enables software engineers
to develop increasingly more complete versions of the software.
Page 16
SOFTWARE ENGINEERING
PROTOTYPING:
Prototyping is more commonly used as a technique that can be implemented within the context of
anyone of the process model.
The prototyping paradigm begins with communication. The software engineer and customer meet and
define the overall objectives for the software, identify whatever requirements are known, and outline
areas where further definition is mandatory.
Prototyping iteration is planned quickly and modeling occurs. The quick design leads to the construction
of a prototype. The prototype is deployed and then evaluated by the customer/user.
Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same
time enabling the developer to better understand what needs to be done.
Qu ick p lan
Mo d e lin g
Qu ick d e sig n
Deployment
De live r y
Const ruct ion
& Fe e dback
of
prot ot ype
Context:
If a customer defines a set of general objectives for software, but does not identify detailed
input, processing, or output requirements, in such situation prototyping paradigm is best approach.
If a developer may be unsure of the efficiency of an algorithm, the adaptability of an
operating system then he can go for this prototyping method.
Advantages:
The prototyping paradigm assists the software engineer and the customer to better understand what
is to be built when requirements are fuzzy.
The prototype serves as a mechanism for identifying software requirements. If a working prototype
is built, the developer attempts to make use of existing program fragments or applies tools.
Page 17
SOFTWARE ENGINEERING
demonstrate capability. After a time, the developer may become comfortable with these choices and
forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an
integral part of the system.
The spiral model, originally proposed by Boehm, is an evolutionary software process model that
couples the iterative nature of prototyping with the controlled and systematic aspects of the
waterfall model.
The spiral model can be adapted to apply throughout the entire life cycle of an application, from
concept development to maintenance.
Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a paper model or prototype. During later iterations, increasingly
morecomplete versions of the engineered system are
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery
code
feedback
produced. test
Anchor point milestones- a combination of work products and conditions that are attained along
the path of the spiral- are noted for each evolutionary pass.
The first circuit around the spiral might result in the development of product specification;
subsequent passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the software.
Each pass through the planning region results in adjustments to the project plan. Cost and schedule
are adjusted based on feedback derived from the customer after delivery. In addition, the project
manager adjusts the planned number of iterations required to complete the software.
It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it
into an iterative framework that more realistically reflects the real world.
The first circuit around the spiral might represent a ―concept development project‖ which starts at
the core of the spiral and continues for multiple iterations until concept development is complete.
If the concept is to be developed into an actual product, the process proceeds outward on the spiral and a
―new product development project‖ commences.
Later, a circuit around the spiral might be used to represent a ―product enhancement project.‖ In essence,
the spiral, when characterized in this way, remains operative until the software is retired.
Context: The spiral model can be adopted to apply throughout the entire life cycle of an application, from
concept development to maintenance.
Advantages:
It provides the potential for rapid development of increasingly more complete versions of the software.
Page 18
SOFTWARE ENGINEERING
The spiral model is a realistic approach to the development of large-scale systems and software. The spiral
model uses prototyping as a risk reduction mechanism but, more importantly enables the developer to apply
the prototyping approach at any stage in the evolution of the product.
Draw Backs:
The spiral model is not a panacea. It may be difficult to convince customers that the evolutionary approach
is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If
a major risk is not uncovered and managed, problems will undoubtedly occur.
none
Await ing
changes
Under review
Under
revision
Baselined
Done
The activity modeling may be in anyone of the states noted at any given time. Similarly, other
activities or tasks can be represented in an analogous manner. All activities exist concurrently but reside in
different states.
Any of the activities of a project may be in a particular state at any one time
under development
awaiting changes
under revision
under review
In a project the communication activity has completed its first iteration and exists in the awaiting
changes state. The modeling activity which existed in the none state while initial communication was
Page 19
SOFTWARE ENGINEERING
Page 20
completed, now makes a transition into the under development state. If, however, the customer indicates
that changes in requirements must be made, the modeling activity moves from the under development state
into the awaiting changes state.
The concurrent process model defines a series of events that will trigger transitions from state to
state for each of the software engineering activities, actions, or tasks.
The event analysis model correction which will trigger the analysis action from the done state into
the awaiting changes state.
Context: The concurrent model is often more appropriate for system engineering projects where different
engineering teams are involved.
Advantages:
The concurrent process model is applicable to all types of software development and provides an
accurate picture of the current state of a project.
It defines a network of activities rather than each activity, action, or task on the network exists
simultaneously with other activities, action and tasks.
A FINAL COMMENT ON EVOLUTIONARY PROCESSES:
The concerns of evolutionary software processes are:
The first concern is that prototyping poses a problem to project planning because of the uncertain number of
cycles required to construct the product.
Second, evolutionary software process do not establish the maximum speed of the evolution. If the
evolution occurs too fast, without a period of relaxation, it is certain that the process will fall into
chaos.
Third, software processes should be focused on flexibility and extensibility rather than on high quality.
A BRIEF HISTORY:
During the 1980s and into early 1990s, object-oriented (OO) methods and programming languages
gained a widespread audience throughout the software engineering community. A wide variety of object-
oriented analysis (OOA) and design (OOD) methods were proposed during the same time period.
During the early 1990s James Rumbaugh, Grady Booch, and Ival Jacobsom began working on a
―Unified method‖ that would combine the best features of each of OOD & OOA. The result was UML- a
unified modeling language that contains a robust notation fot the modeling and development of OO systems.
By 1997, UML became an industry standard for object-oriented software development. At the same
time, the Rational Corporation and other vendors developed automated tools to support UML methods.
Over the next few years, Jacobson, Rumbugh, and Booch developed the Unified process, a
framework for object-oriented software engineering using UML. Today, the Unified process and UML are
widely used on OO projects of all kinds. The iterative, incremental model proposed by the UP can and should
be adapted to meet specific project needs.
Page 20
PHASES OF THE UNIFIED PROCESS:
The inception phase of the UP encompasses both customer communication and planning activities.
By collaborating with the customer and end-users, business requirements for the software are identified, a
rough architecture for the system is proposed and a plan for the iterative, incremental nature of the ensuing
project is developed.
The elaboration phase encompasses the customer communication and modeling activities of the
generic process model. Elaboration refines and expands the preliminary use-cases that were developed as part
of the inception phase and expands the architectural representation to include five different views of the
software- the use-case model, the analysis model, the design model, the implementation model, and the
deployment model.
The construction phase of the UP is identical to the construction activity defined for the generic
software process. Using the architectural model as input, the construction phase develops or acquires the
software components that will make each use-case operational for end-users. To accomplish this, analysis
and design models that were started during the elaboration phase are completed to reflect the final version
of the software increment.
The transition phase of the UP encompasses the latter stages of the generic construction activity and
the first part of the generic deployment activity. Software given to end-users for beta testing, and user
feedback reports both defects and necessary changes.
The production phase of the UP coincides with the deployment activity of the generic process.
During this phase, the on-going use of the software is monitored, support for the operating environment
is provided, and defect reports and requests for changes are submitted and evaluated.
Elaborat ion
Incept ion
product ion
A software engineering workflow is distributed across all UP phases. In the context of UP, a workflow is
analogous to a task set. That is, a workflow identifies the tasks required to accomplish an important software
engineering action and the work products that are produced as a consequence of successfully completing the
tasks.
During the inception phase, the intent is to establish an overall ―vision‖ for the project,
identify a set of business requirements,
make a business case for the software, and
define project and business risks that may represent a threat to success.
Page 21
The most important work product produced during the inception is the use-case modell-a collection of
use-cases that describe how outside actors interact with the system and gain value from it. The use-case model
is a collection of software features and functions by describing a set of preconditions, a flow of events and a
set of post-conditions for the interaction that is depicted.
The use-case model is refined and elaborated as each UP phase is conducted and serves as an important
input for the creation of subsequent work products. During the inception phase only 10 to 20 percent of the
use-case model is completed. After elaboration, between 80 to 90 percent of the model has been created.
The elaboration phase produces a set of work products that elaborate requirements and produce and
architectural description and a preliminary design. The UP analysis model is the work product that is
developed as a consequence of this activity. The classes and analysis packages defined as part of the
analysis model are refined further into a design model which identifies design classes, subsystems, and
the interfaces between subsystems. Both the analysis and design models expand and refine an evolving
representation of software architecture. In addition the elaboration phase revisits risks and the project
plan to ensure that each remains valid.
The construction phase produces an implementation model that translates design classes into
software components into the physical computing environment. Finally, a test model describes tests that
are used to ensure that use cases are properly reflected in the software that has been constructed.
The transition phase delivers the software increment and assesses work products that are produced
as end-users work with the software. Feedback from beta testing and qualitative requests for change is
produced at this time.
Inception phase
Elaboration phase
Vision document
Init ial use-case model
Init ial project glossary
Construct ion phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Transition phase
Design model
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect Deliv ered soft ware
Int egrat ed soft ware
Business model, ure Descript ion. increment increment Bet a t est report s
if necessary . Execut able archit ect Test plan and General user feedback
One or more prot ot ypes ural prot ot ype. procedure Test cases
Preliminary design Support document at ion
model Revised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan adapt descript ion of current
ed workflows milest increment
ones
t echnical work product s
Preliminary user manual
Page 22
UNIT-II
SOFTWARE REQUIREMENTS
Types of requirement:
User requirements
Statements in natural language plus diagrams of the services the system provides and
its operational constraints. Written for customers.
System requirements
A structured document setting out detailed descriptions of the system‘s functions,
services and operational constraints. Defines what should be implemented so may be
part of a contract between client and contractor.
Page 23
System Requirement specification:
The user should be provided with facilities to define the type of external files.
Each external file type may have an associated tool which may be applied to the file.
Each external file type may be represented as a specific icon on the user‘s display.
Facilities should be provided for the icon representing an external file type to be defined by
the user.
When an user selects an icon representing an external file, the effect of that selection is to apply the
tool associated with the type of the external file to the file represented by the selected icon.
Requirements readers:
Page 24
Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account‘s permanent storage area.
Requirements imprecision
Problems arise when requirements are not precisely stated.
Ambiguous requirements may be interpreted in different ways by developers and users.
Consider the term ‗appropriate viewers‘
o User intention - special purpose viewer for each different document type;
o Developer interpretation - Provide a text viewer that shows the contents of the
document.
Requirements completeness and consistency:
In principle, requirements should be both complete and consistent.
Complete
They should include descriptions of all facilities
required. Consistent
There should be no conflicts or contradictions in the descriptions of the system facilities. In
practice, it is impossible to produce a complete and consistent requirementsdocument.
NON-FUNCTIONAL REQUIREMENTS
These define system properties and constraints e.g. reliability, response time and
storage requirements. Constraints are I/O device capability, system representations, etc.
Process requirements may also be specified mandating a particular CASE system,
programming language or development method.
Non-functional requirements may be more critical than functional requirements. If these are
not met, the system is useless.
1.2) Non-functional requirement types:
Non-functional requirements :
Product requirements
Page 25
Requirements which specify that the delivered product must behave in a particular
way e.g. execution speed, reliability, etc.
Eg:The user interface for LIBSYS shall be implemented as simple HTML without
frames or Java applets.
Organisational requirements
Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.
Eg: The system development process and deliverable documents shall conform to
the process and deliverables defined in XYZCo-SP-STAN-95.
External requirements
Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.
Eg: The system shall not disclose any personal information about customers apart
from their name and reference number to the operators of the system.
Requirements measures:
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Page 26
Portability Percentage of target dependent statements
Number of target systems
Requirements interaction:
Conflicts between different non-functional requirements are common in complex systems.
Spacecraft system
To minimise weight, the number of separate chips in the system should be
minimised.
To minimise power consumption, lower power chips should be used.
However, using low power chips may mean that more chips have to be used. Which is the
most critical requirement?
A common problem with non-functional requirements is that they can be difficult to verify. Users
or customers often state these requirements as general goals such as ease of use, the ability of the system
to recover from failure or rapid user response. These vague goals cause problems for system developers as
they leave scope for interpretation and subsequent dispute once the system is delivered.
USER REQUIREMENTS
Should describe functional and non-functional requirements in such a way that they
are understandable by system users who don‘t have detailed technical knowledge.
User requirements are defined using natural language, tables and diagrams as these can
be understood by all users.
Requirement problems
Database requirements includes both conceptual and detailed information
• Describes the concept of a financial accounting system that is to be included in
LIBSYS;
Page 27
28 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
However, it also includes the detail that managers can configure this system - this is
unnecessary at this level.
Grid requirement mixes three different kinds of requirement
Conceptual functional requirement (the need for a grid);
Non-functional requirement (grid units);
Non-functional UI requirement (grid switching).
Structured presentation
Guidelines for writing requirements
Invent a standard format and use it for all requirements.
Use language in a consistent way. Use shall for mandatory requirements, should for
desirable requirements.
Use text highlighting to identify key parts of the requirement.
Avoid the use of computer jargon.
SYSTEM REQUIREMENTS
More detailed specifications of system functions, services and constraints than user requirements.
They are intended to be a basis for designing the system.
They may be incorporated into the system contract.
System requirements may be defined or illustrated using system models
Alternatives to NL specification:
Notation Description
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.
Design description This approach uses a language like a programming language but with more abstract
languages features to specify the requirements by defining an operational model of the system.
This approach is not now widely used although it can be useful for interface
specifications.
Page 28
29 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Graphical A graphical language, supplemented by text annotations is used to define the functional
notations requirements for the system. An early example of such a graphical language was SADT.
Now, use-case descriptions and sequence diagrams are commonly used .
Mathematical These are notations based on mathematical concepts such as finite-state machines or
specifications sets. These unambiguous specifications reduce the arguments between customer and
contractor about system functionality. However, most customers don‘t understand
formal specifications and are reluctant to accept it as a system contract.
Form-based specifications
Definition of the function or entity.
Description of inputs and where they come from.
Description of outputs and where they go to.
Indication of other entities required.
Pre and post conditions (if appropriate).
The side effects (if any) of the function.
Tabular specification
Used to supplement natural language.
Particularly useful when you have to define a number of possible alternative courses of action.
Graphical models
Graphical models are most useful when you need to show how state changes or where you need
to describe a sequence of actions.
Sequence diagrams
These show the sequence of events that take place during some user interaction with a system.
You read them from top to bottom to see the order of the actions that take place.
Cash withdrawal from an ATM
Validate card;
Handle request;
Complete transaction.
Page 29
30 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
When a standard form is used for specifying functional requirements, the following information should be
included:
Description of the function or entity being specified
Description of its inputs and where these come from
Description of its outputs and where these go to
Indication of what other entities are used
Description of the action to be taken
If a functional approach is used, a pre-condition setting out what must be true before the function
is called and a post-condition specifying what is true after the function is called
Page 30
31 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERFACE SPECIFICATION
Most systems must operate with other systems and the operating interfaces must be specified
as part of the requirements.
Three types of interface may have to be defined
Procedural interfaces where existing programs or sub-systems offer a range of services
that are accessed by calling interface procedures. These interfaces are sometimes called
Applicatin Programming Interfaces (APIs)
Data structures that are exchanged that are passed from one sub-system to
another. Graphical data models are the best notations for this type of description
Data representations that have been established for an existing sub-system
Formal notations are an effective technique for interface specification.
Page 31
32 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
IEEE requirements standard defines a generic structure for a requirements document that must
be instantiated for each specific system.
Introduction.
Purpose of the requirements document
Scope of the project
Definitions, acronyms and abbreviations
References
Overview of the remainder of the document
General description.
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
Specific requirements cover functional, non-functional and interface requirements. The
requirements may document external interfaces, describe system functionality and performance,
specify logical database requirements, design constraints, emergent system properties and
quality characteristics.
Appendices.
Index.
Requirements engineering:
Page 32
33 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
The alternative perspective on the requirements engineering process presents the process as a three-stage
activity where the activities are organized as an iterative process around a spiral. The amount of time and
effort devoted to each activity in iteration depends on the stage of the overall process and the type of system
being developed. Early in the process, most effort will be spent on understanding high-level business and
non-functional requirements and the user requirements. Later in the process, in the outer rings of the spiral,
more effort will be devoted to system requirements engineering and system modeling.
This spiral model accommodates approaches to development in which the requirements are developed to
different levels of detail. The number of iterations around the spiral can vary, so the spiral can be exited after
some or all of the user requirements have been elicited.
Some people consider requirements engineering to be the process of applying a structured analysis method
such as object-oriented analysis. This involves analyzing the system and developing a set of graphical system
models, such as use-case models, that then serve as a system specification. The set of models describes the
behavior of the system and are annotated with additional information describing, for example, its required
performance or reliability.
Spiral model of requirements engineering processes
1) FEASIBILITY STUDIES
A feasibility study decides whether or not the proposed system is worthwhile. The input to the feasibility
study is a set of preliminary business requirements, an outline description of the system and how the system
is intended to support business processes. The results of the feasibility study should be a report that
recommends whether or not it worth carrying on with the requirements engineering and system development
process.
A short focused study that checks
– If the system contributes to organisational objectives;
– If the system can be engineered using current technology and within budget;
Page 33
34 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
– If the system can be integrated with other systems that are used.
Page 34
35 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
Process activities
Requirements discovery
– Interacting with stakeholders to discover their requirements. Domain requirements are
also discovered at this stage.
Requirements classification and organisation
– Groups related requirements and organises them into coherent clusters.
Prioritisation and negotiation
– Prioritising requirements and resolving requirements conflicts.
Requirements documentation
– Requirements are documented and input into the next round of the spiral.
The process cycle starts with requirements discovery and ends with requirements documentation. The
analyst‘s understanding of the requirements improves with each round of the cycle.
Requirements classification and organization is primarily concerned with identifying overlapping
requirements from different stakeholders and grouping related requirements. The most common way of
grouping requirements is to use a model of the system architecture to identify subsystems and to associate
requirements with each sub-system.
Inevitably, stakeholders have different views on the importance and priority of requirements, and sometimes
these view conflict. During the process, you should organize regular stakeholder negotiations so that
compromises can be reached.
In the requirement documenting stage, the requirements that have been elicited are documented in such a
way that they can be used to help with further requirements discovery.
Viewpoints:
Viewpoints are a way of structuring the requirements to represent the perspectives of different
stakeholders. Stakeholders may be classified under different viewpoints.
This multi-perspective analysis is important as there is no single correct way to analyse system
requirements.
•
Types of viewpoint:
Interactor viewpoints
– People or other systems that interact directly with the system. These viewpoints provide
detailed system requirements covering the system features and interfaces. In an ATM, the
customer‘s and the account database are interactor VPs.
Indirect viewpoints
Page 35
36 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
– Stakeholders who do not use the system themselves but who influence the requirements.
These viewpoints are more likely to provide higher-level organisation requirements and
constraints. In an ATM, management and security staff are indirect viewpoints.
Domain viewpoints
– Domain characteristics and constraints that influence the requirements. These viewpoints
normally provide domain constraints that apply to the system. In an ATM, an example
would be standards for inter-bank communications.
Typically, these viewpoints provide different types of requirements.
Viewpoint identification:
Identify viewpoints using
– Providers and receivers of system services;
– Systems that interact directly with the system being specified;
– Regulations and standards;
– Sources of business and non-functional requirements.
– Engineers who have to develop and maintain the system;
– Marketing and other business viewpoints.
Interviewing
In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they
use and the system to be developed.
There are two types of interview
Closed interviews where a pre-defined set of questions are answered.
Open interviews where there is no pre-defined agenda and a range of issues are explored
with stakeholders.
-
Interviews in practice:
Normally a mix of closed and open-ended interviewing.
Interviews are good for getting an overall understanding of what stakeholders do and how
they might interact with the system.
Interviews are not good for understanding domain requirements
– Requirements engineers cannot understand specific domain terminology;
Page 36
37 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
– Some domain knowledge is so familiar that people find it hard to articulate or think that it
isn‘t worth articulating.
Effective interviewers:
Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-
conceived ideas about the requirements.
They should prompt the interviewee with a question or a proposal and should not simply expect
them to respond to a question such as ‗what do you want‘.
•
Scenarios:
Scenarios are real-life examples of how a system can be used.
They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
– A description of the state when the scenario finishes.
Use cases
Use-cases are a scenario based technique in the UML which identify the actors in an interaction and
which describe the interaction itself.
A set of use cases should describe all possible interactions with the system.
Sequence diagrams may be used to add detail to use-cases by showing the sequence of
event processing in the system.
•
Article printing use-case:
Page 37
38 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
2.2) ETHNOGRAPHY:
A social scientists spends a considerable time observing and analysing how people actually work.
People do not have to explain or articulate their work.
Social and organisational factors of importance may be observed.
Ethnographic studies have shown that work is usually richer and more complex than suggested
by simple system models.
Focused ethnography:
Developed in a project studying the air traffic control process
Combines ethnography with prototyping
Prototype development results in unanswered questions which focus the ethnographic analysis.
The problem with ethnography is that it studies existing practices which may have some historical
basis which is no longer relevant.
Page 38
39 SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
Scope of ethnography:
Requirements that are derived from the way that people actually work rather than the way I
which process definitions suggest that they ought to work.
Requirements that are derived from cooperation and awareness of other people‘s activities.
REQUIREMENTS VALIDATION
Concerned with demonstrating that the requirements define the system that the customer
really wants.
Requirements error costs are high so validation is very important
– Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.
Requirements checking:
Validity: Does the system provide the functions which best support the customer‘s needs?
Consistency: Are there any requirements conflicts?
Completeness: Are all functions required by the customer included?
Realism: Can the requirements be implemented given available budget and technology
Verifiability: Can the requirements be checked?
Requirements reviews:
Regular reviews should be held while the requirements definition is being formulated.
Both client and contractor staff should be involved in reviews.
Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage.
Review checks:
Verifiability: Is the requirement realistically testable?
Comprehensibility: Is the requirement properly understood?
Traceability: Is the origin of the requirement clearly stated?
Adaptability: Can the requirement be changed without a large impact on other requirements?
REQUIREMENTS MANAGEMENT
Requirements management is the process of managing changing requirements during
the requirements engineering process and system development.
Requirements are inevitably incomplete and inconsistent
– New requirements emerge during the process as business needs change and a better
understanding of the system is developed;
– Different viewpoints have different requirements and these are often contradictory.
Requirements change
The priority of requirements from different viewpoints changes during the development process.
System customers may specify requirements from a business perspective that conflict with end-
user requirements.
The business and technical environment of the system changes during its development.
Page 39
40
SOFTWARE ENGINEERING
Requirements evolution:
Traceability:
Traceability is concerned with the relationships between requirements, their sources and the system design
Source traceability
– Links from requirements to stakeholders who proposed these requirements;
Requirements traceability
– Links between dependent requirements;
Design traceability - Links from the requirements to the design;
Page 40
41
SOFTWARE ENGINEERING
Change management:
SYSTEM MODELLING
System modelling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.
Different models present the system from different perspectives
o Behavioural perspective showing the behaviour of the system;
o Structural perspective showing the system or data architecture.
Model types
Data processing model showing how the data is processed at different stages.
Composition model showing how entities are composed of other entities.
Architectural model showing principal sub-systems.
Classification model showing how entities have common characteristics.
Stimulus/response model showing the system‘s reaction to events.
CONTEXT MODELS:
Context models are used to illustrate the operational context of a system - they show what
lies outside the system boundaries.
Social and organisational concerns may affect the decision on where to position
system boundaries.
Architectural models show the system and its relationship with other systems.
Page 41
42
SOFTWARE ENGINEERING
Process models:
Process models show the overall process and the processes that are supported by the system.
Data flow models may be used to show the processes and the flow of information from
one process to another.
BEHAVIOURAL MODELS:
Behavioural models are used to describe the overall behaviour of a system.
Two types of behavioural model are:
o Data processing models that show how data is processed as it moves through the
system;
State machine models that show the systems response to events.
These models show different perspectives so both of them are required to describe the
system‘s behaviour.
Page 42
43
SOFTWARE ENGINEERING
Statecharts:
Allow the decomposition of a model into sub-models (see following slide).
A brief description of the actions is included following the ‗do‘ in each state.
Can be complemented by tables describing the states and the stimuli.
Page 43
44
SOFTWARE ENGINEERING
Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On
completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display
shows ‗Cooking complete‘ while buzzer is sounding.
Data dictionaries
Data dictionaries are lists of all of the names used in the system models. Descriptions of
the entities, relationships and attributes are also included.
Advantages
o Support name management and avoid duplication;
Store of organisational knowledge linking analysis, design andimplementation;
Many CASE workbenches support data dictionaries.
OBJECT MODELS:
Object models describe the system in terms of object classes and their associations.
An object class is an abstraction over a set of objects with common attributes and the
services (operations) provided by each object.
Various object models may be produced
Inheritance models;
o Aggregation models;
Interaction models.
Natural ways of reflecting the real-world entities manipulated by the system
More abstract entities are more difficult to model using this approach
Object class identification is recognised as a difficult process requiring a deep understanding of
the application domain
Object classes reflecting domain entities are reusable across systems
Page 44
45
SOFTWARE ENGINEERING
Page 45
46
SOFTWARE ENGINEERING
Multiple inheritance:
Rather than inheriting the attributes and services from a single parent class, a system which
supports multiple inheritance allows object classes to inherit from severalsuper-classes.
This can lead to semantic conflicts where attributes/services with the same name in
different super-classes have different semantics.
Multiple inheritance makes class hierarchy reorganisation more complex.
Multiple inheritance
Object aggregation:
An aggregation model shows how classes that are collections are composed of otherclasses.
Aggregation models are similar to the part-of relationship in semantic data models.
Page 46
47
SOFTWARE ENGINEERING
A behavioural model shows the interactions between objects to produce some particular
system behaviour that is specified as a use-case.
Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction
between objects.
STRUCTURED METHODS:
Structured methods incorporate system modelling as an inherent part of the method.
Methods define a set of models, a process for deriving these models and rules and guidelines
that should apply to the models.
CASE tools support system modelling as part of a structured method.
Method weaknesses:
They do not model non-functional system requirements.
They do not usually include information about whether a method is appropriate for a
given problem.
The may produce too much documentation.
The system models are sometimes too detailed and difficult for users to understand.
CASE workbenches:
A coherent set of tools that is designed to support related software process activities such
as analysis, design or testing.
Analysis and design workbenches support system modelling during both requirements
engineering and system design.
These workbenches may support a specific design method or may provide support for a
creating several different types of system model.
Page 47
48
SOFTWARE ENGINEERING
Page 48
49
SOFTWARE ENGINEERING
UNIT-III
DESIGN ENGINEERING
Design engineering encompasses the set of principals, concepts, and practices that lead to
the development of a high- quality system or product.
Design principles establish an overriding philosophy that guides the designer in the work that is
performed.
Design concepts must be understood before the mechanics of design practice are applied and
Design practice itself leads to the creation of various representations of the software that serve as a guide for
the construction activity that follows.
What is design:
Design is what virtually every engineer wants to do. It is the place where creativity rules –
customer‘s requirements, business needs, and technical considerations all come together in the formulation
of a product or a system. Design creates a representation or model of the software, but unlike the analysis
model, the design model provides detail about software data structures, architecture, interfaces, and
components that are necessary to implement the system.
Why is it important:
Design allows a software engineer to model the system or product that Is to be built. This model can
be assessed for quality and improved before code is generated, tests are conducted, and end – users become
involved in large numbers. Design is the place where software quality is established.
The goal of design engineering is to produce a model or representation that exhibits firmness,
commodity, and delight. To accomplish this, a designer must practice diversification and then
convergence. Another goal of software design is to derive an architectural rendering of a system. The
rendering serves as a framework from which more detailed design activities are conducted.
Goals of design:
McGlaughlin suggests three characteristics that serve as a guide for the evaluation of a good design.
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.
Quality guidelines:
In order to evaluate the quality of a design representation we must establish technical criteria for
good design. These are the following guidelines:
A design should exhibit an architecture that
has been created using recognizable architectural styles or patterns
is composed of components that exhibit good design characteristics and
can be implemented in an evolutionary fashion, thereby facilitating implementation
and testing.
A design should be modular; that is, the software should be logically partitioned into elements
or subsystems.
A design should contain distinct representation 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.
A design should lead to components that exhibit independent functional characteristics.
Page 49
50 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
A design should lead to interface 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 communication its meaning.
These design guidelines are not achieved by chance. Design engineering encourages good design through
the application of fundamental design principles, systematic methodology, and thorough review.
Quality attributes:
The FURPS quality attributes represent a target for all software design:
Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
Usability is assessed by considering human factors, overall aesthetics, consistency and
documentation.
Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output
results, and the mean – time –to- failure (MTTF), the ability to recover from failure, and the
predictability of the program.
Performance is measured by processing speed, response time, resource consumption, throughput, and
efficiency
➢
Supportability combines the ability to extend the program (extensibility), adaptability, serviceability- these
three attributes represent a more common term maintainability
Not every software quality attribute is weighted equally as the software design is
developed. One application may stress functionality with a special emphasis on security.
Another may demand performance with particular emphasis on processing speed.
2) DESIGN CONCEPTS:
M.A Jackson once said:‖The beginning of wisdom for a software engineer is to recognize the difference
between getting a program to work, and getting it right.‖ Fundamental software design concepts provide the
necessary framework for ―getting it right.‖
Architecture:
Software architecture alludes to ―the overall structure of the software and the ways in which that structure
provides conceptual integrity for a system‖. In its simplest form, architecture is the structure or organization
of program components (modules), the manner in which these components interact, and the structure of data
that are used by the components.
One goal of software design is to derive an architectural rendering of a system. The rendering serves as a
framework from which more detailed design activities are conducted.
Page 50
51 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The architectural design can be represented using one or more of a number of different models.
Structured models represent architecture as an organized collection of program components.
Framework models increase the level of design abstraction by attempting to identify repeatable
architectural design frameworks that are encountered in similar types of applications.
Dynamic models address the behavioral aspects of the program architecture, indicating how the structure
or system configuration may change as a function external events.
Process models focus on the design of the business or technical process that the system must
accommodate. Functional models can be used to represent the functional hierarchy of a system.
Patterns:
Brad Appleton defines a design pattern in the following manner: ―a pattern is a named nugget of inside
which conveys that essence of a proven solution to a recurring problem within a certain context amidst
competing concerns.‖ Stated in another way, a design pattern describes a design structure that solves a
particular design within a specific context and amid ―forces‖ that may have an impact on the manner in
which the pattern is applied and used.
The intent of each design pattern is to provide a description that enables a designer to determine
Whether the pattern is capable to the current work,
Whether the pattern can be reused,
Whether the pattern can serve as a guide for developing a similar, but functionally or structurally
different pattern.
IV. Modularity:
Software architecture and design patterns embody modularity; software is divided into separately named
and addressable components, sometimes called modules that are integrated to satisfy problem requirements.
It has been stated that ―modularity is the single attribute of software that allows a program to be
intellectually manageable‖. Monolithic software cannot be easily grasped by a software engineer. The number
of control paths, span of reference, number of variables, and overall complexity would make understanding
close to impossible.
The ―divide and conquer‖ strategy- it‘s easier to solve a complex problem when you break it into
manageable pieces. This has important implications with regard to modularity and software. If we subdivide
software indefinitely, the effort required to develop it will become negligibly small. The effort to develop an
individual software module does decrease as the total number of modules increases. Given the same set of
requirements, more modules means smaller individual size. However, as the number of modules grows, the
effort associated with integrating the modules also grow.
Under modularity or over modularity should be avoided. We modularize a design so that
development can be more easily planned; software increment can be defined and delivered; chamges can be
more easily accommodated; testing and debugging can be conducted more efficiently, and long-term
maintenance can be conducted without serious side effects.
Information Hiding:
The principle of information hiding suggests that modules be ―characterized by design decision that
hides from all others.‖
Modules should be specified and designed so that information contained within a module is inaccessible
to other modules that have no need for such information.
Hiding implies that effective modularity can be achieved by defining a set of independent modules
that communicate with one another only that information necessary to achieve software function. Abstraction
helps to define the procedural entities that make up the software. Hiding defines and enforces access
constraints to both procedural detail within a module and local data structure used by module.
The use of information hiding as a design criterion for modular systems provides the greatest benefits
when modifications are required during testing and later, during software maintenance. Because most data
and procedure are hidden from other parts of the software, inadvertent errors introduced during modification
are less likely to propagate to other locations within software.
Page 51
52 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
VII. Refinement:
Stepwise refinement is a top- down design strategy originally proposed by Niklaus wirth. A program is
development by successively refining levels of procedural detail. A hierarchy is development by
decomposing a macroscopic statement of function in a step wise fashion until programming language
statements are reached.
Refinement is actually a process of elaboration. We begin with a statement of function that is defined
at a high level of abstraction. That is, the statement describes function or information conceptually but
provides no information about the internal workings of the function or the internal structure of the data.
Refinement causes the designer to elaborate on the original statement, providing more and more detail as
each successive refinement occurs.
Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify
procedure and data and yet suppress low-level details. Refinement helps the designer to reveal low-level
details as design progresses. Both concepts aid the designer in creating a complete design model as the design
evolves.
VIII. Refactoring :
Refactoring is a reorganization technique that simplifies the design of a component without changing its
function or behavior. Fowler 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 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. The designer may decide that the component
should be refactored into 3 separate components, each exhibiting high cohesion. The result will be software
that is easier to integrate, easier to test, and easier to maintain.
Page 52
53 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Create a new set of design classes that implement a software infrastructure to support the design
solution.
Five different types of design classes, each representing a different layer of the design architectureare
suggested.
User interface classes: define all abstractions that are necessary for human computer interaction.
In many cases, HCL occurs within the context of a metaphor and the design classes for the interface
may be visual representations of the elements of the metaphor.
Business domain classes: are often refinements of the analysis classes defined earlier. The classes
identify the attributes and services that are required to implement some element of the business
domain.
Process classes implement lower – level business abstractions required to fully manage the business domain
classes.
Persistent classes represent data stores that will persist beyond the execution of the software.
System classes implement software management and control functions that enable the system to operate and
communicate within its computing environment and with the outside world.
As the design model evolves, the software team must develop a complete set of
attributes and operations for each design class. The level of abstraction is reduced as each analysis class is
transformed into a design representation. Each design class be reviewed to ensure that it is ―well-formed.‖
They define four characteristics of a well- formed design class.
Complete and sufficient: A design class should be the complete encapsulation of all attributes and methods
that can reasonably be expected to exist for the class. Sufficiency ensures that the design class contains only
those methods that are sufficient to achieve the intent of the class, no more and no less.
Primitiveness: Methods associated with a design class should be focused on accomplishing one service for
the class. Once the service has been implemented with a method, the class should not provide another way
to accomplish the same thing.
High cohesion: A cohesive design class has a small, focused set of responsibilities and single- mindedly
applies attributes and methods to implement those responsibilities.
Low coupling: Within the design model, it is necessary for design classes to collaborate with one another.
However, collaboration should be kept to an acceptable minimum. If a design model is highly coupled the
system is difficult to implement, to test, and to maintain over time. In general, design classes within a
subsystem should have only limited knowledge of classes in other subsystems. This restriction, called the
law of Demeter, suggests that a method should only sent messages to methods in neighboring classes.
Page 53
54 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
high
a na ly sis mode l
class diagrams
analysis packages Requirement s:
use- cases - t ext class diagrams analysis
CRC models const raint s
use- case diagrams packages CRC models
collaborat ion diagrams
act ivit y diagrams sw collaborat ion diagrams int eroperabilit
dat a f low diagrams im lane diagrams dat a f low diagrams y t arget s and
cont rol- f low diagrams
collaborat ion diagrams cont rol- f low diagrams
processing narrat ives
st at e diagrams processing narrat ives st
conf igurat ion
sequence diagrams at e diagrams sequence
diagrams
process dimension
Data design elements:
Data design sometimes referred to as data architecting creates a model of data and/or information that is
represented at a high level of abstraction. This data model is then refined into progressively more
implementation-specific representations that can be processed by the computer-based system.
The structure of data has always been an important part of software design.
At the program component level, the design of data structures and the associated algorithms required to
manipulate them is essential to the criterion of high-quality applications.
At the application level, the translation of a data model into a database is pivotal to achieving the business
objectives of a system.
At the business level, the collection of information stored in disparate databases and reorganized into a
―data warehouse‖ enables data mining or knowledge discovery that can have an impact on the
success of the business itself.
Page 54
55 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The interface design elements for software tell how information flows into and out of the system
and how it is communicated among the components defined as part of the architecture. There are
3 important elements of interface design:
The user interface(UI);
External interfaces to other systems, devices, networks, or other produces or consumers
of information; and
Internal interfaces between various design components.
These interface design elements allow the software to communicated externally and enable internal
communication and collaboration among the components that populate the software architecture.
The design of a UI incorporates aesthetic elements (e.g., layout, color, graphics, interaction
mechanisms), ergonomic elements (e.g., information layout and placement, metaphors, UI navigation), and
technical elements (e.g., UI patterns, reusable components). In general, the UI is a unique subsystem within
the overall application architecture.
The design of external interfaces requires definitive information about the entity to which
information is sent or received. The design of external interfaces should incorporate error checking and
appropriated security features.
UML defines an interface in the following manner:‖an interface is a specifier for the externally-
visible operations of a class, component, or other classifier without specification of internal structure.‖
MobilePhone
WirelessPDA
Cont rolPanel
LCDdisplay LEDindicat
ors keyPadCharact
erist ics speaker Key Pad
readKeySt roke()
decodeKey ()
displaySt at us()
light LEDs()
readKeyst roke()
decodeKey()
Page 55
56 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
iv. Component- level design elements: The component-level design for software is equivalent to a
set of detailed drawings.
The component-level design for software fully describes the internal detail of each software
component. To accomplish this, the component-level design defines data structures for all local data
objects and algorithmic detail for all processing that occurs within a component and an interface
that allows access to all component operations.
SensorManagement
Sensor
Security homeownerAccess
Personal comput er
externalAccess
Security Surveillance
homeManagement communication
1) SOFTWARE ARCHITECTURE:
What Is Architecture?
Architectural design represents the structure of data and program components that are required
to build a computer-based system. It considers
Page 56
57 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The design of software architecture considers two levels of the design pyramid
data design
architectural design.
Data design enables us to represent the data component of the architecture.
Architectural design focuses on the representation of the structure of software components, their
properties, and interactions.
DATA DESIGN:
The data design activity translates data objects as part of the analysis model into data structures at
the software component level and, when necessary, a database architecture at the application level.
At the program component level, the design of data structures and the associated algorithms required
to manipulate them is essential to the creation of high-quality applications.
At the application level, the translation of a data model (derived as part of requirements
engineering) into a database is pivotal to achieving the business objectives of a system.
At the business level, the collection of information stored in disparate databases and reorganized
into a ―data warehouse‖ enables data mining or knowledge discovery that can have an impact on
the success of the business itself.
To solve this challenge, the business IT community has developed data mining techniques, also
called knowledge discovery in databases (KDD), that navigate through existing databases in an attempt to
extract appropriate business-level information. An alternative solution, called a data warehouse, adds an
additional layer to the data architecture. a data warehouse is a large, independent database that encompasses
some, but not all, of the data that are stored in databases that serve the set of applications required by a
business.
Page 57
58 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The representation of data structure should be known only to those modules that must make
direct use of the data contained within the structure.
A library of useful data structures and the operations that may be applied to them should
be developed.
A software design and programming language should support the specification and realization
of abstract data types.
Page 58
59 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Data-flow architectures. This architecture is applied when input data are to be transformed through a
series of computational or manipulative components into output data. A pipe and filter pattern has a set of
components, called filters, connected by pipes that transmit data from one component to the next. Each
filter works independently of those components upstream and downstream, is designed to expect data input
of a certain form, and produces data output of a specified form.
If the data flow degenerates into a single line of transforms, it is termed batch sequential. This
pattern accepts a batch of data and then applies a series of sequential components (filters) to transform it.
Call and return architectures. This architectural style enables a software designer (system architect) to
achieve a program structure that is relatively easy to modify and scale. A number of substyles [BAS98]
exist within this category:
Main program/subprogram architectures. This classic program structure decomposes function into
a control hierarchy where a ―main‖ program invokes a number of program components, which
in turn may invoke still other components. Figure 13.3 illustrates an architecture of this
type.
Remote procedure call architectures. The components of a main program/ subprogram
architecture are distributed across multiple computers on a network
Page 59
60 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Object-oriented architectures. The components of a system encapsulate data and the operations that must
be applied to manipulate the data. Communication and coordination between components is accomplished
via message passing.
Layered architectures. The basic structure of a layered architecture is illustrated in Figure 14.3. A number
of different layers are defined, each accomplishing operations that progressively become closer to the
machine instruction set. At the outer layer, components service user interface operations. At the inner layer,
components perform operating system interfacing. Intermediate layers provide utility services and
application software functions.
Persistence—Data persists if it survives past the execution of the process that created it. Two patterns
are common:
a database management system pattern that applies the storage and retrieval capability of
a DBMS to the application architecture
an application level persistence pattern that builds persistence features into
the application architecture
Page 60
61 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Distribution— the manner in which systems or components within systems communicate with one another
in a distributed environment
A broker acts as a ‗middle-man‘ between the client component and a server component.
Control.
How is control managed within the architecture?
Does a distinct control hierarchy exist, and if so, what is the role of components within this control
hierarchy?
How do components transfer control within the system?
How is control shared among components?
Data.
How are data communicated between components?
Is the flow of data continuous, or are data objects passed to the system sporadically?
What is the mode of data transfer (i.e., are data passed from one component to another or are data available
globally to be shared among system components)?
Do data components (e.g., a blackboard or repository) exist, and if so, what is their role?
How do functional components interact with data components?
Are data components passive or active (i.e., does the data component actively interact with other
components in the system)? How do data and control interact within the system?
4) ARCHITECTURAL DESIGN:
I Representing the System in Context:
At the architectural design level, a software architect uses an architectural context diagram (ACD) to
model the manner in which software interacts with entities external to its boundaries. The generic structure
of the architectural context diagram is illustrated in the figure
Superordinate systems
Safehome Internet-based
Product system
control
target
panel surveillance
Security Function function
uses
homeowner
uses peers
uses
sensors sensors
Subordinate systems
Superordinate systems – those systems that use the target system as part of some higher level
processing scheme.
Page 61
62 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Subordinate systems - those systems that are used by the target system and provide data or processing
that are necessary to complete target system functionality.
Actors -those entities that interact with the target system by producing or consuming information that
is necessary for requisite processing
II Defining Archetypes:
An archetype is a class or pattern that represents a core abstraction that is critical to the design of
architecture for the target system. In general, a relative small set of archetypes is required to design even
relatively complex systems.
In many cases, archetypes can be derived by examining the analysis classes defined as part of the analysis
model. In safe home security function, the following are the archetypes:
Node: Represent a cohesive collection of input and output elements of the home security
function. For example a node might be comprised of (1) various sensors, and (2) a variety of
alarm indicators.
Detector: An abstraction that encompasses all sensing equipment that feeds information into
the target system
Indicator: An abstraction that represents all mechanisms for indication that an alarm condition
is occurring.
Controller: An abstraction that depicts the mechanism that allows the arming or disarming of
a node. If controllers reside on a network, they have the ability to communicate with one
another.
Controller
communicates with
Node
Detector Indicator
Figure 10.7 UML relat ionships for SafeHome security function archetypes
(adapted f rom [ BOS00])
Page 62
63 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
architecture. Hence, the application domain is one source is the infrastructure domain. The
architecture must accommodate many infrastructure components that enable application domain.
For eg: memory management components, communication components database components, and
task management components are often integrated into the software architecture.
In the safeHome security function example, we might define the set of top-level components that address
the following functionality:
External communication management- coordinates communication of the
security function with external entities
Control panel processing- manages all control panel functionality.
Detector management- coordinates access to all detectors attached to the system.
Alarm processing- verifies and acts on all alarm conditions.
Design classes would be defined for each. It is important to note, however, that the design details of
all attributes and operations would not be specified until component-level design.
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Component Structure
IV Describing Instantiations of the System: An actual instantiation of the architecture means the
architecture is applied to a specific problem with the intent of demonstrating that the structure
and components are appropriate.
Page 63
64 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Execut ive
Ext ernal
Communicat ion
Management
Security
GUI Internet
Interface
Key pad
processing scheduler phone
com m unicat ion
CP display
funct ions
alar
m
sssensornnssoor
senens or
soro
sensor
sensorr
se nso r
Page 64
65 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
System Architecture
Once the interaction between the software system that being designed and the system
environment have been defined
We can use the above information as basis for designing the System Architecture.
Object Identification
This process is actually concerned with identifying the object classes.
We can identify the object classes by the following
1)Use a grammatical analysis
2)Use a tangible entities 3)Use
a behaviourial approach
4) Use a scenario based
approach Design model
Design models are the bridge between the requirements and implementation.
There are two type of design models
1) Static model describe the relationship between the objects.
2)Dynamic model describe the interaction between the objects
Object Interface SpecificationIt is concerned with specifying the details of the interfaces to
an objects.
Design evolution
The main advantage OOD approach is to simplify the problem of making changes to the
design. Changing the internal details of an obect is unlikely to effect any other system object.
Page 65
66 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Define interaction modes in a way that does not force a user into unnecessary or undesired actions.
Word processor – spell checking – move to edit and back; enter and exit with little or no effort
Provide for flexible interaction. Several modes of interaction – keyboard, mouse, digitizer pen or
voice recognition, but not every action is amenable to every interaction need. Difficult to draw a
circle using keyboard commands.
Allow user interaction to be interruptible and undoable. User stop and do something and then resume where
left off. Be able to undo any action.
Streamline interaction as skill levels advance and allow the interaction to be customized. Perform same
actions repeatedly; have macro mechanism so user can customize interface.
Hide technical internals from the casual user. Never required to use OS commands; file management
functions or other arcane computing technology.
Design for direct interaction with objects that appear on the screen. User has feel of control when interact
directly with objects; stretch an object.
Mandel defines design principles that enable an interface to reduce the user‘s memory load:
Page 66
67 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Reduce demand on short-term memory. Complex tasks can put a significant burden on short
term memory. System designed to reduce the requirement to remember past actions and results;
visual cues to recognize past actions, rather than recall them.
Establish meaningful defaults. Initial defaults for average user; but specify individual preferences with
a reset option.
Define shortcuts that are intuitive. Use mnemonics like Alt-P.
The visual layout of the interface should be based on a real world metaphor. Bill payment
– check book and check register metaphor to guide a user through the bill paying process; user
has less to memorize
Disclose information in a progressive fashion. Organize hierarchically. High level of
abstraction and then elaborate. Word underlining function – number of functions, but not all
listed. User picks underlining then all options presented
User Model: The user model establishes the profile of end-users of the system. To build an effective user
interface, "all design should begin with an understanding of the intended users, including profiles of their age,
sex, physical abilities, education, cultural or ethnic background, motivation, goals and personality"
[SHN90]. In addition, users can be categorized as
Novices.
Knowledgeable, intermittent users.
Knowledgeable, frequent users.
Page 67
68 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Design Model: A design model of the entire system incorporates data, architectural, interface
and procedural representations of the software.
Mental Model: The user‘s mental model (system perception) is the image of the system that end-users
carry in their heads.
Implementation Model: The implementation model combines the outward manifestation of the computer-
based system (the look and feel of the interface), coupled with all supporting information (books, manuals,
videotapes, help files) that describe system syntax and semantics.
These models enable the interface designer to satisfy a key element of the most
important principle of user interface design: "Know the user, know the tasks."
The analysis of the user environment focuses on the physical work environment. Among
the questions to be asked are
Where will the interface be located physically?
Will the user be sitting, standing, or performing other tasks unrelated to theinterface?
Does the interface hardware accommodate space, light, or noise constraints?
Are there special human factors considerations driven by environmental factors?
The information gathered as part of the analysis activity is used to create an analysis model for
the interface. Using this model as a basis, the design activity commences.
Page 68
69 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
INTERFACE ANALYUSIS
A Key tenet of all software engineering process models is this: you better understand the problem before you attempt
to design a solution. In the case of user interface design, understanding the problem means understanding (1) The
people who will interact with the system through the interface; (2) the tasks that tend-users must perform to do their
work, (3) the content that is presented as part of the inter face, an (4) the environment in which these tasks will be
conducted. In the sections that follow, we examine each of these elements of interface analysis with the intent of
establishing a solid foundation for the design tasks that follow.
The following set of questions (adapted form (HAC98) ) will help the interface designer better understand the users
of a system:
Are user trained professionals, technicians, clerical or manufacturing workers?
What level of formal education does the average user have?
Are the users capable of learning from written materials or have they ecpressed a desire of
classroom training?
Are users expert typists or keyboard phobic?
What is the age range of the user community?
Will the users be represented predominately by one gender?
How are users compensated for the work they perform?
Do users work normal office hours, or do they work until the job is done.
Is the software to be an integral part of the work users do, or will it be used only occasionally?
Page 69
70 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Task elaboration. Task analysis of interface design uses an elaborative approach to assist in understanding the human
activities the user interface must accommodate. To understand the tasks that must be performed to accomplish the
goal of the activity, a human engineer must understand the tasks that humans currently perform (when using a manual
approach) and then map these into a similar (but not necessarily identical) set of tasks that are implemented in the
context of the user interface. Alternatively, the human engineer can study an existing specification for computer-based
solution and derive a set of user tasks that will accommodate the user model, the design model, and the system
perception. For example, assume that a small software company wants to build a computer-aided design system
explicitly for interior designers. By observing an interior designer at work, the engineer notices that interior design
comprises a number of major activities: further layout (note the use-case discussed earlier), fabric and material
selection, wall and window coverings selection, presentation (to the customer), costing, and shopping. Each of these
major tasks can be elaborated into subtasks. For example, using information contained in the use-case, furniture layout
can be refined into the following tasks: (1) draw a floor plan based on room dimensions; (2) place windows and doors
at appropriate locations;(3a) use furniture templates to draw scaled accents on floor plan(4) move furniture outlines;(6)
draw dimensions to show location;(7) draw perspective rendering view for customer. A similar approach could be
used for each of the other major tasks.
Object elaboration. The software engineer extracts the physical objects that are used by the interior designer. These
objects can be categorized into classes. Attributes of each class are defined, and an evaluation of the actions applied
to each object provide the designer with a list of operations. For example, the furniture template might translate into
a class called Furniture with attributes that might include size, shape, location and others. The interior designer
would select the object from the Furniture class, move it to a position on the floor plan (another object in this context),
draw the furniture outline, and so forth. He tasks select, move, and draw are operations. The user interface analysis
model would not provide a literal implementation for each of these operation for each of these operations. How ever,
as the design is elaborated, the details of each operation are defined.
Workflow analysis. When a number of different users, each playing different roles, makes uses of a user interface,
it is sometimes necessary to go beyond task analysis and object elaboration and apply workflow analysis. This
technique allows a software engineer to understand how a work process is completed when several people are
involved.
The flow of events (shown in the figure) enable the interface designer to recognize three day interface characteristics.
Each user implements different tasks via the interface; therefore, the look and feel of the interface designed
for the patient will be different form the one defined for pharmacists or physicians.
Page 70
71 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The interface design for pharmacists and physicians must accommodate access to and display of information
form secondary information sources(e.g., access to inventory of the pharmacist and access to information
about alternative medications for the physician)
Many of the activities noted in the swimlane diagram can be further elaborated using talk analysis and /or
object elaboration(e.g., fills prescription could imply a mail-order deliver, a visit to a pharmacy, or a visit to
a special drug distribution center.
Hierarchical representation. As the interface is analyzed, a process of elaboration occurs. Once workflow has been
established, a task hierarchy can e defined for each user type. The hierarchy is derived by a stepwise elaboration of
each task identified for the user. For example, consider the user task requests that a prescription be refilled. The
following task hierarchy is developed:
Request that a prescription be refilled
Provide identifying information
Specify name
Specify userid
Specify PIN and password
Specify prescription number
Specify date refill is required
To complete the request that a prescription be refilled tasks, three subtasks are defined. One of these subtasks,
provide indentifying information, is further elaborated in three additional sub-subtasks.
Help facilities. Modern software provides on-line help facilities that enable a user to get a question answered or
resolve a problem without leaving the interface. A number of design issues must be addressed when a help facility is
considered:
Will help be available for all system functions and at all times during system interaction? Options include
help for only a subset of all functions and actions or help for all functions.
How will the user request help? Options include a help menu, a special function day, or a HELP command.
How will help be represented? Options include a separate window, a reference to a printed document, or a
one-or two-line suggestion produced in a fixed screen location.
How will the user return to normal interaction? Options include a return button displayed on the screen, a
function key, or control sequence.
How will help information be structured? Options include a ―flat‖ structure in which all information is
accessed through a keyword, a layered hierarchy or information that provides increasing detail as the user
proceeds into the structure, or the user of hypertext.
In general, every error message or warning produced by an interactive system should have the
following characteristics:
The message should describe the problem in language the user can understand.
The message should provide constructive advice for recovering form the error.
The message should indicate any negative consequences of the error(e.g., potentially corrupted
data files)so that the user can check to ensure that they have not occurred.
The message should be nonjudgmental. That is, the wording should never place blame on the user.
But an-effective error message philosophy can do much to improve the quality of an interactive system and will
significantly reduce user frustration when problems do occur.
A number of design issues arise when typed commands or menu labels are provided as mode of interaction:
Will every menu option have a corresponding command?
Page 71
72 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
What form will commands take? Options include a control sequence (e.g., alt-p), function keys, or
a typed word.
How difficult will it be to learn and remember the commands? What can be done if a command
is forgotten?
Can commands be customized or abbreviated by the user?
Are menu labels self-explanatory within the context of the interface?
Are submenus consistent with the function implied by a master menu item?
Application accessibility .Accessibility for users and software engineers) who may be physically challenged is an
imperative for moral, legal, and business reasons. A variety of accessibility guidelines many designed for Web
applications but often applicable to all types of software-provide detailed suggestions for designing interfaces that
achieve vary8ing levels of accessibility. Others provide specific guidelines or ―assistive technology‖ that addresses
the needs of those with visual, hearing, mobility, speech, and learning impairments.
Internationalization. The challenge should be designed to accommodate a generic core of functionality that can
be delivered to all who use the software. Localization features enable the interface to be customized for a specific
market.
A variety of internationalization guidelines are available to software engineers. These guidelines address broad
design issues and discrete implementation issues. The Unicode standard has been developed to address the daunting
challenge of managing dozens of natural languages with hundred of characters and symbols.
12.5 DESIGN EVALUATION
After the design model has been completed, a first-level prototype is created. The prototype is evaluated by the
user, who provides the designer with direct comments about the efficacy of the interface. In addition, if formal
evaluation techniques are used e.g., questionnaires, rating sheets), the designer may extract information form these
data (e.g., 80percent of all users did not like the mechanism for saving data files). Design modifications are made
based on user input, and the next level prototype is created. The evaluation cycle continues until no further
modifications to the interface design are necessary. If a design model of the interface has been created, a number of
evaluation criteria can be applied during early design reviews:
The length and complexity of the written specification of the system and its interface provide an
indication of the amount of learning required by user of the system.
The number of user tasks specified and the average number of actions per task provide an indication
on interaction time and the overall efficiency of the system.
The number of actions, tasks, and system states indicated by the design model imply the memory load
on users of the system.
Interface styles, help facilities, and error handling protocol provide a general indication of the
complexity of the interface and the degree to which it will be accepted by the user.
Once the first prototype is built, the designer can collect a variety of qualitative and quantitative data that will
assist in evaluating the interface. To collect 2qualitaive data, questionnaires can be distributed to users of the
prototype. Questions can be (1) simple yes/no response, (2) numeric response, (3) scaled (subjective) response,(4)
Likert scales(e.g., strongly.
Users are observed during interaction, and data-such as number of tasks correctly completed over a
standard time period, frequency of actions, sequence of actions, time spent ―looking‖ at the display, number and
types of errors, error recovery time, time spent using help, and number of help references per standard time
period-are collected and used as a guide for interface modification.
Page 72
73 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Page 73
74 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
UNIT-IV
Page 74
75 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
95 percent confidence(probability) that 1000 CPU hours of failure free operation is at least 0.995
Software Testing
• Two major categories of software testing
Black box testing
White box testing
Page 75
76 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Equivalence partitioning
Divides all possible inputs into classes such that there are a finite equivalence classes.
Equivalence class
Set of objects that can be linked by relationship
Reduces the cost of testing
Example
Input consists of 1 to 10
Then classes are n<1,1<=n<=10,n>10
Choose one valid class with value within the allowed range and two invalid classes where
values are greater than maximum value and smaller than minimum value.
Boundary Value analysis
Select input from equivalence classes such that the input lies at the edge of
the equivalence classes
Set of data lies on the edge or boundary of a class of input data or generates the data that lies at
the boundary of a class of output data
Example
If 0.0<=x<=1.0
Then test cases (0.0,1.0) for valid input and (-0.1 and 1.1) for invalid
input Orthogonal array Testing
To problems in which input domain is relatively small but too large for exhaustive testing
Example
Three inputs A,B,C each having three values will require 27 test cases
L9 orthogonal testing will reduce the number of test case to 9 as shown below
A B C
1 1 1
1 2 2
1 3 3
2 1 3
2 2 3
2 3 1
3 1 3
Page 76
77 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
3 2 1
3 3 2
Loop Testing
Focuses on the validity of loop constructs
Four categories can be defined
Simple loops
Nested loops
Concatenated loops
Unstructured loops
Testing of simple loops
-- N is the maximum number of allowable passes through the loop
Page 77
78 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Page 78
79 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Cause Elimination
Based on the concept of Binary partitioning
A list of all possible causes is developed and tests are conducted to eliminate each
Software Quality
Conformance to explicitly stated functional and performance requirements, explicitly
documented development standards, and implicit characteristics that are expected of all
professionally developed software.
Factors that affect software quality can be categorized in two broad groups:
Factors that can be directly measured (e.g. defects uncovered during testing)
2. Factors that can be measured only indirectly (e.g. usability or maintainability)
McCall‘s quality factors
Product operation
Correctness
Reliability
Efficiency
Integrity
Usability
Product Revision
Maintainability
Flexibility
Testability
Product Transition
Portability
Reusability
Interoperability
ISO 9126 Quality
Factors 1.Functionality 2.
Reliability
3. Usability
4.Efficiency
5.Maintainability
6.Portability
Page 79
80 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Product metrics
Product metrics for computer software helps us to assess quality.
Measure
Provides a quantitative indication of the extent, amount, dimension, capacity or size of some attribute
of a product or process
Metric(IEEE 93 definition)
A quantitative measure of the degree to which a system, component or process possess a given attribute
Indicator
A metric or a combination of metrics that provide insight into the software process, a software project
or a product itself
Product Metrics for analysis,Design,Test and maintenance
Product metrics for the Analysis model
❖
Function point Metric
First proposed by Albrecht
Measures the functionality delivered by the system
FP computed from the following parameters
Number of external inputs(EIS)
Number external outputs(EOS)
Number of external Inquiries(EQS)
Number of Internal Logical Files(ILF)
Number of external interface files(EIFS)
Each parameter is classified as simple, average or complex and weights are assigned as follows
• Information Domain Count Simple avg Complex
EIS 3 4 6
EOS 4 5 7
EQS 3 4 6
ILFS 7 10 15
EIFS 5 7 10
Page 80
81 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
SOFTWARE MEASUREMENT
Software measurement can be categorized in two ways.
Direct measures of the software engineering process include cost and effort applied. Direct
measures of the product include lines of code (LOC) produced, execution speed, memory size, and
defects reported over some set period of time.
Page 81
82 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Indirect measures of the product include functionality, quality, complexity, efficiency, reliability,
maintainability, and many other "–abilities"
Size-Oriented Metrics
Size-oriented software metrics are derived by normalizing quality and/or productivity measures
by considering the size of the software that has been produced.
To develop metrics that can be assimilated with similar metrics from other projects, we choose lines of
code as our normalization value. From the rudimentary data contained in the table, a set of simple size-
oriented metrics can be developed for each project:
Errors per KLOC (thousand lines of code).
Defects per KLOC.
$ per LOC.
Page of documentation per KLOC.
In addition, other interesting metrics can be computed:
Errors per person-month.
LOC per person-month.
$ per page of documentation.
Function-Oriented Metrics
Function-oriented software metrics use a measure of the functionality delivered by the application as a
normalization value. Since ‗functionality‘ cannot be measured directly, it must be derived indirectly using other
direct measures. Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the
function point. Function points are derived using an empirical relationship based on countable (direct)
measures of software's information domain and assessments of software complexity.
Proponents claim that FP is programming language independent, making it ideal for application
using conventional and nonprocedural languages, and that it is based on data that are more likely
to be known early in the evolution of a project, making FP more attractive as an estimation approach.
Opponents claim that the method requires some ―sleight of hand ‖ in that computation is
basedsubjective rather than objective data, that counts of the information domain can be difficult to
collect after the fact, and that FP has no direct physical meaning- it‘s just a number.
Typical Function-Oriented Metrics:
errors per FP (thousand lines of code)
defects per FP
$ per FP
pages of documentation per FP
FP per person-month
Page 82
83 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Page 83
84 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
To measure integrity, two additional attributes must be defined: threat and security. Threat is the
probability (which can be estimated or derived from empirical evidence) that an attack of a specific
type will occur within a given time. Security is the probability (which can be estimated or derived from
empirical evidence) that the attack of a specific type will be repelled. The integrity of
a system can then be defined as
integrity = ∑ [1 – – security))]
Usability: Usability is an attempt to quantify user-friendliness and can be measured in terms of four
characteristics:
Page 84
85 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
UNIT-V
RISK MANAGEMENT
A proactive strategy begins long before technical work is initiated. Potential risks are identified,
their probability and impact are assessed, and they are ranked by importance. Then, the software team
establishes a plan for managing risk.
formal risk analysis is performed
organization corrects the root causes of risk
o examining risk sources that lie beyond the bounds of the software
o developing the skill to manage change
SOFTWARE RISK
Risk always involves two characteristics
Uncertainty—the risk may or may not happen; that is, there are no 100% probable risks
Loss—if the risk becomes a reality, unwanted consequences or losses will occur.
When risks are analyzed, it is important to quantify the level of uncertainty in the degree of loss
associated with each risk. To accomplish this, different categories of risks are considered.
Project risks threaten the project plan. That is, if project risks become real, it is likely that project schedule
will slip and that costs will increase.
Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk
becomes a reality, implementation may become difficult or impossible. Technical risks identify
potential design, implementation, interface, verification, and maintenance problems.
Business risks threaten the viability of the software to be built. Business risks often jeopardize the
project or the product. Candidates for the top five business risks are
Building a excellent product or system that no one really wants (market risk),
Building a product that no longer fits into the overall business strategy for the company (strategic risk),
Page 85
86 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Building a product that the sales force doesn't understand how to sell,
Losing the support of senior management due to a change in focus or a change in people
(management risk), and
Losing budgetary or personnel commitment (budget risks).
Known risks are those that can be uncovered after careful evaluation of the project plan, the business
and technical environment in which the project is being developed, and other reliable information sources.
Predictable risks are extrapolated from past project experience.
Unpredictable risks are the joker in the deck. They can and do occur, but they are
extremely difficult to identify in advance.
2) RISK IDENTIFICATION
Risk identification is a systematic attempt to specify threats to the project plan. There are two distinct
types of risks.
Generic risks and
product-specific risks.
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 project that is to be built.
Known and predictable risks in the following generic subcategories:
Product size—risks associated with the overall size of the software to be built or modified.
Business impact—risks associated with constraints imposed by management or the marketplace.
Customer characteristics—risks associated with the sophistication of the customer and the
developer's ability to communicate with the customer in a timely manner.
Process definition—risks associated with the degree to which the software process has been defined
and is followed by the development organization.
Development environment—risks associated with the availability and quality of the tools to be used to
build the product.
Technology to be built—risks associated with the complexity of the system to be built and the
"newness" of the technology that is packaged by the system.
Staff size and experience—risks associated with the overall technical and project experience of the
software engineers who will do the work.
Page 86
87 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The impact of each risk driver on the risk component is divided into one of four impact categories—
negligible, marginal, critical, or catastrophic.
RISK PROJECTION
Risk projection, also called risk estimation, attempts to rate each risk in two ways—the likelihood or
probability that the risk is real and the consequences of the problems associated with the risk, should it occur.
The project planner, along with other managers and technical staff, performs four risk projection activities:
establish a scale that reflects the perceived likelihood of a risk,
delineate the consequences of the risk,
estimate the impact of the risk on the project and the product, and
note the overall accuracy of the risk projection so that there will be no misunderstandings.
A project team begins by listing all risks (no matter how remote) in the first column of the table.
Each risk is categorized in Next; the impact of each risk is assessed.
The categories for each of the four risk components—performance, support, cost, and schedule—
are averaged to determine an overall impact value.
High-probability, high-impact risks percolate to the top of the table, and low-probability risks
drop to the bottom. This accomplishes first-order risk prioritization.
The project manager studies the resultant sorted table and defines a cutoff line.
The cutoff line (drawn horizontally 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 re-evaluated to accomplish second-order
prioritization.
4.2 Assessing Risk Impact
Three factors affect the consequences that are likely if a risk does occur: its nature, its scope, and its timing.
The nature of the risk indicates the problems that are likely if it occurs.
The scope of a risk combines the severity (just how serious is it?) with its overall distribution.
Finally, the timing of a risk considers when and for how long the impact will be felt.
Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact,
be integrated into the application. The remaining functionality will have to be custom developed.
Page 87
88 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
The total risk exposure for all risks (above the cutoff in the risk table) can provide a means for adjusting the
final cost estimate for a project etc.
RISK REFINEMENT
One way for risk refinement is to represent the risk in condition-transition-consequence(CTC)
format. This general condition can be refined in the following manner:
Sub condition 1. Certain reusable components were developed by a third party with no knowledge
of internal design standards.
Sub condition 2. The design standard for component interfaces has not been solidified and may
not conform to certain existing reusable components.
Sub condition 3. Certain reusable components have been implemented in a language that is not supported
on the target environment.
Software safety and hazard analysis are software quality assurance activities that focus on the identification
and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If
hazards can be identified early in the software engineering process, software design features can be specified
that will either eliminate or control potential hazards.
Page 88
89 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
QUALITY MANAGEMENT
1) QUALITY CONCEPTS:
Quality management encompasses
a quality management approach,
effective software engineering technology (methods and tools),
formal technical reviews that are applied throughout the software process,
a multitiered testing strategy,
control of software documentation and the changes made to it,
a procedure to ensure compliance with software development standards (when applicable), and
measurement and reporting mechanisms.
Variation control is the heart of quality control.
Quality
The American Heritage Dictionary defines quality as ―a characteristic or attribute of something.‖
Quality of design refers to the characteristics that designers specify for an item.
Quality of conformance is the degree to which the design specifications are followed during
manufacturing.
In software development, quality of design encompasses requirements, specifications, and the design of
the system. Quality of conformance is an issue focused primarily on implementation. If the
implementation follows the design and the resulting system meets its requirements and performance goals,
conformance quality is high.
Robert Glass argues that a more ―intuitive‖ relationship is in order:
User satisfaction = compliant product + good quality + delivery within budget and schedule
Quality costs may be divided into costs associated with prevention, appraisal, and failure.
Prevention costs include
quality planning
formal technical reviews
test equipment
training
Page 89
90 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Appraisal costs include activities to gain insight into product condition the ―first time through‖
each process. Examples of appraisal costs include
in-process and interprocess inspection
equipment calibration and maintenance
testing
Failure costs are those that would disappear if no defects appeared before shipping a product to
customers. Failure costs may be subdivided into internal failure costs and external failure costs.
Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure
costs include
rework
repair
failure mode analysis
External failure costs are associated with defects found after the product has been shipped to the
customer. Examples of external failure costs are
complaint resolution
product return and replacement
help line support
warranty work
Background Issues
The first formal quality assurance and control function was introduced at Bell Labs in 1916 and
spread rapidly throughout the manufacturing world. During the 1940s, more formal approaches to quality
control were suggested. These relied on measurement and continuous process improvement as key elements of
quality management.Today, every company has mechanisms to ensure quality in its products.
During the early days of computing (1950s and 1960s), quality was the sole responsibility of
the programmer. Standards for quality assurance for software were introduced in military contract
software development during the 1970s.
Extending the definition presented earlier, software quality assurance is a "planned and systematic
pattern of actions" that are required to ensure high quality in software. The scope of quality assurance
responsibility might best be characterized by paraphrasing a once-popular automobile commercial:
"Quality Is Job #1." The implication for software is that many different constituencies have software
quality assurance responsibility—software engineers, project managers, customers, salespeople, and the
individuals who serve within an SQA group.
The SQA group serves as the customer's in-house representative. That is, the people who
perform SQA must look at the software from the customer's point of view
Page 90
91 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Prepares an SQA plan for a project. The plan is developed during project planning and is reviewed by
all interested parties. Quality assurance activities performed by the software engineering team and the SQA
group are governed by the plan. The plan identifies
evaluations to be performed
audits and reviews to be performed
standards that are applicable to the project
procedures for error reporting and tracking
documents to be produced by the SQA group
amount of feedback provided to the software project team
Participates in the development of the project’s software process description. The software team
selects a process for the work to be performed. The SQA group reviews the process description for
compliance with organizational policy, internal software standards, externally imposed standards
(e.g., ISO-9001), and other parts of the software project plan.
Reviews software engineering activities to verify compliance with the defined software process. The
SQA group identifies, documents, and tracks deviations from the process and verifies that corrections
have been made.
Audits designated software work products to verify compliance with those defined as part of the
software process. The SQA group reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made; and periodically reports the results of its work to
the project manager.
Ensures that deviations in software work and work products are documented and handled
according to a documented procedure.Deviations may be encountered in the project plan, process
description, applicable standards, or technical work products.
Records any noncompliance and reports to senior management. Noncompliance items are tracked
until they are resolved.
3) SOFTWARE REVIEWS
Software reviews are a "filter" for the software engineering process. That is, reviews are applied at
various points during software development and serve to uncover errors and defects that can then be
removed. Software reviews "purify" the software engineering activities that we have called analysis,
design, and coding.
Many different types of reviews can be conducted as part of software engineering. Each has
its place. An informal meeting around the coffee machine is a formof review, if technical problems are
discussed. A formal presentation of software design to an audience of customers, management, and
technical staff is also a form of review
A formal technical review is the most effective filter from a quality assurance standpoint. Conducted
by software engineers (and others) for software engineers, the FTR is an effective means for improving
software quality.
Page 91
92 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
during testing, 15 units;
and after release, between 60 and 100 units.
Page 92
93 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Limit debate and rebuttal. When an issue is raised by a reviewer, there may not be universal
agreement on its impact.
Enunciate problem areas, but don't attempt to solve every problem noted. A review is not a
problem-solving session. The solution of a problem can often be accomplished by the producer alone
or with the help of only one other individual. Problem solving should be postponed until after the
review meeting.
Take written notes. It is sometimes a good idea for the recorder to make notes on a wall board, so
that wording and priorities can be assessed by other reviewers as information is recorded.
Limit the number of participants and insist upon advance preparation. Keep the number of people
involved to the necessary minimum.
Develop a checklist for each product that is likely to be reviewed. A checklist helps the review
leader to structure the FTR meeting and helps each reviewer to focus on important issues. Checklists
should be developed for analysis, design, code, and even test documents.
Allocate resources and schedule time for FTRs. For reviews to be effective, they should be
scheduled as a task during the software engineering process
Conduct meaningful training for all reviewers. To be effective all review participants should
receive some formal training.
Review your early reviews. Debriefing can be beneficial in uncovering problems with the review
process itself.
SDRs attempt to quantify those work products that are primary targets for full FTRs.To accomplish this
the following steps are suggested…
Inspect a fraction ai of each software work product, i. Record the number of faults, fi found within
a i.
• Develop a gross estimate of the number of faults within work product i by multiplying fi by 1/ai.
Sort the work products in descending order according to the gross estimate of the number of faults
in each.
Focus available review resources on those work products that have the highest estimated number
of faults.
The fraction of the work product that is sampled must
Be representative of the work product as a whole and
Large enough to be meaningful to the reviewer(s) who does the sampling.
Page 93
94 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
Measure the existing process and its output to determine current quality performance (collect
defect metrics)
Analyze defect metrics and determine the vital few causes.
If an existing software process is in place, but improvement is required, Six Sigma suggests two
additional steps.
Improve the process by eliminating the root causes of defects.
Control the process to ensure that future work does not reintroduce the causes of defects
These core and additional steps are sometimes referred to as the DMAIC (define, measure,
analyze, improve, and control) method.
If any organization is developing a software process (rather than improving and existing process),
the core steps are augmented as follows:
Design the process to
o avoid the root causes of defects and
o to meet customer requirements
Verify that the process model will, in fact, avoid defects and meet customer requirements. This
variation is sometimes called the DMADV (define, measure, analyze, design and verify) method.
SOFTWARE RELIABILITY
Software reliability is defined in statistical terms as "the probability of failure-free operation of
a computer program in a specified environment for a specified time".
Page 94
95 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
In addition to a reliability measure, we must develop a measure of availability. Software availability is the
probability that a program is operating according to requirements at a given point in time and is defined as
Availability = [MTTF/(MTTF + MTTR)] 100%
The MTBF reliability measure is equally sensitive to MTTF and MTTR. The availability measure
is somewhat more sensitive to MTTR, an indirect measure of the maintainability of software.
Once hazards are identified and analyzed, safety-related requirements can be specified for the
software. That is, the specification can contain a list of undesirable events and the desired system
responses to these events. The role of software in managing undesirable events is then indicated.
Although software reliability and software safety are closely related to one another, it is
important to understand the subtle difference between them. Software reliability uses statistical analysis to
determine the likelihood that a software failure will occur. However, the occurrence of a failure does not
necessarily result in a hazard or mishap. Software safety examines the ways in which failures result in
conditions that can lead to a mishap.
Page 95
96 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
characteristics and the percent of efficiency for detecting errors, a function of the thoroughness of
the review.
Referring to the figure8.3 each test step is assumed to uncover and correct 50 percent of all incoming
errors without introducing any new errors (an optimistic assumption). Ten preliminary design defects are
amplified to 94 errors before testing commences. Twelve latent errors are released to the field.
Figure8.4 considers the same conditions except that design and code reviews are conducted as part
of each development step. In this case, ten initial preliminary design errors are amplified to 24 errors before
testing commences. Only three latent errors exist.
Recalling the relative costs associated with the discovery and correction of errors, overall cost (with
and without review for our hypothetical example) can be established. The number of errors uncovered during
each of the steps noted in Figures 8.3 and 8.4 is multiplied by the cost to remove an error (1.5 cost units for
design, 6.5 cost units before test, 15 cost units during test, and 67 cost units after release).
Using these data, the total cost for development and maintenance when reviews are
conducted is 783 cost units.
When no reviews are conducted, total cost is 2177 units—nearly three times more
costly.
To conduct reviews, a software engineer must expend time and effort and the development
organization must spend money. Formal technical reviews (for design and other technical activities)
provide a demonstrable cost benefit. They should be conducted.
FIGURE 8.3
Defect amplification, no reviews
Page 96
97 SOFTWARE ENGINEERING – Material
SOFTWARE ENGINEERING
FIGURE 8.4
Defect amplification, reviews conducted
Page 97