ADMN641 Information Systems Design and Integration
Lesson 5 - Software Project Management and Detail Methodologies
 
"If you fail to plan, then you plan to fail." Steven Covey 
 
Mentally return briefly to lesson 2. There we looked at a causal loop for describing the symbiosis between information technology and organizational effectiveness. If we could look deeper into those factors that drive information systems, specifically quality information systems, and their effectiveness, what would they be? What "causes" a quality information system to exist?
 
Think of those information systems that are highly valued in your organization. What are the factors that set them apart? How did they get to that point? Think of those systems which are consistently problematic. Again what are the factors that set them apart? How did they get to that point?
Criteria for judging the effectiveness of most systems can often be categorized into sociological, political, economic, and technological categories. Utilizing these categories may help you ferret out all the factors important to understanding IS effectiveness.

This brings us to some important points. If you can locate those factors which contribute to highly valued or problematic information systems development, is there then a way to:

This weeks study focuses upon the merits and utilization of one or more of a number of methodologies for quality assurance, or producing quality information systems. It extends lesson 4 where the focus was a macro level view of the traditional life cycle, some variants, and factors that effect the life cycle concept . This week we look at those components in more depth and tools for implementing them.

Laudon and Laudon utilize the categories of  Structured Analysis, Structured Design, Structured Programming, and Flowcharts for these methods. There are dozens of approaches within these categories, and many which do not fit well within any of them. We will cover some of the more popular methods often available in Computer Aided Software Engineering (CASE) tools.
 
Implementing Effective Software Life Cycle Management through CASE Tools

The Macro Viewpoint

You can locate an index to approximately 400 CASE  tools at the web site from the Department of Computing and Information Science of Queen's University at Kingston, Canada. http://www.qucis.queensu.ca/Software-Engineering/tools.html. Right there this should tell you something - 400 tools! Wow! How could anyone get to be knowledgeable in all the approaches that must be wrapped up in these tools. Certainly there must be some professionals in this world who are just such experts. But how will this aide you as a IS manager or Chief Information Officer. Well you could hire one of those experts and just follow what they suggest. But before you do that wouldn't it make more sense to get a feel for some of the classes of tools, and some of the types of approaches that can be taken utilizing them? The diagram below from Zackman1 presents a taxonomy for an Information Systems Architecture. This architecture provides a framework for all levels of understanding of an IS infrastructure. While you may find the diagram below difficult to read, the column headings include Data, Function, Network, and People. The Row labels include Scope, Enterprise Model, System Model, Technology Model, and Detail Representation Components.

Zackman developed this framework to help others understand the macro viewpoint in IS development, integration and maintenance -a view from all windows.

Specific CASE Methods and Tools

The Loudon & Loudon book introduces CASE tools and looks in moderate depth at Scitor Process Charter, likely one of the most sophisticated tools for requirements definition and dynamic flowcharting. Utilizing a CASE tool goes hand in hand with adopting those methods which the CASE tool implements. Some tools, such as System Architect provide a grab bag of capability. It is then incumbent upon a user to select what segments of capability he/she deems to be the most important.
 
Have you seen some of these tools before? Do you use them in your organization? If so how would you characterize your organization's experience?
The following diagrams are screen captures from System Architect another CASE tool from Popkin Software & Systems of New York City. The extent of the pieces within this tool provides additional evidence of the wide variety of methods for assisting in the development of information systems.

Figure 5-1. Activity Based Costing Test
Figure 5-2. Utilizing Cost Centers
Figure 5-3. Data Flow Diagram
 
Figure 5.4 - Data Flow Diagram - Ward & Mellor approach
 
Figure 5.5 - Diagram Hierarchy
 
Figure 5.6 - Entity Relationship Diagram
 
 
Figure 5.7 - Standard Flowchart
Figure 5-8. IDEF0 Chart
Figure 5-9. IDEF1X Chart
 
Figure 5-10. Structure Chart
 
 
Figure 5-11- Ward Mellor Component Architecture

How effective are CASE Tools?
 
While you may hear this question asked, it is likely more appropriate to ask two questions: 1) How effective is it to use the method implemented in the CASE tool? and 2) How much more cost effective is it to use an automated tool for applying the methodology than using a non automated approach? Likely you will only find the answer to the first question through in depth research studies on applying specific methods. The answer to the second question is that, given today's competition for IT employees and their cost per hour, it is difficult to believe that the use of any automated tool would not be worthwhile. If the decision is made to utilize a methodology, a CASE tool implementing that method is a wise investment.

Updating the systems development paradigm

Many of today's ideas about systems development stem from mainframe systems development of the 1960s.  Of course the computing world has changed significantly since then. To update system development approaches, Michael Cusumano and Richard Selby, professors at M.I.T studied product development at Microsoft Corp. over a 1 and 1/2 year period2.  They identified a new approach which they term 'synch-and-stabilize'. They state " users needs for many types of software are so difficult to understand, and changes in hardware and software technologies are so rapid that it is unwise to attempt to design a software system completely in advance."

Microsoft's approach is to focus managers upon features that people will pay money for, and to limit the resources available to them such as staff and schedule. They attempt to maximize the utility of a software release toward an overall large audience. This contrasts with focusing much effort upon difficult features that would likely only be utilized by a small number of users.  The development process they use is shown below.
 

Planning Phase 
Vision Statement 
Outline and Working Specifications 
Development Schedule and Feature Team Formation
Development Phase 
Feature Development in 3 or 4 Milestones
Stabilization Phase 
Feature Complete Code Complete 
Alpha and Beta Test, Final Stabilization, and Ship
 

During the development stage while developers are free to work when they desire, they must be ready to create a build / version of the product at a specific time each day. They are also very conscious about creating code which will not "break" or cause problems in the other modules of the package. Some other characteristics of their systems development approach include shared responsibility and tasks, on-site development, a common (usually low level) language, an open culture, evolving specifications, buffer time, and an evolving process (openness to change).
 
 
1. Zackman, J. and Sowa, J.  IBM Systems Journal Vol. 31  No. 3 1992.
 
2. Cusumano, Michael A. "How Microsoft Makes Large Teams Work Like Small Teams." Sloan Management Review. Fall 1997. 9-20.



Assignments (number 1 is due by midnight, Saturday, 02/26/2000):

1. Locate a specific CASE or software project management tool offered by a vendor. List the name of the tool, what technique(s) it implements, its cost, and a testimony or two of its value. Provide a web site if available.

2. Continue with Mini Paper One.
 

(c) John H. Saunders 1999. Permission granted for use in courses at the University of Maryland.