Lecture 09: Waterfall Derivatives

Summary

The script discusses various software development models, focusing on the Classical Life Cycle Model and its challenges, such as inflexibility and difficulty in handling requirements changes. It contrasts this with the Iterative Life Cycle Model, which allows for feedback and adjustments, gaining popularity in the 1970s and 80s. The script also covers the Waterfall Model's strengths, like structured planning and ease of understanding, but points out its limitations, including the inability to accommodate mid-project changes and late integration issues. Alternative approaches like the V Model and Prototyping Model are introduced as solutions to some of these limitations, emphasizing the importance of adapting to client needs and technical complexities in software development.

Takeaways

• 📈 The Classical Life Cycle Model was discussed, highlighting its difficulty in adapting to changes and lack of flexibility for managing project deliverables.
• 🔄 The Feedback Life Cycle Model was introduced as a solution to the issues of the Classical Model, offering iterative processes and pathways for addressing issues and refining responses.
• 🔧 The Iterative Life Cycle Model became popular in the 1970s and 80s, allowing for the identification and rectification of errors at any stage, with a path to revisit and redo subsequent stages.
• 💡 The strengths of the Waterfall Model were examined, including its structured approach that is easy for clients to understand and use for planning and development.
• 🛠 The Waterfall Model's limitations were also discussed, such as the need for clear and unchanging requirements at the outset, which is often impractical in real-world projects.
• 🚧 The V Model, an evolution of the Waterfall Model, was presented, emphasizing its focus on verification and validation throughout the lifecycle, making it suitable for safety-critical applications.
• 🔍 The V Model was described as having distinct phases for requirements analysis and test case development, ensuring thorough testing at each stage of the project.
• 🔄 The Iterative Waterfall Model was mentioned as a variation that combines elements of the Waterfall and Iterative Models, aiming to address some of the Waterfall Model's limitations.
• 🎯 The Prototyping Model was introduced as an alternative approach that can fill gaps left by the Waterfall Model, allowing for the creation of a working model to better understand and refine system requirements.
• 🤝 The benefits of the Prototyping Model include providing clients with a tangible experience of the software, enabling them to visualize and suggest changes before full development.
• 🔧 The Prototyping Model also aids developers in identifying and addressing technical issues early on, guiding the development process towards a more refined final product.

Q & A

What is the Classical Life Cycle Model discussed in the script?

The Classical Life Cycle Model, also known as the Waterfall Model, is a traditional software development process that involves a linear progression of stages, from requirements to design, implementation, testing, and maintenance.

Why is the application of the Classical Life Cycle Model considered challenging?

The Classical Life Cycle Model is challenging because it assumes a clear understanding of all requirements upfront and has no provision for changes in the project's course. It is rigid and does not accommodate feedback or iterative improvements easily.

What is the Feedback Life Cycle Model, and how does it address the issues of the Classical Life Cycle Model?

The Feedback Life Cycle Model incorporates mechanisms for feedback, allowing for the rectification of issues and the introduction of responsive pathways. It addresses the inflexibility of the Classical Life Cycle Model by allowing for iterative development and adjustments based on feedback.

What is the Iterative Life Cycle Model, and how was it popular in the 1970s and 1980s?

The Iterative Life Cycle Model is a software development approach that involves repeated cycles of development and testing. It was popular during the 1970s and 1980s because it provided a way to manage complex projects by breaking them down into smaller, more manageable parts and allowed for continuous improvement.

How does the Waterfall Model ensure that team members understand the project requirements?

The Waterfall Model ensures understanding by requiring that all phases are clearly defined and documented. Each team member must have a good grasp of the requirements before moving on to the next phase, which helps maintain consistency and clarity throughout the project.

What are some limitations of the Waterfall Model?

Limitations of the Waterfall Model include the need for a complete and accurate understanding of requirements at the outset, difficulty in accommodating changes once the project is underway, and the potential for integration issues to arise late in the development process.

How does the Waterfall Model handle changes in project requirements?

The Waterfall Model does not accommodate changes in requirements well. Once the requirements are documented and the project starts, any changes require significant rework, which can be costly and time-consuming.

What is the V Model, and how does it relate to the Waterfall Model?

The V Model is a variation of the Waterfall Model that emphasizes testing at each stage of the development process. It is designed to ensure that each phase of development is thoroughly tested and validated, adding a level of quality assurance to the traditional Waterfall approach.

Why is the V Model considered suitable for safety-critical applications?

The V Model is considered suitable for safety-critical applications because it includes rigorous testing and validation at every development phase. This ensures that all aspects of the software are thoroughly vetted, reducing the risk of critical failures.

What is the Prototyping Model, and how does it differ from the Waterfall Model?

The Prototyping Model is an approach where a preliminary version of the software, or prototype, is developed and tested early in the project. Unlike the Waterfall Model, it allows for early user feedback and iterative improvements, facilitating changes and adjustments based on user interaction.

How does the Prototyping Model benefit both developers and users?

The Prototyping Model benefits developers by allowing them to understand and address technical issues early in the development process. For users, it provides a tangible version of the software to interact with, enabling them to provide feedback and ensure that their requirements are met.

Outlines

00:00

🔄 Challenges and Evolution of Software Development Models

The script discusses the Classical Life Cycle Model and its challenges, particularly its inflexibility and inability to accommodate changes in requirements. It introduces the Feedback Life Cycle Model and the Iterative Life Cycle Model, which offer solutions to these issues by allowing for continuous feedback and iteration. The popularity of the Iterative Model during the 1970s and 1980s is noted, along with the shift towards more adaptive models due to the discovery of certain limitations. The script also touches on the Waterfall Model's strengths, such as its clarity and ease of understanding for clients and developers, and its suitability for stable requirements and well-understood projects.

05:04

🛠 Limitations and Considerations of the Waterfall Model

This paragraph delves into the limitations of the Waterfall Model, emphasizing the need for clear and complete requirements at the outset, which can be challenging to achieve in real-world projects. The model's lack of adaptability to change and the potential for integration issues during the later stages of development are highlighted. Furthermore, the script points out that the Waterfall Model can lead to client disconnection from the development process and may not be suitable for projects with evolving requirements or complex technical problems. It also mentions the Classical Waterfall Model's use in documentation for real projects, despite its recognized limitations.

10:09

📈 The Theorem's Approach and the V Model's Structure

The script uses the metaphor of a mathematician proving a theorem to illustrate the iterative process of software development, where multiple attempts and errors lead to a refined final product. It then introduces the V Model, an evolution of the Waterfall Model, which emphasizes verification and validation throughout the development lifecycle. The V Model is particularly suitable for safety-critical applications and ensures that testing is integrated at every stage, from requirements to deployment. The paragraph explains the V Model's structure, which resembles a V shape, with development on the left and testing on the right, and how it addresses some of the Waterfall Model's limitations.

15:17

🔍 The Role of Testing in the V Model and Iterative Development

This section discusses the continuous involvement of testers in the V Model, from the creation of system test cases during the requirements phase to the development of unit test cases during detailed design. It highlights the importance of testing at every development phase and how it ensures that the final product meets the specified requirements. The paragraph also touches on the iterative nature of the V Model, which allows for refinement of requirements and design through testing and feedback, thus improving the overall quality of the software.

20:21

🚧 The Prototyping Model: Bridging the Gap Between Concept and Reality

The script introduces the Prototyping Model as an alternative to the Waterfall Model, which allows for the creation of a preliminary version of the software to better understand and refine requirements. Prototyping is described as a tool for both clients to visualize the final product and developers to identify technical issues early in the development process. The paragraph outlines the benefits of prototyping, such as reduced development time and cost, better understanding of user needs, and the ability to make informed adjustments before full-scale development.

25:24

🤝 The Benefits of Prototyping for Stakeholders and Developers

This paragraph highlights the advantages of the Prototyping Model for both clients and developers. Clients benefit from a clearer understanding of the software's functionality and the ability to provide feedback on the user interface and interactive elements. Developers, on the other hand, can test hardware responses and technical issues, ensuring that the prototype serves as a practical tool for identifying and resolving potential problems before they become more significant issues in the final product.

🔚 Conclusion: The Significance of the Prototyping Model in Software Development

The final paragraph concludes the discussion by emphasizing the importance of the Prototyping Model in modern software development. It summarizes the benefits of prototyping for stakeholders, including reduced documentation needs, improved development quality, and the ability to make informed decisions based on user feedback and technical evaluations. The script ends by acknowledging the role of prototypes in facilitating better communication and understanding between clients and developers, leading to more successful software projects.

Keywords

💡Life Cycle Model

The Life Cycle Model refers to a series of stages in the development of a system, often used in software engineering to describe the phases through which a software product progresses. In the script, it is mentioned in the context of various models like the Classical Life Cycle Model and the Iterative Life Cycle Model, highlighting the evolution of software development methodologies.

💡Classical Life Cycle Model

The Classical Life Cycle Model, also known as the Waterfall Model, is a linear and sequential approach to software development where progress is seen as flowing steadily downwards (like a waterfall) through conception, initiation, analysis, design, construction, testing, deployment, and maintenance. The script discusses its limitations and the challenges it presents, such as the difficulty in making changes once a phase is completed.

💡Feedback Life Cycle Model

The Feedback Life Cycle Model is an approach that incorporates user feedback into the software development process. It is designed to address issues that arise during development and to refine the product based on user interaction. The script mentions this model as a solution to the problems posed by the Classical Life Cycle Model, where it allows for iterative improvements.

💡Iterative Life Cycle Model

The Iterative Life Cycle Model is a software development approach that allows for repeated cycles of development and testing, enabling continuous refinement of the product. The script points out its popularity during the 1970s and 1980s, and how it provides a pathway for addressing errors and revisiting project stages for improvement.

💡Waterfall Model

The Waterfall Model is a software development process that involves a linear progression of stages, from requirement gathering to maintenance. It is characterized by a lack of iteration and a strict sequential order. The script discusses its strengths, such as its simplicity and ease of understanding, as well as its limitations, including the inflexibility to change requirements once development has begun.

💡V Model

The V Model is a software development model that places a strong emphasis on testing and validation at every stage of the development process. It is shaped like the letter 'V', with the left side representing the development phases and the right side the testing phases. The script describes the V Model as an evolution of the Waterfall Model, offering a more rigorous approach to software development.

💡Prototyping Model

The Prototyping Model is an approach where a preliminary model of the software is developed and tested before the full-scale production begins. It allows for early user interaction and feedback, which can guide the development process. The script mentions the benefits of this model, such as allowing developers to understand technical issues and enabling users to refine their requirements.

💡Requirements

In the context of software development, 'requirements' refer to the specific needs that the software must meet. The script discusses the importance of clearly understanding and documenting requirements at the beginning of a project, as they form the basis for the development process and are critical for the success of the software.

💡Integration Testing

Integration Testing is the phase in software development where individual software modules are combined and tested as a group to ensure that they work together correctly. The script mentions this as a critical part of the V Model and the Iterative Waterfall Model, emphasizing the need for thorough testing as components are integrated.

💡Unit Testing

Unit Testing is the process of testing individual components or units of a software to determine if they function as expected. The script refers to Unit Testing as part of the V Model, where it is conducted to ensure that each unit of the software performs its intended function correctly before integration.

💡System Testing

System Testing involves testing the complete, integrated software system to evaluate the system's compliance with its specified requirements. The script discusses the importance of System Testing in the V Model, where it is conducted to ensure that the software meets all the necessary requirements and functions as intended in a real-world environment.

Highlights

Classical Life Cycle Model is difficult to apply with its rigid and inflexible nature.

The Feedback Life Cycle Model addresses issues and suggests responsive solutions, unlike the Classical Model.

Iterative Life Cycle Model became popular in the 1970s and 80s, allowing for feedback and corrections at any stage.

The Waterfall Model is easy for clients to understand and use for planning and tracking the project.

The Waterfall Model requires all requirements to be clear and unchangeable before project commencement.

V Model is an extension of the Waterfall Model, emphasizing verification and validation throughout the lifecycle.

V Model is suitable for safety-critical applications where reliability and trust are paramount.

Prototyping Model fills the gap of the Waterfall Model by allowing for early customer feedback and iterative improvements.

The need for the Prototyping Model arises when developers need to understand technical issues before full-scale development.

Prototyping helps in reducing documentation needs and focusing on the development quality.

Customers can experience the software and provide feedback on the interface and interactive elements through the Prototyping Model.

Developers can test hardware responses and technical issues using the Prototype Model.

The Classical Waterfall Model is not suitable for real projects where requirements are likely to change.

V Model ensures that each delivery is tested, enhancing the quality and reliability of the software.

V Model has limitations similar to the Iterative Waterfall Model, where requirements must be frozen before planning begins.

The V Model is particularly useful for embedded control applications that demand high safety and reliability.

The transcript concludes by summarizing the importance of choosing the right model based on project needs and requirements.

Transcripts

ಈ ಉಪನ್ಯಾಸಕ್ಕೆ ಸ್ವಾಗತ.

ಕಳೆದ ಕೆಲವು ಉಪನ್ಯಾಸಗಳಲ್ಲಿ ನಾವು ಲೈಫ್ ಸೈಕಲ್

ಮಾಡೆಲ್ (Life Cycle Model) ನೋಡಿದ್ದೇವೆ.

ನಾವು ಎಲ್ಲಾ ಇತರ ಮಾಡೆಲುಗಳಿಗೆ ಆಧಾರವಾಗಿರುವ ಕ್ಲಾಸಿಕಲ್

ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್(Classical Life Cycle Model) ಸಹ ನೋಡಿದ್ದೇವೆ

ಆದರೆ ಕ್ಲಾಸಿಕಲ್ ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್(Classical

Life Cycle Model) ಟೆಕ್ನಿಕ್(technique) ಬಳಸುವುದು ಕಷ್ಟ.

ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ಅದರ ಆದರ್ಶವಾದಿ ಮತ್ತು

ಕೆಲಸದ ಉತ್ಪನ್ನಗಳಿಗೆ ತಿದ್ದುಪಡಿಗಳನ್ನು

ಸರಿಹೊಂದಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.

ಇದು ಕೇವಲ ಪ್ಯೂರ್ ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್(Pure

Life Cycle Model)ಯಾಗಿದೆ.

ಆದರೆ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ 1000 ತಪ್ಪುಗಳು

ಸಂಭವಿಸುತ್ತವೆ ಮತ್ತು ಫೀಡ್ಬ್ಯಾಕ್ ಲೈಫ್

ಸೈಕಲ್ ಮಾಡೆಲ್(feedback Life Cycle Model) ಈ ಸಮಸ್ಯೆಯನ್ನು

ನಿವಾರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಮಾರ್ಗಗಳನ್ನು

ಒದಗಿಸುತ್ತದೆ.

ಇಟೆರಟಿವೆ ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್(Iterative Life Cycle Model)

ಪ್ರತಿಕ್ರಿಯೆ ಮಾರ್ಗಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು

ಯಾವುದೇ ಹಂತದಲ್ಲಿ ತಪ್ಪು ಪತ್ತೆಯಾದರೆ

ಆ ತಪ್ಪುಗಳನ್ನು ಸರಿಪಡಿಸಲು ಮತ್ತು ನಂತರದ ಹಂತಗಳನ್ನು

ಪುನಃ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವಿದೆ.

ಇಟೆರಟಿವೆ ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್(Iterative Life Cycle Model)

1970 ಮತ್ತು 80 ರ ದಶಕಗಳಲ್ಲಿ ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗಿತ್ತು.

ಇದನ್ನು ಪ್ರತಿಯೊಂದು ಅಭಿವೃದ್ಧಿ ಕಾರ್ಯಗಳಲ್ಲಿ

ಬಳಸಲಾಗುತ್ತಿತ್ತು ಆದರೆ ಹೊಸ ಲೈಫ್ ಸೈಕಲ್

ಮಾಡೆಲ್ ಗಣನೆಗೆ ಬಂದ ಕೆಲವು ತೊಂದರೆಗಳನ್ನು

ಹೊಂದಿದ್ದವು.

ನಿಧಾನವಾಗಿ ಯೋಜನೆಗಳ ಗುಣಲಕ್ಷಣಗಳು ಬದಲಾದವು

ಮತ್ತು ಯೋಜನೆಗಳು ಹುಡುಕಲ್ಪಟ್ಟವು.

ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್ ಬಲವಾದ ಅಂಶಗಳನ್ನು

ನೋಡೋಣ ಮತ್ತು ಅದು ಏಕೆ ಜನಪ್ರಿಯವಾಗಿದೆ?

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(Waterfall Model) ಸಾಮರ್ಥ್ಯವು ಗ್ರಾಹಕರು

ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಬಳಸಲು ಪರಿಕಲ್ಪನಾ

ಸುಲಭತೆಯನ್ನು ಒಳಗೊಂಡಿದೆ.

ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ

ಎಂಬುದರ ಪರಿಕಲ್ಪನಾ ತಿಳುವಳಿಕೆಯೊಂದಿಗೆ

ಇದು ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.

ಅಭಿವೃದ್ಧಿ ಸಿಬ್ಬಂದಿಗಳು ಅನನುಭವಿಗಳಾಗಿದ್ದರೂ

ಸಹ, ಅವರು ಲೈಫ್ ಸೈಕಲ್ ಮಾಡೆಲ್ ಸುಲಭವಾಗಿ

ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು

ಪ್ರಾರಂಭಿಸಬಹುದು.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್, ಮೈಲಿಗಲ್ಲುಗಳನ್ನು

ತಂಡದ ಪ್ರತಿಯೊಬ್ಬ ಸದಸ್ಯರೂ ಚೆನ್ನಾಗಿ

ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.

ಮೈಲಿಗಲ್ಲುಗಳು ಮೂಲಭೂತವಾಗಿ ಹಂತದ ಪ್ರವೇಶ ಮತ್ತು

ನಿರ್ಗಮನ ಮತ್ತು ಇದು ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ

ಅಗತ್ಯ ಸ್ಥಿರತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಅವಶ್ಯಕತೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ದಾಖಲಿಸಿದ

ನಂತರ ಅಗತ್ಯತೆಗಳಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಇರುವುದಿಲ್ಲ.

ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಡ್ಡಿಯಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅವರು ಸಾಫ್ಟ್‌ವೇರ್

ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ಆದರೆ ಬದಲಾವಣೆಯಾದರೆ, ಅವರು ತಮ್ಮ ಸಂಪೂರ್ಣ

ಕೆಲಸವನ್ನು ಮತ್ತೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ,

ಸಂಪೂರ್ಣ ಯೋಜನೆ ಮತ್ತು ಒಟ್ಟಾರೆ ವಿನ್ಯಾಸ

ಮತ್ತು ಇತ್ಯಾದಿ.

ಹೀಗಾಗಿ, ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್ ಅಗತ್ಯ ಸ್ಥಿರತೆಯನ್ನು

ಒದಗಿಸುತ್ತದೆ.

ಅಗತ್ಯ ದಾಖಲೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಿದ ನಂತರ

ಅದನ್ನು ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ.

ಅಲ್ಲದೆ, ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಎಲ್ಲಾ

ಹಂತಗಳನ್ನು ಯೋಜಿಸಬಹುದು ಮತ್ತು ಯೋಜನೆಯು ಯೋಜನೆಯ

ಪ್ರಕಾರ ಮುಂದುವರಿಯುತ್ತಿದೆಯೇ ಎಂದು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು

ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ಮತ್ತೆ ಟ್ರ್ಯಾಕ್

ಮಾಡಲು ಸರಿಪಡಿಸುವ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್ ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯಗಳನ್ನು

ಹೊಂದಿದೆ ಆದರೆ ಈ ಮಾದರಿಯ ಹಲವಾರು ನ್ಯೂನತೆಗಳಿವೆ.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್ ಲಿಮಿಟೇಷನ್ಸ್(Waterfall

Model Limitations) ನೋಡುವುದು.

ಪ್ರಾಯಶಃ ಅತ್ಯಂತ ಸಮಸ್ಯಾತ್ಮಕ ಕೊರತೆಯೆಂದರೆ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಮುಂಚಿತವಾಗಿ ತಿಳಿದಿರಬೇಕು.

ಪ್ರಾಜೆಕ್ಟ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಗ್ರಾಹಕರು ಎಲ್ಲಾ

ಅವಶ್ಯಕತೆಗಳನ್ನು ನೀಡಬೇಕು ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್

ಇಲ್ಲದಿರುವ ಕಾರಣ ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯಸಾಧ್ಯವಲ್ಲ

ಮತ್ತು ಕ್ಲೈಂಟ್ ಏನು ಬೇಕು ಎಂದು ಊಹಿಸಬೇಕಾಗುತ್ತದೆ.

ಅವಶ್ಯಕತೆಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು

ಮತ್ತು ಅಸ್ಪಷ್ಟ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮತ್ತು ತಪ್ಪು ಅವಶ್ಯಕತೆಗಳನ್ನು

ನೀಡುವುದು ತುಂಬಾ ಸುಲಭ.

ರಿಯಲ್ ಪ್ರಾಜೆಕ್ಟ್ಸ್(Real Projects) ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ

ಅಗತ್ಯ ಬದಲಾವಣೆಗಳಿವೆ.

ಯೋಜನೆಯ ಪ್ರಾರಂಭದಲ್ಲಿ ಗ್ರಾಹಕರು ನಿಖರವಾದ

ಅವಶ್ಯಕತೆಗಳನ್ನು ದೃಶ್ಯೀಕರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

ಮತ್ತು ಯೋಜನೆಯು ಮುಂಚಿತವಾಗಿ ಗ್ರಾಹಕರು ಅಗತ್ಯಗಳಿಗೆ

ಅನುಗುಣವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(waterfall Model) ಎರಡನೇ ಸಮಸ್ಯೆಯೆಂದರೆ

ಅದು ಪ್ರಗತಿಯ ತಪ್ಪು ಅನಿಸಿಕೆ ನೀಡುತ್ತದೆ.

ಮೂಲಭೂತವಾಗಿ, ಸಮಸ್ಯೆಯು ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್ಗಳೊಂದಿಗೆ(Integration

Testing) ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಇಂಟೆರ್ಗ್ರಷನ್(Integration)ಪ್ರಾರಂಭವಾದ

ನಂತರ ಸಮಸ್ಯೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(waterfall model) ಇದು ಪ್ರಮುಖ ಸಮಸ್ಯೆಯ

ಪ್ರದೇಶಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಮತ್ತು ವೇಳಾಪಟ್ಟಿ

ವಿಳಂಬಗಳು ಇಂಟಿಗ್ರೇಷನ್(Integration) ಪ್ರಾರಂಭವಾಗುತ್ತದೆ

ಮತ್ತು ಯೋಜನೆಯು ಮತ್ತಷ್ಟು ವಿಳಂಬವಾಗುತ್ತದೆ.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(waterfall model) ಮತ್ತೊಂದು ಪ್ರಮುಖ

ಸಮಸ್ಯೆಯೆಂದರೆ ಅದು ಗ್ರಾಹಕರ ಅಗತ್ಯವನ್ನು

ಅಪರೂಪವಾಗಿ ಪೂರೈಸುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕರನ್ನು

ಅಭಿವೃದ್ಧಿ ಕಾರ್ಯದಿಂದ ಹೊರಗಿಡಲಾಗಿದೆ.

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(waterfall model) ಸೂಕ್ತವಾದ ಯೋಜನೆಗಳು.

ಅವಶ್ಯಕತೆಗಳು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದರೆ ಮತ್ತು

ಸ್ಥಿರವಾಗಿದ್ದರೆ, ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ

ಏನು ಬೇಕು ಮತ್ತು ಮುಂಗಡವಾಗಿ ಫ್ರೀಜ್ ಮಾಡಬಹುದು

ಎಂದು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ತಂತ್ರಜ್ಞಾನವನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲಾಗಿದೆ

ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತಂಡವು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾದ

ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ಪರಿಚಿತವಾಗಿದೆ.

ನೀವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ನೋಡಿದರೆ ಇವು ಮೂಲಭೂತವಾಗಿ

ಕೆಲವು ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ

ಮತ್ತು ನಾವು ಸಣ್ಣ ಬದಲಾವಣೆಯ ಆವೃತ್ತಿಯನ್ನು

ಹೊಂದಲು ಬಯಸುತ್ತೇವೆ.

ಆದರೆ ನಾವು ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಸಾಫ್ಟ್‌ವೇರ್

ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬಯಸಿದರೆ ವಾಟರ್ಫಾಲ್

ಮಾಡೆಲ್(waterfall model) ಸೂಕ್ತವಲ್ಲ.

ಕ್ಲಾಸಿಕಲ್ ವಾಟರ್ಫಾಲ್ ಮಾದರಿಯ(Classical Waterfall Model)

ಬಗ್ಗೆ ಏನು?

ಇದು ನಿಜವಾದ ಯೋಜನೆಗಳಿಗೆ ಉಪಯುಕ್ತವಲ್ಲವಾದ್ದರಿಂದ

ಯಾವುದೇ ಉಪಯೋಗವಿದೆಯೇ.

ಪ್ರಾಜೆಕ್ಟ್‌ನ ದಾಖಲೀಕರಣವನ್ನು ಕ್ಲಾಸಿಕಲ್ ವಾಟರ್ಫಾಲ್

ಮಾದರಿಯ(Classical Waterfall Model) ಮಾಡಲಾಗುತ್ತದೆ.

ಇಟೆರಟಿವೆ ಮಾಡೆಲ್ ಅಥವಾ ಇತರ ಯಾವುದೇ

ಮಾಡೆಲನ್ನು ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿ ಸಂಭವಿಸಿರಬಹುದು

ಆದರೆ ಕ್ಲಾಸಿಕಲ್ ವಾಟರ್ಫಾಲ್ ಮಾದರಿಯ(Classical Waterfall Model)

ಬಳಸಿದಂತೆ ದಾಖಲೆಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ.

ಕಾರಣವನ್ನು ನೋಡೋಣ.

ಗಣಿತಜ್ಞನು ಥಿಯರಮ್(Theorem) ಸಾಬೀತುಪಡಿಸುವ ವಿಧಾನವನ್ನು

ಯೋಚಿಸುವುದು.

ಅವನು ಸಾಬೀತುಪಡಿಸಲು ಬಯಸಿದಂತೆ ಸಮಸ್ಯೆಯನ್ನು

ನೀಡಿದರೆ, ಅವನು ಅನೇಕ ದಿಕ್ಕುಗಳಲ್ಲಿ ಕೆಲಸ

ಮಾಡುತ್ತಾನೆ, ಅವನು ಹಿಮ್ಮೆಟ್ಟುತ್ತಾನೆ,

ಅವನು ಅದನ್ನು ದಾಟಲು ಮತ್ತು ಹೊರಗೆ ಮತ್ತು

ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಇತ್ಯಾದಿ.

ಅಂತಿಮವಾಗಿ, ಅವರು ಥಿಯರಮ್(Theorem) ಬರೆಯುವಾಗ

ಅದು ಒಂದೇ ಆಲೋಚನೆಯ ಸರಣಿಯಾಗಿ ಕಂಡುಬರುತ್ತದೆ,

ಮಾಡಿದ ಎಲ್ಲಾ ತಪ್ಪುಗಳು ಮತ್ತು ಪ್ರಯತ್ನಿಸಲಾದ

ವಿಭಿನ್ನ ಪರ್ಯಾಯಗಳನ್ನು ತೋರಿಸಲಾಗುವುದಿಲ್ಲ

ಏಕೆಂದರೆ ಅದು ಯಾರಿಗಾದರೂ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ

ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ತಪ್ಪುಗಳನ್ನು ಸೇರಿಸಿದರೆ ಅದು ಯಾರಿಗಾದರೂ ಗೊಂದಲವನ್ನುಂಟುಮಾಡುತ್ತದೆ

ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿನ

ದಾಖಲಾತಿಗಳನ್ನು ಕ್ಲಾಸಿಕಲ್ ವಾಟರ್ಫಾಲ್ ಮಾದರಿಯ(Classical

Waterfall Model) ಬಳಸಿದಂತೆ ಬರೆಯಲು ನಿಖರವಾಗಿ

ಕಾರಣವಾಗಿದೆ ಏಕೆಂದರೆ ಆ ರೀತಿಯಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು

ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುವ ಯಾರಾದರೂ

ಸುಲಭವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ದಾಖಲೆಗಳು.

V ಮಾದರಿ ಎಂದು ಹೆಸರಿಸಲಾದ ವಾಟರ್ಫಾಲ್ ಮಾದರಿಯ(Waterfall

Model) ವ್ಯುತ್ಪನ್ನವನ್ನು ನೋಡಲಾಗುತ್ತಿದೆ.

ಇದು ವಾಟರ್ಫಾಲ್ ಮಾದರಿಯ(Waterfall Model) ಒಂದು ರೂಪಾಂತರವಾಗಿದೆ

ಮತ್ತು ಇದು ಪರಿಶೀಲನೆ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು

ಒತ್ತಿಹೇಳುತ್ತದೆ.

ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಸುರಕ್ಷತೆಯು ಪ್ರಮುಖವಾಗಿರುವ

ಸುರಕ್ಷತಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಬಳಸಲಾಗುವ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ

ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ.

ಪರಿಶೀಲನೆ ಮತ್ತು ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಚಟುವಟಿಕೆಗಳು ಸಂಪೂರ್ಣ

ಲಿಫೆಸೈಕಲ್(Lifecycle)ಹರಡುತ್ತವೆ.

ನೀವು ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ವಿನ್ಯಾಸದೊಂದಿಗೆ

ಪ್ರಾರಂಭಿಸುತ್ತಿರುವಂತೆ, ಎಲ್ಲಾ ಹಂತಗಳು ಪರಿಶೀಲನೆ

ಮತ್ತು ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯ ಚಟುವಟಿಕೆಗಳಾಗಿವೆ

ಮತ್ತು ಯೋಜನೆಯ ವಿವಿಧ ಅಂಶಗಳು ಪ್ರಗತಿಯಲ್ಲಿರುವಂತೆ

ಟೆಸ್ಟಿಂಗ್ ಆಕ್ಟಿವಿಟೀಸ್(Testing Activities) ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ

ಸಮಾನಾಂತರವಾಗಿ ಯೋಜಿಸಲಾಗಿದೆ, ಹೆಚ್ಚು ನಿಖರವಾದ ಟೆಸ್ಟಿಂಗ್(Testing)

ಕೇಸ್ ವಿನ್ಯಾಸಗಳನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.

ಮಾಡೆಲ್(model) ದೃಶ್ಯ ಪ್ರಾತಿನಿಧ್ಯವು V

ಆಕಾರದಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಈ

ಮಾಡೆಲನ್ನು ವಿ ಮಾಡೆಲ್(V Model) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

ಎಡಭಾಗದಲ್ಲಿ ಇದು ಅಭಿವೃದ್ಧಿಯ ಹಂತವಾಗಿದೆ ಮತ್ತು

ಬಲಭಾಗದಲ್ಲಿ ಇದು ಟೆಸ್ಟ್(Test) ಮತ್ತು ನಿರ್ವಹಣೆಯಾಗಿದೆ.

ಸಿಸ್ಟಮ್ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು ಅವಶ್ಯಕತೆಗಳ

ನಿರ್ದಿಷ್ಟತೆಯ ಸಮಯದಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ

ಏಕೆಂದರೆ ಅಂತಿಮ ಸಾಫ್ಟ್‌ವೇರ್ ಅಂತಿಮ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ

ಸಂಬಂಧಿಸಿದಂತೆ ಅವಶ್ಯಕತೆಗಳನ್ನು ಅನುಸರಿಸಬೇಕಾಗುತ್ತದೆ.

ವಿ ಮಾಡೆಲ್(V Model) ಅವಶ್ಯಕತೆಯ ನಿರ್ದಿಷ್ಟತೆಯ ಹಂತದಲ್ಲಿಯೇ,

ಸಿಸ್ಟಮ್ ಟೆಸ್ಟ್ ಕೇಸ್(system test case) ಗಳನ್ನೂ ಬರೆಯಬೇಕು

ಎಂದು ಪ್ರತಿಪಾದಿಸಲಾಗಿದೆ.

ಅನುಕೂಲಗಳೆಂದರೆ ಅವಶ್ಯಕತೆಗಳ ಟೆಸ್ಟನ್ನು(test) ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು.

ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ ಇತೆರೆತಿವೆ ವಾಟರ್ಫಾಲ್

ಮಾಡೆಲ್(Iterative Waterfall Model), ಅಭಿವೃದ್ಧಿಯ ಹಂತಗಳಲ್ಲಿ

ಟೆಸ್ಟರ್(tester)ಏನು ಮಾಡುತ್ತಾರೆ, ಟೆಸ್ಟ್(test) ಹಂತದಲ್ಲಿ

ಮಾತ್ರ ಸೇರುತ್ತಾರೆಯೇ?

ವಿ ಮಾಡೆಲ್(V Model) ಪರಿಹಾರವನ್ನು ಒದಗಿಸುವಂತೆ, ಟೆಸ್ಟರ್(tester)

ಸಿಸ್ಟಮ್ ಟೆಸ್ಟ್ ಕೇಸುಗಳನ್ನು(system test cases) ಬರೆಯುವಲ್ಲಿ

ನಿರತರಾಗಿದ್ದಾರೆ.

ಉನ್ನತ ಮಟ್ಟದ ವಿನ್ಯಾಸದ ಸಮಯದಲ್ಲಿ, ಅವರು ಇಂಟಿಗ್ರೇಷನ್

ಟೆಸ್ಟಿಂಗ್(Integration Testing) ಟೆಸ್ಟ್ ಕೇಸುಗಳನ್ನು

ಬರೆಯುವಲ್ಲಿ ನಿರತರಾಗಿದ್ದಾರೆ ಮತ್ತು ವಿವರವಾದ ವಿನ್ಯಾಸದ

ಸಮಯದಲ್ಲಿ ಅವರು ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಕಾಸೆಸ್(unit

Test Cases) ಅಭಿವೃದ್ಧಿಪಡಿಸುವಲ್ಲಿ ನಿರತರಾಗಿದ್ದಾರೆ.

ಹೀಗಾಗಿ, ಪ್ರತಿ ಅಭಿವೃದ್ಧಿ ಹಂತದಲ್ಲಿ, ಟೆಸ್ಟನ್ನು(test)

ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಟೆಸ್ಟ್ ಕೇಸ್(test

case) ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತದೆ.

ಏಕೆಂದರೆ, ಇಂಪ್ಲೆಮೆಂಟರ್ಸ್(implementers) ಏನನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ

ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಸುಲಭವಾಗುತ್ತದೆ, ಅವರು

ಮಾಡುವ ಕೆಲಸದ ಬಗ್ಗೆ ಅವರು ಜಾಗೃತರಾಗುತ್ತಾರೆ

ಮತ್ತು ಅಂತಿಮವಾಗಿ ಆ ಪರೀಕ್ಷಾ ಪ್ರಕರಣಗಳನ್ನು

ತೃಪ್ತಿಪಡಿಸಬೇಕಾಗುತ್ತದೆ.

ನಾವು V ಮಾಡೆಲ್(V Model) ವಿವಿಧ ಹಂತಗಳನ್ನು

ನೋಡಿದರೆ, ಅವಶ್ಯಕತೆಗಳ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು

ನಿರ್ದಿಷ್ಟತೆಯ ಸಮಯದಲ್ಲಿ ಕೆಲವು ಟೆಸ್ಟ್ ಕೇಸ್(Test

Case) ಮಾಡಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.

ಉನ್ನತ ಮಟ್ಟದ ವಿನ್ಯಾಸದ ಸಮಯದಲ್ಲಿ ಇಂಟಿಗ್ರೇಷನ್

ಟೆಸ್ಟಿಂಗ್(Integration Testing) ಕೇಸ್ ವಿನ್ಯಾಸ ಮತ್ತು

ಇಂಟಿಗ್ರೇಷನ್ ಪ್ಲಾನಿಂಗ್(Integration Planning) ಮಾಡಲಾಗುತ್ತದೆ.

ವಿವರ ವಿನ್ಯಾಸದ ಸಮಯದಲ್ಲಿ ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಡಿಸೈನ್(Unit

Test Design) ಮಾಡಲಾಗುತ್ತದೆ.

V ಮಾಡೆಲ್(V Model) ಬಲವು ಸ್ಪಷ್ಟವಾಗಿದೆ ಏಕೆಂದರೆ

ಇದು ಪರಿಶೀಲನೆ ಮತ್ತು ಮೌಲ್ಯೀಕರಣವನ್ನು

ಒತ್ತಿಹೇಳುತ್ತದೆ.

ಪ್ರತಿ ವಿತರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಬಹುದಾದಂತೆ

ಮಾಡಲಾಗಿದೆ.

ಮಾದರಿಯು ಬಳಸಲು ಸುಲಭವಾಗಿರುವುದರಿಂದ ಮತ್ತು ವಾಟರ್ಫಾಲ್

ಮಾದರಿಯಂತೆಯೇ ಪರಿಶೀಲನೆ ಮತ್ತು ಮೌಲ್ಯೀಕರಣವಾದ

V ಮತ್ತು V ಚಟುವಟಿಕೆಗಳು ಲೈಫ್ಸೈಕ್ಲ್ (Lifecycle)

ಹರಡುತ್ತವೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ.

ವಿ ಮಾದರಿಯ(V Model) ದೌರ್ಬಲ್ಯಗಳು?

ಇದು ಪುನರಾವರ್ತಿತ ಜಲಪಾತದ ಮಾದರಿಯಂತೆಯೇ(Iterative

Waterfall Model) ಅದೇ ದೌರ್ಬಲ್ಯದಿಂದ ಬಳಲುತ್ತಿದೆ, ಅಂದರೆ

ಯೋಜನೆಯು(planning) ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಅವಶ್ಯಕತೆಗಳನ್ನು

ಫ್ರೀಜ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಜಲಪಾತದ

ಮಾದರಿಯಂತೆ ಅವಶ್ಯಕತೆಗಳನ್ನು(waterfall Model Requirements) ಬದಲಾಯಿಸುವ

ಯಾವುದೇ ಅವಕಾಶವಿಲ್ಲ.

ಜಲಪಾತದ ಮಾದರಿ(waterfall Model) ಮತ್ತು ವಿ ಮಾದರಿಯ(V

Model) ಮತ್ತೊಂದು ಸಮಸ್ಯೆಯೆಂದರೆ ಅದು ಹಂತಗಳ ಅತಿಕ್ರಮಿಸುವಿಕೆಯನ್ನು

ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

ಎಂಬೆಡೆಡ್ ಕಂಟ್ರೋಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಂತಹ

ಸುರಕ್ಷತಾ ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಹೆಚ್ಚಿನ ಒತ್ತು ನೀಡಿದಾಗ

ವಿ ಮಾದರಿಯ(V Model) ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕು.

ಅವಶ್ಯಕತೆಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ತಿಳಿದಿರಬೇಕು

ಮತ್ತು ಇದು ಯೋಜನೆಯ ಗುಣಲಕ್ಷಣಗಳಾಗಿದ್ದರೆ

V ಉತ್ತಮ ಮಾದರಿಯಾಗಿದೆ.

ಈಗ ನಾವು ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(waterfall Model)ಮತ್ತೊಂದು

ರೂಪಾಂತರವನ್ನು ನೋಡೋಣ, ಇದನ್ನು ಮೂಲಮಾದರಿ

ಮಾದರಿ(prototyping model) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

ಮೂಲಮಾದರಿಯ ಮಾದರಿಯು(Prototyping Model) ಜಲಪಾತದ ಮಾದರಿಗೆ(Waterfall

Model) ಹೋಲುತ್ತದೆ ಮತ್ತು ಸಣ್ಣ ವ್ಯತ್ಯಾಸವೆಂದರೆ

ಮೂಲಮಾದರಿಯ(Prototype) ನಿರ್ಮಾಣ ಮತ್ತು ಅವಶ್ಯಕತೆಗಳ

ಹಂತವು ಇಲ್ಲ, ಇದು ವಾಸ್ತವವಾಗಿ ಮೂಲಮಾದರಿಯ (ಪ್ರೋಟೋಟೈಪ್)ನಿರ್ಮಾಣವಾಗಿದೆ.

ಇದು ಜಲಪಾತದ ಮಾದರಿಯ ಸಣ್ಣ ಬದಲಾವಣೆಯಾಗಿದೆ.

ಅಭಿವೃದ್ಧಿ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಮೂಲಮಾದರಿಯನ್ನು(Prototype)

ನಿರ್ಮಿಸುವ ಅಗತ್ಯವಿದೆ.

ಮೂಲಮಾದರಿಯು(Prototyping) ವ್ಯವಸ್ಥೆಯ ಆಟಿಕೆ(toy)

ಅನುಷ್ಠಾನವಾಗಿದೆ(implementation).

ನಾವು ಕಾರ್ಯವನ್ನುfunction) ಕಾರ್ಯಗತಗೊಳಿಸಲು(implementation)

ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ,

ಕಾರ್ಯದ(implement) ಆಟಿಕೆ(toy ) ಅಳವಡಿಸಲು ನಾವು ಕಾರ್ಯದ(function)

ಒಳಗೆ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿರಬಹುದು, ಅದು

ಕಾರ್ಯಕ್ಕೆ(function) ಅಗತ್ಯವಿರುವ ಮೌಲ್ಯಗಳನ್ನು ಹುಡುಕುತ್ತದೆ.

ನಿರ್ಬಂಧಿತ ಇನ್‌ಪುಟ್ ಮೌಲ್ಯಗಳಿಗಾಗಿ ನಾವು

ಅದನ್ನು ಟೇಬಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದಂತೆಯೇ

ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಸೀಮಿತ

ಕ್ರಿಯಾತ್ಮಕ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು

ಅನೇಕ ಇನ್‌ಪುಟ್‌ಗಳಿಗೆ ಕೆಲಸ ಮಾಡದಿರಬಹುದು.

ಕಾರ್ಯಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳೀಕರಿಸಲಾಗಿದೆ.

ನಾವು ಪ್ರೋಟೋಟೈಪ್(prototype) ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾಗಿದೆ

ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ಗ್ರಾಹಕರಿಗೆ ತೋರಿಸಬಹುದು.

ಗ್ರಾಹಕರು ಸಂಪೂರ್ಣ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು

ದೃಶ್ಯೀಕರಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ ಮತ್ತು

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(waterfall Model)ಅನೇಕ ಯೋಜನೆಗಳಲ್ಲಿ

ವಿಫಲವಾಗಲು ಇದು ಒಂದು ಕಾರಣವಾಗಿದೆ.

ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು

ಮೂಲಮಾದರಿಯ ಮಾದರಿಯಲ್ಲಿ(prototype), ನಾವು ಸಾಫ್ಟ್‌ವೇರ್‌ನ

ಮೂಲಮಾದರಿಯನ್ನು(Prototype) ರಚಿಸುತ್ತಿದ್ದೇವೆ.

ಸಾಫ್ಟ್‌ವೇರ್ ಅಂತಿಮವಾಗಿ ಹೇಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ

ಎಂಬುದರ ಕುರಿತು ಗ್ರಾಹಕರು ಉತ್ತಮ ಭಾವನೆಯನ್ನು

ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಅವರು ಬದಲಾವಣೆಗಳನ್ನು

ಸೂಚಿಸಬಹುದು, ಅದನ್ನು ಮೂಲಮಾದರಿಯಲ್ಲಿ(prototype)

ಅಳವಡಿಸಬಹುದು ಮತ್ತು ಗ್ರಾಹಕರು ನಿಖರವಾಗಿ

ಅವರ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವವರೆಗೆ, ಮೂಲಮಾದರಿಯ

(prototype)ಪರಿಷ್ಕರಣೆ ಮುಂದುವರಿಯುತ್ತದೆ.

ಮೂಲಮಾದರಿಯನ್ನು(Prototype) ನಿರ್ಮಿಸಲು ಇನ್ನೊಂದು

ಕಾರಣವೆಂದರೆ ಕೆಲವು ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳನ್ನು

ಪೂರೈಸಬಹುದೇ ಎಂದು ಕೆಲವೊಮ್ಮೆ ಡೆವಲಪರ್‌ಗಳಿಗೆ

ತಿಳಿದಿರುವುದಿಲ್ಲ.

ಮೂಲಮಾದರಿಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಎರಡು ಪ್ರಯೋಜನಗಳಿವೆ;

ಒಂದು ಗ್ರಾಹಕರು ವ್ಯವಸ್ಥೆಯ ಅನುಭವವನ್ನು ಪಡೆಯುತ್ತಾರೆ

ಮತ್ತು ಯಾವುದೇ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮಾರ್ಪಡಿಸಬಹುದು.

ಎರಡನೆಯದು ತಾಂತ್ರಿಕವಾಗಿದ್ದು, ಡೆವಲಪರ್‌ಗಳು ತಾಂತ್ರಿಕತೆಗಳ

ಮೇಲೆ ಕೆಲವು ಅಂಶಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡಲು ಬಯಸಬಹುದು

ಮತ್ತು ನಂತರ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಯಾವ

ಮಾರ್ಗವನ್ನು ನಿರ್ಧರಿಸಬಹುದು.

ಮೂಲಮಾದರಿಯು(prototyping) ಉಪಯುಕ್ತವಾಗಲು ಇನ್ನೊಂದು

ಕಾರಣವಿದೆ, ಡೆವಲಪರ್‌ಗಳು ಕೆಲಸವನ್ನು ಮಾಡುವ

ಮೂಲಕ ಕಲಿಯುತ್ತಾರೆ.

ಆದ್ದರಿಂದ, ಮೂಲಮಾದರಿಯು(prototyping) ಪೂರ್ಣಗೊಂಡ ನಂತರ ಎರಡನೆಯದು

ಅವರು ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ

ಮತ್ತು ಅವರು ಉತ್ತಮ ಕೆಲಸವನ್ನು ಮಾಡಬಹುದು.

ಮತ್ತು ಮೂಲಮಾದರಿಯನ್ನು(prototype) ನೋಡುವ ಬಳಕೆದಾರರು

ಅವಶ್ಯಕತೆಗಳನ್ನು ಅಂತಿಮಗೊಳಿಸಬಹುದು.

ಅದು ಗ್ರಾಹಕರೊಂದಿಗೆ ಸುಧಾರಿತ ಸಂವಹನವಾಗಿದೆ.

ಶುದ್ಧ ಜಲಪಾತದ ಮಾದರಿಯಲ್ಲಿ(pure waterfall Model) ಗ್ರಾಹಕರು

ಸಂಪೂರ್ಣ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಭಾವಿಸುತ್ತಾರೆ

ಮತ್ತು ಗ್ರಾಹಕರು ಕಾಯಬೇಕಾಗುತ್ತದೆ ಆದರೆ ಇಲ್ಲಿ ಅವರು

ಮೂಲಮಾದರಿಯನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಸಿಸ್ಟಮ್ ಅಂತಿಮವಾಗಿ

ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು.

ಇದು ದಾಖಲೀಕರಣದ ಅಗತ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ

ಮತ್ತು ವಿಶಿಷ್ಟವಾಗಿ ಮೂಲಮಾದರಿಯ ಮಾದರಿಯಾಗಿದೆ(prototype).

ನಿರ್ವಹಣಾ ವೆಚ್ಚವು ಕಡಿಮೆಯಾಗಿದೆ ಏಕೆಂದರೆ

ಅಭಿವೃದ್ಧಿಯ ಗುಣಮಟ್ಟ ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು

ಹೀಗಾಗಿ ಇದು ಕಡಿಮೆ ನಿರ್ವಹಣಾ ವೆಚ್ಚವನ್ನು

ಹೊಂದಿದೆ.

ಗ್ರಾಹಕರು ಸಾಫ್ಟ್‌ವೇರ್ ಕುರಿತು ವಿವರಿಸಲಾಗಿದೆ

ಮತ್ತು ಅವರ ಮನಸ್ಸನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಬಳಕೆದಾರ

ಇಂಟರ್ಫೇಸ್ ಸಮಸ್ಯೆಗಳು, ಪ್ರದರ್ಶನದ ಸ್ವರೂಪ(format

of display), ಸಂವಾದಾತ್ಮಕ ಸಂಭಾಷಣೆಗಳು(interactive

dislogues) ಮತ್ತು ಇತ್ಯಾದಿಗಳನ್ನು ವಿಶೇಷವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು.

ಡೆವಲಪರ್‌ಗಳು ಸಹ ಹಾರ್ಡ್‌ವೇರ್ ನಿಯಂತ್ರಕದ ಪ್ರತಿಕ್ರಿಯೆ

ಸಮಯದಂತಹ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.

ಆದ್ದರಿಂದ, ಗ್ರಾಹಕರು ಸಾಫ್ಟ್‌ವೇರ್‌ನ ವೀಕ್ಷಣೆಯನ್ನು

ಪಡೆಯಬಹುದು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ತಾಂತ್ರಿಕ

ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದಾದ ಪ್ರೊಟೋಟೈಪ್ ಮಾಡೆಲ್(prototype

model) ಪ್ರಮುಖ ಅನುಕೂಲಗಳು ಇವೆರಡು.

ನಾವು ಈ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸುತ್ತೇವೆ

ಮತ್ತು ನಾವು ಮುಂದಿನ ಉಪನ್ಯಾಸದಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತೇವೆ.

ಧನ್ಯವಾದ.