Chapter 10 Margin Notes
General Note: This is my kind of chapter---a really geeky, nerdy chapter that talks about how e-Business Systems are developed. Read it, and remember how hard this stuff is the next time you want to attack your computer guy at work.
Page 374, The Systems Approach. This is the classic approach to developing any Computer Program--as well as e-Business. This stuff can be pretty dry, but hang in there--it will give you an appreciation for the way things should be done. By the way, the Systems Approach is used not only in developing Computer Systems, but in building a house, doing a term paper, virtually anything complex that will take more than a few minutes to do.
Page 375, Real World Case #1, Intuit Inc.Check it out for information on In-House Development.
Page 377, The Systems Development Life Cycle. This book indicates that it consists of 5 steps or phases--some books have 6, others have 4.
Page 377, Feasibility Studies. I've always been fascinated by Feasibility Studies, which is a preliminary step you take prior to assuming the costs (and responsibilities) of developing a new System. Each company has different standards or benchmarks for deciding whether to pursue a new system. This is discussed in this section. I bet you can probably recall a system or two that you've worked or interacted with that you wondered "Why was this ever built in the first place?"
Page 380, Cost/Benefit Analysis. There always seems to be a lot of confusion over the concepts of Tangible/Intangible Costs and Benefits. Tangible is anything you can tough or measure quantitatively (with numbers), such as salary, jobs eliminated, savings realized. Intangibles are harder to measure: Customer goodwill, employee morale, etc.
Page 380, Figure 10.5. This is a good one--be sure to read and study this.
Page 381, Systems Analysis. Just a fancy term for what happens before, during and after a new Computer System is developed. As the author says a few pages later, Systems Analysis describes what a system should do to meet the information needs of users.
Page 382, BuyerZone and OfficeMax: Evaluating Customer Website Experiences. Check it out.
Page 384, Systems Design. I like the author's definition: Systems Design specifies how the system will accomplish what is required of the System in the Systems Analysis phase.
Page 384-375, Prototyping. Prototyping should not take the place of the SDLC (Systems Development Life Cycle), but may include it. Prototyping is really a tool to be used in communicating with the user.
Page 386, User Interface Design. An incredibly important concept--check out the Interface Hall of Shame
and the Interface Hall of Fame
for more details on why Interface design is so important.
Here's something else you may find interesting...
Page 387, Google: Evaluating User Interface Design. As good as Google is, we can't skip anything about them, can we?
Page 388, End User Development. End User Development occurred because some intelligent users, with a basic knowledge of computers and programming and development tools, were unhappy with the support being provided them by the Computer Department. It really started a revolution!
Page 391, End User Applications Development: 99 Percent Accuracy is Not Enough. A good one.
Page 391, Technical Note: Overview of Object-Oriented Analysis and Design. Check it out.
Page 393, Implementing Business Systems. This is a pretty interesting section---please read it, and the Case Study on Page 393, carefully. In particular compare how the development of a Business System is similar to the development of the types of Computer Systems discussed earlier in the chapter.
Page 393, Zurich North America: IT Project Management. Check it out.
Page 393, Project Management. Project Management is a very big deal in the world today. It can make you a lot of money.
Page 393, Real World Case #2. Infosys Technologies: the Implementation Challenges of Knowledge Management Initiatives. Love this one!
Page 400, Hardware Evaluation Factors, Figure 10.22. This applies not only to Business but to any Computer System---including hardware you buy for home. Same with Figures 10.23, and 10.24.
Page 401, Other Implementation Activities. We must not forget these---which take place, in theory, after the System has been developed (although Testing Training and Documentation can take place while the System is being developed).
Page 403, System Conversion Strategies.. Every book discusses Conversion Methods in detail--and with good reason. It's been my experience that more projects run over-budget and over-time due to improper conversion (and conversion) planning.
Page 406, Systems Maintenance. Maintenance is what you do to a System after it is complete and implemented. Maintenance can be very minor (adjusting the Sales Tax rate for a state in your e-Business System, for instance) to major (adding a major new function to your web site that previously did not exist). Part of Maintenance is soliciting and receiving feedback on your System (post implementation review) to enable you to measure how successful your Systems Design was in meeting the users' needs and requirements.
Page 406, Aviall Inc.: System Implementation Failure: You know I love this one!
Page 408, Qwest and Others: User Resistance and Involvement. Check it out.
Page 409, Change Management. Entire books (and courses) have been devoted to this topic. Suffice to say that most users don't like change. Managing how users' perceive changes to their work environment, to existing systems is crucial.
Page 416, Real World Case #3, Indiana University. Check it out.