Jawaharlal Nehru Technological University Hyderabad B.Tech IV SOFTWARE PROJECT MANAGEMENT Previous Question Paper (October/November - 2020 - R15)

Conventional software project management, often referred to as the Waterfall model or plan-driven development, is a linear and sequential approach to software development. It assumes that all requirements can be defined upfront and that the project progresses through distinct phases: Requirements, Design, Implementation, Verification, and Maintenance. Each phase must be completed before the next one begins, with little room for iteration or change once a phase is finished.

The performance factors of conventional software project management include:

• Schedule Performance: Measured by the variance between the planned completion date and the actual completion date. Deviations indicate issues with planning, estimation, or execution.
• Cost Performance: Assessed by comparing the planned budget with the actual expenditure. Overruns suggest poor cost estimation, scope creep, or inefficient resource utilization.
• Quality Performance: Evaluated through defect density, customer satisfaction, and adherence to requirements. Low quality can stem from inadequate testing, poor design, or unclear requirements.
• Scope Performance: Determined by how well the final product meets the initially defined scope. Scope creep, where unapproved changes are added, negatively impacts schedule and cost.
• Resource Performance: Examined by the effective utilization of human resources, equipment, and other assets. Underutilization or overutilization can lead to inefficiencies and increased costs.
• Risk Management: The effectiveness of identifying, assessing, and mitigating potential risks that could impact project objectives. Poor risk management can lead to schedule delays, cost overruns, and quality issues.

Conventional software engineering principles, while foundational, have several pitfalls when applied rigidly, especially in today's dynamic environment:

• Inflexibility to Change: The linear, sequential nature makes it difficult and costly to accommodate changes in requirements once a phase is completed. This is a major drawback as requirements often evolve during development.
• Late Discovery of Defects: Testing and verification occur late in the lifecycle. This means defects introduced early in requirements or design might not be discovered until the implementation or verification phase, making them significantly more expensive and time-consuming to fix.
• Assumption of Stable Requirements: Conventional models assume that all requirements can be fully understood and documented at the beginning. This is often unrealistic for complex or innovative projects where user needs become clearer as the system is built and demonstrated.
• Limited Customer Involvement: Customer feedback is typically gathered at the beginning (requirements) and end (acceptance testing). This lack of continuous feedback can lead to a final product that doesn't fully meet user expectations or evolving business needs.
• Risk of Project Failure: Due to the late integration and testing, a project might proceed through many phases only to fail significantly during the final stages, leading to substantial wasted effort and resources.
• Documentation Overhead: Emphasis on comprehensive documentation at each stage can lead to significant overhead and delays, sometimes prioritizing documentation over working software.
• Misalignment with Agile Methodologies: In contrast to modern agile approaches that embrace change and iterative development, conventional methods struggle to adapt to the speed and flexibility required in many contemporary software projects.