Products without security risk becoming irrelevant. Projects lacking governance to comply with organizational security policies will find themselves unable to operate. A Software Development Life Cycle (SDLC) that accounts for security only in the testing, or worse, just after deployment, is increasing the risk of the occurrence of and the cost of fixing exploitable security vulnerabilities. Despite the normalcy surrounding cyberattacks, the unacceptability of them remains at a critical level.
Long ago
My academic training in security dates back to 2006 when I studied Information Assurance and Security, and my practical experience dates back to 2000 when I regularly released software to the public. Every time I published a release, I thought about all of the “hacked” or “cracked” versions of popular competing software. While my product was widely used, it did not get hacked in any notable manner because I added encryption and anti-decompiling mechanisms into the software prior to release. Additionally, I included multiple authentication mechanisms including serial key distribution to control the use of the software by authorized individuals. While sophisticated hackers would have been able to bypass these controls, I made the work more difficult. Making the work more difficult is the key.
Information Security and the Secure Software Development Life Cycle
The next set of blogs will cover two important security areas: Information Security from the perspective of overall information systems security management, and the Secure Software Development Life Cycle (Secure SDLC). It is important to note: there is no such thing as 100% security. There is always a way to affect the Confidentiality, Integrity, and Availability of a system. The important consideration is whether the defender of a system is doing what they can to make sure attackers have a very difficult time accomplishing their goals to the point that the risks to the system are minimized and actions can be taken to prevent catastrophic consequences. As I had done with the PMP® exam, I will go through concepts and details helpful for taking the CISSP® (the gold standard for information security just as the PMP® is for project management) and CSSLP® (for Secure SDLC) exams.
A product is not by definition temporary, but if it’s decommissioned/retired, then it’s over. A product exists to solve an ongoing business need or want. If there is no need nor any want, then there is likely no product (worth sustaining).
A project is a temporary endeavor undertaken to create a unique product, service, or result. I would take it further and say this is undertaken taking into account one or more business cases.
The software development life cycle (SDLC) is often part of product development generally (where there’s software to be made as part of a product life cycle) and the project life cycle (especially planning through the end of execution, which includes monitoring & controlling).
The SDLC is a process for delivering software and is commonly known as consisting of the following phases (or some associated variants):
Analysis – understand what should be made to achieve the relevant goals (business need or want)
Design – determine the way in which the implementation should be done so that it is sustainable
Implementation – make it
Testing – make sure it works as expected
Deployment – get it out to the relevant environment
Maintenance – keep it running and resilient
The development methodology selected will determine when any of the above phases of the SDLC are active. The ones I have worked with are waterfall and a few agile variants (Scrum, Kanban, and XP). I will not go into detail on these methodologies in this post.
How are products, projects, and software development related?
As my role has often been a mixture of project manager and product manager, I have seen how my involvement in the product vision ends up affecting the delivery of project outcomes resulting in the desired product.
For product management, I refer to the phases referenced in the ProdBOK® maintained by the Association of International Product Marketing and Management (AIPMM):
Conceive – generate and prioritize ideas prior to putting in product planning efforts
Plan – define the product more clearly by covering experience design and other market validation to ensure this product is worth developing
Develop – build the product according to the plan with deliverables and beta preparation
Qualify – conduct beta testing through select external users to refine the product and prepare for the launch with relevant marketing and sales training
Launch – get it out there with the appropriate messaging and acquire users
Deliver – scale the product to maximize opportunities and increase sales
Retire – take steps to end support for the product including preparation of any necessary license terminations or documentation on migration to other products
For project management, I refer to the domains referenced in the PMBOK® Guide maintained by the Project Management Institute (PMI):
Initiate – get buy-in and approval to progress
Plan – detailed analysis of the scope, schedule, cost, and other variables that will affect the final outcome of the project
Execute – deliver the outcome according to the plan
Monitor & Control – take relevant steps to ensure execution is going according to plan
Close – wrap up once the project outcome has been achieved (or some other event happens that ends the project)
From my experience the way this would work conceptually (taking into account what I said about the development methodology above) is as follows:
Getting a product made may consist of multiple projects, although actual software development may occur depending on the delivery methodology being used as well as how many projects there might be planned during the product’s life cycle.
I have seen that according to the Optimal Product Process™ that “Launch” and “Deliver” (or Maximize) are not traditionally associated with the SDLC, but I don’t believe there is a hard rule suggesting that they do not apply in those two product life cycle phases. There are numerous professional perspectives on how the overlap works, and all of them are valid in different contexts.
In my product perspective, which is focused on non-stop momentum and sustained value delivered to customers, there should be continuous software delivery without unreasonable stoppage until the product is set to be decommissioned or retire. That includes continuous delivery during the Launch and Deliver phases where necessary.
Additionally, regarding “Deployment” and “Maintenance” in the SDLC, it’s entirely possible that there is not much to consider in a “pre-production” (Pre-Launch) phase of the product, but I believe they still apply whether we are in pre-prod or prod due to how the development operations may be set up.
To recap, when “doing the work” to get the product made, many projects can take place to build and improve the product throughout its life. If we are talking about software and in an agile development context, then the phases of the SDLC will take place throughout this building and improvement of the product typically in scope of one or more projects. The level of formality and process strictness applied depends on the standards applied by the relevant product, project, and delivery managers. Business analysts will often have a role to play in all three distinct life cycles to bridge the relationship between the three.
There is no one-size-fits-all approach in managing desired outcomes for a product or project, though I am generally a proponent of applying lean practices to focus on results over process.
The difference is clearer, so how does the SDLC work?
I will cover more about the SDLC and the associated development methodologies in another post.
