• Home
• About Us
• Services
• Products
• Contact

The ASAP process blueprint was introduced to ASF clients in 1996.

The AdAPT architectural blueprint was introduced to ASF clients in 1996.

Adaptive Solution Acceleration Processes

Adaptive - adjective; able to make fit or suitable by changing or adjusting.

Agile - adjective; quick and easy of movement; deft and active.

Traditional software development methods, as well as many of the latest fads in software development "methodologies," provide the basic steps necessary for constructing applications. However, they generally fail in creating a repeatable and consistent process that delivers opportunity for reuse, and that provides the potential for extensive growth and extension after initial deployment. These methods also perpetuate risk because they often don't take a business-centric approach to the architecture and design of the solution, often don't leverage business modeling to develop a deep understanding of the underlying business processes, and often don't produce for business users the interim deliverables that add value beyond the technology development.

Austin Software Foundry believes application development must be driven by a deep understanding of the business problem combined with an iterative, controlled software development process, in order to recognize the benefits of object-oriented technology. A significant difference between ASFs process and other rapid, agile, or iterative approaches are the boundaries provided by well-defined architecture and infrastructure. A business-driven, object-oriented process is flexible and open to adaptation to changing business and technology requirements. The benefits to this approach are:

• End-user Involvement. A business-driven process reduces risk by involving the end-users early and often, receiving feedback in the initial stages of the analysis and design. Changes early in the project life cycle can be corrected at a considerable discount, compared to those found later in the design or development phases.
• Better Representation of the Business. An object-oriented approach provides models of the business processes rather than descriptions of business functions. Object models mimic real world objects and are a rich representation of the business system being modeled. Because of this, they are a valuable component beyond the software development effort in wider business process (re)engineering.
  
• Simpler Modification or Enhancement. Modeling also is a key concept in reducing risk by providing interim snapshots of the application for review and change. It is easier to change the design of a new aircraft when a "model" has been tested in a wind tunnel,  than later on the assembly line.
• Reuse. The final stage in ASF's process is to generalize. Even in disciplined, engineering-oriented development groups, this step often is overlooked; thus explaining the lack of reuse in most software developed to date. The generalization phase takes the components developed for a particular application and abstracts the characteristics that are common throughout the enterprise so it can be reused in future applications. This is a key benefit to object-oriented development and the source of greatest Return on Investment (ROI) from this approach.

Iterative and Incremental

"An iterative process is one that involves the successive refinement of a system's architecture, from which we apply the experience and results of each major release to the next iteration of analysis and design." - Grady Booch, 1994.

ASAP is designed to help organizations successfully institute effective, iterative process management for object-oriented component and application development. It is based upon accepted and proven best practices from the last 20 years of software engineering, such as James Martin's timeboxing, Barry Boehm's risk adjusted spiral, Bertrand Meyer's clusters, Grady Booch's round trip gestalt, the Dynamic Systems Development Method from the United Kingdom, and Sutherland and Schwaber's SCRUM.

Each phase and every activity level is associated with a clearly defined, deliverable "product." Deliverables consumable by the business or end-users must be produced at least every 90 days during a project.  Early in the process, the analysis and design phase produces such deliverables as use case models and object models. These deliverables evolve into prototypes, dynamic models, subsystem models, test scenarios, etc. With clearly defined, deliverable-based milestones throughout the process, ASAP metrics are easy to institute and track.

Incremental Organizational Change

Austin Software Foundry recognizes that organizations have invested heavily in developing their own approaches and best practices. And often, new processes are rejected because they require an organization to abandon years of effort and to weather extreme cultural change. ASF also believes organizations should adhere to certain standards and proven approaches. ASF's approach leverages the artifacts you have accumulated on previous projects with industry-standard techniques, templates and examples.

One successful technique is to use ASAP on a "Proof of Concept" project. ASF works jointly with you through a complete life cycle of a portion of an application and collects artifacts for customizing ASAP to your corporate needs. This approach provides your staff with a familiarity of the vocabulary, techniques and concepts while accumulating meaningful examples from your business that will serve as the first step in customizing ASAP to your corporate culture and business domain.

The ASAP 12-Step Approach

In response to client requests, ASF has developed a simplified version of its ASAP development process for organizations who are new to rapid, interative software development processes. This stripped-down approach has been used successfully to introduce iterative software development practices to both large and small organizations.

• One - Conduct feasibility and risk assessment.
• Two - Establish business vision and initial requirements.
• Three - Conduct joint requirements planning workshop(s).
  • Produce initial business and system use case models.
  • Produce initial problem domain object model.
  • Produce initial software requirements specification.
• Four - Cluster business domain classes and produce initial estimate(s) of complexity and effort.
• Five - Produce project baselines.
  • Software requirements specification -- Combine business and technical requirements in a formal repository (document, CASE tool, web site, etc.) with the business use case model and problem domain object model.
  • Project plan -- Assign use case categories/class categories to timeboxes, set timebox objectives, assign resources to timeboxes, produce timeline.
  • Architectural model -- Produce architectural model combining use case view, logical view and component view and divide model into categories.
  • Infrastructure -- Define development infrastructure (tools, OSs, configuration management, etc.) and deployment infrastructure (OSs, client configuration, server configuration, etc.).
  • Database -- Produce logical data model and create physical database prototype.
  • User Interface -- Produce prototype of user interface to define style, navigation, workflow, etc.
• Six - Establish timebox rhythm (daily build, weekly build, etc.), select and prioritize features to include in timebox, enter first development timebox.
• Seven - Develop.
• Eight - Integrate and build, iterate to Seven until next build date.
• Nine - Integrate and test timebox deliverables and plan for next timebox.
• Ten - Deliver timebox increment, conduct timebox post mortem, iterate to Six until there are no more timeboxes.
• Eleven - System quality assurance, packaging, implementation planning.
• Twelve - Deliver and install.