Lecture 1 (

bloatdecorumSoftware and s/w Development

Oct 30, 2013 (3 years and 11 months ago)

95 views

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Lecture 1 (
6365 and 6677)

Administration,

SDLC & Purpose of Analysis

Annette Vincent


Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

2

Outline


Administration


What is Systems Analysis?


SDLC Context


What is
Modelling
?


Research Skills Focus


References


Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

3

Administration



Annette Vincent


Sessional

Lecturer


Craig McDonald


Unit convener


Course context


Unit context


Outline walkthrough


Unit Research expectations


Tutorials


Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

4

Course Context

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Research Led Learning

5

Learning Outcomes

Organisation

Issues

Problem Solving

Professionalism

Organisation

Bloom’s Taxonomy

System Purpose

Needs and
issues

Organisational
Changes and assoc.
Issues

Measure effectiveness

Quality
Assurance

Knowledge

P
-

Comprehension

P

Application

P+

Analysis

CR

Synthesis

DI

Evaluation

HD

Research Evidence

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

6

What is Systems Analysis?

The activities involved in establishing a complete and
unambiguous set of
functional requirements

that can be
demonstrably tested.


Defining
WHAT

the system is to do (the requirements).

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

7

SDLC Methodologies


Waterfall


Structured Iterative


Spiral


Agile


Acquisition of COTS Products

(Commercial Off The Shelf)


. . .


Irrespective of the Methodology
-

System Analysis
must be performed

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

(Modified) Waterfall

[5]

8

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Waterfall


Rigid, perform stages in order (sequential)


First used in 70’s


Still common


Doesn’t allow for changing requirements

“No battle plan survives first contact with the enemy” [4]


Risk deferred to late in project

(discover problems too late to fix)

The dreaded integration phase.


Can run out of time/money with no deliverable product




9

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Structured Iterative


[3]

Time

IBM® Rational Unified Process® (RUP®)

10

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Structured Iterative


Or ‘Iterative Incremental’


Business value is delivered incrementally


Focus on architecture related and business
critical features in early iterations


Allows for changing requirements





11

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Spiral

[7]

12

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Spiral


Cycle of


Analysis


Design


Implementation


Refinement at each iteration around the
cycle.


Scope increases for each iteration.


13

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Agile


Group of related methodologies


Attempt to address risks with waterfall


Agile Manifesto :



“Individuals
and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a
plan” [2]

14

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Agile


Lightweight (in contrast to ‘heavyweight’ waterfall)


Promote development, teamwork, collaboration, and
process adaptability


Small increments with minimal planning


Agile Methodologies


XP (Extreme Programming)


SCRUM (Sprints)


Adaptive Software Development


Etc



15

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Other Methodologies/Techniques


Rapid Application Development
(Rapid Prototyping)


MDA
(Model Driven Architecture)


Hybrids


Chaos


....


16

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012


Poor Requirements
are
a primary reason for excessive rework,

delays and poor quality

0

Time not spent in getting
requirements right is time spent
in rework

System Analysis Importance :

Cost of Rework

[8]

17

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

18

Functional Requirements

Requirements specifying the
functions

that the system is to perform.








(aka Essential Requirements [9])




Unambiguous



Complete



Verifiable



Consistent



Modifiable



Traceable

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Non Functional Requirements


Requirements not related to a capability/function of the
system, including :



Performance


Conformance to standards (e.g. User interface standards)


Constraints (e.g. Must run on existing infrastructure)


Legislative Compliance (e.g. Privacy)



Most non functional requirements are design considerations

19

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Inputs to Systems Analysis


Business Case


Market / Domain Research


Users / Stakeholders


Existing System / Documentation


Informal Requirements Documents (Brief)




20

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

21

What is Systems Design?


Uses outputs from analysis as inputs.


Specifies
HOW

the system is to be built.


Business Case specifies
WHY


Project Plan specifies
WHO

and
WHEN



Non functional requirements often impact
design



Out of Scope
for this unit.

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Business Analyst Role

The role investigates, analyses and suggests improvements in business
process. It designs business process requirements that can be enhanced with
ICT development to related business, financial and operations systems critical to
core organisational functions.


Conduit between Business and IT


BA Responsibilities


Identify Stakeholders


Communicate with Users & Stakeholders


Discovering business rules


Capture business rules


Convert business rules into requirements & document requirements


Prepare analysis & design documentation

22

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Why do Analysis?


To build the right system



To document the functions of the system


So we can test if we have
satisifed

the requirements


Mitigate impact when staff changes


Have a basis for change control



23

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

24

Modelling

“All Models are wrong but some are useful” [1]


Models ignore some aspects of the real world
to better focus on other aspects (abstraction)


In this course we will concentrate on various
visual

models (
diagrams).



Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

25

Models

Standard
modelling

notations provide
common understanding.


[6]

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

26

Modelling


Structured Models


Object Oriented Models


Industry projects will usually be
modelled

using one of the above
modelling

strategies.

Or possibly a mix.


Age of project, industry sector, project type,
organisational

standards affect the choice of
models.

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

27

Research


One of the outcomes of the course is to
improve research skills.



TODO : review UC plagiarism & referencing
site



Inadequate referencing in the assignments
will result in the grade being downgraded to
a maximum of P.


Referencing
only

the lecture notes and textbook
is considered inadequate.

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

Questions?


28

Faculty of

ISE

Systems Analysis and
Modelling

Semester 1 2012

29

[1]

Box
,
George E.P. , 1979 "Robustness in the Strategy of Scientific Model Building" (May 1979) in


Robustness in Statistics: Proceedings of a Workshop

edited by RL
Launer

and GN Wilkinson


[2]

“Manifesto for Agile Software Development“,

http://agilemanifesto.org/



viewed 1 February 2012


[3]



UML, RUP, and the
Zachman

Framework: Better together“,

http://www.ibm.com/developerworks/rational/library/nov06/temnenco/


Figure 3, viewed 1 February 2012


[4]

von
Moltke
,
Helmuth
, Originally in
Moltke
,
Helmuth
, Graf Von,
Militarische

Werke
. vol. 2, part 2., pp. 33
-
40.


Found in Hughes, Daniel J. (ed.)
Moltke

on the Art of War: selected writings
. (1993).


Presidio

Press: New York, New York.
ISBN 0
-
89141
-
575
-
0
. p. 45
-
47


[5]

“Managed Mayhem“,

http://www.managedmayhem.com/2009/05/06/sashimi
-
waterfall
-
software
-
development
-
process/


viewed 1 February 2012


[6]

“The K
-
6 Teaching American History Project“,

http://www.washoe.k12.nv.us/americanhistory/elementary/index.htm


viewed 1 February 2012


[7]

“Spiral Model”,

http://newton.cs.concordia.ca/~paquet/wiki/index.php/Spiral_model


viewed 1 February 2012


[8]

“The Incredible Rate of Diminishing Returns of Fixing Software Bugs”,


http://www.superwebdeveloper.com/2009/11/25/the
-
incredible
-
rate
-
of
-
diminishing
-
returns
-
of
-
fixing
-
software
-
bugs/


viewed 1 February 2012


[9]

Lucas, Richard . (2010) Lectures on a Methodology For Systems Analysis.


University of Canberra Systems Analysis and Modelling Semester 2 2010






References