1 / 40

Software Engineering HT06

Software Engineering HT06. Annabella Loconsole bella @cs.umu.se http://www.cs.umu.se/~ bella http://www.cs.umu.se/kurser/TDBB12/HT06/. Lecture part Traditional lectures 1 guest lecture 3 group exercises 2 assignments Written examination. Project part Teamwork Prototype development

jackson-daugherty
Download Presentation

Software Engineering HT06

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 HT06 Annabella Loconsole bella@cs.umu.se http://www.cs.umu.se/~bella http://www.cs.umu.se/kurser/TDBB12/HT06/

  2. Lecture part Traditional lectures 1 guest lecture 3 group exercises 2 assignments Written examination Project part Teamwork Prototype development Team meetings Oral presentation of results Written reports Course Organisation Examination: Assignments + Exam+ Project

  3. Contents • L1: Introduction • L2: Requirements engineering • L3: Project management • L4: Software design • L5: Detailed design and coding • L6: Verification and Validation • L7: Maintenance • Guest Lecture: Product line engineering (?)

  4. Introduction • What is software engineering • Software development processes • Software quality • Approaches to improve quality

  5. Ariane 5 Failure (in ’96 and ’02) Inertial Reference computer (SRI-1) tried to convert 64-bit float value to 16-bit signed integer. Value too large, raised exception. SRI-1 computer shut down. Redundant SRI-2 computer performed same conversion, produced same exception. SRI-2 sent bad data to flight control computer, which then put the launcher into an unstable flight trajectory. Result: Self-destruct mechanism was activated. Failure Cause: improperly constrained computation. http://news.bbc.co.uk/2/hi/science/nature/2565387.stm http://www.esa.int/export/esaCP/ESACVS7708D_index_0.html

  6. COMPUTER SCIENCE ENGINEERING PRINCIPLES CUSTOMER Proven Techniques Computer Functions Theories Problem SOFTWARE ENGINEERING What is Software Engineering? “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” Definition proposed by Fritz Bauer at the NATO conference ‘68 in Garmisch [NRB 76] Tools and Techniques to Solve Problem

  7. Elements of Software Engineering Methods Technical “how tos” to support software development tasks • Languages Notations to support methods Tools (Semi-) automated support for (the usage of) methods and languages Processes Coordination and management of software development tasks supported by methods, languages, and tools Economically produce quality software

  8. Software processes • A structured set of activities required to develop a software system • Specification; • Design; • Validation; • Evolution. • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

  9. The Waterfall Model Requirements Analysis Specification Require- ments Planning Design Coding Testing Installation Operation and Maintenance

  10. The Spiral Model DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES AND RISKS Constraints4 Risk analysis4 Constraints3 Risk analysis3 Alternatives4 Constraints2 Risk analysis2 Alternatives3 Risk analysis1 Alternatives2 Constraints1 Proto- type2 Proto- type3 Proto- type4 Alternatives1 Budget4 Budget3 Budget2 Budget1 Prototype1 start Simulations, models Requirements, life-cycle plan Concept of operation Software requirements Detailed design Development plan Software design Validated requirements Code Integration and test plan Validated, verified design Unit test System test Plan next phase DEVELOP AND TEST PLAN Acceptance test

  11. Waterfall vs. Spiral Model Waterfall Model Spiral Model Complex, iterative model; many integrated tasks Model Complexity Simple, linear sequence of phases Management Document driven Risk driven Continuous evaluation, integrated into the model Quality Control Natural milestone after each phase Customer interaction Prototypes are built and evaluated by customers in every iteration No Low (risk analysis is integrated in the model) Risk High (late feedback) Usability Small and/or low risk projects Large projects

  12. Version- and Confi- guration Control Maintenance Iterations Requirements Engineering Requirements Engineering Requirements Engineering Design Design Design Reuse Documentation Implemen- tation Implemen- tation Implemen- tation Project Management Quality Assurance Incremental and Iterative Processes

  13. Rational Unified Process • RUP is a method of managing OO Software Development • It can be viewed as a Software Development Framework which is extensible and features: • Iterative Development • Requirements Management • Component-Based Architectural Vision • Visual Modelling of Systems • Quality Management • Change Control Management

  14. Rup Organisation along context

  15. Agile processes • Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods: • Focus on the code rather than the design; • Are based on an iterative approach to software development; • Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. • Agile methods are probably best suited to small/medium-sized business systems or PC products.

  16. eXtremeProgramming project

  17. Rules and Practices of Extreme Programming User Stories Release Plan Make frequent small releases Iterative Development iteration Planning Move People Around Daily Stand Up Meeting Simplicity is the Key CRC Cards Create a Spike Solution Never Add Functionality Early • The Customer is Always Available • Coding Standards • Code the Unit Test First • Pair Programming • Sequential Integration • Integrate Often • Collective Code Ownership • Optimise Last • No Overtime • Unit Tests • Acceptance Tests

  18. Component-based software engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis; • Requirements modification; • System design with reuse; • Development and integration. • This approach is becoming increasingly used as component standards have emerged.

  19. Relative Costs of Development Phases Compiled data from 1976-1981, see [Schach 97].

  20. Relative Costs of an Error See [Schach 97].

  21. ?! can lead to can lead to failure human error fault Fault vs Failure

  22. Causes of Errors Study from 1978, see [GoRu 95].

  23. Introduction • What is Software Engineering • Software Development Processes • Software Quality • Approaches to Improve Quality

  24. Quality is ... • … I know it when I see it • … it suits the client/user • … it conforms to the specification • … it has some inherent quality • … it depends on the price

  25. And Quality is … Sponsor User Low costs Functionality Easy to learn Increased productivity Efficiency Easy to remember Short time of delivery Easy to use Flexibility Reliability Few errors Maintainer/ modifier Good design Readable code Good documentation

  26. Functionality Reliability Usability Understandability Efficiency Resource behavior Maintainability Portability Replaceability Suitability Accuracy Interoperability Security Maturity Fault tolerance Recoverability Changeability Time behavior Analyzability Operability Stability Testability Adaptability Installability Conformance Learnability Quality Factors (ISO 9126)

  27. How Companies Pursue Software Quality A survey from the CASE Research Corporation (1990), see [Yourdon 92].

  28. How To Measure Quality? Quality Factor Efficiency • Metrics are (objective) measurements to determine (subjective) quality factors depends on Property/ Criteria Property/ Criteria Property/ Criteria Speed Size determined by Response time LOC ... Metric Metric Metric

  29. To measure efficiency Time behaviour Transactions per second Response time Screen refresh time Resource behaviour KBytes of executables LOC Number of processors To measure usability Training time Number of help frames To measure reliability MTTF (Mean Time To Failure) Availability To measure robustness Time to restart after a failure Probability of data corruption on failure To measure portability Number of target systems Percentage of target dependent statements Some Example Metrics • Measurement is necessary

  30. Analysis: Determine current quality Prediction: Predict future quality Not only code can be measured, but also Products Documentation Design Purpose of Measurement • Resources • Personnel • Budget • Processes • Analysis phase • Test phase

  31. Approaches to Improve Quality • Capability Maturity Model Integrated (CMM) • Personal Software Process (PSP) • Inspections • Standards (ISO9000, ...) • Cleanroom engineering • Statistical quality control • Goal Question Metrics (GQM) • …..

  32. The CMMI model • Developed by SEI for the DoD (Cmm in 1986, Cmmi in 2001) • An integrated capability model that includes software and systems engineering capability assessment. • The model has two instantiations • Staged where the model is expressed in terms of capability levels; • Continuous where a capability rating is computed.

  33. The staged CMMI model

  34. The continuous CMMI model • This is a finer-grain model that considers individual or groups of practices and assesses their use. • The maturity assessment is not a single value but is a set of values showing the organisations maturity in each area. • The CMMI rates each process area from levels 1 to 5. • The advantage of a continuous approach is that organisations can pick and choose process areas to improve according to their local needs.

  35. CMM Results Faults delivered and installed 61 12 7 5 1 CMM level 1 2 3 4 5 Total dev. costs in US$ 5.440.000 1.311.000 728.000 392.000 146.000 Development time 29,8 18,5 15,2 12,5 9,0 Faults detected during dev. 1.348 328 182 97 37 Person months 593,5 143,0 79,5 42,8 16,0 Model predictions for the development of a 200.000 LOC data processing product (1993), see [Schach 97].

  36. CMM Process Maturity Profileof Software Organizations Source: http://www.sei.cmu.edu/sema/profile.html

  37. Goal Question Metric The paradigm helps an organisation to focus on its goals. It consists of three steps: • Specify a set of goals • Generate a set of quantifiable questions • Define a set of metrics

  38. GQM Template Purpose: Analyse some (objects: processes, products, other experience models) for the purpose of (why: characterisation, evaluation, prediction, motivation, improvement) Perspective: with respect to (focus: cost, correctness, defect removal, changes, reliability, user friendliness,...) from the point of view of (who: user, customer, manager, developer, corporation,...) Environment: in the following context (problem factors, people factors, resource factors, process factors,...)

  39. GQM Example Goal: Evaluate the reliability of the final software product Goal:Analyze the final product for the purpose ofevaluationwith respect to defect classes from the point of view of developer in the context of company XYZ Question: What is the defects distribution by phase of entry? How many faults and failures are there in the final product? Metric: Number of Requirements faults, Number of Design faults, MTTF,...

  40. Level 5 KPA Metric Level 4 KPA Metric Question CMM Level 3 Metric KPA Goal Question Level 2 Metric KPA Goal Question Metric Goal Question Metric CMM and GQM

More Related