Choosing Projects

Introduction

The Systems Development Life Cycle is expressed as:

SDLC::= Analysis; Design; Implement; Operate; Obsolescence.
Design starts when we choose the changes that need to be done. In class and in an ideal world we complete analyzing the situation before we start to choose the projects. In practice, we usually discover the need for more information (Analysis) about the enterprise and its systems as we choose our project.
1. Analysis: Systems and Fact Finding [ a1.html ] , Organizational Context of Systems Work [ a2.html ] , Systems Architecture [ a3.html ] , Modeling Data [ a4.html ] , System Modeling using Text [ a5.html ]
2. Design: Choosing Projects [ c1.html ] , Strategic Thinking [ c2.html ] , Project Planning and Management [ c3.html ]
3. Data...
4. Requirements...
Envisioning a Project
1. vision::="a statement of what the enterprise will achieve if a project is carried out".
  For example
  From Chieh-Chou Chou's project presentation in 2004.
. . . . . . . . . ( end of section Envisioning a Project) <<Contents | End>>
Selecting a Project
1. TEC::CoRT=following,
  1. Pick a specific Target.
  2. Expand about this target -- say everything you can.
  3. Contract to a selection, summary, solution, conclusion, action, or ....
  (After the Cognitive Research Trust "THINKING -- ACTION" booklet, UK, 1975?)
  
  Pattern -- PMIU
  Here is another useful pattern. When evauating an idea start by looking for the positive points and end by looking for things you don't know.
2. Evaluating_an_idea::=following
  1. + Good points
  2. - Bad Points
  3. ! Interesting points.
  4. ? Unknowns
  Principle -- Avoid Problems
  The best way to solve a problem is to avoid having it in the first place. Be aware that an important job when analyzing and designing systems is to avoid problems rather than to create and then solve them. Choosing your battles is a significant part of successful systems work.
  
  Principle -- First Define the Problem
  In many cases, the correct description of the problem contains the solution to the problem In other cases explaining what the problem is -- verbally -- or better on paper -- helps you create or discover the solution. For example see [ rubber-duck-problem-solving.html ] Also see Problem_solving and Polya below.
  
  Technique -- Personal Problem Solving
  Sometimes our task is to solve a problem that exists in the current system. Problem solving is a skill that you can learn. It pays to practice it. I've put a set of online resources that you can refer to later at the end of this section.
  Here is a procedure I've used for many decades
3. Problem_solving::=following
  1. Clarify what you really want -- the goal or purpose.
  2. Review the given data and unknowns.
  3. Get data to reduce the unknowns.
  4. Generate at least three solutions
    1. Do nothing
    2. The obvious solution
    3. If X was the solution then ...
    4. Shift your goal a little...
    5. Factorize the problem into subproblems, solve them ( Problem_solving (recursive)), and assemble combinations.
    6. Use a random thought to stimulate an idea. Example open a dictionary at random and pick a random word, now try to find a connection between the word and the problem.
    7. Re-express the problem in a different media or mode. Typically this means drawing a different kind of diagram, but writing a poem on the topic can also generate insight and so solutions. Check out Visual Thinking [ http://www.wired.com/magazine/2010/09/st_thompson_visual/ ] [ http://www.thebackofthenapkin.com/ ] (advert).
    8. ...
    9. Improve any of the solutions that you've got
  5. Evaluate the solutions. Since each solution should be evaluated on several criteria it is beset to draw up a table. I use rows for the criteria and columns for the solution. For example with personal projects I use:
    Table
    Criteria Solution1 Solution2 Solution3 ...
    Feelings ? ? ?
    Ease ? ? ?
    Cost ? ? ?
    fit with Goals ? ? ?
    Best case ? ? ?
    Worst case ? ? ?
    How handle worst ? ? ?
    ...
    
    (Close Table)
    In an enterprise use a table something like this:
    Table
    Criteria Solution1 Solution2 Solution3
    Benefit ? ? ?
    Cost ? ? ?
    Risk1 ? ? ?
    ...
    
    (Close Table)
  6. Choose a solution. Why that solution?
  7. Make a plan of action including: NOW! Development, and Support...
  Pattern -- All problems have three solutions
  A colleague of mine with a lot of experience said that every problem in an organization needed three solutions. Here I've translated them into a medical analogy:
  1. Emergency first aid -- a fast patch to stop the bleeding and keep the system breathing... Also called the band-aid solution.
  2. Curing the underlying disease or repairing the damaged body.
  3. Installing healthy habits to stop the disease re-occurring.
  Example of three solutions
  If the problem was a buffer overflow letting people take over the server.... then the band aid is to shutdown and clean the system. The cure is to find the buffer overrun in the code and fix it. The healthy habit is to give up 'fgets' and C.
  
  Pattern -- Mathematical Problem Solving
  Finding a Feasible set of changes
  1. Requests for changes(RFCs). Does your enterprise have a form for systems requests? Should it? Does a committee prioritize them? Map out the request handling system as a DFD!
  2. Look at the Strategic plan -- if it exists.
  3. Who is responsible for deciding on projects. Some enterprises have a special Steering Committee for IT projects.
  4. List the stakeholders:
    - People who have something to lose if the project or system fails.
    - stake_holders::="people who have a stake in the success of the system".
    - stake_holder::="person who has a stake in the success of the system".
  5. Look at Possible Futures: Best, most likely, and worst. What can you do about the worst case scenarios?
  6. Look for the forces and barriers in the situation.
  7. The 4 Reasons for change: PORT
    1. Problems -- where does it hurt? (just like medical diagnosis)
    2. Opportunities
    3. Risks -- from inside and boundaries.
    4. Threats -- From outside
  8. Some Reasons for Systems Requests
    1. to improve service
    2. to support new products/services
    3. to deliver new or better information
    4. to strengthen control and security of data
    5. to reduce cost
    6. etc.
  9. Costs and Benefits: Before a project can proceed you will need to convince people that it is worth doing. This often means you need to prove that it will either save money or generate more money. Note that most businesses aim to optimize profit: (minimize costs and maximize income). However some enterprises (CSUSB and non-profits for instant) treat money as a constraint and have some other objective. You need to know what the organization's vision, mission, goals, etc. are before proposing a problem to tackle. We will return to formal Cost-Benefit-Analysis later in this course.
  10. Half-a-dozen factors that effect projects
    1. Internal
      1. Existing systems
      2. Strategic planning
      3. Top management (stake_holder)
      4. users (stake_holder)
      5. People in the IT Department (stake_holder)
    2. External
      1. Technology (Opportunity / Threat)
      2. Suppliers (stake_holder?)
      3. Customers (stake_holder?)
      4. Competitors (Threat / opportunity)
      5. The Economy (Threat / opportunity)
      6. Governments (Threat / opportunity)
  Process -- Field of Dreams -- Technology adoption
  This pattern is named for a movie where the central character is told that "If he builds it, they will come". This is a plan that is most often used with commercial and mass marketed software. You develop the new system so that you think it has clear advantages over the old (rival) system and then encourage people to use the new one in place of the old. Given that the new system is attractive enough to make people change then the numbers of people switching over follows a bell shaped curve with small numbers of people at each end:
  1. innovators
  2. early adopters
  3. early majority
  4. late majority
  5. laggards
  Conclusion: if you build it some people come to it slowly...
  Moving from the "early adopters" to the "early majority" is difficult -- it is known as bridging the chasm. If your solution doesn't cross the chasm then it does not enter the mainstream and will vanish from sight.
  
  Pattern -- The Inventor's Dilemma
  Clayton M Christensen wrote a very good book ( "The Innovator's Dilemma: When new Technologies cause Great Firms to Fail", Harvard Business School Press Boston MA 1997 ISBN 0-87584-585-1 CR9802-0061 ). He documented the way that a new technology enters a market and then comes to dominate it. Paradoxically, initially the old system is more effective than the new one. Only evolution through usage makes the new system better. Thus new technology is rarely introduced by companies that already have a dominant product. The technology comes from a start-up with nothing to loose. Some large companies handle this by creating separate parts charged with coming up with a new product which must then compete with the old internally. Examples are the Java language developed inside Sun and The PC developed inside IBM. You may find this branch of the organization called the "Skunk Works".
  Notice that this also means that technological innovations tend to start with a backward step. It takes several iterations to get a better system that people are happy to adopt. For this reason you would be wise to always develop projects as a series of iterations with time to test ideas with the stakeholders well before the deadline.
  
  Phase vs Iteration
  
  (phase): a section of time when a particular part of a method is followed.
  (iteration): a cycle through a series of steps that moves something closer to its ideal state.
  Principle -- Network Effects
  You will often find that a piece of software's value depends on how many people are using it -- the more the better. This effect was first noted by economists with respect to telephones: the value of owning a telephone depends, critically, on there being people you can talk to using the phone. Hence the name: Network Effect or Network Externality.
  In software, for example, it pays to have a the same word processor as everybody else. The value of your word processor is higher if lots of other people also use it. So, as a rule, a better connected product does better. An example is Apple's Newton that did not interface with their Macintosh series -- and failed. On the other hand, Palm Pilots have always have HotSynched with PC's -- and are still with us. And of course now Apple has the iPhone, iPods, and iTunes that connect with PCs and Mac's.
  A wise designer will design a new system to communicate well with the old systems so that people using the new system are not isolated. This might be called
4. Forsters_law::="Only Connect", from a famous novel.
  Exception: in the presence of malicious and infective software it can pay to be different. Diversity slows the spread of viruses.
  Principle -- There are many ways to skin a cat
  Never forget that software doesn't have to be developed internally. You can
  - Get it free from Open Source projects. But it may be without support and documentation. [ open_source_ado.html ]
  - You can buy it.
  - You can buy it and customize it.
  - You can reuse existing software with new software wrapped around it.
  - You can outsource development: next door vs off shore. NearSource vs FarSource.
  Document -- Statement of Work
  1. statement_of_work::document=following
    1. It defines: name, manager, client/customer, sponsor.
    2. It gives dates.
    3. Staffing: How many people doing what.
    4. Vision, goal, objectives, phases or iterations.
  . . . . . . . . . ( end of section Document -- Statement of Work) <<Contents | End>>
  Document -- Project scope
  1. project_scope::=following
    1. Who? What? When?
    2. General information.
    3. Problem or Opportunity.
    4. Objectives.
    5. Description.
    6. Benefits to business.
    7. Deliverables.
    8. How Long will it take?
  . . . . . . . . . ( end of section Document -- Project scope) <<Contents | End>>
  
  Technique -- Assessing Feasibility
  1. Is this project worth doing -- This is Feasibility.
  2. Classify constraints: external vs internal, mandatory vs desirable, present vs future.
  3. Learn the kinds of feasibility
    1. Operational -- Can it work?
    2. Technical -- Can we make it? The key part of technical feasibility is whether we have (or can get) the necessary data that the project will use.
    3. Economic -- Will benefits outweigh costs? If so when does this happen? What is the Return On Investment?
    4. Schedule -- Can we do it in time?
    5. Legal (AMOW)
    6. Political (AMOW) -- who inside the enterprise will oppose this?
    7. Ethical (AMOW)
    All of these can make a project fail. The most important one varies from project to project: the critical one is the one that will kill the project.
    
    (AMOW): I added three kinds of feasibility (Legal, Political, and Ethical) that are not found in most texts. They are based on my experience of projects.
  Pattern -- Trade off
  Commonly you will find several solutions. But a solution that is good for one criteria is bad for another and vice versa. For example one solution is cheap to develop but inefficient to operate, whereas another solution will be expensive to develop but cheaper to operate. We talk about this as a Trade-off. In computing for example we can nearly always speed up a program by giving it more space to run in. This called a space-time trade-off. In these cases you can often developed a mixed strategy which combines the alternatives. Another strategy is to think about the relative importance of the two opposed benefits and set priorities.
  
  Pattern -- The Bathtub Law of Costs and Reliability
  Costs of a system tend to start high and then slowly decline, and then stay low for a long time, until the system starts to need extra maintenance and ultimately replacement. We call such a pattern a Bathtub curve. Bathtub curves were first observed for failure rates.... but the same curve fits the costs of a system.
  
  Questions
  Architectural Choices
  1. TCO::=Total Cost of Ownership.
  2. Initial cost is a lot less than the TCO!
  3. Check the following things about your architecture:
    1. OPTIONS: choose the best of three architectures. Or present three to the stakeholders with a range of costs and let them pick the best one.
    2. Scalability -- choose an architecture that will work with more data and usage than you need. Choose one that can expand as the need grows.
    3. Performance -- details below.
    4. Training,
    5. Reliability -- Mean time to failure, ...
    6. Life time,
    7. Fit with Legacy Systems,
    8. Security,
    9. Maintenance,
    10. Security,
    11. System Management and Support
    12. Help Desk
    13. Maintenance and Faults,
    14. Backups,
    15. Disaster recovery.
    16. Obselescence -- cost of recylcing and cleaning up.
      1. Amip Shah & Tom Christian & Chandrakant Patel & Cullen Bash & Ratnesh Sharma
      2. Assessing ICT's Environmental impact
      3. IEEE Computer Magazine V42n7(Jul 2009)pp91-93
      4. Evaluate the impact of your system over the complete life cycle from manufacture to recycling or the dump.
    17. Security.
  4. Classic Processing options: Online (OLTP) vs Batch, mixed .
  5. OLTP::="Online Transaction Processing".
  6. Classic mix: Provide a mostly automatic system for every day work that gathers performance data for executives and managers to analyze -- OLAP, data ware house, data mining.
  7. OLAP::="Online Analytical Processing".
  8. Classic architectures: client-server architectures -- Notice that a mobile platform provides a thin client free but you can download an app that makes it a fat client.
  9. Systems Design Completion: Report, sign off, presentation.
    
    Performance
    . . . . . . . . . ( end of section Performance depends on load) <<Contents | End>>
    Designing for Performance
    . . . . . . . . . ( end of section Designing for Performance) <<Contents | End>>
  . . . . . . . . . ( end of section Performance) <<Contents | End>>
  How far in advance should you plan
  Your design should be a good design for the whole life time of the system. This is an arbitrary time and if the system works well the life time will be longer than you would ever believe possible. But in planning: look at how long it is before a system will be replaced. For planning activities within a project follow these guidelines
  1. Precise estimates and plans are only good for a short time. You can plan a day of work precisely but you will be wrong about six-months.
  2. Divide a long time period into milestones. Divide these into "inch" "pebble" pieces. Revise the total plan as you go.
  We will cover the classic techniques for detailed planning later.
  What is the most important non-functional requirement when making architectural choices
  I call this the most critical quality of the system. Sadly, it varies from project to project. The prime skill you need to learn is to spot the most critical quality -- the one property that is most likely to make the stakeholders reject your system.
  For example, if you are producing a piece of software for the mass market the most critical quality is time to market and just about all the others (reliability, usability, completeness, ...) have been sacrificed to beat a rival company to the market. For NASA however reliability tops the list... but they also have hard deadlines (launch windows). For many businesses the most critical non-functional requirement is maintainability: being able to cheaply make changes in running software.
. . . . . . . . . ( end of section Architectural Choices) <<Contents | End>>

Criteria	Solution1	Solution2	Solution3	...
Feelings	?	?	?
Ease	?	?	?
Cost	?	?	?
fit with Goals	?	?	?
Best case	?	?	?
Worst case	?	?	?
How handle worst	?	?	?
...

Criteria	Solution1	Solution2	Solution3
Benefit	?	?	?
Cost	?	?	?
Risk1	?	?	?
...

. . . . . . . . . ( end of section Selecting a Project) <<Contents | End>>

Document -- Systems Design Specification -- SDS

Specification::report=following,
1. Executive Summary: Name, who, what, why, how...
2. System Components: Interfaces, Networks, Data, Flows, etc etc
3. System Environment: Constraints on system including operations, hardware, software, security, ... Response times, deadlines, processing schedules,...
4. Implementation Plans: start up, initial data, user training, test plans
5. Time and Cost Estimates
6. Optional(Appendices)
Note: your final project report will be a Systems Design Specification. You will develop it during this course. You will be given extra time to perfect it before your final presentation in the 20th class meeting.

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

Review Questions
1. Are problems solved for ever?
2. Describe two useful frameworks for thinking.
3. Take any topic -- a boring one is best -- and practice TEC.
4. What is a stakeholder?
5. List for 4 reasons for change.
6. List 5 reasons people request changes in an existing system.
7. What is a statement of work?
8. What is a project scope?
9. List some factors that effect projects.
10. Name 6 kinds of feasibility.
11. How does the cost and/or reliability change through the life time of a system.
12. What information should you prepare to sell a project to management in a typical for-profit enterprise.
13. 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? For each one describe how it plays a part in systems analysis and systems design.
Are there any limits on project topics
Your project should be clean and legal! We will check out feasibility as part of this course.
Online Resources
. . . . . . . . . ( end of section Online Resources) <<Contents | End>>

. . . . . . . . . ( end of section Choosing Projects) <<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/ ]