Request for Proposals for Software Development Services Questions and Answers Question: What is the open-source license that the NIEM profile will be distributed under and how will the NIEM profile source code be made available? How much of this will be SEARCH responsibility and how much will be the vendor's? The choice of license will be determined during the course of the project. The source code will be available via the Internet, likely either via an open source repository such as GitHub or Sourceforge, or via direct download, or some equivalent mechanism. It is possible that SEARCH will place a feature on the backlog for the vendor to assist with packaging the code for final distribution, or for assisting with code modifications necessary to facilitate proper licensing. These features would be treated just like any other feature, in terms of estimating, pricing, delivery, acceptance, etc. Question: Will the Eclipse-based toolset also be distributed as open-source or just the NIEM Profile? It is possible that SEARCH will make available for download an instance of the Eclipse environment with the UML Profile Implementation plugins pre installed. All components developed by this project will be released under an open source license. The NIEM UML Profile itself is already publicly available via http://www.omg.org/spec/niem_uml/. Question: It looks like NIEM 3.0 will be available in Fall 2013. Will the release of the tools coincide with the release of NIEM 3.0? How far along is the current NIEM 3.0 definition? Will we be distributing NIEM 3.0 release candidates to the open source community on a regular cadence? We anticipate that this project will implement the current version of the NIEM UML Profile available at http://www.omg.org/spec/niem_uml/. This current version (1.0-Beta 1) is based on NIEM 2.1. It is possible that SEARCH will place features on the backlog for the vendor to implement application functionality related to the release of NIEM 3.0. These features would be treated just like any other feature, in terms of estimating, pricing, delivery, acceptance, etc. Question: If the toolset will be released in the fall, by then a new version of Eclipse will have been released based on the Eclipse release train schedule. Would it be possible to say that the toolset version will target Eclipse 4.2 or higher (to allow the possibility of a later Eclipse version if necessary)? Yes, Eclipse 4.2 or higher is appropriate. Any effort required to modify the NIEM UML Profile implementation to accommodate new Eclipse releases would be scheduled via features on the backlog. Question: It looks like Java 1.6 or higher is a requirement for the project. Is the 1.6+ JVM the requirement or the Java programming language itself? In other words, if the implementation team determines that another JVM language, such as Scala, will provide a significant advantage or cost reduction for the implementation of specific components of the application, will the implementation team be restricted from using these JVM-based languages? SEARCH is open to considering languages other than Java; however, use of such languages requires the explicit approval of the SEARCH project manager. Because Eclipse runs on the JVM, a JVM is a requirement, and SEARCH requires version 1.6 or higher. Page 1 of 6
The following questions are in reference to line 287 of the RFP: While Vendor will store and maintain source code at its facility, Vendor acknowledges and accepts that deliverables and artifacts, including but not limited to source code, documentation, scripts, tests, and the like, are developed as works for hire and are the property of SEARCH from the moment they are created. Question: Open source development typically leverages and sometimes modifies or extends other open source with existing licenses. It is not always possible for such work to be the exclusive property of SEARCH. Will SEARCH recognize and accept deliverables modifying or extending existing software owned by others and carrying their copyright, perhaps with copyright of any extensions belonging to SEARCH? SEARCH is open to considering the use/adaptation of existing open source software. The preference is to use such software in binary form rather than modifying its source code. The delivery of code for which SEARCH will not own the copyright will require the explicit approval of the SEARCH project manager. Question: Vendor has privately invested in software that will meet some SEARCH requirements. Vendor wishes to retain copyright or shared copyright in such intellectual property while potentially using it for SEARCH s project and licensing it as open source. Will SEARCH accept shared copyright for open source licensed intellectual property derived from vendors existing works? SEARCH is open to considering the use/adaptation of software owned by the vendor. The use of code for which SEARCH will not own the copyright will require the explicit approval of the SEARCH project manager. Such approval will require, at a minimum, that vendor release the software to SEARCH, and any other entity SEARCH may specify, under an open source license of SEARCH s choosing. Question: The payment methodology states that vendor may not be remunerated for work performed when delivery does not fit into a 2 week time window. Can it be made clear that SEARCH has rights to works only when vendor has been paid for such work, not the moment they are created? Yes, this is the intent. All code and other project artifacts that vendor produces under this project are works for hire. The following question is in reference to line 291 of the RFP: At the termination of the contract resulting from this RFP, Vendor will transfer possession of all deliverables and artifacts developed under such contract to SEARCH, and will destroy all copies in the Vendor s possession. Question: In that the deliverables being produced are open source, we do not understand the requirement for vendor to destroy all copies in the Vendor s possession. In addition, we cannot delete copies of pre-existing work. Can this requirement be removed? The requirement cannot be removed. Vendor will, of course, be free to obtain the source code from SEARCH under the open source license. Should SEARCH approve the use of vendor-owned software ( pre-existing work ), the final disposition of any modifications will be addressed by negotiation between SEARCH and the vendor. SEARCH cannot and will not require vendor to delete source code to software on which vendor owns the copyright. Page 2 of 6
The following question is in reference to line 230 of the RFP: SEARCH will maintain an ongoing list of potential NIEM UML Profile Implementation features. SEARCH, not the Vendor, is responsible for maintaining this list. While SEARCH would welcome suggestions as to potential new features from the Vendor, SEARCH will not compensate Vendor for time researching or evaluating potential features unless previously agreed in writing by SEARCH and Vendor. Question: Open source development typically involves multiple interrelated activities including dialog with users, support, understanding of requirements, presentation of capabilities, coordination of codevelopment, community engagement, training, maintaining and resolving issues, maintaining open source community resources, etc. In many cases such activities are intertwined with development activities and require developer expertise. Is the vendor expected to support any of these activities? How will vendor be compensated for engaging and supporting the community? While your characterization is true of some open source projects, SEARCH does not intend to make the source code to this project public until at or near the end of the project. Thus, there will not be coordination of co-development. Other tasks you have mentioned could be important, but will be handled largely by SEARCH. If vendor is expected to support such activities, they will be scheduled as features on the backlog. These features would be treated just like any other feature, in terms of estimating, pricing, delivery, acceptance, etc. The following questions are in reference to line 249 of the RFP: Once the features are selected for implementation, Vendor will provide within one (1) business day a firm, fixed-price bid for implementing each feature. After receiving the bid from the Vendor, SEARCH may adjust the scheduled features, in order to reduce the price, or for any other reason. Vendor will have an opportunity to provide a new fixed-price bid after any changes in the scheduled features. Once agreement is reached between SEARCH and Vendor, they will execute a work order via email formalizing the agreement. Question: While we applaud an agile process and have experience with agile development, the quoted fixed price per feature process is outside of our experience and seems to entail substantial risk on both sides while introducing a high administrative burden based on an arbitrary guess of required effort. It also introduces the requirement for precise specification of each feature that is not normally part of an agile process. Agile processes based on time and materials tend to be more fluid and limit risk by time boxing efforts and frequent interaction. Does SEARCH have experience with this process that can better inform vendors on how it works in practice? Would SEARCH consider a time and material basis for payment rather than feature based fixed price? Yes, SEARCH has experience with this process, and it works in practice as stated. SEARCH will not consider a time-and-materials basis for payment. Question: Some but not all features can be designed, implemented and tested in 2 weeks. For example: The NIEM-UML specification has specific compliance points that include multiple capabilities and features, such as producing a PSM (platform specific technology model) from a PIM (platform independent logical model). Such capabilities would normally (and most efficiently) be developed as a unit and such development would probably exceed 2 weeks. How are project components that will take longer than 2 weeks handled? Can iterations be defined in excess of 2 weeks? There will be no project components that will take longer than 2 weeks. SEARCH and vendor will, as part of the negotiation of each iteration scope, ensure that scheduled features can be completed within two weeks. Under exceptional circumstances, and mutual agreement of SEARCH and vendor, iterations can extend longer than two weeks. In SEARCH s experience using this process, such circumstances are rare. Page 3 of 6
Question: In that a turn around of one day for a fixed price bid (that may then be negotiated) may be difficult and interrupt the project flow; can the bid phase of the next iteration overlap the development phase of the prior iteration? The bid phase of iteration t always overlaps the development phase of iteration t-1. In SEARCH s experience, this rarely requires more than 1 day of elapsed time, but upon mutual agreement of SEARCH and vendor, it can begin earlier. In practice, SEARCH will likely inform vendor of intended features a few days before the end of the iteration. Question: Vendors may have pre-existing work that satisfies groups of features. Provided there is a positive cost/benefit, will SEARCH compensate vendor for making such work open source and utilizing it for the benefit of SEARCH? Can bids include such pre-existing work? As noted above, SEARCH is open to considering the use of software and source code on which vendor owns the copyright. The use of code for which SEARCH will not own the copyright will require the explicit approval of the SEARCH project manager. Such approval will require, at a minimum, that vendor release the software to SEARCH, and any other entity SEARCH may specify, under an open source license of SEARCH s choosing. Vendor is welcome to include, as part of vendor s proposal, a description of such existing software, with a description of components or layers in such software that vendor believes may be reusable, as part of its statement of capabilities. SEARCH does not intend to pay an up-front, lump-sum for existing software. Use of (and payment for) such existing software would need to fit within the specified process (payment upon delivery of prioritized backlog features). The following questions are in reference to line 267 of the RFP: If Vendor fails to implement a promised feature by the last day of the iteration, then Vendor will not receive payment for any resources expended in (partial) development of that feature. SEARCH may, at its sole discretion, schedule such a feature for inclusion in a future iteration s scope. Question: Agile processes recognize that not everything is known prior to starting development of a feature. In that work is expected to be incremental and agile this requirement seems unfair to vendors. Would SEARCH consider partial payment for work performed? Note that it is also possible that features could be implemented for less than the feature s fixed price. The small granularity of iterations and features is intended to mitigate the risk of the unknowns in feature development, for both SEARCH and vendor. SEARCH will not consider partial payment for work performed. Question: No software development is perfect, how and when is implemented determined? Are delivered features expected to be bug free? When SEARCH schedules features from the backlog for an iteration, SEARCH provides adequate detail to define what implemented means. Often this detail takes the form of test cases. In any case, vendor is free, during scope negotiation, to request clarification or more detail in order to refine its feature fixedprice. Because SEARCH requires vendor to maintain a unit test suite for the software and to maintain a continuous integration process, it will be easy for SEARCH and vendor to determine if the work of an iteration introduces bugs (defects). The results of any iteration are deemed not accepted as long as any such defects occur in the running of unit tests. SEARCH s acceptance of an iteration s work (features) includes acceptance of the suitability of the unit tests for those features. Page 4 of 6
SEARCH recognizes that there could be future enhancements to previously scheduled features. The existence of such enhancements is not considered a defect. Question: Is vendor expected to fix any issue under the fixed price, and if so for how long? How is subsequent development to address issues with prior development compensated for? As stated above, if an issue (defect) is introduced by a new feature, the defect will be apparent from failing unit tests, and the work of the iteration will not be accepted until the defect is fixed. Enhancement to previously implemented (and tested) features is considered new development and will be scheduled, priced, and delivered per the backlog maintenance process. The following question is in reference to line 344 of the RFP: Prospective Vendor s response must describe its experience and qualifications in the areas of public safety business analysis, information exchange design and implementation, and architecture. This experience and qualifications can include prior projects in the law enforcement, courts, corrections, probation, parole, motor vehicle administration, prosecution, and firstresponder domains. Vendor s response should identify team members familiarity with the National Information Exchange Model (NIEM). Question: As the work involves the creation of an Eclipse modeling tool intended for use by a broad audience, including but not limited to public safety, experience in public safety does not seem particularly relevant to the vendor s role. Of course NIEM expertise, technology, open source as well as tool development is very relevant. Can the requirement for specific domain experience be removed? The RFP does not require domain expertise in public safety only that the vendor s response can include projects in this area. SEARCH is well aware of the expertise needed to deliver this project and will score responses accordingly. The following question is in reference to line 319 of the RFP: The team must include at least one (1) full-time Java developer. The team will include a team lead role; this team member will be responsible for project management and coordination on the Vendor team. The team lead will be the primary point of contact for SEARCH on the project. The team lead must have at least five (5) years of experience working on the Java platform. Question: The Java experience requirement for the team lead seems to imply that the team lead (project manager) and primary Java developer must be the same person? May these roles be split? As stated in the RFP, the team lead must have at least 5 years of experience working on the Java platform. To clarify further, SEARCH requires that the team lead be a Java developer with 5 years of Java development experience. The following question is in reference to line 379 of the RFP: Financial Quote will be scored as follows: Vendor score = 10 x (highest cost Vendor cost) / (highest cost lowest cost) Where cost is the average of the hourly rates provided under Scored Requirement 5 above. Question: The above formula does not seem to recognize the quality of resources and the resulting difference in productivity, which can be substantial. Since cost is dependent on fixed price deliverables, not hourly cost, can expected productivity be factored into the financial score? SEARCH cannot factor productivity into the financial score. Quality of resources is measured under other requirements in the RFP and scored accordingly. Page 5 of 6
The following questions are in reference to line 62 of the RFP: This project will develop an open source implementation of the NIEM UML Profile. Question: Are there any other tools or software expected to be leveraged? For example, will an open source UML tool be extended to support NIEM-UML? As stated in the RFP, tool development will require use of EMF and UML metamodels available in the Eclipse framework, unless mutually agreed between SEARCH and vendor. The successful vendor will be encouraged to suggest tools and other mechanisms that would benefit the project; however, use of such tools must be agreed upon by SEARCH. Question: Some open source is co-developed with the community where as other open source is developed within a closed team. Each of these options implies a different project dynamic and leadership style. What is the expectation for this project? As stated in answer to a previous question, SEARCH intends not to expose the source code for the NIEM UML Profile implementation until at or near the end of the project. Thus SEARCH does not envision codevelopment with the community. However, SEARCH intends to engage key stakeholder groups within the NIEM and broader standards community at appropriate times to the benefit of the project. Page 6 of 6