Building a Real Version – The Main Development Phase: [GreyLoud Guide to Software Project Management Part 6]
Welcome back to the GreyLoud University Course on ‘How to Ensure Software Project Success’ where we will pass on all our successful project experience to help you achieve your software application vision.
In this, the sixth article in the series, I will be covering the Main Development Phase. In the previous phase you reviewed the prototype and firmed up the Plan, Technology and Resources. Now, at the end of this phase during which the system is built, your application will have reached the state of ‘ready for user acceptance testing’ in its SDLC (‘Software Development Life Cycle’). The final crystallization of your vision is about to happen!
The main activities in this phase are:
• Finalizing the User screens
• Building the functionality in components and modules
• Testing at the component and module level
• Preparing the User & support documentation/collateral
• Formal QA to confirm the software is ready for client acceptance testing
Let’s look at them in a bit more detail:
WYSIWYG: Finalizing the User screens
So far you have walked through low-fidelity and high fidelity screens in previous stages. Now screens are hardened up and more detailed functionality is built behind them – maybe the finicky calculation and display of sales tax, or some clever text analysis – even facial recognition if you are building say, an avatar creation app.
This is definitely the point at which What You See Is What You Get. There will be opportunities to make changes after this point, but unless they are defect fixes you will have to take the pain of delay and additional cost or wait until the next version release to make the changes.
Assembling the jigsaw: Building the functionality in components and modules
Agile projects (the vast bulk of modern day development) are run using sprints, modules and milestones and these will be clearly defined during this stage. The sprint is a spurt of software development with limited objectives when components (discrete pieces of software functionality) are built and assembled into modules (blocks of functionality such as an account sign-up module). Each sprint aims to achieve its objectives within a timebox. Milestones do not move – unfinished work is carried forward in a backlog report and re-prioritised in the next sprint.
What this means is that you should not expect 100% completion of the plan – but you should expect the really important work to be completed during each sprint. For example, all the ‘Should Have’ requirements may not be met in a given sprint, but will be built later.
‘Don’t reinvent the wheel’ is a good old proverb and in software development it has its place – ‘re-usable code’ is the norm. Why build a content management system when there are plenty of ‘free’ systems available already? Inevitably, some code will have to be built and even ‘free’ components stitched together to achieve your vision – but the expertise required to do that successfully is huge.
Find the faults early: Testing at the component and module level
In agile projects, the programmer will be told to develop a piece of software using a specific software technology (such as java or php) and to ensure that the code passes a specific set of unit tests – the lowest level of testing. For example, these might include ‘verify that credit card number input from the account sign-up screen matches the correct 16 digit number format’. When the components are assembled into modules, their correct integration must also be tested.
Then there is performance testing – if a credit card check takes too long the user might lose interest – and a customer is lost. There are many other kinds of testing, but in all testing early defect detection is essential to a successful software project.
Of course, with a well-run agile project, the approach to requirements gathering, technical design and iteration should mean that quality is ‘designed in’, minimizing defects. That is why an experienced development team is essential.
Help! Preparing the user & support documentation/collateral
Nowadays, hard copy manuals are rarely issued – they are out of date even before printing is finished. Do you remember the last smartphone you bought? You were lucky if you had a printed Quick Start Guide. Nevertheless, today’s tech products are complex and need extensive ‘documentation’ and much of that is provided online. In the Requirements Gathering stage the forms of help provision will have been agreed – web pages, wikis, FAQs, forums and a support desk to suit your planned operational budget and to meet your planned customer satisfaction levels.
And it’s at this time that the web pages, wikis and FAQs will be created and initially populated. A smart software partner will be able to convert much of the user story content and technical design documentation into ‘help’ pages. Maybe you plan to outsource the support function and not run it yourself, but either way the people that have to resolve customer problems will need a thorough understanding of the application and detailed support collateral to help them. Bad support can kill even a great product, so building this collateral is critical.
Is it really up to scratch? Formal QA to confirm the software is ready for client acceptance testing
Now, at the end of this phase, the development manager should be able to tell you that the software is ready for user acceptance testing. This means that it has passed all the tests that were devised to ensure that the solution meets the business and technical requirements and has met the requirements of their formal QA process.
There you have it – your software application. Or do you? Does it meet your vision? Is it at least the Minimum Viable Product (‘MVP)? Yes, you’d better check that carefully. The next phase will tell you that when you really ‘lift the hood’ in User Acceptance Testing.
It’s a key contractual stage in the software project, but if you and your development team have followed our process and worked effectively with an open, agile approach then there should be no surprises. So, make sure you read the next and final article so that you run your User Acceptance Phase efficiently and effectively, ensuring the success of your software project. Don’t miss it!