Specific Content Sample Clauses
Specific Content. Offerors are required to explain what aspects of the contracts are deemed relevant to the proposed effort and to what aspects of the proposed effort they relate. This may include a discussion of efforts accomplished by the Offeror to resolve problems encountered on prior contracts as well as past efforts to identify and manage program risk. Xxxxxx having problems does not automatically equate to a limited or no confidence rating, since the problems encountered may have been on a more complex program, or an Offeror may have subsequently demonstrated the ability to overcome the problems encountered. The Offeror is required to clearly demonstrate management actions employed in overcoming problems and the effects of those actions in terms of improvements achieved or problems rectified. Categorize the relevant information into the specific technical/management subfactors used to evaluate the proposal. The Past Performance volume will be organized according to the following general outline:
Specific Content. The DD shall consist of the specifications and documentation defined by the TDT and with the format and content as defined by the TDT.
Specific Content. 6.2.1 The software will be developed in an auditable fashion. That is, full version control, as per ISO 9000 and relevant related standards, will be implemented. All versions of the software must be retained in source code format with full documentation of the changes between versions, the reason for these changes and the author or authors responsible for these changes. The source code of the software package will be exhaustively commented. Commonwealth will have access to all versions of the software and all documentation regarding them.
6.2.2 The software package will be comprised of modules. These modules will each relate to specific parts of the prognostic health management modelling algorithm.
6.2.3 Each module of the software package will be subject to strict version control. Dependences between software modules and the interface of each module will be fully documented. Any changes to these interfaces or dependences must be documented along with the reason for the change.
6.2.4 Each module of the software package will be capable of being modified independently of all others without causing incorrect operation of other modules.
Specific Content. 5.2.1 The Agenda shall incorporate agenda items and other input requested by the Project Authority and shall include: the purpose or objective of the meeting; the meeting location, date, starting time, and expected duration; a chronological listing of each major discussion topic, including the person responsible to take the lead on the topic; a list of individuals invited to attend the meeting, identifying their appointment and area of responsibility; the identity of the chair person; administrative information associated with the meeting, including, where appropriate, access arrangements and facilities available; a list of documentation to be reviewed at the meeting; and any other information pertinent to the meeting. DATA ITEM DESCRIPTION 1 DID IDENTIFIER: CTD-07 2 DID NAME: DID-MINUTES 3 TITLE: MEETING MINUTES 4 DESCRIPTION AND INTENDED USE
Specific Content. The SHAR shall include the following: The safety criteria and methodology used to classify and rank hazards, plus any assumptions on which the criteria or methodologies were based or derived including the definition of acceptable risk as specified by the Commonwealth; The results of analyses and tests performed to identify hazards inherent in the system, including: Those hazards that still have a residual risk, and the actions that have been taken to reduce the associated risk to a level contractually specified as acceptable; and Results of tests conducted to validate safety criteria, requirements and analyses; The results of the safety program efforts. Include a list of all significant hazards along with specific safety recommendations or precautions required to ensure safety of personnel, property, or the environment. Categorise the list of hazards as to whether or not they may be expected under normal or abnormal operating conditions; Evidence of all safety assurance activities, including the results of safety assessments performed; Any hazardous materials generated by or used in the system, including: Identification of material type, quantity, and potential hazards; and Safety precautions and procedures necessary during use, packaging, handling, storage, transportation, and disposal (eg, explosive ordnance disposal). Include all explosives hazard classifications; A signed statement that all identified hazards have been eliminated or their associated risks controlled to levels contractually specified as acceptable, and that the system is ready to test or operate or proceed to the next acquisition phase. In addition, the Contractor shall make recommendations applicable to hazards at the interface of his system with the other system(s) as contractually required. DATA ITEM DESCRIPTION 1 DID IDENTIFIER: CTD-15 2 DID NAME: DID-DD 3 TITLE: DESIGN DOCUMENTATION 4 DESCRIPTION AND INTENDED USE
Specific Content. 6.2.1 The CMS shall graphically depict the project schedule and progress to work package level.
6.2.2 The CMS shall identify: activities and their estimated durations; milestones, including Contract Milestones; the relationships and dependencies between activities and milestones to be accomplished by or for the Contractor in the performance of its obligations under the Contract; and earliest and latest start and finish dates for all activities and milestones.
6.2.3 The CMS shall include: Subcontractor schedules; other major events, as mutually agreed between the Contractor and the Project Authority; Project Authority tasks, where such tasks interface with, and may affect, Contractor tasks; and significant meetings and reviews, including: any Contract Performance Reviews, Progress Meetings, and System Reviews.
6.2.4 Each submission of the CMS shall provide visibility of progress against the current Accepted schedule baseline and shall include the original contracted baseline schedule (including all original Contract Milestone completion dates. DATA ITEM DESCRIPTION 1 DID IDENTIFIER: CTD-04 2 DID NAME: DID-PSR 3 TITLE: PROJECT STATUS REPORT 4 DESCRIPTION AND INTENDED USE
Specific Content. 6.2.1 The specific SS content shall be in accordance with DI-IPSC-81431A, section 4, “Content Requirements”.
6.2.2 If the CDRL requests a Verification Cross Reference Matrix (VCRM), the DI-IPSC-81431A “Qualification Provisions” should be by reference to the VCRM.
6.2.3 If the CDRL requests a Requirements Traceability Matrix (RTM), the DI-IPSC-81431A “Requirements traceability” should be by reference to the RTM.
Specific Content. 6.2.1 The software will be developed in an auditable fashion. That is, full version control, as per ISO 9000 and relevant related standards, will be implemented. All versions of the software must be retained in source code format with full documentation of the changes between versions, the reason for these changes and the author or authors responsible for these changes. The source code of the software package will be exhaustively commented. Commonwealth will have access to all versions of the software and all documentation regarding them.
6.2.2 The software package will be comprised of modules. These modules will each relate to specific parts of the prognostic health management modelling algorithm.
6.2.3 Each module of the software package will be subject to strict version control. Dependences between software modules and the interface of each module will be fully documented. Any changes to these interfaces or dependences must be documented along with the reason for the change.
6.2.4 Each module of the software package will be capable of being modified independently of all others without causing incorrect operation of other modules.
6.2.5 The software package will be written so as to not be dependant for its operation or development on any given hardware or software platform or any operating system. As such the software should be able to readily ported to new computer software and hardware as these evolve over time.
6.2.6 The software will be written in a commonly available compiled programming language which can be sourced from multiple vendors. Suitable examples include (but are not limited to) languages such as C, C++, Basic and Pascal. The software must not be dependant on a software environment available from only a single vendor.
6.2.7 The development and use of the software must not require the payment of licence fees for any proprietary framework, proprietary software, proprietary programming language or proprietary programming environment by the Commonwealth and/or any of its agencies.
6.2.8 The software will be delivered as both source code and an executable program. DATA ITEM DESCRIPTION 1 DID IDENTIFIER: CTD-19 2 DID NAME: DID-DR 3 TITLE: FINAL REPORT 4 DESCRIPTION AND INTENDED USE
Specific Content. The SHAR shall include the following:
Specific Content. 6.2.1 The Review Package should include information to be reviewed and discussed at the specific review, including: