C. RFP DATES

Technology ServiceRequest for Proposals

Justice Reference Architecture (JRA)

Services Task Team Phase II Project

IJIS Institute

Scott ParkerSenior Project [email protected](602) 616-1433

April 27, 2010

IJIS Technology Services - Request for Proposal

CONTENTS

A. ENGAGEMENT OVERVIEW............................................................................................................................ 3

Associated Project.......................................................................................................................................... 4

Engagement Sponsor(s)................................................................................................................................. 4

Deliverable Summary...................................................................................................................................... 4

C. RFP DATES..................................................................................................................................................... 6

D. REFERENCE MATERIAL ATTACHMENTS....................................................................................................6

E. STAKEHOLDERS............................................................................................................................................ 7

F. LOCATIONS..................................................................................................................................................... 8

G. DESCRIPTION OF EFFORT........................................................................................................................... 8

Activities........................................................................................................................................................... 8

Required Approach......................................................................................................................................... 9

Deliverables................................................................................................................................................... 10

Mandatory Staff Skills................................................................................................................................... 13

Desired Staff Skills........................................................................................................................................ 13

H. SIGNIFICANT DATES................................................................................................................................... 14

I. COMPENSATION............................................................................................................................................ 14

Labor and Materials Compensation.............................................................................................................14

Travel Compensation.................................................................................................................................... 15

J. SELECTION CRITERIA.................................................................................................................................. 15

K. PROPOSAL CONTENT REQUIREMENTS....................................................................................................15

of 15


Your firm is invited to submit a proposal to conduct activities and produce work products that directly support the IJIS Institute as outlined in this Request for Proposal. This highly-visible engagement will result in the development of several (exact number TBD) Service Specifications for the Services Task Team Phase II Project. The IJIS Institute encourages all member firms that possess the requisite skill sets and experience to submit a response.

A. ENGAGEMENT OVERVIEW

The goal of this engagement is to develop several Service Specifications documents. It is currently envisioned that these Service Specifications documents will be related to fusion center, law enforcement, courts, corrections, and probation and/or parole services. The specific Service Specifications to be developed will be chosen by the Global Services Task Team (STT) no later than June 30, 2010. These Service Specifications will follow the current templates and other components included in the Services Specification Package (SSP). A companion document, the Service Specification Guideline (SSG) provides a detailed explanation of Service Specifications and their associated components. A working draft of the SSG is provided in this document as well as a link to the JRA website. The SSG and SSP documents and available subsequent iterations will be used to guide Service Specifications development.

At a high level, a Service Specification includes a Service Description Document, Service Interface Description Document, Schemas and Sample Files for the Web Service, and other Related Information. A Service Specification will include descriptions of all business and technical aspects of the Service for implementation.

A complete Service Specification is a formal document which includes definition of:

the Capabilities made available through the service;

the Service Model that defines the semantics of the service by representing its behavior model, information model, and interactions; the policies that constrain the use of the service, and the service interface that provides a means of interaction with the service;

the Behavior Model defines the service process and actions

the Information Model describes the data which comprises the inputs and outputs of the service and its actions;

the Policies that constrain the use of the service; and

the Service Interface that provides a means of interaction with the service.

A Service Specification is analogous to the software documentation of an Application Programming Interface (API). It provides stakeholders with an understanding of the interface rules and service structure. The Service Specification provides service consumers with the information necessary to consume a particular service, and service providers with the information necessary to expose the service in a consistent and interoperable way.

This IJIS Institute engagement will be carried out on behalf of the National Center for State Courts (NCSC), the Bureau of Justice Assistance (BJA), and the Global Justice Information Sharing Initiative (Global) Services Task Team committee. The resulting Service Specifications will ultimately afford organizations and agencies within the justice and public safety communities with implementable specifications designed to reduce the cost and effort associated with service deployment. Additionally, development and publication of operationally-relevant Service Specifications will advance and speed adoption of Global JRA standards.

This solicitation is being issued as a request for proposal (RFP) that will result in the award of one or more contracts to one or more firms who will be responsible for completing the work under the direction and management of the IJIS Institute project manager. IJIS Institute encourages all member firms that possess the requisite skill sets and experiences to submit a response.

of 15


Candidate firms may wish to form teams consisting of multiple firms in order to assemble the ideal resources to accomplish this work. The IJIS Institute will only evaluate a single proposal from such a team and one firm must be the legal representative of any such team. IJIS Institute will confer neither an advantage nor a disadvantage to any submission which adopted such an approach.

Associated Project

On September 29, 2004, the Global Advisory Committee (GAC) unanimously adopted Service Oriented Architecture (SOA) and the recommendations in the report entitled; “A Framework for Justice Information Sharing: Service-Oriented Architecture (SOA)”. Global’s approval was based on the understanding that SOA is an approach which will result in a defined justice information sharing infrastructure and architecture.

The Global Infrastructure/Standards Working Group (GISWG), in a collaborative effort with the Office of Justice Programs (OJP), U.S. Department of Justice, published the Global Justice Reference Architecture (JRA) Framework, Version 1.8 in February 2010. This JRA document describes the important Justice Information Sharing Architecture concepts as well as the relationships between those concepts. The Global JRA also identifies, at a high level, the kinds of “components” (software systems, hardware infrastructure, policies, practices, intersystem connections, and so on) necessary to bring those concepts to life in the justice context. The Global JRA is generally not specific enough to govern the implementation of any individual software system. Rather, the JRA is a framework that guides implementations in general, with the aim of standardizing or harmonizing certain key aspects of those implementations to support reusability or interoperability. Specific information about Service Specification development can be found in the Global Justice Reference Architecture (JRA) Service Specification Guideline (SSG): Working Draft V 0.9.7.

Expanding on recent JRA efforts, the Bureau of Justice Assistance, Office of Justice Programs in the U.S. Department of Justice funded the Services Task Team Phase II Project as a collaborative effort between the National Center for State Courts (NCSC) and the IJIS institute.

The Global Services Task Team (STT) and associated support staff and ad hoc work groups will guide development of the Service Specifications developed by the selected subcontractor for this engagement. These Specifications will be based on concepts defined in the aforementioned Service Specification Guideline (SSG).

(NOTE: relevant documents are embedded within this document in section D).

Engagement Sponsor(s)

This project is being funded by the National Center for State Courts (NCSC) and such funding is contingent upon receipt of funds under the Bureau of Justice Assistance (BJA), award number 2009-DD-BX-K025, Services Task Team Project – Phase II (NCSC Project ID 91520.0000).

Deliverable Summary

This engagement will focus on the following six deliverables:

1. Active participation in onsite workshop meetings (which will involve the subcontractor’s facilitation of workshop activities and the creation of meeting notes and action items taken during workshop sessions).

2. Pre-meeting planning and preparation (as needed) and post-meeting documentation, material and follow-up.

3. Regularly-scheduled conference calls to ensure alignment with stakeholder expectations.4. Creation of weekly status reports (to be done while the Service Descriptions are being developed).5. Creation of post deliverable lessons learned/issues,6. Development of a “Development Set”.

of 15

http://it.ojp.gov/docdownloader.aspx?ddid=1215





NOTE: For the purposes of this RFP, a “Development Set” is one iteration of the development cycle described herein resulting in two related service specifications. Each iteration is expected to include 3 (estimated number) pre-meeting conference calls/web conferences, 1 – 3day face-to-face meeting, and 3 (estimated number) post-meeting conference calls/web conferences, along with weekly status reports and the creation of lessons learned and issues.

Although the specific number and topics are to be determined depending on scope and complexity of the services chosen by the STT, the STT will likely, albeit are not guaranteed to, choose service specifications for development based on the problem areas identified and recommended by STT’s 2009–2010 Priorities Definition Workshop held in Salt Lake City, Utah on October 27–28, 2009. (The full report is embedded below.) These recommended service specifications are in the areas of (excerpted from the report):

1. Disposition Tracking — Criminal history records nationwide are missing too many dispositions as a result of inconsistent/incomplete reporting of dispositions and inability to integrate some dispositions into the record. This leads to a lack of coordination among justice business processes across agencies. Criminal history records do not adequately track the actions and decisions that follow from a particular arrest (e.g., arrest event tracking).

2. Encounter Information Capture — Less effective downstream decision-making, as well as inefficiencies, result from a lack of electronic capture and sharing of information about law enforcement encounters with subjects. These encounters include traffic stops, subject encounters outside of vehicles, field interview/contact cards, computer-aided dispatch (CAD) comments and other information, incident reports, and crash reports. This area is important because it initiates the entire criminal justice process; without electronic information at this stage, it is more difficult to have information exchange downstream. Electronic sharing of suspicious encounters would help meet a need of fusion centers and therefore would support counterterrorism. This goes beyond the previously developed suspicious activity reporting (SAR) IEPD and related service specifications, since it seeks to examine the surrounding business process in which suspicious activity as well as other subject activities and characteristics are observed, documented, and reported.

3. Person Status — Practitioners nationwide do not have adequate access to a consolidated, complete (or near-complete) picture of a person’s status (registries, wants/warrants, criminal history, watch lists, licenses/registrations, etc.), location (e.g., is the person incarcerated and if so, where), expected dates of release/movement, risk assessments, etc. Much of this information is available but not in a streamlined form (requires access to diverse systems with no integration). It could include information from outside the justice community, such as information related to homelessness, use of social services, school information, results of harvesting social network data, etc. Protection of privacy and civil liberties in designing and implementing these services will be of paramount importance.

4. Charging Exchanges — We could significantly enhance efficiency by improving the electronic initiation of criminal cases through exchange of charging information. Charging documents include citations, bills of information/complaints, and indictments. Electronic citations/ticketing could lead to major financial savings for law enforcement and lower-jurisdiction courts.

5. Justice/Social Exchanges — There is a general nationwide lack of effectiveness in sharing information among justice agencies and health/social services agencies. Reentry is a well-documented problem and a high national priority and is included within the scope of this problem. However, there are other components, such as better information flow into mental health and other “problem-solving” courts (so that we can be more effective and efficient in providing alternative treatments versus incarceration, where appropriate), and potentially better social service support for families/children of incarcerated persons. Points of integration include prevention programs, domestic violence programs/shelters, drug/alcohol treatment facilities, etc.

of 15


B. PROPOSAL FOCUS, SUBCONTRACTOR(S) SELECTION, AND FLEXIBILITY

1. Proposal Focus – Although the exact number of service specifications to be developed is unknown, and the number of “development sets” are therefore also unknown, proposals should focus on a single (one) development set (including the financial portion of the response) – remember a development set includes 2 service specifications. This will enable all respondents to be evaluated on the same scope. In other words, responses should be submitted as if you were proposing to participate in one development set resulting in developing two service specifications.

2. Multiple Subcontractors – The IJIS Institute reserves the right, and is likely to select multiple subcontractors for the work indicated within this RFP. It is anticipated that if multiple subcontractors are selected, that each shall be assigned one or more development sets.

3. Flexibility – Due to the flexible nature of this engagement (particularly with regard to scope, scope changes, and the fluidity and/or inexactness of determining which specifications shall be ultimately developed), respondents are encouraged to include discussions regarding their flexibility to respond to changing requirements for the service specifications (example: optional artifacts being required) and their ability to respond quickly to unanticipated requests.

C. RFP DATES

Item Due Date(eastern time)

Notes

Statement of Intent

Midnight on 05/06/10

Email to [email protected] Note that responses to questions (below) will be distributed to any firm that submits

a statement of intent or question(s)

Questions Midnight on 05/06/10

Email to [email protected] All questions should be submitted in writing Responses to questions (below) will be distributed to any firm that submits a

statement of intent or question(s)

Proposals Midnight on 05/14/10

Email to [email protected] The attachments listed below and the content within this document should be

reviewed and should all be considered relevant to your creation of a complete and compliant response Specifically, The Proposal Content Requirements section of the RFP should

be used to guide and format your proposal content, paying special attention to the "selection criteria" which will be used to score and select the service provider

D. REFERENCE MATERIAL ATTACHMENTS

The following reference materials are attached for your reference and use:

Attachment Title NotesProposal Response Worksheet

Must be completed and returned with proposal. The project intends to complete the listed tasks as soon as possible. Please note that the dates are estimates and will likely change.

Proposal Response Document

Must be completed and returned with proposal.

of 15

mailto:[email protected]




Subcontractor Agreement

Carefully review this document to understand the terms and conditions that will apply under the associated contract.

Travel Reimbursement Guidelines

Review to understand IJIS Institute travel reimbursement policies and processes.

JRA Framework v1.8This document is a conceptual framework for SOA that is based on an industry standard, the OASIS SOA Reference Model, which was developed by a committee of industry and government SOA experts, including some of the GISWG members who authored the JRA.

JRA Service Specification Guideline (SSG) v0.9.7

This is a working draft of the Service Specification Guideline. The SSG provides detailed information on the contents required for each Service Specification. It serves as a guide and reference for developing the Service Specifications.

This document should be used as a reference to provide a rough idea of the content required within each Service Specification and to assist potential subcontractors determine the level of effort required in developing a Service Specification.

Fingerprint Information Service Specification (FPI)

RECENT SAMPLE OF A JRA SERVICE SPECIFICATION DEVELOPED DURING PHASE 1 (conforms to SSG v0.9.7)

More service specifications are available at http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1015

2010 STT Priorities Definition Workshop Report

This is the full report of the problem areas identified and recommended by the 2009–2010 STT Priorities Definition Workshop held in Salt Lake City, Utah, on October 27–28, 2009.

Other JRA reference documents can be found at the JRA Website:http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1015

Additional documentation (such as other JRA Service Specification project artifacts) will be made available upon request.

E. STAKEHOLDERS

1. The IJIS Institute will serve as the (prime) contracting authority to the selected subcontractor for this engagement. The subcontractor will receive direction from the IJIS Institute project manager. In cases where a consensus position cannot be reached, the IJIS Institute project manager will serve to provide an authoritative decision. All decisions are also subject to external review by NCSC, the STT, and BJA.

2. An Enterprise Architect was selected by the NCSC to work on this project as well. This position is totally separate, and in addition to, the IJIS Institute subcontractor(s). However, the selected subcontractor(s) are expected to work collaboratively during this engagement with the Enterprise Architect to leverage

of 15

http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1015



http://www.ijis.org/db/share/affiliates/Library/Statements%20of%20Work/Travel%20Instructions%20eff%202005-09-01.doc

http://www.ijis.org/db/share/affiliates/Library/Statements%20of%20Work/Travel%20Instructions%20eff%202005-09-01.doc

http://www.ijis.org/db/share/affiliates/Library/Statements%20of%20Work/LawEnforcementInformationExchangeDevelopmentProjectContract20051222.doc


the Enterprise Architect’s expertise and vice versa. The Enterprise Architect subcontractor will receive direction from the NCSC project manager.

3. The Services Task Team is playing a steering role for the overall project and will be available to provide advice and counsel to this engagement.

4. Public safety community representatives will participate in workshop meetings in order to provide subject matter expertise in developing a business decomposition of the specific domain and develop priority candidate service models. The selected subcontractor will be required to attend and actively participate in the workshop meetings and interface with the Enterprise Architect (and utilize related artifacts created during the workshops, such as the business decomposition) and may possibly be asked to facilitate one or more of the workshops in collaboration with the Enterprise Architect and STT Chair.

5. Industry representatives will also be present during workshops in a volunteer capacity to provide technology expertise and private industry representation. These industry representatives will differ from the selected subcontractor in that the role of the subcontractor will be to primarily focus on the activities and deliverables set forth in this document.

F. LOCATIONS

Face-to-face workshops will take place at locations and dates that are yet to be finalized. Tentative dates have been provided within this document but will likely change. It is currently anticipated that one, three-day workshop will be held at a minimum – per development set.

Conference calls and web conferences will be used as needed to facilitate real-time discussions. These remote meetings will be provided by the IJIS Institute so the contractor is not expected to incur connection costs.

It is anticipated that the majority of the work required to develop the Service Specifications will be completed remotely at the candidate’s desired work location.

G. DESCRIPTION OF EFFORT

Activities

The workshops will likely begin with a general problem area topic, so the discussion will need to progress to the business and technical decomposition along with the identification, refactoring, and prioritization of candidate services. The workshops will also result in description of conceptual and logical models documented in sufficient detail to support the subcontractor’s Service Specification development. A complete activity list (FOR A SINGLE DEVELOPMENT SET) appears below:

Pre-Workshop

1. Perform background research of the artifacts attached above.

2. Participate in a kick off meeting conference call.3. If required, work with the IJIS Institute Project Manager, Enterprise Architect, and STT Chair to develop

the workshop agenda (and/or other preparatory work) as required to guide and secure the necessary information to develop Service Descriptions.

4. Participate in three (estimated number) pre-workshop conference call(s).

Services Specification Development Workshop

5. One or two representatives from the selected subcontractor’s organization will travel to, and participate in, the workshop (location TBD, approx three days).

6. Facilitate portions of the workshop (in some instances this may or may not be required; guidance on requirements for facilitating the workshop will be provided by the STT Chair and Enterprise Architect).

of 15


7. Decomposition - Facilitate and lead, with the workshop participants, a business and technical decomposition of the particular domain (the domain will vary depending on selected problem areas) and create a list of business and technical capabilities within the domain.

8. Identification and Prioritization - Facilitate and lead, with the workshop participants, the creation of a basic Gap analysis of business and technical capabilities using business processes (use cases) as an input to create a candidate service list with brief descriptions. The prioritization portion will focus on taking the candidate services list (with the STT chair’s research findings on best practices for prioritization methods) and come up with a prioritized list identifying up to two services to model.

9. Service Modeling - Facilitate and lead, with the workshop participants, to expand on the service model material produced earlier. Begin describing the conceptual and logical models of the two prioritized services and may include (but will not be limited to) a list of inputs and outputs, an action list, assumptions and dependencies, and business use cases for the prioritized services. The result of this workshop will serve as the transition point in developing the service descriptions (two service specification outputs expected per workshop).

10. Compose meeting minutes, detailed notes and action items as they pertain to service description development.

Develop Service Descriptions

11. Participate in a post-workshop conference call(s) (as needed).

12. Work on other post-workshop action items (if any arise from the workshop).13. Develop two Service Specifications based on the Service Specification Guideline as well as information

and artifacts attained from the aforementioned workshops.a. Note that each Service Specification includes a NIEM IEPD as one of the artifacts. Depending

on the specification, three options for an IEPD artifact are possible: (1) use an existing NIEM IEPD; (2) modify an existing IEPD; or (3) create a new NIEM IEPD. The selected subcontractor must be able to handle each scenario as needed. The selection as to which option to use for a given Service Specification is up to the workshop participants, with the final decision being made by the project sponsor.

14. Participate in at least three (estimated number) web conferences with the workshop participants to discuss edits and comments related to the Service Specifications (each call is anticipated to last approximately three to four hours).

a. Take notes on proposed edits and comments.b. Ask questions to clarify requested edits and comments.c. Perform edits to the Service Specifications documents based on comments.

15. Develop and submit weekly development status reports to the IJIS Institute project manager (once Service Specification development has begun).

16. Participate in bi-weekly conference calls and provide development status (once Service Description development has begun - each call is anticipated to last approximately 0.5 hours).

It is required that if the Service Specifications are done sequentially that the first Service Specification be submitted for review as soon as it is complete.

Post-Development

17. Participate in creation of the Draft Project Report.

a. Provide all substantive inputs related to lessons learned and other findings while developing the Service Specifications and provide written suggestions on how the process could have been improved. (This is expected to be a fairly brief document, possibly one page.)

Required Approach

1. Unless indicated otherwise, the IJIS Institute project manager shall serve as the single point of contact for all communications.

of 15


2. The subcontractor shall supply any and all necessary development tools for the creation of Service Specifications and associated models. The use of Open Source modeling tools is encouraged.

3. The SSG will be used as a guide and template to produce the Service Specifications. Details for items that should be included within the Service Specifications are indicated within the Draft Service Specification Guideline, attached within this document. This is a draft document to provide an idea of the scope of work required. The document may change while the service descriptions are being developed but the general content should remain the same.

4. Any other work produced under this project shall be consumable by members of the BJA, STT, IJIS Institute, and NCSC community without requiring the purchase of any additional proprietary tools (e.g., work products may be MS Word or Adobe PDF files). If proprietary tools are used to create or publish the work products, the product artifacts must be provided in a format that can be read via non-proprietary or open source tools.

5. If the Service Specifications are done in sequence, the selected subcontractor will be required to submit completed draft Service Specifications for review so that issues and/or suggestions can be identified and relayed to the selected subcontractor in an efficient timeframe.

6. Candidates for any IJIS Institute consulting engagement are reminded that while consultants are performing the work of the engagement, they are representing the IJIS Institute and industry as a whole and are therefore discouraged from promoting any particular company’s products or services at any time during the engagement. The primary principle behind the IJIS Institute’s projects is to provide a company- neutral team that will focus their energy on the scope of work. Appropriate references to similar projects and lessons learned are encouraged as a method for validating recommendations. However, the emphasis of such references should be on the pertinent details of the engagement and not the firm(s) participating in the engagement.

Deliverables

Deliverables will include, but not be limited to, the following work products:

1. Service Specifications Artifacts

a. The subcontractor will create two Service Specifications based on information attained from the workshops. The Service Specifications must be based on the Service Specification Guideline, follow the structure of the Service Specification Package (SSP) and include at a minimum all SSP required artifacts. A working draft of the SSG is attached to this document to provide an idea of the components that will go into the Service Specifications. If the SSG is modified as revisions are made to the document (as a working document), a revised version of the document will be provided to the selected subcontractor.

b. Items in each Service Specification are described in detail within the Draft Service Specification Guideline embedded within this document. A list of artifacts contained in a Service Specification Package (SSP) is provided below. Depending on the individual service specification, some optional artifacts may be deemed as required during the workshop, development, and/or review phases. The Working Draft SGG document should be seen as the authority on these artifacts in regards to definition and for more detail.

Artifact Description File TypesRequired/Optional

Service Documents Metadata All metadata registered with the Service. xml, xhtml R

CatalogList of artifacts in the Service Package that is machine- readable; in an open, portable format; and browser displayable.

xml, xhtml R

CatalogA human readable version of the entire Service Specification Documentation.

html R

Service Description Document

This document is designed as a template for developing a Service Description.

txt, doc R

Service Interface Description Document

This document is designed as a template for developing a Service Interface Description.

txt, doc R

of 15



Information Model Documents

IEPDAll artifacts associated with the Information Exchange Package in a self-contained zip file.

.zip R

IEPD schemasAll schemas defined as part of the IEPD and usually located in the schema folder of the IEPD

.xsd R

IEPD samplesSamples defined as part of the IEPD and usually located in the sample folder of the IEPD

.xml, doc, jpg, pdf, gif

R

Exchange Context Model

The exchange context model as defined by NIEM in standard open format (xmi, vsd, zargo) and standard open graphic (jpg, gif, pdf, etc.). That is likely a Unified Modeling Language (UML) model.

xmi, zargo, jpg, gif, pdf

O

Various

Service Change LogRecord of cumulative changes from previous service versions. The initial service entry simply records its creation date.

xml, txt, doc

R

Service Change Log by Interface

Record of cumulative changes from previous service interface versions. The initial service interface entry simply records its creation date.

xml, txt, doc

R

Usage GuideExplains how a consumer would use the service. The usage guide would show typical binding and requests.

txt, doc R

Exceptions and Fault Documents

This guide would also include any information necessary to handle exceptions or faults generated by the service.

txt, doc R

Memoranda of Understanding (MOU) Documents

Memorandums of understanding among participating agencies. The service provider may requirement each consumer to sign a MOU before the consumption process can begin in production.

txt, doc O

Service Level Agreement Documents

This needs to match Service Level Agreement (SLA) documents/templates created by the M&P workgroup.

txt, doc O

Service Requirements Document

The service/software requirements document captures the complete software requirements for the system, or a portion of the system.

txt, doc O

Requirements Traceability

The requirements traceability matrix is a table used to trace project life cycle activities and work products to the project requirements. The matrix establishes a thread that traces requirements from identification through implementation.

xls, pdf O

Detailed Design Document

The purpose of this document is to bring all of the models together in one document which satisfies the requirements.

txt, doc O

Business Process Analysis

This document defines the business process model and requirements which supports/defines this service.

txt, doc O

Business Process Model

This is the actual document which describes the business process model for the web service. In many cases this can be used to import/export the process model for the service.

BPMN, BPEL, JIEM, UML

O

Use Case Specification

The use case specification contains information regarding the use case model of the service. This information could be part of the service description document or included in a separate specification document referenced by the service description document. The use case specification document contains use case diagrams and use case scenarios.

txt, doc O

Use Case Diagrams Use case diagram in standard open format and vsd, xmi, O

of 15



standard graphic, likely UML.zargo, jpg, pdf

Project Charter

A document that contains the project overview, scope, objectives, constraints, sponsors, and participants. This document is useful to gain a general understanding of the project/effort used to create this service.

txt, doc O

Test Cases

This document describes the specific functions and objectives for exercising the producers service. Specific actions are identified and measured against expected testing results and outcomes.

txt, doc O

Testing Results Report

Description and results of validation and conformance testing performed — may include testing output or products.

txt, doc O

Asset Cost

Document which identifies the cost for building the service package necessary to support the business capabilities. The asset cost is not cumulative (from version to version). Rather this documents the costs associated with this particular service package.

xls O

Interface FilesWeb Service

WSDLThe Web Service Description Language file for the service being implemented.

wsdl R

Sample SOAP Request(s)

Sample web service requests for this service which utilizes one of the actions defined for the service.

xml O

Sample SOAP Reply(s)Sample web service reply which corresponds to the web service request.

xml O

ebXML

ebXMLThe ebXML schemas files for the service being implemented.

xsd R

Sample ebXML Request(s)

Sample ebXML requests for this service which utilizes one of the actions defined for the service.

xml O

Sample ebXML Reply(s)

Sample ebXML reply message which corresponds to the ebXML request.

xml O

Security and Privacy Information

Security and Privacy Documentation

This document would identify the security and privacy necessary for accessing and handling the information provided by the service.

txt, doc, pdf

R

GFIPM MetadataThis is the GFIPM Metadata Schema and the respective sample XML which is used to authorize access to the service.

xsd, xml O

Access Control Policy Maps

This would identify all security federations and networks which this service is secured and available for use.

xls O

XACMLThe XML Access Control (XACML) representation of the security policy necessary for accessing this service.

xml O

2. Meeting Notes and Workshop Facilitationa. The selected subcontractor will be requested to develop meeting notes and to assist with

agenda creation for each workshop and include action items identified during the workshops.b. Detailed notes should also be taken to provide information needed to create the Services

Descriptions, as appropriate.c. The selected subcontractor will facilitate portions of the workshops, in which they are taking

notes. If needed, direction will be provided by the STT Chair and Enterprise Architect.3. Post-workshop Action Items

of 15


a. Post-workshop work products other than the ones listed in this document (including meeting minutes) are not anticipated. However, action items may arise from one or more of the workshops that require the selected subcontractor’s expertise to work on. If any action items for the selected subcontractor occur, they are not expected to be extremely time consuming.

4. Weekly Status Reporta. During the time the Service Descriptions are being developed, weekly status reports (emails are

sufficient) will be required (development of the service descriptions is expected to begin after the workshop is held).

b. Status reports will be used as discussion topics for the bi-weekly development conference call.5. Input of Narratives and Artifacts Required for Creation of the Project Report

a. Input to this document will be limited to the findings and lessons learned of this engagement.

All work products will become the property of the grant sponsor.

Mandatory Staff Skills

Address each item for each proposed team member in the response:

1. Experience developing functional SOA service requirements.

2. Experience developing and implementing SOA solutions, including web-services applications (experience with WSDL, WS-*, XML, and SOAP).

3. Experience developing and implementing ebXML.4. Experience creating graphical models of business use cases.

5. Experience writing business scenario narratives.

6. Experience with use of BPMN or similar open standards notation.

7. Experience creating UML diagrams.

8. Experience with SOA service identification.

9. Experience developing logical and conceptual models in a Service Oriented Architecture.

10. Experience creating NIEM IEPDs.

11. Experience implementing IEPD-based exchanges.

12. Experience facilitating IEPD development workshops.

Desired Staff Skills

Address each item for each proposed team member in the response:

1. Experience developing JRA Service Specifications.

2. Familiarity with the Justice Reference Architecture.3. Familiarity with the OASIS Service Oriented Architecture Reference Model.4. Experience with the JIEM model and JIEM tool.5. Experience/understanding of the law enforcement domain and business processes. 6. Experience/understanding of the corrections domain and business processes. 7. Experience/understanding of the courts domain and business processes. 8. Experience/understanding of the probation domain and business processes. 9. Experience/understanding of the parole domain and business processes. 10. Strong workshop facilitation skills.11. Strong writing skills.

of 15


H. SIGNIFICANT DATES

It will be assumed that firms responding to this RFP can support the following key activities and dates unless otherwise noted in the proposal. If exceptions are noted, proposals must provide new dates and/or activities under the ‘Schedule’ tab of the ‘Response Worksheet’ submission in the proposal. These dates are not final and are subject to change. A more detailed list of activities can be located in the ‘Response Worksheet’.

Also note that since any response should focus on a single development set, this schedule is representative of the first development set. If a subcontractor is selected for a subsequent development set, it is assumed that the final schedule will be worked out with the subcontractor’s input.

Tentative Schedule: First JRA Specifications Development Set

Activity / Deliverable LocationStart Date

End Date

Award Date n/a 05/28/10 n/a

Engagement Start n/a 06/01/10 n/a

Pre-Meeting Conference Call 1 & Kickoff n/a 07/13/10 n/a

Pre-Meeting Conference Call 2 n/a 07/23/10 n/a

Pre-Meeting Conference Call 3 n/a 08/04/10 n/a

Face-to-Face Meeting/Workshop TBD 08/25/10 08/27/10

Post-Meeting Conference Call 1 n/a 09/08/10 n/a



Submit Draft Service Specification to IJIS Institute Technical Edit n/a 11/01/10 n/a

Conference call to review Service Descriptions n/a 11/05/10 n/a

Submit Final Draft Service Specification n/a 12/07/10 n/a

Document Lessons Learned, Project Issues, and other items for final report.

n/a 12/07/10 12/14/10

Long Term Activities

Develop Service Specifications n/a 07/13/10 12/07/10

Bi-Weekly Development Conference Calls n/a 07/13/10 12/14/10

I. COMPENSATION

Labor and Materials Compensation

This work will be performed under a time and materials contract with a funding cap. Compliant proposals will not exceed a total cost (excluding travel expenses) of $100,000 (although candidates that justifiably exceed the cost will still remain under consideration) - remember, this proposal is for one (1) development set.

Reimbursement for labor, materials, and travel expenses must be submitted to the IJIS Institute within 30 days of incurring the expense and must include a description of the activity and related deliverable line item against which the charge applies.

Travel Compensation

Travel expenses will be directly paid for by the IJIS Institute or reimbursed by the IJIS Institute where prior arrangements have been made and authorized by the IJIS Institute project manager in compliance with the IJIS Institute travel and expense policy. A full description of travel reimbursement policies and procedures can be found in the attached “Travel Reimbursement Guidelines”. Important criteria include:

Airline travel to and from a designated site visit shall be made by the IJIS Institute travel coordinator.

Lodging will be coordinated and acquired by IJIS Institute travel coordinator.

of 15


Daily food and incidental per-diem rates will follow GSA guidelines in cases where meals are not already being provided as part a meeting or lodging.

Additional expenses may be covered provided that they are pre-approved by IJIS Institute staff.

J. SELECTION CRITERIA

The IJIS Institute uses a consistently applied selection methodology, performed by a team of evaluators. This methodology utilizes a formula that takes into consideration the criteria detailed in the table below. Selections will be based on evaluating to what degree each proposal and candidate complies with RFP requirements (compared to a like evaluation of other proposals and candidates) using the criteria weights defined below.

Scoring CategoryActivities 15%Required Approach 10%Schedule / Dates 5%Deliverables 10%Mandatory Staff Skills 20%Desired Staff Skills 10%Hourly Rate Calculation 10%Not to Exceed Cost 10%Total Hours 5%IJIS Institute Membership 5%

K. PROPOSAL CONTENT REQUIREMENTS

The IJIS Institute requires that candidate firms responding to this RFP must submit a proposal that adheres to the following proposal outline. A complete and compliant proposal includes a full response to the RFP sections defined in this section as well as a detailed description of any exceptions to information and supporting artifacts listed elsewhere. Additional relevant information, even if not requested, is welcomed.

Proposal Content (all are required):

1. Proposal Worksheet (MS Excel format – embedded in section D)

2. Proposal Response Document (MS Word format - embedded in section D)3. Résumés (Full resume for each proposed staff member involved in the engagement)4. List of Relevant Previous Work5. References and/or Reference Letters

Notes:

1. Exceptions include:

Requested modifications to the activity/deliverable list or associated dates. Requested modifications to documentation standards or processes which were specified. Requested modifications to terms and conditions in the Subcontractor Agreement contract. Requested modifications to the travel reimbursement policy.

END OF DOCUMENT

of 15

C. RFP DATES

Documents

Transcript of C. RFP DATES