1) 프로그램과 소프트웨어

프로그램은 논리적, 산술적 그리고 신속하게 처리되어야 할 기능들을 프로그래밍 언어로 구현한 명령어 및 관련 데이터의 집합이며, 소프트웨어는 작성된 프로그램을 상품화한 것이라 볼 수 있다. 그 밖의 소프트웨어의 특성을 살펴보면 다음과 같다.

• 소프트웨어의 유형성(有型性) - 소프트웨어는 논리적이며 보고 만질 수 없는 것이 아니라, 프로그램 코드를 인쇄시켜 볼 수도 있고 분석/설계 산출물로 가시화시킬 수 있으므로 유형이다.

• 소프트웨어의 동적행위성(動的行爲性) - 프로그램은 정적인 반면 소프트웨어는 정적이다. 프로그램이 하드웨어에 의해 수행되고 사용자와 상호작용할 때 비로소 소프트웨어가 된다.

• 소프트웨어의 상품성(商品性) - 개발된 프로그램은 제품에 불과하고 포장이 되고 사용자가 사용할 가치가 생기므로써 상품이된다.

• 소프트웨어의 견고성(堅固性) - 소프트웨어의 행위는 예측이 어렵고 수정이 용이하지 않다. 따라서 소프트웨어가 한번 구조성을 잃으면 유지보수는 점점 어려워지므로 '소프트'라는 단어 처럼 그리 유연하지 못하다는 것이다.

• 소프트웨어의 비마모성(非磨耗性) - 소프트웨어는 하드웨어와 달리 마모되지 않고 품질이 저하되는 특징이 있다.

2) 소프트웨어 개발의 특성

• 소프트웨어 개발의 비제조성 - 소프트웨어는 제조, 생산 되어지는 것이 아니라 개발되어진다. 하드웨어와 같이 소프트웨어도 좋은 설계를 바탕으로 만들어지지만 생상과정이 품질에 큰 영향을 주지는 않는 하드웨어에 비해 소프트웨어 개발과정은 그 과정 자체가 곧 품질로 연결된다.

• 소프트웨어 개발의 비조립성 - 하드웨어는 부품의 조립으로 이루어지는 반면 소프트웨어는 대부분의 경우에 개발에 머물뿐 조립의 단계는 아직 아니라는 것이다. 물론 최근에는 컴포넌트, 재사용 개념이 활발하게 적용되고 있다.

• 소프트웨어 개발의 비과학성 - 소프트웨어 개발 자체는 수학적이거나 과학적인 것이 아니라 조직, 인력, 시간, 비용, 절차 등이 중심이되는 관리기술이 중요하다.

3) 소프트웨어의 분류

• 정보처리 방법에 의한 분류 - 일괄처리 소프트웨어, 온라인 소프트웨어, 실시간 소프트웨어 등으로 분류된다.

• 사용자와 하드웨어 사이의 위치에 의한 분류 - 시스템 소프트웨어, 응용 소프트웨어 등으로 분류된다.

• 기능 수행방법에 의한 분류 - 계산 중심, 정보처리 중심, 절차 중심, 지식 기반 등으로 분류된다.

• 개발 목적에 의한 분류 - 프로토타입, 프로젝트, 패키지 등으로 분류된다.

• 획득 방법에 의한 분류 - 패키지, 주문형 소프트웨어 등으로 분류된다.

• 하드웨어 및 운영체제에 의한 분류 - 소프트웨어가 수행되는 하드웨어에 따라 메인프레임, 중형, PC, 워크스테이션 용(用)등으로 분류된다.

• 규모에 의한 분류 - 라인이나 기능점수 등 규모에 의해 분류된다.

• 최신 기술에 의한 분류 - 통신용, 프로그래밍 언어, 사용자 인터페이스, 워드프로세서, 거래처리, 분산처리, 인공지능, 개발지원도구, 멀티미디어 소프트웨어 등 다양하게 분류된다.

1) 이상과 현실의 차이

소프트웨어 엔지니어의 이상은 다음과 같다.
"사용자가 요구하는 양질의 소프트웨어를 계획된 시간에 맞추어 허용된 예산내에서 쌓아지는 기술을 최대한 활용해 가며 적절한 조직과 우수한 개발요원의 관리로 생산성 높게 개발에 임하고 상품화시키고 또한 유지보수한다"
그러나 현실은 냉혹하며 이상대로 실천되지 못한다. 물론 소프트웨어의 공학적 접근을 통해 어느 정도 해결가능하다. 소프트웨어에 공학적 접근이 가능한 이유는 다음과 같다.

• 단계적으로 추진된다.

• 각 단계마다 표준방법을 채택함으로써 효율향상이 가능하다.

• 결과의 미비함을 단계마다 검토, 보완시켜 나아감으로써 품질을 보증할 수 있다.

• 경험과 축적된 기술을 토대로 '어느 정도' 과학적 예측이 불가능하지 않다.

2) 소프트웨어공학의 역사

IBM 360/OS를 개발하던 1960년대 부터 소프트웨어 개발 예산과 기간의 장기화 사태의 심각성이 제기되기 시작
1968년 NATO회의에서 '소프트웨어공학'이라는 단어를 탄생시키면서 '소프트웨어 위기'를 인식 - Dijkstra가 GOTO文이 없어야 구조적인 프로그램 개발이 가능하다는 소위 GOTO 논쟁을 야기시키면서 소프트웨어 개발에 구조적이고 공학적인 접근방안의 시도에 관한 여론 확산
1970년대로 접어들면서 프로그래밍 자체의 문제점보다 분석, 설계 때의 결함이 더욱 심각하다는 품질과 생산성에 관련된 논문들이 발표되면서 구조적 프로그래밍에서 더 나아가 구조적 분석/설계의 개념이 각광을 받기 시작 - 소프트웨어 생명주기와 개발도구의 제안도 등장
1973년 미국 전기전자공학회(IEEE)의 소프트웨어 신뢰성과 공학기법 전반에 걸친 심포지움 및 NCC, IFIP, ICSE 등 국제적 학술대회에서 신기술 발표
1980년대 전반은 구조적 방법, 잭슨 방법, 워니어-오 방법 등 분석, 설계 방법들과 시험, 유지보수, 프로젝트 관리, 개발환경 등 전분야에 뚜렷한 기술 발전
1980년대 후반에는 객체지향 분석/설계/프로그래밍, 4GL, 소프트웨어 재사용, CASE, 피플웨어, 정보공학, 품질보증, 형상관리, 프로토타이핑 등의 기술적 진보
1990년대에는 객체지향, 정보공학, CASE 등의 본격적인 활용 단계 및 소프트웨어 성능공학과 재공학, 사용자 인터페이스의 중요성 등도 강조되기 시작함

3) 소프트웨어공학의 정의

최소의 경비로 품질높은 소프트웨어 상품의 개발, 유지보수 및 관리를 위한 모든 기법, 도구, 방법론의 총칭으로서 전산학, 경영학, 심리학을 토대로 한 종합학문이다.
소프트웨어공학의 체계를 그림으로 나타내보면 다음과 같다.

4) 소프트웨어 생명주기(SDLC)

정보시스템을 개발하는 절차, 혹은 개발단계의 반복현상을 시스템 개발주기(System Development Life Cycle)이라고 부른다. 소프트웨어공학에서는 소프트웨어를 하나의 생명체처럼 탄생에서 사망까지의 변환과정으로 보아 소프트웨어 생명주기라고 한다.
SDLC에서는 소프트웨어를 정보시스템의 일부로만 취급하며 시작과 끝을 중요시한다.

가. 전통적인 '폭포수' 모델(Waterfall Model)

전통적인 생명주기 모델은 단계적 생명주기(Phased Life-Cycle), 혹은 폭포수(Waterfall) 모델이라고도 한다.

• 계획 단계 - 사용자의 문제를 정의하고 전체 시스템이 갖추어야 할 기본기능과 성능요건을 파악하여, 이를 개발코자하는 소프트웨어의 기본요구로 전환시킨다.

• 분석 단계 - 사용자의 문제를 구체적으로 이해하고 소프트웨어가 담당해야 하는 정보영역을 정의한다. 의사소통 기술이 필수적이다.

• 설계 단계 - 소프트웨어의 구조와 그 성분을 명확하게 밝혀 구현을 준비하는 단계이다. 외부 시스템 및 사용자와의 인터페이스를 중시하는 외부설계와 시스템 내부를 설계하는 내부설계로 분류되기도 하고 전체적인 구조와 데이터 알고리즘을 설계하는 단계를 분리해 기본설계와 상세설계로 분류하기도 한다.

• 구현 단계 - 프로그래밍을 하는 단계이다. 각 모듈의 코딩과 디버깅이 이루어지고 그 결과를 검증하는 단위 시험 혹은 모듈 시험을 실시한다.

• 시험 단계 - 개발된 모듈을 통합시키며 시험하는 통합시험, 완성된 시스템으로서의 요구사항을 완벽히 반영시켰는가를 알아보는 시스템 시험, 그리고 사용자가 직접 자신의 사용 현장에서 검증해 보는 인수 시험 등이 있다.

• 운영 및 유지보수 단계 - 소프트웨어를 직접 이용하고 이용상에 나타나는 문제점들을 수정하거나 새로운 기능을 추가해 보다 유용한 소프트웨어로 발전시키는 단계이다.