Date post: | 02-Jan-2016 |
Category: |
Documents |
Upload: | emerald-bryant |
View: | 31 times |
Download: | 0 times |
Review
The goal of systems analysis and design is to understand and specify (analysis) the needs of an information system, and then solve (design) how to make it happen
Usually this is in the form of a project that follows some flavor of Systems Development Life Cycle (SDLC)
INFO 355 Week #1 2
SDLC core processes
Within a typical SDLC we need to: Identify the problem Plan and monitor the project Clarify the problem (requirements) Design the components to solve it Build, test, and integrate those
components Conduct system level testing and
deploy the system
INFO 355 Week #1 3
Waterfall versus Agile
In the waterfall life cycle, each process is done once and fully before going to the next process Often the plan is set in stone
In the Agile development methods, we assume we don’t know the problem very well, so we expect the plan will change as the project unfolds iteratively
INFO 355 Week #1 4
Iterative development
In iterative development, the six processes of the SDLC are repeated over and over, first focusing more on early processes, later iterations doing more development and testing
INFO 355 Week #1 5
RMO?
The text uses Ridgeline Mountain Outfitters (RMO) as a running example of IS development I’m positive they aren’t based on REI I won’t focus on the RMO example
INFO 355 Week #1 6
Project Vision document
One way to propose a new project is to write a System Vision Document for it Problem description – why need this? System capabilities – high level
functional requirements Business benefits – projected
improvements in process speed and/or quality, customer base, etc.
INFO 355 Week #1 7
Project Planning
If the vision gets support, next develop and follow the project plan Identify major subsystems, interfaces Plan the first iteration in detail
Break tasks down in a WBS (work breakdown structure)
Get user feedback Identify use cases Identify object classes
INFO 355 Week #1 8
Project Planning
Then develop a use case diagram and activity diagrams
Define screen layouts (input and output)
Define database structure (see INFO 210)
Design the structure of the system (architecture)
INFO 355 Week #1 9
Project Planning
Then refine the class diagram Design subsystems in detail Implement use cases through
system testing Deploy system when system test
results are ‘good enough’
INFO 355 Week #1 10
INFO 355 versus INFO 200
So in procedural development (INFO 200) you capture processes in the DFD and data structure in the ERD, but the details of implementation are missing
Here we define requirements in ‘use cases’ and capture more details of design in a class diagram and sequence diagrams
INFO 355 Week #1 11
INFO 355 Week #1 12
What is an Object?
“An entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, behavior is represented by operations, methods, and state machines. An object is an instance of a class.” (UML 1.5 spec)
INFO 355 Week #1 13
Huh?
Attributes are the data contained by an object, if any
Relationships describe which objects are allowed to talk to each other
The operations and methods describe the ways objects can interact with each other
So objects are a set of data which can only be acted on in certain prescribed ways
INFO 355 Week #1 14
What is a Class?
“A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment.” (UML 1.5 spec)
Hence a class is a group of similar objects
INFO 355 Week #1 15
What is Object Oriented?
The methods isolate the data, so that it can’t be manipulated directly
Only the methods can create, read, modify, or delete data
Image from Apple, “Object-Oriented Programming and the Objective-C Language”
Investigating System Requirements
To understand an existing organization, determine their: Technology architecture – the
hardware, networking, and system software in use
Application architecture – the applications running on the technology architecture used to perform business processes and run their IS
INFO 355 Week #1 16
Systems Analysis
Five major activities within this process Gather detailed information Define requirements Prioritize requirements Develop user-interface dialogs Evaluate requirements with users
INFO 355 Week #1 17
Requirements
Functional requirements WHAT can someone do using the
system? Non-functional requirements
HOW WELL can the system perform functional requirements?
Usability, reliability, performance, security, maintainability, etc.
INFO 355 Week #1 18
FURPS+
Design constraints (OS, power, memory usage, etc.)
Implementation constraints (prog language, tools used, IDE, etc.)
Interface requirements (export XML files, get data from NYSE)
Physical requirements (size, weight) Supportability requirements
(autoupdate)
INFO 355 Week #1 19
FURPS = Functionality, Usability, Reliability, Performance and Supportability
Modeling
In analysis and design, modeling is critical for communicating the results of our work Some models are text, many are
graphic, few mathematical For object oriented A&D, UML is the
graphic language used
INFO 355 Week #1 20
INFO 355 Week #1 21
A Little History
While object oriented programming has existed since at least 1980 (Smalltalk), there were many ways to describe and diagram an object oriented system
Everybody had their own notation – Booch, Rumbaugh, Jacobson, etc.
Finally unified in 1997 with UML
INFO 355 Week #1 22
What’s UML?
UML, the Unified Modeling Language, is essentially a drawing convention to express object oriented software structure and functionality Just like architects use blueprints to
express different aspects of a building (e.g. plumbing vs. exterior), UML has different types of drawings
INFO 355 Week #1 23
UML Standard
UML is defined by a standard from the Object Management Group (OMG!) Current version is 2.5, dated
September 2013 Our goal is to focus on the most
useful parts of UML English has 600,000 words, but you
don’t need to know all of them
Stakeholders
To get complete requirements, need to identify and solicit all types of stakeholders in the project (p. 47) Internal stakeholders – employees,
volunteers, students External stakeholders – suppliers,
government agencies (regulators)
INFO 355 Week #1 24
Stakeholders
Operational stakeholders – interact with the system
Executive stakeholders – don’t interact with the system
The client or sponsor pays for the project, may or may not actually use it
Technical or support staff are also stakeholders, help maintain the system
INFO 355 Week #1 25
Information-Gathering Techniques
Interviewing stakeholders Questionnaires Review legacy system inputs,
outputs, documentation Observe and document existing
business processes and procedures Research vendor solutions Collect user comments, suggestions
INFO 355 Week #1 26
INFO 355 Week #8 27
Activity Diagrams
Activity Diagrams are a type of flowchart used to describe a business process or workflow They support parallel tasks, which
a traditional flowchart can’t handle They are derived from state
diagram notation, so don’t be surprised by the similarities
INFO 355 Week #8 28
Scope of Activity Diagrams
An activity diagram might show the logic for a complex use case (and all its extensions), or show the interaction among several use cases (such as when included use cases apply) An activity diagram can show the
logical decisions of a process that the use case diagram can’t show
INFO 355 Week #8 29
Activity Diagram Notation
Activity diagram notation includes The processes to be performed, which
appear as boxes with rounded corners The processes are connected by lines
with arrows, to show the direction of process flow
Arrows are always directional in an activity diagram
Use the Guard field for conditions Decisions are shown by diamonds
INFO 355 Week #8 30
Activity Diagram Simple Example
Fill Order Delay Order
[normal order] [urgent order]
Receive Order
Same start shape as State Diagram
Same end shape as State Diagram
Transition line with Guard condition
Process (same shape as a state)
Decision
Merge
INFO 355 Week #8 31
Decisions
Notice that the diamond symbol is used to show a split in the process flow due to a decision
And the same symbol is used to show when the process flows merge afterwards
[condition] [not condition]
Decision Merge
INFO 355 Week #8 32
Concurrent Flow
Notice the implied assumption of time going forward down the page
Concurrent, or parallel flows can be shown by using a ‘fork’ symbol when the flows split, and a ‘join’ symbol when they reconnect
Fork Join
INFO 355 Week #8 33
Uses for Concurrent Flow
Several parallel activities might take place after a single decision
For example, approval of a release might initiate parallel activities to Prepare a release description Start packaging the release Notify customer of impending release Lock the contents of the release
INFO 355 Week #8 34
Concurrency ExampleApprove Release
Prepare Release Description
Package Release
Notify Customer
Lock Release Contents
Review Release Description
Audit Package ContentsUnlock Next Release
Execute Release
Shows four concurrent activity threads to prepare for a new baseline release; this might all be part of a process called Prepare Release
INFO 355 Week #8 35
Partitions
Notice that activities are often performed by different organizations within your project You could add the organization to the
activity name, e.g. ‘Program Control Notifies Customer’
Or use the approach on the next slide Here is another variation on the
“swimlane” approach (each organization has its own ‘lane’)
INFO 355 Week #8 36
Partition Example
Receive Order
Fill Order
Deliver Order
Send Invoice
Receive Payment
Close Order
Order Fulfillment
Customer Service Finance
INFO 355 Week #8 37
Adding Details - Decomposing
Each step in an activity diagram could correspond to (or be decomposed into) a process or procedure which is documented elsewhere For example, Prepare Release
Description could follow a procedure to explain it in more detail
INFO 355 Week #8 38
Adding Details - Decomposing
For that matter, the whole development process could be described in a single step, then broken down to any desired level of detail
Develop Product Follow Life Cycle Phases Perform Support ActivitiesBecomes
INFO 355 Week #8 39
Adding Details - Decomposing
Perform Inception Phase
Perform Elaboration Phase
Perform Construction Phase
Perform Transition Phase
Manage Project
Manage Configuration
Manage Quality
Which in turn becomes
Notice similarity to the project schedule (WBS)
INFO 355 Week #8 40
Timing and Signals
So far the sense of time has been pretty vague Time goes forward down the page Forks and joins indicate when
concurrent processes collectively begin and end
Decisions and merges reflect the start and end of conditional process paths
To be more precise, use signals
INFO 355 Week #8 41
Signals
A Time Signal can be used to indicate when a process waits for a specific timed event before it begins E.g. end of month to start generating
a report The Time Signal is like an hourglass,
labeled to show what event for which it waits (I made this one manually)
Wait 48 hours
INFO 355 Week #8 42
Signals
Send Signals are triggered by some process to start a timer
Receive Signals accept a signal as input, and usually sound like an event more than a process ‘Taxi arrives,’ ‘Itinerary confirmed,’ etc.
<no receive action><no send action>
INFO 355 Week #8 43
Signals
A signal can be split by a ‘fork’ symbol Fig 11.6, p. 123 (Send and receive
labels overwrittenmanually)
Reserve Itinerary
<no send action>
<no receive action>
Wait 48 hours
Send Itinerary
Cancel Itinerary
Book Itinerary
Itinerary Confirmed
INFO 355 Week #8 44
Tokens
To help follow a process, it sometimes helps to imagine physical tokens being passed along the paths A fork creates two or more tokens
to follow each path separately A join waits for all tokens to arrive
before proceeding