SDLC
Software Development Lifecycle
base-foundation's complete SDLC policy document is available upon request.
Software Development Process
Initiation
The initiation phase sets the foundation for the software development project. This phase includes identifying the purpose, goals, and high-level scope of the project. Key stakeholders are involved to define expectations and outline initial constraints. Deliverables include a project charter, an initial timeline, and a list of team members and roles.
Requirements Gathering
In this phase, the project team works closely with stakeholders to elicit and document detailed requirements. Techniques such as interviews, surveys, workshops, and use case analysis are employed to ensure a comprehensive understanding of user needs. The deliverables include a requirements specification document, user stories, and acceptance criteria.
Design and UX
The design phase translates requirements into a blueprint for development. This includes system architecture, database design, and detailed user experience (UX) planning. Wireframes, prototypes, and design mockups are created to visualize the end product. Feedback from stakeholders is incorporated to refine the designs. Deliverables include design documents, UX prototypes, and a finalized system architecture diagram.
Requirements
- All production Applications will access data and externalise communications through the means of service interfaces.
- All production Applications will be 'Service' orientated with support of a REST API serving the external communications.
- All production Applications will adhere to the Agile Testing Manifesto
- Testing throughout over testing at the end.
- Preventing bugs over finding bugs.
- Testing understanding over checking functionality.
- Building the best systems over breaking the system.
- Team responsibility for quality over tester responsibility.
- All applications shall be developed under a Test Driven Development (TDD) process.
- The TDD process shall encapsulate further testing processes such as as BDD and CT as such where applicable under the domain in question.
Implementation with TDD
The implementation phase focuses on building the software using Test-Driven Development (TDD). Developers write unit tests before implementing features to ensure code correctness and maintainability. Continuous integration practices are followed to integrate code changes frequently, allowing early detection of issues. Deliverables include source code, unit tests, and documentation.
Code Review
Peer code reviews are conducted to ensure code quality, adherence to coding standards, and alignment with architectural principles. Reviews focus on identifying potential bugs, improving code readability, and enhancing maintainability. Feedback is discussed in team meetings, and changes are implemented before merging code into the main branch.
Testing and Integration
Comprehensive testing is performed to validate that the software meets requirements and functions correctly. Testing types include integration testing, system testing, performance testing, and user acceptance testing (UAT). Automated test suites are executed regularly to maintain quality throughout development. Deliverables include test reports, bug tracking logs, and a validated software build.
Release
In the release phase, the software is deployed to the production environment. Deployment strategies such as blue-green deployments, feature toggles, or canary releases are used to minimize risk. Documentation, including release notes and user manuals, is published to this knowledgebase website. The team ensures a smooth transition by offering training sessions and post-deployment support.
Maintenance
Post-release, the software enters the maintenance phase, where ongoing support is provided. This includes monitoring the application, resolving bugs, and implementing enhancements based on user feedback. Regular updates and patches are delivered to ensure the software remains secure, performant, and aligned with evolving user needs. Deliverables include updated documentation, bug fixes, and version releases.
Database
The base-foundation platform uses MongoDB Atlas as the database of choice. MongoDB Atlas is a fully-managed cloud database that handles all the complexity of deploying, managing, and healing of deployments. The production database is a multi-region replicaset deployment with an optimal configuration replica ratio of 2:2:1 across regions. This is the preferable configuration to optimize for majority availability.
The replicaset is distributed in a 2:2:1 ration across Ireland, US and Paris respectively.
Failing over from the Primary region to a secondary region may affect latency.
Logs
Audit Logs
Each API service generates structured logs for each request it receives. These logs are collected in observability & monitoring platform and stored in a separate Database where our engineering team can use the logs to troubleshoot the system. The system logs do not contain any personal identifiable information. System logs are retained for 12 months for forensic auditing purposes. Please contact security@base-mc.com to request the audit logs of your tenant.
Audit logs contain information pertaining to which API resource was accessed. Information includes:
- Tenant ID
- Timestamp
- User ID
- Request URL
- HTTP Operation
- HTTP Operation Response Code
- Unique Request ID
The log structure for each integration will vary, extending the above depending on the functionality in question.
System Logs
The Orion system generates a lot of logs. These logs are collected in observability & monitoring platform where our engineering team can use the logs to troubleshoot the system. The system logs do not contain any personal identifiable information. System logs are retained for 30 days before being purged.
Email Notifications
All email notifications are issued by product.notifications@base-foundation.io
Upgrades & Deployments
The system is upgraded using Helm chart deployments for Kubernetes via our CI/CD pipeline. This involves publishing new Docker Containers of each service to our container registry where the corresponding hash is upgraded through our CI/CD pipeline.
Kubernetes offers the ability to rollback deployments if a newly pushed update has a problem. The Kubernetes concept of rolling updates does not affect the system during upgrades. Similar to deployments, helm rollback is applied to roll back to an earlier version of a release with ease. Should there be a need for planned maintenance, it will be scheduled and published to https://status.base-foundation.io where if you are subscribed you will be notified.
We have the means to grant partners and early access customers access to integrations throughout development and before they are considered generally available.
A separate environment is maintained for SQA before deployment to production.
Software Life Cycle Security Considerations
This section presents guidelines for enhancing software security at different stages of its life cycle; design, writing code and maintenance. It also provides guidelines for application with those involved in the different phases.
Architecture & Design
- The software design model should include the following:
- Threat modeling stage;
- Clear definition of security risks;
- Severity level that the compromise of Sensitive Personal Data would bring to the system and institution.
- It should not be omitted, during the system development design and its execution, the definition of responsibilities for system data security and how this responsibility will be verified.
- A design schedule that includes security check points of the system developed during its construction must be used.
Writing Code
Protective measures applied in the source code must be documented, including in the application code, in order to indicate precisely the procedure used and its peculiarities.
Testing
A secure Test Driven Development (TDD) Process for each project shall be undertaken. Under no circumstance and regardless of the application stack in use shall this conformance be deviated from.
Maintenance
Automatic updates of software or components used in the construction of a system should not be enabled, otherwise security breaches may, inadvertently, come up.
Third party software should not be modified, except when strictly necessary. Internal security controls can be invalidated. This change should be made by the original system developer whenever possible.
Personnel
Training and qualification of programmers should be provided for the acquisition and review of computer security principles and the development of secure software.
Internal assessment shall be conducted periodically to ensure current industry/community best practices are been adhered to.