[소프트웨어 공학] Software Engineering 1

[소프트웨어 공학] Software Engineering 1

학교에서 컴퓨터공학을 전공으로 공부할 때 각 과목별로 학습한 내용을 Github에 올려두곤 했었는데, Github에 너무 많은 Repository가 쌓여서 중요하지 않은 Repository를 삭제하기 위해 관련 내용을 블로그로 옮기는 작업을 하려고 합니다. Github 자체를 블로그로 만들지 않았기 때문에 Tistory로 옮기고 있습니다.

 

소프트웨어 공학에 대한 내용을 정리하고자 이 글을 작성합니다.

 

# 소프트웨어 공학 학습 목차

1. 소프트웨어

2. 소프트웨어 위기

3. 소프트웨어 프로젝트

4. 소프트웨어 개발 모형

5. 소프트웨어 개발에 영향을 미치는 요소

 

1. 소프트웨어

소프트웨어란(Software)?

프로그램, 프로그램을 설치, 운용, 보수하기 위한 필요한 정보 및 재료들을 말합니다. 위키백과에서는 소프트웨어는 '컴퓨터에게 동작 방법을 지시하는 명령어 집합의 모임이다.'라고 설명합니다. 소프트웨어는 프로그램의 동적인 실체이고, 프로그램은 형식 언어로 표현된 지적 산물입니다.

 

소프트웨어와 사회

소프트웨어는 정보화 사회, 서비스의 자동화, 기술의 발전과 기술자 수요의 증가, 정보의 신속한 유통, 안전과 보안 등 다양한 사회현상에 의해 발전해오고 있습니다. 컴퓨터가 활용되면서 소프트웨어 생태계는 폭발적으로 발전하게 되었고, 소프트웨어가 발전하면서 사회 발전에도 많은 기여를 하고 있습니다.

 

소프트웨어의 특성

소프트웨어에는 다음과 같은 특성을 지니고 있습니다.

 

비가시성 (invisibility, intangible) : 구조를 파악하기 어렵고, 개발이 난이하며, 눈에 보이는 않는다는 특성을 갖습니다.

복잡성 (complexity) : 소프트웨어, 프로그램은 굉장히 복잡한 구조 갖고 있어 이 같은 특성을 갖습니다.

순응성 (conformity) : 프로그램 명령이나 규칙에 따라 동작한다는 특성을 갖습니다.

복제 가능 (duplicability) : 소프트웨어나 프로그램은 복제가 가능합니다.

테스트 가능 (testability) : 소프트웨어는 테스트 할 수 있습니다.

변경 (changeability) : 소프트웨어는 수정(변경)될 수 있습니다.

장수성 (longevity) : 소프트웨어는 닳아 없어지지 않는다는 특성을 갖습니다.

노동 집약 (labor intensive) : 많은 노동 시간이 투자된다는 특성을 갖습니다.

 

소프트웨어의 종류

소프트웨어는 기능에 따라, 판매 형태에 따라 분류될 수 있습니다.

 

# 기능에 따른 분류

1) 시스템 소프트웨어

 - 운용 ( OS Operating System, DBMS, 네트워크 통신, ETC... )

 - 유틸리티

 - 구현 ( Compiler, IDE, Development Kit, Library, ... )

2) 응용 소프트웨어

 - 산업 전반 : Word Proccessor, Spread Sheet, ...

 - 특수 산업 : 은행, 보험, 생산, 기계... 

 

# 판매 형태에 따른 분류

1) 주문형 : 특정 고객의 수요를 만족하기 위해 개발된 소프트웨어 ex) 웹사이트, 항공-교통제어 시스템,...

2) 패키지형 : 공개된 시장에서 판매, COTS(Commercial Off-The-Shelf)

3) 임베디드 시스템 : 하드웨어에 탑재, 변경 어려움

 

시스템(System)

시스템은 유기적으로 상호 작용하는 개체들의 모임을 말합니다. 소프트웨어는 컴퓨터를 기반으로 하는 여러 시스템과 관계를 맺고 있습니다.

 

특징으로는 시너지 효과, 역동적으로 발전, 변경, 상반되는 요구와 이해관계의 절충

 

소프트웨어 자체도 하나의 시스템으로 볼 수 있습니다. (정보시스템, 제어시스템, 탑재 시스템)

 

2. 소프트웨어의 위기

소프트웨어 공정의 문제점

비용 초과, 기간 지연, 성능 저하, 비신뢰성, 유지 보수 불가능, 엄청난 유지 보수 비용

 

이러한 문제점들로 인해 소프트웨어가 위기를 맞이하는 시기가 있었습니다. 소프트웨어의 요구와 공급 능력 간의 차이가 심했던 것이죠. 

 

1965년에서 1985년으로 봤을 때, (대략) 요구는 100배 증가한 것에 비해 생산성은 2배 증가, 인력 공급은 10배 증가했다고 하니 위기를 맞이한 것이죠.

 

이러한 차이를 극복해내고 해결점을 찾기 위해 소프트웨어 공학이 등장했다고 볼 수 있습니다.

 

소프트웨어 공학

정의

질 좋은 소프트웨어를 경제적으로 생산하기 위해 공학, 과학, 수학적 원리와 방법을 적용한 것.

by. Watts Humphrey, SEI

 

소프트웨어의 개발, 운용, 유지 보수 및 소멸에 대한 체계적인 접근 방법

by. IEEE Computer Society

 

품질, 효율, 비용, 인정에 관한 공학적인 접근 원리

by. F. Brooks

 

목표

품질(Quality)

생산성(Productivity)

 

 

소프트웨어 품질(Quality)의 의미

소프트웨어의 품질에는 2가지 의미를 갖고 있다고 합니다.

 

넓은 의미의 품질은 고객을 만족시키는 것,

좁은 의미로는 결함이 없고 요구 명세에 부합되는 소프트웨어를 의미합니다.

 

넓은 의미의 품질로는 소프트웨어가 정확하고 성능이 좋은 것은 물론이며 고객이 원하는 것을 말합니다. 어떤 탁월성을 보여서 사용하면서 만족을 얻을 만한 것이 되야 합니다.

 

좁은 의미의 품질로는 개발자의 입장으로 국한 할 수 있고, 개발자가 생각하는 품질의 개념은 소프트웨어가 요구를 만족하느냐 못하느냐의 여부에 따라 품질이 평가될 수 있습니다.

 

 

프로세스 품질

미국 정부 회계국 발표에서 '1991년 전세계의 대형 프로젝트의 성공률이 1%' 라고 했었다네요. 과거자료를 검색해보면 2010년도 쯤에 20%~30%를 말하는 경우도 많습니다.

 

프로세스 품질은 개발을 위한 질서 있고 경험에 의한 규칙있는 인력, 기술, 절차, 도구가 어우러져 통합된 작업의 품질을 말합니다. 프로세스에 의해 소프트웨어의 품질을 높일 수 있습니다. 

 

“소프트웨어 시스템의 품질은 그것을 개발하는데 사용되는 프로세스의 품질에 좌우된다.”

by. Humphrey

 

소프트웨어 프로세스 평가 모델

- CMM

- SPICE Software Process Improvement and Capability dEtermination

 

소프트웨어의 품질

소프트웨어를 대하는 입장에 따라 품질에 대한 관점이 변할 수 있습니다.

 

효율성을 증진시키면 유지보수성이나 재사용성은 감소될 수 있고, 사용용이성을 높이면 효율성이 낮아질 수도 있습니다. 이처럼 서로 다른 품질 속성이 상충될 수 있습니다.

 

ISO 9126 

이러한 속성들이 상충되는 상황에서 고객 만족을 높이고자 하는 것이 소프트웨어 공학에서 연구하는 부분이기도 합니다.

 

 

품질

정확성

기능적으로 맞게 동작하고, 표준에 적합한 속성

요구 분석서의 기능과 일치하는지 점검

 

신뢰성

요구한 기능을 실패 없이 행할 수 있는 성질

오류에 비례

정확성을 위한 필요 조건

 

강인성

요구 명세에 표시하지 않은 상황 (오류 입력) 시 제대로 작동하는 성질

 

성능

수행 속도

알고리즘의 복잡도

시뮬레이션, 스트레스 테스트

 

사용 용이성

시스템을 친근하게 느낄 수 있는 성질

사용 대상에 따라 달라질 수 있음

사용자 인터페이스, Human factor

 

유지 보수성

보수성 : 정해진 기간에 소프트웨어 결함을 해결할 수 있는 성질

진화성 : 잠재적 발전 가능성

 

재 사용성

소프트웨어 부품 (라이브러리, 클래스 등) 의 성질

확장 가능성 - openness

적응성 - adaptability

이용 용이성 – closeness

 

생산성

생산 과정(process)에 크게 영향

개발 경험의 성숙도에 의해 좌우

생산성에 영향을 미치는 요소

- 프로그래머의 능력

- 팀 내의 의사 전달

- 제품의 복잡도

- 기술 수준

- 관리 기술

 

3. 소프트웨어 프로젝트

소프트웨어 프로젝트에는 라이프 사이클이 있습니다. 계획, 요구분석, 설계, 프로그래밍, 품질 보증, 설치 및 유지보수 등

 

현대에는 애자일 방법론이라는 것이 선택되고 있는 것 같습니다.

 

위키백과에 따르면, '애자일 소프트웨어 개발(Agile software development) 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다. 최근에는 애자일 게임 보급 등의 여파로 소프트웨어 엔지니어링 뿐 아니라 다양한 전문 분야에서 실용주의적 사고를 가진 사람들이 애자일 방법론을 적용하려는 시도를 하고 있다.' 이라고 설명되고 있는데요. 소프트웨어 공학에서는 전통적인 방식을 먼저 소개하고 있습니다. 소프트웨어 라이프 사이클과 다양한 소프트웨어 개발 모형은 전통적인 방식에 기반해서 나온 내용이지만, 애자일 개발 프로세스와 비교해보면 좋을 것 같습니다.

 

소프트웨어 라이프 사이클

 

계획

- 도메인 분석, 문제의 정의

 

요구분석 

- 요구 추출 및 분석 후 명세화

 

설계

요구가 가용 기술로 어떻게 구현되어야 하는지를 기술

- 시스템 엔지니어링 : 어떤 부분이 하드웨어, 소프트웨어가 돼야 하는지 결정.

- 소프트웨어 구조 : 시스템을 서브시스템으로 나누고 기능을 결정

- 서브시스템의 내부에 대한 상세 설계

- 사용자 인터페이스 설계

- 데이터베이스 설계

      

프로그래밍

- 설계를 토대로 프로그램 개발

 

품질 보증 

- 리뷰, 검증 / 테스트

 

설치 및 유지보수

 

반응형

 

 

4. 소프트웨어 개발 모형

 

소프트웨어 개발 모형은 다양합니다. 실정에 맞는 개발 팀의 모형의 정립이 필요합니다. 개발 모형을 당장 정립하기 어렵다면 참고해보는 것이 좋겠죠.

 

전통적으로 소개되는 소프트웨어 개발 모형에는 다음과 같은 것이 있습니다.

- 폭포수 모형

- 프로토타입 모형

- 점증적 모형

- 컴포넌트 기반 개발 모형

 

폭포수 모델/모형

폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌습니다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 시험, 소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이릅니다.

 

 

폭포수 모델/모형 특징

- 1970 년대 미 국방성 MIL-STD-2167, ISO12207 항공 방위 소프트웨어 개발 경험으로 습득한 모형

 

- 각 단계가 다음 단계 시작 전에 끝나야 함

  순서적 - 각 단계 사이에 중복이나 상호 작용이 없음

  각 단계의 결과는 다음 단계가 시작되기 전에 점검

  바로 전 단계로 피드백

 

- 단순하거나 응용 분야를 잘 알고 있는 경우 적합

  한번의 과정, 비전문가가 사용할 시스템 개발에 적합

 

- 결과물의 정의가 중요

 

- 단점

  처음 단계가 지나치게 강조되면 코딩, 테스트가 지연

  각 단계의 전환에 많은 노력

  프로토타입과 재사용의 기회가 줄어 듦

  소용없는 여러 문서를 생산할 가능성 있음

 

폭포수 모델/모형의 프로세스

 

단계명 - 수행(활동) 내용 > 산출물(결과물)

 

1. P 계획 - 문제의 정의, 타당성 분석, 비용, 일정 예측 > 계획서

2. R 요구 분석 - DFD(Data Flow Diagram), 자료 사전, 소단위 명세서 > 요구 분석서

3. D 설계 - 시스템 구조 설계, 프로그램 설계, UI 설계 > 구조 설계서, 상세 설계서

4. I 구현 - 프로그래밍, 단위 테스트 > 프로그램

5. T 시험 - 통합 시험, 기능 시험, 성능 시험 > 통합 프로그램

6. A 인수 / 설치 - 설치, 인수 시험 > 소프트웨어

 

프로토타입 모델/모형

시범 시스템의 적용

- 사용자의 요구를 더 정확히 추출

- 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작

 

프로토타입 도구

- 화면 생성기

- 비주얼 프로그래밍, 4 세대 언어 등

 

공동의 참조 모델 제공

 

개발 단계에서 유지 보수가 이루어 짐

 

단점

- 오해, 기대 심리 유발

- 관리가 어려움 (중간 산출물의 정의가 난해)

 

프로토타입 모델/모형 프로세스

 

점증적 모델/모형 | 나선형 모델 (Spiral Model)

소프트웨어의 기능을 나누어 단계적 개발

- 실패의 위험 부담을 줄여 대규모 시스템 개발에 적합

- 테스트 용이 

- 초기 시장형성 및 피드백

 

진화 단계

- 계획 수립 (planning) : 목표, 기능 선택, 제약 조건의 결정

- 위험 분석 (risk analysis) : 기능 선택의 우선 순위, 위험 요소의 분석

- 개발 (engineering) : 선택된 기능의 개발

- 평가 (evaluation) : 개발 결과의 평가

 

반복적인 개발 및 테스트로 강인성 향상

 

단점

- 관리가 중요

- 위험 분석이 중요

- 새로운 모형

 

컴포넌트 기반 개발 모형

Component Based Development

- 객체 지향 기술을 바탕으로 작성한 단위 프로그램들을 부품 (component)처럼 여기고, 이 부품들을 조립하여 소프트웨 어를 개발 

- UML (Unified Modeling Language)

- 공통의 인터페이스

- Java의 EJB

 

5. 소프트웨어 개발에 영향을 미치는 요소

의사 소통 - 문서화

소프트웨어를 만들 때 많은 의사 소통을 하게 될 텐데요. 문서화하는 것이 좋고, 혹은 문서로 커뮤니케이션을 하는 것이 좋습니다. 기록이 남지 않으면 올바른 방법과 방향으로 개발되고 있었던 것인지 확인할 수 없기 때문에 기록하고 문서화하는 것은 중요합니다.

 

프로젝트의 성격 – 응용 분야 / 크기 / 복잡도

 

프로그래머의 역량

 

관리 – 일정 / 예산 / 형상

 

팀의 프로젝트 경험

 

 

---

컴퓨터공학전공으로 대학 다닐 때 공부했던 소프트웨어 공학 내용의 일부를 되새기며 글을 작성했습니다. 도움이 되셨길 바랍니다. 틀린 내용이 있다면 지적해주시고, 응원을 해주신다면 좋아요 꾹! 광고 꾹! 클릭해주시면 감사하겠습니다.^^