본문 바로가기

전체 글314

소프트웨어 공학의 오해와 진실(1) - 문서화 산출물 양식 산출물 표준 양식이란 것은 없다 글쓴이 : 민상윤 이글은 필자가 여기저기 강단에 설때마다 자주 언급했던 내용입니다…혹시 필자의 강의를 들은분들은 복습하는 개념에서 읽어 주기를 바랍니다. 일반인들에게 소프트웨어 공학을 이야기하면 대뜸 나오는 반응이 산출물 문서화에 대한 오버헤드이다. 소프트웨어 공학하면 국내 대부분 개발자들은 문서화에 대한 불평부터 토를 달기 시작한다. 도데체 우리나라 왜 이런 것일까? 전세계적인 다양한 통계를 보더라도 국내 소프트웨어 공학 및 소프트웨어 개발 수준은 선진국에 비하여 짧게는 10년에서 길게는 20년까지 뒷쳐저 있다는 것이 일반적인 의견이다. 그중에서 가장 잘 안되는 것이 산출물에 대한 문서화이다. 필자는 지난 10여년간의 컨설팅을 하면서 문서화에 대한 많은 문제점들을 보아왔.. 2009. 7. 25.
요구사항 없이 개발하기 글쓴이: 양승익 “요구사항이 없이 개발이 가능할까요?” 무엇을 개발하라는 요구사항 문서하나 없이 개발을 한다는 자체가 논리적으로는 맞지 않지만 현실은 가능했습니다. 실제 컨설팅을 하러 많은 조직을 가보면 그 흔한 SRS(SW Requirements Specification)문서 하나 없이도 개발 잘 하는 조직이 얼마든지 많이 있습니다. 하지만, 요구사항이 제대로 정의되지 않을 때 사용자가 요구한 내용을 제대로 구현했는지에 대한 검증을 어떻게 할 것이며, 명확하게 정의가 안된 요구사항에서 문제가 발생되었을 때 개발을 다시 해야하는 재작업은 충분히 예상되는 일입니다. 저는 이러한 현상을 우리나라 IT 조직이 가지고 있는 ”코딩 중심”의 개발 조직의 병폐라고 생각합니다. 코딩 중심의 개발 조직에서는.. 1. .. 2009. 7. 25.
요구사항 작성하기 - First Breadth and Evolutionary Depth Approach 글쓴이: 양승익 오늘은 지난 블로그에 언급했던 요구사항을 어떻게 기술하는 것이 좋을지에 대한 글을 쓰려고 합니다. 사실, 요구사항을 어떻게 써야하는지 많은 고민들이 있어왔습니다. 하지만, 대부분이 목차를 어떻게 작성할지에 대한 고민이 대부분이었고 정작 요구사항의 내부 컨텐츠를 어떻게 작성하는지를 가이드하는 것은 그렇게 많아 보이지 않습니다. IEEE에서 제공하는 가이드처럼 목차는 얼마든지 이상적으로 만들 수 있지만 중요한 것은 목차 내부의 컨텐츠를 어떻게 잘 쓰는 것이 요구사항을 작성하는 핵심 Key입니다. 오늘은 상세하게 요구사항을 작성하는 기법적인 측면보다 전반적으로 요구사항을 작성하는 방향성에 대해 주로 말하려고 합니다. 요구사항을 잘 쓰기 위해서는 제가 생각하는 접근법은 “First Breadth.. 2009. 7. 25.
Agile과 CMMI 화해하기 (1) 글쓴이 : 양승익 Agile과 CMMI 패러다임은 2000년대 초반부터 지금까지 각자 고유의 영역에서 나름대로 발전을 하고 있습니다. 이 두가지 패러다임은 서로의 대칭선 상에 위치하면서 때로는 상대 진영의 단점을 통해 자신의 우수성을 홍보하기도 합니다. 즉, “권위적이고 관료적이고 heavy한 프로세스는 CMMI, 반면에 lightweight하고 문서 작성이 필요없는 Agile 프로세스..” 라는 얘기를 종종 볼 수 있죠. 갑자기 출처는 정확히 생각나지는 않지만 다음과 같은 말이 생각납니다. ” 서로 반대되는 두 가지는 한 쪽이 존재하기 때문에 다른 한쪽 역시 존재한다” 즉, 동전의 앞면이 있어서 뒷면이 존재하고, 여당이 있기에 야당이 있고, 선이 있기에 악이 있다는 말입니다. Agile이 발전할 수 있.. 2009. 7. 25.

티스토리툴바