Previous	Next
eBook – content table
The Bona Iqiniso concept	The qualitative techniques – concept
The Life cycle – context

The concept of a life cycle

From the life cycle context, we know that we are using a more generic life cycle reference model and a Bona iqiniso life cycle diagram.

Let us describe the concept of the Bona Iqiniso Life Cycle, using the more generic Life cycle reference model.

Life cycle methodology

Bona Iqiniso !

Life cycle

For now, we limit ourselves to the core life cycle of Bona Iqiniso. This corresponds to the software testing life cycle, which is a mirror of the product life cycle.

Life cycle phases

Life cycle phase	Criteria	Goal*
1. Inception Most activities will be in the business domain (e.g. risk, terminology, business cases, use cases, etc.), the application board (e.g. product breakdown, or product backlog, vision board, etc.), Roadmap (e.g. minimal viable product, major milestones, etc.) For the testing board it is the phase to get the first impression of the product under test, figure out the degree of involvement of software testing, make a first estimate, determine the risk levels of the product components, define the quality needs, etc.	Entry criteria – For Bona Iqiniso to participate in this phase, it needs to be invited. – It must be clear which organizational policies and strategies to use Exit criteria – First application board (high level) – First roadmap (high level) – First testing board (high level) – First description of the product by the business domain. – First estimates – (optional) There may be an intermediate decision to start the next life cycle phase if more a detailed description of the product or a logical unit** of the product is required to finish the first application board, roadmap, and testing board. – Formal approval of the product under construction, and closing of the inception phase.	Once the inception phase is concluded, the goal is to have determined what the product under test will be (Context), to have defined the major functionality/features of the product (Concept), to have estimated the effort and to have planned the delivery (from a business or client perspective) (Implementation), and to have a good sense on how to verify and validate the product (Verification).
2. Functional A product needs to be functionally detailed. Based on and with the participation of the business domain, the application board is detailed to the level that it can be estimated and planned in detail (roadmap). Static testing processes are used to verify the functional descriptions are SMARTER*** and in line with the business domain.	Entry criteria – Formal approval to go further than just the inception phase. This can but does not need to be at the end of the inception phase. it can be an intermediate decision during the inception phase. – Business domain stakeholders are known and are actively involved in the product – Initiated application board – Initiated roadmap – Initiated testing board Exit criteria – Detailed business domain (functionality, use cases, business rules, glossary, relationships, etc.) – Detailed application board (features, user stories) – Detailed roadmap (at least for a set of sprints/releases) – Detailed testing board – Risk-based approach is initiated (risk levels are known) – Formal approval per logical unit**	Once the functional phase is concluded, the goal is to have the product described in line with the business domain (context), in such a way that the application board is SMARTER*** (concept) and detailed enough to create a detailed delivery plan (implementation). The testing board (static testing) will verify the functional description is in line with the business domain and SMARTER*** (verification)
3. Technical Once we know what to build, we need to know how to build it and where. The business domain may give some indication, but most of the decisions will be taken by IT. The technology to be used, the architecture, etc. During the technical phase, a work breakdown of the product is made and work instructions are sent to the involved teams. The work breakdown will contain info for the upcoming releases, intermediate deliveries (sprint), updates, patches, etc.	Entry criteria – formal approval that the functional description of a logical unit** is done – product breakdown is complete (application board) Exit criteria – work breakdown is complete for the upcoming releases and intermediate deliveries. – work instructions are given to the correct teams	Once the technical phase is concluded, the goal is to have a clear view on how to build the product (context), The application board is detailed with the technical information of the product, where to build it, and by whom (concept). The technical phase delivered information such as architecture, infrastructural requirements, technology, etc. (implementation). The testing board (static testing) will verify the technical description on its completeness, correctness, gaps, traceability, etc. (verification)
4. Code Products need to be built. Teams organize and build the product according to its functional and technical description. Step by step the application board is implemented, following the roadmap and verified by executing code-related tests, but also by (static) reviewing the code. For testing, this phase is also called the TDD (Test Driven Development) phase.	Entry criteria – formal approval of the technical work breakdown structure – necessary teams are involved and participating – Infrastructure is ready for use Exit criteria – working code – Code is verified to be technically up to par. This is both by static testing and dynamic testing.	After the code phase is concluded, the goal is to have working software (context), by following the roadmap and the application board (product breakdown and work breakdown) (concept). Creation of the code is done by the core teams (implementation) and the same teams verify the software is working and complies with the functional and technical description. (verification)
5. End to end All separate pieces of code are integrated into a working system, combining multiple items of the application board, where functionality can be fully tested, end to end. This is done according to the roadmap. For testing, this phase is also called the BDD (Behaviour Driven Development) phase.	Entry criteria – Code is planned to be integrated and tested end-2-end. – necessary teams are involved and participating – Infrastructure is ready for use Exit criteria – Functionality is tested on its behaviour and this is end-to-end without interruption. – Test summary report proves the testing conditions have been reached. – Evidence of testing has been collected.	After the end-to-end phase concludes, the goal is to have functionality that can be used end-to-end (context). All involved teams integrated their code (concept). Following the roadmap and the application board, code is integrated in order to have an uninterrupted piece of functionality. (implementation). The functionality is tested from beginning to end without interruption mimicking the expected behaviour of the functionality (verification)
6. Acceptance The software development team has delivered a working functionality and verified that is according to the functional and technical description. Before proceeding, this functionality needs to be validated by representatives of the business to make sure that the functionality is what they expected. For testing, this phase is also called the ATDD (Acceptance Test Driven Development) phase.	Entry criteria – Functionality is ready to be validated by the business domain representatives. – Formal handover from the software development team is done Exit criteria – Representatives of the business domain validated all functionality to make sure the product is the right product.	After the validation phase concludes, the goal is to have confirmation that the right product is being built (context). Validation is done by representatives of the business domain using ‘workflows’ (concept). Business processes are executed under ‘live’ conditions (implementation). The functionality is tested from the perspective of the business domain, mimicking real-life process flows and data. (verification)
7. Tooling Once the functionality has been validated, also the non-functional requirements need to be fulfilled. Stress, load, performance, penetration, security, etc. are tested using specialist tools.	Entry criteria – Product has been formally accepted by the business domain – Non-functional requirements have been described Exit criteria – Specialist tools are used to verify that the product is compliant with the non-functional requirements. – in case of non-compliance, technical solutions have been defined, estimated, and planned (in scaled agile these are called enabler stories). Before finishing the tooling phase, the product will have to cycle back to the technical phase.	After the tooling phase concludes, the goal is to have confirmation that the product complies with the non-functional requirements or is sent back to the technical phase for fixing (context). Specialist tools have been used to perform non-functional testing (concept). Non-functional tests are executed to confirm compliance with the non-functional requirements (implementation). Test execution confirmed compliance with the non-functional requirements, or initiated the technical phase to start fixing non-compliance with the non-functional requirements (verification/validation).
8. External Once the product is in such a state that it is ready to be taken into production, a last step needs to be taken. If parts of the product are dependent on external partners, we need to verify that this part of the product is integrated well with the rest of the product by conducting joint testing. If the product is going to be used by external clients, the product needs to be validated by them as well.	Entry criteria – Product is validated internally (within the organization) – Product has parts depending on external parties – Product is used by external clients Exit criteria – external dependencies are validated – external clients have validated the product	After the external phase concludes, the goal is to have confirmation that the integration with software hosted by external parties is verified and validated and external clients have validated the product (context). Setting up mutual testing with external partners and clients (concept) and execute these tests till satisfaction of the organization, external partners and clients (implementation) will ensure the right product is being delivered (verification/validation)
9. Operational Once the product is taken into production, the organization wants to make sure the product is resilient and business continuity is guaranteed. By mimicking disruptions in the functioning of the product, the organization can make sure it can recover from such disruptions in an effective and efficient way	Entry criteria – Product is in production – possible disruptors have been identified Exit criteria – business recovery is effective/efficient – no data loss	After the operational phase concludes, the goal is to have made sure that the product was resilient (context). This is tested by performing tests that mimic a disruption in business continuity (concept). The execution of these tests is done on a regular basis (implementation) to ensure the business continuity of the product (verification)
10. Decommissioning At a certain moment in the product’s life cycle, the product is replaced, or alternatives are being used, necessitating the decommissioning of the product, making sure the remaining software products are not affected. It is possible that decommissioning the product requires all 10 phases in this life cycle	Entry criteria – a formal request to decommission the product – if necessary other life cycle phases necessary in the decommissioning process have concluded successfully Exit criteria – No more trace of the decommissioned product – All remaining software linked, or not, to the decommissioned product is functioning as intended	After the decommissioning phase concludes, the goal is to have safely removed the product (context). This is done by testing the remaining software with links to the decommissioned product (concept). Executing regression test (implementation), confirming the remaining software is still functioning as intended (verification)

* We use the cognitive behaviour approach to define each goal. That way, each goal feels like a task, where the goal is the ‘end’, and the context, concept, implementation, and verification are the ‘means’ to that ‘end’.

** logical unit is expressed by functionality, feature, or user story, or can be by delivery moment (increment planning, sprint, release). Each organization decides for itself.

*** SMARTER – S (Specific, significant, simple), M (Measurable, motivational, manageable, meaningful), A (Attainable, appropriate, agreed, acceptable, agreed), R (Relevant, result-oriented, result-based, resourced, realistic, reasonable), T (Time limited, time-framed, able to be timed, trackable, tangible, time-sensitive), E (Evaluated, ethical, enjoyable, engaging, evidenced), R (Reviewed, rewarded, recordable)

Life cycle practices & artifacts

For the life cycle practices and artifacts, we refer to ‘the methods – concept’.

Previous	Next
eBook – content table
The Bona Iqiniso concept	The qualitative techniques – concept
The Life cycle – context