MIS 301 Extra Credit Study Guide

Chapter 10 review page covering software development, the make-buy-rent decision, requirements, the software development lifecycle, Agile versus Waterfall, LCNC tools, scope creep, project failure, and the role users and managers play in successful projects.

Chapter 10: Software Development

What Chapter 10 is mainly about

Chapter 10 explains how organizations decide whether to build, buy, or rent software, why systems development is much more than just coding, and why software projects succeed or fail. It emphasizes that systems development involves all five IS components, not just software, and that strong requirements, user involvement, good methodology, and realistic project management matter more than flashy technology alone.

Main takeaway: Technology projects usually fail because of management, requirements, scope, communication, and leadership problems, not because coding is impossible. The most important role for future managers and users is to take responsibility for requirements, stay involved throughout development, and help control scope, time, and cost.

What this page includes

  • Precise Chapter 10 vocabulary
  • Explanations from the textbook and slides
  • A scenario-based 5-question quiz
  • Visible chapter citations and works cited

How to study with it

  • Know make, buy, and rent clearly
  • Understand Agile versus Waterfall deeply
  • Learn why scope creep is so dangerous
  • Focus on why projects fail and how managers help prevent failure

Chapter 10 Vocabulary

Systems Development The process of creating and maintaining information systems through analysis, design, implementation, testing, deployment, and ongoing improvement.
Citation: Software Project Management slides, What Is Systems Development?
Requirements The complete and accurate description of what a system must do, who will use it, what constraints apply, and what outcomes it must support.
Citation: Software Project Management slides, Your Future Role and Why Is IT Development Difficult?
Make, Buy, or Rent Decision The strategic choice between building software internally, purchasing software from a vendor, or renting hosted software such as SaaS.
Citation: Chapter 10 review guide, make-buy-rent section
Software Development Lifecycle (SDLC) The structured sequence of planning, design, development, testing, deployment, and maintenance used to build and improve software systems.
Citation: Chapter 10 review guide, SDLC definition
Software Development Methodology A formal approach for organizing software development tasks, communication, decision-making, and delivery.
Citation: Systems Development Methodologies slide
Waterfall Method A relatively linear, sequential approach to development that emphasizes defining requirements up front and following a structured blueprint through the project.
Citation: The Waterfall Method slide
Agile Method An iterative, flexible development approach that emphasizes smaller increments, frequent review, continuous improvement, and faster delivery.
Citation: Agile Method slide and Agile Process slide
Triple Constraint The project management relationship among scope, resources, and schedule, where changes to one usually affect the others.
Citation: Key Systems Development Issues slide and Chapter 10 review guide
Scope Creep The uncontrolled addition of new features or requirements beyond the original plan, which increases cost, delays delivery, and raises project failure risk.
Citation: Chapter 10 review guide and Why Do Technology Projects Fail? slides
Citizen Developer A non-professional programmer, often a business user, who creates applications using low-code or no-code tools.
Citation: Chapter 10 review guide, vocabulary section
Low Code or No Code (LCNC) Environment A highly visual software development environment that allows users to create systems with little or no traditional coding.
Citation: LCNC slide and Chapter 10 review guide
Shadow IT Systems, tools, or applications created or used outside formal IT governance, often increasing security, compliance, and data quality risks.
Citation: LCNC concerns slide and Chapter 10 review guide implications
Programming Language A formal language with standards, syntax, statements, and instructions used to write software.
Citation: Writing Software slide and Chapter 10 review guide
Integrated Development Environment (IDE) A software application that provides programming tools such as an editor, debugger, and compiler in one place for developers.
Citation: Writing Software slide
Compilation The process of converting code written in a programming language into a form that a microprocessor can understand and execute.
Citation: Compilation vs Interpretation slide
Interpreted or Scripting Language A language whose code is executed within an application or runtime environment rather than fully compiled in advance for direct processor execution.
Citation: Compilation vs Interpretation slide
Prototype A mock-up or early model of part of a system used to help users evaluate requirements, interfaces, and workflows.
Citation: Prototypes and Wireframes slide
Wireframe A simplified visual representation of a system interface used to communicate design ideas and gather feedback before full development.
Citation: Prototypes and Wireframes slide
Compliance Adhering to laws, regulations, rules, and standards when building or using software systems.
Citation: Chapter 10 review guide, vocabulary section and LCNC concerns slide
Total Cost of Ownership (TCO) The full long-term cost of a software system, including development, training, support, maintenance, upgrades, and related business impacts.
Citation: Chapter 10 review guide, TCO section
Brook’s Law The principle that adding more people to a late software project can make the project even later because coordination costs and diseconomies of scale increase.
Citation: Why Is IT Development Difficult? slide
Product Owner The person responsible for defining requirements and prioritizing features, especially in Agile-style development environments.
Citation: Chapter 10 review guide, vocabulary section

Key Concepts and Explanations

1. Systems development is not just coding

Chapter 10 stresses that systems development includes hardware, software, data, processes, and people. It requires business knowledge, project setup, goal definition, requirements gathering, testing, review, and change management. This is why many software projects fail even when the coding itself is not the hardest part.

2. Requirements are the single most important managerial contribution

The slides make this point very directly. Future users and managers must take responsibility for requirements because developers cannot build the right system if the business does not clearly explain what it needs. Unclear, incomplete, or changing requirements create confusion, rework, delays, and wasted resources.

3. The make, buy, or rent decision depends on more than price

Firms build when the system is strategically important or highly customized, buy when software is standardized and available on the market, and rent when hosted solutions can meet the need quickly and efficiently. The real decision depends on TCO, time, customization, internal expertise, compliance, and how strategically important the software is to competitive advantage.

4. Agile is dominant because change is normal in software

Waterfall sounds logical because it assumes firms can define everything up front, but software projects rarely stay stable long enough for that assumption to hold. Agile works better in many situations because it allows planning, design, development, testing, deployment, and review to happen in smaller repeated cycles as the project evolves.

5. Scope creep is the biggest threat because it breaks the triple constraint

When more features and requirements keep getting added, scope expands, which usually increases cost and extends the schedule. If leaders do not control scope, teams start missing deadlines, overusing resources, and producing weaker results. This is why Chapter 10 repeatedly treats scope creep as one of the biggest threats to project success.

6. Most technology failures are management failures

The chapter lists many reasons projects fail: poor goals, weak leadership, poor communication, bad forecasting, inadequate testing, politics, lack of executive support, immature technology, and unrealistic time pressure. The deeper lesson is that failure usually comes from planning and management problems, not simply from technical difficulty.

Good Chapter 10 study habit: do not study development as a programmer-only topic. Ask what managers and users must do before, during, and after development to keep the system aligned with business needs, realistic scope, and strong execution.

Development Methodologies, LCNC, and Why Projects Fail

Chapter 10 compares major development approaches and shows how newer tools such as LCNC can increase speed while also raising governance and compliance risks.

1. Waterfall is structured, but rigid
Waterfall tries to define requirements up front and then move forward in a linear sequence. That can work when needs are stable, but software projects often change too much for this to remain realistic.
2. Agile accepts uncertainty better
Agile uses smaller cycles of planning, design, development, testing, deployment, and review. This makes it easier to adapt when requirements change and helps teams ship usable products more frequently.
3. Prototypes and wireframes improve communication
Mock-ups help users react to something concrete instead of abstract descriptions. They clarify requirements, expose misunderstandings early, and create a better communication bridge between developers and business users.
4. LCNC expands who can build software
Citizen developers can create useful tools quickly, especially for simple internal needs or rapid prototyping. However, without oversight, LCNC can produce inconsistent data, duplicate costs, security risks, and compliance violations.
5. Healthcare.gov shows both failure and recovery lessons
The failed launch reflected weak authority, poor coordination, inadequate measurement, and poor user experience. The rescue succeeded when strong leadership, clear priorities, reporting, coordination, and Agile-style stand-up practices were added.
Important: Chapter 10 argues that users must stay involved. Development is not complete until work is reviewed, tested, approved, and aligned with real business use. Good software is built with users, not just for users.

Chapter 10 Quiz

These questions are scenario-based and designed to feel closer to actual MIS test questions.

1. A company begins a software project with a clear budget and timeline, but executives keep adding small "must-have" features after development has already started. The team falls behind schedule and costs rise. Which Chapter 10 idea best explains what is happening?

2. A hospital asks business users to stay involved throughout development, review work at each phase, define test conditions, and approve deliverables before the next stage begins. Which Chapter 10 lesson does this most closely reflect?

3. A startup needs a simple internal workflow tool quickly and uses a low-code platform to build it. Later, the company realizes the app stores inconsistent customer data, lacks documentation, and creates security concerns because IT was barely involved. Which Chapter 10 concept best explains this problem?

4. A firm is building a system in a fast-changing environment where requirements are likely to evolve, and leaders want frequent releases and constant feedback. Which methodology is the strongest fit according to Chapter 10?

5. A government website launches with weak coordination, unclear authority, bad user experience, poor reporting systems, and major bugs. A rescue team later adds strong leadership, clear priorities, stand-up meetings, and better coordination, and the project improves quickly. Which Chapter 10 point is most clearly illustrated?

Answer Key and Explanations

Question 1

Correct answer: A

This is a classic scope creep problem. As new features are added after work begins, scope expands and the triple constraint is affected. More scope usually means more time, more cost, or both. The other answers do not match the project management problem being described.

Question 2

Correct answer: B

The slides emphasize that taking responsibility for requirements is one of the most important tasks future users and managers perform. Users must help define, review, test, and approve what the system is supposed to do. The other options directly conflict with the chapter’s core message.

Question 3

Correct answer: A

Chapter 10 presents LCNC as powerful but risky. It can speed development and enable citizen developers, but without IT governance it can create poor-quality systems, inconsistent data, security concerns, and compliance problems. The other options either misunderstand LCNC or make claims the chapter does not support.

Question 4

Correct answer: B

Agile is the strongest fit when requirements are changing and leaders want frequent releases, repeated review, and ongoing improvement. Waterfall is more rigid and depends on up-front stability. The other options are clearly unrelated or much too extreme.

Question 5

Correct answer: B

The Healthcare.gov story is used to show that project success or failure is often driven by leadership, authority, coordination, reporting, priorities, and communication. The rescue worked because management discipline improved, not because the system suddenly had different hardware.

Works Cited