Method
The most difficult part of any software project is developing a shared understanding of the functions of the application. The most difficult part of creating an online application is developing a shared understanding of its features and functions. Designers need to understand the customer’s business rationale so that they can place it within the context of an efficient and engaging information architecture. Developers need to understand the user’s intent such that the implementation is transparent to the requirements. Business stakeholders need to understand what the team intends to build so they can make informed decisions about the costs, benefits, and priority of various features.
The Jonah Group's method is aimed at developing shared understanding early in the project's lifecycle and revising it as new information becomes available.
Introduction
This document provides an overview of The Jonah Method. Detailed information can be found in the White Papers section of this site.
The Jonah Method is a synthesis of ideas from Jacobson's use-case driven Object-Oriented Software Engineering method and lightweight methodologies like Scrum and Extreme Programming (XP) such as automated unit testing, continuous integration, and frequent, iterative delivery.
While there are some practices we employ for all projects, we believe that only those elements of a methodology that are appropriate for the project at hand should be selected, and further that these can vary widely from project to project. Before we engage, we deliberately choose and clearly state which of the practices we think are most appropriate, and why.
The use cases describe the requirements of the application. All models, designs and source code are based on the use cases. This makes it easy for programmers to find the origin of a business rule and ensures that the system implements functions as specified in the use cases.
During the build phase of a project programmers translate the requirements and designs into source code. If a programmer can’t find a business rule to cover a condition or situation, she must invent the business rule herself or delay the project while analysts try to locate or invent the requirement. Obviously, programmers should not be inventing business rules, but it happens regularly in projects where the technical design is poorly related to the business requirements.
Following are some of the benefits of The Jonah Group’s method:
- Costs and timelines are predictable
- Our iterative planning technique reduces risk
- Security is built into every Jonah application
- Our applications support thousands of users
- Process overhead is kept to a minimum
- New requirements are accommodated
- Program structure is based on business objects
- The application is tested throughout the project
Process
The Jonah Method has six phases:
Discovery occurs once in each project. The remaining phases - analysis, design, build, test, and deployment - are repeated for each iteration within the project. Discovery is the first phase. During Discovery, The functions of the application are split into iterations during the discovery phase.
Figure 1 - Iterative Project Plan
Iterations are scheduled one after the other. The analysis phase of the next iteration overlaps the deployment phase of the previous iteration. This helps reduce the overall timeline of the project. The biggest benefits of the iterative plan are:
- test and deployment teams are engaged early in the project.
- operations staff are able to tune the environment long before the application goes into production
- the business team sees value for money spent after only a single iteration, which may be as short as 2 weeks, but not more than 3 months.
Discover
Discovery occurs once at the beginning of a project. The main products of the discovery phase are a detailed project plan and cost estimation. During the discovery phase we define the vision, business case and scope of the project. The scope is defined by the list of use cases that describe the features and functions of the application. We flesh out the details of several representative use cases to understand the complexity of the application.
Figure 2 - Function Matrix
The use cases are plotted on a function matrix according to the cost and benefit of the function. The functions with the largest benefit and lowest cost are built in the first iteration and the functions with the smallest benefit and highest cost are built in the last iteration. If a deadline is reached or the budget is exhausted before the final iteration is complete, the high-benefit functions built in previous iterations can be deployed. Each iteration has Analyze, Design, Build, and Test phases.
Analyze
During the analysis phase we complete the use cases for the functions scheduled during the current iteration. The project plan, scope and cost estimate are refined and critical resources are identified. Feedback from the previous iteration is folded into the requirements. Scenarios and test cases are created from the use cases.
We focus on the user's experience to create the first cut of the interactive architecture for the application. The interactive architecture specifies the user's model of the application, content categories and navigation hierarchy.
Design
During the design phase the technical architecture is specified in detail. Object models and sequence diagrams are created from the use cases to describe the static and dynamic nature of the application. The Jonah Group has been developing object-oriented systems for over ten years. We are experts in creating object-oriented business models. Deployment diagrams are created to describe the tiers and processing nodes required to support the application.
Our interface design process creates the most intuitive and direct user experience possible. During the design process we focus on the user to create the information architecture for the site. The information architecture ties the data dictionary, navigation features and content types into a cohesive site map.
Building on the information architecture, we create user scenarios, storyboards and site maps to precisely describe the interface before the project moves to the build stage. Once these deliverables are created, The Jonah Group can analyze the usability of the interface to ensure that assumptions about the user experience are accurate.
Like the Technical Design, the Interface Design is driven by the use cases that describe the requirements of system. Using the same documents as input to both the Interface and Technical Designs ensures that the system is consistent from front to back.
Build
During the build phase, designs are translated directly into source code so the application mirrors the business environment directly. We develop object model programs to model the business environment, transaction programs to update the model, web pages to present the model, databases to store the model, and connectors to integrate other systems.
We develop automated unit tests in parallel with the application. These tests are run each evening to ensure that new code doesn't break existing code. Simple structural rules are coded directly into business object programs. Complex logic that affects several business objects is coded into transaction programs. Transaction programs are layered on top of the business object programs.
We use the site map and interactive architecture to render web pages that create the look and feel of the system. Input validation and other simple business rules are coded directly into the web pages to improve the user's experience. These pages are integrated with server-side business logic to deliver advanced business applications across the Internet.
All non-trivial web applications must work with other business systems. These systems include relational databases, transaction monitors, mainframe applications and third-party systems. In many cases, these systems are operated by other companies. The Jonah Group has extensive experience integrating databases, operational support systems and enterprise systems with web applications.
Test
In addition to the automated unit tests created during the build phase we test the complete business functions of the application at the end of each iteration. The application is deployed to the test environment so capacity and resiliency testing can be performed. Installing the application in the test environment at the end of each iteration forces operations staff to take ownership of the application long before the application is released to end users. Operations scripts and processes can be developed in parallel with the application, which reduces the overall duration of the project. During the test phase, defect reports are collected and analyzed. Defects in early iterations can be avoided in later iterations.
Deploy
During the deployment phase the application makes the transition to its user's community, which includes manufacturing, delivering, training, supporting, and tuning the application until the users are satisfied. Once the application is deployed, warranties and service level agreements come into play to ensure the ongoing success of the application. Training materials are developed to help users make the transition to the new application. Finally operations scripts are developed to manage the application.
Deliverables
The deliverables or artifacts include plans, models, diagrams, documents and source code produce during the course of a project. Following is a high-level list of the deliverables produced by The Jonah Group:
|
|
All deliverables are managed by a version control system and linked together through a project web site. Team members can retrieve information from any location. We have used these sites to manage distributed teams. The web site is archived on CD-ROM for quick reference once the application has been deployed.
Each project is carefully analyzed and the appropriate deliverables are selected. Usually the number of deliverables increases with the complexity of the project. The cost of the project is kept to a minimum by selecting the appropriate deliverables for the size and complexity of the project. It’s important to consider each deliverable and its value to the project. Making a conscious decision not to include a deliverable is different from forgetting to include it.
- Questions? Ready to move your project forward? We'd be happy to discuss a solution for your needs. Contact Us to find out more.
