support analysis for software l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Support Analysis for Software PowerPoint Presentation
Download Presentation
Support Analysis for Software

Loading in 2 Seconds...

play fullscreen
1 / 37

Support Analysis for Software - PowerPoint PPT Presentation


  • 357 Views
  • Uploaded on

Support Analysis for Software. A means to ensure software supportability. R. Somoza. ramon.somoza@software-supportability.org. The Support Analysis for Software (SAS) Process Overview Software Identification and Breakdown Categorisation of Software Supportability Analysis

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Support Analysis for Software' - Anita


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
support analysis for software

Support Analysis for Software

A means to ensure software supportability

R. Somoza

ramon.somoza@software-supportability.org

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

presentation overview
The Support Analysis for Software (SAS) Process Overview

Software Identification and Breakdown

Categorisation of Software

Supportability Analysis

The Support Concept

Interfaces to other disciplines

The SAS database

Reference Documentation

Presentation Overview

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

supportability plan and case
Supportability Plan and Case

It is convenient, in order to ensure software supportability, to frame the management of software supportability around two key components:

  • Software Supportability Plan: As part of the System Supportability Plan, it describes the activities to be undertaken in order to achieve the software supportability objectives. It also describes activities to be undertaken to demostrate achievement of those objectives
  • Software Supportability Case: A written documenation about how product supportability was verified/developed at each stage of software development as per the SW Supportability Plan

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

a process for software supportability
A Process for Software Supportability

Any process (based on the Software Supportability Plan) must achieve that the customer requirements for software supportability shall be:

  • determined
  • satisfied
  • demonstrated
  • Such a process has therefore to
  • determine those requirements
  • influence design so that supportability is built into the product
  • establish the Support Concept and ensure it is implemented
  • be itself validated

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

the response
The response:
  • A methodological process that derives supportability requirements on the basis of the support functions to be carried out:

Support Analysis for Software

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

what is sas
What is SAS?

It’s obvious:

  • A trick of the contractors to ask for more money
  • A new “geniality” of the government to waste even more money (after all, it’s just the taxpayers who pay...)
  • Both
  • Some stupid elucubration from an academic that
    • has never done such an analysis,
    • has never supported software,
    • has never talked to the victims of bad support (the poor users),
    • would not even recognize software if it were put on his dinner plate.
  • A combination of all above (remember Murphy’s Law...)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

what is sas7
What is SAS?

It is a consistent methodology that seeks the achievement of system and software supportability throughout requirements, specification and design, in order to define the most cost effective support concept that meets the operational requirements, and to ensure that the necessary support infrastructure is in place before the system enters into service.

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

goals for a sas process
Goals for a SAS Process
  • Establish supportability requirements in the early programme phases so that they can be properly addressed
  • Influence design during development in order to ensure software supportability, both for operation and modification
  • Ensure that supportability problems do not affect negatively the operation and/or the availability of the fielded system
  • Ensure all required support processes and infrastructure are properly implemented prior to entry into service
  • Reduce as far as feasible the cost of ownership
  • Be itself cost-effective (i.e, the savings and/or achieved improvements must outweigh the cost of the SAS process)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

structure for a sas process
PROGRAM PLANNING AND CONTROL

Development of an early SAS Strategy – SAS Plan

Program and Design Reviews

MISSION, DEVELOPMENT & SUPPORT SYSTEMS DEFINITION

Use Study – Technological Opportunities

Standarization – Design Factors

Comparative Analysis – Integration of ADP Systems

PREPARATION AND EVALUATION OF ALTERNATIVES

Functional and Non-Functional Requirements

Support System Alternatives – Evaluation of Alternatives & Trade-Offs

DETERMINATION OF SASR REQUIREMENTS

Operational Task Analysis

Software Exception/Problem Support Analysis (FRACAS)

Software Modification Analysis

Software Transition Analysis

Post-Deployment Software Support (PDSS)/Logistics Management Analysis

SOFTWARE SUPPORTABILITY ASSESSMENT (CASE)

Operation – Modification – Problem Reaction – Logistics Management

Lessons Learnd

Structure for a SAS Process

Project Life Cycle

Pre-Concept

Concept

Development

Post-Development

But: It is convenient to continue during the service phase!

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

outline of a sas analysis
Outline of a SAS Analysis

Software Identification & Breakdown

Use Study

Categorisation

Vendor

Support

Documentation of Support Concept, CRLCMP

Evaluation of Support Alternatives

Other Support

Options

Identification of Support Resources

Selection of Support Option

Trade-Offs

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

identification of sw within a project
Identification of SW within a Project
  • The identification/structuring of software within a project has always been a major problem.
  • One approach that has worked well (e.g., in the EF-2000 project) is the association of software to the hardware where it executes because:
    • That is the target machine
    • It is where hardware/software integration testing will be carried out
    • It is where the software will reside
  • This strategy can be made consistent with the LSA breakdown
  • This strategy, however, might not work in networks or modular avionics
  • BUT: It should be kept in mind that there are TWO different breakdowns of software, depending on the support function to be assessed:
    • Functional breakdown (i.e, how software is designed) for modification
    • Physical breakdown (i.e, the “loadable” elements) for the operation

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

functional breakdown principles
Functional Breakdown Principles
  • The “Functional” Software are all those elements that depict the functional/design aspects of interest to the software engineers
  • This is the Software that has to be considered for Modification Support
  • It is important that this breakdowns follows as closely as possible the actual software design
    • Because otherwise it will falsify your support considerations
    • Because an Audit Trail to the existing design is required
    • Because that is the starting point for support
    • Because the software documentation is structured that way
  • BUT: You can include "Dummy" Software Items to group sets of functionality that are documented as a whole or which have a separate Design, provided that:
    • Dummy Items are used to provide an additional level of abstraction
    • Dummy Items do not change the overall structure and functionality of the Design

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

functional breakdown of software

S1AB

Functional Breakdown of Software

Candidates for

Separate Software

Support are Framed

S1

S1

S1A

S1B

S1A

S1B

S1AB

(S1AA)

S1AA

S1AAB

S1AAC

S1AAD

S1AAE

S1AAF

S1ABA

S1ABE

S1AAG

S1ABC

S1ABB

S1ABD

S1AAA

S1ABE included in design of S1ABA

Notes: Shaded areas indicate complete designs (CSCIs)

CSCI Candidates are framed, Candidates for Integration in double frames, Dummy Candidate Numbers in brackets.

S1AA also includes the interfaces to the other CSCIs & acts as if it were the Top-Level Design;

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

functional breakdown perspectives

S1A

S1B

Design perspective

(Module coupling & cohesion)

Software

S1

S1

S1A

Dependencies between the different software items exist both horizontally and vertically.

S1B

Hierarchical perspective

(Functional dependencies)

S1A

S1B

Functional Breakdown Perspectives

The Software Breakdown is ONLY one of the possible views of the Software.

Support Decisions CANNOT be based

ONLY on this perspective.

Structure

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

physical breakdown principles
Physical Breakdown Principles
  • The “Physical” Software is all those elements that can be manipulated separately by the operator/user
  • This is the Software that has to be considered for Operational Support
  • Two approaches can be used here:
    • It is part of the hardware element where it is loaded
    • It is part of the hardware element where it resides
  • Similarly, several levels of breakdown can be identified:
    • System
    • Line-Replaceable Item (Computer)
    • Shop-Replaceable Item (Computer Card)
    • Component (Chip)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

physical breakdown of software

L12-L

Application SW Load

L122-S

DVI Module SW Load

L121-S

Audio Module SW Load

L121-F Audio

Firmware Load

L122-F DVI

Firmware Load

Physical Breakdown of Software

Green indicates “groups” of loadable elements

Other colors indicate individual loadable elements

L1

Comms System Load

L12 Audio Mgr.

LRI Load

L11 Transceiver

LRI Load

Loading level

L11-L

Application SW Load

LRI

SRI

L11-F

Firmware Load

Chip

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

software categorisation
Software Categorisation
  • A minimum set of information should be collected for Categorisation.
  • This information should indicate the main parameters that would affect software Support (e.g., Operational Importance, Property Rights, Frequency of Change, etc)
  • The result of the Categorisation should be a decision to:

Note that Categorisation

can be made on:

- Functional Units

- Physical Units

- Both

  • Not continue with the Analysis
  • Collect a minimum Data Set
  • Explore all possible Support Alternatives

Categorisation criteria are important!

Too much analysis

(expensive)

Too little analysis

(lousy support)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

selection of sas candidates
Selection of SAS Candidates
  • SAS Candidates are elements which are going to be subject to some kind of supportability analysis
  • SAS Candidates should be selected on the basis of their operational or supportability significance
  • Three types of distinct SAS Candidates should be selected:
    • Functional Software Elements
    • Physical Software Elements
    • Data
  • Each of these has its own characteristics and different supportability problems

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

selection of functional candidates
Selection of Functional Candidates
  • Inherent Candidates:
    • The Item that includes all Software in the System and/or LRI
    • All Items (CSCIs) that have a separate Design
    • All intermediate Items between the CSCIs and the Top-Level CSCI at which Integration is performed
  • Potential Candidates: All Support Anomalies such as
    • Software Items requiring special hardware or software tools
    • Software Items of different risk classes than the software where they are embedded
    • Proprietary software, such as Run-Time Libraries or COTS Software
    • Software Items that have different versions for use of the parent software on different platforms (e.g., different I/O handlers, so that the Software can run both on an A/C and on the Flight Simulator)
    • Different programming languages (specially weird ones)
    • Deviations to the Design Environment
    • Reused Software

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

selection of physical candidates
Selection of Physical Candidates
  • For Software:
    • All software executables that can be loaded and/or installed separately or that require different loading/installation tasks
    • All groups of the above that are loaded/installed together in one single operation
  • For Data:
    • All databases
    • All data blocks (e.g., mission data) that:
      • Are manipulated as a single entity
      • Require specific software for creation, manipulation or evaluation (e.g., post-flight analysis)
      • Are installed, loaded or unloaded by means of a specific task

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

function oriented supportability analysis
Function-oriented Supportability Analysis
  • It is convenient to carry out the Supportability Analysis from the point of view of the support functions that have to be carried out, and not from the point view of the product
  • When considering the functions (e.g., modify software, operate software), it is much easier to determine the necessary tasks, as well as those aspects that will simplify those tasks (e.g., software modularity helps modification, installation requires a loading device)
  • A first assessment of those tasks early in the development cycle will be useful to determine the software supportability requirements and objectives
  • But: software supportability in only one of the system supportability parameters, and should be always assessed in this context

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

analysis for modification support
Analysis for Modification Support
  • The Analysis for Modification Support should be based both on the software to be modified and the tasks to be carried out to make that modification.
  • The first step should use a set of standard tasks (say, from IEEE 1219, ISO 12207, MIL-STD-498 or equivalent).
  • The standard tasks can be usually related to a specific hierarchical level within the software.
  • A cost or effort estimation tool (e.g., COCOMO) can provide the effort for the modification task. On the basis of existing metrics or software engineering studies, this effort can be statistically distributed over the different tasks.
  • The next step consists of identifying the support elements required to carry out those tasks. The use of those elements usually can be derived from the effort and duration of the tasks.

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

determination of effort
Determination of Effort
  • A cost-estimation tool is used to determine the effort, manpower and duration for each phase of a typical modification
  • This is adjusted to the number of annual changes
  • The resulting value, with minor adjustment, can be considered to be the “use” of the necessary support resources.

Image courtesy of Price Systems

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

determination of support resources
Determination of Support Resources
  • Each Support Task might require specific Support Resources to be carried out
  • These Resources might require, on their turn, other Resources

Ada Program

Coding

Program Design

Ada Compiler

Host Computer

Operating System

Ada Programmer

User Manuals

Program Source Code

Training in Ada

Ada LRM

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

trade offs
Trade-offs

There are tools that permit to consider different support alternatives and assess the most adequate one:

  • Effort
  • Cost of Ownership
  • Response Times

Trade-Offs are simulated by

creating a Support Environment

with all its parameters and then comparing:

  • Operational Impact
  • Required Investment
  • Technological interests

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

analysis for operational support
Analysis for Operational Support
  • Unfortunately, there are no standards for Operational Support from which a set of standard tasks could be derived
  • One practical approach is to derive a set of Support Initiators, that is, a set of events that might affect software
  • These Support Initiators result in a process to be modeled, from which resources can then be identified
  • It is convenient that this is harmonised with the LSA Process, as many of the Support Initiators can be identified through FMECA. Tools used for LORA can often be also used for this purpose
  • Typical Support Initiators include:
    • New software release / new firmware
    • Repair of computing hardware
    • Corruption of data or executable code (including virus infection)
    • System/Software failure
    • New system mission (with change of software and/or mission data)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

operational support issues
Operational Support Issues
  • Supportability decisions might have severe operational impact. Some examples:
    • Where is software loaded? (increases spares or response time)
    • Are computers stored with or without software? (configuration control, response times)
    • How many software versions/variants are at each site? (config.)
    • How do you ship computers containing classified software for repair? (security problem)
    • Is the bootstrap loader loadable? (might be fun if power goes away while loading it!)
    • Do you need to test after loading? (safety issues)
    • Can you actually shut down the system to install new software?
    • What do you do if the safety-critical software has a problem?

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

analysis for logistics management
Analysis for Logistics Management
  • There are no standards either for Logistics Management Support from which a set of standard tasks could be derived
  • Tasks can be identified by modelling the Logistics Management functions or by using a set of Support Initiators as triggers for the process to be carried out
  • Typical Logistics Management Support functions include:
    • Problem reporting and corrective actions
    • System/software configuration control
    • Packaging
    • Distribution
    • Installation and checkout
    • User Support (including help desk, technical representatives)
  • Process modelling tools can be used to determine support effectivity
  • The classic Integrated Logistic Support (ILS) aspects such as Training, Technical Publications, etc, should be also covered here.

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

data support
Data Support
  • Data Support is often neglected despite the fact that it often is critical to mission achievement
  • It is, by its mainly electronic nature, often handled in a similar way as software, with which it has a strong dependency
  • In this context, it is convenient to analyze its support together with that of the software (though not in the same way)
  • Support aspects to be considered include:
    • Data preparation software and hardware
    • Need for validation
    • Media, transmission networks, security aspects
    • Usage (e.g. by other programs, or other computers)
    • Loading/unloading process and/or tools
    • Compatibility aspects (e.g., with software, or certain system configurations)
    • Size, data formats

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

establishment of the support concept crlcmp
Establishment of the Support Concept, CRLCMP
  • The Support Concept provides the global view about how the Software Support will addressed
  • It is coherent - Activities related to different support functions are grouped into processes, which themselves are grouped in accordance with the location (level) and the people (agents) involved, for each software product and all resources and facilities that are available for support purposes.
  • This overall concept is then described in the Computer Resources Life-Cycle Management Plan (CRLCMP)

Support Classes

Processes

Product

Environment

Modification

Levels

Logistics Managment

Operation

Agents

Activities

Support Functions

Support Profile

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

supportability case
Supportability CASE
  • The Supportability CASE is demonstrated by:
    • Quantitative Evidence
    • Qualitative Evidence
    • Historical or Comparative Evidence
  • This demonstration can be also achieved by means of:
    • The reports generated from the SASR
    • The CRLCMP

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

interfaces to other disciplines
Interfaces to other disciplines
  • SAS has also a link to the classic ILS disciplines, to which it issues requirements for Training, Support Equipment and Support Software, Technical Publications, Facilities, etc., in a similar way as LSA
  • The Link to LSA is established through the “Physical Software” breakdown and its relationship with the hardware
  • It is convenient that LSA (if carried out) documents the SAS results for the Operational Support, so that all operational matters are stored together
  • The link to RM&T is also only for operational purposes - RM&T for Software Modification is carried out as part of the SAS Analysis
  • The link to Engineering is through the software design. It is convenient that SAS participates as part of an Integrated Project Team (IPT), or at least as a reviewer during the whole software design.

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

interface to lsa
Interface to LSA

The LSAR and SASR should be linked, in order to obtain overall system consistency and ensure system supportability

The link are the loadable elements and their associated hardware

LSA and SAS have to collaborate in this context, so as to ensure that no incompatible support decisions are taken:

(e.g., incompatible loading levels after HW repair and after SW update)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

the sas database sasr
The SAS Database (SASR)

Though often disconsidered in the Supportability Analysis, the use of a database for all software supportability information is of great importance since:

  • It provides a single master data repository for all software related information (everybody works on the basis of the same data)
  • It integrates such information from multiples sources, for all software in one single system or across multiple related systems
  • It provides an overview of all required support resources, thus making it easier to identify commonalities or consider combined support
  • It can be queried to seek out specific information, such as software metrics, system load, deviations....
  • It can be linked to software engineering tools or information, as well as to logistics-related information (the LSAR)

However: There is no standard for such a database and the LSAR cannot be used for this purpose

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

simplified relational graph of sasr

Software-Specific Information

<SW, Tasks>

<SW,Tasks,Resources, Training>

<SW, Tasks, Resources>

Simplified Relational Graph of SASR

Support Tasks

Host Hardware

Support Resources

Equipment

Facilities

Staff

Training

Software

Publications

Media

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

conclusions
Conclusions
  • A Supportability Analysis can be carried out in a similar way as the LSA Process (but don’t try to use MIL-STD-1388!)
  • It is not specially difficult, but it is convenient that it is done by a mix of software engineers and logisticians
  • Critical to this is the establishment of a software Supportability Plan in the early programme phases
  • Not only support can benefit from this approach, even the design process might be optimized because of it
  • The Supportability Case prevents that supportability is killed due to schedule or cost constraints - it is a contractual requirement!

But it should be always kept in mind:

  • Supportability for its own sake is a waste of money!

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT

some reference documentation
Some Reference Documentation
  • DEF STAN 00-60, “Integrated Logistic Support”, Issue 2, October 1996, Part 3: “Logistic Support Analysis Application to Software Aspects of Systems”
  • SAE Standard JA1004 (Draft), “Software Supportability Program Standard”, in SAE Ballot
  • MIL-HDBK-347, “Mission-Critical Computer Resources Support”, May 1990
  • SAE Aerospace Information Report AIR5121, “Software Supportability - An Overview”, January 1997
  • SAE Report JA1006 (Draft), “Software Support Concept”, in SAE Ballot
  • SAE Recommended Practice JA1005, “Software Supportability Implementation Guide” (Draft)
  • Software Logistics Planning Handbook, US Army, CECOM, October 1995
  • ISO Standard 12207, “Information Technology - Software Life Cycle Processes”,

August 1995

  • IEEE Standard 1219, “IEEE Standard for Software Maintenance”, June 1993
  • MIL-STD-498, “Software Development and Documentation”, December 1994
  • SAE G-11 Software Committtee Homepage (http://www.sae.org/TECHCMTE/g11soft.htm)
  • DEF STAN 00-60 Homepage (http://www.demon.co.uk/ilsuk.html)

DLCSPM - Canadian Software Support Seminar - April 1998 - DAPSCT