프로젝트 썸네일형 리스트형 개발자의 취향 소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다. 이 경우 Architecture상의 심각한 문제점을 내포하게 된다. 제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다. Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에.. 더보기 개발자 100명을 더 투입한다면? 소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다. 그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다. 벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다. 그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까? 그 이유는 "스펙과 설계"에 있다.빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다. 그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다.. 더보기 스펙을 제대로 작성하는 것은 구식이다? '소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것을 판에 박힌 절차라고 생각하고 부정하기도 한다. 그런 주장을 하는 사람들은 이 방법은 Waterfall 방식으로 구닥다리이며 요즘은 Agile 등의 최신 방법으로 개발을 하기 때문에 과거처럼 스펙을 작성하지 않는다고 한다. 이렇게 주장하는 사람들에게 반문해보고 싶은 것이 있다. "스펙을 한번이라도 제대로 작성해 본적이 있는가?" 이런 생각을 하는 것 자체가 스펙을 제대로 이해하고 있지 못하다는 반증이다. 왜냐하면 스펙이 무엇인지 제대로 이해하고 있다면 이런 말이 나올 수가 없다. 지.. 더보기 설계가 필요할까? 최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음과 같은 궁금증을 가지고 있다. SW를 개발하는데 설계는 과연 필요할까? 설계서는 작성할 필요가 있을까? SW는 설계서 없이 개발하는 것이 더 빠르지 않나? 설계는 어떤 기법을 이용하는 것이 좋을까? 설계툴은 UML을 꼭 이용해야 하나? 일단, 설계를 하는 행위와 설계서를 작성하는 행위를 분리해서 생각하는 것이 좋다. 첫째, 우리는 설계서를 작성하든 하지 않든 "Hello world"를 제외하고는 설계 없이 개발하기 어렵다. 단지 단순한 것은 설계를 머리 속으로 할 뿐이다. 복잡하거나.. 더보기 Software Architect를 양성하는 나라 우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Architect 교육을 받아야 Archtect인가? 설계 방법론을 알아야 하는가? 설계 툴을 다룰 수 있어야 하는가? 이런 접근은 SW Architect에 대한 왜곡된 시각을 유발할 수 있다. SW Architect는 "고참 개발자"이다. 외국에서 SW Architect 양성 학원이 있나 물어보라. 개발자들이 스스로 SW Architect라고 강조하는지 알아봐라. 그냥 Software를 오래 개발하면서 경험이 쌓이고 고참 개발자가 되면 그냥 SW Architect인 것이다. 그런데 왜 우리나.. 더보기 프로토타입을 재활용하면 될까? 안될까? 며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다. 여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다. 여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다. 필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 .. 더보기 프로토타입이란? 프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다. by 다음 백과사전 (http://100.daum.net) 소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다. 이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다. 스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 .. 더보기 주석을 달기 어려운 이유 코딩을 하면서 주석을 적절히 잘 달아야 한다는데는 이견이 없을 것이다. 하지만 현실은 주석이 제대로 달린 코드를 찾아보기 어렵다. "주석이 제대로 달렸다"의 애매한 기준을 명확하게 정리해보면 다음과 같습니다. 과도한 주석은 나쁘다. 비용이 너무 많이 들어간다. 소스코드를 활용하고 유지보수하는데 어려움이 없어야 한다. 업데이트가 되어서 소스코드와 일치되어야 한다. 전체적으로 일관된 표준을 지켜야 한다. 주석하나 없이 깨끗한 소스코드나 있어도 소용없는 주석은 개발에 보통 어려움이 있는 것이 아니다. 약간의 시간을 투자해서 주석을 달게 되면 투자대비 몇배의 효과를 볼 수 있다. 그럼 가장 효과적으로 주석을 다는 방법에 대해서 알아보자. 회사의 주석 표준을 정한다. Doxygen이나 Javadoc등의 표준 주석.. 더보기 90%에서 끝나지 않는 프로젝트 Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다. 그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다. 경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다. 이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는.. 더보기 스펙에 있어서는 안될 표현들 필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다. 스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다. 사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다.. 더보기 이전 1 2 3 4 5 6 다음
