00. 들어가기 전
저처럼 비전공자이지만 학문적 기초를 닦고자 하시는 분들, 또는 전공자이나 기초적인 컴퓨터 과학 지식(일명 CS 기초)을 더 채우고자 하는 분들을 위해 부족하게나마 도움이 되고자 글을 씁니다.
앞으로 CS 기초와 관련된 글들을 게시할 예정이고, 이번 포스팅은 소프트웨어 공학에 대한 정리입니다. 글들은 책을 읽고 요약·정리한 내용으로 채울 예정이고, 추후 강의나 보충 자료를 통해 내용을 수정할 수 있습니다.
블로그에 들려주셔서 감사하고, 이 포스팅이 여러분들께 조금이나마 도움이 되길 바랍니다. 감사합니다.
01. 소프트웨어 공학이란?
개발 또는 정보 관련 자격증을 준비하면서 소프트웨어와 소프트웨어 공학이라는 말을 듣게 된다. 소프트웨어가 무엇인지는 막연히 알겠는데, 소프트웨어 공학은 무엇일까?
소프트웨어 공학은 소프트웨어를 어떻게 만들 것인지, 만드는 동안 소요되는 시간과 또 만들어진 결과물의 모습은 어떻게 되는지에 대해 정리한 것이라고 한다.
간단히 정리하자면 소프트웨어를 어떻게하면 잘 만들 수 있는지 가르쳐주는 것이 소프트웨어 공학이라고 한다.
02. 소프트웨어 공학 탄생과 정의
소프트웨어 공학이라는 개념은 소프트웨어 위기(Software Crisis) 속에서 탄생했다. 1960년대 프로그램 개발에 대한 수요가 폭발적으로 증가하면서 많은 개발 프로젝트가 진행됐지만, 당시 이를 지원해줄 공급은 턱없이 부족했고 이에 결과물은 당연히 좋지 못했다.
많은 소프트웨어 개발 프로젝트가 실패하면서 이를 극복하기 위해, 처음부터 모든 것을 만들어내는 것이 아닌 공학적 패러다임을 적용해 개발을 진행하자는 의견이 제기되었고, 1968년 10월 독일의 가미쉬(Garmisch) 도시에서 개최된 NATO의 한 커퍼런스에서 “소프트웨어 공학(Software Engineering)”이라는 용어가 처음 제안되었다.
컨퍼런스가 진행될 때 의장이었던 프리드리히 바우어(Bauer)는 소프트웨어 공학을 다음과 같이 정의했다.
기계에서 효율적으로 작동되는 신뢰성 있는 소프트웨어를 경계적으로 획득하기 위해 적절한 공학적 원리를 수립하여 활용하는 것이다
“Establishment and use of sound engineering principles to economically obtain software that is reliable and works on real machines efficiently.”
소프트웨어 공학 IEEE(Institute of Electrical and Electronics Engineers)는 다르게 정의했다.
소프트웨어의 개발과 운용, 유지보수에 대한 체계적(systematic)이며, 훈련된(disciplined) 계량화할 수 있는(quantifiable) 접근방식의 적용이다
“the application of a systematic, disciplined, quantifiable approach to the development operation, and maintenance of software”
간단히 정리하면,
- 소프트웨어 공학은 소프트웨어 위기 때 많은 프로젝트 실패 속에서 해결 방안으로 탄생
- 소프트웨어 공학이란,
- 효율적이고 신뢰성 있는 소프트웨어를
- 경제적(비용과 시간을 고려)이게 개발하기 위하여
- 체계적이며 계량화할 수 있는 공학적 원리를 이용해 개발하는 방법
정도로 이해하면 될 것 같다.
03. 소프트웨어 정의와 구성요소
위에서 소프트웨어 공학이 어떻게 탄생했고, 그것이 무엇인지 정의를 통해 알아봤다. 그렇다면 소프트웨어는 무엇일까? 무엇을 소프트웨어라 말할 수 있는걸까? 이는 단순히 프로그램을 일컫는 말일까?
답은 아니다. 이를 이해하기 위해 두 개의 정의를 살펴볼 필요가 있다.
소프트웨어는 단순한 프로그램 뿐만 아니라 프로그램이 올바르게 작동하도록 하는데 필요한 관련된 문서 및 설치 데이터를 의미한다. by. 솜머빌(Sommerville)
소프트웨어는 1) 실행되면서 원하는 기능이나 함수, 성능을 제공해 주는 명령어(컴퓨터 프로그램); 2) 프로그램이 데이터를 적절하게 처리할 수 있게 해 주는 자료구조; 3) 프로그램의 사용이나 운영을 나타내는 하드카피나 가상 형태인 문서이다. by. 프레스만(Presman)
솜머빌은 소프트웨어를 프로그램 뿐 아니라 관련된 문서와 데이터까지 포함하여 정의했고, 프레스만은 프로그램, 문서, 그리고 자료구조까지 포함해 정의했다.
즉, 소프트웨어는 프로그램 뿐만 아니라 문서와 데이터, 때로는 자료구조까지 포함한 것을 일컫는다.
04. 소프트웨어 특징 4가지
많은 프로젝트가 실패하면서 소프트웨어 공학이 탄생했는데, 소프트웨어가 어떤 특징을 갖고 있길래 많은 프로젝트들을 실패했을까? 소프트웨어의 특징은 4가지이다.
- 비가시성
- 변경성
- 복제성
- 복잡성
비가시성
비가시성이란 “가시성이 없음, 보이지 않는다”는 뜻이다. 개발 초기에는 소프트웨어 완성 모습을 알 수 없고, 개발 과정 중에도 변경이 일어나 모습을 명확히 그리기가 어렵다. 개발이 완료되더라도 화면만 볼 수 있을 뿐 소프트웨어 그 전체를 알 수 없고, 이러한 비가시성으로 인해 프로젝트는 관리가 어렵고 결과를 예측하기도 쉽지 않다는 특징이 있다.
변경성
소프트웨어는 변경하기가 쉽다는 특성이 있다. 프로젝트가 최종적으로 완성되기 전까지 소프트웨어는 계속 변경될 가능성이 있고, 완성된 후에도 유지보수를 통해 지속적으로 변경된다. 유지보수를 할 수록 처음 설계한 이상적인 모습에서 달라지게 되고 품질은 점점 더 떨어지게 된다.
복제성
소프트웨어는 무한 복제가 가능하다. 소프트웨어는 무한 복제가 가능하며, 복제를 아무리 많이 한다고 해도 닳아 없어지지 않는다.
복잡성
소프트웨어 개발과정은 아주 복잡하고, 개발된 결과물인 문서산출물, 데이터 구조 및 데이터 또한 대단히 복잡하여 전체 시스템이 제대로 동작하게 하기 위해 전체를 조화롭게 작용해야 한다.
05. 소프트웨어 탄생과 폐기
인간이 태어나고 죽음을 맞이하듯 소프트웨어도 무한히 사용하는 것이 아니라 탄생부터 폐기까지의 과정이 존재한다. 프로젝트를 관리함으로써 필요한 소프트웨어를 설계 및 개발하고, 가동 후에는 유지보수를 함으로써 소프트웨어를 운영해나간다. 그러다 다른 소프트웨어로 대체되는 시점에서 해당 소프트웨어는 폐기되는 과정을 거치게 된다.
06. 소프트웨어 도입 프로젝트 방식
소프트웨어는 여러가지 이유에서 도입이 되고, 도입하는 방식에 따라 인하우스(in-house) 개발 프로젝트와 SI(System Integration) 프로젝트, 패키지 도입으로 나뉜다.
인하우스(in-house) 개발 프로젝트
조직 내부에서 자체적인 개발 인력을 활용해 소프트웨어를 개발하는 방법이다. 소규모 프로젝트를 추진하여, 조속한 시일 내에 활용할 수 있도록 하고자 할 때 활용한다. 필요 개발자 또는 전문가를 계약해 일부 호라용하는 경우도 있다.
SI(System Integration) 프로젝트
조직 내부의 인력으로 감당하기 어려운 규모의 시스템을 구축하고자 할 때, 전문 SI업체에 개발을 맡기는 경우이다. SI업체 선정작업이 필요하고, 제안평가를 통해 업체를 선택하게 된다. 선택 과정에서 RFP(Request For Proposal)를 제시하여 도입하고자 하는 시스템의 목적과 규모, 프로젝트 기간, 예산 등을 SI업체에 제시하여 제안서를 받는 과정을 거친다.
패키지 도입
패키지 종류는 다양하고, SAP이나 Oracle 등 세계적으로 유명한 기업의 ERP 패키지를 도입하는 경우가 대표적이다. 패키지의 기능을 수정 보완하여 활용할 수 있도록 커스터미이징이 가능하며, 수정해야 할 수준에 따라 커스터마이징 기간이 달라지고, 비용이 추가적으로 발생한다.
정리
- 소프트웨어 위기
- 소프트웨어 공학 탄생과 정의
- 소프트웨어 개념 및 구성요소
- 소프트웨어 특징 4가지
- 소프트웨어 탄생과 폐기
- 프로젝트 방식 3가지
추가 보완 사항
- 소프트웨어 위기의 자세한 내용과 1960년대 컴퓨터 수요 증가 원인을 보충하고 싶음
- 공학적 패러다임 / 공학 개념 도입의 의미를 더 파악하길 바람
댓글남기기