PHÂN TÍCH THIẾT KẾ HỆ THỐNG - Ppt Download - SlidePlayer

Có thể bạn quan tâm

Presentation on theme: "PHÂN TÍCH THIẾT KẾ HỆ THỐNG"— Presentation transcript:

1 PHÂN TÍCH THIẾT KẾ HỆ THỐNGSDLC, Agile Modeling And Prototyping GVDH : Nguyễn Thanh Tùng Hồ Ngọc Thạch Nguyễn Tiến Tùng Nguyễn Trần Phước Bình

2 Nội Dung Agile Modeling And PrototypingSoftware Development Life Cycle (SDLC) Agile Modeling And Prototyping

3 SDLC (Systems Development Life Cycle)SDLC là cách tiếp cận theo từng giai đoạn để phân tích và thiết kế một hệ thống thông tin tốt nhất thông qua hoạt động của người dùng

4 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S D L C 7. Hiện thực và đánh giá hệ thống. 4. Thiết kế hệ thống được đề xuất. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

5 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S L C D 7. Hiện thực và đánh giá hệ thống. 4. Thiết kế hệ thống được đề xuất. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

6 Xác Định Vấn Đề, Cơ Hội Của Mục TiêuCác nhà phân tích cần phải quan sát nhìn nhận một cách chân thực những gì đang xảy ra tại một công ty, doanh nghiệp. Sau đó, cùng với các thành viên trong tổ chức doanh nghiệp, các nhà phân tích xác định chính xác vấn đề. Analyst Member Identify Problems 1 2 3 4 5 6 7

7 Xác Định Vấn Đề, Cơ Hội Và Mục TiêuCơ hội là những trường hợp mà các nhà phân tích tin rằng các vấn đề có thể được cải thiện thông qua việc sử dụng các hệ thống thông tin máy tính. Nắm bắt cơ hội có thể cho phép các doanh nghiệp đạt được một lợi thế cạnh tranh, hoặc thiết lập một tiêu chuẩn công nghiệp. What business is trying to do? 1 2 3 4 5 6 7

8 Xác Định Vấn Đề, Cơ Hội Và Mục Tiêu+ Trước hết các nhà phân tích cần phải tìm hiểu xem những việc mà doanh nghiệp đang cố gắng làm. + Sau đó, các nhà phân tích có thể xem xét một số khía cạnh của hệ thống thông tin ứng dụng để có thể giúp các doanh nghiệp đạt được mục tiêu của mình. What business is trying to do? 1 2 3 4 5 6 7

9 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S L C D 7. Hiện thực và đánh giá hệ thống. 4. Thiết kế hệ thống được đề xuất. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

10 Xác Định Yêu Cầu Thông Tin Con NgườiCác nhà phân tích sử dụng các phương pháp giao tiếp như: phỏng vấn, lấy mẫu, điều tra dữ liệu cứng, bảng câu hỏi, phương pháp không phô trương → Trả lời các câu hỏi liên quan đến tương tác giữa con người và máy tính (HCI): + Điểm mạnh và điểm yếu về thể trạng của người dùng là gì? + Cần phải làm gì để xây dựng một hệ thống an toàn và dễ sử dụng? Cách thiết kế như thế nào? + Làm thế nào để hệ thống có thể hỗ trợ cho nhiệm vụ, công việc cá nhân của từng người dùng theo những cách thức mới một cách hiệu quả? + Làm thế nào hệ thống mới có thể được tạo ra để mở rộng khả năng của người dùng vượt qua những gì mà hệ thống cũ cung cấp? 1 2 3 4 5 6 7

11 Xác Định Yêu Cầu Thông Tin Con NgườiCác nhà phân tích cần phải nắm rõ chi tiết chức năng của hệ thống hiện tại: + Who – những người có liên quan đến hệ thống? + What – hoạt động của doanh nghiệp? + Where – môi trường công việc diễn ra? + When – thời gian là khi nào? + How – các thủ tục hiện hành được hiện thực như thế nào? 1 2 3 4 5 6 7

12 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S D L C 4. Thiết kế hệ thống được đề xuất. 7. Hiện thực và đánh giá hệ thống. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

13 Phân Tích Yêu Cầu Hệ Thống* Công cụ kỹ thuật dùng để phân tích: Một trong những công cụ kỹ thuật giúp các nhà phân tích phân tích yêu cầu của hệ thống là: Data Flow Diagram (DFD) Data Flow Diagrams Data Dictionary Chart DFD Tool Analyst use 1 2 3 4 5 6 7

14 Phân Tích Yêu Cầu Hệ Thống* Phân tích “Ra quyết định có cấu trúc” – “Structured decisions made”: Quyết định có cấu trúc: + Điều kiện - Condition + Điều kiện lựa chọn thay thế - Condition alternatives + Hành động – Action + Quy tắc hành động – Action rules 1 2 3 4 5 6 7

15 Phân Tích Yêu Cầu Hệ Thống* Phân tích “Ra quyết định có cấu trúc” – “Structured decisions made”: Có 3 phương pháp để phân tích quyết định có cấu trúc: cấu trúc tiếng anh, bảng quyết định, cây quyết định. 1 2 3 4 5 6 7

16 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S D L C 7. Hiện thực và đánh giá hệ thống. 4. Thiết kế hệ thống được đề xuất. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

17 Thiết Kế Hệ Thống Được Đề XuấtCác nhà phân tích sử dụng các thông tin thu thập được trước đó để hoàn thành việc thiết kế luận lý(logical design) của hệ thống. Người dùng nhập dữ liệu vào hệ thống theo những thủ tục, kỹ thuật sử dụng form, các trang web do nhà phân tích thiết kế và cung cấp. Thiết kế giao diện HCI (Human – Computer Interaction) với hệ thống âm thanh rõ rang, an toàn và dễ sử dụng. 1 2 3 4 5 6 7

18 Thiết Kế Hệ Thống Được Đề XuấtThiết kế cơ sở dữ liệu để lưu trữ những dữ liệu cần thiết bởi những người quyết định trong tổ chức. Các nhà phân tích cũng cần phải làm việc với user để thiết kế output, đáp ứng nhu cầu thông tin của họ. Thiết kế cách kiểm soát và sao lưu dữ liệu để bảo vệ hệ thống. 1 2 3 4 5 6 7

19 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S D L C 4. Thiết kế hệ thống được đề xuất. 7. Hiện thực và đánh giá hệ thống. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

20 Phát Triển Và Lập Tài Liệu Về Phần Mềm* Phát triển phần mềm: Các nhà phân tích sẽ làm việc cùng với người lập trình viên để phát triển bất cứ một phần mềm gốc nào nếu cần thiết. Người lập trình có vài trò rất quan trọng vì công việc của họ là thiết kế, code, sửa lỗi cú pháp trong chương trình máy tính. Ngoài ra để đảm bảo chất lượng, người lập trình sẽ phải thiết kế, hướng dẫn, giải thích các phần phức tạp trong chương trình cho các thành viên khác trong team của họ. Software + develop 1 2 3 4 5 6 7

21 Phát Triển Và Lập Tài Liệu Về Phần Mềm- Các nhà phân tích sẽ cùng với người sử dụng xây dựng tài liệu cho phần mềm bao gồm quy trình hướng dẫn, trợ giúp trực tuyến, các trang Web với những câu hỏi thường gặp (FAQs)… Tài liệu phải giải quyết được những vấn đề mà người sử dụng nêu lên. Dựa trên tài liệu về phần mềm, người sử dụng sẽ biết cách sử dụng phần mềm như thế nào và nên làm gì khì phần mềm bị lỗi. 1 2 3 4 5 6 7

22 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S D L C 4. Thiết kế hệ thống được đề xuất. 7. Hiện thực và đánh giá hệ thống. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

23 Kiểm Tra Và Bảo Trì Hệ Thống* Kiểm tra hệ thống: Hệ thống thông tin cần phải được kiểm tra trước khi đưa vào sử dụng. Được thực hiện bởi người lập trình viên, hoặc các nhà phân tích kết hợp với người lập trình viên. Xác định các vấn đề khi hệ thống chạy lần đầu tiên với dữ liệu mẫu, sau đó là chạy trên dữ liệu thật của hệ thống hiện tại. Kế hoạch kiểm tra thường được thực hiện sớm trong SDLC và được hoàn thiện như tiến độ của dự án. 1 2 3 4 5 6 7

24 Kiểm Tra Và Bảo Trì Hệ ThốngTrong giai đoạn này, việc bảo trì hệ thống và tài liệu về hệ thống được thực hiện và sử dụng thường xuyên trong suốt thời gian sống của hệ thống. Phần lớn công việc thường xuyên của lập trình bao gồm bảo trì và các doanh nghiệp chi tiêu rất nhiều chi phí vào bảo trì. Một số việc bảo trì, chẳng hạn như cập nhật chương trình, có thể được thực hiện tự động thông qua một trang web cung cấp bởi trang web đó. 1 2 3 4 5 6 7

25 Các Giai Đoạn Của Chu Trình Phát Triển Hệ Thống2. Xác định yêu cầu thông tin của con người 1. Xác định các vấn đề, cơ hội và mục tiêu. 3. Phân tích nhu cầu của hệ thống S D L C 4. Thiết kế hệ thống được đề xuất. 7. Hiện thực và đánh giá hệ thống. 6. Kiểm tra và bảo trì hệ thống 5. Phát triển và lập tài liệu về phần mềm

26 Hiện Thực Và Đánh Giá Hệ ThốngĐào tạo người sử dụng để có thể sử dụng và xử lý hệ thống. Các nhà phân tích có trách nhiệm quan sát việc đào tạo này. Các nhà phân tích cần phải có kế hoạch chuyển đổi hệ thống cũ qua hệ thống mới. Chuyển đổi file từ định dạng cũ sang định dạng mới, xây dựng một hệ cơ sở dữ liệu, lắp đặt thiết bị, đưa hệ thống vào sản xuất. 1 2 3 4 5 6 7

27 Agile Modeling And Prototyping1 Prototyping 2 Rapid application development (RAD) 3 Agile Modeling

28 Prototyping Là một phương pháp phát triển hệ thống trong đó một mô hình mẫu được xây dựng, kiểm tra, sau đó xây dựng lại nếu cần thiết cho đến khi đạt được một mô hình mẫu chấp nhận được, từ mô hình này, một hệ thống hoặc sản phẩm hoàn chỉnh có thể được phát triển. 3

29 Four Main Type PrototypingFirst of a series Nonoperational Patch-up Selected Features 01 02 03 04

30 Patch Up Prototyping Một hệ thống hoạt động nhưng được tích hợp từ các phần khác nhau. Một mô hình có tất cả chức năng nhưng không hiệu quả Người dùng có thể tương tác với hệ thống Truy vấn và lưu trữ dữ liệu không hiệu quả

31 Nonoperational Scale ModelsMột mô hình tỉ lệ không hoạt động mà được thiết lập để kiểm tra một số khía cạnh của thiết kế Một bản mẫu với thông tin cho đầu vào và những yêu cầu đầu ra

32 First Of A Series PrototypeTạo ra một mô hình thử nghiệm (pilot) Một bản mẫu hoàn chỉnh Hữu dụng khi việc cài đặt nhiều lần của một hệ thống thông tin được lên kế hoạch Một nguyên mẫu hoàn chỉnh được cài đặt tại một hoặc hai vị trí nếu thành công bản sao sẽ được cài đặt dựa trên mô hình sử dụng của khách hàng và một số yếu tố quan trong khác

33 Selected Features PrototypeTạo ra bản mẫu hoạt động nhưng chỉ có một số tính năng Chỉ một số tính năng cần thiết chứ không phải tất cả Được xây dựng thành các module Là một phần của hệ thống thực tế

34 Prototyping Một Lựa Chọn Để Thay Thế SDLCHai vấn đề với SDLC Kéo dài thời gian phát triển đi qua vòng đời phát triển Yêu cầu của người dùng thay đổi quá trễ Có thể sử dụng prototyping như một phần của SDLC

35 Hướng Dẫn Xây Dựng Bản Mẫu01 02 03 04 Làm việc với module dễ quản lí Xây dựng các bản mẫu nhanh chóng Quá trình sửa đổi được lặp lại liên tục Nhấn mạnh giao diện người dùng

36 Nhược Điểm Của PrototypingKhó khăn trong việc quản lí và phát triển đối với dự án lớn. Người dùng và nhà phân tích có thể chấp nhận bản mẫu như là một hệ thống hoàn chỉnh trong khi thực thế là chưa đủ và không thể phục vụ như hệ thống hoàn chỉnh

37 Ưu Điểm Của PrototypingThuận lợi trọng việc thay đổi sớm trong quá trình phát triển hệ thống. Cơ hội để dừng việc phát triển hệ thống nếu không khả thi Phát triển hệ thống gần với yêu cầu và hi vọng của người dùng

38 Prototyping Use COTS SoftwareĐôi khi, cách nhanh nhất để tạo ra bản mẫu là thông qua việc cài đặt các mô đun của phần mềm COTS ( commercial off the shelf) Một số phần mềm COTS là rất phức tạp và tốn kém, nhưng rất hữu ích Ví dụ: “PeopleSoft” : xử lí nhiều hàm cơ bản trên nền tảng Web

39 Vai Trò Của Người Dùng Trong PrototypingNhiệt tình và thành thật Thử nghiệm các bản mẫu Đưa ra những phản ứng rõ ràng với bản mẫu Đưa ra những gợi ý về thêm hoặc xóa trong bản mẫu

40 RAD ( Rapid Application Development )Mô hình này được đưa ra bởi IBM vào những năm 1980, qua sách của James Martin Rapid Application Development một mô hình tiến trình phần mềm gia tăng mà nhấn mạnh tới chu kỳ phát triển ngắn (60-90 ngày) Mô hình RAD là sự ráp nối tốc độ cao của mô hình Thác nước, xây dựng dựa vào thành phần và sử dụng các ứng dụng tạo mã tự động

41 RAD ( Rapid Application Development )Một cách tiến cận hướng đối tượng để phát triển hệ thống bao gồm một phương pháp phát triển cũng như các công cụ phần mềm Các giai đoạn trong RAD Lấy yêu cầu, lập kế hoạch RAD design workshop Hiện thực

42 RAD ( Rapid Application Development )

43 Giai Đoạn Lấy Yêu Cầu Lên Kế HoạchNgười dùng và nhà phân tích gặp nhau đề xác định mục tiêu của ứng dụng hoặc hệ thống Định hướng giải quyết các vấn đề về kinh doanh

44 Khi tạo ra hệ thống mới không cần chạy hệ thống cũ song songGiai Đoạn Hiện Thực Khi hệ thống được xây dựng và chọn lọc, những hệ thống mới hoặc một phần của hệ thống được thử nghiệm và sau đó giới thiệu Khi tạo ra hệ thống mới không cần chạy hệ thống cũ song song

45 Sử dụng chữ kí tắt vào một mô hình đại diệnSo Sánh RAD Với SDLC Công cụ phần mềm RAD được sử dụng để tạo ra các màn hình, môi trường và luồng hoạt động của ứng dụng Sử dụng chữ kí tắt vào một mô hình đại diện Hiện thực RAD là ít căng thẳng bởi vì người dùng đã giúp để thiết kế các khía cạnh kinh doanh của hệ thống

46 So Sánh RAD Với SDLC

47 Khi cần phải phát triển phần mềm cấp báchKhi Nào Sử Dụng RAD Nhóm bao gồm những lập trình viên và nhà phân tích có kinh nghiệm với RAD Khi cần phải phát triển phần mềm cấp bách Dự án cần một ứng dụng thương mại điện tử mới lạ và cần kết quả nhanh chóng

48 Ưu Điểm Của RAD Thời gian phát triển giảm nhờ dùng công cụChỉ cần ít người phát triển hơn, do họ thân thiện với vấn đề Nhanh chóng cho phép hình dung ra sản phẩm Dùng hiệu quả các framework và công cụ đóng gói (off-the-shelf tools and frameworks) Giảm rủi ro nhờ có sự tham gia của khách hàng

49 Nhược Điểm Của RAD Cố gắng đẩy nhanh dự án quá nhiều Thiếu tài liệuThiếu sự tham gia tốt của người dùng trong chu kỳ sống của phần mềm Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử dụng công cụ và thời gian phát triển nhanh Hệ thống có khả năng phân tách module Cần có đáp ứng về thành phần sử dụng lại Người phát triển và khách hàng phải nỗ lực Người quản lý phải làm việc tận tụy với nhóm phát triển và khách hàng để nhanh chóng đạt được các thỏa thuận

50 Phương Pháp Phát Triển Phần Mềm Linh HoạtPhát triển phần mềm linh hoạt (agile software development – gọi tắt là Agile) là sự tập hợp của sự cải tiến, lấy phương pháp tiếp cận người dùng làm trung tâm phát triển hệ thống. Cố gắng để xác định tổng thể hệ thống một cách nhanh chóng, phát triển và phát hành phần mềm một cách nhanh chóng, và sau đó liên tục sửa đổi phần mềm để thêm tính năng bổ sung

51 Mức độ phổ biến của các phương phápNhờ tính linh hoạt, đa dạng và hiệu quả cao, các phương pháp Agile ngày càng trở thành sự lựa chọn hàng đầu của các khách hàng, nhà phát triển, các công ty phát triển phần mềm. Theo khảo sát của hãng nghiên cứu thị trường Forrester, mức độ phổ biến của Agile hiện đang ở mức cao nhất, và gấp nhiều lần so với các phương pháp truyền thống như thác nước hay CMMi.

52 Tuyên Ngôn của Agile Cá nhân và sự tương tác hơn làQuy trình và công cụ. Phần mềm chạy tốt hơn là Tài liệu đầy đủ. Mặc dù các điều bên phải vẫn còn giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái. Cộng tác với khách hàng hơn là Đàm phán hợp đồng. Phản hồi với các thay đổi hơn là Bám sát kế hoạch.

53 Cá nhân và sự tương tác Lập trình cặp (tiếng Anh: Pair Programming) là kiểu lập trình đòi hỏi hai kỹ sư phần mềm cùng tham gia một nỗ lực lập trình chung trên một máy trạm, nghĩa là chỉ có một màn hình, một bàn phím. Mỗi người thực hiện việc mà người kia hiện không làm. Ví dụ, người này gõ các bộ test đơn vị (unit test), người kia nghĩ về các lớp đầu vào (input) sẽ thỏa mãn bộ test đó; hoặc người này viết mã còn người kia quan sát để hướng dẫn hoặc kiểm lỗi. Người ta khuyên rằng hai người nên luân phiên đổi vai trò, khoảng nửa giờ một lần. Tích hợp liên tục (CI) là phương pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên. Mỗi ngày, các thành viên đều phải theo dõi và phát triển công việc của họ ít nhất một lần. Việc này sẽ được một nhóm khác kiểm tra tự động, nhóm này sẽ tiến hành kiểm thử truy hồi để phát hiện lỗi nhanh nhất có thể. Một cuộc họp đứng là một cuộc họp mà trong đó người tham dự thường tham gia trong khi đứng. Sự khó chịu của đứng trong thời gian dài được thiết kế để giữ cho các cuộc họp ngắn. Khi không có vấn đề trong tương tác, nhóm có thể thực hiện công việc tốt hơn 50 lần so với mức trung bình trong lĩnh vực của mình. Khi bắt đầu dự án có nhiều vấn đề: dự án phải cập nhật liên tục, lỗi hệ thống, deadline… đòi hỏi phải có sự tương tác tốt. Để tạo điều kiện cho sự tương tác, một số phương pháp thường được sử dụng : lập trình cặp (pair-programming), tích hợp liên tục (continuos integration), standup metting (họp đứng)…

54 Cá nhân và sự tương tác Để thúc đẩy các hành vi này, nhà quản lý linh hoạt phải cung cấp một môi trường hỗ trợ, các nhà huấn luyện phải tạo điều kiện thuận lợi, và các thành viên của nhóm phải thể hiện chúng. Tuy nhiên, các chu trình đó chỉ thực sự làm việc tốt khi mà các nhà lãnh đạo agile khuyến khích các cuộc xung đột tích cực, thứ cần thiết để xây dựng một nền tảng vững chắc cho sự trung thực, tính minh bạch, lòng tin, sự tôn trọng, và cam kết từ các nhóm agile của họ. Tuy nhiên, chỉ tăng tần suất phản hồi và giao tiếp là không đủ để loại bỏ các vấn đề về truyền thông. Các thành viên trong nhóm thể hiện những hành vi quan trọng sau: Tôn trọng giá trị của mỗi cá nhân; Trung thực. Minh bạch về dữ liệu, hoạt động, và quyết định. Tin tưởng vào sự hỗ trợ của mỗi cá nhân với nhóm. Cam kết với nhóm và các mục tiêu của nhóm.

55 Phần mềm chạy tốt Tất cả các nhóm agile phải xác lập những gì họ muốn nói là “phần mềm chạy tốt”, cái thường được biết như là định nghĩa hoàn thành. Triển khai một loạt các tính năng và theo độ ưu tiên, Cung cấp một phần nhỏ của phần mềm chạy tốt tới khách hàng sau một khoảng thời gian nhất định. Ở mức độ cao, các tính năng phải vượt qua tất cả các kiểm thử và được vận hành bởi người dùng cuối. Ở mức thấp, các nhóm vượt qua được kiểm thử đơn vị (unit test) và kiểm thử hệ thống. Một công ty CMMI Cấp độ 5, chạy các kiểm thử với mỗi tính năng, và sửa bất cứ một lỗi nào có độ ưu tiên cao nhất sẽ tăng gấp đôi tốc độ sản xuất và giảm các sai sót đến 40%.

56 Cộng tác với khách hàng Mức độ chuyển giao thường xuyên đã cho phép khách hàng cung cấp các thông tin phản hồi về phần mềm hoạt động một cách đều đặn hơn. Điều này cho phép khách hàng có thể giúp định hình sản phẩm phần mềm đang được tạo ra

57 Phản hồi với thay đổi Dữ liệu ngành công nghiệp cho thấy hơn 60% các yêu cầu về sản phẩm hay dự án bị thay đổi suốt quá trình phát triển phần mềm. Ngay cả khi các dự án truyền thống kết thúc đúng thời gian, đúng kinh phí, với các tính năng theo kế hoạch, nhưng khách hàng thường không hài lòng. Nếu khách hàng không nhìn thấy phần mềm hoạt động cho đến khi kết thúc dự án, sẽ là quá muộn cho việc kết hợp các thông tin phản hồi của họ ở thời điểm này.

58 12 Nguyên tắc Thỏa mãn yêu cầu của khách hàng thông qua việc giao hàng sớm và liên tục phần mềm có giá trị. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.

59 12 Nguyên tắc Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc. Phần mềm chạy tốt là thước đo chính của tiến độ Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp. Phát triển bền vững và duy trì được nhịp độ phát triển liên tục.

60 Thích ứng thường xuyên với sự thay đổi.12 Nguyên tắc Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt. Sự đơn giản là cần thiết - nghệ thuật tối đa hóa lượng công việc chưa hoàn thành. Các kiến trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức. Thích ứng thường xuyên với sự thay đổi.

61 Quy Trình Phát Triển Trong AgileThăm dò. Lên Kế hoạch. Lặp đi lặp lại để cho ra bản phát hành đầu tiên. Hoàn thiện sản phẩm. Bảo trì.

62 Hoạt động cơ bản của AgileCoding: Suy nghĩ, code, test, có hợp lý không. Khi tôi nhìn vào code, có hiểu ko, có ý tưởng mới ko. => tạo nên sự sống của system. Kiểm tra tự động, sử dụng các thư viện test lơn (Junit, PHPUnit). Trong ngắn hạn tạo sự tin tưởng cho những gì đang xây dựng, tiếp tục phát triển tối ưu. Trong dài hạn tạo nên chất lượng của dự án. Listening: điều mà agile đề cao. Như đã đề cập trong việc Interview. Lắng nghe đồng nghiệp, lắng nghe khách hàng để giải đáp những thắc mắc của mình về yêu cầu. Ko lắng nghe ko biết mình cần làm gì test gì, đồng nghiệp mình đang gặp khó khăn gì. Design : thiết kế tốt cho mọi người, khách hàng, lập trình viên. Thiết kế đơn giản, linh hoạt cho phép phát triển thêm,. Resource : điều quan tâm nhất trong việc quản lý một dự án, Agile mà thông qua các đặc trưng cơ bản đã quản lý các resource một cách hiệu quả. Sử dụng tốt thời gian, giao sản phẩm chạy được liên tục, giảm sự ảnh hưởng của deadline lên dự án. Giảm thiểu chi phí vì những thay đổi và hoạt động, tạo ra những phần sản phẩm chất lượng. Và phạm vi thỏa mãn khách hàng. Coding Testing Listening Designing

63 Coding Viết mã (coding) là 1 hoạt động không thể thiếu.Quá trình này bao gồm : suy nghĩ, viết mã, kiểm tra và xem liệu suy nghĩ đó có hợp lý không. Mã có thể được sử dụng để truyền đạt những ý tưởng không rõ ràng. Khi nhìn vào đoạn mã, có thể có ý tưởng mới. Mã nguồn là cơ sở cho 1 hệ thống

64 Testing Kiểm thử (testing) là hoạt động quan trọng trong phát triển phần mềm. Kiểm thử phải được thực hiện liên tục trong suốt quá trình phát triển dự án. Có 2 loại kiểm thử : dài hạn và ngắn hạn.

65 Listening Các nhà phát triển sử dụng chủ động lắng nghe (listening) đối tác của họ. Mô hình Agile ít phụ thuộc vào hình thức, giao tiếp bằng văn bản, nên lắng nghe sẽ trở thành một kỹ năng quan trọng. Các nhà phát triển giả định rằng mình không biết gì về chức năng mà họ xây dựng, vì vậy họ phải lắng nghe 1 cách cẩn thận. Nếu không, bạn sẽ không biết bạn nên viết mã hay kiểm thử như thế nào.

66 Designing Thiết kế (designing) là cách xây dựng cơ cấu hợp lý cho hệ thống. Thiết kế cần phải đơn giản, linh hoạt, dễ dàng mở rộng hệ thống.

67 Biến điều khiển tài nguyênHoàn thành dự án đúng thời hạn rất quan trọng. Để thực hiện điều này, quản lý dự án là rất quan trọng. Quản lý một dự án không có nghĩa là chỉ đơn giản là nhận được tất cả các nhiệm vụ và nguồn lực với nhau.Nhà phân tích đối mặt sự đánh đổi. Đôi khi chi phí có thể được xác định trước, tại những thời điểm khác thời gian có thể là yếu tố quan trọng nhất. Time Cost Quality Scope

68 Phân chia thời gian hợp lý rất khó khăn.Time Nó là như nhau trong phát triển hệ thống. Bạn có thể tạo ra phần mềm chất lượng, nhưng bạn không lắng nghe. Bạn có thể thiết kế một hệ thống hoàn hảo, nhưng không cho phép đủ thời gian để kiểm tra nó. Thời gian là khó quản lý. Khách hàng, chúng ta thường thấy, là hạnh phúc nếu một số chức năng và chạy đúng giờ. kinh nghiệm của chúng tôi cho thấy rằng thường là một khách hàng là 80 phần trăm hài lòng với 20 phần trăm đầu tiên của các chức năng. Điều này có nghĩa là khi bạn hoàn thành 80 phần tram còn lại của dự án, khách hàng có thể chỉ có một chút hạnh phúc hơn so với khi bạn hoàn thành 20 phần trăm đầu tiên. Điều này có nghĩa là đùng nên kéo dài thời hạn của bạn. Phương pháp Agile nhấn mạnh hoàn thành dự án đúng thời gian. Thời gian (time) được chia thành nhiều phần cho các công việc khác nhau : thời gian để lắng nghe khách hàng, thời gian để thiết kế, thời gian để viết mã, thời gian để kiểm thử… Phân chia thời gian hợp lý rất khó khăn. Khách hàng thích hoàn thành dự án đúng tiến độ hơn là mở rộng thời hạn để thêm các tính năng khác

69 Cost Thuê thêm người : không làm giảm thời gian. Khi 1 người mới tham gia vào nhóm, họ không biết gì về dự án và nhóm. Họ sẽ xuất phát chậm hơn những người khác và làm chậm các thành viên khác. Vì các thành viên khác phải dành thời gian để giải thích cho họ về dự án. OT: không hiệu quả. Lập trình viên mệt mỏi thì năng suất giảm, phát sinh nhiều lỗi tốn nhiều thời gian dể sửa chữa. Giải pháp : đầu tư phần cứng và phần mềm Dự án có nguy cơ trễ thời hạn, công việc nhiều và để hoàn thành dự án đúng tiến độ phải tăng chi phí. Cần quản lý tăng chi phí.

70 Quality Nếu hệ thống là hoàn hảo, tại sao phải có đợt bảo trì, cập nhật, bản vá lỗi … Liệu Phương pháp Agile có làm mất chất lượng hệ thống. Agile hy sinh một số chất lượng bên ngoài. Để cho hệ thống sẽ được phát hành vào thời gian, khách hàng có thể phải đối mặt với một số lỗi phần mềm. Nếu chúng tôi muốn đáp ứng thời hạn của chúng tôi, giao diện người dùng có thể không được hoàn hảo. Chúng tôi có thể làm cho nó tốt hơn trong một phiên bản tiếp theo. các nhà sản xuất phần mềm thương mại thường hy sinh chất lượng bên ngoài, và nó là gây tranh cãi cho dù đây là cách tiếp cận đúng. Vì vậy, không ngạc nhiên khi bạn ứng dụng phần mềm máy tính (không đề cập đến hệ điều hành và trình duyệt Web) được cập nhật thường xuyên, nếu các nhà phát triển đang sử dụng Agile. Chất lượng (quality) chia làm 2 loại : Chất lượng bên trong (Internal quality) : liên quan đến các vấn đề như chức năng (chương trình thực hiện những gì) và sự phù hợp (đáp ứng 1 số tiêu chuẩn và sự duy trì). Chất lượng bên ngoài (Externally quality) : những gì khách hàng cảm nhận về hệ thống: hiệu suất, phần mềm có đáng tin cậy (có lỗi hay không), giao diện …

71 Scope kiểm tra để xem có bao nhiêu có thể được thực hiện trong một thời gian nhất định để đáp ứng khách hàng. Điều này có thể được thực hiện bằng cách đồng ý với các khách hàng rằng một hoặc nhiều trong những câu chuyện có thể được trì hoãn cho đến khi phiên bản tiếp theo của phần mềm. Tóm lại, các nhà phân tích nhanh nhẹn có thể kiểm soát bất kỳ trong bốn biến tài nguyên của thời gian, chi phí, chất lượng và phạm vi. Agile tầm quan trọng vào việc hoàn thành một dự án đúng thời gian. Để làm điều đó, hy sinh phải được thực hiện và các nhà phân tích nhanh nhẹn sẽ tìm ra sự đánh đổi hợp lý là 1 quyết định khó khăn. Nhà phân tích dự án phải lắng nghe yêu cầu khách hàng, xác định phạm vi dự án. Để duy trì chất lượng, quản lý chi phí, và hoàn thành dự án đúng thời gian, Tóm lại, các nhà phân tích phải kiểm soát bốn biến tài nguyên thời gian, chi phí, chất lượng và phạm vi.

72 4 điểm cốt lõi trong AgilePhiên bản ngắn có nghĩa là đội ngũ phát triển Giảm thời gian giữa các phiên bản của sản phẩm của họ. Thay vì phát hành một phiên bản toàn diện trong một năm, sử dụng các phiên bản ngắn họ sẽ rút ngắn thời gian phát hành bằng cách giải quyết các tính năng quan trọng nhất đầu tiên, phát hành hệ thống hoặc sản phẩm, và sau đó cải thiện nó sau này. 40h thay vì tăng ca, làm ảnh hưởng xấu tới sức khỏe, khuyến khích làm việc hiệu quả sau đó nghỉ ngơi giảm stress. Điều này giúp các vấn đề thành viên trong nhóm tại chỗ dễ dàng hơn, và ngăn ngừa các lỗi tốn kém và thiếu sót do hiệu suất không hiệu quả hoặc kiệt sức .. Giao tiếp vs thành viên trong nhóm, ra quyết định. Lập trình cặp, thường là một senior với junior, cả hai cùng code, test. Senior code trước, sau đó junior tham gia code cùng. Cả hai phải bằng lòng về kết quả làm việc. Lập trình cặp giúp suy nghĩ được rõ ràng. Cặp thay đổi thường xuyên, đặc biệt là trong giai đoạn thăm dò của sự quá trình phát triển. Cặp lập trình tiết kiệm thời gian, giảm bớt suy nghĩ cẩu thả, gây ra sự sáng tạo. Short releases 40-hour work week Onsite customer Pair programming

73 Đặc Trưng Của Agile Tính Lặp 1 Phát Triển Dựa Trên Tính Tịnh Tiến VàGiá Trị Giao Tiếp Trực Diện Tính Thích Ứng Tính Tịnh Tiến Và Tiến Hóa Tính Lặp Đặc Trưng 1 2 3 4 5

74 Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại.Tính Lặp ( Iterative) Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. - Các phân đoạn (Sprint) này thường có khung thời gian ngắn (từ một đến bốn tuần). Trong mỗi phân đoạn này, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử để cho ra các phần nhỏ của sản phẩm. Các phương pháp agile thường phân rã mục tiêu thành các phần nhỏ và không thực hiện việc lập kế hoạch dài hạn.

75 Tính tịnh tiến (Incremental) và tiến hóa (Evolutionary)Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành. Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng ngay. Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạy được này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn. Khác với mô hình phát triển Thác nước – vốn chỉ cho phép nhìn thấy toàn bộ các chức năng tại thời điểm kết thúc dự án, sản phẩm trong các dự án agile lớn dần lên theo thời gian, tiến hóa cho tới khi đạt được trạng thái đủ để phát hành. Việc cho ra phần nhỏ của sản phẩm và giao hàng cho khách hàng, làm tăng độ hài lòng, và làm cho khách hàng thấy sản phẩm của mình đang được phát triển tốt, và đang tiến triển đúng hạn. January May

76 Tính thích ứng (hay thích nghi – adaptive):Do các phân đoạn chỉ kéo dài trong một khoảng thời gian ngắn, và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển (yêu cầu thay đổi, thay đổi công nghệ, thay đổi định hướng về mục tiêu v.v.) đều có thể được đáp ứng theo cách thích hợp. Ví dụ, trong Scrum – phương pháp phổ biến nhất hiện nay – trong khi nhóm phát triển sản xuất ra các gói phần mềm, khách hàng có thể đưa thêm các yêu cầu mới, chủ sản phẩm (Product Owner) có thể đánh giá các yêu cầu này và có thể đưa vào làm việc trong phân đoạn (được gọi là Sprint trong Scrum) tiếp theo. Theo đó, các quy trình agile thường thích ứng rất tốt với các thay đổi. Các thay đổi trong quá trình phát triển đều có thể được đáp ứng theo cách thích hợp. Luôn sẵn sàng thay đổi, và Thay đổi ngay lập tức. Giảm thiểu chi phí khi có thay đổi.

77 Giao Tiếp Trực Tiếp Về yêu cầu của khách hàng, agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần, thay vì phụ thuộc nhiều vào các loại văn bản. (Scope của dự án.) (cost, thay vì thuê nhiều người, tăng ca mà ko hiệu quả, việc hiểu rõ công việc và hiểu rõ nhau nâng năng suất lên ) Trong giao tiếp giữa nội bộ nhóm phát triển với nhau, thay vì một lập trình viên (thực hiện việc mã hóa) và một kĩ sư (thực hiện việc thiết kế) giao tiếp với nhau thông qua bản thiết kế, agile khuyến khích hai người này trực tiếp trao đổi và thống nhất với nhau về thiết kế của hệ thống và cùng nhau triển khai thành các chức năng theo yêu cầu. Các dự án lớn muốn dùng agile thường phải phân thành nhóm nhỏ đồng thời làm việc với nhau hướng đến một mục tiêu chung. Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting). Tại đây, tất cả các thành viên được yêu cầu nói rõ cho nhóm của mình biết mình đã làm gì, đang làm gì, sắp làm gì và đang gặp phải khó khăn nào trong quá trình làm việc. Khi cơ chế này được thực hiện hiệu quả, nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự án. Agile khuyến khích nhóm phát triển trực tiếp nói chuyện với khách hàng để hiểu rõ hơn về cái khách hàng thực sự cần. Nhóm agile thường nhỏ (ít hơn mười hai người) để đơn giản hóa quá trình giao tiếp, thúc đẩy việc cộng tác hiệu quả. Một trong các cơ chế thường thấy là các cuộc họp tập trung hằng ngày (daily meeting), nhóm luôn luôn nắm được tình hình công việc của mình, có các hành động thích hợp để vượt qua các trở lực để thực hiện thành công mục tiêu của dự án.

78 Phát Triển Dựa Trên Giá TrịNhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng), cộng tác trực tiếp với họ để biết yêu cầu nào có độ ưu tiên cao hơn, mang lại giá trị hơn cho dự án. Một cách gần như trực tiếp, agile gia tăng đáng kể độ hài lòng của khách hàng. “phần mềm chạy tốt chính là thước đo của tiến độ”. Nhóm agile thường làm việc trực tiếp và thường xuyên với khách hàng (hay đại diện của khách hàng). Sử dụng các công cụ và kỹ thuật cụ thể như unit testing, pair programing, test-driven-development, design pattern, code refactoring… để cải thiện chất lượng và sự nhanh nhẹn của dự án.

79 Sự tương tác giữa các nhà phát triển và người sử dụng.User Story Sự tương tác giữa các nhà phát triển và người sử dụng. Tìm kiếm cái cần làm đầu tiên và quan trọng nhất tạo nên giá trị dự án từ yêu cầu của khách hàng. Mục đích là ngăn ngừa sự hiểu lầm hoặc hiểu nhầm với yêu cầu của người dung.

80 User story

81 Các Phương Pháp Trong Agile

82 Scrum là gì Scrum là một phương pháp linh hoạt (agile), vì thế nó tuân thủ các nguyên tắc của Tuyen Ngôn Agile. Ngoài ra Scrum hoạt động dựa trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và Thích nghi.