Opening the PDF files on this page may require you to download
Adobe Reader or an equivalent viewer (GhostScript).
The first step in improving a situation is to understand it.
This means to first step is to gether facts, then to
make a mental model that fits the facts.
To be able to share your understanding, your mental model must be expressed
in a form that others can review -- presentation, hard-copy, or soft-copy? Formal or informal?
For others to review them you had best use a standard technique -- diagram, table, expression, formula,...
So I will expect you to be able to create models
using standard techniques
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 of a system.
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 logic. For
example 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.
What the above sequence does not show, is that there are certain
that are on going from the start of the life cycle to its end. They
form a set of parallel activities.
The mixture of
disciplines tends to change but the following are always present:
(Management): hiring, firing, motivating, advising, organising, removing blockages, ...
(Planning): long term and short term -- what to do next, what to do later
(Infrastructure): Obtaning, setting up, backing up, and maintaining the systems used by the project team.
(Accounting): Benefits and costs, predicting and tracking
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 time 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 large systems are not what they are supposed to be.
[ 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 code as
tests, prototypes, Betas, etc.
This works well when the solution is a program
but does not help to determine if a program is the right solution.
[ a_better_project_model_than_the_waterfall.html ]
is a short article from the Harvard Business Review
(where information flows down, like a series of waterfalls from analysis, to design,
and so to implementation and testing).
explaining why it often fails, and proposing an alternative. You should read it.
The discussion that follows is optional. The actual term Waterfall process dates back
to a paper by Winston Royce in 1970
which condems it as having never worked on a large software project.
Research at NASA forty years ago showed that errors were made early in this
kind of cycle
and fixed late in the cycle -- when the cost of fixing them would be a thousands
more than fixing the error when it was made. The catch is spotting that your analysis
is incomplete or erroneous without testing it by investing time and money in writing code.
Maintenance must follow the
same sequence as the whole cycle: fact finding; abstraction; redesign;
select change; implement; ....
In other words, even using the
waterfall life cycle
a system will go thru
a series of improvements -- after it has been "finished".
However the disciplines listed -- analysis, design, implement, test -- remain even if we
analyse a bit, design a bit, implement and test a bit; and then repeat with another
feature. We still have to found things out -- but we also accept that we discover the need
fro more "fact finding" after we have some code running. We still have to test and document code -- but
we don't expect this to be last step -- we may start design by writing a set of automated tests.
Similary after a brief anaysis we can spot a technical probel that may be difficult or expensive to solve --
and do a quick bit of programming to find out how feasible our architecture is.
* 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 40 years ago).
use various diagrams that show pictures, 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. Mathematically they are directed graphs showing arcs, edges, or arrows connecting nodes.
[ Directed_graph ]
Using the terminology of graph theory
[ Glossary_of_graph_theory ]
we can discover important properties -- for example cycles lead to feedback loops.
And feedback loops are key to understanding complex systems.
Here is the mathematical view of one of the three systems linked above... can you figure out
To reason more precisely we need to know what the nodes and arrows mean.
To be able to share ideas with other people we need a standard meaning.
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. And here
[ 240000813?cid=DDJ_nl_upd_2012-05-22_h&elq=85d07fc400a54c73be19fd172521b473 ]
is a confession.
I am a programmer. So I am at risk of the following error.
I needed to calculate the correlation coeficient of a small sample of data.
I already had a program to calculate means and standard deviations that ran
on my desktop. So I found the code, added the new functions, tested them, ran
the case I needed and got the answers I needed. It took most of my office hour
(50 minutes) to add and debug the 51 extra lines of code.
When I got home I looked for an app in the app store that did what I wanted...
they exist but not cheap.
Then I realized I should have used Google -- and 3 minutes found 2 pages of links
to free statistics calculators.
Programming may be the worst solution you can find... This class is about
considering alternatives and picking a good strategy.
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:
Systems Pentangle -- People Rules Software Data Hardware
- 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 you 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.
Logically, if changing a component has an effect on other components, then the
failure of that component can easily subvert the dependent components.
So, if hardware fails then people may have to find a work around until it
For example, see
[ http://www.wired.com/wiredenterprise/2012/08/chip_errors/ ]
(Your PC Just Crashed? Don't Blame Microsoft | Wired Enterprise | Wired.com).
But it can get a lot mor complex than this suggests. I remember a systems
that crashed every night... because the cleaners unplugged it to put in
One of the techniques computer professionals have developed is to reduce
dependencies between parts of a system by defining an
between them. For example people use a system through a User Interface.
Programmersuse a framework or subsystem by an "Application Programer
Interface" or "API".
Similarly if we change a piece of hardware for a new piece that provides the
same functions in response to the same instructions (another interface) you
will find that the software still works. In the UML we show these interfaces
So the "pentangle" becomes:
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.
ALso look at
[ http://www.skorks.com/2008/08/3-things-they-should-have-taught-in-my-computer-science-degree/ ]
(Skorks) and notice the third topic/skill that is often omitted in Comp Sci.
This summer people working for some English banks lost their jobs
because they were less than honest. This became known as the LIBOR
scandal. The systemic errors they introduced
potentially effect any body who borrows
money from any bank in the world.
Here is a very good an simple description of
LIBOR and the what the scal is about:
- LIBOR::= See http://www.bbc.co.uk/newsround/18709156,
form the BBC web site.
You should use your search engine to find out more. We will be
discussing the scandal as an example of a system that does not work
as planned for psychological reasons. This kind of failure
is the reason why we study the next topic.
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.
- Feeding and protecting their families
- Getting a life.
- Not feeling stupid.
- Showing competence.
- Getting the job done.
- Getting praised.
- Respect of peers.
- Protecting and strengthening the team, group, or culture that they feel kinship with.
- Doing the right thing.
- Avoiding boredom and doing their own thing.
More -- these goals form a hierarchy and if the earlier goals are not
met then the later goals are ignored -- a starving person will easily
I found this link
[ http://www.flickr.com/photos/77813293@N00/4926795330/sizes/z/in/set-72157624805150480/ ]
to a visual aid showing the similar "Maslow Hierarchy" and it's links to different
social networks. Key point: someone who fears for the life is not likely to
worry about more etheral needs.
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.
I, as a young geek, found Dale Carnegie's "How to win friends and influence people"
a very useful survival guide for talking to and working with non-technical
people. This won't be on any quiz or final but it improves the chances of you
doing well in your chosen career.
. . . . . . . . . ( end of section People in Systems) <<Contents | End>>
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.
. . . . . . . . . ( end of section The Composite Pattern) <<Contents | End>>
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 CSE557
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
- 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.
- system_theory::= See http://en.wikipedia.org/wiki/System_theory.
- 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.
The above formulas do not show the disciplines that must be present in parallel with the above SDLC:
- Disciplines::= Management & Planning & Infrastructure & Accounting & ...
- Project::= Disciplines & SDLC
This list shows how the above SDLC maps into our curriculum:
- Analysis -- Focus of CSE557 -- What problems to solve and how to solve them
- Design -- Focus of CSE375/558
- Implement -- CSE201,202,330,cs375/558....455
- Test -- CSE201,202,...455
- Install -- CSE 557 -- includes training, data conversion, cut-over, ...
- Operate, Backup, Support, and Maintenance -- CSE557
- Discard Obsolescent System -- Recycle!
- Disciplines -- CSE557
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
proposes a different
Game Development Process
which has three phases: Pre-production, Production, and post-production.
It argues for a creative exploration first and finishes with a beta buf-ficnding test.
It does not cope woth what happens to a game after that!
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.
Here is an interesting article
[ 5_annoying_help_desk_calls_and_how_to_banish_them ]
form "Computer World" on the design of Support in Information Technology. Find out the
5 questions that waste the trouble shooters tiem and what real organization have done about them.
. . . . . . . . . ( 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
here in the CSE dept CSUSB. Or here
[ CSE-482-project-application-form.pdf ]
is the form for developing a
CSE482 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 other classes
Here is an expanded view of the Systems Development Life Cycle:
- Work out a rough plan and win resources.
- 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 highermanagement backing.
More infrastructure. Enlarge or start project team.
- 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
- More detailed planning 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
- Get new hardware!
- 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.
It typically does not involve getting new hardware but may end up
chaqnging every other type of component.
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.
Analyze_a_little::=Select some risk to tackle | Choose a new function to add | target some performance issue to fix |...
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 (people who depend on the system) 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,
Dale Carnegie, ...
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 his students 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 the real 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. But what?
Unchecked User Input
-- User input tends to be error prone and untrustworthy. A system
must validate input before using it. Further there must be
checks and balances
between the parts of a system. You should look for cases where someone
can supply data that is never auditted.
-- Creativity is good but inefficient. Could a computer help or is it causing thought?
-- when the system is not open about what it 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?
(of data and materials)
-- is it really necessary, is it efficiently done.
-- a system that alternates 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 is a distraction?
-- when ever there is a shortage of resources you get organizational politics
(Mumford's Law), however: power is always in short supply!
-- machines don't get bored and are usually cheaper. Boring processes
are perfect targets for automation.
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.
- Here is a page
[ http://arstechnica.com/information-technology/2012/11/inside-team-romneys-whale-of-an-it-meltdown/ ]
describing a notable failure of a project in 2012... Which types of components did
the developers ignore that contributed to the failure? (Discussion).
- 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 the disciplines that are needed in parallel with the phases in 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. Clue -- Bugzilla.
[ 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 ]
A slightly more formal kind of mindmap is used by Adrew Binstock of Dr. Dobb's Journal
[ ? ]
is a more organized than a Buzan MindMap but is similar.
[ http://cmap.ihmc.us/ ]
- Home Page Cmap.html). This is targetted at helping
students master topic areas. But analysing systems is a learning
process and so these may help -- they also look a lot tidier than
Tony Buzan's Mind Maps (above). On the other hand they will be lousy
for taking notes in lectures/seminars/interviews.
. . . . . . . . . ( 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 ]
[ project0.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/ ]