The Underpinnings of a Successful Software Development Project

In my last two articles , I discussed two Information Systems (IS) strategies critical in a rapidly changing business environment, namely cross platform client/server systems design and Business Process Reengineering. Though I believe these strategies are important they do not replace the need for sound project life cycle management. Further, effective system models developed with formalized analysis techniques and/or prototyping tools are also critical. The purpose of this article is to very briefly discuss the project life cycle and provide a few examples of analysis tools useful to the successful completion of a development project.

It is critical in any cooperative effort to establish good lines of communications between all parties involved. In a software development project these parties include users, management, quality assurance, systems analysts, systems designers, programmers and operations/maintenance staff. According to Ed Yourdon, in his book, "Modern Structured Analysis", the systems analyst serves several pivotal roles, including: archaeologist, innovator, mediator and project leader. As an archaeologist, one of the system analyst's main jobs is to, "...Uncover detail and document business policy that may exist only as tribal folklore, passed down from generation to generation of users.." The system analyst plays the crucial role of modeling the system that the user wants. His or her role is not dissimilar from that of an architect designing a building. An architect’s blueprints and drawings let his client know the important design features. The plans form the basis for changes and corrections. They serve as a checking tool to let the architect and client know that they are both "on the same wavelength." Further, an architect does not use just one tool. He uses blueprints, drawings, physical models and narrative text to convey different aspects of the project. A systems analyst performs similar functions but his tools are different. The analyst’s tools include, among others, dataflow, entity relationship and state diagrams. There is another key similarity between the architect and system analyst. Both must use modeling tools that are understandable by their clients and can be used as the basis for documenting future changes.

I would like to briefly discuss some of the modeling tools available to the systems analyst. Again, just as an architect or engineer may employ Computer Aided Design (CAD) to help him construct his plans, the systems analyst has an ever increasing number of automated tools to help him generate his models. These tools range from full blown CASE tools from companies such as Bachman, Texas Instruments and Intersolv to relatively simple relational database design tools such as Asymetrix’s Infomodeler. Often these tools will support a variety of structured and/or object oriented analysis and design methods.

The dataflow diagram is a key tool for the systems analyst. According to Yourdon, it addresses the following questions: (1) What functions must the system perform? What are the interactions between functions?; (2) What transformations must the system carry out? What inputs are transformed into what outputs and (3) What kind of work does the system do? Where does it get the information to do its work? Where does it deliver the results of the work?. Dataflow diagrams consist of processes represented pictorially by bubbles. Flows, shown as directed arrows between processes, represent the information processes require as input or generate as output. Data stores, shown by an ellipse or two parallel lines, represent aggregates of data that the system must remember for a time period. Typically stores represent files or databases. Terminators, shown by rectangles, represent the external entities with which the system communicates, for example, customers, other departments or other computer systems. Written process specifications and data dictionaries in turn detail in text what information is transformed and how it is transformed.

The Entity-relationship (ER) diagram is another valuable modeling tool. It describes the relationships between data stores. ER diagrams consist of two major components, object types and relationships. Object types, shown by a rectangular box, represent a collection of objects in the real world whose members play a role in the system being developed, can be identified uniquely and can be described by one or more facts (attributes or adjectives). Customers, Invoices, Rooms, Political Parties, etc. may all be object types. Relationships, shown by diamond shaped boxes, represent a set of connections or associations between object types. Arrows are used to connect object types and relationships. Expressing the relationships between object types is analogous to constructing an English sentence, Object types are the nouns, predicates or verbs describe some action and the two are linked in a complete sentence. For example, Customer (noun) places (verb) order (noun). The goal of ER design is to design a database structure (normalized tables, fields, primary and foreign keys, etc.) that incorporates all the needed object types and their relationships.

State transition diagrams use rectangles to represent states, scenarios or situations that a system can be in. Each state represents a period of time during which the system exhibits some observable behavior. The arrows connecting each rectangular box show the state-change or transitions from one state to another. Associated with each state-change are one or more conditions or actions. State transition diagrams are used to represent real time or on-line systems that have time dependent behavior. For example, the process of using an ATM card involves certain time dependent steps such as: (1) Waiting for the card; (2) Waiting for the password; (3) Waiting for a choice; (4) Waiting for an input from the customer; (5) Dispensing cash and (5) Waiting for cash removal.

The techniques described above fall under the heading of structured analysis. Structured Analysis employs Dataflow, Entity Relationship and State Transition models as well as process specifications and data dictionaries to provide a complete system design view. Structured techniques use a top down approach, starting with the overall system and decomposing it functionally to solve a specific problem. These analysis techniques are in sharp contrast to so called object oriented techniques that focus less on functional decomposition and more on identifying objects from the enterprise domain and specifying their properties and behavior. According an Intersolv Whitepaper on Excelerator II and OO Analysis and Design, "A system using Object Technology can be more easily changed as requirements evolve because it reflects the underlying enterprise domain, rather than data or functional requirements of a specific problem." Structured techniques may still be useful in projects employing object oriented analysis and design where, for example, there is a need for an underlying relational database management system (RDBMS).

Object Oriented (OO) Analysis modeling techniques take advantage of abstraction, inheritance, encapsulation and polymorphism. Encapsulation ensures that an object’s data is hidden from other objects and accessed only via the object’s own methods. Polymorphism results in more flexible code that is easier to maintain because the object sending the message need not know how the message will be processed, only the target object that supports it. In OO Systems Analysis an Object Schema Model diagram is constructed to show object types and structures. Event Schema Model Diagrams describe system events, the sequence in which they occur, how events change the state of objects and the operations that get triggered as a result of a state change.

To this point we have briefly touched on various analysis techniques used to blueprint a software development project. However the sysetms analysis phase is only part of the overall project life cycle. A project life cycle, according to Yourdon, consists of the following activities: (1) Survey; (2) Systems Analysis; (3) Design; (4) Implementation; (5) Acceptance Test Generation; (6) Quality Assurance; (7) Procedure description; (8) Database Conversion and (9) Installation. Depending on the size of the project, deadlines and user expectations these activities may occur in parallel or in a linear, step by step sequence. Often companies will employ prototyping using various 4GL tools throughout the project life cycle. Prototyping can be a valuable tool to clarify user interface issues early on and make it easier for users to communicate their likes and dislikes to the analysis/design team.

For smaller organizations, the systems analyst, designer and programmer may be all one person. In some cases prototyping is all that is required to develop a simple decision support system. Prototyping is however, not sufficient to develop on-line and real time systems with complex business rules. Finally, very few system software projects automate a particular business function 100%. Sound, well thought out manual procedures are still required to successfully implement most projects. During the analysis, design and implementation phases, as much attention needs to be given to these manual procedures as the automated ones.

Lowell Greenberg
Copyright Lowell Greenberg. All rights reserved.
Revised: July 18, 1996.

 

Home • Up • Business Process Reengineering Pitfalls • Transforming Your Company: Business Process Reengineering and Client-Server Technology • BPR Introductory Article • Client/Server Accounting Systems Article • Client Server:1994 • Software Development Projects Article