The document discusses Section 508 compliance and how it can be integrated into a systems engineering life cycle (SELC). It proposes including a Section 508 EIT Accessibility Plan to guide project managers through ensuring compliance at each stage of development. The plan would include templates for documenting applicable standards, exceptions, market research of compliant products, and inclusion of compliance activities in requirements, design, testing and implementation stages. Including accessibility from the beginning is more cost effective than retrofitting later.
International Journal of Engineering Research and DevelopmentIJERD Editor
• Electrical, Electronics and Computer Engineering,
• Information Engineering and Technology,
• Mechanical, Industrial and Manufacturing Engineering,
• Automation and Mechatronics Engineering,
• Material and Chemical Engineering,
• Civil and Architecture Engineering,
• Biotechnology and Bio Engineering,
• Environmental Engineering,
• Petroleum and Mining Engineering,
• Marine and Agriculture engineering,
• Aerospace Engineering.
International Journal of Engineering Research and DevelopmentIJERD Editor
• Electrical, Electronics and Computer Engineering,
• Information Engineering and Technology,
• Mechanical, Industrial and Manufacturing Engineering,
• Automation and Mechatronics Engineering,
• Material and Chemical Engineering,
• Civil and Architecture Engineering,
• Biotechnology and Bio Engineering,
• Environmental Engineering,
• Petroleum and Mining Engineering,
• Marine and Agriculture engineering,
• Aerospace Engineering.
Question Bank (Short answer type) covering Traditional and Object-Oriented Software Development, User Interface Design, Coding, Testing, Metrics, Estimation, Management and Quality based on book by Jibitesh & Mohanty, Pressman, SWEBOK
Learn why Solution Design is critical and what are components of a Solution Architecture. Boston Technology Corporation (BTC) has expertise in Strategic Consulting and Solution Design Services. Visit our website to see some of our work at http://www.boston-technology.com/
A Proven Migration Method for Cognos PlanningAnthony D'Ugo
Cognos Forum, User Conference Presentation
Session attendees learned how a sound application change control process for migrating Cognos Planning between servers from planning, to testing, and finally production environments can benefit their deployment. Benefits of this best practice approach included reduced disruption to their business processes, improved service levels, and a lower risk of production errors down the road. Attendees also gained an understanding of the important differences between a first time migration at the beginning of the budgeting cycle and changes to an existing production environment.
Question Bank (Short answer type) covering Traditional and Object-Oriented Software Development, User Interface Design, Coding, Testing, Metrics, Estimation, Management and Quality based on book by Jibitesh & Mohanty, Pressman, SWEBOK
Learn why Solution Design is critical and what are components of a Solution Architecture. Boston Technology Corporation (BTC) has expertise in Strategic Consulting and Solution Design Services. Visit our website to see some of our work at http://www.boston-technology.com/
A Proven Migration Method for Cognos PlanningAnthony D'Ugo
Cognos Forum, User Conference Presentation
Session attendees learned how a sound application change control process for migrating Cognos Planning between servers from planning, to testing, and finally production environments can benefit their deployment. Benefits of this best practice approach included reduced disruption to their business processes, improved service levels, and a lower risk of production errors down the road. Attendees also gained an understanding of the important differences between a first time migration at the beginning of the budgeting cycle and changes to an existing production environment.
IFSM 301 – Week 4 Citations (NIST, 2009) (The six phasMalikPinckney86
IFSM 301 – Week 4 Citations
(NIST, 2009)
(The six phases of project management, n.d.)
(Waterfall versus Agile Project Management, n.d.)
(Gottesdiener, 2008)
(Value Attainment)
(Potts, 2008)
(Potts, Why You Shouldn't Have an IT Budget, 2008)
(UMUC Faculty)
Bibliography
Gottesdiener, E. (2008, March). Good Practices for Developing User Requirements. The Journal
of Defense Software Engineering, 13-17. Retrieved January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543074/View
NIST. (2009, April). The System Development Life Cycle. Retrieved January 25, 2021, from
NIST: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543036/View
Potts, C. (2008, November 15). It's Time to Change Your Investment Culture. CIO, 24-26.
Retrieved January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543105/View
Potts, C. (2008, May 15). Why You Shouldn't Have an IT Budget. CIO, 74-76. Retrieved
January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543106/View
The six phases of project management. (n.d.). Retrieved January 25, 2021, from University of
Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543072/View
UMUC Faculty. (n.d.). Performance Measures. Retrieved January 25, 2021, from University of
Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543077/View
Value Attainment. (n.d.). Retrieved January 25, 2021, from University of Maryland Global
Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543075/View
Waterfall versus Agile Project Management. (n.d.). Retrieved January 25, 2021, from University
of Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543073/View
The System Development Life Cycle
For a brief overview of the System Development Life Cycle, the following sections have been directly
quoted from the National Institute of Standards and Technology (NIST) publication, The System
Development Life Cycle (SDLC). The entire NIST publication is available at:
http://csrc.nist.gov/publications/nistbul/april2009_system-development-life-cycle.pdf
"The system development life cycle is the overall process of developing, implementing, and retiring
information systems through a multistep process from initiation, analysis, design, implementation, and
maintenance to disposal. There are many different SDLC models and methodologies, but each generally
consists of a series of defined steps or phases.
The System Development Life Cycle
Initiation Phase. During the initiation phase, the organization establishes the need for a system and
documents its purpose.
Development/Acquisition Phase. During this phase, the system is designed, purchased, programmed,
developed, or otherwise constructed. should be identified as well.
Implementation Phase. In the implementation phase, the organization conf ...
This is the first webcast in a four-part series in which we discuss the concepts of demand management in Microsoft Project Server 2010. In this webcast, we highlight the new Demand Management feature in Project Server 2010. Topics we cover include how demand management in Project Server 2010:
•Offers positive business impacts for multiple departments.
•Enhances strategic visibility into portfolios, programs, and projects across the enterprise.
•Benefits governance control processes by allowing for multiple lifecycle styles, creation of a central repository for project/program documents and data, and more streamlined capabilities for collecting project data.
Depending on the size and complexity of the system, every project can be tailored to fit a life cycle approach. Requirement: Same as Security, Privacy or any other requirement.
The Department of Homeland Security’s (DHS) Office of Accessible Systems & Technology (OAST) approach specified the Section 508 requirements used in the DHS Systems Engineering Life Cycle (SELC) ##Do we need a DHS SELC Reference link here?
Plan that will help them meet the legal requirements while avoiding delays or higher costs Pull up your electronic copy or pull out your paper copy of the Section 508 EIT Accessibility Plan. This plan includes all Section 508 artifacts required by the DHS Systems Engineering Life Cycle (SELC)
The primary focus of this presentation is describing this plan and how it helps DHS meet the Section 508 requirements and promote accessibility The plan and life cycle artifacts are used in project planning, requirements, and design to ensure accessibility The plan and artifacts developed easily map to any generic life cycle They are included in the appendices for your reference Meets DHS SELC requirements Lists the information and documentation that must be submitted in order to comply with Section 508 for each phase in a project’s EIT Life Cycle Shows points of contact (POC) to allow assignment of responsibility to specific individuals, as needed A separate plan and set of artifacts may be needed for each individual EIT project or distinct technology
The Section 508 Electronic Information & Technology (EIT) Accessibility Plan was created to summarize and track accessibility throughout a project’s development life cycle. The Section 508 EIT Accessibility Plan lists the Section 508 artifacts needed within each project stage and includes guidance in the form of steps taken in Section 508 compliant life-cycle planning. Reading the plan, the project manager sees exactly in what stage which Section 508 task must be completed and adjusts his project plan accordingly. Spaces for artifact points of contact are included because project managers often delegate tasks, and some large programs have multiple project managers. The points of contact are also used by the Section 508 reviewer if there are questions about the artifact. OAST staffs the DHS Accessibility Help Desk and its phone number and email are included at the bottom of each plan page so that a project manager can quickly reach a contact to get his specific questions answered.
Note that the plan is broken down in to phases that aligns by life cycle – specifically the DHS SELC Stage 1: Solution Engineering & Planning Stage 2 Requirements Definition Stage 3 Design & Development Stage 4 Integration & Test Stage 5 Implementation & Operations We’re going to start right in at the beginning or the initial plan
Clear Early Exception: National Security Because of the nature of DHS business, National Security Exceptions are granted occasionally. OAST recommends that a project manager first determine if there is a National Security Exception before working through the other steps. The Section 508 EIT Accessibility Plan links to the National Security Exception Request and Authorization Form. This form states the criteria for a National Security Exception. At DHS, this exception must be authorized by the OAST Director who reports directly to the DHS Chief Information Officer (CIO). If the exception is authorized, the Section 508 legal requirements are met for the project.
Stage 1: Solution Engineering & Planning At this stage in a project’s life-cycle, planning has just begun. Should the system be designated for work involving National Security, request a National Security Exception at the beginning of the project. – OR –
Identify the applicable Section 508 Technical Standards and any other Section 508 Exceptions that might apply. Show market research indicating that in the analysis of alternative products that meet your business needs, you selected the most compliant product available. If analysis is ongoing, please indicate that with your submission and be prepared to provide the necessary information in the next life-cycle stage. Section 508 EIT Accessibility Plan (This document) Projects Planned Implementation (Deployment) Date: Applicable Standards Worksheets ; identify the applicable Section 508 Technical Standards Point of Contact: Email: Section 508 Exceptions Worksheet; identify any exceptions to Section 508 compliance For Pilots - DHS Form 4106: Most Compliant Product Market Research Form ; Alternative Analysis
Before you can get to identifying the technical standards that apply to whatever EIT you select, buy, build, or use, there is a need to figure out what technologies will be used. Very rarely will a large complex project only have one technology or know for certain that any one product will meet all the stakeholder’s business needs. So in our plan, don’t forget the most important thing isn’t necessarily listed on our Section 508 EIT Accessibility Plan – that is the business need. If we have no need for something, why would we buy it? If we need to solve a problem but there is no commercial product that does what we need, we might have to build it. If we think a product meets our needs, but we don’t really know and want to try it out first, we might need to test or have a pilot test at a few of our business sites. That business need is required by the DHS SELC and is documented in other project artifacts. That business need also affects Section 508 compliance. When stating a product is the most compliant product available – but doesn’t meet all the technical provisions – we need to clearly document our market research, and narrowing down what products can be considered is based on having clear business needs.
So lets go back to looking at what we can address during early planning. If we do know what technologies we want to use, we can determine what standards apply, if any exceptions apply, or if we know we have to choose between a few technologies that meet all meet our business need, we can determine which one is most accessible. ##for the sake of our 1 hour presentation we will briefly mention the purpose of the forms but we won’t be going into detail of the actual forms during the presentation, but they are listed in the appendix and included in the presentation packages.
Section 508 has specific technical standards and requirements for those standards. We are providing this to them early in the project life cycle. Our worksheet helps the project managers determine what standards apply, giving them a template they can use for each separate IT product – commercial or custom developed – and also reminds them to include the appropriate section 508 details in the generic project artifacts. Those include the project technical requirements, requirements traceability matrix, and any test plans. It is important they get these as early as possible to give them more time to figure out how to use these plans as they get more specifics and solidify their project’s plans. Because they are in planning, they might not yet know what technologies will be used.
Project managers are always looking for ways to save time and eliminate anything that isn’t a requirement. That includes looking for any exception. We shouldn’t look at that as being a negative thing. They are responsible for using the resources they have in the most efficient manner. If you don’t have to build in a requirement, it helps you spend time on other priorities. As Section 508 coordinators, it is often easier to not mention the exceptions, because we don’t know them or think that technical compliance is most important. The Section 508 Exceptions Worksheet helps guide that conversation. We want to support project managers when they have legitimate exceptions. They are in the law for a reason. One of the most useful tools is to give them all the information they need to make a decision. The Section 508 exceptions worksheets clearly describes the key questions to consider and then direct them to use the proper form and obtain the proper signatures from the proper authorities. It helps them be informed, and helps clearly document Section 508 compliance.
Now that planning and requirements definition are nearly done, the project is ready to commit to specific technologies and determine which will be developed and which will be procured. Market research is an important step before committing to an acquisition. If EIT is being procured, market research and analysis of alternative technologies is as important to Section 508 compliance as it is to the other project goals. The Most Compliant Product Market Research Form documents selection of the most compliant product that meets the business needs. It assists the project manager in alternatives documentation. For each distinct EIT procurement planned, the project manager lists the alternatives that best meet their business needs. In the table, the project manager should list the key requirements for that procurement and mark the requirements each product meets. For the products that meet the business needs, Section 508 compliance information is obtained. The compliance level of each product is ranked and the most compliant product that meets the business needs is chosen.
We’ve done a lot of describing and preparation for documentation or artifacts to be used for the project up until now. That takes a lot of time. Now that we are in requirements definition we are going to have more specifics, more certainty on the who, what, and how of the project and we are going to document our requirements. Key to this is to simply update the Section 508 EIT Accessibility Plan. Project managers should use this as a “living document” and not just a one-time throw-away checklist Request any Section 508 Exceptions, using Section 508 Request and Authorization Forms Applicable Standards Worksheets ; identify the applicable Section 508 Technical Standards Project’s Functional Requirements Documents include Section 508 Functional Performance Criteria Project’s Technical Requirements Documents include applicable Section 508 Technical Standards, documented in the Applicable Standards Worksheets . Requirements Traceability Matrix includes applicable Section 508 Functional Performance Criteria and Section 508 Technical Standards DHS Form 4106: Most Compliant Product Market Research Form
NOTE: All developed or customized EIT must be fully Section 508 compliant. Updated Section 508 EIT Accessibility Plan Finalize any Section 508 Exceptions, using Section 508 Request and Authorization Forms In the System Acceptance Test Plans documentation, show how Section 508 requirements will be tested. Systems Test Reports include: ##to include in detail or not? Section 508 User Training and Manuals Test Report Section 508 testing results including Impact Report Section 508 Interoperability Test Report Section 508 Remediation Plan (if Section 508 defects are found)
Section 508 has specific technical standards and requirements for those standards. Include accessibility into development life cycle each release Software developers are not the project managers – they may need help in interpreting the requirements – but the project manager does not need to know the technical standards to be able to manage Section 508 technical requirements; in that way they are the same as any other requirement.
Section 508 has specific technical standards and requirements for those standards. We are providing this to them early in the project life cycle. Our worksheet helps the project managers determine what standards apply, giving them a template they can use for each separate IT product – commercial or custom developed – and also reminds them to include the appropriate section 508 details in the generic project artifacts. Those include the project technical requirements, requirements traceability matrix, and any test plans. It is important they get these as early as possible to give them more time to figure out how to use these plans as they get more specifics and solidify their project’s plans. Because they are in planning, they might not yet know what technologies will be used.
The list of known issues should be prioritized and used during ongoing development, evaluation , and testing before each release. For commercial off-the-shelf (COTS) products, use this plan to track defects with the specific product version. Verify the vendor has been notified of the defects, and you have requested them to be fixed. Proactively solving compliance issues with vendors means that they are aware of the issues and actively participating in planning any fixes. For Programs that have multiple projects or project with multiple EIT systems or items, a separate plan may be needed for each individual EIT project or distinct technology. Plan should outline steps to be taken to fix the problem, including reporting any product deficiencies to EIT vendor and establish expectations and dates for bringing EIT into compliance.
Transition to Support includes specific configuration or deployment activities for Assistive Technology (AT) interoperability, if any is required.
The objective of the upcoming implementation and operations stage to prepare the system, operational environment, organization, and users for the intended use of the new solution. The Transition to Support Documentation must include any needed configuration settings that an assistive technology user or the systems administrator must make in order to use the software effectively. This is primarily to ensure that the solution’s help desk is aware of the extra configuration required While OAST promotes a standards-based approach and discourages customization to satisfy specific assistive technology issues, doing so is not against Section 508 law as long as the standards are met
Update Accessibility Plan Section 508 Remediation Plan if defects are found during operation Report accessibility issues to Accessibility Help Desk Document accessibility problems reported during operations In coordination with OAST or your component Section 508 Coordinator, develop a remediation plan with agreed upon timelines for bringing the EIT into compliance. Part of supportability and sustainment planning is to have a plan to report and resolve issues that arise during operations. This document is needed to remind the project manager that Section 508 compliance must be maintained especially if the product is modified. OAST is available to assist in troubleshooting to decide if the problem is user training, assistive technology shortcomings or an issue with the Section 508 compliance of the EIT
The list of known issues should be prioritized and used during ongoing development, evaluation , and testing before each release. For commercial off-the-shelf (COTS) products, use this plan to track defects with the specific product version. Verify the vendor has been notified of the defects, and you have requested them to be fixed. Proactively solving compliance issues with vendors means that they are aware of the issues and actively participating in planning any fixes. For Programs that have multiple projects or project with multiple EIT systems or items, a separate plan may be needed for each individual EIT project or distinct technology. Plan should outline steps to be taken to fix the problem, including reporting any product deficiencies to EIT vendor and establish expectations and dates for bringing EIT into compliance.