Software Engineering

Lecture 2
Introduction

BY: Instructor Tsega A.(MSc)

 Software engineering
 Software Engineering is not Programming
 Programming is primarily a personal activity

 Large software systems must be developed similar to other

engineering practices (not through mere programming)
 “Engineering is the analysis, design, construction, verification, and
management of technical (or social) entities”
 Ian summoerviellie

 Software engineering is a team activity

 Programming is just one aspect of software development

2
 Software engineering
Software Engineering
 a software engineer starts with problem definition and
applies tools of the trade to obtain a problem solution.
 Programming is the craft of implementing the given blueprints.
 Software engineer’s focus is on understanding the
interaction between the system-to-be and its users and
the environment.

3
4
 Software Engineering
 “Engineering is the analysis, design, construction, verification,
and management of technical (or social) entities”
 Questions that we must answer:
 What is the problem to be solved?
 What characteristics of the entity are used to solve the problem?
 How will the entity (and the solution) be realized?
 How will the entity be constructed?
 How to uncover error made in design and construction of entity?
 Manage change: How to support, when corrections, adaptations,
and enhancements are requested by users of the entity.

 The entity that we deal with in software Engineering is a

computer software.
5
 Software engineer should have the ability to imagine and be
creative.

6
7
 What is Software engineering
 Software engineering
 Creating and maintaining software applications by applying
technologies and practices from computer science, project
management, and other fields.

8
 Aspects of software engr.
1. Processes necessary to turn a concept into a robust
deliverable that can evolve over time.

2. Working with limited time and resources

2. Satisfying a customer

3. Managing risk

4. Teamwork and communication

9
 Ties to many fields
 computer science (algorithms, data structures, languages, tools)
 business/management (project mgmt, scheduling)
 economics/marketing (selling, markets, monopolies)
 communication (managing relations with stakeholders:
customers, management, developers, testers, sales)
 law (patents, licenses, copyrights, reverse engineering)
 sociology (modern trends in societies, localization, ethics)
 political science (negotiations; topics at the intersection of
law, economics, and global societal trends; public safety)
 psychology (personalities, styles, usability, what is fun)
 art (GUI design, what is appealing to users)

10
 Roles of people in software
 customer / client: wants software built
 often doesn't know what he/she wants

 managers / designers: plan software

 difficult to foresee all problems and issues in advance

 developers: write code to implement software

 it is hard to write complex code for large systems

 testers: perform quality assurance (QA)

 it is impossible to test every combination of actions
 users: purchase and use software product
 users can be fickle and can misunderstand the product

11
 What is a software project?
 Projects are a balance of three dimensions, with the goal of
producing a successful deliverable.

FEATURES & QUALITY

SOFTWARE
DELIVERABLE
TIME RESOURCES

12
ORTHOGONAL VIEWS OF THE SOFTWARE


Two Approaches:
 Traditional Approach
 Object-Oriented Approach


TRADITIONAL APPROACH:

Collection of programs or functions.
• A system that is designed for performing
certain actions.
• Algorithms + Data Structures =
Programs.
 Software Development Models (Waterfall, 13

The traditional approach to software development
tends toward writing a lot of code to do all the things
that have to be done.

Algorithm Centric Methodology – only the algorithm
that can accomplish the task.

Data-Centric Methodology - think about the data to
build a structure based on the algorithm.

You are the only active entity and the code is just
basically a lot of building materials.

14
 Object-oriented Approach

Object Oriented Development is a new way of
thinking about software based on abstractions that
exist in the real world as well as in the program.

An approach to the solution of problems in which all
computations are performed in the context of
objects.
•The objects are instances of classes, which:

are data abstractions

contain procedural abstractions that operate
on the objects

A running program can be seen as a collection of
objects collaborating to perform a given task.
15

OO development offers a different model
from the traditional software which is based
on functions and procedures.
• software is a collection of discrete object that
encapsulate their data as well as the
functionality.
• Each object has attributes (properties) and
method (procedures).
• software by building self contained modules
or objects that can be easily REPLACED,
MODIFIED AND REUSED. 16
 EXAMPLES OF OBJECT ORIENTED
SYSTEMS

In OO system , “everything is object”.

A spreadsheet cell, bar chart, title in bar chart,
report,numbers, arrays, records, fields, files,
forms, an invoice, etc.

A window object is responsible for things like
opening, sizing, and closing itself.

A chart object is responsible for things like
maintaining data and labels even for drawing
itself.

17
 BENEFITS OF OBJECT ORIENTATION

Faster development,

Re-usability,

Increased quality

modeling the real world and provides us with
the stronger equivalence of the real world‘s
entities (objects).

Raising the level of abstraction to the point
where application can be implemented in the
same terms as they are described.

18
Difference between Traditional and Object
Oriented Approach

19
 Software Process
 A software process is a set of related activities that leads to the
production of a software product.
 There are many different software processes but all must include four
activities that are fundamental to software engineering:
1. Software specification: The functionality of the software and
constraints on its operation must be defined.
2. Software design and implementation: The software to meet
the specification must be produced.
3. Software validation: The software must be validated to ensure
that it does what the customer wants.
4. Software evolution: The software must evolve to meet
changing customer needs

20
Verification: are we building the product right?
Validation: are we building the right product?

21
 software engineering
objectives
1. optimality

Optimality means that the process should be able to produce

high-quality software at low cost

2. scalability.

It should also be applicable for large software projects.

22
 Software process xics
 Functionality: the degree of performance of the software
against its intended purpose.
Required functions are:
 suitability
Accuracy
Interoperability
Compliance
Security

23
 Reliability:
A set of attributes that bears on the capability of software to
maintain its level of performance under the given condition for
a stated period of time.
Required functions are
 Recoverability
Fault tolerance
 Maturity

24
 Efficiency:
It refers to the ability of the software to use system resources
in the most effective and efficient manner.
 The software should make effective use of storage space and
executive command as per desired timing requirements.
Required functions are:
efficiency In time
In resource

25
 Usability: to the extent to which the software can be used
with ease.
 The amount of effort or time required to learn how to use the
software.
Required functions are:
Understandability
Learnability
Operability

26
 Maintainability:
It refers to the ease with which the modifications can be made in a
software system to extend its functionality, improve its performance,
or correct errors.

 Required functions are:

 Testability

 Stability

 Changeability

 Operability

27
 Portability:
A set of attributes that bears on the ability of software to be
transferred from one environment to another, without or
minimum changes.
Required functions are:
Adaptability
Install ability
Replace ability

28
 The "Software Lifecycle"
 software lifecycle: The entire process of creating a software
product from an initial concept until the last user stops using it.
 often divided into "phases":
 Requirements – what does the customer want
 Design – Describe how a solution that meets the requirements
 Implementation – Convert the design (description) into code
 Testing – Make sure the code meets the requirements
 Maintenance – Fix problems while operating
 other possibilities: Risk Assessment, Prototyping

 goals of each phase:

 mark out a clear set of steps to perform
 produce a tangible document or item
 allow for review of work
 specify actions to perform in the next phase

29
 Software is complex
 Measures of complexity:
 lines of code
 number of classes
 number of modules
 module interconnections and dependencies
 time to understand
 # of authors

 … many more

30
 Life without software process
 Advantages:
 nothing to learn or plan!
 work on whatever is interesting, ignore
the rest.

 Disadvantages:
 may ignore some important tasks (testing, design)
 not clear when to start or stop doing each task
 scales poorly to multiple people
 hard to review or evaluate one's work
 code may not match user's needs (no requirements!)
 code was not planned for modification, not flexible

31
 Software process models

 Linear: sequential model

 Prototyping model: identify whatever requirements are known,
and outline areas where further definition is mandatory. A "quick
design" then occurs.
 Rapid application development (RAD): an incremental software
development process model that emphasizes an extremely short
development cycle. “high-speed” adaptation of the linear
sequential model
 Evolutionary : develop increasingly more complete versions of
the software. 32
 Some lifecycle models
 code-and-fix: write some code, fix it when it breaks

 waterfall: standard phases (req., design, code, test) in order

 spiral: assess risks at each step; do most critical action first

 evolutionary prototyping: build an initial small requirement

spec, code it, then "evolve" the spec and code as needed

 staged delivery: build initial requirement specs for several

releases, then design-and-code each in sequence

 agile development: iterative, adaptive, incremental

improvement done by self-organizing cross-functional teams
33
 Ad-hoc development
 ad-hoc development: no formal process (aka "code and fix")
 Sounds great! No learning required.
 Applicable for very small projects and short-lived prototypes

 Drawbacks?
 No way to asses progress, quality, or risks
 Unlikely to accommodate changes without a major design
Examination
 Unclear delivery features (scope), timing, and support

34
 Waterfall
 The first published model of the software development process
 derived from more general engineering processes
 Perform each phase in order

35
1. Requirements analysis and definition
 The system’s services, constraints, and goals are established
by consultation with system users.
 They are then defined in detail and serve as a system
specification.
2. System and software design
 The systems design process allocates the requirements to
either hardware or software systems by establishing an overall
system architecture.
36
3. Implementation and unit testing
 During this stage, the software design is realized as a set of
programs or program units.
 Unit testing involves verifying that each unit meets its
specification.
4. Integration and system testing
 The individual program units or programs are integrated
and tested as a complete system to ensure that the
software requirements have been met.
37
5. Operation and maintenance
 involves correcting errors which were not discovered in earlier
stages of the life cycle.
 In waterfall the following phase should not start until the
previous phase has finished.
 In practice, these stages overlap and feed information to each
other.
 During design, problems with requirements are identified.
During coding, design problems are found and so on.

38
 Waterfall model advantages
 Suitable for projects that are very well understood but complex
 Tackles all planning upfront
 The ideal of no midstream changes equates to an efficient
software development process

 Supports inexperienced teams

 Orderly, easy-to-follow sequential model
 Reviews at each stage determine if the product is ready to
advance

39
 Drawbacks of waterfall
req. change
requirements
verify
design
verify
implement
test

operations

 drawbacks? retirement
 assumes requirements will be clear and well-understood
 requires a lot of planning up front (not always easy)
 rigid, linear; not adaptable to change in the product
 costly to go back to a previous phase
 nothing to show until almost done

40
 Spiral
 steps taken at each loop:
 determine objectives
and constraints
 identify risks
 evaluate options to
resolve risks
 develop and verify
deliverables

 benefits?
 provides early indication of unforeseen problems
 always addresses the biggest risk first
 accommodates changes, growth
 eliminates errors and unattractive choices early
41
 Drawbacks of spiral

 drawbacks?
 relies on developers to have risk-assessment expertise
 perhaps over-focuses on risk and "putting out fires"; other
features may go ignored because they are not "risky" enough
 complex; how do you actually follow this?
 works poorly when bound to an inflexible contract

42
 comparison

Waterfall model Spiral model

 Risk factors are not  Risk factors are considered
considered  Requirements are not
 The requirements are freeze
freeze  Works in loop
 Is linear sequential  Costly as risk factor is
 Not much costly covered
 Communication level is not  Better Communication
high

43
 Evolutionary prototyping
 Develop a skeleton system and evolve it for delivery

Refine
Design and
Initial concept prototype until Complete and
implement
acceptable release
initial
prototype prototype

 build initial requirements, design/code it, "evolve" as needed

44
 Evolutionary prototyping
for each build:
requirements arch. design operations
detailed design,
implement,
verify verify test, deliver
retirement

 benefits?
 produces steady signs of progress, builds customer confidence
 useful when requirements are not well known or change rapidly
 customer involvement ("What do you think of this version?")

45
 Drawbacks of evolutionary
for each build:
requirements arch. design operations
detailed design,
implement,
verify verify test, deliver
retirement

 drawbacks?
 assumes user's initial spec will be flexible
 Problems with planning
 unclear how much iteration/time will be needed to finish
 feature creep
 fails for separate pieces that must then be integrated
 temporary fixes become permanent constraints

46
 Staged delivery
waterfall-like beginnings, then develop in
Requirements short stages
plan, design, execute, test, release
 can ship at any time at the end of any
cycle
Design

Stage 1: detailed design, code, test, deliver

Stage n: detailed design, code, test, deliver

47
Staged delivery model advantages
 Can ship at the end of any release cycle
 Looks like success to customers, even if not original goal

 Intermediate deliveries show progress, satisfy customers, and

lead to feedback

 Problems are visible early (e.g., integration)

 Facilitates shorter, more predictable release cycles

Very practical, widely used and successful

48
Staged delivery model disadvantages
 Disadvantages
 Requires tight coordination with documentation, management,
marketing
 Product must be decomposable
 Extra releases cause overhead

 How does staged delivery differ from evolutionary prototyping?

 In staged delivery, requirements are better known ahead of time
rather than discovered by customer feedback on each release.

49
 Why are there so many models?
 The choice of a model depends on the project circumstances
and requirements.

 A good choice of a model can result in a vastly more

productive environment than a bad choice.

 A cocktail of models is frequently used in practice to get the

best of all worlds. Models are often combined or tailored to
environment

50
 What’s the best model?
 Consider
 The task at hand
 Risk management
 Quality / cost control
 Predictability
 Visibility of progress
 Customer involvement and feedback

Aim for good, fast, and cheap.

But you can’t have all three at the same time.

51
 Model category matrix
 Rate each model 1-5 in each of the categories shown:
Risk Quality/ Predict- Visibility Customer
mgmt. cost ctrl. ability of progress involvement

code-and-fix
1 1 1 3 1
waterfall
3 4 4 1 2
spiral
5 5 3 3 3
evolutionary
prototyping 3 3 2 5 5
staged delivery

design-to-schedule
4 5 4 4 4
4 3 5 3 2
52
 Other Models
 Rapid application development (RAD) Model
 incremental software development process model
 emphasizes an extremely short development cycle
 achieved by using component-based construction
 Piece together already existing components to create what you need
 The Formal-methods model
 formal mathematical specification of computer software
 specify, develop, and verify systems by a rigorous, mathematical
notation
 SE M.Sc. And PhD researches focus here
 Agile Model: is based on iterative development.
 - break tasks into smaller iterations
 - duration and scope of each iteration is clearly defined in
advance.
53
 Software process metrics
Software Measurement
Size-Oriented Metrics(Programming language dependent)
 Errors per KLOC (thousand lines of code).
 Defects per KLOC.
 per LOC.
 Page of documentation per KLOC.
In addition, other interesting metrics can be
computed

Errors per person-month.

LOC per person-month.

per page of documentation.

54
Function oriented metrics(programming language independent)
 Does the system require reliable backup and recovery?
 number of user inputs
 number of user outputs
 Measures of errors uncovered before release
 Defects delivered to and reported by end users

55
 Object Oriented Methodologies

Many methodologies have been developed
for object oriented development.
• A methodology usually includes:
• Notation : Graphical representation of
classes and their relationships with
interactions.
• Process : Suggested set of steps to
carry out for transforming requirements into a
working system.
• Tool (CASE): Software for drawings and
documentation 56
 WHY OBJECT ORIENTATION
 OO Methods enables to develop set of objects that work
together software similar to traditional techniques.
 It adapts to:
• Changing requirements
• Easier to maintain
• More robust
• Promote greater design
• Code reuse

57
 OVERVIEW OF UNIFIED APPROACH(UA)


The unified approach (UA) is a methodology for software
development.

Combines with the OMT (Object Modeling Technique in
Unified Modelling Language(UML).

UA utilizes the unified modeling language (UML) which is
a set of notations and conventions used to describe and
model an application.

58

The unified approach combines all the powerful
features present in the methods of Grady booch,
james, rumbaugh and Jacobson and thus creates a
new tool for the analysis and modeling of the
system.

The result of this is the unified modeling language
(UML) .

In UML a system is represented using five different
views that describe the system form different
perspectives.

Each view is defined by a set of diagrams. A view
may be represented by a single diagram. 59

The views present in UML are:
 1. Structural Model View : Static structures i.e. classes objects
relationships etc. are modeled.
 2. Behavioral Model View: it represent the dynamic aspects of
a system. It also depicts the interactions or collaboration
between various structural element described in other views
 3. User Model view This view represents system from the
user perspective.
 4. Implementation Model View : The structural and behavioral
aspects o f the system are represented as they are
 5. Environment Model View :The structural and behavioral
aspects of the environment in which the system is to be
implemented are represented.
60
 Objects and classes

Objects: All entities involved in the solution design are known as
objects.

For example, person, banks, company, and users are
considered as objects.

Every entity has some attributes associated with it and has
some methods to perform on the attributes.

Classes: A class is a generalized description of an object. An object
is an instance of a class.

A class defines all the attributes, which an object can have
and methods, which represents the functionality of the object.

Messages: Objects communicate by message passing.

Messages consist of the integrity of the target object, the
name of the requested operation, and any other action
needed to perform the function.

They are often implemented as procedure or function calls. 61