It is a RAD method made compliant with the Dynamic Systems Development Method (DSDM), the emerging de facto standard worldwide.

It deals with a number of aspects of a typical RAD project, including time boxing, prioritising and prototyping, and allows the project team to deliver quick, robust, user-driven solutions to the customer with a minimum of risk. ASF Method makes full use of the relational databases and Internet development tools.

It provides modeling and design techniques that support model-based code generation.

The high level of user involvement within ASF Method enables developed application system to deliver significant business benefits early.

Fully committed users and multi-skilled ASF developers form one team that on the agreed delivery date, together deliver the developed application system to the business.

Why to use ASF Methodology?

The main reasons for using the ASF Methodology is that You Know What You Are Getting and You Know When You Are Getting It.

This will drastically reduce the risks of the project as well as the costs. The ASF development cycle:

ASF Method Phases

1. Business Requirements Definition (RD)

The business requirements for the proposed system are identified, refined and prioritised by a tightly integrated team of empowered key users and experienced developers. The process often begins from an existing high-level requirements document and a scope document, such as the Project Scope, Objectives and Approach (CR.010). However, it is possible to begin from an agreed on scope and objectives before requirements have been defined. The Business Requirements Definition process delivers a set of requirements models and a prioritised list of requirements as a basis for system development

2. Existing Systems Examination (ES)

The majority of the tasks associated with the Existing Systems Examination process are only performed when the project objective is to replace or enhance an existing application system. Even if there is no existing system, it will be necessary to document the existing or proposed organisation and existing, relevant business procedures.

3. Technical Architecture (TA)

The Technical Architecture process specifies elements of the technical foundation of the development project. It assumes that the business already has an information system strategy and that these elements will fit within that strategy.

4. Database Design and Build (DB)

The Database Design and Build process makes sure that, through a number of steps, the final production database can be created. The process starts with the creation of the initial Logical Database Design (DB.002), which is refined throughout the process, and ends with the creation of the Production Database DDL (DB.050). The input for the initial Logical Database Design is the Business Data Model (RD.060), which is refined based on input during the validations of the modules.

5. Application Development (AD)

The Application Development process makes sure that, through a number of steps, mostly iterative, the final application is developed. The process starts with defining the Application Development Standards and Guidelines (AD.020), based on User Interface Requirements (AD.015) and the Look and Feel Prototype (AD.010). The Application Development Process is tightly coupled with the Business Requirements Definition Process. The requirement models from the Business Requirements Definition process are used as input for the Application Development process. When a (set of) module(s) has been developed for an iteration, and the module is reviewed by the end users, the requirements models produced in the Business Requirements Definition process are validated, and often need to be refined. Therefore the Application Development process also provides input to the Business Requirements Definition process, until the final production version has been developed.

6. Data Conversion (CV)

In order to avoid delays and to achieve better data quality, the first data should be converted as early as possible in the project. The amount of effort involved with conversion greatly depends on the condition of the data and the knowledge of the data structure in legacy systems and existing applications. In ASF Method the cleaning of legacy data is visibly identified as a user and IS staff task, so that it can be staffed and scheduled. If data anomalies exist in the current system(s), or there are an unusual number of exceptions, recommend data clean-up to the project sponsor.

The Documentation process centres on producing high-quality, printed and online help text deliverables. It produces all of the user, technical and training documentation for the project.

8. Testing (TE)

The Testing process is an integrated approach to testing the quality and conformance of all elements of the new system. Therefore, it is closely related to the review tasks in the Quality Management (QM) process of Project planing and to the definition and refinement of requirements in the Business Requirements Definition process. The Testing process addresses both functional and non-functional testing (such as performance-testing and stress-testing). It includes systems integration in projects with requirements for interfaces to external systems. In projects using the ASF approach, test activities are a shared responsibility of developers and key users, working together as an integrated project team. The Testing process presupposes that a high proportion of modules are visible to the key users (for example, forms and reports) to allow greater participation.

9. Training (TR)

Training process makes sure that users, administrators and other technical staff members are adequately trained to take on the tasks of running the new application system. Initially, the Training process focuses on the key users and the technical staff members who will maintain the system, so that they will be able to train other users and technical staff later.

10. Transition (TS)

The Transition process focuses on installing the system and then going production. It begins early in the project by defining the specific requirements for cut-over to the new application system. It then includes tasks to carry out the elements of that strategy such as developing an Installation Plan, preparing the Production Environment, performing the cut over, and decommissioning any legacy systems.

11. Post-System Support (PS)

The Post-System Support process is defined to monitor and respond to system problems via a help desk, to upgrade the application to fix errors and performance problems, to evaluate the system in production and to plan enhancements for increased functionality, improved performance and tighter security. The development project does not come to an abrupt end when the team installs the application system into production. In fact, the months following that milestone can determine the real success or failure of the project.