نهج أطر المشكلات
تحليل المشكلات أو منهجية أطر المشكلات هو أسلوب لتحليل متطلبات البرمجيات . وقد طوره مستشار البرمجيات البريطاني مايكل أ. جاكسون في التسعينيات.
تاريخ
طُرح مفهوم إطار المشكلة لأول مرة من قِبل جاكسون في كتابه " متطلبات ومواصفات البرمجيات " (1995) وفي عدد من المقالات في مختلف المجلات المتخصصة في هندسة البرمجيات. وقد وُصف هذا المفهوم بشكل كامل في كتابه " إطار المشكلة: تحليل وهيكلة مشاكل تطوير البرمجيات" (2001).
عُقدت جلسة حول أطر المشكلات ضمن فعاليات ورشة العمل الدولية التاسعة حول هندسة المتطلبات : أسس جودة البرمجيات (REFSQ)، التي عُقدت في كلاغنفورت/فيلدن، النمسا، عام 2003. [ 1 ] كما عُقدت ورشة العمل الدولية الأولى حول تطبيقات وتطورات أطر المشكلات [ 2 ] ضمن فعاليات مؤتمر ICSE'04 الذي عُقد في إدنبرة، اسكتلندا. ومن نتائج تلك الورشة إصدار عدد خاص عام 2005 حول أطر المشكلات في المجلة الدولية لتكنولوجيا المعلومات والبرمجيات .
عُقدت ورشة العمل الدولية الثانية حول تطبيقات وتطورات أطر حل المشكلات [ 3 ] ضمن فعاليات المؤتمر الدولي لهندسة البرمجيات (ICSE) لعام 2006 في شنغهاي، الصين. وعُقدت ورشة العمل الدولية الثالثة حول تطبيقات وتطورات أطر حل المشكلات (IWAAPF) [ 4 ] ضمن فعاليات المؤتمر الدولي لهندسة البرمجيات (ICSE) لعام 2008 في لايبزيغ، ألمانيا. وفي عام 2010، استُبدلت ورش عمل IWAAPF بورشة العمل الدولية حول تطبيقات وتطورات التوجه نحو حل المشكلات (IWAAPO). وسّعت IWAAPO نطاق تركيز ورش العمل ليشمل مناهج بديلة ومُكمّلة لتطوير البرمجيات، تشترك جميعها في التركيز على تحليل المشكلات. [ 5 ] وعُقدت ورشة عمل IWAAPO-2010 ضمن فعاليات المؤتمر الدولي لهندسة البرمجيات (ICSE) لعام 2010 في كيب تاون، جنوب أفريقيا. [ 6 ]
اليوم يتم إجراء البحوث حول نهج أطر المشكلة في عدد من الجامعات، وأبرزها في الجامعة المفتوحة في المملكة المتحدة كجزء من موضوع البحث الخاص بها بعنوان "ربط هياكل المشكلة والحل" [ 7 ] [ 8 ].
تم تعميم الأفكار الواردة في منهجية أطر المشكلات لتشمل مفاهيم التطوير الموجه نحو المشكلات (POD) والهندسة الموجهة نحو المشكلات (POE)، والتي تُعد هندسة البرمجيات الموجهة نحو المشكلات (POSE) فئة فرعية منها. وقد عُقدت ورشة العمل الدولية الأولى حول التطوير الموجه نحو المشكلات في يونيو 2009.
ملخص
الفلسفة الأساسية
تحليل المشكلات أو منهجية أطر المشكلات هو منهج - مجموعة من المفاهيم - يُستخدم عند جمع المتطلبات ووضع المواصفات لبرامج الحاسوب. وتختلف فلسفته الأساسية اختلافًا ملحوظًا عن مناهج متطلبات البرمجيات الأخرى، إذ تؤكد على ما يلي:
- إن أفضل طريقة للتعامل مع تحليل المتطلبات هي من خلال عملية تفكيك متوازٍ - وليس هرمي - لمتطلبات المستخدم. [ 9 ]
- تتعلق متطلبات المستخدم بالعلاقات في العالم الحقيقي - مجال التطبيق - وليس بنظام البرمجيات أو حتى واجهة نظام البرمجيات.
من المفيد أكثر إدراك أن الحل يكمن في الحاسوب وبرمجياته، بينما تكمن المشكلة في العالم الخارجي. ... تستطيع الحواسيب تقديم حلول لهذه المشكلات لأنها متصلة بالعالم الخارجي. [ 10 ]
العبرة واضحة: لدراسة وتحليل أي مشكلة، يجب التركيز على دراسة وتحليل بيئة المشكلة بعمق، وفي تحقيقاتك، يجب أن تكون مستعدًا للابتعاد قليلًا عن جهاز الكمبيوتر. ... [في مشكلة تحويل المكالمات...] عليك وصف ما هو موجود - الأشخاص والمكاتب والإجازات وانتقال المكاتب وتفويض المسؤوليات - وما هي التأثيرات [في بيئة المشكلة] التي ترغب أن يحققها النظام - يجب أن تصل المكالمات إلى رقم (أ) إلى (أ)، و [عندما يكون (ب) في إجازة، ويعمل (ج) مؤقتًا على مكتب (د)] يجب أن تصل المكالمات إلى رقم (ب) أو (ج) إلى (ج). [ 11 ]
لا يظهر أي من هذه العناصر في واجهة الحاسوب... بل هي جميعها أعمق من ذلك بكثير. [ 12 ]
يستخدم هذا النهج ثلاث مجموعات من الأدوات المفاهيمية.
أدوات لوصف المشكلات المحددة
تشمل المفاهيم المستخدمة لوصف مشاكل محددة ما يلي: الظواهر (بأنواعها المختلفة، بما في ذلك الأحداث )، وسياق المشكلة ، ومجال المشكلة ، ومجال الحل ( المعروف أيضًا باسم الآلة )، والظواهر المشتركة (التي توجد في واجهات المجال )، ومتطلبات المجال (التي توجد في مجالات المشكلة) والمواصفات (التي توجد عند واجهة مجال المشكلة:الآلة).
الأدوات الرسومية لوصف المشكلات هي مخطط السياق ومخطط المشكلة .
أدوات لوصف فئات المشكلات (أطر المشكلات)
يتضمن منهج أطر المشكلات مفاهيم لوصف فئات المشكلات. وتُسمى فئة المشكلات المعترف بها إطار المشكلة (وهو مشابه تقريبًا لنمط التصميم ).
في إطار المشكلة، تُعطى المجالات أسماءً عامة وتُوصَف من حيث خصائصها المهمة. على سبيل المثال، يمكن تصنيف المجال إلى مجال سببي (يتفاعل بطريقة حتمية يمكن التنبؤ بها مع الأحداث) أو مجال قابل للتوجيه (يمكن توجيهه، أو طلبه، للاستجابة للأحداث، ولكن لا يُتوقع منه دائمًا أن يتفاعل مع الأحداث بطريقة حتمية يمكن التنبؤ بها). (عادةً ما يتكون المجال القابل للتوجيه من الأفراد).
الأداة الرسومية لتمثيل إطار المشكلة هي مخطط الإطار . يشبه مخطط الإطار بشكل عام مخطط المشكلة باستثناء بعض الاختلافات الطفيفة - حيث أن المجالات لها أسماء عامة، بدلاً من أسماء محددة؛ ويتم وضع تعليقات توضيحية على المستطيلات التي تمثل المجالات للإشارة إلى نوع المجال (سببي أو قابل للتحكم).
قائمة بفئات المشاكل المعترف بها (أطر المشاكل)
تضمنت المجموعة الأولى من أطر المشكلات التي حددها جاكسون ما يلي:
- السلوك المطلوب
- السلوك المطلوب
- عرض المعلومات
- قطع العمل البسيطة
- تحويل
وفي وقت لاحق، قام باحثون آخرون بوصف أو اقتراح أطر مشاكل إضافية.
وصف المشاكل
سياق المشكلة
تعتبر عملية تحليل المشكلات تطبيق البرمجيات بمثابة آلة برمجية . ويهدف مشروع تطوير البرمجيات إلى تغيير سياق المشكلة من خلال إنشاء آلة برمجية وإضافتها إلى سياق المشكلة، حيث ستؤدي إلى تحقيق تأثيرات مرغوبة معينة.
يُطلق على الجزء المحدد من سياق المشكلة الذي يثير الاهتمام فيما يتعلق بمشكلة معينة - الجزء المحدد من سياق المشكلة الذي يشكل سياق المشكلة - اسم مجال التطبيق .
بعد الانتهاء من مشروع تطوير البرمجيات، وإدراج جهاز البرمجيات في سياق المشكلة، سيحتوي سياق المشكلة على كلٍ من مجال التطبيق والجهاز. عند هذه النقطة، سيبدو الوضع على النحو التالي:

يتضمن سياق المشكلة الجهاز ومجال التطبيق. واجهة الجهاز هي المكان الذي يلتقي فيه الجهاز ومجال التطبيق ويتفاعلان.
يمكن توضيح الموقف نفسه في نوع مختلف من المخططات، وهو مخطط السياق ، على النحو التالي:

مخطط السياق
تتمثل المهمة الأولى لمحلل المشكلات في فهم المشكلة فهماً حقيقياً. وهذا يعني فهم السياق الذي تظهر فيه المشكلة، وهذا يعني رسم مخطط سياقي.
إليكم وصف جاكسون لفحص سياق المشكلة، وفي هذه الحالة سياق بناء جسر:
- أنت مهندس تخطط لبناء جسر فوق نهر. فتزور الموقع. تقف على ضفة النهر، وتنظر إلى الأرض المحيطة وحركة الملاحة النهرية. تشعر بمدى انكشاف المكان، وقوة الرياح، وسرعة جريان النهر. تنظر إلى الضفة وتتساءل عن الصدوع التي سيكشف عنها المسح الجيولوجي في التضاريس الصخرية. تتخيل في ذهنك الجسر الذي ستبنيه. ( متطلبات ومواصفات البرمجيات : "سياق المشكلة")
يجب على المحلل الذي يحاول فهم مشكلة في تطوير البرمجيات أن يمر بنفس عملية مهندس الجسور. يبدأ بفحص مجالات المشكلة المختلفة في مجال التطبيق. تشكل هذه المجالات السياق الذي يجب أن تتلاءم معه الآلة المخطط لها. ثم يتخيل كيف ستتلاءم الآلة مع هذا السياق. وبعد ذلك، يرسم مخططًا سياقيًا يوضح رؤيته لسياق المشكلة مع الآلة المثبتة فيه.
يُظهر مخطط السياق مجالات المشاكل المختلفة في مجال التطبيق، وعلاقاتها، والجهاز وعلاقاته ببعض مجالات المشاكل. إليك شكل مخطط السياق.

يوضح هذا الرسم التخطيطي ما يلي:
- الآلة المراد بناؤها. يساعد الإطار الداكن على تحديد المربع الذي يمثل الآلة.
- مجالات المشكلة ذات الصلة بالمشكلة.
- تمثل الخطوط المتصلة واجهات النطاقات - وهي المناطق التي تتداخل فيها النطاقات وتتشارك في الظواهر المشتركة.
المجال هو ببساطة جزء من العالم الذي نهتم به. وهو يتكون من ظواهر - أفراد، أحداث، حالات، علاقات، وسلوكيات.
واجهة النطاق هي منطقة تتصل فيها النطاقات وتتواصل فيما بينها. واجهات النطاقات ليست تدفقات بيانات أو رسائل. الواجهة هي مكان تتداخل فيه النطاقات جزئيًا، بحيث تكون الظواهر الموجودة في الواجهة ظواهر مشتركة - أي أنها موجودة في كلا النطاقين المتداخلين.
يمكنك تخيل النطاقات ككائنات بدائية وحيدة الخلية (مثل الأميبا). فهي قادرة على مدّ أجزاء من أجسامها على شكل أقدام كاذبة. تخيل أن كائنين من هذا النوع يمدّان أقدامهما الكاذبة باتجاه بعضهما البعض كما لو كانا يتصافحان، وأن المادة الخلوية في منطقة التلامس تختلط، بحيث تصبح جزءًا من كليهما. هذه هي الواجهة.
في الرسم التخطيطي التالي، يمثل X الواجهة بين المجالين A و B. الأفراد الموجودون أو الأحداث التي تحدث في X، موجودة أو تحدث في كل من A و B.

قد تبدو الأفراد والحالات والأحداث المشتركة بشكل مختلف بالنسبة للمجالات التي تشترك فيها. لنأخذ على سبيل المثال واجهة بين جهاز كمبيوتر ولوحة مفاتيح. عندما يرى مجال لوحة المفاتيح حدثًا ما، مثل " يضغط مستخدم لوحة المفاتيح على مفتاح المسافة"، سيرى الكمبيوتر نفس الحدث حيث يظهر البايت السداسي العشري "20" في مخزن الإدخال المؤقت.
مخططات المسائل
الأداة الأساسية التي يستخدمها محلل المشكلات لوصف المشكلة هي مخطط المشكلة . إليك مخطط مشكلة عام.

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

قد تكون هذه المشكلة جزءًا من نظام حاسوبي في مستشفى. في المستشفى، يُوصل المرضى بأجهزة استشعار قادرة على رصد وقياس درجة حرارتهم وضغط دمهم. المطلوب هو تصميم جهاز يعرض معلومات عن حالة المريض على لوحة في غرفة التمريض.
اسم المتطلب هو "عرض حالة المريض". تشير علامة التلدة (~) إلى أن المتطلب يتعلق بعلاقة أو تطابق بين شاشة العرض وحالة المريض. يشير رأس السهم إلى أن مرجع المتطلب المرتبط بمجال شاشة العرض هو أيضًا قيد متطلب. هذا يعني أن المتطلب يتضمن شرطًا يجب أن تستوفيه شاشة العرض. باختصار، المتطلب هو أن تعرض شاشة العرض معلومات مطابقة لحالة المرضى ودقيقة.
وصف فئات المشاكل
أطر المشكلة
إطار المشكلة هو وصف لفئة محددة من المشكلات، حيث يكون لهذه الفئة حل معروف. بمعنى آخر، تُعد أطر المشكلات أنماطًا للمشكلات.
لكل إطار مشكلة مخطط إطار خاص به . يشبه مخطط الإطار في جوهره مخطط المشكلة، ولكنه بدلاً من إظهار مجالات ومتطلبات محددة، يُظهر أنواع المجالات وأنواع المتطلبات؛ وللمجالات أسماء عامة، وليست محددة؛ ويتم وضع تعليقات توضيحية على المستطيلات التي تمثل المجالات للإشارة إلى نوع المجال (سببي أو قابل للتحكم).
إطارات متغيرة
في إطار دراسة أطر المشكلات، ناقش جاكسون متغيرات أطر المشكلات الخمسة الأساسية التي حددها. وعادةً ما يضيف المتغير مجالاً إلى سياق المشكلة.
- يُقدّم نوع الوصف المتغير مجالًا معجميًا للوصف
- يُدخل أحد متغيرات المُعامل مُعاملًا
- يُدخل نوع الاتصال نطاق اتصال بين الجهاز والنطاق المركزي الذي يتفاعل معه.
- لا يُدخل متغير التحكم مجالًا جديدًا؛ بل يُغير خصائص التحكم في ظواهر الواجهة.
مخاوف المشاكل
يناقش جاكسون أيضاً أنواعاً معينة من المخاوف التي تنشأ عند العمل مع أطر المشكلات.
قلق خاص
- تجاوز
- التهيئة
- مصداقية
- الهويات
- اكتمال
مخاوف تتعلق بالتكوين
- أوصاف قابلة للمقارنة
- تناسق
- أسبقية
- تدخل
- التزامن
أطر المشكلات المعترف بها
تضمنت أطر المشكلات الأولى التي حددها جاكسون ما يلي:
- السلوك المطلوب
- السلوك المطلوب
- عرض المعلومات
- قطع العمل البسيطة
- تحويل
وفي وقت لاحق، قام باحثون آخرون بوصف أو اقتراح أطر مشاكل إضافية.
إطار مشكلة السلوك المطلوب
الفكرة البديهية وراء إطار هذه المشكلة هي:
- هناك جزء من العالم المادي يجب التحكم في سلوكه بحيث يفي بشروط معينة. تكمن المشكلة في بناء آلة تفرض هذا التحكم.

إطار مشكلة السلوك الموجه
الفكرة البديهية وراء إطار هذه المشكلة هي:
- هناك جزء من العالم المادي يجب التحكم في سلوكه وفقًا لأوامر يصدرها مشغل. تكمن المشكلة في بناء آلة تستقبل أوامر المشغل وتفرض التحكم بناءً عليها.

إطار مشكلة عرض المعلومات
الفكرة البديهية وراء إطار هذه المشكلة هي:
- هناك جزء من العالم المادي نحتاج باستمرار إلى معلومات محددة حول حالته وسلوكه. تكمن المشكلة في بناء آلة تحصل على هذه المعلومات من العالم وتقدمها في المكان المطلوب وبالشكل المطلوب.

إطار مشكلة قطع العمل البسيطة
الفكرة البديهية وراء إطار هذه المشكلة هي:
- هناك حاجة إلى أداة تُمكّن المستخدم من إنشاء وتعديل فئة معينة من النصوص أو الكائنات الرسومية القابلة للمعالجة الحاسوبية، أو ما شابهها من هياكل، بحيث يمكن نسخها أو طباعتها أو تحليلها أو استخدامها بطرق أخرى لاحقًا. يكمن التحدي في بناء جهاز قادر على القيام بهذه المهمة.

إطار مشاكل التحويل
الفكرة البديهية وراء إطار هذه المشكلة هي:
- توجد بعض ملفات الإدخال القابلة للقراءة بواسطة الحاسوب، والتي يجب تحويل بياناتها لإنتاج ملفات إخراج محددة. يجب أن تكون بيانات الإخراج بتنسيق معين، ويجب استخلاصها من بيانات الإدخال وفقًا لقواعد محددة. تكمن المشكلة في بناء جهاز يُنتج المخرجات المطلوبة من المدخلات.

تحليل المشكلة وعملية تطوير البرمجيات
عندما يتم دمج تحليل المشكلات في عملية تطوير البرمجيات ، تبدأ دورة حياة تطوير البرمجيات بمحلل المشكلات، الذي يدرس الوضع و:
- إنشاء مخطط سياقي
- يجمع قائمة بالمتطلبات ويضيف شكلاً بيضاوياً للمتطلبات إلى مخطط السياق، مما يُنشئ مخططاً شاملاً للمشكلة. (مع ذلك، في كثير من الحالات، قد يكون إنشاء مخطط شامل للمشكلة غير عملي أو غير مفيد: إذ سيحتوي المخطط على عدد كبير جداً من مراجع المتطلبات المتداخلة، مما يجعله غير عملي).
- يُفكك هذا الأسلوب المسألة الشاملة ومخطط المسألة إلى مسائل أبسط ومخططات مسائل أبسط. هذه المسائل هي إسقاطات ، وليست مجموعات جزئية، من المخطط الشامل.
- يستمر في تجزئة المشكلات حتى تصبح كل مشكلة بسيطة بما يكفي لتُعتبر مثالاً على إطار مشكلة معروف. يتضمن وصف كل مشكلة فرعية وصفًا لواجهات المواصفات الخاصة بالآلة المراد بناؤها.
عند هذه المرحلة، يكون تحليل المشكلة - أو تفكيكها - قد اكتمل. الخطوة التالية هي عكس العملية وبناء نظام البرمجيات المطلوب من خلال عملية تركيب الحلول .
لا تزال عملية تكوين الحلول غير مفهومة تمامًا، وهي موضوع بحثي رئيسي. وبالاستناد إلى ما ورد في متطلبات ومواصفات البرمجيات ، يمكننا أن نفترض أن عملية تطوير البرمجيات ستستمر مع المطورين، الذين سيقومون بما يلي:
- يتم دمج مواصفات الآلات الفرعية المتعددة في مواصفات آلة واحدة متكاملة: مواصفات لآلة برمجية تلبي جميع متطلبات العميل. هذه عملية معقدة، إذ قد تُثير عملية الدمج مشاكل تتطلب حلولاً.
- قم بتنفيذ الجهاز المتكامل من خلال اتباع عملية البرمجة/الاختبار/النشر التقليدية.
أساليب مماثلة
هناك بعض الأفكار الأخرى لتطوير البرمجيات التي تشبه تحليل المشكلات في بعض النواحي.
- يتشابه مفهوم نمط التصميم مع مفهوم جاكسون لإطار المشكلة. ويكمن الاختلاف في أن نمط التصميم يُستخدم لتحديد ومعالجة مشكلات التصميم (غالبًا مشكلات التصميم في لغات برمجة كائنية التوجه محددة مثل C++ أو Java) بدلاً من تحديد ومعالجة مشكلات المتطلبات. علاوة على ذلك، يتمثل أحد الاختلافات في أن أنماط التصميم تغطي الحلول، بينما تُمثل المشكلات في أطر المشكلات . مع ذلك، تميل أنماط التصميم أيضًا إلى مراعاة النتائج الدلالية غير الأصلية للغة البرمجة التي ستُنفذ بها. لذا، يتمثل اختلاف آخر في أن أطر المشكلات هي تدوين وصفي أصلي لمجال المشكلات، بينما تُعد أنماط التصميم بمثابة قائمة بالديون التقنية التي تركها مطورو اللغة.
- يهتم البرمجة الموجهة نحو الجوانب (AOP)، والمعروفة أيضًا باسم تطوير البرمجيات الموجهة نحو الجوانب (AOSD)، بالتفكيك المتوازي، الذي يعالج ما يسميه مؤيدو AOP بالجوانب أو الاهتمامات المتداخلة . وتتناول AOP اهتمامات أقرب إلى مرحلة التصميم وتوليد الكود منها إلى مرحلة تحليل المتطلبات.
- انتقلت منهجية البرمجة الموجهة نحو الجوانب (AOP) إلى رموز هندسة المتطلبات، مثل معيار ITU-T Z.151 لتدوين متطلبات المستخدم (URN). في URN، تُطبَّق منهجية AOP على جميع العناصر المقصودة. كما يمكن تطبيقها على نماذج المتطلبات التي تستخدم أطر المشكلات كأداة استدلالية. تسمح نماذج URN، التي تعتمد على التفكير القائم على أطر المشكلات والمتداخلة مع الجوانب، بإدراج التكتيكات المعمارية في نموذج المتطلبات.
- كتاب مارتن فاولر " أنماط التحليل" يشبه إلى حد كبير تحليل المشكلات في بحثه عن الأنماط. إلا أنه لا يقدم في الواقع منهجاً جديداً لتحليل المتطلبات. كما أن مفهوم التفكيك المتوازي - الذي يُعدّ بالغ الأهمية لتحليل المشكلات - ليس جزءاً من أنماط التحليل التي يقدمها فاولر.
- قام جون جي. هول ولوسيا رابانوتي، بالتعاون مع جاكسون، بتطوير إطار هندسة البرمجيات الموجهة نحو حل المشكلات (POSE) [ 13 ] ، والذي يشترك في أسس أطر حل المشكلات. ومنذ عام 2005، قام هول ورابانوتي بتوسيع نطاق POSE ليشمل هندسة البرمجيات الموجهة نحو حل المشكلات (POE)، والتي توفر إطارًا لتصميم البرمجيات، بما في ذلك نموذج عملية التطوير والتصميم القائم على ضمان الجودة [ 14 ] ، ويمكن توسيع نطاقها لتشمل مشاريع تضم العديد من أصحاب المصلحة وتجمع بين تخصصات هندسية متنوعة مثل البرمجيات والتعليم [ 15 ] .
مراجع
- ↑ ورشة العمل الدولية التاسعة حول هندسة المتطلبات: أساس جودة البرمجيات (REFSQ) التي عقدت في كلاغنفورت/فيلدن، النمسا في عام 2003.
- ↑ ورشة العمل الدولية الأولى حول التطبيقات والتطورات في أطر المشكلات
- ↑ ورشة العمل الدولية الثانية حول التطبيقات والتطورات في أطر المشكلات، مؤرشفة بتاريخ 19 أغسطس 2007 على موقع Wayback Machine
- ↑ "ورشة العمل الدولية الثالثة حول التطبيقات والتطورات في أطر المشكلات" . مؤرشفة من الأصل بتاريخ 24-12-2010 . تم الاطلاع عليها بتاريخ 19-06-2010 .
- ↑ ورشة العمل الدولية حول تطبيقات وتطورات منهجية حل المشكلات، مؤرشفة بتاريخ 11 يناير 2011 على موقع Wayback Machine
- ↑ "IWAAPO-2010" . مؤرشف من الأصل بتاريخ 28 يناير 2010. تم الاطلاع عليه بتاريخ 19 يونيو 2010 .
- ↑ موضوع بحثي حول ربط هياكل المشكلة والحل .
- ↑ على سبيل المثال: "ربط متطلبات البرمجيات وهياكلها باستخدام أطر المشكلات" بقلم هول، جي جي؛ جاكسون، إم؛ لاني، آر سي؛ نسيبة، بي؛ رابانوتي، إل، في وقائع المؤتمر الدولي المشترك لهندسة المتطلبات التابع لمعهد مهندسي الكهرباء والإلكترونيات (2002)، الصفحات 137-144
- ↑ جاكسون، مايكل (1995). "تفكيك المشكلة لإعادة الاستخدام". ص 1، 2.
- ↑ جاكسون، مايكل (2001). أطر المشكلة . أديسون-ويسلي. ص 3، 4.
- ↑ جاكسون، مايكل (2001). أطر المشكلة . أديسون-ويسلي. ص 9.
- ↑ جاكسون، مايكل (2001). أطر المشكلة . أديسون-ويسلي. ص 9، 10.
- ↑ جي جي هول، إل رابانوتي، وإم جاكسون. هندسة البرمجيات الموجهة نحو حل المشكلات: حل مشكلة التحكم في موجه الحزم. معاملات IEEE في هندسة البرمجيات، 2008. doi : 10.1109/TSE.2007.70769 .
- ↑ جي جي هول و إل رابانوتي. التصميم القائم على ضمان الجودة. في وقائع المؤتمر الدولي الثالث حول تطورات هندسة البرمجيات. 2008.
- ↑ ل. رابانوتي وج. ج. هول. تصميم برنامج ماجستير فلسفة بدوام جزئي عبر الإنترنت. في وقائع المؤتمر الدولي الرابع حول تطبيقات وخدمات الإنترنت والويب. مطبعة IEEE، 24-28 مايو 2009.
روابط خارجية
- http://mcs.open.ac.uk/mj665/ هي الصفحة الرئيسية لمايكل أ. جاكسون
- يحتوي الموقع http://www.jacksonworkbench.co.uk/stevefergspages/pfa/index.html على أوراق بحثية ومقالات حول منهجية أطر المشكلات
- تحليل النظم
- هندسة النظم
- متطلبات البرامج
