Information Systems Analysis
Current Events Discussions and Announcements
Extreme Programming (9/3/08)
Soft Systems Methodology
- A video
- An Outline
- Flux
- Learning
- Modeling
(9/3/08)
A view of how clients view specifications (9/3/08)
Standish view of Best Practices for SAD. (9/3/08)
SDLC revisited. (9/3/08)
An example of a systems analysis: Plague Homeland Security & Law Enforcement (9/3/08)
An overview of Methodologies (8/27/08)
Some information about Methodologies
- Software Development Life Cycle
- Cost of Software
- A Comparison of Methodologies
(8/27/08)
Information
Measures
of the value of information
alternate
syllabus (an example of data, not information)
Information
Comparison
Building
Blocks of IS
(8/27/08)
From Ian I. Mitroff and Harold A.
Linstone, The Unbounded Mind: Breaking the Chains of
Traditional Business Thinking, New York: Oxford University
Press, 1993.
| Almost without exception, all who write about the
new, global information age acknowledge that we are literally drowning
in an overload and overabundance of information. Never before has
humankind had access to so much, so quickly, and from every part of the
globe. We have more data and information on every conceivable subject,
yet less understanding at the same time. Data and information do not
automatically lead to greater insight; they may now travel at the speed
of light, but understanding and wisdom do not.
There is also common agreement that "data,"
"information," and "knowledge" are not the same, even though they are
often -- wrongly so -- used interchangeably. Their differences are
often as unclear to the experts as to the layperson.
One aspect above all else is especially
disturbing. It is the strong, taken-for-granted assumption that agreement
between the monumental and voluminous databases that both government
and businesses are constantly producing will eventually result, and
further that agreement itself is fundamentally desirable. -- p.20
In the end, the most general conclusion is "seek agreement or consensus
but do not trust them fully." Agreement and consensus are
important in reaching conclusions and in achieving the necessary
support to carry out complex, important policies. However, as with all
things human, they cannot be followed blindly. Nor are they the
ultimate consideration for deciding all important questions. -- p. 37
Finally, we can state some rules of thumb ....
- ·Seek the obvious, but do everything
in your power to challenge and even ridicule it.
- ·Question all
constraints. The most limiting constraints in building a model or a
representation of a problem are usually imposed not by the problem
itself but by the mindset of the problem solver.
- ·Challenge as many assumptions about
the problem and the model as possible. Remember that what seems
self-evident to the problem formulator is not always evident to others.
- ·Question the scope or the
definition of a problem or model. Frequently what is omitted from the
statement of a problem or model is more important than what is
included.
- ·Question whether a problem is to be
"solved," "resolved," or "dissolved." There are important differences
between "solving," "resolving," or "dissolving" a problem. They are not
necessarily the same. To "solve" a problem means to produce an exact or
optimal solution to it. To "resolve" a problem means to seek a solution
that is "good enough." On the other hand, to "dissolve a problem is to
realize that there may be some other problem that is more important to
focus one's attention on. The old or initial problem may still exist
but may not be as important in the broader scope of things.
- ·Finally question the logic itself.
Being logical and being right are not always the same. The more logical
a solution to a complex problem sounds, the more strongly it deserves
to be challenged. -- p. 47-48
|
(8/27/08)
Relevant Webinar events are also eligible for networking credit. For example, see these webinars from Modern Analyst.
Standish Report Results
- Resolution of Projects
- Resolution of Projects, 1994-2004
- Cost Overruns
- Cost Overruns, 1994-2004
- Top Ten Reasons for Success
- CHAOS Report: 1994
(8/18/08)
An example
consultant's analysis report: Strider and Cline evaluate UM's implementation of PeopleSoft. (8/18/08)
Systems Analysis
- What Does A Systems Analyst Really Do?
- What is Systems Analysis
- Systems Development Life Cycle
- Process v. Data Orientation
- Different Types of Systems
- Stage Deliverables
- Deliverables
- More about Deliverables
- Agile Methods
(8/18/08)
Think about the skills
associated with systems analysis. One of the items in the list is
"systems thinking." We will look at
the definition of a System
and think about what Systems
Thinking means. (8/18/08)
For more information about the
tasks necessary for Systems Analysis, visit some of the sites on the Analysis Links
page. In particular, visit the What
Does A Systems Analyst Really Do? and the Systems
Analysis Want Ads pages, and the Systems
Development Life Cycle page. (8/18/08)
|