: 소프트웨어(S/W, Software)는 하드웨어를 동작시켜 사용자가 작업을 편리하게 수행하도록 하는 프로그램과 자료 구조 등을 총칭
- 특징
1. 상품성: 개발된 소프트웨어는 상품화되어 판매된다.
2. 견고성: 일부 수정으로 소프트웨어 전체에 영향을 줄 수 있다
3. 복잡성: 개발 과정이 복잡하고, 비표준화 되어 이해와 관리가 어렵다
4. 순응성: 사용자의 요구나 환경에 적절히 변경할 수 있다
5. 비가시성: 소프트웨어의 구조가 외관으로 나타나지 않고, 코드 속에 숨어있다
6. 비마모성: 사용에 의해 마모되거나 소멸되지 않는다
7. 비제조성: 하드웨어처럼 제작되지 않고, 논리적인 절차에 맞게 개발된다
8. 비과학성: 조직, 인력, 시간, 비용, 절차 등이 중심이 된다
- 소프트웨어의 분류
1. 기능에 의한 분류
: 시스템 소프트웨어와 응용 소프트웨어로 분류
2. 사용 분야에 의한 분류
: 프로그래밍용, 문서작성용, 통신용, 분산처리용, 멀티미디어용, 소프트웨어 개발용 등
3. 개발 과정의 성격에 따른 분류
: 프로토타입(Prototype), 프로젝트(Project) 산출물, 패키지(Package)
4. 정보처리 방법에 따른 분류
: 일괄 처리 소프트웨어, 온라인 소프트웨어, 실시간 소프트웨어 등
- 시스템
: 공통의 목적이나 목표를 달성하기 위하여 여러 가지 상호 관련된 요소들을 유기적으로 결합한 것
: 시스템의 구성요소에는 입력, 처리(제어), 출력, 피드백(출력 -> 입력)
: 소프트웨어는 독립적으로 존재할 수 없으므로 컴퓨터를 기반을 하는 여러 시스템과 관련을 맺어 상호 작용한다
- 소프트웨어 위기
: 여러가지 원인에 의해 소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생
- 위기의 원인
: 소프트웨어 특징에 대한 이해부족
: 소프트웨어의 관리 부재
: 프로그래밍에만 치중
- 위기의 결과
: 개발 인력 부족과 인권비 상승, 성능 및 신뢰성 부족
: 개발 기간 지연 및 비용 증가, 유지보수가 어렵고, 이에 따른 비용 증가
: 소프트웨어 생산성 저하, 품질 저하
2. 소프트웨어 공학(SE; Software Engineering)
: 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
: IEEE의 소프트웨어 공학 표준 용어 사전 - 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
: Fairly - 지정된 비용과 기간 내에 소프트웨어를 체계적으로 생간하고 유지 보수하는데 관련된 기술적이고 관리적인 원리
: Boehm - 과학적인 지식을 소프트웨어 설계와 제작에 응용, 이를 개발 운용, 유지 보수하는데 필요한 문서 작성 과정
: 소프트웨어 공학은 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것
- 계층화 기술
: 관리자가 소프트웨어 개발 과정을 제어하고, 기술진이 고품질의 소프트웨어를 구축할 수 있도록 하는 기술을 의미. 계층화 기술에는 도구, 방법, 절차가 있다.
1. 도구(Tool): 절차와 방법을 자동 또는 반자동으로 처리하는 기능을 제공하는 것, 대표적으로 CASE(Computer Aided Software Engineering) 사용
2. 방법(Method): 소프트웨어를 구축하는 기술적인 방법을 제공하는 것
3. 절차(Process): 소프트웨어 공학의 기반이 되는 것으로, 소프트웨어 개발에 사용되는 개발방법과 도구가 사용되는 순서를 의미, 계층화 기술들을 결합시켜 합리적이고 적절한 방법으로 소프트웨어를 개발하고 유지시키는 역할을 한다
- 소프트웨어 공학의 기본원칙
1. 현대적인 프로그래밍 기술을 계속적으로 적용
2. 개발된 소프트웨어의 품질이 유지되도록 지속적 검증
3. 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지
- 소프트웨어의 품질
: 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측정 가능한 기능 및 특성을 의미
: 사용자가 요구하는 대로 동작해야 한다
: 하드웨어 자원을 효율적으로 이용할 수 있어야 한다
: 일정 시간 내에 주어진 조건하에서 원하는 기능을 실행할 수 있어야 한다
: 애매모호함이 없이 처리 절차에 맞게 수행되어 정확하게 결과가 산출되어야 한다
: 소프트웨어의 개발, 유지보수 등이 초기 예상 비용 이내에서 수행되어야 한다
: 적당한 사용자 인터페이스 제공으로 사용하기 편리해야 한다
: 유지보수가 용이하고, 신뢰성이 높아야 하고, 에러가 초기화되어야 한다
- 소프트웨어의 생산성
: 투입된 비용, 노력 등에 대한 생산량을 의미
- 생산량에 영향을 미치는 요소
: 개발자의 능력, 원활한 의사전달, 프로젝트의 복잡도와 성격, 기술 수준, 관리 기술
3. 소프트웨어 생명 주기(Software Life Cycle)
: 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
- 생명주기의 역할
: 비용 산정과 개발 계획을 수립할 수 있는 기본 골격이 된다
: 진행 방향을 명확하게 파악하고, 용어 및 기술의 표준화를 가능하게 함
: 프로젝트 관리를 용이하게 하고, 상호 일관성을 유지하게 함
- 생명 주기의 단계
1. 정의 단계
: '무엇'을 처리하는 소프트웨어를 개발할 것인지 정의하는 단계
: 타당성 검토 단계, 개발 계획 단계, 요구사항 분석 단계
2. 개발 단계
: '어떻게'에 초점을 두고 실질적으로 소프트웨어를 개발하는 단계
: 설계 단계, 구현 단계, 테스트 단계
3. 유지보수 단계
: '변경'에 초점을 두고 여러 환경 변화에 따라 소프트웨어를 적응 및 유지시키는 단계
: 생명 주기 단계중에서 가장 시간과 비용이 많이 드는 단계
4. 소프트웨어 생명 주기 모형
1. 폭포수 모형(Waterfall Model)
: 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하여, 이전 단계로 넘어갈 수 없는 방식
: 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 모형
- 장점
: 모형의 적용 경험과 성공사례가 많고, 단계별 정의가 분명, 전체 공조의 이해가 용이
: 단계별 산출물이 정확하여 개발 공정 기준점을 잘 제시함
- 단점
: 개발 과정중에 발생하는 새로운 요구를 반영하기 어렵다
: 단계별로 오류 없이 다음 단계로 진행해야 하는데, 현실적으로 오류없이 진행하기 어렵
2. 프로토타입 모형(Prototype Model, 원형모형)
: 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어의 견본품을 만들어 최종 결과물을 예측하는 모형
: 프로토타입은 요구 분석 단계에서 사용하게 되며, 프로토타입의 평가가 끝나고 개발이 승인 되면 다른 모형을 이용하여 개발이 본격적으로 이루어짐
: 요구사항을 충실히 반영하고, 변경이 용이
: 최종 결과물이 만들어지기 전에 의뢰자가 모형을 볼 수 있음
- 단점
: 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와 차이가 발생할 수 있어 사용자에게 혼란을 줄 수 있음
: 단기간에 제작해야 하기 때문에 비효율적인 언어나 알고리즘을 사용할 수 있음
3. 나선형 모형(Spiral Model, 점진적 모형) - 보헴(Boehm)
: 보헴이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험분석 기능 추가 모델
: 가장 현실적인 모형으로 대규모 프로젝트나 큰 시스템에 적합
: 점진적 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고
: 정밀하고, 유지보수 과정이 필요 없다
- 단점
: 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 생김
: 비교적 최신기법이므로 널리 사용되지 않음
4. 4GT 모형( 4세대 기법)
: 4세대 언어를 이용하여 개발자가 조사한 요구사항 명세서로 부터 원시 코드를 자동으로 생생할 수 있게 해주는 모형
: 설계 단계를 축소하고, 요구 분석 단계에서 구현 단계로 전환할 수 있는 비절차적 모형
-장, 단점
: 설계 단계를 단축할 수 있고, 4세대 언어를 사용하므로 원시 코드를 자동 생성
: 중, 소형 소프트웨어 개발에 사용하면 개발 시간이 감소되지만, 대규모에서는 자동화로 인해 더 많은 시간이 소요
댓글 없음:
댓글 쓰기