Documented policies and procedures for development Deliverable Template

From MIKE2 Methodology

This deliverable template is used to describe a sample of the MIKE2.0 Methodology (typically at a task level). More templates are now being added to MIKE2.0 as this has been a frequently requested aspect of the methodology. Contributors are strongly encouraged to assist in this effort.

Deliverable templates are illustrative as opposed to fully representative. Please help add examples to this template that are representative of the proposed output.

Contents 1 Overivew 2 Example of a sample Development and Testing procedure 2.1 Requirements Definition 2.1.1 Understand User Requirements 2.1.2 Define Functionality 2.1.3 Build & Define Use Cases 2.2 Design 2.2.1 Define Data Model 2.2.2 Refine Functionality 2.2.3 Define Presentation 2.2.4 Define Interface Design 2.3 Build 2.3.1 Build Code 2.3.1.1 Client-Server Interface 2.3.1.2 Client side 2.3.1.3 Server side 2.3.2 Integrate code 2.4 Test 2.4.1 Technical Infrastructure / Test Environment

Overivew

The Documented Policies and Procedures for Development task addresses the uniform development & testing procedures to follow. With most clients there are standards and procedures that already exist; new procedures will have to be developed when existing ones are inadequate.

It is important that the information management environment have documented development & testing procedures. This environment has many different types of technologies that need to be integrated, so it is important to have such procedures well-established. These procedures should adhere to the standards developed in other tasks and should concentrate on when to use certain technologies and when and how software artifacts should move through the development process and into production

Example of a sample Development and Testing procedure

Listed below is a sample Development and Testing procedure:

Requirements Definition

This specifies the general steps involved in implementing and testing an application in an object oriented environment. Stating the methodology applied for the XYZ project, the programming model will not only explain how to implement the XYZ web site but even more be a reference for future enhancements of the once built new web site.

The present scenario will introduce the reader to the phases involved in developing the XYZ web site (and its future enhancements) as well as their deliverables. Since every phase has clearly defined interfaces to the phases before and after (inputs, deliverables), the tasks described within it can be executed by different groups of persons.

Splitting tasks to different persons or groups of persons is not only adding to the project organization’s flexibility but is also wishful because it introduces a four-eyes principle quality check.

Understand User Requirements

The conception phase starts off with the understanding of the user requirements. Therefore, the Implementation Team will take the user requirements deliverable of the User Requirements Team (approved by the client) and build an understanding of the intended business idea and processes.

The understanding will be further elaborated in workshop-style meetings with the User Requirements Team as well as with all relevant parties to be involved for development. The understanding will only be complete when all of the following aspects have been covered:

• strategic idea
• processes
• people involved
• technology

The coverage of all those aspects will eventually help to refine the user requirements as all relevant points of view are considered.

Define Functionality

With refined user requirements the mixed business/technology team defines the high-level functionality to be implemented in the form of a business concept. This concept will sketch the processes of the application, the people involved and the key requirements towards technology.

The project team seeks client approval for that concept before going further.

Build & Define Use Cases

The approach in developing functionality is incremental in essence. It comprises the definition of small units of change (compared to ’big bang’ versions) allowing incremental development of the functionality and increased ability to respond immediately to changes in business needs and technology.

The concept of component based development supports this approach and integrates concepts of use cases and proof of concept.

Each entity of functionality is therefore first defined as a use case with high-level scope of functionality first and then extended after a first release in the test environment. The focus is here on functionality and not on technology.

The use cases reflect the approach in implementing functionality using an iterative and incremental process.

Design

The design phase describes the business and technical specification of the application (or its enhancements).

The following inputs are required for this phase:

• (Design & implementation guidelines)
• Reference Architecture document
• refined user requirements
• defined functionality
• identified tools and technology to be used

The phase will provide the following deliverables:

• functional design
• technical design

Define Data Model

A second step in the design phase is to define the data model.

The questions to be answered in this phase are:

• what are the data needs of the application?
  (type of data, data fields, existing in current data model or new; if data fields are new a new database will be designed, if data fields exist in current data model, reverse engineering of database into Erwin needs to be done.)
• how should the data be provided?
  (data feed, database)
• how does the data provision relate to the reference architecture?
  (integrate in overall data model of XYZ)

The result is the data model of the application, integrated with the XYZ legacy system.

Refine Functionality

The definition of object model and data model adds to the specification of the application’s functionality. The designer will therefore validate and detail the functionality in interaction with the user requirements team.

Define Presentation

This step defines the user interface and its generation. It consists of the following activities:

• design of the graphical user interface
• identify the static and dynamic components in the user interface
• identify the navigation components in the user interface
• design HTML scripts
• identify the data persistence needs and design them using different options like database storage or caching (with applets or JavaScript).

Define Interface Design

This step defines the internal and external interfaces. It consists of the following activities:

• Identify the interfaces
  - between the application and external systems
  - between the presentation layer and the business logic layer
  - between the different layers of business logic
  - between the business logic layer and the data layer
• Define the interfaces
  – needs
  – implied logic
  – methods applied
  – input/output variables
  – exception handling
• Agree on defined interfaces with 3^rd parties
  The clear definition of interfaces with 3^rd parties is crucial for a high quality system development. The project team will therefore invest on clearly defining and agreeing on the interface (e.g. IDLs for CORBA) and the vocabulary used (e.g. XML vocabulary) with 3^rd parties.

The interface design may lead to precision of the object and data model. The designer will therefore validate its consistency with the latter two.

Build

The build phase describes the translation of the technical designs into runable source code as well as its integration.

The following inputs are required for this phase:

• (Design & implementation guidelines)
• technical designs (object model, data model, user interface design, interface design)
• functional design

The phase will provide the following deliverables:

• refined object model
• server code
• client code
• interface code

Build Code

With a refined object model the developer builds the code for interface, server and client.

Client-Server Interface

Based on the interface design - in an ORB based environment e.g. a well-defined IDL - the developer implements the logic to locate in the interface. He makes sure that the input stream of the client side as well as the output stream from the server side are complete and accurate end to end.

Client side

Based on well-defined interface specifications as well as the user interface design the developer implements the client side code. This comprises the user interface (with a special focus on navigation, validation and data persistence) as well as the data transfer to and from the interface with the server.

Server side

The implementation of the server side code comprises the following items:

• Build servlet script code
• Refine existing server utilities (identify Java package)
  - Persistence
  - Exception
  - Logging
  - Exception
  - Database access
  - XML/XSL/HTML
  - Mail
• Integrate with legacy system
• Build application level security

Integrate code

The build phase delivers not only runable server code and client code, but much more an integrated system. The integration of the two sides is therefore a major step in the build phase.

Test

The test phase describes the verification of the correctness of the application built compared to the user requirements and the application design. Testing is an ongoing process throughout the development of the application and applies to different levels:

• Component level
  (Each component built has to be tested individually for correct implementation of design. This test level is called ’component test’ on this engagement.)
• Use case level (business sequences)
  (Each sequence consisting of interacting components has to be tested individually for correct implementation of sequence diagram design. This test level is called ’integration test’ on this engagement.)
• Product level
  (The overall product has to be tested for correct implementation of functionality design. This test level is called ’product test’ on this engagement.)

Each test level is linked to a specific level of the build phase. A strict sequence of testing applies, beginning with the component test and ending with the product test. This staged test approach will guarantee a focused validation of the technical, functional and conceptual designs elaborated and a high-quality stepping forward from the specific to the general.

The test phase concludes with the last stages leading to acceptance (acceptance test) and rollout (release/rollout test) of the product.

Technical Infrastructure / Test Environment

For the different test stages a test infrastructure has to be set up. It consists of three different environments used for specific purposes. The following setups will have to be provided:

• logical environment setup
• physical setup
• test data
• test IDs/passwords
• 3^rd party setup

An engagement following an incremental development approach according to CBD will test components in it’s development environment. The test of use cases depends on the interfaces it involves; test of interfaces would usually necessitate a separate test environment. Production test needs to take place in a separate production-like environment that could also be used for acceptance test.