Use-Case 2.0
Trung tâm phát triển phần mềm
Ivar Jacobson, Ian Spence và Brian Kerr
Các ca sử dụng đã tồn tại gần 30 năm như một phương pháp tiếp cận theo yêu cầu và là một phần của nguồn cảm hứng cho các kỹ thuật mới hơn như câu chuyện người dùng. Bây giờ cảm hứng đã bay theo hướng khác. Use-Case 2.0 là thế hệ mới của sự phát triển theo hướng trường hợp sử dụng — nhẹ nhàng, nhanh nhẹn và tinh gọn — lấy cảm hứng từ câu chuyện của người dùng và các phương pháp linh hoạt Scrum và Kanban.
Use-Case 2.0 có tất cả các giá trị phổ biến trong quá khứ — không chỉ là các yêu cầu hỗ trợ, mà còn cả kiến trúc, thiết kế, thử nghiệm và trải nghiệm người dùng — và nó là công cụ trong mô hình kinh doanh và tái sử dụng phần mềm.
Use-Case 2.0 đã được lấy cảm hứng từ những câu chuyện của người dùng để hỗ trợ xử lý các công việc tồn đọng và quy trình một phần với Kanban, với việc giới thiệu một khái niệm mới quan trọng, phần use-case.
Bài viết này đưa ra lập luận rằng các trường hợp sử dụng về cơ bản bao gồm các kỹ thuật được cung cấp bởi các câu chuyện của người dùng nhưng cung cấp nhiều hơn đáng kể cho các hệ thống lớn hơn, các nhóm lớn hơn và các phát triển phức tạp và đòi hỏi nhiều hơn. Chúng nhẹ như câu chuyện của người dùng, nhưng cũng có thể mở rộng quy mô một cách mượt mà và có cấu trúc để kết hợp nhiều chi tiết khi cần thiết. Quan trọng nhất, chúng thúc đẩy và kết nối nhiều khía cạnh khác của phát triển phần mềm.
Các trường hợp sử dụng — Tại sao vẫn thành công và phổ biến?
Các trường hợp sử dụng đã được giới thiệu tại OOPSLA 87 (Hệ thống, ngôn ngữ và ứng dụng lập trình hướng đối tượng), 6 mặc dù chúng không được chấp nhận rộng rãi cho đến khi xuất bản cuốn sách Công nghệ phần mềm hướng đối tượng năm 1992 - một Phương pháp tiếp cận theo hướng sử dụng theo trường hợp . 7 Kể từ đó, nhiều tác giả khác đã áp dụng các phần của ý tưởng, đặc biệt là Alistair Cockburn 2 liên quan đến các yêu cầu và Larry Constantine 4 liên quan đến thiết kế để có trải nghiệm người dùng tốt hơn. Các trường hợp sử dụng đã được chấp nhận như một phần của UML tiêu chuẩn (Ngôn ngữ tạo mô hình hợp nhất 1), và các sơ đồ của nó (trường hợp sử dụng và các biểu tượng tác nhân) là một trong những phần được sử dụng rộng rãi nhất của ngôn ngữ. Nhiều sách và bài báo khác đã được viết về các trường hợp sử dụng cho tất cả các loại hệ thống — không chỉ cho phần mềm, mà còn cho kinh doanh, hệ thống (chẳng hạn như hệ thống nhúng) và hệ thống của hệ thống. Tập trung vào ngày hôm nay và tương lai, các xu hướng vĩ mô mới nhất, IoT (Internet of Things) và Internet công nghiệp, đã đưa các trường hợp sử dụng trở thành lựa chọn của họ. 9
Thực tiễn ca sử dụng đã phát triển qua nhiều năm, lấy cảm hứng từ ý tưởng của nhiều người khác nhau, với những ý tưởng mới hơn được tích hợp vào Ca sử dụng 2.0. Một ý tưởng mới là cắt một ca sử dụng thành các lát ca sử dụng. 5,8 Ý tưởng sắp xếp kích thước các phần này để trở thành các mục tồn đọng phù hợp và liên hệ chúng với các câu chuyện của người dùng là cốt lõi của Use-Case 2.0.
Các trường hợp sử dụng có thể và nên được sử dụng để thúc đẩy phát triển phần mềm. Họ không quy định cách bạn nên lập kế hoạch hoặc quản lý công việc phát triển của mình, hoặc cách bạn nên thiết kế, phát triển hoặc kiểm tra hệ thống của mình. Tuy nhiên, họ cung cấp một cấu trúc để áp dụng thành công các phương pháp quản lý và phát triển đã chọn của bạn.
Lý do thành công của cách tiếp cận ca sử dụng không chỉ là vì nó là một kỹ thuật rất thực tế để nắm bắt các yêu cầu từ quan điểm sử dụng hoặc thiết kế trải nghiệm người dùng thực tế , mà nó tác động đến toàn bộ vòng đời phát triển. Các trường hợp sử dụng chính — hay nói chính xác hơn, các lát cắt của ca sử dụng chính (một phần là một phần được lựa chọn cẩn thận của một ca sử dụng) — phân tích một cách có hệ thống trong việc tìm kiếm kiến trúc ứng dụng . Chúng thúc đẩy việc xác định các thành phần hoặc các yếu tố phần mềm khác trong thiết kế phần mềm . Chúng là những yếu tố phải trải qua thử nghiệm —và thực sự hỗ trợ thiết kế theo hướng thử nghiệm. Chúng là những yếu tố cần đưa vào công việc tồn đọng khi lập kế hoạch chạy nước rúthoặc để đặt trên canvas bằng cách sử dụng Kanban. Các trường hợp sử dụng của một doanh nghiệp là các quy trình của doanh nghiệp; do đó, lợi thế của việc lập mô hình kinh doanh với các ca sử dụng là nó dẫn trực tiếp đến việc tìm ra các ca sử dụng của hệ thống được phát triển để hỗ trợ công việc kinh doanh. Hơn nữa, các ca sử dụng giúp tìm ra những điểm chung, điều này hướng công việc kiến trúc để đạt được khả năng tái sử dụng phần mềm .
Có nhiều giá trị tương tự hơn trong việc áp dụng các ca sử dụng, nhưng quan trọng nhất là ý tưởng về các ca sử dụng có thể nắm bắt được bằng trực giác. Đây là một cách tiếp cận nhẹ, gọn gàng và nhanh nhẹn, có thể mở rộng, linh hoạt và dễ sử dụng. Nhiều người lần đầu tiên nghe về các trường hợp sử dụng đã khiến họ phải nằm lòng; nhiều người bắt đầu sử dụng thuật ngữ này trong các tình huống cuộc sống hàng ngày mà không nghĩ đến tất cả các chi tiết giúp ích cho rất nhiều khía cạnh của phát triển phần mềm — các khía cạnh là mấu chốt của bánh xe phát triển phần mềm trong đó các trường hợp sử dụng là trung tâm (xem hình 1) .
Vì vậy, rõ ràng là các ca sử dụng đã đứng trước thử thách của thời gian và có một tương lai rất tốt.
Nguyên tắc áp dụng theo ca sử dụng
Có sáu nguyên tắc cơ bản trọng tâm của bất kỳ ứng dụng thành công nào trong các trường hợp sử dụng:
1. Giữ cho nó đơn giản bằng cách kể những câu chuyện.
2. Hiểu được bức tranh lớn.
3. Tập trung vào giá trị.
4. Xây dựng hệ thống theo từng lát.
5. Phân phối hệ thống theo từng bước.
6. Thích ứng để đáp ứng nhu cầu của nhóm.
Nguyên tắc 1: Giữ cho nó đơn giản bằng cách kể chuyện
Kể chuyện là cách các nền văn hóa tồn tại và tiến bộ; đó là cách đơn giản và hiệu quả nhất để truyền kiến thức từ người này sang người khác. Đó là cách tốt nhất để truyền đạt những gì một hệ thống nên làm và để mọi người làm việc trên hệ thống tập trung vào cùng một mục tiêu.
Các ca sử dụng nắm bắt các mục tiêu của hệ thống. Để hiểu một trường hợp sử dụng, chúng tôi kể những câu chuyện. Các câu chuyện đề cập đến cách đạt được mục tiêu và cách xử lý các vấn đề xảy ra trên đường đi. Các trường hợp sử dụng cung cấp một cách để xác định và nắm bắt tất cả các câu chuyện khác nhau nhưng có liên quan một cách đơn giản nhưng toàn diện. Điều này cho phép dễ dàng nắm bắt, chia sẻ và hiểu các yêu cầu của hệ thống.
Nguyên tắc 2: Hiểu bức tranh lớn
Cho dù hệ thống bạn đang phát triển lớn hay nhỏ, cho dù đó là hệ thống phần mềm, hệ thống phần cứng hay hệ thống kinh doanh, việc hiểu được bức tranh toàn cảnh là điều cần thiết. Nếu không có sự hiểu biết về toàn bộ hệ thống, bạn sẽ không thể đưa ra quyết định chính xác về những gì cần đưa vào hệ thống, những gì bỏ đi, những gì nó sẽ tốn kém và những lợi ích mà nó mang lại.
Biểu đồ ca sử dụng là một cách đơn giản để trình bày tổng quan về các yêu cầu của hệ thống. Hình 2 là sơ đồ ca sử dụng cho một hệ thống điện thoại đơn giản. Hình ảnh này cho thấy tất cả các cách hệ thống có thể được sử dụng, người bắt đầu tương tác và bất kỳ bên nào khác có liên quan. Ví dụ, một thuê bao gọi điện có thể thực hiện cuộc gọi nội hạt hoặc cuộc gọi đường dài đến bất kỳ thuê bao có thể gọi được của hệ thống. Bạn cũng có thể thấy rằng người dùng không nhất thiết phải là người mà có thể là các hệ thống khác và trong một số trường hợp là cả hai (ví dụ: vai trò của người đăng ký được gọi có thể là máy trả lời tự động chứ không phải người).
Nguyên tắc 3: Tập trung vào giá trị
Khi cố gắng hiểu cách một hệ thống sẽ được sử dụng, điều quan trọng là phải tập trung vào giá trị mà nó sẽ cung cấp cho người dùng và các bên liên quan khác. Giá trị chỉ được tạo ra nếu hệ thống thực sự được sử dụng, vì vậy tốt hơn hết là tập trung vào cách hệ thống sẽ được sử dụng hơn là vào danh sách dài các chức năng hoặc tính năng mà hệ thống sẽ cung cấp.
Các ca sử dụng cung cấp trọng tâm này bằng cách tập trung vào cách hệ thống sẽ được sử dụng để đạt được một mục tiêu cụ thể cho một người dùng cụ thể. Chúng bao gồm nhiều cách sử dụng hệ thống: những cách đạt được mục tiêu thành công và những cách xử lý bất kỳ vấn đề nào có thể xảy ra.
Hình 3 cho thấy tường thuật trường hợp sử dụng được cấu trúc theo cách này cho trường hợp sử dụng rút tiền của máy rút tiền. Cách đơn giản nhất để đạt được mục tiêu được mô tả bằng quy trình cơ bản. Những dòng khác được trình bày dưới dạng các luồng thay thế. Bằng cách này, bạn tạo một tập hợp các luồng cấu trúc và mô tả các câu chuyện, giúp tìm ra các trường hợp thử nghiệm hoàn thành định nghĩa của chúng.
Loại phác thảo có dấu đầu dòng này có thể đủ để nắm bắt các câu chuyện và thúc đẩy sự phát triển, hoặc nó có thể cần được xây dựng chi tiết khi nhóm khám phá chi tiết về những gì hệ thống cần làm.
Nguyên tắc 4: Xây dựng hệ thống theo từng lát
Hầu hết các hệ thống yêu cầu rất nhiều công việc trước khi chúng có thể sử dụng được và sẵn sàng để vận hành. Họ có nhiều yêu cầu, hầu hết trong số đó phụ thuộc vào các yêu cầu khác đang được thực hiện trước khi chúng có thể được thực hiện và giá trị được phân phối. Luôn luôn là một sai lầm khi cố gắng xây dựng một hệ thống như vậy trong một lần. Hệ thống nên được xây dựng theo từng phần, mỗi phần đều có giá trị rõ ràng đối với người dùng.
Công thức khá đơn giản. Đầu tiên, hãy xác định điều hữu ích nhất mà hệ thống phải làm và tập trung vào điều đó. Sau đó, lấy một thứ đó, và cắt nó thành những lát mỏng hơn . Quyết định các trường hợp kiểm thử đại diện cho việc chấp nhận các lát cắt đó. Chọn phần trung tâm nhất đi qua toàn bộ khái niệm từ đầu đến cuối hoặc gần với phần đó nhất có thể. Hãy ước tính nó như một đội và bắt đầu xây dựng nó.
Đây là cách tiếp cận được thực hiện bởi Use-Case 2.0, trong đó các trường hợp sử dụng được chia nhỏ để cung cấp các hạng mục công việc có kích thước phù hợp và nơi hệ thống tự phát triển từng phần.
Mặc dù các ca sử dụng theo truyền thống được sử dụng để giúp hiểu và nắm bắt các yêu cầu, nhưng chúng luôn làm được nhiều hơn thế. Các lát cắt trường hợp sử dụng không chỉ đơn thuần là các yêu cầu; chúng cũng phân tích tất cả các khía cạnh khác của hệ thống và tài liệu của nó, bao gồm thiết kế, triển khai, các trường hợp thử nghiệm và kết quả thử nghiệm.
Nguyên tắc 5: Phân phối hệ thống theo từng bước
Hầu hết các hệ thống phần mềm phát triển qua nhiều thế hệ. Chúng không được sản xuất trong một lần; chúng được xây dựng như một loạt các bản phát hành, mỗi bản phát hành được xây dựng trên bản trước đó. Ngay cả bản thân các bản phát hành thường không được sản xuất trong một lần mà phát triển qua một loạt các bước tăng dần. Mỗi gia số cung cấp một phiên bản có thể trình diễn hoặc sử dụng được của hệ thống. Đây là cách mà tất cả các hệ thống nên được sản xuất.
Hình 4 cho thấy sự phát triển gia tăng của một bản phát hành hệ thống. Phần tăng đầu tiên chỉ chứa một lát duy nhất — lát đầu tiên từ use-case 1. Phần tăng thứ hai thêm một lát khác từ use-case 1 và lát đầu tiên từ use-case 2. Sau đó, các lát tiếp theo được thêm vào để tạo ra phần thứ ba và thứ tư gia số. Phần tăng thứ tư được coi là hoàn chỉnh và đủ hữu ích để được phát hành.
Nguyên tắc 6: Thích ứng để đáp ứng nhu cầu của nhóm
Thật không may, không có giải pháp chung cho tất cả các thách thức của phát triển phần mềm; các đội khác nhau và các tình huống khác nhau yêu cầu phong cách khác nhau và mức độ chi tiết khác nhau. Bất kể phương pháp và kỹ thuật nào bạn chọn, bạn cần đảm bảo rằng chúng đủ khả năng thích ứng để đáp ứng nhu cầu liên tục của nhóm.
Use-Case 2.0 được thiết kế với tâm trí này và có thể nhẹ như mong muốn. Các nhóm nhỏ, hợp tác có thể có những câu chuyện về tình huống sử dụng rất nhẹ, nắm bắt được những điểm cốt yếu của câu chuyện. Chúng có thể được viết tay trên các thẻ chỉ mục đơn giản. Các nhóm phân tán lớn có thể có các bản tường thuật trường hợp sử dụng chi tiết hơn được trình bày dưới dạng tài liệu. Nhóm nghiên cứu sẽ quyết định xem họ có cần vượt ra ngoài những yếu tố cần thiết hay không, thêm chi tiết theo cách tự nhiên khi họ gặp phải những vấn đề mà những yếu tố cơ bản không thể đối phó.
Thực hành Use-Case 2.0
Thực hành Use-Case 2.0 mô tả các khái niệm chính cần làm việc, các sản phẩm công việc được sử dụng để mô tả chúng và một tập hợp các hoạt động.
Các khái niệm để làm việc với
Use-Case 2.0 bao gồm các yêu cầu, hệ thống được phát triển để đáp ứng các yêu cầu và các bài kiểm tra được sử dụng để chứng minh rằng hệ thống đáp ứng các yêu cầu. Trọng tâm của Use-Case 2.0 là trường hợp sử dụng , phần trường hợp sử dụng và câu chuyện .
Các ca sử dụng nắm bắt các yêu cầu và mỗi ca sử dụng được quản lý phạm vi bằng cách cắt nó thành một tập hợp các lát ca sử dụng có thể hoạt động độc lập. Kể những câu chuyện thu hẹp khoảng cách giữa các bên liên quan, các trường hợp sử dụng và các lát cắt trường hợp sử dụng. Đây là cách các bên liên quan truyền đạt yêu cầu của họ và khám phá các trường hợp sử dụng. Hiểu được các câu chuyện cũng là cơ chế để tìm ra các phân đoạn trường hợp sử dụng phù hợp để thúc đẩy việc triển khai hệ thống.
Trường hợp sử dụng
Một trường hợp sử dụng là:
* Một chuỗi các hành động mà hệ thống thực hiện để mang lại kết quả có thể quan sát được về giá trị cho một người dùng cụ thể.
* Hành vi cụ thể đó của một hệ thống, hệ thống này tham gia vào sự cộng tác với người dùng để cung cấp một cái gì đó có giá trị cho người dùng đó.
* Đơn vị hoạt động nhỏ nhất cung cấp kết quả có ý nghĩa cho người dùng.
* Bối cảnh cho một tập hợp các yêu cầu liên quan.
Tổng hợp lại, tập hợp tất cả các ca sử dụng cung cấp cho chúng ta tất cả các yêu cầu chức năng của hệ thống.
Cách để hiểu một ca sử dụng là kể những câu chuyện. Những câu chuyện này bao gồm cả cách đạt được mục tiêu và cách xử lý bất kỳ vấn đề nào xảy ra trên đường đi. Chúng giúp các nhà phát triển hiểu trường hợp sử dụng và triển khai từng phần một.
Một ca sử dụng trải qua một số thay đổi trạng thái xác định, bắt đầu bằng việc thiết lập mục tiêu của nó , thông qua cấu trúc câu chuyện được hiểu , câu chuyện đơn giản nhất được hoàn thành , câu chuyện đủ hoàn thành , cho đến tất cả câu chuyện được hoàn thành . Các trạng thái tạo thành các quan điểm quan trọng trong việc hiểu và thực hiện ca sử dụng.
Use-Case Slices
Các trường hợp sử dụng bao gồm nhiều câu chuyện liên quan với mức độ quan trọng và mức độ ưu tiên khác nhau. Thường có quá nhiều câu chuyện để cung cấp trong một bản phát hành và nói chung là quá nhiều câu chuyện để giải quyết trong một lần tăng dần. Do đó, cần phải chia các trường hợp sử dụng thành các phần nhỏ hơn.
Phần ca sử dụng là một hoặc nhiều câu chuyện được chọn từ ca sử dụng để tạo thành một hạng mục công việc có giá trị rõ ràng đối với khách hàng. Nó hoạt động như một trình giữ chỗ cho tất cả các công việc cần thiết để hoàn thành việc triển khai các câu chuyện đã chọn. Lát trường hợp sử dụng phát triển để bao gồm các lát cắt tương ứng thông qua thiết kế, triển khai và thử nghiệm.
Phần use-case là yếu tố quan trọng nhất của Use-Case 2.0, vì nó không chỉ được sử dụng để trợ giúp các yêu cầu mà còn để thúc đẩy sự phát triển của một hệ thống để đáp ứng các yêu cầu đó.
Một lát trường hợp sử dụng trải qua một số thay đổi trạng thái, từ nhận dạng ban đầu nơi nó được xác định phạm vi , thông qua việc chuẩn bị , phân tích , triển khai và cuối cùng là xác minh . Các trạng thái này cho phép lập kế hoạch và theo dõi sự hiểu biết, thực hiện và thử nghiệm của phần ca sử dụng.
Đối với những người quan sát bình thường khi nhìn lướt qua các trạng thái, đây có thể giống như một quá trình thác nước. Tuy nhiên, có một sự khác biệt lớn vì điều này liên quan đến một phần trường hợp sử dụng riêng lẻ. Trên toàn bộ các lát cắt, tất cả các hoạt động có thể diễn ra song song. Trong khi một lát ca sử dụng đang được xác minh, một phân đoạn ca sử dụng khác đang được triển khai, một phần ba đang được chuẩn bị và một phần tư đang được phân tích.
Những câu chuyện
Kể chuyện là cách các nhà phát triển khám phá các trường hợp sử dụng với các bên liên quan. Mỗi câu chuyện về giá trị đối với người dùng và các bên liên quan khác là một sợi dây thông qua một trong các trường hợp sử dụng. Các câu chuyện có thể là chức năng hoặc phi chức năng về bản chất.
Một câu chuyện được mô tả bằng một phần của tường thuật trường hợp sử dụng, một hoặc nhiều luồng và các yêu cầu đặc biệt, và một hoặc nhiều trường hợp thử nghiệm. Chìa khóa để tìm ra những câu chuyện hiệu quả là hiểu cấu trúc của câu chuyện tình huống sử dụng. Mạng lưới các luồng có thể được coi như một bản đồ tóm tắt tất cả các câu chuyện cần thiết để mô tả trường hợp sử dụng. Trong ví dụ về máy rút tiền trước đó ở hình 3, bạn có thể xác định các câu chuyện cụ thể như "Rút số tiền tiêu chuẩn là 100 đô la", "Rút số tiền không tiêu chuẩn là 75 đô la và nhận được biên lai" hoặc "Trả lời thẻ không hợp lệ".
Mỗi câu chuyện đi qua một hoặc nhiều luồng bắt đầu với ca sử dụng ở đầu luồng cơ bản và kết thúc với ca sử dụng ở cuối luồng cơ bản. Điều này đảm bảo rằng tất cả các câu chuyện đều liên quan đến việc đạt được cùng một mục tiêu, hoàn chỉnh và có ý nghĩa, đồng thời bổ sung cho nhau, vì tất cả chúng đều được xây dựng dựa trên câu chuyện đơn giản được mô tả bởi quy trình cơ bản.
Công việc sản xuất
Các ca sử dụng và các phân đoạn ca sử dụng được hỗ trợ bởi một số sản phẩm công việc mà nhóm sử dụng để giúp chia sẻ, hiểu và ghi lại chúng.
Một mô hình use-case hình dung các yêu cầu như một tập hợp các trường hợp sử dụng, cung cấp một bức tranh toàn cảnh tổng thể của hệ thống được xây dựng. Mô hình xác định các trường hợp sử dụng và cung cấp bối cảnh để xây dựng các trường hợp sử dụng riêng lẻ.
Các trường hợp sử dụng được khám phá bằng cách kể chuyện. Mỗi trường hợp sử dụng được mô tả bằng (1) bản tường thuật trường hợp sử dụng phác thảo các câu chuyện của nó như một tập hợp các luồng; và (2) một tập hợp các trường hợp thử nghiệm hoàn thành các câu chuyện. Chúng có thể được bổ sung bằng một tập hợp các yêu cầu đặc biệt áp dụng cho toàn bộ trường hợp sử dụng và thường không có chức năng. Những điều này sẽ ảnh hưởng đến các câu chuyện, giúp chỉ định các câu chuyện phù hợp vào các lát trường hợp sử dụng để triển khai và quan trọng nhất là xác định các trường hợp thử nghiệm phù hợp.
Mô hình ca sử dụng được bổ sung bởi thông tin hỗ trợ . Điều này nắm bắt các định nghĩa của các thuật ngữ được sử dụng trong mô hình ca sử dụng và khi phác thảo các câu chuyện trong tường thuật ca sử dụng. Nó cũng nắm bắt mọi yêu cầu trên toàn hệ thống áp dụng cho tất cả các trường hợp sử dụng.
Một thực hiện use-case có thể được tạo ra để hiển thị như thế nào các yếu tố của hệ thống cộng tác để thực hiện một trường hợp sử dụng. Hãy coi việc nhận ra ca sử dụng giống như việc cung cấp "cách" để bổ sung cho "cái gì" của tường thuật trong ca sử dụng. Các cách phổ biến để thể hiện tình huống sử dụng bao gồm các bảng đơn giản, bảng phân cảnh hoặc sơ đồ trình tự.
Làm việc với các trường hợp sử dụng và các lát cắt trường hợp sử dụng
Ngoài việc tạo và theo dõi các sản phẩm công việc, các nhà phát triển cần theo dõi trạng thái và thuộc tính của các ca sử dụng và các lát cắt ca sử dụng. Điều này có thể được thực hiện bằng nhiều cách và bằng nhiều công cụ. Các trạng thái có thể được theo dõi rất đơn giản bằng cách sử dụng ghi chú hoặc bảng tính. Nếu cần nhiều hình thức hơn, thì có thể sử dụng một trong nhiều công cụ quản lý yêu cầu, quản lý thay đổi hoặc theo dõi lỗi có sẵn trên thị trường.
Hình 5 cho thấy một ca sử dụng và một số lát cắt của nó được ghi lại trên một tập hợp các ghi chú dính.
Trường hợp sử dụng được hiển thị là "7. Duyệt và Mua sắm" từ một ứng dụng mua sắm trực tuyến. Lát 1 và 2 của trường hợp sử dụng dựa trên các câu chuyện riêng lẻ bắt nguồn từ quy trình cơ bản: "Chọn và Mua 1 Sản phẩm" và "Chọn và Mua 100 Sản phẩm". Slice 3 dựa trên nhiều câu chuyện về sự sẵn có của các hệ thống hỗ trợ khác nhau liên quan đến trường hợp sử dụng.
Các thuộc tính cần thiết cho một ca sử dụng là tên, trạng thái và mức độ ưu tiên của nó. Trong trường hợp này, lược đồ ưu tiên MoSCoW (Phải, Nên, Có thể, Sẽ) phổ biến đã được sử dụng. Các trường hợp sử dụng cũng nên được ước lượng. Ở đây, một sơ đồ đơn giản để đánh giá kích thước và độ phức tạp tương đối đã được sử dụng.
Các thuộc tính cần thiết cho một lát trường hợp sử dụng là: (1) danh sách các câu chuyện của nó; (2) các tham chiếu đến trường hợp sử dụng và các luồng xác định các câu chuyện; (3) tham chiếu đến các bài kiểm tra và trường hợp kiểm thử sẽ được sử dụng để xác minh sự hoàn thành của nó; và (4) ước tính công việc cần thiết để thực hiện và kiểm tra lát cắt. Trong ví dụ này, các câu chuyện được sử dụng để đặt tên cho lát cắt và các tham chiếu đến trường hợp sử dụng được ẩn trong số lát và danh sách các luồng. Các ước tính đã được bổ sung sau đó sau khi tham khảo ý kiến của nhóm. Đây là những con số lớn ở phía dưới cùng bên phải của mỗi tờ giấy dính. Trong trường hợp này, nhóm đã chơi Planning Poker để tạo ra các ước tính tương đối bằng cách sử dụng điểm câu chuyện.
Các trường hợp sử dụng và các phần trường hợp sử dụng cũng nên được sắp xếp theo thứ tự sao cho những cái quan trọng nhất được giải quyết trước.
Giữ các sản phẩm công việc nhẹ nhất thích hợp
Tất cả các sản phẩm công việc được xác định với một số cấp độ chi tiết. Cấp độ đầu tiên xác định các yếu tố cơ bản, lượng thông tin tối thiểu cần thiết để thực hành hoạt động. Các cấp độ chi tiết khác được xác định để giúp nhóm đối phó với bất kỳ trường hợp đặc biệt nào mà họ có thể gặp phải. Điều này cho phép các nhóm nhỏ, cộng tác có các câu chuyện về ca sử dụng rất nhẹ được xác định trên thẻ chỉ mục đơn giản và các nhóm lớn được phân phối có các tường thuật về ca sử dụng chi tiết hơn được trình bày dưới dạng tài liệu. Sau đó, các nhóm có thể phát triển các câu chuyện khi cần thiết để giúp liên lạc hoặc xác định kỹ lưỡng các yêu cầu quan trọng hoặc quan trọng về an toàn.
Tin tốt là bạn luôn bắt đầu theo cùng một cách, với những yếu tố cần thiết. Sau đó, nhóm có thể liên tục điều chỉnh mức độ chi tiết trong tường thuật trường hợp sử dụng của họ để đáp ứng nhu cầu mới nổi của họ.
Những việc cần làm
Use-Case 2.0 chia nhỏ công việc thành một số hoạt động thiết yếu cần phải thực hiện nếu các ca sử dụng là để cung cấp giá trị thực cho nhóm.
Các tìm diễn viên và sử dụng trường hợp hoạt động sản xuất một mô hình use-case danh sách chỉ rõ các trường hợp sử dụng, mà sẽ được sau đó thái lát . Các lát cắt ca sử dụng này sau đó sẽ được chuẩn bị bằng cách mô tả các câu chuyện liên quan trong tường thuật ca sử dụng và xác định các trường hợp thử nghiệm. Slice được phân tích để tìm ra cách các phần tử hệ thống sẽ tương tác để thực hiện ca sử dụng, sau đó được triển khai và kiểm tra như một slice. Use-Case 2.0 có thể được coi là một hình thức phát triển theo hướng thử nghiệm, vì nó tạo ra các trường hợp thử nghiệm cho mỗi lát cắt trước. Cuối cùng, toàn bộ hệ thống được kiểm tra để đảm bảo rằng tất cả các lát cắt hoạt động cùng nhau khi được kết hợp.
Bản thân các hoạt động sẽ được thực hiện nhiều lần trong quá trình bạn làm việc. Ngay cả một hoạt động đơn giản như Tìm Tác nhân và Ca sử dụng có thể cần được thực hiện nhiều lần để tìm tất cả các ca sử dụng và có thể được tiến hành song song với hoặc sau các hoạt động khác. Ví dụ: trong khi tiếp tục Tìm Diễn viên và Ca sử dụng , bạn cũng có thể triển khai một số lát cắt từ những ca sử dụng đã tìm thấy trước đó.
Khi dự án tiến triển, các ưu tiên thay đổi, các bài học được rút ra và các thay đổi được yêu cầu. Tất cả những điều này có thể có tác động đến các ca sử dụng và các phân đoạn ca sử dụng đã được triển khai, cũng như những ca vẫn đang chờ tiến triển. Điều này có nghĩa là sẽ có một hoạt động Kiểm tra và Điều chỉnh liên tục cho các trường hợp sử dụng. Điều này cũng sẽ điều chỉnh cách làm việc với thực tiễn Use-Case 2.0 để điều chỉnh kích thước của các lát cắt hoặc mức độ chi tiết trong các sản phẩm gia công để đáp ứng các nhu cầu khác nhau của dự án và nhóm.
Sử dụng Use-Case 2.0
Nhiều người nghĩ rằng các ca sử dụng chỉ áp dụng cho các hệ thống sử dụng nhiều người dùng có nhiều tương tác giữa người dùng và hệ thống. Điều này thật kỳ lạ vì ý tưởng ban đầu cho các trường hợp sử dụng đến từ các hệ thống chuyển mạch viễn thông, hệ thống này có cả người dùng (thuê bao, nhà khai thác) và người dùng máy, dưới dạng các hệ thống được kết nối với nhau. Các trường hợp sử dụng có thể áp dụng cho tất cả các hệ thống được sử dụng — và điều đó có nghĩa là tất cả các hệ thống.
Nó không chỉ dành cho các ứng dụng chuyên sâu của người dùng
Trên thực tế, các ca sử dụng cũng hữu ích đối với các hệ thống nhúng có ít hoặc không có sự tương tác của con người cũng như đối với các hệ thống chuyên sâu về người dùng. Mọi người đang sử dụng các ca sử dụng trong việc phát triển tất cả các loại phần mềm nhúng trong các lĩnh vực đa dạng như động cơ, điện tử tiêu dùng, quân sự, hàng không vũ trụ và ngành y tế. Ngay cả các hệ thống kiểm soát quá trình thời gian thực được sử dụng cho các nhà máy hóa chất cũng có thể được mô tả theo các trường hợp sử dụng trong đó mỗi trường hợp sử dụng tập trung vào một phần cụ thể của hành vi quy trình và nhu cầu tự động hóa của nhà máy.
Nó không chỉ dành cho phát triển phần mềm
Việc áp dụng các ca sử dụng không chỉ giới hạn trong việc phát triển phần mềm. Họ cũng có thể giúp hiểu các yêu cầu kinh doanh, phân tích hoạt động kinh doanh hiện tại, thiết kế các quy trình kinh doanh mới và tốt hơn cũng như khai thác sức mạnh của CNTT để chuyển đổi hoạt động kinh doanh. Bằng cách sử dụng đệ quy các ca sử dụng để (1) lập mô hình doanh nghiệp và các tương tác của nó với thế giới bên ngoài và (2) mô hình hóa các hệ thống cần thiết để hỗ trợ và cải thiện doanh nghiệp, các nhà phát triển có thể xác định một cách liền mạch nơi hệ thống sẽ tác động đến doanh nghiệp và hệ thống nào là cần thiết để hỗ trợ doanh nghiệp.
Xử lý tất cả các loại yêu cầu
Mặc dù chúng là một trong những kỹ thuật phổ biến nhất để mô tả chức năng của hệ thống, các ca sử dụng cũng được sử dụng để khám phá các đặc điểm phi chức năng. Cách đơn giản nhất để thực hiện việc này là nắm bắt chúng như một phần của chính các ca sử dụng — ví dụ: liên hệ các yêu cầu về hiệu suất với thời gian thực hiện giữa các bước cụ thể của một ca sử dụng hoặc liệt kê các mức dịch vụ dự kiến cho một ca sử dụng như một phần của việc sử dụng trường hợp chính nó.
Một số đặc điểm phi chức năng nhỏ hơn điều này và áp dụng cho nhiều trường hợp sử dụng, nếu không phải là tất cả. Điều này đặc biệt đúng khi xây dựng kiến trúc phân lớp, bao gồm các thành phần cơ sở hạ tầng như bảo mật, quản lý giao dịch, dịch vụ nhắn tin và quản lý dữ liệu. Các yêu cầu trong các lĩnh vực này vẫn có thể được thể hiện dưới dạng các trường hợp sử dụng — các trường hợp sử dụng riêng biệt tập trung vào việc sử dụng kỹ thuật của hệ thống. Các trường hợp sử dụng bổ sung này được gọi là các trường hợp sử dụng cơ sở hạ tầng, 8 vì các yêu cầu mà chúng chứa sẽ thúc đẩy việc tạo ra cơ sở hạ tầng mà ứng dụng sẽ chạy.
Có thể áp dụng cho tất cả các phương pháp phát triển
Use-Case 2.0 hoạt động với tất cả các phương pháp phát triển phần mềm phổ biến, bao gồm:
* Các cách tiếp cận lặp lại theo hướng backlog như Scrum, EssUP và OpenUP.
* Các phương pháp tiếp cận dựa trên luồng một mảnh như Kanban.
* Phương pháp tiếp cận tất cả trong một lần như thác nước truyền thống.
Use-Case 2.0 và các lần lặp lại theo hướng tồn đọng
Trước khi áp dụng bất kỳ phương pháp tiếp cận theo hướng tồn đọng nào, bạn phải hiểu những hạng mục nào sẽ xuất hiện trong công việc tồn đọng. Có nhiều dạng tồn đọng khác nhau mà các nhóm sử dụng để thúc đẩy công việc của họ, bao gồm tồn đọng sản phẩm, phát hành và dự án. Bất kể thuật ngữ được sử dụng là gì, tất cả chúng đều tuân theo các nguyên tắc giống nhau. Bản thân backlog là một danh sách có thứ tự mọi thứ có thể cần thiết và là nguồn yêu cầu duy nhất cho bất kỳ thay đổi nào được thực hiện.
Trong Use-Case 2.0, các lát use-case là các mục tồn đọng chính. Việc sử dụng các lát trường hợp sử dụng đảm bảo rằng các hạng mục tồn đọng được hình thành tốt, vì chúng độc lập tự nhiên, có giá trị và có thể kiểm tra được. Cấu trúc của tường thuật ca sử dụng xác định chúng đảm bảo rằng chúng có thể ước tính và thương lượng được, và cơ chế phân chia ca sử dụng cho phép chúng được cắt nhỏ khi cần thiết để hỗ trợ nhóm phát triển.
Khi phương pháp tiếp cận theo hướng tồn đọng được áp dụng, điều quan trọng là phải nhận ra rằng công việc tồn đọng không được xây dựng và hoàn thành từ trước mà được liên tục làm việc và tinh chỉnh. Trình tự các hoạt động điển hình cho cách tiếp cận lặp đi lặp lại, định hướng tồn đọng được thể hiện trong Hình 6.
Use-Case 2.0 và quy trình một mảnh
Quy trình một phần là một kỹ thuật được lấy từ sản xuất tinh gọn nhằm tránh việc tạo ra một loạt các yêu cầu được thấy trong các phương pháp lặp lại và tiếp cận thác nước. Mỗi hạng mục yêu cầu trôi chảy nhanh chóng trong quá trình phát triển, nhưng để hoạt động hiệu quả, kỹ thuật này cần các hạng mục nhỏ, có kích thước thường xuyên. Các ca sử dụng sẽ có kích thước quá bất thường và quá lớn để chảy qua hệ thống. Tuy nhiên, các lát cắt theo ca sử dụng có thể được định kích thước phù hợp và được điều chỉnh để đáp ứng nhu cầu của nhóm.
Luồng một phần không có nghĩa là chỉ có một mục yêu cầu được thực hiện tại một thời điểm hoặc chỉ có một phần công việc giữa một máy trạm và máy trạm tiếp theo. Cần có đủ vật phẩm trong hệ thống để giữ cho nhóm bận rộn. Giới hạn công việc đang tiến hành được sử dụng để cân bằng quy trình và ngăn chặn mọi tồn đọng lãng phí tích tụ. Hình 7 cho thấy một bảng Kanban đơn giản để hình dung luồng các lát trường hợp sử dụng.
Các giới hạn công việc đang tiến hành được hiển thị bằng màu đỏ. Đọc từ trái sang phải, bạn có thể thấy rằng các lát cắt phải được xác định và xác định phạm vi trước khi chúng được đầu vào cho nhóm. Trong hình này, giới hạn công việc đang tiến hành là năm và khách hàng, chủ sở hữu sản phẩm hoặc nhóm yêu cầu là nguồn của các yêu cầu cố gắng giữ cho năm phần trường hợp sử dụng luôn sẵn sàng để thực hiện.
Lưu ý rằng không có bảng Kanban cuối cùng hoặc bộ giới hạn công việc đang tiến hành; nó phụ thuộc vào cấu trúc nhóm và phương thức làm việc. Hội đồng quản trị và các giới hạn trong quá trình thực hiện phải được điều chỉnh giống như thực tiễn. Các trạng thái cho các lát trường hợp sử dụng là một trợ giúp tuyệt vời cho kiểu thiết kế công việc này vì chúng có thể xác định rõ ràng trạng thái của lát sẽ ở trạng thái nào khi nó được chuyển đến phần tiếp theo của chuỗi.
Use-Case 2.0 và thác nước
Vì nhiều lý do khác nhau, bạn có thể cần phát triển phần mềm trong sự ràng buộc của một số dạng mô hình quản trị thác nước. Điều này thường có nghĩa là một số nỗ lực sẽ được thực hiện để nắm bắt trước tất cả các yêu cầu trước khi chúng được chuyển giao cho bên thứ ba để phát triển.
Trong cách tiếp cận thác nước, các trường hợp sử dụng không liên tục được làm việc và tinh chỉnh để cho phép hệ thống cuối cùng xuất hiện nhưng được xác định trong một lần khi bắt đầu công việc.
Phương pháp tiếp cận thác nước mang tính chất nhất thời có nghĩa là cách trang điểm của đội liên tục thay đổi theo thời gian, do đó, khả năng sử dụng giao tiếp mặt đối mặt để chia sẻ câu chuyện là rất hạn chế. Để đối phó với điều này, bạn cần phải nâng cao mức độ chi tiết của các sản phẩm làm việc, vượt ra ngoài những yếu tố cần thiết.
Use-Case 2.0 — Nó không chỉ dành cho một loại nhóm
Một khía cạnh quan trọng khác của Use-Case 2.0 là khả năng thích ứng với cấu trúc nhóm hiện có và chức năng công việc đồng thời khuyến khích các nhóm loại bỏ lãng phí và tăng hiệu quả. Vì vậy, Use-Case 2.0 không xác định trước bất kỳ vai trò hoặc cấu trúc nhóm cụ thể nào, nhưng nó xác định một tập hợp các trạng thái cho mỗi phần tử trung tâm (trường hợp sử dụng và phần trường hợp sử dụng).
Như được minh họa bằng cuộc thảo luận về Use-Case 2.0 và quy trình một phần, các trạng thái cho biết khi nào các mục ở trạng thái nghỉ và có thể được chuyển giao từ người này hoặc nhóm khác. Điều này cho phép thực hành được sử dụng với các nhóm thuộc mọi hình dạng và quy mô, từ các nhóm chức năng chéo nhỏ với ít hoặc không có sự bàn giao cho đến mạng lưới lớn các nhóm chuyên gia mà mỗi thay đổi trạng thái là trách nhiệm của một chuyên gia khác nhau. Theo dõi trạng thái và bàn giao của các yếu tố này cho phép theo dõi luồng công việc thông qua nhóm (hoặc các nhóm) và các nhóm điều chỉnh cách làm việc của họ để cải thiện hiệu suất liên tục.
Mở rộng quy mô để đáp ứng nhu cầu của bạn — vào, ra và lên
Không có phương pháp tiếp cận xác định trước nào phù hợp với tất cả mọi người, vì vậy việc sử dụng Use-Case 2.0 cần được mở rộng theo một số kích thước khác nhau:
* Các trường hợp sử dụng mở rộng quy mô để cung cấp nhiều hướng dẫn hơn cho những người thực hành ít kinh nghiệm (nhà phát triển, nhà phân tích, người kiểm tra, v.v.) hoặc cho những người thực hành muốn hoặc cần thêm hướng dẫn.
* Chúng mở rộng quy mô để bao gồm toàn bộ vòng đời, không chỉ bao gồm phân tích, thiết kế, mã hóa và thử nghiệm mà còn bao gồm cả việc sử dụng và bảo trì vận hành.
* Chúng mở rộng quy mô để hỗ trợ các hệ thống lớn và rất lớn như hệ thống của hệ thống: hệ thống doanh nghiệp, dòng sản phẩm và hệ thống phân lớp. Các hệ thống như vậy rất phức tạp và thường được phát triển bởi nhiều nhóm làm việc song song tại các địa điểm khác nhau, có thể cho các công ty khác nhau và sử dụng lại nhiều hệ thống cũ hoặc các giải pháp đóng gói.
Bất kể mức độ phức tạp của hệ thống đang được phát triển, nhóm phát triển luôn bắt đầu theo cùng một cách bằng cách xác định các trường hợp sử dụng quan trọng nhất và tạo ra một bức tranh lớn tóm tắt những gì cần được xây dựng. Use-Case 2.0 sau đó có thể được điều chỉnh để đáp ứng các nhu cầu mới nổi của nhóm. Trên thực tế, thực tiễn Use-Case 2.0 khẳng định rằng bạn liên tục kiểm tra và điều chỉnh việc sử dụng nó để loại bỏ lãng phí, tăng thông lượng và bắt kịp với nhu cầu luôn thay đổi của nhóm.
Câu chuyện của người dùng và các trường hợp sử dụng — Sự khác biệt là gì?
Cách tốt nhất để trả lời câu hỏi này là xem xét các thuộc tính chung của câu chuyện người dùng và trường hợp sử dụng — những thứ làm cho cả hai hoạt động tốt như các mục tồn đọng và cho phép cả hai hỗ trợ các phương pháp tiếp cận nhanh phổ biến như Scrum, Kanban, phát triển theo hướng kiểm tra, và đặc tả bằng ví dụ.
Các lát cắt Use-Case và câu chuyện người dùng 3 có nhiều đặc điểm chung. Ví dụ:
* Cả hai đều xác định các phần của chức năng mà các nhóm có thể hoàn thành trong sprint.
* Cả hai đều có thể được cắt nhỏ nếu chúng quá lớn, dẫn đến nhiều vật phẩm nhỏ hơn.
* Cả hai đều có thể được viết trên thẻ chỉ mục.
* Cả hai đều dẫn đến các trường hợp kiểm thử đại diện cho các tiêu chí chấp nhận.
* Cả hai đều là trình giữ chỗ cho một cuộc trò chuyện và được hưởng lợi từ ba chữ C do Ron Jeffries phát minh: thẻ, hội thoại và xác nhận.
* Cả hai đều có thể được ước tính bằng các kỹ thuật như Lập kế hoạch Poker.
Vì vậy, khi họ có quá nhiều điểm chung, điều gì khiến họ khác biệt? Các trường hợp sử dụng và các lát cắt trường hợp sử dụng cung cấp giá trị gia tăng:
* Một bức tranh lớn để giúp mọi người hiểu được mức độ của hệ thống và giá trị của nó.
* Tăng cường hiểu biết về những gì hệ thống làm và cách nó thực hiện.
* Tổ chức tốt hơn, hiểu, áp dụng và duy trì các tài sản thử nghiệm.
* Dễ dàng tạo và phân tích test-case.
* Hỗ trợ phân tích tác động liên tục.
* Quản lý phạm vi hoạt động cho phép dễ dàng tập trung vào việc cung cấp sản phẩm khả thi tối thiểu.
* Tài liệu linh hoạt, có thể mở rộng để giúp đối phó với khả năng truy xuất nguồn gốc hoặc các ràng buộc hợp đồng khác.
* Hỗ trợ cho các hệ thống đơn giản, hệ thống phức tạp và hệ thống của hệ thống.
* Nhận dạng dễ dàng hơn các chức năng bị thiếu và thừa.
Câu hỏi vẫn là: bạn nên sử dụng kỹ thuật nào, một khi bạn vượt ra ngoài sở thích cá nhân, thì rất phụ thuộc vào ngữ cảnh. Xem xét các yếu tố sau: mức độ tiếp cận của các DNVVN (các chuyên gia về chủ đề); và các lỗi yêu cầu sẽ nghiêm trọng như thế nào nếu chúng thoát ra môi trường sống.
Điểm đáng chú ý cho câu chuyện của người dùng đạt được khi có khả năng tiếp cận dễ dàng với một doanh nghiệp vừa và nhỏ và mức độ nghiêm trọng của lỗi thấp. Các trường hợp sử dụng và các lát cắt trường hợp sử dụng phù hợp hơn khi không có quyền truy cập dễ dàng vào một DNVVN hoặc khi hậu quả lỗi cao. Tuy nhiên, vì cách tiếp cận theo trường hợp sử dụng có thể thu nhỏ đến điểm hấp dẫn của câu chuyện người dùng, bạn vẫn có thể muốn áp dụng chúng. Nếu hệ thống chủ đề luôn ở vị trí quan trọng của câu chuyện người dùng, thì câu chuyện của người dùng vẫn ổn, nhưng nếu bạn mong đợi nó phát triển bên ngoài lĩnh vực đó, bạn nên xem xét các trường hợp sử dụng và các trường hợp sử dụng.
Phần kết luận
Use-Case 2.0 tồn tại như một thực tiễn đã được chứng minh và xác định rõ ràng, tương thích với nhiều thực tiễn phát triển phần mềm khác như tích hợp liên tục, kiến trúc có chủ đích và phát triển theo hướng thử nghiệm. Nó cũng hoạt động với tất cả các phương pháp quản lý phổ biến. Đặc biệt, nó có sự nhẹ nhàng và linh hoạt để hỗ trợ các nhóm làm việc theo kiểu nhanh nhẹn hoặc tinh gọn. Nó cũng có sự hoàn chỉnh và nghiêm ngặt cần thiết để hỗ trợ các nhóm làm việc trong môi trường thác nước hoặc trang trọng hơn.
Thông tin chi tiết về thực hành Use-Case 2.0 được ghi chép đầy đủ có tại http://www.ivarjacobson.com .
Người giới thiệu
1. Booch, G., Jacobson, I., Rumbaugh, J. 2004. Sổ tay Tham khảo Ngôn ngữ Mô hình Thống nhất, ấn bản thứ hai. Addison-Wesley Chuyên nghiệp.
2. Cockburn, A. 2001. Viết các trường hợp sử dụng hiệu quả . Addison-Wesley Chuyên nghiệp.
3. Cohn, M. 2004. Các câu chuyện của người dùng được áp dụng . Addison-Wesley Chuyên nghiệp.
4. Constantine, L., Lockwood, L. 1999. Phần mềm để sử dụng . Addison-Wesley Chuyên nghiệp.
5. Jacobson, I. 2003. Trường hợp các khía cạnh, phần II. Tạp chí Phát triển Phần mềm (tháng 11): 42-48.
6. Jacobson, I. 1987. Phát triển phần mềm hướng đối tượng trong môi trường công nghiệp. Trong Kỷ yếu Hội thảo về Hệ thống, Ngôn ngữ và Ứng dụng Lập trình hướng đối tượng (OOPSLA 87).
7. Jacobson, I., Christerson, M., Johnsson, P., Overgaards, G. 1992. Kỹ thuật phần mềm hướng đối tượng: Phương pháp tiếp cận hướng theo trường hợp sử dụng . Addison-Wesley Chuyên nghiệp.
8. Jacobson, I., Ng, PW 2005. Phát triển phần mềm theo hướng khía cạnh với các trường hợp sử dụng . Addison-Wesley Chuyên nghiệp.
9. Slama, D., Puhlmann, F., Morrish, J., Bhatnagar, R. 2015. Doanh nghiệp Internet of Things ; http://enterprise-iot.org/book/enterprise-iot/ .
Ivar Jacobson, Ph.D, là cha đẻ của các thành phần và kiến trúc thành phần, các trường hợp sử dụng, phát triển phần mềm theo hướng khía cạnh, kỹ thuật kinh doanh hiện đại, Ngôn ngữ tạo mô hình hợp nhất và Quy trình hợp nhất hợp lý. Đóng góp mới nhất của ông cho ngành công nghiệp phần mềm là một khái niệm thực hành chính thức thúc đẩy thực hành là "công dân hạng nhất" của phát triển phần mềm và xem phương pháp (hoặc quy trình) chỉ đơn giản là một cấu thành của thực hành. Jacobson cũng là một trong những người sáng lập cộng đồng SEMAT (Phương pháp và Lý thuyết Kỹ thuật Phần mềm), với nhiệm vụ là tái cấu trúc kỹ thuật phần mềm. Ông là tác giả chính của bảy cuốn sách có ảnh hưởng và bán chạy nhất cùng một số lượng lớn các bài báo. Ông đã được trao huy chương Gustaf Dalén ("giải Nobel nhỏ"), và ông là một tiến sĩ danh dự tại Đại học San Martin de Porres, Peru.
Ian Spence là CTO tại Ivar Jacobson International và là trưởng nhóm phát triển hạt nhân SEMAT (Phương pháp và Lý thuyết Kỹ thuật Phần mềm) . Một huấn luyện viên giàu kinh nghiệm, ông đã giới thiệu hàng trăm dự án với các phương pháp thực hành lặp đi lặp lại và nhanh nhẹn. Ông cũng đã lãnh đạo nhiều dự án chuyển đổi quy mô lớn thành công với các tổ chức phát triển lên đến 5.000 người. Sở thích hiện tại của anh ấy là nhanh nhẹn cho các dự án lớn, thuê ngoài nhanh và thúc đẩy sự thay đổi bền vững bằng các phép đo nhanh nhẹn.
Brian Kerr là một huấn luyện viên, nhà tư vấn và đại diện thay đổi nhanh nhẹn giàu kinh nghiệm , và là nhà tư vấn chính tại Ivar Jacobson International. Anh ấy làm việc với các nhóm và tổ chức, giúp họ áp dụng các phương pháp phát triển phần mềm quan trọng một cách thực dụng và bền vững. Ông có kiến thức chuyên môn đặc biệt về không gian yêu cầu và đã sử dụng, giảng dạy và tư vấn về phương pháp sử dụng trong 20 năm qua trên nhiều ngành và lĩnh vực. Anh ấy đã tham gia vào công việc tư tưởng đằng sau sáng kiến SEMAT (Phương pháp và Lý thuyết Kỹ thuật Phần mềm) và những ý tưởng mới nhất được ghi lại trong thực tiễn Use-Case 2.0.
Đăng nhận xét