공룡과의 승부# 오늘날에도 소프트웨어 프로젝트들을 괴롭히는 난제들은 거의 편하지 않았다. 소프트웨어 프로젝트가 실패하는 가장 큰 요인은 요구사항의 문제(시스템을 잘못 정의하거나, 요구사항이 구체적인 구현을 하기에 모호하거나 너무 자주 바뀌어서 결국 시스템 디자인을 엉망으로 만들어 버리는 일들)과 관려이 있다고 하단다. 포트란이 개발되었을 때 사람들은 이제부터 컴퓨터 프로그래밍을 할 필요가 없을 것이라고 생각했다. 그러나 컴퓨터는 문제 정의를 자동화하는 것은 불가능하다. 문제를 정의하기 위해 필요한 것이 바로 프로그래밍이고, 이런 관점에서 본다면 프로그래밍은 절대로 사라지지 않을 것이다. 바보들의 황금# 소프트웨어 문제점들이 지속된 이유 중 하나는 일부 비효율적인 기법들이 겉으로 보기에는 매력적이라는 것이다. 소스코드를 만드는 일은 바위를 옮기는 것보다 훨씬 더 무형의 성격이기 때문에, 소프트웨어 프로젝트 초기에는 거의 긴박감을 느끼지 못한 채로 시간을낭비하다가 프로젝트를 완성해야 하는 기한이 다가오면 절망적 상태가 되는 “마지막 순간 증후군"에 걸리기 쉽다. 일단 작성하고 고쳐보는 개발문제점: 출발선에서 빨리 떠났다고 해서 결승선에 빨리 가까워진다는 것을 의미하지 않는다. 진보된 접근 방식을 사용하는 팀은 생산선을 높은 단계까지 끌어올리고 효율적으로 일을 끝마치도록 도와주는 프레임워크를 사용한다. 일단 작성하고 고쳐보는 프로젝트에서 시간이 지남에 따라 생산성이 떨어지는 양상을 보여준다. 개발 초반부터 프로젝트를 잘 운용했다면 구현하고 테스트, 디버깅에서 적은 예산을 소비한다. 일단 작성하고 고쳐보는 개발은 두 가지 측면에서 매력적이기 때문에 계속 쓰인다.실행 즉시 얼만큼 진척했는지 알 수 있다. 소프트웨어공학적 훈련을 요하지 않는다. 터무니없이 생산성을 높일 수 있다고 자랑하는 새로운 기술들과 몇몇 방법론들을 은빛 총알이라 부른다.은빛 총알은 프로젝트에 커다란 성공을 가져오리라 기대했지만, 오히려 그로 인해 실패한다. 몇몇 종류의 은빛 총알은 조직의 프로세스를 건성으로 개선하려고 할 때 비롯된다. 단순히 전문적인 용어라는 데 의의를 두고 적용하려 한다면 전혀 쓸모없게 된다. 소프트웨어는 소프트하지 않다.얼마나 조심스럽게 소프트웨어를 설계하든 간에 소프트웨어상에 더는 변형할 수 없는 부분이 생긴다. 유연성은 돈과 직결된다. 유연성을 제한하면 지금 당장의 비용을 절약할 수 있지만, 이후에 불균형적으로 더 많은 돈이 든다. 화물 숭배 소프트웨어공학# 프로세스 기반 개발: 잘 짜인 계획, 잘 정의된 프로세스, 효율적인 시간 사용, 오랜 경험을 통해 좋다고 판명돈 소프트웨어공학 기법들을 적용해 프로젝트를 성공시키는 것이다.대부분의 프로젝트가 성공하고, 회사는 지속적으로 자신의 역량을 향상한다. 책임 기반 개발: 해당 분야의 최고 인재를 고용한 다음, 그 사람에게 특정 프로젝트를 맡아주도록 요청하고, 프로젝트에게 전권을 위임한다.그 인재의 동기 부여 요소에서 잠재력을 유도해 낸다. 개발자들이 자발적으로 책임감을 느끼게 되기 때문에, 프로젝트가 기대 이상으로 성공할 확률이 높아진다. 프로세스를 중시한다고 사칭하는 조직의 경우 조직이 아닌 프로세스 자체를 위한 프로세스에 투자하는데, 이 과정에서 여러가지 잘못된 기법들을 만드는 경우가 많다.프로세스 사칭 조직은 소프트웨어 프로세스의 형태를 그 본질보다 더 중요하게 생각한다. 프로세스를 잘못 사용하면 오히려 개발자들의 사기가 떨어지고, 생산성도 바로 저하된다. 책임 사칭 조직은 결과(긴 근무시간)와 원인(높은 동기부여)을 혼동한다. 화물 숭배 소프트웨어 공학: 무엇이 진정 소프트웨어 프로젝트를 성공으로 이끄는가에 대한 통찰없이 형태만 흉내내는 것화울 숭배 소프트웨어 엔지니어는 그 방식이 비효율적이라도, 지금까지 자신들이 해온 방식으로 일하고 싶어한다. 프로세스 기반 조직에서도 특정 프로젝트에 대해 상당한 책임을 요구할 수 있고, 책임 기반 조직에서도 프로세스 소프트웨어공학 기법들을 효과적으로 적용할 수 있다.우리는 어떤 스타일을 선택했느냐가 중요한 것이 아니라 프로젝트를 수행하기 위해 어떤 교육, 훈련, 이핼르 동반하느냐를 심각하게 고려하여야 한다. 컴퓨터과학이 아닌 소프트웨어 공학# 프로그래밍을 예술의 관점에서 보는 사람들은 소프트웨어 개발의 심미적인 관점을 부각하고, 과학이 영감에 의한 창조적인 자유를 허용하지 않는다는 점을 비난한다. 프로그래밍을 과학의 관점에서 보는 사람들은 많은 소프트웨어들이 믿을 수 없을 만큼 많은 에러를 내포한다는 점을 지적하고, 소프트웨어를 개발할 때 지나친 창조적 자유는 소프트웨어를 믿을 수 없게 만드는 주원인이라고 비난한다. 두 관점은 불완전하고, 서로 잘못된 질문들을 던진다. 소프트웨어 개발은 예술이며 과학이다. 진정한 소프트웨어는 반드시 공학이어야 한다. 소프트웨어공학 대 컴퓨터과학과학자는 무엇이 진실인지, 만들어 놓은 가설을 어떻게 테스트할 수 있는지, 또 어떻게 하면 지식을 더 확장할 수 있는지를 배운다. 엔지니어는 무엇이 진실인지, 어떤 것이 쓸모가 있는지, 받아들인 지식을 사용하여 실무상의 문제를 어떻게 해결하는지에 대해 배운다. 대학교에서 컴퓨터과학 학위를 수여 받은 학생들 대부분이 공학이 아닌 컴퓨터 과학을 전공하였고, 통상 엔지니어가 하는 일을 공학적 마인드를 갖추지 않은 상태에서 바로 수행하여야 한다. 컴퓨터 과학을 전공한 인원이 생산 시설 시스템을 만들 때, 실제 현장에서 사용하기에 너무 빈약하고 불안한 코드를 만들어 내는 경우를 종종 볼 수 있다. 대부분의 교육 과정들은 컴퓨터 과학이지 소프트웨어공학이 아니다. 교육 인프라는 실제 현장이 요구하는 것보다 너무 뒤쳐져 있다. 소프트웨어공학이라는 단어 뒤에 숨겨진 의미공학이란 과학적으로 발전하고 수학적으로 잘 정의된 알고리즘실용적으로 디자인한 방법론, 이미 안전하다고 알려진 방법 등을 실세계에 적용해서 소프트웨어 제품과 서비스에 개발하는 것이다. 공학이 현실적이지 않다면 그것은 공학이 아니다. 소프트에어 프로젝트가 잘 굴러가려면, 아래에 나열된 제품 목표들을 만족하도록 관리해야 한다. 이 특성들의 우선순위를 명확히 정의한 후, 정의한 목표를 달성하기 위해 그에 맞는 특성을 우선 고려하여 제품을 제작해야 한다.최소한의 결함 최대한의 사용자 만족도 응답시간의 최소화 운영성 확장성 어떤 상황에도 다운되지 않을 것 정확한 결과 소프트웨어 프로젝트는 인건비가 프로젝트 비용의 대부분을 차지하기 때문에, 어떻게 하면 프로젝트 목표를 최적화할 것인가에도 초점을 둘 필요가 있다.짧은 일정 예측 가능한 납품기한 저비용 소규모 팀 프로젝트 도중 변화할 수 있는 유연성 지식체계# 한 분야의 전문가가 되기 위해서는 50,000여의 지식을 알아야 하고, 이 지식들은 기존의 지식에서 유도할 수 있는 것이 아니라 각각 따로 기억해야 하는 성질의 것이라고 한다. 소프트웨어 관련 지식은 지식체계로 정리하기에 너무도 불안정하다고 주장하는 사람도 있다. 본질과 우유본질적 속성: 어떤 개체를 바로 그 개체가 되게 하는 속성 우유적 속성: 우연적으로 일어난 속성 코딩과 테스팅은 소프트웨어 개발에서 단지 우유적 속성일 뿐이이다. 소프트웨어 개발의 본질은 서로 맞물려 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이다.우유적 속성들을 잠시 제외하고 본질적 속성만 고려하더라도, 기저에 깔린 실세계 컨셉들을 정의하고 그 정의가 잘못됐는지 확인하는 것은 여전히 어려운 일이다. 레거시 하드웨어나, 서드파티 컴포넌트, 법규, 비즈니스 룰, 데이터 포맷 등과 같은 복잡 다단한 실세계 제약사항에 일치하게 소프트웨어를 작성해야하는 것은 본질적인 어려움을 불러온다. 소프트웨어의 변화 가능성은 또 다른 본질적인 어려움을 불러온다. 소프트웨어의 비가시성 때문에 본질적 어렴움을 불러온다. 소프트웨어는 2차원이나 3차원 도형 같은 것으로 표현하기 힘들다. 앞으로의 대규모 생산성 증가는 소프트웨어의 본질적 어려움들(복잡성 ,일치성, 변화 가능성, 비가시성)을 해결할 때 이루어질 수 있다. 변하지 않는 핵심 잡기본질적 어려움을 극복하기 위해 필요한 짓힉은 바로 소프트웨어공학 지식체계의 핵심을 이루는 소프트웨어 공학원칙들이다. 1968년에 소프트웨어공학 지식체계의 양이 반으로 줄어드는 반감기가 10년이었고, 변하지 않는 핵심의 양은 상대적으로 적은 편이었다. 현재는 소프트웨어를 만들기 위해 필요한 지식 중 약 50%가 변하지 않는 것이라 추정할 수 있고, 이것은 반감기가 10년에서 30년으로 늘어났다는 것을 의미한다. 소프트웨어공학 지식체계소프트웨어공학 영역에 구성되는 지식은 반드시 일반적으로 받아들여지는 지식과 기법에 초점을 맞춰야한다. 소프트웨어 엔지니어가 반드시 갖추어야 할 능력을 구성하는 지식 영역소프트웨어 요구사항: 소프트웨어에서 구현될 기능들의 발견, 기록, 분석. 소프트웨어 설계: 아키텍처 레벨 또는 상세 레벨에서의 시스템 기본 구조 정의, 모듈별 분할, 모듈의 인터페이스 정의, 모듈 내의 알고리즘 선택. 소프트웨어 구축: 상세 설계, 코딩, 디버깅, 단위 테스팅, 테크니컬 리뷰, 성능 최적화를 포함하는 소프트웨어 구현. 소프트웨어 테스팅: 결점을 발견하고, 기능을 평가하기 위한 소프트웨어 실행과 관련한 모든 활동. 소프트웨어 유지보수: 소프트웨어, 관련 문서들의 개정 및 개선. 소프트웨어 형상 관리: 소스 코드, 컨텐츠(그래픽, 사운드, 텍스트,비디오), 요구사항, 설계, 테스트 자료, 추정, 게획, 사용자 설명 서 등의 소프트웨어 프로젝트에서 생성된 지적 재산에 대한 식별, 기록, 변경통제. 소프트웨어 품질: 소프트웨어가 기술적 요구사항을 만족한다는 확신을 부여하는 과정과 관련된 모든 활동들. 소프트웨어공학 관리: 소프트웨어 프로젝트 ,소프트웨어 작업, 또는 소프트웨어 조직의 계획 추정, 통제. 소프트웨어공학 툴과 방법론: CASE 도구, 재사용 코드 라이브러리, 정형 방법론 같은 도구와 방법론의 지원, 조직 내에서 도구와 방법론을 채택, 전파하는 기법도 포함. 소프트웨어공학 프로세스: 소프트웨어 개발 품질, 일정, 생산성 및 프로젝트와 제품의 특성을 향상 시키기 위한 관련 활동. 전문 소프트웨어 엔지니어라면 반드시 모든 영역에 대해 개론 정도의 지식은 가져야 하며, 대부분의 영역에 대해서는 충반한 지식을, 특정 영역에 대해서는 숙달되어야 한다. 노붐 오르가눔# 오늘날 평균적인 소프트웨어 개발은 일단 작성하고 고쳐보는 프로그래밍의 잔잔한 바다에 머물러 있다. 전문직의 정의고도의 학습과 훈련을 필요로 하는 것 시장에서 널리 용인되는 것보다 높은 수준의 윤리를 그 속에 담는 것 규약을 깨뜨리는 자에 대한 징계 시스템 개인이 벌어들이는 것에 대한 대한 사회적 책임의 강조와 영예롭게 훈육된 조직의 일원으로서의 의무 실제 입문에 앞서, 면허를 요구하는 것 소프트웨어공학 전문가를 찾아서최초 전문가 교육: 전문가가 되기를 원하는 사람은 일반적으로 스스로 선택한 대학에 입학함으로써 그들의 직업적 삶을 시작한다. 인가: 대학의 각 과정이 적절한 교육을 제공하는지 증명하는 인가를 받는다. 능력 개발: 대부분의 전문직은 단지 교육만으로 전문가의 능력을 갖추기 어렵다. 자격증: 교육과 훈련이 끝난 후, 전문가는 자신의 최소한 지식 수준에 도달했다는 것을 증명해 줄 하나 이상의 시험을 통과하여야 한다. 면허: 면허는 자격증과 유사하지만, 자발적으로 응시하는 대신 정부가 강제하는 것이 다르다. 연수 교육: 지속적으로 전문직 연수 교육을 함으로써 전문가의 지식과 기술을 유지하거나 향상시킨다. 전문가 모임/학회: 전문가들은 그 자신을 마음이 맞는 사람들끼리 모인 모임의 일부로 본다. 윤리 강령: 각각의 전문직은 전문직은 종사자가 책임감 있ㅇ게 행동하도록 하는 규범이 있다. 조직 인증 소프트웨어공학이 성숙 단계로 가기 위한 세 단계편견을 버려라: 소프트웨어 산업은 오랜 기간 동안 누구에게도 도움이 되지 않은 일단 작성하고 고쳐보는 개발의 악습을 내쫓아 버려야 한다. 조직적으로 관찰과 경험을 축적하라: 소수 조직만이 그들의 사업을 발전시켜 줄 유효한 데이터를 모으기 시작했다. 일부 조직은 극적인 결과를 얻었고 다른 조직들은 그 뒤를 따를 필요가 있다. 일단 작업을 중지하고 자신이 본 것을 개관한 후 초기 결론을 내린다. Please enable JavaScript to view the comments powered by Disqus. comments powered by