ניתוח ועיצוב מערכות מידע 372-1-3401 2012-2013, תשע"ג – ב' רמי פוזיס puzis@bgu.ac.il https://piazza.com/bgu.ac.il/spring2013/37213401

Object-Oriented Analysis and Design Course Goal The course aims at teaching the analysis and design of software systems Analysis means who will use the system, what the system will do, where and when it will be used. Design means how the system will be built and operate, in terms of hardware and software. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Software System Characteristics - Requirements and Solutions Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

What is a software system? Computer programs and associated documentation: Requirements; Analysis and Design models; User manuals; Software products may be Generic - developed to be sold to a range of different customers: PC software such as Excel or Word. Bespoke (custom) - developed for a single customer according to their specification. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Keys for Building a Good System Modularity: a modular system consists of : encapsulated modules with dependencies among them. Flexibility: a flexible system requires minimal changes in order to be adapted for new customers / circumstances Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design The Details Matter Applying changes to a program Automatic refactoring (rename, extract code, pull down/up etc.) Search and replace Validate changes by tracking compile errors and running tests Applying changes to documentation Read, search… and replace? Changing dependency or constraint definition does not propagate throughout the document No ability to validate changes Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design Good Documentation Concise The least text possible. No excess details. Clear Simple figures. Lists and tables where applicable. Simple down to the ground language. Complete Every question on what the system should do and how is it built is answered in the documentation. If the clients sue the developer, he can win the case based on provided system documentation. Well defined There is only one way to understand any documented detail. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

הנפשות הפועלות לקוח איש מחירות מנתח מערכות מפתח זמן צורך שמיים וארץ לקוח איש מחירות מנתח מערכות מפתח זמן צורך שמיים וארץ מקדמה קדימה לעבודה אברה-כדברה מימוש מערכת עובדת רב תודות והון תועפות

נקודה על המסך הצעת פרויקט תיאור המערכת: תוכנה שתציג נקודה על המסך! מפתח לקוח הצעת פרויקט תיאור המערכת: תוכנה שתציג נקודה על המסך! המזמין מתחייב לשלם מקדמה של 100$ עם חתימת ההסכם ו900$ נוספים עם השלמת הפרויקט לשביעות רצונו. המפתח מתחייב להשלים את הפרויקט לשביעות רצון המזמין תוך שני ימי עסקים החל מהיום שאחרי חתימת ההסכם. שני הצדדים מפקידים צ'ק בנקאי על סך 900$ כערבות לעמידה בתנאי ההסכם. אי עמידה באחד מתנאי ההסכם תיתן לצד השני זכות לפרוע את הצ'ק. תאריך: _______ חתימת המזמין _______ חתימת המפתח _______

נקודה על המסך מפתח לקוח כשאני מפעיל את התוכנה שלך אני מצפה שהיא תציג לי נקודה על המסך, לא תפתח חלונות! למה הנקודה לא נשארת על המסך כשאני מאתחל את המחשב? אני רוצה את הנקודה קרוב לפינה השמאלית העליונה. לא, אני רוצה אותה מצד ימין למעלה! לא, אני רוצה להיות מסוגל להזיז אותה!!! אני רוצה שהנקודה תוצג כאילו לפני המסך. אם היא מסתירה לי משהו אני רוצה להיות מסוגל להזיז את הראש ולהביט מאחוריה. ראיתי תוכנה כזאת בטלוויזיה!!!!! מה שהלקוח ציפה לקבל מה שסופק

ניתוח מערכות!? עיצוב מערכת ניתוח דרישות

Development Processes Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

What is a software development process? An organized set of activities whose goal is the development or evolution of software. Generic activities in all software development processes are: Specification - what the system should do and its development constraints. Development - production of the software system. Validation - checking that the software is what the customer wants. Maintenance - changing the software in response to changing demands. Software development processes yield better software systems. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Variety of development processes A variety of development processes have been studied and experimented in the field of Software Engineering: Waterfall. Evolutionary development. Component based development. Incremental development. Spiral development. Agile development. Development processes differ in the involved activities, their duration and ordering. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design Waterfall model (1) Verification Requirement Verification Requirement Change Verification Analysis Verification Design Verification Implementation Verification Integration Operational development maintenance End of use Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Object-Oriented Analysis and Design Waterfall model (2) Problem Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Applicability This model is only appropriate when the requirements are well-understood and changes are fairly limited during the design process. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Evolutionary development (1) Objective is to work with customers and to evolve a final system from an initial outline specification. Requirement Identification Prototype Development Prototype Use and Evaluation Prototype Improvement Operational End of use Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Evolutionary development (2) Applicability: For small or medium-size interactive systems. For parts of large systems (e.g. the user interface). For short-lifetime systems. Problems: Lack of process visibility. Systems are often poorly structured. Special skills (e.g. in languages for rapid prototyping) may be required. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Incremental development (1) Development and delivery is broken into increments: Delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Incremental development (2) Build 1 Analysis Build 2 Design Analysis Implementation & Integration Design Build n Delivery Implementation& Integration Analysis Delivery Design Implementation & Integration Analysis Group Design Group Implementation Group Delivery Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Incremental development (3) Advantages System functionality is available earlier. Early increments act as a prototype: Help elicit requirements for later increments. Lower risk of overall project failure. Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Spiral model – an incremental process planning risk analysis engineering customer evaluation artifacts Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

The Agile Development Movement An incremental software development movement that aims at shortening the development phases: Lightweight – few documents and models. Fast implementation. Correlation between models and software. The most well known agile development process -- Extreme Programming (K. Beck): Minimal development phases. Test Driven Development (TDD). Object-Oriented Analysis and Design Mira Balaban and Arnon Sturm

Inception ADISSA Architectural Design of Information Systems based on Structured Analysis Study the current state Initial specification Feasibility Study System Analysis http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9 System Design Implementation Lecture No. 5

The Unified Process (UP)

Requirements

נקודה על המסך מפתח לקוח לקוח (ייזום): אני רוצה תוכנה שתצייר לי נקודה על המסך! מפתח (חקר מצב קיים): למה? לקוח: ככה! מפתח (הוצאת דרישות): באיזה מיקום? באיזה צבע? באיזה גודל? מתי? וכו, וכו, וכו...

נקודה על המסך: מסמך דרישות מפתח לקוח דרישות חומרה: מחשב PC רגיל + מסך מחשב מע' הפעלה: WIN-XP ומעלה. דרישות פונקציונליות: התוכנה נפתחת בחלון עם רקע לבן וסרגל כלים המכיל 3 שדות טקסט עם תוויות (X, Y, צבע) וכפתור עם תווית "צייר". ערכים מותרים בשדה "צבע" הם: "אדום", "כחול", או "ירוק" בלבד. בעת לחיצה על הכפתור תופיע נקודה בגודל פיקסל אחד בצבע שנבחר. הנקודה תופיע בתוך החלון, X פיקסלים ימינה מה קצה השמאלי וY פיקסלים מטה מהקצה העליון של החלון. הנקודות שהופיעו כודם לכן לא תמחקנה. הנקודות שצוירו לא יופיעו בהפעלה חוזרת של התוכנה. התוכנה לא מספקת אפשרויות של שמירה, טעינה, או ייצוא של נקודות לקובץ. מסירה : באמצעות קובץ התקנה על CD.

שאלות מפתח למה? צריך את זה מה? זה צריך לעשות איך? זה יעשה

בכל הרמות של פיתוח המערכת! שאלות מפתח למה? ייזום מה? דרישות איך? עיצוב בכל הרמות של פיתוח המערכת!

The Requirements Process Why Are Requirements Important? Top factors that caused project to fail (Standish, 1995) Incomplete requirements (13%) Lack of user involvement (12%) Lack of resources (11%) Unrealistic expectations (10%) Lack of executive support (9%) Changing requirements and specifications (9%) Lack of planning (8%) System no longer needed (7%) Some part of the requirements process is involved in almost all of these causes Requirements error can be expensive if not detected early Prof. Mark Last

Categories of Requirements Example: MRP System / Customer Orders Requirements that absolutely must be met The customer name, ordered quantities, and promised due date must be recorded for each order Requirements that are highly desirable but not necessary The date of receiving the order should be recorded Requirements that are possible but could be eliminated Store the original due date requested by the customer Prof. Mark Last

Requirements Elicitation Stakeholders and their roles Clients: pay for the software to be developed Customers: buy the software after it is developed Users: use the system Domain experts: familiar with the problem that the software must automate Market Researchers: conduct surveys to determine future trends and potential customers Lawyers or auditors: familiar with government, safety, or legal requirements Software engineers or other technology experts Prof. Mark Last

Requirements Elicitation or what the stakeholders want? Interviewing stakeholders Reviewing available documentations Observing the current system (if one exists) Apprenticing with users to learn about user's task in more details Interviewing user or stakeholders in groups Using domain-specific check lists Brainstorming with current and potential users Prof. Mark Last

Making Requirements Testable General Guidelines Specify a quantitative description for each adverb and adjective (nice, fast, large, etc…) Replace pronouns with names of specific entities Make sure that each noun is defined in exactly one place Prof. Mark Last

Types of Requirements Two Kinds of Requirements Documents Requirements definition: a complete listing of everything the customer wants to achieve Describing the entities in the environment where the system will be installed Requirements specification: restates the requirements as a specification of how the proposed system shall behave Prof. Mark Last

Characteristics of Requirements Correct Consistent Unambigious Complete Feasible Relevant Testable Traceable Prof. Mark Last

Architectural Design of Information Systems based on Structured Analysis ADISSA

Inception ADISSA Architectural Design of Information Systems based on Structured Analysis Study the current state Initial specification Feasibility Study System Analysis http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9 System Design Implementation