hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
قانون الخصوصية الولايات المتحدة
بالرغم من أن الدستور لا يتضمن صراحة الحق في الخصوصية، لكن الخصوصية الفردية والمكانية محفوظتين ضمنيا في الدستور تحت التعديل الرابع، ووجدت المحكمة العليا في الولايات المتحدة أن الضمانات الأخرى فيها «غبش» والتي تمنح ضمنيا حق الخصوصية ضد تدخل الحكومة، ولقد كان الحق في الخصوصية هو المبرر للقرارات التي تشتمل على مجموعة كبيرة من قضايا الحريات المدنية، بما في ذلك قضية بيرس ضد جمعية الأخوات، والتي أبطلت مبادرة ناجحة من ولاية أوريغون تتطلب فرض التعليم العام الإجباري، وقضية جريسولد ضد كونيكتيكت، والتي كما في حالة جريسولد ضد كونيكتكت (1965)  والتي تم من خلالها التعبير عن الحق في الخصوصية للمرة الأولى بشكل صريح، وقضية رو ضد واد والتي ضربت بعرض الحائط قانون الإجهاض في تكساس، وبالتالي قيدت من سلطات الولاية في فرض القوانين ضد الإجهاض، وقضية لورانس ضد تكساس، والتي ضربت بعرض الحائط قانون اللواط، وبالتالي قللت من سلطات الولاية في فرض القوانين التي تتعلق باللواط. وفي الولايات المتحدة إن حق حرية التعبير الممنوح في التعديل الأول حد من تأثير دعاوى قضائية لانتهاك الخصوصية. وتُنظم الخصوصية في الولايات المتحدة عن طريق قانون الخصوصية 1974 وقوانين مختلفة في الولايات.وينطبق قانون الخصوصية 1974 فقط على الوكالات الفيدرالية في الفرع التنفيذي للحكومة الفدرالية. ولقد تأسست حقوق معينة للخصوصية في الولايات المتحدة من خلال تشريعات مثل: قانون حماية خصوصية الأطفال في الإنترنت،  قانون جرام ليتش بليلي، قانون إخضاع التأمين الصحي لقابلية النقل والمحاسـبة.
قانون الخصوصية الولايات المتحدة
وغالبًا تتم الإشارة إلى مقال صدر في الإصدار الخامس عشر من ديسمبر 1890 من هارفارد لو ريفيو، كتبه المحامي صامويل وارين والقاضي الذي شغل منصبًا بعد ذلك في المحكمة العليا لويس برانديس وكان عنوانه «الحق في الخصوصية» (The Right To Privacy)، على أنه أول إعلان صريح في حق الأمريكيين في الخصوصية  ويخضع هذا الحق للكثير من الجدل. ويقول البنائيون الصارمون أن هذا الحق غير موجود (أو على الأقل أن المحكمة العليا لا تمتلك الاختصاص لحماية مثل هذا الحق)، في حين أن بعض التحرريين يقولون إن هذا الحق يبطل العديد من أنواع المراقبة المدنية المسموح بها حاليًا (التنصت على المكالمات الهاتفية والكاميرات العامة وما إلى ذلك). 
كما تمنح أغلب الولايات كذلك الحق في الخصوصية وتشير إلى أربعة أضرار اعتمادًا على هذا الحق:
قانون الخصوصية فيجي
بلد فيجي، أرخبيل يقع في المحيط الهادئ أنشئ في 10 أكتوبر 1970. يمنح الدستور السكان قاطني الأرض الحق في الخصوصية. فيما يلي الإجراءات الدقيقة المنصوص عليها في الدستور: «لكل شخص الحق في الخصوصية الشخصية التي تشمل الحق في (أ) سرية معلوماته الشخصية؛ (ب) سرية بلاغاتهم؛ (ج) احترام حياتهم الخاصة والأسرية». لكن في هذا الدستور نفسه، يشار إلى أنه من الممكن «بقدر ما توجبه الضرورة» إقرار قانون يحد أو يؤثر على تنفيذ قانون الحق في الخصوصية. يرد قانون آخر متعلق بالخصوصية في المادة 54 من قانون الاتصالات السلكية واللاسلكية الصادر في عام 2008، ينص على أن «أي مزود خدمات يوفر المستهلكين بالاتصالات السلكية واللاسلكية عليه إبقاء معلومات المستهلكين سرية». لا تعتبر معلومات الفوترة ومعلومات المكالمات استثناءً. يكمن الاستثناء الوحيد لهذه القاعدة بهدف تسليط الضوء على «الاحتيال أو الدين المتعثر». بموجب هذا القانون، لا يسمح بالكشف عن المعلومات، حتى بموافقة العميل.
قانون الخصوصية فيجي
تهدف قوانين الخصوصية الأخرى التي تبناها هذا البلد إلى حماية المعلومات المجمعة، وملفات تعريف الارتباط وغيرها من المسائل المتعلقة بالخصوصية للسياح. يتعلق ذلك (ولكن ليس على سبيل الحصر) بالمعلومات التي جمعت خلال الحجر، واستخدام تكنولوجيا أخرى تخص تلك الشركة أو من خلال استخدام خدمة للشركة، أو عند إجراءات الدفع. إضافة إلى ذلك، فإن فيجي، بوصفها عضوًا في الأمم المتحدة، ملزمة بالإعلان العالمي لحقوق الإنسان الذي ينص في المادة الثانية عشرة على أنه «لا يجوز أي شخص لتدخل تعسفي في خصوصياته أو أسرته أو بيته أو مراسلاته، ولا للاعتداء على شرفه وسمعته. لكل شخص الحق في حماية القانون من مثل هذا التدخل أو الهجوم».
قانون الخصوصية فرنسا
تبنت فرنسا قانون خصوصية البيانات عام 1978. ينطبق هذا القانون على المنظمات العامة والخاصة ويحظر جمع البيانات الحساسة عن الأشخاص (بما في ذلك الجنسانية والإثنية والآراء السياسية أو الدينية). تدير القانون اللجنة الوطنية للمعلوماتية والحريات، وهي إدارة وطنية مكرسة لهذا الغرض. كما هو الحال في ألمانيا، تعتبر انتهاكات البيانات جرائم جنائية (المادة 84 من قانون العدل مع القانون الجنائي، المادة 1، الفصل السادس، المادة 226 وما يليها).
تثبيت (حوسبة)
في سياق علم الحاسوب، التثبيت (أو التنصيب) هو عملية وضع برنامج على نظام تشغيل الحاسوب بحيث يصبح تنفيذه ممكنا.
لأن متطلبات التنصيب تختلف من برنامج لآخر و من حاسوب لآخر، فإن الكثير من برامج الحاسوب (ومنها أنظمة التشغيل) يصاحبها «برنامج تثبيت» عام أو خاص، فيكون واجبه تشغيل معظم المهام المندرجة تحت عملية التثبيت تلقائيا.
نقطة ضعف (حوسبة)
في سياق أمن الحاسوب، نقطة الضعف هي ثغرة تسمح للمخترق أن يقلص من ضمان المعلومات لنظام ما. فالضعف هو تقاطع ثلاثة عناصر: عيب في النظام، ومخترق يصل لهذا العيب، وقدرة هذا الهاكر على استغلال هذا العيب. لاستغلال الثغرة الأمنية، يجب أن يكون لدى المهاجم أداة واحدة أو تقنية قابلة للتطبيق على الأقل يمكنها الاتصال بضعف النظام. في هذا الإطار، ويعرف الضعف أيضا باسم سطح الهجوم.
ويمكن تصنيف الخطر الأمني على أنه ضعف. استخدام الضعف مع نفس المعنى من المخاطر يمكن أن يؤدي إلى الارتباك. ويرتبط الخطر باحتمال حدوث خسارة كبيرة. ثم هناك نقاط ضعف دون مخاطر: على سبيل المثال عندما يكون الأصول المتضررة لا قيمة لها. ويصنف الضعف مع واحد أو أكثر من الحالات المعروفة من العمل والهجمات تنفيذها بالكامل على أنها الضعف القابل للاستغلال - الضعف التي يوجد استغلال لها. نافذة الضعف هي الوقت الذي تم فيه إدخال ثغرة أمنية أو تجلى في البرامج التي تم نشرها، إلى عندما تم إزالة الوصول، تم توفير إصلاح الأمان / نشرها، أو تم تعطيل المهاجم - انظر هجوم اليوم صفر.
نقطة ضعف (حوسبة)
علة الأمن (عيب الأمن) هو مفهوم أضيق: هناك نقاط الضعف التي لا تتعلق البرمجيات: الأجهزة، الموقع، ومواطن الضعف الموظفين أمثلة على نقاط الضعف التي ليست أخطاء الأمن البرمجيات.
بناء في لغات البرمجة التي يصعب استخدامها بشكل صحيح يمكن أن يكون مصدرا كبيرا من نقاط الضعف.
نقطة ضعف (حوسبة) نظرة عامة
يتمثل ضعف أنظمة الحاسوب بوجود نقاط ضعف أمنية يمكن استغلالها من قِبل طرف خبيث (مثل مهاجم سيبراني) لتنفيذ عمليات غير مصرح بها داخل نظام حاسوب معين. لا بد للطرف المهاجم من أن يمتلك أداة عملية واحدة على الأقل أو تقنيةً تمكّنه من الوصول إلى نقطة ضعف النظام. وفي هذا الإطار، يُعرف مصطلح الضعف أيضًا بسطح الهجوم.
تُعرف إدارة نقاط الضعف بأنها عملية اكتشاف الثغرات الأمنية، وتصنيفها، وعلاجها، والحد من آثارها السلبية بصفة دورية. تشير تلك العملية بصفة عامة إلى نقاط ضعف البرمجيات في أنظمة الحاسوب.
نقطة ضعف (حوسبة) نظرة عامة
تُصنف الخطورة الأمنية في أحيان كثيرة بصفة خاطئة على أنها نقطة ضعف. قد يؤدي استخدام كلمة «ضعف» مكان «خطورة» إلى الالتباس والفهم الخاطئ. إذ إن الخطورة الأمنية تعبر عن عرضة النظام للتأثر بمحاولة استغلال نقطة الضعف بدرجة ملحوظة. أما نقاط الضعف، فهي لا تشكل خطورة مؤكدة في جميع الأحوال، فعلى سبيل المثال، لا تشكل نقاط الضعف التي تستهدف موارد بلا قيمة أي خطورة تُذكر. تُوصف نقطة الضعف الأمنية بأنها قابلة للاستغلال عند وقوع حادثة هجوم فعال واحدة أو أكثر بسببها. يعبّر مصطلح نافذة الاستغلال عن الوقت الفاصل بين اكتشاف الثغرة الأمنية في برمجيات النظام وإصلاح الثغرة أو منع المهاجم من الوصول إلى النظام أو تعطيله؛ انظر هجوم دون انتظار.
الثغرة الأمنية (أو الخلل الأمني) هي مفهوم أضيق نطاقًا يتعلق بنقاط الضعف المتأصلة في البرمجيات فقط: هناك عدة نقاط ضعف أخرى غير متعلقة بالبرمجيات: نقاط ضعف عتاد الحاسوب، والموقع، وطاقم العمل، وغيرها من الأمثلة.
قد تشكل البنايات المُدمجة في لغات البرمجة التي يصعب استخدامها بشكل صحيح مصدرًا واسعًا لنقاط الضعف.
نقطة ضعف (حوسبة) الأسباب
ضعف كلمات السر: الحاسوب الذي يستخدم كلمات سر ضعيفة يمكن اكتشافها عن طريق القوة العمياء أكثر عرضة للاختراق، ونفس المبدأ يسري على المستخدم الذي يخزن كلمات السر داخل الحاسوب بصفة تسمح للبرامج الأخرى أن تصل إليها بسهولة، أو المستخدمين الذين يعيدون استخدام كلمة السر ذاتها في عدة برامج ومواقع إلكترونية.
عيوب متأصلة في نظام التشغيل: تنشأ تلك العيوب عندما يقرر مصمم نظام التشغيل أن يطبق سياسات غير ملائمة لإدارة البرامج والمستخدمين. على سبيل المثال، أنظمة التشغيل التي تسمح لجميع البرامج والمستخدمين بالوصول الكامل لجميع أجزاء الحاسوب بشكل افتراضي. يسمح هذا الخلل في نظام التشغيل للفيروسات والبرمجيات الخبيثة أن تنفذ أوامر برمجية بالنيابة عن مدير النظام.
تصفح مواقع الإنترنت بلا اكتراث: تحتوي بعض مواقع الإنترنت على برامج تجسس أو برامج إعلانية ضارة تستطيع في بعض الأحيان أن تثبّت نفسها تلقائيًا في الحاسوب. يُصاب الحاسوب بالعدوى إثر زيارته تلك المواقع، وقد تتمكن أطراف خارجية من الاستيلاء على بيانات شخصية داخل الحاسوب بواسطة تلك البرمجيات.
نقطة ضعف (حوسبة) الأسباب
السماح بإدخالات المستخدمين دون رقيب أو حسيب: من الخطأ أن تفترض البرمجيات أن جميع مدخلات المستخدمين آمنة وسليمة. قد تسمح البرامج التي لا تتحقق من مدخلات المستخدمين بتنفيذ أوامر غير مقصودة أو سطور برمجية بلغة إس كيو إل (التي تُعرف أيضًا بتجاوز سعة المخزن المؤقت، أو حقن أوامر إس كيو إل، أو أي مدخلات أخرى غير مُصرح بها).
أظهرت الأبحاث أن أكثر مكونات الأنظمة المعلوماتية ضعفًا تتمثل في البشر، بمن فيهم مستخدمو البرمجيات، ومشغلوها، ومصمموها، ومطوروها. في ضوء ذلك، قد يشكل البشر تهديدًا أو مصدرًا للمعلومات أو الموارد ذات الفائدة وفقًا للدور الذي يلعبه كل إنسان. تثير الهندسة الاجتماعية أيضًا قلقًا أمنيًا متزايدًا في الوقت الراهن.
تمويل أولي للشركات
المال الأولي (بالإنجليزية: Seed money) أو التمويل الأولي أو التمويل القادم من العائلة والأصدقاء، هي طريقة من طرق طرح الأوراق المالية حيث تقوم بعض الأطراف ذات الصلة بالشركة الناشئة الجديدة بالاستثمار بمبلغ يمكّن الشركة الناشئة من البدء بأعمالها والاستمرار بالسوق حتى تصل لمرحلة قادرة على تمويل نفسها بنفسها أو تتمكن خلال هذه الفترة من خلق شيء ذا قيمة يجعل من الشركة الناشئة مغرية للمستثمرين للاستثمار بها في مراحل الاستثمار المقبلة. وتجدر الإشارة إلى أن التمويل الأولي قد يكون أحد أشكال التمويل الجماعي.
تمويل أولي للشركات الاستخدام
يستخدم التمويل الأولي عادةً لدفع التكاليف التمهيدية للشركات الناشئة مثل بحوث التسويق وتطوير الأعمال. ويكون المستثمرين بالعادة هم ملّاك المشروع نفسه، معتمدين على مدخراتهم الشخصية، قروض الرهن العقاري، أو المال المقترض من العائلة والاصدقاء. كما يمكن أن يكون المستثمرون ليسوا من المستثمرين الملائكة أو مستثمري رأس المال المخاطر الذين قد يكونون على معرفة مع مؤسسي المشروع. وتجد الإشارة إلى أنه لا يشترط في التمويل الأولي أن يكون كبيراً, حيث يبدأ الكثير من الأشخاص باستثمارات ومشاريع جديدة بمبلغ يعادل 50,000 دولار أو أقل.
يمكن التمييز بين التمويل الأولي وبين رأس المال المخاطر بأن الأخير يميل لأن يكون أكبر بكثيراً من الناحية النقدية وأن يمتلك بطبيعته تعاقدات طويلة الأجل وان يكون أكثر تعقيداً من ناحية العقود والهيكلية التنظيمية في الشركة المستثمر بها.
تمويل أولي للشركات الاستخدام
يتمييز التمويل الأولي بأنه أكثر مخاطرةً من رأس المال المخاطر، ويعود السبب وراء ذلك إلى أن مقدم رأس المال الأولي لا يرى امامه إلى منتج فعلي ليقيّمه قبل الاستثمار فيه. ولذلك فإن المستثمرين الذي يقدمون رأس المال الأولي يحصلون على حصص مقابلة للحصص التي يحصل عليها المستثمرين في رأس المال المخاطر مع الفرق الكبير في الأموال المستثمرة من قبلهم (يقدم المستثمرين في التمويل الأولي مبلغ يتراوح بين عشرات الآف الدولارات إلى مئات الآف الدولارات مقابل المبلغ الذي يقدمه المستثمرين في رأس المال المخاطر والذي يتراوح بين مئات الآف الدولارات إلى ملايين الدولات).
يمكن أن يجمع التمويل الأولي أيضاً من التمويل الجماعي حيث أنه لا يكون بهذه الحالة معروضاً من المستثمرين.
يقوم بالمستثمرين بالعادة باتخاذ قرارهم بتزويد التمويل الأولي بناءً على تصورهم لمدى نجاح وقوة الفكرة، وقدرة ومهارات وخبرة المؤسسين.
نموذج الشلال
نموذج الشلال هو عملية تصميم متتالية عادة ما تستخدم في عمليات تطوير البرمجيات، ويكون التقدم في سير العمل على هيئة قطع ثابتة متدفقة من أعلى إلى أسفل (مثل الشلال) من خلال المراحل: البدء ثم التحليل ثم التصميم ثم البناء ثم الاختبار ثم الإنتاج والتنفيذ ثم الصيانة.
نموذج الشلال ينشأ في الصناعات التحويلية والتشييد، ولكن للبيئات المادية تعد التغييرات مكلفة وباهظة إن لم تكن مستحيلة. ومع عدم وجود منهجيات تطوير برمجيات رسمية في ذلك الوقت، تم تكييف هذا النموذج ببساطة لتطوير البرمجيات.
نموذج الشلال هو تقسيم لأنشطة المشروع إلى مراحل متتالية خطية، حيث تعتمد كل مرحلة على مخرجات المرحلة السابقة وتتوافق مع تخصص في المهام. النهج نموذجي لمجالات معينة من التصميم الهندسي. في تطوير البرمجيات، تميل إلى أن تكون من بين الأساليب الأقل تكرارًا ومرونة، حيث يتدفق التقدم في اتجاه واحد إلى حد كبير («لأسفل» مثل الشلال) من خلال مراحل التصور والبدء والتحليل والتصميم والبناء والاختبار والنشر والصيانة.
نموذج الشلال
نشأ نموذج تطوير الشلال في صناعات التصنيع والبناء؛ حيث تعني البيئات المادية عالية التنظيم أن تغييرات التصميم أصبحت باهظة التكلفة في وقت مبكر جدًا في عملية التطوير. عندما تم تبنيها لأول مرة لتطوير البرمجيات، لم تكن هناك بدائل معترف بها للعمل الإبداعي القائم على المعرفة.
نموذج الشلال تاريخ النموذج
عقد أول عرض واصفاً استخدام مراحل مماثلة في هندسة البرمجيات من قبل هربيرت د. بينينجتون في ندوة حول أساليب البرمجة المتقدمة لأجهزة الكمبيوتر الرقمية يوم 29 يونيو عام 1956. ، وكان هذا عرض حول تطوير البرمجيات ل SAGE . عام 1983 أُعيد نشر الورقة مع تقديم من بينينجتون مشيراً إلى أن العملية لم تكن في الواقع من أعلى إلى أسفل ولكنها تعتمد على النموذج الأصلي.
وكثيرا ما يستشهد أول وصف رسمي لنموذج الشلال على أنه مقالة ونستون رويس التي طرحها عام 1970 ، وذلك رغم أن رويس لم يستخدم مصطلح شلال في تلك المادة. قام رويس بعرض هذا هذا النموذج على أنه نموذج خاطئ وغير عامل؛ وهي الطريقة التي تستخدم هذا المصطلح في الكتابة عن تطوير البرمجيات لوصف رؤية نقدية لممارسات تطوير البرمجيات شائعة الاستخدام.
أقرب استخدام لمصطلح «الشلال» قد يكون في ورقة بيل وثاير في عام 1976.
نموذج الشلال تاريخ النموذج
وفي عام 1985 حددت وزارة الدفاع في الولايات المتحدة هذا النهج في DOD-STD-2167A ، ومعاييرها للعمل مع مقاولي تطوير البرمجيات كانت تنص على أن «يقوم المقاول بتنفيذ دورة تطوير البرمجيات التي تشمل المراحل التالية: التصميم الأولي ثم التصميم التفصيلي ثم الترميز ووحدة الاختبار ثم التكامل ثم الاختبار».
نموذج الشلال النموذج
في نموذج الشلال الأصلي ل رويس، يتم اتباع المراحل التالية:
لا يجب لأحد ان ينتقل إلى المرحلة التالية إلا عندما يتم الانتهاء من المرحلة السابقة والتحقق منها.
يوجد نماذج مختلفة معدلة (بما في ذلك النموذج النهائي لرويس)، ويمكن أن تشمل اختلافات كبيرة على هذه العملية. هذه الاختلافات شملت العودة إلى الدورة السابقة بعد العثور على العيوب، أو العودة إلى الطريق لمرحلة التصميم، إذا تعتبر المراحل النهائية غير كافية.
نموذج الشلال لماذا نستخدمه؟
يوفر هذا النموذج نهج منظم من خلال مراحل منفصلة يسهل فهمها وتفسيرها، ويوفر المعالم التي يسهل التعرف عليها في عملية التطوير، ويمكن ان يكون مناسب لمشاريع حيث يتم اصلاح متطلبات نطاقها.
نموذج الشلال السلبيات
لا يمكن ان تعود خطوة، إذا مرحلة ما يوجد بها خطأ لا يمكن الرجوع اليها وتعديلها لانها تصبح العمليات معقدة في المرحلة، حتى لو تغيير بسيط في أي مرحلة سابقة يمكن ان يسبب مشاكل كبيرة للمراحل اللاحقة حيث ان جميع المراحل تعتمد على بعضها.
نموذج الشلال متى نستخدمه؟
عندما يكون لدينا متطلبات واضحة ولا توجد متطلبات غامضة ومعقدة، عندما يوجد موارد متوفرة بحرية وتوافر الخبرة.
عندما يكون لدى العميل ثقة عالية في المنظمة، والمشروع يكون صغير. يعتبر هذا النهج مثالياً للمشاريع التي تحتوي على متطلبات ثابتة وموارد وفيرة وجدول زمني ثابت وتكنولوجيا واضحة وثابتة، ولكنه لا يصلح مع المشاريع المُعقدة أو المشاريع غير المُستقرة، التي قد تتغير مُتطلباتها بشكل مُستمر ومفاجئ.
نموذج الشلال دعم الادلة
اقضاء وقت مبكر في دورة إنتاج البرمجيات يمكن من تجنب التكاليف في مراحل لاحقة، على سبيل المثال مشكلة وجدت في المراحل المبكرة (مثل متطلبات المواصفات) هي أرخص للإصلاح من نفس مشكلة وجدت في وقت لاحق في العملية (بمعامل 50 إلى 200).
في الممارسات الشائعة تؤدي منهجيات الشلال في الجدول الزمني للمشروع مع 20-40 ٪ من الوقت، استثمرت في المرحلتين الأولى والثانية، 30-40 ٪ من الوقت إلى الترميز، والباقي مخصص للاختبار والتنفيذ. وسوف تشمل معظم المشاريع المتوسطة والكبيرة مجموعة مفصلة من الإجراءات والضوابط التي تنظم كل عملية على المشروع.
نموذج الشلال دعم الادلة
وهناك حجة أخرى لنموذج الشلال وهو أنه يركز على وثائق (مثل المستندات ومتطلبات وثائق التصميم)، وكذلك شفرة المصدر. في منهجيات أقل مصممة بدقة وموثقة، تُفْقَد المعرفة إذا ترك أعضاء الفريق قبل أن يتم الانتهاء من المشروع، وأنه قد يكون من الصعب على مشروع ليتعافى من الخسارة. إذا كان مستند تصميم العمل بشكل كامل موجودة (كما هو القصد من تصميم كبير في خط الهجوم ونموذج الشلال)، وأعضاء فريق جديد أو حتى فرق جديدة تماما يجب أن تكون قادرة على التعرف من خلال قراءة الوثائق. Arcisphere technologies (2012). "Tutorial: The Software Development Life Cycle (SDLC)" (PDF). Retrieved 2012-11-13.
وفر نموذج الشلال نهج منظم؛ النموذج نفسه تقدم خطيا من خلال مراحل منفصلة، يسهل فهمها وتفسيرها، وبالتالي من السهل أن نفهم. كما يوفر المعالم التي يسهل التعرف عليها في عملية التنمية. ولعله لهذا السبب نموذج الشلال يستخدم كنموذج بداية لنموذج التنمية في العديد من النصوص هندسة البرمجيات والدورات.
نموذج الشلال النقد
العملاء قد لا يعرفون بالضبط ما هي متطلباتهم قبل أن يروا برنامج العمل وذلك بتغيير متطلباتها، مما أدى إلى إعادة تصميم، إعادة الإعمار، وإعادة الاختبار، وزيادة التكاليف.
المصممين قد لا يكون على بينة من صعوبات في المستقبل عند تصميم منتج البرنامج الجديد أو الميزة. في هذه الحالة، فمن الأفضل لإعادة النظر في التصميم من التمادي في التصميم الذي لا يأخذ في الحسبان أي المكتشفة حديثا القيود، والاحتياجات، أو مشاكل.
ردا على المشاكل التي لوحظت مع نموذج الشلال النقي، وأدخلت نماذج شلال تعديل، مثل «الساشيمي (الشلال مع مراحل متداخلة)، الشلال مع المشاريع الفرعية، والشلال مع الحد من المخاطر».
بعض المنظمات، مثل الولايات المتحدة وزارة الدفاع، لديها الآن التفضيل المعلن ضد منهجيات نوع شلال، بدءا MIL- STD- 498، والتي تشجع اكتساب التطوري والتنمية التكرارية وتدريجية.
في حين يجادل دعاة تطوير البرمجيات رشيقة نموذج الشلال هو عملية غير فعالة لتطوير البرمجيات، تشير بعض المتشككين بأن نموذج الشلال هو حجة كاذبة تستخدم بحتة لتسويق منهجيات التنمية البديلة
تصميم البرمجيات
تصميم البرمجيات هي عملية حل مشكلات و تخطيط لبرنامج حاسوبي. بعد أن تكون الغاية من توصيف البرمجية قد حددت، يقوم المبرمجون أو المصممون بتطوير خطة للبرمجية. تحتوي هذه الخطة على أمور تتعلق بمكونات و خوارزميات متدنية المستوى إضافة إلى نظرة لمعمارية البرمجية.
تصميم البرمجيات مفاهيم التصميم
توفر مفاهيم التصميم مصمم البرامج بأساس يمكن من خلاله تطبيق أساليب أكثر تطوراً. تطورت مجموعة من مفاهيم التصميم الأساسية. وهم على النحو التالي:
1- التجريد - التجريد هو عملية أو نتيجة التعميم عن طريق الحد من محتوى المعلومات لمفهوم أو ظاهرة يمكن ملاحظتها، عادة من أجل الاحتفاظ فقط بالمعلومات ذات الصلة لغرض معين. وهو عمل من تمثيل الميزات الأساسية دون تضمين الخلفية التفاصيل أو التفسيرات.
2- صقل - وهي عملية التفصيل . يتم تطوير التسلسل الهرمي من خلال تحليل بيان الدالة macroscopic بطريقة تدريجية حتى يتم الوصول إلى عبارات لغة البرمجة. في كل خطوة، يتم تحليل تعليمات واحدة أو عدة تعليمات لبرنامج معين إلى تعليمات أكثر تفصيلاً. التجريد وصقل مفاهيم تكميلية.
3- النمطيه_تنقسم بنية البرامج إلى مكونات تسمى الوحدات.
4- هندسة البرمجيات - وهي تشير إلى الهيكل العام للبرنامج والطرق التي يوفر بها هذا الهيكل السلامة النظرية للنظام. وستسفر بنية البرمجيات الجيدة عن عائد جيد على الاستثمار فيما يتعلق بالنتيجة المرجوة للمشروع، على سبيل المثال. من حيث الأداء والجودة والجدول الزمني والتكلفة.
تصميم البرمجيات مفاهيم التصميم
5- هرمية التحكم - هي بنية برنامج تمثل تنظيم مكون برنامجي وتتضمن تسلسل هرمي للتحكم.
6- التقسيم الهيكلي - يمكن تقسيم هيكل البرنامج إلى أفقياً وعمودياً. تحدد الأقسام الأفقية فروعًا منفصلة للتسلسل الهرمي المعياري لكل وظيفة برنامج رئيسية. يقترح التقسيم الرأسي أن يتم توزيع السيطرة والعمل من أعلى إلى أسفل في بنية البرنامج.
7- بنية البيانات - هي عبارة عن تمثيل للعلاقة المنطقية بين عناصر البيانات الفردية.
8- إجراءات البرنامج - وهو يركز على معالجة كل وحدة على حدة.
9-ا خفاء المعلومات - يجب تحديد وتصميم الوحدات بحيث لا يمكن الوصول إلى المعلومات الموجودة داخل الوحدة النمطية إلى الوحدات الأخرى التي لا تحتاج إلى مثل هذه المعلومات.
في نموذج وجوهه، ذكر جرادي بوخ التجريد، والتغليف، والوحدات، والتسلسل الهرمي كمبادئ أساسية لتصميم البرمجيات. يستخدم مصطلح PHAME (مبادئ التسلسل الهرمي والتجريد والتعديل والتكليف) في بعض الأحيان للإشارة إلى هذه المبادئ الأساسية الأربعة.
صيانة البرمجيات
في سياق هندسة البرمجيات، يشير مصطلح صيانة البرمجيات (بالإنجليزية: Software maintenance)‏ إلى التعديلات التي تجرى على منتج برمجي بعد التسليم بهدف تصحيح العيوب أو تحسين أداء البرمجية أو أي خاصية من خصائصها.
صيانة البرمجيات التاريخ
يعد مير إم. ليمان أول من تناول موضوع صيانة البرمجيات وتطوّر الأنظمة عام 1969. أدت أبحاثه التي استمرت لعشرين عامًا إلى صياغة قوانين ليمان (ليمان 1997). وأهم النتائج التي توصلت إلها أبحاثه هي أن الصيانة تَطوّر تدريجي حقيقي وأن قرارات الصيانة تُدعم بفهم ما يحدث للأنظمة (والبرمجيات) مع مرور الوقت. أثبت ليمان أن الأنظمة تستمر في التطور بمرور الوقت. ومع تطورها تصبح أكثر تعقيدًا ما لم تُتخذ بعض الإجراءات مثل إعادة تشكيل الكود لتقليل التعقيد.
أظهرت دراسة استقصائية شهيرة ومستشهد بها على نطاق واسع أجراها لينتز وسوانسون في أواخر السبعينيات، أن جزءًا كبيرًا جدًا من تكاليف دورة الحياة كانت تُنفق على الصيانة. صنّفوا أنشطة الصيانة إلى أربع فئات:
صيانة البرمجيات التاريخ
أظهر الاستقصاء أن نحو 75% من جهود الصيانة كانت تبذل في النوعين الأولين، واستهلك تصحيح الأخطاء نحو 21% منها. أشارت العديد من الدراسات اللاحقة إلى حجم مشاكل مماثل. تشير الدراسات إلى أن مساهمة المستخدمين النهائيين خلال جمع وتحليل بيانات المتطلبات الجديدة بالغة الأهمية. وهي السبب الرئيسي لأي مشكلة أثناء تطوير البرمجيات وصيانتها. تعد صيانة البرمجيات مهمة لأنها تستهلك جزءًا كبيرًا من تكاليف دورة الحياة الإجمالية، وعدم القدرة على تغيير البرمجيات بسرعة وموثوقية يعني خسارة فرص العمل.
صيانة البرمجيات أهمية صيانة البرمجيات
المسائل الرئيسية لصيانة البرمجيات هي المسائل الإدارية والفنية. المسائل الإدارية الرئيسية هي: التوافق مع أولويات العملاء، والتوظيف، وأي منظمة تقوم بالصيانة، وتقدير التكاليف. المسائل الفنية الرئيسية هي: الفهم المحدود، وتحليل أثر التغيير، والاختبار، وقياس إمكانية الصيانة.
تعد صيانة البرامج نشاطًا واسعًا للغاية يشمل تصحيح الأخطاء، وتحسين الإمكانيات، وإلغاء الإمكانيات القديمة، والتحسين (الأمثًلة). ولأنه لا بد من التغيير، يجب تطوير آليات للتقييم والتحكم وإجراء التعديلات.
لذا يعتبر أي عمل يجرى لتغيير البرمجيات بعد تشغيلها أعمال صيانة. الغرض منها هو الحفاظ على قيمة البرمجيات بمرور الوقت. يمكن تعزيز القيمة من خلال توسيع قاعدة العملاء، وتلبية المتطلبات الإضافية، وتسهيل الاستخدام، وزيادة الكفاءة واستخدام تقنية أحدث. قد تستمر عملية الصيانة لمدة 20 عامًا، في حين قد يتم التطوير في عام أو عامين.
صيانة البرمجيات تخطيط صيانة البرمجيات
تعد الصيانة جزءًا أساسيًا من البرمجيات، ما يتطلب إعداد خطة صيانة دقيقة أثناء تطوير البرمجيات. يجب أن تحدد كيفية طلب المستخدمين لإجراء تعديلات أو الإبلاغ عن المشاكل. يجب أن تتضمن الميزانية تقديرات الموارد والتكاليف. ويجب معالجة قرار جديد لتطوير كل ميزة جديدة للنظام وأهداف جودته. إن صيانة البرمجيات، التي قد تستمر لمدة تتراوح بين 5 إلى 6 سنوات (أو حتى عقود) بعد عملية التطوير، تتطلب خطة فعّالة يمكنها معالجة نطاق صيانة البرمجيات، تكييف عمليات ما بعد التسليم/النشر، وتحديد من الذي سيوفر الصيانة، وتقدير تكاليف دورة الحياة. إن اختيار التطبيق الصحيح للمعايير هو المهمة الصعبة منذ المراحل الأولى في هندسة البرمجيات والتي لم تكسب أهمية حاسمة لدى أصحاب المصالح المعنيين.
صيانة البرمجيات عمليات صيانة البرمجيات
يصف هذا القسم عمليات صيانة البرمجيات الستة كما يلي:
عملية تحليل المشكلة والتعديل، التي تنفذ عندما يصبح التطبيق من مسؤولية فريق الصيانة. يجب على مبرمج الصيانة تحليل كل طلب، وتأكيده (بإعادة إنتاج الحالة)، والتحقق من صلاحتيه، والتحقيق فيه، واقتراح حل وتوثيق الطلب، وأخيرًا الحصول على جميع التصريحات المطلوبة لتطبيق التعديلات.
تعتبر عملية الترحيل (ترحيل الأنظمة الأساسية مثلًا) وهي عملية استثنائية وليست جزءًا من مهام الصيانة اليومية. إذا كان يجب نقل البرمجيات إلى نظام أساسي آخر دون أي تغيير في الوظائف، تُستخدم هذه العملية ومن المحتمل أن يُعيّن فريق مشروع صيانة لهذه المهمة.
هناك عدد من العمليات والأنشطة والممارسات التي ينفرد بها القائمون على الصيانة، مثلًا:
محددات المتطلبات البرمجية
مواصفة متطلبات البرمجية (بالإنجليزية: Software Requirements Specification)‏ هي شرح كامل لسلوك النظام المزمع تطويره. تحتوي على مجموعة من حالات الاستخدام التي تصف كل التفاعلات ما بين المستخدم والبرمجية. إضافة إلى حالات الاستخدام، تحتوي مواصفة متطلبات البرمجية على شرح للمتطلبات اللاوظيفية.
منهجية تطوير برمجيات
في سياق هندسة البرمجيات، يستخدم مصطلح منهجية تطوير برمجيات (بالإنكليزية Software development methodology) للتعبير عن إطار العمل المتبع لهيكلة و تخطيط و السيطرة على عملية تطوير نظام معلوماتي. من الأمثلة الشائعة على منهجيات تطوير البرمجيات: الشلال و النماذج و التطوير المتزايد و التطوير الحلزوني و تطوير التطبيقات السريع و البرمجة القصوى. يمكن أن تتضمن المنهجية جوانب من بيئة التطوير و استخدام بعض منصات العمل (مثل المكتبات و الأدوات البرمجية).
منهجية تطوير برمجيات تاريخ
لم تظهر أطر عمل منهجيات تطوير البرمجيات حتى الستينيات من القرن العشرين. بحسب إليوت (Elliott 2004) فإن دورة حياة تطوير البرمجيات (systems development life cycle) يمكن أن يعتبر أقدم منهجية قد تم تشكيلها لبناء الأنظمة المعلوماتية. الفكرة الرئيسة في دورة حياة تطوير البرمجيات كانت في السعي إلى تطوير الأنظمة المعلوماتية بطريقة مدروسة و منظمة و متبعة للمنهجية العلمية، مما يتطلب من كل مرحلة من مراحل دورة حياة التطوير أن تضع فكرة تسليم النظام النهائي نصب عينيها.
كاسم، فإن منهجية تطوير البرمجيات هي عبارة أن إطار عمل يستخدم بهدف التنظيم و التخطيط و السيطرة على عملية تطوير نظام معلوماتي ما.
كفعل، فإن منهجية تطوير البرمجيات هي عبارة عن أسلوب يستخدم من قبل المؤسسات و فرق المشاريع لتطبيق إطار عمل منهجية تطوير البرمجيات (الاسم).
منهجية تطوير برمجيات أساليب منهجيات تطوير البرمجيات
كل أسلوب من أساليب منهجيات تطوير البرمجيات يعمل لتطبيق بعض أطر العمل في تطوير و صيانة البرمجيات. منذ بدء تكنولوجيا المعلومات، استخدم كثير من أساليب تطوير البرمجيات. من الأمثلة عليها:
حلزوني, لولبي إطار عمل يجمع ما بين الخطي و المتكرر.