Royalways Technologies specializes in building online ventures — new startups and strategic initiatives that are born on the Web. Online ventures serve their customers, prospects and suppliers exclusively via the Internet and build their brand through unique and rewarding customer experiences online.
Royalways Technologies combines strategic consulting, design, and engineering expertise to shape our client's business vision into an effective Web strategy. We provide sound and innovative online solutions for commerce, community, and brand building that bring online ventures to life — on time, on budget and on target!
Online ventures require more in-depth understandings of a company's corporate mission and its preparedness for meeting its goals. During this phase, core business needs are addressed, from market analysis and online brand building to existing marketing and communication strategies of the company.
The development process for each project is wrapped in a management layer responsible for the meeting of deadlines, schedules, budgets, and the building of teams and relationships throughout the project. During this phase, members of the various teams may be involved, but the goals are to create or respond to a Request for Proposal that succinctly outlines the needs of the project from the client's views. Included in this (as a part) may be a simpler Client Brief and some semblance of a realistic Schedule and Budget should be developed.
In this stage, we discuss with our clients important considerations like most appropriate domain name, content sourcing, point of contact in the organization and staff required for the online venture. Hosting and networking requirements are also discussed in this phase. Finally a requirement document is made for the concept planning.
The first real development step toward a solution takes place during the Concept and Planning phase. This is where the Goals, Messages, and Audience for the project are explored and decided. These are the most important questions that will be addressed throughout the project and have the most impact. Market Research can sometimes provide parts of the answers but the overall goals and messages must, at least, be decided consciously by the client.
The Requirements Document should address all of the design requirements for the project. Part of the Requirements Document should address the proposed Technology for the project, the market and the competition.
In this phase, the first examples of solutions are derived. The Requirements Document from the previous phase should provide all of the answers as to what the project should accomplish, but it is in this phase that the development team derives how it will accomplish these things.
This phase includes the development of many prototypes, often the first merely in paper and sketches, while later ones might be more elaborate. There are often two semi-parallel tracks of development. In the first, the experience (or front-end) team is designing the interface for the experience while a programming team may be prototyping actual technology solutions. Prototypes, for the most part, are examples and not the final solution. They are usually hard-coded, that is, they don’t actually work as intended, only appear to.
After the front-end interface is mostly finalized, it is time for the engineering team to integrate it into whatever technical prototypes they have been building. These technical prototypes are the results of research and development that concentrates on the back-end, technical requirements to make the front-end work properly. It is essential that the front-end development proceed before the back-end decisions are finalized.
Up to this point, all questions should have been answered in the previous two phases Any detailed, residual questions can now be answered by team members, based on the notes from the previous two phases. The idea, is that the careful planning already completed will prevent any big revelations from occurring that might change the scope or nature of the project. If this happens, however, it may send the project back to the Concept and Planning phase (that is, if the goals, audience, or messages sufficiently change), or at least, back into the prototyping stage. This is why it is so important to get those answers right at the beginning.
When production is finished, the project still isn't yet. It still needs to be tested and made live. At this point, everything should be finished and integrated into the Beta Build.
However, it is essential that every piece of the project is tested before it is launched. Testing here does not refer to User Testing but to component testing or Quality Assurance (QA). Every element and link must be checked on every page on every platform in every browser to create a professional product. Each series of testing, fixing, and rebuilding is labeled with a new release: Beta 1, 2, 3, etc.
Types of testing include Unit Testing (testing of every component), Integration Testing (checking the entire system works), Stress Testing (Testing the whole system under heavy load conditions), Content Testing (to be sure that the latest versions of content were used).
The Production Matrix is now reused as a Testing Matrix, for helping track all of the tested elements and components. The Test Plan needs to encompass all testing objectives and coordinate multiple testers working independently.
At the end of the Testing phase, when all problems have been fixed, the project can launch. However, this is not the end of the project. In many ways, it is only the beginning as the site will need to now be maintained with new content and interactions for as long as it is live. While minor additions can be added , major ones will need to be added carefully and may require a new approach to be developed during a new design cycle (back to Concept + Planning). Some websites don't need a lot of updating, but those which have constant and continuous updating of data (such as an online news site or store) will need not only a sophisticated content management system, but the support people necessary to keep it running.
Lastly, this is now the opportunity for the development team to reflect back on the development process and review what worked well, what didn’t, and why.