CS345 Exam2 (Part 2 revision)

Development Environment:

The hardware and software that are used to (design and) implement a software product

Testing Environment:

The hardware and software that are used to test (usually integration testing and system testing) a software product

Production Environment:

The hardware and software system that the user interacts with through the software product

Physical Architectures

a realization of a software product as artifacts

An Important Note regarding Physical Architectures:

A product's physical architecture is distinct from its logical architecture

Characteristics of Physical Architectures

Where is the software installed?

Where is the software executed?
Where are user configurations and data stored?

• Local device

• Central device(s)

• Hybrid

The Rare Archetypes:
Mobile Agents

• The software is stored on the user device and executed on the shared device (using data from one or the other)

• 
  The software is stored and executed on one device (either the user device or the shared device) but the user data is stored on another

Archetypal Physical Architectures
Mainframe:

The software product is installed on and executes on a central device, and is accessed from the user's device

Configuration information for each user and user data is stored on the central device

Archetypal Physical Architectures
Personal:

• The software product is "permanently" installed on the user's device (e.g., personal computer, phone, tablet) and executes on that device's processor

• If the device has multiple users, configuration information and user data are associated with each user

Archetypal Physical Architectures
Shared:

• The software product is "permanently" installed on a shared storage device but executes on the user device's processor

• Configuration information for each user and user data are stored on the user's device

Archetypal Physical Architectures
Cloud:

• The software product is temporarily delivered to the user's device and executes on that device's processor (e.g., applets, WWW apps)

• Configuration information for each user and user data is (mostly) stored "in the cloud"

Archetypal Physical Architectures
The Hybrid Architectures:

• Some components of the system (e.g., classes) may be stored/executed on one device while others might be stored executed on another

• Some data may be one one device and some data may be on another

Activities in the Deployment Process
Release:

Prepare the product for the subsequent steps (i.e., assemble the parts/resources/artifacts and create a distributable package)

Activities in the Deployment Process
Install:

Transfer the product from the development environment to the production environment

Activities in the Deployment Process
Activate:

Start all of the executable components

Activities in the Deployment Process
Deactivate:

Stop the executable components

Activities in the Deployment Process
Uninstall:

Remove the product from the production environment

Adding Updates to the Idealized Process

The Issue:

All or part of an installed product may need to updated

Adding Updates to the Idealized Process
Some Complications:

• It may or may not require deactivation and reactivation

• It is important to be able to "undo" an update and return the product to its previous state

Adding Updates to the Idealized Process
An Implication:

Design and implement with updates in mind

Purpose of Deployment Diagrams:

To model a physical architecture

Elements of a Deployment Diagram:

• Artifacts - a physical manifestation of a non-software element of a software system (e.g., files)

• Components - a software element of a software system (e.g., an application)

• Nodes - computational resources (i.e., a physical device or an execution environment such as a virtual machine)

Artifacts:

Components:

visual representation of a Node

Visual Representation of Relationships
Communication Paths:

A solid line between elements

Visual Representation of Relationships

Static Deployment:

An artifact/component is placed in a node

Visual Representation of Relationships

Dynamic Deployment:

A dependency arrow (a dashed arrow with the stereotype <<deploy>>) connects the artifact/component to the node

Deployment Diagram

Types of Support
Professional:

The person helping is employed by the provider of the software product

Types of Support
Community:

Users of the system helping others

Types of Support
Hybrid:

A community system in which the professionals participate

Methods of Providing/Delivering Support
Channels:

• Telephone

• Electronic Mail

• Chat/Messaging

• Social Network

• WWW "Forms"

Methods of Providing/Delivering Support
Interaction:

• Synchronous

• Asynchronous

Support Tracking/Management
Purpose:

Accept, prioritize, assign, track, and log requests for support

Support Tracking/Management
Common Terminology:

• Call Management System

• Ticketing System

Levels/Tiers of Support
The Concept:

Provide different levels of support services to different stakeholders (usually for different fees)

Levels/Tiers of Support
Defining Tiers:

• Hours of Support (e.g., 24/7, M-F)

• Time to Engage (e.g., within 5 minutes, same-day)

• Priority/Severity of the Request

Types of Maintenance (ISO/IEC 14764)

Corrective
Adaptive
Perfective
Preventive

Frequency (Maintenance)
Agile Processes:

Tend to deploy more frequently so maintenance activities tend to occur more frequently

Frequency (Maintenance)
Heavyweight Processes:

Tend to deploy Less frequently so maintenance is less frequent but no less significant

Why Maintenance is Expensive
Endemic Reasons:

Successful products are in the field for decades so huge costs are bound to accrue

Why Maintenance is Expensive
Other Reasons:

As a product is modified its structure deteriorates

Maintenance Tradeoffs

Related to Availability:

Maintenance improves a product but may make it unavailable

Maintenance Tradeoffs

Related to Quality:

There are often "elegant" solutions and "quick and dirty" solutions

Who is Involved in maintenance?

• The original development team

• A maintenance team