هندسة.pdf

Software Engineering Agile Software Development

2

OUTLINE   

 

Agile Software Development Principles of Agile Software Extreme Programming – XP SCRUM XP and Scrum

3

Agile Software Development • Agile is a method of developing software solutions, including websites, web applications, and mobile applications, that focuses on delivering high-quality working software frequently and consistently, while minimizing project overhead and increasing business value. • ‫ بما فً ذلك مواقع الوٌب وتطبٌقات الوٌب‬، ‫هً طرٌقة لتطوٌر حلول البرامج‬ ‫ التً تركز على تقدٌم برامج تشغٌل عالٌة الجودة بشكل‬، ‫وتطبٌقات المحمول‬ ‫ مع تقلٌل نفقات المشروع وزٌادة قٌمة العمل‬، ‫متغٌر أو ثابت‬ • Agile software development focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they're ready. • ‫تركز على الحفاظ على الكود بشكل بسٌط والفحص فً كثٌر من األحٌان وتقدٌم‬ .‫وحدات وظٌفٌة للتطبٌق بمجرد أن تكون جاهزة‬

Agile Software Development • Agile software development is a conceptual framework for software engineering that supports development iterations throughout the life-cycle of the project. • ‫هو مفهوم هندسة البرمجٌات الذي ٌدعم التطوٌر المتكرر خالل دورة حٌاة تطوٌر المشروع‬ • ‫ماهو هو التكرار؟‬ • Software developed during one unit of time is referred to as an iteration (or sprint) , which may last from one to four weeks. ، )‫ٌشار إلى البرامج التً تم تطوٌرها خالل وحدة زمنٌة واحدة على أنها تكرار (أو سرعة مرحلة‬ .‫والتً قد تستمر من أسبوع إلى أربعة أسابٌع‬

• Agile methods also emphasize working software as the primary measure of progress. • ‫األجاٌل تؤكد على عمل النظام كأساس لقٌاس سٌر العملٌات‬

5

Agile Software Development •

It is against the traditional waterfall approach. In the waterfall approach, there will be a straight path to software development. The needs remain first, later design, implementation, verification, and maintenance. • ‫ العملٌات تكون بمسار مستقٌم لتطوٌر‬، ‫ فً نهج الشالل‬.‫عكس منهج الشالل التقلٌدي‬ ‫ التصمٌم والتنفٌذ والتحقق والصٌانة لحقا ا‬، ‫ وجمع المتطلبات أولا‬.‫البرمجٌات‬

• The agile software development team believes that a running software model should be progressed in a moving series. It includes needs gathering, the design of the system, execution, confirmation and maintenance that can happen once. • ‫ وٌشمل ذلك‬.‫ٌعتقد فرٌق التطوٌر باألجاٌل أن التطوٌر ٌجب أن ٌتقدم فً سلسلة متحركة‬ ‫تجمٌع المتطلبات وتصمٌم النظام والتنفٌذ والتأكٌد والصٌانة التً ٌمكن أن تحدث مرة‬ .‫واحدة‬

6

Agile Software Development

7

Agile Manifesto “Our

• • • • • • • •

highest priority is to satisfy the customer through early and continuous delivery of valuable software“. ‫إن أولوٌتنا القصوى هً إرضاء العمٌل من خالل تسلٌم برامج قٌمة وبشكل‬ ‫مستمر فً وقت قصٌر‬ Agile Values Individuals and interactions over processes and tools ‫األفراد والتفاعالت مقابل العملٌات واألدوات‬ Working software over comprehensive documentation ‫عمل النظام مقابل الوثائق الشاملة‬ Customer collaboration over contract negotiation ‫تعاون العمالء مقابل التفاوض على العقود‬ Responding to change over following a plan ‫استجابة للتغٌرات مقابل اتباع خطة‬

8

9

OUTLINE   

  

Agile Software Development Principles of Agile Software An Agile Process Extreme Programming – XP SCRUM XP and Scrum

10

Principles of Agile Software 1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ‫إن أولوٌتنا القصوى هً إرضاء العمٌل من خالل تسلٌم برامج قٌمة وبشكل‬ ‫مستمر فً وقت قصٌر‬ 2) Welcome changing requirements, even late in development. Agile processes control change for the customer's competitive advantage. ‫ تتحكم فً عملٌات‬.‫ حتى وقت متأخر فً التطوٌر‬،‫ترحب بالمتطلبات المتغٌرة‬ ‫التغٌٌر من أجل المٌزة التنافسٌة للعمٌل‬

11

Principles of Agile Software 3) Build projects around motivated individuals. ‫بناء المشارٌع ضمن تشجٌع األفراد‬ ‫بتوفٌر لهم البٌئة المناسبة والدعم والثقة لتمام العمل‬ Give them the environment and support they need, and trust them to get the job done. All other factors, process, environment, management, etc., are considered to be second order effects, and are subject to change if they are having an adverse effect upon the people. Example: if the office environment is an obstacle to the team, change the office environment. ‫ اذا كان بٌئة العمل غٌر مناسبة او تعٌق العمل ٌجب تغٌرها فورا‬:‫مثال‬

12

Principles of Agile Software 4) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale . ‫ خالل مدة أسبوعٌن إلى‬،‫تسلٌم البرامج التً تعمل بشكل مستمر ومتكرر‬ ‫ مع تفضٌل لفترة زمنٌة أقصر‬، ‫شهرٌن‬ 5) Business people and developers must work together daily throughout the project. ‫ٌجب على رجال األعمال والمطورٌن العمل معا ٌومٌا فً جمٌع مراحل‬ .‫المشروع‬

13

Principles of Agile Software 6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Face-to-face communication is preferred over documentation. .‫ٌُفضل التواصل وج اها أكتر من التواصل خالل مستندات‬ 7) Working software is the primary measure of progress. ‫البرنامج الذي ٌعمل هو مقٌاس أساسً لقٌاس عملٌات‬ ‫التطوٌر‬

14

Principles of Agile Software 8) Continuous attention to technical excellence and good design enhances agility. .‫الهتمام المستمر بالتمٌز الفنً والتصمٌم الجٌد ٌعزز من سرعة التطوٌر‬ ▫ High quality is the key to high speed. ▫ The way to go fast is to keep the software as clean and robust as possible. ▫ Thus, all agile team-members are committed to producing only the highest quality code they can.

15

Principles of Agile Software 9) Simplicity--the art of maximizing the amount of work not done--is essential. ‫البساطة‬ ▫ Agile teams take the simplest path that is consistent with their goals. ▫ ‫فرٌق العمل ٌتخد ابسط الطرق لتحقٌق الهدف‬ ▫ They don’t anticipate tomorrow’s problems and try to defend against them today. ▫ .‫ل ٌتوقعون مشكالت الغد وٌحاولون الدفاع عنها الٌوم‬

16

Principles of Agile Software 10) The best architectures, requirements, and designs emerge from self-organizing teams. – Responsibilities are not handed to individual team members from the outside. – Responsibilities are communicated to the team as a whole, and the team determines the best way to fulfill them.

‫أفضل بناء وجمع متطلبات وتصمٌم ٌنتج من فرٌق ٌعمل ضمن المؤسسة‬ ‫نفسها‬

17

An Agile Process Some Agile Methods • Adaptive Software Development (ASD) • Feature Driven Development (FDD) • Crystal Clear • Dynamic Software Development Method (DSDM) • Rapid Application Development (RAD) • Scrum • Extreme Programming (XP)

18

An Agile Process

19

OUTLINE   

 

Agile Software Development Principles of Agile Software Extreme Programming – XP SCRUM XP and Scrum

20

Extreme Programming - XP • For small-to-medium-sized teams developing software with vague or rapidly changing requirements • ‫مناسبة للفرق الصغٌرة إلى المتوسطة عدد المطورٌن الذٌن ٌقومون بتطوٌر‬ ‫برامج ذات متطلبات غامضة أو سرٌعة التغٌر‬ • Coding is the key activity throughout a software project • ‫كتابة الكود هو النشاط الرئٌسً خالل مشروع البرمجة‬ • Communication among teammates is done with code • ‫التواصل بٌن أعضاء الفرٌق ٌتم عن طرٌق الكود‬ • Life cycle and behavior of complex objects defined in test cases – again in code • ‫ مرة أخرى من‬- ‫دورة الحٌاة وسلوك األشٌاء المعقدة تعرف فً حالت الختبار‬ ‫خالل الكود‬

21

Extreme Programming (XP) • An extreme programming project starts with user stories which are short (a few sentences) descriptions of what scenarios the customers and users would like the system to support. • ً‫ٌبدأ مشروع البرمجة المطور خالل الكسترٌم بقصص المستخدمٌن الت‬ ‫هً قصٌرة (بضع جمل) أوصاف للسٌنارٌوهات التً ٌرغب العمالء‬ .‫والمستخدمون فً دعم النظام‬ • A user story is a short description of what the business or customer wants the software to do, written by the customer in the customer terminology without techno-syntax • ‫قصة المستخدم هً وصف قصٌر لما ٌرٌده صاحب العمل أو العمٌل أن‬ ‫ ٌكتبه العمٌل فً مصطلحات عامة بدون نصوص تقنٌة‬، ‫ٌقوم به البرنامج‬

22

The XP lifecycle

23

Extreme Programming (XP) Example of user story

As a consumer, I want shopping cart functionality to easily purchase items online. As an manager, I want to generate a report to understand which departments need to improve their productivity. ‫ ارٌد اجراء دفع الكترونً لتسهٌل عملٌة شراء على النترنت‬،‫أنا كمستخدم‬ ‫ ارٌد اصدار تقرٌر عن األقسام لتحدٌد اٌهم ٌحتاج لتطوٌر ودعم‬،‫أنا كمدٌر‬

Extreme Programming (XP) Twelve XP Practices • The Planning Game • Small Releases ‫تسلٌم جزئٌات‬ ‫صغٌرة‬ • Metaphor‫تشابه مستعار‬ • Simple Design‫تصمٌم بسٌط‬ • Test-driven development ‫الفحص ٌقود التطوٌر‬ • Refactoring‫إعادة ضبط الكود‬

24

• Pair Programming ‫برمجة‬ ‫مزدوجة‬ • Collective Ownership ‫الملكٌة الجماعٌة‬ • Continuous Integration ‫تكامل متواصل لجزئٌات النظام‬ • 40-Hours a Week 40 ‫ساعة عمل اسبوعٌا‬ • On-Site Customer ‫العمٌل‬ ‫ٌدخل الى الكود فً أي وقت‬ • Coding Standards ‫الكود‬ ‫ضمن معاٌر‬

25

The planning game The planning game • Quickly determine the scope of the next release, combining business priorities and technical estimates.

• Business decisions (customer)

▫ Scope: which “stories” should be developed ▫ Priority of stories (features) ▫ Release dates

• Technical decisions (developers) ▫ ▫ ▫ ▫

Time estimates for features/stories Elaborate consequences of business decisions Team organization and process Scheduling

26

Small Release Small Release • Frequent and small releases are encouraged, and for a release, iterations are employed. • Start with the smallest useful feature set • Release early and often, adding a few features each time

27

Metaphor Metaphor ▫

Programmers have a simple shared story that explains the system • Use metaphors to describe how the system should work. • The system metaphor is a story that everyone customers, programmers, and managers - can tell about how the system work. • It helps everyone understand the basic elements

28

Metaphor • The shopping cart in e-commerce mimics how a supermarket works, collecting products and quantities at different times and leaving checkout for the end for efficiency. • Desktop:

29

Metaphor XP Metaphor Example-Payroll system is like an assembly line: • A large XP project was a payroll system for Chrysler (Car Company). • The metaphor for this project was that the payroll system was like an assembly line where hour parts were converted to dollar parts, all parts were assembled and a paycheck was produced .

30

Simple Design Simple design • Do the simplest thing that could possibly work • Passes all the tests • No duplicate code • Fewest possible classes and methods

Test-driven Development Test-driven development

• Test first: before adding a feature, write a test for it! • When the complete test suite passes 100%, the feature is accepted • Tests come in two basic flavors… • Unit Tests automate testing of functionality as developers write it ▫ Each unit test typically tests only a single class, or a small cluster of classes !

• Acceptance Tests (or Functional Tests) are specified by the customer

31

32

Refactoring Refactoring • The restructuring of changing the behavior. ▫

software

without

Restructure the system continuously to improve code and eliminate duplication

• Continuously improve quality of the code

Refactoring • A method returns a special code to indicate an error is better accomplished with an Exception. int withdraw(int amount) { if (amount > balance) return -1; else { balance -= amount; return 0; } }

void withdraw(int amount) throws BalanceException { if (amount > balance) { throw new BalanceException(); } balance -= amount; }

Pair programming Pair programming • Two programmers work together at one machine • Driver enters code, while navigator critiques it • Periodically switch roles Research results: Pair programming increases productivity Higher quality code (15% fewer defects) in about half the time (58%)

34

35

Collective code ownership Collective code ownership • No single person "owns" a module • Any developer can work on any part of the code base at any time

36

Continuous Integration Continuous integration • New code is integrated with the current system after no more than a few hours. • All changes are integrated into the code base at least daily • Tests have to run 100% both before and after integration

37

40 hours Work no more than 40 hours per week as a rule. • Never work overtime two weeks in a row. •Work only as many hours as you can be productive and only as many hours as you can sustain.

38

On-site customer On-site customer • A customer is accessible to the programming team at all times. • At least one customer is always present.

39

Coding Standards Coding Standards • Everyone codes to the same standards • Coding standards keep the code consistent and easy for the entire team to read and refactor.

Extreme Programming (XP) • Why Extreme ?

• If code reviews are good, we’ll review code all the time (pair programming). • If testing is good, everybody will test all the time (unit testing), even the customers (Acceptance testing) • If design is good, we’ll make it part of everybody’s daily business (refactoring) • If simplicity is good, we’ll always leave the system with the simplest design that supports current functionality (the simplest thing that could possibly work).

Extreme Programming (XP) • If integration testing is important, we’ll integrate and test several times a day (continuous integration). • If short iterations are good, we’ll make the iterations really, really short.

42

Extreme Programming (XP) ADVANTAGES Of XP

• XP is geared toward a single project, developed and maintained by a single team. • Customer focus increase the chance that the software produced will actually meet the needs of the users • The focus on small, incremental release decreases the risk on your project: • Continuous testing and integration helps to increase the quality of your work

43

Extreme Programming (XP) DISADVANTAGES of XP

• XP is particularly vulnerable to "bad apple" developers who:

▫ don't work well with others ▫ who think they know it all, and/or ▫ who are not willing to share their "superior” code

• XP will not work in an environment where a customer or manager insists on a complete specification or design before they begin programming. • XP will not work in an environment where programmers are separated geographically. • XP has not been proven to work with systems that have scalability and complex issues

44

OUTLINE   

 

Agile Software Development 12 Principles of Agile Software Extreme Programming – XP SCRUM XP and Scrum

SCRUM • Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative and incremental practices.

SCRUM • Scrum is a process that allows us to focus on delivering the highest business value in the shortest time.

• It allows us to rapidly and repeatedly check actual working software (every two weeks to one month).

Characteristics of scum • Self-organizing teams • Product progresses in a series of month-long “sprints” • Requirements are captured as items in a list of “product backlog” • No specific engineering practices prescribed

Components of Scrum • Roles : Product Owner, ScrumMaster, Team. • Artifacts : Product Backlog, Sprint Backlog, and Burndown Chart. • The Process: Sprint Planning, Sprint Review, Sprint presentation and Daily Scrum Meeting

Roles: Product Owner 

Typically a Product Manager, Marketing, Internal Customer, etc.

• Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results.

Roles: The Scrum Master • Represents management to the project • Responsible for performing Scrum values and practices • Removes obstacles • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Protect the team from external interferences

Roles: Scrum Team • Typically 5-10 people • Cross-functional

▫ QA, Programmers, UI Designers, etc.

• Members should be full-time ▫ May be exceptions (e.g., System Admin, etc.)

• Teams are self-organizing ▫ Ideally, no titles but rarely a possibility

• Membership can change only between sprints

52

Scrum Workflow

Artifacts: Product Backlog • A list of all desired work on the project • List is prioritized by the Product Owner ▫ Typically a Product Manager, Marketing, Internal Customer, etc.

Sample Product Backlog

Artifacts: Sprint Backlog • A subset of Product Backlog Items, which define the work for a Sprint • Is created ONLY by Team members • Each Item has it’s own status • Should be updated every day

Artifacts: Sprint Backlog • No more than 300 tasks in the list • If a task requires more than 16 hours, it should be broken down • Team can add or subtract items from the list. Product Owner is not allowed to do it

Sample Sprint Backlog

Artifacts :Sprint 

A period of approximately 30 days in which an agreed amount of work will be performed to create a deliverable.

• SCRUM’s goal is to deliver as much quality software as possible within a series (three to eight) of Sprints ▫ Analogous to XP iterations

• A sprint is the basic unit of development in Scrum • Product is designed, coded, and tested during the sprint • NO outside influence can interfere with the Scrum team during the Sprint

59

Process: Sprint Planning Meeting • A collaborative meeting in the beginning of each Sprint between the Product Owner, the Scrum Master and the Team • Takes 8 hours and consists of 2 parts (“before lunch and after lunch”)

60

Process: Sprint Planning Team capacity

Sprint planning meeting Sprint prioritization

Product backlog

Business conditions

•

•

• •

Technology

Sprint goal

Sprint planning

• Current product

Analyze and evaluate product backlog Select sprint goal

Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours

Sprint backlog

Parts of Sprint Planning Meeting • 1st Part: ▫ Creating Product Backlog ▫ Determining the Sprint Goal. ▫ Participants: Product Owner, Scrum Master, Scrum Team

62

Parts of Sprint Planning Meeting • 2nd Part: ▫ Participants: Scrum Master, Scrum Team ▫ Creating Sprint Backlog

63

Process: : Sprint Goals • The sprint goal summarizes the desired outcome of the sprint. • It should move the Scrum team a step closer toward the launch of a successful product. • Sprint goals are the result of a negotiation between the product owner and the development team. • A Sprint goal might be along the lines of: "This Sprint we will allow users to log-in to the site, retrieve a forgotten password, and manage their own profile".

64

Process: Sprint Goals • A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. • The following are example sprint goals on an eCommerce application: “ - Implement basic shopping cart functionality including add, remove, and update quantities. - Develop the checkout process: pay for an order, pick shipping, order gift wrapping, etc.”

65

Process: Sprint Review Meeting • Is held at the end of each Sprint • Business functionality which was created during the Sprint is demonstrated to the Product Owner • Informal, should not divert Team members of doing their work

Process: Sprint Review Meeting • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal ▫ 2-hour prep time rule

• Participants ▫ ▫ ▫ ▫

Customers Management Product Owner Other engineers

Process: Daily Scrum • Is a short (15 minutes long) meeting, which is held every day before the Team starts working • Participants: Scrum Master (which is the chairman), Scrum Team only.

Process: The Daily Scrum • Every Team member should answer on following questions: 1. 2. 3. 4.

What have you accomplished since yesterday? Are your Sprint Backlog estimates accurate? What are you working on today? Is there anything blocking you?

How does SCRUM work? • “SCRUM Meetings” drive the completion of the allocated activities • Each sprint operates on a number of work items called “Backlog” • No more items are externally added into the Backlog within a Sprint, where as derived work items can be added.

70

How does SCRUM work? • During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is a prioritized list of requirements. • Which backlog items go into the sprint (the sprint goals) is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority).

71

How does SCRUM work? • The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog • The sprint backlog is property of the development team, i.e. during a sprint, no one is allowed to edit the sprint backlog except for the development team.

72

OUTLINE   

 

Agile Software Development 12 Principles of Agile Software Extreme Programming – XP SCRUM XP and Scrum

Advanced Software Engineering Introduction

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

Software • Software – As IEEE definition Software is:

1) 2) 3) 4)

Computer programs (code) Procedures Documentations Data affecting the operation of a computer system.

Software • All four components are needed for software development process and the coming years of maintenance services for the following reasons: 1) Computer programs (the “code”) are needed because, obviously, they activate the computer to perform the required applications.

Software 2) Procedures are required, to define the order and schedule in which the programs are performed, the method employed, and the person responsible for performing the activities that are necessary for applying the software.

Software 3) Various types of documentation are needed for developers, users and maintenance personnel. The development documentation (the requirements report, design reports, program descriptions, etc.). • The user’s documentation (the “user’s manual”, etc.) provides a description of the available applications and the appropriate method for their use.

Software 4) Data including parameters, codes and name lists that adapt the software to the needs of the specific user are necessary for operating the software. • Another type of essential data is the standard test data, • Also, there are types of should include data such as web-based systems, expert systems and data mining systems.

Efforts of software Engineering Activates

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

Software Engineering Software Engineering: • The process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints

Software Engineering ►Systematic development and evolution

▫ An engineering process involves applying well understood techniques in a organized way.

Software Engineering ►Large, high quality software systems

▫ Software engineering techniques are needed because large systems cannot be completely understood by one person ▫ Teamwork and co-ordination are required ▫ The end-product that is produced must be of sufficient quality

Software Engineering ►Cost, time and other constraints

▫ Finite resources ▫ The benefit must outweigh the cost ▫ Others are competing to do the job cheaper and faster ▫ Inaccurate estimates of cost and time have caused many project failures

Software Engineering Why is software engineering needed? • To predict time, effort, and cost • To improve software quality • To improve maintainability • To meet increasing demands • To lower software costs • To successfully build large, complex software systems • To facilitate group effort in developing software

Elements of Software Engineering Elements of Methodology •

Elements of Software Engineering • Roles: Who you employ, what you employ them for, what skills they are supposed to have. • Such as Project Manager, Designer, Developer, Tester , etc

Elements of Software Engineering • Skills: The skills needed for the roles. The "personal proficiency" of a person in a role is a product of his training and talent. • Programmers skills in object-oriented, Java programming and unit-testing skills. • User interface designers skills in conduct usability examinations and do paper-based prototyping. • Managers skill in interviewing, motivating, hiring, and critical-path task-management skills.

Elements of Software Engineering • Personality character expected of the person. • A project manager should be good with people, a user interface designer should have natural visual talents and some understanding for user behavior, an object-oriented program designer should have good abstraction faculties, and a adviser should be good at explaining things.

19

Elements of Software Engineering • Teams: The roles that work together under various circumstances. • There may be only one team on a small project. On a large project, there are likely to be multiple, overlapping teams, some aimed at connecting specific technologies and some aimed at steering the project or the system's architecture.

20

Elements of Software Engineering • Activities: How the people spend their days. Planning, programming, testing, and meeting are sample activities.

21

Elements of Software Engineering • Techniques: The specific procedures people use to accomplish tasks. Some apply to a single person (writing a use case, managing by walking around, designing a class or test case), while others are aimed at groups of people (project demonstration, group planning sessions).

Elements of Software Engineering • Tools: Tools used by techniques and standards such as MS Project, NetBeans, Junit …etc

23

Elements of Software Engineering • Process: How activities fit together over time, often with pre- and post conditions for the activities (for example, a design review is held two days after the material is sent out to participants and produces a list of recommendations for improvement). • Process-intensive methodologies focus on the flow of work among the team members.

24

Elements of Software Engineering • Milestones: Events marking progress or completion. Some milestones are simply assertions that a task has been performed, and some involve the publication of documents or code. • A milestone has two key characteristics: It occurs in an instant of time, and it is either fully met or not met (it is not partially met). A document is either published or not published, the code is delivered or not delivered, the meeting was held or not held.

25

Elements of Software Engineering • Work products: What someone constructs. A work product may be disposable, as with design cards, or it may be relatively permanent, as the usage manual or source code.

26

Elements of Software Engineering • Standards: The conventions the team adopts for particular tools, work products, and decision policies. • A coding standard might declare this: "Every function has the following header comment. . ." • A language standard might be this: "We'll be using fully portable Java."

27

Elements of Methodology • Quality: Quality may refer to the activities or the work products.

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

The essential characteristics of Software Engineering Main Characteristics of Software Engineering: 1) Software Engineering concerns the construction of large applications ‫هندسة البرمجيات تختص لألنظمة‬ ‫الكبيرة‬ Small applications generally refers to application written by one person in relatively short period. Large applications refer to multi-person job that span for months. Tools, techniques and methods needed for small applications are different than for large applications

The essential characteristics of Software Engineering 2 ) The Central Theme is Mastering

Complexity ‫السيطرة على التعقيدات‬

One is forced to split the problem into parts such that each individual part can be taken hold of, while the communication between parts remain simple. The total complexity does not decreased in this way ,but it becomes manageable.

The essential characteristics of Software Engineering 3) Regular Cooperation between people in an integral part of large applications ‫التعاون المنتظم بين أعضاء الفريق جزء ال يتجزأ من التطبيقات الكبيرة‬ Since the problem are large , many people have to work concurrently at solving these problems. There must be a clear arrangements for the distribution of work, methods of communication, responsibilities, and so on. Arrangements alone is not sufficient, one has to stick to those arrangements. In order to enforce them , standards or procedures supported by tools maybe employed.

The essential characteristics of Software Engineering 4) Software evolves: ‫أنظمة متغيرة‬ Software models part of reality. This reality evolves (changes). For example, banks regulations always changes. So the software should be evolves in order to not become obsolete. The evolutions should be bear in mind during development.

The essential characteristics of Software Engineering 5) The efficiency with which software is developed is of crucial importance ‫الكفاءة التي يتم تطوير البرمجيات لها أهمية حاسمة‬ Total cost and the development time of software project is high. This is also for maintenance of software. Important themes within the field of software Engineering concern better and more efficient methods and tools for development and maintenance of software

The essential characteristics of Software Engineering 6) The software has effectively support its users: ‫البرنامج يدعم بشكل فعال مستخدميها‬

Software is developed to support users at work. The functionality offered should fit users’ tasks. Users that not satisfied with the system will try to avoid it Effective user support means that must carefully study users at work in order to determine the proper functional requirements, and that we have to address usability and other quality aspects as well, such as reliability , responsiveness , user-friendliness. It also means that software development entails more than delivering software . User manuals and tanning material also important.

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

36

Process Life Cycle ‫دورة حياة العمليات‬ • Software products go through several stages as they mature from initial concept to finished product • ‫تمرعملية انتاج البرامج بعدة مراحل بدأ من الفكرة األولية إلى المنتج‬ ‫النهائي‬ • The sequence of stages is called a process model or life cycle or software methodology. • ‫تسمى تسلسل المراحل نموذج العملية أو دورة الحياة أو منهجية‬ .‫البرمجيات‬ • A process is a sequence of steps performed for a given purpose • ‫العمليات هي سلسلة من الخطوات التي يتم تنفيذها لغرض معين‬

37

Process Life Cycle

Definition: A software model also (Life-cycle model, process model, and software methodology) is a description of the sequence of activities carried out in an Software Engineering project, and the relative order of these activities. ‫وصف لتسلسل النشاطات المنفذة في مشروع هندسة البرمجيات وتتعلق‬ ‫بترتيب هذه األنشطة‬

38

Generic software process models ‫أمثلة‬ Examples of software process models are: ▫ Build and Fix ▫ Waterfall ▫ V- shaped ▫ Prototyping ▫ The Spiral ▫ Incremental ▫ Component-based ▫ Agile (next chapter)

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

40

Build and Fix • In this most simple model of software development, the product is constructed with minimal requirements, and generally no specifications nor any attempt at design, and testing is most often neglected. This is a representation of what is happening in many (old) software development projects. • ‫ يتم بناء البرنامج بالحد‬، ‫هذا النموذج األكثر بساطة في تطوير البرمجيات‬ ‫ وعموما ال توجد مواصفات أو أي محاولة في‬، ‫األدنى من المتطلبات‬ ‫ هذا هو تمثيل لما يحدث‬.‫ وغالبا ما يتم إهمال فحص البرنامج‬، ‫التصميم‬ .)‫في العديد من مشاريع تطوير البرمجيات (القديمة‬

41

Build and Fix

42

Build and Fix • This model starts with an informal general product idea and just develops code until a product is ”ready” (or money or time runs out). Work is in random order. • ‫يبدأ هذا النموذج بفكرة منتج عامة غير رسمية ويطور عن طريق‬ ً .)‫جاهزا" (أو ينفد المال أو الوقت‬ " ‫كتابة الكود حتى يصبح برنامج‬ .‫العمل بترتيب عشوائي‬

43

Build and Fix Advantages ‫المزايا‬ • Requires less experience to execute or manage other than the ability to program. • Suitable for smaller software. • Requires less project planning. • .‫يتطلب خبرة قليلة للتنفيذ أو االدارة‬ • .‫مناسبة للبرامج الصغيرة‬ • .‫يتطلب تخطيط أقل للمشروع‬

44

Build and Fix Disadvantages ‫العيوب‬ • No real means is available of assessing the progress, quality, and risks. • Cost of using this process model is high as it requires rework until user's requirements are accomplished. • Informal design of the software as it involves unplanned procedure. • Maintenance of these models is problematic. • .‫ال توجد وسائل حقيقية متاحة لتقييم التقدم والجودة والمخاطر‬ • ‫تكلفة استخدام نموذج العملية هذا عالية حيث تتطلب إعادة العمل حتى يتم إنجاز‬ .‫متطلبات المستخدم‬ • .‫تصميم غير رسمي للبرنامج ألنه يشتمل على إجراء غير مخطط له‬ • .‫صيانة هذه النماذج مشكلة‬

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

46

Waterfall Model • The waterfall model is the classic lifecycle model – it is widely known, understood and commonly used. In some respect, waterfall is the ”common sense” approach. ‫ وهو معروف على نطاق‬- ‫نموذج الشالل هو نموذج دورة الحياة الكالسيكية‬ .‫واسع ومفهوم ويشيع استخدامه‬ "‫ الشالل هو نهج "الحس السليم‬، ‫في بعض الجوانب‬ • Document-oriented ‫موثق بنظام وترتيب‬ • The output of one phase constitutes the input to next (Liner). • ‫الناتج من مرحلة واحدة يشكل مدخالت إلى المرحلة التالية‬

47

Waterfall Model

48

Waterfall Model Advantage • Easy to understand, easy to use • Provides structure to inexperienced staff • Milestones are well understood • Good for management control (plan, staff, track) • Works well when quality is more important than cost or schedule ‫ سهل االستخدام‬، ‫• سهل الفهم‬ ‫• يوفر هيكل للموظفين غير متمرسين‬ ً ‫• المعالم الرئيسية مفهومة‬ ‫جيدا‬ )‫ المسار‬، ‫ فريق العمل‬، ‫• جيد للتحكم في اإلدارة (الخطة‬ ‫• يعمل بشكل جيد عندما تكون الجودة أكثر أهمية من التكلفة أو الجدول‬ ‫الزمني‬

49

Waterfall Model Disadvantages • All requirements must be known upfront • Deliverables created for each phase are considered frozen – inhibits flexibility • Does not reflect problem-solving nature of software development – iterations of phases • Little opportunity for customer to preview the system (until it may be too late). • Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. • ‫يجب أن تكون جميع المتطلبات معروفة مسبقًا‬ • ‫ تمنع المرونة‬- ‫تعتبر النواتج التي تم إنشاؤها لكل مرحلة مجمدة‬ • ‫ تكرارات المراحل‬- ‫ال يعكس طبيعة حل مشكلة تطوير البرمجيات‬ • .)‫فرصة ضئيلة للعمالء لمعاينة النظام (قد يكون قد فات األوان‬ • ‫ من الصعب جدا ً العودة وتغيير شيء لم‬، ‫بمجرد أن يكون التطبيق في مرحلة االختبار‬ .‫يكن مدروسا في مرحلة جمع المتطلبات‬

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

51

V-Shaped Model • A variant of the Waterfall that emphasizes the verification and validation of the product. • ‫بديل للشالل الذي يؤكد على التحقق من المنتج والتحقق من صحته‬ • It solve the problem of waterfall that “Once an application is in the testing stage, it is very difficult to go back and change something that was not wellthought out in the concept stage.” • ، ‫إنها تحل مشكلة الشالل بأنه "بمجرد أن يكون التطبيق في مرحلة االختبار‬ ‫من الصعب جداً العودة وتغيير شيء لم يكن مدرو ًسا بشكل جيد في مرحلة‬ ".‫جمع المتطلبات‬ • So, Testing of the product is planned in parallel with a corresponding phase of development • ‫ يتم التخطيط الختبار المنتج بالتوازي مع مرحلة التطوير المقابلة‬، ‫لذلك‬

52

V-Shaped Model

53

V-Shaped Model Advantages • Stress planning for verification and validation of the product in early stages of product development • Each deliverable must be testable • Project management can track progress by milestones • Easy to use • ‫تخطيط جيد للتحقق من المنتج في المراحل األولى من تطويره‬ • ‫يجب أن يكون كل منتج قابل لالختبار‬ • ‫يمكن إلدارة المشروع تتبع التقدم من خالل تحقيق االهداف‬ • ‫سهل االستخدام‬

54

V-Shaped Model Disadvantages • Does not easily handle concurrent events • Does not handle iterations • Does not easily handle dynamic changes in requirements • Does not contain risk analysis activities • ‫ال يعالج األحداث المتزامنة بسهولة‬ • ‫ال يعالج التكرارات‬ • ‫ال يتعامل بسهولة مع التغييرات الديناميكية في المتطلبات‬ • ‫ال يحتوي على أنشطة تحليل المخاطر‬

55

Evolutionary Process Models • Evolutionary models are iterative • ‫النماذج التطورية باعتماد التكرار‬ • They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software. • ‫وهي تتميز بطريقة تمكن مهندسي البرمجيات من تطوير إصدارات‬ .‫أكثر اكتماال للبرنامج‬ • Examples: ▫ Prototyping ▫ Incremental ▫ Spiral

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base

57

Prototyping Model Some strong limitations of waterfall model is: :‫بعض القيود القوية لنموذج الشالل‬ • It assumes that the requirements of a system can be frozen before the design begins. This is possible for systems designed to automate an existing manual system. But for new systems, determining the requirements is difficult as the user does not even know the requirements. Hence, having unchanging requirements is unrealistic for such projects. • ‫ هذا ممكن لألنظمة‬.‫يفرض أن متطلبات النظام قد تكون ثابتة قبل بدء التصميم‬ ‫ فإن تحديد‬، ‫ ولكن بالنسبة لألنظمة الجديدة‬.‫المصممة ألتمتة نظام يدوي موجود‬ ‫ فإن وجود‬،‫المتطلبات أمر صعب حيث أن المستخدم ال يعرف ما هي المتطلبات‬ ‫متطلبات غير متغيرة غير واقعي بالنسبة لمثل هذه المشاريع المبتكرة‬

58

Prototyping Model • The basic idea is that instead of freezing the requirements before any design or coding can proceed, a prototype is built to help understand the requirements. • ‫ يتم إنشاء نموذج أولي‬،‫الفكرة األساسية هي أنه بدلا من تجميد المتطلبات قبل الشروع في أي تصميم أو برمجة‬ ‫للمساعدة في فهم المتطلبات‬ • This prototype is developed based on the currently known requirements. • ‫يتم تطوير النموذج األولي بالعتماد على المتطلبات المعروفة‬ • Development of the prototype obviously undergoes design, coding, and testing, but each of these phases is not done very formally or thoroughly. By using this prototype • ‫ ولكن كل واحدة من هذه المراحل ل‬، ‫يتم تطوير النموذج األولي كالحقيقي ويخضع لتصميم الكود والختبار‬ .‫تتم بشكل رسمي أو شامل‬ • This results in more stable requirements that change less frequently. • .‫وينتج عن ذلك متطلبات أكثر استقراراا تتغير بتواتر أقل‬

59

Prototyping Model

60

Prototyping Model It could be a first step in waterfall methodology

61

Prototyping Model

• When customer or developer is not sure • :‫عندما يكون المستخدم والمطور غير متأكدين من التالي‬

▫ Of requirements (inputs, outputs) ‫المتطلبات‬ ▫ Of algorithms, efficiency, human-machine interaction ‫الخوارزميات والكفائة وطريقة تفاعل المستخدم‬

• A prototype built from currently known user needs • ‫يفضل استخدام هذا النموذج حسب ما يتوفر من معرفة الحتياجات‬ ‫المستخدم‬

62

Prototyping Model Advantages: • The software designer and implementer can obtain feedback from the users early in the project. • ‫يمكن لمصمم البرامج والمطور الحصول على مالحظات من المستخدمين في وقت مبكر من‬ ‫المشروع‬ • The client and the developer can compare if the software made matches the software specification, according to which the software program is built. • ‫ والتي‬، ‫يمكن للعميل والمطور مقارنة ما إذا كان البرنامج قد تم مطابقته مع مواصفات البرنامج‬ .‫تم بموجبها بناء البرنامج‬ • It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. • ‫كما أنه يتيح لمهندس البرمجيات نظرة في دقة تقديرات أولية للمشروع وما إذا كان من الممكن‬ ‫تحقيق المواعيد النهائية والمعالم المقترحة بنجاح‬

63

Prototyping Model Disadvantages

• Customer could believe the prototype as the working version. • .‫يمكن للعميل تصديق النموذج األولي كنسخة عاملة‬ • Developer also could make the implementation compromises where he could make the quick fixes to the prototype and make is as a working version. • ‫أيضا أن يجعل من التنازلت في التنفيذ حيث يمكنه إجراء‬ ‫للمطور‬ ‫يمكن‬ ‫ا‬ ّ ‫اإلصالحات السريعة للنموذج األولي وجعله كنسخة عاملة‬

• • • •

Effort in building a prototype may be wasted ‫قد يضيع الجهد في بناء نموذج أولي‬ Difficult to plan and manage ‫من الصعب التخطيط واإلدارة‬

OUTLINE • Software • Software Engineering • The essential characteristics of Software Engineering • Process Life Cycle ▫ ▫ ▫ ▫ ▫ ▫ ▫

Build and Fix Waterfall V- shaped Prototyping The Spiral Incremental Component-base