Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN
TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN <ul><li>Khái niệm cơ bản về hệ thống (System) </li></ul><ul><li>Tổ chức (Organization)  </...
Khái niệm cơ bản về hệ thống <ul><li>&quot;Một hệ thống là một tập hợp các thành phần liên quan với nhau và phối hợp hoạt ...
Tổ chức (Organization) <ul><li>Tổ chức là một hệ thống </li></ul><ul><ul><li>Tổ chức kinh tế: xí nghiệp, công ty, … </li><...
Dữ liệu và thông tin <ul><li>Dữ liệu (data):  </li></ul><ul><ul><li>&quot;Data is the raw input from which information is ...
Information Systems (IS) <ul><li>Một hệ thống thông tin: </li></ul><ul><ul><li>Là các phương tiện có thể nhận dữ liệu (inp...
Hệ thống thông tin tự động hóa  <ul><li>Hệ thống thông tin tự động hóa (Computerized Information Systems) bao gồm:  </li><...
<ul><li>Thông tin cần thiết cho doanh nghiệp và giúp ra quyết định ở nhiều mức quản lý khác nhau trong tổ chức </li></ul>T...
Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Insurance Systems Leisure Industry
Real-Time Systems Automated Production Control Control Systems Security Systems
Management Information Systems Decision Support Systems Office Automation Systems Knowledge Based Systems Executive Inform...
Best Practices of Software Engineering
Objectives: Best Practices <ul><li>Identify symptoms of software development problems. </li></ul><ul><li>Explain the Best ...
Mục đích của công nghệ phần mềm <ul><li>Nhằm tạo ra sản phẩm phần mềm có chất lượng </li></ul><ul><ul><li>Với ít nỗ lực (t...
Bản chất việc phát triển phần mềm <ul><li>Phần mềm là sản phẩm của hoạt động phát triển một cách sáng tạo của các “nghệ sĩ...
Con người liên quan (Stakeholders) <ul><li>Khách hàng (Customers): Users và System owners </li></ul><ul><ul><li>Các nguyên...
Symptoms of Software Development Problems <ul><li>User or business needs not met </li></ul><ul><li>Requirements not addres...
Trace Symptoms to Root Causes Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor qual...
Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Mod...
Practice 1: Develop Iteratively Best Practices Process Made Practical   Develop Iteratively Manage Requirements Use Compon...
Waterfall Development Characteristics <ul><li>Delays confirmation of critical risk resolution.  </li></ul><ul><li>Measures...
Iterative Development Characteristics <ul><li>Resolves major risks before making large investments.  </li></ul><ul><li>Ena...
Develop Iteratively <ul><li>Iterative development produces an executable </li></ul>1. Initial Planning 2. Planning 3. Requ...
Risk Profiles Time Risk Waterfall Risk Iterative Risk Risk Reduction
Practice 2: Manage Requirements Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Comp...
Managing Requirements <ul><li>Ensures that you </li></ul><ul><ul><li>solve the right problem </li></ul></ul><ul><ul><li>bu...
Practice 3: Use Component Architectures Best Practices Process Made Practical   Develop   Iteratively Manage Requirements ...
Use Component Architectures  <ul><li>Software architecture needs to be: </li></ul>Component-based Resilient <ul><ul><li>Re...
Purpose of a Component-Based Architecture <ul><li>Basis for reuse </li></ul><ul><ul><li>Component  </li></ul></ul><ul><ul>...
Practice 4: Model Visually (UML) Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Com...
Model Visually (UML) <ul><li>Captures structure and behavior </li></ul><ul><li>Shows how system elements fit together </li...
Visual Modeling with the Unified Modeling Language Dynamic Diagrams Multiple views Precise syntax and semantics Activity D...
Activity Diagram – Lược đồ hoạt động  <ul><li>Activity diagrams được dùng để miêu tả dòng công việc  </li></ul><ul><li>Ví ...
Use Case Diagram Use Case Actor Use Case Diagram B <<extend>> A <<include>> a1 Generalization
Class Diagram Personal Customer creditCard# Customer name address creditRating() {if Order.customer.creditRating is &quot;...
Sequence Diagram – Lược đồ tuần tự
Collaboration Diagram – Lược đồ cộng tác
Statechart Diagram – Lược đồ trạng thái
Component Diagram – Lược đồ thành phần <ul><li>Lược đồ thành phần trình bày hệ thống được tổ chức thành các thành phần cộn...
Practice 5: Continuously Verify Quality Best Practices Process Made Practical  Develop   Iteratively Manage Requirements U...
Continuously Verify Quality Cost Transition Construction Elaboration Inception <ul><li>Cost to Repair Software </li></ul><...
Test Dimensions of Quality Reliability Test the application for consistent and predictable behavior. Performance Test onli...
Test Each Iteration UML Model  and  Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 3 Tes...
Practice 6: Manage Change  Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Component...
Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. Help Desk User...
Manage Change <ul><li>To avoid confusion, have: </li></ul><ul><ul><li>Secure workspaces for each developer </li></ul></ul>...
Manage Change (continued) <ul><li>Unified Change Management (UCM) involves: </li></ul><ul><ul><li>Management across the li...
Rational Unified Process Implements Best Practices Develop Iteratively Manage Requirements Use Component Architectures Mod...
Achieving Best Practices <ul><li>Iterative approach </li></ul><ul><li>Guidance for activities and artifacts </li></ul><ul>...
A Team-Based Definition of Process <ul><li>A process defines  Who  is doing  What ,  When , and  How , in order   to reach...
Process Structure - Lifecycle Phases <ul><li>The Rational Unified Process has four phases: </li></ul><ul><ul><li>Inception...
Bringing It All Together: The Iterative Approach Disciplines group activities logically. In an iteration, you walk through...
Summary <ul><li>Best Practices guide software engineering by addressing root causes. </li></ul><ul><li>Best Practices rein...
Upcoming SlideShare
Loading in …5
×

1 gioi thieu httt

1,045 views

Published on

Published in: Education, Business
  • Be the first to comment

  • Be the first to like this

1 gioi thieu httt

  1. 1. TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN
  2. 2. TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN <ul><li>Khái niệm cơ bản về hệ thống (System) </li></ul><ul><li>Tổ chức (Organization) </li></ul><ul><li>Dữ liệu (Data) và thông tin (information) </li></ul><ul><li>Thông tin và các mức ra quyết định quản lý (Management decision making) </li></ul><ul><li>Định nghĩa hệ thống thông tin (Information Systems) </li></ul><ul><li>Phân loạI IS </li></ul><ul><ul><li>Các IS phân loại theo mức quản lý tổ chức. </li></ul></ul>
  3. 3. Khái niệm cơ bản về hệ thống <ul><li>&quot;Một hệ thống là một tập hợp các thành phần liên quan với nhau và phối hợp hoạt động cùng với nhau nhằm đạt được một mục tiêu cụ thể&quot; (Lee) </li></ul>System A Subsystem B Subsystem C Subsystem E Subsystem D Boundary Interface Environment of System A
  4. 4. Tổ chức (Organization) <ul><li>Tổ chức là một hệ thống </li></ul><ul><ul><li>Tổ chức kinh tế: xí nghiệp, công ty, … </li></ul></ul><ul><ul><li>Tổ chức xã hội: bệnh viện, câu lạc bộ, … </li></ul></ul>Môi trường hoạt động của tổ chức Sales IT HRI Purchasing Training
  5. 5. Dữ liệu và thông tin <ul><li>Dữ liệu (data): </li></ul><ul><ul><li>&quot;Data is the raw input from which information is provided” (Lucey) </li></ul></ul><ul><ul><li>Là các dữ kiện, các sự kiện, các giao dịch thô, rời rạc, ... </li></ul></ul><ul><li>Thông tin (information): </li></ul><ul><ul><li>“ Information is data that have been processed in such a way as to be useful to the recipient.” (Lucey) </li></ul></ul><ul><li>Thông tin là tài nguyên của tổ chức, và có vai trò quan trọng quyết định sự thành công của tổ chức. </li></ul><ul><ul><li>Thông tin được tạo ra và truy xuất ngày càng tăng </li></ul></ul><ul><ul><li>Yêu cầu quản lý thông tin hiệu quả. </li></ul></ul><ul><ul><li>Xử lý để tạo ra các thông tin mới có giá trị hơn </li></ul></ul>
  6. 6. Information Systems (IS) <ul><li>Một hệ thống thông tin: </li></ul><ul><ul><li>Là các phương tiện có thể nhận dữ liệu (input), lưu trữ và xử lý dữ liệu, để tạo ra thông tin (output) cho mục đích hỗ trợ ra quyết định. </li></ul></ul><ul><ul><li>Có thể xử lý bằng tay hoặc máy tính. </li></ul></ul><ul><li>Hệ thống thông tin của tổ chức gồm: </li></ul><ul><ul><li>Một cơ sở thông tin (information base) mà bao gồm một hay nhiều nguồn thông tin khác; </li></ul></ul><ul><ul><li>Một tập các xử lý mà được thực hiện bởi người hay máy để truy xuất, cập nhập và xử lý thông tin. </li></ul></ul><ul><ul><li>Ví dụ: Một hệ thống thư viện có cơ sở thông tin là sách, loại sách, …; các xử lý là tìm, mượn, trả sách, … </li></ul></ul>
  7. 7. Hệ thống thông tin tự động hóa <ul><li>Hệ thống thông tin tự động hóa (Computerized Information Systems) bao gồm: </li></ul><ul><ul><li>Một hay nhiều cơ sở dữ liệu (databases) hay tập tin (files) lưu trữ cở sở thông tin. </li></ul></ul><ul><ul><li>Một hay nhiều chương trình ứng dụng (Application programs) để truy xuất và cập nhật cơ sở thông tin bằng máy tính. </li></ul></ul><ul><ul><li>Một hay nhiều giao diện người dùng (user interface) cho các nhóm người dùng khác nhau. </li></ul></ul><ul><li>Computerized Information System = Databases + Applications + Interfaces </li></ul>
  8. 8. <ul><li>Thông tin cần thiết cho doanh nghiệp và giúp ra quyết định ở nhiều mức quản lý khác nhau trong tổ chức </li></ul>Thông tin và các cấp quản lý Anthony’s Pyramid: cấu trúc quản lý của tổ chức Operational Tactical Strategic Large time horizon Small time horizon Summary data Detail data Unstructured problems Structured problems
  9. 9. Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Insurance Systems Leisure Industry
  10. 10. Real-Time Systems Automated Production Control Control Systems Security Systems
  11. 11. Management Information Systems Decision Support Systems Office Automation Systems Knowledge Based Systems Executive Information Systems
  12. 12. Best Practices of Software Engineering
  13. 13. Objectives: Best Practices <ul><li>Identify symptoms of software development problems. </li></ul><ul><li>Explain the Best Practices. </li></ul><ul><li>Present the Rational Unified Process (RUP) within the context of the Best Practices. </li></ul>
  14. 14. Mục đích của công nghệ phần mềm <ul><li>Nhằm tạo ra sản phẩm phần mềm có chất lượng </li></ul><ul><ul><li>Với ít nỗ lực (tiến trình phát triển dễ dàng) </li></ul></ul><ul><ul><li>Với ít chi phí và thời gian </li></ul></ul><ul><li>Chất lượng phần mềm (Quality Software) bao gồm: </li></ul><ul><ul><li>Tính đáng tin cậy (Reliable) </li></ul></ul><ul><ul><li>Tính dễ dùng (Reusable) </li></ul></ul><ul><ul><li>Tinh tế (Robust): có các chức năng hiệu quả </li></ul></ul><ul><ul><li>Dễ bảo trì (Maintainable) </li></ul></ul><ul><ul><li>Tính Hiệu quả (Efficient) </li></ul></ul><ul><ul><li>Thân thiện người dùng (Userfriendly) </li></ul></ul><ul><ul><li>… </li></ul></ul>
  15. 15. Bản chất việc phát triển phần mềm <ul><li>Phần mềm là sản phẩm của hoạt động phát triển một cách sáng tạo của các “nghệ sĩ lành nghề” </li></ul><ul><ul><li>Phần mềm được phát triển, chứ không phải sản xuất. </li></ul></ul><ul><ul><li>Ngay cả với công nghệ thành phần (Component technology), phần mềm được xây dựng bằng cách lắp ghép các thành phần thì xử lý lắp ghép này cũng là nghệ thuật. </li></ul></ul><ul><li>Cho bất kỳ hệ thống nào, luôn cần phải tạo ra một mô hình quan niệm của giải pháp cuối cùng thỏa mãn các yêu cầu của khách hàng. </li></ul><ul><ul><li>Đó là kết quả của nhiệm vụ phân tích yêu cầu và thiết kế hệ thống. </li></ul></ul><ul><ul><li>Độc lập với cài đặt. </li></ul></ul>
  16. 16. Con người liên quan (Stakeholders) <ul><li>Khách hàng (Customers): Users và System owners </li></ul><ul><ul><li>Các nguyên nhân dẫn đến thất bại của dự án phần mềm liên quan đến khách hàng: </li></ul></ul><ul><ul><li>Yêu cầu khách hàng bị hiểu sai và hay thu thập không đầy đủ </li></ul></ul><ul><ul><li>Yêu cầu khách hàng thay đổi quá thường xuyên. </li></ul></ul><ul><ul><li>Khách hàng không giao đầy đủ các tài nguyên cho dự án. </li></ul></ul><ul><ul><li>Khách hàng không hợp tác với người phát triển. </li></ul></ul><ul><ul><li>Mong đợi không thực tế của khách hàng. </li></ul></ul><ul><ul><li>Khách hàng không cần đến hệ thống nữa. </li></ul></ul><ul><li>Người phát triển (Developers): Analysts, Designers, Programmers </li></ul><ul><ul><li>“ Thiết kế tốt được tạo từ những nhà thiết kế tốt” </li></ul></ul>
  17. 17. Symptoms of Software Development Problems <ul><li>User or business needs not met </li></ul><ul><li>Requirements not addressed </li></ul><ul><li>Modules not integrating </li></ul><ul><li>Difficulties with maintenance </li></ul><ul><li>Late discovery of flaws </li></ul><ul><li>Poor quality of end-user experience </li></ul><ul><li>Poor performance under load </li></ul><ul><li>No coordinated team effort </li></ul><ul><li>Build-and-release issues </li></ul>
  18. 18. Trace Symptoms to Root Causes Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Symptoms Root Causes Best Practices Ambiguous communications Undetected inconsistencies Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Modules do not fit Model Visually (UML) Continuously Verify Quality
  19. 19. Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally Ensures users are involved as requirements evolve
  20. 20. Practice 1: Develop Iteratively Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  21. 21. Waterfall Development Characteristics <ul><li>Delays confirmation of critical risk resolution. </li></ul><ul><li>Measures progress by assessing work-products that are poor predictors of time-to-completion. </li></ul><ul><li>Delays and aggregates integration and testing. </li></ul><ul><li>Precludes early deployment. </li></ul><ul><li>Frequently results in major unplanned iterations. </li></ul>Code and Test Design Subsystem Integration System Test Waterfall Process Requirements Analysis Planning
  22. 22. Iterative Development Characteristics <ul><li>Resolves major risks before making large investments. </li></ul><ul><li>Enables early user feedback. </li></ul><ul><li>Makes testing and integration continuous. </li></ul><ul><li>Focuses project short-term objective milestones. </li></ul><ul><li>Makes possible deployment of partial implementations. </li></ul>T I M E Iteration 1 Iteration 2 Iteration 3 P R D C I T P R D C I T P R D C I T
  23. 23. Develop Iteratively <ul><li>Iterative development produces an executable </li></ul>1. Initial Planning 2. Planning 3. Requirements 4. Analysis & Design 5. Implementation 7. Deployment 6. Test 8. Evaluation Management Environment (on-going) Each iteration results in an executable release
  24. 24. Risk Profiles Time Risk Waterfall Risk Iterative Risk Risk Reduction
  25. 25. Practice 2: Manage Requirements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  26. 26. Managing Requirements <ul><li>Ensures that you </li></ul><ul><ul><li>solve the right problem </li></ul></ul><ul><ul><li>build the right system </li></ul></ul><ul><li>by taking a systematic approach to </li></ul><ul><ul><li>Understanding the problem. </li></ul></ul><ul><ul><li>Eliciting, organizing, and documenting the requirements. </li></ul></ul><ul><ul><li>Managing the changing requirements of a software application. </li></ul></ul>
  27. 27. Practice 3: Use Component Architectures Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  28. 28. Use Component Architectures <ul><li>Software architecture needs to be: </li></ul>Component-based Resilient <ul><ul><li>Reuse or customize components </li></ul></ul><ul><ul><li>Select from commercially available components </li></ul></ul><ul><ul><li>Evolve existing software incrementally </li></ul></ul><ul><ul><li>Meets current and future requirements </li></ul></ul><ul><ul><li>Improves extensibility </li></ul></ul><ul><ul><li>Enables reuse </li></ul></ul><ul><ul><li>Encapsulates system dependencies </li></ul></ul>
  29. 29. Purpose of a Component-Based Architecture <ul><li>Basis for reuse </li></ul><ul><ul><li>Component </li></ul></ul><ul><ul><li>Architecture </li></ul></ul><ul><li>Basis for project management </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Staffing </li></ul></ul><ul><ul><li>Delivery </li></ul></ul><ul><li>Intellectual control </li></ul><ul><ul><li>Manage complexity </li></ul></ul><ul><ul><li>Maintain integrity </li></ul></ul>System- software Middleware Business- specific Application- specific Component-based architecture with layers
  30. 30. Practice 4: Model Visually (UML) Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  31. 31. Model Visually (UML) <ul><li>Captures structure and behavior </li></ul><ul><li>Shows how system elements fit together </li></ul><ul><li>Keeps design and implementation consistent </li></ul><ul><li>Hides or exposes details as appropriate </li></ul><ul><li>Promotes unambiguous communication </li></ul><ul><ul><li>The UML provides one language for all practitioners. </li></ul></ul>
  32. 32. Visual Modeling with the Unified Modeling Language Dynamic Diagrams Multiple views Precise syntax and semantics Activity Diagrams Models Static Diagrams Sequence Diagrams Communication Diagrams State Machine Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams
  33. 33. Activity Diagram – Lược đồ hoạt động <ul><li>Activity diagrams được dùng để miêu tả dòng công việc </li></ul><ul><li>Ví dụ: Một lược đồ hoạt động trình bày một quy trình nghiệp vụ đơn giản để xuất hóa đơn và thanh toán </li></ul>
  34. 34. Use Case Diagram Use Case Actor Use Case Diagram B <<extend>> A <<include>> a1 Generalization
  35. 35. Class Diagram Personal Customer creditCard# Customer name address creditRating() {if Order.customer.creditRating is &quot;poor&quot; then Order.isPrepaid must be true} Employee Corporate Customer contactName creditRating creditLimit remind() billForMonth() 0..1 0..n 0..1 0..n sales rep Order dateReceived isPrepaid number : String price : Money dispatch() close() 1 0..n 1 0..n Product Order Line quantity : Integer price : Money isSatisfied : Boolean 1..n 1 1..n 1 1 0..n 1 0..n
  36. 36. Sequence Diagram – Lược đồ tuần tự
  37. 37. Collaboration Diagram – Lược đồ cộng tác
  38. 38. Statechart Diagram – Lược đồ trạng thái
  39. 39. Component Diagram – Lược đồ thành phần <ul><li>Lược đồ thành phần trình bày hệ thống được tổ chức thành các thành phần cộng tác với nhau như thế nào; </li></ul><ul><li>Các thành phần được xây dựng từ các đối tượng </li></ul>Call Centre Interface Order Management Customer Management Database Management
  40. 40. Practice 5: Continuously Verify Quality Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  41. 41. Continuously Verify Quality Cost Transition Construction Elaboration Inception <ul><li>Cost to Repair Software </li></ul><ul><li>Cost of Lost Opportunities </li></ul><ul><li>Cost of Lost Customers </li></ul>Software problems are 100 to 1000 times more costly to find and repair after deployment
  42. 42. Test Dimensions of Quality Reliability Test the application for consistent and predictable behavior. Performance Test online response under average and peak loading. Functionality Test the accurate workings of each usage scenario. Usability Test the application from the perspective of convenience to end-user. Supportability Test the ability to maintain and support the application under production use.
  43. 43. Test Each Iteration UML Model and Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 3 Test Suite 3 Test Suite 4 Iteration 4
  44. 44. Practice 6: Manage Change Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  45. 45. Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. Help Desk User input Coders input Testers input Customer and User input Marketing New Feature New Requirement Bug Approved Decision Process Change Control Board (CCB) Single Channel for Approval Change Request (CR) Reqt Design Code Test Maint Weinberg, ‘95
  46. 46. Manage Change <ul><li>To avoid confusion, have: </li></ul><ul><ul><li>Secure workspaces for each developer </li></ul></ul><ul><ul><li>Automated integration/build management </li></ul></ul><ul><ul><li>Parallel development </li></ul></ul>Workspace Management Process Integration Parallel Development Build Management Configuration Management is more than just check-in and check-out
  47. 47. Manage Change (continued) <ul><li>Unified Change Management (UCM) involves: </li></ul><ul><ul><li>Management across the lifecycle </li></ul></ul><ul><ul><ul><li>System </li></ul></ul></ul><ul><ul><ul><li>Project management </li></ul></ul></ul><ul><ul><li>Activity-based management </li></ul></ul><ul><ul><ul><li>Tasks </li></ul></ul></ul><ul><ul><ul><li>Defects </li></ul></ul></ul><ul><ul><ul><li>Enhancements </li></ul></ul></ul><ul><ul><li>Progress tracking </li></ul></ul><ul><ul><ul><li>Charts </li></ul></ul></ul><ul><ul><ul><li>Reports </li></ul></ul></ul>
  48. 48. Rational Unified Process Implements Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Best Practices Process Made Practical
  49. 49. Achieving Best Practices <ul><li>Iterative approach </li></ul><ul><li>Guidance for activities and artifacts </li></ul><ul><li>Process focus on architecture </li></ul><ul><li>Use cases that drive design and implementation </li></ul><ul><li>Models that abstract the system </li></ul>
  50. 50. A Team-Based Definition of Process <ul><li>A process defines Who is doing What , When , and How , in order to reach a certain goal. </li></ul>New or changed requirements New or changed system Software Engineering Process
  51. 51. Process Structure - Lifecycle Phases <ul><li>The Rational Unified Process has four phases: </li></ul><ul><ul><li>Inception – Define the scope of the project </li></ul></ul><ul><ul><li>Elaboration – Plan the project; specify features and baseline architecture </li></ul></ul><ul><ul><li>Construction – Build the product </li></ul></ul><ul><ul><li>Transition – Transition the product into the end-user community </li></ul></ul>Time Inception Elaboration Construction Transition
  52. 52. Bringing It All Together: The Iterative Approach Disciplines group activities logically. In an iteration, you walk through all disciplines.
  53. 53. Summary <ul><li>Best Practices guide software engineering by addressing root causes. </li></ul><ul><li>Best Practices reinforce each other. </li></ul><ul><li>Process guides a team on who does what, when, and how. </li></ul><ul><li>The Rational Unified Process is a means of achieving Best Practices. </li></ul>

×