1 | Page

🔹 1. What is the purpose of software testing in software

development?

Answer:
The purpose of software testing is to verify that the software functions as
intended and to identify any defects before the software is released. It
helps ensure the system behaves correctly and meets both developer and
customer expectations

4. What are the main goals of program testing?

Answer:
The goals of program testing are to demonstrate that the software meets
its specified requirements and to identify any incorrect, unexpected, or
undesirable behavior in the system that could lead to defects or failures.

5. Distinguish between validation testing and defect testing.

Answer:
Validation testing ensures that the software performs correctly according
to the specified requirements, using normal expected inputs. In contrast,
defect testing aims to uncover system errors using unusual or edge-case
inputs to provoke incorrect behavior.

2. What is the difference between validation and verification?

Answer:

 Validation: Are we building the right product?

 Verification: Are we building the product right?

1. What is the aim of the Verification and Validation (V&V) process in

software engineering?

Aim of V & V is to establish confidence that the system is ‘fit for purpose’ .
Depends on system’s purpose, user expectations and marketing
environment
Software purpose

The level of confidence depends on how critical the software is to an

organisation.

User expectations

Users may have low expectations of certain kinds of software.

Marketing environment
2 | Page

Getting a product to market early may be more important than finding

defects in the program.

3. What is the difference between software inspections and

software testing?

Answer:
Software inspections involve examining system representations (e.g.,
code or documents) to find defects without execution. Software testing
involves executing the program with test data to observe runtime
behavior and detect errors, making it a dynamic verification process.

4. What are the advantages of software inspections over testing?

Answer:
Inspections can detect defects without execution, avoiding the issue of
error masking. They can be applied early, even on incomplete systems,
and help assess quality attributes like maintainability, standards
compliance, and portability beyond just functional correctness.
5. Why should both inspections and testing be used in the V&V
process?

Answer:
Inspections and testing are complementary. Inspections ensure design and
code conform to specifications, while testing validates behavior against
actual use. Together, they provide a broader assurance of software quality
than either method alone.

6. What are the main stages of the software testing process?

Answer:
The main stages are:

1. Development testing – done during development to find bugs

early.

2. Release testing – performed by a separate team before release.

3. User testing – conducted by actual users in a real environment.

1. What is development testing and what are its main types?

Answer:
Development testing is carried out by the development team and includes unit testing,
component testing, and system testing. It ensures that individual units work correctly,
components interact properly, and the complete system functions as expected when
integrated.
3 | Page

2. What is the focus of unit testing in software development?

Answer:
Unit testing focuses on testing individual functions, methods, or classes in isolation to
detect defects. It ensures that each program unit behaves correctly before integrating it
into larger components or systems for further testing.

5. What aspects should be tested during object class testing?

Answer:
Object class testing involves testing all class operations, accessing and modifying all
attributes, and exercising the object in every valid state. It aims for comprehensive test
coverage to ensure class functionality and reliability.

2. What is the focus of unit testing in software development?

Answer:
Unit testing focuses on testing individual functions, methods, or classes in isolation to
detect defects. It ensures that each program unit behaves correctly before integrating it
into larger components or systems for further testing.

1. What is automated unit testing and how is it beneficial?

Answer:
Automated unit testing uses testing frameworks like JUnit to run tests without manual
input. It speeds up the testing process, ensures consistency, and provides quick feedback
via GUI reports, helping developers detect issues early in the development cycle.

2. What are the main components of an automated test?

Answer:
Automated tests consist of three parts: setup (initializing test inputs and expected
outputs), call (executing the method or object under test), and assertion (comparing the
actual output with the expected result to determine success or failure).

Testing strategies

4. What is partition testing and how does it help in software testing?

Answer:
Partition testing divides inputs into groups with similar characteristics. A representative input
from each group is tested to ensure the component processes all variations correctly,
increasing test coverage while minimizing the number of test cases needed.

5. How does guideline-based testing improve the testing process?

Answer:
Guideline-based testing uses established testing rules derived from common developer errors.
These guidelines help in selecting test cases that are more likely to uncover defects based on
past experiences and known programming pitfalls.
4 | Page

4. What are some general guidelines for designing effective test cases?

Choose inputs that force the system to generate all error messages

Design inputs that cause input buffers to overflow

Repeat the same input or series of inputs numerous times

Force invalid outputs to be generated

Force computation results to be too large or too small.

1. What is the main focus of component testing in software systems?

Answer:
Component testing focuses on verifying that the interface of a composite component behaves
according to its specification. It assumes that unit testing for individual objects is complete
and ensures that object interactions work correctly through the defined interface.

2. What are the objectives of interface testing?

Objectives are to detect faults due to interface errors or invalid assumptions about interfaces.

3. What are the different types of software interfaces tested during interface testing?
The different interface types include parameter interfaces, shared memory interfaces,
procedural interfaces, and message-passing interfaces.
Parameter interfaces Data passed from one method to another. Shared memory interfaces
Block of memory is shared between functions. Procedural interfaces Sub-system encapsulates
a set of procedures to be called by other sub-systems. Message passing interfaces Sub-
systems request services from other sub-systems

4. What are common interface errors encountered during software testing?

Answer:
Common interface errors include interface misuse (e.g., incorrect parameter order), interface
misunderstanding (wrong assumptions about component behavior), and timing errors
(components operating at different speeds, causing outdated data to be accessed).

1. What is the primary focus of system testing during software development?

Answer:
System testing focuses on verifying the interactions between integrated components. It
checks whether components are compatible, exchange data correctly, and work together to
exhibit the expected system behavior, also known as emergent behavior

3. Why is system testing considered a collective process?

Answer:
System testing is a collective process because it integrates components developed by different
teams or sub-teams. It often involves a dedicated testing team, independent from the
developers, to ensure objective evaluation of the system as a whole.
5 | Page

4. What is use-case testing, and how is it applied in system testing?

Answer:
Use-case testing involves testing the system based on predefined use cases that represent real-
world interactions. It ensures that multiple components involved in each use case interact
correctly, and the system functions properly under typical user scenarios.

What are the key activities in the test-driven development (TDD) process?

Answer:
TDD starts with identifying a small functionality increment. A test is written before
implementation. Initially, it fails. Then the required code is implemented and re-tested. Once
the test passes, development moves to the next increment. This cycle ensures continuous
validation and better alignment with requirements.

1.What are the benefits of using test-driven development?

Code coverage:-
Every code segment that you write has at least one associated test so all code written has at
least one test.
Regression testing:-
A regression test suite is developed incrementally as a program is developed.
Simplified debugging:-
When a test fails, it should be obvious where the problem lies.The newly written code needs
to be checked and modified.
System documentation:-
The tests themselves are a form of documentation that describe what the code should be
doing.

What is the main objective of release testing?

Answer:
The main objective of release testing is to validate that the system is ready for external use. It
6 | Page

ensures the system meets its specified functionality, performance, and dependability, and
demonstrates that it operates correctly under normal usage conditions. Release testing is
usually a black-box testing process where tests are only derived from the system
specification.

How does release testing differ from system testing?

Answer:
System testing is usually performed by the development team to detect defects, while release
testing is done by a separate team to validate the system against requirements. Release testing
confirms readiness for deployment, focusing on user validation rather than just identifying
bugs.

Q1: What is the purpose of user testing in the software development process?

✅ Answer:
User testing ensures that the software works effectively in the real-world environment of the
end user. It identifies usability, performance, and reliability issues that may not appear during
internal system or release testing.

Q2: What are the three main types of user testing?

✅ Answer:
The three types of user testing are:

 Alpha Testing: Conducted at the developer’s site with user collaboration.

 Beta Testing: Software is released to external users for feedback.
 Acceptance Testing: Customer verifies if the software meets requirements for
deployment.

Q3: Why is user testing still necessary after system and release testing?

✅ Answer:
System and release testing can't fully simulate the user's environment. User testing captures
real-world usage conditions, helping identify issues related to robustness, usability, and actual
system behavior under everyday use.

Q4: What is the main goal of acceptance testing?

Answer:
The main goal of acceptance testing is to let the customer decide whether the software is
ready for deployment. It verifies that the system meets all business and functional
requirements.

The acceptance testing process

7 | Page

❓ Q1: How is acceptance testing handled in agile development methods?

✅ Answer:
In agile methods, acceptance testing is not a separate phase. Instead, the customer or user is
part of the development team and defines acceptance tests, which are then integrated and run
automatically with other tests during development.

❓ Q2: What is the role of the user/customer in agile acceptance testing?

✅ Answer:
The user/customer is responsible for defining what makes the system acceptable. They
actively participate in writing and reviewing acceptance tests to ensure the software meets
their needs.

Q1: Why is software change considered inevitable?

Answer:
Software change is inevitable because:

 New requirements emerge during actual usage.

 Business environments evolve.
 Bugs and errors need fixing.
 New hardware or technologies are introduced.
 System performance or reliability may need improvement

Q4: Why is software evolution important for organizations?

Answer:
Because software represents a critical business asset. Organizations must evolve systems to:

 Stay competitive
 Ensure system relevance
 Maximize the return on their initial investment
8 | Page

Evolution
The stage in a software system’s life cycle where it is in operational use and is evolving as
new requirements are proposed and implemented in the system.
servicing
In servicing, the software is only modified to keep it operational—through bug fixes or
environmental updates. No new features or functionality are added, unlike in evolution
where the system is enhanced with new capabilities.
phaseout
During phase-out, the software may still be used, but no further changes or updates are
made. It marks the beginning of the end of the software’s active life cycle.

Q1: What factors influence software evolution processes?

Answer:
Software evolution processes depend on:

 The type of software being maintained

 The development process used
 The skills and experience of the team involved

Q2: What initiates software evolution?

 Answer:
Proposals for change act as the main driver for system evolution. These may include
bug fixes, performance enhancements, or adapting to new requirements.
9 | Page
10 | P a g e

Q1: What is change implementation in software evolution?

 Answer:
Change implementation is an iteration of the development process where revisions to
the system are designed, implemented, and tested. It often begins with program
understanding, especially when the original developers are not involved.
Q3: What are urgent change requests, and why do they bypass regular processes?
Answer:
Urgent change requests occur in situations like:
 System faults that need immediate repair
 Unexpected issues due to environment changes (e.g., OS updates)
 Rapid business demands (e.g., competition)
11 | P a g e

Question: What challenges arise when there is a mismatch between the

development and evolution approaches in software projects?
Answer:
When development uses agile methods but the evolution team prefers plan-based
approaches, issues arise due to the lack of detailed documentation typically
expected in plan-driven processes. Conversely, if the system was developed with a
plan-based approach but the evolution team prefers agile, they may struggle with
the absence of automated tests and clean, refactored code, often requiring them to
begin such practices from scratch.

Q1: What is a legacy system in software engineering?

Answer:
A legacy system is an older software system that depends on outdated technologies,
languages, or hardware. It is typically still in use due to its importance in business
operations, despite being difficult to maintain or upgrade.

📘 Important Questions and Answers from Legacy Systems:

🔹 Q1: What is a legacy system in software engineering?

Answer:
A legacy system is an older software system that depends on outdated technologies,
languages, or hardware. It is typically still in use due to its importance in business
operations, despite being difficult to maintain or upgrade.

🔹 Q2: What are the main components of a legacy system?

12 | P a g e

Answer:
The components of a legacy system include:
 System hardware: May be obsolete or unavailable.
 Support software: Older tools or platforms the system depends on.
 Application software: Core programs providing business services.
 Application data: Business data, possibly inconsistent or duplicated.
 Business processes: Business workflows designed around the legacy system.
 Business policies and rules: Operational constraints that depend on the legacy
system.

🔹 Q3: Why is it difficult to replace legacy systems?

Answer:
Legacy systems are deeply integrated into business operations, often involving custom
business rules, processes, and large datasets. Replacing them risks disrupting essential
services and can be costly and complex.

Q1: Why is legacy system replacement considered risky and expensive?

Answer: Legacy system replacement is risky due to:

 Lack of complete and up-to-date system specifications.

 Tight integration of the system with core business processes.
13 | P a g e

 Undocumented business rules embedded in the legacy system.

 The risk that new software may be delayed or exceed budget.

🔹 Q2: What makes changing a legacy system expensive?

Answer: Several factors make legacy system change costly:

 Inconsistent programming styles.

 Use of obsolete languages with limited skilled professionals.
 Poor or missing documentation.
 Degraded and complex system structure.
 Program optimizations that hinder readability.
 Issues like data errors, redundancy, and inconsistency.

🔹 Q3: What are the main strategies for managing legacy systems?

Answer: Organizations can manage legacy systems through four key strategies:

1. Scrap the system and modify business processes accordingly.

2. Continue maintenance if the system remains functional.
3. Transform the system by re-engineering to enhance maintainability.
4. Replace the system with a new one, if feasible.

Q1: How are legacy systems categorized based on quality and business value?

Answer:

Legacy systems are categorized into four groups:

1. Low Quality, Low Business Value

➤ Should be scrapped.
2. Low Quality, High Business Value
➤ Should be re-engineered or replaced, if a better system is available.
3. High Quality, Low Business Value
➤ Can be replaced with COTS (Commercial Off-The-Shelf) software, scrapped,
or maintained.
4. High Quality, High Business Value
➤ Should be maintained through normal system maintenance.

🔹 Q2: What is the purpose of business value assessment in legacy system evaluation?

Answer:
14 | P a g e

The purpose of business value assessment is to determine the strategic importance of a

system by considering its impact on different stakeholders. This helps in deciding whether to
maintain, re-engineer, replace, or retire the system.

🔹 Q3: Whose viewpoints should be considered during business value assessment?

Answer:

Business value assessment should take into account the views of:

 System end-users
 Business customers
 Line managers
 IT managers
 Senior managers

Interviewing and collating feedback from these stakeholders provides a comprehensive view
of the system's importance.

Q1: What factors affect the business value assessment of a legacy system?

Answer: The business value of a legacy system can be influenced by:

 Usage frequency: Systems used occasionally or by few people may have low
business value.
 Supported business processes: If the system enforces inefficient processes, it lowers
business value.
 System dependability: Undependable systems that impact customers negatively have
low business value.
 System outputs: Systems that produce critical outputs for the business have high
business value.

🔹 Q2: What are the three key areas involved in system quality assessment?

Answer: System quality is assessed in three main areas:

1. Business process assessment: How well business processes supported by the system
align with current business goals.
2. Environment assessment: Effectiveness and maintenance costs of the system’s
environment.
3. Application assessment: Overall quality of the application software itself.

Q1: What factors are considered in environment assessment for a legacy system?

Answer: Factors include:

15 | P a g e

 Supplier stability: Is the supplier still active and financially stable?

 Failure rate: How often does the hardware or support software fail?
 Age: How old is the hardware and software?
 Performance: Is the system performance adequate?
 Support requirements: Are high support costs involved?
 Maintenance costs: Are hardware and software maintenance costs high?
 Interoperability: Are there difficulties connecting the system to newer systems?

🔹 Q2: What factors are considered during application assessment?

Answer: Factors include:

 Understandability: Is the code clear and easy to understand?

 Documentation: Is complete and current documentation available?
 Data: Is data consistent and managed well?
 Performance: Does the application meet performance expectations?
 Programming language: Is the language still widely used and supported?
 Configuration management: Are different system versions managed properly?
 Test data: Are proper tests and regression records available?
 Personnel skills: Are skilled people available to maintain the system?

🔹 Q3: What are some metrics used for system measurement?

Answer: System quality can be measured by:

 Number of system change requests: More requests imply lower quality.

 Number of different user interfaces: More interfaces can mean inconsistencies.
 Volume of data: Larger data volumes often mean more errors and inconsistencies.

Q: What are the different types of software maintenance?

Answer: The three main types of software maintenance are:

1. Fault repairs
o Fixing bugs, vulnerabilities, and correcting deficiencies to meet
requirements.
2. Environmental adaptation
o Modifying the system so it can run in a different environment
(e.g., new hardware or operating system).
3. Functionality addition and modification
o Adding or changing system functionality to satisfy new business
or user requirements.

Q: What is software maintenance, and how is it typically performed?

16 | P a g e

 Answer:
Software maintenance refers to modifying a program after it has been put into use,
usually to correct faults, improve performance, or adapt it to a changed environment.
It mainly applies to custom software, while generic software products are said to
evolve into new versions.
Maintenance does not normally involve major architectural changes; instead, it
focuses on modifying existing components and adding new components to improve
or adapt the system.

Q8: Name four important process metrics used to assess maintainability.

Answer:

 Number of requests for corrective maintenance,

 Average time required for impact analysis,
 Average time taken to implement a change request,
 Number of outstanding change requests.

Q6: What factors affect the complexity of a system component?

Answer:
The complexity depends on:

 Complexity of control structures,

 Complexity of data structures,
 Object, method (procedure), and module size.

Q1: What is change prediction concerned with?

 Answer:
Change prediction is concerned with predicting the number of changes by
understanding the relationship between a system and its environment.

Q: What is maintenance prediction in software engineering?

A:
Maintenance prediction involves assessing which parts of a software system may cause
problems and result in high maintenance costs.
It highlights that:

 Change acceptance depends on the maintainability of affected components.

 Implementing changes often degrades system structure and maintainability.
 Maintenance costs are linked to the number of changes and the maintainability of the
system
17 | P a g e

Q: What is software reengineering?

A:
Software reengineering is the process of restructuring or rewriting part or all of a legacy
system without changing its functionality.
It is used when only some subsystems need frequent maintenance, making the overall system
easier to maintain by restructuring and re-documenting.

Q: What are the advantages of software reengineering?

A:

 Reduced risk: Avoids problems common in new development like staffing,

specification, and technical issues.
 Reduced cost: Reengineering is often much cheaper than developing an entirely new
system.
18 | P a g e

Q: What is refactoring?

A:
Refactoring is the process of improving a program’s structure, reducing complexity, and
making it easier to understand without adding new functionality. It acts as preventative
maintenance to slow down software degradation over time.

Q: How is refactoring different from reengineering?

A:

 Refactoring is a continuous improvement process during development and evolution

to avoid code degradation.
 Reengineering is performed after long-term maintenance when costs rise, using
automated tools to create a more maintainable version of the system.

Q: What are some examples of 'bad smells' in program code?

A:

 Duplicate code: Same or similar code repeated in multiple places.

 Long methods: Methods that are too long and should be split into shorter ones.
19 | P a g e

 Switch (case) statements: Repeated switch cases can be replaced by polymorphism

in object-oriented languages.
 Data clumping: Groups of related data items repeatedly appearing can be
encapsulated in objects.
 Speculative generality: Unused general features added for potential future use,
which should be removed

Q1. What is Defensive Programming?

A1.
Defensive programming assumes all input is dangerous. It validates data, prevents bugs,
improves security, and ensures stable software by expecting errors and proactively handling
them during development.
Q2. What is the First Rule of Defensive Programming?
A2.
The first rule is "Never Assume Anything." Always check and validate everything—user
inputs, system behavior, and code assumptions to prevent unexpected bugs and errors.
Q4. What should be your Testing Strategy in Defensive Programming?
A4.
Test not just correct inputs but also invalid, strange, and unexpected inputs. Involve both CS
and non-CS testers to uncover hidden bugs and weird edge cases.

Q5. Why is Size of Variables important?

A5.
Variable sizes differ across systems. Assuming wrong sizes causes overflow or bugs. Use
limits.h and sizeof in C to check and safely manage variable storage.

Q6. What is the Second Rule of Defensive Programming?

A6.
The second rule is "Use Standards." Following consistent coding rules reduces errors,
improves readability, and ensures easier maintenance across teams and different parts of the
software.

Q7. What is Hungarian Notation?

A7.
Hungarian Notation prefixes variable names with type hints (e.g., ulCount, szName), helping
programmers quickly recognize variable types and avoid misunderstandings or wrong usage.

Q8. What are Magic Numbers, and why avoid them?

A8.
Magic numbers are hardcoded values that confuse code. Always replace them with named
constants to improve readability, maintainability, and reduce the chance of silent errors.
20 | P a g e

Q9. Why is Proper Indentation important?

A9.
Proper indentation makes code clearer, easier to read, and understand. It shows logical
structure visually, helping prevent mistakes and making debugging much easier.

Q10. What is the Third Rule of Defensive Programming?

A10.
The third rule is "Keep Code Simple." Simpler code has fewer bugs. Focus only on needed
features and plan your program structure carefully before starting.

Q11. What is a Contract in a Function?

A11.
A contract means a function must do exactly one specific task with given inputs and clearly
indicate success or failure, without unexpected side effects.

Q1. What is Architectural Design?

A1.
Architectural design defines the overall structure of a software system, identifying major
components and their relationships. It connects requirements engineering to detailed system
design and produces an architectural model.

Q2. What is the output of Architectural Design?

A2.
The output is an architectural model that shows the system as a set of communicating
components, describing how the system is organized for implementation.

Q3. Why is architecture important in Agile processes?

A3.
In Agile, an initial architecture is designed early because later architectural refactoring is
expensive and difficult, as changes affect many interconnected system components.

Q1. What is Architectural Abstraction?

A1.
"Architecture in the small" focuses on a single program’s structure, while "Architecture in the
large" deals with complex enterprise systems composed of multiple programs across different
computers and organizations.
21 | P a g e

Q2. What are the advantages of explicit architecture?

A2.
Explicit architecture improves stakeholder communication, enables system analysis for non-
functional requirements, and promotes large-scale reuse through product-line architectures
across various systems.

Q3. What are Architectural Representations?

A3.
Architectural representations are mostly simple block diagrams showing entities and
relationships, but they often lack clear semantics and details about component properties or
relationship types.

Q4. What are Box and Line Diagrams?

A4.
Box and line diagrams are highly abstract, hiding relationship details, but they are useful for
communicating system design to stakeholders and for planning projects.

Q5. What is the use of Architectural Models?

A5.
Architectural models help in system design discussions and document complete system
architectures, showing components, interfaces, and connections clearly for stakeholders and
developers.

Q1. What are Architectural Design Decisions?

A1.
Architectural design decisions span all design processes, are creative, differ based on system
type, and significantly affect the system’s non-functional characteristics like performance,
security, safety, and maintainability.
22 | P a g e

Q1. What are Architectural Views?

A1.
Architectural views are different perspectives of a system, showing
module decomposition, process interactions, or component distribution,
requiring multiple views for complete design and documentation.
23 | P a g e

Q1. What is an Architectural Pattern?

A1.
An architectural pattern describes good design practices, tested in
different environments, and provides guidance on when it is or isn’t
useful.

Q2. What is the Model-View-Controller (MVC) Pattern?

A2.
MVC separates system data (Model), data presentation (View), and user
interaction (Controller), allowing independent development and multiple
views of the same data.

Q3. What are the Advantages and Disadvantages of MVC?

A3.
MVC supports independent changes between data and views but adds
complexity when the data model and interactions are simple.
24 | P a g e

Q4. What is the Layered Architecture Pattern?

A4.
The system is organized into layers, each offering services to the layer
above, supporting modular development and easier changes.

Q5. What are the Advantages and Disadvantages of Layered

Architecture?
A5.
Advantages: Easy replacement of layers, increased dependability.
Disadvantages: Difficult clean separation; performance overhead due to
multiple layers.

Q2. What is the 4+1 View Model of Software Architecture?

A2.
It includes logical view (abstractions), process view (runtime processes),
development view (software decomposition), physical view (hardware
mapping), and scenarios (+1) linking them.

Q3. How are Architectural Views Represented?

A3.
UML is often suggested but lacks suitable high-level abstractions.
Architectural Description Languages (ADLs) were developed but are not
widely used.
25 | P a g e

Q1. What is the Repository Architecture?

A1.
In repository architecture, all system data is stored in a central database
accessed by components. Sub-systems exchange data through this shared
repository.

Q2. What is the Repository Pattern?

A2.
The repository pattern manages all data centrally, enabling components
to interact only through the repository without direct communication
between them.

Q3. What are the Advantages and Disadvantages of the

Repository Pattern?
A3.
Advantages: Independent components, consistent data management.
Disadvantages: Single point of failure, possible inefficiencies, hard to
distribute across multiple computers
26 | P a g e

Q1. What is Client-server Architecture?

A1.
Client-server architecture is a distributed system where services are
provided by servers and accessed by clients via a network.

Q2. What is the Client-server Pattern?

A2.
The client-server pattern organizes system functionality into separate
services, with clients accessing these services from different servers.

Q3. What are the Advantages and Disadvantages of Client-server

Architecture?
A3.
Advantages: Distributed servers, shared services.
Disadvantages: Single points of failure, unpredictable performance,
management issues with servers from different organizations.
27 | P a g e

Q1. What is Pipe and Filter Architecture?

A1.
Pipe and filter architecture involves organizing the system so that each
component (filter) processes data, transforming it, and passing it to the
next component (pipe). The data flows sequentially from one filter to
another.

Q2. What are the Advantages and Disadvantages of Pipe and

Filter Architecture?
A2.
Advantages:

 Easy to understand.
 Supports transformation reuse.
 Matches the structure of many business processes.
 Evolution by adding transformations is straightforward.
 Can be implemented sequentially or concurrently.

Disadvantages:

 Data transfer format must be agreed upon between components,

adding overhead.
 Each transformation must parse and unparse data, reducing reuse
potential.
28 | P a g e

Q1. What are Application Architectures?

A1.
Application architectures are designed to meet specific organizational
needs. They represent common structures used in many businesses due
to their shared requirements, making them suitable for adaptation in
different contexts. These architectures act as templates that can be
configured and adjusted to create systems for particular requirements.

Q2. What is the Use of Application Architectures?

A2.

 Starting Point for Design: They provide a base for architectural

design.
 Design Checklist: Used as a guideline to ensure key architectural
elements are included.
 Work Organization: Helps organize development tasks and team
roles.
 Component Reuse: Assists in evaluating reusable components.
 Vocabulary: Serves as a common language for discussing different
types of applications.

Q3. What are Some Examples of Application Types?

A3.
29 | P a g e

1. Data Processing Applications: These are batch-oriented systems

that process data without user intervention.
2. Transaction Processing Applications: These handle user
requests and update a central database (e.g., online transactions).
3. Event Processing Systems: These systems react to events from
the environment (e.g., sensor systems).
4. Language Processing Systems: These process user inputs
specified in a formal language (e.g., compilers or command
interpreters).

Q4. Examples of Generic Application Architectures

A4.

 Transaction Processing Systems: Used in e-commerce or

reservation systems, where user transactions are processed and
stored in a database.
 Language Processing Systems: Includes systems like compilers
or command-line interpreters that process formal user input.

Q1. What are Transaction Processing Systems (TPS)?

A1.
Transaction Processing Systems (TPS) are designed to handle user
requests for information from a database or requests to update a
database. They ensure that transactions (sets of operations) are
processed correctly and reliably, maintaining the integrity of the data.

Q2. What is a Transaction from the User's Perspective?

A2.
From the user's perspective, a transaction is defined as:

 A coherent sequence of operations that collectively satisfy a

goal.
 For example, finding the flight times for a specific route (e.g.,
London to Paris) could be considered a transaction, as it involves a
series of steps that fetch information based on the user's request.
30 | P a g e

Q1. What is the Architecture of Information Systems?

A1.
Information systems generally follow a layered architecture. This
approach organizes the system into distinct layers that handle different
aspects of the system's operation. The interactions with these systems
typically involve database transactions, as most actions performed are
related to retrieving, updating, or managing data.
Layers include:
The user interface
User communications
Information retrieval
System database
31 | P a g e

What is the purpose of a language processing system, and how does it

typically work?

Answer:

Language processing systems interpret natural or artificial languages,

converting input into another form. They often include interpreters to act
on instructions, simplifying tasks by describing algorithms or system data,
and can generate tools via meta-case tools.

Compiler components
A lexical analyzer, which takes input language tokens and converts them
to an internal form.
A symbol table, which holds information about the names of entities
(variables, class names, object names, etc.) used in the text that is being
translated.
A syntax analyzer, which checks the syntax of the language being
translated.
A syntax tree, which is an internal structure representing the program
being compiled.
A semantic analyzer that uses information from the syntax tree and the
symbol table to check the semantic correctness of the input language
text.
A code generator that ‘walks’ the syntax tree and generates abstract
machine code.
Security Engineering Overview
32 | P a g e

 Focuses on tools, techniques, and methods to develop and maintain

systems that resist malicious attacks.
 A sub-field of computer security.

⚖️Security Dimensions

1. Confidentiality – Preventing unauthorized access to information.

2. Integrity – Ensuring data is not corrupted or tampered with.
3. Availability – Ensuring systems and data are accessible when
needed.

🧱 Security Levels

 Infrastructure Security: Securing system/network infrastructure.

 Application Security: Securing specific software applications.
 Operational Security: Ensuring users and operations do not
compromise security.

🔒 System Security Management

 User & Permission Management

 Software Deployment & Maintenance
 Attack Monitoring, Detection & Recovery

👥 Operational Security

 Human/social issue: preventing insecure user behavior.

 Trade-off exists between security and system usability.

🔐 Security as a System Property

 Protects systems from accidental/deliberate attacks.

 Essential for availability, reliability, and safety.

⚠️If Security Fails…

 Reliability and safety assurances become invalid.

33 | P a g e

 Intrusions change the executing system or its data.

📚 Security Terminology

Term Definition
Asset Valuable item to protect (e.g., data, system).
Attack Exploiting a vulnerability to cause damage.
Measures to reduce vulnerabilities (e.g.,
Control
encryption).
Exposure Harm/loss due to security breach.
Potential cause of harm (e.g., guessed
Threat
passwords).
Vulnerabil
Weakness that could be exploited.
ity

⚔️Types of Threats

1. Interception – Unauthorized access (e.g., viewing patient records).

2. Interruption – Denial of service or system unavailability.
3. Modification – Unauthorized data alteration.
4. Fabrication – Insertion of false data (e.g., fake transactions).

Security Assurance Techniques

 Vulnerability Avoidance: Prevent vulnerabilities in design.

 Attack Detection and Elimination: Use tools like antivirus
software.
 Exposure Limitation & Recovery: Mitigate damage with backups,
etc.

🧩 Security and Dependability

 Reliability: Compromised if attacks corrupt data/systems.

 Availability: Denial of service affects system uptime.
 Safety: Attack may invalidate assumptions critical to safety.

Security Specification vs. Safety Specification

Aspect Safety Specification Security Specification

Nature Accidental problems Intentional attacks
Analysis Root cause analysis is Attackers conceal failures
34 | P a g e

Aspect Safety Specification Security Specification

feasible
Shutdow
May prevent failure May be goal of attacker
n
Intelligent, persistent
Threats No intelligent adversary
adversary

📋 Types of Security Requirements

1. Identification – Who is requesting access?

2. Authentication – Is the user really who they say they are?
3. Authorization – What is the user allowed to do?
4. Immunity – Protection from threats like viruses.
5. Integrity – Ensure data is not tampered with.
6. Intrusion Detection – Detect unauthorized access.
7. Non-repudiation – Prevent denial of actions by users.
8. Privacy – Protect personal data.
9. Security Auditing – Record and review system activity.
10. System Maintenance Security – Ensure maintenance does
not compromise security.

📊 Classification of Security Requirements

Type Purpose
Risk Design to eliminate risks
Avoidance altogether
Risk Detect risks and prevent
Detection damage
Risk Minimize damage and enable
Mitigation recovery

⚠️Security Risk Assessment Process

1. Asset Identification – What needs protection?

2. Asset Value Assessment – How valuable is it?
3. Exposure Assessment – What’s the potential loss?
4. Threat Identification – What could go wrong?
5. Attack Assessment – How could threats be executed?
6. Control Identification – What security measures help?
7. Feasibility Assessment – Are controls practical and affordable?
8. Requirements Definition – Specify infrastructure/app-level
security needs.
35 | P a g e

🩺 Mentcare System: Example

Asset Analysis

Asset Value Exposure

Information High – includes safety-critical
High
System functions
Patient Database High High – critical for treatments
Individual Usually Low – may hurt reputation if
Record low leaked

Threat and Control Analysis

Probabili
Threat Control Feasibility
ty
Restrict
Unauthorized
Low management Low cost
admin access
access
Unauthorized user Biometric + Feasible but high cost,
High
access Logging may face resistance

Defined Security Requirements

 Download patient data to secure area only.

 Data must be encrypted on the client.
 Upload and delete data after session ends.
 Log changes on separate machine.

❗ Misuse Cases

Type Description
Intercepti Attacker gains access to
on data
Interrupti
Attacker disables system
on
Modificati Data is altered
on maliciously
Fabricatio
Fake data is injected
n

Example – Intercept Transfer in Mentcare:

 Attack: Network monitor or spoofed server

 Mitigations:
o Keep networking gear in locked rooms
o Encrypt all client-server data
36 | P a g e

o Use certificate-based SSL (https)

Secure System Design Best Practices

 Incorporate security early in system design.

 Architectural decisions affect security (e.g., isolation, layering).
 Follow good practices:
o Principle of least privilege
o Defense in depth
o Fail securely

Security Specification vs. Safety Requirements

 Commonality: Both aim to prevent undesirable outcomes.

 Key Differences:
1. Security must anticipate hostile threats; safety does not.
2. Security failures can be hidden by attackers; safety failures
are typically detectable.
3. Shutting down can prevent safety failures; in security, that
may be the attack goal.
4. Attackers are intelligent and adaptive; safety threats are
accidental.

Types of Security Requirements

 Identification: Recognizing users.

 Authentication: Verifying user identity.
 Authorization: Granting user permissions.
 Immunity: Protecting against certain threats.
 Integrity: Ensuring data is not tampered with.
 Intrusion Detection: Monitoring unauthorized access.
 Non-repudiation: Preventing denial of actions.
 Privacy: Ensuring confidentiality.
 Security Auditing: Logging and reviewing actions.
 System Maintenance Security: Protecting during maintenance.

📊 Classification of Security Requirements

 Risk Avoidance: Design system to prevent risks.

 Risk Detection: Identify and neutralize emerging risks.
 Risk Mitigation: Recover from loss, restore assets.
37 | P a g e

🔍 Security Risk Assessment Process

1. Asset Identification: What needs protection?

2. Asset Value Assessment: How valuable is each asset?
3. Exposure Assessment: What is the loss if compromised?
4. Threat Identification: What could go wrong?
5. Attack Assessment: How could attacks occur?
6. Control Identification: What countermeasures exist?
7. Feasibility Assessment: Cost and practicality of controls.
8. Requirements Definition: Finalize security specifications.

⚠️Misuse Cases

 Interception: Unauthorized access (e.g., packet sniffing).

 Interruption: System made unavailable.
 Modification: Data altered.
 Fabrication: False data injected.

💻 Secure Systems Programming

 Language Matters: Java has built-in bounds checks; C/C++ don't.

 Reliability = Security: Reliable code avoids security holes.

✅ Dependable Programming Guidelines

1. Limit data visibility.

2. Validate all inputs.
3. Handle all exceptions.
4. Avoid error-prone constructs.
5. Allow restarts.
6. Check array bounds.
7. Use timeouts.
8. Name real-world constants.

🧪 Security Testing & Assurance

 Challenge: Security is about preventing what should not happen.

 Approaches:
o Experience-based testing
o Penetration testing
o Tool-based analysis
o Formal verification
38 | P a g e

✅ Security Checklist Samples

 Are file permissions correct?

 Do sessions auto-expire?
 Are passwords strong?
 Are input validations present?
 Is buffer overflow checked?

📌 Key Takeaways

 Security threats affect Confidentiality, Integrity, and

Availability (CIA)
 Architecture and design should protect and isolate key assets.
 Attackers are smart and persistent—systems must be designed
accordingly.
 Security validation is inherently complex due to the nature of
threats.