Please enable JavaScript.

Coggle requires JavaScript to display documents.

Phần 1 : GIỚI THIỆU CNPM , QUY TRÌNH , PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU, Quy…

- - - - Thực hiện kiểm thử chức năng và kiểm thử hệ thống.
      - Sửa lỗi và đảm bảo tính ổn định và đúng đắn của hệ thống.
    - - Dựa trên yêu cầu, xác định kiến trúc hệ thống và cấu trúc dữ liệu.
      - Xác định cách triển khai, các thành phần hệ thống và giao diện người dùng.
    - - Triển khai sản phẩm hoặc phiên bản mới.
      - Chuyển giao sản phẩm cho người dùng cuối.
    - - Xác định và hiểu rõ nhu cầu của khách hàng
      - Làm rõ yêu cầu chức năng và phi chức năng.
    - - Hỗ trợ và bảo trì sản phẩm sau khi đã triển khai.
      - Sửa lỗi và thực hiện các cập nhật phần mềm.
    - - Tạo ra các thành phần và module của hệ thống
      - Lập trình và triển khai mã nguồn dựa trên các thiết kế đã được xác định.
  - - - Xây dựng và triển khai các thành phần dựa trên các yêu cầu và thiết kế.
      - Đảm bảo rằng các thành phần có thể tái sử dụng và tương thích với hệ thống.
    - - Thực hiện kiểm thử đơn vị để đảm bảo rằng mỗi thành phần hoạt động đúng đắn và đáp ứng yêu cầu.
      - Kiểm thử tích hợp để đảm bảo tính tương thích giữa các thành phần.
    - - Tìm kiếm các thành phần có sẵn hoặc xây dựng các thành phần mới nếu cần thiết.
      - Chọn lựa các thành phần dựa trên yêu cầu và tiêu chí như tái sử dụng, hiệu suất, tính tin cậy, và khả năng mở rộng.
    - - Tích hợp các thành phần vào hệ thống.
      - Thực hiện kiểm thử hệ thống để đảm bảo tính tương thích và chức năng đúng đắn của toàn bộ hệ thống.
    - - Xác định yêu cầu của hệ thống và phân tích chúng thành các thành phần có thể tái sử dụng.
      - Thiết kế cách các thành phần tương tác với nhau và với hệ thống.
    - - Triển khai hệ thống cho người sử dụng cuối.
      - Hỗ trợ và bảo trì hệ thống sau khi triển khai, bao gồm việc quản lý các thành phần và xử lý sự cố.
- - - - Nhóm Scrum thực hiện công việc được lập kế hoạch trong suốt khoảng thời gian của sprint (thường là 2-4 tuần).
      - Tổ chức các cuộc họp ngắn hàng ngày gọi là Daily Scrum để đảm bảo sự hiểu biết và sự hợp tác liên tục trong nhóm.
    - - Ở cuối mỗi sprint, tổ chức cuộc họp kiểm thử và đánh giá, được gọi là Sprint Review.
      - Nhóm Scrum trình bày những gì họ đã đạt được trong sprint và thu thập phản hồi từ khách hàng.
    - - Giai đoạn này xảy ra ở đầu mỗi chu kỳ phát triển gọi là "sprint".
      - Nhóm Scrum (Scrum Team) lên kế hoạch cho công việc trong sprint tới.
      - Xác định các backlog items (các công việc cần làm) được chọn để triển khai trong sprint.
    - - Ngay sau Sprint Review, tổ chức cuộc họp Sprint Retrospective.
      - Nhóm Scrum đánh giá nhanh sprint vừa qua và xác định cách để cải thiện trong các sprint tiếp theo.
  - - - Cuộc họp lên kế hoạch ở đầu mỗi sprint.
      - Xác định và lập kế hoạch cho công việc cần làm trong sprint tiếp theo.
    - - Cuộc họp ở cuối mỗi sprint để kiểm tra và xác nhận công việc đã hoàn thành.
      - Nhóm Scrum thể hiện sản phẩm và nhận phản hồi từ khách hàng.
    - - Cuộc họp sau Sprint Review để đánh giá sprint vừa qua và xác định cách để cải thiện.
    - - Nếu có nhiều nhóm Scrum làm việc trong dự án lớn, cuộc họp này giúp đồng bộ hóa tiến độ và giải quyết vấn đề liên quan đến tích hợp giữa các nhóm.
    - - Cuộc họp ngắn hàng ngày, thường kéo dài không quá 15 phút.
      - Nhóm Scrum chia sẻ tiến độ công việc, thảo luận vấn đề và cập nhật kế hoạch làm việc.
  - - - Giúp giải quyết mọi rủi ro và vấn đề mà nhóm Scrum có thể gặp phải trong quá trình phát triển.
      - Tạo điều kiện thuận lợi để nhóm có thể tập trung vào công việc và đạt được mục tiêu của sprint.
    - - Nếu dự án có nhiều nhóm Scrum, Scrum Master có trách nhiệm điều phối và giải quyết vấn đề tích hợp giữa các nhóm
    - - Scrum Master chịu trách nhiệm đảm bảo rằng nhóm Scrum hiểu và tuân thủ nguyên tắc và quy tắc của Scrum.
      - Hỗ trợ và tạo điều kiện cho sự tự quản lý của nhóm Scrum.
    - - Tổ chức các cuộc họp Scrum, như Daily Scrum, Sprint Review, và Sprint Retrospective.
      - Hỗ trợ quá trình giao tiếp và tương tác liên tục trong nhóm Scrum.
  - - - Thường xuyên tương tác với nhóm Scrum để đảm bảo sự hiểu rõ về yêu cầu và mục tiêu của sản phẩm.
      - Tham gia trong các cuộc họp lập kế hoạch, cuộc họp review và cuộc họp retrospective.
    - - Đảm bảo rằng Product Backlog luôn được cập nhật và đáp ứng nhu cầu thay đổi của khách hàng.
      - Chịu trách nhiệm trong quá trình quyết định về nội dung và ưu tiên của sản phẩm
    - - Chịu trách nhiệm đảm bảo rằng sản phẩm đáp ứng nhu cầu và kỳ vọng của khách hàng
      - Quyết định khi nào sản phẩm có thể được triển khai và đưa ra thị trường.
    - - Xác định và quản lý Product Backlog, tức là danh sách các yêu cầu và tính năng mà sản phẩm cần.
      - Ưu tiên các yêu cầu theo giá trị kinh doanh và ưu tiên của khách hàng.
- - - - Yêu cầu chức năng là các yêu cầu liên quan đến các chức năng cụ thể mà hệ thống phải thực hiện. Đây là những yêu cầu mô tả những gì hệ thống nên làm và cách nó nên hoạt động. Yêu cầu chức năng thường được mô tả dưới dạng "nếu...thì" và có thể được đo lường và kiểm thử. Ví dụ:
        Yêu cầu chức năng: Khi người dùng nhấn nút "Đăng Nhập," hệ thống phải xác thực thông tin đăng nhập và chuyển họ đến trang chính.
    - - Yêu cầu phi chức năng là các yêu cầu không liên quan trực tiếp đến các chức năng cụ thể của hệ thống, mà thường liên quan đến hiệu suất, an ninh, tính khả dụng, và các khía cạnh khác của hệ thống. Đây là những yêu cầu liên quan đến chất lượng và không thể đo lường một cách trực tiếp như yêu cầu chức năng. Ví dụ:
        Yêu cầu phi chức năng: Hệ thống phải có khả năng xử lý đồng thời 1000 người dùng mà không gây trễ.
  - - - Yêu cầu người dùng là mức độ yêu cầu mà người sử dụng cuối cùng của hệ thống đều có thể hiểu và chia sẻ. Đây là những yêu cầu được mô tả từ góc độ của người sử dụng, không yêu cầu kiến thức chuyên sâu về công nghệ và thường được trình bày bằng ngôn ngữ thông thường. Yêu cầu người dùng giúp xác định các tính năng và chức năng cần thiết để hệ thống đáp ứng mong đợi của người sử dụng.
      - Ví dụ
        Yêu cầu người dùng: Hệ thống phải cung cấp giao diện người dùng thân thiện và dễ sử dụng để người dùng có thể dễ dàng đăng nhập và thực hiện các giao dịch.
    - - Yêu cầu hệ thống là mức độ yêu cầu chi tiết hơn và chuyên sâu hơn, tập trung vào cách hệ thống nên được xây dựng và triển khai để đáp ứng yêu cầu của người sử dụng. Yêu cầu này thường được mô tả bằng ngôn ngữ kỹ thuật, và chúng xác định các thuộc tính và ràng buộc cần thiết cho hệ thống.
      - Ví dụ:
        Yêu cầu hệ thống: Hệ thống phải hỗ trợ đồng thời 1000 người dùng và đảm bảo thời gian phản hồi dưới 2 giây khi thực hiện các giao dịch.
    - - Quan điểm:
        
        Yêu cầu người dùng tập trung vào trải nghiệm và đòi hỏi của người sử dụng.
        
        Yêu cầu hệ thống tập trung vào cách hệ thống nên được xây dựng và hoạt động để đáp ứng yêu cầu của người sử dụng.
      - Ngôn Ngữ:
        
        Yêu cầu người dùng được mô tả bằng ngôn ngữ thông thường và dễ hiểu.
        
        Yêu cầu hệ thống thường được mô tả bằng ngôn ngữ kỹ thuật và chuyên sâu.
      - Mức Độ Chi Tiết:
        
        Yêu cầu người dùng thường chưa đủ chi tiết cho việc triển khai trực tiếp mà còn cung cấp hướng dẫn chung về các tính năng mong muốn.
        
        Yêu cầu hệ thống cung cấp các thông số cụ thể và yêu cầu kỹ thuật để xây dựng hệ thống.
      - Mục Tiêu:
        
        Yêu cầu người dùng đặt ra mục tiêu về trải nghiệm và giá trị từ sản phẩm hoặc hệ thống.
        
        Yêu cầu hệ thống đặt ra mục tiêu về hiệu suất, bảo mật, và các tính năng kỹ thuật cụ thể.
  - - - 1.Xác Định và Phân Tích Yêu Cầu:
        
        Thu thập và xác định yêu cầu từ các bên liên quan, bao gồm người sử dụng, khách hàng, và các bên quan trọng khác.
        
        Phân tích yêu cầu để hiểu rõ các chức năng và tính năng cần thiết của hệ thống.
      - 2.Biểu Diễn Yêu Cầu:
        
        Biểu diễn yêu cầu bằng các tài liệu, mô hình, hoặc ngôn ngữ phù hợp như UML (Unified Modeling Language).
        
        Đảm bảo yêu cầu được biểu diễn một cách rõ ràng và dễ hiểu cho tất cả các bên liên quan.
      - 3.Kiểm Soát Yêu Cầu:
        
        Đảm bảo rằng các yêu cầu được duy trì và được bảo tồn theo thời gian.
        
        Xác định, theo dõi, và quản lý sự thay đổi trong yêu cầu trong suốt quá trình phát triển.
      - 4.Kiểm Tra và Xác Nhận Yêu Cầu:
        
        Xác nhận rằng yêu cầu đáp ứng được nhu cầu và mong đợi của người sử dụng.
        
        Kiểm tra tính toàn vẹn và chính xác của yêu cầu
      - 5.Quản Lý Xung Đột Yêu Cầu:
        
        Điều phối và giải quyết xung đột giữa các yêu cầu khi chúng xảy ra.
        
        Đảm bảo rằng các yêu cầu không mâu thuẫn hoặc tương lẫn loại trừ nhau.
      - Những Trở Ngại Thường Gặp Trong Quy Trình Kỹ Nghệ Yêu Cầu:
        
        1.Không Hiểu Rõ Yêu Cầu
        
        Các bên liên quan có thể không hiểu rõ hoặc không đồng nhất về yêu cầu của hệ thống.
        
        2.Thay Đổi Yêu Cầu Liên Tục:
        
        Sự thay đổi không kiểm soát hoặc liên tục trong yêu cầu có thể tạo khó khăn cho quá trình phát triển.
        
        3.Xung Đột Yêu Cầu:
        
        Xung đột giữa các yêu cầu từ các bên liên quan có thể xảy ra và cần phải được giải quyết.
        
        4.Chuyển Đổi Yêu Cầu:
        
        Khi yêu cầu được chuyển giao từ bên này sang bên khác, có thể xảy ra hiểu lầm và mất thông tin.
        
        5.Thiếu Tài Nguyên và Kỹ Năng:
        
        Thiếu tài nguyên và kỹ năng trong việc thu thập và biểu diễn yêu cầu có thể gây trở ngại.
- - - - Ảnh Hưởng: Kiến trúc phần mềm tốt giúp dễ bảo trì, tức là dễ dàng thực hiện các sửa lỗi, nâng cấp, và thay đổi hệ thống mà không làm ảnh hưởng đến các phần khác của mã nguồn.
      - Giải Thích: Nếu kiến trúc được thiết kế chặt chẽ và có sự tách biệt giữa các thành phần, việc thực hiện các thay đổi sẽ dễ dàng hơn, giảm nguy cơ tác động phụ.
    - - Ảnh Hưởng: Kiến trúc phần mềm ảnh hưởng đến hiệu suất của hệ thống, bao gồm tốc độ thực hiện, đáp ứng và khả năng xử lý đồng thời.
      - Giải Thích: Kiến trúc được thiết kế tốt có thể tối ưu hóa tài nguyên và mối quan hệ giữa các thành phần, làm tăng hiệu suất tổng thể của hệ thống.
    - - Ảnh Hưởng: Kiến trúc phần mềm cũng ảnh hưởng đến khả năng mở rộng của hệ thống, tức là khả năng mở rộng để đáp ứng được tăng cường nguồn lực và yêu cầu.
      - Giải Thích: Một kiến trúc có thể mở rộng cho phép hệ thống linh hoạt thích ứng với sự thay đổi của môi trường và nhu cầu tăng cường.
  - - - Thành Phần Chính:
        
        1.Thành Phần Chức Năng (Functional Components):
        Đại diện cho các tính năng chức năng của hệ thống.
        
        2.Thành Phần Giao Diện Người Dùng (User Interface Components):
        Chịu trách nhiệm cho giao diện người dùng và tương tác người dùng.
        
        3.Thành Phần Dữ Liệu (Data Components):
        Điều khiển và quản lý dữ liệu của hệ thống.
      - Quan Hệ:
        
        1.Quan Hệ Chức Năng - Giao Diện Người Dùng:
        Thành phần chức năng giao tiếp với thành phần giao diện người dùng để hiển thị thông tin và nhận input từ người dùng.
        
        2.Quan Hệ Chức Năng - Dữ Liệu:
        Thành phần chức năng sử dụng thành phần dữ liệu để lưu trữ và truy xuất thông tin cần thiết.
        
        3.Quan Hệ Giao Diện Người Dùng - Dữ Liệu:
        Thành phần giao diện người dùng tương tác với thành phần dữ liệu để hiển thị và cập nhật thông tin từ và đến người dùng.
    - - 1.Tái Sử Dụng (Reuse):
        Kiểu kiến trúc có sẵn thường chứa các thành phần có thể tái sử dụng, giúp giảm thiểu công sức phát triển và tăng tốc độ phát triển phần mềm.
      - 2.Dễ Dàng Quản Lý và Bảo Trì:
        Cấu trúc tổ chức rõ ràng giúp dễ dàng quản lý và bảo trì mã nguồn, đặc biệt là khi có sự cần thiết cho việc thay đổi và mở rộng.
      - 3.Chất Lượng Mã Nguồn:
        Kiểu kiến trúc giúp đảm bảo chất lượng mã nguồn bằng cách cung cấp một cấu trúc tổ chức chuẩn mực và giúp tránh được các lỗi thường gặp.
      - 4.Hiệu Quả Phát Triển:
        Những kiểu kiến trúc có sẵn thường được kiểm tra và tối ưu hóa để đảm bảo hiệu suất tốt, giúp tăng khả năng mở rộng và xử lý công việc phức tạp.
      - 5.Sự Thống Nhất:
        Việc sử dụng kiểu kiến trúc giúp tạo ra sự thống nhất trong quá trình phát triển và làm cho mã nguồn dễ đọc và hiểu hơn.
- - - - Các thành phần của hệ thống không phụ thuộc lẫn nhau nhiều, điều này tạo ra sự độc lập giữa chúng.
      - Mức độ coupling thấp thường được xem là lợi ích vì nó làm giảm sự phụ thuộc và tăng tính linh hoạt của hệ thống.
    - - Các thành phần phụ thuộc lẫn nhau nhiều, mức độ liên kết giữa chúng là cao.
      - Mức độ coupling cao có thể tạo ra các vấn đề như sự phụ thuộc mạnh mẽ, khó bảo trì, và khó tái sử dụng mã nguồn.
- - - - Tập Trung vào Đối Tượng:
        Mô hình hóa hệ thống bằng cách xác định các đối tượng có liên quan và mô tả cách chúng tương tác với nhau.
      - Kế Thừa và Đa Hình:
        Sử dụng kế thừa và đa hình để tái sử dụng mã nguồn và tạo ra các lớp con có thể mở rộng và thay đổi hành vi của lớp cha.
      - Encapsulation:
        Ưu tiên sự đóng gói để ẩn thông tin và triển khai chi tiết bên trong các đối tượng.
      - Phân Chia Chức Năng:
        Mô hình chức năng theo cách tận dụng tính đóng gói, tính tái sử dụng và tương tác giữa các đối tượng.
  - - - Tập Trung vào Hàm (Function):
        Tính chất chủ yếu là sử dụng hàm, xử lý dữ liệu thông qua việc thực hiện các hàm.
      - Không Có Trạng Thái (Stateless):
        Hệ thống không giữ trạng thái trong biến toàn cục, mọi thay đổi dựa trên đầu vào và đầu ra của các hàm.
      - First-Class và Higher-Order Functions:
        Hỗ trợ first-class và higher-order functions, có thể truyền hàm như là tham số cho hàm khác và trả về hàm từ hàm khác.
      - Không Có Hiện Thực Thay Đổi Trực Tiếp:
        Không sử dụng các biến toàn cục, không thay đổi giá trị của biến trực tiếp.
      - Ví Dụ:
        Hàm "DangKyMonHoc" (RegisterCourse):
        Nhận vào thông tin sinh viên và môn học, trả về thông báo đăng ký thành công hoặc thất bại.
        Hàm "XemDiem" (ViewGrade):
        Nhận vào thông tin sinh viên, trả về bảng điểm của sinh viên đó.
  - - - Hướng Đối Tượng: Có thể có lớp "HocKy" có thuộc tính số tín chỉ, lớp "SinhVien" có phương thức tính tổng số tín chỉ đã đăng ký.
      - Hướng Chức Năng: Có thể có hàm "TinhTongTinChi" nhận vào danh sách môn học và trả về tổng số tín chỉ.
    - - Hướng Đối Tượng: Tính tái sử dụng và bảo trì thông qua việc tái sử dụng lớp, đa hình và đóng gói.
      - Hướng Chức Năng: Tính tái sử dụng thông qua việc sử dụng hàm độc lập, không thay đổi trạng thái toàn cục.
    - - Hướng Đối Tượng: Có thể sử dụng exception handling trong các phương thức.
      - Hướng Chức Năng: Sử dụng hàm trả về giá trị đặc biệt để xử lý lỗi.
    - - Hướng Đối Tượng: Có thể tạo ra các lớp tối ưu với việc sử dụng đa luồng và caching.
      - Hướng Chức Năng: Có thể tận dụng tính không thay đổi của hàm để tối ưu hóa.
- - - - Cả hai quy trình đều tập trung vào việc viết mã nguồn một cách có tổ chức và chất lượng.
        Cả hai đều tích hợp kiểm thử vào quy trình, giúp đảm bảo tính ổn định và chất lượng của mã nguồn.
    - - Quy Trình Viết Mã Tăng Dần:
        
        Viết mã nguồn trước rồi kiểm thử.
        Tập trung vào viết mã nguồn theo từng phần và kết hợp sau đó.
        Yêu cầu có mức độ chi tiết và định rõ từ đầu.
      - Quy Trình Viết Mã Hướng Kiểm Thử:
        
        Viết bài kiểm thử trước rồi mới viết mã nguồn.
        Tập trung vào viết mã nguồn để đáp ứng bài kiểm thử.
        Yêu cầu có mức độ chi tiết ít hơn, hướng đến chức năng cụ thể.
  - - - 1.Duy Trì Dễ Dàng:
        Mã nguồn được tái cấu trúc giúp dễ dàng đọc, hiểu và duy trì.
      - 2.Tính Linh Hoạt:
        Cho phép mở rộng và thay đổi hệ thống một cách linh hoạt hơn.
      - Tăng Hiệu Suất:
        
        Cải thiện hiệu suất của mã nguồn và giảm độ phức tạp.
    - - Thay Đổi Tên Biến và Phương Thức (Rename Variables and Methods):
        Đổi tên các biến và phương thức để làm cho mã nguồn dễ đọc hơn và phản ánh đúng ý nghĩa của chúng.
      - Tách Phương Thức (Extract Method):
        Tách một đoạn mã lớn thành các phương thức con nhỏ, giúp làm giảm độ phức tạp và tăng tái sử dụng.
      - Gộp Phương Thức (Inline Method):
        Gộp các phương thức có thể làm cho mã nguồn trở nên ngắn gọn hơn và dễ hiểu hơn.
    - - IDE (Integrated Development Environment):
        Ví Dụ: IntelliJ IDEA, Eclipse, Visual Studio Code.
        IDE thường cung cấp các công cụ và tính năng hỗ trợ tái cấu trúc mã nguồn như tự động đổi tên, tái cấu trúc phương thức, và gợi ý mã nguồn.
  - - - Git:
        
        Mục Đích: Quản lý phiên bản và theo dõi thay đổi trong mã nguồn.
        
        Đặc Điểm: Phiên bản phân tán, có khả năng theo dõi và hủy bỏ các thay đổi.
    - - 1.Commit (Ghi Lại):
        Ghi lại sự thay đổi vào hệ thống quản lý mã nguồn.
      - 2.Branching (Tạo Nhánh):
        Tạo một nhánh (branch) mới để phát triển tính năng hoặc sửa lỗi mà không làm ảnh hưởng đến mã nguồn chính.
      - 3.Merge (Hợp Nhất):
        Hợp nhất các thay đổi từ một nhánh vào nhánh chính.
      - 4.Pull Request (Yêu Cầu Hợp Nhất):
        Yêu cầu hợp nhất thay đổi từ một nhánh vào nhánh chính sau khi đã hoàn tất công việc.
      - 5.Conflict Resolution (Giải Quyết Xung Đột):
        Giải quyết xung đột giữa các thay đổi khi hợp nhất giữa các nhánh.
    - - Hệ Thống Quản Lý Phiên Bản (VCS - Version Control System):
        
        Ví Dụ: Git, SVN.
        Quản lý lịch sử phiên bản của mã nguồn.
      - Hệ Thống Quản Lý Mã Nguồn (SCM - Source Code Management):
        
        Ví Dụ: GitHub, Bitbucket.
        Cung cấp dịch vụ quản lý mã nguồn trực tuyến và công cụ hợp nhất.
      - Công Cụ Quản Lý Phát Triển (CDM - Development Management):
        
        Ví Dụ: Jira, Trello.
        Quản lý công việc, theo dõi tiến độ, và giao việc trong quá trình phát triển.
      - Hệ Thống Tự Động Hóa (CI/CD - Continuous Integration/Continuous Deployment):
        
        Ví Dụ: Jenkins, Travis CI.
        Tự động hóa quy trình tích hợp và triển khai.
      - Hệ Thống Quản Lý Gói (Package Management):
        
        Ví Dụ: npm, pip.
        Quản lý và phân phối các gói phần mềm và thư viện.
- - - - Mô Hình: Bottom-Up.
        Lợi Ích: Xác nhận từng phần nhỏ của mã nguồn trước khi tích hợp.
  - - - Mô Hình: Top-Down hoặc Bottom-Up.
        Lợi Ích: Đảm bảo tính tương thích giữa các module.
  - - - Mô Hình: Black-Box Testing.
        Lợi Ích: Kiểm tra hệ thống toàn bộ dưới nhiều điều kiện khác nhau.
  - - - Mô Hình: Continuous Testing.
        Lợi Ích: Đảm bảo tính ổn định sau mỗi thay đổi.
  - - - Mô Hình: Alpha hoặc Beta Testing.
        Lợi Ích: Đảm bảo hệ thống đáp ứng đúng yêu cầu và mong đợi của người dùng cuối.