때찌네

1강 1장 소프트웨어공학 개요

학습에 앞서
이번 보충학습은 교재 1장 “소프트웨어 공학 개요”의 내용 가운데 우리가 꼭 알고 있어야 하는 개념과 용어 일부를 정리한 것이다. 소프트웨어공학 과목을 학습할 때 관련 개념이나 용어들에 대해 그 의미를 정확히 이해하고 적소에 사용할 수 있어야 하는 점은 매우 중요하다

• 소프트웨어 공학과 시스템 공학
  시스템 공학은 하드웨어 개발, 정책, 프로세스 설계, 시스템 배포 및 소프트웨어 공학을 포함하는 개념으로 개별적인 하드웨어나 소프트웨어의 개발을 다루는 것은 아니다. 소프트웨어 공학은 소프트웨어기반의 시스템만을 다룬다.
  
• 프로토타입
  프로토타입의 의미는 적용 분야나 관점에 따라 다르다. 소프트웨어공학에서는 일반적으로 진화적(evolutionary) 프로토타입과 일회성(throwaway) 프로토타입으로 나뉜다. 전자는 개발 초기에 요구사항의 일부를 구현하여 관련자(stakeholder)와 의사소통하기 위한 소프트웨어를 의미하는 것으로, 계속 보강되어 최종적인 제품으로 발전하게 된다. 후자는 연구 과제의 결과물이거나 요구사항 분석, 품질 보증, 사업 분석 등을 위해 일시적인 데모 버전으로 개발되는 것으로 모델의 성격을 가진다.
  
• 소프트웨어 공학 방법(method)
  소프트웨어 개발을 위한 구조적인 접근방법을 의미하는 것으로 모델을 기술하기 위한 표기법과 규칙, 모델의 개발을 위한 절차와 권고사항을 포함한다. 이것은 프로젝트 관리, 분석, 설계, 코딩, 테스팅, 품질 보증 등의 분야로 나뉠 수 있다
  
• 소프트웨어 위기
  ”소프트웨어 위기”는 1968년 독일에서 열렸던 1회 NATO 소프트웨어공학 컨퍼런스에서 F. L. Bauer가 처음 사용한 용어로 당시까지 소프트웨어 공학 개념은 명확히 정의되지 못했던 상태였다. 이것은 컴퓨터 파워의 빠른 증가로 인해 다루어야 할 문제들의 복잡성 또한 크게 증가한다는 사실을 묘사한 것으로 본질적으로 정확하고 이해하기 쉬우며 검증가능한 프로그램 작성의 어려움을 나타낸 것이다. 1972년 ACM 튜링상을 받은 Edsger Dijksta는 강연에서 소프트웨어 위기를 다음과 같이 표현하였다. “소프트웨어 위기"의 주 원인은 컴퓨터가 수십 배로 강력해졌기 때문이다. 정확히 말하면 기계가 없다면 프로그래밍도 전혀 문제가 되지 않는다. 또한 허약한 컴퓨터만 있다면 프로그래밍도 별반 문제가 되지 않는다. 그러나 이제 컴퓨터는 매우 강력해졌으며 프로그래밍도 그에 상응하는 커다란 문제를 가지게되었다.”
    소프트웨어 위기의 원인은 소프트웨어 프로세스의 큰 복잡성과 소프트웨어 공학의 상대적 미성숙함과 관련 있다. 다음의 문제점들은 소프트웨어 위기 현상을 분명히 보여주는 것들이다.
  • 프로젝트 예산의 초과, 프로젝트 기간의 초과, 낮은 품질의 소프트웨어, 요구사항을 충족하지 못하는 소프트웨어, 관리되지 못하고 유지보수가 힘든 프로젝트
     
• 패키지와 주문형 소프트웨어
  패키지는 generic product라하여 일반적인 목적으로사용되는 제품으로, 필요로하는사용자가 시장에 나와 있는 것을 구입하게 된다. 이러한 소프트웨어의 요구 명세를 작성하는 주도권은 개발조직이 가지게 되며 예를 들어 DB프로그램, 문서 편집기, 이미지 도구, 프로젝트 관리 도구 등을 들 수 있다. 주문형 소프트웨어는 bespoke product라 하여 특정 고객에 맞도록 개발되는 제품을 의미한다. 이러한 소프트웨어의 요구 명세를 작성하는 주도권은 사용자가 가지게된다. 예를 들어 특정 전자장비의 제어 시스템, 특정 업무를 지원하는 시스템, 항공 운항 통제 시스템 등이 있다.
  
• 소프트웨어 프로세스와 생명주기 모형
  소프트웨어 프로세스는 도구와 방법을 사용하여 작업하는 순서를 말하며 보다 구체적으로는 소프트웨어 생산과 관련한 행위들과 관련 결과물들의 집합을 의미한다 프로세스는 개발 조직의 특성에 따라 다르나 일반적으로 다음의 단계들로 구성된다.
  
  • 소프트웨어 명세:소프트웨어의 기능과 동작에 대한 제약사항을 정의
  • 소프트웨어 개발:요구사항에 맞는 제품 생산
  • 소프트웨어 확인:고객의 요구사항에 맞는 것인지 확인
  • 소프트웨어 진화:변화하는 고객의 요구사항에 맞도록 소프트웨어 변경
  • 소프트웨어 생명주기 모형은 프로세스 모형이라고도 하며 실제 소프트웨어 프로세스를 단순화하고 추상화시켜 표현한 것이다.
    
• 점증
  점증적인 개발 방법을 적용했을 때, 먼저 고객은 시스템이 제공해야 하는 서비스 목록을 개략적으로 확인해 주어야 한다. 또한 어떤 서비스가 가장 중요하며 어느 것이 덜 중요한지를 알려주어야 한다. 그런 다음 여러 점증들이 정의될 수 있다. 각 점증은 시스템이 가지는 전체 기능에 대한 부분 집합이다. 점증에 서비스를 할당하는 것은 서비스 우선순위를 따르게 되는데 높은 서비스들을 먼저 개발되도록 하는 것이다. 즉 가장 중요한 첫 번째 점증의 서비스 요구사항들을 상세히 정의하고 개발한다. 개발을 진행하면서 추가 요구사항들이 발견되면 차후의 점증에만 반영되도록 한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.