We follow a ten step cascade process that brings our customers up to speed quickly, but without sacrificing quality. Iterative processes can be used for development that builds on existing functionality, including but not limited to new design implementation, content architecture processes and application enhancements. Some smaller applications can also use a iterative process if the end product is well suited to that model of development.
Ten steps does not mean that the project will drag on forever, instead it insures that your project is executed completely. A small project, such as a form to collect information to be stored in a database might pass through multiple steps in one day, while more complex applications might pass through some steps quickly, but spend longer on the planning phases.
Our first step is to meet with you to discuss what your trying to accomplish with this particular project. Sometimes the goal is simply to refresh an already existing application with a new User Interface, other times it's a complete re-build from the ground up to facilitate new business goals. Whatever the reason, it's important that we establish clear goals so we can be successful in our strategy for meeting them. Key items we will end this phase with are:
A clear understanding of the target audience for the project
A clear understanding of the position in the marketplace
A clear understanding of the goals of completion of the project
A plan for measuring the success of the project - if warranted
The second step is to consider the systems required, this often will begin with a reality check to what we're trying to accomplish. While anything, given unlimited time and resources can be done, it doesn't mean you'll want to invest that much into the project. Technology costs can escalate quickly if goals weren't clearly defined in phase one of the project. Outcomes from phase two include:
A user architype, a sample user (or two) who can be used for decision making regarding the functionality of the application.
A clear understanding of the content, through a content analysis provides the developers with a framework with which to build the necessary class diagrams and workflow charts. Additionally, effective grouping and organization of the content can facilitate the design of your navigational structure. Expected outcomes from this step:
Inventory audit
Navigational structure
Next a prototype is made, this is often a series of mocked up screens but in more complex applications, may include a paper prototype or a paper model. The purpose of this is to discuss functionality early one before developing the actual application. It provides a firm framework and foundation from which discussions about expectations, functionality and features can be discussed without speaking in abstract terms. Additionally, a firm user-interface paradigm is established at this point, along with consistent use of terminology, control widgets and interface cues and help. Expected outcomes from this step are paper or onscreen prototypes, flow diagrams of how simple tasks are accomplished and class diagrams that illustrate how the site will be built and work.
Prototypes (digital / paper)
Class diagrams
Workflows
Often concurrently with the beginning of phase 6, the design process will begin. Depending on if the application is to be integrated into an existing design or involves a full redesign development work would remain focused on implementing the back end functionality first. If warranted by the project, design concepts will be presented, along with a model of how the application might look within a specific design. This will begin an iterative review process to create the design which best suits your needs without sacrificing accessibility of the applications. Outcomes of this phase are:
Design concepts
Design documentation and styleguides
Review and approval
The development of the application begins. The hard steps are out of the way. A design is in the works, the workflows and data structures have been created, finally, actual development begins. Development can take multiple paths, but each component of the class diagrams (if included) are built and tested during this process. In an iterative process model, phased release into existing applications may occur to facilitate the ultimate move to the new feature rich state that is being developed. This backend first approach allows the design process to proceed unhampered by development. Expected outcomes from this step would include:
Fully functional class files
Construction of database schemas
Integration of front end (web) pages
The next phase implements the design with the technical aspects of the project. Merging these two components can be challenging, however, through solid documentation this step often goes smoothly.
Real world testing brings the application online in a test environment and allows for a selected group of individuals to actually try to use the application. Since prototypes and archtypes have been using this system since it's inception, there is often very little feedback at this point. This is really an affirmation of the decisions made earlier in the process. However, should any changes need to be made, a punch list of issues is created and addressed. Expected outcomes from this phase include:
A punch-list of questions/answers/changes to be addressed
Real world validation of the application
Identification of next steps in an iterative process or future development
Some projects require a training program which can be built as part of the application, documentation or be hands on in a controlled environment. This is dependent on the application and its intended audience. Not all applications require training, however, especially with office automation projects, it is highly recommended. Public facing application, like those for email newsletters, should be self explanatory for the public and often can be supported through either online or printed documentation.
Lastly, we roll the application out. Any issues not resolved with the testing period are resolved as uncovered for a two-month window following the launch of the application. This is the day we've been waiting for! A final analysis for measuring the success of the project should be conducted, documenting any shortcomings, changes and modifications that might be necessary for future versions.
While it seems like a lot right now, some projects can be completed in as little as two or three days! Remember, depending on the scope of the work to be completed, some steps might be skipped!
