How to ensure a robust and viable product lifecycle
Here are 9 things to consider, that will help you ensure a robust and viable product lifecycle
Initial viability: Based on the requirements, at the outset its essential to identify the appropriate platforms, services, technologies, and software dependencies and that these are a fit for the long-term service owners. This helps eliminate risks later and sets the landscape going forward. We also typically run through rapid prototyping of key features and infrastructure to further reduce risk especially where we are pushing boundaries and best practice has little or no defined pattern.
High level Requirements: With the landscape defined it would be important to put together overarching requirements and put together work items to form content for each iteration / sprint. we typically set the pace with sprints using agile methodology, delivering a working usable solution as soon as possible to the customer, once it has been approved by the QA function (typically this is a series of test processes, unit testing, automated testing, user acceptance testing, integration testing and manual testing) then it will be staged to the customer and approved before going to production. Some projects are user research lead, which would be a key part of defining deliverables for the sprint.
Security: We work within NCSC and OWASP guidelines and routinely asked to provide evidence of adherence to these standards which we can do on an ongoing basis (and should be doing). we typically use a third party to conform the security our work, this is effective for all concerned since it keeps everyone honest and transparent. There are various levels of testing that can be applied to a project and it’s something we have advised on to various clients. An external PEN test is very common, internal PEN tests (where the tester has a login to the service) less so but are very useful and provides confidence. There are various approaches beyond the basics and these should be designed by the requirements they need to meet.
Environment management: With each iteration we would initially deploy staging / testing environments and finally once all approved to production. For deployment to staging and production we will typically have a documented process of deployment and rollback process detailing the appropriate to implement or revert changes. It’s important to maintain a staging environment that is as close to production as possible, with all the features but not necessarily the horsepower.
Software Development: Where software engineering is required which is in most cases, we will maintain a very high level of unit testing and a strong code style to enforce documentation and good clean readable code for all software components. The versioning of each software component would use the semantic versioning system and would be using version control and a well-tested branching model (like git flow) to maintain a full product change log and history. Every change merged to a production branch in code undergoes peer review and approval. This may be straight forward or involve multiple runs of the code in different scenarios to explore the change fully. Nothing goes into a main branch without approval from a peer.
Automation: We typically implement automation from the outset and build upon it to reduce overall administration as the project matures. Initial setup does require more initial time but provides value throughout the entire process afterwards, and typically quickly pays early in the project.
Infrastructure and Configuration management: Where possible we will maintain configuration and infrastructure to source control allowing iterations of the infrastructure, and global configuration changes where possible.
Documentation: Documenting the various facets of a project does require design and planning to be effective, some creative flair would not hurt either. We typically do atomic documentation in parallel with the work items so infrastructure, design, discovery, software engineering, all happen as part of the process. The higher-level documentation covering a workflow, or several areas needs a little more planning and structure and is better done retrospectively once a feature line is completed since there may be many moving parts some of which are still work in progress.
Redundancy, Backups & Disaster Recovery: These elements are typically requirement driven and will need to be evidenced as part of a staged sign off. Some requirements like 99.99% uptime require additional costs and work to achieve. Based on requirements we design, test and evidence the solutions performance and iterate of required.
Healthcare
Government
Defence
