RFP: Answers to Received Questions

1. RFP format

1.1 Please specify the RFP response format or information ArchivesSpace would like to see in the RFP response.

Proposals should be submitted in PDF format. Submit via email by 5:00PM EDT, Friday, October 14, 2011 to Mark Matienzo, ArchivesSpace Technical Architect (mark.matienzo@yale.edu), and Katherine Kott, ArchivesSpace Development Manager (katherine.kott@gmail.com). Please format the subject line with the phrase “ArchivesSpace Proposal – [Business/firm name of respondent]”

Proposals should include:

General qualifications and development expertise

• Information about development and project management skills and philosophy
• Examples of successful projects, delivered on time and on budget
• Tools and methods used for issue tracking
• Preferences for change control tools and methodologies
• Qualifications of project team members
• User centered development experience
• Experience developing software in the library and archives domain

Project specific strategies

• Proposed technical framework with specific examples of past success using the framework
• Potential licensing conflicts and proposed resolutions for frameworks, libraries, or other code to be used in development of the application
• Proposed staffing plan for addressing four development tracks
• Experience building scalable systems
• Experience dealing with large, deeply hierarchical data structures
• Experience integrating indexing systems with persistence layers
• Strategy for meeting functional requirements

2. Parties that may submit proposals

2.1 Will the ArchivesSpace project accept proposals from firms, individuals, or both?

See answer to 2.2.

2.2 What is the best way for an individual developer to get involved in the project?

The ArchivesSpace project will accept proposals from either firms or individuals. Individual developers are encouraged to consider posting to the ArchivesSpace Google Group if they are interested in creating a team with other individual developers to submit a proposal.

3. Identification of respondents

3.1 Who are the other bidders? If you don’t feel it is appropriate to name them, can you tell us how many individual contractors v. how many firms are bidding?

We will not know the answer to this question until proposals have been submitted (October 14th). We have received inquiries from both individual contractors and firms.

4. Development tracks

4.1 Under what terms may a contract, awarded or proposed, be a contract for less than the entire project?

See answer to 4.3.

4.2 Does the request for multiple tiers or structures during the proposal period imply granular combinations of awards?

See answer to 4.3.

4.3 Will you be awarding the contract to a single bidder for all 4 tracks, or might you potentially award the work to multiple bidders?

It is expected that a single vendor will perform the work of all tracks. The overlapping track durations are a suggestion, based on our analysis of anticipated resource requirements. If desired, the vendor may allocate resources in another way, as long as each track milestone is achieved on time.

5. Budget information

5.1 What is the available budget?

See answer to 5.2.

5.2 Can you specify the allocated budget for this project for the vendor portions?

The vendor should propose the budget it requires to complete the work on schedule.

6. Timeline

6.1 How much flexibility is there in the timeline?

The deadline for completion of the development work is part of the original funding agreement with the Andrew W. Mellon Foundation. Any changes would require the approval of the Mellon Foundation.

6.2 The to-date development chronology already is a long one. Given this, if a RFP response includes desirable improvements that require an extension to the 12-month project timetable, will it be considered?

Proposals may include recommendations for desirable improvements, including if they may require an extension to the current timetable for the project. Any improvements that fall out of scope may be subject to negotiation with the ArchivesSpace team.

7. Insurance

7.1 Would you please describe the scope of insurance that may be required of a participating entity?

New York University Insurance and Risk Management Department provides information about Minimum Insurance Limits on their website. The ArchivesSpace team will post a sample contract, including insurance coverage requirements by October 1, 2011. Note: In evaluating sample contracts for posting, the ArchivesSpace team determined that contracts can differ, and that posting a sample would be a disservice. Please refer to the Risk Management link above for insurance coverage information. See section 14 for licensing requirements.

8. Contract-related questions

8.1 Will there be any provision in the contract for change-of-work orders? If so, can change-of-work orders be initiated by either party?

Change orders may be negotiated in the contract with New York University.

8.2 The RFP states, “The selected contractor will provide programming staff as needed for ArchivesSpace, consistent with the functional specifications…” The RFP also states, “This will be a fixed price contract. Proposers must indicate their pricing separately for each track.“ First statement requires vendors to provide resources on need basis (typical in a Time & Materials contract), the second statement is requesting a fixed price. Are we expected to submit a fixed price approach (resource loading is determined by vendor based on the effort and schedule) or Time & Materials approach where ArchivesSpace determines the resource loading? As an alternate, can we submit a Time & Materials approach with budgetary estimates?

The contract will be for a fixed price. As described above in response to question #5, vendors may allocate resources within or across tracks as they wish, as long as they specify their pricing for each track and meet the deadline for each track.

9. Management of development

9.1 Is vendor expected to manage the development and take responsibilities for the deliverables?

The vendor is expected to manage the development in collaboration with the ArchivesSpace Development Manager, Technical Architect, and Technical Team. One possible model, using an Agile development methodology, would be for the ArchivesSpace team to provide a “product owner” while the vendor provides a “scrum master” to provide a single point of contact to coordinate project activities.

The vendor is responsible for the deliverables; the ArchivesSpace team is responsible for insuring that the deliverables meet requirements and specifications.

10. Location and meeting requirements

10.1 Will you consider proposals from firms with geographically dispersed development teams?

See answer to 10.2.

10.2 The RFP states, “The ArchivesSpace project staff is geographically distributed. There is no requirement for programming staff to be located in a particular place.” Can some or all of the programming resources be located at offshore delivery centers?

There are no constraints on the location of development teams or firms. We will consider proposals from respondents who use offshore delivery centers or have geographically distributed development teams.

10.3 How often should we expect to meet with/report to the project team for each track? In person (and if so, where, if not at NYU) or remotely?

Vendors should expect to meet with ArchivesSpace team members virtually (by phone, Skype, etc.) for a weekly “standup meeting.” Quarterly, in-person meetings may also be scheduled with locations to be determined by mutual agreement. Some meetings may occur in conjunction with conferences, such as the Society of American Archivists Annual Meeting.

11. Deliverables, acceptance criteria and testing

11.1 The RFP states: “Acceptance will include code review by ArchivesSpace project staff and component testing quality control by the ArchivesSpace Build/Release team at the University of California” Please provide us documentation which is used as standards for coding/testing/release by University of California.

See answer to 11.2.

11.2 What are the acceptance criteria currently defined for each track, if not listed in the functional specifications or technical architect’s report?

Acceptance criteria will be finalized in the contractual agreement between the vendor and NYU. Proposed criteria include:

• Confirmation that development meets acceptance criteria written into user stories
• Code passes review
• Technical test coverage is greater than 95%
• Functional test coverage is 100%
• Unit tests pass
• The application builds successfully
• The application deploys successfully
• Archon and Archivists’ Toolkit data import tests pass
• Export tests pass
• Scalability tests pass
• Functional tests demonstrate that specifications and functional requirements have been met
• User interface meets requirements
• APIs are well documented

11.3 Is the build and deployment team performing browser-based regression testing or is that responsibility assigned to the contractor? Is there a preferred QA testing methodology?

The vendor is expected to collaborate with the ArchivesSpace team to determine the best methods for testing, including user interface testing and browser-specific testing. The preferred QA testing methodology will include automated unit, integration, and functional tests.

11.4 Will there be a public beta? If so, who will the user testers be?

Members of the archival community will serve as testers. A small subset of the community will perform initial testing. A larger subset of the community may serve as beta testers.

11.5 Please provide the deliverables expected at each phase.

Specific deliverables for each phase will be negotiated between the ArchivesSpace team and the vendor as the project plan is formulated. Deliverables for each development cycle may include working code that meets a particular requirement, API documentation, test coverage, etc.

11.6 Who ultimately signs off work during the acceptance process?

The ArchivesSpace Technical Architect and the ArchivesSpace Development Manager have final signoff on work during the acceptance process. The Technical Architect and the Development Manager will consult with other members of the project team, but the decision ultimately lies in their hands.

12. Functional specifications and requirements

12.1 Are the specifications in the form as posted on the website in their final form?

The specifications as posted on the website are currently under review and revision by the ArchivesSpace Technical Review Team. We expect that the changes made to the specifications will not add functionality that is not already specified within the specifications themselves or the High-Level Requirements document. The revision process includes clarifying language and phrasing; refining technical requirements; identifying barriers to technical implementation, scalability and performance; and identifying integration points for other applications or platforms for archives, libraries, and other related domains.

12.2 How much flexibility is there in the scope of the project?

See answer for 12.3.

12.3 Is there going to be prioritized list of requirements?

A draft list of prioritized requirements is included in the High-Level Requirements document, available in the reports section of the ArchivesSpace website. Our review of the specifications and the high-level requirements will likely only produce slight modifications to the current prioritization (see 12.1)

There may be some flexibility in the scope of the project, guided by priorities for development as indicated in the high-level requirements.

12.4 The specifications do not include wireframes or UI design. Is the vendor expected to develop the wireframes and UI design?

No, the vendor is not expected to develop the wireframes and UI design. We anticipate that this work will be handled by a separate contractor. The ArchivesSpace Development Manager will coordinate work between contractors as necessary. However, please feel free to include information about your preferred method for working with designers in your proposal, or if you have experience in this area.

12.5 Vendors response is based on the specifications made available at http://www.archivesspace.org/documents/specifications/ – Resource Records specification is in preliminary draft. System Administration/Configuration Options and Staff Interface Design Principles are under development. When are these specifications expected to be released?

Draft versions of System Administration/Configuration Options and Staff Interface Design Principles will be available by September 30, 2011. The team anticipates that these specifications will be released by the end of October, 2011.

12.6 We assume if the specifications are not made available in time for our response, any changes to the specifications including the ones in draft and under development will be managed through change control process. Please confirm.

See the answer to 12.5 regarding release dates and other answers in section 12. Vendors should indicate any preferences or requirements regarding change control procedures in their proposal.

12.7 Are records imported in MARCXML, EAD, EAC, etc stored in its native format (ASIS) or mapped to a common format in ArchivesSpace?

Imported records that are expressed in a data structure standard such as MARCXML, EAD, or EAC, will be mapped to the underlying data model within ArchivesSpace. The ArchivesSpace team will be engaging in work over the coming weeks to refine the data model for the application. We will release information about the proposed data model through the ArchivesSpace website and through postings to the ArchivesSpace Google Group.

13. Use of existing frameworks or architectural components

13.1 ArchivesSpace Technical design meeting has identified several candidate technologies/frameworks for solution components, but final decision has not been made on the Architecture. Is vendor expected to develop the Architecture for the solution?

See answer to 13.3.

13.2 Can architectural components of Kuali/OLE, or another framework, be a value-add to have common interface with other open library systems?

See answer to 13.3.

13.3 Assuming all licensing criteria can be met, will ArchivesSpace consider responses that propose the use of an established and widely-adopted content management framework (e.g. Drupal) or an established MVC-patterned framework (e.g. Symfony2, CodeIgniter, et al.) to construct selected components identified in the core programming, functional programming, and reporting tracks, including but not limited to the authentication subsystem, field validation, format syndication, resource description, and authority control?

Development plans or recommendations within your proposals can include plans for development of architectural components or frameworks or recommend use of existing components or frameworks. Existing components and frameworks can either be those developed or maintained by the respondent as well as those available within the greater open source community. Proposals that include recommendations of existing frameworks or components should address the licensing requirements for the application (see section 14 “Licensing” of these answers and paragraph 3 of “Statement of Needs” in the RFP document).

Frameworks and applications from the archives domain, or related domain areas, such as libraries and museums of are of particular interest to the ArchivesSpace from the standpoint of integration. If you choose to include developing the product using a framework from one of these domains within your proposal, please include a clear articulation of the value of using the recommended framework or application and the benefits of integration between the product and the recommended framework or application.

14. Licensing

14.1 Will there be a future opportunity for releasing a “community edition” of the resulting ArchivesSpace product under a GNU General Public License?

The ArchivesSpace is committed to releasing the product as open source. The application and source code will be released under the Educational Community License (ECL) version 2.0. ECL 2.0 consists of the Apache 2.0 license, modified to change the scope of the patent grant to be specific to the needs of the education communities using this license.