Stage 4

E-Mail

E-mail has become the de facto standard for business correspondence. E-mail can be used as a

superior substitute for memos and letters and as the multimedia carrier for an essentially

unlimited array of pictures, sounds, movements, and colors.

Reports

Reports will comprise the bulk of the documentation of the processes involved in systems

analysis and design. The feasibility report was discussed in module 1; other reports of interest are

the technical, progress, and formal.

Technical Reports

After the feasibility study has been completed, but before the systems design is prepared, it will

be necessary for the analyst to ensure the preparation of one or more technical reports. The

purpose of technical reports is to validate the studied opinion. To say that a particular solution is

feasible is one thing, but to know that it has a high probability of actually solving the problem is

another matter. A technical report is one of definition—defining the problem, the solution, the

audience, and the needs to be fulfilled. The specific type of technical report is a function of the

task at hand and can be a technical-background report, a state-of-the-art review, instructions, a

primary research report, or technical specifications.

Technical-Background Report

The technical-background report provides specific information about a well-defined topic such

as intelligent agents, unified messaging, or a particular programming language. This kind of

report focuses on a specific audience who has specific needs or uses for the information.

Technical Background Report: Existing Conditions and Alternatives, an example of a technical

background report is provided at http://www.lcog.org/metro/pfsp_tbr_nm.pdf. Key elements of

the technical-background report can include:

• historical background • definitions • processes • descriptions • comparisons • applications • advantages and disadvantages

Since this report addresses any kind of technical information, it should be modified as necessary

to capture the contents needed to get the job done.

State-of-the-Art Study

A variation of the technical-background report is the state-of-the-art study. With this study,

there is no clear topic as in the technical-background report. Instead, there is a need to research

the availability of solutions that are currently viable. Elements for the study can include:

• causes • effects • types • economic considerations • social, political, legal, ethical implications

A state-of-the-art study is essential for determining your opportunities as well as the possible

constraints associated with each.

Instructions

Instructions are probably the most familiar of all reports. Common examples are the user

manuals that accompany appliances, equipment, and software applications. Instructions are

essential in the development of schedules and budgets that will be provided in the project plan.

Primary Research Report

A primary research report is the type of report, often called a "lab report", that presents

original research data—regardless of whether that data was generated in a laboratory or out in

the field. It is called primary because a secondary research report presents information gained

largely from printed information sources or from other sources such as personal interviews.

Technical Specifications

Technical specifications are descriptions of products or product requirements. More broadly,

they can provide details for the design, manufacture, testing, installation, and use of the product.

When you write technical specifications, pay particular attention to critical factors such as

accuracy, precision of detail, and clarity.

Progress Reports

Once a new system has been accepted and once the implementation phase has begun, there is a

need to keep all relevant stakeholders informed about how things are going. There will always be

periods along the way to systems maintenance when what was proposed to happen is changed by

reality. Systems-design plans are supposed to be estimates about what might happen rather than

an evaluation of what has happen. Progress reports are the "what has happened compared to the

what might happen."

Progress reports are recommended if the new system is more than 30 days in duration. No news

is good news—except for the status of systems implementation. Decision-makers want to know

about any problems or potential problems as soon as possible. This means that they are looking

for some kind of periodic report of how the systems implementation is progressing toward

completion of its specified goals. At a minimum, a progress report should contain five important

elements: completion, WIP, remainder, contingencies, and status.

• Completion is a measure of how much of the work has been actually accomplished. This indicator of progress is compared against the budget and the schedule established as the baseline for the systems implementation.

• Work-in-progress (WIP) is a description of the work that is currently in progress. WIP is an important consideration for stakeholders. What you are doing compared with what you said you would be doing will directly equate to the comfort level of the decision-maker.

• Remainder is an estimate of what work remains to be done. The amount of work yet to be done will influence completion of the systems implementation on time and within budget. The amount of work remaining on the project can be a significant factor in the determination of whether or not the systems implementation will be allowed to continue.

• Contingencies explain what problems, if any, occurred and the corrective actions taken to eliminate each of them. By their very nature, new systems are prone to a certain amount of risk and uncertainty. Things are going to happen, but what's important is how well the analyst can correct the inevitable risk incident and keep the project on track.

• Status is a statement of how well the project is going in general. Status can be simply a narrative of the current state of the project or it can be supported with the results of analyses such as:

o earned value o cost of work performed o cost variance o cost performance index o schedule variance o schedule performance index

In general, the more detailed the progress report, the better the new system can be controlled.

Formal Reports

Formal reports are the accounts of the completed new system. They become the document of

closure for the systems implementation as well as the major reference document for the newly

created system. The number and arrangement of elements in a formal report will vary, depending

on the specifics of the project, but there is a standard convention that can be used as a guide.

The formal report is the most detailed and comprehensive of all the documents that an analyst will need

to prepare. While there may be relief and satisfaction that the new system has been successfully

implemented, it is not finished until the formal report has been submitted for closeout of the contracts

and obligations. Skills for new Information Professionals: the SKIP Project, an example of a final report, is

provided at http://www.ukoln.ac.uk/services/elib/papers/other/skip/. The formal report is actually a

collection of elements grouped into a sequence of five parts: front matter, up-ramp, text or body, down-

ramp, and back matter.

The front matter is written primarily to inform the reader of what and where specific elements

are available. Not all elements are included in all reports, but, for purposes of this course, the

front matter will include:

o title page o abstract o table of contents o list of figures o list of tables o list of abbreviations and symbols o preface

• The abstract and preface are the "sizzle for the steak." Special attention should be paid to the crafting of these elements because they are used to compel the reader to go to the body of the report (i.e., the "steak"). The abstract highlights the major points of the report, enabling the reader to decide whether to read the entire report. The preface is an introductory statement written by the author that announces the purpose, background, and scope of the report.

• The up-ramp is used to create the transition into the body of the report. It is usually composed of the executive summary and an introduction. The executive summary is intended to provide more information about the report than is contained in the abstract. While an abstract is about 50 words, an executive summary is about 250 words. The introduction will provide general information the reader must have in order to understand the detailed information in the rest of the report.

• The text, or body as it is often called, of a formal report presents the details of how the problem was researched, how the solution was determined and implemented, components of the new system, risks that were mitigated, lessons learned, and so on. The information is usually clarified and further developed by the use of illustrations and tables and may be supported by references to other systems that have been implemented.

• The down-ramp is used to provide a wrap-up of the new system. The conclusions element is used to summarize the major components of the new system. Recommendations, which are sometimes combined with the conclusions, state what course of action should be taken based on the lessons learned from the systems implementation.

• The back matter is used to provide supplemental information about the report, and will often include:

o reference o bibliography o appendixes o glossary o index

Both the references and the bibliography contain a list of resources. The reference section lists

materials that were actually "referred to" in the body of the report, while the bibliography section

lists materials that were "consulted" but not cited.

Presentations

At some point there will arise a need to provide intentions, status, or results to the various

stakeholders. There are three non-report presentations: oral, slide show, and poster.

Oral

An oral presentation, commonly called a talk, can be viewed as a series of steps (Radel, 1999a):

• Planning • Preparation • Outlining • Important elements • Practice • Presentation • Moment of truth • Handling questions

The oral presentation is a talk without supporting visual elements.

Slide Show

Creating an effective set of visuals will greatly enhance the oral presentation. Remember that the

use of visuals to enhance your oral presentation has a tradeoff—the need for a way to present the

visuals. Radel and Massoth (1999) recommend four important design elements:

• Make it BIG. • Keep it Simple. • Make it Clear. • Be Consistent.

Poster

A poster session is intended to present the desired information as printed pages that are affixed to

a mat board, which is then placed on a poster easel for a relatively long term. The steps involved

in this form of presentation are (Radel, 1999b):

• planning the poster • creating the title banner • layout of the poster • dealing with illustrations • dealing with text

• poster assembly

Case Studies

Case studies are an excellent way to document the SDLC, or at least the basis for development.

The four main areas of interest in the development of case studies are situation, problem,

solution(s), and evaluation (Engineering Communication Centre 2001).

Situation

The situation refers primarily to the existing system to be changed. Key questions to be answered

are:

• "What are the needs of the client? • What are the constraints of the situation (time, resources, laws, technologies)? • What are the background facts? • What are other key questions that must be answered (Engineering Communication Centre

2001)?"

Problem

Creating an effective solution depends on whether there has been a clear statement of the

problem. The problem articulated by the client may not be the root cause of the symptoms

recognized. Obtaining a full background to the problem requires answers to the following key

questions:

• "What are the parameters that have been set for your analysis? • What is happening in the situation now? • What are the shortcomings of the current or previous ways of handling the situation? • What changes have been made in the situation (Engineering Communication Centre 2001)?"

Solution(s)

While many solutions may be generated in response to a particular problem, chances are that

only one will be a real solution. The best solution is the one that will correct the root cause of the

problem and not merely one of the symptoms of it. The key questions to be answered about the

solution include the following:

• "How does the solution work? • How does the solution fit with what we know about the situation? • What research supports and validates the proposed solution (Engineering Communication

Centre 2001)?"

Evaluation

Before the new system can be actually implemented, it must be refined in order to provide a

good fit. Key questions include the following:

• "Is the solution likely to be successful? • What limitations might prevent total success? • What should the client do in order to make the solution work (Engineering Communication

Centre 2001)?"

Proposals

A proposal is an offer to do something for someone. According to Reid (2001), "any proposal

offers a plan to fill a need, and your reader will evaluate you plan according to how well your

written presentation answers questions about:

• "What you are proposing • How you plan to do it • When you plan to do it • How much it is going to cost"

Introduction

"The introduction presents and summarizes the problem you intend to solve and your solution to

that problem, including the benefits the reader/group will receive from the solution and the cost

of that solution (Reid 2001)."

Body of the Proposal

"The body of the proposal should explain the complete details of the solution:

• How the job will be done • Broken into separate tasks • What method will be used to do it (equipment, material, and personnel) • When the work will begin • When the job will be completed • Detailed cost breakdown for the entire job (Reid 2001)."

Conclusion

"The conclusion should emphasize the benefits that the reader will realize from your solution to

the problem and should urge the reader to action. It should be encouraging, confident and

assertive in tone (Reid 2001)."

WorldWideWeb: Proposal for a HyperText Project, an example of a proposal, is provided at

http://www.w3.org/Proposal.html.

Cost Estimates

The traditional approach to estimating software costs has focused on algorithmic cost modeling.

However, these formal models have shown that the estimates between predicted and actual

values can vary as much as 85 percent to 610 percent (Snell, 1997). Alternatives to algorithmic

cost modeling include estimating by using equations, estimating by using comparison, and

estimating by using analogy (ISBSG 2002).

Using Equations

By analyzing historical information, regression equations can be produced for a rather wide

variety of parameters, such as:

• project delivery rate • effort • duration • speed of delivery • platform used • language used

Using Comparison

More detailed estimates can be obtained by using comparisons. The focus of this method is to

compare the proposed system against the median of a set of similar projects previously

performed. If you do not have access to a suitable set of data available for comparison then this

method cannot be used.

Using Analogy

Estimation by analogy involves selecting a previous project that most closely resembles your

new system. This method differs from estimation by comparison in that the focus is on a single

project that closely matches the characteristics of you new system. The "analogue" becomes the

basis for the new estimates.

Cost-Benefit Analysis

A cost-benefit analysis (CBA) is a technique that attempts to compare the outflows, as costs,

with the inflows, as benefits. If the new system is positive (that is, benefits exceed costs) then the

new system can be justified. The primary limitation of a CBA is that you are literally trying to

compare apples (cost) and oranges (benefits) in dollar terms. More Than Just Pretty Pictures: A

Cost/Benefit Analysis of Digital Library Holdings, an example of a CBA is provided at

http://www.educause.edu/ir/library/html/cnc9804/cnc9804.html. The methods used to compute a

CBA can vary depending on whom you consult, but the five essential steps are as follows (CIT

2001):

1. Collect Cost Data

Cost data should be extensively accumulated so that a meaningful CBA can be performed. There

are six sources of data to consider:

• historical organizational experience • current system costs • market research • publications • analyst judgment • special studies

2. Estimate Costs

Estimating the costs associated with the CBA must include all costs for the full system

development life cycle. The following factors should be considered:

• activities • resources • cost categories • personnel costs • direct cost • overhead • depreciation • annual costs

3. Estimate Benefits

Benefits are the services, capabilities, and qualities of the new system. Common benefits include

the following:

• improvement of the current system • addition of new services • productivity gains • staffing reductions • improved organizational effectiveness

4. Establish Equivalency

Regardless of how well the costs and benefits have been identified and estimated, the greatest

difficulty in CBA is the matter of equivalency. This means that both must be "monetized" in

equal dollar terms. The transition to monetary value is objective for costs, but largely subjective

for benefits. Placing monetary values on human well-being attributes for which there is no

market value will be complicated, expensive, and controversial.

5. Perform Sensitivity Analysis

Once the CBA has been completed, there is a need to determine the reliability of the results

obtained. The sensitivity of the results is a measure that requires a determination of the variables

considered, reflected in a deliberate change shown by another CBA. For example, changes in the

input of incremental staffing reductions may be much greater to the results than an equivalent

input of productivity gains. Thus, if a relatively small change to an input parameter results in a

relatively large change in output, the analysis is sensitive to that particular variable.

Payback Analysis

Payback analysis is a simple economic analysis method, intended especially for comparing

alternative systems (Tri-State 2000) The results of a payback analysis is a "payback period"

expressed in months or years. Lighting Systems: Simple Payback Analysis Method, an example

of a payback analysis is provided at http://tristate.apogee.net/lite/lecospm.asp. The payback

period is a metric that takes an investment view of the new system and its estimated cash-flow

stream.

Amount of Time

The payback period is the length of time required to recover the cost of an investment in the new

system, usually measured in months or years. Other things being equal, the better investment is

the one with the shorter payback period.

Marginal Cost

The marginal cost is the amount above and beyond the current expenditures that will be required

to implement the recommended innovation. As an example, let's assume that the cost of a new

system is a total, one-time cost of $30,000.

Cost Savings

Cost savings, the goal of the new system, has been estimated to be about $6,000 per year. Thus,

the payback period is $30,000/$6,000, or five years

Return on Investment

A measure of performance is the return on invested capital, or, more commonly, the return on

investment (ROI). Since the meaning of an ROI is easily understood and seems self-evident, ROI

is an appealing concept to stakeholders.

Amount of Investment

According to Rice (2001), investments can be determined for three types of returns:

• tangible benefits, such as reduced inventory or back office processing costs

• intangible benefits, such as customer satisfaction or improving business processes • strategic benefits, such as long-term growth or expansion into new markets

Amount of Time

The time required for the "return" is determined in advance. Commonly with new systems, the

measure is the ROI during the first year of investment. But if the incremental returns do not

become significant, the measure may be the ROI during the first two years, during the first five

years, and so on. The point is that there must be some kind of ROI during a realistic timeframe in

order for the investment to be considered.

Amount of Return

The return is measured as a percentage of the investment, which assumes that the new system

will break even by recouping the entire amount invested. If not, there will be no return, only a

loss of some, or all, of the investment—not a good thing to happen.

Percentage of ROI

The calculation of ROI is quite simple: (return minus investment) divided by the investment,

resulting in a ratio that can be easily converted to a percentage. The higher the ratio the better,

because this provides a measure of each dollar invested. For example, suppose that during the

first year the new system is expected to generate $120,000 in total cost reductions. The new

system cost $100,000 to implement. The ROI is this case is ($120,000 -$100,000)/$100,000 =

$20,000/$100,000 = .20 = 20% ROI.

Value Analysis

Value is an imprecise word that is influenced by both the user and the context of situation. The

notion of value analysis is to increase values rather than reduce costs.

Defining Value

According to Crow (no date), value "can be expressed as maximizing the function of a product

relative to its cost: Value = (Performance + Capability)/Cost = Function/Cost". Value, as

functional worth, is "the lowest cost to provide a given function."

Functional Analysis

Value analysis was developed at General Electric in 1945 as a team problem-solving system.

Value analysis begins with an analysis of function. In other words, if the new system does not

work as intended, it will not have value to the customer. The process begins with word pairs

called functions, which become the focus of team discussion.

Earned Value Analysis (EVA)

Earned value analysis was established by the Department of Defense in 1967 as a way of

standardizing contractor requirements. At a fundamental level, EVA compares "planned" work

with "accomplished" work in terms of the dollar value assigned to the work. According to the

Microsoft Assistance Center:

Earned value analysis tells us how much of the budget should have been spent, in view of the

amount of work done so far, and the baseline cost for the task, assignment, or resource. "Earned

value" is actually a very descriptive name: how much value has the work on the project earned

so far? To make cost and schedule values comparable, earned value analysis focuses on dollar

values of cost and schedule (Microsoft Corporation 2002).

Future Value Analysis (FVA)

Another variation is a technique called future value analysis. The purpose of FVA is "to help

organizations identify and create future value. FVA begins with an assessment of the strategic

planning environment. Next, FVA identifies activities that create value for the organization.

Finally, analysis is performed to select the best strategies or portfolios of decisions (RAAF

1998)."

Structured Methodologies

Rationale for CASE Tools

Computer-aided software engineering, or CASE, was developed in an attempt to reduce the

burden of software development and its subsequent maintenance. The rationale for the

development of CASE tools is to increase the speed of systems development by using a more

engineering-type discipline.

Why Use CASE Tools?

When used under the proper set of circumstances, CASE tools can provide the following

advantages (Hogan 1999):

• ensure consistency, completeness, and conformance to standards • encourage an interactive, workstation environment • can speed up the development process (by helping to generate code) • allow precision to be replicated • can reduce costs, especially in the maintenance phase • can increase productivity • can make structured techniques practical

CASE tools can be divided into two types: upper CASE and lower CASE. Occasionally a toolset,

such as those developed for project management, will include both upper and lower CASE tools.

The combination of upper and lower, referred to as integrated CASE tools, is designed to support

activities across all phases of the SDLC.

Upper CASE

Upper CASE tools, or front-end as they are sometimes called, are designed for the first three

phases of the SDLC: systems planning, systems analysis, and systems design. Tools are included

for requirements determination, GUI design, and database design. Those who create and modify

the system design, such as analysts and designers, use upper CASE tools.

Lower CASE

Lower CASE tools, or back-end as they are sometimes called, are designed to support the last

two phases of the SDLC: implementation and maintenance. Lower CASE tools, including those

used for generating code, testing and software maintenance, are used primarily by programmers

and maintainers of the new system.

Rationale for Prototyping

Walter Maner provides an excellent overview that addresses the rationale of the prototyping

process. He suggests that prototyping may address the problem of:

• "Communications between developers and customers • Customer acceptance • Delivering early proof of concept • Fuzziness in early stages of design • Gathering valid requirements • Increasing constructive user participation • Managing change requests • Product invisibility • Quality assurance (Maner 1997)"

References

Center for Information Technology (CIT). (2001). Cost-Benefit Analysis Guide for NIH IT

Projects. National Institutes for Health. Retrieved August 6, 2002, from

http://irm.cit.nih.gov/itmra/cbaguide.html.

Crow, K. (no date). Value Analysis and Function Analysis System Technique. DRM Associates.

Retrieved August 6, 2002, from http://www.npd-solutions.com/va.html.

Engineering Communication Centre (2001). On-line Handbook: Case Studies. The University of

Toronto. Retrieved August 5, 2002, from http://www.ecf.utoronto.ca/~writing/handbook-

casestudies.html.

Hogan, D. (1999). Topic: A Study of Case Tools. Information Systems, College of Business

Administration, University of Missouri – St. Louis. Retrieved August 6, 2002, from

http://www.umsl.edu/~sauter/analysis/dfd/CaseTool.html.

International Software Benchmarking Standards Group (ISBSG). (2002). Estimation Techniques.

Retrieved August 6, 2002, from http://www.isbsg.org.au/html/estech.html.

Maner, W. (1997). Prototyping. Department of Computer Sciences, Bowling Green State

University. Accessed August 6, 2002, from http://csweb.cs.bgsu.edu/maner/domains/Proto.htm.

Microsoft Corporation. (2002). Microsoft Project 98/2000: Introduction to Earned Value

Analysis. Microsoft Office Assistance Center. Retrieved August 6, 2002, from

http://office.microsoft.com/assistance/2000/ProjEarnedValueFields.aspx.

Radel, J. (1999a). Preparing Effective Oral Presentations. "Main Menu." Department of

Occupational Therapy Education, Allied Health, University of Kansas Medical Center. Retrieved

August 5, 2002, from http://www.kumc.edu/SAH/OTEd/jradel/Preparing_talks/103.html.

Radel, J. (1999b). Designing Effective Posters. "Main Menu." Department of Occupational

Therapy Education, Allied Health, University of Kansas Medical Center. Retrieved August 5,

2002, from http://www.kumc.edu/SAH/OTEd/jradel/Poster_Presentations/PstrStart.html.

Radel, J., and C. Massoth. (1999). Designing Effective Visuals. "4 Important Design Concepts."

Department of Occupational Therapy Education, Education Technology, University of Kansas

Medical Center. Retrieved August 5, 2002, from

http://www.kumc.edu/SAH/OTEd/jradel/Effective_visuals/105.html.

Reid, A. (2001). A Practical Guide for Writing Proposals. Retrieved August 6, 2002, from

http://members.dca.net/areid/proposal.htm.

Rice, C. (2001). Calculating Return on Investment on IT Projects. PriceWaterhouseCoopers

White Paper based on Corporate Finance article in Infotech. Retrieved August 6, 2002, from

http://www.pwcglobal.com/extweb/ncinthenews.nsf/docid/5FA647225691100DCA256AE6003E

BE5D.

Royal Australian Air Force (RAAF). (1998). Value Analysis. RAAF Project ORACLE 2030

Future Value Model. Retrieved August 6, 2002, from

http://www.defence.gov.au/raaf/2030/valueanalysis.html.

Snell, D. (1997). Algorithmic Cost Models. Retrieved August 6, 2002, from http://www.ecfc.u-

net.com/cost/models.htm.

Tri-State Generation and Transmission Association, Inc. (Tri-State) Energy Library. (2000).

Simple Payback Analysis Method. Lighting Systems. Retrieved August 6, 2002, from

http://tristate.apogee.net/lite/lecospm.htm.

Copyright © by University of Maryland Global Campus

Table of Contents.html