Software Development Processes Based on Chapter 21 of

Software Development Processes Based on Chapter 21 of Bennett, Mc. Robb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4 th Edition), Mc. Graw Hill, 2010. © 2010 Bennett, Mc. Robb and Farmer

In This Lecture You Will Learn: • What a software development process is, and how this relates to method and methodology • Why methodologies are used • Some characteristics of the Unified Software Development Process • Some issues in choosing a methodology 2 © 2010 Bennett, Mc. Robb and Farmer

Process, Method and Methodology • Process or method refers to the tasks carried out during a project • Methodology refers to the general framework and principles used to organise the tasks • Some authors use method to mean methodology • Some authors use process for both! 3 © 2010 Bennett, Mc. Robb and Farmer

Why Methodology? • Techniques of system development must be organized if they are to work together – Analyst has drawn collaboration diagrams for main use cases – Should she now convert these to sequence diagrams and write operation specifications? – Or concentrate on class diagram, inheritance and composition structures? • UML itself contains nothing that helps to make this decision 4 © 2010 Bennett, Mc. Robb and Farmer

Why Methodology? • Organization of tasks is not contained within the techniques • Must be described at a higher level of abstraction • Method or process of a project is the particular way that tasks in that project are organized • Methodology is more abstract still: a metaprocess that can be applied to many projects • A methodology is instantiated on a project 5 © 2010 Bennett, Mc. Robb and Farmer

Process, Method or Methodology? • Often confused, as if they were all the same thing, but actually these terms differ • Method/Process = step-by-step description of the steps involved in doing a particular job • No two projects are ever identical, so method is specific to one project • Methodology = set of general principles that guide the choice of a method suited to a specific task or project 6 © 2010 Bennett, Mc. Robb and Farmer

Method/Process vs. Methodology Level of abstraction Example of application Developing a first-cut class diagram Method/Process Methodology Any UML class diagram Specific techniques used on a particular project that lead to a specific software product A product costing system General selection and sequence of techniques capable of producing a range of software products Technique Specific version of a class diagram Description of how to carry out a technique, e. g. UML class modelling Task Typical product A range of business software applications 7 © 2010 Bennett, Mc. Robb and Farmer

What Is a Methodology? • Avison and Fitzgerald (2002): a collection of – – Procedures Techniques Tools Documentation aids • Organised within a lifecycle structure (or process) • Usually also an underlying philosophy that captures a particular view of the meaning and purpose of IS development 8 © 2010 Bennett, Mc. Robb and Farmer

Elements of a Methodology • Technique: the UML class diagram • Tool: Rational Rose (CASE software) • Procedure: Find classes by inspecting use case descriptions • Structure: Operation specifications should not be written until class model is stable (also the stages) • Stages: Inception, Elaboration, Construction… • Activities: Requirements, Analysis, Design… • Philosophy: OO development promotes software which is robust and resilient to change 9 © 2010 Bennett, Mc. Robb and Farmer

Methodology Metamodel • The OMG has defined a metamodel for software development methodologies • Software Process Engineering Metamodel (SPEM) uses UML notation for: – – Roles (e. g. class designer) Activities (e. g. design) Products (e. g. design class model) Phases (e. g. construction) • The ultimate aim is to define a process with sufficient rigour that much of it can be automated 10 © 2010 Bennett, Mc. Robb and Farmer

Why Use a Methodology? • Many advantages claimed – Helps produce better quality product • • – – Better documented software More acceptable to user More maintainable software More consistent software Helps ensure user requirements are met Helps project manager control the project Reduces development costs Promotes communication among all parties 11 © 2010 Bennett, Mc. Robb and Farmer

Unified Software Development Process (USDP) • Public domain methodology for Object-Oriented software development • Originally produced by Rational team • Now largely superseded by Rational Unified Process (similar in their main aspects) • Main principles: – – Use-case driven Architecture-centric Iterative development Incremental development 12 © 2010 Bennett, Mc. Robb and Farmer

Use-Case Driven • In USDP the basic element is a single interaction between user and system • Use cases are the start of modelling • Unit from which later models are derived • Each use case is a thread that links requirements to implementation • Has practical significance for users • Constant reminder to systems developers that only users’ requirements really matter 13 © 2010 Bennett, Mc. Robb and Farmer

Use Case-Driven 1 Add new staff Accountant 14 © 2010 Bennett, Mc. Robb and

Use Case-Driven 2 create. Staff ( ) : Add. New. Staff. UI Accountant Staff

Use Case-Driven 3 Staff Member staff. Name staff. No staff. Start. Date assign. Staff.

Architecture-Centric • In USDP, software architecture is a theme from the earliest stages of a project • Reflected most obviously in: – Stereotyping of boundary, control and entity classes – Use of packages to organize both models and development activity 17 © 2010 Bennett, Mc. Robb and Farmer

Architecture-centric Analysis Package Campaign Management User Interface Staff Management Control 18 © 2010 Bennett,

Iterative Development • The USDP lifecycle is cyclic: – Analyse a bit – Design

Incremental Development • USDP aims to deliver working, freestanding, useful ‘chunks’ of software, one at a time • (Corresponds to DSDM in this respect) • In its simplest form, each use case may represent one increment of delivered software 20 © 2010 Bennett, Mc. Robb and Farmer

Activities and Phases • • Activity has meaning for developers Phase matters to project manager Phases are sequential, delineated by milestones Each milestone is a decision point: – Begin next phase or stop now? • Manager’s focus shifts from one phase to the next • Within each phase, activities iterate 21 © 2010 Bennett, Mc. Robb and Farmer

Phases (and time) Iterations Workflows Inception 1 2 Elaboration 3 4 Construction Transition 5

Phases and Iterations • No set rule for number of iterations • Within a phase, workflows are the same • All 4 phases run from requirements to testing, but emphasis changes • At first, main effort is on capture, modelling, analysis of requirements • Later phases emphasize implementation and testing 23 © 2010 Bennett, Mc. Robb and Farmer

Inception Phase • Essentially a feasibility stage: do potential risks outweigh potential benefits • Decision based partly on CBA • Viability of project judged on delivery of a small subset of requirements as working software 24 © 2010 Bennett, Mc. Robb and Farmer

Inception Phase • Main activities: – Requirements capture – Analysis – Small amount of design, implementation and testing • Even at this early stage, iteration is likely • OO approach makes this possible 25 © 2010 Bennett, Mc. Robb and Farmer

Elaboration Phase • Produce design for a suitable system • Aim is to reduce cost uncertainties • Demonstrate how system can be built within acceptable timescale and budget • Proportion of time spent on design activities increases • Small increase in time on implementation and testing (still small in relation to analysis and design) 26 © 2010 Bennett, Mc. Robb and Farmer

Construction phase • Build, through several iterations, a system capable of satisfactory operation in target environment • Implementation and testing rapidly become core activities • Each iteration moves away from design and towards testing 27 © 2010 Bennett, Mc. Robb and Farmer

Transition phase • Achieve the intended full capability of the system • Deal with any defects or problems that have emerged • Includes system conversion, if older system is being replaced 28 © 2010 Bennett, Mc. Robb and Farmer

Workers and Activities • USDP differentiates between real people and the more abstract worker • A Worker is a project role, e. g. – use-case specifier – system architect – component engineer – integration tester • No direct one-to-one mapping between people and workers 29 © 2010 Bennett, Mc. Robb and Farmer

Inputs and Outputs of an Activity 30 © 2010 Bennett, Mc. Robb and Farmer

The Analysis Workflow in USDP Architect Analyse Architecture architecture Architecture Use Case Engineer Component Engineer Analyse aa Analyse Use Case Analyse a Class Analyse aa Analyse Package adapted from Jacobson et al. , 1999 31 © 2010 Bennett, Mc. Robb and Farmer

USDP: Summary • Rooted in: – Booch method (good at design and implementation) – OMT (good at analysis) – Objectory (strong at requirements engineering and system architecture) • USDP brought these together • Also large and complex: significant learning curve involved, or tailor to fit • Led to RUP – the most mature OO methodology to date 32 © 2010 Bennett, Mc. Robb and Farmer