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

정보처리기사 필기 - 4과목 소프트웨어 공학

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

112 소프트웨어와 시스템

① 소프트웨어의 개요

· 소프트웨어는 하드웨어를 동작시켜 사용자가 작업을 편하게 수행하도록 하는 프로그램과 자료구조 등을 총칭

· 소프트웨어는 프로그램 자체뿐만 아니라 프로그램의 개발, 운용 및 유지보수에 관련된 모든 문서와 정보를 포함 

※ 프로그램 : 작업 실행 시 요구되는 기능과 성능을 제공해주는 명령어들의 집합

※ 자료구조 : 기억공간 내에서 자료 표현이나 처리 방법, 자료 간의 관계 등을 나타내는 것

② 소프트웨어의 특징

· 상품성 : 개발된 소프트웨어는 상품화되어 판매됨

· 견고성 : 일부 수정으로 소프트웨어 전체에 영향을 줄 수 있음

· 복잡성 : 개발 과정이 복잡하고 비표준화되어 이해와 관리가 어려움

· 순응성 : 사용자의 요구나 환경 변화에 적절히 변경할 수 있음

· 비가시성 : 소프트웨어의 구조가 외관으로 나타나지 않고, 코드 속에 숨어 있음

· 비마모성 : 사용에 의해 마모되거나 소멸되지 않음

· 비제조성 : 하드웨어처럼 제작되지 않고 논리적인 절차에 맞게 개발됨

· 비과학성 : 소프트웨어 개발 자체는 수학적이거나 과학적인 것이 아니라 조직, 인력, 시간, 비용, 절차 등이 중심이 됨

③ 소프트웨어의 분류

· 기능에 의한 분류 : 소프트웨어의 기능에 따라 분류 → 시스템 소프트웨어와 응용소프트웨어

· 사용 분야에 의한 분류 : 소프트웨어가 사용되는 분야에 따라 분류 → 프로그래밍용, 문서 작성용, 통신용, 분산 처리용, 멀티미디어용, 소프트웨어 개발용, 인공지능용

· 개발 과정의 성격에 따른 분류 : 소프트웨어가 개발되는 과정의 성격에 따라 분류 → 프로토타입, 프로젝트 산출물, 패키지

· 정보처리 방법에 따른 분류 : 정보를 처리하는 방법에 따라 분류 → 일괄 처리 소프트웨어, 온라인 소프트웨어, 실시간 소프트웨어

※ 개발 과정의 성격에 따른 분류

· 프로토타입(Prototype) : 사용자의 요구 사항을 정확히 분석하고 쉽게 이해할 수 있도록 지원하는 견본품, 시제품

· 프로젝트(Project) 산출물 : 아직 상품화되지 않은 연구 과정에서 생산된 소프트웨어

· 패키지(Package) : 소프트웨어 개발이나 업무 처리를 지원하기 위해서 개발된 상품형 소프트웨어

④ 시스템

시스템은 공통의 목적이나 목표를 달성하기 위하여 여러 가지 상호 관련된 요소들을 유기적으로 결합한 것

· 소프트웨어는 독립적으로 존재할 수 없으므로 컴퓨터를 기반으로 하는 여러 시스템과 관련을 맺어 상호 동작함

· 시스템의 구성 요소

[그림 1] 시스템 구성 요소

· 입력(Input) : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것

· 처리(Process) : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것

· 출력(Output) : 처리된 결과를 시스템에서 산출하는 것

· 제어(Control) : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것

· 피드백(FeedBack) : 출력된 결과가 예쩡된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것

⑤ 소프트웨어 위기의 원인

소프트웨어 위기는 여러 가지 원이에 의해 소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생함을 의미

· 소프트웨어의 특징에 대한 이해 부족 : 물리적이지 않고 논리적인 소프트웨어의 특징을 이해 못함

· 소프트웨어의 관리 부재 : 소프트웨어에 대한 관리를 소홀히 하여 효율적인 자원 통제가 이루어지지 못함

· 프로그래밍에만 치중 : 소프트웨어의 품질이나 유지보수는 고려하지 않고, 프로그래밍만 잘하려고 집착함으로써 다양하고 복잡해지는 소프트웨어의 요구사항을 처리하지 못함

⑥ 소프트웨어 위기의 결과

· 개발 인력의 부족과 그로 인한 인건비 상승

· 성능 및 신뢰성 부족

· 개발 기간 지연 및 개발 비용 증가

· 유지보수가 어렵고, 이에 따른 비용 증가

· 소프트웨어의 생산성 저하

· 소프트웨어의 품질 저하

113 소프트웨어 공학 

① 소프트웨어 공학의 개념

· 소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이며 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상이 목적

· 소프트웨어 공학은 다음과 같이 여러 형태로 정의 가능

- IEEE의 소프트웨어 공학 표준 용어사전 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안

- Fairley : 지정된 비용과 기간 내에 소프트웨어를 체계적으로 생산하고 유지보수하는 데 관려된 기술적이고 관리적인 원리

- Boehm : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발, 운용, 유지보수하는 데 필요한 문서 작성 과정

· 소프트웨어 공학은 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것

· 소프트웨어 공학은 안정적이며 효율적으로 작동하는 소프트웨어를 생산하고, 유지보수 활동을 체계적이고 경제적으로 수행하기 위해 계층화 기술 사용

② 계층화 기술

계층화 기술은 관리자가 소프트웨어 개발 과정을 제어하고, 기술진이 고품질의 소프트웨어를 구축할 수 있도록 하는 기술을 의미하며, 계층화 기술에는 도구, 방법, 절차가 있음

[그림 2] 계층화 기술

· 도구(Tool) : 절차와 방법을 자동 또는 반자동으로 처리하는 기능을 제공하는 것으로, 대표적으로 CASE(Computer Aided Software Engineering)를 사용

· 방법(Method) : 소프트웨어를 구축하는 기술적인 방법을 제공

· 절차(Process) : 소프트웨어 공학의 기반이되는 것으로, 소프트웨어 개발에 사용되는 개발 방법과 도구가 사용되는 순서

계층화 기술들을 결합시켜 합리적이고 적절한 방법으로 소프트웨어를 개발하고 유지시키는 역할

③ 소프트웨어 공학의 기본 원치

· 현대적인 프로그래밍 기술을 계속적으로 적용해야 함

· 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함

· 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함

④ 소프트웨어 공학의 발전

⑤ 소프트웨어의 품질과 생산성

소프트웨어의 품질

소프트웨어의 품질은 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측정 가능한 기능 및 특성을  의미하며, 좋은 품질의 소프트웨어는 다음과 같은 특성을 갖음

· 사용자가 요구하는 대로 동작해야 함

· 하드웨어 자원을 효율적으로 이용할 수 있어야 함

· 일정 시간 내에 주어진 조건하에서 원하는 기능을 실행할 수 있어야 함

· 애매모호함이 없이 처리 절차에 맞게 수행되어 정확하게 결과가 산출되어야 함

· 소프트웨어의 개발, 유지보수 등이 초기 예상 비용 이내에서 수행되어야 함

· 적당한 사용자 인터페이스 제공으로 사용하기가 편리해야 함

· 유지보수가 용이하고 신뢰성이 높아야 함

· 잠재적인 에러가 최소화되어야 함

· 소프트웨어의 사용법, 구조의 설명, 성능, 기능 등이 이해하기 쉬워야 함

· 실행 속도가 빠르고, 기억 용량을 적게 차지해야 함

소프트웨어의 생산성

소프트웨어의 생산성은 투입된 비용, 노력 등에 대한 생산량을 의미하는 것으로, 생산성에 영향을 미치는 요소는 다음과 같음

· 개발자의 능력

· 원할한 의사 전달

· 프로젝트의 복잡도와 성격

· 기술 수준

· 관리 기술

114 소프트웨어 생명 주기

① 소프트웨어 생명 주기의 개요

· 소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

· 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 활동의 결과에 대한 산출물로 표현하며, 소프트웨어 수명 주기라고도 함

· 소프트웨어 생명 주기의 역할

- 프로젝트 비용 산정과 개발 계획을 수립할 수 있는 기본 골격이 됨

- 프로젝트 진행 방향을 명확하게 파악하게 함

- 용어 및 기술의 표준화를 가능하게 함

- 프로젝트 관리를 용이하게 함

- 여러 소프트웨어 간에 상호 일관성을 유지하게 함

② 일반적인 소프트웨어 생명 주기

정의 단계 → 개발 단계 → 유지보수 단계

정의단계

· '무엇'을 처리하는 소프트웨어를 개발할 것인지를 정의하는 단계로,관리자와 사용자가 가장 많이 참여하는 단계

- 타당성 검토 단계 : 개발할 소프트웨어가 법적, 경제적, 기술적으로 실현 가능성이 있는지를 조사하는 단계

- 개발 계획 단계 : 소프트웨어 개발에 사용될 자원과 비용을 측정하는 단계

- 요구사항 분석 단계 : 사용자가 요구한 문제를 보다 상세하고 정확히 분석하는 단계

개발 단계

· '어떻게'에 초점을 두고 실제적으로 소프트웨어를 개발하는 단계

- 설계 단계 : 소프트웨어의 구조, 알고리즘, 자료 구조 등을 작성하는 단계로, 프로그램 설계용 언어나 자연 언어 또는 도표로 표현

에러가 가장 많이 발생하는 단계

- 구현 단계 : 설계 단계에서 작성된 문서를 기초로 하여 코딩하고 번역하는 단계

- 테스트 단계 : 구현된 소프트웨어에 내재되어 있는 오류를 찾아주는 단계

유지보수 단계

· 소프트웨어를 직접 운용하며, '변경'에 초점을 두고 여러 환경 변화에 따라 소프트웨어를 적응 및 유지시키는 단계

· 소프트웨어 생명 주기 단계 중에서 시간과 비용이 가장 많이 듬

115 소프트웨어 생명 주기 모형1

① 소프트웨어 생명 주기의 개요

· 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라고 하며, 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임

· 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고, 개별적인 모형을 사용할 수도 있음

· 일반적으로 사용되는 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 4세대 모형 등이 있음

② 폭포수 모형

폭포수 모형은 폭포에서 한번 떨어진 물은 거슬러 올라갈 수 없듯이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 넘어갈 수 없는 방식

· 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로, 고전적 생명 주기 모형이라고도 함

· 소프트웨어 개발 과정의 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형

· 제품의 일부가 될 매뉴얼을 작성해야 함

· 다음 단계를 수행하기 위해 각 단계가 끝난 후에는 결과물이 정확하게 산출되어야 함

· 두 개 이상의 과정이 병행하여 수행되지 않음

개발 순서

타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수

장점

· 모형의 적용 경험과 성공 사례가 많음

· 단계별 정의가 분명하고, 전체 공조의 이해가 용이함

· 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시함

단점

· 개발 과정중에 발생하는 새로운 요구나 경험을 반영하기 어려우므로 처음부터 사용자들이 모든 요구사항들을 명확하게 제시해야 함

· 단계별로 오류 없이 다음 단계로 진행해야 하는데 현실적으로 오류 없이 다음 단계로 진행하기는 어려움

· 개발된 프로그램을 업무에 운용할 대 검출되지 않은 오류로 인하여 사용자들이 큰 인내심을 가져야 함

③ 프로토타입 모형

프로토타입 모형은 사용자의 요구 사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

· 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발

· 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 됨

· 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형

· 프로토타입은 요구 분석 단계에서 사용하게 되며, 프로토타입의 평가가 끝나고 개발이 승인되면 다른 모형을 이용하여 본격적으로 개발이 이루어짐

· 소프트웨어 생명주기에서 유지보수가 없어지고, 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있음

개발 순서

[그림 3] 프로토타입 모형 개발 순서

장점

· 요구사항을 충실히 반영하며, 요구사항의 변경이 용이

· 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있음

· 프로토타입은 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공

단점

· 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와의 차이가 발생할 수 있어 사용자에게 혼란을 줄 수 있음

· 단기간에 제작해야 하기 때문에 비효율적인 언어나 알고리즘을 사용할 수 있음

116 소프트웨어 생명 주기2

① 나선형 모형

나선형 모형은 보헴이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

· 나선형을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로(프로토타입을 지속적으로 발전시켜) 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모델

· 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 함

개발 순서

① 계획 및 정의(Planing) : 개발 목적, 제약 조건 등을 설정

② 위험 분석(Risk Analysis) : 위험 요소를 분석하고, 기능 선택의 우선순위를 지정

③ 공학적 개발(Engineering) : 개선된 한 단계 높은 수준의 프로토타입을 개발

④ 고객 평가(Customer Evaluation) : 개발된 결과(프로토타입)을 평가

장·단점

· 가장 현실적인 모형으로, 대규모 프로젝트나 큰 시스템에 적합

· 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항 첨가 가능하고 정밀하며 유지보수 과정이 필요 없음

· 위험 분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로서 완성도 높은 소프트웨어를 만들 수 있음

· 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 발생함

· 비교적 최신 기법이므로 폭포수 모형이나 프로토타입 모형보다 널리 사용되지 않음

② 4GT 모형

4GT 모형은 사용자와 개발자가 쉽게 접근하고 사용할 수 있는 4세대 언어를 이용하여 개발자가 조사한 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형

· 설계 단계를 축소하고, 요구 분석 단계에서 구현 단계로 전환할 수 있는 비절차적 모형

개발 순서

요구사항 수집 → 설계 전략 → 4세대 언어를 이용한 구현 → 제품화

장·단점

· 설계 단계 단축 가능

· 4세대 언어를 사용하므로 원시 코드를 자동으로 생성함

· 중·소형 소프트웨어 개발에 사용하면 개발 시간이 감소되지만 대규모 소프트웨어 개발에서는 자동화로 인해 단축된 시간보다 분석, 설계 단계 등에서 더 많은 시간을 필요로 함

출처 : 2017 시나공 정보처리기사 필기