Mô tả bài toán

Một phần của tài liệu Nghiên cứu SEMAT và ứng dụng công cụ EssWork trong phát triển phần mềm (Trang 62)

Do lượng khách hàng của công ty nhiều nên nhân viên kinh doanh không thể nhớ hết khách hàng đã từng có hợp đồng mua bán với công ty, hơn nữa các nhân viên kinh doanh của công ty có thể nghỉ làm, vì vậy nhân viên còn lại nếu có hợp đồng với các khách hàng cũ rất khó để lấy thông tin chính xác (về tình hình thanh toán, đặc điểm của quá trình thi công) của khách hàng này để tiện trong việc đàm phán các điều khoản trong hợp đồng. Vì vậy anh Hải (nhân viên kinh doanh của công ty) đã đề nghị với giám đốc công ty là anh Thi xây dựng một phần mềm quản lý khách hàng, ở đó có thể quản lý tất cả các thông tin khách hàng như: Thông tin về khách hàng (khách hàng lẻ hay khách hàng thường xuyên, địa chỉ, tên người đứng tên hợp đồng, tên công ty v.v), các hợp đồng đã có với công ty, cách thức thanh toán của hợp đồng, nhận xét về tính hình thanh toán, nhận xét chung về khách hàng v.v. Ý kiến này đã được giám đốc Thi đồng ý và đề nghị phòng IT triển khai phát triển phần mềm này.

Như vậy bài toán đặt ra là cần xây dựng một chương trình quản lý khách hàng có một số yêu cầu mà anh Hải nêu ra ở trên.

Phòng IT đã họp lại và thống nhất dùng kiến thức SEMAT và quy trình trình Essential Unified Process để áp dụng trong quy trình quản lý dự án của mình. Công cụ sử dụng hỗ trợ áp dụng SEMAT là EssWork.

Nhân viên tham gia vào đội dự án gồm có:  Anh Hải: phòng kinh doanh

 Anh Long: Quản lý dự án, trưởng nhóm kỹ thuật.  Anh Hùng: phòng IT – nhân viên coder

 Anh Thiện: phòng IT coder  Chị hòa: Phòng IT-tester.

55

Quy trình Essential Unified Process được đưa ra như sau:

Áp dụng quy trình này thì quá trình phát triển sẽ gồm bốn giai đoạn: - Inception:Giai đoạn bắt đầu.

- Elaboration:Giai đoạn phác thảo. - Construction: Giai đoạn hoàn thành. - Transition:Giai đoạn chuyển giao.

56 3.2 Giai đoạn khởi đầu

Kết quả cuối của giai đoạn này cần đạt được đó là xác định được tập các yêu cầu khách hàng, lựa chọn kiến trúc. Sau đây là là mô tả chi tiết từng Alpha trong giai đoạn này.

3.2.1 Opportunity

Nếu dự án được triển khai thì sẽ có hai cơ hội được thực thi đó là nhân viên trong công ty, cụ thể là nhân viên phòng kinh doanh và phòng kế toán sẽ được sử dụng hệ thống quản lý khách hàng bằng máy tính mà không phải quản lý bằng giấy tờ, sổ sách. Cơ hội thứ hai là sẽ có rất nhiều lợi ích thu lại khi nhân viên sử dụng hệ thống này như: Thống kê công nợ, xem thống tin khách hàng cũ một cách dễ dàng v.v.

Trạng thái hiện thời của Alpha Opportunity là trạng thái: Start. Trạng thái đích của Alpha trong giai đoạn này là: Value Established.

Các công việc cần thực thực hiện để Alpha này đạt được trạng thái đích được hướng dẫn khi ta lựa chọn Submit trạng thái. Các công việc đó được EssWork tự tạo công việc cần thực hiện trong Work Pad như hình 3.3.

57

Như vậy để đạt được trạng thái Value Established trong hai Opportunity đều cần có hoạt động là phân tích vấn đề. Cụ thể đó là: Xác định Opportunity, hiểu rõ vấn đề và xác định giá trị của cơ hội, sau khi xem hướng dẫn cụ thể từng nhiệm vụ ta có các công việc cần thực hiện được thể hiện ở bảng sau:

Trạng thái Cách thực hiện để đạt được trạng thái

Opportunity Identified

Vấn đề phát sinh đầu tiên khi anh Hải phòng kinh doanh gặp một khách hàng mà anh ấy nhớ rằng đó là khách hàng cũ, hình như là trước đây rất khó đòi nợ, người phụ trách kinh doanh lúc đó đã nghỉ và không có cách nào liên hệ lại được, lúc này anh ấy nghĩ đến nếu có một chương trình quản lý các thông tin khách hàng thì sẽ dễ dàng hơn rất nhiều. Như thế người kinh doanh sẽ và nhân viên phòng kế toán có thể dùng ứng dụng này phục vụ công việc của mình và việc dùng ứng dụng này chắc chắn sẽ có thu được nhiều lợi ích tốt.

Problem Understood

Để hiểu rõ sự cần thiết của việc xây dựng chương trình quản lý khách hàng, anh Hải đã đề nghị phòng kế toán, phòng kinh doanh và nhóm phát triển họp lại, trong cuộc họp anh ấy nêu ra những khó khăn gặp phải trong thực tế nếu không phát triển ứng dụng này như không thể biết được tình hình thanh toán của khách hàng cũ, một vài Hình 3.3: Công việc cần thực hiện với Opportunity ở giai đoạn khởi đầu.

58

đặc điểm của khách hàng cũ. Việc biết được những đặc điểm này là rất quan trọng trong quá trình xây dựng các tỉ lệ thanh toán của hợp đồng hoặc đàm phán hợp đồng, đồng thời anh ấy cũng nêu ra sự cần thiết của việc xây dựng hệ thống này và cũng lý giải việc hệ thống này sẽ giải quyết một số khó khăn mà phòng kinh doanh gặp phải, nêu ra lợi ích khi phòng kế toán được sử dụng hệ thống này.

Value Establish

Sau khi trình bày những vấn đề phòng kinh doanh gặp phải, trình bày giải pháp xây dựng chương trình quản lý khách hàng và đặc điểm cũng như lợi ích của nó, mọi người đều thấy được giá trị của giải pháp nêu ra và đồng ý đề nghị giám đốc đầu tư kinh phí xây dựng chương trình này, giám đốc đã đồng ý phê duyệt xây dựng chương trình quản lý này.

3.2.2 Requirement

Trạng thái đích của Requirement trong giai đoạn này là Shared. Sau khi nhập thông tin về trạng thái đích của Alpha Requirement lên bảng Requirement Game Board và chọn Submit, các công việc được hướng dẫn lần lượt được thể hiện trong Work Pad như hình 3.3:

59

Như vậy để đạt được trạng thái Shared của Alpha Requirement cần thực hiện lần lượt các công việc như hướng dẫn: Đặc tả yêu cầu, xác định Actor và Use Cases, chia nhỏ các Use Case, kiểm tra và chỉnh sửa lại Use Case. (adsbygoogle = window.adsbygoogle || []).push({});

- Mô tả yêu cầu cho ứng dụng: Chức năng này hoàn thành chính là trạng thái

Conceived đã đạt được. Công việc cụ thể như sau:

Anh Hải phòng kinh doanh, người đã đặt vấn đề xây dựng hệ thống quản lý khách hàng đã viết bản mô tả về các chức năng của sản phẩm, trong cuộc họp anh ấy đã trình bày cho nhóm phát triển và những người sử dụng ứng dụng những yêu cầu về chức năng mà ứng dụng cần đạt được như: Quản lý thông tin khách hàng, theo dõi tình hình nợ đọng của khách hàng, tìm kiếm khách hàng.

- Xác định Actor và Use Cases:

o Actor: Là người quản trị hệ thống, nhân viên kinh doanh, nhân viên phòng

kế toán và được gọi chung là người dùng.

o Use Case: Gồm có quản trị hệ thống, quản lý thông tin khách hàng, theo dõi

nợ của khách hàng.

Sau khi xác định được các Use Case thì nó được đưa lên bảng Use Case Game Board của công cụ EssWork:

60

- Chia nhỏ Use case:

o Ca sử dụng quản trị hệ thống: Chức năng này cho phép người quản trị hệ thống cấp quyền cho nhân viên nào được phép sử dụng hệ thống và sử dụng những chức năng nào của hệ thống. Khi có một nhân viên mới vào công ty cần dùng hệ thống thì người quản trị hệ thống sẽ tạo một người dùng mới, cấp quyền cho người dùng này. Nếu trong quá trình tạo thông tin người dùng sai thì người quản trị sẽ sửa thông tin người dùng. Nếu một nhân viên nào đó nghỉ việc thì người quản trị sẽ xóa nhân viên đó ra khỏi danh sách người dùng của hệ thống.

o Ca sử dụng quản lý thông tin khách hàng: Chức năng này gồm một loạt các chức năng nhỏ như: Tạo một khách hàng mới, sửa thông tin khách hàng vừa nhập khi có sai sót, tìm kiếm một khách hàng cũ và xem thông tin các khách hàng. Chức năng này được nhân viên kinh doanh thực hiện để hỗ trợ cho công việc kinh doanh của mình.

o Ca sử dụng theo dõi nợ khách hàng: Chức năng này được cấp cho nhân viên phòng kế toán. Khi nhân viên phòng kế toán muốn lập báo cáo để xem tháng này khách hàng còn nợ đọng bao nhiêu, những khách hàng nào còn nợ đọng hoặc khi có một khách hàng nào đó thanh toán tiền nợ thì nhân viên phòng kế toán sẽ cập nhật tình hình nợ đọng của khách hàng đó, đồng thời cũng cập nhật những ghi chú về việc đòi nợ của một khách hàng nào đó.

Các ca sử dụng trên sau khi được chia nhỏ sẽ gồm các ca sử dụng như hình các hình 3.6, 3.7, 3.8.

61

Hình 3.6: Ca sử dụng quản trị hệ thống.

62

Sau khi xác định được các Use Case ở mức thấp hơn thì các Use Case này được cập nhật lên bảng Use Cases Slice Game Board.

Sau khi hoàn thành việc chia nhỏ các Use Case thì trạng thái Use Case ban đầu được cập nhật lại thành Story Structure Understood như hình 3.9:

Hình 3.8: Ca sử dụng theo dõi nợ của khách hàng.

63

- Kiểm tra và chỉnh sửa lại các Use Case: Nhóm nhận thấy không cẩn phải chỉnh sửa các Use Case.

3.2.3 System

Trạng thái mà hệ thống cần đạt được ở giai đoạn này là Approach Selected. Sau khi Submit thì các công việc được liệt kê ở Work Pad cần thực hiện như hình 3.10:

Nhóm đã họp lại và thống nhất xác định về cấu trúc phần cứng phù hợp cho ứng dụng. Bởi tất cả thành viên trong nhóm đều thành thạo C# nên mọi người đã thống nhất dùng C# để phát triển ứng dụng, sử dụng cơ sở dữ liệu SQL, ứng dụng này sẽ được nhóm phát triển từ đầu mà không dùng lại hay mua từ một bên thứ ba nào khác. Sau khi xác định xong thì nhóm cũng xây dựng tài liệu thiết kế cho ứng dụng gồm các thành phần tạo nên hệ thống quản lý khách hàng, thiết kế giao diện cho ứng dụng.

Đồng thời xác định các modul cần được tạo gồm có các modul như hình 3.11: Hình 3.10: Các công việc cần thực hiện để đạt được trạng thái Approach

Selected của Alpha System.

64

3.2.4 Team (adsbygoogle = window.adsbygoogle || []).push({});

Trạng thái của nhóm làm việc trong giai đoạn này cần đạt được là Formed. Để đạt được trạng thái này thì nhóm cần xác định được cách tổ chức và trách nhiệm của nhóm, các thành viên trong nhóm cần đáp ứng các yêu cầu để dự án có thể phát triển tốt. Các công việc cần thực hiện để đạt được từng trạng thái trong giai đoạn này như sau:

- Trạng thái Mission Defined: Trạng thái này gồm có các nhiệm vụ là xác định cấu trúc nhóm và xác định nhiệm vụ của nhóm. Nhóm được xác định gồm năm thành viên với các nhiệm vụ cụ thể như mô tả trong bảng sau:

Tên thành viên nhóm

Nhiệm vụ

Anh Hải Nhân viên phòng kinh doanh – Người đề xuất xây dựng hệ thống: nhiệm vụ anh Hải là trung gian giữa người dùng ứng dụng và nhóm phát triển, phản hồi những thông tin từ người dùng ứng dụng với nhóm phát triển và cung cấp thông tin về quá trình phát triển ứng dụng cho những người liên quan khách.

Anh Long Quản lý dự án, trưởng nhóm kỹ thuật: Chịu trách nhiệm quản lý nhóm, lập kế hoạch quản lý phát triển dự án, hỗ trợ các thành viên trong nhóm khi gặp khó khăn, đôn đốc các thành viên trong nhóm thực hiện tốt các công việc được giao.

Anh Hùng Nhân viên lập trình: Thực hiện viết code theo nhiệm vụ được giao. Anh Thiện Nhân viên lập trình: Thực hiện viết code theo nhiệm vụ đượcgiao.

Chị Hòa Nhân viên kiểm thử: Thực viết viết test case và thực hiện test, lập báo cáo kiểm thử, hướng dẫn người dùng sử dụng ứng dụng khi ứng dụng được xây dựng xong.

65

- Trạng thái Formed: Nhóm được thành lập và trưởng nhóm phân công nhiệm vụ cho từng thành viên trong nhóm. Trách nhiệm của từng thành viên trong nhóm được mô tả như trong bảng ở phần trạng thái Mission Defined

Khi đã xác định xong các thành viên và nhiệm vụ của các thành viên thì bảng thông tin về các thành viên được cập nhật lên bảng Team Member Game Board.

3.2.5 Project

Trạng thái cần đạt được của Alpha Project trong giai đoạn này là Milestones Agreed. Công việc cần thực hiện để đạt được trạng thái này chính là lập kế hoạch từng bước để hoàn thành dự án. Anh Long đã lập kế hoạch cho dự án gồm các giai đoạn phát triển, thời gian biểu cho từng giai đoạn và các công việc cần thực hiện trong từng giai đoạn.

3.2.6 Way of Work

Trạng thái cần đạt được của Alpha Way of Work trong giai đoạn này là Opption Explored. Hoạt động để đạt được trạng thái này đó là: Quản lý dự án đã quyết định sử dụng phát triển ứng dụng theo quy trình RUP, phát triển theo hướng điều khiển kiểm

66

thử (TDD), Sử dụng Use Case để mô tả chức năng, công cụ dùng để phát triển là VS 2013 và cơ sở dữ liệu dùng ở đây là SQL.

3.3 Giai đoạn phác thảo

Ở giai đoạn này nền tảng kiến trúc đã được xác định, quy trình, cơ sở hạ tầng, môi trường phát triển cũng đã được mô tả rõ ràng.

3.3.1 Opportunity

Trạng thái cần đạt được ở giai đoạn này là Viability Establish.

Để đạt được trạng thái này thì nhóm phát triển cần xác định tính khả thi của dự án và xác nhận đại diện các bên liên quan để trao đổi thông tin giữa những người sử dụng và nhóm phát triển.

- Xác định tính khả thi của ứng dụng: Anh Long tính toán kinh phí cho việc phát triển ứng dụng, xem xét lại những khó khó khăn có thể gặp phải trong quá trình phát triển ứng dụng và thấy kinh phí cho việc phát triển thỏa mãn điều kiện kinh phí mà giám đốc duyệt, một số khó khăn khác như thời gian hoàn thành dự án hơi gấp thì nhóm phát triển có thể khắc phục được. Do vậy ứng dụng này có thể tiếp tục phát triển được.

- Xác định đại diện các bên liên quan: Người sử dụng ứng dụng này là nhân viên phòng kế toán, nhân viên phòng kinh doanh. Hai phòng này đã họp lại và quyết định anh

67

Hải sẽ là người đại diện cho ý kiến của các nhân viên của hai phòng này, sẽ có nhiệm vụ trao đổi thông tin qua lại giữa nhóm phát triển và nhân viên hai phòng.

3.3.2 Requirement

Trạng thái cần đạt được ở giai đoạn này của Alpha Requirement là Stable

Mục đích của trạng thái này là xác định chắc chắn về các yêu cầu của ứng dụng để tránh việc sửa đổi sau này. Sau khi Submit thì các nhiệm vụ cần thực hiện để Requirement đạt được trạng thái này được mô tả trong Work Pad như hình 3.12:

- Xác định kiến trúc của Requirement: Như mô tả ở phần trên thì yêu cầu của của hệ thống gồm có ba chức năng chính là quản trị hệ thống, quản lý thông tin khách hàng, theo dõi nợ khách hàng. Mỗi một chức năng này lại gồm phân cấp các chức năng nhỏ như mô tả ở các hình vẽ phần trình bày về các Actor và Use Case ở các hình 3.6, 3.7, 3.8. Các thông tin về hoạt động của từng chức năng cũng đã được mô tả trong phần 3.7. (adsbygoogle = window.adsbygoogle || []).push({});

- Chuyển trạng thái Use Case Slice thành Prepared như hình 3.16 như sau: Hình 3.14: Requirement với trạng thái đích là Stable.

Một phần của tài liệu Nghiên cứu SEMAT và ứng dụng công cụ EssWork trong phát triển phần mềm (Trang 62)