Software Engineering: Analysis and Design - CSE3308 CSE3308/CSC3080/DMS/2000/3 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 What is Analysis and Design?

Lecture Outline Defining Analysis and Design Why do Analysis and Design? Types of Analysis and Design

Definitions Many different definitions of the difference between analysis and design In the past there was common agreement Was viewed as follows: Description of the Problem Description of the Solution Essential Model Implementation Model Role of the Analyst Role of the Designer

Definitions (2) Structured Analysis and Structured Design Different Tools used to develop system often different teams used to do analysis and design Clear distinction between tasks Leads to the Analysis/Design Wall

Definitions (3) With newer development methods, the divide between analysis and design breaks down the concept of seamlessness that an essential model is very difficult to develop without reference to the implementation issues the increasing emphasis on requirements analysis Some commentators see only Requirements Analysis High-level Design Low-level Design The debate rages on!

Definitions (4) Systems Analysis Systems Design Process of defining a problem, gathering the requirements and developing an analysis model representing those requirements Describing the problem the system means to solve Systems Design Process by which the analysis model is transformed into a model which is capable of being implemented Describing the solution to the problem

Why do analysis and design? Add formality Reduce errors Improve communication between participants Get the requirements right! Can be a factor of 100 in the cost of fixing analysis and design errors from analysis phase to maintenance phase Generate documentation

Cost of Analysis/Design Errors

Source of Errors

Types of Analysis/Design Top-down Analysis and Design Structured Analysis SADT Object-Oriented Analysis and Design Object Modeling Technique (OMT) Booch OOA&D Unified Modeling Language (UML) OPEN/Mentor (Australian based) Brian Henderson-Sellars and Object-Oriented Pty. Ltd. Data-Driven Analysis and Design Jackson System Design Warnier-Orr Method Soft Systems Methodology

Data-driven Analysis and Design Structure of system is driven by mapping system inputs to outputs Software structure can be directly derived from the data structure More concentration on timing and scheduling than in Structured Analysis and Design (specifically Jackson System Design) Both methods have been extensively used but have only a very small market share

Soft Systems Methodology (SSM) Developed by Peter Checkland Aims to represent the multiple perspectives that users have of a system

Soft Systems Methodology vs. Hard Systems Engineering (1) “Hard” systems engineers are used to producing a well-defined system to achieve clearly stated objectives In many real situations, things are less clear: “See what you can do to help us” (Marketing director of textile business) “Make me a plan” (Owner of small carpet-making business) “Try to improve the project” (Director of British Aircraft Corporation, with reference to the Concorde project)

Soft Systems Methodology vs. Hard Systems Engineering (2) The traditional activity of “Hard” systems engineers is “how-oriented”: How can this need be met? (design) This assumes that what to do is already defined SSM endeavours to address the question: What is needed? (requirements analysis) SSM is a system of enquiry. Several notional systems which might be relevant are: defined and modeled compared with the perceived problem situation used to articulate a debate about change, which takes in both “whats” and “hows”

Naming Relevant Systems System names must be written such that a model of the system can be built. These names are known as root definitions. A root definition expresses the core purpose of a purposeful activity system. The core purpose is always expressed as a transformation T of entity “input” into some new form of that entity “output” input Transformation process output

CATWOE Well-formulated root definitions should be prepared by consciously considering each of the following elements: C - Customers: the victims/beneficiaries of T A - Actors: those who would do T T - Transformation process: the conversion of input to output W - Weltanschauung: the worldview which makes this T meaningful in context O - Owners: those who could stop T E - Environmental constraints: elements outside the system which it takes as given

Root definition A full root definition’s core transformation T would be: “a system to do X by Y in order to achieve Z” where T is the means Y, Z is related to O’s longer term aims Y should be an arguably appropriate means for doing X It is generally useful to write root definitions with the XYZ formula in mind

“The Three Es” Any transformation T of input to output can be judged successful or unsuccessful on three criteria: Efficacy Does the means work? Efficiency amount of output divided by amount of resources used Effectiveness is T meeting the longer term aim? Also mention Ethicality and Elegance

Root Definition

Root definition (2)

Rich Pictures

Types of Analysis in SSM Role Analysis Social System Analysis Political System Analysis SSM provides tools to integrate the three types of analysis Problems with integrating results of the analysis with design/implementation of an information system Soft Systems Methodology In Action by Peter Checkland and Jim Scholes Hargrave Library 003 C514S