10. System10. System Design Design

System Analysis And Design

Program: BSCS II (Advent Semester – 2014)

Lecturer: Rebecca Asiimwe

Email: rasiimwe@technology.ucu.ac.ug1

Introduction

• The Design phase of the SDLC uses the requirements that were gathered during analysis to create a blueprint for the future system

• Purpose of analysis is to figure out business needs • Purpose of design is to decide how to build the

system• Systems design is the process or art of defining the

architecture, components, modules, interfaces, and data for a system to satisfy specified requirements

Design Phase steps

1. Present design alternatives- Alternative matrix

2. Convert logical process and data model to physical process and data model- process and data models

3. Design the architecture for the system- Architecture design

4. Make hardware and software selection- Hardware/Software specifications

5. Design the inputs and outputs of the system- Interface design

1. Design the way in which data will be stored- Data storage design

2. Design programs that will enable the process of the system- Program design

3. Create the final deliverable for the design phase- system specification: all of the above deliverables are combined and presented to approval committee

4

Step 1

• Until now we have assumed that the system will be built and implemented by the project team

• However there are three ways to approach the creation of a new system1. Developing custom application(in-house)

2. Buying a packaged system and customize

3. Relying on an external vendor, developer or service provider to build the system

• Each of these has strengths and weakness and is more appropriate in different situations

Custom Development

Team has complete control over the system looks and functionality

Good for high specialized requirementsAllows developer to be flexible and creative in a way they

solve business problemsIt builds technical skills and functional knowledge within

the company

• Long hours of working and dedication• Variety of skills have to be in place• No guarantee that the project will succeed

• Delay -technical obstacles

Packaged Software• For some it makes little sense to reinvent the wheel• Some needs can be easily met by packaged software• The packages have already been created, tested and

proven• Can be bought and installed in a relatively short period of

time• Incorporates the expertise and experience of the vendor

who created it– Must accept the function that is provided by the system

and rarely is there a perfect fit• Most allow customization and manipulation

Packaged Software

• Project teams can introduce a workaround; custom-built-add on program that interfaces with the packaged application to handle special needs.

• Workarounds are not supported by the Vendor - Incase problem, the vendor blames it on the workaround, hence no support.

Outsourcing

• Require the least amount of in-house resources

• Means hiring an external vendor, developer or service provider to create the system

• Has become popular in recent years• Used when more in-house experienced

programming and technology is required yet not available.

• Reduces costs

• Opportunity to add value to the business

• Compromises confidential information as outsiders are the ones who work on solution using company data

• Lose control over future development

• In-house professionals don’t benefit from the skills that could have been learnt

10

Outsourcing contract• There are three primary types of contracts that can be

drawn to control the outsourcing deal– Time and arrangement-Agree to pay for whatever

time and expenses that are needed to get the job done

– Fixed- price - you pay no more than expected. Incase costs exceed, then the vendor absorbs the costs

– Value added – outsourcer/vendor reaps some percentage of the completed system’s benefits

• Managing outsourcing relationship is a full time job, someone is assigned to manage this

Evaluate design strategiesWhen to use Custom Development

When to use a Packaged system

When to use Outsourcing

Business needs The business need is unique

The business need is common

The Business need is not core to the business

In- house experience In- house functional and technical experience exists

In-house functional experience exists

In-house functional or technical experience doesn’t exists

Project Skills There is a desire to build in-house skills

The skills are not strategic

The decision to outsource is a strategic decision

Project Management The project has a highly skilled project manager and a proven Methodology

The project has a project manager who can coordinate vendors effort

The project has a highly skilled project manager at the level of the organization that matches the scope of the outsourced deal

Time frame The time frame is flexible

The time frame is short

The time frame is short or flexible

Selecting a Design Strategy• Alternative matrix can be used to organize the pros and

cons of the design alternatives so that best solution will be chosen in the end.

• It’s a grid with technical, budget, and organizational feasibilities for each system candidate, pros and cons associated with adopting each solution and other information that is helpful when making comparison

• Challenge is finding the criteria, what helps is the RFP (Request for Proposal)

• RFP explains the system you are trying to build and the criteria that you will use to select the system

2. Converting logical to Physical Models

• So far Processes supporting business system have been defined by logical DFDs and ERDs that define the data used by the processes

• These models do not contain any indication of how the system will be built, they simply state what the new system will do

• Physical process models and data models are created to show implementation details and explain how the final system will work

Logical to Physical model

• Physical models;– show references to actual technology,

– format of information moving through processes

– human interaction that is involved.

Physical DFDs

• Contains same components as logical DFDs and same rules apply.

• They contain additional details that describe how the system will be built

• The conversion follows five steps– Add implementation reference– Draw a human-machine boundary– Add system-related data stores, data flows and processes– Update the data elements in the data flows– Update the metadata

Physical DFDsStep Explanation

Add implementation references Using existing logical DFD, place the way in which the data stores, data flows and processes will be implemented in parenthesis below each component

Draw a human- machine boundary Draw a line to separate the automated parts of the system from manual parts

Add system-related data stores, data flows and processes

Add these components to the model

Update the data elements in the data flow

Update to include system-related data elements

Update the metadata update to include physical characteristics

Physical ERDSteps Explanation

Change entities to tables or files

Make changes to entities, to tables to files and update metadata

Change attributes to fields Convert attributes to fields and update metadata

Add Primary key Assign primary key to all entities

Add Foreign key Add foreign keys to represent relationships among entities

Add system-related components

Add system-related tables and fields

Use Case AnalysisUse Case Analysis

19

Objectives

• Understand the role of Use cases

• Understand the process used to create Use cases

• Be able to create Use cases

Use cases

• Describe in more details the key elements of the requirement definition

• Explain the process by which the system will meet the functional requirements

• Use Cases are the main tasks performed by the users of the system.

– Use Cases describe the behavioral aspects of the system.

– They are used to identify how the system will be used.

– They are a convenient way to document the functions that the system must support.

– Use Cases are used to identify the components (classes) of the system.

 

22

• A use case is an activity a system carries out, usually in response to a user request

• A use case is an external view of the system that represents some action the user might perform in order to complete a task.

• A Use Case is functionality provided by the system, typically described as verb + object (eg. Register Car, Delete User). Use Cases are depicted with an ellipse (circle)

 

Use Case Definition

Use Case Principles

• Describes required functionality in terms of the user – system

• Identifies external actors

• Identifies system boundary

• Describes scenarios of use

• Describes pre/post conditions

• Describes variants/exceptions

24

Use Case diagram Components

1. Use cases

2. Actor

3. Association

Use Case Notation (Basic)

Use Case

Actor

Association

SystemBoundary(often implied)

26

Actors

• An actor is a person, organization, or external system that interacts with the system.

• Actors are drawn as stick figures.

Customer

27

Association

Associations are used to link Actors with Use Cases, and indicate that an Actor participates in the Use Case in some form.

Associations are depicted by a line connecting the Actor and the Use Case.

Use Case (Basic) Example

Customer

FinancialInstitution

Credit Card System

Perform Card Transaction

RetailInstitution

Process CustomerBill

Manage Account

29

Use Case usage

1. Describes the behavior of a system from a user's standpoint. Providing a high-level view of what the system does.

2. Provides functional description of a system and its major processes.

3. Provides graphic description of the users of a system and what kinds of interactions to expect within that system .

4. Identifying the users ("actors") of the system .

Building Use case

1. Identify all of the actors who will use the system.2. Interview these actors to identify the functions

that they need to perform. (use cases)3. Identify scenarios (sequence of steps to

accomplish a use case).4. Identify common steps within the different

scenarios. Separate them into different use cases so that they can easily be included in other scenarios.

5. Identify relationships between use cases.

31

One of the goals during analysis is to identify potential opportunities for reuse, a goal you can work toward as you are developing your use-case model. Potential reuse can be modeled through four generalization relationships supported by UML use-case models :

1 -  Extend dependencies between use case. 2 -    Include dependencies between use case. 3 -    Inheritance between use case. 4 -    Inheritance between actors. 

Reuse in Use-Case Model

32

The extends association is used when you have one use case that is similar to another use case but does a bit more or is more specialized; in essence, it is like a subclass

Include relationship is a situation in which one use case requires the services of a common subroutine.

Inheritance between actors means that one actor fills the same roles as another actor. It may also fill additional roles. It interacts with the same use cases in the same way, indicated by a generalization relationship.

33

<<<<IncludesIncludes>> Relationship>> Relationship

• Documents situation in which one use case requires the services of a common subroutine

• A common use case can be reused by multiple use cases

• E.g., two use cases “Create new order” and “Update order” may need to validate the customer account as shown in the use case diagram in the following slide.

34

Example of Order-Entry Subsystem with <<Includes>> Use Cases

36

Airline reservation system

Architecture DesignArchitecture Design

37

Overview

• Architecture design is very important because it describes the systems hardware, software and network environment of the to-be system.

• It flows from nonfunctional requirements;operational, performance, security, cultural and

political environment

• Deliverable is the architecture design and hardware and software specifications

38

Key Definitions

• Architecture design– Plans for how the system will be distributed

across computers and what hardware and software will be used for each computer (objective is to determine what part of application software will be assigned to what hardware)

• Hardware and software specification– Describes the hardware/software components in

detail to aid those responsible for purchasing those products.

39

ELEMENTS OF AN ARCHITECTURE DESIGN

40

Architectural Components of Software

• Data storage-– Most ISs require data to be stored and retrieved

• Data access logic- – Processing required to access stored

data( database queries)• Application logic

– Processing logic of the application (as depicted by DFDs, use cases and functional requirements)

• Presentation logic– Information display and user command processing

41

Architectural Hardware components

• Client computers• Input/output devices employed by users

• PCs, laptops, handheld devices, cell phones

• Server Computers• Larger computers storing software and hardware

that can be accessed by anyone with permission

• Mainframes, minicomputers, microcomputers

• Network• Connects computers, vary in speed (there are

slow, medium , fast and high speed networks)42

IS Architecture Choices

• Server-based Architecture

• Client-based Architecture

• Client-server based Architecture

43

Server-Based Architecture

44

Client-Based Architecture

45

Client-Server Architecture (Two-Tiered)

46

Client-Server Attributes

• Benefits– Scalable – Works with multiple

vendors/products through middleware

– Improved modularity of web-based systems

– No central point of failure

• Limitations– Complexity– New programming

languages and techniques (adds stress for personnel)

– More complex to update

47

Three-Tiered Client-Server Architecture

48

Four-Tiered Client-Server Architecture

49

N-Tiered versus 2-Tiered Client-Server Architectures

• Benefits– Separates

processing to better balance load on different servers

– More scalable

• Limitations– Greater load on

the network– More difficult to

program and test

50

CREATING AN ARCHITECTURE DESIGN

51

Selecting an Architecture Design

• Lower costs are often used to justify choice of client-server

• Recommended selection process:– Expand nonfunctional requirement details– Base architecture selection on the detailed

nonfunctional requirements

52

Operational RequirementsRequirement

Definition Example

Technical Environment

Special hardware, software, and network requirements imposed by business requirements

Always-on network connection permitting real-time database updates

System Integration

The extent to which the system will operate with other systems

The system will read and write to the main inventory database

Portability The extent to which the system will need to operate in other environments

The system may need to operate with handheld devices

Maintainability

Expected business changes to which the system should be able to adapt

The system must accommodate new manufacturing plants

Performance Requirements

Requirement

Definition Example

Speed Time within which the system must perform its function

Network transaction response time <= 7 seconds

Capacity Total and peak number of users and the volume of data expected

Maximum of 100-200 simultaneous users at peak times

Availability and Reliability

Extent to which the system will be available to the users and the permissible failure rate due to errors

99% uptime performance

Security RequirementsRequirement

Definition Example

System Value Estimates

Estimated business value of the system and its data

A complete loss of all system data would cost $20 million

Access Control

Limitations on who can access what data

Inventory changes can be made only by department managers

Encryption and Authentication

Defines what data will be encrypted where and whether authentication will be needed for user access

Data will be encrypted from the user’s computer to the Web site to provide secure ordering

Virus Control

Controls to limit viruses

All uploaded files will be checked for viruses before being saved in the system

Cultural/Political RequirementsRequirement

Definition Example

Multilingual

The language(s) the system users will need

The system will operate in English, French, and Spanish

Customization

Specification of what aspects of the system can be changed by local users

Country managers will be able to define new fields in the product database to capture country-specific information

Making Unstated Norms Explicit

Explicitly stating assumptions that differ from country to country

All weights will be stated in kilograms

Legal The laws and regulations that impose system requirements

Personal customer information cannot be transferred from European Union countries to US

Designing the Architecture

• Technical environment requirements driven by business requirements, often define the application architecture

• If not, other nonfunctional requirements become important

57

Nonfunctional Requirements and the Architecture Design

Nonfunctional Requirements and the Architecture Design

59

HARDWARE AND SOFTWARE

SPECIFICATION

60

Hardware and Software Specification

• Used if new hardware or software must be purchased

• Communicates project needs

• Actual acquisition of hardware and software usually left to a purchasing department -- especially in larger firms

61

Hardware and Software Specification

• Determine software needs– OS, special purpose– Training, warranty, maintenance, licensing

needs

• Determine hardware needs– Server(s), clients, peripherals, backup

devices, storage components– Minimum configuration needs

62

Summary

• The three fundamental computing architectures are server-based, client-based, and client-server based.

• Select architecture design based on detailed nonfunctional requirements

• Hardware and software specification documents acquisition needs

63

Q & A

64