AIR FORCE DI-SESS-81771-2009 REUSE MANAGEMENT REPORT (ReMR)《再用管理报告（ReMR）》.pdf

《AIR FORCE DI-SESS-81771-2009 REUSE MANAGEMENT REPORT (ReMR)《再用管理报告（ReMR）》.pdf》由会员分享，可在线阅读，更多相关《AIR FORCE DI-SESS-81771-2009 REUSE MANAGEMENT REPORT (ReMR)《再用管理报告（ReMR）》.pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、DATA ITEM DESCRIPTION Title: REUSE MANAGEMENT REPORT (ReMR) Number: DI-SESS-81771 Approval Date: 20090520 AMSC Number: F9071 Limitation: N/A DTIC Applicable: N/A GIDEP Applicable: N/A Preparing Activity: 13 (ESC/AQT) Applicable Forms: Worksheet Questions for Reused As-is/Modified Software Worksheet

2、Questions for COTS/GOTS Software Use/Relationships: The Reuse Management Report (ReMR) provides information about existing software products intended to be reused as-is or modified as part of the delivered operational software. The report also provides the acquirer insight into the current status of

3、 the activities associated with the reuse of these products as compared to the planned activities, and alternative approaches. This Data Item Description (DID) contains the format, content and intended use information for the data product resulting from the work tasks described in the contract. Requ

4、irements: 1. Reference documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as cited in the contract. 2. Format. Contractor format is acceptable. 3. Content. The report shall contain the

5、 following: 3.1 Executive Summary. This section shall identify and briefly describe all software products that will be reused as-is or modified (existing software requiring change) and integrated into the delivered operational software. Both commercial off-the-shelf (COTS) and government off-the-she

6、lf (GOTS) shall be included. 3.2. Current Status. This section shall present the current status of the software reuse activities compared to the contractors planned activities. Status shall include progress made and accomplishments for the engineering and management activities for each software reus

7、e product. 3.3. Variance. This section shall identify any activities where work is not progressing in accordance with the plans and schedules, including the reasons for this lack of progress. 3.4. Milestones. This section shall describe the progress made against program milestones during the reporti

8、ng period. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-DI-SESS-81771 2 3.5. Alternative Approaches. This section shall describe alternative approaches for any reused as-is/modified and COTS/GOTS software products that are 1) considered high or mo

9、derate risk or 2) not available (i.e., fully documented and tested) at contract award. Alternative approaches provide options if these software reuse products cannot be implemented as planned. 3.6. Impacts of Implementing Alternative Approaches. This section shall include an assessment of the techni

10、cal impacts to the program and estimates of the programmatic (i.e., effort and schedule) impacts of implementing alternative approaches. 3.7. Decision Points. This section shall include the decision points for implementing alternative approaches. These decision points shall identify when the alterna

11、tive approach would need to be implemented in the event that the planned software reuse products are not available in time to preserve the program schedule. 3.8. Worksheet Questions. This section shall include the completed forms (updated, if needed) for all reused as-is/modified and COTS/GOTS softw

12、are products in accordance with the instructions embedded in the forms. Forms will be included for any newly identified software reuse products. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-DI-SESS-81771 3 WORKSHEET QUESTIONS FOR REUSED AS-IS/MODI

13、FIED SOFTWARE The questions below should be answered in the corresponding worksheet format for each software product for which the Contractor plans to assume responsibility for the performance of the product. Software products may be reused as-is or modified. Information about the commercial off-the

14、-shelf (COTS) or Government off-the-shelf (GOTS) software products that will be reused as-is should be provided in the worksheet format titled “Worksheet Questions for COTS/GOTS Software.” Product and Contact Information 1. What is the name of the software product to be reused as-is or modified? 2.

15、What is the version number and date of release for the software product that is being reused as-is/modified? 3. What are the programming language(s) of this software? 4. For which system/program was the software originally developed? 5. Provide contact information, including the contacts name, the o

16、ffice symbol (if applicable), phone number and address for the: - Program manager currently responsible for the reused as-is/modified software - Responsible entity or source of the software, if the Government is not responsible for the software Applicability 6. To which Computer Software Configurati

17、on Item (CSCI) (and Computer Software Component (CSC), if known) is this reused as-is/modified software product assigned? 7. What functions/requirements will the software provide? (Attach a separate sheet that shows performance requirements cross referenced to the Technical Requirements Document (TR

18、D). Identify any mismatches in requirements between the TRD and the reused as-is/modified software product.) 8. Has the Contractor conducted an internal demonstration(s) to evaluate the applicability of this software product for this system/program? - If yes, provide additional information 9. Have t

19、he software products interfaces that provide access to the functionality been evaluated? - If yes, provide additional information 10. Has the software products architecture been evaluated for compatibility with the system architecture? - If yes, provide additional information 11. Has the software pr

20、oduct been used on a hardware/software platform similar to the one proposed for this system/program? Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-DI-SESS-81771 4 - If yes, provide additional information Extent of Modification 12. Briefly describe

21、the tasks (e.g., modification, integration, test) required to make the reused as-is/modified software functional within this system. 13. What organization will perform the modifications to this software product? 14. What organization will integrate the reused as-is/modified software with the systems

22、 software? 15. What is the effective size of the reused as-is/modified software product and extent of the modification, if applicable? Complete this table, in an Excel workbook, according to the definitions and instructions attached. A B C D E F G H I JTotal Delivery or Delivered BuildID Number of C

23、SCI Contained In Name of CSCI Contained InCSC NameModule or Class LevelDevelopment Contractor/ SubcontractorSizing MethodNew SoftwareTotal Pre-existing SoftwareDeletedSoftwareK L M N O P Q RModified SoftwareRedesign Required (%)Reimple- mentation Required (%)RetestRequired (%)Weight for Design Phase

24、 (%)Weight for Implementation Phase (%)Weight for Test Phase(%)Effective Size for Modified SoftwareS T U V W XReused As-is/ Lifted SoftwareReuse As-is/ Lift Factor Required (%)Effective Size for Reused As-is/Lifted SoftwareTotal Effective SizeEffective Size Representing Software GrowthTotal SizeMatu

25、rity 16. What is the extent of testing of the software that is to be reused as-is/modified (e.g., completed unit tests, completed CSC tests, completed CSCI tests)? 17. Has formal qualification has been conducted? - If yes, provide additional information 18. Has the software been certified and accred

26、ited? - If yes, provide additional information (e.g., specific certifications and accreditations) 19. Has the software been fielded in an operational environment? - If yes, provide additional information 20. Has the software been fielded in an operational environment? - If yes, provide additional in

27、formation (e.g., which systems/programs, whether these systems/programs have fielded the software) 21. Is the software in long-term maintenance? - If yes, provide additional information (e.g., organization maintaining the software) Provided by IHSNot for ResaleNo reproduction or networking permitted

28、 without license from IHS-,-,-DI-SESS-81771 5 Availability 22. How does the Contractor have access to the software to be reused as-is/modified (e.g., developed the software in-house, has or will acquire the software from another contractor/vendor, or requesting the software be provided by the Govern

29、ment)? 23. Is the software currently available? - If not, describe the software delivery schedule, including all critical dates that could affect program success. 24. Is the Contractors solution dependent on another Government program for this software? - If yes, briefly discuss if cross program (an

30、d contractor to contractor) relationships have been established, how they will be managed, and how the Contractor plans to stay informed about the evolving software functionality. Other Attributes Designed for Reuse 25. Identify any attributes (e.g., standards, design patterns, architecture paradigm

31、s) of the reused as-is/modified software that support reuse. Contractors Experience with Software 26. Will the Contractor have any access to the software developers, who were part of the original software development team? - If yes, provide additional information 27. Has the organization (that will

32、be performing the modifications to this software product for this program) reused as-is or modified (e.g., altered the design, made changes to the code) the software previously? - If yes, provide additional information (e.g., for what systems/programs, how many of the software developers have modifi

33、ed this software product before) 28. Has the organization (that will be integrating this software product for this program) integrated the software previously? - If yes, provide additional information (e.g., for what systems/programs, how many of the software integration engineers have integrated th

34、is software product before) Documentation 29. What supporting engineering and management documentation for the reused as-is/modified software is available for the software developers? 30. What supporting documentation for the reused as-is/modified software is available for the end users? 31. What do

35、cumentation (both development and end user) will be delivered to the Government? 32. Describe the test procedures that will support the conduct of the comprehensive Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-DI-SESS-81771 6 regression testing fo

36、r the reused as-is/modified software? - Do these procedures exist or do they need to be created? Standards 33. What development standards (e.g., IEEE/EIA Std 12207.0-2008) were followed during the development of the software intended to be reused as-is/modified? Data and Software Rights 34. What rig

37、hts will the Government have to the data and software? Identify what data and software rights are being provided to the Government using the relevant Defense Federal Acquisition Regulation Supplement (DFARS) clause definitions (DFARS 227.7103-3 and 227.7203-3.1. What is the name of the COTS/GOTS sof

38、tware product to be reused as-is? 35. Does the reused as-is/modified software require the Government to purchase any COTS software licenses? If yes, provide the commercial software licenses for review. 36. Do you intend to transfer any COTS software licenses to the Government? If yes, provide the co

39、mmercial software licenses for review. Defect Reports 37. How many Defect Reports (DRs) are currently open for the software? 38. Provide a listing of all (open and closed) DRs by category/priority, date when opened, description of problem and planned/actual date of closure. Maintenance and Support S

40、trategy 39. What organization is expected to maintain the modified software? Releases/Updates 40. Will the Contractor incorporate future releases of the reused as-is/modified product into the systems software baseline? - If yes, how will these releases be incorporated Dead and Unused Code 41. Identi

41、fy any dead code (i.e., unreachable, unnecessary, or inoperative code that is not required for any purpose) and unused code (i.e., code used in applications other than this program) from the reused as-is and modified software products. Discuss how dead and unused code will be handled, how it will be

42、 tested, and whether it presents any risks to the program. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-DI-SESS-81771 7 WORKSHEET QUESTIONS FOR REUSED AS-IS/MODIFIED SOFTWARE Instructions for Completing Question 15 Definitions: Total Delivery or D

43、elivered Build (Col. A): If there are multiple delivered builds (blocks, increments, etc.), enter the build identifier for the sizing information provided. Enter “Total” if the sizing information represents the total delivery. A separate table should be completed for each delivered build as well as

44、the total delivery. ID Number of CSCI Contained In (Col. B): Enter the identification numbers for the Computer Software Configuration Item (CSCI), in which the reused as-is/modified software product is contained. Name of CSCI Contained In (Col. C): Enter the name of the CSCI, in which the reused as-

45、is/modified software product is contained. CSC (Col. D): Enter the names of the Computer Software Components (CSCs), if known. A separate row should be completed for each CSC. Module or Class Level (Col. E): Enter the software module or class level, if known. A separate row should be completed for e

46、ach software module or class level. Development Contractor/Subcontractor (Col. F): Enter the name of the contractor or subcontractor responsible for the development of each CSCI. Sizing Method (Col. G): Enter either Source Lines of Code (SLOC) or Function Points (FP). Standard definitions for SLOC a

47、nd FPs are provided below. Fully explain any non-standard definition on a separate sheet. If an alternative sizing measure is used, the counting method should be described in detail. This table can be adapted to accommodate an alternative measure, but the type of information requested in these instr

48、uctions must be included. Lines of Code: Non-Comment lines of source code for the computer program. Source lines to include are: All executable source lines such as (1) Control, (2) Mathematical, (3) Conditional, (4) Deliverable Job Control, (5) Data Declaration Statements, and (6) Data Typing and E

49、quivalence; and input/output/format. Source lines to exclude are: debug statements, continuation of single statement to multiple lines, machine/library generated statement, and non-deliverable test statements. Function Points: Unadjusted function points, IFPUG compatible. Use this only if your size methods are function based rather th