483 lines
19 KiB
Org Mode
483 lines
19 KiB
Org Mode
#+TITLE: Put the title of project here
|
|
#+AUTHOR: Rongsong Shen
|
|
#+EMAIL: shenrs@cn.ibm.com
|
|
#+OPTIONS: ^:{} H:3 LaTeX:t
|
|
#+STARTUP: showall
|
|
#+EXCLUDE_TAGS: hidden
|
|
#+LATEX_HEADER: \usepackage{tabularx,mythemes}
|
|
|
|
#+LATEX: \usetikzlibrary{calc, shapes, backgrounds}
|
|
|
|
#+BEGIN_LaTeX
|
|
\newcommand\projname{Put Project Name Here}
|
|
\newcommand\projid{}
|
|
\newcommand\productname{LSF}
|
|
\newcommand\productversion{9.2}
|
|
\newcommand\docname{\projname}
|
|
\newcommand\docversion{0.1}
|
|
\newcommand\docstatus{Under Review}
|
|
\newcommand\doctype{Functional Specification}
|
|
\newcommand\docauthor{Rongsong Shen}
|
|
\newcommand\docupdate{\today}
|
|
\newcommand\contributors{}
|
|
\newcommand\docreviewers{}
|
|
\newcommand\circulation{Confidential, for internal use only}
|
|
\newcommand\docdescription{Add description here}
|
|
#+END_LaTeX
|
|
|
|
#+BEGIN_LATEX
|
|
\begin{coverpage}{ibm-logo.png}
|
|
% BEGIN RECEIVE ORGTBL docinfo
|
|
% END RECEIVE ORGTBL docinfo
|
|
\begin{copyrightnotice}
|
|
The materials contained herein are proprietary to Platform Computing and
|
|
are presented in draft form for the purposes of your review and
|
|
comment. By providing your comments and suggestions to Platform
|
|
Computing, you acknowledge that the intellectual property rights in
|
|
these materials and in your comments and suggestions regarding the
|
|
materials shall vest in and remain the exclusive property of Platform
|
|
Computing, for use by Platform Computing in its sole discretion and
|
|
without attribution as to the source of any comments or suggestions
|
|
received. These materials are not in a final form and are not
|
|
intended to be relied upon by you and you specifically affirm that you
|
|
will not rely on any statement contained in the materials as being a
|
|
definitive position, opinion or statement of Platform Computing. The
|
|
trademarks and registered trademarks contained herein are the property
|
|
of their respective owners.
|
|
\end{copyrightnotice}
|
|
|
|
\begin{confidential}
|
|
Platform Computing Confidential
|
|
- No part of this document may be reproduced, copied or distributed
|
|
in any fashion without the express written permission of Platform Computing Corporation.\\
|
|
\end{confidential}
|
|
|
|
\end{coverpage}
|
|
\ibmpagestyle
|
|
\begin{projectinfo}
|
|
% BEGIN RECEIVE ORGTBL projectinfo
|
|
% END RECEIVE ORGTBL projectinfo
|
|
\end{projectinfo}
|
|
|
|
\begin{dochistory}
|
|
% BEGIN RECEIVE ORGTBL dochistory
|
|
% END RECEIVE ORGTBL dochistory
|
|
\end{dochistory}
|
|
#+END_LATEX
|
|
|
|
\newpage
|
|
#+LATEX: \tableofcontents
|
|
\newpage
|
|
|
|
* Hide information :hidden:
|
|
|
|
#+ORGTBL: SEND docinfo orgtbl-to-latex :splice nil :skip 0
|
|
| *Document Name:* | \docname |
|
|
| *Document Version:* | \docversion |
|
|
| *Document Status:* | \docstatus |
|
|
| *Document Type:* | \doctype |
|
|
| *Document Author:* | \docauthor |
|
|
| *Last Updated:* | \docupdate |
|
|
|
|
#+ORGTBL: SEND projectinfo orgtbl-to-latex :splice t :skip 0
|
|
|-----------------------+--------------------------|
|
|
| *Author* | \docauthor \contributors |
|
|
|-----------------------+--------------------------|
|
|
| *Reviewers* | \docreviewers |
|
|
|-----------------------+--------------------------|
|
|
| *Circulation* | \circulation |
|
|
|-----------------------+--------------------------|
|
|
| *Project Name* | \docname \projname |
|
|
|-----------------------+--------------------------|
|
|
| *Project No* | \projid |
|
|
|-----------------------+--------------------------|
|
|
| *Project Description* | \docdescription |
|
|
|-----------------------+--------------------------|
|
|
|
|
#+ORGTBL: SEND dochistory orgtbl-to-latex :splice t :skip 0
|
|
|-----+------------+------------+----------------------------|
|
|
| 0.2 | \today | \docauthor | using \TeX{}4ht to convert |
|
|
| | | | document to other formats |
|
|
|-----+------------+------------+----------------------------|
|
|
| 0.1 | Feb 2,2015 | \docauthor | Initial Version |
|
|
|-----+------------+------------+----------------------------|
|
|
|
|
* Scope
|
|
|
|
# This section shall be divided into the following paragraphs.
|
|
|
|
** Identification
|
|
|
|
# This paragraph shall contain a full identification of the system and
|
|
# the software to which this document applies, including, as applicable,
|
|
# identification number(s) and name(s), title(s), abbreviation(s),
|
|
# version number(s), and release number(s).
|
|
|
|
** System overview
|
|
|
|
# This paragraph shall briefly state the purpose of the system and the
|
|
# software to which this document applies. It shall describe the general
|
|
# nature of the system and software; summarize the history of system
|
|
# development, operation, and maintenance; identify the project sponsor,
|
|
# and developer; and list other relevant documents.
|
|
|
|
** Document overview
|
|
|
|
# This paragraph shall summarize the purpose and contents of this
|
|
# document and shall describe any security or privacy considerations
|
|
# associated with its use.
|
|
|
|
|
|
* Reference documents
|
|
|
|
# This section shall list the number, title, revision, and date of all
|
|
# documents referenced in this document (for example, internal documents
|
|
# such as functional specifications, marketing requirements documents
|
|
# and investigation reports, and external documents such as reference
|
|
# guides, user manuals, etc.).
|
|
|
|
* System-wide design decisions
|
|
|
|
# This section shall be divided into paragraphs as needed to present
|
|
# system-wide design decisions, that is, decisions about the system's
|
|
# behavioral design (how it will behave, from a user's point of view, in
|
|
# meeting its requirements, ignoring internal implementation) and other
|
|
# decisions affecting the selection and design of the components that
|
|
# make up the system. If all such decisions are explicit in the
|
|
# requirements or are deferred to the design of the software units, this
|
|
# section shall so state. Design decisions that respond to requirements
|
|
# deemed critical, such as those for safety, security, or privacy, shall
|
|
# be placed in separate subparagraphs. Design conventions needed to
|
|
# understand the design shall be presented or referenced. Examples of
|
|
# system-wide design decisions are the following:
|
|
|
|
# 1. Design decisions regarding inputs the system will accept and
|
|
# outputs it will produce, including interfaces with other systems,
|
|
# hardware, software, and users (4.3.x of this document identifies
|
|
# topics to be considered in this description).
|
|
# 2. Design decisions on system behavior in response to each input or
|
|
# condition, including actions to perform, response times and other
|
|
# performance characteristics, description of physical systems
|
|
# modelled, selected equations/algorithms/rules, and handling of
|
|
# disallowed inputs or conditions.
|
|
# 3. Design decisions on how databases/data files will appear to the
|
|
# user (4.3.x of this document identifies topics to be considered in
|
|
# this description).
|
|
# 4. Selected approach to meeting safety, security, and privacy
|
|
# requirements.
|
|
# 5. Other system-wide design decisions made in response to
|
|
# requirements, such as selected approach to providing required
|
|
# flexibility, availability, and maintainability.
|
|
|
|
* Architectural design
|
|
|
|
# This section shall be divided into the following paragraphs to
|
|
# describe the architectural design. If design information falls into
|
|
# more than one paragraph, it may be presented once and referenced from
|
|
# other paragraphs. Design conventions needed to understand the design
|
|
# shall be presented or referenced.
|
|
|
|
** Components
|
|
|
|
# This paragraph shall:
|
|
|
|
# 1. Identify the software units that make up the system.
|
|
# Note: A software unit is an element in the design of a system; for
|
|
# example, a major subdivision of a system, a component of that
|
|
# subdivision, a class, object, module, function, routine or
|
|
# database. Software units may occur at different levels of a
|
|
# hierarchy and may consist of other software units. Software units
|
|
# in the design may or may not have a one-to-one relationship with
|
|
# the code and data entities (routines, procedures, databases, data
|
|
# files, etc.) that implement them or with the computer files
|
|
# containing those entities.
|
|
|
|
# 2. Show the static (``consists of'') relationship(s) of the software
|
|
# units. Multiple relationships may be presented, depending on the
|
|
# selected software design methodology (for example, in an
|
|
# object-oriented design, this paragraph may present the class and
|
|
# object structures as well as the modules and process
|
|
# architectures).
|
|
# 3. State the purpose of each software unit and identify the
|
|
# requirements and system design decisions allocated to
|
|
# it. (Alternatively, the allocation of requirements may be provided
|
|
# in Section 5).
|
|
# 4. Identify each software unit's development status/type (such as new
|
|
# development, existing design or software to be reused as is,
|
|
# existing design or software to be reengineered, software to be
|
|
# developed for reuse, etc.) For existing design or software, the
|
|
# description shall provide identifying information, such as name,
|
|
# version, documentation references, library, etc.
|
|
# 5. Describe planned utilization of computer hardware resources (such
|
|
# as processor capacity, auxiliary storage capacity, and
|
|
# communications/network equipment capacity), if appropriate.
|
|
# 6. Identify the program library in which the software that implements
|
|
# each software unit is to be placed.
|
|
|
|
** Concept of execution
|
|
|
|
# This paragraph shall describe the concept of execution among the
|
|
# software units. It shall include diagrams and descriptions showing
|
|
# the dynamic relationship of the software units, that is, how they
|
|
# will interact during operation, including, as applicable:
|
|
|
|
# - Flow of execution control,
|
|
# - Data flow,
|
|
# - Dynamically controlled sequencing,
|
|
# - State transition diagrams,
|
|
# - Timing diagrams,
|
|
# - Priorities among units,
|
|
# - Handling of interrupts and signals,
|
|
# - Timing/sequencing relationships,
|
|
# - Exception and error handling,
|
|
# - Concurrent execution,
|
|
# - Dynamic allocation/deallocation of memory or other resources,
|
|
# - Dynamic creation/deletion of objects,
|
|
# - Processes, Tasks, and Other aspects of dynamic behavior.
|
|
|
|
** Interface design
|
|
|
|
# This paragraph shall be divided into the following subparagraphs to
|
|
# describe the interface characteristics of the software units. It
|
|
# shall include both interfaces among the software units and their
|
|
# interfaces with external entities such as systems, configuration
|
|
# items, and users. If part or all of this information is described
|
|
# elsewhere, these sources may be referenced.
|
|
|
|
*** Interface identification and diagrams
|
|
|
|
# **** Interface A
|
|
|
|
# This paragraph (beginning with 4.3.2) shall identify an interface,
|
|
# briefly identify the interfacing entities, and shall be divided into
|
|
# subparagraphs as needed to describe the interface characteristics of
|
|
# one or both the interfacing entities. If a given interfacing entity
|
|
# is not covered by this document (for example, an external system or
|
|
# user) but its interface characteristics need to be mentioned to
|
|
# describe interfacing entities that are, these characteristics shall
|
|
# be stated as assumptions or as ``When [the entity not covered] does
|
|
# this, [the entity that is covered] will ...'' This paragraph may
|
|
# reference other documents (such as data dictionaries, standards for
|
|
# protocols, and standards for user interfaces) in place of stating
|
|
# the information here. The design description shall include the
|
|
# following, as applicable, presented in any order suited to the
|
|
# information to be provided, and shall note any differences in these
|
|
# characteristics from the point of view of the interfacing entities
|
|
# (such as different expectations about the size, frequency, or other
|
|
# characteristics of data elements):
|
|
|
|
# 1. Priority assigned to the interface by interfacing entities
|
|
# 2. Type of interface (such as real-time data transfer, storage of
|
|
# data, command-line user interface, etc.) to be implemented
|
|
# 3. Characteristics of individual data elements that interfacing
|
|
# entity(ies) will provide, store, send, access, receive, etc.,
|
|
# such as:
|
|
# - Technical name (e.g., variable or field name in code or
|
|
# database), non-technical name, or other identifier
|
|
# - Data type (alphanumeric, integer, etc.)
|
|
# - Size and format
|
|
# - Units of measurement
|
|
# - Range or enumeration of possible values
|
|
# - Accuracy and precision
|
|
# - Priority, timing, frequency, volume, sequencing, and other
|
|
# constraints, such as whether the data element may be updated
|
|
# and whether business rules apply
|
|
# - Security and privacy constraints
|
|
# - Sources (setting/sending entities) and recipients
|
|
# (using/receiving entities)
|
|
|
|
# 4. Characteristics of data element assemblies (records, messages,
|
|
# files, arrays, displays, reports, etc.) that the interfacing
|
|
# entity(ies) will provide, store, send, access, receive, etc.,
|
|
# such as:
|
|
# - Technical name (e.g., record or data structure name in code or
|
|
# database), non-technical name, or other identifier
|
|
# - Data elements in the assembly and their structure (number,
|
|
# order, grouping)
|
|
# - Medium (such as disk) and structure of data elements/assemblies
|
|
# on the medium
|
|
# - Visual and auditory characteristics of displays and other
|
|
# outputs (such as colours, layouts, fonts, icons and other
|
|
# display elements, beeps, lights)
|
|
# - Relationships among assemblies, such as sorting/access
|
|
# characteristics
|
|
# - Priority, timing, frequency, volume, sequencing, and other
|
|
# constraints, such as whether the data assembly may be updated
|
|
# and whether business rules apply
|
|
# - Security and privacy constraints
|
|
# - Sources (setting/sending entities) and recipients
|
|
# (using/receiving entities)
|
|
|
|
# 5. Characteristics of communication methods that the interfacing
|
|
# entity(ies) will use for interface, such as:
|
|
# - Identifier
|
|
# - Communication links/bands/frequencies/media and their
|
|
# characteristics
|
|
# - Message formatting
|
|
# - Flow control (such as sequence numbering and buffer allocation)
|
|
# - Data transfer rate, whether periodic/aperiodic, and interval
|
|
# between transfers
|
|
# - Routing, addressing, and naming conventions
|
|
# - Transmission services, including priority and grade
|
|
# - Safety/security/privacy considerations, such as encryption,
|
|
# user authentication, compartmentalization, and auditing
|
|
|
|
# 6. Characteristics of protocols the interfacing entity(ies) will use
|
|
# for the interface, such as:
|
|
# - Identifier
|
|
# - Priority/layer of the protocol
|
|
# - Packeting, including fragmentation and reassembly, routing, and
|
|
# addressing
|
|
# - Legality checks, error control, and recovery procedures
|
|
# - Synchronization, including connection establishment,
|
|
# maintenance, termination
|
|
# - Status, identification, and other reporting features
|
|
|
|
# 7. Other characteristics
|
|
|
|
* Use case study
|
|
|
|
# Run use cases through the proposed architecture and interface design
|
|
# to see whether it addresses appropriately the quality dimensions of
|
|
# the system, such as:
|
|
|
|
# - Functionality?
|
|
# - Performance requirements or expectations?
|
|
# - System availability?
|
|
# - System operability?
|
|
# - Resource constraints and limitations?
|
|
# - Operational and data integrity?
|
|
# - Security and controls?
|
|
# - Usability?
|
|
# - Maintainability? Debugging?
|
|
|
|
# Use negative and worse cases as well.
|
|
|
|
* Performance analysis
|
|
|
|
# Analyze the performance of the proposed system, including (but not
|
|
# limited to):
|
|
|
|
# - System resource usage (CPU, Memory)
|
|
# - User query time
|
|
# - Job submission time
|
|
# - System response time
|
|
# - System throughput
|
|
# - Communication overhead, latency I/O rate
|
|
|
|
# Apply use cases (including negative and worse ones) in performance
|
|
# analysis.
|
|
|
|
* Requirement traceability
|
|
|
|
# This section shall contain:
|
|
|
|
# 1. Traceability from each software unit in this document to the
|
|
# requirements allocated to it. (Alternatively, this traceability
|
|
# may be provided in 4.1.)
|
|
|
|
# 2. Traceability from each requirement to the software units to which
|
|
# it is allocated.
|
|
|
|
* Checklist
|
|
|
|
# To avoid loose ends and ensure project quality, check the following
|
|
# questions while you start low-level design and implementation.
|
|
|
|
# - Have you run use cases against the design successfully?
|
|
# - Have you done performance analysis for the design?
|
|
# - Does the implementation consider platform-dependency (if
|
|
# applicable)?
|
|
# - Is the acceptance test plan inspected against FS?
|
|
# - Is the integrate test plan ready for inspection?
|
|
|
|
* Notes
|
|
|
|
# This section shall contain any general information that aids in
|
|
# understanding this document (e.g., background information, glossary,
|
|
# rationale). This section shall include an alphabetical listing of
|
|
# all acronyms, abbreviations, and their meanings as used in this
|
|
# document and a list of any terms and definitions needed to
|
|
# understand this document.
|
|
|
|
* Unit test plan and integration test considerations
|
|
|
|
** Unit test plan
|
|
|
|
# Document the test cases that will be used for unit
|
|
# tests. Documented test cases are important because we need them at
|
|
# least for the coverage analysis.
|
|
# *Some guidelines*
|
|
|
|
# - Can use the above LL implementation design and codes as hints to
|
|
# figure out the test cases, trying to cover all the branches and
|
|
# functions in the new changes of the project.
|
|
|
|
# - General description of how to execute the testing scnerios; not
|
|
# necessary to give the detail procedures.
|
|
|
|
# - Can use pseudo code to describe combination testing; e.g.,
|
|
|
|
# #+BEGIN_VERSE
|
|
# for Ioption = -I, -Ip
|
|
# for io = -i, -o, -e
|
|
# bsub {Ioption} {io}
|
|
# #+END_VERSE
|
|
|
|
# - Internal State Verification
|
|
|
|
# Test internal state change are correct. This may be done by
|
|
# running certain scenerios, and then dumping the data structures
|
|
# to syslog.
|
|
|
|
# - Try to give an indication of the percentage testing coverage by
|
|
# considering all the combinations, but only executing some of
|
|
# them.
|
|
|
|
** Integration test considerations
|
|
|
|
# - Scalability
|
|
|
|
# Test number of hosts, jobs, users, etc.
|
|
|
|
# - Performance
|
|
|
|
# Testcases for performance.
|
|
|
|
# - Regression
|
|
|
|
# Identify which existing regression testcases must be rerun.
|
|
|
|
# - Platform-Dependenent
|
|
|
|
# Identifiy platform specific testcases.
|
|
|
|
# - Faulty Tolerance
|
|
|
|
# Test how well the feature works under faulty conditions (e.g.,
|
|
# host crash).
|
|
|
|
# - Security
|
|
|
|
# Test any security issues related to the feature.
|
|
|
|
# - Usability
|
|
|
|
# Describe some testcases which test how user friendly the feature
|
|
# is.
|
|
|
|
* Appendixes
|
|
|
|
# Appendixes may be used to provide information published separately for
|
|
# convenience in document maintenance (e.g., charts). As applicable,
|
|
# each appendix shall be referenced in the main body of the document
|
|
# where the data would normally have been provided. Appendixes shall be
|
|
# lettered alphabetically (A, B, etc.).
|
|
|
|
|
|
# Local Variables:
|
|
# org-latex-title-command: "\\relax"
|
|
# org-latex-toc-command: "\\relax"
|
|
# End:
|
|
|