2.1 Organization
2.1.1 Project Organization
2.1.1 Project Organization
Figure 1 LaSRS++ Project Organization
Figure 1 illustrates the basic organizational structure for all simulation projects. The organizations identi-fied here have active involvement in all simulation projects and are the only organizations upon which this plan places primary configuration management responsibility. Two organizations play major roles in the development of simulation projects. The Simulation Systems Branch (SSB) is responsible for flight simulation at LaRC. Flight Simulation Support Services (FSSS) contractors develop the research simula-tions. Some projects may support LaRC-wide projects or cooperative projects with the aviation industry or the military. These projects will have additional organizations involved. Project CMPs must identify those organizations in this section and explain any role they will assume in the SCM process.
A number of FSSS individuals contribute to the simulation project’s development. FSSS management, which consists of the FSSS Program Manager and FSSS Project Manager, allocates resources to simulation projects and oversees that projects meet customer needs. The FSSS Project Manager creates the project development team. He selects the Project Leader (PL) and assigns developers to the project. The PL heads each simulation project. The PL has primary responsibility for the project’s development and is the CCB Chairman. The project developers create the simulation software; they are also members of the proj-ect CCB.
The LaSRS++ Architecture Team (LAT) guides the evolution of the LaSRS++ project. LaSRS++ is an object-oriented framework designed for rapid development of simulation projects. LAT members are FSSS simulation developers with experience creating object-oriented software. Members are chosen by the LaSRS++ Project Leader. More information about the group and its activities can be found in the Configuration Management Plan for the Langley Standard Real-Time Simulation in C++ (LaSRS++) and the LaSRS++ Software Development Plan. The FSSS Project Manager assigns a LAT member to each simulation project as an Architecture Consultant (AC). The AC helps the simulation project achieve effi-cient use of the LaSRS++ framework and identifies project-specific designs which could be migrated to the framework. The AC is most active during the design process; they do not actively participate in the other stages of development (unless they are also an assigned developer to the project).
The NASA organizations most involved in simulation projects are the Simulation Systems Branch (SSB) and the “research community”. SSB establishes and monitors the simulation projects. SSB is managed by a branch head and an assistant branch head. SSB is supported by the FSSS contract. SSB must authorize all labor and expenditures related to a simulation project. SSB management selects an individual, called a “Facilitator”, to be a liaison between the simulation developers and the simulation customers. The Facili-tator is a member of the Project CCB. The Facilitator performs the functional configuration audits (FCA) (see section 3.4.2) and approves the physical configuration audit (PCA) (see section 3.4.4). The “research community” encompasses all NASA civil servants that use the simulation facilities for research purposes. These organizations are direct customers of simulation projects; thus, they have an interest in its evolution and success.
2.1.2 Software Configuration Management Organization
Figure 1 illustrates the basic organizational structure for all simulation projects. The organizations identi-fied here have active involvement in all simulation projects and are the only organizations upon which this plan places primary configuration management responsibility. Two organizations play major roles in the development of simulation projects. The Simulation Systems Branch (SSB) is responsible for flight simulation at LaRC. Flight Simulation Support Services (FSSS) contractors develop the research simula-tions. Some projects may support LaRC-wide projects or cooperative projects with the aviation industry or the military. These projects will have additional organizations involved. Project CMPs must identify those organizations in this section and explain any role they will assume in the SCM process.
A number of FSSS individuals contribute to the simulation project’s development. FSSS management, which consists of the FSSS Program Manager and FSSS Project Manager, allocates resources to simulation projects and oversees that projects meet customer needs. The FSSS Project Manager creates the project development team. He selects the Project Leader (PL) and assigns developers to the project. The PL heads each simulation project. The PL has primary responsibility for the project’s development and is the CCB Chairman. The project developers create the simulation software; they are also members of the proj-ect CCB.
The LaSRS++ Architecture Team (LAT) guides the evolution of the LaSRS++ project. LaSRS++ is an object-oriented framework designed for rapid development of simulation projects. LAT members are FSSS simulation developers with experience creating object-oriented software. Members are chosen by the LaSRS++ Project Leader. More information about the group and its activities can be found in the Configuration Management Plan for the Langley Standard Real-Time Simulation in C++ (LaSRS++) and the LaSRS++ Software Development Plan. The FSSS Project Manager assigns a LAT member to each simulation project as an Architecture Consultant (AC). The AC helps the simulation project achieve effi-cient use of the LaSRS++ framework and identifies project-specific designs which could be migrated to the framework. The AC is most active during the design process; they do not actively participate in the other stages of development (unless they are also an assigned developer to the project).
The NASA organizations most involved in simulation projects are the Simulation Systems Branch (SSB) and the “research community”. SSB establishes and monitors the simulation projects. SSB is managed by a branch head and an assistant branch head. SSB is supported by the FSSS contract. SSB must authorize all labor and expenditures related to a simulation project. SSB management selects an individual, called a “Facilitator”, to be a liaison between the simulation developers and the simulation customers. The Facili-tator is a member of the Project CCB. The Facilitator performs the functional configuration audits (FCA) (see section 3.4.2) and approves the physical configuration audit (PCA) (see section 3.4.4). The “research community” encompasses all NASA civil servants that use the simulation facilities for research purposes. These organizations are direct customers of simulation projects; thus, they have an interest in its evolution and success.
2.1.2 Software Configuration Management Organization
Figure 2 SCM Organization
Figure 2 displays the minimum SCM organization involved in simulation projects. The organization is a hierarchy of configuration control boards (CCBs). The Simulation Systems CCB controls changes to COTS software used for all simulation development; it rules on change requests which affect both simula-tion software and hardware and approves simulation project requests (SPRs). The SSB Branch Head or his designee chairs the Simulation Systems CCB. The Simulation Systems Configuration Management Plan defines the Simulation Systems CCB and its activities. The LaSRS++ CCB governs the development of the LaSRS++ application framework upon which all simulations are built. It actively monitors simula-tion projects for framework enhancements. The LaSRS++ Project Leader chairs the LaSRS++ CCB. The Configuration Management Plan for the Langley Standard Real-Time Simulation in C++ (LaSRS++) de-fines the LaSRS++ CCB and its activities. The Project CCB controls project software, most of which will be built on top of LaSRS++. The Project Leader is the CCB Chairman. The remainder of this CMPT describes the membership and basic activities of Project CCBs. If a project must interact with outside CM organizations, the project CMP will acknowledge them in this section. The project CMP will summarize their scope of authority and refer the reader to documents which detail their membership and activities.
2.2 SCM Roles and Responsibilities
Project success relies on good communication between FSSS contractors and NASA. This plan facilitates efficient communication required to approve and implement changes by clearly defining the role each organization plays in the CM process. Table 1 provides a visual matrix of the responsibilities that each role is assigned for a given activity. A description of each activity, responsibility, and role follows the matrix. Project CMPs which add SCM activities or roles will summarize them in this section using the same matrix/description format. The project CMP will assign its new activities to one or more roles with an elaboration of the role’s responsibilities within the activity. The project CMP will assign new roles to members of the project organization it presents in section 2.1.1.
Table 1 Responsibility Assignments for Project SCM Activities
Roles
————————
Activities CCB Chairman Project CCB SSB Facilitator FSSS Management SSB Management Architecture
Consultant Simulation Customers
Change Request Submit
Review
Approve Submit
Review Submit
Review
Submit
Appeal Submit
Appeal Submit
Review Submit
Change Implementation Perform
Review
Approve Perform
Review Review Assign Authorize
Change Control Enforce
Perform Perform Enforce
Configuration Identification Perform
Approve Perform
Documentation Perform
Approve
Maintain Perform
Maintain
Status Accounting Perform Perform
Audits & Reviews Perform
Approve Perform Perform
Approve Perform
Approve
2.2.1 Activity Definitions
Change Requests – CRs represent either the identification of CI defects or a request for enhancement of a configuration item. CRs for simulation projects are written (submitted), reviewed, approved, and sometimes appealed (see section 3.2 and Appendix A).
Change Implementation – Once a CR is approved and SSB has authorized work on behalf of it, imple-mentation of the requested change is assigned to a group or individual (see section 3.2.6 and the LaSRS++ Software Development Plan).
Change Control – Changes cannot be introduced without approval. Each change will be screened to verify that it implements only an approved CR (see section 3.2.6).
Configuration Identification – Items (software, documentation, and resources) under control of the plan must be identified and named (see section 3.1).
Documentation – Documentation encompasses any text generated in support of a simulation project. It includes but is not limited to design documents, source code documentation, test reports, CRs, status accounting reports, and audit reports.
Status Accounting – Status accounting gathers and reports information concerning the tracking of CRs, change implementation, and CI contents (see section 3.3).
Audits & Reviews – Audits and reviews verify that LaSRS++ CIs contain all and only all changes from closed CRs, that they adhere to LaSRS++ standards, that the framework matches its documentation, and that any distribution of the framework is complete (see section 3.4).
2.2.2 Responsibility Definitions
Approve – The organization/individual approves requests for an activity and/or its results. More than one approval may be needed. This responsibility may be delegated temporarily or permanently to another individual within the same project organization.
Assign – The organization/individual is responsible for assigning the activity to a developer. This respon-sibility may be delegated temporarily or permanently to another individual within the same project organization.
Authorize – The organization/individual authorizes resource expenditures for the activity. This responsi-bility may be delegated temporarily or permanently to another individual within the same project or-ganization.
Enforce – The organization/individual is responsible for exacting compliance with all policies regarding the activity.
Maintain – The organization is responsible for upkeep of products associated with the activity.
Perform – The organization is responsible for carrying out the activity.
Review – The organization is responsible for examining products required by an activity for completeness, correctness, and clarity. This organization may also be responsible for identifying missing informa-tion.
Submit – The organization/individual can submit a CR.
2.2.3 Role Definitions
2.2.3.1 The Simulation Project CCB
The configuration control board (CCB) for a simulation project has primary responsibility for reviewing, approving, and assigning changes to the project’s requirements and products. The Project CCB shall in-clude the Project Leader (PL), the SSB Facilitator, and all developers assigned to the project. The PL is the CCB Chairman. The FSSS Project Manager selects the PL. The FSSS Project Manager also assigns the developers to the project. SSB Management selects the Facilitator. One FSSS CCB member administers the CR database and is given the role of CCB Secretary. One FSSS CCB member administers the simulation project’s CI repositories; he is given the title of CCB Librarian. All CCB members are technical analysts who review change requests. CCB members perform the following CM activities:
• Implement approved changes.
• Review approved changes. According to the LaSRS++ Software Development Plan, all class designs must undergo review and all source code changes are subject to a code walk-through. During these reviews, CCB members shall verify that only the requested change is being made and that it has been implemented according to LaSRS++ standards.
• Create or amend required documents.
2.2.3.1.1 CCB Chairman
The CCB Chairman has the following responsibilities:
• Authority to approve change requests.
• Determines when sufficient information is available to make the approval decision.
• Decides whether a CR review requires a formal meeting of the CCB or an informal discussion with some CCB members.
• Selects the CCB Secretary and the CCB Librarian.
• Approves code reviews and the PCA (see section 3.4).
2.2.3.1.2 CCB Secretary
The CCB Secretary has the following responsibilities:
• Administer the CR database, performing periodic maintenance and coordinating new custo-mizations.
• Verify that all CRs are complete and properly submitted before promoting them to review (see section 3.2).
• Deliver implementation assignments for approved CRs (see section 3.2.6).
• Verify that CRs are complete with proper authorization before closing them (see section 3.2.8).
• Produce all configuration status accounting reports (see section 3.4).
• Prepares agenda and records minutes for the formal CCB meetings.
The Configuration Management Procedures for Simulation Projects further elaborates the responsibilities of the CCB Secretary.
2.2.3.1.3 CCB Librarian
The CCB Librarian has the following responsibilities:
• Administer the project’s CI repositories, performing periodic maintenance and coordinating minor customizations.
• Give CR implementors write access to the repository.
• Ensures that only reviewed and tested changes become visible to other simulation developers (see section 3.2.8).
• Define each new release of a project CI (see section 3.1.2).
• Create repositories for new CIs (see section 3.1.3).
The Configuration Management Procedures for Simulation Projects further elaborates the responsibilities of the CCB Librarian.
2.2.3.2 Simulation Customers
A simulation customer is anyone represented by the organizations in Figure 1 who is not directly involved in the development of the project. Usually, these are members of the “research community”. The simula-tion customer can freely submit CRs to the Project CCB. Simulation customers are also invited to partici-pate in the project FCAs (see section 3.4.2). One simulation customer is designated as the ‘Principal In-vestigator’. The Principal Investigator has the authority to approve the FCA (i.e., accept the simulation product) on behalf of all customers.
2.2.3.3 Architecture Consultant (AC)
The AC, a LAT member, attends all design reviews and examines CRs which add enhancements to a project. The AC aids simulation projects in maximizing reuse of the LaSRS++ framework. The AC iden-tifies new simulation features which would benefit the LaSRS++ framework. If the AC determines that a project feature shall be moved into the framework, he will submit a CR to the LaSRS++ CCB. If the CR is approved, authority for the identified feature will be handed to the LaSRS++ CCB and its physical storage (if any) will be moved into a LaSRS++ CI repository.
2.2.3.4 FSSS Management
The FSSS Management consists of the FSSS Program Manager and the FSSS Project Manger. They can submit CRs to the project’s CCB. They assist the CCB in enforcing change control procedures through their support of the CM process. They resolve appeals on CRs which were submitted by FSSS contractors (see section 3.2.5). FSSS Management also approves in-process audits (see section 3.4.3).
2.2.3.5 SSB Management
SSB Management consists of the Branch Head and Assistant Branch Head. SSB Management can submit CRs to the project’s CCB. SSB Management resolves appeals on CRs submitted by simulation customers (see section 3.2.5). SSB Management authorizes work done on behalf of any approved CR (see section 3.2.6); this authority can be shared with no more than two SSB civil servants, for all projects. SSB management approves PCAs for products delivered to a third party (see section 3.4.4). SSB management can initiate an in-process audit and approve the results (see section 3.4.3).
2.2.3.6 SSB Facilitator
SSB Management selects a ‘Facilitator’ for each project. The SSB Facilitator is a liaison between the de-velopment group and the simulation customers. They act on behalf of the customers’ interests. This is most apparent in their responsibility to conduct the functional configuration audit (FCA) of the simulation product. The FCA embodies the process of accepting the simulation product for production. The Facilita-tor also represents the simulation customers on the CCB.
2.3 Applicable Policies, Directives, and Procedures
In addition to the CM policies detailed in this document, the following external standards and procedures apply for the duration of the project:
• The Simulation Project Configuration Management Procedures details how SCM software is used in support of this plan.
• The LaSRS++ Programmer’s Guide, which specifies stylistic and programming conventions, shall be followed for all source code written as part of a LaSRS++ CI. These guidelines in-clude but are not restricted to source code file names, variable names, structured code for-matting, and class design restrictions. The guide’s purpose is to ensure uniform looking code that is readable and avoids dangerous language idioms. Code changes shall not be accepted unless they conform with this document.
• The LaSRS++ Software Development Plan discusses the software lifecycle and proper testing procedures. All directives in this plan must be adhered to before a code change is accepted.
If the project has any other documented policies that affect SCM activities (e.g., security plans), they will be listed here.
Figure 2 displays the minimum SCM organization involved in simulation projects. The organization is a hierarchy of configuration control boards (CCBs). The Simulation Systems CCB controls changes to COTS software used for all simulation development; it rules on change requests which affect both simula-tion software and hardware and approves simulation project requests (SPRs). The SSB Branch Head or his designee chairs the Simulation Systems CCB. The Simulation Systems Configuration Management Plan defines the Simulation Systems CCB and its activities. The LaSRS++ CCB governs the development of the LaSRS++ application framework upon which all simulations are built. It actively monitors simula-tion projects for framework enhancements. The LaSRS++ Project Leader chairs the LaSRS++ CCB. The Configuration Management Plan for the Langley Standard Real-Time Simulation in C++ (LaSRS++) de-fines the LaSRS++ CCB and its activities. The Project CCB controls project software, most of which will be built on top of LaSRS++. The Project Leader is the CCB Chairman. The remainder of this CMPT describes the membership and basic activities of Project CCBs. If a project must interact with outside CM organizations, the project CMP will acknowledge them in this section. The project CMP will summarize their scope of authority and refer the reader to documents which detail their membership and activities.
2.2 SCM Roles and Responsibilities
Project success relies on good communication between FSSS contractors and NASA. This plan facilitates efficient communication required to approve and implement changes by clearly defining the role each organization plays in the CM process. Table 1 provides a visual matrix of the responsibilities that each role is assigned for a given activity. A description of each activity, responsibility, and role follows the matrix. Project CMPs which add SCM activities or roles will summarize them in this section using the same matrix/description format. The project CMP will assign its new activities to one or more roles with an elaboration of the role’s responsibilities within the activity. The project CMP will assign new roles to members of the project organization it presents in section 2.1.1.
Table 1 Responsibility Assignments for Project SCM Activities
Roles
————————
Activities CCB Chairman Project CCB SSB Facilitator FSSS Management SSB Management Architecture
Consultant Simulation Customers
Change Request Submit
Review
Approve Submit
Review Submit
Review
Submit
Appeal Submit
Appeal Submit
Review Submit
Change Implementation Perform
Review
Approve Perform
Review Review Assign Authorize
Change Control Enforce
Perform Perform Enforce
Configuration Identification Perform
Approve Perform
Documentation Perform
Approve
Maintain Perform
Maintain
Status Accounting Perform Perform
Audits & Reviews Perform
Approve Perform Perform
Approve Perform
Approve
2.2.1 Activity Definitions
Change Requests – CRs represent either the identification of CI defects or a request for enhancement of a configuration item. CRs for simulation projects are written (submitted), reviewed, approved, and sometimes appealed (see section 3.2 and Appendix A).
Change Implementation – Once a CR is approved and SSB has authorized work on behalf of it, imple-mentation of the requested change is assigned to a group or individual (see section 3.2.6 and the LaSRS++ Software Development Plan).
Change Control – Changes cannot be introduced without approval. Each change will be screened to verify that it implements only an approved CR (see section 3.2.6).
Configuration Identification – Items (software, documentation, and resources) under control of the plan must be identified and named (see section 3.1).
Documentation – Documentation encompasses any text generated in support of a simulation project. It includes but is not limited to design documents, source code documentation, test reports, CRs, status accounting reports, and audit reports.
Status Accounting – Status accounting gathers and reports information concerning the tracking of CRs, change implementation, and CI contents (see section 3.3).
Audits & Reviews – Audits and reviews verify that LaSRS++ CIs contain all and only all changes from closed CRs, that they adhere to LaSRS++ standards, that the framework matches its documentation, and that any distribution of the framework is complete (see section 3.4).
2.2.2 Responsibility Definitions
Approve – The organization/individual approves requests for an activity and/or its results. More than one approval may be needed. This responsibility may be delegated temporarily or permanently to another individual within the same project organization.
Assign – The organization/individual is responsible for assigning the activity to a developer. This respon-sibility may be delegated temporarily or permanently to another individual within the same project organization.
Authorize – The organization/individual authorizes resource expenditures for the activity. This responsi-bility may be delegated temporarily or permanently to another individual within the same project or-ganization.
Enforce – The organization/individual is responsible for exacting compliance with all policies regarding the activity.
Maintain – The organization is responsible for upkeep of products associated with the activity.
Perform – The organization is responsible for carrying out the activity.
Review – The organization is responsible for examining products required by an activity for completeness, correctness, and clarity. This organization may also be responsible for identifying missing informa-tion.
Submit – The organization/individual can submit a CR.
2.2.3 Role Definitions
2.2.3.1 The Simulation Project CCB
The configuration control board (CCB) for a simulation project has primary responsibility for reviewing, approving, and assigning changes to the project’s requirements and products. The Project CCB shall in-clude the Project Leader (PL), the SSB Facilitator, and all developers assigned to the project. The PL is the CCB Chairman. The FSSS Project Manager selects the PL. The FSSS Project Manager also assigns the developers to the project. SSB Management selects the Facilitator. One FSSS CCB member administers the CR database and is given the role of CCB Secretary. One FSSS CCB member administers the simulation project’s CI repositories; he is given the title of CCB Librarian. All CCB members are technical analysts who review change requests. CCB members perform the following CM activities:
• Implement approved changes.
• Review approved changes. According to the LaSRS++ Software Development Plan, all class designs must undergo review and all source code changes are subject to a code walk-through. During these reviews, CCB members shall verify that only the requested change is being made and that it has been implemented according to LaSRS++ standards.
• Create or amend required documents.
2.2.3.1.1 CCB Chairman
The CCB Chairman has the following responsibilities:
• Authority to approve change requests.
• Determines when sufficient information is available to make the approval decision.
• Decides whether a CR review requires a formal meeting of the CCB or an informal discussion with some CCB members.
• Selects the CCB Secretary and the CCB Librarian.
• Approves code reviews and the PCA (see section 3.4).
2.2.3.1.2 CCB Secretary
The CCB Secretary has the following responsibilities:
• Administer the CR database, performing periodic maintenance and coordinating new custo-mizations.
• Verify that all CRs are complete and properly submitted before promoting them to review (see section 3.2).
• Deliver implementation assignments for approved CRs (see section 3.2.6).
• Verify that CRs are complete with proper authorization before closing them (see section 3.2.8).
• Produce all configuration status accounting reports (see section 3.4).
• Prepares agenda and records minutes for the formal CCB meetings.
The Configuration Management Procedures for Simulation Projects further elaborates the responsibilities of the CCB Secretary.
2.2.3.1.3 CCB Librarian
The CCB Librarian has the following responsibilities:
• Administer the project’s CI repositories, performing periodic maintenance and coordinating minor customizations.
• Give CR implementors write access to the repository.
• Ensures that only reviewed and tested changes become visible to other simulation developers (see section 3.2.8).
• Define each new release of a project CI (see section 3.1.2).
• Create repositories for new CIs (see section 3.1.3).
The Configuration Management Procedures for Simulation Projects further elaborates the responsibilities of the CCB Librarian.
2.2.3.2 Simulation Customers
A simulation customer is anyone represented by the organizations in Figure 1 who is not directly involved in the development of the project. Usually, these are members of the “research community”. The simula-tion customer can freely submit CRs to the Project CCB. Simulation customers are also invited to partici-pate in the project FCAs (see section 3.4.2). One simulation customer is designated as the ‘Principal In-vestigator’. The Principal Investigator has the authority to approve the FCA (i.e., accept the simulation product) on behalf of all customers.
2.2.3.3 Architecture Consultant (AC)
The AC, a LAT member, attends all design reviews and examines CRs which add enhancements to a project. The AC aids simulation projects in maximizing reuse of the LaSRS++ framework. The AC iden-tifies new simulation features which would benefit the LaSRS++ framework. If the AC determines that a project feature shall be moved into the framework, he will submit a CR to the LaSRS++ CCB. If the CR is approved, authority for the identified feature will be handed to the LaSRS++ CCB and its physical storage (if any) will be moved into a LaSRS++ CI repository.
2.2.3.4 FSSS Management
The FSSS Management consists of the FSSS Program Manager and the FSSS Project Manger. They can submit CRs to the project’s CCB. They assist the CCB in enforcing change control procedures through their support of the CM process. They resolve appeals on CRs which were submitted by FSSS contractors (see section 3.2.5). FSSS Management also approves in-process audits (see section 3.4.3).
2.2.3.5 SSB Management
SSB Management consists of the Branch Head and Assistant Branch Head. SSB Management can submit CRs to the project’s CCB. SSB Management resolves appeals on CRs submitted by simulation customers (see section 3.2.5). SSB Management authorizes work done on behalf of any approved CR (see section 3.2.6); this authority can be shared with no more than two SSB civil servants, for all projects. SSB management approves PCAs for products delivered to a third party (see section 3.4.4). SSB management can initiate an in-process audit and approve the results (see section 3.4.3).
2.2.3.6 SSB Facilitator
SSB Management selects a ‘Facilitator’ for each project. The SSB Facilitator is a liaison between the de-velopment group and the simulation customers. They act on behalf of the customers’ interests. This is most apparent in their responsibility to conduct the functional configuration audit (FCA) of the simulation product. The FCA embodies the process of accepting the simulation product for production. The Facilita-tor also represents the simulation customers on the CCB.
2.3 Applicable Policies, Directives, and Procedures
In addition to the CM policies detailed in this document, the following external standards and procedures apply for the duration of the project:
• The Simulation Project Configuration Management Procedures details how SCM software is used in support of this plan.
• The LaSRS++ Programmer’s Guide, which specifies stylistic and programming conventions, shall be followed for all source code written as part of a LaSRS++ CI. These guidelines in-clude but are not restricted to source code file names, variable names, structured code for-matting, and class design restrictions. The guide’s purpose is to ensure uniform looking code that is readable and avoids dangerous language idioms. Code changes shall not be accepted unless they conform with this document.
• The LaSRS++ Software Development Plan discusses the software lifecycle and proper testing procedures. All directives in this plan must be adhered to before a code change is accepted.
If the project has any other documented policies that affect SCM activities (e.g., security plans), they will be listed here.
0 التعليقات