Archive Notes

Week 1. Software Engineering and Software Lifecycles

5 min read

Week 1. Soft Eng. and Lifecycles

Software Engineering

Software Engineering

Software Engineering is the “systematic application of scientific and technological knowledge, methods, and the experience” to the design, implementation, testing, and documentation of software.

Link to original

Essential attributes of good software

  • Maintainability

    Maintainability: software should be written in a way that it can evolve to the changing needs of a customer. Software change is an inevitable requirement.

    Link to original

  • Dependability and security

    Dependability and security: dependable software should not cause physical or economic damage in the event of failure. Malicious users should not be able to access or damage the system.

    Link to original

  • Efficiency

    Efficiency: Software should not waste system resources such as memory or CPU time. Includes responsiveness, processing time, memory utilisations, etc.

    Link to original

  • Acceptability

    Acceptability: Software must be acceptable to the type of users that it’s designed for. Must be understandable, usable and compatible with the systems that they use.

    Link to original

General issues that affect software

  • Heterogeneity (issue affecting software)

    Heterogeneity: systems are required to operate as distributed systems across networks that include different types of computer and mobile devices.

    Link to original

  • Business and social change (issue affecting software)

    Business and social change: business and society are changing as emerging economies develop and new technologies become available. They need to be able to change their existing software and to be able to rapidly develop new software.

    Link to original

  • Security and trust (issue affecting software)

    Security and trust: it is essential that we can trust software which is intertwined with all aspects of our life.

    Link to original

  • Scale (issue affecting software)

    Scale: software has to developed across a very wide range of scales, from very small embedded systems in portal or wearable devices to Internet-scale, cloud-based systems that serve customers globally.

    Link to original

Software engineering diversity

There are many different types of software systems and there is no universal set of software techniques applicable to all of these. The software engineering methods and tools used depend on the type of application being developed, the requirements of the customer and the background of the development team.

Types of Applications

  • Stand-alone applications

    Stand-alone applications are application systems that run on a local computer, they include all necessary functionality and do not need to be connected to the internet.

    Link to original

  • Interactive transaction-based applications

    Interactive transaction-based applications: applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications.

    Link to original

  • Embedded control systems

    Embedded control systems: Software control systems that manage hardware devices.

    Link to original

  • Batch processing systems

    Batch processing systems: business systems designed to process data in large batches, process large numbers of individual inputs to create corresponding outputs.

    Link to original

  • Entertainment systems

    Entertainment systems: systems primarily for personal use and intended to entertain the user.

    Link to original

  • Data collection systems

    Data collection systems: systems that collect data from their environment using a set of sensors and send data to other systems for processing.

    Link to original

  • Systems of systems

    Systems of systems: these are systems that are composed of a number of other software systems.

    Link to original

Engineering Fundamentals

  1. Systems should be developed using a managed and understood development process. Dependability and performance are important for all types of system.
  2. It is important to understand and manage the software specification and requirements.
  3. Where appropriate, software should be reused rather than developed again.

Internet software engineering

The web is now a platform for running applications and many organisations are now increasingly developing web-based systems. Web services allow application functionality to be accessed over the web.

Cloud Computing

Cloud computing is an approach to provisioning of computer services where applications run on the ‘cloud’ (remote servers). Users do not buy software but usually pay to use.

Link to original

Web-based systems are complex distributed systems but the fundamental principles of software eng. are still applicable.

Software Development Lifecycle (SLDC)

digraph {
	a[label="1. Feasibility Analysis"]
	b[label="2. Requirements Analysis"]
	c[label="3. Architecture & Design"]
	d[label="4. Implementation"]
	e[label="5. Testing"]
	f[label="6. Deployment & Maintenance"]
	
	a->b
	b->c
	c->d
	d->e
	e->f
	f->b
}

1. Feasibility Analysis

Before starting a project, we need to know whether it can be done successfully.

  • Business need: is there a case or use for this system?
  • Technical feasibility: is it possible with available technology?
  • Financial feasibility: can it be developed within the budget?
  • Time: is it possible to develop in a useful time frame?
  • Resources: are all necessary resources available for development?

2. Requirements Analysis

Systematically identify and record requirements of stakeholders.

The requirements should reflect the needs of the stakeholders:

  • Functional requirement

    A functional requirement is what the system should do, it is a series of statements of the services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

    Link to original

  • Non-functional requirement

    A non-functional requirement is how the system should do it. (refers to performance, usability, extensibility and related) It includes constraints on the services or functions provided by the system.

    Link to original
  • Constraints imposed by system context. (existing systems, policy, law, etc.)

Requirements may be conflicting or ambiguous so analysis aims to resolve ambiguity and conflict. These final requirements may be eventually written up as a specification, this can be in any form such as a multi-page document, formal-logic specification, user stores, use cases, etc.

A specification should include requirement prioritisation:

MoSCoW style

MoSCoW style is based on risk / benefit analysis and follows as “Must, Should, Could, Won’t”.

Link to original
The specification should be

SMART

SMART: Specific, Measurable, Assignable, Realistic, Time-related.

Link to original

Stages in requirements analysis

There are several stages in requirements analysis:

  1. Domain analysis, requirements elicitation
    • Identify stakeholders
    • Gather information on domain + requirements
    • Talk with users, customers, and other stakeholders
    • Look at literature and other similar systems
  2. Evaluation and negotiation
    • Identify conflicts, imprecision, omissions, redundancies
    • Consult and negotiate with stakeholders to agree resolutions
  3. Specification and negotiation
    • Systematically document requirements as system specification
    • In-precise or potentially formal notation
    • Agreement between developers and stakeholders on what will be developed
  4. Validation and verification
    • Check formalised requirements for consistency, completeness and correctness
Link to original

3. Architecture & Design

Describe a high-level overall view of the system. Good for work planning, overall team organisation and communication.

4-1 Model

The 4-1 model for architecture:

  • Logical: define the major subsystems / components and their inter-connections
  • Process: define the major information and data-flows, their interactions and concurrency
  • Physical: identify hardware resources and allocation of components
  • Development: identify how to package, build and deploy
  • Scenarios: use cases highlighting integration / interaction between views
Link to original

Design by thinking through detailed structure and algorithms within components. This is risk / value driven, so invest an appropriate amount of effort into each part of the system. Don’t design everything, some things can just be programmed. Focus on parts that are technically difficult.

Design may involve:

  • Use of diagrams in Unified Modelling Language or other modelling languages.
  • Signing off by relevant stakeholders.
  • High-level analysis of performance, security, safety, reliability, potentially using automated tools.

4. Implementation

This stage involves building the software following the design documents, using the appropriate languages and tools. May involve expertise from different areas and including code for physical and development views.

5. Testing

Aim is to discover errors before they make it into production.

White-box testing

White-box testing is test cases determined based on understanding of code / design structure, aiming to test each program path.

Link to original

Black-box testing

Black-box testing is test cases determined based on requirements without regard for code structure, it does not consider how the system works.

Link to original

There are different levels of testing we need to consider:

6. Deployment & Maintenance

Roll out software on to a production system, this may require:

  • sophisticated support systems itself
  • may need consideration of a transition phase
  • substantial planning of the roll out itself, since it is a potentially dangerous activity
  • training of users

Post-delivery activities / maintenance, includes:

  • Correction: bug-fixing and correcting defects
  • Adaption: changing the system to operate in new / updated environments
  • Enhancement: extending the system to handle new requirements
  • Prevention: re-engineering to improve the structure of the system
  • Decommissioning: managing termination of use of the system

Selected Software Lifecycles

Sequential Lifecycles

Below is an example of the Waterfall model:

digraph {
	a[label="1. Feasibility Analysis"]
	b[label="2. Requirements Analysis"]
	c[label="3. Architecture & Design"]
	d[label="4. Implementation"]
	e[label="5. Testing"]
	f[label="6. Deployment & Maintenance"]
	
	a->b
	b->a
	
	b->c
	c->b
	
	c->d
	d->c
	
	d->e
	e->d
	
	e->f
	f->b
}

Problems with the sequential approach

  1. Hard to handle requirement changes.
    • Once captured, requirements are assumed to be fixed.
    • Requirements may have been misunderstood.
    • Requirements may change in the future. Stakeholders may only understand their requirements when they see a partial solution.
  2. Time-to-market and loss of system relevance.
    • System only available at the end of process.
    • The system may be finished after several months or even years.
  3. Lack of incorporation of risk / value in process.
    • We are always building a “complete system”.
    • A step at the end may fail.
    • A component built at the start may lose its value for the customer.

Incremental (agile) approaches

Incremental development approach

We develop and deliver software in a series of planned increments.

  1. Design and plan increments.
  2. Each increment provides additional functionality.
  3. Planning horizon is across multiple increments. You can lay design foundations in earlier increments.
digraph {
	rankdir=LR
 
	subgraph cluster0 {
		label="Increment 1"
	
		1 [label=Analyse]
		2 [label=Design]
		3 [label=Implement]
		4 [label=Test]
	
		1->2
		2->3
		3->4
	}
 
	subgraph cluster1 {
		label="Increment 2"
		
		5 [label=Analyse]
		6 [label=Design]
		7 [label=Implement]
		8 [label=Test]
	
		5->6
		6->7
		7->8
	}
 
	4->5
	8->9
 
	9 [shape=plain label="..."]
}
Link to original

Advantages / disadvantages of incremental

Advantages:

  • Early value and continues to add value.
  • Flexibility to adjust to changing requirements.
  • Risk of failure increases with project length since increments are short.
  • Project always delivers something.

Disadvantages:

  • Difficult to identify the end of the project.
  • Difficult to plan costs and budgets.
  • Can easily deteriorate into code and fix.
  • Susceptible to technical debt.

Examples of incremental approaches

Agile Lifecycle

Agile lifecycle

Agile approaches favour incremental / iterative approaches, it is often driven by a feature list. It is regularly reviewed and re-prioritised with the product owner and any relevant stakeholders.

Planning horizon is often very short-term, architectural concerns are sometimes only captured through the “Minimum Viable Product”. In SCRUM (see below), it is sometimes captured through a “Sprint 0”, which does initial planning work.

Link to original

Kanban

Kanban lifecycle

Kanban is an approach where you work with multiple lists which dictate how issues are currently being handled.

Link to original

SCRUM

SCRUM is a more structured and planned out agile lifecycle, it prioritises and refines tasks according to priority.

Graph View