Software Engineering Ethics

✽​ Introduction
○​ Like other engineering disciplines, software engineering is carried out
within a social and legal framework that limits the freedom of people
working in that area.

○​ As a software engineer, you must acknowledge that your role involves

broader responsibilities beyond technical skills.

○​ You are expected to behave ethically and morally to be respected as

a professional engineer.

○​ This includes upholding honesty and integrity and avoiding actions

that could bring disrepute to the profession. Some areas of ethical
behaviour, not always governed by laws, include:

✽​ Ethics
○​ Confidentiality: Whether or whether a formal confidentiality
agreement has been negotiated, you should typically protect the
confidentiality of your clients or employers.

○​ Competence: It is improper for you to misrepresent your degree of

expertise. Knowingly taking on tasks beyond your area of expertise is
not something you should do.

○​ Rights related to intellectual property: You should be aware of the local

laws that control the use of rights related to intellectual property,
including copyright and patents. It's important to take precautions to
safeguard employers' and clients' intellectual property

○​ Misuse of computers: You shouldn't abuse other people's computers

by using your technological expertise. The abuse of computers may
be anything from very minor (playing games on the work computer)
to very dangerous (distributing viruses or other malware).
 Week 2

Software Processes
Chapter 2

Software prototyping

✽​ Introduction
○​ A prototype is an early, simplified version of a software system, built to
demonstrate concepts, test functionality, and gather user feedback
before full-scale development.

○​ A software prototype can be used in a software development process

to help anticipate changes that may be required.

○​ In the requirements engineering process, a prototype can help with

the elicitation and validation of system requirements.

○​ In the system design process, a prototype can be used to explore

software solutions and in the development of a user interface for the
system.

✽​ Types of Prototypes
○​ Throwaway/Rapid Prototyping: Used for requirements elicitation, then
discarded.

○​ Evolutionary Prototyping: Built to evolve into the final system through

iterative refinements.

✽​ Benefits of Prototypes
○​ Improved systems usability.

○​ A closer match to the user's real needs.

○​ Improved design quality.

○​ Improved maintainability

○​ Reduced development effort.

✽​ Limitations
○​ Lack of Robustness: Prototypes are often built quickly to demonstrate
feasibility and may lack robustness.

○​ Insufficient Testing: Prototypes are typically tested minimally,

focusing on core functionality rather than comprehensive testing.

○​ Lack of Documentation: Prototypes often have minimal

documentation, making it difficult for new developers to understand
and maintain the system.
✽​ System Engineering Principles for Software Development
○​ Interdisciplinary Approach: Integrating different engineering
disciplines to ensure all aspects of a system's lifecycle are
considered, from conception through design, implementation, and
maintenance.

○​ Requirement Engineering: Eliciting, analyzing, specifying, and

validating the needs and constraints of stakeholders to ensure the
system meets its intended purpose.

○​ System Architecture Design: Creating a high-level structure of the

system that defines its components and their interactions, ensuring
scalability, performance, and security.

○​ Integration and Testing: Systematically integrating system

components and rigorously testing them to detect and correct issues
early in the development process.

○​ Lifecycle Management: Managing the system throughout its lifecycle,

including planning, development, deployment, operation,
maintenance, and decommissioning, ensuring continuous
improvement and adaptation to changing requirements and
technologies.

Week 2

Agile Software Development

Lesson #

Header 2

✽​ Introduction
○​ Essential for businesses to quickly develop and deploy new software to
respond to competitive pressures and new opportunities.

○​ Agile development is a methodology aimed at producing useful

software quickly and efficiently.

○​ Plan-driven software development processes that completely specify

the requirements and then design, build, and test a system are not
geared to rapid software development.

○​ the requirements change or as requirements problems are

discovered.
 ○​ A conventional waterfall or specification-based process is usually a
lengthy one, and the final software is delivered to the customer long
after it was originally specified.

✽​ Principles of Agile Methods / Development Techniques

○​ Customer Involvement: Continuous engagement of the customer to
provide and prioritise requirements and evaluate iterations.

○​ Embrace Change: Design systems to accommodate changing

requirements.

○​ Incremental Delivery: Develop software in small, functional increments.

○​ Maintain Simplicity: Focus on simplicity in both software and

development processes.

○​ People Over Process: Prioritise the skills and collaboration of the

development team over rigid processes.

✽​ Agile Development Techniques:

○​ User Stories: Scenarios describing system use from the user’s
perspective. Used to plan iterations and identify tasks. Allow for
incremental development and refinement based on user feedback.

○​ Refactoring: Continuous improvement of the codebase to enhance

readability and maintainability. Helps avoid code degradation and
supports easier implementation of changes.

○​ Test-first development: requires task implementers to understand the

specification thoroughly to write system tests, clarifying ambiguities
and omissions. This avoids "test-lag" where developers work faster
than testers, leading to skipped tests to maintain the development
schedule.

○​ In XP, programmers work in pairs to develop software. Pair

programming supports collective ownership, acts as an informal
review process, and encourages refactoring to improve software
structure. It's dynamically created, allowing all team members to
work together during the development process.

✽​ Scrum
○​ Scrum is an agile method that provides a framework for organising
agile projects. It is centred around a set of sprints, which are fixed
time periods when a system increment is developed.

○​ Scrum is an agile framework used for developing, delivering, and

sustaining complex products. Emphasises teamwork, accountability,
and iterative progress towards a well-defined goal.

○​ Planning is based on prioritising a backlog of work and selecting the

highest priority tasks for a sprint.
 ○​ A Sprint is a fundamental time-boxed event in the Scrum framework,
typically lasting 1-4 weeks, during which a specific set of work is
completed and made ready for review.

✽​ Benefits of Scrum:
○​ Product broken into manageable chunks.

○​ Unstable requirements don't hold up progress.

○​ Improved team communication and morale

○​ Customers see on-time delivery of increments.

○​ Trust established between customers and developers.

Requirements engineering

✽​ Introduction
○​ Requirements: Descriptions of services a system should provide and
constraints on its operation.

○​ These specifications are a reflection of what users need from a system

to do specific tasks, such ordering, locating information, or using a
gadget.

○​ Requirements Engineering (RE): The process of finding, analysing,

documenting, and checking these services and constraints.

○​ Requirements engineering aims to ensure that the system being

developed meets the needs of its users and stakeholders, while also
being feasible to implement within the given constraints.

○​ Types of Requirements: User Requirements: High-level abstract

statements in natural language and diagrams detailing what services
the system should provide and constraints on its operation.

System Requirements: Detailed descriptions of software system

functions, services, and operational constraints. These are often part
of a contract between the system buyer and developers.

✽​ Functional vs. Non-Functional Requirements:

○​ Functional Requirements: Statements of services the system should
provide, how it should react to inputs, and behaviour in specific
situations.

○​ Functional requirements: What the system should do

○​ Non-Functional Requirements: Constraints on the system's services or

functions, such as performance, reliability, and usability.

○​ Non-functional requirements: Constraints on the system's

services/functions (e.g. performance, security). Non-functional
 requirements are often more critical than individual functional
requirements

○​ Stakeholders: Include users, managers, developers, and external

entities such as regulators. They have varying needs and interests in
the system, influencing requirements documentation.

✽​ Requirements engineering processes

○​ Requirements Engineering Processes involve a set of activities to
systematically gather, document, and manage system requirements.
These processes ensure that the system meets the needs and
expectations of stakeholders. The main activities in requirements
engineering processes include:

○​ Requirements Elicitation: Gathering requirements from stakeholders

through various techniques like interviews, surveys, and observations.

○​ requirements Analysis: Analysing gathered requirements to detect

conflicts, ambiguities, and inconsistencies.

✽​ Requirements elicitation
○​ Requirements Elicitation is the process of gathering information
about the desired system from stakeholders and other sources.
Effective elicitation ensures that the requirements captured are
complete and accurate.

○​ There are two fundamental approaches to requirements elicitation:

○​ Interviews, one-on-one or group interviews with stakeholders to

gather detailed information. Observation or ethnography, where you
watch people doing their job to see what artefacts they use, how they
use them, and so on.

○​ Document Analysis: Reviewing existing documentation such as

business plans, user manuals, and system documentation to gather
requirements.

✽​ Requirements Specification
○​ Requirements Specification is the process of documenting the
gathered requirements in a clear, precise, and comprehensive
manner. The main goals are to provide a detailed description of the
system to be built and to serve as a reference for system design,
development, and validation. Key aspects of requirements
specification include:

○​ Use Cases and Scenarios: Descriptions of how users will interact with
the system to achieve specific goals.

○​ State Diagrams and Flowcharts: Visual representations of the

system’s behaviour and processes.
✽​ Requirements Validation
○​ Requirements Validation ensures that the documented requirements
accurately capture the needs and expectations of stakeholders and
are feasible to implement.

○​ During the requirements validation process, different types of checks

should be carried out on the requirements in the requirements
document.

○​ These checks include: Validity checks, Consistency checks,

Completeness checks, Realism checks, Verifiability.

○​ Requirements validation techniques include requirements reviews,

prototyping, and test-case generation. Requirements are
systematically analysed by a team to identify errors and
inconsistencies. Prototyping involves developing a system model and
testing it with end-users and customers to ensure it meets their
needs.

✽​ Requirements Change
○​ Requirements Change involves managing changes to requirements
as the project progresses due to evolving stakeholder needs, market
conditions, or technical constraints.

○​ Requirements management planning involves identifying and

managing evolving requirements, assessing change impact and
cost, defining traceability policies, and utilising various tools for
processing large amounts of information. It involves unique
identification of requirements for cross-referencing, a change
management process, and maintaining traceability records. Tools
can range from specialist systems to shared spreadsheets and
simple database systems.

○​ Requirements change management is crucial for implementing new

system requirements after the requirements document is approved.
It involves three principal stages: problem analysis and specification,
change analysis and costing, and change implementation. The
process helps determine if the benefits of implementing new
requirements are justified by the costs.

System Modelling

✽​ Introduction
○​ Definition: System modelling is the process of creating abstract
models of a system, offering different perspectives or views.

○​ Purpose: Used during requirements engineering to detail system

requirements, describe the system for engineers during the design
process, and document the system post-implementation.
✽​ Activity Diagram
○​ Illustrate the flow of activities in a process, highlighting the sequence
and conditions for coordinating actions.

○​ The process diagram consists of activities, flows, start and end points,
decision points, and synchronisation bars, representing tasks, flows,
start and end points, branching points, and convergence of parallel
activities.

✽​ Object/Class Diagram
○​ Represent the static structure of a system by showing the system's
classes, their attributes, operations (methods), and the relationships
among objects.

○​ The text outlines the components of a class diagram, including

classes, relationships, inheritance, and aggregate/composition,
which are represented by rectangles, attributes, operations,
associations, inheritance, and diamonds respectively.

✽​ Sequence Diagram
○​ Purpose: Model the sequence of interactions among objects or
components in a system over time.

○​ The diagram consists of lifelines, actors/objects, messages, activities,

and guards, which represent the existence of an object over time,
communication between objects, the period of an action, and
necessary conditions for message transmission.

✽​ Use Case Diagram

○​ Purpose: Describe the functional requirements of a system by
showing the interactions between users (actors) and the system
itself.

○​ The system consists of actors, use cases, a system boundary, and

relationships, represented by stick figures and ovals respectively,
illustrating the system's scope and participation in various use cases.

Architectural design

✽​ Introduction
○​ Architectural design is the first stage in the software design process,
focusing on organising and designing the system's structure.

○​ It is a critical link between design and requirements engineering,

identifying main structural components and their relationships. In
agile processes, early architecture design is essential.

○​ Refactoring components is easy but expensive due to potential

modifications.
 ○​ System architectures are often modelled informally using simple block
diagrams.

○​ Block diagrams are used to model system architectures informally,

representing components and data/control signals. They facilitate
communication, are intuitive, and are useful for domain experts,
engineers, and managers in project planning.

○​ Block diagrams are often the only architectural description for many
projects.

✽​ Architecture design decisions

○​ Architectural design is a creative process influenced by the type of
system, the architect's background and experience, and specific
system requirements. Architects make structural decisions that
significantly affect the system and its development.

○​ Fundamental Questions: Define system purpose, constraints, structure,

decomposition, and control.

✽​ Architectural Views
○​ Architectural views are representations of the overall architecture
meaningful to one or more stakeholders in the system. The architect
chooses and develops views that enable the architecture to be
communicated to, and understood by, all stakeholders, ensuring their
concerns are addressed.

○​ Key Issues in Documenting Design:Useful Views/Perspectives:

Determine which views or perspectives are useful when designing and
documenting a system’s architecture. Notations: Decide what
notations should be used for describing architectural models.

○​ Krutchen’s Four Fundamental Architectural Views

○​ Logical View: Shows key abstractions in the system as objects or

object classes. Relates system requirements to entities in this view.
Process View: Shows how, at runtime, the system is composed of
interacting processes. Useful for assessing non-functional
characteristics like performance and availability.

○​ Development View: Shows the decomposition of software for

development. Useful for software managers and programmers to see
the breakdown of software into components. Physical View: Shows the
system hardware and the distribution of software components across
processors. Useful for systems engineers planning a system
deployment.

✽​ Chapter 7
✽​ Open-source development
○​ Open-source development involves publishing the source code and
inviting volunteers to contribute. Open-source development involves
 making the source code of a system publicly available. This means
that many people can propose changes and improvements to the
software.

○​ Roots: The Free Software Foundation (FSF) promotes the idea that
source code should be freely available for users to examine and
modify.

○​ Open Source Development : Core Group: Initially controlled by a small

core group; expanded to a larger volunteer population through the
Internet.

○​ Volunteer Contributions: Volunteers can report/fix bugs and propose

new features, but core developers often control changes.

✽​ Benefits of Open Source

○​ Cost: Often free to download; documentation/support may incur low
costs.

○​ Reliability: Large user base leads to quicker bug fixes.

○​ Use of Open-Source Components: Beneficial for reducing time to

market and costs.May not be suitable if software needs to integrate
with incompatible existing systems.

○​ Community Involvement Challenges: Publishing source code does

not guarantee community help. Success Factors: Successful projects
are often platforms, not specialised systems.

✽​ Open-Source Licensing
○​ Ownership: The developer owns the code and can impose usage
restrictions through licences.

○​ Common Licences: GNU General Public License (GPL): Reciprocal;

requires derived works to be open source. GNU Lesser General Public
License (LGPL): Allows linking without publishing source, but changes
to the licensed component must be open source. Berkeley Standard
Distribution (BSD) Licence: Non-reciprocal; changes need not be
published but original creators must be acknowledged.

○​ Licensing Issues; Obligations: Using GPL-licensed software may

require making your product open source. Compliance: Maintain
records of licenses.Understand and track licence conditions and
component evolution.

○​ Educate developers and have auditing systems.

○​ Business Models Open-Source Model: Release source code and

monetize through services and advice. Cloud-Based Services: Selling
cloud services and specialised versions of open-source systems.
 ○​ Explain why, in these circumstances, it might be a good idea for the
company owning the software to make it open source.
○​ One of the main advantages of open source software is that it allows
a greater number of developers to work on projects, which speeds up
the process of developing and debugging products.

○​ Open source might raise consumer awareness of the business's

offering and draw in additional clients.

○​ When code is integrated into a larger system, problems may

surface. Explain how configuration management can be useful
when handling such problems.

○​ Configuration Management (CM): A systematic process of handling

changes to a system in a way that it maintains its integrity over time.
It involves the management of software, hardware, and other system
components to ensure consistency and traceability throughout the
system’s lifecycle.

Chapter: 8 Software Testing

✽​ Introduction
○​ Testing aims to demonstrate that a program works as intended and to
discover defects before use. Involves executing the program with
artificial data and checking results.

○​ Goals of Testing: Validation Testing: Demonstrates that the software

meets requirements. Defect Testing: Identifies defects by finding
inputs that cause incorrect or undesirable behaviour.

○​ Two main goals:Demonstrate the software meets requirementsFind

inputs that cause incorrect or undesirable behaviour (defects).Testing
cannot prove a program is defect-free, only show presence of errors.
Part of broader verification and validation process

✽​ Development Testing
○​ Development testing includes all testing activities that are carried out
by the team developing the system. Carried out by development team
during implementation.

○​ Stages of Development Testing:

Unit testing - testing individual components/methods. Requires tests that

cover all features and states of an object. Use of state models to identify and
test state transitions.

Component testing - testing integrated components

System testing - testing the whole integrated system

 ○​ Development testing is primarily a defect testing process, where the
aim of testing is to discover bugs in the software.

○​ It is therefore usually interleaved with debugging—the process of

locating problems with the code and changing the program to fix
these problems.

✽​ Test-Driven Development (TDD)

○​ Interleaves testing and code development. Test-driven development
(TDD) is a program development approach that integrates testing
and code development, developing code incrementally and testing
each increment before moving on to the next.

○​ TDD Process: Write a test for a new function. Run the test and see it
fail. Write the minimum code to pass the test. Refactor the code while
ensuring tests still pass.

○​ Benefits of TDD: Ensures code is thoroughly tested. Encourages better

design and code quality. Provides a safety net for future code
changes.

○​ Regression testing: As a software is built, a test suite is gradually

created. Regression tests are a useful tool for ensuring that software
modifications have not resulted in the introduction of new issues. The
fact that doing regression at a lower cost is another significant
benefit.

✽​ Release Testing
○​ The process of testing a specific system release that is meant for
usage by users other than the development team is known as release
testing. Testing a specific release for use outside development team

○​ The primary goal of the release testing process is to convince the

supplier of the system that it is good enough for use.

○​ Requirements-based testing is validation rather than defect testing —

you are trying to demonstrate that the system has properly
implemented its requirements.

○​ Scenario testing is an approach to release testing whereby you devise

typical scenarios of use and use these scenarios to develop test cases
for the system.

○​ Performance testing is a crucial process after integrating a system to

ensure it can handle its intended load, progressively increasing the
load until it becomes unacceptable.

✽​ User Testing
○​ User testing is a crucial stage in system testing where users provide
input and advice, either formally testing a commissioned system or
experimenting with a new software product. It influences system
 reliability, performance, usability, and robustness, even after
comprehensive system and release testing.

○​ Types of User Testing: Alpha Testing: Performed by internal staff

before release. Beta Testing: Conducted by actual users in their
environment. Acceptance Testing: A formal type of user testing.
Customer decides if the system meets their requirements and should
be accepted.

○​ Acceptance testing : involves six stages: defining criteria, planning,

running tests, negotiating results, and rejecting/accepting the
system, conducted early in the process, requiring approval from both
customers and developers.

Software Evolution

✽​ Introduction
○​ The introduction discusses the high cost of maintaining large software
systems. These systems often have a long lifetime, and businesses
need to invest in changes to maintain their value.

○​ The cost of software evolution is especially high in enterprise systems

that are part of a broader system of systems. When one system
changes, other systems may also need to change to accommodate
the new version.

○​ There's no one-size-fits-all approach to software evolution.

○​ Software type: Informal for mobile apps (user-developer

conversations), formal with documented stages for critical systems.

○​ Development process: Aligns with the established development

methods within the organization.Team skills: Matches the skillset of the
team responsible for maintenance.

○​ Add your notes here

○​ Add your notes here

✽​ Legacy systems
○​ Older software systems that continue to be used due to their critical
role in business operations. These systems often rely on outdated
technologies and hardware.
 ○​ Characteristics: Dependence on outdated languages and hardware.
Degraded structure due to continuous maintenance. Inclusion of
hardware, software, data, business processes, and policies.

○​ Components of Legacy Systems: System Hardware: Often obsolete

and expensive to maintain. Support Software: Outdated operating
systems and utilities. Application Software: Composed of various
programs developed over time. Application Data: Large volumes of
possibly inconsistent and duplicated data. Business Processes:
Defined around legacy systems. Business Policies and Rules:
Embedded in the software.

○​ Challenges: High maintenance costs. Security vulnerabilities.

Integration difficulties with modern systems. Shortage of skilled
programmers for older languages.

○​ Modern software engineering processes like agile development allow

for the integration of system development and evolution, reducing
costs and improving overall software system life-cycle.

○​ Management Strategies: Scrap: Discard the system if it no longer

supports business processes. Maintain: Continue regular maintenance
if the system is stable. Reengineer: Improve maintainability if the
system quality is degraded. Replace: Develop a new system if the
legacy system is untenable.

✽​ Software maintenance
○​ Definition: Process of modifying a system after delivery to fix faults,
improve performance, or adapt to a changed environment. Modifying
a software system after it has been delivered.

○​ Types of Maintenance: Corrective Maintenance: Fixing bugs. Adaptive

Maintenance: Adjusting the system to changes in the environment.
Perfective Maintenance: Enhancing the system with new features.
Preventive Maintenance: Improving system reliability to prevent
future issues.

○​ Challenges: Understanding the existing system. Managing the

complexity of changes. Ensuring that changes do not introduce new
errors.

○​ Strategies: Impact Analysis: Assessing the effects of changes.

Regression Testing: Ensuring new changes do not affect existing
functionalities. Documentation: Maintaining updated and
comprehensive documentation.
 Dependable processes

✽​ Introduction
○​ Dependable software processes are designed to ensure that the
resulting software is reliable, consistent, and less prone to failure.

○​ Investing in dependable processes is crucial because they help

minimise errors in the delivered software, enhancing its overall
reliability.

○​ Add your notes here

○​ Add your notes here

○​ Add your notes here

○​ Add your notes here

○​ Add your notes here

✽​ Attributes of Dependable Software Processes

○​ Auditable: The process should be clear and understandable to
external reviewers who can verify adherence to standards and
suggest improvements. Diverse: It should incorporate redundant and
diverse verification and validation activities to catch more errors.
Documentable: There should be a defined process model that outlines
all activities and the necessary documentation. Robust: The process
should be able to recover from failures in individual activities.
Standardised: A comprehensive set of development standards should
be in place.

✽​ Activities in Dependable Processes

○​ Requirements Reviews: Ensure that requirements are complete and
consistent. Requirements Management: Control changes to
requirements and understand their impact. Formal Specification:
Create and analyze a mathematical model of the software to
uncover requirements issues.

○​ System Modeling: Document software design with graphical models

and establish links between requirements and models. Design and
Program Inspections: Inspect different system descriptions to find
errors. Static Analysis: Use automated tools to check the source code
for anomalies.

○​ Test Planning and Management: Design a comprehensive set of

system tests to ensure requirements coverage and proper
application.

○​ Suggest six reasons why software dependability is important in

most sociotechnical systems. ?
 ○​ Users may not use the system if they don't trust it. System failure may
lead to a loss of business. An undependable system may lose or
damage valuable data. An undependable system may damage its
external environment. The reputation of the company who produced
the system may be damaged, hence affecting other systems. The
system may be in breach of laws on consumer protection and the
fitness of goods for purpose.

Safety Engineering

✽​ Introduction
○​ Formal methods involve mathematically-based techniques for
specifying and verifying systems. These methods are essential in
safety-critical systems, such as those used in aerospace and railway
control, to ensure reliability and adherence to specifications​

○​ Safety engineering processes are based on reliability engineering

processes. Regulators may require evidence that safety engineering
processes have been used in system development.

✽​ System Engineering Principles for Software Development

○​ Formal Specification and Analysis: Developing a formal specification
of the system and mathematically analyzing it for inconsistency. This
helps discover specification errors and omissions.

○​ Formal Verification: Using mathematical arguments to formally verify

that the code of a software system is consistent with its specification.
This is effective in discovering programming and some design errors.

○​ Model Checking: Constructing or generating a formal state model of a

system and using a model-checker to ensure properties of the model,
such as safety properties, always hold. This method helps identify
undesirable states, like deadlock in concurrent systems.

○​ Refinement-based Development: Refining a formal specification

through a series of correctness-preserving transformations to
generate software, ensuring the software is consistent with its
specification.

○​ Transformational Development: Systematically transforming a formal

specification through a series of representations to program code,
supported by software tools to verify consistency across
representations.
 Software Engineering Architecture
Chapter 13

Security Engineering

✽​ Introduction
○​ The Internet introduced a new challenge of designing secure systems
resistant to external attacks.

○​ Security breaches can result in data theft, hardware misuse, or

service disruption.

○​ Need to consider 3 security dimensions: confidentiality, integrity,

availability. Security must be considered at infrastructure,
application, and operational levels.

○​ Confidentiality: Unauthorized access to information (e.g., credit card

data theft). Integrity: Information damage or corruption (e.g., data
deletion by a worm). Availability: Inaccessibility of systems or data
(e.g., denial-of-service attacks).

○​ Infrastructure Security: Secures all systems and networks providing

organizational infrastructure. Application Security: Secures individual
or related groups of application systems. Operational Security:
Ensures secure system usage and operation by individuals.

○​ Key Security Management Activities: User and Permission

Management: Handling user authentication and resource access
permissions. System Software Deployment and Maintenance:
Installing and updating system software to avoid vulnerabilities.
Attack Monitoring, Detection, and Recovery: Monitoring systems,
detecting attacks, and organizing recovery strategies.

○​ Operational Security: Focuses on user behavior to avoid security

compromises. Users should be made aware of security issues and
practices to balance security and efficiency.

✽​ Security and Dependability

○​ Security measures protect systems from internal and external
malicious attacks. The highest security is often achieved by
disconnecting from the Internet, though this is impractical for most
systems. Especially for military, e-commerce, and confidential data
systems.
 ○​ Security terminology: Assets = valuable items (e.g., patient records).
Attack: Malicious actions (e.g., impersonation). Control: Measures to
prevent attacks (e.g., password checks). Exposure: Potential losses
from security breaches (e.g., financial loss). Threat: Possible attacks
(e.g., unauthorized access). Vulnerability: Weaknesses in the system
(e.g., weak password policies).

○​ Security threats: Interception: Unauthorized access to information.

Interruption: Making systems unavailable (e.g., denial-of-service
attacks). Modification: Tampering with system assets. Fabrication:
Inserting false information into systems.

○​ Security controls: Avoidance: Preventing successful attacks through

design (e.g., encryption). Attack Detection and Neutralization:
Detecting and repelling attacks (e.g., monitoring system activities).
Exposure Limitation and Recovery: Supporting recovery from attacks
(e.g., backups and mirroring).

○​ Security and Other Dependability Attributes:

1 Reliability: Attacks can cause system failures.

2 availability:Denial-of-service attacks impact availability.

3 Safety: Corrupted systems can induce safety-related

failures.

4 Resilience: Ability to resist and recover from attacks.

✽​ Security and Organizations

○​ Cost and Risk Management: Security is expensive and predicting
costs of failures is challenging. Companies often assess the risk and
decide on the balance between security measures and accepting
risks.

○​ Security Policy: Asset Protection: Identify and prioritize assets for

protection. Protection Levels: Determine appropriate security levels
for different assets.User Responsibilities: Define user expectations
and responsibilities. Existing Procedures: Maintain practical existing
security procedures despite known limitations.

○​ Security Risk Assessment: Preliminary Risk Assessment: Identifies

high-level risks early in the development. Design Risk Assessment:
Considers risks during the design and implementation stages.
Operational Risk Assessment: Focuses on risks during system use
and adapts to changing conditions and requirements.

✽​ Security Requirements
○​ Challenges in Specifying Security Requirements: Security
requirements must consider hostile environments and intelligent
 adversaries. Unlike safety, security requirements cannot be specified
as probabilities and often involve extensive considerations.

○​ Must cover a wide range of potential threats and outline necessary

protective measures.10 types: identification, authentication,
authorization, immunity, integrity, intrusion detection,
non-repudiation, privacy, auditing, maintenance.

○​ Secure Systems Design: Consider protection mechanisms and

distribution of assets. Defense in depth - use multiple security
mechanisms. Fail securely - no reduced security after failures.
Balance security vs usability. Design guidelines: explicit policy,
redundancy, input validation, compartmentalization, deployment,
recoverability

○​ Security Testing: *Difficult due to "shall not" requirements and

intelligent attackers. *Experience-based testing against known
attacks. *Penetration testing simulating real attacks. *Tool-based
analysis (password checkers, static analysis). *Formal verification of
security properties.

✽​ Class notes
○​ Risk assessment process to identify security requirements.

○​ Misuse cases can model security threats alongside use case.

Week 2

Software Engineering Architecture

Chapter 14

Resilience Engineering

✽​ Introduction
○​ Resilience is the ability of a system to maintain critical services in the
presence of disruptive events like failures or cyberattacks

○​ Apollo 13 Case Study: Illustrates resilience when the spacecraft crew

and ground staff adapted to a catastrophic failure.

○​ Embeds critical services, disruptive events, and expert judgment for

assessment.

○​ Importance: Increasing cyberattacks make resilience vital for system

dependability.
 ○​ Reliability aims to avoid failures. Vs Resilience accepts failures will
happen and focuses on limiting their impact and recovering from
them.

○​ Resilience activities involve: recognition, resistance, recovery and

reinstatement of system capabilities after an adverse event.

○​ Recognition: Detect symptoms of potential failures before they occur.

Resistance: Invoke strategies to reduce the likelihood of failure upon
detection of problems or attacks.

○​ Recovery: Restore critical services quickly post-failure.

Reinstatement: Fully restore all system services to normal operation.

✽​ Cybersecurity
○​ Cybersecurity is crucial for system resilience against cyberattacks.
Significance: Protecting IT infrastructure from cyber threats is crucial
due to its societal impact.

○​ Must protect confidentiality, integrity and availability of assets. Threat

Types: Confidentiality: Unauthorized access to data. Integrity:
Damage or alteration of data/systems. Availability: Denial of access
to authorized users.

○​ Controls: Authentication, Encryption, Firewalls. Layered protection

system with redundancy and diversity.

○​ Planning for Cyber-Resilience : Asset Classification: Identify and

categorize hardware, software, and human assets.

○​ Threat Identification: Recognize potential threats to each asset.

Threat Recognition: Identify mechanisms to detect attacks. Threat
Resistance: Develop strategies to resist attacks.

○​ Asset Recovery: Define procedures for asset recovery post-attack.

Asset Reinstatement: Restore full system operations.

✽​ Sociotechnical Resilience
○​ Resilience is a sociotechnical issue involving people, processes and
technology. Example: Patient data protection in the Mentcare system
requires organizational measures beyond technical safeguards.

○​ Organizations should cultivate responding, monitoring, anticipating

and learning abilities.

○​ Human error is inevitable, use a "systems approach" with defensive

barriers.

○​ Balance operational efficiency and problem management flexibility.

○​ Flexibility in Operations: Systems should allow for emergency modes

where normal security checks are bypassed but logged for audit.
✽​ Resilient Systems Design
○​ Resilient systems are designed to resist and recover from adverse
incidents like software failures and cyberattacks. They ensure the
delivery of critical services with minimal interruptions and can quickly
return to their normal state after an incident.

○​ There key principles Assume Failures Will Occur: Design with the
expectation that system failures or penetrations by attackers will
happen. Redundancy and Diversity: Incorporate redundant and
diverse features to handle adverse events effectively.

○​ Use redundancy, diversity, maintaining system state to enable

resilience. Ongoing resilience testing against failure/attack scenarios.
Regular Testing: Test all aspects of resilience planning with failure
and attack scenarios.

Class Notes (2024/05/28)

○​ resilience of a system as a judgment of how well that system can
maintain the continuity of its critical services in the presence of
disruptive events, such as equipment failure and cyber-attacks.

○​ Figure 14.1 - which shows how a system deals with a cyberattack. The
goal is to keep the system running smoothly, even during and after
an attack, by recognizing threats early, defending against them,
repairing any damage, and fully restoring services.

Systems Engineering
Lesson #

Header 2

✽​ Introduction
○​ Software engineering is not an isolated activity but is part of a broader
systems engineering process

○​ Systems engineering includes procuring, specifying, designing,

implementing, validating, deploying and maintaining socio-technical
systems.

○​ The development of complex systems requires a comprehensive

understanding of both the technical and social components that
influence their functionality and effectiveness. Sociotechnical systems
engineering is a multidisciplinary approach that integrates technical
engineering with considerations of human, organizational, and social
factors.
 ○​ Systems engineering stages : conceptual design, Procurement or
acquisition, Development and Operation.

○​ Systems engineering involves designing entire systems, considering

hardware, software, human elements, services, constraints, and usage

✽​ Sociotechnical Systems
○​ Socio-technical systems are large-scale systems that do not just
include software and hardware but also people, processes and
organizational policies.

○​ A sociotechnical system is a purposeful collection of interrelated

components that include both technical systems and human
elements, designed to deliver services to its users.

○​ A new system may lead to changes in some or all of these elements:

process changes, job changes, organizational policies, organizational
politics.

○​ A complex system may include software, mechanical, electrical and

electronic hardware and be operated by people.

○​ Have emergent properties, are non-deterministic, and have subjective

success criteria.

○​ Emergent properties: These are properties of the whole system that

arise from component interactions. They can be: Functional: Arising
when components work together for an objective . Non-functional:
Including reliability, performance, safety, and security.

○​ Non-determinism: Unlike purely software systems, socio-technical

systems don't always produce the same output for the same input
due to: Human elements, Frequent system changes

○​ Wicked problems: These systems often address complex issues

without clear, complete specifications. Different stakeholders may
have varying perspectives on the problem and system success.

✽​ Conceptual Design
○​ The conceptual design phase is the initial stage of systems
engineering where the concept and purpose of the required system
are developed. It involves setting out in non-technical language what
the system is meant to achieve, why it is needed, and its high-level
features.

○​ Conceptual design creates a framework for an idea before

translating it into an actual design. It occurs early in the design
process, preceding specific details like color choices and illustration
styles.
 ○​ This text outlines the key activities involved in conceptual design for
systems engineering: Involves concept formulation, problem
understanding, proposal development, feasibility study.

○​ Concept formulation: Refining initial needs and determining the most

suitable system type. Problem understanding: Engaging with
stakeholders to understand their work processes, preferences, and
issues with existing systems.

○​ System proposal development: Presenting ideas for one or more

possible systems. Feasibility study: Examining comparable systems
and assessing the viability of the proposed system with current
technologies.

○​ System vision document: Documenting the conceptual design results

in a non-technical, readable format. This document should include:

○​ a) A short summary for decision-makers, covering:

○​ System Vision: Create an outline of what the system will do and how it
will function.

○​ The problem

○​ The proposed system

○​ How the system will be used

○​ Expected benefits

✽​ System Procurement
○​ The system procurement stage involves further developing the
conceptual design to make decisions about contracting for system
development. It includes deciding on the distribution of functionality
across hardware, software, and operational processes, as well as
selecting suppliers.

○​ Considers system scope, budgets, timelines, high-level requirements.

Different processes for off-the-shelf, configurable, and custom
systems.

○​ Types of systems to be procured:

○​ a) Off-the-shelf applications: Require minimal or no configuration. b)

Configurable applications or ERP systems: Require modification or
adaptation. c) Custom systems: Specially designed and
implemented.

○​ Key issues in system procurement: a) Organizational software

approval: Many organizations have pre-approved software lists,
simplifying acquisition of off-the-shelf or open-source applications.
b) Requirements matching: Off-the-shelf components rarely match
requirements exactly. Procurement involves finding the closest
 match. c) Custom system requirements: For custom-built systems,
requirements specification becomes part of the legal contract,
making the process more time-consuming.

✽​ System Development
○​ The system development stage is where the system is built. It includes
requirements definition, system design, hardware and software
engineering, system integration, and testing. Operational processes
are also defined, and user training is designed.

○​ Often follows a plan-driven "waterfall" model

○​ Key activities: Requirements engineering, architectural design,

requirements partitioning, subsystem engineering, integration, testing,
deployment

○​ Deployment can face challenges such as: Incorrect environmental

assumptions, Human resistance to the new system and Coexistence
with older systems.

○​ Operational Processes: Define how the system will be operated and

maintained.User Training: Develop training materials and courses for
system users.

✽​ System Operation and Evolution

○​ During the system operation and evolution stage, the system is
deployed, users are trained, and the system begins to be used. Over
time, the system evolves to meet new requirements, and eventually, it
is decommissioned and replaced.

○​ Deployment: The system is put into operational use. Training: Users

are trained to use the system

○​ System Evolution: The system evolves to meet new requirements and

adapt to changes. Decommissioning: Eventually, the system is
phased out and replaced.

○​ Factors that affect system lifetimes:

○​ Investment Cost: The high initial costs of systems engineering

projects necessitate long-term value delivery to justify the
investment.

○​ Loss of Expertise: Organisational changes may lead to a loss of

engineering expertise, making it difficult to specify requirements for
new systems. Replacement Cost: The high cost of replacing large
systems means that replacement can only be justified if it leads to
significant cost savings.
 Configuration management
Lesson #

Header 2

✽​ Introduction
○​ Software systems are constantly changing during development and
use. Configuration management (CM) is concerned with the policies,
processes and tools for managing changing software systems (Aiello,
and Sachs, 2011).

○​ You need CM because it is easy to lose track of what changes and

component versions have been incorporated into each system
version.

○​ CM is essential for team projects to control changes made by different

developers.

○​ Configuration management is useful for individual projects as it is

easy for one person to forget what changes have been made. It is
essential for team projects where several developers are working at
the same time on a software system.

○​

✽​ Version Management
○​ Version Control: Tracks multiple versions of system components,
ensuring changes made by different developers do not conflict.

○​ Therefore, version management can be thought of as the process of

managing codelines and baselines

○​ Codeline: A sequence of versions of a software component and

associated configuration items.

○​ Branching: Creating a new codeline from a version in an existing

codeline, allowing independent development.

○​ Version control (VC) systems identify, store and control access to the
different versions of components.

○​ There are two types of modern version control systems. centralized

and distributed systems.

○​
✽​ System Building
○​ Process: Assembling program components, data, and libraries, then
compiling and linking them to create an executable system.

○​ System building tools and version management tools must

communicate as the build process involves checking out component
versions from the repository managed by the version management
system.

○​ Continuous Integration: Regularly rebuilding and testing the system

after changes to detect bugs early.

○​ Challenges: Issues such as differences in physical filenames, target

machines, and maintaining obsolete systems for building.

○​ A system platform is the development system, which includes

development tools such as compilers, source code editors, etc
(Sommerville, 2016).

✽​ Change Management
○​ Organizational needs and requirements change during the lifetime of
a system, bugs have to be repaired and systems have to adapt to
changes in their environment.

○​ Change management is intended to ensure that system evolution is a

managed process and that priority is given to the most urgent and
cost-effective changes.

○​ The change management process is concerned with analyzing the

costs and benefits of proposed changes, approving those changes
that are worthwhile and tracking which components in the system
have been changed.

○​ Change Requests: Tracking and assessing requests for changes from

customers and developers. Cost and Impact Analysis: Evaluating the
implications of proposed changes.

○​ Implementation Decisions: Deciding if and when changes should be

made.

○​ Factors in change analysis : The benefits of the change, The number of

users affected by the change and The costs of making the change.

○​ In some agile methods, customers are directly involved in change

management.

✽​ Release Management
○​ Release Preparation: Preparing software for external release and
documenting each system version.
 ○​ A system release is a version of a software system that is distributed
to customers.

○​ For mass-market software, it is usually possible to identify two types of

release: major releases, which deliver significant new functionality,
and minor releases, which repair bugs and fix customer problems that
have been reported.

○​ Tracking Releases: Keeping track of system versions released to

customers.Customer Feedback: Managing bug reports and change
requests post-release.

○​ System releases include executable code, data files, configuration

files, and documentation. Release management involves making
decisions on system release dates, preparing all information for
distribution and documenting each system release.

○​ Factors influencing system release planning : Competition, Marketing

requirements, Platform changes and Technical quality of the system.

✽​ Notes
○​ Software Architect: A software architect is responsible for designing
the high-level structure of a software system. This role involves making
key decisions about the system's organization, selecting appropriate
technologies, and ensuring that the architecture supports the system's
requirements and quality attributes.

○​ Software Testing: Software testing is the process of evaluating a

software system to find defects and ensure it meets its requirements.
Testing can be automated or manual and includes various methods
like unit testing, integration testing, system testing, and acceptance
testing.

○​ System Architecture: System architecture defines the structure and

behaviour of a software system. It includes the decomposition of the
system into components, the interaction between components, and
the technologies used.

○​ System Maintenance: System maintenance involves modifying and

updating software after its initial deployment. It includes corrective
maintenance (fixing bugs), adaptive maintenance (adapting to
changes in the environment), and perfective maintenance (improving
performance or maintainability).
Mock Examination
✽​ However, there are fundamental principles for approaching all types of
systems. Briefly explain these fundamental methods for approaching
professional software development.?
○​ Managed Development Process: The development process has to be
comprehended and well handled. Companies should have a
well-defined development process strategy with deliverables and
timetables. This guarantees that the program is methodically built
and upholds the necessary requirement.

○​ Dependability and Performance: Software needs to be trustworthy and

effective. It should, therefore, perform without fail, be available when
needed, and operate dependably. Another crucial component is
security, which guarantees that the program is protected from outside
dangers.

○​ Specification and Requirements Management: It's critical to

comprehend and manage software needs and specifications. To
provide a functional system within budget and on schedule,
developers must manage users' and customers' expectations of the
product.

○​ Effective Use of Resources: It's critical to reuse pre-existing software

resources wherever it can. This aids in cutting expenses and
development time while preserving consistency and dependability
across various software projects.

✽​ Discuss some of the societal difficulties in developing these kinds of

systems?
○​ Privacy Concerns: Drones equipped with advanced sensors and
cameras can intrude on personal privacy. They can capture images
and videos without consent, leading to concerns about surveillance
and data misuse.

○​ Safety and Security: It's imperative to guarantee the security and

safety of drones. Drone malfunctions or hacking may result in
unintentional harm or malevolent actions. It is very difficult to ensure
drone operations over populous regions and in shared airspace with
human aircraft in a safe manner.

○​ Ethical and Legal Issues: Using drones raises a number of ethical and
legal issues. This covers concerns about drone usage in law
enforcement and combat as well as its effects on civil rights. The rapid
development of drone technology necessitates that regulatory
frameworks adapt accordingly.
✽​ Provide your manager with a brief report outlining the reasons why
prototype systems shouldn't typically be used as production systems?
○​ Lack of Documentation: Prototypes often have minimal
documentation, making it difficult for new developers to understand
and maintain the system.

○​ Lack of Robustness: Rather than ensuring robustness and

dependability, prototypes are frequently constructed rapidly with an
emphasis on concept exploration. They might not be built to withstand
the strains and responsibilities of everyday use, which could result in
frequent malfunctions and maintenance problems.

○​ Security Vulnerabilities: Security considerations in prototypes are often

minimal or overlooked. Using a prototype in production could expose
the system to significant security risks, including data breaches and
unauthorised access.

✽​ Can you describe agile practices that they will have to implement in
the software development process?
✽​ Agile development is a methodology aimed at producing useful software quickly and
efficiently.
○​ User Stories: Scenarios describing system use from the user’s
perspective. Used to plan iterations and identify tasks. Allow for
incremental development and refinement based on user feedback.

○​ Refactoring: Continuous improvement of the codebase to enhance

readability and maintainability. Helps avoid code degradation and
supports easier implementation of changes.

○​ Test-first development: requires task implementers to understand the

specification thoroughly to write system tests, clarifying ambiguities
and omissions. This avoids "test-lag" where developers work faster
than testers, leading to skipped tests to maintain the development
schedule.

○​ Pair Programming: Two developers work together at one workstation.

One writes the code (the driver) while the other reviews each line of
code as it’s written (the observer or navigator). This enhances code
quality and knowledge sharing.

○​ Scrum is an agile method that provides a framework for organising

agile projects. It is centred around a set of sprints, which are fixed
time periods when a system increment is developed.Emphasises
teamwork, accountability, and iterative progress towards a
well-defined goal.
✽​ Develop a sequence diagram showing the interactions involved when
the librarian creates an online library account and also select the
library user account type.?

✽​
✽​ To minimise misunderstandings when writing natural language
requirements, suggest recommendations that could be followed for
requirements gathering?
○​ Use Clear and Simple Language: Avoid jargon, technical terms, and
complex sentences. Use simple, clear, and concise language that can
be easily understood by all stakeholders.

○​ Clearly define any words and acronyms used in the requirements

document to ensure that there is no confusion and that everyone is
on the same page.

○​ Clearly define any words and acronyms used in the requirements

document to ensure that there is no confusion and that everyone is
on the same page.

○​ Arrange the Needs Clearly: Assemble similar needs into groups and
arrange them logically. To make content easier to read and navigate,
use headings, subheadings, and numbered lists.

○​ Give Examples and Scenarios: Give instances, scenarios, or use cases

that clarify how the requirements ought to be understood and put
into practice. This gives context and aids in the clarification of difficult
requirements.

✽​ create a use case scenario that depicts the librarian requesting the
system to create a new online library account and also selecting the
library user account type.
○​ Primary Actor: Librarian

○​ Preconditions: The librarian is logged into the library management

system. The system has access to the User Credentials Database.
 ○​ Main Success Scenario: The librarian selects the option to create a
new library account. The system prompts the librarian to enter the
user's details (name, email, etc.). The librarian enters the user
details.The system

○​ checks the entered details against the User Credentials Database.

○​ If the details are valid, the system creates a new library user
account.The librarian selects the user account type (e.g., student,
faculty, guest).The system assigns the selected account type to the
new user account. The system generates a summary of the library
user account's details. The system emails the summary to the user.

✽​ The new client wants to be involved in the system configuration

process. Describe why it might be a good idea for the company owning
the software to make it open source?
○​ One of the main advantages of open source software is that it allows
a greater number of developers to work on projects, which speeds up
the process of developing and debugging products.

○​ Open source might raise consumer awareness of the business's

offering and draw in additional clients.

○​ Cost: Often free to download; documentation/support may incur low

costs.

○​ Reliability: Large user base leads to quicker bug fixes.

✽​ Comprehend how you might set up a program to analyze the

maintenance process and determine appropriate maintainability
metrics for the company?
○​ High-quality code is the foundation of a maintainable and adaptable
system. by using readable code, achieved through clear structure
and meaningful names, allows developers to jump in and understand
the system's logic. Consistency in coding conventions and naming
further enhances maintainability. Complexity should be avoided in
favour of simpler solutions, promoting easier understanding and
future modifications. Thorough documentation, including comments,
explanations, and overviews, empowers team members to grasp the
codebase. Additionally, documenting APIs ensures smooth
interaction between different components. Modularity plays a key
role, with well-defined, logical modules minimising dependencies
and allowing isolated updates. Testable code, facilitated by
automated and unit tests, catches bugs early and ensures changes
don't disrupt existing functionality. Finally, designing for flexibility
allows the software to adapt to evolving requirements without
extensive rework. By prioritising these aspects, code quality becomes
an investment in the system's long-term maintainability and
adaptability.
✽​ You suggest that formal methods should be used in the development
of this system, but your manager is sceptical of this approach. Write a
report highlighting the benefits of formal methods and presenting a
case for their use in this project?
○​ Systems that are essential to safety, like train control systems, require
the greatest standards of security and dependability. Formal
techniques guarantee that systems fulfill strict safety and accuracy
criteria by offering a mathematically rigorous approach to system
definition, development, and verification.

○​ Specification: Formal methods allow for precise and unambiguous

system specifications, reducing the risk of misunderstandings and
errors during development. This clarity is crucial for safety-critical
systems where ambiguities can lead to catastrophic failures.

○​ Verification and Validation: Formal methods facilitate exhaustive

verification of system properties through model checking and
theorem proving. This ensures that the system behaves as intended
under all possible conditions, which is essential for safety-critical
applications.

○​ Improved Documentation: Formal methods produce comprehensive

and precise documentation of the system's behavior and properties.
This documentation is valuable for maintenance, audits, and
certification processes, ensuring long-term reliability and safety.

○​ Increased Reliability: By providing a solid foundation for system

design and verification, formal methods enhance the overall
reliability of the system. This reduces the likelihood of failures and
increases confidence in the system's operation.

✽​ Identify and briefly describe the four types of requirements that may
be defined for an e-commerce-based system to the client?
○​ 1. Functional Requirements: These requirements specify what the
system should do. For an e-commerce application, functional
requirements might include user authentication, product catalogue
management, shopping cart functionality, order processing,
payment processing, and user notifications.

○​ Non-functional Requirements: These specify the system's quality

qualities, including scalability, security, performance, and usability.
The system needs to be able to manage 10,000 users at once, secure
critical data, have a user interface that is easy to use, and have a
99.9% uptime guarantee.

○​ User Requirements: These are natural language statements that

explain the services provided by the system from the viewpoint of the
user. Examples of user stories and use cases include "As an admin, I
 want to update product prices so that I can reflect current
promotions" and "As a customer, I want to search for products by
category so that I can find items easily."

○​ If tests are written before the code in test-first development

methodology. Briefly describe how the test suite might compromise
the quality of the software system being developed?
○​ 1. Incomplete Test Coverage: Some functionality may go untested if
the first tests do not cover all potential outcomes and edge cases.
This may lead to errors and problems going unnoticed until much
later in the development cycle or after deployment.

○​ 2. Overemphasis on Testing at the Expense of Design: Instead of

taking the system's architecture and general design into account,
developers may place an excessive amount of reliance on passing
the tests. This may result in a codebase that satisfies the test
requirements but lacks structure and maintainability.

○​ 3. False Sense of Security: Developers who pass tests may have a

false sense of security, thinking that the program is more dependable
than it really is. Unit tests may not be sufficient to evaluate critical
elements such as usability, security, and performance.

○​ 4. Maintenance Overhead: As the system develops, it may become

more difficult to maintain the test suite. Requirement changes may
result in regular revisions to the tests, which may cause them to
become out-of-date or unnecessary. This might increase the
maintenance burden and perhaps introduce inconsistencies.