Asst.Prof. Dr. Surasak Mungsing. 3 Learning Objectives Explain the purpose and various phases of the systems development life cycle (SDLC) Explain when

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


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


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


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)


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


Class Diagram: StereotypesClass Diagram: Stereotypes


Class Diagram: Stereotypes


Class Diagram: StereotypesClass Diagram: Stereotypes


Class Diagram: Class SymbolClass Diagram: Class Symbol

Class Diagram: Instance Symbol


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


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


Class Diagram: AssociationsClass Diagram: Associations


Class Diagram: MultiplicityClass Diagram: Multiplicity


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


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]


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


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


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


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


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


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/

Documents

Asst.Prof. Dr. Surasak Mungsing. 3 Learning Objectives Explain the purpose and various phases of the systems development life cycle (SDLC) Explain when