Software Engineering

Introduction To Software
Engineering
By. Mohamed Essam

Software
Software is Almost
Everywhere.

Software Engineering
Software engineering is concerned with theories, as well as
methods and tools for professional software
development.

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

Ariane 5 Flight 501
Cause: design errors in the software

Software Engineering
It is not enough to do your best: you must
Know what to do, and THEN do your best.
-- W. Edwards Deming

Professional software development

Software Development Process Models

Frequently asked questions about software
engineering
•Computer programs and associated documentation.
Software products may be developed for a particular
customer or may be developed for a general market.
What is software?
•Good software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable.
What are the attributes of good
software?
•Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What is software engineering?
•Software specification, software development, software
validation and software evolution.
What are the fundamental
software engineering activities?
•Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of
developing and delivering useful software.
What is the difference between
software engineering and
computer science?
•System engineering is concerned with all aspects of
computer-based systems development including hardware,
software and process engineering. Software engineering is
part of this more general process.
What is the difference between
software engineering and system
engineering?

• Coping with increasing diversity, demands for reduced
delivery times and developing trustworthy software.
What are the key challenges facing
software engineering?
• Roughly 60% of software costs are development costs,
40% are testing costs. For custom software, evolution
costs often exceed development costs.
What are the costs of software
engineering?
• While all software projects have to be professionally
managed and developed, different techniques are
appropriate for different types of system. For example,
games should always be developed using a series of
prototypes whereas safety critical control systems require
a complete and analyzable specification to be developed.
You can’t, therefore, say that one method is better
than another.
What are the best software
engineering techniques and
methods?
• The web has led to the availability of software services
and the possibility of developing highly distributed
service-based systems. Web-based systems
development has led to important advances in
programming languages and software reuse.
What differences has the web
made to software engineering?

Software products
Generic products
Stand-alone systems that are marketed and sold to any customer
who wishes to buy them.
Examples – PC software such as graphics programs, project
management tools; CAD software; software for specific markets
such as appointments systems for dentists.
Customized products
Software that is commissioned by a specific customer to meet their
own needs.
Examples – embedded control systems, air traffic control software,
traffic monitoring systems.

Product specification
Generic products specification
The specification of what the software should do is owned by the
software developer and decisions on software change are made
by the developer.
Customized products specification
The specification of what the software should do is owned by the
customer for the software and they make decisions on software
changes that are required.

Essential attributes of good software
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
security
•Software
dependability
includes a range of
characteristics
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.

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.

Importance of software engineering
 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.

Software process activities
Software
specificati
on
•where customers and engineers define the software that is to be produced and the constraints on its operation.
Software
developm
ent
•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.

General issues that affect software
Heterogeneity
Increasingly, systems are required to operate as distributed systems across
networks that include different types of computer and mobile devices.
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.

General issues that affect software
Security and trust
As software is intertwined with all aspects of our lives, it is essential that we
can trust that software.
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 engineering diversity
There are many different types of software system and there is no
universal set of software techniques that is 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.

Application types
Stand-alone applications
These are application systems that run on a local computer, such as a PC. They
include all necessary functionality and do not need to be connected to a
network.
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 such as e-
commerce applications.
Embedded control systems
These are software control systems that control and manage hardware devices.
Numerically, there are probably more embedded systems than any other type
of system.

Application types
Batch processing systems
These are business systems that are designed to process data in large
batches. They process large numbers of individual inputs to create
corresponding outputs.
Entertainment systems
These are systems that are primarily for personal use and which are
intended to entertain the user.
Systems for modeling and simulation
These are systems that are developed by scientists and engineers to
model physical processes or situations, which include many,
separate, interacting objects.

Application types
Data collection systems
These are systems that collect data from their environment using a set of sensors
and send that data to other systems for processing.
Systems of systems
These are systems that are composed of a number of other software systems.

Software engineering fundamentals
Some fundamental principles apply to all types of software system,
irrespective of the development techniques used:
Systems should be developed using a managed and understood
development process. Of course, different processes are used for
different types of software.
Dependability and performance are important for all types of system.
Understanding and managing the software specification and
requirements (what the software should do) are important.
Where appropriate, you should reuse software that has already been
developed rather than write new software.

Software Engineering And WEB
The Web is now a platform for running application and organizations are
increasingly developing web-based systems rather than local
systems.
Web services allow application functionality to be accessed over the web.
Cloud computing is an approach to the provision of computer services
where applications run remotely on the ‘cloud’.
Users do not buy software buy pay according to use.

Web-based software engineering
Web-based systems are complex distributed systems but the fundamental
principles of software engineering discussed previously are as applicable
to them as they are to any other types of system.
The fundamental ideas of software engineering apply to web-based
software in the same way that they apply to other types of software
system.

Software reuse
Software reuse is the dominant approach for constructing web-based systems. When
building these systems, you think about how you can assemble them from pre-
existing software components and systems.
Incremental and agile development
Web-based systems should be developed and delivered incrementally. It is now
generally recognized that it is impractical to specify all the requirements for such
systems in advance.

Service-oriented systems
Software may be implemented using service-oriented software engineering, where the
software components are stand-alone web services.
Rich interfaces
User interfaces are constrained by the capabilities of web browsers.
Technologies such as AJAX and Bootstrape allow rich interfaces to be created within a
web browser but are still difficult to use. Web forms with local scripting are more
commonly used.

Case studies
A personal insulin pump
An embedded system in an insulin pump used by diabetics to maintain blood glucose
control.
A mental health case patient management system
Mentcare. A system used to maintain records of people receiving care for mental health
problems.
A wilderness weather station
A data collection system that collects data about weather conditions in remote areas.

The software process
A structured set of activities required to develop a software system.
Many different software processes but all involve:
Specification – defining what the system should do;
Design and implementation – defining the organization of the system and
implementing the system;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing customer needs.
A software process model is an abstract representation of a process.
It presents a description of a process from some particular perspective.

The software process
 Plan Driven Development : Water Fall Model
 Incremental Developement or RAD:
 Incremental Model
 ProtoType Model
 Reusabilty Development: Reuse oriented Model
 Agile Development : Extreme programming model

Plan-driven and Agile processes
Plan-driven processes are processes where all of the process
activities are planned in advance and progress is measured against
this plan.
In RAD and Agile processes, planning is incremental and it is easier
to change the process to reflect changing customer requirements.
In practice, most practical processes include elements of both plan-
driven and agile approaches.
There are no right or wrong software processes.

The waterfall model
 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.

The waterfall model
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, that needs well planning .
In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.

Rapid software development
 Rapid development and delivery is now often the most important
requirement for software systems
Businesses operate in a fast –changing requirement and it is practically impossible
to produce a set of stable software requirements
Software has to evolve quickly to reflect changing business needs.
 Rapid software development
Specification, design and implementation are inter-leaved
System is developed as a series of versions with stakeholders involved in version
evaluation
User interfaces are often developed using an IDE and graphical toolset

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;

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.

Iteration vs Increment
When discussing iterative and incremental development, the terms iteration and
increment are often used freely and interchangeably. However, They are NOT
synonyms.
Iteration refers to the cyclic nature of a process in which activities are repeated in a
structured manner.
Increment refers to the quantifiable outcome of each iteration.

Reuse-Oriented Software Engineering
(Integration and configuration)
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

Types of reusable software
Web services that are developed according to service standards and which are
available for remote invocation.
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.

Reuse-oriented software engineering

Process activities
 Real software processes are inter-leaved sequences of technical,
collaborative and managerial activities with the overall goal of
specifying, designing, implementing and testing a software system.
 The four basic process activities of specification, development,
validation and evolution are organized differently in different
development processes.
 For example, in the waterfall model, they are organized in
sequence, whereas in incremental development they are
interleaved.

1. Software Specifications
(Analysis)

Software specification
 Software Requirements
Description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product.
The requirements can be obvious or hidden, known or unknown, expected or
unexpected from client’s point of view.
 Requirement Engineering
The process to gather the software requirements from client, analyze and
document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain
sophisticated and descriptive SRS ‘System Requirements Specification’
document.

Requirements Engineering
Requirements engineering process:
A. Requirements elicitation and analysis
What do the system stakeholders require or expect from the
system?
B. Requirements specification
Defining the requirements in detail “output SRS sheet”
C. Requirements validation
Checking the validity of the requirements

A. Requirements Elicitation
Requirements elicitation “Not Gathering” and analysis:
What do the system stakeholders require or expect from the
system?

Requirement Elicitation Process
Requirements Elicitation
the process to find out the requirements for an intended software system by
communicating with client, end users, system users and others who have a
stake in the software system development.
Requirement elicitation process can be depicted using the following
diagram:

Requirement Elicitation Process (Cont.)
Requirements gathering - The developers discuss with the client and end users
and know their expectations from the software.
Organizing Requirements - The developers prioritize and arrange the
requirements in order of importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, if they are, it is then negotiated
and discussed with stakeholders. Requirements may then be prioritized and
reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements
are compromised reasonably.
Documentation - All formal & informal, functional and non-functional requirements
are documented and made available for next phase processing.

Requirements Elicitation Techniques:
Brainstorming
Document Analysis
Focus Groups
Interviews
Observation
Prototyping
Survey/Questionnaire

Interviews
Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
Structured (closed) interviews, where every single information to gather is
decided in advance, they follow pattern and matter of discussion firmly.
Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
Oral interviews
Written interviews
One-to-one interviews which are held between two persons across the table.
Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.

Surveys
Organization may conduct surveys among various stakeholders by querying about
their expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in
the questionnaire, the issue might be left unattended.
Task “Document” analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain
operation, it is studied and requirements of proposed system are collected.

Domain Analysis “Focus Group”
Every software falls into some domain category. The expert people in the domain
can be a great help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
Observation
Team of experts visit the client’s organization or workplace. They observe the
actual working of the existing installed systems. They observe the workflow at
client’s end and how execution problems are dealt. The team itself draws some
conclusions which aid to form requirements expected from the software.

Prototyping
Prototyping is building user interface without adding detail functionality for user to
interpret the features of intended software product.
It helps giving better idea of requirements. If there is no software installed at
client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned
requirements.
The prototype is shown to the client and the feedback is noted. The client
feedback serves as an input for requirement gathering.

Requirement Specification Sheet:
SRS is a document created by system analyst after the requirements are collected
from various stakeholders.
SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software
across various platforms, maintainability, speed of recovery after crashing,
Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the
responsibility of system analyst to document the requirements in technical
language so that they can be comprehended and useful by the software
development team.

SRS should come up with following features:
User Requirements are expressed in natural language.
Technical requirements are expressed in structured language, which is used
inside the organization.
Design description should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.

Software Requirement Validation
Software Requirement Validation:
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts
may interpret the requirements incorrectly.
Requirements can be checked against following conditions -
If they can be practically implemented
If they are valid and as per functionality and domain of software
If there are any ambiguities
If they are complete
If they can be demonstrated

Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software
development project. Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
Clear
Correct
Consistent
Coherent
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source

Broadly software requirements should be categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of software fall into this
category.
They define functions and functionality within and from the software system.
EXAMPLES -
Search option given to user to search from various invoices.
User should be able to mail any report to management.
Users can be divided into groups and groups can be given separate rights.
Should comply business rules and administrative functions.
Software is developed keeping downward compatibility intact.

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users
make assumption of.
Non-functional requirements include -
Security
Logging
Storage
Configuration
Performance

Requirements are categorized logically as
Must Have : Software cannot be said operational without them.
Should have : Enhancing the functionality of software.
Could have : Software can still properly function with these requirements.
Wish list : These requirements do not map to any objectives of software.
While developing software, ‘Must have’ must be implemented, ‘Should have’ is a
matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish
list’ can be kept for software updates.

2. Software Design & Implementation

Software Development
(Design and Implementation)
The process of converting the system specification into an executable system.
Software design:
Design a software that meets the specification;
Implementation:
Translate this structure into an executable program;
The activities of design and implementation are closely related and may be inter-
leaved.

Software design is a process to transform user requirements into some suitable
form, which helps the programmer in software coding and implementation.
For assessing user requirements, an SRS SoftwareRequirementSpecification
document is created whereas for coding and implementation, there is a need of
more specific and detailed requirements in software terms. The output of this
process can directly be used into implementation in programming languages.
Software design is the first step in SDLC SoftwareDesignLifeCycle, which moves
the concentration from problem domain to solution domain. It tries to specify how
to fulfill the requirements mentioned in SRS.

Software design yields three levels of results:
Architectural Design: The architectural design is the highest abstract version of the system. It
identifies the software as a system with many components interacting with each other. At this
level, the designers get the idea of proposed solution domain.
High-level Design: The high-level design breaks the ‘single entity-multiple component’ concept
of architectural design into less-abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the system along with all of its
components can be implemented in forms of modules. It recognizes modular structure of each
sub-system and their relation and interaction among each other.
Detailed Design: Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards modules
and their implementations. It defines logical structure of each module and their interfaces to
communicate with other modules.

Architectural design, where you identify the overall structure of the
system, the principal components (subsystems or modules), their
relationships and how they are distributed.
Database design, where you design the system data structures and
how these are to be represented in a database.
Interface design, where you define the interfaces between system
components.
Component selection and design, where you search for reusable
components. If unavailable, you design how it will operate.

A use case
A use case is a methodology used in system analysis to identify, clarify
and organize system requirements. The use case is made up of a set of
possible sequences of interactions between systems and users in a
particular environment and related to a particular goal. The method
creates a document that describes all the steps taken by a user to
complete an activity.
Business analysts are typically responsible for writing use cases and
they are employed during several stages of software development, such
as planning system requirements, validating design, testing software
and creating an outline for online help and user manuals. A use case
document can help the development team identify and understand
where errors may occur during a transaction so they can resolve them.

A use case
Every use case contains three essential elements:
The actor. The system user -- this can be a single person or a group of people
interacting with the process.
The goal. The final successful outcome that completes the process.
The system. The process and steps taken to reach the end goal, including the
necessary functional requirements and their anticipated behaviors.

ERD
An entity relationship diagram (ERD), also known as an entity relationship model,
is a graphical representation that depicts relationships among people,
objects, places, concepts or events within an information technology (IT)
system.

3. Software Verification & Validation
(V & V)
Verification:
"Are we building the product right”?
The software should conform to its specification and it is “error free”.
Validation:
"Are we building the right product”?!
The software should do what the user really requires.

(V & V)

(V & V)
Development or Component “Unit” 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 “Acceptance” testing
Testing with customer data to check that the system meets the
customer’s needs.

4. Software evolution
Software is flexible and can change.
As requirements change through changing business circumstances, the
software that supports the business must also evolve and change.
Although there has been a demarcation between development and
evolution (maintenance) this is increasingly irrelevant as fewer and fewer
systems are completely new.

Any Questions?
Mohamed Essam
!

CREDITS: This presentation template was created by Slidesgo,
including icons by Flaticon, and infographics & images by Freepik
THANKS!
Contacts
Mhmd96.essam@gmail.com
Please keep this slide for attribution

Software Engineering

More Related Content

What's hot (20)

Similar to Software Engineering (20)

More from Mohamed Essam (20)

Recently uploaded (20)

Software Engineering