1. ניתוח ועיצוב מערכות מידע
, תשע"ג – ב'
רמי פוזיס

3. 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

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

5. 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

6. 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

7. 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

8. 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

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

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

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

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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

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

24. 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

25. Inception
ADISSA
Architectural Design of Information Systems based on Structured Analysis
Study the current state
Initial specification
Feasibility Study
System Analysis
System Design
Implementation
Lecture No. 5

26. The Unified Process (UP)

27. Requirements

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

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

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

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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

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

39. Architectural Design of Information Systems based on Structured Analysis ADISSA

40. Inception
ADISSA
Architectural Design of Information Systems based on Structured Analysis
Study the current state
Initial specification
Feasibility Study
System Analysis
System Design
Implementation