Information Systems Development — System Analysis and design methods

Please note that the following publication is available on an "as-is" basis and has not undergone any editorial review. 

Review questions:

3. Table 3-1 in the textbook illustrates the difference in a typical project's duration, person-months, quality, and cost, depending upon whether an organization's system development process is at CMM level 1, 2, or 3. Between which two CMM levels does an organization gain the greatest benefit in terms of percentage of improvement? What do you think is the reason for this? 

~> While this is by no means the only correct answer, I'd argue that the greatest benefit in terms of percentage of improvement comes between level 1 and 2. While it is not the goal of CMM to stop at level 2 but to move on to as high a level as feasible, the fact that all organizations start at level 1 and must move up one step at a time means that the transition between levels 1 and 2 is one that all organizations have made or need to make. Achieving this level is critical because this is the first level where earlier project successes are looked into to help with current and future projects. A stable level 2 means that transition to standard processes in the next level will be as smooth as possible. A solid foundation at this stage could make standardizing processes for the next levels less troublesome and less costly. At a cursory glance, it also appears that the business value (ratio between investment in CMM and the dollar value generated by using CMM) would be be greatest for the transition from level 1 to level 2. Finally, the level 1 organization is totally immature and there is almost no basis for judging the quality or efficiency at that stage. Jian Wang at the Univiersity of Michigan at St Louis wrote, "In an immature organization, there is no objective basis for judging product quality or for solving product or process problems." The percentage improvement in going from nothing to something is something you cannot beat at any other level. For example at higher levels, you are probably trying to go from a ~60% (in network efficiency or up time or so on) to a ~80% or at level six (optimized), you are probably looking at the proverbial six nines and achieving 99.9999%. Going from a 60% to an 80% does not come close to the infinite percentage improvement you get from going from a zero to a finite number (say around 20%).from http://www.umsl.edu/~sauterv/analysis/6840_f03_papers/wang/IS6840FinalPaper.doc  

Thus, I believe that the greatest gain in terms of percentage of improvement is between levels 1 and 2.

4. Systems development methodology and system life cycle are two terms that are frequently used and just frequently misused. What are the differences between these two terms?

System development methodology is a formalized approach to the systems development process. It is a standardized process that includes the activities methods, best practices, deliverables, and automated tools to be used for information systems development. System life cycle is the factoring of the lifetime of an information system into two stages: 1. systems development 2. systems operation and maintenance—first you build it and then you use and maintain it. Eventually you cycle back to redevelopment of a new system. 

SDM	SLC
SDM is planned.	SLC just happens.
SDM executes the system development of the SLC.	There is more to SLC than just development.
Methodology can be purchased or homegrown.	Life cycle decisions must, ultimately, be in-house.

6. A number of underlying principles are common to all systems development methodologies. Identify these underlying principles and explain them.

The principles are as follows:

1. Get the system users involved: Seek agreement from all stakeholders. Try to minimize miscommunication and misunderstanding between technical staff and the users and management.
2. Use a problem-solving approach: Understand the problem and follow all steps when using the classical problem-solving approach.
3. Establish Phases and Activities: Establish and follow the phases and activities as decided.
4. Document throughout development: Documentation is critical. Document as you go and try to avoid post-documentation.
5. Establish standards: Standards are important in order to allow disparate objects to work together in sync. Embrace standards, not proprietary technology, wherever possible.
6. Manage the process and projects: Be consistent. Use your system development process/methodology in all projects.
7. Justify information systems as capital investments: Make sure that the cost-benefit analyses are properly conducted and the estimated costs truly reflect the reality. Pay attention to the unexpected and overheads as well as expanding scopes. 
8. Don't be afraid to cancel or revise scope: Creeping commitment can cause entire projects to never deliver. Do not try to accomplish too much. Do not be afraid to draw lines in sand. Use sound economics and common sense and understand the concept of sunk costs. If necessary, do not be afraid to call the whole project off.
9. Divide and conquer: Use factoring (dividing a system into subsystems and components in order to more easily conquer the problem and build the larger system).
10. Design systems for growth and change: Plan ahead.

8. Each phase of the project includes specific deliverables that must be produced and delivered to the next phase. Using the textbook's hypothetical FAST methodology, what are the deliverables for the requirements analysis, logical design, and physical design/integration phases? 

Phase	Deliverables
Requirement analysis	Business requirement statement
Logical design	Logical system models and specifications
Physical Design/integration	some combination of Physical design models and specifications, design prototypes, and redesigned business processes

Research project #2. You are a new project manager and have been assigned responsibility for an enterprise information systems project that touches every division in your organization. The chief executive officer stated at project initiation that successfully implementing this project was the number one priority of your organization. The project is in midst of the requirements analysis phase. While it is on schedule, you notice that attendance of the system users and owners at meetings on requirements has been dropping. A more experienced project manager has told you not to worry, that this is normal. Should you be concerned?

~> Yes. Although the project is on schedule and it is highly likely that we will ship on time, if the final product is not what the stakeholders need, then the project will need costly modifications. We know that fixing code in pre-release form is much cheaper than fixing code that has already been shipped. Moreover, truly capturing and understanding what the stakeholders need and translating it to be an integral part of the initial project makes the most sense. Thus, yes, there is a reason to be concerned about dropping attendance. If attendance cannot be improved, an alternative way to encourage stakeholder participation has to be found.