Người xưa dạy: "Tiên trách kỷ, hậu trách nhân". Dân mình thì thường "Tiên trách nhân". Cũng Ok con dê, có nhiều bài thế lắm rồi ;)), nhưng giờ là lúc phải "Hậu trách kỷ"
Đã có ai tự hỏi, tại sao mình có CMMi5, mình cũng biết tất cả các process chuẩn để làm phần mềm. Cũng biết là phải tạo URS, SRS, SAD, SDD, Test Case. Code thì đầy dẫy sample trên Internet, chúng ta cũng biết OO, OOAD. Sao các sản phẩm phần mềm của chúng ta vẫn không đạt được chất lượng cao.
Cũng như bao người khác, tôi cố công đi tìm lý do của việc đó. Thật ra việc này bắt đầu từ khoảng 1 năm về trước khi mà tôi nhận ra có một cái gì đó không ổn lắm trong quá trình làm phần mềm ở FSOFT. Nó làm tôi nhớ lại một câu chuyện về xảy ra trong thời kỳ kháng chiến chống Pháp, quân ta đã bỏ ra rất nhiều công sức để cố tìm ra cách làm ra một khẩu súng. Chúng ta có thể dễ dàng làm được hầu hết mọi phần của khẩu súng. Báng súng, nòng súng, cò súng, kim hỏa, đạn, ống ngắm. Nhưng rốt cục, khẩu súng không hoạt động được. Lý do rất đơn giản là nằm ở một bộ phận bé tí của khẩu súng cái KIM HỎA. Cứ mỗi lần chúng ta bắt đầu thử bắn một loạt đạn đầu tiên thì cái KIM HỎA lại bị nát toét. Như thế ta vẫn có một khẩu súng hay chính xác hơn là một cái gọi là khẩu súng. Chỉ mỗi cái nó không work được.
Tôi nghĩ, nếu cái mà tôi đang tìm kiếm gọi là KIM HỎA thì cũng không chuẩn xác lắm vì tự mình làm nó quá quan trọng. Có lẽ nó giống hơn với một hoặc một vài cái ốc vít còn thiếu. Nó có thể không phải là phần chính của khẩu súng, nhưng thiếu nó thì khẩu súng work không ngon, thậm chí là không work được.
Giả sử, khẩu súng của chúng ta bao gồm có URS, SRS, SDD, Code. Công việc của tôi là tìm ra các ốc vít bắt giữa các thành phần theo thứ tự lần lượt (ở đây, assume là tôi sử dụng water fall process để làm súng). Có thể tôi không thể tìm được tất cả các ốc vít cần thiết, hoặc tìm ra một serial các ốc vít lởm khởm, nhưng cũng mạnh dạn xin trình bày một dưới dạng một series các bài viết. Có gì các cao thủ đầu mưng mủ đu đủ bổ xung nhé ;)
Hãy bắt đầu từ tình huống đơn giản nhất. Tôi có một khách hàng không biết gì về Software, họ chỉ biết đến yêu cầu phải có một phần mềm được mô tả trong một tài liệu mà tôi tạm gọi là URS. Nhiệm vụ của tôi là phải phân tích và chuyển hóa từ ngôn ngữ người sử dụng thành ngôn ngữ mà đội làm phần mềm có thể hiểu được dưới góc độ làm phần mềm. Công việc "phân tích và chuyển hóa" được tôi tạm define là cái ốc vít bắt giữa ngôn ngữ người sử dụng (URS) và tài liệu đặc tả phần mềm (SRS). Có rất nhiều cách để làm cái ốc vít này, tôi chỉ xin trình bày một phương pháp đơn giản mà ai cũng có thể làm được. Nó gọi là Textual Analysis
Giả sử khách hàng gửi cho chúng ta có một requirement đầu tiên với tóm tắt như sau:
"
Develop an system that support student to enroll to a school. A student can enroll into a course using the online enrollment system.
He/she must be a student of the school in order to enroll a course. After that, he/she can browse through the list of available courses of the department that he/she is belong to. The basic information of each course including course title, prerequisites, teacher and duration of each course are listed so that student can choose the one that he/she wants to enroll into.
"
Xuất phát từ khái niệm cơ bản nhất về làm software. Software = Data + Algorithm. Tôi cần phải định nghĩa được đâu là Data, đâu là Algorithm. Với bài toàn quản lý kiểu này, tôi tạm tôi xin tạm thay khái niệm Algorithm bằng khái niệm Behaviors. Cộng thêm với khái niệm OO, tôi có các objects có data và có các behaviors của riêng mình nên tôi sẽ coi một software = Tập hợp của nhiều Object.
Như vậy tôi sẽ có: Software = tập hợp của các Objects = tập hợp của (Data + Business)s. Như vậy công việc của tôi ở đây là đi tìm ra các Objects với các Data và Business đi kèm theo Object đó.
Tôi sẽ bắt đầu bằng việc đi tìm ra các Objects của chương trình sẽ sử dụng. Nhìn vào requirement, tôi có thể dễ dàng nhận ra các khái niệm sau sẽ có dạng Object (Những từ bôi đỏ) Một số các behaviors của các objects (các từ bôi vàng)cũng bắt đầu có thể nhận ra. Thậm chí một số data cũng đã xuất hiện tuy nhiên chưa đầy đủ lắm, một số data của object này bản chất lại là một object nên xin không bôi màu. Tôi xin liệt kê ra như sau:
- Student
- Data: School, Course, Department
- Behaviors: Enroll, Browse, Choose
- Course:
- Data: Course Title, Prerequisites, Teacher, Duration
- Behaviors:
- School
- Data:
- Behaviors:
- Department
- Data: Course, student
- Behaviors:
- Teacher
- Data:
- Behaviors:
Rõ ràng, ở đây vẫn còn thiếu khá nhiều thứ. Đó sẽ là những thứ mà tôi sẽ cần phải workout với khách hàng trong lần gặp nhau tiếp theo hoặc thông qua email. Nhưng về tổng thể, tôi bắt đầu hình dung được về cơ bản tôi sẽ phải làm gì trong bản SDD
Nếu giả sử khách hàng yêu cầu viết SRS theo phương pháp Use Case Approach, Với những thứ này, tôi có thể viết tạm được một Use Case Diagram cơ bản với Actor là Student, ba Use cases tương ứng là Enroll, Browse, Choose trong đó Choose và Browse sẽ có mối quan hệ nhất định mà tôi cần define ra sau này. Một Pre-condition là must be a student of the school.Tất nhiên cũng vẫn còn thiếu nhiều thứ. Cứ từ rồi khoai sẽ nhừ vậy :))
Như thế, tôi tạm có một cái gì đó cơ bản nhất để có thể bắt đầu. Tạm thời tôi sẽ gọi cái này là ỐC VÍT MỘT. Trong bài sau, tôi sẽ trình bày về "ỐC VÍT HAI" theo cách của tôi để chuyển hóa tiếp từ những thứ này sang SDD.
Nhờ các cao thủ review và đóng góp ý kiến nhé. Cái này serious đấy. Bọn em đang định xây dựng một chương trình training đầy đủ từ đầu đến cuối cho mấy cái món này. Vẫn đang mò mẫm nêu nếu các bác đóng góp ý kiến thì xin hậu tạ. Em thì chẳng giầu có gì, chỉ hậu tạ được bữa café. Coi như của ít lòng nhiều :)
Notes:
- Bài viết chỉ áp dụng cho việc làm software cho các hệ thống hướng OO và sử dụng phương pháp Use Case Approach.
- Vì lý do SAD sẽ cần phải có nhiều dữ liệu đầu vào hơn và cũng khó hơn nên sẽ xin trình bày trong một series khác.
- Thêm nữa, rất quan trọng đây này "Tác giả không chụi trách nhiệm về các hậu quả nếu áp dụng vào một dự án mà nó lại lăn quay ra chết, he he he"
Posted 10/15/2009 12:28:13 AM by 
