business development plan
UC Residency
Dr. Yousefi
TOC
Introduction
BI Presentation
Residency Activities
Individual Project
Group Project
BI Project
Business Decision Support Systems
Discussion
Primary Task Response: Within the Discussion Board area, write 400–600 words that respond to the following questions with your thoughts, ideas, and comments.
This will be the foundation for future discussions by your classmates. Be substantive and clear, and use examples to reinforce your ideas:
There is a fundamental difference between business data, information, and knowledge with respect to the value that each brings to the organization.
Discussion
Research online, and discuss the following:
Describe the differences between business data, information, and knowledge.
How does each provide value to the acquisition of business intelligence?
Responses to Other Students: Respond to at least 2 of your fellow classmates with at least a 100-word reply about their Primary Task Response regarding items you found to be compelling and enlightening. To help you with your discussion, please consider the following questions:
Discussion
What did you learn from your classmate’s posting?
What additional questions do you have after reading the posting?
What clarification do you need regarding the posting?
What differences or similarities do you see between your posting and other classmates’ postings
A reference is mandatory for the initial post
Project
You have been asked to develop a Business Intelligence Development Plan for a local corporation that has recently implemented a new centralized information management system.
01
The corporation can be your choice of either a hypothetical example or an existing company.
02
Project
The document should be in the following format (use Word document):
1
Business Intelligence Development Plan
2
Title page
Course number and name
Project name
Student name
Date
Table of contents
Use the auto-generated TOC.
Project
Make it a maximum of 3 levels deep.
Be sure to update the fields of the TOC so that it is up-to-date before submitting your project.
Section headings (create each heading on a new page)
Business Intelligence Justification
Business Performance Plan
Business Performance Methodologies
Data Classification and Visualization Assessment
Data-Mining Methods and Processes
Project
You will add a section to the Business Intelligence Development Plan and submit it for grading. Be sure that you support your information each week with scholarly sources and that you cite each source both in-text and in the References section using APA. The first section of new content will be as follows:
Business Intelligence Justification (Week 1 IP): 4–5 pages
Describe the general business environment for the case study organization.
Define at least 6 problems related to decision making that currently exist in the organization.
Project
Describe
Describe the typical organizational response to the above 6 problems using the business pressure-responses-support model.
Describe
Describe the quantitative and qualitative impact of the organizational response to the 6 problems on managerial decision making.
Describe
Describe how business intelligence can be used to support problem solving and decision support in the case study organization.
Name
Name the document “yourname_IT415_IP1.doc.”
Learning Objectives
Understand today’s turbulent business environment and describe how organizations survive and even excel in such an environment (solving problems and exploiting opportunities)
Understand the need for computerized support of managerial decision making Describe the business intelligence (BI) methodology and concepts Understand the various types of analytics
Introduction
The business environment (climate) is constantly changing, and it is becoming more and more complex.
Organizations, private and public, are under pressures that force them to respond quickly to changing conditions and to be innovative in the way they operate.
Such activities require organizations to be agile and to make frequent and quick strategic, tactical, and operational decisions, some of which are very complex.
Introduction
Such activities require organizations to be agile and to make frequent and quick strategic, tactical, and operational decisions, some of which are very complex.
Making such decisions may require considerable amounts of relevant data, information, and knowledge.
Processing these, in the framework of the needed decisions, must be done quickly, frequently in real time, and usually requires some computerized support.
Business Decision Support Systems
Decision support systems:
Are used by businesses to enable the analysis of stored data as a means of supporting the decision-making process.
In essence, any collection of integrated software and hardware that is purposely combined to support the organization could be considered a potential decision support system.
Business Decision Support Systems
It is not until the data are collected from multiple sources, formatted, and collated to support reporting and analysis—and tools are used to analyze, monitor and report the findings—that such systems are considered capable of decision support.
The decision support system is considered critical to the organization, but the ability to make effective decisions is based on the integrity of the data and the interpretation of the analysis on the part of individuals in the organization.
Differences Between Business Data, Information, and Knowledge
There is a fundamental difference between business data, information, and knowledge.
Data represents the facts that are stored about a given subject. For example, all of the facts stored about customers are often referred to as customer data.
Information pertains to data being placed into some context. Data that are represented on an invoice about the customer have been placed into the context of the invoice.
Differences Between Business Data, Information, and Knowledge
Because an invoice is a form that can be related to the concept of the customer, it makes sense that the customer data are placed into that specific context. Knowledge is gained once the data becomes information and a conclusion can be made about the information.
For example, reviewing a specific customer invoice allows for the gaining of knowledge as to when the order was placed, when the order was shipped, and how much the invoice total was.
Differences Between Business Data, Information, and Knowledge
In comparing one invoice to many invoices over time, conclusions can be made about how one invoice relates to others.
For example, a case could be made that an invoice is representative of an average order, from a sales-figure point of view.
Because the review of invoices over time adds to the knowledge base of the organization, these types of conclusions are possible and quite common. In this regard, data, information, and knowledge are said to provide value to the organization
How Business Data, Information, and Knowledge Provide Value
Data that have integrity are valid (an accurate depiction of the variable in question) and reliable (produce consistent and recognizable results over time).
01
It is these characteristics of data that permit them to provide significant value to the organization.
02
The information that is gathered during business processes and the knowledge that is gained from the information about those processes provide value to the organization because the ability to compete in the industry sector is enhanced as a result.
03
How Business Data, Information, and Knowledge Provide Value
Decisions about resource allocation, staffing, and purchasing are all examples of how data, information, and knowledge provide value to the organization.
If the organization does not know its current state with respect to goals and objectives, forecasts, and performance history, reasonable expectations cannot be formulated, and decisions cannot be made effectively.
In other words, decisions may be made as a function of uninformed or reactionary conclusions, rather than carefully crafted, informed decisions founded in certainty.
The Business Pressure-Responses-Support Model
The business pressure-responses-support model has the following three factors associated with it:
The pressures resulting from the business climate
The actions or responses taken to maximize opportunities or counter pressures
The Business Pressure-Responses-Support Model
The computerized support that creates an environment that facilitates monitoring and enhanced actions as responses
The paradox of the possibilities that are associated with increased opportunity while experiencing increased risk and problems is the basis of many business problems. Therefore, businesses need to make effective business decisions based on available intelligence
Bus. Pressure-Responses-Support Model
The Business Pressure-Responses-Support Model
The pressures resulting from the business climate
The actions or responses taken to maximize opportunities or counter pressures
The computerized support that creates an environment that facilitates monitoring and enhanced actions as responses
Business Pressures
The business environment is impacted by market-related pressures, consumer demand, technology drivers, and society in general.
The market is a competitive force that businesses contend with, especially with globalization and expansion to e-commerce, innovation, and the need to engage in business and with the customer in real time. Outsourcing and offshoring are market-related pressures that many businesses face as possible cost-saving options, especially in the area of information technology.
Business Pressures
Consumers demand better products, lower prices, and more options for products.
With the massive amount of product information that is available online, the consumers are more empowered to compare products and educate themselves about features, value-added opportunities, and product availability from vendor to vendor
Consumers are no longer willing to settle for less; they want to get quality and value.
As technologies advance and innovations become more common, the products and services that are based on these technologies cause products to have less of a useful life; the more connected consumers are, the more overloaded they feel.
Business Pressures
Businesses feel the need to bombard the consumer with information about the latest technologies, but to some extent, the consumers feel that they have only just learned the outdated technology.
The need for businesses to create a balance and provide graduated exposure is compounded by the need to do better than the competition. Society, including governmental regulation and deregulation, also creates pressure for the business simply because of the need to maintain compliance.
Changes in the workforce have brought about more diversity and the need of businesses to embrace and support these workers. Homeland Security, terrorist threats, the Sabines-Oxley Act, and financial auditing all create additional pressures on the business
Business Responses
Organizations respond in various ways in the face of pressure.
The activities that are related to the response are classified as reactive, anticipative, adaptive, or proactive.
The responses include the formulation and use of strategy, modification of existing or use of new business models, the restructuring of business processes, and the improvement to existing information systems and technology.
Establishing strategic alliances with other businesses and the cultivation of existing and new relationships are also used to respond to business pressures.
Businesses also respond by implementing business intelligence methods and techniques in an effort to improve communication, customer service, revenue, and facing competition in the market
Tools
Three types of analytical techniques—
Descriptive,
Predictive, and
Prescriptive analytics—
To turn the raw data returned from the monitoring devices into actionable recommendations and warnings
Predictive analysis
Use of tools that help determine the probable future outcome for an event or the likelihood of a situation occurring.
These tools also identify relationships and patterns. predictive analytics A business analytical approach toward forecasting (e.g., demand, problems, opportunities) that is used- instead of simply reporting data as they occur.
Process
First, the graphical analysis of the data (termed reporting analytics) allows users to get a good feel for the situation.
Then, additional analysis using data mining techniques can be used to estimate what future behavior would be 6like.
This is the domain of predictive analytics.
Process
Such analysis can then be taken to create specific recommendations for operators.
This is an example of prescriptive analytics. Finally, this opening vignette also suggests that innovative applications of analytics can create new business ventures. Identifying opportunities for applications of analytics and assisting with decision making in specific domains is an emerging entrepreneurial opportunity.
Changing Business Environments and Computerized Decision Support
The opening vignette illustrates how an organization can employ analytics to develop reports on what is happening,
Predict what is likely to happen,
and then also make decisions to make best use of the situation at hand.
Changing Business Environments and Computerized Decision Support
These steps require an organization to collect and analyze vast stores of data.
01
Companies are moving aggressively to computerized support of their operations.
02
To understand why companies are embracing computerized support, including business intelligence, we developed a model called the Business Pressures–Responses–Support Model
03
Business Pressures–Responses–Support Model
The Business Pressures–Responses–Support Model
three components:
business pressures that result from today’s business climate;
responses (actions taken) by companies to counter the pressures (or to take advantage of the opportunities available in the environment);
and computerized support that facilitates 7the monitoring of the environment and enhances the response actions taken by organizations.
Closing the Strategy Gap
One of the major objectives of computerized decision support is to facilitate closing the gap between the current performance of an organization and its desired performance, as expressed in its mission, objectives, and goals, and the strategy to achieve them.
In order to understand why computerized support is needed and how it is provided, especially for decision-making support, let’s look at managerial decision making.
Review Questions
List the components of and explain the Business Pressures–Responses–Support Model.
What are some of the major factors in today’s business environment?
What are some of the major response activities that organizations take?
A Framework for Business Intelligence (BI)
The decision support concepts presented in Sections 1.1 and 1.2 have been implemented incrementally, under different names, by many vendors that have created tools and methodologies for decision support.
As the enterprise-wide systems grew, managers were able to access user-friendly reports that enabled them to make decisions quickly.
A Framework for Business Intelligence (BI)
These systems, which were generally called executive information systems (EIS), then began to offer additional visualization, alerts, and performance measurement capabilities.
By 2006, the major commercial products and services appeared under the term business intelligence (BI).
Definitions of BI
Business intelligence (BI) is an umbrella term that combines architectures, tools, databases, analytical tools, applications, and methodologies.
01
It is, like DSS, a content-free expression, so it means different things to different people.
02
Part of the confusion about BI lies in the flurry of acronyms and buzzwords that are associated with it (e.g., business performance management [BPM]).
03
Definitions of BI
BI’s major objective is to enable interactive access (sometimes in real time) to data, to enable manipulation of data, and to give business managers and analysts the ability to conduct appropriate analysis.
By analyzing historical and current data, situations, and performances, decision makers get valuable insights that enable them to make more informed and better decisions. The process of BI is based on the transformation of data to information, then to decisions, and finally to actions
Figure 1.2 Evolution of Business Intelligence (BI).
The Architecture of BI
A BI system has four major components: a data warehouse, with its source data; business analytics, a collection of tools for manipulating, mining, and analyzing the data in the data warehouse; business performance management (BPM) for monitoring and analyzing performance; and a user interface (e.g., a dashboard). The relationship among these components
Figure 1.3 A High-Level Architecture of BI.
Intelligence Creation, Use, and BI Governance
A Cyclical Process of Intelligence Creation and Use
Data warehouse and BI initiatives typically follow a process similar to that used in military intelligence initiatives.
In fact, BI practitioners often follow the model depicted in Figure 1.4.
The process is cyclical with a series of interrelated steps.
Analysis is the main step for converting raw data to decision-supporting information. However, accurate and/or reliable analysis isn’t possible unless other steps along the way have been properly addressed.
Continue
Once a data warehouse is in place, the general process of intelligence creation starts by identifying and prioritizing specific BI projects.
For each potential BI project in the portfolio, it is important to use return on investment (ROI) and total cost of ownership measures to estimate the cost–benefit ratio.
This means that each project must be examined through costing associated with the general process phases as well as costs of maintaining the application for the business user.
Additionally, the benefits estimations need to involve end-user examinations of decision-making impacts, including measures reflecting benefits like cash flow acceleration. Some organizations refer to the project prioritization process as a form of BI governance
Continue
A major governance issue is who should serve as decision makers involved in prioritizing BI projects.
1
The two critical partnerships required for BI governance are (1) a partnership between functional area heads and/or product/service area leaders (Middles), and (2) a partnership between potential customers and providers (representatives of the business side and representatives from the IT side).
2
Continue
Customers can offer insight into the potential usefulness of the intelligence generated in a project, and providers are important from the standpoint of reflecting delivery realities.
A typical set of issues for the BI governance team is to address
(1) creating categories of projects (investment, business opportunity, strategic, mandatory, etc.);
(2) defining criteria for 14project selection;
(3) determining and setting a framework for managing project risk;
(4) managing and leveraging project interdependencies; and
(5) continually monitoring and adjusting the composition of the portfolio.
Figure 1.4 Process of Intelligence Creation and Use
Transaction Processing VERSUS Analytic Processing
To illustrate the major characteristics of BI, first we will show what BI is not—namely, transaction processing.
The information systems that support our transactions, like ATM withdrawals, bank deposits, cash register scans at the grocery store, and so on. These transaction processing systems are constantly involved in handling updates to what we might call operational databases.
Calculation of total sales for the day, and it should reflect an appropriate reduction in the store’s inventory for the items we bought, and so on.
Computer Processing
Online transaction processing (OLTP)
Online analytical processing (OLAP)
Enterprise Resources Planning (ERP) systems
Successful BI Implementation
Implementing and deploying a BI initiative can be lengthy, expensive, and failure prone. Let’s explore some of the issues involved.
The Typical BI User Community
BI may have a larger and more diversified user community.
The success of BI depends, in part, on which personnel in the organization would be the most likely to make use of BI.
One of the most important aspects of a successful BI is that it must be of benefit to the enterprise as a whole.
This implies that there are likely to be a host of users in the enterprise—many of whom should be involved from the outset of a DW investment decision.
Appropriate Planning and Alignment with the Business Strategy
One framework, developed by Gartner, Inc. (2004), decomposes planning and execution into business, organization, functionality, and infrastructure components.
At the business and organizational levels, strategic and operational objectives must be defined while considering the available organizational skills to achieve those objectives.
Issues of organizational culture surrounding BI initiatives and building enthusiasm for those initiatives and procedures for the intra-organizational sharing of BI best practices must be considered by upper management—with plans in place to prepare the organization for change.
Continue
One of the first steps in that process is to assess the IS organization, the skill sets of the potential classes of users, and whether the culture is amenable to change.
From this assessment, and assuming there is justification and need to move ahead, a company can prepare a detailed action plan.
Another critical issue for BI implementation success is the integration of several BI projects (most enterprises use several BI projects) among themselves and with the other IT systems in the organization and its business partners.
Continue
If the company’s strategy is properly aligned with the reasons for DW and BI initiatives, and if the company’s IS organization is or can be made capable of playing its role in such a project, and if the requisite user community is in place and has the proper motivation, it is wise to start BI and establish a BI Competency Center (BICC) within the company. The center could serve some or all of the following functions.
Group Project Overview
Section 1 – Overview of Company and Client Business Case
Section 2 – Application Requirement Elicitation Strategy
Section 3 – System Components and Design Requirements
Section 4- Methodology for Application Development Process
Section 5 – Complete Features and Trade-off Analysis
Section 6 – Milestones and Deliverables based on Date and Dependencies
Section 7 – System Architecture Aligned with System Requirements
Section 8 – Technical Design Document
Section 9 – Design Review Checklist
Section 10 – Testing and Deployment
Group Discussion
Overview of Company and Client Business Case:
As a group, hold a discussion and make a decision on a business case that will require the development and deployment of an IT Network System Application for any organization. As an idea, the Business Case could be but not limited to:
The development of a custom accounting application for an accounting firm
The development of a Customer Service Application for a store
Student Information System for a small university
Or any other similar solution requirements
Group Work
As a group determine the following:
Create a name for your company and a profile for your company
What is your company’s expertise?
Ensure that the expertise matches the skill sets required for the business case you have chosen
Client Case Overview
What client business case did you choose and why?
How does your company expertise match your client’s needs?
Client Application Solution
Based on the case you have chosen, what do you believe is the application solution? Why?
Application Requirement Elicitation and Strategy
Before you are able to work on the development of a solution you must have a clear understanding of the customers’ needs.
As a group discuss and determine the following:
How will requirement elicitation be conducted by your team?
Who will be the main stakeholder that you will be eliciting information from?
What questions need to be answered and why?
How will you implement your elicitation strategy?
System Components and Design Requirements
As a group decide and discuss the following:
Based on the elicitation results, finalize the system components and design requirements that are needed for your business case.
Does the design solution support all the customer needs?
Provide specifics that the proposed application should address
Based on the requirements, each individual will tackle the weekly deliverables. However, students can decide to share the work from various components of their project with each other. If this is the approach the group will use, each individual’s work must be cohesive to what other members are developing considering that the individual efforts will be combined across components.
Methodology for Application Development Process
As a group, complete the following:
Choose a system development methodology for your project.
The methodology chosen should align with achieving the overall objective of your business case.
Unit 1: Application Development Methods
Reading Task:
McConnell, Chap. 2, 6, 7, 12, 13, 25, 35
Primary Task Response: Within the Discussion Board area, write 400–600 words that respond to the following questions with your thoughts, ideas, and comments. This will be the foundation for future discussions by your classmates. Be substantive and clear, and use examples to reinforce your ideas:
There are various System Development Methodologies. These include but not limited to:
Waterfall
Continue
Agile
Dynamic Systems Development Method
Microsoft Solution Framework
Rapid Application Development
Choose and discuss any one of the methodologies.
What are the benefits and constraints of the methodology chosen?
How do you believe you can leverage this methodology in system development?
This discussion board will lead into a greater discussion with your small group for the Key Assignment Project.
Application Development Methods
System Development Methodology
System Project Planning
Risks Assessment and Planning
What Is Rapid Development?
A “rapid-development project,” then, is any project that needs to emphasize development speed. In today’s climate, that description fits a lot of projects.
The importance of the project:
Quality
Cost
Performance
Maintainability
Success at rapid development
consists of two elements:
1. Choosing effective practices rather than ineffective practices
2. Choosing practices that are oriented specifically toward achieving your schedule objectives
Set of all software-development practices
Practices
Organizations routinely choose ineffective practices. They choose practices that are proven failures or that fail more often than they succeed.
When they need maximum scheduling certainty, they choose high-risk practices that reduce the chance of meeting their schedule goals.
When they need to reduce costs, they choose speed-oriented practices that drive costs up.
The first step toward improving development speed for those organizations is to admit that they’re choosing ineffective practices and then to begin choosing effective ones.
Schedule-oriented practices
Practices that improve development speed, allowing you to deliver software faster
Practices that reduce schedule risk, allowing you to avoid huge schedule overruns
Practices that make progress visible, allowing you to dispel the appearance of slow development
Schedule-oriented practices
General Strategy for Rapid Development
Best Possible Schedule:
Avoid classic mistakes
Apply development fundamentals
Manage risks to avoid catastrophic setbacks
Apply schedule-oriented practices such as the three kinds of practices
Four Dimensions of Development Speed
Staff selection for team projects
Top talent—Use better and fewer people.
Job matching—Fit the tasks to the skills and motivation of the people available.
Career progression—Help people to self-actualize rather than forcing them to work where they have the most experience or where they are most needed.
Team balance—Select people who will complement and harmonize with each other.
Misfit elimination—Eliminate and replace problem team members as quickly as possible.
Team organization
The way that people are organized has a great effect on how efficiently they can work.
Software shops can benefit from tailoring their teams to match project size, product attributes, and schedule goals.
A specific software project can also benefit from appropriate specialization.
Motivation
A person who lacks motivation is unlikely to work hard and is more likely to coast. No factor other than motivation will cause a person to forsake evenings and weekends without being asked to do so.
Few other factors can be applied to so many people on so many teams in so many organizations. Motivation is potentially the strongest ally you have on a rapid-development project.
Variations in Productivity
Here’s a summary of the variations that researchers have found:
Greater than 10-to-1 differences in productivity among individuals with different depths and breadths of experience.
10-to-1 differences in productivity among individuals with the same levels of experience.
5-to-1 differences in productivity among groups with different levels of experience.
2.5-to-1 differences in productivity among groups with similar levels of experience.
Process
Process, as it applies to software development, includes both management and technical methodologies.
Process represents an area of high leverage in improving your development speed—almost as much as people.
Rework avoidance.
If requirements change in the late stages of project, you might have to redesign, recode, and retest. If you have design problems that you didn’t find until system testing, you might have to throw away detailed design and code and then start over. One of the most straightforward ways to save time on a software project is to orient your process so that you avoid doing things twice.
Raytheon won the IEEE Computer Society’s Software Process Achievement Award in 1995 for reducing their rework costs from 41 percent to less than 10 percent and simultaneously tripling their productivity (Raytheon 1995).
Quality assurance.
Quality assurance has two main purposes.
The first purpose is to assure that the product you release has an acceptable level of quality.
The second function of quality assurance is to detect errors at the stage when they are least time-consuming (and least costly) to correct. T
Development fundamentals
Much of the work that has been done in the software-engineering field during the last 20 years has been related to developing software rapidly.
A lot of that work has focused on “productivity” rather than on rapid development per se, and, as such, some of it has been oriented toward getting the same work done with fewer people rather than getting a project done faster.
You can, however, interpret the underlying principles from a rapid-development viewpoint
Risk management
One of the specific practices that’s focused on avoiding disaster is risk management
Developing rapidly isn’t good enough if you get your feet knocked out from under you two weeks before you’re scheduled to ship. Managing schedule-related risks is a necessary component of a rapid development program.
Lifecycle planning
One of the keys to targeting resources effectively is to apply them within a lifecycle framework that makes sense for your specific project.
Without an overall lifecycle model, you can make decisions that are individually on target but collectively misdirected.
A lifecycle model is useful because it describes a basic management plan.
For example, if you have a risky project, a risk-oriented lifecycle model will suit you; and if you have vague requirements, an incremental lifecycle model may work best.
Lifecycle models make it easy to identify and organize the many activities required by a software project so that you can do them with the utmost efficiency.
Product
The most tangible dimension of the people/process/product/technology compass is the product dimension, and a focus on product size and product characteristics presents enormous opportunities for schedule reduction.
If you can reduce a product’s feature set, you can reduce the product’s schedule. If the feature set is flexible, you might be able to use the 80/20 rule and develop the 80 percent of the product that takes only 20 percent of the time.
Product
You can develop the other 20 percent later. If you can keep the product’s look and feel, performance characteristics, and quality characteristics flexible, you can assemble the product from preexisting components and write a minimum amount of custom code.
The exact amount of schedule reduction made possible by focusing on product size and product characteristics is limited only by your customer’s product concept and your team’s creativity.
Classic Mistakes
A group of ITT researchers reviewed 44 projects in 9 countries to examine the impact of 13 productivity factors on productivity (Vosburgh et al. 1984).
The factors included the use of:
modern programming practices,
code difficulty,
performance requirements,
level of client participation in requirements specification,
personnel experience, and several others.
They divided each of the factors into categories that you would expect to be associated with low, medium, and high performance. For example, they divided the “modern programming practices” factor into low use, medium use, and high use. Figure 3-1 on the next page shows what the researchers found for the “use of modern programming practices” factor.
People
Undermined motivation
Weak personnel
Uncontrolled problem employees
Heroics
Adding people to a late project
Noisy, crowded offices
Friction between developers and customers
People
Unrealistic expectations
Lack of effective project sponsorship
Lack of stakeholder buy-in
Lack of user input
Politics placed over substance
Wishful thinking
Process
Overly optimistic schedules
Insufficient risk management
Contractor failure
Insufficient planning
Abandonment of planning under pressure
Wasted time during the fuzzy front end
Shortchanged upstream activities
Inadequate design
Process
Shortchanged quality assurance
Insufficient management controls
Premature or overly frequent convergence
Omitting necessary tasks from estimates
Planning to catch up later
Code-like-hell programming
Product
Requirements gold-plating
Feature creep
Developer gold-plating
Push-me, pull-me negotiation
Research-oriented development
Technology
Silver-bullet syndrome
Overestimated savings from new tools or methods
Does One Size Fit All?
Different projects have different rapid-development needs, even when they all need to be developed “as fast as possible.” Generally speaking, products that are widely distributed need to be developed more carefully than products that are narrowly distributed
Products whose reliability is important need to be developed more carefully than products whose reliability doesn’t much matter.
What Kind of Rapid Development Do You Need?
The most central issue to the topic of rapid development is determining what kind of rapid development you need. Do you need a slight speed edge, more predictability, better progress visibility, lower costs, or more speed at all costs?
How strong is the product’s schedule constraint?
Does the project’s emphasis on schedule arise because it is really one of the common “rapid-development look-alikes”?
Is your project limited by any weaknesses that would prevent a rapid development success?
Products with Strong Schedule Constraints
Odds of Completing on Time
Schedule, Cost, and Product Trade-Offs
Lifecycle Planning
EVERY SOFTWARE-DEVELOPMENT EFFORT goes through a “lifecycle,” which consists of all the activities between the time that version 1.0 of a system begins life as a gleam in someone’s eye and the time that version 6.74b finally takes its last breath on the last customer’s machine.
A lifecycle model is a prescriptive model of what should happen between first glimmer and last breath.
For our purposes, the main function of a lifecycle model is to establish the order in which a project specifies, prototypes, designs, implements, reviews, tests, and performs its other activities
It establishes the criteria that you use to determine whether to proceed from one task to the next.
Lifecycle
By defining the master plan for the project, the lifecycle model you choose has as much influence over your project’s success as any other planning decision you make.
The appropriate lifecycle model can streamline your project and help ensure that each step moves you closer to your goal.
Depending on the lifecycle model you choose, you can improve development speed, improve quality, improve project tracking and control, minimize overhead, minimize risk exposure, or improve client relations.
The wrong lifecycle model can be a constant source of slow work, repeated work, unnecessary work, and frustration.
Not choosing a lifecycle model can produce the same effects.
Pure Waterfall
The granddaddy of all lifecycle models, a base for other models
In the waterfall model, a project progresses through an orderly sequence of steps from the initial software concept through system testing.
The project holds a review at the end of each phase to determine whether it is ready to advance to the next phase
For example, from requirements analysis to architectural design. If the review determines that the project isn’t ready to move to the next phase, it stays in the current phase until it is ready.
The waterfall model is document driven, which means that the main work products that are carried from phase to phase are documents. In the pure waterfall model, the phases are also discontinuous—they do not overlap
Continue
The waterfall model is document driven, which means that the main work products that are carried from phase to phase are documents. In the pure waterfall model, the phases are also discontinuous—they do not overlap
Code-and-Fix
If you haven’t explicitly chosen another lifecycle model, you’re probably using code-and-fix by default.
If you haven’t done much project planning, you’re undoubtedly using code-and-fix. Combined with a short schedule, code-and-fix gives rise to the code-like-hell approach
When you use the code-and-fix model, you start with a general idea of what you want to build. You might have a formal specification, or you might not.
You then use whatever combination of informal design, code, debug, and test methodologies suits you until you have a product that’s ready to release
The code-and-fix model. Code-and-fix is an informal model
Spiral
At the other end of the sophistication scale from the code-and-fix model is the spiral model. The spiral model is a risk-oriented lifecycle model that breaks a software project up into miniprojects.
Each miniproject addresses one or more major risks until all the major risks have been addressed. The concept of “risk” is broadly defined in this context, and it can refer to poorly understood requirements, poorly understood architecture, potential performance problems, problems in the underlying technology, and so on
Continue
Each iteration involves the six steps shown in bold on the outer edges of the spiral
Determine objectives, alternatives, and constraints
Identify and resolve risks
Evaluate alternatives
Develop the deliverables for that iteration, and verify that they are correct
Plan the next iteration 6. Commit to an approach for the next iteration
Continue
Evolutionary Prototyping
Evolutionary prototyping is a lifecycle model in which you develop the system concept as you move through the project.
Usually you begin by developing the most visible aspects of the system. You demonstrate that part of the system to the customer and then continue to develop the prototype based on the feedback you receive.
At some point, you and the customer agree that the prototype is “good enough.”
At that point, you complete any remaining work on the system and release the prototype as the final product.
Staged Delivery
The staged-delivery model is another lifecycle model in which you show software to the customer in successively refined stages.
Unlike the evolutionary-prototyping model, when you use staged delivery, you know exactly what you’re going to build when you set out to build it.
What makes the staged-delivery model distinctive is that you don’t deliver the software at the end of the project in one fell swoop.
You deliver it in successive stages throughout the project. (This model is also known as “incremental implementation.”)
The primary advantage of staged delivery is that it allows you to put useful functionality into the hands of your customers earlier than if you delivered 100 percent of the project at the end of the project.
Design-to-Schedule
The design-to-schedule lifecycle model is similar to the staged-release lifecycle model in that you plan to develop the product in successive stages. The difference is that you don’t necessarily know at the outset that you’ll ever make it to the last release.
You might have five stages planned—but only make it to the third stage because you have an immovable deadline
This lifecycle model can be a viable strategy for ensuring that you have a product to release by a particular date
The primary disadvantage of this approach is that if you don’t get through all of the stages, you will have wasted time specifying, architecting, and designing features that you don’t ship. If you hadn’t wasted time on a lot of incomplete features that you didn’t ship, you would have had time to squeeze in one or two more complete features
Evolutionary Delivery
Evolutionary delivery is a lifecycle model that straddles the ground between evolutionary prototyping and staged delivery.
You develop a version of your product, show it to your customer, and refine the product based on customer feedback.
How much evolutionary delivery looks like evolutionary prototyping really depends on the extent to which you plan to accommodate customer requests.
If you plan to accommodate most requests, evolutionary delivery will look a lot like evolutionary prototyping.
If you plan to accommodate few change requests, evolutionary delivery will look a lot like staged delivery
Design-to-Tools
The design-to-tools lifecycle model is a radical approach that historically has been used only within exceptionally time-sensitive environments.
As tools have become more flexible and powerful—complete applications frameworks, visual programming environments, full-featured database programming environments—the number of projects that can consider using design-to-tools has increased.
Copyright © 2017 HomeworkM
Do you need a similar assignment done for you from scratch? We have qualified writers to help you. We assure you an A+ quality paper that is free from plagiarism. Order now for an Amazing Discount!
Use Discount Code "Newclient" for a 15% Discount!
NB: We do not resell papers. Upon ordering, we do an original paper exclusively for you.
