CS261 - Software Engineering

Methodologies

• Plan-driven - all of the process activities are planned in advance, progress is measured against initial plan, fixed specification before development starts
• Agile - Incremental planning, more adaptable

Most methodologies consist of design, implementation, testing and maintenance.

Waterfall model

The waterfall model is an example of plan-driven development.

• Linear ordering of processes
• Each stage must be completed before moving on to the next
• Allows distributed development

The waterfall model is ideal for projects where the requirements are understood and will not change. It allows each component to be tested independently and it's easy to add members to a team because the whole system is well documented.

The waterfall model is not adaptable and the customer will have to wait a long time to see results. It is difficult to respond to changing customer requirements. This means it is not ideal for long term projects.

Incremental development

More flexible than waterfall but still plan-driven, software can be developed in stages with customer feedback incorporated between iterations.

Advantages

• The cost of accommodating changing customer requirements is reduced
• Software is available to the customer quicker which allows for quicker feedback
• Greater perceived value for money
• Includes user acceptance testing in each stage

Disadvantages

• Difficult to estimate the cost of development
• Difficult to maintain consistency with new features being added
• Harder to include new features or make changes to fundamental components
• Not cost effective to produce documentation for every version of the software
• Increased cost of repeated deployment

Reuse-oriented software

Rewriting software from scratch is unnecessary and expensive so development can rely on a large base of reusable components instead.

Software specification

Software specification is the first stage of a software methodology. It requires understanding and definition of required services in a system and identification of constraints. This process is also called requirements engineering and results in a requirements document. This document has to be understood by both the customer and developers. Requirements engineering is divided into 4 steps.

• Feasibility study - Determine that the task is feasible and cost-effective
• Requirements elicitation and analysis - Derive the system requirements from the customer
• Requirements specification - Translate information from the previous stage into formal documents that define the set of requirements
• Requirements validation - Ensure the requirements are achievable and valid These four stages come together to form the requirements document.

Agile development

Principles of agile development

• Customer involvement - The customer can provide and prioritise new system requirements and evaluate iterations
• Incremental delivery - Software is developed in increments with the customer specifying the requirements for the next iteration
• People, not processes - Skills of the development team should be recognised, team members should develop their own ways of working
• Embrace change - Design a system that accommodates change
• Maintain simplicity - Focus on simplicity in the software being developed

Agile focuses more on development than documentation so it can be harder to make changes later. This can also cause problems if the team changes.

Extreme programming

• Extreme programming is an agile method with incremental delivery and fast iterations
• Versions will be built several times a day and delivered to the customer every few weeks
• Automated tests are used to verify builds and builds are only accepted if all tests pass
• Code is continually refactored to maintain simplicity
• Strong customer involvement
• Simple design
• Test-driven development - tests are written before the software
• Pair programming - developers work in pairs checking each others work and providing support
• Collective ownership - pair programming means at least two people understand it
• Continuous integration - components are integrated as soon as they are ready
• Sustainable pace
• On-site customer - easier to get feedback

Scrum

Scrum is an agile method which focuses on managing iterative development it has 3 primary phases

• Outline planning phase - establish general goals
• Sprint cycles - each cycle develops an increment of the system
• Project closure - wrap up the project, document and deliver

A scrum master interfaces between the developers and customer.

Prototypes or MVPs

Prototypes are for testing feasibility and proof of concept and presenting to customers. They are not necessarily a complete solution.

Minimum Viable Products (MVPs) meet the fundamental requirements for deployment to production. They are mostly finished products.

Requirements analysis

Requirements are descriptions of what the system should do, the service it provides and the constraints on its operation. They provide a basis for tests, validation and verification and enable more accurate cost estimation.

Requirements are a bridge between customers and developers, so requirements need to be specified so both the customer and developers can understand them. There is a notion of C- and D-facing requirements, written to be understood by the customer and developers respectively.

Customer requirements (C-facing) define how the system should work from the user's view. They use natural language and diagrams. Developer requirements (D-facing) use detailed, technical descriptions and define exactly what must be designed and implemented.

Requirements describe what needs to be built, whereas design and implementation are how it is built.

Requirements should be

• Prioritised - Must/should/could/won't
• Consistent - requirements don't conflict
• Modifiable - requirements can be changed
• Traceable - each requirement should have a reason
• Correct - a requirement should accurately describe its functionality
• Feasible
• Necessary
• Unambiguous
• Verifiable - can be tested

The requirements analysis document needs to be understood by customers, managers, engineers, testers and maintainers.

The requirements analysis document consists of a preface, introduction, glossary, user requirements design (customer facing requirements), system architecture (high level overview of system), system requirements specification (functional and non-functional requirements), system models (relationships between components), system evolution and appendices.

Functional requirements describe what the system should do. Non-functional requirements describe qualities of a system such as availability, performance and deployment. They specify constraints on the system and legal constraints.

Requirements elicitation and analysis consists of a few stages

• Discovery - interview stakeholders
• Classification - categorise discovered requirements
• Prioritisation and negotiation - prioritise requirements and negotiate conflicting requirements
• Specification - Put the requirements in a document for stakeholders to review, then repeat the process if more changes have to be made

Requirements need to be validated.

• Validity - will the system support the customer's needs?
• Consistency - are there any conflicts?
• Realism - can the system be produced with available technologies and resources?
• Verifiability - Once complete, can the system be shown to satisfy the requirements?

Requirements must take into consideration legal, social and professional issues including respecting copyright and patents, recognising developers, not breaking any laws and working in the best interest of the 🅱ustomer.

Project management

A project may fail if the requirement specification was poor, deadlines were unrealistic, budget was insufficient, communication was poor, testing was inadequate or team members did not fulfil their tasks.

The four main goals of project management are

• Deliver the software at the agreed time
• Keep overall costs within budget
• Deliver software that meets the customers expectations
• Maintain a happy and well-functioning development team

The success of a team depends on three generic factors

• The people in the team
• The group organisation
• Technical and managerial communications

Risk management

Steps for risk management

• Identify
• Analyse
• Plan
• Monitor

Risks can be grouped by what they affect. Project risks affect the project schedule or resources. Product risks sre those that affect the quality or performance of the software being developed. Business risks are those that affect the organisation developing the software.

Project planning

Project managers must break down the work into parts and assign each part to a team member. They must also anticipate and deal with problems which may arise. Project planning takes place in 3 stages:

• Proposal stage
• Startup phase
• Periodical planning

Project scheduling involves identifying activities, estimating resources and allocating activities to people. Gantt charts can be used to represent project schedules.

Schedule estimation can be done based on past experience or using an algorithm to estimate based on project attributes.

A project is successful if it meets the original specification and the customer's expectations.

System design

System design is supported by system modelling.

System modelling perspectives:

• External - model the context of the system
• Interaction - model the interactions between the system and its environment, or between components of a system
• Behavioural - model dynamic behaviour of the system
• Structural - model the organisation of a system or the structure of the data being processed

System modelling encourages ambiguity resolution.

UML is a modelling language to represent static and dynamic parts of the system. Creating static views of a system requires identifying entities (objects).

A class diagram in UML shows entities and their relationships. It gives the class name, attributes and methods. + and - denote public and private methods respectively. They do not include setters, getters and inherited methods. Static attributes/methods should be underlined. Abstract class names are styled in italics and interfaces are surrounded with << >>.

Arrows between classes denote parent-child relationships. Arrows go from child to parent. A solid line with black arrow denotes a class, a solid line with white arrow denotes an abstract class and a dashed line with a white arrow denoted an interface.

Entities in a class diagram can be linked together to represent relationships. These associations have several features

• Multiplicity - a..b means between a and b inclusive, where a and b are numbers. If b is omitted it means "a or more". * denotes zero or more.
• Name - what relationship the objects have, such as "contains" or "creates"
• Navigability - direction

Entities can have one-to-one or one-to-many relationships.

A white diamond denotes aggregation and means one class in part of the other, like an engine being part of a car. A black diamond denotes composition and means one class is made up of the other, like a book is made up of pages. The book entity cannot exist without the page entity, whereas the car can without the engine so composition is stronger than aggregation. A dashed line denotes temporary dependency.

For example, a diagram may contain cinema, movie and box office as entities with a black diamond from box office to cinema and a white diamond from movie to cinema. If the cinema is destroyed, so is the box office (composition) but the movies will still exists (aggregation).

Context models illustrate the operational context of the system and other systems.

Structural models show the organisation of components in a system. UML diagrams are an example of these.

Activity diagrams are used to represent workflows of stepwise activities, like a flowchart.

Interaction models show user interaction with the system. In UML these are use case diagrams and sequence diagrams. A use case diagram represents a user's interactions with the system and a sequence diagram shows a user's interactions over time.

A state machine diagram is a finite state machine showing how the state of the system changes, like an NFA but less CS259-y.

Architectural design

Architectural design is concerned with understanding how a system should be organised. Some common architectural patterns include

• Layered - structure system into layers that provide services to the layer above, each layer only relies on the layer below it. Good for modular design but may not be an ideal structure for some systems
• Repository - all data is in a central repository and all interaction is done through it. Efficient for sharing data but introduces a single point of failure
• Pipe and filter - Components take data, transform it and then pipe it to other components. Components can be reused, flexible but requires standardised data format. Ideal for batch processing
• Model-View-Controller (MVC) - focusses on how to interpret user interactions, update data and present that to the user. Provides separation between presentation, interaction and data but can make design more complex. Ideal for UI

Implementation

Design patterns can be used to solve common programming problems. Encapsulation, inheritance, iteration and exceptions are design patterns.

Creational patterns are design patterns for creating objects.

• Factories - method which produces classes of a particular type
• Builders - objects created step by step using methods
• Prototypes - clone objects to make new objects

Structural patterns are used to realise relationships between entities.

• Proxy - Stand in for another object, can load the original when needed
• Decorator - Adds new behaviour to objects at runtime
• Adaptor - Allows output from one object to be used by another
• Flyweight - Store one copy of expensive attributes in a static class and reference it

Behavioural patterns are concerned with how objects communicate.

• Iterator - Traverse a container to access its elements
• Observer - Notifies other objects if state changes are made
• Memento - Save and restore objects without revealing its implementation details
• Strategy - Select the method to complete a task at runtime

Design patterns help achieve the SOLID design principles.

• Single responsibility - a class should be responsible for a single piece of functionality
• Open/closed - once designed and completed, a class should be extended, not modified
• Liskov substitution - an object that uses a parent class can use its child classes without knowing
• Interface segregation - Many specific interfaces are better than a general one
• Dependency inversion - high level classes don't depend on low level classes

Human computer interaction

HCI is the study of how humans interact with computers. There are four main human traits that underpin HCI.

1. Attention

   • Selective attention - tune other things out to focus on a particular set of stimuli
   • Divided attention - focussing on multiple things at once
   • Sustained attention - attention span
   • Executive attention - more organised attention

2. Memory

   • Sensory stores - visual and auditory stores hold information before it enters working memory
   • Working memory - Holds transitory information and makes it available for further processing
   • Long-term memory

3. Cognition - the process by which we gain knowledge

   Norman's human action cycle is the idea that humans go through a cycle of 7 stages when interacting with a computer system.

   1. Form a goal
   2. Intention to act
   3. Planning to act
   4. Execution
   5. Feedback
   6. Interpret feedback
   7. Evaluate outcome

   The human action cycle is used to evaluate the effectiveness of a user interface. It focusses on two particular aspects, the gulf of evaluation and the gulf of execution. The gulf of evaluation is the psychological gap which must be crossed to interpret a UI. The gulf of execution is the gap between the user's goals and the means to execute these goals. Both of these gulfs need to be minimised.

   The Gestalt laws of perceptual organisation are a set of principles around human visual perception.

   1. Figure ground principle - People tend to segment their vision into the figure and the ground, the figure is the focus and the ground is the background.
   2. Similarity principle - If two things look similar, they should behave the same way
   3. Proximity principle - If objects are close together they must be related
   4. Common region principle - If objects in the same closed region (like a border) are grouped together
   5. Continuity principle - If objects are in a line or a curve they are perceived as related
   6. Closure principle - If there is a complex arrangement of shapes they are perceived as a single pattern
   7. Focal point principle - People are drawn to the most unique part of an image

4. Affordances - what an object allows us to do, a door affords opening it. It is important to make affordances as clear as possible. Signifiers are cues about an object's affordances.

Nielson's Usability Principles

1. Visibility of system status
2. Match between system and real world
3. User control and freedom
4. Consistency and standards
5. Help users recognise and recover from errors
6. Error prevention
7. Recognition rather than recall
8. Flexibility and efficiency of use
9. Aesthetic and minimalist design
10. Help and documentation

Software dependability

Software systems need to be dependable. If they are not, people won't use them.

Reliability is a measure of how likely the system is to provide its service for some amount of time. Perceived reliability is how reliable the system appears to the user.

Reliability can be measured using

• Probability of failure on demand
• Rate of occurrence of failures
• Mean time to failure
• Availability

There are many attributes of a dependable system

• Availability
• Reliability
• Safety
• Confidentiality
• Integrity
• Maintainability

A fault is the cause of an error. A failure is the result of an error propagating beyond a system boundary.

Some causes of system failures include

• Hardware failure
• Software failure
• Operational failure

Dependability can be proved using

• fault avoidance
• fault detection and correction
• fault tolerance

Graceful degradation means the system is able to operate, possibly with reduced capacity, in the event of component failure. Redundancy is spare capacity included in a system that can be used in case of a failure. If components are diverse they are less likely to fail in the same way.

Dependable processes are those that produce dependable software. Dependable processes are

• Documentable
• Standardised
• Auditable
• Diverse
• Robust

System architectures also need to be dependable. This can be achieved with

• Protection systems
• Self-monitoring architectures
• N-version programming
• Software diversity

System testing

Testing shows a program does what it was intended to do. It highlights defects before the software is in use.

Static testing is testing without execution. Dynamic testing is executing test cases.

• Structural/white-box testing are test cases derived from control/data flow of system
• Functional/black-box testing are test cases derived from formal component specification

Statement adequacy means all statements have been executed by at least one test. Statement coverage is number of executed statements divided by number of statements.

Unit tests test the simplest parts of a system, like objects and methods. Component or integration testing tests how units interact with each other.

Test driven development develops tests before writing code and development does not continue until all tests pass.

User testing ensures the system works in a variety of environments.

• Alpha testing - small group, early release
• Beta testing - larger group, later release
• Acceptance testing - larger group, final system

Release management

Version control manages code changes over time and allows rolling back to previous versions.

Systems can be released into different environments during release, such as test, development, feature and master.