Department of Computer Science

Software Engineering
(CoSc3061)

Chapter One
Introduction

By Kelil Mohammed
 Introduction
What is software?
Software is set of instruction or programs that direct the computer hardware
or that help user to perform users’ task.
• Is collection of computer programs, procedures, rules, and associated
documentations and data (IEEE).
• Software have variety of application or touch all aspect of human life such
as:
• business domain
• engineering domain(software used for drawing, drafting, modelling, etc)
• Education domain (e-learning, ...)
• etc
04/08/2022 By Kelil M. 2
 Cont’d…
What is software engineering?
 Software engineering is the process of solving customers’ problems by the
systematic development and evolution of large, high-quality software
systems within cost, time and other constraints.
•Other definitions:
• IEEE: the application of a systematic, disciplined, quantifiable approach to
the development, operation, maintenance of software; that is, the
application of engineering to software.
• The Canadian Standards Association: The systematic activities involved in
the design, implementation and testing of software to optimize its
production and support.

04/08/2022 By Kelil M. 3
 Cont’d...
Solving customers’ problems
This is the goal of software engineering
Sometimes the solution is to buy, not build
Adding unnecessary features does not help solve the problem
Software engineers must communicate effectively to identify and understand
the problem
Systematic development and evolution
An engineering process involves applying well understood techniques in a
organized and disciplined way
Many well-accepted practices have been formally standardized
• e.g. by the IEEE or ISO
Most development work is evolution

04/08/2022 By Kelil M. 4
 Cont’d...
Large, high quality software systems
 Software engineering techniques are needed because large systems cannot
be completely understood by one person
 Teamwork and co-ordination are required
 Key challenge: Dividing up the work and ensuring that the parts of the
system work properly together
 The end-product must be of sufficient quality
 Cost, time and other constraints
 Finite resources
 The benefit must outweigh the cost
 Others are competing to do the job cheaper and faster
 Inaccurate estimates of cost and time have caused many project failures
 Software engineers must ensure their systems can be produced within a
limited budget and by a certain due date
04/08/2022 By Kelil M. 5
 Two orthogonal view of the software
The two-orthogonal views of software are:
1. Traditional paradigm view of software
2. Object-oriented paradigm view of software
Object-oriented systems development methods differ from traditional
development techniques in that the traditional techniques view software as a
collection of programs (or functions) and isolated data.
• What is a program?
• Algorithms + Data structures = Program

04/08/2022 By Kelil M. 6
 Cont’d…
A software System is a set of mechanisms for performing certain action on a
certain data
This means that there are two different, yet complementary ways to view
software construction; we can focus primarily on the function or primarily
focus on the data.
The heart of the distinction between traditional system development
methodologies and newer object-oriented methodologies lies in their
primary focus,
the traditional approach focuses on the functions of the system, where as
The object-oriented approach focuses on the object, which combines
data and functionality.

04/08/2022 By Kelil M. 7
 Cont’d…
Differences between traditional approach and Object Oriented system development
are summarized as follows:
Traditional Approach Object Oriented system development
Collections of procedures (functions ) Combination of data and functionality
Focuses on functions and Focuses on object, classes, modules that
procedures ,different styles and can be easily replaced , modified and
methodologies for each step of process reused
Moving from one phase to another phase is Moving from one phase to another phase
complex is easier
Increase the duration of project Decrease the duration of project
Increases complexity Reduces complexity and redundancy
04/08/2022 By Kelil M. 8
 Software Processes
A software process is the set of activities and associated outcome that produce a
software product.
• A structured set of activities required to develop a software system
These are four key process activities, which are common to all software processes:
i. Software specifications: The functionality of the software and constraints on its
operation must be defined. Defining what the system should do
ii. Software development: production of the software system
(Analysis, design and implementation.)
iii. Software validation: The software must be validated (checked) to ensure that it
does what the customer wants.
iv. Software evolution: changing the software in response to changing demands

04/08/2022 By Kelil M. 9
 Software Process Models

Process is a set of activities whose goal is the development of software.

We refer to the process as a life cycle.
The process model is an abstract presentation of software process.
The models specifies
• the various phases of the process
• e.g., requirements, specification, analysis, design, implementation, …
• the order in which these phases are carried out
• Provide guidance for project management
• what major tasks should be tackled next? milestones!
• what kind of progress has been made?

04/08/2022 By Kelil M. 10
 Cont’d…

 There are a number of different models for software development life cycles
(SDLC), which describe the interrelationships between software
development phases.

 The following SDLC models are the common ones:

 Water fall model ,
 prototype model
 incremental model
 Spiral model
04/08/2022 By Kelil M. 11
Cont’d…

Waterfall model: organize the activities in linear fashion.

 Each phase is end up with expected output in the forms of document
 It is the simplest process model (advantage of this process).
 Enforced discipline through documents(It has proper documentation)
 no phase is complete until the docs are done & checked by SE group
 concrete evidence of progress

04/08/2022 By Kelil M. 12
Waterfall model …  Requirements – defines needed
information, function, behaviour,
performance and interfaces.
 Design – data structures, software
architecture, interface representations,
algorithmic details.
 Implementation – source code, database,
user documentation, testing.
 Test – check if all code modules work
together and if the system as a whole
behaves as per the specifications.
 Installation – deployment of system, user-
training.
 Maintenance – bug fixes, added
04/08/2022
functionality
By Kelil M.
(an on-going process). 13
 Drawbacks of Waterfall Model
 All requirements must be known up front (in advance)
 Does not reflect problem-solving nature of software development – iterations
of phases
 Change during development is unlikely
 There is no risk analysis.
 Little opportunity for customer to preview the system
When to use the Waterfall Model
when technology is understood
When requirements are very well known
When it is possible to produce a stable design
• E.g. a new version of an existing product
• E.g. porting an existing product to a new platform.
04/08/2022 By Kelil M. 14
 Prototype process model
It is model implementation of the project with limited functionalities.

 The prototype model suggests that before development of the actual software, a
working prototype of the system should be built first

Developers build a prototype during the requirements phase

Prototype is evaluated by end users

Users give corrective feedback

Developers further refine the prototype

When the user is satisfied, the prototype code is brought up to the standards needed for
a final product.
04/08/2022 By Kelil M. 15
 Prototype process model Steps
A preliminary project plan is developed
A partial high-level paper model is created
The model is source for a partial requirements specification
A prototype is built with basic and critical attributes
The designer builds
• the database
• user interface
• algorithmic functions
 The designer demonstrates the prototype, the user evaluates for
problems and suggests improvements.
This loop continues until the user is satisfied
04/08/2022 By Kelil M. 16
 Prototype process model

What is the main goal of this model?

 To avoid early freezing of the requirements
 Instead of freezing the requirement,
prototype is built to understand the
requirement
 To enable the client to better understand
the requirement
04/08/2022 By Kelil M. 17
Prototype process model strengths
Customers can “see” the system requirements and give corrective feedback
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Prototype process model weakness
Tendency to abandon structured program development for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlooked
The customer may want the prototype delivered.
Process may continue forever (scope creep)
Controlling changes to the prototype following suggestions by the users is big challenge.
04/08/2022 By Kelil M. 18
 When to use Prototype process model
When requirements are unstable (when uncertainties in requirements).
When UI very important
Short-lived demonstrations
New, original development
With the analysis and design portions of object oriented development.
Systems with novice users

04/08/2022 By Kelil M. 19
 Incremental process model
Incremental development is dividing the project in various independent
parts and developing these sub-parts at the same rate/ different rate and
integrating them when ready.
Steps
Develop a system in smaller portions at a time
Then slowly add increased functionality
Each subsequent release of the system adds function to the previous release,
until all designed functionality has been implemented.

04/08/2022 By Kelil M. 20
Incremental process model…

04/08/2022 By Kelil M. 21
Incremental Model Strength
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early

04/08/2022 By Kelil M. 22
Incremental Model weakness
Requires good planning and design
Requires early definition of a complete and fully functional system to allow
for the definition of increments
Well-defined module interfaces are required
Total cost of the complete system is not lower
When to use the Incremental Model
Most of the requirements are known up-front (in advance) but are
expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules

04/08/2022 By Kelil M. 23
 Spiral Model

Process is conceived as a spiral rather than as a sequence of activities

with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design
• loops in the spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.

04/08/2022 By Kelil M. 24
Objective Risk
setting assessment
& reduction

Planning

Development
and validation

04/08/2022 Spiral model By Kelil M. 25

 Spiral model sectors
Objective setting
Specific objectives for the phase are identified.
Risk assessment and reduction
Risks are assessed and activities put in place to reduce the key risks.
Development and validation
A development model for the system is chosen which can be any of the
generic models.
Planning
The project is reviewed and the next phase of the spiral is planned

04/08/2022 By Kelil M. 26
 Spiral Model Strengths
Provides early indication of insurmountable (not in highest level)risks,
without much cost
Users see the system early because of rapid prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all life cycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently

04/08/2022 By Kelil M. 27
 Spiral Model Weaknesses
Time spent for evaluating risks too large for small or low risk projects
Time spent planning, resetting objectives, doing risk analysis and prototyping
may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase activities
May be hard to define objective, verifiable milestones that indicate readiness
to proceed through the next iteration
04/08/2022 By Kelil M. 28
 When to use Spiral Model

When creation of a prototype is appropriate

When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to
economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

04/08/2022 By Kelil M. 29
 Process assessment

In the CMM(capability maturity models) model, the maturity level of an

organization tells us to what extent an organization can produce low cost,
high quality software.
Having known the current maturity level, an organization can work to reach
the next higher level.
Software Process Improvement Efforts
Carnegie Mellon University’s Software Engineering Institute’s Capability
Maturity Model - (SEI’s CMM)
International Standards Organization’s 9001 Specification (ISO 9001)

04/08/2022 By Kelil M. 30
 Capability Maturity Models (CMM)

The capability maturity models of the SEI (Software Engineering Institute) are
a related group of strategies for improving the software process, irrespective
of the actual life-cycle model used.

 The term maturity is a measure of the goodness of the process itself.

In SW–CMM (software capability maturity models ) five levels of maturity are
defined, and an organization advances slowly in a series of small evolutionary
steps toward the higher levels of process maturity.

04/08/2022 By Kelil M. 31
 CMM Level 1. ( Initial Level)

The software process is characterized as ad hoc (unplanned, for one

specific purpose)
Few processes are defined
Success depends on individual effort
the software process is unpredictable, because it depends totally on the
current staff; as the staff changes, so does the process.
As a consequence, it is impossible to predict with any accuracy such
important items as the time it will take to develop a product or the cost of
that product.
04/08/2022 By Kelil M. 32
 CMM Level 2. Repeatable Level
Basic project management processes are established to track
cost, schedule, and functionality
Planning and management techniques are based on experience
with similar products; hence, the name repeatable.
The necessary process discipline is in place to repeat earlier
successes on projects with similar applications
Success achieved through basic project management; not
advanced technologies
“BASIC MANAGEMENT CONTROL”

04/08/2022 By Kelil M. 33
 CMM Level 3. Defined Level

The software process for both management and engineering activities is

documented, standardized, and integrated into a standard software process
for the organization
All projects use an approved, tailored version of the organization’s standard
software process for developing and maintaining software
At this level, it makes sense to introduce new technology, such as CASE
(Computer-Aided Software Engineering) environments, to increase quality
and productivity further.

“PROCESS DEFINITION”

04/08/2022 By Kelil M. 34
 CMM Level 4. Managed Level
A managed-level organization sets quality and productivity goals for each project.
These two quantities are measured continually and corrective action is taken
when there are unacceptable deviations from the goal.
Statistical quality controls are in place to enable management to distinguish a
random deviation from a meaningful violation of quality or productivity standards.
• A simple example of a statistical quality control measure is the number of faults
detected per 1000 lines of code.

“PROCESS MEASUREMENT

04/08/2022 By Kelil M. 35
 CMM Level 5. Optimizing Level
The goal of an optimizing-level organization is continuous process
improvement.
Statistical quality and process control techniques are used to guide
the organization.
 The knowledge gained from each project is utilized in future projects.
The process therefore incorporates a positive feedback loop, resulting
in a steady improvement in productivity and quality.

“PROCESS CONTROL”

04/08/2022 By Kelil M. 36
The five levels of the
software capability
maturity model and their
key process areas (KPAs)

04/08/2022 By Kelil M. 37
SW-CMM Process Assessment

General Classes of SW-CMM Appraisal

1. Software Process Assessment
Determine state of organization’s software process
2. Software Capability Evaluations
 Identify contractors qualified to perform software work

04/08/2022 By Kelil M. 38
Software Process Assessment:
Identify improvement priorities within organization
Assessment team uses CMM to guide identifying & prioritizing findings
• Findings & KPA guidance used to plan improvement strategy for organization
Software Capability Evaluations:
Identify risks associated with a project or contract to build high quality on
schedule & budget
During acquisition process, capability evaluation may be performed on bidders
Findings of an evaluation may be used to identify risk with using a contractor
Performed on existing contracts to monitor process performance

04/08/2022 By Kelil M. 39
Software Process Assessment & Capability Evaluation Steps:

04/08/2022 By Kelil M. 40
 Common steps in …. assessment
1. Team Selection
Select team trained in CMM
Knowledgeable in SE & mgmt.

2. Maturity Questionnaire
Site representatives complete questionnaire

3. Response Analysis
Analyse results of questionnaire
Investigation areas = KPAs

04/08/2022 By Kelil M. 41
Cont’d…

4. On-site Visit
Using results analysis, conduct on-site visit to view process areas
Using KPAs as guide, question, listen, review & synthesize info
Apply professional judgment
Document rationale for situations where KPAs not met

04/08/2022 By Kelil M. 42
 Cont’d…
5. Findings
At end of on-site period, team produces list of findings

Identifies strengths & weaknesses of org’s software processes

Software Process Assessment => Basis for Process Improvement recommendations

Software Capability Evaluation -> Findings part of risk analysis

6. KPA Profile
Team prepares KPA profile, showing where KPAs satisfied /not satisfied by organization

 KPA can be satisfied and still have associated findings, as long as findings don’t identify
major problems achieving goals of KPA
04/08/2022 By Kelil M. 43
Differences between Process Assessments & Capability Evaluation
Results of process assessment and capability evaluation may differ
Assessment and evaluation scope may vary:
Motivation, objective, outcome & results ownership differ
 These factors lead to differences in dynamics of interviews, scope of
inquiry, information collected, & results
Assessment & evaluation methods are different
 Assessment training doesn’t prepare team to do evaluation, vice versa
 Process Assessment is performed in open, collaborative environment
 Commitment from management & staff to do process improvement
 Objective: help improve organization
 Emphasis on interviews as tool for understanding organization’s software
process
04/08/2022 By Kelil M. 44
Differences between…cont’d

Capability Evaluation – performed in audit-oriented environment

 Objective tied to monetary considerations
 Emphasis on documented audit outcome that reveals software
process actually implemented by organization

04/08/2022 By Kelil M. 45
 Software process metrics

Why Measure Software?

Metric - quantitative measure of degree to which a system, component or process

possesses a given attribute. “A handle or guess about a given attribute.”
 E.g., Number of errors found per person hours expended

We measure software to:

 Determine the quality of the current product or process
 Predict qualities of a product/process
 Improve quality of a product/process

04/08/2022 By Kelil M. 46
 Motivation for Metrics

Estimate the cost & schedule of future projects

Evaluate the productivity impacts of new tools and techniques

Establish productivity trends over time

Improve software quality

Forecast future staffing needs

Anticipate (Realize beforehand) and reduce future maintenance needs

04/08/2022 By Kelil M. 47
 Metrics in the Process Domain
A metric as " a quantitative measure of the degree to which a system,
component, or process possesses a given attribute”.
Process metrics are collected across all projects and over long periods of time
They are used for making strategic decisions
The intent is to provide a set of process indicators that lead to long-term
software process improvement
The only way to know how/where to improve any process is to
 Measure specific attributes of the process
 Develop a set of meaningful metrics based on these attributes
 Use the metrics to provide indicators that will lead to a strategy for
improvement
04/08/2022 By Kelil M. 48
Metrics in the Process Domain (continued)

We measure the effectiveness of a process by deriving a set of metrics

based on outcomes of the process such as
 Errors uncovered before release of the software
 Defects delivered to and reported by the end users
 Work products delivered
 Human effort expended
 Calendar time expended
 Conformance to the schedule
 Time and effort to complete each generic activity

04/08/2022 By Kelil M. 49
 Protocol of Process Metrics

Use common sense and organizational sensitivity when interpreting

metrics data
Provide regular feedback to the individuals and teams who collect
measures and metrics
Don’t use metrics to evaluate individuals
Work with practitioners and teams to set clear goals and metrics that
will be used to achieve them
Never use metrics to threaten individuals or teams
Metrics data that indicate a problem should not be considered “negative”
 Such data are merely an indicator for process improvement
Don’t obsess on a single metric to the exclusion of other important metrics

04/08/2022 By Kelil M. 50
 Object oriented system development methodology
Object-oriented systems development is a way to develop software by building self-
contained modules or objects that can be easily replaced, modified and reused.
Furthermore , it encourages a view of the world as a system of cooperative and
collaborating objects .
In an object- oriented environment software is a collection of discrete objects that
encapsulate their data as well as the functionality to model real-world “objects”.
 An object orientation yields important benefits to the practice of the software
construction.
Each object has attribute (data) and methods (functions).

04/08/2022 By Kelil M. 51
 Why an object orientation?

Object-oriented methods enable us to create sets of objects that work

together synergistically (in a cooperative manner) to produce that better
model their problem domains than similar systems produced by traditional
techniques.

 The systems are easier to adapt to change requirements, easier to maintain,

more robust, and promote greater design and code reuse.

04/08/2022 By Kelil M. 52
The reasons why object orientation works

 High level of abstraction.

Seamless (smooth) transition among different phases of software

development.

Encourage of good programming techniques.

Promotion of reusability.

04/08/2022 By Kelil M. 53
 The reasons why … cont’d
Higher level of abstraction
The traditional approach supports abstraction at function level.
 The object-oriented approach supports abstraction at the object level.
Since objects encapsulate both data (attribute) and functions (methods) they
work at higher level of abstraction
 The development can proceed at object level and ignore the rest of the system
for as long as necessary
This makes designing, coding, testing, and maintaining the system much simpler.

04/08/2022 By Kelil M. 54
 The reasons why … cont’d
Seamless (smooth) transition among different phases of software development.
The traditional approach to software development requires different styles and
methodologies for each step of the process.
 Moving from one phase to an other requires a complex transition of perspective
between models that almost can be in different worlds
This transition not only can slow the development process but also increases the
size of the project and the chance for errors introduced in moving from one
language to another
The object oriented approach on the other hand, essentially uses the same
language in talk about analysis, design, programming, and database design.
The seamless approach reduces the level of complexity and redundancy and makes
clearer and more robust system development
04/08/2022 By Kelil M. 55
 The reasons why … cont’d
Encourage of good programming techniques
A class in an object-oriented system carefully delineates between its interface (specification
what the class can do) and the implementation of that interface (how the class does what it
does).
The attributes and methods are encapsulated within a class (or) held together tightly.
The classes are grouped into subsystems but remain independent one class has no impact
on other classes.
Object oriented approach is not a magical one to promote perfect design (or) perfect code.
Raising the level of abstraction from function level to object level and focusing on the
real-world aspects of the system, the object oriented method tends to
 Promote clearer designs.
 Makes implementation easier.
 Provide overall better communication.
04/08/2022 By Kelil M. 56
The reasons why … cont’d

Promotion of Reusability:
Objects are reusable because they are modelled directly out of real world.
The classes are designed generically (in a way can be reused) with reuse.
The object orientation adds inheritance, which is a powerful technique that
allows classes to built from each other.
The only different and enhancements between the classes need to be designed
and coded.
All the previous functionality remains and can be reused without change.

04/08/2022 By Kelil M. 57
 Overview of the unified approach

The Unified Approach (UA) is a methodology for software development.

UA is based on methodologies identified by Booch, Rumbaugh, and
Jacobson.
It tries to combine best practices, processes, and guidelines along with UML
notations and diagrams
UA utilizes the unified modeling language (UML) which is a set of notations
and conventions used to describe and model an application.
The heart of the UA is Jacobson’s use case
The use case represents, a typical interaction between a user and a computer
system to capture the user’s goals and needs .
• You capture a use case by talking to a typical users and discussing the various
ways they might want to use the system
04/08/2022 By Kelil M. 58
Overview of the unified approach … cont’d
 UA to software development revolves around the following process
and concepts
 Use–case driven development
 Object–oriented analysis
 Object– oriented design
 Incremental development
 Prototyping and continuous testing

04/08/2022 By Kelil M. 59
 Overview of the unified approach … cont’d
Layered Architecture
UA uses layered architecture to develop applications.
Creates object that represent elements to the user through interface or
physically stored in database.
The layered approach consists of user interface, business, access layers.
This approach reduces the interdependence of the user interface, database
access and business control.
More robust and flexible system.

04/08/2022 By Kelil M. 60
 Basic concepts of an object

What is an Object?
 The term object was first formally utilized in the Simula language to
simulate some aspect of reality.
 The term object means a combination of data and logic that represent
some real-world entity.
 An object is an entity.
• It knows things (has attributes)
• It does things (provides services or has methods)

04/08/2022 By Kelil M. 61
 Basic concepts of an object … cont’d

In object-oriented system, everything is an object and each object is responsible for itself.
For example:
• Windows applications needs windows object that can open themselves on screen and
either display something or accept input.
• Windows object is responsible for things like opening, sizing, and closing itself.
• When a windows display something, that something is an object.
• Example : chart.
• Chart object is responsible for maintaining its data and labels and even for drawing
itself.
04/08/2022 By Kelil M. 62
 Attributes of an object, its state and properties
Attributes:
 Attributes represented by data type
• Data of an object.
• Properties of an object
• They describe objects states.
• Example: A car is an object a real-world entity, identifiably separate
from its surroundings.
• A car has a well-defined set of attributes in relation to other object
• It’s attributes are:
• colour, manufacturer, cost, owner, model, etc

04/08/2022 By Kelil M. 63
 object … cont’d
Properties:
 Properties ( Methods) define objects
behaviour and specify the way in
which an Object’s data are
manipulated.
 In the Car example the car’s methods
are:
• drive it, lock it, stop it, carry
passenger in it.

===== End of Chapter One ====

04/08/2022 By Kelil M. 64