- 하드웨어를 동작시켜 사용자가 작업을 편리하게 수행하도록하는 프로그램과 자료구조
- 프로그램 개발, 운용, 유지보수 관련된 모든 문서와 정보를 포함
- 상품성 : 개발된 소프트웨어는 상품화되어 판매된다.
- 견고성 : 일부 수정으로 소프트웨어 전체에 영향을 줄 수 있다.
- 복잡성 : 개발과정이 복잡, 비표준화
- 순응성 : 사용자의 요구나 환경 변화에 적절히 변경
- 비가시성 : 소프트웨어 구조는 외관으로 나타나지 않고 코드로 숨어 있다.
- 비마모성 : 마모되거나 소멸되지 않는다.
- 비제조성 : 하드웨어처럼 제작이 아니라 논리적인 절차에 맞게 개발
- 비과학성 : 과학적이 아니라 조직, 인력, 시간, 절차 등 중심
분류
- 기능에 의한 분류 : 시스템, 응용
- 사용 분야에 의한 분류 : 프로그래밍, 문서, 통신, 분산처리, 멀티미디어, 개발, 인공지능
- 개발 과정 성격에 따른 분류 : 프로토타입, 프로젝트 산출물, 패키지
- 정보처리 방법에 따른 분류 : 일괄처리, 온라인, 실시간
시스템 구성요소
- 입력 : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
- 처리 : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
- 출력 : 처리된 결과를 시스템에서 산출하는 것
- 제어 : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
- 피드백 : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리 하는 것
위기
여러가지 원인해 의해 개발 속도가 하드웨어의 개발속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생함을 의미
- 소프트웨어의 특징에 대한 이해 부족 : 물리적이지 않고 논리적인 소프트웨어 특징을 이해하지 못함
- 소프트웨어의 관리 부재 : 소프트웨어에 대한 관리를 소홀히 하여 효율적인 자원 통제가 이루어지지 못했다.
- 프로그래밍에만 치중 : 소프트웨어 품질이나 유지보수는 고려하지 않고, 프로그래밍만 하려하므로 다양하고 복잡해지는 소프트웨어의 요구사항을 처리하지 못함
- 개발 인력 부족과 그로 인한 인건비 상승
- 성능 및 신뢰성 부족
- 개발 기간 지연 및 개발 비용 증가
- 유지보수가 어려워져 비용 증가
- 소프트웨어의 생산성 저하
- 소프트웨어의 품질 저하
소프트웨어 공학
- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
- 소프트웨어의 품질과 생산성 향상을 목적
- IEEE 정의 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
- Fairley 정의 : 지정된 비용과 기간 내의 소프트웨어를 체계적으로 생산하고 유지보수하는 데 관련된 기술적이고 관리적인 원리
- Boehm 정의 : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발 운용, 유지보수하는 데 필요한 문서 작성 과정
- 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것
- 계층화 기술을 사용한다.
계층화 기술
도구, 방법, 절차가 있다.
- 도구 : Tool 절차와 방법을 자동 또는 반자동으로 처리하는 기능을 제공, 대표적으로 CASE를 사용
- 방법 : Method 소프트웨어를 구축하는 기술적인 방법을 제공
- 절차 : Process
- 소프트웨어 개발에 사용되는 개발 방법과 도구가 사용되는 순서
- 계층화 기술들을 결합시켜 합리적이고 적절한 방법으로 소프트웨어를 개발하고 유지
기본 원칙
- 현대적인 프로그래밍 기술을 계 속적으로 적용해야한다.
- 개발된 소프트웨어 품질이 유지되도록 지속적으로 검증해야한다.
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야한다.
발전 과정
- 1960 : 소프트웨어 공학의 시작, 구조적 프로그래밍
- 1970 : 구조적 분석/설계 개념 도입, 상품화
- 1980 : 하드웨어 가격 하락
- 1985~ : 객체지향 기술 사용, CASE 등의 활용, 재공학
품질과 생산성
품질
- 사용자가 요구하는 대로 동작
- 하드웨어 자원을 효율적으로 이용
- 일정 시간 내에 주어진 조건하에서 원하는 기능을 실행
- 처리 절차에 맞게 수행되어 정확하게 결과가 산출
- 소프트웨어의 개발, 유지보수 등이 초기 예상 비용 이내에서 수행
- 적당한 사용자 인터페이스를 제공해 사용하기가 편리해야한다.
- 유지보수가 용이하고 신뢰성이 높아야한다.
- 에러가 최소화
- 소프트웨어 사용법, 구조의 설명, 성능, 기능이 이해하기 쉬어야한다.
- 실행 속도가 빠르고, 기억 용량을 적게 차지해야 한다.
생산성
투입된 비용, 노력에 대한 생산량을 의미
- 개발자의 능력
- 원활한 의사 전달
- 프로젝트의 복잡도와 성격
- 기술 수준
- 관리 기술
생명 주기
- 소프트웨어 수명 주기
- 소프트웨어 개발 방법론의 바탕
- 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 단계별로 나눈 것
- 프로젝트 비용 산정과 개발 계획을 수립할 수 있는 기본 골격
- 프롲게트 진행 방향을 명확하게 파악
- 용어 및 기술의 표준화를 가능하게 한다.
- 프로젝트 관리를 용이하게 한다.
- 여러 소프트웨어 간 상호 일관성을 유지하게 한다.
단계
정의 단계, 개발단계, 유지보수 단계로 나뉨
정의 단계
- 소프트웨어를 개발할 것인지 정의하는 단계
- 관리자와 사용자가 가장 많이 참여하는 단계
- 타당성 검토단계, 개발 계획단계, 요구사항 분석 단계로 나뉨
개발 단계
- 실제적으로 소프트웨어를 개발하는 단계
- 설계 단계 : 구조, 알고리즘, 자료구조를 작성하는 단계로 에러가 가장 많이 발생
- 구현 단계 : 설계 단계에서 작성된 문서를 기초로 하여 코딩하고 번역하는 단계
- 테스트 단계 : 구현된 소프트웨어에 내재되어 있는 오류를 찾아주는 단계
유지보수 단계
- 소프트웨어를 적응 및 유지시키는 단계
- 소프트웨어 생명 주기 단계 중에서 시간과 비용이 가장 많이 든다.
정의 : 개발 계획, 요구사항 분석 설계 : 구조, 알고리즘 구현 : 코딩 테스트 : 오류 검출
생명 주기 모형
폭포수 모형
- 소프트웨어 개발이 각 단계를 확실히 매듭짓고 그 결과를 철저히 검토하여 승인한 뒤 다음 단계로 진행
- 이전 단계로 넘어갈 수 없는 방식
- 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
- 고전적 생명 주기 모형
- 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
- 제품의 일부가 될 매뉴얼을 작성해야 한다.
- 타당성 검토 => 계획 => 요구 분석 => 설계 => 구현(코딩) => 테스트(검사) => 유지보수
- 모형 적용 경험과 성공 사례가 많다.
- 단계별 정의가 분명하고 전체 공조의 이해가 용이하다.
- 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시한다.
- 개발 중 발생하는 새로운 요구나 경험을 반영하기 어려워 처음부터 사용자가 모든 요구사항을 명확하게 제시해야한다.
- 오류 없이 다음 단계로 진행해야 하는데 현실적으로 힘들다.
- 업무에 운용할 때 검출되지 않은 오류가 발생할 수 있다.
프로토타입 모형
- 사용자의 요구사항을 정확하게 파악하기 위해 프로토타입(견본품)을 만들어 최종 결과물을 예측하는 모형
- 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
- 폭포수 모형의 단점을 보완
- 프로토타입은 요구 분석 단계에서 사용한다.
- 소프트웨어 생명주기에서 유지보수가 없어지고, 개발 단계 안에서 유지 보수가 이뤄지는 것으로 볼 수 있다.
- 요구 수집 => 빠른 설계 => 프로토타입 구축 => 고객 평가 => 프로토타입 조정 => 구현
- 요구사항을 충실히 반영하며 요구사항의 변경이 용이
- 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.
- 프로토타입은 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공한다.
- 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와의 차이가 발생할 수 있다.
- 단기간 제작해야되기 때문에 비효율적 언어나 알고리즘을 사용할 수 있다.
나선형 모형
- Boehm이 제안한 것으로 폭포수와 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
- 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
- 점진적 모형
- 소프트웨어를 개발하면서 발생하는 위험을 관리하고 최소화하는 것을 목적으로 한다.
- 계획 및 정의 => 위험 분석 => 공학적 개발 => 고객평가의 반복
- Planning => Risk Analysis => Engineering => Customer Evalutation
- 가장 현실적인 모형
- 대규모 프로젝트나 큰 시스템에 적합하다.
- 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 추가할 수 있고, 정밀하며 유지보수가 필요 없다.
- 위험성 평가에 크게 의존하기 때문에 발견하지 못하면 문제가 발생한다.
- 비교적 최신 기법이라 널리 사용되지 않는다.
4GT 모형
- 사용자와 개발자가 쉽게 접근하고 사용할 수 있는 4세대 언어를 이용하여 개발자가 조사한 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형
- 설계 단계를 축소하고 요구 분석단계에서 코딩단계로 전환할 수 있는 비절차적 모형
- 요구사항 수집 => 설계 전략 => 4세대 언어를 이용한 구현 => 제품화
- 중소형 소프트웨어 개발에는 시간이 감소하지만 대규모에서는 자동화로 인해 분석 설계 단계에서 더 많은 시간이 필요
프로젝트 관리
- 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 활동
- 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등 작업을 통제하는 것
- 소프트웨어 생명 주기의 전 과정에 걸쳐 진행된다.
관리 대상
- 계획관리 : 프로젝트 계획, 비용산정, 일정 계획, 조직 계획
- 품질관리
- 위험관리
3대 요소
- 사람 : People 프로젝트 관리에서 가장 기본이 되는 인적자원
- 문제 : Problem 사용자 입장에서 문제를 분석하여 인식
- 프로세스 : Process 소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조
구성 단계
- 프로젝트 계획 수립
- 프로젝트 가동
- 프로젝트 통제
- 프로젝트 종료
프로젝트 계획 수립
- 프로젝트가 수행되기 전에 소프트웨어 개발 영역 결정, 필요한 자원, 비용, 일정 등을 예측하는 작업
- 관리자가 합리적으로 예측할 수 있도록 프레임워크 제공
- 소프트웨어 개발 과정에서 발생할 수 있는 위험성 최소화
- 계획 수립 후에는 시스템 정의서와 프로젝트 계획서가 산출
- 프로젝트 관리자의 임무
소프트웨어 개발 영역 결정
- 프로젝트 계획 수립의 첫 번째 업무
- 개발될 소프트웨어의 영역을 결정
- 주요 요소 : 처리될 데이터, 소프트웨어에 대한 기능, 성능, 제약 조건, 신뢰도, 인터페이스 등
- 인터페이스
- 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨러를 실행하는 프로세서나 하드웨어
- 운영체제, 서브루틴 패키지와 같이 새로운 소프트웨어에 연결되어야 하는 소프트웨어
- 키보드나 기타 I/O 장치를 통해 소프트웨어를 사용하는 사람
- 순서적인 연산에 의해 소프트웨어를 실행하는 절차
자원 추산
- 소프트웨어 개발에 필요한 자원을 예측하는 것
- 인적자원, 재사용 소프트웨어자원, 환경 자원
소프트웨어 프로젝트 추산
- 프로젝트 수행에 필요한 비용을 예측하는 것
프로젝트 계획 수립시 고려사항
- 프로젝트 복잡도
- 프로젝트 규모
- 구조적 불확실성의 정도
- 과거 정보의 가용성
- 위험성
소프트웨어 프로젝트 추산
- 비용을 예측하는 작업
- 가장 어렵고 오차 발생이 심한 작업
프로젝트 비용 결정 요소
프로젝트 요소
- 제품의 복잡도
- 시스템의 크기
- 요구되는 신뢰도 : 일정한 기간 내에 주어진 조건 하에서 필요한 기능을 수행하는 정도
자원 요소
- 인적 자원 : 관리자, 개발자의 자질
- 하드웨어 자원
- 소프트웨어 자원 : 개발 지원 도구
생산성 요소
- 개발자의 능력
- 개발 기간 : 개발 기간이 길어질수록 개발 비용이 적어짐
비용 산정 기법
하향식
전문가 감정 기법
- 경험이 많은 두 명 이상의 전문가에게 비용 산정 의뢰
- 개인적이고 주관적
- 편리하고 신속하게 비용 산정
- 의뢰자에게 신뢰를 얻을 수 있음
델파이 기법
- 전문가 감정 기법의 주관적 편견을 보완하기 위함
- 많은 전문가의 의견을 종합해 선정하는 방법
- 한 명의 조정자와 여러 명의 전문가
상향식
프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
LOC 기법
- 원시 코드 라인수 기법
- 소프트웨어 각 기능의 원시 코드 라인 수와 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
- 측정 이 용이하고 이해하기 쉬워 가장 많이 사용된다.
- 예측치 = (낙관치 + (4 X 기대치) + 비관치) / 6 = (a + 4m + b) / 6
- ManMonth = 개발 기간 X 투입 인원 = LOC / 1인당 월평균 코딩량
- 개발 비용 = ManMonth X 1인 인건비
- 개발 기간 = ManMonth / 투입 인원
- 생산성 = LOC / ManMonth
개발 단계별 인원수 기법
- Effort Per Task
- 각 기능을 구현시키는데 필요한 ManMonth를 생명 주기의 각 단계별로 산정
- LOC보다 정확하다.
수학적 산정 기법
- 상향식 비용 산정 기법
- 경험적 추정 모형 = 실험적 추정 모형
- COCOMO, Putnam, FP 모형
COCOMO 모형
- COnstructive COst MOdel
- Boehm이 제안
- 원시 프로그램 규모인 LOC에 의한 비용 산정 기법
- 개발할 소프트웨어의 규모를 예측한 후 소프트웨어의 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 구한다.
- 비용 견적의 강도 분석 및 유연성이 높아 널리 사용된다.
- 같은 규모의 프로그램이라도 성격에 따라 비용이 다르게 산정된다.
- 비용 산정 결과는 ManMonth로 나타낸다.