Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 8

Mô hình hóa theo cách của bạn cho một quy trình nhanh tốt hơn

Trong phần đăng gần nhất của loạt bài này, tìm hiểu cách cải thiện chất lượng của quy trình nhanh của bạn với mô hình hóa. Mô hình hóa có nhiều thuận lợi trong quy trình phát triển. Trong bài viết này, hãy tìm ra một số quan niệm sai lầm về mô hình hóa nhanh, tìm hiểu các đặc tính của các mô hình nhanh có ích và tìm hiểu cách lựa chọn mô hình để khớp nhất với dự án của bạn.

Mikko Kontio, Giám đốc, Softera

Mikko Kontio có một nền tảng về phát triển và tư vấn phần mềm. Ông hiện là Giám đốc tại Softera, một công ty phát triển phần mềm tập trung vào các cổng kinh doanh và giải pháp tính cước viễn thông.



30 10 2009

Giới thiệu

Loạt bài này đã nghiên cứu các lợi ích của các quá trình nhanh và các yêu cầu đã đặt ra cho các tổ chức có sử dụng chúng. Bạn đã học được cách các tổ chức thích ứng với sự phát triển nhanh, về các kiểu khác nhau của các bên liên quan và làm thế nào để áp dụng các câu chuyện của người dùng. Bạn đã duyệt qua nghiên cứu trường hợp và đã nhận thấy các câu chuyện của người sử dụng, cuộc thảo luận và sự ưu tiên có thể dẫn đến các phiên bản beta phát triển nhanh chóng như thế nào. Bạn đã xem xét lại các động cơ, hành vi của khách hàng và các mô hình định giá của mỗi dự án có ảnh hưởng đến sự thành công hiện tại và tương lai của một dự án phát triển như thế nào. Và, bạn đã học về đánh giá nỗ lực làm việc trong một môi trường nhanh.

Bài viết này bàn về mô hình hóa có liên quan đến sự phát triển nhanh. Hãy tìm hiểu về các quan niệm sai lầm về mô hình hóa nhanh, một mô hình nhanh tốt đòi hỏi những gì, việc lựa chọn công cụ và lựa chọn mô hình để khớp nhất với mục tiêu của bạn.


Mô hình hóa nào là không được

Có nhiều quan niệm sai về mô hình hóa phần mềm và về bạn có thể sử dụng nó ở đâu và như thế nào. Trước khi thảo luận về các mô hình nhanh có ích, phần này vạch ra một số sự hiểu lầm hoặc không đúng, về mô hình hóa phần mềm.

Các mô hình là tư liệu.
Đây là một quan niệm sai lầm phổ biến. Một số người nghĩ rằng nếu họ làm một vài mô hình, thì sau đó đó là tài liệu. Có rất nhiều thông tin nằm ngoài phạm vi của biểu đồ UML chẳng hạn, hoặc các thông tin có thể được giải thích tốt hơn như văn bản tường thuật. Các bố trí màn hình, thiết kế giao diện người dùng đồ họa (GUI) chi tiết, các luồng màn hình, các tài liệu tổng quan và các tài liệu tiếp thị tất cả có thể đưa ra sự hiểu biết sâu sắc cho nhóm phát triển. Chỉ riêng các mô hình không đủ cho tài liệu, mặc dù chúng là một thành phần quan trọng.
Mô hình hóa là chậm và không nhanh.
Nếu bạn không quen phần mềm được mô hình hóa, bạn có thể nghĩ rằng nó tốn thời gian, chậm và khó khăn. Điều quan trọng nhất cần nhớ trong ngữ cảnh này là khi bạn mô hình hóa, bạn nên luôn luôn cố gắng để thiết kế phần mềm (không chỉ vẽ các biểu đồ mà bạn cho là bắt buộc).

Bạn mô hình hóa để lên kế hoạch và thiết kế những phần quan trọng của ứng dụng. Việc mô hình hóa không phải để bỏ qua truyền thông hoặc thế vào việc phát triển như một nhóm. Mô hình hóa là rất mạnh khi bạn sử dụng nó với nhau theo các cặp hoặc trên các nhóm. Các phần tử khác nhau của UML rất có ích trong khi bạn đang thảo luận cách thực hiện các tính năng và cách đảm bảo thiết kế ấn tượng. Ví dụ, các nhà thiết kế tất cả có thể tụ họp ở phía trước một bảng đen và thảo luận về việc thiết kế với sự trợ giúp của các mô hình.

Bạn cần tất cả các yêu cầu để bắt đầu mô hình hóa
Một số người nghĩ rằng bạn không thể bắt đầu mô hình hóa trước khi bạn có tất cả các yêu cầu. Một phần tử then chốt của việc mô hình hóa là bạn chỉ nên mô hình hóa các điều cốt yếu. Khi mô hình hóa, không điểm nào là không thách thức, hoặc giả việc mô hình hóa là hiển nhiên đối với mọi người. Bạn có thể bắt đầu mô hình hóa ngay sau khi bạn có một số các phần tử cơ bản của hệ thống.

Nếu bạn đã chọn phương thức nhanh, bạn đã chấp nhận các yêu cầu sẽ thay đổi và chấp nhận ứng dụng sẽ thay đổi theo thời gian. Các yêu cầu và ứng dụng đại diện cho doanh nghiệp và các yêu cầu của nó tại một thời gian nhất định. Ba tháng sau đó, chúng có thể khác trước. Nếu bạn thực hiện việc mô hình hóa của mình chỉ với các phần tử cần thiết, bạn không phải thay đổi quá nhiều chi tiết khi những điều đó thay đổi. Khi các yêu cầu mới khiến thay đổi cho mô hình, đó là các thay đổi lớn đối với ứng dụng và cần được lập kế hoạch cẩn thận.

Bạn cần một công cụ tình thế để mô hình hóa.
Bạn không cần một công cụ tình thế đắt tiền. Những ngày này, bạn có thể có được một công cụ tình thế khá tốt miễn phí như là mã nguồn mở hoặc phiên bản cộng đồng của một công cụ thương mại. Bạn thậm chí không cần một công cụ. Bạn có thể mô hình hóa bằng bút và giấy. Chắc chắn thay đổi hoặc phân phối các mô hình đến các vị trí khác nhau là khó khăn hơn nhiều. Nhưng bằng cách vẽ và thảo luận về các mô hình, bạn sẽ đạt được nhiều hơn mà không cần các mô hình hóa nào cho tất cả.
Mô hình hóa là một sự lãng phí thời gian.
Bạn có thể nghe thấy điều này từ những người không tin tưởng vào việc mô hình hóa. Hãy nhớ nguyên tắc cơ bản là mô hình hóa chỉ các điều cốt yếu. Khi bạn mô hình hóa các phần tử này, các phần tử và các vấn đề thiết kế mà chúng cần được giải quyết và truyền đạt sẽ lộ ra, do đó, công việc này không phải là vô ích. Do phần mềm được phát triển và càng phức tạp, thật là tốt khi có các mô hình mà nhóm phát triển có thể quay trở lại.

Các mô hình nhanh

Các mô hình nhanh hữu dụng có một số đặc điểm. Các mô hình nên:

Cần thiết
Đầu tiên và trước hết, một ai đó sẽ cần các mô hình, chứa thông tin hoặc các quyết định về thiết kế. Không có việc tạo ra sử dụng và duy trì một cái mà không ai cần tới.

Nếu bạn đang làm việc với lần lặp phần mềm đầu tiên và cơ sở dữ liệu chứa chỉ một bảng, bạn có thể nghĩ rằng bạn không cần một mô hình. Tuy nhiên, cơ sở dữ liệu sẽ phức tạp hơn theo thời gian. Tại sao không tạo nền tảng cho mô hình này khi bạn tạo cơ sở dữ liệu? Nó không tốn thời gian.

Có một mục đích
Ví dụ, nếu bạn có một biểu đồ lớp các giao diện của bạn, nó phải rõ ràng và dễ hiểu cho những người đang tìm cách để tích hợp với phần mềm của bạn. Mô hình cũng không nên chứa nhiều thông tin hơn là cần thiết. Nếu bạn muốn mô hình hóa các vấn đề thiết kế nhiều hơn, luôn luôn có thể tạo một biểu đồ mới.
Có đầy đủ chi tiết
Nhưng không quá nhiều. Nếu bạn có một biểu đồ lớp chỉ có các tên của các lớp, nhưng không có các kết nối nào giữa các lớp, thật là khó sử dụng. Nếu bạn có một biểu đồ tuần tự có bốn trang rộng và tất cả các hành động nhỏ hơn được hiển thị, nên có nhiều thông tin hơn một chút cho mục đích đó.
Dễ hiểu
Thông tin phải dễ hiểu cho những người sử dụng mô hình. Trang bị đủ để người dùng hiểu được những ý tưởng cốt lõi phía sau mô hình. Mặt khác, không chứa những thứ rõ ràng đối với người dùng. Đọc một mô hình có chứa rất nhiều thứ đã biết sẽ gây phiền nhiễu và lãng phí thời gian đối với bạn.
Đủ chính xác
Với việc nhấn mạnh vào đủ. Đôi khi các nhà phát triển cố gìn giữ làm đánh bóng mô hình, vì họ lo sợ rằng đoạn thông tin thiếu hoặc một lỗi in ấn sẽ làm cho một mô hình không có giá trị. Điều đó là không đúng. Bạn không nên lo lắng lo lắng về việc những thứ thiếu chút ít, miễn là đủ những điều lớn hơn.

Thực hiện mô hình hóa nhanh

Như đã đề cập, bạn không cần một công cụ tình thế để mô hình hóa. Giấy, bìa cứng, tấm giấy đặt trên giá vẽ hay tương tự là đủ. Tập hợp nhóm lại với nhau ở phía trước của tấm giấy đặt trên giá vẽ, sau đó vẽ, thảo luận và thiết kế. Khi bạn đã hoàn thành, vẽ thiết kế trên giấy hoặc chụp ảnh nó.

Nếu bạn quyết định sử dụng các công cụ, bạn có thể khắc phục một số vấn đề rõ ràng với việc thiết kế trên giấy. Có đầy các công cụ có sẵn với giá khác nhau. Các công cụ đắt tiền hơn thường hỗ trợ nhiều hơn và có nhiều tính năng cho phép làm việc theo nhóm. Hầu hết các công cụ tình thế có một phiên bản đơn giản miễn phí hoặc để dùng thử một thời gian.

Trong khi bạn mô hình hóa, suy nghĩ về những người sử dụng và mục đích của mô hình, rồi chọn công cụ phù hợp. Các biểu đồ lớp rất hiệu quả nếu bạn muốn hiển thị điều mà các lớp và các thành phần thể hiện và cách chúng được kết nối trong phần mềm tĩnh. Các biểu đồ tuần tự và trạng thái là mạnh nếu bạn muốn hiển thị cách các lớp tương tác trong thời gian chạy.

Xem xét một ví dụ về mua hàng trên Web. Mô tả ngắn gọn về các chức năng có thể là: Người sử dụng (người dùng tiêu biểu, người dùng doanh nghiệp hoặc đại diện bán hàng) thêm một mục mới vào giỏ mua hàng và có thể nhận được một mức giá đặc biệt theo lịch sử mua sắm hoặc vai trò của họ. Với một biểu đồ ca sử dụng, bạn có thể làm nổi bật ba người sử dụng chức năng này và mối quan hệ của họ với các ca sử dụng. Đại diện bán hàng chẳng hạn, sẽ truy cập để chọn giá chiết khấu; các khách hàng sẽ có được mức giá theo lịch sử mua sắm của họ. Những người sử dụng biểu đồ có thể thấy mối quan hệ cần thiết của những người dùng và các hành động của họ và không gì khác. Điều này sẽ giữ cho biểu đồ đơn giản.

Khi bạn tiếp tục phát triển các phần mềm, bạn có thể thêm các ca sử dụng khác có liên quan đến giỏ mua hàng. Với một biểu đồ lớp, bạn có thể hiển thị các kết nối tĩnh của các lớp cần thiết và vai trò chủ yếu của chúng (Giỏ hàng, Mục, Phiên, v.v). Với một biểu đồ tuần tự, bạn có thể hiển thị cách các lớp làm việc với nhau trong thời gian chạy (trang sản phẩm gọi giỏ mua hàng để thêm mục mới).

Bạn nên suy nghĩ về các kiểu mô hình khớp nhất với các chức năng bạn muốn thiết kế. Không bao giờ tạo ra một biểu đồ trạng thái chỉ vì bạn nghĩ rằng bạn cần phải làm; hãy tạo ra nó nếu đó là cách tốt nhất để hiển thị các thông tin này.

Mô hình của bạn sẽ tiếp tục nâng cấp khi bạn phát triển phần mềm. Đôi khi bạn cần phải thực hiện các thay đổi quan trọng đối với các biểu đồ và đôi khi bạn chỉ cần thêm các phương thức mới vào các lớp và các lời gọi mới cho biểu đồ tuần tự.

Điều quan trọng là thực hiện mô hình hóa trong các nhóm nếu tất cả sẵn sàng. Bạn muốn đảm bảo rằng tất cả những ý tưởng tốt được đưa vào quy trình mô hình hóa. Một ưu điểm khác của một nỗ lực nhóm là các thành viên của nhóm có nhiều khả năng nhận được quyền sở hữu tập thể của mô hình đó — nó sẽ không hẳn là "những điều mà Frank đã làm". Làm việc theo nhóm cải thiện chất lượng và có thể giúp bạn dễ dàng thoát khỏi những sai lầm ngớ ngẩn ngay từ đầu trong một quá trình.

Thật có ích để nói về những suy nghĩ với các khách hàng của bạn (hoặc nội bộ hay bên ngoài) và giải thích đó là những gì mà bạn đang làm và cách mà bạn sắp thực hiện nó. Tất nhiên, bạn phải tính đến trình độ khách hàng. Đối với một số người, các bố trí màn hình và các luồng màn hình là tốt nhất, còn những người khác có thể muốn xem các giao diện và nhiều khía cạnh nhiều kỹ thuật.


Kết luận

Trong mục này, bạn đã học về mô hình hóa nhanh bằng cách thảo luận về các quan niệm sai và các đặc điểm của các mô hình nhanh tốt. Rất nhiều chuông và còi không cần thiết khi mô hình hóa. Một bản vẽ mực trên giấy đơn giản có thể đủ trong một số trường hợp. Nhóm làm việc là then chốt trong việc mô hình hóa thực. Nhóm cần chọn cẩn thận kiểu biểu đồ để khớp nhất với mục đích của bạn.

Mô hình hóa cải thiện chất lượng của phần mềm bằng cách làm truyền thông dễ hơn, làm dễ việc tích hợp và đảm bảo các quyết định sự phát triển được suy nghĩ cẩn thận từ đầu đến cuối. Và nếu bạn làm điều đó một cách hiệu quả, nó không chiếm mất nhiều thời gian như bạn nghĩ đâu.

Tài nguyên

Học tập

  • Xem các phần khác của loạt bài này về việc chấp nhận phát triển nhanh:
    • Phần 1, "Phát triển nhanh có đúng với tổ chức của bạn không?" (developerWorks, 03.2008)
    • Phần 2, "Hiểu biết về các khía cạnh khác nhau" (developerWorks, 04.2008)
    • Phần 3, "Vai trò của các bên liên quan đến nhanh" (developerWorks, 05.2008)
    • Phần 4, "Sử dụng các câu chuyện của người sử dụng để xác định các yêu cầu dự án" (developerWorks, 06.2008)
    • Phần 5, "Áp dụng các câu chuyện của người sử dụng trong một dụng cụ lập kế hoạch tài chính dựa vào Web" (developerWorks, 07.2008)
    • Phần 6, "Quan điểm của người muat" (developerWorks, 09.2008)
    • Phần 7, "Các phương thức để đánh giá nỗ lực làm việc trong sự phát triển nhanh" (developerWorks, 11.2008)
  • Agile Software Construction, một hướng dẫn toàn diện cho các phương thức nhanh hiện tại phổ biến nhất, cũng thảo luận về mô hình hóa.
  • Mô hình hóa nhanh cung cấp phương pháp luận mô hình hóa và thông tin có ích khác.
  • Đọc cuộc thảo luận của Wikipedia về Scrum.
  • Đọc nhiều hơn về ScrumQuản lý dự án thích nghi bằng cách sử dụng Scrum.
  • Duyệt qua cửa hàng sách công nghệ với các sách về các chủ đề kỹ thuật này và khác.
  • Trong khu vực Kiến trúc trên developerWorks, hãy nhận tài nguyên mà bạn cần để đặt các kỹ năng của bạn trong vùng kiến trúc.
  • Tìm các nguồn tài nguyên để giúp bạn xây dựng doanh nghiệp và các hệ thống phần mềm trong các bộ dụng cụ kiến trúc CNTT miễn phí của IBM.
  • Theo sát với các sự kiện kỹ thuật và webcasts của developerWorks.

Lấy sản phẩm và công nghệ

  • Tải về phiên bản đánh giá sản phẩm IBM và nhận được các bài thực hành của bạn trên các công cụ phát triển ứng dụng và các sản phẩm phần mềm trung gian từ IBM® DB2®, Lotus®, Rational®, Tivoli® và WebSphere®.

Thảo luận

  • Đọc những gì mà mọi người đang nói trong developerWorks blogs và dành tâm trí cho cộng đồng developerWorks.
  • Hãy xem blog của Scott Ambler - các chiến lược để điều chỉnh Phát triển phần mềm nhanh.
  • Tham gia vào diễn đàn kiến trúc CNTT để trao đổi các lời khuyên và các kỹ thuật và để chia sẻ các thông tin liên quan khác về chủ đề rộng lớn của kiến trúc CNTT.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational
ArticleID=441885
ArticleTitle=Bản tuyên ngôn kiến trúc: Chấp nhận phát triển nhanh, Phần 8
publish-date=10302009