Presentation is loading. Please wait.

Presentation is loading. Please wait.

Why is Packaged Software Sometimes Not Enough? Chapter 12

Similar presentations


Presentation on theme: "Why is Packaged Software Sometimes Not Enough? Chapter 12"— Presentation transcript:

1 Why is Packaged Software Sometimes Not Enough? Chapter 12
Systems Development Why is Packaged Software Sometimes Not Enough? Chapter 12

2 Student Learning Outcomes
Discuss why organizations develop computer systems List the six phases within the systems development life cycle (SDLC) and describe the major purposes of each Define the people who are included on most project development teams ©2003 The McGraw-Hill Companies

3 Student Learning Outcomes
Describe the reasons why modeling systems from both a logical and physical perspective is important Define end user development and how it differs from the traditional systems development life cycle (SDLC) and the advantages and disadvantages of end user development Describe why organizations choose to outsource systems development and the major steps in outsourcing ©2003 The McGraw-Hill Companies

4 Student Learning Outcomes
Define end user development and how it differs from the traditional systems development life cycle (SDLC) and the advantages and disadvantages of end user development Describe why organizations choose to outsource systems development and the major steps in outsourcing ©2003 The McGraw-Hill Companies

5 ©2003 The McGraw-Hill Companies
Introduction Organizations today are very dependent on computer systems. To develop successful computer systems requires great skill and knowledge. Most people will not be involved in actually developing systems from scratch but they will certainly be using them. ©2003 The McGraw-Hill Companies

6 12.1 Why Organizations Develop Systems
Become more efficient Level the competitive playing field There is a purpose for developing software A need has been determined Details are drawn on how software should work Information is captured Steps of each process have been defined Code is written Code is tested Code is retested Achieve an advantage through innovation ©2003 The McGraw-Hill Companies

7 Developing Systems to Become More Efficient
Some organizations develop systems just to be more efficient in their internal processes New system may not be designed to yield a market advantage but to add to the survivability and the bottom line of an organization by making it more productive Most organizations today develop systems just to remain efficient. Automation is a key benefit of using technology. If an organization is more efficient through the use of technology, it’s saving money and thus adding to its bottom line. ©2003 The McGraw-Hill Companies

8 Developing Systems to Level the Competitive Playing Field
Developing new systems to stay competitive in the marketplace is often a “reactionary” measure Example: UPS and the U.S. Postal System developed a tracking system similar to FedEx Organizations also develop new systems just to stay up with the competition. The example in the text is a good one. FedEx was the first parcel delivery service to offer a customer-integrated tracking system over the Web. All the other parcel delivery services developed similar systems just to stay up with FedEx. p Fig. 12.1 ©2003 The McGraw-Hill Companies

9 Developing a System to Achieve an Advantage Through Innovation
FedEx developed its new customer-oriented parcel tracking software to achieve an advantage over its competitors. Results 1. Until UPS and others were able to develop similar systems FedEx attracted many new customers (away from its competition). 2. FedEx was also able to reduce the number of people handling incoming phone calls for parcel pickup and tracking. ©2003 The McGraw-Hill Companies

10 Example of Achieving Advantage Through Innovation
Self-scanning systems at the grocery store helped to achieve a competitive advantage People can get through the checkout process quickly The best reason for which to develop systems is to achieve an advantage in the marketplace through innovation. That’s what FedEx did when creating its Web-based tracking system. It won a new portion of the market until its competitors developed similar systems. Another example of innovation through technology is self-scanning systems in many grocery stores. ©2003 The McGraw-Hill Companies

11 12.2 The Traditional Systems Development Life Cycle
The most common way in which organizations develop systems today is through the traditional systems development life cycle. The traditional systems development life cycle (SDLC) is a structured step-by-step approach to developing systems that creates a separation of duties among technology specialists and users. In the SDLC, users (such as yourself) are the business process experts and quality control analysts, whereas the technology specialists are responsible for the actual design, construction, and support of the system. The traditional systems development life cycle (SDLC) includes 6 phases. p Fig. 12.2 ©2003 The McGraw-Hill Companies

12 Why Your Participation is Important in the SDLC
You are or will be a: Business process expert Quality control analyst Manager of other people Your participation is important If you understand why your participation is important, you’ll be more inclined to add as much value as you can to the systems development process. Your participation during the systems development process is important because you are (or will be) a: Business process expert - a person who understands the computerized business process being developed. Quality control analyst - a person who makes sure guidelines are being followed and that specifications are being met. Manager of other people – a person who handles more than the traditional functions of hiring, terminating, motivating, and so on. Today, it extends into the function of providing employees with the technology they need. Ask students to try to define these three responsibilities. ©2003 The McGraw-Hill Companies

13 Richmond Blood Center Current System
2 1 4 To illustrate some key concepts and techniques in the SDLC, follow the Richmond Blood Center as it goes about developing a new system for tracking donors, inventory, and requests from local hospitals. Above is an example of the current system (Investigation Phase): The Richmond Blood Center is a non-profit organization that basically maintains an inventory of blood by accepting donations and filling requests for blood from local hospitals. The Richmond Blood Center needs a new system for tracking donors, inventory, and requests from local hospitals. 3 p Fig. 12.3 ©2003 The McGraw-Hill Companies

14 First Phase of the SDLC - Systems Investigation
Four tasks: 1. Define the Problem/Opportunity 2. Assess Initial Feasibility 3. Build the Project Team 4. Create A Systems Development Project Plan SimNet Concepts Support CD: “Systems Development Overview” ©2003 The McGraw-Hill Companies

15 Systems Investigation
In systems investigation you seek to lay the foundation for the systems development process by performing four tasks which include: Define the problem/opportunity - a concise document that describes the exact nature of the problem or opportunity and provides broad statements concerning how the proposed system will benefit the organization. Assess initial feasibility time feasibility assessment determines if your organization can develop the proposed system while meeting certain deadlines. technical feasibility assessment determines if your organization has access to or can acquire the necessary hardware and software for the proposed system. fiscal feasibility assessment determines if your organization has sufficient resources to develop the proposed system and if the total cost of those resources falls within an allocated budget. Build the project team System champion – management person within your organization who (1) believes in the worth of the system and (2) has the “organizational muscle” to pull together the necessary resources. This is often the chief information office (CIO), the person within your organization who oversees the use of information as a resource. Several users One or more systems analysts – technology specialists who understand both technology and business processes. Programmers – technology specialists whose expertise lies in taking user requirements and writing software to match those requirements. This could include application programmers (programmers who write application software) and system programmers (programmers who write operating system and utility software). One or more hardware specialists Project manager – the person who oversees the project from beginning through implementation and support. Create a systems development project plan - a document that includes a list of the project team, the problem/opportunity statement, the project budget, the feasibility assessments, and project timetable. p Fig. 12.4 ©2003 The McGraw-Hill Companies

16 Initial Feasibility Assessment
Time feasibility assessment Technical feasibility assessment Time feasibility assessment - determines if your organization can develop the proposed system while meeting certain deadlines. Technical feasibility assessment - determines if your organization has access to or can acquire the necessary hardware and software for the proposed system. Fiscal feasibility assessment - determines if your organization has sufficient resources to develop the proposed system and if the total cost of those resources falls within an allocated budget. Fiscal feasibility assessment ©2003 The McGraw-Hill Companies

17 Composition of Systems Development: Project Teams
System Champion Programmer(s) Several Users Hardware Specialist(s) Ask students to give you a description of what these individuals do. System champion – management person within your organization who (1) believes in the worth of the system and (2) has the “organizational muscle” to pull together the necessary resources. This is often the chief information office (CIO), the person within your organization who oversees the use of information as a resource. Several users – users are simply those people who will eventually be responsible for interacting with the system on a daily basis. One or more systems analysts – technology specialists who understand both technology and business processes. Programmers – technology specialists whose expertise lies in taking user requirements and writing software to match those requirements. This could include application programmers (programmers who write application software) and system programmers (programmers who write operating system and utility software). One or more hardware specialists Project manager – the person who oversees the project from beginning through implementation and support. Systems Analyst(s) Project Manager ©2003 The McGraw-Hill Companies

18 Elements of a Systems Development Project Plan
p Fig. 12.5 ©2003 The McGraw-Hill Companies

19 Project Management Software
Most project teams use project management software such as Microsoft Project to help them effectively manage the project plan and organize all of the documents associated with the development of a specific project SimNet Concepts Support CD: “Project Management Applications” ©2003 The McGraw-Hill Companies

20 ©2003 The McGraw-Hill Companies
Systems Analysis The systems analysis phase of the systems development life cycle (SDLC) involves modeling how the current system works from a logical (not physical) point of view identifying its weaknesses and the opportunities to improve creating a logical model of the new system reviewing the project plan The real key here is to focus on logical aspects, not physical. Don’t deal with CPU speed, network characteristics, or other such technical matters at this point. You simply want to determine what the system should be doing from a logical point of view. To aid in this process, you can perform data flow diagramming. p Fig. 12.6 ©2003 The McGraw-Hill Companies

21 Systems Analysis Phase
Model how the current system works from a logical point of view Identify current system weaknesses and the opportunities to improve Create a logical model of the new system Review the project plan ©2003 The McGraw-Hill Companies

22 Richmond Blood Center Data Flow Diagram (DFD)
Data flow diagramming (DFD) is a modeling technique for illustrating how information moves through various processes and how people outside the system provide and receive information. The Richmond Blood Center data flow diagram (DFD) shows major processes and the flows of information among them. p Fig. 12.7 ©2003 The McGraw-Hill Companies

23 ©2003 The McGraw-Hill Companies
Systems Design The systems design phase of the systems development life cycle (SDLC) involves generating several alternative technical solutions for the new logical model selecting the best technical alternatives developing detailed software specifications, and – once again – reviewing the project plan At this point, your role as a business process expert diminishes and your role as a quality control analyst increases. Most of the work during this phase is performed by the technology specialists. p Fig. 12.8 ©2003 The McGraw-Hill Companies

24 ©2003 The McGraw-Hill Companies
Systems Design Phase Generate several alternative technical solutions for the new logical model Select the best technical alternative Develop detailed software specifications Review the project plan ©2003 The McGraw-Hill Companies

25 Richmond Blood Center Flowchart
This flowchart shows the process the Richmond Blood Center follows to process blood requests from hospitals. p Fig. 12.9 ©2003 The McGraw-Hill Companies

26 Intranet Protected by a Firewall Richmond Blood Center
The Richmond Blood Center technical design shows an intranet protected by a firewall. Why is this important? Review the functions of an intranet. ©2003 The McGraw-Hill Companies

27 ©2003 The McGraw-Hill Companies
Systems Construction The goal of the systems construction phase of the systems development life cycle (SDLC) is to actually create the new system. Tasks here include: Acquiring and installing new hardware Writing software Testing software Reviewing the project plan Again, during this phase your students will be mostly quality control analysts, verifying (testing) the software to ensure it works properly. p Fig ©2003 The McGraw-Hill Companies

28 Systems Construction Phase
Acquire and installing new hardware Write software Test the software Review the project plan Note: 80 to 90 percent of all efforts are devoted to this phase ©2003 The McGraw-Hill Companies

29 Systems Implementation
The systems implementation phase of the systems development life cycle (SDLC) involves: training users converting existing information to the new system converting users acceptance testing reviewing the project plan Acceptance testing is key here. Acceptance testing is the formal, documented process in which users: use the new system verify that it works correctly under operational conditions note any errors that need to be fixed Ask students how they think conversion will occur? How will a company move from the old to the new? Some people don’t realize the time and effort that is involved in a conversion process. Some conversions may take years. p Fig ©2003 The McGraw-Hill Companies

30 Systems Implementation Phase
Convert existing information to the new system Convert users Perform Acceptance testing Review the project plan ©2003 The McGraw-Hill Companies

31 Conversion Techniques
Parallel conversion – in which you run both the old and new systems until you’re sure the new system works correctly. Plunge conversion – you unplug the old system and use the new system exclusively. Pilot conversion – you target a select group of users to convert to the new system before converting everyone. Phased / Piecemeal conversion – you target only a portion of the new system for conversion, ensure that is works correctly, and then convert the remaining system. ©2003 The McGraw-Hill Companies

32 ©2003 The McGraw-Hill Companies
Systems Support During systems support there are four tasks: Provide a mechanism for system review – meetings, checkpoints, testing Your organization will be interested in answering such questions as “Does this system still support the overall business goals?” and “Do modifications need to be made to this system in light of changes to business processes?” These are very important questions, and your organization should provide answers to them on a frequent basis. Provide a mechanism for requesting changes – create a change request form or by holding meetings in which users provide feedback concerning the system and its operation. Evaluate proposed system changes – Are changes necessary and worth implementing? Initiate system changes Most importantly, you want your students to understand that a newly developed system will someday be obsolete, and the organization will have to develop a new system to replace the old one. Over time, a system eventually begins to cost a lot of money in terms of maintenance. At some point, these maintenance costs outweigh the costs of new systems development. It’s time to start over. p Fig ©2003 The McGraw-Hill Companies

33 ©2003 The McGraw-Hill Companies
Systems Support Phase Provide a formal mechanism for system review Provide mechanism for requesting changes Evaluate proposed system changes Initiate system changes ©2003 The McGraw-Hill Companies

34 Systems Support: Seek Answers Frequently to these Questions
Does this system still support the overall business goals? 2. Do modifications need to be made to this system in light of changes to business processes? ©2003 The McGraw-Hill Companies

35 Support Costs for a System
Support costs for a system vary over time. p Fig ©2003 The McGraw-Hill Companies

36 12.3 End User Development and Prototyping
Organizations develop computer systems using three different methods: SDLC End User Development Outsourcing ©2003 The McGraw-Hill Companies

37 ©2003 The McGraw-Hill Companies
End User Development End user development is growing in popularity It is estimated that most organizations have a five year back-log of requests for new proposed systems Organizations are empowering employees to develop small-scale systems themselves End user development is the development and support of computer systems by users (such as yourself) with little or no help from technology specialists. Many organizations are now not only letting but also requiring that users develop smaller systems for themselves. Why? Because the systems development backlog in many organizations exceeds 5 years. ©2003 The McGraw-Hill Companies

38 ©2003 The McGraw-Hill Companies
Prototyping Prototyping is the process of building a model that demonstrates the features of a proposed product, service, or system People and organizations perform prototyping all the time i.e., Automobile manufacturers Building contractors Your instructor (sample exam questions) Prototyping involves four steps: Identify the basic requirements of the system. Build a prototype from basic requirements. Have other users review the prototype and suggest changes. Refine and enhance the prototype until it’s complete. The iterative process occurs between steps #3 and #4. As your fellow users review your prototype and suggest changes, you refine and enhance your prototype and then have the users once again review the updated prototype. This iterative process continues until the prototype is complete and can become the final system. ©2003 The McGraw-Hill Companies

39 Prototyping: An Iterative Process
1. Identify the basic requirements of the system 2. Build a prototype from basic requirements 3. Have other users review the prototype and suggest changes 4. Refine and enhance the prototype until it’s complete ©2003 The McGraw-Hill Companies

40 ©2003 The McGraw-Hill Companies
Prototyping SDLC Prototyping End User Development Prototyping Prototyping is the process of building a model that demonstrates the features of a proposed product, service, or system. A prototype, then, is a model of a proposed product (which can be a computer system). p Fig ©2003 The McGraw-Hill Companies

41 End User Development Cycle
End user development looks similar to the traditional systems development life cycle (SDLC). What are the differences? p Fig ©2003 The McGraw-Hill Companies

42 Advantages of End User Development
Encourages active user participation Improves requirements determination Strengthens user sense of ownership Increases speed of systems development Encourages active user participation – when users develop their own systems, they definitely increase their participation in the systems development process. Improves requirements determination – during end user development, users essentially tell themselves what they want. This greatly improves the effectiveness of capturing requirements. Strengthens user sense of ownership – no matter what you do, if you do it yourself, you take pride in your work. Increases speed of systems development – many small systems do not lend themselves well to the SDLC. These smaller systems may suffer from “analysis paralysis” because they don’t require a structured step-by-step approach. ©2003 The McGraw-Hill Companies

43 Disadvantages of End User Development
Inadequate expertise leads to underdeveloped systems Lack of organizational focus creates "privatized" system Insufficient analysis and design leads to subpar systems Lack of documentation of a system may lead to its being short lived Inadequate expertise leads to undeveloped systems – many end user development systems are never completed because users lack the real expertise to utilize the most appropriate IT tools. If you spend time developing a system that you never complete, you have in fact wasted time. Lack of organizational focus creates “privatized” systems – when you develop a system for yourself, you must ensure that it interacts with other organizational systems. If you don’t, you may create a “privatized” system that includes redundant information or performs redundant processes. Insufficient analysis and design leads to sub par systems – Some users jump to conclusions about the hardware and software they should use without carefully analyzing all the alternatives. If this happens, your system may work but not as efficiently as it could. Lack of documentation and support leads to short-lived systems – when users develop their own systems, they often forgo documentation of how the system works and fail to realize that they can expect little or no support from technology specialists. ©2003 The McGraw-Hill Companies

44 ©2003 The McGraw-Hill Companies
12.4 Outsourcing Another alternative to developing a computer system Delegation of work to a group outside of your organization for: A specified period of time A specified cost A specified level of service Outsourcing is the delegation of work to a group outside your organization for (1) a specified length of time, (2) a specified cost, and (3) a specified level of service. Outsourcing is big business, and not just limited to the technology area. According to a Yankee Group survey of 500 companies, 90 percent stated that they had outsourced at least one major business function and 45 percent stated that they had outsourced some major portion of their technology environment. In just the IT area, a survey estimated that outsourcing exceeded $120 billion in the year 2000. ©2003 The McGraw-Hill Companies

45 Ways an Organization Can Outsource
Purchasing horizontal software Purchasing vertical market software Hiring an outsource vendor to develop from scratch Purchasing horizontal market software, or general business software that has application in many industries. Horizontal market software includes accounts receivable, payroll, inventory management, logistics, and customer relationship management. Purchasing vertical market software, or software that is unique to a particular industry. Hiring an outsourcing vendor to develop software from scratch. p Fig ©2003 The McGraw-Hill Companies

46 How Outsourcing Compares to SDLC
Organization turns over much of the design, construction, implementation, and support steps to another organization Organization is still responsible for: Investigation Analysis Creating a request for proposal Systems Investigation Even if you outsource, you still need to determine the exact nature of the problem or opportunity. You also need to develop a preliminary budget. Systems Analysis It is still your responsibility to model the proposed system from a logical point of view. After all, it’s your business process. This documentation can be quite long and take several months to develop. Build a Request for Proposal (RFP) - the most important document in outsourcing is a request for proposal. A request for proposal (RFP) is a format document that outlines your logical requirements for the proposed system and invites outsourcing vendors to bid on its development. Evaluate Request for Proposal Returns and Select a Vendor - once you receive RFP returns, you must evaluate them. This is a difficult process, as each vendor will offer different alternatives. Once you choose a vendor, you enter into a legal and binding agreement. Test and Accept the Solution Once the vendor completes the system, you must fully test it. “Signing off” on a system means that the system works the way you want it to and that the vendor is released from any further development responsibilities. Systems Support and Relationship Re-evaluation As with all systems, you must continually monitor the system for its effectiveness. If you need changes, you can often contract the vendor to make those changes. As well, you must continually monitor your relationship with the vendor. ©2003 The McGraw-Hill Companies

47 ©2003 The McGraw-Hill Companies
Outsourcing Cycle Like end user development, outsourcing looks similar to the traditional systems development life cycle (SDLC). p Fig ©2003 The McGraw-Hill Companies

48 A System May be Targeted for Outsourcing When:
It is determined that the in-house IT specialists do not have enough time or resources to build a system The organization does not possess the expertise to develop a given system It is determined that it is cheaper to buy prewritten horizontal or vertical market software than it is to develop it from scratch ©2003 The McGraw-Hill Companies

49 Building a Request for Proposal (RFP)
RFP is a formal document that outlines the logical requirements for the proposed system and invites outsourcing vendors to bid on its development RFP can be long and complex, requiring months to create. Do not rush through it ©2003 The McGraw-Hill Companies

50 ©2003 The McGraw-Hill Companies
RFP: Outsourcing To tell an outsourcing vendor what you want, you must create a request for proposal. A request for proposal (RFP) is a formal document that outlines your logical requirements for the proposed system and invites outsourcing vendors to bid on its development. Note that RFPs are used for a variety of functions, purchases, construction, etc. p Fig ©2003 The McGraw-Hill Companies

51 Advantages/Disadvantages of Outsourcing
Outsourcing has both advantages and disadvantages. ©2003 The McGraw-Hill Companies

52 ©2003 The McGraw-Hill Companies
Evaluating an RFP Evaluate all bids and decide on which outsourcing vendor to use Once the vendor is decided upon, a lengthy and legal process follows during which a legally binding document must be developed that both organizations sign stating: exactly what work is to be carried out how and when payments will be made project time frame how your organization can get out of the contract if the outsourcing vendor does not live up to its end ©2003 The McGraw-Hill Companies

53 Test and Accept the Outsource Solution
Steps performed during testing and acceptance: software is completely tested Train users Convert old information to the new system Convert users to the new system If the software does not perform according to the specifications – DO NOT accept the system. Have the outsourcer fix the problem(s) immediately ©2003 The McGraw-Hill Companies

54 Systems Support and Relationship Evaluation
Perform a periodic review of the system Provide a formal mechanism through which users can request changes, and evaluate their worth Reevaluate your relationship with the outsourcing vendor ©2003 The McGraw-Hill Companies

55 ©2003 The McGraw-Hill Companies

56 ©2003 The McGraw-Hill Companies
12.5 Key Terms Systems design phase Systems implementation phase Systems investigation Systems support Traditional systems development life cycle (SDLC) End user development Outsourcing Prototyping Request for proposal Systems analyst Systems construction phase ©2003 The McGraw-Hill Companies

57 ©2003 The McGraw-Hill Companies
Review of Concepts Understanding Your Roles in Each Step of the SDLC When are you a business process expert, quality control analyst, and manager of other people? Understanding the Relationships among the SDLC and a Request for Proposal Identifying Steps within Phases of the SDLC A great way to study for your exam ©2003 The McGraw-Hill Companies

58 Hands On Projects E-Commerce
Researching Horizontal Market Software Buying Sports Gear Buying Event Tickets ©2003 The McGraw-Hill Companies

59 Hands On Projects Ethics, Security & Privacy
When Should You Consider Ethics, Security, and Privacy while Developing a System? During which phases is it most important? What to do When Software Produces the Wrong Result If you won the lottery because of a computer error, should you get the big prize? ©2003 The McGraw-Hill Companies

60 Hands On Projects on the Web
Researching IT Outsourcing Vendors Who provides vertical market software for schools? Understanding Degrees of Freedom Count the clicks Finding Free Flowcharting and Data Flow Diagramming Tools Building Synergistic Teams ©2003 The McGraw-Hill Companies

61 Hands On Projects Group Activities
Creating a Program Flowchart How do you get a driver’s license? Identifying Outsourcing at Your School Everyday Prototyping Creating a Data Flow Diagram for a Vending Machine How do you pay with a cell phone? ©2003 The McGraw-Hill Companies


Download ppt "Why is Packaged Software Sometimes Not Enough? Chapter 12"

Similar presentations


Ads by Google