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.

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

3|Page

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.
12 | P a g e

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

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:

13 | P a g e

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

• Tight integration of the system with core business processes.
• 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?
14 | P a g e

Answer:

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?
15 | P a g e

Answer: Factors include:

• 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.
16 | P a g e

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

• 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.

Q4. What is the Layered Architecture Pattern?

A4.
24 | P a g e

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.

Q1. What is the Repository Architecture?

25 | P a g e

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

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.
26 | P a g e

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.

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:
27 | P a g e

• 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.

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.
28 | P a g e

• 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.

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.
29 | 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
30 | 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.
31 | P a g e

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

• 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
32 | P a g e

• 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.

• 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.
Control Measures to reduce vulnerabilities (e.g., encryption).
Exposure Harm/loss due to security breach.
Threat Potential cause of harm (e.g., guessed passwords).
Vulnerability Weakness that could be exploited.
33 | P a g e

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 feasible Attackers conceal failures
Shutdown May prevent failure May be goal of attacker
Threats No intelligent adversary Intelligent, persistent 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.
34 | P a g e

10. System Maintenance Security – Ensure maintenance does not compromise

security.

Classification of Security Requirements

Type Purpose
Risk Avoidance Design to eliminate risks altogether
Risk Detection Detect risks and prevent damage
Risk Mitigation Minimize damage and enable 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.

Mentcare System: Example

Asset Analysis

Asset Value Exposure

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

Threat and Control Analysis

Threat Probability Control Feasibility

Unauthorized admin Restrict management
Low Low cost
access access
Unauthorized user Feasible but high cost, may
High Biometric + Logging
access face resistance

Defined Security Requirements

35 | P a g e

• 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
Interception Attacker gains access to data
Interruption Attacker disables system
Modification Data is altered maliciously
Fabrication Fake data is injected

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
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.
36 | P a g e

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.

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

37 | P a g e

• 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

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.
38 | P a g e