10. System10. System Design Design
System Analysis And Design
Program: BSCS II (Advent Semester – 2014)
Lecturer: Rebecca Asiimwe
Email: [email protected]
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