©1999 Addison Wesley Longman Slide 12.1 Building and Maintaining Information Systems 12.

©1999 Addison Wesley Longman Slide 12.1

Building and MaintainingInformation Systems

12


Table 12.1Microsoft Programs Software for a New Release



CUSTOMER

Customers who purchase Microsoft’s software

Microsoft itself, because it must create a basis for new releases and because the software reflects its strategy



PRODUCT

New release of a software product



BUSINESS PROCESS

Major steps:•Identify features customers want and features Microsoft wants for strategic reasons•Decide which features to include in a release•Divide the work among small teams and break each team’s work into three phases•Program and test features in each module•Performs a daily build to make sure all parts of the product work together•Decide which features to delay to subsequent releases•Test the entire release•Package and distribute the new release

Rationale:

•Produce releases that combine what the customers want and what Microsoft wants to produce

•Maintain creativity and responsiblity by assigning subprojects to small teams

•Maintain control and compatibilty by doing a daily build



PARTICIPANTS

Programmers and testers

INFORMATION

Features to be included in the release

Programs

Examples for testing

Project plan

TECHNOLOGY

(Not mentioned in the case)Programming languages

Debugging techniques

Computers that run the programs


Figure 12.1Costs in design errors detected at different times


Figure 12.2Links between the four phases of an information system


Table 12.2Common Issues and Problems in Each Phase of an Information System

INITIATION•Can we agree on the purposes and goals of the proposed system?•Are the requirements unnecessarily elaborate and expensive?

DEVELOPMENT•Can we assure that the system genuinely solves the user’s problems?•Can we assure that users will participate effectively in the design process?

IMPLEMENTATION•Can we convert effectively and painlessly from the old system to the new system?•Can we solve political issues related to changes in power relationships?

OPERATION AND MAINTENANCE•Can we keep system performance and uptime at acceptable levels?•Can we correct bugs and enhance the system to keep it focused on current business problems?


Table 12.3Differences between Four System Life Cycles

TRADITIONAL SYSTEM LIFE CYCLEIssue addressed: ControlSummary: Go through a fixed sequence of steps with signoffs after each step and careful documents.

PROTOTYPEIssue addressed: KnowledgeSummary: Quickly devellop a working model of the system; use the model to gain experience and decide how the final syatem should operate.

APPLICATION PACKAGESIssue addressed: Resources and timingSummary: Purchase an existing information system from a vendor; customize the system if necessary.

APPLICATION PACKAGESIssue addressed: Responsiveness Summary: Provide tools and support that make it practical for end users to develop their own information systems.


Box 12.1The capability maturity model

Level 1- INITIALProcesses are ad hoc and sometimes chaotic. Because few processes are defined, successful projects often depend on heroic individual effort.

Level 2- REPEATABLEBasic project management processes are used to track cost, schedule, and functionality. The discipline exists to repeat previous success with similar projects.

Level 3- DEFINEDBoth management and technical processes are documented and integrated into a standard software process for the organization. Projects use an approved, tailored version of the standard software processes.

Level 4- MANAGEDDetailed measures of the software process and product quality are collected and that information is used to understand both the product and the process in quantitative terms.

Level 5- OPTIMIZINGContinuous process improvement is facilitated by quantitative feedback from

the process and by doing pilot studies of innovative ideas and technologies.


Figure 12.3Steps in the development phase of the traditional system life cycle


Figure 12.4Steps in the implementation phase of the traditional system life cycle


Table 12.4Steps and Deliverables in the Traditional System Life Cycle

INITIATION

•Feasibility studyDegree of user participation- HighKey deliverable, plan, or document- Functional specificationKey Participants- User representatives, management, and technical staff

•Project planningDegree of user participation - MediumKey deliverable, plan, or document - Project planKey Participants deliverable, plan, or document - User representatives, management, and technical staff



DEVELOPMENT•Detailed requirements analysisDegree of user participation - HighKey deliverable, plan, or document - External specificationKey Participants- User representatives, management, and technical staff•Internal system designDegree of user participation - NoneKey deliverable, plan, or document - Internal specificationKey Participants- Programmers and technical staff•Hardware acquisition and installationDegree of user participation - NoneKey deliverable, plan, or document - Hardware plan Hardware operationalKey Participants- Technical staff•ProgrammingDegree of user participation - NoneKey deliverable, plan, or document - Individual programs debuggedKey Participants- Programmers•DocumentationDegree of user participation- MediumKey deliverable, plan, or document - User and programmer documentationKey Participants- Technical staff and users•System testingDegree of user participation - MediumKey deliverable, plan, or document - Test plan Completed system testKey Participants- Programmers and users



IMPLEMENTATION•Implementation planningDegree of user participation - HighKey deliverable, plan, or document - Implementation planKey Participants- Training staff, users, and management

•TrainingDegree of user participation - HighKey deliverable, plan, or document - Training materialsKey Participants- Trainers and users

•ConversionDegree of user participation - HighKey deliverable, plan, or document - System in useKey Participants- Users and project team

•Acceptance testingDegree of user participation - HighKey deliverable, plan, or document - System acceptedKey Participants- Users and project team

•Postimplementation auditDegree of user participation - HighKey deliverable, plan, or document - Audit reportKey Participants- Users and management



OPERATION AND MAINTENANCE

•Ongoing operation and supportDegree of user participation - LowKey deliverable, plan, or document - Operations manualKey Participants- Technical staff

Degree of user participation - LowKey deliverable, plan, or document - Usage statisticsKey Participants- Technical staff and users

Degree of user participation - HighKey deliverable, plan, or document - Enhancement requests and bug fix requestsKey Participants- Technical staff and users

•MaintenanceDegree of user participation - MediumKey deliverable, plan, or document - MaintenanceKey Participants- Technical staff and users

•Absorption or terminationDegree of user participation - ======Key deliverable, plan, or document - ======Key Participants- ======


Table 12.5System Life Cycle Based on a Prototype

INITIATIONUsers and developers agree to develop a prototype because they need experience with a working model before designing a final system.

DEVELOPMENTWorking iteratively with users, a prototype is developed and improved. Later, decide whether to complete the prototype or switch to a traditional life cycle.

IMPLEMENTATIONAccomplish parts of implementation along with development as users work with the prototype system. Dispel skepticism about whether the system will meet users’ needs.

OPERATION AND MAINTENANCEMay be similar to a traditional life cycle. May require less maintenance because the system fits users’ needs more accurately. May require more maintenance because the system is not constructed as well.


Figure 12.5Using a prototype approach


Figure 12.6Creating a data input form

(a) (b)


Figure 12.7Example of a commercial application package


Table 12.6System Life Cycle for Acquiring an Application Package

INITIATIONMay start with user’s or manager’s recognition of a business problem or with a sales call from a vendor.

DEVELOPMENTThe vendor develops the software, although the purchase still performs some typical development activities, such as determining detailed requirements. Development may include customization of the software and user documentation.

IMPLEMENTATIONImplementation starts by deciding exactly how the package will be used. It often relies on the vendor’s staff because they have the greatest knowledge of the system.

OPERATION AND MAINTENANCEOperation occurs as it would with a traditional life cycle. Maintenance is different because the vendor maintains the software based on requests from customers and demands of the market.


Box 12.2Selecting an application package

APPLICATION FEATUREScompletenessquality of reportsease of usedocumentation

TECHNICAL FEATURESuse of DBMStransportabilityexpandability

VENDOR COMPARISONfinancial strengthmanagement strengthcommittment to product

ECONOMIC COMPARISONpurchase pricemaintenance contractconsulting chargesconversion cost

Total weighted score

WEIGHT2.51.02.32.8

2.80.81.2

2.01.32.6

2.01.50.62.3

SCORE9 7 89 5 95 9 63 9 7

8 7 32 5 64 5 5

9 7 56 9 84 7 9

7 5 77 7 85 6 85 3 5

A B C A B C

WEIGHTED SCORE22.5 17.3 20.0 9.0 5.0 9.011.5 20.7 19.6 8.4 25.2 19.6

22.4 19.6 8.4 1.6 4.0 4.8 4.8 6.0 6.0

18.0 14.0 10.0 7.8 11.7 10.410.4 18.2 23.4

14.0 10.0 14.010.5 10.5 12.0 3.0 3.6 4.811.5 6.9 11.5

155.4 172.9 167.7


Figure 12.8Vendor responsibilties for application packages


Figure 12.9A tool for end-user devlopment


Table 12.7System Life Cycle for End-User Development

INITIATIONBecause the user will develop the information system, a formal functional specification is unnecessary.

DEVELOPMENTThe user develops the system using tools that do not require a professional level of programming knowledge. Information systems that are critical to the company or have many users require more extensive testing, documentation, and usage procedures.

IMPLEMENTATIONImplementation is simplified because the developer is the user.

OPERATION AND MAINTENANCEEnd users are responsible. Long-term maintenance and technical quality become larger issues because the end users have other work to do and are not professional programmers.


Figure 12.10Roles in end-user development


Table 12.8Common Approaches to Issues in End-User Computing

HARDWARE SELECTION AND MAINTENANCEThe IS staff selects the types of harware that can be purchased and maintains the hardware.

SOFTWARE SELECTIONThe IS staff selects the the spreadsheet software and other end-user software that can be purchased and used.

TRAININGThe IS staff provides training for end users on selected hardware and software.

DATA AVAILABILITYEnd users control their own data and share data using LANs. Corporate data are downloaded from central computers.

DATA SECURITYLimit access to only the data users need.

SYSTEMS ANALYSISHelp end users with systems analysis and design where necessary. Provide help lines and other types of support.


Table 12.9Advantages and Disadvantages of Four System Life Cycles

LIFE CYCLE:

Traditional system life cycle

Prototype

Application package

End-user development

©1999 Addison Wesley Longman Slide 12.1 Building and Maintaining Information Systems 12.

Documents

Transcript of ©1999 Addison Wesley Longman Slide 12.1 Building and Maintaining Information Systems 12.