›

Giáo trình Công nghệ phần mềm - Bài 1: Các kinh nghiệm quý của Công nghệ Phần mềm

pdf 57 trang huongle 4380
Download
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Công nghệ phần mềm - Bài 1: Các kinh nghiệm quý của Công nghệ Phần mềm", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfgiao_trinh_cong_nghe_phan_mem_bai_1_cac_kinh_nghiem_quy_cua.pdf

Nội dung text: Giáo trình Công nghệ phần mềm - Bài 1: Các kinh nghiệm quý của Công nghệ Phần mềm

  1. Các kinh nghiệm quí của Công nghệ phần mềm Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 1
  2. Mục đích: ? Khám phá các triệu chứng và các nguyên nhân cốt lõi của các vấn đề trong phát triển phần mềm ? Trình bày Rationals 6 kinh nghiệm tốt cho quá trình phát triển phần mềm ? Xem xét cách dùng các kinh nghiệm này để giảI quyết các vấn đề trong phát triển phần mềm Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 2
  3. Phân tích tình hình của CNPM Kinh tế thế giớI ngày Các ứng dụng mơ rộng càng phụ thuộc hơn về kích thước, độ phức vào CNPM tạp, và phân bố Thương trường đòi hỏi nâng Không đủ nhân lực có cao năng suất & chất lượng trình độ và giảm thời gian Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 3
  4. Phát triển phần mềm là công việc tập thể Các thách thức Performance • Các nhóm đông hơn Engineer • Sự chuyên môn hóa Analyst • Phân tán Project Manager • Công nghệ thay đổi Developer quá nhanh Tester Release Engineer Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 4
  5. Chúng ta đã làm việc ra sao ? Performance Engineer • Nhiều thànhAnalyst công Project • Quá nhiều thấtManager bại Tester Release Engineer Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 5
  6. Các triệu chứng của các vấn đề trong PTPM ? Hiểu không đúng những gì người dùng cần ? Không thể thích ứng với các thay đổi về y/c đ/v hệ thống ? Các Module không khớp với nhau ? Phần mềm khó bảo trì và nâng cấp, mở rộng ? Phát hiện trễ các lỗ hổng của dự án ? Chất lượng phần mềm kém ? Hiệu năng của phần mềm thấp ? Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở đâu, tai sao phải thay đổi ? Quá trình build-and-release không đáng tin cậy Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 6
  7. Chữa trị triệu chứng không giải quyết vấn đề Root Causes Symptoms insufficient requirements end-user needs ambiguous communications changing brittle architectures requirements overwhelming modules dont fit complexity hard to maintain undetected inconsistencies late discovery poor testing poor quality subjective poor performance assessment colliding waterfall developers development build-and-release uncontrolled change Diagnose insufficient automation Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 7
  8. Các nguyên nhân chính của các v/đ trong PTPM ? Sự quản lý y/c người dùng không đầy đủ ? Trao đổi thông tin mơ hồ và không đầy đủ ? Kiến trúc không vững chắc ? Độ phức tạp vượt quá tầm kiểm soát ? Có những mâu thuẫn không phát hiện được giữa y/c, thiết kế, và cài đặt ? Kiểm chứng không đầy đủ ? Sự lượng giá chủ quan về tình trạng của dự án ? Sự trễ nải trong việc giảm rủi ro do mô hình thác nước ? Sự lan truyền không thể kiểm soát của các thay đổi ? Thiếu các công cụ tự động hóa Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 8
  9. Các kinh nghiệm giúp giải quyết các vấn đề Nguyên nhân cốt lõi Các kinh nghiệm tốt ? Các y/c không đầy đủ ? Phát triển theo vòng lặp ? Trao đổi thông tin mơ hồ ? Quản trị các y/c ? Kiến trúc kém bền vững ? Sử dụng KT component ? Độ phức tạp quá cao ? Mô hình hóa trực quan ? Các lượng giá chủ quan ? Kiểm định chất lượng ? Các mẫu thuẫn chưa thấy ? Kiểm soát các thay đổi ? Kiểm chứng nghèo nàn ? Q/tr phát triển thác nước ? Sự thay đổi không k/soát ? Thiếu sự tự động hóa Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 9
  10. G/q các nguyên nhân giúp giảm các triệu chứng Symptoms Root Causes Best Practices end-user needs insufficient requirements develop iteratively changing ambiguous manage requirements requirements communications use component modules dont fit brittle architectures architectures hard to maintain overwhelming complexity model the software late discovery undetected visually inconsistencies verify quality poor quality poor performance poor testing control changes subjective assessment colliding developers build-and-release waterfall development uncontrolled change insufficient automation Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 10
  11. Các kinh nghiệm quí của CNPM Phát triển theo vòng lặp Sử dụng Quản trị Kiểm định Quản trị kiến trúc Mô hình hóa Kiểm định Các y/c trực quan chất lượng Các y c Component chất lượng Kiểm soát các thay đổi trong hệ thống Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 11
  12. Các kinh nghiệm tạo ra các nhóm lv hiệu năng cao Kết quả Performance • Nhiều dự án thành Engineer công hơn Analyst Project Manager Developer Develop Iteratively Tester Use Manage Component Model Verify Requirements Architectures Visually Quality Release Engineer Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 12
  13. Kinh nghiệm 1: PTPM theo vòng lặp Develop Iteratively Use Manage Model Verify Component Visually Requirements Architectures Quality Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 13
  14. Kinh nghiệm 1: PTPM theo vòng lặp ? Một thiết kế ban đầu có thể không hoàn chỉnh so với các yêu cầu chính ? Việc phát hiện trễ các thiếu sót trong bản thiết kế sẽ làm tăng giá thành, tốn thời gian và thậm chí làm hủy bỏ dự án $$$ Thời gian và tiền bạc chi ra để cài đặt một thiết kế sai là không thể bù đắp Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 14
  15. Qui trình thác nước truyền thống Requirements Analysis Design Code & Unit Testing Subsystem Testing System Testing T I M E Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 15
  16. Qui trình thác nước có nhiều rủi ro Requirements R Analysis I S Design K Code & Unit Testing Subsystem Testing System Testing T I M E Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 16
  17. Ứ/d QT thác nước theo vòng lặp Iteration 1 Iteration 2 Iteration 3 R R R D D D C C C T T T T I M E ? Các vòng lặp đầu dành cho các v/đ nhiều rủi ro ? Mỗi vòng lặp sinh ra một phiên bản với một sự bổ sung cho hệ thống ? Mỗi VL bao gồm cả việc tích hợp và kiểm chứng Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 17
  18. Qui trình lặp đẩy nhanh việc giảm rủi ro R I S K Iterative Waterfall Iteration Iteration Iteration Iteration Iteration Iteration Iteration T I M E Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 18
  19. Các đặc tính của qui trình lặp ? Các rủi ro chính được giải quyết trước khi có các phát triển lớn ? Các vòng lặp đầu tiên cho phép nhận feedback ? Việc kiểm chứng và tích hợp diễn ra liên tục ? Các cột mốc cục bộ sẽ định ra các tiêu điểm ngắn hạn ? Sự tiến triển được đo bằng bản cài đặt ? Các cài đặt bộ phận có thể triển khai riêng Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 19
  20. Áp dụng các kinh nghiệm trong chu kỳ sống PM Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration & Change Mgmt Project Management Environment Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1 Iterations Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 20
  21. Qui trình lặp giải quyết các vấn đề Nguyên nhân cốt lõi Cách giải quyết ? Không đủ các yêu cầu Nhận và khuyến khích các đ/v hệ thống feedback từ người dùng ? Trao đổi TT mơ hồ Các hiểu lầm nghiêm trọng được làm rõ sớm ? Kiến trúc kém bền vững Tập trung phát triển các khái ? Độ phức tạp quá cao niệm chứa nhiều rủi ro trước ? Đánh giá chủ quan Đánh giá khách quan thông qua ? Các mâu thuẫn không test được phát hiện Mâu thuẫn đc phát hiện sớm ? Kiểm chứng kém ? QT thác nước Bắt đầu test sớm ? Các thay đổi không ks Các rủi ro được xác định và giải quyết sớm ? Thiếu ccụ tự động Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 21
  22. Kinh nghiệm 2: Quản lý yêu cầu đ/v hệ thống Develop Iteratively Use Component Model Verify Manage Visually Quality Requirements Architectures Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 22
  23. Kinh nghiệm 2: Quản lý yêu cầu đ/v hệ thống ? Suy dẫn, tổ chức, và tạo sưu liệu về các yêu cầu chức năng và các ràng buộc ? Lượng giá các thay đổi và xác định ảnh hưởng của chúng ? Theo dấu và tao sưu liệu về các thỏa hiệp & các quyết định Yêu cầu đối với hệ thống luôn động Phải lường trước khả năng chúng bị thay đổi trong quá trình PTPM Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 23
  24. Định nghĩa: Y/c đ/v HT và sự quản lý chúng ? Một yêu cầu là một điều kiện hoặc khả năng mà hệ thống phải tuân theo/có ? Quản lý y/c là một tiếp cận có hệ thống để ?Suy dẫn, tổ chức, và tạo sưu liệu về các yêu cầu chức năng đ/v hệ thống, và ?Thiết lập và duy trì sự thỏa thuận giữa customer/user và project team liên quan đến các thay đổi về yêu cầu đ/v hệ thống Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 24
  25. Thỏa thuận về những gì mà HT phải làm Đích Cộng đồng Hệ thống Các Customer cần xây dựng User Xác minh Surrogate Các yêu cầu Goal Adapted from Al Davis Các yêu cầu Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 25
  26. Y/c ảnh hưởng đến nhiều thành phần khác Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 26
  27. Làm thế nào để bắt được lỗi về y/c sớm ? ? Phân tích vấn đề và suy dẫn ra các nhu cầu của người dùng một cách có hiệu quả ? Đạt được thỏa thuận với customer/user về các yêu cầu đối với hệ thống ? Mô hình hóa sự tương tác giữa user và system ? Thiết lập một đường ranh giới (baseline) và qui trình kiểm soát thay đổi (change control process) ? Duy trì khả năng theo vết tiến và lùi các yêu cầu đ/v hệ thống ? Sử dụng một qui trình lặp Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 27
  28. Các vấn đề giải quyết nhờ quản lý y/c đ/v HT Nguyên nhân cốt lõi Cách giải quyết ? Thiếu các y/c đ/v HT Xây dựng trong quản lý Y/C một tiếp cận kỷ luật ? Trao đổi TT mơ hồ ? Kiến trúc kém bền vững Trao đổi thông tin dựa trên các y/c đã xác định ? Độ phức tạp quá cao Đặt độ ưu tiên, lọc và theo dõi ? Đánh giá chủ quan các yêu cầu ? Các mâu thuẫn không Đánh giá khách quan các được phát hiện chức năng và hiệu năng ? Kiểm chứng kém Các mâu thuẫn đễ phát hiện ? QT thác nước QT thác nước RM tool cung cấp một kho ? Các thay đổi không ks chứa các y/c, thuộc tính và đồ ? Thiếu ccụ tự động hình, sẽ được kết nối tự động với sưu liệu Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 28
  29. Kinh nghiệm 3: Dùng kiến trúc Component-Based Develop Iteratively Manage Use Model Verify Visually Requirements Component Quality Architectures Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 29
  30. Kiến trúc phần mềm xác định: ? Kiến trúc phần mềm chứa đựng các quyết định quan trọng về tổ chức của hệ thống phần mềm ?Sự lựa chọn các phần tử cầu trúc và interface của chúng để cấu thành một hệ thống ?Hành vi được mô tả như sự cộng tác giữa các phần tử này ?Sự tổng hợp của các phẩn tử cấu trúc và hành vi này thành các subsystem lớn hơn ?Kiểu kiến trúc định hướng cho tổ chức này, cho các phần tử cấu trúc và interface của chúng, các công tác, và sự tổng hợp giữa chúng Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 30
  31. Các ảnh hưởng của kiến trúc ? Kiến trúc phần mềm liên quan đến cấu trúc, hành vi và ngữ cảnh (context): ?Cách dùng (Usage) ?Chức năng (Functionality) ?Hiệu năng (Performance) ?Tính co dãn (Resilience) ?Khả năng tái sử dụng (Reuse) ?Tính dễ hiểu (Comprehensibility) ?Các ràng buộc về kinh tế và kỹ thuật và các dung hòa ?Tính thẩm mỹ (Aesthetics) Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 31
  32. Resilient, Component-Based Architectures ? Các kiến trúc tốt thỏa mãn các y/c đ/v chúng, là tính đàn hồi, và component-based ? Một kiến trúc đàn hồi cho phép ?Tăng cường khả năng dễ bảo trì và dễ mở rộng ?Khả năng tái sử dụng với lợi ích kinh tế cao ?Phân chia công việc rõ ràng trong đội ngũ PTPM ?Gói gọn các phụ thuộc phần cứng & hệ thống ? Một kiến trúc component-based cho phép ?Tái sử dụng hoặc tùy chỉnh các component sẵn có ?Chọn lựa giữa hàng ngàn component thương mại trên thị trường ?Tiến hóa không ngừng phần mềm đang tồn tại Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 32
  33. Ví dụ: Component-Based Architecture Lead Tracking Licensing User Interface User Interface User Interface Mechanisms Customer Product License Key: - Purchased Oracle Vantive - Built - New Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 33
  34. Kiến trúc Component giải quyết các vấn đề Các nguyên nhân cốt lõi Cách giải quyết ? Thiếu y/c đ/v hệ thống Các Component dễ tạo ra ? Trao đổi TT mơ hồ các kiến trúc đàn hồi ? Kiến trúc kém bền Tái sử dụng các com. và framework Thương mại trở ? Quá phức tạp nên dễ dàng ? Đánh giá chủ quan Tính đơn thể cho phép phân ? Các mâu thuẫn chưa tách các điều lo lắng xác định ? Test kém Component cung cấp nền ? Qui trình thác nước tảng tự nhiên cho quản lý cấu hình ? Các thay đổi không thể kiểm soát Các ccụ mô hình hóa trực quan hỗ trợ thiết kế tự động ? Thiếu ccụ tự động component-based Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 34
  35. Kinh nghiệm 4: Mô hình hóa trực quan phần mềm Develop Iteratively Use Manage Component Verify Requirements Model Quality Architectures Visually Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 35
  36. Kinh nghiệm 4: Mô hình hóa trực quan phần mềm ? Nắm bắt cấu trúc và hành vi của các thành phần kiến trúc ? Thể hiện cách mà các phần tử hệ thống khớp với nhau ? Che dấu hoặc phơi bày chi tiết theo nhu cầu công việc ? Duy trì tinhd nhất quán giữa thiết kế và cài đặt ? Tăng cường trao đổi thông tin rõ ràng Mô hình hóa trực quan tăng khả năng quản lý độ phức tạp của phần mềm Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 36
  37. UML là gì ? ? Unified Modeling Language (UML) là ngôn ngữ • đặc tả • trực quan hóa • xây dựng • làm sưu liệu các artifact của một hệ thống phần mềm Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 37
  38. Các lược đồ là các khung nhìn của mô hình Một mô hình là một mô tả đầy đủ của hệ thống từ một phối cảnh cụ thể State StateState DiagramsDiagramsStateClass DiagramsDiagramsClass DiagramsDiagrams State use-case StateState use-case DiagramsDiagramsObjectState Activity DiagramsDiagrams DiagramsDiagramsObject Activity DiagramsDiagrams DiagramsDiagrams Scenario State ScenarioScenario StateState DiagramsDiagramsScenarioSequence DiagramsDiagramsStateState DiagramsDiagramsSequence DiagramsDiagramsState DiagramsDiagrams Models DiagramsDiagrams Scenario Component Scenario ComponentComponent DiagramsScenarioScenario DiagramsComponentDiagramsComponent DiagramsCollaborationCollaboration DeploymentDeployment ComponentDiagramsDiagrams DiagramsDiagrams Diagrams DiagramsDiagrams DiagramsDiagrams Diagrams Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 38
  39. Mô hình hóa trực quan dừng các lược đồ UML Use-Case Diagram Class Diagram State Diagram add file DocumentList FileMgr Document add( ) name : int fetchDoc( ) delete( ) docid : int sortByName( ) numField : int add file [ numberOffile==MAX ] / Writing get( ) flag OFF read() fill the open( ) code close( ) FileList read( ) sortFileList( ) Openning fList create( ) use-case 1 fillDocument( ) add( ) delete( ) 1 close file Actor A Actor B close file Reading Closing rep use-case 2 File Repository > (from Persistence) GrpFile read( ) Customer name : char * = 0 read( ) readDoc( ) name open( ) readFile( ) create( ) fillFile( ) addr receive () use-case 3 withdraw () fetch () Domain send() Expert UI Deployment MFC Class Diagram DocumentApp êÈÀ ÀÀ Á à á - Àì 95 : óÀÌ - Àì NT: ÀÀ - À Ó: ÀÀ ÀÌ , IBM- ÀÁÀÓ: ÀÌ , RogueWave DocumentList Windows95 Repository Window 95 9:sortByName( ) Persistence Windows95 global óÀÌ . EXE FileManager à mainWnd : MainWnd Windows NT 1:Doc view request () User Interface L Document Solaris 2:fetchDoc ( ) Package Á. EXE Definition 4: create )( gFile : GrpFile Alpha 8:fillFile() UNIX ÀÀ. EXE Windows NT user : ÀÚ Diagram GraphicFile IBM fileMgr : FileMgr Mainframe 3: create )( File FileList 6:fillDocument() ÀÌÀÌ 7:readFile( ) 5:readDoc ( ) document : Document repository : Repository Component Forward Engineering (Code Generation) Collaboration Diagram Diagram and Reverse Engineering mainWnd fileMgr : document : gFile repository user FileMgr Document Á â 1:Doc view request () ÀÚ ÃÙ. 2:fetchDoc ( ) 3: create )( Source Code edit, compile, debug, link 4: create )( 5:readDoc ( ) ÈÀÀÚ À 6:fillDocument() À Á à ÁÀ ÃÙ. 7:readFile( ) 8:fillFile() Èé àÀéÀ 9:sortByName( ) Ãé ÀÌ ÁÀ à Èé ÁÙ. Sequence Diagram Executable System Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 39
  40. Mô hình hóa trực quan và phát triển theo vòng lặp Yêu cầu ban đầu risk targeting Đánh giá requirements analysis & design implementation & testing deployment Thay đổi bản thiết kế ? Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 40
  41. Mô hình hóa trực quan và phát triển theo vòng lặp Yêu cầu ban đầu risk targeting Đánh giá requirements analysis & design implementation & testing deployment Cái gì thay đổi? Những thay đổi này được phép không? Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 41
  42. Giải quyết vấn đề nhờ mô hình hóa trực quan Các nguyên nhân cốt lõiLời giải Các use-case và scenario ? Thiếu y/c đ/v HT Các use case và scenario đặc tả hành vi rõ ràng ? Truyền tin mơ hồ Các mô hình nắm bắt tường ? Kiến trúc kém bền minh các thiết kế ? Quá phức tạp Các kiến trúc không đơn thể ? Đánh giá chủ quan hay cứng nhắc bị phơi bày ? Các mâu thuẫn chưa Các chi tiết không cần thiết xác định được che dấu khi cần ? Test kém Các thiết kế tường minh chỉ ra các mâu thuẫn dễ dàng ? Qui trình thác nước các mâu thuẫn dễ dàng Chất lượng của ứng dụng đi kèm ? Thay đổi không thể KS Chất lượng của ứng dụng đi kèm với bản thiết kế tốt ? Thiếu ccụ tự động Thiếu ccụ tự động Các ccụ trực quan hỗ trợ cho mô hình hóa bằng UML Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 42
  43. Kinh nghiệm 5: Kiểm định chất lượng phần mềm Develop Iteratively Use Model Manage Component Requirements Visually Verify Architectures Quality Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 43
  44. Kinh nghiệm 5: Kiểm định chất lượng phần mềm Chi phí tìm kiếm và sửa chữa các vấn đề của phần mềm sẽ tăng hàng 100, hàng 1000 lần sau khi PT Cost Development Deployment Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 44
  45. PT theo vòng lặp cho phép test liên tục Iteration 1 Iteration 2 Iteration 3 R R R D D D C C C T T T Test Test Test T I M E Plan Plan Plan Design Design Design Test Implement Implement Implement Life Execute Execute Execute Cycle Evaluate Evaluate Evaluate Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 45
  46. Test trong một môi trường PT theo vòng lặp Iteration 1 Iteration 2 Iteration 3 Iteration 4 Requirements Requirements Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 Tests Tests Automated Automated Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 46
  47. Tự động hóa giảm thời gian và công sức test MộtOnechuManualtrình testTestthủCyclecông 13,00013,000 lần TestsTest 2 Weeks2 Tuần 6 People6 Người Test tự động 13,000 Test 13,000 Test Ch?y ngày càng nhi?u test hon 66 giờ giờ 11 người người Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 47
  48. Các khía cạnh của chất lượng phần mềm Kiểu Tại sao? Thế nào? Chức năng Ư/d của tôi có làm những gì Tạo cácTest case cho mỗi được yêu cầu? scenario đã cài đặt Độ tin cậy Ư/d của tôi có làm mất bộ Các công cụ phân tích và nhớ? các thiết bị coding Hiệu năng ứng Ư/d của tôi có hồi đáp hợp Kiểm tra hiệu năng của mỗi dụng lệ? use-case/scenario đã cài đặt Kiểm tra hiệu năng của tất Hiệu năng của Ư/d của tôi có hoạt động cả use-case ở mức độ tin hệ thống dưới công suất thiết kế? cậy và trường hợp xấu nhất Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 48
  49. Các vấn đề được giải quyết nhờ kiểm định CL Nguyên nhân cốt lõi Cách giải quyết ? Thiếu y/c đ/v HT Testing đánh giá khách quan ? Truyền tin mơ hồ về trạng thái dự án ? Kiến trúc kém bền Đánh giá khách quan triệt ? Quá phức tạp tiêu các mâu thuần sớm ? Đánh giá chủ quan Đánh giá chủ quan Testing và kiểm định tập ? Các mâu thuẫn chưa trung vào vùng high risk được xác định ? Test kém Tìm thấy thiếu sót sớm và chi phí sửa chữa thấp ? Qui trình thác nước ? Thay đổi không thể KS Các ccụ test tự động giúp , ? Thiếu ccụ tự động test độ tin cậy, chức năng và hiệu năng Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 49
  50. Kinh nghiệm 6: Kiểm soát thay đổi trong PM Develop Iteratively Use Manage Model Verify Component Visually Requirements Architectures Quality Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 50
  51. Kinh nghiệm 6: Kiểm soát thay đổi trong PM ? Nhiều developer ? Nhiều team ? Nhiều vị trí ? Nhiều vòng lập ? Nhiều release ? Nhiều project ? Nhiều platform Thiếu sự kiểm soát tường minh, đầy đủ Phát triển song song dễ biến thành hỗn độn Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 51
  52. Ba khía cạnh chính của CM System Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 52
  53. Các khái niệm của Configuration & Change M. ? Phân rã kiến trúc thành các subsystem và gán trách nhiệm thực hiện các subsystem cho mỗi nhóm ? Thiết lập vùng làm việc an toàn cho mỗi developer ?Cho phép cô lập với các thay đổi tạo bởi vùng làm việc khác ?Kiểm soát tất cả software artifact - models, code, docs, ? Thiết lập một vùng làm việc tích hợp ? Thiết lập một cơ chế khả thi kiểm soát các thay đổi ? Nắm bắt thay đổi xuất hiện nào xuất hiện trong release nào ? Đưa ra một đường ranh giới hạn chỗ hoàn tất của mỗi vòng lặp Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 53
  54. Change Control hỗ trợ tất cả Best Practices khác ? Phát triển theo ? Dự án chỉ tiến triển khi các thay qui trình lặp đổi được kiểm soát ? Quản lý Y/c ? Để loại bỏ sự dãn phạm vị, đánh giá ảnh hưởng của mọi thay đổi dự kiến trước khi chấp nhận ? Dùng kiến trúc Dùng kiến trúc ? Các Component phải đáng tin cậy, component Các Component phải đáng tin cậy component i.e., tìm thấy phiên bản đúng đắn của tất cả các phần hợp thành ? Mô hình hóa trực ? Để bảo đảm sự hội tụ, phải tăng quan quan dần kiểm soát các model khi các thiết kế ổn định ? Kiểm định chất ? Test chỉ có ý nghĩa nếu các version lượng các phần tử đang test được biết rõ và các phần tử được bỏa vệ trước các thay đổi Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 54
  55. Các vần đề được giải quyết nhờ Control Change Nguyên nhân cốt lõi Cách giải quyết Requirements change workflow được ? Thiếu y/c đ/v HT xác định và lặp lại đi lặp lại ? Truyền tin mơ hồ Các Change request làm cho thông ? Kiến trúc kém bền tin trao đổi rõ ràng Vùng làm việc biệt lập giảm các trở ? Quá phức tạp ngại do làm việc song song ? Đánh giá chủ quan Thống kê về mức độ thay đổi là độ đo tốt cho các đánh giá khách quan ? Mâu thuẫn chưa được về trạng thái của dự án xác định Vùng làm việc chứa tất cả các ? Test kém artifact dễ tạo sự nhất quán ? Qui trình thác nước Kiểm soát được sự lan truyền các thay đổi ? Thay đổi không thể Các thay đổi được duy trì trong một kiểm soát hệ thống mạnh mẽ, có khả năng tùy chỉnh ? Thiếu ccụ tự động Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 55
  56. Các kinh nghiệm hỗ trợ lẫn nhau Ensures users involved Manage as requirements evolve Requirements Validates architectural Use decisions early on Component Architectures Develop Addresses complexity of Model Visually Iteratively design/implementation incrementally Measures quality early and often Verify Quality Evolves baselines incrementally Control Changes Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 56
  57. Tổng kết ? Kết quả là phần mềm trở nên ?Đúng thời hạn ?Bảo đảm ngân sách Performance Engineer ?Thỏa mãn nhu cầu userAnalyst Project Develop Iteratively Manager Developer Use Model Manage Component Visually Verify Requirements Quality Architectures Tester Control Changes Release Engineer Các kinh nghi?m quí trong CNPM Duong Anh Ð?c 57