Chapter 4: System Acquisition and Development
I. Introduction
Welcome to Chapter 4, where we explore different approaches to system acquisition
and development. Organizations must decide whether to build custom software or buy
off-the-shelf solutions, and they must choose between traditional (Waterfall), Agile, and
Rapid Application Development (RAD) methodologies. Today, we will compare these
approaches and learn how to select the best strategy based on project needs.
II. Main Content
A. Buy vs. Build Approach
Definition and Key Differences
Buy (Off-the-Shelf Software):
o Purchasing pre-built software from vendors (e.g., Microsoft Office, SAP,
Salesforce).
o The software is already developed, tested, and available for immediate
use.
o Best when standard solutions meet most business needs.
Key Differences:
Standardization: Designed for a broad user base, offering a set of
standard features and functionalities.
Vendor Dependency: Relies on the vendor for updates, support, and
the software's future roadmap.
Predictable Costs (Initially): Upfront costs are usually clear (licensing
fees, subscription costs).
Faster Implementation: Can often be deployed relatively quickly.
Build (Custom Development):
o Developing a system in-house or outsourcing development.
o The software is created from the ground up to meet your organization’s
unique needs.
o Best when unique business processes require tailored solutions.
Key Differences:
Tailored Solution: Precisely matches your specific business
processes and requirements.
Full Control: You have complete control over the design, features,
and future development of the software.
Unpredictable Costs (Potentially): Development costs can be
significant and may be subject to changes during the project.
Longer Implementation: Requires time for planning, design,
development, testing, and deployment.
Advantages & Disadvantages:
Factor Buy (Off-the-Shelf) Build (Custom)
Cost Lower upfront cost Higher development cost
Time to Market Faster deployment Longer development cycle
Customization Limited flexibility Fully customizable
Maintenance Vendor handles updates Internal team manages updates
Integration May require middleware Built for seamless integration
Scalability Depends on vendor Designed for future growth
When to Choose:
Buy:
o When standard solutions meet 80%+ of requirements. // address the
majority of your core business process or requirements
o When budget and time constraints exist.
o Example: Accounting software (QuickBooks).
Build:
o When unique workflows require customization.
o When competitive advantage depends on proprietary tech.
o Example: AI-driven logistics optimization system.
B. Waterfall System Development Process
Definition: A linear, sequential approach where each phase must be completed before
moving to the next.
Phases:
1. Requirements Gathering – Define system needs.
2. System Design – Plan architecture and specifications.
3. Implementation – Develop and code the system.
4. Testing – Verify functionality and fix bugs.
5. Deployment – Release the system to users.
6. Maintenance – Provide updates and support.
Limitations:
Inflexible to changes after a phase is completed.
Long delivery time; working product comes late.
High risk if requirements are unclear.
Pros and Cons of the Waterfall Model
Pros:
Objectives are easy to translate and align to
Enforces discipline and enables strict adherence to timelines
Planning takes absolute precedence enabling predictability
Testing specifications are predetermined
Issues are identified early
Cons:
Delivery times are typically longer
Very rigid and may not allow for a change in direction
Will require a hard restart if changes are significant
Does not include the client or end user in the development process
C. Agile Development
Definition: An iterative, flexible approach focusing on incremental delivery and
collaboration.
Key Principles:
✔ Customer collaboration over rigid contracts.
✔ Working software over extensive documentation.
✔ Responding to change over following a fixed plan.
✔ Frequent iterations (sprints) with continuous feedback.
Benefits:
Faster delivery of usable features.
Adaptable to changing requirements.
Strong team and customer collaboration.
Challenges:
Requires high user involvement.
Difficult to predict timelines and costs.
Not ideal for highly regulated industries with strict documentation needs.
D. Rapid Application Development (RAD)
Definition: A flexible, prototype-driven approach emphasizing rapid iterations and user
feedback.
Key Features:
✔ Prototyping – Quick mockups to refine requirements.
✔ User Involvement – Continuous feedback loops.
✔ Reusable Components – Speeds up development.
✔ Time-Boxed Phases – Faster delivery than Waterfall.
When to Use RAD:
When requirements are unclear at the start.
When fast delivery is critical (e.g., startups, MVPs).
When user feedback is essential (e.g., UI/UX-heavy apps).
Limitations:
Requires experienced developers.
Not ideal for large-scale, complex systems.
Can lead to technical debt if not managed well.
E. Comparison: Waterfall vs. Agile vs. RAD
Aspect Waterfall Agile RAD
Flexibility Low High Very High
Customer Mostly at start Continuous High (prototype
Involvement reviews)
Delivery Time Long (full product at Short (incremental) Very Fast
end) (prototypes first)
Documentation Extensive Minimal Moderate
Best For Stable requirements Changing Fast prototyping &
requirements feedback
F. Buying Off-the-Shelf Software
Factors to Consider:
1. Vendor Reputation – Reliability, support, and reviews.
2. Cost – Licensing fees, upgrades, and hidden costs.
3. Customization – Can it be tailored to business needs?
4. Integration – Compatibility with existing systems.
5. Scalability – Can it grow with the business?
Best Practices:
Conduct a pilot test before full deployment.
Negotiate service-level agreements (SLAs) for support.
Assess vendor lock-in risks (difficulty switching later).
III. Application Activity
Scenario-Based Discussion:
Divide into groups and analyze the following cases:
1. A small business needs an inventory system. Should they buy or build? Why?
2. A bank is developing a new mobile app. Would Waterfall, Agile, or RAD be
better? Justify.
3. A company wants to purchase CRM software. What factors should they
evaluate?
IV. Conclusion & Key Takeaways
✔ Buy vs. Build depends on cost, time, and customization needs.
✔ Waterfall is structured but inflexible; Agile is adaptive; RAD is fastest for prototyping.
✔ When buying off-the-shelf software, assess vendor reliability, cost, and integration.
✔ The best approach depends on project requirements and organizational context.
