Docstoc

Addendum C

Document Sample
Addendum C Powered By Docstoc
					 Social Security Administration (SSA)
           SSA-RFP-10-1007

Request for Proposal(RFP) to Establish a Information
   Technology Support Serivces Contract (ITSSC)




          Section B - Statement of Work

                         1
                SECTION B - DESCRIPTION OF SUPPLIES OR SERVICES




SECTION B.1 – Background/General Requirements3
SECTION B.2 – Technical Area 1: Application and Business Planning, Analysis, and Requirements13
SECTION B.3 – Technical Area 2: Application Design, Development, Testing, and Maintenance17
SECTION B.4 – Technical Area 3: Application Validation
SECTION B.5 – Technical Area 4: Database Administration (DBA) and Imaging and Document Management
SECTION B.6 – Technical Area 5: Data Administration (DA), Programmatic Repository, and Enterprise
Architecture
SECTION B.7 – Technical Area 6: Software Engineering and Technology
SECTION B.8 – Technical Area 7: Emerging Technology (ET) Applications43
SECTION B.9 – Technical Area 8: Software Engineering Management
SECTION B.10 – Technical Area 9: Systems Administration for z/OS, UNIX, Windows, and WebSphere
SECTION B.11 – Contractor Competencies/Experience Requirements
SECTION B.12 – Software Engineering Process (SEP)
SECTION B.13 – Project Performance/Compliance, Reporting Requirements and Deliverables
SECTION B.14 – Section 508 of the Rehabilitation Act
SECTION B.15 - IPV6 Requirements




                                                       2
SECTION B.1 – BACKGROUND/GENERAL REQUIREMENTS

B.1(a) – Background

B.1(a)(1) – The Social Security Administration (SSA)

SSA has a strategic plan to provide 21st century services to the American people by reshaping
policies and procedures to take maximum advantage of information technology (IT). The
Agency is adopting a new business process that is dependent on a skilled workforce, effective
use of technology, and streamlined policies and procedures. As outlined in the IT Vision, SSA
needs significant investments in IT in order to change how the Agency does business, build a
stronger IT foundation, and revamp Agency software and databases.

The Agency Strategic Plan charts the course that will enable SSA to maintain a strong level of
performance on core workloads and to work towards long-term improvement of the services the
Agency provides to the public by concentrating on four goals:

   1.   Eliminate our hearings backlog and prevent its recurrence,
   2.   Improve the speed and quality of our disability process,
   3.   Improve our retiree and other core services, and
   4.   Preserve the public’s trust in our programs.

B.1(a)(2) – The SSA Office of Systems

The Office of Systems (OS) is responsible for designing, developing, and implementing new and
efficient software to support SSA’s programmatic, administrative, management information (MI),
and office automation systems.

Additionally, SSA must continue to improve and modernize existing software for more efficient
processing and to take advantage of current and emerging technologies. These systems are
national in scope, affect all SSA components, and are critical to the successful completion of
SSA’s strategic priorities. This contract will address SSA’s integrated programmatic,
administrative, MI, and office automation IT needs.

B.1(a)(3) – SSA’s Information Resources Management (IRM) Strategic Plan

As stated in the IRM Strategic Plan, SSA’s vision of the future anticipates that technological
changes will continue to occur at a dramatic rate. The introduction of even more advanced
technology requires innovative thinking, a new way of viewing processes, and proficiency in
using new products. Predictions are that there will be too few people trained in the new
information systems to satisfy growing needs in both the public and private sectors. Furthermore,
the gap between the demand and the supply of skilled professionals is growing.

Contractor support will assist SSA in addressing Agency goals and objectives and developing the
information systems necessary to serve the Agency in the next decade. Information technology




                                                3
will continue to transform the way that SSA does business by providing efficient and responsive
systems to support administrative tasks, improve communications, and process workloads.

Technology services are required to: (1) accomplish SSA strategic initiatives, (2) provide full
software lifecycle support, (3) provide technical support for software engineering and database
activities, (4) perform analytical and research activities, (5) support software process
improvement and software engineering management activities, (6) provide highly specialized
skills related to the current and advanced technologies not yet available to SSA, and (7) transfer
private sector knowledge to SSA.

B.1(a)(4) – Software Improvement Activities

In addition to technical programmatic and administrative processes, SSA’s OS requires support
in many non-technical areas that will be crucial to meeting Agency goals. Business modeling
and systems architecture expertise, as well as thorough knowledge of Health Information
Technology (HIT) and medical records/standards are just a few examples of the advanced skill
sets that will be necessary to change the way SSA does business presently and in the future. The
most far-reaching include, but are not limited to:

Continuous Availability (CA)

The CA project will deliver high quality, citizen-centered service by ensuring availability of core
business functions via enhanced critical systems infrastructure, systems software, new and/or
redesigned programmatic-application software, use of more modern database technologies, and
additional functionality at the Durham Support Center (DSC) and the National Computer Center
(NCC). The project objectives include providing a citizen-focused, technology-enabled
eServices suite that is available, stable, changeable, and secure.

Providing a CA infrastructure with early enterprise-wide capability will provide SSA with the
infrastructure needed to accommodate key Agency initiatives requiring CA/Remote Disaster
Recovery services while providing a safer migration path for legacy applications as they
transition to the modernized database infrastructure.

Although patch and software distribution management may not be considered directly related to
CA, those functions have an impact as it relates to server/workstation availability and potential
downtime. Machines that are not patched to approved levels may be taken off-line, resulting in
lost productivity. Although there is no planned large expansion of the existing facilities, the OS
projects normal replacement cycles for the current infrastructure. Newer versions of the
Microsoft software used for these functions may also dictate upgrading existing hardware.

Health Information Technology (HIT)

HIT will standardize the storage and transmission of medical records in a uniform electronic
format. SSA manages the largest repository of imaged medical information in the world. The
Agency collects and currently stores more than 250 million medical documents and adds 2
million more weekly. In order to effectively manage the largest social insurance system in the



                                                 4
world, the Agency must be at the forefront of the health care industry’s transition to electronic
record keeping and data sharing.

The contractor will support the following HIT activities, including, but not limited to:

      Use Business Process Modeling to document current business processes and to create and
       test new business models;
      Expand Internet offerings for Medicare, Survivors, and Supplemental Security Income
       applications similar to iClaim for retirement;
      Develop and implement a common Disability Common Processing System (DCPS) for
       the Disability Determination Services (DDSs); and
      Enable an automated process for requesting and receiving medical data through HIT.

As part of on-going efforts to support HIT strategic initiatives, SSA seeks expertise with
demonstrated knowledge in the following areas:

      Experience validating or adhering to Health Information Technology Standards Panel
       (HITSP) Standards;
      Demonstrated knowledge of Clinical Terminology, Vocabulary, and Standards;
      Experience with Integrating the Healthcare Enterprise (IHE) Standards (PIX, PDQ,
       XDS.b, XDR);
      Demonstrated knowledge of/experience with Web Service Security (WS-Security, WS-
       Addressing, SAML, XACML);
      Demonstrated knowledge of/experience with Health Informatics;
      Demonstrated knowledge of/experience with Health IT Standards (HL7 v2.x, HL7 v3,
       ASTM, X12N);
      Experience with NHIN-Connect and/or NHIN-Cooperative Implementations;
      Experience with American Health Information Community (AHIC/NeHC) use cases
       relating to Electronic Health Records;
      Demonstrated knowledge of/experience with Continuity of Care Document (CCD)
       standards and constructs;
      Experience with Patient Confidentiality and Privacy Standards – Health Insurance
       Portability and Accountability Act (HIPAA);
      Experience with the management of the entire project lifecycle for software development
       of a Health IT/Electronic Health Records (EHR) solution deployment;
      Experience with Health IT efforts for government agencies and/or specifically for SSA;
      Involvement with common Health IT industry organizations (CHIME, HIMSS, HL7,
       IHE);
      Demonstrated knowledge of/experience with Personal Health Records (PHR) solution
       deployment;
      Experience with financial transactions/fiscal standards that are currently in use in the
       medical community;
      Demonstrated knowledge of/experience with HIPAA administrative transactions that
       insurance companies and medical providers use for payments;
      Experience in Technical rollouts to healthcare facilities; and


                                                 5
      Experience in Health IT related legislation analysis and research.

Service Oriented Architecture (SOA)

SSA currently is moving towards a Service Oriented Architecture to realize the Agency’s new
initiative for seamless processing. This approach will provide a single view of SSA clients and
streamlined processing for external and internal-facing applications.

The OS has established the Center for Services Integration (CSI) to work with business
components and Systems to define and refine SSA business processes, enabling the
implementation of a SOA that will address Agency’s growing needs in an effective and efficient
manner. These efforts will integrate with SSA’s emerging Application Portfolio Management
(APM) and Project Portfolio Management (PPM) capabilities.

The Contractor will provide support to assist in organizing, planning, quickly integrating, and
delivering business-focused automation solutions. This effort will require demonstrated
expertise in current analysis, development, and project management techniques of these new-
generation software projects across all phases of the Software Development Lifecycle (SDLC).
In addition, while many new customer-facing systems will be developed, many existing back-
office systems will remain or be integrated with the new systems. The Contractor will provide
support on legacy systems to assist in integrating these systems with modern new systems, or
migrating legacy systems through re-purposing, redesign, or replacement.
The following lists the areas where support is needed aligned with tooling that implements new
methodologies that produce this new generation software by SDLC phase.

Component Business Model (CBM)

Assist in defining and developing the insight, architecture, and investment phases tailored to
SSA’s lines of business, and the policy, strategic planning, oversight, and accountability, and
service delivery that are the core accountability levels of an effective CBM.

Business Process Management (BPM)

Assist in SSA Business Process Management projects and initiatives.

Business Process Management at the Agency is the full round-trip cycle of identifying business
processes and requirements, including Key Performance Indicators (KPIs), and then
instrumenting the business automation solution to monitor the business activities measured by
these KPIs and display the real-time results to the business during production use of the
application. KPIs can be based on business rules, which can be abstracted from the application’s
business logic and stored distinctly in a business rules repository to be called at execution time
for running in a Business Rules Engine.

Project Management




                                                 6
Support activities across all phases of the SDLC that affect the ability to deliver the project on
time and within budget.

      Following an effective SDLC using a software development process tailored and based
       on Rational Method Composer;
      Utilizing Rational RequisitePro as the key tool to measure project progress against
       business-focused requirements;
      Using Rational ProjectConsole to collect standard and custom project metrics and display
       them in a Web-based dashboard to monitor project progress. ProjectConsole is used to
       identify trends and problem areas using quantitative measures and analysis to keep
       projects on track and schedule;
      Integrating software development tooling that enables project team members to work
       collaboratively regardless of geographic location; and
      Establishing an auditable and accountable Earned Value Management System (EVMS).

Business Process/Requirements Analysis

Assist in SSA’s business process analysis/modeling and requirements projects and initiatives.
SSA performs Business Process Modeling using modeling tools, such as WebSphere Business
Modeler (WBM), to document “As-Is” business processes and develop “To-Be” business
processes. All process modeling phases begin by incorporating the appropriate (As-Is or To-Be)
narrative into WBM and reviewing the resulting model(s) with appropriate stakeholders. The
Business Process Modeling efforts conclude with a comparison of the differences between the
As-Is and the To-Be business processes in order to highlight major changes and the potential
constraints, decisions, or action items that will be necessary in order to realize or enable the To-
Be process as identified in the model. Obtaining this information is a key part of the planning
and analysis phase of application development projects and helps to ensure the best quality of
project requirements in terms of accuracy and reusability of design. Perform activities including,
but not limited to:

      Assist in process design to identify and analyze existing business-focused processes (the
       work being done “As-Is,” not how or where), and design “To-Be” processes that improve
       service and responsiveness to the customer, increase SSA productivity, and reduce
       processing times and costs;
      Use professional, high-productivity requirements elicitation to develop and lead
       interviews with project sponsors and stakeholders to produce high-quality and thorough
       business-focused requirements. Use SSA’s available tooling to capture, analyze, and
       record business-focused requirements;
      Produce effective Business Process Descriptions that describe the “As-Is” business
       process, the “To-Be” business process, and perform the initial break down of the overall
       business process into high-level Business Use Cases, as the basis for traceability of all
       project activities back to the original requirement of the business;
      Use experience and ongoing analyses of industry experience, lessons learned, and best
       practices to assist in optimizing process performance using an integral program for
       continual improvement;



                                                  7
      Assist in developing staff skills for effective modeling of software and information
       structures that contribute to high-productivity new-generation business focused
       automation solutions;
      Assist in implementing effective team-enabling capabilities to make these new skills a
       significant force multiplier over today’s single person capabilities; and
      Produce automated reports on requirements using Rational SoDA.

Design, Architecture, and Development

      Support the development and maintenance of an effective SOA for SSA’s various lines of
       business;
      Assist in development and execution of effective governance for the SOA that maximizes
       effective contributions of SSA’s development community;
      Effective use of:
       o Rational Software Architect (RSA) – to develop and update effective software design
           and architecture using effective governance. Produce software architecture model
           artifacts that should be versioned and kept in a repository.
       o Rational Data Architect (RDA) – to develop and update effective information
           structure design and architecture that delivers high-productivity data services to
           existing and new-generation software. Produce information architecture model
           artifacts that should be versioned and kept in a repository.
       o Rational Application Developer (RAD) – for Java, Web-services, and SOA services
           software development. Produce Java and “services” source code that must be
           versioned and kept in a repository.
       o Rational Developer for zSeries (RDz) and Interactive System Productivity Facility
           (ISPF) – to develop new and update existing COBOL software for maintenance,
           reducing program maintenance costs, transformation, and re-purposing to participate
           in SSA’s new software environment. Produce COBOL source code that must be
           versioned and kept in a repository.
       o Additional tooling – to take stock of SSA’s existing software assets, including
           COBOL; evaluate them for change to reduce maintenance costs; and re-purpose and
           redesign for participating more directly in customer-centered SOA systems.
       o Tooling to Instrument Applications to Monitor KPIs in Production – WebSphere
           Integration Developer (WID) in development; WebSphere Process Server (WPS), or
           other Business Rules Engines (BREs) or Management Systems (BRMSs); and
           WebSphere Business Monitor (WSBM) for business activity monitoring (BAM).
      Develop, implement, and provide sustained support for development-time repositories
       (Rational Asset Manager) of:
       o Re-usable software components,
       o Re-usable business components, and
       o Re-usable business services produced from assembling re-usable software and
           business components into re-usable business services.

Support for Section 508




                                               8
SSA needs highly specialized Section 508 testing and evaluation services to fill critical needs in
mainframe, electronic documentation, and an electronic folder Section 508 support needs. In
addition, there is a need for critical consulting and training functions that impact developers
throughout the entire organization.

      As SSA move towards SOA, advanced Section 508 support to design and implement the
       View Layer strategy will be required.
      At the same time, upcoming major revisions to the Section 508 standards (expected to be
       implemented starting in 2010) will place significant demands on SSA as it transitions to
       handling potentially extensive new requirements. Highly specialized contracting support
       will be needed to assist SSA with this transition and to provide ongoing support to
       Agency employees charged with implementing the standards.

Software Build Management

Software Build Management is used to automate, schedule, and execute multi-step, multi-
platform software builds recording detailed results to logs and provides automation that includes
automated notifications, checkpoints, and restarts.

Testing

SSA has requirements-based testing, which is when validation testing is traced back through the
detailed requirements to the business requirements in the tool RequisitePro (ReqPro).

Validation testing is mostly manual now, but SSA is moving quickly to implement more
automated script-based testing and increasing its automated regression testing capabilities to
speed accurate deployment of new software releases.

The use of current testing tools is limited by SSA’s legacy environment, and their future use is
being supplanted by tooling that integrates activities in a single SDLC phase across numerous or
all phases of the SDLC. QualityCenter is a test plan development, manual execution, and defect
management tool. Requirements can be shared from SSA’s ReqPro requirements repository as
basis for “requirements-driven testing” providing traceability back to business requirements, but
software design features and functions cannot be shared. QuickTest Pro is a scripted testing tool
for automated validation and regression testing but does not support traceability back to original
business requirements.

Rational ClearQuest (CQ) is an SDLC-wide repository of detailed project information that
supports integration (not just sharing) of requirements with development and testing. These
requirements can be used as the basis for the validation test plan and produce test scripts for
automated validation and regression testing. Because CQ is SDLC-wide it is used to identify
defects in any phase of the SDLC phase, to identify and track future enhancements for inclusion
in a future version, and to support a higher level of requirements traceability throughout the
SDLC.




                                                 9
The Rational testing tools (Rational Functional Tester, Rational Performance Tester, Rational
Robot, and Rational SOA Tester) all integrate with Rational CQ to do integrated defect
management across the full breadth of software testing, not just for validation.

      Validation
           o Manual
           o Automated – Validation and Regression testing
      Performance Testing – high-performance to support high-productivity use
           o Performance testing
                   Load – roll-out
                   Stress – ramp-up
           o Code Efficiency
      Tooling – current and future direction
           o Workstation
                   QuickTest Pro
                   Quality Center
                   Rational ClearQuest
                   Rational Manual Tester
                   Rational Performance Tester
                   Rational Quality Manager
                   Rational Robot
                   Rational Tester for SOA

   SSA has made significant investments in having the same software monitoring tools used in
   the Production environments available in every Pre-Production environment (DEV, VAL,
   and INT).

      Run-time Platform (z/OS)
          o CA Wily Introscope
          o ITCAM SOA
          o ITCAM WAS

Production Execution Capabilities and Monitoring

Production execution capabilities and monitoring provides SSA’s lines of business with better
flexibility and improved responsiveness in delivering citizen-centered service oriented business
automation solutions.

      Run-time repository of re-usable software components, services, and business services –
       WebSphere Service Registry and Repository;
      Production monitoring frequency and depth with results stored in a high-performance
       repository – IBM Tivoli Component Application Manager System for WebSphere
       Application Server (ITCAM WAS);
      Run-time execution profiling – CA Wily Introscope and ITCAM WAS;
      Ability to re-play failing scenario; and



                                               10
       Direct tie to Development staff – Rational Performance Tester
           o Identification of offending code – both in execution and in the source repository
           o Integral defect tracking to resolution.

Common technologies used to connect components are:

       SOAP (Simple Object Access Protocol);
       WSDL (Web Services Description Language); and
       XML (eXtensible Markup Language).

Four IBM methodologies exist for implementing SOA:

   1.   Component Business Modeling (CBM);
   2.   Service Integration Maturity Model (SIMM);
   3.   SOA Entry Points; and
   4.   Service Oriented Modeling Architecture (SOMA).

The Contractor shall provide support in areas including, but not limited to:

       Defining and developing all three phases of CBM (insight, architecture, and investment);
       Defining and developing a CBM framework that would include Accountability level,
        Business Competencies, and Business components;
       Assisting in process design which would encompass both the identification of existing
        processes and designing the “to-be” process;
       Business process modeling using the WebSphere Business Modeler software;
       Process executing, optimizing, and monitoring;
       Supporting the development and maintenance of the SOA architecture;
       Supporting the governance for the SOA model;
       Developing and implementing support for a repository of enterprise-level services
        developed in-house;
       Identifying common business services; and
       Standardizing tools and processes used in building SSA’s infrastructure for electronic
        services.


B.1(b) – General Requirements

B.1(b)(1) – Technical Areas

The Contractor shall provide information technology support services in nine technical areas:

   1.   Application and Business Planning, Analysis, and Requirements;
   2.   Application Design, Development, Testing, and Maintenance;
   3.   Application Validation;
   4.   Database Administration (DBA) and Imaging and Document Management;
   5.   Data Administration (DA), Programmatic Repository, and Enterprise Architecture;


                                                11
   6.   Software Engineering and Technology;
   7.   Emerging Technology (ET) Applications;
   8.   Software Engineering Management; and
   9.   Systems Administration for z/OS, UNIX, Windows, and WebSphere.

There will be a fair opportunity award for each Technical Area, with specific work requests
resulting in Task Orders and Work Orders that precisely define the scope, deliverables, and
schedule of the work to be performed. Each Task Order will be awarded as a logical follow-on
to the appropriate Technical Area award.

A description of the nine technical area requirements follows. The descriptions and examples of
activities are representative of the currently-required support and are not to be considered all-
inclusive. Other systems, projects, and activities will be undertaken, and new technologies will
be studied and implemented.

Technical Areas 1, 2, and 3 represent a large portion of the work and are considered critical
requirements by the Agency.

B.1(b)(2) – Methodology, Standards, and Guidelines

In early 2005, SSA’s OS achieved Level 3 Software Capability Maturity Model (SW-CMM)
rating. SSA has matured in its software engineering discipline and is evaluating the Capability
Maturity Model Integration (CMMI) to selectively adopt those practices which will add value at
SSA, in order to create its own organizational profile or model to provide an objective evaluation
of process strengths and weaknesses and identify processes for potential OS-wide adoption. In
2008, the OS began to conduct periodic evaluations of organizational processes against the
Systems' Organizational Profile.

The Contractor shall perform all work in accordance with SSA’s Project Resource Guide
(PRIDE); Information Resources Management (IRM) Strategic Plan; and all of SSA’s other
pertinent methodologies, standards, and guidelines. Copies of these and other technical
documents will be provided upon contract award. Task Orders will be issued, processed, and
managed in accordance with Section E.3 - Task Order Ordering Procedures.

SSA seeks to continually improve Agency methodologies, standards, and guidelines; and they
are considered, by nature, to be dynamic. The methodologies, standards, and/or guidelines to be
used for a given Task Order are those that are in effect at the time the request for Task Order is
issued.

B.1(b)(3) – Software Tools

The Contractor shall be required to use SSA’s automated software tools for mainframes and
workstations to support all phases of the systems lifecycle and the nine technical areas. A tool is
defined as a product, utility, Control List (CLIST), physical environment, catalogued procedure,
or command. The use of software development tools helps to ensure standardization of software




                                                12
code. A list of SSA’s mainframe and distributed tools is included in Section E.4 -Tools List.
This list is not all-inclusive. The future marketplace will dictate additional tools SSA may use.

B.1(b)(4) – Contractor Experience and Skills

The Contractor shall provide personnel with the skills and experience necessary to support the
technical requirements of each activity. Refer to Section B.8 - Contractor
Skills/Knowledge/Experience Requirements, and Section E.1 - Personnel Qualifications.

B.1(b)(5) – Application Software

The Contractor shall perform activities related to Agency programmatic and
administrative/management information systems. SSA will furnish the software system
information necessary for work performance.

B.1(b)(6) – Computing Environment

The Contractor shall perform activities in a multiple-platform, cooperative processing computing
environment as described in SSA’s IRM Strategic Plan.

B.1(b)(7) – Architectures

The Contractor shall perform activities in accordance with SSA’s current and target software and
infrastructure architectures, and SSA’s current and target data administration and database
management sub-architectures as described in the IRM Strategic Plan. SSA will furnish
additional information on the architectures as necessary for work performance.

SECTION B.2 – TECHNICAL AREA 1: APPLICATION AND BUSINESS PLANNING,
ANALYSIS, AND REQUIREMENTS

The Contractor shall provide application and business planning, analysis, and requirements
support, including business process modeling, for the Agency’s programmatic, administrative,
business intelligence, and strategic analysis software applications.

These applications will run in SSA’s multi-platform, cooperative processing computing
environment consisting of large-scale IBM-compatible mainframes, an IBM-compatible
Intelligent Work Station/Local Area Network (IWS/LAN), SSA’s intranet, and the Internet. All
support services and contract deliverables will be in accordance with SSA’s software and data
architectures as described in the the IRM Strategic Plan.

      Current mainframe code is primarily written in Common Business-Oriented Language
       (COBOL), Assembler Language Code (ALC), FORTRAN, and uses VSAM, DB2 (via
       SQL or stored procedures), CA-IDMS/DB databases, and/or a proprietary file
       management and control system called the Master Data Access Method (MADAM).
       Mainframe systems include batch as well as online CICS applications.




                                                13
      Current front-end code is primarily written in JAVA language and uses IBM Rational
       Application Developer for WebSphere Software V7.0 as the full function Eclipse 3.2
       based development platform for developing Java 2 Platform Standard Edition (J2SE) and
       Java 2 Platform Enterprise Edition (J2EE) applications.
      Applications that run on IBM’s WebSphere Application Servers (WAS).
      IBM iSeries application development that runs in each State Disability Determination
       Service (DDS) office. These are part of the Agency’s Disability programmatic
       processing. This code is developed both in-house and by vendors.
      IBM’s WebSphere MQ is a message oriented middleware that is used for asynchronous,
       guaranteed data transfer between locations, platforms, and applications; for example,
       State DDSs and SSA’s Central Office.
      Distributed production applications run on UNIX (presently Sun Solaris) using
       WebSphere or ColdFusion with DB2 on mainframe or Oracle (presently on HP-UX
       UNIX) as the distributed relational database management system (DBMS).
      There is some use of Windows Server and Microsoft SQL Server databases for
       applications not requiring high end reliability, availability, and scalability or tight
       integration with programmatic SDLC processes.
      There is some use of Web 2.0 technologies (b10gs, Wikis, video sharing sites, etc.),
       change management tools (SourceSafe, CVS, etc.) and tools such as Macromedia Studio
       MX Suite (Dreamweaver, Flash Professional, Fireworks, FreeHand, ColdFusion), Adobe
       Creative Suite (Photoshop, ImageReady, Illustrator, InDesign, Acrobat), file transfer
       protocol (FTP), and audio editing software, understanding of Macromedia Authorware,
       Hypertext Markup Language (HTML) editors, JavaScript, JAVA, JSP, ColdFusion
       Markup Language (CFML), Extensible Markup Language (XML), and Ruby on Rails.
      There is some use of WebFocus development, WebFocus Developer Studio (Release 7
       and above), Dashboard Development, MRE Administrator, using Report Caster/Report
       Library, Focus programming (sometimes the GUI tool requires 'tailoring' for complex
       reports/queries), SQL, DB2, VSAM, and Hyperion.

Implementation of the requirements will drive the need for software engineering support for the
development, optimization, and upgrade of SSA’s programmatic, administrative, and
management information software applications. All modifications shall be compliant with SSA
policies. Throughout the development, the contractor will define and identify standards and best
practices. Records will be created and maintained to support the key processes and configuration
management. The Contractor support shall also include application and business planning,
analysis, and requirements activities, including business process modeling activities, supporting,
but not limited to, the following areas:

      Software design, development, testing, integration, and deployment;
      Web design, development, testing, integration, and deployment;
      Interface design, development, testing, integration, and deployment; and
      System security design, development, testing, integration, and deployment.

The Contractor shall support any acquisition and implementation of Commercial off-the-shelf
(COTS), Government off-the-shelf (GOTS), and Application Service Provider (ASP) solutions
identified for the purpose of reduced costs and minimized customization.


                                                14
All deliverables shall be prepared in accordance with SSA Software Process Improvement
Guidelines, the Project Resource Guide (PRIDE), Task Order Ordering Procedures, and all of
SSA’s other standards, guidelines, procedures, and architectures for mainframe, local, and
distributed applications, as well as IEEE standards. The Contractor shall adhere to SSA data
naming and definition conventions, screen formats, source code language, and automatic source
code generators.

Lifecycle activities include, but are not limited to: planning, business process analysis,
requirements definition, design alternatives, training, user-centered design, and user-centered
testing.

Maintenance activities include, but are not limited to, documentation.

B.2(a) – Programmatic Systems

The Contractor shall provide application and business planning, analysis, and requirements
support services, including business process modeling services, for SSA’s programmatic
applications software. SSA will determine which platform best meets the needs of each
workload. Refer to the IRM Strategic Plan for more detailed descriptions of major systems.

The five primary systems are: Enumeration; Earnings; Retirement, Survivor’s and Disability
Systems (Title II); Supplemental Security Income Systems (Title XVI); and Medicare.

Other important programmatic support systems include, but are not limited to: Business
Information, Comprehensive Integrity Review (CIRP), Continuing Disability Review (CDR),
Customer Help Information Program (CHIP), Debt Management, Disability Quality Review
(DQR), Earnings Modernization, Electronic Quality Assurance (eQA), Electronic Service
Delivery (Internet, intranet, Electronic Data Interchange (EDI), etc.), iClaims, Intelligent
Disability (iDib), Medicare, Paperless Processing, Ready Retirement, and Representative Payee.
Some of these systems run on distributed (non-mainframe) platforms. SSA intends to integrate
existing programmatic support systems with the CSI to convert many of SSA’s applications to
SOA design standards and principles.

B.2(b) – Administrative/Business Intelligence (Admin/BI)

The Contractor shall provide application and business planning, analysis, and requirements
support, including business process modeling, for SSA’s varied set of Admin/BI applications
through the development of functional requirements by performing business process analysis and
business process reengineering. These range from highly localized software running on
microcomputers to widely used mainframe-based applications or Sun Solaris/UNIX platforms to
software running in a multiple-platform, cooperative processing environment.

Specific functional areas include SSA’s program and administrative accounting, cost accounting,
reporting, budgeting, time and attendance, payroll, personnel, purchase and travel cards,
electronic service delivery (Internet, intranet, Electronic Data Interchange (EDI), etc.), payroll



                                                15
accounting, finance modernization, travel, and BI Architecture, as well as routine business
processes that are candidates for automation through use of office tools, and technology, such as:
word processing, statistical analysis, management tracking and control, electronic mail, and
document storage and retrieval.

B.2(c) – Application and Business Planning, Analysis, and Requirements Support for
Design and Development Activities

The Contractor shall provide application and business planning, analysis, and requirements
support services, including business process modeling, including producing the planning,
analysis, and requirements major products described in the PRIDE.

In addition, the Contractor shall provide application and business planning, analysis, and
requirements support, including business process modeling, for the following activities:
establishing and supporting development environments, which includes, but is not limited to:
server installation, configuration, maintenance, and troubleshooting; providing technical
briefings and reports; participating in meetings and walkthroughs; analyzing problems and
providing solutions; providing user support; and conducting research.

The Contractor shall provide application and business planning, analysis, and requirements
support, including business process modeling, related to the application of prototyping
technologies, Object-Oriented design and development, and RAD/Joint Application
Development (JAD) techniques and methods to support application design and development
activities as described.

The Contractor shall provide application and business planning, analysis, and requirements
support, including business process modeling, related to usability and accessibility to assist
SSA’s developers and project teams. These services are essential to the Agency’s successful use
of IT to handle the upcoming wave of new benefit claims coming from the retiring baby boomers.
The OS is making plans to migrate to a seamless SOA in order to streamline development time
and modernize SSA’s aging application architecture.

To support this effort, usability specialists are needed to perform business process analysis, user
requirements elicitation, requirements documentation through visual design and prototyping, and
usability testing, usability standards development, and training. Accessibility specialists are
needed to assist SSA developers with planning, designing, developing and testing for
accessibility and Section 508 compliance. Accessibility specialists are also needed to assist with
the development of accessibility best practices, accessibility policies and procedures,
procurement, training, and automated tools to assist with administering SSA’s Section 508
program.

B.2(d) – Application and Business Planning, Analysis, and Requirements Support for
Software Maintenance and Improvement Activities

The Contractor shall support SSA’s major software systems on multiple computing platforms.
Maintenance and improvement activities shall be performed in accordance with the PRIDE, the



                                                16
IRM Strategic Plan, and all of SSA’s other policies, guidelines, lifecycle standards, Section 508
standards, accessibility standards, usability standards, and procedures.

The Contractor shall perform application and business planning, analysis, and requirements
support, including business process modeling, related to the following areas (as defined further
in Sections B.3 and B.4):

      Software Maintenance
      Maintenance Activities
      Input Documents
      Standardized Software Testing and Validation
      Software Conversion and System Documentation
      Software Measurement Program

SECTION B.3 – TECHNICAL AREA 2: APPLICATION DESIGN, DEVELOPMENT,
TESTING, AND MAINTENANCE

The Contractor shall provide application design, development, testing, and maintenance support
for SSA’s programmatic, administrative, business intelligence, and strategic analysis software
applications. “Testing” as used to describe the functions of Technical Area 2 refers to unit
testing at the code level.

These applications will run in SSA’s multi-platform, cooperative processing computing
environment consisting of large-scale IBM-compatible mainframes, an IBM-compatible
IWS/LAN, SSA’s intranet, and the Internet. All support services and contract deliverables will
be in accordance with SSA’s software and data architectures as described in the IRM Strategic
Plan.

      Current mainframe code is primarily written in COBOL, ALC, FORTRAN, and uses
       VSAM, DB2 (via SQL or stored procedures), CA-IDMS/DB databases, and/or a
       proprietary file management and control system called the MADAM. Mainframe
       systems include batch as well as online CICS applications.
      Current front-end code is primarily written in JAVA language and uses IBM Rational
       Application Developer for WebSphere Software V7.0 as the full function Eclipse 3.2
       based development platform for developing J2SE and J2EE applications.
      Applications that run on IBM’s WAS.
      IBM iSeries application development that runs in each State DDS office. These are part
       of the Agency’s Disability programmatic processing. This code is developed both in-
       house and by vendors.
      IBM’s WebSphere MQ is a message oriented middleware that is used for asynchronous,
       guaranteed data transfer between locations, platforms, and applications; for example,
       State DDSs and SSA’s Central Office.
      Distributed production applications run on UNIX (presently Sun Solaris) using
       WebSphere or ColdFusion with DB2 on mainframe or Oracle (presently on HP-UX
       UNIX) as the distributed relational database management system.



                                                17
      There is some use of Windows server and Microsoft SQL Server databases for
       applications not requiring high end reliability, availability, and scalability or tight
       integration with programmatic SDLC processes.
      Knowledge of and skills in: Web 2.0 technologies (b10gs, Wikis, video sharing sites,
       etc.), change management tools (SourceSafe, CVS, etc.) and tools such as Macromedia
       Studio MX Suite (Dreamweaver, Flash Professional, Fireworks, FreeHand, ColdFusion),
       Adobe Creative Suite (Photoshop, ImageReady, Illustrator, InDesign, Acrobat), FTP, and
       audio editing software, understanding of Macromedia Authorware, HTML editors,
       JavaScript, JAVA, JSP, CFML, XML, and Ruby on Rails.
      Knowledge, skill, and experience in: Web Focus development, WebFocus Developer
       Studio (release 7 and above), Dashboard Development, MRE Administrator, using
       Report Caster/Report Library, Focus programming (sometimes the GUI tool requires
       'tailoring' for complex reports/queries), SQL, DB2, VSAM, and Hyperion.

Implementation of the requirements will drive the need for information technology support for
the development, optimization, and upgrade of SSA’s programmatic, administrative, and
management information software applications. All modifications shall be compliant with
SSA’s policies. Throughout the development, the Contractor will define and identify standards
and best practices. Records will be created and maintained to support the key processes and
configuration management. The contractor support shall also include application design,
development, testing, and maintenance activities supporting, but not be limited to, the following
areas:

      Software design, development, testing, integration, and deployment;
      Web design, development, testing, integration, and deployment;
      Interface design, development, testing, integration, and deployment; and
      System security design, development, testing, integration, and deployment.

The Contractor must be able to support the design and development of JAVA pages, JSP pages,
and properties files. The contractor shall adhere to SSA’s Web applications standards and
provide support of the framework (consists of Java components) that provide a foundation for
building Agency Web (Internet and intranet), as well as voice, applications. These components
are pre-built functionality for common services required by these applications such as session
management, navigation, application session restart, back-end Customer Information Control
System (CICS) invocation, security authorization, and data validation.

The Contractor shall provide support to audit, design, and architect SSA enterprise applications
to eliminate single points of failure and mitigate communication weaknesses.

The Contractor shall support any acquisition and implementation of COTS, GOTS, and ASP
solutions identified for the purpose of reduced costs and minimized customization.

All deliverables shall be prepared in accordance with SSA’s Software Process Improvement
Guidelines, the PRIDE, Task Order Ordering Procedures, and all of the other Agency standards,
guidelines, procedures, and architectures for mainframe, local, and distributed applications, as



                                                18
well as IEEE standards. The Contractor shall adhere to SSA’s data naming and definition
conventions, screen formats, source code language, and automatic source code generators.

Lifecycle activities include, but are not limited to: architecture analysis, design alternatives,
software design and development, testing, training, and implementation.

Maintenance activities include, but are not limited to: support to improve production code using
reverse engineering, re-engineering, restructuring and conversions, and documentation.

B.3(a) – Programmatic Systems

The Contractor shall provide application design, development, testing, and maintenance support
services for SSA’s programmatic applications software. SSA will determine which platform best
meets the needs of each workload. Refer to the IRM Strategic Plan for more detailed
descriptions of major systems.

The five primary systems are: Enumeration; Earnings; Retirement, Survivor’s and Disability
Systems (Title II); Supplemental Security Income Systems (Title XVI); and Medicare.

Other important programmatic support systems include, but are not limited to: Business
Information, Comprehensive Integrity Review (CIRP), Continuing Disability Review (CDR),
Customer Help Information Program (CHIP), Debt Management, Disability Quality Review
(DQR), Earnings Modernization, Electronic Quality Assurance (eQA), Electronic Service
Delivery (Internet, intranet, Electronic Data Interchange (EDI), etc.), iClaims, Intelligent
Disability (iDib), Medicare, Paperless Processing, Ready Retirement, and Representative Payee.
Some of these systems run on distributed (non-mainframe) platforms. SSA intends to integrate
existing programmatic support systems with the CSI to convert many of SSA’s applications to
SOA design standards and principles.

B.3(b) – Administrative/Business Intelligence Systems (Admin/BI)

The Contractor shall provide application design, development, testing, and maintenance support
for SSA’s varied set of Admin/BI applications through the development of functional
requirements by performing business process analysis and business process reengineering.
These range from highly localized software running on microcomputers to widely used
mainframe-based applications or Sun Solaris/UNIX platforms to software running in a multiple-
platform, cooperative processing environment.

Specific functional areas include SSA’s program and administrative accounting, cost accounting,
reporting, budgeting, time and attendance, payroll, personnel, purchase and travel cards,
electronic service delivery (Internet, intranet, Electronic Data Interchange (EDI), etc.), payroll
accounting, finance modernization, travel, and BI Architecture, as well as routine business
processes that are candidates for automation through use of office tools, and technology, such as:
word processing, statistical analysis, management tracking and control, electronic mail, and
document storage and retrieval.




                                                  19
B.3(c) – Application Design and Development Support

The Contractor shall provide application design, development, testing, and maintenance support
services, including producing the design, development, testing, and maintenance major products
described in the PRIDE.

In addition, the Contractor shall provide application design, development, testing, and
maintenance technical support for the following activities: establishing and supporting
development environments, which includes, but is not limited to: server installation,
configuration, maintenance, and troubleshooting; providing technical briefings and reports;
participating in meetings and walkthroughs; analyzing problems and providing solutions;
providing user support; and conducting research.

The Contractor shall provide application design, development, testing, and maintenance support
related to the application of prototyping technologies, Object-Oriented design and development,
and RAD/Joint Application Development (JAD) techniques and methods to support application
design and development activities as described.

The Contractor shall provide application design, development, testing, and maintenance support
services related to usability and accessibility to assist SSA developers and project teams. These
services have recently become essential to the Agency’s successful use of IT to handle the
upcoming wave of new benefit claims coming from the retiring baby boomers. The Office of
Systems is making plans to migrate to a seamless SOA in order to streamline development time
and modernize SSA’s aging application architecture.


B.3(d) – Application Design, Development, Testing, and Maintenance Support for Software
Maintenance and Improvement Activities

The Contractor shall support SSA major software systems on multiple computing platforms.
Maintenance and improvement activities shall be performed in accordance with the PRIDE, the
IRM Strategic Plan, and of SSA’s other policies, guidelines, lifecycle standards, Section 508
standards, accessibility standards, usability standards, and procedures.

The Contractor shall perform application design, development, testing, and maintenance support
services related to the following areas:

B.3(d)(1) – Software Maintenance

Contractor shall provide application design, development, testing, and maintenance support to
ensure that SSA software is reliable, efficient, accurate, and maintainable. These activities may
include, but are not limited to, any or all of the activities in the five stages of the PRIDE, and fall
into four basic categories: Corrective Maintenance; Adaptive Maintenance; Perfective
Maintenance; and Preventive Maintenance.




                                                  20
      Corrective Maintenance is performed to identify and correct software failures,
       performance failures, and implementation failures and includes:
           o Emergency repairs performed when immediate repair is necessary to continue
               user service.
           o Corrective coding performed to correctly reflect the specifications or to correctly
               utilize system resources.
      Adaptive Maintenance is performed to adapt software to changes in the requirements or
       the processing environment, and includes:
           o Upgrades/conversions performed to adapt to changes in the hardware/software
               environment, i.e., z/OS operating system, from COBOL II to IBM Enterprise
               COBOL for z/OS compilers and CICS Transaction Server, DB2 conversions,
               REXX conversions, programming language conversions, etc. Upgrades, patches,
               and conversions in the hardware and software for the UNIX and Windows server
               environments.
           o Enhancements made on the software to provide additional or changed
               functionality, or to adapt to changes in the business processes, or to extend the
               software to new users.
      Perfective Maintenance is performed to enhance performance, improve cost-effectiveness,
       improve processing efficiency, or improve maintainability.
           o The Contractor shall analyze the system/program to be maintained and its
               environment to acquire the knowledge and understanding needed to perform a
               maintenance activity.
           o The Contractor shall provide support for COTS tools used as part of perfective
               maintenance including, but not limited to:
                     TestBase
                     Expediter/CodeCoverage
                     MetaData Analyzer
      Preventive Maintenance is performed to identify and correct software failures before they
       happen.

B.3(d)(2) – Maintenance Activities

The Contractor shall be responsible for performing typical application design, development,
testing, and maintenance assistance necessary for the following maintenance activities, including,
but not limited to:

      Redesign activities which modify functionality and/or technical improvements to enhance
       the software;
      Revise existing software to respond to legislative changes;
      Support cyclical changes to operational workloads;
      Develop ad hoc software that may only be used once or for a limited time, such as stand-
       alone programs, modules (common, shared or other) and/or utility software;
      Modify software support documentation when software maintenance changes take place;
      Investigate reported problems and, as directed, implement recommended changes;




                                               21
      Translate a specification and/or a request for operational support into executable
       computer programs in a file format and programming language appropriate to the
       platform and Office of Systems specified;
      Support development/maintenance activity (i.e., provide general technical support,
       develop test data files); and
      Debug and resolve Abnormal Ends (ABENDS) timely and return programs to production
       status.

B.3(d)(3) – Input Documents

SSA may furnish the following types of documents to the Contractor for maintenance activities:

      A Request for Operational Support document providing background, functional changes,
       testing criteria, etc., needed to perform a maintenance activity;
      A problem report document identifying possible production program problems for
       analysis and corrections; and
      Various PRIDE stage documents for background and maintenance changes.

B.3(d)(4) – Standardized Software Testing and Validation Processes

SSA continually improves the quality of SSA’s test and validation environments. This activity
involves the analysis of the existing test environments and institutionalizing a disciplined
validation environment to assure that software performs its specified functions both in an
independent and in an integrated environment. The software must meet a measurable degree of
performance in both reliability and accuracy prior to implementation.

The Contractor shall use SSA software tools. Some activities may require analysis and/or
development of tools and methodologies other than those that SSA currently has in use. SSA
may provide these tools, or the Contractor may be required to acquire the tool to be analyzed,
which will be reimbursed as Other Direct Costs (ODCs).

Contractor application design, development, testing and maintenance support may include, but
not be limited to, the following types of activities to improve SSA’s test environment:

      Provide analyses of current testing and validation environments and tools with
       recommendations for improvements to existing processes;
      Provide an automated methodology to test software to assure its accuracy and reliability
       at the unit, validation, program integration, and system levels. Regression testing may be
       included in the methodology adopted;
      Provide an automated system to generate and/or select a proper set of records to
       thoroughly test and validate all programs, subsystems and systems, thus providing a level
       of confidence that all functions were exercised;
      Perform market research and evaluation/impact analysis of automated tools (Government
       or Contractor furnished) and techniques for the automatic generation of test databases;
      Provide on-going support for SSA’s standard testing tools, both COTS and in-house
       developed;


                                               22
      Provide customization of testing tools to meet functional area requirements;
      Provide the methodology to collect, house, and manipulate all data generated to enable
       decision support at all levels of management. Provide support for requirements-based
       testing and automate test tools such as WINRUNNER, TSL scripting language, Quality
       Center, Test Director, QTP with SPUFI, QMF, Fileaid for DB2 and other DB2 query
       tools;
      Provide support for designing systems and test architecture (e.g., driver scripts, data
       stores, etc.); and
      Support CA and HIT by providing the expertise necessary for the expansion of SSA’s
       existing standard software tools including but not limited to:
           o Quick Test Pro
           o Quality Center

B.3(d)(5) – Software Conversion and System Documentation

The Contractor shall support the application design, development, testing, and maintenance
activities necessary for conversion of software from current language to new languages or
language versions if needed.

Systems which were developed years ago and have evolved are now undocumented. While still
effective, they are difficult to maintain. As these systems are being updated, they must be
thoroughly and completely documented in accordance all of SSA’s standards and guidelines.

B.3(d)(6) – Software Measurement Program

The Contractor shall support SSA in its software measurement program efforts within the OS.
Contractor support services for application design, development, testing, and maintenance may
include, but are not limited to:

      Establishing baselines for project size, effort, cost, schedule, and defects;
      Tracking project size, effort, cost, schedule, and defects throughout the life of a software
       development project;
      Advising on metrics issues relating to SSA’s CMM/CMMI process improvement efforts;
      Assisting software measurement analysts as they count the function points for completed
       projects and as they estimate the function points for new projects; and
      Counting the function points in a workshop environment for a number of SSA systems.

SECTION B.4 – TECHNICAL AREA 3: APPLICATION VALIDATION

The Contractor shall provide application validation support for SSA’s programmatic,
administrative, business intelligence, and strategic analysis software applications.

These applications will run in SSA’s multi-platform, cooperative processing computing
environment consisting of large-scale IBM-compatible mainframes, an IBM-compatible
IWS/LAN, SSA’s intranet, and the Internet. All support services and contract deliverables will



                                                23
be in accordance with SSA’s software and data architectures as described in the IRM Strategic
Plan.

      Current mainframe code is primarily written in COBOL, ALC, FORTRAN, and uses
       VSAM, DB2 (via SQL or stored procedures), CA-IDMS/DB databases, and/or a
       proprietary file management and control system called the MADAM. Mainframe
       systems include batch as well as online CICS applications.
      Current front-end code is primarily written in JAVA language and uses IBM Rational
       Application Developer for WebSphere Software V7.0 as the full function Eclipse 3.2
       based development platform for developing J2SE and J2EE applications.
      Applications that run on IBM’s WAS.
      IBM iSeries application development that runs in each State DDS office. These are part
       of the Agency’s Disability programmatic processing. This code is developed both in-
       house and by vendors.
      IBM’s WebSphere MQ is a message oriented middleware that is used for asynchronous,
       guaranteed data transfer between locations, platforms, and applications; for example,
       State DDSs and SSA sites.
      Distributed production applications run on UNIX (presently Sun Solaris) using
       WebSphere or ColdFusion with DB2 on mainframe or Oracle (presently on HP-UX
       UNIX) as the distributed relational database management system.
      There is some use of Windows server and Microsoft SQL Server databases for
       applications not requiring high end reliability, availability, and scalability or tight
       integration with programmatic SDLC processes.
      There is some use of Web 2.0 technologies (b10gs, Wikis, video sharing sites, etc.),
       change management tools (SourceSafe, CVS, etc.) and tools such as Macromedia Studio
       MX Suite (Dreamweaver, Flash Professional, Fireworks, FreeHand, ColdFusion), Adobe
       Creative Suite (Photoshop, ImageReady, Illustrator, InDesign, Acrobat), FTP, and audio
       editing software, understanding of Macromedia Authorware, HTML editors, JavaScript,
       JAVA, JSP, CFML, XML, and Ruby on Rails.
      There is some use of Web Focus development, WebFocus Developer Studio (release 7
       and above), Dashboard Development, MRE Administrator, using Report Caster/Report
       Library, Focus programming (sometimes the GUI tool requires 'tailoring' for complex
       reports/queries), SQL, DB2, VSAM, and Hyperion.

Implementation of the requirements will drive the need for software engineering support for the
development, optimization, and upgrade of SSA’s programmatic, administrative, and
management information software applications. All modifications shall be compliant with
Agency policies. Throughout the development, the contractor will define and identify standards
and best practices. Records will be created and maintained to support the key processes and
configuration management. The contractor support shall also include application validation
activities supporting, but not be limited to, the following areas:

      Software design, development, testing, integration, and deployment;
      Web design, development, testing, integration, and deployment;
      Interface design, development, testing, integration, and deployment; and
      System security design, development, testing, integration, and deployment.


                                               24
The Contractor shall support any acquisition and implementation of COTS, GOTS, and ASP
solutions identified for the purpose of reduced costs and minimized customization.

All deliverables shall be prepared in accordance with the SSA’s Software Process Improvement
Guidelines, the PRIDE, Task Order Ordering Procedures, and all other Agency standards,
guidelines, procedures, and architectures for mainframe, local and distributed applications, as
well as IEEE standards. The Contractor shall adhere to SSA’s data naming and definition
conventions, screen formats, source code language and automatic source code generators.

Lifecycle activities include, but are not limited to: software validation, testing, training, and
implementation.

Maintenance activities include, but are not limited to: documentation.

B.4(a) – Programmatic Systems

The Contractor shall provide application validation support services for SSA’s programmatic
applications software. SSA will determine which platform best meets the needs of each
workload. Refer to the IRM Strategic Plan for more detailed descriptions of major systems.

The five primary systems are: Enumeration; Earnings; Retirement, Survivor’s and Disability
Systems (Title II); Supplemental Security Income Systems (Title XVI); and Medicare.

Other important programmatic support systems include, but are not limited to: Business
Information, Comprehensive Integrity Review (CIRP), Continuing Disability Review (CDR),
Customer Help Information Program (CHIP), Debt Management, Disability Quality Review
(DQR), Earnings Modernization, Electronic Quality Assurance (eQA), Electronic Service
Delivery (Internet, intranet, Electronic Data Interchange (EDI), etc.), iClaims, Intelligent
Disability (iDib), Medicare, Paperless Processing, Ready Retirement, and Representative Payee.
Some of these systems run on distributed (non-mainframe) platforms. The OS intends to
integrate existing programmatic support systems with the CSI to convert many Agency
applications to SOA design standards and principles.

B.4(b) – Administrative/Business Intelligence Systems (Admin/BI)

The Contractor shall provide application validation support for SSA’s varied set of Admin/BI
applications through the development of functional requirements by performing business process
analysis and business process reengineering. These range from highly localized software
running on microcomputers to widely used mainframe-based applications or Sun Solaris/UNIX
platforms to software running in a multiple-platform, cooperative processing environment.

Specific functional areas include SSA’s program and administrative accounting, cost accounting,
reporting, budgeting, time and attendance, payroll, personnel, purchase and travel cards,
electronic service delivery (Internet, intranet, Electronic Data Interchange (EDI), etc.), payroll
accounting, finance modernization, travel, and BI Architecture, as well as routine business



                                                  25
processes that are candidates for automation through use of office tools, and technology, such as:
word processing, statistical analysis, management tracking and control, electronic mail, and
document storage and retrieval.

B.4(c) – Application Validation Support for Application Design and Development Activities

The Contractor shall provide application validation support services, including producing the
application validation major products described in the PRIDE.

In addition, the Contractor shall provide application validation support for the following
activities: establishing and supporting development environments, which includes, but is not
limited to: configuration, maintenance, and troubleshooting; providing technical briefings and
reports; participating in meetings and walkthroughs; analyzing problems and providing solutions;
providing user support; and conducting research.

The Contractor shall provide application validation support related to the application of
prototyping technologies, Object-Oriented design and development, and RAD/Joint Application
Development (JAD) techniques and methods to support application design and development
activities as described.

The Contractor shall provide application validation support services related to usability and
accessibility to assist SSA developers and project teams.

B.4(d) – Application Validation Support for Software Maintenance and Improvement
Activities

The Contractor shall support SSA’s major software systems on multiple computing platforms.
Maintenance and improvement activities shall be performed in accordance with the PRIDE, the
IRM Strategic Plan, and all other Agency policies, guidelines, lifecycle standards, Section 508
standards, accessibility standards, usability standards, and procedures.

The Contractor shall perform application validation support services related to the following
areas:

      Software Maintenance
      Maintenance Activities
      Input Documents
      Standardized Software Testing and Validation
      Software Conversion and System Documentation
      Software Measurement Program

B.4(d)(1) – Standardized Software Testing and Validation Processes

SSA continually improves the quality of SSA’s test and validation environments. This activity
involves the analysis of the existing test environments and institutionalizing a disciplined
validation environment to assure that software performs its specified functions both in an


                                                26
independent and in an integrated environment. The software must meet a measurable degree of
performance in both reliability and accuracy prior to implementation.

SSA require Contract support for testing and validation activities, such as using automated test
tools for validation; developing, documenting, and executing manual tests; and providing
research and designing, developing, and deploying processes that enable effective validation and
testing of applications, including Web (Internet and/or intranet) and voice applications.

The Contractor shall use SSA’s software tools. Some activities may require analysis and/or
development of tools and methodologies other than those that SSA currently has in use. SSA
may provide these tools, or the Contractor may be required to acquire the tool to be analyzed,
which will be reimbursed as Other Direct Costs (ODCs).

Contractor application validation support may include, but not be limited to, the following types
of activities to improve SSA’s test environment:

      Provide analyses of current testing and validation environments and tools with
       recommendations for improvements to existing processes;
      Provide an automated methodology to test software to assure its accuracy and reliability
       at the unit, validation, program integration, and system levels. Regression testing may be
       included in the methodology adopted;
      Provide an automated system to generate and/or select a proper set of records to
       thoroughly test and validate all programs, subsystems and systems, thus providing a level
       of confidence that all functions were exercised;
      Perform market research and evaluation/impact analysis of automated tools (Government
       or Contractor furnished) and techniques for the automatic generation of test databases;
      Provide on-going support for SSA’s standard testing tools, both COTS and developed in-
       house, including, but not limited to:
            o TestBase for DB2,
            o Expediter/Code Coverage, and
            o MetaData Analyzer;
      Provide customization of testing tools to meet requirements;
      Provide the methodology to collect, house, and manipulate all data generated to enable
       decision support at all levels of management.
      Provide support for requirements-based testing and automated test tools such as
       WINRUNNER, TSL scripting language, Quality Center, Test Director, QTP with SPUFI,
       QMF, Fileaid for DB2 and other DB2 query tools;
      Provide support for designing systems and test architecture (e.g., driver scripts, data
       stores, etc.); and
      Support CA and HIT by providing the expertise necessary for the expansion of SSA’s
       existing standard software tools including but not limited to:
            o Quick Test Pro
            o Quality Center

B.4(e) – Other Specific Validation Activities



                                                27
The Contractor shall provide application validation support to SSA’s independent validation
environment, which currently provides validation services to the majority of SSA’s
programmatic processes and are cross-platform and multi-disciplinary. The areas to be
supported include the following general requirements:

B.4(e)(1) – Testware Development, Execution, and Maintenance

The Contractor shall develop, execute, and maintain test automation software, tester productivity
tools, and test data tools for SSA initiatives. The validations will be system-level, functional
testing of SSA’s programmatic, administrative, MI, and office automation systems. Validation
will be performed cross-platform including, but not limited to, batch mainframe and CICS, Web
(Internet and intranet), and voice. The general work anticipated in this area includes, but is not
limited to:

      Design, develop, maintain, and execute automated test processes that run system-wide
       validations in a test environment using such languages and tools as: Job Control
       Language (JCL), CLISTs, REXX, ISPF/Dialog Manager, DB2, IDMS, TESTBASE,
       Control-M, IBM utilities, and other SSA-developed testing tools.
      Maintain policies, standards, procedures, and guidelines for systems validation tests,
       including designing and developing test plans, test procedure specifications, test run logs,
       CICS test region setup, and system documentation.
      Evaluate current validation methodologies and make recommendations to improve
       efficiency.
      Independently resolve ABENDS and/or execution errors and take corrective actions.
      Participate in meetings to assist, coordinate, plan review, and resolve issues as well as
       regularly scheduled status meetings as requested.

B.4(e)(2) – Risk Analysis

The Contractor shall provide expert support for tools that are used to analyze or otherwise
improve the code used for SSA’s major programmatic and business process, including upcoming
initiatives such as SOA, Ready Retirement, and HIT. The Contractor’s responsibilities shall
include, but are not limited to:

      Executing a code coverage tool (such as Expediter/Code Coverage) for selected systems
       and sub-systems during system-wide validations;
      Evaluating the results produced by the tool and preparing the reports to be distributed to
       analysts, developers, and managers;
      Maintaining reports, counts, and other assessments; and
      Supporting the maintenance of the tool and troubleshooting any technical problems that
       arise during the execution of the code coverage process.

B.4(e)(3) – Tool Support

The Contractor shall provide expert support for a variety of mainframe- and PC-based tools and
processes, both COTS and in-house-developed. Representative COTS tools include, but are not


                                                28
limited to: QuickTest Professional, HP Quality Center, Mortice Kern Systems (MKS) Source
Integrity, devEnterprise, MetaDataAnalyzer, TestBase, and File-Aid for DB2. In-house-
developed tools that will require Contractor support include, but are not limited to, JAWS Using
a Data Generated Environment (JUDGE), which supports the interaction between all of SSA’s
CICS screens and JAWS; the Validation Transaction Tracking System (VTTS); System’s
problem reporting system (WINPAIRS); the Validation Plan (VP) system; and the Mainframe
Validation Automated Scenario System (MVASS), which supports disaster recovery and the
Continuous Availability initiatives.

The Contractor shall provide tool support in areas including, but not limited to:

      Designing, maintaining, and trouble-shooting in-house-developed tools and support
       processes.
      Providing technical support for COTS products including, but not limited to, problem
       resolution, upgrading, configuration management, supporting user requirements analysis,
       planning and coordinating server consolidation, and installing upgrades and patches.
      Provide technical support for Web services.
      Attending meetings that may include, but are not limited to, planning meetings, user-
       centered meetings, project reviews, and problem resolution sessions.
      Provide support for Video on Demand services including script development and
       alternative analysis.
      Developing and maintaining documentation as required, including, but not limited, to
       user manuals and operational guides.

B.4(e)(4) – Validation Database (VDB) Support and Redesign

The VDB currently houses over 4 million records that are used for the validation of SSA’s
programmatic, administrative, and MI. The records produce test cases, which may be comprised
of as many as 45 different master files, and are used for functional analysis. The VDB supports
VSAM, IDMS/R, MADAM, and DB2 file structures. A variety of in-house-developed tools are
used to manage the test cases and include such processes as data sanitization, production
selections, indexing, cloning, editing, searching, linking, and report generation. There are
several significant efforts underway directly impacting VDB, including the need for a VDB
redesign to improve processing efficiency and usability for end-users, the establishment of an
External Testing Environment (ETE) to provide VDB accesses to non-SSA developers, and the
probable need for increased data sanitization. The use of DB2 has impacted the VDB and other
areas of validation necessitating the introduction of new tools, which require maintenance and
on-going support.

The Contractor shall provide VDB support including, but not limited to:

      Design, develop, maintain, and execute data selection routines, data cloning routines, and
       data sanitization routines for new files and databases as they are added to the VDB;
      Design, develop, maintain, and execute test data management utilities, test data alteration
       utilities, and test transaction generators;



                                                29
         Provide planning, coordination, monitoring, and reporting on the configuration and
          maintenance of the ETE;
         Provide requirements, alternative analysis, design features, recommendations, and expert
          technical support, including development, for the redesign of the VDB;
         Develop and maintain documentation, including system documentation, operating
          procedures, and user manuals for the VDB and its various functions;
         Provide problem analysis and resolution for ABENDS, slow processing, and inaccurate
          data results;
         Provide technical support for various tools including, but not limited to, TestBase and
          File-Aid RDX;
         Attend meetings including, but not limited to, planning meetings, problem resolution
          sessions, project reviews, status meetings, and regularly-held staff meetings; and
         Provide VDB user support including problem resolution, problem tracking, report
          generation, and recommendations for process improvements.

SECTION B.5 – TECHNICAL AREA 4: DATABASE ADMINISTRATION (DBA) AND
IMAGING AND DOCUMENT MANAGEMENT

The Contractor shall provide technical database administration support across multiple platforms.

All work shall be accomplished in compliance with the PRIDE and all of SSA’s database
architectures, standards and guidelines; and must be consistent with the IRM Strategic Plan.
These architectures, standards/guidelines may include, but are not limited to: the use of CICS,
COBOL, ALC, Java, SAS, Structured Query Language (SQL), Oracle PL/SQL, CA-IDMS, DB2,
DB2 UDB for Multi-platforms (UNIX hosted DB2), Microsoft SQL Server, Microsoft
SharePoint Server, Oracle, SSA data naming and definition conventions, the use of ERWIN 1 or
Bachman Diagrams, Data Resource Management Systems (DRMS), the Application Interface
Facility (AIF), the MADAM file management and control system, and Computer Associates
Integrated Database Management System (CA-IDMS/DB). The Contractor shall also be
required to understand the infrastructure architecture and its components as described in the IRM
Strategic Plan, which make full use of the SSA’s Communications Network (SSANet), wide area
networks, dial-up gateways and local area networks. Contractor shall have demonstrated
expertise in the conversion of flat file structures to mainframe-based DB2.

More specific data and database activities that shall be accomplished during all PRIDE stages
include, but are not limited to:

B.5(a) – Relational Database Technology

The Contractor will provide support to transition SSA from a proprietary, primarily in-house
developed, database architecture to a modern, open architecture based upon relational database
management systems.



1
    CA AllFusion ERWIN Data Modeler


                                                 30
All new development projects will be built using relational database technology. Support in
converting existing data stores to this new architecture will be required. This effort creates the
need for experienced Oracle, DB2 for z/OS, DB2 UDB for Multi-platforms, and Microsoft SQL
Server database administrators to complement SSA’s staff. In addition to database
administration expertise, the Contractor will provide expertise in the areas of data warehousing,
content management, stored-procedure programming, SQL programming, database migration
and Web-based database access. As SSA progresses with this transition, legacy data stores must
continue to be maintained. The Contractor will provide support for CA-IDMS/DB databases and
its proprietary in-house developed database architecture.

The Contractor shall support and perform activities including, but not limited to:

      Develop procedures and processes to monitor database conditions, performance,
       availability, and usage;
      Establish standards for relational database administration;
      Identify procedures for database development and maintenance;
      Develop procedures to enforce SSA’s standards;
      Evaluate and test database administration support tools;
      Assist SSA with relational database design;
      Evaluate DBMS characteristics and provide recommendations as to appropriateness for
       SSA’s architectures;
      Evaluate and implement new DBMS-related technologies such as Web-enabled data
       access, XML data types, parallel processing, etc. This infrastructure must provide the
       functionality to handle both the SSA’s “programmatic” mission critical data as well as
       data used for management information systems;
      Provide support for data warehousing design, development and implementation;
      Make recommendations on most efficient data warehouse architecture;
      Evaluate and test database related products, for example, tools that are designed to
       efficiently implement, maintain, and monitor a data warehouse, imaging, or document
       management architecture;
      Perform capacity planning;
      Provide database problem evaluation and resolution as well as related concerns or issues;
      Design/develop backup/recovery procedures;
      Determine Direct Access Storage Device (DASD) requirements;
      Develop data storage strategies;
      Develop physical database model;
      Develop and support TestBase databases;
      Develop schema/subschema;
      Develop database access routines;
      Provide support and tool evaluation in major testing and validation areas; and
      Provide support for DB2 initiatives.

B.5(b) – Imaging and Document Management Systems

B.5(b)(1) – Paperless Processing


                                                31
This project includes the integration of electronic records with images of paper documents,
workflow reengineering and the development of system interfaces. The software is presently
implemented using the eiStream WMS Document Management System software on a Windows
server platform and is one of eiStream’s largest implementations of that software.

The Contractor shall provide support that would cover the scope of an imaging/document
management application, including, but not limited to:

      Support significant refinements and enhancements to the application to address
       scalability;
      Address performance challenges and provide production support as problems arise;
      Support redesign efforts which will require the investigation and evaluation of the full
       range of options available for each of the components of the document imaging/paperless
       system;
      Maintain client-server application programs to support the paperless processing
       application;
      Provide analytical support for indexing of documents (text and images) to facilitate
       retrieval;
      Provide support for converting from Visual Basic 6 to Visual Basic.NET;
      Support storage and retrieval strategies to most efficiently address the user needs to
       access structured and unstructured data; and
      Support an archive strategy that maximizes the use of storage of structured and
       unstructured data and procedures to recall/retrieve structured and unstructured (i.e.,
       imaging, text) data as required.

B.5(b)(2) – Document Management Architecture

The OS currently is supporting a major initiative to provide enterprise document management
architecture for unstructured data. The goal of this project is to develop and implement an
architecture and infrastructure to address the known and future document capture, indexing,
storage, retrieval, and SSA’s management needs.

The Contractor shall support and perform activities including, but not limited to:

      Provide support on the installation and configuration of supporting software;
      Provide the infrastructure support for data storage and retrieval;
      Identify and recommend solutions to overcome COTS software shortcomings and
       limitations;
      Provide development support for the pilot and productions efforts;
      Develop Web-based application programs to support the infrastructure;
      Support the electronic capture of digitized images of text or figure documents;
      Provide analytical support for indexing of documents (text and images) to facilitate
       retrieval;




                                                32
      Develop storage and retrieval strategies to most efficiently address the user needs to
       access structured and unstructured data;
      Analyze storage technology, including conventional magnetic DASD, and other mass
       storage technologies that are, or which may become, commercially available;
      Develop and implement a records management strategy including relevant software,
       hardware, processes and procedures;
      Develop an archive strategy to maximize use of storage of structured and unstructured
       data and procedures to recall/retrieve structured and unstructured (i.e., imaging, text) data
       as required;
      Provide support for capacity planning initiatives;
      Participate in planning initiatives in conjunction with other system components; and
      Provide off-hours production support to include weekends, holidays, and both night shifts.

SECTION B.6 – TECHNICAL AREA 5: DATA ADMINISTRATION (DA),
PROGRAMMATIC REPOSITORY, AND ENTERPRISE ARCHITECTURE

B.6(a) – Data Administration, Programmatic Repository

The Contractor shall provide analytical and technical data administration and repository support.

The Data Administration/Programmatic Repository technical area consists of an integrated set of
information technologies and lifecycle procedures that support SSA’s Data Administrator in
achieving the strategic objectives outlined in the Agency Strategic Plan.

An ability to function in the environment in which repository generated components run is
required in order to develop, test, debug, and migrate through the Systems Development
Lifecycle (SDLC), repository generated, or developed application components.

      Examples of those environments include:
           o CICS and batch COBOL, JAVA, and IBM Assembler Language Code (ALC)
              applications;
           o In order to access programmatic data in a controlled manner, distributed
              applications will invoke repository generated Java code which will run in an IBM
              or SUN Solaris/UNIX WebSphere Application Server; and
           o Potentially Microsoft.Net server based applications.
      Examples of repository generated components include:
           o Java source components and whole modules;
           o Whole, compilable programs (ALC, COBOL, etc.) for record support functions;
           o Executable COBOL source code copybooks;
           o COBOL data area copybooks; and
           o Record specifications (e.g., elements with metadata).
      Examples of repository group developed components include:
           o Common code routines for date validation/transformation.
      Expertise in IBM ISPF Dialogue Manager Language is needed to support that mechanism
       for mainframe access to the portion of the programmatic repository known as the Data



                                                33
        Resource Management System (DRMS), for example for Data Element Cluster (DEC2)
        definition.
       Knowledge of XML is required since repository XML plans include storage of data
        element XML metadata into the repository and generation of XML structures from the
        repository. Supported application programs may access CA-IDMS/DB or DB2 databases.
       The DRMS portion of the programmatic repository is constructed around the Allen
        Systems Group (ASG) ASG-Manager Products™ for Enterprise Metadata Management3
        and the Computer Associates (CA) Advantage Repository for z/OS so knowledge of
        those products is necessary. Both programmatic repository and data administration
        require a knowledge of SSA’s data element and definition conventions (e.g. naming), and
        the use of Bachman Diagrams, the ERWIN4 and ModelMart5 modeling toolsets, and the
        Troux8 product.

Support services include, but are not limited to, one or more of the following:

B.6(b) – Data Administration

       Develop and update SSA’s Enterprise Model using the ERWIN tool;
       Perform (two way) data element gap analysis between new or changing project needs and
        enterprise model;
       Develop user views of the data models;
       Develop a gateway to the repository for all of SSA’s official data models using the
        Troux8 tool; and
       Avoid the creation of redundantly stored data (except in cases where the physical
        database design process indicates that planned redundancy is necessary for performance
        reasons).

B.6(c) – Programmatic Repository

       Provide support to enhance and maintain existing DRMS Programmatic Repository;
       Implement and maintain the CA Advantage Repository for z/OS;
       Provide installation and upgrade support for the ModelMart software used by Database
        Administration and Data Administration personnel throughout SSA’s Office of Systems;
       Design and develop backup/recovery procedures for the Data Resource Management
        System (DRMS) repository;
       Provide repository support (to include both the DRMS and CA Advantage Repository for
        z/OS) for data content requirements, access control mechanism, specialized reports and
        integrity requirements;




2
  A customized data view of MADAM or CA-IDMS/DB programmatic data.
3
  A consolidation of formerly ASG ControlManager; ASG DataManager; and ASG MethodManager
products.
4
  CA AllFusion ERWIN Data Modeler
5
  CA AllFusion Model Manager


                                                34
       Provide generation of AIF and CICS executable and copybook source code, generation of
        “Master File6” record specifications, generation of DEC copy areas;
       Support for IBM ALC common code modules used for standard CICS and batch data
        element validation functions;
       Support for all of SSA’s date conversion common code modules, primarily written in
        IBM ALC;
       Depending on Enterprise Architecture progress in the area of XML, explore and
        implement repository support for XML metadata storage and XML “copy area” and
        source code (COBOL, Java, etc) to facilitate use of XML for data exchange (e.g. Extranet)
        and application integration (between SSA’s in-house applications, COTS etc);
       Provide services to access ASG repository information via a Web front end (e.g. HTML,
        etc); and
       Provide support for repository use of the Troux8 enterprise architecture product.

B.6(d) – Enterprise Architecture

The OS currently is engaged in a major ongoing initiative to provide Enterprise Architecture
implementation support for the Chief Information Officer (CIO) in accordance with the Clinger-
Cohen Act and the Office of Management and Budget (OMB) guidelines. The focus of this
effort is to identify and implement industry best practices and supporting technology to improve
SSA’s Enterprise Architecture while maintaining compliance with Federal Enterprise
Architecture (FEA) guidelines and standards. The contractor shall support the SSA in its efforts
to enhance and maintain its enterprise architecture programs.

Services required of the Contractor may include, but are not limited to: planning, research,
analysis, design, report generation, project management, and technical support in the following
areas:

       Enterprise Architecture Tool Integration – SSA has procured an enterprise architecture
        tool (Troux8) and will create and populate an Enterprise Architecture Repository to
        provide:
            o Users with access to Enterprise Architecture components and models;
            o Configuration management; and
            o Audit capabilities.
       Application Portfolio Management Tool Integration – SSA has procured a Project
        Portfolio Management (PPM)/Application Portfolio Management (APM) tool (Clarity)
        and will create and populate an Application Portfolio Repository to provide:
            o The identification and implementation of APM best practices;
            o User access to the APM Repository data; and
            o An overall health indicator of the Application Inventory.
       Extensible Markup Language (XML) Strategy Development – The Contractor will
        provide support to the Enterprise Architecture staff in developing a strategy for defining
        and implementing processes, standards, and guidelines for incorporating XML-related
6
 “Master File” refers to one of SSA’s major programmatic files. These Master Files are stored using SSA
proprietary software known as MADAM which uses via IBM’s VSAM/BDAM/BSAM access methods
depending on the function performed.


                                                   35
       technologies into future systems development. While creating this Enterprise
       Architecture strategy, the primary focus will be on using existing metadata within SSA’s
       data architecture to efficiently and effectively provide controlled access to enterprise
       information. Additional activities may involve how SSA can best participate in the
       creation of a federal XML registry for use in facilitating Data Exchanges with business
       and Government agencies.
      Enterprise Architecture Implementation – Contractor support will be required to assist
       SSA in its effort to enhance and maintain its Enterprise Architecture in accordance with
       OMB requirements, guidelines, and data formats (OMB 300B), identifying and
       implementing industry best practices, and supporting technology to improve SSA’s
       Enterprise Architecture while conforming to Federal Enterprise Architecture (FEA)
       guidelines and standards.
      Enterprise Architecture Web Site Enhancement and Maintenance – The Contractor will
       provide support to the Enterprise Architecture staff to maintain an intranet Web site for
       SSA’s Enterprise Information Technology Architecture (EITA) framework and related
       architecture models and tools.
      Periodic Analysis of Business Strategy Changes to Enterprise Architecture - The
       Contractor shall provide support to the Enterprise Architecture staff to conduct interviews
       with business, technical and strategic planning component personnel as part of Enterprise
       Architecture target/transition planning as well as interact with Technology Infusion (or
       Emerging Technology) efforts in order to track and incorporate areas identified as having
       potential to impact target architectures.

SECTION B.7 – TECHNICAL AREA 6: SOFTWARE ENGINEERING AND
TECHNOLOGY

The Contractor shall provide support to SSA’s software engineering community, users of the
Enterprise Software Engineering Facility (ESEF) and the production infrastructures, which
include the Management Information Services Facility (MISF), Document Management
Facilities (DMF), and Programmatic Processing Facility (PPF). The ESEF is a general-purpose
multi-platform computer facility dedicated to the interactive development, testing, validation and
maintenance of SSA’s programmatic and Admin/BI software systems. Operating in a multi-
programming mode, the ESEF provides IBM TSO, online IBM CICS, database and batch IBM
mainframe processing services, SUN Solaris UNIX operating systems for WebSphere and
ColdFusion, and Windows servers to programmers, analysts and contractors throughout the Agency.
Many different types of software development and validation/testing activities are performed using
ESEF resources; TSO, ISPF, CICS, IDMS, DB2 and batch are the primary mainframe workloads,
as well as WebSphere Application Development (WSAD/WSED) on the developer’s desktop and
WebSphere Application Server (WAS) J2EE runtime for the z/OS and Sun Solaris platforms.
Distributed and multi-platform application development, primarily Internet/intranet, is a fast
evolving portion of overall ESEF activities.

Eleven general requirement areas have been targeted for support.

B.7(a) – CICS Internals and Generations




                                               36
The Contractor shall provide technical support to the ESEF user community, which may include,
but is not limited to:

      Perform CICS table and Resource Definitions Online (RDO) maintenance;
      Establish new CICS region configurations;
      Migrate CICS application systems through the CICS regions as releases of these projects
       move through the software development lifecycle;
      Provide/develop long-and-short-range planning for CICS configurations to meet user
       requirements;
      Provide technical assistance and support to designers and developers of CICS
       applications;
      Provide written analysis of design and development considerations/recommendations for
       CICS applications;
      Provide written analysis for recommended use of CICS development tools to aid in the
       design and development of CICS applications;
      Provide analysis of testing techniques and test results of newly developed CICS
       application;
      Install, validate and implement CICS software development tools, such as Intertest;
      Resolve system and user related problems; and
      Maintain CICS resources.

B.7(b) – Mainframe, UNIX, and LAN Applications Engineering and Management Support

The Contractor shall provide technical support to the software engineering community for
mainframe and LAN activities/projects related to application engineering and management
support. This support may include, but is not limited to:

      Identify and define the specifications for the development or acquisition of Common
       User Access Interfaces with the Systems Application Architecture (SAA) standards as
       defined by IBM;
      Define the requirements for the use of program development tools necessary to interface
       application systems with networks and telecommunications systems;
      Identify, troubleshoot and resolve software application and software integration problems
       on UNIX, workstations, and LANs;
      Define and develop the standards for application systems development in the three major
       computing areas (Windows, UNIX, and mainframe);
      Define and develop gateways and/or interfaces SSA needs in order to allow application
       systems to be developed that take advantage of all of its resources;
      Define and develop communications standards that allow peer to peer, Distributed Server
       to Mainframe, or other appropriate levels of communications to take place;
      Perform or recommend tuning/stressing of application/networks to ensure proper
       utilization of available equipment and software; and
      Develop the programming guides that specify how to use the network interface.




                                              37
B.7(c) – Networking on Multiple Platforms

The Contractor shall provide support including, but are not limited to:

      Support the key infrastructure used by client-server, mainframe, UNIX, Windows,
       intranet and Internet developers in the LAN environment which includes LAN, server
       and workstation management and configuration, automated and manual software
       distribution, electronic mail services and problem resolution on all platforms;
      Provide support for current z/OS, iSeries, Windows desktop operating systems (Windows
       XP and looking to move to Windows Vista) and server operating systems (Windows
       2003 and looking to possibly move to R2 and 64-bit under that operating system), and
       UNIX server operating systems and architecture issues, and coordinate those activities
       with other systems components;
      Provide support for future z/OS, iSeries, Windows, and UNIX versions;
      Support migration to 100% Transmission Control Protocol/Internet Protocol (TCP/IP)
       protocols and enhancements to IWS/LAN and UNIX (or Distributed System) to
       mainframe connectivity; and
      Conversion from IPv4 to IPv6 including development of conversion strategies, migration
       implementation, cross-node communication assessment and support, and tunneling
       mechanisms, etc.

B.7(d) – Performance Analysis/System Monitoring, Monitoring and Tuning

The Contractor may be required to perform a full range of Distributed Storage Management
(DSM) support activities, performance monitoring, tuning and reporting activities for all the
various engineering and production facilities on all platforms, including the mainframe, LANs,
UNIX, and microcomputer. These activities include, but are not limited to:

      Actively monitor the overall performance and DASD on all platforms and/or for all
       facilities using Help Desk consoles, Omegamon monitors, Landmark CICS monitors,
       NETVIEW, LAN performance monitors and any other available hardware and software
       and monitoring tools;
      Provide technical advice, guidance, problem determination and problem resolution
       support to the software engineering community on all platforms (mainframe, client-server,
       and intranet/Internet);
      Identify and document potential engineering and/or production facility performance
       problems to ensure that service degradation on any given platform does not occur.
       Provide recommendations for improvement or correction of identified problems;
      Monitor and evaluate the performance of support software products/tools (i.e., vendor
       and system software) that will be utilized on all platforms;
      Maintain performance database(s) and perform data recovery activities when appropriate;
      Produce daily, weekly, monthly and ad hoc performance reports; perform regular
       analyses of performance and trend reports; and provide tuning recommendations.
      Execute and monitor DASD maintenance jobs;
      Conduct performance evaluation studies, including but not limited to, modeling and
       impact analyses of software changes, new user workloads and new software products.


                                                38
       These evaluation studies could apply to all of the various engineering and production
       facilities/platforms; and
      Provide documentation, procedures and training for newly developed performance
       monitoring systems or methodologies.
      Develop and execute test plans and implementation plans for proposed new DASD,
       Hierarchical Storage Management (HSM), Systems Managed Storage (SMS) and/or SAN
       support for LAN and UNIX support software.

B.7(e) – Quality Control

Prior to the release of software into the production environment, it is processed through a version
and quality control enforcement mechanism to ensure that it conforms to standards established
for the production environment. This process also ensures that software released to production is
the same software that was certified through validation.

The Contractor shall provide quality control support to the software engineering community
including, but not limited to, the following types of activities:

      Provide quality control system updates;
      Participate in the validation of software changes;
      Participate in the evaluation and implementation of metrics tools to access software
       quality control adherence;
      Perform updates to quality control procedure documentation; and
      Maintain in-house written QA applications.

B.7(f) – Software Release, Evaluation and Problem Resolution

The Contractor shall be required to assist SSA in the area of software problem resolution for the
software user community. The Contractor personnel will serve as technical advisors and perform
software analysis and problem solving on a daily basis.

The Contractor may perform activities including, but not limited to:

      Provide comprehensive software consulting services for applications, tools and utilities
       that are available on various development and production facilities;
      Provide “user-friendly” and accessible documentation of software packages on the
       various development and production facilities;
      Provide seminars on software packages and tools that reside on the various development
       and production facilities;
      Provide support for problem management (problem resolution, tracking, monitoring and
       reporting); and
      Perform validation of changes to software tools on the various development and
       production facilities.

B.7(g) – Software Storage (DASD) Management, Performance and Tuning



                                                39
Assistance is required in monitoring and ensuring efficient utilization of system resources on the
various engineering and production facilities; for example, analysis of the impact of software
tools used for program development and testing, CICS regions, and Redundant Arrays of
Inexpensive Disks (RAID) DASD.

The Contractor shall perform typical support activities including, but not limited to, the
following system management activities:

      Software performance monitoring and reporting;
      Impact analysis studies of changes to existing system and vendor software, new
       programmatic workloads and new software tools;
      Performance modeling of software tools to determine system resource usage;
      Workload characterization and performance evaluation on the various software
       engineering facilities;
      DASD management to ensure efficient usage including DASD monitoring and
       performance reporting;
      Development of recommendations for software engineering facility tuning changes;
      Development of improved methods of data collection for performance monitoring;
      Evaluation and formatting of data for daily and monthly reports to reflect attainment of
       service level objectives;
      Perform impact analyses of new software tools;
      Maintenance of the SSA’s Performance and Impact Analysis Guide;
      Conduct TPNS stress tests;
      Provide consulting services on enterprise-wide storage and storage management solutions,
       and assistance in determining the best course for the various software engineering
       facilities; and
      Model software engineering facility workloads to predict future capacity requirements.

B.7(h) – Systems Security and Access

B.7(h)(1) – Development and Production Facility Security:

Security of the various engineering and production facilities requires technical support for the
security and access control software. SSA has a published set of uniform sanctions for
information systems access violations. The purpose of these sanctions is to ensure that any
violations of the confidentiality, integrity and availability of SSA’s information systems and
records are treated in a consistent manner and that all of SSA’s employees and contractors are
aware of the consequences of these violations. These sanctions apply to all of SSA’s employees
and contractors. For more details on these Sanctions and the Acknowledgment Statement, refer
to Office of Labor Management and Employee Relations Website.

The Contractor shall perform typical support activities including, but not limited to, the
following:

      Develop standards, guidelines and procedures for protection of resources;
      Provide assistance to users with TOP SECRET and resource access problems;


                                                 40
      Review and revise security and access control reports pertaining to users, their access
       privileges and the utilization of resources;
      Participate in testing of new versions of security and access control software, such as
       TOP SECRET; and
      Participate in ongoing software security projects with work assigned to:
           o Analyze security data to determine patterns of security violations;
           o Make recommendations for standardization of administrative and user profiles;
           o Prepare procedures for processing security access requests, TOP SECRET
               services, and other security-related processes; and
           o Provide technical expertise in solving user’s difficulties in interfacing with
               security and access software.

B.7(h)(2) – IWS/LAN, UNIX, and intranet/Internet Security:

Security of the IWS/LANs and the intranet/Internet requires technical support in the form of
software and hardware requirements analysis, design, development and ongoing support. SSA
has a published set of uniform sanctions for information systems access violations. The purpose
of these sanctions is to ensure that any violations of the confidentiality, integrity and availability
of SSA’s information systems and records are treated in a consistent manner and that all of
SSA’s employees and contractors are aware of the consequences of these violations. These
sanctions apply to all of SSA’s employees and contractors. For more details on these Sanctions
and the Acknowledgment Statement, refer to Office of Labor Management and Employee
Relations Website.

The Contractor shall perform typical support activities including, but not limited to, the
following:

      Provide assistance to application developers with IWS/LAN and intranet/Internet security
       procedures and resource/data access problems;
      Provide assistance to application developers with integrating security into SSA’s
       applications for the IWS/LAN and the intranet/Internet;
      Determine the requirements for IWS/LAN and intranet/Internet to mainframe security;
      Design and development of IWS/LAN and intranet/Internet to mainframe security
       systems;
      Develop standards, guidelines and procedures for:
           o The protection of IWS/LAN and intranet/Internet resources and data;
           o IWS/LAN and intranet/Internet to mainframe communications;
           o Accessing mainframe data from the IWS/LAN and intranet/Internet platforms;
               and
           o The addition/removal of IWS/LAN and intranet/Internet software and/or hardware.
      Develop, review and revise software license usage reports;
      Provide support for eTrust implementation and administration;
      Develop, review and revise security and access control reports pertaining to IWS/LAN
       and intranet/Internet users, their access privileges and the utilization of IWS/LAN and
       intranet/Internet resources; and



                                                  41
      Participate in researching, analyzing and testing IWS/LAN intranet/Internet platforms
       and IWS/LAN and intranet/Internet to mainframe security commercial products.

B.7(i) – Tool Market Research, Evaluation, Integration, and Support

As new or updated releases of automated tools become available, the OS acquires selected tools
under the PRIDE systems development lifecycle methodology.

The Contractor shall perform activities, which may include, but are not limited to:

      Perform market research and evaluation of tools and techniques for all aspects of the
       software development lifecycle;
      Develop technical standards for evaluation of commercial software products and tools;
      Prepare written evaluations of tools;
      Provide technical briefings on tools and tool evaluations;
      Provide written recommendation/justification of new/replacement tools and conduct tool
       impact analysis;
      Provide customization of tools, where appropriate;
      Create, maintain, and update technical manuals, user manuals, technical guides, and
       checklists for publication or incorporation into the online manual system;
      Install, validate, and implement vendor software productivity tools on the various
       engineering and production facilities and LAN platforms;
      Plan and manage the integration of various tools across multiple platforms (z/OS, Sun,
       Windows 2003/XP/Vista, etc.) including defining communications requirements for this
       integration;
      Develop and modify/enhance in-house software engineering tools;
      Develop user-friendly software interfaces for Software Development Lifecycle
       Methodology (SDLM) tools;
      Resolve software tool related problems; and
      Provide support for the resolution of tool related problems.

B.7(j) – User Assistance (Help Desk)

The Contractor shall perform activities, which may include, but are not limited to:

      Provide continuous and responsive Help Desk, problem resolution, and software
       consultation to the user of the various engineering and production facilities;
      Provide support for multiple distributed applications development, validation and
       usability activities such as CHIP, Payment Center Action Control System (PCACS NT),
       Integrated Human Resources System (IHRS), BI and data warehousing, as well as Java
       and non-mainframe source code management (Mortice Kearns Software Integrity
       Enterprise (MKS SIE); and
      Support integration of new electronic data processing functions such as imaging, faxing,
       electronic signature, and Internet into these and future client-server applications.




                                                42
B.7(k) – Version Management (PC, UNIX, and Mainframe)

The Contractor shall perform activities, which may include, but are not limited to:

      Provide support for application source code version management through automated tools
       such as Endevor MVS (mainframe) and MKS SIE;
      Support the development of processes to use this automated version management
       software; and
      Support the release of executables through the SDLC.

SECTION B.8 – TECHNICAL AREA 7: EMERGING TECHNOLOGY (ET)
APPLICATIONS

The Contractor will provide support in the area of emerging technology to assist SSA’s
management in the analysis and application of leading software/systems development techniques
and their applicability to SSA’s current and future system environments. The Contractor shall
provide support for SSA’s initiatives, pilots, evaluations, and studies for integration into SSA’s
software environment.

The Contractor shall maintain a knowledge base of technological advances in the marketplace
and determine the appropriateness of new technologies in SSA’s current and target environments.

The Contractor shall perform the following types of typical activities including, but not limited
to: research, testing, prototyping, evaluations, analyses, reports, cost benefit analyses, impact
analyses, demonstrations, and/or technical briefings and seminars on emerging technologies and
new software packages to support SSA’s projects and pilots. As the territory for emerging
technologies continues to develop at an accelerated pace, ET hopes to play a crucial role in
helping to identify, prototype and perhaps build those systems that will enable technology to
serve SSA’s needs.

Possible technologies to be studied include, but are not limited to:

      Authentication and Authorization Technologies & Gateways.
      Blogging.
      Cloud Computing.
      Code Generators.
      Collaboration and Reporting.
      Content Management.
      Data Mining.
      Data Quality and Profiling.
      Data Sanitization.
      Data Warehousing.
      Document Imaging.
      Electronic Service Delivery.
      Extraction, Transform and Load (ETL).


                                                 43
      eTags.
      Grid Computing.
      High Speed Networking.
      Mobile and Portable Office Technologies.
      PKI, Digital Certificates, and eSignatures.
      Server Virtualization.
      Service Delivery Channel Convergence.
      Service Oriented Architecture (SOA).
      Smart Card Technology.
      Software as a Service.
      Voice Telephony and Recognition.
      Web Development including J2EE/Java.
      Wikis.

A more detailed list can be found in Attachment B-2. Should the Agency decide to adopt
technologies in any of these areas, the Contractor shall support SSA’s efforts to implement and
utilize the technology.

SECTION B.9 – TECHNICAL AREA 8: SOFTWARE ENGINEERING MANAGEMENT

The Contractor shall be required to assist SSA in all aspects of software engineering
management. The Contractor shall review the consistency, completeness, and correctness of
systems at each stage and between each stage of the systems development lifecycle. In addition,
the Contractor shall assist SSA in planning for the integration of systems into the cooperative
processing architecture as well as establishing a baseline and controlling changes within each
system.

Typical activities to be performed under this technical area are included in, but not limited to, the
following list; more detailed, but not all-inclusive, activity descriptions follow below.

      Alternatives Analysis
      Backup and Restore of Application Data
      Backup Software for Disaster Recovery
      Business Re-engineering
      Configuration Management
      Cost Benefit and Return on Investment Analyses
      Feasibility Studies
      Function Point Measurements
      Independent Verification and Validation
      Quality Control/Quality Assurance
      Requirements Management
      Software Accessibility in Compliance with Section 508 Regulations
      Software Benchmarking and Capacity Studies
      Software Configuration Management
      Software Inventory Control


                                                 44
      Software Process Improvement
      Software Standards
      Software Tool Assessments
      Software Usability
      Transition Planning for New Architectures

B.9(a) – Independent Verification and Validation (IV&V)

The IV&V activities shall be performed on systems/projects developed in-house and/or by
another Contractor. The Contractor shall not perform IV&V on any effort in which it was
involved in the development process.

B.9(b) – Performance of Independent Verification and Validation Activities

In addition to supporting the IV&V requirement as stated above, the Contractor shall support the
following activities on any system or project and/or on any part of a system or project including,
but not limited to:

      Review and assess the adequacy of technical and management approaches used in:
           o Plans;
           o Designs;
           o Cost Benefit Analyses;
           o Documents;
           o Strategy papers; and
           o Implemented systems.
      Perform an unbiased assessment of actual project status:
           o How far system development has progressed; and
           o Identification of potential problems that could affect the project schedule.
      Review system development lifecycle products:
           o Map back to earlier lifecycle products, such as user requirements;
           o Verify adherence to standards; and
           o Verify consistency with architectures as specified in the IRM Strategic Plan.
      Conduct independent system testing and/or monitor the testing conducted by others:
           o Preparation of test plans;
           o Creation of test data;
           o Predicting test results;
           o Conduct unit, validation, and integration testing; and
           o Report on test results.
      Analyze System Development Team Practices/Performance:
           o As they relate to the disciplines presented in PRIDE;
           o Project management techniques; and
           o Contract administration methods.
      Assess risk areas in the systems being built, including:
           o Security/Privacy;
           o Fraud/Abuse; and
           o Adequacy of Internal Controls.


                                                45
      Conduct Post-Implementation Reviews of Developed Systems
      Monitor/Validate:
          o Preparation of validation plan;
          o Creation of validation databases;
          o Execution of full system cycles; and
          o System certification practices.

B.9(c) – Improvement of SSA’s Independent Verification and Validation Environment and
Processes

The Contractor shall provide expert systems analysis and development support services to assist
in the reengineering of SSA’s software testing and IV&V environment. Some potential areas of
support may include, but not be limited to:

      Reengineer the Validation Environment;
      Test Process Automation;
      Validation Databases;
      Distributed Systems-Internet Validation Process;
      Systems Release Certification Process;
      Maintain Validation Environment; and
      Identify Commercially Available Test Tools.

B.9(d) – Testing and Validation Support for Agency Improvement Initiatives including CA,
HIT and SOA

      Designing, developing and supporting, or evaluating and supporting, COTS tools in the
       areas of, but not limited to:
           o Development of Test Data Management Tool;
           o Development of Configuration Management Tool;
           o Management of Data and Maintenance of Tools; and
           o Data Sanitation.

B.9(e) – Project Management

The objective of this task is to provide direction and control of project personnel, establish a
framework for effective project communications, reporting, procedural, and contractual activities.
The major sub-tasks include, but are not limited to:

      Maintain project communications through SSA’s Project Manager;
      Establish documentation and procedural standards for the development of the project;
      Prepare a project plan at the onset of each existing or new project task for performance of
       this contract. The project plan will define tasks and schedule responsible personnel for
       each milestone;
      Conduct project status meetings weekly via conference call with SSA’s personnel
       responsible for the overall management of the project;
      Respond to SSA’s ad-hoc requests for information and support;


                                               46
      Produce weekly progress/update reports that outline the status of Contractor and any
       associated SSA activities; and
      Review and administer Project Change Control with SSA’s Project Manager.

B.9(f) – Application Transition Planning and Integration

The Contractor shall provide support to integrate target systems in multiple-platform,
cooperative mode, with existing systems, databases, telecommunications networks and hardware.
It is critical that when transitioning from the current software architectures to the target
architectures, negative impacts to ongoing processing do not occur. Contractor support will also
be required for integrating software initiatives with SSA’s other initiatives. The Contractor may
support the following types of activities:

      Strategic Planning for Software Engineering:
           o Analyze new initiatives and their impact on the architectures found in the IRM
               Strategic Plan;
           o Provide assistance in incorporating new initiatives/directives into the architectures
               listed in SSA’s IRM Strategic Plan; and
           o Analyze technological advancements in light of the evolutionary process of the
               architectures described in SSA’s IRM Strategic Plan.
      Tactical Planning for Software Engineering:
           o Assist the OS in inter-project dependencies and critical path dependencies,
               contingency planning and backup of software for disaster recovery, and in the
               development and maintenance of transition plans for moving from the current
               architecture to the target architecture and of the System Release Schedule (SRS)
               that shows the major system releases and their schedules; and
           o Tie in software tactical plans with other operations plans.
      Integration of Software Engineering Initiatives:
           o Assist the OS in coordinating and integrating interdependent programmatic
               software engineering projects.

B.9(g) – Software Configuration Management

The Contractor shall support the requirements for Software Configuration Management (SCM).
SCM is defined as a discipline of identifying the configuration of a system at discrete points in
time for purposes of systematically controlling changes to this configuration and maintaining the
integrity and traceability of this configuration throughout the software lifecycle. The
configuration of the system refers to the baselined products developed through the software
development lifecycle.

The Contractor must have the training and expertise to perform the following types of SCM
activities:

      Support SSA’s personnel in preparing the SCM plans for Applications Design and
       Development Support and Software Maintenance and Improvement Support. The SCM
       plan will address the following:


                                               47
           o SCM procedures for identifying, controlling and auditing configuration baselines;
           o Forms used for change control and trouble reporting;
           o Conventions for labeling configuration items;
           o Automated aids available to support the SCM process;
           o Required configuration status accounting reports; and
           o SCM resource estimation.
      Support SSA’s personnel in performing configuration identification functions. These
       functions include, but are not limited to:
           o Use configuration identification labeling conventions described in the SCM plan
               for identifying all configuration items;
           o Maintain a database which documents all configuration items which have been
               prepared during the software development lifecycle; and
           o Prepare reports tracing the evolution of a baselined product.
      Support SSA’s personnel in auditing configuration items. These functions include, but
       are not limited to:
           o Verify that each configuration item is logically related to the specifications of
               preceding baselines;
           o Validate that system and software requirements are fulfilled through the
               configuration items;
           o Perform technical analyses of configuration items for impact on the programmatic
               system configuration and other systems under development;
           o Provide recommendations for acceptance or revision to the documents; and
           o Advise SSA’s management of configuration issues making recommendations for
               resolution.
      Support SSA’s personnel in configuration status reporting of significant events affecting
       the development of all lifecycle products:
           o Support the maintenance of a complete and organized database of all significant
               events affecting software lifecycle products; and
           o Generate scheduled configuration status accounting reports as identified in the
               SCM plan.
      Support SSA’s personnel in evaluating lifecycle products submitted for final approval.
       These functions include, but are not limited to:
           o Prepare, or assist in the preparation of, a configuration management impact
               assessment;
           o Assist in the resolution of differences in product assessment of defining issues and
               recommending options; and
           o Assist in the scheduling and preparation of briefing materials for configuration
               control board meetings.
      Develop, maintain and support software configuration management tools.

SECTION B.10 – TECHNICAL AREA 9: SYSTEMS ADMINISTRATION FOR Z/OS,
UNIX, WINDOWS, AND WEBSPHERE

The Contractor shall provide technical server support and maintenance across the following
platforms: z/OS, UNIX, Windows, and WebSphere. WebSphere software is continuing to move



                                               48
from versions 5.0 and 5.1 to version 6.1. Sun Solaris UNIX is moving from version 8 to version
10. Windows servers are at version 2003, and workstations are moving from XP to Vista.

Systems administrative technical support will be needed for WebSphere on z/OS, on UNIX, and
on Windows platforms, and for each of the Operating Systems platforms. Contractor support
may include, but not be limited to, the following types of activities in order to assure SSA of
robust development, validation, and tools environments.

      Installing, configuring, administering, and troubleshooting Solaris/UNIX 8, 9 and 10, (or
       currently supported versions) operating systems;
      Installing, configuring, networking, administering, and troubleshooting Solaris/UNIX
       hardware and software and taking corrective action;
      Performing daily network and systems administration tasks;
      Performing user administration for development, validation, and tools users;
      Providing support for application developers;
      Building Solaris/UNIX servers;
      Building and administering Solaris/UNIX systems to support distributed platform
       development efforts;
      Installing, administering, and troubleshooting WebSphere servers (WAS 5.1 and WAS
       6.1 or currently supported versions) on a Solaris/UNIX platform;
      Installing, configuring, and administering WebSphere (WAS) on z/OS, UNIX, and
       Windows;
      Administrating servers, and WAS networking in a multi-node environment;
      Installing, administering, and troubleshooting ColdFusion MX for UNIX;
      Installing, configuring, and using SunOne Web Server;
      Installing, configuring, and using Sun Java System Web Server;
      Maintaining compliance with the Division of Information Systems Security
       Administration and Operations (DISSAO) security standards;
      Maintaining data files and monitoring systems configuration;
      Patching, updating, and upgrading hardware, systems software, and application software;
      Architecting, configuring, and maintaining the EMC Storage Area Network (SAN)
       infrastructure;
      Maintaining the Sunray environment;
      Implementing and administering Backup and recovery software (Veritas NetBackup) to
       support developers;
      Testing, configuring, and implementing fail-over software to support critical developer
       applications;
      Installing, configuring, and using eTrust Access Control;
      Resolving eTrust issues;
      Installing, configuring, and using IBM HTTP server;
      Installing, configuring, troubleshooting and maintaining Oracle HP-UNIX Server;
      Installing, configuring, and using Webmin;
      Installing, configuring, and using Apache;
      Writing scripts to automate repetitive administration tasks;
      Scripting the deployment of software when applicable;


                                               49
   Maintaining existing scripts;
   Upgrading and maintaining the Java Development Kits (JDKs) on all appropriate servers;
   Monitoring and resolving issues from the helpdesk or users;
   Troubleshooting WebSphere configuration and network problems;
   Reading and interpreting WAS logs to resolve configuration/application issues;
   Configuring IHS and interpreting IHS logs;
   Providing UNIX support and installing, configuring, and updating MKS interface for
    WebSphere deployments;
   Working with UNIX operational personnel to identify WebSphere performance issues;
   Working with UNIX operational personnel to identify space issues;
   Configuring WebSphere UNIX for Lightweight Directory Access Protocol (LDAP)
    security;
   Installing, configuring, and updating DB2 connect for WAS compatibility;
   Installing, configuring, and updating Oracle Client for WAS compatibility;
   Working with Java code and J2EE;
   Providing guidance to software developers about systems requirements;
   Presenting project status reports and other information to technical staff, customers and
    management;
   Coordinating repairs and maintenance with vendors;
   Setting up the servers and directories for WebSphere on z/OS;
   Conducting Initial Planning Meetings for developers new to WebSphere, explaining the
    WebSphere environment and the requirements to start a project;
   Contacting developers, support staff, or vendors for more information or assistance in
    solving problems, opening problem reports (PMRs) with IBM on major issues, and
    following up when needed;
   Providing after hours support for application support or software testing (that affects
    WebSphere on z/OS) as needed;
   Performing health checks on WebSphere cells;
   Building new WebSphere cells and performing upgrades and maintenance when needed;
   Maintaining the WASIPM Website;
   Updating WebSphere support documentation;
   Providing z/OS support for MKS interface for WebSphere deployments;
   Working with z/OS operational personnel to identify WebSphere performance issues;
   Working with z/OS operational personnel to identify Unix System Services space issues;
   Creating application directories in Unix Systems Services;
   Installing and maintaining the Time Provider Library for WebSphere z/OS;
   Participating in WebSphere proof of concepts (e.g. security single sign-on);
   Configuring WebSphere z/OS for LDAP security;
   Researching best practices;
   Building, installing, configuring, networking, administering, and troubleshooting HP
    UNIX system;
   Installing, configuring, administering, and troubleshooting Windows Advanced Server
    2003 (or currently supported versions) operating systems;




                                           50
      Installing, configuring, networking, administering and troubleshooting Windows server
       hardware, software and peripherals, and taking corrective action;
      Building Windows servers;
      Building and administering Windows systems to support distributed platform
       development efforts;
      Installing and administering Windows virtualization software (such as Microsoft HyperV
       or VMWare ESX) and supporting tools, to support a national user base of Windows
       application developers;
      Installing and administering SAN equipment in support of Windows or UNIX servers;
       and
      Installing, administering, testing, and troubleshooting a SAN and tape library backup and
       recovery process for all critical server data.

SECTION B.11 – CONTRACTOR COMPETENCIES/EXPERIENCE REQUIREMENTS

In order to provide support for the nine technical areas, the Contractor’s aggregate personnel
must have diverse knowledge, skills and experience. The following list provides a “baseline”
reference for the skills, knowledge and experience necessary to support SSA’s requirements.
This list is not all-inclusive. The future marketplace will dictate any additional skills, knowledge,
and experience SSA may require. The Agency does not expect that each individual proposed by
the Contractor to perform on this contract will be knowledgeable in every item on the list.
However, the Contractor must be able to provide Contractor personnel to meet these
requirements and/or provide Contractor personnel highly skilled at quickly learning the
essentials of the skills requirements.

In order to provide support for Task Orders, the Contractor must provide personnel with
experience in requirements, analysis, design, development, testing and implementation of large
business oriented data systems. Additionally, experience is needed in developing software for
mainframe, client-server, and distributed processing environments. Experience and knowledge
of communications integration among PC workstations, LANs and mainframes as it relates to
software design and development is required to support SSA’s applications development efforts.
Skills are required to provide technical support for software strategies in evaluating SSA’s
design alternative.

Systems analysis and design techniques employed must result in the development of modern,
structured systems. The Contractor must have working knowledge of structured techniques and
methodologies, and create and use test files that simulate production systems. Use of SSA’s
various development and production facilities requires knowledge of test and debug facilities,
code generators, the awareness and understanding of library functions, and the use of
programmer workbenches and system utilities. The Contractor must provide personnel with
experience in various software development languages.

Data Administration and Database Administration skills are required to design and develop
SSA’s databases for cooperative processing environments in real-time, interactive and off-line
modes. In addition, the Contractor must have experience with the use of database access
languages such as ANSI SQL or other vendor SQL package, such as the IBM SQL package for


                                                 51
mainframe, LANs, and PC-based systems. Examples of work in the database area include
evaluating DBMSs, Master File restructuring, security, integrity, reviewing physical database
designs, database software installation and maintenance and data purification and data dictionary
management support.

As necessary, the Contractor must be able to obtain personnel with specialized skills in highly
technical areas to analyze and evaluate the feasibility of using new technologies in the distributed
processing/cooperative processing environment. SSA will evaluate and/or pilot a multitude of
emerging technologies, including, but not limited to: Authentication and Authorization
Technologies and Gateways, Cloud Computing, Code Generators, Collaboration and Reporting,
Content Management, Data Mining, Data Quality and Profiling, Data Sanitization, Data
Warehousing, Document Imaging, Electronic Service Delivery, Extraction, Transform and Load
(ETL), eTags, Grid Computing, High Speed Networking, Mobile and Portable Office
Technologies, PKI, Digital Certificates, eSignatures, Server Virtualization
Service Delivery Channel Convergence, Smart Card Technology, and Wikis.

In addition to the technical skills required in the contract, the Contractor’s management team and
employees must provide administrative and management skills to plan, organize, lead and
provide quality deliverables in a timely manner and within cost estimates. Process and project
management must be conducted according to the practices delineated in the CMM/CMMI.
Quality of deliverables cannot be sacrificed due to the number of projects underway. A
consistency in superior performance must be evidenced prior to contract award.

Business and interpersonal skills are required to perform business analysis activities including,
but not limited to, data collection, workload performance measurement and resolving issues or
selecting strategies via computer-generated tools. Communication skills are essential in
developing and reviewing Task Orders and deliverables as well as working out daily issues and
problems. Technical training skills are necessary to transfer technical knowledge and skills to
SSA’s staff. Technical writing skills will be required to produce lifecycle deliverables,
workplans, and reports. Documentation of procedures/systems must be done to enable ease of
technical and operational upgrades.

Examples of competencies required by the contractor can be found at Section E.7. This list is
not all-inclusive.

SECTION B.12 – SOFTWARE ENGINEERING PROCESS (SEP)

The Contractor must submit evidence that the proposed Software Engineering Organization has
demonstrated, within the past two (2) years, fulfillment of Level 3 or higher requirements based
upon a CMM/CMMI-based appraisal.

The Contractor must submit to SSA for review the proposed documented software engineering
processes, which will be followed in the conduct of work performed under this contract. The
Contractor must show how the ITSSC will fit into the organization that received the
CMM/CMMI-based appraisal. The Contractor must demonstrate the ability to staff the contract
with personnel experienced in its documented software engineering practices.



                                                52
The Contractor’s documented processes, as submitted with its proposal in response to this
solicitation, will be incorporated into the contract award document. The Contractor shall work to
improve these practices and procedures throughout the performance of all aspects of the
operation and management of the software development lifecycle environment and shall update
the documentation upon SSA’s approval. SSA reserves the right to implement procedures to
monitor the Contractor’s Software Quality Assurance activities and Software Configuration
Management activities.

SECTION B.13 – PROJECT PERFORMANCE/COMPLIANCE, REPORTING
REQUIREMENTS AND DELIVERABLES

B.13(a) – Project Management Plan

In order to ensure sound project performance and compliance, the Contractor shall institute and
maintain a project management approach that will plan, organize, staff and direct the
Contractor’s efforts throughout the life of this contract. This project management approach shall
be fully set forth in the Contractor’s proposal as the Contractor’s “Project Management Plan” for
this contract. The Project Management Plan shall present the Contractor’s project management
approach and philosophy for this contract.

The plan shall address and discuss proposed policies, procedures, techniques and software to be
employed to assure cost effective and quality performance in the following areas: application of
CMM/CMMI-qualified processes, organization and personnel to this contract, project
management organization; Task Order management in accordance with Section E.3 - Task Order
Ordering Procedures; periodic progress and financial reporting; facilities and automation support;
systems and personnel security; staffing; training; contract phase-in; and quality
assurance/quality control.

The Contractor’s Project Management Plan shall be developed in accordance with the provisions
of this Section B.13(a) Project Management Plan, and in accordance with the instructions in
Section B.13(a)(2) Project Management Section. The Project Management Plan shall be
included as part of the Contractor’s Technical Proposal.

Subsequent to contract award, formal delivery and ongoing maintenance of the Project
Management Plan shall be required and shall be allocated under the Contract Management Task
Order. The Contractor shall use Microsoft software, including Word, Outlook, Access, Excel,
PowerPoint, and Project to support its Project Management Plan and this contract. The
Contractor shall be required to use the software release levels SSA designates at the time of
contract award for compatibility purposes, unless specified differently in the Task Order request.

Any modifications to the Project Management Plan made after contract award must be agreed to
by the COTR. Requests by the Contractor to modify the plan shall be made, in writing, to the
Contracting Officer (CO). Requests to modify the plan shall be made, in writing, by the CO.
Any mutually agreed changes shall be included as part of the Monthly Contract Summary




                                                53
Report/Invoice (reference Section B.13(g) Reporting Requirements & Acceptance of
Deliverables and Section C.1(c)(2) Monthly Contract Summary Report/Invoice).

The Contractor’s Project Management Plan for this contract shall consist of the following seven
(7) sections:

   1.   Staffing
   2.   Project Management
   3.   Phase-In Plan
   4.   Labor and Cost Planning, Reporting and Control
   5.   Quality Assurance/Quality Control
   6.   Training
   7.   Small Business Subcontracting Plan

The minimal requirements for each of these sections are discussed below.

B.13(a)(1) – Staffing Section

The Contractor shall provide a comprehensive staffing plan describing how the Contractor
proposes to meet the staffing requirements of the contract. This section shall also include the
resumes of all Key personnel.

I. Qualifications

   Contractor personnel assigned to the performance of this contract shall satisfy the personnel
   qualification requirements as set forth in Section E.1 - Personnel Qualifications, of this
   solicitation/contract. The Contractor’s aggregate personnel should be able to meet the
   requirements set forth in Section B.11 – Contractor Competencies/Experience Requirements.

II. Key/Non-Key Personnel Definitions

   a. Key Personnel

        Key personnel under this contract are defined as personnel assigned to labor categories
        designated as Key labor categories. The Key labor categories specified in this contract
        are considered to be essential or “Key” to the work being performed hereunder. The
        contract may be amended from time to time during the course of the contract to either add
        or delete Key personnel, as appropriate. Replacement procedures for Key personnel are
        included in Section C.2(b) Program Director and Key personnel.

        Key personnel as defined and designated in Section C.2(b) Program Director and Key
        personnel of this solicitation/contract shall consist of those individuals assigned to the
        following labor categories:

           Program/Project Manager/Director (3);




                                                  54
        One resource from the following Level 3 categories:

           Administrative/Business Operations Specialist/Manager
           Business Process/Requirements Analyst
           Computer Systems Analyst/Programmer
           Data/Systems Architect
           Database Engineer/Administrator
           Information Technology Specialist
           Subject Matter Expert
           Systems/Network Administrator/Engineer
           Systems Security Engineer
           Validation Specialist
           Web Technology Specialist

        Labor category personnel qualifications for Key personnel are included in Section E.1 -
        Personnel Qualifications.

    b. Non-Key Personnel

        The remainder of the Level 1 and 2 labor categories as defined in Section E.1 - Personnel
        Qualifications of this solicitation/contract shall be considered Non-Key personnel and
        include the following labor categories:

           Administrative/Business Operations Specialist/Manager
           Business Process/Requirements Analyst
           Computer Systems Analyst/Programmer
           Data/Systems Architect
           Database Engineer/Administrator
           Information Technology Specialist
           Subject Matter Expert
           Systems/Network Administrator/Engineer
           Systems Security Engineer
           Validation Specialist
           Web Technology Specialist

III. Retention

    Staffing continuity through the retention of a highly qualified technical staff is a major factor
    for success in achieving high quality products and efficient performance of software support.
    It is considered important to the success of this contract that the Contractor provides for staff
    continuity throughout the life of this contract. The Contractor’s management shall discuss
    potential staffing changes with SSA’s management as soon as practicable. The Contractor
    shall give a minimum of 2 weeks notice for staffing changes except where mutually agreed.

IV. New and Replacement Staff




                                                 55
   The Contractor shall promptly notify the CO and COTR simultaneously, of any personnel no
   longer under the Contractor’s employ or the employ of any subcontractor. The loss of Key
   personnel should include a justification and an impact analysis and must be approved by the
   COTR, as required by Section C.2(b) – Program Director and Key personnel.

   When the Contractor adds new personnel or replaces personnel after contract award, the
   Contractor shall submit resumes in the format outlined in Section E.2 – Resume Format, to
   the COTR for review and approval.

   The process by which personnel in the position description categories can be assigned to,
   charged to, and work on Task Orders under this contract is through submission and
   certification by the Contractor, and verification and validation by the COTR, of personnel
   resumes in the prescribed resume format.

   Personnel resumes may be submitted as part of the Contractor’s proposal or any time during
   the life of the contract. Once verified and validated by the COTR for specific position
   description labor categories, proposed personnel may be selected to work on Task Orders
   under the contract only if that labor category and skill(s) are needed for a particular Task
   Order.

   Personnel are chargeable to the contract only through an approved Task Order. Once a Task
   Order has been completed, the individuals’ names remain in the approved pool of personnel
   resources that may work on a Task Order, but are no longer chargeable to the contract until
   employed under another Task Order.

   In the event of a question relative to a submitted resume for Key personnel, the Contractor
   understands and agrees that the COTR may request a meeting with the proposed individual to
   discuss the individual’s resume and qualifications. The COTR must be assured that all
   replacement personnel are qualified to work under the contract.

   The Contractor’s Program Director, or designee, shall be in attendance at any such meeting.
   However, in no event shall this process result in the establishment of, nor take upon the
   appearance of, a personal services/employer-employee relationship between SSA and the
   Contractor.

V. Resource Pool

   Where appropriate, the Contractor may submit names and resumes before it is known that
   replacement personnel are actually needed. Advanced review and endorsement of potential
   replacement personnel by the COTR will help expedite workplan proposal approvals and
   establish a pool of qualified personnel. The COTR will notify the Contractor of the result of
   its resume verification and validation process in writing.

   After an individual has been determined to meet the qualifications for a particular labor
   category the individual may be proposed by the Contractor to perform in that particular
   position under various Task Order(s).



                                               56
VI. Resumes

     The resumes of all proposed Key personnel shall be included in the Staffing Section of the
     Project Management Plan. The Contractor and the COTR shall maintain resume files of all
     personnel authorized to work on Task Orders under the contract. The Contractor shall be
     required to notify the COTR of the name, labor category changes, labor rate changes and
     departures of all personnel working on the contract within two (2) weeks of the effective date.

VII. New Requests for Task Orders

     For new requests for Task Orders, the Contractor shall submit names and resumes of all
     personnel with the workplan proposal or earlier, if possible.

     In conclusion, the Contractor’s Staffing Section shall, at a minimum, address/include the
     following:

        Qualifications of proposed staff;
        The procedures for staffing to meet Task Order requirements and personnel replacement
         procedures as discussed above, particularly as to how the Contractor will ensure that
         qualified staff are available at the time that Task Orders are requested, negotiated and
         initiated in accordance with SSA’s Task Order Ordering Procedures as described in
         Section E.3 - Task Order Ordering Procedures;
        The expected number of personnel to be hired; to be transferred from within the
         Contractor’s own organization; and any sub-contracting support anticipated. The plan
         shall also address the anticipated number of proposed transfers or newly hired personnel
         from the local area as well as the number of relocations/travel anticipated (including
         point of origination for travel/ relocation) by labor category. Any individual for whom
         relocation is paid must remain on the contract for a minimum of 1 year; or the Contractor
         must repay SSA the relocation charges. However, it should be noted that although
         relocation expenses are allowable, SSA will require substantial justification and will
         approve such costs, only on an exception basis.
        Efforts that will be undertaken to recruit qualified staff not currently in the Contractor’s
         employ;
        Procedures which will be used to ensure that qualified staff assigned to other
         locations/projects will be available when needed and with the proposed level and degree
         of commitment;
        Methods, procedures and criteria for coping with attrition, hiring to fill vacancies,
         evaluating personnel performance, promoting personnel, motivating personnel to produce
         timely, cost effective products with technical quality and effectuating disciplinary actions;
        Incentive plans, retirement plans and awards; and
        The Contractor’s philosophy and practices for motivating personnel assigned to this
         project/contract to produce timely, cost-effective products with technical quality.




                                                  57
B.13(a)(2) – Project Management Section

I. Application of CMM/CMMI-Qualified Processes, Organization and Personnel to this
   Contract

   The Contractor shall show how the proposed documented software engineering processes
   will be performed/applied under this contract and how this contract will fit into the
   organization that received the CMM/CMMI-based appraisal. In addition, the Contractor will
   demonstrate the ability to staff this contract with personnel experienced in the documented
   software engineering processes that qualify for the CMM/CMMI-based appraisal. Included
   in this section shall also be an overview of the Contractor’s documented processes that have
   been included in the proposal. Finally, this section must show a means of ensuring that the
   Contractor is continuing to operate at the CMM/CMMI level stated in the proposal once the
   proposed documented software engineering processes have been applied to this contract.

II. Project Management Organization

   The Contractor shall describe the detailed structure and functions of the project management
   organization responsible for management of the contract. The Contractor shall provide an
   organization chart that will identify the project management organization within the existing
   corporate structure.

   Methods and lines of communications between corporate units shall be described, especially
   as they relate to assuring access to, and timely support from, corporate resources/staff
   relative to the needs of this project/contract. The relationship and proposed interfaces to
   assure timely and effective communications between the project management organization,
   any proposed subcontractors, and SSA’s staff shall also be described.

   The Project Management Section shall provide a project management organizational chart
   for this project/contract identifying all managerial positions by title and name of individual.
   The Contractor shall clearly state the responsibilities and authorities of each manager by
   describing the amount of independence, access to corporate management, etc. The plan shall
   also reflect how the corporate organization will contribute to, support, and recognize the
   responsibilities and authorities of each manager and Key personnel.

   The Contractor shall provide a description of the Program Director’s independence and
   authority to manage this project/contract relative to technical issues/matters. The Contractor
   shall clearly state the reasons for, and method of, the Program Director’s access to corporate
   officials. The types and degree of corporate support that will be available to the Program
   Director in the performance of this project/contract shall be described.

   Also, the Contractor shall explain the corporate support in terms of location, flexibility,
   timeliness and availability to the Program Director.




                                                58
    Additionally, the Contractor shall provide information concerning the corporate professional
    affiliations and/or agreements with industry experts and professional organizations and the
    availability of these resources to the project/contract.

III. Task Order Management

    The Contractor shall be required to comply with SSA’s Task Order Ordering Procedures
    described in Section E.3 - Task Order Ordering Procedures.

    The Contractor shall describe in the Project Management Section how it proposes to manage
    Task Orders issued by SSA to meet the requirements of this contract. This description shall
    include the proposed method for determining how cost, schedule and technical performance
    will be planned/projected throughout the life of the contract, along with a complete definition
    of the cost management system (tracking, reporting and controlling) which will be employed
    on the corporate and project management level, as well as how the Contractor will comply
    with the Task Order Ordering Procedures.

IV. Periodic Progress and Financial Reporting

    The Contractor shall also describe in the Project Management Section how the Contractor
    proposes to manage the periodic progress reporting requirements and meetings, including
    Monthly Electronic Technical Progress Reports (eTPR) by Task Order, Monthly Contract
    Summary Report/Invoice, Monthly Financial Planning Reports, Weekly Task Order Status
    Reports, Weekly Summary Progress Report/Meeting, Weekly Task Order Manager/Project
    Manager Meeting, and other formal meetings required by Section C.1(c) - Periodic Progress
    Reports.

    The Contractor shall also describe in this section compliance with the subcontract reporting
    requirements as defined in Section E.8. - Individual Subcontract Report and the Summary
    Subcontract Report (SSR) in the Electronic Subcontracting Reporting System (eSRS) at
    www.esrs.gov)

 Finally, the Contractor shall describe in this section how it plans to reconcile and match the
 resource and cost information provided as part of these reports with the financial information
 required pursuant to the invoice submission requirements as defined in Section C.1(c) -
 INVOICE SUBMISSION AND PAYMENT RELATED INFORMATION

V. Facilities and Automation Support

    The Contractor shall provide the physical location of the proposed Program Management
    Office, including distance from SSA’s Headquarters. The Contractor shall also provide full
    details regarding its plans for establishing and maintaining the requisite automation support
    proposed in response to the automation support requirements for this project/contract
    including the timeframes, procedures and process for acquiring additional facilities and
    automated support after contract award, as set forth under Section B.13(b) Project Facilities
    and Support Requirements, Section B.13(c)(2) Contractor Responsibilities/Data



                                                 59
    Communications, Section B.13(d)(2) Contractor Responsibilities/Local Area Network, and
    Section B.13(e)(2) Contractor Responsibilities/Intelligent Workstations. The contractor shall
    also provide full details of its Continuation of Operations Plan (COOP) for all personnel
    resources and the proposed off-site facility. The COOP shall ensure acceptable level of
    service under all circumstances.

VI. Systems, Physical, and Personnel Security

    The Contractor shall also provide as part of the Project Management Section, a detailed
    discussion of its proposed plans for complying with the physical, system and personnel
    security provisions of this solicitation/contract. The Contractor shall appoint one of its
    managers/Key personnel to serve as the Contractor’s “Security Officer”. This individual
    shall be responsible for all aspects of Contractor security activities.

    The Contractor shall comply with the security requirements set forth in SSA’s Systems
    Security Handbook and the requirements directed by SSA’s Office of Systems Security
    Operations Management. This includes physical security requirements. The Contractor shall
    include applicable provisions in any subcontract awarded pursuant to this contract.

    a. Systems Security

        The Contractor’s staff shall be required to use UserIDs, PINS, passwords, etc., to access
        the ESEF and MISF and any of SSA’s LAN resources. These controls are described in
        the ESEF User Guide and the MISF User Guide. Necessary forms will be provided after
        contract award. The Contractor Security Officer and COTR shall sign each form.

        The COTR must also authorize access to SSA’s LAN resources and any resources (such
        as production complexes) other than the ESEF and MISF.

        The Contractor shall follow the procedures, guidelines, restrictions and conventions
        described in the ESEF and MISF User Guides. For example, the Contractor shall be
        responsible for purging unnecessary and/or outdated work files, program versions and so
        forth.

        Systems access will be granted after the appropriate background investigation based upon
        position risk designation has been completed.

    b. Physical Security

        Once a preliminary background check has been completed, the Contractor employees will
        be able to apply for an HSPD-12 credential and receive a temporary badge. The badge
        will grant them access to all Headquarters buildings. Once the HSPD-12 credential is
        issued, the Contractor employee will return the temporary badge to the Parking and
        Credentialing Office located in the Operations Building.

    c. Personnel Security



                                                60
       The Contractor shall also comply with the following personnel security requirements:

       The Contractor is responsible for timely notification to the COTR and CO when an
       employee is no longer working on the contract. The Contractor shall be required to
       return the temporary badge or the HSPD-12 badge.

B.13(a)(3) – Phase-In Plan Section

SSA anticipates a phase-in period of up to 90 calendar days from the date of contract award to
July 31, 2010 with an initial 2 month contract year immediately thereafter beginning on August 1,
2010 and ending September 29, 2010. During the phase-in period, SSA will hold orientation
sessions starting within 5 to 7 work days from award of the contract, to familiarize Key
Contractor personnel with SSA’s environment, organization, mission, functions, architectures,
the PRIDE, Contractor workloads, Task Order Ordering Procedures, contract management
requirements, security and logistical information. The orientation, including facility tours, is
anticipated to take 2 to 3 days.

The Contractor personnel to be in attendance at the orientation sessions shall include only
individuals proposed, committed and certified by the COTR as qualified for the contract’s Key
personnel labor category positions. Specifically, the following personnel are required:

Labor Category

       Program/Project Manager/Director                               4
       Administrative/Business Operations Specialist/Manager          1
       Business Process/Requirements Analyst                          1
       Computer Systems Analyst/Programmer                            1
       Data/Systems Architect                                         1
       Database Engineer/Administrator                                1
       Information Technology Specialist                              1
       Subject Matter Expert                                          1
       Systems/Network Administrator/Engineer                         1
       Systems Security Engineer                                      1
       Validation Specialist                                          1
       Web Technology Specialist                                      1

       Total Key Personnel at Orientation                                     15

The Contractor shall be required to provide a reason in writing, which SSA deems acceptable,
for the absence of committed personnel from the complete orientation session.

The Contractor shall be responsible for subsequent orientation training of its staff (this particular
aspect shall be addressed in the Training section of the Project Management Plan).




                                                 61
During the Contractor’s orientation to the Agency, SSA will initiate the Task Order Ordering
Procedures such that actual Task Orders are in place and technical/project efforts are underway
by the end of the phase-in period. In order to be immediately effective in staffing and
performing the Task Orders, it is anticipated that the Contractor shall have, at a minimum, the
following Non-Key personnel committed, on-board and certified by the end of the phase-in
period in addition to the aforementioned Key personnel who shall be required to attend
orientation sessions:

       Business Process/Requirements Analyst           10
       Computer Systems Analyst/Programmer             13
       Data/Systems Architect                          10
       Database Engineer/Administrator                 10
       Information Technology Specialist               10
       Subject Matter Expert                           10
       Systems/Network Administrator/Engineer          10
       Systems Security Engineer                       10
       Validation Specialist                           10
       Web Technology Specialist                       10

       Minimum Total Additional Personnel:                     103

MIMIMUM TOTAL PERSONNEL ON AUGUST 1, 2010: 118

Therefore, the total anticipated minimum Contractor staffing requirement by the end of the
phase-in period shall be the total of the aforementioned labor categories and personnel equaling
118 contractor personnel performing work on August 1, 2010.

In the Phase-In Section of the Project Management Plan, the Contractor shall provide a detailed
Phase-In Plan relating how the Contractor expects to staff, organize and have its personnel
certified to meet the aforementioned requirements for orientation and for the phase-in period.
Certification requirements for personnel under each labor category position shall be stated,
including examination methods or procedures for determining the satisfaction of those
requirements.

The Phase-In Plan shall specify project organization for the phase-in period, associated with each
element of this organization. The Phase-In Plan shall also describe how the Contractor will
interface with SSA personnel during this period.

The Contractor shall state its intention as to hiring any personnel not in the Contractor’s employ
at the time this contract is awarded and whether they are in the local area or if relocation/travel is
necessary and from where. However, it should be noted that although relocation expenses are
allowable, SSA will require substantial justification and will approve such costs only on an
exception basis. The Contractor shall state the procedures that will be used to ensure that
personnel not in the current employ of the Contractor/subcontractor(s), personnel assigned to
other locations of the Contractor/subcontractor(s), and/or personnel assigned to other projects for
the Contractor/ subcontractor(s) shall be available when and where required.



                                                  62
The Phase-In Plan shall also address in detail how the Contractor proposes to have the facility
and automation support established during the phase-in period and ready for staff resources and
work initiation at the end of the phase-in period.

B.13(a)(4) – Labor and Cost Planning, Reporting and Control

The Contractor must prepare and maintain labor plans which identify resources by: person, labor
category, Technical Area Fair Opportunity Awards, Task Order, and Work Order for hours on at
least a monthly basis. The plans must:

      Reflect current funding and staffing levels;
      Incorporate the latest available actuals;
      Be presented in accordance with SSA’s fiscal calendar; and
      Identify variances to the baseline.

Additionally, the Contractor must produce labor reports sorted by SSA’s Office of Systems
Resource Accounting System (RAS) codes. RAS codes are comprised of up to eight
alphanumeric digits that identify SSA’s projects. SSA Task Order managers will provide these
codes. However, the Contractor shall be required to ensure that all Task Orders have the
appropriate RAS codes associated with them. Additionally, SSA performs Earned Value
Management (EVM) on all major IT programs, which, as a result, makes EVM a contract
requirement.

The Contractor’s response to this section shall describe the process for implementing RAS
reporting.

The Contractor’s response to this section shall describe the process for implementing monthly
EVM reporting.

The Contractor’s response to this section shall also describe cost control and verification
processes and systems to be implemented on this contract.

Finally, the Contractor should describe cost savings initiatives and results anticipated during the
life of the program, and cite examples achieved on similar contracts in the past.

B.13(a)(5) – Quality Assurance/Quality Control Section

The Contractor shall ensure technical quality for all deliverables and work products in
accordance with PRIDE, the Task Order Ordering Procedures, and SSA’s other approved
standards and guidelines for quality assurance/quality control (QA/QC).

Controlling the quality of Contractor produced products is considered to be part of the ongoing
responsibility of Key personnel. A separate QA/QC staffing effort in addition to the staffing
requirements of this solicitation/contract and/or charged to the contract in a direct cost capacity
will not be permitted.


                                                 63
In this section of the Project Management Plan, the Contractor shall state how quality will be
built into its products through Contractor planning and management as part of ongoing QA/QC
procedures. The Contractor shall discuss management techniques and controls to be employed
for technical and management reviews and audits to ensure quality of work and adherence to
standards by its personnel and subcontractors. Proposed procedures, at a minimum, shall be
designed to:

      Concentrate on quality for each Task Order and product produced;
      Avoid, detect, and eliminate defects in all products;
      Reduce the risk of system integration failure;
      Ensure that products produced are in compliance with requirements;
      Conform to PRIDE and other approved guidelines/standards and procedures for QA/QC
       including the use of tools; and
      Ensure quality software engineering policies, procedures, and techniques.

SSA reserves the right to implement procedures to monitor the Contractor’s Software Quality
Assurance activities.

B.13(a)(6) – Training Section

The Training Section shall include a description of the Contractor’s plan to ensure continuity of
skilled personnel to support the variety of software support experience, skills and knowledge
outlined in Section E.1 – Personnel Qualifications, and Section B.11 – Contractor
Competencies/Experience Requirements, of this solicitation/contract.

At a minimum, the Contractor’s training plan shall include proposed procedures for:

      Certification, assignment, and orientation of qualified personnel to support Task Orders;
      Providing for continuity of the software engineering support skills outlined in Section
       B.11 – Competencies/Experience Requirements;
      Ongoing cross-training efforts and updating of skills across the nine (9) technical areas;
      Realistic utilization of personnel (i.e., training vs. ongoing operations);
      Realistic resource estimation for the type of training courses, cost of training and time
       required for training contingent upon works issued; and
      Ensuring that personnel remain qualified in their specialty area.

B.13(b) – Project Facilities and Support Requirements

A very small amount (up to approximately 30 workyears per year) of the contract's total effort
may be performed on-site at SSA-designated government facilities. For these on-site services,
the Government will furnish and fund all needed resources for on-site contractor personnel. The
resources include Government-furnished space, telephones, and property and equipment,
including hardware and software, technical materials, and office supplies. All Government space,
materials, and facilities to be used by or provided to the contractor will be employed according to



                                                64
current Government regulations. Consequently, they will be required to comply with the
appropriate Agency policies and procedures.

For all other services, the Contractor shall provide all necessary resources such as: office space,
supervisory and managerial staff, clerical support, equipment, furnishings, software manuals,
automated tools and computer systems, (except as otherwise noted in Section C.6
Government-Furnished Computer Processing Support or elsewhere) to accomplish all work
assigned under this contract. (Note: See Section C.2(b) Place of Performance regarding onsite
support.)

It is not SSA’s intent to establish office space for the Contractor at SSA headquarters facilities.
With respect to facilities, the contractor will be required to either possess, or cause to be
established, a Program Management Office (PMO) nearby SSA headquarters, 6401 Security
Boulevard, Baltimore, Maryland, 21235. This office shall be capable of providing day-to-day
contractor/subcontractor staff interaction with SSA staff, including meetings and review of the
Contractor’s products. Given the volume and level of day-to-day interaction between SSA’s
management and contractor management which will occur under the proposed contract, SSA
considers it to be more efficient and cost-effective when contractor’s management is located
close enough to SSA headquarters to facilitate frequent site visits. This office shall provide for
the day-to-day project needs of the Contractor’s staff to interact with SSA personnel.

The Contractor shall ensure that automated resources, procedures, and communications will be
used, wherever practical, to maintain the most cost-efficient and cost-effective use of
Government funds. In response to that objective, SSA require that reports be maintained and
delivered using electronic means, where appropriate. The equipment or microcomputers shall be
capable of producing high quality “camera-ready” copies of deliverables. Also, hardware and
software resources shall be capable of producing high quality graphics for use in the contract
deliverables, if necessary.

SSA reserves the right to conduct periodic audits of the Contractor’s facility for this contract in
order to survey and inventory furnishings, tools, equipment, etc., as well as to assess the status of
deliverables and project performance. The Contractor shall provide a current inventory list of
items to be surveyed to the COTR one week prior to the performance of an inventory audit.

All authorized costs in support of this requirement will be reimbursed as ODC expenses.

B.13(c) – Automated Support Specifications/Data Communications

B.13(c)(1) – Background

The Contractor shall use the ESEF and MISF mainframe (and possibly other) facilities,
intelligent workstations (IWS) and local area networks (LAN) to perform work. The
Contractor’s IWS/LAN shall be used to access the ESEF and MISF. Access to the ESEF and
MISF will be via a router from the Contractor’s IWS/LAN to SSA’s core network.




                                                 65
Equipment requirements for the Contractor’s IWS/LAN are described in Section B.10(d)
Automated Support Specifications/Local Area Network and Section B.10(e) Automated
Support Specifications/Intelligent Workstations. All installations are to be done according to
SSA’s directions. SSA will provide instructions and parameters to the successful offeror.

All authorized costs in support of this requirement will be reimbursed as ODC expenses.

B.13(c)(2) – Contractor Responsibilities/Data Communications

The Contractor shall be responsible for:

       Providing power and facility support for the installation of a router SSA provides at its
        off site facility to connect to SSA’s data communications circuit. SSA will provide the
        circuit as well.
       Following all of SSA’s network and security conventions, procedures and standards. The
        Contractor shall be provided with copies of all applicable procedures and standards
        within 7 workdays after contract award.
       Ensuring the security and reliable operation of all of the Contractor’s equipment at the
        Contractor’s facility, i.e., including LAN administration. SSA will assist the Contractor’s
        technical personnel in resolving equipment problems, as necessary.
       Providing a standalone facsimile service, including a dedicated telephone line, which
        must be compatible with SSA’s equipment.

B.13(c)(3) – Government Responsibilities/Data Communications

SSA will be responsible for providing, installing, and maintaining (with the Contractor’s
assistance):

       The routers (hardware and software) to connect the circuit to the Contractor’s LAN at the
        Contractor’s facility to SSA’s wide area network; and
       Network management services and access control.

B.13(c)(4) – Compatibility Specifications/Data Communications

   1.   SNA Emulator Software: IBM Personal Communications (SNA PU Type 2.0 and 2.1)
   2.   Data Link: SNA SDLC/LLC (802.2); Ethernet (802.3)
   3.   Transmission Mode: Full Duplex
   4.   Communications Segment: MPLS and DLSw or Enterprise Extender (HRP/IP)
   5.   Transmission Code: EBCDIC/ASCII
   6.   Host Processor Software: ACF/VTAM, z/Series
   7.   Data Stream: 3270 Extended Data Stream; 5250; APPC/LU6.2

B.13(d) – Automated Support Specifications/Local Area Network

B.13(d)(1) – Background



                                                66
SSA’s target platform includes the hardware, software and communication facilities to provide a
standard local environment for cooperative processing.

B.13(d)(2) – Contractor Responsibilities/Local Area Network

The Contractor shall be responsible for all of its own equipment. The Contractor shall construct
a local area network (LAN) connecting the workstations used for this contract. This LAN and
the workstations attached to it shall serve as the administrative and software development
platform for work performed under this contract. The LAN shall be functionally equivalent to
SSA’s LANs and have some additional services such as an Outlook post office and a database
server.

The Contractor is required to have installed at the Contractor’s worksite a LAN that is
functionally equivalent to SSA’s LANs. The LAN shall employ Ethernet transport (IEEE 802.3)
at 100 MBPS and using Category 5e or 6cabling. The LAN shall employ Cisco Ethernet
switches and may support 1000 MBPS connections as well.

The LAN shall include a router to the Agency’s SSANet wide area network leading to
connections with SSA’s mainframe computer resources in the National Computer Center (NCC).
The router shall be as described in Section B.13(c) - Automated Support Specifications/Data
Communications.

The LAN shall have two (2) Intel Pentium III or Xeon-based file servers with a minimum of 5-
73 Gb SCSI based hard disks, 2 Gb of RAM, a video display, keyboard, floppy disk drive,
minimum of a 24x CD ROM drive and a DDS4 tape backup service. The network operating
system shall be the latest version (through the life of the contract) of Microsoft Windows 2000
server for Intel-based computers.

This LAN shall also include local and mainframe print services. The local print service uses a
Lexmark printer with a minimum of 20 MB of RAM and an Ethernet card for direct connection
to the LAN. There shall be one local printer for every eight intelligent workstations. The
mainframe print service, known as the secure printer, shall also be a LAN Laser Printer.

The database server shall consist of an Intel Pentium III or Xeon-based file servers with a
minimum of 5-73 Gb SCSI based hard disks, 2 Gb of RAM, a video display, keyboard, floppy
disk drive, minimum of a 24x CD ROM drive and a DDS4 tape backup service. The network
operating system shall be the latest version (through the life of the contract) of Microsoft
Windows 2000 server for Intel-based computers. It shall be capable of running database server
products such as Microsoft’s SQL Server, Oracle’s database server software, and IBM’s OS/2
Database Manager. The database server shall be configured with SQLServer for the database
software.

Additional LAN enhancements or specific software tools may be required at a later date.

The Contractor shall acquire all hardware and software listed above under the ODC line item b. -
Computing Platform, found in Section A.1 – Description and Scope of Work. All hardware and



                                               67
software shall be installed and operational in the Contractor’s office within 90 calendar days
after contract award.

B.13(e) – Automated Support Specifications/Intelligent Workstations

B.13(e)(1) – Background

SSA’s workstation standard includes a variety of hardware and software facilities to provide a
standard local workstation environment for cooperative processing.

B.13(e)(2) – Contractor Responsibilities/Intelligent Workstations

The Contractor is required to have installed at the Contractor’s worksite sufficient workstations
to accommodate contractor personnel located at the offsite facility. The workstations, including
the network interface cards (NICs), shall be of a similar configuration (software and hardware)
as SSA’s workstations.

The workstations shall meet the following minimum specification: Intel Core 2 Duo E8400
processor, 2GB of RAM (expandable to 4GB), 160GB hard drive, bootable CD/DVD-DL/R-W-
RW combo drive, NVIDIA NVS 290 graphics adapter, integrated 10/100/1000 Ethernet network
interface, standard 104-key keyboard with integrated smart card reader, 2-button (minimum)
mouse with scroll wheel, minimum of six USB 2.0-compliant ports, one 9-pin serial port, and
one 25-pin parallel port. After the workstation is fully configured, there must be a minimum of
one 3.5” internal drive bay, one 5.25” external drive bay, and two full height PCI slots available
for future expansion.

Each workstation shall be configured with SSA standard workstation software. This software
could include, and is not limited to:

Windows XP/Vista, Microsoft Office 2003/2007, eTrust Threat Manager 8.1, PCOMM,
Microsoft Project, Outlook 2003/2007 or later versions as deployed.

Each workstation shall also have the appropriate network software to allow access to SSA’s
mainframe computers in the NCC, which is PCOMM. In addition, the Contractor shall have
available at the Contractor’s worksite and workstations the following software for work
performed under this contract:

      PCOMM
      IT Excelerator, 1 copy
      Microsoft Project, 1 LAN version
      Bachmann, 1 copy

The software shall be the Windows version where available and shall be the same software
release levels SSA designates at the time of contract award for compatibility purposes.
Additional workstation enhancements or specific software tools may be required at a later date.




                                                68
The Contractor shall acquire all hardware and software listed above under the ODC line item b. -
Computing Platform, found in Section A.1 – Description and Scope of Work. All hardware and
software shall be installed and operational in the Contractor’s office within 90 calendar days
after contract award.

B.13(f) – Contract Performance Reviews

SSA will compile current information relevant to contractor performance on a monthly basis for
any active Task Order. The performance reviews shall be based on work products and/or
deliverables produced during the month. SSA will use these performance reviews as evaluation
criteria for awards of future contracts. Interim reviews will be prepared on the Contractor’s
performance to coincide with exercising an option or at other intervals consistent with the
contract effort. Such interim reviews shall be prepared at least once every 12 months, but may
be prepared more frequently, if appropriate. The interim reports will be provided to the
Contractor as soon as practicable after completion of SSA’s performance reviews. The
Contractor then has a minimum of 30 calendar days in which to submit comments, rebutting
statements, or additional information.

A final report of Contractor Performance addressing/covering the entire systems/contract life
(e.g., ALL contract years, including the final/last contract year) will be prepared at the time the
work under the contract is completed. The Contractor will be allowed to submit any pertinent
comments, rebutting statements, and/or additional information within 30 calendar days of
acknowledged receipt thereof.

B.13(g) – Reporting Requirements and Acceptance of Deliverables

B.13(g)(1) – Reporting Requirements

The following is a summarization of reporting requirements that will be used upon contract
award.

Monthly Electronic Technical Progress Reports (eTPR) by Task Order – required for each Task
Order assigned/active during the reporting period. This collection of reports will be due on or
before the fifteenth (15th) calendar day of each month for each Task Order. (Reference Section
C.1(c)(1) of this solicitation/contract).

Monthly Contract Summary Report/Invoice - due to the COTR by the fifteenth (15th) calendar
day of the month. This collection of reports provides a detailed breakdown of contract resource
expenditures as well as a workload summarization. (Reference Section C.1(c)(2) of this
solicitation/contract).

Monthly Financial Planning Report - due to the COTR by the thirtieth (30th) calendar day of the
month. This collection of reports provides financial planning information for a contract period
specified by the COTR. (Reference Section C.1(c)(3) of this solicitation/contract).

Weekly Task Order Status Report (Reference Section C.1(c)(4) of this solicitation/contract).



                                                 69
Weekly COTR Progress Review Meeting (Reference Section C.1(c)(5) of this
solicitation/contract).

Weekly Task Order Manager Communication (Reference Section C.1(c)(6) of this
solicitation/contract).

Other Formal Meetings (Reference Section C.1(c)(7) of this solicitation/contract).

Ad-Hoc Reports (Reference Section C.1(c)(8) of this solicitation/contract).

Monthly RAS Reports (Reference Section C.1(c)(9) of this solicitation/contract).

Monthly EVM Reports (Reference Section C.1(c)(10) of this solicitation/contract).

Subcontracting Report for Individual Contracts - (Reference Section E.8 of this
solicitation/contract).

Summary Subcontract Report - (Reference Section E.8 of this solicitation/contract).

Socio-Economic Report – (Reference Section E.8 of this solicitation/contract).

NOTE: Reports will be deliverables under the Contract Management Task Order.

B.13(g)(2) – Acceptance of Formal Deliverables

Formal deliverables are products delivered by the Contractor for acceptance by the COTR. A
Task Order will specify the deliverables and completion dates for the deliverables.

Deliverables may be written products or software products, delivered either in hard copy or
electronic format. If the deliverable is in electronic format, it must meet all of the requirements
of Section 508 and SSA’s accessibility standards. Written products include, for example:
technical reports, design stage documentation (e.g., system external specifications, and system
internal specifications). For Task Orders where the Contractor is performing other types of
services (e.g., ESEF technical assistance, attending meetings, briefings), the deliverable is a
written product that documents the services that have been performed by the Contractor.

Software products include, for example: source code, job control language, and executable
programs. Data products include, for example, work files, Microsoft Word files, and
configuration data.

Products shall be delivered for acceptance in two stages, unless otherwise specified. The
Contractor shall deliver draft products to the COTR or the designated representative for technical
evaluation that is coordinated by SSA’s Task Order Manager(s).




                                                 70
SSA will review the draft within the specific Task Order deliverable timeframe. SSA will
determine whether the deliverable conforms to the technical acceptance requirements (content
and format) identified in the work description. The COTR and/or Task Order Manager will
notify the Contractor of the sections in the draft that must be reworked in the final deliverable.
The Contractor shall have a required number of calendar days to incorporate the requested
changes into the final deliverable following receipt of these changes.

Final formal deliverable products shall be delivered to the COTR or a designated representative.
SSA will review the deliverable and if the product does not meet final acceptance standards due
to a lack of conformance with the technical requirements identified in the Task Order description,
the COTR will return the deliverable as unacceptable. SSA reserves the right to request the
Contractor to rework the deliverable or to cease further work; whichever SSA deems to be more
advantageous/in its best interests.

If the deliverable is a written product, the number of written copies required for each deliverable
(draft and final) shall be a minimum of two (2). More may be specified in the Task Order. In
addition, one electronic copy using the most current version of Microsoft Word is required for
each final product after SSA has approved and accepted it. The Contractor shall use the software
release levels SSA designates at the time of contract award unless specified differently in a
specific Task Order.

Documents delivered in spreadsheet form shall be provided in the most current version of
Microsoft EXCEL unless specified differently in a specific Task Order.

Documents delivered requiring graphics shall be provided in the most current version of
Microsoft PowerPoint unless specified differently in a specific Task Order.

Deliverables may also be required to be transmitted by Outlook and/or FAX.

If after award SSA upgrades to a new software release, the Contractor shall be required to use
SSA specified software version/release level of each software package thereafter unless
notification is specified differently in a Task Order.

All electronic media (diskette, CDs, etc.) presented to SSA shall be accompanied by written
certification from the Contractor’s Security officer that the media are virus free.

If the deliverable is a software product, the Contractor shall submit to the SSA Task Order
Manager a form stating that the product has been completed and is ready for evaluation. The
form shall include information regarding the location and identification of software modules
being tested, Customer Information Control System (CICS) files, etc. The SSA Task Order
Manager and Contractor Task Order Manager shall establish acceptance criteria and procedures
for each deliverable required as part of a Task Order. An action plan for correcting unacceptable
deliverables shall be established.

Software (source code, JCL, etc.) and data (test, master files, etc.) products shall be delivered
and evaluated according to the technical specifications provided in the particular Task Order.



                                                 71
Such technical specifications shall include, but not be limited to, source code language, data
descriptions/format, levels of testing, structured methodology requirements, location of
development, testing and evaluation, etc. In addition, adherence to SSA standards, ESEF/MISF
requirements and use of SSA’s tools and technical capabilities, shall also be part of the
acceptance criteria. When specifically addressed in a Task Order, the Contractor shall be
required to provide, install, and demonstrate successful installation of certain deliverables on
SSA’s specified IWS/LAN. For example, if the use of an XML tool “XYZ” was specified in a
Task Order, the Contractor may be required to transfer the “XYZ” XML files to a workstation
specified by SSA and successfully demonstrate the use of this file with the “XYZ” on SSA’s
machine. The media for this data transfer shall be specified in the Task Order.

The SSA Task Order Manager shall have access to all software products stored on the
Contractor’s IWS/LAN and SSA’s ESEF/MISF throughout the period of performance of any
Task Order in order that ongoing progress may be evaluated. If software/data products are
developed at a Contractor site (using equipment other than the Contractor’s IWS/LAN or SSA’s
ESEF/MISF), SSA must have access to that software/data during the development period.
Transfer of software/data products to the ESEF/MISF or to SSA’s designated IWS/LAN shall be
accomplished at the time designated by, and following requirements/restrictions defined in, the
individual Task Order(s).

When software/data products are completed and ready for final acceptance, access to these
products shall be restricted to SSA’s designated individuals until the formal acceptance has been
completed. If the product is unacceptable, the Contractor shall have the number of days
specified in the Task Order to incorporate the required changes.

If the software/data products are still unacceptable after a second formal acceptance, SSA
reserves the right to request the Contractor to rework the deliverable or to cease further work,
whichever is deemed by SSA to be more advantageous/in its best interests.

The Contractor shall ensure the protection of computer storage materials, software, and data that
are intended for use with SSA’s computers against acts of vandalism, including personal
computer viruses.

B.13(g)(3) – Work Status Reports

A Task Order may include one or more Work Status Reports to be used as checkpoints or
milestones to help the SSA Task Order Managers to determine status, progress or adherence to
the scope of effort. Such Work Status Reports shall be delivered to the SSA Task Order
Manager and will not be accepted or rejected as formal deliverables. Work Status Reports may
include written drafts, oral reports, meetings, informal walkthroughs, source code, preliminary
JCL, test data, preliminary test results and so forth. Work Status Reports will be identified in the
Task Order.

SECTION B.14 – SECTION 508 OF THE REHABILITATION ACT




                                                 72
Requirements for accessibility based on Section 508 of the Rehabilitation Act of 1973 (29 U.S.C.
794d) and additional agency specific accessibility requirements, hereafter referred in total as
“SSA’s Accessibility Requirements”, are determined to be relevant for this solicitation. Please
reference Attachment 1 for a specific listing of all applicable SSA Accessibility Requirements
for this solicitation.

SECTION B.15 – IPV6 REQUIREMENTS

IPv6 capability is a technical requirement for procurements of relevant network devices, system
hardware and software, applications, operating systems, etc.

An IPv6 capable product or system must be able to receive, process, and transmit or forward (as
appropriate) IPv6 packets and should interoperate with other systems and protocols in both IPv4
and IPv6 modes of operation.
Specifically, any new IP product or system developed, acquired, or produced must:
    Interoperate with both IPv6 and IPv4 systems and products;
    If not initially capable, provide a migration path and commitment to upgrade to IPv6 for all
     application and product features by June 2008; and
    Have available IPv6 technical support for development, implementation, and management
     of deployed products, components or systems.




                                               73

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:1/6/2012
language:
pages:73
jianghongl jianghongl http://
About