Tôi có nên lắng nghe chủ nhân của mình và sử dụng các công cụ CASE không?

Chủ lao động của tôi (Không phải là Nhà phát triển) nghĩ rằng các công cụ CASE sẽ giúp chúng tôi cải thiện quy trình và tài liệu phát triển. Tôi không chắc về điều đó, chúng tôi là một nhóm nhỏ gồm 5 nhà phát triển xây dựng các giải pháp ngân hàng di động cho khách hàng địa phương. Tôi nghĩ rằng các công cụ CASE sẽ lãng phí thời gian và tiền bạc khi chúng cần được mua và chúng ta sẽ cần một thời gian trước khi chúng ta quen với chúng và làm việc hiệu quả với chúng để mô hình hóa và công cụ. Tạo mã là một vấn đề khác, tôi thực sự nghĩ rằng mã được tạo CASE sẽ không tốt như mã được viết bởi các nhà phát triển giỏi.

Tôi nghĩ rằng nếu chúng ta tuân thủ các nguyên tắc nhanh, các mẫu thiết kế, sử dụng TDD và giữ cho mã của chúng ta sạch sẽ. chúng ta nên tốt Và theo như Phân tích và Thiết kế, tôi nghĩ các sơ đồ UML đơn giản trên bảng trắng nên thực hiện thủ thuật này. Tài liệu là tốt và quan trọng, nhưng nên được thực hiện càng ít càng tốt và chúng ta không nên tập trung vào Docs và quên mã. Đây là điều mà tôi nghĩ.

Tôi có đúng không? hoặc tôi nên lắng nghe chủ nhân của mình và bắt đầu nghiên cứu cho một Công cụ CASE thích hợp?

Tình huống này đảm bảo một cách tiếp cận phân tích cho quyết định. Điểm mấu chốt sẽ là "Công cụ CASE có cung cấp giá trị cho doanh nghiệp không?" Thông thường, ban quản lý sẽ muốn các nhà phát triển áp dụng một phương pháp hoặc công cụ vì họ đã nghe thấy những điều hay về nó, bất kể nó phù hợp với quy trình và văn hóa hiện tại của tổ chức như thế nào.

Nếu chủ lao động của bạn đã yêu cầu bạn xem xét các công cụ CASE, như ChrisF chỉ ra, bạn nên bắt buộc (đây là vấn đề tại nơi làm việc, không phải lập trình). Một số yếu tố sẽ ảnh hưởng đến việc áp dụng công cụ CASE bao gồm:

• Các quy trình của bạn có sẵn các công cụ CASE,
• Ước tính cần bao nhiêu giờ người để áp dụng (các) công cụ mới,
• Quá trình sẽ thay đổi như thế nào với việc áp dụng (các) công cụ mới,
• hoặc Loại tác động tích cực (hoặc tiêu cực) nào có thể đo lường được từ việc áp dụng (các) công cụ mới

Hãy nghĩ về điều này như một cơ hội để nâng cấp môi trường và quy trình phát triển của bạn. Có thể các quy trình hiện tại của bạn là một kết hợp hoàn hảo cho văn hóa của tổ chức của bạn, nhưng bạn nợ chủ lao động và nhóm của bạn để thực hiện nghiên cứu thích hợp.

Có, bạn nên bắt đầu nghiên cứu các công cụ CASE.

1. Bởi vì bạn cần bằng chứng để sao lưu khẳng định của bạn rằng họ sẽ không giúp đỡ. Bạn không bao giờ biết, bạn có thể thấy rằng họ sẽ giúp đỡ.
2. Bởi vì chủ nhân của bạn nói với bạn để.

Tôi sẽ không lặp lại những điểm được David Kaczynski đưa ra trong câu trả lời xuất sắc của anh ấy vì chúng chính xác là những bước bạn nên làm theo.

Có vẻ như một sự thay đổi mô hình lớn thực sự từ phát triển theo định hướng Agile sang CASE / MDA với việc tạo mã. Không nhất thiết theo quan điểm quản lý dự án (cách tiếp cận CASE sẽ không mâu thuẫn với các khái niệm lặp, câu chuyện của người dùng, phản hồi nhanh hoặc cải tiến liên tục) nhưng chắc chắn là từ góc độ "thủ công phần mềm" - điều đó có nghĩa là ít kiểm soát mã hơn mã được tạo, tạo ra có thể sẽ không thể đọc được, cứng nhắc, khó kiểm tra hơn, liên tục cần đồng bộ hóa với mô hình, v.v.

Từ những gì bạn mô tả, những gì chủ nhân của bạn cần là dễ hiểu:

• Tài liệu tốt hơn để tránh mất kiến ​​thức nếu một nhà phát triển rời khỏi nhóm.
• Một quá trình phát triển nhanh hơn.

Là một chuyên gia phần mềm, bạn chắc chắn có thể (và nên) nói với anh ấy về những nghi ngờ của bạn về khả năng của phương pháp CASE để phù hợp với những kỳ vọng này. Bạn cũng có nhiệm vụ bắt đầu xem xét các công cụ CASE nếu anh ấy yêu cầu như vậy. Chỉ cần thử một trong số chúng không có nghĩa là 1 / rằng kết quả sẽ thỏa mãn (tôi đặc biệt nghĩ về chi phí tạo mã lớn có khả năng xung đột với nhu cầu phát triển nhanh hơn) và 2 / mà bạn không thể tìm một sự thỏa hiệp trong đó một số tính năng của công cụ CASE (sơ đồ, tạo tài liệu) sẽ được sử dụng trong khi bảo tồn bối cảnh nhanh nhẹn hiện có.

Đây là một bài viết thú vị về các công cụ CASE trong môi trường Agile và những lợi ích / nhược điểm có thể có của chúng: http://www.agilemodeling.com/essays/simpleTools.htmlm

Chủ lao động của tôi (Không phải là Nhà phát triển) nghĩ rằng các công cụ CASE sẽ giúp chúng tôi cải thiện quy trình và tài liệu phát triển của mình. "

Nếu tôi sẽ đóng vai trò là nhà tư vấn cho chủ nhân của bạn, tôi sẽ có nghĩa vụ phải cố gắng can ngăn họ khỏi loại điều này. Trước hết, đó là một lỗi quản lý lớn khi có những người không liên quan đến công việc chọn công cụ cho nhà phát triển. Điều này gần như không bao giờ đi tốt. Điều đó ít nhất tệ gấp đôi khi những người đưa ra lựa chọn không có nền tảng kỹ thuật mạnh mẽ. Và nếu họ không có bất kỳ kinh nghiệm nào với các công cụ họ đang thúc đẩy, đây có thể là một sự thất bại hoàn toàn.

Lý do rất có thể là loại điều này đang được đề xuất bởi quản lý phi kỹ thuật là bởi vì ai đó đang cố gắng bán cho họ một cái gì đó. Một công ty lớn bán những thứ này có doanh thu đang giảm như một zeppelin chì trong không khí hiếm. Nhân viên bán hàng (còn gọi là người bán lại, chuyên gia tư vấn) chưa chuyển sang một thứ khác đang cố gắng tìm kiếm nhãn hiệu mới, ... khách hàng. Một trong những lý do chính khiến các công ty này gặp khó khăn là không còn nhiều nhu cầu về các loại công cụ này nữa. Theo 'các loại công cụ này', ý tôi là các công cụ hứa sẽ 'loại bỏ mã viết'. Không có gì sai với mã, tùy thuộc vào ngôn ngữ. Mã viết có sự trừu tượng mạnh mẽ hơn nhiều so với những gì các công cụ này cung cấp.

Một trong những lý do chính khiến đây là một cách kém để quản lý sự phát triển là nó sẽ làm giảm nghiêm trọng nhóm người bạn có sẵn để kéo về đội ngũ nhân viên của bạn. Đối với một người, họ cần học những công cụ không phổ biến này và thứ hai, hầu hết các nhà phát triển có kinh nghiệm không muốn làm việc với những thứ này. Thông thường, xung quanh các loại công cụ này là bạn không thực sự cần các nhà phát triển giỏi vì những công cụ này thực hiện hầu hết các công việc nặng nhọc. Điều này là hoàn toàn sai. Nó là điều ngược lại. Họ làm tất cả những việc không quan trọng và thường làm cho những phần không tầm thường trở nên khó khăn hơn. Họ cũng không bao giờ thực sự loại bỏ sự cần thiết phải viết mã.

Cụ thể với các công cụ CASE, tôi đã làm việc tại ba nơi khác nhau sở hữu các gói này. Trong mỗi một, nó đã đi như thế này:

1. Mô hình được thiết kế tỉ mỉ trong công cụ. Phải mất nhiều thời gian hơn bình thường và không có sản phẩm nào có thể sử dụng được sản xuất cho đến khi rất muộn trong nỗ lực.
2. Các mô hình cần phải được tăng cường với logic kinh doanh. Mô hình đã sai và phải điều chỉnh thủ công trong các giai đoạn cuối của dự án vì nỗ lực đã quá hạn.
3. Đồng bộ hóa lại mô hình và mã rất tốn kém, công cụ CASE bị gác lại, không bao giờ được sử dụng lại.

Tóm lại, đó là một thất bại hoàn toàn 100% và lãng phí tiền trong mỗi trường hợp. Khi tôi nói chuyện với những người khác đã sử dụng các công cụ CASE trong các tổ chức khác, câu chuyện luôn luôn giống nhau. Tôi đã không sử dụng tất cả các công cụ này và có thể một số người đã sử dụng chúng rất tốt nhưng tôi khá chắc chắn rằng hầu hết các đội đã sử dụng chúng đã ngừng sử dụng chúng từ lâu.

Một trong những lợi ích bạn sẽ nhận được khi điều tra / triển khai các công cụ CASE là bạn sẽ có được một bộ kỹ năng thị trường hơn cho việc làm trong tương lai. Tôi nghĩ rằng nhiều mối quan tâm của bạn là đáng chú ý, nhưng, như David Kaczynski đã chỉ ra, đây không phải là một câu hỏi lập trình nhiều vì đây là một câu hỏi về mối quan hệ chủ nhân / nhân viên. Một lợi ích khác của các công cụ CASE là một khi đã học, công ty của bạn sẽ ở vào vị trí để đảm nhận một loạt các dự án có độ phức tạp lớn hơn. Rất có thể là một hợp đồng mà chủ nhân của bạn đang tìm kiếm để yêu cầu, hoặc ưu tiên sử dụng các công cụ CASE.

Bạn đang trộn lẫn vấn đề và giải pháp và sếp của bạn đang cố gắng giúp đỡ, với ít nhiều thành công. Để thách thức sếp của bạn, bạn phải hiểu rõ vai trò của bạn trong tổ chức là gì. Nếu anh ấy là Giám đốc điều hành và bạn là CTO, quyết định là của bạn và Giám đốc điều hành chỉ nên chỉ ra những khía cạnh kinh doanh bị ảnh hưởng bởi việc thiếu tài liệu. Nghĩa vụ của bạn sau đó là giải quyết vấn đề kinh doanh, với công cụ CASE hoặc bất kỳ giải pháp nào khác mà bạn đưa ra.

Về đề xuất cụ thể về việc sử dụng các công cụ CASE, tôi nghĩ bạn phải chọn nó đúng cách để bạn đạt được mục tiêu của mình mà không làm quá tải nhóm của bạn với công việc làm thêm. Nếu tài liệu là những gì bạn muốn cải thiện, bạn có thể có đủ với một công cụ có thể tạo sơ đồ từ mã, không nhất thiết phải tạo mã từ sơ đồ đồ họa. Một ví dụ về một công cụ như vậy là Codelogic . Tôi đã sử dụng một vài năm trước để đảm bảo rằng các thiết kế của chúng tôi rõ ràng và dễ hiểu và khá dễ sử dụng. Nếu như bạn thể hiện tiền là một mối quan tâm khác, có lẽ bạn có thể tìm trong nguồn mở (tôi không thể giúp ở đây nhưng sẽ quan tâm đến kết quả của bất kỳ nghiên cứu nào).

Sự thay thế cho các công cụ CASE cũng có thể giúp đỡ. Đo lường những thứ như chu kỳ hoặc các biện pháp phức tạp khác sẽ giữ cho thiết kế của bạn có cấu trúc tốt và các nhà phát triển tập trung vào mã. Nhận xét tốt hơn về mã của bạn, giống như Javacode, cũng có thể giúp cải thiện tài liệu.

Thành thật mà nói, tôi nghĩ rằng nếu bạn cho rằng các công cụ CASE không giúp sếp của bạn phải biết điều đó. Nếu anh ấy là một ông chủ tốt, anh ấy sẽ coi trọng ý kiến ​​của bạn. Tôi chưa bao giờ thích một nhân viên chỉ làm những gì anh ta nói mà không phân tích quan trọng. Nhưng tất nhiên, như David gợi ý, bất kỳ cuộc thảo luận nào cũng nên được giữ vững bằng những lập luận mạnh mẽ và khách quan.

Tôi sẽ cố gắng làm cho chủ nhân của bạn nhận ra rằng anh ấy / cô ấy đã nhận được những điều ngược lại. Nếu có chỗ cho đầu tư cho nhóm phần mềm, bạn nên xác định các điểm nghẽn hoặc vấn đề chất lượng của bạn là gì. NẾU nó chỉ ra rằng bạn có nhiều cơ hội để cải thiện các lĩnh vực quy trình phát triển và tài liệu, bạn nên xác định những thay đổi nào có ROI lớn nhất liên quan đến việc cải thiện các lĩnh vực này. Điều đó có thể hoặc có thể không bắt đầu sử dụng các công cụ CASE.

Giúp ông chủ của bạn, giúp chính mình

Bạn có thể phản ứng hoặc hành động theo yêu cầu này.

Ghi nhớ tất cả các câu hỏi "Di chuyển núi Phú Sĩ"? Nếu bạn đang trong một cuộc phỏng vấn cho một công việc bạn thực sự muốn, bạn sẽ không nói với người phỏng vấn rằng câu hỏi đó ngu ngốc đến mức nào, nhưng sẽ tiếp tục đặt câu hỏi và bày tỏ ý tưởng tốt nhất của bạn về việc giải quyết nó. Ở một số nền văn hóa, bạn sẽ không bao giờ nói không với một ông chủ thực sự yêu cầu bạn di chuyển Núi Phú Sĩ, nhưng sẽ tìm cách để bạn vừa giữ thể diện.

Lọc lại câu hỏi

Nếu bạn định điều chỉnh lại câu hỏi thành một cái gì đó như,

"Tôi có thể mua hoặc có được một bộ công cụ tự động hóa càng nhiều tác vụ năng suất thấp liên quan đến phần mềm càng tốt không?"

nhiệm vụ này trở nên ngon miệng hơn nhiều. Giúp sếp của bạn (và chính bạn) bằng cách cung cấp cho anh ta một tùy chọn có khả năng truy nguyên rõ ràng với CASE và một hoặc hai tùy chọn dựa trên Agile / mã nguồn mở / đám mây.

Xem lại CASE

Vào những năm 90, các công cụ CASE có thể có dạng một bộ công cụ từ Rational có thể bao gồm Requisite Pro, Rational Rose, Clear Case, Rational Robot (một người chạy thử), Purify, Pure Co hiểm và Quantify và một số công cụ khác đã được tích hợp với nhau. Nếu bạn là một cửa hàng MAD (Y tế, Hệ thống điện tử, Quốc phòng), bạn có thể sử dụng các phiên bản cập nhật của các công cụ này để tạo tài liệu và đồ tạo tác rộng rãi và có thể theo dõi thường được khách hàng yêu cầu trong các thị trường đó.

Liên hệ với IBM và nhờ nhân viên bán hàng đưa ra báo giá cho năm giấy phép (hoặc chỉ một giấy phép nổi). Thêm vào một số đào tạo quá. Chia sẻ trích dẫn này với người quản lý của bạn có thể kết thúc cuộc nói chuyện về các công cụ CASE. Nhưng đừng hiểu sai ý tôi. Tôi thích Rational, các nhà khoa học chính của họ và các sản phẩm của họ, nhưng chủ yếu truy cập chúng thông qua giấy phép trang web của trường đại học vì giá của chúng quá cao so với các công ty nơi tôi đã làm việc. Nếu bạn được chấp thuận, ít nhất là từ kinh nghiệm của tôi, họ sẽ đối xử với quyền của bạn với sự hỗ trợ tốt, đào tạo chất lượng (thường là ở một khu nghỉ dưỡng hàng đầu với thức ăn tuyệt vời).

Công cụ để bán

Bạn vẫn có một cơ hội tuyệt vời để đi mua sắm công cụ. Các nhà phát triển Agile cũng cần các công cụ. Bạn có thể mua một bộ cung cấp cho bạn hỗ trợ tài liệu cho thẻ câu chuyện trực tuyến, ca sử dụng, ca sử dụng và các loại sơ đồ UML khác. Atlassian có những gì tôi nghĩ là một bộ công cụ tuyệt vời - Jira cho nhiệm vụ và theo dõi lỗi, Green Hopper cho những gì họ mô tả là quản lý dự án Agile, Confluence cho wiki mạng nội bộ, Crucible để đánh giá mã trực tuyến và Bamboo cho máy chủ tích hợp liên tục. Có phần mềm làm giấy phép dịch vụ cho những bộ này và các bộ công cụ khác nhắm vào nhu cầu của bạn nếu bạn là Agile.

Tích hợp IDE là một con đường khác để có được một năm 2012 CASE tương đương. Nếu bạn là nhà phát triển của Microsoft, Visual Team Studio có các công cụ có phạm vi tương tự như những gì Rational tạo ra. Họ có một số kỹ thuật phần mềm khứ hồi, tạo ra các bài kiểm tra đơn vị từ các lớp, tích hợp với các hệ thống kiểm soát nguồn và một loạt các công cụ để hợp tác nhóm.

Công cụ nguồn mở

Về phía nguồn mở, Eclipse và nhiều trình cắm thêm của nó cố gắng tích hợp một loạt các công cụ nguồn mở. Tôi không chắc liệu Khung mô hình hóa Eclipse đã trưởng thành hay nếu có các công cụ khác mang lại cho kỹ sư phần mềm khứ hồi hiệu quả, nhưng lần trước tôi đã xem xét, có vẻ như nó không dễ đạt được. Môi trường Qt Creator tích hợp với kiểm soát nguồn và có một số khả năng để giúp kiểm tra tại chỗ từ phạm vi bảo hiểm mã của các thay đổi khi bạn ở trong trình chỉnh sửa.

Áp dụng công cụ tăng dần lặp đi lặp lại

Một cách tiếp cận lặp lại / gia tăng để lựa chọn công cụ cũng có thể rất hiệu quả. Các dự án nguồn mở thường hỗ trợ các môi trường đơn hoặc nhiều. Lựa chọn công cụ của bạn có thể bị ảnh hưởng bởi các ngăn xếp mà bạn sử dụng. Không bao giờ có thời điểm tốt để đóng cửa hoàn toàn sự phát triển, vì vậy, thêm và đào tạo đội ngũ trong một vài công cụ nhỏ hơn mỗi quý có thể tốt hơn một cách tiếp cận lớn làm thay đổi mọi thứ cùng một lúc.

Giải pháp công cụ đám mây

Nhiều giải pháp được liệt kê có thể yêu cầu máy chủ và thiết lập tương đối phức tạp. Có rất nhiều tùy chọn xuất hiện trên thị trường dựa trên nền tảng đám mây và cung cấp phần mềm dưới dạng dịch vụ được nhà cung cấp lưu trữ với một khoản phí hàng tháng. Điều này có thể có ý nghĩa đối với nhóm của bạn, dù là ngắn hạn hay dài hạn. Một số có thể có một giải pháp lưu trữ mà bạn có thể sử dụng để bắt đầu nhanh, với tùy chọn mua giấy phép sau này.

Không có gợi ý nào trong số này là một con đường rẻ tiền và dễ dàng để cải thiện năng suất tức thì, nhưng nếu bạn có thể tìm thấy một số công cụ không thể thiếu một khi bạn thử chúng.

Một điều tôi muốn thêm vào câu trả lời tuyệt vời ở đây là bạn có thể được lợi từ việc hiểu cách bạn muốn "cải thiện quá trình phát triển của mình".

Xu hướng áp đảo trong 20 năm qua là tối ưu hóa phát triển phần mềm theo thời gian đưa ra thị trường. "Agile", "lean", DevOps, TDD, BDD - tất cả họ đều muốn đưa phần mềm chất lượng ra khỏi cửa càng nhanh càng tốt.

Công cụ CASE không phải là về thời gian để thị trường. Họ tập trung vào truy xuất nguồn gốc, tính nhất quán trong thiết kế, tính hoàn thiện của mô hình, v.v ... Đây đều là những khía cạnh có giá trị - đặc biệt là trong các hệ thống ngân hàng - nhưng chúng phải trả giá bằng thời gian đưa ra thị trường.

Vì vậy, có thể hỏi sếp của bạn chính xác những gì anh ta đang cố gắng tối ưu hóa.

Từ kinh nghiệm, làm việc với các công cụ CASE nhanh chóng trở nên khó khăn hơn so với làm việc với mã - đặc biệt là khi làm việc với các miền có vấn đề phức tạp hơn bình thường. Dự án dừng lại là một dự án "ngân hàng", và thay vào đó trở thành một dự án "chèn tên của CASE-tool-here".