What is a Software?

• The economies of ALL developed nations are

dependent on software.

• More and more systems are software controlled

• Software engineering is concerned with theories, methods and tools for professional software
development.

• Expenditure on software represents a

significant fraction of GNP in all developed countries.

• Software costs often dominate computer system costs. The costs of software on a PC are often
greater than the hardware cost.

• Software costs more to maintain than it does to develop. For systems with a long life,
maintenance costs may be several times development costs.

• Software engineering is concerned with cost-effective software development.

• Software engineering is an engineering discipline that is concerned with all aspects of software
production from the early stages of system specification through to maintaining the system after
it has gone into use.

• Engineering discipline

• Using appropriate theories and methods to solve problems bearing in mind organizational and
financial constraints.

• All aspects of software production

• Not just technical process of development. Also project management and the development of
tools, methods etc. to support software production.

Software engineering activities

• Software specification, where customers and engineers define the software that is to be
produced and the constraints on its operation.

• Software development, where the software is designed and programmed.

• Software validation, where the software is checked to ensure that it is what the customer
requires.

• Software evolution, where the software is modified to reflect changing customer and market
requirements.

Software engineering importance

• More and more, individuals and society rely on advanced software systems. We need to be able
to produce reliable and trustworthy systems economically and quickly.
 • It is usually cheaper, in the long run, to use software engineering methods and techniques for
software systems rather than just write the programs as if it was a personal programming
project. For most types of system, the majority of costs are the costs of changing the software
after it has gone into use.

General issues

1. Heterogeneity

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

1. Business and social change

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

Security and trust

As software is intertwined with all aspects of our lives, it is essential that we can trust that software.

4. Scale

Software has to be developed across a very wide range of scales, from very small embedded systems in
portable or wearable devices through to Internet-scale, cloud-based systems that serve a global
community.

Software testing

Testing stages

• Component testing

• Individual components are tested independently;

• Components may be functions or objects or coherent groupings of these entities.

• System testing

• Testing of the system as a whole. Testing of emergent properties is particularly

important.

• Customer testing

• Testing with customer data to check that the system meets the customer’s needs.
System models

• The waterfall model

 Plan-driven model. Separate and distinct phases of specification and development.

• Incremental development

 Specification, development and validation are interleaved. May be plan-driven or agile.

• Integration and configuration

 The system is assembled from existing configurable components. May be plan-driven or

agile.

• In practice, most large systems are developed using a process that incorporates elements from
all of these models.

Agile Models

Agile development

• Program specification, design and implementation are inter-leaved

• The system is developed as a series of versions or increments with stakeholders involved in

version specification and evaluation

• Frequent delivery of new versions for evaluation

 • Extensive tool support (e.g. automated testing tools) used to support development.

• Minimal documentation – focus on working code

• Plan-driven development

• A plan-driven approach to software engineering is based around separate

development stages with the outputs to be produced at each of these stages planned
in advance.

• Not necessarily waterfall model – plan-driven, incremental development is possible

• Iteration occurs within activities.

• Agile development

• Specification, design, implementation and testing are inter-leaved and the outputs
from the development process are decided through a process of negotiation during
the software development process.

Agile methods

• Dissatisfaction with the overheads involved in software design methods of the 1980s and
1990s led to the creation of agile methods. These methods:

• Focus on the code rather than the design

• Are based on an iterative approach to software development

 • Are intended to deliver working software quickly and evolve this quickly to meet
changing requirements.

• The aim of agile methods is to reduce overheads in the software process (e.g. by limiting
documentation) and to be able to respond quickly to changing requirements without
excessive rework.

Incremental Development

Incremental development benefits

• The cost of accommodating changing customer requirements is reduced.

• The amount of analysis and documentation that has to be redone is much less than is
required with the waterfall model.

• It is easier to get customer feedback on the development work that has been done.

• Customers can comment on demonstrations of the software and see how much has
been implemented.

• More rapid delivery and deployment of useful software to the customer is possible.

• Customers are able to use and gain value from the software earlier than is possible with
a waterfall process.

Incremental development problems

• The process is not visible.

• Managers need regular deliverables to measure progress. If systems are developed

quickly, it is not cost-effective to produce documents that reflect every version of the
system.

• System structure tends to degrade as new increments are added.

• Unless time and money is spent on refactoring to improve the software, regular change
tends to corrupt its structure. Incorporating further software changes becomes
increasingly difficult and costly.
 Waterfall

• There are separate identified phases in the waterfall model:

• Requirements analysis and definition

• System and software design

• Implementation and unit testing

• Integration and system testing

• Operation and maintenance

• The main drawback of the waterfall model is the difficulty of accommodating change after the
process is underway. In principle, a phase has to be complete before moving onto the next
phase.

Waterfall model problems

• Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing
customer requirements.

• Therefore, this model is only appropriate when the requirements are well-understood
and changes will be fairly limited during the design process.

• Few business systems have stable requirements.

• The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites.

• In those circumstances, the plan-driven nature of the waterfall model helps coordinate
the work.

Reuse Approach
 Types of reusable software

• Stand-alone application systems (sometimes called COTS) that are configured for use in a
particular environment.

• Collections of objects that are developed as a package to be integrated with a component

framework such as .NET or J2EE.

• Web services that are developed according to service standards and which are available for
remote invocation.

Reuse-oriented software engineering

reuse-oriented software

Incremental Delivery

• Rather than deliver the system as a single delivery, the development and delivery is broken
down into increments with each increment delivering part of the required functionality.

• User requirements are prioritised and the highest priority requirements are included in early
increments.

• Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.

• Incremental development

• Develop the system in increments and evaluate each increment before proceeding to
the development of the next increment;

• Normal approach used in agile methods;

• Evaluation done by user/customer proxy.

• Incremental delivery

• Deploy an increment for use by end-users;

• More realistic evaluation about practical use of software;

• Difficult to implement for replacement systems as increments have less functionality

than the system being replaced.
Incremental delivery advantages

• Customer value can be delivered with each increment so system functionality is available earlier.

• Early increments act as a prototype to help elicit requirements for later increments.

• Lower risk of overall project failure.

• The highest priority system services tend to receive the most testing.

Incremental delivery problems

• Most systems require a set of basic facilities that are used by different parts of the system.

• As requirements are not defined in detail until an increment is to be implemented, it can

be hard to identify common facilities that are needed by all increments.

• The essence of iterative processes is that the specification is developed in conjunction with the
software.

• However, this conflicts with the procurement model of many organizations, where the
complete system specification is part of the system development contract.

Extreme programming

• A very influential agile method, developed in the late 1990s, that introduced a range of agile
development techniques.

• Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.

• New versions may be built several times per day;

• Increments are delivered to customers every 2 weeks;

• All tests must be run for every build and the build is only accepted if tests run
successfully.

The extreme programming release cycle

Scrum

• Scrum is an agile method that focuses on managing iterative development rather than specific
agile practices.

• There are three phases in Scrum.

• The initial phase is an outline planning phase where you establish the general objectives
for the project and design the software architecture.

• This is followed by a series of sprint cycles, where each cycle develops an increment of
the system.

• The project closure phase wraps up the project, completes required documentation
such as system help frames and user manuals and assesses the lessons learned from the
project.

The Scrum sprint cycle

• Sprints are fixed length, normally 2–4 weeks.

• The starting point for planning is the product backlog, which is the list of work to be done on the
project.

• The selection phase involves all of the project team who work with the customer to select the
features and functionality from the product backlog to be developed during the sprint.

• The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work to be
done, records decisions, measures progress against the backlog and communicates with
customers and management outside of the team.
 • The whole team attends short daily meetings (Scrums) where all team members share
information, describe their progress since the last meeting, problems that have arisen and what
is planned for the following day.

• This means that everyone on the team knows what is going on and, if problems arise,
can re-plan short-term work to cope with them.

Scrum benefits

• The product is broken down into a set of manageable and understandable chunks.

• Unstable requirements do not hold up progress.

• The whole team have visibility of everything and consequently team communication is
improved.

• Customers see on-time delivery of increments and gain feedback on how the product works.

• Trust between customers and developers is established and a positive culture is created in
which everyone expects the project to succeed.

Stories and Scenarios

• Scenarios and user stories are real-life examples of how a system can be used.

• Stories and scenarios are a description of how a system may be used for a particular task.

• Because they are based on a practical situation, stakeholders can relate to them and can
comment on their situation with respect to the story.

Scenarios

• A structured form of user story

• Scenarios should include

o A description of the starting situation;

o A description of the normal flow of events;

o A description of what can go wrong;

o Information about other concurrent activities;

o A description of the state when the scenario finishes.

Requirement engineering

• The process of establishing the services that a customer requires from a system and the
constraints under which it operates and is developed.

• The system requirements are the descriptions of the system services and constraints that are
generated during the requirements engineering process.

What is a requirement?
 • It may range from a high-level abstract statement of a service or of a system constraint to a
detailed mathematical functional specification.

• This is inevitable as requirements may serve a dual function

• May be the basis for a bid for a contract - therefore must be open to interpretation;

• May be the basis for the contract itself - therefore must be defined in detail;

• Both these statements may be called requirements.

Types of requirement

• User requirements

o Statements in natural language plus diagrams of the services the system provides and its
operational constraints. Written for customers.

• System requirements

o A structured document setting out detailed descriptions of the system’s functions,

services and operational constraints. Defines what should be implemented so may be
part of a contract between client and contractor.

Requirements Validation

• Concerned with demonstrating that the requirements define the system that the customer
really wants.

• Requirements error costs are high so validation is very important

 o Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.

Functional and non-functional requirements

• Functional requirements

o Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.

o May state what the system should not do.

• Non-functional requirements

o Constraints on the services or functions offered by the system such as timing

constraints, constraints on the development process, standards, etc.

o Often apply to the system as a whole rather than individual features or services.

• Domain requirements

o Constraints on the system from the domain of operation

Functional requirements

• Describe functionality or system services.

• Depend on the type of software, expected users and the type of system where the software is
used.

• Functional user requirements may be high-level statements of what the system should do.

• Functional system requirements should describe the system services in detail.

Non-functional requirements

• These define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.

• Process requirements may also be specified mandating a particular IDE, programming language
or development method.

• Non-functional requirements may be more critical than functional requirements. If these are not
met, the system may be useless.

Requirements specification

• The process of writing down the user and system requirements in a requirements document.

• User requirements have to be understandable by end-users and customers who do not have a
technical background.

• System requirements are more detailed requirements and may include more technical
information.

• The requirements may be part of a contract for the system development

o It is therefore important that these are as complete as possible.

UML Diagram Types

• Activity diagrams, which show the activities involved in a process or in data processing .

• Use case diagrams, which show the interactions between a system and its environment.

• Sequence diagrams, which show interactions between actors and the system and between
system components.

• Class diagrams, which show the object classes in the system and the associations between these
classes.

• State diagrams, which show how the system reacts to internal and external events.

Use case diagram

• Use cases were developed originally to support requirements elicitation and now incorporated
into the UML.

• Each use case represents a discrete task that involves external interaction with a system.

• Actors in a use case may be people or other systems.

• Represented diagramatically to provide an overview of the use case and in a more detailed
textual form.

Activity Diagram

Class diagram
• Class diagrams are used when developing an object-oriented system model to show the classes
in a system and the associations between these classes.

• An object class can be thought of as a general definition of one kind of system object.

• An association is a link between classes that indicates that there is some relationship between
these classes.

• When you are developing models during the early stages of the software engineering process,
objects represent something in the real world, such as a patient, a prescription, doctor, etc.

Sequence diagram

• Sequence diagrams are part of the UML and are used to model the interactions between the
actors and the objects within a system.

• A sequence diagram shows the sequence of interactions that take place during a particular use
case or use case instance.

• The objects and actors involved are listed along the top of the diagram, with a dotted line drawn
vertically from these.

• Interactions between objects are indicated by annotated arrows.

 State diagram

• These model the behaviour of the system in response to external and internal events.

• They show the system’s responses to stimuli so are often used for modelling real-time systems.

• State machine models show system states as nodes and events as arcs between these nodes.
When an event occurs, the system moves from one state to another.

• Statecharts are an integral part of the UML and are used to represent state machine models.