System Analysis and Development and Models Class Ppt

8/3/2019 System Analysis and Development and Models Class Ppt

1/92

System Analysis and

Development andmodels

Module 4


2/92

What is Software?

Instructions (computer programs) that when executedprovide desired function and performance

Data structures enable the programs to adequately

manipulate information Documents that describe the operation and use of

the program

Software engineering : A Practitioner's Approach


3/92

A definition of the software

development: The application of a systemic,

disciplined, quantifiable approach todevelopment, operation, and

maintenance of software. EEE Standard Computer Dictionary, 610, ISBN

1-55937-079-3Software Engineering: A Practitioner's Approach


4/92

Whos Who

CUSTOMER Sponsors systemdevelopment

USER

Uses

system

DEVELOPER

Builds

system

Contractualobligation

$$$,needs

Software system

Needs


5/92

5


6/92

6

Two Main Approaches

Both traditional and object-oriented approaches tosystem development use the system development lifecycle (SDLC) as a project management and aprocess management framework.

The predictive approach to the SDLC is used forprojects that are

well understood and low risk. The adaptive approach to the SDLC is used for

projects that are not well understood and are higherrisk.

Adaptive SDLCs are more iterative and allow theproject team to adapt the project to changingcircumstances. Sometimes very important in today'srapidly changing environments.


7/92

The System Development Life Cycle

What is an information system (IS)?

Hardware, software, data,

people, and procedures that

work together to producequality information

SystemSet of components

that interact to achieve

common goal

Businesses use many types of

systems


8/92


What are the phases of the system development cycle?

Phase 1. Planning

Phase 2. Analysis

Phase 3. Design

Phase 4. ImplementationPhase 5. Support

Review project requests

Prioritize project

requests Allocate resources

Identify project

development team

Conduct preliminary investigation

Perform detailed analysis activities:

Study current system

Determine user requirements

Recommend solution

Acquire hardware

and software, if

necessary

Develop details of

system

Develop programs, if necessary

Install and test new system

Train users

Convert to new system

Conduct post-implementation

system review

Identify errors and enhancements

Monitor system performance


9/92

Arrange tasks into phases


What are guidelines for system development?

Involve users (anyone for whom

system is being built)

Develop clearly defined standards (procedurescompany expects employees to follow)


10/92


Who participates

in the system

development life

cycle?


11/92


What is the role of a systems analyst?

Responsible for designing

and developing

information system

Liaison between users

and IT professionals


12/92


What is the project team?

Consists of users, systems analyst, and other IT professionals

Formed to work on project from beginning to end

Project leaderone member of the team who

manages and controls project budget and schedule


13/92


What is feasibility?Measure of

how suitable

system

developmentwill be to the

company

Operational

feasibility

Schedule

feasibility

Four feasibility

tests:

Technicalfeasibility

Economic

feasibility

(also calledcost/benefit

feasibility)


14/92


What is documentation?

Includes reports, diagrams,

programs, and other deliverables

Collection and summarization

of data and information


15/92


What are six data and information gathering techniques? Review documentation Observe

Questionnaire

Interview

Joint-application

design (JAD) session

Research


16/92


What are some reasons to create or modify an

information system?

Competition canlead to change

To improve

existing system

Outside group maymandate change

To correct problem

in existing system


17/92


What is a request for system services? Formal request for

new or modified

information system Also called

project request


18/92


What is the planning phase?Begins when steering committee receives project request

Steering

committee

decision-making

body for the

company

Function of committee:

Review and

approve project

requests

Allocate

resources

Form projectdevelopment

team for each

approved

project

Prioritize

project requests


19/92


What is the analysis phase?Conduct preliminary

investigation, also

called feasibility

study

Perform detailed

analysis


20/92


What is the preliminary investigation? Determine exact nature of problem or improvement

and whether it is worth pursuing Findings are presented in feasibility report, also known as a feasibility study


21/92


What is detailed analysis?

Sometimes called logical design

2. Determine users wants, needs,and requirements

3. Recommend solution

1. Study how current system

works


22/92

Presented to

steering

committee,

which decideshow system will

be developed


What is the

system proposal? Assessesfeasibility

of each

alternative

solution

Recommends

the most

feasible

solution forthe project


23/92


What are possible solutions?Buypackaged softwareprewritten

software available for purchase

Outsourcehave outside sourcedevelop software

Write own custom softwaresoftware

developed at users request

Vertical market

softwaredesigned

for particular industry

Horizontal market

softwaremeetsneeds of many

companies


24/92


What is the design phase?

Acquire hardware and software

Develop all details of new or

modified information system


25/92

Visit vendors stores


What is needed to acquire new hardware and software?

Identify all hardware and software requirements of new or

modified system

Surf Web

Read print and online

trade journals,newspapers, and

magazines

Talk with other

systems analysts


26/92


What are three basic documents used to summarize

technical specifications?

Less formal method

that uses standard

form to request

information about

product or service

Vendor quotes

price(s) for

listed

product(s)

Vendor selects

product(s) that

meet(s) your

requirements andthen quotes

price(s)

Identifies

product(s)

you want

Request for information (RFI)

Request for proposal (RFP)

Request for quotation (RFQ)


27/92


How do systems analysts test software products? References from vendor

Talk to current users of product

Product demonstrations

Trial version of software

Benchmark test measures performance


28/92


What is a detailed design?

Includes several activities

Database

design

Input and

output design

Program

design

Detailed design specifications for components in proposed solution


29/92


What is a mockup? Sample of input or output that contains actual data

T


30/92


What is a prototype?

Working model of

proposed system

Beginning a prototype

too early may lead to

problems

Th S D l if C l


31/92


What is computer-aided software engineering (CASE)? Software tools designed to support activities of system

development cycle

Th S D l Lif C l


32/92

Convert to new system


What is the implementation phase? Purpose is to construct, or build, new or modified

system and then deliver it to users

Train users

Install and test new system

Develop programs

Th S D l Lif C l


33/92


What are the three types of tests performed by system

developers?

Verifies application

works with other

applications

Systems test

Integration Test

Unit Test

Verifies eachindividual program

works by itself

Verifies all programsin application work

together

Th S D l Lif C l


34/92


What is training? Showing users exactly

how they will use new

hardware and software

in system

Th S D l Lif C l


35/92


What is the support phase?Conductpost-implementation system reviewmeeting to find out if

information system is performing according to expectations

Identify errors

Identify enhancements

Monitor system performance

Provides ongoing assistance after system is implemented


36/92

SYSTEM DEVELOPMENTMODELS

36


37/92

Two Approaches to

System Development1. Traditional Approach

Structured system development

Structured analysis Structured design

Structured programming

Known as Structured Analysis and

Design Technique (SADT)

2. Object-Oriented Approach


38/92

Structured Programming

Improves computer program quality

Allows other programmers to easily

read and modify the code Each program module has one

beginning and one ending

Three programming constructs


39/92

Satzinger et al (2006) Fig 2-12

Three Structured Programming

Constructs


40/92

Top-Down Programming

Divides complex programs into hierarchy ofmodules

Module at top controls execution by callinglower level modules

Modular programming Similar to top-down programming One program calls others to work as single system


41/92


Top-Down or Modular

Programming


42/92

Structured Design

Developed to provide guidelines

What the set of programs should be

What each program should accomplish How programs should be organized into a

hierarchy Structure Chart

Main principles of program modules Loosely coupled

Highly cohesive


43/92

Satzinger et al (2006) Fig 2-14Structure Chart


44/92

Structured Analysis

Helps developer define what the systemneeds to do (processing requirements)

Data to store and use Inputs and outputs

How functions work together

DFDs and ERDs commonly showresults of structured analysis


45/92


Structured Analysis Leads to StructuredDesign and Structured Programming


46/92

Automated Tools and

Technology Computer-aided systems engineering

(CASE)

Application Development Environments(ADE) or Integrated DevelopmentEnvironments (IDE)

Process and project managers


47/92

ADE Tools

Application development environments(ADEs) are:

integrated software development tools

provide all the facilities necessary to develop newapplication software

maximise speed and quality

A common synonym is integrateddevelopment environment (IDE)


48/92

Project Managers

A project manageris an automated tool to: help plan system development activities

(preferably using the approved methodology)

estimate and assign resources (including peopleand costs)

schedule activities and resources

monitor progress against schedule and budgetcontrol

modify schedule and resources

report project progress


49/92

Computer-Aided System

Engineering (CASE) Automated tools to improve the speedand quality of system development work

Support the drawing of models Provide for the translation of systemmodels into application programs

Database of information about systemcalled repository

Upper CASE, Lower CASE, ICASE


50/92

CASE repository

is a system developers or project

database

it is a place where developers can storesystem models, detailed descriptions andspecifications, and other products ofsystem development

synonyms include dictionary andencyclopedia


51/92

Forward and Reverse

Engineering Forward engineering requires the systemsanalyst to draw system models, either fromscratch or from templates. The resulting

models are subsequently transformed intoprogram code

Reverse engineering allows a CASE tool toread existing program code and transform

that code into a representative system modelthat can be edited and refined by the systemsanalyst


52/92


CASE ToolRepository containsall system Information


53/92

Process AnalysisSystem Process Modeling

Three main analysis techniques tobe reviewed here are:

Data Flow Diagrams (DFDs)

Data Dictionary Definitions

Process Specifications


54/92

Introduction to Data Flow Diagrams

Basic Constructs:

Processes

Data flows

Files

External Entities: sources or sinks


55/92

The Interrelation BetweenSpecification Components


56/92

Example of a Data FlowDiagram(1)

Example of a Data Flow


57/92

Example of a Data FlowDiagram(2)


58/92

Introduction to Data Flow Diagrams(cont.)

Constructing Data Flow Diagrams

Identify the Static Components

Identify the Main Processes

Expand and Refine the Diagram

Review the Diagram


59/92

Context DiagramDecomposition Level: 0

Diagram 0


60/92

Diagram 0Decomposition Level: 1


61/92



62/92



63/92

Data Dictionaries (DD)

Purpose:

to keep data about:

Data Flow and Data Item Specifications

File Specifications


Data Specification Language:

Notational Conventions: = , + , [ ] , { } , ( )e.g. amount due = [dollar amount, sterling amount]



64/92


Processing and control information omitted from a DFD belongsin a process specification

Each functional primitive has one process specification

Process Specifications can be represented in a variety oflanguages, the most popular are:

Structured English

Decision Tables and Decision Trees


65/92

Decision Tables

A tabular of conditions and actions and an indicationunder which conditions, which actions must beperformed

Consists of four quadrants

Condition Stub Rulesa list of all possible conditions contains selectors which identify

that can arise within the process different combinations of the possible conditions

Action Stub Action Entriesa list of all possible actions that indicators which select the actions to be performed

occur within the process


66/92

Decision Tables: 3 variants

Limited Entry Decision Table

Mixed Entry Decision Table

Extended Entry Decision Table


67/92

Limited Entry Decision Table

Contains only the binary selectors Y & N and the catch all selector -in the rules quadrant. In the action entries, it contains only the actionselector symbol X.

1 2 3 4

Credit Satisfactory Y N N N

Prompt Payer - Y N N

Special Clearance - - Y N

Accept Order X X XReturn Order X


68/92

Contains only the binary selectors Y & N and the catch all selector -

in the rules quadrant. In the action entries quadrant, indicators otherthan X appear.

1 2 3

Salaried Employee N N Y

Hours Worked > 40 Y N -

Pay Overtime Regular Regularrate rate rate

Mixed Entry Decision Table


69/92

Extended Entry Decision Table

Selectors in the rules quadrant are no longer simply binary (y or N)but may take on specific values or ranges of values.

1 2 3 4

Approved Credit N Y Y Y

Quantity Ordered - 0-24 25-55 56-99

Discount (%) 0 5 10

Release Order X X X

Reject Order


70/92

Advantages of Decision Tables

Easily understood

Alternatives are shown side by side

Cause & effect relationship is shown, thus permittingeasier user validation

Possible to check that all combinations of conditionshave been considered


71/92

SDLC Model

A framework that describes the activitiesperformed at each stage of a softwaredevelopment project.

f


72/92

Waterfall Model Requirements defines

needed information, function,behavior, performance andinterfaces.

Design data structures,

software architecture, interfacerepresentations, algorithmicdetails.

Implementation source

code, database, userdocumentation, testing.

W f ll S h


73/92

Waterfall Strengths

Easy to understand, easy to use

Provides structure to inexperienced staff

Milestones are well understood

Sets requirements stability Good for management control (plan, staff, track)

Works well when quality is more important than

cost or schedule

W f ll D fi i i


74/92

Waterfall Deficiencies

All requirements must be known upfront Deliverables created for each phase areconsidered frozeninhibits flexibility

Can give a false impression of progress

Does not reflect problem-solving nature ofsoftware development iterations of phases

Integration is one big bang at the end

Little opportunity for customer to preview thesystem (until it may be too late)

Wh h W f ll M d l


75/92

When to use the Waterfall Model

Requirements are very well known Product definition is stable

Technology is understood

New version of an existing product Porting an existing product to a new platform.

Structured Evolutionary Prototyping


76/92

Structured Evolutionary PrototypingModel

Developers build a prototype during therequirements phase

Prototype is evaluated by end users

Users give corrective feedback

Developers further refine the prototype

When the user is satisfied, the prototypecode is brought up to the standardsneeded for a final product.



77/92

Structured Evolutionary PrototypingSteps

A preliminary project plan is developed An partial high-level paper model is created The model is source for a partial requirements

specification A prototype is built with basic and critical attributes The designer builds

the database user interface algorithmic functions

The designer demonstrates the prototype, the userevaluates for problems and suggests improvements. This loop continues until the user is satisfied



78/92

Structured Evolutionary PrototypingStrengths

Customers can see the system requirementsas they are being gathered

Developers learn from customers

A more accurate end product

Unexpected requirements accommodated

Allows for flexible design and development

Steady, visible signs of progress produced

Interaction with the prototype stimulatesawareness of additional needed functionality



79/92

Structured Evolutionary PrototypingWeaknesses

Tendency to abandon structured programdevelopment for code-and-fix development

Bad reputation for quick-and-dirty methods

Overall maintainability may be overlooked The customer may want the prototype delivered.

Process may continue forever (scope creep)

When to use


80/92

When to useStructured Evolutionary Prototyping

Requirements are unstable or have to beclarified

As the requirements clarification stage of a

waterfall model Develop user interfaces

Short-lived demonstrations

New, original development

With the analysis and design portions of object-oriented development.

R id A li ti M d l (RAD)


81/92

Rapid Application Model (RAD)

Requirements planning phase (a workshoputilizing structured discussion of businessproblems)

User description phase automated tools

capture information from users Construction phase productivity tools, such as

code generators, screen generators, etc. insidea time-box. (Do until done)

Cutover phase -- installation of the system, useracceptance testing and user training

RAD St th


82/92

RAD Strengths

Reduced cycle time and improved productivitywith fewer people means lower costs

Time-box approach mitigates cost and schedulerisk

Customer involved throughout the completecycle minimizes risk of not achieving customersatisfaction and business needs

Focus moves from documentation to code(WYSIWYG).

Uses modeling concepts to capture informationabout business, data, and processes.

RAD W k


83/92

RAD Weaknesses

Accelerated development process must givequick responses to the user

Risk of never achieving closure

Hard to use with legacy systems

Requires a system that can be modularized

Developers and customers must be committedto rapid-fire activities in an abbreviated time

frame.

Wh t RAD


84/92

When to use RAD

Reasonably well-known requirements

User involved throughout the life cycle

Project can be time-boxed

Functionality delivered in increments

High performance not required

Low technical risks System can be modularized

Spiral SDLC Model


85/92

Spiral SDLC Model Adds risk analysis,

and 4gl RADprototyping to thewaterfall model

Each cycle involvesthe same sequence ofsteps as the waterfallprocess model

Spiral QuadrantD t i bj ti lt ti d t i t


86/92

Determine objectives, alternatives and constraints

Objectives: functionality, performance,hardware/software interface, critical success factors, etc.

Alternatives: build, reuse, buy, sub-contract, etc.

Constraints: cost, schedule, interface, etc.

Spiral Quadrant


87/92

p QEvaluate alternatives, identify and resolve risks

Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight

schedules, poor process, etc.

Resolve risks (evaluate if money could be lost by

continuing system development

Spiral Quadrant


88/92

pDevelop next-level product

Typical activites: Create a design

Review design

Develop code

Inspect code

Test product

Spiral Quadrant


89/92

pPlan next phase

Typical activities Develop project plan

Develop configuration management plan

Develop a test plan

Develop an installation plan

Spiral Model Strengths


90/92

Spiral Model Strengths

Provides early indication of insurmountablerisks, without much cost

Users see the system early because of rapid

prototyping tools Critical high-risk functions are developed first

The design does not have to be perfect

Users can be closely tied to all lifecycle steps

Early and frequent feedback from users

Cumulative costs assessed frequently

Spiral Model Weaknesses


91/92

Spiral Model Weaknesses Time spent for evaluating risks too large for small or low-

risk projects

Time spent planning, resetting objectives, doing riskanalysis and prototyping may be excessive

The model is complex

Risk assessment expertise is required Spiral may continue indefinitely

Developers must be reassigned during non-developmentphase activities

May be hard to define objective, verifiable milestonesthat indicate readiness to proceed through the nextiteration

When to use Spiral Model


92/92

When to use Spiral Model

When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because

of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line

Significant changes are expected (research andexploration)

System Analysis and Development and Models Class Ppt

Documents

Transcript of System Analysis and Development and Models Class Ppt