Transcript Title
Software Engineering
Natallia Kokash email: [email protected]
N. Kokash, Software Engineering 1
Software Engineering
Introduction
Course overview Logistics Literature Practical assignment Evaluation What is Software Engineering?
What does Software Engineer do?
Software Engineering Processes 2 N. Kokash, Software Engineering
Software Engineering
Natallia Kokash , researcher at LIACS
Research experience
Postdoc at Centrum Wiskunde & Informatica (CWI), Amsterdam Ph.D. from University of Trento, Italy (2008) Research in Software Engineering Semantics of Modeling Languages Software Design and Verification Service-Oriented Computing
Industrial Experience
Collaboration with large international companies Thales-France, Telcordia-Poland, PWC.
Two years of experience as Software Engineer Development of banking systems 3 N. Kokash, Software Engineering
Software Engineering N. Kokash, Software Engineering 4
Software Engineering
What will you learn?
Engineering = skill + knowledge This course 70% knowledge and 30% skills Basic concepts & vocabulary of SE Main activities in SE projects Main methods and techniques
excluding: programming
Guest lectures by professionals N. Kokash, Software Engineering 5
Software Engineering
Literature
70% - H. van Vliet,
Software Engineering: Principles and Practice
, 3 rd ed., 2008.
A. Shalloway and J.R. Trott,
“Design Patterns Explained”
(2004) WWW Check my course web page http://homepages.cwi.nl/~kokash/courses.html
These slides are based on the slides by Prof. Dr. Hans van Vliet
6 N. Kokash, Software Engineering
Software Engineering
Course overview
Theme
Course Overview, Introduction to Software Engineering (SE) & Software Development (SD) Lifecycle Requirements Engineering & Configuration Management Software Modeling Software Design & Architectural Styles Software Quality Assurance & Metrics Team Organization & Global SD Software Reuse, Component-based & Service-oriented Computing Design Patterns & Refactoring Software Testing Software Maintenance Cost Estimation, Planning & Control Empirical Research in SE
Chapter
1, 2, 3.1-3.2
4, 9 3.3-3.9,10 11, 12 6 5, 20 17, 18,19 tbd 13 14 7, 8 tbd 7 N. Kokash, Software Engineering
Software Engineering
Logistics
Lecturer (B.Sc. Informatica & Economie, Den Haag)
Dr. Natallia Kokash
Lecturer (B.Sc. Informatica, Leiden)
Drs. Werner Heijstek
Werkgroepdocent, Leiden
Christoph Johann Stettina, M.Sc
Course Manager
Dr. Michel R.V. Chaudron You may take hoorcolleges (but not werkcolleges) at either location The schedule for Leiden can be found at www.liacs.nl
Check slides by
Drs.
W. Heijstek http://www.liacs.nl/~heijstek/se11-slides/ 8 N. Kokash, Software Engineering
Software Engineering Team of 3-4 people Focus on a proper development process Results: requirements specification, software design, implementation, documentation and testing report Any tools or programming languages (pointers to useful tools & libraries will be given) 9 N. Kokash, Software Engineering
Software Engineering
Problem
Convert a picture of a UML class diagram (.bmp, .jpg) to a UML class diagram in XMI format 10 N. Kokash, Software Engineering
Software Engineering
Details
Retrieve images of UML class diagrams from Google images Recognize basic shapes (rectangles, arrows) Use optical character recognition (OCR) tools to recognize names of classes, attributes, annotations, etc.
Create a graph-based representation of a recognized class diagram Write an XMI file 11 N. Kokash, Software Engineering
Software Engineering
Final evaluation
50% written exam But > 5.5
50% practical assignment 25% Requirement specification 25% Software architecture and design 25% Implementation 25% Quality evaluation N. Kokash, Software Engineering 12
Software Engineering
Software Crises
“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, programming has become an equally gigantic problem.”
Edsger Dijkstra, The Humble Programmer, Communications of the ACM (1972)
13 N. Kokash, Software Engineering
Software Engineering
Who is Edsger Dijkstra?
Born in Rotterdam in 1930.
Studied theoretical physics at the University of Leiden where he became interested in “programming” Received numerous awards including Turing Award in 1972 1.300+ publications Helped the emancipation of computer science as a science Best known for his "shortest
path algorithm
” and his hate to the
goto
operator.
14 N. Kokash, Software Engineering
Software Engineering
The crisis manifest
Projects running over-budget Projects running over-time Software was very inefficient Software was of low quality Software often did not meet requirements Projects were unmanageable and code difficult to maintain Software was never delivered 15 N. Kokash, Software Engineering
Software Engineering
The beginning of Software Engineering
1968/69 NATO conferences: introduction of the term Software Engineering Idea: software development is not an art, or a bag of tricks Build software like we build bridges N. Kokash, Software Engineering 16
Software Engineering
Definition
Software Engineering
is the application of a systematic , disciplined , quantifiable approach to the development, operation , and maintenance of software; that is, the application of engineering to software N. Kokash, Software Engineering 17
Software Engineering
Famous software failures
Military
Mariner 1 rocket (1962) Cost: $18.5 million Soviet anti-missile warning system (1983) Patriot missile system (1991) 28 soldiers dead, 100 injured
Medicine
Therac-25 (1985) (3 dead, 3 critically injured) Radiation therapy software by Multidata Systems (2000) (8 dead, 20 critically injured) N. Kokash, Software Engineering 18
Software Engineering
Famous software failures
Finance
Wall Street Crash (1987) caused by the NYSE computer system EDS Drops Child Support (2004) Cost: £540 million
Airspace and flight control
ARIANE 5, Flight 501 crash (1996) Cost: $500 million Mars Climate Orbiter crash (1998) Cost: $125 million N. Kokash, Software Engineering 19
Software Engineering
ARIANE Flight 501
Disintegration after 39 sec Caused by wrong data being sent to On Board Computer Large correction for attitude deviation Software exception in Inertial Reference System after 36 sec. Overflow in conversion of a variable from 64-bit floating point to 16-bit signed integer Of 7 risky conversions, 4 were protected Reasoning: physically limited, or large margin of safety In case of exception: report failure and shut down N. Kokash, Software Engineering 20
Software Engineering
Explanations
Inadequate testing
Specification does not contain trajectory data In tests, components that measure altitude and movements of the launcher were simulated by software modules
Wrong type of reuse
If a component works perfectly well in one environment, it doesn’t necessarily do so in another Ariane 5 is much faster than Ariane 4, and horizontal velocity builds up more rapidly excessive values for parameter in question This software doesn’t have any purpose for the Ariane 5, but was still kept
Wrong design philosophy
“If something breaks down, it is caused by a random hardware failure” Action: shut down that part There is no provision for design errors!
N. Kokash, Software Engineering 21
Software Engineering
Further information
Ariane 5: IEEE Computer, January 1997, p. 129-130 http://www.cs.vu.nl/~hans/ariane5report.html
20 Famous Software Disasters http://www.devtopics.com/20-famous-software disasters/ N. Kokash, Software Engineering 22
Software Engineering
Is SE = Engineering?
Software is logical, rather than physical Progress is hard to see (speed progress) Software is not continuous
Further reading:
Henry Petroski, Design Paradigms: Case Histories of Error and Judgement in Engineering A. Spector & D. Gifford, A Computer Science Perspective of Bridge Design, Communication of the ACM 29, 4 (1986) p 267-283 N. Kokash, Software Engineering 23
Software Engineering
Quo Vadis?
It takes at least 15-20 years for a technology to become mature Software engineering has made tremendous progress There is no silver bullet N. Kokash, Software Engineering 24
Software Engineering
The CHAOS report
1994 1996 1998 2000 2002 2004 2006 2009
Successful 16% 27% 26% 28% 34% 29% 35% 32% Challenged 53% 33% 46% 49% 51% 53% 46% 44% Failed 31% 40% 28% 23% 15% 18% 19% 24% http://www.projectsmart.co.uk/docs/chaos-report.pdf
25 N. Kokash, Software Engineering
Software Engineering
Famous Engineering Disasters
Tacoma Narrows bridge (1940) (1 dog dead) Hyatt Regency Hotel Walkway Collapse (1981) 114 dead, >200 injured N. Kokash, Software Engineering 26
Software Engineering
Famous Engineering Disasters
Chernobyl Nuclear Power Plant (1986) (at least 5000 dead, 336000 relocated) Air crashes: DC10-S (1979) (271 dead) Aloha Airlines Flight 243 (1988) (1 dead) 27 N. Kokash, Software Engineering
Software Engineering
Relative distribution of software/ hardware costs
100 Hardware Development 60 20 1955
N. Kokash, Software Engineering
Software 1970 Year Maintenance 1985
28
Software Engineering
Types of Software
Custom
For a specific customer
Generic
Sold on open market Often called COTS (Commercial Off The Shelf) Shrink-wrapped
Embedded
Built into hardware Hard to change N. Kokash, Software Engineering 29
Software Engineering
Types of software
Real time software
E.g. control and monitoring systems Must react immediately Safety often a concern
Business Information Systems
Data processing Used to run businesses Accuracy and security of data are key N. Kokash, Software Engineering 30
Software Engineering
Central themes
LARGE programs COMPLEX programs Software EVOLVES Software COSTS Software is developed by TOGETHER by many people Software must EFFECTIVELY support users SE depends on knowledge transfer from DIFFERENT disciplines SE is about finding a BALANCE N. Kokash, Software Engineering 31
Software Engineering
Simple life cycle model
Problem requirements engineering Requirements specification design Design implementation System testing Working system maintenance N. Kokash, Software Engineering 32
Software Engineering
Requirements Engineering
Yields a description of the DESIRED system: which functions possible extensions required documentation performance requirements Includes a feasibility study Resulting document:
requirements specification
N. Kokash, Software Engineering 33
Software Engineering
Design
Earliest design decisions captured in
software architecture
Decomposition
into parts/components; what are the functions of, and interfaces between, those components?
Emphasis on
what
rather than
how
Resulting document:
specification
N. Kokash, Software Engineering 34
Software Engineering
Implementation
Focus on individual components Goal: a working, flexible, robust, … piece of software
Not a bag of tricks
Present-day languages have a module and/or class concept N. Kokash, Software Engineering 35
Software Engineering
Testing
Does the software do what it is supposed to do?
Are we building the right system? (
validation
) Are we building the system right? (
verification
) Start testing activities in phase 1, on day 1 N. Kokash, Software Engineering 36
Software Engineering
Maintenance
Correcting errors found after the software has been delivered Adapting the software to changing requirements, changing environments, ...
N. Kokash, Software Engineering 37
Software Engineering
Global distribution of effort
design 15% requirements engineering 10% specification 10% coding 20% testing 45%
Rule of thumb: 40-20-40 distribution of effort Trend: enlarge requirements specification/design slots; reduce test slot Beware: maintenance alone consumes 50 75% of total effort N. Kokash, Software Engineering 38
Software Engineering
Distribution of maintenance activities
corrective 21% perfective 50% adaptive 25% preventive 4%
Corrective maintenance
: correcting discovered errors
Preventive maintenance
: correcting latent errors
Adaptive maintenance
: adapting to changes in the environment
Perfective maintenance
: adapting to changing user requirements N. Kokash, Software Engineering 39
Software Engineering
SE in a nutshell
N. Kokash, Software Engineering 40
Software Engineering
What does Software Engineer do?
individually interacting with clients in a team
programming, documenting, planning, presenting, reviewing, reporting
Microsoft 1978
listening, explaining, proving feedback, selling Specializing in different roles designing, programming, testing, brainstorming discussing planning 41 N. Kokash, Software Engineering
Software Engineering
Hammurabi’s Code
64: If a builder builds a house for a man and does not make its construction firm, and the house which he has built collapses and causes the death of the owner of the house, that builder shall be put to death.
… 73: If it cause the death of a son of the owner of the house, they shall put to death a son of that builder.
N. Kokash, Software Engineering 42
Software Engineering
Software Engineering Ethics
Act consistently with the public interest Act in a manner that is in the best interest of the client and employer Ensure that products meet the highest professional standards possible Maintain integrity in professional judgment Managers shall promote an ethical approach Advance the integrity and reputation of the profession Be fair to and supportive of colleagues Participate in lifelong learning and promote an ethical approach N. Kokash, Software Engineering 43
Software Engineering
A broader view on SD
information planning boundary conditions input documentation software people program program output procedures N. Kokash, Software Engineering 44
Software Engineering
Contents of project plan
Introduction Process model Organization of project Standards, guidelines, procedures Management activities Risks Staffing Methods and techniques Work packages Resources Quality assurance Budget and schedule Changes Delivery 45 N. Kokash, Software Engineering
Software Engineering
Project control
Time, both the number of man-months and the schedule Information, mostly the documentation Organization, people and team aspects Quality, not an add-on feature; it has to be built in Money, largely personnel N. Kokash, Software Engineering 46
Software Engineering
Managing time
Measuring progress is hard (“we spent half the money, so we must be halfway”) Development models serve to manage time More people less time?
Brooks’ law:
adding people to a late project makes it later 47 N. Kokash, Software Engineering
Software Engineering
Managing information
Documentation Technical documentation Current state of projects Changes agree upon …
Agile projects:
less attention to explicit documentation, more on tacit knowledge held by people N. Kokash, Software Engineering 48
Software Engineering
Managing people
Managing expectations Building a team Coordination of work
N. Kokash, Software Engineering
49
Software Engineering
Managing quality
Quality has to be designed in Quality is not an afterthought Quality requirements often conflict with each other Requires frequent interaction with stakeholders N. Kokash, Software Engineering 50
Software Engineering
Managing cost
Which factors influence cost?
What influences productivity?
Relation between cost and schedule N. Kokash, Software Engineering 51
Software Engineering
Software Development Methods
Projects are large and complex A phased approach to control it is necessary Traditional models are document-driven: there is a new pile of paper after each phase is completed Evolutionary models recognize that much of what is called maintenance is inevitable 52 N. Kokash, Software Engineering
Software Engineering
Waterfall model
Requirements eng.
Iteration Feedback V&V Validation
Are we building the right system
?
Verification A
re we building the system right
? Requirements are fixed as early as possible Design V&V Implementation V&V Testing V&V Maintenance V&V 53 N. Kokash, Software Engineering
Software Engineering
V-model
Requirements engineering Acceptance testing Global design Integration testing Detailed design Unit testing Problems Coding Too rigid Developers cannot move between various abstraction levels N. Kokash, Software Engineering 54
Software Engineering
Evolutionary model
Waterfall Model (Mid 70ies) Requ. Eng. & Architecting Specification Design Implementation Test Evolutionary Models (80ies) Increments (Spiral cycles) Iteration N. Kokash, Software Engineering Scope 55
Software Engineering
Win-Win Spiral Model
1. Identify next-increment stakeholders 2. Identify stakeholders objectives and win conditions / values (Boehm, 1998) Emphasizes continuous stakeholder alignment 3. Reconcile win conditions Establish next-increment objectives, constraints & alternatives 4. Evaluate product and process alternatives Resolve risks 7. Verify & commit 6. Implement product & process definitions 5. Define next-increment of product & process, inclusive partitions 56 N. Kokash, Software Engineering
Software Engineering
Incremental development
A software system is delivered in small increments The waterfall model is employed in each phase The user is closely involved in directing the next steps Incremental development prevents over-functionality 57 N. Kokash, Software Engineering
Software Engineering
Incremental development
delivered system
design build install evaluate first incremental delivery design build install evaluate second incremental delivery increment 1 increment 2 design build install evaluate third incremental delivery Each component delivered must give some benefit to the stakeholders increment 3 58 N. Kokash, Software Engineering
Software Engineering
Velocity tracking
Measure team productivity Unit of work – hours, days, story points, ideal days Interval – week, month N. Kokash, Software Engineering 59
Software Engineering
Prototyping
Requirements elicitation is difficult software is developed because the present situation is unsatisfactory however, the desirable new situation is as yet unknown Used to obtain the requirements of some aspects of the system Should be a relatively cheap process use rapid prototyping languages and tools not all functionality needs to be implemented production quality is not required N. Kokash, Software Engineering 60
Software Engineering
Prototyping as a tool for SE
Requirements engineering design design implementation implementation testing testing maintenance N. Kokash, Software Engineering 61
Software Engineering
Prototyping approaches
Throwaway prototyping: the n-th prototype is followed by a waterfall-like process Evolutionary prototyping: the n-th prototype is delivered 62 N. Kokash, Software Engineering
Software Engineering
Prototyping, advantages
The resulting system is easier to use User needs are better accommodated The resulting system has fewer features Problems are detected earlier The design is of higher quality The resulting system is easier to maintain The development incurs less effort 63 N. Kokash, Software Engineering
Software Engineering
Prototyping, disadvantages
The resulting system has more features The performance of the resulting system is worse The design is of less quality The resulting system is harder to maintain The prototyping approach requires more experienced team members 64 N. Kokash, Software Engineering
Software Engineering
Recommendations for prototyping
The users and the designers must be well aware of the issues and the pitfalls Use prototyping when the requirements are unclear Prototyping needs to be planned and controlled as well 65 N. Kokash, Software Engineering
Software Engineering
The plan
N. Kokash, Software Engineering 66
Software Engineering
Reality
N. Kokash, Software Engineering 67
Software Engineering
Recent developments
Rise of agile methods Shift from producing software to using software Software development becomes more heterogeneous Success of open source software N. Kokash, Software Engineering 68
Software Engineering
The Agile Manifesto (2001)
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” .
N. Kokash, Software Engineering 69
Software Engineering
12 principles of Agile SE:
Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Close, daily co-operation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances 70 N. Kokash, Software Engineering
Software Engineering
Popular agile methods
Rapid Application Development (RAD) & Dynamic System Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) Unified Processes: Agile Unified Process (AUP) Open Unified Process (OpenUP)/Basic Essential Unified Process (EssUP) Scrum N. Kokash, Software Engineering 71
Software Engineering
RAD
Evolutionary development
, with time boxes : fixed time frames within which activities are done; Time frame is decided upon first, then one tries to realize as much as possible within that time frame; Other elements: Joint Requirements Planning (JRD) and Joint Application Design (JAD), workshops in which users participate; Requirements prioritization through a
triage
; Development in a SWAT team
:
Skilled Workers with Advanced Tools 72 N. Kokash, Software Engineering
Software Engineering
DSDM
Dynamic Systems Development Method, #1 RAD framework in UK Fundamental idea:
fix time
and
resources
(
timebox
), adjust functionality accordingly One needs to be a member of the DSDM consortium 73 N. Kokash, Software Engineering
Software Engineering
DSDM phases
Feasibility: delivers feasibility report and outline plan, optionally fast prototype (few weeks) Business study : analyze characteristics of business and technology (in workshops), delivers System Architecture Definition Functional model iteration: time-boxed iterative, incremental phase, yields requirements Design and build iteration Implementation : transfer to production environment 74 N. Kokash, Software Engineering
Software Engineering
DSDM practices
Active user involvement is imperative Empowered teams Frequent delivery of products Acceptance determined by fitness for business purpose Iterative, incremental development All changes are reversible Requirements baselined at high level Testing integrated in life cycle Collaborative, cooperative approach shared by all stakeholders is essential 75 N. Kokash, Software Engineering
Software Engineering
Extreme Programming (XP)
Everything is done in small steps The system always compiles, always runs Client as the center of development team Developers have same responsibility w.r.t. software and methodology 76 N. Kokash, Software Engineering
Software Engineering
13 practices of XP
Whole team: client part of the team Metaphor: common analogy for the system The planning game, based on user stories Simple design Small releases (e.g. 2 weeks) Customer tests Pair programming Test-driven development: tests developed first Design improvement (refactoring) Collective code ownership Continuous integration: system always runs Sustainable pace: no overtime Coding standards 77 N. Kokash, Software Engineering
Software Engineering
Differences
Lightweight (Agile) Heavyweight
Developers Customers Requirements Architecture Size Primary objective Knowledgeable, collocated, collaborative.
Plan-driven, adequate skills, access to external knowledge.
Dedicated, knowledgeable, collocated, collaborative, representative, empowered Largely emergent, rapid change Designed for current requirements Smaller teams and products Rapid value Access to knowledgeable, collaborative, representative, empowered customers Knowable early, largely stable Designed for current and foreseeable requirements Larger teams and products High assurance 78 N. Kokash, Software Engineering
Software Engineering
Heterogeneity
Old days: Software development department had everything under control Nowadays: Teams scattered around the globe Components acquired from others Includes open source parts Services found on the Web N. Kokash, Software Engineering 79
Software Engineering
Producing software means using software!
Builders build pieces, integrators integrate them Component-Based Development (CBSD) Software Product Lines (SPL) Commercial Off-The-Shelves (COTS) Service Orientation (SOA) N. Kokash, Software Engineering 80
Software Engineering N. Kokash, Software Engineering Software engineering is a balancing act, where trade-offs are difficult Solutions are not right or wrong; at most they are better or worse Most of maintenance is (
inevitable
) evolution SD project control concerns: time, information, organization, quality, money There are many lifecycle models Agile projects do less planning than document-driven projects 81
Software Engineering
Homework
Which SE model is the most suitable for the assignment project and why?
Write down your development plan Use RUP
Software Development Plan
template Read chapters 1,2 & 3.1-3.2
N. Kokash, Software Engineering 82
Software Engineering
Software Engineering (3
rd
Ed.)
1. Introduction 2. Introduction to Software Engineering Management 3. The Software Life Cycle Revisited 4. Configuration Management 5. People Management and Team Organization 6. On Managing Software Quality 7. Cost Estimation 8. Project Planning and Control 9. Requirements Engineering 10. Modeling 11. Software Architecture 12. Software Design 13. Software Testing 14. Software Maintenance 17. Software Reusability 18. Component-Based Software Engineering 19. Service Orientation 20. Global Software Development N. Kokash, Software Engineering 83