Transcript Introduction to Information System

Asst.Prof. Dr. Surasak Mungsing
Learning Objectives
 Explain the purpose and various phases of the systems
development life cycle (SDLC)
 Explain when to use an adaptive approach to the SDLC in
place of a more predictive traditional SDLC
 Explain the differences between a model, a tool, a
technique, and a methodology
 Describe the two overall approaches used to develop
information systems: the traditional method and the
object-oriented method
3
The Systems Development Lifecycle (SDLC)
 Systems development life cycle (SDLC)
 Provides overall framework for managing systems
development process
 Two main approaches to SDLC
 Predictive approach – assumes project can be planned out
in advance
 Adaptive approach – more flexible, assumes project
cannot be planned out in advance
 All projects use some variation of SDLC
4
Traditional Predictive Approach to the SDLC
 Project planning – initiate, ensure feasibility, plan schedule,




5
obtain approval for project
Analysis – understand business needs and processing
requirements
Design – define solution system based on requirements and
analysis decisions
Implementation – construct, test, train users, and install
new system
Support – keep system running and improve
“Waterfall” Approach to the SDLC
6
Modified Waterfall Approach
with Overlapping Phases
7
Newer Adaptive Approaches to the SDLC
 Based on spiral model
 Project cycles through
development activities
over and over until project
is complete
 Prototype created by end
of each cycle
 Focuses on mitigating risk
 Iteration – Work activities are
repeated
 Each iteration refines
previous result
 Approach assumes no one
gets it right the first time
 There are a series of mini
projects for each iteration
8
Activities of Planning Phase of SDLC
 Define business problem and scope
 Produce detailed project schedule
 Confirm project feasibility
 Economic, organizational, technical, resource, and
schedule
 Staff the project (resource management)
 Launch project  official announcement
9
Activities of Analysis Phase of SDLC
 Gather information to learn problem domain
 Define system requirements
 Build prototypes for discovery of requirements
 Prioritize requirements
 Generate and evaluate alternatives
 Review recommendations with management
10
Activities of Design Phase of SDLC
 Design and integrate the network
 Design the application architecture
 Design the user interfaces
 Design the system interfaces
 Design and integrate the database
 Prototype for design details
 Design and integrate system controls
11
Activities of Implementation Phase of SDLC
 Construct software components
 Verify and test
 Convert data
 Train users and document the system
 Install the system
12
Activities of Support Phase of SDLC
 Maintain system
 Small patches, repairs, and updates
 Enhance system
 Small upgrades or enhancements to expand system
capabilities
 Larger enhancements may require separate development
project
 Support users
 Help desk and/or support team
13
Methodologies and Models
 Methodologies
 Comprehensive guidelines to follow for completing every
SDLC activity
 Collection of models, tools, and techniques
 Models
 Representation of an important aspect of real world, but
not same as real thing
 Abstraction used to separate out aspect
 Diagrams and charts
 Project planning and budgeting aids
14
Tools and Techniques
 Tools
 Software support that helps create models or other
required project components
 Range from simple drawing programs to complex CASE
tools to project management software
 Techniques
 Collection of guidelines that help analysts complete a
system development activity or task
 Can be step-by-step instructions or just general advice
15
Two Approaches to System Development
 Traditional approach
 Also called structured system development
 Structured analysis and design technique (SADT)
 Includes information engineering (IE)
 Object-oriented approach
 Also called OOA, OOD, and OOP
 Views information system as collection of interacting
objects that work together to accomplish tasks
16
Object-Oriented Approach
 Completely different approach to information systems
 Views information system as collection of interacting
objects that work together to accomplish tasks
 Objects – things in computer system that can respond to
messages
 Conceptually, no processes, programs, data entities, or
files are defined – just objects
 OO languages: Java, C++, C# .NET, VB .NET
17
Object-Oriented Approach
 Object-oriented analysis (OOA)
 Defines types of objects users deal with
 Shows use cases are required to complete tasks
 Object-oriented design (OOD)
 Defines object types needed to communicate with people and
devices in system
 Shows how objects interact to complete tasks
 Refines each type of object for implementation with specific
language of environment
 Object-oriented programming (OOP)
 Writing statements in programming language to define what
each type of object does
18
Life Cycles with Different Names for Phases
19
Current Trends in Development
 The Unified Process (UP): Reinforces six best
practices(develop iteratively, define and manage
system requirements, use component architectures,
create visual models, verify quality, control changes)
 Extreme Programming (XP): Recent development
approach to keep process simple and efficient
 Agile Modeling: Hybrid of XP and UP
 Scrum: Respond to situation as rapidly as possible
20
Tools to Support System Development
 Computer-aided system engineering (CASE)
 Automated tools to improve the speed and quality of system
development work
 Contains database of information about system called
repository
 Upper CASE – support for analysis and design
 Lower CASE – support for implementation
 ICASE – integrated CASE tools
 Now called visual modeling tools, integrated application
development tools, and round-trip engineering tools
21
Q&A
Why Analyse Requirements?
 Use case model alone is not enough
 There may be repetition
 Some parts may already exist as standard components
 Analysis aims to identify:
 Common elements
 Pre-existing elements
 Interaction between different requirements
© Bennett,
McRobb and
Farmer 2005
23
What a Requirements Model Must Do
A requirements model meets two main needs:
 Confirms what users want a new system to do



Must be understandable for users
Must be correct and complete
Specifies what designers must design

Must be unambiguous
© Bennett,
McRobb and
Farmer 2005
24
What a Requirements Model Must Do
 Describes what the software should do
 Represents people, things and concepts important to
understand what is going on
 Shows connections and interactions among these
people, things and concepts
 Shows the business situation in enough detail to
evaluate possible designs
 Is organized so as to be useful for designing the
software
© Bennett,
McRobb and
Farmer 2005
25
How We Model the Analysis
 The main tool used for analysing requirements is the
class diagram
 Two main ways to produce this:
 Directly based on knowledge of the application domain
(a Domain Model)
 By producing a separate class diagram for each use case,
then assembling them into a single model (an Analysis
Class Model)
© Bennett,
McRobb and
Farmer 2005
26
Class Diagram: Stereotypes
 Analysis class stereotypes differentiate the roles
objects can play:
 Boundary objects model interaction between the system
and actors (and other systems)
 Entity objects represent information and behaviour in
the application domain
 Control objects co-ordinate and control other objects
© Bennett,
McRobb and
Farmer 2005
27
Class Diagram: Stereotypes
© Bennett,
McRobb and
Farmer 2005
28
Class Diagram: Stereotypes
© Bennett,
McRobb and
Farmer 2005
29
Class Diagram: Stereotypes
© Bennett,
McRobb and
Farmer 2005
30
Class Diagram: Class Symbol
© Bennett,
McRobb and
Farmer 2005
31
Class Diagram: Instance Symbol
Class Diagram: Attributes
Attributes are:
 Part of the essential description of a class
 The common structure of what the class can ‘know’
 Each object has its own value for each attribute in its
class
© Bennett,
McRobb and
Farmer 2005
33
Class Diagram: Links
Class Diagram: Associations
Associations represent:
 The possibility of a logical relationship or connection
between objects of one class and objects of another
 If two objects can be linked, their classes have an
association
© Bennett,
McRobb and
Farmer 2005
35
Class Diagram: Associations
© Bennett,
McRobb and
Farmer 2005
36
Class Diagram: Multiplicity
© Bennett,
McRobb and
Farmer 2005
37
Class Diagram: Operations
 Operations describe
what instances of a class
can do:
 Set or reveal attribute
values
 Perform calculations
 Send messages to other
objects
 Create or destroy links
© Bennett,
McRobb and
Farmer 2005
38
From Requirements to Classes
 Start with one use case
 Identify the likely classes involved (the use case
collaboration)
 Draw a collaboration diagram that fulfils the needs of
the use case
 Translate this collaboration into a class diagram
 Repeat for other use cases
© Bennett,
McRobb and
Farmer 2005
39
From Requirements to Classes
Sequence Diagrams
Jul-15
41
sd Add a new advert to a campaign if within budget
:CampaignManager
:Client
:Campaign
:Advert
getName
listCampaigns
ref
List client campaigns
ref
Get campaign budget
addCostedAdvert
alt
[totalCost <= budget]
ref
Create advert
[else]
ref
42
Create request
Interaction Fragment Used
sd Get campaign budget
:CampaignManager
:Campaign
:Advert
checkCampaignBudget
loop
[For all campaign’s adverts]
getCost
getOverheads
Simple activity diagram
Create new
StaffGrade
Link to
CreativeStaff
Link to previous
StaffGrade
Set previous
StaffGrade
gradeFinishDate
An activity diagram show the main steps for the operation
Activity Diagram with Selection and Iteration
Calculate bonus
Create
warning
letter
[bonus < £25]
[bonus > £250]
Add to ‘star’ list
[bonus >= £25 AND
bonus <= £250]
Add to list
[more StaffMembers]
[no more StaffMembers]
Format list
System Design and Detailed Design
 System design deals with the high level architecture of
the system
 structure of sub-systems
 distribution of sub-systems on processors
 communication between sub-systems
 standards for screens, reports, help etc.
 job design for the people who will use the system
© Bennett,
McRobb and
Farmer 2005
46
System Design and Detailed Design
 Object-oriented detailed design adds detail to the
analysis model
 types of attributes
 operation signatures
 assigning responsibilities as operations
 additional classes to handle user interface
 additional classes to handle data management
 design of reusable components
 assigning classes to packages
© Bennett,
McRobb and
Farmer 2005
47
Qualities of Analysis
 Correct scope—everything in the system is required
 Completeness—everything required is in the system
and everything is documented in the models
 Correct content—accurate description of requirements
 Consistency—each element is consistently referred to
by the same name
© Bennett,
McRobb and
Farmer 2005
48
Qualities of Design
 Functional—system will perform the functions that it
is required to
 Efficient—the system performs those functions
efficiently in terms of time and resources
 Economical—running costs of system will not be
unnecessarily high
 Reliable—not prone to hardware or software failure,
will deliver the functionality when the users want it
© Bennett,
McRobb and
Farmer 2005
49
Qualities of Design
 Secure—protected against errors, attacks and loss of
valuable data
 Flexible—capable of being adapted to new uses, to run
in different countries or to be moved to a different
platform
 General—general-purpose and portable (mainly
applies to utility programs)
 Buildable—Design is not too complex for the
developers to be able to implement it
© Bennett,
McRobb and
Farmer 2005
50
Qualities of Design
 Manageable—easy to estimate work involved and to
check of progress
 Maintainable—design makes it possible for the
maintenance programmer to understand the
designer’s intention
 Usable—provides users with a satisfying experience
(not a source of dissatisfaction)
 Reusable—elements of the system can be reused in
other systems
© Bennett,
McRobb and
Farmer 2005
51
Q&A
http://staruml.en.softonic.com/