10 ROI Pitfalls
Robin F. Goldsmith, JD Anthony Sarno
Go Pro Management, Inc. https://www.doczj.com/doc/9813179727.html,
22 Cynthia Road 5385 Peachtree Dunwoody Rd. #1009
Needham, MA 02494 Atlanta, GA 30342
781 444-5753 404 255-0847
Return on Investment (ROI) is frequently required as a basis for making decisions about technology directions and acquisitions. Equally frequently it seems, ROI can create controversy and consternation. Many people question the appropriateness of ROI calculations, while others are uncomfortable with and even fearful of making the ROI calculations themselves.
Frankly, ROI often is misunderstood and misapplied; and although some folks undoubtedly are scared of math in general, ROI computations can invoke uncertainty even in those who ordinarily are not mathphobic.
To help you use ROI confidently and competently, we’ve identified and suggest ways to avoid the following 10 pitfalls that commonly affect the suitability
of ROI calculations and their usage. We start with simpler issues related to the calculations themselves. Then we move to the more difficult, and often more important, issues of how ROI is interpreted and used.
1. Including Only Cost Savings
ROI often is criticized because many people address only cost savings in
ROI calculations. In fact, the “return” in Return on Investment refers to
financial benefits, which can involve both costs and revenues; and both
should be taken into account.
Terminology inconsistencies can further complicate understanding. The
term “cost” is often used to mean different things and referred to by other
names. For example, “investment” relates to spending for a future return;
and “expense” pertains to spending for a current return. ROI is calculated
through cost/benefit analysis, where “cost” is the amount invested in a
solution, and the benefits can include impacts on expenses attributable to
that solution, which usually are called “cost savings” and “cost avoidance.”
Cost savings result from no longer spending some amount which had been
spent previously. The most common source of cost savings comes from
cutting staff (reducing headcount) and their related personnel expenses,
such as salaries and benefits.
Understandably, people often are not comfortable with savings from
personnel reductions; and they may find cost avoidance benefits more
palatable. Cost avoidance occurs when the proposed solution enables
avoiding an expense which otherwise would have been necessary. For
example, the solution could make it possible to handle a typically-growing
workload without having to add resources, or by reducing the rate at which
additional resources must be added (“decreasing the increase”).
Whereas cost savings may involve eliminating the job of someone we know, cost avoidance generally means not having to hire someone we haven’t yet
met. While often emotionally preferable, cost avoidance is more subject to (conscious or unconscious) exaggeration than is cost saving.
Revenue-related benefits come in two similar versions. Revenue
enhancement means that the proposed solution causes additional revenue.
The solution may enable selling additional products, selling more of existing products, charging higher prices for products, and/or collecting more billed amounts than previously.
In contrast, revenue protection does not increase revenues but enables
maintaining current revenues which otherwise would be lost. For example, if a competitor introduces a product which attracts our customers, we may have to introduce a similar product simply to keep our existing customers
from switching to the competitor. Another common form of revenue
protection involves compliance with laws and regulations, which can be the price of being allowed to continue generating revenue.
2. Ignoring the Product Solution’s Useful Life
ROI frequently is faulted for considering only the immediate, short-term
period. In fact, most solutions will continue in operation for a longer period which should be taken into account and can considerably affect both costs and benefits. Accounting conventions define the appropriate length of time for evaluating an investment as its useful life. (By the way, an asset’s useful life also is the basis for determining its depreciation.)
Different categories of investments have different useful lives. For example,
a building typically has a useful life of 25 or more years, whereas
computerized information systems are assumed to last only five (or possibly fewer) years. Note that the useful life is merely an accounting convention.
It’s entirely possible you work in a 200-year-old building with an information system written 30 years ago. Conversely, brand new buildings sometimes burn, collapse, or are abandoned; and some new information systems meet similar fates long before the end of their theoretical useful life.
Thus, when determining the benefits of a solution over its useful life, one
must include its ongoing costs of operation and maintenance. While paying more for a product may just mean the product is more expensive,
sometimes paying an initial premium for quality can yield a lower total cost of ownership over the product’s life. Of course, customers would prefer
paying less initially for a product which also costs little to maintain and
operate.
Similarly, impacts on revenue can vary over time. Considering just the initial effect on sales could obscure the product’s more important total return. A product could have initial high sales but then fail to sustain the rate, such as
when needs are satisfied, needs change, or experience shows the product is unsatisfactory. On the other hand, many products take an initial period to catch on but then sell at a sustained or even growing rate for an extended duration. Don’t forget too that subsequent warranty costs and returns can reduce or even eliminate revenues.
3. Not Including the Time Value of Money
Would you give me $1000 now if I promise to pay it back to you in one
year? Assuming I will repay it (hey, I’m good for it; you can trust me, I’m a salesperson), getting back $1000 a year from now is worth less than having the $1000 now.
There is a value to having money in your hands. You can use the money.
At the very least, you could put it in an insured bank savings account and earn interest. If the interest rate is four percent, I’d have to pay you back
$1040 just to keep you even.
An ROI calculation should reflect this time value of money. That is, the
value of a dollar decreases the longer one waits to spend or receive it.
Thus, deferring spending is a way of increasing benefits; whereas deferring revenue reduces benefits.
Some expenses are one-time, such as the price for purchasing a product.
Some are ongoing at a constant rate irrespective of usage, such as rent or property taxes. Other ongoing expenses vary with usage, such as utility
bills. Some types of expenses experience step-wise increases, which occur all at once, such as when the Post Office raises postage rates.
Some expenses increase annually by a definable percentage, which may vary from year to year, such as inflation. Business growth and revenues
may experience comparable types of changes over time. For example, the postal rate change represents a cost to you but revenue to the Post Office.
The year-to-year timing of such revenues and expenses should be reflected and adjusted for the time value of money in the ROI calculation.
Statistical tables are readily available to use in reflecting the time value of money in ROI and other calculations. These tables show the discount
factor, which is the percentage of a dollar that it is worth when spent or
received at some particular future time, based upon a presumed interest
rate.
The typical discounted cash flow technique calculates for each year of
useful life the net annual benefit, which is usually revenue for the year
minus expense for the year. For solutions which are mainly concerned with reducing costs, net annual benefit alternatively is computed as expense for
the year minus revenue for the year. Either approach is appropriate, so
long as the same calculation is used consistently throughout.
For each year of useful life, the applicable discount factor is multiplied times the year’s net annual benefit to produce the year’s net present value.
Because the calculation means each year’s net present value is stated in
today’s dollars, the total net present value is a single figure in today’s dollars which can be calculated by summing the net present values for each year of useful life.
4. Comparing Revenue and Expenses Dollar-to-Dollar
Many seemingly reasonable ROI calculations inadvertently grossly
misrepresent benefits because they assume a dollar of revenue directly
offsets a dollar of expense. Thus, for instance, spending a dollar to gain two dollars in revenue actually may be an unwise investment.
Expense-related benefits go directly to the bottom line. Each dollar of cost that is saved or avoided becomes a dollar of profit. On the other hand, only
a portion of an increased or protected revenue dollar becomes profit. The
profit margin reflects that portion of revenue that remains after subtracting the additional manufacturing, sales, support, and administrative costs of
producing the additional revenue.
5. Using Unsupportable Cost and Revenue Estimates
It’s common for ROI to be calculated using cost and revenue estimates
which have no reasonable bases. That is, there is not a rational link
between the proposed solution and the costs and revenues the solution is purported to affect.
For example, inexperienced consultants have been known to focus on
activities such as photocopying as the way for client companies to save their way to prosperity. The consultants realize there’s a savings opportunity
when they observe employees making personal copies of jokes and body parts. However, in their zeal, they tend to lose sight of the fact that the
company can save no more than the total amount currently being spent on photocopying, which usually is relatively modest and can’t be eliminated
completely anyhow.
When ROI is used to advocate some desired approach, costs tend to be
underestimated, and benefits tend to be overestimated. Use of the term
“justification” is a tip-off, since justification is merely finding arguments to
support a pre-defined answer, rather than providing objective financial
analysis to aid informed decision making, which is what ROI should be. Of course, many prospective buyers disregard vendors’ ROI claims out of hand on the assumption that vendors promise ROIs based on intentionally understated product costs and wildly exaggerated benefits of their proposed product solutions.
The keys to supportable cost and revenue estimates are to obtain the estimate from someone who:
x Is in a position to reliably know the cost and/or revenue impact.
Often, the project manager or analyst charged with calculating ROI
makes their best guess about the costs and revenues. The
operative word is “guess.” Such guesses have little likelihood of
being accurate or believed. It’s important therefore to get the
figures from people who know or should know; and therefore a
credible ROI calculation often includes numbers from several
sources. For instance, a vendor is better qualified to quote prices
for their products than is someone who is less familiar with the
products. A sales manager is better suited to predict effects on the
company’s revenue than is a finance manager, business analyst, or
vendor’s salesperson.
.
x Is aware of the factual factors affecting the costs and/or revenues.
For example, estimates commonly turn out wrong when they are
based on advertised prices for products, because the estimator
may price an inappropriately presumed product solution or product
configuration. The knowledgeable estimator needs to know not just
the product but also the needs it must meet and the circumstances
under which it must operate, since these factors may well
necessitate involving different or additional products/configurations.
For instance, a product which must meet rigorous security
standards probably differs considerably from a similar product that
does not have such demands. In addition, the knowledgeable
estimator may be aware of additional commonly-overlooked cost or
revenue factors, such as the need to periodically replace or
upgrade products and the need to include the cost of capital
invested when buying the product (which some consultants call
“Economic Value Added”).
x Has a reason to provide figures which will hold up. Estimates tend not to be as reliable when the estimator feels no personal
accountability for the estimates’ accuracy. For example, a sales
executive probably will predict different effects on sales depending
on whether or not their bonus depends on achieving the predicted
sales level. Likewise, a vendor may give widely different answers
to the general information question, “What’s it cost?” as contrasted
with the seemingly similar but legally binding, “What price will you
sell it to me for?”
6. Not Realizing Benefits
It’s common for reasonable ROI estimates not to be achieved because
organizations don’t follow through to make the expected benefits come true.
Thus, ROI benefits based on eliminating headcount (employee salaries) will be realized only if those salaries actually are eliminated. Yet, often the
headcount staffing stays the same even after the proposed solution has
been implemented. Usually, retaining the staffing is rationalized on the
premise that the people are now able to do something else.
However, close scrutiny frequently reveals that either what the people now are doing does not add significant value and/or that Parkinson’s Law has
taken effect: Work expands to fill the available time.
For example, systems commonly are justified on the claim that they will
save each of many workers “five minutes a day.” Across enough workers, five minutes a day can add up to a sizeable amount of staff time which then is valued as a payroll cost saving for the ROI calculation at a typical
employee pay rate per hour or day. The fallacy of such calculations is that five minutes from each employee doesn’t actually eliminate any payroll
costs; and unfortunately the company is unlikely to realize any real benefit from all the freed up five minutes.
Many solutions don’t really eliminate costs, but rather merely shift the costs to someone else. Failing to include the shifted costs in an ROI calculation can give an illusion of benefits. Failing to appreciate that the costs haven’t been eliminated indicates an even more serious issue.
For instance, many computer systems shifted data entry from dedicated
back office personnel to being just another responsibility of front office
personnel. In such case, the reductions in back office staffing need to be
balanced with corresponding increases in front office staffing to handle the added duties.
A thornier variation involves shifting the work from employees to customers,
typically in the name of “improved customer service” or “convenience.” For instance, many of us can remember how we used to pay a small fee for a skilled travel agent to spend their time researching travel options and then booking the flights the customer selected. Now, most people book their own travel on the Web.
Objective analysis would show clearly that usually the customer’s employer spent far less for the skilled travel agent’s small fee than by tying up their
employees’ time at their hourly billing rates to book their own travel. The seller’s apparent cost savings from shifting work to customers may need to be offset by loss of customers who resist taking on the added burden. Such an effect has been evident recently in advertisements aimed specifically at attracting away customers who have been alienated by being trapped in
totally automated telephone systems.
Another common case of unrealized benefits involves the widespread belief that reducing headcount of full-time employees is valuable in its own right.
Often, the method for reducing headcount is to replace employed staff with contractors, who typically are the same individuals, just operating under a different payment arrangement. Payroll expenses haven’t been eliminated.
They’ve been shifted to payables.
If the contractors are paid the same amounts they used to make as
employees, which they usually are, there is no saving. Actually, companies generally pay somewhat higher rates for contractors than they paid the
same people as employees. That’s because the contract rates have to
include additional amounts to enable the contractors to obtain the same
types of benefits they used to have as employees, including retirement
plans. While a contracting arrangement often is premised on not having to keep an individual employed, many contractors stay on as long as regular employees. Moreover, when such arrangements are brokered through
some sort of third party consulting firm or placement agency, contract rates are increased further to pay for the agency’s expenses and profit.
7. Separating Out Intangibles, Risk, Opportunity, and Flexibility
Intangibles
Even many ROI consultants assume incorrectly that intangibles cannot be quantified. Typically-cited intangible benefits include customer satisfaction, better management information and more informed decision making, and
various noble or charitable outcomes.
People who believe intangibles cannot be quantified typically create
business cases consisting of two parts: (1) a rigorous quantified ROI
cost/benefit analysis for tangibles, and (2) a qualitative discussion of
intangibles, usually describing mainly benefits, expected to result from the proposed solution. Similar separate treatment approaches often are
followed with respect to other factors which represent variations of
intangibility, such as risk, opportunity, and flexibility.
Failing to quantify supposed intangibles almost always turns seemingly objective financial analysis into subjective justification, where the decision usually is based mainly on the unquantified intangibles. Thus, the seemingly good advice of many supposed experts generally turns the rigorous ROI quantification exercise.into a superfluous waste of time smokescreen, which is essentially ignored in favor of subjective factors. Such an illusory outcome is even more likely for “cost justification,” where intangibles often provide an easy out to justify a predefined answer which hard ROI numbers may not support.
In fact, responsible ROI analysis demands that all factors be quantified in money terms. Whether recognized or not, the decision maker is placing a quantified monetary value on the intangible benefits. Ultimately, the decision is based on comparing the very quantified costs of the proposed solution with the often less-conscious but no less quantified benefits the solution is expected to provide.
Thus, for example, putting a dollar value on relieving pain and suffering may seem impossible and even inappropriate; but every day, health care providers make thousands of such determinations when allocating limited resources among competing demands. While it may seem crass, in actuality, the soundness of the decision is enhanced considerably by making these processes conscious and explicit.
Risk
In similar manner, it’s also common for risk to be discussed separately from the quantified ROI calculations, even though risks should be factored into ROI calculations. Risk exposure is defined as the impact if something goes wrong times the likelihood that it goes wrong.
Risk is often quantified by rating impact and likelihood high, medium, or low and then assigning a weight to each and multiplying. For instance, where high=3, medium=2, and low=1, the quantified risk would be from 1 for low impact and low likelihood to 9 for high impact and high likelihood.
ROI is affected by two types of risks. First, are risks that costs will exceed expectations, which is usually a function of ineffective estimating, which in turn is usually due to inadequately defining REAL business requirements. (For more on understanding the differences between REAL, business requirements and the product/system/software/functional requirements/ specifications people often assume are the requirements, see Robin Goldsmith’s recent Artech House book, Discovering REAL Business Requirements for Software Project Success.)
One can argue that such outcomes are predictable results of ineffective development processes and therefore are not truly risks, since true risk involves some degree of statistical uncertainty.
Second, are risks that benefits will fail to meet expectations. Such risks can occur because the product doesn’t work appropriately, due to of defective design (which again usually traces back to inadequate definition of the REAL business requirements) and/or defective implementation. Related issues include products that don’t adequately address a market need, products which are delivered too late to provide needed benefits, and products that lose out to a superior competitor.
There are three common ways to address risks in ROI calculations: x Apply likelihood percentages. For instance, if a one-month overrun is deemed 50 percent likely, add half a month to the
estimated schedule and add half a month’s work effort to the
estimated cost. One should be very cautious about using such
techniques, since stating percentage likelihood gives a false
appearance of precision unless the percentages are based on
suitable quantified historical information, such as airlines maintain
about key aspects of flight durations and delays, which becomes
part of their determination of how much excess fuel to carry.
x Show best case, most likely case, and worst case scenarios.
Since ROI calculations often are used to support a desired solution,
they frequently reflect the most optimistic “best case scenario,” in
which everything goes right. The likelihood of everything going
right is practically zero; and most people realize ROI calculations
based on the best case are not wise to rely upon. This is one
reason why sales people’s claims are easily ignored, because they
generally are assumed to be, and often are, best case scenarios.
Responsible professionals ordinarily endeavor to describe ROI for
the “most likely scenario,” which when estimated accurately, just by
normal statistical variation will come true somewhat less than half
the time.
Very seldom do estimators present the most pessimistic “worst
case scenario,” in which everything goes wrong. Even those folks
who seem to greet every idea with an almost kneejerk litany of why
“it can’t be done,” seldom actually articulate their fears in financially
quantified terms.
If like most of us, Murphy works on your projects, whatever can go wrong will go wrong; and the worst case scenario is much more of
a possibility than the best case scenario. The weighted average
below takes into account that the worst case usually is more likely than the best case.
Showing all three scenarios essentially shows the range of risks.
PERT prescribes a weighted average which produces a single
number that reflects the risk and is calculated as the:
best case + worst case + 4 x most likely case estimates
6
Note, it’s common for people to simply apply percentages to the most likely estimate to come up with the best and worst case
estimates. Often these percentages are arbitrary and therefore
may be illusory. Also, people frequently apply the same
percentages, thereby assuming the best and worst cases have
equal likelihoods of occurring, which seldom is true.
A more demanding but more accurate method for estimating best,
worst, and most likely case scenarios is to describe each scenario and determine the respective costs and benefits based on the
characteristics of the scenario. This approach is described further in Pitfall #8 below.
x Incorporate mitigation techniques in product and project design. Buildings are equipped with smoke detectors, sprinklers and extinguishers, and fire escapes to reduce the impact if fire
occurs; and buildings are constructed mainly of nonflammable
materials and with various protective mechanisms to reduce the likelihood of fire occurring. Before a building may be used, trained fire experts must inspect the construction to assure it complies with suitable fire safety standards.
Periodically, building occupants may participate in fire drills to
practice emergency procedures in case a fire does occur. The
building owner secures a fire insurance policy covering the
premises. And, we all pay local taxes to assure a fire department will be available to battle any blaze which still may occur.
Just as with buildings and fire risk, it is appropriate to identify
relevant product and/or project risks and include in their design
means of reducing the impact and/or likelihood of those risks
occurring. Common risk mitigation techniques include engaging experts, applying more thorough Quality Assurance and testing, and providing added or fallback capacity.
Opportunity and Flexibility
Several boutique ROI consultants have specialized in methods to address issues of opportunity or flexibility within ROI calculations. While opportunity and flexibility often are treated separately, these are somewhat related
topics, since flexibility is needed to take advantage of opportunities.
At its most basic, opportunity cost is an inherent element in all ROI
calculations. That is, choosing any particular alternative implies forgoing the other alternatives. The opportunity cost of choosing one alternative is what one misses by not choosing another.
As with risk, there is a possible beneficial impact of the unchosen alternative and a likelihood that such a benefit actually would occur were the alternative chosen instead. Thus, one ROI calculation approach involves applying
likelihood percentages to the respective opportunities. Such percentages can be tricky to ascertain at best, and even trickier to factor into a single
ROI calculation. Therefore, it’s usually preferable to describe each
opportunity in a separate scenario, as described in pitfall #8 below.
Ordinarily, though, opportunity in ROI calculations involves issues of
whether or not it is cost-effective to provide the added ability to take certain types of opportunities. For instance, someone contemplating opening a
restaurant could conceivably in the future sell franchises. There could be current considerations that would facilitate or even be necessary to make
such opportunities possible at some future time.
Used in this sense, opportunity is really a form of flexibility, investing now to facilitate change at some future time. Generally, it is most appropriate to
develop and compare the ROIs of scenarios reflecting the various
alternatives, i.e., with and without the specified flexibility.
8. Confusing Scenarios and Deltas
Net annual benefit can be portrayed in two ways: deltas and scenarios. For simple situations, deltas are usually sufficient; but scenarios are necessary to responsibly ascertain ROI of more complicated situations. Often the
hardest part of ROI calculation is knowing how to tell when a delta format is and is not appropriate.
In either format, the return of a proposed solution is determined by
comparing a scenario involving it with a scenario of how things would be
with “No Change,” which also is called Business as Usual (BAU).
Deltas
The delta format focuses only on the differences between the two scenarios, which are presumably attributable to the proposed solution.
For example, consider a function that currently takes ten employees paid a total of $500,000 per year to perform. Assume the proposed solution enables eight employees paid a total of $400,000 per year to perform the same function. The delta is the difference between the costs with and without the proposed solution, or $100,000.
Or, consider a function that currently generates $5,000,000 a year in revenue but will generate $7,500,000 per year when using the proposed solution. Here the delta is the difference in revenue with and without the proposed solution, or $2,500,000.
Take the example one step further and assume that both the cost and revenue changes involve the same function. It’s pretty easy to see that a single delta can take into account both cost and revenue effects of the proposed solution. The $100,000 cost savings plus the $2,500,000 revenue enhancement add up to a combined delta of $2,600,000.
Well, not exactly, since we know from pitfall #4 above that the return should include only the net profit from the added revenue. Assuming a 10 percent profit margin, the net revenue delta would be $250,000, which added to the $100,000 cost saving equals a total delta benefit return of $350,000. Assume we project the benefits over a five-year useful life and factor in annual inflation of five percent and annual growth of ten percent. Even with such a somewhat more complicated calculation, a single delta could be calculated that would suitably convey the full story.
Deltas are the simplest and easiest to understand format for portraying return on investment. Deltas seem intuitive and are probably the most commonly used format. Most commercial ROI calculators portray deltas, including https://www.doczj.com/doc/9813179727.html,’s powerful ROI Value Dashboard? for graphically showing in real time how changes in customer-defined key variables affect a proposed solution’s ROI.
For most purposes, including many sales situations describing the financial benefits of a proposed product, such delta calculators are sufficient. Delta calculations almost always focus on a relatively small number of factors, which can be suitable when the 80-20 rule applies. The 80-20 rule says that 20 percent of the factors account for 80 percent of the value.
In many ROI calculations, reduction in headcount salary expenses and/or increases in sales revenues are the overwhelmingly determinative factors affected by the proposed solution. Many commercial calculators essentially deal mainly with these two variables.
If the calculator addresses the most important 20 percent of the variables, a large indicated return generally would be assumed to be characteristic of the other variables; and even if not, it would be deemed adequate to offset any contrary effects of the less controlling variables that weren’t included in the calculation.
Deltas are not appropriate for all situations:
x When the projected benefits are small, it is more important to also take into account the other 80 percent of the variables that
ordinarily are not included in delta calculations.
x When a simple set of variables having major impacts from the proposed solution are not readily apparent, such as often occurs
when benefits are largely intangible.
x When several alternatives must be compared, especially when each alternative has somewhat different cost and revenue effects.
Thus, a single delta may be appropriate for a vendor to show the
benefit of their product relative to Business as Usual; but deltas
may not suffice to meaningfully compare multiple proposed
products.
x When numerous costs and/or revenues are impacted in complex ways, which often is the case when deciding among strategies. Scenarios
The more comprehensive but more complicated method is to calculate a complete separate scenario describing the full set of costs and revenues associated with each alternative. Each alternative’s scenario is developed by itself without reference to any other alternative’s scenario, but then is compared to each of the other alternatives, including the Business as Usual scenario.
For the example used above to show deltas, the Business as Usual scenario has costs of $500,000, revenues of $5,000,000, and cost of sales of $4,500,000 per year for a net benefit of $0. The proposed solution scenario has costs of $400,000 revenues of $7,500,000, and cost of sales
of $6,750,000 per year for a net benefit of $350,000. Note, the profit margin reflects the difference between the revenue and the costs of producing the revenue (cost of sales).
The proposed solution scenario’s net benefit exceeds the Business as
Usual scenario’s net benefit by the same $350,000 seen in the delta format example. As with the delta example, each scenario’s annual figures could
be extended over the full useful life and reflect annual changes due to
inflation and growth. For this simple example, either the delta or scenario
format would be suitable.
As alternatives’ revenue and expense effects become more complex, deltas become less and less suitable; and scenarios increasingly become
necessary to accurately represent net annual benefits over the useful life.
In order to define a full scenario, it is essential to have a thorough
understanding of how the scenario will operate and recognize all of its
impacts on revenues and expenses. Thus, when elaborating separate
scenarios for best case, worst case, and most likely case, it’s common to
realize that different variables may be affected and in different ways in each scenario. For instance, worst case could include warranty costs and actual reduction in sales, whereas best case would only see sales increases.
To provide comparability, all scenarios should address the same set of
revenue and expense variables, even if the variable is not specifically
affected by the individual scenario.
Frankly, most people (including, we fear, many supposed ROI experts) are not skilled at accurately defining the full scenario financial effects of
respective alternatives. That’s a major reason why intangibles are so
seldom quantified.
9. Not Matching Actuals to Estimates
As with project estimates in general, few organizations accurately measure what actually happens; and even fewer compare what actually happens to
what they expected (estimated). Without grounding in actuality, ROI and
other estimates have a habit of rapidly and continually diverging from reality.
The purpose of financial and nonfinancial estimates is to guide decision
making as reliably as possible, realizing that estimates of the future carry an inherent degree of uncertainty. Where the process does not provide means to periodically assess and address that uncertainty, the process very quickly becomes certain to be unworthy as a basis for decisions.
Conversely, matching actuals to estimates provides a means for
establishing a degree of confidence in the estimates’ accuracy; and
furthermore it provides a way to continually improve the accuracy of
estimates, including ROI calculations..
10. Not Addressing the Right Variables People Really Value
Pretend for the moment that you sell a product which dramatically reduces the costs of operating and maintaining apartment buildings. People who
currently own or are considering owning an apartment building probably
would find your product valuable. On the other hand, other people probably would not care how much your product saved, because they wouldn’t be in
a position to realize those savings.
Talk about no-brainers! It should go without saying that ROI financial
benefits must relate to what the customer or decision maker values.
Yet, in a surprisingly large number of instances, the benefits stressed in ROI business cases are not addressing what is really valued. By definition, this type of disconnect almost always occurs when intangibles are not
quantified; and it’s often a main reason why ROI calculations are not
persuasive.
Failure to address what customers truly value is also a major, though
seldom recognized, reason why products don’t sell as much, or at as high prices, as sales people want and expect.
Most sales training emphasizes knowledge of the product being sold. Often only lip service is paid to understanding the needs of the prospective
customer, and then mainly from the perspective of the product. Similarly, most sales messages tout product features and assume the features will
strike a chord with prospects. That’s not a wise assumption.
When prospects don’t respond to sales messages, it may well indicate that what the sales person values is not what the prospective customer values.
Describing the product features’ supposed benefits in financial terms
doesn’t change a fundamental disconnect.
For a business case and its ROI calculations to be persuasive, they must
describe benefits the recipient customer or decision maker truly values.
Often it is not easy to ascertain what is truly valued, but it is easy to assume that it’s whatever you think should be valued. That’s a deep trap into which many conventional ROI analyses frequently fall, even when guided by
supposed experts.
On the other hand, https://www.doczj.com/doc/9813179727.html,’s ROI Value Modeling? methodology uses
x Powerful Problem Pyramids? to identify the REAL, business requirements that the prospective customer or decision maker truly
values.
x ROI Value Maps? that link the proposed solution’s differentiating features to what is truly valued.
x ROI Value Dashboards? and/or ROI Value Scenarios? which understandably and professionally present objective financial
analyses of quantified tangibles and intangibles.
Robin F. Goldsmith, JD speaks frequently at leading conferences, presents both public and in-house seminars, and is the author of numerous articles and the recent Artech House book, Discovering REAL Business Requirements for Software Project Success.
Since 1982, as President of Go Pro Management, Inc. consultancy of Needham, MA, Robin has provided senior professional advisory assistance working directly with and training business and systems managers and professionals. Robin specializes in quickly and insightfully understanding his client's REAL business requirements, utilizing operational and financial measurements to achieve more effective and efficient management processes, and improving software development/acquisition quality, testing, and productivity.
Anthony Sarno is the Founder and President of https://www.doczj.com/doc/9813179727.html,, LLC, a value-focused software and technology services company providing ROI and sales optimization tools and assistance.
Prior to founding https://www.doczj.com/doc/9813179727.html,, Mr. Sarno created and executed structured software architecture and acquisition methodologies for industry leading companies including; Coca-Cola, Johnson & Johnson, American Family Insurance, IBM and EDS. Mr. Sarno has also designed and developed field force administration applications for Bellcore.
计算器 项目内容：编写一个Applet，模仿windows附件所带计算器的功能，可以帮助用户完成计算功能，具体如下图所示。 项目要求：使用图形的方式借助窗口、菜单、按钮等标准界面元素和鼠标操作，来帮助用户方便地向计算机系统发出命令，启动操作，并将系统运行的结果同样以图形的方式显示给用户，这样更加直观和生动； 1.Applet容器中组件的添加与设置，包括面板以及菜单的使用； 2.容器中组件的布局管理； 3.Java核心包中数组、数学计算类的使用； 4.异常的处理； 5.事件处理模型中的三类对象的使用： 1.Event-事件，用户对界面操作在java语言上的描述，以类的形式出现，例如键盘操作对应的事件类是KeyEvent。 2.Event Source-事件源，事件发生的场所，通常就是各个组件，例如按钮Button。 3.Event handler-事件处理者，接收事件对象并对其进行处理的对象。 6.程序中事件处理的流程：
1.计算流程的细化 参考代码： import .*;
import .*; import .*; import import import public class Calculator implements ActionListener { #############"); dd(panel); panel1 = new JPanel(); panel2 = new JPanel(); (new BorderLayout()); 键入计算的第一个数字。\n"); ("2. 单击“+”执行加、“-”执行减、“*”执行乘或“/”执行除。\n"); ("3. 键入计算的下一个数字。\n"); ("4. 输入所有剩余的运算符和数字。\n"); ("5. 单击“=”。\n"); aboutCal = new JMenuItem(" 关于计算器(A)"); (this);
C/C++程序设计课程设计设计说明书 简单计算器的设计与实现 学生姓名 学号 班级 成绩 指导老师 计算机科学与技术系 2010年11月22日
C/C++程序设计课程设计评阅书
课程设计任务书 2010—2011学年第一学期 专业：计算机科学与技术学号：姓名： 课程设计名称： C/C++程序设计课程设计 设计题目：简单计算器的设计与实现 完成期限：自2010 年 11月 15 日至 2010 年 11 月 26 日共2 周 设计内容及要求： 要求用C/C++语言设计一个简易的计算器程序，对输入的数据进行加、减、乘、除、开平方等操作。 设计要求及功能如下： 1.阐述设计思想，画出流程图； 2.实现功能： （1）对输入的数据进行加法运算； （2）对输入的数据进行减法运算； （3）对输入的数据进行乘法运算； （4）对输入的数据进行除法运算； （5）对输入的数据进行开平方根运算。 最终设计成果形式为： 1.编写好的程序； 2.撰写课程设计说明书一份，打印并装订成册。 指导教师（签字）：教研室主任（签字）： 批准日期：年月日
摘要 设计了一个简单的计算器程序，该计算器具有简单的四则混合运算以及复杂的数学表达式的功能。该计算器采用VC++作为软件开发环境，采用算数表达式处理算法来实现加、减。乘、除四则混合运算。操作简单，界面清晰，易于用户使用，容易被他们所接受的。 关键词：计算器；VC++；数学表达式
目录 1课题描述 (1) 2问题分析和任务制定 (2) 3详细设计 (3) 3．1头文件设计 (3) 3．2简单计算器的设计与实现函数设计 (3) 4 程序调试与测试 (8) 4．1主界面测试 (8) 4.2基本功能的测试 (8) 5结果分析 (12) 总结 (13) 参考文献 (14)
Xx大学计算机与电子 信息学院《移动编程 技术》安卓程序开发 设计报告---简单计算 器 《安卓开发》程序设计报告 题目简单计算器开发 专业(班级) 网工111班 姓名张波波 学号952937885（qq） 指导教师赵（老师） 日期2014.5.7
目录 一、设计说明： (3) 1.设计内容：Android简单应用程序开发，简单计算器。 (3) 2程序说明： (3) 二、开发环境： (3) 三、概要设计： (3) 3.1 系统的总体 (3) 四、程序流程和系统功能设计 (4) 4.1程序流程设计 (4) 4.2.系统功能设计 (5) 4.3基于Android平台系统具体设计 (6) 4.3.1 总体模块详细设计 (6) 4.3.2 输入模块详细设计 (6) 4.3.3 显示模块详细设计 (7) 4.3.4 计算模块详细设计 (7) 五、计算器系统实现 (8) 5.1 Android应用程序构成 (8) 六、截图说明 (9) 1、图标 (9) 2界面 (10) 3运算界面 (11) 4错误输入 (11) 5设计平台界面 (12) 6签名导出apk (12) 七、总结 (13)
课程设计任务书 一、设计说明： 1.设计内容：Android简单应用程序开发，简单计算器。 2程序说明： 1、计算器界面友好，方便使用。 2、具有基本的加、减、乘、除功能，还有+—、开方、平方功能。 3、能够判断用户输入运算数是否正确。 4、 4、支持小数运算。 5、具有退格功能，能够删除最后一个输入，ce。 6、具有清除功能，删除所有，c。 7、具有结果存储功能，能够显示存储器状态，支持触屏手机。 8、支持最低版本2.0，最高版本4.4。开发时为4.2 二、开发环境： 开发环境：本系统是采用Eclipse+EclipseMe+JDK+ADT作为开发平台。事实上为了节约时间就直接用Google公司安给的直接绑定好的adt-bundle-windows-x86_64开发，只需要配置下环境变量，无需要关联等操作。 三、概要设计： 3.1 系统的总体 整个程序基于android技术开发，出总体模块外主要分为输入模块、显示模块以及计算模块（包括一些其她功能）这三大部分。在整个系统中总体模块控制系统的生命周期，输入模块部分负责读取用户输入的数据，显示模块部分负责显示用户之前输入的数据以及显示最
项目一简易计算器 项目要求： C语言具有功能强大，灵活，可移植性好等特点，可用其开发各类应用系统。本项目要求用C语言完成一个简易计算器的开发。相关要求如下： 1.能够实现两个数的算术运算功能（加、减、乘、除）。即依次输入第一个操作数、运算符、第二个操作数，然后输出运算结果。 例如：输入：2 + 5 输出：2+5=7 2.能实现单运算符表达式运算功能。 例如：输入：13*8 输出：13*8=104 3.开发工具与运行环境。 ●操作系统：windows xp/2000/ME等。 ●开发工具：VC++ 6.0。 4.附加功能。 ●实现各类进制之间的转换，输入/输出格式根据个人理解确定； ●带函数功能； ●良好的操作界面与提示信息。 教学目标： 1.能力目标。
●进一步熟悉自顶向下，逐步细化的程序设计方法； ●掌握结构化程序开发过程。 2.知识目标。 ●函数的定义、说明、调用方法； ●局部变量、全局变量的概念。 3.核心能力目标。 ●成员之间的交流沟通能力； ●成员之间的协调配合意识与能力。 教学方法： 1．直观教学法。将需要完成的简易计算器展示给各位同学，演示各项功能。启发学生思考系统的整体结构与模块划分和各个功能的实现方法，调动学生学习的积极性与主动性。 2．学法。（1）模仿练习；（2）通过网络查找其它计算器的功能及实现方法，小组讨论改善系统功能，力求实现更多的功能。 课时及教学环境： 1．课时：课内8+课外8； 2．教学环境：机房+网络。 项目实施前准备： 复习C语言的基本数据类型，运算符，表达式，基本语句，上网查找与计算器相关的资料，了解软件系统开发的过程。 引导文（函数）： 函数是实现模块化设计的基础，C语言中用函数来实现模块功能。C语言函数分为两
import javax.swing.*; import java.awt.event.*; import java.awt.*; import https://www.doczj.com/doc/9813179727.html,ng.Math; class ring extends JFrame implements ActionListener { //定义成员变量： //JFrame frame;//定义一个窗口类； JTextField text;//定义一个文本框类； JLabel label;//定义一个标签类； JPanel p1,p2,p3,p4,p5,p6;//定义面板类； String s1,s,s2;//定义三个字符串变量； int count=0; JButton a1,a2,a3,a4,a5,a6,b1,b2,b3,b4,b5,b6,c1,c2,c3,c4,c5,c6,d1,d2,d3,d4 ,d5,d6; //ring的构造函数； ring() { this.setTitle("计算器"); // super("计算器"); JMenuBar menubar1=new JMenuBar();//新建菜单条； this.setJMenuBar(menubar1); JMenu menu1=new JMenu("编辑(E)"); JMenu menu2=new JMenu("查看(V)"); JMenu menu3=new JMenu("帮助(H)"); menubar1.add(menu1); menubar1.add(menu2); menubar1.add(menu3); JMenuItem item1=new JMenuItem("复制(c) ctrl+c"); JMenuItem item2=new JMenuItem("粘贴(p) ctrl+v"); JMenuItem item3=new JMenuItem("标准型(T)"); JMenuItem item4=new JMenuItem("科学型(s)"); JMenuItem item5=new JMenuItem("数字分组(I)"); JMenuItem item6=new JMenuItem("帮助主题(H)"); JMenuItem item7=new JMenuItem("关于计算机(A)"); menu1.add(item1); menu1.add(item2); menu2.add(item3); menu2.add(item4); menu2.add(item5); menu3.add(item6);
第02讲计算器 2.1 计算器简介 大家都知道，计算器是日常生活中不可缺少的一个工具，在Microsoft的Windows操作系统中，附带了一个计算器程序，有标准型和科学型两种模式。Windows XP下的标准型和科学型计算器程序分别如图2-1和图2-2所示。 图2-1 Windows XP下的标准型计算器 图2-2 Windows XP下的科学型计算器 Windows操作系统下附带的计算器程序功能相当的强大，本课我们将模仿Windows的计算器，使用Visual C# 2005开发平台开发一个功能相对简单的计算器应用程序，它能完成加、减、乘、除运算。 接下来详细的介绍简易计算器的设计方法和步骤。
2.2 界面设计及属性设置 用户界面设计是软件开发中非常重要的一个部分，用户界面的好坏直接影响软件的质量，本节将介绍如何设计简易计算器的用户界面以及界面上各控件的属性设置。 2.2.1 界面设计 打开Visual Studio 2005开发工具，新建一个Windows应用程序，然后在窗体上依次放置1个TextBox和17个Button控件，如图2-1所示（设置好属性后）。 图2-1 计算器用户界面 2.2.2 属性设置 窗体和各控件的属性设置如表2-1所示。 表2-1 窗体和各控件的属性
2.3 编写代码 本程序需要用到一些公共变量，例如用来接收操作数、运算结果，判断输入的是否为小数等，因此首先在代码的通用段声明以下变量： //****************************************************************** double num1, num2, result; // 操作数及运算结果 bool decimalFlag = false; // 判断输入的是否为小数 string myOperator; // 操作类型 //******************************************************************
用java写了一个简单计算器，能实现简单的数据计算。 一、先写界面代码： 在UI包里面新建一个Class文件，取名自己想，这里我写的是CalculatorFrame package ui; import java.awt.Color; import java.awt.Font; import java.awt.GridLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.JOptionPane; import javax.swing.JPanel; import javax.swing.JScrollPane; import javax.swing.JTextArea; import javax.swing.border.TitledBorder; public class CalculatorFrame extends JFrame { private static final long serialV ersionUID = 1L; public String opt; public String str; private JTextArea show; private ClientContext clientContext;//引用控制器对象 /*因为调用了控制器里面的方法，所以要对控制器的对象进行赋值，否则运行会出现空指针异常*/ public void setClientContext(ClientContext clientContext) { this.clientContext = clientContext; } public CalculatorFrame() { init(); } private void init() { setTitle(" Simple Calculator"); setBounds(533, 184, 300, 400); setContentPane(creatContentPane()); }
.net 框架编程技术实验报告 实验名称: 计 算 器 姓 名： 龙 会 中 学 号： 201217010141 专业班级： 计科12101班 指导教师： 屠添翼 设计时间： 2014年11月2日 评阅意见： 评定成绩： 指导老师签名： 年 月 日
实验一简单计算器的开发 一、实验目的 1）熟悉VS2005编程环境； 2）了解Windows应用程序编程的基本步骤； 3）熟悉组件文件的开发和引用操作。 二、实验内容及要求 1）设计和创建一个简单的计算器，要求能够进行＋、－、×、/、sqrt、1/x 等计算； 2）应用程序界面如图1-1。 图1-1 计算器界面 三、实验重点 1）业务逻辑的封装； 2）界面逻辑的设计与实现 四、实验环境 Windows2000、VS2005。 五、实验代码 using System; using System.Collections.Generic; using https://www.doczj.com/doc/9813179727.html,ponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms;
namespace Calculator { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void Number0_Click(object sender, EventArgs e) { var button = sender as Button; if (number == "0") number = button.Text; else number += button.Text; Result.Text = number; } private void Clear_Click(object sender, EventArgs e) { number = "0"; Result.Text = number; operation = null; } private Operation.Operation operation; private string number; private void Add_Click(object sender, EventArgs e) { if (operation != null) { operation.NumberB = Convert.ToDouble(number); number = operation.GetResult().ToString(); Result.Text = number; } var button = sender as Button; operation = Operation.OperationFactory.createOperate(butt https://www.doczj.com/doc/9813179727.html,); operation.NumberA = Convert.ToDouble(number); number = "0"; }
《.NET框架编程技术实验》 单位：计算机学院 教师：屠天翼 时间：2014.11 课程名称.NET框架编程技术实验 实验名称简单计算器的开发 专业班级计算机学院计科专业12级计科2班姓名曹科 学号201217010207 授课时间2014学年下学期
一、实验目的 1）熟悉VS2005编程环境； 2）了解Windows应用程序编程的基本步骤； 3）熟悉组件文件的开发和引用操作。 二、实验内容及要求 1）设计和创建一个简单的计算器，要求能够进行＋、－、×、/、sqrt、1/x 等计算； 2）应用程序界面如图1-1。 图1-1 计算器界面 三、实验重点 1）业务逻辑的封装； 2）界面逻辑的设计与实现 四、实验环境 Windows2000、VS2005。 五丶代码 using System; using System.Collections.Generic; using https://www.doczj.com/doc/9813179727.html,ponentModel; using System.Data; using System.Drawing;
using System.Linq; using System.Text; using System.Windows.Forms; namespace WindowsFormsApplication2 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { } private void button1_Click(object sender , EventArgs e) {
“移动应用开发”实验报告 1
而受至到众多开发者的欢迎，成为真正意义上的开放式操作系统。计算器通 过算法实行简单的或学计算从而提高了数学计算的效率，实现计算器的界面 优化，使界面更加友好，操作更加方便。基于android的计算器的设计系统具 有良好的界面；必要的英互信息：简约美观的效票，使用人员能快捷简单地 进行操作，即可单机按钮进行操作，即时准确地获得需要的计算的结果，充 分降低了数字计算的难度和节约了时间。 2.系统概要设计 2.1计算器功能概要设计 根据需求，符合用户的实际需求，系统应实现以下功能：计算器界面友好， 方便使用，具有基本的加，减，乘，除功能。能够判断用户输入运算数是否 正确，支持小数运算，具有清除功能。 整个程序基于Android 技术开发，除总体模块外主要分为输入模块、显 示模块以及计算模块这三大部分。在整个系统中总体模块控制系统的生命周期，输入模块部分负责读取用户输入的数据，显示模块部分负责显示用户之 前输入的数据以及显示最终的计算结果，计算模块部分负责进行数据的运算 以及一些其他的功能。具体的说，总体模块的作用主要是生成应用程序的主类，控制应用程序的生命周期。 输入模块主要描述了计算器键盘以及键盘的监听即主要负责读取用户的 键盘输入以及响应触屏的按键，需要监听手机动作以及用指针事件处理方法 处理触屏的单击动作。同时提供了较为直观的键盘图形用户界面。 显示模块描述了计算器的显示区，即该区域用于显示用户输入的数据以 及最终的计算结果，同时负责显示一些其他的信息。 计算器模块主要描述了计算器的整体，实现了计算器的界面，负责用户 2
输入数据，计算，显示，清零等功能。 2.2输入模块设计 系统如果想完成计算器中各种功能，首先用户要能进行数据输入，由于 是在触屏手机上开发计算器程序，所以要求输入可以直接使用触屏进行，所 以在设计的时候就要充分的考虑这一点。正是由于考虑到这个特殊的地方， 所以在进行模块设计中，选择编写输入模块类的时候会特意选取使用可以支 持触屏输入的特殊增强型图形用户界面类。 输入模块主要的任务是描述计算器键盘以及实现键盘的监听，即当用户 点击按键或者屏幕的时候监听会去调用相应的处理办法，本模块还需要为系 统提供一个较为直观的键盘图形用户界面。输入模块的功能图如图 2.3显示模块设计 作为手机计算器系统，显示部分也是必不可少的一部分。没有显示部分 就没有办法显示用户输入的数字是否正确，甚至不能显示计算出的结果，由 此可见显示模块即包括输入的部分（因个人技术原因不能显示表达式的形式）也包括输出的部分。 显示模块主要完成的任务是描述计算器的显示区，该区域用于显示用户 输入的数据以及最终的计算结果和一些其他信息。同时本模块还将提供调用 和设置显示的具体方法。 3
import java.awt.BorderLayout; import java.awt.Color; import java.awt.GridLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.KeyEvent; import java.awt.event.KeyListener; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.JPanel; import javax.swing.JTextField; /*使用java 语言开发一个简易计算器 * * */ public class TestJsq extends JFrame implements ActionListener, KeyListener { private JTextField jtf; private JButton jb_bk, jb_ce, jb_c; private String xs = ""; private double sum = 0; private int fh; public static void main(String[] args) { new TestJsq().creatCUI(); } public void creatCUI() { JFrame jf = new JFrame(); jf.setTitle("计算器"); jtf = new JTextField("0."); jtf.setHorizontalAlignment(JTextField.RIGHT); jf.add(jtf, BorderLayout.NORTH); JPanel jp_main = new JPanel(new BorderLayout()); jf.add(jp_main); JPanel jp1 = new JPanel(new GridLayout(1, 3, 1, 1)); jb_bk = new JButton("Backspace"); jb_bk.setForeground(Color.RED); jb_bk.addActionListener(this); jb_ce = new JButton("CE"); jb_ce.setForeground(Color.RED);
JAVA实验报告——简单计算器的编写 班级： 学号： 姓名：
一、实验目的 1.掌握java图形用户界面（GUI)的设计原理和程序结构 2.能设计复核问题要求的图形用户界面程序 3.掌握常用组件的事件接口 4.应用awt和swing组件进行应用程序设计 二、实验条件 1.计算机一台 2.java软件开发环境 三、实验步骤 1、编写代码： mport java.awt.*; import java.awt.event.*; import javax.swing.*; public class JCalculator extends JFrame implements ActionListener { private static final long serialVersionUID = -169068472193786457L private class WindowCloser extends WindowAdapter { public void windowClosing(WindowEvent we) { System.exit(0); } }
int i; private final String[] str = { "7", "8", "9", "/", "4", "5", "6", "*", "1", "2", "3", "-", ".", "0", "=", "+" }; JButton[] buttons = new JButton[str.length]; JButton reset = new JButton("CE"); JTextField display = new JTextField("0"); public JCalculator() { super("Calculator"); JPanel panel1 = new JPanel(new GridLayout(4, 4)); for (i = 0; i < str.length; i++) { buttons[i] = new JButton(str[i]); panel1.add(buttons[i]); } JPanel panel2 = new JPanel(new BorderLayout()); panel2.add("Center", display); panel2.add("East", reset);
AStack.h #ifndef ASTACK_HEADER #define ASTACK_HEADER #include
}; #endif Function.cpp #include "function.h" #include "AStack.h" #include 开发一个简单科学计算器 （基于对话框模式的应用程序） 一. 开发目标及软件功能 开发一个科学计算器程序，要求采用基于对话框模式的应用程序，至少具有加、减、乘、除四个基本功能，并在此基础上扩展平方、开方、三角函数等功能。 （1）仔细阅读操作过程，学习如何根据编译信息，定位语法错误。 （2）将警告与错误一律看作是错误。 （3）学习并模仿书上的程序书写风格。 二. 编程步骤 1. 启动Visual C++6.0，选择File | new 菜单项，弹出New 对话框。单击Projects 选项卡，项目类型选择MFC AppWizard(exe)，在Project name中填入工程名，在Location中填用户子目录路径（设置用户程序子目录的目的是，将所有编程时产生的中间文件和最终执行程序文件全部放在自己的目录中，以便管理）。 2. 在程序向导的第1步选择建立一个基于对话框（Dialog based）的应用程序，点击“Finish”结束向导。 3. 在对话框上添加各类控件，设计对话框的界面如图所示。在对话框中右键点击，弹出属性设置对话框（Dialog Properties），标题（caption）中填入“迷你计算器”；其余各控件的参数设置如下表所示。 控件类型ID号Caption 其它 Button IDC_ADD ＋ Button IDC_SUB － Button IDC_MUL × Button IDC_DIV / Button IDC_SIN sin Button IDC_COS cos Button IDC_SQU x^2 Button IDC_REC 1/x Button IDC_EQUAL = Edit Box IDC_FIRST Edit Box IDC_SECOND Edit Box IDC_RESULT 4. 为对话框中的控件添加相应的成员变量：点击菜单“View →ClassWizard”，点击“Member Variables”标签项，为对话框中的三个编辑框控件添加对应的成员变量如图所示。 添加成员变量的步骤为：选中“IDC_FIRST”，点击“Add Viarable”，在弹出的对话框中，指定成员变量名为“m_first”，分类为“Value”，变量类型为“double”，点击“OK”确 简单计算器的开发 假设有这么一个问题：请用C++、Java、C#任意一种面向对象程序设计语言实现一个计算器控制台程序，要求输入两个数和运算符号，得到结果。你会怎么写？下面以C#为例说明。 一、看下面一个程序： class Program { static void Main(string[] args) { Console.Write("请输入数字A："); string A = Console.ReadLine(); Console.Write("请选择运算符号(+、-、*、/)："); string B = Console.ReadLine(); Console.Write("请输入数字B："); string C = Console.ReadLine(); string D = ""; if (B == "+") D = Convert.ToString(Convert.ToDouble(A) + Convert.ToDouble(C)); if (B == "-") D = Convert.ToString(Convert.ToDouble(A) - Convert.ToDouble(C)); if (B == "*") D = Convert.ToString(Convert.ToDouble(A) * Convert.ToDouble(C)); if (O == "/") D = Convert.ToString(Convert.ToDouble(A) / Convert.ToDouble(C)); Console.WriteLine("结果是：" + D); } } 二、代码是否规范、重构 class Program { static void Main(string[] args) { try { Console.Write("请输入数字A："); string strNumberA = Console.ReadLine(); Console.Write("请选择运算符号(+、-、*、/)："); string strOperate = Console.ReadLine(); Console.Write("请输入数字B："); string strNumberB = Console.ReadLine(); string strResult = ""; switch (strOperate) { case "+": strResult = Convert.ToString (Convert.ToDouble(strNumberA) + Convert.ToDouble(strNumberB)); break; case "-": using System; using System.Collections.Generic; using https://www.doczj.com/doc/9813179727.html,ponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace简易计算器 { public partial class Form1 : Form { //定义变量 private int iPrevValue = 0;//上一次值 private bool bAppend = true;//确定按下数字键后是否和上次的相连，默认为相连private string strPrevOpt = "";//上次按下的操作符号 public Form1() { InitializeComponent(); } private void Num_click(object sender, EventArgs e)//数字按钮关联事件 { string strNum = ((System.Windows.Forms.Button)sender).Text; if (bAppend) { textBox1.Text = int.Parse(textBox1.Text + strNum).ToString(); } else { textBox1.Text = strNum; bAppend = true; } } private void btn_clear_click(object sender, EventArgs e)//C操作符事件 { textBox1.Text = "0"; bAppend = true; iPrevValue = 0; strPrevOpt = ""; } private void Opt_click(object sender, System.EventArgs e) { if (textBox1.Text != "") { int iCurValue = int.Parse(textBox1.Text);//得到当前显示的值 switch (strPrevOpt) { case"+": iCurValue += iPrevValue; break; case"-": iCurValue = iPrevValue - iCurValue; break; case"*": iCurValue *= iPrevValue; break; case"/": iCurValue = iPrevValue / iCurValue; break; default: break; } strPrevOpt = ((Button)sender).Text; bAppend = false; textBox1.Text = iCurValue.ToString(); iPrevValue = iCurValue; } } } 计算器设计报告简易计算器的设计报告 计算器的设计 1概述 1.1 课程设计目的 1、巩固并加深学生对C++语言程序设计知识的理解； 2、培养学生面向对象的程序设计思想，使学生认识面向过程和面向对象两种设计方法的区别； 3、进一步掌握和应用VC++ 6.0集成开发环境； 4、提高运用C++语言解决实际问题的能力； 5、初步掌握开发小型实用软件的基本方法，能独立设计、实现基本的MIS系统； 6、掌握书写程序设计开发文档的能力（书写课程设计实验报告）。 1.2 课程设计内容 课题名称：计算器的实现 说明：实现一个计算器。 要求： 用“计算器”的标准视图执行简单的计算。 3 四则代码如下 void CCALDlg::OnButtonequal() { // TODO: Add your control notification handler code here UpdateData(TRUE); num2 =m_str; if(num2==0&&ope==3) { m_str1="除数不能为零"; m_str =0; num1 = 0; num2 = 0; UpdateData(FALSE); } else{ // int f = 0; switch (ope) { //加 case 0: m_str = num1 + num2; peak; //减 case 1: m_str = num1 - num2; peak; 5 4系统详细设计 4.1 设计步骤 打开Microsoft Visual C++ 6.0,在文件中点击新建，在弹出框内选择MFC AppWizard[exe]工程，输入工程名yeyahui及其所在位置，点击确定，如图4- 1所示。 图4-1 新建MFC AppWizard[exe]工程 将弹出MFC AppWizard-step 1对话框，选择基本对话框，点击完成，如图4-2所示。 7 图4-3新建的对话框 4.2 界面设计 界面设计主要是创建控件，在图4-3所示的Resoure View选项卡中打开Dialog资源组，双击IDD_ZHOUTONG_DIALOG，在右边的窗口中显示出待编辑的对话框。开始摆放控件，包括编辑框和按钮的创建。按钮的创建以“1”为例进行介绍，其他按钮的创建可参照此进行操作。 1）在图4- 3中Controls的“编辑框”按钮上单击鼠标左键，在对话框编辑窗口上合适的位置按下鼠标左键并拖动鼠标画出一个大小合适的编辑框。在编辑框上单击鼠标右键，在弹出的快捷莱单中选择属性选项，此时弹出Edit属性对话框，如图4-4所示，在该对话框中输入ID属性。 9 图5-1 四则运算，乘法测试结果图 13 附录 附录1 源程序清单 // 计算器Dlg.cpp : implementation file // #include "stdafx.h" #include "CAL.h" #include "CALDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CAboutDlg dialog used for App About class CAboutDlg : public CDialog { public: CAboutDlg(); // Dialog Data //{{AFX_DATA(CAboutDlg) enum { IDD = IDD_ABOUTBOX }; //}}AFX_DATA import java.awt.*; import java.awt.event.*; import javax.swing.*; import java.util.Vector; public class Tuo { String str1="0"; //运算数1 初值一定为0 为了程序的安全 String str2="0"; //运算数2 String fh="+"; //运算符 String jg="";//结果 //状态开关重要 int k1=1;//开关1 用于选择输入方向将要写入str2或str2 int k2=1;//开关2 符号键次数k2>1说明进行的是2+3-9+8 这样的多符号运算int k3=1;//开关3 str1 是否可以被清0 ==1时可以!=1时不能被清0 int k4=1;//开关4 str2 同上 int k5=1;//开关5 控制小数点可否被录入==1时可以!=1 输入的小数点被丢掉JButton jicunqi; //寄存器记录是否连续按下符号键 Vector vt=new Vector(20,10); JFrame frame=new JFrame("sunshine---计算器"); JTextField jg_TextField=new JTextField(jg,20);//20列 JButton clear_Button=new JButton("清除"); JButton button0=new JButton("0"); JButton button1=new JButton("1"); JButton button2=new JButton("2"); JButton button3=new JButton("3"); JButton button4=new JButton("4"); JButton button5=new JButton("5"); JButton button6=new JButton("6"); JButton button7=new JButton("7"); JButton button8=new JButton("8"); JButton button9=new JButton("9"); JButton button_Dian=new JButton("."); JButton button_jia=new JButton("+"); JButton button_jian=new JButton("-"); JButton button_cheng=new JButton("*"); JButton button_chu=new JButton("/"); JButton button_dy=new JButton("="); //////////////////////////////////////////////////////////////////////// public static void main(String[] args) {最新开发一个简单计算器程序-基于对话框
简单计算器的开发
C#编写的简易计算器
计算器设计报告 简易计算器的设计报告.docx
java编写的简单计算器代码
相关主题
文本预览