DBIT 201/DCIS 200 Systems Analysis and Design

System Design

Key Definitions
Design phase
Decide how to build the system Create system requirements that describe technical details for building the system

System specification
Final deliverable from design phase Conveys exactly what system the design team will implement during the implementation phase

Design Phase Steps

Present design alternatives (make, buy, or outsource) Convert logical process and data models into physical models Design the architecture for the system Make hardware and software selections Design the system inputs and outputs Design the way data will be stored Design the programs for the underlying processes Create the system specification

Classical Design Mistakes

Reducing design time Feature creep?? Silver bullet syndrome Switching tools in mid-project

Design Strategies
Custom development (build from scratch) inhouse Purchase software package (and customize it) Outsource development to third party

Custom Development
Pros Cons
Requires significant time and effort May exacerbate existing backlogs May require missing skills Often costs more Often takes more calendar time Risk of project failure

Allows flexibility and creativity Consistent with existing technology and standards Builds technical skills and functional knowledge in-house

Packaged Software
Available for many common business needs Tested, proven; cost and time savings Rarely a perfect fit with business needs May allow for customization Manipulation of system parameters Changing the way features work Synchronizing with other application interfaces May require workarounds

Systems Integration
Building systems by combining packages, legacy systems, and custom pieces Integrating data is the key

Outsourcing
Hiring an external vendor, developer, or service provider May reduce costs or add value Risks include possibly
Losing confidential information Losing control over future development Losing learning opportunities

Outsourcing Contracts
Time and arrangements Fixed-price Value-added

Outsourcing Guidelines
Keep lines of communication open Define and stabilize requirements before signing the contract View the relationship as a partnership Select vendor, developer, or provider carefully Assign someone to manage the relationship Dont outsource what you dont understand Emphasize flexible requirements, long-term relationships, and short-term contracts

Selecting a Design Strategy

Consider each of the following when deciding what strategy to use:
Business need In-house experience Project skills Project management Time frame

Selecting a Design Strategy

Custom Development Business need The business need is unique In-house functional and technical experience exists Packaged System The business need is common In-house functional experience exists Outsourcing The business need is not core to the business In-house functional or technical experience does not exist Outsourcing is a strategic decision Highly skilled project manager at appropriate organizational level

In-house experience

Project skills Project management

Desire to build in-house skills Have highly skilled project manager and proven methodology

Skills are not strategic Project manager can coordinate vendors efforts

Time frame

Time frame is flexible

Time frame is short

Time frame is short or flexible

Developing an Alternative Matrix

What tools and technologies are needed for a custom development project? What vendors make products that address the project needs? What service providers would be able to build this application if outsourced?

Developing an Alternative Matrix

Combine several feasibility analyses into one matrix Include technical, budget, and organizational feasibilities Assign weights to indicate the relative importance of the criteria Assign scores to indicate how well the alternative meets the criteria

Developing an Alternative Matrix

Request for Proposals (RFP)

Solicits proposals from vendor, developer, or service provider Explains the system to be built and criteria for selecting among applicants Request for Information (RFI) -- a shorter and less detailed version

Request for Proposal Contents

Description of desired system Special technical needs or circumstances Evaluation criteria Instructions on how to respond Desired schedule Other information that will help the submitter to make a more complete or accurate proposal

Discussion
If your university were investing in an online registration system, would you recommend - Building it in-house? Buying a package? Outsourcing the project?

What is the basis for your recommendation?

MOVING FROM LOGICAL TO PHYSICAL MODELS

The second design phase after looking at design alternatives is to Convert logical process and data models into physical models. So how do we do that?

Key Definitions
Physical process models and physical data models
Show the implementation details and explain how the system will work, including
Actual, specific technology Format of information Human interaction with system

CRUD (create, read, update, delete) matrix

Technique to ensure that the data stores are associated with the right processes

The Physical DFD

Contains the same components as the logical DFD The same rules pertaining to balance and decomposition apply Contains additional details describing how the system will be built

Steps to Create the Physical DFD

Add implementation references e.g referring to a receipt by its name e.g. cash receipt Draw a human-machine boundary Add system-related data stores, data flows and processes Update data elements in the data flows Update the metadata in the CASE repository

Contrasting Logical and Physical DFDs

A Logical DFD A Physical DFD

The Physical ERD

Contains the same components as the logical ERD The same rules pertaining to cardinality and modality apply Contains additional details describing how the data will be stored, in a file or database table Additional metadata content required

Steps to Create the Physical ERD

Change entities to tables or files Change attributes to fields Add primary keys Add foreign keys Add system-related components

Example for physical ERD

The Appointment system
Six main categories
Patient Appointment Doctor Bill Payment Insurance company

Metadata Entries for a Field

The CRUD Matrix

Technique to balance the physical process and data models with each other
Process 1 Data Store A Data Store B Data Store C Data Store D Process 2 Process 3 Process 4

CRUD

R R R CRU R CRUD

Summary
The design phase is where the blueprint of the system is developed Design strategy is considered and selected from:
custom application development, buying a package and customizing it, and outsourcing.

Physical DFDs and ERDs add details about the implementation of the system to the business view The system specification compiles all the design phase deliverables to be used by the system builders