SOLICITATION NOTICE
A -- Software and Systems Test Track
- Notice Date
- 5/9/2007
- Notice Type
- Solicitation Notice
- NAICS
- 541710
— Research and Development in the Physical, Engineering, and Life Sciences
- Contracting Office
- Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate 26 Electronic Parkway, Rome, NY, 13441-4514, UNITED STATES
- ZIP Code
- 00000
- Solicitation Number
- Reference-Number-BAA-06-13-IFKA-PART-1
- Description
- PART 1 OF 2. SEE BAA-06-13-IFKA-PART-2 The purpose of this modification is to republish the original announcement pursuant to FAR 35.016(c). This republishing also includes the following changes: (a) removes Phase I information that is no longer pertinent; (b) adds Phase II information; (c) changes the white paper recommended dates; (d) changes the evaluation criteria; (e) changes the content and form of submission; (f) adds technical data requirements to paragraph VI.2; (g) changes the anticipated schedule; (h) removes the following evaluation criteria "consideration will be given to past and present performance on recent Government contracts, and the capacity and capability to achieve the objectives of this BAA", and (i) changes the Ombudsman point of contact information. No other changes have been made. NAICS CODE: 541710 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: Software and Systems Test Track ANNOUNCEMENT TYPE: Initial announcement FUNDING OPPORTUNITY NUMBER: BAA #06-13-IFKA CFDA Number: 12.800 DATES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 07 by 31 May 2007; FY 08 by 31 December 2007; FY 09 by 31 December 2008 and, FY 10 by 31 December 2009. White papers will be accepted until 2:00 p.m. Eastern time on 30 March 2010, 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: It is increasingly difficult to create software to deal successfully with increased device and system complexity. Moreover, networked distributed systems create vast increases in the scale and scope of information processing applications, exacerbating the challenges to the system engineers' ability to specify, design, build, verify and test software. This situation is an emerging issue in information technology in general, but the requirement of military systems set them sharply apart from non?military applications in terms of reliability, robustness, security, interoperability and real time operation. Business, government, and technical endeavors ranging from financial transactions to space missions increasingly require complex software systems to function correctly. The complexity of the software arises from stringent requirements (e.g., for reliability in performance and integrity of the data used), the need to support a range of interactions with the environment in real time, and/or certain structural features. These attributes make software difficult to produce. Major hardware-software failures in defense acquisition programs have occurred both because components were expected to interoperate properly and they did not, as well as the fact that tools did not work as advertised. Interoperability is required for network centric environments but reality has shown it very difficult to achieve. A scalable, flexible, realistic synthetic testing environment is required for stressing tools against key benchmarks, assessment of the utility of tools by key program offices as well as use as a synthetic environment for testing tools against large systems (tens of millions of SLOC or larger) or systems-of-systems. Software intensive systems are critical to meeting demands of current and future warfighting capabilities. The costs of development of these systems -- in terms of dollars, time and human resources are increasing rapidly. Approximately 40% of DoD's RTD&E budget is currently spent on software development, and this is expected to increase. "The (Army FCS) software task alone is five times larger than that required for Joint Strike Fighter and ten times larger than the F-22, which after two decades is finally meeting its software requirements." -- Congressman Curt Weldon (April, 2004) The complexity of current and emerging systems and systems of systems (SoS) requires breakthrough approaches in system development including new tools and methodologies spanning the entire system lifecycle from architecture design to system and SoS verification. One of the risk factors affecting the transitionability of such research is the difficulty of validating and verifying the functionality of research technologies against realistic problems. The poor collaboration among people working across the technology maturity lifecycle has created a "valley of disappointment" where DoD programs fail to adopt advanced technologies, regardless of their inherent promise. A regime of ad hoc policies and procedures for transitioning software research into software practice in avionics and other domains has arisen for technology transitioning. The expectation is that promising work funded by one organization early in the lifecycle, e.g., a DARPA program focusing on Science and Technology, will be perpetuated by another organization in the following phase, e.g., an AFRL program on Research & Engineering. The DoD has over 100 separate organizations engaged in technology transfer. The current strategy and the number of organizations involved makes it hard for knowledgeable people across the Technology Readiness Lifecycle ? customers, researchers, engineers, and operators ? to collaborate and plan for transition. Program Engineers typically view new development tools and runtime platforms as risky due to: Insufficient evidence to prove their capabilities can payoff in production environments, Immature prototypes that lack stability, features, user support and training, and technology-to-tool chain integrations, and The absence of affordable and sustainable long-term commercial support plans. Software-Intensive Systems Producibility researchers typically assume others in government or commercial market place will address these problems. It is the intent of Software and Systems Test Track to help address all of the above issues. Objective: The overall objective of this Systems and Software Test Track (SSTT) BAA program is to provide an open framework environment where an assortment of experimental tools and products may be deployed and allowed to interact in real-time, interactive, evolutionary and interdependent means, thereby allowing rigorous testing of new technologies, methodologies and theories in support of the Software-Intensive Systems Producibility Initiative (SISPI). The Systems and Software Test Track will facilitate testing of Software-Intensive Systems Producibility research products and methods, provide an environment for research of DoD embedded systems and software problems, provide an ability for university and industry leverage of technology development, and establish a capability for successful technology transition and transfer. The SSTT is intended to be an open collaborative research and development environment to demonstrate, evaluate, and document the ability of novel tools, methods, techniques, and technologies to yield affordable and more predictable production of software intensive systems. The SSTT system will bring together researchers, developers, and domain experts from different communities to de-fragment the knowledge necessary to achieve SISPI research, development and technology transition. The SSTT will be a system where SISPI researchers can test their research against relevant challenge problems, and where independent analysis of SISPI research can be preformed. This independent analysis would enable the SSTT to support acquisition program offices and analyze utility of tools. Also, SSTT users can bring their unsolved problems to provide challenges that drive SiSPI research where no such tools are available, or search for a solution by leveraging existing capabilities available in the SSTT. The SSTT will have several logical roles of collaborating participants: Challenge Problem Provider (for providing challenge problems), Candidate Solution Provider (for providing candidate solutions to challenge problems), Experimenter (for running experiments and collecting experimental results), Collaborators (involved in collaborating on challenge problems, candidate solutions, and/or experiments), Solution Inquirer (actively searching for a needed capability) and SSTT Administrators (responsible for administering the SSTT infrastructure). Various community participants may play one or more of these logical roles. SSTT will enable Program Engineers from DoD Acquisition Programs to interact with SISPI Researchers from Industry Labs or Universities to define, discover and evaluate SISPI technology. Phase 1 consisted 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 the architecture and the fundamental organization of the Systems and Software Test Track 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 therefore, the technical data rights proposed need to be consistent with this requirement. Two awards were made and all documentation is available on the BCSW server (please contact steven.drager@rl.af.mil to request access). The CONOPS will be posted on FedBizOpps along with this modification 1. Phase II will be the environmental development and operations phase. The environment should be open and available for use by developers as well as independent analysis by the facility operators. This independent analysis allows the facility operators to be supportive to major defense acquisition program offices as well as analyzing the utility of tools. Program offices may bring their unsolved problems to the test track for either help in solving or by looking for needed utility amongst the tools available. Lastly, this synthetic environment should provide a place where big codes can be tested in the loop allowing requirements verification prior to production and deployment. This risk reduction affords the ability to verify and validate functionality of today's complex software intensive systems while providing a realistic environment for researchers to verify their tools against realistic problems. The Systems and Software Test Track should also provide a place (possibly virtual and not a single physical location) for experimental verification of Software-Intensive Systems Producibility technologies due to their novelty and the potential complexity of the underlying theories. The experimental platforms should incorporate software technology to instrument, monitor and test large-scale applications. Challenge problems for the open experimental platforms should be made accessible for all the research teams. The experimental platform research should include subtasks to conduct large-scale coordination experiments, and to develop methods and tools for evaluating aggregate performance of applications. This environment should provide a full range of collaborative technology challenges, run-time platforms and applications, experiments, evaluations, and demonstrations. A Common infrastructure will enable control and data flow between both kinds of application components for a distributed environment. The open experimentation environment will provide the fundamental reference architecture and underpinnings helping researchers to develop and test their designs as well as facilitates transition of promising technologies into production use. Research Concentration Areas: The primary goal of the Phase 2 research is to design and implement the Systems and Software Test Track (SSTT) from the Concept of Operations (CONOPS). The SSTT will facilitate testing of Software-Intensive Systems Producibility research products and methods, provide an environment for research of DoD embedded systems and software problems, provide an ability for university and industry leverage of technology development, and establish a capability for successful technology transition and transfer. To ensure a broad range of collaborators offerors need to provide details on how researchers will collaborate with the SSTT, including non-team participation and successful methods of collaboration used in the past. The Architecture should provide the ability to understand and control those elements of system design that capture the system's utility, cost, and risk. These elements could be the physical components of the system and their relationships, the logical components or enduring principles or patterns that create enduring structures. The Architecture shall provide a rigorous definition of what constitutes the fundamental organization of the Systems and Software Test Track embodying all information regarding elemental relations, interactions and interfaces. Areas to consider when developing the Architecture include, but are not limited to: The environment to host, execute and test technology, both hardware environment (run time platform) and software environment (run time platform) Details on how researchers will collaborate with the SSTT, including non-team participation and successful methods of collaboration used in the past Interfaces and collaborations Mechanisms to support research and analysis of DoD problems including, but not limited to: software artifacts, benchmarks, executables, source code, design documents, requirements documents, examples, models, fault data, lessons learned, software construction files and tools Data repositories for results, success stories, benchmarks, quantitative and qualitative results, software disaster studies defining problems and basic research areas, ability to upload/download artifacts Measurement Techniques and Software Forensics Metrics including reduced development time; ease in which domain experts and software engineers can interact; ease in which different domain experts can specify and design code independently of one another; usability, i.e., the 'naturalness' of the modeling language from which code is generated; ability of test engineers to modify and tune code in the field; accurate automated documentation in design Mechanism for studying innovative systems and dynamic processes, not static snapshots Populate, demonstrate, promote and improve the SSTT. For the SSTT to be successful it must be populated with challenge problems, software producibility tools, collaboration tools, and administrative tools. 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. Anticipated Schedule: Phase 2, the Development and Operations phase, is anticipated to be a 4 year effort. Phase 3, the Research and Operations phase, is expected to begin upon the completion of Phase 2. Additional information will be provided as a modification to this BAA to initiate Phase 3. This modification is anticipated to be issued in September 2009. PART 1 OF 2. SEE BAA-06-13-IFKA-PART-2
- Record
- SN01290655-W 20070511/070509220929 (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 |