Our Software Development Process: The Launch
March 2, 2016
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.
Related posts
Introducing Auggy AI: A Conversational AI Assistant
Embracing AI sounds easy but it’s often hard to know what and how to implement AI. To that end, we built an internal custom AI assistant. Our AI assistant Auggy is built to respond accurately to questions regarding our internal policies, manage project tasks, and provide updates on JIRA, to create, and view events, allowing …
Why AI
Why are we excited about AI? There is definitely a lot of hype around AI. The hype is exciting but also deafening sometimes. Everyone feels the pressure to build and engage with AI. It’s magical, life changing. That’s kind of all true. But there is a lot of work to be done to achieve that …
Designer Diaries: Our discourse with AI towards customized design
UX designers often face creative blocks, making conceptualization and execution challenging, particularly when working under tight deadlines. Traditional design workflows can be time-consuming and relatively less productive. Hence in an attempt to rapidly generate new ideas, visualize complex information, and interact with the team, we chose to blend AI for the design process. So what …