Ideal Stages of a Software Development Project
For almost a decade, Transcending Digital has been working with creative teams to deploy premium software experiences across North America and Europe. Throughout this tenure an ideal step by step process has emerged for creating solutions that not only satisfy the business requirements, but most often go above and beyond. This strategy will work for kiosk and experiential applications as well as enterprise level applications. If desired this process can be utilized in an agile environment. The list of ideal steps that we like to use in a software project are as follows:
- Proposing or Brainstorming and Deployment Information Gathering
- Rough Sketches
- Stakeholder Feedback Based on Sketches and Wireframes
- Formal Design
- Design Feedback
- Software Development Starts
- 1st Software Delivery (Alpha Delivery)
- Feedback Period and Design Adjustment if Needed
- 2nd Software Delivery (Beta Delivery)
- Feedback Period and Minimal Design Adjustment if Needed
- Final QA
- Final Software Delivery / Install
- Post Delivery Training
This list may seem daunting, but it ensures all stakeholders walk away with positive results. Depending on the type of project, some of these steps can be substituted or removed. We will now take a look at each step in detail.
1. Proposing or Brainstorming and Deployment Information Gathering
We mention Proposing or Brainstorming as the particular situation will be dependent on your business situation. The process in this step is the same for all situations. This is where you will come up with ideas about the desired software to create. Put your most wild ideas on the table and make an exhaustive list of all of the functionality you would like from the application or experience.
After you have created your exhaustive functionality list, it is a good idea to start gathering information about how and on what hardware the software will be deployed. It is a good idea at this stage to also start thinking about application intent and goals. This will help eliminate non applicable functionality from the initial brainstorming process and refine the concept. Once you are confident the conceptualized software can be deployed to your target environment it is finally time to move on to step 2!
2. Rough Sketches
Rough sketches are a wonderful way to further refine ideas generated in step 1. Depending on the organization this step could be combined with step 1 or eliminated entirely. More experienced teams may wish to move straight into wireframing. At Transcending Digital we usually sketch using paper and pencil or on white boards. Charles, our Principal Software Architect keeps a notebook with sketches. A notebook with sketches will allow future reference to original conceptual intent during the programming and design phases.
Wireframes are similar to process flow charts used for business planning. They typically illustrate the entire visible layout that a user interface will be comprised of. You may be able to use step #2 sketches in place of wireframes if you sketch out the entire user interface. It is important that you do not skip the process of sketching or wireframing the user interface. This sketch will be given to designers and software developers. Often in Enterprise environments, user interfaces are created that contain way too many confusing buttons or forms. Confusing user interfaces can usually be attributed to skipping the sketch or wireframing process. Here is an example of wireframes for a simple full screen user interface that preforms the following:
A. Has an attract loop video that users can touch to continue.
B. Allows the user to take a photo.
C. Confirms or denies the photo.
D. Option to Email the photo.
4. Stakeholder Feedback Based on Sketches or Wireframes
At this point it is a great idea to solicit stakeholder feedback if possible. Once formal design starts in #5 the ideas and concepts become much more costly to change. The wireframes or sketches will give stakeholders something concrete and not conceptual to visualize. Wireframes can be quickly changed or added to depending on solicited feedback. It can also be helpful to request software development feedback to ensure the capabilities described are possible.
5. Formal Design
Formal design is the process of obtaining an actual graphic designer or design team to create beautiful original graphics. Depending on the budget, developer skill set, and software requirements, formal design may be skipped. If the application relies on a visual user interface it is advisable to have some sort of formal graphics created for use in stakeholder feedback solicitation. At this stage, other media assets may also need to start production such as original videos or narration.
6. Design Feedback
This is another critical feedback step. Before actual software development begins in #7 it is important to get approval for the created designs. It is important to not skip this step because the design is fresh in the designers mind. Providing feedback at this stage will make it more cost effective for a designer to correct any issues before their role in the project is completed at the conclusion of this step. In rare cases, the designer may need to create more graphical elements at a later time but that tends to be an uncommon occurrence unless application scope changes late in the process.
7. Software Development Starts
We have finally made it to the start of software development. Designs, wireframes, and any supplemental sketches should be provided to the developer(s) so that they can create the software. The development team should coordinate with project managers to outline a timeline and scope of features for the first software delivery in step 8. The initial software delivery may not be a complete subset of all desired functionality. It is important to try and ensure that the most critical functionality makes it into the alpha delivery if possible. An agile development process can be implemented here with project managers. However, over use of "stand-ups" should be avoided unless the development team is inexperienced and requires lots of feedback and support. Stand-ups are short meetings that in general if not implemented correctly waste time. A good time for stand-ups are in the two weeks prior to a major software delivery.
8. 1st Software Delivery (Alpha Delivery)
The development team should provide a working software build for review on a determined date. If special hardware is being used it may be a little more difficult to review the actual software. If utilizing special hardware, at minimum videos should be provided for review. Cases requiring videos could include software that incorporates environmental sensing technology like the Kinect, special projections, monitor arrays, access to simulated networks, or assets to name a few.
9. Feedback Period and Design Adjustment If Necessary
All stakeholders should be involved in the alpha delivery feedback. This is the most flexible time in the software development lifecycle to implement changes. It is important to collect consolidated feedback from all stakeholders and deliver it in one round. If feedback trickles in piece by piece it does not allow an effective and efficient response to changes. Feedback that is not organized and consolidated can also include hidden contradictions wasting time and money of all involved.
If the feedback raises the need to refine graphics, the graphics production team may need to become involved again at this stage if the development team cannot handle the changes on their own.
A work schedule and deliverables should be agreed upon by all parties for the next software delivery.
10. 2nd Software Delivery (Beta Delivery)
The beta software delivery should include mostly complete functionality. The only exception to a beta delivery with non complete functionality should be late Alpha feedback or an overly aggressive schedule. This delivery should provide stakeholders with an opportunity to see an almost completed project. This version could still contain bugs that must be fixed. You should aim to break software during this review to ensure that all errors are found.
11. Feedback Period and Minimal Design Adjustment if Needed
After the Beta software delivery it is again important to obtain feedback from as many stakeholders as possible. If approvals were delegated for the software project; now would be a good time to pull in the big boss to look at an almost completed project. In an ideal scenario any feedback at this point will be minimal. If the project has significant changes at this point, it may be a good idea to include a 2nd Beta software delivery before the final delivery if possible. Adding or modifying significant functionality at this late stage will increase the risk for bugs dramatically. Typically when a software development project starts, a developer will plan out a structure for the application that attempts to organize and simplify the code. Programming will follow this structure as much as possible. When changes are introduced late into a project the likelihood of it breaking the structure can increase significantly. Certain programming organizational techniques can help mitigate late breaking changes but not eliminate them. It is especially risky to introduce late changes with a junior team as they may not be as familiar with reducing risk related to late changes.
12. Final QA
QA in this context stands for “Quality Assurance”. This step involves thorough testing of all software to ensure that it is as bug free as possible. With a junior team it may be wise to introduce an additional round of QA earlier in the process to help isolate bugs sooner. However, if working with an experienced development team this is the ideal time to commence quality assurance. If no formal QA staff is available this is a good time to enlist any testers that can be found. The objective is to break the software. Make sure to thoroughly document the steps taken to cause an error if any are found. Video or photos of the process to create the error will be helpful so that the development team can re-create and correct any errors.
13. Final Software Delivery/Install
At this juncture it is time to preform the final software delivery. Depending on the job this could entail many things. It may involve traveling to a customer location to physically preform an installation. It could simply involve deployment of the software through a distribution platform such as an app store. Or, it may entail a production deployment with multiple levels of staff on standby. In any case, this is the big moment for the project. The culmination of all of the hard work. It is possible that unforeseen problems could show up during the production deployment. Usually it is best to plan for problems, then celebrate if there are none. It is critically important to schedule a buffer around this final install to provide a shakedown period of at least a week. In the context of an Enterprise this would mean having hands on deck for any problems that could show up in production and a rollback contingency. In an interactive context this means that any opening events should be scheduled at least a week away. In no circumstances should a final install be scheduled near a holiday.
14. Post Delivery Training
While the project is still fresh, post delivery training should take place immediately. Everyone will be exhausted but this is the perfect time for training. This is also the perfect time to complete any required documentation regarding the software project. Make sure to allocate time within any schedules for this critical step. Proper training will reduce support and help to resolve any hiccups for operations staff.
The project is finally finished! Now it is time to be prepared to offer timely support. The most experienced software developers can certainly reduce the amount of support; but very few projects can escape the need entirely. Ask yourself the question. Have you ever needed support for your Apple device or Windows OS? These are billion dollar companies and even their products require minimal support. Support resources should be allocated to each project. Support is one of the most critical aspects of a successful deployment and should not be taken lightly.