The first step in improving a situation is to understand it.
The first step is to gether facts, then to
make a mental model of something.
To be able to share your understanding, your model must be expressed
somehow -- presentation, hard-copy, or soft-copy? Formal or informal?
So I will expect you to be able to create models that show that you understand
existing systems as part of the process of planning improvements. The "Analytical"
readings are about constructing different kinds of models.
The systems community distinguishes two ways to look at a system:
The Logical view is also called the
Any view of a system that refers to the current implementation:
(as hardware, software, or by people) is said to be a Physical View.
A view that is expressed in terms of abstractions is a Logical View.
For example: a model specifying a mainframe
and cards is a physical model. But a model in terms of abstract
ideas: entities, processes, and stores is a Logical Model.
The distinction is important because the physical details change
quicker than the logical model. For
example this registration at this university discarded punched cards years ago and moved to:
terminals, then to PCs, then to Telephones, then onto the Web, then to CMS/MyCoyote...,
But the abstract (logical) processes
of adding and dropping classes has not changed much in all this time.
The classic form of Systems Analysis and Design consists of a
series of procedures leading to particular models:
- Fact finding
- -> Current Physical System ->
- Abstract the essential model
- -> Current Logical System ->
- Redesign the essential system
- -> Ideal Logical System ->
- Select the best technology for the parts of the system.
- Specify the parts and interconnections.
- -> Proposed Physical System ->
- Implementation: including training, programing, translating data,....
- Operation, Maintenance, Backup, Support etc.
The above is OK in theory -- indeed was the process that has been
advocated for decades. However it fails in practice. First, implementing the
new system often fails because the fact finding failed to get complete or correct
requirements. Secondly, When we work on a big change there is a long gap between
fact finding and implementation and it is likely that the facts have changed.
One programmer and system developer writes
[ 001313.html ]
"Version 1 Sucks, But Ship It Anyway". Please follow this link and study this
It argues strongly for repeating the above steps iteratively -- each time
getting closer to a better system.
A later entry from the same blog
[ listen-to-your-community-but-dont-let-them-tell-you-what-to-do.html ]
describes how the same system was improved, iteratively, by analysing and discussing postings by
users of the system. The articale is well worth reading. Notice the word
for when we set up a subsystem for the purpose of talking about the system. In this case
a blog about the design of Stack Overflow. Also note the
importance of listening to stakeholders
-- in this case the users.
You might think that that the next iteration could start with out the
fact finding and abstraction because the Proposed Physical System is the
one that is the new current one. But this is not so. Implementation
can uncover things that lead to a different physical system and it
is rare for the documentation to record this. Then during operation
the system undergoes
and more undocumented changes are made that don't get mapped back into
the Proposed Physical System. So the next cycle has to start with
Fact finding to see what was actually implemented and what has happened
to it since.
Indeed systems are not what they are supposed to be in large systems.
[ http://www.datacenterknowledge.com/archives/2010/10/13/feds-discover-1000-more-data-centers/ ]
( Feds Discover 1,000 More Data Centers, October 2010).
There have been two challenges to the above process for changing a system.
In the 1980s some pundits proposed going directly to a Logical
Model (they called it an Essential Model) and starting from there.
In the late 1990's a strong movement proposed that documentation
needed to be reduced and the cycle shortened. These
processes typically incorporate the model into executable tests and
code. This works well when the solution is a program
but does not help to determine if a program is the right solution.
A final note on this traditional life cycle. Maintenance must follow the
same sequence as the whole cycle: fact finding; abstraction; redesign;
select change; implement; ....
In other words, even in the waterfall life cycle a system will go thru
a series of improvements.
* A system is a collection of interacting subsystems.
Here is another definition from "Computer Based Systems" by John Race,
Teach Yourself books 1977:
- A system is an organization of people, each with a defined responsibilities,
and using appropriate methods, to achieve together a defined set of objectives.
(Disclaimer... John was a good friend and colleague in the UK 30 years ago).
use various diagrams that show boxes (or icons) connected by
various kinds of arrows.
Here are some examples I found using Google:
[ sarsat-system-peb.jpg ]
[ 2_Overview_System_Architecture.2.1.1.jpg ]
[ systemComponents.gif ]
, please follow these links to see the examples.
Notice that because the above are informal diagrams it is not clear what
they mean. Later in this class you will meet diagrams that have quite
rigorous meanings. As a result
we can use them to analyze and design systems. We will tighten
up the notation as the course proceeds.
On the other hand -- informal diagrams
are nice in presentations and documents for managers!
In systems analysis and design we use diagrams to make our ideas
precise. You will have to demonstrate that you know the rules
for drawing and interpreting these diagrams to get a good grade. I want to be sure
you know what you are doing...
The original way to analyze systems (1940s)
was in terms of inputs and outputs. Both for the whole system for each
individual part or subsystem.
Thus the system was seen as a collection of communicating components, or
interacting parts, .... The whole was divided into parts that
communicate and these in turn are made of smaller parts. This
creates a hierarchy.
* Always notice the boundaries!
- Between the system under study and its environment.
- Between parts/components/subsystems.
* Things to notice
- Physical Boundaries and moving material
- Monetary Boundaries -- cash flows
- Movements of documents and data -- paperwork.
- Movements of ideas -- between people
- Messages and signals sent betweeen substsems and/or the environment
I common mistake by beginners is overgeneralization. This cartoon
[ http://xkcd.com/974/ ]
expresses the error perfectly.
All the systems that we a concerned with have 5 distinct types of components:
People, Rules, Software, Data, and Hardware. Each is vitally
important and understnding the differences between them is an excellent step
toward good systems thinking. The main error made by computer people is to
focus on the Hardware and the Software and ignore the other three types of
components. It does not matter how uptodate the hardware is if people hate
processes that drive it. The software may be a brilliant collection of
buss-phrase compatible programs but it will not usually work without
the right data. And so on. In this class you must learn to think
outside the box and study all five types of component:
- People -- Culture? norms? motivation? training? -- Discretion and tough decisions.
- Rules -- Laws, Norms, Processes, and Procedures -- recorded?? -- Change means documentation, overcoming resistance, and training.
- Software -- depends on the hardware, people, rules, data (below)
- Data -- content is easy to change, structure can be expensive to change
- Hardware -- requires space, power, cooling, network connections,and security.
This class is about understanding and changing the above types of components.
Notice that computer science is largely limited to studying hardware, data,
and software. People and procedures(Rules), however, are where the wheel hits the road
and where innovations can be very effective. People can also ruin a new
system -- in very creative ways. Especially when a new rule is
imposed from outside without consultation.
|Hardware||Document||Instal||Protect and Maintain
|Software||Study & Redesign||Acquire and/or Program||Maintain
You need to remember that if you change any hardware in a system then you will have to change the data
and the software. Chage the data and you will need to change the software,
anyway. Any change in software is likely to change the rules and
procedures, and these in turn mean that people have to change as well. When you plan a change recall
these dependencies and use them to find the other things ou need to do to make the system work.
A more recent way of analyzing a system is in terms of the
between the parts: changing part A means you must also
change B and C. For example: changing the software platform
(operating system, etc) means that you have to change the application software.And changing the software, usually means retraining the users.
In the Unified Modeling Language -- (UML)
a dependency is shown as a dashed arrow that points from the dependent
part to the part it depends on.
However, the UML dependency notation is mostly used for dependencies inside software.
This is covered in CSE375.
Summer 2011 -- recording bonus points for reports on seminars...
People are the most critical type of component in any system. They have the
intelligence and creativity that lets them work around problems or
make an otherwise good system fail. You can not program people. You can not,
cheaply, give a person a CPU or RAM upgrade:-)
For example take a little time to study these examples
[ stupid-user-tricks-6-it-idiocy-loves-company-184491?page=0,5 ]
of the stupid things people do with computer technology.
You need some
to design systems that people won't
sabotage. It is more than making a system look good or be user friendly.
It is all about designing systems that help people achieve their goals. The
catch is that a person's goals usually include:
- Surviving -- including getting a fair wage.
- Getting a life.
- Not feeling stupid.
- Showing competence.
- Getting the job done.
- Getting praised.
- Feeding and protecting their families
- Respect of peers.
- Protecting and strengthening the team, group, or culture that they feel kinship with.
- Doing the right thing.
- Avoiding boredom and doing there own thing.
On top of individual psychology you need to worry about the
of the organization. This will define
-- patterns of behavior that are acceptable.
- That is the way it has always been done.
is the study of control and communication. By the middle of the
20th century it had identified several classic system
patterns. If you want you can find out more
[ Cybernetics ]
on the Wikipedia.
Cyberneticians use two types of diagrams (W Ross Ashby). Both
have boxes and arrows.
One of these is
state transition diagram
that shows the state of a system
and the possible changes of state that can happen. We will come back to
these later. They are a useful tool for documenting protocols
and entity life histories.
diagram of immediate effects
is used a lot more often when analysing and designing systems. It
shows the parts of the system and how they effect each other.
Each box is a part of the whole and
an arrow goes from part A to part B if A can effect B. For example:
A thermostat turns on the heater. The heater heats the house. The house
temperature changes the thermometer in the thermostat.
(Exercise... draw the diagram).
Norbert Wiener worked in the Second World War (1939-1945) on an gun that would
automatically track its target. He invented a very simple scheme: when the target
moved the gun sensor would detect the deviation and move a little in a direction
to reduce the error. He worked out a more general theory that become part of his new
discipline of cybernetics.
-- simple chain. Example: When the weather forecast is for a
hot day, I open the windows in the early morning to get cool air into the
house. This is anticipatory control or feed forward for controlling
the temperature in my house. Plans are another example of this
kind of control mechanism. Anticipatory controls are common and necessary.
-- an information loop. The controller uses the output of the
controlled system to determine input to that system. When I set my
thermostat in my house I rely on it sampling the temperature and
running the chiller or the heater to give me temperature I want. This
is a feedback controller for the temperature in my house.
Note that feedback automatically compensates for things that are not
planned for. If I run the clothes dryer
it generates a lot of heat in the house. The house gets hotter.
The temperature goes up. The thermostat detects the increased temperature
and turns of the heat. One the other hand, if I leave a door open and ice-cold winter
air gets it, the temperature falls and the thermostat turns on the heat.
Feedback doesn't guarantee the optimum solution. But it
can handle the unexpected.
Feedback loops in systems determine the long term behavior of a system.
increases the size of the signals each time round the loop and can lead to a
does the reverse and damps down the system's behavior. A
very common pattern.
A mixture of positive
and negative feedback leads to complex behaviors and even chaos.
This may not be a bad thing.
An effective/surviving/viable system always has a mixture of anticipatory
feed-forward and feedback controls. Thus I plan my trip to work
using feed-forward, but my eyes are open as I drive to
avoid accidents. Planning and anticipation tends
to save money, but only feed back forces a system to produce acceptable
outputs in a changing environment.
However a complex network of feedback of two or more loops can produce unexpected patterns of behavior. To help people understand these complexities. Prof. Jay Forrester developed
along with tools to model systems and display how they evolve. You should look at
[ System_Dynamics ]
to get an idea of how systems behave. How ever, I have experimented a lot with
various methods of modeling systems. They do help you to understand the counter-intuitive
patterns that are often found in real systems. They do not predict the future very well.
Exercise: Do you know of a software company that plans its software
but relies on customer feedback on early versions to make a better
Some parts can program and/or monitor other parts. We sometimes
say that the source of the program(rules), control, and monitoring
is a meta-system for the system it programs.
The following provides some of the underlying theory for this course:
- system::="a collection of interconnected parts".
- subsystem::="a system that is part of a larger system", also known as a part
- supersystem::="A system that contains this as a subsystem".
A part or component can be
treated as an elementary whole, but is usually another system in turn.
Similarly each system is typically a part of a larger system. We avoid an
infinite regress by pretending that there is a top level
with "The System" connected to "The Environment".
A system (by definition) has many parts or components.
Inside a component you find a system. And so on!
This is also a pattern in software design and the basis of the fractals
found in nature.
The interconnection of the parts means that you can not predict what
happens to a part without studying the whole system.
Good design means that you can change the inside of a part/component
without the whole system breaking down. At the boundaries you must have (explicit or implicit)
contracts -- "If you scratch my back, I will scratch yours". One component guarantees to
provide the right kind of items and the other will process them correctly.
A collection of even simple non-linear systems will exhibit complex
behaviors including chaos.
Generalized Uncertainty Principle of General Systemantics
-- -- --(GUP)
is that all complex systems exhibit
unpredicted behaviors or "antics". For more see
- systemantics::= See http://en.wikipedia.org/wiki/Systemantics.
Problem: there are many ways to divide up a system into parts. In CSci372
we will typically divide a system by the movement of things and data.
Most parts in systems can be modeled as processes and stores.
Processes change material goods, or information, or money...
Stores keep the material, money, or information ...
We can model the environment as a set of external
entities. We can classify these as sources and sinks of the
material, money, information we are studying.
Later we will look at pictures and models of flows later.
For more try the Wikipedia entry
- system_theory::= See http://en.wikipedia.org/wiki/System_theory.
- * Just about everything is a system -- if you look at the right way!
- * Le Chatelier: Systems kick back: never change one you don't understand.
- * Feed back (below) trumps feed forward.
- * An enterprise always includes an Information System.
- * Modeling the enterprise helps develop the right Information System.
- SDLC::acronym="System Development Life Cycle".
Here is a simple view of a systems life cycle:
- SDLC::= Analyze; Design; Implement & Test; Install; Operate; Discard.
- Operate::=Run System & Provide Support & Provide Backup & Maintain System.
This list shows how it maps into our curriculum:
- Analysis -- Focus of CSci372 -- What problems to solve and how to solve them
- Design -- Focus of CSci375
- Implement -- CSci201,202,330,cs375....455
- Test -- CSci201,202,...455
- Install -- CSci 372 -- includes training, data conversion, cut-over, ...
- Operate, Backup, Support, and Maintenance -- CSci372
- Discard Obsolescent System
In practice, there are usually many iterations of the above sequence.
Notice, the same acronym(SDLC) is also used for the "Software Development Life Cycle".
Software Development focusses on the Implementation and Testing of software. It
assumes that the problem to be solved has been determined correctly,
and must be solved by writing a program. Neither of these assumption hold up
in reality. The discipline of
the Personal Software Process (PSP) as developed by Watts Humphrey
at CMU SEI is a highly codified way to improve your programming skills.
This also has a life cycle. Here is an example
[ psp3proc.jpg ]
from John Frankovich's thesis at the University of Calgary.
You can find out more on this, if you are interested at
- PSP::= See http://www.sei.cmu.edu/publications/documents/05.reports/05sr003.html
, but it is not what this course is about. This class is about
understanding the situation surrounding the software.
You can find out more about the various life cycles at the Wikipedia
[ Development_cycle ]
but bear in mind that the topic is subject to a lot of
debate. Also see the International Standard "Software Lifecycle Processes":
- ISO12207::standard= See http://en.wikipedia.org/wiki/Software_Lifecycle_Processes
plus IBM's latest
[ Application_lifecycle_management ]
"one ring to bind them".
Meanwhile, for airborn software you have to follow
[ DO-178B ]
If you were making a large number of identical sandwiches the most efficient
process is to lay out all the slices of bread, spread butter on all of them, put the
filling on half of them, and then assemble the sandwiches. But the other night,
I wanted two sandwiches but made one and ate it, before I started on the second one.
Because it let me improve the second sandwich.
Here we have two sandwich development life cycles. One is batch and
the other iterative. Similarly in changing systems we have
many software development processes. Choosing the right one is important.
Software projects are "R&D" -- Research and Development.
You need to distinguish the research part of a project from the development part. Unknowns and Risks need research. This must be done as soon as possible. Research should come early in each iteration. It answers questions. The answers influence how long the rest of the iteration will take. More, early iterations should contain more research. Tackling risks in the early iterations in a project leads to better estimates and better results. For example, you need to know how the client's chosen web-hosting
system does not allow CSS before you have written style sheets for the project. Once questions are answered the later iterations in a project have more developments.
Offer more functions and higher qualities.
Apologize and look for a new job.
. . . . . . . . . ( end of section Life Cycles) <<Contents | End>>
A successful system spends more time being used than being developed.
Hence the importance of the four processes that are followed
between implementation and obsolescence.
Systems don't work unless we do.
Systems don't operate without Support and Maintenance.
To prepare for disasters the data and processes in the system need to
be copied and placed in a secure place. Here are some sample disasters a system
has to recover from: user deletes something, user deletes everything,
fire, flood, theft, earthquake, terrorism.
Once you have a "sunny day" design -- assuming everything works perfectly --
use the power of negative thinking to generate worst case scenarios
and then work out plans to recover.
For example: CSUSB student data used to be copied and shipped out to a different state.
Note: in field trips find out what backup systems are in place here.
[ New-Virginia-IT-Systems-Lack-Network-Backup?art_pos=8 ]
(Slashdot Nov 9th 2009).
. . . . . . . . . ( end of section Backup) <<Contents | End>>
In addition to the system you will need to set up a support system that helps people
- Help screens/pages.
- The help desk: a place and staff to fix and repair broken equipment,...
- On-line forums, chat rooms, and such. Blogs. Wikis.
- Customer service phone center...
This is an area where most systems are less than perfect.
. . . . . . . . . ( end of section Support) <<Contents | End>>
Maintenance is a vital part of all systems in there operations phase.
It is an ignored and despised part of software work.
Here is a list of the different types:
corrective_maintenance, adaptive_maintenance, perfective_maintenance, preventive_maintenance, and periodic_maintenance. Memorise these!
See the definitions below.
- corrective_maintenance::="Correct errors and defects discovered in the system".
Tends to be needed at the beginning and end of a systems life.
- adaptive_maintenance::="Make system work in changing circumstances".
None at first and then a stream of events outside the system force
it to adapt.
Large changes can appear in the later half of a systems life.
The changes are rather like radio-active decay: there is a small
chance that any given atom will explode, but there are a lot of atoms.
In the case of systems the atoms are the assumptions made when the system
was designed. Changed assumptions force adaption.
The symptom: a memo, phone call, or Email from a stakeholder... You may need
a process to select, merge, and prioritize change requests.
- perfective_maintenance::="Make system work better: faster, cheaper, cleaner,..."
Tend to appear in the middle of the life of a system. Old systems
may not be worth replacing, and new technology are so much better than the
legacy system that it is worth replacing parts of the old system
or retuning it to work better. Perfective maintenance is about providing the
same functions with better performance. In a word: optimization.
Premature optimization is the root of all programming evil -- don't optimize
code until you have evidence that it is the problem.
first measure, then tune. Components of performance include response time, bandwidth, latency,
throughput, turnaround time...
A part of systems work is making sure that the system has enough power (capacity) to
allow it to handle a larger load. This called
and is an important part of system design.
Usually a performance
problem is fixed by changing how the data is deployed and structured not on
the tricks used to write the code.
- preventive_maintenance::="Regular inspection and improvement of all parts".
Preventive maintenance tends to be low at the beginning and end of a systems
life and peak in the middle.
Includes routine Backup, regular updates, ...
- periodic_maintenance::="Scheduled down time for preventive maintenance".
- Maintenance tools. Tracking, debugging, change control and configuration
- Things done in maintenance:
- Diagnosing the problem and so the part that needs fixing.
- Fixing the parts without breaking the rest of the system.
- Testing the patches, and the whole rest of the system again....
- Placing the corrected parts back into the live system.
- Refactoring the system so that the quality is not degraded by random patches.
- Distributing the patches to all the machines where the artifacts are deployed.
Example: updates to OS's and applications on CSUSB workstations.
In a large system with a large number of users there will be a lot of
complaints about how it works. We can call these
and it should be part of the Support process to note these so that Maintenance
can fix the important ones. These are commonly called
Tracking issues and bugs includes
[ Triage ]
which recognises issues which stem from a common bug and allocates a priority
to them. Then we need to allocate somebody to fix the bug and track their progress.
There are special tools/packages to help you do this. Some
are expensive and some are Free/Open Source.
One part of bug tracking is to spot the same issue appearing from more than one user.
These need to be merged to provide a more complete picture of the problem and its scope.
As the issues are reported they need to be classified. Here is a typical list of
types of issue
that users have with software:
- Inconvenient but there is a work arround -- change training and user interface when there is time.
- System does something wrong -- classify as a bug and set a priority.
- System does not do something that it should -- missing function bug
- System does something slowly/unreliably -- performance.
- Systems allows user to do something bad -- Security.
Bugs need to be assigned to a particular person in the maintenance team who
is responsible for fixing it. Since in a large organization many people will all
be maintaining the software, there is a need for Configuration Management and
Revision Control Systems. THese make sure that only one person can change part of
the software at a time and also keep track of the many versions that appear as
After the first version is released the costs of updates often exceeds the
cost of making the first version -- indeed often the amount of code
changed in each release is equal to the size of the first release!
Software engineering and architecture
is about making it cheap to make
changes to software.
. . . . . . . . . ( end of section Maintenance) <<Contents | End>>
Obsolescence -- do a cost/benefit analysis (later in this course)
comparing maintaining the current
system with replacing it with a new one.
Don't forget the bath tub curve: costs start high, drop and then
start climbing again.
. . . . . . . . . ( end of section Operation, Support, and Maintenance) <<Contents | End>>
Some texts, some organizations, and most teachers have rigid standards that
you will be expected to follow. For example,
[ ../SRS/ ]
is a description of the key artifact in developing graduate projects
here in the CSci dept CSUSB. Or here
[ CSCI_482_Senior_Interdisciplinary_Project#Steps_for_Completing_CSCI_482 ]
is the procedures and forms for developing a CSci482 Senior Project.
Note: you don't have to memorize these for this class. But you
may very well be forced to follow such templates in this and many other classes
Here is an expanded view of the Systems Development Life Cycle:
- Analyze the current system :
[ Fact Finding ]
, modeling, thinking,...
- Who has a stake in the system -- who are the stakeholders?
- Goals -- what do the stakeholders want?
- Look for "SPORTs".
- Smells -- things that are not quite right or even just plain wrong
- Problems -- Effects the performance of the enterprise
- Opportunities -- Something that the enterprise can use
- Risks -- Things that might go wrong internally
- Threats -- Things that others might do to effect the enterprise badly.
- Futures: best, worst, expected,...
- Challenges facing the enterprise
- Determine what parts need to change.
- Data, people, procedures, hardware, software.
- Outline a plan and get approval. Get management backing.
- Generate at least three(3) options
- Evaluate: Costs & Benefits to the enterprise.
- Present the top 2 or 3 options to management and stakeholders.
- Get the stakeholders to select and approve one (or try again).
- Detailed Analysis of components to be changed:
- etc etc
- Systems Design
- Describe new parts in detail.
- Check that your design will work: now, and in the future.
Involve others in reviewing your ideas. Use walk-throughs, inspections, and tools
to verify that all the parts work together correctly to achieve the objectives.
- How might they be implemented: type of component.
- Software: use existing, buy, build, outsource, open source, ...
- People: sack, hire, retrain, promote, move,...
- Hardware: upgrade, buy, lease, repurpose,...
- Data: content or structure?
- Rules: Procedures, training, documentation, support,...
- Plan development and Implementation
- Do Changes -- Design and Implement, convert data, train users, ...
- Maintainenance, Backup, Operate, and Support new system
- Obsolescence: Retire system
(End of Net)
Notice: the bigger the change the more expense and risk is involved.
Just about every attempt to follow a sequence of steps like the above
with no feedback on a large project has lead to cost over-runs and
(often) failure. Also notice that small, incremental improvements
tend to work -- and are called maintenance.
In other words: Maintenance uses same cycle but faster and with smaller steps.
However, once a system enters obsolescence maintenance ceases to be an option.
Agile life cycles rely on feedback rather than feed-forward.
They assume that it is best to eat an elephant one bite at a time.
They tend to have many small iterations of
the same phases but without discarding the running system -- the cycle repeats
Another difference is that agile processes tend to stress early testing
and live code rather than diagrams and documentation.
The final difference is the use of
to maintain the quality of the code base after a small set of changes. Refactorings
are a set of systematic changes in software that are guaranteed to preserve
its correctness while improving its quality.
Sample_Agile_Life_Cycle::= do_forever( Iteration ).
Iteration::=Analyze_a_little; Design_a_Little & Test; Refactor.
Refactor::=Improve the code, step-by-step, without changing its behavior.
Each iteration looks at a few small changes and aims to have a working subsystem or partial
implementation at the its end. These are typically given a fixed length of time but
with flexible goals.
One agile process has single 40-hour week as one cycle(eXtreme Programming/XP).
Scrum tends to use 1 month cycles. Adaptive Software Development(ASD) would let
the team select the length of a cycle.
For more see
[ http://www.agilealliance.com/ ]
(The Agile Alliance).
Notice that Agile Methods are very suitable for software development and
research projects -- when we can not be sure of the right direction.
. . . . . . . . . ( end of section Life Cycles) <<Contents | End>>
This principle is as old as the Roman Empire "Caveat Emptor". It especially
applie with bargains and offers of freebies. For example, this comic
[ ?id=20101031&mode=classic ]
"The hardware is Free"
A variety of this is -- Give away the razor but sell the razor blades.
Free/Open Source Software
you should look for hidden costs in
implementing and supporting it.
Absolutely. I consider them to be the critical "component"
in any system. They will star in future topics!
The only reason for a new system is the people it will serve.
[ http://www.msnbc.msn.com/id/6174622/ ]
The following recent article starts by describing the value of
the stakeholders to a system:
People also have the information that we need to make
a system that is worth producing. The people define the problems
and opportunities. People have wants and needs that have to be met
if the systems is to have any positive value.
A Systems analyst has the challenging job of bridging between
the people and the technology. They need to be able to work with
people, talk (and listen) to people, as well as handle enumerable
However we can not lose sight of the other types of component:
data, hardware, software, and processes(procedures/rules). These
are also important sources of information for the analyst and designer.
They also constrain the possible solutions. They are also less likely
to react badly when you investigate them. I have known
people to lie to sabotage computer projects. They commonly tend
to clam up if you are not careful.
So although people are vital, the other components are also
important. The job of the computer professional is to not
miss any of them out.
For more on people -- study psychology. Here are some key
words to search for: Maslow, Douglas McGregor, B F Skinner, ...
To learn about people in organizations try: C Northcote Parkinson
[ parkinson_review.htm ]
. . . . . . . . . ( end of section Questions) <<Contents | End>>
. . . . . . . . . ( end of section Systems) <<Contents | End>>
When you are
"fact finding" you must be a mixture of reporter and detective.
Many years ago a colleague used to teach a course like this in my
Alma Mata in England. He always set a project for the students.
When he was in charge of recruiting students he asked them to
find ways to make this task easier. Another year he took a
problem out of the headlines: a company on the edge of bankruptcy
because it couldn't sort out the various specialized products it
was working on -- at the end he invited the CEO (a friend) to
talk with the students about their solutions and his solution.
- Organization type: Is it for profit or non-profit?
Does it try to maximize profit or does it optimize service within given
- First get the facts, then come up with models and proposals.
- ** What does the organization do that allows it to continue existing?
- How does computer technology support the organizations goals etc.?
- Review any existing documents about the current system: memos, plans,
Data Flow Diagrams, Entity-Relationship Diagrams, use-case diagrams,...
Existing documents are the safest place to start. They don't get embarrassed
or defensive when you examine them.
- Tackle the documentation and paperwork
before you talk to people: Does the organization
have a vision statement, a mission, goals, a business model, manuals,
data bases, program source code, ...
- Get samples of existing data in the system and any blank forms.
Don't forget to collect both paper forms and HTML forms!
- Questionnaires. Ask safe questions first.
- Get access to the source code -- if at all possible.
- Interviews. See Interviews Below.
- Take Notes: learn about mind mapping for unstructured interviews.
Any diagram or format we cover in this course can
be used quickly and roughly using pencil and paper. Later
tidy it up using tools.
- Why not make audio or visual records of things? A Cell phone camera
can capture data for later analysis. Note: before you record a meeting
or interview -- get people's permission.
Video or audio tape meetings, operations, interviews. See below.
- Observe how people do things.
- Do it yourself! Don't just observe.... but get involved.
- Look out for the difference between the official, documented, manifest
system and the informal, undocumented, latent organization.
You will often find that people make the official system work
by doing things that are not documented.
- Look for SPORTs: Smells, Problems, Opportunities, Risks, and Threats.
- What are the enterprises current challenges?
Most enterprises have some challenges facing them. Make sure you know
what these are for your organization
-- that way you can make your proposals match the challenges.
On the field trips try to find out what is challenging the enterprise that
How does computer technology hinder and/or help the enterprise
meet the challenges?
- Questions to ask:
- Who, What, When, How.
- Ask about the numbers: How many, How often, How big, How fast, etc.
- Look to the future
- Ask about the future.
- Work out quantitative models of data -- How much, How often, How many.
- Estimate volumes: storage, flow, outputs
What happens if the system outputs the backlog of invoices
the first time it is run?.
- Guesstimate how long the critical processes/steps will take.
(Does the daily weather report take 25 hours to prepare?)
- Scalability. What happens when the load increases? Do the Math.
- Look at possible futures. (Best case, worst case, fixing up the worst case,...)
One year he involved the whole faculty by asking us to act various
people involved in running a restaurant -- manager, cook, waiter,
head waiter, ... The students had to interview us and then propose
a new system. Not one students realized that the head waiter had
a gigantic stake in choosing the table to which parties were taken...
and was lying when he said that a computer would never
Once upon a time, I lived next door to a stock control clerk
called Todd. He worked for a company that was putting in a computer.
Because he was expecting to lose his job he told the programmer
many lies about how the company did its work. The resulting software
worked very badly -- and the programmer lost her job.
Better fact finding and a better understanding of the organization
might have lead to a more efficient company and a better working
environment for Todd and the young programmer.
The following 2006 article in "Computer Weekly" reports on the continuing
usage of COBOL in business.
[ article.do?command=viewArticleBasic&articleId=266156 ]
Smells are clues to things that may need fixing to make a system work better -- to serve
its organization better. Here is a quick list of some
you may notice.
-- when a system fails to produce the correct results then there is probably
something wrong inside it.
-- Creativity is good but inefficient. Could a computer help or is it a cause?
-- when the system is not open about what is doing or people seem to be hiding
something then it worth looking in more detail.
-- do the people working in a system interfere with its function (throw their
shoes in the works)?
-- People get tired but a machine does not...
-- systems will work better if they do not make people unhappy.
-- check out every piece of paper work, what is its value?
Movement of data and materials
-- is it really necessary, efficiently done.
-- a system that has shortages and over production has a faulty communication
pattern that is introducing delays and/or positive feedback
-- how much of the information flying around a system is actualy of value and
how much a distraction?
-- when ever there is a shortage of resources you get organizational politics
(Mumford's Law), however power is always in short supply!
A problem always involves people and one task is to make a
list of those most dependent on the solving the problem.
We call them
They include the direct users,
the people who think they will be hurt by a new system,
the manager who will look bad, the people who work the system, the
developers of the solution, ...
The wise developer involves the stakeholders in the analysis and design of
Prepare a set of questions to ask -- a kind of informal questionnaire with blank
spaces for you to jot down answers.
- Don't be late. Don't forget that in class
there are points for being on time... and field trips are worth extra.
- Start by asking the person's name and role. Use the name in the rest of the interview.
- Look at the people.
- Listen to them. Facts and feelings,...
- Take notice and take notes.
- Prove that you are listening. Echo thoughts in different words back to them.
- ASK = Always Seek Knowledge.
- In interviews always
ask for examples and samples that you can copy and take away with you.
- Learn to listen to what is not said.
- Take note of facts and also of feelings. Also note your thoughts (but keep
them separate from your observations).
- Thank people.... and give feedback later.
- After any fact finding activity -- write up your notes as soon as possible.
- To get some one to talk: translate what they say and
echo it back to them. Write notes when they say good things not bad
(delay these for a moment...). To shut them up: drop your pencil.
(feelings): Bad feelings are a powerful "smell". So are hopes and fears.
Use them to guide your choice of problems to solve.
- Keep an eye/ear out for SPORTs!
. . . . . . . . . ( end of section Interviews) <<Contents | End>>
- Always take notes! (1) it keeps you awake. (2) it makes you look interested. (3)
the notes will help you recall what was said.
- Record the key data about the interview/meeting first: who, when, where, why....
Always get the person's name right and USE it.
- Use the techniques you are most comfortable with. Notes are personal
but should, at least, be readable by you.
- Review your notes -- several times. When you review -- do something with the
data: summarize, transcribe into a electronic form, recite from memory,
reorganize, draw using a special technique, add ideas, etc.
I take notes in pencil and color them in later.
- Here is a massive collection of visual ways of summarizing your notes:
[ periodic_table.html ]
Just look at the possibilities! Find the "Stakeholder map" as an example.
When doing your project come back to this
site to get ways to express your thoughts.
- There are several computerized tools that are intended to help teams
organize their thoughts, clarify stakeholder concerns, etc. Some of these
are even open source or free. Examples include IBIS/Compendium, ...
- Don't forget that you don't have to use paper: 3><5 cards are easy to sort and
cheap and fit in a pocket, Sticky notes can be moved around on a board, and a
tablet computer or palm top is just about usable in a meeting/interview. PCs
and laptops get in the way and people will think you are goofing off.
- However, use
PC and laptops to summarize your data after the interview.
- But, a PC/laptop + projector helps present prototypes and drafts of artifacts. When a small group
needs to rapidly develop a document then projecting a draft version and
editing it can work well.
- We will come back to more specialized techniques several times in this class.
- In your notes, distinguish what you observed from what you think.
Separate the smell/problem/opportunity/risk/threat from the solutions/proposals.
Use "Problem Mapping" (more later
) to separate the problem from your solution. For example:
|Problem or Need||Cause||Consequence||Solution
|Students can't find their classes on the first day
||They don't know the geography of the campus.
||They miss part or whole of a class.
They attend the wrong class.
They may drop out.
||Provide an on-line map with their schedule highlighted
on the web and/or to a cell phone.
When you are taking notes you can use your own short-hand. I've done this for
years. This is good security and also means you can get
more information down in the same time.
Looks geeky. Not as effective as pencil and paper in my experience.
Depends on the software -- the closer it mimics pencil and paper the better.
. . . . . . . . . ( end of section Hints for taking notes) <<Contents | End>>
A story is a short paragraph that describes how something happens.
Ideally it should fit on a 3><5 card. They can describe what exists
or what is wanted. Stories must be simple. The need a name.
Build up a glossary for the system you are studying -- a alphabetic
list of terms and there meanings. Again 3><5 cards are very helpful.
I tend to use a notation
based on the Bachus-Naur-Form:
Term ::= meaning.
Don't forget to ask for the official one... but you can sketch your own
- For example
- bullet a
- bullet b
- bullet c
- Another item
These are excellent for recording sequences and plans. They also do
a nice job for hierarchies and classifications, for minutes
in a meeting, and planning a presentation. Note: people over-do
bullet points in PowerPoint presentations: Avoid the Machine Gun Bullet Point effect!
. . . . . . . . . ( end of section Fact Finding) <<Contents | End>>
- Where is a good place to start when learning about an enterprise?
- What is a system?
- The five types of components in a system are named by words that start(alphabetically): D,H,P,R,S.
What do they stand for? Work out a personal mnemonic (word or sentence) to remind you of letters.
- What are the five types of components in a systems? Which is most critical for
success of a project? Explain what is needed to change each type.
- What is feedback?(essay)
- Draw a diagram of a heating system with a heater, house, thermometer, and thermostat.
- Draw a diagram of a heating/AirConditioning system with a heater, chiller,
house, human, thermometer, thermostat, set temperature, and switch(heat | chill | off).
- Name some informal note taking techniques.
- What does SDLC stand for in this course? What are the parts of the SDLC?
- Name 4 kinds of maintenance. How is the effort distributed over
the operation of a system for each of these?
- What is an iteration in an Agile life cycle?
- What is most important: the technology of your solution or your understanding of
- How important are people in a system?
- What are SPORTs? and why do you look for them?
- What is a stakeholder? List three types of stakeholder.
- What is a backup and why is it created?
- Once a system is implemented and operating, name the other 3 processes that are needed
to keep it operating.
. . . . . . . . . ( end of section Review Questions) <<Contents | End>>
Don't try to replace face-to-face interaction by Email!
[ JustSayNoToEmail.aspx?GT ]
Choose the right media for any communication
[ 001302.html ]
(includes a list of better media).
- From: Bash
- Sent: Saturday, September 08, 2007 3:22 PM
- Subject: Crazy Questions at Google Job Interview
[ http://tihomir.org/crazy-questions-at-google-job-interview/ ]
See what you can find out about tools for bug or issue tracking in an open
source project like Mozilla or Linux.
See what you can find out about tools for bug or issue tracking in an open
source project like Mozilla or Linux.
[ Configuration_management ]
[ Revision_Control_System ]
Question: Define delta, commit, fork, merge, RCS, CVS, SCCS, ...
These have a central node that names the topic with the key ideas radiating
out from it. I like them and use them a lot. You don't have to
use it in this course, but if you want to learn more start with
's web page
[ Mind_Maps.htm ]
and then the following web searches:
[ search?cat=img&cs=utf8&q=buzan+mindmap&rys=0&itag=crv ]
[ images?q=buzan+mindmaps&hl=en&btnG=Search+Images ]
. . . . . . . . . ( end of section Enrichment) <<Contents | End>>
. . . . . . . . . ( end of section Systems and Fact Finding) <<Contents | End>>
TBA::="To Be Announced".
TBD::="To Be Done".
Notes -- Analysis
[ a1.html ]
[ a2.html ]
[ a3.html ]
[ a4.html ]
[ a5.html ]
[ c1.html ]
[ c2.html ]
[ c3.html ]
[ d1.html ]
[ d2.html ]
[ d3.html ]
[ d4.html ]
[ r1.html ]
[ r2.html ]
[ r3.html ]
[ project1.html ]
[ project2.html ]
[ project3.html ]
[ project4.html ]
[ project5.html ]
[ projects.html ]
[ F1.html ]
[ F2.html ]
[ F3.html ]
[ about.html ]
[ index.html ]
[ schedule.html ]
[ syllabus.html ]
[ readings.html ]
[ review.html ]
[ glossary.html ]
[ contact.html ]
[ grading/ ]