CHAPTER 3 Software Requirement Engineering ھندسة المتطلبات البرمجية Topics: 3.1 Introduction 3.2 Requirement and its Problems 3.3 Software Requirement Engineering and its Objectives 3.4 Software Requirement Engineering Activities - Requirement Elicitation - Requirement Analysis - Requirement Specification - Requirement Validation - Requirement Management 1
3.1 Introduction After system engineering is completed, software engineers need to look at the role of software in the proposed system. Software requirements analysis is necessary to avoid creating software product that fails to meet the customer's needs. Data, functional, and behavioral requirements are elicited from the customer and refined to create specification that can be used to design the system. Software requirements work products must be reviewed for clarity, completeness, and consistency. مقدمة : ان احد االسباب االساسية لفشل معظم المنظومات البرمجية ھو وجود مشاكل في تحديد المتطلبات( Requirements ( ويمكن ان نقول بأن تقريبا %85 من االخطاء في المنظومات مرده ومرجعه عدم وضوح المتطلبات وبالتالي المساعدة على عرقلة المراحل التي تلي مرحلة التحليل وفي النھاية الحصول على منظومات غير ذات جودة وال تلبي احتياجات المستخدم بالكامل. لقد كان االھتمام في : الستينيات بالبرمجة. السبعينيات بالتصميم. الثمانينيات والتسعينيات (والى حد االن) بالمتطلبات والمواصفات. وتعتبر المرحلة المتعلقة بجمع المتطلبات Requirement Gathering من اھم مراحل دورة حياة اعداد المنظومة الن جمع المتطلبات اذا لم يتم بالصورة الصحيحة والكاملة فأن كل المراحل التي تليھا ستكون بالطبع غير كاملة.ومھما يكن مستوى التصميم جيدا فلن تنجح المنظومة اال بجودة المتطلبات اوال. وھناك مفھوم خاطىء عند بعض الناس مرده ان المتطلبات موجودة في رأس المستخدم او الزبون. والحقيقة التي تم اكتشافھا ھي ان جمع المتطلبات عمل جماعي يتم اداؤه من قبل ما يسمى Stakeholders وھم الزبون والمستخدم ومعد المنظومة. لھذا بدأ العلماء والمتخصصون والھيئات العلمية ذات العالقة بھذا المجال في التفكير جديا بالتعامل مع ھذه المسألة وايجاد الحلول لھا ومن ثم ظھر مصطلح ھندسة المتطلبات البرمجية Requirement Engineering يطفو على السطح في بداية التسعينيات وھو نفس النمط الذي ظھر في نھاية الستينيات عندما ظھر مصطلح ھندسة البرمجيات كحل ألزمة البرمجيات Software Crisis التي لم تحل بالكامل حتى االن. فھندسة المتطلبات البرمجية ستساھم مع غيرھا من الطرق لحل ھذه المشكلة التي شعرت بھا الشركات المتخصصة العداد المنظومات وادركت ان العواقب ستكون وخيمة وقوية ومؤثرة على االعداد والتكلفة والصيانة. وقبل ان نبدأ في شرح محتويات ھذا الفصل نورد بعض التعريفات المھمة لألشخاص الذين لھم عالقة بھندسة المتطلبات : المستخدم النھائي : End-User وھو الشخص الذي سيستخدم المنظومة ألداء الوظائف المنوطة به. مھندس البرمجيات : Software Engineer وھو الشخص الذي له الخبرة والمعرفة بالتحليل والتصميم والبرمجة واالختبار واعداد النماذج التجريبية وغيرھا. مھندس المتطلبات : Requirement Engineer وھو الشخص المسؤول على التعرف على المتطلبات وتوثيقھا. 2
نستعرض في ھذا الفصل معنى ومشاكل المتطلبات ثم نعرج على خمس نشاطات رئيسية (وظائف ھندسة المتطلبات البرمجية)خاصة بالوصول الى متطلبات صحيحة وكاملة وواضحة وھذه النشاطات تشتمل على : وظائف ھندسة المتطلبات البرمجية (نشاطات) : (1 (2 (3 (4 (5 استنباط المتطلبات تحليل المتطلبات توصيف المتطلبات اعتماد المتطلبات ادارة المتطلبات Requirement Elicitation Requirement Analysis Requirement Specification Requirement Validation Requirement Management 3.2 Requirement and its Problems المتطلبات ومشاكلھا المتطلبات( Requirement ) : ما ھي اال ملخص لمجموعة طلبات يرغبھا الزبون في شكل وظائف وقدرات وخصائص ومعايير جودة خاصة بالمنظومة المعلوماتية المطلوبة وذلك لجلب منفعة وقيمة للمستخدم.او بتعبير اخر ھي قدرات برمجية مطلوبة في المنظومة لحل مشكلة المستخدم. انواع المتطلبات البرمجية : يمكن تصنيف المتطلبات البرمجية حسب االتي : -1 متطلبات وظيفية Functional Requirements المتطلبات الوظيفية ھي االفعال (الوظائف) المرغوب اداؤھا بواسطة المنظومة البرمجية.او ھي المعامالت الرئيسية التي تحدث في المنظومة من حيث قراءة ومعالجة البيانات والحصول على النتائج في صورة مخرجات. -2 متطلبات األداء Performance Requirements وتسمى متطلبات زمن االستجابة مثل : كم عدد المعامالت التي يتم تنفيذھا في فترة زمنية محددة او ان زمن االستفسار عن صنف معين ال يتعدى ثالث ثوان او نوع وكمية البيانات التي يتم التعامل معھا ومعالجتھا فمثال : قد تكون احدى المتطلبات ما يلي :%95 من المعامالت يجب اداؤھا في زمن اقل من الثانية الواحدة. -3 متطلبات البيانات Data Requirements البيانات المطلوبة في المنظومة الجديدة. -4 متطلبات التشغيل Operational Requirements يمكن ان تشتمل على مؤھالت وقدرات المستخدم ومعايير واجھة المستخدم المطلوبة. -5 متطلبات القبول Acceptance Requirements وتتضمن خصائص الجودة المطلوبة في المنظومة البرمجية مثل االعتمادية وسھولة الصيانة والحماية والكفاءة وغيرھا. 3
المتطلبات : المشاكل واألسباب تتلخص اھم المشاكل واألسباب التي تتعلق بالمتطلبات في اآلتي : الزبون او المستخدم ال يعرف بالضبط ماذا يريد وما ھي احتياجاته الفعلية. التحليل في اغلب االحيان ناقص وغير كامل. التغيير الكبير في تقنية الحاسوب (البرمجياتSW والعتادHW ) وعالم التجارة واالعمال زاد من الضغط على تقليص مدة اعداد المنظومة. معد البرمجيات يجد صعوبة في ترجمة او تحويل المتطلبات الى برامج وقواعد بيانات. التغيير في المتطلبات من جانب الزبون بشكل متكرر وھو في بعض االحيان غير مبرر. الميزانية والجدول الزمني غير معقول وغير مقبول. التغيير في اللوائح والقوانين زاد من مشكلة المتطلبات. عدم تعريف نطاق العمل المراد اداؤه بصورة صحيحة وكاملة. التعرف على كامل المتطلبات وتوثيقھا صعب للغاية. عدم قدرة المستخدم على فھم اھمية وغرض مواصفات المتطلبات. عدم القدرة على فھم منھجية صحيحة عند اعداد المنظومات. االعتقاد السائد بين المدراء بأن مرحلتي البرمجة واالختبار ھما المجھود الحقيقي والمھم في اي مشروع برمجي دون مراعاة اھمية المراحل االخرى. نقص في مدراء مشاريع البرمجيات المھرة وذوي الخبرة. 3.3 Software Requirement Engineering and its Objectives ھندسة المتطلبات البرمجية واھدافھا ھندسة المتطلبات البرمجية Software Requirement Engineering ھي كل النشاطات المستخدمة للتعرف على المتطلبات ثم تحليل ھذه المتطلبات للوصول الى متطلبات اضافية ومن ثم توثيق واعتماد ھذه المتطلبات لتلبي احتياجات المستخدم. اما االھداف التي ترمي اليھا فھي : 1- فھم اساسيات ھندسة المتطلبات. 2- التعرف على طرق استنباط المتطلبات. 3- تحليل المتطلبات البرمجية. 4- تكوين وكتابة مواصفات المتطلبات. 5- تقييم واعتماد المتطلبات البرمجية. 6- ادارة اي تغييرات تحصل لھذه المتطلبات.... 3.4 Software Requirement Engineering Activities ولنبدأ بوظائف ھندسة المتطلبات البرمجية (النشاطات) : اوال - استنباط المتطلبات Elicitation of Requirements يعتبر ھذا النشاط وھو جمع واستنباط المتطلبات من المستخدم والزبون الوظيفة االولى في مرحلة التحليل ويتم فيه االستفادة من كل الذين لھم عالقة بالمنظومة Stakeholders المراد اعدادھا من اجل اكتشاف واستنباط وفھم احتياجات المستخدم. User needs 4
ان اصعب مھمة في عملية جمع المتطلبات ليس توثيق ما يريده الزبون ولكن محاولة مساعدة الزبون لفھم ما يحتاجه. ويتم في ھذا النشاط استخدام مجموعة طرق وادوات لھذا الغرض منھا : 1- المقابلة الشخصية Interview تعتبر المقابلة الشخصية احدى اھم طرق جمع المتطلبات الخاصة بالمنظومات المعلوماتية وفي بداية المشروع يقضي محلل النظم وقتا كافيا لعمل مقابالت شخصية مع الزبون والمستخدم من اجل فھم طبيعة العمل والبيانات والمعلومات المتداولة في بيئة الزبون وايضا القوانين واللوائح المستخدمة لتسيير دفة العمل. -2 االستبيان Questionnaire بالرغم من اھمية المقابلة الشخصية كطريقة من الطرق الرئيسية في الحصول على المتطلبات اال انھا مكلفة ويتم اجراؤھا على عدد صغير ومحدود بمعنى انه لن تكون الصورة واضحة على كل ما يجري. لھذا فان طريقة االستبيان Questionnaire ھي النقيض حيث تجري على عدد ھائل من الناس في زمن قليل. وعادة يتم تجھيز االستبيان على ورق اال انه يمكن اجراؤه على الھاتف او االنترنت. ويحتوي االستبيان عادة على مجموعة من االسئلة القصيرة والطويلة او االسئلة ذات االجابة المحددة من بين مجموعة اجابات. Multiple Choice وتجري االستبيانات وتسمى ايضا المسح Survey للوصول الى ھدف معين. وعلى سبيل المثال يمكن استخدامھا لمعرفة رأي المستخدمين في عمل النظام ) او المنظومة) الحالي. -3 المالحظة Observation تعتبر طريقة مباشرة لتفقد ومعرفة النظام تحت الدراسة وتساعد على الوصول للمعلومة بشفافية وبموضوعية كما ھي وليس كما يعتقدھا الزبون والمستخدم. ولكن من عيوبھا ان عملھا ليس دائم ومستمرا لھذا قد يلتجىء المستخدم للتصنع والعمل المثالي لحظة مالحظة المحلل وبالتالي تكون المعلومات المجمعة ال تعكس الواقع المعيش. لھذا من االفضل اداء ھذا العمل (في بعض الحاالت) من دون علم الموظف القائم بالعمل وھذا ال يعني انه في حاالت معينة يمكن ان يتفاعل محلل النظم مع الشخص المعني وان يوجه االسئلة او يشاھد ويجمع بعض النماذج المستخدمة. -4 جمع وتحليل العينات والوثائق Document Gathering & Sampling تعتبر طريقة جمع وتحليل النماذج Forms والوثائق Documents ھامة ايضا ومجدية الننا قد نجد طرقا اخرى تساعدنا على معرفة طريقة عمل النظام كما ھي على ارض الواقع او كما تم شرحھا اثناء المقابلة والمالحظة. لكن السؤال ھو ھل يعمل المستخدم بالطريقة المثالية والصحيحة المدونة بالقوانين واللوائح في شكل وثائق او ال ولالجابة عن السؤال اقول : عند جمع عينات من الوثائق الخاصة باللوائح والملفات والنماذج والتقارير والمخططات التنظيمية للمؤسسة وتحليلھا يمكن معرفة ومقارنة طريقة عمل النظام بالطريقة المثالية وطريقة عمل النظام بالطريقة الفعلية. وبالطبع سيستفيد محلل النظم من ھذا عند تحيد المتطلبات للمنظومة الجديدة. -5 تصميم التطبيق المشترك (JAD) Joint Application Design بدأت ھذه الطريقة في أواخر السبعينات من قبل شركة IBM لغرض جمع كل من الزبون (المدير ورؤساء االقسام مثال) والمستخدمين ومحللي النظم والمبرمجين ومقرر الجلسات في عملية تحليل النظام. وانتشرت ھذه الطريقة JAD بعد ذلك كأداة مھمة تستعمل في اعداد المنظومة وذلك بأشراك الزبون في معظم المراحل. وفي مرحلة التحليل يتم عمل ورش عمل (جلسات) لجمع المتطلبات من قبل الذين لھم عالقة بالنظام ( Stakeholders )في مكان واحد وفي وقت واحد ولمدة قد تستغرق اسبوعا. وھي جلسات مكثفة لحل المشاكل او على االقل معرفة السبب في صعوبة ايجاد الحلول. ان مشاركة المستخدم في اغلب مراحل المشروع اصبح من المفاھيم الحديثة والمرغوبة. وقد تم ايجاد عالقة بين مشاركة المستخدم ورضاه عن المنظومة حين تسلمھا الن افضل االفكار االبداعية للمنتجات الجديدة وتحسينھا تأتي عادة من الزبون وليس من معد المنظومة. ويجب اخذ المالحظة بأن مكان االجتماع يجب ان يكون بعيدا من مكان عمل الزبون ويجب اعداد الحجرة التي ستعقد فيھا الجلسات جيدا بمعنى وجود السبورة البيضاء وجھاز الحاسوب للمقرر وطابعة لطباعة الوثائق التي قد توزع على الحاضرين وجھاز 5
عرض الشرائح باستخدام الحاسوب. اما بعد المكان فمرده الى االبتعاد عن االزعاج واالرباك وزحمة العمل ليتسنى التركيز على العمل الذي كلفوا به. وتتلخص النقاط في ھذه الجلسات في ما يلي : 1- لمحة على النظام الحالي والمشاكل التي تعترضه. 2- مناقشة لتصميم النماذج والتقارير للمنظومة المقترحة (واجھة المستخدم). 3- مناقشة حول وظائف المنظومة المقترحة وخصائص الجودة المطلوبة في ھذه المنظومة. -6 تخطيط المتطلبات المشترك (JRP) Joint Requirement Planning ھذه الطريقة JRP لجمع المتطلبات تعتبر حالة خاصة من طريقة JAD وھي مصطلح خاص بالتحليل والمتطلبات بينما JAD لجميع المراحل. وھي جلسة عمل جماعية بعكس الطريقة التقليدية المتمثلة في : المقابلة التي يتم فيھا اجتماع منفرد مع الزبون او المستخدم. فھذا االجتماع الجماعي لالشخاص الذين لھم عالقة بالمنظومة الجديدة له ھدف واحد يتمثل في التعرف على المشاكل التي تعترض النظام الحالي وتحليلھا ومحاولة تحديد المتطلبات للمنظومة الجديدة. وتتركز فكرة ھذه الطريقة على مبدا االجماع والشورى في تحديد المشاكل والمتطلبات واالھداف ويتم االجتماع عادة في اماكن مجھزة لھذا الغرض. وفي ھذه الجلسات يمكن اثارة وتوليد افكار لحل المشاكل التي تعترض النظام الحالي باستخدام طريقة اثارة االفكار. Brainstorming -7 العرض التجريبي : Prototyping يعتبر العرض التجريبي Prototyping من اھم الطرق الفعالة والناجحة لجمع المتطلبات الوظيفية فھي طريقة لعرض منظومة تجريبية ) لنسخة مبدئية من المنظومة المعلوماتية ( ذات الوظائف المحدودة تبين قدرات المنظومة على اداء وظائفھا. وھي اداة تواصل جيدة بين جميع االطراف ذات العالقة بالمنظومة وتبين بشكل مبدئي شكل المنظومة النھائي حيث نرى ان المتطلبات التي قد تم جمعھا في المقابلة الشخصية تجسدت واقعيا في المنظومة. -8 حالة االستخدام والسيناريو Use Case and Scenarios تستخدم طريقة حاالت االستخدام Use Cases للتحديد والتعرف على المتطلبات الوظيفة للمنظومة المزمع تنفيذھا. وتسمى ھذه الوظائف (المعامالت) بحاالت المستخدم. وفي ھذه الطريقة يقوم محلل النظم باالستفادة من المقابالت الشخصية والمالحظة بالتعرف على الذين يقومون بأداء الوظائف ومن ثم رسم مخطط حالة االستخدام UCD بمساعدة المستخدم. ثم بعد ذلك يقوم المستخدمون بشرح كيفية اداء كل معاملة او وظيفة خاصة بالمنظومة على شكل وصف نصي لكل حالة استخدام على حده ويسمى ھذا النص بالسيناريو Scenarios وتلحق بھذا المخطط وبالتالي الحصول على المتطلبات الوظيفية. Functional Requirements ويفضل استخدام ورش العمل Workshops في شكل جلسات يحضرھا المستخدم والزبون ومحلل النظم وفريق العمل االخر. وھذه الطريقة تشجع عملية االجماع حول المتطلبات ومن ميزاتھا رخص تكاليف استعمالھا. وھي طريقة تفاعلية بين كل المستفيدين والمتأثرين بالمنظومة وبھا يتم ادماج المستخدم في المنظومة منذ البداية. 9- جلسة توليد االفكار : Brainstorming وتعتبر طريقة جلسة توليد واثارة افكار Brainstorming ذات اھمية حيث تكوين وجمع واقتباس المتطلبات من مجموعة من االشخاص ذوي العالقة بالمنظومة (Stakeholders) في مدة قصيرة وتوليد عدة افكار بخصوص المزايا المرتقبة من المنظومة. ثم بعد ذلك يتم تصنيفھا حسب االھمية ويتم ايضا اكتشاف متطلبات مخفية ولم يتم التعرف عليھا بالطرق االخرى. وھذه الطريقة تشجع على التفكير المنظم واعطاء فرصة لالبداع. -10 البحث والتطبيقات المشابھة Research & Similar Applications تعتبر طريقة البحث Research من الطرق المھمة لتجھيز محلل النظم للعمل في المنظومات الجديدة التي ليس له سابق خبرة بھا وال بمصطلحاتھا ومفرداتھا. يتضمن البحث عادة المكتبة واالنترنت ودراسة السوق ومراجعة تطبيقات مشابھة Similar Applications في الشركات واقسام الحاسوب بالجامعات والمعاھد التقنية. 6
... Requirements Analysis ثانيا : تحليل المتطلبات ان فكرة التحليل اساسا ھي تقييم احتياجات المستخدم للوصول الى تعريف محدد للمتطلبات البرمجية المراد تجھيزھا. ونعني بتحليل المتطلبات Analysis) :(Requirements عملية تفكيك وتجزئة المتطلبات العامة (العالية المستوى) وتحويلھا الى متطلبات وظيفية تفصيلية (متدنية المستوى) حيث يتم استخدام ادوات مناسبة لتمثيلھا و نمذجتھا. Modeling وكمالحظة في ھذا السياق يجب ان اقول انه يجب تصنيف وترتيب ھذه المتطلبات ليتم تنفيذھا حسب االھمية. وھذا التصنيف للمتطلبات يمكن ان يأخذ شكل : متطلبات ضرورية. متطلبات مشروطة. متطلبات اختيارية. - وعند تحليل المتطلبات اي نمذجتھا نستخدم االدوات بناء على المنھجية التي يتم اختيارھا لعملية التحليل للمنظومة. وتوجد منھجيتان مشھورتان على نطاق واسع وھما المنھجية الھيكلية و المنھجية الشيئية. المنھجيات المستخدمة في تحليل المتطلبات : اوال : المنھجية الھيكلية Structured Methodology ثانيا : المنھجية الشيئية Object-Oriented Methodology ثالثا - منھجية أجل Agile Methodology رابعا : منھجية اطار عمل الحلول (MSF) Ms-Solution Framework Methodology :Structured Methodology اوال : المنھجية الھيكلية المنھجية الھيكلية Methodology) (Structured : وتقسم ھذه المنھجية المنظومة الى أجزاء وظيفية في شكل ھرمي وتستخدم أدوات ھيكيلة في التحليل والتصميم والبرمجة مثل مخطط انسياب البيانات DFD والمخطط الھيكلي.Structure chart ھذه المنھجية تركز اكثر على وظائف المنظومة (المعالجة) حيث يتم استخدام االدوات المستخدمة في التحليل الھيكلي Structured Analysis لتمثيل ووصف نمذجة ھذه الوظائف. ومن ھذه االدوات المستخدمة في المنھجية الھيكلية : 1- مخطط انسياب البيانات (DFD) : Data Flow Diagram وھو مخطط ھيكلي رسومي يبين صورة لحركة انسياب البيانات داخل النظام بين مخازن البيانات والمعالجة والكيانات الخارجية. نإ الشكلاألساسيلل DFD يعرف باسم graph) Flow أوchart (Bubble الرسم البياني لتدفق البيانات أو مخطط الفقاعة. يستخدم لغرضين : اوال يعطينا مؤشرات حول كيفية انتقال البيانات خالل النظام. ثانيا يوضح الدوال التي تقوم بتناقل البيانات او تحويل البيانات. 7
وھناك نوعان من مخطط : DFD األول : يستخدم لتمثيل النظام كما ھو على ارض الواقع مشتمال على المعلومات والمواد ويسمى المخطط االنسيابي الماديDFD Physical وھو وسيلة تفاھم بين المستخدم ومحلل النظم حتى يفھم محلل النظم الدورة المستندية وتحرك المواد عبر النظام ليتسنى له فھم عمل النظام وبالتالي تزال عملية الغموض لديه. الثاني : يستخدم ليكون اساسا لمرحلة التصميم ويسمى المخطط االنسيابي المعنوي Logical DFD ويشتمل على انسياب البيانات فقط محذوفا منه انتقال المواد. وعملية رسم مخطط انسياب البيانات تبدأ برسم مخطط عام وعالي المستوى (وبدون تفاصيل) يسمى المخطط البيئي Context Diagram يبين تفاعل المنظومة مع الكينونات الخارجية (البيئة الخارجية للمنظومة). ثم يقوم محلل النظم بتفصيل المخطط البيئي ليشمل على مخططات تفصيلية تسمى DFD level 1 و DFD level 2 وھكذا تتم التجزئة تباعا. ومن مزايا ھذه التجزئة الھيكلية ازدياد سھولة فھم النظام او المنظومة من خالل المناقشة حولھا بين جميع االطراف ذات العالقة. ويعتبر مخطط انسياب البيانات بسيط التكوين اال انه اداة قوية لتمثيل (نمذجة) وظائف النظام (او المنظومة). ويعتقد العديد من محللي النظم ان ھذا المخطط ھو كل ما يحتاجونه لمعرفة التحليل الھيكلي والحق انه بدون استخدام ادوات اخرى مساعدة لعملية التحليل تصبح ھذه االداة غير ذات جدوى في حد ذاتھا. لھذا يجب جمع ھذه االداة مع ادوات اخرى مثل قاموس البيانات Data Dictionary واالنجليزية الھيكلية Decision وشجرة القرار Entity Relationship Diagram ومخطط الكائنات العالئقية Structured English Tree وغيرھا. -2 قاموس البيانات Data Dictionary يمكن تعريف اداة قاموس البيانات Data Dictionary بأنه قائمة او مستودع لكل عناصرالبيانات objects) (data الخاصة بالمنظومة او وصف لمخازن البيانات وانسيابھا والموجودة في مخطط. DFD ونظرا ألھمية ھذه االداة لتحديد متطلبات البيانات Data Requirements الخاصة بالمستخدم فأنھا يجب ان تكون دقيقة وواضحة لكي تساعد على التفاھم المشترك بين كل من المستخدم ومحلل النظم والمصمم والمبرمج وابعاد اي لبس حول مدخالت ومخرجات المنظومة. وتعتبر ھذه االداة من االساسيات التي سيستفاد منھا في تصميم قاعدة البيانات في مرحلة التصميم. -3 االنجليزية الھيكلية Structure English تعتبر االنجليزية الھيكلية Structure English اداة تحليل نصية تستخدم جزء محدود من اللغة االنجليزية لتوضيح الخطوات المراد اداؤھا لوظائف (عمليات) منظومة معلومات. وتستخدم افعال مثل : subtract...etc read,write, print, sort, add, وعناصر بيانات مثل Customer-no, item-no, price وتركيبات البرمجة الھيكلية مثل While-Do أو If-then-else وعادة ما تستخدم االنجليزية الھيكلية بعد رسم مخطط انسياب البيانات لتوضيح كل معالجة Processes في. DFD وتعتبر االنجليزية الھيكلية اداة تواصل مع المستخدم ألزالة الغموض حول كل عملية. وھي اساس كتابة شبه الشفرة Pseudo code في مرحلة التصميم. 8
-4 جدول القرار Decision Table يعتبر جول القرار Decision Table أداة تحليل في شكل جدول (مصفوفة) يبين االفعال Actions المحتملة بناءا على شروط Conditions معينة. - وتساعد ھذه األداة Table) (Decision في توضيح القرارات التي تستخدم في الحاالت المعقدة. ويستخدم محلل النظم ھذه االداة لتبيين سياسة عمل النظام مثل : - سياسة التخفيضات في نظم المبيعات. - سياسة تنسيب طلبة الثانوية للجامعات والمعاھد. - سياسة تقييم المستوى األكاديمي للطالب بناء على أدائه في االمتحانات والواجبات المدرسية. -5 شجرة القرار Decision Tree شجرة القرار Decision Tree أداة تحليل على شكل شجرة تبين الحاالت (الشروط) Conditions واالفعال Actions ذات العالقة بھذه الشروط وھي تبين سياسة عمل النظام. وھي تشبه الى حد بعيد عمل جدول القرار اال ان تفرعاتھا يجب ان تكون محدودة وھي بديل لجدول القرار في النظم الغير معقدة. -6 مخطط الكائنات العالئقية (ERD) Entity Relationship Diagram يعتبر مخطط الكائنات العالئقية (Entity Relationship Diagram) ERD بداية صحيحة من قبل محلل النظم لفھم متطلبات البيانات Data Requirements الخاصة بالمنظومة تحت االعداد.ويتكون مخطط الكائنات العالئقية من اشكال ھندسية تشبه المخطط االنسيابي تبين الكائنات Entities والعالقة Relationships بين ھذه الكائنات وايضا الخصائص Attributes (عناصر البيانات) لكل كائن أو عالقة. ويعتبر ھذا المخطط أيضا أساسا لتصميم قاعدة البيانات. - وھو أداة تواصل بين محلل النظم والمستخدم لفھم وتدوين عناصر البيانات المستخدمة وانتمائھا للكيانات. - وفي الوقت الحاضر وبأستخدام العرض التجريبي Prototyping أصبح الحصول على عناصر البيانات عمال ميسرا. ثانيا : المنھجية الشيئية :Object-Oriented Methodology المنھجية الشيئية Methodology) (Object Oriented : وتقسم ھذه المنھجية النظام الى كائنات لھا وظائف وخصائص شبيھة بالكائنات التي نتعامل معھا في حياتنا اليومية.وتستخدم ادوات شيئية مثل مخطط الحالة UCD ومخطط الفصيلة.class diagram يمثل التحليل الشيئي Object-Oriented Analysis تغيرا دراميا مقارنة بالتحليل الھيكلي حيث يتم التعامل مع النظام على أساس أنه مجموعة من الكائنات (المادية والمعنوية). أما التحليل الھيكلي فيعتبر البيانات منفصلة عن العمليات التي تحصل على ھذه البيانات. بمعنى أن البيانات ليس لھا أھمية بالغة في التحليل الھيكلي. Structured Analysis حيث يتم تقسيم المنظومة الى وظائف رئيسية وتجزأ ھذه الوظائف الى وظائف فرعية وھكذا. أما غرض التحليل الشيئي OOA فھو ربط البيانات والعمليات في مكان واحد وھو الكائن Object أو الفصيلة Class علما بأن الكائن حالة خاصة من الفصيلة. وفي ھذا النوع من التحليل يمكن تعريف الفصائل والعالقات بين ھذه الفصائل والنظام. ويجب اتباع الخطوات التالية للحصول على ھذا التحليل : 1- يبدأ محلل النظم في الحصول على بعض المتطلبات من الزبون والتي من اھمھا المتطلبات الوظيفية ويستخدم مخطط استخدام الحالة (UCD) Use Case Diagram كأداة ھامة لتحديد ھذه المتطلبات. ويستخدم السيناريو Scenario النصي لوصف كل حالة استخدام. 9
Methods Attributes الخاصة بالنظام ) أيضا الخصائص والطرق لكل 2- التعرف على الفصائل Classes فصيلة ). 3- رسم مخطط الفصائل Class Diagram ويتم ذلك اما يدويا او بأستخدام احدى ادوات. Case 4- رسم مخطط السلسلة Sequence Diagram ليعبر عن وصف تفصيلي لكل حالة استخدام. االدوات المستخدمة في المنھجية الشيئية: وفي ھذا البند نقوم بشرح ثالث مخططات شيئية تستخدم في مرحلة التحليل : -1 مخطط حالة االستخدام (UCD) : Use Case Diagram ويعتبر مخطط حالة االستخدام UCD أداة تحليل شيئية مھمة لتوضيح المتطلبات الوظيفية للنظام. ويتكون من اشكال ھندسية تعبر عن حالة االستخدام Use Case وھي المعاملة او الوظيفية التي يؤديھا النظام والممثل او الفاعل Actor وھو الذي يقوم بأداء ھذه المعاملة (حالة االستخدام). -2 مخطط الفصيلة Class Diagram مخطط الفصيلة Class Diagram ھو أداة تحليل شيئي رسومي يبين ھيكلية الكائنات الساكنة للنظام. وھذه الھيكلية تبين فصائل الكائنات والعالقة بين ھذه الكائنات. ويبين مخطط الفصيلة الحركة الساكنة للمنظومة الشيئية. -3 مخطط السلسلة Sequence Diagram يعتبر مخطط السلسلة Sequence Diagram أداة تحليل شيئية تبين الكائنات والتواصل بين ھذه الكائنات بأستخدام الرسائل المتبادلة بينھم عند تنفيذ حالة االستخدام. ويبين مخطط السلسلة الحركة المتحركة (الديناميكية) للمنظومة الشيئية. ثالثا : منھجية أجل : Agile Methodology تعتمد منھجية Agile على اختيار افضل االدوات والطرق المناسبة ألداء المھام الخاصة بالمنظومة. وتعتمد على استعمال عدة منھجيات في المشروع الواحد مثل استخدام االداة DFD مع االداة UCD في نفس المشروع اي المنھجية الھيكلية والمنھجية الشيئية. وبعبارة اخرى يمكن استخدام منھجيات وطرق مختلفة والھدف ھو تسريع عملية اعداد المنظومة وھذه المنھجية تفاضل بين االنتاجية والجودة. رابعا : منھجية اطار عمل الحلول (MSF) Ms-Solution Framework Methodology في ھذه المنھجية MSF التي تستخدمھا شركة Microsoft في اعداد منظوماتھا يستطيع محلل النظم ان يصمم عدة نماذج Models منھا على سبيل المثال ال الحصر : نموذج المعالجة Process Model نموذج البيانات Data Model نموذج ادارة المخاطرة Risk Management Model وكل نموذج يساھم في تحليل وتصميم المنظومة تحت االعداد. وتستخدم منھجية MSF ادوات OOA مثل UCD وادوات. CASE ونعيد ھنا القول أنه : للحصول على منظومة ذات جودة يجب ادماج والحاق المستخدم جنبا الى جنب مع معد المنظومة في ھذه المرحلة المھمة اال وھي التحليل.... 10
ثالثا : المواصفاتSpecifications Requirements ) (Specification او توصيف المتطلبات في ھذا النشاط يتم كتابة وتجھيز وثيقة ھامة من وثائق المنظومة في نھاية مرحلة التحليل وتسمى وثيقة مواصفات المتطلبات Requirement Specification Document والتي تشتمل على كل متطلبات المنظومة المقترحة. وتلعب وثيقة المتطلبات دورا مھما في دورة حياة المنظومة النھا تقودنا الى مراحل التصميم والتنفيذ وتعتبر اساسا للتعاقد بين الزبون ومعد المنظومة. ولقد ثبت ان حوالي %85 من اخطاء البرمجيات كان مرده الى المتطلبات ومشاكلھا والتي ھي : %49 افتراضات تتعلق بمتطلبات غير صحيحة. %29 متطلبات محذوفة (غير معلنة). %13 متطلبات متضاربة. %5 متطلبات غامضة وغير واضحة. وقد ثبت من االحصائيات بسبب مشكلة تحديد المتطلبات ايضا ان حوالي %30 من المشاريع يتم الغاؤھا قبل ان تنتھي وان حوالي %50 من المشاريع تكلف الضعف من التقديرات االولية. خصائص مواصفات المتطلبات البرمجية : تناول العالم (1984) Boehm خصائص مواصفات المتطلبات البرمجية الجيدة فيما يلي : Complete كاملة Measurable دقيقة وقابلة للقياس Correct صحيحة Unambiguous واضحة Testable قابلة لالختبار Consistent متناغمة (غير متضاربة) Concise موجزة ومحددة Verifiable قابلة للتحقق Changeable سھولة التعديل Design-free بدون عالقة بالتصميم وقبل لن نشرع في ھذه الوثيقة نشرح معنى واھداف التوثيق : التوثيق Documentation يعتبر التوثيق عنصرا مھما في اعداد البرمجيات واستمرار عملھا بعد االعداد. ويمكن تعريف التوثيق بأنه مجموعة اوصاف نصية ورسومية وشروح للمنتوج البرمجي (المنظومة البرمجية ). وقد يشمل التوثيق ما يلي : Narratives سرد أو نص Charts مخططات Tables جداول Voice الصوت Video clips قصاصات فيديو Animations صور متحركة Comments in program تعليقات في البرنامج ويمكن ان تكون الوثيقة على شكل ورقة او تكون مخزنة في الحاسوب. 11
اھداف ووظائف التوثيق : يؤدي التوثيق الوظائف التالية : 1- مرجع تاريخي. 2- مرجع ارشادي وتوضيحي. 3- متابعة جودة المنتوج البرمجي. 4- التواصل بين مراحل اعداد المنظومة. 5- التواصل بين المھام داخل المرحلة الواحدة. 6- اتفاق بين المستخدم او الزبون ومعد المنظومة. استخدام التوثيق : يستخدم التوثيق المعد بصورة عامة من قبل : االدارة لغرض المراجعة. القائمين على صيانة البرنامج. فريق التفتيش. فريق المراجعة غير الرسمية من قبل زمالء العمل. موظفي التحقق والمصادقة. نستعرض االن محتويات وثيقة مواصفات المتطلبات التي يجب ان يعدھا محلل النظم في نھاية مرحلة التحليل ولتتم مراجعتھا من قبل االدارة التخاذ احد القرارات االتية : االستمرار في المشروع وتنفيذ المرحلة التالية وھي التصميم. وقف استمرار المشروع. اجراء بعض التعديالت ثم االستمرار في المشروع. وثيقة تحديد المتطلبات : Requirement Specification Document تعريف وثيقة تحديد المتطلبات : ھي وثيقة يتم اعدادھا في نھاية مرحلة التحليل تتضمن وظائف المنظومة المراد تنفيذھا وخصائص الجودة المتعلقة بھا. وھذه الوثيقة يجب ان تكون صحيحة ودقيقة وكاملة ومتناسقة وقابلة للقياس واالختبار. بنود وثيقة مواصفات المتطلبات : Introduction (a (المقدمة) -1 description Overall وصف عام : تعريف المسألة problem definition االھداف system objectives of the البينيات (الواجھات) system interfaces of the حدود المنظومة scope of the system القيود system constraints of the -2 الوصف الوظيفي : Functional description قائمة الوظائف functions list of system وصف كل وظيفة function Narrative for each 12
Data/ Information description (b وصف البيانات : مخطط ERD قاموس البيانات Entity relationship diagram Data dictionary Process/ logic description (c وصف المعالجة والمنطق: مخطط انسياب البيانات مخطط استخدام الحالة االنجليزية الھيكلية شجرة القرار جدول القرار (DFD) Data Flow Diagram (UCD) Use Case Diagram Structured English Decision tree Decision table Performance Requirements (d متطلبات االداء: زمن االستجابة الذاكرة Response Time Memory Validation / Acceptance Criteria (e معيار التحقيق والقبول: انواع االختبارات خصائص الجودة المطلوبة البنود القابلة للتسليم Types of test Quality attributes required Deliverables Solutionاستراتيجية Strategy الحل: (f رسومات أم نص قاعدة بيانات أم ملفات on-line/off-line Graphic / text database / files مالحظات عن وثيقة مواصفات المتطلبات : 1- تصف مشاكل وليس حلوال. 2- ھي منتوج وليس عملية معالجة. 3- وثيقة بين الزبون والمحلل وتستخدم فيما بعد في التصميم. 4- تقوم بتحويل االحتياجات الى متطلبات. 5- يجب مراجعتھا من قبل المستخدم ومعد المنظومة. 6- تبين ما ھو المتوقع من المنظومة وليس كيفية العمل.... 13
رابعا :اعتماد المتطلبات Requirement Validation يعتبر ھذا النشاط مھما للغاية يھدف في النھاية الى التأكد Confirmation من ان مواصفات المتطلبات التي تم تجھيزھا في البند السابق تتوافق مع المعايير Standards في كتابة وثيقة المتطلبات وجاھزة الن تكون أساسا لعملية التصميم في المرحلة الالحقة لمرحلة التحليل. ويستخدم في ھذا التحقق واالختبار عدة طرق للفحص والمراجعة والتأكد والتي منھا : المراجعة النھائية Review او مراجعة البرمجيات Review) ( Software : -1 تعتبر مراجعة البرمجيات مصفيا ضروريا ومھما لعملية إعداد البرمجيات حيث تتم مراجعة توثيق نھاية كل مرحلة : التحليل والتصميم والبرمجة. والھدف ھو كشف االخطاء وھي لضمان الجودة عن طريق فحص التوثيق للمنظومة تحت اإلعداد لغرض إيجاد أي أخطاء فيه. وفي المراجعة التي تتم بحضور االدارة يتم تجھيز تقرير يتم إعداده في نھاية كل مرحلة التخاذ قرار بخصوص المنظومة تحت اإلعداد. ونتيجة المراجعة يتم اتخاذ أحد القرارات التالية : 1- االستمرار في المرحلة التي تليھا. 2- التوقف عن المشروع بالكامل. 3- إجراء تغييرات على التوثيق ثم االستمرار في المرحلة التي تليھا. والمراجعة بصفة عامة تعتبر طريقة تأكيد ومصادقة تحضرھا اإلدارة ويتم فيھا : - تحديد التحسينات الضرورية للمنتوج البرمجي الذي تم إعداده من قبل فريق إعداد المنظومة. - تحديد وتأكيد األجزاء التي ال حاجة وال ضرورة لتحسينھا. - جعل العمل التقني أكثر مالئمة ويتوافق مع ما ھو متوقع. 2- الفحص او التفتيش Inspection او فحص الشفرة او التفتيش الرسمي ) Inspection : (Formal/ Code Inspection إلى جانب المراجعة على التوثيق في نھاية كل مرحلة يتم الفحص او التفتيش على الشفرة. فالفحص ھو عملية لكشف األخطاء في شفرة جزء برمجي وليس تصحيحھا. ومن أمثلة ھذه األخطاء : األخطاء المنطقية في الشفرة. ويتم فحص الشفرة في جلسة تعقد بحضور معد الجزء البرمجي وفريق الفحص (التفتيش) المكون من المنسق والشخص المراجع او المختبر وقارئ للجزء البرمجي. وتستغرق الجلسة الواحدة زھاء الساعتين. ويتم توفير اآلتي لھذه الجلسة : - الشفرة المراد فحصھا. - المعايير المستخدمة في إعداد المنظومة ليلم فريق الفحص بھا وباستخدامھا في عملية التفتيش. - قائمة باالخطاء المتوقعة errors) (Check list يتم تجھيزھا بواسطة أخصائيين ذوي خبرة ويتم استخالصھا من منظومات سابقة. ومن أمثلة بنود ھذه القائمة ما يلي : 1- ھل تم إعطاء قيم ابتدائية للمتغيرات المستخدمة في الجزء البرمجي (الشفرة) 2- ھل كل حلقة (loop) لھا نھاية end) ) 14
3- ھل عدد البارمترات المستخدمة في اإلجراء (procedure) أو الدالة ) function )صحيح 4- ھل التداخل بين جمل التحكم والحلقات صحيح 5- ھل جمل التحكم مكتوبة بشكل صحيح وتوافق لغة البرمجة 6- ھل جمل اإلدخال واإلخراج صحيحة 7- ھل العمليات الحسابية في الجزء البرمجي تمت بطريقة صحيحة -ھذا النوع من المراجعة قد يكلف الوقت والجھد ولكنه يقلل من تكلفة االختبارات بعد تنفيذ المنظومة. وكما ذكرنا سابقا فان مھمة فريق الفحص ھي تحديد واكتشاف االخطاء وليس تصحيحھا فالذي يقوم بتصحيح ھذه االخطاء ھو نفس الشخص الذي أعد ھذا الجزء البرمجي. وتتم جلسة أخرى للتاكد من عدم اكتشاف أخطاء اخرى ناتجة عن تصحيح األخطاء المكتشفة سابقا. لھذ نقول بأن عملية الفحص عملية تكرارية. مالحظة : رغم أن المراجعة والفحص لھما نفس الھدف وھو إنتاج منتوج ذي جودة عالية إال أنھما يختلفان في طريقة العمل. 1 2 المراجعة Review) (Software تتم المراجعة عادة بصورة عامة يتم توجيه تقريرھا إلى اإلدارة ألخذ القرارات الالزمة حياله. الفحص (Inspection) يتم بشكل اكثر تفصيال وتكرارا يتم توجيه التقرير الناتج عنه إلى معد الجزء البرمجي للتصحيح 3- المراجعة السريعة (التصفح) : Walkthrough ھو عبارة عن طريقة أخرى للمراجعة الغير رسمية وتھدف أصال للحصول على الجودة في المنتوج البرمجي شأنھا شأن المراجعة والفحص ولكنھا تختلف عنھما بأنھا عملية لمراجعة المنتوج البرمجي بواسطة الزمالء في فريق العمل (Peers) وذلك بھدف كشف األخطاء (بدون تصحيحھا) بطريقة غير منتظمة أي ال ضرورة من معرفة مدير المشروع بھا وال ضرورة لتوثيقھا بل تاتي عفوية بين أعضاء فريق المنظومة فيما بينھم. مثال : قد يعد أحد المحللين مخطط انسياب البيانات (DFD) وللتأكد من صحته قد يتصفحه ويراجعه محلل أخر من نفس الفريق لتحديد األخطاء في ھذا المخطط دون التعرض لطريقة تصحيحه. والجدول التالي يعرض الفرق بين التصفح (Walkthrough) و الفحص (Inspection) التصفح (Walkthrough) يزيد من تواصل اعضاء فريق المشروع (تأتي عفوية بين أعضاء فريق المنظومة فيما بينھم) جلسات غير رسمية جلسات غير منتظمة يتم بواسطة زمالء فريق اعداد المنظومة فھو أداة تعليمية ممتازة ألعضاء الفريق الجدد. الفحص (Inspection) يستخدم قائمة أخطاء متوقعة تستخدم جلسات رسمية أسلوب منتظم للبنود يتم بواسطة عناصر مؤھلة 1 2 3 4-4 التحقق والتصديق &Validation) (Verification - التحقق : Verification يستخدم التحقق Verification للتأكد من صحة توثيق المنتوج البرمجي في مراحل التحليل والتصميم والبرمجة (ويتم على الورق بدون جھاز الحاسوب) والتأكد من أن أي وثيقة في نھاية مرحلة ما مقتنبسة من المرحلة السابقة لھا. 15
فمثال يمكن التاكد من ان شبة الشفرة (Pseudocode) التي يتم إعدادھا في مرحلة التصميم مقبسة من المرحلة السابقة لھا وھي مرحلة التحليل وبالتحديد مقتبسة من االنجليزية الھيكلية Structure English وھكذا.ويسمى التحقق بالكشف الساكن او االختبار الساكن Checking) (Static Testing or Static ويعني الكشف عن االخطاء على التوثيق (وثيقة المتطلبات أو وثيقة التصميم مثال). - اما التصديق و االعتماد :Validation فھو اختبار يتم عند تنفيذ المنظومة Implementation ويتم من قبل فريق عمل مستقل حيث يجري اختبار يسمى test) (Validation ويسمى أيضا ) Dynamic (Testing ألنه يجري على جھاز الحاسوب (بدل التوثيق) للتأكد بان المتطلبات الوظيفية والمدونة في وثيقة المتطلبات قد تم تنفيذھا بالكامل وبطريقة صحيحة على جھاز الحاسوب. والھدف الوصول الى برمجية ذات جودة عالية وتلبي متطلبات المستخدم بالكامل وبطريقة صحيحة ومرضية. ونلخص الفرق بين االعتماد والتحقق في اآلتي : التحقق Verification ھو عملية تحديد ما إذا كانت مواصفات مرحلة معينة (مثال مرحلة التصميم) تحقق مواصفات مرحلة سابقة لھا (مثال مرحلة التحليل) أي مقتبسة منھا. يتم على الورق بدون جھاز الحاسوب اي اختبار ساكن Static Testing يتم من قبل جھة او فرق عمل مستقل التصديق و االعتماد Validation ھو عملية تقييم المنظومة في نھاية المشروع أي في نھاية مرحلة التنفيذ والتأكد من ان المنظومة تؤدي وظائفھا طبقا للمتطلبات الواردة في وثقية تحديد المتطلبات. تستخدم آلية اختبار االعتماد على جھاز الحاسوب في عملية االختبار اي اختبار ديناميكي Dynamic Testing يتم من قبل جھة او فرق عمل مستقل 1 2 3 مالحظة : ترتيب التسلسل الزمني للطرق السابقة ھو كالتالي : -1 التصفح (Walkthrough) -2 الفحص (Inspection) -3 التحقق Verification 4- التصديق و االعتماد Validation -5 مراجعة البرمجيات Review) ( Software... خامسا : ادارة المتطلبات Requirement Management ان ادارة المتطلبات : ھي دراسة واستخدام االجراءات والسياسات والعمليات التي تحكم كيفية التعامل مع التغير في المتطلبات وبمعنى أدق : 1- كيفية تقديم مستند طلب تغيير. Change Request 2- كيفية تحليل ھذا الطلب ومعرفة تأثيره على التكاليف والجدول الزمني وحدود المشروع. 3- كيفية المصادقة والموافقة على اجراء التغيير او رفضه. 4- كيفية تنفيذ التغيير بعد اخذ الموافقة عليه. Controlling ويھتم ھذا النشاط في ھندسة المتطلبات ايضا بالتخطيط Planning المتطلبات والتحليل والمواصفات والتحقق. والمتابعة لنشاطات جميع 16
ومن المھام االدارية الخاصة بأدارة المتطلبات Requirement Management ما يلي : ادارة النسخ الخاصة بالمنظومة والتغيير Managing versions and change تخزين خصائص المتطلبات Storing requirement Attributes التواصل مع الذين لھم عالقة بالمنظومة Stakeholders من قبل شركات Automated Requirement Management وتوجد برمجيات جاھزة الدارة المتطلبات متخصصة. ومن ابرز ھذه البرمجيات : Doors Requisite Pro RTM Workshop Caliber-RM ونظرا الھمية المتطلبات والتعامل معھا فقد أنشأت بعض الشركات ادارة تعھد اليھا بمتابعة التغييرات التي تحدث في المتطلبات ومتابعة اصدار النسخ واالصدارات لھذه البرمجيات والتي تسمى ادارة مكونات البرمجيات.... 17