겐도사마의 재림

회사명 : 막벌자 회사의 Vision : 기업도덕이고 뭐고 없이 순수하게 돈만을 추구하자. 프로젝트명 : 100원 포도주 Vision Statement : 초초초초 저가원가의 포도주를 만들어 대량 판매하자. Business Opportunity 지금 포도주를 마시고 싶어하는 사람은 많지만 가격 문제로 쉽게 접근을 하지 못하고 있다. 만약 100원에 공급할 수 있다면 최소 100만명 이상 사람들의 시장을 차지할 수 있다. 사장 겸 기획자 왈 "천원도 아닌, 오백원도 아닌, 100원짜리면 애들도 사먹을 수 있는 돈이다. 포도주 하면 많은 사람들이 즐겨보려 하는 아이템 아닌가. 잠재 수요 충분하고 불만 붙여주면 대량으로 팔릴것이다. 100원이라해도 원가를 더욱 낮추고 양으로 승부를 보면 엄청난 돈을 벌 수 있..

Steve McConnel이라고 한다면 , , , 의 저자이자 그가 주장했던 소프트웨어 개발 방법론은 Artifact(산출물) 많기로 유명하다. Joel Spolsky도 자신의 저서 에서 그것을 다시 언급했다. McConnel의, 혹은 그가 다닌 회사인 CxOne에서 제안하는 Artifact의 가지수는 엄청나지만 사실 CxOne에서 혹은 책이나 문서를 통해 제시되는 가이드에 보면 중요하다고 생각되는 부분은 따로 문서를 별도로 작성해야 겠지만 반대로 쓸모없는 것들은 상위 문서에 "필요 없는 것 같애"라고 적고 생략해 버리라도고 한다. 하지만 일부 몇가지 항목 들은 필수적인 것들이라고 한다. 이보다 이전의 개발방법론에서도 존재했었지만 McConnel이든 아니면 이후의 개발방법론들은 그것들을 좀더 명확하게 정..

http://agile.egloos.com/2970034 테스팅에 관련된 글중 최근에 많이 회자되었던 글입니다. 두시간 후에 수술에 사용될 프로그램에 대한 테스트 플랜을 작성하라는 내용입니다. 수술 대상은 바로 자신입니다. 안정성을 검토하는 테스트 자체에 대한 검증문제죠. 만약 저에게 이런 문제가 주어진다면 저는 이렇게 답할지 모릅니다. 그냥 두시간 남은 인생 밖에서 놀다 오렵니다.너무 무책임한가요? 제가 소프트웨어를 개발함에 가지는 기초적인 관념중 하나는 "결점 허용 모델"입니다. 이 모델을 가지게 된 것은 몇년전의 경험때문이기도 합니다. 대부분의 포인터 어레이가 null로 초기화 되어야 하는데 어느날 갑자기 동작중에 잘못된 메모리 참조를 일으키는 것이었습니다. 포인터 값도 이상한 것이었습니다. 몇시간..

Mozilla rebuts Firefox 2 bug reports 아이들이 잘못을 저지르곤 부모에게 비오는날 먼지날리게 맞으면서 하는 말이 "다시는 안그럴께요"일 것이다. 물론 대부분의 경우 몇번 더 저지르고는 그것을 고치기 전에 어른이 되어버려 할 필요가 없어지는게 대부분이긴 하다. 어플리케이션의 메이저 버전업의 초기에 보는 현상이 이와 비슷하다. 직전 버전의 마이너 업데이트에서 실컷 고쳤던 버그가 다시 나타나곤 한다. 비단 FF뿐만이 아니라 MS의 윈도우에서도 무려 몇년의 간격을 두고 똑같은 버그가 발견되고 Critical Security Patch라는 이름의 프로그램이 전송된다. 최근의 해커들은 메이저 업때는 기존 버전의 모든 해킹 방법들을 다시 테스트 해 본다. QA 담당자들은 왜 안해보나 몰라 ..

책이 나온 사실은 많이들 아실테고;;; http://tapm.blogspot.com 조금씩 글이 올라오는데 한번쯤 둘러보실만한 블로그일 것입니다. 피드 등록 추천~~ http://tapm.blogspot.com/2006/07/2.html SE에서의 일정과 마켓팅에서의 일정은 접근 자체가 틀리다 보니 이런 것 같습니다. 뭐 관리에서의 일정도 다를테구요. 지정된 시간내에 혹은 짧은 기간(경비와 연관되니)내에 만들지 않으면 소용이 없다고 하지만 LNG선을 만드는 것을 전세계 인구가 달려든다고 해도 하루만에 만들수는 없는 거죠. 더 재미있는 것은 전세계 인구가 달려 들었다간 지구가 멸망하기 전에 만들 수 있으려나 모르겠습니다. 기획자에게 있어 소프트웨어의 이런 특성은 상당히 기분이 나빠서 묵살해 버립니다. 정확..

jrogue님의 글 : [일상다반사] 참고문헌에 얽힌 묘한 습관 이 책이 번역되신답니다. +.+ 전에 원서로 사서 아직도 이해하는데 어려움을 격고 있는데 번역본이 나온다면 당장 질러야 겠군요. 더불어 당분간 이책 Pause ㄱ-(역시 원서는 이해가 느려서 원 ㅠ.ㅠ) 관리라는 것은 정말 예술(Art)입니다. 쉽지도 않고 끊임없이 새로운 것들이 나오고 개개인이나 개별 상황에 따라 다르고. 부디 멋있는 번역 본이 나오길 +.+ PS. 그러고보니 jrogue님의 블로그가 블로그스팟이군요. 많은 태터 블로그에 트랙백이 안될 것 같네요.@.@;

수퍼히어로 개발자에 대한 관점 from Iguacu MS의 Dev2006에서 소만사 김대환 사장의 "람보" 이야기(ZDNET 기사 참고) 이후 논의되는 글에 나도 참여해 볼까 한다. 람보프로그래머 "람보프로그래머"라 한다면 혼자서 수백만 라인의 코드를 생성하고 관리 가능한 개발자를 지칭할 것이다. 만약 이런 식으로 개발을 하겠다라고 한다면 당장 말려야 할 것이다. 람보가 영화속에서만 존재하는 인물이듯 이런 프로그래머는 이세상에 없다. 마치 m60을 양손에 한자루씩 쥐고 쏠 수 없는 것과 마찬가지이다.(물리시간에 많이 풀어봤을지 모른다. 사람이 그렇게 쏘면 어떤 일이 벌어지는지;;;) 또한 람보는 지상전투에는 전문가일지 모르나 전투기를 조정할 수 없고 절단부상자의 수술을 할 수도 없다. 한명이 전쟁 전체를..

What is "Project VISION" 이번에 새로운 프로젝트를 하면서 프로젝트의 범위를 정하기도 힘들고 해서 기존에 만들어 두었던 Project Template를 꺼내 들었습니다. Contrux사의 CxOne을 기본으로 만든 것입니다. Contrux사의 핵심인이 바로 Steve McConnel이고 Rapid Development나 Code Complete의 저자기도 하죠. 더불어 조엘이 너무 정형화 되어 문제의 소지가 있다라고 지적된 것이기도 합니다. 저로서는 프로젝트가 너무 막연한 상태에서 범위 설정도 어려운 상황이라 Project Charter를 사용하기로 하였습니다. 개발지원사이트에 wiki(공동으로 편집 가능한 웹페이지라 보시면 되겠습니다.)가 깔려 있어 Project Charter의 Te..

보안에서는 시스템의 가장 취약한 부분이 시스템 전체의 보안성을 결정한다라고 하는데 이와 비슷한 현상이 코딩에도 일어나는 것 같다. 지아무리 아키텍쳐가 잘하고 PM, PL, 그리고 각 파트의 장들이 잘 해낸다 하더라고 실제의 말단 코드를 작성하는 코더에게 문제가 있다면 그 시스템은 결국 무너져 내린다. 이런 부분을 보완하기 위해서 테스팅이라던가 코드 리뷰등의 방법을 동원하지만 너무나 뛰어난 서포트 시스템에 의해 오히려 초보 코더의 실수는 숨겨져 버릴 가능성이 높아진다. Bug에 대해 소위 빈도와 중요도에 따라 분류하고 적절히 대처한다 하더라도 고객의 클레임에 날밤 까는건 결국 일주일이나 한달에 한번 발생하는 시덥잖은 오동작일 것이고 찾아보면 말단 코더의 오타일 경우가 많다는 것이 문제이다. 그럼 1년차 신..

MS site Link The Trustworthy Computing Security Development Lifecycle 보안에 대해 곤욕을 치르고 있는 MS. 드디어 이러 해괴 망칙한 것까지 만들어 내다. -0- 전통적인 관점에서 보자면 Security Vulerability는 일종의 버그라 할 수 있다. 그것이 특정 컨디션(케이스)이 되면 오동작을 하고 프로그램이 종료되거나 임의코드 수행이나 정의된 동작이 아닌 다른 동작을 수행하는 것이다. 그래서 이를 Testing이나 Verification의 차원에서 점검하는 것이 일반적이었다. 하지만 SDL에서는 Security Requirement라는 것을 정의를 하고 이에 따른 개발 Process를 거치도록 한것이다. 그리고 Requirement나 Des..