Lecture 11: Evolutionary Model

Summary

The video script delves into various software development models, highlighting the Incremental Development Model and its evolution from the Waterfall Model. It discusses the necessity for adaptability in project requirements and the shortcomings of fixed models in handling such changes. The script explores the Evolutionary Model and its iterative approach to development, emphasizing the importance of client feedback and the flexibility to incorporate changes. It also touches on the Rapid Application Development (RAD) model, emphasizing quick prototyping and customer interaction, and concludes with the Unified Process, an iterative and incremental approach to software development that involves four phases: Inception, Elaboration, Construction, and Transition.

Takeaways

• 📈 The Incremental Development Model builds upon the Waterfall Model by addressing its limitations and allowing for changes in requirements as a project progresses.
• 🔄 Requirements often change during a software project due to various reasons, including clients' inability to fully visualize the software before its creation, leading to many requirements being discarded or altered.
• 🔍 Capers Jones’s research across 8000 projects revealed that about 40% of requirements change during development, which is a significant issue not well addressed by either the Waterfall or Incremental Model.
• 🛠 The Evolutionary Model attempts to embrace all requirements and iteratively develop features based on client feedback, allowing the software to evolve and adapt to real-world usage.
• 🔑 The key difference between the Incremental Model and the full Evolutionary Model lies in the approach to requirement specification, with the latter allowing for more flexibility and less rigid planning.
• 🚀 The Evolutionary Model is sometimes referred to as 'plan a little, design a little, code a little,' emphasizing the iterative and incremental development of features based on client input.
• 🔄 The model supports changes in requirements and design throughout the development process, ensuring that the final software product is more aligned with user needs and feedback.
• 🌐 The iterative nature of the Evolutionary Model allows for the gradual integration of new features and functions, with each iteration potentially adding to the system's functionality based on client site deployment.
• 🛑 The model also acknowledges the unpredictability of software development, allowing for changes in direction and adjustments to the development process as needed.
• 🔍 The Unified Process, developed by Jacobson, Booch, and Rumbaugh, is an iterative and incremental approach widely used in object-oriented software development, emphasizing the importance of client interaction and feedback throughout the development lifecycle.
• 📊 The Unified Process is structured into four phases: Inception, Elaboration, Construction, and Transition, each with its own set of activities and iterations, culminating in the deployment of the software to the client.

Q & A

What does the Incremental Development Model address that the Waterfall Model does not?

The Incremental Development Model addresses the limitations of the Waterfall Model by allowing for changes in requirements as the project progresses, whereas the Waterfall Model does not accommodate such changes once the development process has begun.

Why might software requirements change during the development process?

Software requirements may change due to various factors, such as clients gaining a better understanding of what they want as the software takes shape, or because initial requirements were not fully understood or specified at the outset.

What did Capers Jones’s research on 8000 projects reveal about requirement changes?

Capers Jones’s research found that during the development phase, about 40 percent of the requirements change. This highlights the importance of development models that can accommodate such changes, unlike the Waterfall Model.

How does the Evolutionary Model differ from the Incremental Model in terms of requirement specification?

The Evolutionary Model, unlike the Incremental Model, does not require a complete specification of all requirements upfront. Instead, it focuses on identifying a set of features and evolving the software by adding more features based on client feedback and testing.

What is the basic principle behind the 'plan a little, design a little, code a little' approach in the Evolutionary Model?

This approach in the Evolutionary Model emphasizes incremental development where each iteration focuses on a small set of features. It allows for continuous refinement and adaptation of the software based on user feedback and evolving requirements.

How does the client's involvement in the Evolutionary Model differ from other models?

In the Evolutionary Model, clients are involved throughout the development process, providing feedback on each iteration, which influences the evolution of the software. This is more interactive compared to models where client involvement is limited to the initial requirements phase.

What is the significance of the iterative approach in the Evolutionary Model?

The iterative approach in the Evolutionary Model allows for the continuous integration of new features and refinement of existing ones based on real-world usage and feedback. This leads to a more adaptive and user-focused development process.

How does the Rapid Application Development (RAD) Model differ from the Incremental and Evolutionary Models?

The RAD Model focuses on rapid prototyping and quick development cycles, often using high-level tools and standard APIs to speed up the process. It typically involves short-term planning and customization, with an emphasis on quick feedback and iteration.

What are the potential downsides of the Evolutionary Model in terms of project management?

The Evolutionary Model can lead to challenges in project management due to its iterative and adaptive nature, which may result in unpredictable timelines and budgets. It also requires a flexible and responsive team that can handle the uncertainty of evolving requirements.

How does the Unified Process address the iterative and incremental aspects of software development?

The Unified Process, developed by Jacobson, Booch, and Rumbaugh, is an iterative and incremental approach that encompasses four phases: Inception, Elaboration, Construction, and Transition. It allows for continuous refinement and client involvement throughout the development lifecycle.

What is the main advantage of using a graphical representation in the Unified Process?

A graphical representation in the Unified Process provides a visual overview of the development lifecycle, showing the phases and iterations, and highlighting the peaks and valleys of activities such as analysis, design, implementation, and testing.

Outlines

00:00

🔄 Incremental and Evolutionary Models in Software Development

The paragraph discusses the Incremental Development Model and its advantages over the traditional Waterfall Model, highlighting the need for flexibility in changing requirements. It introduces the Evolutionary Model, which accommodates these changes more effectively. The speaker references a study by Capers Jones, which found that 40% of requirements change during development, emphasizing the importance of models that can adapt to such changes. The paragraph also touches on the client-side planning in the Evolutionary Model and the iterative process of feature development and refinement.

05:01

👥 Roles and Perspectives on Iterative Software Engineering

This paragraph explores the roles of stakeholders, including testers and technical architects, in the iterative software development process. It contrasts the Iterative Waterfall Model with the Incremental Model and cites Tom Gilb's perspective on the importance of early feedback in complex systems. The paragraph discusses the Revolutionary Model, which emphasizes client feedback and feature selection based on usage, and Craig Larman's view on the iterative development of requirements, planning, and solutions. It also mentions the challenges of managing the unpredictable nature of software development.

10:04

🛠 The Evolutionary Model's Process and Client Interaction

The paragraph delves into the schematic representation of the Evolutionary Model, starting with a rough system design and evolving through iterations that include specification, development, validation, and deployment. It explains how each iteration refines the core system and integrates client feedback. The model's flexibility is highlighted, allowing for changes and adaptations based on user experience and feedback, leading to a more reliable final software delivery compared to the Waterfall Model.

15:08

📈 The Impact of Iterative Models on Project Management

This paragraph discusses the challenges of managing software projects using iterative models, such as the difficulty in predicting the number of iterations required for completion and the continuous changes in software requirements. It mentions the potential for increased complexity in project management due to the evolving nature of software development, the need for frequent releases, and the impact on client expectations and satisfaction.

20:08

🚀 Rapid Application Development (RAD) Model and Prototyping

The paragraph introduces the Rapid Application Development (RAD) Model, also known as Rapid Prototyping, which focuses on reducing development time and cost while allowing for quick changes. It explains the RAD Model's adherence to incremental development, the use of time-boxed iterations, and the emphasis on creating functional software with minimal design. The paragraph also addresses the trade-offs between speed and quality in RAD projects and the suitability of RAD for smaller, modular software development.

25:11

🔧 Unified Process and Iterative Software Development

This paragraph outlines the Unified Process, developed by Jacobson, Booch, and Rumbaugh, which is widely used in object-oriented software development. It describes the process as iterative and incremental, involving client-side deployment and feedback. The Rational Corporation's development process, now known as the Unified Process, was acquired by IBM in 2003. The Unified Process is divided into four phases: Inception, Elaboration, Construction, and Transition, each involving multiple iterations and activities.

📊 Outputs and Phases of the Unified Process

The final paragraph summarizes the outputs and phases of the Unified Process. It lists the deliverables for each phase, such as initial models, use cases, risk lists, and project plans in the Inception phase, and detailed models and user manuals in the Construction phase. The paragraph also mentions the graphical representation of the Unified Process, with the horizontal axis showing the lifecycle and the vertical axis showing the core process flow, illustrating the iterative nature of the process.

Keywords

💡Incremental Development Model

The Incremental Development Model is a software development approach where the product is built and delivered in stages, with each stage adding new features or functionality. It is a core concept in the video, illustrating an adaptive method to accommodate changing requirements. For example, the script mentions that 'In the Incremental Model, requirements change over time,' highlighting its flexibility compared to the traditional Waterfall Model.

💡Evolutionary Model

The Evolutionary Model is a development strategy that involves continuous refinement and enhancement of the software product through iterative cycles. It is integral to the video's theme of progressive development. The script refers to it as an approach that 'attempts to address the need to identify all requirements completely,' showcasing its dynamic nature in software evolution.

💡Software Engineering

Software Engineering is the application of engineering principles to software design, development, and maintenance. It is the overarching field within which the video's discussion of development models is situated. The script touches on various models and their impact on software engineering practices, emphasizing the importance of adapting to changing requirements and user feedback.

💡Rapid Prototyping

Rapid Prototyping is a method of quickly creating a minimally viable product to elicit user feedback and refine the product iteratively. It is a key concept in the video, as it exemplifies the agile approach to development. The script describes it as a process that 'reduces the time and cost of development,' allowing for swift adaptation to user needs.

💡Iterative Process

The Iterative Process involves repeating cycles of development and refinement, allowing for continuous improvement of the product. It is a fundamental concept in the video, as it underpins many of the discussed models. The script mentions that 'the project is developed in several increments,' which is characteristic of iterative processes.

💡Unified Process

The Unified Process, also known as the Rational Unified Process, is an iterative software development process that emphasizes the use of components and patterns. It is a significant framework discussed in the video, which includes phases like Inception, Elaboration, Construction, and Transition. The script refers to it as 'a more realistic picture of the software development lifecycle,' indicating its comprehensive approach.

💡Waterfall Model

The Waterfall Model is a traditional, linear approach to software development where progress flows sequentially through stages of conception, design, implementation, testing, and maintenance. It is contrasted with more flexible models in the video. The script points out its limitations, such as 'no opportunity for necessary changes during the development time,' to highlight the need for adaptive models.

💡Software Reliability

Software Reliability refers to the dependability of a software product to perform its intended function without failure. It is a critical aspect discussed in the context of development models. The script implies that models like the Waterfall Model may not ensure reliability due to the lack of iterative feedback and refinement.

💡Modular Design

Modular Design is an approach to software architecture where the system is divided into independent, interchangeable modules. It is relevant to the video's discussion on development models that promote maintainability and scalability. The script suggests that 'if the software is to be large and complex,' a modular approach like that in the Unified Process can be particularly useful.

💡Client-Side Development

Client-Side Development pertains to the creation of applications or features that run on the user's device, as opposed to server-side development. It is a term used in the video to describe where certain functionalities are planned and executed. The script mentions that 'features are developed and deployed at the client's site,' emphasizing the importance of user interaction and feedback in the development process.

💡Feedback Loop

A Feedback Loop is a process where the output of a system is used as input to refine the system's performance. It is central to the video's discussion of iterative and evolutionary models. The script describes how 'receiving feedback from the client and using it to refine the system' is a key part of the development process, illustrating the iterative nature of modern software development.

Highlights

Introduction to the Incremental Development Model and its advantages over the Waterfall Model.

Explanation of how requirements change frequently in real projects and the reasons behind it.

Capers Jones’s research findings on the high rate of requirement changes in software development projects.

The limitations of the Waterfall Model in handling requirement changes during development.

Description of the Incremental Model's approach to identifying and prioritizing requirements in slices.

The Evolutionary Model's strategy for dealing with the uncertainty of requirements in software projects.

Comparison between the Evolutionary Model and the Incremental Model, especially regarding client-side planning.

The concept of 'plan a little, design a little, code a little' in the Evolutionary Model.

Discussion on the importance of customer feedback in the Evolutionary Model for refining software features.

The iterative nature of the Evolutionary Model and its contrast with the traditional Waterfall Model.

Tom Gilb's perspective on the value of the Evolutionary Model in real-life projects for managing complexity.

Craig Larman's view on the iterative development process and its focus on planning, estimating, and solving within iterations.

The challenges of the Evolutionary Model, such as the unpredictability of the process and the difficulty in management.

The Rapid Application Development (RAD) Model and its emphasis on quick prototyping and reduced development time.

The Unified Process developed by Jacobson, Booch, and Rumbaugh for object-oriented software development.

The four phases of the Unified Process: Inception, Elaboration, Construction, and Transition.

The outputs of each phase in the Unified Process, from initial models to final software deployment.

The graphical representation of the Unified Process showing the lifecycle and core process flow.

Transcripts

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

ಕಳೆದ ಉಪನ್ಯಾಸದಲ್ಲಿ, ನಾವು ಇನ್ಕ್ರಿಮೆಂಟಲ್

ಡೆವಲಪ್ಮೆಂಟ್ ಮಾಡಲ್(Incremental Development Model)ನ ಬಗ್ಗೆ ಚರ್ಚಿಸಿದ್ದೇವೆ.

ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಮಾಡಲ್(Incremental Model), ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(waterfall

Model)ನ ಅನೇಕ ನ್ಯೂನತೆಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ.

ಈ ಉಪನ್ಯಾಸದಲ್ಲಿ, ನಾವು ಇಟೆರೇಷನ್(iteration)ಗಳೊಂದಿಗೆ

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model)ನ್ನು ನೋಡುತ್ತೇವೆ.

ಯಾವುದೇ ರಿಯಲ್(real) ಪ್ರಾಜೆಕ್ಟ್(project)ನಲ್ಲಿ, ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಮಾಡಲ್(Incremental

Model)ನಲ್ಲಿ ಅವಶ್ಯಕತೆಗಳು ಬದಲಾಗುತ್ತವೆ.

ಅವಶ್ಯಕತೆಗಳ ಬದಲಾವಣೆಯ ಹಿಂದೆ ಹಲವು ಕಾರಣಗಳಿವೆ.

ಸಾಫ್ಟ್‌ವೇರ್(software) ನಿರ್ಮಿಸುವ ಮೊದಲು

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

ವೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಗದಿರುವುದು ಒಂದು ಕಾರಣ, ಮತ್ತು

ಆದ್ದರಿಂದ, ಅನೇಕ ಅವಶ್ಯಕತೆಗಳು ತಪ್ಪಿಹೋಗಿವೆ, ಸಾಫ್ಟ್‌ವೇರ್(software)

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

ಅಸ್ಪಷ್ಟವಾಗಿ ನೀಡಲಾಗುತ್ತದೆ.

ಕೇಪರ್ಸ್ ಜೋನ್ಸ್(Capers Jones’s) ಸ್ಥಾಪಿತ ಸಂಶೋಧಕರು,

8000 ಪ್ರಾಜೆಕ್ಟ್(project)ಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡಿದರು ಮತ್ತು

ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ 40 ಪ್ರತಿಶತದಷ್ಟು ಅವಶ್ಯಕತೆಗಳು

ಬದಲಾಗುತ್ತವೆ ಎಂದು ಕಂಡುಕೊಂಡರು.

ಇದು ಬಹಳ ಮಹತ್ವದ ವಿಷಯವಾಗಿದೆ ಏಕೆಂದರೆ ವಾಟರ್ಫಾಲ್

ಮಾಡಲ್(waterfall Model)ಯಾಗಲೀ ಅಥವಾ ಇನ್ಕ್ರಿಮೆಂಟಲ್

ಮಾಡಲ್(Incremental Model)ಯಾಗಲೀ ಇದನ್ನು ತೃಪ್ತಿಕರವಾಗಿ

ನಿಭಾಯಿಸಲಿಲ್ಲ.

ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(waterfall Model)ನ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ

ಅಗತ್ಯ ಬದಲಾವಣೆಗೆ ಯಾವುದೇ ಅವಕಾಶವನ್ನು

ಹೊಂದಿಲ್ಲ.

ನಮಗೆ ತಿಳಿದಿರುವ ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಮಾಡಲ್(Incremental Model) ನಲ್ಲಿ,

ಮಾಡಲ್(Model)ನ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಮುಂಗಡವಾಗಿ ಗುರುತಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ

ಮತ್ತು ನಂತರ ಗ್ರಾಹಕರ ಬದಿಯಲ್ಲಿ ನಿಯೋಜಿಸಬೇಕಾದ

ಹೆಚ್ಚುತ್ತಿರುವ ವೈಶಿಷ್ಟ್ಯಗಳಾಗಿ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಸ್ಲೈಸ್ ಮಾಡುವುದು.

ಸಹಜವಾಗಿ, ಒಂದು ಫೀಚರ್(feature)ನ್ನು ಇನ್ಸ್ಟಾಲ್(instal) ಮಾಡುವಾಗ,

ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ, ಇದು

ಹೆಚ್ಚುವರಿ ಅವಶ್ಯಕತೆಗಳು ಅಥವಾ ಅವಶ್ಯಕತೆಗಳ

ಬದಲಾವಣೆಯ ಅಗತ್ಯವಾಗಬಹುದು.

ಆದರೆ ಇನ್ನೂ, ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಮಾಡಲ್(Incremental Model)ನ ಎಲ್ಲಾ

ಅವಶ್ಯಕತೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಮುಂಗಡವಾಗಿ

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

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model)ನ್ನು ನೋಡೋಣ, ಇದು

ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮುಂಗಡವಾಗಿ ಗುರುತಿಸುವ

ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model) ಮತ್ತು ಇನ್ಕ್ರಿಮೆಂಟಲ್

ಮಾಡಲ್(Incremental Model)ನ ನಡುವೆ ಕೆಲವು ಸಾಮ್ಯತೆಗಳಿವೆ,

ಅಂದರೆ ಏರಿಕೆಗಳನ್ನು ಕ್ಲೈಂಟ್-ಸೈಡ್‌(client-side)ನಲ್ಲಿ

ನಿಯೋಜಿಸಲಾಗಿದೆ.

ಆದರೆ ಇಲ್ಲಿ, ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model)ನಲ್ಲಿ,

ಯಾವುದೇ ಮುಂಗಡ ಅಗತ್ಯ ವಿವರಣೆಯ ಅಗತ್ಯವಿಲ್ಲ.

ಆರಂಭದಲ್ಲಿ, ಗುರುತಿಸಲಾದ ಕೆಲವು ಫೀಚರ್(feature)ಗಳನ್ನು

ಅಳವಡಿಸಲಾಗಿದೆ.

ತದನಂತರ, ಹೆಚ್ಚು ಹೆಚ್ಚು ಫೀಚರ್(feature)ಗಳನ್ನು

ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ನಿಯೋಜಿಸುವ

ಗ್ರಾಹಕರ ಪ್ರಯೋಗಗಳಂತೆ.

ಆದ್ದರಿಂದ, ಸಾಫ್ಟ್‌ವೇರ್ ವಾಸ್ತವವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತದೆ,

ಇದು ತುಂಬಾ ಸರಳವಾದ ಸಂಗತಿಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಆದರೆ ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಮಾಡಲ್(Incremental Model) ಮತ್ತು

ಸಂಪೂರ್ಣವಾಗಿ ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model) ನಡುವಿನ

ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅವಶ್ಯಕತೆಗಳ ಮುಂಗಡ

ಗುರುತಿಸುವಿಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಇರುತ್ತದೆ.

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model)ನ್ನು " ಪ್ಲಾನ್ ಎ

ಲಿಟಲ್ (plan a little) , ಡಿಸೈನ್ ಎ ಲಿಟಲ್ (design a little) , ಕೋಡ್

ಎ ಲಿಟಲ್(code a little)" ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ.

ಏಕೆಂದರೆ ಎವೊಲ್ಯೂಷನರಿ ಮಾಡೆಲ್(Evolutionary model)ನಲ್ಲಿ,

ಪ್ರತಿ ಬಾರಿಯೂ ಕೆಲವು ಫೀಚರ್(feature)ಗಳನ್ನು

ಮಾತ್ರ ಗುರುತಿಸಲಾಗುತ್ತದೆ.

ಗ್ರಾಹಕರ ಕಡೆಯಿಂದ ಮಾತ್ರ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ,

ಕೋಡ್ ಮಾಡಲಾದ ಮತ್ತು ನಿಯೋಜಿಸಲಾದ ಫೀಚರ್(feature)ನ

ಬೆಳವಣಿಗೆಗಳಿಗಾಗಿ ಪ್ರಾಜೆಕ್ಟ್(project) ಮಾಡಿ.

ಈ ಮಾಡಲ್(model), ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಮಾಡಲ್(Incremental Model)ಯಂತೆಯೇ,

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

ಅಂತಿಮ ಬಳಕೆದಾರರು ಅದರ ಬಗ್ಗೆ ತಮ್ಮ ಅನುಭವವನ್ನು

ನೀಡಬಹುದು.

ಪರೀಕ್ಷಕರು, ಇನ್ಕ್ರಿಮೆಂಟರ್‌(incrementor)ಗಳು, ತಾಂತ್ರಿಕ ಬರಹಗಾರರು

ಎಲ್ಲರೂ ಯೋಜನೆಯ ಪ್ರಾರಂಭದಿಂದ ತೊಡಗಿಸಿಕೊಳ್ಳುತ್ತಾರೆ,

ಇಟರೇಟಿವ್ ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(iterative waterfall model)ಗಿಂತ

ಭಿನ್ನವಾಗಿ.

ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರಿಂಗ್ ಕ್ಷೇತ್ರದ ಖ್ಯಾತ ವ್ಯಕ್ತಿ

ಟಾಮ್ ಗ್ಲಿಬ್ ಹೇಳಿದ್ದಾರೆ.

"ಸಣ್ಣ ಹಂತಗಳಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ

ಕಾಂಪ್ಲೆಕ್ಸ್(complex) ಸಿಸ್ಟಮ್(system)ನ ಅತ್ಯಂತ

ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ವೈಫಲ್ಯದ ಹಿಂದಿನ ಯಶಸ್ವಿ

ಹೆಜ್ಜೆಗೆ "ಹಿಮ್ಮೆಟ್ಟುವಿಕೆ" ... ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು

ಎಸೆಯುವ ಮೊದಲು ನೈಜ ಪ್ರಪಂಚದಿಂದ ಕೆಲವು

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

ನೀವು ಸಂಭವನೀಯ ಎರ್ರರ್(error)ಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದು"

ಆದ್ದರಿಂದ, ರೆವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(revolutionary model)ನ ದೊಡ್ಡ

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

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

ಕ್ಲೈಂಟ್ ವಿಕಸನಗೊಳ್ಳುವ ಸಿಸ್ಟಮ್(system) ಅನ್ನು

ಬಳಸುತ್ತಿರುವಂತೆ ಫೀಚರ್(feature)ಗಳನ್ನು

ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.

ಮತ್ತು ಕೆಲವು ಫೀಚರ್(feature)ಗಳು ಗ್ರಾಹಕರು ಇಷ್ಟಪಡದಿದ್ದರೆ,

ಆ ಫೀಚರ್(feature) ಅನ್ನು ಸರಳವಾಗಿ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ಹೊಸ ಫೀಚರ್(feature)ಗಳನ್ನು ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ.

ಪ್ರದೇಶದ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರಿಂಗ್‌ನ

ಇನ್ನೊಬ್ಬ ಪ್ರಸಿದ್ಧ ವ್ಯಕ್ತಿತ್ವದ ಕ್ರೇಗ್

ಲಾರ್ಮನ್, "ವಿಕಸನೀಯ ಇಟೆರೇಷನ್(iteration)ನ ಅಭಿವೃದ್ಧಿಯು

ಅವಶ್ಯಕತೆಗಳು, ಪ್ಲಾನ್, ಎಸ್ಟಿಮೇಟ್, ಅಂಡ್

ಸೊಲ್ಯೂಷನ್(plan, estimate, and solution), ಸಂಪೂರ್ಣವಾಗಿ

ವ್ಯಾಖ್ಯಾನಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಇಟೆರೇಷನ್(iteration)ಗಳ

ಅವಧಿಯಲ್ಲಿ ವಿಕಸನಗೊಳ್ಳುತ್ತದೆ ಅಥವಾ ಪರಿಷ್ಕರಿಸುತ್ತದೆ

ಎಂದು ಸೂಚಿಸುತ್ತದೆ.

ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಇಟೆರೇಷನ್(iteration)ಗಳು

ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಒಂದು ಪ್ರಮುಖ ಅಪ್-ಫ್ರಂಟ್(up-front)

ವಿವರಣೆಯ ಪ್ರಯತ್ನದಲ್ಲಿ "ಫ್ರೀಜ್" ಆಗಿರುತ್ತದೆ.

ವಿಕಸನೀಯ ವಿಧಾನಗಳು ಅನಿರೀಕ್ಷಿತ ಆವಿಷ್ಕಾರದ

ಮಾಡಲ್(model) ಮತ್ತು ಹೊಸ ಉತ್ಪನ್ನ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿನ

ಬದಲಾವಣೆಯೊಂದಿಗೆ ಸ್ಥಿರವಾಗಿವೆ.

ಇದರಿಂದ ನಾವು ಹೇಳಬಹುದು, ಕ್ರೇಗ್ ಲಾರ್ಮನ್ ಸಹ

ಮುಂಗಡ ವಿವರಣೆಯು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ ಎಂದು

ಒಪ್ಪಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ರೆವೊಲ್ಯೂಷನರಿ

ಮಾಡಲ್(revolutionary model) ನಿಜ ಜೀವನದ ಪ್ರಾಜೆಕ್ಟ್(project)ಗಳಲ್ಲಿ

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

ರೆವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(revolutionary model)ನಲ್ಲಿ ಏನು ಒಳಗೊಂಡಿದೆ

ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಸಾಫ್ಟ್‌ವೇರ್‌(software)ನ ಒಟ್ಟಾರೆ ತಿಳುವಳಿಕೆಯನ್ನು

ಆಧರಿಸಿ, ಮೊದಲು ಸಾಫ್ಟ್‌ವೇರ್‌(software)ನ ಕೋರ್ ಮಾಡ್ಯೂಲ್‌(core

module)ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಈ ಕೋರ್ ಮಾಡ್ಯೂಲ್‌(core

module)ಅನ್ನು ಐಟೆರೇಷನ್(iteration)ಗಳು ಎಂದು ಕರೆಯಲಾಗುವ ಸಾಮರ್ಥ್ಯದ

ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸುವಂತೆ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಇಟೆರೇಷನ್(iteration) ಹೊಸ ಫಂಕ್ಷನ್(function)ಗಳನ್ನು

ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಇವುಗಳನ್ನು ಕ್ಲೈಂಟ್(client)

ಸೈಟ್‌(site)ನಲ್ಲಿ ಅನುಕ್ರಮವಾಗಿ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿಯೊಂದು ಇಟೆರೇಷನ್ ವಾಸ್ತವವಾಗಿ ಮಿನಿ

ವಾಟರ್ಫಾಲ್(mini waterfall) ಆಗಿದೆ.

ಒಂದೇ ಇಟೆರೇಷನ್(iteration)ನ ನಂತರ ಕೆಲವು ಕೋಡ್

ಅನ್ನು ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್(client)

ತನ್ನ ಮುಂದಿನ ಅಗತ್ಯವನ್ನು ವ್ಯಕ್ತಪಡಿಸುತ್ತಾನೆ

ಮತ್ತು ಇದು ಎವಲ್ಯೂಷನರಿ( evolutionary) ಬೆಳವಣಿಗೆಗೆ

ಕಾರಣವಾಗುತ್ತದೆ.

ಪ್ರತಿ ಇಟೆರೇಷನ್(iteration)ನಲ್ಲಿ, ಕ್ಲೈಂಟ್(client) ಬದಿಯಲ್ಲಿ

ಪರೀಕ್ಷಿಸಲಾದ, ಇಂಟಿಗ್ರೇಟ್(integrate) ಮಾಡಲಾದ, ಎಕ್ಸಿಕ್ಯೂಟಬಲ್(executable)

ಸಿಸ್ಟಮ್(system) ಅನ್ನು ಕೆಲವು ಕೋಡ್ ನಿಯೋಜಿಸಲಾಗಿದೆ.

ಇಟೆರೇಷನ್(iteration)ನ ಉದ್ದವು ಸಾಮಾನ್ಯವಾಗಿ 2 ರಿಂದ

6 ವಾರಗಳವರೆಗೆ ಚಿಕ್ಕದಾಗಿದೆ.

ಸಾಫ್ಟ್‌ವೇರ್(software) ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ

ಅಭಿವೃದ್ಧಿಪಡಿಸಲು 10 ರಿಂದ 15 ಇಟೆರೇಷನ್(iteration)ಗಳ

ನಡುವೆ ಎಲ್ಲೋ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.

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

ಮತ್ತು ಫ್ರೀಜ್(freeze) ಮಾಡಲಾಗುವುದಿಲ್ಲ

ಮತ್ತು ನಂತರ ಯಾವುದೇ ಭವಿಷ್ಯದ ಬದಲಾವಣೆಗಳನ್ನು

ಸರಿಹೊಂದಿಸಲು ಸಂಪ್ರದಾಯವಾದಿಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ

ಎಂದು ನಾವು ಹಲವಾರು ಬಾರಿ ಒತ್ತಿಹೇಳಿದ್ದೇವೆ.

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

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

ಎಲ್ಲಾ ಸಕ್ಸಿವ್(successive) ವರ್ಷನ್(version)ಗಳು ಸಂಪೂರ್ಣ

ಫಂಕ್ಷನಲ್ ಸಿಸ್ಟಮ್(functional system) ಗಳಾಗಿವೆ.

ಗ್ರಾಹಕರು ಅವುಗಳನ್ನು ರಿಯಲ್(real) ಕೆಲಸದಲ್ಲಿ

ಬಳಸಿಕೊಳ್ಳಬಹುದು.

ಹೊಸ ಬಿಡುಗಡೆಯನ್ನು ಮಾಡಿದಾಗ ಹೊಸ ಫಂಕ್ಷನ್(function)

ಅನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ.

ಆದರೆ ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯ ಆಧಾರದ ಮೇಲೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ

ಕೆಲವು ಫಂಕ್ಷನ್(function)ಗಳನ್ನು ಬದಲಾಯಿಸಿರಬಹುದು

ಅಥವಾ ಹೆಚ್ಚಿಸಿರಬಹುದು.

ಈ ಸ್ಕೀಮ್ಯಾಟಿಕ್‌(schematic)ನಲ್ಲಿ ನಾವು ಮಾಡಲ್(model)ನ್ನು

ಪ್ರತಿನಿಧಿಸಬಹುದು: ಆರಂಭದಲ್ಲಿ, ಸಿಸ್ಟಮ್‌(system)ನ

ಕೆಲವು ರಫ್(rough) ತಿಳುವಳಿಕೆಯನ್ನು ಮಾಡಲಾಗುತ್ತದೆ, ಇದು

ಇನ್ಕ್ರೀಮೆಂಟಲ್ ಮಾಡಲ್(incremental model) ಗಿಂತ ಭಿನ್ನವಾಗಿ

ಸಿಸ್ಟಮ್‌(system)ನ ಸಂಪೂರ್ಣ ವಿವರಣೆಯಲ್ಲ.

ಇಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಒವೆರಾಲ್ ಫೀಚರ್(overall

feature) ಮತ್ತು ನಂತರ ಕೋರ್(core), ಮತ್ತು ಪ್ರತಿ ಇಟೆರೇಷನ್(iteration)ನ್ನು

ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಇಟೆರೇಷನ್(iteration)ನಲ್ಲಿ, ಸ್ಪೆಸಿಫಿಕೇಷನ್ ಡೆವಲಪ್ಮೆಂಟ್(specification

development), ವ್ಯಾಲಿಡೇಷನ್(validation) , ಮತ್ತು ನಂತರ ಅಂತಿಮವಾಗಿ,

ಡಿಪ್ಲೋಯ್ಮೆಂಟ್ (deployment) ಇರುತ್ತದೆ.

ಕೋರ್ ಅನ್ನು ಡಿಪ್ಲೋಯ್ಮೆಂಟ್ (deployment) ಮಾಡಲಾಗಿದೆ ಮತ್ತು

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

ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ.

ಮತ್ತೆ, ಇಟೆರೇಷನ್(iteration) ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು

ಎಲ್ಲಾಸಕ್ಸಿವ್(successive) ವರ್ಷನ್(version)ಗಳನ್ನು

ಗ್ರಾಹಕ ಸೈಟ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ; ಗ್ರಾಹಕ

ಸೈಟ್‌ನಲ್ಲಿ ಅಂತಿಮ ವರ್ಷನ್(version)ನ್ನು ನಿಯೋಜಿಸುವವರೆಗೆ

ಇಟೆರೇಷನ್(iteration)ಗಳು ಮುಂದುವರೆದಂತೆ ಪಡೆದ

ಪ್ರತಿಕ್ರಿಯೆಯು ಮುಂದುವರಿಯುತ್ತದೆ.

ಈ ಎವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(evolutionary model)ಗೆ ಅನೇಕ ಪ್ರಯೋಜನಗಳಿವೆ.

ಒಂದು ಅನುಕೂಲವೆಂದರೆ ಬಳಕೆದಾರರು ಪ್ರಯೋಗ

ಮಾಡಬಹುದು, ಅವರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಬಹುದು; ಅವರು ಸಾಫ್ಟ್‌ವೇರ್

ಅನ್ನು ಸಹ ಬಳಸಬಹುದು.

ಆದ್ದರಿಂದ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

ಎಂಬುದರ ನಿಜವಾದ ಭಾವನೆಯನ್ನು ಅವರು ಪಡೆಯುತ್ತಾರೆ

ಮತ್ತು ಆದ್ದರಿಂದ, ಇದು ನಿಖರವಾದ ಬಳಕೆದಾರರ

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

ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಅದನ್ನು

ಗ್ರಾಹಕರ ಸೈಟ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಿದಾಗ ನಿಖರವಾದ

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

ಮತ್ತು, ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಗ್ರಾಹಕರ ಸೈಟ್‌(site)ನಲ್ಲಿ

ನಿಯೋಜಿಸಲಾಗಿರುವುದರಿಂದ ಮತ್ತು ಬಳಸುವುದರಿಂದ,

ಯಾವುದೇ ಡಿಫೆಕ್ಟ್(defect)ಗಳನ್ನೂ ಗಮನಿಸಲಾಗುತ್ತದೆ

ಮತ್ತು ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ.

ಆದ್ದರಿಂದ, ಕೋರ್(core) ಮಾಡ್ಯೂಲ್ಗಳನ್ನು

ದೀರ್ಘಕಾಲದವರೆಗೆ ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು

ಎಲ್ಲಾ ಡಿಫೆಕ್ಟ್(defect)ಗಳನ್ನೂ ಕಂಡುಹಿಡಿಯಬೇಕು.

ಮತ್ತು ಆದ್ದರಿಂದ, ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(waterfall

model)ನಲ್ಲಿ ಇರುವುದಕ್ಕಿಂತ ಅಂತಿಮ ಡೆಲಿವರ್(deliver)

ಮಾಡಲಾದ ಸಾಫ್ಟ್‌ವೇರ್(software) ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ.

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(evolutionary model) ನಲ್ಲಿ, ಡೆವೆಲಪರ್(developer)ಗಳು

ಕೇವಲ ಒಂದು ಅಥವಾ ಎರಡು ಫೀಚರ್(feature)ಗಳನ್ನು

ಕೇಂದ್ರೀಕರಿಸಿದ್ದಾರೆ.

ಆದ್ದರಿಂದ, ಕಾಂಪ್ಲೆಕ್ಸಿಟಿ(complexity) ಯನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು.

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

ಮತ್ತು ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ.

ಯಾವುದೇ ದೀರ್ಘಾವಧಿಯ ಯೋಜನೆಗಳನ್ನು ಮಾಡಲಾಗಿಲ್ಲ

ಮತ್ತು ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(waterfall model) ಗಿಂತ

ಭಿನ್ನವಾಗಿ ಬದಲಾಗುವ ಅವಶ್ಯಕತೆಗಳನ್ನು

ಸುಲಭವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದಾದ ಪ್ರದೇಶವಾಗಿದೆ.

ಗ್ರಾಹಕರು ಸಾಫ್ಟ್‌ವೇರ್(software) ಅನ್ನು ನಿಯೋಜಿಸುತ್ತಾರೆ

ಮತ್ತು ಹೆಚ್ಚೆಚ್ಚು ಕಲಿಯಬಹುದು ಮತ್ತು

ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಲು ಕಷ್ಟಕರವಾದ

ಯಾವುದೇ ಭಾಗವನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು.

ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ ಮತ್ತು

ಹೆಚ್ಚು ಬಳಸಬಹುದಾಗಿದೆ.

ಫ್ರಿಕ್ಯುನ್ಟ್(Frequent) ರಿಲೀಸ್(release)ಗಳು ಡೆವಲಪರ್‌(developer)ಗಳು

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

ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ ಏಕೆಂದರೆ ಅವರು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿದ್ದಾರೆ

ಮತ್ತು ಸಂಭವಿಸುವ ಯಾವುದೇ ಸಮಸ್ಯೆಯು ಸಮಸ್ಯೆಗಳನ್ನು

ತ್ವರಿತವಾಗಿ ಸರಿಪಡಿಸಲು ಏನನ್ನಾದರೂ ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು.

ಆದರೆ ನಂತರ, ಎವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(evolutionary model) ಕೆಲವು

ಸಮಸ್ಯೆಗಳನ್ನು ಅಥವಾ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ.

ನಾವು ವಿವರಿಸಿದಂತೆ ಸಾಹಿತ್ಯದಲ್ಲಿ ವಿವರಿಸಿದ

ಪ್ರಕ್ರಿಯೆಯು ಅಸ್ಪಷ್ಟವಾಗಿದೆ.

ಮತ್ತು ಆದ್ದರಿಂದ, ಪ್ರಕ್ರಿಯೆಯು ಅಮೂರ್ತವಾಗಿದೆ.

ಪ್ರಕ್ರಿಯೆಯು ನಿಯಮಿತವಾಗಿಲ್ಲ, ಸರಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ;

ಪ್ರಕ್ರಿಯೆಯು ಅನಿರೀಕ್ಷಿತವಾಗಿದೆ.

ಯಾವುದೇ ದೀರ್ಘಾವಧಿಯ ಯೋಜನೆಗಳನ್ನು ಮಾಡದ

ಕಾರಣ, ನಾವು ಇಟರೇಷನ್(iteration)ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ

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

ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿಲ್ಲ.

ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಎಷ್ಟು

ಇಟರೇಷನ್(iteration)ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ

ಎಂದು ನಮಗೆ ತಿಳಿದಿಲ್ಲ.

ಇದು 3 ತಿಂಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳಬಹುದು; ಇದು 6 ತಿಂಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳಬಹುದು.

ಆದ್ದರಿಂದ, ನಿಯಂತ್ರಣವು ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ.

ಮೊದಲಿನಿಂದಲೂ ಇದು ಎಷ್ಟು ಪುನರಾವರ್ತನೆಗಳನ್ನು

ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಊಹಿಸಲು ಕಷ್ಟ,

ಉದ್ಯೋಗಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಕಷ್ಟ, ಎಷ್ಟು ಜನರು

ಕೆಲಸ ಮಾಡುತ್ತಾರೆ, ಎಷ್ಟು ದಿನ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ,

ಒಟ್ಟು ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕುವುದು ಕಷ್ಟ

ಇಲ್ಲಿ ಇನ್ನೊಂದು ಪ್ರಮುಖ ತೊಂದರೆ ಏನೆಂದರೆ ಸಾಫ್ಟ್‌ವೇರ್(software)

ಬದಲಾಗುತ್ತಲೇ ಇರುತ್ತದೆ.

ಆದ್ದರಿಂದ, ಸಾಫ್ಟ್‌ವೇರ್(software)ಗೆ ನಿರಂತರ ಬದಲಾವಣೆಗಳು

ಸಾಫ್ಟ್‌ವೇರ್(software) ವಿನ್ಯಾಸವನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ

ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು

ನೀಡುವುದು, ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮಾರ್ಪಡಿಸುವುದು ಇತ್ಯಾದಿಗಳನ್ನು

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

ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, ಸಿಸ್ಟಮ್(system) ಅಂತಿಮ

ಪರಿಹಾರಕ್ಕೆ ಒಮ್ಮುಖವಾಗದಿರಬಹುದು ಮತ್ತು ಯೋಜನೆಯು ಪೂರ್ಣಗೊಳ್ಳದಿರಬಹುದು.

ಈಗ, ನಾವು RAD ಮಾಡಲ್(model)ನ ಬಗ್ಗೆ ಚರ್ಚಿಸುತ್ತೇವೆ.

RAD ಮಾಡಲ್(model)ನ ರಾಪಿಡ್(Rapid) ಅಪ್ಲಿಕೇಶನ್(application)

ಅಭಿವೃದ್ಧಿ ಮಾಡಲ್(model)ನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.

ಇದೂ ಕೂಡ ಜನಪ್ರಿಯ ಮಾಡಲ್(model); ಇದನ್ನು

ರಾಪಿಡ್ ಪ್ರೊಟೊಟೈಪಿಂಗ್(Rapid prototyping) ಮಾಡಲ್(model) ಎಂದು

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

ಇಲ್ಲಿ ರಾಪಿಡ್(Rapid) ಎಂಬ ಹೆಸರು ಸೂಚಿಸುವಂತೆ,

ಅಭಿವೃದ್ಧಿಯ ಸಮಯ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ

ಮಾಡಲು ಇಲ್ಲಿ ಒತ್ತು ನೀಡಲಾಗಿದೆ ಮತ್ತು

ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಬದಲಾವಣೆಗಳಿಗೆ ಅವಕಾಶ

ಕಲ್ಪಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ಕೇವಲ ಶಾರ್ಟ್ ಟರ್ಮ್ ಪ್ಲಾನ್(short-term

plan)ಗಳನ್ನು ಮಾತ್ರ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ

ಕಸ್ಟಮೈಸೇಶನ್(customization) ಯೋಜನೆಗಳಾಗಿರುವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ

ಕೋಡ್‌(code)ನ ಭಾರೀ ಮರುಬಳಕೆಯಾಗಿದೆ.

RAD ಮಾಡಲ್(model) ಇನ್‌ಕ್ರಿಮೆಂಟಲ್ ಡೆವಲಪ್‌ಮೆಂಟ್(incremental

development) ವಿಧಾನವನ್ನು ಸಹ ಪಾಲಿಸುತ್ತದೆ,

ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಕೇವಲ ಒಂದು ಇನ್‌ಕ್ರಿಮೆಂಟ್(increment)

ಅನ್ನು ಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಒಂದು ಇಟರೇಷನ್(iteration)

ಮೇಲೆ ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.

ಮತ್ತು ಇಟರೇಷನ್(iteration) ಯನ್ನು ಇಲ್ಲಿ ಟೈಮ್

ಬಾಕ್ಸ್(time box) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಇಟರೇಷನ್(iteration) ಅಥವಾ ಇನ್‌ಕ್ರಿಮೆಂಟ್(increment)

ಅಪ್ಲಿಕೇಶನ್‌(application)ನ ಫಂಕ್ಷನಾಲಿಟಿ(functionality)

ಅನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಇನ್ಕ್ರೀಮೆಂಟಲ್ ಮತ್ತು ಎವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(incremental

and the evolutionary model) ಗಿಂತ ಭಿನ್ನವಾಗಿ, ರಾಪಿಡ್(rapid) ಅಭಿವೃದ್ಧಿ

ಮಾಡಲ್(model)ನಲ್ಲಿ ಗಮನವು ಯಾವುದನ್ನಾದರೂ ವೇಗವಾಗಿ

ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು.

ಆದ್ದರಿಂದ, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲು ಗ್ರಾಹಕರ ಸೈಟ್‌ನಲ್ಲಿ

ತ್ವರಿತ ಮತ್ತು ಡರ್ಟಿ ಪ್ರೊಟೋಟೈಪ್(prototype)ನ್ನು

ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ನಿಯೋಜಿಸಲಾಗಿದೆ

ಮತ್ತು ಗ್ರಾಹಕರು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುವಂತೆ, ಈ ಪ್ರೊಟೋಟೈಪ್(prototype)

ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯ ಆಧಾರದ ಮೇಲೆ ಪರಿಷ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಆದ್ದರಿಂದ, ಇದು RAD ಅಭಿವೃದ್ಧಿಯಿಂದ ಪ್ರತಿಪಾದಿಸಲ್ಪಟ್ಟ

ವಿಭಿನ್ನ ಶೈಲಿಯಾಗಿದೆ.

ಕ್ಷಿಪ್ರ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ಪ್ರೊಟೋಟೈಪ್(prototype)ನ್ನು

ನಿಜವಾದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

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

ಎಸೆಯುವ ಸಾಫ್ಟ್‌ವೇರ್(software) ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ.

ಮತ್ತು ಸಹಜವಾಗಿ, ಇನ್ಕ್ರೀಮೆಂಟಲ್ ಮತ್ತು ಎವೊಲ್ಯೂಷನರಿ

ಮಾಡಲ್(incremental and the evolutionary model), ಪ್ರತಿ ಏರಿಕೆಯು

ಪ್ರೊಟೋಟೈಪ್(prototype) ಆಗಿರಲಿಲ್ಲ, ಆದರೆ

ಕೆಲವು ಲೈಫ್ ಸೈಕಲ್(lifecycle)ನ ಪ್ರಕಾರ ಸರಿಯಾಗಿ ಯೋಜಿಸಲಾದ

ವಾಟರ್ಫಾಲ್(waterfall) ಮಾಡಲ್(model) ಆಗಿರಬಹುದು.

ವೇಗವಾದ ಅಭಿವೃದ್ಧಿಗೆ ಅನುಕೂಲವಾಗುವಂತೆ

RAD ಯ ಒತ್ತು ನೀಡುವುದರಿಂದ, ಇದು ವಿಶೇಷ ಸಾಧನಗಳನ್ನು

ಬಳಸಿಕೊಂಡು ಪ್ರೊಟೋಟೈಪ್(prototype) ಅನ್ನು ರಚಿಸುತ್ತದೆ

ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ದೃಶ್ಯ ಶೈಲಿ, ಡ್ರ್ಯಾಗ್(drag)

ಮತ್ತು ಡ್ರಾಪ್(drop) ಶೈಲಿ, ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ

ಕಂಪೋನೆಂಟ್(component)ಗಳ ಬಳಕೆ ಮತ್ತು ಸ್ಟ್ಯಾಂಡರ್ಡ್(standard)

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

ಸ್ಟ್ಯಾಂಡರ್ಡ್(standard) API ಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ

ಏಕೆಂದರೆ ಅದು ಮರುಬಳಕೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

RAD ಮಾದರಿಯು ಒಂದು ಅಥವಾ ಎರಡು ಗ್ರಾಹಕರಿಗೆ

ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ಸಾಫ್ಟ್ವೇರ್(software)ಗೆ

ಸೂಕ್ತವಾಗಿದೆ.

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

ಕಾರಣ, ಕೋಡ್(code) ಗುಣಮಟ್ಟವು ತುಂಬಾ ಉತ್ತಮವಾಗಿಲ್ಲ.

ಪ್ರಾಜೆಕ್ಟ್(project)ನ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಮತ್ತು

ರಿಲಿಎಬಿಲಿಟಿ(performance and reliability) ಪ್ರೀಮಿಯಂ(premium)

ಮಟ್ಟದಲ್ಲಿಲ್ಲ ಮತ್ತು ತುಂಬಾ ಚಿಕ್ಕ ಸಾಫ್ಟ್ವೇರ್(software)ಗೆ

ಸಹ ಸೂಕ್ತವಲ್ಲ.

ಸಾಫ್ಟ್ವೇರ್(software) ಹಲವಾರು ಸ್ವತಂತ್ರ ಮಾಡ್ಯೂಲ್ಗಳಾಗಿ

ವಿಭಜಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಮತ್ತು, ನಾವು ನಿಜವಾಗಿಯೂ ಕೆಲಸ ಮಾಡಲು RAD ಮಾಡಲ್(model)

ಅನ್ನು ಬಯಸಿದರೆ, ನಾವು ಅನೇಕ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ

ಕಂಪೋನೆಂಟ್(component)ಗಳನ್ನು ಹೊಂದಿರಬೇಕು.

ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಸಾಫ್ಟ್‌ವೇರ್(software)

ಲಭ್ಯವಿಲ್ಲದ ಹೊಸ ಉತ್ಪನ್ನಕ್ಕಾಗಿ, RAD ಮಾಡಲ್(model) ರನ್(run)

ಆಗುವುದಿಲ್ಲ.

ನಮಗೆ ಹೆಚ್ಚಿನ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಮತ್ತು ರಿಲಿಎಬಿಲಿಟಿ(performance

and reliability) ಅಗತ್ಯವಿದ್ದರೆ, RAD ಮಾಡಲ್(model) ಸೂಕ್ತವಲ್ಲ.

ಸಾಫ್ಟ್‌ವೇರ್(software) ಸಮಂಜಸವಾಗಿ ದೊಡ್ಡದಾಗಿದ್ದರೆ

ಮತ್ತು ಹಲವಾರು ಮಾಡ್ಯೂಲ್‌(module)ಗಳಾಗಿ ಮಾಡ್ಯುಲೈಸ್(modulise) ಮಾಡಬಹುದಾದಾಗ

RAD ಮಾಡಲ್(model) ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ.

RAD ಮಾಡಲ್(model) ಯೊಂದಿಗೆ ಪ್ರೊಟೋಟೈಪ್(prototype)

ಅನ್ನು ಹೋಲಿಸುವುದು ಸುಲಭ.

ಪ್ರೊಟೋಟೈಪ್(prototype) ಮಾಡಲ್(model) ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ

ಪ್ರೊಟೋಟೈಪ್(prototype) ಥ್ರೋಅವೇ(throwaway) ಪ್ರೊಟೋಟೈಪ್(prototype)

ಆಗಿದೆ.

ಪ್ರೊಟೋಟೈಪ್(prototype) ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು

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

ಮತ್ತು ಪರಿಹಾರದ ಒಳನೋಟವನ್ನು ಪಡೆಯುವುದು.

ಪ್ರೊಟೋಟೈಪ್(prototype) ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ

ಮೂಲಕ ಡೆವಲಪರ್‌(developer)ಗಳು ಪರ್ಯಾಯಗಳ ನಡುವೆ ಆಯ್ಕೆ

ಮಾಡಬಹುದು.

ಪರ್ಯಾಯಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಪ್ರೊಟೋಟೈಪ್(prototype)

ಅನ್ನು ಬಳಸಿದ ನಂತರ, ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆ

ಅನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಪ್ರೊಟೋಟೈಪ್(prototype)

ಅನ್ನು ಎಸೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಸಂಪೂರ್ಣ

ಯೋಜಿತ ಅಭಿವೃದ್ಧಿ ಪುನರಾವರ್ತನೆಯ ವಾಟರ್ಫಾಲ್(waterfall)

ಮಾಡಲ್(model) ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, RAD ಮಾಡಲ್(model) ನಲ್ಲಿ

ಪ್ರೊಟೋಟೈಪ್(prototype) ಅನ್ನು ಸ್ವತಃ ವಿತರಿಸಬಹುದಾದ

ಸಾಫ್ಟ್‌ವೇರ್(software) ಆಗಿ ಮಾರ್ಪಡಿಸಲಾಗಿದೆ.

ಸಹಜವಾಗಿ, ಇದು ವೇಗವಾದ ಅಭಿವೃದ್ಧಿಯ RAD ಯ ಅವಶ್ಯಕತೆ

ಅಥವಾ ಉದ್ದೇಶದೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ,

ಆದರೆ ಕ್ವಾಲಿಟಿ ಮತ್ತು ರಿಲಿಯಬಿಲಿಟಿ(quality

and reliability) ಪ್ರಶ್ನೆಯಾಗುತ್ತದೆ.

ಆದರೆ ಇಟರೇಟಿವ್ ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(Iterative waterfall model)

ಯೊಂದಿಗೆ RAD ಹೇಗೆ ಹೋಲಿಸುತ್ತದೆ?

ಇಟರೇಟಿವ್ ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(Iterative waterfall model),

ಆರಂಭದಲ್ಲಿ ಎಲ್ಲಾ ಅಗತ್ಯತೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯಲಾಗುತ್ತದೆ

ಮತ್ತು ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತದೆ,

ಆದರೆ RAD ಮಾಡಲ್(model) ನಲ್ಲಿ ಇವುಗಳನ್ನು ಹೆಚ್ಚೆಚ್ಚು

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

ಆದ್ದರಿಂದ, ಇದು ಇನ್ಕ್ರೀಮೆಂಟಲ್ ಡೆವಲಪ್ಮೆಂಟ್ ಮಾಡಲ್

(incremental development model) ಯೊಂದಿಗೆ ಹೋಲಿಕೆಯನ್ನು ಹೊಂದಿದೆ

ಮತ್ತು ಪ್ರತಿ ಇಟರೇಟಿವ್(iterative)ನ ಮೇಲೆ ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು

ಪಡೆಯಲಾಗುತ್ತದೆ.

ಆದ್ದರಿಂದ RAD ಮಾಡಲ್(model) ನಲ್ಲಿ, ಕ್ಲೈಂಟ್(client)

ಇಂಟರ್ಆಕ್ಷನ್(interaction)ಗಳು ಅಥವಾ ಗ್ರಾಹಕರ ಇಂಟರ್ಆಕ್ಷನ್(interaction)ಗಳು

ಇಟರೇಟಿವ್ ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(iterative waterfall model)ಗೆ

ಹೋಲಿಸಿದರೆ ಹೆಚ್ಚು.

ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಯ ಆಧಾರದ ಮೇಲೆ ಅಗತ್ಯ

ಬದಲಾವಣೆಗಳಿಗೆ ಅವಕಾಶ ಕಲ್ಪಿಸುವುದು ಸುಲಭ.

ಆದರೆ ನಂತರ, RAD ಮಾಡಲ್(model)ಗೆ ಹೋಲಿಸಿದರೆ, ಇಟರೇಟಿವ್

ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(Iterative waterfall model) ಸಾಮಾನ್ಯವಾಗಿ

ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಡಿಸೈನ್(design), ಹೆಚ್ಚಿನ ರಿಲಿಎಬಿಲಿಟಿ(reliability)

ಮತ್ತು ಉತ್ತಮ ದಾಖಲಾತಿಗಳ ಉತ್ಪಾದನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(evolutionary model) ಯೊಂದಿಗೆ RAD ಮಾಡಲ್(model)

ಹೇಗೆ ಹೋಲಿಸುತ್ತದೆ?

RAD ಮತ್ತು ಎವೊಲ್ಯೂಷನರಿ(evolutionary) ಏರಿಕೆಗಳೆರಡರಲ್ಲೂ

ಅಭಿವೃದ್ಧಿಯು ಹಲವಾರು ಏರಿಕೆಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ.

RAD ನಲ್ಲಿ ಹೆಚ್ಚಳವು ತ್ವರಿತ ಮತ್ತು ಡರ್ಟಿ(dirty)

ಪ್ರೊಟೋಟೈಪ್(prototype) ಆಗಿದೆ.

ಮತ್ತೊಂದೆಡೆ, ಎವೊಲ್ಯೂಷನರಿ(evolutionary) ಮಾಡಲ್(model) ನಲ್ಲಿ ಪ್ರತಿ

ಹೆಚ್ಚಳವನ್ನು ಇಟರೇಟಿವ್ ವಾಟರ್ಫಾಲ್ ಮಾಡಲ್(Iterative

waterfall model) ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ.

ಮತ್ತು ನಾವು ಇನ್ಕ್ರಿಮೆಂಟ್(increment)ನ ಸೈಜ್(size) ಅನ್ನು ನೋಡಿದರೆ,

RAD ಹೆಚ್ಚಳವು ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಟೈಮ್ ಬಾಕ್ಸ್(time

box) ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಮತ್ತೊಂದೆಡೆ,

ಎವೊಲ್ಯೂಷನರಿ ಮಾಡಲ್(evolutionary model) ನಲ್ಲಿ ಪ್ರತಿ ಇನ್ಕ್ರಿಮೆಂಟ್(increment)

ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇಟರೇಟಿವ್(iterative)

ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಈಗ, ಮತ್ತೊಂದು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಕ್ರಿಯೆ

ಆದ ಯುನಿಫೈಡ್(unified) ಪ್ರಕ್ರಿಯೆ ಅನ್ನು ನೋಡೋಣ.

ಯುನಿಫೈಡ್(Unified) ಪ್ರಕ್ರಿಯೆಯನ್ನು ಜಾಕೋಬ್ಸನ್, ಬೂಚ್

ಮತ್ತು ರುಂಬಾಗ್ (Jacobson, Booch and Rumbaugh)ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ.

ಆಬ್ಜೆಕ್ಟ್ ಓರಿಎಂಟೆಡ್ ಸಾಫ್ಟ್‌ವೇರ್(object-oriented

software) ಅಭಿವೃದ್ಧಿಗಾಗಿ ಇದನ್ನು ವ್ಯಾಪಕವಾಗಿ

ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಹೆಚ್ಚುತ್ತಿರುವ

ಮತ್ತು ಇಟರೇಟಿವ್(iterative) ಆಗಿದೆ.

ಆದ್ದರಿಂದ, ಇನ್ಕ್ರಿಮೆಂಟಲ್(incremental) ಮತ್ತು ಇಟರೇಟಿವ್(iterative)

ಪದದಿಂದ ಇಲ್ಲಿ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮೊದಲೇ ಗುರುತಿಸಬೇಕಾಗಿತ್ತು.

ತದನಂತರ, ಹಲವಾರು ಇಟರೇಟಿವ್(iterative) ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ

ಸಾಫ್ಟ್‌ವೇರ್(software) ಅನ್ನು ಕ್ಲೈಂಟ್-ಸೈಡ್‌ನಲ್ಲಿ

ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು

ಪಡೆಯಲಾಗುತ್ತದೆ.

ರೇಷನಲ್ ಕಾರ್ಪೊರೇಷನ್(rational corporation) ವಿನ್ಯಾಸಗೊಳಿಸಿದ

ರೇಷನಲ್ ಕಾರ್ಪೊರೇಷನ್(rational corporation) ಪ್ರಕ್ರಿಯೆಯನ್ನು

ಯುನಿಫೈಡ್(Unified) ಪ್ರೋಸಸ್(process) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ

ಮತ್ತು ರೇಷನಲ್ ಕಾರ್ಪೊರೇಷನ್(rational corporation) ಅನ್ನು 2003 ರಲ್ಲಿ

IBM ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡಿತು.

ಯುನಿಫೈಡ್(unified) ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಇಲ್ಲಿ ಅಭಿವೃದ್ಧಿಯು

4 ಹಂತಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ: ಇನ್ಸೆಪ್ಷನ್ , ಎಲ್ಯಾಬೋರೇಷನ್,

ಕನ್ಸ್ಟ್ರಕ್ಷನ್ ಮತ್ತು ಟ್ರಾನ್ಸಿಷನ್(Inception,

Elaboration, Construction and Transition).

ಈ ಪ್ರತಿಯೊಂದು ಹಂತಗಳಲ್ಲಿ, ಅನೇಕ ಏರಿಕೆಗಳನ್ನು

ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಇನ್ಸೆಪ್ಷನ್(inception) ಫೇಸ್(phase) ಅನೇಕ ಏರಿಕೆಗಳು

ಅಥವಾ ಇಟೆರೇಷನ್(iteration)ಗಳ ಮೇಲೆ ಸಂಭವಿಸುತ್ತದೆ.

ವಿವರಣೆಯಲ್ಲಿಯೂ ಅನೇಕ ಇಟೆರೇಷನ್(iteration)ಗಳು

ಇರಬಹುದು; ನಿರ್ಮಾಣದಲ್ಲಿ ಹಲವಾರು ಇಟೆರೇಷನ್(iteration)ಗಳು

ಇವೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಇಟೆರೇಷನ್(iteration).

ಎಲ್ಲಾ ಫೇಸ್(phase)ಗಳು ಏನನ್ನು ಸೂಚಿಸುತ್ತವೆ

ಎಂಬುದನ್ನು ಈಗ ನಾವು ನೋಡುತ್ತೇವೆ.

ಪ್ರಾರಂಭದ ಹಂತದಲ್ಲಿ, ಗ್ರಾಹಕರೊಂದಿಗೆ ಕಮ್ಯುನಿಕೇಷನ್(communication)

ಅನ್ನು ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಫೀಚರ್(feature)ಗಳನ್ನು

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

ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ಯೋಜಿಸಲಾಗುತ್ತದೆ.

ಎಲೆಬೊರೇಷನ್(elaboration) ಸಮಯದಲ್ಲಿ, ಗುರುತಿಸಲಾದ

ಫೀಚರ್ ಗಳನ್ನು ಮಾಡಲ್(model) ಆಗಿ ಮಾಡಲಾಗುತ್ತದೆ.

ಮತ್ತು ಅಂತಿಮವಾಗಿ, ನಿರ್ಮಾಣ ಹಂತದಲ್ಲಿ

ಸಾಫ್ಟ್‌ವೇರ್(software) ಅನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ

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

ಮತ್ತು ಟ್ರಾನ್ಸಿಷನ್(Transition) ಸಮಯದಲ್ಲಿ, ಸಾಫ್ಟ್‌ವೇರ್(software)

ಅನ್ನು ಕ್ಲೈಂಟ್(client) ಬದಿಯಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ.

ಈ ಹಂತದಲ್ಲಿ ಇದು ಸರಳವಾಗಿ ಕಾಣಿಸಬಹುದು ಆದರೆ

ಇವೆಲ್ಲವೂ ಅಷ್ಟು ಸರಳವಲ್ಲ.

ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಹೆಚ್ಚು ಸರಳವಾದ ಮಾಡಲ್(model)

ನಿಖರವಾಗಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ.

ಈಗ, ಪ್ರತಿ ಹಂತದ ಔಟ್‌ಪುಟ್ ಏನೆಂದು ನೋಡೋಣ?

ಪ್ರಾರಂಭದ ಹಂತದಲ್ಲಿ, ಆರಂಭಿಕ ಬಳಕೆಯ ಮಾಡಲ್(model)

ಫೀಚರ್(feature)ಗಳು, ವ್ಯವಹಾರ ಕೇಸ್(case) , ರಿಸ್ಕ್ ಲಿಸ್ಟ್(risk

list) , ಪ್ರಾಜೆಕ್ಟ್ ಪ್ಲಾನ್(project plan) , ಯಾವುದೇ ಪ್ರೊಟೋಟೈಪ್(prototype)

ಇತ್ಯಾದಿಗಳು ಔಟ್‌ಪುಟ್ ಆಗಿ ಬರುತ್ತವೆ.

ಎಲಬೋರೇಷನ್ ಹಂತದಲ್ಲಿ, ವಿಶ್ಲೇಷಣಾ ಮಾಡಲ್(madal),

ಪ್ರಾಥಮಿಕ ಮಾಡಲ್(madal), ಹಸ್ತಚಾಲಿತ ಬಳಕೆಯ

ಪ್ರಕರಣ ಮಾಡಲ್(madal) ಇತ್ಯಾದಿಗಳು ಔಟ್‌ಪುಟ್(output)

ಆಗಿ ಬರುತ್ತವೆ.

ನಿರ್ಮಾಣ ಹಂತ, ಸಾಫ್ಟ್‌ವೇರ್(software) ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ,

ಪರೀಕ್ಷಾ ಯೋಜನೆಯನ್ನು ಮಾಡಲಾಗಿದೆ, ಬಳಕೆದಾರರ

ಯೂಸರ್ ಮ್ಯಾನುಯಲ್(user manual) ಮತ್ತು ಅನುಸ್ಥಾಪನಾ

ಕೈಪಿಡಿಯನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ,

ಇವುಗಳನ್ನು ಗ್ರಾಹಕರ ಸೈಟ್‌(site)ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.

ನಿರ್ಮಾಣ ಹಂತದಲ್ಲಿ ಬೀಟಾ ಟೆಸ್ಟ್ ರಿಪೋರ್ಟ್(test

report)ಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು

ಸಹ ಪಡೆಯಲಾಗುತ್ತದೆ.

ಆದರೆ ನಾವು ಇದನ್ನು ದೃಶ್ಯೀಕರಿಸಲು ಬಯಸಿದರೆ

ಅದು ರೇಷನಲ್ ಯುನಿಫೈಡ್(rational unified) ಪ್ರಕ್ರಿಯೆಯ ಹೆಚ್ಚು

ವಾಸ್ತವಿಕ ಚಿತ್ರವನ್ನು ತೋರಿಸುತ್ತದೆ.

ಹಾರಿಜಾಂಟಲ್ ಆಕ್ಸಿಸ್(horizontal axis), ಲೈಫ್ ಸೈಕಲ್(lifecycle)

ಅನ್ನೋದು ಅಂಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು

ವರ್ಟಿಕಲ್ ಆಕ್ಸಿಸ್(vertical axis) ಅನ್ನೋದು ಕೋರ್(core)

ಪ್ರಕ್ರಿಯೆಯ ಫ್ಲೋ(flow) ಅನ್ನು ತೋರಿಸುತ್ತದೆ.

ಗ್ರಾಫಿಕಲ್(graphical) ಪ್ರಾತಿನಿಧ್ಯದಿಂದ ನಾವು ನಾಲ್ಕು ಹಂತಗಳನ್ನು

ಇಲ್ಲಿ ಗುರುತಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ

ಹಲವಾರು ಇಟರೇಷನ್(iteration) ಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ

ಎಂದು ನೋಡಬಹುದು ಮತ್ತು ಅವು ಎಲ್ಯಾಬೋರೇಷನ್(elaboration)

ಮತ್ತು ಕನ್ಸ್ಟ್ರಕ್ಷನ್(construction) ಹಂತದಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತವೆ.

ಅನಾಲಿಸಿಸ್(analysis) ಮತ್ತು ಡಿಸೈನ್(design), ಆವು ಎಲ್ಯಾಬೋರೇಷನ್(elaboration)

ಮತ್ತು ಕನ್ಸ್ಟ್ರಕ್ಷನ್(construction)ನ ಸಮಯದಲ್ಲಿ ಪೀಕ್(peak)ಗೆ

ಏರುತ್ತವೆ ಮತ್ತು ನಿಧಾನವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತವೆ

. ಕನ್ಸ್ಟ್ರಕ್ಷನ್(construction) ಹಂತದಲ್ಲಿ ಇಂಪ್ಲೇಮೆಂಟೇಶನ್

(implementation) ಪೀಕ್(peak)ಗೆ ಏರುತ್ತದೆ ಮತ್ತು ಕುಗ್ಗುತ್ತದೆ;

ಆದರೆ ನಂತರ, ಎಲ್ಯಾಬೋರೇಷನ್(elaboration) ಹಂತದಲ್ಲಿ ಕೆಲವು ನಿರ್ಮಾಣಗಳಿವೆ

ಮತ್ತು ಪರೀಕ್ಷೆಯು ಉದ್ದಕ್ಕೂ ಇರುವುದನ್ನು

ನಾವು ನೋಡಬಹುದು ಮತ್ತು ಟ್ರಾನ್ಸಿಷನ್(transition)

ಕಡೆಗೆ ನಿಯೋಜನೆಯು ಪೀಕ್(peak)ಗೆ ಏರುತ್ತದೆ.

ನಾವು ಈ ಉಪನ್ಯಾಸದ ಸಮಯವನ್ನು ಸಮೀಪಿಸುತ್ತಿದ್ದೇವೆ.

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

ಈ ಹಂತದಿಂದ ಮುಂದುವರಿಯುತ್ತೇವೆ.