소프트웨어 공학

소프트웨어 정의

-기계에서 효율적으로 작동하는 신뢰성 있는 소프트웨어를 경제적으로 획득하기 위해 적절한 공학적 원리를 수립하여 활용하는 것(비우어)

-소프트웨어의 개발과 운용, 유지보수에 대한 체계적(Systematic), 훈련된(Disciplined), 계량적(Quantifiable),접근방식의 적용(IEEE)

 

소프트웨어에 대한 이해

-프레스만

>실행되면서 원하는 기능이나 함수, 성능을 제공해 주는명령어들(컴퓨터 프로그램)

>프로그램이 데이터를 적절하게 처리할 수있게 해주는 자료구조

>프로그램의 사용이나 운영을 나타내는 하드카피나 가상의 형태의 문서

 

소프트웨어 구성요소

- 프로그램 / 자료구조 / 문서

 

소프트웨어의 특징과 분류

-비가시성 : 완성되기 전까지 전체를 파악하기 힘듦

-변경성 : 완성되기 전까지 계속 바뀌며, 완성된 이후에도 변경됨

-복제성 : 무한 복제 가능, 닳거나 없어지지 않음

-복잡성 : 개발과정이 대단히 복잠함

 

-시스템 소프트웨어 : 다른 프로그램의 수행을 지원해주기 위해 만들어진 소프트웨어

-애플리케이션 소프트웨어 : 특수한 업무상의 요구를 해결해주며, 비즈니스 처리 또는 관리/기술 측면에서의 의사결정을 쉽게 처리할 수 있도록 사업상 또는 기술적 데이터를 처리하는 소프트웨어

-공학.과학 소프트웨어 : "수 처리" 알고리즘이 특징이며, 공학 및 과학적 연구를 위해, 실시간 처리가 가능한 소프트웨어

-임베디드 소프트웨어 : 생산품이나 시스템에 내장되어 있으면서 사용자나 시스템 자체를 위한 특징이나 기능을 구현하는 데 사용

-응용 소프트웨어 : 인터넷을 위해 개발된 하이퍼텍스트 이거나, 웹으로 가동되는 응용시스템을 위한 소프트웨어

-인공지능 소프트웨어 : 계산이나 일반적인 알고리즘으로 분석할 수 없는 복잡한 문제를 해결하기 위해 비수치적 알고리즘을 사용

-생산라인 소프트웨어 : 제조과정에 필요한 소프트웨어

 

소프트웨어의 탄생과 폐기

-사람처럼 sw도 태어나고 사라짐(Life Cycle)

 

유지보수의 종류

-안전 유지보수 : 새로운 요구사항을 추가하거나 시스템의 구조와 성능을 게선하여 시스템을 완전하게 만드는 목적으로 수행

-수정 유지보수 : 요구사항의 오류나 설계 및 구현 상의 오류를 개선할 목적으로 수행함

-적응 유지보수 : 시스템의 플랫폼 변경과 같은 새로운 환경으로의 적응을 목적으로 수행

-예방 유지보수 : 시스템의 잠재적인 결함을 사전에 방지하기 위한 목적으로 수행

 

인하우스 및 SI 프로젝트

 

인하우스 개발 프로젝트

-조직 내부 자체 인력으로 SW를 개발

>소규모 프로젝트 추진 시

>프로젝트 계약과정이 불필요

>일부 필요 시 개발자 혹은 전문가를 초빙

 

SI 프로젝트

-대규모 프로젝트 혹은 위험한 프로젝트의 경우 외부 전부 SI업체에 맡겨 프로젝트 향

>REF 제시

>업체를 선정하기 위한 과정이 필요

>선정된 엄체와 프로젝트에 대한 계약 필요

 

패키지 도입

-조직 레벨에서 활용할 패키지의 도입

>ERP를 도입하는 프로젝트가 예시

>이미 만들어진 기능을 대부분 활용혹은 커스터마이징을 통해 기능을 보완

>전혀 변경이 없이 활용하기도 함

 

---

 

 

소프트웨어 프로세스의 중요성

 

개발의 목표

-정해진 기간 내에, 주어진 예산을 이용해 사용자가 원하는 좋은 품질로 개발하는 것

계속되는 실패의 원인

-정해진 기간 내에 고품질의 소프트웨어를 개발하는 것이 점점 더 어려워짐

-요구사항이 복잡해지고 규모가 점점 커짐

 

소프트웨어의 생명주기

-SW를 어떻게 개발할 것인가에 대한 전체적인 큰 흐름을 나타내는 추상적 표현

 

주먹구구식 개발 모델

-요구사항 분석, 설계 단계 없이 일단 개발에 들어간 후 만족할 떄까지 수정작업 수행

 

단점

-정해진 개발 순서가 없기 때문에 계획이 정확하지는 않음

-관리자는 프로젝트 진행 상황 파악에 어려움

-개발 문서가 없기 떄문에 개발 및 유지보수에 어려움

 

폭포수 모델

-순차적으로 소프트웨어를 개발하는 전형적인 개발 모델

-대부분의 소프트웨어 개발 프로젝트의 기본적인 모델이며 가장 많이 사용되는 모델

-소프트웨어 개발의 전 과정을 나누어 체계적이고 순차적으로 접근하는 방법

-개발 방법 : 요구사항 분석, 설계, 구현, 테스팅, 유지보수

 

 

 

1단계 : 요구사항 분석

-what

>사용자 요구나 주어진 문제를 정확히 분석 이해하는 과정

>구현 시스템의 기능, 목표, 제약사항 등을 정확히 파악

>발주자와 개발자가 요구분석 사항에 동의하여야 다음 단게호 진입

 

-요구사항 명세서

>요구 부석 단계의 결과물

>사용자와 개발자의 의사소통 수단으로 사용

 

2단계 : 설계

-How

>분석된 결과를 어떻게 프로그램으로 구성할 것인가?

>솔루션에 집중

 

-설계 내용

>시스템 구조 설계 : 시스템을 구성하는 모듈의 관게와 구조

>프로그램 설계 : 각 모듈 내에서의 알고리즘을 설계

>사용자 인터페이스 설계 : 사용자에게 보이는 부분을 설계

 

-설계 명세서

>설게 단계의 결과물

>소프트웨어 구조를 기술한 것으로모듈의 기능과 모듈 사이의 관계를 기술

 

3단계 : 구현

-'Do it:'단계

-이전 단계의 모듈 설계를 기준으로 프로그래밍을 함

-결과물 : 소스 코드

 

4단계 : 테스트

-프로그램이 입력에 따라 요구되는 결과대로 작동하는지, 내부적 이상 여부 및 오류 발견을 위해 수행

-테스트 계획을 세운 후 문서화

 

5단계 : 유지보수

-개발된 소프트웨어의 변경사항을 수정하는 것

-수정 유지보수, 적응 유지보수, 기능 추가 유지보수 등이 있음

 

단점

-앞단계가 완료될 때까지 다음 단계들은 대기상태여야 함

-실제 작동되는 시스템을 개발 후반부에 확인 가능하기 떄문에 고객이 요구사항 확인하는데 많은 시간이 걸림

 

원형 모델

-폭포수 모델의단점을 보완한 모델

-점진적으로 시스템을 개발해 나가는 접근 방법

-원형을 만들어 고객과 사용자가 함꼐 평가한 후 개발 될 소프트웨어의 요구사항을 정제하여 보다 완전한 요굿항 명세서를 완성함

 

1단계 :  요구사항 정의

-고객의 일부 요구사항 또는 불완전한 요구 사항으로부터 제품의 윤곽을 잡음

 

2단계 : 원형 설계

-주어진 요구사항을 기반으로 빠른 설계를 함

-주로 제품의 사용자 인터페이스에 초점을 맞춤

 

3단계 : 원형 개발

-설게된 원형을 RAD도구 등을 사용하여 빠르게 구현함

-고객이 요구하는 기능을 구현하고 필요한 요소를 파악하는데 중점을 둠

-프로그램의 신뢰도나 품질이 아니라 간으한 빨리 원형을 구현하는 것이 목적

 

4단계 : 고객 평가

-고객과 개발자가 함께하는 중요한 단계 

-고객 요구사항을 정확하게 규명하기 위해 원형에 대한 사용 및 평가시간을 충분히 제공

-개발될 소프트웨어의 요구사항 정제에 중요한 정보로 활용

 

5단계 : 원형 정제

-원형이 어떻게 수정되어야 할지를 결정함 

-원형 개발과 검증, 요구사항 정제의 순환을 반복하여 추가적인 정보를 통해 요구사항을 완성해 나감

 

장점

-사용자의 의견 반영이 잘됨

-사용자가 더 관심을 가지고 참여할 수 있고, 개발자는 요구를 더 잘 받아드릴 수 있음

 

단점

-프로토타입이 최종 결과라고 믿고 수프트웨어 개발이 완성되리라는 사용 자의 오해, 기대심이 유발

-개발자 관점 : 관리가 어려움(중간 산출물 정의가 난해)

 

적용

-개발 착수 시점에 사용자 요구가 불투명할 때

-실험적으로 실현 가능성을 타진해 보고 싶을 떄

-혁신적인 기술을 사용해 보고 싶을 때

 

나선형 모델

-폭포수 모형과 원형 모형의 장점을 수용하고 위험 분석을 추가한 점증적 개발 모델

-프로젝트 수행 시 발생하는 위험을 관리하고 최소화 하려는 것이 목적

-여러 개의 작업 영역으로 구분

-가장안쪽 타원부터 개념적 개발 프로젝트, 실제 제품 개발 프로젝트, 제품 향상 프로젝트, 유지보수 프로젝트

-단계가 명확히 구분되지 않고, 엔지니어가 프로젝트 성격이나 진행상황에 따라 단계 구분

 

1단계 : 계획 및 정의 단계

-개발자는 고객으로부터 요구사항을 수집

-개발자는 시스템의 성능, 기능을 비롯한 시스템의 목표를 규명하고 제약 조건을 파악

-목표와 제약 조건에 대한 여러 대안들을 고려하고 평가함으로써 프로젝트 위험의 원인을 규명 가능

 

2단계 : 위험 분석 단계 

-초기의 요구 사항을 토대로 위험 규명

-위험에 대한 평가가 이루어지면 프로젝트를 계속 진행할 것인지, 중단할 것인지를 결정

 

3단계 : 개발 단계

-시스템의 대한 생명주기 모델을 선택하거나 원형 또는 최종적인 제품을 만드는 단계

 

4단계 : 고객 평가 단계
-구현된 소프트웨어를 고객이나 사용자가 평가함

-고객의 피드백을 얻는 데 필요한 작업이 포함 

-다음 단게에서 고객의 평가를 반영할 수 있는 자료 획득 가능

 

적용 가능한 경우

-고비용의 시스템 개발

-시간이 많이 소요되는 큰 시스템 구축 시 유용

 

장점

-프로젝트의 모든 단계에서 기술적인 위험을 직접 고려할 수 있어 사전에 위험 감소 가능

-테스트 비용이나 제품 개발 지연 등의 문제 해결 가능

 

단점

-개발자가 정확하지 않은 위험 분석을 했을 경우 심각한 문제 발생

-폭포수, 원형 모델에 비해 상대적으로 복잡하여 프로젝트 관리 자체가 어려울 수 있음