इंटरनेट-गति विकास
इंटरनेट-स्पीड डेवलपमेंट एक चंचल सॉफ्टवेयर विकास पद्धति है, जिसमें उच्च गति वाले उत्पाद को विकसित करने के उद्देश्य से दैनिक निर्माण के साथ एक संयुक्त सर्पिल मॉडल/झरना मॉडल का उपयोग किया जाता है।
इसे नब्बे के दशक के अंत में विकसित किया गया था क्योंकि सॉफ्टवेयर विकास तेजी से बदल रहा था। कंपनियों को परियोजना के लिए निर्धारित समय के भीतर सही आवश्यकताओं के साथ उत्पादों को वितरित करने में समस्या हो रही थी और इस तरह वे अधिक चुस्त सॉफ्टवेयर विकास विधियों में बदल रहे थे। इब्राहीमसन के पेपर में इवोल्यूशनरी मैप में इंटरनेट-स्पीड पद्धति को कैसे विकसित किया गया था, इसके बारे में अधिक विवरण देखा जा सकता है।[1]
इंटरनेट-गति विकास के पीछे मुख्य विचार
सॉफ्टवेयर इंजीनियरिंग में अक्सर सबसे बड़ी समस्याओं में से एक यह है कि आवश्यकताओं में तेजी से परिवर्तन होता है और इस स्थिति के अनुकूल होने के लिए इंटरनेट-गति विकास पद्धति बनाई गई थी। यह विचार सॉफ्टवेयर इंजीनियरिंग मॉडल में दो मुख्य मानकों को जोड़ने का है, अर्थात् सर्पिल मॉडल और वॉटरफॉल मॉडल को एक नए मॉडल में और इस नए मॉडल पर एक नई सॉफ्टवेयर इंजीनियरिंग पद्धति को आधार बनाना है। जलप्रपात मॉडल का मुख्य नुकसान यह था कि जब आवश्यकताओं में परिवर्तन की बात आती है तो यह बहुत कठोर और बहुत लचीला नहीं था, जबकि सर्पिल मॉडल का नुकसान यह था कि यह बहुत संरचित नहीं था। इंटरनेट-गति विकास के पीछे विचार यह है कि इन मॉडलों के संयोजन के परिणामस्वरूप एक ऐसी विधि होगी जिसमें ये नुकसान नहीं होंगे और यह उन स्थितियों में उपयोग करने के लिए एक बेहतर तरीका है जहां आवश्यकताएं तेजी से बदल सकती हैं, लेकिन परियोजना को एक संरचित तरीके से क्रियान्वित किया जाना है। रास्ता।
विधि का लक्ष्य
इंटरनेट-गति विकास पद्धति का लक्ष्य सॉफ्टवेयर डेवलपर्स को एक संरचित तरीके से एक परियोजना को पूरा करने की अनुमति देना है, लेकिन फिर भी ग्राहक की जरूरतों को पूरा करने में सक्षम होना है। इसका उद्देश्य गहन विकास के माध्यम से कम समय में एक सॉफ्टवेयर उत्पाद प्रदान करना है। विधि पूरी तरह से कार्यान्वित प्रणाली प्रदान करने का एक साधन प्रदान करती है और मील के पत्थर के उपयोग के माध्यम से किसी परियोजना में प्रगति निर्धारित करने के तरीके भी हैं। इस पद्धति के मुख्य संस्करणों में से एक Microsoft द्वारा बनाया गया है और इसे Microsoft समाधान फ्रेमवर्क कहा जाता है।
इंटरनेट-गति विकास पद्धति के पीछे की अवधारणा
पहली अवधारणा जो इंटरनेट की गति के विकास के लिए बहुत महत्वपूर्ण है, एक दृष्टि और कार्यक्षेत्र (परियोजना प्रबंधन) का निर्माण है। इसका मतलब यह है कि परियोजना की शुरुआत में सिस्टम की एक वैश्विक परिभाषा बनाई जाती है जो बताती है कि सिस्टम का लक्ष्य क्या है और दायरे में क्या है और क्या नहीं है। यह मौलिक कदमों में से एक है क्योंकि यह डेवलपर्स को कुछ दिशानिर्देश देता है कि बिना किसी आवश्यकता को रोके सिस्टम क्या होगा। स्कोप को एक लक्ष्यों का विवरण में प्रलेखित किया जा सकता है।
इस पद्धति के भीतर एक और बहुत महत्वपूर्ण अवधारणा स्कोप प्रबंधन है। स्कोप रेंगने से रोकने के लिए स्कोप को पूरे प्रोजेक्ट में प्रबंधित करने की आवश्यकता है जिसके परिणामस्वरूप देरी होती है। दायरा जल्दी निर्धारित किया जाएगा और दायरे में परिवर्तन (जैसे अतिरिक्त सुविधाओं को जोड़ना जो पहले परियोजना के दायरे से बाहर माने जाते थे) का मूल्यांकन किया जाएगा और या तो स्वीकार या अस्वीकार कर दिया जाएगा। दायरे में बदलाव किए जा सकते हैं लेकिन यह हमेशा सुविधाओं, संसाधनों और समय के बीच व्यापार बंद से प्रभावित होगा।
इंटरनेट-गति विकास पद्धति पारंपरिक तरीकों से बहुत अलग है और इसलिए फुर्तीली पद्धति सिद्धांतों का उपयोग करती है। यह आवश्यकताओं के अनुकूलन पर ध्यान केंद्रित करता है और जैसे कि एजाइल सॉफ्टवेयर विकास के मूल सिद्धांतों पर आधारित है।
इंटरनेट-गति विकास भी एक निश्चित रूपरेखा संरचना का उपयोग करने पर ध्यान केंद्रित करता है जिससे उत्पाद बनाया जाता है और विकास की गति को बढ़ाने के लिए उपकरणों पर बहुत अधिक निर्भर करता है।
इंटरनेट की गति के विकास की एक और बुनियादी अवधारणा यह है कि यह छोटी टीमों का उपयोग करने पर भी ध्यान केंद्रित करता है। विचार यह है कि सभी परियोजनाओं को छोटी-छोटी गतिविधियों में विभाजित किया जा सकता है जिन्हें अक्सर समानांतर में किया जा सकता है। छोटी टीमें अक्सर अपने कार्य पर अधिक ध्यान केंद्रित कर सकती हैं और परियोजना के भीतर उत्तरदायित्व निर्धारित करना और प्रगति की निगरानी करना आसान होता है।
इंटरनेट-गति विकास की इस प्रविष्टि में चर्चा की गई अंतिम अवधारणा समानांतर विकास की अवधारणा है। इस अवधारणा का मूल रूप से मतलब है कि सभी सॉफ्टवेयर विकास जितनी बार संभव हो समानांतर में किया जाता है। यह बहुत तेजी से विकास की अनुमति देगा और यह छोटी टीमों को जितना संभव हो सके अपनी सुविधा पर ध्यान केंद्रित करने की अनुमति देगा, जिसका गुणवत्ता पर अच्छा परिणाम है। यह सुनिश्चित करने के लिए कि अंतिम प्रणाली बनाने के लिए छोटी टीमें एक साथ काम करती हैं, हालांकि उनके विकास को अक्सर सिंक्रनाइज़ करने की आवश्यकता होती है। यह दैनिक बिल्ड का उपयोग करके किया जा सकता है जिसका अर्थ है कि सभी डेवलपर दिन के अंत में अपने कोड की जांच करते हैं जिसके बाद एक बिल्ड बनाया जाता है जिसका मूल्यांकन और प्रगति की निगरानी के लिए परीक्षण किया जा सकता है। निर्माण में एक फीचर के पूरा होने के बाद इसे परीक्षण और परिष्कृत करने की आवश्यकता होती है जिसे कभी-कभी सिंक-एंड-स्टेबिलाइज प्रक्रिया कहा जाता है। विकसित सुविधाओं को निर्माण और परीक्षण के साथ सिंक्रनाइज़ किया गया है। इन परीक्षणों के बाद किसी भी बग को ठीक कर दिया जाएगा और फीचर को बेहतर काम करने के लिए परिष्कृत किया जा सकता है (जो स्थिरीकरण भाग है)।
इंटरनेट-गति का विकास चुस्त सिद्धांतों पर आधारित है और इस तरह इसमें चरम कार्यक्रम, तर्कसंगत एकीकृत प्रक्रिया, गतिशील प्रणाली विकास पद्धति और फीचर संचालित विकास के साथ बहुत समानताएं हैं। इंटरनेट की गति का विकास हालांकि इन तरीकों से अलग है क्योंकि इसमें एक अधिक व्यापक जोखिम प्रबंधन योजना भी शामिल है और एक परियोजना के एक बहुत ही महत्वपूर्ण उद्देश्य के रूप में गुणवत्ता है।[2] इंटरनेट-गति विकास का विकास चरण भी खुला स्रोत सॉफ्टवेयर विकास मॉडल के साथ कुछ समानताएं दिखाता है क्योंकि इंटरनेट के माध्यम से संचार और कोड और दस्तावेज़ीकरण को संग्रहीत करने के लिए रिपॉजिटरी के उपयोग के कारण दुनिया भर के कई डेवलपर विकास प्रक्रिया का हिस्सा हो सकते हैं। .
इंटरनेट-गति विकास के चरण
इस पद्धति के पीछे का मॉडल इस तरह दिखता है: File:PhaseModel.jpgचित्रा 1: चरण मॉडल यह मॉडल विधि के पांच बुनियादी चरणों को दर्शाता है। इस प्रविष्टि के निम्नलिखित खंडों में इन चरणों की व्याख्या की जाएगी। चरण हैं: कल्पना करना, योजना बनाना, विकास करना, स्थिर करना और तैनाती करना। इस चक्र के पूरा होने के बाद सिस्टम का एक संस्करण तैयार होता है और एक नया चक्र एक नया संस्करण बनाने के लिए शुरू होता है। चरणों को निम्नलिखित खंडों में समझाया गया है और एक मेटा-मॉडलिंग तकनीक के माध्यम से दिखाया गया है। एक परियोजना के संदर्भ में बहुलताओं और अवधारणाओं के बारे में अधिक जानकारी बाद में समग्र डेटा मॉडल में देखी जा सकती है।
कल्पना चरण
परिकल्पना चरण को निम्नानुसार प्रतिरूपित किया जा सकता है: File:Envisioning.jpgचित्र 2: कल्पना चरण प्रक्रिया/डेटा मॉडल
| Activity | Definition (source) |
|---|---|
| Analyze requirements | During the envisioning phase, business requirements must be identified and analyzed.
“These are refined more rigorously during the planning phase.” (MSF Process model)[3] |
| Define Goals and Constraints | “Envisioning, by creating a high-level view of the project’s goals and constraints.”
(MSF Process model)[3] |
| Form Team | Formation of the core team. |
| Create Vision/scope | “The preparation and delivery of a vision/scope document.”
(MSF Process model)[3] |
| Create Risk assessment | “During the envisioning phase, the team prepares a risk document and presents the top risks.”
(MSF Process model)[3] |
तालिका 1: गतिविधियों की कल्पना करना
परिकल्पना चरण में की गई बुनियादी गतिविधियाँ आवश्यकताओं का विश्लेषण कर रही हैं, परियोजना के लिए टीम का गठन कर रही हैं, जोखिमों का निर्धारण कर रही हैं और परियोजना का दायरा तय कर रही हैं। परियोजना की आवश्यकताओं और लक्ष्यों से एक विजन/स्कोप दस्तावेज़ बनाया जाता है। यह दस्तावेज़ बताता है कि जब उत्पाद वितरित किया जाता है तो उसे क्या होना चाहिए। इसमें उत्पाद की बहुत विस्तृत कार्यप्रणाली शामिल नहीं है।
| Concept | Definition (source) |
|---|---|
| VISION/SCOPE DOCUMENT | “Document defining the Vision and Scope.”
(MSF Process model)[3] |
| VISION | “Visionis an unbounded view of what a solution may be.”
(MSF Process model)[3] |
| SCOPE | “Scope identifies the part(s) of the vision can be accomplished within the project constraints.”
(MSF Process model)[3] |
| RISK ASSESSMENT DOCUMENT | “Standardized document for Risk Assessment”
(MSF Risk Management Discipline)[4] |
| PRIORITIZED RISK LIST | “Detailed risk information including project condition, context, root cause, and the metrics used for prioritization (probability, impact, exposure) are often recorded for each risk in the risk statement form.”
(MSF Risk Management Discipline)[4] |
| RISK PLANNING | “Translation of the prioritized risk list into action plans.”
(MSF Risk Management Discipline)[4] |
| PROJECT STRUCTURE DOCUMENT | “The project structure document includes information on how the team is organized and who plays which roles and has specific responsibilities. The project structure document also clarifies the chain of accountability to the customer and designated points of contact that the project team has with the customer. These can vary depending on the circumstances of the project.”
(MSF Process model)[3] |
| TEAM ORGANIZATION | “Information on how the team is organized.”
(MSF Process model)[3] |
| CONTACT POINTS | “Designated points of contact that the project team has with the customer.”
(MSF Process model)[3] |
| TEAM ROLES | “Definition of who plays which roles and has specific responsibilities.”
(MSF Process model)[3] |
तालिका 2: परिकल्पना चरण में अवधारणाएँ
योजना चरण
चित्र 3: योजना चरण प्रक्रिया/डेटा मॉडल
| Activity | Definition (source) | |
|---|---|---|
| Define Requirements | Early in the planning phase, the team analyzes and documents
requirements in a list or tool. Requirements fall into four broad categories: business requirements, user requirements, operational requirements, and system requirements (those of the solution itself).” (MSF Process model)[3] | |
| Trace Requirements to Features | “As the team moves on to design the solution and create the functional specifications, it is important to maintain traceability between requirements and features. Traceability does not have to be on a one to one basis. Maintaining traceability serves as one way to check the correctness of design and to verify that the design meets the goals and requirements of the solution.”
(MSF Process model[3] | |
| Define Functional Specification | “The team prepares the functional specification.”
(MSF Process model[3] | |
| Create Planning | Estimate Risks | Team creates a risk estimation. |
| Estimate Costs | Team creates a costs estimation. | |
| Create work plans | Team creates work plans. | |
| Create Schedules | Team creates schedules. | |
| Create Design | Create Use-Case Model | “This begins with a systematic analysis of user profiles
(also called “personas”) which describe various types of users and their job functions (operations staff are users too). Much of this is often done during the envisioning phase. These are broken into a series of usage scenarios, where a particular type of user is attempting to complete a type of activity, such as front desk registration in a hotel or administering user passwords for a system administrator. Finally, each usage scenario is broken into a specific sequence of tasks, known as use cases, which the user performs to complete that activity. This is called “story-boarding.”” (MSF Process model[3] |
| Create Conceptual Design | Creation of a conceptual design. | |
| Create Logical Design | Creation of a logical design. | |
| Create Physical Design | Creation of a physical design. | |
| Create Architecture | Creation of the architecture for the product. | |
तालिका 3: गतिविधियों की योजना बनाना नियोजन चरण में आवश्यकताओं से एक कार्यात्मक विनिर्देश बनाया जाता है। चयनित सुविधाओं को इस विनिर्देश में शामिल किया गया है (एक MoSCoW विधि अक्सर सुविधाओं के लिए उपयोग की जाती है ताकि उन्हें अधिक आसानी से प्राथमिकता दी जा सके)। साथ ही, इस चरण में मूल डिजाइन और योजना बनाई जाती है। हालांकि डिजाइन इस चरण में स्थिर नहीं है क्योंकि विकास के चरण में बदलाव किए जा सकते हैं।
| Concept | Definition (source) |
|---|---|
| REQUIREMENTS LIST | Documentation
of requirements in a list or tool.” (MSF Process model[3] |
|
RISK MANAGEMENT PLAN |
Document
on how the team plans to implement the risk management process within the context of the project.” (MSF Risk Management Discipline[4] ) |
| MASTER PROJECT PLAN | All
plans are synchronized and presented together as the master project plan.” (MSF Process model[3] |
| WORKPLANS | A plan or plans for the deliverables that pertain to the role and
participates in team planning sessions.” (MSF Process model[3] |
| COST ESTIMATES | An estimation of the costs of the project. |
| SCHEDULES | Time estimates and schedules for Deliverables.”
(MSF Process model[3] |
| MASTER PROJECT SCHEDULE | The
various schedules are then synchronized and integrated into a master project schedule.” (MSF Process model[3] |
| FUNCTIONAL SPECIFICATION | The
functional specification describes in detail how each feature is to look and behave. It also describes the architecture and the design for all the features.” (MSF Process model[3] |
तालिका 4: नियोजन चरण में अवधारणाएँ
विकास चरण
चित्र 4: चरण प्रक्रिया/डेटा मॉडल का विकास करना
| Activity | Definition (source) |
|---|---|
| Develop Features | Building of solution components (documentation as well as code).”
(MSF Process model)[3] Also includes testing after the daily build, bug fixing and evaluating the features. |
| Create Daily Build | Creation of a build after a workday. |
| Finalize Scope | At this milestone, all features are complete and the solution is ready for external testing and stabilization.”
(MSF Process model)[3] |
| Develop Infrastructure | The infrastructure is developed.”
(MSF Process model)[3] |
तालिका 5: विकासशील गतिविधियाँ विकासशील चरण में सबसे महत्वपूर्ण गतिविधि सुविधाओं का विकास है। इन सुविधाओं के कार्यान्वयन के अलावा इस चरण में कार्यक्षेत्र को भी अंतिम रूप दिया गया है। विकास के दौरान उत्पाद में नई विशेषताएं जोड़ी जा सकती हैं, लेकिन एक बार कार्यक्षेत्र को अंतिम रूप देने के बाद विशेषताएं स्थिर हो जाती हैं और परीक्षण और स्थिरीकरण के लिए तैयार हो जाती हैं। इस चरण में आधारभूत संरचना भी विकसित की जाती है जिसका अर्थ है कि नेटवर्क संरचनाओं की पहचान की जाती है और उदाहरण के लिए डेटाबेस सर्वर जैसे सर्वर परिभाषित किए जाते हैं।
| Concept | Definition (source) |
|---|---|
| INSTALLATION SCRIPTS AND CONFIGURATION SETTINGS FOR DEPLOYMENT | A collection of scripts and settings needed for the product to install/run. |
| INSTALLATION SCRIPTS | The scripts needed to install the product. |
| CONFIGURATION SETTINGS |
The configuration properties of the product. |
| PERFORMANCE SUPPORT ELEMENTS | Elements that support the performance of the product (extra databases, servers etc.). |
| TEST SPECIFICATIONS AND TEST CASES | Specification of the tests and test cases used to validate the product. |
| FUNCTIONAL SPECIFICATION | The functional specification describes in detail how each feature is to look and behave. It also describes the architecture and the design for all the features.”
(MSF Process model)[3] |
| SOURCE CODE AND EXECUTABLES | The source code/executables combination. |
| SOURCE CODE | The source code of the product. |
| EXECUTABLE | The executable created by source code. |
तालिका 5: विकासशील चरण में अवधारणाएँ
स्थिरीकरण चरण
File:Stabilizing.jpgचित्रा 5: स्थिरीकरण चरण प्रक्रिया/डेटा मॉडल
| Activity | Definition (source) |
|---|---|
| Testing | Testing during this phase emphasizes usage and operation under realistic environmental conditions.“
(MSF Process model)[3] |
| Resolve Bugs | The team focuses on resolving and triaging (prioritizing) bugs and preparing the solution for release.”
(MSF Process model)[3] |
| Deploy Pilot | Once a build has been deemed stable enough to be a release candidate, the solution is deployed to a pilot group.”
(MSF Process model)[3] |
| Review | Once reviewed and approved, the solution is ready for full deployment to the live production environment.”
(MSF Process model)[3] |
तालिका 6: स्थिरीकरण गतिविधियाँ मुख्य गतिविधियाँ बगों का परीक्षण और समाधान हैं। एक बार एक पायलट संस्करण को एक पायलट के लिए पर्याप्त स्थिर माना जाता है, एक पायलट संस्करण बनाया और तैनात किया जाता है। इस पायलट से यह या तो परीक्षण/स्थिरीकरण लूप में वापस जाएगा या इसे अनुमोदित और समीक्षा की जाएगी।
| Concept | Definition (source) |
|---|---|
| TEST RESULTS AND TESTING TOOLS | Collection of test results and tools used for testing. |
| TEST RESULTS | Results of executed tests. |
| TESTING TOOLS | Tools used for testing. |
| GOLDEN RELEASE | The version used for the final reviewing. |
| RELEASE NOTES | Notes for a release version. |
| SOURCE CODE AND EXECUTABLE | The source code/executables combination. |
| SOURCE CODE | The source code of the product. |
| EXECUTABLE | The executable created by source code. |
| MILESTONE REVIEW | Review of the final version and the project documents. |
| PROJECT DOCUMENTS | Collection of all the project documents. |
तालिका 7: स्थिरीकरण चरण में अवधारणाएँ
परिनियोजन चरण
File:Deploying.jpgचित्र 6: परिनियोजन चरण प्रक्रिया/डेटा मॉडल
| Activity | Definition (source) |
|---|---|
| Deploy the Core Components | Deployment of all components needed by the product (such as database servers, mail servers etc.) |
| Deploy the solution on site | For tailor-made systems deployment of the product occurs here (can be skipped for software products). |
| Stabilize the deployment | Tacking, monitoring and improving the deployed components. |
| Transfer the project to operations and support | Transferring all documents and code to the operations and support team. |
| Obtain final approval from customer | The customer must agree that the team has met its objectives before it can declare the solution to be in production and close out the project. This requires a stable solution, as well as clearly stated success criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place.”
(MSF Process model)[3] |
| Review the project | Final review of the project. |
तालिका 8: गतिविधियों की तैनाती परिनियोजन चरण में मुख्य गतिविधि उत्पाद को चलाने के लिए आवश्यक बुनियादी ढाँचे की स्थापना (सर्वर आदि की तैनाती) है। साथ ही, दस्तावेजों को अंतिम रूप दिया जाता है और संचालन और सहायता विभाग को हस्तांतरित किया जाता है, एक ज्ञान का आधार बनाया जाता है और ग्राहक (यदि लागू हो) और परियोजना टीम द्वारा उत्पाद और परियोजना की समीक्षा की जाती है।
| Concept | Definition (source) |
|---|---|
| PROCEDURES AND PROCESSES | Collection of procedures and processes. |
| PROCEDURES | Collection of procedures to be used for installation and operation of the product. |
| PROCESSES | Collection of processes to be used for installation and operation of the product. |
| KNOWLEDGE BASE, REPORTS, LOGBOOKS | Collection of the knowledge base, reports and logbooks. |
| KNOWLEDGE BASE | The knowledge base associated with the product. |
| REPORTS | The reports associated with the product. |
| LOGBOOKS | Logbooks associated with the product. |
| DOCUMENT REPOSITORY | A repository of all documents. |
| FINAL VERSIONS OF ALL PROJECT DOCUMENTS | The final versions of the project documents. |
| OPERATION AND SUPPORT INFORMATION SYSTEMS | Systems used by the operation and support teams associated with the product. |
| CUSTOMER/USER SATISFACTION DATA | Collection of data from the customer/user about his satisfaction with the product. |
| DEFINITION OF NEXT STEPS | Description of next steps to take for evolving the product. |
| PROJECT CLOSE-OUT REPORT |
Final report on the product, project and the transfer to operations and support. |
तालिका 9: परिनियोजन चरण में अवधारणाएँ
समग्र डेटा मॉडल
File:Datamodel.jpgचित्र 7: समग्र डेटा मॉडल यह डेटा मॉडल एक पूर्ण परियोजना संदर्भ में सभी अवधारणाओं को बहुलताओं और संबंधों के साथ दिखाता है।
इंटरनेट-गति विकास के साथ प्रयोग के लिए उपकरण
- ड्राइंग टूल्स (उदाहरण: Microsoft Visio, Rational Rose, Dia (सॉफ्टवेयर)) डायग्राम बनाने के लिए।
- वर्ड प्रोसेसर (उदाहरण: Microsoft Word, OpenOffice.org राइटर, AbiWord, Calligra Words) विजन स्टेटमेंट या स्कोप डॉक्यूमेंट जैसे टेक्स्ट डॉक्यूमेंट बनाने के लिए।
- स्प्रेडशीट (उदाहरण: Microsoft Excel, OpenOffice.org Calc, Gnumeric, Calligra Sheets) प्राथमिकता वाली जोखिम सूची बनाने और लागत गणना करने के लिए।
- प्रोजेक्ट टूल्स (उदाहरण: माइक्रोसॉफ्ट प्रोजेक्ट, ओपनप्रोज, गनोम प्लानर, कैलीग्रा योजना) प्रोजेक्ट गतिविधियों की योजना बनाने के लिए।
- डेटाबेस और डेटाबेस प्रबंधन उपकरण (उदाहरण: MS SQL सर्वर, MySQL, Oracle, PostgreSQL) ज्ञान आधार बनाने के लिए।
- स्वचालित परीक्षण उपकरण (उदाहरण: परीक्षण स्क्रिप्ट) प्रत्येक दैनिक निर्माण के बाद परीक्षण निष्पादित करने के लिए।
यह भी देखें
- चुस्त सॉफ्टवेयर विकास
- वृद्धिशील और पुनरावृत्त विकास
- माइक्रोसॉफ्ट सॉल्यूशंस फ्रेमवर्क
- डायनेमिक सिस्टम डेवलपमेंट मेथड (DSDM)
- MoSCoW विधि
टिप्पणियाँ
- ↑ Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003
- ↑ As shown in the paper of Zuser, Heil and Grechening.
- ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 Microsoft Solutions White Paper June 2002
- ↑ 4.0 4.1 4.2 4.3 Microsoft Risk Management Discipline White Paper
संदर्भ
- Microsoft June 2002 Microsoft Solutions Framework (White Paper) Microsoft Press
- Microsoft June 2002 MSF Risk Management Discipline v.1.1 (White Paper) Microsoft Press
- Wolfgang Zuser, Stefan Heil, Thomas Grechenig 2005 Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study Proceedings of the 2005 workshop on Software quality
- Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003 New Directions on Agile Methods: A Comparative Analysis ICSE
- Michael A. Cusumano, David B. Yoffie 1999 Software Development on Internet Time 32 IEEE
- Balasubramaniam Ramesh, Jan Pries-Heje 2002 Internet Software Engineering: A Different Class of Processes Annals of Software Engineering 14 169–195
