Application Development

All projects begin with the Briefing. Here, you tell us your ideas about the project. What are your goals? What constraints will come into play? Are there third-party products (either software or hardware) that your project needs to interact with? During this phase, we engage in "active listening"-seeking to understand your needs by asking questions. We also share with you the risks entailed in any software project and explain how we use Interface-Driven Architecture to consistently achieve successful projects.

Objectives

• Consult with client on overview of project
• Introduce Interface-Driven Architecture

Deliverables

• "Successful Software Projects: From Architecture to Fabrication" booklet
• Project recommendations--a plan for going forward with your project

During Analysis, the project begins to take shape. In order to understand your business processes, we will often ask to "shadow" those involved in the day-to-day work that the project is concerned with. This "mini-apprenticeship" ensures that we incorporate the way your company works into the software we create. During this phase, we will create personas that mirror the various users (often with different needs and goals for the software) and create a shared vocabulary that identifies the various users, deliverables, and processes the software must account for.

Objectives

• Review existing business process and infrastructure
• Identify organization/brand position
• Align goals of the client and the software development firm
• Discover personas
• Create use cases
• Develop relational semantics (shared vocabulary)
• Research supporting technologies

Deliverables

• Project Analysis Report

Once Analysis is complete, we begin a process of designing how users will interact with the software. This is far more than "look-and-feel"-this process shows users what appears to be functioning software. This "interactive blueprint" is the heart of Interface-Driven Architecture (IDA). User Interface Design is a highly iterative process that asks users for feedback, provides a new iteration of the interface, and asks users again for feedback. This process continues until:

• users tell us that what we've shown them is accurate and complete, and
• we are assured that we know everything we need to create a Software Architecture.

Typical development methodologies keep the user interface hidden from the user until delivery-when it's too late to make changes. The greatest reason (by far) for failed software projects is that the software delivered does not do what users need. By creating the user interface first in conjunction with actual users, we drive out the risk of project failure.

Objectives

• Define site/application structure
• Create site/application design
• Design user interaction

Deliverables

• Completed User Interface software

Usability Testing begins in the late part of the User Interface Design phase. Working with virtual focus groups, we use special software designed for testing user interaction with the interface. One source of project failure is user rejection—the software is just too hard or too frustrating to use. By methodical usability testing, we discover in advance any sources of difficulty or frustration and make any adjustments necessary. While usability testing is routine on commercial off-the-shelf software, it is an unfortunate rarity in the custom software development process

A software vendor not doing usability testing should be prepared to explain what they know that companies such as Apple, Google, and Microsoft (all of whom do extensive usability testing) do not.

Objectives

• Assemble virtual focus groups
• Test use cases

Deliverables

• Usability report

Robust software--software that readily adapts to the changes in your business--is built from individual modules. Each module must be carefully specified. Without this attention to structure, software quickly becomes brittle. In this step, we employ software best practices (known as design patterns), expressed in UML diagrams, and a solid relational database schema. It is, in large part, this step of component modeling that will determine how robust, scalable, and maintainable the final code will be.

Objectives

• Create domain model
• Create data schema
• Create API (Application Programming Interface)
• Create user documentation/help system

Deliverables

• UML class diagram
• Entity/Relationship persistence diagram

Interface-Driven Architecture makes back-end coding far easier, faster, and less expensive than traditional development methodologies, since the business rules and system requirements have been firmly established. While some shops may specialize in a particular programming language, the language and database should be chosen to best fit the type of project you envision. Further, all code should be fully tested to ensure that deployed software will be free of dangerous “bugs”.

Objectives

• Code system components
• Perform unit testing
• Perform coverage testing
• Perform load testing

Deliverables

• Beta version of your application deployed to testing server

During the coding phase, developers do their best to build robust code. During the Beta Testing phase, dedicated testers do their best to break that code. In too many development shops, beta testing is left as an exercise for the user. But, just as editors help writers produce the best possible product, testers work with coders to ensure that annoying and possibly costly bugs are discovered and “squashed” before the software is launched. At the end of the Beta Testing phase, acceptance testing should be performed. An acceptance test is a formal review in which you agree that the system has been fully and accurately implemented.

Objectives

• Test all use cases
• Conduct acceptance testing

Deliverables

• Deployment-ready software

When the proceeding phases have been conducted properly, the launch of your project should be a straight-forward process. The Deployment step simply moves the fully tested and accepted software into a live environment, adjusting the necessary parameters in a declarative configuration file.

Objectives

• Prepare server environment
• Deploy code to production environment from testing server

Deliverables

• Archival DVD with production code and supporting documentation

Once your project is deployed, Live Monitoring regularly checks system performance to provide metrics on usage and load. A monthly report is provided with any steps needed to ensure the ongoing health of your project.

Objectives

• Ensure stability and continuing performance of the system
• Report on usage and system load

Deliverables

• Monthly System Health Report