Transcript Software Engineering

Software Engineering
Introduction to Computer Engineering
by Dr. Mustafa Sanver
Zirve University
Spring 2013
Topics
1. Definitions
Software, Engineering, Software
Engineering (SE)
2. Hardware vs. Software
8. What are SE Methods
9. What is a software process
Models
Requirements
Examples
3. SE: Layered Technology
Process Framework and Activities
Design
Implementation
4. Why needed?
Testing
Software Disasters
10.Myths
5. Software Features
6. History of SE
7. Attributes of good Software
McCall’s Quality Metric
11.Difference between SE and
Computer Science
12.Difference between SE and
System Engineering
Definitions: Software
 Computer programs and associated documentation
such as requirements, design models and user
manuals.
 Software is: (1) instructions (computer programs)
that when executed provide desired features,
function, and performance; (2) data structures that
enable the programs to adequately manipulate
information and (3) documentation that describes
the operation and use of the programs
 Software products may be


Generic - developed to be sold to a range of different
customers e.g. PC software such as Excel or Word.
Custom - developed for a particular customer according to
their specification.
 New software can be created by developing new
programs, configuring generic software systems or
reusing existing software.
http://www.shutterstock.com/
Software: Examples
Desktop Apps OS
Mobile Applications
Games
Scientific Applications
From the last class: Operating Systems
Programming Languages
Web Apps
Definition: Engineering
Engineering is the science, skill, and profession of
acquiring and applying scientific, economic, social, and
practical knowledge, in order to design and also build
structures, machines, devices, systems, materials, and
processes.
Spinnakert Tower: agsd.org.uk
rubberimpex.com
trade.indiamart.com
Transistor:
mycircuits9.blogspot.com
Ataturk Dam: allaboutturkey.com
Helios: rubberimpex.com
Definition: Software Engineering (SE)
 Software engineering is an engineering discipline that is concerned with
all aspects of software production.
 The IEEE definition: Software Engineering: (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. (2) The study of approaches as in (1).
 Software engineers should adopt a
systematic and organised approach to their
work and use appropriate tools and
techniques depending on the problem to
be solved, the development constraints
and the resources available.
SDLC: contrib.andrew.cmu.edu
Hardware vs. Software
Hardware
Software
1.
2.
3.
4.
5.
1.
2.
3.
4.
5.
Manufactured
Wears out
Built using components
Relatively simple
Tangible
Developed/engineered
Deteriorates
Custom built
Complex
Intangible - no laws of physics are applicable
Software: techwench.com
Production line: dreamstime.com
HW vs. SW
1: Manufacturing vs. Development
 Once a hardware product has been manufactured,
it is difficult or impossible to modify. In contrast,
software products are routinely modified and
upgraded.
 In hardware, hiring more people allows you to
accomplish more work, but the same does not
necessarily hold true in software engineering.
 Unlike hardware, software costs are concentrated
in design rather than production.
HW vs. SW
2: Wear vs. Deterioration
Hardware wears out over time
Software deteriorates over time
HW vs. SW
2: Wear vs. Deterioration
Hardware wears out over time
Software deteriorates over time
Yan etkiler
nedeniyle hatalar
Hata
oranı
ilk üretim defoları
Hata
oranı
aşınma
Değişim
Gerçekçi durum
Ideal durum
zaman
zaman
HW vs. SW
3: Component Based vs. Custom Built
 Hardware products typically employ many
standardized design components.
 Most software continues to be custom built.
 The software industry does seem to be moving
(slowly) toward component-based construction.
HW vs. SW
4: Software Complexity
I believe the hard part of building software to be the
specification, design, and testing of this conceptual
construct, not the labor of representing it and testing
the fidelity of the representation.
If this is true, building software will always be hard.
There is inherently no silver bullet.
- Fred Brooks, “No Silver Bullet”
http://www.computer.org/computer/homepage/misc/Brooks/
SE: A Layered Technology
Software Engineering
tools
methods
process model
a “quality” focus
and the next slide from Software Engineering: A Practitioner’s Approach, 6/e, R.S. Pressman & Associates, Inc.
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
Umbrella Activities
Framework Activities (CPMCD)

Software project management (PM)

Formal technical reviews

Communication

Planning

Software quality assurance (SQA)

Modeling
 Analysis of requirements
 Design

Software configuration management (CM)

Work product preparation and production
Construction
 Code generation
 Testing

Reusability management

Measurement
Deployment

Risk management


Why Needed?
“Software engineering is baloney. It makes us create
tons of paperwork, only to slow us down …”
Why needed? – cont.
Windows OS: Blue-screen
MAC OS: Crash Report
Why needed? – cont.
Why not only code it ?
Which event happens more frequently ?
Italy Cruise: abcnews.go.com
Tacoma-narrow bridge: engineeringcivil.com
Which is deadlier ?
http://en.wikipedia.org/wiki/Turkish_Airlines_Flight_1951
http://castlescribe.hispeed.com/fam/remember/nf-challenger.html
From Dr. Rolf Lakaemper’s CIS 068
Why needed? - cont.
20 Famous Software Disasters
www.devtopics.com/20-famous-software-disasters/
List of software bugs
http://en.wikipedia.org/wiki/List_of_software_bugs
Software Disasters
 Medical Machine Kills (1985)
 Cost: Three people dead, three people critically injured
 Disaster: Canada’s Therac-25 radiation therapy machine
malfunctioned and delivered lethal radiation doses to patients.
 Cause: Because of a subtle bug called a race condition, a
technician could accidentally configure Therac-25 so the electron
beam would fire in high-power mode without the proper patient
shielding.
 http://en.wikipedia.org/wiki/Therac-25
Software Disasters – cont.
 Patriot Fails Soldiers (1991)
 Cost: 28 soldiers dead, 100 injured
 Disaster: During the first Gulf War, an American Patriot
Missile system in Saudi Arabia failed to intercept an incoming
Iraqi Scud missile. The missile destroyed an American Army
barracks.
 Cause: A software rounding error incorrectly calculated the
time, causing the Patriot system to ignore the incoming Scud
missile.
 Timer error: 0.000000095
Software Disasters – cont.
 Mars Surveyor '98 Orbiter 1998
 The Mars Climate Orbiter was a 338
kilogram (750 lb) 2.1x1.6x2 meters robotic
space probe launched by NASA on
December 11, 1998 to study the Martian
climate, atmosphere, surface changes
and to act as the communications relay in
the Mars Surveyor '98 program.
 Cost: $125 million
Artist's conception of the Mars Climate Orbiter. Wikipedia.com
 Cause of Failure: metric mixup. The flight system software on the Mars
Climate Orbiter was written to take thrust instructions using the metric unit
newtons (N), while the software on the ground that generated those
instructions used the Imperial measure pound-force (lbf).
Software Disasters – cont.
 Love Virus (2000)
 Cost: $8.75 billion, millions of computers infected,
significant data loss
 Disaster: The LoveLetter worm infected millions of
computers and caused more damage than any other
computer virus in history. The worm deleted files, changed
home pages and messed with the Registry.
 Cause: LoveLetter infected users via e-mail, Internet chat
and shared file systems. The email had an executable file
attachment and subject line, “ILOVEYOU.” When the user
opened the attachment, the virus would infect the user’s
computer and send itself to everyone in the address book.
Software Features
Software is
 a critically important infrastructure component
 a key enabler for
 militarily
 economically
 scientifically
 culturally
But usually
 expensive
 of poor quality
Engine Control Room
History of SE
1968: NATO Software Engineering
Conference in Garmisch (Germany):
Why cannot bridge-building techniques
be used to build operating systems
(‘engineering’) ?
IEEE Standard 610.12 (IEEE, 1990)
Capability Maturity Model (CMM) 1993
ISO-9 126 (ISO, 2001)
Engineering and SE by Example
There are characteristics analogy to physical engineering processes
Building a house:
System Feasibility
•Land and finances
Softwaregarage,
Plans andyou
Requirements
•garden,
are used to age wine, enjoy to
sit by the fireplace, lots of storage, don’t like bauhaus
•Architect will define number of floors and rooms,
Product Design
orientation
of the driveway, size of the garage …
•type
of bricks,
Detailed
Design colour of the walls,…
•Construction
Code
•Entering
Integration (Product Verification)
•Living in the house
Integration (System Test)
•Fixing minor problems, leaking in the roof …
Operations and Maintenance
From Dr. Rolf Lakaemper’s CIS 068
The 4 P’s
 People — the most important element of a
successful project
 Product — the software to be built
 Process — the set of framework activities and
software engineering tasks to get the job done
 Project — all work required to make the product a
reality
26
These courseware materials
are to be used in conjunction
with Software Engineering: A
Practitioner’s Approach, 6/e
and are provided with
permission by R.S.
The Human Factor
• A miracle
• A wonderful tool making things easier
• An incombprehensible tool
unnecessarilly complicating life
• Something that simply should work !
•
•
•
•
Some (holy) lines of code
A technical challenge
A pet
...
Programmer
User
SOFTWARE
Customer
• A hopefully affordable tool
to enhance profit.
Designer
• A reasonably complicated
tool to fulfill the needs
• A technical challenge
A Process Framework-again
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
Umbrella Activities
Framework Activities (CPMCD)

Software project management (PM)

Formal technical reviews

Communication

Planning

Software quality assurance (SQA)

Modeling
 Analysis of requirements
 Design

Software configuration management (CM)

Work product preparation and production
Construction
 Code generation
 Testing

Reusability management

Measurement
Deployment

Risk management


Şemsiye aktiviteleri
Çerçeve aktiviteleri
work tasks
work products
milestones &
deliverables
QA
checkpoints
work tasks
work products
milestones & deliverables
QA checkpoints
Attributes of good Software
The software should deliver the required functionality and performance
to the user and should be maintainable, dependable and acceptable.
Maintainability: Software must evolve to meet changing needs
Dependability/Reliability: being trustworthy
Efficiency : not making wasteful use of system resources
Acceptability: being accepted by the users for which it was
designed. This means it must be understandable, usable and
compatible with other systems.
Quality: The degree to which a system, component, or process
meets specified requirements.
McCall’s Quality Metric
What are SE methods?
 Structured approaches to software development which include system
models, notations, rules, design advice and process guidance.
 Model descriptions
 Descriptions of graphical models which should be produced;
 Rules
 Constraints applied to system models;
 Recommendations
 Advice on good design practice;
 Process guidance
 What activities to follow.
 CASE: Computer-Aided Software Engineering
 Software systems that are intended to provide automated support for
software process activities to support the early process activities of requirements
and design and later activities such as programming, debugging and testing.
What is a software process
 A set of activities whose goal is the development or evolution of software.
 Generic activities in all software processes are:




Specification - what the system should do and its development constraints
Development - production of the software system
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands.
 Another view of the activities:
 Requirement analysis and definition
 System design
 Program design
 Writing the programs
 Unit testing
 Integration testing
 System testing
 System delivery
 Maintenance
Cost: %60 development %40 test or 40-20-40 rule.
http://asfak-ur-rahman.blogspot.com/2011/02/40-20-40-rule-is-best-for.html
Software Development Life
Cycle Activities-SDLC
Independent of how they are organized, the following
activities are involved in the development of software:
From Dr. Rolf Lakaemper’s CIS 068
Developers Roles
SE Process Models
 Waterfall
 Prototype
 Incremental
 Iterative
 V-Model
 Agile
 Spiral
 Rapid Development Model (RAD)
The Waterfall Model
System Feasibility
Validation
Plans +
Requirements
Validation
Product Design
Verification
Detailed Design
Code
Verification
Unit Test
Integration
Product
Verification
Integration
System Test
Operation +
Maintenance
From Dr. Rolf Lakaemper’s CIS 068
Revalidation
V-Model
The V-model of the Systems Engineering Process wikipedia.com
V Süreç Modeli
Sistem
Gereksinimler
Son kullanıcı bakışı
Sistem Tanımları
Tasarımcı bakışı
Sistem
Proje Tanımı Altsistem
Modül
Bitmiş Sistem
Sistem Testi
Altsistem Testi
Modül Testi
Programıc Bakışı
Proje Testi ve
Entegrasyon
Spiral Model
Spiral_model_(Boehm,_1988).svg wikipedia.com
The RAD Model
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
Evolutionary Models: Prototyping
Quick
plan
communication
Modeling
Quick design
Deployment
delivery &
feedback
Construction
of prototype
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
Agile Development
 Individual and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation.
 Responding to change over following a plan
Extreme Programming
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
 A system to control anti-lock braking in a car
 A virtual reality system to support software
maintenance
 A university accounting system that replaces an
existing system
 An interactive travel planning system that helps users
plan journeys with the lowest environmental impact
Process Steps: Requirements

First technical representation of a system

Data collected
 From files, forms, documents
 current systems

Tools: interviews, on-site observations, questionnaires etc.

Find the problems and new requirements & pros and cons of the new system
 Sub-divide (top-down), manual processing, identification of data store,

Findings: analyzed and documented in the form of text and diagrams:
 data flow diagrams (DFD)
 Data dictionary
 Logical data structures etc.

Requirements Models





Scenario-based (system from the user’s point of view)
Data (shows how data are transformed inside the system)
Class-oriented (defines objects, attributes, and relationships)
Flow-oriented (shows how data are transformed inside the system)
Behavioral (show the impact of events on the system states)
Example
Requirements
Use-case examples
Use-Case Diagram Example
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
State Diagram
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
Class Diagram
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
Sequence Diagrams
Load data from file
From Dr. Rolf Lakaemper’s CIS 068
Process Steps: Design
 Architectural
 Component-level
 User Interface
 Pattern-based
Analysis: Top Down Design
Refinement
From Dr. Rolf Lakaemper’s CIS 068
Object Oriented Design
Class Diagram for Phone Book Example:
Actor
Class
Aggregation (“part of”)
Navigability: Source Target
Defined by UML (Unified Modeling Language)
From Dr. Rolf Lakaemper’s CIS 068
Swimlane Diagram Example
Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman
Steps: Implementation
 Programming or coding or implementation or producing
 Pair programming is an agile software development
technique in which two programmers work together at
one workstation
Steps: Testing
 Unit
 Integration
 Validation
 Acceptance
 System
 Definitions
 Failure: The inability of a system or component to perform its
required functions within specified performance requirements.
 Fault: An incorrect step, process, or data definition in a computer
program.
 Error: A human action that produces an incorrect result.
Error, Fault, Failure
Yazılım Geliştirme Prosesi
hata-error
aksaklık fault
arıza failure
Software Errors
Three kinds of errors:
1.Syntax error

Mistakes in the usage of programming language‘s grammer

Compilers catch the at implementation

Not all but most of them are easy to find

Not critical
2.Runtime errors

Critical

Not found by compilers

Exit the program if no recovery code is written

Example: artihmetic (division by zero), null pointer, index out of range.
3.Logical errors

Most critical

Design-time problem and cannot be detacted at compile and run time.

Solution:

carefully check the algorithm

single step tracing

explain and simulate execution with other team members (structured walkthrough)

use program testing strategies Top-down,
Buttom-up, white-box or black-box
Software Quality Assurance
Software Myths
 Affect managers, customers (and other nontechnical stakeholders) and practitioners
 Are believable because they often have elements
of truth,
but …
 Invariably lead to bad decisions,
therefore …
 Insist on reality as you navigate your way through
software engineering
And the next 4 slides from Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
Software Myths

If we get behind schedule, we can add more programmers and catch up.

A general statement about objectives is sufficient to begin building programs.

Change in project requirements can be easily accommodated because software is
flexible.

Once we write a working program, we’re done.

Until I get the program running, I have no way of assessing its quality.

The only deliverable work product for a successful project is the working program.

Software engineering will make us create too much documentation and will slow us
down.
Management Myths
 “We already have a book of standards and
procedures for building software. It does provide my
people with everything they need to know …”
 “If my project is behind the schedule, I always can
add more programmers to it and catch up …”
 “If I decide to outsource the software project to a
third party, I can just relax: Let them build it, and I
will just pocket my profits …”
Customer Myths
 “A general statement of objectives is sufficient
to begin writing programs - we can fill in the
details later …”
 “Project requirements continually change but
this change can easily be accommodated
because software is flexible …”
Practitioner’s Myths
 “Let’s start coding ASAP, because once we write
the program and get it to work, our job is done …”
 “Until I get the program running, I have no way of
assessing its quality …”
 “The only deliverable work product for a successful
project is the working program …”
 “Software engineering is baloney. It makes us
create tons of paperwork, only to slow us down …”
Difference: SE and CS
 Computer science is concerned with
theory and fundamentals; software
engineering is concerned with the
practicalities of developing and
delivering useful software.
 Computer science theories are still
insufficient to act as a complete
underpinning for software
engineering (unlike e.g. physics and
electrical engineering).
Müşteri
Bilgisayar Bilimi
Teoriler
Fonksiyon
Problem
Yazılım Müh.
Çözüm
için
Araçlar
Teknikler
Software Engineering 4e Shari L. Pfleeger Joanne M. Atlee
Difference: SE and System Engineering
 Sytems: A hierarchy of macro-elements
 System engineering is concerned with all aspects of
computer-based systems development including
 Software
 Hardware
 People
 Database
 Documentation
 Procedures (process engineering)
Ferrari GT car manufacturing process: ferrari.com
 System engineers are involved in system specification,
architectural design, integration and deployment.
Varta Manufacturing Process jgdarden.com
 Software engineering is part of this process concerned with
developing the software infrastructure, control, applications
and databases in the system.
Tire making process: eng.buffalo.edu
Conclusion
Software Engineering is crucial to develop good quality
software within budget and schedule to meet the
requirements and specifications.
There is no flawless software but good and better one.
40-20-40 rule
blog.lib.umn.edu
Thank you, Questions?
http://t0.gstatic.com/images?q=tbn:ANd9GcSHQky-dKfrzgqTGBIVoFxgYaN1LmYFsLIyk_l7m6XxT3cilMNfAQ