MIT,Mysore Software Engineering - M23BCS305

MODULE 2

Chapter 3: Critical Systems: A simple safety- critical system; System dependability; Availability
and reliability, safety, security.

Chapter 4 : Software Processes Models, Process iteration, Process activities, The Rational Unified
Process, Computer Aided Software Engineering.

NOTE: Please Refer To Text Book, This Is Only For Reference Purpose

Critical systems

• Systems on which people or businesses depend, where failure can lead to significant
economic losses, physical damage, or threats to human life.

• Types of Critical Systems:

1. Safety-Critical Systems:
o Failure may result in injury, loss of life, or serious environmental damage.
o Example: Control system for a chemical manufacturing plant.
2. Mission-Critical Systems:
o Failure may result in the failure of a goal-directed activity.
o Example: Navigational system for a spacecraft.
3. Business-Critical Systems:
o Failure may result in very high costs for the business.
o Example: Customer accounting system in a bank.

• Dependability:

• The term dependability was proposed by Laprie to cover availability, reliability,

safety, and security.
• Importance:
o User Trust: Unreliable, unsafe, or insecure systems may be rejected by users,
affecting the company's reputation.
o Failure Costs: Costs of failure can be orders of magnitude greater than the
cost of the system itself.
o Information Loss: Valuable data may be lost, leading to high costs in data
duplication and maintenance.

• Critical systems use well-tried techniques due to their reliability and known strengths and
weaknesses.
• Expensive methods like formal mathematical techniques may be used to reduce testing
requirements and manage high verification costs (more than 50% of total development
costs).
• Socio-Technical Systems: Most critical systems involve human operators who monitor
and control the system.

Prepared by : Prof. Roshini P 32 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Operator Role: While operators can help recover from failures, they can also cause
problems if they make mistakes.

• There are three ‘system components’ where critical systems failures may occur

1. System Hardware:
o Failures due to design mistakes, manufacturing errors, or component life.
2. System Software:
o Failures due to specification, design, or implementation mistakes.
3. Human Operators:
o Human error is often the largest single cause of system failures.

• Interrelation of Failures: Hardware failures can lead to increased stress and mistakes
by operators, which may cause further software failures.

• Designers should consider the entire system, including hardware, software, and
operational processes.
• Designing components separately without considering interactions can lead to errors at
the interfaces between system parts.

3.1 A simple safety-critical system

• Types of Critical Systems:

• Ranges from control systems for devices and machinery to information and e-
commerce systems.
• Advanced software engineering techniques are often used in their development.

• Case Study: Medical Insulin Delivery System

• Medical systems are relevant and illustrate why safety and reliability are crucial.
• To help people with diabetes by simulating the operation of the pancreas.

• Diabetes Overview:

• Condition: The pancreas cannot produce sufficient insulin, which metabolizes

glucose in the blood.
• Conventional Treatment: Regular insulin injections and blood sugar level
measurements.
• Problem: Insulin levels depend on injection timing, leading to potential issues:
o Low Blood Sugar( if there is too much insulin): Can cause brain
malfunction, unconsciousness, and death.
o High Blood Sugar(if there is too little insulin): Long-term effects include
eye damage, kidney damage, and heart problems.

• Advancement: Automated Insulin Delivery Systems

• Miniaturized sensors allow for automated insulin delivery.

• Systems monitor blood sugar levels and deliver insulin as needed.

Prepared by : Prof. Roshini P 33 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Exists for hospital patients.

• Potential for permanent attachment for many diabetics.

• System Operation:

• Components:
o Micro-Sensor: Measures a blood parameter proportional to sugar levels.
o Pump Controller: Computes sugar levels and required insulin dosage.
o Miniaturized Pump: Delivers insulin via a permanently attached needle.
• Below Figure shows how it transforms blood sugar level input into pump control
commands
Figure 3.1 shows the components and organisation of the insulin pump and
Figure 3.2 is a data-flow model that illustrates how an input blood sugar level is
transformed to a sequence of pump control commands.

• High-Level Dependability Requirements:

1. Availability: The system must be available to deliver insulin when required.

2. Reliability: The system must perform reliably and deliver the correct insulin amount
based on current blood sugar levels.

• Critical Consideration:

Prepared by : Prof. Roshini P 34 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Failure Risk: System failure could result in excessive insulin doses, potentially
threatening the user's life.
• Safety Focus: Preventing overdoses of insulin is crucial.

3.2 System dependability

Computer systems sometimes crash and fail to deliver services as requested.

Programs may not operate as expected and might corrupt data.

Users often do not fully trust personal computers due to these issues.

• Dependability:

• The property of a system that equates to its trustworthiness.

• Trustworthiness essentially means degree of user confidence that the system will
operate as expected and not fail during normal use.
• This property cannot be expressed numerically but can be described in relative terms
like ‘not dependable’, ‘very dependable’, ‘ultra-dependable’.

• Dependability vs. Usefulness:

• Usefulness: A system may be useful but not dependable.

• Example: A word processor might be useful but not very dependable, requiring
frequent saving and backups.

• Principal Dimensions of Dependability (Figure 3.3):

Figure 3.3 Dimensions of dependability

1. Availability:
o Probability that the system will be up and running and able to deliver services
at any given time.
2. Reliability:
o Probability that the system will correctly deliver services as expected over a
given period.

Prepared by : Prof. Roshini P 35 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

3. Safety:
o Likelihood that the system will not cause damage to people or its environment.
4. Security:
o Likelihood that the system can resist accidental or deliberate intrusions.

• Ex:

• Security:
o Includes integrity (ensuring that the systems program and data are not
damaged) and confidentiality (ensuring that information can only be accessed
by people who are authorised).
• Reliability:
o Includes correctness (ensuring the system services are as specified), precision
(ensuring information is delivered at an appropriate level of detail), and
timeliness (ensuring that information is delivered when it is required).

• Interrelation of Dependability Properties:

• Safe system operation depends on system availability and reliability.

• Reliability can be compromised by data corruption from intruders.
• Security issues like denial-of-service attacks can affect availability.
• Safe operation cannot be assumed if a system is infected with a virus.

• Other system properties can also be considered under the heading of dependability:

1. Repairability:
o Ability to repair the system quickly after failure.
o Diagnostic capability, access to failed components, and source code access
enhance repairability.
2. Maintainability:
o Ability to adapt software economically to new requirements with minimal risk
of introducing new errors.
3. Survivability:
o Ability to continue service while under attack or part of the system is disabled.
o Resistance to attack, attack recognition, and recovery from damage.
4. Error Tolerance:
o Extent to which the system is designed to handle user input errors.
o Detection and automatic correction of errors or user prompts for re-input.

• Dependability in Critical Systems:

• Important Properties for Insulin Pump System:

o Availability (must work when needed)
o Reliability (must deliver correct insulin dosage)
o Safety (must avoid dangerous doses)
• Less Critical Property for Insulin Pump:
o Security (not networked, so less likely to be attacked)

• Trade-offs:

Prepared by : Prof. Roshini P 36 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Performance vs. system Dependability:

o High dependability often comes at the expense of system performance.
o Dependable software includes extra code for checking and fault recovery,
reducing performance and increasing storage requirements.
o Increased dependability raises development costs, particularly for validation
and regulatory compliance.

• Cost of Dependability:

• Cost/Dependability Curve (Figure 3.4):

o Higher dependability requires higher testing costs.

o Achieving 100% dependability is impractical due to infinite costs for
assurance.

3.3 Availability and reliability

• Reliability:
The probability of failure-free operation over a specified time in a given environment
for a specific purpose.

• Availability:
Probability that the system will be operational and able to deliver requested services
at a given time.

• Relationship Between Availability and Reliability:

• Closely Related: Both can be expressed as numerical probabilities.

• Not the Same:
o A system can be highly available but less reliable, or vice versa.
o Example: A telephone exchange switch has high availability requirements
because users expect a dial tone. If a connection fails, it can often be quickly
recovered, so reliability is less critical.

• Availability vs. Reliability in Practice:

• Repair Time Impact:

Prepared by : Prof. Roshini P 37 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o Availability is affected by how quickly faults can be repaired.

o Example: System A (fails once per year, 3 days to restart) vs. System B (fails
once per month, 10 minutes to restart).
▪ System B has better availability over a year despite more frequent
failures.

• Definitions:

1. Reliability:
o Probability of failure-free operation over a specified time in a given
environment for a specific purpose.
2. Availability:
o Probability that a system will be operational and able to deliver requested
services at a specific time.

• Practical Issues with Definitions:

• Environmental and Purpose Dependency:

o Reliability can vary with different environments and usage, i.e you can’t
assume that the reliability will be the same in another environment where the
system is used in a different way
o Example: let’s say that you measure the reliability of a word processor in an
office environment where most users are uninterested in the operation of the
software. they follow the instructions for its use and do not try to experiment
with the system. If you measure the reliability of the same system in a
university environment, then the reliability may be quite different.

• Human Perception:
o Example: A faulty car wiper system may be seen as unreliable in a wet
climate but not in a dry one. Driver in Seattle(wet climate) will probably be
more affected by this failure than a driver in Las Vegas (dry climate). The
Seattle driver’s perception will be that the system is unreliable, whereas the
driver in Las Vegas may never notice the problem
• Severity of Failure:
o More severe failures impact perceived reliability more than minor ones.
o For example, say a failure of initialisation in the engine management software
causes a car engine to cut out immediately after starting, but it operates
correctly after a restart that corrects the initialisation problem. This does not
affect the normal operation of the car, and many drivers would not think that a
repair was needed.
On contrast: Engine cutting out at high speed is more concerning than a start-
up issue fixed by a restart.

• Reliability and Availability can be compromised by system failures:

• Failure Types:
o Failure to provide a service, failure to meet specifications, or delivering
unsafe/insecure services.
• Faults vs. Errors vs. Failures:

Prepared by : Prof. Roshini P 38 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o Fault: Characteristic in the system that can lead to errors (e.g., uninitialized
variable).
o Error: Erroneous system state leading to unexpected behavior.
o Failure: System does not deliver the service as expected.

• Figure 3.5 helps us identify three complementary approaches that are used to improve the
reliability of a system:

1. Fault Avoidance:
o Development techniques to minimize or trap mistakes before they lead to
system faults.
o Examples: Avoiding error-prone constructs such as pointers and the use of
static analysis to detect program anomalies
2. Fault Detection and Removal:
o Verification and validation techniques that increase the chances that faults will
be detected and removed before the system is used.
o Examples: Systematic testing and debugging.
3. Fault Tolerance:
o Ensuring faults do not lead to system errors or failures.
o Examples: Self-checking facilities, redundant modules.

• Faults in the code lead to failures when executed with certain inputs.
• Faults affecting frequently used code impact reliability more than those in rarely used
code.

• Users might avoid inputs that cause problems or work around known faults.
• Example: Avoiding features known to cause issues, like automatic numbering in
word processing.

• Removing faults in rarely used parts of software has minimal impact on overall
reliability.
• Many defects only cause issues after extensive usage.
• Users may adapt their behavior to avoid problems with known faults.

Prepared by : Prof. Roshini P 39 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Certain inputs or input combinations, depicted in the shaded ellipse in Figure 3.6, generate
erroneous outputs.

• The probability that, in a particular execution of the program, the system input will be a
member of the set of inputs that cause erroneous output.

o If an erroneous input is linked to frequently used parts of the program, failures

will occur more often.
o If linked to rarely used code, failures will be less frequent and less noticeable
to users.

• Different users interact with the system in various ways.

• Example (Figure 3.7):
o User 2's inputs intersect with the erroneous input set, so User 2 will experience
some system failures.
o Users 1 and 3 do not use inputs from the erroneous set, so they will perceive the
software as reliable.

3.4 Safety

• Safety-critical systems are systems where it is essential that operation is always safe. They
should never cause harm to people or the environment, even if the system fails.

Prepared by : Prof. Roshini P 40 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Examples:

• Control and monitoring systems in aircraft.

• Process control systems in chemical and pharmaceutical plants.
• Automobile control systems.

• Hardware vs. Software Control:

• Hardware Control:
o Simpler to implement and analyze.
• Software Control:
o Essential for managing large numbers of sensors and actuators with complex
control laws.
o Example: Advanced, aerodynamically unstable military aircraft require
continual software-controlled adjustment of flight surfaces to avoid crashing.

• Types of Safety-Critical Software:

1. Primary Safety-Critical Software:

o Embedded as a controller in a system.
o Malfunctioning can cause hardware malfunction, leading to human injury or
environmental damage.
o Focus: This type of software.

2. Secondary Safety-Critical Software:

o Can indirectly result in injury.
o Examples:
▪ Computer-aided engineering design systems: Malfunctions can lead to
design faults causing injury.
▪ Medical databases: Errors can result in incorrect drug dosages being
administered.

• System reliability and system safety are related but separate dependability attributes.
• A safety-critical system should be reliable, meaning it conforms to its specification
and operates without failures. It may include fault-tolerant features to ensure
continuous service even if faults occur.
• However, fault-tolerant systems are not necessarily safe; the software might still
malfunction and lead to accidents.

• Reasons Reliable Systems May Not Be Safe:

1. Incomplete Specifications:
o Specifications may lack details on required behavior in critical situations.
o A high percentage of system malfunctions are due to specification errors
rather than design errors.
o Example: A study by Lutz (1993) found that difficulties with requirements are
a key cause of safety-related software errors persisting into integration and
testing.
2. Hardware Malfunctions:

Prepared by : Prof. Roshini P 41 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

oHardware malfunctions can cause unpredictable system behavior and present

the software with unanticipated conditions.
o Components close to failure may act erratically, generating signals outside the
software's handling range.
3. Operator Inputs:
o System operators might input commands that are not individually incorrect but
could lead to system malfunctions in certain situations.
o Example: A mechanic instructed an aircraft's utility management software to
raise the undercarriage while the plane was on the ground. The software
executed the command perfectly, but the system should have disallowed it
unless the plane was in the air.

• Specialised Vocabulary:

• A specific vocabulary has developed for discussing safety-critical systems.

• Key terms adapted from Leveson (1985) are important to understand.

• key to assuring safety is to ensure either that accidents do not occur or that the
consequences of an accident are minimal. This can be achieved in three complementary
ways:

1. Hazard Avoidance:
o Design the system to avoid hazards.
o Example: A cutting system that requires pressing two separate buttons
simultaneously avoids the hazard of the operator’s hands being in the blade
pathway.

2. Hazard Detection and Removal:

o Design the system to detect and remove hazards before they cause accidents.
o Example: A chemical plant system that detects excessive pressure and opens
a relief valve to reduce the pressure before an explosion occurs.
3. Damage Limitation:
o Include protection features to minimize damage from accidents.
o Example: Aircraft engines include automatic fire extinguishers that can
control a fire before it poses a threat to the aircraft.

Prepared by : Prof. Roshini P 42 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Serious accidents often result from a combination of malfunctions, not single failures
(Perrow, 1984).
• Unanticipated combinations lead to interactions causing system failures.
• It is impossible to foresee all possible malfunction combinations in complex systems.
• Accidents are considered inevitable in complex systems.
• Software increases system complexity, potentially raising the probability of accidents.
• Monitors a wider range of conditions compared to electro-mechanical systems.
• Easier to adapt and update.
• Uses highly reliable and lightweight computer hardware.
• Provides sophisticated safety interlocks.
• Supports control strategies to minimize human exposure to hazardous environments.
• It's impossible to make a system completely safe.
• Society must weigh the benefits of advanced technologies against the risks of occasional
accidents.
• Decisions about safety involve social and political considerations regarding the allocation
of resources to reduce overall risk.

3.5 Security

• Definition of Security:
Security is the system's ability to protect itself from external attacks, whether accidental or
deliberate.

• Importance of Security:

• Internet Connectivity:
o Increased importance due to more systems being connected to the Internet.

Prepared by : Prof. Roshini P 43 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o Provides additional functionality (e.g., online banking) but also exposes

systems to potential attacks.
o Vulnerability details can be easily shared, increasing the risk of attacks.
o Internet connectivity also enables faster distribution of patches to fix
vulnerabilities.

• Examples of Attacks:

• Viruses
• Unauthorized use of system services
• Unauthorized modification of the system or its data

• Impact on Critical Systems:

• Security is crucial for all critical systems.

• Lack of security can compromise system availability, reliability, and safety.
• External attacks can damage the system, affecting its overall dependability.

• Dependability and Security Relationship:

• Dependability attributes (availability, reliability, and safety) assume the system is

unaltered from its original installation.
• Compromised systems (e.g., those with viruses) may not meet original reliability and
safety assurances, leading to unpredictable behavior.

• Errors Leading to Security Loopholes:

• Development errors can create security weaknesses.

• Examples:
o Failure to respond to unexpected inputs.
o Lack of array bounds checking.
• These weaknesses can be exploited by attackers to gain unauthorized access.

• Historical Security Incidents:

• Internet Worms:
o Original Internet worm (Spafford, 1989).
o Code Red worm (Berghel, 2001).
• Both exploited the lack of array bound checking in C programs.
• Attackers overwrote memory with code, allowing unauthorized access.

• Critical Systems and Security:

• For some systems, security is the most critical aspect of dependability.

• Examples of such systems:
o Military systems
o Electronic commerce systems
o Systems processing confidential information
• Consequences of Insecurity:
o Airline reservation system example:

Prepared by : Prof. Roshini P 44 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

▪ Unavailability causes inconvenience and delays.

▪ Insecurity can lead to fake bookings and significant financial loss for
the airline.

There are three types of damage that may be caused through external attack:

1. Denial of Service:
o The system is forced into a state where its normal services become
unavailable.
o Affects the system's availability.
2. Corruption of Programs or Data:
o Software components may be altered in an unauthorized way.
o Affects the system’s behavior, reliability, and safety.
o Severe damage may also impact system availability.
3. Disclosure of Confidential Information:
o Confidential information managed by the system may be exposed to
unauthorized people.
o This can affect the system's safety and may lead to further attacks impacting
availability or reliability

Terms related to security are discussed by Pfleeger (1997) and defined in Figure 3.9.

Analogies in Security Terminology

• Exposure is analogous to an accident in safety.

• Vulnerability is analogous to a hazard in safety.

There are comparable approaches that may be used to assure the security of a system:

1. Vulnerability Avoidance:
o The system is designed so that vulnerabilities do not occur.
o Example: A system not connected to an external public network avoids
potential attacks.
2. Attack Detection and Neutralisation:

Prepared by : Prof. Roshini P 45 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

oThe system is designed to detect vulnerabilities and remove them before they
result in an exposure.
o Example: Using a virus checker to analyze and remove viruses from incoming
files.
3. Exposure Limitation:
o The consequences of a successful attack are minimized.
o Examples: Regular system backups and a configuration management policy to
recreate damaged software.

• Much vulnerability arise from human rather than technical failings.

• Examples: Easy-to-guess passwords, mistakes in setting up access controls or
configuration files.
• Improving security requires considering how systems are used, not just their technical
characteristics.
• Detailed discussion on this in Chapter 30 on security engineering and emerging
technologies.

Software Processes
• A software process is a set of activities that leads to the production of a software
product.

Activities Involved

• Development from Scratch: Creating software using a standard programming

language like Java or C.
• Extension and Modification: Adding to and modifying existing systems.
• Configuration and Integration: Using and integrating off-the-shelf software or system
components.

Complexity and Automation

• Complexity: Software processes are complex and rely on human decision-making and
creativity.
• Limited Automation: Attempts to automate software processes have had limited
success.
• CASE Tools: Computer-aided software engineering (CASE) tools can support some
process activities but cannot fully automate creative design.

Diversity of Software Processes

• No Ideal Process: There is no one-size-fits-all process; many organizations develop

their own approaches.
• Process Evolution: Processes evolve to suit organizational capabilities and system
characteristics.
o Critical Systems: Require a very structured development process.
o Business Systems: Often benefit from a flexible, agile process due to rapidly
changing requirements.

Prepared by : Prof. Roshini P 46 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

Some fundamental activities are common to all software processes:

1. Software Specification:
o Define the functionality and constraints of the software.
2. Software Design and Implementation:
o Produce software to meet the specification.
3. Software Validation:
o Ensure the software does what the customer wants.
4. Software Evolution:
o Evolve the software to meet changing customer needs.

Improving Software Processes

• No ‘Ideal’ Process: There is no perfect software process; opportunities for

improvement exist in many organizations.
• Current Issues:
o Processes may include outdated techniques.
o Many organizations do not use best practices or modern software engineering
methods.
• Process Standardisation:
o Reduces diversity in software processes across an organization.
o Leads to improved communication and reduced training time.
o Makes automated process support more economical.
o Important for introducing new software engineering methods and practices.

4.1 Software process models

o A software process model is an abstract representation of a software process.

o Each model offers a partial view of the process, representing it from a specific
perspective.
o Process models are frameworks for explaining different approaches to
software development.
o They can be extended and adapted to create more specific software
engineering processes.

These three generic process models are widely used in current software engineering
practice:

1. The Waterfall Model:

o Represents process activities (specification, development, validation,
evolution) as separate phases.
o Phases include requirements specification, software design, implementation,
and testing.
2. Evolutionary Development:
o Interleaves specification, development, and validation activities.
o Develops an initial system quickly from abstract specifications, then refines it
with customer input.
3. Component-Based Software Engineering:

Prepared by : Prof. Roshini P 47 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o Focuses on integrating reusable components rather than developing

components from scratch.
o System development emphasizes component integration.

• These models are widely used and not mutually exclusive.

• They are often combined, especially in large systems development.
• For example, the Rational Unified Process incorporates elements from all these models.
• Different sub-systems within a larger system may use different approaches.
• The models are not mutually exclusive and are often used together, especially in large
systems development.
• The Rational Unified Process, discussed in Section 4.4, combines elements from all these
models.
• Sub-systems within a larger system may be developed using different approaches.

Variants of Generic Processes

• Formal System Development:

o Creates a formal mathematical model of the system.
o The model is transformed into executable code using mathematical
transformations that preserve consistency.
o Cleanroom Process:
▪ Developed by IBM.
▪ Each software increment is formally specified and transformed into an
implementation.
▪ Correctness is demonstrated using a formal approach.
▪ Focuses on system reliability rather than defect testing.
• Other Formal Approaches:
o B Method:
▪ Another formal development approach, particularly suited for systems
with stringent safety, reliability, or security requirements.
▪ Simplifies the creation of safety or security cases for customers or
certification bodies.

• Formal approaches are particularly suited to domains with high safety, reliability, or
security requirements.
• Formal processes are not widely used outside of these specialised domains.
• They require specialized expertise and often do not offer significant cost or quality
advantages for most systems compared to other development approaches.

4.1.1 The waterfall model

• The first published model derived from general system engineering processes (Royce,
1970).
• Known as the waterfall model or software life cycle.

• Principal Stages:

1. Requirements Analysis and Definition:

Prepared by : Prof. Roshini P 48 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o Establish system services, constraints, and goals by consulting with users.

o Define these in detail to serve as the system specification.
2. System and Software Design:
o Partition requirements between hardware and software systems.
o Establish overall system architecture.
o Software design involves identifying and describing software abstractions and
their relationships.
3. Implementation and Unit Testing:
o Realize the software design as a set of programs or program units.
o Unit testing verifies that each unit meets its specification.
4. Integration and System Testing:
o Integrate and test individual units as a complete system.
o Ensure software requirements are met before delivering to the customer.
5. Operation and Maintenance:
o Typically the longest phase.
o Install and use the system.
o Maintenance involves correcting errors, improving implementation, and
enhancing services as new requirements arise.

• Process Flow:

• Each phase results in documents that are approved ('signed off').

• Ideally, each phase starts only after the previous phase is finished.
• In practice, stages overlap and inform each other, involving iterations.

• Challenges:

• Iterations are costly and involve significant rework.

• Early commitments may lead to problems being left unresolved or circumvented by
implementation tricks.
• Premature freezing of requirements may cause the system to not meet user needs or
lead to poorly structured systems.

• Advantages:

• Documentation produced at each phase.

• Fits with other engineering process models.

• Disadvantages:

• Inflexible partitioning into distinct stages.

• Difficult to respond to changing customer requirements.

• Usage:

• Suitable when requirements are well understood and unlikely to change.

• Still used in software development, particularly as part of larger systems engineering
projects.

Prepared by : Prof. Roshini P 49 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

4.1.2 Evolutionary development

• Develop an initial implementation.

• Expose it to user feedback.
• Refine through many versions until an adequate system is developed (Figure 4.2).
• Specification, development, and validation activities are interleaved with rapid
feedback.

• Types of Evolutionary Development:

1. Exploratory Development:
o Work with the customer to explore requirements and deliver a final system.
o Starts with understood parts of the system.
o Evolves by adding new features proposed by the customer.
2. Throwaway Prototyping:
o Understand the customer's requirements to develop a better requirements
definition.
o Focuses on experimenting with poorly understood customer requirements.

• Advantages:

• Often more effective than the waterfall approach for meeting immediate customer
needs.
• Specification develops incrementally, reflecting users' better understanding of their
problems.

• The evolutionary approach has two problems:

1. Lack of Process Visibility:

o Managers need regular deliverables to measure progress.
o Quick development makes it cost-ineffective to produce documents for every
version.

Prepared by : Prof. Roshini P 50 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

2. Poorly Structured Systems:

o Continual changes tend to corrupt the software structure.
o Incorporating changes becomes increasingly difficult and costly.

• Small to Medium-Sized Systems (up to 500,000 lines of code):

• Evolutionary approach is recommended as the best approach to development.

• Large, Complex, Long-Lifetime Systems:

• Problems with evolutionary development become acute.

• Difficult to establish a stable system architecture.
• Integration of contributions from different teams is challenging.

• Recommended Approach for Large Systems:

• Use a mixed process incorporating features of both waterfall and evolutionary models.
o Develop a throwaway prototype using evolutionary approach to resolve
uncertainties in system specification.
o Reimplement the system using a more structured approach.
o Waterfall-based process for well-understood parts of the system.
o Exploratory programming approach for parts difficult to specify in advance,
such as the user interface.

4.1.3 Component-based software engineering

• Informal Software Reuse:

• Majority of software projects, there is some software reuse

• Developers use existing designs or code, modify them as needed, and incorporate
them into their system.
• Often essential for rapid system development, especially in evolutionary approaches.

• Component-Based Software Engineering (CBSE):

• A reuse-oriented approach becoming increasingly used.

Prepared by : Prof. Roshini P 51 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Relies on a large base of reusable software components and an integrating framework.

• Components can be systems themselves (COTS - Commercial Off-The-Shelf
systems) providing specific functionality such as text formatting or numeric
calculation..

• While the initial requirements specification stage and the validation stage are comparable
with other processes, the intermediate stages in a reuse-oriented process are different. These
stages are:

1. Component Analysis:
o Search for components that match the requirements specification.
o Components may not provide exact matches but offer partial functionality.
2. Requirements Modification:
o Analyze requirements with available component information.
o Modify requirements to fit the components.
o If modifications are not possible, re-enter component analysis for alternative
solutions.
3. System Design with Reuse:
o Design or reuse an existing framework for the system.
o Consider reusable components in the design.
o Design new software if required components are unavailable.
4. Development and Integration:
o Develop software that cannot be externally procured.
o Integrate reusable components and COTS systems to create the new system.
o Integration may be part of the development process rather than a separate
phase.

• Advantages:

• Reduces the amount of software to be developed.

• Lowers cost and risk.
• Often results in faster delivery of the software.

• Disadvantages:

• Requirements Compromises: May lead to a system that does not fully meet user
needs.
• Control Over Evolution: Limited control over system evolution since new versions
of reusable components are not managed by the organization using them.

Figure 4.3 Component-based software engineering

Prepared by : Prof. Roshini P 52 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

4.2 Process iteration

• System requirements evolve due to external pressures, management priorities, and

new technologies.
• Software processes are iterative and repeat regularly in response to change requests.

• Iterative Development:

• Incremental Delivery:
o Software is broken down into increments that are developed sequentially.
• Spiral Development:
o Development progresses in spirals from an initial outline to the final system.

• Challenges with Iterative Processes:

• Conflicts with procurement models where a complete system specification is required

at the start.
• Incremental approaches may lack a complete system specification until the final
increment.
• Adapting to iterative processes may require new contract models, which can be
challenging for large customers like government agencies.

4.2.1 Incremental delivery

• Comparison with Waterfall and Evolutionary Models:

• Waterfall Model:
o Requires customer commitment to a set of requirements before design.
o Changes require rework of requirements, design, and implementation.
o Separates design and implementation, leading to well-documented systems.
• Evolutionary Approach:
o Allows requirements and design decisions to be delayed.
o May result in poorly structured and difficult-to-maintain software.

• Incremental Delivery:

• Combines advantages of both models.

▪ Customers outline system services and prioritize them.
▪ Define delivery increments with subsets of system functionality.
▪ High-priority services are delivered first.
▪ Detailed requirements for the first increment are defined.
▪ Development of increments proceeds, with further requirements analysis for
later increments.
▪ No changes accepted for the current increment during its development.
▪ Early delivery of partial system functionality.
▪ Customers experiment and refine requirements with early increments.
▪ New increments integrate with existing ones to improve system functionality.

Prepared by : Prof. Roshini P 53 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• The incremental development process has a number of advantages:

1. Customers do not have to wait until the entire system is delivered before they can gain
value from it. The first increment satisfies their most critical requirements so they can
use the software immediately.
2. Customers can use the early increments as prototypes and gain experience that
informs their requirements for later system increments.
3. There is a lower risk of overall project failure. Although problems may be
encountered in some increments, it is likely that some will be successfully delivered
to the customer.
4. As the highest priority services are delivered first, and later increments are integrated
with them, it is inevitable that the most important system services receive the most
testing. This means that customers are less likely to encounter software failures in the
most important parts of the system.

Problems with Incremental Delivery

• Size and Functionality:

o Increments should be relatively small (no more than 20,000 lines of code).
o Each increment must deliver some system functionality.
o Mapping customer requirements to appropriately sized increments can be
challenging.
• Common Facilities:
o Many systems require basic facilities used across different parts.
o Requirements are not defined in detail until an increment is developed.
o Identifying common facilities needed by all increments can be difficult.
• Extreme Programming (variant of this incremental approach):
o Key Features:
▪ Development and delivery of very small increments of functionality.
▪ High customer involvement in the process.
▪ Constant code improvement.
▪ Pair programming.

Figure 4.4 Incremental delivery

4.2.2 Spiral development

• Proposed by Boehm (1988).

• Represents the software process as a spiral with multiple phases.

Prepared by : Prof. Roshini P 54 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Each loop in the spiral represents a phase of the software process.

o Innermost Loop: Might focus on system feasibility.
o Next Loops: Could address requirements definition, system design, etc.

• Each loop in the spiral is split into four sectors:

1. Objective Setting:
o Define specific objectives for the phase.
o Identify constraints and draw up a detailed management plan.
o Identify project risks and plan alternative strategies.
2. Risk Assessment and Reduction:
o Analyze identified project risks.
o Take steps to reduce risk, such as developing a prototype if requirements are
uncertain.
3. Development and Validation:
o Choose an appropriate development model based on risk evaluation.
o Options include evolutionary prototyping for user interface risks or formal
transformations for safety risks.
o The waterfall model may be used if integration is a major risk.
4. Planning:
o Review the project and decide whether to continue with another loop of the
spiral.
o If continuing, plan for the next phase.

• The main difference between the spiral model and other software process models is:

• Explicit recognition of risk.

• Risks are issues that could cause problems such as schedule and cost overruns.

• Spiral Cycle:

• Spiral begins by elaborating objectives such as performance and functionality.

• Alternative ways of achieving these objectives and the constraints imposed on each of
them are then enumerated. Each alternative is assessed against each objective and
sources of project risk are identified.
• The next step is to resolve these risks by information-gathering activities such as more
detailed analysis, prototyping and simulation.
• Once risks have been assessed, some development is carried out, followed by a
planning activity for the next phase of the process

Prepared by : Prof. Roshini P 55 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

Figure 4.5 Boehm’s spiral model of the software process (©IEEE, 1988)

4.3 Process activities

• Basic Process Activities:

• Specification
• Development
• Validation
• Evolution

• Waterfall Model:

• Activities are organized in a sequence:

o Specification → Development → Validation → Evolution

• Evolutionary Development:

• Activities are interleaved:

o Specification, Development, and Validation occur together and continuously.

• These activities are carried out depends on

• Type of Software

Prepared by : Prof. Roshini P 56 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• People Involved
• Organizational Structures

• The main goal is to provide an introduction to different ways of organizing these activities.

4.3.1 Software specification

• Understanding and defining what services are required from the system and
identifying constraints on its operation and development.
• Critical stage of the software process; errors here lead to problems in system design
and implementation.

• Requirements Document:

• Contains high-level statements for end-users and customers.

• Includes detailed system specifications for developers.

• There are four main phases in the requirements engineering process:

1. Feasibility Study:
o Estimate whether user needs can be met with current technology.
o Assess cost-effectiveness and budget constraints.
o Should be relatively cheap and quick; informs the decision to proceed.
2. Requirements Elicitation and Analysis:
o Derive system requirements through observation, discussions, and task
analysis.
o May involve developing system models and prototypes.
3. Requirements Specification:
o Translate gathered information into a requirements document.
o Includes:
▪ User Requirements: Abstract statements for customers and end-users.
▪ System Requirements: Detailed description of functionality.
4. Requirements Validation:
o Check for realism, consistency, and completeness.
o Identify and correct errors in the requirements document.

• Activities are interleaved; analysis continues during definition and specification.

• In agile methods (e.g., extreme programming), requirements are developed incrementally
and elicited from users who are part of the development team.

Prepared by : Prof. Roshini P 57 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

4.3.2 Software design and implementation

• The implementation stage of software development is the process of converting a

system specification into an executable system.
• Involves software design and programming. If using an evolutionary development
approach, it may also include refining the software specification.

Software Design:

• Describes the structure of the software to be implemented, including:

o data which is part of the system
o Interfaces between system components
o Algorithms used (sometimes)
• Process:
o Iterative Development: The design evolves through multiple versions.
o Backtracking: Earlier designs are corrected based on feedback i.e designers do
not arrive at a finished design immediately but develop the design iteratively
through a number of versions. Multiple models at different abstraction levels
are developed.

Design Process Model(ref Figure 4.7 ):

• Design process may involve developing several models of the system at different
levels of abstraction. As a design is decomposed, errors and omissions in earlier
stages are discovered.
• These feedbacks allow earlier design models to be improved.
• Outputs of each design activity, becoming more detailed over time.
o Abstract or formal, clarifying requirements.
o includes detailed algorithms and data structures.

Prepared by : Prof. Roshini P 58 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

The specific design process activities are:

1. Architectural Design:
o Identify and document sub-systems and their relationships.

2. Abstract Specification:
o Abstract specifications of its services and the constraints for each sub-system
to operate are produced.
3. Interface Design:
o Design and document the interfaces between sub-systems.
o Ensure interfaces are unambiguous, using formal specification methods if
needed .
4. Component Design:
o Allocate services to components.
o Interfaces of these components are designed.
5. Data Structure Design:
o The data structures used in the system implementation are designed in detail
and specified.
6. Algorithm Design:
o Design and specify algorithms used to provide services in detail.

→ The design process is iterative and involves feedback and refinement. Starting with
abstract specifications and progressing to detailed designs, it includes architectural,
interface, component, data structure, and algorithm design activities.

A general model of the design process and real, practical processes may adapt it in different
ways. Possible adaptations are:

1. The last two stages of design—data structure and algorithm design—may be delayed until
the implementation process.

2. If an exploratory approach to design is used, the system interfaces may be designed after
the data structures have been specified.

Prepared by : Prof. Roshini P 59 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

3. The abstract specification stage may be skipped, although it is usually an essential part of
critical systems design.

Agile Methods:

o Outputs of the design process are represented in the program code rather than
separate specification documents.
o After designing the system architecture, later stages of design are incremental
and represented as program code.

Structured Methods:

• Graphical Models and Code Generation:

o Use graphical models of the system and may automatically generate code from
these models.
o Structured methods were developed in the 1970s to support function-oriented
design.
o Competing methods for object-oriented design led to the creation of the
Unified Modeling Language (UML) and the unified design process.
o UML 2.0 is currently undergoing a major revision.

Components of Structured Methods:

• Includes: Design process model, notations, report formats, rules, and design
guidelines.

Supported Models:

1. Object Model: Shows the object classes used in the system and their dependencies.
2. Sequence Model: Shows how objects interact during system execution.
3. State Transition Model: Shows system states and triggers for transitions between
states.
4. Structural Model: Documents the system components and their aggregations.
5. Data Flow Model: Models the system using data transformations. This is less
common in object-oriented methods but still used in real-time and business system
design.

• Structured methods are standard notations and embodiments of good practice.

• Following these methods and applying the guidelines can result in a reasonable design.
• Designer creativity is still required for system decomposition and to ensure that the
design adequately captures the system specification.
• Empirical studies of designers (Bansler and Bødker, 1993) show that designers rarely
follow methods slavishly. They pick and choose from the guidelines according to local
circumstances.

Program Development:

• The development of a program to implement the system follows naturally from the
system design processes.
• For safety-critical systems, detailed design usually precedes implementation.

Prepared by : Prof. Roshini P 60 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• More commonly, later stages of design and program development are interleaved.
• CASE tools may be used to generate a skeleton program from a design. This includes
code to define and implement interfaces; developers often only need to add details of
the operation of each program component.

Programming Practices:

• Programming is a personal activity with no general process usually followed.

• Some programmers start with components they understand and develop them first,
while others start with less familiar components.
• Some define data early in the process and use it to drive program development; others
leave data unspecified for as long as possible.

Testing and Debugging:

• Programmers normally carry out some testing of the code they have developed,
revealing program defects that must be removed is called debugging.
• Defect Testing: Establishes the existence of defects.
• Debugging: Concerned with locating and correcting these defects.

Debugging Process: (Figure 4.8 illustrates the stages of debugging)

• Defects in the code must be located, and the program must be modified to meet its
requirements.
• Testing must be repeated to ensure that changes have been made correctly.
• Debugging is part of both software development and software testing.

Hypothesis Testing in Debugging:

• Generate hypotheses about the observable behavior of the program and test these
hypotheses to find the fault causing the output anomaly.
• Testing hypotheses may involve:
o Tracing the program code manually.
o Writing new test cases to localize the problem.
o Using interactive debugging tools that show intermediate values of program
variables and a trace of the statements executed to aid in the debugging
process.

4.3.3 Software validation:

Verification and Validation (V & V):

• To show that a system conforms to its specification and meets the expectations of the
customer.

Prepared by : Prof. Roshini P 61 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• Involves: Checking processes such as inspections and reviews at each stage of the
software process from user requirements definition to program development.
• Costs: The majority of validation costs are incurred after implementation when the
operational system is tested.

Testing Process:

• Not Monolithic: Except for small programs, systems should not be tested as a single,
monolithic unit.

• Three-Stage Testing Process:

1. Component (or unit) Testing:
▪ Individual components are tested to ensure they operate correctly.
▪ Each component is tested independently, without other system
components.
▪ Components may be simple entities like functions or object classes, or
coherent groupings of these entities.
2. System Testing:
▪ Components are integrated to make up the system.
▪ Focuses on finding errors from unanticipated interactions between
components and component interface problems.
▪ Also validates that the system meets its functional and non-functional
requirements and tests emergent system properties.
▪ For large systems, this may be a multistage process where components
are integrated into sub-systems, tested individually, and then integrated
into the final system.
3. Acceptance Testing:
▪ The final stage before the system is accepted for operational use.
▪ The system is tested with data supplied by the system customer rather
than simulated test data.
▪ May reveal errors and omissions in the system requirements definition
because real data exercise the system differently from test data.
▪ May also reveal requirements problems where the system’s facilities
do not meet user needs or where system performance is unacceptable.

• As defects are discovered, the program must be debugged, which may require repeating
other stages in the testing process.
• Errors in program components may come to light during system testing.
• The process is iterative with feedback from later stages affecting earlier parts of the
process.
• Normally, component development and testing are interleaved.
• Programmers create their own test data and incrementally test the code as it is developed.

Prepared by : Prof. Roshini P 62 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• This is economically sensible as the programmer knows the component best and is
therefore the best person to generate test cases.
• If an incremental approach is used, each increment should be tested as it is developed.
• Tests should be based on the requirements for that increment.
• In extreme programming, tests are developed along with the requirements before
development starts.
• This approach helps testers and developers understand the requirements and ensure no
delays in creating test cases.

Later Stages of Testing:

• Integration and Planning:

o Later stages of testing involve integrating work from multiple programmers
and must be planned in advance.
o An independent team of testers should work from pre-formulated test plans
developed from the system specification and design.
o Figure 4.10 illustrates how test plans are the link between testing and
development activities.

Figure 4.10 Testing phases in the software process

Acceptance Testing:

• Alpha Testing:
o Acceptance testing is sometimes called alpha testing.
o Custom systems are developed for a single client.
o The alpha testing process continues until the system developer and the client
agree that the delivered system is an acceptable implementation of the system
requirements.

• Beta Testing Process:

o When a system is marketed as a software product, beta testing is often used.
o Beta testing involves delivering a system to a number of potential customers
who agree to use the system and report problems to the system developers.
o This exposes the product to real use and detects errors that may not have been
anticipated by the system builders.

Prepared by : Prof. Roshini P 63 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o After this feedback, the system is modified and released either for further beta
testing or for general sale.

4.3.4 Software evolution:

Incorporation in Large Systems:

o The flexibility of software systems is one of the main reasons why more and
more software is being incorporated into large, complex systems.
o Once a decision has been made to procure hardware, it is very expensive to
make changes to the hardware design.
o However, changes can be made to software at any time during or after the
system development.
o Even extensive changes are still much cheaper than corresponding changes to
system hardware.

Development vs. Maintenance:

• Historical Split:
o Historically, there has always been a split between the process of software
development and the process of software evolution (software maintenance).
o Software development is seen as a creative activity where a software system is
developed from an initial concept through to a working system.
o Software maintenance is sometimes thought of as dull and uninteresting.
o Although the costs of 'maintenance' are often several times the initial
development costs, maintenance processes are sometimes considered less
challenging than original software development.
• Continuum of Development and Maintenance:
o The distinction between development and maintenance is becoming
increasingly irrelevant.
o Few software systems are now completely new systems, making it more
sensible to see development and maintenance as a continuum.
o It is more realistic to think of software engineering as an evolutionary process
(Figure 4.11) where software is continually changed over its lifetime in
response to changing requirements and customer needs.

4.4 The Rational Unified Process

• The Rational Unified Process (RUP) is a modern process model derived from work on
the UML and the Unified Software Development Process (Rumbaugh, et al., 1999b).

Prepared by : Prof. Roshini P 64 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• RUP is a hybrid process model that combines elements from all generic process
models, supports iteration, and illustrates good practice in specification and design.

The RUP recognizes that conventional process models present a single view of the
process. In contrast, the RUP is normally described from three perspectives:

1. Dynamic Perspective:
o Shows the phases of the model over time.
2. Static Perspective:
o Shows the process activities that are enacted.
3. Practice Perspective:
o Suggests good practices to be used during the process.

• Most descriptions of RUP combine the static and dynamic perspectives in a single
diagram, which can make the process harder to understand. Therefore, separate
descriptions of each perspective are used.

Phases of RUP:

1. Inception:
o Goal: Establish a business case for the system.
o Identify all external entities (people and systems) that will interact with the
system and define these interactions.
o Assess the contribution of the system to the business. If this contribution is
minor, the project may be cancelled after this phase.
2. Elaboration:
o Goals:
▪ Develop an understanding of the problem domain.
▪ Establish an architectural framework for the system.
▪ Develop the project plan and identify key project risks.
o Completion:
▪ Requirements model for the system (UML use cases specified).
▪ Architectural description.
▪ Development plan for the software.
3. Construction:
o Concerned with: System design, programming, and testing.
o Parts of the system are developed in parallel and integrated during this phase.
o Completion:
▪ A working software system and associated documentation that is ready
for delivery to users.
4. Transition:
o Focus: Moving the system from the development community to the user
community and making it work in a real environment.
o This phase is often ignored in other software process models but is expensive
and sometimes problematic.
o Completion:
▪ A documented software system that is working correctly in its
operational environment.

• Each phase may be enacted in an iterative way with results developed incrementally.

Prepared by : Prof. Roshini P 65 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• The entire set of phases may also be enacted incrementally, with a looping arrow from
Transition to Inception indicating this iterative nature (ref Figure 4.12)

Static View of the RUP:

• Focus: The activities that take place during the development process, called
workflows in the RUP description.
• Core Process Workflows:
o Six core process workflows are identified.
o Three core supporting workflows.
• The workflow description is oriented around associated UML models as RUP was
designed in conjunction with the UML—an object-oriented modelling language.
• Core Engineering and Support Workflows: Described in Figure 4.13.

Figure 4.13 Static workflows in Rational Unified Process

• Advantage:
o Phases of the development process are not associated with specific workflows.
o In principle, all RUP workflows may be active at all stages of the process.
o Most effort will likely be spent on workflows such as business modelling and
requirements in the early phases, and on testing and deployment in the later
phases.

Prepared by : Prof. Roshini P 66 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

• The practice perspective on the RUP describes good software engineering practices
that are recommended for use in systems development.

Six fundamental best practices are recommended:

1. Develop Software Iteratively:

▪ Plan increments based on customer priorities.
▪ Develop and deliver the highest priority system features early in the
development process.
2. Manage Requirements:
▪ Explicitly document the customer’s requirements.
▪ Keep track of changes to these requirements.
▪ Analyse the impact of changes on the system before accepting them.
3. Use Component-Based Architectures:
▪ Structure the system architecture into components.
4. Visually Model Software:
▪ Use graphical UML models to present static and dynamic views of the
software.
5. Verify Software Quality:
▪ Ensure that the software meets the organisational quality standards.
6. Control Changes to Software:
▪ Manage changes using a change management system and configuration
management procedures and tools .

RUP usually is :

• Not Suitable for All Development Types:

o The RUP represents a new generation of generic processes.
• Important Innovations:
o Separation of phases and workflows.
o Recognition that deploying software in a user’s environment is part of the
process.
• Phases vs. Workflows:
o Phases are dynamic and have goals.
o Workflows are static and technical activities not associated with a single phase
but used throughout development to achieve the goals of each phase.

4.5 Computer-Aided Software Engineering

• Computer-Aided Software Engineering (CASE) refers to software used to support

software process activities such as requirements engineering, design, program
development, and testing.
• CASE tools include design editors, data dictionaries, compilers, debuggers, system
building tools, and more.
• CASE technology provides software process support by automating some process
activities and by providing information about the software that is being developed.

Examples of activities that can be automated using CASE include:

1. Development of graphical system models as part of requirements specification
or software design.

Prepared by : Prof. Roshini P 67 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

2. Understanding a design using a data dictionary that holds information about

entities and relations in a design.
3. Generation of user interfaces from a graphical interface description created
interactively by the user.
4. Program debugging through the provision of information about an executing
program.
5. Automated translation of programs from an old version of a programming
language (e.g., COBOL) to a more recent version.

Improvements and Limitations:

• Improvements:
o CASE technology is available for most routine activities in the software
process.
o It has led to some improvements in software quality and productivity, though
less than early predictions suggested.
o Early advocates predicted orders of magnitude improvement with integrated
CASE environments.
o Actual improvements achieved are of the order of 40% (Huff, 1992).

• The improvements from the use of CASE are limited by two factors:

- Software engineering is a design activity based on creative thought. Existing

CASE systems automate routine activities but attempts to use artificial
intelligence for design support have not been successful.
- Software engineering is often a team activity, with significant interaction
between team members. CASE technology does not provide much support for
this interaction.

• CASE technology is now mature, with CASE tools and workbenches available from a
wide range of suppliers.
• Rather than focusing on specific tools, an overview of tools is provided, with further
discussion on specific support in other chapters.
• Links to additional material on CASE and CASE tool suppliers are available on the web
pages.

4.5.1 CASE classification

Classification Perspectives:

1. Functional Perspective:
o CASE tools are classified according to their specific function.
2. Process Perspective:
o Tools are classified according to the process activities that they support.
3. Integration Perspective:
o CASE tools are classified according to how they are organised into integrated
units that provide support for one or more process activities.

• Figure 4.14:
o Classifies CASE tools according to function.

Prepared by : Prof. Roshini P 68 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

o Lists different types of CASE tools with specific examples.

o Note: This is not a complete list of CASE tools. Specialised tools (e.g., tools to
support reuse) are not included.

• Figure 4.15:
o Presents an alternative classification of CASE tools.
o Shows the process phases supported by various types of CASE tools.
• Tools for planning and estimating, text editing, document preparation and configuration
management may be used throughout the software process.

Prepared by : Prof. Roshini P 69 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

Fuggetta’s Classification (1993):

1. Individual Process Tasks:

o Support tasks such as checking design consistency, compiling programs, and
comparing test results.
o Can be general-purpose, standalone tools (e.g., a word processor) or grouped
into workbenches.
2. Workbenches:
o Support process phases or activities like specification, design, etc.
o Typically consist of a set of tools with some degree of integration.
3. Environments:
o Support all or a substantial part of the software process.
o Normally include several integrated workbenches.

Figure 4.16:

• Illustrates Fuggetta’s classification with examples.

• General-purpose Tools:
o Used at the discretion of the software engineer for process support.
• Workbenches:
o Support a method that includes a process model and a set of rules/guidelines
for software development.
• Environments:
o Integrated Environments: Provide infrastructure support for data, control,
and presentation integration.
o Process-Centered Environments: Include software process knowledge and a
process engine that advises engineers on tool/application use based on the
process model.

Prepared by : Prof. Roshini P 70 MIT,Mysore

MIT,Mysore Software Engineering - M23BCS305

Note:

• Boundaries between classes can be blurred. Tools may offer support for different
activities or embed multiple functions.
o Example: Word processors may include diagram editors.
o CASE workbenches for design may also support programming and testing,
resembling environments rather than specialized workbenches.

• Classification helps understand the extent of process support a tool provides, although
positioning a product within a classification can be challenging.

Prepared by : Prof. Roshini P 71 MIT,Mysore