सॉफ्टवेयर विकास प्रक्रिया

सॉफ्टवेयर डेवलपमेंट प्रक्रिया किसी सॉफ्टवेयर उत्पाद के विकास में अधिरोपित एक संरचना है। इसके पर्यायवाची शब्द सॉफ्टवेयर जीवन चक्र और सॉफ्टवेयर प्रक्रिया हैं। ऐसी प्रक्रियाओं के लिए कई मॉडल हैं। इनमें से प्रत्येक प्रक्रिया के दौरान होने वाले विभिन्न प्रकार के कार्यों या गतिविधियों तक पहुंच का वर्णन करते हैं।

समीक्षा

सॉफ्टवेयर डेवलपमेंट संगठनों की सबसे बड़ी निकाय प्रक्रिया संबंधी पद्धतियों का कार्यान्वयन करती है। उनमें से अनेक रक्षा उद्योग में हैं, जिनके लिये संयुक्त राज्य अमेरिका में अनुबंधों को प्राप्त करने के लिये 'प्रक्रिया मॉडलों' के आधार पर मूल्यांकन की आवश्यकता होती है।

चयन की पद्धति का वर्णन करने, सॉफ्टवेयर के लिये जीवन चक्र का कार्यान्वयन करने और उसके निरीक्षण के लिए अंतर्राष्ट्रीय मानक ISO 12207 है।

उत्पादकता और गुणवत्ता में सुधार करने वाली एक दोहराने योग्य, पूर्वानुमेय प्रक्रिया का पता लगाना दशकों से लक्ष्य रहा है। कुछ लोग सॉफ्टवेयर लेखन के प्रकटत: कठिन कार्य को व्यवस्थित या निश्चित रूप देने की कोशिश करते हैं। अन्य लोग सॉफ्टवेयर लेखन के लिए परियोजना प्रबंधन तकनीक प्रयोग में लाते हैं। परियोजना प्रबंधन के बिना, सॉफ्टवेयर परियोजनाओं की सुपुर्दगी में सहज में ही विलंब हो सकता है या इसकी लागत बजट से अधिक हो सकती है। कार्यात्मकता, लागत, या सुपुर्दगी की समय-सारिणी के संबंध में बड़ी संख्या में परियोजनाओं द्वारा अपनी अपेक्षाओं को पूरा नहीं कर पाने के कारण, प्रभावकारी परियोजना प्रबंधन में कमी रह जाती है।

संस्थाएं एक सॉफ्टवेयर इंजीनियरिंग प्रक्रिया समूह (SEPG) की रचना कर सकती हैं, जो प्रक्रिया में सुधार का केंद्र बिन्दु होता है। विभिन्न कौशलों वाले लाइन पेशेवरों से बना यह समूह सॉफ्टवेयर इंजीनियरिंग प्रक्रिया में सुधार लाने के कार्य में शामिल प्रत्येक व्यक्ति के सहयोगपूर्ण प्रयास के केंद्र में स्थित रहता है।

सॉफ्टवेयर डेवलपमेंट संबंधी गतिविधियां

सॉफ्टवेयर डेवलपमेंट प्रक्रिया की गतिविधियां वाटरफॉल मॉडल में चित्रित की गई। इस प्रक्रिया को चित्रित करने के लिए कई अन्य मॉडल हैं।

योजना

सॉफ्टवेयर उत्पाद तैयार करने में महत्वपूर्ण कार्य आवश्यकताओं का पता करना या आवश्यकताओं का विश्लेषण करना है। ग्राहक जिन्हें अंतिम परिणाम के रूप में चाहते हैं, उस संबंध में उनके पास विशेष रूप से एक अमूर्त विचार होता है, न कि सॉफ्टवेयर को क्या करना चाहिए इस संबंध में. इस बिंदु पर अपूर्ण, अस्पष्ट या विरोधाभासी आवश्यकताओं की कुशल और अनुभवी सॉफ्टवेयर इंजीनियरों के द्वारा पहचान की जाती हैं। सजीव कोड (कूट) का प्रदर्शन अक्सर ही करते रहने से आवश्यकताओं के गलत रहने का जोखिम कम हो सकता है।

एक बार ग्राहकों से सामान्य आवश्यकताओं को एकत्रित कर लेने के बाद विकास के कार्य-क्षेत्र के विश्लेषण का निर्धारण किया जाना चाहिए और इसे स्पष्ट रूप से व्यक्त करना चाहिए। इसे अक्सर एक कार्य-क्षेत्र संबंधी दस्तावेज कहा जाता है।

लागत के फलन के कारण या विकास के आरंभ में अस्पष्ट आवश्यकताओं के परिणामों के कारण कुछ कार्यात्मकता परियोजना के कार्य-क्षेत्र से बाहर हो जा सकती है। यदि विकास बाह्य रूप से किया जाता है, तो इस दस्तावेज़ को एक कानूनी दस्तावेज माना जा सकता है ताकि यदि कभी कोई विवाद हो तो ग्राहक को किये गए वादों के संबंध में किसी भी संशयता को स्पष्ट किया जा सके।

डिजाईन

एक नए सॉफ्टवेयर को तैयार करने में अक्सर डोमेन विश्लेषण पहला कदम होता है। चाहे यह वर्तमान सॉफ्टवेयर में कोई परिवर्द्धन, एक नया प्रोग्राम (एपलीकेशन), एक नया उपतंत्र या एक पूर्ण नयी व्यवस्था हो। यह मानकर कि डेवलपर्स (विश्लेषक सहित) नये सॉफ्टवेयर के विषय-क्षेत्र के कुशल जानकार नहीं हैं, पहला काम सॉफ्टवेयर के तथाकथित 'डोमेन' का पता लगाना है। डोमेन के संबंध में वे पहले से ही जितने अधिक जानकार होते हैं, उतने कम काम की आवश्यकता होती है। इस कार्य का एक अन्य उद्देश्य उस क्षेत्र के विशेषज्ञों के साथ आवश्यकताओं को प्राप्त करने वाले और उसे एकत्रित करने वाले विश्लेषकों का डोमेन की अपनी शब्दावली में बात कराना है जिससे इन विशेषज्ञों (क्षेत्र के विशेषज्ञों) द्वारा व्यक्त किये गए कथनों के संबंध में बेहतर समझ विकसित किया जा सके। यदि विश्लेषक उचित शब्दावली का प्रयोग नहीं करता है तो यह संभावना है कि उनकी बातों को गंभीरता से नहीं लिया जायेगा. इस प्रकार, यह चरण आवश्यकताओं का पता करने और उसे एकत्रित करने में एक महत्वपूर्ण प्रस्तावना होगी। यदि किसी विश्लेषक ने उचित काम नहीं किया है तो भ्रम उत्पन्न हो सकता है: "मैं जानता हूं कि आप यह मानते हैं कि मैंने जो कहा उसके संबंध में आप जो सोचते है उसे आपने समझ लिया, लेकिन मैं इस संबंध में निश्चित नहीं हूं कि आप यह समझते हैं कि आपने जैसा सुना वह मेरा मतलब नहीं था ".

विनिर्देश

विनिर्देश वह कार्य है जिसके अर्न्तगत लिखे जाने वाले सॉफ्टवेयर का संभवतः सही ढ़ंग से वर्णन किया जाता है। व्यावहारिक रूप से, सबसे सफल विनिर्देशों को पहले से ही सुविकसित प्रोग्रामों को समझने और अधिक अनुकूल बनाने के लिए लिखा जाता है। यद्यपि अक्सर प्रोग्राम के विकास के पूर्व सुरक्षा की दृष्टि से अत्यंत महत्वपूर्ण सॉफ्टवेयर तंत्रों का सावधानीपूर्वक विस्तृत विवरण दिया जाता है। विनिर्देश बाहरी अंतरफलकों के लिए सबसे अधिक महत्वपूर्ण होते हैं जिन्हें स्थिर बना रहना चाहिए. विनिर्देश पर्याप्त रूप से सही हैं या नहीं इसका निर्धारण करने का एक अच्छा तरीका आवश्यकताओं और उपयोग की स्थितियों की शुद्ध रूप से सक्षमता सुनिश्चित करने के लिए तीसरे पक्ष द्वारा दस्तावेजों की समीक्षा कराना है।

संरचना

एक सॉफ्टवेयर सिस्टम या सॉफ्टवेयर संरचना की बनावट उस तंत्र का एक अमूर्त निरूपण है। संरचना का संबंध यह सुनिश्चित करना है कि सॉफ्टवेयर सिस्टम उत्पाद की आवश्यकताओं को पूरा करेगा, साथ ही साथ यह भी सुनिश्चित करना है कि भविष्य में आवश्यकताओं के संबंध में चर्चा की जा सकती है। संरचना संबंधी कदम सॉफ्टवेयर सिस्टम और अन्य सॉफ्टवेयर उत्पादों के बीच इंटरफेसों (अंतराफलकों), साथ ही साथ अंतर्निहित हार्डवेयर या परिचारक प्रचालन सिस्टम की चर्चा करता है।

कार्यान्वयन, परीक्षण और दस्तावेजीकरण

कार्यान्वयन प्रक्रिया का एक हिस्सा है जहां सॉफ्टवेयर इंजीनियर परियोजना के लिए कोड (कूट) का प्रोग्राम लिखते हैं।

सॉफ्टवेयर परीक्षण सॉफ्टवेयर डेवलपमेंट प्रक्रिया का एक अभिन्न और महत्वपूर्ण हिस्सा है। प्रक्रिया का यह हिस्सा यह सुनिश्चित करता है कि बग की पहचान यथाशीघ्र कर ली जाये.

भविष्य में रखरखाव और सॉफ्टवेयर में वृद्धि करने के उद्देश्य से सॉफ्टवेयर के आंतरिक डिजाइन का दस्तावेजीकरण सम्पूर्ण विकास के दौरान किया जाता है। इसमें एक API का संलेखन शामिल हो सकता है, चाहे वह बाहरी या आतंरिक हो।

परिनियोजन और रखरखाव

कोड का उचित रूप से परीक्षण करने के बाद परिनियोजन आरंभ होता है, इसे निर्गमन और बिक्री के लिए स्वीकृत किया जाता है, नहीं तो किसी उत्पादन परिवेश में वितरित कर दिया जाता है।

सॉफ्टवेयर प्रशिक्षण और सहायता महत्वपूर्ण है, क्योंकि सॉफ़्टवेयर परियोजनाओं का एक बड़ा प्रतिशत इस कारण से असफल हो जाता है कि डेवलपर्स (विकासक) यह नहीं समझ पाते हैं कि यदि संस्था में कोई भी व्यक्ति सॉफ़्टवेयर का अंतिम उपयोग नहीं करता है तो इसे विकसित करने वाले दल द्वारा सॉफ़्टवेयर को तैयार करने में लगे समय और योजना का कोई महत्त्व नहीं रहता है। लोग अक्सर परिवर्तन के प्रतिरोधी होते हैं और एक अपरिचित क्षेत्र में जोखिम उठाने से बचते हैं। इसलिए परिनियोजन चरण के हिस्सा के रूप में, आपके सॉफ़्टवेयर के नए ग्राहकों के लिए प्रशिक्षण कक्षाएं आयोजित होना बहुत आवश्यक है।

नए अविष्कृत समस्याओं या नयी आवश्यकताओं का सामना करने के लिये सॉफ़्टवेयर के अनुरक्षण (रखरखाव) और उसके परिवर्द्धन में सॉफ़्टवेयर के आरंभिक विकास की अपेक्षा अधिक समय लग सकता है। अप्रत्याशित समस्या में सुधार करने के लिये एक कोड को जोड़ना आवश्यक है जो मूल डिजाइन में उपयुक्त नहीं बताता है या यह भी हो सकता है कि कोई ग्राहक अधिक कार्यात्मकता का अनुरोध कर रहा हो और उनके अनुरोध को समायोजित करने के लिये कोड को जोड़ा जा सकता है। इसी चरण में ग्राहकों के कॉल प्राप्त होते हैं और आप देखते हैं कि ग्राहक द्वारा प्रयोग करने के पूर्व क्या आपका परीक्षण समस्याओं को दूर करने के लिये व्यापक रूप से पर्याप्त था। यदि अनुरक्षण वाले चरण का श्रम लागत पूर्व चरणों के श्रम लागत की अपेक्षा 25% से अधिक होता है, तो यह संभावना होती है कि कम से कम एक पूर्व चरण की समग्र गुणवत्ता अच्छी नहीं है। उस स्थिति में, प्रबंधन को अनुरक्षण संबंधी लागत अनियंत्रित होने के पूर्व सिस्टम को पुनर्निर्मित करने के विकल्प पर विचार करना चाहिए।

किसी वास्तविक या महसूस किये गए विषयों की पहचान करने वाले सॉफ्टवेयर का परीक्षण करने वाले ग्राहकों/क्षेत्र दलों के साथ इंटरफेस द्वारा जुड़े रहने के लिये विकास दलों को अनुमति प्रदान करने के लिये प्रक्रिया के इस चरण में अक्सर बग ट्रैकिंग सिस्टम उपकरण परिनियोजित किये जाते हैं। ये सॉफ्टवेयर उपकरण, मुक्त स्रोत और वाणिज्यिक लाइसेंस प्राप्त दोनों, सूचित विषयों को अपनाने, उनकी समीक्षा करने के लिये एक अनुकूल करने योग्य प्रक्रिया उपलब्ध कराते हैं।

मॉडल

पुनरावृत्तीय प्रक्रियाएं

समस्याओं के बहुत पहले महत्वपूर्ण विषयों पर से पर्दा हटाने में शामिल लोगों की मदद करने के लिये पुनरावृत्तीय विकास किसी सॉफ्टवेयर परियोजना के लिये प्रारंभ में छोटे लेकिन हमेशा अधिक बड़े हिस्सों की संरचना निर्धारित करती है। पुनरावृत्तीय प्रक्रियाओं को वाणिज्यिक डेवलपर्स (विकासकों) के द्वारा अधिक पसंद किया जाता है, क्योंकि यह अपनी मांग को परिभाषित करने में असमर्थ ग्राहक के अभिकल्प (डिजाइन) लक्ष्यों तक पहुंचने की संभाव्यता की अनुमति प्रदान करता है।

एजाइल (दक्ष) सॉफ्टवेयर डेवलपमेंट प्रक्रियाओं का निर्माण पुनरावृत्तीय विकास की नींव पर किया जाता है। वे उस नींव में एक अधिक हल्का, पारंपरिक दृष्टिकोणों की अपेक्षा अधिक लोक-केन्द्रित दृष्टिकोण जोड़ते हैं। एजाइल प्रक्रियाएं प्राथमिक नियंत्रण प्रणाली के रूप में योजना की अपेक्षा फीडबैक (प्रतिपुष्टि) का उपयोग करती हैं। फीडबैक नियमित परीक्षणों और विकसित होने वाले सॉफ्टवेयर के रिलीज होने से प्रेरित होता है।

XP: एक्सट्रीम प्रोग्रामिंग

एक्सट्रीम प्रोग्रामिंग (XP) सर्वश्रेष्ठ ज्ञात पुनारावृत्तीय प्रक्रिया है। पहले के पुराने "बैच" प्रक्रियाओं की अपेक्षा XP में, चरणों को अत्यधिक छोटे (या "निरंतर") चरणों में पूरा किया जाता है। प्रथम चरण (स्वेच्छापूर्वक अपूर्ण) उन कदमों से होकर गुजरता है, जिसमें वाटरफॉल मॉडल के प्रत्येक पूर्ण चरण में लगने वाले महीनों और वर्षों की तुलना में एक दिन या एक सप्ताह लग सकता है। सबसे पहले, व्यक्ति विकास के लिए ठोस लक्ष्य उपलब्ध कराने के लिए कम्प्युटरीकृत (स्वतः) परीक्षणों को अंकित करता है। अगला चरण कूट लेखन (प्रोग्रामरों के युग्म द्वारा) है, जो सभी परीक्षणों के बीत जाने और प्रोग्रामर द्वारा और अधिक परीक्षण करने की आवश्यकता महसूस नहीं किये जाने के बाद पूर्ण हो जाता है। डिजाइन और संरचना, रिफ्रैक्टरिंग से उत्पन्न होती है और कूट लेखन (कोडिंग) के बाद आती है। डिजाइन उन्हीं लोगों के द्वारा किया जाता है जो कूट लेखन करते हैं। (केवल अंतिम विशेषता- डिजाइन और कोड का विलय - सभी अन्य एजाइल प्रक्रियाओं के लिए सामान्य होता है। अपूर्ण लेकिन कार्यात्मक प्रणाली उपयोगकर्ताओं (जिनमें से कम से कम एक विकास दल में रहता है) के लिए प्रभावकारी ढ़ंग से प्रयुक्त या प्रर्दशित की जाती है (कुछ उपसमुच्चय). इस बिंदु पर, विशेषज्ञ सिस्टम के अगले सबसे महत्वपूर्ण भाग के लिए परीक्षण लेखन पुनः शुरू करते हैं।

वाटरफॉल प्रक्रियाएं

वाटरफॉल मॉडल एक प्रक्रिया को दर्शाता है, जहां डेवलपर्स (विकासकों) को इन कदमों का क्रम से पालन करना पड़ता है:

1. आवश्यकता संबंधी विनिर्देश (AKA सत्यापन या विश्लेषण)
2. डिजाइन
3. निर्माण (AKA कार्यान्वयन या कूट लेखन)
4. एकीकरण
5. परीक्षण और दोषमार्जन (AKA प्रमाणीकरण)
6. अधिष्ठापन (AKA परिनियोजन)
7. अनुरक्षण (रख-रखाव)

जिस प्रकार ढांचा खड़ा होने के बाद निर्माणकर्ता घर की नींव नहीं बदलता है, प्रत्येक कदम के पूरा होने के बाद प्रक्रिया अपने अगले कदम में आगे बढ़ती जाती है।

यह एक गलत धारणा है कि इस प्रक्रिया में आरंभिक कदमों में त्रुटियों को सुधारने की कोई व्यवस्था नहीं है (उदाहरण के लिए, आवश्यकताओं में). वास्तव में, इसी जगह आवश्यकताओं के प्रबंधन की बात सामने आती है, जिसमें परिवर्तन पर नियंत्रण शामिल है। प्रक्रिया के आलोचकों द्वारा पुनरावृत्ति की शुरुआत के द्वारा समस्याओं को दूर करने में प्रतिवादी तर्क महत्वपूर्ण रूप से एक बढ़ी हुई लागत होती है। यह भी एक कारक है जो सुपुर्दगी के समय को बढ़ा देता है और उच्च जोखिम वाली परियोजनाओं में भी इस प्रक्रिया को तेजी से अलोकप्रिय बना देता है।

इस दृष्टिकोण का प्रयोग उच्च जोखिम वाली परियोजनाओं, विशेष रूप से रक्षा संबंधी बड़े अनुबंधों, में किया जाता है। वाटरफॉल में समस्याएं "विशेष रूप से आवश्यकताओं के विश्लेषण और प्रबंधन में अपरिपक्व इंजीनियरिंग कार्यप्रणालियों" से उत्पन्न नहीं होती है। वाटरफॉल को लागू करने वाली DOD-STD-2167 के विनिर्देश दर की विफलता के अध्ययन ने यह दर्शाया है कि विशेष रूप से अग्रिम आवश्यकताओं के संग्रह में, कोई परियोजना अपनी प्रक्रिया का जितना अधिक ध्यानपूर्वक पालन करता है, परियोजना द्वारा वर्त्तमान रूप में अप्रयुक्त विशेषताओं को जारी करने की उतनी अधिक संभावना होती है। ^{[उद्धरण चाहिए]}

अक्सर कथित चरण ग्राहक और आपूर्तिकर्ता के बीच समीक्षा का हिस्सा होते हैं। वास्तव में, आपूर्तिकर्ता जोखिम में विकास कर सकता है और डिजाइन का विकास कर सकता है, लेकिन उसे डिजाइन को मील के पत्थर क्रिटिकल डिजाइन रिव्यू (CDR) को कम कीमत में अवश्य बेचना चाहिए। यह इंजीयरिंग के भार को इंजीनियरों से ग्राहकों में विस्थापित कर देता है, जिनके अन्य कौशल होते हैं।

अन्य मॉडल

क्षमता परिपक्वता मॉडल एकीकरण

क्षमता परिपक्वता मॉडल एकीकरण (CMMI) प्रमुख मॉडलों में से एक है और सबसे अच्छी कार्यप्रणाली पर आधारित है। स्वतंत्र आकलन संस्थाओं का वर्गीकरण परिभाषित प्रक्रियाओं का उनके पालन के तरीकों के आधार पर करते हैं, न कि उन प्रक्रियाओं या उत्पादित सॉफ्टवेयर की गुणवत्ता के आधार पर. CMMI ने CMM की जगह ले ली है।

ISO 9000

ISO 9000 औपचारिक रूप से प्रलेखन के साथ प्रक्रियाओं के आयोजन के लिए मानकों का वर्णन करता है।

ISO 15504

सॉफ्टवेयर प्रक्रिया सुधार क्षमता निर्धारण (SPICE) के रूप में भी जाना जाने वाला ISO 15504 "सॉफ्टवेयर प्रक्रियाओं के मूल्यांकन की एक रूपरेखा" है। इस मानक का उद्देश्य प्रक्रिया की तुलना के लिए एक स्पष्ट मॉडल की स्थापना करना है। CMMI के समान ही SPICE का भी अधिक प्रयोग किया जाता है। यह सॉफ्टवेयर डेवलपमेंट का प्रबंध, नियंत्रण, मार्गदर्शन और देख रेख करने के लिए प्रक्रियाओं को तैयार करता है। फिर इस मॉडल का प्रयोग सॉफ्टवेयर डेवलपमेंट के दौरान एक विकास संस्था या परियोजना दल के द्वारा किये जाने वाले विकास का मूल्यांकन करने के लिए किया जाता है। इस जानकारी का विश्लेषण कमजोरियों और चालन सुधार की पहचान करने के लिए किया जाता है। यह उन शक्तियों की भी पहचान करता है, जिन्हें उस संस्था या दल के लिए जारी रखा जा सकता है या सामान्य व्यवहार में एकीकृत किया जा सकता है।

सिक्स सिग्मा

सिक्स सिग्मा किसी कंपनी के परिचालन संबंधी प्रदर्शन का मूल्यांकन करने या उसमें सुधार लाने के लिए आंकडों और सांख्यिकीय विश्लेषण का प्रयोग करने वाली प्रक्रिया परिवर्तनों के प्रबंधन की एक पद्धति है। यह निर्माण और सेवा-संबंधी प्रक्रियाओं में दोषों की पहचान कर और उन्हें दूर कर कार्य करता है। अधिकतम स्वीकृति योग्य दोष प्रति दस लाख अवसरों में 3.4 है। हालांकि, सिक्स सिग्मा निर्माण-उन्मुखी है और इसे सॉफ्टवेयर के डेवलपमेंट के लिए अपनी प्रासंगिकता के संबंध में और अधिक शोध करने की जरूरत है।

परीक्षण चालित विकास

परीक्षण चालित विकास (TDD) एजाइल कैंप का एक उपयोगी आउटपुट है, लेकिन कुछ लोग यह सुझाव देते हैं कि यह एक समस्या (पहेली) उत्पन्न करता है। TDD की आवश्यकता है कि एक क्लास के लेखन के पहले एक इकाई परीक्षण लिखा जाए. तब यह सोचा जा सकता है कि सबसे पहले उस क्लास का "पता लगाना" है और दूसरा TDD द्वारा वास्तविक रूप से प्रयोग किये जाने वाले एक बार परीक्षण का लेखन करना और क्लास द्वारा स्वीकृति देने वाले मॉडल को पर्याप्त विस्तार से बताना है। वास्तव में यह एजाइल दृष्टिकोण, विशेष रूप से (तथाकथित) एजाइल मॉडलिंग का प्रतिरोध करेगा, जहां अभी भी डेवलपर्स को हल्के डिजाइन के द्वारा जल्दी से संकेतबद्ध करने के लिए प्रोत्साहित किया जाता है। हालांकि, TDD के दावाकृत लाभों को पाने के लिए क्लास और जिम्मेदारियों का पूरी तरह से एक पूर्ण डिजाइन (कब्जा किया हुआ प्रयोग, उदाहरण के लिए, अनुबंध के द्वारा डिजाइन) आवश्यक नहीं है। इसकी गणना पुनरावृतीय विकास के रूप में की जाती है, जिसमें डिजाइन की कार्यप्रणाली में बाधा आती है, लेकिन पुनरावृतीय डिजाइन में बाधा नहीं आती है - क्योंकि प्रोग्राम के कोड की गुणवत्ता में भारी सुधार और पुनः अभियांत्रिकरण TDD की उपयोगिता को नकार सकते हैं।

औपचारिक पद्धतियां

औपचारिक पद्धतियां आवश्यकताओं, विनिर्देश और डिजाइन के स्तर पर सॉफ्टवेयर (और हार्डवेयर) की समस्याओं को हल करने के गणितीय दृष्टिकोण हैं। औपचारिक पद्धतियों के उदाहरण में बी-विधि (B-Method), पेट्री नेट्स, स्वचालित प्रमेय सिद्ध करना, RAISE और VDM शामिल हैं। विभिन्न औपचारिक विनिर्देश संकेतन, जैसे कि Z संकेतन उपलब्ध हैं। अधिक सामान्य रूप से, परिमित अवस्था यंत्रों के सिस्टम की अभिकल्पना (डिजाइनिंग) कर अनुप्रयोग (प्रोग्राम) की प्रवृत्ति का निर्माण एवं अभिपुष्ट करने के लिए स्वचल प्ररूप सिद्धांत (ऑटोमेटा सिद्धांत) का प्रयोग किया जा सकता है।

परिमित अवस्था यंत्र (FSM) आधारित पद्धतियां निष्पाद्य सॉफ्टवेयर विनिर्देश और पारंपरिक कूटलेखन के लिए उपमार्ग बनाने की अनुमति प्रदान करती है (आभासी परिमित अवस्था यंत्र या कार्यक्रम चालित परिमित अवस्था यंत्र को देखें).

औपचारिक पद्धतियों का अधिक संभवतः वयाविकी सॉफ्टवेयर में अनुप्रयोग किया जा सकता है, विशेष रूप से जहां सॉफ्टवेयर सुरक्षा की दृष्टि से महत्वपूर्ण है। सॉफ्टवेयर सुरक्षा गारंटी मानक, जैसे कि DO178B वर्गीकरण के उच्चतम स्तर (A स्तर) पर औपचारिक विधियों की मांग करती हैं।

अन्य स्थानों में अभिलक्ष्य प्रतिरोध भाषा (और जावा प्रतिदर्शन भाषा जैसे विनिर्देश) और विशेष रूप से अभिकल्पनाओं (डिजाइनों) के निष्पादन, यदि विनिर्देश नहीं हो तो भी, की अनुमति देने वाले मॉडल-चालित संरचना के अनुप्रयोग के साथ-साथ सॉफ्टवेयर डेवलपमेंट का वर्गीकरण फैल रहा है।

सॉफ्टवेयर के विकास में एक अन्य उभरती हुई प्रवृत्ति तर्क के किसी रूप में एक विनिर्देश लेखन (साधारणतः FOL का परिवर्तन) करना और फिर उस तर्क का निष्पादन उसी प्रकार करना है जैसे कि यह कोई प्रोग्राम हो। वर्णन तर्क पर आधारित OWL भाषा इसका एक उदहारण है। तार्किक रूप में और तार्किक रूप से अंग्रेजी के कुछ संस्करणों (या अन्य स्वाभाविक भाषा) रूपों का स्वतः प्रतिचित्रण करने और तर्क को सीधे निष्पादित करने का काम चल रहा है। इसके उदाहरण हैं नियंत्रित प्राकृतिक अंग्रेजी भाषा और इंटरनेट व्यवसाय संबंधी तर्क, जिन्हें शब्दकोश या वाक्य विन्यास को नियंत्रित नहीं करना पड़ता है। द्विदिशी अंग्रेजी-तार्किक प्रतिचित्रण और तर्क का सीधे निष्पादन करने वाले तंत्र की एक विशेषता है कि व्यवसायिक या वैज्ञानिक स्तर पर उनके द्वारा अंग्रेजी में उनके परिणामों की व्याख्या करायी जा सकती है।

सरकारी जवाबदेही कार्यालय ने, 2003 के संघीय उड्डयन प्रशासन की वायु यातायात नियंत्रण के आधुनिकीकरण कार्यक्रमों के रिपोर्ट में प्रमुख अधिग्रहण संबंधी तंत्रों के प्रबंधन के लिए एजेंसी के मार्गदर्शन का अनुपालन करते हुए निम्नलिखित सिफारिशें की है।

• एक सही, वैध और वर्तमान प्रदर्शन की माप करने वाली आधार-रेखा का निर्माण करना, देख-रेख करना और नियंत्रण करना, जिसमें सभी अधिकृत, अनिश्चित मूल्य वाले काम का 3 महीने के भीतर व्यवस्था करना;
• 6 महीने के भीतर किसी भी बड़े अनुबंध संशोधनों की एक एकीकृत आधार-रेखा की समीक्षा करना; और
• अधिग्रहण प्रणाली टूलसेट के मार्गदर्शन के अनुसार और मूल्यांकन में अन्तर्निहित अनिश्चितता के स्तर की पहचान कर जोखिम मूल्यांकन सहित एक कठोर जीवन-चक्र लागत मूल्यांकन तैयार करना।

इन्हें भी देखें

विकास की कुछ और विधियां: विकासवादी विकास मॉडल मॉडल संचालित विकास उपयोगकर्ता अनुभव ऊपर-नीचे और नीचे-ऊपर डिजाइन करना केऑस मॉडल विकासवादी प्रोटोटाइप प्रोटोटाइप ICONIX प्रक्रिया (उपयोग पेटी के साथ UML-आधारित अभिलक्ष्य मॉडलिंग) एकीकृत प्रक्रिया वी-मॉडल ऐक्सट्रीम प्रोग्रामिंग सॉफ्टवेयर डेवलपमेंट लय विनिर्देश और वर्णन भाषा वृद्धि संबंधी धन प्रणाली सत्यापन और मान्यता (सॉफ्टवेयर) सेवा उन्मुखी मॉडलिंग फ्रेमवर्क

संबंधित विषय: तीव्र प्रोग्राम विकास सॉफ्टवेयर डिजाइन सॉफ्टवेयर डेवलपमेंट सॉफ्टवेयर अनुमान सार मॉडल विकास मंच IPO+S मॉडल सॉफ्टवेयर इंजीनियरिंग विषयों की सूची प्रदर्शन इंजीनियरिंग प्रक्रिया प्रोग्रामिंग प्रतिमान प्रोग्रामिंग उत्पादकता परियोजना सिस्टम विकास जीवन चक्र (SDLC) सॉफ़्टवेयर दस्तावेज़ीकरण सिस्टम्स डिजाइन सॉफ्टवेयर डेवलपमेंट दर्शन की सूची परीक्षण प्रयास सर्वोत्तम कूटलेखन प्रणाली सेवा उन्मुखी मॉडलिंग फ्रेमवर्क सूचना प्रौद्योगिकी में स्नातक

बाहरी कड़ियाँ

• नो सिल्वर बुलेट: एसेंस एंड एक्सिडेन्ट्स ऑफ़ फ्टवेयर इंजीनियरिंग", 1986
• जेर्हार्ड फिशर, "द सॉफ्टवेयर टेक्नोलॉजी ऑफ़ द 21st सेंचुरी: फ्रॉम सॉफ्टवेयर रियूज़ टु कॉलाबोरेटिव सॉफ्टवेयर डिज़ाइन", 2001
• लायडिया ऐश: द वेब टेस्टिंग कॉम्पेनियन: द इनसाइडर्स गाइड टु एफिसिएंट एंड इफेक्टिव टेस्ट्स, विली, 2 मई 2003. ISBN 0-471-43021-8
• सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल (SDLC) [विज़ुअल इमेज], "सॉफ्टवेयर डेवलपमेंट लाइफ साइकिल"
• सेलेक्टिंग ऐन SDLC", 2009