BRIDGE: A Model for Modern Software Development Process to Cater the Present Software Crisis

As hardware components are becoming cheaper and powerful day by day, the expected services from modern software are increasing like any thing. Developing such software has become extremely challenging. Not only the complexity, but also the developing of such software within the time constraints and budget has become the real challenge. Quality concern and maintainability are added flavour to the challenge. On stream, the requirements of the clients are changing so frequently that it has become extremely tough to manage these changes. More often, the clients are unhappy with the end product. Large, complex software projects are notoriously late to market, often exhibit quality problems, and don’t always deliver on promised functionality. None of the existing models are helpful to cater the modern software crisis. Hence, a better modern software development process model to handle with the present software crisis is badly needed. This paper suggests a new software development process model, BRIDGE, to tackle present software crisis.

💡 Research Summary

The paper begins by outlining the “modern software crisis”: rapid hardware advances have raised expectations for software, leading to projects that are larger, more complex, and subject to tighter time‑budget constraints. A survey of current practice shows that a significant portion of organizations either do not use any lifecycle model or find existing models inadequate, citing reasons such as insufficient client involvement, poor requirement understanding, weak communication, and lack of configuration management. The authors enumerate 17 symptom categories of the crisis (size, complexity, cost, delivery delays, trust, quality, productivity, heterogeneity, reusability, modularity, maintainability, integration, scalability, portability, change management, and risk). They also list contemporary development trends—component‑based development, reuse, aspect‑oriented, service‑oriented, multi‑tier, object‑oriented, standards, and CASE tools—and argue that traditional SDLCs fail to support these trends.

In response, the authors propose a new process model named BRIDGE, structured into ten sequential phases, each emphasizing verification and specification. The phases are: (1) Requirement analysis, verification, and specification (producing an SRS); (2) Feasibility and risk analysis, verification, and specification (producing feasibility and risk reports); (3) Software architecture design, verification, and specification (SADD); (4) Detailed design, verification, and specification (SDD); (5) Pattern identification and component search, verification, and specification (CSD); (6) Standard coding, unit testing, verification, and specification (including addition of new components to a library); (7) System building through component integration, system testing, verification, and specification; (8) System validation against the original SRS, verification, and specification (validation report); (9) System deployment, implementation, training, and specification; and (10) System maintenance and specification. Throughout the model, each phase produces a documented artifact that serves both as a contract and as input for subsequent phases, creating a feedback loop for continuous process improvement.

The authors claim that BRIDGE directly addresses the identified crisis factors by integrating risk management, feasibility studies, component reuse, rigorous testing, and client‑centric validation. However, the paper provides limited empirical evidence, offers no quantitative comparison with existing models, and lacks concrete guidance on how to manage the potentially high overhead of repeated verification and documentation. Moreover, while client involvement is highlighted, the mechanisms for communication, role definition, and agile‑style iteration are not detailed. The model’s strength lies in its systematic, document‑driven approach that aligns with regulated or safety‑critical domains, but its practicality for fast‑moving, highly iterative environments remains uncertain. The paper concludes that BRIDGE can improve project success rates by bridging the gap between traditional heavyweight processes and modern development practices, yet further validation and tooling support are required for widespread adoption.