Using Sdlc at Gm Wilmington Assembly

Using SDLC at GM Wilmington Assembly

...

BSA 375

Gordon Hodgson

July 6, 2004

Abstract

The Software Development Life Cycle is seldom used at my place of work. Unfortunately, recent developments in its use are deemed confidential. Due to this fact, this paper will examine in general terms one of the projects we are undertaking right now while at the same time attempting to maintain our confidentiality.

The project that will be examined is an upgrade to our main Human-Machine Interface (HMI) software: Cimplicity, to SQL Server and to the Windows OS. Cimplicity is a product of the GEFanuc group of General Electric. This group develops a full suite of applications used in the manufacturing environment. By way of introduction, the manufacturing floor environment uses a variety of types of equipment. To control these machines, a specialized computer is used. For the purposes of simplicity (not the program), this paper will refer to them all as PLC's or Programmable Logic Controllers. Most of these PLC's are accessible via the ethernet and communicate to our Protocol Data Units (PDU) in the computer room. These PDU's have Cimplicity installed on them in the form of projects that are named for the various areas or functions of our plant such as GA or General Assembly. The project we are undertaking will be a fundamental change to these PDU's in our computer room. The servers currently run Windows NT and will be upgraded to Windows Server 2003 or Windows 2000 and SQL Server will will be upgraded from version 7 to SQL 2000.

Using SDLC at GM Wilmington Assembly

The most recent history of our HMI software upgrades has been full of small upgrades, hot fixes (quick patches provided by GE) and changes to minor configuration items on the projects themselves. Recently, spurred by an announcement from Microsoft that Windows NT would soon be unsupported, GM decided it was time to upgrade its servers. The new servers would have Windows 2003 Server and any client or production computer would have Windows 2000. Any SQL Server will run SQL 2000 after the upgrade. The project began as a somewhat simple server hardware and software upgrade and has moved into a full-blown consolidation, network upgrade and server consolidation. From the outset, both EDS and GM have agreed to use a CMMi framework for all actions relating to this upgrade.

Systems Investigation

The first step in the process was to assign a group of EDS personnel that would handle what is called a "Blockpoint" in GM speak. These people would be charged with assessing the needs of the various plants across the GM enterprise. The effort would be huge since this would be an international project (Canada, Mexico and the US).

This group began by sending out a series of system surveys to get a snapshot of the systems at the various plants. This was facilitated by a new system of coordinated support called "ACE" which placed personnel from across the corporation in a Cimplicity group. Once they got a picture of the needs and the lack of commonality, the negotiations began between EDS and GM to determine what this upgrade would consist of. This leads to the next step of the SDLC called Systems Analysis.

Systems Analysis

Since the stated goal of the upgrade is to move from Windows NT wherever possible, the scope of the project has expanded considerably. Cimplicity has a data logging component that uses SQL server as a repository. Therefore, there has been a move toward upgrading the SQL servers as well.

For the most part, the focus of the Blockpoint has been on the various Cimplicity- based applications. These have been separated into vital, critical and non-critical categories. GM has determined that these vital and critical applications must be able to run with either no or only minimal interruption. The systems must be designed to prevent plant downtime and loss of units of production. The SQL server environment must also be available for both input and output of data during the production day.

Once the general rules and assumptions were laid down and the current systems were catalogued from the various plants, a full-blown system architecture plan was developed and a site to pilot the upgrade was selected. The pilot plant would establish the methods to be used during the upgrade in general terms as well as produce a set of documentation for our ISO work instructions. The next phase of the Blockpoint is system design.

System Design

The System design phase of this project has been somewhat protracted since the GM team changed in mid-stream. As is always the case, when an established team is replaced, some of the assumptions are changed and therefore the plans are changed. A new site was chosen for the pilot and the architecture was altered as well. This set us back in our schedule somewhat but hasn't affected the pilot dates.

Our final architecture is based on the three categories mentioned earlier: Vital, Critical and Non-Critical. Anything deemed Vital is to be installed in a cluster to allow for quick failover in the event of a failure. Anything in the Critical group will have a single backup server onto