Software Engineering (old course)

A safety-critical system is a system whose failure or malfunction may cause death or injury, serious damage to property or the environment, for example aircraft control, medical devices, and nuclear plant control systems.

A test case is a set of inputs, execution conditions and expected results designed to check whether a particular feature or requirement of the software works correctly.

A sequence diagram is made to show how objects interact with each other by messages in a time order for a particular scenario or use case, so that the flow of control is clear.

Database design is the process of defining the structure of a database: the tables or entities, their attributes, keys, relationships and constraints, so that data is stored efficiently and consistently and can be retrieved easily.

Software is a set of programs, data and documentation (instructions) that tells the computer hardware what to do and how to perform a task.

One task in a feasibility study is to assess whether the proposed system is technically, economically and operationally possible, for example estimating the costs and benefits (cost-benefit analysis) of developing it.

Advantages of re-use oriented software engineering: reduced development time and cost, lower risk, faster delivery, and higher quality and reliability because the reused components are already tested.

Architectural models show the overall structure of a software system (its main components and their relationships), which is used to communicate with stakeholders, analyse the design for requirements such as performance and security, and guide the detailed design and development.

Refactoring is the process of improving the internal structure of existing code, making it cleaner and easier to understand and maintain, without changing its external behaviour.

Graphical models are used to represent a system visually, which makes it easier to understand and to communicate with stakeholders and developers than long text descriptions.

A Java int is 4 bytes (32-bit signed), with range $-2147483648$ to $2147483647$. The test values should cover each class of input.

Boundary values ($-2147483648$, $0$, $1$, $2$, $2147483647$) check overflow and edge conditions, while the other values check normal behaviour.

Actors: User (the person who views the records). Optionally, an Administrator/Data Entry person who adds and edits records.

Use cases:

• Add person record (name, date of birth, gender, height, weight)
• View records by gender (males only / females only)
• View records by height or weight greater than a given value
• View records by given date of birth
• (Optional) Update / delete person record

Use case diagram (text form):

                 +----------------- People Record System -----------------+
                 |                                                        |
                 |   ( Add person record )                                |
   +-------+     |                                                        |
   | Admin |-----|---( Update / delete record )                           |
   +-------+     |                                                        |
                 |   ( View records by gender )                           |
   +-------+     |                                                        |
   | User  |-----|---( View records with height/weight > given value )    |
   +-------+     |                                                        |
                 |   ( View records by date of birth )                    |
                 +--------------------------------------------------------+

The Admin is also allowed to perform all the viewing use cases (generalization of User). The "View" use cases may include a common "Search records" use case, with the gender, height/weight and date-of-birth criteria as inputs.

Four requirements for online banking software:

1. User authentication: the system shall authenticate users by user ID and password with a second factor (OTP) before giving access.
2. Account information: customers shall be able to view account balances and transaction history/statements.
3. Fund transfer: the system shall allow transferring funds between own accounts and to other accounts/banks, and bill payments.
4. Security and availability: all data shall be encrypted in transit, sessions shall time out after inactivity, and the system shall be available 24 hours a day with transaction records kept for audit.

Characteristics of sociotechnical systems needed to develop secure and dependable systems:

• Hardware, software and people together: the system includes the equipment, software, operators and organizational processes, so security and dependability must be designed for all of them, not just the software.
• Emergent properties: safety, reliability and security depend on the interaction of all components, so they must be assessed at the system level.
• Non-deterministic behaviour: human operators and the environment make behaviour unpredictable, so the system should tolerate human error and give clear feedback.
• Organizational and social context: policies, culture, training and procedures must support secure use; operators must be trained and responsibilities defined.
• Defence in depth and redundancy: use of multiple layers of protection, fault tolerance, and recovery and backup so that a single failure does not cause system failure.
• Evolution and regulation: the system changes over time and must follow legal and regulatory requirements, with maintenance and upgrade of security.

In extreme programming, a task card breaks a user story into a small piece of work that one developer can finish in a few hours. A task card for medical dose checking:

Task 4: Dose checking

• Story: Prescribing medication (the doctor prescribes a drug and the dose is validated).
• Task: Implement the dose checking function for a prescribed drug.
• Inputs: Drug name, dose per administration, frequency, patient weight and age.
• Steps:
  1. Find the drug's safe minimum and maximum single dose and maximum daily dose, per kg of body weight where relevant, from the drug database.
  2. Calculate the prescribed dose per administration and the total per day.
  3. If the dose is below the minimum or above the maximum, show a warning and ask the doctor to confirm or change it.
  4. If the dose is within range, accept the prescription.
• Tests: dose below minimum; dose equal to the limits; dose above the maximum; weight not entered; unknown drug.
• Estimate: 2 days.

Dependability reflects the user's degree of trust in a system: whether it works as expected and does not fail in normal use. It is usually more important than detailed functionality for these reasons:

• Failure costs are high. An unreliable system can cause loss of data, money, business or even lives (for example in medical, banking or aviation software). Missing a feature is usually only an inconvenience.
• Users reject untrustworthy systems. If users do not trust a system they stop using it, however many functions it offers.
• Dependability attributes (availability, reliability, safety and security) are system-wide properties. They cannot be added after the system is built, while a function can be added later.
• Recovery is expensive. Restoring data and reputation after a failure costs far more than building the system carefully in the first place.
• Security failures can expose confidential data and be exploited by attackers.

Hence a system with fewer features that is dependable is more valuable than a feature-rich but unreliable one.

Agile methods are based on incremental development and delivery, so they fit both developing a program and changing it afterwards.

• Evolution is continuous development. Evolution means making changes to an existing system in response to new requirements. Agile methods are built to handle changing requirements, so the same practices (user stories, short iterations, frequent releases) work for new changes.
• Same team and tools. The developers who built the system, with their automated tests and continuous integration, can continue to release small increments instead of handing over to a separate maintenance team.
• Regression testing. Test-first development and automated tests give confidence that each change does not break existing functionality.
• Refactoring keeps the code clean and easy to change as it evolves.
• Customer involvement. The customer continues to prioritise the changes, so the most valuable ones are delivered first.
• Small, frequent releases reduce risk compared with large infrequent changes.

Difficulties remain: little documentation may make it hard for new staff to understand the system, and the customer may not stay involved after delivery.