1

LECTURE 2:LECTURE 2:Approaches to System DevelopmentApproaches to System Development

ITEC 3010 “Systems Analysis and Design, I”

[Prof. Peter Khaiter]

2

Lecture OutlineLecture Outline

Systems Development Life CycleSystems Development Life Cycle Phases and Activities in the SDLC Phases and Activities in the SDLC Variations of the SDLC modelsVariations of the SDLC models Selecting the appropriate modelSelecting the appropriate model Methodologies Methodologies of the SDLC of the SDLC Traditional Approach to SDLCTraditional Approach to SDLC Information Engineering Approach to SDLCInformation Engineering Approach to SDLC Object-Oriented Approach to SDLCObject-Oriented Approach to SDLC Rapid Application DevelopmentRapid Application Development Current trends in the SDLCCurrent trends in the SDLC CASE ToolsCASE Tools

3

Systems Development Life CycleSystems Development Life Cycle

Systems development life cycleSystems development life cycle (SDLC)

Provides overall frameworkoverall framework for managing systems development process

Two main approaches to SDLC

Predictive approachPredictive approach – assumes project can be planned out in advance

Adaptive approachAdaptive approach – more flexible, assumes project cannot be planned out in advance

All projects use some variation of SDLC

4

Predictive vs. Adaptive Approach Predictive vs. Adaptive Approach to the SDLCto the SDLC

5

Phases in SDLCPhases in SDLC

Project planningProject planning – initiate, ensure feasibility, plan schedule, obtain approval for project

AnalysisAnalysis – understand business needs and processing requirements

DesignDesign – define solution system based on requirements and analysis decisions

ImplementationImplementation – construct, test, train users, and install new system

SupportSupport – keep system running and improve

6

Systems Development Life CycleSystems Development Life Cycle

7

Systems Life CycleSystems Life Cycle

8

Activities of Each SDLC PhaseActivities of Each SDLC Phase

Predictive or adaptive approach use SDLC

Activities of each “phase” are similar

Phases are not always sequential Phases can overlap Activities across phases can be

done within an iteration

9

Activities of Project PlanningActivities of Project Planning

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

10

Analysis ActivitiesAnalysis Activities

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

11

Design ActivitiesDesign Activities

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

12

Implementation ActivitiesImplementation Activities

Construct software components Verify and test Convert data Train users and document the

system Install the system

13

Support Activities (SLC, not SDLC)Support Activities (SLC, not 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

14

FIGURE 2-2 The SDLC Phases.

15

““Waterfall” Approach to the SDLCWaterfall” Approach to the SDLC

16

““Waterfall” ApproachWaterfall” Approach

Each life cycle phase is completed in sequencesequence and then the results of the phase flow on to the next phase

There is nono going back going back once the phase is completed (like a waterfall) or it is extremely difficult to do

The key deliverablesdeliverables for each phase are typically produced on paperon paper (hundreds of pages in length)

The decisions made at each phase are frozenfrozen, i.e. they cannot be changed

17

Overlap of activitiesOverlap of activities

18

““Waterfall” Approach: pros and Waterfall” Approach: pros and conscons

The two key advantages of the waterfall model:• Identifying system requirements long before programming begins• It minimizes changes to the requirements as the project proceeds

The key disadvantages:• The design must be completely specified on paper before programming begins• A long time elapses between the completion of the system proposal in the analysis

phase and the delivery of the system (usually many months or years).• A paper document is often a poor communication mechanism, so important

requirements can be overlooked in the hundreds of pages of documentation• Users rarely are prepared for their introduction to the new system, which occurs long

after the initial idea for the system was introduced.• If the project team misses important requirements, expensive post-implementation

programming may be needed.• A system may require significant rework because of changes in business environment

since the time the analysis phase occurred. It means going back to the initial phases and following the changes through each of the subsequent phases in turn.

19

The Parallel ModelThe Parallel Model

The Parallel Model attempts to address the problem of long delays between the analysis phase and the delivery of the system.

Instead of doing the design and implementation in sequence, it performs a general design for the whole system and then divides the project into series of distinct subprojects that can be designed and implemented in parallel

Once all subprojects are complete, the final integration of the separate pieces is delivered

20

The Parallel ModelThe Parallel Model

21

Parallel Model: pros and consParallel Model: pros and cons

Primary advantages: Can reduce the schedule time required to deliver

a system There is less chance of changes in the business

environment causing rework

Key disadvantages: Still suffers from problems caused by paper

documentation A new problem: sometimes the subprojects are

not completely independent; design made in one subproject may affect another and the end of the project may require significant integrative efforts

22

Newer Adaptive Approaches to the Newer Adaptive Approaches to the SDLCSDLC

Based on spiral modelspiral model

Project cycles through development activities over and over until project is complete

Prototype created by end of each cycle

Focuses on mitigating risk

IterationIteration – 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

23

Spiral ModelSpiral Model

Breaks each project into smaller pieces, each with a different type of risk (Sources of risk: undefined requirements, complex technology, uncertain competitive environment)

The project begins in the center of the spiral where project is still small, easy to manage and low in risk

Then the project slowly expands The project starts out small, initially handling a few of

the risks Then the project expands in next iteration to address

more of the risks Eventually the system is completed (all risks

addressed)

Advantage:Advantage: The iterative nature and focus on risk reduction

24

The Spiral Life Cycle ModelThe Spiral Life Cycle Model

25

The Model with IterationsThe Model with Iterations

Iteration:Iteration: the process of looping through the same development activities multiple times, sometimes at increasing levels of details or accuracy

Assumes no one gets the right results the first time Do some analysis, then some design, then some

implementation, then do some further analysis, etc until you get it right

Idea:Idea: not always realistic to complete analysis before starting design

Waterfall no longer applies - Phases become blurred Decisions are not frozen at the end of each phase

Applicability:Applicability: Good for projects where requirement specifications are hard to

arrive at

26

Iteration of System Development Iteration of System Development ActivitiesActivities

27

Phased Development ModelPhased Development Model

Breaks the overall system into a series of versions that are developed sequentially

The analysis phase identifies the overall system concept. The project team, users and system sponsors categorize the requirements into a series of versions

The most important and fundamental requirements are bundled into the first version of the system. The analysis phase then leads into design and implementation, but only with the set of requirements identified for version 1

Once version 1 is implemented, work begins on version 2. Additional analysis is performed on the basis of the previously identified requirements and combined with new ideas and issues that arose from users’ experience with version 1.

Version 2 then is designed and implemented, and work immediately begins on the next version. This process continues until the system is complete

28

Phased ModelPhased Model

29

Phased Model: pros and consPhased Model: pros and cons

Advantages: Quickly getting a useful system into the hands of users. Although it does not perform all the functions the users need, it helps them sooner to identify important additional requirements

Disadvantages: The users begin to work with systems that are incomplete. It is critical to identify the most important and useful features and include them in the first version. 

30

Just For FunJust For Fun

http://www.funnyhumor.com/pictures/206.php

31

Prototyping modelPrototyping model

Performs analysis, design and implementation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed.

The basics of analysis and design are performed, and work immediately begins on a system prototype (i.e., a ‘quick-and-dirty” program that provides a minimal amount of features

The first prototype is shown to the users and the project sponsor, who provide comments, which are used to re-analyze, re-design, and re-implement a second prototype that provides a few more features

This process continues in a cycle until the analysts, users and sponsor agree that the prototype provides enough functionality to be installed and used. Refinement occurs until it is accepted as the new system.

32

Prototyping SDLCPrototyping SDLC

33

Prototyping model: pros and consPrototyping model: pros and cons

The key advantages:

• Very quickly provides a system for users to interact with. It reassures the users that the project team is working on the system. The users can interact with the prototype to better understanding what it can and cannot do rather than attempting to understand a system specification on paper.

The major disadvantages:

• Fast-paced system releases challenge attempts to conduct careful, methodical analysis. Often the prototype undergoes such significant changes that many initial design decisions become poor ones. This can cause problems in the development of complex systems because fundamental issues and problems are not recognized until well into the development process.

34

Throwaway PrototypingThrowaway Prototyping

Similar to the prototyping model in that it includes the development of prototypes, however, they are done at a different point in the SDLC

Has a relatively thorough analysis phase that is used to gather information and to develop ideas for the system concept. Many of the features suggested by the users may not be well understood and many technical issues may not be solved.

Each of these issues are examined by analyzing, designing and building a design prototype (it is not a working system; it only represents a part of the system that needs additional refinement and it contains only enough details to enable users to understand the issues under consideration)

Typically, several prototypes are used during analysis and design phase. Each of them is used to minimize the risk of missing of important issues before the real system is built.

Once the issues are resolved, the project moves into design and implementation. At this point, the design prototypes are thrown away, what is a principal difference between this model and prototyping, in which the prototypes evolve into the final system

35

Throwaway Prototyping ModelThrowaway Prototyping Model

36

Throwaway Prototyping: pros and Throwaway Prototyping: pros and conscons

• Balances the benefits of well-through-out analysis and design phases with the advantages of using prototypes to refine key issues before a system is built.

• It may take longer to deliver the final system as compared with prototyping (as far as the prototypes do not become the final system), but this model usually produces more stable and reliable systems.

37

Criteria for Selecting the Criteria for Selecting the Appropriate Model of SDLCAppropriate Model of SDLC

38

Criteria for SelectingCriteria for Selecting

Clarify of user requirements Sometimes the user requirements are unclear or subject to change. Prototyping and throwaway prototyping are more appropriate models for such situations, because they provide prototypes for user to interact with at early stages of the SDLC.

Familiarity with Technology When the system will use new technology, which is unfamiliar for the analysts and programmers (e.g. the first Web-based project with Java), it increases the risks. Application of the new technology as early as possible will improve the chance of success. Throwaway prototyping is particularly appropriate for this situation since it explicitly encourages the developers to develop design prototypes for areas with high risks. Phased model is good as well because it creates opportunities to investigate the technology in some depth before the design is complete.

System Complexity Complex systems require careful and detailed analysis and design. Throwaway prototyping is particularly well suited to such situation, but prototyping is not. The traditional structured methodologies can handle complex systems, but without the ability to get the system or prototypes into users’ hands early on, some key issues may be overlooked. Even though the phased model enables users to interact with the system early in the process.

39

Criteria for SelectingCriteria for Selecting

Short time schedules Projects with short time schedules are well suited for RAD models as far as they are designed to increase the speed of development. Prototyping and phases development are excellent choices because they best enable the project team to adjust the functionality in the system. If the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under development. The waterfall model is the worst choice, because it does not allow for easy schedule changes.

Schedule visibility One of the greatest challenges in systems development is knowing whether a project is on schedule. This is particularly true of the structured methods because design and implementation occur at the end of the project. The RAD models move many of the critical design decisions to an earlier point in the project to help project managers to recognize and address risk factors and keep expectations in check.

40

MethodologiesMethodologies

MethodologiesMethodologies

Comprehensive guidelines to follow for completing every SDLC activity

Collection of models, tools, and techniques

41

Relationships Among Components Relationships Among Components of a Methodologyof a Methodology

42

ModelsModels

Models

Representation of an important aspect of real world, but not same as real thing

Abstraction used to separate out aspect

• physical (like a model of an airplane)

• abstract (e.g. in form of mathematical notation or in graphical form)

Models in SDLC are graphical: diagrams and charts

Project planning and budgeting aids

43

Some Models Used in SDLCSome Models Used in SDLC

44

ToolsTools

ToolsSoftware support that helps create models or other required project components Range from simple drawing programs to complex CASE tools to project management software

45

Some Tools Used in SDLCSome Tools Used in SDLC

46

TechniquesTechniques

TechniquesCollection of guidelines that help analysts complete a system development activity or taskCan be step-by-step instructions or just general advice

47

Some Techniques Used in SDLCSome Techniques Used in SDLC

48

Two Approaches to System Two Approaches to System DevelopmentDevelopment

Traditional approachTraditional approach Also called structured system developmentStructured analysis and design technique (SADT)Includes information engineering (IE)

Object-oriented approachObject-oriented approachAlso called OOA, OOD, and OOPViews information system as collection of interacting objects that work together to accomplish tasks

49

Traditional ApproachTraditional Approach

Structured programmingImproves computer program qualityAllows other programmers to easily read and modify codeEach program module has one beginning and one ending

Three programming constructs (sequence, decision, repetition)

50

Three Structured Programming Three Structured Programming ConstructsConstructs

51

Top-Down ProgrammingTop-Down Programming

Divides complex programs into hierarchy of modules

The module at top controls execution by “calling” lower level modules

Modular programming

Similar to top-down programming

One program calls other programs to work together as single system

52

Top-Down or Modular ProgrammingTop-Down or Modular Programming

53

Structured DesignStructured Design

Technique developed to provide design guidelines

What set of programs should beWhat program should accomplishHow programs should be organized into a hierarchy

Modules are shown with structure chart

Main principle of program modulesLoosely coupled – module is independent of other modulesHighly cohesive – module has one clear task

54

Structure Chart Created Using Structure Chart Created Using Structured Design TechniqueStructured Design Technique

55

Structured AnalysisStructured Analysis

Define what system needs to do (processing requirements)

Define data system needs to store and use (data requirements)

Define inputs and outputs

Define how functions work together to accomplish tasks

Data flow diagrams (DFD) and entity relationship diagrams (ERD) show results of structured analysis

56

Data Flow Diagram (DFD) Created Data Flow Diagram (DFD) Created Using Structured Analysis Using Structured Analysis TechniqueTechnique

57

Entity-Relationship Diagram (ERD) Entity-Relationship Diagram (ERD) Created Using Structured Analysis Created Using Structured Analysis TechniqueTechnique

58

Structured Analysis Leads to Structured Analysis Leads to Structured Design and Structured Structured Design and Structured ProgrammingProgramming

59

• Techniques address some but not all of the activities of analysis and design • Techniques make system development not enough formal (not like an engineering discipline) but rather like an art. • The transition from the data flow diagram (in structured analysis) to the structure chart (in structured design) did not work well in practice. • data modeling using structure chart and ER diagram were more important than modeling of processes (using dataflow diagrams) • However, the structured approach overall still made processes rather than data the central focus of the system • Many felt a strategic planning technique needed to be included in the approach to determine which systems to be built and to provide some initial requirements. • As an alternative: information engineering.

Weaknesses of the Structured Weaknesses of the Structured ApproachApproach

60

Information Engineering (IE)Information Engineering (IE)

Focus on strategic planning to identify all the organization information needs (the application architecture plan), data modeling, and automated tools

More focused on data itself than the structured approach. But just as the structural approach includes data requirements, IE includes processes, too

The processing model of information engineering, the process dependency diagram, is similar to a data flow diagram, but it focuses more on which processes are dependent on other processes and less on data inputs and outputs

Provides more complete life cycle support through the use of an integrated CASE tools (help to automate systems development; final program code can be generated automatically by the CASE tools)

Became popular on large-mainframe systems in the 1980’s, less used in the 1990’s on smaller desktop systems (but concepts still used by planning and emphasis on data modeling)

61

Structured Approach Structured Approach andand IE IE

Both approaches define information system requirements, design and construct information systems by looking at processes, data and the interaction of these two

Industry merged key concepts from structured development and information engineering approaches into traditional approach

An object-orientedobject-oriented technology provides a completely different perspective

62

Object-Oriented ApproachObject-Oriented Approach

Completely different approach to information systems

Views information system as collection of interacting objectsinteracting objects that work together to accomplish tasks

Objects – things in computer system that can respond to messagesConceptually, no processes, programs, data entities, or files are defined – just objects

OO languages: Java, C++, C#, .NET, VB

63

Object-Oriented Approach to Object-Oriented Approach to SystemsSystems

64

Object-Oriented Approach Object-Oriented Approach (continued)(continued)

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

65

Class Diagram Created During OO Class Diagram Created During OO AnalysisAnalysis

66

SDLC VariationsSDLC Variations

Many variations of SDLC in practice

Based on variation of names for phases

No matter which one, activities/tasks are similar

Some increase emphasis on people

User-centred design, participatory design

Socio-technical systems

Some increase speed of development

Rapid application development (RAD)

Prototyping

67

Rapid application development (RAD) is one of the variations of SDLC

Aims to speed up the development process.

Emerged in the 1990s as an attempt to address both weaknesses of the waterfall development: long development times and the difficulty in understanding a system from paper-based description.Methods:

• Tries to speed up the activities in each phase (e.g. speeding the analysis phase by scheduling intensive meetings of key participants to get information gathered and decisions made rapidly)

• Using iterative development (e.g., spiral life cycle model) to speed up the process of getting to design and implementation

• Building prototypes of the system during analysis and design phases. It improves understanding of the system requirements• Using CASE (computer-aided system engineering) tools to speed up the analysis, design and implementation phases

Rapid Application DevelopmentRapid Application Development

68

Current Trends in DevelopmentCurrent Trends in Development

More adaptive approachesThe Unified Process (UP)Extreme Programming (XP)Scrum

Details on each in Chapter 17

69

The Unified Process (UP)The Unified Process (UP)

Object-oriented development approach Offered by IBM / Rational

Booch, Rumbaugh, Jacobson Unified Modeling Language (UML) used primarily for

modeling UML can be used with any OO methodology UP defines four life cycle phases

Inception, elaboration, construction, transition Defines workflows within each phase: business modeling,

requirements modeling, analysis and design, implementation, testing, development, configuration and change management, and project management

Involves roles of: designer, use case specifier, systems analyst, implementer, architect

70

Unified Process Unified Process Life CycleLife Cycle

71

The Unified Process (UP) The Unified Process (UP) (continued)(continued)

Reinforces six best practices

Develop iteratively

Define and manage system requirements

Use component architectures

Create visual models

Verify quality

Control changes

72

Extreme Programming (XP)Extreme Programming (XP)

Recent, lightweight, development approach to keep process simple and efficient

Describes system support needed and required system functionality through informal user stories

Has users describe acceptance tests to demonstrate defined outcomes

Relies on continuous testing and integration, heavy user involvement, programming done by small teams

73

ScrumScrum

For highly adaptive project needs

Respond to situation as rapidly as possible

Scrum refers to rugby gameBoth are quick, agile, and self-organizing

Team retains control over project

Values individuals over processes

74

Computer-Aided System Computer-Aided System Engineering (CASE) ToolsEngineering (CASE) Tools

CASE tools are software tools designed to help systems analyst complete development tasks

The CASE tool contains a database of information called a repository

The repository stores information about the system, including models, descriptions, and references that link the various model together

Information stored in repository can be used in a variety of ways by the development team

Every time a team member adds information about the system, it is immediately available for everyone else

CASE tools can check the models to make sure they are complete and follow the correct diagramming rules

CASE tools can check one model against another to make sure they are consistent

75

Visual Modeling Tool Repository Visual Modeling Tool Repository Contains All System InformationContains All System Information

76

CASE Tools: ExamplesCASE Tools: Examples

Microsoft Visio• a drawing tool suitable for about any

system model• comes with a collection of drawing

templates (incl. symbols used in a variety of business and engineering applications: flowcharts, DFDs, ERDs, UML diagrams)

• provides only a limited repository for storing definitions and descriptions of diagram elements, but not a complete repository for a system development project.

77

Visio Visio for drawing a variety of for drawing a variety of diagrams and chartsdiagrams and charts

78

CASE Tools: Examples (cont’d)CASE Tools: Examples (cont’d)

Oracle Designer• a tool set for recording definitions and automating

the rapid constructions of flexible, graphical client-server applications

• integrated with Oracle Developer (a tool for creating GUI applications)

• includes a complete repository, diagramming and code-generating capabilities

• an integrated CASE tool that supports traditional approach to system development (process modeler, function-hierarchy diagrammer, data flow diagrammer, entity-relationship diagrammer)

• Design Transformer and Design Editor produce diagrams along with the database and application logic

79

Oracle DesignerOracle Designer: Front Panel : Front Panel screenscreen

80

Oracle DesignerOracle Designer: Entity-: Entity-Relationship DiagrammerRelationship Diagrammer

81

CASE Tools: Examples (cont’d)CASE Tools: Examples (cont’d)

TogetherSoft• The most recent concept of round-trip

engineering • allows synchronizing the graphical models

(such as class diagram) with generated program code (automation in both directions – round trip).

• If the program code is changed, the class diagram is updated and contra versa, if the class diagram is changed, the program code is updated.

• Together uses UML diagrams with several different programming languages

82

TogetherTogether showing a class diagram showing a class diagram with synchronized Java source codewith synchronized Java source code

83

CASE Tools: Examples (cont’d)CASE Tools: Examples (cont’d)

Embarcadero Describe• a new product that include modeling

and round-trip engineering features• provides flexible UML modeling

capabilities for analysis and design• provides round-trip engineering with

several Java development tools (JBuilder and Sum Forte)

84

Embarcadero DescribeEmbarcadero Describe with visual with visual modeling and round-trip modeling and round-trip engineeringengineering

85

ReadingsReadings

Today’s lecture: Chapter 2 – “Approaches to System Development”

For next lecture: Chapter 3 – “The Analyst as a Project Manager”

Thank you !!!