Transcript ch3-ch5ppt

‫الفصل الثالث‬
‫عمليات البرمجيات‬
‫‪Software Processes‬‬
‫مقدمة‬
‫عمليات البرمجيات ‪Software Processes‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫هى مجموعة من األنشطة المترابطة المتماسكة المطلوبة لتطوير وانتاج‬
‫النظم البرمجية‪.‬‬
‫واألنشطة العامة هى‪ :‬توصيف المتطلبات‪ ،‬التصميم‪ ،‬التنفيذ‪ ،‬اإلختبار‪،‬‬
‫التحقق‪ ،‬الصيانة‪ ،‬إرتقاء النظم البرمجية‪.‬‬
‫وتمثل هذه األنشطة فى نموذج عمليات البرمجيات‪.‬‬
‫نماذج عمليات البرمجيات‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫نموذج العملية البرمجية ‪ Software process model‬هو تمثيل مجرد‬
‫لوصف العملية من منظور معين‪ ،‬ومن النماذج العامة لعمليات البرمجيات‪:‬‬
‫نموذج الشالل ‪ : The waterfall model‬وهى عبارة عن مراحل واضحة‬
‫المعالم منفصلة لوضع المواصفات والتطوير‪.‬‬
‫التطوير اإلرتقائى ‪:Evolutionary development‬‬
‫المواصفات مع التطوير‪.‬‬
‫وفيه‬
‫تتداخل‬
‫التطوير المعتمد على إعادة اإلستخدام ‪: Reuse-based development‬‬
‫بتجميع النظام من مكونات موجودة‪.‬‬
Waterfall model
‫نموذج الشالل‬
:‫مراحله‬
Requirements analysis and
.‫تعريف وتحليل وتحديد المتطلبات‬

.‫تصميم النظام وتصميم البرمجيات‬

.‫تنفيذ واختبار وحدات النظام‬

.‫تجميع النظام واختباره‬

definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
.‫عمل النظم وصيانته‬
Requirements
definition
Waterfall model
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
‫‪‬‬
‫‪‬‬
‫من عيوب نموذج الشالل صعوبة تقدير وتكييف التغييرات أثناء‬
‫العملية‪.‬‬
‫من مشاكل نموذج الشالل‪ :‬التقسيم غير المرن للمشروع إلى‬
‫مراحل منفصلة‪ ،‬يزيد من صعوبة اإلستجابة عن تغيير متطلبات‬
‫المستهلك‪ ،‬لهذا يصبح هذا النموذج مفيدا فقط ومرغوبا عند التفهم‬
‫الكامل للمتطلبات وقلة التغييرات فيها إلى الحد األدنى‪.‬‬
‫التطوير اإلرتقائى‬
‫‪Evolutionary development‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫نموذج تطوير إلنتاج البرمجيات تتداخل فيه المواصفات مع‬
‫التطوير‪.‬‬
‫التطوير اإلستكشافى‪ Exploratory development :‬الهدف‬
‫هو العمل مع المستهلك والتوصل إلى النظام النهائى من خالل‬
‫خطوط عامة تمهيدية للمواصفات ويجب البدء بمتطلبات مفهومة‬
‫جيدا‪.‬‬
‫النماذج األولية‪ Throw-away prototyping :‬الغرض هو‬
‫فهم متطلبات النظام ويجب البدء بمتطلبات مفهومة إلى حد ما‪.‬‬
Evolutionary development
Concurr ent
activities
Outline
description
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
‫‪‬‬
‫فى التطوير اإلرتقائى يتم وضع خطوط وصف عامة ثم تتم‬
‫متابعة العمل بأنشطة متالقية مساعدة لتحديد المواصفات التى‬
‫التى تعطى إصدا ار أوليا بمكن أن يتفاعل مرة أخرى مع تحديد‬
‫المواصفات لتغييرها وتعديلها وهكذا‪ ،‬ثم من تحديد المواصفات تبدأ‬
‫أعمال التطوير التى توفر إصدارات وسيطة تتفاعل بدورها مع‬
‫التطوير وتؤثر فيه وتتأثر به‪ ،‬ثم يتم التحقق من النظام للوصول‬
‫إلى اإلصدار النهائى‪ .‬تتفاعل أيضا مراحل تحديد المواصفات‬
‫والتطوير والتحقق مع بعضها البعض‪.‬‬
‫‪‬‬
‫‪‬‬
‫من مشاكل التطوير اإلرتقائى ‪ : Problems‬نقص وضوح‬
‫العمليات‪ ،‬فقر هيكلية النظم‪ ،‬وتحتاج مهارات خاصة‬
‫بلغات تسمح بالنماذج األولية السريعة‪.‬‬
‫قابلية تطبيق التطوير اإلرتقائى ‪ : Applicability‬للنظم‬
‫الصغيرة والمتوسطة الحجم ذات التفاعلية‪ ،‬وألج ازء من‬
‫النظم الكبيرة مثل واجهة المستخدم‪ ،‬وللنظم قصيرة األمد‪.‬‬
‫التطوير المبنى على إعادة اإلستخدام‬
‫‪Reuse-oriented development‬‬
‫‪‬‬
‫يعتمد على إعادة اإلستخدام التقليدى حيث يتم تجميع النظام من عدة مكونات‬
‫موجودة أو من نظم أخرى )‪.(Commercial-off-the-shelf‬‬
‫‪‬‬
‫مراحل العمليات‪Process stages .‬‬
‫‪‬‬
‫تحليل المكونات‪Component analysis .‬‬
‫‪‬‬
‫تعديل اإلحتياجات‪Requirements modification .‬‬
‫‪‬‬
‫تصميم النظام بإعادة اإلسنخدام‪System design with reuse .‬‬
‫‪‬‬
‫التطوير والتجميع‪Development and integration .‬‬
‫‪‬‬
‫خطواتها‪ :‬توصيف المتطلبات‪ ،‬تحليل المكونات‪ ،‬تعديل المتطلبات‪ ،‬تصميم النظام‬
‫بإعادة اإلستخدام‪ ،‬التطوير والتجميع‪ ،‬التحقق من النظام‪.‬‬
Reuse-oriented development
Requirements
specification
Component
analysis
Requirements
modification
System design
with reuse
Development
and integration
System
validation
‫تكرار العمليات ‪Process iteration‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫دائما ما تستخرج متطلبات النظام من سير المشروع لهذا تتكرر العملية ويعاد‬
‫العمل على المراحل المبكرة من المشروع خاصة فى النظم الكبيرة‪ ،‬وقد يتم‬
‫التكرار المتتالى فى أى عملية أو فى أى نموذج‪ ،‬وهناك منهجيتان للتكرار هما‪:‬‬
‫التطوير المتزايد أو التطوير بنموذج الحلزون‪.‬‬
‫التطوير المتزايد‪ Incremental development :‬بدال من التوصل إعداد‬
‫النظام مرة واحدة بقسم التطوير والتسليم إلى أجزاء متزايدة يقوم كل منها بتوفير‬
‫وظيفة مطلوبة‪ ،‬وتكون لمتطلبات المستخدمين أعلى أولوية‪ ،‬وتوضع المتطلبات‬
‫ذات األولوية األعلى فى األجزاء المبكرة من النظام‪.‬‬
‫تعريف الخطوط العريضة للمتطلبات‪ ،‬تخصيص المتطلبات لألجزاء المتزايدة‪،‬‬
‫تصميم معمارية النظام‪ ،‬تطوير أجزاء تزايد النظام‪ ،‬تحقق من التزايد‪ ،‬تجميع‬
‫األجزاء المتزايدة‪ ،‬التحقق من النظام حتى نصل للنظام النهائى‪.‬‬
Incremental development
Define outline
requirements
Develop system
increment
Assign requirements
to increments
Valida te
increment
Design system
architecture
Integrate
increment
Valida te
system
Final
system
System incomplete
‫البرمجة القصوى أو الطرفية‬
‫‪Extreme programming‬‬
‫‪‬‬
‫تعتمد على التطوير والتسليم لمكونات وأجزاء صغيرة جدا من‬
‫وظائف النظام بالطريقة المتزايدة‪ ،‬ويعتمد على تحسين الشفرة‬
‫الثابتة‪ ،‬وتضمين الزبون فى فريق التطوير والبرمجة السريعة‪.‬‬
‫التطوير الحلزونى‬
‫‪Spiral development‬‬
‫‪‬‬
‫يمثل تطوير العمليات على هيئة لولبية بدال من تتابع متتال‬
‫لألنشطة أو التتابع المتتالى مع الرجوع عكسيا لمزيد من التحسين‪،‬‬
‫وتمثل كل حلقة من الحلزون مرحلة من مراحل العملية‪ ،‬والتوجد‬
‫مراحل ثابتة مثل توصيف المتطلبات أو التصميم‪ ،‬ويتم إختيار‬
‫الحلقات فى الحلزون بناء على ما هو مطلوب‪ ،‬ويتم تقدير‬
‫المخاطر وتحليلها وحل أمورها خالل العمليات‪.‬‬
Spiral model of the software
process
Determine objectives
alternatives and
constraints
Risk
analysis
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Plan next phase
Integration
and test plan
Prototype 3
Prototype 2
Risk
analysis Prototype 1
Operational
protoype
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Requirement
validation
Product
design
Detailed
design
Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product
‫قطاعات نموذج الحلزون‬
‫‪Spiral model sectors‬‬
‫‪‬‬
‫فى الربع األول من الحلزون يتم تحديد األهداف والبدائل والقيود‪،‬‬
‫فى الربع الثانى يتم تقييم البدائل وتعريف وتحليل المخاطر‪ ،‬فى‬
‫الربع الثالث يتم التطوير والتأكد من منتج المرحلة التالية‪ ،‬وفى‬
‫الربع األخير يتم تخطيط المرحلة التالية‪.‬‬
‫مواصفات البرمجيات‬
‫‪Software specification‬‬
‫‪‬‬
‫هى عملية وضع وتحديد الخدمات المطلوبة والقيود المفروضة‬
‫على تشغيل النظام وتطويره‪ ،‬وتتضمن عملية هندسة المتطلبات‪،‬‬
‫دراسة الجدوى‪ ،‬إستنباط وتحليل المتطلبات‪ ،‬تحديد مواصفات‬
‫المتطلبات‪ ،‬التحقق من المتطلبات‪.‬‬
‫عملية هندسة اإلحتياجات‬
‫‪‬‬
‫ينتج عن دراسة الجدوى تقرير جدوى ومن إستنباط وتحليل‬
‫المتطلبات يتم تقديم نماذج النظام‪ .‬عند توصيف المتطلبات يجرى‬
‫تحديد متطلبات المستخدم والنظام‪ ،‬وبعد التحقق من المتطلبات‬
‫يتم توثيق المتطلبات الناتجة عن متطلبات النظام والمستخدم‪.‬‬
The requirements engineering
process
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
‫تصميم وتنفيذ البرمجيات‬
‫‪Software design and implementation‬‬
‫‪‬‬
‫هى العملية الناتجة عن تحويل مواصفات النظام إلى نظام‬
‫تنفيذى‪ ،‬وقى تصميم البرمجيات يتم تصميم هيكل البرمجيات التى‬
‫تحقق هذه المواصفات أما التنفيذ فيعنى تحويل هذا الهيكل إلى‬
‫برامج تنفيذية‪ ،‬وتتصل أنشطة التصميم والتنفيذ ببعضها البعض‬
‫إتصاال وثيقا وقد تتداخل فيما بينها‪.‬‬
‫أنشطة عملية التصميم‬
‫‪Design process activities‬‬
‫‪‬‬
‫هى‪ :‬تنفيذ التصميم المعمارى‪ ،‬عمل تجريد للمواصفات‪ ،‬تصميم‬
‫واجهة اإلستخدام‪ ،‬تصميم المكونات‪ ،‬تصميم هيكل البيانات‪.‬‬
‫عمليات تصميم البرمجيات‬
‫‪The software design process‬‬
‫‪‬‬
‫بعد تحديد مواصفات المتطلبات تمر أنشطة التصميم بعدة مراحل‬
‫تبدأ بتحديد معمارية التصميم الذى يقود إلى موجز مجرد‬
‫للمواصفات ثم يتم تصميم واجهة اإلستخدام وتصميم مكونات‬
‫وهيكل البيانات وتصميم الخطوات المنطقية للتنفيذ‪.‬‬
The software design process
Requirements
specification
Design activities
Architectural
design
Abstract
specification
Interface
design
Component
design
Data
structure
design
Algorithm
design
Sy stem
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Design products
‫‪‬‬
‫منتجات أنشطة التصميم هى معمارية النظام‪ ،‬مواصفات‬
‫البرمجيات‪ ،‬مواصفات واجهة اإلستخدام‪ ،‬مواصفات المكونات‪،‬‬
‫مواصفات هيكل البيانات‪.‬‬
‫طرق التصميم‪Design methods :‬‬
‫‪‬‬
‫منهجيات نمطية لتطوير تصميم البرمجيات‪ ،‬يتم توثيق التصميم‬
‫كمجموعة نماذج رسومية‪ ،‬والنماذج المحتملة منها‪ :‬نموذج تدفق‬
‫البيانات‪ ،‬نموذج خصائص الجزئيات‪ ،‬النموذج الهيكلى‪ ،‬ونماذج‬
‫الكائن‪.‬‬
‫البرمجة واكتشاف وتصحيح العلل‬
‫‪Programming and debugging‬‬
‫‪‬‬
‫تبدأ بتحديد المشكلة وتحديد الخطأ فى البرنامج‪ ،‬يتبعها تصميم‬
‫إصالح العطل‪ ،‬ثم إصالح الخطأ‪ ،‬واعادة إختبار البرنامج‪.‬‬
The debugging process
Locate
error
Design
error repair
Repair
error
Re-test
program
‫التحقق من البرمجيات ‪Software validation‬‬
‫‪‬‬
‫ثبوت الصحة والتأكيد والتحقق هو بيان أن النظام يطابق المواصفات ويلبى‬
‫متطلبات المستهلك‪.‬‬
‫عمليات الفحص واإلختبار‪The testing process :‬‬
‫‪‬‬
‫تتضمن إختبار المكونات‪ :‬إختبار الوحدات‪ ،‬إختبار المركب البرمجى‪.‬‬
‫‪‬‬
‫يحتوى إختبار التجميع على‪ :‬إختبار النظم الفرعية‪ ،‬واختبار النظام‪.‬‬
‫‪‬‬
‫يعنى إختبار القبول‪ :‬إختبار يقوم به المستخدم‪.‬‬
The testing process
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
testing
Integration testing
User
testing
‫مراحل اإلختبار‬
‫‪Testing stages‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫إختبار الوحدات ‪ Unit testing‬بإختبار األجزاء المنفردة‪.‬‬
‫إختبار المركبات البرمجية ‪ Module testing‬بإختبار المجموعات المرتبطة‬
‫من األجزاء التى تعتمد عل بعضها البعض‪.‬‬
‫إختبار النظام الفرعى ‪ : Sub-system testing‬بتجميع المكونات البرمجية‬
‫فى نظام فرعى واختبارها‪ ،‬ويتم التركيز على إختبار واجهة المستخدم‪.‬‬
‫إختبار النظام ‪ System testing‬بإختبار النظام ككل واختبار الخصائص‬
‫المنبثقة‪.‬‬
‫إختبار القبول ‪ Acceptance testing‬بإختبار النظام ببيانات المستهلك‬
‫لفحص قبوله‪.‬‬
Testing phases
Requir ements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
System
design
Acceptance
test
Detailed
design
Sub-system
integration
test plan
System
integration test
Sub-system
integration test
Module and
unit code
and tess
‫إرتقاء البرمجيات‪Software evolution :‬‬
‫‪‬‬
‫كلما تغيرت المتطلبات خالل تغير ظروف األعمال فإن‬
‫البرمجيات التى تدعم هذه األعمال يجب أن تتضمن التغيرات‬
‫الجديدة وأن تتغير وتتكيف تبعا لذلك‪.‬‬
‫إرتقاء النظام‪System evolution :‬‬
‫يتضمن األنشطة األتية‪:‬‬
‫‪‬‬
‫تعريف متطلبات النظام‪ ،‬تقييم النظم الموجودة‪ ،‬إقتراح تغييرات‬
‫النظام‪ ،‬تعديل النظام‪ ،‬وصوال للنظام الجديد‪.‬‬
System evolution
Define system
requirements
Assess existing
systems
Existing
systems
Propose system
changes
Modify
systems
New
system
‫الفصل الرابع‬
‫إدارة المشروع‬
‫‪Project management‬‬
‫مقدمة‬
‫‪‬‬
‫اإلدارة الجيدة للمشروع هى أقوى وأهم عوامل نجاح‬
‫المشروع‪ ،‬وتسبب الطبيعة غير الملموسة للبرمجيات‬
‫المشاكل المتعددة فى إدارة المشروعات‪ .‬وبالرغم من إتباع‬
‫القواعد فإن أهم األنشطة التى لها تأثير قوى هى ‪:‬‬
‫التخطيط‪ ،‬التوقع‪ ،‬وجدولة المهام‪.‬‬
‫أنشطة اإلدارة‬
‫‪Management activities‬‬
‫‪‬‬
‫تتضمن‪ :‬كتابة المقترح‪ ،‬تخطيط المشروع وجدولته‪ ،‬تكاليف‬
‫المشروع‪ ،‬مراقبة المشروع‪ ،‬إعادة تقدير الوقف‪ ،‬اإلختيار‬
‫الشخصى والتقييم‪ ،‬كتابة التقرير والعروض التقديمية‪.‬‬
‫عموميات اإلدارة‬
‫‪Management commonalities‬‬
‫‪‬‬
‫هيئة أو طاقم المشروع‪ :‬قد ال يمكن تخصيص األشخاص المناسبين‬
‫للعمل فى المشروع‪ ،‬كما ال تسمح الميزانية المخصصة للمشروع‬
‫بإستخدام طاقم من األفراد لهم تكلفة عالية‪ ،‬وقد ال يكون متاحا توفر‬
‫األشخاص الذين يملكون الخبرة المرغوب فيها‪ ،‬وقد ترغب المؤسسة فى‬
‫تطوير مهارات األفراد والموظفين العاملين لديها من خالل مشروع‬
‫البرمجيات‪ ،‬ويحب أن يعمل جهاز اإلدارة فى إطار هذه القيود خاصة‬
‫عندما يكون هناك قصور فى توافر المتخصصين المهرة فى مجال‬
‫تقنية المعلومات وهى الحالة التى تصادف العمل فى مشروعات‬
‫البرمجيات‪.‬‬
‫تخطيط المشروع‬
‫‪Project planning‬‬
‫‪‬‬
‫هو الوقت الكبير المستهلك فى أنشطة إدارة المشروع‪ ،‬وهى‬
‫أنشطة مستمرة من التصور المبدئى حتى تسليم المشروع‪ ،‬ويجب‬
‫أن تتم مراجعة الخطط بإنتظام كلما أتيحت معلومات جديدة‪،‬‬
‫ويمكن تطوير العديد من أنواع الخطط التى تلبى ما يحتاجه دعم‬
‫خطة مشروع البرمجيات مكن ميزانية وجدولة‪.‬‬
Types of project plan
Plan
Quality plan
Validation plan
Configuration
management plan
Maintenance plan
Staff development plan.
Des cription
Des cribes the quality
procedures and
s tandards that will be us ed in a project.
Des cribes the approach, resources and
s chedule used for sys tem validation.
Des cribes the configuration management
procedures and structures to be us ed.
Predicts the maintenance requirements of
the s ystem, maintenance cos ts and
effort
required.
Des cribes how the skills and experience of
the project team
members will be
developed.
‫عملية تخطيط المشروع‬
‫‪Project planning process‬‬
‫‪‬‬
‫تقدير قيود المشروع‪.‬‬
‫‪‬‬
‫عمل تقييمات تمهيدية لمعامالت المشروع‬
‫‪‬‬
‫تعريف أحداث المشروع الهامة وقابلية التسليم‪.‬‬
Project planning process
Establish the project cons traints
Make initial as sess ments of the project parameters
Define project m iles tones and deliverables
while project has not been com pleted or cancelledloop
Draw up project schedule
Initiate activities according to s chedule
Wait ( for a while )
Review project progres s
Revise estimates of project parameters
Update the project s chedule
Re-negotiate project constraints and deliverables
if ( problems arise )then
Initiate technical review and pos sible revis ion
end if
end loop
‫هيكل خطة المشروع يتكون من‬
‫‪Project plan structure‬‬
‫‪‬‬
‫مقدمة‪ ،‬تنظيم المشروع‪ ،‬تحليل المخاطر‪ ،‬متطلبات موارد العتاد‬
‫والبرمجيات‪ ،‬تقسيم العمل‪ ،‬جدولة المشروع‪ ،‬مراقبة اآللية وتقريرها‪.‬‬
‫تنظيم األنشطة‬
‫‪Activity organization‬‬
‫‪‬‬
‫يجب تنظيم األنشطة فى المشروع إلنتاج مخرجات واضحة‬
‫ملموسة لإلدارة للحكم على تقدم المشروع‪ ،‬األحداث الهامة‬
‫والمعالم الرئيسية هى نقطة النهاية وغاية نشاط العمليات‪ ،‬قابلية‬
‫التسليم هى نتائج المشروع التى تسلم إلى المستهلك‪ ،‬تسمح‬
‫عمليات الشالل بالتعريف المباشر الواضح والتقديم لألحداث‬
‫الهامة‪.‬‬
‫جدولة المشروع‬
‫‪Project scheduling‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تقسيم المشروع إلى مهام‪ ،‬تخمين الوقت والموارد الالزمة إلكتمال‬
‫كل مهمة‪.‬‬
‫عملية جدولية مهام المشروع‪:‬‬
‫من هندسة المتطلبات يتم تعريف األنشطة وتعريف إعتمادية‬
‫األنشطة وتقدير موارد األنشطة وتخصيص البشر لإلنشطة إنشاء‬
‫مخططات المشروع للحصول على المخططات البيانية لألنشطة‪.‬‬
The project scheduling process
Identify
activities
Software
requirements
Identify activity
dependencies
Estimate resources
for activities
Allocate people
to activities
Create project
charts
Activity charts
and bar charts
‫مشاكل جدولة المهام‬
‫‪The project scheduling process‬‬
‫‪‬‬
‫توقع صعوبة المشاكل‪ ،‬وبالتالى صعوبة تكلفة حلول التطوير‪.‬‬
‫‪‬‬
‫التتناسب اإلنتاجية مع عدد األشخاص القائمين على تنفيذ‪.‬‬
‫‪‬‬
‫إضافة األشخاص إلى مشروع متأخر قد يزيد التأخير سبب أعباء‬
‫اإلتصاالت‪.‬‬
‫المخططات البيانية وشبكة األنشطة‬
‫‪Bar charts and activity networks‬‬
‫‪‬‬
‫تدوين رسومى يستخدم لتمثيل جدولة مهام المشروع‪ ،‬ويبين تقسيم‬
‫المشروع إلى مهام‪ ،‬واليجب أن تكون المهام قصيرة جدا بحيث‬
‫تتراوح مدتها بين أسبوعين‪ ،‬وتبين مخططات األنشطة إعتمادية‬
‫األنشطة والمسار الحرج لها‪ ،‬وتبين أعمدة المخططات جدولة‬
‫المهام مع وقت التقويم التاريخى‪.‬‬
Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Task durations and
dependencies
Duration (da ys)
8
15
15
10
10
5
20
25
15
15
7
10
Dependencies
T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4 (M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8)
Activity network
‫شبكة األنشطة‬
8 days
15 days
M1
T3
15 days
T9
T1
25/7/99
4/7/99
start
14/7/99
5 days
4/8/99
25/8/99
T6
M4
M6
M3
7 days
20 days
15 days
T7
T2
25/7/99
10 days
M2
T4
T11
10 days
M7
T5
5/9/99
11/8/99
T10
18/7/99
M8
15 days
10 days
T12
M5
25 days
T8
Finish
19/9/99
Activity timeline
‫لألنشطة‬
‫الخط الزمنى‬
4/ 7
11/ 7
18 /7
25 /7
1/ 8
8/ 8
15 /8
22 /8
29 /8
5/ 9
12 /9
19 /9
St art
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T 10
M6
T 11
M8
T 12
Fi nish
Staff allocation
‫العمل‬
‫تخصيص طاقم‬
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
T7
T5
T10
12/9
19/9
‫إدارة المخاطر‬
‫‪Risk management‬‬
‫‪‬‬
‫‪‬‬
‫تهتم إدارة المخاطر بتعريف المخاطر ورسم الخطط لتقليل تأثيرها‬
‫على المشروع‪.‬‬
‫المخاطرة هى إحتما حدوث ظرف مناوئ‪ ،‬وتؤثر مخاطر المشروع‬
‫على جدولة المهام والموارد‪ ،‬وتؤثؤ مخاطر المنتج على كفاءة‬
‫وأداء البرمجيات التى يجرى تطويرها‪ ،‬وتؤثر مخاطر األعمال‬
‫على تطوير المنظمة أو إنتاج البرمجيات‪.‬‬
‫عملية إدارة المخاطر وتتضمن‬
‫‪The risk management process‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تعريف المخاطرة‪ :‬بتعريف مخاطر المشروع‪ ،‬والمنتج واألعمال‪.‬‬
‫تحليل المخاطرة‪ :‬بتخمين وتقييم وترجيح اإلحتماالت والنتائج‬
‫المنطقية لهذه المخاطر‪.‬‬
‫تخطيط المخاطرة‪ :‬مراقبة المخاطر خالل المشروع‪.‬‬
The risk management process
Risk
identification
Risk analysis
Risk planning
Risk
monitoring
List of potential
risks
Prioritised risk
list
Risk avoidance
and contingency
plans
Risk
assessment
‫تعريف المخاطرة‬
Risk identification
‫ مخاطر‬،‫ المخاطر التنظيمية‬،‫ مخاطر البشر‬،‫مخاطر التقنية‬
.‫ مخاطر التقييم‬،‫المتطلبات‬
Organisational - People risks - Technology risks
Estimation risks - Requirements risks -risks


‫المخاطر وأنواعها‬
‫فيما يلى نوع المخاطرة والمخاطر المحتملة‪:‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫مخاطرة تقنية‪ :‬قد ال تتمكن قاعدة البيانات المستخدمة فى النظام‬
‫من العمل والمعالجة كلما زاد معدل إنتقال البيانات الكثير المتوقع‬
‫مع الوقت‪.‬‬
‫البشر‪ :‬حاجة إمداد طاقم العمل بمهارات مطلوبة‪.‬‬
‫التنظيمية‪ :‬إعادة تشكيل بنية المنظمة قد يؤدى إلى إدارة مختلفة‬
‫مسئولة عن المشروع‪.‬‬
‫المخاطر وأنواعها‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫(تابع)‬
‫األدوات‪ :‬الشفرة الملدة بواسطة أدوات هندسة البرمجيات بمساعدة‬
‫الكمبيوتر غير كافية‪ ،‬كما قد اليمكن تجميع أو توافر تكامل‬
‫أدوات هندسة البرمجبات بمساعدة الكمبيوتر‪.‬‬
‫المتطلبات‪ :‬تغيير المتطلبات تحتاج إعادة أعمال لتصميم‪ ،‬كما قد‬
‫يفشل الزبون فى فهم حتمية تغيير المتطلبات‪.‬‬
‫التقدير‪ :‬عدم التخمين والتقدير الصحيح للوقت المطلوب فى‬
‫تطوير البرمجيات‪ ،‬كما قد اليكون هناك تخمين وتقدير صحيح‬
‫إلصالح األعطال‪ ،‬وحجم البرمجيات‪.‬‬
‫تحليل المخاطر‬
‫‪Risk analysis‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تخمين وتقدير إحتمالية ومدى جدية كل خطر‪ ،‬وقد يكون إحتمال‬
‫الخطر منخفضا أو متوسطا أو عاليا جدا‪ ،‬وقد تكون تأثيرات‬
‫الخطر فاجعة أو خطيرة أو مقبولة أو ضئيلة غير مؤثرة‪.‬‬
‫تخطيط المخاطر‪:‬‬
‫وضع كل مخاطرة فى اإلعتبار‪ ،‬وتطوير إستراتيجية للتعامل مع‬
‫هذه المخاطرة‪.‬‬
‫مراقبة المخاطرة‬
‫‪Risk monitoring‬‬
‫‪‬‬
‫تقدير كل المخاطر المعرفة على فترات منتظمة لتقدير ما إذا‬
‫كانت سوف تصبح أقل أو أكثر إحتماال‪ .‬أيضا تقدير ما إذا كانت‬
‫تأثيرات المخاطرة قد تغيرت‪ .‬يجب مناقشة كل مخاطرة رئيسية فى‬
‫إجتماعات تقدم إدارة المشروع الدورية‪.‬‬
‫الفصل الخامس‬
‫لغة النمذجة الموحدة‬
‫‪UML‬‬
‫مقدمة‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫تقدم لغة النمذجة الموحدة مجموعة من أفضل خبرات الممارسات‬
‫الهندسية التى ثبت نجاحها فى نمذجة النظم الكبيرة والمعقدة‪ ،‬وهى جزء‬
‫مهم من التطوير الكائنى المنحى للبرمجيات وعمليات تطوير‬
‫البرمجيات‪.‬‬
‫ليست لغة النمذجة الموحدة منهجية لبناء أو تصميم البرمجيات‬
‫وتطويرها‪.‬‬
‫ال ترتبط لغة النمذجة الموحدة بمنهجية أو طرق إنتاج البرمجيات‪،‬‬
‫ويمكن توظيف هذه اللغة على مختلف العمليات البرمجية بغض النظر‬
‫عن المنهجية المتبعة‪.‬‬
‫تتألف لغة النمذجة الموحة من أربع طبقات أساسية تقسم كل طبقة بدورها إلى‬
‫طبقات فرعية وهى بناء على التجريد تقسم إلى‪:‬‬
‫طبقة كائنات المستخدم‬
‫‪User Objects Layer‬‬
‫‪‬‬
‫‪‬‬
‫هى الطبقة السطحية العامة التى يستخدمها الذين يتعاملون مع لغة‬
‫النمذجة الموحدة‪ ،‬وتتألف من تسعة مخططات رئيسية باإلضافة إلى‬
‫كائنات وأدوات مساعدة وهى الطبقة األكثر وضوحا وتوصيفا‪ ،‬وتشرح‬
‫كتب تعليم اللغة هذه الطبقة‪ ،‬والمستخدم هنا المقصود هو مستخدم‬
‫اللغة وليس المستخدم النهائى للبرمجية أو المنتج البرمجى‪ ،‬تشمل‬
‫الطبقة األولى المخططات التسعة التالية‪.‬‬
‫مخطط حاالت إلستخدام‪ ،‬مخطط الفئة‪ ،‬مخطط الكائن‪ ،‬مخطط‬
‫النشاط‪ ،‬مخطط التعاون‪ ،‬مخطط الحالة‪ ،‬مخطط التتابع‪ ،‬مخطط‬
‫المكونات‪ ،‬مخطط التوزيع‪.‬‬
‫الطبقة الثانية تسمى طبقة النموذج‬
‫‪Model Layer‬‬
‫‪‬‬
‫وتكون فى المرحل األولى من التحليل حيث تحتوى على‬
‫مفاهيم موضوع التحليل كفهم النظام بشكل عام أو مجال‬
‫التحليل أو مجال النظام‪ ،‬ويستخدم هذه الطبقة محلل النظام‬
‫أثناء عمله قبل نضج فكرة النظام أو وضوحه بتوصيف أقل‬
‫من طبقة المستخدم األولى‪.‬‬
‫الطبقة الثالثة‪ :‬طبقة ما وراء النموذج‬
‫‪Meta Model Layer‬‬
‫‪‬‬
‫وتعنى هذه الطبقة بالمفاهيم المتعلقة بلغة النمذجة الموحدة‬
‫كمفهوم الصنف والظاهرة ونوع البيانات والتجريد واألنماط‬
‫وغيرها من مفاهيم اللغة‪ ،‬وهى طبقة تصف ما يجرى فى‬
‫النموذج وتتألف من ثالث حزم رئيسية هى‪ :‬حزمة األساس‬
‫حزمة العناصر السلوكية‪ ،‬حزمة إدارة النموذج‪.‬‬
‫الطبقة الرابعة‪ :‬طبقة ما وراء ما وراء النموذج‬
‫‪Meta meta model layer‬‬
‫‪‬‬
‫طبقة ال تهم معظم محللى النظم حيث تشكل أساس اللغة‬
‫وتهتم بلغة كتابة النمذجة الموحدة‪ ،‬وتهم مطورى أدوات لغة‬
‫النمذجة الموحدة مثل البرامج التى تؤتمت المخططات‬
‫وترسمها‪.‬‬
‫مكونات لغة النمذجة الموحدة‬
‫‪UML Components‬‬
‫‪‬‬
‫‪‬‬
‫تحتوى على عدد من العناصر الرسومية التى تدمج مع المخططات‪،‬‬
‫وألنها لغة فإن لها قواعدها فى دمج هذه العناصر‪.‬‬
‫أن الهدف من المخططات هو تقديم النظام من وجهات نظر متعددة‪،‬‬
‫وهذه المجموعة المتعددة من وجهات النظر تسمى بالنموذج‪ ،‬فنموذج‬
‫لغة النمذجة لموحدة يصف ما المفروض أن يفعله النظام‪.‬‬
‫وتحتوى اللغة على تسعة نماذج أساسية هى‬
‫مخطط األنشطة‬
‫‪‬‬
‫مخطط الفئات‬
‫‪‬‬
‫‪‬‬
‫مخطط الكائن‬
‫‪‬‬
‫‪‬‬
‫مخطط حالة اإلستخدام‬
‫‪‬‬
‫مخطط المكون‬
‫‪‬‬
‫مخطط الحالة‬
‫‪‬‬
‫مخطط التجهيز‬
‫‪‬‬
‫مخطط التتابع‬
‫مخطط التعاون‬
‫أنواع مخططات لغة النمذجة الموحدة‬
‫‪UML Diagrams‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫مخطط حالة اإلستخدام‪ :‬التى تعرض العالقة بين الفعلة ‪actors‬‬
‫وحاالت اإلستخدام‪.‬‬
‫مخططات الفئة‪ :‬التى تنمذج هيكل الفئة المحتويات بإستخدام عناصر‬
‫التصميم مثل الفئات والحزم والكائنات وتعرض أيضا العالقات مثل‬
‫المحتوى والوراثة واإلرتباطات وغيرها‪.‬‬
‫مخططات التفاعل‪ :‬وتشمل‬
‫مخطط التتابع‪ :‬الذى يعرض التتابع الزمنى للكائنات المشاركة فى‬
‫التفاعل‪ ،‬ويتكون من بعد رأسى للزمن وبعد افقى للكانئات المختلفة‪.‬‬
‫أنواع مخططات لغة النمذجة الموحدة‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫(تابع)‬
‫مخطط التعاون‪ :‬ويعرض التفاعالت التى تنتظم حول الكائنات‬
‫والوصالت بينها وبعضها البعض‪ ،‬وتستخدم األرقام لبيان تتابع‬
‫الرسائل‪.‬‬
‫مخطط الحالة‪ :‬يعرض تتابع الحاالت التى يكون عليها كائن التفاعل‬
‫خالل دورة حياته إستجابة إلستقبال تنيه مع إستجابته وأفعاله‪.‬‬
‫مخطط النشاط‪ :‬يعرض مخطط حالة خاصة حيث تكون معظم‬
‫الحاالت حاالت أفعال ومعظم التعامالت تم قدحها بواسطة إتمام أفعال‬
‫الحاالت المصدر‪ ،‬ويركز هذا المخطط على التدفقات المقادة بالمعالجة‬
‫الداخلية‪.‬‬