Construction Information Systems Development

Construction Information Systems Development

Overview of Systems Development Methodology

Systems concepts are useful in understanding and analyzing the way things work: both abstract and concrete. Construction organizations can be viewed as dynamic systems that take economic resources as inputs and transform them by diverse organizational processes to provide a finished project as output. Information systems are developed in order to provide knowledge that helps management to make the most efficient and effective use of these resources. Whether the system is automated or manual, highly formal or very informal, a systems perspective views information as input to or output from some other external entity. The process of systems development provides a framework for the creation or maintenance of these interrelated entities by decomposing each into its fundamental inputs, processes and outputs.

A system may be most simply defined as a set of interrelated elements. Some of these elements are themselves grouped into sub-systems. Although these sub-systems may be viewed independently, they must be carefully designed to work together smoothly as a whole. Much of the task of systems development is characterizing how these external systems and sub-systems interface. Information systems which are relatively open systems, i.e. have fewer boundaries to interface, are generally more desirable because they are more responsive to environmental conditions and because they are easier to connect to other external systems.

The objective in systems development methodology is to isolate the issues of structure and function, allowing analysts to design very complex systems. The methodology first involves the functional decomposition of the problem that is to be solved. This entails defining the data, processes and interfaces of the system including the physical environment. Once the problem is thoroughly understood, a logical design framework can be assigned to the problem, much like the conceptual drawings of a building outline the design framework for technical specifications. This conceptual work evolves into the actual physical design of the system, or the working blueprint. From this blueprint cost analysis can be performed and a prototype, or mock-up, built. When the prototype is tested and any improvements made to the design, the system design is then released for implementation in its final location.

Functional Analysis

Functional analysis can be performed most directly by first identifying the business goals and desired outcomes of the system. The outputs needed to achieve these outcomes are then determined. Finally the processes and inputs that are needed to produce these outputs are defined and modeled. Since improvements can almost always be made to any design, functional analysis is an iterative process. What functional analysis accomplishes is the creation of a structured thought process in which a business process is broken into all of its most fundamental components. These components are then used to assemble a data model that represents the process, using information, computers, communications technology and human resources to create the result.

If a contractor wished to develop a system for paying invoices, the first step of functional analysis would be to specifically identify the goal of the system, such as “A check from a bank account is written to a vendor for an invoice received.” The outputs of this system are checks and transaction information for the bank and for internal records. The inputs to the system are the invoices received by the vendors and the bank account information. What relates this input and output data are the processes that define the relationships within the system. An invoice is received and then approved for payment. The bank account balance is verified and the check is written. And lastly the transaction is logged and recorded. Thus for the simple problem statement, the result is the description of outputs, inputs and the processes that relate them.

However, there are two additional components to functional analysis once the decomposition of the problem is achieved. The system itself occurs within an environment. These environmental factors, such as when a transaction is recorded, what initiates a check being written or how a check is printed, are the events that occur within the system. And the physical characteristics of how data moves through the system, such as through keyboard entry, as a record in a database or from an electronic data interchange process, are the system communications. All five components, inputs, outputs, processes, events and communications work together as the building blocks of the systems development methodology.

Data

In an information system, data characterizes the outputs and inputs of the business process being modeled, whether it is people, things, places, quantities or any other descriptive characteristic. Data is most frequently thought of as an entity or an attribute of an entity in design methodology.

Data stored on a computer is organized into levels, and this is often referred to as the data hierarchy. When data is grouped together, it most frequently follows a structured format, referred to as a database. In a database, a field is the smallest unit of storage that has business meaning and is usually given a name (such as Vendor_Name, Invoice, or something meaningful.) A record is a group of related fields that describe some business entity. Records of the same type are grouped into tables that form the overall structure of a database. Tables within a given database usually relate to one another in some way trough relationships and can be searched by a process called querying.

In the functional analysis process it is helpful to understand the structure of a database. Databases and their tools are frequently used to model physical systems as information systems. Only by understanding both the business process being modeled and language and structure of the model being used, can an analyst achieve the goals for the system. Just as an architect must understand the language and capabilities of construction to produce an effective design, the systems analyst must thoroughly understand data structures to model business problems.

Processes

Defining and analyzing business processes is the most fundamental, yet most difficult, part of functional analysis. This procedure involves mapping the interrelationships between all of the data pertaining to the process. Frequently, the first step to developing this map of relationships is to write a narrative that includes all of the entities within the system and a description of how they behave, or relate to one another. Thinking about the problem in an unstructured narrative can actually be helpful in outlining a more structured approach to the problem. This more structured format is frequently called an entity relationship diagram (ERD) and will be discussed more under logical design.

When thinking about processes, the system designer will often use a method of visualizing the business problem. In order to chart the process, it is best to look at any similar existing systems, whether they are physical processes or data models. From these existing systems, a graphical representation may be made of the movement of data or information within the system. An example of this functional process diagram is shown in Figure 1 for a simple invoice payment model.

Figure 1 - Functional Process Diagram

Often each process is broken into sub-processes. Each sub-process has its own inputs and outputs, requiring a separate narrative and process diagram. For example, paying an invoice requires writing acheck, which in turn requires capturing a payment amount, capturing a payee’s company information and printing a check. Decomposition of processes into their sub-processes is continued until all interrelationships relevant to the system are modeled.

Events

The development of the process model requires a subsequent analysis that relates to the events required by the processes and the actions required of the user. Events trigger processes in a system. For instance, the receipt (the event) of an invoice triggers the invoice being sent for approval (the process).

Events are used to create automated workflow processing as well as to define the requirements of user inputs and screens. They are conditional responses to data within the system and are the cause for system processes. There are those events that are characterized by input data or output data attributes, like the time of a transaction record or the balance of an account. And some events are governed by variables of system state such as the security level of a user, or the status of a network printer. For example, an automated event might be, “Invoice is approved if Invoice_Amount equals Purchase_Order_Amount.”

Decision tables are frequently used to provide a framework to analyze these events. In the decision table the events that dictate each process are outlined. A number of characteristics about the input may govern the process or flow of the data through the system. This information is also cataloged in the table. Tables are frequently produced for each process in the system, or in the case of simple processes, grouped by the next level in the process hierarchy.

Communications

Underlying the functional scheme that is created in the analysis of data, processes and events are the requirements for how the three will work together to create a system. Communications are the means by which data is passed through the system between processes. Data can be moved physically or electronically through the system. The production of report printouts, lists, invoices, checks and the like are examples of physical communications. However, an increasing number systems are employing electronic means to transfer and share data. The framework required to implement these electronic transfers is network communications.

Network communications are best analyzed by looking at the geographic requirements of the system. The location of the data sources, databases, users and interfaces dictate the basic network infrastructure requirements. There are several common network types that might be used for a construction information management system. Centralized systems collect and store system data in common locations, with data flowing from and to remote user locations for temporary use and modification. Decentralized systems on the other hand transfer the storage responsibility out the remote sites, allowing for multiple copies of data, or geographically defined boundaries for data storage.

There are many reasons to implement either type of network system, ranging from computing speed to data reliability. The decision of which type of network to implement is itself part of the functional analysis process. To determine communications needs the analyst will examine the geography of the system, the location and performance characteristics of existing system components, the performance requirements of the new system as well as the various demands of the system users. A decision matrix is then used to prioritize the communications requirements and evaluate the system.

Logical Design

Entity-Relationship Diagramming

The ERD is the backbone of the database design. It is the logical model by which a physical design may be implemented. There are several notations that may be used for the actual diagram, but the fundamental analysis process is the same. In addition computer-aided software engineering (CASE) tools are often used to assist in the analysis process, each providing its own syntax. The process of creating an ERD is as follows:

The system narrative created in the functional analysis is used to identify the entities within the system.

Entities are drawn, and those that are related to one another are connected, representing the relationship between them.

The relationship between entities is analyzed, annotating the cardinality of the relationship, i.e. one-to-one, one-to-many, many-to-many.

Entities and relationships are examined to determine their characteristics or attributes, which are also represented on the diagram.

Finally, the diagram is reviewed for the correctness of its logic.

This simple structure may be applied to complex data analysis problems by breaking the data into subsets, allowing the analyst to focus clearly on the relevant data. Figure 2 shows a sample ERD.

Figure 2: Entity-Relationship Diagram

Business Process Design

Design of system processes is the logical modeling of the flow of data through the system. After performing the functional analysis of the business problem, by describing it and mapping out the relationships within the system, a detailed process diagram is created. This entails combining the event prioritization tables with the various system processes. For each process, various outcomes are possible based on the inputs and the event criteria. Figure 3 is the diagram for part of an invoice processing system.

Figure 3: Business Process Diagram

Interface Requirements

The logical design of system interfaces involves the analysis of the users’ relationships to the system, including forms and screens for capturing data, automated processes for administering the system and output requirements such as reports or printouts. The designer develops these requirements by the following processes:

Interviewing users for input regarding the desired functionality of the system interface.

Analyzing user requirements and system capabilities to develop a list of elements to be incorporated into the design.

Creating conceptual schematics of forms and screens from the requirements list.

Review by users of the final design.

Flow diagramming of all forms and screens into a comprehensive interface schema.

By performing these tasks, a logical design is created that can be directly modeled in programming language to implement the system. More effort in planning the eventual physical design benefits both the users and programmers, since the analyst is providing the link between the needs of the users and the capabilities of the programmers.

Communications Requirements

The logical analysis of data communications requirements calls for a detailed look at the geographic and/or physical location of the users and the system hardware. In construction management, users are often dispersed to remote project sites as well as collected at headquarters offices. The communications design must reflect the needs of both groups.

In developing a logical design, the analyst first maps out the geography of the overall system. This entails defining location of project sites, regional offices (if any) and the headquarters office. Since the physical location of project sites is constantly changing, the design must deal with these entities dynamically. The permanent physical locations within the company would then play a more static role in defining the system architecture. Ultimately, permanent offices would have more permanent data connections, while project sites would have connections as required. The communications map thus shows the location of users and hardware, the permanency of connections required between each as well as the nature and volume of data being transmitted. Figure 4 gives an example of a construction management oriented communications design.

Figure 4: Communications Requirements

Physical Design

Record Structure Diagramming

The process of converting the ERD into an actual data set requires the creation of a record structure diagram (RSD). The RSD is the model that represents the way data is actually stored in the database, using fields, records and tables. By converting the ERD into and RSD the analyst can test logic, review requirements and look for errors in the design methodology prior to the actual implementation of the system. Furthermore, RSD’s are useful in calculating the physical memory requirements of the databases and corresponding communications requirements.

To create an RSD entities, attributes and relationships are converted into fields and tables within the database. A table is created for each entity and its corresponding attributes. The table is the structure to which each entry, also known as a record, conforms. An entity is uniquely identified by a key field, which has a different value for every record in the table. Some entities and attributes are related to others inside and outside of the table. These relationships and also indicated on the diagram, as they are critical components of the database design. Figure 5 shows a complete RSD for a project management example.

Tables in the RSD are implemented in an actual database in quite the same manner. Each line in the RSD represents a table in the database. The relationships between attributes and entities are implemented through database table joins, which link fields in the various tables. Database design and programming is a structured and complicated process that is best accomplished by an experienced specialist for the specific database application that is being used.

User Interface Programming

Since the logical design process for application interfaces involved significant planning, the programming of interfaces is straightforward. Using any of a variety of programming languages, including built-in application programming interfaces (API) as well as traditional programming tools, custom integrated applications can be easily built. The simplest approach, shown in the case example of the next chapter, is using applications from the same developer with the supplied API to customize a user interface.

Screens and forms can frequently be implemented from within individual applications, reducing the need for custom programming in many cases. It is possible, for instance, to build data input forms with a database management system. It is also possible to create user menus in applications such as a spreadsheet or word-processor using simple internal programming tools such as macros or API’s. For example, Lotus supplies an API called Lotus Script with all of its products to facilitate custom design. Microsoft supplies a similar add-in called Visual Basic for Applications (VBA).