(See related pages)
|
|
|
| Analysis phase | Involves end users and IT specialists working together to gather, understand, and document the business requirements for the proposed system. (See page(s) 85) |
| |
| |
| |
| Business requirement | A detailed knowledge worker request that the system must meet in order to be successful. (See page(s) 85) |
| |
| |
| |
| Critical success factor (CSF) | A factor critical to your organization’s success. (See page(s) 83) |
| |
| |
| |
| Design phase | Builds a technical blueprint of how the proposed system will work. (See page(s) 86) |
| |
| |
| |
| Development phase | Takes all of your detailed design documents form the design phase and transform them into an actual system. (See page(s) 88) |
| |
| |
| |
| Feature creep | Occurs when developers add extra features that were not part of the initial requirements. (See page(s) 84) |
| |
| |
| |
| Graphical user interface (GUI) | The interface to an information system. (See page(s) 87) |
| |
| |
| |
| GUI screen design | The interface to an information system. (See page(s) 87) |
| |
| |
| |
| Help desk | A group of people who responds to knowledge workers questions. (See page(s) 91) |
| |
| |
| |
| Implementation phase | Distributes the system to all of the knowledge workers and they begin using the system to perform their everyday jobs. (See page(s) 90) |
| |
| |
| |
| Insourcing | A project means that IT specialists within your organization will develop the system. (See page(s) 83) |
| |
| |
| |
| Integration testing | Verifies that separate systems can work together. (See page(s) 89) |
| |
| |
| |
| Joint application development (JAD) | Occurs when knowledge workers and IT specialist meet, sometimes for several days, to define or review the business requirements for the system. (See page(s) 85) |
| |
| |
| |
| Maintenance phase | Monitors and supports the new system to ensure it continues to meet the business goals. (See page(s) 91) |
| |
| |
| |
| Modeling | The activity of drawing a graphical representation of a design. (See page(s) 87) |
| |
| |
| |
| Online training | Runs over the Internet or off a CD-ROM. (See page(s) 90) |
| |
| |
| |
| Onshore outsourcing | Using organizations from developing countries to write code and develop systems. (See page(s) 104) |
| |
| |
| |
| Outsourcing | The delegation of specific work to a third party for a specified length of time, at a specified cost, and at a specified level of service. (See page(s) 83) |
| |
| |
| |
| Parallel implementation | Using both the old and new system until you’re sure that the new system performs correctly. (See page(s) 91) |
| |
| |
| |
| Pilot phase | Having only a small group of people use the new system until you know it works correctly and then adding the remaining people to the system. (See page(s) 91) |
| |
| |
| |
| Planning phase | Involves determining a solid plan for developing your information system. (See page(s) 83) |
| |
| |
| |
| Plunge implementation | Discarding the old system completely and immediately using the new system. (See page(s) 91) |
| |
| |
| |
| Project manager | An individual who is an expert in project planning and management, defines and develops the project plan, and tracks the plan to ensure all key project milestones are completed on time. (See page(s) 84) |
| |
| |
| |
| Project milestone | Represents a key date for which you need a certain group of activities performed. (See page(s) 84) |
| |
| |
| |
| Project plan | Defines the what, when, and who questions of system development including all activities to be performed, the individuals, or resources, who will perform the activities, and the time required to complete each activity. (See page(s) 83) |
| |
| |
| |
| Project scope | Clearly defines the high-level system requirements. (See page(s) 83) |
| |
| |
| |
| Project scope document | A written definition of the project scope and is usually no longer than a paragraph. (See page(s) 83) |
| |
| |
| |
| Proof-of-concept prototype | A prototype you se to prove the technical feasibility of a proposed system. (See page(s) 97) |
| |
| |
| |
| Prototype | A model of a proposed product, service, or system. (See page(s) 96) |
| |
| |
| |
| Prototyping | The process of building a model that demonstrates the features of a proposed product, service, or system. (See page(s) 96) |
| |
| |
| |
| Request for proposal (RFP) | A formal document that describes in detail your logical requirements for a proposed system and invites outsourcing organizations (which we’ll refer to as “vendors”) to submit bids for its development. (See page(s) 103) |
| |
| |
| |
| Requirement definition document | Defines all of the business requirements and prioritize them in order of business importance and place them in a formal comprehensive document. (See page(s) 85) |
| |
| |
| |
| Scope creep | Occurs when the scope of the project increases. (See page(s) 84) |
| |
| |
| |
| Selfsourcing (knowledge worker development, end user development) | The development and support of IT systems by knowledge workers with little or no help from IT specialists. (See page(s) 83) |
| |
| |
| |
| Selling prototype | A prototype you use to convince people of the worth of a proposed system. (See page(s) 97) |
| |
| |
| |
| Sign-off | The knowledge workers’ actual signatures indicating they approve all of the business requirements. (See page(s) 85) |
| |
| |
| |
| System testing | Verifies that the units or pieces of code written for a system function correctly when integrated into the total system. (See page(s) 89) |
| |
| |
| |
| Systems development life cycle (SDLC) | A structured step-by-step approach for developing information systems. (See page(s) 82) |
| |
| |
| |
| Technical architecture | Defines the hardware, software, and telecommunications equipment required to run the system. (See page(s) 87) |
| |
| |
| |
| Test condition | A detailed step the system must perform along with the expected result of the step. (See page(s) 89) |
| |
| |
| |
| Testing phase | Verifies that the system works and meets all of the business requirements defined in the analysis phase. (See page(s) 88) |
| |
| |
| |
| Unit testing | Tests individual units or pieces of code for a system. (See page(s) 89) |
| |
| |
| |
| User acceptance testing (UAT) | Determines if the system satisfies the business requirements and enables the knowledge workers to perform their job correctly. (See page(s) 89) |
| |
| |
| |
| User documentation | Highlights how to use the system. (See page(s) 90) |
| |
| |
| |
| Workshop training | Set in a classroom-type environment and led by an instructor. (See page(s) 90) |