Thông tin Tốt nghiệp - Capstone
02/03/2012 01:38:26 PM

Hướng dẫn dự án Capstone - phần 1

 

Nhiều sinh viên đã viết cho tôi hỏi xin giúp đỡ về dự án Capstone của họ. Vì đây là dự án "thực" đầu tiên, nhiều người lo lắng và không chắc về phải làm gì. Dựa trên yêu cầu của họ, tôi đã viết bản hướng dẫn tóm tắt cho dự án Capstone dựa trên điều tôi đã dạy ở Carnegie Mellon (mỗi trường có thể khác) mà một số trong các bạn có thể thấy nó là hữu dụng:

Dự án Capstone được thiết kế để giúp cho sinh viên kinh nghiệm việc phát triển phần mềm "thế giới thực". Qua vài tháng tiếp, tổ của bạn sẽ thiết kế và xây dựng sản phẩm phần mềm bằng việc dùng tri thức bạn đã học trong ba năm quá khứ trong trường. Đây là cơ hội cho bạn áp dụng tri thức của bạn và chuyển nó thành kĩ năng "thực". Bằng việc tuân theo hướng dẫn này, bạn sẽ học các kinh nghiệm có giá trị trong làm việc tổ, giải quyết vấn đề, qui trình phần mềm, và quản lí dự án. Đây là những kĩ năng mà công nghiệp phần mềm cần và mong đợi người tốt nghiệp biết.

Ngày nay phát triển phần mềm vẫn còn có vấn đề. Nhiều dự án không đáp ứng lịch biểu của chúng. Ngay cả khi được chuyển giao, nhiều sản phẩm phần mềm chưa bao giờ được dùng vì chất lượng thấp. Điều đáng quan tâm là các dự án này không thất bại bởi vì các lí do kĩ thuật mà chúng thất bại do quản lí dự án kém và làm việc tổ không hiệu quả. Nói cách khác, chúng thất bại do các lí do có liên quan tới "qui trình" hơn là "công nghệ". Đó là lí do tại sao trong các dự án Capstone, điều quan trọng nhất mà sinh viên phải học là "làm việc tổ" và "qui trình" như lập kế hoạch, quản lí và thực hiện dự án phần mềm.

Phát triển phần mềm là hoạt động phức tạp. Mặc dầu các ngôn ngữ lập trình và công cụ cho phép người phát triển viết nhiều mã nhanh hơn, nhưng viết mã chỉ đại diện cho một phần nhỏ của hoạt động phát triển phần mềm. Học về phát triển phần mềm hiệu quả, tổ của bạn phải tuân theo cách tiếp cận vòng đời phần mềm và tạo ra một loạt các tài liệu. Tổ của bạn được yêu cầu đệ trình các báo cáo pha dự án được viết ra trong toàn thể dự án capstone. Các báo cáo này được dùng để làm tài liệu cho tiến bộ của tổ và để nhận diện các vấn đề mà tổ tìm ra. Các báo cáo này là công cụ có giá trị cho quản lí dự án và tự đánh giá của tổ. Chúng cũng cung cấp cho giáo sư của bạn các thông tin họ cần để đánh giá hiệu năng của tổ và cung cấp hướng dẫn cho tổ trong dự án Capstone project.

Trước khi bạn bắt đầu, có vài điều bạn cần biết: Bạn phải KHÔNG BAO GIỜ nhảy vào viết mã như bạn nghĩ bạn có thể làm. Đây là vấn đề thông thường trong các sinh viên. Nhiều người nghĩ họ đã biết về giải pháp cho nên họ bắt đầu viết mã ngay. Đó là lí do tại sao nhiều dự án Capstone thất bại. Xin nhớ cho rằng dự án Capstone KHÔNG phải là phân công nhiệm vụ trong lớp lập trình. Bạn không học về Java, PHP, hay C++ ở đây. Bạn đã học chúng trong các năm trước và không cần lặp lại ở đây. Dự án Capstone là về thực hiện vòng đời phát triển phần mềm. Nó sẽ giúp bạn hiểu mọi bước cần thiết để xây dựng chất lượng của sản phẩm phần mềm. Xin nhớ cho rằng viết mã chiếm ít hơn 20% của mọi công việc được cần tới trong dự án phần mềm điển hình. Không dự án nào đã bao giờ thất bại vì viết mã nhưng bởi vì mọi người KHÔNG tuân theo qui trình. Cho nên bạn phải học về qui trình phần mềm và không bỏ qua bất kì bước nào. Một khi bạn học mọi bước này, bạn cũng phát triển kĩ năng phát triển riêng của bạn và do đó không có vấn đề gì khi làm việc trong công nghiệp phần mềm.

Phần lớn các dự án Capstone được trao cho bạn bởi các công ti bên ngoài (khách hàng) trong cộng tác với đại học của bạn. Về truyền thống, khách hàng cho đại học của bạn bản đặc tả yêu cầu phần mềm (SRS) cho dự án Capstone. Phần lớn thời gian, yêu cầu là mông lung và không được xác định rõ (Tất nhiên, nó là được dự định cho bạn học về phân tích yêu cầu). Như một tổ, bạn phải kiểm điểm yêu cầu một cách cẩn thận để nhận diện từng cấu phần hệ thống và chức năng. Tổ của bạn phải hiểu điều khách hàng (công ti phần mềm bên ngoài) muốn tổ thực hiện. Tất nhiên, bạn phải biết cái gì đó về khách hàng. Bước đầu tiên là tổ viết ra phát biểu ngắn mô tả công việc của khách hàng của bạn và cách họ vận hành như họ là ai, họ làm gì v.v. (Bạn học về kinh doanh của họ). Sau đó, bạn phải phỏng vấn khách hàng để hiểu sản phẩm và dịch vụ của họ. Bạn muốn biết cách họ làm công việc, cách họ giải quyết thông tin, cách họ phát triển phần mềm (bạn học về qui trình công việc của họ). Bạn phải kiểm điểm công nghệ họ dùng để hiểu nhu cầu của họ và các lí do tại sao họ muốn tổ của bạn làm việc trên dự án này. Bằng việc hỏi họ, thảo luận với họ tổ của bạn sẽ biết nhiều thêm về qui trình của khách hàng và yêu cầu của họ (Xin ôn lại tài liệu của lớp kĩ nghệ yêu cầu).

Một khi tổ của bạn biết lí do và yêu cầu của khách hàng, bạn có thể bắt đầu viết ra phát biểu viễn kiến mô tả dự án capstone bằng những cấu phần hệ thống riêng mà tổ bạn phải phát triển để đáp ứng cho nhu cầu của khách hàng. Bạn có thể không có khả năng đáp ứng được tất cả mọi yêu cầu mà khách hàng đã trao cho đại học của bạn, cho nên giới hạn viễn kiến của bạn vào các cấu phần khả thi và hữu dụng. (Đây là "thủ đoạn" thông thường trong các dự án Capstone, vì khách hàng bao giờ cũng đòi hỏi nhiều cho nên bạn phải áp dụng kĩ năng phân tích và thương lượng ở đây - Đây là chỗ bạn cũng học kĩ năng mềm: Kĩ năng thương lượng). Bạn phải giải thích cho khách hàng của bạn rằng tổ của bạn muốn nhận diện vấn đề, hay nhu cầu mà dự án Capstone của bạn sẽ giải quyết cho khách hàng. Bạn phải nhận diện khách hàng và người dùng của hệ thống được đề nghị và cách sản phẩm mà tổ bạn dựng có thể giúp cho họ. (Đây là phần mấu chốt của mọi dự án phần mềm. Tổ của bạn phải có khả năng thuyết phục khách hàng xác định phạm vi của dự án và giới hạn các yêu cầu vào cái gì đó mà tổ của bạn có thể thực hiện được trong thời gian hợp lí. Kĩ năng thương thảo của bạn là rất quan trọng ở đây).

Vì khách hàng có thể không quen thuộc với điều bạn đề nghị (họ bao giờ cũng nói rằng họ không hiểu thuật ngữ kĩ thuật), tổ của bạn phải tạo ra tập các biểu đồ use case trường hợp sử dụng (chỉ ra các tác nhân, qui trình, biên hệ thống) cho hệ thống. Phải chắc đưa vào các chức năng quản trị bản chất trong biểu đồ của bạn. Viết lời dẫn tóm tắt cho từng use case với việc giải thích use case đó. Chỉ ra mức ưu tiên của các use case như # 1 cho use case bản chất đối với vận hành hệ thống; # 2 cho use case là không bản chất với vận hành hệ thống nhưng sẽ tăng thêm giá trị đáng kể cho người dùng hệ thống; và # 3 cho use case sẽ thêm một số giá trị nhỏ cho người dùng hệ thống. Mô tả vắn tắt mọi tác nhân (người dùng, hệ thống hay tổ chức) những người tương tác với hệ thống của bạn, như được chỉ ra trong biểu đồ của bạn. Đừng giả định rằng nghĩa của bất kì use case, tác nhân, hay chức năng nào bị bỏ qua cho khách hàng của bạn; mô tả của bạn phải rất rõ ràng và không nhập nhằng. (Xin ôn lại tài liệu lớp yêu cầu về chỉ dẫn cách thực hiện điều đó).

Bằng việc dùng các kịch bản use-case, tổ của bạn sẽ hiểu nhiều hơn về các yêu cầu chức năng của dự án Capstone. Nó cũng làm cho mọi cấu phần được đề nghị thành thấy được nhiều hơn đối với khách hàng của bạn khi bạn thương lượng và thảo luận với họ về phạm vi của dự án. (Cái gì cần giữ và cái gì không cần giữ trong thương lượng). Tổ phải kiểm điểm phạm vi và độ phức tạp của hệ thống được đề nghị của bạn và ước lượng công việc tham gia vào đó. (Đây là chỗ công việc tổ thành rất mấu chốt vì bạn thảo luận với từng thành viên tổ về thời gian và nỗ lực cần dành ra để hoàn thành các nhiệm vụ này. Nhớ rằng đây chỉ là ước lượng sơ khởi, mọi người đều có ý kiến riêng của họ, tổ phải học cách cộng tác để đi tới ước lượng hợp lí.)

Từng thành viên tổ phải ước lượng nỗ lực được cần tới (theo man-hours), để hoàn thành các pha phân tích yêu cầu và thiết kế của dự án. Họ phải giải thích cách ước lượng của họ được suy ra cho các thành viên tổ khác để cho cùng nhau họ có thể đi tới ước lượng toàn thể của cả tổ. (Có thể làm ước lượng trung bình ở đây, nếu một nửa tổ đi tới 100 man-hours và nửa kia ước lượng 200 man-hours thì bạn có thể đồng ý điều chỉnh ước lượng tổng thể là 150 giờ).

Từng thành viên tổ phải ước lượng nỗ lực được cần tới (theo man-hours), để làm các pha xây dựng và kiểm thử của dự án. Họ có thể ước lượng nỗ lực để thực hiện điểm use case cho cả # 1 (ưu tiên cao) và # 2 (ưu tiên trung bình) nhưng không thể làm cho # 3 vì điều này nên có tính thương lượng với khách hàng hay liệu họ có muốn tổ làm điều đó không. Dùng thông tin này để ước lượng nỗ lực toàn bộ được yêu cầu để hoàn thành cả hai kiểu use case. Thành viên tổ phải giải thích được cách họ làm ước lượng. (Nhớ rằng bạn phải xem xét tới các ước lượng từ từng thành viên tổ rồi thảo luận để có sự thoả thuận của tổ về ước lượng toàn thể. Bạn sẽ học nhiều về làm việc tổ trong hoạt động này.)

Từng thành viên tổ phải ước lượng "hoạt động nỗ lực hỗ trợ" được yêu cầu cho việc quản lí dự án, họp, viết, kiểm điểm, báo cáo, làm tài liệu, viết mã và kiểm điểm thiết kế, tích hợp và kiểm thử mức hệ thống, các kĩ năng học và kĩ năng phát triển khác như học công nghệ mới, hoạt động đảm bảo chất lượng QA và các qui trình khác hay các vấn đề quản lí qui trình có liên quan tới dự án của bạn hay tổ của bạn. (Đây là lí do tại sao nhiều dự án phần mềm thất bại bởi vì nhiều người quản lí dự án quên tính tới những nỗ lực hỗ trợ này vì họ chỉ làm ước lượng về khía cạnh kĩ thuật mà không có khía cạnh hỗ trợ. Đó là lí do tại sao nhiều dự án đã không đáp ứng lịch biểu.)

Tổ phải trình bày phân tích yêu cầu và các ước lượng dự án (Đây vẫn là ước lượng sơ khởi vì phạm vi vẫn còn đang được thương lượng với khách hàng). Bạn phải làm tài liệu cho những hoạt động này và có khả năng giải thích cho khách hàng và giáo sư của bạn trong bài trình bày dưới dạng họ có thể hiểu được. Bạn phải nói rõ ràng và biện minh cho bất kì giả định nào bạn đã làm trong ước lượng của bạn. Dựa trên ước lượng nỗ lực của bạn (theo Man-hours), bạn phải giải thích chính xác trường hợp sử dụng use case nào mà tổ của bạn sẽ thực hiện cho dự án này cũng như ước lượng về tổng nỗ lực công việc theo thời gian lịch biểu nhà trường. Tất nhiên bạn phải giải thích các lí do của bạn tại sao tổ của bạn ra quyết định đó (Hoạt động này sẽ giúp cho bạn học kĩ năng trình bày, kĩ năng thương lượng, kĩ năng cộng tác, và kĩ năng lắng nghe – những kĩ năng mềm này là bản chất trong công nghiệp phần mềm). Tất nhiên khách hàng có thể không đồng ý (Họ bao giờ cũng làm điều đó trong mọi dự án Capstone vì họ muốn thấy thêm về kĩ năng mềm của bạn. Bạn cần thuyết phục họ bằng việc có các lập luận rõ ràng và logic như ưu tiên, ích lợi và lịch biểu. Đến cuối, phần lớn thời gian khách hàng đồng ý để cho bạn thực hiện mọi # 1 (ưu tiên cao) và # 2 (ưu tiên vừa) vì lịch biểu nhà trường cho phép.)

Đây là pha đầu của Capstone thường mất ít nhất một tháng (4 tuần) để hoàn thành. Nó yêu cầu tri thức về phân tích yêu cầu, biểu đồ trường hợp sử dụng use case, ước lượng, vòng đời phát triển phần mềm, lập kế hoạch dự án và kĩ năng mềm.

 

http://www.segvn.org/forum/mvnforum/viewthread_thread,1066#1740