LOG 330 Travail Pratique

1

Business Models

Their risks and Practices to minimize risks

Source: The source will be disclosed after the exercise is completed

Instructions

1. Read the text describing the business models (below)
2. Read the Situational Factors that define the environment in which business models.
3. Study Table 1 (at the end of this text), which describes the business model 'Custom Systems Written on Contract', situational factors, fears and practices in place to minimize the fears and risks.
4. Choose a business model (except the model Custom Systems Written on Contract), as a team, and give an example of this business model.
5. Discuss into teams and identify the elements that complete the description of the business model: the characteristics, fears / risk business model chosen and practices in place to minimize his fears/risk.
6. Fill in the template (Table 2) at the end of this text.

Business models – How we make money

• Custom systems written on contract: We make money by selling our services to write other people’s software.
• Custom systems written in-house: We make software to make our own business run better.
• Commercial products: We make money by writing and selling software to other businesses.
• Mass-market software: We make money by writing and selling software to consumers
• Commercial and mass-market firmware: We make money by selling objects which happen to require embedded software.

Custom Systems Written on Contract

In a fixed-bid contract, the customer specifies exactly what they want and promises a fixed sum of money to the vendor. The vendor’s profit depends on staying within budget and delivering a product that works as specified. Large business applications and military software are frequently written on contract, so the typical product in this practice culture is either business-critical or life-critical. The cost of distributing post-release fixes is manageable because fixes are distributed to a known, accessible, and reasonably sized set of locations.

Custom Systems Written In-House

An alternative to contracting for finance and business systems is to write the software in-house, using the company’s own employees. The economics are somewhat different from those of contracted software – the value of the work depends on improving efficiency or effectiveness in other aspects of the company’s operations. The emphasis on meeting schedule is lessened, since projects are often paused and restarted depending on overall budgets. The systems may be business-critical or may be more experimental in nature. Again, fixes are distributed to a limited and identifiable set of locations.

Commercial Software

Commercial software is software sold to other businesses, rather than to an individual consumer. In this practice culture, profit depends on the more familiar economic model of selling many copies of the same item for more than it cost to design the item and make the copies. Instead of satisfying one customer’s needs precisely, the profitable vendor satisfies many customers less exactly. The software is often business-critical or at least quite important to the operation of the customer’s business. Since the software is in the hands of many customers in many locations, distributing fixes can be quite expensive. (Internet applications, where the customer subscribes to a centralized service, are an exception.) The customers also have an annoying habit of suing or causing other trouble if the software is seriously deficient, which drives up the cost of errors.

Mass-market Software

Mass-market software is sold to individual consumers, often at very high volumes. Profit depends on selling product above cost, frequently in market “windows” or buying seasons such as pre-Christmas. Software manufacturers don’t set these windows – they predated the existence of consumer software by many decades. The potential effects of software failures on the customer are usually less serious than those in the preceding cultures, and the customers are less likely to demand or receive reparation for damages. Software failures can significantly affect the user’s financial wellbeing, as in tax-preparation software, but many do fall into the category of mere annoyances.

Commercial and Mass-market Firmware

The business considerations for mass-market firmware differ enough from those for mass-market software that it makes sense to lump commercial and mass-market firmware together. As in both commercial and mass-market software, profit depends on selling the product above cost. The cost of distributing fixes is extremely high, because the physical items have to be brought in and re-flashed or otherwise physically changed – fixes cannot be simply sent to the customer. The impact of failures in mass-market firmware is potentially more serious than the impact of software failures, since the firmware is controlling a device. While the destructive potential of small items such as digital watches is probably minimal, there are plenty of consumer devices that contain enough electronics to catch fire. Firmware failures can have fatal consequences.

Situational Factors

Each business model has a set of attributes or situational factors associated with it. Situational factors are often derived from or limited by the business model – both the way the money flows, and the end purpose of the software itself. For instance, software meant for consumer purchase is unlikely to be life-critical.

Here’s a list of situational factors that seem to influence the choice of software engineering practices:

• Criticality: The potential for harming the user’s or purchaser’s interests varies depending on the type of product. Some software can kill you when it fails, other software can lose large sums of many people’s money, and yet other software can do nothing worse than waste the user’s time.
• Uncertainty of Users’ Wants and Needs: The requirements for software that implements a known business process (such as the tax code) are necessarily better known than the requirements for a consumer product that is so new the end users don’t even know that they want it.
• Range of Environments: Software written to use in a specific company needs to be compatible only with that company’s officially supported computing environments, whereas software sold to the mass market has to work with a wide range of environments.
• Cost of Fixing Errors: Distributing firmware fixes is a lot more expensive than patching a single website.
• Regulation: Regulatory agencies and contract terms can require practices that might not otherwise be adopted, or may set up a situation in which certain practices become useful. Some situations require process audits, which verify that a certain process was followed to make the product. (The term “audit” is also used in some fields for an activity which verifies that the end product works as intended, which is not the same as a process audit.)
• Project Size: Multi-year projects with hundreds of developers are common in some businesses, whereas shorter single-team projects are more typical in other businesses.
• Communication: There are a number of factors in addition to project size that can increase the amount of person-to-person communication needed, or make accurate communication more difficult. Some of the factors seem to show up more frequently in certain practice cultures, whereas others appear to be randomly distributed.
• Concurrent Developer-Developer Communication: Communication with other people on the same project is affected by the way the work is distributed. In some organizations, senior staff designs the software and junior staff does the actual coding and unit testing (as opposed to having the same individual design, code, and unit test a given component). This practice increases the amount of developer-developer communication needed. Specialization can also cause communication difficulties when taken to the point where specialists start assuming knowledge on the part of others or are themselves missing a piece of the picture.
• Forward Developer-Developer Communication: Maintenance and enhancements require communication with developers forward in time. This is easiest when the developers tend to stick around, and thus the communication is with yourself.
• Developer-Management Communication: Project status needs to be reported upwards, but the amount and form of communication that managers believe they need varies rather considerably.
• Organizational Culture: The organization itself will have a culture that defines how people operate. Four organizational cultures:
• Control – “Control cultures, like IBM and GE, are motivated by the need for power and security.”
• Competence – “A competence culture is driven by the need for achievement: Microsoft is an obvious example.”
• Collaboration – “Collaboration cultures, epitomized by Hewlett-Packard, are driven by a need for affiliation.”
• Cultivation – “A cultivation culture motivates by self-actualization … and can be illustrated by Silicon Valley start-up companies.”

1

Table 1. Fears and Risks -Practices to Minimize Them (Example)

Name of the Business Model selected: Custom systems written on contract

Provide the name of a company that represents this business Model: ______

1. Criticality: Software failures in finance systems can seriously damage the purchaser’s business interests. Software failures in military systems can be life-critical

1. Uncertainty of Users’ Wants and Needs: Since the purchasers and users are an identifiable group of people, they can be located to find out what they want

1. Range of Environments : small set of target environments to hold down their costs,

1. Cost of Fixing Errors: reasonably priced ways to distribute fixes

1. Regulation: Software for the Department of Defense must be written in accordance with a huge list of regulations. Finance software is not subject to regulation in the same way, although contracts vary

1. Project Size: Really big. Many dozens of people over two years seems merely average, whereas the biggest have hundreds of people over multiple years

1. Communication: Since the systems and projects are large, there are often separate people or even separate departments for analysis, database design

1. Organizational Culture: control culture

1. Penalties for late delivery: Delivery on time and within budget is very important.

1. Not profits.

1. Damaged reputation: may be more difficult to win new contracts

1. Software that reliably delivers correct output is very important.

1. Requirements: can and should be known in detail up front.

1. Projects will be large and communication paths complex.

1. Litigations: Must be able to prove that we did what we promised.

Table 2. Fears and Risks -Practices to Minimize Them

Name of the Business Model selected: ______

Provide the name of a company that represents this Business Model: ______

1. Criticality______

1. Uncertainty of Users’ Wants and Needs______

1. Range of Environments______

1. Cost of Fixing Errors______

1. Regulation______

1. Project Size______

1. Communication______

1. Organizational Culture______