Fis2010 Chapter1

Foundations of Software Engineering
Introduction Foundations of Software Engineering
Dr. Radu Marinescu
Dr. Radu Marinescu
I, Me and Myself :-)

! Associate Professor at Politehnica University of Timi!oara
! Department of Computer Science ! lectures on Software Engineering, Good Object Oriented Design, Quality Assurance & Software Evolution
Some Achievements
! Head of the LOOSE Research Group ! Researcher since 1997

! on Metrics, OO Design, Software Evolution, Reengineering, ! over 30 publications in main international conferences ! PC member in main IEEE/ACM conferences on software maintenance and evolution (ICSM, ICPC, MODELS/UML etc) ! member of the European Network of Excellence in Software Evolution
! Software (Tool) Developer

! autor/co-author of: TableGen, MEMORIA, iPlasma/Insider, inCode
Dr. Radu Marinescu 3 Dr. Radu Marinescu 4
Contact
! email: radu.marinescu@cs.upt.ro ! phone: 404058 ! office: ASPC, P11
http://loose.upt.ro/~oose
! Vital Source of Information
! Lectures
"
this lecture and other lectures on Software Engineering topics
! Labs ! Exam Results ! Resources ! oose07
Dr. Radu Marinescu
Dr. Radu Marinescu
Bibliography...
Examen SCRIS (+ oral pentru mariri de la 8 la 10)

! 3h ! asimilare i nelegere real de cunotine
! NU reproducere mecanic de text!
! surse multiple de informaie

! citii mult i formai-v o prere!
! teorie + probleme
! promovabile doar atomic ! un numr mare de subiecte mici ! la probleme la fel
! Mrire examen scris+oral

! oral din toat materia pentru marire de la 8 la 10
Joys of Programming [Brooks,1995]

! Joy of creating things
! and pleasure of making useful things for the others
Goals, Roles and Myths of Software Engineering
! Fascination of fashioning complex puzzle-like objects ! Delight of working in a highly tractable (flexible) medium
! Slightly removed from the realm of pure ideas ! Easy to polish and rework ! Its fun because it gratifies creative longings
! Joy of always learning
Dr. Radu Marinescu
Dr. Radu Marinescu
10
Woes of Programming [Brooks,1995]

! We must perform perfectly ! Dependency upon others
! Including dependencies on other peoples imperfections ! Study and fix things that in an ideal world would be perfect
Software Crisis in the 60s

! Rapid increase of computer power and complexity of
problems to be solved
! Difficulty to write programs that are:

! Correct ! Understandable ! Verifiable
! Creativity is not the whole story

! Designing grand concepts is fun, finding little bugs is just work :-(
! Products are oftentimes obsolete upon (or before) completion

! Laws of Software Evolution
Dr. Radu Marinescu
11
Dr. Radu Marinescu
12
Root of Software Crisis

! Complexity
! Orders of magnitude larger and more complex than previously developed software
In other words
"The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, thus programming has become an equally gigantic problem."
E.W.Dijkstra, 1972
(The Humble Programmger, ACM Turing Award Lecture)
! Expectations
! Hardware prices were going down, prices for software were increasing dramatically
! Change
! Need to maintain and evolve programs
Dr. Radu Marinescu
13
Dr. Radu Marinescu
14
1st Conference on Software Engineering (1968)
Small vs. Large Projects

! Small projects can be understood and implemented by one
person
! For 1 person, by 1 person
! Large projects require division of labor, integration,

management
! For many people, by many people
! Real systems are more than just code ! Lets see

Program vs. Software [Brooks,1995]

x3 Programming System
(Interfaces, System Integration)
The Tar Pit of Software [Brooks,1995]
Program
x3 Programming Product
(Generalization, Testing, Documentation, Maintenance)
Dr. Radu Marinescu
Programming Systems Product

17 Dr. Radu Marinescu 18
Large-system programming has [...] been such a tar-pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systems -few have met goals, schedules, and budgets .... No one thing seems to cause the difficulty, any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion.
F.P.Brooks, 1995
The challenge and the mission are to find real solutions to real problems, on actual schedules with available resources.
F.P.Brooks, 1995
Dr. Radu Marinescu
19
Dr. Radu Marinescu
20
What is software engineering?

! Software engineering is an engineering discipline that is concerned
with all aspects of software production.
What do we need to learn ?

! Processes
! how to manage long-term development/deployment of software
"
what are the phase and whats the flow?
! Adequate usage of appropriate tools and techniques depending on

! the problem to be solved, ! development constraints ! resources available.
! Techniques
! how should we approach each phase of the process?
! Tools
! how to automate as much as possible of the process?
! Software engineering is concerned with methods, techniques and

tools for professional software development.
Dr. Radu Marinescu
21
Dr. Radu Marinescu
22
What is CASE? (Computer-Aided Software Engineering)
3 Major questions about software engineering

1. What is software? 2. What are the costs? 3. What is good software?
! Software systems that are intended to provide
automated support for software process activities. !often used for method support.
! Upper-CASE
! Tools to support the early process activities of requirements and design;
! Lower-CASE
! Tools to support later activities such as programming, debugging and testing.
Dr. Radu Marinescu
23
Dr. Radu Marinescu
24
What is software?
! Computer programs and associated documentation

! e.g. requirements, design models and user manuals.
! Software products may be

Q1: What is Software?
! Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word. ! Custom - developed for a single customer according to their specification.
! New software can be created by

! developing new programs, ! configuring generic software systems or ! reusing existing software.
Characteristics of Software
1. Software is engineered, not manufactured
1. Software is engineered, not manufactured

! Engineered = a human creative process
! analysis, design, construction, testing
! Hardware after being engineered is translated into a

2. Software does not wear out... but it deteriorates physical form (manufacturing)
! e.g. chips, circuit boards etc.
! Software is only about engineering

3. Most software continues to be custom built
! the manufacturing phase does not introduce quality problems ! ...or easily correctable problems
Costs of software are strictly in engineering. Software projects cant be managed as manufacturing projects

CHAPTER 1 E PRODUCT 2. HardwareT HWears Out. Software Doesnt!

8
Ideal Failure Curve for Software

Increased failure rate due to side effects
PA R T O N E
THE PRODUCT AND THE PROCESS
F I G U R E 1.1 Failure curve for hardware Infant mortality

Failure rate
F I G U R E 1.2 Idealized and actual failure curves for software
Failure rate
Wear out
Change Actual curve
Idealized curve
Time
from R.S.Pressman, 2005
Dr. Radu Marinescu 29
Software engineering methods strive to reduce the magnitude of the spikes and the slope of the actual curve in Figure 1.2.
Time
changes are made, it is likely that some new defects will be introduced, causing the from R.S.Pressman, 2005 failure rate curve to spike as shown in Figure 1.2. Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to Dr. Radu Marinescu 30 spike again. Slowly, the minimum failure rate level begins to risethe software is deteriorating due to change. Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. There-
ity is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities are dependent on people, but the relationship between people applied and work accomplished is entirely different (see Chapter 7). Both activities require the construction of a "product" but the approaches are different. Software costs are concentrated in engineering. This means that software proj8
Foundations of cannot be managed as if they were manufacturing projects. ects Software Engineering
Software doesnt wear

Fout, U R E does I G but it 1.2 Idealized and deteriorate. actual failure curves for software
Actual2. SoftwareCurve"wear out." Failure doesn't for Software

Increased failure Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, rate due to side often called the "bathtub curve," indicates that hardware exhibits relatively high faileffects ure rates early in its life (these failures are often attributable to design or manufac-
PA R T O N E
THE PRODUCT AND THE PROCESS
fore, software maintenance involves considerably more complexity than hardware Foundations of Software Engineering maintenance.
Most software continues to be custom built.
Why 3. Although the industry is moving toward component-based assembly, most must it change?
software continues to be custom built. Consider the ! Enhance manner in which the control hardware for a computer-based product is to implement new business requirements. ! designed and built. The design engineer draws a simple schematic of the digital circuitry, does some fundamental analysis to assure that proper function will be achieved, and then goes to the shelf where catalogs of digital components exist. Each
turing defects); defects are corrected and the failure rate drops to a steady-state level
Failure rate
(ideally, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative affects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out.
Change
integrated circuit (called ! Extend & Adapt an IC or a chip) has a part number, a dened and validated
function, ! make a well-dened interface, and a standardmodern systems it interoperable with other more set of integration guidelines. After each component is selected, it can be ordered off the shelf. ! to meet the needs of new computing environments As an engineering discipline evolves, a collection of standard design components is created. Standard screws and off-the-shelf integrated circuits are only two of thousands of standard components that are used by mechanical and electrical engineers as they design new systems. The reusable components have been created so that the engineer can concentrate on the truly innovative elements of a design, that is, the
Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the idealized curve shown in Figure 1.2. Undiscovered defects will cause high failure
Software engineering methods strive to reduce the magnitude of the spikes and the slope of the actual curve in Figure 1.2.
Actual curve
rates early in the life of a program. However, these are corrected (ideally, without introTime from R.S.Pressman, 2005 ducing other errors) and the curve attens as shown.The idealized curve is a gross over-
Idealized curve
Software does not wear new defects will be introduced, causing changes are made, it is likely that someout! But it does deteriorate! the
simplication of actual failure models (see Chapter 8 for more information) for software. However, the implication is clearsoftware doesn't wear out. But it does deteriorate! This seeming contradiction can best be explained by considering the actual curve
The main cause for this in Figure 1.2. Before repeated change failure rate curve to spike as shownphenomenon is the curve can return to the
original steady-state failure rate, another change is requested, causing the curve to deteriorating due to change. Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the
spike again. Slowly, the minimum failure rate level begins to risethe software is
shown in Figure 1.2. During itsDr. Radu Marinescu will undergo change (maintenance). As life, software 31
Laws of Software Evolution

! The Law of Continuing Change (1974): Systems must be continually
adapted else they become progressively less satisfactory.
Software has no sparse parts

! When hardware components wear out, they can be
replaced by sparse parts.
! The Law of Continuing Growth (1980): The functional content of systems

must be continually increased to maintain user satisfaction over their lifetime.
! The Law of Increasing Complexity (1974): As a system evolves its !

complexity increases unless work is done to maintain or reduce it. The Law of Declining Quality (1996): The quality of systems will appear to be declining, unless they are rigorously maintained and adapted to operational environment changes.
! ... but there are no sparse parts for software

! failures indicate design errors or in the process of translating design into machine executable code.
Source: Lehman, M., et al, Metrics and Laws of Software EvolutionThe Nineties View, Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997 Dr. Radu Marinescu 33
Software maintenance involves considerably more complexity than hardware maintenance!

3. Software is still custom- not component-built

! In each engineering discipline standard design components
are created
! e.g. in hardware: integrated circuits
! In software we need more than algorithmic libraries

! reuse both algorithms and data structures ! e.g. GUIs
Q2: What are the Costs?
! Example of reusing in large: Frameworks

! inversion of control: Hollywood Principle
Dr. Radu Marinescu
35
Dr. Radu Marinescu
36
Costs of software engineering

! Software costs often dominate computer system costs. ! Software costs more to maintain than it does to develop.
! For systems with a long life, maintenance costs may be several times development costs.
Main Cost is not coding!

! System Tests are the strongest sequential constraint Brooks Scheduling Rule:
1/3 Planning 1/6 Coding 1/4 Component Test 1/4 System Test
! Software engineering is concerned with cost-effective

software development.
! Fraction devoted to planning is larger ! Half of schedule goes to testing
Not enough testing times is disastrous because bad news come late!
In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. F.P.Brooks
Q3: What makes software GOOD?
Dr. Radu Marinescu
39
Dr. Radu Marinescu
40
Key challenges facing software engineering
! Acceptability
! accepted by the users for which it was designed. ! understandable, usable and compatible with other systems.
! Legacy
! Challenge of maintaining and updating this software ! Avoid software aging [Parnas] ! ...and software entropy[Lehman]
! Dependability
! Software must be trustworthy;
! Efficiency
! Software should not make wasteful use of system resources;
! Heterogeneity
! Cope with heterogeneous platforms and execution environments;
! Maintainability
! Software must evolve to meet changing needs;
! Delivery
! Developing techniques that lead to faster delivery of software;
! Trust
! Techniques that prove that software can be trusted by its users.
Software Myths [Pressman, 2005]

Myths are not heroic legends :) ... they are propagated misinformation!
! Myths are dangerous because:
Software Myths
1. they appear reasonable and intuitive 2. they are hard to change!
! Each involved site has its myths:

! Management myths ! Customer myths ! Developer myths
Dr. Radu Marinescu
43
Dr. Radu Marinescu
44
Management Myths
I. We have books, standards and procedures that guarantee good software
Adding more programmers to a late project... [Brooks 95]
! Project is Planned for 3 people x 4 months ! If there is no time (e.g. we have to finish it in 2 months)
What do we do?? ! ADD MANPOWER
! E.g. employ 3 more people ! Believing that 3 people x 4 months = 6 people x 2 months
Are they up-to-date? Are they used? Are they complete?

II. We buy high-end computers and most expensive CASE tools
Are these used efficiently? Are these customized for specific needs?
III. Outsourcing will release us from software engineering problems
Managing a project externally is harder than doing it internally

IV.If project gets late we will add more programmers and catch up
F.P. Brooks calls this the mythical man-month: Adding people to a late
project, makes the project even later
WRONG!
Types of Tasks
Types of Tasks (2)
Task Requiring Communication Perfectly Partitionable Task

! No inter-communication required ! E.g. reaping wheat
Totally Unpartitionable Task

! Sequential constraints ! More effort no effect on schedule ! E.g. bearing a child
! Effort of communication must be added to the amount of work to be done ! Poorer than even trade of men for months
Task with Complex Interrelationships

! Communication may fully counteract the division of the original task
48
Dr. Radu Marinescu
Communication
Brooks Law
! Training
! Technological, goals of the effort, overall strategy plan of work
! Intercommunication
! For N people involved: N*(N-1)/2 ! E.g. It is 6 x in a team of 4 people compared to a team of 2 people
Adding manpower to a late software project makes it later
Corollaries
Nr. of months of a project depends on its sequential constraints Maximum nr. of people depends on the nr. of independent subtasks
Dr. Radu Marinescu
49
Dr. Radu Marinescu
50
Customer Myths
I. Just sketching the requirements is enough to start building software II. Requirements can permanently change at a low cost because software is flexible
Developer Myths
I. Once we write a program and get it to work, our job is done
the sooner you begin writing code the longer itll take to get done
II. The only deliverable work product is the working program
program is only a part of a working configuration, which also includes

documentation
III. Software engineering will make use create voluminous and unnecessary documentation, which slows us down
Pressman: SWE is not about creating documents. Its about creating

quality. Better quality leads to reduced work.
from R.S.Pressman, 2005


Fis2010 Chapter1

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Fis2010 Chapter1

Transféré par

Droits d'auteur :

Formats disponibles

Foundations of Software Engineering

Foundations of Software Engineering

Introduction Foundations of Software Engineering

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

I, Me and Myself :-)

! Head of the LOOSE Research Group ! Researcher since 1997

! Software (Tool) Developer

Foundations of Software Engineering

Foundations of Software Engineering

this lecture and other lectures on Software Engineering topics

! Labs ! Exam Results ! Resources ! oose07

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

Examen SCRIS (+ oral pentru mariri de la 8 la 10)

! surse multiple de informaie

! Mrire examen scris+oral

Foundations of Software Engineering

Foundations of Software Engineering

Joys of Programming [Brooks,1995]

Goals, Roles and Myths of Software Engineering

! Joy of always learning

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

Woes of Programming [Brooks,1995]

Software Crisis in the 60s

! Difficulty to write programs that are:

! Creativity is not the whole story

! Products are oftentimes obsolete upon (or before) completion

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

Root of Software Crisis

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

1st Conference on Software Engineering (1968)

Small vs. Large Projects

! Large projects require division of labor, integration,

! Real systems are more than just code ! Lets see

Foundations of Software Engineering

Foundations of Software Engineering

Program vs. Software [Brooks,1995]

The Tar Pit of Software [Brooks,1995]

Programming Systems Product

Foundations of Software Engineering

Foundations of Software Engineering

Dr. Radu Marinescu

Dr. Radu Marinescu

Foundations of Software Engineering

Foundations of Software Engineering

What is software engineering?

What do we need to learn ?

what are the phase and whats the flow?