Development Methodologies

Data-Oriented System Development


Object-oriented system development (OOSD) is the process of solution specification and modeling. This process defines how to implement functionality defined by the analysis. OOSD is usually divided into two levels: the first, abstract design, adds solution characteristics to the analysis models but is still largely independent of development tool specifies; the second, physical design, is a more detailed level which looks at the specifies of the development environment and incorporates those features or constraints into the design. The major advantages of an OOSD are as follows:
  • The ability to manage an unrestricted variety of data types
  • Provision of a means complex relationships
  • The capacity to meet the demands of a changing environment

Object-Oriented Technology

Object-Oriented technology views the raw data and the procedures governing use of data as a single object. An object-oriented approach to data management defines the object in terms of its characteristics (for example, test, graphics, format specifications and printer information) and the procedures governing their use (how those characteristics are used to make a complete document). The object is then stored as a resource that can be reused or modified. Applications that use object-oriented technology are:

  • Computer-aided software engineering (CASE) for software development
  • Office automation for e-mail and work orders
  • Artificial intelligence (IA)
  • Computer-aided manufacturing (CAM) for production and process control

The major advantages of an object-oriented approach to data management systems are:

  • Ability to manage an unrestricted variety of data types
  • Provides a means to model complex relationships
  • Capacity to meet the demands of a changing environment
  • Object-oriented models can be manipulated easily by the user
  • Increased efficiency in programming through the ability to re-use elements of logic
  • Ability to allow a user or an application to access only the needed information, since it stores objects independently of one another.

Prototyping

Prototyping, also known as heuristic development, is the process of creating a system through controlled trial and error. It is a method, primarily using faster development tools such as 4GLs, that allows a user to see a high level view of the working of the proposed system within a short period of time.

The initial emphasis during development of the prototype is usually placed on the reports and screens, which are the system aspects most used by the ends users. This allows the end user to see a working model of the proposed system within a short time.

There are two basic methods or approaches to prototyping:

  1. Build the model to create the design. Then, based on that model, develop the system with all the processing capabilities needed.
  2. Gradually build the actual system that will operate in production using a 4GL that has been determined to be appropriate for the system being built.

The problem with the first approach is that there can be considerable pressure to implement an early prototype. Often, users observing a working model cannot understand why the early prototype has to be refined further. The fact that the prototype has to be expanded to handle transaction volumes, terminal networks, backup and recovery procedures, as well as provide for audit ability and control is not often understood.

Another disadvantage of prototyping is that it often leads to functions or extras being added to the system that are not included in the initial requirements document. All major enhancements beyond the initial requirements document should be reviewed to ensure that they meet the strategic needs of the organization and are cost effective. Otherwise, the final system can end up being functionally rich but inefficient.

A potential risk with prototyped systems is that the finished system will have poor controls. By focusing mainly on what the user wants and what the user sees, system developers may miss some of the controls that come out of the traditional system development approach, such as: backup/recovery, security and audit trails.

Change control often becomes much more complicate with prototyped systems. Changes in designs and requirements happen so quickly that they are seldom documented or approved and can escalate to a point of being un attainable.

Rapid Application Development (RAD)

RAD is a methodology that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality. This is achieved by using a series of proven application development techniques, within a well-defined methodology. These techniques include the use of:
  • Small, well-trained development teams
  • Evolution prototypes
  • Integrated power tools that support modeling, prototyping and component re-usability.
  • A central repository
  • Interactive requirements and design workshops
  • Rigid limits on development time frames
RAD supports the analysis, design, development and implementation of individual application systems. However, RAD does not support the planning or analysis required to define the information needs of the enterprise as a whole or of a major business area of the enterprise. RAD provides a means for developing systems faster while reducing cost and increasing quality. This is done by automating large portions of the systems developments. The RAD methodology has four major stages:
  1. The concept definition stage defines the business functions and data subject areas that the system will support and determines the system scope.
  2. The functional design stage uses workshops to model the system’s data and processes and to build a working prototype of critical system components.
  3. The development stage completes the construction of the physical database and application system, builds the conversion system and develops user aids and deployment work plans.
  4. The deployment stage includes final user testing and training, data conversion and the implementation of the application system.

Re-engineering

Re-engineering is a process of updating an existing system by extracting and reusing design and program components. This process is used to support major changes in the way an organization operates. A number of tools are now available to support this.

Reverse Engineering

Reverse engineering is the process of taking apart an application or a software application or a product, in order to see how it functions and to use that information to develop a similar system. This process can be carried out in several ways:
  • Decompiling object or executable code into source code and using it to analyze the program.
  • Utilizing the reverse-engineered application as a black box and unveiling its functionality using test data.

The major advantages of reverse engineering are:

  • Faster development and reduced SDLC duration.
  • Creation of an improved system using the reverse-engineered application drawbacks.

The IS Auditor should be aware of the following risks:

  • Software license agreement often contain clause prohibiting the license from reverse engineering the software, so that any trade secrets or programming techniques are not compromised.
  • Decompilers are relatively new tools whose function depends on specific computers, operating systems and programming languages. Any change in one of these components will require developing or purchasing a new decompiler.

Structured Analysis

Structured analysis (SA) is a framework for the physical components (data and process) of an application using data flow diagrams. It includes a physical model of the system, refined data and process allocations with a revised user interface. Using SA, a review process in which a project team member leads one or more team members or customers through a segment of a deliverable he or she has produced can be implemented. Team members ask questions and make comments about technique, style, possible errors, violations of standards and other problems. In a SA process the developer would want to do the following:

  • Develop system context diagrams.
  • Perform hierarchical data flow/control flow decomposition.
  • Develop control transformations.
  • Develop mini-specifications.
  • Develop data dictionaries.
  • Define all external events – inputs from external environment.
  • Define single transformation data flow diagrams from each external event.

Exhibit 6.3 describes the strengths and weaknesses of structured analysis:

Exhibit 6.3


Structured Analysis Strengths & Weaknesses

Strengths
  • Addresses user concerns quickly
  • Supports CASE tools
  • More applicable to problem-oriented analysis than design
Weaknesses
  • Weak solution representation; structured chart notation inadequate to capture concurrent task elements and their interactions (synchronous or asynchronous communication)
  • Does not address the issue of structuring system into concurrent tasks.
Author - Purnima Varadrajan
E-mail ID - purnima_varadrajan@ipott.com
Cheif Executive Officer,
iPOTT Softech India Private Limited.