دورات هندسية

 

 

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

صفحة 1 من 57 12 3 4 5 1151 ... الأخيرةالأخيرة
النتائج 1 إلى 10 من 568
  1. [1]
    المهندس المسلم.
    المهندس المسلم. غير متواجد حالياً

    مشرف سابق

    تاريخ التسجيل: Jul 2005
    المشاركات: 680
    Thumbs Up
    Received: 8
    Given: 0

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

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


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

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

    ما هي هندسة البرمجيات؟
    من يشارك بها؟
    ما هي مكونات النظم البرمجية؟
    وكيف يتم بنائها؟



    مقدمة:

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

    المرجع :

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



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

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

    يهتم الكيميائي بدراسة المواد الكيميائية (تركيبها، تفاعلاتها، والنظريات التي تحكم سلوكها).
    بينما المهندس الكيميائي يستخدم النتائج التي توصل إليها الكميائي لحل المشاكل التي يطلب منه إيجاد حل لها.

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

    ومن وجهه نظر المهندس الكميائي الكيمياء هي أداة tool تستخدم لأيجاد الحلول لمشاكل عامة (وقد لا تكون هذه المشكلة ذات طبيعة كيميائية بحد ذاتها).

    وبنفس الفكرة يمكن النظر إلى علم الحوسبة computer science حيث يكون تركيزنا على الحواسيب ولغات البرمجة لدرستها وتطويرها في حد ذاتها.
    أو يمكن النظر إليها والتعامل بها على أنها أدوات نستخدمها عند تصميم وتطوير حل لمشكلة ما تواجهنا أو الآخرين.

    مهندس البرمجيات Software Engineer يعتبر أن الكمبيوتر هو أداة لحل المشاكل problem-solving tool.
    وعليه أن يستخدم معلوماته حول الحاسوب وعلم الحوسبة للمساعدة في حل المشكلة التي يطلب منه إيجاد حل لها.



    شكل (1)



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

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

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

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

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

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

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

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

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



    شكل (2)



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

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

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

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

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

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

    2. العلاقات وحدود النظام Relationships and System Boundary
    بعد تعريف الكائنات والنشاطات جيدا، يمكن أن نربط بين كل كائن والنشاطات المتعلقة به بدقة. تعريف الكائن يتضمن الموقع الذي سوف ينشأ به(نعض العناصر يمكن أن تكون موجودة بملف سبق انشاءه، والبعض قد يتم انشاءه خلال حدث ما)، والهدف من انشاءه(بعض الكائنات تستخدم من قبل نشاط واحد فقط والبعض يمكن أن يستعمل من قبل نظم آخرى كمدخلات Input) , لذا يمكن أن نعتبر أن لنظامنا حدود boundary بعض الكائنات بمكن أن تعبر هذه الحدود إلى داخل النظام، والبعض الآخر هي مخرجات من نظامنا ويمكن أن ترحل إلى نظم آخرى.

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

    · مجموعة من الكائنات entities.
    · مجموعة من الانشطة activities.
    · وصف للعلاقات بين الكائنات والانشطة Relationship.
    · تعريف لحدود النظام boundary.



    كيف نبي نظام؟

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

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

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

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

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

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

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


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



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

  2. [2]
    المهندس
    المهندس موجود حالياً
    ،، المشرف العام ،،
    الصورة الرمزية المهندس


    تاريخ التسجيل: Oct 2001
    المشاركات: 11,787
    Thumbs Up
    Received: 273
    Given: 428
    ما شاء الله تبارك الله ..

    مجهود رائع و معلومات قيمة ..
    بداية موفقة و بنتظار الباقي من الدروس ..

    بارك الله فيك و في مجهوداتك ..

    تحياااااااتي
    :)

    0 Not allowed!



  3. [3]
    M.Ghareb
    M.Ghareb غير متواجد حالياً
    عضو فعال جداً


    تاريخ التسجيل: Dec 2005
    المشاركات: 173
    Thumbs Up
    Received: 8
    Given: 0
    جزاكم الله خيرا يا أخى الكريم وأرجو التواصل ، وبالتوفيق ان شاء الله

    0 Not allowed!



  4. [4]
    المهندس المسلم.
    المهندس المسلم. غير متواجد حالياً
    مشرف سابق


    تاريخ التسجيل: Jul 2005
    المشاركات: 680
    Thumbs Up
    Received: 8
    Given: 0

    Lightbulb

    السلام عليكم ورحمة اللة تعالى وبركاته/

    جزاكم الله كل خير وعافيه ودعونا جميعاً نشارك في نهوض هذا القسم من حالة الركود إلى حالة الرقي والتقدم إن شاء الله ولكم مني جزيل الشكر.

    0 Not allowed!



  5. [5]
    المغمور
    المغمور غير متواجد حالياً
    جديد


    تاريخ التسجيل: Apr 2006
    المشاركات: 1
    Thumbs Up
    Received: 0
    Given: 0

    هيا نحاول ان نكون الافضل دائما

    السلا عليكم ورحمة الله وبركاته
    شكرا جزيلا وارجوا منكم المتابعة
    حتى نستطيع ان نملك العالم ونهديه الى الخير من جديد
    والى اللقاء
    ................................المغمور........... ..................................

    0 Not allowed!



  6. [6]
    المهندس المسلم.
    المهندس المسلم. غير متواجد حالياً
    مشرف سابق


    تاريخ التسجيل: Jul 2005
    المشاركات: 680
    Thumbs Up
    Received: 8
    Given: 0

    Lightbulb

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


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



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

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

    مقدمة:

    عملية بناء أي منتج تمر بعدة مراحل يطلق عليها عادة "دورة الحياة" Life Cycle، ومما تعلمنا في الدرس السابق فإن دروة حياة تطوير أي نظام برمجي Software development life cycle تتضمن المراحل التالية:

    1. تحديد وتعريف المتطلبات Requirements analysis and definition
    2. تصميم النظام System design
    3. تصميم البرنامج Program design
    4. كتابة البرنامج (تطويره) Program implementation
    5. أختبار وحدات البرنامج Unit testing
    6. أختبار النظام system testing
    7. تسليم النظام system delivery
    8. الصيانة maintenance


    كل مرحلة من تلك المراحل تتضمن العديد من الخطوات أو النشاطات ولكل منها مدخلاتها ومخرجاتها وتأثرها على جودة المنتج النهائي (البرنامج).

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


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


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

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



    شكل (1)


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

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

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

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


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

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

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

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

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

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

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


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

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


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


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

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

    يبدأ النموذج اللولبي بمتطلبات العميل مع خطة العمل المبدئية (الميزانية، قيود النظام، والبدائل المتاحة). ثم يتقدم خطوة إلى الامام بتقدير المخاطر وتمثيل البدائل المتاحة قبل تقديم ما يعرف بـ "وثيقة العمليات" Concept of Operations التي تصف وبشكل عام (بدون الدخول في التفاصيل) كيف يجب على النظام أن يعمل. بعدها يتم تحديد وتدقيق المتطلبات للتأكد من أنها تامة ودقيقة إلى أقصى حد ممكن.

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

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






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

    0 Not allowed!



  7. [7]
    smsmh
    smsmh غير متواجد حالياً
    جديد


    تاريخ التسجيل: Mar 2006
    المشاركات: 1
    Thumbs Up
    Received: 0
    Given: 0
    أشكرك جدا جدا على ارسال المشاركة وياريت المزيد عن صيانة الكمبيوتر وماهى مكونات الكيسة الخاصة بيها وكيف اتعرف على المشاكل الخاصة بيها وكيفية أصلاحها وماهى مكوناتها واهى أحسن مواصفات لتجميع الكيسه

    0 Not allowed!



  8. [8]
    المهندس المسلم.
    المهندس المسلم. غير متواجد حالياً
    مشرف سابق


    تاريخ التسجيل: Jul 2005
    المشاركات: 680
    Thumbs Up
    Received: 8
    Given: 0

    Lightbulb

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

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


    في هذا الدرس سوف نبدأ في دراسة أول (ولعلها أهم) خطوة في تطوير البرامج وهي تحديد متطلبات النظام Capturing the requirements.


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


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

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


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

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

    1-طرح الأسئلة على العميل، ومن المفيد أحيانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من مرة فهذا يساعدنا على التأكد من أننا نفهم ما يقصده العميل بالتحديد.

    2-عرض نظم مشابه للنظام المطلوب سبق تصميمها من قبل.

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

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


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

    وجهات الاستخدام Interfaces

    المستخدمين وإمكاناتهم Users and human factors

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

    التوثيق Documentation

    البيانات Data

    المصادر Resources

    الأمن Security

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

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

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

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

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

    ثانيا توضح للمصممين ماهية الوظائف والخصائص التي سيمتاز بها النظام.

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


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

    1. أن تكون صحيحة Correct وخالية من الأخطاء.
    2. أن تكون ثابتة consistent بمعنى أن لا يكون هناك أي تعارض بين متطلب وآخر.
    3. أن تكون تامة Complete يجب أن يتم ذكر جميع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة منه، ...الخ.
    4. أن تكون واقعية realistic بمعنى أن تكون قابلة للتطبيق في الواقع.
    5. أن تكون متعلقة بأمور ضرورة للعميل، ويتطلبها النظام.
    6. أن يكون من الممكن التحقق منها verifiable
    7. أن تكون قابلة للتتبع traceable
    يطلق على هذه الوثائق "وثائق تعريف المتطلبات" Requirement Definition Document


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

    لسنوات عديدة كان يتم الاكتفاء بوثيقة تعريف المتطلبات (التي تحدثنا عنها قبل قليل) والتي تكتب باستعمال اللغة الطبيعية (لغة البشر) لوصف وتسجيل متطلبات النظم بحيث يمكن للعميل أن يفهم كل كلمة موجودة بها، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببها في أغلب الأحيان إلى سوء تفسير بعض التعبيرات للمستخدمين من قبل المصمم أو العكس، فعلى سبيل المثال قد يطلق المستخدم على النظام التعبير (متوقف عن العمل) إذا كان النظام مشغول بعملية تسجيل احتياطي backup باعتبار أن لا يستجيب لأوامر المستخدم في هذه الحالة، بينما يعتبر المصمم أن النظام في هذه الحالة (مستمر في العمل) لأنه يقوم بمهمة أساسية!
    لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثيرة عند تصميم النظام، وينتج عنها نظام لا يقبله العميل لأنه لا يلبي متطلباته التي حددها من قبل، لذلك يتم كتابة نوع ثاني من الوثائق تسمى "وثائق مواصفات المتطلبات" Requirement specification Document وهي تكتب باستعمال وسائل وطرق خاصة ابتكرها مهندسو البرمجيات لكتابة المتطلبات باسلوب تقني بحت. منها على سبيل المثال: لغة النمذجة الموحدة UML Unified Modeling Language و هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية.
    الشكل التالي يعرض مثال على استعمال UML


    رابعا: التثبت والتحقق من المتطلبات التي تم تسجليها في كلا من وثيقة تعريف المتطلبات (والتي تقدم للعميل) ووثيقة مواصفات المتطلبات (والتي تقدم للمصمم) للتأكد من صحتهما وشموليتهما وأن كلا منهما لا تعارض الثانية في أي نقطة، وإلا فإن النتيجة سوف تكون نظام لا يلبي طلبات العميل!.






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

    0 Not allowed!



  9. [9]
    الموسوي
    الموسوي غير متواجد حالياً
    جديد


    تاريخ التسجيل: Apr 2006
    المشاركات: 7
    Thumbs Up
    Received: 0
    Given: 0
    شكرا جزيلا لكم وجزاكم اله الف خير

    0 Not allowed!



  10. [10]
    mohammad al zara'a
    mohammad al zara'a غير متواجد حالياً
    عضو
    الصورة الرمزية mohammad al zara'a


    تاريخ التسجيل: May 2005
    المشاركات: 13
    Thumbs Up
    Received: 1
    Given: 0
    شكرا جزيلا لك والإستفادة ممتازه من هذه الدروس

    0 Not allowed!



  
صفحة 1 من 57 12 3 4 5 1151 ... الأخيرةالأخيرة
الكلمات الدلالية لهذا الموضوع

عرض سحابة الكلمة الدلالية

RSS RSS 2.0 XML MAP HTML