> RFQ \# 9-BJ2-Z14-02-17Q
>
> Attachment I
>
> Questions & Answers

## SOW Section 1. Background Information

> **Question 1**. Is this assumption correct?
>
> The end of paragraph 1 and the beginning of paragraph 2 states:
>
> " . . . The Integrated Display Development and Deployment Environment
> (IDDE) is composed of three major components: (1) a display
> development environment, (2) a display deployment environment, and (3)
> a set of graphical user interface widgets.
>
> The proof of concept IDDE has been completed and demonstrated during
> prototype testing. This document will detail the requirements that
> should be used during the development of the final deployment system .
> . .."
>
> **[Assumption]{.underline}:** The only software item being developed
> is the "final deployment system" mentioned in the previous sentence as
> the "display deployment environment" of the IDDE.
>
> *[Answer (Q1]{.underline}). Per the SOW, the contractor will be
> responsible for delivering \"*a prototype release (for some of the
> items, see delivery schedule), deployment release, and final release
> version of the following items: display development environment, a
> display deployment environment, a set of Graphical User Interface
> (GUI) widgets, a Wave Player application, an equation parser, utility
> widgets, and a web based help system.\"
>
> *.*
>
> **Question 2.** Is this assumption correct?
>
> The end of the second paragraph states that:
>
> "The IDDE will need to seamlessly integrate the help system and
> intelligent procedure assistant that will be built concurrently by
> NASA engineers."
>
> **Assumption:** Required functionality includes compatibility with
> software that is non-commercial and has not been complete.
>
> *[Answer (Q2]{.underline}). Assumption is correct.*
>
> **Question 3.** Is the deliverable product the final deployment system
> as implied or are there other modules to be delivered but whose
> specifications are not mentioned in this SOW?
>
> *[Answer (Q3]{.underline}). Yes the final delivery will be the
> deployment system. The actual number of modules that make up the final
> deployment system will depend on the architecture that is employed by
> the vendor.*
>
> An end-to-end system must be developed using an iterative process. Two
> iterations of the software must be delivered.
>
> **Question 4.** Is the IDDE to be provided as GFE in this contract?
>
> *[Answer (Q4]{.underline}). The display developer, display deployment,
> wigets, support utility applications, and help system are the portions
> of the Integrated Display Development Environment that the vendor is
> responsible for \~ all but the Intelligent procedure assistant, the
> data distribution framework, and the documents for the \"intelligent
> producedure assistant\".*
>
> **Question 5.** What hardware platform has been used to develop and
> test the requested module?
>
> *[Answer (Q5]{.underline}). Windows 2000.*
>
> **Question 6.** Is the IDDE a commercial off the shelf product or a
> custom product?
>
> *[Answer (Q6]{.underline}). The IDDE is the combination of the
> software developed by the contractor and the software developed by
> NASA S/W engineers.*
>
> **Question 7.** What documentation is available supporting the IDDE?
>
> *[Answer (Q7]{.underline}). Additional charts and documents have been
> developed that detail the IDDE. The development of the items specified
> in the SOW should be sufficient to develop the necessary software.*
>
> **Question 8.** What documentation or specifications are available for
> the help system and intelligent procedure assistant that will be built
> in the future by NASA?
>
> *[Answer (Q8]{.underline}). The requirements for the intelligent
> system are currently under development. Preliminary help files have
> been created and used in a web based stand-alone help system.*
>
> *The vendor is responsible for the development of the \"System\".
> Parallel development is possible between the components that the
> vendor is to work on and the NASA portions. All the \"system\"
> components that will be required by the vendor to commence work will
> be completed before contract start.*
>
> **Question 9.** Is it NASA's intent to provide all documentation
> necessary to seamlessly integrate software with the products being
> developed by NASA?
>
> The last sentence of the paragraph states:
>
> "The final IDDE will allow users to develop and deploy displays in a
> fraction of the time that it would normally take using "standard"
> programming practices. Not only are the displays developed faster, but
> the time required for validation and "flight certification" of each
> display is significantly reduced."
>
> *[Answer (Q9]{.underline}). The vendor will have to provide a solution
> that will integrate into the final IDDE, but any necessary
> documentation will be delivered by NASA that detail how to integrate
> the software developed into the IDDE. In other words, the initial
> prototype system components would be furnished to the awardee to
> integrate into the final IDDE. For proprietary reasons, we cannot post
> this \"data\" to the solicitation.*
>
> **Question 10.** Is it correct to assume that these qualitative
> requirements will not be levied on the contractor?
>
> *[Answer (Q10]{.underline}). The contractor will be responsible for
> delivering \"a prototype release (for some of the items, see delivery
> schedule), deployment release, and final release version of the
> following items: display development environment, a display deployment
> environment, a set of Graphical User Interface* *(GUI) widgets, a Wave
> Player application, an equation parser, utility widgets, and a web
> based help system.\" The only Government Furnished items (GFE)are the:
> Intelligent Procedure Assistant, the documents that make up the
> procedure assistant, and the underlying data distribution
> architecture. Everything else that makes up the IDDE is to be provided
> by the contractor. Consequently, your assumption with respect to the
> qualitative requirements are correct.*
>
> **SOW Section 2. Deliveries:**
>
> The first paragraph in Section 2 states:
>
> The deliveries for this contract will include a prototype release (for
> some of the items, see delivery schedule), deployment release, and
> final release version of the following items: display development
> environment, a display deployment environment, a set of Graphical User
> Interface (GUI) widgets, a Wave Player application, an equation
> parser, utility widgets, and a web based help system.
>
> **Question 11.** The background information indicates that the only
> development module is to be the display deployment environment (refer
> to contractor question 1). Exactly how much of the IDDE if GFE and
> what modules are to be CFE?
>
> *[Answer (Q11]{.underline}). The contractor will be responsible for
> delivering \"*a prototype release (for some of the items, see delivery
> schedule), deployment release, and final release version of the
> following items: display development environment, a display deployment
> environment, a set of Graphical User Interface (GUI) widgets, a Wave
> Player application, an equation parser, utility widgets, and a web
> based help system.\"
>
> **Question 12.** The first paragraph of section 2 indicates that the
> help system is being developed by NASA engineers and the only
> requirement is "seamless integration" (refer to contractor question
> 8).
>
> *[Answer (Q12]{.underline}). NASA S/W engineers are developing the
> .html help files. The vendor will be responsible for an
> architecture/system that can be used to \"integrate\" these help files
> into the vendor created help system.*
>
> **Question 13.** Situation Awareness Widgets are apparently based on
> Rapid Imaging Software's AFVT components. Will this software be GFE or
> CFE?
>
> *[Answer (Q13]{.underline}). AFVT is a commercial product, which will
> need to be acquired by the vendor. A point of contact will be provided
> upon contract start. It will be up to the vendor and Rapid Imaging
> Software to work out any details pertaining to the use of AFVT during
> the development of the necessary components by the vendor for NASA
> purposes.*
>
> **Question 14.** What components of Rapid Imaging Software's AFVT have
> been used?
>
> *[Answer (Q14]{.underline}). The entire AFVT suite has been used.*
>
> **Question 15.** Many dynamic widgets called for a mathematical
> relationship between input data string and display movement. Are these
> relationships GFE or CFE?
>
> *[Answer (Q15]{.underline}). The relationships will be Government
> Furnished Equipment.*
>
> **Question 16.** What interface documentation exists for the Wave
> Player function and when can it be provided?
>
> *[Answer (Q16]{.underline}). All the necessary documentation to build
> the application can be found in the SOW. If any other clarifications
> are required, they will be provided when necessary.*
>
> **Question 17.** Are the time based variables for the equation phase
> GFE or CFE? What document controls these?
>
> *[Answer (Q17]{.underline}). The variables (we call them MSIDs) will
> be GFE. These parameters are controlled by our Master Measurement List
> (MML).*

#  Section 4. Software Delivery

> **Question 18.** The schedule provided indicates delivery in the first
> month of Custom Colorwells, Font Dialogs, and line width utility
> controls, which are not specified in Section 2. Please provide
> specifications for these modules.
>
> *[Answer (Q18]{.underline}). Font dialogs are provided so that users
> will have the ability to select a desired font. Colorwells are dialogs
> that provide users with the ability to select a color. A line width
> utility provides users with the ability to select a line width. These
> are all very typical in Windows \"type\" utility applications. See
> Microsoft Word/Excel/Paint for samples of these.*
>
> **Question 19.** The schedule provided indicates delivery in the first
> month of Multiple State Architecture Implementation. Please provide
> specifications for this requirement.
>
> *[Answer (Q19]{.underline}). The Multiple State Architecture is the
> architecture that allows widgets to be programmed to behaved
> differently depending on the value received.*
>
> **Question 20.** The schedule provided indicates delivery in the first
> month of Persistence Architecture Definition and Implementation
> documentation and testing. Please provide specifications for this
> requirement.
>
> *[Answer (Q20]{.underline}). The persistence mechanism is the method
> by which the \"programmed\" settings will be saved and used during
> deployment.*
>
> **Question 21.** Delivery of display developer and display deployer in
> the first month is unreasonable unless the government proof of concept
> IDDE is, in fact, a commercial product that is being slightly modified
> for government use. If it is a commercial product, the name of the
> product and its specifications sheets should be released as part of
> the RFP.
>
> *[Answer (Q21]{.underline}). The schedule was reached after careful
> consideration of the necessary deliveries.*
>
> **Question 22.** After a set of displays are developed, is there a
> plan for testing all of the developed displays together in simulation?
>
> *[Answer (Q22]{.underline}). Yes.*
>
> **Question 23.** What is the information distribution mechanism for
> the IDDE? COM?
>
> The AHICS IDDE provides for the construction of displays that render
> on one or more Windows platforms. Data employed to "fuel" the
> interfaces with information must be shared among the multiple machines
> hosting the deployed interfaces.
>
> *[Answer (Q23]{.underline}). The data will be distributed using
> Tibco\'s Rendezvous software. We have developed a set of C++ classes
> that use Rendezvous inside of the widgets to receive the data.*
>
> **Question 24.** What operating system(s) will these tools (display
> developer and deployer) need to run on top of?
>
> *[Answer (Q24]{.underline}). Wintel based PCs.*
>
> **Question 25.** How is the live, real time data for the deployed
> system obtained? (i.e. COM, TCP/IP socket connection, other method)
>
> *[Answer (Q25]{.underline}). The data will be distributed using
> Tibco\'s Rendezvous software. We have developed a set of C++ classes
> that use Rendezvous inside of the widgets to receive the data.*
>
> **Question 26.** Is this software required to meet flight standards?
> If so, which?
>
> *[Answer (Q26]{.underline}). Since there are varying level of flight
> certifications, upon receipt, the software will be extensively tested
> by NASA engineers. If deemed acceptable during this testing, it will
> be considered acceptable and deemed \"flight worthy\".*
>
> **Question 27.** Is the prototype software and its source code
> available for examination either now, during contract negotiations, or
> after award?
>
> *[Answer (Q27]{.underline}). After contract award.*
>
> **Question 28.**. What kinds of images are to be viewed in the image
> viewer widget? (i.e. GIF, JPEG, etc.)
>
> *[Answer (Q28]{.underline}). .bmp, .jpeg, .tiff, .jpeg*
>
> **Question 29.** How are instant messages to be transported among
> deployed systems?
>
> *[Answer (Q29]{.underline}). We have an implementation of some
> Rendezvous classes that may simplify this. It will be up to the vendor
> to come up with an acceptable technological solution.*
>
> **Question 30.** What is the \"Rendezvous\" software listed in the
> solicitation and who produces it?
>
> *[Answer (Q30]{.underline}). Rendezvous is our interprocess
> communication API. It is developed by Tibco Software (www.tibco.com).*
>
> **Question 31.** I was wondering if any futher documents or more
> detailed information is available.
>
>  

In the provided Statement of Work, there are references to diagrams and
pictures in Appendix C, which was not provided in the file available for
download.

> *[Answer (Q31]{.underline}). Yes, there is additional documentation
> available. It will be provided upon contract start. The item being
> referred to here is a depiction of 1 vertical and 1 horizontal
> splitter bar in a window. These items are not very significant in the
> overall scheme. Information contained in the SOW is deemed not only
> sufficient for furnishing quotes, but adequately indicates the scope
> of work 1) Develop and end-to-end IDDE (those described in the SOW),
> 2) develop support utilities, and 3) Provide technical/development
> phone support for 1 year.*
>
> **Question 32.** The SOW describes a prototype that NASA already has.
> Is the intent to take the prototype to the next stage, or leverage the
> knowledge of the prototype and start a new project? If the intent is
> to start a new project, skip to question 5 below. If the intent is to
> leverage the prototype, we need questions 2, 3 and 4 answered as well.
>
> *[Answer (Q32]{.underline}). Leverage on the knowledge. (Skipping to
> Question 5)*
>
> **Question 33.** How many of the 18 controls have not been
> implemented?
>
> *[Answer (Q33]{.underline}). Question Skipped.*
>
> **Question 34.** Has any of the new data delivery mechanism been
> implemented in the controls?
>
> *[Answer (Q34]{.underline}). Question Skipped.*
>
> **Question 35.** What other enhancements to the existing controls need
> to be implemented?
>
> *[Answer (Q35]{.underline}). Question Skipped.*
>
> **Question 36.** Has any of the Instant Messenger / Chat been
> prototyped?
>
> *[Answer (Q36]{.underline}). None has been prototyped. 1) we have not
> had the resources to prototype this widget, 2) we have not needed this
> widget to date.*
>
> **Question 37.** Has the Situation Awareness control been implemented
> or is there a prototype or additional specification for this control?
>
> *[Answer (Q37]{.underline}). We have a prototype that does not
> function as required. The prototype was developed with the intent of
> \"flushing out\" requirements. It was not designed/developed to be the
> fully functional version.*
>
> **Question 38.** Has the Go / No Go control been implemented or is
> there a prototype or additional specification for this control?
>
> *[Answer (Q38]{.underline}). It has not been implemented. They will be
> furnished when the operations procedures are better defined and I have
> time to get these down on paper and worked into a set of widget
> requirements (should within the 1st month of contract start).*
>
> **Question 39.** We noticed something in the SOW that implied NASA
> wanted to do the HTML based help system internally. Is this correct?
>
> *[Answer (Q39]{.underline}). The .html files will be provided by NASA.
> The architecture to house the .html files will be developed by the
> vendor.*
>
> **Question 40.** Is this acquisition for an existing
> commercial product (perhaps with modifications), or for contractor
> services to develop the specified system? Please elaborate on the
> level of \"services\" (i.e., labor hours) desired vs. \"re-use of
> existing product software\".
>
> *[Answer (Q40]{.underline}). It is not for an existing commercial
> product. It will have to be developed by the vendor to meet the
> requirements in the SOW.*
>
> **Question 41.** If a vendor can provide a commercial product as a
> basis for meeting the requirement (rather than developing new
> software), how will the \"technical capability of key staff
> \"evaluation factor be determined?
>
> *[Answer (Q41]{.underline}). The key staff must still posses the
> skills outlined in the package. Technical phone support is a key
> component of this contract.*
>
> **Question 42.** The background section indicates that a proof of
> concept system has been created. Other than NASA personnel, who, if
> anyone, has worked on, or contributed to, the proof of concept system?
>
> *[Answer (Q42]{.underline}). Myself and several contractors.*
>
> **Question 43.** Are any commercial software products used in the
> proof of concept system?
>
> *[Answer (Q43]{.underline}). Yes. Rendezvous, AFVT, RobotHelp,
> Objective Studio Pro, Objective View, Stingray Foundation Libraries,
> Measurement Studio, ATL, VC++, Lead Tools Libraries, and COM .*
>
> **Question 44.** Does the contemplated purchase involve \"completion\"
> of - or any further work on - this proof of concept system? If so, the
> cost will be highly dependent on the state of that system and
> providing a fixed price for the work is virtually impossible by
> suppliers who are not already familiar with that system. Suppliers
> already familiar with it, if any, that propose to re-use any of the
> proof of concept system would likely have an unfair competitive
> advantage over others.
>
> *[Answer (Q44]{.underline}). Vendors must assume that the work
> performed to date has been largely used to help evolved/determine the
> necessary functionality. Vendors should not presume that they will be
> able to \"use\" anything we have developed up to this point. The
> requirement is to provide a system that complies with the items in the
> SOW. Vendors should bid based on the SOW. Before posting this
> synopsis, we determined that a fixed price vehicle was the best
> approach to use*
>
> **Question 45.** What source code, if any, will be a deliverable if
> part, most, or all of the requirement is met by a commercial off the
> shelf product?
>
> *[Answer (Q45]{.underline}). All code developed to integrate the NASA
> components into the commercial product.*
>
> **Question 46.** Presuming that the AHIC system is not intended to be
> a standalone system, what is its overall mission? In other words, will
> AHIC be part of a larger system/operation?
>
> *[Answer (Q46]{.underline}). Overall mission is to have a system that
> can be used to monitor vehicle subsystem during: operation testing,
> testbed testing, and vehicle integration testing.*
>
> **Question 47.** Will NASA consider Linux implementations or
> \"Windows-client\"/\"Linux-server\" architectures that meet the SOW
> requirements and support multiple concurrent users, particularly if
> this approach is shown to be more cost effective and easier to upgrade
> in the future? Please elaborate if possible.
>
> *[Answer (Q47]{.underline}). Any operation system implementation will
> be considered if it is deemed to meet all the SOW requirements.*
>
> **Question 48.** There are no requirements or guidelines specified for
> the \"final version\" of the items, so it\'s impossible to provide a
> fixed price quote for the final versions listed. Will NASA provide an
> alternative acquisition mechanism that solicits a firm quote for the
> prototype and deployment releases only, and cost-plus or time &
> materials bids for the unspecified final versions? If not, what other
> procurement options are available that allow vendors to bid only on
> work that is specified in the SOW?
>
> *[Answer (Q48]{.underline}). Vendors should bid based on the statement
> of work and the schedule provided.*
>
> **Question 49.** The SOW references \"Appendix C\" on page 4 and
> \"Appendix H\" on page 14, but no appendices are included. Are there
> other documents (these and others) available that clarify the
> requirements and/or mission environment? If so, will NASA make these
> available?
>
> *[Answer (Q49]{.underline}). Yes, this information will be provided
> upon contract. Note that the items being referenced are not very
> significant in the overall scheme. Information contained in the SOW is
> sufficient for furnishing quotes.*
>
> **Question 50.** The requirements for the situational awareness widget
> and image viewing widget are not sufficient to determine the desired
> functionality of these items. Please elaborate. In addition, will NASA
> consider products other than Rapid Imaging Software\'s that meet the
> functional requirements for these items?
>
> *[Answer (Q50]{.underline}). It is believed that the requirements are
> sufficient. We are willing to consider any other software package that
> provides the same funcationality as the Rapid Imaging Software AFVT
> components.*
>
> **Question 51.** What are the data sources for this system?
>
> *[Answer (Q51]{.underline}). The Command and Telemetry Computer,
> vehicle simulations, and the Waveplayer application will all be
> sources of data.*
>
> **Question 52.** What data stream format(s) will be input to the
> system?
>
> *[Answer (Q52]{.underline}). Rendezvous messages.*
>
> **Question 53.** Are there any requirements to support
> concurrent users (i.e., multiple workstations, as implied by the Chat
> widget) using the same data stream or playback/Wave Player stream?
>
> *[Answer (Q53]{.underline}). Yes, there will be multiple workstations
> concurrently running the software. They will be connect to a LAN.*
>
> **Question 54.** We assume the acronym MSID stands for measurement
> identifier, which is a common term used for space shuttle and payload
> data points. Is this correct? If so, what mechanism will the system
> use to link MSID\'s to specific vehicle data points?
>
> *[Answer (Q54]{.underline}). The vendor will be required to become
> familiar with our data distribution mechanism and add data listening
> capability to the widgets.*
>
> **Question 55.** Are there any requirements to monitor MSID\'s for
> limit checking, exceptions, stale or invalid data; perform engineering
> unit conversion, archival, or other data processing functions? If not,
> what system will provide these functions?
>
> *[Answer (Q55]{.underline}). MSID Limit checking will be performed by
> the vendor created widgets. Stale data information will be included in
> the data packets being received. Any exceptions will be handled by the
> widgets. Engineering unit conversions will be performed by the server
> machine (vendor not responsible for this) - but the vendor is required
> to develop and expression parser (per 2.5 in SOW).*
>
> **Question 56.** Is this procurement funded at this time?
>
> *[Answer (Q56]{.underline}). Yes**.***
>
> **Question 57.** The RFQ (\"Evaluation Criteria\" web link) requests a
> set of documents in para. 11, but the solicitation requires use of the
> on-line RFQ system. Should bidders provide both?
>
> *[Answer (Q57]{.underline}). Yes, provide both.*
>
> **Question 58.** The contract is for consulting services provided over
> a 12 month period.
>
> I would prefer to receive payment on a monthly basis rather than in
> one
>
> large sum. In the On-line RFQ can I change the \"Discount or Payment
> Terms\"
>
> from \'Net 30\' to \'Other\' and describe my desired payment schedule
> in the
>
> additional comments section?
>
> *[Answer (Q58]{.underline}). 12 payments will be fine. Please be aware
> that payments are made upon NASA's acceptance of the products
> received. If products are not accepted, invoices have to returned to
> the vendor, to be re-submitted, upon acceptance of the items. You may
> indicate your discount terms on the quote you furnish us, but even
> more importantly, on each invoice you submit*. The Treasury Rate (TBR)
> is often the most advantageous to both the vendor and the Government.
> It's recommended that any terms you propose accommodate a reasonable
> amount of time for product acceptance by NASA, otherwise, the payment
> terms automatically revert to a 30-day period.