고용주의 말을 듣고 CASE 도구를 사용해야합니까?

저의 고용주 (개발자가 아님)는 CASE 도구가 개발 프로세스 및 문서를 개선하는 데 도움이 될 것이라고 생각합니다. 우리는 현지 고객을 위해 모바일 뱅킹 솔루션을 구축하는 5 명의 개발자로 구성된 소규모 팀입니다. CASE 툴은 구매해야하므로 시간과 비용이 낭비 될 것으로 생각되며, 모델링에 익숙해 지려면 시간과 시간이 필요합니다. 코드 생성은 또 다른 문제입니다. CASE 생성 코드는 좋은 개발자가 작성한 코드만큼 좋지 않을 것이라고 생각합니다.

민첩한 원칙, 디자인 패턴을 고수하고 TDD를 사용하고 코드를 깨끗하게 유지한다고 생각합니다. 우리는 잘해야합니다. 그리고 분석 및 디자인에 있어서는 화이트 보드의 간단한 UML 다이어그램이 트릭을 수행해야한다고 생각합니다. 문서는 훌륭하고 중요하지만 가능한 한 적게 작성해야하며 문서에만 집중하고 코드를 잊어서는 안됩니다. 이것이 내가 생각하는 것입니다.

제가 맞습니까? 또는 고용주의 말을 듣고 적절한 CASE 도구를 연구해야합니까?

상황은 결정에 대한 분석적 접근을 보증합니다. 결론은 "Case 도구가 비즈니스에 가치를 제공합니까?"입니다. 종종 경영진은 개발자가 조직의 현재 프로세스 및 문화에 얼마나 잘 맞는지에 관계없이 방법론이나 도구를 채택하기를 원할 것입니다.

ChrisF가 지적한 것처럼 고용주가 CASE 도구를 살펴 보라고 요청한 경우이를 준수해야합니다 (프로그래밍이 아닌 작업장 문제임). CASE 도구 채택에 영향을 줄 수있는 몇 가지 요소는 다음과 같습니다.

• 어떤 프로세스에 사용 가능한 CASE 도구가 있습니까?
• 새로운 도구를 채택하기 위해 몇 인당 시간이 필요한지 추정
• 새로운 도구를 채택하면 프로세스가 어떻게 변할까요?
• 또는 새로운 도구를 채택함으로써 어떤 긍정적 (또는 부정적인) 영향이 측정 될 수 있습니까?

이것을 개발 환경과 프로세스를 업그레이드 할 수있는 기회로 생각하십시오. 현재 프로세스가 조직의 문화와 완벽하게 일치 할 수도 있지만 적절한 연구를 수행하기 위해 고용주와 팀에게 맡겨야합니다.

예, CASE 도구에 대한 연구를 시작해야합니다.

1. 도움이되지 않을 것이라는 주장을 뒷받침 할 증거 가 필요 하기 때문입니다. 당신은 결코 그들이 당신을 도울 것임을 알 수 있습니다.
2. 고용주가 당신에게 말했기 때문입니다.

나는 David Kaczynski가 그의 훌륭한 답변 에서 제시 한 요점 을 정확하게 반복하지 않을 것 입니다.

코드 생성을 통해 실제로 애자일에서 CASE / MDA 지향 개발로의 큰 패러다임 전환처럼 보입니다. 프로젝트 관리 관점 (CASE 접근 방식이 반복, 사용자 스토리, 빠른 피드백 또는 지속적인 개선 개념과 충돌하지는 않음) 일 필요는 없지만 "소프트웨어 기술"관점에서 분명히 그렇게하므로 코드에 대한 통제력이 떨어집니다. 읽을 수없고, 단단하며, 테스트하기가 더 어려우며, 지속적으로 모델과 동기화해야하는 코드 등이 생성되고 생성됩니다.

당신이 묘사 한 것에서, 고용주에게 필요한 것은 쉽게 이해할 수 있습니다

• 개발자가 팀을 떠나는 경우 지식 손실을 피하기 위해 더 나은 문서화.
• 더 빠른 개발 프로세스.

소프트웨어 전문가는 CASE 접근 방식이 이러한 기대치를 충족시키는 능력에 대한 의심을 분명히 말할 수 있습니다. 또한 필요한 경우 CASE 도구를 살펴 보는 것도 귀하의 의무입니다. 그중 하나를 시도한다고해서 1 / 결과가 만족 스러울 것이라는 것을 의미하지는 않습니다 (특히 개발해야 할 필요성과 충돌하는 잠재적으로 큰 코드 생성 오버 헤드에 대해 생각하고 있습니다). 기존 민첩한 컨텍스트를 유지하면서 CASE 도구 (다이어그램, 문서 생성)의 일부 기능이 사용되는 절충안을 찾으십시오.

애자일 환경의 CASE 툴과 그 장점 / 단점에 대한 흥미로운 기사가 ​​있습니다 : http://www.agilemodeling.com/essays/simpleTools.htm

저의 고용주 (개발자가 아님)는 CASE 도구가 개발 프로세스와 문서를 개선하는 데 도움이 될 것이라고 생각합니다. "

만약 당신의 고용주를위한 컨설턴트의 역할을하려고한다면, 나는 이런 종류의 것들로부터 그것들을 설득해야 할 의무가 있습니다. 우선, 업무에 관여하지 않는 사람들이 개발자를위한 도구를 선택하게하는 것은 중대한 관리 오류입니다. 이것은 거의 잘되지 않습니다. 선택하는 사람들이 강한 기술적 배경을 가지고 있지 않으면 적어도 두 배나 나쁩니다. 그리고 그들이 추진하고있는 도구에 대한 경험이 없다면, 이것은 완전한 혼란이 될 것입니다.

비 기술적 경영진이 이런 종류의 것을 제안하는 가장 큰 이유는 누군가가 무언가를 팔려고하기 때문입니다. 이런 종류의 물건을 판매하는 한 주요 회사는 희귀 한 공기 속에서 납 제플린처럼 떨어지는 수입을 가지고 있습니다. 다른 곳으로 이동하지 않은 영업 사원 (일명 리셀러, 컨설턴트)은 새로운 마크, 즉 고객을 찾기 위해 노력하고 있습니다. 이 회사들이 어려움을 겪고있는 주요 이유 중 하나는 더 이상 이러한 종류의 도구에 대한 수요가 많지 않기 때문입니다. '이러한 종류의 도구'라는 말은 '코드 작성을 제거 할 것'을 약속하는 도구를 의미합니다. 언어에 따라 코드에 아무런 문제가 없습니다. 작성된 코드는 이러한 도구가 제공하는 것보다 훨씬 강력한 추상화를 가지고 있습니다.

이것이 개발을 관리하는 나쁜 방법 인 주된 이유 중 하나는 팀 직원을 끌어들이는 데 사용할 수있는 인력을 크게 줄일 수 있기 때문입니다. 하나는,이 흔하지 않은 도구를 배워야하며, 둘째, 대부분의 숙련 된 개발자는 이러한 일을하고 싶지 않습니다. 종종 이러한 도구를 중심으로하는 것은 이러한 도구가 대부분의 작업을 수행하기 때문에 훌륭한 개발자가 필요하지 않다는 것입니다. 이것은 완전히 거짓입니다. 반대입니다. 그들은 사소한 모든 일을하고 종종 사소한 부분을 어렵게 만듭니다. 또한 코드를 작성할 필요가 전혀 없습니다.

특히 CASE 도구를 사용하여 이러한 패키지를 소유 한 세 곳에서 근무했습니다. 모든 하나에서 다음과 같이 진행되었습니다.

1. 이 모델은 도구로 설계되었습니다. 평소보다 훨씬 오래 걸리고 노력이 늦어 질 때까지 사용 가능한 결과물이 생산되지 않았습니다.
2. 비즈니스 로직으로 모델을 보강해야했습니다. 모델이 잘못되었고 프로젝트가 너무 늦었 기 때문에 프로젝트 초기 단계에서 수동으로 조정해야했습니다.
3. 모델과 코드를 다시 동기화하면 CASE 도구를 선반에 다시 넣지 않아도되므로 비용이 많이 들었습니다.

간단히 말해서, 그것은 모든 경우에 100 % 총 실패와 돈 낭비였습니다. 다른 조직에서 CASE 도구를 사용한 다른 사람들과 이야기했을 때 이야기는 거의 같습니다. 이러한 도구를 모두 사용하지는 않았으며 일부 사람들이 도구를 잘 활용했을 가능성이 있지만,이를 사용한 대부분의 팀은 오래 전에 사용을 중단했을 것입니다.

CASE 도구를 조사 / 구현함으로써 얻을 수있는 이점 중 하나는 향후 고용을 위해보다 유용한 기술을 습득 할 수 있다는 것입니다. 데이비드 카친 스키 (David Kaczynski)가 지적한 것처럼, 이것은 고용주 / 직원 관계 질문만큼 프로그래밍 문제가 아닙니다. CASE 도구의 또 다른 이점은 일단 배우면 회사는 더 복잡한 프로젝트를 더 광범위하게 수행 할 수 있다는 것입니다. 고용주가 원하는 계약이 CASE 도구 사용을 선호하거나 선호하는 계약일 수 있습니다.

당신은 문제와 솔루션을 혼합하고 있으며 상사는 거의 성공으로 도움을 주려고합니다. 상사에게 도전하려면 조직에서 자신의 역할이 무엇인지 분명해야합니다. 그가 CEO이고 CTO 인 경우 결정은 귀하의 결정이며 CEO는 문서 부족으로 인해 어떤 비즈니스 측면이 영향을 받는지 지적해야합니다. 그런 다음 CASE 도구 또는 다른 솔루션을 사용하여 비즈니스 문제를 해결해야합니다.

CASE 도구 사용에 대한 구체적인 제안과 관련하여 추가 작업으로 팀에 과부하를주지 않고 목표를 달성 할 수 있도록 올바르게 선택해야한다고 생각합니다. 문서화를 개선하려는 경우 그래픽 다이어그램에서 코드를 생성 할 필요는 없지만 코드에서 다이어그램을 생성 할 수있는 도구가 충분할 수 있습니다. 이러한 도구의 예는 Codelogic 입니다. 나는 몇 년 전에 깨끗하고 명확한 디자인을 이해하고 사용하기 쉽게 만들기 위해 사용했습니다. 돈을 표현하는 것이 또 다른 관심사라면 아마도 오픈 소스를 볼 수 있습니다 (여기서는 도울 수 없지만 모든 연구 결과에 관심이있을 것입니다).

CASE 도구의 대안도 도움이 될 수 있습니다. 순환 적 또는 기타 복잡성 측정과 같은 것을 측정하면 설계가 잘 구성되고 개발자가 코드에 집중할 수 있습니다. Javacode와 같은 코드에 대한 주석이 좋으면 문서를 개선하는 데 도움이 될 수 있습니다.

솔직히 CASE 도구가 상사가 그것을 이해하는 데 도움이되지 않는다고 생각하면 생각합니다. 그가 좋은 상사라면 그는 당신의 의견을 소중하게 생각할 것입니다. 나는 비판적 분석없이 자신이 말하는 것을 수행하는 직원을 결코 좋아하지 않았습니다. 그러나 물론 다윗이 제안한대로 모든 토론은 강력하고 객관적인 주장에 대해 논의해야합니다.

나는 고용주가 자신이 물건을 거꾸로 받았다는 것을 깨닫게하려고합니다. 소프트웨어 팀에 투자 할 여지가 있다면 병목 현상이나 품질 문제가 무엇인지 식별해야합니다. 경우 당신이 문서와 개발 프로세스 분야에서 개선을위한 대부분의 여지가 있음을 밝혀, 당신은이 지역을 개선 관련하여 가장 큰 투자 수익 (ROI)을 가지고 어떤 변화 식별해야합니다. CASE 도구를 사용하기 시작했을 수도 있고 그렇지 않을 수도 있습니다.

당신의 상사를 도와주세요

이 요청에 반응하거나 행동 할 수 있습니다.

"후지산 이동"질문을 모두 기억하십니까? 당신이 정말로 원하는 직업에 대한 인터뷰에 있었다면, 당신은 면접관에게 그 질문이 얼마나 어리석은지를 말하지 않고 질문을 계속하고 문제 해결에 대한 최선의 아이디어를 표현할 것입니다. 일부 문화권에서는 실제로 후지산을 옮기라고 요청한 상사에게 거절하지 말고 얼굴을 구할 수있는 방법을 찾으십시오.

질문을 재구성

질문을 다음과 같이 재구성하면

"소프트웨어와 관련하여 생산성이 낮은 많은 작업을 자동화하는 도구 모음을 구매하거나 구입할 수 있습니까?"

이 과제는 훨씬 맛있어집니다. CASE에 대한 명확한 트래커 빌리티 옵션과 하나 또는 두 개의 애자일 / 오픈 소스 / 클라우드 기반 옵션을 제공하여 상사 (및 자신)를 도울 수 있습니다.

CASE 재검토

90 년대에 CASE 툴은 Requisite Pro, Rational Rose, Clear Case, Rational Robot (테스트 러너), Purify, Pure Coverage 및 Quantify 및 기타 여러 툴을 포함한 Rational 툴 세트의 형태를 취할 수 있습니다. 그것은 함께 통합되었습니다. MAD (Medical, Avionics, Defense) 상점 인 경우 이러한 도구의 업데이트 된 버전을 사용하여 해당 시장의 고객이 필요로하는 광범위하고 추적 가능한 문서 및 아티팩트를 생성 할 수 있습니다.

IBM에 문의하여 영업 사원에게 5 개의 라이센스 (또는 하나의 유동 라이센스)에 대한 견적을 제공하십시오. 훈련도 추가하십시오. 이 견적을 관리자와 공유하면 CASE 도구에 대한 이야기가 끝날 수 있습니다. 그러나 나를 잘못 이해하지 마십시오. 저는 Rational, 수석 과학자 및 제품을 좋아하지만 제가 일한 회사에 비해 가격이 너무 높기 때문에 주로 대학 사이트 라이센스를 통해 액세스했습니다. 귀하가 적어도 내 경험을 통해 승인을 받으면 귀하의 권리를 훌륭한 지원, 양질의 교육 (보통 훌륭한 음식이있는 최고의 리조트에서)으로 대우 할 것입니다.

판매 도구

여전히 툴 쇼핑을 할 수있는 좋은 기회가 있습니다. 민첩한 개발자도 도구가 필요합니다. 온라인 스토리 카드, 사용 사례, 사용 사례 및 기타 UML 다이어그램 유형에 대한 문서 지원을 제공하는 제품군을 구입할 수 있습니다. Atlassian은 작업 및 버그 추적을위한 Jira, Agile 프로젝트 관리를위한 Green Hopper, 인트라넷 Wiki를위한 Confluence, 온라인 코드 검토를위한 Crucible, 지속적인 통합 서버를위한 Bamboo를위한 훌륭한 도구 모음이라고 생각합니다. 민첩한 경우 귀하의 요구를 대상으로하는 이들 및 기타 툴 세트에 대한 서비스 라이센스로서의 소프트웨어가 있습니다.

IDE 통합은 2012 년 CASE에 상응하는 또 다른 방법입니다. Microsoft 개발 하우스 인 경우 Visual Team Studio에는 Rational에서 작성한 것과 유사한 범위의 도구가 있습니다. 여기에는 왕복 소프트웨어 엔지니어링, 클래스의 단위 테스트 스텁 생성, 소스 제어 시스템과의 통합 및 팀 협업을위한 다양한 도구가 있습니다.

오픈 소스 도구

오픈 소스 측면에서 Eclipse와 수많은 플러그인은 여러 오픈 소스 도구를 통합하려고 시도합니다. Eclipse Modeling Framework가 성숙했는지 또는 효과적인 왕복 소프트웨어 엔지니어를 제공하는 다른 도구가 있는지 확실하지 않지만 마지막으로 보았을 때 달성하기가 쉽지 않았습니다. Qt Creator 환경은 소스 제어와 통합되며 편집기를 사용하는 동안 코드 적용 범위에서 스팟을 확인하는 데 도움이되는 몇 가지 기능이 있습니다.

반복적 인 증분 도구 채택

공구 선택에 대한 반복 / 증분 방식도 매우 효과적 일 수 있습니다. 오픈 소스 프로젝트는 종종 단일 또는 다중 환경을 지원합니다. 도구 선택은 사용하는 스택의 영향을받을 수 있습니다. 개발을 완전히 중단 할 수있는 좋은 시간은 없으므로 분기마다 몇 가지 작은 도구로 팀을 추가하고 교육하는 것이 모든 것을 한 번에 변경하는 빅뱅 접근 방식보다 낫습니다.

클라우드 툴 솔루션

나열된 많은 솔루션에는 서버와 비교적 복잡한 설정이 필요할 수 있습니다. 클라우드 기반의 많은 옵션이 있으며, 월별 요금으로 공급자가 호스팅하는 서비스로 소프트웨어를 제공합니다. 이는 단기 또는 장기적으로 팀에 적합 할 수 있습니다. 일부는 나중에 라이센스를 구입할 수있는 옵션과 함께 빠른 시작에 사용할 수있는 호스팅 된 솔루션을 보유 할 수 있습니다.

이러한 제안 중 어느 것도 즉각적인 생산성 향상을위한 저렴하고 쉬운 길은 아니지만, 일단 도구를 사용해 본 후에 필수 도구를 찾아야하는 경우가 있습니다.

여기서 훌륭한 답변에 추가 할 한 가지 사항은 "개발 프로세스 개선"방법을 이해하면 도움이 될 수 있다는 것입니다.

지난 20 년 동안 압도적 인 추세는 출시 기간 동안 소프트웨어 개발을 최적화하는 것이 었습니다. "Agile", "lean", DevOps, TDD, BDD-품질 소프트웨어를 최대한 빨리 제공하는 것입니다.

CASE 툴은 출시시기가 아닙니다. 추적 성, 설계 일관성, 모델 완성도 등에 중점을 둡니다. 이는 특히 은행 시스템에서 가치있는 측면이지만 시장 출시 시간이 소요됩니다.

따라서 상사에게 정확히 무엇을 최적화하려고하는지 물어보십시오.

경험상 CASE 도구를 사용한 작업은 코드를 사용하는 것보다 빠르게 어려워집니다. 특히 평균적으로 복잡한 문제 도메인을 다룰 때는 더욱 그렇습니다. 프로젝트는 "뱅킹"프로젝트가 중지되고 대신 "CASE-tool-here 삽입"프로젝트가됩니다.