MIS 301 Study Guide
Chapter 10 focuses on software development and software project management. It explains why systems development is difficult, why requirements matter so much, and how projects must balance scope, resources, and time. The chapter also compares major development methodologies such as Waterfall and Agile, explains why prototypes and wireframes help, and examines the risks of low-code/no-code development and common causes of project failure. :contentReference[oaicite:1]{index=1}
Citizen Developer – A nonprofessional programmer or end user who creates applications using tools such as low-code/no-code platforms.
Compliance – Meeting legal, regulatory, and policy requirements when building and operating information systems.
Feature Creep / Scope Creep – The gradual expansion of a project’s requirements during development, often causing delays, confusion, and cost overruns.
Product Owner – The person responsible for defining priorities, clarifying requirements, and helping ensure a product delivers business value.
Programming Language – A formal language with rules, syntax, and instructions used to write software. :contentReference[oaicite:2]{index=2}
Low Code / No Code (LCNC) Environment – A highly visual software development environment that allows users to create systems with little or no traditional coding required. :contentReference[oaicite:3]{index=3}
Total Cost of Ownership (TCO) – The full long-term cost of a system, including development, implementation, support, training, maintenance, and change over time.
Triple Constraint – The project management tradeoff among scope, resources, and schedule. Changing one usually affects the others. :contentReference[oaicite:4]{index=4}
Software Development Lifecycle – The overall process used to plan, design, build, test, deploy, and maintain software systems.
Software Development Methodologies – Structured approaches used to organize and manage software creation and deployment, such as Waterfall and Agile. :contentReference[oaicite:5]{index=5}
The slides explain that systems development is the process of creating and maintaining information systems. It involves all five IS components, not just software, and requires business knowledge and management skill in addition to technical expertise. :contentReference[oaicite:6]{index=6}
Software development is hard because requirements are often unclear, requirements change, technology changes during the project, and schedule and budget are hard to estimate. The slides also note diseconomies of scale and Brook’s Law: adding more people can make a late project even later. :contentReference[oaicite:7]{index=7}
Every project must balance scope, resources, and time. Expanding scope usually requires more time or more resources. Cutting time may force a reduction in scope or create pressure that reduces quality. :contentReference[oaicite:8]{index=8}
One of the biggest themes in Chapter 10 is that business users must take responsibility for requirements. Users need to help define what the system should do, manage scope creep, and define test conditions so IS professionals have clear direction. :contentReference[oaicite:9]{index=9}
Waterfall is a more linear, sequential approach that tries to define requirements up front. Agile is iterative, with smaller cycles of planning, designing, developing, testing, deploying, and reviewing. The slides describe Agile as the dominant method because it is faster and more flexible than Waterfall. :contentReference[oaicite:10]{index=10}
Prototypes and wireframes help users evaluate requirements before the final system is built. They give users a way to test interfaces, see data in context, and communicate more clearly with developers, although they must be presented as mock-ups rather than finished systems. :contentReference[oaicite:11]{index=11}
Low-code/no-code tools allow citizen developers to build applications quickly, but they also create governance risks. Poorly designed systems may collect inconsistent data, duplicate costs, create security issues, or violate laws and regulations such as HIPAA, FERPA, or GDPR. :contentReference[oaicite:12]{index=12}
The slides list many reasons projects fail: poor goals, weak leadership, lack of executive support, poor communication, scope creep, inadequate testing, inappropriate technical choices, and political conflict. The Healthcare.gov example shows that clearer authority, better coordination, and Agile-style stand-up meetings helped rescue a failing project. :contentReference[oaicite:13]{index=13}
A company starts building a new internal system. Halfway through the project, managers keep adding new features and changing what they want the system to do. The development team now expects the launch date to slip and the budget to increase.
Which concept best explains this problem?
A. Network effectsCorrect Answer: B
Scope creep occurs when requirements expand during development. This usually causes delays, cost increases, and confusion about priorities. The other options are unrelated to changing project requirements.
A team wants to finish a software project faster without reducing the number of features. Management suggests simply adding many more people to the project right away, but a senior manager warns that this may actually slow things down.
Which Chapter 10 idea supports the senior manager’s concern?
A. Brook’s LawCorrect Answer: A
Brook’s Law says that adding more people to a late software project can make it later. As teams grow, coordination gets harder and average contribution per worker can fall. The other options refer to different topics.
A business wants a development approach that allows for repeated testing, user feedback, and frequent improvements in smaller cycles instead of one long sequential process.
Which methodology best fits that goal?
A. WaterfallCorrect Answer: C
Agile is iterative and emphasizes continual development, testing, deployment, and review. It is more flexible than Waterfall and better suited for changing requirements and fast feedback cycles.
A department employee builds an app with a low-code tool to solve a local problem. The app works at first, but later the company discovers it stores duplicate data, does not follow security rules, and may violate regulatory requirements.
What is the main lesson from this example?
A. LCNC tools remove the need for governanceCorrect Answer: B
The slides warn that LCNC tools can create inconsistent data, duplicate costs, security problems, and compliance issues if they are not governed well. The problem is not the tool itself, but the lack of proper systems design and oversight.
A project team creates a rough screen mock-up so business users can react to the layout, test the interface idea, and clarify what they actually need before coding moves too far.
Why are prototypes and wireframes helpful in this situation?
A. They eliminate the need for testing laterCorrect Answer: C
Prototypes and wireframes help users see requirements in context, test interface ideas, and communicate more clearly with developers. They are especially useful for reducing misunderstandings early, but they do not replace testing or guarantee the final system is nearly finished.