Chapter-1

Introduction to Software Engineering

Admas University
Computer Science Department
Mekenisa Campus
1
By:- Habib Kedir
 What is Software engineering?
 Software engineering is defined as a process of analyzing user requirements and then
designing, building, and testing software application which will satisfy those requirements
 Software engineering is a detailed study of engineering to the design, development and
maintenance of software. Software engineering was introduced to address the issues of low-
quality software projects.
 (1969) Software engineering is the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines
 (IEEE) The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of engineering to software

2
 Orthogonal view of software.

There are two orthogonal views of software development.

1) Traditional Technique – focuses on data and functions.
2) Object Oriented methodologies – focuses on objects that combines
data and functionality.

3
Software Engineering is a
Layered Technology

Tools

Methods

Processes
4
 What is a Process?

• (Webster) A system of operations in producing

something; a series of actions, changes, or
functions that achieve an end or a result
• (IEEE) A sequence of steps performed for a given
purpose

5
 What is a Software Process?

• (SEI) A set of activities, methods, practices, and

transformations that people use to develop and
maintain software and the associated products (e.g.,
project plans, design documents, code, test cases,
and user manuals)
• As an organization matures, the software process
becomes better defined and more consistently
implemented throughout the organization
• Software process maturity is the extent to which a
specific process is explicitly defined, managed,
measured, controlled, and effective
6
Software Process, Methods, and
Tools
• Process
– Provides the glue that holds the layers together; enables rational
and timely development; provides a framework for effective
delivery of technology; forms the basis for management; provides
the context for technical methods, work products, milestones,
quality measures, and change management
• Methods
– Provide the technical "how to" for building software; rely on a set
of basic principles; encompass a broad array of tasks; include
modeling activities
• Tools
– Provide automated or semi-automated support for the process and
methods (i.e., CASE tools)

7
 Generic Process Framework

• Communication
– Involves communication among the customer and other stake
holders; encompasses requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses
technical tasks, resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better understand the
requirements and the design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and
feedback

8
Five Levels of Software Process
Maturity

9
 Characteristics of Each Level

• Initial Level (Level 1)

– Characterized as ad hoc, and occasionally even chaotic
– Few processes are defined, and success depends on individual effort
• Repeatable (Level 2)
– Basic project management processes are established to track cost, schedule,
and functionality
– The necessary process discipline is in place to repeat earlier successes on
projects with similar applications
• Defined (Level 3)
– 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
10
 Characteristics of Each Level
(continued)
• Managed (Level 4)
– Detailed measures of the software process and product quality are collected
– Both the software process and products are quantitatively understood and
controlled
• Optimized (Level 5)
– Continuous process improvement is enabled by quantitative feedback from
the process and from piloting innovative ideas and technologies

11
Key Process Areas

12
 1.2 Software Engineering
Disciplines

 Requirements Elicitation
 Specification and Analysis
 Design
 Implementation
 Testing and Validation
 Maintenance and Evolution
 Process Evolution

13
Software Development Life Cycle

14
 Modeling: Software Requirements
Analysis

• Helps software engineers to better understand the problem they will

work to solve
• Encompasses the set of tasks that lead to an understanding of what the
business impact of the software will be, what the customer wants, and
how end-users will interact with the software
• Uses a combination of text and diagrams to depict requirements for
data, function, and behavior
– Provides a relatively easy way to understand and review requirements for
correctness, completeness and consistency

15
15
 Modeling: Software Design
• Brings together customer requirements, business needs, and technical
considerations to form the “blueprint” for a product
• Creates a model that that provides detail about software data structures,
software architecture, interfaces, and components that are necessary to
implement the system
• Architectural design
– Represents the structure of data and program components that are required to build
the software
– Considers the architectural style, the structure and properties of components that
constitute the system, and interrelationships that occur among all architectural
components
• User Interface Design
– Creates an effective communication medium between a human and a computer
– Identifies interface objects and actions and then creates a screen layout that forms
the basis for a user interface prototype
• Component-level Design
– Defines the data structures, algorithms, interface characteristics, and communication
mechanisms allocated to each software component

16
16
What is software process model and its type?

A software process model is an abstraction of the software development

process. The models specify the stages and order of a process. So, think of this

as a representation of the order of activities of the process and the sequence in

which they are performed

17
 Waterfall Model
(Diagram)
Communication

Project initiation

Requirements gathering

Planning

Estimating

Scheduling

Tracking Modeling

Analysis

Design Construction

Code

Test
Deployment

Delivery

Support

Feedback

18
18
 Waterfall Model
(Description)
• Oldest software lifecycle model and best understood by upper management
• Used when requirements are well understood and risk is low
• Work flow is in a linear (i.e., sequential) fashion
• Used often with well-defined adaptations or enhancements to current
software

19
19
 Waterfall Model
(Problems)
• Doesn't support iteration, so changes can cause confusion
• Difficult for customers to state all requirements explicitly and up front
• Requires customer patience because a working version of the program
doesn't occur until the final phase
• Problems can be somewhat alleviated in the model through the addition of
feedback loops (see the next slide)

20
20
 Waterfall Model with Feedback
(Diagram)
Communication

Project initiation

Requirements gathering

Planning

Estimating

Scheduling

Tracking Modeling

Analysis

Design Construction

Code

Test
Deployment

Delivery

Support

Feedback

21
21
 Incremental Model
(Diagram)
Increment #1

Communication
Planning
Modeling
Construction
Deployment

Increment #2

Communication
Planning
Modeling
Construction
Deployment

Increment #3

Communication
Planning
Modeling
Construction
Deployment

22
22
 Incremental Model
(Description)
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow is in a linear (i.e., sequential) fashion within an increment and is
staggered between increments
• Iterative in nature; focuses on an operational product with each increment
• Provides a needed set of functionality sooner while delivering optional
components later
• Useful also when staffing is too short for a full-scale development

23
23
 Prototyping Model
(Diagram)
Quick Planning

Communication

Start

Modeling

Quick Design
Deployment,

Delivery,

and Feedback

Construction

Of Prototype

24
24
 Prototyping Model
(Description)
• Follows an evolutionary and iterative approach
• Used when requirements are not well understood
• Serves as a mechanism for identifying software requirements
• Focuses on those aspects of the software that are visible to the customer/user
• Feedback is used to refine the prototype

25
25
 Prototyping Model
(Potential Problems)
• The customer sees a "working version" of the software, wants to stop all
development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software
running quickly (e.g., language choice, user interface, operating system
choice, inefficient algorithms)
• Lesson learned
– Define the rules up front on the final disposition of the prototype before it is
built
– In most circumstances, plan to discard the prototype and engineer the actual
production software with a goal toward quality

26
26
 Spiral Model
(Diagram)
Planning

Communication

Start Modeling

Start

Deployment Construction

27
27
 Spiral Model
(Description)
• Invented by Dr. Barry Boehm in 1988 while working at TRW
• Follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project risks; may
also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements have been
defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each
complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development

28
28
 General Weaknesses of
Evolutionary Process Models

1) Prototyping poses a problem to project planning because of the

uncertain number of iterations required to construct the product
2) Evolutionary software processes do not establish the maximum speed of
the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and extensibility, and
second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could result in
late delivery

29
29
Object Oriented system Development Methodology

30
Continue….

31
Overview of the Unified Approach

32
Continue….

33
Continue….

34
Object Oriented Paradigm

35
Continue….

36
Continue….

37
 What is the state and behavior of an object?

All the objects have a state, behavior and identity.

- The state or attributes are the built in characteristics or properties of an

object. ... Behaviour of the object

- The behavior or operations of an object are its predefined functions.

All the objects have a state, behavior and identity.

State of an object - The state or attributes are the built in characteristics or

properties of an object. For example, a T.V has the size, colour, model etc.

Behavior of the object - The behavior or operations of an object are its predefined

functions. For example, a T.V. can show picture , change channels, tune for a
38
channel etc. in object oriented programming terminology the behavior is
 Software Development Challenges

. What are the key challenges

facing software engineering?

39
 1 The heterogeneity challenge

The heterogeneity challenge Increasingly, systems are required

to operate as distributed systems across networks that
include different types of computers and with different kinds
of support systems. It is often necessary to integrate new
software with older legacy systems written in different
programming languages. The heterogeneity challenge is the
challenge of developing techniques for building dependable
software that is flexible enough to cope with this
heterogeneity.

40
 2 The delivery challenge

The delivery challenge Many traditional software

engineering techniques are time-consuming. The
time they take is required to achieve software
quality. However, businesses today must be
responsive and change very rapidly. Their
supporting software must change equally rapidly.
The delivery challenge is the challenge of
shortening delivery times for large and complex
systems without compromising system quality.

41
 3 The trust challenge

The trust challenge As software is intertwined with all aspects of our lives, it
is essential that we can trust that software. This is especially true for
remote software systems accessed through a web page or web service
interface. The trust challenge is to develop techniques that demonstrate

.
that software can be trusted by its users Of course, these are not
independent. For example, it may be necessary to make rapid changes to
a legacy system to provide it with a web service interface. To address
these challenges, we will need new tools and techniques as well as
innovative ways of combining and using existing software engineering
methods.

42