Software Development Lifecycle SOP Examples

Hello, I am developing a Corporate SOP to define the SDLC requirements for the initiation, planning, development, testing, implementation, operation, change management and retirement of the organization's information systems and software applications. I'd like to cover the basic phases of the SDLC cycle, which can be applied to all types of projects including new or modified proprietary application development, SaaS projects and configuration or customization of COTS. The organization uses both waterfall and agile development models. The software products in scope of this SOP are supporting operations in the pharma industry, but are NOT medical device software or applications that support medical devices.

Doing my research to create a robust document, and looking for any current examples of such SOPs that anyone can share with me. Thanks in advance.

I doubt that handing you an SDLC SOP would be all that beneficial to you. Ours is built around IEC 62304 (for medical device software).

You may be best served by asking some questions, for example:

• Is it worth applying sound engineering practices (requirements, [documented] architecture & design, reviews, code inspections / static analysis / unit testing, formal testing, configuration & change management, etc.)?
• What are the current practices? Are they successful? Trying to layer an ill-fitting SOP onto existing processes rarely finds success
• What are your current pain points? Are your previous software development efforts successful? Why? If not, why?
• Do you expect to have to maintain the software? What do your developers need to best enable maintenance?

It would absolutely be beneficial to me, no doubt about that. I consider this platform/ online community a valuable resource for information and knowledge exchange across the industries. Members do share documents and "hand" each other examples of procedures, process flows, references, etc. often in order to facilitate discussions, learn and support each others' analysis and research.

victoria.chala said:

Hello, I am developing a Corporate SOP to define the SDLC requirements for the initiation, planning, development, testing, implementation, operation, change management and retirement of the organization's information systems and software applications. I'd like to cover the basic phases of the SDLC cycle, which can be applied to all types of projects including new or modified proprietary application development, SaaS projects and configuration or customization of COTS. The organization uses both waterfall and agile development models. The software products in scope of this SOP are supporting operations in the pharma industry, but are NOT medical device software or applications that support medical devices.

Doing my research to create a robust document, and looking for any current examples of such SOPs that anyone can share with me. Thanks in advance.

Click to expand...

I do agree, that having a 'reference / example' gives a platform to evolve and fastrack the drafting stage;

it is critical to make it relevant ( customize) it to organizational preferences viz., like you mentioned
development methodology....waterfall & agile
deployment strategies....SaaS vs on premise.
implementation strategies...Configuration vs customisation

each of the above aspects will determine the weightage of the various aspects of the deliverables.; and also have the compliance to standards / regulations in mind while evolving the SOPs.

My point was that, for example, my SOP is for medical device software development and is based on IEC 62304. I have influences from ISO 14971, IEC 62366, IEC 60601, and FDA guidance documents in it. Those are probably irrelevant for your software and would likely just lead to confusion.

And you may have to consider ISO 27001 and maybe other standards like UL 2900-1 for cybersecurity, which I don't; again, increasing the likelihood for confusion.

I don't know if you're a software developer or not, but if not, you may want to pull some from your team to talk through what they do. Then you can work towards filling any gaps, working towards any standards, & getting some consistency.

Thank you, both, for your responses so far.

@yodon -
I am not a software developer and the discussions with applicable teams will absolutely happen during the process of developing this document so it is relevant and clear.

In our current procedure library, we maintain upwards of 20 development SOPs (including ADLC, ALM, SDLC procedures, and also procedures for Testing, creation of URD, creation of System Design Documents, creation of Validation Strategy, Change Management, etc.) These procedures are all very high-level (no more than 1.5 pages content) and there are discussions to consolidate/reduce/ create supporting WIs, if needed. At the same time, there is a need for a clear high-level overview of the organization's development strategies/methodologies/pathways and a general description/training of what an SDLC is and how it connects to our services/business operations. The organization uses both waterfall and agile, our development project include proprietary applications, SaaS and config/customization of COTS in support of our services/business operations.

So we need to develop a hierarchy of documents (1) high-level overview of SDLC models, applicable methodologies, relevant regulations, etc. (2) streamlined service-specific SOPs that cover the applicable deliverables, etc.

@v9991 - absolutely, they output needs to be relevant.

So I think I was correct in thinking giving you my SOP (for example) would be more confusing to you than helpful.

I don't disagree with your thinking but is there a particular problem you're trying to solve? Something with the current situation that is resulting in problems? If the teams don't see there's a problem, you will likely have trouble getting buy-in.

I would see if there are ways to categorize the software (maybe based on risk?) that could help you establish an overall plan for deliverables? (The journey - whether waterfall [which I would question] or agile isn't as important as the destination.)

One thing you probably absolutely need to converge on is configuration and change management.

Since you're not a software developer, you can expect to get push-back from the software developers if you try to lay anything on them. I expect your best approach is to assemble the team, establish what problems you're trying to solve with this effort, and shepherd them through the process of making these changes.