CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 2A.1 Software Engineering:...

CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.1

Software Engineering: Analysis and Design - CSE3308

What is Analysis and Design?

Monash University - School of Computer Science and Software Engineering

CSE3308/CSC3080/DMS/2000/3


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:

EssentialModel

ImplementationModel

Role of the Analyst Role of the Designer

Description of the Problem Description of the Solution


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 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 Transformationprocess

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?


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

Date post:	21-Dec-2015
Category:	Documents
View:	215 times
Download:	0 times

CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 2A.1 Software Engineering:...

Documents