डिजाइन के दौरान ग्राहक के साथ आंतरिक बातचीत। ग्राहक और ठेकेदार - परियोजना की सफलता के आधार के रूप में संबंध

ग्राहक के साथ बातचीत के सामान्य चरण निम्नलिखित बिंदु हैं:

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

ग्राहक के साथ बातचीत का एक महत्वपूर्ण रूप गोस्ट 34 और आरयूपी की आवश्यकताओं के अनुसार परियोजना के कार्यान्वयन के दौरान विकसित दस्तावेज है।

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

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

आज, जीवन चक्र के चरणों में विभाजित किए बिना जटिल सॉफ्टवेयर एप्लिकेशन बनाने की प्रक्रिया की कल्पना नहीं की जा सकती है। कार्यक्रम के जीवन चक्र के तहत, हमारा मतलब चरणों के समूह से है:

विषय क्षेत्र का विश्लेषण और तकनीकी विशिष्टताओं का निर्माण (ग्राहक के साथ बातचीत)
कार्यक्रम संरचना डिजाइन
कोडिंग (प्रोजेक्ट प्रलेखन के अनुसार प्रोग्राम कोड का एक सेट)
परीक्षण और डिबगिंग
कार्यक्रम कार्यान्वयन
कार्यक्रम का समर्थन
निपटान

आइए डिजाइन प्रक्रिया पर करीब से नज़र डालें। डिजाइन प्रक्रिया के दौरान, एक वास्तुकार या एक अनुभवी प्रोग्रामर भविष्य के कार्यक्रम के पाठ विवरण, आरेख और मॉडल सहित परियोजना प्रलेखन बनाता है। इस मुश्किल मामले में यूएमएल भाषा हमारी मदद करेगी।

यूएमएल विज़ुअलाइज़ेशन, मापदंडों का विवरण, विभिन्न प्रणालियों के डिजाइन और प्रलेखन (विशेष रूप से कार्यक्रम) के लिए एक चित्रमय भाषा है। डायग्राम विशेष केस टूल जैसे रैशनल रोज़ (http://www-01.ibm.com/software/rational/) और एंटरप्राइज आर्किटेक्ट (http://www.sparxsystems.com.au/) का उपयोग करके बनाए जाते हैं। यूएमएल तकनीक के आधार पर एक एकल सूचना मॉडल बनाया गया है। उपरोक्त CASE उपकरण विभिन्न वस्तु-उन्मुख भाषाओं में कोड उत्पन्न करने में सक्षम हैं, और इसमें एक बहुत ही उपयोगी रिवर्स इंजीनियरिंग सुविधा भी है। (रिवर्स इंजीनियरिंग आपको मौजूदा प्रोग्राम कोड से एक ग्राफिकल मॉडल बनाने और उस पर टिप्पणी करने की अनुमति देता है।)

मॉडल की कल्पना के लिए आरेखों के प्रकारों पर विचार करें (ये अवश्य ही हैं, हालांकि कई और प्रकार हैं):

स्थिति चित्र का उपयोग

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

वर्ग आरेख (वर्ग आरेख)

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

राज्य आरेख (स्टेटचार्ट आरेख)

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

अनुक्रम आरेख

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

सहयोग आरेख

सहयोग के आरेख में, बातचीत में भाग लेने वाली वस्तुओं को आयतों के रूप में दर्शाया गया है, जिसमें वस्तु का नाम, उसका वर्ग और, संभवतः, विशेषता मान शामिल हैं। जैसा कि वर्ग आरेख में है, वस्तुओं के बीच संबंध को विभिन्न कनेक्टिंग लाइनों के रूप में दर्शाया गया है। इस मामले में, आप स्पष्ट रूप से एसोसिएशन के नाम और इस एसोसिएशन में ऑब्जेक्ट्स द्वारा निभाई जाने वाली भूमिकाओं को स्पष्ट रूप से निर्दिष्ट कर सकते हैं।
एक अनुक्रम आरेख के विपरीत, एक सहयोग आरेख केवल उन वस्तुओं के बीच संबंधों को दर्शाता है जो एक बातचीत में कुछ भूमिका निभाते हैं।

घटक आरेख

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

परिनियोजन आरेख

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

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

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

1.1. ग्राहकों के साथ बातचीत (मुख्य कार्य)

1.1.1. आदेश खोज

7.2.3.1. उत्पाद जानकारी के लिए

1.1.2 ग्राहक के साथ पूर्व-अनुबंध कार्य

नियामक दस्तावेज

2.2.1.2.1। ग्राहक एसटीपी-1-01 . के साथ पूर्व-संविदात्मक कार्य

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.2.1.1. उपलब्धता, वितरण और रखरखाव के लिए आवश्यकताओं सहित उत्पादों के लिए ग्राहकों की आवश्यकताएं

7.2.2.4। कुछ आवश्यकताओं के अनुपालन को प्राप्त करने की क्षमता का निर्धारण

// उत्पाद आवश्यकताओं का विश्लेषण / उपभोक्ता से संबंधित प्रक्रियाओं / उत्पादों की बिक्री

1.1.3. संदर्भ की शर्तों का गठन

नियामक दस्तावेज

2.2.1.2.2। अनुबंध के विश्लेषण और निष्कर्ष के लिए प्रक्रिया एसटीपी-2-01 // एंटरप्राइज एंटरप्राइज एलाट (एसटीपी) के मानक / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.2.1.2। आवश्यकताएं ग्राहक द्वारा निर्दिष्ट नहीं हैं, लेकिन इच्छित या निर्दिष्ट उपयोग के लिए आवश्यक हैं // ग्राहकों की आवश्यकताओं की परिभाषा / ग्राहक से संबंधित प्रक्रियाएं / उत्पाद की बिक्री

7.2.1.3. अनिवार्य आवश्यकताओं और कानूनी प्रावधानों सहित उत्पाद से संबंधित दायित्व // ग्राहकों की आवश्यकताओं की परिभाषा / ग्राहक से संबंधित प्रक्रियाएं / उत्पाद की बिक्री

7.2.2.2। उपभोक्ता आवश्यकताओं की पुष्टि उनकी स्वीकृति से पहले, यदि उपभोक्ता आवश्यकताओं का लिखित विवरण प्रदान नहीं करता है // उत्पाद आवश्यकताओं का विश्लेषण / उपभोक्ता से संबंधित प्रक्रियाओं / उत्पादों की बिक्री

7.2.2.3। अनुबंध या आदेश की आवश्यकताओं में परिवर्तन का स्पष्टीकरण जो पहले प्रस्तुत किए गए से भिन्न है (उदाहरण के लिए, बोली या लिंक द्वारा) // उत्पाद आवश्यकताओं का विश्लेषण / उपभोक्ता से संबंधित प्रक्रियाओं / उत्पादों की बिक्री

7.3.1.1. डिजाइन और/या विकास प्रक्रियाओं के चरणों का निर्धारण

7.3.2.2. लागू कानूनी और नियामक आवश्यकताएं

7.3.2.3. इसी तरह के पिछले विकास से प्राप्त लागू डेटा // डिजाइन और विकास / डिजाइन और विकास / उत्पाद बिक्री के लिए इनपुट डेटा

7.3.2.4। डिजाइन और विकास के लिए महत्वपूर्ण अन्य आवश्यकताएं // डिजाइन और विकास / डिजाइन और विकास / उत्पाद बिक्री के लिए इनपुट डेटा

7.3.4.1. आवश्यकताओं को पूरा करने की क्षमता का आकलन

1.1.4. समझौतों का निष्कर्ष

नियामक दस्तावेज

2.2.1.2.3। ग्राहक के साथ संविदात्मक कार्य पर विनियम (एसटीपी-3-01) // उद्यम मानक Ellat (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

1.1.5. संविदात्मक दायित्वों की पूर्ति की निगरानी

नियामक दस्तावेज

2.2.1.2.3.2. परिवर्तनों का विश्लेषण करने और संविदात्मक दस्तावेजों में परिवर्तन करने की प्रक्रिया // ग्राहक के साथ संविदात्मक कार्य पर विनियम (एसटीपी-3-01) / उद्यम मानक एलाट (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

2.2.1.2.4.1. ग्राहक की शिकायतों और दावों को संभालने की प्रक्रिया

2.2.1.2.4.2. ग्राहक की टिप्पणियों को समाप्त करने की प्रक्रिया // सुधारात्मक और निवारक कार्रवाइयों पर विनियम (एसटीपी-4-01) / एलाट एंटरप्राइज स्टैंडर्ड्स (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.2.3.2. प्रसंस्करण अनुरोध, अनुबंध, आदेश, परिवर्तन सहित // उपभोक्ता के साथ संचार / उपभोक्ता से संबंधित प्रक्रियाएं / उत्पादों की बिक्री

1.2. परियोजना कार्य निर्धारण (मुख्य कार्य)

1.2.1. परिसर की संरचना और विकास के दायरे का स्पष्टीकरण

नियामक दस्तावेज

// उद्यम मानक Ellat (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.2.2.1। उत्पाद आवश्यकताओं की परिभाषा // उत्पाद आवश्यकताओं का विश्लेषण / उपभोक्ता से संबंधित प्रक्रियाओं / उत्पादों की बिक्री

1.2.2. परियोजना गुणवत्ता आश्वासन योजना

नियामक दस्तावेज

2.2.1.2.5. एक परियोजना गुणवत्ता आश्वासन कार्यक्रम (एसटीपी-5-01) विकसित करने के लिए संरचना और प्रक्रिया // उद्यम मानक Ellat (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.1.1. किसी उत्पाद, परियोजना या अनुबंध के लिए गुणवत्ता लक्ष्य निर्धारित करना

7.1.3. समीक्षा और अनुमोदन गतिविधियों और स्वीकृति मानदंड की परिभाषा // बिक्री प्रक्रियाओं की योजना / उत्पादों की बिक्री

7.2.2.5. विश्लेषण और अनुवर्ती अनुवर्ती कार्रवाइयों के परिणामों को ठीक करना (खंड 5.5.7 देखें) // उत्पाद आवश्यकताओं का विश्लेषण / उपभोक्ता से संबंधित प्रक्रियाओं / उत्पादों की बिक्री

7.3.1.2। प्रत्येक डिजाइन और/या विकास चरण के लिए समीक्षा, सत्यापन और अनुमोदन गतिविधियों की परिभाषा // डिजाइन और विकास योजना / डिजाइन और विकास / उत्पादों की बिक्री

1.2.3. परिसर के घटकों के विकास के लिए निजी तकनीकी विशिष्टताओं का गठन

नियामक दस्तावेज

2.2.1.2.7. परियोजना कार्यान्वयन प्रौद्योगिकी। काम के चरण और क्रम (एसटीपी-7-01) // उद्यम मानक Ellat (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

1.2.4. परियोजना की योजना बना

नियामक दस्तावेज

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.1.2. उत्पाद के लिए विशिष्ट संसाधन और बुनियादी ढाँचा प्रदान करने, प्रक्रियाओं और प्रलेखन की स्थापना की आवश्यकता का निर्धारण // बिक्री प्रक्रियाओं की योजना / उत्पादों की बिक्री

1.2.5 कार्य प्रदर्शन का समन्वय और परिचालन नियंत्रण

नियामक दस्तावेज

2.2.1.2.4.3. सुधारात्मक कार्रवाई प्रक्रिया // सुधारात्मक और निवारक कार्रवाइयों पर विनियम (एसटीपी-4-01) / एलाट एंटरप्राइज एंटरप्राइज स्टैंडर्ड्स (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

2.2.1.2.6। कार्य योजना पर विनियमन (एसटीपी-6-01) // उद्यम मानक Ellat (एसटीपी) / गुणवत्ता प्रबंधन प्रणाली के दस्तावेज / आंतरिक नियामक दस्तावेज / विनियम

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.3.4.2. अनुवर्ती कार्रवाई के लिए समस्याओं की पहचान और प्रस्तावों का विकास // डिजाइन और विकास विश्लेषण / डिजाइन और विकास / उत्पाद मेलिंग

7.3.7. डिजाइन और विकास परिवर्तन प्रबंधन

1.3. डिजाइन, सॉफ्टवेयर और परिचालन प्रलेखन का विकास (मुख्य कार्य)

1.3.1. परिसर के हार्डवेयर के लिए प्रलेखन का विकास

नियामक दस्तावेज

2.3.3.3. हार्डवेयर विकास और उत्पादन विभाग के लिए कार्य योजना

1.3.2. परिसर के सॉफ्टवेयर भाग का विकास

नियामक दस्तावेज

2.3.3.4. सॉफ्टवेयर विकास और उत्पादन विभाग के लिए कार्य योजना // कार्यक्रम और कार्य योजनाएं / कंपनी के संगठनात्मक और प्रशासनिक दस्तावेज / विनियम

1.3.4. डिजाइन परिणामों का विश्लेषण और अनुमोदन

नियामक दस्तावेज

ISO9000:2000 गुणवत्ता प्रबंधन प्रणाली आवश्यकताएँ खंड 7

7.3.3.1. डिजाइन और विकास इनपुट आवश्यकताओं के अनुरूप

7.3.3.2. विनिर्माण और सेवा संचालन के लिए उपयुक्त जानकारी प्रदान करें (देखें 7.5) // डिजाइन और विकास आउटपुट / डिजाइन और विकास / उत्पाद मेलिंग

7.3.3.4. उत्पाद की विशेषताओं को निर्धारित करें जो इसके सुरक्षित और उचित उपयोग के लिए आवश्यक हैं। // डिजाइन और विकास आउटपुट / डिजाइन और विकास / उत्पाद मेलिंग

7.3.5.1. इनपुट आवश्यकताओं के लिए आउटपुट डेटा की अनुरूपता // डिजाइन और विकास सत्यापन / डिजाइन और विकास / उत्पाद बिक्री

7.3.6. डिजाइन और विकास परिणामों की स्वीकृति // डिजाइन और विकास / बिक्री उत्पाद

शिक्षा, विकास, प्रशिक्षण

कीवर्ड:

1 -1

वेबसाइट विकास के उदाहरण पर ग्राहक के साथ बातचीत की पूरी योजना पर विचार करें। ग्राफिक रूप से, बातचीत के चरणों को निम्न आकृति के रूप में दर्शाया जा सकता है:

प्राथमिक is बुलानाया ईमेल, जो खाता प्रबंधक द्वारा संसाधित किए जाते हैं। प्रबंधक बीहाइव कंपनी की सेवाओं के बारे में बात करता है, रुचि के सभी सवालों के जवाब देता है और ग्राहक को बातचीत की आगे की प्रक्रिया के बारे में बताता है।

* यह ध्यान देने योग्य है कि ग्राहक को अपनी परियोजना की पूरी अवधि के लिए एक व्यक्तिगत प्रबंधक आवंटित किया जाता है, जो सभी सवालों के जवाब देने और सभी समस्याओं को हल करने में मदद करने के लिए तैयार है।

इसके बाद, प्रबंधक पूरा करने में मदद करता है संक्षिप्त रूपएक वेबसाइट के विकास के लिए जिसमें सहयोग के विषय पर आवश्यक स्पष्ट प्रश्न शामिल हैं और आंतरिक सीआरएम सिस्टम (ग्राहक संबंध प्रबंधन प्रणाली) से संपर्क जोड़ता है।

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

पूर्ण संक्षिप्त के आधार पर, मधुमक्खी विशेषज्ञ तैयार करते हैं व्यक्तिगत वाणिज्यिक प्रस्तावकाम के समय और लागत के विवरण के साथ और प्रबंधक इसे ग्राहक को विचार के लिए भेजता है।

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

*कॉल करने से लेकर अनुबंध पर हस्ताक्षर करने तक की प्रक्रिया में आमतौर पर 1-2 दिनों से अधिक का समय नहीं लगता है।

अनुबंध पर हस्ताक्षर करने और इलेक्ट्रॉनिक स्कैन की गई प्रतियों का आदान-प्रदान करने के बाद, ग्राहक एक अग्रिम भुगतान करता है, जिसकी राशि आमतौर पर कुल अनुबंध राशि का 50% होती है।

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

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

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

कभी-कभी ग्राहक के लिए अपनी सेवाओं का स्वयं वर्णन करना कठिन होता है या उसके लिए समय ही नहीं होता है। इस मामले में, ठेकेदार साइट के लिए लापता सामग्री (चित्र, पाठ, वीडियो, आदि) लिखने का काम पूरा करने के लिए तैयार है।

* ग्राहक को आवश्यक सामग्री उपलब्ध कराना महत्वपूर्ण है क्योंकि:

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

* प्रिय ग्राहकों, कृपया अपनी खुद की साइट के विकास और उससे लाभ में देरी न करें। समय पर सामग्री प्रदान करें! अन्यथा, जब तक हमें आपसे जानकारी नहीं मिलती है, तब तक परियोजना को रोक दिया जाएगा और तदनुसार, साइट को जमा करने की समय सीमा स्थगित कर दी गई है। यदि हमारे पास जानकारी एकत्र करने और लिखने का, टेक्स्ट लिखने का आदेश देने और फोटो प्रोसेसिंग का समय नहीं है, तो यह सस्ता है।

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

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

आगे काम जारी रखने के लिए, ग्राहक से सभी आवश्यक सामग्री प्राप्त करना अनिवार्य है, जिसकी सूची ग्राहक को पहले भेजी गई थी।

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

इंटरनेट परियोजना का परीक्षण ठेकेदार के विशेषज्ञों द्वारा किया जाता है, सभी त्रुटियों और टिप्पणियों को समाप्त कर दिया जाता है, साइट काम के लिए ठीक है।

जैसे ही काम पूरा हो जाता है और तकनीकी डोमेन पर साइट का परीक्षण पूरा हो जाता है, हैंडओवर स्टेज. यहां, ग्राहक की ओर से, टीओआर की आवश्यकताओं की पूर्ति और इंटरनेट परियोजना के कामकाज की पूरी प्रक्रिया की जाँच की जाती है।
ग्राहक द्वारा टीओआर की आवश्यकताओं के साथ साइट के पूर्ण अनुपालन पर निर्णय लेने के बाद, साइट को ग्राहक को स्थानांतरित कर दिया जाता है और परियोजना को होस्टिंग पर प्रकाशित किया जाता है।

कार्यों के वितरण और स्वीकृति का परिणाम और पुष्टि एक व्यावहारिक साइट और स्वीकृति का एक कार्य है, जिस पर दोनों पक्षों द्वारा हस्ताक्षर किए जाते हैं। हस्ताक्षरित अधिनियम, लेखांकन के लिए दस्तावेजों के पूरे सेट के साथ, मेल द्वारा भेजा जाता है।

स्वीकृति प्रमाण पत्र पर हस्ताक्षर करने के बाद, ग्राहक, अनुबंध के अनुसार, कार्य की शेष लागत का भुगतान करता है।

अंतिम गणना के बाद, दस्तावेजों और वेबसाइट के साथ, ग्राहक को एक उपयोगकर्ता पुस्तिका प्राप्त होती है, डीवीडी पर साइट की एक प्रतिऔर मुफ़्त तकनीकी समर्थनसाइट की स्वीकृति की तारीख से 2-4 सप्ताह के भीतर।

इस आरेख में, हमने प्रारंभिक कॉल से लेकर परियोजना के वितरण तक के सभी पहलुओं को पूरी तरह से प्रतिबिंबित करने का प्रयास किया। सरल परियोजनाओं के लिए, कुछ चरणों को जोड़ा या छोड़ा जा सकता है। लेकिन किसी भी मामले में, अनुबंध में सब कुछ परिलक्षित होता है।

सेवाओं के लिए काम की योजना "व्यापक वेबसाइट विकास", साथ ही "वेबसाइट प्रचार" संरचनात्मक रूप से ऊपर वर्णित ग्राहक और ठेकेदार के बीच बातचीत की प्रक्रिया को दोहराती है और इसलिए विस्तृत विवरण की आवश्यकता नहीं होती है।

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

परियोजना:	खोज सूचकांकों और खोज शब्दों द्वारा इलेक्ट्रॉनिक कैटलॉग में प्रश्नों का वितरण
परियोजना गुंजाइश:	13.02.2006 - 05.06.2006
ग्राहक:	पेट्रोज़ावोडस्क स्टेट यूनिवर्सिटी की वैज्ञानिक पुस्तकालय।
ज़िम्मेदार:	गोर्शकोवा गैलिना अनातोल्येवना, दस्तावेजों के कंप्यूटर प्रसंस्करण और कैटलॉग के निर्माण विभाग के प्रमुख। ईमेल मेल: . दास। दूरभाष: 719602. पुस्तकालय: कैब। 102. आरसीएनआईटी के प्रमुख प्रोग्रामर गुरयेव दिमित्री बोरिसोविच। ईमेल मेल: . दास। दूरभाष: 784775. इंटरनेट केंद्र।
प्रशिक्षक:	कुलकोव किरिल अलेक्जेंड्रोविच ईमेल: । कार्यालय फोन: 711015. कमरा 215
प्रशिक्षक के लिए सूचना:	समूह संख्या 13
संबंधित दस्तावेज:	परियोजना अवलोकन परियोजना योजना कार्य अनुसूची (गैंट चार्ट) आवश्यकताएँ विशिष्टता डिजाइन परीक्षण कार्यान्वयन दस्तावेज़ परीक्षण दस्तावेज़ Customer Engagement डेवलपर संबंध रिपोर्ट विकास प्रगति शब्दावली उपयोगकर्ता मार्गदर्शिका

ग्राहक के साथ पहली बैठक।

पहली बैठक में, विकास टीम को ग्राहक से मिलवाया गया। बदले में, ग्राहक ने पेट्रएसयू के वैज्ञानिक पुस्तकालय के बारे में बात की।

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

ग्राहक को लगातार लॉग टेबल की निगरानी करने और खोज इंडेक्स के उपयोग पर कुछ आंकड़े प्रदान करने की आवश्यकता होती है।

कार्यान्वित की जा रही परियोजना के लिए प्रारंभिक आवश्यकताओं को भी प्रस्तुत किया गया था। आवश्यकताओं में से एक आँकड़ों का कुशल संकलन है। यानी अनुरोध भेजने के बाद उचित समय के बाद आंकड़े प्रदर्शित होने चाहिए। इस आवश्यकता के कारण, डेवलपर्स को पीएल/एसक्यूएल में सर्वर-साइड प्रक्रियाओं का उपयोग करने के लिए प्रोत्साहित किया गया।

ग्राहक के साथ दूसरी बैठक।

ग्राहक ने डेवलपर्स को इलेक्ट्रॉनिक कैटलॉग सिस्टम में प्रवेश करने के लिए एक लॉगिन और पासवर्ड प्रदान किया, जो काम के लिए दो तालिकाओं की प्रतियां प्रदान करता है - एक लॉग टेबल और खोज इंडेक्स की एक तालिका।

Guryev दिमित्री बोरिसोविच ने Oracle SQL*Plus DBMS क्लाइंट में काम के साथ हमें और अधिक विस्तार से परिचित कराया। टीम इलेक्ट्रॉनिक कैटलॉग के काम से परिचित हुई।

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

निर्देशिका उपयोगकर्ता आंतरिक और बाहरी में विभाजित हैं। प्रत्येक विभाग या कर्मचारी को अपने अधिकार सौंपे जाते हैं। किसी ऑब्जेक्ट के बारे में प्रत्येक रिकॉर्ड को अलग-अलग तत्वों में पार्स किया जाता है और संपूर्ण रूप से संग्रहीत नहीं किया जाता है।

ग्राहक के साथ तीसरी बैठक।

ग्राहक ने हमें लिखित रूप में स्पष्ट आवश्यकताएं प्रदान की हैं।

ग्राहक निम्नलिखित आँकड़ों में रुचि रखता है:

इलेक्ट्रॉनिक कैटलॉग के अनुरोधों की संख्या।

पिछले महीने के लिए दिन के हिसाब से।
चालू वर्ष के लिए मासिक लेखा।
वर्षों से लेखांकन।
जानकारी का इतिहास बनाएं।

द्वारा अनुरोधों की सूची प्रत्येक के लिएखोज अनुक्रमणिका जहां खोज परिणाम शून्य था।

बार-बार होने वाले अनुरोधों की सूची।

एक निश्चित अवधि के लिए अनुरोधों के निष्पादन का विश्लेषण। रिपोर्ट में निम्नलिखित आँकड़े शामिल होने चाहिए:

अनुरोधों की संख्या।
लुकअप अनुरोधों की संख्या।
जटिल प्रश्नों की संख्या।
सफल प्रतिक्रियाओं की संख्या।
शून्य प्रतिक्रियाओं की संख्या।
लेखक
लेखक रेव. उत्पाद
दस्तावेज़ के प्रकार।
भौगोलिक खंड।
तिथि दर्ज करें।
प्रकाशन तिथि।
शीर्षक।

ग्राहक के साथ चौथी बैठक।

ग्राहक से विशेषज्ञ गुरयेव डी.बी. SQL*Plus उपयोगिता को स्थापित और कॉन्फ़िगर करने की पेचीदगियों के बारे में बताया। प्रोग्राम को लॉन्च करने की समस्या का समाधान SQL * नेट पैकेज को स्थापित करना था, साथ ही Guryev D.B. डेवलपर्स के लिए तालिकाओं के सटीक नाम प्रदान किए, और टीम के निपटान में एक और तालिका भी जोड़ी। विशेषज्ञ ने वास्तुकला दस्तावेज़ का अध्ययन किया और सभी प्रकार की वास्तुकला को व्यावहारिक रूप से लागू करने और सबसे इष्टतम चुनने का प्रस्ताव दिया। साथ ही, यह वांछनीय है कि लॉग-टेबल का पुनर्निर्माण न किया जाए और, जितना संभव हो, किसी विशिष्ट समस्या को हल करते हुए, विभिन्न स्थानीय आंकड़ों में आगे उपयोग के लिए लॉग-टेबल से डेटा को सामान्यीकृत किया जाए।

ग्राहक गोर्शकोवा जी.ए. आवश्यकताओं के दस्तावेज से परिचित हुए, उन्हें अनुमोदित किया।

ग्राहक के साथ पांचवीं बैठक।

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