نمذجة إجرائيات الأعمال

1. نمذجة إجرائيات الأعمال Business Process Modeling

2. وصف عام لمحتوى المادة • إجرائيات تطوير نظم المعلومات • مراحل دورة حياة المنتج البرمجي • نماذج أساسية لإجرائيات التطوير • الإجرائية الموحدة لتطوير نظم المعلومات: • مبادئ الهندسة غرضية التوجه • الإجرائية التكرارية التزايدية • نمذجة التحليل والتصميم باستخدام لغة النمذجة الموحدة: • نمذجة حالات الاستخدام وبناء مخططاتها • نمذجة الصفوف وعلاقاتها وبناء مخطط الصفوف • نمذجة السلوك (مخططات التسلسل ومخططات النشاط) • نمذجة واجهات الاستخدام ITA330_F12_S1

3. ما هي “إجرائية العمل”؟ يمكن تعريف إجرائية العمل (Business Process) بأنها مجموعة من الأنشطة أو المهام المهيكلة والمترابطة والتي تُنتج بعد نجاح تنفيذها خدمة أو منتجاً يحقق غاية محددة لزبون محدد. يمكن التمييز بين ثلاثة أنماط من إجرائيات الأعمال: • الإجرائيات الإدارية (Management Processes): وهي الموجهة لإدارة عمل مؤسسة على المستوى الأعلى (إدارة استراتيجية). • الإجرائيات العملياتية (Operational Processes): وهي المتعلقة بجوهر العملية الإنتاجية والتي تعطي المنتج قيمته (عمليات الشراء، التصنيع، التسويق، المبيعات...). • الإجرائيات الداعمة (Supporting Processes): موجهة لدعم الإجرائيات العملياتية (المحاسبة، التوظيف، الدعم الفني...). ITA330_F12_S1

4. أنماط الإجرائيات ومستويات الإدارة • مستويات الإدارة الثلاث: • استراتيجي (Strategic). • تكتيكي (Tactical). • عملياتي (Operational). • التطبيقات والحلول الموافقة لمستويات القرار: يبين الشكل في الشريحة التالية التطبيقات والحلول الموافقة لمستويات القرار المختلفة في المؤسسة. • المستوى الاستراتيجي: التطبيقات والحلول التي تعود على المؤسسة بالفائدة الأكبر، لكنها أيضاً الحلول الأصعب تحقيقاً فهي تحتاج لاستخدام أحدث التقانات كما تتطلب درجة عالية من المهارة والتصميم التخصصي. وهذه الأنظمة هي التي تعطي المؤسسة قدرتها التنافسية. • المستوى العملياتي: أنظمة روتينية تستخدم تقانات قواعد المعطيات التقليدية وغالباً ما تبنى بتخصيص حلول موجودة مسبقاً. ITA330_F12_S1

5. أنماط نظم المعلومات ومستويات الإدارة ITA330_F12_S1

6. إجرائية العمل (نموذج عام) ITA330_F12_S1

7. ما هو النموذج؟ • النموذج هو محاولة لتبسيط الواقع. ITA330_F12_S1

8. لم نقوم ببناء النماذج؟ • نبني النموذج لنفهم النظام الذي ننوي تطويره فهماً أفضل. • تحقق النمذجة أربعة أهداف أساسية: • تساعدنا على معاينة النظام كما نريده أن يكون. • تسمح لنا بتوصيف بنية النظام وسلوكه. • تزودنا بقالب يرشدنا أثناء بناء النظام. • توثّق القرارات التي اتخذناها. • نبني نماذج للأنظمة المعقدة التي يتعذر فهمها بكليتها. ITA330_F12_S1

9. لم نقوم ببناء النماذج؟على مستوى الإجراء • لبناء تصور وفهم مشترك لطريقة تنفيذ الإجراء • للبحث عن الخطوات المتناقضة أو المكررة أو الناقصة لضمان فعالية الإجراء. • لدراسة الأنشطة الملائمة للوصول لأهداف الإجراء وتقييمها. • لتعديل إجراء عام بحيث يصبح ملائماً لحالة محددة سيُستخدم فيها. ITA330_F12_S1

10. ما المقصود بـ “نمذجة إجرائيات الأعمال ”؟ في هندسة النظم: هي تمثيل إجرائيات عمل المؤسسة بما يسمح بتحليلها وتحسينها (وتوثيقها أيضاً). • أكثر الطرق شيوعاً: مخطط تدفق العمل (Workflow Diagram). • يقوم بالعملية عادة محللو الأعمال (Business analysts) والمدراء الذين يتطلعون إلى تحسين كفاءة (efficiency) وجودة (quality) الإجرائيات. • قد تتطلب التحسينات التي جرى توصيفها استخدام تقانة المعلومات (وقد لا تتطلب ذلك). ITA330_F12_S1

11. بعض أدوات النمذجة التقليدية • مخطط تدفق الأعمال (Business Workflow). • مخطط علاقات الكيانات (Entity Relationship Diagram – ERD). • مخطط تدفق المعطيات (Data Flow Diagram – DFD). • قاموس المعطيات (Data Dictionary – DD). • أدوات توصيف الإجراءات (Process Description Tools). ITA330_F12_S1

12. مخطط تدفق أعمال ITA330_F12_S1

13. مخطط علاقات الكيانات ITA330_F12_S1

14. مخطط تدفق المعطيات Context diagram DFD for a grading system. ITA330_F12_S1

15. أدوات توصيف الإجراءات(Process Description Tools) • التصميم الوحدوي (Modular Design). • اللغة المهيكلة (Structured English). • جداول القرار (Decision Tables). • أشجار القرار (Decision Trees). ITA330_F12_S1

16. التصميم الوحدويModular Design • تعتمد على تراكيب من ثلاث بنى منطقية (تسمى أحياناً بنى تحكم) وتشكل كتل بناء الإجراء: • التسلسل (Sequence). • الاختيار (Selection). • التكرار (Iteration – looping). ITA330_F12_S1

17. اللغة المهيكلةStructured Language • يوصف الإجراء بصيغة نصية تحترم القواعد التالية: • استخدام بنى التحكم الأساسية الثلاث فقط (التسلسل والاختيار والتكرار). • تنسيق النص (باستخدام الإزاحة) لتسهيل القراءة. • استخدام عدد محدود من المفردات بما فيها تلك المعرفة في قاموس المعطيات وبعض المفردات لوصف قواعد المعالجة. ITA330_F12_S1

18. جداول القرارDecision Tables • جدول يبين كل التوليفات الممكنة من الشروط وما يقابلها من أفعال. ITA330_F12_S1 18

19. أشجار القرارDecision Trees • تمثيل بياني للشروط والأفعال الموجودة في جداول القرار. ITA330_F12_S1 19

20. مشكلات أدوات النمذجة السابقة • أين تظهر وجهة نظر الزبون؟ • تصعب قراءتها من قبل غير الاختصاصي (تتعامل غالباً مع تفاصيل فنية). • صعوبة ضمان التكامل (Integrity) والانسجام (Coherence) بين النماذج المختلفة. ITA330_F12_S1

21. العوامل المؤثرة على نجاح/فشل البرمجيات متى نقول عن مشروع برمجي إنه فاشل؟ بالرغم من تعدد وجهات النظر، يبقى رضى الزبون هو المعيار الأساسي، وعليه يمكن القول عن مشروع برمجي إنه مشروع فاشل إذا: • لم يلبِ المنتج البرمجي احتياجات الزبون • تأخر تسليم المنتج عن الموعد المتوقع أو المخطط له • تضمن المنتج عدداً هاماً من الأخطاء ITA330_F12_S1

22. معلومات إحصائية (1) • تبين الدراسات الإحصائية أن مشاريع البرمجيات هشة علمياً وعرضة للفشل أكثر من المشاريع الهندسية الأخرى. • أظهرت نتائج ابحاث أجرتها مجموعة Standish Group أن 31.1% من المشاريع البرمجية قد ألغيت قبل أن يُستكمل بناؤها، وأن 52.7% من المشاريع بلغت كلفتها 189% من الكلفة المتوقعة. • وقد أظهرت إحصائيات أخرى شملت شركات برمجيات بحجوم وأنماط مختلفة أننا: "...نواجه فشلاً في المشاريع البرمجية أكثر بكثير مما نتوقع، والأكثر من ذلك أنه لا يمكن التنبؤ بفشل المشاريع البرمجية، فهذا يحدث في كل الدول، في الشركات الكبيرة والصغيرة، في المؤسسات التجارية كما في المنظمات غير الربحية، وفي المؤسسات الحكومية وبغض النظر عن السمعة التي تتمتع بها تلك الشركات والمؤسسات..." ITA330_F12_S1

23. معلومات إحصائية (2) نتائج إحصاءات Standish Group (أجري البحث عام 2005): ITA330_F12_S1

24. أسباب فشل المشاريع البرمجية (Standish Group): ITA330_F12_S1

25. لمَ تتعرض المشاريع البرمجية للفشل؟ • مستوى نضج هندسة البرمجيات • طبيعة المنتج البرمجي (من حيث كونه مجرداً وغير ملموس) • تغير المتطلبات والمواصفات أثناء العمل • سوء إدارة الوقت • ضعف المهارات الإدارية • غياب منهجية العمل (دورة حياة المنتج البرمجي) او استخدام منهجية غير مناسبة. • غياب التوثيق أو ضعفه • سوء توصيف المتطلبات البرمجية • قصور الاختبارات • سوء إدارة الموارد البشرية للمشروع • عدم الاهتمام بإدارة الإصدارات والنسخ • قصور أو حتى تجاهل إدارة المخاطر. ITA330_F12_S1

26. تصنيف أسباب الفشل • أسباب جوهرية مرتبطة بالتعقيد الملازم للبرمجيات (من حيث كونها منتجات مجردة غير ملموسة). • أسباب طارئة: الصعوبات الناجمة عن الخبرات المتعلقة بإنتاج البرمجيات والتي يمكن إعادتها إلى: • التخطيط والإدارة • العامل البشري • الإجرائية (بما فيها لغة النمذجة وأدواتها). ITA330_F12_S1

27. الحقول ذات الصلة بالموضوع التخطيط (Business Planning) إدارة المشاريع (Project Management) إدارة الجودة (Quality Management) ITA330_F12_S1

28. تخطيط النظام1- مقدمة • دور التخطيط في مشاريع نظم المعلومات. • استراتيجية العمل: يجري تحديد استراتيجية العمل عبر إجرائيات متنوعة حيث تهتم مناهج وضع الاستراتيجيات بدراسة إجرائيات العمل الأساسية في المؤسسة بهدف وضع تصور مستقبلي على المدى البعيد لنمط وآلية العمل ومن ثم إعطاء الأولوية للمواضيع والمشكلات التي يمكن حلها باستخدام تقانات المعلومات. • استراتيجيات العمل في المؤسسات الصغيرة: تختار المؤسسات الصغيرة نظم المعلومات التي ترغب بتطويرها تبعاً لأكثر مشكلات العمل إلحاحاً. فإذا تغيرت بنية عمل المؤسسة أو تغيرت شروط العمل داخلها تضطر لتعديل نظم المعلومات الموجودة فيها من جديد.   • استراتيجيات العمل في المؤسسات الكبيرة: تقوم المؤسسات الكبيرة بصياغة المحيط وتشكيله تبعاً لاحتياجاتها الحالية. ITA330_F12_S1

29. تخطيط النظام2- طرق وضع الخطط • طرق وضع الخطط: • SWOT (اختصاراً للكلمات الأربع. Strengths, Weakness, Opportunities, Threats أي: القوة، الضعف، الفرص، التحديات) • استراتيجية المرونة VCM (Value Chain Model، أي نموذج سلسلة القيمة). • الطريقة BPR (Business Process Reengineering أي إعادة هندسة إجرائية العمل) • النموذج ISA (Information System Architecture، أي بنيان نظام المعلومات): لتقدير احتياجات المؤسسة من المعلومات • تشترك طرق التخطيط المذكورة كلها بخاصية هامة، فهي كلها تركز على واقعية الفعل (القيام بالفعل المطلوب فعلاً - (effectiveness بدلاً من التركيز على الفعالية (تنفيذ العمل بشكل صحيح - efficiency)، فحل المسألة الخطأ بطريقة فعالة لا يفيد بشيء. ITA330_F12_S1

30. العامل البشريالأطراف المعنية (Stakeholders) •  الطرف المعني:هو أي شخص (أو جهة) معني بالمشروع البرمجي بطريقة أو بأخرى، سواء كان سيتأثر بالنظام أم سيؤثر على تطويره أو استخدامه، ونميز هنا بين: • مالك النظام (System Owner) • المستخدمون • المطورون (محللون، مصممون، مبرمجون....). (ثمة أطراف أخرى: منافسون، شركاء...) ITA330_F12_S1

31. العامل البشريدوره وأثره • دور العامل البشري في فشل البرمجيات: • من ناحية الزبون: • لا تُفهم كل احتياجات الزبون أو يُفهم بعضها خطأ. • تتغير متطلبات الزبون بتواتر كبير. • الزبائن غير مهيئين لتقديم موارد كافية للمشروع. • لا يريد المستخدمون أن يتعاونوا مع المطورين. • للزبائن تصورات وتوقعات غير منطقية. • لم يعد النظام مفيداً للزبائن. • من ناحية المطورين: قد تفشل المشاريع أيضاً لأن المطورين ليسوا على المستوى المطلوب لأداء المهمة. ITA330_F12_S1

32. مهارات محلل الأنظمة • معرفة عملية بتقانات المعلومات. • خبرة بالبرمجة ولغاتها. • معرفة عامة بالأعمال. • مهارات في حل المشكلات. • مهارات شخصية وقدرة على التواصل مع الآخرين (Interpersonal Communication Skills). • المرونة والقدرة على التأقلم مع بيئات عمل مختلفة. • احترام الأخلاق المهنية. ITA330_F12_S1

33. الإجرائية؟ ITA330_F12_S1

34. تطوير البرمجيات - نظرياً • نظرياً، يجري تطوير البرمجيات بدءاً من الصفر وبشكل تسلسلي. ITA330_F12_S1

35. دورة حياة المنتج البرمجي(Software Development Life Cycle – SDLC) ITA330_F12_S1

36. دورة حياة المنتج البرمجي • التخطيط (Planning) • لمَ نريد بناء النظام؟ • التحليل (Analysis) • من هم المستخدمون؟ • ما هي المتطلبات (Requirements)؟ • ما هو نطاق النظام (Scope)؟ • التصميم (Design) • كيف سيعمل النظام؟ • التحقيق (Implementation) • تسليم النظام (System Delivery). • كيف ندعم المستخدمين؟ ITA330_F12_S1

37. المرحلة المنتج خطة المشروع مقترح النظام توصيف التصميم النظام الجديد وخطة صيانته التخطيط التحليل التصميم التحقيق المراحل الأساسية ومخرجاتها ITA330_F12_S1

38. تطوير البرمجيات - عملياً • يبدو تطوير البرمجيات في الواقع مختلفاً تماماً عن التوصيف النظري وأكثر فوضوية مما هو متوقع. • يرتكب إخصائيو تطوير البرمجيات العديد من الأخطاء. • تتغير متطلبات الزبون خلال فترة تطوير المنتج البرمجي. • يُعتبر المنتج البرمجي نموذجاً للعالم الحقيقي الذي يتغير باستمرار. ITA330_F12_S1

39. ما هي الإجرائية البرمجية؟ • مجموعة من الأنشطة المرتبة هدفها النهائي تطوير منتج برمجي جديد أو تحسين منتج موجود. • تتمحور كل الإجرائيات البرمجية حول أنشطة عامة أساسية: • التوصيف (Specification): ما يجب أن يؤديه النظام والقيود المفروضة عليه. • التطوير (Development): عملية إنتاج النظام البرمجي. • التحقق (Validation): التأكد من أن النظام يحقق ما يريده الزبون. • التحسين (Evolution): تغيير النظام استجابة لمتطلبات متغيرة. • نموذج الإجرائية هو تمثيل مجرد للإجرائية يصفها من زاوية نظر معينة. • تسلسل الأنشطة (Workflow perspective). • تدفق المعلومات (Data-flow perspective). • من يفعل ماذا (Role/action perspective). ITA330_F12_S1

40. دورة الحياة والإجرائية • تقسم دورة الحياة حياة نظام المعلومات إلى مرحلتين أساسيتين: تطوير النظام، وتشغيل النظام ودعمه. • منهجية تطوير النظام هي إجرائية صورية دقيقة تعرِّف مجموعة من الأنشطة (Activities) والطرق (Methods) والخبرات (Best practices) والمخرجات (Deliverables) والأدوات المؤتمتة (Automated Tools) التي يجب على مطوري النظم ومدراء المشاريع اتباعها لتطوير نظم المعلومات والبرمجيات وصيانتها. ITA330_F12_S1

41. مكونات الإجرائية • تتضمن الإجرائية مجموعة منسجمة من النماذج (Models) والأدوات (Tools) والتقنيات (Techniques). ITA330_F12_S1

42. النماذج • تمثيل لجانب مهم من العالم الحقيقي لكن غير مطابق له. • تعتمد على التجريد للفصل بين الجوانب المختلفة. • تعتمد على استخدام المخططات البيانية. • تساعد على إعداد الخطط (فنياً ومالياً). • بعض النماذج المستخدمة في تطوير النظم: • لمكونات النظام: Flowchart, DFD, ERD, Structure chart, Class Diagram... • لإدارة إجرائية التطوير: Gantt Chart، Financial Analysis Models... ITA330_F12_S1

43. الأدوات • برمجيات تساعد على إنشاء النماذج. • تتنوع من برامج الرسم البسيطة إلى الأدوات المساندة في هندسة البرمجيات (CASE Tools) إلى برمجيات إدارة المشاريع. • أمثلة لبعض الأدوات المستخدمة: معالجات الرسوم، معالجات النصوص، بيئات التطوير المتكاملة (IDE)، أدوات الهندسة العكسية، مولدات الرماز... ITA330_F12_S1

44. الأدوات المساندة في هندسة البرمجياتCASE Tools الأدوات المساندة هي برمجيات حاسوبية تُستخدم لأتمتة عمليات تحليل ورسم نماذج النظام أو تسهيلها كما تساعد على ترجمة النماذج وتحويلها إلى تطبيقات برمجية. • الهندسة الأمامية (Forward Engineering) وتعني أن يقوم محلل النظام ببناء نماذجه (من الصفر أو باستخدام قوالب معدة مسبقاً) ليجري فيما بعد تحويل هذه النماذج إلى رماز (Code) لتطبيقات برمجية. • الهندسة العكسية (Reverse Engineering) وتعني أن تقوم الأداة المساندة بقراءة رماز تطبيق برمجي موجود لتحويله إلى نماذج تمثل النظام والتي يمكن لمحلل النظم تنقيحها وتحسينها. ITA330_F12_S1

45. بيئات التطوير بيئة تطوير التطبيقات هي عبارة عن أداة برمجية متكاملة توفر التسهيلات اللازمة لتطوير تطبيقات برمجية جديدة ذات جودة عالية وبأزمنة قصيرة (تدعى عادة ADE أو IDE). من أمثلة التسهيلات هذه: • لغات البرمجة ومترجماتها (أو مفسراتها) • أدوات بناء الواجهات • أدوات الاختبار • أدوات إدارة الإصدارات • أدوات إعداد نصوص المساعدة (Help authoring). يمكن أن يكون لبعض هذه البيئات واجهات اتصال مع أدوات مساندة في هندسة البرمجيات أو أن تتضمن بعضاً من إمكاناتها. ITA330_F12_S1

46. التقنيات • مجموعة من التوجيهات والنصائح التي تساعد المحلل على إكمال مهمات تطوير النظام. • يمكن أن تكون بصيغة نصائح عامة أو توجيهات على شكل خطوات متسلسلة. • أمثلة: تقنيات إجراء المقابلات، تقنيات تصميم قواعد المعطيات، تقنيات إجراء الاختبارات... ITA330_F12_S1

47. إدارة المشروع وإدارة الإجرائية • إدارة المشروع (Project Management): وتشمل تعريف المشروع، التخطيط له، توجيه العمل ومراقبة التنفيذ بهدف تطوير نظام مقبول ضمن قيود الزمن والموارد المتاحة. • إدارة الإجرائية (Process management): هي عملية مستمرة تُعنى بتحديد الإجرائية (أو المنهجية – Methodology) وتحسينها وتطبيقها على كل مشاريع التطوير البرمجية. ITA330_F12_S1

48. الإجرائية (Process)نموذج استحقاق الأهلية • CMM: Capability Maturity Model • يمثل نموذج استحقاق الأهلية (CMM) طريقة شائعة لتقييم إجرائية التطوير وتحسينها. • طريقة العمل: يعتمد النموذج CMM بشكل رئيسي على استمارة أسئلة يجب أن تملأها المؤسسة ليتم بعد ذلك التحقق منها والتأكد من صحة ما يرد فيها لتعطى المؤسسة مستوى من مستويات النموذج CMM الخمسة، التي يعبر فيها المستوى الأعلى عن نضج وأهلية أفضل لإجرائية التطوير. ITA330_F12_S1

49. مستويات النموذج CMM • المستوى 5 الأمثلية : (Optimizing) • يجري تحسين إجرائية التطوير باستمرار. • تحسين طريقة تعديل الإجرائية. • المستوى 4 مُدارة: (Managed) • تستخدم مقاييس للتحكم بإجرائية التطوير. • تحسين مقاييس الإجرائية. • المستوى 3 معرّفة: (Defined) • يجري إتباع إجرائيات إدارية وهندسية معرفة ومنظمة. • تحسين تعريف الإجرائية. • المستوى 2 مكِّررة: (Repeatable) • إدارة مشاريع مكرَّرة • إمكانية تقدير الوقت والجهد اللازمين لمشاريع متشابهة. • تحسين مستوى تخصص الإجرائية. • المستوى 1 بدائية: (Initial) • إجرائية غير ثابتة وغير واضحة تعتمد على الفريق الحالي. ITA330_F12_S1

50. المستوى 5 - الأمثلة تحسين إدارة عملية تعديل الإجرائية تحسين إجرائية التطوير باستمرار المستوى 4 - مدارة تحسين قياسات الإجرائية يجري اتباع إجرائيات إدارية وهندسية معرفة ومنظمة المستوى 3 - معرفة تحسين تعريف الإجرائية يجري اتباع إجرائيات إدارية وهندسية معرفة ومنظمة المستوى 2 - مكررة إدارة مشاريع مكررة، يمكن تقدير الوقت والجهد لها. المستوى 1 - بدائية إجرائية غير مضبوطة وتعتمد على فريق العمل الحالي مستويات النضج في النموذج CMM مستويات النموذج CMM ITA330_F12_S1