Chapter One
Chapter One
1
History
Software engineering has evolved steadily from its
founding days in the 1940s until today in the 2000s.
2
1945 to 1965: The Origins
The term software engineering first was used in the
late 1950s and early 1960s.
4
Cost and Budget Overruns: The OS/360 operating
system was a classic example.
5
Property Damage: Software defects can cause property
damage.
6
Life and Death: Software defects can kill.
Some embedded systems used in radiotherapy
machines failed so catastrophically that they
administered lethal doses of radiation to patients.
Peter G. Neumann keeps a contemporary list of
software problems and disasters at Computer Risks.
The software crisis has been slowly fizzling out,
because it is unrealistic to remain in crisis mode for
more than twenty years.
SEs are accepting that the problems of SE are truly
difficult and only hard work over many decades can
solve them.
7
1985 to Present: No Silver Bullet
8
Tools: Especially emphasized were tools.
Structured programming, object-oriented
programming, CASE tools, Ada, documentation,
standards, and UML were touted as silver bullets.
Discipline: Some pundits argued that the software
crisis was due to the lack of discipline of programmers.
Formal methods: Some believed that if formal
engineering methodologies would be applied to
software development, then production of software
would become as predictable an industry as other
branches of engineering. They advocated proving all
programs correct.
Process: Many advocated processes and
methodologies like CMM.
Professionalism: This led to work on a code of ethics,
licenses and professionalism.
9
Major Developments
There are a numbers of areas where the evolution of
software engineering is notable.
10
Role of women:
In the 1940s, 1950s, and 1960s, software was often written by
women.
Men often filled the highest prestige hardware engineering roles.
Grace Hopper and many other unsung women filled many
programming jobs during the first several decades of software
engineering.
Today, fewer women work in software engineering than in other
professions. Saying that this is sexual discrimination is too
simple because it related directly to individual identity.
In one sense, software engineering is the masculinization of
programming.
The roles women fill in SE continue evolving.
Today, more women in software engineering fill the social roles
of analysis, training, documentation and management; and
fewer do hardcore technical development.
11
Software is more than just a program code.
12
Engineering on the other hand, is all about
developing products, using well-defined, scientific
principles and methods.
13
IEEE defines software engineering as:
(1) The application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software; that is,
the application of engineering to software.
Tools
CASE tools (e.g., Visio, ArgoUML, and Rational Rose) to assist
in application of techniques to the analysis and design process
15
Major problems in software developments …
18
Custom Information System
Custom Information System is an information system
that has been developed for one specific client
Stakeholders
Client: the one who is paying for the information system
to be developed
Users: future users of the information system
Developers: those who build the information system
19
COTS Software
COTS (Commercial Off-The-Shelf) packages provide
functionality that meets the needs of many users
Stakeholders
Users
Developers
20
Enterprise Resource Planning (ERP)
System
Enterprise Resource Planning (ERP) system integrate
business functions into modules enabling a single seamless
transaction to cut across functional boundaries
Examples: PeopleSoft, SAP
21
Open Source System
Open Source Systems are freely available (most of the
time including source code)
Developed by a community of interested people
Performs the same functions as commercial software
Examples: Linux, mySQL, Firefox
22
Software Development Life Cycle
Software Development Life Cycle, SDLC for short, is a
well-defined, structured sequence of stages in software
engineering to develop the intended software product.
23
Basic Problem Solving Flow
WHAT
HOW
DO
TEST
USE
24
Development Process
Commonly has these activities:
1. Requirements analysis,
2. Design
3. Coding,
4. Testing,
5. Maintenance
Software Process 25
1. Requirement Analysis
State the problem precisely!
Forms the basis of agreement between user and
developer
Specifies “what” not “how”
Hard task - needs often not understood well
Requirement specifications of even medium
systems can be many hundreds of pages
Output is the SW Requirements Spec (SRS)
document
Software Process 26
2. Design
A major step in moving from problem domain
to solution domain
Three main tasks
1. Architecture design – components and connectors
that should be there in the system
2. High level design – modules and data structures
needed to implement the architecture
3. Detailed design – logic of modules
Most methodologies focus on architecture or
high level design
Outputs are arch/des/logic design docs
Software Process 27
3) Coding
Converts design into code in specific language
Goal: Implement the design with simple and
easy to understand code
Software Process 28
4) Testing & Quality Assurance
Defects are introduced in each phase
Must be found and removed to achieve high
quality
Goal: Identify most of defects
Very expensive task; must be properly planned
and executed
Outputs are
Test plans/results, and
the final tested (hopefully reliable) code
Software Process 29
5) Maintenance
Modify the system
Remove any remaining faults
Correcting mistake
Extend (Upgrade) the system in some way
30
Financial implications of Maintenance
For very 1 Birr spent on development, at least
2 Birr is spent on maintenance
31
Maintenance Activities
There are three main maintenance activities:
Corrective maintenance
Fixing faults
Perfective maintenance
Adding functionality
Adaptive maintenance
Making changes because the environment changes
32
Why there is No Planning phase
We cannot plan until we have accurate, detailed
information
33
Cont’d
Planning activities are carried out through all the life cycle
34
Why there is No Documentation phase
35
Software Process Model
A (software/system) process model is a description of
the sequence of activities carried out in a SE project,
and the relative order of these activities.
36
There are hundreds of different process models to
choose from, e.g:
• waterfall,
• code-and-fix
• spiral
• rapid prototyping
• V-shaped
• agile methods, extreme programming (XP)
• COTS …
SW developers select among various process models
regarding the character of the particular SW system they
are to develop.
37
The Waterfall Model
The waterfall model is the classic process model – it is
widely known, understood and used.
All the phases of SDLC will function one after another
in linear manner.
That is, when the first phase is finished then only the
second phase will start and so on.
This model assumes that everything is carried out and
taken place perfectly as planned in the previous stage
and there is no need to think about the past issues that
may arise in the next phase.
38
This model does not work smoothly if there are some
issues left at the previous step.
The sequential nature of model does not allow us to go
back and undo or redo our actions.
This model is best suited when developers already
have designed and developed similar software in the
past and are aware of all its domains.
Requirements
definition
System and
software design
Implementation
and unit testing
Operation and
maintenance
39
Iterative Model
Leads the software development process in iterations.
It projects the process of development in cyclic
manner repeating every step after every cycle of SDLC
process.
40
Every cycle produces a software, which is complete in
itself and has more features and capabilities than that
of the previous one.
After each iteration, the management team can do
work on risk management and prepare for the next
iteration.
Because a cycle includes small portion of whole
software process, it is easier to manage the
development process but it consumes more resources.
41
Spiral Model
Spiral model is a combination of both, iterative model
and one of the SDLC model. It can be seen as if you
choose one SDLC model and combined it with cyclic
process (iterative model).
42
This model considers risk, which often goes un-
noticed by most other models.
The model starts with determining objectives and
constraints of the software at the start of one iteration.
44
At every stage, test plans and test cases are created to verify
and validate the product according to the requirement of
that stage.
For example, in requirement gathering stage the test team
prepares all the test cases in correspondence to the
requirements.
Later, when the product is developed and is ready for
testing, test cases of this stage verify the software against its
validity towards requirements at this stage.
This makes both verification and validation go in parallel.
This model is also known as verification and validation
model.
Verification and Validation: is the process of checking that
a software system meets specifications and that it fulfills its
intended purpose.
Validation: Are we building the right system?
Verification: Are we building the system right?
45
Big Bang Model
This model is the simplest model in its form.
It requires little planning, lots of programming and
lots of funds.
This model is conceptualized around the big bang of
universe. As scientists say that after big bang lots of
galaxies, planets, and stars evolved just as an event.
46
For this model, very small amount of planning is
required.
It does not follow any process, or at times the customer
is not sure about the requirements and future needs.
So the input requirements are arbitrary.
This model is not suitable for large software projects
but good one for learning and experimenting.
47
Software Metrics
A software metric is a measure of software
characteristics which are measurable or countable.
Software metrics are valuable for many reasons,
including measuring software performance, planning
work items, measuring productivity, and many other
uses.
Within the software development process, many
metrics are there, that are all connected.
Software metrics are similar to the four functions of
management: Planning, Organization, Control, or
Improvement.
48
Classification of Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various
characteristics of the software product. The two important
software characteristics are:
Size and complexity of software.
Quality and reliability of software.
These metrics can be computed for different stages of
SDLC.
2. Process Metrics: These are the measures of various
characteristics of the software development process.
For example, the efficiency of fault detection. They are
used to measure the characteristics of methods,
techniques, and tools that are used for developing software.
49
Types of Metrics
Internal metrics: Internal metrics are the metrics
used for measuring properties that are viewed to be of
greater importance to a software developer. For
example, Lines of Code (LOC) measure.
External metrics: External metrics are the metrics
used for measuring properties that are viewed to be of
greater importance to the user, e.g., portability,
reliability, functionality, usability, etc.
50
Hybrid metrics: Hybrid metrics are the metrics that
combine product, process, and resource metrics.
For example, cost per FP where FP stands for Function
Point Metric.
Project metrics: Project metrics are the metrics used
by the project manager to check the project's progress.
Data from the past projects are used to collect various
metrics, like time and cost; these estimates are used as
a base of new software.
Note that as the project proceeds, the project manager
will check its progress from time-to-time and will
compare the effort, cost, and time with the original
effort, cost and time.
51
Chapter 3
Requirement Engineering
The software requirements are description of features
and functionalities of the target system.
Requirements convey the expectations of users from
the software product.
Requirement Engineering is the process of
gathering the software requirements from client,
analyze, and document it.
Goal is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’
document.
52
Requirement Engineering Process
53
Feasibility Study
What all functions the software must perform and
which all features are expected from the software.
The analysts do a detailed study about whether the
desired system and its functionality are feasible to
develop.
This study analyzes whether the software product can
be practically materialized in terms of
implementation,
contribution of project to organization,
cost constraints, and
as per values and objectives of the organization.
54
It explores technical aspects of the project and product
such as usability, maintainability, productivity, and
integration ability.
55
Requirement Gathering
If the feasibility report is positive towards undertaking
the project, next phase starts with gathering
requirements from the user.
56
Software Requirement Specification
SRS is a structured document created by system
analyst after the requirements are collected from
various stakeholders.
57
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 inaccurately.
58
Software Requirement Elicitation
Requirement elicitation process can be depicted using
the following diagram:
59
Negotiation & discussion - If requirements are
ambiguous or there are some conflicts in requirements
of various stakeholders, it is then negotiated and
discussed with the 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 and informal, functional
and non-functional requirements are documented and
made available for next phase processing.
60
Requirement Elicitation Technique
Requirements Elicitation is 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.
62
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.
63
Domain Analysis: 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.
66
Software Requirements
SR are categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of
software.
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.
67
Non-Functional Requirements
Requirements, which are not related to functional aspect of
software.
They are implicit or expected characteristics of software,
which users make assumption of.
Non-functional requirements include -
Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility
68
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.
71
System Perspectives
An external perspective, where you model the context
or environment of the system.
An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
A structural perspective, where you model the
organization of a system or the structure of the data
that is processed by the system.
A behavioral perspective, where you model the
dynamic behavior of the system and how it responds
to events.
72
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.
73
Use of Graphical Models
As a means of facilitating discussion about an existing
or proposed system
Incomplete and incorrect models are OK as their role is
to support discussion.
As a way of documenting an existing system
Models should be an accurate representation of the
system but need not be complete.
As a detailed system description that can be used to
generate a system implementation
Models have to be both correct and complete.
74
Context Models
Context models are used to illustrate the operational
context of a system - they show what lies outside the
system boundaries.
Social and organisational concerns may affect the
decision on where to position system boundaries.
Architectural models show the system and its
relationship with other systems.
75
System Boundaries
System boundaries are established to define what is
inside and what is outside the system.
They show other systems that are used or depend on the
system being developed.
The position of the system boundary has a profound
effect on the system requirements.
Defining a system boundary is a political judgment
There may be pressures to develop system boundaries
that increase / decrease the influence or workload of
different parts of an organization.
76
Process Perspective
Context models simply show the other systems in the
environment, not how the system being developed is
used in that environment.
Process models reveal how the system being developed
is used in broader business processes.
UML activity diagrams may be used to define business
process models.
77
Interaction Models
Modeling user interaction is important as it helps to
identify user requirements.
Modeling system-to-system interaction highlights the
communication problems that may arise.
Modeling component interaction helps us understand
if a proposed system structure is likely to deliver the
required system performance and dependability.
Use case diagrams and sequence diagrams may be
used for interaction modeling.
78
Use case Modeling
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 diagrammatically to provide an overview
of the use case and in a more detailed textual form.
79
Transfer-data use case
A use case in the MHC-PMS
80
Tabular description of the ‘Transfer
data’ use-case
81
Sequence diagrams
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.
82
Sequence diagram for View patient
information
83
Structural models
Structural models of software display the organization
of a system in terms of the components that make up
that system and their relationships.
Structural models may be static models, which show
the structure of the system design, or dynamic models,
which show the organization of the system when it is
executing.
You create structural models of a system when you are
discussing and designing the system architecture.
84
Class diagrams
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.
85
Classes and associations in the
MHC-PMS
86
The Consultation Class
87
Key points
A model is an abstract view of a system that ignores system
details. Complementary system models can be developed to
show the system’s context, interactions, structure and behavior.
Context models show how a system that is being modeled is
positioned in an environment with other systems and processes.
Use case diagrams and sequence diagrams are used to describe
the interactions between users and systems in the system being
designed. Use cases describe interactions between a system and
external actors; sequence diagrams add more information to
these by showing interactions between system objects.
Structural models show the organization and architecture of a
system. Class diagrams are used to define the static structure of
classes in a system and their associations.
88
Generalization
Generalization is an everyday technique that we use to
manage complexity.
89
In modeling systems, it is often useful to examine the
classes in a system to see if there is scope for
generalization. If changes are proposed, then you do
not have to look at all classes in the system to see if
they are affected by the change.
In object-oriented languages, such as Java,
generalization is implemented using the class
inheritance mechanisms built into the language.
In a generalization, the attributes and operations
associated with higher-level classes are also associated
with the lower-level classes.
The lower-level classes are subclasses inherit the
attributes and operations from their superclasses.
These lower-level classes then add more specific
attributes and operations.
90
A Generalization Hierarchy
91
A Generalization Hierarchy with
added detail
92
Behavioral models
Behavioral models are models of the dynamic behavior
of a system as it is executing. They show what happens
or what is supposed to happen when a system
responds to a stimulus from its environment.
You can think of these stimuli as being of two types:
Data Some data arrives that has to be processed by the
system.
Events Some event happens that triggers system
processing. Events may have associated data, although
this is not always the case.
93
Data-driven modeling
Many business systems are data-processing systems
that are primarily driven by data. They are controlled
by the data input to the system, with relatively little
external event processing.
Data-driven models show the sequence of actions
involved in processing input data and generating an
associated output.
They are particularly useful during the analysis of
requirements as they can be used to show end-to-end
processing in a system.
94
Event-driven modeling
Real-time systems are often event-driven, with
minimal data processing. For example, a landline
phone switching system responds to events such as
‘receiver off hook’ by generating a dial tone.
Event-driven modeling shows how a system responds
to external and internal events.
It is based on the assumption that a system has a finite
number of states and that events (stimuli) may cause a
transition from one state to another.
95
State machine models
These model the behavior of the system in response to
external and internal events.
They show the system’s responses to stimuli so are
often used for modeling 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.
96
State diagram of a microwave oven
97
States and stimuli for the
microwave oven (a)
98
States and stimuli for the
microwave oven (b)
99
Microwave oven operation
100
Model-driven engineering
Model-driven engineering (MDE) is an approach to
software development where models rather than
programs are the principal outputs of the development
process.
The programs that execute on a hardware/software
platform are then generated automatically from the
models.
Proponents of MDE argue that this raises the level of
abstraction in software engineering so that engineers
no longer have to be concerned with programming
language details or the specifics of execution
platforms.
101
Model driven architecture
Model-driven architecture (MDA) was the precursor of
more general model-driven engineering
MDA is a model-focused approach to software design
and implementation that uses a subset of UML models
to describe a system.
Models at different levels of abstraction are created.
From a high-level, platform independent model, it is
possible, in principle, to generate a working program
without manual intervention.
102
Types of model
A computation independent model (CIM)
These model the important domain abstractions used in
a system. CIMs are sometimes called domain models.
A platform independent model (PIM)
These model the operation of the system without
reference to its implementation. The PIM is usually
described using UML models that show the static
system structure and how it responds to external and
internal events.
Platform specific models (PSM)
These are transformations of the platform-independent
model with a separate PSM for each application
platform. In principle, there may be layers of PSM, with
each layer adding some platform-specific detail.
103
Key points
Behavioral models are used to describe the dynamic
behavior of an executing system. This behavior can be
modeled from the perspective of the data processed by the
system, or by the events that stimulate responses from a
system.
Activity diagrams may be used to model the processing of
data, where each activity represents one process step.
State diagrams are used to model a system’s behavior in
response to internal or external events.
Model-driven engineering is an approach to software
development in which a system is represented as a set of
models that can be automatically transformed to
executable code.
104