introduce to system analysis and design

1. T O P I C 1
I N T R O D U C T I O N T
O I N F O R M A T I O N
S Y S T E M S
A N A L Y S I S A N D
D E S I G N
A N A L I S I S D A N P E R A N C A N G A N S I S T E M I N F O R M A S I
C S I M 6 0 3 1 8 3

2. Learning Objectives
1. Able to elaborate what computer-based information
systems is.
2. Able to e
xplain the system development lifecycle (SDLC)
principlesandthedeliverablesfor eachphase.
3. Able to explain the evolution of information
systems development methodology.
4. Able to elaborate the role of each member in IS project
team.
5. Able to elaborate the characteristics of OO Systems and
OO Systems Design and Analysis.
6. Abletoelaboratethecomponentof UML Diagram

3. 1. Computer-basedInformation Systems
2. ThePrincipleof InformationSystemsDevelopmentLifecycle
(SDLC)andtheRoleof SystemAnalyst
3. ISDevelopmentMethodology
4. BuildingT
eaminISDevelopmentProject
Session Outline

4. 1 . 1
C O M P U T E R -
B A S E D
I N F O R M A T I O N
S Y S T E M S A N D
T H E R O L E O F
S Y S T E M
A N A L Y S T

5. What are the characteristics of
Information Systems?

6. • Information System is a set of interrelated elements or components
that collect (input), manipulate (process), and disseminate (output) data
and information and provide a feedback mechanism to meet an
objective.
– Whataretheelements?People, Data, Processes and Procedures, Technology,
Tools, etc.
– Whatobjective(s)needtobeachieve?Organization objectives
• WefocusonComputer-basedInformation System.
– By definition,InformationSystem isnot necessarily needs computer
.
– It’sacomputerapplicationtoperform acertaintasks.
What is Computer Based Information
Systems?

7. BusinessIntelligenceSystems
IntegratedInformationSystems: ERP
StandaloneInformation System
Manual
CloudComputing,BigData,andMobileTechnology
havechangedtheutilizationof IT Services.
Information Systems Evolution

8. Information Systems Evolution
Era Information System Data Processing
1960 TransactionProcessingSystem Automaterepeatingactivity
1970 ManagementInformation System Recapweekly,monthly,etc.
functional data
1980 StrategicInformationSystem ProcessExternalandInternaldata
1990 B. usiness,
C. ommerce,e-Gov.
ProcessMulti-stakeholderOnline
Data
2000 EnterpriseResource Planning IntegrateFunctional Data
2006 BusinessIntelligent ProcessTemporalandSpatialData
becomeBig Data

9. What are the differences among
Transaction Processing Systems,
Management Information Systems, and
Strategic IS

10. Basic Type ofIS

11. HRD FINANCE …… Functions
ERP
Business
Intelligence
IS
Basic Type ofIS

12. HRD FINANCE …… Functions
Basic Type ofIS
ASetof T
ables
ASetof Graphics
75%
Dashboard

13. 1 . 2
T H E S Y S T E M S
D E V E L O P M E N T
L I F E C Y C L E
( S D L C )

14. (Information) Systems Development
Lifecycle: SDLC
• The process of understanding how an information system (IS)
can support business needs by designing a system, building
it,anddeliveringitto users.
• Soundspretty simple…
•Isit?…

15. What are the importance of SDLC?

16. The Importance of SDLC
the full
• TheStandishGroup(1996)
– 42% w
ere abandoned
before completion
• GeneralAccountingOffice(1996)
– 53% all US Government IS projects
wereabandoned
– Many of the remaining w
ere
delivered very late, over budget,
fewerfeaturesthanplanned.
• IAGConsulting
– 80%wereovertime
– 72%wereoverbudget
– 55% delivered less than
functionality
• PanoramaConsultingSolutions
– 54%ERPprojectswereovertime
– 56%wereoverbudget
– 48%deliveredlessthan50%of full
functionality
• IBM
– 59%projectsmissedoneormoreof
on time, within budget and
quality constraints.

17. Key Person in SDLC
System Analyst
Createwonderfulsystem?

19. Key Issues
• Many failed systems wereabandoned because analysts tried to build
wonderful systems without understanding how the system would
fit with the organization’s goals
• Theprimarilygoal of informationsystemistocreate value for the
organization profit for mostorganization/company

20. Key Issues: What should system analyst do?
To Create Value for the Organization!!!
1. Analyze business situation
2. Identify opportunities for improvements
3. Design an IS to implement them

21. Key Issues
• The systems analyst is a key person analyzing the business,
identifying opportunities for improvement, and designing
informationsystemstoimplementthese ideas.
• It is important to understand and develop through practice the skills
needed to successfully design and implement new information
systems.

23. Programmer Users,Clients
Programmer Users,Clients
SystemAnalyst
Programmer Users,Clients
T
echnicalAnalyst BusinessAnalyst
SystemAnalyst
1970-an
1980-an
2000-an
The Changing Roles of System Analyst

24. Building Information Systems
• BuildingISissimilartobuild ahouse
– Startswithbasicidea
– T
ransformed into a simple drawing and shown to customer and refined until
customeragree
– Asetof blueprintis designed
– Thehouseisbuiltfollowingtheblueprint
• InIS,itiscalledSystemDevelopmentLifeCycle(SDLC)whichhasa similar
of 4-fundamental phases (Planning, Analysis, Design and
Implementation)
• Each phases is composed of a series of steps, which rely upon
techniques that produce deliverables (specific documents and files
thatprovideunderstandingaboutthe project)

25. Information Systems Development Lifecycle
• In many project, SDLC phases and steps proceed in a logical
path from start to finish, while in other project, the project
teams move through the steps consecutively
, incrementally
,
iteratively
,or inother pattern.
• SLDC is a gradual refinement (each phase refines and
elaborateson theworkdonepreviously)
– Deliverablesproducedintheanalysisphaseprovideageneralidea of
theshapeof thenew system
– Theseareusedasinputtothedesignphasewhichthenrefines them
toproduceasetof moredetailed deliverables.
– Thesedeliverables,inturn,areusedintheimplementationphaseto
producetheactualsystem.

26. Analyze for each phase of SDLC steps and
how they are related each other!

27. Phases of SDLC
• Planning
– Whybuildthe system?
– Howtheprojectteamwillgo tobuild it?
• Analysis
– Who,what,when,wherewillthesystembe?
• Design
– Howwillthesystemwilloperate,intermsof thehardware,softwareand
infrastructure?
• Implementation
– Thesystemisactuallybuiltor purchased
– Systemdelivery

28. #1 Planning
• ProjectInitiation
– Identifybusinessvalue(howwilltheISlowercostsor increase
revenue?)
• Asystemrequestpresentsabrief summaryof businessneed,andexplainhowthesystem will
createbusinessvalue
– Analyzefeasibility(technical,economicandorganizational)
• ProjectManagement
– Developwork plan
– Staffthe project
– Controlanddirect project

29. #2 Analysis
• AnalysisStrategy
– Analyzecurrentsystem(as-issystem)andnewsystem(to-be
system)
• Requirement gathering
– Interviewor questionnairesor othermethod
– AnalysisModel (ProcessandData)
• SystemProposal
– Describewhatbusinessrequirementsof thenewsystemshould
met.

30. #3 Design
• Design Strategy
– Buildit,outsourceor buy ?
• Architectural& Interface Design
– Describeh/w,s/w,networkinfrastructure
– Howtheuserswillmovethrough thesystem
• Databaseandfilespecification
• Program design

31. #4 Implementation
• SystemConstruction
– Thesystemisbuiltandtestedtomakesureitperformsasdesigned.
• Installation
– Preparetosupporttheinstalled system.
• Support Plan
– Includesapost-implementation review
.

32. Process Product
Planning
Analysis
Design
Implementation
Project Plan
System Proposal
System
Specification
New System and
Maintenance Plan
Processes andDeliverables

33. 33
Tim
e
Plan Analysis Design
Phases/Stages
Implementation
ANAPERANCIS
SDLC Effort Allocation

34. Basic Information Systems Development
Project Life Cycle
Project Charter (System Request)
Project Proposal
System Proposal (Logical IS)
System Specification (Physical IS)
PHASES
ProjectInitiation
ProjectManagement Plan
ProjectExecution:Requirement
Analysis
InformationSystemsDesign
DELIVERABLES
Accept
Rejec
t
Accept
Rejec
t
SystemImplementation Working Information Systems
Rejec
t
Rejec
t
Accept
Accept

35. 1 . 3
I S
D E V E L O P M E N T
M E T H O D O L O G Y

36. What is methodology?
• Aformalizedapproachor seriesofsteps
• A methodology isaformalizedapproachtoimplementing
the SDLC.
– The methodology will vary depending on whether the
emphasis is on businesses processes or on the data that
supportsthe business.
Writing code without a well-thought-out system request may
work for small programs, but rarely works for large ones.

37. SDLC methodology categorization
• Methodology thatfocusesonbusinessprocessor datathatsupport
the business
– Process-centered methodology
– Datamethodology
– Object-oriented methodology
• Methodology thatfocusesonthesequencingof SDLCphasesandthe
amountof timeand effort.
– StructuredDevelopment
– RapidApplication Development
– Agile Development

38. Process-Centered Methodology
• With this methodology
, the focus is on defining the
activities associatedwiththesystem.
• Theconcentrationison representingthesystemconceptas a
set of processes with information flowing into and out
of the processes.

39. Data-Centered Methodology
• This methodology focuses on defining the content of the
data storagecontainersandhowtheyareorganized.
• Data-centered methodologies utilize data models as the
core of the system concept.

40. Object Oriented Methodology
• Attemptstobalanceemphasisondataandprocess
• UsesUnifiedModeling Language(UML)for diagramming

41. Compare and contrast Structured
Development,
Rapid Application Development, and
Agile Development methodology

42. Type of Systems Development Methodology
• StructuredDesign
– Waterfall
– Parallel
• RapidApplicationDevelopment(RAD)
– PhasedDevelopment
– Prototyping
– Throw-AwayPrototyping
• Agile Development
– ExtremeProgramming
– Scrum

43. Structured Design
• Projects move methodically from one to the next step
• Generally, a step is finished before the next one begins
• Thisdesignmethodologyintroducestheuseof formal
modelingor diagrammingtechniquestodescribea
system’sbasicbusinessprocessesandfollowsabasic
approachof twostructureddesign categories.
Structured Design
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

44. Structured Design: Waterfall
Structured Design
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum
Withwaterfalldevelopment- basedmethodologies,theanalysts
andusersproceedsequentiallyfromonephasetothe next.

45. Structured Design: Waterfall
Structured Design
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum
• Advantages:
– The system requirements are identified long before
programming begins.
– Changestotherequirementsareminimizedastheproject
proceeds.
• Disadvantages:
– Thelengthof keydeliverables
– Highesttimegapbetweenanalysisandthedeliveryof the
system
– Highpostimplementationeffortfor amissedrequirement
– Significantreworkastheconsequencesof business
environment changes

46. Structured Design: Parallel
Structured Design
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum
• Thismethodologyattemptstoaddressthelong timeinterval
betweentheanalysisphaseandthedeliveryof the system
• Ageneraldesignfor theentiresystemisperformedandthen the
projectisdividedintoaseriesof distinctsubprojects.
• Advantage:
– Reducetimedelivery
– Lesschangesinthebusinessenvironmentcausingrework
• Disadvantage:
– Interdependency of subprojects  significant
integration
efforts

47. Structured Design: Parallel
Structured Design
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

48. Rapid Application Development(RAD)
• RAD-based methodologies adjust the SDLC phases to
getsomepartof systemdevelopedquicklyandinto the
handsof theusers.
• Most RAD-based methodologies recommend that
analysts use special techniques and computer tools to
speeduptheanalysis,design,and implementation
phases,suchasCASE(computer-aided software
engineering) tools.
– CASEtools
– JADsessions
– Fourth generation/visualization programming
languages
– Codegenerators
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

49. Rapid Application Development(RAD)
• OnepossiblesubtleproblemwithRAD-based
methodologiesismanaginguserexpectations.
• RADCategories:
– Phaseddevelopment
• Aseriesof versions
– Prototyping
• Systemprototyping
– Throw-away prototyping
• Design prototyping
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

50. RAD: Phased Development
• This methodology breaks the overall system into a
seriesof versionsthataredevelopedsequentially
.
• The team categorizes the requirements into a series of
versions, then the most important and fundamental
requirements are bundled into the first version of the
system.
• The analysis phase then leads into design
and
the set of
implementation; howe
ver
, only
with requirements
identifiedfor version 1.
• Aseachversioniscompleted,theteambeginsworkon
anewversion.
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

51. RAD: Phased Development
• Advantage:
– The users quic
kly use the system, although it does not
perform allthefunctionstheusers need
• Disadvantage:
– The users begin to work with systems that intentionally
incomplete  critical to define the priority of u
s
e
r
requirements
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

52. RAD: Phased Development
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

53. RAD: Prototyping
methodologies perform the
and implementation phases
• Prototyping-
based analysis,
design
concurrently
.
• Allthreephasesareperformedrepeatedlyinacycle
untilthesystemiscompleted.
• Aprototypeisasmallerversionof thesystemwitha
minimalamountof features.
• Quickanddirtyprogram providesminimala
m
o
u
n
t
of features
• Fitsfor userswithunknownrequirements
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

54. RAD: Prototyping
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

55. RAD: Prototyping
• Advantage
– Quicklyprovideasystemfor theuserstointeract
with,evenif itisnotinitiallyreadyfor use.
– Helptomorequicklyrefinereal requirements
• Disadvantage
– Oftentheprototypeundergoessuchsignificant
changesthatmanyinitialdesigndecisionsproveto
bepoor ones.
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

56. RAD: Throw-Away Prototyping
• Throw-awayprototypingmethodologiesaresimilarto
prototypingbased methodologies.
• Themaindifferenceisthatthrowaway prototyping IS
completed during a different point in the SDLC.
• Hasrelativelythoroughanalysis phase.
• Designprototypeisnotworking systems
• Fitfor userswhoarenotcompletelyclearonhowthe
systemswork
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

57. RAD: Throw-Away Prototyping
to minimize the risk
• Advantages
– Each prototype is used
associatedwiththesystem
– Important issues are understood before the
real systemisbuilt
– Producemorestableandreliable systems
• Disadvantages:
– T
a
k
elongerdeliverytimecomparetoprototyping-based
methodologies
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

58. RAD: Throw-Away Prototyping
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile Development
Extreme
Programming
Scrum

59. Agile Development
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile
Development
Extreme
Programming
Scrum
• ThiscategoryfocusesonstreamliningtheSDLC
byeliminatingmuchof themodelingand
documentationoverheadandthetimespenton
thosetasks.
• Projectsemphasizesimple,iterativeapplication
development.
• Thiscategoryusesextremeprogramming,which
isdescribednext.

60. Agile Development
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile
Development
Extreme
Programming
Scrum
Typical agile development methodology

61. Agile Development: Extreme Programming
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile
Development
Extreme
Programming
Scrum
• ExtremeProgramming(XP)wasfoundedon fourcore
values:
– Communication
– Simplicity
– Feedback
– Courage
• All programming is done in pairs, a shared responsibility
for each soft ware component develops among the
programmers.
• K
eyprinciplesof XPinclude:
– Continuous testing
– Simplecoding
– Closeinteractionwiththeenduserstobuildsystemsveryquickly

62. Agile Development: Scrum
StructuredDesign
Waterfall
Parallel
Rapid Application
Development
(RAD)
Phased
Development
Prototyping
Throw-
Away
Prototyping
Agile
Development
Extreme
Programming
Scrum
• Scrum is the most chaotic of all systems development
approaches
• T
eamsareself-organizedandself-directed.
• Unlike other approaches, Scrum teams do not have a
designated team leader
. Instead, teams organize
themselvesinasymbioticmannerandsettheir own goals
for eachsprint (iteration).
• The team members attend the scrum meetings,
but anyonecan attend.

63. Selecting Methodology
is not simple, as no one
• Selecting a methodology
methodology isalwaysbest.
• Manyorganizationshavetheirown standards.

64. What is the best methodology in SDLC?
What are the criterias for choosing the
appropriate methodology?

65. Selecting Methodology
1. Clarityof User Requirements
2. FamiliaritywithTechnology
3. SystemComplexity
4. SystemReliability
5. ShortTime Schedules
6. Schedule Visibility

66. Selecting Methodology

67. Criterion 1: Clarity of User Requirements
RAD methodologies of prototyping and throwaway
prototyping are usually more appropriate when user
requirements are unclear as they provide prototypes for users
tointeractwithearlyintheSDLC.

68. Criterion 2: Familiarity with Technology
If thesystemisdesignedwithoutsomefamiliaritywith the base
technology
,risksincreasebecausethetoolsmaynotbe capable
of doing whatisneeded.

69. Criterion 3: System Complexity
• Complex systems require careful and detailed analysis and
design.
• Project teams who follow phased development-based
methodologies tend to devote less attention to the analysis
of the complete problem domain than they might if they
wereusingother methodologies.

70. Criterion 4: System Reliability
• Systemreliabilityisusuallyanimportantfactorinsystem
development.
• Throwaw
ay prototyping-based methodologies are
most appropriatewhensystemreliabilityisa
highpriority
.
• Prototyping-basedmethodologiesaregenerallynotagood
choiceastheylackcarefulanalysisanddesignphases.

71. Criterion 5: Short Time Schedules
• RAD-based methodologies are well suited for projects with
shorttimeschedulesastheyincrease speed.
• Waterfall-based methodologies are the worst choice when
time is essential as they do not allow for easy schedule
changes.

72. Criterion 6: Schedule Visibility
RAD-based methodologies move many of the critical design
decisions earlier in the project; consequently
, this helps project
managers recognize and address risk factors and keep
expectations high.

73. 1 . 4
B U I L D I N G
T E A M I N I S
D E V E L O P M E N T
P R O J E C T

74. Project Team Skills and Roles
• Projectsshouldconsistof avarietyof skilledindividualsin
orderfor asystemtobesuccessful.
• Sixmajorskillsetsananalystshouldhaveinclude:
– T
echnical
– Business
– Analytical
– Interpersonal
– Management
– Ethical

75. Categories of Analysts
• Businessanalyst
• Systemanalyst
• Infrastructureanalyst
• Changemanagement analyst
• Projectmanager

76. Project TeamRoles

77. 1 . 5
B A S I C
C H A R A C T E R I S T
I C S O F O - O
S Y S T E M S

78. Characteristics of OO Systems
Object-oriented systems focus on capturing the structure and
behavior of information systems in little modules that encompass
both dataand process.
Familiar Terms
1. ClassesandObjects
2. Methodsand Messages
3. EncapsulationandInformation Hiding
4. Inheritance
5. PolymorphismandDynamic Binding

79. Characteristics of OO Systems
1. Classesand Objects
– Aclassisthegeneraltemplateweusetodefineandcreatespecificinstances,or objects.
– Anobjectisaninstantiationof aclass.
– Eachobjecthasattributesthatdescribeinformationabouttheobject
– Eachobjectalsohasbehaviors,thatspecifywhattheobjectcando.
2. Methods and Messages
– Methodsimplementanobject’sbehavior.
– Amethodisnothingmorethananactionthatanobject canperform.
– Messagesareinformationsenttoobjectstotriggermethods.
– Amessageisessentiallyafunctionor procedurecallfromoneobjecttoanother
object.

80. Characteristics of OO Systems
3. Encapsulation and Information Hiding
– Encapsulationissimplythecombinationof processanddataintoa
single entity
.
– Theprincipleof informationhidingsuggeststhatonlythe
informationrequiredtouseasoftwaremodulebepublishedtothe
userof themodule.
– Wereallydo notcarehowtheobjectperformsitsfunctions,as
long asthefunctions occur
.
– Inobject-orientedsystems,combiningencapsulationwiththe
information-hidingprinciplesupportstreatingobjectsasblack
boxes.

81. Characteristics of OO Systems
4. Inheritance
– using inheritance to identify higher-level, or more general, classes
of objects.
5. Polymorphism and Dynamic Binding
– Polymorphism means that the same message can be interpreted
differentlybydifferentclassesof objects.
– Polymorphism is made possible through dynamic binding.
Dynamic, or late, binding is a technique that delays typing the
object until run-time. Thespecific method that is actually called is
not chosen by the object-oriented system until the system is
running.

82. Characteristics of OO Systems Analysis and
Design
The primary difference between a traditional approach like structured
design and an object-oriented approach is how a problem is
decomposed.
– In traditional approaches, the problem-decomposition process is either
process-centricor data-centric.
– However
,processesanddataaresocloselyrelatedthatitisdifficultto pick
oneor theotherastheprimary focus.
– Based on this lack of congruence with the real world, new object-
orientedmethodologies haveemergedthatusetheRAD-based sequence
of SDLCphasesbutattempttobalancetheemphasisbetween processand
data by focusing the decomposition of problems on objects that contain
bothdataandprocesses.

83. Characteristics of OO Systems Analysis and
Design
1. Use-Case Driven
– Use cases are the primary modeling tools defining the behavior of the
system.
– A use casedescribes how the user interacts with the system to perform
some activity
, such as placing an order, making a reservation, or
searchingforinformation.
– Theusecasesareusedtoidentifyandtocommunicatethe requirements
for thesystemtotheprogrammerswhomustwritethe system.
– Usecasesareinherentlysimplebecausetheyfocusononlyone business
processata time.

84. Characteristics of OO Systems Analysis and
Design
1. Use-Case Driven
– In contrast, the process model diagrams used by traditional structured
andRADmethodologies arefar morecomplexbecausetheyrequire the
systemsanalystandusertodevelopmodelsof theentiresystem.
– Withtraditionalmethodologies,eachsystemisdecomposedintoaset of
subsystems, which are, in turn, decomposed into further subsystems,
andso on.
– Thisgoesonuntilnofurtherprocessdecompositionmak
essense,and it
often requires dozens of pages of interlocking diagrams. In contrast, a
use casefocuses on only one business process at a time, so developing
modelsismuchsimpler
.

85. Characteristics of OO Systems Analysis and
Design
2. Architecture-Centric
– Any modern approach to systems analysis and design should
be architecture-centric.
– Architecture-centric means that the underlying software
architecture of the evolving system specification drives the
specification,construction,anddocumentationof the system.

86. Characteristics of OO Systems Analysis and
Design
2. Architecture-Centric
– Modern object-oriented systems analysis and design approaches should
support at least three separate but interrelated architectural views of a
system:functional,static,anddynamic.
a) The functional, or external, view describes the behavior of the
systemfromtheperspectiveof the user
.
b) The structural, or static, view desc
ribes the system in term
s of
attributes,methods,classes,and relationships.
c) The behavioral, or dynamic, view describes the behavior of the
systemintermsof messagespassedamongobjectsandstate changes
withinanobject.

87. Characteristics of OO Systems Analysis and
Design
3. Iterative and Incremental
 Modern object-oriented systems analysis and design approaches
emphasize iterative and incremental development that undergoes
continuoustesting and refinementthroughout the life of the project.
 Thisimpliesthatthesystemsanalystsdeveloptheirunderstandingof a
user’s problem by building up the threearchitecturalviewslittle by little.
 The systems analyst does this by working with the user to create a
functionalrepresentationof thesystemunder study
.
 Next, the analyst attempts to build a structural representation of the
evolving system.

88. Characteristics of OO Systems Analysis and
Design
3. Iterative and Incremental
 Using the structural representation of the system, the analyst distributes
the functionality of the system over the evolving structure to create a
behavioralrepresentationof theevolving system.
 As an analyst works with the user in developing the three architectural
views of the evolving system, the analyst iterates over each of and among
the views.
 That is, as the analyst better understands the structural and behavioral
views, the analyst uncovers missing requirements or misrepresentations in
the functional view
. This, in turn, can cause changes to be cascaded back
throughthestructuralandbehavioralviews.

89. 1 . 6
U M L

90. Characteristics of OO Systems Analysis and
Design
• Until 1995, object concepts were popular but implemented in many
different ways by different developers. Each developer had his or her
ownmethodologyandnotation(e.g., Booch,Coad,Moses,OMT
, OOSE,
SOMA).23 Then in 1995, Rational Software brought three industry
leaders together to create a single approach to object- oriented
systems development.
• The objective of UML wastoprovideacommonvocabularyof object-
orientedtermsanddiagrammingtechniquesrichenoughto modelany
systemsdevelopmentprojectfromanalysisthrough implementation.

91. UML Diagram
1. Structure diagrams
– provideawaytorepresentthedataandstaticrelationshipsinaninformationsystem.
– the structure diagram
s include c
lass, object, pac
kage, deployment, component,
compositestructure,andprofile diagrams.
2. Behavior diagrams
– providetheanalystwithawaytodepictthedynamicrelationshipsamongtheinstances or
objectsthatrepresentthebusinessinformation system.
– theyalsoallowmodelingof thedynamicbehaviorof individualobjectsthroughouttheir
lifetime.
– thebehaviordiagramssupporttheanalystinmodelingthefunctionalrequirementsof an
evolvinginformation system.
– thebehaviormodelingdiagramsincludeactivity
,sequence,communication,interaction
overview
,timing,behaviorstatemachine,protocolstatemachine,anduse-case diagrams.

92. UML Diagram

93. S U M M A R Y

94. Summary
• Basic type of computer-based information systems consist of
Transaction Processing System, Management Information System,
and Strategic Information System, which process data and
informationfor differenttypeof users.
• The development of information systems have to consider the
technological development, such as cloud computing, big data, and
alsomobiletechnology
.
• The primarily goal of information system is to create value for the
organization.
• SDLChelps team member to understand how an information system
(IS) can support and enable business needs by designing a system,
building it,anddeliveringitto users.

95. Summary
• SDLC consists of 4-fundamental phases (Planning, Analysis, Design and
Implementation), which each phase refines and elaborates on the work done
previously).
• The systems analyst is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to
implementthese ideas.
• SDLCmethodology thatfocuseson businessprocessor datathatsupport the
business consists of process-centered methodology, data methodology,
and object-oriented methodology
• SDLC methodology that focuses on the sequencing of SDLC phases and the
amount of time and effort consists of Structured Development, Rapid
Application Development, and Agile Development

96. Summary
• Criterias for selecting SDLC methodology: clarity of user
requirements, familiarity with technology, system complexity,
system reliability, short time schedules, schedule visibility

97. References
1. SystemsAnalysisandDesign:AnObjectOrientedApproachwith UML
5thed.AlanDennis,BarbaraHaleyWixom,andRobertaM. Roth
© 2015– Chapter1
2. http://emojipedia.org/whatsapp/
3. Forcompletedescriptionof UML see:
4. www
.rational.com/uml