Các kinh nghiệm quí của Công nghệ phần mềm

Công cụ môi trường phát triển phần mềm 1 Các kinh nghiệm quí của Công nghệ phần mềm Công cụ và môi trường phát triển phần mềm Công cụ môi trường phát triển phần mềm 2 Mục đích w 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 w Trình bày 6 kinh nghiệm tốt của Rational trong quá trình phát triển phần mềm w Xem xét cách sử 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ông cụ môi trường phát triển phần mềm 3 Phân tích tình hình của CNPM Kinh tế thế giới ngày càng phụ thuộc hơn vào CNPM Các ứng dụng mở rộng về kích thước, độ phức tạp, và phân bố Thương trường đòi hỏi nâng cao năng suất, chất lượng và giảm thời gian Không đủ nhân lực có trình độ Công cụ môi trường phát triển phần mềm 4 Phát triển phần mềm là công việc tập thể Project Manager Performance Engineer Release Engineer Analyst Developer Tester Các thách thức • Các nhóm đông hơn • Sự chuyên môn hóa • Phân tán • Công nghệ thay đổi quá nhanh Công cụ môi trường phát triển phần mềm 5 • Nhiều thành công • Quá nhiều thất bại Chúng ta đã làm việc ra sao? Project Manager Performance Engineer Release Engineer Analyst Tester Developer Công cụ môi trường phát triển phần mềm 6 Các triệu chứng của các vấn đề trong phát triển PM w Hiểu không đúng những gì người dùng cần w Không thể thích ứng với các thay đổi về yêu cầu của hệ thống w Các Module không khớp với nhau w Phần mềm khó bảo trì và nâng cấp, mở rộng w Phát hiện trễ các lỗ hổng của dự án w Chất lượng phần mềm kém w Hiệu năng của phần mềm thấp w Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở đâu, tại sao phải thay đổi w Quá trình build-and-release không đáng tin cậy Công cụ môi trường phát triển phần mềm 7 Symptoms end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automationDiagnose Chữa trị triệu chứng không giải quyết hết vấn đề Công cụ môi trường phát triển phần mềm 8 Các nguyên nhân chính w Sự quản lý yêu cầu người dùng không đầy đủ w Trao đổi thông tin mơ hồ và không đầy đủ w Kiến trúc không vững chắc w Độ phức tạp vượt quá tầm kiểm soát w Có những mâu thuẫn không phát hiện được giữa yêu cầu, thiết kế, và cài đặt w Kiểm chứng không đầy đủ w Sự lượng giá chủ quan về tình trạng của dự án w Sự chậm trễ trong việc giảm rủi ro do mô hình thác nước w Sự lan truyền không thể kiểm soát của các thay đổi w Thiếu các công cụ tự động hóa Công cụ môi trường phát triển phần mềm 9 þ Các yêu cầu không đầy đủ þ Trao đổi thông tin mơ hồ þ Kiến trúc kém bền vững þ Độ phức tạp quá cao þ Các lượng giá chủ quan þ Các mâu thuẫn chưa thấy þ Kiểm chứng nghèo nàn þ Qui trình phát triển thác nước þ Sự thay đổi không kiểm soát þ Thiếu sự tự động hóa þ Phát triển theo vòng lặp þ Quản trị các yêu cầu þ Sử dụng kiến trúc component þ Mô hình hóa trực quan þ Kiểm định chất lượng þ Kiểm soát các thay đổi Nguyên nhân cốt lõi Các kinh nghiệm tốt Các kinh nghiệm giúp giải quyết các vấn đề Công cụ môi trường phát triển phần mềm 10 Symptoms end-user needs changing requirements modules don’t fit hard to maintain late discovery poor quality poor performance colliding developers build-and-release Root Causes insufficient requirements ambiguous communications brittle architectures overwhelming complexity undetected inconsistencies poor testing subjective assessment waterfall development uncontrolled change insufficient automation Best Practices develop iteratively manage requirements use component architectures model the software visually verify quality control changes Giải quyết các nguyên nhân giúp giảm các triệu chứng Công cụ môi trường phát triển phần mềm 11 Phát triển theo vòng lặp Kiểm soát các thay đổi trong hệ thống Sử dụng kiến trúc Component Quản trị các yêu cầu Mô hình hóa trực quan Kiểm định chất lượng Các kinh nghiệm quí của CNPM Công cụ môi trường phát triển phần mềm 12 Các kinh nghiệm tạo ra các nhóm làm việc hiệu năng cao Project Manager Performance Engineer Release Engineer Analyst Developer Tester Kết quả • Nhiều dự án thành công hơn Kiểm soát các thay đổI trong hệ thống Phát triển theo vòng lặp Sử dụng kiến trúc Component Quản trị các yêu cầu Mô hình hóa trực quan Kiểm định chất lượng Công cụ môi trường phát triển phần mềm 13 Kinh nghiệm 1: Phát triển phần mềm theo vòng lặp Phát triển theo vòng lặp Kiểm soát các thay đổi trong hệ thống Sử dụng kiến trúc Component Quản trị các yêu cầu Mô hình hóa trực quan Kiểm định chất lượng Công cụ môi trường phát triển phần mềm 14 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 Kinh nghiệm 1: Phát triển phần mềm theo vòng lặp(tt) w 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 w 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 Công cụ môi trường phát triển phần mềm 15 T I M E Qui trình thác nước truyền thống Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis Công cụ môi trường phát triển phần mềm 16 R I S K T I M E Qui trình thác nước có nhiều rủi ro Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis Công cụ môi trường phát triển phần mềm 17 Ứng dụng qui trình thác nước theo vòng lặp w Các vòng lặp đầu dành cho các vấn đề nhiều rủi ro w 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 w Mỗi vòng lặp bao gồm cả việc tích hợp và kiểm chứng T C D R T I M E Iteration 1 Iteration 2 Iteration 3 T C D R T C D R Công cụ môi trường phát triển phần mềm 18 Qui trình lặp đẩy nhanh việc giảm rủi ro WaterfallIterative R I S K T I M E Iteration Iteration Iteration Iteration Iteration Iteration Iteration Công cụ môi trường phát triển phần mềm 19 Các đặc tính của qui trình lặp w Các rủi ro chính được giải quyết trước khi có các phát triển lớn w Các vòng lặp đầu tiên cho phép nhận feedback w Việc kiểm chứng và tích hợp diễn ra liên tục w Các cột mốc cục bộ sẽ định ra các tiêu điểm ngắn hạn w Sự tiến triển được đo bằng bản cài đặt w Các cài đặt bộ phận có thể triển khai riêng Công cụ môi trường phát triển phần mềm 20 Áp dụng các kinh nghiệm trong chu kỳ sống của PM Công cụ môi trường phát triển phần mềm 21 Nhận và khuyến khích các feedback từ người dùng Các hiểu lầm nghiêm trọng được làm rõ sớm Tập trung phát triển các khái niệm chứa nhiều rủi ro trước Đánh giá khách quan thông qua test Mâu thuẫn đc phát hiện sớm Bắt đầu test sớm Các rủi ro được xác định và giải quyết sớm 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 đốI với hệ thống þ Trao đổi thông tin mơ hồ ¨ Kiến trúc kém bền vững þ Độ phức tạp quá cao þ Đánh giá chủ quan þ Các mâu thuẫn không được phát hiện þ Kiểm chứng kém þ Qui trình thác nước ¨ Các thay đổi không kiểm soát ¨ Thiếu công cụ tự động Công cụ môi trường phát triển phần mềm 22 Kinh nghiệm 2: Quản lý yêu cầu đốI với hệ thống Phát triển theo vòng lặp Quản trị các yêu cầu Kiểm soát các thay đổi trong hệ thống Sử dụng kiến trúc Component Mô hình hóa trực quan Kiểm định chất lượng Công cụ môi trường phát triển phần mềm 23 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 phát triển phần mềm Kinh nghiệm 2: Quản lý yêu cầu đối với hệ thống(tt) w 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 w Lượng giá các thay đổi và xác định ảnh hưởng của chúng w Theo dấu và tao sưu liệu về các thỏa hiệp & các quyết định Công cụ môi trường phát triển phần mềm 24 Định nghĩa: Yêu cầu đối với HT và sự quản lý chúng w 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ó w Quản lý yêu cầu 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 đối với 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 đối với hệ thống Công cụ môi trường phát triển phần mềm 25 Thỏa thuận về những gì mà hệ thống phải làm Đích Surrogate Goal Xác minh Các yêu cầu Cộng đồng Các Customer User Các yêu cầu Hệ thống cần xây dựng Adapted from Al Davis Công cụ môi trường phát triển phần mềm 26 Yêu cầu ảnh hưởng đến nhiều thành phần khác Công cụ môi trường phát triển phần mềm 27 Làm thế nào để bắt được lỗi về yêu cầu sớm? w 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ả w Đạt được thỏa thuận với customer/user về các yêu cầu đối với hệ thống w Mô hình hóa sự tương tác giữa user và system w Thiết lập một đường ranh giới (baseline) và qui trình kiểm soát thay đổi (change control process) w Duy trì khả năng theo vết tiến và lùi các yêu cầu đốI với hệ thống w Sử dụng một qui trình lặp Công cụ môi trường phát triển phần mềm 28 Các vấn đề giải quyết nhờ quản lý yêu cầu đối với HT Nguyên nhân cốt lõi Cách giải quyết Xây dựng trong quản lý Y/C một tiếp cận kỷ luật Trao đổi thông tin dựa trên các y/c đã xác định Đặt độ ưu tiên, lọc và theo dõi các yêu cầu Đánh giá khách quan các chức năng và hiệu năng Các mâu thuẫn đễ phát hiện RM tool cung cấp một kho chứa các y/c, thuộc tính và đồ hình, sẽ được kết nối tự động với sưu liệu þ Thiếu các y/c đ/v HT þ Trao đổi TT mơ hồ ¨ Kiến trúc kém bền vững þ Độ phức tạp quá cao þ Đánh giá chủ quan þ Các mâu thuẫn không được phát hiện þ Kiểm chứng kém ¨ QT thác nước ¨ Các thay đổi không ks þ Thiếu ccụ tự động Công cụ môi trường phát triển phần mềm 29 Kinh nghiệm 3: Dùng kiến trúc Component-Based Phát triển theo vòng lặp Quản trị các yêu cầu Sử dụng kiến trúc Component Kiểm soát các thay đổi trong hệ thống Mô hình hóa trực quan Kiểm định chất lượng Công cụ môi trường phát triển phần mềm 30 Kiến trúc phần mềm xác định: w 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ông cụ môi trường phát triển phần mềm 31 Các ảnh hưởng của kiến trúc w 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ông cụ môi trường phát triển phần mềm 32 Resilient, Component-Based Architectures w Các kiến trúc tốt thỏa mãn các yêu cầu đối với chúng, là tính đàn hồi, và component-based w 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ũ phát triển phần mềm § Gói gọn các phụ thuộc phần cứng & hệ thống w 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ông cụ môi trường phát triển phần mềm 33 Ví dụ: Component-Based Architecture Key: - Purchased - Built - New User Interface Mechanisms Oracle Vantive Customer Product Lead Tracking User Interface License Licensing User Interface Công cụ môi trường phát triển phần mềm 34 Kiến trúc Component giải quyết các vấn đề Các Component dễ tạo ra các kiến trúc đàn hồi Tái sử dụng các com. và framework Thương mại trở nên dễ dàng Tính đơn thể cho phép phân tách các điều lo lắng Component cung cấp nền tảng tự nhiên cho quản lý cấu hình Các ccụ mô hình hóa trực quan hỗ trợ thiết kế tự động component-based Các nguyên nhân cốt lõi Cách giải quyết ¨ Thiếu y/c đ/v hệ thống ¨ Trao đổi TT mơ hồ þ Kiến trúc kém bền þ Quá phức tạp ¨ Đánh giá chủ quan ¨ Các mâu thuẫn chưa xác định ¨ Test kém ¨ Qui trình thác nước þ Các thay đổi không thể kiểm soát þ Thiếu ccụ tự động Công cụ môi trường phát triển phần mềm 35 Kinh nghiệm 4: Mô hình hóa trực quan phần mềm Phát triển theo vòng lặp Quản trị các yêu cầu Mô hình hóatrực quan Kiểm soát các thay đổi trong hệ thống Sử dụng kiến trúc Component Kiểm định chất lượng Công cụ môi trường phát triển phần mềm 36 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 Kinh nghiệm 4: Mô hình hóa trực quan phần mềm(tt) w Nắm bắt cấu trúc và hành vi của các thành phần kiến trúc w Thể hiện cách mà các phần tử hệ thống khớp với nhau w Che dấu hoặc phơi bày chi tiết theo nhu cầu công việc w Duy trì tính nhất quán giữa thiết kế và cài đặt w Tăng cường trao đổi thông tin rõ ràng Công cụ môi trường phát triển phần mềm 37 UML là gì? w 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ông cụ môi trường phát triển phần mềm 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ể Deployment Diagrams Deployment Diagrams use-case Diagrams use-case Diagrams Scenario Diagrams Scenario DiagramsScenario Diagrams Scenario DiagramsSequence Diagrams Sequence Diagrams State Diagrams State DiagramsState Diagrams State DiagramsState Diagrams State Diagrams Component Diagrams Component DiagramsComponent Diagrams Component DiagramsComponent Diagrams Co ponent Diagrams Models State Diagrams State DiagramsState Diagrams State DiagramsObject Diagrams Object Diagrams Scenario Diagrams Scenario DiagramsScenario Diagrams Scenario DiagramsCollaboration Diagrams Collaboration Diagrams Activity Diagrams Activity Diagrams State Diagrams State DiagramsState Diagrams State DiagramsClas Diagrams Clas Diagrams Công cụ môi trường phát triển phần mềm 39 Mô hình hóa trực quan dùng các lược đồ UML Actor A use-case 1 use-case 2 Actor B user : »ç¿ëÀÚ mainWnd : MainWnd fileMgr : FileMgr repository : Repository document : Document gFile : GrpFile 9: sortByN ame ( ) L 1: Doc view request ( ) 2: fetchDoc( ) 5: readDoc ( ) 7: readFile ( ) 3: create ( ) 6: fillDocument ( ) 4: create ( ) 8: fillFile ( ) GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) fList 1 FileList add( ) delete( ) File read( ) read() fill the code.. UI MFC RogueWave global DocumentApp Persistence Wi ndow95 ¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Wi ndows NT ¹®¼-°ü¸® ¿£Áø.EXE Wi ndows NT Wi ndows95 Solaris ÀÀ¿ë¼-¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼- ¹ö Wi ndows95 ¹®¼-°ü¸® ¾ÖÇ Ã¸´ ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾ î¹× ³× Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½ ýºÅÛ ¿¬°á ¸ 𵨠- À©µµ¿ì 95 : Ŭ¶óÀ̾ ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼-¹ ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹ × µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ ö, Åë½ Å ¼-¹ö Document FileManager GraphicFile File Repository DocumentList FileList user mainWnd fileMgr : FileMgr repositorydocument : Document gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByN ame ( ) ƯÁ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äÃ»Ç Ñ´Ù. È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼- °´Ã¼¿¡ ¼ ³Á¤À» ¿äÃ»Ç Ñ´Ù. È-¸é °´Ã¼ ´Â ÀÐ ¾îµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ ÃÄÑ È- ¸é¿¡ º¸¿©ÁØ´ Ù. Customer name addr withdraw() fetch() send() receive() > Forward Engineering (Code Generation) and Reverse Engineering Executable System User Interface Definition Domain Expert Openning Writing Reading Closing add file [ numberOffile==MAX ] / flag OFF add file close file close file use-case 3 Source Code edit, compile, debug, link Use-Case Diagram Class Diagram Collaboration Diagram Sequence Diagram Component Diagram State Diagram Package Diagram Deployment DiagramClass Công cụ môi trường phát triển phần mềm 40 Thay đổi bản thiết kế? Mô hình hóa trực quan và phát triển theo vòng lặp Yêu cầu ban đầu implementation & testing risk targeting deployment Đánh giá requirements analysis & design Công cụ môi trường phát triển phần mềm 41 Cái gì thay đổi? Những thay đổi này được phép không? Mô hình hóa trực quan và phát triển theo vòng lặp Yêu cầu ban đầu implementation & testing risk targeting deployment Đánh giá requirements analysis & design Công cụ môi trường phát triển phần mềm 42 Giải quyết vấn đề nhờ mô hình hóa trực quan Các use-case và scenario đặc tả hành vi rõ ràng Các mô hình nắm bắt tường minh các thiết kế Các kiến trúc không đơn thể hay cứng nhắc bị phơi bày Các chi tiết không cần thiết được che dấu khi cần Các thiết kế tường minh chỉ ra các mâu thuẫn dễ dàng Chất lượng của ứng dụng đi kèm với bản thiết kế tốt Các ccụ trực quan hỗ trợ cho mô hình hóa bằng UML Các nguyên nhân cốt lõi Lời giải þ Thiếu y/c đ/v HT þ Truyền tin mơ hồ þ Kiến trúc kém bền þ Quá phức tạp ¨ Đánh giá chủ quan þ Các mâu thuẫn chưa xác định þ Test kém ¨ Qui trình thác nước ¨ Thay đổi không thể KS þ Thiếu ccụ tự động Công cụ môi trường phát triển phần mềm 43 Kinh nghiệm 5: Kiểm định chất lượng phần mềm Phát triển theo vòng lặp Quản trị các yêu cầu Kiểm định chất lượng Kiểm soát các thay đổi trong hệ thống Sử dụng kiến trúc Component Mô hình hóa trực quan Công cụ môi trường phát triển phần mềm 44 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 trăm, hàng ngàn lần sau khi phát triển Development Deployment Cost Kinh nghiệm 5: Kiểm định chất lượng phần mềm (tt) Công cụ môi trường phát triển phần mềm 45 Phát triển theo vòng lặp cho phép test liên tục T I M E Test Test Test T C D R Iteration 1 Iteration 2 Iteration 3 T C D R T C D R Test Life Cycle Evaluate Plan Design Implement Execute Evaluate Plan Design Implement Execute Evaluate Plan Design Implement Execute Công cụ môi trường phát triển phần mềm 46 Test trong một môi trường phát triển theo vòng lặp R eq ui re m en ts R eq ui re m en ts Test Suite 1 Iteration 2 Iteration 3 Iteration 4 Test Suite 2 Test Suite 3 Test Suite 4 Iteration 1 Au to m at ed T es ts Au to m at ed T es ts Công cụ môi trường phát triển phần mềm 47 Tự động hóa giảm thời gian và công sức test One Manual Test Cycle 13,000 Tests 2 Weeks 6 People 13,000 Test 6 giờ 1 người 13,000 Test 6 giờ 1 người Một chu trình test hủ ông 13,000 lần Test 2 Tuần 6 Người Test tự động Chạy ngày càng nhiều test hơn Công cụ môi trường phát triển phần mềm 48 Các khía cạnh của chất lượng phần mềm Chức năng Độ tin cậy Hiệu năng ứng dụng Hiệu năng của hệ thống Ứng dụng của tôi có làm những gì được yêu cầu? Ứng dụng của tôi có làm mất bộ nhớ? Ứng dụng của tôi có hồi đáp hợp lệ? Ứng dụng của tôi có hoạt động dưới công suất thiết kế? Tạo cácTest case cho mỗi scenario đ