Sop 1705 SDLC Sop PDF

SOFTWARE
SOP-1705 DEVELOPMENT LIFE Version 14.0

CYCLE
SOP-1705 ( Version 14.0) - EFFECTIVE - Check electronic version in eDMS before use
STANDARD OPERATING PROCEDURE

DOC TITLE: SOFTWARE DEVELOPMENT LIFE CYCLE
DOC ID: SOP-1705
VERSION: 14.0
PROCESS CATEGORY: SDLC PROCESS
Johnson & Johnson Information Technology

Template: TMP-1779 V2.0 Page 1 of 71
Confidential
SOFTWARE
CYCLE
TABLE OF CONTENTS
1 OBJECTIVE .................................................................................................................. 3
2 SCOPE ........................................................................................................................ 3
3 DEFINITIONS ................................................................................................................ 4
3.1 Terms and Acronyms: .................................................................................................4
3.2 Role Descriptions......................................................................................................13
4 REFERENCES ............................................................................................................. 16
5 ACTIVITY PROCEDURE DESCRIPTION ........................................................................... 17
6 PROCESS OVERVIEW .................................................................................................. 17
6.1 Process Diagram ......................................................................................................18
7 SOFTWARE-AS-A-SERVICE (SAAS).............................................................................. 18
8 WATERFALL FRAMEWORK .......................................................................................... 19
8.1 Discovery & Initiate Phase ........................................................................................20
8.2 Requirements & Analysis Phase...............................................................................24
8.3 Architecture & Design Phase ....................................................................................25
8.4 Build Phase...............................................................................................................27
8.5 Test Phase................................................................................................................29
8.6 Release & Deploy Phase ..........................................................................................33
9 AGILE FRAMEWORK ................................................................................................... 36
9.1 Discovery & Initiate Phase ........................................................................................37
9.2 Plan & Readiness Phase ..........................................................................................41
9.3 Development & Test Phase ......................................................................................43
9.4 Sprint Review Phase.................................................................................................47
9.5 Release & Deploy Phase ..........................................................................................48
10 OPERATE PHASE – AGILE AND WATERFALL FRAMEWORKS ...................................... 52
11 ARCHIVE & RETIREMENT PHASE – AGILE AND WATERFALL FRAMEWORKS ................ 56
12 DOCUMENT HISTORY ............................................................................................. 60
12.1 Superseded Document(s) .........................................................................................60
12.2 Revision History ........................................................................................................60

Confidential
SOFTWARE
CYCLE
1 Objective
The purpose of this procedure is to outline the Software Development Lifecycle (SDLC)
to be followed for software engineering projects. This procedure briefly outlines the
Waterfall and Agile Frameworks, along with their respective phases and deliverables.
The applicability of deliverables may be Expected (must do) or Conditional (if applicable)
according to the type of project being carried out. The scope of project may be defined
by various projects parameters; such as whether the project is a configuration or
customization of Commercial Off-the-Shelf (COTS) software products, Software-as-a–
Service (SaaS) initiative, or new application development.
2 Scope
The SDLC is a framework for initiating, planning, creating, testing, deploying, operating
and decommissioning information systems and applications; including operations upon
go-live and archival and retirement when the application or system will be phased out to
complete the lifecycle. It outlines the activities that have to be performed with
associated deliverables to be compliant when developing, maintaining, replacing,
altering or enhancing specific software for a given software engineering project.
The structure of the procedure details two frameworks under SDLC which are supported;
the Waterfall Framework and the Agile Framework. It specifies the deliverables under
each phase based on the Entry Criteria, Tasks to be performed, Verification to be
executed and Exit Criteria/Deliverable expectations. The Roles and Responsibilities are
clearly defined by a RACIS matrix for each phase under the respective framework.
The a2 tool will score the applicability of the appropriate framework, Agile or Waterfall,
which should be used for the specific project.
The outputs of the SDLC are project deliverables, often electronic reports containing
signatures or project data captured in the tools utilized. Per sanctioned J&J policy, each
Operating Company shall abide by their local procedures for creating, updating,
reviewing, approving, developing and conducting training, releasing, conducting periodic
reviews and retiring these deliverables which are considered Quality System Documents
(QSD).
Out of Scope The following are not required to use this procedure:
! Mobile Medical Applications – mobile applications used a medical device
! Software as Medical Device - software in medical devices/equipment

Confidential
SOFTWARE
CYCLE
! Infrastructure and tools that support infrastructure 1
! Automated manufacturing and laboratory equipment and instrumentation
3 Definitions
3.1 Terms and Acronyms:

! a2 Tool – Application Accelerator Tool provides a single platform designed to make
project planning simpler, faster and more effective by enabling global teams to work
consistently, unifying standards and templates in order to manage risk and deliver
alignment across two key domains:
i. Project Management
ii. Software Development Lifecycle
! Application Security Self-Assessment - Two-part self-assessment tool which is
completed by the IT project team in order to understand the risk and potential security
control gaps in projects where ISRM resources are not engaged to support IT in the risk
assessment and security requirements gathering process. The assessment:
i. Provides a heat map of control strength vs a risk-based target level in order

to enable the IT teams to build-in an adequate level of security protection
consistent with the Minimum Viable Security Controls as defined in
Information Asset Protection Policies (IAPP) S-15 Worldwide Secure
Application Software Life Cycle Policy.
ii. Allows the receiving support team to ensure that the appropriate security
controls have been built into software relative to the risk to the business.
iii. Meet J&J policy requirements for application security.
! Business Impact Assessment (BIA) – Describes the business use and various
business risks of a business application as well as the requested Disaster Recovery
parameters: Recovery Time Objective (RTO) and Recovery Point Objective (RPO),
and/or the option to not have Disaster Recovery and accept that risk.
! Business Process Analysis Documentation – Process maps, process modeling

and other documentation associated with the analysis of current business processes
and the identification of improvements to reduce wasteful steps and identify process
improvements.
1
Use SDLC Infrastructure SOP for these projects.

Confidential
SOFTWARE
CYCLE
! Business Simulation Testing (BST) – Mimics real-life business scenarios that

ensure the solution delivered solves the business need it was intended to resolve.
! CaseComplete – Requirements management tool that is integrated with JIRA,

supporting both Waterfall and Agile projects.
! Change Control (CC) - Is a formal approved request or an order for the

implementation of a change to the system which is usually submitted in a Change
Management System. For GxP projects, the use of an authorized Change
Management System is mandatory,
! Code Review Record - Typically, code review focuses on ensuring that the code is
in accordance with the technical design and that it follows applicable coding
standards.
! Coding Standards - A set of guidelines for a specific programming language that

recommend programming style, practices, and methods for each aspect of a
program written in that language.
! Commercial Off-the-Shelf (COTS) – Packaged solutions which are procured and

then adapted to satisfy business needs.
! Compliance Analysis (CA) - Identifies the compliance requirements for the software
being delivered. The results of this analysis establish the following:
i. Descriptive data for entry into the Configuration Management Database
(CMDB).
ii. Information to aid in determining detailed Compliance Requirements, which
will be captured in the User Requirements or User Stories and information to
aid in determining additional compliance deliverables, to be defined in the
Compliance Plan.
iii. Application categorization, to assist in further project planning and input for
identifying risks.
! Compliance Plan (CP) - Describes the activities that must be performed to provide
evidence that the software has been developed and installed as per predefined
specifications and operates as intended.
! Compliance Summary Report - Summarizes the compliance deliverables, the

activities performed, documents deviations from the Compliance Plan and provides
an executive summary of the validation activities carried out. For GxP applications, it
also authorizes the implementation of the software in a production environment.

Confidential
SOFTWARE
CYCLE
! Conditional Documentation – Project documentation that is needed for the specific

project, such as user guides, checklists, job aids, Work Instructions (WIs), Standard
Operating Procedures (SOPs), or other such documentation that is project specific.
Conditional documentation should be identified and included in the Compliance Plan.
! Configuration Control Document (CCD) - Track and control versions of software to

be released for the system’s operational environment. It is a summary of the
features and contents for the software build, including version; and contains general
release information, installation instructions, an itemized list of all the configured
elements, and recovery instructions. This document supports tracing changes and
ensures that the final delivered software package has all of the intended
components.
! Continuous Process Improvement (CPI) - Is an ongoing effort to improve

products, services, or processes. These efforts can seek "incremental" improvement
over time or "breakthrough" improvement all at once. Delivery (customer valued)
processes are constantly evaluated and improved in the light of their efficiency,
effectiveness and flexibility.
! Critical Success Factors (CSFs) - Critical factor or activity required for ensuring the
success of the software engineering product.
! CSV Risk Assessment Report – The objective of the risk assessment is to assess
GxP and business priority high/medium business requirements to determine the
recommended testing based on risk. In addition, the risk assessment will be used to
document multiple controls, as applicable.
! Data Flow Map - A visual representation of application components, users and the
transmission, processing and storage of data of different classifications (public,
confidential, restricted, highly restricted) between those components.
! Data Conversion/Migration Requirements Specification – The requirements for

transferring and/or translating data from one format and/or location to another by a
set of customized qualified and validated programs or scripts.
! Defect Form - Highlights conditions when the system in test does not function as
required. The purpose of a defect form is to state the problem as clearly as possible
so that developers can replicate the defect easily and resolve it. Corrective actions
that are to be taken to resolve the defect and close it are captured.
! Design Specifications - Describes functional and technical design which

developers can understand and construct the code as specified. Design

Confidential
SOFTWARE
CYCLE
specifications are used to design software features. Definition of Done (DoD) -

Refers to completion of all activities necessary to deliver usable software, with
varying degrees of Done at project, release increment and user story level. This is
applicable for the Agile framework only.
! Definition of Ready (DoR) – Refers to completion of all activities necessary before

starting development of user story. This is applicable for the Agile framework only.
! Disaster Recovery Plan – The documentation that formally describes the

implementation and execution for a disaster recovery; which is the process of
reestablishing an environment using alternate capacity in an alternate location.
! Entry-Task-Validation-Exit (ETVX) – Model that views processes within the context

of Input or Triggers, Tasks (also called procedures), Controls, Constraints and
Outputs.
! Functional Requirement (FR) – Requirements that describe the behavior of the

solution and the information managed, allowing for developers to fully understand
how the software must function and what attributes are needed to meet user
requirements, In the case of a system or application, these are the features and
functions of the system.
! GxP - An abbreviation that refers to all relevant regulations, including but not limited
to Good Laboratory Practice (GLP), current Good Manufacturing Practice (cGMP),
Good Clinical Practice (GCP) and Good Distribution Practice (GDP). GxP can refer
to one specific set of practices or to any combination of regulations.
! Happiness Metric – A tool utilized by the Scrum Team to help identify improvement
efforts in how they are working and what actions they will undertake to improve
Scrum Team engagement, autonomy and morale. .
! Health Insurance Portability and Accountability Act (HIPPA) - A US law

designed to provide privacy standards to protect patients' medical records and other
health information provided to health plans, doctors, hospitals and other health care
providers
! Hewlett Packard - Application Lifecycle Management (HP-ALM) – Application

that helps to manage requirements, plan tests and support test execution for
technical and functional testing; including defect management. Traceability to the
requirements to test cases is also available.

Confidential
SOFTWARE
CYCLE
! Hypercare Transition Plan – The document that identifies the roles, responsibilities,
readiness, timelines and acceptance criteria to transition operational support from
the sending organization to a receiving organization(s). This Transition plan will be
used as a formal agreement to align the sending and receiving organizations
functions during transition and provides a formal documented signoff by the leaders
of these respective organization(s). This includes the Service Level Agreement (SLA)
that has to be followed by the Operations team.
! JIRA – A tracking application which provides bug tracking, issue tracking, and
project management functions; such as capturing and tracking user stories or use
cases.
! Key Performance Indicators (KPIs) – Business metrics used to evaluate the

success of an organization or of a particular activity in which it engages.
! Minimum Viable Product (MVP) – A release of a software system that has just
those core features that allows the product to be deployed, and no more. It is a
strategy targeted at avoiding building products that customers do not want, that
seeks to maximize the information learned about the customer per dollar spent.
! Minimum Viable Security Controls (MVS) – The minimum application security

controls required by J&J Information Asset Protection Policies (IAPPs) to protect the
confidentiality, integrity and availability of J&J data and application software assets.
! Non-Functional Requirement (NFR) – Requirements that define the qualities of the

solution or the environmental conditions under which the solution will remain
effective. This often refers to characteristics of capacity, response time, security and
availability.
! Operations Run Book (ORB) - Is a set of defined procedures developed by the

administrator or IT professional for maintaining the everyday routine, as well as the
exceptional operations of the computer system or network. The ORB should contain
all the information a staff would need to perform daily operations as information on
dealing with any problems that arise during usage from the operational system or
network.
! Potentially Shippable Increment (PSI) - Is the sum of all the Product Backlog Items
completed during a Sprint and all previous Sprints. At the end of a Sprint, the
increment must be complete, according to the Scrum Team's Definition of Done
(DoD), and in a usable condition regardless of whether the Product Owner decides to
actually release it.

Confidential
SOFTWARE
CYCLE
! Product Backlog – The inventory of system requirements including regulatory,

internal controls and security requirements as prioritized by the Product Owner. This
is applicable for the Agile framework only.
! Project Case - Captures the reasoning for initiating a project or task, usually citing
benefits; such as the reduction of costs, early market entry, or process improvement.
! Product Increment – The increment (or Potentially Shippable Increment (PSI)) is

the sum of all the Product Backlog items completed during a sprint and all previous
sprints. At the end of the sprint, the increment must be done according to the Scrum
Team’s criteria called Definition of Done (DoD). The increment must be in a useable
condition regardless of whether a Product Owner decides to actually release it.
! Project Management Excellence (PMx) Team Site – A platform that offers

program/project management governance and standards to ensure IT projects are
managed and controlled by a consistent and universal project management
standard, resulting in on time, on budget and low risk delivery.
! Rapid Requirements (rRDS) - A requirements development methodology for the

definition and documentation of requirements (business, user and functional).
! Release Plan - This plan includes how and when project releases will be delivered.
! Requirements Specification - A requirements specification is a comprehensive

description of the intended purpose and environment for software under
development. It fully describes what the software will do and how it will be expected
to perform.
! Responsible Accountable Consult Inform Signatory (RACIS) Matrix - A

responsibility assignment matrix that describes the participation by various roles in
completing tasks or deliverables for a project or business process. It is especially
useful in clarifying roles and responsibilities in cross-functional/departmental projects
and processes. RACIS is an acronym derived from the key responsibilities most
typically used: Responsible (R), Accountable (A), Consulted (C), Informed (I), and
Signatory (S).
i. Responsible – Has the obligation for creating, authoring and ensuring

execution of a task or step in a process.
ii. Accountable – Has the obligation to make sure the task is assigned and
completed the appropriate process assets and project artifacts that
Responsible provides.

Confidential
SOFTWARE
CYCLE
iii. Consult 2– Has the recommended obligation of providing subject-matter

expertise for a task or step in a process.
iv. Informed – Has the obligation of being kept up-to-date on progress, often only
on completion of the task or deliverable; and with whom there is just one-way
communication.
v. Signatory – Individuals responsible for signing-off on the project deliverable

! Retirement Plan – The Retirement Plan describes the approach for retiring the
application (decommissioning of the system) and specifies any additional
deliverables to be produced. The Retirement Plan identifies the components of the
computerized system to be decommissioned (for example, data, software, hardware,
documentation, procedures, etc.) and how each component will be disposed of (for
example, archived, migrated, deleted, repurposed), and the responsibilities and
timelines for the decommissioning process.
! Retirement Report - A required deliverable that documents and summarizes the

results of the retirement activities as described in the Retirement Plan including
deviations from the Retirement Plan.
! Retrospective – A ceremony scheduled after a sprint to reflect on how things went

and what may be improved; both within the team and the process.
! Risk Calculator - An assessment tool based on input from the project team which
provides a high-level risk scoring based on a combination of compliance and
technical risk factors. The assessment is used by ISRM as a triage tool to assign
ISRM resources to the highest risk projects.
! SDLC Project Deliverables – The outputs of the SDLC process, usually electronic
reports containing signatures or the project contents captured in utilized tools.
! Service Level Agreement (SLA) - An agreement between an IT service provider

and a customer. Describes the IT service, documents service level targets, and
specifies the responsibilities of the internal or external IT service provider and the
customer. A single SLA may cover multiple services or multiple customers.
! Software as a Service (SaaS)3 - The capability provided to the consumer is to use

the 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
2
RIM requires that all projects must consult with their Records Manager if engaged on the project. All others may be consulted as
the project requires.
3
Definition per the National Institute of Standards and Technology (NIST).

Confidential
SOFTWARE
CYCLE
web browser (e.g., web-based email), 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, with the
possible exception of limited user specific application configuration settings. The
customer licenses the use of SaaS vendor’s application service, built on the vendor’s
environment, on a subscription basis. A standard service is provided for all

customers; limited customization possible in some cases.
Examples: Salesforce.com, Tableau, Cisco WebEx, Microsoft Office 365,

SharePoint, JIRA
! Software Development Life Cycle (SDLC) - Describes the process for initiating,
planning, creating, testing, deploying, operating and retiring software.
! Software Quality Assurance (SQA) Stage Gate Assessment Report – SQA

conducts the SDLC Stage Gate quality reviews executed at the end of the most
SDLC phases, as applicable, and will provide independent perspective on the SDLC
process adherence of software quality inclusive of process adherence
! Sprint Backlog – Used to identify the scope of work in a sprint, including the user
stories to be developed and their associated tasks, success criteria and release
information.
! Sprint Planning - In preparation for the next Sprint, the Team revisits the Product
Backlog and adds any new User Stories identified during the Sprint or as a result of
the feedback.
! Sprint Retrospective - Is an opportunity for the Scrum Team to inspect itself at the
end of iteration (sprint) and create a plan for improvements to be enacted during the
next sprint. During the retrospective, the team reflects on what happened in the
iteration and identifies action for improvements going forward.
! Sprint Review - To close the Sprint, the Scrum Team presents the work done to the
Product Owner and other stakeholders to obtain acceptance and gather feedback
! System Testing (ST) – The testing conducted on a complete, integrated system to

evaluate the system's compliance with its specified requirements. System testing
falls within the scope of black-box testing, and as such, should require no knowledge
of the inner design of the code or logic. System Testing encompasses pre-UAT
testing, such as regression, functional testing, integration testing, load testing and
stress testing.

Confidential
SOFTWARE
CYCLE
! Test Protocol - This document describes the overall test strategy and test approach
for project. The document’s main purpose is to:
i. Identify the system under test.

ii. Specify test levels and test strategy (pre-UAT, UAT) for the system under
test.
iii. Define a test approach for each test level, its entry and exit criteria, test types
and techniques to be used.
iv. Identifies timelines, time dependencies and test resource roles and
responsibilities needed to execute the test strategy.
v. Testing to provide objective evidence that the software can be used in its
operating environment for its intended purpose. Testing is documented in
such a manner as to allow independent verification of the day-to-day use of
the software, based on new or existing end-user procedures.
! Test Report – Final report that summarizes the outcome of Test Protocol
execution.
! Test Scripts – A set of instructions that will be performed on the system under
test to validate that the system functions as expected. There are various types of
tests to verify the application software; including but not limited to unit test, user
acceptance test, functional test, integration test, stress test and performance test.
The means for executing these test scripts are varied.
! Traceability Matrix (TM) - Captures approved requirements and their traceability

delivered at the conclusion of the life-cycle. The Traceability Matrix links the user
and functional requirements, to their corresponding design/configuration
specifications, test scripts and production release. System Test Scripts are linked
to the functional and technical requirements and UAT scripts are linked to the
user requirements identified within the test scripts.
! User Acceptance Testing (UAT) - The last phase of the software testing
process where actual software users test the software to make sure it can handle
required tasks in real-world scenarios, according to specifications. Any
regression or end-to-end testing is included.
! User Story – A software system requirement formulated in a few sentences in

the everyday language of the user.
! Vendor Assessment – A formal assessment of the Vendor and their total quality
management system to ensure their policy, procedures and practices are robust
enough be compliant with J&J regulatory and other standards.

Confidential
SOFTWARE
CYCLE
3.2 Role Descriptions

The SDLC is role based, not resource based; offering the agility needed to address
business needs and changes in direction. This means that on a given project:
one person can have multiple roles;
multiple people can have the same role; and

one person can play the same role on multiple teams.
! Applications Support - Archiving Services – The organization responsible for
archiving data, under an approved retirement or migration plan, once authorization is
received from the Stage Gate Review Committee (SGRC).
! Business Analyst (BA) – Is responsible for the interpretation of business rules and
requirements for the development of software. They are the primary interface with
the business stakeholders (Business Technology Leader, Project Manager/Scrum
Master, Business Owner, Business User SME) and Product Line Owners (PLO) to
analyze business needs and identify and prioritize requirements to achieve minimum
viable product. Ensures that all the business requirements are understood,
documented and met. BAs should be certified from the IT-AS rRDS team.
! Business Unit Information Technology (BUIT) - The organization responsible for

ensuring the IT needs of the business units are addressed.
• Computerized Systems Validation (CSV) – Independent Quality role that fulfills

both quality assurance and quality control responsibilities for the application.
• Information Security and Risk Management (ISRM) - The organization

responsible for:
i. Enabling IT teams to design, build and operate secure application software
consistent with the Minimum Viable Security Controls as defined in
Information Asset Protection Policy (IAPP) S-15 Worldwide System and
Application Lifecycle Security Policy
ii. Providing management with assurance that security and IT process controls
are designed, built and continue to operate effectively in new and existing
systems; and
iii. Providing advice on compliance with organization (other than GxP), contracts
and internal policies throughout the application software and data lifecycle.
! OPCx Cloud Factory Services - The organization responsible for decommissioning

a system once authorization is received from the Stage Gate Review Committee
(SGRC).

Confidential
SOFTWARE
CYCLE
! Operations Owner – Responsible for the overall Service Operation Activities and
ensures that all day-to-day operational activities are carried out in a timely and
reliable way.
! Peer Developer – An experienced developer who provides an independent

validation of developed code, before testing. This validation ensures that code
follows the appropriate coding standards.
! Privacy – Is responsible for ensuring privacy controls are built into new and existing
applications and systems, ensuring that personal data or personally identifiable
information (PII) is properly classified and protected based on corresponding IAPPs
and for providing advice on compliance with external privacy regulations, statutes,
contracts and internal policies.
! Product Line Owner (PLO) – The individual, who is the primary IT interface with the
business and is accountable for the development work getting done correctly.
! Project Manager (PM) - Is responsible for the planning, procurement and execution
of a project, in any domain of engineering. Project Managers should be certified in
PMx. PMs play different roles on whether they are supporting and Agile or Waterfall
project.
! Project Team – Comprised of the Q-CSV (for GxP projects), BUIT and IT-AS
(including SQA) software engineering personnel that have been assigned to a
software development and/or implementation project. Personnel may include
Business Analysts, Project Managers, Testers, Developers, Service Owners, Q-
CSV, SQA and other software engineering personnel needed to develop and
implement software solutions.
! Process Specialist (PS) (CPI) - Identifies the current state of processes, eliciting
their useful and harmful attributes, documenting models of the processes and
facilitating stakeholder groups to consensus regarding new business process
designs.
! Product Owner – A business representative, or their delegate, that owns the

software and drives product vision, roadmap and owns the product backlog.
! Records and Information Management (RIM) - The organization responsible for all
Records and Information Management matters. Records and Information
Management refers to a set of activities required for systematically controlling the
creation, distribution, use, maintenance, and disposition of recorded information

Confidential
SOFTWARE
CYCLE
maintained as evidence of business activities and transactions. The Records

Manager serves as the signatory for RIM.
! Regulatory Affairs (RA) – The organization that determines if an externally facing

system is considered a medical device that will be used by patients, consumers,
Health Care Providers, in order to document the respective conclusion in the

Compliance Analysis.
! Release Manager (RM) - The person responsible for release management, which is
the process of managing, planning, scheduling and controlling software build through
different stages and environments; including testing and production.
! Scrum Master (SM) - Key responsibility is to support team in outcomes of working

software from sprints as well as partnering with Product Owner and Business Analyst
to ensure ceremonies include weekly product backlog refinement to feed sprints.
! Scrum Team: Comprised of the Q-CSV (for GxP projects), BUIT and IT-AS
(including SQA) software engineering personnel that have been assigned to a
software development and/or implementation project. Personnel may include
Business Analysts, Product Owners, Testers, Scrum Masters, Developers, Q-CSV,
SQA and other software engineering personnel needed to develop and implement
software solutions,
! Service Owner – Responsible for the end-to-end delivery of the service (design,
engineering, deployment, and operations), ensures quality and timely delivery of
service to consumers, and determines functionality roadmap and milestones for the
provided service.
! Software Quality Assurance (SQA) – Independent organization ensuring that

quality is built into developed software and that it meets and complies with defined
J&J’s standards and regulations. This organization provides quality control services
(testing) and quality assurance services (verification).
! Solution Service Engineer - Responsible for platform solution design and

engineering, drive standardization and consistency of platforms deployed globally
that can meet business objectives and service levels, and drive platform solution
lifecycle
! Stage Gate Review Committee (SGRC)4 – Operates within the Records and
Information Management organization and provides additional support and guidance
4
Should not be confused with the SQA Stage Gates, which occur at key points during the SDLC process.

Confidential
SOFTWARE
CYCLE
to strengthen existing data preservation safeguards across the J&J enterprise when
decommissioning, migrating, archiving, consolidating, and/or upgrading systems
containing data subject to record retention (including regulatory compliance) or legal
hold preservation requirements. The committee consists of select members from
Information Technology, Records and Information Management, the Law
Department, and outside counsel.
! Support Team – Ensures that all service requests, incidents, problems, access
issues are addressed and resolved as per the service levels specified in the agreed
upon Service Level Agreement (SLA).
! Technical Application Owner (TAO) - The individual that manages the

development, implementation, and operation of the system from a technical
perspective, explains the technical aspects of the system to auditors and provides
input for requirements and communication planning.
! Technical Lead – Responsible for ensuring that the technical environment setup
meets the design specification and adheres to development and testing best
practices.
! Test Team – Team responsible for validating software prior to UAT to provide
stakeholders with information about the quality of the product or service under test.
Software testing can also provide an objective, independent view of the software to
allow the business to appreciate and understand the risks of software
implementation. Test techniques include the process of executing a program or
application with the intent of finding software bugs (errors or other defects). Test
team may be a member of the Scrum team.
4 References
! DOC ID – N/A Title: IAPP S-15 Worldwide System and

Application Lifecycle Security Policy
! DOC ID - TV-QTS-00018 Title: Computerized System Validation
! DOC ID - TV-SOP-13574 Title: Computer System Validation Procedure for

GxP-Regulated Applications
! DOC ID – SOP-5981 Title: SDLC Infrastructure
! DOC ID - TV-SOP-13575 Title: Risk-Based Approach to Validation

Confidential
SOFTWARE
CYCLE
! DOC ID – SOP-8190 Title: BIA Management Processes
! DOC ID – SOP-1008 Title: Disaster Recovery Planning and

Management
!
DOC ID – TV-eFRM-02062 Title: CSV Risk Assessment
5 Activity Procedure Description
Activities, or tasks, have been included in the Entry Task Validation eXit (ETVX) table
under the respective phases for Waterfall and Agile Frameworks.
Tools defined in the SDLC are not all inclusive. The SDLC only identifies tools available
enterprise-wide; tools utilized at local levels are not documented. Please see your CSV
representative or SQA analyst to confirm which local tools may be utilized for your
specific project.
6 Process Overview
This Standard Operating Procedure (SOP) describes Johnson & Johnson’s Software
Development Life Cycle (SDLC), including associated processes and requirements or
activities and deliverables. The SDLC is intended to ensure that computerized systems
are fit for intended use, meet business requirements and are compliant with applicable
regulations.

Confidential
SOFTWARE
CYCLE
6.1 Process Diagram

SDLCv8 Process
7 Software-as-a-Service (SaaS)
SaaS projects provide a different approach as the software is licensed or leased from a vendor
but the data is usually owned by the enterprise. To protect Johnson & Johnson projects, data
and applications the below depicts the validation process for a SaaS project.
For SaaS projects:

! Vendors providing SaaS applications, both GxP and non-GxP, must be audited to
assess their Quality Management System. This will verify their processes are robust,
system development processes are transparent to the project and testing that can be
leveraged. SDLC tasks that utilize Vendor processes, work instructions, standards,
template and tools must be clearly identified and approved in the Compliance Plan.
! In some instances, both the vendor and project team are responsible for tasks in a
specific SDLC Phase, such as Release Management. If this is the case, the expectation
is that SDLC process will be utilized for the non-Vendor portion of the project.
! There are SDLC tasks that must be executed using the tools and templates as identified
by the SDLC in order to be in compliance with quality and regulatory oversight.

Confidential
SOFTWARE
CYCLE
! A Business Continuity Plan at the Operating Company is recommended to address how

data may be used or viewed when the SaaS application is retired, what happens if the
vendor relationship is terminated, and a detailed plan on how the data will be migrated
from the host system to the appropriate J&J platform.
! In the case of a SaaS project, all SQA Stage Gates must be executed as defined by
the framework used – whether Waterfall or Agile.

SDLC has identified the J&J SDLC tasks that must be executed for SaaS projects in each
phase for both the Waterfall and Agile frameworks.
8 Waterfall Framework
The Waterfall Framework is a sequential design process, used in software development

processes, in which progress is seen as flowing steadily downwards (like a waterfall)
through the phases of conception, initiation, analysis, design, construction, testing,
production/implementation and maintenance. The following sections describes each of
these phases in detail covering all the tasks, deliverables, roles and responsibilities in
order to deliver the required software and associated documentation.

Confidential
SOFTWARE
CYCLE
8.1 Discovery & Initiate Phase

The purpose of this phase is to derive the initial requirements based on the analysis of the existing business processes within the boundary
defined for the business problem at hand in addition to starting the project activities. The Business Analyst works with stakeholders to draft the
initial set of requirements that will also help in performing the Compliance Analysis and Risk Assessment for the project.
Upon completion of the initial requirements, the project initiates additional project activities which include compliance analysis, compliance
planning, estimation and scheduling, resource identification, project planning, and project kick off per PMx - which is the enterprise standard for
Project Planning, Management and Monitoring.
The Product Owner (PO) is responsible to identify GxP and non-GxP requirements as per regulations applicable for the project in consultation
with CSV and ISRM teams.
No. Applicabilit Entry Tasks Verification Templates/ Exit SaaS RACIS

y Criteria Tools Criteria/ Applicabilit
Deliverable y
s R A C I S
1 Conditional5 Project Execute/ Review of Business Final Use J&J PS PO BA PM PO
Approval6 Verify Initial Business Process Business SDLC (CPI) (rRDS)
PS
Business Process Analysis Process (CPI)
Vendor
Process Analysis Template Analysis
Assessment7
Analysis Documents
Process
Modeling
Tool
2 Expected Project Case Develop Review of Case Draft Use J&J BA PO ISRM (if PM N/A
Initial Requirement Complete Requirement SDLC (rRD fully
5
The following must perform a Business Process Analysis of the existing business process; 1) all Supply Chain projects and 2) those projects whose budget is $500,000 or greater.
6
If known at this point in time.
7
Required for all SaaS and COTS projects.

Confidential
SOFTWARE
CYCLE

Deliverable y
s R A C I S
Requirement s s S) engaged
Business or 8
)
s Specification
Process
Enterprise
Analysis SQA
JIRA
Document (GxP
or and non-
GxP)
Requirement
s CSV
Specification (GxP)
Template
3 Expected Project Execute/ Review of a2 tool (Q2) Final Use J&J PO CSV ISRM PM ISRM
Case Verify Compliance Compliance SDLC (GxP (SOX,
or & non- DARM, SQA Privac
Compliance Analysis Analysis (GxP y
Draft GxP) HIPAA,
Analysis Compliance & non-
Requirement PCI, CSV
Analysis IOT, GxP)
s
Template Security) RIM
Specification
Privacy Servic
Newly e
Identified & RIM Owne
Impacted r
RA (if
System(s) engaged PO
Vendor ) (as
Assessment Autho
(for SaaS) r)
RA (if
engag
ed)
8
The Compliance Analysis and Risk Calculator will determine if stakeholders, such as ISRM, Privacy and RIM, must be fully engaged in the project.

Confidential
SOFTWARE
CYCLE

Deliverable y
s R A C I S
4a Expected Draft Execute/ Review Risk a2 tool – Risk Risk Use J&J PO PO ISRM PM PO
Requirement Verify Risk Assessment Calculator Calculator SDLC and
s Assessment Results 10 ISR
or M
Risk Data Flow
Calculator Map
Template9
Application
and Security Self-
Data Flow Assessment
Map
Template
and
Application
Security Self-
Assessment
Tool
4b Conditional Initial Execute/ Review GxP CSV Risk CSV Risk Use J&J PO PO CSV PM CSV
Business Verify GxP Risk Assessment Assessment SDLC (GxP)
Requirement Risk Assessment Template (for Report SQA
s Assessment GxP only) (GxP)
PO
5 Expected Initial Create/Verify Review a2 BIA Final Use J&J BA PO CSV PM PO

Business Business Business Business SDLC (rRD (GxP)
9
Not required for digital projects
10
Risk Calculator does not require sign-off.

Confidential
SOFTWARE
CYCLE

Deliverable y
s R A C I S
Requirement Impact Impact Impact S)
or SQA Servic
s Assessment Assessment Assessment (GxP & e
Business non- Owne
Compliance
Impact GxP) r
Analysis
Assessment
TAO
Template
6 Expected Compliance Create Review of a2 tool (Q9) Final Use J&J CSV SQA RIM (if PM ISRM
Analysis Compliance Compliance Compliance SDLC (GxP non- engaged (if
or ) GxP) ) engag
Plan Plan Plan
Initial ed)
Compliance SQA CSV Privacy
Requirement
Plan (non- (GxP) (if Privac
s GxP) engaged y (if
Template
Specification ) engag
s ed)
ISRM (if
Risk engaged CSV
Assessment ) (GxP)
PO SQA
(GxP
&
non-
GxP)
Servic
e
Owne
r
PO
7 Expected Project Case Prepare PMx Review PMx PMx Team PMx Team Use J&J PM PO N/A N/A N/A
Team Site Team Site Site Site Set-Up SDLC
Newly
Completed
Identified &

Confidential
SOFTWARE
CYCLE

Deliverable y
s R A C I S
Impacted
System(s) &
Application(s
)
8.2 Requirements & Analysis Phase

The purpose of this phase is to elicit, analyze and establish business, compliance, security and system requirements. Risks of the system
requirements are assessed. This phase also addresses management of any changes to the requirements while adhering to compliance needs
throughout the software development life cycle.
No. Applicability Entry Tasks Verification Templates/ Exit SaaS RACIS

Criteria Tools Criteria/ Applicabilit
R A C I S
Deliverable y
s
1 Expected Project Case Develop Review of Case Detailed Use J&J BA PM ISRM (if N/A PO
Detailed Detailed Complete Requirement SDLC (rRDS engage
Compliance ) d) Servi
Requirement Requirement s ce
Analysis or
s s CSV Own
Document
Enterprise (GxP) er
Risk JIRA SQA SQA
Assessment (GxP & (GxP
or
Business Non- &
Requirement GxP) non-
Process GxP)
s
Analysis
Specification CSV
Document
Template (GxP
Draft )
Requirement

Confidential
SOFTWARE
CYCLE
No. Applicability Entry Tasks Verification Templates/ Exit SaaS RACIS

Criteria Tools Criteria/ Applicabilit
R A C I S
Deliverable y
s
s
2 Expected Detailed Initiate Review Traceability Draft Use J&J BA PM CSV PO N/A
Requirement Traceability Traceability Matrix Traceability SDLC (rRDS (GxP)
s Matrix Matrix Template Matrix )
SQA
(GxP &
or
non-
HP-ALM GxP)
3 Expected Business Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA SQA Project PM N/A
Process SQA Stage Gate SDLC (GxP Team
and PO
Analysis Gate SQA Stage Assessment
non-
Document Assessment Gate Report
GxP)
Assessment
Detailed
Template
Requirement
s
Traceability
Matrix
Compliance
Plan
Risk
Assessment
8.3 Architecture & Design Phase

The purpose of this phase is to translate the functional and non-functional requirements into design specifications
(Architecture/Technical/Database Design Specifications as applicable) for the proposed solution. In this phase alternatives are assessed and
architecture is based on the final selected solution.
Confidential
SOFTWARE
CYCLE

R A C I S
Deliverable y
1 Expected Detailed Create Review of Design Design Vendor Project PM BA PO SQA
Requirement Design Design Specification Specification process Team (rRDS) (GxP
s Specification Specification Template acceptable and
Data ISRM non-
s s
Business Data Conversion/ Integration Operati GxP)
Process Conversion/ Migration development ons PO
Analysis Migration Design must use Owner
Document Design Specification SDLC
Specification
Template
2 Expected Design Update Review N/A Updated Use J&J Project PM CSV N/A N/A
Specification Traceability Traceability Draft SDLC Team (GxP)
Updating
Matrix Matrix Traceability BA SQA
Data existing
Matrix (rRDS) (GxP &
Conversion/ document
non-
Migration GxP)
Specification
3 Conditional Design Set-Up Review by As applicable Reviewed Vendor Project TAO N/A N/A TAO
Specification Development Technical Development process Team
s Environment Lead Environment acceptable
Data Integration
Conversion/ development
Migration must use
Design SDLC
Specification
4 Expected Detailed Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA SQA Project N/A N/A
Requirement SQA Stage Gate SDLC (GxP Team
SQA Stage and non-
s Gate Assessment
Gate GxP)
Assessment Report
Design Assessment

Confidential
SOFTWARE
CYCLE
Specification Template
Data
Conversion/
Migration
Design
Specification
Compliance
Plan
PMx Team
Site Setup
Draft
Traceability
Matrix
8.4 Build Phase

The purpose of this phase is to convert the design into a complete solution or set of software components either from scratch or by
customization/configuration. Activities in this phase include developing source code or configuration/customization of an off-the-shelf software
product, conducting code reviews, unit testing, data migration, and preparing the configuration control document.
No. Applicabili Entry Tasks Verification Templates/ Exit SaaS RACIS

ty Criteria Tools Criteria/ Applicabilit
Deliverable y R A C I S
s
1 Expected Detailed Perform Peer Code As applicable Reviewed Vendor Project PM N/A SQA Peer
Requirement Coding/ Review Code process Team Develo
s Development acceptable per
Code Review
Design Perform Record Integration
Specification Configuration development
s / must use
Development SDLC
Data

Confidential
SOFTWARE
CYCLE

s
Conversion/
Perform Data
Migration
Conversion/
Design
Migration
Specification
Development
Coding
(as
Standards
applicable)
2 Expected Design Create and Review Unit Testing Suite Executed Vendor Project PM N/A N/A TAO
Specification Execute Unit Test Scripts – HP ALM Unit Test process Team
s Test Scripts Scripts acceptable
or
Reviewed Track Unit Reviewed Integration
Test Script
Code Test Defects Unit Test development
Template
Defects must use
Data
Defect Form SDLC
Conversion/
Migration
Design
Specification
3 Expected Unit Test Update Draft Review Traceability Updated Use J&J Project PM CSV PM N/A
Scripts Traceability Traceability Matrix Draft SDLC Team (GxP)
Matrix Matrix Traceability SQA
or
Matrix (GxP &
HP-ALM non-
GxP)
4 Expected Unit Tested Create Review Configuration Configuration Use J&J Project PM N/A N/A SQA
Code Configuration Configuration Control Control SDLC Team (non-
Control Control Document Document GxP &
Design GxP)
Document Document Template
Specification
PO
s Software

Confidential
SOFTWARE
CYCLE

s
Configuration
Data
Management
Conversion/
Tool
Migration
Design
Specification
8.5 Test Phase

The purpose of this phase is to demonstrate that an application or set of application components fulfill their intended use and meet their
acceptance criteria when placed in their intended environment.
System testing appropriate for the project (which includes functional, system integration, performance, security, regression, data migration and
data conversion, load testing, stress testing, business simulation testing, and installation quality testing as needed) for use cases as needed.
No. Applicabi Entry Tasks Verification Templates/ Exit SaaS RACIS

lity Criteria Tools Criteria/ Applicabilit
1 Expected Design Setup Test Review by Change Reviewed Vendor Test PM N/A PO TAO
Specification Environment Technical Management Test process Team
s Lead System Environment acceptable
Raise
Data Change Change Integration
Conversion/ Control Control development
Migration must use
Design SDLC
Specification
2 Expected Test Draft Test Review Draft Test Protocol Final Test Use J&J Test PM CSV PO SQA
Environment Protocol Test Protocol Template Protocol SDLC Team (GxP) (non-
GxP

Confidential
SOFTWARE
CYCLE

and
SQA GXP
(GxP & pre-
non- UAT)
GxP)
CSV
(GxP
UAT
3 Expected Compliance Create and Review Testing Suite Executed Vendor Test PM BA PM SQA
Plan Execute System Test – HP ALM System Test process Team (rRDS) (GxP
System Test Scripts Scripts acceptable &
Final Test or ISRM non-
Scripts
Protocol Reviewed Integration GxP)
Test Script
Create Business development
Detailed Template
Business Simulation projects must
Requirement
Simulation Defect Form Test Scripts use SDLC
s
Test
Reviewed
Scripts11
System and
Track Business
System Test Simulation
Defects Test Defects
4 Conditional Detailed Create Review Templates, Reviewed Use J&J Project PO/ N/A PM CSV
Requirement Conditional Conditional as applicable Conditional SDLC Team PLO12 (GxP
s Documentati Documentati Documentati )13
CSV
on (User on (as on (GxP) SQA
Manual, applicable) (GxP
SQA
Standard &
11
For SaaS and SAP projects only at this time. No template for Business Simulation Test since it is executed is more of ad-hoc testing in nature.
12
Depending on the document, this could either be the PO or the PLO.
13
CSV requires sign-off on the following conditional deliverables for GxP projects: SOPs, WIs, GDLs.

Confidential
SOFTWARE
CYCLE

Operating (GxP & non-
Procedures non- GxP)
(SOPs), GxP)
Work
Instructions
(WIs),
Communicati
ons Plan and
other
applicable
project
assets
5 Expected Detailed Create and Review UAT Testing Suite Executed Use J&J Test PM N/A N/A CSV
Requirement Execute UAT Test Scripts – HP ALM UAT Test SDLC Team (GxP
s Test Scripts Scripts )
or
SQA
Capture UAT UAT Defects
Compliance Test Script (non-
Defects
Plan Template GxP)
Defect Form PO
Final Test
Protocol
6 Expected Executed Generate Review of Test Report Final Test Use J&J Test SQA N/A PM CSV
System Test Test Report Test Report Template Report SDLC Team (GxP & (GxP
Scripts non- )
Review of Final Post- GxP)
SQA
Executed Post Execution
CSV (non-
UAT Test Execution UAT Scripts (GxP)14 GxP)
Scripts UAT Scripts
Final Post- PO
Defect Review of Execution
14
CSV approves Data Conversion and UAT test scripts only.

Confidential
SOFTWARE
CYCLE

Report Post System Test
Execution Scripts
Final Test
System Test
Protocol
Scripts
7 Expected System Test Update Review N/A Final Use J&J Test PO Project PM PO
Scripts Traceability Traceability Traceability SDLC Team Team
Updating the SQA CSV
Matrix Matrix Matrix (non- BA (GxP
UAT Test existing
GxP) (rRDS) )
Scripts document
CSV ISRM SQA
(GxP) (GxP
&
non-
GxP)
8 Expected Design Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA N/A Project PM/ N/A
Specification SQA Stage Gate SDLC (GxP Team PO
SQA Stage and
Gate Assessment
Code Review Gate non-
Assessment Report
Records Assessment GxP)
Template
System Test
Scripts
UAT Test
Scripts
Final Defect
Forms
Compliance
Plan
Draft Test
Protocol

Confidential
SOFTWARE
CYCLE

PMx Team
Site
Draft Test
Report
Draft
Traceability
Matrix
8.6 Release & Deploy Phase

The purpose of this phase is to deliver proposed system to its end users and by doing so achieve an operational capability that satisfies the
business requirements. This phase marks the logical end of a software development project.
This phase includes development of Hypercare Transition plan; package assembled products, installation on production environment,
preparation of end user training material and knowledge transfer. This will also include the preparation of the Operations Run Book (ORB) that
will be handed over to the Application Operations team once the system goes live.

R A C I S
Deliverable y
1 Expected PMx Team Create/ Review Hypercare Hypercare Vendor Project PM N/A CSV RM
Site Update Hypercare Transition Transition process Team (GxP
Hypercare Transition Plan Plan acceptable )
Test Report
Transition Plan Template SQA
Final Defect Plan Integration (GxP
Forms development &
must use non-
SDLC GxP)

Confidential
SOFTWARE
CYCLE

2 Expected Design Create/ Review Operations Operations Vendor Project PM N/A PO RM

Specification Update Operations Run Book Run Book process Team
s Operations Run Book (ORB) (ORB) acceptable
Run Book (ORB) Template
Data Integration
(ORB)
Conversion/ development
Migration must use
Design SDLC
Specification
Configuration
Control
Document
3 Expected Hypercare Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA SQA Project PM N/A
Transition SQA Stage Gate SDLC Team
or PO
Plan Gate Assessment
Assessment SQA Stage Report
Final Defect
Gate
Forms
Assessment
Final Test Template
Report
Final
Compliance
Plan
PMx Team
Site
4 Expected SQA Stage Prepare Review Change Approved Vendor Scrum PM ISRM N/A SQA
Gate Production Change Management Change process Team (non-
Assessment Environment Control (CC) System Control (CC) acceptable GxP)
CSV
Executed Raise Post Code/Data Integration
(GxP)

Confidential
SOFTWARE
CYCLE

UAT Change Production delivered to development
RM
Control Verification production must use
SDLC PO
Verified
production
release
5 Expected Final Create Review Compliance Final Use J&J CSV PO RIM (if PM ISRM
Compliance Compliance Compliance Summary Compliance SDLC (GxP) engage (if
SQA d) engag
Plan Summary Summary Report Summary SQA (GxP ed)
Report Report Template Report (non- & non-
Stage Gate
GxP) GxP) Privac
Assessment y (if
Developed CSV engag
Code/Config (GxP) ed)
uration in CSV
production (GxP)
Loaded SQA
Data in (GxP
production & non-
GxP)
Servic
e
Owner
PO

Confidential
SOFTWARE
CYCLE
9 Agile Framework
The Agile framework is an approach for requirements and solutions to evolve through the
collaborative effort of self-organizing cross-functional teams. It promotes adaptive planning,
evolutionary development, early delivery, and continuous improvement, and it encourages rapid
and flexible response to change.

Confidential
SOFTWARE
CYCLE
9.1 Discovery & Initiate Phase

The purpose of this phase is to elicit and analyze requirements for the release. The key activity in this phase is to prepare an initial product
backlog in consultation with Product Owner. During Product Backlog prioritization of the Product Backlog from the business perspective is
performed.
The purpose of this phase is to assess compliance applicability, assess risks of the business requirements and prepare the Compliance Plan.
The product owner is responsible to identify GxP and non-GxP requirements as per regulations applicable for the project in consultation with Q-
CSV, Privacy, Records Information Management and ISRM teams.

R A C I S
Deliverable y
1 Conditional15 Project Execute/ Review of Business Final Use J&J PS PO BA PM PS

Approval 16 Verify Initial Business Process Business SDLC (CPI) (rRDS)
SM
(CPI)
Business Process Analysis Process PO
Vendor
Process Analysis Template Analysis
Assessment
17 Analysis Documents
Process
Modeling
Tool
2 Expected Project Develop Initial Review Case Initial Use J&J BA PO SQA PM N/A
Case Product Product Complete Product SDLC (rRDS) (GxP
and non- SM
Backlog Backlog Backlog
Business or GxP)
15
The following must execute a Business Process Analysis of the existing business process; 1) all Supply Chain projects and 2) those projects whose budget is $500,000 or greater.
16
If known at this point in time.
17
Required for all SaaS and COTS projects.

Confidential
SOFTWARE
CYCLE

Process
CSV
Analysis (GxP
Enterprise
Document only)
JIRA
Project BA
Case Or (rRDS)
Newly
Requirement
Identified &
s
Impacted
Specification
System(s)/A
Template
pplication(s)
3 Expected Project Prepare PMx Review PMx PMx Team PMx Team Use J&J PM PO N/A N/A N/A
Case Team Site Team Site Site Site Setup SDLC
Completed
Newly
Identified &
Impacted
System(s)/A
pplication(s)
4 Expected Project Execute/ Review of a2 tool (Q2) Final Use J&J PO CSV ISRM PM/ Privac
Case Verify Compliance Compliance SDLC (GxP (SOX, SM y
or & non- DARM,
Compliance Analysis Analysis SQA ISRM
GxP) HIPAA,
Initial Analysis Compliance (GxP
PCI, RIM
Product Analysis IOT, &
Backlog Template Security) non- CSV
GxP)
Privacy RA (if
(if engag
engage) ed)
RIM Servic

Confidential
SOFTWARE
CYCLE

e
RA (if Owner
engaged
) PO (as
author)
5a Expected Initial Execute/ Review Risk a2 tool – Risk Use J&J PO and PO ISRM PM PO
Product Verify Risk Assessment Risk Calculator SDLC ISRM
Backlog Assessment Calculator Results19
or Data Flow
Map
Risk
Calculator Application
Template18 Security Self-
Assessment
and
Data Flow
Map
Template
and
Application
Security Self-
Assessment
Tool
5b Conditional Initial Execute/ Review GxP CSV Risk CSV Risk Use J&J PO PO CSV PM CSV
Product Verify GxP Risk Assessment Assessment SDLC (GxP)
Backlog Risk Assessment Template Report SQA
18
Not required for digital projects.
19
Risk Calculator does not require sign-off.

Confidential
SOFTWARE
CYCLE

Assessment (GxP) (GxP)

PO
6 Expected Initial Create/Verify Review a2 BIA Final Use J&J BA PO CSV PM PO

Product Business Business Business SDLC (rRDS) (GxP)
or Servic
Backlog Impact Impact Impact SQA e
Assessment Assessment Business Assessment (GxP & Owner
Compliance
Impact non-
Analysis GxP)
Assessment
Template TAO
7 Expected Initial Create Review a2 tool (Q9) Final Use J&J CSV SQA RIM (if PM ISRM
Product Compliance Compliance Compliance SDLC (GxP) (non- engaged (if
or GxP) ) SM engag
Backlog Plan Plan Plan SQA ed)
Compliance (non- CSV Privacy
Compliance
Plan GXP) (GxP) (if Privac
Analysis engaged y (if
Template
Document ) engag
ed)
ISRM (if
engaged CSV
) (GxP)
PO SQA –
(GxP &
non-
GxP)
Servic
e
Owner
PO

Confidential
SOFTWARE
CYCLE
9.2 Plan & Readiness Phase

The purpose of this phase involves preparation to begin Agile Development; Release plan, Sprint plan, and refined product backlog are
prepared based on the business requirements. This phase also includes identification of controls - Definition of Done (DoD) and Definition of
Ready (DoR) as decided by the Scrum team.
The Product Owner determines acceptance criteria of a minimum viable product for each release. During sprint planning, identification and
grooming of user stories are done for the upcoming sprint.
The Traceability Matrix must be prepared to show the linkage between business process and user stories, test scripts and any other constructs
as applicable.

s
1 Expected Compliance Perform Review JIRA Release Use J&J PM PO SM RM N/A
Plan Release Release Plan SDLC
Planning Plan
Initial
Product
Backlog
2 Expected Initial Groom Review Case Sprint Use J&J BA PO ISRM PM PO

Product Detailed Product Complete Backlog SDLC (rRDS) (if
engage SM Servic
Backlog User Stories Backlog and e
or d)
User Stories Owner
Compliance
JIRA CSV
Plan (GxP) SQA
or (GxP
SQA & non-
Requirement (GxP & GxP)
s Template Non-
GxP) CSV
(GxP)

Confidential
SOFTWARE
CYCLE

s
Scrum
Team
3 Expected Detailed Draft Review of HP-ALM Draft Use J&J BA PO CSV PM N/A
Product Traceability Traceability Traceability SDLC (rRDS) (GxP)
or SM
Backlog Matrix Matrix Matrix SQA
Traceability (GxP &
Matrix non-
Template GxP)
4 Expected Compliance Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA SQA Scrum PO N/A
Analysis SQA Stage Gate SDLC (GxP & (GxP & Team
or non- non-
Gate Assessment PM
GxP) GxP)
Compliance Assessment SQA Stage Report
Plan SM
Gate
Assessment
Template
Detailed
Product &
Sprint
Backlog
Business
Process
Analysis
Documents
CSV Risk
Assessment
(GxP)
Draft

Confidential
SOFTWARE
CYCLE

s
Traceability
Matrix
9.3 Development & Test Phase

The purpose of this phase is to implement user stories, drive each story towards DoD at the end of each sprint. The sprint may result in a
Minimum Viable Product (MVP). The scrum team is responsible to analyze, design, build and unit test each user story in the sprint backlog.
System testing appropriate for the project (which includes functional, system, integration, performance, security, regression, data migration and
data conversion, load testing, stress testing, business simulation, and installation quality testing as needed) for user stories executed in the
sprint backlog is performed as needed. If there are any changes made to the user stories during the sprint then they must be added to the
product backlog to assess for impact, prioritization, test and must be traceable to the original user story.

R A C I S
Deliverable y
1 Expected Sprint Perform Peer Code Code Reviewed Use J&J Scrum PO N/A SQA Scrum
Backlog Coding/Deve Review Review Code SDLC Team Team
lopment Record Peer
Code
Coding Template
Review
Standards
Record
and Best
Practices

Confidential
SOFTWARE
CYCLE

2 Expected Sprint Draft Test N/A Test Protocol Final Test Vendor Test PO CSV PM SQA
Backlog Protocol20 Template Protocol process Team (GxP
SM
(non-
acceptable UAT GxP
only) and
Integration GxP
SQA pre-
development (GxP &
must use UAT)
non-
SDLC GxP) CSV
(GxP
UAT)
3 Expected Design Setup Test Review by Change Reviewed Vendor Test TAO N/A PM TAO
Specification Environment Technical Management Test process Team
SM
Lead System Environment acceptable
Data Raise
Conversion/ Change Updated/ Integration
Migration Control New Code development
Design must use
Approved
Specification SDLC
Change
Control
4 Expected Reviewed Create and Review Unit Testing Suite Executed Vendor Scrum SQA ISRM PM N/A
Code Execute Unit Test Scripts – HP ALM Unit Test process Team (GxP & (if
non- engage SM
Test Scripts Scripts acceptable
Sprint or GxP) d)
Backlog Integration
Test Script PO
development
Template
must use
or SDLC
JIRA
20
For GxP projects, a separate Test Protocol must be created for UAT - see Computer System Validation Procedures for GxP Regulated Applications for details. For non-GxP projects, a single
Test Protocol may be developed covering both pre-UAT and UAT.

Confidential
SOFTWARE
CYCLE

5 Expected Sprint Create and Review Testing Suite Executed Vendor Test PO N/A PM/ SQA
Backlog Execute System – HP ALM System Test process Team SM (GxP &
System Test Tests Scripts acceptable22 non-
Unit Test or GxP)
Scripts
Scripts Reviewed Integration
Test Script
Create System and development
Final Test Template
Business BST Test must use
Protocol
Simulation Defect Form Defects SDLC
Compliance Test Scripts
21
Plan
Track
System Test
Defects
6 Conditional23 Sprint Create and Review UAT Testing Suite Executed Use J&J PO PO Test PM CSV
Backlog Execute UAT Tests – HP ALM UAT Test SDLC Team (GxP)
SM
Test Scripts Scripts SQA
Compliance or
(non-
Plan Track UAT Final Test
Test Script GxP)
Test Defects Protocol
Final Test Template PO
Protocol Reviewed
Defect Form
UAT Test
Defects
7 Expected Executed Create Test Review Test Test Report Final Test Use J&J Test PO ISRM PM PO
System Test Report24 Report Template Report SDLC Team
21
For SaaS and SAP projects only at this time. No template for Business Simulation Test since it is executed is more of ad-hoc testing in nature.
22
Vendor process is not applicable for Business Simulation Testing. (BST).BST must be executed within the J&J firewall.
23
UAT is Conditional to support projects where business resources cannot support every sprint. A UAT must be executed for the release if not executed in the sprint.

Confidential
SOFTWARE
CYCLE

Scripts
CSV SM CSV
Executed (GxP) (GxP)
UAT Test SQA SQA
Scripts (GxP & (non-
non- GxP)
Defect GxP)
Forms
Final Test
Protocol
8 Expected Sprint Update Review of Traceability Final Use J&J Scrum PO N/A PM PO
Backlog Traceability Traceability Matrix Traceability SDLC Team
SM CSV
Matrix Matrix Template Matrix BA (GxP)
Executed (rRDS)
or SQA
System and
Test (GxP &
UAT Test HP-ALM Team non-
Scripts GxP)
Draft
Traceability
Matrix
9 Expected Tested Code Create Review Configuratio Configuratio Use J&J Scrum PO N/A PM SQA
Configuratio Configuratio n Control n Control SDLC Team (non-
SM GxP &
Data n Control n Control Document Document
GxP)
Conversion Document Document Template
or Migration PO
Software
Design
Configuratio
Specification
n
Management
24
For GxP projects, a separate Test Report must be created for UAT. For non-GxP projects, both System and UAT test results may be contained in a single Test Report.

Confidential
SOFTWARE
CYCLE

Tool
9.4 Sprint Review Phase

The purpose of this phase is to ensure the minimum viable product is developed based on Definition of Done (DoD), collect the product demo
feedback and perform sprint retrospective.
Sprint retrospective is performed to identify good practices and potential improvements. If the improvements result in new user stories they
must be added to the product backlog and addressed in subsequent sprints.

s
1 Expected Reviewed Perform Sprint As Review Vendor Scrum PO N/A PM N/A
and Tested Sprint Review applicable Feedback process Team
ISRM
Code Review (demo) acceptable (where
Product
(demo) Witnessed engage
Increment Integration
Sprint d)
development
Backlog
must use CSV
SDLC (GxP)
SQA
(GxP &
non-
GxP)
2 Expected Demo Conduct Review of Happiness Happiness Vendor Scrum PO N/A N/A SM
Feedback Sprint Happiness Metric Tool Metrics process Team
Retrospectiv Metrics acceptable PM
Confluence - Completed

Confidential
SOFTWARE
CYCLE

s
e Meeting Sprint Sprint
Integration SM
Retrospectiv Retrospectiv
development
e Template e
must use
SDLC
3 Conditional25 Review Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA SQA Scrum PO N/A
Feedback SQA Stage Gate SDLC (GxP Team
or and
Gate Assessment PM
Sprint non-
Assessment SQA Stage Report
Backlog GxP) SM
Gate
Final Test Assessment
Protocol Template
Final
Traceability
Matrix
Final Test
Report
9.5 Release & Deploy Phase

The purpose of this phase is to deliver proposed system to its end users and by doing so achieve an operational capability that satisfies the
business requirements. Release retrospective is performed to identify good practices and potential improvements for the next release.
This phase includes development of Hypercare Transition Plan; package assembled products, installation on production environment,
preparation of end-user training material and knowledge transfer.
25
SQA Stage Gate Assessment is not mandatory for every Sprint and is up to the SQA resource to determine which sprint should execute the assessment. Ideally a SQA Stage Gate Assessment
should occur every 3-4 sprints.

Confidential
SOFTWARE
CYCLE

R A C I S
Deliverable y
1 Conditional Detailed Create Review As Conditional Use J&J As PO BA PM CSV 26
Product Conditional Conditional applicable Documentati SDLC determi (rRDS) (GxP )
Backlog Documentati Documentati on ned by SM
PO SQA
on User on (GxP &
Manual, CSV non-
Standard (GxP) GxP)
Operating
Procedures
(SOP), Work
Instructions
(WI),
Communicat
ion Plan, etc.
2 Expected Sprint Create and Review UAT Test Script Final UAT Use J&J Scrum PO BA PM CSV
Backlog(s) Execute Test Scripts Template Test Scripts SDLC Team (rRDS) (GxP)
SM
UAT Test SQA
Final Test or Reviewed
Scripts (non
Protocol UAT Defects
Test Suite – GxP)
Track UAT
HP ALM
Test Defects
3 Expected Executed Update Review Traceability Final Use J&J Scrum PO N/A PM PO
UAT Test Traceability Traceability Matrix Traceability SDLC Team
SM CSV
Scripts Matrix Matrix Template Matrix BA (GxP)
(rRDS)
or SQA
Test (GxP &
HP-ALM Team non-
GxP)
26
CSV must sign-off on the following conditional deliverables for GxP projects: SOPs, WIs, GDLs.

Confidential
SOFTWARE
CYCLE

4 Expected Executed Generate Review of Test Report Final Post- Use J&J CSV PO N/A PM PO
UAT Test Test Test Report Template Execution SDLC (GxP)
SM CSV
Scripts Report27 UAT Scripts SQA (GxP)
(non- Test
Review of Final Test Team SQA
UAT
Post- Report GxP (non-
Execution and GxP)
UAT Scripts non-
GxP)
5 Expected PMx Team Create/ Review Hypercare Hypercare Vendor Scrum PO SQA PM RM
Site Update Hypercare Transition Transition process Team (GxP &
non- SM
Hypercare Transition Plan Plan acceptable
Test Report GxP) CSV
Transition Plan Template
Integration (GxP)
Final Defect Plan
development
Forms SQA
must use
(GxP &
SDLC non-
GxP)
6 Expected Sprint Create/ Review Operations Operations Vendor Scrum PO N/A PM RM

Backlog Update Operations Run Book Run Book process Team
RM
Operations Run Book (ORB) (ORB) acceptable
Configuratio CSV
Run Book (ORB) Template
n Control Integration (GxP)
(ORB)
Document development
SQA
must use
(GxP &
SDLC non-
GxP)
7 Expected Release Conduct N/A a2 tool (QP1) SQA Stage Use J&J SQA SQA N/A PO N/A
27
The Test Report should be generated at this point-in-time if the UAT has been conducted in the Sprint.

Confidential
SOFTWARE
CYCLE

Plan SQA Stage Gate SDLC
SQA Stage PM
Gate Assessment
Operations Gate SM
Assessment Report
Run Book Assessment
Template
Hypercare
Transition
Plan
Final Test
Protocol
Final Test
Report
Final
Traceability
Matrix
Final Defect
Report
8 Expected SQA Stage Prepare Review Change Approved Vendor Scrum PO ISRM N/A SQA
Gate Production Change Managemen Change process Team (non-
RM GxP)
Assessment Environment Control (CC) t System Control (CC) acceptable
CSV
Executed Raise Post Code/Data Integration
(GxP)
UAT Change Production delivered to development
Control Verification production must use PM
SDLC PO
Verified
production
release
9 Expected Compliance Create Review Compliance Final Use J&J CSV PO RIM (if PM ISRM
Plan Compliance Compliance Summary Compliance SDLC (GxP) engage (if
SQA d) engage
Summary Summary Report Summary SQA (GxP &
Final Test d)

Confidential
SOFTWARE
CYCLE

Protocol Report Report Template Report (non- non-
GxP) GxP) Privacy
SQA Stage (if
Gate CSV engage
d)
Assessment (GxP)
CSV
Developed (GxP)
Code/Config
uration in SQA –
production (GxP &
non-
Loaded GxP)
Data in Service
production (if Owner
applicable)
PO
10 Operate Phase – Agile and Waterfall Frameworks
The purpose of this phase is to ensure that the Application Services team and specifically the Operations staff are equipped with the
information required to perform day-to-day operations and to respond to emergency situations or any event that effects the application
or system. The same process is applicable for both the Waterfall and Agile frameworks.
No. Applicabilit Entry Tasks Verification Template/ Exit SaaS RACIS

1 Expected Hypercare Report Service ISM Tools Service Vendor Suppor Operati N/A PLO Operati
Transition Against Managemen Managemen process t Team ons ons
Reporting Owner PO Owner
Plan Service t Reviews t Reporting acceptable

Confidential
SOFTWARE
CYCLE

Levels Tools
Operations
Run Book
(ORB)
2 Expected Incident Manage User ISM Tool Resolved Vendor Suppor Operati N/A Team Operati
Incidents Confirmation Incidents process t Team ons ons
Operations Owner PLO Owner
acceptable
Run Book Raised PO
(ORB) Problem
Records
ISM SOP/WI
Satisfaction
Feedback
3 Expected Raised Manage User ISM Tool Resolved Vendor Suppor Operati N/A Team Operati
Problem Problems /System/ Problems process t Team ons ons
Records Vendor acceptable Owner Owner
Request for
Confirmation
ISM SOP/WI Changes
Workaround
s and Known
Errors
Reports and
Improvemen
t
Recommend
ations
4 Expected Service Manage User ISM Tool Fulfilled Vendor Suppor Operati N/A Project Operati
Requests Service Confirmation Service process t Team ons Team ons
Requests Requests acceptable Owner Owner
RFC/
Standard

Confidential
SOFTWARE
CYCLE

Changes
5 Expected Operational Manage As As Communicat Vendor Suppor Operati N/A PO Operati

Alerts Events applicable applicable ed and process t Team ons ons
Escalated acceptable Owner owner
Hypercare
Events
Transition
Plan Event Logs
Operations Indication of
Run Book completenes
(ORB) s of support
activities
6 Expected Information Access User ISM Tool Provision of Vendor Suppor Operati N/A PO Operati
Security Managemen Confirmation Access to IT process t Team ons ons
Policies t Services acceptable Owner Owner
Hypercare Records &

Transition History of
Plan access
granted /
Authorized
denied
Requests
7 Expected Completed Raise Review Change Approved Vendor Project CSV Suppor PO CSV
System Change Change Managemen Change process Team (GxP) t Team (GxP)
Assets Control (CC) Control (CC) t System Control (CC) acceptable Operati
ons
Owner
8 Conditional Service Continual As applicable As Service Vendor Suppor Operati N/A Team Operati
Reporting Service applicable Improvemen process t Team ons ons
Owner PO Owner

Confidential
SOFTWARE
CYCLE

Improvemen t Register acceptable
Proposed
t
Problem
Resolutions
and
Proactive
Measures
Service
Managemen
t Knowledge
Repository
Achievement
s against
metrics,
KPIs and
CSFs
9 Conditional Operations Update Review N/A Updated Vendor Support Operati N/A PLO Operati
Run Book Service Updated Hypercare process Team ons ons
Updating PO
(ORB) Levels Hypercare Transition acceptable Owner Owner
existing
Hypercare Transition Plan
document
Transition Plan
Plan
Changing
Business
Needs

Confidential
SOFTWARE
CYCLE

10 Expected Traceability Maintain Review N/A Final Use J&J Project CSV N/A PO CSV
Matrix Traceability Traceability Traceability SDLCv8 Team (GxP) (GxP)
Matrix28 Matrix Matrix SQA SQA
(non- (non-
GxP) GxP)
11 Archive & Retirement Phase – Agile and Waterfall Frameworks
This phase addresses the process of archiving data and retiring the system once it has been decided to decommission the system. A
determination of Record Retention requirements and Legal Hold is completed.
The same process is applicable for both the Waterfall and Agile frameworks.

R A C I S
Deliverable y
1 Expected Decision Enter N/A Enterprise Decommissi Use J&J TAO PO N/A OPCx PO
to Disposition Architecture on Date and SDLC Cloud
Decommi (Retirement) Tool Disposition Factory
Service
ssion and and (MEGA)
s
/or Decommission
Archive Date
2 Conditional Decommi Perform Stage Stage Gate Standardize Stage Gate Use J&J TAO SGRC N/A OPCx SGRC
ssion Gate Review Review d Stage Review SDLC Cloud
28
Application Traceability Matrix should be reviewed quarterly to ensure requirements are in alignment with the product.

Confidential
SOFTWARE
CYCLE

Date and Committee Committee Gate Review Committee Factory
SGRC
Dispositio Review (SGRC) Committee Authorizatio service
n Communicat n s
Decommission
ion Communicat Applica
Details
ion tion
Suppor
t–
Archivi
ng
Service
s
3 Expected Stage Develop Review of Retirement Retirement Use J&J TAO PO Project OPCx PO
Gate Retirement Retirement Plan Plan SDLC Team Cloud
CSV Factory CSV
Review Plan Plan Template Verification (GxP) RIM Service (GxP)
Committe of Legal SQA s SQA
e (SGRC) Hold (non- Applica (non-
Authorizat GxP) tion GxP)
Verification if
ion Archive is Suppor RIM
t–
Required Archivi
ng
Service
s
4 Conditional Stage Develop Review Retirement Archive Use J&J TAO PO Project OPCx PO
Gate Archive Plan Archive Plan Plan Plan SDLC Team Cloud
Factory CSV
Review Template29 Service (GxP)
Committe s SQA
29
The Retirement Plan Template will be used to support the Archive Plan.

Confidential
SOFTWARE
CYCLE

e (non-
Applica GxP)
Authorizat tion
ion Suppor
t–
Retiremen Archivi
t Plan ng
Service
Verificatio s
n of Legal
Hold
5 Conditional Archive Execute Data Completed/R IRIS Verified Vendor Applica CSV N/A OPCx CSV
Plan Archive eviewed Archived process tion (GxP) Cloud (GxP)
Data acceptable Suppor Factory
Change t– SQA Service SQA
Request Archivi (non- s (non-
ng GxP) GxP)
Post Service PO PO
Migration s
Verification
6 Expected Retiremen Execute Completed/R IRIS Decommissi Vendor OPCx TAO N/A Applica TAO
t Plan System eviewed oned process Cloud tion
System no System acceptable Factory Suppor
Decommission Change Service t–
Archive longer
Request Close Integration s Archivi
Plan available in ng
Decommissi development
network oning must use Service
Change
Change SDLC s
Control
Control (CC)
(CC)
Notification
to BUIT

Confidential
SOFTWARE
CYCLE

7 Expected Archive Verify Archive Review of Retirement Final Archive Vendor TAO CSV N/A N/A CSV
Plan Results Archive Report Report process (GxP) (GxP)
Report Template30 acceptable SQA SQA
Archived Create Archive (non- (non-
Integration
Data Report GxP) GxP)
development
must use PO PO
SDLCv8
8 Expected Retiremen Verify Review of Retirement Final Vendor TAO CSV RIM N/A CSV
t Plan Decommission Retirement Report Retirement process (GxP) (GxP)
Results Report Template Report acceptable SQA SQA
Decommi (non- (non-
Integration
ssioned Create GxP) GxP)
development
Software Retirement must use PO PO
Report SDLCv8
30
The Retirement Report Template will be used for the Archive Report.

Confidential
SOP-1705 SOFTWARE DEVELOPMENT LIFE CYCLE Version 14.0
12 Document History
12.1 Superseded Document(s)

! Doc ID: – N/A Title: N/A Effective Date: N/A
12.2 Revision History

Major/Minor
Version DD-MM-YYYY Author Change Summary Change
14.0 17-Oct-2017 Deborah Added language to clarify that tools cited in Minor
Lang this document via the ETVX matrices are
not all inclusive, however, represent
enterprise-wide tools. Project Teams
should reach out to their CSV
representative or SQA analyst for guidance
on what tools may be utilized locally.
13.0 24-Apr-2017 Deborah Version 12.0 was never made public as a Major
Lang last minute correction from ISRM on their
new Risk Assessment deliverables and
signatories was required. Version 13.0
contains all the changes made in 12.0.
Changes:
Waterfall: 8.1 Discovery & Initiate –
broke out Risk Assessment task (Task 4)
into 2 parts (Task 4a and Task 4b) to
correct and clarify signatories on GxP and
non-GxP Risk Assessment deliverables.
Agile: 9.2 Discovery & Initiate - Broke
out Risk Assessment task (Task 5) into 2
parts (Task 5a and Task 5b) to correct and
clarify signatories on GxP and non-GxP
Risk Assessment deliverables.
12.0 19-Apr-2017 Deborah General: Major
Lang ! Corrected typos; verifed ETVX matrix
for consistent template names.
! Corrected and verified RACIs
throughout the document
! Added new colum in RACIs to include
signatories.
Updated Section 2: Scope to claify
mobile applications are included.
Changes to Section 3.1 Terms: and
Acronyms :

Confidential
Major/Minor
Changes to Section 3.2: Role

Descriptions:
Updated Framework Diagrams for both
Agile and Waterfall.
Changes to Section 8: Waterfall ETVX
tables Section 8.1:

Changes to Section 9: Agile ETVX tables
Changes to Section 10: Operations:
ETVX tables
Changes to Section 11: Archive &
Retirement ETVX tables
11.0 21-Nov-2016 Deborah General : Major
Lang • SOP consolidated to include
Waterfall and Agile Framework
Section 2 (Scope)
Out of Scope:
• Software as Medical Devices
(SaMD) projects; and
• Infrastructure projects.
Section 3.1 (Terms and Acronyms)
• Inludes the definition of terms used
across the document. No separate
glossary document
Section 3.2: (Role Descriptions)
• Includes the description of each of
the Roles played by an individual
or a department in the SOP under
Waterfall and Agile Framework
across all the phases
Section 6.1 (Process Diagram)
• Process diagram for Waterfall and
Agile Framework included
Section 7 – SaaS
• Overview on Software-as-a-
Service projects.
Section 8 (Waterfall Framework)

• Described in detail with an ETVX
table and RACI matrix for all the 6

Confidential
Major/Minor
phases
Section 8 (Agile Framework)
• Described in detail with an ETVX
and RACI for all the 5 phases
Section 9 (Operate Phase – Agile and
Waterfall Frameworks)
• ETVX and RACI matrix created
that is applicable for both Waterfall
and Agile Frameworks
Section 10 (Archive and Retirement
Phase – Waterfall and Agile
Frameworks)
• ETVX and RACI matrix created
that is applicable to both Waterfall
and Agile Frameworks
10.0 12-Nov-2015 Rathnakar General: Major
Raghunat • Changed “Systems Development
h Life Cycle” to “Software
Development Life Cycle” in the
term
• Renamed Application track to
Waterfall track
• Updated content across the
document to reflect removal of
infrastructure from SDLC
Section 2 (Scope):
• Updated Scope section to remove
infrastructure
Section 5.1 (SDLC Archtecture):
• Updated the Waterfall and Agile
phases in the SDLC Architecture
diagram
• Removed Project Management
track
• Removed Application category-
based tailoring section from the
diagram
Section 5.4 Tailoring
• Updated the section to make it
generic so that it applies to both
Waterfall and Agile implementation
tracks

Confidential
Major/Minor
9.0 25-Feb-2015 Andre Section 2 (Scope): Major

Salomon • Reinforced the types that digital
assets can fall into: non-regulated,
regulated, medical devices.
• Added “Medical Devices” as out of
scope.
• Clarified the concept of Mobile
Medical Applications (“mobile apps
that fall into the category of
Medical Device”).
Section 2.1 (SDLC Guidelines)
• Now clearly defines that:
− the Compliance / Validation
lead role is accountable for
the assessment of GxP
applicability and must be
assigned to Quality CSV / Q-
CSV CoE or it can be
delegated to IT Risk
Assurance when applicable.
− IT Risk Assurance is
accountable for the
assessment of SOx, Privacy
and DARM and for ensuring
the project team follows the
applicable compliance
requirements.
Section 4 (References)
• Added a new reference to the
document DS-STA-2018 (Mobile
Medical Applications).
Section 5.1 (SDLC Architecture)
• Updated the diagram to reflect
changes introduced by SDLC 7
Agile.
Section 5.5 (Development Phases of
SDLC)
• Updated the Agile phases.
8.0 07-May-2014 Rathnakar Section 2 Scope updated to Major
Raghunat ! Add Mobile Medical Applications
h under Out of Scope
! Revise in-scope and out of scope
for IT Infrastructure

Confidential
Major/Minor
Section 2.1
! Statement in bullet # 2 rephrased
to clarify that the term “risk
management” is intended be an
activity and does not refer to a role
! In bullet # 3 the role “Quality

Assurance” is replaced with
“Compliance/ Validation Lead”
! In bullet # 16 a statement added to
indicate that supplier assessment
will be conducted based on the
procedure of the respective
operating company
! Bullet # 17 updated to include
“conducting” of training along with
developing
Section 3.2 rephrased to consolidate roles
& responsibilities and roles matrix
summary together
Section 4 References updated to remove a
separate reference to Roles Matrix as this
is included within the Roles and
Responsibilities guideline
Section 5.6.2 updated to refer to WWRIM
System Decommissioning Standard
Section 6.3 updated to address SDLC in-
flight projects for revised SDLC Assets
7.0 26-Jul-2013 Andre Updated Section 4: Included references to Minor

the WI-5982 (System Development Life
Salomon
Cycle Governance) and GDL-6077
(Testing Type Guideline)
6.0 17-May-2013 Andre Updated Section 4: Included reference to Minor
the GDL-1545 (Identifying Project Work
Salomon
Products).
5.0 15-Mar-2013 Linda Updated Section 3.1 Terms – changed Minor
Johnson and Johnson to Johnson &
Andel
Johnson
Updated Section 5 to include (SDLC) after

The Systems Development Life Cycle

Confidential
Major/Minor
4.0 14-Sep-2012 Linda Updated entire document to align to SDLC Major

release 6.
Andel
Changed from an SOP about work product
management and focused the SOP on
what an SDLC is and the overall life cycle
activities
Removed all appendices

3.0 06-Apr-2012 James Updated URS appendix to clarify language Minor
around capturing user requirements with
Gunning
out of the box solutions
2.0 03-Oct-2011 Naveen Updated Scope section to add new Major
applications and examples that are
Chamakur
considered In Scope and Out Scope.
Added instructions on the usage of
Automated Tools.
Updated Terms and Acronyms section to

update the definition of Compliance Plan.
Updated Create/Update Work Product

Activity description table to add SDLC
template usage instructions.
Updated Appendix A: Compliance Analysis

to align with the Compliance Analysis
template harmonization changes.
Following are the key changes:
! Added instructions on when
Compliance Analysis can be
revised
! Added the IT Application Owner
and Records Manager role which
are mandatory to sign-off the
Compliance Analysis
! Removed reference to Business
Criticality assessment
! Added Assessment questions for
Privacy and Records Management
Updated Appendix B: Compliance Plan to

align with the Compliance Plan template
harmonization changes. Following are the
key changes:
! Added additional instructions to
describe potential risks during
FMEA Risk Assessment and
Project Risk Assessment

Confidential
Major/Minor
! Renamed ‘Compliance
Deliverables’ to ‘Deliverables’
! Moved the Acceptance Criteria
section after the Procedures To Be
Developed/Modified section
! Updated instructions in the
Procedures to be
Developed/Modified section to
include examples of
topics/functions that should be
included in procedures. Updated
instructions to require listing
procedures that must be
modified/updated as part of the
project, as applicable.
! Section on Contingency Planning
has been deleted and added to the
Project Management Plan
template.
Updated Appendix C: User Requirements

Specification to add instructions to
mandate all configurable, customizable
and out-of-box functionality is documented
in the User Requirements Specification.
Updated Appendix G: Functional

Specification to add instructions to
mandate all configurable and customizable
functionality is documented in the
Functional Specification. Throughout this
appendix any reference to an individual
Functional Specification (FS) is renamed to
Functional Requirement (FR).
Updated Appendix R: Test Defect Log and

Test Defect Report to replace all
references of the term Deviation with
Defect.
Updated Appendix S: System Test

Protocol to align with the System/UAT Test
Protocol template harmonization changes.
Updated Appendix T: System Test Report

to align with the System/UAT Test Report
template harmonization changes.

Confidential
Major/Minor
Updated Appendix U: User Acceptance
Test Protocol to align with the System/UAT
Test Protocol template harmonization
changes. Removed references to
Installation activity.
Updated Appendix V: User Acceptance

Test Report to align with the System/UAT
Test Report template harmonization
changes.
Updated Appendix AB: Retirement Plan to

add Business Owner, Records Manager
(Operating Company), Business Unit
Quality Lead roles.
Also deleted references to the following
compliance activities as some of them are
no referenced in SDLC - Original
compliance deliverables, User Notification,
Support Resource Notifications, System
Interfaces, Access Restrictions,
Documentation/Procedures, Maintenance,
Long Term Data Storage, Archival and
Retrieval, Migration, Removing system
from PC’s, SMS packages, Removal of
application software and files from servers
that the system no longer exists on JJNET
and Update System Inventory.
Updated Appendix AC: Retirement Report
to add Business Owner, Records Manager
(Operating Company), Business Unit
Quality Lead roles.
Also deleted references to the following
compliance activities as some of them are
no referenced in SDLC - Original
compliance deliverables, User Notification,
Support Resource Notifications, System
Interfaces, Access Restrictions,
Documentation/Procedures, Maintenance,
Long Term Data Storage, Archival and
Retrieval, Migration, Removing system
from PC’s, SMS packages, Removal of
application software and files from servers
that the system no longer exists on JJNET
and Update System Inventory.
Deleted Appendix AH: Business Continuity

& Recovery Risk Acceptance and

Confidential
Major/Minor
Appendix AI: Business Impact
Assessment. Created a new Appendix AH:
Business Continuity Assessment.
Updated Appendix AJ: Detailed

Requirements Specification to add
instructions to mandate all configurable,

customizable and out-of-box functionality is
documented in the Detailed Requirements
Specification.
Updated Appendix AK: Functional

Infrastructure Specifications to add
instructions to mandate all configurable
and customizable functionality is
documented in the Functional
Infrastructure Specification. Throughout
this appendix any reference to an
individual Functional Specification (FS) is
renamed to Functional Requirement (FR).
Replaced ‘Technical Architecture SME’
with Solution Architect.
Updated Appendix AL: Infrastructure

Detailed Design to replace ‘Technical
Architecture SME’ with Solution Architect.
Updated Appendix AM: Infrastructure
Qualification Pre-Approval to replace the
title Infrastructure Qualification Pre-
Approval with new title Infrastructure
Qualification Master Template 1 (Pre-
Approval).
Updated Appendix AN: Infrastructure
Qualification to replace the title
Infrastructure Qualification with new title
Infrastructure Qualification Master
Template 2.
Updated Appendix AU: Master Test Plan to
describe the procedure to create Master
Test Plan.
Updated Appendix AV: Worktype Exit
Review Checklist to describe the
procedure to complete a Worktype Exit
Review Checklist for a project.
1.0 07-Feb-2011 Kausik Document created. Major

Following changes are made for SDLC
Bhattach Release 4.0.

Confidential
Major/Minor
arya Section 3.1 Terms and Acronyms:

Changed the words from critically to
criticality and guidance to guidelines
Appendix B: Replaced the role from Test
Lead to Compliance/Validation Lead
Appendix E: Added Functional
Specifications as an input
Replaced the word Technology Roadmap
by "Architecture Standards and Strategies
(Refer to the link for more details
http://it.jnj.com/standards/Pages/Architectu
reStandardsStrategies.aspx)" in the step
"Develop Computerized System
Architecture"
Replaced the word "Deliverables of the
Architecture Design" to "Architecture
Design Document". Also removed the term
Quality Guidelines and replaced by
"document meets all the requirements of
Architecture Design needs"
Appendix F: Included User Requirement
Specification and Traceability as Inputs.
Also made Functional Specifications and
Architecture Design as optional by
mentioning as applicable.
Appendix H: Removed the word SOP and
replaced with "implementation Appendix J".
Appendix I: Added a sentence "The level of
details to be updated can be decided by
the Project Manager to his/her discretion".
Also removed the word Re-engineered.
Appendix J: Added a sentence "The level
of details to be updated can be decided by
the Project Manager to his/her discretion".
Appendix K: Replaced the role Technical
Lead by Project Manager for Release
Notes step.
Also removed the word Re-engineering.
Appendix M: Removed the word "not" from
the sentence "Development testing may
occur in a test environment and will not be
included in the validation documents".
Appendix N: Changed the Role from
Technical Lead to Project Manager for the
step Review Release Notes.
"Development Test Checklist" is added as
a step with the details as "The results of
Self Testing are recorded in the
Development Test Checklist as an output".

Confidential
Major/Minor
Appendix P: Removed the reference to
URS and retained only the data conversion
and migration details in the Update
Traceability Matrix activity.
Appendix R: Replaced the word Formal
with System Testing and UAT.
Changed the Defect Prioritization into the

word Defect Classification.
Appendix S: Changed the word from
FMEA to User Requirement Specification.
Added a sentence as “Installation
Qualification Testing is planned, performed
and recorded in the System Test Report” in
the Create/Update System Test Protocol.
Deleted the UAT details from the activity
"Execute System Test Protocol".
Removed the word Executed from
“Executed System Test Protocol”.
Appendix T: Changed the word from FMEA
to User Requirement Specification.
Removed the template filling instructions
as it’s duplicated in the SOP.
Added a sentence as “Details of the
Installation Qualification Testing and its
results are suitably recorded in the System
Test Report” in the Create/Update System
Test Report.
Removed the word Executed from
“Executed System Test Protocol”.
Appendix U: Added “As Applicable” to UAT
is performed in QA or in Prod environment.
Appendix V: Added “As Applicable” to UAT
is performed in QA or in Prod environment.
Changed the sentence to "Create/update
the User Acceptance Test (UAT) Report by
summarizing the results of testing" by
removing the details of template.
Removed the template filling instructions
as it’s duplicated in the SOP.
Added “As Applicable” to Update
Traceability Matrix activity.
Appendix W: Reference to System
Management Plan is removed.
Appendix AA: Reference to System
Management Plan is removed.
Appendix AB: Included the phrase
“removal of any SMS packages, removal of
application software and files from servers”

Confidential
Major/Minor
by removing the wording SMS verification.
Appendix AG: Changed the term from
Project Scaling to Project Classification for
the table. Updated the Classification table
with the latest one.
Changed the number from 90 to 91 in the
Moderate range in the classification table.

Changed the number from 120 to 121 in
the Complex range in the classification
table.
Removed reference (Orbit Doc ID) to the
Project Classification in the step Identify
Compliance Deliverables.
All references to SDLC orbit documents ids
are removed. Replaced ITS and Global
Services with I/TSS. Rephrased the
training requirement.

Confidential
DOC ID:SOP-1705
Version:14.0
UNCONTROLLED PRINT
J&J SERVICES, INC.
CONFIDENTIAL - USE PURSUANT TO COMPANY INSTRUCTIONS
Title: SOFTWARE DEVELOPMENT LIFE CYCLE
Signed By: Lewis Ozepher

Decision: Approved
Decision Date: 10/23/2017 11:16:12 AM
Role: Owner
Purpose: Approve Software Development Life Cycle Process
Meaning Of Signature: As the Owner, I confirm that this document is technically correct and
complete, and that the appropriate persons are reviewing/approving this document
Signed By: Lang Deborah

Decision: Approved
Decision Date: 10/23/2017 11:35:12 AM
Role: Functional Approver
Meaning Of Signature: As the functional approver, I confirm that this document is technically
correct and complete, I agree with the purpose and scope of this document and accept for the
department identified within the content of this document.
Signed By: Anderson Angela

Decision: Approved
Decision Date: 11/1/2017 11:30:33 AM
Role: Q&C Functional Approver
Meaning Of Signature: As the Q&C functional approver, I confirm that this document is
correct and complete from a quality perspective.
Signed By: KRINGDON KENNETH

Decision: Approved
Decision Date: 11/1/2017 3:54:50 PM
Role: Q&C Approver
Meaning Of Signature: As a Q&C approver, I confirm that this document complies with
Document management process.
Document Printed On Document Printed By Effective Date Approved Date

06-Nov-2017 Hector Soto-Gonzalez 01-NOV-17 1-NOV-17

Sop 1705 SDLC Sop PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sop 1705 SDLC Sop PDF

Uploaded by

Copyright:

Available Formats

SOFTWARE

SOP-1705 DEVELOPMENT LIFE Version 14.0

STANDARD OPERATING PROCEDURE

Johnson & Johnson Information Technology

Johnson & Johnson Information Technology

! Software as Medical Device - software in medical devices/equipment

Johnson & Johnson Information Technology

! Infrastructure and tools that support infrastructure 1

! Automated manufacturing and laboratory equipment and instrumentation

3.1 Terms and Acronyms:

i. Provides a heat map of control strength vs a risk-based target level in order

! Business Process Analysis Documentation – Process maps, process modeling

Johnson & Johnson Information Technology

! Business Simulation Testing (BST) – Mimics real-life business scenarios that

! CaseComplete – Requirements management tool that is integrated with JIRA,

! Change Control (CC) - Is a formal approved request or an order for the

! Coding Standards - A set of guidelines for a specific programming language that

! Commercial Off-the-Shelf (COTS) – Packaged solutions which are procured and

! Compliance Summary Report - Summarizes the compliance deliverables, the

Johnson & Johnson Information Technology

! Conditional Documentation – Project documentation that is needed for the specific

! Configuration Control Document (CCD) - Track and control versions of software to

! Continuous Process Improvement (CPI) - Is an ongoing effort to improve

! Data Conversion/Migration Requirements Specification – The requirements for

! Design Specifications - Describes functional and technical design which

Johnson & Johnson Information Technology

specifications are used to design software features. Definition of Done (DoD) -

! Definition of Ready (DoR) – Refers to completion of all activities necessary before

! Disaster Recovery Plan – The documentation that formally describes the

! Entry-Task-Validation-Exit (ETVX) – Model that views processes within the context

! Functional Requirement (FR) – Requirements that describe the behavior of the

! Health Insurance Portability and Accountability Act (HIPPA) - A US law

! Hewlett Packard - Application Lifecycle Management (HP-ALM) – Application

Johnson & Johnson Information Technology

! Key Performance Indicators (KPIs) – Business metrics used to evaluate the

! Minimum Viable Security Controls (MVS) – The minimum application security

! Non-Functional Requirement (NFR) – Requirements that define the qualities of the

! Operations Run Book (ORB) - Is a set of defined procedures developed by the

Johnson & Johnson Information Technology

! Product Backlog – The inventory of system requirements including regulatory,

! Product Increment – The increment (or Potentially Shippable Increment (PSI)) is

! Project Management Excellence (PMx) Team Site – A platform that offers

! Rapid Requirements (rRDS) - A requirements development methodology for the

! Requirements Specification - A requirements specification is a comprehensive

! Responsible Accountable Consult Inform Signatory (RACIS) Matrix - A

i. Responsible – Has the obligation for creating, authoring and ensuring

Johnson & Johnson Information Technology

iii. Consult 2– Has the recommended obligation of providing subject-matter

v. Signatory – Individuals responsible for signing-off on the project deliverable

! Retirement Report - A required deliverable that documents and summarizes the

! Retrospective – A ceremony scheduled after a sprint to reflect on how things went

! Service Level Agreement (SLA) - An agreement between an IT service provider

! Software as a Service (SaaS)3 - The capability provided to the consumer is to use

Johnson & Johnson Information Technology

environment, on a subscription basis. A standard service is provided for all

Examples: Salesforce.com, Tableau, Cisco WebEx, Microsoft Office 365,

! Software Quality Assurance (SQA) Stage Gate Assessment Report – SQA

! System Testing (ST) – The testing conducted on a complete, integrated system to

Johnson & Johnson Information Technology

i. Identify the system under test.

! Traceability Matrix (TM) - Captures approved requirements and their traceability

! User Story – A software system requirement formulated in a few sentences in

Johnson & Johnson Information Technology