Post on 10-Mar-2018
Information Technology Policy Software Development Life Cycle (SDLC) Policy
ITP Number ITP-SFT000
Effective Date February 17, 2017
Category Software
Supersedes None
Contact RA-ITCentral@pa.gov
Scheduled Review September 2018
1. Purpose Managing information systems to support business and technical operations requires an organization to have a well-defined Systems Development Life Cycle (SDLC) framework. This ITP establishes policy for a SDLC framework, and related software application development
methodologies and tools that are essential components in the management, development, and delivery of software applications to support agency business needs and services.
2. Scope This Information Technology Policy (ITP) applies to all departments, boards, commissions and councils under the Governor’s jurisdiction. Agencies not under the Governor’s jurisdiction are strongly encouraged to follow this ITP.
3. Background Software application development is a complex endeavor, susceptible to failure, unless undertaken with a deliberate and systematic methodology. Application development requires a SDLC framework that fully integrates Software Application Development Methodologies
(SADM), Project Management, and Software Quality Control and Assurance components to create quality software applications with real business value in a timely cost effective
manner.
In addition, a SDLC is the essential underlying foundation required in establishing a standard framework for the proper evaluation, development, installation, validation, integration, implementation, and life cycle management of information system solutions (i.e., hardware
and software), regardless of the systems engineering, or software development methodologies, and/or tools used to automate, manage, execute the development and/or
delivery the information systems solutions.
It is imperative to have an SDLC framework established with procedures and processes aligned with their respective software application development methodology. Integrating
software development tools (e.g., CAD, Application Life Cycle Management, Modeling, Testing, Compliance, etc.) can aid in the management, automation, and consistency of solution development as well as the overall quality of the end product. These tools must also
be properly aligned and integrated into the SDLC framework and respective SADM approach.
Managing the application portfolio is a key component of life cycle management.
Understanding the type, composition, status, and risks associated with agency applications
that enable business and IT services is critical for IT strategic planning and making informed
decisions regarding modernization, enhancements, divestiture, or replacement based on the
changing needs of the business and IT ecosystems.
ITP-SFT000 Systems Development Life Cycle Policy
Page 2 of 16
4. Definitions
4.1 Application Inventory: A centrally managed repository used to capture data and assess risk profiles for all enterprise and agency-level applications that support the
business needs of the commonwealth.
4.2 Application Lifecycle Management (ALM): A tool that aids the development teams in the entire application development and product lifecycle management (e.g., governance, development, and maintenance). It encompasses requirements
management, software architecture, programming, software testing, software maintenance, change management, continuous integration, project management,
defect management, versioning and release management.
4.3 Application Software: Often called productivity programs or end-user programs because they enable the user to complete tasks, such as creating documents, spreadsheets, databases, and publications, doing online research, sending email,
designing graphics, and running businesses. Examples include:
• Commercial-off-the-Shelf (COTS) is a term used to describe the purchase of products that are standard manufactured products rather than custom, or bespoke, products. COTS application software are built and delivered usually
from a third party vendor and can be purchased, leased or even licensed.
• Modified off-the-Shelf (MOTS) is typically a COTS product whose source code can be modified. The product may be customized by the purchaser, vendor, or
another party to meet business requirements. MOTS is a software delivery concept that enables source code or programmatic customization of a standard
prepackaged, market-available software.
• Custom Built Application Software is the designing of software applications for a specific user or group of users within an organization. Such application software
is designed to address specific user needs precisely as opposed to the more traditional and widespread off-the-shelf application software. Custom built application software meets unique business requirements.
4.4 Development Application Software: Known as computer programming tools, are used to translate and combine computer program source code and libraries.
4.5 Functional Testing: Validating an application correctly performs functions identified in requirements documents. This includes testing for normal and erroneous input. Functional testing can be performed manually or automated.
4.6 Integration Testing: The phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes
system testing.
4.7 Load Testing: Covers both performance testing and stress testing.
4.8 Performance Testing: Performance testing identifies bottlenecks during high volume simulation.
4.9 Regression Testing: Allows a consistent and repeatable validation of current functionality with each new release of an application. This ensures no new defects have been introduced with the latest maintenance.
ITP-SFT000 Systems Development Life Cycle Policy
Page 3 of 16
4.10 Service Design Coordinator: Role responsible for providing oversight of all design activities and associated processes of service design and evaluation for new or changes to existing services. Coordinates with Business Relationship Managers, technical staff, product vendors, procurement, project managers, transition teams,
and other key stakeholders to ensure the completeness and successful implementation of the Service Design Package for enabling and sustainment of the
IT services.
4.11 Service Design Package (SDP): Documentation defining all aspects of an IT service and its requirements through each stage of its lifecycle. SDP defines the service model, requirements (utility & warranty), tools, architecture, metrics, and
blueprints needed by the service transition team to build, test/validate, and deliver the service and their underpinning components. A service design package is developed for new, major changes, and retirement of an IT service.
4.12 Service Design Processes: Refers to the design activities regarding:
• Determining service scope, type, and composition
• Define critical success factors and key performance indicators for the service; mapped to business and IT strategies
• Defining utility and warranty requirements (e.g., functional, nonfunctional, and SLA/SLO requirements)
• Development of “As-Is” and “To-Be”, architecture models (e.g., applications, data/information, infrastructure, security, organization, operational support,
governance)
• Conducting gap analysis of “As-Is” and “To-Be” states relative to business and IT ecosystems
• Design blueprints and executable roadmaps associated with service assets/configuration items required to enable and sustain the service. Following existing SDLC processes for applications and infrastructure solution design,
development, test/validation, and implementation.
• Define a consolidated transition and deployment strategy and executable plan for successful service delivery (e.g. business, technical, and operational perspectives)
• Ensure alignment with existing ISTM processes such as service level management, service desk, availability management, capacity management,
change management, financial management, and service continuity management.
4.13 Software Application Development Methodology (SADM): A software application development methodology is a structured framework of procedures and processes used to develop custom software applications. Software application
development methodologies are essentially derivatives from the system development life cycle model but are unique in their respective processes and
execution. Some SADMs are as follows:
• Agile Model: A highly iterative software application development model that involves an interactive, cross-functional, and focused team approach to build software solutions in a time boxed (sprints) development methodology. The
Agile model uses feedback and checklists, tightly integrated cross functional teams, and multi-faceted iterations or sprints to quickly build custom software
applications. The feedback is driven by regular tests and releases of the evolving software
• Spiral Model: An incremental software development process model that
incorporates requirements, design, build/construct, test/simulations, and deploy prototype phases separated by planning and risk assessment. A prototype is created with each iteration and evaluated until a final production ready (i.e.,
fully functional and validated) prototype model has been created. This method can be used to create temporary prototype solutions that are later discarded or
for large, expensive, and complicated projects using each iterative prototype build as a phase gate and/or milestone. Documentation in this process is dynamic and incrementally refined. Documentation is finalized with the
implementation of the final production ready prototype.
• Waterfall Model: A software development process model that involves distinct sequential phases (i.e., conception, requirements, design, build/construct, test,
and implementation). Solution progress is flowing steadily downwards (like a waterfall) through each of the phases. This means that any phase in the
development process may begin only if the previous phase is complete. There can be some slight variations in the waterfall approach (i.e., modified water fall) that define the circumstances and processes to go back to the previous phase.
Documentation in this process is also sequential. Documentation is typically created, delivered, and approved with each phase as a prerequisite for the next
phase to begin. Each phase in this model is a phase gate or key milestone.
4.14 Stress Testing: Used to determine the load under which the application ceases to perform acceptably.
4.15 Software-as-a-Service (SaaS): The capability provided to the consumer is to use the cloud service provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client
interface, such as a web browser or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers,
operating systems, storage, or even individual application capabilities, apart from limited user-specific application configuration settings.
ITP-SFT000 Systems Development Life Cycle Policy
Page 5 of 16
4.16 Software Development Life Cycle (SDLC): The SDLC is a conceptual model used in software engineering as well as project management that describes the phases involved in an information system solution development and delivery. A SDLC framework consists of multiple phases to assure high quality systems are
delivered, provide strong management controls over IT projects, and ensure that the information system can, and will, work as required and is effectively maintained
to support agency’s missions. SDLC can be applied to Commercial-off-the-Shelf (COTS), Software-as-a-Service, (SaaS), or custom-built applications. SDLC frameworks should be intently integrated into key service life cycle phases (e.g.,
strategy, design, transition, operations) and affiliated processes.
4.17 Systems Software: includes the programs that are dedicated to managing the computer itself, such as the operating system. The operating system manages the computer hardware resources in addition to applications and data. Without systems
software installed in our computers we would have to type the instructions for everything we wanted the computer to do. Examples include:
• Operating systems, which are essential collections of software that manage resources and provides common services for other software that runs "on top" of them. Supervisory programs, boot loaders, shells and window systems are core
parts of operating systems. In practice, an operating system comes bundled with additional software (including application software) so that a user can potentially do some work with a computer that only has an operating system.
• Device drivers, which operate or control a device that is attached to a computer. Each device needs at least one corresponding device driver; because a computer typically has at minimum at least one input device and at least one output
device, a computer typically needs more than one device driver.
• Utilities, which are computer programs designed to assist users in the maintenance and care of their computers.
4.18 System Testing: Testing conducted on a complete integrated system to evaluate the system's compliance with its specified requirements.
4.19 Unit Testing: Functional testing on each module in an application. Used early in development process before all components are completed.
4.20 User Acceptance Testing (UAT): This is generally the last phase of the software testing process. During UAT, actual software users test the
software to make sure it can handle required tasks in real-world scenarios, per requirements.
5. Objective Provide a framework for the creation and delivery of high quality business information
systems that:
• Meet or exceed customer expectations when promised and within cost estimates;
• Work effectively and efficiently within the current and planned information
infrastructure; and
• Are properly managed, maintained, and properly documented throughout their useful
life.
• Ensure proper alignment with Business and IT Service Portfolio and integrated ITIL processes
ITP-SFT000 Systems Development Life Cycle Policy
Page 6 of 16
• Facilitate the development of agency specific policies and associated standard
operating procedures to establish sound SDLC frameworks, audit controls, and separation of duties.
• Ensure Commonwealth agencies are employing the best practices of SDLC and
providing some assurance that systems are being developed efficiently and effectively.
• Outline some tools and specifications that can be used/referenced by agency
application development teams for facilitating the management, automation, consistency, quality assurance, and compliance of solutions.
• Provide SDLC strategy concepts
• Posture the Commonwealth application portfolio towards a COTS or SaaS-first priority
6. Policy All new application development and enhancement projects are required to utilize a well-documented systems development life cycle framework. This applies to projects performed
by Commonwealth employees and by Commonwealth contractors.
Whether a software application development methodology is based on waterfall, spiral, agile processes or some other methodology they share fundamental systems development life cycle components and activities. Agencies are required to establish a SDLC framework that
at a minimum include the following components:
Feasibility - processes and procedures to evaluate and define the best solution approach
through research, feasibility studies, analysis of business needs and/or high-level
requirements, resources, capability, capacity, IT investment and risk strategies, alternatives
analysis, SADM, etc.
Cloud Services Request
Agencies that have determined a Software-as-a-Service (SaaS) solution meets the business
requirements are required to engage OA/OIT through a Service Request process prior to
consumption of the SaaS solution. This process allows the agency and OA/OIT to perform a
robust vetting analysis that will:
• Determine the impact and capacity of bandwidth on the Commonwealth backbone • Ensure and maintain agency and enterprise information security • Help establish consistent rules of engagement for implementation of the solution
• Help establish flexible cloud procurement vehicles • Allow for a centralized repository of lessons learned, use cases, and other cloud-based
artifacts to enhance the Commonwealth’s cloud solutions posture • Determine the impacts to existing to existing agency and/or enterprise service
offerings, capabilities, and resources
Additional details on the Service Request process is in Section 9 - Related ITPs/Other
References.
Requirements Management - requirements definition, analysis, refinement, categorization,
prioritization, changes, traceability, and documentation procedures and processes based on
SADM. Service Design Coordinator shall ensure alignment with Service Design Package (SDP)
and affiliated application, infrastructure, data/information, security requirements defined and
managed through service design and integrated SDLC frameworks.
ITP-SFT000 Systems Development Life Cycle Policy
Page 7 of 16
Principles – To reduce the commonwealth’s legacy and customized application portfolio,
agencies tasked with new or modernizing applications to support business needs are to
emphasize reuse engineering of existing solutions, Commercial-off-the-Shelf (COTS) and
Software-as-a-Service (SaaS) solutions over commonwealth-customized applications.
Agencies are to also consider leveraging multiple COTS or SaaS solutions that can be
integrated to formulate a holistic solution to the business needs. Evidence of such must be
included with required project initiative documentation.
If no third-party solution (i.e. COTS, SaaS, or combination with integration), meets business
requirements, next consideration is to be given to commonwealth-custom application actively
maintained in the Commonwealth (utilize the Enterprise Application Inventory for analysis of
available commonwealth-custom applications). If a commonwealth-custom application is not
available or does not meet business requirements, agencies may then leverage internal and
external personnel to develop a commonwealth-custom application. NOTE: This policy
requires agencies to enter and maintain all custom applications into the Enterprise
Application Inventory. Failure to maintain current continuity plans and an updated application
entry in the Enterprise Application Inventory may result in delays in agency project
approvals.
Agencies must perform a comprehensive multidimensional examination of COTS and/or SaaS
solution alternatives in comparison to custom application development. A comparative
analysis matrix should be created using predefined evaluation criteria with weighted scoring
and ranking method to evaluate solution alternatives in making informed decisions as to the
solution that will provide the best value to the organization.
Agencies must be able to provide sound justification for the why a COTS or SaaS solution
alternative is or is not the viable alternative to custom application development when
investing in a new, modernizing, or replacing application platform used to support the agency
mission.
Design – processes and procedures for the creation and evaluation of conceptual design
models and high-level diagrams to detailed design models and diagrams based on SADM.
Service Design Coordinator shall ensure alignment with Service Design Package (SDP) and
affiliated application, infrastructure, data/information, security design specifications managed
through service design, change management and integrated SDLC frameworks.
Build – processes and procedures utilized to construct and/or configure the solution based on
SADM. All Commonwealth-custom application source code and/or software must reside on
Commonwealth IT Resources or approved commonwealth-contracted resources. This source
code and/or software is not being shared in public domains. A COPPAR waiver is required if
an agency needs to share Commonwealth-custom application source code and/or software in
a public domain. Service Design Coordinator shall ensure alignment with Service Design
Package (SDP) and service transition activities affiliated with application, infrastructure,
data/information, security design specifications managed through service design, transition,
change management and integrated SDLC frameworks.
Testing & Validation - processes and procedures associated with test planning, test design,
test execution, validations, defect management, and approvals, based on SADM and in
ITP-SFT000 Systems Development Life Cycle Policy
Page 8 of 16
relation to unit, systems integration, user acceptance, and security vulnerability testing
requirements. These processes and procedures should also include integrated quality control
and assurance mechanisms to ensure solution meets all business, systems, security, policy,
product quality, and/or other relevant compliance/certification requirements.
• Application quality is fundamental to delivering expected business outcomes and agreed
upon service level. The quality of testing is the overall contributor to the quality of the
application. The effectiveness of the testing effort can be maximized by selection of a
testing strategy which includes thorough unit, integration, system, regression,
performance, stress testing, good management of the testing process, and the
appropriate use of tools.
• Testing tools are to be used to verify that changes in functionality were successfully
implemented and that changes were implemented without degradation to other
application components or performance. The use of testing tools is to be integrated with
the change management strategy and the standards defined in section 7.
The selection and use of test tools (open source or purchased) should be properly evaluated
relative to interoperability, extensibility, maintainability, and overall test coverage and
effectiveness under the specified test conditions/parameters and targeted systems
environment(s).
Implementation - processes and procedures regarding production ready solution adoption,
delivery, and deployment; including business and technical operational readiness
assessments with integrated go-live decision and roll-back mechanisms.
Operations & Maintenance - processes and procedures to ensure the system is monitored for
expected performance in accordance with requirements in live production environments,
needed modifications are incorporated and subsequent product releases are effectively
managed to ensure the system continues to evolve to meet the changing needs of the
business. All documentation is finalized and archived for future reference.
Agencies shall incorporate separation of duties to maintain continuity and integrity
throughout the execution of the procedures and processes associated with the SDLC
framework and affiliated software development projects. Careful consideration should be
given to:
Establishing access controls granting permissions to Commonwealth employees and/or
outside contractors performing multiple roles within the various environments (i.e.,
development, production, system integration, testing, staging, etc.) to add, modify, delete,
and migrate application code, data sets, and/or make configuration changes to systems in
these environments.
Granting privileged access granting permissions to outside contractors to add, modify, and/or
delete user accounts and IDs and/or information systems security configurations.
Establishing controls defining oversight, authority and responsibilities for end-product
verifications, validations, and final acceptance/approvals associated with operational
readiness assessments, testing, systems and data conversions, and go-live decisions.
ITP-SFT000 Systems Development Life Cycle Policy
Page 9 of 16
Agencies shall ensure proper alignment of SDLC frameworks with the desired project
management approach based on the SADM chosen, i.e., integrated project management
elements associated with waterfall, spiral or agile approaches that are used to facilitate the
initiating, planning, executing, monitoring/controlling, and closing of all systems development
tasks and activities within the SDLC framework.
Agencies shall ensure proper alignment and integration of ALM and other application development tools with established SDLC frameworks and corresponding SADM approach
used in the solution development. When utilizing tools, agencies should reference Section 7 and affiliated product listings.
Service Design Coordinator shall ensure alignment of Service Design Package (SDP) test
plans, execution, validation, acceptance activities affiliated with application, infrastructure,
data/information, security design specifications managed through service design, transition,
change management, and integrated SDLC frameworks.
It is acceptable for agencies to maintain and utilize more than one SADM and project management approach within the SDLC framework.
Release Management – The objective of release management is to ensure that standardized
methods and procedures are used for defining executable solution deployment strategies and
implementation playbooks to ensure efficient and successful delivery of all software releases
with minimal impact the integrity of existing services and/or business operations. Release
management practices are to be applied to all software development lifecycles as well as
hardware, documentation, processes, and other components of a service. Release
management focuses on strategic planning, scheduling, and controlling the movement of
releases between development, staging, and production environments. Release management
should include a release package, a set of configuration items to be built, tested, and
deployed as a single release.
The Service Design Coordinator shall evaluate systems and operational readiness
assessments and monitor service transition activities and integrated SDLC frameworks in
collaboration with business and service operations stakeholders.
Change Management – The objective of change management is to ensure that standardized
methods and procedures are used for efficient handling of all changes to minimize the impact
of change-related incidents and to improve day-to-day operations. Change management is
the process of documenting change requests, analyzing feasibility, planning, implementing,
and verifying changes to a system. Change requests can be initiated by the requirement for a
new feature, by the requirement to fix a problem, or by the requirement to change the way a
business function is performed. A request is accompanied by all the relevant information
about the proposed change and the change initiator. Analyzing the change request involves
assessing the urgency, assigning priority, performing technical and economic feasibility, and
risk and impact analysis. Designated approvers use this information to approve or reject the
change request. Planning refers to developing specific technical requirements, scheduling,
identifying the implementation and back-out strategy, and receiving approval.
Implementation includes deployment and propagation of the change, as well as testing and
ITP-SFT000 Systems Development Life Cycle Policy
Page 10 of 16
documentation updates. Before closing the change request in the change management
system, the change is verified by the stakeholders.
Application Inventory – The integration of an application inventory also provides a valuable
tool for risk assessments and business continuity planning. The inventory identifies risks
associated with technology maturity (software and hardware), compliance, sustainability,
audits, supportability, recoverability, etc. It contains vital information regarding business
criticality and physical location of assets which will provide valuable insights to agency and
enterprise stakeholders to prepare for continuity plans, assessing impacts on business and/or
IT operations, and assist in planning and making key decisions regarding modernization
strategies, IT project and investments priorities.
The application inventory also provides agency CIOs and IT Managers with a resource to prepare their agency IT strategic plans and to ensure alignment with agency and enterprise business and IT strategic initiatives. In addition, the application inventory provides an
additional mechanism for agency portfolio/project managers to understand potential risks/impacts, align business and IT strategies with IT projects initiatives to meet agency
business goals and objectives.
Systems development life cycles need to have a long-term strategy to maintain value and alignment with ever-changing business function requirements. Key components that a
mature SDLC strategy will capture include:
• Detailed demonstration of continued value to the enterprise • A defined plan of communication and understanding between application development
teams, key stakeholders, and business users using:
o Service design packages o Documented workflow and decision-tree models
o Implementation of a knowledge management process • Integration of application security programs and processes in all SDLC processes • A proper balance between delivery of systems based on business requirements and
cost-effectiveness processes • New and modernized application/system software designs that consider the hardware
and software roadmaps that support the systems
7. Standards
Current Standards for Application Testing Tools (These technologies meet the requirements of the current architecture and are recommended for use.)
Technology Platforms Technology Classification
Microsoft Visual Studio Team Services (VSTS)
Windows Current
IBM Rational Team Concert (RTC) Windows Current
IBM Rational Performance Tester Windows Current
IBM Rational Robot Windows Current
IBM Rational Functional Tester Windows Current
ITP-SFT000 Systems Development Life Cycle Policy
Page 11 of 16
IBM Rational PurifyPlus Windows Current
IBM Rational Test Manager Windows Current
HP LoadRunner All Current
HP/Quick Test Professional Version Windows Current
HP Quality Center All Current
Microsoft Team Foundation Server (TFS)
Windows Current
Contain Standards for Application Testing Tools (These technologies no longer meet the requirements of the current architecture and are not recommended for use. They are to be phased out over time. No date has been set for their
discontinuance.)
Technology Platforms Technology Classification
Mercury WinRunner (all versions) All Contain
Current Standards for Application Requirements, Data, and Object Modeling Tools (These technologies meet the requirements of the current architecture and are recommended for use.)
Technology Platforms Technology Classification
Microsoft Visual Studio Team Services (VSTS)
Windows Current
IBM Rational Team Concert (RTC) Windows Current
IBM Rational Software Architect Windows Current
IBM Rational Software Modeler Windows Current
Computer Associates ERwin Data Modeler
Windows Current
Microsoft Visio (Standard/Professional/Enterprise Architect Editions)
Windows Current
Sparx Systems Enterprise Architect Windows Current
Sparx Systems MDG Integration for Visual Studio
Windows Current
ITP-SFT000 Systems Development Life Cycle Policy
Page 12 of 16
Contain Standards for Application Requirements, Data, and Object Modeling Tools (These technologies no longer meet the requirements of the current architecture and are not
recommended for use. They are to be phased out over time. No date has been set for their
discontinuance.)
Technology Platforms Technology
Classification
IBM Rational Rose Modeler (all
versions)
Windows Contain
IBM Rational Rose Developer for
Java (all versions)
Windows Contain
IBM Rational Rose Developer for
Visual Studio (all versions)
Windows Contain
IBM Rational Rose Enterprise (all
versions)
Windows Contain
Borland Together Windows Contain
Sybase PowerDesigner (all versions)
Windows Contain
MagicDraw UML (all versions) Windows Contain
Computer Associates Groundworks
(all versions)
Windows Contain
Current Standards for Application Requirements Management Tools (These technologies meet the requirements of the current architecture and are recommended for use.)
Technology Platforms Technology Classification
Microsoft Visual Studio Team
Services (VSTS) Windows Current
IBM Rational Team Concert (RTC) Windows Current
IBM/Rational RequisitePro Windows Current
HP Quality Center All Current
Microsoft Team Foundation Server Windows Current
Sparx Systems Enterprise Architect Windows Current
Contain Standards for Application Requirements Management Tools
(These technologies no longer meet the requirements of the current architecture and are not
recommended for use. They are to be phased out over time. No date has been set for their
discontinuance.)
Technology Platforms Technology Classification
Borland Caliber-RM All Platforms Contain
ITP-SFT000 Systems Development Life Cycle Policy
Page 13 of 16
Telelogic DOORS All Platforms Contain
Current Standards for Software Configuration Management Tools
(These technologies meet the requirements of the current architecture and are recommended for use.)
Technology Platforms Technology Classification
Microsoft Visual Studio Team
Services (VSTS) Windows Current
IBM Rational Team Concert (RTC) Windows Current
Microsoft Team Foundation Server Windows Current
IBM Rational ClearCase MultiSite All Current
Contain Standards for Software Configuration Management Tools
(These technologies no longer meet the requirements of the current architecture and are not
recommended for use. They are to be phased out over time. No date has been set for their
discontinuance.)
Technology Platforms Technology Classification
IBM Rational ClearCase All Contain
Microsoft Visual SourceSafe 2005
Standard Edition
Windows Contain
Current Standards for Software Change Management Tools
(These technologies meet the requirements of the current architecture and are recommended for use.)
Technology Platforms Technology Classification
IBM Rational ClearQuest All Current
IBM Rational ClearQuest
MultiSite
All Current
Microsoft Team Foundation
Server
All Current
Microsoft Visual Studio
Team Services (VSTS) Windows Current
ITP-SFT000 Systems Development Life Cycle Policy
Page 14 of 16
Contain Standards for Software Change Management Tools
(These technologies no longer meet the requirements of the current architecture and are not
recommended for use. They are to be phased out over time. No date has been set for their
discontinuance.)
Technology Platforms Technology Classification
N/A N/A N/A
8. Responsibilities
8.1 Commonwealth Agencies:
• When performing application development, are required to utilize a documented SDLC framework for all new application development and enhancement projects.
• All applications that directly or indirectly support vital business functions (e.g. financial, federally-mandated, etc.) and/or are linked to a Continuity of Planning
(CoP) Primary Mission Essential Business Function (PMEF) must be reported into the Enterprise Application Inventory tool (see Section 9 for location of tool). The agency
must update this inventory to reflect the status and composition of their application portfolio supporting their agency mission.
• Agencies that utilize an internal agency-based application inventory are required to report their applications into the Enterprise Application Inventory tool.
• Agencies are to maintain proper alignment of their application portfolios contained in the Enterprise Application Inventory tool with their respective agency IT Strategic Plans and IT Policy compliance status (existing policy waivers or other non-
compliance conditions).
• Agency applications that are public-facing must comply with ITP-SEC005 Commonwealth Application Certification and Accreditation procedures and requirements.
• Align and integrate ITIL Service life cycle phases with SDLC frameworks as appropriate and level of maturity evolves within commonwealth IT organizations.
• Agencies are to adhere to the software decision Principles for determining software/application needs.
• Agencies are to submit an OA/OIT Service Request for all SaaS solutions prior to consumption of said solutions.
8.2 Office of Administration, Office for Information Technology
• Will maintain an intranet-available centralized Enterprise Application Inventory tool
and provide guidance and assistance to agencies utilizing that tool.
• Will maintain a Service Request process for agencies to on SaaS solutions and provide a timely analysis of all SaaS solution requests.
ITP-SFT000 Systems Development Life Cycle Policy
Page 15 of 16
9. Related ITPs/Other References
Commonwealth policies, including Executive Orders, Management Directives, and IT Policies are published on the Office of Administration’s public portal: http://www.oa.pa.gov/Policies/Pages/default.aspx
• Management Directive 205.34 Commonwealth of Pennsylvania Information Technology Acceptable Use Policy
• RFD-SFT000C Application Development Security Decision Tree [Publication TBD]
• ITP-SEC000 Information Security Policy
• ITP-SFT001 Software Licensing
• ITP-SEC005 Commonwealth Application Certification and Accreditation
• Enterprise Application Inventory: https://itcentral.pa.gov/apps/applicationinventory/Pages/ApplicationInventory.aspx
(COPA limited access only)
• Enterprise Application Inventory Guidelines: https://itcentral.pa.gov/apps/applicationinventory/Documents/ApplicationInventoryGui
deline.docx (COPA access only)
• Enterprise Service Request: https://itcentral.pa.gov/Pages/Enterprise-Services.aspx (COPA access only)
10. Authority Executive Order 2016-06, Enterprise Information Technology Governance
11. Publication Version Control
It is the user’s responsibility to ensure they have the latest version of this publication, which appears on https://itcentral.pa.gov for Commonwealth personnel and on the Office of
Administration public portal: http://www.oa.pa.gov/Policies/Pages/default.aspx. Questions regarding this publication are to be directed to RA-ITCentral@pa.gov.
12. Exemption from This Policy In the event an agency chooses to seek an exemption, for reasons such as the need to comply with requirements for a federally mandated system, a request for waiver may be submitted via the Commonwealth of PA Procurement and Architectural Review (COPPAR)
process. Requests are to be entered into the COPPAR Tool located at http://coppar.oa.pa.gov/. Agency CIO approval is required.
This chart contains a history of this publication’s revisions:
Version Date Purpose of Revision Original 02/17/2017 Base Document
Moved to Software domain from Application, including ITP number change Merged ITP-APP012 Systems Development Life Cycle Policy, ITP-APP014 Application Testing Tools Policy, ITP-APP016 Requirements, Data and Object Modeling Tools, ITP-APP017, ITP-APP018 Software Configuration Management Tools, ITP-APP019 Software Change Management Tools into ITP Added additional guidance to Policy and Responsibilities sections
ITP-SFT000 Systems Development Life Cycle Policy
Page 16 of 16
Revision 09/13/2017 Inserted language on software decision Principles Added software decision Principles Agency Responsibility Added MS VSTS to Current Standards for Software Change Management Tools Added Release Management concepts Added Service Request requirement for SaaS solutions Added additional definitions Added additional responsibilities addressing Service Request requirement for SaaS