Post on 21-Dec-2015
transcript
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.2
Lecture Outline
Defining Analysis and Design Why do Analysis and Design? Types of Analysis and Design
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.3
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.4
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.5
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!
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.6
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.7
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.8
Cost of Analysis/Design Errors
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.9
Source of Errors
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.10
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.11
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.12
Soft Systems Methodology (SSM) Developed by Peter Checkland Aims to represent the multiple perspectives
that users have of a system
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.13
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)
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.14
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”
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.15
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.16
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.17
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
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.18
“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?
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.19
Root Definition
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.20
Root definition (2)
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.21
Rich Pictures
CSE3308/CSC3080 - Software Engineering: Analysis and Design Lecture 2A.22
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