Reuse-Oriented Software Engineering primarily relies on the integration of existing components, which reduces the need for new development and thus accelerates response to changes. However, because it involves commercial off-the-shelf (COTS) components, adapting to changes in user requirements or market needs can be limited by the constraints of these components. This often requires compromising on ideal requirements or accepting less tailored solutions, highlighting the importance of selecting the right components that closely align with expected changes as much as possible .

Reuse-oriented software engineering might not be suitable for large systems because it depends on integrating reusable components, which can lead to complex system structures and management challenges. Large systems often involve different teams working on various parts, requiring a stable framework and architecture that reuse-oriented approaches may lack. Therefore, coordinating multiple reusable components can be inefficient and may result in a system that does not fully meet users' needs or stability requirements .

Prototypes that focus on functional requirements are typically used to validate specific functionalities, improve user-interface design, and refine user requirements through direct interaction and feedback. However, by not thoroughly addressing non-functional requirements such as performance, security, and usability, there is a risk of underestimating these critical aspects, which can lead to architectural issues or underperformance in the final product. Therefore, it is crucial to integrate non-functional requirement considerations early in subsequent development phases, despite the functional focus of initial prototypes .

The Waterfall Model approaches software process planning in a sequential manner where all process activities are planned in advance and follow a fixed order: specification, development, validation, and evolution. Its advantages include simplicity, ease of management, and clearly defined phases. The disadvantages are high risk, lack of flexibility for changing requirements, and delayed production of working software until late stages, making it unsuitable when customer requirements are likely to change or when quick delivery is crucial .

Prototypes in software development serve as initial versions of a system used to visualize features and refine requirements early on. They help in checking customer requirements and testing design feasibility, thus supporting change avoidance by preventing costly modifications later. Prototypes are critical tools for eliciting and confirming system needs and improving user-interface designs. By providing early feedback, they support change tolerance in incremental development by allowing modifications without affecting the entire system .

COTS (Commercial Off-The-Shelf) components can significantly reduce software development cost and risks by leveraging pre-existing components, leading to faster delivery. However, drawbacks include compromised system requirements, as these components may not fully meet specific user needs. Additionally, there is a loss of control over system updates because new versions of COTS are not managed by the organization, introducing potential compatibility issues and increased dependency on third-party vendors .

Change avoidance involves anticipating modifications early in the development process, often through prototyping, to prevent significant rework later. It supports refining and confirming user requirements and design feasibilities, thereby reducing unexpected changes after system completion. Change tolerance, on the other hand, structures the development process to accommodate changes cost-effectively, typically seen in incremental development where parts of the system can be altered without impacting the whole. Both approaches help manage evolving business requirements and technology shifts efficiently .

Implementing incremental delivery poses challenges such as difficulty in planning common features due to unclear early shared system needs and incompatibility with traditional contracting approaches that prefer comprehensive upfront planning. For large systems, logistical issues arise when teams work in different locations, complicating integration. Critical systems demand full requirement analysis for safety and security, which are complex to achieve incrementally and can hinder fulfilling rigorous standards that gradually evolving systems may struggle to meet .

The principal supporting process activities in software development include documentation, software configuration management, and quality assurance. These activities ensure that all development phases are well-documented, that changes to software components are systematically controlled, and that software quality is consistently monitored. These activities are crucial for maintaining clarity, accountability, and quality control throughout the software development lifecycle, ultimately contributing to the project's success by reducing errors and facilitating easier collaboration and maintenance .

Incremental development focuses on creating and refining increments internally without immediate deployment, allowing continuous integration and improvement of system functionality. Meanwhile, incremental delivery involves the actual release of increments for use and evaluation by end-users, ensuring that critical features are deployed early. The key difference lies in deployment; incremental delivery releases increments for use, while incremental development keeps increments internal until the system is complete .