Loren Data's SAM Daily™

fbodaily.com
Home Today's SAM Search Archives Numbered Notes CBD Archives Subscribe
FBO DAILY ISSUE OF APRIL 13, 2008 FBO #2330
SOLICITATION NOTICE

A -- The Software Systems Stockroom (S3)

Notice Date
4/11/2008
 
Notice Type
Presolicitation
 
NAICS
541712 — Research and Development in the Physical, Engineering, and Life Sciences (except Biotechnology)
 
Contracting Office
Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, New York, 13441-4514
 
ZIP Code
13441-4514
 
Solicitation Number
BAA-08-03-RIKA
 
Point of Contact
Lori L. Smith, Phone: (315) 330-1955
 
E-Mail Address
Lori.Smith@rl.af.mil
 
Description
NAICS CODE: 541712 FEDERAL AGENCY NAME: Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, NY, 13441-4514 TITLE: The Software Systems Stockroom (S3) ANNOUNCEMENT TYPE: Initial announcement FUNDING OPPORTUNITY NUMBER: BAA 08-03-RIKA CFDA Number: 12.800 DATES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 08 by 12 May 2008; FY 09 by 31 December 2008; FY 10 by 31 December 2009 and, FY 11 by 31 December 2010. White papers will be accepted until 2:00 p.m. Eastern time on 30 March 2011, but it is less likely that funding will be available in each respective fiscal year after the dates cited. FORMAL PROPOSALS ARE NOT BEING REQUESTED AT THIS TIME. See Section IV of this announcement for further details. I. FUNDING OPPORTUNITY DESCRIPTION: Background: The Air Force Research Laboratory (AFRL)/RI, in conjunction with the Office of Naval Research (ONR), is soliciting white papers for a new research program with the title, the Software Systems Stockroom (S3). The increased complexity and diversity of computational devices and systems is reflected in a corresponding increase in the difficulty in developing software for these systems. These difficulties are compounded by the dramatic increases in scale and scope of information processing applications due to the availability of networked heterogeneous distributed systems. All of these effects have exacerbated the challenges that system engineers face in trying to specify, design, build, verify and test software. A number of codified approaches are available that utilize a technological framework for defining systems, expressing requirements, classifying components, validating systems and their components, and disseminating the results. However, these approaches have demonstrated point solutions with a limited ability to mitigate risks with limited success. Complexity and diversity in computational systems is an issue in information technology in general, but the unique combination of reliability, robustness, security, interoperability, and real-time operation requirements that military systems must satisfy set them sharply apart from non-military applications. To successfully mitigate risks, approaches require community involvement, and a social framework for participation, discussion and a means for gaining community approval of new technologies. Solutions to the increased complexity and diversity of computational devices and systems require a sustained commitment by the community to devise technologies that can be used for system design and the development of general use tools. A software library is such a tool that is used to help develop applications by providing services and offering modularity, portability and efficiency of the code. Libraries follow the principles of encapsulation and separation of concerns allowing programmers to add functionality. Such tools strive to reduce complexity by providing a shared common resource, with a shared vocabulary, a shared understanding, and a shared culture of its use. Furthermore, libraries can become an authoritative and trusted reference for software system development with the right framework and smart dedicated community effort. Objective: White papers are being solicited that propose a foundational reference architecture for an open framework environment that enables researchers to develop, analyze, and classify their software components and designs. Additionally, the open framework environment will facilitate transition of promising technologies into production use. The framework should include software and systems components and products of various degrees of pedigree residing together with appropriate role-based access controls and mechanisms that allow accounting for resources, the generation of system components, and documented case studies of their application to specific projects. This open framework environment should: have similar features to an interactive library or repository; facilitate evolutionary change; promote the understanding of the resources available within the repository; and provide mechanisms for applying the resources to system development work. The framework should incorporate technology to evaluate, implement, monitor, verify, and prove components. The open framework environment will facilitate the adoption and development of new technologies, methodologies, and theories in support of the Software-Intensive Systems Producibility Initiative. The open framework environment will also facilitate the design and construction of research products and methods across a range of platforms and software systems, provide capability to allow universities and industry to leverage technology development, and will establish a capability for successful technology transition and transfer. Research Concentration Areas: CONOPS: The document that outlines a concept of operations (CONOPS) should be written to communicate overall quantitative and qualitative system characteristics to the user, developer, stakeholders and other organizational elements. It should describe an open system framework, operational policies, classes of users, interactions among users, and organizational objectives from an integrated systems point of view. Under another Software-Intensive Systems Producibility Initiative (SISPI) effort, the Systems and Software Producibility Collaboration and Evaluation Environment (SPRUCE) seeks to provide an open collaborative research and development environment to demonstrate, evaluate, and document the ability of novel tools, methods, techniques, and run-time technologies to yield more predictable production of software intensive systems. SPRUCE should be leveraged where possible. In particular, the CONOPS should address: Community and Technical Specialization. The S3 should focus on a technical area for which there is an active research and applications community, supportive of systematic standardization and codification of tools, techniques and practices at the component level. A plan to engage and involve a wider community including industry, government, and academia must be provided. Areas of general interest and their specializations include but are not limited to: verification, signal and image processing, protocols, parallel and distributed algorithms, operating systems, and discrete mathematics. Classifications and Taxonomies. Innovative approaches are sought for describing software systems components, their interrelationships, functional and non-functional dependencies, the construction environment, and that address complexity, derivations, invariants, signatures, provenance, traceability, provability, and attestations. The taxonomies devised should facilitate understanding and classifying behaviors and properties that arise from combining components. Of particular interest are systematic correct-by-construction derivations of components for classification and taxonomic structure. Information Provenance and Intellectual Property. The open framework should support laws and policies governing the use of digital intellectual property of data, software, systems and their derivations as transparently as possible for all stakeholders. Architecture. The architecture must include the architectural description as appropriate not only for an open-system architecture but also for the supporting roles and responsibilities affecting the use and construction of that architecture. The architectural definition should provide the ability to understand and control those elements of system design that capture the system’s utility, cost and risks. The definition shall provide a rigorous definition of what constitutes the fundamental organization embodying all information regarding elemental relations, interactions, and interfaces. In addition, an extended architecture should provide a structured framework for such items as accounts of success and failures, benchmarks, quantitative and qualitative results from assessments of usage, and forensic studies of software disasters that help define problems and basic research areas. Of particular interest are issues concerning the semantics of an “interface” and the information provided at an interface. User Interface and Usability. The style of interfaces affects overall usability. Scenarios that illustrate the salient features and their use should be provided in a storyboard style. Technology Diffusion and the Developer Community. A plan to involve the community of developers (especially, compiler developers) must be provided. The plan should promote principles of interoperability, transparency, and accountability, encourage the use of the open framework and its resources, and engage vendors. Collaboration. Teaming, joint projects, and in-kind cooperation are encouraged especially when competing commercial interests find common ground to address DoD and community-wide needs. Metrics. The major characteristics of the S3 and its usage are to be assessed and measured among others for accuracy, consistency, completeness, organization, transparency, trustedness, and usability. International Traffic in Arms Regulations (ITAR) and export control issues. These laws are to be enforced in the S3 at all times when sensitive material is involved. References: Institute for Electrical and Electronics Engineers, IEEE Guide for Information Technology-System Definition-Concept of Operations (CONOPS) Document. IEEE Std 1362-1998, IEEE Computer Society Press, 1998. For details on SPRUCE, please see: https://www.fbo.gov/index?s=opportunity&mode=form&id=e7730ae5bd7d600c44290fea433390d9&tab=core&_cview=1 https://www.fbo.gov/index?s=opportunity&mode=form&id=ffd956335bf3fab87ccf353fe11c0aa2&tab=core&_cview=1 Program Phases: This program will be competed in two Phases. Phase I will be the definition phase and will consist of defining, developing, and documenting the Concept of Operations (CONOPS), a user-oriented document that describes system characteristics for a proposed system from the users' viewpoint; and defining, developing and documenting fundamental principles for organizing knowledge, supporting architectures, as embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. Initial concepts along with the final CONOPS and architectures will be presented to representatives from Government, Industry, and Academia; and, the technical data rights proposed need to be consistent with this requirement. Phase II will be the environmental development and operations phase. Additional information will be issued around the April 2009 timeframe concerning Phase II and white papers for Phase II will be solicited at that time. Phase I is the area for which white papers are currently solicited. Anticipated Schedule for Phase 1 Activities: The Definition Phase will begin with a kickoff workshop and proceed with a several month CONOPS and Architecture development for the S3. A review workshop will be held mid-way through the Phase I effort during which the initial concepts will be briefed to representatives from Government, Industry and Academia who have been invited to review the ideas and provide feedback. The final months should be devoted to completing the initial concepts and incorporating comments from the review workshop. A final review workshop will be held in the final month, at which time the final CONOPS and Architectures will be presented to representatives from Government, Industry and Academia invited to review the ideas and provide feedback. Phase 1 awardees will be required to present the full extent of their work at both a mid-term and a final workshop, attendance at which will not be limited to only the Government and awardees. Phase 1 work will provide the basis for the Phase 2 solicitation, and will be used both by the Government for definition of the Phase 2 addendum, and as a repository available for Phase 2 offerors use. Therefore, the technical data rights proposed need to be consistent with these requirements. Additional information will be provided as a modification to this BAA to initiate Phase 2, which will consist of the Development and Operations phase. This modification is anticipated to be issued around the April 2009 timeframe. II. AWARD INFORMATION: Total funding for this BAA is approximately $4.9M. The anticipated funding to be obligated under this BAA is broken out by fiscal year as follows: FY 08 - $1M; FY 09 - $1.3M; FY 10 - $1.3M; and FY 11- $1.3M. Individual awards for Phase I will not normally exceed 6 months with dollar amounts ranging between $200K and $350K per year for Phase 1 and Phase II awards will not normally exceed 18 months with dollar amounts ranging between $500K and $1.3M per year. There is also the potential to make awards up to any dollar value. Awards of efforts as a result of this announcement will be in the form of contracts, grants or cooperative agreements, depending upon the nature of the work proposed. III. ELIGIBILITY INFORMATION: 1. ELIGIBLE APPLICANTS: All potential applicants are eligible. Foreign or foreign-owned offerors are advised that their participation is subject to foreign disclosure review procedures. Foreign or foreign-owned offerors should immediately contact the contracting office focal point, Lori L. Smith, Contracting Officer, telephone (315) 330-1955 or e-mail Lori.Smith@rl.af.mil for information if they contemplate responding. The e-mail must reference the title and BAA 08-03-RIKA. 2. COST SHARING OR MATCHING: Cost sharing is not a requirement. IV. APPLICATION AND SUBMISSION INFORMATION: 1. APPLICATION PACKAGE: THIS ANNOUNCEMENT CONSTITUTES THE ONLY SOLICITATION. WE ARE SOLICITING WHITE PAPERS ONLY. DO NOT SUBMIT A FORMAL PROPOSAL AT THIS TIME. Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal, see Section VI of this announcement for further details. For additional information, a copy of the AFRL/Rome Research Sites "Broad Agency Announcement (BAA): A Guide for Industry," April 2007, may be accessed at: http://www.fbo.gov/spg/USAF/AFMC/AFRLRRS/Reference%2DNumber%2DBAAGUIDE/listing.html 2. CONTENT AND FORM OF SUBMISSION: Offerors are required to submit an electronic copy of a NOT to exceed 5 page white paper summarizing their proposed approach/solution. The purpose of the white paper is to preclude unwarranted effort on the part of an offeror whose proposed work is not of interest to the Government. The white paper will be formatted as follows: Page 1 - Section A: Title, Period of Performance, Estimated Cost of Task, Name/Address of Company, Technical and Contracting Points of Contact (phone, fax and email); Pages 2 to not more than 5 - Section B: Task Objective, and Section C: Technical Summary and Proposed Deliverables. Multiple white papers within the purview of this announcement may be submitted by each offeror. If the offeror wishes to restrict its white papers/proposals, they must be marked with the restrictive language stated in FAR 15.609(a) and (b). All white papers/proposals shall be double spaced with a font no smaller than 12 pitch. In addition, respondents are requested to provide their Commercial and Government Entity (CAGE) number, their Dun & Bradstreet (D&B) Data Universal Numbering System (DUNS) number, a fax number, an e-mail address, and reference BAA 08-03-RIKA with their submission. All responses to this announcement must be addressed to the technical POC, as discussed in paragraph five of this section. 3. SUBMISSION DATES AND TIMES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 08 by 12 May 2008; FY 09 by 31 December 2008; FY 10 by 31 December 2009 and, FY 11 by 31 December 2010. White papers will be accepted until 2pm Eastern time on 30 March 2011, but it is less likely that funding will be available in each respective fiscal year after the dates cited. 4. FUNDING RESTRICTIONS: The cost of preparing white papers/proposals in response to this announcement is not considered an allowable direct charge to any resulting contract or any other contract, but may be an allowable expense to the normal bid and proposal indirect cost specified in FAR 31.205-18. Incurring pre-award costs for ASSISTANCE INSTRUMENTS ONLY, are regulated by the DoD Grant and Agreements Regulations (DODGARS). 5. OTHER SUBMISSION REQUIREMENTS: DO NOT send white papers to the Contracting Officer. All responses to this announcement must be addressed to: Steven.Drager@rl.af.mil Attn: Mr. Steven Drager V. APPLICATION REVIEW INFORMATION: 1. CRITERIA: The following criteria, which are listed in descending order of importance, will be used to determine whether white papers and proposals submitted are consistent with the intent of this BAA and of interest to the Government: (1)Overall Scientific and Technical Merit. The technical concepts should be clearly defined and carefully developed. Emphasis should be placed on the technical excellence, creativity, and innovation of the development and the usability of the proposed technology, which include the architecture, interoperability, and methodology to broaden participation of the technical community. (2)Collaboration and Information Sharing. The offeror must demonstrate a high level of commitment with detailed plans for collaboration among all major relevant parties. Moreover, the offeror must provide plans for sharing results with the broader community and encouraging participating of team and non-team members alike in evaluations and information dissemination. (3)Related Experience. The white paper will be judged on the extent to which the offeror demonstrates technical knowledge and competency in relevant domains of software technologies, balance of the skills set of the team, excellence of the academic-industry team members, experience with government contracts, and proven capability to conduct innovative practical research. Of particular importance is acumen in the unique challenges of integration and development, anticipated in the near to far term. (4)Openness and Maturity of Solution. - The extent to which existing capabilities and standards are leveraged, the relative maturity of the proposed technology in terms of reliability and robustness, and previous demonstration of capability to accomplish the proposed tasks. (5)Reasonableness and realism of proposed costs and fees (if any). No further evaluation criteria will be used in selecting white papers or proposals. Individual white papers and proposals will be evaluated against the evaluation criteria without regard to other white papers and proposals submitted under this BAA. White papers and proposals submitted will be evaluated as they are received. 2. REVIEW AND SELECTION PROCESS: Only Government employees will evaluate the white papers/proposals for selection. The Air Force Research Laboratory's Information Directorate has contracted for various business and staff support services, some of which require contractors to obtain administrative access to proprietary information submitted by other contractors. Administrative access is defined as "handling or having physical control over information for the sole purpose of accomplishing the administrative functions specified in the administrative support contract, which do not require the review, reading, or comprehension of the content of the information on the part of non-technical professionals assigned to accomplish the specified administrative tasks." These contractors have signed general non-disclosure agreements and organizational conflict of interest statements. The required administrative access will be granted to non-technical professionals. Examples of the administrative tasks performed include: a. Assembling and organizing information for R&D case files; b. Accessing library files for use by government personnel; and c. Handling and administration of proposals, contracts, contract funding and queries. Any objection to administrative access must be in writing to the Contracting Officer and shall include a detailed statement of the basis for the objection. VI. AWARD ADMINISTRATION INFORMATION: 1. AWARD NOTICES: Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal. Notification by email will be sent by the technical POC. Such invitation does not assure that the submitting organization will be awarded a contract. Those white papers not selected to submit a proposal will be notified in the same manner. Prospective offerors are advised that only Contracting Officers are legally authorized to commit the Government. All offerors submitting white papers will be contacted by the technical POC, referenced in Section VII of this announcement. Offerors can email the technical POC for status of their white paper/proposal no earlier than 45 days after proposal submission. 2. ADMINISTRATIVE AND NATIONAL POLICY REQUIREMENTS: Depending on the work to be performed, the offeror may require a TOP SECRET facility clearance and safeguarding capability; therefore, personnel identified for assignment to a classified effort must be cleared for access to TOP SECRET information at the time of award. In addition, the offeror may be required to have, or have access to, a certified and Government-approved facility to support work under this BAA. Data subject to export control constraints may be involved and only firms holding certification under the US/Canada Joint Certification Program (JCP) (www.dlis.dla.mil/jcp) are allowed access to such data. A Phase 1 awardee will have to present the full extent of its work at a mid-term and at a final workshop, attendance at which will not be limited to only the Government and awardees. Also, the Phase 1 work will provide the basis for the Phase 2 solicitation, and be used both by the Government for definition of the Phase 2 addendum, and as a repository available for Phase 2 offerors to use. Therefore, the technical data rights proposed need to be consistent with these requirements. 3. REPORTING: Once a proposal has been selected for award, offerors will be required to submit their reporting requirement through one of our web-based, reporting systems known as JIFFY or TFIMS. Prior to award, the offeror will be notified which reporting system they are to use, and will be given complete instructions regarding its use. VII. AGENCY CONTACTS: Questions of a technical nature shall be directed to the cognizant technical point of contact, as specified below: TPOC Name: Steven Drager Telephone: (315) 330-2735 Email: Steven.Drager@rl.af.mil Questions of a contractual/business nature shall be directed to the cognizant contracting officer, as specified below: Lori Smith Telephone (315) 330-1955 Email: Lori.Smith@rl.af.mil The email must reference the solicitation (BAA) number and title of the acquisition. In accordance with AFFARS 5315.90, an Ombudsman has been appointed to hear and facilitate the resolution of concerns from offerors, potential offerors, and others for this acquisition announcement. Before consulting with an ombudsman, interested parties must first address their concerns, issues, disagreements, and/or recommendations to the contracting officer for resolution. AFFARS Clause 5352.201-9101 Ombudsman (Aug 2005) will be incorporated into all contracts awarded under this BAA. The AFRL Ombudsman is as follows: Susan Hunter Building 15, Room 225 1864 Fourth Street Wright-Patterson AFB OH 45433-7130 FAX: (937) 225-5036; Comm: (937) 255-7754 All responsible organizations may submit a white paper which shall be considered.
 
Web Link
FedBizOpps Complete View
(https://www.fbo.gov/?s=opportunity&mode=form&id=4b0ea09e35d954504ce0ae5866789ae5&tab=core&_cview=1)
 
Record
SN01552808-W 20080413/080411221827-4b0ea09e35d954504ce0ae5866789ae5 (fbodaily.com)
 
Source
FedBizOpps Link to This Notice
(may not be valid after Archive Date)

FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |
ECGrid: EDI VAN Interconnect ECGridOS: EDI Web Services Interconnect API Government Data Publications CBDDisk Subscribers
 Privacy Policy  Jenny in Wanderland!  © 1994-2024, Loren Data Corp.