소프트웨어공학
전공-소프트웨어공학

소프트웨어

소프트웨어의 특징

소프트웨어공학의 관점에서 소프트웨어는 단순히 실행되는 프로그램뿐 아니라, 모든 공정에서 출력되는 결과물들(도면, Use Case, 회의록 등)을 의미한다. 형상관리에 대표적으로 사용되는 깃(Git)에서의 각각의 커밋 역시 소프트웨어이다. 소프트웨어의 대표적인 특성은 다음과 같다.

  • 비가시성Invisibility

    소프트웨어는 개념적이고 무형적이며, 구조가 외부에 노출되지 않고 코드에 내재되어 있다(정보은닉).

  • 복잡성Complexity

    소프트웨어는 개발 과정과 구조가 복잡하다.

  • 순응성Conformity

    소프트웨어는 사용자 요구, 환경 등의 변화에 순응한다.

  • 복제 가능Duplicability

소프트웨어 분류 특징
응용 소프트웨어 업무를 위한 목적으로 개발된 소프트웨어
특정 고객 또는 기업의 요구를 만족시키는 주문형 소프트웨어 및
패키지로 만들어 상업적으로 판매하는 패키지 소프트웨어가 응용 소프트웨어에 속한다.
시스템 소프트웨어 하드웨어를 제어, 관리할 목적으로 개발된 소프트웨어
임베디드 소프트웨어 다른 시스템에 내장된 소프트웨어

시스템이란, 특정 목표를 달성하기 위하여 유기적으로 결합(요소들끼리 영향을 받음)된 집합체를 의미한다.

소프트웨어 개발의 어려움

고비용

소프트웨어의 성능은 하드웨어의 성능에 비해 빠르게 증가하지 않는다.

또한 소프트웨어의 유지 보수 비용이 차지하는 비율이 점차 증가하고 있다.

소프트웨어의 비용은 다음 지표들을 사용해 측정할 수 있다.

  • LOC (Lines of Code)

  • MM (Man-Month)

  • 생산성: MM당 생산하는 프로그램의 LOC

    5만 줄의 코드로 구성된 프로그램은 4천만원 ~ 1억 2천만원 정도의 비용을 요구한다.

개발 지연과 낮은 신뢰도

  • 계획에서 벗어난 프로젝트
  • 예상대로 작동하지 않는 사례
  • 개발 과정에서 유입된 오류

유지보수

개발이 끝난 뒤에도 소프트웨어의 유지보수는 필요하다.

  • 시스템에 오류가 남아 있을 수 있다.
  • 기능을 업그레이드하는 일이 흔하다.

재작업

  • 소프트웨어 개발은 의도하는 바가 잘 드러나지 않아 사용자의 요구를 파악하기 어렵다.
  • 또한 개발을 진행하면서 요구가 변경되기도 한다.

소프트웨어 공학

소프트웨어 공학이란?

소프트웨어 공학이란 최소의 비용으로 고품질의 소프트웨어를 적시에 제공하기 위한 여러 기법이나 방법을 말한다.

따라서 분석부터 유지보수에 이르기까지의 개발과정에 대해 체계적으로 접근해야 한다.

체계적인 접근: 반복적으로 사용이 가능해야 한다.

규모

프로젝트의 규모에 따라 개발에 사용되는 방법이 다르다.

품질과 생산성

비용, 일정, 품질과 같은 변수가 중요하다.

  • 비용

    Man-Month로 측정한다.

  • 일정

    time-to-market : 정해진 시간 내에 제품이 출시되어야 한다.

  • 품질

    • 기능성functionality: 요구를 만족시키는 기능을 제공하는 능력
    • 신뢰성reliablity: 정해진 수준의 성능을 유지할 수 있는 능력
    • 사용용이성usability
    • 효율성efficiency
    • 유지보수성maintainability
    • 이식성portability

소프트웨어 공학의 접근 방법

소프트웨어 엔지니어링 작업 설명
소프트웨어 개발 프로세스 시스템에 대한 개념을 소프트웨어로 구체화
품질 보증 SQASoftware Quality Assurance 개발작업이 적절히 수행되었는지 확인
프로젝트 관리 개발 및 품질보증 작업을 관리, 감독

단계적 개발 프로세스

  • 요구분석

    소프트웨어 시스템이 풀어야 할 문제를 이해하고, 시스템을 위하여 무엇을(What) 만들 것인지에 초점을 둔다.

    분석 단계에서의 작은 실수가 이후 단계에서 큰 오류를 초래할 수 있으므로 주의해야 한다.

    요구명세서(SRS)를 산출한다.

  • 설계

    사용자의 요구를 만족시키기 위해 시스템을 어떻게(How) 구축할지 결정한다.

    • 아키텍처 설계
    • 상세 설계: 각 모듈의 내부 논리를 작성한다.

    설계서(SD)를 산출한다.

  • 구현(코딩)

    시스템 설계(알고리즘)를 프로그래밍 언어로 변환(Do it)한다.

    프로그램을 읽고 이해하기 쉬어야 하므로 단순함과 명확성을 추구한다.

  • 통합과 테스트

    • 통합

      모듈들의 관계를 바탕으로 통합을 수행한다.

    • 테스트

      단위 테스트, 통합 테스트, 시스템 테스트 등을 통해 단계적으로 소프트웨어의 결함을 찾아낸다.

      내부 구조와 동작을 검사하는 화이트박스 테스트와, 그렇지 않고 진행하는 블랙박스 테스트로도 분류할 수 있다.

      테스팅 결과 보고서를 산출한다.

품질 보증

개발되고 있는 소프트웨어가 요구 및 품질 수준을 만족시킬 것을 보장하는 작업이다.

  • Validation (Right Product: 올바른 제품을 만들었는는가?)
  • Verification (Product Right: 제품을 올바르게 만들고 있는가?)

좋은 품질의 소프트웨어는

  • 사용자 관점
    • 원하는 기능을 제공하여 유용하고 쉽게 쓸 수 있다.
    • 신뢰성이 높고 필요에 따라 계속 발전한다.
  • 개발자 관점
    • 좋은 설계 구조를 가진다.
    • 테스트 및 유지보수가 용이하다.
    • 환경에 맞도록 변경이 가능하다.

소프트웨어의 품질은

  • 넓은 의미: Quality

    고객 만족

  • 좁은 의미: Quantity

    개발자의 입장으로 국한되며, 결함이 없고 명세에 부합하는 소프트웨어