Software Engineering

Chapter 1
Introduction
 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
• Real-time software

• Business software

• Engineering and scientific software

• Embedded software

• Personal computer software

• Web-based software

• Artificial intelligence software

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

1. Working with limited time and resources

1. Satisfying a customer

1. Managing risk

1. Teamwork and communication

10
 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)

11
 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

12
 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

13
ORTHOGONAL VIEWS OF THE SOFTWARE

⚫ Two Approaches:
Traditional Approach
Objected-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 14
⚫ 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.

15
 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.

16
⚫ 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. 17
 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.

18
 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.

19
Difference between Traditional and Object
Oriented Approach

20
 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

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

22
 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.

23
 Software process xics
• Functionality: the degree of performance of the software
against its intended purpose.
Required functions are:
✓ suitability

✓Accuracy

✓Interoperability

✓Compliance

✓Security

24
• 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

25
• 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

26
• 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

27
• 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

28
• 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

29
 Big questions
• What is a software lifecycle model? When and why should we
use such models?

• Briefly describe each of these models:

− code-and-fix, waterfall, spiral, evolutionary prototyping, staged
delivery, design-to-schedule

• How do we decide which model is the best one to use?

• What are some benefits and drawbacks of each model?

30
 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

31
 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

32
 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

33
 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. 34
 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
35
 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

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

37
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.
38
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.
39
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.

40
 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

41
 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

42
 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
43
 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

44
 comparison

Waterfall model Spiral model

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

45
 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

46
 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?")

47
 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

48
 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

49
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

50
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.

51
 Embracing or fighting timelines
• Fit-to-schedule
− “We will ship on a certain date and cut until it fits”
− useful when you absolutely need to ship by a certain date
− similar to the staged delivery model
• but less flexible because of the fixed shipping date
− requires careful prioritization of features and risks to address
− not recommended

• Fit-to-features/quality
− “We’ll ship the product when it is ready”
− Trade predictable schedules for quality control

52
 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

53
 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.

54
 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.
55