This list of 10 ways to cut cost from the app dev lifecycle comes from Experimentus, a UK-based software management consultancy…1. Focus on well documented Functional Requirements
Without well documented Functional Requirements, there is potential for a system to be delivered which does not meet the customer’s expectations. For example, perhaps it does not work as they believe it should – even though the development team believe that they have worked in line with the requirements as documented. This can lead to development rework, which is likely to delay the release, increase costs, and create discord between the customer and the software team.
2. Ensure all Non Functional Requirements are clearly defined early
Many organisations focus solely on the Functional aspect of systems – WHAT it does – rather than the Non-Functional – HOW it does it. Non-Functional elements comprise everything from performance to security to usability.
Without clear, early definition of Non-Functional requirements, it is possible that a system could be delivered which does exactly what the customer wants – but is difficult to use, slow, insecure, unreliable, or is not scalable. Once again, this can lead to development rework – although some non-functional areas are so integral to the design of the product, it can be difficult to correct them without starting the project again.
3. Ensure change control procedures are in place
Without Change Control, system development can find itself in an uncertain and constantly changing state. For example, development may be initially performed against what is believed to be the final version of a requirements document. However, more changes might be made to the requirements whilst development continues, each change without a proper impact assessment.
Content from our partners
As there is no procedure for consulting with or informing development of the changes, it may not be the case that the knowledge of the changes is passed on in a timely fashion. Additionally, the impact of some changes might be so large that they cannot be incorporated into the software easily at a late stage. In this case, if the changes are deemed to be vital, major development rework might have to take place. For these reasons, every change should be strictly controlled. Change can be allowed, but should only take place after a full impact assessment to see how it will affect the project timescales and costs.
4. Ensure strict Configuration Management is in place for code, data and documentation
Without Configuration Management, a high quality of testing is impossible. This is because there cannot be high levels of confidence that the right version of the software or documentation is being tested, or that the right version will be released to the customer.
Organisations with poor Configuration Management might test one version of a product, and yet perhaps release a slightly different version – a version which then enters the field UNTESTED. It is viewed as untested, as potentially major faults may have been introduced which change the behaviour of parts of the system from that which was intended – or, in some cases, even disabling the entire system.
5. Focus quality approach on product risks, focus on preventing rather than detecting defects
It has been proven many times that the later in the software development lifecycle that a defect is found, the more costly it is to rectify it. For example, correcting a mistake in a requirements document before development begins is a far quicker and cheaper activity than correcting the software after it has been developed against the faulty requirements document.
6. Begin UAT(User Acceptance Testing) test design during requirement definition
If an organisation is using the ‘V-model’ of software development correctly, then the test team should be involved with the project from the very beginning – during the requirements definition. Not only can the testers use their expertise and experience to help assess whether or not particular requirements are testable or not, but they can also start to design the relevant tests, which helps to ease the test schedule later.
In this scenario, the User Acceptance Tests should correspond directly to the user requirements. This is because the requirements are the items that the user wishes to see in the system, and the tests represent the way that the system is proved to meet those requirements. It clearly follows that the best time to write the UAT is when the requirements are being constructed.
7. Begin system test design during the system design stage
It is important that the system is designed to be easily testable, if possible. This can only occur if testing expertise is involved in the system design stage. Collaboration between the testers and the system designers can help ensure that the system produced fulfils this aim. During this early involvement, the testers can also start to construct the System Tests, which helps ease the testing schedule. An additional benefit to this approach is the enhanced team collaboration between the system design and testing team.
8. Focus test effort on unit test where it is cheaper
As previously stated, correcting defects earlier in the software development lifecycle is far easier, quicker and cheaper than otherwise. Given this axiom, it is surprising that many organisations spend little or no time on unit testing activities – often with the reasoning that “our developers develop, and our testers test”.
However, not only does this approach mean that potential defects reach later stages of testing than they should, it is possible that they may not be found at all – as later stages of testing normally perform different testing activities, in different ways, to those used in unit testing.
9. Plan test approach using risk to define focus of test effort
Test time is often limited, due to reasons like fixed release dates, or late software delivery from the development team. This can often mean that not all tests that were originally planned are carried out.
In this scenario, it is vital that those elements of the system that are considered critical to product success have been tested. Therefore, the approach to testing should always be to focus effort on the ‘highest risk’ areas of the system first. Following this, medium risk and low risk areas of the system can be tested, in turn, as time permits.
This risk-based approach ensures that, when under time pressures, the areas of the system which remain untested (and potentially flawed) are the lowest risk areas possible from those that are left to be tested.
10. Use tools to test for functional and non functional errors very early on when they are cheaper and more effective at removing errors, and throughout the lifecycle
If an automated test set is created and maintained, it can be repeatedly utilised from an early stage of the software development lifecycle, as a ‘smoke test’. This method has the potential to find a lot of defects quickly at an early stage, saving time in later test phases.
Additionally, sometimes specific tools may indicate flaws in the system design – which should be exposed as early as possible. For example, early performance testing on parts of the system that are available might reveal a poorly-designed module, which would hinder the system beyond the tolerance levels of the user when released.
In this way, the module is easily identified, isolated, and fixed or replaced – an activity that would be much harder if performance testing was only conducted when the system was about to be delivered to the customer.
