ممكن الإفادة لو سمحتوا؟؟؟؟

لا حول ولا قوة إلا بالله

أين الردود؟؟؟؟؟؟؟؟

حسنا يا اخى سارفع لك ما يوضح لك الفرق

الموسوعة العربیة للكمبیوتر/ قسم الدورات التعلیمیة

سلسلة كتب الدورات التعلیمیة الإلكترونیة

C4arab.com

ھندسة البرمجیات

Software Engineering

في ستة أيام......

تألیف

أسماء المنقوش

مشرفة ساحة لغات البرمجة

یسمح بتوزیع الكتاب على صورته الإلكترونیة لكن لا یسمح بطبع الكتاب أو تغییر هیئته

إلا بعد أخذا إذن من الكاتب

2000-2005 جمیع الحقوق محفوظة - © الموسوعة العربیة للكمبیوتر والإنترنت

1

التواصل مع القراء

العزیز ،،، القارئ إلى

حرصت الموسوعة العربیة للكمبیوتر والإنترنت _ ومن منطلق اهتمامها العام بعلوم الحاسب والتقنیة

واهتمامها الخاص بتقدیم هذه العلوم باللغة العربیة _ على تقدیم هذه السلسة من

الكتب الإلكترونیة التى نتمنى أن تحقق طموحات القارئ العربى الذى اعتاد على قراءة أجو د

. المطبوعات بكافة اللغات العالمیة

إن الموسوعة العربیة _من خلال هذه السلسلة _ تطمح لتقدیم سلسلة من الكتب بمستوى عالٍ من

الجودة ، الشيء الذى لن یتحقق بدون ملاحظاتكم واقتراحاتكم حول السلسلة _ طریقة الكتابة ،

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

الخ

ننتظر سماع أراءكم على البرید الإلكتروني المخصص لذلك

ebooks@c4arab.com

نرجو ذكر اسم الكتاب والكاتب والطبعة مع ذكر ملاحظاتكم لنا

تهانى السبیت

مشرفة الموسوعة العربیة للكمبیوتر والإنترنت

2

.. بسم الله الرحمن الرحیم ..

الدورات التعلیمیة .. ھي مجموعة من الدورات

التي تقدمھا لكم الموسوعة العربیة؛ بدأنا بتقديمھا

في الصیف تحت مسمى " الدورات الصیفیة " وھا

ھي تعود من جديد . حرصنا على تقديم دورات في

مجالات مختلفة لنراعي أغلب الاھتمامات كما

حرصنا على انتقاء الدورات المفیدة، غیر المتكررة،

بطريقة جادة تنقلك إلى الجو الدراسي في قاعات

الجامعة و صفوف المعاھد و لكن في بیئة

إلكترونیة! كل ھذا مجانا! ...

يوجد كذلك ساحة متخصصة لھا ضمن مجموعة

ساحات الموسوعة العربیة للنقاش والأسئلة،

تجدھا ھنا! ...

استفد واستثمر وقتك معنا! إذا كنت ترغب في

تطوير ذاتك و توسیع نطاق ثقافتك في الحاسوب

فاستغل كل دقیقة واستفد معنا! و لا تنسى أننا

في عصر المعلومات والسرعة.

ابدأ الآن !انتقل لصفحة الدورات و اختر الدورة التي تناسبك، انتقل لصفحة الأساتذة للاطلاع على

قائمة الأساتذة الّذين سیلقون المحاضرات ،انتقل لصفحة التسجیل كي تسجّل نفسك في إحدى

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

المراجع المقدمة من الأساتذة بخصوص الدورات الحالیة .انتقل لصفحة الملتحقین لتطلع على بعض

المعلومات عن الملتحقین في الدورات. انتقل لصفحة اتصل بنا كي ترسل لنا اقتراحاً أو طلباً. نحن

بانتظارك! لكن الوقت محدود و عدد الملتحقین في كل دورة محدود لذا لا تتأخر في التسجیل من

فضلك.

3

هذا الكتاب ....

لیس فى الأصل ألا دورة تم تدریسها فى ساحة الدورات التعلیمیة بالموسوعة

العربیة للكمبیوتر والإنترنت ، وتم جمع تلك الدروس وسلسلة النقاش التى

دارت حولها هنا فى هذا الكتاب ، وتم وضع النقاشات على هیئة أسئلة

وأجوبة لكى یستفید الجمیع منها ،،،،،،،،،

لذلك تعتبر سلسلة كتب الدورات التعلیمیة :

أول سلسلة كتاب إلكترونیة عربیة خاصة بالمبتدأین. ·

السلسلة الوحیدة التى تتبع نظام الأسئلة والأجوبة الناتجة فعلاً من مشاكل حقیقة لأشخاص من مختلف ·

الأماكن والدول ، مما یهیئ عندك نوع من استعداد لأى مشكلة وكیفیة التعامل معها.

تعتبر سلسلة الكتاب الوحیدة المدعومة اربع وعشرین ساعة طوال العام ، فیمكنك الاستفسار عن اى ·

مشكلة وحلها عن طریق وضعها فى ساحة النقاش والأسئلة بالموسوعة .

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

فى حد ذاته، بل الاستطلاع واكتشاف الذات والإلمام الجید بالأساسیات والمبادئ الأولیة

من اجل شق طریق النجاح بكل سهولة ویسر.

4

المحتويات ..

الدرس الأول: ماذا نعني بھندسة البرمجیات؟

تطوير المشروع دورة حیاة : الدرس الثاني

الدرس الثالث: دراسة المتطلبات

الدرس الرابع: تصمیم النظام

الدرس الخامس: كتابة البرنامج واختباره

الدرس الخامس _ الحزء الثانى : كتابة البرنامج واختباره

5

بسم الله الرحمن الرحیم

الدرس الأول: ماذا نعني بھندسة البرمجیات؟

أھداف الدرس الأول:

سوف نحاول خلال ھذا الدرس الإجابة على ھذه الأسئلة:

ما ھي ھندسة البرمجیات؟ ·

من يشارك بھا؟ ·

ما ھي مكونات النظم البرمجیة؟ ·

وكیف يتم بنائھا؟ ·

مقدمة:

في حیاتنا الیومیة سواء في البیت أو المصنع أو Software لم يعد خافیا على أي منا أھمیة البرمجیات

المستشفى أو ... الخ، فنحن نتعامل يومیا مع العديد من الأجھزة والمعدات التي تعتمد في عملھا على

البرمجیات ومن المھم لنا أن تعمل ھذه الأجھزة وبرامجھا بالشكل والكفاءة التي نتوقعھا منھا. لذا فإن

ھندسة البرمجیات أصبحت الیوم أكثر أھمیة من أي وقت مضى.

المرجع:

1- Shari Pfleeger, "Software Engineering - Theory and Practice", 2nd Edition

ما ھي ھندسة البرمجیات؟

لنفھم معا علاقة ھندسة البرمجیات بعلوم الكومبیوتر، دعونا نأخذ ھذا المثال عن علم الكیمیاء واستخدامه

في حل المشاكل التي نقابلھا في حیاتنا الیومیة.

يھتم الكیمیائي بدراسة المواد الكیمیائیة (تركیبھا، تفاعلاتھا، والنظريات التي تحكم سلوكھا.(

بینما المھندس الكیمیائي يستخدم النتائج التي توصل إلیھا الكمیائي لحل المشاكل التي يطلب منه إيجاد

حل لھا.

من وجھه نظر الكیمیائي الكمیاء ھي موضوع الدراسة بحد ذاتھا.

تستخدم لأيجاد الحلول لمشاكل عامة) وقد لا tool ومن وجھه نظر المھندس الكمیائي الكیمیاء ھي أداة

تكون ھذه المشكلة ذات طبیعة كیمیائیة بحد ذاتھا.(

حیث يكون تركیزنا على الحواسیب ولغات computer science وبنفس الفكرة يمكن النظر إلى علم الحوسبة

البرمجة لدرستھا وتطويرھا في حد ذاتھا.

أو يمكن النظر إلیھا والتعامل بھا على أنھا أدوات نستخدمھا عند تصمیم وتطوير حل لمشكلة ما تواجھنا أو

الآخرين.

problem-solving tool. يعتبر أن الكمبیوتر ھو أداة لحل المشاكل Software Engineer مھندس البرمجیات

وعلیه أن يستخدم معلوماته حول الحاسوب وعلم الحوسبة للمساعدة في حل المشكلة التي يطلب منه

إيجاد حل لھا.

6

(1- شكل ( 1

بقدر ما ھي علم، لماذا؟ Art ولكن ومن المھم أن نتذكر أن عملیة كتابة البرامج تعد فن

أن يكتب برنامج لیؤدي مھمة hacker لأنه يمكن لأي شخص لديه معرفة كافیة بأحد لغات برمجة الحاسوب

محددة، لكن الامر يتطلب مھارة ومعرفة مھندس برمجیات محترف لكتابة برنامج أكثر تناسقا ووضوحا ،وأسھل

في الصیانة، ويقوم بالمھمة المطلوبة منه بفعالیة ودقة أكبر.

أي أن، ھندسة البرمجیات تعنى بتصمیم وتطوير برامج ذات جودة عالیة.

من يشارك في ھذه العملیة؟

المشاركون في عملیة صناعة البرنامج، عادة ما يندرجون تحت ثلاث مجموعات:

وھو الشركة (أو الشخص) الممولة لمشر وع تطوير البرنامج المطلوب Customer: الزبون ·

الشخص (أو مجموعة الاشخاص ) الذي سوف يقوم فعلا باستعمال البرنامج، User: المستخدم ·

والتعامل معه مباشرة.

وھو الشركة (أو الشخص) الذي سوف يقوم بتطوير البرنامج لصالح الزبون. Developer: المطور ·

الشكل التالي يظھر العلاقة بین الفئات الثلاثة السابقة

7

(2- شكل ( 1

مكونات النظام

مشاريعنا التي نطورھا لن تعمل في الفراغ، فعلیھا أن تتفاعل مع مستخدمین، أجھزة ومعدات متنوعة، نظم

تشغیل وبرامج وملفات وقواعد بیانات .... إلخ و ربما حتى أنظمة حواسیب آخرى. لھذا يجب تعريف حدود

النظام ومكوناته جیدا .أي يجب تعريف ما الذي يشتمل علیه النظام وما الذي لا يشتمل علیه.

بالإضافة إلى وصف للعلاقات activities والنشاطات objects أي نظام ھو عبارة عن مجموعة من الكائنات

التي تربط تلك الكائنات والنشاطات معا. مع تعريف قائمة المدخلات المطلوبة والخطوات المتبعة والمخرجات

الناتجة لكل نشاط.

أول خطوات تحلیل المشكلة ھو فھم ماھیة المشكلة وتعريفھا بوضوح، لذا علینا أولا أن نصف النظام بتحديد

مكوناته والعلاقات التي تربط بین ھذه المكونات.

1النشاطات والكائنات: النشاط ھو عمیلة تحدث بالنظام وعادة ما يوصف كحدث يتم من خلال حافز. النشاط .

يغیر شئ ما إلى آخر بتغیر خواصه (صفاته(

ھذا التغیر يمكن أن يعنى تحويل أحد عناصر البیانات من موقع إلى آخر، أو تعديل قیمته إلى قیمة مختلفة.

وھي عادة ماتكون مرتبطة ببعضھا البعض بشكل أو بأخر. مثلا الكائنات objects ھذه العناصر تسمى كائنات

يمكن أن تكون مرتبة في مصفوفة أو سجل) قید.(

8

وصف ھذه الكائنات نوعھا، النشاطات التي يمكن إجرائھا علیھا ... يجب وضعھا بدقة ھي ايضا.

2

Relationships and System Boundary . العلاقات وحدود النظام

بعد تعريف الكائنات والنشاطات جیدا، يمكن أن نربط بین كل كائن والنشاطات المتعلقة به بدقة. تعريف الكائن

يتضمن الموقع الذي سوف ينشأ به(نعض العناصر يمكن أن تكون موجودة بملف سبق انشاءه، والبعض قد يتم

انشاءه خلال حدث ما(، والھدف من انشاءه(بعض الكائنات تستخدم من قبل نشاط واحد فقط والبعض يمكن

بعض boundary لذا يمكن أن نعتبر أن لنظامنا حدود Input) , أن يستعمل من قبل نظم آخرى كمدخلات

الكائنات بمكن أن تعبر ھذه الحدود إلى داخل النظام، والبعض الآخر ھي مخرجات من نظامنا ويمكن أن ترحل

إلى نظم آخرى.

على أنه تجمع من: A System بھذا يمكن أن نعرف النظام

entities. مجموعة من الكائنات ·

activities. مجموعة من الانشطة ·

Relationship. وصف للعلاقات بین الكائنات والانشطة ·

boundary. تعريف لحدود النظام ·

كیف نبي نظام؟

إذا طلب منا عمیل تطوير نظام (برنامج) له، لحل مشكلة معینة تواجھه في عمله. فمثلا يحتاج نظام حماية

لشركته، أو نظام صرف آلي لبنك، أو ممكن أن يكون صاحب مكتبة أو متجر و يريد تغیر نظام البیع و الشراء أو

العرض لیتم بشكل آلي. علینا اتباع الخطوات التالیة لبناء ھذا النظام:

1عقد اجتماع مع العمیل لتحديد متطلباته، ھذه المتطلبات تشمل وصف النظام بجمیع مكوناته التي .

شرحنا.

2وضع تصمیم عام للنظام يحقق المتطلبات التي حددھا العمیل، وعرضه على العمیل لیوضح له الشكل .

الذي سیظھر علیه النظام عند الانتھاء، و ومراجعته معه لأخذ موافقته علیه.

3بعد موافقة العمیل على التصمیم يتم العمل على وضع التصامیم التفصیلیة لأجزاء المشروع. .

4كتابة البرنامج .

5اختباره، واعادة مراجعة المتطلبات التي وضعھا العمیل للتأكد من تحققھا في البرنامج. .

6تسلیم النظام إلى العمیل. .

7بعد تسلم العمیل للنظام قد تظھر بعض المشاكل أو الاخطاء التي لم تظھر خلال عملیة الاختبار، والتي .

تجب على المطور اصلاحھا فیما يعرف بصیانة النظام.

خلال الدروس التالیة من الدورة سنتعرف على كل خطوة من ھذه الخطوات وكیف تتم بشكل مبسط، وسوف

نخوض في مزيد من التفاصیل في دروس لاحقة بإذن الله.

) •·.·´¯`·.·• نھا ية الدرس الأول •·.·´¯`·.·• (

9

•·.·´¯`) •·.·´¯`·.·• نقاش الدرس الأول ·.·• (

س 1 - ھل المقصود بھذي الجملة ان المبرمج لا يستطیع حل المشكله فقط مھندس البرمجیات

ھو الذي يستطیع؟؟؟؟

ممكن أن يوجد شخص تعلم البرمجة دون أن يدرس ھندسة برمجیات و شخص آخر درس ھندسة البرمجیات

وبالطبع علوم الحاسوب .. لو اعطیت ھذين الشخصین مشكلة ما .. سیكون حل مھندس البرمجیات

للمشلكة أفضل من حل المبرمج الذي لم يدرس ھندسة البرمجیات

"تستطیع أن تقول أن كل مھندس برمجیات ھو مبرمج بینما لیس كل مبرمج ھو مھندس برمجیات"

نعم ھذا ھو المقصود، ھندسة البرمجات لا تھتم فقط بكتابة برنامج يؤدي مھمة محددة فحسب، بل أنھا

تھتم بما ھو أكثر من ذلك "جودة البرنامج"

تطلق على كل من يعرف كیف يكتب برنامج للقیام بأداء عمل ما.. Hacker كلمة مبرمج أو

ولكن كلمة مھندس برمجیات لا تطلق إلا على من يكتب ھذه البرمجیات باسلوب علمي يسعى من خلاله

إلى أن تكون برامجه ذات جودة عالیة.

؟ Art س 2 - ما المقصود في فن

بالانجلیزي = Art ھو الفن .. لأن كلمة الفن Art المقصود بكلمة

واما المقصود بالدرس ..

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

شخصیین مختلفیین ويودي نفس المھام...

وھذا كله يعتمد علي اسلوب المبرمج وكیفیة حله للمشكلة وطريقة صیغته للبرنامج .

س 3 - ھل يوجد فرق بین مھندس برمجیات و محلل نظم ؟

نعم ھناك فرق بین مھندس البرمجیات ومحلل النظم فمثلا في الدول المتقدمة يقوم محلل النظام بدراسة

المشروع المراد تنفیذه وكیفیة حل المشاكل التي توجه كما ويقوم بدراسة الجدوى ومعرفة متطلبات

النظام ...الخ

أي انه يقوم بتحلیل النظام المراد بنائه تحلیل دقیق .

اما مھندس البرمجیات فیقوم ببرمجة النظام وتھیئته كي يظھر في الصورة النھائیة..

أي يحتاج على الاقل الي شخصین كي يتم بناء النظام او البرنامج المطلوب.

10

الدرس الثاني: دورة حیاة تطوير المشروع

أھداف الدرس الثاني:

كما رأينا في الدرس الاول فإن ھندسة البرمجیات ھو عمل إبداعي يتم إداءه خطوة بخطوة، ويتعاون فیه عدد

من الاشخاص لكل منھم مھمة محددة .في ھذا الدرس سوف نناقش الخطوات التي يتم اتباعھا عند تطوير

مشروع برمجي بمزيد من التفاصیل ونبحث في الطرق المستخدمة لتنظیم ھذا العمل (صناعة البرمجیات(

مقدمة:

ومما تعلمنا في الدرس ،" Life Cycle عملیة بناء أي منتج تمر بعدة مراحل يطلق علیھا عادة "دورة الحیاة

تتضمن المراحل التالیة: Software development life cycle السابق فإن دروة حیاة تطوير أي نظام برمجي

Requirements analysis and definition 1تحديد وتعريف المتطلبات .

System design 2تصمیم النظام .

Program design 3تصمیم البرنامج .

) Program implementation 4كتابة البرنامج (تطويره .

Unit testing 5أختبار وحدات البرنامج .

system testing 6أختبار النظام .

system delivery 7تسلیم النظام .

maintenance 8الصیانة .

كل مرحلة من تلك المراحل تتضمن العديد من الخطوات أو النشاطات ولكل منھا مدخلاتھا ومخرجاتھا وتأثرھا

على جودة المنتج النھائي) البرنامج.(

دورة حیاة أي منتج تبدأ بأول خطوة وھي تحديد المتطلبات وتتدرج إلى باقي الخطوات كما ھي مرتبة حتى

الوصول إلى آخر خطوة وھي تسلیم البرنامج وصیانته (إن دعت الحاجة)، إلا أن التجارب العملیة تظھر أن ھذا

لیس ضروريا وأن دورة حیاة تطوير البرامج قد تأخذ أشكال (أو أنماط) مختلفة. وفي ھذا الدرس سوف نتعرف

إلى ھذه الأنماط

Lifecycle Models: أنماط دورة الحیاة

Waterfall Model النموذج الانحداري

في ھذا النموذج تسیر دورة الحیاة بشكل تدريجي بدأ من الخطوة ( 1) وحتى الخطوة ( 8)، وكما يظھر

بالشكل ( 1) فإن كل مرحلة تبدأ بعد الأنتھاء من المرحلة التي تسبقھا مباشرة.

11

(1- شكل ( 2

يتمیز النموذج الانحداري بالبساطة، ولذا فإنه يسّھل على المطور توضیح كیفیة سیر العمل بالمشروع

للعمیل (الذي عادة لا يعرف الكثیر عن صنع البرمجیات) والمراحل المتبقیة من العمل. وقد كان ھذا النموذج

أساس عمل كثیر من المؤسسات لفترة طويلة مثل وزارة الدفاع الامريكیة، واستنبط منه العديد من النماذج

الاكثر تعقیدا.

إلا أن لھذا النموذج العديد من العیوب، أھمھا أنه لا يعكس الطريقة التي يعمل بھا المطورون في الواقع.

فباستثناء المشاريع الصغیرة والبسیطة (أي أنھا مفھومة بشكل جید للمطور) فإن البرمجیات عادة ما تنتج

بعد قدر ھائل من التكرار والاعادة. في حین أن ھذا النموذج يفترض أن يكون الحل واضح ومفھوم وسبق

تحلیله بالكامل قبل مباشرة مرحلة التصمیم وھو أمر يكاد يكون شبه مستحیل مع الانظمة الضخمة. وحتى

إن كان ممكن فإنه يأخذ وقت طويل جدا (ربما سنوات!(

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

تعقید المشروع.

Phased Development التطوير على مراحل

حسب النموذج الانحداري فإنه يجب على المطورين إنھاء مرحلة تحلیل المشروع بشكل تام قبل البدأ في

التصمیم، وكما وضحنا فإن ھذه المرحلة قد تتطلب وقت طويل في بعض المشاريع وقد تمر عدة سنوات قبل

أن يرى البرنامج النھائي النور، ولكن ھل يمكن لسوق العمل الانتظار كل ھذا الوقت؟!

الاجابة بالطبع لا.

أحد ھذه الطرق ھي التطوير Cycle time. لذا كان لابد من ايجاد طرق آخرى لتقلیل زمن تطوير المشروع

حیث يتم تطوير النظام على عدة مراحل، بتقديم إصدار من البرنامج به Phased Development على مراحل

بعض الوظائف للعمیل والعمل على تطوير الاصدار الاحق الذي سوف يقدم له بقیة الوظائف.

يوجد عدة طرق يمكن بھا تنظیم عملیة تطوير إصدارات البرنامج، ومن اشھرھا:

Incremental model النموذج التزايدي ·

12

حیث يتم تقسیم النظام المطلوب تطويره إلى عدة اجزاء حسب الوظائف التي يعتین علیه القیام بھا، يبدأ

أول إصدار بأحد تلك الاجزاء ومع الوقت يتم إضافة المزيد من الاجزاء (الوظائف) حتى يتم الانتھاء من تطوير

النظام بشكل تام وحسب متطلبات العمیل.

Iterative model النموذج التكراري ·

ھذه المرة يتم تسلیم برنامج بكامل الوظائف من أول مرة، ولكن يتم تعديل وتغییر بعض تلك الوظائف مع كل

إصدار من البرنامج.

من ممیزات ھذا الأسلوب أنه يمكن المطورين من الحصول على ملاحظات وتقییم الزبون مبكرا و بصورة

منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعیدا في عملیات التطوير.كم أنه يمّكن من اكتشاف مدى

حجم و تعقید العمل مبكرا.

Spiral Model النموذج اللولبي

وھو شبیه لدرجة كبیرة إلى النموذج التزايدي والتكراري، ولكن فیه يتم دمج فعالیات التطوير مع إدارة المخاطر

من إجل التحكم بھا وتقلیلھا. risk

يبدأ النموذج اللولبي بمتطلبات العمیل مع خطة العمل المبدئیة (المیزانیة، قیود النظام، والبدائل المتاحة). ثم

يتقدم خطوة إلى الامام بتقدير المخاطر وتمثیل البدائل المتاحة قبل تقديم ما يعرف ب "وثیقة العملیات "

التي تصف وبشكل عام (بدون الدخول في التفاصیل) كیف يجب على النظام أن Concept of Operations

يعمل. بعدھا يتم تحديد وتدقیق المتطلبات للتأكد من أنھا تامة ودقیقة إلى أقصى حد ممكن.

بذلك تكون وثیقة العملیات ھي المنتج من الطور الأول، و المتطلبات ھي المنتج الاساسي من الطور الثاني.

وفي الطور الثالث تتم عملیة التصمیم، أما الاختبار فیتم خلال الطور الرابع.

في كل طور أو مرحلة يساعد تحلیل المخاطر على تقدير البدائل المختلفة في ضوء متطلبات وقیود النظام،

وتساعد النمذجة على التحقق من ملائمة أي بديل قبل أعتماده.

13

(2- شكل ( 2

) •·.·´¯`·.·• نھاية الدرس الثاني •·.·´¯`·.·• (

14

•·.·´¯`·) •·.·´¯`·.·• نقاش الدرس الثاني .·• (

WaterFall Model .. لي ملاحظه و ھي في ال

لأخر و كلما كان ھذا الرجوع أكبر كلما كان مكلف أكثر Phase من back track ھل من الممكن أن يكون ھناك

من ناحیة الوقت و التعديل و المال ؟؟

Phase من back track نعم من الممكن أن يكون ھناك

وغالبا ما يكون ھذا ما يحصل بالفعل عند التطبیق العملي...

ولیس ھذا فقط .. فبعد كل مرحلة ممكن يُكتشف أن ناتج models ممكن يحدث في جمیع ال backtrack ال

أحد المراحل السابقة لم يكن صحیح ويحتاج إلى تعديل

وھذا ما يجعل أنماط آخرى كالنمط اللولبي أكثر تفضیلا.

Waterfall Model بالنسبة لل backtrack صورة لل15

الدرس الثالث: دراسة المتطلبات

في ھذا الدرس سوف نبدأ في دراسة أول (ولعلھا أھم) خطوة في تطوير البرامج وھي تحديد متطلبات

Capturing the requirements. النظام

الھدف من تحديد المتطلبات ھو فھم ما يتوقعه العمیل والمستخدم من النظام (ما الذي يمكن للنظام أداؤه

وما لا يمكنه أداؤه).فقد يكون النظام المطلوب تصمیمه بديل لنظام أو لطريقة مستخدمة لأداء مھمة محددة،

أو ممكن أن يكون نظام جديد يقدم خدمة جديدة لم يسبق تقديمھا من قبل. فلكل نظام برمجي وظیفة

معینة، تحدد بما يمكن له أن يقوم به من أجل أداء تلك الوظیفة.

المتطلبات :ھي تعريف لشكل النظام أو وصف لما يستطیع ھذا النظام أن يقوم به لأداء وظیفته التي

سیصمم من أجلھا.

خطوات تحديد المتطلبات :

أولا: الاجتماع مع العمیل للتعرف على المتطلبات:

وھذه خطوة ھامة جدا إذ أن بقیة الخطوات التالیة تعتمد علیھا بشكل أساسي. لذا يجب علینا أن نستخدم

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

المستخدم بكل أبعادھا، نتعرف على العملیات والمصادر التي تتضمنھا المشكلة والعلاقات التي تربطھا معا و

نحدد حدود النظام. وھذا يمكن أن يتم من خلال:

طرح الأسئلة على العمیل، ومن المفید أحیانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من ·

مرة فھذا يساعدنا على التأكد من أننا نفھم ما يقصده العمیل بالتحديد.

عرض نظم مشابه للنظام المطلوب سبق تصمیمھا من قبل. ·

تصمیم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل. ·

تقسم المتطلبات إلى عدة عناصر تشمل:

Physical Environment البیئة المحیطة بالنظام ·

Interfaces وجھات الاستخدام ·

Users and human factors المستخدمین وإمكاناتھم ·

Functionality وظائف النظام ·

Documentation التوثیق ·

Data البیانات ·

Resources المصادر ·

Security الأمن ·

Quality Assurance ضمان الجودة ·

ويجب التأكد من أن نناقش جمیع ھذه العناصر

ثانیا: تسجیل ھذه المتطلبات في وثائق أو قاعدة بیانات، وعرضھا على العمیل لیوافق علیھا باعتبار أنھا ما

يطلبه بالفعل

المتطلبات لا تصف فقط تدفق البیانات والمعلومات من وإلى النظام، وأما تصف كذلك القیود المفروضة على

عمل النظام. وبذلك فإن عملیة تحديد المتطلبات تخدم ثلاثة أغراض:

16

أولا تمكن المطورين من شرح فھمھم للطريقة التي يود المستخدمین أن يعمل بھا النظام. ·

ثانیا توضح للمصممین ماھیة الوظائف والخصائص التي سیمتاز بھا النظام , ·

وثالثا: توضح المتطلبات لفريق الاختبار ما الذي يجب إثباته لإقناع الزبون أن النظام الذي تم تطويره ·

ھو ما سبق أن طلبه بالضبط .

لذلك ولضمان أن كلا من المطورين والزبون متفاھمون تماما على ما يجب القیام به، فإن المتطلبات المسجلة

حتى ھذه الخطوة يجب أن تكون لھا الصفات التالیة:

وخالیة من الأخطاء. Correct 1أن تكون صحیحة .

بمعنى أن لا يكون ھناك أي تعارض بین متطلب وآخر. consistent 2أن تكون ثابتة .

يجب أن يتم ذكر جمیع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة Complete 3أن تكون تامة .

منه، ...الخ .

بمعنى أن تكون قابلة للتطبیق في الواقع. realistic 4أن تكون واقعیة .

5أن تكون متعلقة بأمور ضرورة للعمیل، ويتطلبھا النظام. .

verifiable 6أن يكون من الممكن التحقق منھا .

traceable 7أن تكون قابلة للتتبع .

" Requirement Definition Document يطلق على ھذه الوثائق "وثائق تعريف المتطلبات

لیقوم المصممون بتحويل تلك المتطلبات إلى mathematical ثالثا: إعادة تسجیل المتطلبات بشكل رياضي

تصمیم جید للنظام في مرحلة التصمیم.

لسنوات عديدة كان يتم الاكتفاء بوثیقة تعريف المتطلبات (التي تحدثنا عنھا قبل قلیل) والتي تكتب

باستعمال اللغة الطبیعیة) لغة البشر) لوصف وتسجیل متطلبات النظم بحیث يمكن للعمیل أن يفھم كل

كلمة موجودة بھا، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببھا في أغلب الأحیان إلى سوء

تفسیر بعض التعبیرات للمستخدمین من قبل المصمم أو العكس، فعلى سبیل المثال قد يطلق المستخدم

باعتبار أن backup على النظام التعبیر (متوقف عن العمل) إذا كان النظام مشغول بعملیة تسجیل احتیاطي

لا يستجیب لأوامر المستخدم في ھذه الحالة، بینما يعتبر المصمم أن النظام في ھذه الحالة (مستمر في

العمل) لأنه يقوم بمھمة أساسیة!

لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثیرة عند تصمیم النظام، وينتج عنھا

نظام لا يقبله العمیل لأنه لا يلبي متطلباته التي حددھا من قبل، لذلك يتم كتابة نوع ثاني من الوثائق

وھي تكتب باستعمال وسائل " Requirement specification Document تسمى "وثائق مواصفات المتطلبات

وطرق خاصة ابتكرھا مھندسو البرمجیات لكتابة المتطلبات باسلوب تقني بحت. منھا على سبیل المثال: لغة

و ھي لغة نمذجة رسومیة تقدم لنا صیغة لوصف UML Unified Modeling Language النمذجة الموحدة

العناصر الرئیسیة للنظم البرمجیة.

UML الشكل التالي يعرض مثال على استعمال

17

رابعا: التثبت والتحقق من المتطلبات التي تم تسجلیھا في كلا من وثیقة تعريف المتطلبات (والتي تقدم

للعمیل) ووثیقة مواصفات المتطلبات (والتي تقدم للمصمم (للتأكد من صحتھما وشمولیتھما وأن كلا منھما لا

تعارض الثانیة في أي نقطة، وإلا فإن النتیجة سوف تكون نظام لا يلبي طلبات العمیل.!

) •·.·´¯`·.·• نھاية الدرس الثالث •·.·´¯`·.·• (

18

•·.·´¯`·) •·.·´¯`·.·• نقاش الدرس الثالث .·• (

_________________أقتباس__________________

أولا: الاجتماع مع العمیل للتعرف على المتطلبات:

وھذه خطوة ھامة جدا إذ أن بقیة الخطوات التالیة تعتمد علیھا بشكل أساسي. لذا يجب علینا أن نستخدم

كافة التقنیات المتاحة لنكتشف ما الذي يطلبه العمیل والمستخدم،............. الخ

اخر شي قلتي" : ويجب التأكد من أن نناقش جمیع ھذه العناصر"

_________________________________________

ھل تقصدين النقاش مع العمیل!!?

نعم يجب مناقشة كل نقطة مع العمیل للتأكد من اننا فھمنا ما يقصده تماما.

Physical Environment .. البیئة المحیطة بالنظام

لم أقھم ما تقصدين بالبیئة المحیطة؟؟

يقصد بھا كل ما يحیط بالنظام ولیس من مكوناته مثلا الموقع الذي سیعمل به النظام، ھل ھو ثابت في

Hardware + موقع واحد أكثر أو يمكن أن يتم نقله إلى مواقع مختلفة (طبعا الحديث يشمل النظام كامل

software)

نربد توضیح او مثال عن صفات المتطلبات الأتیة :

1

verifiable . أن يكون من الممكن التحقق منھا

بمعنى أن تكتب المتطلبات بحیث تكون قابلة للاختبار للتأكد من تحققت، فمثلا قد يذكر العمیل أن يريد من

النظام أن يكون ذا استجابة سريعة!

ما مقدار السرعة المطلوب؟

قد يرى المصمم أن الانتظار لمدة 50 ثانیة مناسب كحد أقصى، بینما يتوقع الزبون زمن انتظار 20 ثانیة كحد

أقصى!

traceable 2 أن تكون قابلة للتتبع .

بمعنى أن تكون المتطلبات مكتوبة بحیث يسھل تتبعھا للتأكد من أن كل وظیفة مطلوبة من النظام تم

استیفائھا من خلال المتطلبات.

19

الدرس الرابع: تصمیم النظام

نكمل مع خطوات بناء النظام، وھذه المرة سوف نتحدث عن خطوة "تصمیم النظام "

ما ھو التصمیم؟

التصمیم ھو عملیة إبداعیة لإيجاد حل لمشكلة، كما تطلق عادة كلمة تصمیم على وصف ھذا الحل.

حیث نستفید من المتطلبات التي حددنھا في الخطوة السابقة في التعرف على المشكلة، ثم نبدأ في

التفكیر في الحل الذي يفي بجمیع الشروط والمواصفات التي تحددھا المتطلبات، وغالبا ما يمكن إيجاد عدد

غیر محدود من الحلول يمكن لنا أن نختار أحدھا و الذي نجده الأنسب من بینھا.

عند الانتھاء من خطوة تحديد المتطلبات، فإننا ننتھي بوثیقتین (كما ذكرنا في الدرس السابق) الأولى ھي

(وثیقة تعريف المتطلبات) ويتم تقديمھا للعمیل والثانیة (وثیقة مواصفات المتطلبات) ويتم تقديمھا للمصمم.

ودور المصمم ھو تحويل ھذه الوثائق إلى نظام يرضي العمیل (يلبي احتیاجاته)، وفي نفس الوقت يرضي

المطور (يمكن تطبیقه.(

من خطواتین: iterative لذا فإن عملیة التصمیم في عملیة تكرارية

والذي يوضح للعمیل ما الذي سیقوم به النظام conceptual design أولا :يتم إنتاج التصمیم التصوري

بالتحديد .

وفي حال موافقة العمیل على ھذا النظام، يتم الانتقال للخطوة التالیة.

ثانیا :تحويل التصمیم التصوري إلى وثیقة بھا تفاصیل أكثر عن التصمیم يطلق علیھا اسم التصمیم التقني

والذي يجب أن يظھر للمطور ما ھي المعدات والبرمجیات اللازمة لبناء النظام. technical design

أحیانا يتطلب الأمر للعودة إلى الخطوة الأولى) التصمیم التصوري) والتعديل علیه، لذا فأنھا عملیة تكرارية

حتى الوصول إلى التصمیم الذي يرضي العمیل ويمكن تطبیقه على أرض الواقع في ظل الإمكانیات المتاحة

للمطورين.

20

conceptual design: التصمیم التصوري

ويكتب بلغة يمكن للعمیل أن يفھمھا (لغة البشر) لیجیب functions يركز ھذا التصمیم على وظائف النظام

يعمل النظام. ويجب أن يكون خالي تماما من أي تفاصیل برمجیة أو (WHAT) عن أسئلة العمیل حول ماذا

فنیة. والاھم أن يحقق كل المتطلبات التي تم تحديدھا سابقا.

technical design التصمیم التقني

ھذا التصمیم سوف يتم تقديمه إلى مطوري النظام لیقوموا ھم بتحويله إلى النظام المطلوب، لذا يجب أن

تطوير النظام. ولمنع إلى تضارب في (HOW) يقدم ھذا التصمیم إجابة شافیة لأسئلة المطور عن كیفیة

المفاھیم فإن ھذا التصمیم عادة ما يكتب باستعمال تعبیرات وأسالیب تقنیة.

) •·.·´¯`·.·• نھاية الدرس الرابع ولا يوجد نقاش له •·.·´¯`·.·• (

21

الدرس الخامس: كتابة البرنامج واختباره

أھداف الدرس:

ھذا الدرس لن يعلمك لغة برمجة لتكتب بھا البرامج، ولكن الھدف منه التعرف على:

القواعد الصحیحة لكتابة البرامج ·

خطة الاختبار وأنواع الاختبارات ·

الجزء الأول :كتابة البرامج:

بعد وضع التصمیم للنظام واختیار لغة البرمجة المناسبة، تبدأ الخطوة التي سوف تنقل التصمیم المكتوب

على الورق إلى واقع. خلال ھذا الدرس سوف نناقش أھم القواعد التي على المبرمج إتباعھا أثناء كتابة

برامجه. ولكن قبل ذلك لنجیب على ھذا السؤال الذي لا شك أنه ورد على ذھنك الآن

س: لماذا علینا إتباع ھذه القواعد؟

ج :إذا كنت تعمل منفردا في كتابة برامجك، فإن إتباعك لقواعد وأسالیب قیاسیة في البرمجة سوف تساعدك

على تنظیم أفكارك لتجنب الوقوع في الأخطاء. كما أنھا ستساعدك على اكتشاف أي أخطاء قد تحدث

بسرعة وبسھولة.

أم إذا كنت تعمل ضمن فريق برمجي، فإن إتباع القواعد والأسالیب القیاسیة في كتابة أجزاء البرامج التي

يطلب منك كتابتھا، سوف تساعدك وبقیة الفريق من تنسیق أعمالكم وتنظیمھا، كما أنھا ستقلل من عدد

الأخطاء في البرنامج وتساعد على اكتشاف ما يقع منھا في اسرع وقت ممكن.

تفرض الكثیر من شركات البرمجة على مبرمجیھا إتباع قواعد قیاسیة في كتابة برامجھم، وذلك لضمان

التكامل في جمیع البرامج، كما أن بعض الشركات تعین فرق لاختبار البرامج، غیر الفريق الذي قام بالبرمجة

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

Programming Guidelines بعض قواعد البرمجة

Control Structures ھیاكل التحكم ·

وأثناء كتابة ھذه الھیاكل ، if- else)، Goto يقصد بھا تلك الھیاكل التي تتحكم في مسار عمل البرنامج (مثل

علنا أن نحاول أن نجعلھا واضحة وسھلة التتبع، وخالیة من القفزات الواسعة قدر الإمكان. انظر لھذا المثال:

benefit = minimum;

if (age < 75) goto A;

benefit = maximum;

goto C;

if (age < 65) goto B;

if (age < 55) goto C;

A: if (age < 65) goto B;

22

benefit = benefit * 1.5 + bonus;

goto C;

B: if (age < 55) goto C;

benefit = benefit * 1.5;

C: next statement

نفس الكود يمكن كتابته على ھذا النحو:

if (age < 55) benefit = minimum;

else if (age < 65) benefit = minimum + bonus;

else if (age < 75) benefit = minimum * 1.5 +bonus;

else benefit = maximum;

لذلك حاول دائما أن ، generality is a virtue عالم البرمجة ھناك قاعدة تقول أن العمومیة میزة ·

تجعل شفراتك البرمجة عامة، لتتمكن من إعادة استعمالھا في بقیة برامجك بأقل قدر ممكن من

التعديل، ولكن حاذر من التمادي في ذلك!

لا تستخدم أبدا أسماء لا معنى لھا لمتغیرات أو بارمترات برنامجك ( ينصح بمراجعة ھذا الدرس ·

"التسمیة في البرنامج، درس لابد من أن يقرأه كل مبرمج!("

"أريد برنامجا سريعا" وكلنا نريد ذلك، ولكن ما ھو الثمن؟! ·

عندما تفكر في جعل برنامجك أسرع ما يمكن، علیك أن تفكر كذلك في الثمن الذي ستدفعه مقابل ذلك:

1. البرنامج السريع قد يتطلب منك كتابة كود معقد يتطلب منك (ومن فريق العمل) المزيد من

الوقت والجھد في كتابته.

2. الوقت الذي تحتاجه عملیة اختبار البرنامج المعقد في مختلف حالته.

3. الوقت والجھد الذي تحتاجه لتعديل ھذا الكود أو لتطويره.

زمن تنفیذ البرنامج ما ھو إلا جزء من معادلة كبیرة لحساب تكلفة البرنامج، لذلك علیك أن تعادل بین

السرعة، والجودة، واحتیاجات الزبون. ولا تضحي بالبساطة والوضوح من أجل السرعة.

التوثیق: لا تھمل أبدا توثیق برنامجك، ما سُمي الإنسان إنسانا إلا لنسیانه. ·

) •·.·´¯`·.·• نھاية الدرس الخامس - الجزء الأول ولا يوجد نقاش له •·.·´¯`·.·• (

23

الدرس الخامس: كتابة البرنامج واختباره

الجزء الثاني :اختبار البرامج:

وصلنا الآن إلى آخر مرحلة في تطوير النظام، وھي اختبار البرنامج للتأكد من أنه يعمل على النحو الذي

يتوقعه الزبون.

قبل تسلیم النظام النھائي إلى الزبون تجرى علیه الكثیر من الاختبارات، بعضھا يعتمد على ما الذي يتم

اختباره مثلا:

)أحد مكونات البرنامج - مجموعة من المكونات - جزء من النظام - النظام بالكامل(

والبعض الأخر يعتمد على ما الذي نريد معرفته من ھذه الاختبارات، مثلا:

ھل يعمل النظام وفقا لما ورد في المتطلبات؟ ·

ھل يعمل النظام وفقا لما ورد في التصمیم؟ ·

ھل يعمل النظام كما يتوقعه الزبون منه؟ ·

مراحل الاختبار:

عند العمل على اختبار نظام من الحجم الكبیر، فإن عملیة الاختبار تتم على عدة مراحل موجزھا في ما

يلي:

component Testing أو Module Testing 1. اختبار المكون

أول مراحل اختبار النظم، ھي اختبار كل مكون على حدى بمعزل عن بقیة مكونات النظام، للتأكد من

منه بعد إمداده بالبیانات اللازمة (output) عمله على النحو المتوقع منه. باختبار المعلومات المتحصل علیھا

(input). له

Integration Testing 2. اختبار التكامل

بعد اختبار كل مكونات النظام والتأكد من سلامة تصمیمھا، يجب أن نتأكد من أنھا ستعمل معا بشكل

صحیح وأنه لا يوجد تضارب بین بعضھا البعض بحیث أن المعلومات المنتقلة بین ھذه المكونات تصل بالھیئة

المتوقعة لھا. وھذا ھو الھدف من اختبار التكامل.

Function Testing 3. اختبار الوظیفة

ويقصد به اختبار النظام بعد تجمیع كل مكوناته للتأكد من أنه يؤدي الوظیفة التي يتعین علیه القیام بھا،

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

Functioning System نظام عامل

Performance Testing 4. اختبار الأداء

24

في ھذه الخطوة يتم اختبار أداء البرنامج في بیئة عمل الزبون للتأكد من أن النظام متوافق مع بقیة

وبھذا فإننا نعتبر أن validated system المتطلبات .عند اجتیاز النظام لھذا الاختبار يتم التصديق على النظام

النظام أصبح جاھز حسب مفھومنا لما طلبه الزبون.

Acceptance Test 5. اختبار القبول

يتم إجراء ھذا الاختبار للتأكد من أن النظام المحقق موافق لما توقعه الزبون، وبعدھا يعد النظام مقبول

Accepted system عند المستخدم والزبون

Installation Test 6. اختبار التثبیت

الاختبار الأخیر يتم فیه تثبیت النظام في بیئة العمل الخاصة به والتأكد من أنه يعمل كما ھو مطلوب منه.

الشكل التالي يوضح خطوات تطبیق عملیة اختبار النظام، والتي يحسن تطبیقھا على اي نظام مھما كان

حجمه للتأكد من أنه سیؤدي المھمة المطلوبة منه

) •·.·´¯`·.·• نھاية الدرس الخامس - الجزء الثاني ولا يوجد نقاش له •·.·´¯`·.·• (

تمت دورة ھندسة البرمجیات بحمدالله وتوفیقه ..

الموسوعة العربیة للكمبیوتر/ قسم الدورات التعلیمیة

سلسلة كتب الدورات التعلیمیة الإلكترونیة

C4arab.com

ھندسة البرمجیات

Software Engineering

في ستة أيام......

تألیف

أسماء المنقوش

مشرفة ساحة لغات البرمجة

یسمح بتوزیع الكتاب على صورته الإلكترونیة لكن لا یسمح بطبع الكتاب أو تغییر هیئته

إلا بعد أخذا إذن من الكاتب

2000-2005 جمیع الحقوق محفوظة - © الموسوعة العربیة للكمبیوتر والإنترنت

1

التواصل مع القراء

العزیز ،،، القارئ إلى

حرصت الموسوعة العربیة للكمبیوتر والإنترنت _ ومن منطلق اهتمامها العام بعلوم الحاسب والتقنیة

واهتمامها الخاص بتقدیم هذه العلوم باللغة العربیة _ على تقدیم هذه السلسة من

الكتب الإلكترونیة التى نتمنى أن تحقق طموحات القارئ العربى الذى اعتاد على قراءة أجو د

. المطبوعات بكافة اللغات العالمیة

إن الموسوعة العربیة _من خلال هذه السلسلة _ تطمح لتقدیم سلسلة من الكتب بمستوى عالٍ من

الجودة ، الشيء الذى لن یتحقق بدون ملاحظاتكم واقتراحاتكم حول السلسلة _ طریقة الكتابة ،

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

الخ

ننتظر سماع أراءكم على البرید الإلكتروني المخصص لذلك

ebooks@c4arab.com

نرجو ذكر اسم الكتاب والكاتب والطبعة مع ذكر ملاحظاتكم لنا

تهانى السبیت

مشرفة الموسوعة العربیة للكمبیوتر والإنترنت

2

.. بسم الله الرحمن الرحیم ..

الدورات التعلیمیة .. ھي مجموعة من الدورات

التي تقدمھا لكم الموسوعة العربیة؛ بدأنا بتقديمھا

في الصیف تحت مسمى " الدورات الصیفیة " وھا

ھي تعود من جديد . حرصنا على تقديم دورات في

مجالات مختلفة لنراعي أغلب الاھتمامات كما

حرصنا على انتقاء الدورات المفیدة، غیر المتكررة،

بطريقة جادة تنقلك إلى الجو الدراسي في قاعات

الجامعة و صفوف المعاھد و لكن في بیئة

إلكترونیة! كل ھذا مجانا! ...

يوجد كذلك ساحة متخصصة لھا ضمن مجموعة

ساحات الموسوعة العربیة للنقاش والأسئلة،

تجدھا ھنا! ...

استفد واستثمر وقتك معنا! إذا كنت ترغب في

تطوير ذاتك و توسیع نطاق ثقافتك في الحاسوب

فاستغل كل دقیقة واستفد معنا! و لا تنسى أننا

في عصر المعلومات والسرعة.

ابدأ الآن !انتقل لصفحة الدورات و اختر الدورة التي تناسبك، انتقل لصفحة الأساتذة للاطلاع على

قائمة الأساتذة الّذين سیلقون المحاضرات ،انتقل لصفحة التسجیل كي تسجّل نفسك في إحدى

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

المراجع المقدمة من الأساتذة بخصوص الدورات الحالیة .انتقل لصفحة الملتحقین لتطلع على بعض

المعلومات عن الملتحقین في الدورات. انتقل لصفحة اتصل بنا كي ترسل لنا اقتراحاً أو طلباً. نحن

بانتظارك! لكن الوقت محدود و عدد الملتحقین في كل دورة محدود لذا لا تتأخر في التسجیل من

فضلك.

3

هذا الكتاب ....

لیس فى الأصل ألا دورة تم تدریسها فى ساحة الدورات التعلیمیة بالموسوعة

العربیة للكمبیوتر والإنترنت ، وتم جمع تلك الدروس وسلسلة النقاش التى

دارت حولها هنا فى هذا الكتاب ، وتم وضع النقاشات على هیئة أسئلة

وأجوبة لكى یستفید الجمیع منها ،،،،،،،،،

لذلك تعتبر سلسلة كتب الدورات التعلیمیة :

أول سلسلة كتاب إلكترونیة عربیة خاصة بالمبتدأین. ·

السلسلة الوحیدة التى تتبع نظام الأسئلة والأجوبة الناتجة فعلاً من مشاكل حقیقة لأشخاص من مختلف ·

الأماكن والدول ، مما یهیئ عندك نوع من استعداد لأى مشكلة وكیفیة التعامل معها.

تعتبر سلسلة الكتاب الوحیدة المدعومة اربع وعشرین ساعة طوال العام ، فیمكنك الاستفسار عن اى ·

مشكلة وحلها عن طریق وضعها فى ساحة النقاش والأسئلة بالموسوعة .

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

فى حد ذاته، بل الاستطلاع واكتشاف الذات والإلمام الجید بالأساسیات والمبادئ الأولیة

من اجل شق طریق النجاح بكل سهولة ویسر.

4

المحتويات ..

الدرس الأول: ماذا نعني بھندسة البرمجیات؟

تطوير المشروع دورة حیاة : الدرس الثاني

الدرس الثالث: دراسة المتطلبات

الدرس الرابع: تصمیم النظام

الدرس الخامس: كتابة البرنامج واختباره

الدرس الخامس _ الحزء الثانى : كتابة البرنامج واختباره

5

بسم الله الرحمن الرحیم

الدرس الأول: ماذا نعني بھندسة البرمجیات؟

أھداف الدرس الأول:

سوف نحاول خلال ھذا الدرس الإجابة على ھذه الأسئلة:

ما ھي ھندسة البرمجیات؟ ·

من يشارك بھا؟ ·

ما ھي مكونات النظم البرمجیة؟ ·

وكیف يتم بنائھا؟ ·

مقدمة:

في حیاتنا الیومیة سواء في البیت أو المصنع أو Software لم يعد خافیا على أي منا أھمیة البرمجیات

المستشفى أو ... الخ، فنحن نتعامل يومیا مع العديد من الأجھزة والمعدات التي تعتمد في عملھا على

البرمجیات ومن المھم لنا أن تعمل ھذه الأجھزة وبرامجھا بالشكل والكفاءة التي نتوقعھا منھا. لذا فإن

ھندسة البرمجیات أصبحت الیوم أكثر أھمیة من أي وقت مضى.

المرجع:

1- Shari Pfleeger, "Software Engineering - Theory and Practice", 2nd Edition

ما ھي ھندسة البرمجیات؟

لنفھم معا علاقة ھندسة البرمجیات بعلوم الكومبیوتر، دعونا نأخذ ھذا المثال عن علم الكیمیاء واستخدامه

في حل المشاكل التي نقابلھا في حیاتنا الیومیة.

يھتم الكیمیائي بدراسة المواد الكیمیائیة (تركیبھا، تفاعلاتھا، والنظريات التي تحكم سلوكھا.(

بینما المھندس الكیمیائي يستخدم النتائج التي توصل إلیھا الكمیائي لحل المشاكل التي يطلب منه إيجاد

حل لھا.

من وجھه نظر الكیمیائي الكمیاء ھي موضوع الدراسة بحد ذاتھا.

تستخدم لأيجاد الحلول لمشاكل عامة) وقد لا tool ومن وجھه نظر المھندس الكمیائي الكیمیاء ھي أداة

تكون ھذه المشكلة ذات طبیعة كیمیائیة بحد ذاتھا.(

حیث يكون تركیزنا على الحواسیب ولغات computer science وبنفس الفكرة يمكن النظر إلى علم الحوسبة

البرمجة لدرستھا وتطويرھا في حد ذاتھا.

أو يمكن النظر إلیھا والتعامل بھا على أنھا أدوات نستخدمھا عند تصمیم وتطوير حل لمشكلة ما تواجھنا أو

الآخرين.

problem-solving tool. يعتبر أن الكمبیوتر ھو أداة لحل المشاكل Software Engineer مھندس البرمجیات

وعلیه أن يستخدم معلوماته حول الحاسوب وعلم الحوسبة للمساعدة في حل المشكلة التي يطلب منه

إيجاد حل لھا.

6

(1- شكل ( 1

بقدر ما ھي علم، لماذا؟ Art ولكن ومن المھم أن نتذكر أن عملیة كتابة البرامج تعد فن

أن يكتب برنامج لیؤدي مھمة hacker لأنه يمكن لأي شخص لديه معرفة كافیة بأحد لغات برمجة الحاسوب

محددة، لكن الامر يتطلب مھارة ومعرفة مھندس برمجیات محترف لكتابة برنامج أكثر تناسقا ووضوحا ،وأسھل

في الصیانة، ويقوم بالمھمة المطلوبة منه بفعالیة ودقة أكبر.

أي أن، ھندسة البرمجیات تعنى بتصمیم وتطوير برامج ذات جودة عالیة.

من يشارك في ھذه العملیة؟

المشاركون في عملیة صناعة البرنامج، عادة ما يندرجون تحت ثلاث مجموعات:

وھو الشركة (أو الشخص) الممولة لمشر وع تطوير البرنامج المطلوب Customer: الزبون ·

الشخص (أو مجموعة الاشخاص ) الذي سوف يقوم فعلا باستعمال البرنامج، User: المستخدم ·

والتعامل معه مباشرة.

وھو الشركة (أو الشخص) الذي سوف يقوم بتطوير البرنامج لصالح الزبون. Developer: المطور ·

الشكل التالي يظھر العلاقة بین الفئات الثلاثة السابقة

7

(2- شكل ( 1

مكونات النظام

مشاريعنا التي نطورھا لن تعمل في الفراغ، فعلیھا أن تتفاعل مع مستخدمین، أجھزة ومعدات متنوعة، نظم

تشغیل وبرامج وملفات وقواعد بیانات .... إلخ و ربما حتى أنظمة حواسیب آخرى. لھذا يجب تعريف حدود

النظام ومكوناته جیدا .أي يجب تعريف ما الذي يشتمل علیه النظام وما الذي لا يشتمل علیه.

بالإضافة إلى وصف للعلاقات activities والنشاطات objects أي نظام ھو عبارة عن مجموعة من الكائنات

التي تربط تلك الكائنات والنشاطات معا. مع تعريف قائمة المدخلات المطلوبة والخطوات المتبعة والمخرجات

الناتجة لكل نشاط.

أول خطوات تحلیل المشكلة ھو فھم ماھیة المشكلة وتعريفھا بوضوح، لذا علینا أولا أن نصف النظام بتحديد

مكوناته والعلاقات التي تربط بین ھذه المكونات.

1النشاطات والكائنات: النشاط ھو عمیلة تحدث بالنظام وعادة ما يوصف كحدث يتم من خلال حافز. النشاط .

يغیر شئ ما إلى آخر بتغیر خواصه (صفاته(

ھذا التغیر يمكن أن يعنى تحويل أحد عناصر البیانات من موقع إلى آخر، أو تعديل قیمته إلى قیمة مختلفة.

وھي عادة ماتكون مرتبطة ببعضھا البعض بشكل أو بأخر. مثلا الكائنات objects ھذه العناصر تسمى كائنات

يمكن أن تكون مرتبة في مصفوفة أو سجل) قید.(

8

وصف ھذه الكائنات نوعھا، النشاطات التي يمكن إجرائھا علیھا ... يجب وضعھا بدقة ھي ايضا.

2

Relationships and System Boundary . العلاقات وحدود النظام

بعد تعريف الكائنات والنشاطات جیدا، يمكن أن نربط بین كل كائن والنشاطات المتعلقة به بدقة. تعريف الكائن

يتضمن الموقع الذي سوف ينشأ به(نعض العناصر يمكن أن تكون موجودة بملف سبق انشاءه، والبعض قد يتم

انشاءه خلال حدث ما(، والھدف من انشاءه(بعض الكائنات تستخدم من قبل نشاط واحد فقط والبعض يمكن

بعض boundary لذا يمكن أن نعتبر أن لنظامنا حدود Input) , أن يستعمل من قبل نظم آخرى كمدخلات

الكائنات بمكن أن تعبر ھذه الحدود إلى داخل النظام، والبعض الآخر ھي مخرجات من نظامنا ويمكن أن ترحل

إلى نظم آخرى.

على أنه تجمع من: A System بھذا يمكن أن نعرف النظام

entities. مجموعة من الكائنات ·

activities. مجموعة من الانشطة ·

Relationship. وصف للعلاقات بین الكائنات والانشطة ·

boundary. تعريف لحدود النظام ·

كیف نبي نظام؟

إذا طلب منا عمیل تطوير نظام (برنامج) له، لحل مشكلة معینة تواجھه في عمله. فمثلا يحتاج نظام حماية

لشركته، أو نظام صرف آلي لبنك، أو ممكن أن يكون صاحب مكتبة أو متجر و يريد تغیر نظام البیع و الشراء أو

العرض لیتم بشكل آلي. علینا اتباع الخطوات التالیة لبناء ھذا النظام:

1عقد اجتماع مع العمیل لتحديد متطلباته، ھذه المتطلبات تشمل وصف النظام بجمیع مكوناته التي .

شرحنا.

2وضع تصمیم عام للنظام يحقق المتطلبات التي حددھا العمیل، وعرضه على العمیل لیوضح له الشكل .

الذي سیظھر علیه النظام عند الانتھاء، و ومراجعته معه لأخذ موافقته علیه.

3بعد موافقة العمیل على التصمیم يتم العمل على وضع التصامیم التفصیلیة لأجزاء المشروع. .

4كتابة البرنامج .

5اختباره، واعادة مراجعة المتطلبات التي وضعھا العمیل للتأكد من تحققھا في البرنامج. .

6تسلیم النظام إلى العمیل. .

7بعد تسلم العمیل للنظام قد تظھر بعض المشاكل أو الاخطاء التي لم تظھر خلال عملیة الاختبار، والتي .

تجب على المطور اصلاحھا فیما يعرف بصیانة النظام.

خلال الدروس التالیة من الدورة سنتعرف على كل خطوة من ھذه الخطوات وكیف تتم بشكل مبسط، وسوف

نخوض في مزيد من التفاصیل في دروس لاحقة بإذن الله.

) •·.·´¯`·.·• نھا ية الدرس الأول •·.·´¯`·.·• (

9

•·.·´¯`) •·.·´¯`·.·• نقاش الدرس الأول ·.·• (

س 1 - ھل المقصود بھذي الجملة ان المبرمج لا يستطیع حل المشكله فقط مھندس البرمجیات

ھو الذي يستطیع؟؟؟؟

ممكن أن يوجد شخص تعلم البرمجة دون أن يدرس ھندسة برمجیات و شخص آخر درس ھندسة البرمجیات

وبالطبع علوم الحاسوب .. لو اعطیت ھذين الشخصین مشكلة ما .. سیكون حل مھندس البرمجیات

للمشلكة أفضل من حل المبرمج الذي لم يدرس ھندسة البرمجیات

"تستطیع أن تقول أن كل مھندس برمجیات ھو مبرمج بینما لیس كل مبرمج ھو مھندس برمجیات"

نعم ھذا ھو المقصود، ھندسة البرمجات لا تھتم فقط بكتابة برنامج يؤدي مھمة محددة فحسب، بل أنھا

تھتم بما ھو أكثر من ذلك "جودة البرنامج"

تطلق على كل من يعرف كیف يكتب برنامج للقیام بأداء عمل ما.. Hacker كلمة مبرمج أو

ولكن كلمة مھندس برمجیات لا تطلق إلا على من يكتب ھذه البرمجیات باسلوب علمي يسعى من خلاله

إلى أن تكون برامجه ذات جودة عالیة.

؟ Art س 2 - ما المقصود في فن

بالانجلیزي = Art ھو الفن .. لأن كلمة الفن Art المقصود بكلمة

واما المقصود بالدرس ..

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

شخصیین مختلفیین ويودي نفس المھام...

وھذا كله يعتمد علي اسلوب المبرمج وكیفیة حله للمشكلة وطريقة صیغته للبرنامج .

س 3 - ھل يوجد فرق بین مھندس برمجیات و محلل نظم ؟

نعم ھناك فرق بین مھندس البرمجیات ومحلل النظم فمثلا في الدول المتقدمة يقوم محلل النظام بدراسة

المشروع المراد تنفیذه وكیفیة حل المشاكل التي توجه كما ويقوم بدراسة الجدوى ومعرفة متطلبات

النظام ...الخ

أي انه يقوم بتحلیل النظام المراد بنائه تحلیل دقیق .

اما مھندس البرمجیات فیقوم ببرمجة النظام وتھیئته كي يظھر في الصورة النھائیة..

أي يحتاج على الاقل الي شخصین كي يتم بناء النظام او البرنامج المطلوب.

10

الدرس الثاني: دورة حیاة تطوير المشروع

أھداف الدرس الثاني:

كما رأينا في الدرس الاول فإن ھندسة البرمجیات ھو عمل إبداعي يتم إداءه خطوة بخطوة، ويتعاون فیه عدد

من الاشخاص لكل منھم مھمة محددة .في ھذا الدرس سوف نناقش الخطوات التي يتم اتباعھا عند تطوير

مشروع برمجي بمزيد من التفاصیل ونبحث في الطرق المستخدمة لتنظیم ھذا العمل (صناعة البرمجیات(

مقدمة:

ومما تعلمنا في الدرس ،" Life Cycle عملیة بناء أي منتج تمر بعدة مراحل يطلق علیھا عادة "دورة الحیاة

تتضمن المراحل التالیة: Software development life cycle السابق فإن دروة حیاة تطوير أي نظام برمجي

Requirements analysis and definition 1تحديد وتعريف المتطلبات .

System design 2تصمیم النظام .

Program design 3تصمیم البرنامج .

) Program implementation 4كتابة البرنامج (تطويره .

Unit testing 5أختبار وحدات البرنامج .

system testing 6أختبار النظام .

system delivery 7تسلیم النظام .

maintenance 8الصیانة .

كل مرحلة من تلك المراحل تتضمن العديد من الخطوات أو النشاطات ولكل منھا مدخلاتھا ومخرجاتھا وتأثرھا

على جودة المنتج النھائي) البرنامج.(

دورة حیاة أي منتج تبدأ بأول خطوة وھي تحديد المتطلبات وتتدرج إلى باقي الخطوات كما ھي مرتبة حتى

الوصول إلى آخر خطوة وھي تسلیم البرنامج وصیانته (إن دعت الحاجة)، إلا أن التجارب العملیة تظھر أن ھذا

لیس ضروريا وأن دورة حیاة تطوير البرامج قد تأخذ أشكال (أو أنماط) مختلفة. وفي ھذا الدرس سوف نتعرف

إلى ھذه الأنماط

Lifecycle Models: أنماط دورة الحیاة

Waterfall Model النموذج الانحداري

في ھذا النموذج تسیر دورة الحیاة بشكل تدريجي بدأ من الخطوة ( 1) وحتى الخطوة ( 8)، وكما يظھر

بالشكل ( 1) فإن كل مرحلة تبدأ بعد الأنتھاء من المرحلة التي تسبقھا مباشرة.

11

(1- شكل ( 2

يتمیز النموذج الانحداري بالبساطة، ولذا فإنه يسّھل على المطور توضیح كیفیة سیر العمل بالمشروع

للعمیل (الذي عادة لا يعرف الكثیر عن صنع البرمجیات) والمراحل المتبقیة من العمل. وقد كان ھذا النموذج

أساس عمل كثیر من المؤسسات لفترة طويلة مثل وزارة الدفاع الامريكیة، واستنبط منه العديد من النماذج

الاكثر تعقیدا.

إلا أن لھذا النموذج العديد من العیوب، أھمھا أنه لا يعكس الطريقة التي يعمل بھا المطورون في الواقع.

فباستثناء المشاريع الصغیرة والبسیطة (أي أنھا مفھومة بشكل جید للمطور) فإن البرمجیات عادة ما تنتج

بعد قدر ھائل من التكرار والاعادة. في حین أن ھذا النموذج يفترض أن يكون الحل واضح ومفھوم وسبق

تحلیله بالكامل قبل مباشرة مرحلة التصمیم وھو أمر يكاد يكون شبه مستحیل مع الانظمة الضخمة. وحتى

إن كان ممكن فإنه يأخذ وقت طويل جدا (ربما سنوات!(

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

تعقید المشروع.

Phased Development التطوير على مراحل

حسب النموذج الانحداري فإنه يجب على المطورين إنھاء مرحلة تحلیل المشروع بشكل تام قبل البدأ في

التصمیم، وكما وضحنا فإن ھذه المرحلة قد تتطلب وقت طويل في بعض المشاريع وقد تمر عدة سنوات قبل

أن يرى البرنامج النھائي النور، ولكن ھل يمكن لسوق العمل الانتظار كل ھذا الوقت؟!

الاجابة بالطبع لا.

أحد ھذه الطرق ھي التطوير Cycle time. لذا كان لابد من ايجاد طرق آخرى لتقلیل زمن تطوير المشروع

حیث يتم تطوير النظام على عدة مراحل، بتقديم إصدار من البرنامج به Phased Development على مراحل

بعض الوظائف للعمیل والعمل على تطوير الاصدار الاحق الذي سوف يقدم له بقیة الوظائف.

يوجد عدة طرق يمكن بھا تنظیم عملیة تطوير إصدارات البرنامج، ومن اشھرھا:

Incremental model النموذج التزايدي ·

12

حیث يتم تقسیم النظام المطلوب تطويره إلى عدة اجزاء حسب الوظائف التي يعتین علیه القیام بھا، يبدأ

أول إصدار بأحد تلك الاجزاء ومع الوقت يتم إضافة المزيد من الاجزاء (الوظائف) حتى يتم الانتھاء من تطوير

النظام بشكل تام وحسب متطلبات العمیل.

Iterative model النموذج التكراري ·

ھذه المرة يتم تسلیم برنامج بكامل الوظائف من أول مرة، ولكن يتم تعديل وتغییر بعض تلك الوظائف مع كل

إصدار من البرنامج.

من ممیزات ھذا الأسلوب أنه يمكن المطورين من الحصول على ملاحظات وتقییم الزبون مبكرا و بصورة

منتظمة، ورصد الصعوبات المحتملة قبل التمادي بعیدا في عملیات التطوير.كم أنه يمّكن من اكتشاف مدى

حجم و تعقید العمل مبكرا.

Spiral Model النموذج اللولبي

وھو شبیه لدرجة كبیرة إلى النموذج التزايدي والتكراري، ولكن فیه يتم دمج فعالیات التطوير مع إدارة المخاطر

من إجل التحكم بھا وتقلیلھا. risk

يبدأ النموذج اللولبي بمتطلبات العمیل مع خطة العمل المبدئیة (المیزانیة، قیود النظام، والبدائل المتاحة). ثم

يتقدم خطوة إلى الامام بتقدير المخاطر وتمثیل البدائل المتاحة قبل تقديم ما يعرف ب "وثیقة العملیات "

التي تصف وبشكل عام (بدون الدخول في التفاصیل) كیف يجب على النظام أن Concept of Operations

يعمل. بعدھا يتم تحديد وتدقیق المتطلبات للتأكد من أنھا تامة ودقیقة إلى أقصى حد ممكن.

بذلك تكون وثیقة العملیات ھي المنتج من الطور الأول، و المتطلبات ھي المنتج الاساسي من الطور الثاني.

وفي الطور الثالث تتم عملیة التصمیم، أما الاختبار فیتم خلال الطور الرابع.

في كل طور أو مرحلة يساعد تحلیل المخاطر على تقدير البدائل المختلفة في ضوء متطلبات وقیود النظام،

وتساعد النمذجة على التحقق من ملائمة أي بديل قبل أعتماده.

13

(2- شكل ( 2

) •·.·´¯`·.·• نھاية الدرس الثاني •·.·´¯`·.·• (

14

•·.·´¯`·) •·.·´¯`·.·• نقاش الدرس الثاني .·• (

WaterFall Model .. لي ملاحظه و ھي في ال

لأخر و كلما كان ھذا الرجوع أكبر كلما كان مكلف أكثر Phase من back track ھل من الممكن أن يكون ھناك

من ناحیة الوقت و التعديل و المال ؟؟

Phase من back track نعم من الممكن أن يكون ھناك

وغالبا ما يكون ھذا ما يحصل بالفعل عند التطبیق العملي...

ولیس ھذا فقط .. فبعد كل مرحلة ممكن يُكتشف أن ناتج models ممكن يحدث في جمیع ال backtrack ال

أحد المراحل السابقة لم يكن صحیح ويحتاج إلى تعديل

وھذا ما يجعل أنماط آخرى كالنمط اللولبي أكثر تفضیلا.

Waterfall Model بالنسبة لل backtrack صورة لل15

الدرس الثالث: دراسة المتطلبات

في ھذا الدرس سوف نبدأ في دراسة أول (ولعلھا أھم) خطوة في تطوير البرامج وھي تحديد متطلبات

Capturing the requirements. النظام

الھدف من تحديد المتطلبات ھو فھم ما يتوقعه العمیل والمستخدم من النظام (ما الذي يمكن للنظام أداؤه

وما لا يمكنه أداؤه).فقد يكون النظام المطلوب تصمیمه بديل لنظام أو لطريقة مستخدمة لأداء مھمة محددة،

أو ممكن أن يكون نظام جديد يقدم خدمة جديدة لم يسبق تقديمھا من قبل. فلكل نظام برمجي وظیفة

معینة، تحدد بما يمكن له أن يقوم به من أجل أداء تلك الوظیفة.

المتطلبات :ھي تعريف لشكل النظام أو وصف لما يستطیع ھذا النظام أن يقوم به لأداء وظیفته التي

سیصمم من أجلھا.

خطوات تحديد المتطلبات :

أولا: الاجتماع مع العمیل للتعرف على المتطلبات:

وھذه خطوة ھامة جدا إذ أن بقیة الخطوات التالیة تعتمد علیھا بشكل أساسي. لذا يجب علینا أن نستخدم

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

المستخدم بكل أبعادھا، نتعرف على العملیات والمصادر التي تتضمنھا المشكلة والعلاقات التي تربطھا معا و

نحدد حدود النظام. وھذا يمكن أن يتم من خلال:

طرح الأسئلة على العمیل، ومن المفید أحیانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من ·

مرة فھذا يساعدنا على التأكد من أننا نفھم ما يقصده العمیل بالتحديد.

عرض نظم مشابه للنظام المطلوب سبق تصمیمھا من قبل. ·

تصمیم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل. ·

تقسم المتطلبات إلى عدة عناصر تشمل:

Physical Environment البیئة المحیطة بالنظام ·

Interfaces وجھات الاستخدام ·

Users and human factors المستخدمین وإمكاناتھم ·

Functionality وظائف النظام ·

Documentation التوثیق ·

Data البیانات ·

Resources المصادر ·

Security الأمن ·

Quality Assurance ضمان الجودة ·

ويجب التأكد من أن نناقش جمیع ھذه العناصر

ثانیا: تسجیل ھذه المتطلبات في وثائق أو قاعدة بیانات، وعرضھا على العمیل لیوافق علیھا باعتبار أنھا ما

يطلبه بالفعل

المتطلبات لا تصف فقط تدفق البیانات والمعلومات من وإلى النظام، وأما تصف كذلك القیود المفروضة على

عمل النظام. وبذلك فإن عملیة تحديد المتطلبات تخدم ثلاثة أغراض:

16

أولا تمكن المطورين من شرح فھمھم للطريقة التي يود المستخدمین أن يعمل بھا النظام. ·

ثانیا توضح للمصممین ماھیة الوظائف والخصائص التي سیمتاز بھا النظام , ·

وثالثا: توضح المتطلبات لفريق الاختبار ما الذي يجب إثباته لإقناع الزبون أن النظام الذي تم تطويره ·

ھو ما سبق أن طلبه بالضبط .

لذلك ولضمان أن كلا من المطورين والزبون متفاھمون تماما على ما يجب القیام به، فإن المتطلبات المسجلة

حتى ھذه الخطوة يجب أن تكون لھا الصفات التالیة:

وخالیة من الأخطاء. Correct 1أن تكون صحیحة .

بمعنى أن لا يكون ھناك أي تعارض بین متطلب وآخر. consistent 2أن تكون ثابتة .

يجب أن يتم ذكر جمیع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة Complete 3أن تكون تامة .

منه، ...الخ .

بمعنى أن تكون قابلة للتطبیق في الواقع. realistic 4أن تكون واقعیة .

5أن تكون متعلقة بأمور ضرورة للعمیل، ويتطلبھا النظام. .

verifiable 6أن يكون من الممكن التحقق منھا .

traceable 7أن تكون قابلة للتتبع .

" Requirement Definition Document يطلق على ھذه الوثائق "وثائق تعريف المتطلبات

لیقوم المصممون بتحويل تلك المتطلبات إلى mathematical ثالثا: إعادة تسجیل المتطلبات بشكل رياضي

تصمیم جید للنظام في مرحلة التصمیم.

لسنوات عديدة كان يتم الاكتفاء بوثیقة تعريف المتطلبات (التي تحدثنا عنھا قبل قلیل) والتي تكتب

باستعمال اللغة الطبیعیة) لغة البشر) لوصف وتسجیل متطلبات النظم بحیث يمكن للعمیل أن يفھم كل

كلمة موجودة بھا، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببھا في أغلب الأحیان إلى سوء

تفسیر بعض التعبیرات للمستخدمین من قبل المصمم أو العكس، فعلى سبیل المثال قد يطلق المستخدم

باعتبار أن backup على النظام التعبیر (متوقف عن العمل) إذا كان النظام مشغول بعملیة تسجیل احتیاطي

لا يستجیب لأوامر المستخدم في ھذه الحالة، بینما يعتبر المصمم أن النظام في ھذه الحالة (مستمر في

العمل) لأنه يقوم بمھمة أساسیة!

لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثیرة عند تصمیم النظام، وينتج عنھا

نظام لا يقبله العمیل لأنه لا يلبي متطلباته التي حددھا من قبل، لذلك يتم كتابة نوع ثاني من الوثائق

وھي تكتب باستعمال وسائل " Requirement specification Document تسمى "وثائق مواصفات المتطلبات

وطرق خاصة ابتكرھا مھندسو البرمجیات لكتابة المتطلبات باسلوب تقني بحت. منھا على سبیل المثال: لغة

و ھي لغة نمذجة رسومیة تقدم لنا صیغة لوصف UML Unified Modeling Language النمذجة الموحدة

العناصر الرئیسیة للنظم البرمجیة.

UML الشكل التالي يعرض مثال على استعمال

17

رابعا: التثبت والتحقق من المتطلبات التي تم تسجلیھا في كلا من وثیقة تعريف المتطلبات (والتي تقدم

للعمیل) ووثیقة مواصفات المتطلبات (والتي تقدم للمصمم (للتأكد من صحتھما وشمولیتھما وأن كلا منھما لا

تعارض الثانیة في أي نقطة، وإلا فإن النتیجة سوف تكون نظام لا يلبي طلبات العمیل.!

) •·.·´¯`·.·• نھاية الدرس الثالث •·.·´¯`·.·• (

18

•·.·´¯`·) •·.·´¯`·.·• نقاش الدرس الثالث .·• (

_________________أقتباس__________________

أولا: الاجتماع مع العمیل للتعرف على المتطلبات:

وھذه خطوة ھامة جدا إذ أن بقیة الخطوات التالیة تعتمد علیھا بشكل أساسي. لذا يجب علینا أن نستخدم

كافة التقنیات المتاحة لنكتشف ما الذي يطلبه العمیل والمستخدم،............. الخ

اخر شي قلتي" : ويجب التأكد من أن نناقش جمیع ھذه العناصر"

_________________________________________

ھل تقصدين النقاش مع العمیل!!?

نعم يجب مناقشة كل نقطة مع العمیل للتأكد من اننا فھمنا ما يقصده تماما.

Physical Environment .. البیئة المحیطة بالنظام

لم أقھم ما تقصدين بالبیئة المحیطة؟؟

يقصد بھا كل ما يحیط بالنظام ولیس من مكوناته مثلا الموقع الذي سیعمل به النظام، ھل ھو ثابت في

Hardware + موقع واحد أكثر أو يمكن أن يتم نقله إلى مواقع مختلفة (طبعا الحديث يشمل النظام كامل

software)

نربد توضیح او مثال عن صفات المتطلبات الأتیة :

1

verifiable . أن يكون من الممكن التحقق منھا

بمعنى أن تكتب المتطلبات بحیث تكون قابلة للاختبار للتأكد من تحققت، فمثلا قد يذكر العمیل أن يريد من

النظام أن يكون ذا استجابة سريعة!

ما مقدار السرعة المطلوب؟

قد يرى المصمم أن الانتظار لمدة 50 ثانیة مناسب كحد أقصى، بینما يتوقع الزبون زمن انتظار 20 ثانیة كحد

أقصى!

traceable 2 أن تكون قابلة للتتبع .

بمعنى أن تكون المتطلبات مكتوبة بحیث يسھل تتبعھا للتأكد من أن كل وظیفة مطلوبة من النظام تم

استیفائھا من خلال المتطلبات.

19

الدرس الرابع: تصمیم النظام

نكمل مع خطوات بناء النظام، وھذه المرة سوف نتحدث عن خطوة "تصمیم النظام "

ما ھو التصمیم؟

التصمیم ھو عملیة إبداعیة لإيجاد حل لمشكلة، كما تطلق عادة كلمة تصمیم على وصف ھذا الحل.

حیث نستفید من المتطلبات التي حددنھا في الخطوة السابقة في التعرف على المشكلة، ثم نبدأ في

التفكیر في الحل الذي يفي بجمیع الشروط والمواصفات التي تحددھا المتطلبات، وغالبا ما يمكن إيجاد عدد

غیر محدود من الحلول يمكن لنا أن نختار أحدھا و الذي نجده الأنسب من بینھا.

عند الانتھاء من خطوة تحديد المتطلبات، فإننا ننتھي بوثیقتین (كما ذكرنا في الدرس السابق) الأولى ھي

(وثیقة تعريف المتطلبات) ويتم تقديمھا للعمیل والثانیة (وثیقة مواصفات المتطلبات) ويتم تقديمھا للمصمم.

ودور المصمم ھو تحويل ھذه الوثائق إلى نظام يرضي العمیل (يلبي احتیاجاته)، وفي نفس الوقت يرضي

المطور (يمكن تطبیقه.(

من خطواتین: iterative لذا فإن عملیة التصمیم في عملیة تكرارية

والذي يوضح للعمیل ما الذي سیقوم به النظام conceptual design أولا :يتم إنتاج التصمیم التصوري

بالتحديد .

وفي حال موافقة العمیل على ھذا النظام، يتم الانتقال للخطوة التالیة.

ثانیا :تحويل التصمیم التصوري إلى وثیقة بھا تفاصیل أكثر عن التصمیم يطلق علیھا اسم التصمیم التقني

والذي يجب أن يظھر للمطور ما ھي المعدات والبرمجیات اللازمة لبناء النظام. technical design

أحیانا يتطلب الأمر للعودة إلى الخطوة الأولى) التصمیم التصوري) والتعديل علیه، لذا فأنھا عملیة تكرارية

حتى الوصول إلى التصمیم الذي يرضي العمیل ويمكن تطبیقه على أرض الواقع في ظل الإمكانیات المتاحة

للمطورين.

20

conceptual design: التصمیم التصوري

ويكتب بلغة يمكن للعمیل أن يفھمھا (لغة البشر) لیجیب functions يركز ھذا التصمیم على وظائف النظام

يعمل النظام. ويجب أن يكون خالي تماما من أي تفاصیل برمجیة أو (WHAT) عن أسئلة العمیل حول ماذا

فنیة. والاھم أن يحقق كل المتطلبات التي تم تحديدھا سابقا.

technical design التصمیم التقني

ھذا التصمیم سوف يتم تقديمه إلى مطوري النظام لیقوموا ھم بتحويله إلى النظام المطلوب، لذا يجب أن

تطوير النظام. ولمنع إلى تضارب في (HOW) يقدم ھذا التصمیم إجابة شافیة لأسئلة المطور عن كیفیة

المفاھیم فإن ھذا التصمیم عادة ما يكتب باستعمال تعبیرات وأسالیب تقنیة.

) •·.·´¯`·.·• نھاية الدرس الرابع ولا يوجد نقاش له •·.·´¯`·.·• (

21

الدرس الخامس: كتابة البرنامج واختباره

أھداف الدرس:

ھذا الدرس لن يعلمك لغة برمجة لتكتب بھا البرامج، ولكن الھدف منه التعرف على:

القواعد الصحیحة لكتابة البرامج ·

خطة الاختبار وأنواع الاختبارات ·

الجزء الأول :كتابة البرامج:

بعد وضع التصمیم للنظام واختیار لغة البرمجة المناسبة، تبدأ الخطوة التي سوف تنقل التصمیم المكتوب

على الورق إلى واقع. خلال ھذا الدرس سوف نناقش أھم القواعد التي على المبرمج إتباعھا أثناء كتابة

برامجه. ولكن قبل ذلك لنجیب على ھذا السؤال الذي لا شك أنه ورد على ذھنك الآن

س: لماذا علینا إتباع ھذه القواعد؟

ج :إذا كنت تعمل منفردا في كتابة برامجك، فإن إتباعك لقواعد وأسالیب قیاسیة في البرمجة سوف تساعدك

على تنظیم أفكارك لتجنب الوقوع في الأخطاء. كما أنھا ستساعدك على اكتشاف أي أخطاء قد تحدث

بسرعة وبسھولة.

أم إذا كنت تعمل ضمن فريق برمجي، فإن إتباع القواعد والأسالیب القیاسیة في كتابة أجزاء البرامج التي

يطلب منك كتابتھا، سوف تساعدك وبقیة الفريق من تنسیق أعمالكم وتنظیمھا، كما أنھا ستقلل من عدد

الأخطاء في البرنامج وتساعد على اكتشاف ما يقع منھا في اسرع وقت ممكن.

تفرض الكثیر م

أخي محمد منير ...

يعني لو كبّرت الخط كمان شوي بس!!!!!!

------------- في إختراع اسمه رابط... ضع رابط بدل ما تنسخ كل النت هون.

معلش شكرا لتفهمك.

أخي العزيز

أشكرك جدا على الرد وعلى النسخ واللصق

ولكن أخي كنت أريد من شخص متخصص في هذا المنتدى

ويكون مهندس برمجيات يعطيني إجابة وإفادة من عنده

سلام

و من أدراك أن الشخص الذي رد عليك ليس متخصصاً؟ عدد المشاركات لم يكن أبداً مقياساً في أي يوم من الأيام.

الذي أدراني أنه شخص غير متخصص وليس مهندس

أن الكلام الذي جلبه لي من موقع آخر وأنه استفاد من خاصية النسخ واللصق فقط

وأنه لم يأتي بكلام جديد

فأنا أريد مهندس متخصص يفيدني

وشكرا

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

ثم أفرض أن شخصاً قام بالفعل بكتابة رد. ما الذي سيدريك أنه متخصص؟ في الإنترنت يمكن لأي شخص أن يتقمص شخصية المتخصص. إقرأ المعلومة و احكم عليها من محتواها و ليس من هوية كاتبها.

خلاص أخي أنا غلطان

كل الكلام الذي أتى به الأخ الذي في الأعلى أعرفه تماما

ولكن كنت أريد أحد في المنتدى هنا يفيدنا أكثر

أعلم أن هناك أناس يتقمصون الشخصيات

ولعلمك أنا أتخصص حاليا في مجال هندسة البرمجيات وأريد معلومات عميقة

ولكن للأسف

سأبحث في مكان آخر يفيدني

سلام

اخى الى يطلب مساعدة او سؤال ما اعتقد ان يتم الطلب بطريقة دى بتعتك

دى مجرد وجة نظر

................

السلام عليكم

اقتباس

ولعلمك أنا أتخصص حاليا في مجال هندسة البرمجيات وأريد معلومات عميقة

ولكن للأسف

سأبحث في مكان آخر يفيدني

سلام

يا أخي ما في حد ضربك على إيدك وقال لك تيجي تدور هنا

نقول شكرا للأخ الذي رد عليك

والشبكه مليئه ممكن تبحث في أي مكان

أم أنه إما أن تكون المعلومه جاهزه للقطف أو لا نريدها من الأصل

أأسف على طريقتي في العرض ولكن اعلم أخي أنه "من لم يشكر الناس لم يشكر الله"