software engineering chapter2, Slides of Software Development

Download software engineering chapter2 and more Slides Software Development in PDF only on Docsity! Chapter 2 – Software Processes Lecture 2 1Chapter 2 Software Processes Topics covered  Software process models  Process activities  Coping with change  The Rational Unified Process ▪ An example of a modern software process. نماذج العمليات البرمجية▪ أنشطة العملية▪ التعامل مع التغيير▪ العملية العقالنية الموحدة▪ مثال على عملية برمجية حديثة▪ 2Chapter 2 Software Processes Software process descriptions  When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities.  Process descriptions may also include: ▪ Products, which are the outcomes of a process activity; ▪ Roles, which reflect the responsibilities of the people involved in the process; ▪ Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. 5Chapter 2 Software Processes أوصاف عمليات البرامج ات مثل عندما نصف العمليات ونناقشها ، نتحدث عادةً عن األنشطة في هذه العملي .نشطةتحديد نموذج بيانات وتصميم واجهة مستخدم وما إلى ذلك وترتيب هذه األ قد تشمل أوصاف العملية أيًضا: المنتجات ، وهي نتائج نشاط العملية ؛ األدوار ، التي تعكس مسؤوليات األشخاص المشاركين في العملية ؛ اط العملية الشروط المسبقة والالحقة ، وهي عبارات صحيحة قبل وبعد تفعيل نش .أو إنتاج منتج Chapter 2 Software Processes 6 Plan-driven and agile processes  Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.  In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.  In practice, most practical processes include elements of both plan-driven and agile approaches.  There are no right or wrong software processes. 7Chapter 2 Software Processes نماذج العمليات البرمجية نموذج الشالل مراحل منفصلة ومتميزة من المواصفات والتطوير. نموذج خطة مدفوعة. التنمية المتزايدة أو قد تكون مدفوعة بالخطة. المواصفات والتطوير والتحقق من صحة معشق .رشيقة هندسة البرمجيات الموجهة إلعادة االستخدام قةقد تكون مدفوعة بالخطة أو رشي. يتم تجميع النظام من المكونات الموجودة. تضمن من الناحية العملية ، يتم تطوير معظم األنظمة الكبيرة باستخدام عملية ت .عناصر من كل هذه النماذج Chapter 2 Software Processes 10 The waterfall model Requirenne nts definition System: are soltware design Implemveniation and unit testing Integration ad system testing Operation anal maantenanmce Chapter 2 Software Processes 11 Chapter 2 Software Processes 12 Waterfall model problems  Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. ▪ Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. ▪ Few business systems have stable requirements.  The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. ▪ In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work. 15Chapter 2 Software Processes مشاكل نموذج الشالل جابة التقسيم غير المرن للمشروع إلى مراحل متميزة يجعل من الصعب االست .لمتطلبات العمالء المتغيرة ًدا وتكون لذلك ، يكون هذا النموذج مناسبًا فقط عندما تكون المتطلبات مفهومة جي .التغييرات محدودة إلى حد ما أثناء عملية التصميم قليل من أنظمة األعمال لديها متطلبات مستقرة. يتم يستخدم نموذج الشالل في الغالب لمشاريع هندسة األنظمة الكبيرة حيث .تطوير نظام في عدة مواقع نسيق في هذه الظروف ، تساعد الطبيعة القائمة على الخطة لنموذج الشالل في ت .العمل Chapter 2 Software Processes 16 Incremental development Comourrent activiti Crutline description Chapter 2 Software Processes 17 فوائد التنمية المتزايدة يتم تقليل تكلفة استيعاب متطلبات العمالء المتغيرة. ب مع كمية التحليل والتوثيق التي يجب إعادة بناؤها أقل بكثير مما هو مطلو .نموذج الشالل  من األسهل الحصول على مالحظات العمالء حول أعمال التطوير التي تم .إجراؤها دار ما تم يمكن للعمالء التعليق على العروض التوضيحية للبرنامج ومعرفة مق .تنفيذه من الممكن تقديم برامج مفيدة ونشرها للعميل بشكل أسرع. مكن يمكن للعمالء استخدام البرنامج واكتساب قيمة منه في وقت أبكر مما هو م .من خالل عملية االنحدار Chapter 2 Software Processes 20 Incremental development problems  The process is not visible. ▪ Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.  System structure tends to degrade as new increments are added. ▪ Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. 21Chapter 2 Software Processes مشاكل النمو المتزايدة العملية غير مرئية. ة إذا تم تطوير األنظم. يحتاج المديرون إلى مخرجات منتظمة لقياس التقدم مًرا فعاالً بسرعة ، فلن يكون إنتاج المستندات التي تعكس كل إصدار من النظام أ .من حيث التكلفة تميل بنية النظام إلى التدهور مع إضافة زيادات جديدة. ، فإن ما لم يتم إنفاق الوقت والمال على إعادة بناء البرامج لتحسين البرنامج رات البرمجية يصبح دمج المزيد من التغيي. التغيير المنتظم يميل إلى إفساد هيكله .أمًرا صعبًا ومكلفًا بشكل متزايد Chapter 2 Software Processes 22 Reuse-oriented software engineering fear (congener feauene System Coren fie) fear (congener feauene Coren fie) Development and integration vahdation Chapter 2 Software Processes 25 هندسة البرمجيات الموجهة إلعادة االستخدام Chapter 2 Software Processes 26 Types of software component  Web services that are developed according to service standards and which are available for remote invocation.  Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.  Stand-alone software systems (COTS) that are configured for use in a particular environment. 27Chapter 2 Software Processes أنشطة العملية فنية عمليات البرمجيات الحقيقية عبارة عن تسلسالت متداخلة من األنشطة ال تبار نظام والتعاونية واإلدارية بهدف عام يتمثل في تحديد وتصميم وتنفيذ واخ .برمجي التطوير يتم تنظيم أنشطة العملية األساسية األربعة المتمثلة في المواصفات و في . لفةوالتحقق من الصحة والتطور بشكل مختلف في عمليات التطوير المخت تكون متداخلة نموذج الشالل ، يتم تنظيمها بالتسلسل ، بينما في التطور التدريجي .األوراق Chapter 2 Software Processes 30 Software specification  The process of establishing what services are required and the constraints on the system’s operation and development.  Requirements engineering process ▪ Feasibility study • Is it technically and financially feasible to build the system? ▪ Requirements elicitation and analysis • What do the system stakeholders require or expect from the system? ▪ Requirements specification • Defining the requirements in detail ▪ Requirements validation • Checking the validity of the requirements 31Chapter 2 Software Processes أنشطة العملية تطويرهعملية تحديد الخدمات المطلوبة والقيود المفروضة على تشغيل النظام و. عملية هندسة المتطلبات دراسة الجدوى هل من الممكن فنيا وماليا بناء النظام؟ استنباط المتطلبات وتحليلها ما الذي يطلبه أو يتوقعه أصحاب المصلحة في النظام من النظام؟ مواصفات المتطلبات تحديد المتطلبات بالتفصيل التحقق من المتطلبات التحقق من صالحية المتطلباتChapter 2 Software Processes 32 Software design and implementation  The process of converting the system specification into an executable system.  Software design ▪ Design a software structure that realises the specification;  Implementation ▪ Translate this structure into an executable program;  The activities of design and implementation are closely related and may be inter-leaved. 35Chapter 2 Software Processes تصميم البرامج وتنفيذها عملية تحويل مواصفات النظام إلى نظام قابل للتنفيذ. تصميم البرمجيات تصميم هيكل برمجي يحقق المواصفات ؛ التنفيذ ترجمة هذا الهيكل إلى برنامج قابل للتنفيذ ؛ تداخلةترتبط أنشطة التصميم والتنفيذ ارتباًطا وثيقًا ويمكن أن تكون م. Chapter 2 Software Processes 36 A general model of the design process نموذج عام لعملية التصميم 37Chapter 2 Software Processes أنشطة التصميم تسمى )ة التصميم المعماري ، حيث تحدد الهيكل العام للنظام والمكونات الرئيسي .وعالقاتها وكيفية توزيعها( أحيانًا األنظمة الفرعية أو الوحدات النمطية تصميم الواجهة ، حيث تحدد الواجهات بين مكونات النظام. ملهتصميم المكونات ، حيث تأخذ كل مكون من مكونات النظام وتصمم طريقة ع. ف يتم تمثيلها تصميم قاعدة البيانات ، حيث تقوم بتصميم هياكل بيانات النظام وكي .في قاعدة البيانات Chapter 2 Software Processes 40 Software validation  Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.  Involves checking and review processes and system testing.  System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.  Testing is the most commonly used V & V activity. 41Chapter 2 Software Processes التحقق من صحة البرامج  تهدف عملية التحقق والتحقق من صحة البرمجيات(V & V) إلى إظهار أن .النظام يتوافق مع مواصفاته ويلبي متطلبات عميل النظام تتضمن عمليات فحص ومراجعة واختبار النظام. صفات يتضمن اختبار النظام تنفيذ النظام مع حاالت االختبار المشتقة من موا .البيانات الحقيقية التي سيعالجها النظام  االختبار هو نشاطV & V األكثر استخداًما. نشوئها Chapter 2 Software Processes 42 Testing stages  Development or component testing ▪ Individual components are tested independently; ▪ Components may be functions or objects or coherent groupings of these entities.  System testing ▪ Testing of the system as a whole. Testing of emergent properties is particularly important.  Acceptance testing ▪ Testing with customer data to check that the system meets the customer’s needs. 45Chapter 2 Software Processes مراحل االختبار التطوير أو اختبار المكونات يتم اختبار المكونات الفردية بشكل مستقل ؛ قد تكون المكونات وظائف أو كائنات أو مجموعات متماسكة من هذه الكيانات. اختبار النظام اختبار الخصائص الناشئة مهم بشكل خاص. اختبار النظام ككل. اختبار القبول ت العميلاالختبار باستخدام بيانات العميل للتحقق من أن النظام يلبي احتياجا. Chapter 2 Software Processes 46 Testing phases in a plan-driven software processمراحل االختبار في عملية برمجية مدفوعة بالخطة 47Chapter 2 Software Processes تطور البرمجيات البرمجيات مرنة بطبيعتها ويمكن أن تتغير. طور مع تغير المتطلبات من خالل ظروف العمل المتغيرة ، يجب أيًضا أن يت .البرنامج الذي يدعم العمل ويتغير  ألمر ، إال أن هذا ا( الصيانة)على الرغم من وجود ترسيم بين التطوير والتطور .غير ذي صلة بشكل متزايد حيث أن عدًدا أقل من األنظمة الجديدة تماًما Chapter 2 Software Processes 50 System evolution alail! | sb5 ' Define system requirements Chapter 2 Software Processes 51 Chapter 2 Software Processes 52 Key points  Requirements engineering is the process of developing a software specification.  Design and implementation processes are concerned with transforming a requirements specification into an executable software system.  Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.  Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful. 55Chapter 2 Software Processes النقاط الرئيسية هندسة المتطلبات هي عملية تطوير مواصفات البرنامج. ظام برمجيات تهتم عمليات التصميم والتنفيذ بتحويل مواصفات المتطلبات إلى ن .قابل للتنفيذ فاته التحقق من صحة البرامج هو عملية التحقق من أن النظام يتوافق مع مواص .وأنه يلبي االحتياجات الحقيقية لمستخدمي النظام ة المتطلبات يحدث تطور البرامج عندما تقوم بتغيير أنظمة البرامج الحالية لتلبي .يجب أن يتطور البرنامج ليظل مفيًدا. الجديدة Chapter 2 Software Processes 56 Chapter 2 – Software Processes Lecture 2 57Chapter 2 Software Processes التعامل مع التغيير التغيير أمر ال مفر منه في جميع مشاريع البرامج الكبيرة. تغييرات األعمال تؤدي إلى متطلبات نظام جديدة ومتغيرة تفتح التقنيات الجديدة إمكانيات جديدة لتحسين عمليات التنفيذ تغيير األنظمة األساسية يتطلب تغييرات في التطبيق على )عمل يؤدي التغيير إلى إعادة العمل ، لذا فإن تكاليف التغيير تشمل إعادة ال ذ وظائف جديدةباإلضافة إلى تكاليف تنفي( سبيل المثال ، متطلبات إعادة التحليل Chapter 2 Software Processes 60 Reducing the costs of rework  Change avoidance, where the software process includes activities that can anticipate possible changes before significant rework is required. ▪ For example, a prototype system may be developed to show some key features of the system to customers.  Change tolerance, where the process is designed so that changes can be accommodated at relatively low cost. ▪ This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have be altered to incorporate the change. 61Chapter 2 Software Processes تقليل تكاليف إعادة العمل غييرات تجنب التغيير ، حيث تتضمن عملية البرنامج أنشطة يمكنها توقع الت .المحتملة قبل الحاجة إلى إعادة صياغة مهمة ت على سبيل المثال ، قد يتم تطوير نظام نموذج أولي إلظهار بعض الميزا .الرئيسية للنظام للعمالء ييرات بتكلفة تحمل التغيير ، حيث تم تصميم العملية بحيث يمكن استيعاب التغ .منخفضة نسبيًا التغييرات قد يتم تنفيذ. هذا عادة ما ينطوي على شكل من أشكال التنمية اإلضافية ، فقد يتم إذا كان هذا مستحياًل . المقترحة في الزيادات التي لم يتم تطويرها بعد .لتضمين التغيير( جزء صغير من النظام)تعديل زيادة واحدة فقط Chapter 2 Software Processes 62 Benefits of prototyping  Improved system usability.  A closer match to users’ real needs.  Improved design quality.  Improved maintainability.  Reduced development effort. 65Chapter 2 Software Processes فوائد النماذج األولية تحسين قابلية استخدام النظام. تطابق أوثق مع احتياجات المستخدمين الحقيقية. تحسين جودة التصميم. تحسين الصيانة. انخفاض جهود التنمية. Chapter 2 Software Processes 66 The process of prototype development عملية تطوير النموذج األولي 67Chapter 2 Software Processes تطوير النموذج األولي قد يعتمد على لغات أو أدوات النماذج األولية السريعة قد تنطوي على إهمال الوظيفة يجب أن يركز النموذج األولي على مناطق المنتج غير المفهومة جيًدا ؛ قد ال يتم تضمين فحص األخطاء واالسترداد في النموذج األولي ؛ ل الموثوقية ركز على المتطلبات الوظيفية بدالً من المتطلبات غير الوظيفية مث واألمان Chapter 2 Software Processes 70 Throw-away prototypes  Prototypes should be discarded after development as they are not a good basis for a production system: ▪ It may be impossible to tune the system to meet non-functional requirements; ▪ Prototypes are normally undocumented; ▪ The prototype structure is usually degraded through rapid change; ▪ The prototype probably will not meet normal organisational quality standards. 71Chapter 2 Software Processes النماذج األولية للتخلص منها  ًا لنظام يجب التخلص من النماذج األولية بعد التطوير ألنها ليست أساًسا جيد :اإلنتاج ة ؛قد يكون من المستحيل ضبط النظام لتلبية المتطلبات غير الوظيفي النماذج األولية عادة ما تكون غير موثقة ؛ عادة ما يتدهور هيكل النموذج األولي من خالل التغيير السريع ؛ ربما لن يلبي النموذج األولي معايير الجودة التنظيمية العادية. Chapter 2 Software Processes 72 Incremental development and delivery  Incremental development ▪ Develop the system in increments and evaluate each increment before proceeding to the development of the next increment; ▪ Normal approach used in agile methods; ▪ Evaluation done by user/customer proxy.  Incremental delivery ▪ Deploy an increment for use by end-users; ▪ More realistic evaluation about practical use of software; ▪ Difficult to implement for replacement systems as increments have less functionality than the system being replaced. Chapter 2 Software Processes 75 التطوير والتسليم التدريجي التنمية المتزايدة ادة التالية ؛تطوير النظام بزيادات وتقييم كل زيادة قبل الشروع في تطوير الزي النهج العادي المستخدم في األساليب الرشيقة ؛  العميل/ تم التقييم بواسطة وكيل المستخدم. تسليم تزايدي نشر زيادة لالستخدام من قبل المستخدمين النهائيين ؛ تقييم أكثر واقعية حول االستخدام العملي للبرمجيات ؛ ظام الذي من الصعب التنفيذ ألنظمة االستبدال ألن الزيادات لها وظائف أقل من الن .يتم استبداله Chapter 2 Software Processes 76 Incremental delivery Define outline requanrements Validate increment Assign requirements. igr Develap system to increments increment C wie C wie Chapter 2 Software Processes 77 مزايا التسليم اإلضافية قًايمكن تسليم قيمة العميل مع كل زيادة حتى تتوفر وظائف النظام مسب. ادات تعمل الزيادات المبكرة كنموذج أولي للمساعدة في تحديد متطلبات الزي .الالحقة انخفاض مخاطر فشل المشروع بشكل عام. تميل خدمات النظام ذات األولوية القصوى إلى تلقي معظم االختبارات. Chapter 2 Software Processes 80 Incremental delivery problems  Most systems require a set of basic facilities that are used by different parts of the system. ▪ As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.  The essence of iterative processes is that the specification is developed in conjunction with the software. ▪ However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract. 81Chapter 2 Software Processes مشاكل التسليم المتزايدة  تتطلب معظم األنظمة مجموعة من المرافق األساسية التي تستخدمها أجزاء .مختلفة من النظام زيادة ، فقد يكون من نظًرا ألن المتطلبات لم يتم تحديدها بالتفصيل حتى يتم تنفيذ ال .الصعب تحديد المرافق المشتركة التي تحتاجها جميع الزيادات رنامججوهر العمليات التكرارية هو أن المواصفات تم تطويرها بالتزامن مع الب. ن ومع ذلك ، يتعارض هذا مع نموذج الشراء للعديد من المؤسسات ، حيث تكو .مواصفات النظام الكاملة جزًءا من عقد تطوير النظام Chapter 2 Software Processes 82 Boehm’s spiral model of the software process 85Chapter 2 Software Processes Chapter 2 Software Processes 86 Spiral model sectors  Objective setting ▪ Specific objectives for the phase are identified.  Risk assessment and reduction ▪ Risks are assessed and activities put in place to reduce the key risks.  Development and validation ▪ A development model for the system is chosen which can be any of the generic models.  Planning ▪ The project is reviewed and the next phase of the spiral is planned. 87Chapter 2 Software Processes استخدام النموذج الحلزوني  ار في كان للنموذج الحلزوني تأثير كبير في مساعدة الناس على التفكير في التكر .عمليات البرمجيات وإدخال نهج يحركه المخاطر في التنمية  في الممارسة العملية ، ومع ذلك ، نادًرا ما يتم استخدام النموذج كما هو منشور .لتطوير البرامج العملية Chapter 2 Software Processes 90 The Rational Unified Process  A modern generic process derived from the work on the UML and associated process.  Brings together aspects of the 3 generic process models discussed previously.  Normally described from 3 perspectives ▪ A dynamic perspective that shows phases over time; ▪ A static perspective that shows process activities; ▪ A practive perspective that suggests good practice. 91Chapter 2 Software Processes العملية العقالنية الموحدة  عملية عامة حديثة مشتقة من العمل علىUML والعملية المرتبطة بها. قًايجمع بين جوانب نماذج العمليات العامة الثالثة التي تمت مناقشتها ساب.  وجهات نظر3يوصف عادة من منظور ديناميكي يظهر مراحل بمرور الوقت ؛ منظور ثابت يوضح أنشطة العملية ؛ منظور عملي يقترح ممارسة جيدة. Chapter 2 Software Processes 92 RUP phases  Inception ▪ Establish the business case for the system.  Elaboration ▪ Develop an understanding of the problem domain and the system architecture.  Construction ▪ System design, programming and testing.  Transition ▪ Deploy the system in its operating environment. 95Chapter 2 Software Processes RUPمراحل بداية إنشاء دراسة الجدوى للنظام. تفصيل تطوير فهم لمجال المشكلة وبنية النظام. بناء تصميم النظام وبرمجته واختباره. انتقال نشر النظام في بيئة التشغيل الخاصة به. Chapter 2 Software Processes 96 RUP iteration  In-phase iteration ▪ Each phase is iterative with results developed incrementally.  Cross-phase iteration ▪ As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally. Chapter 2 Software Processes 97