On this page there are two topics: Pick a strategy that will pay off financially, and carefully choose an implementation strategy that is likely to work.
Development Strategies
- First -- can you do it with hardware?
- Program it in house: but don't reinvent the wheel!
- Reuse old software, perhaps with wrappers?
- Translate old code into new system.
- Reverse engineer existing component.
- You can often find a language+library system that partially fits your problem domain and so simplifies the coding. Take time to research the advantages and disadvantages of different platforms and frameworks(Ajax for example).
- You can reduce coding by using a web based Application Programmer Interface(API) as part of a social netowork like FaceBook [ http://developers.facebook.com/ ] or Search Engine like Google, that has a cool Calendar web app for example. These have defined a completely new platform for developing software. We can include "Cloud" computing in this category as well.
- Buy it -- a component or a complete system.
- Buy it -- and customize. Needs a Fit Gap process. This looks for where the component fits and where there is a gap between the component and what the enterprise needs.
- Customizing a general package like ERP. Needs a Fit Gap process. But see [ 102010-red-hat-ceo-software-vendor.html ] for a criticism of this option.
- Look for Free or Open source versions -- may involve unexpected maintenance costs plus specialized skills.
- Let the user develop their own scripts -- Visual Basic, Word Macros, Applescript, Hypercard, Koala [Lau07] , XCode, , etc.
- Out source the coding -- 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.
- Analysis. Current Physical System->Current Logical system. (extract what is going on from it's current implementation).
- Transition: Current Logical-> New Logical. Feasibility (solve problems, think up changes, check it will work)
- Design. New Logical-> New Physical, Requirements (plan ways to implement the changes).
- Implement.
- Test.
- Operate and Maintain.
- 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.
- 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)
- There Ain't No Such Thing As A Free Lunch!
- Tradeoffs: most systems involve a tradeoff between competing needs. It is worth looking for a mix of competing resources that is better than either extreme.
- The Internet has changed (1) communications, (2) services, and (3)
architectural 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. Notice that if you are developing for the Android market you will
be involved in the Linux platform and Java. On the other hand for the iPad/iPhone/iPod you
will need Objective-C (not Java or C++) to get the resulting app into the Apple
App Store. For Windows it is a moving target with ".Net" and Visual <whatever>
the current (2011) requirement.
- 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:- 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.
- 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.
- Make people feel at home. Fake bits of the old system as parts of the new.
- Make sure that management is visibly on the side of the new system.
- Meetings to sell users on the new system.
- Train the existing leaders (formal or informal) first. Send them out as evangelists.
- Provide training to cover the rough spots. Don't forget to apologise and explain the pain.
- 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. Service oriented systems are a new technology.
Pattern -- Target risks early
Choose strategies that resolve unknowns, test new technology, test user interfaces early ----- and often! - Cost_benefit_analysis::= Benefits and costs; Break_even; Return_on_investment; present_value_of_money,
(Note this shows a sequence of 4 steps).
- 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
![[Zero at first and then growing to a limit]](Sigmoid.png)
- 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
![[High at first and at the end]](BathtubCosts.png)
- Cash_Flow::=Benefit-Cost.
- 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, ...
- 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 how a small company that might invest in replacing their van by a new one:
- Benefit or cost: Cost of a new van.
- Tangible or intangible?: tangible.
- Once or recurring? : Once.
- How much? : $20,000
- When does it happen? : Start of Project
- Benefit or cost: Benefit of possible customers seeing smart van.
- Tangible or intangible?: intangible.
- Once or recurring? : Each time someone sees the van.
- How much? : $20 (??)
- When does it happen? : Each Week (??). Estimate $1,000 per year.
- Benefit or cost: Benefit of reduced running costs.
- Tangible or intangible?: tangible.
- Once or recurring? : Recurring -- each year.
- How much? : $200 (get rid of that oil leak for a start, old engine,...)
- When does it happen? : Each month
- Benefit or cost: Sell van
- Tangible or intangible?: tangible.
- Once or recurring? : Once
- How much? : $10000
- When does it happen? : 5th year
We summarize this data in a table like this:
TableTime(years) Cost Cumulative Cost Benefit Cumulative Benefit 0 20000 20000 1200 1200 1 0 20000 1200 2400 2 0 20000 1200 3600 3 0 20000 1200 4800 4 0 20000 11200 16000 Total 20000 - 16000 -
(Close Table)
Note. The Time is the time elapsed since the start of the project.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.
![[Costs grow quickly and the slowly while benefits start later and grow steadily]](BreakEven.png)
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
- Benefit or cost: Cost of a new van.
- 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
- cash_flow::= benefit - cost.
TableTime Cost Benefit Cash-flow 0 20000 1200 -18800 1 0 1200 1200 2 0 1200 1200 3 0 1200 1200 4 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 you would give up now to buy the 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:
TableYears 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)
Example 2 -- with a discount rate of 1% per year then $1 is worth different amounts if it arrives or leaves in the future:
TableYears PV (rounded to nearest cent) 0 100 cents 1 99 cents 2 98 cents 3 97 cents 4 96 cents 5 95 cents 6 94 cents 7 93 cents 8 92 cents
(Close Table)
There is a formula (called the present value (PV)) that discounts the amount depending on how far in the future(t) the cash flow(c) is for a given rate (r) --
- For Money c, Time t, Rate r, PV(c,t,r)::= c/(1+r)**t. For example:
- PV(1, 0.06, 0) = 1,
- PV(1, 0.06, 1) = 1/(1.06) = 0.94,
- PV(1, 0.06, 2) = 1/(1.06*1.06)=0.89,
You don't need to memorize the formula.... you'll find it in most spreadsheets and one the Wikipedia. But you do need to recognize it and be able to describe how we use it in cost-benefit calculations.
In calculations it is easier (often) to record the discount -- the number you divide by. For example, in the above example and assuming an interest rate of 6% per year, the cost benefit analysis would be:
TableTime Cost Benefit Cash-flow Discount Present Value(PV) 0 20000 1200 -18800 1 -18800 1 0 1200 1200 1.06 1132 2 0 1200 1200 1.12 1068 3 0 1200 1200 1.19 1008 4 0 11200 11200 1.26 8871 NPV - - - - -6721
(Close Table)
- NPV::= "Net Present Value", the sum of the present values of all the cashflows.
- NPV(cashflows, rate)::= Σ [t:Time] ( PV(cashflows[t], rate, t )).
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 calculations.
- Calculating present value of a project::=following
- Draw up a table (spreadsheet) showing when each benefit/cost happens.
- Subtract each Cost from Benefit -- the net cash flow.
- Convert cash flows to present day cash -- the Present Value or PV.
- Add the present values up -- the Net Present Value -- NPV
- Break-even analysis (Pay-back time). When does the present value of the project become positive?
- Return on investment (ROI).
Most spreadsheets have a PV(...) function to convert future money into its Present Value. Even my Tungsten E2 Palm Pilot could do this. However each one seems to be a different formula and some are about annuities not costs and benefits. As a result -- it may be best to add an extra column that accumulates the discounts for each period. Here is example of the formulas:
TableTime 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
- Make a list of all costs and benefits from the start of the project to it's end of life.
- Classify each as tangible or intangible.
- Classify each as one-off or recurring. Note when each occurs.
- Use a spread sheet to tabulate all costs/benefits and when they occur.
- Use the spreadsheet to calculate cumulative costs and benefits and the break-even point and simple ROI.
- For each time period add up benefits and subtract costs to get the "cash flow" for that time.
- Convert each cash-flow into "Present Value" or PV.
- Calculate the Net Present Value NPV at each period.
- Find the break even point when the project moves (we hope) from NPV negative to NPV positive.
- 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?Are there any other ways to discount future money
In 2011 some economists have proposed that the discount rate should decrease for cash flows in the more distance future. Others are arguing that the constant discount rate is the only rational way to do it.In this course we will assume that the discount rate is constant in all projects -- but different projects or at different times may have different discount rates.
- Name of project.
- Introduction: Who did what and why that lead to this report.
- Executive Summary -- the guts of the proposal in half a page.
- Findings -- What came out of your analysis of the situation. Indicate alternatives.
- Recommended Strategy -- what should be done
- Project Roles -- Who will be needed to do what. Training? Consultants?
- Time and Cost Estimates
- Expected Benefits
- Financial Cost/Benefit Analysis (see above)
- Appendix (for any supporting evidence you may need).
- 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 (lab, office, cubicles, meeting room, etc) if "co-located" else if not co-located set up an excellent communications infrastructure.
- Get a supply caffeine!
- Set up a project workbook or work space on a web server. (perhaps use a Wiki?)(perhaps use GoogleDocs or DropBox).
- Setup backup systems for project documents... disaster preparedness.
- Set up tools and environments.
- Review everything with team, managers, stakeholders...
- 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...
- 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 -- Review
All artifacts should be reviewed by other people. This includes special review meetings called Walkthroughs and Inspections.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:
- Preparation: people taking part must know what artifacts are being looked at and must have become familiar with them.
- Review. All issues that are raised must be noted. None are fixed.
- 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.Inspection Process:
- Preparation: people taking part must know what artifacts are being looked at and must have spent time looking for issues in them.
- Review. All issues that are raised must be noted. None are fixed.
- 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 walk throughs and inspections
In a walk through, 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. - Marketing and advertizing.
- Accounting: track and monitor money and assets.
- Inventory: raw materials on hand, stuff in production, goods to be sold.
- Pay Roll.
- Manage orders and invoices.
- Security.
- External Communications: telephone,internet address, Email, Web presence, ... Track customers, sales, ... CRM(Customer Relationship Management system)
- Handle complaints... feedback on problems.
- ...
- Investors etc.
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.Example of a Logical model for a Grading System
![[Context of Grading system DFD]](./06gradingContext.gif)
![[7 processes 2 data stores... level 0 DFD]](./06gradingDFD.gif)
Physical Designs for my Grading System
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 have tried over the years... but it illustrates how a many physical systems can implement one logical system. I have 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 | UNIX, vi & PC | 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 |
(Close Table)
. . . . . . . . . ( end of section Example -- My Grading System) <<Contents | End>>
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!
Principle -- No Programming is good programming
-
There are many ways
to get software
:
. . . . . . . . . ( end of section Principle -- No Programming is good programming) <<Contents | End>>
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: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" systems. They tend to get stuck on top of "Hills" -- local optima -- where any small change makes the system worse. They do not have to end up in the best state -- the global optimum. Under these circumstances the only thing to do is launch a big project to move the system a distant part of the "systems landscape".
A compromise method focusses on just the parts of the system that need fixing before doing any modeling.
Selecting Strategies, system architectures and Initiating Projects
Background
. . . . . . . . . ( 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 one of the categories listed below:
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.
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
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:
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 if your project is taking the opportunity of using a new piece of hardware then you will have to give the details. Another example of a case where full physical description is need is when persuading a large enterprise to buy hardware.Here are some useful tools when modeling designs:
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
. . . . . . . . . ( 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.
Start from the above and modify it to fit your company's business plan.
. . . . . . . . . ( end of section Development Strategies) <<Contents | End>>
Implementation
- Quality Control and Testing.
- Documentation
- Programming
- Training
- Data Conversion
- Acquiring hardware and software
- Change over processes
- Post-mortem
- SQA::= "Software Quality Assurance",
testing, peer review, walkthroughs, inspections, computerized validation of
artifacts(syntax check, Spell check, Model checking), 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.
- 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 steps are:
- (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. - ISO::="International Standard Organization".
- 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
- A requirement that can not be tested needs to be worked on.
- Tests have to be planned. Start planning tests as early as you can. Specifying tests is an excellent way of defining requirements.
- Automate testing whenever possible. For example unit testing for Java is a lot easier (and fun) if you use the JUnit framework.
- Unit_test::="a test that finds out if a component is working up to its specification."
- TDD::="Test Driven Development", write code that does the testing before you write the components.
- Integration_test::="a test to see if a collection of tested components work as expected".
- top_down_testing::="tests the whole first with parts replaced by stubs until they are completed, and so on down".
- bottom_up_testing::="Starts with unit tests and moves up to larger components until the whole system is tested".
- regression_testing::="Repeating all previous tests each time a change is made", means you must store tests.
- System_testing::="Top level integration test",
- Acceptance_tests::="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.
- Produce each output at least once.
- Make sure each statement is executed at least once in some test.
- Make sure that each condition is tested for true and for false.
- Test boundaries: where conditions move from true to false and vice versa
- Test what happens if a loop body is not executed.
- ...
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:
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.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 suppose we need to implement a class counter [ Counter.png ] we could write tests like this [ ttest.cpp ] and make the class Counter [ counter.cpp ] works as specified.
This technique scales well -- as the psolutions become more complex then the technique continues to work pretty well... especially when combined with better tools like make [ Makefile ] and/or an IDE like Eclipse. In Java there is JUnit...
Notice that the tests are a very good way to document typical ways to use the component.
. . . . . . . . . ( end of section Testing) <<Contents | End>>
Documentation = Producing Artifacts
- Documentation includes user documentation and system documentation.
- Better late than never?
- You need to have written instructions for operating the software.
- Routine procedures must be written down -- and be on-line.
- Use "Frequently Asked Questions" as a format for documentation -- (FAQ)
- Program documentation is designed to support maintenance and evolution.
- 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.
- Tests are also useful documentation.
- Source code is documentation and contains documentation (as comments and its identifiers).
Programming
Try to find alternatives... but we cover this in detail in [ ../cs375/ ]Training
- 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.
Story -- smart technology made dumb
This university have installed a number of Smart Boards that act as projection screens and input devices. How ever I have not had the time to be trained in using them so they are being underutilized.Training is a vital part of installing a new 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.. . . . . . . . . ( end of section Training) <<Contents | End>>
Data Conversion
- 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
- Many strategies with varying costs and risks.
TableName 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
- 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.
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:Quality is Job 1
. . . . . . . . . ( end of section Implementation) <<Contents | End>>
Online Exercises
- Also see
[ http://www.wired.com/magazine/2009/12/fail_duke_nukem/ ]
for the story of a failed game company.
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).
Story -- ERP System Abandoned Unfinished
Study this story [ http://www.computerworld.com.au/article/442099/air_force_scraps_massive_erp_project_after_racking_up_1_billion_costs/ ]Analyse the project in terms of SPORTs and the development plan.
How could this money not have been wasted?
Story -- What caused the dot.com and other failures
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 ]. . . . . . . . . ( end of section Online Exercises) <<Contents | End>>
Further Resources
- R Dennis Gibbs
- Project Management with the IBM Rational Unifeid Process: Lessons from the Trenches.
- IBM Press 2006, Safari
- Phillip G Armour
- Return at Risk
- Communications of the ACM Vol 53 no 9(Sep 2010)pages 23-25 [ 1810891.1810902 ]
- =POLEMIC ESTIMATION ROI RISK COST VALUE DISTRIBUTION
- ROI::acronym="Return on Investment"
- Argues that the traditional straight line formula
- ROI=(value-cost)/cost, is not valid if there is any risk of the cost or value being wrong.
- Need cost and value profiles. Probability distributions.
- Notes that cost' tends to be skewed toward overruns and value` towards zero.
- Calculating a better likely or average ROI is not simple and may need Monte Carlo methods. There exist tools.
Outsourcing book
I've studied a book that treats any systems process that separates the systems team from the programming team as outsourcing.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.
ROI and Risk
Study this paper, after CSE557 is over, to get an idea of how the risks in calculating costs and benefits can make calculating Return on Investment highly non-trivial:Armour10
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
- 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? Implementing a system may require changing any type of component. For each type name a process used to change them.
- How can you get a new piece of software? Make a list.
- Give an example of a benefit that is a tangible and one that is intangible.
- What does PV calculate? Draw a context DFD of the function!
- Which kind of feasibility is assessed by using cost-benefit methods?
- Draw a context DFD of cost-benefit analysis.
- Write a scenario that models a typical cost-benefit analysis.
- What information should you provide to management to start a new project?
- Distinguish: tangible vs intangible. one-time vs recurring. cost vs benefit.
- What does a walk-through do? How is it set up? How does it finish? What are its benefits?
- What must be done when initiating a project?
- What is a walkthrough? What is an inspection? How do they differ? How are they similar?
- When should you tackle the risk in a project?
- What is JAD? How is it done?
- What kinds of testing are there?
- In addition to ensuring a program works what are the other benefits of documenting tests?
- What kind of information do you need to convince people to back your project?
- Describe the data needed to select a suitable project to kick off?
- Describe some of the things you must do to get a project started.
- Explain to grandma: the difference between a walkthrough and an inspection.
- Describe the processes that take place in implementing a system -- other than writing software.
- Study the case study/experience cited as [Lobur11] (Use the oncampus IEEE Digital Library) and summarize what you learned from it in one or two sentences.