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:

Functional Analysis

Have a clear understanding of business processes and workflows to be supported by the software application. This may include development process maps, interdependencies between processes and systems, user journeys, personas and collecting feedback from current or planned software product users on functionality. 

In projects involving upgrades to existing systems or optimization of systems, the functional analysis should include differences between current processes and target outcomes, as well current pain points and challenges. 

Technical Analysis

Assessing the technology stack supporting current applications, such as architecture, user interactions, database structure, performance metrics, etc. For new product development this analysis expands to factors like preferred platforms or devices, scalability options, complexity levels, integration needs, maintenance requirements, audience preferences and choosing between source or proprietary technologies.

Market Analysis

In addition to collecting internal processes and system related information, its important to consider external aspects like industry trends, supply chain dynamics and technological advancements. Recognizing how these factors align with the project’s objectives ensures alignment with market trends.

It is crucial to combine the knowledge obtained from functional, technical and market evaluations with the essential project planning parameters such as project vision, budget, resources, timelines and risks. This comprehensive approach helps create a practical software project plan. 

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;

Technology Stack Selection

We carefully assess technologies and frameworks to select the appropriate ones that align with the projects goals and needs. Factors like scalability, compatibility, performance and future growth potential are taken into account during this evaluation process.

Design System Architecture

Our team creates a blueprint for the system architecture outlining the structure and components of the software solution. This includes defining modules, interfaces, data flows and interactions between system elements to ensure functionality and compatibility.

Database Planning

We focus on designing the database schema and data model while considering aspects like data integrity, normalization, indexing and performance enhancement. Our aim is to establish an scalable database structure of storing retrieving and managing data effectively.

Environment Setup (Development, Testing & Production)

Establishing development, quality assurance and production environments is crucial for supporting the software development process and ensuring transitions, between stages.

We set up work environments with all the tools and setups to support the various stages of development, testing and deployment. When it comes to security we take it seriously in todays software development landscape. That’s why we integrate security measures and protocols into our system architecture to protect against risks and vulnerabilities. This involves implementing features, like authentication, authorization, encryption and other security methods to safeguard information and ensure compliance with industry standards and regulations. By addressing these tasks during the design phase of our solution we establish a foundation, for a successful software development project. This guarantees that the final product is well designed, scalable, secure and tailored to meet the clients needs and goals.

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;

Translating Business Needs

Through wireframing the project team can turn business requirements into representations of how the application will look and function. This ensures that the final product closely reflects the clients vision and goals.

Visual Aid for Users

By sharing wireframes with end users we offer them a picture of what the end product will look like including brand elements and color schemes. This allows stakeholders to confirm that the design meets their expectations and provide feedback before development begins.

Refinement

Wireframes act as a testing platform for navigation and user interaction. By simulating the user experience we can identify any usability issues or areas for improvement on in the process. This proactive approach helps streamline development efforts and reduce the need for rework on.

Validation and Sparks Innovation

Reviewing the wireframes as part of the agile development process, allows the client and the full project team from product owners to developers to review the product design and ask questions and provide critique on the design and process logic. This exercise helps validate the design, and also often sparks ideas that may have not been originally considered or identify gaps that may have been overlooked. In any one of those cases, the wireframing process improves the design and minimizes development cycle, and in turn development costs. 

Wireframing lays a foundation for a development journey by ensuring alignment with business needs promoting collaboration with stakeholders and establishing a user focused design approach.

The user experience design entails activities including;

• Conducting User Research; Delving into user requirements and behaviors.
• Creating Wireframes & Prototypes; Mapping out the layout and navigation flow.
• Establishing Information Architecture; Structuring content, in an  intuitive manner.
• Designing Visual Elements; Improving usability and visual appeal.
• Performing Usability Testing & Iterations; Collecting feedback for enhancements.

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;

Programming

Central to development is coding, where software engineers turn design plans into working code. This process involves writing, testing and implementing algorithms and logic to bring envisioned features to life.

Version Control

When multiple team members collaborate on code managing versions becomes essential. Tools like Git help developers handle code changes, track revisions and coordinate contributions smoothly ensuring code integrity and enabling teamwork.

Code Review

Maintaining high quality code is crucial for software stability and reliability. Through code reviews developers carefully assess each others work, checking for adherence to coding standards, spotting bugs and offering suggestions for enhancements. This collaborative effort encourages knowledge sharing. Supports a culture of improvement.

Documentation

Clear and detailed documentation forms the foundation of any software project. Developers document code functions, APIs, settings and dependencies to aid comprehension, upkeep and future developments. Technical documentation serves as a reference for developers, testers and other stakeholders, throughout the software lifecycle.

When software is being developed the different parts and pieces must come together to form a system. This process, known as integration involves merging code resolving dependencies and ensuring communication between components of the software. It’s a stage to confirm that everything works well together and functions, across the entire system.

Essentially the development phase is where all the planning and design work comes to fruition as ideas are transformed into reality through coding, teamwork and integration efforts. By implementing quality checks and detailed documentation practices developers aim to create scalable software solutions that can be easily maintained and meet the requirements of both users and stakeholders.

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: 

Test Planning

Developing a plan that outlines testing goals, scope, resources and timelines.

Test Case Creation

Writing comprehensive test cases and scenarios to cover different aspects of the software’s functionality.

Text Execution

Conducting both manual and automated tests based on the test plan and documenting the outcomes.

Defect Tracking

Identifying and documenting software issues prioritizing them by severity and monitoring their resolution.

Regression Testing

Repeat tests to ensure that developed and fixed features still function correctly after new changes have been made.

Penetration Testing

Conducted by a neutral third party to ensure the code is not vulnerable to attacks.

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.

Requirements and Planning:

In the first stage of the Software Development Life Cycle (SDLC), we ensure that all stakeholders are aligned with the finalized requirements and that there is no ambiguity. Once the requirements are clear, we move on to planning and analysis. During this phase, we ensure that adequate project planning is conducted to stay within the allocated timelines and budget. This includes accounting for a sufficient buffer to address any disruptions or issues that may arise. We also periodically review the progress of our development to ensure it aligns with the project plan and make necessary adjustments to correct any deviations.

Development Phase: Robust System Design

To minimize risk during the development phase, the undertake the following tasks:

• Ensure all functional and nonfunctional requirements are accounted for in development planning.
• Review the architecture’s robustness by assessing factors such as scalability, peak traffic handling, transaction management, modularity, deployment architecture, etc.

Whether the project involves a cloud or on-premise solution, a web application or mobile app, a single location or international use with multiple languages and time zones, all these considerations are taken into account during system design.

Careful consideration of these factors is essential to avoid risk factors that could prove costly if detected later, once development starts or during the middle of project implementation.

Development Phase: Coding and Tech stack

• Right choice of tech stack, which has good industry support and development resources being available.
• Usage of best coding practices (like coding standards, adequate test coverage, test driven development so on)
• Implementation of Continuous integration and deployment to detect errors and fail fast.
• Code security via code scans and penetration testing 

Development Phase: Sustainability

To ensure sustainability during the development phase, we focus on the following key aspects:

• Eliminate Single Point Failure: This applies both to the people working on the project and the components of the application. Avoiding single points of failure is crucial to mitigating risks.
• Comprehensive Documentation: We maintain thorough documentation, including deployment steps, configuration details, local development setup, API and code documentation, and playbooks. This ensures that anyone can onboard quickly, ensuring business continuity.
• Adherence to Best Practices: We follow best design and coding practices, such as SOLID principles. This helps maintain long-term code quality, avoiding code smells and regression issues, and ensuring the codebase remains manageable even as team members change.

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.

Application Components

• Ensure usage of the latest stable version of all software components/libraries. 
• Avoid using third party libraries without vetting them out carefully. This applies more if you’re using a less popular package/library.
• Replacement and/or upgrading libraries when any security risks are identified.

Identity Management

• Well documented requirements which mentions the permissions and roles required for each operation in the application at the beginning of the project during requirements gathering.
• Usage of well established authentication mechanisms like dual factor authentication, JWT tokens for Rest APIs.
• Permission checks on both frontend and backend to ensure users have necessary privileges to perform the required action.

Configuration Management

• No passwords and secrets in the code base or build artifacts.
• All are confidential information pushed to applications at runtime via best practices prescribed by the respective cloud provider.
• Limiting the permissions of database user used by applications in RDBMS, like not having drop table privilege etc.
• Network connections best practices, all critical components behind the firewall, proper choice of SSL settings and encryption protocol versions.

Application Code

• Inclusion of code review guidelines with security aspects in mind.
• Performing code Security scans as a part of build deploy process/continuous integration.
• Usage of best coding practices like parameter validation, parameterised queries to prevent SQL Injection.
• Reviewing code is not prone to OWASP top 10 vulnerabilities and training the team adequately so that they code effectively.

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.

Risk	Issue
Risk is a potential obstacle that is likely to happen with a certain probability.	Issue is an obstacle that is impacting the project at present and that needs to be addressed.
Risk becomes an Issue if it occurs	All current issues should have been identified as risks with measures taken to reduce their impact.
Typically prioritized based on risk score which is computed from impact severity and likelihood of occurrence.	Typically prioritized based on severity and urgency.

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: