소프트웨어는 무엇이라 말할 수 있는가 ?
소프트웨어란 프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체를 말한다. 소프트웨어에 프로그램 이외의 문서와 정보를 포함시키는 이유는 이들 모두가 소프트웨어 생산 행위의 결과이기 때문이다. 또한 프로그램은 프로그램 언어로 작성된 코드, 즉 정적인 표현을 의미하지만 소프트웨어는 프로그램이 컴퓨터를 가동시킨다는 동적인 의미도 포함하고 있다.
소프트웨어는 종이나 자기 디스크와 같은 유형의 매체에 저장되지만 개념적이고 무형적이다. 건축이나 자동차는 그 생산물을 보고 그 구조를 쉽게 파악할 수가 있으나 소프트웨어는 그 생산물의 구조가 코드 안에 숨어 있다. 이를 소프트웨어의 비가시성(invisibility) 이라고 한다. 소프트웨어의 다른 특성으로 복잡성(complexity)을 들 수 있다. 소프트웨어는 개발 과정이 복잡할 뿐만 아니라 전산화 대상 업무, 소프트웨어 시스템 자체가 난해하다. 소프트웨어는 수학이나 물리학에서 볼수 있는 규칙적이고 정형적인 구조가 없다. 요구나 환경의 변화에 따라 적절히 변형시킬 수 있는 특징(conformity)이 있다.
[Brooks, 1987]
소프트웨어를 정의하는 것은 어려운 일이지만 다음과 같은 특징을 가지고 있다고 본다.
- 소프트웨어는 부드럽다(soft). 적응력이 있으며 변경되기도 한다. 기계 엔지니어들이 설계하고 구현한 물리적 장치와는 매우 다르다.
- 광범위하게 적용될 수 있는 몇 가지 소프트웨어 규칙들이 있다. 화학 엔지니어와 전기 엔지니어들은 물리학과 화학의 기본 원칙을 따라 설계한다. 만약 소프트웨어 법칙이 있다면 아직 그것들을 발견하지 못한 것 같다. 컴퓨터 하드웨어 디자이너들은 정확한 공식을 사용하면 그들이 설계하는 칩에서 발생하는 열의 양을 계산할 수 있지만 소프트웨어 엔지니어들은 프로그램 사이즈 같은 제품 속성을 측정할 방법 조차도 합의에 이르지 못한다.
- 소프트웨어는 대량으로 생산되지 않는다. 자동차 같은 경우는 대량 생산이 가능하다. 액세서리는 변화시킬 수 있지만 기본 디자인을 반복적으로 사용한다. 소프트웨어는 그렇지 않다. OS 같은 특정 프로그램을 복사하여 수백만 사용자들에게 배포할 수는 있지만 단 하나의 실제 프로그램만 구현해야 한다. 제조 과정에는 카피를 만드는 것이 포함되지만 또 다른 동일 제품을 구현하는 것은 포함되지 않는다.
- 소프트웨어의 스펙은 지속적으로 변한다. 심지어 개발 사이클 후반에도 바뀔 수 있다. 절반 정도가 완성된 다리를 보고, "저기요, 내가 보기에 이 다리가 여기 보다는 저쪽에다 짓는 것이 나을 것 같은데요! " 라고 말하는 고객은 없을 것이다. 불행히도 그와 같은 요구 사항에 대한 변경 요청은 소프트웨어에는 끊임없이 발생한다.
소프트웨어 공학이란 ?
소프트웨어 공학이란 소프트웨어의 품질과 생산성을 향상시키기 위하여 사용자의 요구사항을 체계적으로 분석하여 설계 및 구현, 구현된 시스템의 시험 그리고 유지보수 및 폐기 시까지 소프트웨어 전수명주기 간에 걸쳐 이루어지는 체계적인 접근법을 말한다.
[Sommerville, in “Software Engineering”]
소프트웨어 엔지니어링은 신뢰성 있고 실제 머신에서도 효율적으로 작동하는 소프트웨어를 얻기 위해 올바른 엔지니어링 원칙을 확립하고 사용하는 것이다
[A Report on a Conference Sponsored by the NATO Science Committee. NATO 1969]
“The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software.
(소프트웨어의 개발, 운영 및 유지보수에 체계적이고, 훈련이 잘 된 정량적인 접근 방법을 적용하는 것으로,소프트웨어 개발및 관리를 공학적으로 접근하는 것을 말한다)”
[Definition by IEEE Computer Societ]
즉, 소프트웨어 공학이라는 것은 소프트웨어의 개발, 운영 및 유지 보수에 체계적이고, 훈련이 잘되고 정량적인 접근 방법을 적용하는 것을 의미하며, 이는 곧 소프트웨어에 공학적으로 접근하는 것을 말한다. 1968년10월 7일 ~ 11일 간 열린NATO 소프트웨어 엔지니어링 컨퍼런스에서 소프트웨어 위기(Software Crisis)라는 용어가 처음 언급된 이후 소프트웨어 개발에 공학적인 접근 방법의 필요성이 제기되면서 소프트웨어공학이라는 용어가 처음 소개되었으며 이후로 약간씩의 수정이 가해졌지만 소프트웨어공학의 정의는 대체로 유사한 내용을 담고 있다.
이러한 역사적 배경때문에 소프트웨어 공학의 출발은 상업용 어플리케이션이 아닌 국방 또는 정부 시스템을 개발하기 위한 요구사항들을 충족시키기 위하여 발전되었다. 실재로 소프트웨어 개발에서 체계적이고, 훈련되고, 정량화를 통한 측정 가능한 접근방식은 안정성이 최우선 가치가 되는 시스템 개발에서 아주 효과적인 것으로 증명되었다. (그러나 상업용 어플리케이션은 안정성이 최우선 되는 시스템과는 다르다.)
프트웨어 공학자가 알아야할 지식의 범위에 대한 표준 ISO/IEC 24773)
1. 소프트웨어 요구 사항
2. 소프트웨어 설계
3. 소프트웨어 구현
4. 소프트웨어 시험
5. 소프트웨어 유지 보수
6. 소프트웨어 형상 관리
7. 소프트웨어 공학 관리
8. 소프트웨어 공학 프로세스
9. 소프트웨어 공학 도구 및 방법
10. 소프트웨어 품질
그러나 소프트웨어 공학은 진실 또는 거짓의 개념이 아닌 유용한가/유용하지 않는가 의 개념이다. 유용한가의 여부는 해보지 않고서는 알수 없다. 무턱대로 비판없이 사용하는 것은 브룩스가 이야기한 은빛 총알과 다르지않다.
소프트웨어 라이프사이클(Software Life Cycle)
소프트웨어 라이프사이클이란 소프트웨어를 생산하기 위해 필요한 모든 활동들을 설명하는 모델을 의미한다. 소프트웨어를 개발하는 스타일이라고 할 수 있다. 비슷한 용어로 소프트웨어 프로세스(Software process), 소프트웨어 개발 프로세스(Software Development Process) 가 있다.
소프트웨어 개발의 각 단계와 절차는 어떤 입장(스타일)에서 소프트웨어를 만드느냐에 따라 조금씩 다르며, Waterfall, Spiral, Prototyping, Incremental, Evolutionary 등 여러가지 모델들이 있다.
유사한 용어인 소프트웨어 개발 방법론은 소프트웨어 공학의 원리를 소프트웨어 라이프 사이클에 적용한 개념으로 소프트웨어를 생산하기 위해 반복적으로 수행되는 작업활동, 절차, 산출물, 기법등을 체계적으로 정리한 것이다.
성공적인 소프트웨어 개발
성공적인 소프트웨어 개발은 비용, 납기, 품질 3가지 요소를 만족시킬수 있음을 의미한다.
IBM 386 메인 프레임의 아버지인 프레드 브룩스는 "No Silver Bullet" 에서 "하드웨어의 생산성과 같은 소프트웨어 개발의 생산성을 10배 향상시킬수 있는 마법과 같은 해결책은 없다" 라고 단언한다.
1994년 베일에 감추어진 SW 프로젝트의 성공과 실패에 대한 보고서로 많은 이들의 주목을 받았던Standish Group 의 정기적 보고서 통계 자료에 따르면 SW 프로젝트 성공률은 2009년을 제외하고 년간 1.7% 정도 성공률이 개선되는 것으로 보여진다. 이러한 경향이 계속된다면 2014년에는 SW 프로젝트 성공률은 50% 에 이를것으로 추정하고 있다.
| |
날짜 |
성공률 |
| First CHAOS 보고서 |
1994 |
16% |
| "Extreme CHAOS" |
2001 |
28% |
| CHAOS |
2003 |
31.1% |
| CHAOS |
2006 |
35% |
| CHAOS |
2009 |
32% |
성공적인 소프트웨어 개발을 위하여 방법론과 도구 관련하여 엄청난 투자가 이루어 졌다.
소프트웨어 구현
소프트웨어에서의 구현(Construction)이란 소프트웨어를 구성하는 프로그램과 관련 여러 산출물들을 만들기 위하여 필요한 실무적 활동(Activity)들을 의미한다.
보통 소프트웨어 구현은 아래의 그림이 보여주듯이 소프트웨어 라이프사이클 모델에서 상세설계 > 코딩 과 디버깅 > 시스템 테스트 단계(Phase) 를 구현이라고 표현 한다.
스티브 맥코넬은 그의 저서 Code Complete 2 에서 기존의 시각과는 조금 다르게 구현(Construction)을 라이프사이클 모델의 특정 단계(Phase)가 아닌 활동(Activity)으로 보고있다. 아래 그림은 소프트웨어 개발 활동들과 연관된 구현의 위치를 보여준다.
그림에서 구현의 대부분의 활동은 코드 작성과 디버깅이며, 상세설계, 구현 계획, 단위테스트, 통합, 통합 테스트와 같은 활동들도 수반한다.
또한 스티브 맥코넬은 소프트웨어 구현은 다음과 같은 이유에서 아주 중요하다고 말한다.
구현은 소프트웨어 개발에서 큰 비중을 차지한다.
구현은 소프트웨어 개발 과정에서 중심적인 활동이다.
구현에 집중함으로써, 프로그래머 개인의 생산성을 극대화할 수 있다.
구현의 결과물인 소스 코드만이 소프트웨어를 정확하게 설명한다.
구현은 반드시 수행되는 유일한 활동이다.
참고서적 및 자료
Steve McConnell, Code Complete 2
Steve McConnell, Professional software development
Guide to SoftWare Engineering Body Of Knowledge (SWEBOK 2004)
