Our Software Development Process: The Launch
This is the last post in our series Our Software Development Process. In this post we talk about the final phase: The Launch!
This is the last in a series of posts about our software development process. Our previous posts in the series walked you through all the stages of thinking and development an application: The Ideation Phase; Gathering Basic Requirements for a Proposal; The Proposal; Gathering Requirements; Creating a Backlog and Planning Sprints; Testing and Quality Assurance; and User Testing. In this last post we will look at how we launch the product to the world.In our most recent post in the series we talked about User Acceptance Testing (UAT). This is usually done on a separate server, called the UAT server. This is where the client/user performs their own testing after we do our own QA. The bugs found during the UAT are taken care of in the next two week sprint. Once the bugs are fixed, the pages are released to the world. They’re launched.
To launch the newly created, or edited, pages we move the pages from the UAT server to the production server. This is the server that serves the pages to the world. It’s an exciting and scary time. The project and pages we’ve spent so much time working on are now being released to the world.
At this stage we begin to receive feedback from users about the user experience. We can also look at the analytics to see which pages people are visiting and which are dropping off. This is more marketing analytics, but that helps define what changes need to be made to the site or product.
It is important to keep in mind that constant maintenance will be essential. This is especially true for high traffic sites and sites with more functionality, like ecommerce and other features like managing staff or projects. Another type of site that typically needs more maintenance is those with more integrations. From our experience, system/app/module integrations are more likely to need maintenance because if code changes in any one of these systems, it can break the integrations. However, this may not always be the case.
After the site is released it is important to practice regular QA. Have someone who is not a customer try to break the site. For a small brochure site with minimal traffic, regular QA is probably not necessary. But for a site with more functionality and traffic QA is a must.
Now that the site or pages are launched, you can look forward to the launch of the next pages being developed. With agile software development launching new pages happens on a regular basis.