Lecture 1

Introduction
to Software
Engineering

1
Topics covered

SOFTWARE SOFTWARE COPING WITH

ENGINEERING PROCESSES MODEL CHANGES

2
 1.1
Software
engineering

3
Software engineering
• 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.

4
Importance of software engineering
• More and more, individuals and society rely on
advanced software systems. We need to be able to
produce reliable systems 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.

5
The software process
• A software process model is an abstract representation
of a process. It presents a description of a process
from some particular perspective.
• Many different software processes but all involve:

Software Software Software Software

Specification Development Validation Evolution

6
 Software Specification

• Customers and engineers define the

software that is to be produced and the
constraints on its operation.

Software Development
Software • The software is designed and

process
programmed.

Software Validation
activities • Software is checked to ensure that it is
what the customer requires.

Software Evolution

• Software is modified to reflect changing

customer and market requirements.

7
Essential attributes of good software

Product characteristic Description

Maintainability Software should be written in such a way so that it can evolve to
meet the changing needs of customers. This is a critical attribute
because software change is an inevitable requirement of a
changing business environment.

Dependability and Software dependability includes a range of characteristics

security including reliability, security and safety. Dependable software
should not cause physical or economic damage in the event of
system failure. Malicious users should not be able to access or
damage the system.

Efficiency Software should not make wasteful use of system resources such
as memory and processor cycles. Efficiency therefore includes
responsiveness, processing time, memory utilisation, etc.
Acceptability Software must be acceptable to the type of users for which it is
designed. This means that it must be understandable, usable and
compatible with other systems that they use.

8
 1.2
Software
process model

9
Software process models
• A software process model is an abstraction of a
software process.
• Activities of a software process are complex.
• It represents a process from particular perspective.
• “Abstraction” also means partial information about that
process is offered.
• Ex: A process model doesn’t show roles of the people
involved in this process.

10
Software process 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.

11
The waterfall model

12
Waterfall model problems
• The main drawback of the waterfall model is the
difficulty of accommodating change after the process is
ongoing. In principle, a phase has to be completed
before moving onto the next phase.
• 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.

13
Waterfall model problems
• 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.

14
Incremental development
• This development is based on the idea of developing
an initial implementation, exposing this to user
comment and evolving it through several versions until
an adequate system has been developed.
• Specification, development, and validation activities are
interleaved rather than separate.
• Rapid feedback across activities.
• It is a fundamental part of agile approaches.
• It is better than a waterfall approach for most business,
e-commerce, and personal systems.

15
Incremental development

16
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.

17
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.
• Incremental development become particularly difficult
for large, complex, long-lifetime systems.
• Different teams develop different parts of the system.
• A large system has to be planned in advance rather than
developed incrementally.

18
Reuse-oriented software engineering
• Based on software reuse where systems are integrated
from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf)
systems).
• Reused elements may be configured to adapt their
behaviour and functionality to a user’s requirements
• Reuse is now the standard approach for building many
types of business system

19
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.

20
Key process stages
• Requirements specification
• Software discovery and evaluation
• Requirements refinement
• Application system configuration
• Component adaptation and integration

21
Key process stages

22
Advantages and disadvantages
• Reduced costs and risks as less software is developed
from scratch
• Faster delivery and deployment of system
• But requirements compromises are inevitable so
system may not meet real needs of users
• Loss of control over evolution of reused system
elements

23
 Software prototyping
• A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
• A prototype can be used in:
• The requirements engineering process to help with
requirements elicitation and validation;
• In design processes to explore options and develop a UI
design;
• In the testing process to run back-to-back tests.
• Back-to-back testing: all versions of software applications
are tested with similar set of tests and then the results are
always compared for some system / application problems, if
any issue exists.

24
Low- and High-fidelity prototypes

25
Low-fidelity prototype
• Also called as “sketches”
• Not meant to look all that much like the final product.
• Using pencil and papers, whiteboards, flip charts, post-it note
and so on.
• Help stakeholders concentrate on the subject matter.
• Elicit ideas from the stakeholders.
• Your aim is to uncover the existing requirements that
must be carried forward into the new product.
• Sketching this prototype as quick as possible.

26
High-fidelity prototypes
• Built by using software tools
• Have the appearance of working software products.
• The stakeholders have the chance to simulate a
realistic-looking product
• They can check whether the product displays the correct
requirements

27
Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.

28
 1.3
Coping with
change

29
Coping with change
• Change is inevitable in all large software projects.
• Business changes lead to new and changed system
requirements
• New technologies open up new possibilities for improving
implementations
• Changing platforms require application changes
• Change leads to rework so the costs of change include
both rework (e.g. re-analyzing requirements) as well as
the costs of implementing new functionality

30
Coping with changing requirements
• Software prototyping, where a version of the system
or part of the system is developed quickly to check the
customer’s requirements and the feasibility of design
decisions. This approach supports change avoidance.
• Incremental development, where system increments
are delivered to the customer for comment and
experimentation. This supports both change avoidance
and change tolerance.

31