[Skip Navigation] [CSUSB] / [CNS] / [CSE] / [R J Botting] /[CS557 Course Materials] /a1.html [Search ] Mon Dec 3 14:42:13 PST 2012
[a1.txt(Text)] [a1.pdf(PDF)]
[About] [News] [Schedule] [Syllabus] [Readings] [Glossary] [Contact] [Grades]
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Contents

    Systems and Fact Finding

      Introduction

      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.

      Physical vs Logical Models

      The systems community distinguishes two ways to look at a system:
      1. Physical
      2. Logical

      The Logical view is also called the Essential view.

      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:

      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. Specify the parts and interconnections.
      9. -> Proposed Physical System ->
      10. Implementation: including training, programing, translating data,....
      11. Operation, Maintenance, Backup, Support etc.

      What the above sequence does not show, is that there are certain disciplines 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 blog entry. 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 meta 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 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.

      Indeed large systems are not what they are supposed to be. For example: [ 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 Agile 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.

      Here [ a_better_project_model_than_the_waterfall.html ] is a short article from the Harvard Business Review defining the Waterfall Process (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 [Royce70] 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.

      Systems as 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 40 years ago).

      We tend 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 which?

      [A digraph representing a system]

      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!

      1. Between the system under study and its environment.
        1. Sources
        2. Sinks

      2. Between parts/components/subsystems.

      * Things to notice

      A Common Error in Systems Work -- Overgeneralization

      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.

      Story -- Another Common Error -- it is not about the programming

      I am a programmer. So I am at risk of the following error.
        May 2012. 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.

      The Five Types of Component in Systems

      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

      1. People -- Culture? norms? motivation? training? -- Discretion and tough decisions.
      2. Rules -- Laws, Norms, Processes, and Procedures -- recorded?? -- Change means documentation, overcoming resistance, and training.
      3. Software -- depends on the hardware, people, rules, data (below)
      4. Data -- content is easy to change, structure can be expensive to change
      5. Hardware -- requires space, power, cooling, network connections,and security.

      [Systems Pentangle]

      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.

      Five Types of Components in a Project


      Table
      TypeDevelopmentImplementationOperation
      PeopleInvolveTrainSupport
      DataAnalyseConvertBackup
      HardwareDocumentInstalProtect and Maintain
      SoftwareStudy & RedesignAcquire and/or ProgramMaintain
      RulesReviewTrainingMonitor

      (Close Table)

      Dependencies between types of components

      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.

      [People->Rules->Software->Data->Hardware]

      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, 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 is fixed. 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 a polisher...

      One of the techniques computer professionals have developed is to reduce dependencies between parts of a system by defining an interface 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 using a lollipop symbol: o----. So the "pentangle" becomes:

      [People->Rules->o-Software->o--Data->o--Hardware]

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

        Example -- The LIBOR scandal as a System Problem

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

        Psychology

        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. Feeding and protecting their families
        3. Getting a life.
        4. Not feeling stupid.
        5. Showing competence.
        6. Getting the job done.
        7. Getting praised.
        8. Respect of peers.
        9. Protecting and strengthening the team, group, or culture that they feel kinship with.
        10. Doing the right thing.
        11. Avoiding boredom and doing their own thing.
        12. ...

        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 rationalize stealing. 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 culture of the organization. This will define norms -- patterns of behavior that are acceptable.

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

        Further Reading on People

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

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

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

        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 another example of this kind of control mechanism. Anticipatory controls are common and necessary.

        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.

        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 Systems Dynamics 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 product?

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

        The Composite Pattern

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

        Complex Systems are hard to predict

        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.

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

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

        Some Key points of Systems Theory

        • Just about everything is a system -- if you look at the right way!
        • Le Chatelier: Systems kick back: never change one you don't understand.
        • Feed back (below) trumps feed forward.
        • An enterprise always includes an Information System.
        • Modeling the enterprise helps develop the right Information System.
        For more try the Wikipedia entry
      5. system_theory::= See http://en.wikipedia.org/wiki/System_theory.

      Life Cycles

        Systems Life Cycle

      1. SDLC::acronym="System Development Life Cycle".

        Here is a simple view of a systems life cycle:

      2. SDLC::= Analyze; Design; Implement & Test; Install; Operate; Discard.
      3. 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:

      4. Disciplines::= Management & Planning & Infrastructure & Accounting & ...
      5. Project::= Disciplines & SDLC

        This list shows how the above SDLC maps into our curriculum:

        1. Analysis -- Focus of CSE557 -- What problems to solve and how to solve them
        2. Design -- Focus of CSE375/558
        3. Implement -- CSE201,202,330,cs375/558....455
        4. Test -- CSE201,202,...455
        5. Install -- CSE 557 -- includes training, data conversion, cut-over, ...
        6. Operate, Backup, Support, and Maintenance -- CSE557
        7. Discard Obsolescent System -- Recycle!
        8. 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

      6. 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":

      7. 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 ] !

        Joke -- Sandwich Development Life Cycles

        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. Why?

        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.

        Hint -- Do the research before the development

        Software projects are "R&D" -- Research and Development. You need to distinguish the research part of a project from the development part. Unknowns and Risks need research. This must be done as soon as possible. Research should come early in each iteration. It answers questions. The answers influence how long the rest of the iteration will take. More, early iterations should contain more research. Tackling risks in the early iterations in a project leads to better estimates and better results. For example, you need to know how the client's chosen web-hosting system does not allow CSS before you have written style sheets for the project. Once questions are answered the later iterations in a project have more developments.

        This [Mountain10] 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!

        What do you do when you finish a project early?

        Offer more functions and higher qualities.

        What do you do when you finish a project late?

        Apologize and look for a new job.

      . . . . . . . . . ( end of section Life Cycles) <<Contents | End>>

      Operation includes Backup Support 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

          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.

          2009-11-24 Tue Nov 24 10:27 Consequences of Lack of Backup

          [ New-Virginia-IT-Systems-Lack-Network-Backup?art_pos=8 ] (Slashdot Nov 9th 2009).

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

        Support

          In addition to the system you will need to set up a support system that helps people use it.
          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...

          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

          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.

          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. Placing the corrected parts back into the live system.
          5. Refactoring the system so that the quality is not degraded by random patches.
          6. Distributing the patches to all the machines where the artifacts are deployed. Example: updates to OS's and applications on CSUSB workstations.

          Bug and Issue Tracking

          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 Issues and it should be part of the Support process to note these so that Maintenance can fix the important ones. These are commonly called Bugs. 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:

          1. Inconvenient but there is a work arround -- change training and user interface when there is time.
          2. System does something wrong -- classify as a bug and set a priority.
          3. System does not do something that it should -- missing function bug
          4. System does something slowly/unreliably -- performance.
          5. 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 software evolves.

          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 Maintenance) <<Contents | End>>

        Obsolescence

        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.
        (Bathtub):

        [High at first, low in middle of life, rising at the end again]

      . . . . . . . . . ( 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 Masters Projects 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 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. Work out a rough plan and win resources.
        2. 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".
          • SPORTs::=following,
            • 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
        3. Determine what parts need to change.
          • Data, people, procedures, hardware, software.
        4. Outline a plan and get approval. Get highermanagement backing. More infrastructure. Enlarge or start project team.
          1. Generate at least three(3) options
          2. Evaluate: Costs & Benefits to the enterprise.
          3. Present the top 2 or 3 options to management and stakeholders.
          4. Get the stakeholders to select and approve one (or try again).

        5. Detailed Analysis of components to be changed:
          • People
          • Data
          • Rules
          • Hardware
          • Software
          • Communications
          • etc etc
        6. More detailed planning etc.
        7. 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. Use walk-throughs, inspections, and tools to verify that all the parts work together correctly to achieve the objectives.
          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?
            • Rules: Procedures, training, documentation, support,...

        8. Plan development and Implementation
        9. Get new hardware!
        10. Do Changes -- Design and Implement, convert data, train users, ...
        11. Maintainenance, Backup, Operate, and Support new system
        12. 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.

      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. Analyze_a_little::=Select some risk to tackle | Choose a new function to add | target some performance issue to fix |...
    5. 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>>

    Principle -- Buyer Beware

    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 ] summarizes the "The hardware is Free" Business model.

    A variety of this is -- Give away the razor but sell the razor blades.

    Again with Free/Open Source Software you should look for hidden costs in implementing and supporting it.

    Questions from Students on Systems

      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 (people who depend on the system) 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, 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>>

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. How does computer technology support the organizations goals etc.?
    5. 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.
    6. 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, ...
    7. Get samples of existing data in the system and any blank forms. Don't forget to collect both paper forms and HTML forms!
    8. Questionnaires. Ask safe questions first.
    9. Get access to the source code -- if at all possible.
    10. Interviews. See Interviews Below.
    11. 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.
    12. 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.
    13. Observe how people do things.
    14. Do it yourself! Don't just observe.... but get involved.
    15. 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.
    16. Look for SPORTs: Smells, Problems, Opportunities, Risks, and Threats.
    17. 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?

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

    19. 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,...)

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

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

    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 ]

    Smells

    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 System Smells you may notice.

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

    Thinking -- Creativity is good but inefficient. Could a computer help or is it causing thought?

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

    Sabotage -- do the people working in a system interfere with its function (throw their shoes in the works)?

    Fatigue -- People get tired but a machine does not...

    Unhappiness -- systems will work better if they do not make people unhappy.

    Paperwork -- check out every piece of paper work, what is its value?

    Movement (of data and materials) -- is it really necessary, is it efficiently done.

    Oscilation -- a system that alternates shortages and over production has a faulty communication pattern that is introducing delays and/or positive feedback (see above).

    Noise -- how much of the information flying around a system is actualy of value and how much is a distraction?

    Politics -- when ever there is a shortage of resources you get organizational politics (Mumford's Law), however: power is always in short supply!

    Boredom -- machines don't get bored and are usually cheaper. Boring processes are perfect targets for automation.

    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 developer 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.
    7. Prove that you are listening. Echo thoughts in different words back to them.
    8. ASK = Always Seek Knowledge.
    9. In interviews always ask for examples and samples that you can copy and take away with you.
    10. Learn to listen to what is not said.
    11. Take note of facts and also of feelings. Also note your thoughts (but keep them separate from your observations).
    12. Thank people.... and give feedback later.
    13. After any fact finding activity -- write up your notes as soon as possible.
    14. 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.

    15. Keep an eye/ear out for SPORTs!

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

    Note taking

    1. Always take notes! (1) it keeps you awake. (2) it makes you look interested. (3) the notes will help you recall what was said.

    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! Find the "Stakeholder map" as an example. When doing your project come back to this site to get ways to express your thoughts.

    6. 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, ...

    7. 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.
    8. However, use PC and laptops to summarize your data after the interview.
    9. 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.

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

    11. 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 [Simonsen07] ) to separate the problem from your solution. For example:
      Table
      Problem or NeedCauseConsequenceSolution
      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.

      (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. 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.
  4. 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.
  5. 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).
  6. What is feedback?(essay)
  7. Draw a diagram of a heating system with a heater, house, thermometer, and thermostat.
  8. Draw a diagram of a heating/AirConditioning system with a heater, chiller, house, human, thermometer, thermostat, set temperature, and switch(heat | chill | off).
  9. Name some informal note taking techniques.
  10. What does SDLC stand for in this course? What are the parts of the SDLC?
  11. Name the disciplines that are needed in parallel with the phases in the SDLC.
  12. Name 4 kinds of maintenance. How is the effort distributed over the operation of a system for each of these?
  13. What is an iteration in an Agile life cycle?
  14. What is most important: the technology of your solution or your understanding of the situation?
  15. How important are people in a system?
  16. What are SPORTs? and why do you look for them?
  17. What is a stakeholder? List three types of stakeholder.
  18. What is a backup and why is it created?
  19. 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>>

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

    Bug tracking in an open source project

    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

    [ Configuration_management ] (Wikipedia)

    Revision Control System

    [ Revision_Control_System ] (Wikipedia)

    Question: Define delta, commit, fork, merge, RCS, CVS, SCCS, ...

    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 ] A slightly more formal kind of mindmap is used by Adrew Binstock of Dr. Dobb's Journal [ ? ]

    A Concept Maps is a more organized than a Buzan MindMap but is similar. See [ http://cmap.ihmc.us/ ] ( CmapTools - 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>>

Abbreviations

  • TBA::="To Be Announced".
  • TBD::="To Be Done".

    Links

    Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]

    Projects [ project0.html ] [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]

    Field Trips [ F1.html ] [ F2.html ] [ F3.html ]

    Metadata [ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]

    ( End of document ) <<Contents | Top