Hình 3 .9 Cập nhật trạng thái Use Case tới Story Structure Understood
Hình 3.16Use Case Slice ở trạng thái Prepared
Chức năng xóa thông tin người dùng: Quản trị hệ thống đăng nhập vào hệ thống và xóa người dùng không dùng ứng dụng hoặc nghỉ việc tại công ty. Sau khi xóa thông tin của người dùng không còn trong cơ sở dữ liệu nữa.
Chưc năng đăng nhập: Mỗi người dùng được cấp một user và password. Khi muốn sử dụng ứng dụng thì người dùng sẽ nhập user và password. Sau khi đăng nhập thì người dùng sẽ được sử dụng các chức năng cho phép.
Nhập thông tin khách hàng: Khi có một hợp đồng mới được ký, nhân viên kinh doanh sẽ đăng nhập vào hệ thống và nhập các thông tin của khách hàng này vào hệ thống. Kết quả là thông tin của khách hàng sẽ được lưu lại trong cơ sở dữ liệu.
Sửa thông tin khách hàng: Nếu khi nhập thông tin bị sai lệch thì nhân viên nhập thông tin cho khách hàng đó sẽ có nhiệm vụ sửa lại thông tin bị sai. Kết quả thông tin chỉnh sửa của khách hàng sẽ được lưu lại trong cơ sở dữ liệu.
Xem danh sách khách hàng: Mỗi nhân viên được cấp user và password đều có thể xem danh sách khách hàng. Sau khi nhân viên chọn chức năng xem danh sách khách hàng thì hệ thống sẽ hiển thị danh sách khách hàng cùng với các tiêu chí mà nhân viên đó muốn xem.
Tìm kiếm khách hàng: Người dùng nhập thông tin tìm kiếm có thể là tên công ty hoặc tên đại diện hợp đồng, sau khi nhập thông tin này thì hệ thống sẽ hiển thị những khách có thông tin giống như thông tin tìm kiếm.
Thống kê nợ: Nhân viên kế toán có thể thực hiện chức năng thống kê nợ theo tháng, theo quý, theo năm. Sau khi chọn chức năng này thì hệ thống sẽ hiển thị ra danh sách những khách hàng còn nợ, số tiền nợ của từng khách hàng, và tổng tiền nợ theo tiêu chí thống kê tương ứng.
Cập nhật tình hình thu nợ: Khi khách hàng trả tiền hàng, hoặc trả nợ hàng đã mua thì nhân viên kế toán cần cập nhật lại thông tin trả nợ của khách, đồng thời thêm vào trường ghi chú ngày trả và đợt trả. Với mỗi lần đòi nợ, khách hàng có thể trả hoặc không thì nhân viên kế toán cũng ghi lại vào trường ghi chú ngày đòi,tình hình trả của khách
hàng đó. Kết thúc quá trình thanh toán thì nhân viên phụ trách việc thu hồi nợ cần thêm vào trường ghi chú nhận xét về việc thanh toán của khách hàng đó.
Thoát khỏi ứng dụng: Khi không dùng ứng dụng nữa người dùng sẽ chọn chức năng thoát khỏi ứng dụng. Khi chọn chức năng này thì không thể thực hiện bất kỳ chức năng nào khác trong ứng dụng nữa.
Sau khi mô tả xong thì các Use Case được chuyển sang trạng thái đích là Analyzed
Nhóm phát triển đã tiến hành phân tích từng Use Case trên xem có thể chia nhỏ nữa được không để sẵn sàng cho việc viết code và kiểm thử.
- Kiểm tra và chỉnh sửa lại ca sử dụng: Nhóm đã xem xét và thấy rằng chức năng phân quyền người dùng là không cần thiết vì hoạt động này đã được thực hiện trong chức năng thêm người dùng nên quyết định bỏ chức năng này.
Sau các hoạt động này thì bảng trạng thái Use Case được cập nhật lại như hình 3.18: Hình 3.17: Use Case Slice ở trạng thái Analyzed.
3.3.3 System
Trạng thái cần đạt được của Alpha System trong giai đoạn này là Production Quality Achieved.
Các công việc của giai đoạn này được thể hiện trong Work Pad như hình 3.20: Hình 3.18: Bảng Use Case Game Board khi Requirement đạt trạng thái Stable.
- Xác định kiến trúc cho ứng dụng: Nhóm xây dựng bản thiết kế kiến trúc cho ứng dụng để đáp ứng được các chức năng yêu cầu của người sử dụng.
- Nhóm bắt đầu xây dựng một vài chức năng ban đầu như trong kế hoạch của dự án.
- Cùng với việc xây dựng chức năng thì việc viết test case cũng được thực hiện. - Thực hiện kiểm thử các chức năng đã hoàn thành:
Hình 3.20: Các nhiệm vụ cần thực hiện để System đạt được trạng thái Production Quality Achieve.
- Sau khi có kết quả test thì tiến hành phân tích xem có lỗi không, lỗi được đưa lên bảng quản lý lỗi.
Hình 3.23: Xác nhận lỗi.
- Sau khi sửa lỗi xong thì những lỗi đã được sửa đạt trạng thái Closed
Sau khi đã sửa xong các lỗi ở những chức năng đã kiểm thử thì tiến hành kiểm thử lại, sau khi hoàn thành việc kiểm thử ở những chức năng đã hoàn thành thì cập nhật lại trạng thái trong bảng kiểm thử.
- Tích hợp các chức năng đã hoàn thành vào hệ thống và gửi cho người sử dụng kiểm chứng lại những chức năng đã hoàn thiện xem có đạt yêu cầu đặt ra hay không.
Hình 3.24: Cập nhật lại những lỗi đã được sửa.
3.3.4 Project
Trạng thái đích của giai đoạn này là Rick Under Control: Do đây là dự án nhỏ, nhóm phát triển rất thành thạo công cụ lựa chọn, chỉ có vấn đề là thời gian thực hiện dự án hơi ngắn tuy nhiên nhóm đã xác định khắc phục bằng cách làm thêm giờ để đạt tiến độ. Nên rủi ro của dự án là hầu như không có, các mục tiêu của dự án đang dần hoàn thành theo đúng kế hoạch đề ra ban đầu. Do đó mục tiêu tiếp theo của dự án sẽ là Development Complete
3.3.5 Team
Trạng thái đích của Team trong giai đoạn này là Collaborating.
- Focused: Nhóm tập trung hoàn thành nhiệm vụ của nhóm, các thành viên trong nhóm tích cực hoàn thành nhiệm vụ của mình. Trong quá trình làm việc thì các thành viên trong nhóm được anh Long tích cực hỗ trợ về mặt kỹ thuật khi gặp khó khăn.
Hình 3.26: Project Game Board với mục tiêu là Development Complete.
- Collaborating: Các thành viên trong nhóm đoàn kết, hỗ trợ giúp đỡ lần nhau hoàn thành mục tiêu đề ra, công việc luôn tiến triển tốt. Mỗi khi hoàn thành một modul nhóm luôn có một cuộc họp ngắn để rút kinh nghiệm và giải đáp những khó khăn mà các thành viên khách gặp phải. Do vậy trạng thái của các thành viên trong nhóm đổi thành Integrated.
3.3.6 Way of Working
Mục tiêu đạt được của Way of Working trong giai đoạn này là trạng thái Essential in Place. Mục đích của trạng thái này là xác định lựa chọn những công cụ hỗ trợ cho công việc của nhóm và hỗ trợ việc cộng tác nhóm để đạt mục tiêu đề ra. Để đạt được điều này nhóm đã sử dụng công cụ quản lý code và quản lý lỗi, nhờ vậy mà việc cộng tác trao đổi giữa các thành viên dễ dàng hơn.
Ví dụ: Mỗi khi nhân viên kiểm thử phát hiện lỗi sẽ cập nhật lên bảng quản lý lỗi, người phát triển sẽ vào đó xem các chức năng nào còn lỗi để sửa chữa hay phản hồi về các lỗi đó.
3.4 Giai đoạn hoàn thành
3.4.1 Opportunity
Lúc này một số chức năng đã được hoàn thiện và tích hợp dần vào hệ thống, người sử dụng đã dùng thử một số chức năng hoàn thành và họ nhận thấy đã đạt được những yêu cầu đề ra ban đầu, giải quyết một số khó khăn trong công việc của họ. Lúc này trạng thái Problem Adressed đã đạt được.
3.4.2 Requirement
Lúc này các thành viên trong nhóm đang hoàn thiện nốt các chức năng còn lại, nhân viên kiểm thử đang kiểm thử các chức năng còn lại của ứng dụng xem có thỏa mãn yêu cầu đặt ra ban đầu hay không.
Kết thúc giai đoạn này thì các chức năng đã được hoàn thiện hết và được kiểm thử, một số chức năng phát hiện lỗi đã được gửi cho nhóm lập trình sửa chữa lại và cập nhập lại thành công.
3.4.3 System
Trạng thái mục tiêu của giai đoạn này là Release Candidate.
Để đạt được trạng thái này thì nhóm tích cực hoàn thành nốt các chức năng còn lại. Khi các chức năng đã hoàn thiện thì bảng Component được cập nhật lại
Thực hiển kiểm thử và tích hợp vào hệ thống, kiểm thử toàn hệ thống, trạng thái của bảng Test Game Board cũng được cập nhật lại thành Evalued. Sau Khi hoàn thành các công việc trên thì trạng thái này đã đạt được đồng thời trạng thái của Alpha Requirement đã đạt được Fulfilled. Và trạng thái đích hướng tới của Alpha System là Release.
3.4.4 Team
Nhóm tiếp tục cộng tác với nhau để hoàn thành nốt các công việc còn lại. Các thành viên trong nhóm vẫn sử dụng các công cụ nêu ra để phục vụ cho việc cộng tác được tốt hơn và hoàn thành mục tiêu đề ra.
3.4.5 Project
Lúc này dự án gần đã hoàn thành và có đầy đủ các chức năng ban đầu đặt ra, đạt tiến độ như kế hoạch, trạng thái đã được chuyển sang Development Complete. Ứng dụng chuẩn bị đưa vào triển khai chạy thử trong môi trường thực để nhận phản hồi từ người dùng.
3.4.6 Way of Working
Trong quá trình hoàn thành nốt các chức năng còn lại nhóm vẫn tiếp tục sử dụng các công cụ hỗ trợ cho công việc của mình, các thành viên trong nhóm sử dụng các công cụ ấy một cách thành thạo không cần suy nghĩ, nhờ có việc sử dụng thành thạo
các công cụ đó trong việc phát triển và cộng tác làm việc mà công việc tiến triển ngày một nhanh chóng hơn. Trạng thái đạt được ở giai đoạn này là Embedded.
3.5 Giai đoạn chuyển giao
3.5.1 Opportunity
Người sử dụng đã nhận thấy rõ hiệu quả của hệ thống ứng dụng phục vụ vào công việc của mình, giải quyết được các khó khăn gặp phải trong công việc nhờ đó mà hiệu quả công việc được tốt hơn.
3.5.2 Requirement
Tất cả các chức năng đã hoàn thành đáp ứng mọi yêu cầu đặt ra.
3.5.3 System
Hệ thống mang đi triển khai trong môi trường thực, đồng thời xây dựng tài liệu hướng dẫn sử dụng, hướng dẫn cài đặt. Chị Hòa chịu trách nhiệm hướng dẫn cho người
Hình 3.32: Requirement đã đạt được trạng thái Fulfilled.
dùng sử dụng ứng dụng và giải quyết những thắc mắc của người dùng, nhận phản hồi của người dùng về ứng dụng.
3.5.4 Team
Lúc này nhiệm vụ của nhóm là triển khai ứng dụng tới người dùng, khi hoàn thành việc triển khai thì nhóm được giải tán không còn thực hiện nhiệm vụ liên quan đến dự án này nữa. Nhóm có thể cùng nhau làm việc ở các dự án khác hoặc không làm việc cùng nhau nữa.
3.5.5 Project
Dự án đã hoàn thành đúng tiến độ và hoàn thành các chức năng như ban đầu, công việc bàn giao cho người sử dụng được tiến hành, người dùng hài lòng với ứng dụng mà nhóm đã phát triển.
Hình 3.33: System đã đạt được trạng thái Released.
3.5.6 Way of Working
Do công việc đã hoàn thành, ứng dụng đã được bàn giao cho người sử dụng mang vào ứng dụng trong thực tế nên cách làm việc không còn dùng nữa. Tuy nhiên các tài liệu về dự án được lưu giữ lại ở phòng IT để nếu sau này có phát triển tiếp thì có thể dùng nó làm tham khảo hoặc có thể dùng nó làm tham khảo cho các dự án khác. Trạng thái kết thúc của Alpha này là Hand Over.
Hình3.35: Project đã hoàn thành việc chuyển giao.
CHƯƠNG 4 - NHẬN XÉT, ĐÁNH GIÁ, THẢO LUẬN
Sau quá trình tìm hiểu vể SEMAT và công cụ EssWork, tôi có một số nhận xét và đánh giá như sau:
4.1 Ưu điểm của SEMAT
Áp dụng SEMAT sẽ giảm thiểu những rủi ro trước khi bắt tay vào việc thực hiện dự án. Bởi trước khi xác định yêu cầu thì trong hướng dẫn của Kernel còn cần phải xác định một loạt các điều kiện khác như: Xác định xem liệu giải pháp đưa ra có thực sự có lợi ích không? Lợi ích đó là gì? Có khả thi không? (chính là một số trạng thái ban đầu của Alpha Opportunity) Những người sử dụng có đồng ý với giải pháp nêu ra không? Nếu tất cả những điều kiện đó được đáp ứng thì mới đi tới bước tiếp theo là xác định yêu cầu. Rõ ràng việc xác định trước những điều đó sẽ giúp cho dự án có tính an toàn cao hơn là việc mất thời gian xác định các yêu cầu người dùng, xác định xong chức năng của ứng dụng rồi mới thấy dự án không thể tiến hành vì một lý do nào đó như: Kinh phí không đảm bảo, kỹ thuật quá phức tạp mà trình độ của đội dự án không thể đáp ứng để hoàn thành…
Kernel trong SEMAT giúp theo dõi sự phát triển của dự án một cách thuận lợi, người dùng có thể theo dõi bằng cách gắn mỗi trạng thái của từng Alpha lên bảng, nếu trạng thái nào hoàn thành thì được chuyển sang bên trái của bảng, trạng thái nào chưa hoàn thành thì để ở bên phải. Nhờ đó có thể dễ dàng biết được họ đang ở giai đoạn nào, vị trí nào của dự án và đích họ cần đến là gì. Việc tới đích như thế nào lại có các hướng dẫn thực hiện công việc trong từng trạng thái.
Các hướng dẫn để đạt được từng trạng thái thì rõ ràng và ngắn gọn. Các trạng thái trong từng Alpha được trình bày thông qua Card, trong mỗi Card chứa các hướng dẫn để đạt được trạng thái đưa ra, có hai loại Card là Card định nghĩa và Card chi tiết. Nếu người dùng có chỗ nào chưa rõ có thể tham khảo ở Card chi tiết. Các Card này được trình bày dưới dạng các gạch đầu dòng hoặc những câu ngắn gọn chứ không phải là văn xuôi dài nên người phát triển có thể nắm bắt nhanh chóng các hướng dẫn. Tuy là các hướng dẫn
ngắn gọn nhưng lại rất chi tiết nó giúp người mới phát triển phần mềm không bỏ qua những việc làm cần thiết gây ra những sai sót sau này.
Quá trình hoàn thành từng nhóm công việc luôn được chỉ dẫn cặn kẽ thông qua sự tiến triển các trạng thái, từ trạng thái bắt đầu đến trạng thái kết thúc. Mỗi trạng thái lại có các hướng dẫn riêng gọi là các Checklist, nó giúp người làm dự án đạt được tới đích chính một cách chính xác mà không bị đi sai đường hoặc bỏ qua một công việc nào đó dẫn đến kết quả bị sai lệch. Ví dụ để xác định được yêu cầu của khách hàng thì không phải chỉ có một việc là đưa ra ngay các yêu cầu mà phải trải qua một loạt các công việc như: Ban đầu là xác định những điều cần thiết cho hệ thống mới, sẽ có rất nhiều yêu cầu được ra ra và người phát triển cần phải xác định yêu cầu nào là cần thiết và cần giới hạn lại tập các yêu cầu, tiếp theo là loại bỏ bớt các yêu cầu, tiếp tục làm công việc chỉnh sửa, loại bỏ thì sẽ thu được tập các yêu cầu, nhờ có một loại các công việc như thế mà yêu cầu khách hàng không bị xác định sai.
Sử dụng Kernel tránh được sự không thống nhất yêu cầu của ứng dụng giữa khách hàng và nhóm phát triển bởi khi có sự không thống nhất về yêu cầu thì lại có sự hướng dẫn ở Alpha Stakeholder trong trạng thái In Agreement, trong trạng này đã hướng dẫn khi có sự không thống nhất về yêu cầu chức năng của ứng dụng giữa người phát triển và những người sử dụng ứng dụng thì cần phải có sự thỏa thuận giữa hai nhóm này, người sử dụng sẽ có một tập các yêu cầu tối thiểu cần đạt được và nhóm phát triển sẽ phải hoàn thành các yêu cầu thỏa mãn tập tối thiếu công việc đó.
Những hướng dẫn của Alpha Team giúp người quản lý dự án và trưởng nhóm làm tốt