shiny bead

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

- 소프트웨어가 다루는 문제가 점점 커지고 변화가 많아지지만

  '높은 품질'과 '생산성'이 일관적으로 성취하여야 할 목표임.

-프로젝트를 수행하는 동안 얻은 품질과 생산성은 여러 가지 요인에 좌우됨.

-'품질'을 좌우하는 세가지는 인력, 프로세스, 기술임.

*삼각 균형(triangle seesaw)

: 좋은 프로세스나 방법이 사용되고 작업을 수행하는 인력이 적절히 훈련되어야

 좋은 품질의 소프트웨어를 적기에 공급할 수 있음.

-소프트웨어 공학의 초점은 주로 프로세스에 있음.(프로세스: 체계적인 접근법)

-프로세스는 도구와 방법과 함께 소프트웨어 공학에서 핵심을 이룸.

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

 : 소프트웨어를 개발하는 프로세스를 개발된 제품, 즉 소프트웨어와 분리하는 것.

-적절한 소프트웨어 프로세스의 설계와 관리는 소프트웨어 공학의 중요한 연구 목표.

 → 알고리즘, OS, DB 등은 소프트웨어 제품 자체에 초점을 두고 있지만, 소프트웨어

     엔지니어링은 소프트웨어 제작 과정에 집중

-소프트웨어 엔지니어링 작업의 종류

ⓐ 소프트웨어 개발 프로세스

    : 시스템에 대한 비젼과 개념을 목표로 하는 컴퓨터 환경에 실행되는

      소프트웨어로 바꾸는 작업.

     비즈니스 요구를 파악하고 타당성을 검토하며 시스템이 제공하여야 할

     요구와 성능을 정형화함. 또한 설계하고 구현하고 테스팅하여 목표환경에 설치함.

ⓑ 품질 보증

    : 소프투에어 품질 보증(SQA, Software Quality Assurance)은 개발 작업이 적절히

      수행되었는지 확인하는 작업.

      개발 작업에 의한 산출물이 요구와 일치하는지 품질 수준에 맞는지 검사함.

ⓒ 프로젝트 관리

    : 개발과 품질 보증 작업을 관리하고 감독하는 일.

      노력 예측, 프로젝트 계획, 일정, 리스크 관리, 행정 등.

      소프트웨어 시스템이 정해진 일정과 예산 내에 인도될 수 있도록 확인하는 작업. 

[출처]소프트웨어공학론(최은만 저, 정익사)

1.3 소프트웨어 공학이란?

: 전기전자 기술자 협회(IEEE)의 소프트웨어 공학 표준에 의하면 소프트웨어 공학이란

소프트웨어의 개발과 운영, 유지보수, 소멸에 대한 체계적인 접근 방법이라고 정의.

- 소프트웨어 엔지니어링의 목표

: 소프트웨어 개발 작업이 결과를 예측할 수 없는 주먹구구식이 아니라

과학이나 공학에 더 가깝게 하려는 노력임.

아래 설명하는 요소들이 소프트웨어 공학 분야의 발전과 기술 개발의 원동력이 됨.

1.3.1 규모

- 규모가 큰 시스템을 개발하는 일은 작은 시스템을 개발하는 방법과 다른 방법이

동원되어야 함.

-일반적으로 소규모 시스템에 사용하던 방법은 대규모 시스템에 확대 적용하기 어려움.

-대규모 프로젝트는 엔지니어링(사용하는 방법, 절차, 도구)과 프로젝트 관리 기법이 필요.

-소규모 프로젝트에서는 개발과 관리에 비정형 방법을 사용할 수 있으나,

 대규모 프로젝트에는 정형화된 방법이 필요.

*소프트웨어 제품의 규모(KLOC)

-소규모: 만 줄 이하

-중규모: 십만 줄 이하

-대규모: 백만 줄 이하

-초대규모: 수백 만 줄 이상

1.3.2 품질과 생산성

: 엔지니어링 원리는 비용, 일정, 품질과 같은 변수를 중요하게 여김.

-소프트웨어 시스템을 개발하기 위한 비요은 대부분 인건비에 속함.

 (사람이 많이 필요한 노동집약적인 작업이기 때문)

 → 소프트웨어 프로젝트의 비용은 MM(man-month)로 측정.

-일정은 대부분의 프로젝트에서 중요한 요소.

 최근에는 제품이 시장에 나올 때까지 걸리는 기간(time to market)이 더욱 짧아지는 추세.

 → 즉 소프트웨어는 더욱 빨리 개발되어야 함.

*생산성

 : MM당 생산하는 소프트웨어의 라인 수.

-모든 사업 전략을 '품질' 중심으로 짜고 있음.

 고품질의 소프트웨어를 개발하는 것이 소프트웨어 엔지니어링의 또 다른 근본적인 목표.

*소프트웨어의 품질 속성

 ⓐ기능성(functionality): 소프트웨어가 사용될 때 원래 정한 또는 내재된 요구를

                                만족시키는 기능을 제공하는 능력. (적합성, 정확성, 보안성 등)

 ⓑ신뢰성(reliability): 소프트웨어가 정해진 수준의 성능을 유지할 수 있는 능력.

 ⓒ사용용이성(usability): 쉽게 이해되고 배울 수 있고 사용될 수 있는 능력.

                                (이해용이성, 학습용이성, 운용성 등)

 ⓓ효율성(efficiency): 사용되는 자원의 양에 따라 적절한 성능을 제공할 수 있는 능력.

 ⓔ유지보수성(maintainability): 정정, 개선, 적응시킬 목적으로 수정될 수 있는 능력.

                                         (변경용이성, 시험용이성, 확장성 등)

 ⓕ이식성(portability): 별도의 작동이나 수단 없이 다양한 환경에서 적응될 수 있는 능력.

                             (적응성, 설치용이성 등)

-품질은 많은 의미가 담긴 다차원 개념.

 →소프트웨어 품질은 하나의 숫자로 축약할 수 없음.

 →품질 개념은 프로젝트마다 다름.(프로젝트마다 개벌 전에 품질 목표를 설정하여야 함)

-일반적으로 '신뢰성'이 소프트웨어 품질의 기준을 대표함.

-품질 측정 방법 중 한가지는 출시된 소프트웨어의 단위크기(일반적으로 천 줄, KLOC)당 결함의 수.

*결함

 : 소프트웨어가 고장 나게 하거나 출력이 바르지 않게 하는 문제.

1.3.3 일관성과 재현성

 : 어떻게 하면 성공적인 결과가 되풀이 될 수 있고 품질과 생산성에 일관성을 가지게 하느냐.

-사용하는 방법이 프로젝트 전체에 반복 적용되어 생산된 소프트웨어의 품질에 일관성이 있어야 함.

-소프트웨어 개발 기관은 일관된 품질을 일관된 생산성으로 만들기 원함.

-ISO 9001과 CMM(Capability Maturity Model)은 기관이 방법론을 표준화 하고 일관되게

 사용할 것을 권장하고 있음.

1.3.4 변경

 : 오늘날 비즈니스 환경 변화가 매우 빨라 소프트웨어도 변화의 흐름을 따라갈 것을 요구.

-소프트웨어는 변경을 어렵게 하는 물리적인 부분이 없기 때문에 변경하기 쉽고 소프트웨어에서

 더 많은 변경이 일어날 것으로 예상됨.

-변경은 소프트웨어 공학의 중요한 성장 요인.

[출처]소프트웨어공학론(최은만 저, 정익사)

*소프트웨어 공학

: 사용자가 있는 실용적인 소프트웨어, 즉 이를 통하여 비즈니스 업무나 제조 활동 등에서

발생하는 문제를 해결해 주는 프로그램을 다룸.

즉 소프트웨어에 있는 직접 똔느 간접적인 손해가 따를 수 있는 심각한 문제를 해결하기 위한 것.

*소프트웨어 제품

: 고객의 문제를 해결하기 위하여 구축하며 비즈니스를 운영하기 위하여 사용.

소프트웨어 구축에서 중요한 점은 정확히 작동하는 것.

→소프트웨어 시스템은 높은 품질이 요구됨.

소프트웨어 공학이 다루는 문제는 제품으로 만든 알찬 소프트웨어(industrial strength)임.

1.2.1 고비용

1. LOC(Lines of Code)

 : 소프트웨어의 규모를 측정하는 데 사용.(가장 보편적)

2. MM(Man-Month)

 : 소프트웨어 개발에 드는 비용을 나타내는 데 사용.

   주된 비용은 인건비.

   생산성은 MM당 생산하는 프로그램의 LOC로 측정.

   (새로 프로그램을 작성하기 위한 생산성은 일반적으로 MM당 300~1000LOC)

1.2.2 개발 지연과 낮은 신뢰도

- 600여 회사를 조사하였더니 35% 이상이 계획에서 벗어난 컴퓨터 관련 개발 프로젝트였음.

  (계획에서 벗어났다함은 일정이 조금 지연되거나 예산이 초과된 것이 아니라 관리할 수 없을 정도가

  되어버린 프로젝트를 의미)

-방위 산업 보고에 의하면 장비 고장의 70% 이상이 소프트웨어에 의한 것이라고 함.

→ 결국 엔지니어링 원리를 적용하는 시스템 제작에서 소프트웨어가 가장 취약한 부분이라는 것을 발견하게 됨.

-소프트웨어 고장은 다른 요소(기계, 전기시스템 등)의 고장과는 다름.

 : 다른 엔지니어링 원리를 적용하는 제품의 고장은 노후화 되면서 진행되는 물리적 또는 기계적

   특성의 변화 때문.

   소프트웨어 제품은 세월이 흐르면서 마모되는 것이 없음. 즉 소프트웨어에서는 설계와 개발 과정에

   유입된 오류에 의해서만 고장이 발생.(소프트웨어 시스템은 일정 기간 올바로 작동되다가 고장을

   일으킬 수도 있지만 고장의 원인인 버그는 처음부터 있던 것)

1.2.3 유지보수와 재작업

1. 유지보수

-소프트웨어가 배포, 설치된 후에는 유지보수 단계로 들어감.(시스템에 남아 있는 오류가 있기 때문에 유지보수)

-버그가 없더라도 소프트웨어는 자주 변경됨.(업그레이드, 환경의 변화로 인해)

-유지보수 비용은 소프트웨어 개발 비용을 초과함.

-유지보수 작업은 현재 소프트웨어를 기반으로 함.

 → 현재 소프트웨어를 이해하는 과정 필요.(여기에 상당한 노력과 비용이 듦)

2. 재작업

- 소프트웨어 개발에서 가장 큰 문제 중 하나는 의도했던 바가 잘 이해되지 않는다는 점.

  : 처음엔 요구가 잘 정의되었다고 생각했는데 개발이 진행되면서 시스템에 대한 이해도 깊어지고

    새로운 요구가 자꾸 추가됨. 그로 인해 계속 변경을 요구하게 되고 변경 때문에 재작업을 하게 됨.

- 개발 비용 중 30~40%가 변경으로 인한 재작업.

-변경과 재작업이 소프트웨어 위기에 대한 주요 원인.

[출처]소프트웨어공학론(최은만 저, 정익사)

1.시스템

: 필요한 기능을 실현시키기 위하여 관련 요소를 어떤 법칙에 따라 조합한 집합체.

-소프트웨어도 독립적으로 존재하는 것이 아니라 컴퓨터를 기반으로 하는 여러 시스템과 관계를 맺고 있음.

-각 서브시스템은 다른 서브시스템으로부터의 자극에 대하여 영향을 받고 반응함으로써 상호작용하고 이들이 통합되어 하나의 거대한 시스템이 형성되어 있는 것

-소프트웨어 그 자체도 상호 동작하는 서브시스템드로 구성된 하나의 시스템

2.시스템의 성질

ⓐ서브시스템

  : 시스템은 관련 깊은 서브시스템들로 구성.

    ex) 교통시스템은 신호기, 신호체계, 도로망 등 여러가지 요소가 있고 이들 요소들은 원활한 교통 소통과

    제어를 위하여 밀접하게 연관.

ⓑ기능적 분할

  : 시스템은 규모가 작은 부속 시스템(서브시스템)들로 나눌 수 있음.

ⓒ시스템 경계

  : 시스템은 어떤 것이건 시스템과 주변 환경을 구분할 수 있는 경계가 있음.

     이곳이 입력과 출력이 만나는 곳.

ⓓ자동화 경계

  : 시스템이 자동화된 부분과 수동 작업 부분을 나누는 경계.

3.소프트웨어 엔지니어가 파악해야 할 사항

  : 소프트웨어 엔지니어는 개발하려는 소프트웨어에 대하여 시스템적으로 사고하여야 함.

-대상을 시스템으로 파악할 수 있어야

-서브시스템을 찾아낼 수 있어야

-시스템의 특성과 기능을 찾아낼 수 있어야

-시스템의 경계가 어디인지 찾아낼 수 있어야

-시스템에 대한 입력과 출력을 찾아낼 수 있어야

-서브시스템 사이의 관계를 찾아낼 수 있어야

[출처]소프트웨어공학론(최은만 저, 정익사)

1.1 소프트웨어(Software)

소프트웨어란?

: 프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체를 말함.

소프트웨어 프로그램 이외의 문서와 정보도 소프트웨어 생산 작업의 결과이기 때문에

소프트웨어에 포함.

프로그램 vs 소프트웨어

: 프로그램은 프로그램 언어로 작성된 코드, 즉 정적인 표현을 의미하지만

소프트웨어는 프로그램이 컴퓨터를 가동시킨다는 동적인 의미를 포함.

소프트웨어의 특성

-invisibility(비가시성)

-complexity(복잡성)

-conformity(변형 가능)

1.1.1 소프트웨어의 유형

-주문형 소프트웨어

: 특정 고객의 수요를 만족하기 위해 개발된 소프트웨어.

다른 사용자나 기관에게는 쓸모없거나 잘 맞지 않음.

사용할 기관 내에서 만드는 경우가 많고 외부에 발주하여 개발을 의뢰하기도 함.

ex) 웹사이트, 항공기-교통제어 시스템, 대기업의 재정관리 시스템.

-패키지형 소프트웨어

:공개된 시장에 내놓고 판매하기 위한 것으로 범용 컴퓨터에서 실행되어 기능을 수행.(범용 소프트웨어)

소프트웨어에 대한 요구는 전적으로 시장의 요구에 의해 결정.

비즈니스 분야에서는 주문형 소프트웨어보다 패키지형 소프트웨어를 사용.(훨씬 저렴하고 신뢰도가 높아서)

(단점)특정 기관의 요구에 꼭 맞지 않을수도.

COTS(Commercial Off-The-Shelf) 소프트웨어라고도 불림.(판매하기 위해 진열된 판매대에서 뽑혀나감)

ex)워드프로세서, 스프레드시트, 컴파일러, 웹브라우저, 운영체제

-임베디드 소프트웨어

: 시장에서 판매되는 하드웨어 장치(세탁기, 자동차 등)에서 수행되는 소프트웨어.

범용 소프트웨어와는 달리 하드웨어를 교체하지 않는 한 소프트웨어를 업그레이드하기 어려움.

하드웨어 장치가 범용으로 판매된다는 점에서 임베디드 소프트웨어도 범용 패키지 소프트웨어와 유사하지만

개발방법과 프로세스가 달라 별도의 분야로 취급.

대량의 소비자와 상품을 추구해 나가므로 소프트웨어 카피의 수량이 대단히 많음.

*소프트웨어 카피 수량: 임베디드 > 패키지 > 주문형

(주문형이 카피 수는 가장 적지만 시스템이 다양하고 개발에 종사하는 인력이 많음)

범용 소프트웨어를 구입하여 커스텀화하는 방법도 있음.(비용이 적게 들지만, 범용 소프트웨어의 새 버전이

출시되면 계속 커스텀화 작업을 반복해야 하는 위험)

*요구되는 하드웨어 성능: 패키지 > 임베디드 > 주문형

*개발 인력: 주문형 > 패키지 > 임베디드

-소프트웨어가 동작되는 하드웨어 환경에 따라

: 대형, 병렬처리, PC 또는 워크스테이션, 모바일 소프트웨어

-운영체제 환경에 따라

: 단일 사용자, 다수 사용자, 원도우 및 인터넷 환경 소프트웨어

-소프트웨어가 쓰이는 분야에 따라(가장 보편적인 방법)

: 행정, 금융, 국방, 의료, 항공, ...

-리얼타임 소프트웨어와 자료처리 소프트웨어

리얼타임 소프트웨어: 임베디드 시스템이나 산업용 플랜트, 통신 네트워크와 같이 특수 목적의 하드웨어에

장착되어 실행.

외부로부터의 반응, 즉 사용자가 버튼을 누르거나 센서로부터 신호가 발생되었을 때 신속히 반응.

따라서 대부분의 설계 노력은 반응시간을 보장하려는 데 소모.

[출처]소프트웨어공학론(최은만 저, 정익사)