Primary List
Secondary List
Suspended
Monday, October 20, 2008
Suspended
A2: CONFIG Hybrid Simulator (CHS) - no site
A5: Reactis - has a site, needs yet another program to run it
A6: Reconciler Text Analysis Tool and Aerospace Ontology (RTATAO) - no site
A7: Requirements Assistant - site but no download/contact page is broken
B2: Defect Detection and Prevention (DDP) - no response
A5: Reactis - has a site, needs yet another program to run it
A6: Reconciler Text Analysis Tool and Aerospace Ontology (RTATAO) - no site
A7: Requirements Assistant - site but no download/contact page is broken
B2: Defect Detection and Prevention (DDP) - no response
Secondary List (Unfinished)
01. Method for Quality Assessment of Software Intensive System Architectures (QUASAR)
02. StateRover
03A. Artifact Tracking (SCARAB)
03B. Artifact Tracking (MANTIS)
04. SEMA: Software Engineering Measurement and Analysis
05. Team Software Process (TSP) and Personal Software Process (PSP)
06. SCR Test Case Generator
07. Safety Test Builder
08. Safety Checker Blockset
09. Robustness Testing of Software-Intensive Systems
10. LDRA Testbed
11. ICOSIM
12. ARRT (Advanced Risk Reduction Tool)
13. ASCT (Automated Specification Centered Testing)
02. StateRover
03A. Artifact Tracking (SCARAB)
03B. Artifact Tracking (MANTIS)
04. SEMA: Software Engineering Measurement and Analysis
05. Team Software Process (TSP) and Personal Software Process (PSP)
06. SCR Test Case Generator
07. Safety Test Builder
08. Safety Checker Blockset
09. Robustness Testing of Software-Intensive Systems
10. LDRA Testbed
11. ICOSIM
12. ARRT (Advanced Risk Reduction Tool)
13. ASCT (Automated Specification Centered Testing)
Primary List (Unfinished)
C2: Attribute Driven Design (ADD)
C4: Software Process Assurance for Complex Electronics (SPACE)
C5: Testability And Engineering Maintenance System (TEAMS)
C6: Unit Testing (CTA++)
C8: ODC Defect Analysis Technology
C4: Software Process Assurance for Complex Electronics (SPACE)
C5: Testability And Engineering Maintenance System (TEAMS)
C6: Unit Testing (CTA++)
C8: ODC Defect Analysis Technology
In Progress
A8: Software Reuse Analysis Environment (SRAE)
- in progress (Eddie)
B1: 21st Century Effort Estimator (2CEE)
- waiting for software (Aaron)
B3: Model Checking Artificial Intelligence-Based Planners (MAP)
- waiting for software (Aaron)
B5: Safety-Critical Application Development Environment (SCADE) Suite
- in progress (Aaron)
C3: ReaGeniX Programmer
- in progress(Aaron)
C7: UML Dynamic Specification
- in progress (Aaron)
- in progress (Eddie)
B1: 21st Century Effort Estimator (2CEE)
- waiting for software (Aaron)
B3: Model Checking Artificial Intelligence-Based Planners (MAP)
- waiting for software (Aaron)
B5: Safety-Critical Application Development Environment (SCADE) Suite
- in progress (Aaron)
C3: ReaGeniX Programmer
- in progress(Aaron)
C7: UML Dynamic Specification
- in progress (Aaron)
Tuesday, October 7, 2008
Quality Attributes Workshop Presentation
Quality attribute workshops (QAWs) provide a method for identifying a system’s architecture critical quality attributes, such as availability, performance, security, interoperability, and modifiability, that are derived from mission or business goals. The QAW does not assume the existence of a software architecture. It was developed to complement the Architecture Tradeoff Analysis Method® (ATAM®) in response to customer requests for a method to identify important quality attributes and clarify system requirements before there is a software architecture to which the ATAM could be applied.
In the QAW, an external team facilitates meetings between stakeholders during which scenarios representing the quality attribute requirements are generated, prioritized, and refined (i.e., adding additional details such as the participants and assets involved, the sequence of activities, and questions about quality attributes requirements). The process of refining the scenarios allows stakeholders to communicate among themselves, thereby exposing assumptions that may not have surfaced during requirements elicitation. The refinement also provides insights as to how these attributes interact, forming a basis for making tradeoffs between these attributes.
There may be more than one scenario generation workshop, depending on the number and type of organizations and stakeholders involved in the development, maintenance, or use of the system. The QAW process ends with the list of prioritized, refined scenarios. The refined scenarios can be used in different ways, for example as seed scenarios for ATAM or as test cases in an acquisition effort.
In the QAW, an external team facilitates meetings between stakeholders during which scenarios representing the quality attribute requirements are generated, prioritized, and refined (i.e., adding additional details such as the participants and assets involved, the sequence of activities, and questions about quality attributes requirements). The process of refining the scenarios allows stakeholders to communicate among themselves, thereby exposing assumptions that may not have surfaced during requirements elicitation. The refinement also provides insights as to how these attributes interact, forming a basis for making tradeoffs between these attributes.
There may be more than one scenario generation workshop, depending on the number and type of organizations and stakeholders involved in the development, maintenance, or use of the system. The QAW process ends with the list of prioritized, refined scenarios. The refined scenarios can be used in different ways, for example as seed scenarios for ATAM or as test cases in an acquisition effort.
ATAM Presentation
The SEI's Architecture Tradeoff Analysis Method® (ATAM®) is the leading method in the area of software architecture evaluation. An evaluation using the ATAM typically takes three to four days and gathers together a trained evaluation team, architects, and representatives of the architecture's various stakeholders. Proven benefits of the ATAM include
* clarified quality attribute requirements
* improved architecture documentation
* documented basis for architectural decisions
* identified risks early in the life-cycle
* increased communication among stakeholders
Business drivers and the software architecture are elicited from project decision-makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver.
The most important results are improved architectures. The output of an ATAM is an out-brief presentation and/or a written report that includes the major findings of the evaluation. These are typically:
* the architectural styles identified
* a "utility tree" - a hierarchic model of the driving architectural requirements
* the set of scenarios generated and the subset that were mapped onto the architecture
* a set of quality-attribute specific questions that were applied to the architecture
and the responses to these questions
* a set of identified risks
* a set of identified non-risks
* clarified quality attribute requirements
* improved architecture documentation
* documented basis for architectural decisions
* identified risks early in the life-cycle
* increased communication among stakeholders
Business drivers and the software architecture are elicited from project decision-makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver.
The most important results are improved architectures. The output of an ATAM is an out-brief presentation and/or a written report that includes the major findings of the evaluation. These are typically:
* the architectural styles identified
* a "utility tree" - a hierarchic model of the driving architectural requirements
* the set of scenarios generated and the subset that were mapped onto the architecture
* a set of quality-attribute specific questions that were applied to the architecture
and the responses to these questions
* a set of identified risks
* a set of identified non-risks
Views and Beyond Presentation
Model-based system engineering (MBE) lets you focus on the analysis of system architecture—and detect problems with availability, security, and timeliness early on, before they conspire to raise costs, reduce effectiveness and predictability, and shorten lifespan.
AADL Presentation
Model-based system engineering (MBE) lets you focus on the analysis of system architecture—and detect problems with availability, security, and timeliness early on, before they conspire to raise costs, reduce effectiveness and predictability, and shorten lifespan.
Java PathFinder
Java PathFinder (JPF) is a system to verify executable Java bytecode programs. In its basic form, it is a Java Virtual Machine (JVM) that is used as an explicit state software model checker, systematically exploring all potential execution paths of a program to find violations of properties like deadlocks or unhandled exceptions. Unlike traditional debuggers, JPF reports the entire execution path that leads to a defect. JPF is especially well-suited to finding hard-to-test concurrency defects in multithreaded programs.
While software model checking in theory sounds like a safe and robust verification method, reality shows that it does not scale well. To make it practical, a model checker has to employ flexible heuristics and state abstractions. JPF is unique in terms of its configurability and extensibility, and hence is a good platform to explore new ways to improve scalability.
JPF is a pure Java application that can be run either as a standalone command line tool, or embedded into systems like development environments. It was mostly developed - and is still used - at the NASA Ames Research Center. Started in 1999 as a feasibility study for software model checking, JPF has found its way into academia and industry, and has even helped detect defects in real spacecraft.
Quote from http://javapathfinder.sourceforge.net/
While software model checking in theory sounds like a safe and robust verification method, reality shows that it does not scale well. To make it practical, a model checker has to employ flexible heuristics and state abstractions. JPF is unique in terms of its configurability and extensibility, and hence is a good platform to explore new ways to improve scalability.
JPF is a pure Java application that can be run either as a standalone command line tool, or embedded into systems like development environments. It was mostly developed - and is still used - at the NASA Ames Research Center. Started in 1999 as a feasibility study for software model checking, JPF has found its way into academia and industry, and has even helped detect defects in real spacecraft.
Quote from http://javapathfinder.sourceforge.net/
PathMATE Presentation
The Engine automatically transforms PIMs defined in UML into high-performance embedded C, C++ or Java software, which shifts most development from being code-centric to being architecture-centric. By using the Engine to transform design vision into code, developers can create more features in less time. PathMATE customers measure development productivity gains of up to 40% within the first year.
Rapid RMA Presentation
RapidRMA is a scheduling analysis tool that enables designers, engineers, and system architects to build a timing model and determine if a system's timing requirements are being met. RapidRMA is intended to be used throughout the development lifecycle to validate the timing requirements of a new system before coding. When prototyping, it can be used to identify potential architecture problems and to revalidate timing requirements. On existing systems, it can be used to pinpoint potential timing problems and bottlenecks in the architecture.
STOL Presentation
A platform-independent integrated toolset based on the Eclipse IDE framework designed to assist NASA IV&V practitioners in the analysis of STOL scripts, and improve the quality and timeliness of test verification of STOL-based systems.
SAVE Presentation
The Software Architecture Visualization and Evaluation (SAVE) tool visualizes and evaluates software architectures. It extracts the software architecture from your software systems and visualize it in a powerful graphical user interface. The architecture can then be compared to a planned design.
Subscribe to:
Posts (Atom)