ما هو مدرج في دورة حياة البرنامج. دورة حياة البرمجيات

يجب أن نبدأ بالتعريفدورة حياة البرمجيات(نموذج دورة حياة البرنامج) هي فترة زمنية تبدأ من اللحظة التي يتم فيها اتخاذ قرار لإنشاء منتج برمجي وتنتهي في اللحظة التي يتم فيها سحبه تمامًا من الخدمة. هذه الدورة هي عملية بناء وتطوير البرمجيات.

نماذج دورة حياة البرمجيات

يمكن تمثيل دورة الحياة في شكل نماذج. الأكثر شيوعًا حاليًا هي:المتتالية, تدريجي (نموذج مرحلي مع تحكم وسيط ) و حلزونينماذج دورة الحياة.

نموذج تتالي

نموذج تتالي(م. نموذج الشلال) هو نموذج لعملية تطوير البرمجيات ، تبدو دورة حياتها مثل التدفق الذي يمر بالتتابع عبر مراحل تحليل المتطلبات والتصميم. التنفيذ والاختبار والتكامل والدعم.

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

تنقسم دورة الحياة تقليديًا إلى ما يليمراحل:

1. تحليل المتطلبات،
2. تصميم،
3. الترميز (البرمجة) ،
4. الاختبار والتصحيح ،
5. التشغيل والصيانة.

مزايا النموذج:

• استقرار المتطلبات طوال دورة حياة التطوير ؛
• في كل مرحلة ، يتم تكوين مجموعة كاملة من وثائق المشروع التي تفي بمعايير الاكتمال والاتساق ؛
• يقين وإمكانية فهم خطوات النموذج وبساطة تطبيقه ؛
• تسمح لك مراحل العمل المنجز في تسلسل منطقي بالتخطيط لتوقيت الانتهاء من جميع الأعمال والموارد المقابلة (النقدية والمادية والبشرية).

عيوب النموذج:

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

من الصعب تنفيذ نموذج دورة حياة الشلال نظرًا لتعقيد تطوير PS دون العودة إلى الخطوات السابقة وتغيير نتائجها للتخلص من المشكلات الناشئة.

نطاق نموذج Cascade

يتم تحديد حدود نطاق النموذج التعاقبي من خلال عيوبه. يكون استخدامه أكثر فاعلية في الحالات التالية:

1. عند تطوير المشاريع بشكل واضح وغير قابل للتغييردورة الحياة المتطلبات مفهومة من خلال التنفيذ والمنهجيات التقنية ؛
2. عند تطوير مشروع يركز على بناء نظام أو منتج من نفس النوع كما سبق للمطورين تطويره ؛
3. عند تطوير مشروع متعلق بإنشاء وإصدار نسخة جديدة من منتج أو نظام موجود ؛
4. عند تطوير مشروع متعلق بنقل منتج أو نظام موجود إلى منصة جديدة ؛
5. عند تنفيذ مشاريع كبيرة تضم العديد من فرق التطوير الكبيرة.

نموذج تزايدي

(نموذج مرحلي مع تحكم وسيط)

نموذج تزايدي(م. زيادة راتب- الزيادة ، الزيادة) تعني تطوير البرنامج بتسلسل خطي من المراحل ، ولكن في عدة زيادات (إصدارات) ، أي مع تحسينات المنتج المخطط لها طالما أن دورة حياة تطوير البرامج تنتهي.

يتم تطوير البرامج في تكرارات مع حلقات تغذية مرتدة بين المراحل. تجعل التعديلات بين المراحل من الممكن مراعاة التأثير المتبادل الفعلي لنتائج التنمية في مراحل مختلفة ، ويتم تمديد عمر كل مرحلة على مدار فترة التطوير بأكملها.

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

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

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

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

مزايا:

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

عيوب النموذج:

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

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

نموذج حلزوني

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

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

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

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

مزايا النموذج:

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

عيوب النموذج:

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

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

نطاق النموذج الحلزوني

ينصح باستخدام النموذج الحلزوني في الحالات التالية:

• عند تطوير المشاريع باستخدام التقنيات الجديدة ؛
• عند تطوير سلسلة جديدة من المنتجات أو الأنظمة ؛
• عند تطوير المشاريع مع التغييرات الكبيرة المتوقعة أو الإضافات على المتطلبات ؛
• لتنفيذ مشاريع طويلة الأجل ؛
• عند تطوير المشاريع التي تتطلب توضيحًا لجودة وإصدارات نظام أو منتج خلال فترة زمنية قصيرة ؛
• عند تطوير المشاريع. التي من الضروري حساب التكاليف المرتبطة بتقييم وحل المخاطر.

في الهندسة الكهربائية). يحدد هذا المعيار بنية دورة الحياة ، التي تحتوي على العمليات والأنشطة والمهام التي يجب إجراؤها أثناء إنشاء PS.

في هذا المعيار PS (أو البرمجيات) على أنها مجموعة من برامج الكمبيوتر ، والإجراءات ، وربما الوثائق والبيانات المرتبطة بها. يتم تعريف العملية على أنها مجموعة من الإجراءات المترابطة التي تحول بعض بيانات الإدخال إلى بيانات الإخراج (يطلق G. تتميز كل عملية بمهام وطرق معينة لحلها. في المقابل ، يتم تقسيم كل عملية إلى مجموعة من الإجراءات ، ويتم تقسيم كل إجراء إلى مجموعة من المهام. يتم بدء كل عملية أو إجراء أو مهمة وتنفيذها بواسطة عملية أخرى حسب الحاجة ، ولا توجد تسلسلات تنفيذ محددة مسبقًا (بالطبع ، مع الحفاظ على اتصالات بيانات الإدخال).

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

يتم تنظيم عمليات إنشاء الأنظمة الآلية (AS) ، والتي تشمل أيضًا البرامج ، وفقًا للمعايير GOST 34.601-90 "تكنولوجيا المعلومات. مجموعة من المعايير للأنظمة المؤتمتة. مراحل الإنشاء" ، GOST 34.602-89 "تكنولوجيا المعلومات. أ مجموعة من المعايير للأنظمة الآلية. مهمة فنيةلإنشاء نظام آلي "و GOST 34.603-92" تكنولوجيا المعلومات. أنواع اختبارات الأنظمة المؤتمتة ". ومع ذلك ، فإن العديد من أحكام هذه المعايير قد عفا عليها الزمن ، في حين أن البعض الآخر لا ينعكس بما يكفي لاستخدامه في المشاريع الجادة لإنشاء PS ، لذلك فمن المستحسن استخدام المعايير الدولية الحديثة في التطورات المحلية.

وفقًا لمعيار ISO / IEC 12207 ، يتم تقسيم جميع عمليات دورة حياة البرنامج إلى ثلاث مجموعات (الشكل 5.1).

أرز. 5.1

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

5.2 العمليات الرئيسية لدورة حياة PS

تتكون عملية الاستحواذ من أنشطة ومهام العميل الذي يشتري البرنامج. تغطي هذه العملية الخطوات التالية:

1. بدء الاستحواذ
2. إعداد مقترحات التطبيق.
3. إعداد العقد وتعديله ؛
4. الإشراف على أنشطة المورد ؛
5. القبول والانتهاء من العمل.

يشمل بدء التزويد المهام التالية:

1. تحديد العميل لاحتياجاته في اكتساب أو تطوير أو تحسين النظام أو منتجات أو خدمات البرامج ؛
2. اتخاذ قرار بشأن اقتناء أو تطوير أو تحسين البرامج الموجودة ؛
3. التحقق من توفر الوثائق والضمانات والشهادات والتراخيص والدعم اللازمة في حالة شراء منتج برمجي ؛
4. إعداد واعتماد خطة الاستحواذ ، بما في ذلك متطلبات النظام ، ونوع العقد ، ومسؤوليات الأطراف ، إلخ.

يجب أن تحتوي العطاءات على:

1. متطلبات النظام؛
2. قائمة منتجات البرمجيات ؛
3. شروط الاستحواذ والاتفاق ؛
4. القيود الفنية (على سبيل المثال ، على بيئة تشغيل النظام).

يتم إرسال العطاءات إلى مورد مختار أو عدة موردين في حالة وجود عطاء. المورد هو مؤسسة تدخل في عقد مع عميل لتزويد نظام أو برنامج أو خدمة برمجية وفقًا للشروط المحددة في العقد.

يشمل إعداد وتعديل العقد المهام التالية:

1. تحديد العميل لإجراءات اختيار المورد ، بما في ذلك معايير تقييم عروض الموردين المحتملين ؛
2. اختيار مورد معين بناءً على تحليل العروض ؛
3. التحضير والاستنتاج عقود الموردين;
4. إجراء تغييرات (إذا لزم الأمر) على العقد في عملية تنفيذه.

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

تغطي عملية التسليم الأنشطة والمهام التي يقوم بها البائع الذي يزود العميل بمنتج أو خدمة برمجية. تتضمن هذه العملية الخطوات التالية:

1. بدء التسليم
2. إعداد الرد على العطاءات.
3. إعداد العقد
4. تخطيط العمل التعاقدي ؛
5. أداء ومراقبة الأعمال التعاقدية وتقييمها ؛
6. تسليم وإنجاز الأعمال.

يتمثل بدء التوريد في النظر من قبل المورد للعطاءات واتخاذ قرار بشأن الموافقة على المتطلبات والشروط المحددة أو تقديم العروض الخاصة بهم (متفق عليها). يشمل التخطيط المهام التالية:

1. اتخاذ قرار من قبل المورد فيما يتعلق بأداء العمل بمفرده أو بمشاركة مقاول من الباطن ؛
2. وضع المورد لخطة إدارة مشروع تحتوي على الهيكل التنظيمي للمشروع ، وتحديد المسؤوليات ، والمتطلبات الفنية لبيئة التطوير والموارد ، وإدارة المقاولين من الباطن ، إلخ.

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

تتضمن عملية التطوير الخطوات التالية:

1. العمل التحضيري
2. تحليل متطلبات النظام ؛
3. تصميم معمارية النظام
4. تحليل متطلبات البرمجيات ؛
5. تصميم هندسة البرمجيات ؛
6. تصميم برنامج مفصل
7. برمجة واختبار البرمجيات ؛
8. تكامل البرامج
9. اختبار تأهيل البرمجيات ؛
10. نظام التكامل؛
11. اختبار التأهيل للنظام ؛
12. تثبيت البرامج؛
13. قبول البرنامج.

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

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

يتكون تصميم بنية النظام من تحديد مكونات معداته (الأجهزة) والبرامج والعمليات التي يقوم بها الموظفون الذين يقومون بتشغيل النظام. يجب أن تتوافق بنية النظام مع متطلبات النظام ومعايير وممارسات التصميم المقبولة.

يتضمن تحليل متطلبات البرامج تحديد الخصائص التالية لكل مكون برمجي:

1. الوظيفة ، بما في ذلك خصائص الأداء وبيئة تشغيل المكون ؛
2. واجهات خارجية
3. مواصفات الموثوقية والسلامة ؛
4. متطلبات مريحة
5. متطلبات البيانات المستخدمة ؛
6. متطلبات التثبيت والقبول ؛
7. متطلبات وثائق المستخدم ؛
8. متطلبات التشغيل والصيانة.

يتم تقييم متطلبات البرامج بناءً على معايير الامتثال لمتطلبات النظام ككل والجدوى وإمكانية التحقق أثناء الاختبار.

يتضمن تصميم هندسة البرمجيات المهام التالية لكل مكون برمجي:

1. تحويل متطلبات البرمجيات إلى بنية تحدد هيكل البرنامج وتكوين مكوناته على مستوى عالٍ ؛
2. تطوير وتوثيق واجهات البرنامج للبرامج وقواعد البيانات (DB) ؛
3. تطوير نسخة أولية من وثائق المستخدم ؛
4. تطوير وتوثيق المتطلبات الأساسية للاختبارات وخطة تكامل البرامج.

يتضمن التصميم التفصيلي للبرنامج المهام التالية:

1. وصف مكونات البرامج والواجهات فيما بينها بمستوى أدنى ، كافٍ للترميز والاختبار اللاحقين ؛
2. تطوير وتوثيق تصميم قاعدة بيانات مفصلة ؛
3. تحديث (إذا لزم الأمر) وثائق المستخدم ؛
4. تطوير وتوثيق متطلبات الاختبار وخطة لاختبار مكونات البرامج ؛

يتضمن ترميز البرامج والاختبار المهام التالية:

1. ترميز وتوثيق كل مكون من مكونات البرنامج وقاعدة البيانات ، وكذلك إعداد مجموعة من إجراءات الاختبار والبيانات لاختبارها ؛
2. اختبار كل مكون من مكونات البرنامج وقاعدة البيانات للامتثال للمتطلبات الخاصة بهما ، متبوعًا بتوثيق نتائج الاختبار ؛
3. تحديث الوثائق (إذا لزم الأمر) ؛
4. تحديث خطة تكامل البرنامج.

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

يتم إجراء اختبار تأهيل البرنامج من قبل المطور بحضور العميل (

تغطي عملية التشغيل أنشطة ومهام منظمة المشغل الذي يقوم بتشغيل النظام. تتضمن عملية التشغيل الخطوات التالية.

1. الأعمال التحضيرية ، والتي تشمل تنفيذ المهام التالية من قبل المشغل:

   1. أنشطة التخطيط والعمل المنجز أثناء التشغيل ، ووضع معايير التشغيل ؛
   2. تحديد إجراءات التوطين وحل المشكلات التي تنشأ أثناء التشغيل.
2. يتم إجراء الاختبار التشغيلي لكل إصدار تالٍ من منتج البرنامج ، وبعد ذلك يتم نقل هذا الإصدار إلى التشغيل.
3. التشغيل الفعلي للنظام ، والذي يتم إجراؤه في البيئة المخصصة لذلك وفقًا لوثائق المستخدم.
4. تحليل المشكلات وطلبات تعديل البرامج (تحليل الرسائل حول مشكلة نشأت أو طلب تعديل ، تقييم الحجم ، تكلفة التعديل ، التأثير الناتج ، تقييم جدوى التعديل) ؛
5. تعديل البرنامج (إجراء تغييرات على مكونات منتج البرنامج والوثائق وفقًا لقواعد عملية التطوير) ؛
6. التحقق والقبول (من حيث سلامة النظام الجاري تعديله) ؛
7. نقل البرامج إلى بيئة أخرى (تحويل البرامج والبيانات ، التشغيل الموازي للبرنامج في البيئة القديمة والجديدة لفترة زمنية معينة) ؛
8. إيقاف تشغيل البرنامج بقرار من العميل بمشاركة منظمة التشغيل وخدمة الصيانة والمستخدمين. في الوقت نفسه ، تخضع منتجات ووثائق البرامج للأرشفة وفقًا للعقد.

حاشية. ملاحظة.

مقدمة.

1. دورة حياة البرمجيات

مقدمة.

خطوات عملية البرمجة رايلي

مقدمة.

1.1.1. صياغة المشكلة.

1.1.2. تصميم الحلول.

1.1.3. ترميز الخوارزمية.

1.1.4. دعم البرنامج.

1.1.5. وثائق البرنامج.

الخلاصة للفقرة 1.1

1.2 تعريف ZhTsPO وفقًا لـ Lehman.

مقدمة.

1.2.1 تعريف النظام.

1.2.2. تطبيق.

1.2.3. خدمة.

الخلاصة للبند 1.2.

1.3 مراحل وأعمال برنامج دورة الحياة بحسب بوم

1.3.1. نموذج تتالي.

1.3.2. الإثبات الاقتصادي للنموذج التعاقبي.

1.3.3. تحسين نموذج الشلال.

1.3.4. تعريف مراحل دورة الحياة.

1.3.5. العمل الأساسي في المشروع.

المؤلفات.

مقدمة

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

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

1 دورة حياة البرنامج

المقدمة

LCPE هي عملية مستمرة تبدأ من اللحظة التي يتم فيها اتخاذ قرار بشأن الحاجة إلى إنشاء برنامج وتنتهي في اللحظة التي يتم فيها سحبها تمامًا من التشغيل.

هناك عدة طرق لتحديد مراحل وأنشطة دورة حياة البرنامج (SLLC) ، وخطوات عملية البرمجة ، والنماذج الحلزونية والشلال. لكنها تحتوي جميعها على مكونات أساسية مشتركة: بيان المشكلة ، وتصميم الحلول ، والتنفيذ ، والصيانة.

ولعل أشهرها واكتمالها هي بنية دورة الحياة بحسب بوهم ، والتي تشمل ثماني مراحل. سيتم تقديمه بمزيد من التفصيل لاحقًا.

قد يكون أحد الخيارات الممكنة هو وصف المستوى الأعلى وفقًا لـ Lehman ، والذي يتضمن ثلاث مراحل رئيسية ويمثل وصف برنامج دورة الحياة في الحالة الأكثر عمومية.

وللتغيير ، إليك خطوات عملية البرمجة التي قدمها د.رايلي في كتاب "استخدام لغة Modula-2". هذه الفكرة في رأيي بسيطة للغاية ومألوفة وسنبدأ بها.

1.1 خطوات عملية البرمجة رايلي

مقدمة

تتضمن عملية البرمجة أربع خطوات (الشكل 1):

بيان المشكلة ، أي الحصول على فكرة مناسبة عن المهمة التي يجب أن يؤديها البرنامج ؛

تصميم حل لمشكلة مطروحة بالفعل (بشكل عام ، هذا الحل أقل رسمية من البرنامج النهائي) ؛

ترميز البرنامج ، أي ترجمة الحل المصمم إلى برنامج يمكن تنفيذه على الجهاز ؛

دعم البرنامج ، أي عملية مستمرة لإصلاح الخلل في البرنامج وإضافة ميزات جديدة.

أرز. 1. أربع خطوات برمجة.

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

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

1.1.1 بيان المشكلة

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

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

خصائص بيان المشكلة الجيد:

دقة، بمعنى آخر. استبعاد أي غموض. لا ينبغي أن يكون هناك شك حول ما سيكون ناتج البرنامج لأي مدخلات معينة.

اكتمال، بمعنى آخر. النظر في جميع الخيارات لمدخل معين ، بما في ذلك المدخلات الخاطئة أو غير المتوقعة ، وتحديد المخرجات المناسبة.

وضوح، بمعنى آخر. يجب أن يكون مفهوماً لكل من المستخدم ومحلل النظام ، لأن بيان المشكلة هو العقد الوحيد بينهما.

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

الشكل القياسي لبيان المشكلة.

ضع في اعتبارك العبارة التالية للمشكلة: "أدخل ثلاثة أرقام وأخرج الأرقام بالترتيب."

مثل هذا البيان لا يفي بالمتطلبات المذكورة أعلاه: فهو ليس دقيقًا ولا كاملًا ولا مفهومًا. في الواقع ، هل يجب إدخال الأرقام بمعدل واحد في كل سطر ، أم إدخال جميع الأرقام في سطر واحد؟ هل تعني عبارة "بالترتيب" الترتيب من الأكبر إلى الأصغر ، من الأصغر إلى الأكبر ، أو نفس الترتيب الذي قدمت به.

من الواضح أن مثل هذا البيان لا يجيب على العديد من الأسئلة. إذا أخذنا في الاعتبار الإجابات على جميع الأسئلة ، فإن بيان المشكلة سيصبح شديد الكلام ويصعب فهمه. لذلك ، يقترح د.رايلي استخدام النموذج القياسي لتحديد المشكلة ، والذي يضمن أقصى قدر من الدقة والاكتمال والوضوح ويتضمن:

اسم المهمة (تعريف تخطيطي) ؛

وصف عام (بيان موجز للمهمة) ؛

أخطاء (يتم سرد خيارات الإدخال غير المعتادة بشكل صريح لتظهر للمستخدمين والمبرمجين الإجراءات التي سيتخذها الجهاز في مثل هذه المواقف) ؛

مثال (يمكن للمثال الجيد أن ينقل جوهر المشكلة ، وكذلك يوضح حالات مختلفة).

مثال. بيان المشكلة بالشكل القياسي.

لقب

فرز ثلاثة أعداد صحيحة.

وصف

الإدخال والإخراج لثلاثة أعداد صحيحة ، مرتبة من الأصغر إلى الأكبر.

يتم إدخال ثلاثة أعداد صحيحة ، رقم واحد في كل سطر. في هذه الحالة ، الرقم الصحيح هو واحد أو أكثر من الأرقام العشرية المتتالية ، والتي قد تسبقها علامة الجمع "+" أو علامة الطرح "-".

يتم إخراج الأعداد الصحيحة الثلاثة التي تم إدخالها ، مع عرض الثلاثة جميعها على نفس السطر. الأرقام المجاورة مفصولة بمسافة. يتم عرض الأرقام من الأصغر إلى الأكبر ، من اليسار إلى اليمين.

1) إذا تم إدخال أقل من ثلاثة أرقام ، ينتظر البرنامج إدخالًا إضافيًا.

2) يتم تجاهل سطور الإدخال بخلاف الثلاثة الأولى.

3) إذا كان أي من الأسطر الثلاثة الأولى يحتوي على أكثر من عدد صحيح ، فسيخرج البرنامج ويصدر رسالة.

حاشية. ملاحظة.

مقدمة.

1. دورة حياة البرمجيات

مقدمة.

خطوات عملية البرمجة رايلي

مقدمة.

1.1.1. صياغة المشكلة.

1.1.2. تصميم الحلول.

1.1.3. ترميز الخوارزمية.

1.1.4. دعم البرنامج.

1.1.5. وثائق البرنامج.

الخلاصة للفقرة 1.1

1.2 تعريف ZhTsPO وفقًا لـ Lehman.

مقدمة.

1.2.1 تعريف النظام.

1.2.2. تطبيق.

1.2.3. خدمة.

الخلاصة للبند 1.2.

1.3 مراحل وأعمال برنامج دورة الحياة بحسب بوم

1.3.1. نموذج تتالي.

1.3.2. الإثبات الاقتصادي للنموذج التعاقبي.

1.3.3. تحسين نموذج الشلال.

1.3.4. تعريف مراحل دورة الحياة.

1.3.5. العمل الأساسي في المشروع.

المؤلفات.

مقدمة

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

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

1 دورة حياة البرنامج

المقدمة

LCPE هي عملية مستمرة تبدأ من اللحظة التي يتم فيها اتخاذ قرار بشأن الحاجة إلى إنشاء برنامج وتنتهي في اللحظة التي يتم فيها سحبها تمامًا من التشغيل.

هناك عدة طرق لتحديد مراحل وأنشطة دورة حياة البرنامج (SLLC) ، وخطوات عملية البرمجة ، والنماذج الحلزونية والشلال. لكنها تحتوي جميعها على مكونات أساسية مشتركة: بيان المشكلة ، وتصميم الحلول ، والتنفيذ ، والصيانة.

ولعل أشهرها واكتمالها هي بنية دورة الحياة بحسب بوهم ، والتي تشمل ثماني مراحل. سيتم تقديمه بمزيد من التفصيل لاحقًا.

قد يكون أحد الخيارات الممكنة هو وصف المستوى الأعلى وفقًا لـ Lehman ، والذي يتضمن ثلاث مراحل رئيسية ويمثل وصف برنامج دورة الحياة في الحالة الأكثر عمومية.

وللتغيير ، إليك خطوات عملية البرمجة التي قدمها د.رايلي في كتاب "استخدام لغة Modula-2". هذه الفكرة في رأيي بسيطة للغاية ومألوفة وسنبدأ بها.

1.1 خطوات عملية البرمجة رايلي

تتضمن عملية البرمجة أربع خطوات (الشكل 1):

بيان المشكلة ، أي الحصول على فكرة مناسبة عن المهمة التي يجب أن يؤديها البرنامج ؛

تصميم حل لمشكلة مطروحة بالفعل (بشكل عام ، هذا الحل أقل رسمية من البرنامج النهائي) ؛

ترميز البرنامج ، أي ترجمة الحل المصمم إلى برنامج يمكن تنفيذه على الجهاز ؛

دعم البرنامج ، أي عملية مستمرة لإصلاح الخلل في البرنامج وإضافة ميزات جديدة.

أرز. 1. أربع خطوات برمجة.

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

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

1.1.1 بيان المشكلة

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

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

خصائص بيان المشكلة الجيد:

دقة، بمعنى آخر. استبعاد أي غموض. لا ينبغي أن يكون هناك شك حول ما سيكون ناتج البرنامج لأي مدخلات معينة.

اكتمال، بمعنى آخر. النظر في جميع الخيارات لمدخل معين ، بما في ذلك المدخلات الخاطئة أو غير المتوقعة ، وتحديد المخرجات المناسبة.

وضوح، بمعنى آخر. يجب أن يكون مفهوماً لكل من المستخدم ومحلل النظام ، لأن بيان المشكلة هو العقد الوحيد بينهما.

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

الشكل القياسي لبيان المشكلة.

ضع في اعتبارك العبارة التالية للمشكلة: "أدخل ثلاثة أرقام وأخرج الأرقام بالترتيب."

مثل هذا البيان لا يفي بالمتطلبات المذكورة أعلاه: فهو ليس دقيقًا ولا كاملًا ولا مفهومًا. في الواقع ، هل يجب إدخال الأرقام بمعدل واحد في كل سطر ، أم إدخال جميع الأرقام في سطر واحد؟ هل تعني عبارة "بالترتيب" الترتيب من الأكبر إلى الأصغر ، من الأصغر إلى الأكبر ، أو نفس الترتيب الذي قدمت به.

من الواضح أن مثل هذا البيان لا يجيب على العديد من الأسئلة. إذا أخذنا في الاعتبار الإجابات على جميع الأسئلة ، فإن بيان المشكلة سيصبح شديد الكلام ويصعب فهمه. لذلك ، يقترح د.رايلي استخدام النموذج القياسي لتحديد المشكلة ، والذي يضمن أقصى قدر من الدقة والاكتمال والوضوح ويتضمن:

اسم المهمة (تعريف تخطيطي) ؛

وصف عام (بيان موجز للمهمة) ؛

أخطاء (يتم سرد خيارات الإدخال غير المعتادة بشكل صريح لتظهر للمستخدمين والمبرمجين الإجراءات التي سيتخذها الجهاز في مثل هذه المواقف) ؛

مثال (يمكن للمثال الجيد أن ينقل جوهر المشكلة ، وكذلك يوضح حالات مختلفة).

مثال. بيان المشكلة بالشكل القياسي.

لقب

فرز ثلاثة أعداد صحيحة.

وصف

الإدخال والإخراج لثلاثة أعداد صحيحة ، مرتبة من الأصغر إلى الأكبر.

يتم إدخال ثلاثة أعداد صحيحة ، رقم واحد في كل سطر. في هذه الحالة ، الرقم الصحيح هو واحد أو أكثر من الأرقام العشرية المتتالية ، والتي قد تسبقها علامة الجمع "+" أو علامة الطرح "-".

يتم إخراج الأعداد الصحيحة الثلاثة التي تم إدخالها ، مع عرض الثلاثة جميعها على نفس السطر. الأرقام المجاورة مفصولة بمسافة. يتم عرض الأرقام من الأصغر إلى الأكبر ، من اليسار إلى اليمين.

1) إذا تم إدخال أقل من ثلاثة أرقام ، ينتظر البرنامج إدخالًا إضافيًا.

في 1 مارس 2012 ، اعتمدت الوكالة الفيدرالية للتنظيم الفني والمقاييس في الاتحاد الروسي معيار GOST R ISO / IEC 12207-2010 "تكنولوجيا المعلومات. هندسة النظم والبرمجيات. عمليات دورة حياة البرمجيات "، مطابقة للمعيار الدولي ISO / IEC 12207: 2008" هندسة النظم والبرمجيات - عمليات دورة حياة البرمجيات ".

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

عمليات دورة حياة البرمجيات

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

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

تتضمن كل عملية عددًا من الأنشطة. على سبيل المثال ، تغطي عملية الاستحواذ الخطوات التالية:

1. بدء الاستحواذ
2. تحضير العطاءات
3. إعداد العقد وتعديله
4. مراقبة المورد
5. قبول وإنجاز العمل

يتضمن كل إجراء عددًا من المهام. على سبيل المثال ، يجب أن يشمل إعداد العطاءات ما يلي:

1. تشكيل متطلبات النظام
2. تشكيل قائمة منتجات البرمجيات
3. تحديد الشروط والاتفاقيات
4. وصف القيود الفنية (بيئة تشغيل النظام ، إلخ)

مراحل دورة حياة البرمجيات والعلاقة بين العمليات والمراحل

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

لا يقدم معيار GOST R ISO / IEC 12207-2010 نموذج دورة حياة محددًا. أحكامه مشتركة مع أي نماذج دورة حياة ، وأساليب وتقنيات لإنشاء الملكية الفكرية. يصف هيكل عمليات دورة الحياة دون تحديد كيفية تنفيذ أو أداء الأنشطة والمهام المدرجة في هذه العمليات.

يتضمن نموذج دورة حياة البرنامج ما يلي:

1. مراحل؛
2. نتائج العمل في كل مرحلة ؛
3. الأحداث الرئيسية - نقاط إتمام العمل واتخاذ القرار.