Software Engineering course


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Engineering course

  1. 1. Software EngineeringIntroduction
  2. 2. course objectives • to understand the difference between traditional and agile approaches to system development • to understand the primary software engineering tools and techniques and how and when to apply them • to develop the capacity to use these understandings in your own practice • overview course – not learn this technique and learn how to apply it in the exercisesSOE: introduction 2
  3. 3. course design traditional development tools, approaches techniques, SPI practices agile (Ivan Aaen) miniproject 1: miniproject 2: miniproject 3: DA TTP evaluationSOE: Introduction 3
  4. 4. the problem• development project success rates in the US: 29% • serious problems: 53% • complete failure: 18%• by budget • <$750,000: success = 55% • >$10,000,000 success = 0%• England (public sector) 84% partial or total failure• estimated overall: 20-30% projects are total failures (abandoned)• ”failure of large and complex information system developments is largely unavoidable” Source: Dangerous Enthusiams: Gauld and GoldfinchSOE: introduction 4
  5. 5. the problem elaborated• the requirements problem: the software does not match the needs of users• the analysis problem: the software contains a model of the external world which cannot be recognized or adapted to by its users• the design problem: the software design inadequately solves the problem, creating issues such as maintainability, adaptivity, portability, security• the quality problem: the system is delivered with bugs, service and usability problems that make it difficult to use• the project management problem: the project becomes delayed and/or over budget; in extreme cases so much so that it is aborted• the change problem: changes in problem or solution, or the project’s environment (such as an economic crisis, or market change) which affect the project• the complexity problem: the interaction of any combination of the aboveSOE: introduction 5
  6. 6. one answer:• the application of engineering principles to software development• “the discipline, art and profession of acquiring and applying technical, scientific and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or inventions” Wikipedia• “the creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property” American Engineers Council• “the application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems”SOE: introduction 6
  7. 7. 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).” - the IEEE Computer Society - SWEBOK (the software engineering body of knowledge) - (not clear that SE is a (natural) science)SOE: introduction 7
  8. 8. SE - related disciplines SWEBOK (2004):SOE: introduction 8
  9. 9. SE in this course• a development • a set of complimentary approach SE tools, techniques • process model and practices designed • associated tools, to support the techniques, practices underlying development • a set of (unspoken) approach assumptions about the • such as project nature of software development and its management, contexts configuration• e.g. traditional management, waterfall estimationSOE: introduction 9
  10. 10. traditional development approach (process)a.k.a• SDLC (Systems Development Life Cycle)• waterfall• linear sequential• big design up front Requirements Design Implementation TestSOE: introduction 10
  11. 11. typical SDLC activities  understand what the customer or user wants (requirements)  understand the context or work process that the computer system will support (analysis)  write a description of the system to be built (specification)  make a upfront paper design for the program (design)  program the system (coding)  debug the resulting program (test)  install or implement the system  support the system in use and redevelop as necessary (operation and maintenance)SOE: introduction 11
  12. 12. NATO-seminar in Garmisch 1968SOE: introduction 12
  13. 13. waterfall modelSOE: introduction 13
  14. 14. Boehm’s Seven Principles (1976) • manage using a sequential life cycle plan • perform continuous validation • maintain disciplined product control • use enhanced top-down structured programming • maintain clear accountability • use better and fewer people • maintain commitment to improve processSOE: introduction 14
  15. 15. SWEBOK = traditional development approachSOE: introduction 15
  16. 16. SWEBOK + associated tools and techniquesSOE: introduction 16
  17. 17. early waterfallproblems NATO-seminar in Garmisch 1968 Rayleigh Curve SOE: introduction 17
  18. 18. A rational design process (Parnas et al, 1986)• ‘ideally, we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in a published proof’• impossible because of: 1. imperfect requirements 2. learning during design work 3. human cognitive limits 4. external change 5. human error 6. preconceived design ideas 7. economic considerations (e.g. reuse of software)• solution: fake it: continuous requirements documentationSOE: introduction 18
  19. 19. Poppendieck 2000: its time to stop faking it• accept that the rational (traditional) model cannot be achieved• focus on iterative and incremental development • requirements and architecture (40%) first • then construction and testSOE: introduction 19
  20. 20. traditional approach: many alternativesalternative examples perceived flaw in traditional software processparticipatory  ETHICS, Scandinavian school responds to lack of serious user involvementdevelopmentcontext‐aware  Contextual Design responds to heavy focus on computer system designmethodsrapid development  RAD responds to poor speed of deliverytest driven  TDD responds to lack of rigor in delivering bug free codedevelopmentagile methods XP, SCRUM responds to process‐rigid, analysis‐heavy and programmer  unfriendly development styleopen source LINUX, REDHAT projects responds to hierarchical and commercially oriented development  stylebusiness‐focused Business Process Re‐ responds to inability to focus on business process innovation and  engineering automation of existing business processsystems theory‐ Soft‐Systems Methodology,  responds to heavy focus on rational analysis and hard systems focused User Centred Design traditionformal methods Z, UPPAAL responds to perceived lack of mathematical or logical rigour in  traditional process SOE: introduction 20
  21. 21. the Aalborg SE tradition agile (Ivan Aaen) development tools, approaches techniques, practices traditional • understand the meta-principles upon which traditional software development is based (not learn how to do it again) • learn agile methods and one alternative set of meta-principles which respond to a particular set of concerns with the traditional development approach • learn software engineering tools, techniques and practices and how to apply them in both situationsSOE: introduction 21
  22. 22. SOE: introduction 22
  23. 23. Software Engineeringdevelopment approaches: process models
  24. 24. waterfall model• linear sequentialSOE: process models 2
  25. 25. V-modelSOE: process models 3
  26. 26. prototyping Qu ick p lan• throwaway Com m unicat ion• evolutionary Mo d e lin g Qu ick d e sig n Deployment De live r y & Fe e dback Const r uct ion of pr ot ot ype SOE: process models 4
  27. 27. iterativeSOE: process models 5
  28. 28. incremental increment # n Co m m u n i c a t i o n Pl a nning M ode li ng analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t est d e l i v e ry fe e dba c k deliv ery of nt h increment increment # 2 Co m m u n i c a t i o n Pl a nning M ode ling analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry fe e dba c k deliv ery of increment # 1 2nd increment Co m m u n i c a t i o n Pla nni ng M ode ling analy s is Co n s t ru c t i o n des ign c ode De p l o y m e n t t es t d e l i v e ry deliv ery of fe e dba c k 1st increment project calendar t imeSOE: process models 6
  29. 29. SOE: process models 7
  30. 30. spiral model(Boehm,1988)SOE: process models 8
  31. 31. unified processSOE: process models 9
  32. 32. SCRUMSOE: process models 10
  33. 33. XPSOE: process models 11
  34. 34. linear v. iterativeSOE: process models 12
  35. 35. Usage Functions Interfaces Class Structure Behavior Model Component Function Component Connecting componentsOOAD – Criteria ComponentsMathiassen Processeset al 13
  36. 36. lifecycle XP Qu ick p lan Com m unicat ion increment # n Co m m u n i c a t i o n Pla nning Mo d e lin g M od e lin g a n a ly s is d e s ig n Co n s t ru c t i o n Q u ick d e sig n c o de De p l o y m e n t t est d e l i v e ry fe e dba c k deliv ery of nt h increment increment # 2 Co m m u n i c a t i o n Pla nn in g M ode ling a n a ly s is Co n s t ru c t i o n d e s ig n c ode De p l o y m e n t t es t d e l i v e ry fe e dba c k deliv ery of increment # 1 2nd increment Deployment Co m m u n i c a t i o n Pla nning M ode ling De live r y an a ly s is de s ig n Co n s t ru c t i o n c od e De p l o y m e n t & Fe e dback Const r uct ion deliv ery of t es t d e l iv e ry fe e dba c k of 1st increment pr ot ot ype project calendar t ime incremental prototypingSOE: process models 14
  37. 37. Software Engineeringtraditional: requirements requirements analysis design ( programming ) test
  38. 38. early project activities• objective: start the project and find out what is to be built• can include: • feasibility study • cost benefit analysis • risk analysis • project initiation • system concept • early planning • team setup • contract negotiation• and requirements analysis/engineeringSOE: requirements 2
  39. 39. the problem addressed:• the requirements problem: the software does not match the needs of users • software features are missing or incomplete • (costly) features are provided which are unnecessary • as a result the user struggles to complete their work task or achieve their objectives, even though the software functions according to its specification and is bug freeSOE: requirements 3
  40. 40. a requirement is:• a specification for what should be implemented - a description of: • how the system should behave • application domain information • constraints on the systems operation • specification of a system property or attributes• a system capability needed by the user 1.1 System Feature 1 to solve a problem or achieve an <Don’t really say “System Feature 1.” State the feature name in just a few words.> objective, and/or a system capability 3.1.1 Description and Priority <Provide a short description of the feature and indicate whether it is of High, that must be met or possessed by a Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale system or system component to satisfy from a low of 1 to a high of 9).> 3.1.2 Stimulus/Response Sequences a contract, standard, specification or <List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements other formally imposed document 3.1.3 associated with use cases.> Functional Requirements• acquired by dialogue with users <Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out• classical division between: the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and • functional necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available.> • non-functional <Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.> SOE: requirements 4
  41. 41. requirements analysis is• a series of analysis techniques to address shortfalls in what users/stakeholders are able to express as their needs and wishes for the system including: • many modelling techniques • evolutionary or throwaway prototyping• and to improve developers’ understanding of their users and their users’ situationsSOE: requirements 5
  42. 42. requirements engineering is:• the attempt to add scientific precision to users’ incomplete accounts of their needs and wishes and developers flawed attempts to understand them• ”Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families."SOE: requirements 6
  43. 43. the requirementsspecification: the endresult• the baseline for all future project activities • future contract negotiations • project planning, estimation, scheduling, cost planning, risk management • analysis and design • acceptance testing • tradeoffs • change control• and the beginning of most its problemsSOE: requirements 7
  44. 44. requirements: problems• from the user: incomplete, contested, badly explained, ambiguous, misunderstood, without technical understanding, socially contested• by the developer: badly understood, poorly interpreted through lack of domain knowledge, poorly documented, under negotiated• churn – change over the lifetime of the project due to poor initial analysis or natural situational evolutionSOE: requirements 8
  45. 45. requirements: managing for changeSOE: requirements 9
  46. 46. requirements: iterative ‘good enough’ strategySOE: requirements 10
  47. 47. Requirements management toolsSOE: requirements 11
  48. 48. the requirements problem expressed visually use domain developer dialogue an agreed, domain mutually understood and relatively stable account of what to buildSOE: requirements 12
  49. 49. difficult or inappropriate situations • users are • very many and/or use domain • very different • difficult to communicate with (children) • the use domain is • unusually expert (eye surgery, investment management) • poorly defined (start-up consultancy) • the software is not primarily determined by user needs • consider: embedded software, missile control system, computer game, ERP systemSOE: requirements 13
  50. 50. classical requirements analysis - supplementsand alternatives• domain engineering (overlaps with system analysis) – obtaining a more precise understanding of the use domain through a variety of domain modelling techniques e.g.: • object modelling • business process modelling • ontology construction SessionVars • and very many others mode: MODE operator: OPERATOR• formal specification language (e.g. Z) patient: PATIENT field: FIELD• prototyping, paper prototyping names: PATIENT fields: FIELD PRESCRIPTION• iterative process counters: FIELD ACCUMULATION• use cases and user stories operator = no_operator operator operators mode = experiment operator physicists names = if mode = therapy then patients else studiesSOE: requirements 14
  51. 51. supplements andalternatives• ethnography• participatory development (e.g. ETHICS, User-Centred Design, Contextual Design, Joint Application Design)• low-tech models (e.g. rich picture)• user workshops, focus groups, virtual communities• on-site customer, product ownerSOE: requirements 15
  52. 52. the requirements problem• traditional solution: application of greater engineering rigour to requirements gathering by means of • structured data gathering with users • better planning • comprehensive, structured documentation, • additional modelling techniques • management of requirements throughout developmentSOE: requirements 16
  53. 53. a research roadmap: Nuseibah + Easterbrook• better modelling and analysis of problem domains, as opposed to the behaviour of software.• development of richer models for capturing and analysing non-functional requirements.• bridging the gap between requirements elicitation approaches based on contextual enquiry and more formal specification and analysis techniques.• better understanding of the impact of software architectural choices on the prioritisation and evolution of requirements.• reuse of requirements models to facilitate the development of system families and the selection of COTS (commercial off-the-shelf).• multi-disciplinary training for requirements practitioners.SOE: requirements 17
  54. 54. Software Engineeringtraditional: analysis requirements analysis design ( programming ) test
  55. 55. the analysis (representation) problem• the software contains a model of the external world which cannot be recognized or adapted to by its usersSOE: requirements 2
  56. 56. analysis• many hundreds of systems analysis and design methodsaka: • requirements analysis • requirements modelling • systems analysis (as in systems analysis and design) • domain analysis • structured analysis • object-oriented analysis • problem and application domain analysis (OOA+D)SOE: analysis 3
  57. 57. use domain code models #include <functional> /* class for the compose_f_gx adapter */ template <class OP1, class OP2> class compose_f_gx_t : public std::unary_function<typename OP2::argument_type, typename OP1::result_type> { private: OP1 op1; // process: op1(op2(x)) OP2 op2; public:domain models // constructor compose_f_gx_t(const OP1& o1, const OP2& o2) : op1(o1), op2(o2) { } // function call typename OP1::result_type operator()(const typename OP2::argument_type& x) const { return op1(op2(x)); } }; /* convenience function for the compose_f_gx adapter */ template <class OP1, class OP2> inline compose_f_gx_t<OP1,OP2> compose_f_gx (const OP1& o1, const OP2& o2) { return compose_f_gx_t<OP1,OP2>(o1,o2); } SOE: analysis 4
  58. 58. analysis models• abstractions• contain: • a set of terms, concepts and relationships, often with a theoretical background • a standardised representation form or modelling language (e.g. UML) • a (usually hidden) set of assumptions about the nature of reality, how it’s understood and what’s important• model forms: • textual (system definition, event list) • pictorial (rich picture) • diagrammatic (entity model, object model, dataflow diagram) • algorithmic (pseudo code, Z) SOE: analysis 5
  59. 59. an interpretation problem users developers formalised user-near program- near use domain informal analysis modelsSOE: analysis 6
  60. 60. classical systems analysis • a classical systems analysis is a description of relevant parts of a use domain, not a plan for a software implementation use domain • ensures that a software design is based on a sound understanding of the context that the software will later be used in • this understanding is often extremely difficult for software engineers to acquire and share • analysis provides a • common communication language for developers • process structure (what to do, when) • consistency and completeness checking • stepwise refinement • programming-related modelling forms which can be the basis for designSOE: analysis 7
  61. 61. what is modelled:• classical systems analysis - three types of analysis: 1. data structure (the structure of information) e.g. ERM 2. process (transformations or operations on data) e.g. dataflow diagram 3. sequence or dynamics (the behaviour of the system over time) e.g. state transition diagram• object orientation conflates the first two D a t a O b jec t D e sc r ip t io n P r o c e s s S p e c ific a tio n (P S P E C ) E n t ity - D a t a F lo w R e la tio n s h ip D ia g r a m D ia g r a m D a t a D ic tio n ar y arch i ectur l S t a te -T r a n s it io n d e ig D ia g r a m d ata C o n tro l S p e c if ica tio n (C S P E C ) d esign SOE: analysis 8
  62. 62. a bewildering array of other analysis forms29th Conference on Conceptual ModellingInformation Modeling Concepts, including Ontologies;Ontological and Semantic Correctness in Conceptual Modeling;Logical Foundations of Conceptual Modeling;Cognitive Foundations of Conceptual Modeling;Conceptual Modeling and Web Information Systems;Business Process Modeling;Conceptual Modeling and Enterprise Architecture;The Semantic Web;Semi-structured Data and XML;Integration of Conceptual Models and Database Schemas;Information Retrieval, Filtering, Classification, Summarization, and Visualization;Methodologies and Tools for Conceptual Design;Evaluation and Comparisons of Conceptual Models and Modeling Methods;Requirements Engineering;Reuse, Patterns, and Object-Oriented Design;Reverse Engineering and Conceptual Modeling;Quality and Metrics of Conceptual Models;Empirical Studies of Conceptual Modeling;Conceptual Change and Schema Evolution;Maintenance of Conceptual Models;Management of Integrity Constraints;Active Concepts in Conceptual Modeling;Spatial, Temporal, and Multimedia Aspects in Conceptual Models;Metadata, its Interpretation and Usage;Conceptual Models and Knowledge Management Systems;Data warehousing, data mining, and business intelligence; andOther Advanced and Cross-Disciplinary Applications of Conceptual ModelsSOE: analysis 9
  63. 63. SOE: analysis 10
  64. 64. case tool support• diagram support and debugging, code generation, document generation, tailored development method support, consistency and completeness checking, reverse engineering, import, model driven architecture support, IDE diagrammer code generator integration, integration with estimation and scheduling tools repository SOE: analysis 11
  65. 65. classical systems analysis: four critiques 1XP• classical systems analysis is unnecessary and time consuming• it promotes the role of the analyst over the programmer• the programmer can obtain the necessary domain understanding from the customer and write it directly into the programSOE: analysis 12
  66. 66. classical systems analysis: four critiques 2Soft Systems Methodology• classical systems analysis does not capture what is really important in a user domain (e.g. the underlying work system – only some minor things which contribute to software design)• it encourages a (false) impression that there is one correct view of a user domain that the analyst can determine and later use as the basis for design SOE: analysis 13
  67. 67. classical systems analysis: four critiques 3Contextual Design• classical systems analysis is the property of the expert systems analyst• it does not promote real dialogue with the stakeholders and users or involve them in any future workSOE: analysis 14
  68. 68. classical systems analysis: four critiques 4Business Process Re-engineering• classical systems analysis focuses on automating an existing (manual) system• it provides no incentive for changing or radically improving the underlying work processSOE: analysis 15
  69. 69. analysis: summary problem: accurate representation of user domain objective: understand the use domain and represent it in a software friendly notation tools and techniques various forms of semi-formal modelling underlying theory systems theory + purpose user domain understanding - develop accurate and communicable domain models which can later be represented as software known weaknesses not always very close either to programmer or to user scope limitation situational – access to a suitable use domain is required principal danger goal displacement SOE: analysis 16
  70. 70. SOE: analysis 17
  71. 71. SOE requirementstraditional: test analysis design ( programming ) test
  72. 72. the quality problem• the system is delivered with bugs, service and usability problems that make it difficult to use• software released too early - users run untested code, which crashes or delivers system-generated error messages• requested functionality is missing, the software runs slowly, interfaces contain major usability errors• calculations are wrong, data is lost or corruptedSOE: test 2
  73. 73. generates 28 test cases (= paths through the code)SOE: test 3
  74. 74. traditional engineering response •validation to demonstrate to the developer and the systemwhy test? customer that the software•problems with meets its requirements •unit testrequirements, •verification •integration testanalysis and to establish that the program •regression testdesign revealed runs as intended without •GUI testlate defects •smoke test•programmer •performance/load testerror in •a test strategy •interface testexecuting the •a test plan •system testdesign •a test suite with test •acceptance/operational cases test •test execution •alpha/beta test •debugging •test reportSOE: test 4
  75. 75. a testing-oriented development process:v model + effective project managementSOE: test 5
  76. 76. a planned process test test test test cases data results reports design test prepare test r un program compare results cases data with test data to test casesSOE: test 6
  77. 77. policies and guidelines•exhaustive test is impossible on •define procedures for tests andnon-trivial systems test cases, e.g.:•test policies define the approach •choose inputs that force the system to generate all errorto be used in selecting system messages;tests e.g.: •design inputs that cause buffers •all functions accessed through to overflow; menus should be tested; •repeat the same input or input •combinations of functions series several times; accessed through the same •force invalid outputs to be generated; menu should be tested; •force computation results to be •where user input is required, all too large or too small. functions must be tested with correct and incorrect input. SOE: test 7
  78. 78. an experienced team developer errors requirements conformanceunderstands the systembut will test "gently" independent tester performanceand is driven by "delivery" must learn about the system, but will attempt to break it an indication and is driven by quality of quality• a professional testing team, with their own tools and structured proceduresSOE: test 8
  79. 79. unit test designed environment interface driver local data structures boundary conditions independent paths error handling paths module stub stub RESULTS Test casesSOE: test 9
  80. 80. structured testing: top down integration A top module is tested with stubs B F G stubs are replaced one at a time, “depth or breadth first” C as new modules are integrated, D E some subset of tests is re-runSOE: test 10
  81. 81. white-box test requirements output... our goal is to ensure that allstatements and conditions have been executed at least once ... input events black-box testSOE: test 11
  82. 82. mathematical and engineering techniques, e.g.:basis path test first, we compute the cyclomatic complexity: number of simple decisions + 1 or number of regions or 1 number of edges – number of nodes + 2 in this case, v(g) = 4 2 next, we derive the independent paths: 4 3 5 6 since v(g) = 4, there are up to four paths path 1: 1,2,3,6,7,8 7 path 2: 1,2,3,5,7,8 8 path 3: 1,2,4,7,8 path 4: 1,2,4,7,2,4, …7,8 finally, we derive test cases to exercise these paths.SOE: test 12
  83. 83. object class test• complete test coverage of a class involves • test all operations associated with an object; • setting and • define test cases for interrogating all object reportWeather, calibrate, test, attributes; startup and shutdown. • exercising the object • using a state model, identify in all possible states. sequences of state transitions to• inheritance makes it be tested and the event more difficult to design sequences to cause these object class tests as the transitions data to be tested is not • for example: localised. • waiting > calibrating > test > transmitting > waitingSOE: test 13
  84. 84. test automation HP QuickTest Professional HP IBM Rational Functional IBM Rational• test is an expensive Tester process phase - test Rational robot IBM Rational workbenches provide a Selenium OpenSource Tool range of tools to reduce Silk Test Microfocus the time required and total Test Complete AutomatedQA test costs. TestPartner Micro Focus• bug tracker Watir OpenSource Tool• unit test: xUnit SilkCentral - Test Management• record and play SilkTest - Automated functional and regression testing SilkPerformer - Automated load and performance testing• acceptance test: Fit, SilkMonitor - 24x7 monitoring and reporting of Web, application FitNesse, EasyAccept and database servers SilkPilot - Unit testing of CORBA objects• ……. SilkObserver - End-to-end transaction management and monitoring for CORBA applications• ……….. SilkMeter - Access control and usage metering SilkRealizer - Scenario testing and system monitoring SilkRadar - Automated defect trackingSOE: test 14
  85. 85. systematic debugging: symptoms & causes • symptom and cause may be geographically separated • symptom may disappear when another problem is fixed • cause may be due to a combination of non-errors • cause may be due to a system or compiler error • cause may be due to cause symptom assumptions that everyone believesSOE: test 15
  86. 86. traditional test ideals: summary• a testing-oriented development process• a planned process• policies and guidelines• an experienced team• a designed environment• white/black box testing• test automation• systematic de-buggingSOE: test 16
  87. 87. traditional test: alternatives and supplements• test driven development (agile)• usability testing• walkthrough/code review• user satisfaction testing• business performance evaluation• model-driven testing (UPPAAL)SOE: test 17
  88. 88. SOE: test 18
  89. 89. Software Engineering requirementstraditional:design analysis design ( programming ) test
  90. 90. SLOC Operating System (Million) Windows NT 3.1 4-5 Windows NT 3.5 7-8• the design problem: the Windows NT 4.0 11-12 software design Windows 2000 more than 29 inadequately solves the Windows XP 40 problem, creating issues Windows Server 2003 50 such as maintainability, adaptivity, portability, Debian 2.2 55-59 Debian 3.0 104 security Debian 3.1 215 Debian 4.0 283SOE: design 2
  91. 91. why design?• program structure• completeness and consistency• complexity management• performance• communication between programmers• planning and organization of development work• maintenance• change readinessSOE: design 3
  92. 92. traditional software design design principals, patterns architectural modelsrequirements design process analysis design specificationSOE: design 4
  93. 93. some design tasks• design strategies – priorities and tradeoffs• architecture design• sub-system/module/component design• detailed component design• data structure (database)• user interface design• processing design• algorithm design• logical/physical designSOE: design 5
  94. 94. design strategy• trade-off of different desirable program characteristics in relation to design context and known principles, criteria, heuristics system characteristics:quality criteria:•usable modular design principles: •performance•secure •security •information hiding•efficient •safety •cohesion (high) •availability•correct •coupling (low) •maintainability•reliable•..... modular design heuristics:•..... •evaluate the first design iteration to•.... reduce coupling and improve cohesion •strive for fan-in depth •......................... •...............................SOE: design 6
  95. 95. the traditional ideal:structured design, planned, top down,sequential, output dependence requirements specification design activities architectural interface component data algorithm abstract design design design structure design specification design software data system interface component algorithm specification structure architecture specification specification specification specification design productsSOE: design 7
  96. 96. the traditional ideal – design derived fromanalysis Process Specification (PSPEC) Data Object Description procedural Entity- design Data Flow Relationship Diagram Diagram interface Data Dictionary design architectural State-Transition design Diagram data Control Specification (CSPEC) design THE ANALYSIS MODEL THE DESIGN MODELSOE: design 8
  97. 97. in practice •stepwise refinement of existing analysis model so that it can be programmedData Object Description Process Specification (PSPEC) •add many missing elements: plug-in procedural design Entity- Relationship Data Flow Diagram components, interface, navigation, Diagram network communication, database Data Dictionary communication etc interface design •partition into separate modules, components architectural State-Transition design Diagram •structure program according to data Control Specification (CSPEC) performance requirements design •describe at several levels of abstraction for different stakeholders THE ANALYSIS MODEL THE DESIGN MODEL SOE: design 9
  98. 98. system architectureSOE: design 10
  99. 99. traditional ideal - deriving architectures from analysis models control hierarchy example transform mapping transaction mappingSOE: design 11
  100. 100. architecture trade-offs traditional ideal: rationality •using large-grain componentsarchitecture in relation to designstrategy improves performance but reduces maintainability.performance •introducing redundant data improves localise critical operations and availability but makes security more minimise communications - use difficult. large rather than fine-grain •localising safety-related features components. usually means more communicationsecurity so degraded performance. use a layered architecture with critical assets in the inner design considerations •is there a generic application architecture that can be localise safety-critical features in used? a small number of sub-systems. •how will the system be distributed?availability •what architectural styles are appropriate? include redundant components and mechanisms for fault •what approach will be used to structure the system? tolerance. •how will the system be decomposed into modules?maintainability •what control strategy should be used? use fine-grain, replaceable •how will the architectural design be evaluated? components. •how should the architecture be documented? SOE: design 12
  101. 101. traditional ideal: generic design structuresimposed externally «component» • OOAD – generic Interface «component» User interface «component» System interface architecture • matches «component» problem/application area division Function «component» Model «component» Technical platform «component» «component» «component» UIS DBS NSSOE: design 13
  102. 102. architectural styles client serverrepository function oriented pipelining (pipes and filters) layered SOE: design 14
  103. 103. traditional ideal – top down decomposition:detailed component design data dictionary <variable> = <expression> if <condition> do stuff; else pseudocode do other stuff; while <condition> do stuff; for <variable> from <first value> to <last value> by <step> do stuff with variable; function <function name>(<arguments>) do stuff with arguments; return something; <function name>(<arguments>) // Function callSOE: design 15
  104. 104. the design documentSOE: design 16
  105. 105. alternatives and complementary techniques• evolutionary design with refactoring (agile)• low-tech design (contextual design)• design pattern movement• metaphors• design standards• guidebooksSOE: design 17
  106. 106. the design problem: traditional engineeringsolutions• structured design, planned, sequential, output dependence• top down design, decomposition• design derived (quasi algorithmically) from earlier analysis• rational argumentation of design trade-offs based on known design principles• generic design structures imposed from outside• precise and detailed documentation that can later be used by a programmer with no prior knowledge of analysisSOE: design 18
  107. 107. SOEUnified ProcessRational Unified Process
  108. 108. UP: iterative not (necessarily) agileSOE: Unified Process 2
  109. 109. • Unified Software Development Process – widely used industry standard software engineering process • commonly referred to as the "Unified Process" or UP • generic process for the UML • free - described in "The Unified Software Development Process", ISBN:0201571692"• UP is: • use case (requirements) driven • risk driven • architecture centric • iterative and incremental• UP is a generic software engineering process – must be customised (instantiated) for your project • in-house standards, document templates, tools, databases, lifecycle modifications, …• Rational Unified Process (RUP) is the commercial instantiation of UP • marketed and owned by Rational Corporation • also has to be instantiated for your project SOE: Unified Process 3
  110. 110. Unified Process at a glance Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations within phasesSOE: Unified Process
  111. 111. iterations, phases, workflows, milestones initialmilestone life-cycle life-cycle product operational objectives architecture release capabilityphase inception elaboration construction transitioniterations iter 1 iter 2 iter 3 iter 4 iter 5 iter 6 5 core workflows r a d i t … … … … … SOE: Unified Process 5
  112. 112. artefacts (work products), activities, workers (roles) some prominent work products: • vision: summary of objectives, features, business case • software architecture document: short learning aid to understand the system • test plan: summary of goals and methods of testing • iteration plan: detailed plan for the next iteration • change request: uniform way to track all requests for work, e.g. defects SOE: Unified Process 6
  113. 113. instantiation agile green-field maintenance hot fixbusiness modellingrequirementsanalysis and designimplementationtestdeploymentconfigurationmanagementmanagementenvironment SOE: Unified Process 7
  114. 114. development................ problems  causes  UP practice inaccurate understanding  insufficient requirements  develop software of end-user needs specification and their ad hoc iteratively inability to deal with management  manage changing requirements  ambiguous and imprecise requirements modules don’t integrate communication  use component- it is difficult to maintain or  brittle architecture based extend the software  overwhelming complexity architectures late discovery of flaws  undetected inconsistencies in  visually model poor quality and requirements, design, and software performance of the implementation  continuously verify software  poor and insufficient testing software quality no coordinated team effort  subjective assessment of project  control changes to build-and-release issues status software  failure to attack risk  uncontrolled change propagation  insufficient automation SOE: Unified Process
  115. 115. develop iteratively, manage requirements:case-driven developmentin inception in elaboration • use case model outlined • use cases are iteratively specified • use cases briefly and realized described • use cases ranked • elaboration iterations are elaboration elaboration elaboration iteration 1 iteration 2 iteration 3 planned and organized on the basis of the ranked use cases use case a use case a use case f ......... sketch full version ......... use case b use case g ......... ......... ......... ......... ......... .........SOE: Unified Process
  116. 116. develop iteratively:architecture-centric developmentin inception • in elaboration • software architecture gradually • initial candidate architecture defined based on requirements • software architecture finally baselined elabo- elabo- elabo- ration ration ration iteration 1 iteration 2 iteration 3 analysis of storing persistent access control and architectural data security factors architectural control flow distribution viewsSOE: Unified Process
  117. 117. 4+1 view model of architecture implementation logical view view an abstraction of the an organization of static design model that identifies software modules (source major design packages, code, data files, components, subsystems and classes executables, and others …) use-case view key use-case and scenarios process view deployment view a description of the concurrent various executables and aspects of the system at other runtime components runtime - tasks, threads, or are mapped to the underlying processes as well as platforms or computing their interactions nodes 11soe: unified process
  118. 118. use component-based architectures• component-based development• resilient software architecture• enables reuse of components from many available sources• systems composed from existing parts, off-the-shelf third-party parts, (few) new parts that address the specific domain and integrate the other parts together.• iterative approach involves the evolution of the system architecture.• each iteration produces an executable architecture that can be measured, tested, and evaluated against the system requirements.SOE: Unified Process
  119. 119. visually model software (uml standard) class use-case diagrams diagrams object sequence diagrams diagrams collaboration models component diagrams diagrams deployment statechart diagrams diagrams activity diagramsSOE: Unified Process
  120. 120. continuously verify software quality• software problems are exponentially more expensive to find and repair after deployment than beforehand.• verifying system functionality involves creating test for each key scenario that represents some aspect of required behavior.• since the system is developed iteratively every iteration includes testing = continuous assessment of product quality. cost SOE: Unified Process time
  121. 121. control changes to software• the ability to manage change - making certain that each change is acceptable, and being able to track changes - is essential in an environment in which change is inevitable.• maintaining traceability among elements of each release is essential for assessing and actively managing the impact of change.• in the absence of disciplined control of changes, the development process degenerates rapidly into chaos.SOE: Unified Process
  122. 122. best practices summarized visual modeling time-boxed iterations • prior to programming, do • avoid attempting large, up- at least some visual front requirements modeling to explore strive for cohesive architecture creative design ideas and reuse existing manage requirements components • find, organize, and track on large projects: requirements & requirements iteratively core architecture developed through skillful means with by small co-located team; use tool support. then early team members manage change divide into sub-project • disciplined configuration leaders management and version continuously verify quality control, change request • test early, often, and protocol, base-lined realistically by integrating all releases at the end of each software each iteration iteration SOE: Unified Process 16
  123. 123. RUP - overview Faser Artifacts Process Workflows Inception Elaboration Construction Transition Business Modelling Analysis model Requirements Analysis & Design Implementation Design model Use case model Test User Deployment Software Supporting Workflows Architecture Implementation Configuration Mgmt. Document model Project Management Environment  Architect Test  Prelimenary I-1 I-2 I-3 I-4 I-5 I-6 I-7 I-8 I-9  iterations  Test model Iterations Deployment Risk list model 1. Xxx xxx 2. Xx xx xxx 3. Xx xxxxxxx Risk & iterations Iteration plan $ Project Manager  RUP - philisophy RUP - key elements Contents of a workflow - Iterations / Increments - Phases Architecture & system - Use case driven - Iterations Artifact - Architecture centered - Workflows - Visual (UML) - Activities Artifact Artifact I1 I2 ... - Configurable process - Roles - Risk driven - Artifacts Role Activity Domain knowledgeSOE: Unified Process 17
  124. 124. SOE: Unified Process 18
  125. 125. bottom-up design: patternsthe pattern movement
  126. 126. pattern• a pattern addresses a recurring problem that arises in specific situations• patterns document existing, well-proven design experience• patterns identify and specify abstractions that are above the level of single classes and instances• patterns provide a common vocabulary and understanding for design principles• patterns are a means of documenting software architectures• patterns support the construction of software with defined properties• patterns help you build complex and heterogeneous software architectures• patterns help you manage software complexitySOE: refactoring and patterns 2
  127. 127. standard documentation formpattern name and classification: a descriptive and unique name that helps in identifying and referring to the patternintent: a description of the goal behind the pattern and the reason for using italso known as: other names for the patternmotivation (forces): a scenario consisting of a problem and a context in which this pattern can be usedapplicability: situations in which this pattern is usable; the context for the patternstructure: a graphical representation of the pattern – class diagrams and interaction diagrams may be used for this purposeparticipants: a listing of the classes and objects used in the pattern and their roles in the designcollaboration: a description of how classes and objects used in the pattern interact with each otherconsequences: a description of the results, side effects, and trade offs caused by using the patternimplementation: a description of an implementation of the pattern; the solution part of the patternsample code: an illustration of how the pattern can be used in a programming languageknown uses: examples of real usages of the patternrelated patterns: other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patternsSOE: refactoring and patterns 3
  128. 128. types of patterns • analysis patterns • design patterns/GRASP • software architecture patterns • organizational and process patterns SOE: refactoring and patterns 4
  129. 129. analysis patterns • patterns that reflect the generic conceptual structure of business processes rather than analysis problem actual software implementations • simple, specialized notation (very similar to entity-relationship diagram notation) analysis pattern‘Analysis Patterns: ReusableObject Models’, Martin Fowler SOE: refactoring and patterns 5
  130. 130. organisational and process patterns• research into social and Coplien’s top ten patterns behavioural patterns in • unity of purpose software firms which lead to • engage customers successful outcomes • domain expertise in roles  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.