| PIR 3: Systems Development Process | | MIS 310-01 |

| PIR 3: Systems Development Process | | MIS 310-01 |

Table of Contents

Introduction 2
Development of Policies, Procedures and Standards 2
Need & Gathering Requirements 3
Build or Buy Decision 3
Application Implementation 4
System Maintenance 5
Project Sponsorship 6
Conclusion 7

Introduction

Within this paper, we will begin to delve into the research and development phase of our report on the Trinium system and its implementation within Transport America. We will go into further detail about the various development and policy procedures for Trinium, what specific guidelines employees or users must follow when developing or acquiring this tool and other policies. Need requirements or what caused the company to want or need to acquire this system will also be explained in the following text as well. We will also be touching upon the build or buy process and how it was decided on purchasing a third party application or building one from the ground up. In addition, we will also be exploring application implementation into business workflow, system maintenance and any possible project sponsorship.
Development of Policies, Procedures and Standards
Due to the size of Transport America, they currently do not have on record any published policies, procedures or standards when it comes to application development. In addition, they also have no published policy for outsourcing or working with vendors outside of the company. They do implement standards or best practices, although these are not written. They currently utilize software lifecycles, or what they have titled SDLC. These SDLC’s define development tests which Transport America uses to gauge and evaluate the implementation of new applications or systems.
Transport America does implement policy standards when it comes to security and authentication when using system applications. The typical authentication procedure depends on the application or system being use, but most use a simple network login ID and password. Each ID has certain limitations and restrictions based on their role in regards to the company and what portions of the system application they use, or need to use, on a daily basis.
Need & Gathering Requirements

The need to acquire a new application arose within Transport America when it acquired a third party company who was utilizing an inefficient application. No specific need analysis was conducted, but internal feedback from many operational roles within the company led to the acquisition of the current application. The initial request for the new system was made by the IT division Vice President without a consensus and no apparent feasibility study performed.
During the requirement gathering process the most involved departments included Customer Service, Fleet Operations, Billing, and Payroll with the Finance department being included at the tail-end of the process. From each of these specific departments the representatives included the Director of Customer Service, Intermodal Fleet & Billing, Payroll managers, and divisional general managers. Discussions during this process included what the current system was able, or not able, to accomplish and what they expected and needed a new system to provide. They documented gaps with the current software and created ways for the new system to be as efficient as possible.
Build or Buy Decision

Transport America currently does have the capability to develop and create applications via an in-house IT department. The ultimate decision to outsource the development process was made by the CIO early on when accessing the intermodal business model versus the regular truckload business. Eventually, the final buy decision was justified due to the fact that the intermodal division was too different from what Transport America was accustomed to. It was too difficult to combine with Transcom, the system that was being used at the time.