소프트웨어 개발기법

1．수명주기법

응용시스템이 기획, 개발, 운영되는 과정을 수명주기(life cycle)라 하는데 하나의 시스템은 초기 정보요구에서 설계·개발·운영을 거쳐 시스템의 폐기까지의 수명주기를 갖는다. 수명주기는 정의(definition), 구축(construction), 이행(implementation), 운영(operation)의 ４단계로 이루어지는 單線的 과정(iterative process)으로 보이지만 실제에서는 반복적 과정으로 이를 위해 각 단계에 관계되는 사람은 다음 단계에 대해서도 예견할 수 있어야 한다.
지금까지 수명주기의 단계들에 대해서는 학자마다 수많은 의견이 있었으며 (표 1)은 수명주기에 관한 주요 의견들을 정리한 것이다.

(표 1) 수명주기의 단계 비교

Biggs, Birk & Atkins

Davis & Olson

Teichroew

Allen & Lientz

CIBA-GEIGY社

시스템 계획

타당성 평가

필요의 인식

착수

사전타당성 조사

타당성 조사

타당성 조사

시스템 요구사항

정보분석

요구사항 기술

분석

설계

시스템 개발

시스템 설계

시스템 설계

설계

프로그램 개발

구축

구축

개발

절차 개발

시스템 이행

전환

시험

설치

설치

시스템 유지보수

운영 및 유지보수

운영

운영：유지보수

사후감사

수정

운영：기능제고

1. C.L. Biggs, E.G. Birks & W.Atkins, Managing the System Development Process, Englewood Cliffs, N.J.：Prentice-Hall, 1980.
2．G.B. Davis & M.H. Olson, Mangement Information System, NY：McGraw-Hill, 1974.
3．D. Teichroew, "Education Related to the Use of Computers in Organizations," Communications of the ACM, Vol.14, No.9, 1971, pp.513-18.
4．J. Allen & B.P. Lientz, Systems in Action, Santa Monica, Calif.：Goodyear Publishing Company, 1978.
5．E.R. McLean & J.V. Soden, eds., Strategic Planning for MIS, NY：Wiley-Interscience, 1977, pp.119-120.

⑴ 수명주기법의 각 단계

수명주기는 다양하게 논리적으로 연결된 활동으로 구성되며 정보시스템의 개발은 일련의 조직화된 활동이며 작은 업무로 세분될 수 있다. 이 때 각 활동은 정보분석자·시스템설계자·프로그래머·사용자 등에 의해 수행된다. 각 단계별로 개발과정에서 직면하게 되는 기본적인 문제는 한사람에서 다른 사람에게로 책임이 이전되는 활동간에 접속부분(interface)이 있을 경우이다. 이러한 문제해결을 위해 전반적인 프로젝트 관리자는 접속이 순탄하게 진행되고 정보가 가능한 문서화된 형태로 상호 교환되도록 조정할 필요가 있다. 따라서 경영자는 개발과정을 단계와 각 단계내의 활동으로 나눔으로써 개발과정의 통제, 적절한 전문실행자에게의 권한 이양, 필요한 반복과정의 최적 수행, 개발된 시스템의 계속적인 경제성 평가 등의 효익을 볼 수 있다. 컴퓨터에 기초한 정보시스템의 수명주기는 다음과 같다.

Ⅰ．정의단계
예비분석(preliminary anaysis), 타당성조사(feasibility study), 정보분석(information anaysis), 시스템설계(system design)
Ⅱ．구축단계
프로그래밍(programing), 절차개발(procedure development)
Ⅲ．이행단계
전환(conversion)
Ⅳ．운영단계
운영과 유지보수(operation & maintenance), 사후감사(post audit), 폐기(termination)

정보시스템의 수명주기는 학자들마다 여러가지로 설명되고 있으나 원칙에 있어서는 유사하며 각 단계의 주요 활동과 관련된 전형적인 비용지출과 시간요소는 다음과 같이 구성된다.

(표 2) 수명주기 관련활동의 상대적 비용 및 시간

단 계

비 용(%)

시 간(%)

예비분석
타당성조사
정보분석
시스템설계
구 축
이 행

2
1
10
8
40
39

5
5
15
10
35
30

수명주기의 각 단계 활동별로 주요 작업, 담당자, 다음 활동으로의 진행여부를 승인하는 권한의 소재, 각 활동의 문서화된 결과는 다음과 같으며 이상의 단계를 거쳐 완료된다.

(표 3) 수명주기의 각 단계별 주요활동

활 동

내 용

담당자

다음 활동의 승인

문서화

예비분석

-정보요구사항

-入力源결정

-목적 및 범위결정

-정보분석자

-사용자

-사용자

-관리자

-예비보고서

타당성조사

-경제적 타당성

-기술적 타당성

-조직적 타당성

-정보분석자

-사용자

-사용자

-관리자

-EDP 감사인

-타당성조사보고서

정보분석

-시스템명세

-프로젝트계획

-소요자원

-프로젝트예산

-정보분석자

-사용자

-사용자

-EDP 감사인

-시스템분석보고서

시스템설계

-프로그램명세

-파일명세

-전환작업명세

-경제적 타당성 검토

-절차개발명세

-시스템시험운용계획

-시스템설계자

-사용자

-시스템개발담당 관리자

-관리자

-EDP 감사인

-프로그램명세서

-절차명세서

프로그래밍

-프로그램작성

-프로그램시험 및 문 서화

-시스템 시험운용

-프로그래머

-선임프로그래머

-시스템설계자

-프로그램

-오퍼레이터, 입력요원 指針書

절차개발

-사용자, 입출력 담당자, 통제 및 업무담당자 등에 대한 지시

-전환절차

-사용자

-시스템설계자

-정보분석자

-사용자

-EDP 감사인

- 절차매뉴얼(manuals)

전환

-훈련

-신규파일작성

-병행처리

-세부조정

-수용여부시험

-上記 관련자

모두

-오퍼레이터

-입출력담당자

-사용자

-EDP 감사인

-전환작업기록

(log)

운영과 유지보수

-운용, 시스템수정

-上記 관련자

모두

-유지보수기록

사후감사

-목적, 비용, 효익검토

-운용특성평가

-사용자

-정보분석자

-EDP 감사인

-사용자

-관리자

-사후감사보고서

폐기

-폐기 및 신규대체에

관한 의사결정

-사용자

-정보분석자

-관리자

⑵ 수명주기법의 문제점

거래자료처리시스템(TPS)이나 정보보고시스템(IRS)과 같이 요구사항이 체계적이고 상세하게 규정되어야 하는 시스템의 경우에는 수명주기법의 방식이 적합한 대안이 될 수 있다. 그러나 수명주기법은 여러가지 제약점도 갖고 있는게 사실이다.

① 비용부담
수명주기법에는 각 단계에 걸쳐 문서를 작성하고 상세한 묘사를 위해 많은 시간과 비용이 수반된다.

② 개발에 장기간 소요
수명주기에 따라 시스템을 개발하고 최종적으로 설치하기 까지에는 장기간이 소요된다. 따라서 개발이 진행되는 도중에 최초의 요구사항이 변경되너 자원의 낭비를 초래하게 된다.

③ 수명주기의 비융통성
요구사항이 정확하게 묘사되지 못한 경우 수명주기의 각 단계는 반복될 수 있으나 이는 개발비용을 높이고 프로젝트 완성일을 지연시키는 결과를 초래한다.

④ 변화수용의 기피
개발비용과 기간의 문제때문에 수명주기법은 초기단계에 이용자의 요구사항을 확정시키려 한다. 그러나 개발초기에 사용자가 원하는 바를 스스로 밝힌다는 것은 쉬운 일이 아니다. 사용자는 프로그램이 개발되고 테스트되는 시점에 가서 제시한 요구사항이 잘못되어 있음을 뒤늦게 발견하는 것이 보통이다. 실제 직접 관찰하고 사용하기 전에 사용자가 원하는 바를 미리 상정하기란 매우 어려운 일이다.

⑤ 의사결정 위주의 시스템에는 부적합
의사결정 위주의 업무환경은 원래 비구조적이고 유동적이다. 이러한 경우 정보요구사항은 계속적으로 변화하기 마련이므로 의사결정자가 요구정보의 성격을 미리 규정하기란 불가능하다.

이와 같이 수명주기법의 장점인 정형화된 세부단계, 단계별 결과물 산출, 요구사항의 명세화 등은 경우에 따라서는 약점으로 나타나게 된다.

2．원형개발법

기존의 수명주기법은 문제의 성격이 비구조적이어서 사용자의 정보요구사항을 정확하게 기술하기가 곤란하였으며 시스템개발시 장기간이 소요되어 개발이 완료된 시점에서 환경의 변화로 요구사항이 변동될 가능성이 컸다. 또한 수명주기법의 일주기(one cycle)에는 장기간이 소요되기 때문에 DP부서에 개발업무가 정체되어 사용자들의 불만사항이 증폭되는 단점이 있다.
이러한 문제점을 해결하기 위해 제시된 방안이 원형개발법(prototyping method), 최종사용자 개발(end user development) 등이다. 특히 원형개발법은 개발과정에서 신속한 피드백으로 사용자의 요구사항을 반영하고 사용자의 참여에 의해 관심과 수용가능성 등을 제고시켜 궁긍적으로 시스템개발의 생산성을 향상시키려는 것이다.

⑴ 원형개발법의 특성

원형개발법에서는 사용자의 요구사항에 따라 １차의 단순화된 시스템(원형)이 설계·개발되어 사용자에게 제공된다. 사용자는 이를 시험운용하고 추가되어야 할 부분이나 개선되어야 할 부분을 지적하며 설계자는 이에 따라 새로운 원형을 설계·개발한다. 이러한 절차는 사용자가 만족할 때까지 계속되고 사용자가 만족을 표명하면 이를 기초로 실제 사용될 시스템(producton system)의 개발에 착수한다. 경우에 따라서는 최종 원형이 그대로 실제 운영시스템이 되기도 하고 혹은 상당부분 개정되기도 한다.
원형개발법은 비교적 단순한 경영관리시스템이나 의사결정지원시스템(DSS)의 개발에 사용되는 경향이 있다. 실제의 사례를 보아도 복잡한 경영관리시스템이나 거래자료처리시스템에 원형개발법을 사용하지는 않는다. 그것은 간략한 시스템분석과 소수 사용자와의 직접 접촉·운용 등 원형개발법의 특징을 볼 때 다수가 관여되거나 복잡한 시스템에는 부적절하기 때문이다. 또한 원형개발법의 원칙은 사용자가 제시한 요구사항이 시스템에 반영되었는지의 여부를 입력·출력·처리과정 각각의 단편적 측면이 아니라 실제상황에서 시스템의 운용을 통해 평가한다는 것이다.

⑵ 원형개발법의 한계점

원형개발법은 기존 시스템개발 방식에서 발생하는 문제점을 치유하기 위한 대안으로 제시된 것이다. 이는 사용자의 높은 관심과 참여를 통해 사후 원형에 기초한 실제 시스템의 수용가능성을 증대시켜 원하는 시스템을 완성할 가능성이 크며, 개발기간의 단축을 통한 비용절감과 사용자의 요구사항의 변화에 대처할 수 있게 된다. 특히 정교한 의사결정을 위한 시스템의 경우 유용하게 사용된다.
그러나 원형개발법도 다음과 같은 한계점을 안고 있다.

① 모든 종류의 시스템에 적합한 것은 아니다. 특히 일괄처리를 위한 대형시스템 또는 복잡한 연산 및 알고리듬(algorithm)에 의존하는 시스템의 경우에 원형개발법은 적합하지 않다.
② 시스템분석을 소홀히 취급할 가능성이 있다. 시스템개발에 있어 요구사항분석은 중요한 과정이나 원형개발법에서는 간이시스템의 신속한 개발요구때문에 기본적인 사용자의 요구도 파악하지 않은채 간이시스템을 개발하려는 경향이 있다.
③ 시스템테스트와 다큐멘테이션(documentation)이 불충분할 수 있다. 시스템테스트는 사용자에 의해 수행될 것이라는 점과 시스템오류가 있더라도 나중에 수정될 것이라는 점때문에 테스트가 건성으로 이루어질 수 있다. 또한 시스템이 계속적으로 변경됨에 따라 다큐멘테이션을 계속 수정·보완하기도 어려워진다.
④ 원형개발에 사용되는 개발도구도 한계점이 있다. 원형개발도구는 간이시스템을 신속하게 개발할 수 있게 하나 이러한 개발도구는 복잡하고 정교한 시스템개발에 부적절할 수 있다.

이러한 문제점에도 시스템규모가 작고 사용자 수가 제한되어 있을 때 또는 사용자와 시스템개발자가 개발할 시스템의 기능에 대해 확실한 지식이 없을 때 유용한 대안이다.

3．최종사용자 개발

최종사용자 개발은 사용자가 원하는 바를 스스로 파악할 수 있고 시스템이 너무 크거나 복잡하지 않을 경우 유용하다. 최종사용자에 의해 직접 설계·개발되므로 수명주기와 같은 과정을 거칠 필요가 전혀 없다. 또한 최근의 최종사용자는 예전보다 정보기술의 이해정도가 높기때문에 실행가능한 대안으로 성공가능성이 비교적 높다. 최종사용자 개발이라고 해서 시스템개발 모든 과정이 반드시 사용자만에 의해 개발됨을 뜻하는 것은 아니다. 최종사용자 개발의 구체적 수행방안은 시스템성격과 최종사용자의 자질에 따라 정보기술요원이 제공해 주는 도움의 종류가 결정된다.

4．고수준언어를 사용한 개발법

시스템을 개발하는데 있어 시스템의 기능명세서 또는 설계명세서를 반영하는 고수준언어(very high level language) 프로그램은 마치 컴파일러가 원시프로그램을 기계언어로 바꾸어 주는 것처럼 원하는 응용프로그램으로 변환될 수 있다. 이러한 고수준언어에 대한 궁극적인 목표는 自然語라고 할 수 있다. 그러나 현재는 주로 ４세대 언어가 사용되고 있기 때문에 이 방법은 ４세대기법(４generation technique)이라고도 한다.
고수준언어 사용기법은 소프트웨어의 기능이 간단하고 잘 이해될 수 있는 시스템에 주로 적용되며 사용자나 개발자로부터 적절한 母數(parameter)들을 받아들여 응용프로그램을 자동적으로 산출하고자 하는 것을 목적으로 한다. 이 방법을 사용하면 개발자 또는 프로그래머들이 표현이 쉽고 단순한 고수준언어를 이용하여 오류가 거의 없는 응용프로그램을 자동으로 생성할 수 잇다는 장점이 있으나 적용할 수 있는 대상시스템이 매우 제한적이라는 단점이 있다.

5．기존 소프트웨어를 활용하는 방법

일반적으로 하드웨어 설계자들은 먼저 유용한 칩()이 시장에서 판매되고 있는가를 조사한 후 그것들로부터 원하는 시스템을 구축한다. 이렇게 기본 모듈로부터 시스템을 설계하고 그것들을 연결하여 보다 큰 시스템을 구축하는 上向的(bottom-up) 접근법은 아무것도 없는 상태로부터 필요한 모듈을 설계해야 하는 어려움을 제거시켜 준다. 시스템의 개발에 있어서도 기존 소프트웨어 활용법(reusability approach)은 프로그래머가 가능한 많은 기존의 소프트웨어를 재사용하려고 시도하는 방법이기 때문에 상향적 접근방법을 취한다.
재사용가능성은 소프트웨어의 개발비용과 기간을 감소시키고 검사의 복잡성도 감소시킨다. 현재 개발되어 사용되고 있는 소프트웨어들은 거의 재사용가능성을 염두에 두지 않고 개발되었기 때문에 현재로서는 이 방식의 성과는 불투명하지만 소프트웨어개발에 드는 비용이 점차 증대됨에 따라 상대적으로 기존 소프트웨어 활용법의 중요성도 점차 커지는 추세에 있다.

6. Concurrent Engineering

기존의 시스템개발법은 각 개발단계가 직렬로 연결되고 복합적으로 걸쳐있어 예비분석에서 시스템개발 완료단계까지 장기간이 소요될 수 밖에 없다. 이러한 단점을 보완하기 위해서는 정보·통신기술을 이용하여 시스템개발을 병렬형태로 바꾸는 것이 요구된다. 또한 지금의 각 개발단계를 대폭 줄이고 개선하여 시스템개발이 신속하게 사안별(case by case)로 처리될 수 있도록 팀 워크(team work)를 구성하여야 한다. 병렬형태의 시스템개발에서 구성원들은 정보자원과 데이타 베이스(database)를 공유하여 보다 신속하고 낮은 비용으로 시스템을 개발할 수 있게 한다.
기존의 시스템개발법은 시스템개발 디자인을 예정된 작업순서에 의해 진행하고 후속과정에서 선행 작업이 잘못된 것을 판정한다. 그리고 그 작업을 담당했던 선행 작업자에게 되돌려 보내 다시 수정디자인을 하는 등의 방식으로 시스템을 반복적인 형태로 개선하고 개발한다.
반면에 병렬형태의 시스템개발법은 마케팅 담당자, 엔지니어, 생산관리자, 디자이너 등이 한 팀으로 구성되어 제품개발에 관한 전 과정을 동시에 진행하면서 시스템을 개발한다. 이와 같은 병렬방식은 시스템의 개발단계에서부터 사용자의 필요와 욕구를 충실하게 반영함은 물론 시스템개발 전 과정이 동시에 진행됨으로써 개발시간이 전통적 직렬방식보다 매우 단축된다.