Navigating the Software Development Life Cycle (SDLC) with Mantrax

Software Development Lifecycle (SDLC) is the process of developing software applications using a cost-effective and time-efficient process. The SDLC process combines all the critical elements of software product development from planning to development to quality assurance to launch and post-product launch maintenance. While there are many SDLC processes, such as waterfall, iterative, spiral and agile, at Mantrax, our development processes are centered on agile methodologies.

At Mantrax, we follow a systematic process to SDLC:

1. Strategic Planning and Analysis

Before starting a software development project it’s crucial to understand the business objectives and project justification underlying the software product development. A comprehensive plan also outlines key internal and external factors that will have an impact on the software development life cycle. Here are some of the areas to consider in planning a software development project:

2. Solution Design

During the solution design phase, in the Software Development Life Cycle (SDLC) our main focus is on translating project requirements into a robust architecture. This phase involves tasks that aim to establish a strong groundwork for the development process;

3. User Experience Design

Before we dive into the development work we start off by creating versions of the User Interface (UI) and features using wireframing tools, like Figma. This crucial step in the Software Development Life Cycle (SDLC) is highly important for a reasons;

4. Agile Software Development

Welcome to the heart of software development, where ideas are transformed into solutions through a variety of tasks. Lets take a look, at the aspects of the development phase;

5. Quality Assurance

Testing is crucial for ensuring software quality, ensuring every piece of code functions correctly, and upholds standards for reliability and security. At Mantrax, we seamlessly integrate Quality Assurance into our agile software development process. In fact, application testing begins as early as the end of the first development sprint. To provide examples, Quality Assurance involves the following activities: 

6. Pilot Release and Final UAT

Although quality assurance is an ongoing process during development, conducting a comprehensive end-to-end test, often referred to as boardroom testing or conference room testing, is essential. This involves engaging an extended group of testers—a fresh set of eyes—to ensure software readiness for launch. Here, the Pilot Release and Final User Acceptance Testing (UAT) stage comes into play as a critical step. This phase assesses readiness for deployment and ensures user satisfaction. Final UAT with Subject Matter Experts (SMEs) Protocol involves testing various test cases and scenarios meticulously. The Pilot Release and Final UAT activities are customized for each project and client, as the requirements are unique for each project, the tasks may include: 

• Final User Acceptance Testing: Verifying the software’s readiness for production by engaging with subject matter specialists.
• Creating Test Protocols: Developing a series of test cases and scenarios to direct the testing procedure.
• Continuous Testing: Incorporating feedback from experts to enhance the software and meet user requirements effectively.

7. Training

Once the final UAT is complete with the core Project Team, training is facilitated for the end users. The training plans are developed in collaboration with the Client to accommodate end users’ preferences, skill set and availability. Training plans could may include:

• Group training
• Written Standard Operating Procedures (SOPs) / Work instructions
• HOW TO videos
• User guides accessible directly from the software

8. Product Launch

The Launch or Go-Live planning is done in close collaboration with the Client, as timing and coordination of launch impacts the end users and other business activities. Meticulous planning in advance of launch, during the launch and post launch are managed by our team, including:

• Pre-launch Preparation and Audits;
• Day 1 Planning; Crafting a schedule for the 48 hours leading up to and following the launch.
• Risk Management Strategy; Identifying risks and planning ways to address them.
• Developing Communication Templates;
• Rolling out software following a gated approach – each step will have some prerequisites which must be satisfied
• Monitoring & Assistance; Continuously checking system performance. Offering assistance for any problems.
• Engaging with Stakeholders; Keeping everyone informed
• Evaluation After Launch; Conducting an assessment to measure the success of the launch and pinpoint areas for enhancement.

9. Post Product Launch Maintenance and Optimization

We offer post-launch support and maintenance tailored to client’s needs. Examples of post-launch activities include:

• Monitoring how the system is running and collecting user feedback
• Hot fixes for urgent issues
• Collect stakeholder feedback
• Ensuring the application security
• Providing additional training.
• Continuous Improvement initiatives

Success Factors in SDLC

The SDLC process encompasses more than the nine outlined steps. It involves various critical success factors including collaboration, communication, budget management, change management, risk management, and stakeholder engagement. While each factor holds significance, we believe that collaboration, communication, and risk management stand out as particularly crucial for ensuring successful software development.

Important of Collaboration and Communication in SDLC

At Mantrax, at every stage of the SDLC we prioritize keeping clients informed on project status and progress. To ensure transparency and accurate communication, our project initiation process includes the following steps.

• Document requirements gathered and solicit feedback from clients via collaboration tools like google docs, confluence, etc.
• Develop wireframes and mockup screens in accordance to the UI standards prescribed. Work with the clients to fine tune according to the usability aspects which come up during our reviews of mockups.
• Clearly document non-functional requirements along with functional requirements to assist in proper choice of technology based on the non-functional needs like performance, scalability, security etc. Seek consensus for these aspects from clients.

Our development phase communication plan includes:

• Daily Standups – Short daily call with round table updates from the Dev team on their progress for the day, along with any questions and clarifications.
• Weekly or biweekly grooming/backlog refinement – Discuss priorities with client and setup path for the upcoming sprints. Get clarity around any new stories that need development in upcoming sprints.
• Demos and reviews – End of Sprint review of what’s been accomplished during the sprint, demos.
• Regular strategic project review meetings to review budget, timeline, risks, and team performance.

Once an application is live, our Production Support cadence includes:

• Feedback: Setup customer feedback widgets like Ybug and capture customers feedback. Fortnightly review of important improvement aspects and user pain points with Client. Further prioritizing the needed improvements in the backlog.
• Health Monitoring: Setup production health monitoring via tools like Sentry, Splunk, Datadog, google analytics etc. (based on client’s preference). Share regular updates on how the application is performing with suggestions on improvements related to scalability, reliability etc.
• Bugs and Improvements Tracking: Creating bugs and improvement stories on a regular basis based on Feedback and health monitoring updates. Monthly and quarterly meetings to work with Client to prioritize and resolve these in a timely manner to avoid starving (of issues in backlog) and improve customer experience by early resolution.

Risk Management

At Mantrax our philosophy is that risk management should be an integral part of the application development lifecycle. Risk manifests itself in various forms at various stages of SDLC. Risk could arise due to internal or external factors. Risk is something which cannot be avoided always, but how well we are prepared to handle it in event of its occurrence defines the overall success or failure of a project.

Risk avoidance with emphasis on Security

Security risks are among the most significant factors that can harm a project and the company if not properly managed. Here are some key security aspects we address during software development.

Risk management in SDLC

What are Risks?

Risk in software development refers to the potential for unforeseen events or conditions that can negatively impact a software project. These risks can affect the project’s scope, schedule, cost, quality, or overall success.

Source of Risk

Risk could arise from various sources such as requirements, technology, design, processes, resources, timelines and as well as from people. These are at a high level but are limited to these.

The source of risk could be internal as well as external like a change in government rule, change in business dynamics. In this this article, we will focus on management of internal risks.

Risk Management

No project is entirely risk-free. Therefore, being aware of risks and prepared to manage them is crucial for success. Fortunately, there are industry-standard processes for managing risk, such as ISO-31000.

Key steps in risk management can be broadly divided into :

• Risk Identification
• Risk Analysis
• Prioritization of risk
• Address the risk
• Monitoring

Also Risk Management is not a one time effort but it is a continuous process, typically following PDCA cycle (https://en.wikipedia.org/wiki/PDCA). Plan Do Check Act.

Risk log is generally maintained to capture details about risk, actions taken etc. while we traverse through these stages of risk management. It typically contains 

• Risk description
• Risk impact 
• Probability of occurrence 
• Priority: either computed or assigned priority based on impact and probability 
• Risk owner 
• Mitigation strategy and status 
• Actions needed 
• Due dates for actions

Risk Identification:

Risk can be identified by team members, stakeholders, architects, external reviewers, and anyone else involved in the project. At this stage, we document the risk description in the risk log, which will be analyzed further in later stages. This description should clearly state what the risk is and its potential impact on the project.

Risks can be identified at various stages of the project, not just at the beginning or end. For example:

• During requirements gathering: Risks may arise from unknowns in the requirements.
• During design: Risks related to the use of specific technologies, design choices, or scalability can be identified.
• During development: Risks may involve dependencies between teams, loss of team members, or deployment environment issues.
• During reviews: Risks such as code security issues and exploitable loopholes can be identified.
• During project timeline preparation: Risks may emerge when deviations from the initial timeline occur.
• Due to inter-team and intra-team dependencies: Risks related to team utilization and project schedules can be identified.

Risk Analysis:

The purpose of risk analysis is to identify the following and document them in risk log:

• Risk impact
• Factors that could cause this risk and probability of their occurrence
• Risk mitigation strategy
• Action plan

Risk Impact:

What is the impact of each risk on the project timelines, project budget, project goals should be identified. Based on the impact analysis, the severity of the risk can be evaluated.

Contributing factors and their probability: 

For a risk to become an issue, several contributing factors must come into play. It is important to assess the likelihood of these factors arising and their probability. Documenting these factors and grading them based on their probability and impact is essential.

Risk mitigation strategy

Based on the type of risk and contributing factors, there are a few paths to address the potential risk:

• Avoid
• Mitigate
• Transfer
• Accept
• Ignore

Risk Handling	Description
Avoid	Identify the causes and ensure you take necessary steps to avoid those causes when possible. Ex: Setup network firewall to avoid network security breach.
Mitigate	Identify steps that can be taken to mitigate and reduce the impact of risk occurrence. Ex: Take database backups to mitigate risks of system failures.
Transfer	Sometimes, it makes sense to transfer risk to others by delegating risky parts of the project or making customers responsible for the impact if a risk occurs. For example, client-side project leadership can manage the engagement of client-side stakeholders, as the client has more direct engagement and authority over their staff. Additionally, purchasing insurance is a common method of risk transfer, as it shifts the financial impact of certain risks to the insurance provider.
Accept	Some risks are too costly or inefficient to avoid or mitigate. In such cases, it is necessary to accept the risk and be prepared to absorb the impact if it occurs. For example, when a project has a low budget, it may not be economical to implement a multi-region deployment for high availability to protect against a disaster. In this scenario, it is crucial to clearly outline the potential impact of the risk to project leadership and ensure transparency about potential challenges and consequences. Fully understanding the impact of the risk may lead to changes in the budget or the allocation of additional time and resources to minimize the severity of the risk.
Ignore	Risks which have a low probability or a low impact or things which are easier to handle, we ignore and take on them as and when they occur.

Risk Management Action Plan

Once we know the contributing factors and we have a risk mitigation strategy at hand the next step would be to make an action plan. Action plan typically contains:

• Short description of the action to be taken. (can link to a detailed page if it is too long)
• Who: Owner of action
• When: Target completion date
• Notes section which could have details of actions taken till date.
• Status of the action – Should be updated frequently for review by stakeholders. Example values could be:
  • Red, Amber, Green
• Open, InProgress, Mitigated, Closed, Blocked

• Next due date or review date (need to revisit the risk status by all stakeholders on this date, this will continue until the risk is mitigated or closed)

Utilizing a story tracking system such as JIRA, it’s advisable to create stories, bugs, and tasks, and assign them to the appropriate sprint, assignee, and tags. By placing them in the backlog, they are less likely to go unnoticed once identified and logged in the risk log.

Prioritization of Risk

Considering the impact of the risk, its probability, and the time remaining before it could potentially become an issue, it’s crucial to prioritize risks. Concentrating our resources and efforts on addressing high-priority risks is essential. A common approach is to calculate a risk score based on its impact and probability, with higher-scoring risks being addressed first.

Addressing the Risk

At this stage, we’ve identified risks, assessed their impacts, and devised action plans. Prioritizing based on the risk score and internal stakeholder consensus, we begin addressing risks in order of priority. Addressing involves executing the steps outlined during the risk analysis stage and documented in the action plan.

Execution of Action Plan: Each item in the action plan should have a specific owner responsible for its completion. While delegation is permissible, ultimate responsibility remains with the assigned individual.

Status Monitoring: The team must diligently update the risk log to reflect the current status of action plan items. Any deviations from the action plan should be promptly reported to stakeholders.

Risk Monitoring

Risk management is a continuous process; hence, monitoring is a key aspect. It is not enough to identify risks, create an action plan, and consider the task complete. Periodically reviewing all risks and the status of action plan items is essential. The time duration between these reviews should be based on the current situation the project is facing. If there are many critical risks that need addressing within a short duration, it is advisable to hold weekly meetings at the least, involving all stakeholders and action item owners.

Even if there are no active risks, it is recommended to have periodic meetings to assess whether we are actually in the clear or not. During these meetings, the team should come prepared with evidence of a favorable status. This essentially means presenting various statistics relevant to the project’s stage in the SDLC. For example, it could be the percentage completion of an EPIC relative to timelines or the response times of rolled-out features.

RAID Log

Anything that impacts a project is a risk, but in general some organizations divide them into four categories based on their nature and source. That is RAID namely Risks, Assumptions, Issues and Dependencies. One point to note here is the difference between Risk and an issue.

Assumptions: During the various stages of SDLC, teams make certain assumptions and proceed with the implementation or design. It is very much essential to log these assumptions and get an agreement with Stakeholders, Project sponsors etc. This would help ensure all are on the same page and reduces chances of blaming discussions if things go wrong.

Dependencies: Dependencies could prove a big bottleneck if not documented and planned properly by the project management team. We should log the dependencies in RAID log and bring-up in the calls like Scrum of Scrums when the dependency is on the external teams, and regular team meetings if the dependency is intra-team.

An example of RAID template: