제목 : J2EE 개발 툴, 방법론 최상의 조합은??
글쓴이: 김경태(tweni) 2003/03/06 05:23:58 조회수:21929 줄수:29 |
|
일반적은 J2EE프로젝트 환경에서의 개발도구들의 최상의 조합(?)은 무엇일까요..?
CASE툴과 개발툴과 방법론을 모두 포함해서요
best practices를 찾아봅시다..
프로젝트관리 : MS Project 2002
문서 : Office XP (PPT, XLS, WORD)
객체모델링 : Together6(산출물 작성시 문서생성기능활용)
데이타모델링 : 파워디자이너 9
개발 : Eclipse + Dreamweaver MX + Ultraedit
WAS : Resin(서블릿만) or Weblogic(EJB를 쓴다면..)
웹서버 : Apache
테스트 프레임워크 : Cactus
빌드툴 : Ant
프레임워크/패턴 : Struts + EJB식의 자체 개발 프레임워크
VO - Bussiness Object(ORMapping API를 사용하며 SQL은 별도의 XML파일에 기술) - Command(서블릿)
- Velocity(JSTL에서 벨로시티로 바꿨습니다. 벨로시티가 생산성도 높고 드림위버랑 궁합도 좋군요)
기타 각종 유틸성 클래스들을 개발해서 사용합니다.(ex: request parameter를 VO에 자동매핑 등)
코드생성기? : 테이블 스키마를 이용 위의 패턴에 맞추어 실제 동작하는
어플리케이션 소스를 생성하는 코드생성기를 개발하여 사용
컬럼에 코멘트를 달면 UI와 주석에 활용하는 기능..등
DBMS : Oracle
DB툴 : Toad
형상관리 : CSV + Wincsv
부족하지만 제가 생각하는 것을 적어보았습니다..
실제로 위와 같이 적용한 부분도 있고 그렇지못한 부분도 있습니다..
여러분의 생각은 어떠신지요..
|
제목 : Re: 딴지는 아니지만
글쓴이: 손님(guest) 2003/03/06 22:45:07 조회수:1398 줄수:3 |
|
프로그램도 사람이 하는거지요 ^^;;
이건 좀...
|
제목 : Re: 최상의 조화이군요.
글쓴이: 손님(guest) 2003/03/06 23:47:08 조회수:1657 줄수:7 |
|
실제 프로젝트에서 그러한 툴과 방법론을 다 활용하는지는 의문이지만...
위에서 언급한 것들을 수용할 수 있는 개발팀이라면 A급이라고 할 수 있겠죠.
몇가지 더 추가하자면 문서는 MS 엑셀도 많이 쓰이고 있고, 그냥 오피스XP라고 하죠
소스 에디터로는 Ultraedit10.0, WAS는 JBoss가 휼륭하고 개발시 Oracle 9i는 너무 무겁죠
HyperSonicDB나 MySQL정도가 적당할듯..그 외 성능 측청도구로 Borland Optimizer5.0
요구사항관리툴로는 Borland CaliberRM이 좋죠..^^
|
제목 : Re: 대단한 조합니다...
글쓴이: 난이아빠(baram4x) 2003/03/08 03:23:09 조회수:1396 줄수:56 |
|
문제는 위의 모든 프로그램들을 사용할 수 있고, 제대로 이해하는가
입니다.
실제 프로젝트에서 MS Project에서 나온 문서를 보고 프로젝트
스케줄이나 인력관리를 제대로 이해하는가 ?
RUP등의 문서들을 개발자나 고객이 제대로 이해하는가??
이상의 문제들로 인해서
소스의 개발팀이 아니면 대규모의 개발인 경우에는
사실상 불가능하져...
그래서 대부분의 문서를 오피스( MS Office 아님 ) 프로그램에서
작성한 문제를 사용하구요...
조금 나은 버전은 모델링 툴이나 설계 툴에서 자동으로
오피스 문서를 만드는 방법을 쓰죠.
그리고 개발툴은 자동화 툴보다는 에디터를 활용하는
경우가 많습니다. 그 이유는 일단 자동화 툴을 알아야 하는
문제와 개발자들의 성격이 워낙 다양하기 때문에 각자
스타일에 맞는 걸 쓰죠..
그리고 가장 중요한 것은 일단 프로젝트를 하게 되면
TF팀에서 기본적으로 아키텍쳐에 대해서 모든 설계와
검증을 끝난 모델을 제시하기 때문에...
일반 개발자들은 샘플소스를 참고하구. 왜 쓰는지만
파악하여 개발하는 경우가 많습니다.
즉, 일반 개발자들은 업무에 중심을 두고 개발하게 되는것이죠.
내부적인 아키텍쳐나 프로그램 모듈에 대해서는 필요로
하는 것이 어느 모듈인지만 알면 된다는 것이죠..
참고로 제가 바로 전에 했던 프로젝트에는 200명정도가
참여했는데...
위의 툴을 검토하다가 결론은 엑셀로 MVC모델관련
문서 모두를 만들었습니다.
참으로 노가다였져...
그럼.
----------------------------------------------------
난이 & 성이 아빠
홈 페이지 http://kr.geocities.com/baram4x/
E-mail baram4x@--NO-SPAM-hotmail.SPAM-NO.com
|
제목 : Re: 딴지
글쓴이: 손님(guest) 2003/03/10 19:23:18 조회수:1404 줄수:26 |
|
음....
핵심 기술자라....
직업에 따라 보통 약간의 공통적 성격이 드러나는데
전산직 사람들의 경우는 잡기에 능하고 어떤 일에 대해 과대포장을 잘하죠.
이러한 경향은 소위 일류대 출신의 젊은 개발자들에게서 많이 나타납니다.
불필요한 것들에 대한 과장이나 언급을 통해 자신의 주가를 올리는...
마치 프로젝트 자체가 자신의 손에서 놀아나는 양....
그리고 특징이 집단적으로 활동하죠. 아마?
겸손만 하다면 정말 훌륭한 인재들인데 말이죠.
ps:김경태님이 소개해줘서 이아스(이창신)님에 대해 알게 됬는데
김경태님이랑 같이 활동하시더군요
그리고 한가지 더 이창신씨의 시나리오 또는 글들은 참으로 형편없었습니다.
그건 시나리오도 아니었는데..에이 자신들을 너무 포장하는 것 같아요.
그냥의 모습이 더 좋은데...
|
제목 : 딴지 답변
글쓴이: 김경태(tweni) 2003/03/11 03:43:37 조회수:1189 줄수:7 |
|
개인적으로 이아스님을 알지못합니다.
단지 매우 선도적인 내용의 교육이 생각해서 적은것인데..
내용과 관련이 없는듯하여 삭제하였습니다.
위글은 저 자신을 과대포장하고자 쓴 글이 아니라
여러 고수님들의 기술적인 비판이나 조언을 얻고자 하는것입니다.
답변달아 주신 분들게 감사드립니다. 많은 도움이 되었습니다.
|
제목 : Re: 딴지라는 글에 동감합니다.
글쓴이: 손님(guest) 2003/03/11 09:27:42 조회수:1095 줄수:24 |
|
저역시 딴지라는 글에 동감합니다...
그리고 실제로 그러한 사람들을 꽤 접했구요...
정말 역겨워서 상대하기도 싫은 사람들이라고 생각하구요...
상당히 거슬릴지도 모르지만 프로젝트팀에 꼭 존재하더군요..
위의 글처럼 겸손만하다면 너무나도 좋은 사람들이라고 생각은 합니다만...
역시 프로젝트는 혼자서 하는게 아니겠지요....
하지만 그와 반대되는 사람도 많지요...
정말 이사람이 개발경력 6년7년쯤 된사람인가 의심가는 사람들....
경력만됐다고 직급올라가는 사람들...
사실 이런사람들을 보면 역겹습니다....
이런현상은 조직이 큰곳일수록 심하더군요...
이런데 있으려면 아무소리 안하고 있는게 최고겠지요...
거저 월급올려주면 암소리안하고 받고... 승진시켜주면 좋다고 받고....
지금 있는 소위 말하는 대기업이라는 곳이 이렇더군요...
나도 소속되어 있는 조직이라서 가슴이 아픕니다...
머하다가 이런말이...
여하튼 모두 겸손하고 자기의 능력을 개발합시다...
|
제목 : Re: 좋은 툴들이기는 하지만..
글쓴이: 조대협(guest) 2003/03/11 11:10:56 조회수:1168 줄수:8 |
|
허허.. 툴이나 환경을 보니 참 좋기는 하군요...
그렇지만, 저정도를 다 소화해낼 수 있는 개발자의 수준이란게... 현실상에서 얼마나
가능할지 궁금합니다.
물론, 저정도의 툴과, 기반지식을 가지고 있는 경험있는 개발자분들도 계시겠지만,
실무 프로젝트에서 저것을 적용할때까지 수많은 시행착오를 겪을것 같다는 생각이 드네요..
이런말 하면서도.. 저도역시 말씀하신 툴과,방법론,패턴등을 적용하고자 공부하는 사람
중에 하나입니다.
정말 배움에는 끝이 없지요? ^^
|
제목 : Re: 다양한 솔루션의 점검이 필요
글쓴이: 이원영(javaservice) 2003/03/11 11:26:05 조회수:2510 줄수:178 |
|
(IBM에 몸담고 있는 몸이라, 다소 한쪽에 치우친 생각일 가능성이 있으나, 몇가지 피력
해 보겠습니다.)
WAS(Web Application Server), IDE(Integrated Development Environment) Tool 및
Database Product에 대한 특정 제품을 못박아 언급/생각하는 경우는 스스로를 제품
종속화 시켜, 자신의 Skill Set이 협소해 질 수 있습니다.
1. WAS(Web Application Server)
각 시장조사기관에 따른 market-share 시장현황입니다.
Garter Copyright 2002
Application Platform Market-share 2002
Application Server Market-share 2002
Korea Market-share 2001-2002
eWEEK & 소프트뱅크리서치
Korea Market-share 2002
(워낙 민감한 부분들이라, 몇 번 편집을 했습니다. 대부분이 삭제하는 것으로 결론이
났지만..... SI업체에 있을 땐, 제 의견을 맘대로 피력했지만, 이젠 제 의견을 함부로
올릴 수 있는 입장이 아닌 듯 하네요... 쩝)
NOTE: Tmaxsoft의 최근 1-2년 사이에 일어난 괄목할 만한 성장이 주목됩니다. Tmaxsoft는
Tmax라는 TPM 솔루션과 더불어 WAS인 JEUS Application Server를 전면에 내세워 매우
공격적인 모습으로 공공/금융시장을 뚫어내고 있습니다. 한국 시장에서만 일어나는
특이현상으로 BEA의 TUXEDO를 Tmaxsoft의 Tmax로, 금융/공공분야에서의 WebSphere 및
WebLogic으로부터 JEUS로의 winback, 심지어 Host기반의 시스템까지 Host Link를 통한
winback 등, 그 공격적인 영업력은, 다소 시장에서 언짢은 평판을 듣기도 하나, 최소한
향후 1-2년 동안은 지속될 것으로 예상됩니다. 이러한 상황은 BEA나 IBM에게는 타격이
아닐 수 없으며, 한국 WAS Market-share를 뚜렷하게 변화시키는 요인으로 작용하고
있습니다. 가장 타격을 받을 것으로 우려되는 부분은 한국IBM보다는 BEA코리아 및
IT-PLUS일 가능성이 높으며, market-share 1위 였던 BEA WebLogic의 경우, Tmaxsoft JEUS의
마켓 성장으로 인해 한국IBM에게 1위를 내어줄 가능성이 높다는 것이 결국 앞서의 최근
2002년 한국 WAS시장 market-share의 자료로 나타나고 있습니다. 또한, BEA WebLogic에
대한 한국총판 IT-PLUS와의 독점계약이 끝나고 다수의 총판업체으로 분산/전환시키는
과도기적 상황이 WebLogic market-share에 긍정적으로 작용할 지 부정적으로 작용할지는
좀 더 지켜봐야할 것으로 보입니다.
한국Oracle의 경우, 지난해 대대적인 반격을 선언한 것에 비하면 결과론적으로 특별한
성장을 이뤄내지 못한 것으로 판단됩니다.(Oracle 9iAS의 경우, 가능성이 대단히 높음에도
불구하고, 힘과 동력을 끌어내지 못함이 안타깝습니다)
SUN ONE의 기치아래 적잖은 노력을 들이 SUN의 iPlanet의 경우 ....
2. IDE(통합개발환경) Tools
IDE Tools로서는 Boland JBuilder, IBM WSAD(WebSphere Studio Application Development)
Oracle jDeveloper, WebGain Studio 등이 있으며, 항상 WAS제품과 전략적 공조하에
Selling이 일어나며, WAS와의 Integration을 강조하게 됩니다.
개인적으로, UltraEditor나 Notepad를 이용하여 개발하는 개발자는, "아무리 IDE툴이
좋다고는 하지만, 자동으로 모든 것을 처리하는 과정이 어떻게 보면 좋을 듯 하지만,
막상 IDE Tool을 이용할 경우, Bug도 많고, 자동으로 생성되는 코드가 어줍잖을 수 있으며
개발/컴파일/테스팅/Deploy과정을 자동으로 해 주는 편리함보다는 엔지니어가 직접
직접 UltraEditor 및 Ant와 같은 도구를 이용하여 Customizing하는 것이, 실질적인
기술적 이해 및 연구하는 데에는, 개발자의 실력이 높아갈 수록 더 낫더라" 라는 관점을
갖고 있을 수 있습니다.
그러나, 저 역시 그러한 생각에 공감한 적이 3-4년간 있었지만, 어느 순간 부터인가
IDE툴을 왜 그동안 사용하지 않았던가를 후회할 만큼, IDE Tool의 편리함과 신속한
개발, 테스팅, WAS와의 Integration등의 강점을 확신하고 있습니다.
Boland JBuilder는 사실상 전세계적으로 market-share 1위이며, Boland의 경우 AppServer
보다 IDE Tools시장이 더 전략적인 제품으로 인식되고 있는 듯 합니다.
IBM WSAD의 경우는 기존 VisualAge for Java에서, Eclipse기반의 WebSphere Studio
Family 제품군을 내어놓게 되는데, Eclipse 환경 자체가 전세계적으로 광범위한
호응을 얻으면서 WebSphere Studio 역시 효과적으로 시장에 대응하고 있습니다.
제품군은 크게 4가지로 나뉘는데, WSSD(WebSphere Studio Site Developer), WSAD
(WebSphere Studio Application Developer), WSAD-IE(WebSphere Studio Application
Developer Integration Edition) 및 WSED(WebSphere Studio Enterprise Developer)로
packaing되어 있습니다. (개인적으로 Eclipse기반으로 된 IBM의 WebSphere Studio
제품군들은 그 인터페이스와 편리함에 있어서, 가장 막강하고 편리한 IDE툴로 평가하고
있습니다.)
Symantec VisualCafe가 2000년 경에 WebGain사로 흡수되면서, WebGain사는 WebGain Studio,
DreamWeaver(HTML 저작툴), JSP Editor, VisualCafe, StructureBuilder(UML을 이용한
모델링 툴), TopLink(OR mapping tool), Application Composer, Quality Analyzer,
Business Designer 등을 제공하고 있으며, 전략적으로 BEA WebLogic과 가장 많이
Selling되고 있습니다.(정정: 아래의 SW-Yu님글 참조)
Oracle의 경우, Boland의 JBuilder를 라이센싱하여 Oracle JDeveloper라는 이름으로
자사 제품화 하였는데, Oracle 9iAS를 내어 놓으면서 전면적으로 Swing 인터페이스로
바뀌어 있더군요.
이처럼 IDE Tools 시장은 인터페이스의 편리성과 기능성에 더불어 WAS 툴과 얼마나 잘
통합되어 있느냐에 따라 평가되어져야 하며, 앞으로도 시장규모는 꾸준히 늘어날 것입니다.
또한, IDE 툴은, Ant와 같이 Customizing되어할 대부분의 절차를 내부적으로 제공하고
있을 뿐만 아니라, 팀개발 및 버전관리를 위한 형상관리 기능까지를 모두 포함하고 있는
경우가 대부분입니다.
PS: IDE Tools에 대한 글을 적으면서, 99년에 작성한 아래의 글이 떠오르는 군요.
1 WEB개발 및 Application Server동향
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=consult&c=r_p&n=936757537
3. 데이타베이스
Database 역시, Oracle만이 능사가 아니라, IBM UDB DB2, Informix, Sybase, Microsoft
SQL Server 등, 고객의 상황에 따라, 그리고 구축하려는 해당 시스템의 특성에 따라
선택적으로 사용될 수 있어야 겠지요. 엔지니어 입장에서 보면, 어느 하나의 DB에 종속적이
되기 보다는, 다양한 환경에서 개발/운영할 수 있는 skill이 필요합니다. 이 부분에
있어서는 Java언어 개발자는 타 언어개발자보다 쉽고 유연하게 대응할 수 있는 위치에
있지요.
4. 성능 테스팅/관리
개인적으로 Performance 분야가 가장 관심있는 부분이기에, JMeter를 언급한 부분은
다소 우려의 느낌을 갖고 있습니다. 성능관리 분야에는 크게 3가지 정도의 영역으로
나누어 볼 수 있습니다.
하나는 테스팅 툴입니다. Mercury사의 RoadRunner (http://www.merc-int.com),
Rational Suite Performance Studio (http://www.rational.com), Mindcraft사의 WebStone
(http://www.mindcraft.com), 등과 같은 외국 상용제품이나 라메르정보기술㈜의 e-Test
Suite(http://www.lamer.co.kr) 등과 같은 국산 웹스트레스툴들도 몇몇 출시되어 있습니다.
반면, Microsoft 사의 Web Application Test Tool(http://webtool.rte.microsoft.com)이나
Apache그룹의 Apache Bench와 같이 웹서버에 내장되어 있는 무료의 간단한 툴들도 존재하며
앞서 언급한 Apache의 JMeter도 미약한 기능을 갖고 있는 유사한 툴입니다..
IBM의 Alphaworks에 가면 WPT(Web Performance Tool)을 무료로 제공하고 있으며 누구나
다운받을 수 있습니다. 제품에 따라 측정할 수 있는 방법이나 기능이 천차만별이며,
다양한 실제 부하 환경을 시뮬레이션하려면 가급적 상용제품을 사용할 것을 적극 권합니다.
테스팅 툴은 그 기능성을 떠나서, 어떻게 테스팅할 것인가, 어떤 성능관리 방법론을 적용할
것인가와 같이 전문적인 기술지원이 필수적이기 때문입니다.
또하나는 성능관리/모니터링 제품군입니다. 지난 번, 펜타시스템테크놀러지(주)에서
WAS(Web Application Server) 성능관리솔루션 중의 하나인 Willy Technology사의 Willy4와
같은 제품들이지요. 국내 WAS시장이 형성된 것이 98년 말부터라고 본다면 대략 4년을
갓넘는 역사를 갖고 있습니다. TPM(Transaction Monitoring Management)시장이 지난
C/S(Client/Server)시기의 메인 미들웨어였다면, 지금의 WAS를 주축으로 한 J2EE
어플리케이션서버 미들웨어시장이 전체 미들웨어시장의 50%이상을 차지하는 수준으로
급성장 했지만, TPM미들웨어가 제공해 주었던 안정적인 Transaction 관리 및 성능관리
기술은 WAS시장에서도 -때늦은 감이 없잖아 있지만 이제서야- 본격적인 도입이 예상되고
있습니다. 그러나, 아직, WAS환경하에서의 Transaction관리는 C/S환경의 그것에 비하면
걸음마 수준에 지나지 않은 듯 합니다.
(성능관리 솔루션은 다양하게 있을 터인데, 추가적으로 조사되는 대로, 이곳에 첨가/수정
할 예정입니다.)
세번째로는 Profiling Tool들입니다. Boland의 OptimizeIt Tool이나 JProbe 등과 같은
Tool들이 여기에 속하며, 클래스/메소드 레벨로 CPU 및 메모리 사용량을 보여줍니다.
그러나, Profiling의 특성상 Profiling을 ON 시킬 경우, JIT(Just In Time)를 Off해야
하는 점과 더불어 운영상의 Performance가 급격하게 저하되는 현상을 보일 수 있습니다.
반면, Memory Leak이나, 자신의 어플리케이션 코드를 Optimize/Tuning할 때 효과적인
결과를 얻을 수 있습니다.
아래의 글에서 몇가지 유용한 정보를 더 얻을 수 있을 것입니다.
531 Resources for Java Performance Tuning
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=consult&c=r_p&n=1027528989
무엇보다 중요한 것은, 이제는, SI 개발단계, 방법론 단계의 각 stage마다 Performance
관점이 녹아들어야 할 시점이라는 것이지요. 시스템을 오픈하고 나서야 장애를 직면하고
그 때서야 성능진단을 받는 것은 매우 비효과적이라는 것을 차츰 공감해 나가고 있는
시점입니다.
또하나, 짚고 넘어가야 할 부분은, 아직 "성능분석이론의 부재"가 가장 심각하며,
급변하는 미들웨어 환경변화를 신속하게 이해하고 모델링하여 이론적인 발전을 이루어
내어야 할 시점이라는 것입니다. 성능관리, 용량산정, 벤치마크테스트 등을 수행함에
있어서, 현재의 IT업계는 왜곡된 이론과 경험의 부재로 몸살을 앓고 있습니다.
589 웹퍼포먼스이론: 실사이트 측정결과보고서 및 관련언급
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=consult&c=r_p&n=1035524021
PS: 상용 WAS에는 기본적인 성능관리 기능은 내장되어 있으니, 이 또한 상용 WAS를
사용하는 잇점 중의 하나가 됩니다. (예를 들어, WebSphere Application Server
Version 5의 경우에는 Tivoli Performance Viewer, Performance Advisor, Thread Analyzer,
Request Metrices 등의 성능관리 모듈이 제공됩니다.)
NOTE: RUP로 잘 알려진 Rational사가 IBM에 인수되었다는 부분이 의외로 시장에선 잘
알려지지 않고 있음이 의아스럽습니다.
http://news.com.com/2100-1001-976327.html
http://www.ibm.com/news/us/2002/12/061.html
http://biz.yahoo.com/bw/021206/62064_1.html
자바서비스넷 이원영
 2.gif (12791 Bytes)
4.gif (96558 Bytes)
1.gif (17342 Bytes)
5.gif (22160 Bytes)
3.gif (8076 Bytes)
|
제목 : Re: 툴보다 중요한 것은 커뮤니케이션..
글쓴이: ck(Rainman1) 2003/03/11 13:40:45 조회수:1296 줄수:66 |
|
was, db, 개발도구, 그룹웨어 까지 언급이 되었는데,
일을 하는데에 있어서 환경이 갖춰지는건 부수적인 문제라 생각합니다.
중요한 것은 고객과 프로젝트팀의 커뮤니케이션이 선행되어야 하고,
둘째로는 프로젝트의 특성에 적합한(요구사항,개발기간,개발인력구성 등)
올바른 방법론 선택과 그것에 대한 모두의 공유와 이해가 이루어져야 하고,
그 다음이 그에 적절한 개발환경의 선택입니다.
개발환경을 중시여겨 개발이전에 혹은
중도에 상당한 투자를 했음에도 불구하고,
도입자체가 무의로 돌아가는 사례가 상당수가 존재합니다.
이유는 개발환경, 도구에 대해 갖는 관점이 잘못되었기 때문이죠.
개발도구는 그 자체에 '기능성'에 촛점을 두어 우수성을 평가할 수 있습니다.
그렇다면, 도입하려는 개발도구들이 개별적으로 각각의 '기능성'의 측면에서,
최우수란 평가를 받았고, 그것을 도입한다면, 프로젝트는 성공에 가까워지는걸 까요?
답은 'NO'라고 생각합니다.
하나의 프로젝트 측면에서 개발도구의 가치는
프로젝트 전체의 일부로써의 '커뮤니케이션'의 역할에 있고,
그 이후에서야 '기능성'으로써 가치가 있다고 생각합니다.
도구가 프로젝트의 특성에 맞지 않아
어떠한 커뮤니케이션에도 도움이 되지 못하거나,
중복된 다른 무언가가 결합되어야 해결이 된다거나,
적극적으로 사용되지 못하거나, 오히려 과도한 무엇을 요구하게 된다면
도입하지 않는만 못하게 될 수도 있습니다.
(문서를 위한 과도한문서, 코드생산을 위한 과도한 코드생산, 중복목적의 툴사용
(툴의 세부역할 수행에 미흡으로 인한 또다른 도구들 도입, 추가로 도구 생산 등..
(여기서 '커뮤니케이션'이란 개개인의 정보전달을 위한 공유만이 아닌,
(프로젝트 요소들에 대한 피드백을 불러일으키는 것들, 가능하게 하는 것들을 통칭합니다.
(즉, 결과산출,문제보고 등.. 어휘력이 부족해서 커뮤니케이션 말고는 생각이 않나서..
하나의 프로젝트는 커다란 땅으로 볼 수 있고,
시간,요구사항, 개발인력, 리스크들이 곳곳에 놓여있습니다.
프로젝트는 리스크들을 피해가며 이 모든 것을
최소의 비용으로 타통하는 노선을 만드는 노력과 같다고 생각합니다.
회의,커뮤니케이션,체크주기,테스트,컨벤션,프레임웍,개발도구 등 개개는
서로 다른 측면에서의 중복체크 혹은 잦은 커뮤니케이션이 필요한 '교차로'와,
커뮤니케이션이 반드시 거쳐야 하는 '지점' 등을 연결하는 개별노선이라 생각합니다.
개발도구는 이러한 측면에서 하나의 자원으로 고려되어야 하는 것이죠.
전체적 측면에서 노선이 적절한 지점을 타통할 수 있느냐 없느냐가 문제이고,
다음이 고속전철이 갈 수 있는 노선이면 더 좋다..라는 것이죠, 도구 또한 마찬가지입니다.
좋은 평가를 받는 도구는 제너럴한 케이스에서 좋은 평가를 받는 것이고,
개별 프로젝트마다 만점을 받을 순 없겠죠~ 마이너스의 효과를 가져올 지도 모르죠.
혹시라도, 원글을 읽으신 분이 개발환경이 프로젝트를 성공으로 이끄는데
다른 것보다 우선시 된다는 것으로 받아들여 성급히 구매를 추진하지 않을까 싶어,
경험도 일천하고, 아는 것도 없는데 성급히 개인적 의견을 긁적였습니다..
이만..
p.s : RUP와 XP의 tailoring이 플러스 효과를 낳을 수 있을까 고민을 해봅니다.
각각은 적합한 특성의 환경에서, 최대의 효과를 거둘 수 있는 최소한의 자원에 대한
실천에 대해 언급이 되었는데, 임의로 특정요소를 빼고, 다른 요소를 도입하거나 했을 때엔,
원래의 의도에 벗어나, 빈틈이 생기기 마련이라서 상당히 유의해야 하지 않을까 싶습니다.
(가령 규모가 상당한 프로젝트에서도 언제든 요구사항이 변경가능하다하고,
(코드의 수정변경이 해당모듈외의 팀에게까지 공유하자는 식으로 나온다면..^^;;
p.s2 : 성능관리나 테스트, 모니터링을 수행한 적이 거의 없어,
처음으로 jmeter를 사용중이였는데, 말씀대로 빈약함에 목말랐었는데,
이원영님이 적어주신 성능관리/테스트 부분, 정말 도움 많이되었습니다. 감사합니다.
|
제목 : Re: 평이하네요...
글쓴이: 손님(guest) 2003/03/11 14:30:19 조회수:1265 줄수:13 |
|
요즈음 많이 쓰는것들이군요... 평이합니다...
하지만...글쎄요..RUP + XP라...
개념을 아시는 분이라면 모르겠지만...좀 힘들겠져...
음음...T_T
새롭다는 느낌은 안들지만...
위에 있는 툴들 다 익히려면....
신입개발자는 죽어나겠군요....
암튼 수고...
--------------------------- 최고와 최신만이 가장좋을수는 없다고 봅니다. ---------
|
제목 : Re: 이원영님의 좋은 자료에 몇가지 더 첨부 하자면
글쓴이: S W Yu(guest) 2003/03/11 16:26:43 조회수:1404 줄수:42 |
|
저도 Visual Cafe와 , TopLink, Structure Builder 사용자로서 그 제품들을 퍽 선도적인
제품 라인으로 긍정적인 평가를 했었으나, 무리한 인수로 결국 WebGain이 작년(2002년)
8월에 TopLink는 Oracle에 팔았고, 나머지 제품군은 모두 TogetherSoft에 매각했습니다.
매각 조건은 냉정하지만, VisualCafe 제품 라인을 더이상 가져 가지 않는다는 조건입니다.
그리고 꾸준히 StarBase등 모델링 회사를 인수 해온 볼랜드가 결국 TogetherSoft를
인수 하였습니다. 지금은 TogetherCC 와 WSAD 용 Together 그리고 볼랜드 스튜디오에 포함된
Together Borland Edition 이 있습니다.
그리고 JBuilder에 아성을 무너뜨리거나 균형을 깰 수 있는,
실제로도 많은 자바 개발자 IDE포럼의 반은 이 제품의 이름입니다.
아시는 분은 잘 아실거라 생각됩니다. 저도 역시 포토샵처럼
단축기가 많은 이 제품의 기능과 지능성에 감탄을 하고 있습니다
저는 도구가 개발자의 순수한 기술 역량을 저해 하는것이 아니라
오히려 상호 생산적이라고 생각합니다.
일주일에 십만라인의 코드의 생산 비율을 지능화된 도구로 더 많이
혹은 더 정확하게, 사내 솔루션 코드들의 메타에디터 역활도 한다면
더 낫지 않을 까요.
자동화의 내부 메카니즘을 모르고 인터페이스만으로 환경을
가져가는 단순성을 피하고, 약간의 시스템의 지식 정도와 플러그인의 구조 정도만
이해하는 수준이면 단순히 툴 쓰면 바보 된다는 말은 대응 할수 있을것 같습니다.
오히려 툴의 내부 자동화된 룰 엔진에 따라서 초급 개발자나 학습자는
더 생산적일수 있습니다. 근간의 어떤 CASE도구는 완벽한 개발 플랫폼을 갖추고
있어서 마지막 구현과 테스팅, 배포 그리고 QA(Quality Assurance) 항목의 Report까지
자동화 됩니다.
소프트웨어 개발의 자동화 영역은 점차 지능화 정도가 더 정확성이 증가되고 있고,
하드웨어 플랫폼 발전과 통합기술 , 통신 속도 발전, 기타 자동버그 검증기법이나
Model Checking(IBM,MS)같은 응용 Agent기술의 발전에 따라서, 많은 변화가 있을
것으로 생각됩니다.
한가지 아쉬운 점은 이원영 시샵님의 자료가 전형적인 벤더의 제품라인과
시장수요에만 기준으로 만들어진 자료라는 점입니다.
아울러 개발에 관련된 주요한 비교점을 말씀해주셨으면 더 좋았을 것 같습니다.
이 커뮤니티가 실험적인 기술에 대한 제3세계 혹은 OpenWorld로 보다
더 많은 다양성을 수용했으면 좋겠습니다.
저 역시도 신* MIS 프로젝트에 IBM WebSphere 5.0으로 환경을 구축했으나
간간히 내부 프로젝트 에서는 JBoss를 사용하고 있습니다.
|
제목 : Re: 한가지 더 고민할 것은...
글쓴이: 아름다운프로(guest) 2003/03/12 05:12:35 조회수:1884 줄수:120 |
|
좋은 많은 글들이 있어, 중복되는 내용은 피하고 한가지 고려사항에서
빠진 부분이 있는거 같아서 써봅니다.
좋은 IDE나 좋은 WAS, 좋은 ...
J2EE쪽에 관심을 가지고 있거나 관련 업무를 해보신 분이라면 어떤 것들이
좋고 나쁘고.. 때로는 어떤 업무나 환경에서 어떤 것을 쓰는 것이 좋다라는
것은 개인적이든 사람들을 통해서건 많이 접할 것으로 압니다.
위에서 논의 되는 것들을 보면..비용이 어느정도 발생하고 그것에 있어서의
비교 검토에서의 자료라면 어려모로 도움이 되는 것이겠지만,
현 시점에서의 중요한 또 다른 포인트는.. Open Project와 Free 라이센스 제품들도
이제는 비교 검토 대상에 들어야하지 않을까 합니다.
오픈 프로젝트에 대해서 그것을 어떻게 사용으로 써? 라고 말씀하시는
분들이 계시다면 한번쯤 다시 자료를 찾아보셨으면 합니다.
J2EE의 위에서 언급되었던 제품중에도 그 핵심엔진이나 커파일러등등은 Open Project
의 것을 사용하는 것은 이미 잘 알려진 사실이고 이것을 업체에서는 숨기는 것이
아니라 이들을 지원하고 함께 성장하고 있음은 인정해야할 사실 일 겁니다.
어떤 분은 위의 처음 글 올리신 분의 내용을 가지고 그 많은 것은 초보자가 공부하고
하려면 죽어난다고 하셨지만, 어떻게보면 이것은 아주 작은 부분이 아닐까도 합니다.
지금 처럼 경기도 안좋은 시점에서 기분좋게 비싼 고가의 제품을 쓰면 좋기야 하겠지만
그렇지 못한 환경도 아직은 많고, 특히 자체 솔루션의 개발에 있어서는 우선적으로는
오픈쪽에서 시작하여 상용화 제품을 붙여나가는 곳도 많은 것으로 압니다. ㅡㅡ;;
이렇게 말하면 배째라라고 말씀하실 분도 계실 겁니다.
그래서 어떻게 보면 처음 질문의 의도에서 처럼.. J2EE쪽에서 있어서는 어떤 툴을
선택해서 하느냐가 아주 중요하다고 봅니다.
(그러한 차원에서 이번 논의는 아주 좋은 내용이 아닐까 합니다)
최근 J2EE기반의 웹서비스기반의 개발을 하면서 이와 관련된 쪽의 많은 테스트와
고민을 한적이 있었습니다. 이것을 잠시 적어보며 글을 마무리 지어보겠습니다.
-------
웹서비스환경구축 : UDDI를 이용하는 부분에 있어서 private이나 public이냐에 따라
우선 고려대상이 됩니다. 현재 프로젝트의 영업과 수주를 담당했던 담장자는 이번
프로젝트를 웹서비스 기반으로 한다고 써냈는데 이것이 private이나 public 인지를
구분하지 않고 "웹서비스 기반 미들웨어 시스템"이라고 써넣은것 때문에 개발진행자
로써 처음부터 고민이 많았습니다. '..시스템' 시스템을 넣어줘야하는냐 마느냐..
웹서비스 개념없이 진행을 했기에 넣어준다고 했는데 이것은 public이 아닌 private
이 됩니다. 이러한 경우에선 웹로직이나 웹스피어에서 제공하는 서비스를 이용하면
좋겠지만, 이것에 대한 비용을 비용에 계산되지 않았답니다. 그렇다면 선택은?
JBoss에서 JBoss .NET 이란 것을 이용하는 방법이 대안이였습니다 ...
(EJB까지 사용하는 상황에서.. EJB를 사용하지 않는 경우라면 Tomcat+Axis면
되겠죠. )
JBoss .NET이란 것은.. 결국 Axis를 이용하는 방법입니다. (Axis는 Open Project의
산출물이라기 보다는 자바진영의 웹서비스쪽의 핵심으로 봐도 되겠죠.)
Axis에서 제공하는 Tool만을 이용하여 웹서비스를 구현해보신 분이라면 불편함을
많이 느끼셨을 겁니다.(특히 툴에 익숙해진 분이라면.. )
이를 극복하기 위해서 eclipse를 이용하여 우선은 플러그인이 있어서 설치해봤습니다.
결론적으로 사용하기엔 부적할만큼 아직 형편 없었습니다. 다음은 JBuilder7~8 테스트
7은 웹서비스를 이용하기엔 최신버젼과의 호환성이 떨어지고, 8은 Axis를 이용하여
개발하기엔 그래도 좋은 환경을 제공했습니다.
그런데 웹환경에서의 모든 것을 개발하기 위함에 있어서 struts를 개발 framework으로
생각하고 있었는데.. 1.0으로 하는 상황이라면 JBuilder8상황에서는 아주 좋은 환경이
였지만, 1.1기반으로 생각하였기에.. 1.1 기반으로 환경을 이리저리 바꿔봤지만,
제대로 되지 않았습니다.
이 시점에서 개발에 있어서 TDD(Test Driven Development)를 생각하여 Refactoring에
편한 툴을 다시 생각해고 이 부분에 있어서 가장 강점이 있는 IntellJ의 IDEA를
앞선 문제점이 해결이 되는지 테스트 해봤는데... 웹서비스 기반과 웹개발 환경으로써는
아직 다른 툴들에 비해 좀 떨어졌습니다.
그 다음의 선택은 IBM의 WSAD5 ...
한때 eclipse의 매력에 흡뻑 빠져 있다가 이 녀석을 접하니 eclipse가 초라하다는 느낌까지
들 정도로 많은 기능과 최근의 개발이슈에 대한 것이 묻어 있음을 알 수 있었습니다.
위의 모든 고민 부분이 이것을 이용하면 해결할 수 있는 상황...
하지만, eclipse의 장점중에 하나인 가벼운것에 비해 WASD는 기능이 늘어나며 상당히
무거운 느낌이 들었습니다. (다들 툴들에 비해 조금 더 무겁게 느껴짐 : 별다른 테스트
없이 그냥 체감느낌..)
그리고 또 한가지 중요한 문제중에 하나인.. 라이센스부분...
이런 글을 이곳에 올리는 것이 부적합할 수 있겠지만,
다른 툴들의 경우 최신 버젼의 크랙이나 시리얼을 구할 수 있었지만, WASD는 이것이
존재하지 않음 60일 평가버젼으로 우선 개발해야하는 상황.
(이 부분에 대해서 좀 더 이야기 해보면... 지금이 이러한 논의 처럼 아직 우리나라의
개발자들에겐 돈내고 툴을 이용하기 보다는 다들 구해다가(!) 쓰는 형편이 많습니다.
실제 SI든 현업에 그나마 툴이 책정이 되면 이것을 접하게 되는 것이 고작이고,
개발회사내에서는 더 말할 것도 없는 현실이죠... 더 길어지면 이야기가 이상해질 것
같고 어쨌든 ...) 몇개월 동안의 프로젝트를 60일 평가버젼을 가지고 계속해서 진행할
수 있을까라는 것에서 이것을 쉽게 선택할 수 없었음.
그래서 최종 결론은?
웹서비스 부분의 개발은 : JBuilder8을 기반으로 구현하고 Publishing ...
TDD가 적극 고려되야한다면 : 엔진 및 Util과 같은 개발의 일부를 IntellJ사용...
EJB 부분은 모든 툴들이 그래도 최근엔 잘 지원하므로 해당 개발쪽에서 관련 툴 사용...
JSP .. struts 개발 부분 : eclipse+tomcat+easystruts 사용 ...
J2EE 테스트 프레임워크는 : Cactus ...
요구사항 정의 및 설계/모델링툴 : Together6, ERWin
형상관리 : CVS + TortoisCVS
방법론 : Writing Effeective Use Cases(Cockburn)+ ERD +... +TDD ...
(문서를 좀(!) 제출해야하는 상황이라 문서제출면에서
Use Case로 요구사항 정의해서 Activate/sequense Diagram정도로 기본 문서
양식에 맞춤. 메소드1기법 또는 UML방식택이라 데이터흐름 형식으로 작성
해서 하면 양이 많아지므로(!) ERD로 앞선 Diagram과 양식을 대충 구성 ㅡㅡ;
양식 적당히 체우고 개발쪽에선 TDD쪽으로 전환)
...등등.. 이렇게 되었습니다.
상황이 이렇게 되다보니..
툴만을 놓고 봐도 모든 것이 쪼개지고 난리도 아닌 그림이 나왔답니다.
해결책으로는 해당분야 개발자에게 각지 다른 툴을 이용하게 한거나..
아니면 처음 의도했던 스펙을 바꾸던가 해야하는 것이겠지요... 생략...
(여기에 XML DB 도입이냐 RDB에서의 O/R Mapping이냐 등등의 이슈까지 더 있는데
이러면 글이 더 정신없이 복잡해 질 것 같아서 생략합니다. ^^; )
어쨌든, 이러한 상황을 쓰는 이유는..
지금의 변화해나가는 개발환경은 예전처럼 에디터에만 의존하는 개발하기에는
점점 어려워지고 좋은 툴을 사용하면 좀 더 편리한 것들을 제공해 준다는 겁니다.
하지만, 각기 툴의 특징과 지원하는 것에 있어서 조금씩 틀리기에 ...
예전처럼 난 XXX툴 메니아만을 외치며 한가지만을 고집하는 것도 꼭 좋은 것만은
아닐 수도 있다는 겁니다.
세상이 빠르게 변해 가는 만큼 어느것에 목매여서 옳고 그름을 이야기하기보다는
좀 더 많은 것을 접해보면서 거기에서 좋고 나쁜 것들을 발견하고 그것을 많은
사람들과 공유하고 하는 것이 되었으면 합니다.
이야기가 중간에 이상하게 빠졌지만 ...
상용화 제품뿐만이 아니라 Open Project들에도 많은 관심 가졌으면하는 생각과
이것을 고민하고 테스트 하는 사람들에도 많은 지지와 여러분의 참여를 기대해봅니다. ^^
(내용의 상당부분을 상용화 제품 이야기를 해놓고 이런 얘기하니 좀 이상하긴 하네요. ㅡㅡ;)
|
제목 : Re: 환경보다는 비용이 문제 ..
글쓴이: 박상길(likejazz) 2003/03/12 09:21:33 조회수:1226 줄수:23 |
|
저만한 제품군을 사용하면서 불법카피로 프로젝트를 진행한다는건 말이
안되죠 ?
모든제품을 정품으로 사용한다고 가정한다면 개발자 1인당 소요되는 비용이
엄청날듯 하군요 .
다행히 900만원짜리 Rational Rose 는 빠져 있군요 :)
어쨋든 저도 저 대열에 합류해보자면 DB툴에 SQLGate 라는 국산쿼리툴과 협업툴에
Exchange/Outlook, 모델링에 Rational Rose/XDE 를 추가하고싶습니다 .
그리고 방법론에서 RUP+XP 보다는 대형프로젝트임을 감안할때 그냥 RUP/UML 로 미는것이
나아보입니다 .
진정 접목을 원한다면 RUP+XP+MSF(Microsoft Solution Framework) 까지 추가하는것이
어떨런지 .. MSF 는 프로젝트 매니지먼트부분이 상당히 구체적이고 체계적으로 잘
정리되어 있습니다 .
------------------------------------------------------
Park, Sang Kil
http://www.likejazz.com/
|
제목 : Re: sqlgate참고로..
글쓴이: ck(Rainman1) 2003/03/12 11:42:36 조회수:1344 줄수:2 |
|
약간의 버그와 0.0x초 대에 대한 모니터링이 불가능하지만,매우 편하고 잘만들었더군요.
|
제목 : Re: 하지만 방법론에 있어서는......
글쓴이: Reno(renocruise) 2003/03/13 00:59:32 조회수:1176 줄수:19 |
|
윗 글들을 계속 읽고 있으려니..저의 허접한 수준에 정말 눈물이 날 지경입니다.
마침표 하나 하나 마다 .. 대인의 풍모가 느껴집니다.. ㅠ.ㅠ
RUP로 미는 것은 무리가 있다고 생각됩니다. RUP를 Full로 적용해서 할 수 있느
프로젝트가 과연 얼마나 있을지가 의심스럽습니다. RUP는 너무 방대해서 다른 여느
방법론 보다도 더욱 tailoring이 필수적인데요.. XP를 적용해서 사용하기에도 적합하다고
생각됩니다. 간혹 XP를 너무나 작은 프로젝트에만 한정하는 분들이 계신데 이는 다시한번
생각해봐야 할 듯 합니다.
개인적인 생각으로는, 실질적으로 프로젝트 매니지먼트 부분은 방법론에서 참조하는것도
좋지만, 실제 경험이 쌓인 회사/조직이라면 나름의 매니지먼트 방법론이 있을 텐데
그거 이상 좋은 것은 없지 않나 싶습니다. 너무 기존의 것에 연연하는 것은 큰 문제가
있지만 말입니다.
위 글을 쭈욱 읽고 나니 ... 콕번이 쓴 글중에...
제대로 된 사람들만 있으면... 그냥 놔두어도.. 프로젝트는 성공하기 마련...
이라는 내용의 글이 생각나는 군요..
RenoCruise
|
제목 : Re: 특정 툴에 얽매이지 말아야...
글쓴이: 다른손님(guest) 2003/03/13 23:19:24 조회수:1066 줄수:12 |
|
기본적으로 어떤 하나에 얽매이는 건 안 좋다고 생각합니다. 최상의 개발도구의 조합이란
없다고 생각합니다. 프로젝트에 따라서 조합은 늘 달라진다고 보는 게 맞지 않을까요?
최강 도구들의 조합을 뽑기 보다는 저마다 각각의 가치가 있는 툴들을 다룰 줄 알며 -
한가지 툴에 얽매이지 않은 유연한 개발자…….가끔 자기가 쓰는 툴만 최고다라고
생각하시는 분들이 있어서.. ) 그때 그때마다 조합할 수 있는 능력이 개발자에겐
중요하다고 생각합니다. – 너무 당연한 얘기가….쩝….
--
사실 이런 툴의 조합보다는 한국에서 프로젝트에 툴을 선정하는데 얼마나 개발자가 영향의
못 미치는 현실이 더 안타깝습니다. 천대 받는 개발자나 엔지니어에 대한 토론하는 게
어떨까요? 서른 중반이 되어가니 저도 그렇지만 제 주위에 개발자의 길을 포기하는
사람이 많네요…..
|
제목 : Re: 맞습니다...맞고요...
글쓴이: 또다른손님(guest) 2003/03/15 04:03:33 조회수:1259 줄수:5 |
|
저같이 떠돌이 SI를 하는 사람의 입장에선 해당 업체가 어느 서버를 쓰는지
어느 WAS를 쓰는지 안쓰는지 어느 업체와 아웃소싱하는지에 따라 천차만별
달라집니다. 일정 툴에 얽매여 있다면 정말 힘든 프로젝트를 해야 합니다.
가장 중요한 것은 어떤 툴이건 방법론이건 기본과 원리에 충실해야 한다는 것입니다.
|
제목 : Re: 돈많은회사와 적은 회사..
글쓴이: 스티브김(webarch) 2003/03/28 05:28:54 조회수:1832 줄수:11 |
|
저 회사는 분명...
돈많은 회사임에 틀림없습니다.
우리나라에서도 손가락에 꼽을수 있을 정도겠군요.
홈페이지 : www.javalinux.co.kr
MSN메신져 : dotnetlover@msn.com
E-mail : netlover@chol.net
|
제목 : Re: 글쎄요..
글쓴이: 손님(guest) 2003/06/02 19:12:07 조회수:1119 줄수:15 |
|
방법른을 XP+CBD+OOAD라고 말씀하셨는데 과연 그럴까 의문이네요..
interation, tdd, test first도 아니고, model driven에 검수가 뒷순이라..
xp의 요소에 해당하는 부분은 전혀 없는 듯 싶은데요..
제가 보기엔 비싸고 화려한 툴과 도구를 사용한 일반적인 프로젝트 진행으로 느껴집니다.
방법론을 사용한다, 장점을 조합했다 라는 느낌은 없구요..
uml distilled책과 rup책에서 발췌 부분부분조합한 듯한 느낌입니다.
틈이 커보이네요. 좀 더 정련할 필요가 있다고 느껴집니다.
|
제목 : Re: 의견 감사드립니다.
글쓴이: 김경태(tweni) 2003/06/03 02:57:02 조회수:1427 줄수:7 |
|
좋은 의견 감사드립니다.
TDD와 지속적인 통합과 배포에 관한 부분은 일부 글을 수정하였습니다.
8단계의 코딩전에 비지니스메소드에 대한 테스트를 먼저 작성 부분이 TDD의 반영이라고
봅니다. 8~13의 반복 부분이 지속적인 통합과 배포를 의미합니다.
그리고 UI프로토타이핑과 지속적인 배포가 고객의 빠른 피드백을 위한 것이라고 생각했습니다.
물런 저 정도로 몇자 끄적인 것으로 방법론을 논한다는 것 자체가 어불성설이라고 생각합니다.
선배님들의 고견을 듣고자하는 욕심이니 계속 좋은 의견 부탁드립니다.
|
제목 : Re: 뭐가 이리도 가식적인가
글쓴이: 손님(guest) 2003/08/20 11:17:43 조회수:1904 줄수:4 |
|
제가 보기에는 tweni 분은 만능 툴인 메모장을 이용하심이 적당하다 봅니다.
각 툴의 장단점을 모르고 한간에 떠돌아 다니는 용어에 맞춰서 조합하신듯 합니다.
그거 그렇게 해놓고 프로그래머들 닥달해서 만들어 주기를 바라십니까?
이래서 우리나라 개발자들이 대우를 못받음을 다시 한번 생각하게 만듭니다.
|
제목 : Re: 도대체 모가 그리 불만인지..
글쓴이: 손님(guest) 2003/08/21 23:59:15 조회수:1072 줄수:6 |
|
제가 보기에 그리 돈들일도 없군요. DB, 모델링 툴, WAS 정도만 정상구매하지 않을까
싶은데 대부분 그렇지 않나요? 요즘 프로젝트 진행하면서 충분히 고민해볼만한 내용
인것 같은데 가식적이라느니.. 무지하다느니.. 정말 내용있는 답글들은 이원영님과
몇몇 분들 글밖에 없군요. 정말 무지하고 가식적인 사람들은 자신의 입장에서 극히
냉소적인 답글을 달고 있는 사람들이 아닐까 합니다. 모.. 어쨋든 이 글도 그런 부류
이군요..
|
제목 : Re: 근데 CBD는 왜 들어갔쪄?
글쓴이: 손넘(guest) 2003/08/22 13:58:26 조회수:1259 줄수:6 |
|
CBD와 직접 관련된 산출물은 컴포넌트 명세서 하나밖에 없네여..
클래스 다이어그램은 OOAD에서도 나오는 산출물이고..
글구 시퀀스 다이어그램은 아예 빠져있군여..
CBD를 적용하셨다면 컴포넌트 식별에서 인터페이스 도출 -> 컴포넌트 설계 -> 컴포넌트 명세의
과정이 필요한데... 여기에서는 전혀 언급이 되어있지 않네여..
|
제목 : Re: 틀린말 아닌데요 뭐
글쓴이: 손님(guest) 2003/08/22 22:01:50 조회수:1243 줄수:18 |
|
뭐 좋은 툴과 방법론이야 고미할만하지만, 언급되어 있는 것은
그냥 책에서 긁고 들은것들 휘갈겨 적고 방법론이.. 툴이 어쩌구 하니까
아마 현업에서 관련 일 종사하시는 분은 화가 치솟을 일이니 그렇겠죠..
가령 html코딩하는 사람이 닷넷에 대해 몇몇이 하는 얘기를 듣고,
가자바는 사양길에 들어섰다. 자바는 않쓴다, 너무 느리다,
닷넷의 시대다..라고 하면, 현업에서 하는 사람의 입장에서야 속이 뒤틀일 일이겠죠.
CMM좀 알고, 관련 프로젝트를 해봤으면 언급된 것이 일단 아마추어 적이고,
앞뒤가 안맞은데다가 xp+cbd+ooad란 이상한 말이나,
쿼리xml?;; 이클릭스와 투게더의 중복 툴 사용에 srs란 것도 없죠..
cbd나 cmm을 조금이라도 아는 사람이 봤을 때.. 그냥 후후..하고
넘어 갈 수도 있겠지만, 뭐 그게 사람의 마음이 그렇겠습니까..
개발 순서도 전혀 안맞고, 이제 막 패턴이란 것에 흥미를 갖고 다 모아놓은 듯한..
원글 쓴 사람이 CMM이나 CBD에 관한 짧은 ppt라도 봤었으면 이런 글과
최상의 조합이란말이라던가 jstl대신 velocity라는 이상한 말 같은건 안썼을겁니다.
|
제목 : Re: 부실속의 노력들...
글쓴이: 손님(guest) 2003/08/25 01:56:21 조회수:1558 줄수:53 |
|
정말 모든분들이 열띠미 글들을 쓰시는 군요.
글 내용들로 보면 몇몇분은 SI업계에 있으면서 자기개발에
많은 시간도 투자 하는것 같구요..
하지만...서로 말은 좀 듣기 좋게좋게 하는것도
힘겨운 동종업계 사람들간의 예의 이겠죠...
프로젝트...툴,,,서버...
서버는 돈주고 산다 치는데..
방법론, 프로젝관리, 툴, 개발자 모두 단가 후려쳐서 부족하고 부실한게 우리네 실정
아닌가요?
방법론...자체방법론이라고 뻥친 돈안들인 RUP및 그 아류(대놓고 만든 마르미도 있으니...
거룩하신 교수양반들 및 그의 무리덜...)
툴...투게더...메모리릭이 생겨 나중에 뻣는거랑 매우 투박(프로젝트 문서 생성기로서만
좋군요...단시간에 많은양...
어차피 감리 하는넘덜 쥐뿔도 모르고 OO며 CBD들먹이는데 가서 DFD내노라는넘들인데여...
술 언제 사주나 목이나 빼고 기다리는..)
코드생성기..자체제작...
이클립스...공짜~
CVS...공짜~
토드...쿠뢕~
로즈...쿠뢕~
ER-Win...쿠뢕~
오피스...이쯤은 개나소나 라이센스있고...
개발자...턱없이 부족...(쿠뢕이 안되는 단점..)
.
.
.
입찰 유형 많지만...IT쪽 최저가 입찰만 하고...
계약관계가 갑을병정진사오미신유술해..마구마구 가지 쳐 나가니...
도무지 프로젝!!! 부실이 될래야 될수 밖에 없죠...
또 계약 관련 양반덜 아가씨덜 나오는 주점가서 절라 퍼 마셔야 하고...
이상황에 돈벌고 즐기는건 누구? 박스장사랑...사람장사...
이정도면 이공계 출신...여기서도 몸파는 쟁이 되는군요...
사농공상 이라고 했었나요...
사상공농 내지는 사상농공 쯤 아닐까요...요즘....
요즘 화물연대 파업하죠? 자기돈들여 차사서 대우 못받이 억울해 하는 그네들을 보면
자기살 깍고 몸팔아 가며 열띠미~~~전산 불모지에서 사투를 벌이는 꼬리아 IT인들의
순박함과 순진함이 보이네요...(이 참에 SI연대 파업해서 단가나 올릴까요? 요새 툭하면
배 째던데..ㅋㅋㅋ,,기왕이면 기생하는 사람 장사덜도 몰아내고...)
이런 마당에 서로 즐겁게 즐겁게 대화하죠~
그러면서 서로 보완해 나가는....
누구나 "틀린말" "맞는말" "모르는말" 많이 접하겠죠..
불특정 다수가 쓴글이니...당연한거죠...
여.유.있.게.삽.시.다.
|
제목 : Re: 몇몇 분들의 딴지를 이해 못하겠군요.
글쓴이: 손님(guest) 2003/10/02 01:11:10 조회수:1452 줄수:26 |
|
툴이 비싸서 어떻게 산다느니, 말도 않되는 방법론이라느니... 딴지를 거시는 분들 이해가
안되는군요.
방법론이야 회사의 업무성격과 자연스레 생겨난 프로세스를 따르게 마련이고, 저희 회사는
위에서 언급한 툴들을 거의다 씁니다.
그리고 회사에서 개발하는것이니 회사돈으로 사는것이지 개인이 사는것은 아니잖습니까?
프로세스, 방법론이라는게 책에 나왓다고, 다른이들이 좋다고 해서 되는것이 아니라
생각됩니다. 참고하고 자신의 회사에 맞는 것을 들이는것이라 생각합니다.
프로세스와 방법론이란 결국은 여러 사람이 일하는것 ㅤㄸㅒㅤ문에 생긴것 아닙니까?
이런저런것 아무리 얘기 해봤자 다른 개발자나 다른 그룹사람들이 안따라주면 아무
소용없지요.
그리고 여러툴들 회사에서 다 쓴다고 했는데, 개발자 혼자가 그 툴들을 다 쓰는 것이
아니죠. 자기가 쓸것만 쓰지만, 결국은 팀전체로 보면 다 쓰는것이고요. 예를 들어
MS Project같은거야 리드 개발자, 메니저, 또는 프로젝리더/메니저가 쓰지, 개발자가
쓸필요 없죠. (최소한 저희 회사에서는) 그리고 거꾸로, 그 사람들이 Resin이니
Eclipse니 Jbuilder니 쓸필요 없고요.
개인이 개발툴들을 구한다면 오픈소스 툴들도 많고, 어떻게든 구해서 쓰는것이고요,
혼자 집에서 개발한다면 굳이 방법론을 따져가면서 시간쓸 필요없을테고요.
처음 글의 취지는 "생각해보자" -- 다른 사람들의 의견을 듣고 싶은것이라 생각됩니다.
|
제목 : Re: 딴지는 좋은 현상입니다.
글쓴이: 손님(guest) 2003/10/04 23:08:15 조회수:1391 줄수:37 |
|
'생각해보자'란 글이라 해서 이견을 삭히기만 하면,
커뮤니케이션이 되지 않고 발전할 수 없습니다. 딴지는 좋은현상입니다.
(일반적인 프로젝트 커뮤니케이션을 저해하는 요소가 바로 이런 점이고,
(추후에 큰 문제를 가져오게 됩니다. 의견은 바로바로 표출을 해야죠..
"방법론과 툴의 최상의 조합", "xp+cbd+ooad'로 자신의 의견을 내세웠을 때,
그에 대한 이견을 가진 사람은 언제든 잘못된 점을 지적할 수 있고,
그것의 이유를 스스로 파악하여 정정토록 할 수 있습니다.
RUP+XP(궁극적으로 개발프로세스나 그밖의 활동들은 양극단입니다. )란 글이나,
방법론과는 관련없이 나열된 툴들은 분명 지적사항입니다.
RUP는 정의 정교화, 설계, 교차체크,
관리자체를 위한 문서와 관련팀간 협업의 룰을 지키는 것이 중요하고,
xp는 정반대로 가능한 최대한 공유,테스트,부가적인 작업최소화,문서 최소화입니다.
솔직히 개발프로세스나 방법론에 많은 지식을 가진 사람이 보았을 때는
많은 부분이 지적사항입니다. 툴을 보고 수긍을 하는 분이 계실지도 모르지만,
저는 전혀 수긍 안됩니다.
lotus notes가 협업툴이 될 수 있습니까?
단계별 산출물이 프로세스에 따라 진행되려면 workflow와 cm, 커뮤니케이션,
notification이 지원되는 툴이 없으면 안됩니다.
notes가 revision, 버젼, 라벨, cm, product와의 싱크를 주는지..
reqm은 뭐로 하는지, cbd를 적용한다 언급되어 있는데..
그렇다면, 해당 방법론은 뭔지, 시스템인터페이스, 비즈니스인터페이스,
인터페이스 인터랙션 다이어그램등의 산출물 없이 어떻게 컴포넌트스펙을
만들 수 있는지..
(엄청난 아키텍트가 아니고서야 어찌 컴포넌트 명세서를 한방에 그린단 말이요..;;
(한방에 그린다해도, 실제 연관성과 책임영역을 살펴보고, 변화관리를 위해서
(기타 산출물은 반드시 있어야 합니다..
너무나 틀린 것이 많아서 그나마 많은 분들이 아예 언급을 안할거라 생각합니다만,
여하튼 약간의 딴지로 자신의 글에 잘못된 부분이 있다는 걸 인식할 수 있다면,
그건 매우매우 발전적인 현상이고 좋은 글입니다..
여하튼 그렇습니다--;;
|
|
