Business Information Systems - Chapter 7

The process of acquiring and implementing an information system for a business. This involves choosing the right approach, like buying off-the-shelf software, developing a custom solution, or using user-developed applications.

A structured and sequential series of phases involved in the development of any information system project, ensuring a systematic approach from initiation to maintenance. It guides the whole process from idea to live system.

A major stage in the SDLC where the feasibility of the proposed information system is thoroughly examined. This involves evaluating its technical, economic, and operational viability. The study assesses its suitability for the business.

A phase in the SDLC where the detailed requirements of the proposed information system are captured through user interviews, observation, and analyzing existing systems. It defines the 'what' of the system.

The stage in the SDLC where the design of the information system is meticulously planned. This involves outlining the user interface, program modules, security measures, and database transactions. It defines the 'how' of the system.

This phase focuses on the actual development of the software, including writing codes, building release versions, and constructing and populating the database. It's the "construction" phase of the system.

The stage where the developed system is brought into practice. This involves putting the system into operation, testing it, and training end-users. It's the "moving in" phase of the system.

A crucial stage in the SDLC where the operating system is continually monitored for any required adjustments or improvements. This involves fixing bugs, adding new features, and ensuring the system runs smoothly over time. Think of it as the "maintenance and upkeep" of the system.

An alternative approach for acquiring information systems that focuses on involving users actively in the development process by creating and refining prototypes throughout the development journey.

A preliminary version of the information system being developed, which users can review and provide feedback on. This allows for iterative development and fine-tuning based on user input.

A method of acquiring software that involves purchasing ready-made applications from vendors, which are designed to be used by multiple companies. It's like buying a "pre-built" system.

The software developed from scratch by a team of IS professionals to meet the specific needs of a particular business. It's like tailoring a suit for a unique fit.

Software developed by non-IS professionals, such as business users themselves. This approach is usually used for more limited and departmental needs. Think of it as "DIY" information systems.

The method where the development of a system is outsourced to a third-party software house, rather than being done in-house. Think of it as "hiring" a team of developers to build a system.

The process of developing information systems by a team of professionals who work for the organization, rather than outsourcing it. Think of it as "building" a system internally.

The ability of a system to function within required performance standards, including speed, volume, usability, and reliability. Think of it as the "practical" limits of the system.

The evaluation of whether the proposed system aligns with the organizational culture, user skills, and attitudes. It ensures the system is "acceptable" to the organization.

The assessment of whether the necessary technology exists or can be created to support the proposed system. Think of it as the system's "technical viability"

The evaluation of whether the proposed system will generate more benefits than its cost. Think of it as the system's "financial viability"

The use of formal structured methodologies, like the SDLC, for developing information systems. Think of it as a "formal" and "structured" approach to system development.

A mismatch between the understanding of the business users and the capabilities of the information system developers, leading to potential misunderstandings and misaligned deliverables. Think of it as a "communication gap" between users and developers.

A situation where developers tend to work in isolation, not involving users adequately in the development process, leading to reduced user buy-in and potentially functional issues. Think of it as "working in a bubble" without user collaboration.

A situation where the focus is on measuring the quality by how closely the delivered system adheres to the technical specifications, rather than meeting the actual needs of the users, which can lead to inefficiencies and dissatisfaction. Think of it as "ticking boxes" of specifications instead of addressing user requirements effectively.

The practice of evaluating the success of a project after it has been implemented in a live environment, learning lessons, and making adjustments based on the outcome. It's like conducting a "post-mortem" to understand what went well and what could be improved.

A software product that is designed and sold to be used by various companies, allowing for easy integration and customization. It's like buying a "standard" house that can then be personalized.

The process of customizing or configuring packaged software to meet the specific requirements of a particular organization. Think of it as "personalizing" a standard product.

The ability to connect or integrate different software applications with each other, allowing seamless data exchange and streamlined workflows. Think of it as creating a "network" of different software systems working together.

The ability of software to adapt and change over time to meet evolving business requirements and technological advancements. Think of it as software that can "grow" with a company.

The process of converting data from an older system or format to a new system or format during implementation. Think of it as "moving files" from an old computer to a new one.