From GridLAB-D Wiki
Jump to: navigation, search

 Proposed for review 

Figure 1 - GridLAB-D Project Cycle

The planning process for Version 3.0 began in early April 2010. In contrast to previous versions of GridLAB-D, which focused on porting the prototype to open source (version 1) and demonstrating the capabilities and applications (version 2), this version will focus on achieving specific science and engineering objectives. As a result, the development process will change fairly dramatically as we formalize it to meet these new objectives.

The process is divided into 5 major phases, as shown in Figure 1. The early phases (analysis, definition, and design) involve decomposition and definition of the system design, and the later phases involve integration and validation. Throughout the process various stage gate reviews are held to ensure that the project is ready to proceed to the next stage. The reviews are as follows.

Project Acceptance Review (PAR)
This is a review of the user needs and user requirements. A preliminary analysis will be done during this review to ensure that the requirements are established and agreed to by all the parties involved. This review process is conducted by the technical contributors, the users and the product sponsors.
System Design Review (SDR)
These are reviews of the design of the modules of the system. This review will ensure that the modules meet the requirements established in the System Requirements Document, the specification in the System Module Specification, and the design in the Systems Module Design. This review process is done by the technical contributors.
Component Design Review (CDR)
These are reviews of the detailed designs of the system components. This review will ensure that the modules meet the requirements established in the System Requirements Document and the design in the Component Design Document. This review process is done by the technical contributors.
Component Readiness Review (CRR)
This is a review to check if the components are ready for integration into modules. This review also ensures the component codes meet the requirements of their respective designs. This review also determines if the components have passed their respective test cases. This review is done by the technical contributors.
Module Readiness Review (MRR)
This is a review to check if the modules are ready for integration into the application. This review also ensures the module codes meet the requirements of their system module designs. This review also determines if the modules have passed their respective test cases. This review is done by the technical contributors.
Project Approval Review (PAPR)
In this review all functionality is reviewed/examined. The review team will consist the project sponsors, the technical contributors and external experts, who have expertise on the functionality covered by the different modules. This review will help determine if the application code is readied for release to the users.


Phase A - Requirements

Figure 2 - Phase A - Requirements phase

The project begins with creating an Applications Concept Document (APPCON). The APCON gives a descriptive narrative at a conceptual level of all the uses and features of the product. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. This process is conducted by the technical teams in cooperation with the product sponsors and technical contributors (J).

The APPCON establishes the user needs. A Preliminary Engineering Needs Statement (PENS) is developed by all the concerned parties. The PENS provides a technical description of the needs of the users arising from the APPCON. This process is conducted by the technical teams in cooperation with the product sponsors and technical contributors (J).

The PENS is used to establish the initial System Requirements Document (SRD). The SRD provides a detailed statement of the requirements that are to be met by theproduct. The requirements are structured according to their authority level. ****Take from Harold's other document****. This process is conducted by the technical contributors as well as the technical teams (J).

At this stage a Requirements Traceability Matrix (RTM) is prepared based on the SRD. This process is conducted by the technical teams (P).

A requirement analysis is then performed. As a result of the requirement analysis, critical issues are identified. User requirements clarification, refining of the concepts of the application, deciding on the technologies that will drive the application, prototyping the product, and identification of any hardware constraints are all done during this phase. This process is conducted by the technical contributors as well as the technical teams (J).

At this point a Project Acceptance Review is performed. During the review, the technical team will document the critical issues identified. After the review is completed, the technical team will analyze these critical issues. At this point, new requirements are either added or old requirements are modified/deleted. Some suggested requirements may not be accepted by the technical team. Once the requirements have been modified and/or added/deleted all three requirements documents are put under revision control. These documents represent the first major milestone and establish the user requirements baseline. At this point all parties should be assured that a product which meets the clarified user requirements will satisfy the user. This review process is conducted by the technical contributors, the users and the product sponsors (J).

The next step will be to develop a System Module Specification (SMS). The SMS will be a detailed specification of all the modules in the application. It will also describe how the modules will interact/interface/communicate with each other. This document assures that all the modules of the application will satisfy the product requirements. This process is conducted by the technical contributors and technical teams (J).

Following the creation of the SMS, the System Module Design (SMD) is developed. The System Module Design specifies the detailed design of the different modules, how they interact with each other, how they interact with the hardware and other software being used by the application. The definition, design and interaction of the modules of the project is well defined in this document. This process is conducted by the technical contributors and technical teams (J).

The next milestone is the System Design Review (SDR). The SMS and SMD are reviewed at this stage. The RTM is also used and updated with the SMS and SMD mapping information. During the review, the technical team will document the areas where further changes are required. After the review is completed, the technical team will analyze these changes. At this point, new design/specifications are either added or old design/specifications are modified/deleted. Once the changes have been modified and/or added/deleted, the SMS and SMD are put under revision control. The results of this review are carried into the next phase. This review process is conducted by the technical contributors and technical teams (J).

Phase B - Design

Figure 3 - Phase B - Design phase

After the System Design Review (SDR) is completed, the results are taken to the technical teams to begin the development of the component designs. The component designs give the detailed specification and design of the all the components in each of the modules. The component designs will also specify how the different components interact/interface/communicate with each other. These designs are maintained in a series of Component Design Documents (CDD). This process is conducted by the technical teams (P).

Following the creation of the component designs, critical issues are identified. Depending on the critical issues identified, the SMS and SMD are revised and rechecked into revision control.

The Application User Document (AUD), is then developed. The AUD describes how the application concepts can be implemented. The AUD gives the users a clear understanding of how to use the various modules and components of the system to achieve their requirements from the system. This process is conducted by the technical contributors and technical teams (J).

Hardware Configuration Document (HCD) is then developed. The HCD identifies what hardware (e.g., CPU, memory, disk, network) configuration are required to perform the required functions. The HCD gives the users an understanding of the hardware requirements required for using the system. This process is conducted by the technical contributors and technical teams (J).

Software Configuration Document (SCD) is also developed. The SCD identifies what software (e.g., operation system, support applications, third-party products) are required to perform the required functions. The SCD helps the user install and gather the necessary software required for running the system. This process is conducted by the technical contributors and technical teams (J).

Coding Standards Guideline (CSG) is also developed. The CSG idetifies the coding practices that need to be followed by the team. Variable naming convention, best pratices for efficient coding, scope of variables, best pratices for component and module deveopment will be specified in this document. This process is conducted by the technical teams (P).

When all the documents are completed, a Component Design Review (CDR) is undertaken. The RTM is also used and updated with the CDDs, AUD, HCD and SCD mapping information. Any critical issues in the design of the components are identified. After the review is completed, the technical team will analyze these critical issues. At this point, new design changes are either added or old design is modified/deleted. Once the changes have been modified and/or added/deleted, the CDD's, AUD, HCD, SCD, CSG are put under revision control. The results of this review are carried into the next phase. This process is conducted by the technical contributors and technical teams (J).

Phase C - Development

Figure 4 - Phase C - Development phase

After the Component Design Review (CDR) is completed, the technical teams begin the development of the component codes. The technical teams will use the CDD's of their respective components as the basis of the code. The technical teams will use the CSG to follow the best coding pratices that are required to be followed by them.

The testing teams also take the results of the CDR to develop the component test cases. The CDD's of their respective components will form the basis of their test cases.

During the creation of the component codes or the component test cases, if any critical issues are identified in the corresponding CDD's, then the critical issues are reviewed. If the issue is found to be valid, then the respective CDD is modified.

After the completion of the component codes, the component codes will undergo a peer code review. The CDDs and CSG will form the basis for the peer code review. Issues with coding standards, less efficient code pieces, following project required coding conventions will be addressed during the peer code review. Any issues found during the peer code reviews will be documented. They will then be fixed in the corresponding component codes by the respective technical teams.

After the peer code reviews are completed, the component tests are applied to the component codes. Any issues found during testing will be documented as bugs. They will then be fixed in the corresponding component codes by the respective technical teams.

When the compment coding and component tests are completed, a Component Readiness Review (CRR) is performed. The RTM is also used and updated with the component code and component test case mapping information. The components are assessed for their readiness to be integrated into modules. Any issues identified in this phase are documented. The results are used to update the component codes and/or component test cases. After the updation, the component codes and component test cases are placed and baselined under revision control and the next phase of the project is started. This process is conducted by the technical contributors as well as the technical teams (J).

Phase D - Integration

Figure 5 - Phase D - Integration phase

After the Component Readiness Review (CRR) is completed, the technical teams begin the integration of the component codes into module codes. The technical teams will use the SMS and SMD as the basis for the component code integration. They will also use the CSG for following the best practices for code integration.

The testing teams begin the development of the module test cases. The SMS and SMD will again form the basis on which the testing teams will prepare the module test cases.

During the integration of the component codes, if any critical issues are found in the component codes, they are documented. These issues are then fixed by the corresponding technical teams. If the SMS or SMD need to be updated, that is done at this stage too.

The module tests are applied to the module codes. Any integration bugs or component level bugs found are documented. The bugs are then fixed by the corresponding technical teams.

When the module coding and module tests are completed, a Module Readiness Review (MRR) is performed. The RTM is also used and updated with the module code and module test case mapping information. The modules are evaluated against the SMS and SMD for completeness. This process is conducted by the technical contributors as well as the technical teams (J). Any issues identified in this phase are documented. The results are used to update the module codes and/or module test cases. After the updation, the module codes and module test cases are placed and baselined under revision control and the next phase of the project is started.

Phase E - Applications

Figure 6 - Phase E - Applications phase

After the Module Readiness Review (MRR) is completed, the technical teams begin to integrate the module codes into the application. The technical teams will use the APCON, PENS and AUD as the basis for the module code integration. They will also use the CSG for following the best practices for code integration.

The testing teams begin the development of the application test cases. The APCON, PENS and AUD will again form the basis on which the testing teams will prepare the application test cases.

During the integration of the module codes, if any critical issues are found in the module codes, they are documented. These issues are then fixed by the corresponding technical teams.

The application test cases are applied to the application code. Any integration bugs or module/component level bugs found are documented. The bugs are then fixed by the corresponding technical teams.

When the application coding and application test cases are completed, a Project Approval Review (PAPR) is performed. The RTM is also used and updated with the application code and application test case mapping information. All functionality is reviewed/examined. The review team will consist the project sponsors, the technical contributors and external experts, who have expertise on the functionality covered by the different modules (J). The critical issues found are documented. The results are used to update the application code. Once the code is updated and all critical issues have been fixed by the technical teams, the application code is readied for release to the users.

Acronyms

APPCON (Applications Concept Document)
The APCON gives a descriptive narrative at a conceptual level of all the uses and features of the product. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders.
PENS (Preliminary Engineering Needs Statement)
The PENS provides a technical description of the needs of the users arising from the APPCON.
SRD (System Requirements Document)
The SRD provides a detailed statement of the requirements that are to be met by theproduct. The requirements are structured according to their authority level. ****Take from Harold's other document****.
RTM (Requirements Traceability Matrix)
It is prepared based on the SRD. The RTM lists all the requirements level wise for the rows of the matrix. The columns of the matrix are the various stages at which the project would like to trace back the requirements into the artifacts/output of that stage.
PAR (Project Acceptance Review)
This is a review of the user needs and user requirements. A preliminary analysis will be done during this review to ensure that the requirements are established and agreed to by all the parties involved. This review process is conducted by the technical contributors, the users and the product sponsors.
SMS (System Module Specification)
The SMS will be a detailed specification of all the modules in the application. It will also describe how the modules will interact/interface/communicate with each other. This document assures that all the modules of the application will satisfy the product requirements.
SMD (System Module Design)
The System Module Design specifies the detailed design of the different modules, how they interact with each other, how they interact with the hardware and other software being used by the application. The definition, design and interaction of the modules of the project is well defined in this document.
SDR (System Design Review)
These are reviews of the design of the modules of the system. These reviews will ensure that the modules meet the requirements established in the System Requirements Document, the specification in the System Module Specification, and the design in the Systems Module Design.
CDD (Component Design Documents)
The component design documents give the detailed specification and design of the all the components in each of the modules. The component designs will also specify how the different components interact/interface/communicate with each other.
AUD (The Application User Document)
The AUD describes how the application concepts can be implemented. The AUD gives the users a clear understanding of how to use the various modules and components of the system to achieve their requirements from the system.
HCD (Hardware Configuration Document)
The HCD identifies what hardware (e.g., CPU, memory, disk, network) configuration are required to perform the required functions. The HCD gives the users an understanding of the hardware requirements required for using the system.
SCD (Software Configuration Document)
The SCD identifies what software (e.g., operation system, support applications, third-party products) are required to perform the required functions. The SCD helps the user install and gather the necessary software required for running the system.
CSG (Coding Standards Guideline)
The CSG idetifies the coding practices that need to be followed by the team. Variable naming convention, best pratices for efficient coding, scope of variables, best pratices for component and module deveopment will be specified in this document.
CDR (Component Design Review)
This review is for reviewing the component designs. Any critical issues in the design of the components are identified. The results of this review are carried into the next phase. This review process is conducted by the technical contributors.
CRR (Component Readiness Review)
The CRR checks if the components are ready for integration into modules. This review also ensures the component codes meet the requirements of their respective designs. This review also determines if the components have passed their respective test cases. This review is done by the technical contributors.
MRR (Module Readiness Review)
The MRR checks if the modules are ready for integration into the application. This review also ensures the module codes meet the requirements of their system module designs. This review also determines if the modules have passed their respective test cases. This review is done by the technical contributors.
PAPR (Project Approval Review)
In the PAR all functionality is reviewed/examined. The review team will consist the project sponsors, the technical contributors and external experts, who have expertise on the functionality covered by the different modules. This review will help determine if the application code is readied for release to the users.
CC (Component Codes)
The various component codes
MC (Module Codes)
The various module codes
(C)
Contributor-controlled activity - activities are performed by technical contributors and decisions are developed by technical teams, subject to appropriate reviews and approvals depending on the level of the requirement or process.
(J)
Jointly controlled activity - Activities are performed by a joint team and decisions are developed through a consensus process, subject to appropriate reviews and approvals depending on the level of the requirement or process.
(P)
Project-controlled activity - activities are performed by project managers and decisions are developed by management teams, subject to appropriate reviews and approvals depending on the level of the requirement or process.