Request for Proposal Outsourcing OIST · 1 Cover page Request for Proposal Outsourcing of Redesign...
31
1 Cover page Request for Proposal Outsourcing of Redesign and Upgrade of OIST Website Okinawa Institute of Science and Technology Promotion Corporation August 15, 2011
Transcript of Request for Proposal Outsourcing OIST · 1 Cover page Request for Proposal Outsourcing of Redesign...
1
Cover page
Request for Proposal Outsourcing of Redesign and Upgrade of OIST Website
Okinawa Institute of Science and Technology
Promotion Corporation
August 15, 2011
2
Table of contents page
Contents 1 Introduction .............................................................................................................................. 4
1.1 Purpose of Request for Proposal ....................................................................................... 4
1.2 Background........................................................................................................................ 4
1.2.1 OIST ............................................................................................................................ 4
1.2.2 OIST Web/Communications/IT .................................................................................. 4
1.2.3 Existing Content Management Systems and Websites.............................................. 5
1.2.4 Systems Infrastructure/Hosting ................................................................................. 5
1.2.5 OIST Content Managers ............................................................................................. 5
1.2.6 Enterprise Systems Integration .................................................................................. 6
1.3 Service Location................................................................................................................. 6
1.4 Term of Agreement............................................................................................................ 6
1.5 Completeness and Compliance ......................................................................................... 6
1.6 Official Issuing Contact ...................................................................................................... 7
1.7 Definition of Terms ............................................................................................................ 7
2 Schedule of Events .................................................................................................................... 7
3 Proposal Information and Processes ........................................................................................ 8
3.1 Compliance with Specifications......................................................................................... 8
3.2 Intent to Respond.............................................................................................................. 8
3.3 Decline to Offer ................................................................................................................. 8
3.4 Required Proposal Format................................................................................................. 8
3.5 Requirements for Return of Response .............................................................................. 8
3.6 Questions and Clarification ............................................................................................... 9
3
3.7 Vendor Presentations ........................................................................................................ 9
3.8 Rights Reserved by OIST and Restrictions on RFP Process ................................................ 9
4 Vendor Information and Qualifications .................................................................................... 9
4.1 General Corporate and Contact Information .................................................................... 9
4.2 Vendor Experience .......................................................................................................... 10
4.2.1 Drupal Specific Experience....................................................................................... 10
4.2.2 Domain and Development Experience .................................................................... 13
4.3 Vendor Client List References.......................................................................................... 14
4.4 Value Added Services ...................................................................................................... 14
4.5 Relevant Litigation/Investigations ................................................................................... 15
5 Scope and Specifications ........................................................................................................ 15
5.1 Scope ............................................................................................................................... 15
5.1.1 Main Activities.......................................................................................................... 15
5.2 Specifications................................................................................................................... 18
5.2.1 Setup and Operational Requirements...................................................................... 18
5.2.2 Non‐functional Requirements.................................................................................. 20
5.3 Drupal Functional Requirements..................................................................................... 22
5.3.2 Migration Timeline Requirements ........................................................................... 25
5.4 Deliverables ..................................................................................................................... 26
5.5 Additional Scope of Work................................................................................................ 26
5.5.1 Development Services.............................................................................................. 26
5.5.2 Additional New Sites ................................................................................................ 27
5.6 Independent Verification and Validation ........................................................................ 27
6 Appendix A: Glossary .............................................................................................................. 28
4
1 Introduction
1.1 Purpose of Request for Proposal The purpose of this Request for Proposal (RFP) is for the Okinawa Institute of Science and
Technology (OIST) to establish a contract with a Vendor that will create a comprehensive,
integrated web system to accommodate the current and future needs of OIST using a
content management system (CMS) built on the Drupal open source software platform.
The intended scope of this RFP includes obtaining the software and planning, design,
implementation and testing services required to install, implement, migrate, and support
the new CMS, any installed modules, integration with other systems, or additional
enhancements.
1.2 Background
1.2.1 OIST The Okinawa Institute of Science and Technology Promotion Corporation (OIST PC) was
founded by the Japanese government with the goal of creating a world‐class research
institute in Okinawa. At OIST all research and education is conducted in English, half of
the faculty is recruited from overseas, and half of the student body and faculty body is
planned to be non‐Japanese. OIST PC will transition to a School Corporation (OIST SC) in
November 2011 and begin accepting students as a graduate school in September 2012.
To coincide with this transition, OIST is seeking the creation of a comprehensive,
integrated web system to unify and integrate current external, internal, and auxiliary
websites and support the needs of a graduate school. Of particular importance is the
launch of new public facing external sites for the November 2011 transition to a
graduate school.
1.2.2 OIST Web/Communications/IT OIST currently uses staff resources from Communications and IT sections to support
Web‐related projects, management, and operations. OIST is considering the
establishment of a formal Web Strategy Counsel to provide direction and guidance for
OIST’s overall Web strategy, implementation, standardization, resource needs, reporting,
and policies. OIST also maintains an IT Infrastructure Working Group to coordinate
activities for improvements to core IT systems and policies, including Web application
systems, usage, and security.
5
OIST is introducing a new Graphics Standard Manual and official logo to unify its visual
presence and brand. To support the transition to a graduate school and the introduction
of the Graphics Standard Manual, OIST intends that the implementation of a
comprehensive, integrated web system will unite all of its websites under a single CMS,
with the goal of streamlining management and oversight and offering users a consistent
and extensible system for internal and external use, regardless of whether users are on
campus or not.
1.2.3 Existing Content Management Systems and Websites Currently OIST maintains a number of websites and systems for managing content. The
current external website runs on a vendor‐customized version of the Joomla open
source CMS platform (PHP, Linux server) which has proven insufficient and cannot be
updated or extended very easily. The current internal website runs on an internally‐
supported DotNetNuke open source CMS platform (ASP, Windows server), and it has
proven insufficient for the needs of the administrative and research community. Public
websites for research units and websites for workshops and courses run by research
units are hosted on several servers at OIST Campus, Seaside House, and IRP in Uruma
City using a number of different architectures, platforms, and software, from static
HTML to DokuWiki to researcher‐built custom scripts. The OIST Welcome Club and
Human Resources section have set up two wikis hosted on Google to offer OIST
employees and families a venue for creating a community and exchanging information
on living and working at OIST. In the absence of an available, flexible, well‐maintained
internal website, many departments in the administration have set up section‐specific
websites. The appearance and branding of these many websites lack consistency and do
not match the new official OIST Graphics Standard Manual. What is more, these internal
websites are not accessible outside of the OIST intranet.
1.2.4 Systems Infrastructure/Hosting Currently OIST IT department provides and maintains all IT systems infrastructure and
hosting for known and identified websites.
1.2.5 OIST Content Managers OIST will have a wide variety of content managers from various departments, units, and
sections comprised of administrative staff, faculty, and students. The majority of the
content managers will be non‐technical staff with little knowledge or need for
knowledge of HTML to perform basic content management tasks as part of their regular
responsibilities. Common content management tasks performed by content managers
6
include but are not limited to adding new content, uploading files, editing/deleting
existing content, adding new menu items, and editing/deleting menu items. Workflow
processes and rules governing the use and publishing of content are intended to be
implemented as part of the web CMS.
1.2.6 Enterprise Systems Integration OIST is planning for a series of enterprise‐wide IT system deployments by the end of
2011 including the following:
• ERP
• ECM/Document Management (OpenText, Alfresco)
• Accounting/Payroll
• Directory Services (Microsoft Active Directory/LDAP)
• Email/Messaging (Microsoft Exchange)
• Portal (ITER YWC project, joint effort between OIST and ITER)
• LMS (Sakai)
Selection of Drupal as the web CMS platform was made in part based on the ability to
integrate with a wide variety of enterprise systems.
1.3 Service Location Vendor will meet onsite with OIST stakeholders in the early planning stages to develop
and finalize details of the project, but the development of the system will take place
offsite. The number of and timing of these meetings should be included in the proposal as
part of the overall development project plan.
1.4 Term of Agreement The initial contract duration will be one year, during which the firm will complete the
initial development of the external sites in preparation for the November announcement,
and the subsequent development of internal subsystems like unit and section subsites. At
the time of the initial contract, approval will be sought for a contract for the initial
support and adjustment period.
1.5 Completeness and Compliance In the initial phase of the evaluation, proposals will be reviewed for completeness and
compliance with all requests and requirements, including proposal instructions,
specifications, and terms and conditions of the RFP. Proposals that fail to comply with the
essential requests and requirements of the RFP may be rejected as non‐responsive and
7
eliminated from further consideration. Vendors should understand that RFP terms,
conditions, and technical specifications do not fully identify nor completely define OIST’s
service requirements and satisfaction. The successful Vendor shall be expected to work
closely with OIST’s designated representatives to deliver an effective and efficient solution
resulting in high overall customer satisfaction.
1.6 Official Issuing Contact Procurement Section, OIST
1919‐1, Tancha, Onna‐Son, Kunigami, Okinawa 904‐0412 Japan
Tel: +81‐98‐966‐2293. Fax: +81‐98‐966‐2887
E‐mail: [email protected]
1.7 Definition of Terms See Appendix A: Glossary included with this RFP. Please note that any special terms which
are not identified in this RFP may be identified separately in one or more attachments.
2 Schedule of Events The schedule of events presented below represents OIST’s best estimate of the schedule
that will be followed. However, delays to the procurement process may occur which may
require adjustments to the proposed schedule. If an activity on this schedule is delayed, the
rest of the schedule may be shifted as appropriate. Any changes to the dates up to the
closing date of the RFP will be publicly posted prior to the closing date. After the closing
date, OIST reserves the right to adjust the remainder of the proposed dates, including dates
for evaluation, negotiations, award, and contract terms on an as needed basis with or
without notice.
Description of Activity Due Date RFP released 15‐August Written questions submitted to OIST 24‐August Responses provided from OIST on website 26‐August Proposals due 5‐September Proposal evaluation and screening completed 9‐September Vendor presentations TBD Final evaluation by committee TBD Finalize contract terms 20‐September Notice of award 20‐September
8
3 Proposal Information and Processes
3.1 Compliance with Specifications Vendor proposals must satisfy all project specifications, and vendor must satisfy
qualifications listed in this RFP.
3.2 Intent to Respond OIST requests that any Vendor who intends to respond to this RFP send notice via email of
their intent to respond to the Official Issuing Contact identified in this RFP. Receipt of the
intent to respond email will ensure that the Vendor will receive copies of any additional
information or changes to this RFP.
3.3 Decline to Offer OIST requests that any Vendor who receives a copy of this RFP but declines to respond
send notice via email of their decline to offer to the Official Issuing Contact identified in
this RFP. Receipt of the decline to offer email will ensure that the Vendor will not be
removed from consideration for future engagements.
3.4 Required Proposal Format OIST requests no specific format. However, the Vendor’s proposal should include the
following items;
• Company name (full legal name).
• Company address (corporate headquarters)
• Contact person’s name
• Telephone number
• Email address
• Quotation (cost estimation) (The quotation shall include any costs related to the
scope and specifications)
OIST does not bear any costs for preparing the proposals.
3.5 Requirements for Return of Response • All proposals must be submitted in electronic format.
• The Vendor may withdraw a proposal prior to the due date.
• Late submissions will not be accepted by OIST.
• A legally authorized representative of the Vendor must sign the proposal.
• The ability of OIST to open all electronic information submitted must be verified by
OIST Procurement department prior to acceptance.
9
3.6 Questions and Clarification All questions concerning this RFP must be submitted in writing via email or fax to the
Official Issuing Contact specified in this RFP. No questions other than written will be
accepted, and no response other than written will be considered binding upon OIST. All
Vendors must submit questions by the deadline specified in the Schedule of Events. OIST
retains the right to accept or deny questions submitted late or by another method.
Questions about this RFP are expected to be submitted by email or fax. OIST requests no
specific format, however, the questions should include following items;
• Name of company submitting the question
• Question number (1, 2, 3…) and corresponding relevant section of the RFP (3.6)
• Contact person’s name
• Telephone number
• Email address
3.7 Vendor Presentations OIST reserves the right to invite Vendors to present their proposal factors and solutions to
the evaluation team.
3.8 Rights Reserved by OIST and Restrictions on RFP Process
• OIST reserves the right to reject any or all proposals, including by way of example
only and without limitation, any proposal that does not contain all the requested
information.
• OIST reserves the right to award in part, in whole, or not at all.
• OIST is the sole owner of all data and information contained within this RFP and
any related attachments. Vendors shall use this information exclusively to prepare
their response. Vendors should not disclose this information to any other company
or use it for any other purpose unless required by law or legal process.
4 Vendor Information and Qualifications
4.1 General Corporate and Contact Information Please provide the following information for all Vendors that are represented in the
response to this RFP. If more than one Vendor is represented, please indicate the primary
and secondary Vendor relationships.
• Company Name (full legal name)
• Company Address (corporate headquarters)
10
• Other Office Locations (list all locations if multiple offices)
• Authorized Contact Person’s Name
• Telephone Number
• Email Address
4.2 Vendor Experience The following areas outline the types of experience and background that OIST is
requesting from Vendors for the purposes of this RFP. OIST recognizes that it may be
desirable and practical for Vendors to work in partnership with other Vendors for the
delivery of the services requested. In the same spirit of community and global
collaboration that is part of its mission, OIST is fully supportive of this approach.
4.2.1 Drupal Specific Experience
4.2.1.1 Drupal Software Relationship and Community Involvement The Vendor should be committed to involvement and support with the Drupal open
source software project and community. OIST expects the Vendor to demonstrate a
desire to give back to the Drupal community through participation in commonly
accepted activities and events.
• Vendor is encouraged to provide a list of activities including but not limited to
posts, articles written, events attended, participation in local meet‐ups,
sponsorships, code contributions, presentations given, partnerships, and/or
other evidence to indicate that the Vendor has an understanding of Drupal
software and involvement in the community.
4.2.1.2 Drupal Project Experience The Vendor should have experience in creation and migration projects with a Drupal
CMS solution. OIST expects references from previous customers for similar sized
education, government, or corporate organizations.
• Vendor should provide references for which similar services to those described in
this RFP have been provided during the past three years. The list should include
company name, address, contact name (name, title, email, and telephone),
company website URL, and description of services delivered.
• Vendor must also disclose any services terminated by any client and the reasons
for termination.
Please note that OIST reserves the right to use references developed on its own. Also
11
note that vendor references and experience will be heavily weighted in the selection
process.
4.2.1.3 Drupal Functionality Experience The Vendor should have experience in the capabilities and use of core Drupal
functionality and a wide range of contributed Drupal functionality including modules,
themes, and installation profiles (distributions). OIST expects the Vendor to be well
versed in the development and implementation of D6 and D7.
• Vendor should provide examples from previous project engagements where they
have worked with key functionality identified in this RFP including but not
limited to Organic Groups, custom workflows, and automated creation of
subsites.
Please note that OIST expects the Vendor to demonstrate in‐depth experience with
Drupal functionality and capabilities, such as:
• Structure and display including CCK, Views, Panels • Administration
• Granular access rights and authorization • Content and functionality staging and development
• Content and SEO including URL paths, printer/email/PDF versions, redirects,
sitemaps, meta tags, page titles
• Navigation and organization including menus, taxonomy, breadcrumbs
• WYSIWYG editors and image uploading
• Video and image handling including ImageAPI, ImageCache, Imagefield, Lightbox
• User profile, ratings, and notifications • Marketing including Webform, Google Analytics
• Events and calendars • Development including Devel, Drush
4.2.1.4 Drupal Support The Vendor should have the ability to provide ongoing support post creation and
migration of the Drupal CMS solution. OIST expects the Vendor to offer directly or
through partnership help desk support, Drupal software support to OIST to
troubleshoot major problems with stability and functionality, assistance with applying
appropriate patches and fixes for Drupal, and testing of module installations and
upgrades. More specifically, OIST expects the Vendor to ensure that all modules
12
installed by the Vendor will work with all other existing components of the system at
least to the current level of functionally agreed upon by OIST. If installation of a module
breaks another module or component of the system, OIST expects that the Vendor will
troubleshoot the issue and provide a solution. The Vendor is expected to keep track of
when new versions of installed modules become available and to take the lead to
schedule version updates when appropriate. OIST expects that the Vendor will be able
to demonstrate procedures for dealing with system downtime and outages, both
planned and unplanned, and best practices for monitoring the Drupal CMS
environment.
• Vendor should provide a description of their support services and processes, including but not limited to help desk, trouble ticketing, Service Level
Agreements (SLAs), maintenance and patching routines, test plans, downtime
procedures, monitoring systems, and incident management.
4.2.1.5 Drupal Customizations and Quality Assurance The Vendor should have the ability to manage customizations and quality assurance of
a Drupal CMS solution. OIST expects the Vendor to demonstrate experience with code
customization, security, integrity, and QA testing.
• Vendor should provide description of how customizations to Drupal code and
security were managed during previous project engagements.
4.2.1.6 Drupal Training The Vendor should have the ability to provide training to all levels of users with a
Drupal CMS solution. OIST expects the Vendor to provide sample training materials
from previous project engagements to demonstrate experience with training different
user levels at an organization.
• Vendor should provide training samples including but not limited to
adding/editing content, creating new websites, creating/cloning sites,
maintaining existing sites, and developing user training.
4.2.1.7 Drupal Architecture The Vendor should have experience with installation of a Drupal CMS solution in
development, staging, and production environments. The Vendor should be
knowledgeable in the architecture, planning, and configuration of Drupal‐based
software applications both in virtualized public cloud and/or private cloud
infrastructure and physical server implementations.
• Vendor should provide implementation plans from previous project engagements
13
for development, staging, and production servers including but not limited to
scalability, performance, and security.
• Vendor should provide names of cloud hosting partners, list of client
engagements, and descriptions of hosting architecture implemented from
previous engagements.
4.2.2 Domain and Development Experience
4.2.2.1 Scientific Research and Education Experience The Vendor should have experience working with and building web systems for publicly
funded scientific research and education institutions similar to OIST in scope and
mission. OIST expects the Vendor to demonstrate expertise and understanding with
how to work with these types of clients, build consensus and knowledge sharing, and
support the many facets and goals of the organization.
• Vendor should provide reference contacts from previous project engagements
with scientific research and education institutions.
4.2.2.2 CMS Strategy and Migration The Vendor should have experience in developing comprehensive migration strategy
and plan for multiple different CMS platforms. OIST expects the Vendor to provide
clear and concise plans for how they will migrate content from the current CMS
installations and various content repositories to a Drupal CMS solution.
• Vendor should provide a high‐level plan outlining the major activities and tasks
involved in migrating content from existing CMS and other repositories
identified in this RFP including but not limited to how migration may be
automated, known issues to look for, and example timelines.
• Vendor should provide a list of open source and commercial web content
management, document management, and enterprise content management
software that they have experience with implementations and migrations from
previous project engagements.
4.2.2.3 Agile Development Practices and Project Management The Vendor should have experience with Agile development practices and project
management approaches, such as Kanban, Scrum, and XP. OIST expects the Vendor to
demonstrate use of agile approaches to standard project activities including but not
limited to scope management, requirements management, estimating, budget
management, schedule management, communications, performance measurement,
14
quality assurance and testing, risk management, resource management, and change
control. OIST intends that the implementation outlined in this RFP be performed using
Agile practices with multiple iterative development and release cycles during the
course of the project.
• Vendor should provide description of their Agile development and project
management practices including use of their project management tracking
tools, source control systems, and release management processes.
• Vendor should provide a high‐level project plan with estimated milestones
outlining an agile approach with multiple iterative release cycles for completion
of the project.
4.2.2.4 Distributed Team Collaboration The Vendor should demonstrate experience working with distributed project teams
spread across multiple locations and time zones. OIST expects the Vendor to have
experience working with and managing multiple project team members in a distributed
manner including but not limited to internal staff of the Vendor, external staff in
partnership with other companies, and external staff from the client.
• Vendor should provide description from previous project engagements of how
they have both managed and been involved in projects requiring use of
distributed teams.
• Vendor should provide list of communication and collaboration tools that they
use to facilitate working with distributed teams and brief description of how
team members use them in daily activities.
4.2.2.5 Staff Experience The Vendor should have the ability to assign highly qualified and experienced staff
members in key project positions.
• Vendor should provide resume or CV of Project Manager.
4.3 Vendor Client List References The list of client references explained in the Drupal Project Experience section above must
include scientific research and education institutions.
4.4 Value Added Services Vendors may describe other value‐added services that they can make available and deem
applicable to OIST but not necessarily addressed in this RFP. OIST shall determine which
value‐added service options shall be most beneficial from both a cost and service
15
standpoint, and may further negotiate these options to include or omit dependent on the
needs of OIST.
4.5 Relevant Litigation/Investigations Vendors must describe any current lawsuits, legal actions, or governmental investigations
against their company including but not limited to parties of dispute, any equipment
affected, cause of action, jurisdiction and date of legal complaint.
5 Scope and Specifications
5.1 Scope The scope for this RFP is to select a Vendor that will provide a comprehensive set of
services to develop and deploy a Drupal‐based CMS, implement and migrate content to
the Drupal‐based CMS replacing the existing content and web publishing systems, and
support the Drupal‐based CMS while offering ongoing web development services.
5.1.1 Main Activities The main activities being sought include but are not limited to:
• Planning
o Conduct 2‐3 on‐site planning meetings with stakeholders.
o Producing high‐level planning document which outlines:
Project goals
Roles and responsibilities for all parties involved
Project timeline, including deliverables
Design brief
Working architectural site map
Working implementation specification, including:
• All modules and distribution packages
• All anticipated customizations
• Interface and design
o Produce home page wireframes showing content types, relationships, and
relative placement which are then refined in response to OIST input
o Present 2‐3 home page graphic concepts which are then refined in
response to OIST input
o Produce sub‐page graphic concepts based on finalized home page
concepts
16
o Produce wireframes or working examples for all main technical interfaces,
including but not limited to searches, results, publications management,
etc.
o Wireframes for any page requested by OIST
• Hardware Requirements and Network Configuration
o At the beginning of the development phase, the vendor will produce a
detailed recommended hardware document on which OIST can base
purchasing decisions to establish the hardware infrastructure necessary
to support the system being proposed.
Hardware requirements/ recommendations should be as detailed
as possible, addressing issues such as virtual machines versus
dedicated servers, number of cores, disk cache, offline storage
architecture, etc.
The proposal should should include at least one concrete example
of a comparable system that the firm has implemented at an
institution similar in purpose and scale to OIST.
o At the beginning of the development phase, the vendor will produce a
detailed network configuration recommendation that will ensure that the
new web system satisfies industry standards for security and
maintainability
Document should follow security best practices and address such
issues as how web and database servers are separated from other
DMZ servers, network segmentation and isolation, redundancy,
implementation of offsite backups and mirror sites, integration of
a hardware load balancer, and other topics as dictated by the OIST
IT section staff with the goal of maximizing the efficiency and
functionality of the new web system.
The initial bid proposal should include at least one concrete
example of a comparable system that the firm has implemented at
an institution similar in purpose and scale to OIST.
• Implementing a CMS using the latest version of Drupal
• Migrating or preparing for migration the following existing websites and content
to the new system:
o Main public website (Joomla)
o News website (various)
o Research unit and section sites (static HTML, DocuWiki, custom)
17
o Workshop and course sites (static HTML, DocuWiki, custom)
o Internal Intranet site (DotNetNuke)
o OIST community site (Google sites)
• Training OIST staff on use of the Drupal‐based CMS
• Supporting the Drupal‐based CMS
• Implementing hosting environment in coordination with OIST IT department
5.1.1.1 Implementation OIST expects the rights for both Drupal and the CMS to be free and clear for OIST’s use.
The selected Vendor will obtain the latest version of Drupal appropriate for meeting
the requirements and any related modules at no cost to OIST.
OIST expects that the selected Vendor will provide a Drupal‐based CMS with all
components to complete a comprehensive CMS transformation.
OIST expects the selected Vendor to install Drupal and all required CMS components
for a multi‐site, enterprise level CMS for OIST. The implementation of the CMS will
occur at the data center(s) designated by OIST IT department.
5.1.1.2 Migration OIST expects the selected Vendor to fully manage and be responsible for preparing the
migration procedures of the existing websites to the new Drupal‐based CMS. It is
expected that the selected Vendor’s migrating efforts be supported by both their
internal resources and designated OIST resources. It is anticipated that the migration
would begin with the main public site, the news site, the internal Intranet site, and the
OIST community site followed by the various research unit, section, workshop, course,
and personal websites. OIST expects the Vendor to be sensitive to the scheduling issues
of the organization.
It is important that the selected Vendor be able to provide enhancements to each
website during migration. However, it will be also important to keep a consistent “look
and feel” of the sites according to the officially sanctioned OIST style guide. Continuity
of all the sites is also an important factor during the migration phase.
5.1.1.3 Training OIST requires the Vendor to provide training to the OIST Web team, including but not
limited to instructions on the finalized site architecture, how to build a new Drupal site
18
based on an existing site in the system, creating and assigning permissions to new
users, and how to best provide support to the various Content Managers throughout
the organization.
5.1.1.4 Support OIST requires that the selected Vendor support the CMS prior to the first migration and
have post‐migration support services for the CMS. Support services include but are not
limited to:
• Break/fix support • Routine maintenance and updates
• Help desk • Website security
5.1.1.5 Hosting OIST requires the selected Vendor to consult with OIST IT staff regarding the
architecture and configuration of the hosting environment for the Drupal solution in
coordination with OIST IT department. OIST expects the Vendor to determine and
provide a hosting environment necessary to support the multi‐site Drupal CMS
installation. The hosting plan should leverage all resources using current virtualization
tools to deliver a secure, high performance computing platform that can accommodate
the scope of this migration, with room to grow as OIST’s website services continue to
grow. OIST expects the dedicated hosting environment to be managed, scalable, and
redundant, with uptime standards and nightly backups in conformance with OIST IT
department.
5.2 Specifications
5.2.1 Setup and Operational Requirements
5.2.1.1 Platform The platform for development and production should be Scientific Linux 6 (highly
preferable), unless vendor has an overwhelming reason to require the use of RHEL6, in
which case server and support license costs must be included in the contract amount.
The virtual machine technology used must be KVM. No other server OS environments
will be accepted.
UTF‐8 content, with all functions, including search, compatible with both Japanese and
English is required.
19
WebAuth shall be used to integrate with OIST Active Directory for authorization and
authentication, and the vendor will be expected to cooperate with OIST IT staff in
integration and stabilization.
5.2.1.2 Support Duration and extensions to be negotiated.
5.2.1.3 Availability The Vendor must work with OIST IT department to ensure that all IT infrastructure
systems and application servers providing the Drupal CMS platform provide
redundancy with the ability to easily and quickly switch over in case of system failure.
A roll‐back system must be in place that will return a website to a previously backed‐up
state. This process must be documented, tested, and verified before delivery.
The Vendor must build into the system compatibility with offsite mirrors and backups
and provide a recommendation for how to integrate these measures into the system.
The Vendor must provide a recommendation for how a hardware load balancer would
be used with the system.
5.2.1.4 Security Security audit (vulnerability test) will be done upon delivery and then twice per year
during support duration.
State‐of‐the‐art security measures and best practices must be followed at every stage
of development to ensure that the finished product is as secure and stable as possible.
Vendor must supply best‐practices recommendations for administration and
maintenance that ensure continued security of the system.
5.2.1.5 Updates Both the CMS core and all extensions will be kept up to date with updates and minor
version releases. Major version upgrades will be done with mutual agreement between
OIST and the Vendor after the extensions being used are compatible with the new
version.
20
5.2.1.6 Test Environment The system must include the ability to easily test new extensions, additional code,
design changes, etc. without affecting the site as it is experienced by visitors.
The site must be easily cloned to create VMs for use on development and test
machines.
5.2.1.7 Development Environment The Vendor will provide a network‐accessible development and preview environment
for use during the planning and development stages of the project so that the OIST
Web and IT staff can be actively involved with the development team and the OIST
administration can provide feedback on the direction of development as early and
often as possible, when modifications can be more easily made.
5.2.1.8 Continued System Development Environment The Vendor will provide a system development environment and migration method to
allow the vendor and/or OIST staff to continue to develop new functionality for the
web system and migrate that functionality to the production environment once it has
been confirmed production‐worthy.
5.2.1.9 Content Staging and Development Functionality The system will include a method for content managers to safely develop content,
navigation, and templates without affecting the production site. Vendor will also
provide a method for efficiently migrating this new content to the production site as
needed.
5.2.2 Nonfunctional Requirements
5.2.2.1 Multibrowser compatible Firefox 3.5+, Chrome 9+, Safari 4+, Internet Explorer 7+, Opera 10+
5.2.2.2 Site search capability The system must offer comprehensive site search capabilities. OIST intends for Drupal
to be integrated with Apache Solr for scalable, high performance faceted search
capabilities. OIST will consider deployment of Solr with OIST's web application server
resources or using Acquia Search (cloud‐based search service from Acquia using Solr for
D6 or D7 sites).
21
5.2.2.3 Print page capability The system must offer page printing capabilities including PDF versions of designated
pages.
5.2.2.4 Completely bilingual The system must offer page‐to‐page language switching between Japanese and English
for all content and functionality is required.
5.2.2.5 Themes Each part of the system must be themed to conform to the new Graphics Standard
Manual, and all templates, themes, graphics, etc. will be directed by Communications
staff of OIST and implemented by the Vendor.
5.2.2.6 Core Code Modifications The CMS core must not be modified. Features not available in the core must be realized
by implementing existing extensions or developing new extensions in accordance with
Drupal community standards. Any new extensions developed must be made available
to the Drupal community as open source.
5.2.2.7 WCAG 2.0 The site must pass Level A of conformance to WCAG 2.0.
5.2.2.8 Style Guide Layout must be done with CSS, and CSS style sheets must be logically and modularly
designed for flexibility and efficiency. A complete guide to the CSS styles used must be
provided so that content added at OIST can follow consistent guidelines.
5.2.2.9 Legacy content style During content migration, legacy content must be reviewed and made to conform to
the look and style of the new site.
5.2.2.10 Analytics Google Analytics must be implemented to provide site usage statistics.
5.2.2.11 Legacy content files Resource files like images, PDFs, etc. must be re‐organized logically, and the links for
these images and PDFs must be modified in the legacy content.
5.2.2.12 Content updates It must be possible for non‐technical OIST staff to create and update content.
22
5.2.2.13 Finegrained User Access Control It must be possible for administrators to restrict editor/content manager access to
website content on a category or single article basis.
5.3 Drupal Functional Requirements
5.3.1.1 CMS The CMS will store all information made available on the web and serve as the main
tool of web development for OIST staff. In accordance with research by OIST staff and
consultants, Drupal has been selected as the best open source CMS to use for OIST’s
purposes, based on the current and growing adoption of Drupal by similar
organizations and the availability of research‐ and education‐oriented extensions.
5.3.1.2 Website and Application Roles The new Drupal‐based web system will serve the following roles:
5.3.1.2.1 Main public website • Same functionality as the existing public website (http://www.oist.jp).
5.3.1.2.2 News website • Based on same functionality as SLAC News Center, which is a Drupal‐based
flexible, extensible platform for serving and archiving content like news stories,
press releases, feature articles, etc. to both external and internal audiences
(https://news.slac.stanford.edu/home).
o External: On its home page, the site showcases SLAC's science, projects
and people with feature stories, press releases, images and video for
external readers.
o Internal: The SLAC Today page hosts the lab's daily newsletter for SLAC
staff and users (internal). Under Calendar users find SLAC science talks
and conferences, including the popular bi‐monthly SLAC Public Lecture
series.
• Includes video and photo libraries with explanations, keyword searches, easy
linking to CMS content, and export options for file format, size, etc.
• Serves video and audio podcasts.
• Offers integrated workflow system for publishing content, including defined
workflows for content such as announcements and news. Allows OIST to
define roles and semi‐automate editing and approval processes.
23
5.3.1.2.3 Websites for research units, sections, and any other collaborative group • Based on the Drupal Organic Groups project, the system will support research
units and groups easily creating and managing comprehensive sub‐sites for
purposes of information sharing and collaboration with user access
restrictions, blogs, forums, calendars, etc.
• Should include publications management features.
• The system should be configured so that a new sub‐site themed in
conformance to the OIST official Graphics Standard Manual can be set up
simply, requiring minimal administrator effort.
5.3.1.2.4 Workshop and course websites • The system will include functionality that allows for the creation of websites
for the courses and workshops sponsored by OIST and managed by research
units and the Academic Affairs and Workshop Section.
• Workshop and course websites will require online applications (integrated
referral letter upload, CV and letter of intent upload, access‐controlled data
and file storage, and CSV download of applicant data), program, schedule,
speaker profiles, participant profiles, and integrated wiki for collaborative
work.
• Participants must compete for a place in the workshop or course, so an
application workflow must be implemented in each workshop site which
allows for entry of form data, uploads of PDF files, user‐specific storage areas
for information and files, and user access controls so that only event
organizers can access applicant data. Specifics of the application management
aspect of the system will be determined during development in collaboration
with OIST representatives.
• A custom form generator configured to satisfy application and selection needs
as defined by OIST may be sufficient, depending on the functionality offered.
• Each workshop and course will also have a sub‐site based on Organic Groups,
but the configuration will be customized for workshop and course use. The
details of this configuration will be determined during the development phase.
• The system should be configured so that a new sub‐site themed in
conformance to the OIST official Graphics Standard Manual can be set up
simply, requiring minimal administrator effort.
24
5.3.1.2.5 Personal sub‐sites • All researchers and students will be able to easily create a sub‐site using the
Drupal OpenScholar project (or components of the project). The OpenScholar
project includes functions for publication management, blogs, calendar,
custom pages, news, CV, wiki, bulletin boards, and other features.
• As with unit sites, the personal sub‐sites will be configured to conform to the
Graphics Standard Manual guidelines and use the official logo.
• The system should be configured so that a new sub‐site themed in
conformance to the OIST official Graphics Standard Manual can be set up
simply, requiring minimal administrator effort.
5.3.1.2.6 Internal Intranet website • Information restricted to OIST members, such as internal calendars, restricted
documents, internal galleries, internal forums, notifications, etc.
• Active‐Directory/LDAP‐managed login authentication and authorization for
off‐campus and on‐campus access.
5.3.1.2.7 OIST Community website • Information intended for OIST members and their families, such as person‐to‐
person marketplace, information about living in Okinawa, schools, travel,
community activities, etc.
• Active‐Directory/LDAP‐managed login authentication and authorization for
off‐campus and on‐campus access.
5.3.1.3 Extensions In the realization of all functional requirements, the system must remain extensible
with standard Drupal extensions, allowing OIST IT and Communications staff to further
develop and update the system to accommodate future needs.
Drupal extensions should be implemented to realize the following:
• File sharing/download service for OIST members to share large files with
collaborators off campus.
• Flexible video and photo gallery/library to enable users to share photos within OIST and to the outside.
• Flexible, customizable form generator to allow for ad‐hoc creation of forms with
db data storage, file uploads, and event triggers for complex processes. This
functionality will be used for things like campus tour reservations, event
25
registration, and seminars.
• Glossary extension to manage term definitions and generate a glossary of terms
and their meanings.
• Calendar system that can manage separate calendars for internal and external
use, including RSS feeds, ical/vcal import/export, and compatibility with cloud
calendar sites like Google, Yahoo, Hotmail. Integration with OIST Exchange
server also desirable.
• Mailing list management.
5.3.1.4 Custom Content Drupal custom content types should be developed to accommodate specific content
needs, including but not limited to:
• Press Release content type that has a "Release Date‐Time" field for press release
embargos.
• Types for news, press releases, etc. which feature a built‐in image gallery that
keeps the photos associated with the article itself so that the editor creating the
content does not have to figure out a place to store the photos.
5.3.2 Migration Timeline Requirements The table below outlines the desired general timeline objectives that OIST has for the
various parts of the overall implementation project.
Website Role Due Date Live Status Content Migration Main public website November 2011 Production Existing, Bilingual News website November 2011 Production Existing, Bilingual Section unit sites November 2011 Development TBD by OIST Research unit sites November 2011 Development TBD by OIST Workshop sites November 2011 Development TBD by OIST Personal sites November 2011 Development TBD by OIST Intranet site November 2011 Production Existing, Bilingual Community site November 2011 Production Existing, Bilingual
Please note that only the existing content for the main public website, news website,
Intranet site, and community site is expected to be migrated to production by the
Vendor. The migration of existing content must include both Japanese and English
content so that sites are fully bilingual at delivery. OIST intends that its staff and content
managers will work with the Vendor to coordinate and assist with the migration process.
The creation of all new content for those sites will be handled by OIST.
26
Please note that all Section unit sites, Research unit sites, Workshop sites, and Personal
sites are not expected to be migrated completely and put into production by the Vendor.
The sites must include the functionality to support both Japanese and English content so
that the sites can be fully bilingual. OIST intends that its staff and content managers will
handle the migration of these various sites over time to the new Drupal CMS including
the determination of whether the content will be bilingual. OIST intends that the Vendor
will complete development for the capability for OIST to create those sites on the new
Drupal CMS and demonstrate test migrations for those sites.
Please note that while the Intranet and Community sites will be migrated to production
by the Vendor, OIST intends to use these Drupal CMS sites primarily for backend content
management and administration. Internal and external users will access content from
these sites through a new portal for staff, faculty, students, and community members
based on the joint YWC project between OIST and ITER.
5.4 Deliverables All deliverables shall be submitted in Japanese and English both uploaded online and
provided in duplicated CD‐ROMS. (Deadlines negotiable.)
• Hardware Requirements and Network Configuration Document Recommendation
for hardware and network environmentdefined under “Scope”.
• Layout Manual: A manual of examples of the CSS used which can serve as a
manual for staff creating and maintaining content.
• Roll‐back Manual: A manual for the quick roll‐back restoration procedure
(restoring a site from a backup), including a test report.
• Restore Manual: A manual for complete restore of the system (restoring the
Drupal CMS implementation from backup), including a test report.
• Base architecture design document.
• System structure diagram and document.
• Complete code base.
5.5 Additional Scope of Work
5.5.1 Development Services OIST retains the right to request new functionality support post migration, and expects
the selected Vendor to provide development capabilities either through its own offerings
27
or through a partner at an additional cost.
5.5.2 Additional New Sites During and prior to the migration, OIST may be developing additional websites to add to
their environment. It is OIST’s intent that the selected Vendor will also handle migration
of these new sites, with an understanding that a change order will be necessary to
include them within the scope of work.
5.6 Independent Verification and Validation Independent Verification and Validation is a set of activities performed by an entity not
under control of the selected Vendor. OIST reserves the right to select a separate Vendor
that is technically, managerially, and financially independent that will check that the
deliverables provided by the selected Vendor to meet the users’ needs (Validation) and
check that the deliverables are well engineered (Verification). During all phases of the
project, the Independent Verification and Validation Vendor will be acting with the full
authority of OIST in performing activities.
28
6 Appendix A: Glossary
Backup Process
Making copies of data so that these additional copies may be used to restore the original after a
data loss event. The primary purpose is to recover data as from a data loss caused by data
deletion or corrupted data.
Break/Fix Maintenance
The work involved in supporting the CMS and its technology when it fails in the normal course
of its function and needs intervention by a support organization to be restored to working order.
Bug
The common term used to describe an error, flaw, mistake, failure, or fault in a computer
program or system that produces an incorrect or unexpected result, or causes it to behave in
unintended ways.
Cloudbased Hosting Services
The practice of using a network of remote servers hosted on the Internet to store, manage, and
process data, rather than using a local server or personal computer.
CMS Metadata
Data about data; information that is attached to content that describes certain attributes of the
information.
Content Development/ Staging
The process by which content is created, reviewed, and modified in the CMS before being made
visible to external website visitors.
Content Type
A type of content. These content types define what can be stored within the CMS and what
information is stored with that content.
Deliverable
29
Quantifiable services that will be provided during the scope of the project.
Drupal 6.x (D6) and Drupal 7.x (D7)
Version 6 and version 7 of the Drupal open source software. At any given time, there are two
major release series of Drupal which are supported. Currently, these are D6 and D7. Updated
versions of each of these are issued on a regular basis (e.g. for D6 versions 6.0, 6.1, 6.2, etc.
have been and will continue to be released).
Hacking Event
Gaining access and change control to the CMS and or the live website without
permission/authorization.
Milestone
A project checkpoint used to validate how the project is progressing and revalidate the work.
Outage
Downtime or outage duration refers to a period of time that a system whether the CMS or the
live website fails to provide or perform its primary function.
Patch
A quick repair job for a piece of programming. During a software product's beta test distribution
or try‐out period and later after the product is formally released, problems (or bugs) will almost
always be found. A patch is an immediate solution that is provided to users. A patch is not
necessarily the best solution for the problem and the product developers often find a better
solution to provide when they package the product for its next release.
Security Breach
An act from outside an organization that bypasses security policies, practices, or procedures.
Service Provider
The vendor and/or supplier responding to this RFP.
Severity Levels Level Condition Description Level 1 Live websites and CMS are down and
no workaround is immediately All or a substantial portion of mission critical data is at a significant risk of loss or
30
available corruption. There is a substantial loss of service. Organization operations have been severely disrupted. Emergency response is required.
Level 2 Major functionality is severely impaired
Operations can continue in a restricted fashion, although long‐term productivity might be adversely affected. A major milestone is at risk. Ongoing and incremental installations are affected. A temporary workaround is available.
Level 3 Partial, non‐critical loss of functionality of the software
Impaired operations of some components, but the user is able to continue using the software. Initial installation milestones are at minimal risk.
Level 4 General style and usage questions Cosmetic issues, including errors in the documentation. How‐to questions.
Support Levels Level Type Description Tier 1 Initial support for user issues. Serves
as starting point for all support tickets.Tier 1 support includes: • Training content managers on how to
use the system • Triaging support requests to determine
if a Tier 1 response is appropriate, can be addressed efficiently, and can be resolved by existing staff or if the request needs to be directed to Tier 2
• Performing CSS and design updates to websites
• Creating new user accounts and assisting with login errors
• Enabling existing modules for websites • Handling minor updates to template
components where applicable Tier 2 Next level of support for user and
system issues. Serves as escalation point for support tickets.
Tier 2 support includes: • Responding to system bug, hacking
event, outage, or security breach issues• Managing Severity Level 1 and 2 tickets• Handling major update to system
User Acceptance Testing (UAT)
Testing performed using real world scenarios and perceptions relevant to the end users to
31
ensure that the end product will meet user needs and specifications.
Wireframe
A basic visual guide used to show the layout of fundamental elements of a web interface.
Works as Designed
A term used to describe that the CMS and live website are in working order as intended and
agreed upon by the Vendor and the organization.
WYSIWYG
Acronym for “what you see is what you get.” The term is used in computing to describe a system
in which content displayed during editing appears the same or very similar to the final output.
