When you are thinking about a project you need to think about (1) which project, (2) which architecture, and (3) how to implement it. Bad choices in these areas can be embarrassing or lead to disasters.

On this page there are two topics: Pick a strategy that will pay off, and carefully choose an implementation strategy that is likely to work.

Development Strategies

Theory

What we need is a way of getting from an idea of what might be done to a detailed description of what hardware and software we will need. This includes deciding what software we we will create and what we will buy. A part of this process is resolving competing projects, balancing the costs and benefit, and selecting a way forward.

In most case we can not make a good choice of the best projects, or the best way to do a project without breaking it down into components and estimating the costs and benefits of different ways of developing or obtaining the components. This leads to cost-benefit analysis. Choosing the best development strategy and system architecture is often the key to a successful project. There many ways to implement one logical solution to a problem.

Example -- My Grading System

Here is one logical systems architecture and many implementations.

Vision

Students can submit work and have it graded by the teacher. The teacher can correct erors.

Logical Design





Physical Designs

Here is a table showing how different parts of the above Logical Design have been implemented at various times. It is not a complete list of the many attempts I've tried over the years... but it illustrates how a physical architectures can implement a given logical system. I've also omitted the various media and forms that "Syllabus etc" have taken through the years.
Table

Grades	Work	Grade Work	Submit Work	Return Work	Read Grades	Fix Errors
Paper	Paper	Pen, Paper	Manual	Manual	Ask the teacher	Manual
Paper	Paper	Pen, Paper,Calculator	Manual	Manual	Ask the teacher	Manual
Paper	Paper	Pen, Paper+Pascal Program	Manual	Manual	Ask the teacher	Manual
Hypercard Stack	Paper	Pen, Paper & Mac	Manual	Manual	Ask the teacher	Manual
UNIX Files	Paper	Pen, Paper & awk	Manual	Manual	Ask the teacher	Manual
Spread Sheet	Paper	Pen, Paper & PC	Manual	Manual	Ask the teacher	Manual
Spread Sheet	Email	UNIX, vi & PC	mail	mail	Ask the teacher	Manual
Spread Sheet	Paper	Pen, Paper & PC	Manual	Manual	Web Pages	Manual
Spread Sheet	Paper	Pen, Paper in class	Manual	Manual	Web+PHP	EMail


(Close Table)


. . . . . . . . . ( end of section Example -- My Grading System) <<Contents | End>>

No Programming is good programming

Notice: In this class we don't want or need to work out how to code a program -- it is better to find a way of not coding it at all!

Classic Processes

There are a lot of competing methods for changing systems and one size does not fit all situations. As a result I will not be following the traditional list of phases and deliverables in these notes. For example it is traditional to show you a diagram that shows six phases:

1. Analysis. Current Physical System->Current Logical system. (extract what is going on from it's current implementation).
2. Transition: Current Logical-> New Logical. Feasibility (solve problems, think up changes, check it will work)
3. Design. New Logical-> New Physical, Requirements (plan ways to implement the changes).
4. Implement.
5. Test.
6. Operate and Maintain.



Some methods completely omit the Analysis above -- they go directly to an essential model (logical model) of what needs to change.

Some methods focus on one small fix at a time.... This is called evolutionary development or incremental development. When done well it handles changing or risky situations well (but not efficiently). However be aware that these are what cyberneticians call "Hill Climbing" algorithms. These tend to get stuck on top of "Hills" -- local optima -- where any small change makes the system worse. Under these circumstances the only thing to do is launch a big project to find a new part of the "systems landscape".

A compromise method focusses on just the parts of the system that need fixing before doing any modeling.

• Analysis. Diagnosis. Current Physical of bad part->current Logical. Changes. Feasibility. Select a project. Project Scope.
• Transition. Design: current Logical-> new Logical. Propose strategies. Cost/Benefit Analysis.
• Design. Select strategy. Select system architecture. new Logical-> new Physical; Requirements.

Selecting Strategies, system architectures and Initiating Projects

Background

1. Introduction: There are many different architectures we can use these days: main frame + terminal, user+work station, web-based, LAN linked databases, client-server, client+web+database, batch update+on-line retrieval, purchase package, customize a "Enterprise Resource Program" -- (ERP)
2. There Ain't No Such Thing As A Free Lunch!
3. Tradeoffs: most sytems involve a tradoff between competing needs. It is worth looking for a mix of competing resources that is better than either extreme.
4. The Internet has changed (1) communications, (2) services, and (3) architectral options, and even (4) platforms. These days every system seems to use the Internet. As a result just about every piece of software is made of components coded in different languages. We even have languages purely for communicating between components over the web.
5. There are many ways to get software:
   
   1. Program it in house
   2. Buy it -- a component or a complete system.
   3. Buy it -- and customize. Needs a FitGap process. This looks for where the component fits and where there is a gap with the enterprise needs.
   4. Customizing a general package like ERP. Needs a FitGap process.
   5. Look for Free or Open source versions -- may involve unexpected maintenance costs plus specialized skills.
   6. Use old programs, perhaps with wrappers?
   7. Translate old code into new system.
   8. Reverse engineer existing component.
   9. Let the user develop their own scripts -- Applescript, Hypercard, Koala [Lau07] , XCode, , etc.
   10. Out source -- asking another enterprise to do the programming:
       • Risky unless you have solid and well defined requirements.
       • Benefit: no need to hire/exploit local skill.
       • Has been around since the 1970's - Electronic Data Services (EDS).
       • Includes using the company down the road or in another country.
       • The out-sourcers need to show a track-record of success in similar projects.
       • Communication between your enterprise and the programmers is not free. Include it as a cost.
   
   

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

Selecting Strategies and Architectures

Most requests for change are internal. Even if the ultimate source of a suggestion is from a customer.... there will be an internal person or system to handle it.

Which Systems Requests become Changes

You have to know how your enterprise handles requests. You should be able to draw a rough diagram of the procedures: Who selects them in your enterprise? Do they arise Top-down or Bottom-up?

In medium to large sized enterprises there will be a committee called a Steering Group who are tasked to select the projects that have time and money invested in them. They typically start with a list of Systems Requests from stakeholders. They have to resolve the political forces to classify projects (typically) in these categories list below:

1. decision::=accept | delay | reject | refocus | purchase | enduser | out-source | open-source | modify_and_resubmit.

   The decision is based on ranking projects in terms of feasibility, efficiency, stability, security, needs, Cost/Benefit analysis(next), etc..

   New Feature or Bug

   Some development tools insist that you classify change requests into either "Feature Requests" or "Bugs". You can argue that to a user, a missing feature is a bug. So I don't think you should waste much time on whether the request is a new feature or a bug. Instead get the users to prioritize the requests and spend time estimating how much work is needed to carry out the change. Then negotiate with the user about which changes will be done next.

   How do you overcome user resistance to change

   The classic strategies include:
   
   1. Involve the users in the analysis and design. Get user representatives on your team, or (weaker) use forums and meetings. Note that the representatives should become the evangelists you need to sell a new system to other users.
   2. Design the new system to be better to use than the old ones. Here "better" means more rewarding to the users. It should let them do more with less effort. It should make them feel in charge, skillful, and competent.
   3. Make people feel at home. Fake bits of the old system as parts of the new.
   4. Make sure that management is visibly on the side of the new system.
   5. Meetings to sell users on the new system.
   6. Train the existing leaders (formal or informal) first. Send them out as evangelists.
   7. Provide training to cover the rough spots. Don't forget to apologise and explain the pain.
   8. Anonymous(?) help line.
   
   Selling a bad system is bad place to be.

   Is there a best way to establish relationships with clients and stakeholders

   You can't beat face-to-face situations ... within that there are lots of varieties. Notice I said "situations" not "meetings". The occasional informal get together (Party!) can be a big help. So can inviting a stakeholder to "live" with the development or systems team. As an alternative the team can go and work with the stakeholders as part of the development process. A good developer/systems/IT person has to become an amateur psychologist and sociologist.

   How much say do stakeholders have in system modifications and requests

   It depends on the enterprise, but the more they are involved the better. However, there is a risk with large projects of the stakeholders producing too many changes -- and so some form of filter is a wise idea. Hence the idea of a stakeholder Steering Group to assess the costs and benefits of requests and then prioritizing them.

   Pattern -- Divide and Conquer

   A common technique is to Divide and conquer -- you split the problem/system into separate components and find a solution/component for each. You have to define the interfaces between the components precisely or work out how to make mismatching components fit, of course. But once divided each component can be obtained/created by a different technique.

   In a Service Oriented system the assembling of parts is done on the fly, as the software runs. Different components can advertise their services on the Internet. At any time a different set of components cooperate as parts of the current system. But this is a new technology.

   Pattern -- Target risks early

   Choose strategies that resolve unknowns, test new technology, test user interfaces early ----- and often!

Financial and Cost-Benefit Analysis

Knowing about financial analysis is important in practice, but we don't have enough time to do many exercises and/or quizzes on these techniques this quarter. But, I'll ask you to do them in your team project -- you'll have to fake the figures but doing these calculations should give you a feel for the process.

The first step is to have a pretty firm schedule for each strategy you are comparing.

1. Cost_benefit_analysis::= Benefits and costs; Break_even; Return_on_investment; present_value_of_money, (Note this shows a sequence of 4 steps).

2. Benefit::=something good that will happen at some time as a result of the project, needs to be expressed in terms of money.

   Benefits typically follow a "Sigmoid" curve

   

3. Cost::=something bad that will happen at some time as a result of the project, needs to be expressed in terms of money.

   Typically costs follow a Bathtub curve

   

4. Cash_Flow::=Benefit-Cost.
5. tangible::=a benefit or cost that you can touch -- with an abvious value to the enterprise. Examples: money paid by costumer, money spent on software, ...
6. intangible::=a benefit or cost that is hard to quantify. Examples: the results of advertizing, the losses caused by a bad bug in software.

   Tangible costs and benefits have an obvious monetary value. A classic example would be computer equipment. An intangible costs and benefits tend to be hard to quantify. The classic intangible benefit is "goodwill". You can't touch it but the fact the customers have had good experiences with a company in the past has a value to the enterprise.

   You start cost/benefit analysis by documenting all the benefits and costs for a project. If there are different projects you do a different list for each and compare the values at the end. Given a list of benefits and costs then there are two or three traditional ways of evaluating a project. Most of these can be calculated using simple spreadsheets. I'll show them (mostly) as tables in this document.

   Here is an example of a small company that might invest in replacing their van by a new one:

   • Benefit or cost: Cost of a new van.
     
     1. Tangible or intangible?: tangible.
     2. Once or recurring? : Once.
     3. How much? : $20,000
     4. When does it happen? : Start of Project
     
     
   • Benefit or cost: Benefit of possible customers seeing smart van.
     
     1. Tangible or intangible?: intangible.
     2. Once or recurring? : Each time someone sees the van.
     3. How much? : $20 (??)
     4. When does it happen? : Each Week (??). Estimate $1,000 per year.
     
     
   • Benefit or cost: Benefit of reduced running costs.
     
     1. Tangible or intangible?: tangible.
     2. Once or recurring? : Recurring -- each year.
     3. How much? : $200 (get rid of that oil leak for a start, old engine,...)
     4. When does it happen? : Each month
     
     
   • Benefit or cost: Sell van
     
     1. Tangible or intangible?: tangible.
     2. Once or recurring? : Once
     3. How much? : $10000
     4. When does it happen? : Year 5
     
     

   We summarize this data in a table like this:
   Table

   Time	Cost	Cumulative Cost	Benefit	Cumulative Benefit
   Year 0	20000	20000	1200	1200
   Year 1	0	20000	1200	2400
   Year 2	0	20000	1200	3600
   Year 3	0	20000	1200	4800
   Year 5	0	20000	11200	16000
   Total	20000	-	16000	-

   
   (Close Table)
   

   If a project is worth tackling then there should come a time when the cumulative benefits outweigh the cumulative costs. This is called the Break Even point.

   

   It is simple to calculate the break-even point and return-on-investment from a table like the one above. We can see that in this project there is no time in the 5 year plan when the benefits pay back the cost. Perhaps the project should run longer, or a cheaper way to pay for the van should be found.

   The return-on-investment is calculated as

7. ROI::= (total_benefits-total_costs)/total_costs.

   And in this example project the ROI is negative -- -20%.

   A more sophisticated calculation is to find the cash-flow for each period. Where

8. cash_flow = benefit-cost.

   
   Table

   Time	Cost	Benefit	Cash-flow
   Year 0	20000	1200	-18800
   Year 1	0	1200	1200
   Year 2	0	1200	1200
   Year 3	0	1200	1200
   Year 5	0	11200	11200

   
   (Close Table)
   

   The above tables do not allow for the fact that money that arrives (or departs) in the future is not as valuable as today's money. Here is the key concept: the Present Value of Future Money. This is the money now you would give up now to get the given money in the future.

   In the above calculation benefits and costs that will occur in the future are of less value than the money flowing in the present. There is even a well known formula to convert 2 birds in the bush into a bird in the hand. Money that is in the bank accumulates interest and so gains value as time goes one. So, if the interest rate is 6% then if you invested $100 now, then it would become say $106 in a years time. So $106 in one year is actually worth $100 today! Further, money that comes in or is spent in the future should be decreased in value to allow for the risk of it not happening. This is calculated using a current interest rate. It thus balances the value of a dollar in the bank today vs two dollars in the future. You can also discount risks by increasing the interest rate above the bank rate...

   Example -- with a discount rate of 6% per year then $1 is worth different amounts if it arrives or leaves in the future:
   Table

   Years	PV (rounded to nearest cent)
   0	100 cents
   1	94 cents
   2	89 cents
   3	84 cents
   4	79 cents
   5	75 cents
   6	70 cents
   7	66 cents
   8	63 cents

   
   (Close Table)
   

   There is a formula that (called the present value (PV)) discounts the amount depending on how far in the future(t) the cash flow(c) is for a given rate (r) --

9. For Money c, Time t, Rate r, PV(c,t,r)::= c/(1+r)**t.

   (No need to memorize this.... you'll find it in most spreadsheets).

   For example, in the above example and assuming an interest rate of 6% per year, the cost benefit analysis would be:
   Table

   Time	Cost	Benefit	Cash-flow	Discount	Present Value(PV)
   Year 0	20000	1200	-18800	1	-18800
   Year 1	0	1200	1200	1.06	1132
   Year 2	0	1200	1200	1.12	1068
   Year 3	0	1200	1200	1.19	1008
   Year 5	0	11200	11200	1.26	8871
   NPV	-	-	-	-	-6721

   
   (Close Table)
   

10. NPV::= "Net Present Value", the sum of the present values of all the cashflows.
11. NPV(cashflows, rate)::= Σ [t:Time] ( PV(cashflows[t], t, rate )).

    Conclusion: Definitely rethink this project... for example, lease a van rather than buy it, perhaps. Or, perhaps keep the van longer ( but the resell benefit will decrease..).

    Here is a summary of the procedure for cost-benefit discounted cash-flow calcultaions.

12. Calculating present value of a project::=following
    
    1. Draw up a table (spreadsheet) showing when each benefit/cost happens.
    2. Subtract each Cost from Benefit -- the net cash flow.
    3. Convert cash flows to present day cash -- the Present Value or PV.
    4. Add the present values up -- the Net Present Value -- NPV
    5. Break-even analysis (Pay-back time). When does the present value of the project become positive?
    6. Return on investment (ROI).
    
    Most spreadsheets have a PV(...) function to convert future money into its Present value. Even my Tungsten E2 Palm Pilot can do this. However each one seems to be a different formula and some are about anuities not costs and benefits. As a result -- it may be best to ad an extra collumn that accumulates the discounts for each period. Here is axmple of the formulae:
    Table

    Time	Cost	Benefit	Cash-flow	Discount	PV
    0	c0	b0	c0-b0	1	c0-b0
    ...
    t	c	b	b-c	d	(b-c)/d
    t+1	c'	b'	b'-c'	d'=d*(1+r/100)	(b'-c')/d'
    ...
    NPV	-	-	-	-	SUM(column above)

    
    (Close Table)
    (r= interest rate in percentage per time period).

    The above calculations should be done for every alternative. In theory the one with the best cost/benefit is chosen. If not then at least you know what the more expensive choice may have cost the enterprise.

    You can also use the above table to calculate a Discounted ROI and discounted Break-Even figures that will be more pessimistic than the original.

    Summary -- Procedure -- Cost-Benefit Analysis

    
    
    1. Make a list of all costs and benefits from the start of the project to it's end of life.
    2. Classify each as tangible or intangible.
    3. Classify each as one-off or recurring. Note when each occurs.
    4. Use a spread sheet to tabulate all costs/benefits and when they occur.
    5. Use the spreadsheet to calculate cumulative costs and benefits and the break-even point and simple ROI.
    6. For each time period add up benefits and subtract costs to get the "cash flow" for that time.
    7. Convert each cash-flow into "Present Value" or PV.
    8. Calculate the Net Present Value NPV at each period.
    9. Find the break even point when the project moves (we hope) from NPV negative to NPV positive.
    10. Calculate the final Discounted Return On Investment (ROI) = Final NPV/Money invested.
    
    

    What do we do if we find that the benefits of a finished system is less than the costs even tho' the cost benefit analysis was positive.

    First: Cost-Benefit analysis would tell you how long you have to wait before the initial investment is paid off. Typically all software projects start off costing more than they earn. The benefits come in as the new system runs for several years. Second: If the actual costs and benefits don't match your expectations you should change the way you do the analysis the next time. Third: If it is clearly a big mistake, perhaps it is time to move on to a new job?

The Business Case

All the above work -- from learning about the current system/situation... through to a feasible proposal (often called a Feasibility Study ) culminates in a report presented to management. Here is a typical outline:

Document -- Preliminary Report

1. Name of project.
2. Introduction: Who did what and why that lead to this report.
3. Executive Summary -- the guts of the proposal in half a page.
4. Findings -- What came out of your analysis of the situation. Indicate alternatives.
5. Recommended Strategy -- what should be done
6. Project Roles -- Who will be needed to do what. Training? Consultants?
7. Time and Cost Estimates
8. Expected Benefits
9. Financial Cost/Benefit Analysis (see above)
10. Appendix (for any supporting evidence you may need).
It helps if the above document has a pictures -- for example a context DFD plus some lower level ones.

Notice the preliminary report develops easily from a less complex "Project Scope" document -- if you did one.

Initiating Projects

"Beginnings are delicate times...." Frank Herbert, Dune.

Once your Business Case has been accepted and the project approved you will have a lot of things to do to "kick off" the project. Here is a quick check list:

• Look for vagueness, novelty and, other risks in the business case.
• Form a team -- who, where, when,...
• Any training needed? Any recruiting?
• Either call the first meeting or invite a person the team to set up the first meeting.
• Setup a continuing relationship with clients and stakeholders
• Think about the schedule of meetings (yearly, monthly, weekly, daily). The more often they are, the simpler and more informal they should be. Perhaps a daily "stand-up" meeting + monthly joint application development meetings?
• What kind of meetings?
• Create a first (and probably inaccurate) plan (see [ c3.html ] later).
• Install management procedures. How do you find out if something is failing?
• Set up the necessary physical space if "co-located" else if not co-located set up an excellent communications infrastructure.
• Set up a project workbook or (perhaps) a project work space on a web server. (perhaps use a Wiki?)(perhaps use GoogleDocs).
• Setup backup systems for project documents... disaster preparedness.
• Set up tools and environments.
• Review everything with team, managers, stakeholders...

Early Design Models

Keep these as simple as you can -- do not commit to details (especially technology/physical decisions) unless you absolutely have to. For example your project is taking the opportunity of using a new piece of hardware.

Here are some useful tools when modeling designs:

• DFDs: Context and level-0.
• Notes defining the data flows and stores.
• A first rough UML Entity-Relationship-Attribute Diagram(ERD).
• ANSI Flowcharts =~= UML activity diagrams
• Prototypes
• Data dictionary etc...

What is an Artifact

This is the current jargon for anything you produce while developing a system -- including diagrams, documents, ... and code.

Tool -- Meetings

Meetings are a critical tool for developing systems! You need an agenda saying who does what. For example see the deliverables for each class in this course. A coordinator, facilitator, or chairperson is in charge of getting things set up. Equipment can include postIt notes, Chalk boards, ...

A very useful thing to say: "What I hear is ..." and then describe objectively and fairly what you've seen happening in the meeting: "Jim say A, but Joan says B."

Stand Up Meetings

This is a technique from the "Scrum" agile development method. A standup meeting is very simple, informal and short. First: nobody sits down! Second: Management keeps quiet. Third the developers, in turn, report their progress and where they are blocked. There can be some discussion of what to do.... management listens to find ways to remove blocks.

Technique -- JAD Workshop

1. JAD::="Joint Application Development". A JAD workshop involves programmers, analysts, and stakeholders in specifying, in detail, a specification for a piece of software. As a rule you need special training to facilitate a JAD workshop.

   Technique -- Walk through

   
   (Walk-through): a group meeting that looks for errors in an artifact that is lead by one of the producers of the artifact.

   Process:
   

   1. Preparation: people taking part must know what artifacts are being looked at and must have become familiar with them.
   2. Review. All issues that are raised must be noted. None are fixed.
   3. Follow up. This is when the noted issues are worked on.
   
   

   Notes:

   • Important: does not review people. Leave "you" and names out of comments.
   • Roles: coordinator, user, standard bearer, presenter, secretary, maintenance oracle. Note: people should be held accountable if the artifact proves to have a defect in their area.
   • People must be stopped from fixing the artifact.
   • Sign off: Go, No_Go, fix and resubmit, fix and go.

   Technique -- Inspection

   
   (Inspection): a group meeting that looks for errors in an artifact that is not lead by one of the producers of the artifact. Process:
   
   1. Preparation: people taking part must know what artifacts are being looked at and must have spent time looking for issues in them.
   2. Review. All issues that are raised must be noted. None are fixed.
   3. Follow up. This is when the issues are worked on.
   
   Notes on inspections:
   • Important: does not review people.
   • A representative of the producers can be present but if present must stay silent.
   • Roles: coordinator, observer, user, standard bearer, presenter, secretary, maintenance oracle.
   • People must be stopped from fixing the artifact.
   • Sign off: Go, No_Go, fix and resubmit, fix and go.

   What is the difference between walkthroughs and inspections

   In a walkthrough, the person who made the artifact presents it to a group. In an inspection, the producer is not allowed to speak to the inspecting group.

. . . . . . . . . ( end of section Tool -- Meetings) <<Contents | End>>

. . . . . . . . . ( end of section Initiating Projects) <<Contents | End>>

What are the most important IT steps to help a company survive its critical first years.

What an excellent question -- and I wish I was competent to give a definitive answer.

(1) you need a product or service, a way to advertise it, a way to deliver it, control systems, a way to scale up, ..., In other words: you need a Business Plan.

(2) A classic rule of thumb is that you must have enough money or credit to operate for 3 years without a profit!

Many years ago I looked into starting a business developing and selling games for the new "Personal Computers" that were coming on the market. When I analyzed the business model, I realized that piracy would be a gigantic drain on the company... in fact I'd have to spend more time and effort defending my intellectual property than developing (and playing) games. So, I decided to work for the UK Civil Service instead... and wrote a few games as a hobby.

When I started up a consulting company in the 1980s the two legal requirements were a bank account and an accounting system. This is for a California Sole Proprietorship. The bank account was easy. And I figured out that the old fashioned accounting system would be good enough. I used an old paper based accounting procedure based on a couple of books: a journal of credits and debits, a paste book of receipts and invoices, and a list of assets.

Some of following will be needed for any new company.


1. Marketing and advertizing.
2. Accounting: track and monitor money and assets.
3. Inventory: raw materials on hand, stuff in production, goods to be sold.
4. Pay Roll.
5. Manage orders and invoices.
6. Security.
7. External Communications: telephone,internet address, Email, Web presence, ... Track customers, sales, ... CRM(Customer Relationship Management system)
8. Handle complaints... feedback on problems.
9. ...
10. Investors etc.

Start from the above and modify it to fit your company's business plan.

. . . . . . . . . ( end of section Development Strategies) <<Contents | End>>

Implementation

Introduction to Implementation

Implementing a computer system has a lot more things in it than just programming. Here I will touch on the some of the sub-processes that will be needed as you take an idea and make it part of the enterprise:

1. Quality Control and Testing.
2. Documentation
3. Programming
4. Training
5. Data Conversion
6. Acquiring hardware and software
7. Change over processes
8. Post-mortem



Quality is Job 1

1. SQA::= "Software Quality Assurance", testing, peer review, walkthroughs, inspections, computerized validation of artifacts, etc. All the procedures and tools used to ensure the quality of the final system.

   The commonest techniques are the Walk-through and Inspection above.

2. CMM::= "Capability Maturity Model", a model of how capable an organization is at producing something. It has 5 levels (picture below) and you can get an outside body to certify which level you are at.

   

   The key thought is: (1) figure out what you are doing. (2) Document it. (3) Enforce it. (4) Control it. (5) Improve it.

   What is the Defined level of Capability Maturity Model CMM

   Prior to the defined level things are done in a routine way but the procedures are folk law and not fully documented.

3. ISO::="International Standard Organization".
4. ISO9000::="A set of ISO standards aimed at the quality of work done by an Enterprise", key idea: you must document your procedures and provide evidence of following them.

   Testing

   
   
   1. Tests have to be planned. Start planning tests as early as you can. Specifying tests is an excellent way of defining requirements.
   2. Automate testing whenever possible. For example unit testing for Java is a lot easier (and fun) if you use the JUnit framework.
   3. Unit_test::="a test that finds out if a component is working up to its specification."
   4. TDD::="Test Driven Development", write code that does the testing before you write the components.
   5. Integration_test::="a test to see if a collection of tested components work as expected".
   6. top_down_testing::="tests the whole first with parts replaced by stubs until they are completed, and so on down".
   7. bottom_up_testing::="Starts with unit tests and moves up to larger components until the whole system is tested".
   8. regression_testing::="Repeating all previous tests each time a change is made", means you must store tests.
   9. System_testing::="Top level integration test",
   10. Acceptance::="Tests specified by a user or stake holder and carried out by them", if these fail then the system needs work. They can be derived from scenarios/stories.
   
   

   What kind of thought process goes into the initial planning of a test

   Two forms: black box and white box.

   Black box tests are derived from the specification of the system under test not the finished code. They can be worked out before the code is written. The place to look for tests are the functional requirements. So system level tests should be derived from the scenarios and use cases for the system. Each test should be a particular scenario of the use case... and every scenario needs to be tested at least once.

   White box tests are written after examining the code and aim to exercise every part of the code at least once. Here is a list of the minimum set of white-box tests:
   

   1. Produce each output at least once.
   2. Make sure each statement is executed at least once in some test.
   3. Make sure that each condition is tested for true and for false.
   4. Test boundaries: where conditions move from true to false and vice versa
   5. Test what happens if a loop body is not executed.
   6. ...
   
   

   Are there any other types of testing

   Yes.

   Performance testing. Here you input a particular load to the system under test and see how fast it handles it. For example you use a script to input 25 requests in a second to a PHP script and see how long it takes to complete them.

   Are benchmarks used at all?

   Yes. This is Performance testing.

   Who invented test driven development TDD

   I think it was Kent Beck as part of the XP package.

   How does TDD work

   Demo in class of C++ test driven development of a class.

   Basically you need to accept that you are going to have a lot of errors to fix because initially the tests won't even compile. But one test at a time you change the code until it compiles, and then change it until all the tests produce the correct result.

   How can you devise a test before you actually produce the product.

   The first step is to figure out how to automate tests. This may involve some form of scripting -- shell or other tools. Then all you have to do is write the tests as data and/or programs. I also demonstrated the 'make' tool and Makefiles -- these make it easy to automate testing on UNIX.

   How does a unit test find out if a component is working up to its specification?

   The test is a program that executes the methods of the component and looks at the results of the execution.

   In class I demonstrated using the C/C++ 'assert' function from the <cassert> library. This is an excellent tool for writing programs that do unit tests. For example [ ttest.cpp ] tests the class Counter [ counter.cpp ] to see if it works as specified.

   Notice that the tests are a very good way to document typical ways to use the component.

   In Java there is JUnit...

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

   Documentation = Producing Artifacts

5. Documentation includes user documentation and system documentation.
   
   1. Better late than never?
   2. You need to have written instructions for operating the software.
   3. Routine procedures must be written down -- and be on-line.
   4. Use "Frequently Asked Questions" as a format for documentation -- (FAQ)
   5. Program documentation is designed to support maintenance and evolution.
   6. System documentation includes all the reports prepared during analysis and design. It is the record of the analysis and answers the question "Why". It must define the functions of the system and its qualities. These are called requirements.
   7. Tests are also useful documentation.
   8. Source code is documentation and contains documentation (as comments and its identifiers).
   
   

   Programming

   [ ../cs375/ ]

   Training

   1. Training -- a vital activity in installing a system. First train an elite of respected users and then let them train the rest. Good design can reduce the need for training but the official procedures and their reasons must be explained independently. For example: we are not given access to PeopleSoft until we are trained on the security precautions we must follow.
   2. Training options: face-to-face vs online, Just-in-time vs ahead of time, on-site vs off-site, inside vs outside trainers.

      Is face to face training more effective then online training

      The effectiveness of face-to-face training depends on the trainer. But as a rule face-to-face training allows more intelligence to be used in the teaching. Online and remote training has to be very carefully planned and executed to become as effective as a good teacher. However -- it can cost more to use a live human being than a DVD.

   Data Conversion

   1. Data Conversion: the vital process of moving legacy data into new forms. It includes: collecting the data, cleaning it, and copying and/or translating it. Data conversion is a significant task that can take many weeks of work and special tools. It can, sometimes, be simplified by clever data designs. Don't forget data quality is vital: the old rule of

       		Garbage In; Garbage Out.

      is still true. So clean the data: review it, use programs to look for odd and bad data.

      How can you make sure that Data Conversion that is done over the internet is converted correctly to different computers

      The same way that you make sure that ANY data conversion is correct: look at the data, compare old and new, take random samples and check them, try reverse mapping back and then use a tool to find differences between the old and the reconverted new.

      One thing to watch out for is different character codes. In my experience the 3 or 4 different code sequences used to indicate "end of line" is the most problematic. MacOS, UNIX, and MSWindows use different conventions.

      Also watch out for the ASCII vs UNICODE vs EBCDIC(OLD) differences.

      However most systems provide tools to convert codes, or you can write one or pervert an existing tool. For example, my MS WordPerfect automatically converts UNIX text to Windows text.

   . . . . . . . . . ( end of section Data Conversion) <<Contents | End>>

   Installation plans and change over

   1. Many strategies with varying costs and risks.
      Table

      Name	Strategy	Cost	Risk
      Cut Over or Big Bang	The legacy system is shut down and the new system starts up and replaces it.	Lowest	Highest	1
      Pilot Operation	A part of the enterprise uses the new system while the rest uses the old one. Once the bugs are removed the old is replaced by the new in the whole organization.	Medium	Medium	2
      Phased Operations	Parts of the legacy system are replaced by new parts.	Medium	Medium	3
      Parallel Operation	The legacy system is left running and the new one introduced. In time the old system is shutdown.	Highest	Lowest	4

      
      (Close Table)
      
      Table

      -	Low Cost	Medium Cost	High Cost
      Low Risk	-	-	4
      Medium Risk	-	2,3	-
      High Risk	1	-	-

      
      (Close Table)
      Exercise: Think about the field trips -- can you find an example of each of these strategies?

   . . . . . . . . . ( end of section Installation plans and change over) <<Contents | End>>

   Project Evaluation and Post Mortem

6. Evaluation -- How good a system have you produced? What can you learn from this project and its product? This is a form an Inspection of the process used in the project to determine what can be learned. Also known as a Project Retrospective.

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

Online Exercises

Story -- What caused the dot.com bust

A "dot.com" is one of a large number of firms that appear in the 1990's and vanished in the 2000's that used the Internet as an enabling tool. They all had a web pressence in the ".com" (commercial) domain of the Internet. Hence the name "dot" "com". A lot of software companies suddenly failed ... but what mistakes did they make: Technical or Nontechnical? See [ 506732.506734 ]

Cost Benefit on the Wikipedia

[ Cost-benefit ] [ Rate_of_return_on_investment ] [ Net_present_value ]

More on Meetings

[ meetings.txt ] from "Software Development Magazine".

Where is most outsourced work going

The standard answer is "India" for IT. I went in search of data and found [ ? ] as a place to monitor news about outsourcing.

CMM and ISO on the Wikipedia

[ Capability_Maturity_Model ] [ ISO9000 ]

Test data that you convert

[ dont_ignore_you.html ] (intro) and [ 193402922;jsessionid=P4NXOU45CUCFWQSNDLPSKHSCJUNN2JVN ] (Scott Ambler's analysis).

. . . . . . . . . ( end of section Online Exercises) <<Contents | End>>

Further Resources

Outsourcing book

I've studied a book that treats any systems process that separates the systems team from the programming team as outsourcing.

1. R Dennis Gibbs
2. Project Management with the IBM Rational Unifeid Process: Lessons from the Trenches.
3. IBM Press 2006, Safari

You don't need to study this book now. We will look closely at the Unified Process in CSci375. But if you are becoming a manager of such a project -- get a copy of the book.

Main reason for dot.com bust

No business model, no management, no planning, ... None of the stuff that we are talking about in this course.

Review Questions on Strategy

1. Give an example of a benefit that is a tangible and one that is intangible.
2. What does PV calculate? Draw a context DFD of the function!
3. Which kind of feasibility is assessed by using cost-benefit methods?
4. Draw a context DFD of cost-benefit analysis.
5. Write a scenario that models a typical cost-benefit analysis.
6. What information should you provide to management to start a new project?
7. Distinguish: tangible vs intangible. one-time vs recurring. cost vs benefit.
8. What does a walk-through do? How is it set up? How does it finish? What are its benefits?
9. What must be done when initiating a project?
10. What is a walkthrough? What is an inspection? How do they differ? How are they similar?
11. When should you tackle the risk in a project?
12. What is JAD? How is it done?
13. What kinds of testing are there?
14. In addition to ensuring a program works what are the other benefits of documenting tests?
15. What kind of information do you need to convince people to back your project?
16. Describe the data needed to select a suitable project to kick off?
17. Describe some of the things you must do to get a project started.
18. Explain to grandma: the difference between a walkthrough and an inspection.
19. Describe the processes that take place in implementing a system -- other than writing software.

. . . . . . . . . ( end of section Strategic Thinking) <<Contents | End>>

Abbreviations