INTRODUCTION

UIIT -UAAR
.

. 1
 SE Project/Assignment
Deliverable #1 (Unmarked):
- - UIIT -UAAR
COMPANY
1) Company Name (of your
newly established
company)
2) Company Logo
TEAM (3-4) Members
Required/Gained capabilities
(Possible Roles)
1) Project Manager
2) (Requirement)
Analyst/Architectet
3) Manager QA
4) Manager SW Testing
5) Manager UI
6) Designer

. 2
 SE Project/Assignments

Assignment #2: Project Proposal (Marked)

PROJECTS MUST BE TAKEN FROM THE EXISTING FYPs

Deadline: -
– Project Title
– Scope
– Objectives
– Problem Statement and Description

. 3
 Definitions

• The application of engineering to software

• Field of computer science dealing with software
systems
– large and complex UIIT -UAAR
– built by teams
– exist in many versions
– last many years
– undergo changes

. 4
 Definitions

• Application of a systematic, disciplined,

quantifiable approach to the development,
operation, and maintenance of software
(IEEE 1990)

• Multi-person construction of multiversion

software (Parnas 1978)

. 5
 Role of software engineer

• Programming skill not enough

• Software engineering involves "programming- in-

the –large"
– understand requirements and write specifications
– derive models and reason about them
– master software
– operate at various abstraction levels
– member of a team
– communication skills
– management skills

UIIT -UAAR

. 6
 Software Myths
Customer Perspectives
– general statement of objectives is sufficient to get started with the
development of software. Missing/vague requirements can easily be
incorporated/detailed out as they get concretized.
 Application requirements can never be stable; software can be and has
to be made flexible enough to allow changes to be incorporated as they
happen.

Customer
Perspectives

Software Developer
Myths Perspectives

Management
Perspectives

. 7
 Software Myths
(Developer Perspectives)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!

UIIT -UAAR
. 8
 Software Myths
(Developer Perspectives -2)

Until the software is coded and is available for testing,

there is no way for assessing its quality.

Usually, there are too many

tiny bugs inserted at every stage
that grow in size and complexity
as they progress thru further
stages!

. 9
 Software Myths
(Developer Perspectives - 3)

The only deliverable for a software development

project is the tested code.

The code is only

the externally visible component
of the entire software
complement!

. 10
 Software Myths
(Management Perspectives - 1)

As long as there are good standards and clear

procedures in my company, I shouldn’t be too
concerned.

But the proof of the pudding

is in the eating;
not in the Recipe !

. 11
 Software Myths
(Management Perspectives -2)

As long as my software engineers(!) have

access to the fastest and the most
sophisticated computer environments and
state-of-the-art software tools, I shouldn’t be
too concerned.
The environment is
only one of the several factors
that determine the quality
of the end software product!

. 12
 Software Myths
(Management Perspectives -3)

When my schedule slips, what I have to do is

to start a fire-fighting operation: add more
software specialists, those with higher skills
and longer experience - they will bring the
schedule back on the rails!
Unfortunately,
software business does not
entertain schedule compaction
beyond a limit!

. 13
 Misplaced Assumptions

• All requirements can be pre-specified

• Users are experts at specification of their
needs
• Users and developers are both good at
visualization
• The project team is capable of
unambiguous communication

Ref: Larry Vaughn

. 14
 Confusion with Programs and Products
Programs Software Products
Usually small in size Large

Author himself is sole Large number of users

user
Single developer Team of developers

Lacks proper user Well-designed interface

interface
Lacks proper Well documented & user-
documentation manual prepared

Ad hoc development Systematic development

. 15
 Software Programming ≠ Software Engineering
• Software programming: the process of translating a
problem from its physical environment into a language that
a computer can understand and obey. (Webster’s New
World Dictionary of Computer Terms)
– Single developer
– “Toy” applications
– Short lifespan
– Single or few stakeholders
– Architect = Developer = Manager = Tester =
Customer = User
– One-of-a-kind systems
– Built from scratch
– Minimal maintenance

. 16
 Software Programming ≠ Software Engineering

Software engineering
– Teams of developers with multiple roles
– Complex systems
– Indefinite lifespan
– Numerous stakeholders
– Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
– System families
– Reuse to amortize costs
– Maintenance accounts for over 60% of overall
development costs

. 17
 INTRODUCTION TO SOFTWARE ENGINEERING
History Of Software Engineering
In the early days of computing, the problem of programming was
viewed essentially as how to place a sequence of instructions together
to get the computer to do something useful.
The problems being programmed were quite well understood- for
example how to solve a differential equation.
The problem was just between the user and the computer – no other
person was involved.
In the late 1950s, higher level languages were invented to make it
easier to communicate with the machine and it was the time when
“programming” attained the status of a profession: you could ask a
programmer to write a program for you instead of doing it yourself.
This introduced a separation between the user and computer.
 Now the user has to specify the task in a form other than the precise
programming notation used before.
Very few larger software projects were being done in the early 1960s
and these were done by computer pioneers who were experts.

. 18
  In the middle to late 1960s, truly large software systems were
attempted commercially. The best documented of these projects was
the OS 360 operating system for the IBM 360 computer family.
 The term Software Engineering was invented around this time and
conferences were held to discuss the difficulties these projects were
facing in delivering the promised products.
 It was discovered that the problems in building the large software
systems were not a matter of putting computer instructions together
rather:
 People on the project had to spend a lot of time communicating with
each other rather than writing code.
 People sometimes even left the project, and this not only affected their
work but also the work of the others who were depending on them.
 Many solutions were proposed and tried. Some suggested that the
solution lay in better management techniques.
 Other proposed different team organizations. Yet other argued for
better languages and tools.

. 19
 • The final consensus was that the problem of building software
should be approached in the same way that engineers had built
other large complex systems such as bridges, refineries,
factories, ships and airplanes.
• The engineering approach required management, organization,
tools, methodologies and techniques. And thus was software
engineering born.

. 20
 WHAT IS SOFTWARE ENGINEERING?

 The term S/W Engineering was/is sometimes confusing, firstly because

S/W engineer (some times) work as system programmer, people assume
that the engineering component of the term comes from this source. SO we
have H/W engg and S/W engg.
 Second cause of confusion lies in the fact that there is no generally agreed
definition of software engineering, although many are similar.
 Software Engineering as a term was first coined in 1968 at a NATO
conference in West Germany held to discuss the software crises
 Other definitions such as Fairley’s 1985 explicitly include the concerns of
management in the software development process:
‘Software engineering is the technological and managerial
discipline concerned with systematic production and maintenance
of software products that are developed and modified on time and
within cost estimates.’

. 21
 What is Software Engineering? (2)

"The establishment and use of sound engineering

principles (methods) in order to obtain economically
software that is reliable and works on real machines"
[Bauer 1972].

"cost-effective Software engineering is that form of

engineering that applies the principles of computer science
and mathematics to achieving solutions to software
problems.“ [CMU/SEI-90-TR-003]

"The application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance
of software" [IEEE Standard Computer Dictionary, 610.12,
ISBN 1-55937-079-3, 1990].

. 22
 What is Software Engineering? (3)

 Software engineering is concerned with the theories,

methods and tools for developing, managing and evolving
software products. [ I. Sommerville, 6ed.]
 A discipline whose aim is the production of quality
software, delivered on time, within budget, and satisfying
users' needs. (Stephen R. Schach, Software Engineering,
2ed.)
 The practical application of scientific knowledge
in the design and construction of computer
programs and the associated documentation
required to develop, operate and maintain them
[B.W. Boehm]
 Multi-person construction of multi-version software
(Parnas, 1987)

. 23
 What is Software Engineering? (4)

• Software Engineering 2004 (SE2004)

Curriculum Guidelines for Undergraduate Degree
Programs in Software Engineering. A Volume of
the Computing Curricula Series

The Joint Task Force on Computing Curricula

IEEE Computer Society
Association for Computing Machinery

• Guide to the Software Engineering

Body of Knowledge
2004 Version
SWEBOK®
A project of the IEEE Computer Society
Professional Practices Committee

. 24
 So, Software Engineering is …

• Scope
– study of software process, development
principles, techniques, and notations
• Goals
– production of quality software,
– delivered on time,
– within budget,
– satisfying customers’ requirements and
users’ needs

. 25
 The Role/Scope Of S/W Engineering In System Design

 A software system is often a component of a much larger system.

 The software engineering activity is therefore a part of a much

larger system design activity in which the requirements of the
software are balanced against the requirements of other parts of
the system being designed.*
 For Example, A requirement such as “the system must not be down
for more than a second in 20 years” or “when a receiver is taken off-
hook, a dial tone is played within half a second” can be satisfied
with a combination of hardware, software and special devices.
 A trade off is required as what should be done in software and what
should be done in hardware. Software implementation offers
flexibility, while hardware implementation offers performance.$

. 26
 The Role/Scope Of S/W Engineering In System Design (ctd.)

 To do software engineering right, requires a broader look at the

general problem of system engineering. It requires software
engineer to be involved when requirements are being developed
initially for the whole system.

 It requires that software engineer attempt to understand the

application area rather than just what abstract interfaces the
software must meet.

. 27
 Knowledge Spectrum

Social Issues
Politics
& Law

Psychology
& Sociology
Economics

Solutions
Theory

Engineering Engineering Engineering Production

Science Installation
Science Design Technology

Industrial
Design

Architecture

Arts
Human factors
. 28
 A Computing Spectrum

Social Issues
Politics
& Law

Psychology
• Algorithms
• Information theory & Sociology • Development Environment
• Computability theory • Implementation Standards
Economics

Solutions
Theory

Engineering Engineering Engineering Production

Science
Science Design Technology Installation

Industrial
Design
• Analysis & • System
• System Software Architecture Design Methods Administration
• Computer Architecture • Design Process • End-user Support
• Information storage • Measurements
Arts
Human factors
. 29
 Computing Professions
Social Issues
•Creates new applications Politics
applying engineering principles & Law Information Systems Practitioner
and CS best practices
•Creates business solutions
Psychology
Software Engineer
& Sociology
Economics

Solutions
Theory

Engineering Engineering Engineering Production

Science Installation
Science Design Technology

Industrial
Computer Scientist Design Information Technologist
Architecture
•Provides end-user solutions
•Creates New Infrastructure
Arts
Human factors

. 30
 THE RELATIONSHIP OF SOFTWARE ENGINEERING TO
OTHER AREAS OF COMPUTER SCIENCE
[Carlo Ghezzi]
Influence on Programming Language
Team Development
inclusion of modularity features, such as separate and independent
compilation, and the separation of specification from implementation,
in order to support decomposition and large software.

Library of Components
The Ada programming language, for example, supports the
development of “Package”- allowing the separation of the package
interface from its implementation- and libraries of packages that can be
used as component in the development of independent software system.
Recent examples …...classes, patterns, components…

. 31
 In the opposite direction, programming languages have influenced
software engineering. One example is the idea that requirements and
design should be described precisely, possibly using a language as
rigorous and machine-processable as a programming language.
Influence On Operating System
can be seen the way operating systems are structured and the goals they
try to satisfy. For example, the UNIX operating system attempts to provide
a productive environment for software development. A class of tools
provided in this environment supports configuration management-a way
to maintain and control the relationships among the different components
and versions of a software system (SCCS: Source Code Control System!).
Further LEX, YACC etc [1980’s]
In the opposite direction, Virtual machines, levels of
abstraction, and separation of policy from mechanism are all
concepts from operating system field with general applicability to
any large software system.
. 32
 Database
 The database allows applications to be written that
use data without worrying about the underlying
representation of the data. This independence allows
the database to be changed in certain ways (e.g. to
increase the performance of the system-without any
need to change the applications). This is a perfect
example of the benefit of abstraction and separation of
concerns, two key software engineering principles.
 SE requires Now OO data bases

 influence of the database field on SE is through the

notion of “data independence”.

. 33
 Artificial intelligence
SE techniques have been used in AI systems – e.g. in
expert systems. These systems are modularized, with a
clear separation between the fact “known” by the expert
system and the rules used by the system for processing the
fact-for example, a rule to decide on a course of action.
Techniques of AI are being applied to improve software
engineering tasks. For example, “programming
assistants” are being developed to act as consultants to
the programmer, watching for common programming
idioms or the system requirements. Such “assistants” are
also being developed to help in the testing activities of the
software development, to debug the software.
. 34
 Theoretical models
• SE has also affected theoretical computer science.
Algebraic specification and abstract data type theory
are motivated by the needs of SE.
Management science
• A large part of software engineering is involved with
management issues. Such management has two aspects:
technical management and personnel management. The
generic issues project management include project
estimation, project scheduling, human resource planning,
task decomposition and assignment, and project
monitoring.
• SE has provided management science with a new
domain/challenges in which to test management theories and
models.
. 35
 S/W CHARACTERISTICS

• Software is developed or engineered, it is

not manufactured in the classical sense.
• Software doesn’t wear out
• Software is complex
• Software is like an ‘aging factory’
• Industry is moving towards component-
based assembling, most software is
custom built.

. 36
 Wear vs. Deterioration

increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

. 37
 Future of SE …
• Process • Software analysis
• Requirements engineering • Formal specification
• Reverse engineering • Mathematical foundations
• Testing • Reliability and Dependability
• Maintenance and Evolution • Performance
• Software architecture • SE for Safety
• SE for security
• OO Modeling
• SE for mobility
• SE and Middleware
• SE & the Internet
• Tools and environments
• Software economics
• Configuration management • Empirical studies of SE
• (OO) Databases and SE • Software metrics
• SE Education

. 38
 Software Engineering Principles

• Principles form the basis of methods,

techniques, methodologies and tools
• Seven important principles that may be
used in all phases of software
development
• Apply to the software product as well as
the development process

. 39
 Key principles

1. Rigor and formality

2. Separation of concerns
3. Modularity
4. Abstraction
5. Anticipation of change
6. Generality
7. Incrementality

. 40
 1. Rigor and formality

• Software engineering is a creative

design activity, BUT It must be
practiced systematically
• Rigor is a necessary complement
to creativity that increases our
confidence in our developments
• Formality is rigor at the highest
degree

. 41
 Examples: Rigor and formality
• Product:
– Formal-Mathematical analysis of program
correctness
– Rigorous-Systematic test data derivation
• Process:
– Rigorous- detailed documentation of each
development step in waterfall model
– Formal- automated transformational
process to derive program from formal
specifications
. 42
 2. Separation of concerns
• To dominate complexity, separate the
issues to concentrate on one at a time
– "Divide & conquer"
• Supports parallelization of efforts and
separation of responsibilities

. 43
 Separation of concerns
Examples:
– Process: Go through phases one after the
other as in waterfall Model
–Does separation of concerns by separating
activities with respect to time
– Product: Keep different types of product
requirements separate
–Functionality discussed separately from the
performance constraints

. 44
 3. Modularity
• A complex system may be divided into
simpler pieces called modules

• A system that is composed of modules is

called modular

• Supports application of separation of

concerns
– when dealing with a module we can ignore
details of other modules

. 45
 Modularity: Cohesion and coupling

• Each module should be highly cohesive

– module understandable as a meaningful unit
– Components of a module are closely related to
one another

• Modules should exhibit low coupling

– modules have low interactions with others
– understandable separately

. 46
 An Example

. 47
 4. Abstraction
• Identify the important aspects of a
phenomenon and ignore its details
– Special case of separation of concerns
– The type of abstraction to apply
depends on purpose
• Example: the user interface of a watch
(its buttons) abstracts from the watch's
internals for the purpose of setting time;
other abstractions needed to support
repair
. 48
 Abstraction ignores details

• Example: equations describing

complex circuit (e.g., amplifier) allows
designer to reason about signal
amplification
• Equations may approximate
description, ignoring details that yield
negligible effects (e.g., connectors
assumed to be ideal)

. 49
 Abstraction yields models

• For example, when requirements are

analyzed we produce a model of the
proposed application

• The model can be a formal or

semiformal description

• It is then possible to reason about the

system by reasoning about the model

. 50
 Abstraction in process

• When we do cost estimation we

only take some key factors into
account

• We apply similarity with previous

systems, ignoring detail
differences

. 51
 5. Anticipation of change

• Ability to support software

evolution requires anticipating
potential future changes

–It is the basis for software

evolvability

. 52
 6. Generality
• While solving a problem, try to
discover if it is an instance of a more
general problem whose solution can
be reused in other cases
• Sometimes a general problem is
easier to solve than a special case
–Carefully balance generality against
performance and cost

. 53
 7. Incrementality
• Process proceeds in a stepwise fashion
(increments)
• Examples (process)
– deliver subsets of a system early to get
early feedback from expected users,
then add new features incrementally
– deal first with functionality, then turn to
performance

. 54
 Case study: compiler
• Compiler construction is an
area where systematic (formal)
design methods have been
developed
–e.g., BNF for formal description
of language syntax

. 55
 Separation of concerns example

• When designing optimal register

allocation algorithms (runtime
efficiency) no need to worry about
runtime diagnostic messages (user
friendliness)

. 56
 Modularity

• Compilation process decomposed

into phases
– Lexical analysis
– Syntax analysis (parsing)
– Code generation
• Phases can be associated with
modules

. 57
 Representation of modular structure

. 58
 Module decomposition may be
iterated
• further modularization of code-generation module

. 59
 Abstraction

• Applied in many cases

– abstract syntax to neglect syntactic
details such as begin…end vs. {…} to
bracket statement sequences
– intermediate machine code (e.g.,
Java Bytecode) for code portability

. 60
 Anticipation of change

• Consider possible changes of

–source language (due to
standardization committees)
–target processor

. 61
 Generality

• Parameterize with respect to

target machine (by defining
intermediate code)
• Develop compiler generating
tools (compiler compilers)
instead of just one compiler

. 62
 Incrementality

• Incremental development
–deliver first a kernel version for a
subset of the source language, then
increasingly larger subsets
–deliver compiler with little or no
diagnostics/optimizations, then add
diagnostics/optimizations

. 63