소프트웨어의 중요성
- 의존성: 생활의 모든 곳에 활용
- 소프트웨어가 비즈니스를 주도하고 있음
- 정보혁명의 토대는 컴퓨터이며 그 잠재력은 소프트웨어
- 소프트웨어는 과거 "편리" 추구에서 현재는 "생존"에 필수적 요소
- 소프트웨어의 결함은 생명과 재산에 치명적 결과
소프트웨어의 정의
- 좁은 의미: 프로그램 자체
- 넓은 의미: 프로그램 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체
소프트웨어의 속성
- 개발, 설계되며 제조되지는 않음
- 마모되는 것이 아니라 잦은 변경으로 인해 기능이 퇴화될 뿐
- 기존의 구성요소로 조립되기보다는 요구에 의해 항상 새로 제작
- 극히 적은 비용으로 복제가 가능
- 언제나 시험이 가능하고 수정이 가능
소프트웨어의 특징
- 비마모성: 유지보수 과정에서 소프트웨어 변화를 요구하므로 고장 발생률이 높아짐
- 비가시성: 하드웨어와 달리 소프트웨어는 무형으로 형체가 없음
- 견고성: 소프트웨어 구조의 파괴는 유지보수를 어렵게 하고, 또한 소프트웨어의 행위는 예측하기 힘들고, 수정이 용이하지 못함
- 제조가 아닌 개발: 하드웨어는 제조되며 소프트웨어는 인간의 두뇌에 의한 개발
- 복잡성: 제 3자가 보았을 때 복잡성 최대
- 장수성: 죽지 않으며 단지 불필요한 경우 사라짐
소프트웨어 분류
기능적 분류
- 응용 소프트웨어 (Application Software): 증권 처리, 학사 관리, 워드 프로세서 등
- 시스템 소프트웨어 (System Software): 운영체제, DBMS, Compiler 등
개발 과정에 따른 분류
- Prototype: 시제품, 연구 결과물 등
- Product: 상품화 이전이나 완성된 소프트웨어
- Package: 시험을 거쳐서 상품화된 소프트웨어
- 주문형 소프트웨어: 고객의 목적에 맞도록 패키지된 소프트웨어
하드웨어 환경에 따른 분류
- Mainframe, PC & Workstation
- Parallel Processing or Distributed Processing
- Real time system, In-memory system, mobile system
적용 분야에 따른 분류
- 통신용, 프로그래밍 언어, 사용자 인터페이스, 데이터베이스, 분산처리 등
- 문서 작성, 거래 처리, 개발 도구, 멀티미디어 등
- 전자 정부, 전자 상거래, 가상 도서관 등
소프트웨어 시스템
- 유기적으로 상호 작용하는 객체들의 모임
- e.g. 은행의 업무 전산화
- 현금 자동 인출기, 중앙 컴퓨터, 계좌 DB, 은행 업무 처리 절차, 입출금 전표, 은행원 등
- 시너지 효과: 독립적인 의미를 갖지 않고, 통합되었을 때 의미를 가짐
소프트웨어 시스템의 네 가지 중요 성질
- 서브 시스템: 밀접한 연관이 있는 여러 서브 시스템으로 구성
- 기능적 분할: 규모가 작은 부속 시스템(서브 시스템)들로 나눌 수 있음
- 시스템 경계: 시스템과 주변 환경을 구분하는 경계, 입력과 출력이 만나는 곳
- 자동화 경계: 자동화된 부분과 수동작업 부분을 나누는 경계
S/W와 H/W 비교
| 특성 |
소프트웨어 |
하드웨어 |
| 수정 용이성 |
용이함 |
비교적 용이하지 않음 |
| 복잡성 |
높음 |
비교적 낮음 |
| 공간 점유율 |
낮음 |
높음 |
| 오류 발생률 |
요구 해석 단계 |
제조 단계 |
| 오류 감응도 |
민감함 |
비교적 민감하지 않음 |
| 제품 장애 |
없음 |
있음 |
| 표준화 |
아직 미흡함 |
상당 수준 진전 |
| 검사 용이성 |
어려움 |
비교적 쉬움 |
소프트웨어 위기
내부적 원인
- 개발 프로젝트 관리의 부재 및 전문 인력이 부족
- 개발 참여자들의 신개발기법 지식의 부족 및 개발 기술이 낙후
- 소프트웨어 자체는 오류를 갖기 쉬운 산물이므로 소프트웨어 품질이 미흡
- 소프트웨어의 난해한 특성을 이해하지 못했기 때문에 개발 일정 지연이나 개발 예산의 초과를 불러왔으며, 사용자의 불만을 가중시킴
외부적 원인
- 하드웨어 개발 기술의 발전 속도에 비해 소프트웨어 개발 기술의 속도가 느림
- 새로운 소프트웨어를 요구하는 시장의 수요를 감당할 수 없음
- 구조적으로 개발된 시스템은 복잡하고 시스템이 커질수록 유지보수가 어려워짐
- 이러한 대용량의 재사용 가능한 시스템을 활용하지 못함으로 인해 소프트웨어의 위기를 맞음
- 소프트웨어가 거대화, 복잡화되면서 개발 비용이 증가
개발 공정상의 문제점
- 개발 비용의 초과
- 개발 기간의 지연: 개발 비용과 기간 예측이 부정확, 주먹구구식 개발
- 성능 저하: 프로그래머의 경험과 역량에 의존, 비정형적인 방법 이용
- 제품의 신뢰성 문제: 품질 관리, 품질 보증 기법의 결여
- 제품의 유지보수 비용 과다
해결 방안
소프트웨어 개발 측면
- 주어진 기간 동안 프로젝트의 효율적 관리
- 프로젝트에 소요되는 경비를 정확하게 산출
- 사용자 요구를 정확히 분석, 이에 맞춰 제품개발, 문서화 유지
- 소프트웨어 품질보증기법의 적용 및 정형화된 기술의 사용
유지보수 측면
- 소프트웨어 엔지니어링 기술의 도입
- 소프트웨어 재구조화 (Restructuring)
- 역공학(Reverse-Engineering) 방법의 적용
- 형상관리 실시
해결 절차
- 소프트웨어 위기의 인식
- 소프트웨어 위기의 문제점 분석
- 소프트웨어 위기의 원인 규명
- 소프트웨어 위기의 해결방안 모색
잘못된 의식 구조
- 사용자의 착각
- 시스템이 정의되고 개발목표가 설정되면 프로그래밍은 착수 가능하며 상세 내역은 파악됨에 따라 프로그램 상에 추가시키면 됨
- 사용자의 요구는 지속적으로 변할 수밖에 없음
- 하지만 소프트웨어 개발은 유연해서 개발 도중에 변경되는 사용자의 요구를 개발자들이 쉽게 관철시킬 수 있음
- 관리자의 착각
- 소프트웨어 개발방법이 문서로 상세히 기록되어 있어 개발자들이 어려움을 느낄 이유가 없음
- 스케줄이 지연되면 인력을 추가로 투입함으로써 제 시간에 끝낼 수 있음
- 교육만 시키면 우수한 소프트웨어는 쉽게 확보 가능함
- 개발자의 착각
- 프로그램을 짜고 시험을 끝내면 개발자의 작업은 완료됨
- 프로젝트가 완료되었을 때의 결과는 작동되는 프로그램임
- 소프트웨어의 유지보수란 결함을 찾아 수정하는 작업으로 간단함
- 프로그램이 실제로 동작할 때까지는 S/W 품질을 평가하는 것이 불가능함
소프트웨어 품질 평가 요소
- 정확성 (Correctness)
- 기능이 정확히 작동, 표준에 적함
- 요구사항 명세서의 기능과 일치하는지를 점검
- 신뢰성 (Reliability)
- 소프트웨어가 주어진 기간 동안 정상적으로 작동하는 확률
- 작동 확률은 오류 발생 수에 비례, 정확성 유지를 위한 필요조건
- 강인성 (Robustness)
- 요구사항 명세서의 내용과 일치되지 않은 예외적인 상황에서도 기능이 제대로 작동할 경우
- 재사용성 (Reusability)
- 소프트웨어 부품(라이브러리, 클래스 등 component의 조립, 재사용)
- 확장 가능성(openness), 적응성(adaptability), 이용 용이성(closeness)
- 성능 (Performance)
- 수행 속도(처리 시간, 응답 시간 등), 알고리즘의 시간, 공간 복잡도에 종속, 시뮬레이션, 스트레스 테스트를 통해 점검
- 사용 용이성 (Usability)
- 시스템의 친근성(user friendliness), 사용 대상에 따라 달라질 수 있음
- 사용자 인터페이스, Human factor 등
- 유지 보수성 (Maintainability)
- 특정 기간 내에 소프트웨어 결함(fault)을 해결할 수 있는 특성 (보수성)
- 잠재적인 확장 가능성 (진화성)
소프트웨어 품질
Product 품질
- 소프트웨어 제품 자체의 품질
- 사용자 입장: 외부로 드러나는 품질 요소
- 소프트웨어 사용 중에 서비스 제공의 실패 빈도와 실패 유형이 품질 판단의 기준
- 개발 엔지니어 입장: 내부에 포함된 품질 요소
- 소프트웨어 개발 과정(설계, 코딩, 테스트 등)에서 발견된 결함 개수가 품질 판단의 근거
- 결함(fault): H/W, S/W의 에러 원인 제공
- 에러/오류: 서비스 실패의 원인 제공
- 실패/하자(failure/defect)
- 서비스 기능 미 작동(실패)
- 제품의 인도 후에 발생(하자)
- 오해(mistake): 휴먼 에러 또는 결함, 인간의 실수로 발생
Process 품질
- 개발 및 유지보수 과정의 품질이 제품 자체의 품질 못지않게 중요
- 프로세스 모델링(모형화)에 따른 개발 절차의 향상 방안
- 특정 오류가 언제 어디서 발견되는가?
- 어떻게 하면 개발과정에 오류를 조기에 발견할 수 있는가?
- 어떻게 하면 오류에 대해 내성이 강한 시스템을 개발할 수 있는가?
- 프로세스가 좋은 품질을 보장하는 좀 더 효과적인 다른 방법이 있는가?
소프트웨어 생산성
- Software Productivity
- 개발과정(process)에 크게 의존
- 개발 경험의 성숙도에 의해 의존
- CMM(Capability Maturity Model)
- 개발 경험에 따라 1~5 단계로 분류
- 각 단계별로 프로세스 향상을 위한 지침(guideline)을 제시
- 생산성에 영향을 미치는 요소
- 프로그래머의 성숙도/역량
- 팀 간의 의사소통 기술
- 제품의 복잡도
- 사용 기술의 수준 및 관리 기술
정리
- 소프트웨어는 실행 시 요구되는 컴퓨터 명령어들의 모임이나 프로그램을 의미하고, 소프트웨어 특징으로는 비마모성, 비가시성, 견고성, 제조가 아닌 개발이 있다.
- 소프트웨어 시스템은 유기적으로 상호 작용하는 객체들의 모임으로 소프트웨어 시스템의 네 가지 중요 성질은 서브 시스템, 기능적 분할, 시스템 경계, 자동화 경계이다.
- 개발 측면의 소프트웨어 위기 해결 방안으로 프로젝트의 효율적 관리, 프로젝트 경비 산출, 소프트웨어 품질보증기법의 적용 및 정형화된 기술의 사용이 있다.
- 유지보수 측면의 소프트웨어 위기 해결 방안으로 소프트웨어 엔지니어링 기술의 도입, 소프트웨어 재구조화(Restructuring), 역공학(Reverse-Engineering) 방법의 적용, 형상관리 실시가 있다.
