1 / 83

Software Engineering

Software Engineering. Natallia Kokash email: nkokash@liacs.nl. Introduction. Course overview Logistics Literature Practical assignment Evaluation What is Software Engineering? What does Software Engineer do? Software Engineering Processes. Industrial Experience

marsha
Télécharger la présentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Natallia Kokash email: nkokash@liacs.nl N. Kokash, Software Engineering

  2. Introduction • Course overview • Logistics • Literature • Practical assignment • Evaluation • What is Software Engineering? • What does Software Engineer do? • Software Engineering Processes N. Kokash, Software Engineering

  3. Industrial Experience • Collaboration with large international companies • Thales-France, Telcordia-Poland, PWC. • Two years of experience as Software Engineer • Development of banking systems • NatalliaKokash, 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 N. Kokash, Software Engineering

  4. N. Kokash, Software Engineering

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

  6. Literature These slides are based on the slides by Prof. Dr. Hans van Vliet • 70% - H. van Vliet, Software Engineering: Principles and Practice, 3rd 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 N. Kokash, Software Engineering

  7. Course overview N. Kokash, Software Engineering

  8. Logistics Check slides by Drs. W. Heijstekhttp://www.liacs.nl/~heijstek/se11-slides/ • Lecturer (B.Sc. Informatica & Economie, Den Haag) • Dr. NatalliaKokash • 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 N. Kokash, Software Engineering

  9. 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) N. Kokash, Software Engineering

  10. Problem Convert a picture of a UML class diagram (.bmp, .jpg) to a UML class diagram in XMI format N. Kokash, Software Engineering

  11. 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 N. Kokash, Software Engineering

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

  13. 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.” EdsgerDijkstra, The Humble Programmer, Communications of the ACM (1972) N. Kokash, Software Engineering

  14. Who is EdsgerDijkstra? 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 gotooperator. N. Kokash, Software Engineering

  15. 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 unmanageableand code difficult to maintain Software was never delivered N. Kokash, Software Engineering

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

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

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

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

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

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

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

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

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

  25. The CHAOS report http://www.projectsmart.co.uk/docs/chaos-report.pdf N. Kokash, Software Engineering

  26. Famous Engineering Disasters Tacoma Narrows bridge (1940) (1 dog dead) Hyatt Regency Hotel Walkway Collapse (1981) 114 dead, >200 injured N. Kokash, Software Engineering

  27. 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) N. Kokash, Software Engineering

  28. Relative distribution of software/ hardware costs 100 Hardware Development 60 Percent of total cost Software 20 Maintenance 1955 1970 1985 Year N. Kokash, Software Engineering

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

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

  31. Central themes • LARGE programs • COMPLEX programs • Software EVOLVES • Software COSTS • Software is developed by TOGETHERby 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

  32. Simple life cycle model Problem requirements engineering Requirements specification design Design implementation System testing Workingsystem maintenance N. Kokash, Software Engineering

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

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

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

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

  37. Maintenance Correcting errors found after the software has been delivered Adapting the software to changing requirements, changing environments, ... N. Kokash, Software Engineering

  38. Global distribution of effort design 15% coding 20% requirements engineering 10% specification 10% 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

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

  40. SE in a nutshell N. Kokash, Software Engineering

  41. What does Software Engineer do? in a team interactingwith clients individually Microsoft 1978 programming, documenting, planning, presenting, reviewing, reporting listening, explaining, proving feedback, selling Specializing in different roles designing, programming, testing, • brainstormingdiscussingplanning N. Kokash, Software Engineering

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

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

  44. A broader view on SD information planning boundary conditions documentation people software program input output program procedures N. Kokash, Software Engineering

  45. 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 N. Kokash, Software Engineering

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

  47. 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 N. Kokash, Software Engineering

  48. Documentation Technical documentation Current state of projects Changes agree upon … Agile projects: less attention to explicit documentation, more on tacit knowledge held by people Managing information N. Kokash, Software Engineering

  49. Managing people • Managing expectations • Building a team • Coordination of work N. Kokash, Software Engineering

  50. Quality has to be designed in Quality is not an afterthought Quality requirements often conflict with each other Requires frequent interaction with stakeholders Managing quality N. Kokash, Software Engineering

More Related