1 / 251

Software Design and Development

Software Design and Development. Kittipong Klomklaum Senior System Analyst / Data Modeler Bank of Thailand Kittipok@bot.or.th. COURSE OUTLINE. Chapter 1 Software Development Lifecycles (SDLC). Chapter 1. Software Development Lifecycles (SDLC). Software Development Lifecycles (SDLC).

irene-dalton
Télécharger la présentation

Software Design and Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Designand Development Kittipong Klomklaum Senior System Analyst / Data Modeler Bank of Thailand Kittipok@bot.or.th

  2. COURSE OUTLINE

  3. Chapter 1 Software Development Lifecycles (SDLC)

  4. Chapter 1. Software Development Lifecycles (SDLC) Software Development Lifecycles (SDLC) SDLC is the methodology for developing software SDLC is a tight combination of software development phases and process model. Software Development Phases = Requirement + Analysis + Design + Build Process Model = The model that represents Directions and Activities of System Development Phases

  5. Chapter 1. Software Development Lifecycles (SDLC) 1. Phases of Software Development Requirements Acquisition : To explore and ask what is the set of “needed to solved” problems? Requirement Analysis: To try to answer the question “What should the software do to solve the problems?” Software Design: To try to answer the question “How the software solve the problems?” Software Build: To try to implement the answer to the question “How the software solve the problems?”

  6. Design Build Requirement Acquisition Analysis Requirement Acquisition Design Build Requirement Acquisition Analysis Analysis Design Build Requirement Acquisition Analysis Design Build Chapter 1. Software Development Lifecycles (SDLC) 2. Software Development Process Models Waterfall Process Model Incremental Process Model Spiral Process Model

  7. Chapter 1. Software Development Lifecycles (SDLC) 2. Software Development Process Models Positive and Negative Factors to the Success of Process Model • Stabilities of user requirements • Association from steakholders • Flexibilities on budgets management • Efficiency of project manangement • Etc. • Inefficient change management • Budget Problems • Underestimation of work • Lacking of user participation • Etc.

  8. Requirement Acquisition Analysis Design Build Chapter 1. Software Development Lifecycles (SDLC) Waterfall Process Model • So called, sequential process model, waterfall process model prefers the end-to-end (one-shot) plan. Therefore user requirements must be • Clearly and completely understood. • Stable over the development period. • In waterfall process model, after one phase finished, normally, revision is not allowed . To cover the risk, signoff for each phase before working on the next phase is recommended.

  9. Requirement Acquisition Analysis Design Build Chapter 1. Software Development Lifecycles (SDLC) Waterfall Process Model • Waterfall process model is the oldest and the most classic process model: • Simple / No complicated manangement needed. • Waterfall process model causes many problems: • The changes on development process could not easily asserted if the development proceeded. • A working version will be produced only when the the development success as a whole. • Uncertainty of requirement could not be handled in waterfall process model.

  10. Requirement Acquisition Analysis Design Build Chapter 1. Software Development Lifecycles (SDLC) Waterfall Process Model Time Passed : Risk Increase Risk Time

  11. Requirement Acquisition Analysis Design Build Chapter 1. Software Development Lifecycles (SDLC) Waterfall Process Model With Positive Factors : Time Passed : Risk Increase more Slowly Positive Factors Risk Time

  12. Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Chapter 1. Software Development Lifecycles (SDLC) Incremental Process Model • Incremental Process Model delivers a reduced set of functions of software, which is enhanced in each iteration. In addition, iterations can occur between steps. • The incremental approach to software development starts to delivers limited function earlier than other approaches, with correnponding faster return on investment. However it requires • Careful planning • Very tight management control.

  13. Chapter 1. Software Development Lifecycles (SDLC) Incremental Process Model Delivery of 1st Increment (20% of Requirement) Design Build Requirement Acquisition Analysis Delivery of 2nd Increment (45% of Requirement) Design Build Requirement Acquisition Analysis Delivery of Complete Version (Nth increment) Design Build Requirement Acquisition Analysis • Incremental process model deliver partial-bodies of software when time passed. • Early increment is often a core product. ( product that address normal/critical requirements) • Incremental process model is useful for: • Relieve the staffing problem. • The changes can be handled in the next incremental. • Incremental process can cause problems because: • Increment needs an efficient version control mechanism.

  14. Chapter 1. Software Development Lifecycles (SDLC) Incremental Process Model Positive Factors Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Risk Time Incremental Process Model :Tend to Success

  15. Chapter 1. Software Development Lifecycles (SDLC) Incremental Process Model Risk Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Positive Factors Time Incremental Process Model :Tend to Fail !

  16. Chapter 1. Software Development Lifecycles (SDLC) Spiral Process Model • Spiral process model is similar to incremental process model. • Each cycle of spiral process model output the prototype and leter version of software. • Each development methodology could be recurred and improve in each cycle. • Like incremental process model, user association is significant to the success of development. • At the end of each cycle: revision and evaluation is needed for the improvement of development on the next phase

  17. Chapter 1. Software Development Lifecycles (SDLC) Spiral Process Model Positive Factors Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Risk Time Spiral Process Model :Tend to Success

  18. Chapter 1. Software Development Lifecycles (SDLC) Spiral Process Model Risk Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Design Build Requirement Acquisition Analysis Positive Factors Time Spiral Process Model :Tend to Fail !

  19. Chapter 2 Requirements Acquisition

  20. Chapter 2. Requirements Acquisition Requirements Acquisition To analyze is to try to answer the question: WHAT THE SOFTWARE DO?, based on the requirement of users. The analysis cannot be accomplished completely without the exact requirements Before analyze requirements it is very needed to ”ACQUIRE EXACT REQUIREMETNS from USERS” and model the requirement on users’ perspective

  21. Chapter 2. Requirements Acquisition • Requirements Acquisition • To acquire requirements is to: • Initialize requirements acquisition session. • Run requirements acquisition process. • Summarize the requirements. • If required, reprocess the acquisition.

  22. Chapter 2. Requirements Acquisition • Requirements Acquisition • Initialize requirements acquisition • The easiest way for requirement acquisition is to conduct a meeting or interview • At beginning, the the communication must be initialized by • explaining explaining the importance of development • explaining the effects of system on users and stakeholders • explaining the expected association from users and stakeholders.

  23. Chapter 2. Requirements Acquisition Requirements Acquisition 2. Run the acquisition process To run a meeting or interview is to ask context-free questions and to ask meta questions: Context-free Questions: A set of questions that will be lead to - - basic understanding of the problem - basic understanding of people who need solutions - basic understanding of nature of desired solutions Meta Questions: A set of questions that are asked to - clarify the context-free questions - confirm the understanding on questions and answers

  24. Chapter 2. Requirements Acquisition Requirements Acquisition 2. Run the acquisition process (cont.) The acquisition process should be partitioned into many subsessions, each sub-session should be divided into 3 phases 1st phase: source of solutions/ benefit of successful solutions 2nd phase: problem understanding 3rd phase: clarify and confirmation

  25. Chapter 2. Requirements Acquisition • Requirements Acquisition • 2. Run the acquisition process (cont.) • 1st phase: the first set of context-free questions should be asked by the analysts are: • Who are behind the solution request? • Who will use the solution? • Who will get the benefit if the solution is successful? • Are there any other sources of solution that needed?

  26. Chapter 2. Requirements Acquisition • Requirements Acquisition • 2. Run the acquisition process (cont.) • 2nd phase: the second set of context-free questions should be asked by the analysts are: • How would you characterize GOOD output that will be generated by a successful solution? • What are the exact problems this solution address? • Can you describe the environment of the problem? • What will happen or what will you need if some conditions/ environments changed?

  27. Chapter 2. Requirements Acquisition • Requirements Acquisition • 2. Run the acquisition process (cont.) • 3rd phase: the second set of meta questions should be asked by the analysts are: • Are my questions relevant to the problem you have? • Should I ask anything else? • Do you have any additional questions or suggestions?

  28. Chapter 2. Requirements Acquisition • Requirements Acquisition • 3. Summarize the requirements • QFD: Quality Function Deployment • QFD is a quality technique that translates needs of customer • into technical requirements for S/W. (QFD is first used by • Mitsubishi Heavy Industry Co.,Ltd., 1970s) • The Methodology to Classify the Users’ Requirements to: • Normal Requirements • Expected Requirements • Exciting Requirements

  29. Chapter 2. Requirements Acquisition • Requirements Acquisition • 3. Summarize the requirements • QFD: Normal Requirements • Objectives and goals stated during the meeting with customers. • The customers quite satisfy with these requirements. • Example: - specific system functions • - favorite level of performance

  30. Chapter 2. Requirements Acquisition • Requirements Acquisition • 3. Summarize the requirements (cont.) • QFD: Expected Requirements • Fundamental requirements that are forgotten by customers • The absence of these requirements cause significantly dissatisfaction to software • Example: - error handling and recovery • - user interface quality • - ease of installation

  31. Chapter 2. Requirements Acquisition • Requirements Acquisition • 3. Summarize the requirements (cont.) • QFD: Exciting Requirements • Requirements that go beyond customers’ expectation. • Proved to be very satisfying when presented. • Example: - help and tutorial. • - layout and template function. • - cross-application enabled components.

  32. Chapter 3 Object Orientation

  33. Chapter 3. Object Orientation Objectคือ สิ่งที่มีตัวตน และขอบเขตที่แน่นอน และมีสิ่งต่อไปนี้ - Operation:สิ่งที่ Object สามารถกระทำได้ (ต้องมี) • Unique Identity:สิ่งที่บ่งบอกถึงความมีอยู่จริงของ Object /ความแตกต่างจาก Object อื่นๆ (ต้องมี) • Attribute:คุณสมบัติที่ Object ตัวหนึ่งๆจะมีได้ (อาจจะมีหรือไม่มีก็ได้) Object: เครื่องบินรุ่น BOEING 747 จุผู้โดยสารได้ 140 คน ที่บินออกจากดอนเมืองไปยัง Sydney ในวันที่ 15 เมษายน 2547 เวลา 12.30 น.

  34. Car Chapter 3. Object Orientation Class คือต้นฉบับของ Object ซึ่งมีคุณสมบัติ (attribute) พฤติกรรม (operation) ที่เหมือนกัน Class Class เป็น static description Object เป็น instance ของ Class Objects OO Principle : Abstraction

  35. Chapter 3. Object Orientation Class: Attributes Object attribute value Car:Truck A Class attribute จำนวนล้อ = 10 ขนาดเครื่องยนต์ =10000 Car จำนวนล้อ ขนาดเครื่องยนต์ Car:Racer B จำนวนล้อ = 4 ขนาดเครื่องยนต์ = 2500

  36. “ An Operation is the implementation of a service that can be requested from any object of the class to affect behavior.” Chapter 3. Object Orientation Car Operation จำนวนล้อ ขนาดเครื่องยนต์ ติดเครื่อง เดินหน้า ถอยหลัง Operation คือบริการที่ object มีให้เรียกใช้งาน

  37. Chapter 3. Object Orientation หลักการพื้นฐานของ ObjectOrientation ประกอบด้วย 3 ข้อ • Abstraction • Encapsulation • Modularity Object Orientation Modularity Abstraction Encapsulation

  38. Chapter 3. Object Orientation นิยามของ Abstraction “Any model that includes the most important, essential,or distinguishing aspects of something while suppressing or ignoring less important, immaterial, ordiversionary details. The result of removing distinctions so as to emphasize commonalties” จาก the Dictionary of Object Technology (Firesmith, Eykholt, 1995) สรุปคือ โครงร่างที่มีเฉพาะลักษณะพิเศษของตัวเอง ที่ทำให้แตกต่างจากสิ่งอื่นๆ

  39. Chapter 3. Object Orientation นิยามของ Encapsulation “ The physical localization of features (e.g., properties, behaviors) into a single black box abstraction that hides their implementation (and associated design decisions) behind a public interface)” สรุปคือ การซ่อนการทำงานไว้ภายในกล่องโดยต้องติดต่อผ่าน Interface ที่กำหนดไว้เท่านั้น

  40. Chapter 3. Object Orientation นิยามของ Modularity “ The logical and physical decomposition of things (e.g., responsibilities and software) into small, simple groupings (e.g., requirements and classes, respectively), which increase the achievements of software-engineering goals.” สรุปคือ Modularity เป็นหลักการเดียวกับ Divide & conquer คือการแบ่งสิ่งที่มีขนาดใหญ่ และ/หรือ มีความซับซ้อน ให้เป็นชิ้นๆ ที่เล็กลง และจัดการได้ง่ายขึ้น

  41. Chapter 3. Object Orientation Abstractions • Abstractionsคือกระบวนการในการหาและใส่ Concept เข้าไปยัง Real-world Objects ที่สนใจเพื่อก่อให้เกิด Class • Abstractions สามารถจำแนกออกได้เป็น • 4 กระบวนการ คือ • Classification Abstraction • Aggregation Abstraction • Association Abstraction • Generalization Abstraction

  42. Chapter 3. Object Orientation Classification Abstractions Classification Abstractionคือกระบวนการในการหาและใส่ Concept เข้าไปยัง Real-world Objects เพื่อให้เกิด Class Concepts: มีร่างกาย สื่อสารด้วยภาษามนุษย์ สามารถคิดได้ สรพงษ์ Mary หวงเฟยหง Class: คน

  43. Chapter 3. Object Orientation Classification Abstractions (cont.) การเปลี่ยน Concept จะมีผลให้ Class มีคุณสมบัติเปลี่ยนไป และอาจจะทำให้จำนวนสมาชิกของ Object ใน Class นั้นเปลี่ยนไปได้ สรพงษ์ Concepts: มีร่างกาย สื่อสารด้วยภาษามนุษย์ สามารถคิดได้ เพศชาย Mary หวงเฟยหง Class: ผู้ชาย

  44. Chapter 3. Object Orientation Classification Abstractions (cont.) Concepts: Concepts: มีร่างกาย สื่อสารด้วยภาษามนุษย์ สามารถคิดได้ เพศชาย เล่นเบสบอลได้ สรพงษ์ Mary Class: นักกีฬาเบสบอลชาย หวงเฟยหง

  45. Chapter 3. Object Orientation Aggregation Abstraction Aggregation Abstractionคือกระบวนการในการหาความสัมพันธ์ในเชิง “องค์ประกอบ” ระหว่าง Class Class ที่เป็นองค์ประกอบเรียกว่า Component Class Class ที่เกิดจากการรวมกันของ Component Classเรียกว่า Aggregated Class หัว Aggregate ลำตัว แขน Class: คน ขา

  46. Chapter 3. Object Orientation Aggregation Abstraction : Cardinality ใน Aggregation Abstraction เราจำเป็นต้องระบุ Cardinalityหรือ จำนวนของ Objects ของ Component Class ที่มีได้น้อยที่สุด(Minimum Cardinality: min-card)และมากที่สุด(Maximum Cardinality: max-card)ใน Aggregated Class Aggregate หัว 1..1 1..1 Aggregate 0..n ร่างกาย ผม 0..2 แขน Class: คน 0..2 ขา

  47. Chapter 3. Object Orientation Association Abstraction Association Abstractionคือกระบวนการในการหาความสัมพันธ์ระหว่าง Class ที่แตกต่างกัน โดยเป็นความสัมพันธ์ที่ไม่ใช่ในเชิงที่ขึ้นต่อกันเหมือนกับใน Aggregation Abstraction สอน อาจารย์ผู้สอน วิชาเรียน แบ่งเป็น มี นักเรียน Section เส้นตรงใช้แสดงความสัมพันธ์ระหว่าง Class ลูกศรใช้ในการบอกทิศทางของความสัมพันธ์ ใช้ ห้องเรียน

  48. Chapter 3. Object Orientation Association Abstraction: Cardinality ความสัมพันธ์เชิง Associationระหว่าง Class จะมี Minimum Cardinalityและ Maximum Cardinalityของ Class ที่อยู่ทั้งสองข้างของความสัมพันธ์ เสมอ ประเภทของ Association จำแนกตาม Cardinality ได้เป็น 3 ประเภท ดังนี้ One-to-One Association (1-1) One-to-Many Association (1-M) Many-to-Many Association (M-M)

  49. Chapter 3. Object Orientation Association Abstraction: Cardinality Example One-to-One Association (1-1) One-to-Many Association (1-M) Many-to-Many Association (M-M) มี 0..1 1..1 คน บัตรประจำตัวประชาชน 1..1 ผู้โดยสาร 0..n บรรทุก รถยนต์ 0..n 0..n เรียน วิชาเรียน นักเรียน

  50. Chapter 3. Object Orientation Generalization Abstraction Generalization Abstractionคือกระบวนการในการหาความสัมพันธ์ระหว่าง Class ในลักษณะที่มีการเพิ่มเติม Attributes หรือ Operations ให้กับ Class เดิม เพื่อให้เกิด Class ใหม่ทีมีคุณลักษณะพิเศษแตกต่างไปจากเดิมโดย Class ใหม่ได้รับถ่ายทอด (inherit) คุณลักษณะบางอย่างจาก Class เดิมด้วย • Generalization Abstraction สามารถจำกัดความได้ใน 2 ความหมายคือ • Generalize • Specialize

More Related