Lecture 10: Incremental Model

Summary

The video script discusses the Prototyping Model, an iterative approach in software development that contrasts with the traditional Waterfall Model. It highlights the benefits of prototyping, such as better understanding of requirements, early detection of issues, and improved client engagement through feedback incorporation. The script also touches upon the Agile Model, emphasizing incremental development and iterative enhancement, which allows for more flexibility and customer-oriented outcomes in software projects.

Takeaways

• 😀 The script discusses the Prototyping Model as an alternative to the Waterfall Model in software development.
• 🔍 A prototype is initially created to explore and define requirements and is then presented to users for feedback.
• 🔧 The flexibility of the Prototyping Model allows for changes based on user feedback, which can lead to a more refined final product.
• 💡 The model helps in clarifying vague or uncertain requirements early in the development process by providing a tangible starting point.
• 👥 It emphasizes user interaction and feedback, which can lead to a product that better meets user needs and expectations.
• 📋 The script suggests that the Prototype Model may reduce the need for extensive documentation compared to other models.
• 🚀 The development process can be faster and more efficient with the Prototyping Model because it allows for iterative improvements based on user input.
• 🛠️ The model can be particularly useful for Graphical User Interface (GUI) development, where user experience is critical.
• 🔄 The script mentions that the Prototype Model can lead to 'Over Engineering' where developers may incorporate unnecessary features tempted by the prototype's success.
• 📉 One of the downsides of the Prototype Model is that it may not be suitable for projects where requirements are well-understood and stable from the outset.
• 🔮 The script also touches on the classical Waterfall Model and its limitations, such as the inflexibility to change requirements once the development process has begun.

Q & A

What is the primary purpose of the Prototyping Model in software development?

The primary purpose of the Prototyping Model is to analyze and clarify requirements and provide a platform for users to interact with a preliminary version of the software, allowing for feedback and potential changes before the actual development begins.

How does the Waterfall Model relate to the Prototyping Model?

The Waterfall Model is a sequential design process where each phase of software development proceeds in a strict sequence, and the Prototyping Model can be seen as a precursor to the Waterfall Model, where the prototype is used to gather user feedback before the formal development process begins.

What are some advantages of using the Prototyping Model in software development?

Some advantages include the ability to clarify vague requirements early on, reduce development risks by allowing users to interact with a preliminary version, and potentially lower documentation needs since the prototype serves as a functional requirement document.

How does the Prototyping Model assist in the development of Graphical User Interfaces (GUIs)?

The Prototyping Model is particularly useful for GUI development as it allows for the quick creation of a visual interface that can be tested and refined based on user feedback, ensuring that the final product meets user expectations and is personalized to their needs.

What is the significance of user feedback in the Prototyping Model?

User feedback is significant as it helps developers understand whether the prototype meets the users' needs and expectations, allowing for necessary adjustments to be made before proceeding with full-scale development, thus enhancing the final product's usability and functionality.

Can the Prototyping Model lead to over-engineering in software development?

Yes, the Prototyping Model can lead to over-engineering if developers are tempted to incorporate advanced features into the prototype that may not be necessary, thus increasing the complexity and cost of the project without adding value.

Why might the Waterfall Model be considered outdated in modern software development?

The Waterfall Model might be considered outdated because it requires all requirements to be defined upfront, which is often impractical in the dynamic and iterative nature of modern software development where requirements frequently change.

What are some of the key challenges associated with the Waterfall Model?

Key challenges include the inflexibility to accommodate changes once the development process has started, the heavy documentation burden, and the potential for developers to spend a significant amount of time on documentation rather than actual development.

How does the Incremental Development Model differ from the Waterfall Model?

The Incremental Development Model involves developing and delivering the software in increments or iterations, allowing for continuous feedback and refinement, as opposed to the Waterfall Model, which follows a strict sequence of phases with little to no iteration.

What is the Iterative Enhancement Model and how does it improve software development?

The Iterative Enhancement Model is a development approach where the software is incrementally improved upon with each iteration, incorporating new functionalities and refining existing ones based on user feedback, leading to a more refined and user-centric final product.

Why is it important to prioritize certain features during incremental development?

Prioritizing certain features is important to ensure that the most critical and valuable functionalities are developed first, allowing for early delivery of a minimum viable product and subsequent refinement based on user interaction and feedback.

Outlines

00:00

🛠 Prototyping Model Overview

The first paragraph introduces the concept of the Prototyping Model as an alternative to the traditional Waterfall Model. It discusses the iterative process of developing a prototype, presenting it to users, and incorporating their feedback for improvements. The model allows for clearer understanding of requirements and is beneficial for projects with uncertain or evolving needs. It emphasizes the importance of user interaction and the reduction of development risks by allowing changes based on real-world feedback. The paragraph also mentions the reduced necessity for formal documentation like the Software Requirements Specification (SRS) due to the prototype serving as a functional requirement specification.

05:04

🎨 GUI Development through Prototyping

The second paragraph delves into the application of the Prototyping Model, especially for Graphical User Interface (GUI) development. It highlights the rapid creation of a prototype to gather client feedback and the iterative refinement of the GUI based on this input. The paragraph mentions that developers can use the prototype to address technical issues and ensure optimal design. It also discusses the common practice of presenting a prototype with shortcuts and placeholder functions to clients to facilitate a more accurate development process based on their reactions and suggestions.

10:05

🔄 Advantages and Limitations of the Prototyping Model

The third paragraph discusses the advantages of the Prototyping Model, such as the ability to accommodate user needs and reduce development costs. It also touches on the potential for over-engineering when developers are tempted to make the prototype more advanced than necessary. The paragraph points out the limitations of the Waterfall Model, which can be problematic due to the inflexibility in changing requirements and the heavy documentation process. It contrasts this with the Prototyping Model, which allows for more adaptive and customer-focused software development.

15:08

📉 Critique of the Waterfall Model

The fourth paragraph critiques the Waterfall Model, pointing out its inflexibility and the extensive documentation it requires. It notes that developers often spend half their time on paperwork, which can slow down the development process. The paragraph also references the views of renowned authors like Frederick P. Brooks, who argue against the Waterfall Model's approach due to its inherent issues and the impracticality of fully specifying requirements upfront.

20:10

🔧 Incremental and Iterative Development Models

The fifth paragraph introduces Incremental and Iterative development models as alternatives to the Waterfall Model. It explains how these models involve developing and enhancing the software in increments, allowing for client feedback to be incorporated at each stage. The paragraph emphasizes the iterative process of refining the software with each increment, making it more adaptable to changing requirements and more aligned with user expectations.

25:10

📈 Prioritization and Evaluation in Incremental Development

The sixth paragraph discusses the process of prioritization in Incremental Development Models. It presents a method for evaluating features based on customer value (V) and development cost (C), using a scale from 1 to 10. This approach helps in deciding which features to develop first, ensuring that the most valuable and feasible increments are prioritized. The paragraph also looks forward to discussing Evolutionary Models in future sessions, which build upon the concepts of Incremental and Iterative models.

Keywords

💡Prototyping Model

The Prototyping Model is an iterative approach to software development where a basic version of the product is created and then improved upon based on user feedback. It is central to the video's theme as it discusses the process of evolving the software by progressively incorporating user suggestions and refining the product. The script mentions that initially a prototype is developed, shown to users, and then any requested changes are accommodated, highlighting the dynamic and flexible nature of this model.

💡Waterfall Model

The Waterfall Model is a traditional software development process that follows a sequential design approach, where each phase of development must be completed before the next one can start. In the script, it is contrasted with the Prototyping Model, illustrating a more rigid and less adaptable development process. The video discusses how the Waterfall Model can be limiting due to its lack of accommodation for changes once development has begun.

💡Requirements Analysis

Requirements Analysis is the process of understanding and defining the needs and constraints of a project, which is crucial in software development. The script refers to this concept when discussing the initial phase of the Prototyping Model, where the needs are examined and a basic prototype is constructed. It is a fundamental step that sets the direction for the entire development process.

💡User Interface (UI)

User Interface, or UI, is the point of interaction between users and a software application. The video script emphasizes the importance of UI in the Prototyping Model, as it is where users can visualize the input data formats, display messages, reports, and interactive dialogues. The development of the UI often relies on prototyping to ensure it meets user expectations and is personalized to their needs.

💡Feedback

Feedback is the response from users regarding the software's functionality, design, and usability. The script mentions that after users see the prototype, they can provide feedback, which is critical for making changes and improvements. It is a key component of the Prototyping Model, allowing developers to understand user satisfaction and areas for enhancement.

💡Incremental Development

Incremental Development is a process where software is developed and delivered in small, iterative parts or increments. The script describes this as a series of steps where each increment builds upon the previous one, adding new features and refining the software based on user responses. This approach allows for continuous improvement and adaptation to user needs.

💡Iterative Enhancement Models

Iterative Enhancement Models refer to the development approach where the software is improved in cycles, with each iteration adding value and refining the product. The script discusses this concept as an alternative to the traditional Waterfall Model, emphasizing the ability to make ongoing improvements and adapt to changing requirements.

💡Over-Engineering

Over-Engineering occurs when a system or component is designed to be more complex than necessary. The script warns about the risk of over-engineering in the Prototyping Model, where developers might be tempted to incorporate advanced features that may not be required, thus making the prototype overly complex.

💡Agile Model

The Agile Model is a flexible approach to software development that promotes adaptive planning, evolutionary development, and continuous improvement. The script briefly mentions this model as an alternative to the Waterfall Model, highlighting its focus on minimal documentation and rapid, flexible response to change.

💡Customization

Customization is the process of adapting software to meet specific user requirements or preferences. The script discusses how the Waterfall Model can be problematic for applications that require high customization, as it is difficult to make changes once the development process has started.

💡Evolutionary Model

The Evolutionary Model is a software development approach where the system evolves over time through a series of incremental and iterative development cycles. The script suggests that this model will be discussed in more detail in a future lecture, indicating its relevance to the ongoing discourse about flexible and adaptive development methodologies.

Highlights

Prototyping model is an alternative to the Waterfall model.

Involves creating a prototype first to understand requirements better.

The prototype is shown to users and any required changes are incorporated.

Development starts using the Waterfall model once the users approve the prototype.

Helps in clarifying vague requirements early in the development process.

Allows for better communication with users through interaction with a preliminary software version.

Reduces the need for extensive documentation as the prototype serves as a functional requirement specification.

Useful for GUI development where user interfaces are highly personalized.

Helps in quickly identifying technical issues and allows for better design decisions.

Supports incremental development, which is efficient and can lead to better software quality.

Reduces development cost by minimizing the risk of significant rework.

May not be suitable for projects with well-understood issues and requirements from the start.

Can lead to over-engineering if advanced features are incorporated unnecessarily.

The Waterfall model is criticized for its inflexibility and inability to accommodate changes.

The Agile model is introduced as an alternative, emphasizing iterative development and minimal documentation.

Transcripts

ಸ್ವಾಗತ.

ಕೊನೆಯ ಉಪನ್ಯಾಸದಲ್ಲಿ, ನಾವು ಪ್ರೋಟೋಟೈಪಿಂಗ್

ಮಾಡೆಲ್(prototyping model) ಬಗ್ಗೆ ಚರ್ಚಿಸಿದ್ದೇವೆ.

ಪ್ರೋಟೋಟೈಪಿಂಗ್ ಮಾಡೆಲ್(prototyping model) ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್

(Waterfall Model) ರೂಪಾಂತರವಾಗಿದೆ.

ಪ್ರೋಟೋಟೈಪಿಂಗ್ ಮಾಡೆಲ್(prototyping model), ಅವಶ್ಯಕತೆಗಳ ವಿಶ್ಲೇಷಣೆ

ಮತ್ತು ವಿವರಣೆಯ ಸ್ಥಳದಲ್ಲಿ ನಾವು ಮೂಲಮಾದರಿಯ ನಿರ್ಮಾಣವನ್ನು

ಹೊಂದಿದ್ದೇವೆ.

ಮೊದಲು ಒಂದು ಮೂಲಮಾದರಿಯನ್ನು(prototype) ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ನಂತರ ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ

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

ಅವಕಾಶ ಕಲ್ಪಿಸಲಾಗುತ್ತದೆ.

ಗ್ರಾಹಕರು ಮೂಲಮಾದರಿಯನ್ನು(prototype) ಒಪ್ಪಿಕೊಂಡ ನಂತರ ಜಲಪಾತದ

ಮಾದರಿಯನ್ನು(waterfall Model) ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿ

ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಪ್ರೋಟೋಟೈಪಿಂಗ್ ಮಾಡೆಲ್(prototyping model)ಹಲವು ಅನುಕೂಲಗಳಿವೆ.

ಮೊದಲನೆಯದು, ಅವಶ್ಯಕತೆಗಳನ್ನು ಬರೆಯುವಾಗ ಏನು ಕಾಣೆಯಾಗಿದೆ

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

ಎಂಬುದನ್ನು ಗುರುತಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ, ಅಸ್ಪಷ್ಟ

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

ಆದರೆ ಡೆವಲಪರ್ ಮೂಲಮಾದರಿಯನ್ನು(prototype) ಅಭಿವೃದ್ಧಿಪಡಿಸಲು

ಪ್ರಾರಂಭಿಸಿದರೆ, ಅವಶ್ಯಕತೆಗಳೊಂದಿಗಿನ ತೊಂದರೆಗಳು ಯಾವುವು

ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಇದು ಕೇವಲ ದಾಖಲೆಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ

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

ಸಂವಹನವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ಅವರು ನಿಜ ಜೀವನದಲ್ಲಿ ಏನನ್ನಾದರೂ ನೋಡಬಹುದು

ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಅವರು ತಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು

ನೀಡಬಹುದು.

ಬಳಕೆದಾರರು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದಾರೆ

ಎಂದು ಭಾವಿಸುತ್ತಾರೆ ಏಕೆಂದರೆ ಅವರ ಕಾಮೆಂಟ್‌ಗಳ

ಪ್ರಕಾರ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗಿದೆ.

ದಸ್ತಾವೇಜನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಅವಶ್ಯಕತೆಯಿದೆ

ಏಕೆಂದರೆ ಮೂಲಮಾದರಿಯು ಅವಶ್ಯಕತೆಯ ಉದ್ದೇಶವಾಗಿ

ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಮೂಲಮಾದರಿಯು ಅನಿಮೇಟೆಡ್ ಅವಶ್ಯಕತೆಯ ವಿವರಣೆಯಾಗಿ

ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಾರಣ ಸೇವಾ ದಾಖಲೆ

ಇಲ್ಲ.

ಅಗತ್ಯವಿದ್ದರೆ, ಯೋಜನೆಯ ಆಧಾರದ ಮೇಲೆ SRS ಡಾಕ್ಯುಮೆಂಟ್

ಅನ್ನು ಮೂಲಮಾದರಿಯ(prototype) ಆಧಾರದ ಮೇಲೆ ಬರೆಯಬಹುದು.

ಸಾಮಾನ್ಯವಾಗಿ SRS ಡಾಕ್ಯುಮೆಂಟ್ ಅಗತ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ

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

ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

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

ಇದು ಕಡಿಮೆ ನಿರ್ವಹಣಾ ವೆಚ್ಚವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಮೊದಲು ಮೂಲಮಾದರಿಯು(prototype)

ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಾರೆ ಮತ್ತು ಮಾಡುವ ಮೂಲಕ

ಪರಿಣತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ನಿಜವಾದ ಅಭಿವೃದ್ಧಿಯನ್ನು

ಕೈಗೊಳ್ಳಲು ಉತ್ತಮವಾಗಿ ಸಿದ್ಧರಾಗಿದ್ದಾರೆ

ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ತಮ

ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಹೀಗಾಗಿ ನಿರ್ವಹಣೆ ವೆಚ್ಚ ಕಡಿಮೆ.

ಮೂಲಮಾದರಿಯ(prototype) ಮಾದರಿಯನ್ನು(model) ಏಕೆ ಬಳಸಲಾಗುತ್ತಿದೆ

ಎಂಬುದಕ್ಕೆ ಮುಖ್ಯ ಕಾರಣಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ

ಹೇಳಲು; ಮೂಲತಃ 2 ಕಾರಣಗಳಿವೆ.

ಮೊದಲನೆಯದು ಗ್ರಾಹಕರು ಸಾಫ್ಟ್‌ವೇರ್ ಬಗ್ಗೆ

ವಿವರಿಸಬಹುದು.

ವಿಶೇಷವಾಗಿ ಅವರು ಇನ್‌ಪುಟ್ ಡೇಟಾ ಸ್ವರೂಪಗಳು(data

formats), ಪ್ರದರ್ಶಿಸಲ್ಪಡುವ ಸಂದೇಶಗಳು(diaplay messages),

ವರದಿಗಳು(reports), ಸಂವಾದಾತ್ಮಕ ಸಂವಾದಗಳು(interactive dialogues)

ಮತ್ತು ಇತ್ಯಾದಿಗಳನ್ನು ನೋಡಬಹುದು ಏಕೆಂದರೆ

ಈ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಭಾಗವು ಹೆಚ್ಚಿನ ಮಟ್ಟಿಗೆ

ವೈಯಕ್ತಿಕ ಆಯ್ಕೆಯಾಗಿದೆ.

ಅದಕ್ಕಾಗಿಯೇ GUI ಭಾಗದಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ

ಮೂಲಮಾದರಿಯ ಮಾದರಿಯನ್ನು(prototyping model) ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ

ಮತ್ತು ಕೆಲವು ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳಿಗೆ ಸಹ, ಸಂಪೂರ್ಣ ಅಭಿವೃದ್ಧಿಯು

ಮೂಲಮಾದರಿ ಮಾದರಿಯ(prototyping model) ಪ್ರಕಾರವಾಗಿರುತ್ತದೆ.

ಪ್ರತಿ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ GUI ಸಾಮಾನ್ಯವಾಗಿ ಮೂಲಮಾದರಿಯ

ಮಾದರಿಯ(prototyping model) ಮೂಲಕ ಇರುತ್ತದೆ, ಅಲ್ಲಿ

GUI ಗಾಗಿ ತ್ವರಿತ ಮೂಲಮಾದರಿಯನ್ನು(prototyping) ತಯಾರಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ.

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

ಪರಿಶೀಲಿಸಲು ಸಹ ಇದು ಅನುಮತಿಸುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳು ಹಾರ್ಡ್‌ವೇರ್

ನಿಯಂತ್ರಕದ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯವನ್ನು ಅವಲಂಬಿಸಿರಬಹುದು

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

ಪ್ರಯೋಗಿಸಿದರೆ, ಅವರು ಅದನ್ನು ಉತ್ತಮವಾಗಿ

ವಿನ್ಯಾಸಗೊಳಿಸಬಹುದು.

ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಕಾರಣವಾಗುವ ಇನ್ನೊಂದು

ಕಾರಣವೆಂದರೆ ಅದನ್ನು ಮೊದಲ ಬಾರಿಗೆ ಸರಿಯಾಗಿ

ಪಡೆಯುವುದು ಅಸಾಧ್ಯ.

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

ಸುಲಭವಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳನ್ನು

ಪಡೆಯಬಹುದು ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅನೇಕ

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

ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬಯಸಿದರೆ ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು

ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬಾರದು ಎಂದು ಹೇಳುತ್ತಾರೆ.

ಇದನ್ನು ಗ್ರಾಹಕರಿಗೆ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ಮೂಲಮಾದರಿಯನ್ನು(prototyping) ಹಲವಾರು ಶಾರ್ಟ್‌ಕಟ್‌ಗಳನ್ನು

ಬಳಸಿಕೊಂಡು ನಿರ್ಮಿಸಲಾಗಿದೆ ಬಹುಶಃ ನಕಲಿ ಕಾರ್ಯಗಳು.

ನಿಜವಾದ ಗಣನೆ ಮತ್ತು ಇತ್ಯಾದಿಗಳ ಬದಲಿಗೆ

ಟೇಬಲ್ ಲುಕ್ ಅಪ್.

ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮೂಲಮಾದರಿಯ ಮೇಲೆ ಪಡೆಯಲಾಗುತ್ತದೆ

ಮತ್ತು ಕ್ಲೈಂಟ್ ಒಪ್ಪುವವರೆಗೂ ನಿಜವಾದ ಅಭಿವೃದ್ಧಿ(actual

deveopment) ಮುಂದುವರಿಯುತ್ತದೆ.

ಮೇಲಿನ ಸ್ಕೀಮ್ಯಾಟಿಕ್‌ನೊಂದಿಗೆ ನಾವು ಮೂಲಮಾದರಿಯ ಮಾದರಿಯನ್ನು(Prototyping

model) ಪ್ರತಿನಿಧಿಸಬಹುದು.

ಆರಂಭಿಕ ಅಗತ್ಯ ಸಂಗ್ರಹಣೆಯು ತ್ವರಿತ ವಿನ್ಯಾಸ ಮತ್ತು

ನಿರ್ಮಾಣದ ಮೂಲಮಾದರಿಯಾಗಿದೆ(prototyping model).

ಮೌಲ್ಯಮಾಪನಕ್ಕಾಗಿ ಗ್ರಾಹಕರಿಗೆ ಮೂಲಮಾದರಿಯನ್ನು

ನೀಡಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯ ಆಧಾರದ ಮೇಲೆ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಪರಿಷ್ಕರಿಸಿ.

ಮತ್ತೊಮ್ಮೆ, ಬದಲಾದ ಅವಶ್ಯಕತೆಗಳ ಆಧಾರದ

ಮೇಲೆ ತ್ವರಿತ ವಿನ್ಯಾಸವನ್ನು ಮಾಡಿ, ಮೂಲಮಾದರಿಯನ್ನು(prototyping)

ಪರಿಷ್ಕರಿಸಿ ಮತ್ತು ಇತ್ಯಾದಿ.

ಗ್ರಾಹಕರು ತೃಪ್ತರಾಗುವವರೆಗೆ ಇದು ಈ ಸೈಕಲ್ ನಲ್ಲಿ\

ಹೋಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅಭಿವೃದ್ಧಿಯ

ಕ್ಲಾಸಿಕಲ್ ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(classical waterfall model)ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಹೀಗಾಗಿ, ಇಲ್ಲಿ ನಿಜವಾದ ಅಭಿವೃದ್ಧಿಯು ಜಲಪಾತದ

ಮಾದರಿಯಾಗಿದೆ(actual development waterfal model) ಮತ್ತು ಜಲಪಾತದ

ಮಾದರಿಯೊಂದಿಗೆ(waterfall model) ಮುಖ್ಯ ವ್ಯತ್ಯಾಸವೆಂದರೆ

ಮೂಲಮಾದರಿ ನಿರ್ಮಾಣ(Prototype model).

ಮೂಲಮಾದರಿಯು(prototype model) ಅನಿಮೇಟೆಡ್ ಅವಶ್ಯಕತೆಗಳ

ವಿವರಣೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಮೂಲಮಾದರಿಯು(prototype model) SRS ಡಾಕ್ಯುಮೆಂಟ್‌ಗಾಗಿ

ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಆದರೆ ಒಮ್ಮೆ ಮೂಲಮಾದರಿಯು(prototype model) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

ಎಂಬುದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ, ಅದು ನಿಜವಾಗಿಯೂ

ನಿಜವಾದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಪರಿಷ್ಕರಿಸಲ್ಪಟ್ಟಿಲ್ಲ.

ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಮೊದಲಿನಿಂದ ಮತ್ತೆ

ಬರೆಯಲಾಗಿದೆ.

ಆರಂಭಿಕ ಮಾದರಿಯನ್ನು(initial model) ಎಸೆಯಲಾಗುತ್ತದೆ

ಮತ್ತು ಹೊಸ ಸಾಫ್ಟ್‌ವೇರ್(software) ಅನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ.

ಆದರೆ ಮೂಲಮಾದರಿಯನ್ನು(prototype model) ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದರಿಂದ

ಪಡೆದ ಅನುಭವವು ಅಭಿವರ್ಧಕರಿಗೆ(developers) ಸಹಾಯ ಮಾಡುತ್ತದೆ.

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

ಅಂತಿಮವಾಗಿ ಒಂದು ಉತ್ತಮ ಉಪಾಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ

ಮೂಲಕ ಮುಂಗಡ ಪ್ರಯೋಗವನ್ನು ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು

ವೆಚ್ಚವಾಗುತ್ತದೆ.

ಅನೇಕ ವಿಧದ ಯೋಜನೆಗಳಿಗೆ, ಮೂಲಮಾದರಿಯ(prototyping model)

ನಿರ್ಮಾಣವು ಸಣ್ಣ ಓವರ್ಹೆಡ್ ಆಗಿರಬಹುದು ಆದರೆ ನಿಜವಾದ

ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಬಹಳಷ್ಟು ಉಳಿತಾಯವಾಗಬಹುದು.

ಅನೇಕ ಬಳಕೆದಾರರ ಅವಶ್ಯಕತೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ,

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

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

ಪ್ರಮಾಣದಲ್ಲಿ ಕಡಿಮೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಉತ್ತಮ

ಗುಣಮಟ್ಟದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಹೀಗಾಗಿ, ಮೂಲಮಾದರಿಯ ಮಾದರಿಯನ್ನು(prototype model)

ಹೆಚ್ಚಾಗಿ ಆದ್ಯತೆ ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು

ವಿಶೇಷವಾಗಿ GUI ಗಾಗಿ ಮೂಲಮಾದರಿಯ ಮಾದರಿಯನ್ನು(prototype

model) ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ ಸಾಫ್ಟ್ವೇರ್ ಹೆಚ್ಚು ಬಳಸಬಹುದಾಗಿದೆ.

ಬಳಕೆದಾರರ ಅಗತ್ಯಗಳಿಗೆ ಉತ್ತಮ ಅವಕಾಶ ಕಲ್ಪಿಸಲಾಗಿದೆ

ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ತಮ ಗುಣಮಟ್ಟದ್ದಾಗಿದೆ.

ಪರಿಣಾಮವಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು

ಸುಲಭವಾಗಿದೆ ಮತ್ತು ಒಟ್ಟಾರೆ ಡೆವಲಪ್ಮೆಂಟ್

ಕಾಸ್ಟ್(Development cost)ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ.

ಅನಾನುಕೂಲಗಳೇನು?

ಕೆಲವು ಯೋಜನೆಗಳಿಗೆ(project) ಮೂಲಮಾದರಿಯು(prototype)

ದುಬಾರಿಯಾಗಬಹುದು.

ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ,

ಅವಶ್ಯಕತೆಗಳು ಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಮೂಲಮಾದರಿಯ(prototype) ನಿರ್ಮಾಣವು

ಹೆಚ್ಚುವರಿ ಓವರ್ಹೆಡ್ಗೆ ಸೇರಿಸುತ್ತದೆ.

ಮೂಲಮಾದರಿಯ ಮಾದರಿಯೊಂದಿಗಿನ(prototype model) ಮತ್ತೊಂದು ತೊಂದರೆ

ಎಂದರೆ ಓವರ್ ಎಂಜಿನಿಯರಿಂಗ್(Over Engineering).

ಡೆವಲಪರ್‌ಗಳು ಮೂಲಮಾದರಿಯನ್ನು(prototyping) ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ

ನಂತರ ಅವರು ಮೂಲಮಾದರಿಯಲ್ಲಿ(prototype) ಸಂಯೋಜಿಸದ(incorporate) ಅತ್ಯಾಧುನಿಕತೆಗಳನ್ನು

ಸಂಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳು

ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ, ಅವರು ಸರಳ ಮೂಲಮಾದರಿಯನ್ನು(simple

protoype) ಬರೆಯುವ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದರಿಂದ ಅದನ್ನು

ಮಾಡಲು ಪ್ರಚೋದಿಸಬಹುದು.

ಅವರು ಅದನ್ನು ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕವಾಗಿ

ಮಾಡಲು ಬಯಸುತ್ತಾರೆ.

ಆದ್ದರಿಂದ, ಪ್ರೊಟೋಟೈಪ್ ಮಾಡೆಲ್ (prototype model ) ಮಾದರಿಯನ್ನು

ಬಳಸಿದಾಗ, ಡೆವಲಪರ್‌ಗಳು ನಿಜವಾದ ಸಾಫ್ಟ್‌ವೇರ್

ಅನ್ನು ಹೆಚ್ಚು ಇಂಜಿನಿಯರ್ ಮಾಡಲು ಪ್ರಲೋಭನೆಗೆ(tempted)

ಒಳಗಾಗುತ್ತಾರೆ.

ಜಲಪಾತ ಆಧಾರಿತ ಮಾದರಿಯೊಂದಿಗಿನ(waterfall model based) ಪ್ರಮುಖ ತೊಂದರೆಗಳನ್ನು

ನೋಡೋಣ ಮತ್ತು ಈ ಮಾದರಿಗಳನ್ನು(model) ಏಕೆ ಬಳಸಲಾಗಿಲ್ಲ ಮತ್ತು

ಹೊಸ ಮಾದರಿಗಳು(model) ಬಂದವು.

ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು

ಅವಶ್ಯಕತೆಗಳನ್ನು ಫ್ರೀಜ್ ಮಾಡಬೇಕಾಗಿರುವುದು

ಒಂದು ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಅದು ಪ್ರತಿ ಜಲಪಾತ

ಆಧಾರಿತ ಮಾದರಿಯ ಲಕ್ಷಣವಾಗಿದೆ.

ವಾಸ್ತವದಲ್ಲಿ, ಅಭಿವೃದ್ಧಿ ಪ್ರಾರಂಭವಾದಾಗ ಸುಮಾರು

40 ಪ್ರತಿಶತದಷ್ಟು ಅವಶ್ಯಕತೆಗಳು ಬದಲಾಗುತ್ತವೆ ಮತ್ತು

ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಜಲಪಾತದ ಮಾದರಿಯನ್ನು(waterfall

model) ಬಳಸಿದರೆ, ಅಂತಿಮ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ

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

ಪೂರೈಸುವುದಿಲ್ಲ.

ಜಲಪಾತದ ಮಾದರಿಯು(waterfall model) ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ

ಉತ್ತಮವಾಗಿದೆ, ಇದನ್ನು 1970 ಮತ್ತು 80 ರ ದಶಕದಲ್ಲಿ

ಮಾಡಲಾಗುತ್ತಿದ್ದಂತೆ ಮೊದಲಿನಿಂದ ಬರೆಯಲಾಗಿದೆ.

ಆದರೆ ಈಗ ಜಲಪಾತದ ಮಾದರಿಯನ್ನು(waterfall model) ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ

ಗ್ರಾಹಕೀಕರಣವು(customization) ಹೆಚ್ಚು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ

ಏಕೆಂದರೆ ಜಲಪಾತದ ಮಾದರಿಯು (waterfall model)ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು

ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗಿದೆ.

ಗ್ರಾಹಕೀಕರಣವು(customization) ಬಹುಶಃ ನಾವು ಈಗಾಗಲೇ

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

ಸಣ್ಣ ಅಂಶವನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ.

ಆದ್ದರಿಂದ, ಇಲ್ಲಿ ಕೆಲಸವು ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು

ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ

ಮತ್ತು ಜಲಪಾತದ ಮಾದರಿಯೊಳಗೆ(waterfall model) ಹೊಂದಿಕೊಳ್ಳಲು

ಅವುಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ.

ಜಲಪಾತ-ಆಧಾರಿತ ಮಾದರಿಯೊಂದಿಗಿನ(Waterfall model based) ಕೊನೆಯ ಪ್ರಮುಖ

ತೊಂದರೆ ಏನೆಂದರೆ, "ಹೆವಿ ವೇಟ್ ಪ್ರಕ್ರಿಯೆಗಳು"(Heavy

Height Processes) ಇವೆ, ಏಕೆಂದರೆ ಬಹಳಷ್ಟು ದಾಖಲಾತಿಗಳನ್ನು

ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಹಂತದ ದಸ್ತಾವೇಜನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ಎಲ್ಲಾ ಜಲಪಾತ-ಆಧಾರಿತ ಮಾದರಿಗಳ((waterfall model) ಲಕ್ಷಣವೆಂದರೆ

ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಕೊನೆಯಲ್ಲಿ ದಾಖಲೆಗಳ

ಬೃಹತ್ ಪರ್ವತವಿದೆ ಮತ್ತು ಜಲಪಾತದ ಮಾದರಿಯನ್ನು(waterfall

model) ಭಾರೀ ತೂಕ ಎಂದು ಕರೆಯಲು ಇದು ಕಾರಣವಾಗಿದೆ.

ಕಾರ್ಯವಿಧಾನಗಳು.

ಜಲಪಾತದ ಮಾದರಿಯಲ್ಲಿ(waterfall model) ಡೆವಲಪರ್‌ಗಳು ಅರ್ಧದಷ್ಟು

ಸಮಯವನ್ನು ದಾಖಲಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಇದು ನಿಜವಾದ

ಅಭಿವೃದ್ಧಿಯಲ್ಲ ಎಂದು ಗಮನಿಸಲಾಗಿದೆ.

ಆದ್ದರಿಂದ, ನಾವು ದಸ್ತಾವೇಜನ್ನು ಕಡಿಮೆ ಮಾಡಿದರೆ ಅಭಿವೃದ್ಧಿಯನ್ನು

ವೇಗವಾಗಿ ಮಾಡಬಹುದು.

ನಂತರದ ಅಭಿವೃದ್ಧಿ ಮಾದರಿಗಳಲ್ಲಿ(Development

model) ಅಗೈಲ್ ಮಾದರಿಗಳಲ್ಲಿ(Agile Model) ದಾಖಲಾತಿಯನ್ನು

ಕನಿಷ್ಠವಾಗಿ ಇರಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.

ಆದರೆ ತೀವ್ರವಾಗಿ ಅನುಭವಿಸುವ ಪ್ರಮುಖ ತೊಂದರೆಗಳೆಂದರೆ,

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

ಮತ್ತು ಆ ಹಂತದಿಂದ ಅದನ್ನು ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ.

ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್(project manager) ಅವಶ್ಯಕತೆಗಳ ಆಧಾರದ

ಮೇಲೆ ಯೋಜನೆಗಳನ್ನು ರೂಪಿಸುವುದರಿಂದ ಮತ್ತು

ಯಾವುದೇ ಬದಲಾವಣೆಯನ್ನು ಸಂಯೋಜಿಸಿದರೆ ಅದು

ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದಲ್ಲಿ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಈ ಪ್ರದೇಶದ ಪ್ರಸಿದ್ಧ ಲೇಖಕರಾದ ಫ್ರೆಡೆರಿಕ್

ಬ್ರೂಕ್ಸ್ ಅವರು ಏನು ಹೇಳುತ್ತಾರೆಂದು ನೋಡೋಣ

"ಒಬ್ಬರು ಮುಂಚಿತವಾಗಿ ತೃಪ್ತಿದಾಯಕ ವ್ಯವಸ್ಥೆಯನ್ನು

ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು, ಅದರ ನಿರ್ಮಾಣಕ್ಕಾಗಿ

ಬಿಡ್ಗಳನ್ನು ಪಡೆಯಬಹುದು, ಅದನ್ನು ನಿರ್ಮಿಸಿ

ಮತ್ತು ಸ್ಥಾಪಿಸಬಹುದು ಎಂಬ ಊಹೆ.

ಈ ಊಹೆಯು ಮೂಲಭೂತವಾಗಿ ತಪ್ಪಾಗಿದೆ ಮತ್ತು

ಅನೇಕ ಸಾಫ್ಟ್‌ವೇರ್ ಆರೋಪದ ಸಮಸ್ಯೆಗಳು

ಇದರಿಂದ ಹುಟ್ಟಿಕೊಳ್ಳುತ್ತವೆ.

ಬ್ರೂಕ್ಸ್ ಅನೇಕ ಯೋಜನೆಗಳಲ್ಲಿ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದಾರೆ

ಮತ್ತು ಯಾವುದೇ ಗ್ರಾಹಕರಿಗೆ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಮುಂಚಿತವಾಗಿ ನೀಡುವುದು ಮತ್ತು ನಂತರ ಅದನ್ನು

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

ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ ಎಂದು ಗಮನಿಸಿದರು.

ಇದು ಮೂಲಭೂತವಾಗಿ ತಪ್ಪು ಮತ್ತು ಹೆಚ್ಚಿನ ಯೋಜನೆಯ

ವೈಫಲ್ಯಗಳು ಇದಕ್ಕೆ ಕಾರಣವೆಂದು ಅವರು ಹೇಳುತ್ತಾರೆ.

ಹೆಚ್ಚುತ್ತಿರುವ ಮಾದರಿಯನ್ನು(Model) ನೋಡಲಾಗುತ್ತಿದೆ.

ಈ ಮಾದರಿಯಲ್ಲಿ(model), ನಾವು ಇನ್‌ಕ್ರಿಮೆಂಟ್

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

ಒಂದು ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ

ಮೂಲಕ ಕಲಿಯುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಮುಂದಿನ

ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಮಾಡಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಸ್ಥಳದಲ್ಲಿ

ಕಂತು ಮಾಡಿ ಮತ್ತು ನಂತರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು

ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಮುಂದಿನ ಇನ್‌ಕ್ರಿಮೆಂಟ್‌ನಲ್ಲಿ

ನಾವು ಅದನ್ನು ಸರಿಹೊಂದಿಸುತ್ತೇವೆ ಮತ್ತು ಇದು ಇಟೆರಟಿವೆ

ಎಂಹನ್ಸಮೆಂಟ್ ಮಾಡೆಲ್ (Iterative Enhancement Models).

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, “ಮೂಲ ಕಲ್ಪನೆ, ಹೆಚ್ಚಳದ

ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಕಲಿಯುವ ಲಾಭವನ್ನು

ಪಡೆದುಕೊಳ್ಳಿ.

ಕಲಿಕೆಯು ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿ ಮತ್ತು

ಬಳಕೆ ಎರಡರಿಂದಲೂ ಬರುತ್ತದೆ.

ಅವಶ್ಯಕತೆಯ ಉಪವಿಭಾಗದ ಸರಳ ಅನುಷ್ಠಾನದೊಂದಿಗೆ(Simple

implementation) ಪ್ರಾರಂಭಿಸಿ; ಆವೃತ್ತಿಗಳ ಇಟೆರಟಿವೆ

ಎನ್ಹ್ಯಾನ್ಸ್ (iteratively enhance) ಪುನರಾವರ್ತಿತವಾಗಿ

ವರ್ಧಿಸುತ್ತದೆ.

ಪ್ರತಿ ಆವೃತ್ತಿಯಲ್ಲಿ ಹೊಸ ಕ್ರಿಯಾತ್ಮಕ ಸಾಮರ್ಥ್ಯಗಳನ್ನು

ಸೇರಿಸುವುದರೊಂದಿಗೆ ವಿನ್ಯಾಸ ಮಾರ್ಪಾಡುಗಳನ್ನು

ಮಾಡಲಾಗುತ್ತದೆ.

ಹೆಚ್ಚುತ್ತಿರುವ ಮತ್ತು ಇಂಕ್ರಿಮೆಂಟಲ್ ಡೆವಲಪ್ಮೆಂಟ್

(Incremental development) ಪ್ರಮುಖ ಲಕ್ಷಣವೆಂದರೆ ಅದು

ವ್ಯವಸ್ಥೆಯನ್ನು ಹೆಚ್ಚುತ್ತಿರುವ ರೀತಿಯಲ್ಲಿ ನಿರ್ಮಿಸುತ್ತದೆ.

ಯೋಜಿತ ಸಂಖ್ಯೆಯ ಪುನರಾವರ್ತನೆಗಳಿವೆ ಮತ್ತು ಆರಂಭಿಕ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಆವೃತ್ತಿಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ ಮತ್ತು ಅವುಗಳು ಏರಿಕೆಗಳಾಗಿವೆ.

ಪ್ರತಿ ಪುನರಾವರ್ತನೆಯು ಕ್ಲೈಂಟ್‌ನ ಸ್ಥಳದಲ್ಲಿ

ಸ್ಥಾಪಿಸಲಾದ ಕೆಲಸದ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು

ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಮುಖ್ಯ ಪ್ರಯೋಜನಗಳೆಂದರೆ, ಕ್ಲೈಂಟ್ ಮುಂದಿನ ಇನ್‌ಕ್ರಿಮೆಂಟ್‌ನಲ್ಲಿ

ಸೇರಿಸಬಹುದಾದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಬಹುದು ಮತ್ತು ಈ

ತಂತ್ರಗಳು ವಾಸ್ತವವಾಗಿ ಚುರುಕುಬುದ್ಧಿಯ ತಂತ್ರಗಳಿಗೆ

(ಅಂದರೆ ತರ್ಕಬದ್ಧ ಏಕೀಕೃತ ಪ್ರಕ್ರಿಯೆ

ಮತ್ತು ತೀವ್ರ ಪ್ರೋಗ್ರಾಮಿಂಗ್) ಅಡಿಪಾಯವಾಗಿದೆ.

ಹೆಚ್ಚುತ್ತಿರುವ ಅಭಿವೃದ್ಧಿಯು ಅನೇಕ ಪ್ರಯೋಜನಗಳನ್ನು

ಹೊಂದಿದೆ.

ನಾವು ಹೆಚ್ಚುತ್ತಿರುವ ಅಭಿವೃದ್ಧಿಯ ಗ್ರಾಹಕರ

ದೃಷ್ಟಿಕೋನದಿಂದ ನೋಡಿದರೆ.

ಆರಂಭದಲ್ಲಿ ಅವರು ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಪ್ರಮುಖ ಭಾಗವನ್ನು

ಪಡೆಯುತ್ತಾರೆ, ಪ್ರಯೋಗಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು

ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತಾರೆ.

ಪೂರ್ಣ ಸಾಫ್ಟ್‌ವೇರ್ ತಯಾರಿಸುವವರೆಗೆ ಅವರು

ಸ್ವಲ್ಪ ದೊಡ್ಡ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ.

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

ಅವಶ್ಯಕತೆಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು

ಅವರು ಇದನ್ನು ವಿತರಿಸಬಹುದಾದ ವೈಶಿಷ್ಟ್ಯಗಳಾಗಿ

ವಿಭಜಿಸುತ್ತಾರೆ.

ಒಟ್ಟಾರೆ ವಿನ್ಯಾಸವನ್ನು ಮಾಡಲಾಗಿದೆ ಮತ್ತು

ಅವರು ಏರಿಕೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಲೇ

ಇರುತ್ತಾರೆ, ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ,

ಹಿಂದಿನ ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತಾರೆ,

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

ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವವರೆಗೆ

ಮತ್ತು ಅಂತಿಮವಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ತಲುಪಿಸುತ್ತಾರೆ.

ಆರಂಭಿಕ ಅವಶ್ಯಕತೆಗಳನ್ನು ವೈಶಿಷ್ಟ್ಯಗಳಾಗಿ

ವಿಭಜಿಸಲಾಗಿದೆ ಮತ್ತು ಅವುಗಳು ಒಂದು ಸಮಯದಲ್ಲಿ

ಒಂದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು

ಮುಂದುವರಿಸಬಹುದು.

ಸಹಬಾಳ್ವೆಯನ್ನು ಹಲವಾರು ವಿಧಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ:

ಒಟ್ಟಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು (ಸಮಯ ಅಥವಾ ಸ್ಥಳದಲ್ಲಿ)

ಮತ್ತು ಪರಸ್ಪರ ಸಹಿಷ್ಣುತೆಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು.[2]

ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಬದುಕಲು ಕಲಿಯಲು.[3]

ಯಾವುದೇ ಪಕ್ಷಗಳು ಇತರರನ್ನು ನಾಶಮಾಡಲು ಪ್ರಯತ್ನಿಸದ

ವ್ಯಕ್ತಿಗಳು ಅಥವಾ ಗುಂಪುಗಳ ನಡುವೆ ಸಂಬಂಧವನ್ನು

ಹೊಂದಲು.[4] ಸಹಿಷ್ಣುತೆ, ಪರಸ್ಪರ

ಗೌರವ ಮತ್ತು ಹಿಂಸಾಚಾರವನ್ನು ಆಶ್ರಯಿಸದೆ ಸಂಘರ್ಷಗಳನ್ನು

ಇತ್ಯರ್ಥಪಡಿಸುವ ಒಪ್ಪಂದಕ್ಕೆ ಬದ್ಧತೆಯೊಂದಿಗೆ ಸಂವಹನ

ನಡೆಸುವುದು.[5] ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(Waterfall

Model) ನಾವು ಹೆಚ್ಚುತ್ತಿರುವ ಮಾದರಿಯನ್ನು(Model) ಹೋಲಿಸಿದರೆ,

ವಾಟರ್ಫಾಲ್ ಮಾಡೆಲ್(Waterfall Model) ಒಂದೇ ಬಿಡುಗಡೆಯನ್ನು

ಹೊಂದಿದೆ ಆದರೆ ಪುನರಾವರ್ತಿತ ಮಾದರಿಯಲ್ಲಿ(Iterative model)

ಗ್ರಾಹಕರಿಗೆ ಅನೇಕ ಧಾರ್ಮಿಕತೆಗಳಿವೆ.

ಮೊದಲ ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಮುಖ

ಕಾರ್ಯಚಟುವಟಿಕೆಯಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ಇನ್‌ಕ್ರಿಮೆಂಟ್‌ನಲ್ಲಿ

ಹೊಸ ಫುನ್ಕ್ಷನ್ಗಳನ್ನು(functions) ಸೇರಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯ ಪ್ರಕಾರ, ಮಾರ್ಪಾಡುಗಳನ್ನು

ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಉತ್ಪನ್ನದ

ಅಂತಿಮ ಹೆಚ್ಚಳವನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.

ಆದರೆ ಪ್ರತಿ ಪುನರಾವರ್ತನೆಯು ಜಲಪಾತದಂತಹ ಜೀವನ ಚಕ್ರದಲ್ಲಿ(Iterative

waterfall life cycle) ಬಳಸಬಹುದಾದ ಸಣ್ಣ ಕಿರು ಪ್ರಾಜೆಕ್ಟ್

ಆಗಿದೆ (small mini project).

ಸಂಪೂರ್ಣ ಅಗತ್ಯವನ್ನು ಏರಿಕೆಗಳಾಗಿ ವಿಭಜಿಸಲಾಗಿದೆ;

ಮೊದಲ ಹೆಚ್ಚಳವು ವಿನ್ಯಾಸ(design), ನಿರ್ಮಾಣ(build), ಸ್ಥಾಪನೆ(install)

ಮತ್ತು ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿದೆ(customer feedback).

ಮೊದಲ ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು(customer

feedback) ಪಡೆದ ನಂತರ, ಎರಡನೇ ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ

ಮತ್ತು ನಂತರ ಮೂರನೆಯದು ಮತ್ತು ಈ ಕೆಳಗಿನಂತೆ

ವಿಶ್ರಾಂತಿ(rest) ಪಡೆಯುತ್ತದೆ.

ಒಂದು ಇನ್ಕ್ರಿಮೆಂಟ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ

ಸಮಯವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಟೈಮ್ ಬಾಕ್ಸ್ ಎಂದು

ಕರೆಯಲಾಗುತ್ತದೆ.

ನಾವು ಹೆಚ್ಚುತ್ತಿರುವ ಮಾದರಿಯನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು.

ಪ್ರತಿ ಬಾರಿ ಒಂದು ಇನ್ಕ್ರಿಮೆಂಟ್ ಅನ್ನು

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

ಏರಿಕೆಗಳನ್ನು ಯೋಜಿಸಲಾಗಿದೆ.

ಇನ್‌ಕ್ರಿಮೆಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ ಮತ್ತು ಅದನ್ನು

ಕಾರ್ಯಗತಗೊಳಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ

ಮಾಡಿ ಮತ್ತು ಪೂರ್ಣ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು

ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರೆಗೆ ಇದು ಒಂದರ ನಂತರ ಒಂದರಂತೆ

ಇನ್ಕ್ರಿಮೆಂಟ್(increment) ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ.

ಆದರೆ ಯಾವ ಹೆಚ್ಚಳವನ್ನು ಮೊದಲು ಮಾಡಲಾಗುತ್ತದೆ

ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತಾರೆ?

ಆರಂಭದಲ್ಲಿ ನಾವು ಕೆಲವು ಏರಿಕೆಗಳನ್ನು ಮಾಡಬೇಕು

ಏಕೆಂದರೆ ಇತರರು ಅದರ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬಹುದು.

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

ಮಾಡಲಾಗಿದ್ದರೆ, ನಾವು ಮೌಲ್ಯದಿಂದ ವೆಚ್ಚದ

ಅನುಪಾತವನ್ನು ಗಣಿಸಬಹುದು, ಅದು V ಬೈ ಸಿ ಅನುಪಾತ

ಎಂದು ತಿಳಿಯುತ್ತದೆ; ಅಲ್ಲಿ, V ಎಂಬುದು ಗ್ರಾಹಕರಿಗೆ

ಮೌಲ್ಯವಾಗಿದೆ.(1 ರಿಂದ 10 ರ ನಡುವಿನ ಮೌಲ್ಯವನ್ನು

ನೀಡಿ) ಮತ್ತು C ವೆಚ್ಚವು ಅಭಿವೃದ್ಧಿಯ ವೆಚ್ಚವಾಗಿದೆ

(1 ರಿಂದ 10 ರ ನಡುವೆ).

ಇದು ಕೇವಲ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ ಮತ್ತು ಮುಂದಿನ ಉಪನ್ಯಾಸದಲ್ಲಿ

ಪುನರಾವರ್ತನೆಗಳೊಂದಿಗೆ ವಿಕಸನೀಯ ಮಾದರಿಯ(evolutionary

model) ಬಗ್ಗೆ ನಾವು ಚರ್ಚಿಸುತ್ತೇವೆ.

ಹೆಚ್ಚುತ್ತಿರುವ ಮಾದರಿಯು(model) ಬಹಳ ಮುಖ್ಯವಾದ ಮಾದರಿಯಾಗಿದೆ

ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ಅದು ಬಹಳಷ್ಟು

ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಮುಂದೆ, ನಾವು

ವಿಕಸನೀಯ ಮಾದರಿಯನ್ನು(evolutionary model) ನೋಡುತ್ತೇವೆ ಮತ್ತು

ಈ ಎರಡು ಮಾದರಿಗಳ(models) ಆಧಾರದ ಮೇಲೆ ನಾವು

ಚುರುಕಾದ ಮಾದರಿಗಳನ್ನು(Agile models) ನೋಡುತ್ತೇವೆ.