소프트웨어

소프트웨어 생명주기 (소프트웨어 공학)

by

소프트웨어 생명주기 – Software Development Life Cycle

소프트웨어 공학의 목표는 “좋은 품질 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하는 것“이다. 즉 품질과 생산성이라는 명확한 두 가지 목표를 위하여 소프트웨어 공학은 지속 발전하고 있다. 이 발전의 중심에는 생명주기가 있다. 소프트웨어도 생명체처럼 자라고 성숙하고 쇠퇴하는 단계가 있다. 아무리 잘 개발된 소프트웨어라도 계속 변경되고 새로운 기능이 추가되며 사용되다가 어느 순간 소멸의 때를 맞이하게 된다. 

이러한 소프트웨어를 개발하는 과정은 생명주기 측면에서 보통 요구 분석, 설계, 구현, 테스트 및 설치 인도 등 과정을 거친다. 매 과정의 단계는 각기 범위와 해야 할 항목들이 정해져 있으며 하나의 단계가 마무리되면 다음 단계로 넘어가는 분명한 기준을 가지고 있다. 이런 일련의 프로세스들은 하나의 모형으로 제안되었으며 여러 모형이 SDLC로서 나와 있다. 

 




종류

SDLC는 소프트웨어 개발 프로세스를 가이드하는 구조화된 접근 방식으로서 여러 모델이 있으며 각각의 모델들은 모두 고유한 특징과 장단점을 가지고 있다. 

🚩 폭포수(Waterfall) 모델
: 순차적 프로세스를 따르고 각 단계가 완료되어야 다음 단계로 넘어갈 수 있는 선형적 접근법이다. SDLC의 원형에 가까우며 가장 오랜 역사를 지니고 있으며 산업계의 표준과도 같이 사용된다. 이 모델은 사용자의 의견이 상이하거나 중간 결과 점검에 따라 전 단계의 작업에 결함이 있다면 다시 수정하기 위해 전 단계로 돌아가는 피드백이 있다. 이 모델은 응용 분야가 단순하거나 잘 알고 있는 경우, 사용자 요구사항을 이미 잘 알고 있으며 연구 중심의 문제를 다루는 개발에 적합하다. 또한 생명주기 전반에 걸쳐 변경이나 진화가 예상되지 않는 비교적 위험이 적은 프로젝트에 알맞다.

  • 간단하고 이해하기 쉬움
  • 명확하고 잘 정의된 요구사항이 있는 소규모 프로젝트에 적합
  • 문서화가 잘되어 있어 유지 관리가 쉬움
  • 단계가 완료 시 변경 불가
  • 요구 사항 변경 직면 시 모델 적응력 저하
  • 긴 개발 주기로 인해 최종 사용자의 피드백 지연 가능

🚩 프로토타입(Prototyping) 모델
: 초기 요구 사항을 바탕으로 프로토타입을 개발하여 고객의 피드백을 받고 개선하는 과정을 계속 반복한다. 소프트웨어 개발은 전문가가 아닌 고객/발주자의 입장에서는 블랙박스에 가깝다. 이에 프로젝트의 실현 가능성은 보장받는 일이 묘연하다. 이런 경우 이 모델이 매우 적합할 수 있다. 프로토타이핑이란 시스템의 일부 혹은 시스템 모형이 될 만한 것을 만드는 과정이며 이를 시뮬레이션하여 사용자가 볼 수 있는 반응을 미리 보여준다.

  • 사용자 요구사항을 정확하게 파악하여 빨리 최적화 개발 가능
  • 고객은 완성 시스템을 사전에 확인하고 요구사항을 수정할 수 있음
  • SDLC 내 유지보수가 없어지고 개발 단계 내 유지보수 가능
  • 고객이 프로토타입을 최종 결과라고 믿고 곧 개발이 완료될 것이라는 오해 소지
  • 관리가 쉽지 않음
  • 완전한 문서화 어려움

🚩 나선형(Spiral) 모델
: 소프트웨어 개발 프로세스는 위험 관리 측면에서 매우 중요하다. 이는 개발 계획 및 요구사항 분석 후 각종 위험 요소와 차선책에 대해서 검토하는 단계를 필수로 갖는다. 이를 통해 프로젝트 초기 실패 요인과 위험 요소를 찾아내어 대비하는 것인데 이 모델은 이를 만족시킨다. 즉 반복과 폭포수 모델이 결합한 형태로 증분/진화모델과 함께 중요한 위치를 차지한다. 이 모델은 재정적 또는 기술적으로 위험 부담이 큰 경우 위험분석을 지속하면서 시스템을 발전시켜 나가는 데 적합하다. 

  • 개발 프로세스 전반에 걸쳐 위험 평가 및 관리 강조
  • 일련의 나선형으로 주기마다 소프트웨어를 반복적 구축
  • 개발 프로세스 초기에 위험 식별 및 완화 허용
  • 반복적 특성으로 인해 시간과 비용 과다 소요
  • 위험을 효과적으로 평가하고 관리하려면 숙련된 관리 필요
  • 익숙하지 않은 방법으로 적용에 어려움

🚩 V 모델
: 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 모델이다. 이는 코딩단계를 중심으로 각 단계가 V자 모양의 대칭구조를 이루고 있다. 모듈의 상세 설계를 단위 테스트 과정에서 검증하고 시스템 설계는 통합 테스트 단계에서, 사용자 요구사항은 시스템 테스트 단계에서 검증한다. 또한 이러한 검증을 통해 오류가 발견된다면 요구분석, 설계, 코딩 단계로 되돌아갈 수 있는 모델이다. 이 모델은 무엇보다도 높은 신뢰성이 필요한 의료, 제어 시스템이나 원전 시스템 등의 분야에 적합하다.

  • 각 단계에서 확인 및 확인의 중요성 강조
  • 각 단계에서 광범위한 테스트로 인해 고품질의 소프트웨어 보장
  • 요구 사항과 테스트 사례 간의 추적 가능성 설정
  • 요구 사항의 변화에 ​​적응력 저하
  • 각 단계에서 광범위한 테스트로 인한 시간 소요
  • 개발 중 제한된 고객 참여

🚩 Agile(애자일) 모델
: 소프트웨어 개발 프로세스를 일정 크기의 작은 단위로 개발, 검증 및 수정 과정을 여러 차례 반복적이고 점진적인 개발 접근 방식이다. 이를 통해 협업을 원활히 하고 업무의 적응성과 고객의 피드백에 중점을 둔다. 또한 스프린트라고 하는 잠재적인 출하 가능한 제품에 대한 증분 형태를 제공하는 방식을 지속 반복한다. 이 모델은 프로젝트에 대한 초기 비용 추정이 다소 어려워 대규모 프로젝트보다는 빠른 응답성을 요구하는 프로젝트에 요긴하게 적용할 수 있다.

  • 변화하는 요구 사항에 유연하고 적응력 높음
  • 빈번한 고객 피드백을 통해 지속적인 개선 가능
  • 정기적으로 작동하는 소프트웨어를 제공하여 귀중한 기능을 조기 배포 가능
  • 팀원 간의 강력한 협업과 의사소통 필요
  • 크고 복잡한 프로젝트를 관리하기 어려움
  • 지속적인 변화는 효과적으로 관리되지 않으면 범위 증가 가능성

 




인기

최근에 가장 많이 사용되는 SDLC는 애자일 모델이다. 애자일 방법론은 기존 전통적인 개발 방식과는 달리 민첩하게 변화에 대응할 수 있는 개발 방식을 제공하며 요구사항의 변화에 적절하게 대처할 수 있는 작은 주기로 개발을 진행한다. 이는 요구 사항을 빠르게 반영, 개발의 품질과 고객 만족도를 높일 수 있는 장점이 있어서 대부분의 소프트웨어 개발 프로젝트에서 애자일 방법론을 많이 적용하고 있다. 하지만 모델 하나만으로 모든 것을 만족할 수는 없다. 현장과 업계는 끊임없이 진화하고 있으며 지속해서 새로운 방법론이나 변형들이 등장하고 있다. 

이는 한 상황에 충족되지 않는 부분들을 서로 다른 모델들을 결합하여 진행할 수도 있다. 다시 말해 SDLC는 필수적 요소이기는 하나 프로젝트 규모, 복잡성 및 각종 특성 등에 따라 적절한 방법을 선택해야 한다. 이를 통해 빠른 개발 속도, 높은 사용자 만족 및 프로젝트 성공률을 보장받을 수 있는 모델들이 선호되고 있다. 근래에는 특히 개발조직뿐만 아니라 운영조직 간의 긴밀한 협업이나 AI 등을 활용한 자동화에도 중점을 두며 발전되어 나가고 있다. 다만 SDLC를 따르더라도 프로젝트의 위험을 최소화하기 위해 지속해서 프로젝트를 모니터링하고 이에 응당한 조처를 해야 한다.

소프트웨어 공학이란 (소프트웨어 공학)

by

“소프트웨어가 소수의 탁월한 능력을 갖춘 프로그래머에 의해 만들어지던 규모를 넘어서면서 소프트웨어 개발의 성패는 그 집단의 소프트웨어공학에 대한 숙달 정도에 크게 좌우된다.”

소프트웨어 공학의 첫 등장은 1968년 NATO가 지원한 한 콘퍼런스에서 시작되어 꽤 오랜 시간이 흘렀다. 이는 컴퓨터 소프트웨어 개발, 운영, 및 유지 보수에 관련된 체계적이고 표준화된 접근법에 대한 연구와 적용 기술로 이해된다. 이를 통해 고품질의 소프트웨어를 생산하고 시간과 비용을 최소화하며 고객과 사용자 요구사항을 충족하는 것이다.

그 결과물들은 공학적 원칙과 가이드라인으로 신뢰성, 확장성, 효율성, 보안성 및 사용성의 향상을 기대한다. 그래서 생명체와 같은 생명주기를 바탕으로 여러 기법, 도구 및 방법론이 고안되고 쓰이고 있다. 하지만 학문적 공학의 위치는 실제 현장에서 일하는 개발자들에게는 다소 생경하다. 이는 급변하는 IT 환경, 수요 대비 공급을 원활히 할 수 없는 교육적 생태계, 개발인력에 대한 대우 및 여러 편견 등으로 눈앞에 급한 불만 끄면 된다는 식의 대응에만 몰두한 결과이다.

현실은 현장에서 체득되는 지식도 있지만 학문적 고찰을 통한 지식과 지혜가 없이는 원하는 성과를 만들어낼 수 없다. 이는 수많은 무기를 지니고는 있으나 정작 아무런 전략, 전술도 세우지 않고 무작정 전장에 나서는 장수와 다를 바가 없다. 이제 개발자들은 모두 다시금 소프트웨어 공학을 찬찬히 살펴봐야 할 이유가 여기에 있다.

 

시작

무엇을 시작하든 제일 중요한 것은 “용어”를 제대로 알고 이해하는 것이다. 같은 용어라도 장소와 시간, 쓰임새 및 사람에 따라 모두 다를 수 있기 때문에 가장 먼저 다뤄야 할 용어를 정의하고 눈높이를 맞춰야 한다.

✔️ 프로그램
  : 프로그래밍 언어로 작성된 source code (정적)
✔️ 소프트웨어
  : 프로그램(source code)과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체, 즉 산출물, 사용자 매뉴얼 등 모든 것을 포함한 것 (동적)
✔️ 시스템
  : 필요한 기능을 실현하기 위해 관련 요소들을 어떠한 법칙에 따라 조합한 집합체

시스템은 모든 것은 포괄하며 소프트웨어도 시스템 내에서 다른 요소들과 상호 동작하는 하나의 시스템으로 볼 수 있다. 이러한 시스템의 기능과 성능이 잘 발휘되려면 시스템을 구성하는 모든 요소, 서브 시스템이 잘 작동되어야 한다. 즉, 제대로 만들어져야 하는데 소프트웨어의 경우 눈에 보이지 않는 비가시성과 복잡성을 모두 가지고 있다.

물리적인 하드웨어는 눈부시게 발전하면서 구체적인 성과들을 보여주는데 소프트웨어는 그렇지 못하다. 그러다 보니 소프트웨어를 등한시하게 되었으나 하드웨어를 작동시키는 것이 소프트웨어임을, 그 수요가 하드웨어 못지않게 폭발하면서 수많은 수요를 따라가지 못하게 되었고 여기서 소프트웨어 위기라는 것이 발생한다.

 




소프트웨어 위기

이러한 위기는 소프트웨어가 가지는 비가시성과 복잡성을 포함한 또 다른 특징이 있는데 첫 번째. 소프트웨어는 제조가 아닌 개발이라는 것이다. 제조와 개발이 비슷해 보이지만 가장 큰 차이는 제조는 능력별 결과물의 차이가 거의 없지만 개발은 개인의 능력이 매우 중요시되고 그 능력에 따라 결과물의 차이가 크게 난다는 것이다. 둘째. 소프트웨어는 소모되는 것이 아니라 품질이 떨어진다는 것이다. 소프트웨어는 소모성 상품이 아니다. 다만 계속 사용됨으로써 지속적인 사용자의 요구사항을 반영해야 하는데 이것이 여러 사유로 원활하지 않다면 품질은 자연히 떨어지게 되는 것이다. 셋째. 소프트웨어 관리 기술이 전체가 아닌 일부만 사용된다. 즉 개발 프로젝트에서 활용하는 관리지식체계(PMBOK)가 있는데 이를 필요한 부분만 일부 적용함으로써 그 효과를 제대로 보지 못하는 것이다.

✔️ 소프트웨어 위기
  : 소프트웨어 생산성에 대한 심각한 인식 

소프트웨어 위기는 생산성 외에도 많은 문제점을 가지고 있었다. 소프트웨어 개발 프로젝트는 예산을 초과하기 일쑤이고 개발일정의 지연도 반복되었다. 중요한 소프트웨어 개발에 필요한 개발자는 각자 가지고 있는 역량의 편차로 그 결과물의 수준을 예측 할 수가 없었으며 이는 결국 품질문제로 비화되었다. 다른 공산품과 달리 불량품에 대한 관리나 품질보증에 대한 정량적 개념이 부족했고 고객은 인도된 결과물을 신뢰할 수 없었다. 이러한 상황에서 문제를 재인식하고 타계하고자 하는 노력으로 공학적 접근이 대두되었다.

✔️ 공학
  : 기술적 문제를 발견하고 기술적 해결책을 제시하는 학문으로 과학적이고 잘 조직된 지식을 현실적인 문제해결에 체계적으로 적용하는 것

공학의 특성은 자연과학하고 다르며 여러 제약사항이 있는데 우선 기간이 정해져 있고 예산도 정해져 있다는 것이다. 이러한 조건 하에서는 결국 최종적으로 기간을 얼마나 단축하고 보다 적은 비용으로 가능할 수 있는가에 대한 과학적 해법을 마련하는 것이다. 이 관점에서 소프트웨어를 개발하는 과정에서, 공학에서 쓰이고 있는 원리들을 적용하여 개발을 해보겠다는 것이 소프트웨어 공학이라고 볼 수 있다. 보다 효율적인 개발을 통한 생산성을 높이고 품질 좋은 소프트웨어를 제작하려는 것이 소프트웨어 공학의 취지이자 목적이다.

 




소프트웨어와 공학

✔️ 소프트웨어 공학
  : 소프트웨어 개발에 필요한 이론이나 기술, 도구들에 관하여 연구하는 학문

다시 말해 소프트웨어 공학은 “품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 제대로 개발하는 것”을 말한다. 이러한 품질과 생산성 두마리 토끼를 모두 잡아야 하는 소프트웨어 공학은 방법, 도구, 프로세스 및 페러다임을 가지고 있다. 이는 소프트웨어 개발을 위해 생명주기를 통한 단계별 방법들을 연구하고 효율성과 효과성을 획득하기 위한 적절한 도구의 사용, 사용자 요구사항에 맞게 개발하기 위한 절차와 단계들, 그리고 상황에 맞게 적용가능하고 유연한 철학이 그것이다.

✔️ 방법: 어떤 결과를 생성하기 위해서 적용하는 기법과 절차
✔️ 도구: 더 좋은 방법으로 작업하기 위한 기기 또는 자동화된 시스템
✔️ 프로세스: 도구와 기법을 사용하여 작업하는 순서
✔️ 패러다임: 개발 스타일

이러한 4가지 요소를 바탕으로 소프트웨어는 유기체와 같은 생명주기를 갖는데 이는 계획 단계, 분석 단계, 설계 단계, 구현, 테스트, 유지 보수하는 과정으로 소프트웨어 개발 과정에서의 생산성을 향상시키고 품질 좋은 소프트웨어를 생산하여 고객을 만족시키려고 하는 최종적인 목표에 방점을 찍는다. 생명주기 내 각 단계는 일련의 활동을 포함하며 전체 소프트웨어 프로젝트에 대한 계획과 관리를 수행하고 개발 과정의 체계적인 구조화와 일정 관리를 지원한다.

✔️ 소프트웨어 생명주기(Software Development Life Cycle)
  : 소프트웨어 제품 개발에서 시작하여 최종 사용자에게 배포되고, 유지 보수 및 폐기될 때까지의 전 과정으로 일반적인 작업단계는 다음과 같다.

  – 요구분석: 고객과 사용자의 요구와 기대를 조사하여 프로젝트 목표를 정의
  – 설계: 소프트웨어 기능, 구조, 데이터 흐름, 인터페이스 등을 결정
  – 구현(개발): 설계 문서를 토대로 소프트웨어 코드 작성
  – 테스트: 생길 수 있는 오류와 결함을 찾아내고 수정
  – 배포: 개발된 소프트웨어를 최종 사용자에게 전달, 설치하여 사용할 수 있도록 함
  – 유지보수: 소프트웨어가 효율적으로 동작하도록 지속적으로 업데이트하고 개선
  – 폐기: 소프트웨어 수명이 끝난 경우, 안전하게 제거하고 관련 데이터와 자원을 처리

 

※ SWEBOK(Software Engineering Body of Knowledge)
  : ISO/IEC 국제 표준화 기구와 IEEE(Institute of Electrical and Electronics Engineers)가 승인, 지원하고 전 세계 소프트웨어 전문가들이 협력하여 개발한 소프트웨어 공학 관련 전문 지식의 체계적 모음으로 소프트웨어 공학자들이 필요로 하는 기본 원칙, 개념, 기술 및 실천 방법을 포괄한다. 여기서 다루는 다양한 주제와 영역은 SDLC의 여러 단계에 지침을 제공하고 이는 소프트웨어 개발 및 관리의 범위와 효율성을 높이는 데 도움이 되며 소프트웨어 개발자에게 필요한 기술, 능력 및 전문적 역량을 개발하는 데 중요한 역할을 한다.

※ PMBOK(Project Management Body of Knowledge)
  : 프로젝트관리협회(PMI:Project Management Institute)에서 개발한, 프로젝트 관리에 관한 전문 지식의 체계적 모음으로 ‘프로젝트관리지식체계’라고 하며 PM과 팀원들이 프로젝트를 계획, 실행, 통제하고 성과를 평가하는 데 필요한 일련의 표준 및 가이드라인을 제공한다. 이를 통해 프로젝트를 실천하면 프로젝트의 성공 가능성을 높이고 리스크를 최소화하는 데 도움을 준다.