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 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
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
1

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
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
2

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
Vendor
Invoice
Check
Transaction
1
Pay Invoice
Balance Bank Account
Modified Balance
Number
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 a check, 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.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
3

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
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
4

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.
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.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
5

Figure 2: Entity-Relationship Diagram
1:N
Customer
1:N
Contract 1:N PayRequest
1:N
Project
1:N
Phase
1:N
Completion
1:N
1:1 BudgetedAmount
1:1
Assignment HoursWorked
1:N
Correspondence N:1 Transmit 1:N Employee
1:N
Non-union
1
Union N:1 PayRate
Markup
Materials
Labor
Materials N:1 Vendor
1:N
N:1 PurchaseOrder
1:1
Invoice
N:1
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
6

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.
1
Invoice
Received
Invoice OK
2
Approve
Invoice
Invoice = Approved
3
Contact
Vendor
Invoice N.E. PO
Invoice = PO
5
Pay Invoice
Balance > Invoice
6
Check
Balance
Invoice = PO
AND
Balance > Invoice
7
Write Check
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.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
7


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.
Terminal
Terminal
Peer-to-peer
Home
Office
Terminal
BNC
Sychronized
Daily
Regional
Office
BNC
Jobsite #1
Jobsite #2
Terminal
Figure 4: Communications Requirements
Terminal
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
8

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.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
9

Figure 5 Record Structure Diagram
Contract Administration Based Relationships
CompanyState, CompanyZIP, CompanyPhone, CompanyFAX,
CompanyNotes}
1
Project ={ProjectNo, CompanyID, ProjectName, ProjectPM, RegionLoc*,
1 ProjectAddress, ProjectCity, ProjectState, ProjectZIP, ProjectPhone,
ProjectFAX, Directions, Architect, ArchCont, Engineer, EngCont,
Owner, OwnerCont, GenCont, GCProjExec, GCMEP, GCPhone}
1
M
Contract ={CompanyID, ProjectNo, ContractNo (
This is the customer’s number)
,
ContractAmt} 1
M
PayRequest ={CompanyID, ProjectNo, InvNo, InvDate, SalesTax, Retainage,
M AmtDue}
M
Phase ={ProjectNo, PhaseName}
1
M
M
1
BudgetedAmt ={ProjectNo, PhaseName, BudgetMaterial, BudgetLabor, Markup}
N
N
Completion ={ CompanyID, ProjectNo, InvNo, PhaseName, PhasePercentComplete,
PhaseAmtBilled}
Purchasing Based Relationships
1 1
Vendor ={VendorID, VendorName, VendorAddress, VendorCity, VendorState,
VendorZIP, VendorPhone, VendorFAX, VendorType, RegionLoc*,
VendorContact, VendorNotes}
N N
PurchaseOrder ={ProjectNo, VendorID, PONumber, ShipAddress, ShipMethod,
ShipCity, ShipState, ShipZIP, ShipMethod, Terms, PONotes}
N
Invoice ={InvoiceNo, VendorID, InvoiceDate, PONumber, Shipping Charge,
InvAmount, InvNotes}
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
10

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).
In order to program custom interfaces across applications, it is helpful to create an application schema diagram. This diagram outlines the various applications that are being bound together in the various interfaces and data exchanges. By using the applications schema with an interface schema, the designer can map visually the data and user interface connections necessary in implementing the system.
Physical Network Design
When the database and application design are complete, the next step in the physical design process is to determine the system requirements for the actual hardware that is to be installed to support the system. Physical network design entails a number of aspects as follows:

Determination of database design characteristics, including the size and number of decentralized databases and associated applications.

Calculation of network transmission speeds based upon data transfer characteristics between remote sites and main offices. This stage includes analysis of database size, number of records and frequency of synchronization.
An additional consideration is the extent to which distributed applications share data across the network.

Determination of distributed network connection types based upon transmission speeds, technology availability and expected duration of service. This stage entails the selection of high-speed network communications technologies such as frame relay, ISDN, xDSL or other types of WAN and distributed computing standards.

Selection of computing hardware including network hub speeds, processor speeds and memory requirements.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
11

These steps are crucial to building an adequate, scaleable network that forms the backbone of the integrated construction information management system. It is very important that sufficient planning is dedicated to network design and implementation to ensure that the system runs effectively and reliably.
Determine Prototype Scope
Crucial in developing a successful integrated system is determining the feasibility of each stage of development as early in the development life cycle as possible. System prototypes are frequently used to reduce the risks involved with implementing large, integrated systems. By focusing on a much smaller component of the problem, the designer can 1) implement systems more rapidly by having pieces available for use very early in the development cycle and 2) ensure system performance by proving the system and concepts on a smaller scale.
The key to prototype development is selecting a sub-component of the entire system that tests the design methodology and engages the user’s interest in the system. Careful examination of the overall design leads the designer to the identification of critical components of the integrated system. For example, these may be data exchange methods, application interfaces, database queries or communications technologies. Most frequently, the subject of a prototype will be untested technologies or new design ideas.
Crucial to prototype success is not only the verification of technologies but also the extent to which the user’s needs are met. By satisfying the users, and to some extent the system buyers if not the same, the implemented system will have greater acceptance and a smoother launch.
Develop Performance Benchmarks
A prototype is built as a model for the development for a larger system. To that end it is important to create performance benchmarks to verify the success of the prototype system in achieving its goals. These criteria may include proof that processes achieve desired results, determination of processing time and efficiency measured against those desired or verification of data communications speeds across the network. The system owner and designer determine these benchmarks much like performance specifications are developed for a building construction project. The prototype benchmarks may be very similar to those employed for the fully implemented system.
Build and Test Prototype
Prototype build and test can be a very brief process, taking only weeks to complete.
While not all systems are implemented using prototypes to test the system concepts, the method has become very popular because of its reliability and speed. Frequently prototype applications use sub-components that were developed at another time or are from existing systems. This component architecture enhances the speed of prototyping
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
12

and additionally improves reliability since components are pre-tested. Prototypes are frequently constructed using CASE tools for their initial design, again improving the speed of deployment.
Prototypes are most often debugged and tested by the developer, but frequently undergo extensive use and testing by the end-user prior to the implementation of a complete system. Some firms have found that multiple stages of prototype development and deployment is superior to a large-scale system roll out. In the construction industry the existence of many isolated applications suggests that a phased prototype approach to implementation could be advantageous in tying these systems together gradually over time. By taking this phased approach, existing operations are not disturbed and validation of each sub-system can take place to ensure system performance.
Project Cost Estimates
While it is possible to create a cost estimate at the outset of systems development, it is difficult to accurately determine the overall scope of the project until final physical designs are complete. Estimates of costs in system development often are much like construction cost estimates. These estimates progress from the conceptual level to a more detailed state as the design of the system is completed. Prototype development is the last stage in the design cycle prior to the commitment of the major financial resources to the project.
Prototyping not only tests the feasibility of the project from a technical perspective, but it gives a means to test the overall financial feasibility of the project as well. Furthermore, if a phased prototyping approach is taken, the system buyer may pay for each part of the system as it is developed and delivered. This allows for greater financial control over the progress and performance of the project.
Implementation
Foremost in the implementation of the integrated system is employee training. The acceptance of the system by the end-users is crucial to project success and payback on the investment in information. To this point users should have played a significant roll in the design of the system, so they should be knowledgeable of its purpose and capabilities.
However, they need significant guidance through the introduction and transition phase of the project to ensure that they are able to use the system to its fullest extent. It is important to note that this training involves much more than just how the system is operated. An integrated construction information system requires that the users have a much more cross-functional knowledge base to improve the firm’s operational efficiency.
At a minimum, employees should be introduced to the following concepts:

Supply chain management including resource planning, purchasing and distribution.

Documentation management including project litigation issues.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
13


Financial management including budgeting, earned value reporting, variance analysis and fundamentals of the firms ROI and earnings targets.
By welcoming employees as management partners, their stake in the success of the integrated system is increased. They can be encouraged to be managers of firm as well as managers of information.
Once the prototyping process is complete, costs are estimated and an employeetraining plan is developed, the system is ready to be implemented. Implementation can take place in either a phased approach, gradually introducing new systems as older ones are phased out, or by complete switchover. Often in the case of completely replacing an older system, the new and old are operated simultaneously for a prescribed period of time to validate the new systems performance. In either case, the new system should be thoroughly evaluated using performance benchmarks and improvements made on a continuous basis. This repetitive evaluation process should likewise include input from the system users.
CM 560 - Construction Firm Management II
Instructor: Mark Huppert
14