• Systems and Fact Finding
• : Systems
• : Questions
• Fact Finding
• : Hints and Advice
• : Story -- Realistic Class Projects
• : Story -- Find out about the system you are replacing
• : Story -- Legacy systems -- COBOL is not dead
• : Advice when Fact Finding
• : Tool -- Look to the future
• : Goal -- List of Problems and Opportunities
• : Problems and Stakeholders
• : Interviews
• : Note taking
• : Stories are a simple form of note
• : Definitions and Terminology must be noted
• : Organizational Charts
• : Outlines and Bulleted Lists
• Review Questions on Fact Finding and Systems Thinking and Development
• Enrichment
• : EMail consider harmful
• : What happens if you apply for a job with Google?
• : Buzan -- MindMaps or Spidergrams
• Abbreviations

Systems and Fact Finding

Systems

This first step in improving a situation is to understand it. To understand something is to make a mental model of something. To be able to share your understanding your model must be expressed somehow -- 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.

Physical vs Logical Models

The systems community distinguishes two ways to look at a system:

1. Physical
2. Logical

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 of the systems architecture (using 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 very quickly compared to the underlying logical model. For example this university has discarded punched cards years ago and moved to: terminals, PCs, Telephones, the Web, ..., But the abstract processes of adding and dropping classes has not changed much in all this time.

The Logical view is also called the Essential view.

The classic form of Systems Analysis and Design consists of a series of procedures leading to particular models:


1. Fact finding
2. -> Current Physical System ->
3. Abstract the essential model
4. -> Current Logical System ->
5. Redesign the essential system
6. -> Ideal Logical System ->
7. Select the best technology for the parts of the system
8. -> Proposed Physical System ->
9. Implementation: including training, programing, translating data,....
10. Operation, Maintenance, Backup, Support etc.



You might think that that the next cycle 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 Maintenance 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.

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 Agile processes typically incorporate the model into executable code and executable tests for the code. This works well when the solution is a program but does not help to determine if a program is the right solution at all.

Systems = Boxes and Arrows

* A system is a collection of interacting subsystems.

Here is another definition from "Computer Based Systems" by John Race, Teach Yourself books 1977:

---

1. 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).

We tend use various diagrams that show boxes (or icons) connected by various kinds of arrows. Here are four examples I found on Google: [ sarsat-system-peb.jpg ] [ 2_Overview_System_Architecture.2.1.1.jpg ] [ systemComponents.gif ] [ system_analysis_2.gif ] -- note I can't copy these on to this page without risking breaching copyright. 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!


1. Between the system under study and its environment.
   
   1. Sources
   2. Sinks
   
   
2. 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
• Messages

By the way, a more recent way of analyzing a system is in terms of the dependencies 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, this notation is mostly used in practice for dependencies inside software.

The Five Types of Component in Systems



1. People -- Culture? norms? motivation? training? -- Discretion and tough decisions.
2. Processes and Procedures -- recorded?? -- Change means documentation, resistance, and training.
3. Software -- depends on the hardware and data
4. Data -- content is easy to change, structure can be expensive to change
5. 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 changing hardware, data, and software. People and procedures, 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 procedure is imposed from outside without consultation.

Exercise: how can you change each of the above types of component?

People in Systems

People are the most critical type of component in any system. They have the intelligence and creativity that lets them work around problems or to make a stupid system fail. You can not program people. You can not, cheaply, give a person a CPU or RAM upgrade.

You need some psychology 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:


1. Surviving -- including getting a fair wage.
2. Not feeling stupid.
3. Showing competence.
4. Getting the job done.
5. Getting praised.
6. ...



On top of individual psychology you need to worry about the culture of the organization. This will define norms -- patterns of behavior that are acceptable.

---

1. That is the way it has always been done.

---

Systems Patterns -- Cybernetics

Cybernetics 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.

Diagrams

Cyberneticians use two types of diagrams (W Ross Ashby). Both have boxes and arrows. One of these is the state transition diagram that shows the state of a (small) system and the possible changes of state that can happen. We will come back to these later in this class as a useful tool for documenting protocols and entities. More common and useful for complex systems, was the diagram of immediate effects that shows parts and how the 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).

Pattern -- Control Systems

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.



Feed-forward -- 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 expressions of this kind of control mechanism.

Feedback -- 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. Positive feedback increases the size of the signals each time round the loop and can lead to a run-away system. Negative feedback 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.

Exercise: Do you know of a software company that plans its software but relies on customer feedback on early versions to make a better product?

The Composite Pattern

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.

Good design means that you can change the inside of a part/component without the whole system breaking down.

Levels and meta-systems

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.

Systems Theory Glossary

The following provides some of the underlying theory for this course:
1. system::="a collection of interconnected parts".
2. subsystem::="a system that is part of a larger system", also known as a part and/or component.
3. 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".

   The interconnection of the parts means that you can not predict what happens to a part without studying the whole system.

   A collection of even simple non-linear systems will exhibit complex behaviors including chaos.

   Joke: The Generalized Uncertainty Principle of General Systemantics -- -- --(GUP)
   is that all complex systems exhibit unpredicted behaviors or "antics". For more see

   1. 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

   2. system_theory::= See http://en.wikipedia.org/wiki/System_theory.

   ---

   Key points

   • * Le Chatelier: Systems kick back: never change one you don't understand.
   • * An enterprise always includes an Information System.
   • * Modeling the enterprise helps develop the right Information System.

Life Cycles

Systems Life Cycle

1. SDLC::= Analyze, Design, Implement, Operate & Support & Backup & Maintain, Discard.

   Review of the SDLC

2. SDLC::="System Development Life Cycle", an ideal model of how software is developed, typically the following:
   
   1. Analysis -- Focus of CSci372 -- What problems to solve and how to solve them
   2. Design -- Focus of CSci375
   3. Implement -- CSci201,202,330,cs375....455
   4. Test -- CSci201,202,...455
   5. Install -- CSci 372 -- includes training, data conversion, cut-over, ...
   6. Operate, Backup, Support, and Maintenance -- CSci372
   7. Obsolescence
   
   In practice, there are many iterations of the above sequence.

   Notice, the same acronym(SDLC) is also used for the "Software Development Life Cycle", but is focused on the Implementation and Testing of software. It assumes that the problem to be solved has been determined correctly, and (subtly) must be solved by writing a program. 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

3. 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.

   There will more on Life Cycles below: SDLC2.

Operation, Backup Support, and Maintenance

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.

Operate

Systems don't work unless we do. Systems don't operate without Support and Maintenance.

Backup

In preparation for disasters the data and processes in the system need to be copied and placed in a secure place. For example: user deletes a file, fire, flood, theft, earthquake, terrorism. 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.

Support

1. Help screens/pages.
2. The help desk: a place and staff to fix and repair broken equipment,...
3. On-line forums, chat rooms, and such. Blogs. Wikis.
4. Customer service phone center...

. . . . . . . . . ( end of section Support) <<Contents | End>>

Maintenance

Maintenance is a vital part of all operating systems but 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. See the definitions below.


1. corrective_maintenance::="Correct errors and defects discovered in the system". Tends to be needed at the beginning and end of a systems life.
2. 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.
3. 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. Managing Performance: 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 capacity planning 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.
4. 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, ...
5. periodic_maintenance::="Scheduled down time for preventive maintenance".


1. Maintenance tools. Tracking, debugging, change control and configuration management.
2. Things done in maintenance:
   
   1. Diagnosing the problem and so the part that needs fixing.
   2. Fixing the parts without breaking the rest of the system.
   3. Testing the patches, and the whole rest of the system again....
   4. Refactoring the system so that the quality is not degraded by random patches.
   5. Distributing the patches to all the machines where the artifacts are deployed. Example: updates to OS's and applications on CSUSB workstations.
   
   

   Obsolescence

   Obsolescence -- do a cost/benefit analysis 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.
   (Bathtub):

   

   Pattern -- Cost of Maintenance in Commercial Software

   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 Operation, Support, and Maintenance) <<Contents | End>>

Rigid Life Cycle Standards

Some texts, some organizations, and most teachers have rigid standards that you will be expected to follow. For example, here [ ../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 and jobs.

The Systems Development Life Cycle: Analysis, Design, Implementation, ...

Here is an expanded view of the Systems Development Life Cycle:
1. sample_SDLC_details::=following,
   Net
   Repeat:
   
   1. Analyze the current system : [ Fact Finding ] , modeling, thinking,...
      • Goals -- what does management want?
      • Smells
        • Problems
        • Opportunities
        • Risks
        • Threats
        • Challenges
      • Futures: best, worst, expected,...
   2. Determine what parts need to change.
      • Data, people, procedures, hardware, software.
   3. Outline a plan and get approval.
      • Generate options
      • Evaluate: Costs & Benefits to the enterprise.
      • Present the top 2 or 3...
      • Get management to select and approve one (or try again).
   4. Detailed Analysis of parts to be changed:
      • People
      • Communications
      • Data
      • Procedures and/or Rules
      • Hardware
      • Software
      • etc etc
   5. Systems Design
      
      1. Describe new parts in detail
      2. Check that your design will work: now, and in the future. Involve others in reviewing your ideas.
      3. 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?
         • Procedures and/or Rules: training, documentation, support,...
      
      
   6. Plan development and Implementation
   7. Do Changes -- Design and Implement, convert data, train users, ...
   8. Maintain, Backup, Operate, and Support new system
   9. 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.

   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 for ever. 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 refactoring 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.

2. Sample_Agile_Life_Cycle::= do_forever( Iteration ).
3. Iteration::=Analyze_a_little; Design_a_Little & Test; Refactor.
4. Refactor::=Improve the code, step-by-step, without changing its behavior.

   Each iteration looks at a few small changes:

5. plan a little, analyze a little, design a little, implement a little, operate a little, and repeat.

   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>>

Questions

Shouldn't we talk more about and to the people in the system?

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.

See [ http://www.msnbc.msn.com/id/6174622/ ]

The following recent article starts by describing the value of the stakeholders to a system: [Simonsen07]

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 technical details.

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>>

Fact Finding

When you are fact finding you must be a mixture of reporter and detective.

Hints and Advice

1. Organization type: Is it for profit or non-profit? Does it try to maximize profit or does it optimize service within given financial constraints?
2. First get the facts, then come up with models and proposals.
3. ** What does the organization do that allows it to continue existing?
4. 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, ...
5. How does computer technology support the organizations goals etc.?
6. Take rough notes. 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.
7. 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.
8. 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.
9. Look for: Smells, Problems, Opportunities, Threats, and Risks.
10. 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 we visit.

    How does computer technology hinder and/or help the enterprise meet the challenges?

    ---

Story -- Realistic Class Projects

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.

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 work.

Story -- Find out about the system you are replacing

Once upon a time, I lived next door to a stock control clerk called Todd. He worked for a company that was putting a new 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.

Story -- Legacy systems -- COBOL is not dead

The following 2006 article in "Computer Weekly" reports on the continuing usage of COBOL in business. [ article.do?command=viewArticleBasic&articleId=266156 ]

Questions:


1. Who, What, When, How.
2. Ask about the numbers: How many, How often, How big, How fast, etc.
3. Why.



Advice when Fact Finding

1. Review any existing documents about the current system: memos, plans, Data Flow Diagrams, Entity-Relationship Diagrams, use-case diagrams,... Exisitng documents are the safest place to start. They don't get embarrassed or defensive when you examine them.
2. Get samples of existing data in the system and any blank forms. Don't forget both paper forms and HTML forms!
3. Get access to the source code -- if at all possible.
4. Interviews. See Interviews Below.
5. Take Notes: learn about mind mapping for unstructured interviews. Video or audio tape meetings, operations, interviews. See below.
6. Observe how people do things.
7. Do it yourself! Don't just observe.... but get involved.
8. Questionnaires. Ask safe questions first.
9. Practice in field trips.

. . . . . . . . . ( end of section Advice when Fact Finding) <<Contents | End>>

Tool -- Look to the future



1. Ask about the future.
2. Work out quantitative models of data -- How much, How often, How many.
3. Estimate volumes: storage, flow, outputs What happens if the system outputs the backlog of invoices the first time it is run?.
4. Guesstimate how long the critical processes/steps will take. (Does the daily weather report take 25 hours to prepare?)
5. Scalability. What happens when the load increases? Do the Math.
6. Look at possible futures. (Best case, worst case, fixing up the worst case,...)



Goal -- List of Problems and Opportunities

Problems and Stakeholders

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 stakeholders. 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 person involves the stakeholders in the analysis and design of solutions.

Interviews

1. Prepare. Prepare a set of questions to ask -- a kind of informal questionnaire with blank spaces for you to jot down answers.
2. Don't be late. Don't forget that in class there are points for being on time... and field trips are worth extra.
3. Start by asking the person's name and role. Use the name in the rest of the interview.
4. Look at the people.
5. Listen to them. Facts and feelings,...
6. Take notice and take notes. Prove that you are listening. Echo thoughts in different words back to them.
7. ASK = Always Seek Knowledge.
8. In interviews always ask for examples and samples that you can copy and take away with you.
9. Learn to listen to what is not said.
10. Take note of facts and also of feelings. Also note your thoughts (but keep them separate from your observations).
11. Thank people.... and give feedback later.
12. After any fact finding activity -- write up your notes as soon as possible.
13. 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.

14. Keep an eye/ear out for: Problems, Opportunities, Risks, and Threats -- (PORT)

. . . . . . . . . ( end of section Interviews) <<Contents | End>>

Note taking

1. Always take notes!

2. Record the key data about the interview/meeting first: who, when, where, why.... Always get the person's name right and USE it.

3. Use the techniques you are most comfortable with. Notes are personal but should, at least, be readable by you.

4. 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.

5. Here is a massive collection of visual ways of summarizing your notes: [ periodic_table.html ] Just look at the possibilities! When doing your project come back to this site to get ways to express your thoughts.

6. 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. However, use PC and laptops to summarize your data and not in the interview itself. Exception: presenting prototypes and drafts of artifacts.

7. We will come back to more specialized techniques several times in this class.

8. In your notes, distinguish what you observed from what you think. Separate the problem/oportunity/risk/threat from the solutions/proposals. Use "Problem Mapping" (more later [Simonsen07] ) to separate the problem from your solution. For example:
   Table

   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 to a cell phone.

   
   (Close Table)
   

   Short hand

   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.

   Palm top note taking

   Looks geeky. Not as effective as pencil and paper in my experience.

   Tablet computers

   Depends on the software -- the closer it mimics pencil and paper the better.

. . . . . . . . . ( end of section Hints for taking notes) <<Contents | End>>

Stories are a simple form of note

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.

Definitions and Terminology must be noted

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.

Organizational Charts

Don't forget to ask for the official one... but you can sketch your own ones ...

Outlines and Bulleted Lists



1. For example
   • bullet a
   • bullet b
   • bullet c
2. Another item
   • bullet x
   • bullet y
   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>>

Review Questions on Fact Finding and Systems Thinking and Development

1. Where is a good place to start when learning about an enterprise?
2. What is a system?
3. What are the five types of components in a systems? Which is most critical for success of a project?
4. What is feedback?
5. Draw a diagram of a heating system with a heater, house, thermometer, and thermostat.
6. Draw a diagram of a heating/AirConditioning system with a heater, chiller, house, human, thermometer, thermostat, set temperature, and switch(heat | chill | off).
7. Name some informal note taking techniques.
8. What does SDLC stand for in this course? What are the parts of the SDLC?
9. Name 4 kinds of maintenance. How is the effort distributed over the operation of a system for each of these?
10. What is an iteration in an Agile life cycle?
11. What is most important: the technology of your solution or your understanding of the situation?
12. How important are people in a system?
13. What is a stakeholder? List three types of stakeholder.
14. What is a backup and why is it created?
15. Once a system is implemented and operating, name the other 3 processes that are needed.

. . . . . . . . . ( end of section Review Questions) <<Contents | End>>

Enrichment

EMail consider harmful

Don't try to replace face-to-face interaction by Email! See [ JustSayNoToEmail.aspx?GT ]

Choose the right media for any communication [ 001302.html ] (includes a list of better media).

What happens if you apply for a job with Google?

---

1. From: Bash
2. Sent: Saturday, September 08, 2007 3:22 PM
3. Subject: Crazy Questions at Google Job Interview

   [ http://tihomir.org/crazy-questions-at-google-job-interview/ ]

---

Buzan -- MindMaps or Spidergrams

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 Tony Buzan '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>>

Abbreviations