2010-08-29 3 views
6

... 또는 왜 실패 했나요?왜 CASE 도구가 성공하지 못했습니까?

나는 CASE로 분류 될 수있는 개념의 증거를 만들 예정이지만 이전에 수행 한 실수 중 일부를 피하려고합니다.

감사합니다.

+0

ok ... 어떤 종류의 사례 도구를 알고 있는지 알려주십시오. CASE는 컴퓨터 지원 소프트웨어 엔지니어링을 의미하므로 ... 매우 다양한 도구를 선택할 수 있습니다. (왜냐하면 내가 그렇게 요정 같은 방식으로 말하기 란 거의 불가능하다고 생각하기 때문이다.) –

+0

그렇다면 돌파구였던 3 가지 사례 도구를 쉽게 명명하고 도움이되는 방법을 설명해야한다. 일반적인 견해는 CASE가별로 유용하지 않기 때문에 묻습니다. 예를 들어 다른 답변을보십시오. CASE 도구의 개념은 좋은 생각이지만 CASE 도구의 좋은 예를 들어 본 적이 없으므로 이름을 지정하고 설명해주세요. 감사합니다. –

+0

왜 도구가 성공하지 못했습니까? 그들은 성공했습니다. 당신이 CASE 툴에서 생각할 때 당신은 어떻게 생각합니까? 몇 가지 획기적인 사례 도구를 쉽게 알 수 있습니다. 어쩌면 당신은 uml 도구에서 생각하고 있습니까? 또는 코드 생성 또는 도구? –

답변

7

첫째, 다이어그램은 작고 단순 할 때 실제 가치를 제공한다고 생각합니다. 크고 매우 상세한 다이어그램은 대부분 종이, 시간, 하드 드라이브 공간 등을 낭비합니다. 연필과 종이는 유용 할 수있을만큼 작고 (그리고 충분히 단순한) 다이어그램에 대해 상당히 잘 작동합니다. 소프트웨어 도구는 실제로 크고 복잡한 다이어그램을 생성 할 때만 유용합니다. 실제로는 쓸모 없게 보장됩니다.

둘째, 대부분의 경우 다이어그램을 그리는 가장 빠른 방법은 일부 (단순화 된 모형) 코드를 작성한 다음 코드에서 다이어그램을 "리버스 엔지니어링"하는 것입니다. 다이어그램을 직접 그리는 것은 종종 코드를 작성하는 것보다 느립니다. 많은 실제 가치를 제공하기 위해, 높은 수준의 다이어그램을 생성하는 것은 동등한 코드를 작성하는 것보다 훨씬 간단해야합니다.

당신이 그것에 익숙해지면 어쨌든 "소프트웨어 엔지니어링"에 대한 실제 "지원"으로 사용되는 사례 도구를 거의 보지 못했습니다. 필자가 보았던 대부분의 경우, 소프트웨어 엔지니어링은 완전히 독립적으로 수행되었으며 CASE 도구는 이미 작성된 코드에서 다이어그램을 리버스 엔지니어링하는 데 사용되었습니다. 다이어그램을 작성하는 사람들은 일반적으로 쓸모가 없다는 사실을 발견하고 "와우 요소"에 대한 상위 관리자에게보고했습니다. 그들이 다이어그램에서 바라는 유일한 "원조"는 자금 조달을 증가시키기 위해 자신이하고있는 일의 복잡성을 감수하고있었습니다 (표준 라이브러리의 일부분과 같이 순수하게 명백한 복잡성을 추가하는 다이어그램 포함) .

편집 : 소프트웨어 엔지니어링 부분에서 도구가 어떻게 실패했는지에 관해서는 단 하나의 간단한 답을 모릅니다. 내가 본 것에서는 "천명의 죽음" 칙칙한 문제 "라고 말합니다. 하나의 커다란 문제를 지적해야만한다면, 내가 본 것 중 하나는 패턴을 고려하지 않는 것입니다. 예를 들어, 내가 원하는 것은 더 높은 수준의 추상화에서 작업하는 것입니다. 그래서 몇 가지 기능을 가리킬 수 있으며 다음과 같은 기능을 구현할 경우 어떻게 보입니까? 데코레이터 클래스? " 그렇습니다. 데코레이터 클래스로 하나의 다이어그램을 그릴 수 있지만 실제로는 "이 전체 계층 구조를 변형하여 데코레이터 클래스로 X, Y 및 Z를 옮길 수 있습니다."라고 말하는 것은 쉽지 않습니다.

대조적으로 스프레드 시트가있는 일반적인 사례 도구. 스프레드 시트에서 셀 하나를 변경할 수 있으며 스프레드 시트의 다른 요소에 영향을 미치는 방식을 자동으로 다시 계산합니다. 대조적으로 CASE 도구는 (적어도 내게는) 셀 컨트롤을 변경할 수있는 대략적인 그리드 컨트롤 수준에 머물러 있지만, 다른 셀이 그 셀에 종속되어 있는지 수동으로 추적해야합니다. 영향을받은 모든 세포를 손으로 사용하고 계산하고 수정하십시오. 네, 올바른 값의 시트를 인쇄하여 컴퓨터에서 편집 할 수 있다면 셀에 지우개 흔적이 없어야합니다. 은 개선 될 수 있지만 은 작은입니다. 개인용 컴퓨터를 몇 명의 애호가를위한 장난감에서 본질적으로 지구상의 모든 비즈니스의 필수품으로 전환시킨 것은 아닙니다.

+0

아, interresting :) 다이어그램 대신 모형 용 구문 (모형 코드와 유사)을 사용하고 다이어그램과 문서를 생성한다고 가정 해 보겠습니다. 지금 당장에 얻으려고하는 것은 "소프트웨어 엔지니어링"부분입니다. 이 도구는 어떻게 실패 했습니까? –

2

위키피디아 항목을 보면 http://en.wikipedia.org/wiki/Computer-aided_software_engineering을 볼 수 있는데, 1990 년대의 "고전적인"도구를 볼 수 있습니다. 이러한 도구들로 많은 작업을 해본 결과, 상용화에 초점을 두어 시장이 분열되었다고 생각합니다. 일반적으로 도구에 대한 엄청난 금액을 지불했을뿐만 아니라 컨설팅, 교육 및 런타임 환경에 많은 돈을 지불했습니다. 많은 도구가 제공 되었기 때문에 주어진 도구를 전문으로하는 유능한 팀을 구성하는 것이 어려웠습니다.

또한 도구가 과다 판매되는 데 도움이되지 않았습니다. 유망한 경영진은 비현실적인 생산성 향상을 가져옵니다. 너무 많은 선반 - 제품을 한 프로젝트에 사용한 다음 포기하고 종종 프로젝트와 함께 사용하는 다른 IT 분야는 없습니다.

CASE의 개념은 Eclipse 및 많은 다른 MDE 도구에 있습니다. 가파른 학습 곡선 및 단편화 문제는 아직 해결되지 않았습니다. 도구의 비용이 절감되어 (많은 경우 무료), 컨설팅 및 비용 상승은 여전히 ​​존재합니다.

CASE 도구에서 많은 노력을하기 전에 MDA, MDE, DSL, 심지어 UML 필드를 살펴보십시오. 그 가치는 OMG 웹 사이트에서도 찾아 볼 가치가 있습니다.

하루가 끝나면 도구가 아닌 제품에 집중해야합니다. 몇 가지 작업을 자동화 할 수 있다면 좋습니다. 또 하나의 사례와 같은 도구를 구축하는 것은 훌륭한 지적 연습이지만 상업적 성공의 기회는 거의 없습니다. 결국 IBM, Oracle 및 Computer Associates는 툴을 사용하여 산발적 인 성공을 거두었지만 여전히 기업 고객에게 적극적으로 마케팅하고 있습니다.

관련 문제