cs2301 se 16marks
DESCRIPTION
important 16 mark quesTRANSCRIPT
www.nskinfo.com- College Student and Faculty Website
Department Of nskinfo i-education
CS2301-Software Engineering-16MARKS
www.nsksofttech.com- AnnaUniversity Chennai all department soft
copy question paper& More than 500 c&c++ programs coming
soon…………………….
1
CS2301 SOFTWARE ENGINNERING
IMPORTANT SIXTEEN MARKS QUESTIONS
UNIT – I – SOFTWARE PRODUCT AND PROCESS
Introduction – S/W Engineering Paradigm – Verification – Validation – Life
Cycle Models – System Engineering – Computer Based System – Business
Process Engineering Overview – Product Engineering Overview.
1. Explain the Water Fall Software Process Model with neat diagram.
The waterfall model is the classical model of software engineering. This
model is one of the oldest models and is widely used in government projects and in
many major companies. As this model emphasizes planning in early stages, it
ensures design flaws before they develop. In addition, its intensive document and
planning make it work well for projects in which quality control is a major
concern. It is used when requirements are well understood in the beginning and
also called as classic life cycle. A systematic, sequential approach to Software
development begins with customer specification of Requirements and progresses
through planning, modeling, construction and deployment. This Model suggests a
systematic, sequential approach to software development that begins at the system
level and progresses through analysis, design, code and testing. The waterfall
method does not prohibit returning to an earlier phase, for example, returning from
the design phase to the requirements phase. However, this involves costly rework.
Each completed phase requires formal review and extensive documentation
development. Thus, oversights made in the requirements phase are expensive to
correct later.
Advantages:
1. Easy to understand and implement.
2. Widely used and known
3. Reinforces good habits: define-before- design, design-before-code.
4. Works well on mature products and weak teams.
Disadvantages:
2
1. Idealized doesn’t match reality well.
2. Unrealistic to expect accurate requirements so early in project.
3. Difficult to integrate risk management.
2. Explain the Spiral S/W Process Model with neat diagram.
The spiral model is similar to the incremental model, with more emphases
placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis,
Engineering and Evaluation. A software project repeatedly passes through these
phases in iterations. The baseline spiral, starting in the planning phase,
requirements is gathered and risk is assessed. Each subsequent spiral builds on the
baseline spiral. Requirements are gathered during the planning phase. In the risk
analysis phase, a process is undertaken to identify risk and alternate solutions. A
prototype is produced at the end of the risk analysis phase. Software is produced in
the engineering phase, along with testing at the end of the phase. The evaluation
phase allows the customer to evaluate the output of the project to date before the
project continues to the next spiral. In the spiral model, the angular component
represents progress, and the radius of the spiral represents cost.
The task regions of Spiral Model are,
Customer communication:
Tasks required are establishing effective communication between developer and
planning.
Estimation
Scheduling
Risk analysis
3
Risk analysis:
Analysis and Design
Construct and release:
Code and Test
Customer evaluation:
Delivery and Feedback
Advantages:
1. High amount of risk analysis.
2. Good for large and mission-critical projects.
3. Software is produced early in the software life cycle.
Disadvantages:
1. Can be a costly model to use.
2. Risk analysis requires highly specific expertise.
3. Project’s success is highly dependent on the risk analysis phase.
4. Doesn’t work well for smaller projects.
3. Explain System Engineering Process in detail.
System engineering process follows a waterfall model for the parallel
development of different parts of the system. Specifying, designing, implementing,
validating, deploying and maintaining socio-technical systems. Concerned with the
services provided by the system, constraints on its construction and operation and the
ways in which it is used. Usually follows a ‘waterfall’ model because of the need for
parallel development of different parts of the system. There is a little scope for
iteration between phases because hardware changes are very expensive. Software
may have to compensate for hardware problems. Inevitably involves engineers from
different disciplines who must work together. Also there is a much scope for
misunderstanding. Different disciplines use a different vocabulary and much
negotiation is required. Engineers may have personal agendas to fulfil.
4
SYSTEM REQUIREMENTS DEFINITION:
Three types of requirement defined at this stage
Abstract functional requirements: System functions are defined in an
abstract way;
System properties: Non-functional requirements for the system in general are
defined;
Undesirable characteristics: Unacceptable system behaviour is specified.
THE SYSTEM DESIGN PROCESS:
Process steps:
Partition requirements:
Organise requirements into related groups.
Identify sub-systems:
Identify a set of sub-systems which collectively can meet the system
requirements.
Assign requirements to sub-systems:
Causes particular problems when COTS are integrated.
Specify sub-system functionality
Define sub-system interfaces:
5
Critical activity for parallel sub-system development.
SUB-SYSTEM DEVELOPMENT PROCESS:
Typically parallel projects developing the hardware, software and
communications may involve some COTS (Commercial Off-the-Shelf) systems
procurement. This involves Lack of communication across implementation teams.
Bureaucratic and slow mechanism for proposing system changes means that the
development schedule may be extended because of the need for rework.
SYSTEM INTEGRATION:
The process of putting hardware, software and people together to make a system
is called System Integration. This should be tackled incrementally so that sub-systems
are integrated one at a time. Interface problems between sub-systems are usually
found at this stage and may be problems arises with uncoordinated deliveries of
system components.
SYSTEM INSTALLATION:
System Installation Issues are,
Environmental assumptions may be incorrect.
There may be human resistance to the introduction of a new system.
System may have to coexist with alternative systems for some period.
There may arise some physical installation problems (e.g. cabling problem).
Operator training has to be identified.
SYSTEM EVOLUTION:
The lifetime of large systems is too long. They must evolve to meet change
requirements. The evolution may be costly. Existing systems that must be
maintained are sometimes called as legacy systems.
SYSTEM DECOMMISSIONING:
Taking the system out of service after its useful lifetime is called as System
Decommissioning.
4. Write short notes on Business Process Engineering overview and
Product Engineering overview?
BUSINESS PROCESS ENGINEERING:
“Business process” engineering defines architectures that will enable a
business to use information effectively. It involves the specification of the
appropriate computing architecture and the development of the software
architecture for the organization's computing resources. There are three different
architectures must be analyzed and designed within the context of business
objectives and goals,
6
The data architecture provides a framework for the information needs of a
business (e.g., ERD)
The application architecture encompasses those elements of a system that
transform objects within the data architecture for some business purpose
The technology infrastructure provides the foundation for the data and
application architectures. It includes the hardware and software that are
used to support the applications and data
PRODUCT ENGINEERING:
Product engineering translates the customer's desire for a set of defined
capabilities into a working product. It achieves this goal by establishing product
architecture and a support infrastructure. Product architecture components consist
of people, hardware, software, and data. Support infrastructure includes the
technology required to tie the components together and the information to support
the components.
Requirements engineering elicits the requirements from the customer and
allocates function and behavior to each of the four components.
System component engineering happens next as a set of concurrent
activities that address each of the components separately. Each component
takes a domain-specific view but maintains communication with the other
domains. The actual activities of the engineering discipline take on an
element view.
Analysis modeling allocates requirements into function, data, and behavior.
7
Design modeling maps the analysis model into data/class, architectural,
interface, and component design.
UNIT – II – SOFTWARE REQUIREMENTS
Functional and Non-Functional – Software Document – Requirement
Engineering Process – Feasibility Studies – Software Prototyping –
Prototyping in the Software Process – Data – Functional and Behavioral
Models – Structured Analysis and Data Dictionary.
1. What is Software Prototyping? Explain the prototyping approaches in
software process?
SOFTWARE PROTOTYPING:
Prototyping is the rapid development of a system. The principal use is to help
customers and developers understand the requirements for the system
Requirements elicitation – Users can experiment with a prototype to see
how the system supports their work
8
Requirements validation – The prototype can reveal errors and omissions
in the requirements.
Prototyping can be considered as a risk reduction activity.
PROTOTYPING APPROACHES IN SOFTWARE PROCESS:
Evolutionary
prototyping
Throw-away
Prototyping
Delivered
system
Executable Prototype +System Specification
OutlineRequirements
There are Two Approaches,
Evolutionary prototyping - In this approach of system development, the initial
prototype is prepared and it is then refined through number of stages to final stage.
Throw-away prototyping - Using this approach a rough practical implementation of
the system is produced. The requirement problems can be identified from this
implementation. It is then discarded. System is then developed using some different
engineering paradigm.
EVOLUTIONARY PROTOTYPING:
Objective:
The principal objective of this model is to deliver the working system to the
end-user. Example: AI systems. Based on techniques which allow rapid system
iterations Verification is impossible as there is no specification. Validation means
demonstrating the adequacy of the system.
The Specification, design and implementation are inter-twined. The system is
developed as a series of increments that are delivered to the customer. Techniques
for rapid system development are used such as CASE tools and 4GLs. User
interfaces are usually developed using a GUI development toolkit.
9
Advantages:
Fast delivery of the working system
User is involved while developing the system
More useful system can be delivered.
Problems:
Management problems
Maintenance problem
Verification
THROW-AWAY PROTOTYPING:
Objective:
The principal objective of this model is to validate or to derive the system
requirements. It is developed to reduce requirement risks.
Outline
requirements
Develop
prototype
Evaluate
prototype
Specify
system
Developsoftware
Validatesystem
Deliveredsoftwaresystem
Reusablecomponents
The prototype is developed from an initial specification, delivered for
experiment then discarded.
Advantage:
Requirement risks are very less.
Problems:
It can be undocumented.
Changes made during the software development proceed may degrade the
system structure.
Sometimes organizational quality standard may not be strictly applied.
INCREMENTAL DEVELOPMENT:
System is developed and delivered in increments after establishing an overall
architecture. Requirements and specifications for each increment may be
developed. Users may experiment with delivered increments while others are being
developed.
10
Validateincrement
Build system
incrementSpecify system
incrementDesign system
architecture
Define system
deliverables
Systemcomplete?
Integrateincrement
Validatesystem
Deliver finalsystem
YES
NO
Therefore, these serve as a form of prototype system. The main intension is to
combine some of the advantages of prototyping but with a more manageable
process and better system structure.
2. With suitable examples and required diagrammatic representation
explain the Functional Modeling in detail.
All functional models really do is describe the computational structure of the
system. On the other hand, this system – even though it may have many Use
Cases should only have one functional model, yet this may be composed of many
functional diagrams. Furthermore, the activity of creating a functional model is
commonly known as functional modeling. A functional model describes how the
system is changing. This can be best viewed with an Activity Diagram which
shows how we change from one state to another depends on what actions are
being performed or the overall state of the system. This leads me to the key
feature (subject) of a functional model Functions and Flows. It can be representing
as with the help of functional diagrams. For example:
Activity Diagrams
Use Case Diagrams
Context Model
ACTIVITY DIAGRAM:
The purpose of an activity diagram is to represent data and activity flows in an
application. The components are, within an activity diagram there are many key
modeling concepts, here is a select main few of them:
An activity represents an action or a set of actions to be taken.
This is a control flow. It shows the sequence of execution.
This is the initial start node – the beginning of the set of actions (the start
basically)
11
This is the Final node. It stops all flow in an activity diagram.
This is a decision node. It represents a test condition much like an IF
statement.
USE CASE DIAGRAM:
They are diagrams to help aid the creation, visualization and documentation of
various aspects of the software engineering process.
Use Cases come in pairs, so we have
Use Case Diagram: an overview of the system
Use Case Description: details about each function
An Actor is something that performs use cases upon a system. An Actor is just
an entity, meaning it can be a Human or other artifacts that directly play an
external role in the system – as long as they either directly use the system or is
used by the system. For each Use Case we have to know entry conditions
(preconditions) and Exit conditions (post-conditions), so basically “What is true
before the Use Case” and “What is true after the Use Case”.
CONTEXT MODEL:
Context models are used to illustrate the boundaries of a system. 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.
Example for Context Model is the ATM Systems,
Auto-tellersystem
Securitysystem
Maintenancesystem
Accountdatabase
Usagedatabase
Branchaccounting
system
Branchcountersystem
12
3. With suitable examples and required diagrammatic representation
explain the Behavioral Modeling in detail.
Behavioural models are used to describe the overall behaviour of a system. Two
types of behavioural model are,
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
Both of these models are required for a description of the system’s behaviour.
DATA PROCESSING MODELS:
Data flow diagrams are used to model the system’s data processing. These
show the processing steps as data flows through a system. Intrinsic part of many
analysis methods. Simple and intuitive notation by which the customers can
understand and it shows end-to-end processing of data.
DATA FLOW DIAGRAMS:
DFDs model the system from a functional perspective. Tracking and
documenting how the data associated with a process is helpful to develop an
overall understanding of the system. Data flow diagrams may also be used in
showing the data exchange between a system and other systems in its
environment.
Completeorder form
Orderdetails +
blank
order form
Valida teorder
Recordorder
Send tosupplier
Adjustavailablebudget
Budgetfile
Ordersfile
Completedorder form
Signedorder form
Signedorder form
Checked andsigned order
+ ordernotification
Orderamount
+ accountdetails
Signedorder form
Orderdetails
STATE MACHINE MODELS:
These model the behaviour of the system in response to external and internal
events. They show the system’s responses to stimuli so are often used for modelling
real-time systems. State machine models show system states as nodes and events as
arcs between these nodes. When an event occurs, the system moves from one state to
another. State charts are an integral part of the UML.
13
Example for State Machine Model is the Microwave Oven Model,
Full power
Enabled
do: operateoven
Fullpower
Halfpower
Halfpower
Fullpower
Number
TimerDooropen
Doorclosed
Doorclosed
Dooropen
Start
do: set power = 600
Half power
do: set power = 300
Set time
do: get numberexit: set time
Disabled
Operation
Timer
Cancel
Waiting
do: display time
Waiting
do: display time
do: display 'Ready'
do: display 'Waiting'
4. Explain the various functionalities accomplished in the Requirement
Engineering Process in detail.
OBJECTIVES:
To describe the principal requirements engineering activities and their
relationships
To introduce techniques for requirements elicitation and analysis
To describe requirements validation and the role of requirements reviews
To discuss the role of requirements management in support of other
requirements engineering processes
REQUIREMENTS ENGINEERING PROCESS:
The processes used for RE vary widely depending on the application domain,
the people involved and the organisation developing the requirements. There are a
number of generic activities common to all processes.
Requirements Elicitation;
Requirements Analysis;
Requirements Validation;
Requirements Management.
14
FEASIBILITY STUDIES:
A feasibility study decides whether or not the proposed system is worthwhile.
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; if the system can be integrated with other systems that are used.
ELICITATION AND ANALYSIS:
Sometimes called requirements elicitation or requirements discovery. Involves
technical staff working with customers to find out about the application domain,
the services that the system should provide and the system’s operational
constraints. May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions, etc. These are called stakeholders.
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 Validation Techniques:
Requirements reviews: Systematic manual analysis of the requirements.
Prototyping: Using an executable model of the system to check requirements.
Test-case generation: Developing tests for requirements to check testability.
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
15
the system is developed; Different viewpoints have different requirements and
these are often contradictory.
During the requirements engineering process plan,
Requirements identification: How requirements are individually identified;
A change management process: The process followed when analysing a
requirements change;
Traceability policies: The amount of information about requirements
relationships that is maintained;
CASE tool support: The tool support required to help manage requirements
change;
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;
Case Tool Support:
Requirements storage
Requirements should be managed in a secure, managed data store.
Change management
The process of change management is a workflow process whose stages can
be defined and information flow between these stages partially automated.
Change Management:
Should apply to all proposed changes to the requirements.
Principal stages
Problem analysis. Discuss requirements problem and propose change;
Change analysis and costing. Assess effects of change on other requirements;
Change implementation modifies requirements document and other documents to
reflect change.
16
UNIT – III – ANALYSIS, DESIGN CONCEPTS AND PRINCIPLES
Systems Engineering - Analysis Concepts - Design Process And Concepts –
Modular Design – Design Heuristic – Architectural Design – Data Design – User
Interface Design – Real Time Software Design – System Design – Real Time
Executives – Data Acquisition System – Monitoring And Control System.
1. Explain the Modular Design with necessary diagrams.
EFFECTIVE MODULAR DESIGN:
Modularity has become an accepted approach in all engineering disciplines. A
modular design reduces complexity, facilitates change, and results in easier
implementation by encouraging parallel development of different parts of a system.
FUNCTIONAL INDEPENDENCE:
The concept of functional independence is a direct outgrowth of modularity
and the concepts of abstraction and information hiding. Functional independence
is achieved by developing modules with "single-minded" function and an
"aversion" to excessive interaction with other modules. Stated another way, we
want to design software so that each module addresses a specific sub function of
requirements and has a simple interface when viewed from other parts of the
program structure. It is fair to ask why independence is important. Software with
effective modularity, that is, independent modules, is easier to develop because
function may be compartmentalized and interfaces are simplified. Independent
modules are easier to maintain because secondary effects caused by design or code
modification are limited, error propagation is reduced, and reusable modules are
possible. To summarize, functional independence is a key to good design, and
design is the key to software quality. Independence is measured using two
qualitative criteria: cohesion and coupling. Cohesion is a measure of the relative
functional strength of a module. Coupling is a measure of the relative
interdependence among modules.
COHESION:
Cohesion is a natural extension of the information hiding concept. A cohesive
module performs a single task within a software procedure, requiring little
interaction with procedures being performed in other parts of a program. Stated
simply, a cohesive module should do just one thing. Cohesion may be represented
as a "spectrum." We always strive for high cohesion, although the mid-range of the
spectrum is often acceptable. Low-end cohesiveness is much "worse" than middle
range, which is nearly as "good" as high-end cohesion. In practice, a designer need
not be concerned with categorizing cohesion in a specific module. Rather, the
overall concept should be understood and low levels of cohesion should be avoided
when modules are designed. At the low end of the spectrum, we encounter a
module that performs a set of tasks that relate to each other loosely, if at all. Such
modules are termed coincidentally cohesive. A module that performs tasks that are
related logically is logically cohesive. e.g., one module may read all kinds of input.
When a module contains tasks that are related by the fact that all must be executed
17
with the same span of time, the module exhibits temporal cohesion. As an
example of low cohesion, consider a module that performs error processing for an
engineering analysis package. The module is called when computed data exceed
pre-specified bounds. It performs the following tasks: (1) computes supplementary
data based on original computed data, (2) produces an error report on the user's
workstation, (3) performs follow-up calculations requested by the user, (4) updates
a database, and (5) enables menu selection for subsequent processing. Although the
preceding tasks are loosely related, each is an independent functional entity that
might best be performed as a separate module. Combining the functions into a
single module can serve only to increase the likelihood of error propagation when a
modification is made to one of its processing tasks. Moderate levels of cohesion
are relatively close to one another in the degree of module independence. When
processing elements of a module are related and must be executed in a specific
order, procedural cohesion exists. When all processing elements concentrate on
one area of a data structure, communicational cohesion is present. High cohesion
is characterized by a module that performs one distinct procedural task.
COUPLING:
Coupling is a measure of interconnection among modules in a software
structure. Coupling depends on the interface complexity between modules, the
point at which entry or reference is made to a module, and what data pass across
the interface. In software design, we strive for lowest possible coupling. Simple
connectivity among modules results in software that is easier to understand and
less prone to a "ripple effect", caused when errors occur at one location and
propagates through a system.
Modules a and d are subordinate to different modules. Each is unrelated and
therefore no direct coupling occurs. Module c is subordinate to module a and is
accessed via a conventional argument list, through which data are passed. As long
as a simple argument list is present, low coupling is exhibited in this portion of
structure. A variation of data coupling, called stamp coupling is found when a
portion of a data structure is passed via a module interface. This occurs between
18
modules b and a. At moderate levels, coupling is characterized by passage of
control between modules. Control coupling is very common in most software
designs and is shown in Figure 1 where a “control flag” is passed between modules
d and e. High coupling occurs when a number of modules reference a global data
area Common coupling. Modules c, g, and k each access a data item in a global
data area. Module c initializes the item. Later module g recomputes and updates the
item. Let's assume that an error occurs and g updates the item incorrectly. Much
later in processing module, k reads the item, attempts to process it, and fails,
causing the software to abort. The apparent cause of abort is module k; the actual
cause, module g. Diagnosing problems in structures with considerable common
coupling is time consuming and difficult. However, this does not mean that the use
of global data is necessarily "bad." It does mean that a software designer must be
aware of potential consequences of common coupling and take special care to
guard against them. The highest degree of coupling, content coupling, occurs when
one module makes use of data or control information maintained within the
boundary of another module. Secondarily, content coupling occurs when branches
are made into the middle of a module. This mode of coupling can and should be
avoided.
2. List out Design Heuristics for effective Modular Design
Evaluate the first iteration of the program structure to reduce coupling and
improve cohesion.
Attempt to minimize structures with high fan-out; strive for fan-in as structure
depth increases.
Keep the scope of effect of a module within the scope of control for that
module.
Evaluate module interfaces to reduce complexity, reduce redundancy, and
improve consistency.
Define modules whose function is predictable and not overly restrictive (e.g. a
module that only implements a single sub function).
Strive for controlled entry modules, avoid pathological connection (e.g.
branches into the middle of another module)
Modular Design Evaluation Criteria:
Modular Decomposability - provides systematic means for breaking problem
into sub problems
Modular Composability - supports reuse of existing modules in new systems
Modular Understandability - module can be understood as a stand-alone unit
Modular Continuity - side-effects due to module changes minimized
Modular Protection - side-effects due to processing errors minimized
3. Write short notes on User Interface Design.
User Interface Design means, Designing effective interfaces for software
systems.
OBJECTIVES:
19
To explain different interaction styles
To introduce styles of information presentation
To describe the user support which should be built-in to user interfaces
To introduce usability attributes and system approaches to system evaluation
USER INTERFACE DESIGN PRINCIPLES:
UI design must take account of the needs, experience and capabilities of the
system users. Designers should be aware of people’s physical and mental
limitations (e.g. limited short-term memory) and should recognise that people
make mistakes. UI design principles underlie interface designs although not all
principles are applicable to all designs.
User familiarity: The interface should be based on user-oriented
terms and concepts rather than computer concepts. For example, an office
system should use concepts such as letters, documents, folders etc. rather than
directories, file identifiers, etc.
Consistency: The system should display an appropriate level
of consistency. Commands and menus should have the same format; command
punctuation should be similar, etc.
Minimal surprise: If a command operates in a known way, the user should be
able to predict the operation of comparable commands
Recoverability: The system should provide some resilience to
user errors and allow the user to recover from errors. This might include an
undo facility, confirmation of destructive actions, 'soft' deletes, etc.
User guidance: Some user guidance such as help systems, on-line manuals,
etc. should be supplied
User diversity: Interaction facilities for different types of user should be
supported. For example, some users have seeing difficulties and so larger text
should be available
INTERFACE EVALUATION:
Some evaluation of a user interface design should be carried out to assess its
suitability. Full scale evaluation is very expensive and impractical for most
systems. Ideally, an interface should be evaluated against a usability specification.
However, it is rare for such specifications to be produced.
4. Write short notes on Real Time Software Design.
Real Time Software Design means, Designing embedded software systems
whose behaviour is subject to timing constraints.
20
OBJECTIVES:
To describe a design process for real-time systems
To explain the role of a real-time executive
To introduce generic architectures for monitoring and control and data
acquisition systems.
REAL TIME SYSTEMS:
Real Time System is the system which monitors and controls their
environment. Inevitably associated with Two hardware devices,
Sensors: Collect data from the system environment
Actuators: Change (in some way) the system's environment.
Time is critical. Real-time systems MUST respond within specified times. A
real-time system is a software system where the correct functioning of the system
depends on the results produced by the system and the time at which these results
are produced. A ‘soft’ real-time system is a system whose operation is degraded if
results are not produced according to the specified timing requirements. A ‘hard’
real-time system is a system whose operation is incorrect if results are not
produced according to the timing specification.
Real-timecontrol system
ActuatorActuator ActuatorActuator
SensorSensorSensor SensorSensorSensor
SYSTEM ELEMENTS:
Sensors control processes: Collect information from sensors. May buffer
information collected in response to a sensor stimulus
Data processor: Carries out processing of collected information and computes
the system response
Actuator control: Generates control signals for the actuator.
21
Dataprocessor
Actuatorcontrol
Actuator
Sensorcontrol
Sensor
Stimulus Response
SYSTEM DESIGN:
Design both the hardware and the software associated with system. Partition
functions to either hardware or software. Design decisions should be made on the
basis on non-functional system requirements. Hardware delivers better
performance but potentially longer development and less scope for change.
MONITORING AND CONTROL SYSTEMS:
This is the important class of real-time systems. Continuously check sensors
and take actions depending on sensor values Monitoring systems examine sensors
and report their results Control systems take sensor values and control
hardware actuators.
DATA ACQUISITION SYSTEMS:
Collect data from sensors for subsequent processing and analysis. Data
collection processes and processing processes may have different periods and
deadlines. Data collection may be faster than processing e.g. collecting
information about an explosion. Circular or ring buffers are a mechanism for
smoothing speed differences.
UNIT – IV TESTING
Taxonomy Of Software Testing – Types Of S/W Test – Black Box
Testing – Testing Boundary Conditions – Structural Testing – Test
Coverage Criteria Based On Data Flow Mechanisms – Regression
Testing – Unit Testing – Integration Testing – Validation Testing –
System Testing And Debugging – Software Implementation
Techniques
1. Explain Cyclomatic Complexity and its Calculation with example.
The number of tests to test all control statements equals the cyclomatic
complexity
Cyclomatic complexity equals number of conditions in a program
22
Useful if used with care. Does not imply adequacy of testing.
Although all paths are executed, all combinations of paths are not
executed.
Independent Paths:
1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
Test cases should be derived so that all of these paths are executed
A dynamic program analyser may be used to check that paths have been
executed.
1
2
3
4
65
7
while bottom <= top
if (elemArray [mid] == key
(if (elemArray [mid]< key8
9
bottom > top
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
23
2. Explain the types of Black Box Testing in detail.
EQUIVALENCE PARTITIONING:
Equivalence partitioning is a black-box testing method that divides the input
domain of a program into classes of data from which test cases can be derived. An
ideal test case single-handedly uncovers a class of errors (e.g., incorrect processing
of all character data) that might otherwise require many cases to be executed before
the general error is observed. Equivalence partitioning strives to define a test case
that uncovers classes of errors, thereby reducing the total number of test cases that
must be developed.
Test case design for equivalence partitioning is based on an evaluation of
equivalence classes for an input condition. Using concepts introduced in the
preceding section, if a set of objects can be linked by relationships that are
symmetric, transitive, and reflexive, an equivalence class is present. An
equivalence class represents a set of valid or invalid states for input conditions.
Typically, an input condition is a specific numeric value, a range of values, a set of
related values, or a Boolean condition.
Equivalence classes may be defined according to the following guidelines:
If an input condition specifies a range, one valid and two invalid equivalence
classes are defined.
If an input condition requires a specific value, one valid and two invalid
equivalence classes are defined.
If an input condition specifies a member of a set, one valid and one invalid
equivalence class are defined.
If an input condition is Boolean, one valid and one invalid class are defined.
As an example, consider data maintained as part of an automated banking
application.
The user can access the bank using a personal computer, provide a six-digit
password, and follow with a series of typed commands that trigger various banking
functions. During the log-on sequence, the software supplied for the banking
application accepts data in the form area code—blank or three-digit number
Prefix — three-digit number not beginning with 0 or 1
Suffix — four-digit number
24
Password — six digit alphanumeric string
Commands — check, deposit, bill pay, and the like
The input conditions associated with each data element for the banking
application can be specified as area code: Input condition, Boolean — the area
code may or may not be present.
Input Condition, range — values defined between 200 and 999, with specific
exceptions.
Prefix: Input condition, range — specified value >200
Input condition, value — four-digit length
Password: Input Condition, Boolean — a password may or may not be present
Input Condition, value — six-character string
Command: Input Condition, set — containing commands noted previously.
Applying the guidelines for the derivation of equivalence classes, test cases for
each input domain data item can be developed and executed. Test cases are
selected so that the largest numbers of attributes of an equivalence class are
exercised at once.
BOUNDARY VALUE ANALYSIS:
For reasons that are not completely clear, a greater number of errors tends to
occur at the boundaries of the input domain rather than in the "center." It is for this
reason that Boundary Value Analysis (BVA) has been developed as a testing
technique. Boundary value analysis leads to a selection of test cases that exercise
bounding values. Boundary value analysis is a test case design technique that
complements equivalence partitioning. Rather than selecting any element of an
equivalence class, BVA leads to the selection of test cases at the "edges" of the
class. Rather than focusing solely on input conditions, BVA derives test cases from
the output domain as well
Guidelines for BVA are similar in many respects to those provided for Equivalence
Partitioning:
If an input condition specifies a range bounded by values a and b, test cases
should be designed with values a and b and just above and just below a and b.
25
If an input condition specifies a number of values, test cases should be
developed that exercise the minimum and maximum numbers. Values just
above and below minimum and maximum are also tested.
Apply guidelines 1 and 2 to output conditions. For example, assume that
temperature vs. pressure table is required as output from an engineering
analysis program. Test cases should be designed to create an output report that
produces the maximum (and minimum) allowable number of table entries.
If internal program data structures have prescribed boundaries (e.g., an array
has a defined limit of 100 entries), be certain to design a test case to exercise
the data structure at its boundary. Most software engineers intuitively perform
BVA to some degree. By applying these guidelines, boundary testing will be
more complete, thereby having a higher likelihood for error detection.
3. Explain Unit Testing and Structural Testing in detail.
UNIT TESTING:
In unit testing the individual components are tested independently to ensure
their quantity. The focus is to uncover the errors in design and implementation.
The various tests that are conducted during the unit test are described as below.
Module interfaces are tested for proper information flow in and out of the
program.
Local data are examined to ensure that integrity is maintained.
Boundary conditions are tested to ensure that the module operates properly at
boundary established to limit or restrict processing.
All the basis (independent) paths are tested for ensuring that all statements in
the module have been executed only once.
All error handling paths should be tested.
26
a. Drivers and Stub software need to be developed to test incomplete software.
The driver is a program that accepts the test data and prints the relevant results
and the stub is a subprogram that uses the module interfaces and performs the
minimal data if required. This is given by following figure.
b. The unit testing is simplified when a component with high cohesion(with one
function) is designed.in such a design the number of test cases are less and
one can easily predict or uncover errors.
27
STRUCTURAL TESTING:
White-box testing, sometimes called glass-box testing is a test case design
method that uses the control structure of the procedural design to derive test cases.
Using white-box testing methods, the software engineer can derive test cases that
(1) guarantee that all independent paths within a module have been exercised at
least once,(2) exercise all logical decisions on their true and false sides, (3) execute
all loops at their boundaries and within their operational bounds, and (4) exercise
internal data structures to ensure their validity.
A reasonable question might be posed at this juncture: "Why spend time and
energy worrying about (and testing) logical minutiae when we might better expend
effort ensuring that program requirements have been met?" Stated another way,
why don’t we spend all of our energy on black-box tests? The answer lies in the
nature of software defects
Logic errors and incorrect assumptions are inversely proportional to the
probability that a program path will be executed. Errors tend to creep into our
work when we design and implement function, conditions, or controls that are out
of the mainstream. Everyday processing tends to be well understood, while "special
case" processing tends to fall into the cracks.
We often believe that a logical path is not likely to be executed when, in fact, it
may be executed on a regular basis. The logical flow of a program is
sometimes counterintuitive, meaning that our unconscious assumptions about
flow of control and data may lead us to make design errors that are uncovered
only once path testing commences.
Typographical errors are random. When a program is translated into
programming language source code, it is likely that some typing errors will
occur. Many will be uncovered by syntax and type checking mechanisms, but
others may go undetected until testing begins. It is as likely that a typo will
exist on an obscure logical path as on a mainstream path.
Basis Path Testing:
Basis path testing is a white-box testing technique first proposed by Tom
McCabe. The basis path method enables the test case designer to derive a logical
complexity measure of a procedural design and use this measure as a guide for
defining a basis set of execution paths. Test cases derived to exercise the basis set
28
are guaranteed to execute every statement in the program at least one time during
testing.
Flow Graph Notation:
Before the basis path method can be introduced, a simple notation for the
representation of control flow, called a flow graph (or program graph) must be
introduced. The flow graph depicts logical control flow using the notation
illustrated in Figure. Each structured construct has a corresponding flow graph
symbol.
To illustrate the use of a flow graph, we consider the procedural design
representation in Figure. Here, a flowchart is used to depict program control
structure
Figure maps the flowchart into a corresponding flow graph (assuming that no
compound conditions are contained in the decision diamonds of the flowchart).
Referring to Figure, each circle, called a flow graph node, represents one or more
procedural statements. A sequence of process boxes and a decision diamond can
map into a single node. The arrows on the flow graph, called edges or links,
represent flow of control and are analogous to flowchart arrows. An edge must
terminate at a node, even if the node does not represent any procedural statements
(e.g., see the symbol for the if-then-else construct). Areas bounded by edges and
nodes are called regions. When counting regions, we include the area outside the
graph as a region. When compound conditions are encountered in a procedural
design, the generation of a flow graph becomes slightly more complicated. A
compound condition occurs when one or more Boolean operators (logical OR,
AND, NAND, NOR) is present in a conditional statement. Referring to Figure, the
PDL segment translates into the flow graph shown. Note that a separate node is
29
created for each of the conditions a and b in the statement IF a OR b. Each node
that contains a condition is called a predicate node and is characterized by two or
more edges emanating from it.
4. Explain the Regression Testing and Integration Testing in detail.
REGRESSION TESTING:
Regression testing is testing done to check that a system update does not re-
introduce errors that have been corrected earlier.
All – or almost all – regression tests aim at checking the,
Functionality – black box tests.
Architecture – grey box tests
Since they are supposed to test all functionality and all previously done changes,
regression tests are usually large.
Thus, regression testing needs automatic,
Execution – no human intervention
Checking. Leaving the checking to developers will not work.
We face the same challenge when doing automating regression test as we face
when doing automatic test checking in general:
Which parts of the output should be checked against the oracle?
This question gets more important as we need to have more version of the
same test due to system variability.
Simple but annoying – and sometimes expensive – problems are e.g.
Use of date in the test output
Changes in number of blanks or line shifts
Other format changes
Changes in lead texts
Simple but annoying – and sometimes expensive – problems are e.g.
Use of date in the test output
30
Changes in number of blanks or line shifts
Other format changes
Changes in lead texts
Regression testing is a critical part of testing, but is often overlooked.
Whenever a defect gets fixed, a new feature gets added, code gets re-factored
or changed in any way, and there is always a chance that the changes may
break something, that was previously working. Regression testing is the
testing of features, functions, etc. that have been tested before, to make sure
they still work, after a change has been made to software.
Within a set of release cycles, the flow is typically as follows: The testers will
test the software and find several defects. The developers will fix the defects,
possibly add a few more features and give it back to be tested. The testers will
then have not only tested the new features, but test all of the old features to
make sure they still work.
Questions often arise as to how much Regression Testing needs to be done.
Ideally, in Regression Testing, everything would be tested just as thoroughly
as it was the first time, but this becomes impractical as time goes on and more
and more features and, therefore, test cases get added. When looking at which
tests to execute during regression testing, some compromises need to be made.
When deciding, you will want to focus on what has changed. If a feature has
been significantly added to or changed, then you will want to execute a lot of
tests against this feature. If a defect has been fixed in a particular area you will
want to check that area to see that the fix didn't cause new defects. If, on the
other hand, a feature has been working well for some time and hasn't been
modified only a quick test may need to be executed.
INTEGRATION TESTING:
Integration Testing,
Tests complete systems or subsystems composed of integrated components
Integration testing should be black-box testing with tests derived from the
specification
31
Main difficulty is localising errors
Incremental integration testing reduces this problem.
Approaches to Integration Testing:
Top-down Testing:
Start with high-level system and integrate from the top-down replacing
individual components by stubs where appropriate.
Level 2Level 2Level 2Level 2
Level 1 Level 1Testing
sequence
Level 2stubs
Level 3stubs
. . .
Bottom-up Testing:
Integrate individual components in levels until the complete system is
created.
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence1
Test sequence2
Test sequence3
32
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
.
In practice, most integration involves a combination of these strategies
UNIT – V SOFTWARE PROJECT MANAGEMENT
Measures And Measurements – ZIPF’s Law – Software Cost Estimation –
Function Point Models – COCOMO Model – Delphi Method – Scheduling
– Earned Value Analysis – Error Tracking – Software Configuration
Management – Program Evolution Dynamics – Software Maintenance –
Project Planning – Project Scheduling– Risk Management – CASE Tools
1. Explain Software Cost Estimation in detail?
Software productivity
Estimation techniques
Algorithmic cost modelling
Project duration and staffing
Fundamental estimation questions are,
How much effort is required to complete an activity?
How much calendar time is needed to complete an activity?
What is the total cost of an activity?
Project estimation and scheduling are interleaved management activities.
33
SOFTWARE COST COMPONENTS:
Hardware and software costs.
Travel and training costs.
Effort costs (the dominant factor in most projects)
o The salaries of engineers involved in the project;
o Social and insurance costs.
Effort costs must take overheads into account
o Costs of building, heating, lighting.
o Costs of networking and communications.
o Costs of shared facilities (e.g library, staff restaurant,
etc.).
COSTING AND PRICING:
Estimates are made to discover the cost, to the developer, of producing a
software system.
There is not a simple relationship between the development cost and the price
charged to the customer.
Broader organisational, economic, political and business considerations
influence the price charged.
SOFTWARE PRODUCTIVITY:
A measure of the rate at which individual engineers involved in software
development
produce software and associated documentation.
Not quality-oriented although quality assurance is a factor in productivity
assessment.
Essentially, we want to measure useful functionality produced per time unit.
PRODUCTIVITY MEASURES:
34
Size related measures based on some output from the software process. This
may be lines of delivered source code, object code instructions, etc.
Function-related measures based on an estimate of the functionality of the
delivered software. Function-points are the best known of this type of
measure.
LINES OF CODE:
What’s a line of code?
o The measure was first proposed when programs were typed on cards
with one line per card;
o How does this correspond to statements as in Java which can span
several lines or where there can be several statements on one line.
What programs should be counted as part of the system?
This model assumes that there is a linear relationship between system size and
volume of documentation.
ESTIMATION TECHNIQUES:
There is no simple way to make an accurate estimate of the effort required to
develop a software system
o Initial estimates are based on inadequate information in a user
requirements definition;
o The software may run on unfamiliar computers or use new technology;
o The people in the project may be unknown.
Project cost estimates may be self-fulfilling
o The estimate defines the budget and the product is adjusted to meet the
budget.
Algorithmic cost modelling.
Expert judgement.
35
Estimation by analogy.
Parkinson's Law.
Pricing to win.
PROJECT DURATION AND STAFFING:
As well as effort estimation, managers must estimate the calendar time
required completing a project and when staff will be required.
Calendar time can be estimated using a COCOMO 2 formula
o TDEV = 3 ´ (PM)(0.33+0.2*(B-1.01))
o PM is the effort computation and B is the exponent computed as
discussed above (B is 1 for the early prototyping model). This
computation predicts the nominal schedule for the project.
The time required is independent of the number of people working on the
project.
STAFFING REQUIREMENTS:
Staff required can’t be computed by diving the development time by the
required schedule.
The number of people working on a project varies depending on the phase of
the project.
The more people who work on the project, the more total effort is usually
required.
A very rapid build-up of people often correlates with schedule slippage.
2. Explain Software Configuration Management in detail?
a) Configuration Management Planning
b) Change Management
36
c) Version and Release Management
d) System Building
e) CASE tools for Configuration Management
CONFIGURATION MANAGEMENT PLANNING:
All products of the software process may have to be managed:
a. Specifications;
b. Designs;
c. Programs;
d. Test data;
e. User manuals.
Thousands of separate documents may be generated for a large, complex
software system.
The Configuration Management Plans:
Defines the types of documents to be managed and a document naming
scheme.
Defines who takes responsibility for the CM procedures and creation
of baselines.
Defines policies for change control and version management.
Defines the CM records which must be maintained.
Describes the tools which should be used to assist the CM process and
any limitations on their use.
Defines the process of tool use.
Defines the CM database used to record configuration information.
May include information such as the CM of external software, process
auditing, etc.
37
Configuration Hierarchy:
PCL-TOOLS
EDIT
STRUCTURES
BIND
FORM
COMPILE MAKE-GEN
HELP
DISP LAY QUERY
AST-INTERFACEFORM-SPECS FORM-IO
CODEOBJECTS TESTS
The Configuration Database:
All CM information should be maintained in a configuration database.
This should allow queries about configurations to be answered:
o Who has a particular system version?
o What platform is required for a particular version?
o What versions are affected by a change to component X?
o How many reported faults in version T?
The CM database should preferably be linked to the software being managed.
New versions of software systems are created as they change:
o For different machines/OS;
o Offering different functionality;
o Tailored for particular user requirements.
Configuration management is concerned with managing evolving software
systems:
o System change is a team activity;
o CM aims to control the costs and effort involved in making changes to
a system.
38
It involves the development and application of procedures and standards to
manage an evolving software product. The CM may be seen as part of a more general
quality management process. When released to CM, software systems are sometimes
called baselines as they are a starting point for further development.
Server
version
Linux
version
PC versionInitial
system
Desktop
versionWindows XP
version
HP
version
Sun
version
CM Standards:
CM should always be based on a set of standards which are applied within
an organisation.
Standards should define how items are identified; how changes are
controlled and how new versions are managed.
Standards may be based on external CM standards (e.g. IEEE standard for
CM).
Some existing standards are based on a waterfall process model - new CM
standards are needed for evolutionary development.
CHANGE MANAGEMENT:
Change management is a procedural process so it can be modelled and
integrated with a version management system.
Change management tools
Form editor to support processing the change request forms;
Workflow system to define who does what and to automate information
transfer;
39
Change database that manages change proposals and is linked to a VM
system;
Change reporting system that generates management reports on the status
of change requests.
VERSION AND RELEASE MANAGEMENT:
Version and Release Identification: Systems assign identifiers
automatically when a new version is submitted to the system.
Storage Management: System stores the differences between versions
rather than all the version code.
Change History Recording: Record reasons for version creation.
Independent Development: Only one version at a time may be checked
out for change. Parallel working on different versions.
Project Support: Manages groups of files associated with a project rather than
just single files.
SYSTEM BUILDING:
It is easier to find problems that stem from component interactions early in the
process.
This encourages thorough unit testing - developers are under pressure not to
‘break the build’.
A stringent change management process is required to keep track of problems
that have been discovered and repaired.
CASE TOOLS FOR CONFIGURATION MANAGEMENT:
CM processes are standardised and involve applying pre-defined procedures.
Large amounts of data must be managed.
CASE tool support for CM is therefore essential.
Mature CASE tools to support configuration management are available
ranging from stand-alone tools to integrated CM workbenches
40
3. Explain COCOMO Model in detail?
COCOMO MODELS:
COCOMO has three different models that reflect the complexity:
The Basic Model
The Intermediate Model
The Detailed Model
The Development Modes: Project Characteristics:
Organic Mode:
o Relatively small, simple software projects
o Small teams with good application experience work to a set of less
than rigid requirements
o Similar to the previously developed projects
o relatively small and requires little innovation
Semidetached Mode:
o Intermediate (in size and complexity) software projects in which
teams with mixed experience levels must meet a mix of rigid and less
than rigid requirements.
Embedded Mode:
o Software projects that must be developed within a set of tight
hardware, software, and operational constraints
Some Assumptions:
Primary cost driver is the number of Delivered Source Instructions (DSI) /
Delivered Line Of Code developed by the project
41
COCOMO estimates assume that the project will enjoy good management by
both the developer and the customer
Assumes the requirements specification is not substantially changed after the
plans and requirements phase
Basic COCOMO is good for quick, early, rough order of magnitude
estimates of software costs
It does not account for differences in hardware constraints, personnel
quality and experience, use of modern tools and techniques, and other project
attributes known to have a significant influence on software costs, which
limits its accuracy.
BASIC COCOMO MODEL:
Formula:
E=ab (KLOC or KDSI) b
b
D=cb (E) d
b
P=E/D
where E is the effort applied in person-months, D is the development time in
chronological months, KLOC / KDSI is the estimated number of delivered lines of
code for the project (expressed in thousands), and P is the number of people required.
The coefficients ab, bb, cb and db are given in next slide.
Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
42
Equation:
Mode Effort Schedule
Organic E=2.4*(KDSI)1.05
TDEV=2.5*(E)0.38
Semidetached E=3.0*(KDSI)1.12
TDEV=2.5*(E)0.35
Embedded E=3.6*(KDSI)1.20
TDEV=2.5*(E)0.32
Limitation:
Its accuracy is necessarily limited because of its lack of factors which have a
significant influence on software costs
The Basic COCOMO estimates are within a factor of 1.3 only 29% of the
time, and within a factor of 2 only 60% of the time
Example:
We have determined our project fits the characteristics of Semi-Detached
mode
We estimate our project will have 32,000 Delivered Source Instructions.
Using the formulas, we can estimate:
Effort = 3.0*(32) 1.12
= 146 man-months
Schedule = 2.5*(146) 0.35
= 14 months
Productivity = 32,000 DSI / 146 MM
= 219 DSI/MM
Average Staffing = 146 MM /14 months
= 10 FSP