Organizations that need to understand the quality of their software and systems development processes and practices can benchmark their SDLC by measuring its maturity. There are models available for measuring software and systems development maturity, including:
Capability Maturity Model (CMM)
This model is far the most popular model for measuring software development maturity. The Software Capability Maturity Model (CMM) is a maturity framework for evaluating and improving the software development process. The purpose of CMM is to develop a methodical framework for creating quality software that lets measurable and repeatable results. The CMM describes the principles and practices underlying software process maturity.
There are five maturity levels of the CMM:
- Level 1(Initial): Processes are chaotic and unpredictable, poorly controlled, and reactive
- Level 2(Repeatable): A formal structure provides change control, quality assurance, and testing.
- Level 3 (Defined): Processes and procedures are designed and followed during the project.
- Level 4 (Managed): Processes are characterized for projects, but are still reactive.
- Level 5 (Optimizing): There is a model of continuous improvement for the development cycle.
Software Assurance Maturity Model (SAMM)
This model is an open framework that is geared towards organizations that want to ensure that development projects include security features.
Building Security In Maturity Model (BSIMM)
This model is used to measure the extent to which security is included in software development processes. This model has four areas:
- Secure Software Development Lifecycle (SSDL) Touchpoints
Agile Maturity Model (AMM)
This model is a software process improvement framework for organizations that use Agile software development processes.
Operation and Maintenance
After the development, testing and releasing of product, the next step of the process is to provide operational support and maintenance of the released product.
This phase can include resolving unexpected problems or developing new features to address new requirements.
One of the key processes on which to focus for improvement is change management. Change management is discussed in greater detail in Security Operations domain.
This type of management actually is the formal business process that ensures all changes made to a system receive formal review and approval from all stakeholders before implementation.
The change management process has three basic components:
- Request Control: This component offers an organized framework in which users can request modifications, managers can conduct cost/benefit analysis, and developers can prioritize activities.
- Change Control: This process is used by developers to regenerate the situation encountered by the user and analyze the appropriate changes to fix the situation.
- Release Control: Once the changes are settled, they must be approved for release through the release control procedure. A crucial step of the release control process is to ensure that any code which is inserted as a programming aid during the change process such as debugging code and backdoors is removed before releasing the new software to production.
Integrated Product Team
Suppose one day, organization has experienced a disconnection between the major IT functions of software development, quality assurance, and technology operations.
These functions operated with distinct individuals and located in a separate location often conflicted with each other.
It is clear that this conflict may cause a delay in codes generation and
deployment of codes into a production environment.
To overcome this problem, DevOps seeks to resolve by bringing the three functions together in a single operational model. In other words, DevOps is a popular trend that represents the fusion of Development and Operations.
The goal of DevOps is to improve communication and collaboration between software/systems developers and IT operations teams.
Anyway, there are inherent security challenges that must be addressed in a DevOps environment. For example, in DevOps, there is a speration between development and production environments ,but this sepration is little less absolute. So, It is a dangeriuos situation that it can introduce additional risks to the production environment.