Asst.Prof. Dr. Surasak Mungsing. 3 Learning Objectives Explain the purpose and various phases of the...
-
Upload
lora-preston -
Category
Documents
-
view
218 -
download
1
Transcript of Asst.Prof. Dr. Surasak Mungsing. 3 Learning Objectives Explain the purpose and various phases of the...
Asst.Prof. Dr. Surasak Mungsing
3
Learning ObjectivesLearning ObjectivesExplain 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
4
The Systems Development Lifecycle (SDLC)The Systems Development Lifecycle (SDLC)Systems development life cycle (SDLC)
Provides overall framework for managing systems development process
Two main approaches to SDLCPredictive approach – assumes project can be
planned out in advanceAdaptive approach – more flexible, assumes
project cannot be planned out in advanceAll projects use some variation of SDLC
5
Traditional Predictive Approach to the SDLCTraditional Predictive Approach to the SDLC
Project planning – initiate, ensure feasibility, plan schedule, 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
6
““Waterfall” Approach to the SDLCWaterfall” Approach to the SDLC
7
Modified Waterfall ApproachModified Waterfall Approachwith Overlapping Phaseswith Overlapping Phases
8
Newer Adaptive Approaches to the SDLCNewer Adaptive Approaches to the SDLC
Based on spiral modelProject 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 resultApproach assumes no
one gets it right the first time
There are a series of mini projects for each iteration
9
Activities of Planning Phase of SDLCActivities of Planning Phase of SDLCDefine 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
10
Activities of Analysis Phase of SDLCActivities of Analysis Phase of SDLCGather information to learn problem domain
Define system requirements
Build prototypes for discovery of requirements
Prioritize requirements
Generate and evaluate alternatives
Review recommendations with management
11
Activities of Design Phase of SDLCActivities of Design Phase of SDLCDesign 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
12
Activities of Implementation Phase of SDLCActivities of Implementation Phase of SDLCConstruct software components
Verify and test
Convert data
Train users and document the system
Install the system
13
Activities of Support Phase of SDLCActivities of Support Phase of SDLCMaintain system
Small patches, repairs, and updatesEnhance system
Small upgrades or enhancements to expand system capabilities
Larger enhancements may require separate development project
Support usersHelp desk and/or support team
14
Methodologies and ModelsMethodologies and ModelsMethodologies
Comprehensive guidelines to follow for completing every SDLC activity
Collection of models, tools, and techniquesModels
Representation of an important aspect of real world, but not same as real thing
Abstraction used to separate out aspectDiagrams and chartsProject planning and budgeting aids
15
Tools and TechniquesTools and TechniquesTools
Software support that helps create models or other required project components
Range from simple drawing programs to complex CASE tools to project management software
TechniquesCollection of guidelines that help analysts
complete a system development activity or taskCan be step-by-step instructions or just general
advice
16
Two Approaches to System DevelopmentTwo Approaches to System DevelopmentTraditional approach
Also called structured system developmentStructured analysis and design technique
(SADT)Includes information engineering (IE)
Object-oriented approachAlso called OOA, OOD, and OOPViews information system as collection of
interacting objects that work together to accomplish tasks
17
Object-Oriented ApproachObject-Oriented ApproachCompletely different approach to information
systemsViews information system as collection of
interacting objects that work together to accomplish tasksObjects – things in computer system that can
respond to messagesConceptually, no processes, programs, data
entities, or files are defined – just objectsOO languages: Java, C++, C# .NET, VB .NET
18
Object-Oriented ApproachObject-Oriented ApproachObject-oriented analysis (OOA)
Defines types of objects users deal withShows use cases are required to complete tasks
Object-oriented design (OOD)Defines object types needed to communicate with
people and devices in systemShows how objects interact to complete tasksRefines each type of object for implementation with
specific language of environmentObject-oriented programming (OOP)
Writing statements in programming language to define what each type of object does
19
Life Cycles with Different Names for PhasesLife Cycles with Different Names for Phases
20
Current Trends in DevelopmentCurrent Trends in DevelopmentThe 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
21
Tools to Support System DevelopmentTools to Support System DevelopmentComputer-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
Q&AQ&A
© Bennett, McRobb and Farmer 2005 23
Why Analyse Requirements? Why Analyse Requirements? Use case model alone is not enoughUse case model alone is not enough
There may be repetitionSome parts may already exist as standard
componentsAnalysis aims to identify: Analysis aims to identify:
Common elementsPre-existing elementsInteraction between different requirements
© Bennett, McRobb and Farmer 2005 24
What a Requirements Model Must DoWhat a Requirements Model Must Do
A requirements model meets two main needs:A requirements model meets two main needs: Confirms what users want a new system to Confirms what users want a new system to
dodo Must be understandable for users Must be correct and complete
Specifies what designers must designSpecifies what designers must design Must be unambiguous
© Bennett, McRobb and Farmer 2005 25
What a Requirements Model Must DoWhat a Requirements Model Must Do
Describes what the software should doRepresents people, things and concepts
important to understand what is going onShows connections and interactions among
these people, things and conceptsShows the business situation in enough detail
to evaluate possible designsIs organized so as to be useful for designing
the software
© Bennett, McRobb and Farmer 2005 26
How We Model the AnalysisHow We Model the AnalysisThe main tool used for analysing
requirements is the class diagramTwo 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 27
Class Diagram: StereotypesClass Diagram: StereotypesAnalysis 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 domainControl objects co-ordinate and control other
objects
© Bennett, McRobb and Farmer 2005 28
Class Diagram: StereotypesClass Diagram: Stereotypes
© Bennett, McRobb and Farmer 2005 29
Class Diagram: Stereotypes
© Bennett, McRobb and Farmer 2005 30
Class Diagram: StereotypesClass Diagram: Stereotypes
© Bennett, McRobb and Farmer 2005 31
Class Diagram: Class SymbolClass Diagram: Class Symbol
Class Diagram: Instance Symbol
© Bennett, McRobb and Farmer 2005 33
Class Diagram: AttributesClass Diagram: Attributes
Attributes are:Attributes are:Part of the essential description of a classThe common structure of what the class can
‘know’Each object has its own value for each
attribute in its class
Class Diagram: LinksClass Diagram: Links
© Bennett, McRobb and Farmer 2005 35
Class Diagram: AssociationsClass Diagram: Associations
Associations represent: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 36
Class Diagram: AssociationsClass Diagram: Associations
© Bennett, McRobb and Farmer 2005 37
Class Diagram: MultiplicityClass Diagram: Multiplicity
© Bennett, McRobb and Farmer 2005 38
Class Diagram: OperationsClass Diagram: Operations
Operations describe what instances of a class can do:Set or reveal
attribute valuesPerform calculationsSend messages to
other objectsCreate or destroy
links
© Bennett, McRobb and Farmer 2005 39
From Requirements to ClassesFrom Requirements to ClassesStart with one use caseIdentify the likely classes involved (the use
case collaboration)Draw a collaboration diagram that fulfils the
needs of the use caseTranslate this collaboration into a class
diagramRepeat for other use cases
From Requirements to ClassesFrom Requirements to Classes
Sequence Diagrams
04/19/23 41
42
:Client :Campaign :Advert
getName
listCampaigns ref
:CampaignManager
alt
[else]
sd Add a new advert to a campaign if within budget
List client campaigns
[totalCost <= budget]
refCreate advert
Create requestref
ref
Get campaign budget
addCostedAdvert
Interaction Fragment UsedInteraction Fragment Used
:Campaign :Advert
getCost
sd Get campaign budget
loop
getOverheads
checkCampaignBudget
:CampaignManager
[For all campaign’s adverts]
Simple activity diagramSimple activity diagram
Link to
CreativeStaff Create new StaffGrade
Link to previous StaffGrade
Set previous StaffGrade
gradeFinishDate
An activity diagram show the main steps for the operation
Activity Diagram with Selection and Activity Diagram with Selection and IterationIteration
Calculate bonus
[bonus > £250]
Add to list
[more StaffMembers]
Format list
[no more StaffMembers]
Add to ‘star’ listCreate warning
letter
[bonus < £25]
[bonus >= £25 ANDbonus <= £250]
© Bennett, McRobb and Farmer 2005 46
System Design and Detailed DesignSystem Design and Detailed DesignSystem design deals with the high level
architecture of the systemstructure of sub-systemsdistribution of sub-systems on processorscommunication between sub-systemsstandards for screens, reports, help etc.job design for the people who will use the
system
© Bennett, McRobb and Farmer 2005 47
System Design and Detailed DesignSystem Design and Detailed DesignObject-oriented detailed design adds detail to
the analysis modeltypes of attributesoperation signaturesassigning responsibilities as operationsadditional classes to handle user interfaceadditional classes to handle data managementdesign of reusable componentsassigning classes to packages
© Bennett, McRobb and Farmer 2005 48
Qualities of AnalysisQualities of AnalysisCorrect scope—everything in the system is
requiredCompleteness—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 49
Qualities of DesignQualities of DesignFunctional—system will perform the
functions that it is required toEfficient—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 50
Qualities of DesignQualities of DesignSecure—protected against errors, attacks
and loss of valuable dataFlexible—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 51
Qualities of DesignQualities of DesignManageable—easy to estimate work involved
and to check of progressMaintainable—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
Q&AQ&A
http://staruml.en.softonic.com/