Your SlideShare is downloading. ×
0
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Software Engineering course
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software Engineering course

1,141

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,141
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
279
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software EngineeringIntroduction
  • 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. course design traditional development tools, approaches techniques, SPI practices agile (Ivan Aaen) miniproject 1: miniproject 2: miniproject 3: DA TTP evaluationSOE: Introduction 3
  • 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. 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. 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. 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. SE - related disciplines SWEBOK (2004):SOE: introduction 8
  • 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. 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. 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. NATO-seminar in Garmisch 1968SOE: introduction 12
  • 13. waterfall modelSOE: introduction 13
  • 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. SWEBOK = traditional development approachSOE: introduction 15
  • 16. SWEBOK + associated tools and techniquesSOE: introduction 16
  • 17. early waterfallproblems NATO-seminar in Garmisch 1968 Rayleigh Curve SOE: introduction 17
  • 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. 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. 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. 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. SOE: introduction 22
  • 23. Software Engineeringdevelopment approaches: process models
  • 24. waterfall model• linear sequentialSOE: process models 2
  • 25. V-modelSOE: process models 3
  • 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. iterativeSOE: process models 5
  • 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. SOE: process models 7
  • 30. spiral model(Boehm,1988)SOE: process models 8
  • 31. unified processSOE: process models 9
  • 32. SCRUMSOE: process models 10
  • 33. XPSOE: process models 11
  • 34. linear v. iterativeSOE: process models 12
  • 35. Usage Functions Interfaces Class Structure Behavior Model Component Function Component Connecting componentsOOAD – Criteria ComponentsMathiassen Processeset al 13
  • 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. Software Engineeringtraditional: requirements requirements analysis design ( programming ) test
  • 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. 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. 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. 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. 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. 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. 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. requirements: managing for changeSOE: requirements 9
  • 46. requirements: iterative ‘good enough’ strategySOE: requirements 10
  • 47. Requirements management toolsSOE: requirements 11
  • 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. 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. 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. 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. 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. 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. Software Engineeringtraditional: analysis requirements analysis design ( programming ) test
  • 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. 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. 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. 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. an interpretation problem users developers formalised user-near program- near use domain informal analysis modelsSOE: analysis 6
  • 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. 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. 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. SOE: analysis 10
  • 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. 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. 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. 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. 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. 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. SOE: analysis 17
  • 71. SOE requirementstraditional: test analysis design ( programming ) test
  • 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. generates 28 test cases (= paths through the code)SOE: test 3
  • 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. a testing-oriented development process:v model + effective project managementSOE: test 5
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. SOE: test 18
  • 89. Software Engineering requirementstraditional:design analysis design ( programming ) test
  • 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. 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. traditional software design design principals, patterns architectural modelsrequirements design process analysis design specificationSOE: design 4
  • 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. 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. 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. 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. 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. system architectureSOE: design 10
  • 99. traditional ideal - deriving architectures from analysis models control hierarchy example transform mapping transaction mappingSOE: design 11
  • 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 layers.safety •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. 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. architectural styles client serverrepository function oriented pipelining (pipes and filters) layered SOE: design 14
  • 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. the design documentSOE: design 16
  • 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. 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. SOEUnified ProcessRational Unified Process
  • 108. UP: iterative not (necessarily) agileSOE: Unified Process 2
  • 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. 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. 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. 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. instantiation agile green-field maintenance hot fixbusiness modellingrequirementsanalysis and designimplementationtestdeploymentconfigurationmanagementmanagementenvironment SOE: Unified Process 7
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. SOE: Unified Process 18
  • 125. bottom-up design: patternsthe pattern movement
  • 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. 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. types of patterns • analysis patterns • design patterns/GRASP • software architecture patterns • organizational and process patterns SOE: refactoring and patterns 4
  • 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. 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 • architect controls product • distribute work evenly • function owner and component owner • mercenary analyst • architect also implements • firewalls • developer controls processSOE: refactoring and patterns 6
  • 131. design anti-patterns• big ball of mud: a system with no recognizable structure• database-as-ipc: using a database as the message queue for routine inter-process communication where a much more lightweight mechanism would be suitable• gas factory: an unnecessarily complex design• gold plating: continuing to work on a task or project well past the point at which extra effort is adding value• inner-platform effect: a system so customizable as to become a poor replica of the software development platform• input kludge: failing to specify and implement handling of possibly invalid input• interface bloat: making an interface so powerful that it is extremely difficult to implement• magic pushbutton: coding implementation logic directly within interface code, without using abstraction• race hazard: failing to see the consequence of different orders of events• stovepipe system: a barely maintainable assemblage of ill-related components SOE: refactoring and patterns 7
  • 132. design patterns • design patterns provide abstract, reusable “micro-architectures” that can be applied (“instantiated”) to resolve specific design issues (forces) in previously-used, high-quality ways • GoF (Gang of Four) • creational - manage instantiation - can be further divided into class- creation (use inheritance effectively) patterns and object-creational (use delegation) patterns • structural - concern class and object composition - use inheritance to compose interfaces and define ways to compose objects to obtain new functionality • behavioural - concerned with communication between objects GAMMA, E., HELM, R., JOHNSON, R. & VLISSIDES, J. (1995) Design Patterns, Boston, Addison-Wesley.SOE: refactoring and patterns 8
  • 133. GoF creational patterns:• abstract factory groups object factories that have a common theme• builder constructs complex objects by separating construction and representation• factory method creates objects without specifying the exact class to create• prototype creates objects by cloning an existing object• singleton restricts object creation for a class to only one instanceSOE: refactoring and patterns 9
  • 134. GoF structural patterns:• adapter allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class• bridge decouples an abstraction from its implementation so that the two can vary independently• composite composes zero-or-more similar objects so that they can be manipulated as one object• decorator dynamically adds/overrides behaviour in an existing method of an object• façade provides a simplified interface to a large body of code• flyweight reduces the cost of creating and manipulating a large number of similar objects• proxy provides a placeholder for another object to control access, reduce cost, and reduce complexitySOE: refactoring and patterns 10
  • 135. GoF behavioral patterns: concerned with communicationbetween objects• chain of responsibility delegates commands to a chain of processing objects• command creates objects which encapsulate actions and parameters• interpreter implements a specialized language• iterator accesses the elements of an object sequentially without exposing its underlying representation• mediator allows loose coupling between classes by being the only class that has detailed knowledge of their methods• memento provides the ability to restore an object to its previous state (undo)• observer is a publish/subscribe pattern which allows a number of observer objects to see an event• state allows an object to alter its behavior when its internal state changes• strategy allows one of a family of algorithms to be selected on-the-fly at runtime• template method defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior• visitor separates an algorithm from an object structure by moving the hierarchy of methods into one objectSOE: refactoring and patterns 11
  • 136. pattern use example Movie Price 1 charge() charge()<<code>> ChildrensPrice 1 RegularPrice 1 NewRelease 1return priceCode.charge() Price charge() charge() charge() state pattern singleton pattern SOE: refactoring and patterns 12
  • 137. GRASP (General Responsibility Assignment Software Patterns)• information expert: allocating responsibilities (methods, computed fields etc.) by determining which class has the most relevant data variables• creator: determines which class should govern creation of new instances of classes in non-trivial situations. Given two classes (A,B), class B should be responsible for the creation of A if class B contains or compositely aggregates, records, closely uses or contains the initializing information for class A (see also factory)• controller: assigns the responsibility of dealing with system events to a non-UI class that represents a use case scenario(s) - the first object beyond the UI layer that receives and coordinates a system operation. The controller should delegate to other objects the work that needs to be done• low coupling: determines low dependency between classes, low impact in a class of changes in other classes and high reuse potentialSOE: refactoring and patterns 13
  • 138. GRASP 2• high cohesion: the responsibilities of a given element are strongly related and highly focused• polymorphism: responsibility for defining the variation of behaviors based on type is assigned to the types for which this variation happens• pure fabrication: a class that does not represent a concept in the problem domain but is added to achieve low coupling, high cohesion, and the reuse potential thereof• indirection: supports low coupling between two elements by assigning the responsibility of mediation between them to an intermediate object e.g. controller in MVC.• protected variations: protects elements from variations on other elements by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.SOE: refactoring and patterns 14
  • 139. architectural patterns “.....an architectural pattern expresses a fundamental structural organisation schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them” • from mud to structure • interactive systems • layers • model-view-controller • pipes and filters • presentation-abstraction- • blackboard control • distributed systems • adaptable systems • broker • microkernel • reflectionBUSCHMAN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P. & STAL, M. (1996) Pattern-oriented Software Architecture, Chichester, Wiley. SOE: refactoring and patterns 15
  • 140. architectural patterns: from mud to structure layersexample OSI model pipes and filtersproblem large system with high and low example level functions requiring problem process or transform a data decomposition streamstructure layer j provides services used by structure •filter: collects, transforms and j+1, delegates subtasks to j-1 outputs data supplied by pipeknown use TCP protocol, IS •pipe: transfers, buffers data and synchronizes with neighbours presentation •data source: delivers data to application logic pipe •data sink: consumes output domain layer known use UNIX program compilation and documentation creation databaseSOE: refactoring and patterns 16
  • 141. architectural patterns: from mud to structure blackboardproblem no feasible deterministic solution for transforming data into high level structures (diagrams, tables, language phrases)structure a collection of independent programs that work co- operatively on common data •blackboard: central data store •knowledge source: evaluates its own applicability, computes a result, updates blackboardknown use speech and image recognition, vision, surveillanceSOE: refactoring and patterns 17
  • 142. architectural patterns: distributed systems brokerproblem manage distributed and possibly heterogeneous systems with independent operating componentsstructure •client: implements user functionality •server: implements services •broker: locates, registers and communicates with servers, interoperates with other brokers through bridges •client side proxy: mediates between client and broker •server side proxy: mediates between server and broker •bridge: mediates between local broker and bridge of a remote brokerknown CORBA, WWWuse SOE: refactoring and patterns 18
  • 143. architectural patterns: interactive systems model-view-controllerproblem interactive systems with flexible and change prone user interfacestructure •model: provides central data and function logic •view: displays information to the user •controller: accepts inputs and makes service requests for the model, display requests for viewknown Smalltalk systemsuse SOE: refactoring and patterns 19
  • 144. architectural patterns: interactive systems presentation-abstraction- controlproblem interactive systems as a set of cooperating agentsstructure tree hierarchy of PAC agents, with one top level agent – each agent has: •presentation: visible behaviour of the agent •abstraction: maintains data and provides core functionality •control: connect presentation and abstraction and communicate with other agentsknown use network traffic control SOE: refactoring and patterns 20
  • 145. architectural patterns: adaptable systems microkernalproblem application domains with broad spectrums of standards and programming technologies, continuous hardware and software evolution. Software should be portable, extensible, adaptablestructure •microkernal: provides core services, manages resources and communication •internal server: implements additional services •external server: provides programming interfaces for clients •client: represents an application •adapter: hides system dependencies, invokes methods of external servers on behalf of clientsknown use Windows NT SOE: refactoring and patterns 21
  • 146. architectural patterns: adaptable systems reflectionproblem systems exposed to changing technology and requirements, and support their own modificationstructure •base level: implements the application logic using information from meta level •meta level: encapsulates system internals that may change and provides interface to facilitate modifications to meta-level •metaobject protocol: interface for specifying and performing changes to meta levelknown OLE 2.0use SOE: refactoring and patterns 22
  • 147. potential benefits of patterns • provides a common vocabulary and understanding of design elements for software designers • increases productivity in design process due to design reuse • promotes consistency and high quality of system designs and architectures due to application of tested design expertise and solutions embodied by patterns • allows all levels of designers, from novice to expert, to gain these productivity, quality and consistency benefitsSOE: refactoring and patterns 23
  • 148. concerns • benefits are dependent upon architects, analysts and designers understanding the patterns to be used – the common “design vocabulary” • such training can be costly, and in many cases is proprietary and cannot be obtained externally • specific funding and effort must be directed toward maintenance and evolution of patterns as reusable assets or they tend to devolve into project/application-specific artifacts with dramatically reduced reusability characteristics • promotes design culture at the expense of analysis culture – less focus on responding adequately and accurately to specific user domainsSOE: refactoring and patterns 24
  • 149. patterns and refactoring work together:bottom up design refactoring to patterns pattern through refactoring developmentSOE: refactoring and patterns 25
  • 150. design style,abstraction level architecture architectural patterns agile design as model design as code GRASP design refactoring patterns detailed design SOE: refactoring and patterns 26
  • 151. traditional and agile design styles compareddesign assumptions traditional agilestyle top down bottom upstarts with modelling programmingprocess grand design up front evolutionary designresponsible architect, designers programmersbased upon user domain analysis generic design patterns modelsoutcome design document programweakness separation of design and absence of early programming overview, unspecific user domain understandingsSOE: refactoring and patterns 27
  • 152. SOEbottom-up design - refactoring and patterns
  • 153. architecture components modules architecture screen sketch object model ERM design as model design as code screen code object codedesign style database tables algorithm design data validation exception handling detailed design abstraction level SOE: refactoring and patterns 2
  • 154. design style,abstraction level architecture traditional agile design as model design as code detailed design SOE: refactoring and patterns 3
  • 155. top down design - MDA executable UML(Model Driven Architecture) compiler J2EE .NET archetypeSOE: refactoring and patterns 4
  • 156. bottom-up design – refactoring’Refactoring: improving the design of existing code’Marting Fowler, Addison Wesley
  • 157. bottom up design: refactoring • refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior • refactor (verb): to restructure software by applying a series of refactorings • refactoring is not: • debugging • mending business logic • adding new functionalityMartin Fowler (and Kent Beck, John Brant, William Opdyke, Don Roberts), Refactoring - Improving theDesign of Existing Code, Addison Wesley, 1999 SOE: refactoring and patterns 6
  • 158. refactoring example: duplicated codecase 0: activePiece = RightHookgetRightHook(); case 0: ml = new MoveListener(activePiece); activePiece = RightHookgetRightHook(); break; gameBoardaddKeyListener(ml); case 1: break; activePiece = LeftHookgetLeftHook(); break;case 1: case 2: activePiece = LeftHookgetLeftHook(); activePiece = RightRisegetRightRise(); break; ml = new MoveListener(activePiece); case 3: gameBoardaddKeyListener(ml); activePiece = LeftRisegetLeftRise(); break; break; case 4:case 2: activePiece = HillgetHill(); break; activePiece = RightRisegetRightRise(); case 5: ml = new MoveListener(activePiece); activePiece = StraightPiecegetStraightPiece(); break; gameBoardaddKeyListener(ml); case 6: break; activePiece = SquaregetSquare(); break;case 3: } activePiece = LeftRisegetLeftRise(); ml = new MoveListener(activePiece); ml = new MoveListener(activePiece); gameBoardaddKeyListener(ml); gameBoardaddKeyListener(ml); break; //moreSOE: refactoring and patterns 7
  • 159. why refactor? refactoring improves design without refactoring, even a well designed program will decay (‘go sour’) as programmers make changes refactoring makes software easier to understand understandable code is easier to update and maintain refactoring helps find bugs refactoring involves clarification and re-shaping through better understanding refactoring speeds up programming good design ensures comprehensibility and fewer changes as new functionality is addedSOE: refactoring and patterns 8
  • 160. bad smells• duplicate code: identical or very similar code exists in more than one location• large method: a method, function, or procedure that has grown too large• large class: a class that has grown too large (god object)• feature envy: a class that uses methods of another class excessively• inappropriate intimacy: a class that has dependencies on implementation details of another class• data clumps: a set of variables that seem to “hang out” together – e.g. often passed as parameters, changed/accessed at the same time• primitive obsession: all subparts of an object are instances of primitive types (int, string, bool, double, etc)• refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class• lazy class: a class that does too little• duplicated method: a method, function, or procedure that is very similar to another• contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice• ………… SOE: refactoring and patterns 9
  • 161. refactoring (n): a standard way of improving poor code Preserve Whole Object Add Parameter Pull Up Constructor Body Change Bidirectional Association to Unidirectional Pull Up Field Change Reference to Value Pull Up Method Change Unidirectional Association to Bidirectional Push Down Field Change Value to Reference Push Down Method Collapse Hierarchy Reduce Scope of Variable by Mats Henricson Consolidate Conditional Expression Refactor Architecture by Tiers (Link Only) Consolidate Duplicate Conditional Fragments Remove Assignments to Parameters Convert Dynamic to Static Construction by Gerard M. Davison Remove Control Flag Convert Static to Dynamic Construction by Gerard M. Davison Remove Double Negative by Ashley Frieze and Martin Fowler Decompose Conditional Remove Middle Man Duplicate Observed Data Remove Parameter Eliminate Inter-Entity Bean Communication (Link Only) Remove Setting Method Encapsulate Collection Rename Method Encapsulate Downcast Replace Array with Object Encapsulate Field Replace Assignment with Initialization by Mats Henricson Extract Class Replace Conditional with Polymorphism Extract Interface Replace Conditional with Visitor by Ivan Mitrovic Extract Method Replace Constructor with Factory Methodbad smell Extract Package by Gerard M. Davison Extract Subclass Extract Superclass Replace Data Value with Object Replace Delegation with Inheritance Replace Error Code with Exception Form Template Method Replace Exception with Test Hide Delegate Replace Inheritance with Delegation Hide Method Replace Iteration with Recursion by Dave Whipp Hide presentation tier-specific details from the business tier (Link Replace Magic Number with Symbolic Constant Only) Replace Method with Method Object Inline Class Replace Nested Conditional with Guard Clauses Inline Method Replace Parameter with Explicit Methods Inline Temp Replace Parameter with Method Introduce A Controller (Link Only) Replace Record with Data Class Introduce Assertion Replace Recursion with Iteration by Ivan Mitrovic Introduce Business Delegate (Link Only) Replace Static Variable with Parameter by Marian Vittek Introduce Explaining Variable Replace Subclass with Fields Introduce Foreign Method Replace Temp with Query Introduce Local Extension Replace Type Code with Class Introduce Null Object Replace Type Code with State/Strategy Introduce Parameter Object Replace Type Code with Subclasses Introduce Synchronizer Token (Link Only) Reverse Conditional by Bill Murphy and Martin Fowler Localize Disparate Logic (Link Only) Self Encapsulate Field Merge Session Beans (Link Only) Separate Data Access Code (Link Only) Move Business Logic to Session (Link Only) Separate Query from Modifier Move Class by Gerard M. Davison Split Loop by Martin Fowler Move Field Split Temporary Variable Move Method Substitute Algorithm Parameterize Method Use a Connection Pool (Link Only) Wrap entities with session (Link Only)SOE: refactoring and patterns 10
  • 162. very simple example title titleText titleX titleY titleColour bad smell: data clump refactoring: extract classSOE: refactoring and patterns 11
  • 163. class Customer extends DomainObject { public Customer(String name) { _name = name; } public String statement() { double totalAmount = 0; int frequentRenterPoints = 0; Enumeration rentals = _rentals.element s(); String result = "Rental Record for " + name() + "n" ; while (rentals.hasMoreElements()) { double thisAmount = 0; Rental each = (Rental) rentals.nex tElement(); //determine amounts for each line switch (each.tape().movie().priceC ode()) { case Movie.REGULA R: thisAmount += 2; if (each.daysRented() > 2) thisAmoun t += (each.da ysRented() - 2 ) * 1.5; break; case Movie.NEW_RE LEASE: thisAmount += each.daysRen ted() * 3; break; case Movie.CHILDR ENS: Fowler’s video shop thisAmount += 1.5; if (each.daysRented() > 3) thisAmoun t += (each.da ysRented() - 3 ) * 1.5; break; } totalAmount += thisAmount; example // add frequent renter points frequentRenterPoints ++; // add bonus for a two day new rel ease rental if ((each.tape().movie().priceCode() == Movie.NEW_RELEASE) && each.daysRented()> 1) frequentRenterPoints ++; //show figures for this rental result += "t" + each.ta pe().movie() .name()+ "t" + String .valueOf(thisA mount) +"n"; refactor: replace condition with polymorphism } //add footer lines Movie Price result += "Amount owed is " + String. valueOf(totalA mount) + "n "; 1 result += "You earned " + String.valueOf(fre quentRenterPo ints) + " frequent renterpoints"; return result; charge() charge() } public void addRental(Rental arg) { _ren tals.addEleme nt(arg); } public static Customer get(St ring name) {<<code>> rn (Customer) Registrar.ge t("Customers" , name); retu ChildrensPrice 1 RegularPrice 1 NewRelease 1return priceCode.charge() } Price public void persist() { Regi strar.add("Cu stomers", thi s); charge() charge() } charge() private Vector _rentals = new Vector(); SOE: refactoring and patterns 12
  • 164. common refactorings• push down method - behaviour on a super class is relevant only for some of its subclasses’ - the method is moved to those subclasses• extract subclass - ‘a class has features that are used only in some instances’ - a subclass is created for that subset of features• encapsulate field - the declaration of a field is changed from public to private• hide method - ‘a method is not used by any other class’ (the method should be made private)• pull up field - ‘two subclasses have the same field’ - the field in question should be moved to the super class• extract super class – ‘two classes with similar features’ - in this case, create a super class and move the common features to the super classSOE: refactoring and patterns 13
  • 165. common refactorings• push down field - a field is used only by some subclasses’ - the field is moved to those subclasses• pull up method - methods with identical results in subclasses’ - methods should be moved to the super class• move method - a method is, or will be, using or used by more features of another class than the class on which it is defined’• move field - a field is, or will be, used by another class more than the class on which it is defined’• rename method - a method is renamed to make its purpose more obvious.• rename field - field is renamed to make its purpose more obviousSOE: refactoring and patterns 14
  • 166. refactoring principles• make changes small and methodical• follow design patterns• have your test suites ready • refactoring introduces new bugs • sometimes in unrelated parts of the programme• run test suites each time you refactor• clean before you add new functionalitySOE: refactoring and patterns 15
  • 167. two dubious refactoring practicesrefactoring the architecturerefactoring: ‘extract package’, ‘refactor architecture by tiers’• large scale decisions about the organisation of the program taken too late in the construction because of insufficient overview• liable to cause chaos unless extremely well thought outthe refactoring sprint(s)• some weeks in the life of the project, paid for by the customer, where the only purpose is to rectify relatively serious design problems caused by lack of real understanding of the user domain and too early commitment to programming SOE: refactoring and patterns 16
  • 168. traditional view of refactoring• refactoring reflects poor analysis and design work – do it right first time• refactoring is expensive – all prior documentation must be altered• refactoring introduces new errors in unpredictable places• refactoring threatens architectural integrity• customers expect new functionality and will not pay for rework• refactoring does not extend value – if it ain’t broke don’t fix it SOE: refactoring and patterns 17
  • 169. Software Engineeringparticipative design:contextual design – Beyer + Holtzblatt
  • 170. overview• a system design method designed • problem analysis tools and used by software consultants • solution design strategies• focused on users’ work • small learning curve• empirically-based analysis tools• participative (Scandinavian tradition) • design/re-design of• simple analysis and design systems: work, techniques information,• designing user environments communication, computer• simple prototyping strategy
  • 171. problem analysis: work oriented five analysis models: • (information) flow • sequence • (information) artifacts • culture • physical workspace
  • 172. flow model actors- task, responsibility artifact information flow
  • 173. sequenceintent:trigger: task, step sequence, order breakdown
  • 174. information artifact model•information, data•distinct parts•structure•annotations, informaluse•presentation•usage•breakdown
  • 175. culture influencer influence directionextent and nature ofinfluenceroles, norms, values
  • 176. physical surroundings
  • 177. contextual design• vision• storyboard• work redesign• user environment design• paper prototype
  • 178. vision • a diagrammatic representation of the new way of working and communicating when the new systems and services are implemented • can include; users, other actors, information flows, screens, databases and other things as required
  • 179. storyboard • a sequential depiction of the use of the new system and services, divided into its principle stages • can include; users, other actors, information flows, screens, databases and other things as required
  • 180. work design (modified use case) the major actors (user, citizen, role) workprocess their interaction with role system function the major functions workprocess system role in the system function the work process behind the workprocess role system function interactions workprocess system function workprocess
  • 181. user environmentdesign• a graphical representation of the major focus areas of the system, usually divided by function• functions: what the user can do in the system• overview: information displayed on screen• links: connections to other places in the system• objects: principle work ”objects” which may later be coded
  • 182. paperprototype • drawing of a screen • shows divisions of screen, menu items, data entry possibilities, buttons, scroll bars, links, pictures, graphics, computer visualizations (or any thing else that a user can see in a system)
  • 183. Software Engineeringagile or traditional?
  • 184. a development approach traditional agile• process model linear, iterative iterative• associated tools, analysis and design stand-up meeting, pair techniques, practices techniques, case tool, programming, time-• characteristics etc boxing, etc• a set of (unspoken) assumptions about the nature of software development and its contexts SOE: traditional v. agile 2
  • 185. a project situation• development project circumstances, factors, conditions • size (FP, LOC, developers, project length, no. of developers) • complexity • environmental dynamism • technology platform • software type • developer organization history • team members’ work style • customer organization history traditional • user domain complexity agile • user profile and accessibility • contracting and delivery needs • maintenance expectations development • .......... approach SOE: traditional v. agile 3
  • 186. development approach characteristics:ceremony and cycles (Larman) waterfall strict (no iteration)few steps, few formal steps,documents many documents SCRUM ceremony XP UP many short iterations cyclessoe: agile or traditional 4
  • 187. project characteristics: uncertaintySOE: traditional v. agile 5
  • 188. project characteristics: complexitySOE: traditional v. agile 6
  • 189. project situation: complexity, uncertainty highuncertainty low low high complexitySOE: traditional v. agile 7
  • 190. project situations: complexity and uncertainty 8 From: LittleSOE: traditional v. agile
  • 191. commonly used development approachestraditional development evolutionary development prototyping (waterfall) • iteratively • quick initial working model • single pass, sequential • expanding increments • cycle: partial requirements Analysis Design of operational product gathering with (some) • progresses through stakeholders - quick design – requirements analysis, • evolution determined prototyping – evaluation design, coding, testing, by operational Implemen- integration experience • full-scale model and Evaluation tation functional form – but only on • document-based • development begun on part of the system criteria between stages the most visible aspect • I’ll Know It When I See It (IKIWISI)incremental development spiral model agile development • all requirements and • risk-driven variation of • iterative preliminary evolutionary architectural design development • adaptive process determined up front • can function as a • light-weight • separate increments superset process • intensive communication addressing subsets of model between developers and requirements • risk-based transition customer criteria between stages • programming focus • XP, SCRUM …SOE: traditional v. agile 9
  • 192. development approaches in one dimension(Boehm and Turner) agile methods prototyping Unified Process code and fix spiral model waterfall evolutionary adaptive undisciplined predictive linear disciplined (agile) (traditional – plan-driven) 10SOE: traditional v. agile
  • 193. agile v. traditional (plan-driven) differences • application • project goals, size, environment; velocity • management • customer relations, planning and control, communications • technical • how the software is developed • personnel • the type and competency of developers and stakeholders From: Boehm & TurnerSOE: traditional v. agile 11
  • 194. agile vs. traditional characteristicscharacteristics agile traditional (plan-driven)applicationprimary goals rapid value; responding to change predictability, stability, high assurancesize smaller teams and projects larger teams and projectsenvironment turbulent; high change; project-focused stable; low-change; project/organization focusedmanagementcustomer dedicated on-site customers, where as-needed customer interactions; focusedrelations feasible; focused on prioritized on contract provisions; increasingly increments evolutionaryplanning/control internalized plans; qualitative control documented plans, quantitative controlcommunications tacit interpersonal knowledge explicit documented knowledge 12 SOE: traditional v. agile
  • 195. characteristics agile traditional (plan-driven)technicalrequirements prioritized informal stories and test formalized project, capability, interface, cases; undergoing unforeseeable quality, foreseeable evolution requirements changedevelopment simple design; short increments; architect for parallel development; longer refactoring assumed inexpensive increments; refactoring assumed expensivetest executable test cases define documented test plans and procedures requirementspersonnelcustomers dedicated, collocated crack* crack* performers, not always collocated performersdevelopers at least 30% full-time Cockburn level 50% Cockburn level 3s early; 10% 2 and 3 experts; no level 1b or -1 throughout; 30% level 1b’s workable; no personnel** level -1s**culture comfort and empowerment via many comfort and empowerment via framework degrees of freedom (thriving on of policies and procedures (thriving on chaos) order)* collaborative, representative, authorized, committed, knowledgeable** these numbers will particularly vary with the complexity of the application 13 SOE: traditional v. agile
  • 196. sweet spots From: Boehm 14SOE: traditional v. agile
  • 197. Boehm: critical factorsFactor Agility discriminators Plan-driven discriminators Well matched to small products and teams; Methods evolved to handle large products andSize reliance on tacit knowledge limits scalability. teams; hard to tailor down to small projects. Untested on safety-critical products; potential Methods evolved to handle highly critical products;Criticality difficulties with simple design and lack of hard to tailor down efficiently to low-criticality documentation. products. Simple design and continuous refactoring are Detailed plans and “big design up front” excellent excellent for highly dynamic environments, butDynamism for highly stable environment, but a source of present a source of potentially expensive rework expensive rework for highly dynamic environments. for highly stable environments. Need a critical mass of scarce Cockburn Level 2 Require continuous presence of a critical mass of and 3 experts during project definition, but canPersonnel scarce Cockburn Level 2 or 3 experts; risky to work with fewer later in the project—unless the use nonagile Level 1B people. environment is highly dynamic. Can usually accommodate some Level 1B people. Thrive in a culture where people feel comfortable Thrive in a culture where people feel comfortableCulture and empowered by having many degrees of and empowered by having their roles defined by freedom; thrive on chaos. clear policies and procedures; thrive on order. SOE: traditional v. agile 15
  • 198. polar chart of factorsSOE: traditional v. agile 16
  • 199. development approach assumptions assumption make (internal) locus of effort (external) buy linear process model cyclical (iterative) rational analytical approach experimental specification expression form prototype all at once delivery incremental expert-driven user involvement user-driven process developer focus product delivery developer-customer relationship co-operation predictive uncertainty management adaptive all lifecycle phases completeness chosen lifecycle phases experienced developer maturity naiveSOE: traditional v. agile 17
  • 200. NERUR, S., MAHAPATRA, R. K. & MANGALARAJ, G. (2005) Challenges ofmigrating to agile methodologies. Communications of the ACM, 48, 72-78.SOE: traditional v. agile 18
  • 201. broader assumptions traditional agilethe world (user stable and governed by rules changing and governed bydomain) is .......... (natural science) relationships between people (social science)development is application of an externally stepwise refinement of a localthe .............. imposed algorithm (the design design solution method)a complex rational analysis informed trial andproblem is solved error/experimentby ...................knowledge formal and documented informal by directexchange is .......... communication.............................SOE: traditional v. agile 19
  • 202. the normative ideals v. software development inpractice• normative ideal – designers of development approach direct engineers’ actions• in practice – engineers make informed decisions about their practice• in theory - traditional and agile methods incompatible• in practice – much overlap• now its up to you SOE: traditional v. agile 20
  • 203. SOE scopeproject management and planningestimating and scheduling control estimate manage schedule risk
  • 204. the economics of softwarethe prime objective of a software firm = make softwarethe prime objective of a software firm = make moneyproject cost = fixed costs + developer person daysproject income = actual revenue – actual project costexpected revenue = estimated project cost + desired profit marginactual project cost = estimated project cost – all overspendcurrent project value = code value to date – all other costsconclusion: in order to make money the project must be correctlyestimated and scheduled, and managed without significant overspendSOE: project management 2
  • 205. reminder: the project management problem• nearly two thirds of project significantly overrun their cost estimates (Lederer and Prasad 1992)• the average project exceeds its schedule by 100% (Standish 2001)• good project management is a question of business survival• many software firms have as their primary goal: deliver on timeSOE: project management 3
  • 206. the project start • what will we get? scope • what will it cost? (features,customer • when will it be finished? functionality)• the prime PM objectives: schedule resources 1. make money (cost, 2. keep the customer happy (time) budget) 3. deliver on time 4. build good quality software 5. keep the team happy SOE: project management 4
  • 207. the purpose of planning• reduce uncertainty• ensure efficient resource use• monitor progress uncertainty• establish confidence and trust• allocate roles and tasks• support future decision making• ensure the project earns money• improve future planning time• generate and communicate overview of project the planning horizonSOE: project management 5
  • 208. the plan and its execution adaptive planning traditional adaptation agile prediction predictive planningSOE: project management 6
  • 209. the tasks • scope - understand the problem and the work that must be done scope • estimate - how much effort? how much time? • manage risk - what can go wrong? how can we avoid it?control estimate what can we do about it? • schedule - how do we allocate resources along the timeline? what are the milestones? manage • control - how do we control schedule quality? how do we control risk change? how do we manage developments in schedule and estimate and unforeseen risksSOE: project management 7
  • 210. predictive planning scope(traditional) control estimate manage schedule risk SOE: project management 8
  • 211. software scoping scope • functionality decomposition control estimate • data and processing demands • interfaces and reports • performance, security and reliability constraints schedule manage risk • understand the customers’ needs • understand the business context • understand the project boundaries • understand the customer’s motivation • understand the likely paths for change • feasibility report • 2 part contracting • preliminary requirements analysis • the more information, the more accurate the estimation • scoping and contract documentationSOE: project management 9
  • 212. estimation scope control estimate• the intelligent anticipation of the amount of work that needs to be performed and the resources needed to perform it schedule manage risk• software size (LOC, function or object points)• development • effort (person days, hours, months) • cost • time• for example: • how big is the software • how much effort is needed for this much software? • what will that much effort cost and how long will it take?SOE: project management 10
  • 213. software size metrics scope• Lines Of Code control estimate• Function Points n.......user inputs schedule manage risk n.......user outputs n.......user inquiries function point to lines of code: n.......files ada 95 49 n.......external outputs assembly 320 • adjust for weighting and ‘complexity c 128 c++ 55 adjustment values’, empirically derived fortran 95 71 constants java 53• Feature Points (where algorithmic pascal 91 visual basic 5.0 29 complexity is high) ………………• Object Points Jones: ”Applied Software Measurement ..” Mcgraw-Hill 1996SOE: project management 11
  • 214. scopebaseline metrics: control estimate• local historical – collected from a series of projects manage• researcher produced – collected from analysis schedule risk of many projects• constants• adjustment factorsSOE: scheduling and estimating 12
  • 215. estimation strategies scope control estimate• process-based estimation• use case based estimation manage algorithmic (empirical) cost modelling schedule• risk• expert judgement• estimation by analogy• Parkinson’s law• pricing to win• error margins can be large: use two methodsSOE: project management 13
  • 216. scope process-based decomposition and estimation control estimate Risk manage Activity CC Planning Engineering Release Totals schedule analysis riskFunction Anal. Design Code Testa 0.75 2.50 0.40 5.00 8.65b 0.50 4.00 0.60 2.00 7.10c 0.50 4.00 1.00 3.00 8.50d 0.50 3.00 1.00 1.50 6.00e 0.25 2.00 0.75 1.50 4.50f 0.50 2.00 0.50 2.00 5.00Totals .25 .25 .25 3.00 17.50 4.25 15.00 34.80% effort 1% 1% 1% 7% 45% 12% 40% SOE: project management 14
  • 217. use case based estimation scope control estimate• highly structured use cases divided into scenarios manage schedule risk LOC = N × LOCavg + [(Sa/Sh - 1) + (Pa/Ph - 1)] × LOCadjust N = actual number of use-cases LOCavg = historical average LOC per use-case for this type of system Sa = actual scenarios per use-case Sh = average scenarios per use-case for this type of system Pa = actual pages per use-case Ph = average pages per use-case for this type of system LOCadjust = represents an adjustment based on n percent of LOC where n is defined locally and represents the difference between this project and “average” projects SOE: project management 15
  • 218. algorithmic (empirical) modelling scope control estimate• empirically derived constants from research- oriented historical baseline data manage• example structure: E = A + B x (ev) c schedule risk • E = effort • ev = estimation value (e.g. FP) • A,B,C are empirically derived constants• various research-based models in the literature with considerable outcome variationSOE: project management 16
  • 219. COCOMO 2Boehm et al: ”Software Cost Estimation with Cocomo II” Prentice Hall 2000 SOE: scheduling and estimating 17
  • 220. expert estimation scope control estimate• variations of Delphi technique• combine and improve the estimation estimates manage of several experienced estimators schedule riskSOE: project management 18
  • 221. estimation by analogy scope control estimate similar past project schedule manage risk similar past similar past project project • similarities size current • differences project project team • similarities • differences programming • similarities technologies • differences ....................... .........................SOE: project management 19
  • 222. estimation & politics: scope control estimate• competitive bidding produces (unrealistically) low estimates manage• estimation is not an exact science schedule risk• a professional will not conform to wishful thinking• managers are entitled to an early estimate• your challenge is to make them understand uncertaintySOE: scheduling and estimating 20
  • 223. scheduling scope control estimate • decide who does what and when • a good schedule: schedule manage risk describes an effective process - succeed describes an efficient process - fast and cheap describes a realistic process - estimate respects stakeholders’ interests - motivate enables partition of labour - coordinate enables measurement of progress - control can be communicated - simplicitySOE: project management 21
  • 224. top-down + bottom up scope control estimate • situation • resource allocation schedule manage risk • strategy • resources • process model • task • phases & decomposition deliverablesSOE: scheduling and estimating 22
  • 225. phases, deliverables, milestones scope control estimate manage schedule riskSOE: scheduling and estimating 23
  • 226. hierarchical task decomposition scope control estimaterequirements r1 schedule manage risk r2 r3 r3.1 Task definition: Task I.1 Concept Scoping I.1.1 Identify need, benefits and potential customers; r3.2 Begin Task I.1.2 I.1.2 Define desired output/control and input events that drive the application;analysis I.1.2.1 FTR: Review written description of need9 I.1.2.2 Derive a list of customer visible outputs/inputs a1 case of: mechanics mechanics = quality function deployment a2 meet with customer to isolate major concept requirements; interview end-users;design observe current approach to problem, current process; review past requests and complaints; d1SOE: project management 24
  • 227. dependencies scope control estimateidentify tasks and dependencies, estimatee.g. from a design (work breakdown structure) schedule manage risk• design a• code & test a S• design b• code & test b• integrate & test s A B it S dA ct A dB ct BSOE: scheduling and estimating 25
  • 228. tasks, durations, dependencies scope control estimate activity duration (days) dependencies T1 8 T2 15 schedule manage risk T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)SOE: project management 26
  • 229. task network with milestones, durations scope control estimate manage schedule riskSOE: project management 27
  • 230. gant chart scope control estimate manage schedule riskSOE: project management 28
  • 231. task assignment scope control estimate manage schedule riskSOE: project management 29
  • 232. program evaluation and review technique scope(PERT) control estimate manage schedule risk tasks, calendar days, dependencies, milestonesSOE: scheduling and estimating 30
  • 233. critical path method (CPM) • the critical path is the longest path through a network (defines the minimum project completion time) • slack is the amount of time an activity can be delayed without delaying the projectSOE: scheduling and estimating 31
  • 234. controlling projects scope control estimate manage schedule risk • check (monitor): • resource use (developer hours) • schedule (overrun) • progress (deliverables) • act • enforce or modify planSOE: project management 32
  • 235. the project manager’s dilemma scope control estimate scope manage schedule risk (features, functionality) • decrease scope (risk contract breech) • alter schedule (risk late delivery schedule resources and contract breech) (cost, (time) budget) • increase resources (risk making a loss or having to go to the customer for more money)SOE: project management 33
  • 236. project management tool supportSOE: scheduling and estimating 34
  • 237. adaptive planning scope(agile) control estimate manage schedule riskSOE: project management 35
  • 238. an adaptive plan (Larman) scopecontrol estimate manage schedule risk scope control estimate manage schedule riskSOE: project management 36
  • 239. two contract phase plan scope SOE: project management 37
  • 240. estimate• planning poker (a simplified version of Delphi techniques• story points (a simplified application of the FP idea)• velocity: story points per iteration• estimation improves as velocity becomes known• ideal days• shared estimation generates commitmentSOE: project management 38
  • 241. schedule • prioritize user stories for: • customer functionality • business value • risk • must-haves, exciter-delighters user • feature benefit v. cost of absence • story decomposition story • release planning (stories, points velocity) • iteration planning (iteration length, activities) • bufferingSOE: project management 39
  • 242. control• story self-selection generates commitment• burndown chart• velocity monitoring• time-boxingSOE: project management 40
  • 243. primary control locus scope requirements specification scope (features, schedule resources functionality) scope schedule resources time-boxed (cost, (time) budget) schedule resourcesSOE: project management 41
  • 244. comparisonplanning assumptions traditional agilestyle predictive adaptiveteam managed self-organizingteam manager leader facilitatorexpression detailed plans instrumental sketchesdriving force professional responsibility commitmentmanagement focus complexity uncertaintyfixed point scope scheduletechniques analytical, quantitative simple, pragmatic SOE: project management 42
  • 245. “Prediction is very difficult –especially about the future” “To be uncertain is to be uncomfortable, but to beNiels Bohr certain is ridiculous”“Planning is everything. Plans Chinese proverbare nothing”“No plan survives contactwith the enemy” “You improvise, you adapt, you overcome”Field Marshal Helmuth Grafvon Moltke Clint EastwoodSOE: project management 43
  • 246. project managers’ competence priorities at WM Data Take tough decisions with little information and without being sure of the consequences Work to reduce uncertainty, for example through risk management Focus on the uncertainties and act as the leader in these areas Build a relationship Develop understanding and trust uncertainty management Handle differences professionally Educate the customer customer management Compensate for contracting Record agreements Understand strategic goals business management Estimate realisticallyQuickly build a functioning teamCompensate for poor communication team managementManage team stressHandle crises and rebellion process management core competences technical competences SOE: project management 44
  • 247. SOEmanaging change in system development projects:configuration management
  • 248. 2
  • 249. understanding the problem of change• change is one of the most fundamental characteristics in any software development process (Leon 2000) – it is intrinsic and must be accepted as a fact of life (Lehman 1980)• changing software is very easy, but if it is done at will, results in chaos (Leon 2000)• effective projects control changes, whereas ineffective projects allow changes to control them (McConnell 1998)• the level and formality of control should vary according to project conditions (Whitgift 1991)SOE: configuration management 3
  • 250. sources of change• requirements change through misunderstanding, better customer understanding or situational change (= requirements churn)• analysis clarification with improving developer understanding• design improvements, evolutionary design changes, code improvement, refactoring• bug fixes during test• improvements and new functionality after release• version, variant and implementation change• component and code reuseSOE: configuration management 4
  • 251. change sources: system evolution system variants mobile server Windows XP initial PC desktop system Linux SUN ... alpha beta bug + issue fixes 1.0 1.1 1.3 version evolution new functionality 2.0 2.1 2.3SOE: configuration management 5
  • 252. SAP to 2006SOE: configuration management 6
  • 253. change sources: system evolution implementation 1 implementation 2 implementation 1 .......... implementation 2 implementation n .......... SAP r7.0 SAP r6.20 implementation n standard systemSOE: configuration management 7
  • 254. example: a simple requirements specification(but late) change design specificationrequest test plan system documentation user manual the customer change requests a new requestfield on a screen presentation code model code database reports test scripts and cases XML component and system interfaces SOE: configuration management 8
  • 255. a simple (but late) change request the customer change requests a new request field on a screen document -ation change test system system unit test debug rewrite build test recode SOE: configuration management 9
  • 256. change problems• change inherent in the life of the system• many developers working concurrently on many (hundreds or thousands of) documents and files• probability of introduction of further errors and communication problems• system must be built and tested, preferably early• many possible combinations of version, implementation and variant releasesSOE: configuration management 10
  • 257. software configuration management (SCM)“the purpose of Software Configuration Management is to establish and maintain theintegrity of the products of the software project throughout the projects software lifecycle. Software Configuration Management involves identifying configuration items forthe software project, controlling these configuration items and changes to them, andrecording and reporting status and change activity for these configuration items.” SEI2000aSOE: configuration management 11
  • 258. some simple CM scenarios• developer A wants to see latest version of foo.c and its change history since last week• B needs to revert foo-design.doc to its version two days ago• B makes a release of the project and he needs to know what items to include and which version• A lives in New Dehli, India and B lives in Boston, US - they want to work on HelloW.java together• in the latest release, a serious bug is found and manager C wants to track what changes caused the bug, who made those changes and when• an innocent-looking change 2 days before release causes major test problems – the whole design is rolled back to its state before the change• C wants to get reports about current project progress to decide if she needs to hire more programmers and delay the alpha release
  • 259. a set of practices: supported by tools:- change control - configuration database- version control - source code repository- release management - build tools SOE: configuration management 13
  • 260. SCM terminology• configuration item – any development output for which change control is considered necessary• baseline – a collection of configuration item(s) which is reviewed and approved, and thus under change control – often a project milestone• revision – a change to a baseline• configuration – a particular assembly of configuration items (such as all the source code files for release 3.0)• version – a configuration adding repair or new functionality• variant – a configuration with similar functionality on a different platform• release – a version or variant distributed to users
  • 261. CM activities • identification • identifying the items to be managed, establishing naming conventions (e.g. PCL- tools/edit/forms/display/AST-interface/code), storage and accessidentification control • control • change evaluation • change coordination • change approvalstatusaccounting audit • change implementation • status accounting • tracking of status of configuration items • audit • verifying that a configuration conforms to its specification
  • 262. CM practice exampleSOE: configuration management 16
  • 263. change request form changeChange Request Form control boardProject: Proteus/PCL-Tools Number: 23/02Change requester: I. Sommerville Date: 1/12/02 (CCB) reviewRequested change:When a component is selected from the structure, displaythe name of the file where it is stored.Change analyser: G. Dean Analysis date: 10/12/02Components affected: Display-Icon.Select, Display-Icon.Display changeAssociated components: FileTable implementation:Change assessment: Relatively simple to implement as a file name table isavailable. Requires the design and implementation of a display field. No changes code,to associated components are required. documentationChange priority: LowChange implementation:Estimated effort: 0.5 daysDate to CCB: 15/12/02 CCB decision date: 1/2/03 baseline updateCCB decision: Accept change. Change to be implemented in Release 2.1.Change implementor: Date of change:Date submitted to QA: QA decision:Date submitted to CM:Comments verification, audit SOE: configuration management 17
  • 264. managing collaborative working: versioncontrol, revision control • solutions: • pessimistic: file locking • optimistic: version mergingSOE: configuration management 18
  • 265. version control: terminology• checkout – creates local working copy of file• change (diff, delta) – modification to a file under version control• commit – write or merge changes to repository• merge – 2 or more sets of changes applied to repository file• delta compression – retains the only the differences between successive versions of files• trunk – mainline development stream• branch – an alternative development stream• tag/label – point in time snapshot of group of files SOE: configuration management 19
  • 266. version management tools• version and release identification • system assigns identifiers automatically when a new version is submitted to the system• storage management • system stores the differences between versions rather than all the version code• change history recording • record reasons for version creation• independent development • parallel working on different versions• project support • can manage groups of files associated with a project rather than just single filesSOE: configuration management 20
  • 267. trunk and branch, forward and reverse integrationSOE: configuration management 21
  • 268. example version control tool: SubversionSOE: configuration management 22
  • 269. system building version s ystem management c ompilers l inker builder system s ource code o bject code e xecutable b uild component script components system versions• compiling and linking software components into an executable system• different systems built from different combinations of components• invariably supported by automated tools driven by ‘build scripts’
  • 270. system building tools• building a large system is computationally expensive and may comp take several hours• hundreds of files may be involved system building tools may provide: scan.o syn.o sem.o cgen.o• • a dependency specification language and interpreter scan.c syn.c sem.c cgen.c • tool selection and instantiation support • distributed compilation • derived object management defs.hExample: SCons
  • 271. release management• release: not just a set of executable programs, may also include: • configuration files defining how the release is configured for a particular installation; • data files needed for system operation; • an installation program or shell script to install the system on target hardware; • electronic and paper documentation; • packaging and associated publicity• release creation involves collecting all files and documentation required to create a system release• configuration descriptions for different hardware and installation scripts• the release must be documented to record exactly what files were used to create it - this allows it to be re-created if necessarySOE: configuration management 25
  • 272. many varieties of integrated tool supportRational ClearCase Rational BuildForge SOE: configuration management 26
  • 273. traditional configuration management• configuration management is the management of system change to software products• a formal document naming scheme should be established and documents should be managed in a database• the configuration data base should record information about changes and change requests• a consistent scheme of version identification should be established using version numbers, attributes or change sets• system releases include executable code, data, configuration files and documentation• system building involves assembling components into a system• case tools are available to support all CM activities• case tools may be stand-alone tools or may be integrated systems which integrate support for version management, system building and change managementSOE: configuration management 27
  • 274. Agile CM automated release daily build environment test scripts version continuous control integration code sandboxSOE: configuration management 28
  • 275. traditional and agile configuration management traditional agilefocus documents and code codeactivities CM practice, change version control, management, version automated build control, automated buildresponsible CM team, CM board programmersprocess formal, managed informal and integrated with practice environmentoutcome CM audit (documented next release product control)importance indispensible in medium indispensible and large projectsSOE: refactoring and patterns 29
  • 276. Software Engineeringmanaging SE practice across the software organisation:- software metrics- Capability Maturity Model Integrated (CMMI)- Software Process Improvement (SPI)
  • 277. the problem – the SE answer • the requirements problem • the analysis problem • development project success rates in • the design problem the US: 29% • the quality problem • by budget • the project management problem • <$750,000: success = 55% >$10,000,000 success = 0% • the change problem • • England (public sector) 84% partial or • the complexity problem total failure • estimated overall: 20-30% projects are total failures (abandoned) • ”failure of large and complex information system developments is software engineering largely unavoidable” traditional agileSOE: metrics and SPI 2
  • 278. SE improvement styles internal: own experiencequalitative:description and quantitative:experience- metrics-basedbased external: professional norms, research SOE: metrics and SPI 3
  • 279. improving software engineering practice • how do you improve your metrics: establishing a practice in software knowledge baseline engineering? not as an individual, not as a team, but as a company? CMMI: orienting SE practice after SPI: improving SE professional practice normsSOE: metrics and SPI 4
  • 280. Software EngineeringSoftware Metrics
  • 281. definitions• measure - quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process. • e.g., number of errors• metric - quantitative measure of degree to which a system, component or process possesses a given attribute • e.g., number of errors found per person hours expended• indicator - group of metrics pointing towards a desirable end • e.g. product quality• a defined and commonly understood language • defect • error • failure • fault (bug)
  • 282. motivation for metrics• estimate the cost & schedule of future projects• evaluate the productivity impacts of new tools and techniques• establish productivity trends over time• improve software quality• forecast future staffing needs• anticipate and reduce future maintenance needs• ………………………• ………………………………
  • 283. example metrics• bug and analysis design code test maintain defect rates • measured by individual, module, project• defect removal process project efficiency product
  • 284. size-oriented metrics• measures • LOC - Lines Of Code • KLOC - 1000 Lines Of Code • SLOC – Statement Lines of Code (ignore whitespace) • FP • OP• typical metrics: • Errors/KLOC, Defects/KLOC, Cost/LOC, Documentation Pages/KLOC
  • 285. program complexity metrics• example - cyclomatic complexity – defines the set of independent paths through a 1 programme• V(G) = E – N + 2 2 • E is the number of flow graph edges • N is the number of nodes• V(G) is the number of (enclosed) 3 regions/areas of the planar graph• a quantitative measure of testing difficulty 7 4 5 and an indication of ultimate reliability• experimental data shows value of V(G) should be no more then 10 - testing is very 6 difficulty above this value control flow graph: sequence, selection, repetition
  • 286. design metrics• structural complexity • example: structural• data complexity complexity S(i) of a module• system complexity i.• coupling • S(i) = fout2(i) • fan out is the number of modules immediately subordinate (directly invoked).
  • 287. object-oriented metrics• weighted methods per class• depth of inheritance tree• number of children• coupling between classes• response for a class• lack of cohesion in methods (LCOM)• class size• number of operations overridden• method inheritance factor• coupling factor• polymorphism factor
  • 288. software quality and metrics product operation revision transition reliability efficiency usability maintainability testability portability reusability metrics
  • 289. JMetric
  • 290. a measurement data baseline – so what? • reduce the time to implement change requests goal • how long do change requests take, what factors question delay implementation? • tqueue, Weval, teval, Wchange, tchange, Echange, metric DchangeSOE: metrics and SPI 15
  • 291. Motorola’s metric programme• goal 1: improve project planning • adherence to schedule • goal 1: improve project• goal 2: increase defect • delivered defects and planning containment delivered defects per size • question 1.1: what was• goal 3: increase software • total effectiveness the accuracy of estimating reliability throughout the process the actual value of project• goal 4: decrease • accuracy of estimates schedule? software defect density • number of open customer • metric 1.1: schedule goal 5: improve estimation accuracy (SEA)• problems customer service • time that problems remain •• goal 6: reduce the cost open of nonconformance • cost of nonconformance• goal 7: increase software • software reliability productivitySOE: metrics and SPI 16
  • 292. independent metrics consultancy Users Y. User Satisfaction analysisA. Development B. Production A1 Study A5 Installation B1 Application Processing & Quality A2 Analysis A6 User Documentation B2 User Support B3 Repair A3 Design A7 Project Management B4 Upgrade B5 Technical Enhancement bench-marking Quality Assurance etc. ALL APPLICATIONS ALL ENVIRONMENTS A4 Implementation & Test D. Management & Administration D1 Management & Administration ALL PROJECTS ALL ENVIRONMENTSC. Development Services E. Customer Services reportingC1 Development C2 Standards C3 Quality E1 Contracting & Consulting C4 TrainingTools & Technologies & Methods Assurance SOE: metrics and SPI 17
  • 293. metrics: formal baseline of knowledge establishing a knowledge of software engineering baseline practice in place CMMI: orienting SPI: improving SE practice after SE practice professional normsSOE: metrics and SPI 18
  • 294. professional norms• professional norms: • embody professional knowledge • facilitate exchange of experience through standard nomenclature • increase predictability in processes and results • facilitate evaluation and certification of professionals • are maintained by international or national authorities or by professional organisationsSOE: metrics and SPI 19
  • 295. CMMI: a norm for software processes• Capability Maturity Model Integration• initiated by the US Dept. of Defense, late 1980’s• Watts Humphrey, Software Engineering Institute, Carnegie-Mellon University• purpose 1: qualification - identify reliable software suppliers• purpose 2: road map to increased professionalism in software organisations• key document (573 pages): http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html• other norms: ISO quality standards, project management standards (IPMA)…SOE: metrics and SPI 20
  • 296. process maturity levelsSOE: metrics and SPI 21
  • 297. SOE: metrics and SPI 22
  • 298. SOE: metrics and SPI 23
  • 299. example: requirements managementPurpose The purpose of Requirements Management (REQM) is to manage the Typical Work Products 1. Requirements status requirements of the project’s products 2. Requirements database and product components and to identify 3. Requirements decision database inconsistencies between those requirements and the project’s plans Subpractices and work products. 1. Document all requirements and requirements changes that are given to or generated by theSpecific Goal and Practice Summary project. 2. Maintain the requirements change history with theSG 1 Manage Requirements rationale for the changes. Maintaining theSP 1.1 Obtain an Understanding of change history helps track requirements Requirements volatility.SP 1.2 Obtain Commitment to Requirements 3. Evaluate the impact of requirement changes fromSP 1.3 Manage Requirements Changes the standpoint of relevant stakeholders.SP 1.4 Maintain Bidirectional Traceability of 4. Make the requirements and change data available Requirements to the project.SP 1.5 Identify Inconsistencies Between Project Work and Requirements SOE: metrics and SPI 24
  • 300. statistical process control:– the level five software organisation• software processes documented and institutionalized• software processes quantitatively measured, benchmarked and statistically evaluated• software processes continually improved and re-evaluatedSOE: metrics and SPI 25
  • 301. assumption descriptionprocess orientation What is important about a software organisation is the way the work is organised (a process). Good (mature) software organisations have defined and repeatable processes which govern the way that they work (their capability) and lead to success.hierarchical management: planning, Management has the responsibility for process standardization, learning andmonitoring, control improvement. Software developers should execute the organization’s processes according to the standardized models and descriptions.externally imposed generic process Software processes leading to effective software development are well understood andmodels share generic features which can be externally documented. These generic process models are suitable for implementation in all software organisations.documentation, standardization and Good software organizations not only have standardized and documented processes,institutionalization but those processes are institutionalized; that is, carried out throughout the organization. Software projects are therefore conducted in a similar fashion according to pre-defined process modelsorganizational progression to Software organisation improvement is understood as the movement from immaturitymaturity (undefined processes) to maturity (standardized and institutionalized processes) through a series of management led change initiatives.objective measurement, external The extent of process standardization and institutionalization can be measured, and theverification and certification measurements used to achieve 1) better standardization 2) enforcement of processes, 3) process learning leading to process improvement. Measurement represents objective knowledge about software processes, and maturity can be externally certifiedgoal-directed change through Organizational learning is achieved by the rational analysis and optimization of processesrational analysis and learning which sets the goals for organizational development and changemanagement-sponsored Software process improvement initiatives follow the principles outlined above: definedimprovement initiative and documented externally imposed process, management –led, focused on maturity, objectively measured, analysis-oriented. Thus the CMMI model is an extensive, externally imposed process plan SOE: metrics and SPI 26
  • 302. SOE: metrics and SPI 27
  • 303. Capability Immaturity Model 0 : Negligent lip service only to implementing software engineering processes. CMM level 0 organizations generally fail to produce any product, or do so by abandoning regular procedures in favor of crash programs. -1 : Obstructive Processes, however inappropriate and ineffective, are implemented with rigor and tend to obstruct work - adherence to process is the only measure of success. Any actual creation of viable product is incidental - quality of the product is not assessed -2 : Contemptuous While processes exist, they are routinely ignored by engineering staff and those charged with overseeing the processes are regarded with hostility. Measurements are fudged to make the organization look good.-3 : UnderminingNot content with faking their own performance, undermining departments routinely work to downplay and sabotage the efforts of rival teams,especially those successfully implementing processes common to CMM level 2 and higher. This is worst where company policy causes 28departments to compete for scarce resources, which are allocated to the loudest advocates. SOE: metrics and SPI
  • 304. metrics: formal baseline of knowledge establishing a knowledge of software engineering baseline practice in place CMMI: orienting software organisation SPI: improving SE practice after has institutionalized SE SE practice professional processes that match norms professional normsSOE: metrics and SPI 29
  • 305. software engineeeringSoftware Process Improvement (SPI)
  • 306. SPI: Software Process Improvement • generic name for initiatives to improve software development and management in a software company • the movement towards good software engineering practice - as experienced and as industry good practice (norm) assessment education selection installation and gap and and and analysis training justification migrationSOE: metrics and SPI 31
  • 307. IDEALSOE: metrics and SPI 32
  • 308. traditional SPI:- the CMMI project Learn by measuring results Act to Initiate CMMI project improve process control Establish Diagnose CMMI current team and maturity process level areasSOE: metrics and SPI 33
  • 309. metrics: formal baseline of knowledge establishing a knowledge of software engineering baseline practice in place software organisation has organized improvement initiatives CMMI: orienting software organisation SPI: improving SE practice after has institutionalized SE SE practice professional processes that match norms professional normsSOE: metrics and SPI 34
  • 310. the Scandinavian approach – a critique oftraditional CMMI 1. focus on problems – not on a specific solution (e.g. CMMI level 2) 2. emphasize knowledge creation – not knowledge deployment 3. encourage participation – not expert solution 4. integrate leadership – do not rely on staff work 5. plan for continuous improvement – a portfolio, not a project (Mathiassen et al., 2002)SOE: metrics and SPI 35
  • 311. Industry Knowledge model Network model Model (CMMI) (Agile)Underlying metaphor Factory Learning organization CommunityFocus/orientation Process Knowledge Software challengeManagement style Hierarchical management: Facilitation and team Self-organisation in planning, monitoring, learning networks controlGuiding principle Generic process models Experiential learning Technical masteryOrganizational form Machine bureaucracy Professionalised Virtually enabled knowledge work communityMotivation for Market pressure Individual self-motivation Self-realisation in theimprovement through professionalism technological meritocracyImprovement focus Internal efficiency, Customer satisfaction, Software solution software quality market accommodationImprovement strategy Goal-directed change Continuous learning, Code sharing, peer through rational analysis knowledge sharing, feedback, development of process knowledge, individual and collective and sharing of process documentation, competence development programming skills and standardization and techniques institutionalizationImprovement objective Process maturity, Adaptation to market Technology leadership organizational disciplineImprovement assessment Objective measurement, Responsiveness to Code quality, intellectualmethod external verification and market, improved sales, property rights certification of process profitability adherenceImprovement champions Top managers Project managers Programmers 36
  • 312. Industry Knowledge model Network model Model (CMMI) (Agile)Underlying metaphor Factory Learning organization CommunityFocus/orientation Process Knowledge Software challengeManagement style Hierarchical management: Facilitation and team Self-organisation in planning, monitoring, learning networks controlGuiding principle Generic process models Experiential learning Technical masteryOrganizational form Machine bureaucracy Professionalised Virtually enabled knowledge work communityMotivation for Market pressure Individual self-motivation Self-realisation in theimprovement through professionalism technological meritocracyImprovement focus Internal efficiency, Customer satisfaction, Software solution software quality market accommodationImprovement strategy Goal-directed change Continuous learning, Code sharing, peer through rational analysis knowledge sharing, feedback, development of process knowledge, individual and collective and sharing of process documentation, competence development programming skills and standardization and techniques institutionalizationImprovement objective Process maturity, Adaptation to market Technology leadership organizational disciplineImprovement assessment Objective measurement, Responsiveness to Code quality, intellectualmethod external verification and market, improved sales, property rights certification of process profitability adherenceImprovement champions Top managers Project managers Programmers 37
  • 313. Industry Knowledge model Network model Model (CMMI) (Agile)Underlying metaphor Factory Learning organization CommunityFocus/orientation Process Knowledge Software challengeManagement style Hierarchical management: Facilitation and team Self-organisation in planning, monitoring, learning networks controlGuiding principle Generic process models Experiential learning Technical masteryOrganizational form Machine bureaucracy Professionalised Virtually enabled knowledge work communityMotivation for Market pressure Individual self-motivation Self-realisation in theimprovement through professionalism technological meritocracyImprovement focus Internal efficiency, Customer satisfaction, Software solution software quality market accommodationImprovement strategy Goal-directed change Continuous learning, Code sharing, peer through rational analysis knowledge sharing, feedback, development of process knowledge, individual and collective and sharing of process documentation, competence development programming skills and standardization and techniques institutionalizationImprovement objective Process maturity, Adaptation to market Technology leadership organizational disciplineImprovement assessment Objective measurement, Responsiveness to Code quality, intellectualmethod external verification and market, improved sales, property rights certification of process profitability adherenceImprovement champions Top managers Project managers Programmers 38
  • 314. SPI manifesto (agile)SOE: metrics and SPI 39
  • 315. ` internal: own experience metrics programmes Scandinavian SPIqualitative:description and quantitative:experience- metrics-basedbased traditional SPI(CMMI) external: professional norms, research SOE: metrics and SPI 40
  • 316. Metrics for the Object OrientedChidamber & Kemerer ’94 TSE 20(6)Metrics specifically designed to address object oriented softwareClass oriented metricsDirect measures
  • 317. Weighted Methods per Class n WMC = c i 1 ici is the complexity (e.g., volume, cyclomatic complexity, etc.) of each methodViewpoints: (of Chidamber and Kemerer) -The number of methods and complexity of methods is an indicator of how much time and effort is required to develop and maintain the object -The larger the number of methods in an object, the greater the potential impact on the children -Objects with large number of methods are likely to be more application specific, limiting the possible reuse
  • 318. Depth of Inheritance TreeDIT is the maximum length from a node to the root (base class)Viewpoints:Lower level subclasses inherit a number of methods making behavior harder to predictDeeper trees indicate greater design complexity
  • 319. Number of ChildrenNOC is the number of subclasses immediately subordinate to a classViewpoints:As NOC grows, reuse increases - but the abstraction may be dilutedDepth is generally better than breadth in class hierarchy, since it promotes reuse of methods through inheritanceClasses higher up in the hierarchy should have more sub-classes then those lower downNOC gives an idea of the potential influence a class has on the design: classes with large number of children may require more testing
  • 320. Coupling between ClassesCBO is the number of collaborations between two classes (fan- out of a class C) • the number of other classes that are referenced in the class C (a reference to another class, A, is an reference to a method or a data member of class A)Viewpoints:As collaboration increases reuse decreasesHigh fan-outs represent class coupling to other classes/objects and thus are undesirableHigh fan-ins represent good object designs and high level of reuseNot possible to maintain high fan-in and low fan outs across the entire system
  • 321. Response for a ClassRFC is the number of methods that could be called in response to a message to a class (local + remote)Viewpoints: As RFC increasestesting effort increasesgreater the complexity of the objectharder it is to understand
  • 322. Lack of Cohesion in MethodsLCOM – poorly described in PressmanClass Ck with n methods M1,…MnIj is the set of instance variables used by Mj
  • 323. LCOMThere are n such sets I1 ,…, In • P = {(Ii, Ij) | (Ii  Ij ) = } • Q = {(Ii, Ij) | (Ii  Ij )  }If all n sets Ii are  then P = LCOM = |P| - |Q|, if |P| > |Q|LCOM = 0 otherwise
  • 324. Example LCOMTake class C with M1, M2, M3I1 = {a, b, c, d, e}I2 = {a, b, e}I3 = {x, y, z}P = {(I1, I3), (I2, I3)}Q = {(I1, I2)}Thus LCOM = 1
  • 325. ExplanationLCOM is the number of empty intersections minus the number of non-empty intersectionsThis is a notion of degree of similarity of methodsIf two methods use common instance variables then they are similarLCOM of zero is not maximally cohesive|P| = |Q| or |P| < |Q|
  • 326. Some other cohesion metrics
  • 327. Class SizeCS • Total number of operations (inherited, private, public) • Number of attributes (inherited, private, public)May be an indication of too much responsibility for a class
  • 328. Number of OperationsOverriddenNOOA large number for NOO indicates possible problems with the designPoor abstraction in inheritance hierarchy
  • 329. Number of Operations AddedNOAThe number of operations added by a subclassAs operations are added it is farther away from super classAs depth increases NOA should decrease
  • 330. Method Inheritance Factor n  M (C ) i 1 i i MIF = n .  M a (Ci ) i 1Mi(Ci) is the number of methods inherited and not overridden in CiMa(Ci) is the number of methods that can be invoked with CiMd(Ci) is the number of methods declared in Ci
  • 331. MIFMa(Ci) = Md(Ci) + Mi(Ci)All that can be invoked = new or overloaded + things inheritedMIF is [0,1]MIF near 1 means little specializationMIF near 0 means large change
  • 332. Coupling Factor  is _ client (C , C ) i j i j CF= (TC 2  TC ) .is_client(x,y) = 1 if a relationship exists between the client class and the server class. 0 otherwise(TC2-TC) is the total number of relationships possibleCF is [0,1] with 1 meaning high coupling
  • 333. Polymorphism Factor M i (Ci )o PF =  M (C )  DC (C ). i n i iMn() is the number of new methodsMo() is the number of overriding methodsDC() number of descendent classes of a base classThe number of methods that redefines inherited methods, divided by maximum number of possible distinct polymorphic situations
  • 334. Software Engineeringcourse summary
  • 335. 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: course summary 2
  • 336. course design agile development tools, approaches techniques, SPI practices traditional miniproject 1: miniproject 2: miniproject 3: DA TTP evaluationSOE: course summary 3
  • 337. the problem – the SE answer • the requirements problem • the analysis problem • development project success rates in • the design problem the US: 29% • the quality problem • by budget • the project management problem • <$750,000: success = 55% >$10,000,000 success = 0% • the change problem • • England (public sector) 84% partial or • the complexity problem total failure • estimated overall: 20-30% projects are total failures (abandoned) • ”failure of large and complex information system developments is software engineering largely unavoidable” traditional agileSOE: metrics and SPI 4
  • 338. one answer:• apply engineering principles to software development “(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).”SOE: course summary 5
  • 339. no – two answers software engineering traditional agileSOE: course summary 6
  • 340. traditional agilethe requirements problem requirements management, on-site customer, user stories, requirements engineering, iteration, test driven change control developmentthe analysis problem formal analysis techniques dialogue with customerthe design problem top down formal design evolutionary designthe quality problem formal test strategies, quality test-driven design, continuous programmes, SPI + CMMI, integration metricsthe project management estimation, scheduling, iteration, planning poker,problem predictive planning, project velocity control, change management, risk managementthe change problem configuration management, iteration, version control, risk management continuous integrationthe complexity problem anticipate and plan experiment and adapt SOE: course summary 7
  • 341. literature agile viewpoint deepening articles – thematically organised (traditional viewpoint)SOE: course summary 8
  • 342. literaturecompulsory reading:Craig Larman: Agile Iterative Development: A Managers Guide, Addison-Wesley , chapters 1-9 (buy this one)Boehm, B. & Turner, R. (2003) Observations on balancing discipline and agility. Agile Development Conference (ADC 03), Salt Lake City, UtahGray, M. M. (1999) Applicability of Metrology of Information Technology. Journal of Research - National Institute of Standards and Technology, 104(6), 567-578.Heemstra, F. (1992) Software cost estimation. Information and Software Technology, 34(10), 627-639.Nerur, S., Mahapatra, R. K. & Mangalaraj, G. (2005) Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), 72-78.Nuseibeh, B. & Easterbrook, S. (2000) Requirements engineering: a roadmap. In: ICSE 00: Proceedings of the Conference on The Future of Software Engineering, 35-46. ACM.Parnas, D. & Clements, P. (1985) A rational design process: How and why to fake it. Formal Methods and Software Development, 80- 100.Poppendieck, M. B. & Poppendieck, T. D. (2010) A Rational Design Process–It’s Time to Stop Faking It.Schuh, P. (2008) Agile Configuration management for large organizations. In: The Rational Edge, IBM.Talby, D., Hazzan, O., Dubinsky, Y. & Keren, A. (2006) Agile software testing in a large-scale project. IEEE SOFTWARE, 30-37.Tiwana, A. & Keil, M. (2004) The one-minute risk assessment tool. Communications of the ACM, 47(11), 73-77.Whittaker, J. A. (2000) What is software testing? And why is it so hard? Software, IEEE, 17(1), 70-79.supplementary reading:Pressman, R.S. Software Engineering: A Practitioners Approach European Adaption (Paperback) fifth edition, Parts 1-3. Use this to deepen your understanding of traditional topics where you find it necessary (you can find it online). You can also use another edition (there are several) but be careful you read the corresponding chapters. The chapter numbering systems can be quite different.SOE: course summary 9
  • 343. course content: mindmapSOE: course summary 10
  • 344. course content by ten revision topics comparison of iterative and agile methods: UP, SCRUM, XP traditional and agile development approaches: similarities and differences requirements: traditional and agile analysis and design: traditional and agile test: traditional and agile risk analysis: traditional (and agile) project management, scheduling and estimation: traditional and agile top down and bottom up design: refactoring and design patterns configuration management: traditional and agile metrics and software process improvement: traditional and agileSOE: course summary 11
  • 345. comparison of iterative and agile methods: UP, SCRUM, XP 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 phases• work products, roles, practices• UP – iterative not necessarily agile• SCRUM – team management• XP – programmer orientation SOE: course summary 12
  • 346. traditional and agile development approaches:similarities and differences• T or A development approach• T or A software engineeringSOE: course summary 13
  • 347. requirements: traditional and agile on-site customer, product owner user stories, product backlog iteration, sprint requirements specification: an agreed, mutually understood and test relatively stable account cases of what to buildSOE: course summary 14
  • 348. analysis and design: traditional and agile use domain CRC cards requirements specification continuous metaphor design improvement high level design refactoringSOE: course summary 15
  • 349. test: traditional and agile • XP: test-driven development test automation test cases iteration, sprint acceptance continuous testing integrationSOE: course summary 16
  • 350. risk analysis: traditional (and agile) risk analysis change risk response = iteration risk riskidentification prioritisation one minute risk management risk riskmanagement mitigation risk monitoringSOE: course summary ? 17
  • 351. project management, scheduling and estimation:traditional and agile two contract phase plan predictive planning adaptive iteration and release planning technique- corrective based planning control estimation velocity poker monitoring time-boxing story points ideal days burndown formal chart predictive scheduling risk analysisSOE: course summary 18
  • 352. top down andbottom up design: architecturerefactoring anddesign patterns traditional architectural patterns agile design as model design as code GRASP design refactoring patterns detailed designSOE: course summary 19
  • 353. configuration management: traditional and agile identification control status accounting auditSOE: course summary 20
  • 354. metrics and software process improvement:traditional and agileSOE: course summary 21
  • 355. perspectives • with standard shortcomings• traditional SE - a • limits creativity and developer standard response to initiative difficult problems • distributes responsibility • discipline and rational • expensive and goal-displacing analysis • standard one-size-fits-all • quantitative and scientific solutions which are hard to • rules, routines and adapt to changing conditions procedures • creates many products with • documentation and no direct value bureaucracy • complexity analysis limited by • hierarchy and control human understandingSOE: course summary 22
  • 356. • agile – a serious • taken to extremes - flight response to the from things that shortcomings of developers find unpleasant traditional SE • discipline, standardization, • minimal bureaucracy and documentation hierarchy • authority • focus on software production and quality • serious investigation of customer domain • improvement through experimentation replaces • non-coding tasks rational analysis • delivery deadlines • developers regain • contractual responsibilities control and responsibilitySOE: course summary 23
  • 357. • exploit freedom and • find the discipline in flexibility in traditional agility and use traditional SE and scale to task tools where appropriateSOE: course summary 24

×