소프트웨어 공학에서 요구분석은 소프트웨어 개발 프로세스의 초기 단계에서 매우 중요하고 가장 어려운 부분 중 하나다. 그 이유는 요구분석 외 다른 작업은 만약 잘못되었을 때 비교적 적은 비용으로 오류를 수정, 보완할 수 있으나 요구분석의 경우에는 처음부터 다시 개발해야 하는 비용이 증가하고 개발기간은 늘며 소프트웨어 품질 저하의 직접적 원인이 되기 때문이다. 요구분석은 사용자 및 이해관계자와의 의사소통을 통해 시스템의 기능, 성능, 제약조건 등을 명확하게 이해하고 시스템이 충족해야 할 기능적 요소와 비기능적 요소를 파악, 정제하여 적절한 시스템 설계와 구현 기초를 다지는 과정이다. 이는 프로젝트의 성패를 좌우하는 결정적 요소로, 보다 정확하고 완전한 요구사항을 수집하고 분석하는 과정을 포함하며 이를 통해 시스템의 목표와 범위를 확실히 하여 성공적인 소프트웨어 개발을 돕는다.

다시 말해 요구분석은 다음과 같은 이유로 소프트웨어 개발에서 매우 중요하며

• 소프트웨어 시스템의 개발, 구현, 테스트, 유지보수의 모든 단계에서 요구사항 참조
• 소프트웨어 시스템의 개발 비용 절감 가능
• 소프트웨어 시스템의 개발 기간 단축 가능
• 소프트웨어 시스템의 품질 향상 가능

요구분석을 통해 얻을 수 있는 이점은 다음과 같다.

• 소프트웨어 시스템 개발 목표 및 범위 명확화
• 소프트웨어 시스템 기능/비기능 요구사항 명확화
• 소프트웨어 시스템 테스트 사항 명확화
• 소프트웨어 시스템 개발, 테스트, 유지보수에 드는 시간 및 비용 절약
• 소프트웨어 시스템 성공적인 개발 보장

이러한 요구분석의 과정은 크게 요구, 요구추출 및 분석, 구조적 분석, 요구분석 명세로 구분할 수 있다. 이 단계들을 철저히 수행하여 프로젝트 초기부터 요구사항에 대한 명확한 이해와 관리가 가능하고 개발 프로세스의 효율성과 최종 제품의 품질 향상에 기여하여 소프트웨어 시스템의 성공적 개발을 보장받는다. 

 

요구(Requirement)

요구는 시스템이 외형적으로 나타내는 기능, 성능, 품질, 인터페이스, 환경, 보안, 유지보수, 제약사항 등의 동작을 말한다. 요구는 사용자, 고객, 시스템 이해관계자들로부터 도출되는데 명시적이고 모호하지 않으며 변하지 않는 특성을 가져야 한다. 이를 통해 소프트웨어 개발팀은 프로젝트의 목표와 범위를 파악할 수 있다. 이런 요구는 기능적 요구와 비기능적 요구로 크게 구분되며 기능적 요구는 시스템의 기능이나 동작에 관련된 것이고 비기능적 요구는 성능, 안전성, 보안 등과 같은 품질 속성에 관련된 것이다.

• 기능적 요구: 시스템이 수행해야 할 특정 작업이나 기능에 대한 요구로 웹 서비스의 경우 사용자 등록, 로그인, 상품 검색 등의 기능을 말함
  • 시스템이 무엇을 언제 그 일을 하는가?
  • 시스템 운영 시 여러 다른 모드가 존재하는가?
  • 시스템이 언제 어떻게 변경 또는 확장되는가?
• 비기능적 요구: 시스템이 충족시켜야 할 성능, 안정성, 사용성, 유지보수성 등과 같은 운영적, 환경적 제약 조건들로 응답 시간, 동시 접속자 수, 확장성 등이 포함
  • 시스템의 속도, 반응시간, 처리율, 처리자료 크기
  • 시스템 가동 평균 시간, 중단 후 복구시간
  • 시스템 설계변경 용이성, 용적률

그래서 요구는 매우 잘 정의되어야 하며 충분히 구체적이고 명료하여 개발자들이 이를 이해하고 작업에 착수할 수 있게 도움을 줄 수 있어야 한다.

 

요구추출 및 분석

요구추출은 소프트웨어 개발에서 특히 중요한 작업이다. 사용자가 무엇을 원하는지 결정을 내리는 작업으로서 이해관계자와의 대화, 설문 조사, 브레인스토밍, 워크숍 등의 여러 방법을 사용하여 요구를 도출한다. 요구추출 후에는 요구사항을 분석하고 중복, 모호성, 불일치 등을 식별하고 정제한다. 이 과정에서 중요한 것은 사용자의 실제 기대에 부합하도록 정확하게 요구사항을 파악하는 것이다. 요구추출이 잘못되면 소프트웨어 시스템이 사용자의 요구를 충족하지 못하거나, 개발 비용이 증가하거나, 개발 기간이 늘어나거나, 소프트웨어 시스템의 품질이 저하될 수 있다.

이러한 요구추출은 크게 3가지 우선순위를 따지는데 첫째는 절대적으로 필요한 요구인가? 둘째는 꼭 필요하지 않은 요구인가? 셋째는 요구로 판단되나 제외할 수 있는가? 이다. 그러면서 다음 사항을 고려해야 한다.

• 사용자 요구의 정확한 이해
• 요구사항 명확성과 간결성
• 요구사항 완결성과 일관성
• 요구사항 실행 가능성

요구추출 후 진행하는 요구분석에 있어 가장 중요한 것은 사용자가 현재 안고 있는 문제점을 이해하는 것이다. 이에 분석가는 사용자의 입장에서 현황을 파악하고 사용자가 원하는 문제 해결이 무엇인지 이해하여야 한다. 즉 수많은 정보를 수집하고 재구성하는 데 있어 ‘육하원칙’에 따라 질문하고 답을 구하는 단계가 요구분석이라고 볼 수 있다. 이러한 질문을 통해서 사용자의 문제를 이해할 수 있고 해결 방법을 찾는 데 도움을 받을 수 있다. 또한 해결 과정에서의 제약점과 이를 사용자가 수용할 수 있는지도 살펴야 한다. 특히 구체화한 목표가 명확해야 한다.

• 분석 대상 업무에 누가 관계되어 있는가? 그들은 누구인가? 어떤 일을 하는가?
• 현재의 상태는 어떠한가? 문제가 있는가? 요구 기능은 무엇인가?
• 신규 시스템은 언제 완료되어야 하는가? 언제 교체하는가? 
• 신규 시스템을 어떤 환경으로 운영할 것인가? 인력은 어떻게 배치하는가?
• 왜 신규 시스템을 고려하였는가? 개선하고자 하는 이유는?
• 신규 시스템은 어떻게 작동되어야 할 것인가? 작동의 제약사항은 무엇인가?

이러한 요구분석에는 구조적 분석, 객체지향 분석, 정보공학 및 정형화 방법 등 여러 기법이 존재한다.

 

구조적 분석

구조적 분석은 시스템의 기능적 요구사항을  분해하고 구조화하여 조직화하는 단계다. 이를 통해 요구사항 간의 관련성과 의존성을 이해하고 시스템의 구조를 설계할 수 있다. 구조적 분석은 문제 영역을 이해하기 위해 데이터 흐름 다이어그램(DFD), 상태 전이 다이어그램, 클래스 다이어그램 등의 모델링 기법을 활용하며 요구사항이 어떻게 상호작용하고 구성되는지를 시각화한다. 구조적 분석은 보통 다음과 같은 단계로 수행한다.

• 요구사항 분해
• 요구사항 상호 연관
• 요구사항 계층 구조화
• 요구사항 흐름도 작성

이런 단계를 통해 현재 시스템과 목표 시스템의 모형이 만들어진다. 일반적인 모형들은 정보나 아이디어를 추상화하여 집약적으로 나타내며 시스템 구성 요소들의 상호 작용과 기능들을 표현하여 사용자의 이해를 돕는다. 이는 건축과 같이 철저히 양식이 기능을 따르는 원리를 적용한다.

 

요구분석 명세

문제를 명확히 이해하고 목표가 정해지면 문서화가 필요하다. 요구분석 명세는 수집된 요구사항을 정확하게 문서화하는 것을 말하며 이 과정에서는 요구 사항들에 대한 정규화, 우선순위 정하기, 추적 행렬 생성 등이 이뤄진다. 이를 통해 개발자, 테스터 및 다른 이해관계자들이 이를 이해하고 활용할 수 있도록 한다. 이 문서는 요구사항의 상세 내용과 우선순위, 변경 요청 프로세스 등을 포함하고 시스템 설계 및 구현의 입장에서 충분한 정보를 제공, 개발자와 관계자들이 이해할 수 있는 언어로 아주 명료하게 작성하여 이후 개발 및 테스트 단계에서 참조되는 중요한 자료이다.

요구분석 명세(Software Requirement Specification)는 소프트웨어 개발 모든 단계에서 중요한 역할을 수행하며 보통은 다음과 같은 내용을 포함하며

• 시스템의 목적
• 시스템의 기능
• 시스템의 성능과 품질
• 시스템의 인터페이스
• 시스템의 환경
• 시스템의 보안
• 시스템의 유지보수

그 평가 기준은 아래와 같다.

• 무결성/완벽성: 사용자의 요구사항을 오류 없이 완벽하게 반영
• 일관성: 상호 간 모순 없이 존재
• 명확성: 여러 의미로 해석되지 않음
• 기능적: ‘어떻게’가 아닌 ‘무엇’에 초점
• 검증가능성: 사용자 요구 만족과 시스템 일치성
• 추적 가능성/변경 용이성: 체계적 정리

 

프로젝트 문제와 범위 정의

소프트웨어 개발 시 일정이 지연되거나 비용이 초과고 기대했던 품질에는 못 미치는 산출물, 그에 따라는 여러 유지비용의 증가 등과 같은 문제들은 기본적으로 계획의 부재에서 오는 경우가 많다. 개발 일정을 준수하면서 질 좋은 소프트웨어를 개발 생산하기 위해서는 정밀하고 세심한 계획수립이 필요하다. 소프트웨어 개발 프로젝트 초기 단계에서 프로젝트의 목표를 기반으로 여러 불분명한 사안들을 확인해 가면서 계획을 수립하는 것은 매우 어렵다. 하지만 계획작업을 통해 불분명한 목표, 사용자 요구사항 및 제약사항 등을 명확히 하는 것이 필요하다. 이러한 계획은 보통 문제의 범위를 확인, 정의하고 필요한 활동들을 정하며 세부적인 일정계획과 비용을 추정하고 최종적으로 계획서를 작성하는 절차로 이뤄진다. 

다시 말해 프로젝트 계획은 대상업무와 문제들을 고객이 이해하는 용어로 정확하기 정의하고 기술하는 것으로 시작한다. 문제는 철저하게 고객의 입장에서 정의되어야 하며 기술관련 전문용어 등을 사용해서는 안된다. 문제를 정의하는 것은 범위를 정하는 것이다. 이는 개발대상의 기능, 성능, 제약조건, 인터페이스 등의 프로젝트에 대한 타당성과 신뢰성 및 초기 계획을 작성가능한가에 대한 판단 근거로 쓰인다. 문제 정의는 제일 먼저 그 배경을 이해하여야 한다. 이를 위해선 고객과의 면담, 현장답사 및 실제 업무를 수행하는 실무자의 실제 업무를 관찰하거나 직접 수행을 해보기도 한다. 그러면서 객관적 시각에 문제를 파악한다. 이 모든 것이 끝나면 문제 해결을 위한 준비를 한다.

 

일정 계획

일정은 프로젝트 개발에 있어 모든 프로세스를 구성하는 작업들을 파악하여 그 우선순위와 기간을 산정하며 진행한다. 이에 모든 작업들을 수준별로 나열을 하며 산출물이 있다면 각각 기술해 준다. 프로젝트의 규모가 작다면 큰 일이 아닐 수도 있으나 대규모의 프로젝트에서는 작업도출과 더불어 각 작업들 간의 상관관계를 면밀히 검토하여야 한다. 이때 보통은 PERT/CPM을 활용하며 최종적으로 간트차트 등을 사용하여 거시적 관점에서의 일정을 관리할 수 있도록 한다. 이렇듯 소프트웨어 공학은 엔지니어링 작업으로서 정확하고 현실적인 계획을 수립하고 작업 수행에 소요되는 여러 자원들을 최적화하여야 한다. 이에 따라 프로젝트의 진척도를 실시간으로 점검할 수 있고 계획과 비교하여 문제가 있을 시에 다방면의 조치로 문제해결이 가능하다.

간트차트로 보여지는 프로젝트 작업들, 일정표는 그 수준에 맞춰 분해가 이뤄지고 계층적으로 구성하여야 하는데 이를 위해 WBS(Work Breakdown Structure)를 사용한다. 이는 작업들이 모여 소요 일정이 예측되며 이를 통해 프로젝트 전체 일정을 예측할 수 있다. WBS는 큰 단위의 업무를 관리하기 쉬운 작은 단위의 작업으로 나누기 위한 도구이다. 여기서 관리 가능한 작은 작업들은 업무 지시를 하는 단위가 되며 작업시작일, 종료일, 소요기간, 담당자, 필요 자원 등을 병기하여 관리한다. WBS는 일정계획 작업의 입력값이며 작업 분해는 프로젝트가 어떤 작업으로 구성되었는지를 알아내는 것이고 일정 계획은 이들 작업을 어떤 순서로 할 것인가를 정하는 일이다.

• 소프트웨어 개발모형 선정, 단계별 작업을 분해 후 작업결과 정의
• 각 작업간 상호의존관계 정리
• 각 작업소요기간 정의 및 프로젝트 완료에 필요한 최소기간 산출
• 프로젝트 규모추정을 통한 M/M 산출
• 확정 결과 정리 및 공유

 

비용 추정

소프트웨어 개발에 있어 비용을 정확히 예측하기는 매우 어려운 일이다. 특히 계획단계에서는 불분명한 사항들이 많고 여러 환경적인 요소로 비용에 대한 입장차도 존재한다. 그럼에도 불구하고 기준을 바탕으로 수립되는 소프트웨어 개발 비용예측은 특히 투입되는 개발자와 기간에 매우 큰 변수로 작용한다. 이에 과거 프로젝트의 경험이 중요하며 특히 유사 프로젝트가 있다면 규모와 비용, 인력들을 감안하여 예측을 어느 정도 가능하게 한다. 그러므로 정확한 예측은 프로젝트 성공율을 높이는 필수 조건이다. 이에 비용 예측방법도 매우 다양하며 인건비의 경우 소요기간을 기준으로 하거나 프로그램 규모를 기준하는 방법으로 크게 나뉜다.

첫번째 방법은 소요기간 기준이다. 이는 프로젝트 내 작업들에 소요되는 기간을 구하고 여기에 투입인력과 참여도를 반영하여 최종 인건비를 산출한다. 이 방법은 상향식이라 불리우며 단순히 헤드카운팅이라고도 하는데 시스템 개발에 필요한 모든 작업에 대한 노력들을 하나하나 계획할 수 있는 장점이 있으나 객곽적이 못한 추정 가능성이 있을 수 있다. 두번째 방법은 하향식으로 프로그램 규모를 추정하고 과거 경험을 바탕으로 예측 규모에 대한 소요인력과 기간을 추정한다. 프로그램 규모는 원시코드의 라인수(LOC)나 시스템의 기능을 정량화한, 좀더 복잡한 기능점수(Function Point) 등올 산출할 수 있다. 

 

조직 구성

경영관리에서 조직이란 개개인의 역할을 잘 정의하고 할당하여 프로젝트 목표 성취를 하기 위한 것이다. 이는 기업이나 단체 등 다수의 사람이 모여서 하나의 목표를 이루기 위한 방안으로 조직이 생겨난 것이다. 이러한 조직 구성의 목적은 공통된 목표를 위하여 상호 협력을 하는 것으로 프로젝트에서도 동일하게 적용된다. 이런 조직구성은 조직의 생산성과 효율에 얼마나 많은 영향을 미치고 그 결과가 어떻게 나타나냐에 대한 근본 원리를 따진다. 소프트웨어 개발 프로젝트에서 소프트웨어는 타 제품과는 다른 특징들로 인해 어떠한 조직을 구성하여 진행했느냐에 따라 소프트웨어 개발에 많은 영향을 미친다. 즉 소프트웨어의 품질을 향상시킬 수 있는 소프트웨어의 특성을 잘 살린 조직 구성이 필요한 것이다.

조직의 선택에 영향을 주는 요소는 비용 예측에 사용되는 요소와 유사하다. 알맞은 조직 구성은 프로젝트 기간과 매우 밀접하다. 장기 프로젝트의 경우 구성원들의 사기를 높이고 이직과 이탈을 막기 위하여 개개인의 만족도가 중요 시 된다. 경험이 많은 인력과 적은 인력이 적절하게 섞여야 하며 상호 간 배우고 배울 수 있는 관계 설정도 필요하다. 대규모 프로젝트의 경우 요구의 변경과 명세가 어려운 특성으로 인하여 프로젝트 후반에 신규 인력을 투입하면 일정은 그만큼 지연된다. 이는 인력 상호 간 의사소통의 통로 이슈와 기존 업무의 인수인계 등에 따른 시간을 고려한다고 해도 해소되지 않는 난제이다. 다시 말해 작업의 특성과 조직 구성원 사이의 의사소통의 횟수는 조직의 규모에 맞춰야 하며 필요 이상의 결과에 집중하지 않게 적정 선을 지키는 것이 중요하다.

프로젝트 팀 구성에 영향을 주는 다른 요소는 작업의 특성 및 팀 구성원 사이에 의사교류의 횟수이다. 의사소통이 원활할 수 있는 조직규모와 인력수는 매우 밀접하며 프로젝트의 복잡도와도 긴밀하다. 이에 공식적인 모형과 인원수도 산출할 수 있는데 중요한 것은 생산성에 촛점을 맞춘 균일한 규모의 조직을 구성하는 것이다. 이 규모는 소프트웨어의 특성과도 연계가 되며 팀은 원칙적으로 작업 수행에 제일 타당하게끔 조직되어야 한다. 그러기 위해선 관리자의 권한과 더불어 일정, 예산, 품질 등 여러 요소를 고려하여 조직 구성방법을 결정하여야 한다. 특히 소프트웨어 개발 팀구성은 의사결정권이 누구에게 있느냐에 따라 구별되며 리더의 역할, 권한, 의무에 따라 크게 3가지 형태의 구성방식을 갖는다.

• 중앙집중형: 하나의 관리자의 지휘에 따라 움직인다. 기업 조직 내 일반적인 계층형 조직으로 상하관계가 명확하여 대규모 조직보다는 소규모 조직에 적합하고 이의 모듈화로 규모를 키울 수 있다.
• 분산형: 의사결정을 민주주의식으로 하며 모든 작업은 공동의 작업이다. 팀 구성원 각자가 서로의 작업을 검토하고 타 구성원의 작업결과에 대하여 책임을 진다. 다만 의사소통 비용이 많이들며 이에 따른 생산성 문제가 있다.
• 혼합형: 중앙집중형과 분산형의 단점을 보완하기 위해 구성된다.

 

위험분석

위험 분석은 프로젝트에 내재한 위험 요소를 인식하고 그 영향력을 분석하여 관리하는 활동이며 프로젝트를 성공시키기 위하여 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동이 포함된다. 위험 요소에 대해 적절히 관리하지 못하면 프로젝트는 실패할 수 있다. 초기 단계에 위험 요소를 인식하고 그 영향을 분석하였어도 이를 다루는 일관성 있는 계획이 없으면 실패하기 쉽다. 이러한 위험을 줄이는 효과적인 방법은 프로토타이핑이나 점증적 개발 방법 있으며 중간 변경 위험을 대비하기 위한 모듈화도 생각해 볼 수 있다. 

< Boehm(Barry William Boehm, 미국 소프트웨어 엔지니어 및 교수, 나선형 모델 제)이 제시한 10가지 위험 요소와 관리 기법 >

• 인력부족: 유능한 인력 수급, 팀구성, 교육
• 비현실적 일정/예산: 구체적 비용/일정 예측, 원가분석, 재사용
• 잘못된 기능의 SW개발: 프로토타이핑, 조직/직능분석
• 잘못된 I/F개발: 프로토타이핑, 타스크분석, 시나리오기법
• 과포장: 프로토타이핑, 원가분석, 비용수익분석
• 계속적인 요구변경: 최대변경상한선, 점증적 개발
• 외부 모양 빈약: 벤치마킹, 성숙도분석
• 외부 기능 빈약: 사전검증, 대조확인
• 실시간 성능 빈약: 벤치마킹, 튜닝, 시뮬레이션
• 기술적 취약: 기술분석, 비용수익분석

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

소프트웨어 공학의 첫 등장은 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과 팀원들이 프로젝트를 계획, 실행, 통제하고 성과를 평가하는 데 필요한 일련의 표준 및 가이드라인을 제공한다. 이를 통해 프로젝트를 실천하면 프로젝트의 성공 가능성을 높이고 리스크를 최소화하는 데 도움을 준다.