BUS 394 - need to add topic 9

Topic 6 - 9

What phase is the system acquisition in?

• design phase = “how”

• decisions are made regarding how the system requirements will be fulfilled

• know requirements, but need to figure out how to fulfill the requirements

system acquisition key decisions

• How will we acquire/edit the new system?

→ build ourselves? buy from someone?

• What type of system will work best?

→ website? app? combo?

• What will the system look like?

→ how will it be presented.

• How will the use cases be enacted?

→ what does “the user selects the save option” mean?

the actual look of the design phase is only one small component of the design'; it’s primarily how it will function 

what is a system acquisition?

the process of determining where the new system will come from and who will provide it

2 key decisions for system acquisition

how will we acquire the new system?

• custom development: build it from scratch

• off-the-shelf purchase: purchase and customize existing system

who will do the acquiring?

• in-house (ex: building from scratch)

• outsourced to a third party

• both

Decision #1 - How to Acquire the New System

Custom Development

• more customizable

• greater control (you can control exactly how the system will look like)

Off-the-shelf purchase

• usually cheaper

• less time to acquire

• frees up staff for other projects

Decision #2: Who to Acquire

In-House

• greater control

• skill development

• usually cheaper

Outsourcing

• expertise

• usually faster (because of expertise and certain type of project)

• expanded skill repertoire (gain skill sets)

grey areas in system acquisition

• system acquisition is no longer an “either-or” proposition

• custom development:

→ can now purchase (or use freeware - aka acquiring not buying anything) software modules that can be incorporated into your custom developed system

ex: using a map on your company website

• off-the-shelf purchase:

→ new systems allow for expansive customization

→ some “packaged solutions” allow for custom coding

Ex: Salesforce

→ nearly all packaged solutions require customizing and integrating with existing systems

Off-the-shelf purchasing

packaged software has changed in recent decades

• then: individual client installations; long process to customize/install

• now: web-based solutions make purchasing much simpler

→ SaaS: “software as a service”

→ with SaaS, instead of installing software, organizations simply purchase licenses that are used for web-based applications

Ex: Gmail, Lucid Chart, Slack → not purchasing anything, you are just signing up for a license and pay advance purchasing (if not free) to use it

Sources of System Acquisition

• IT Services Firms

• Packaged software producers

      → have a specific solution in mind (experts on their solution)

• Enterprise solutions providers

• Cloud computing vendors 

      → SaaS

• Open-source software

      → lot of software open in public domain you have access for free

• In-House Developers

Outsourcing - How does it work?

key concept: contracts

in order to understand outsourcing contracts, you must understand risk

• the type and price of a contract are determined by who takes on more risk

→ the client or the contractor

2 main types of contracts

Time and Materials:

• client pays contractor by the hour, as long as they are on the project

• risk is on the client - because if they come in and do a bad job you still have to pay them for their time

Fixed Price:

• client pays contractor a fixed total amount for a solution

• risk is on the contractor - because if they do not provide the solution they are looking for, the contractor can be sued

How do clients find contractors? - 2 main ways

Requests for Proposal (RFP)

• the client sends out an RFP, detailing as much information as possible about the needs of the project

• contractors submit proposals that details why they should be selected, what they would do for the project, and how much they would charge

Prior Relationship

• many outsourcing projects are initiated based on prior projects, through existing relationships

• outsourcing has a strong sales component

key factors to choosing an acquisition strategy

how distinct are our requirements? (aka how customized does this actually need to be?)

• ex: if we need an email system & our needs are basically the same as everyone else’s’, we probably can find a packaged solution that meets our needs without having to rebuild anything

• may need if people do something a certain way

In-house resources (technology, number of people, skills, etc.)

• re-assessment of technical feasibility

• are we capable of doing it ourselves?

Availability of purchased alternatives

• may be there is nothing out there we can purchase or its so expensive its not worth purchasing

choosing an acquisition strategy: the goal

fulfill as many requirements as possible as quickly and cheaply as possible

What phase is the system architecture?

design phase

• the plan for allocating system software across client devices and/or servers

• aka “client-server architecture”

Client devices

• individual computing devices that allow for user interaction

• include desktop computers, laptops, mobile devices, voice assistants, etc.

• typically referred to as a group (ex: “clients”), rather than individually

Server

• multiple-user computers that serve clients and/or other servers

Networks

• networks connect clients with servers, to allow for client-server architectures

Basic Architectures: Client-Only

Client-Only Architecture

• all software is installed on all client devices

• no servers are utilized

• ex: notepad; Microsoft word (traditional); adobe photoshop

Basic Architectures: Server-Only

Server-Only Architecture

• no software is installed on any client devices

• software can only be accessed on a central server

• ex: secure banking systems; security systems

Client-Server Architectures

key concept: tiers

• tiers refer to clients and/or servers used in a system architecture

• all client devices count as one tier

• every additional server counts as a separate tier

How Software is Distributed: Is it divided?

software can be divided into 3 main components:

• user interface → part of the system the user is interacting with

• application → behind the scenes code that allows the system to run

• database → how to store data to use it at later points

How Software is Distributed: each component can be subdivided

• exception: the user interface is typically only on 1 device

How Software is Distributed:

• the user interface is almost always placed on client devices

• the database is almost always placed on servers

• the application software can be on clients, servers, or both

Thick Client

Thick Client: application software stored on client devices

• Rephrase: the application software is installed on client devices

• Installing on each individual client machine = thick

• Ex: Microsoft Word (OneDrive), Outlook, Slack

Thin Client

• Thin Client: application software stored on servers

• Not installed, but able to access (like a website)

• Servers are storing so multiple people can access them

• Ex: Facebook, Gmail, Microsoft Word (online)

both thin and thick are different ways clients can access applications

Why distribute systems? (5 reasons)

1. Compatibility

2. Reusability

3. Security

4. Licensing

5. Cloud

Why Distribute Systems: Compatibility

• thin client systems can work on multiple operating systems, on client devices with varying hardware specifications

Why Distribute Systems: Reusability

• Ex: 3 systems (3-tier architecture) uses 1 database → reusing databases

• instead of having data for each application you can have it spread across multiple applications

Why Distribute Systems: Security

• it is easier to secure one server than 100 client devices

• however, storing all data on one server poses its own risk

Why Distribute Systems: Licensing

• thin client systems don’t require installation

• thus, adding another user is as simple as creating a new profile in the database

Why Distribute Systems: Cloud

• a client-server architecture is effectively a cloud-based architecture

• all benefits of the cloud (portability, backups, ease of transference) apply

Selecting a system architecture

1. practical considerations

2. technical considerations

what are Practical Considerations

• client only vs thick client vs thin client

• pertains to how the user will interact with the system and how the application/database will be distributed

what are Technical considerations

• server allocation

• pertains to the efficiency and effectiveness of the architecture

Practical Considerations: Organizational alignment

consistency with the goals of the organization

Practical Considerations: User Preferences

how do you want to interact with the system and what interface or workflow you prefer.

Practical considerations: Non-functional Requirements

non-functional requirements:

• security - who has access to what?

• performance - how fast/reliable the system must be

• aesthetic/branding - system matches brandy identity

• cultural/political - system must fit internal norms/values of organization

• operational - physical/technical environment the system will be running on (ex: windows devices or mac devices)

Technical Considerations: virtualization

key concept: virtualization

• virtualization: the act of making one hardware device act as though it is two or more hardware devices

ex:

• parallels: creates a “virtual computer”

• hard drive partitioning

• server virtualization

Technical Considerations: System Architecture

• focuses on allocating software across one or more servers to maximize efficiency

• hardware selection is done at this stage

• however, because of virtualization, one server can act as multiple servers, or organizations can lease space on other servers if needed

Technical Consideration: Cloud Computing

key concept: cloud computing

• a utility computing model where organizations rent processing, storage, or networking from an external provider and pay only for what they use

Why organizations use cloud computing

• many cannot afford or manage full client-server systems; cloud computing delivers server benefits at lower cost and without heavy management

Cloud Computing Example: Fluctuating Traffic

Websites with seasonal or variable traffic can scale resources up or down depending on demand

Forms of Cloud Computing

1. Infrastructure as a Service

2. Platform as a Service

3. Software as a Service

Infrastructure as a Service

• the organization pays for hardware resources such as computing power and storage while providing and managing their own applications

Platform as a Service

the organization pays to use a platform on which they develop and run their own applications

Software as a Service

• the organization pays to use a fully developed application that is hosted and run on the cloud

What is the user interface?

the part of a system’s software that allows users to interact with the system

Interface

connection between a system and an outside entity

System Interface

One system interacting with another

User interface

A user interacting with a system

Audio user interface

interface using sound or voice commands

ex: Alexa

Haptic User interface

touch-based interface, using physical feedback

Graphical user interface (GUI)

visual interface using icons, buttons, and graphics; most common type

user centered design

Systems are not designed for generic users, they are designed for specific users

principles of user-centered design: accessibility

open to all potential users

• Ex: colorblind people cannot see certain colors

principles of user-centered design: Usability

ease/efficiency in completing tasks

principles of user-centered design: Acceptability

• degree of fit with potential users

• Don't want an amazing system but forces everyone to change their jobs (how they do it)

Usefulness vs Usability

Usefulness: value in completing tasks

Usability: ease of completing tasks

the 4 tasks of UI Design

1. understanding

2. design

3. envisionment

4. evaluation

goal of understanding phase

gather information needed to design the system effectively

Information collected in the understanding phase

• functional requirements

• non-functional requirements

• user characteristics

• organizational characteristics

what is a user persona

a research-based representation of a specific type of user used to guide design decisions

what personas should focus on

characteristics that impact user behavior, not stereotypes or irrelevant details

anti-persona

a persona representing users who are not the intended audience

3 types of user goals in personas

1. life goals

2. end goals

3. experience goals

life goals

who the user wants to be (emotional)

end goals

what the user wants to do (functional)

experience goals

how the user wants to feel (emotional)

What is a use scenario

a sequence of steps showing how a specific persona interacts with the system

goal of the design phase

determine how best to design the system

goal of envisionment

visualize the design to clarify and evaluate ideas

4 envisionment methods

1. paper sketches

2. wireframes

3. mockups

4. prototypes

interface structure diagram

a visual map of all screens and how users navigate between them (flow diagram/site map)

goal of the evaluation phase

ensure design decisions meet usability and user-centered goals

common evaluation methods

• expert evaluation

• experiments

• surveys

• comparative designs

design pattern: control

users should feel in control of their actions as much as possible

design pattern: consistency

users expect consistent appearance, behavior, and responses throughout the system

user interface patterns: safe exploration

• allow users to make mistakes safely

• ex: confirmation dialogs, undo button

user interface patterns: instant gratification

users should be able to accomplish something meaningful early

user interface patterns: satisficing

let users choose their desired level of detail

• ex: optional email field

user interface patterns: changes in midstream

allow users to make adjustments without restarting the process

user interface patterns: deferred choices

let users decide on some choices later

user interface patterns: incremental construction

users see results as they build or add items 

• ex: live shopping cart

user interface patterns: habituation

use patterns and behaviors that work everywhere else

user interface patterns: spatial memory

keep screen elements in predictable locations

user interface patterns: prospective memory

let users save items for later

• ex: draft, wish list

user interface patterns: streamlined repetition

make repeat actions faster

• ex: saved billing info

user interface patterns: interface flexibility

allow users to choose how they interact

• ex: audio or text

user interface patterns: other people’s advice

use reviews or comments to help guide user decisions

when is consistency established?

at the beginning of design, not at the end

what is a design language

a formal plan for consistent elements: colors, screen components, actions, etc.

purpose of metaphors in UI

apply real-life concepts to digital design for familiarity

• ex: shopping cart

why mobile guidelines matter

OS guidelines ensure consistency and usability across apps

Design Principles

• navigation: how the user moves throughout the system

• input: how the user inputs actions and data

• output: how the system sends information to the user

Navigation: Content Awareness

Users must know where they are in the system and how they got there

Navigation: Three-Clicks Rule

users should reach any main screen in three clicks/taps

Menu Organization Schemes

Topic, task, audience, or time-based structures

Breadcrumbs

show where the user is, how they got there, and how to move backward

goals of input design

accuracy, speed, and user experience