소프트웨어공학 - 서론
소프트웨어 개발은 다음과 같은 프로세스를 따른다.
고객의 요구 -> 요구사항 분석 -> 설계 -> 구현 -> 테스팅 -> S/W 제품
또한 제조가 아니라 개발이기 때문에 개발은 개인 능력에 따라 차이가 크고, 구현하는 방법도 달라진다.
소프트웨어공학 - 역사적 측면
- 1967년 , NATO가 소프트웨어공학이라는 용어를 만들었다.
- NATO는 크고 복잡한 프로그램을 제작하는 데 많은 어려움을 겪고 있는 컴퓨터 산업의 문제들에 전념하는 회의를 주최했다.
- 1968년 NATO 회의에서 소프트웨어 공학은 소프트웨어 위기의 문제를 해결하기 위해 (이전에)확립된 공학 분야의 철학과 패러다임을 사용해야 한다고 결론을 내렸다.
소프트웨어공학 출현 배경
- 소프트웨어 개발에 소요되는 시간, 노력 및 비용을 예측할 수 없음.
- 소프트웨어의 질이 떨어짐.
- H/W 대 S/W 비용 비율의 변화
- 점점 더 중요해지는 유지보수의 역할
- 하드웨어 발전
- 소프트웨어에 대한 수요 증가
- 더 크고 더 복잡한 S/W 시스템에 대한 요구
소프트웨어 제작의 문제점
- 비용 초과
- 배달 지연
- 미흡한 성능
- 신뢰성 없음
- 일이 밀림
- 불가능한 유지보수
- 높은 유지보수 비용
-> 소프트웨어 위기
- 소프트웨어의 품질은 일반적으로 받아들일 수 없을 정도로 낮고 마감일과 비용 제한을 충족하지 못하고 있다.
- 55%의 프로젝트가 예상보다 비용이 많이 들었고, 68%는 일정을 초과했으며, 88%는 대폭 재설계해야 했다.
소프트웨어 위기
소프트웨어 프로젝트에 대한 DoD의 발표(1980년 초)에 따르면…
worked on delivery : 2%
worked after some corrections 3%
delivered but never successfully used : 45%
used but either extensively reworked or abandoned : 20%
paid for, but never delivered : 30%
2001년 미국 소프트웨어 프로젝트 결과
취소됨 : 29%
일정준수 : 26%
20% 이하 지연 : 6%
21~50% 지연 : 8%
51%~100% 지연 : 9%
101%~200% 지연 : 16%
대규모 프로젝트의 어려움
- 수백명의 개발자 : 의사소통 및 상호 협력이 어렵고, 조직 및 팀 구조가 바뀔 수 있다.
- 오랜 개발 시간 : 프로젝트 관리가 어렵고, 비용 및 효과의 산정이 어렵다(비용 상승).
- 모호하고 복잡한 요구사항 : 수백페이지의 요구사항, 빈번한 요구사항의 변화
소프트웨어공학이란
- 고품질 소프트웨어의 경제적 생산을 위한 공학적, 과학적, 수학적 원리와 방법의 규율화된 적용 - Watts Humphrey
- 소프트웨어의 개발, 운영, 유지 및 폐기에 대한 체계적 접근 - IEEE Computer Society
- 다중 버전 소프트웨어의 다중 사용자 구성 - D.L. Parnas
- 대형 소프트웨어 시스템의 설계, 구축 및 유지보수 - Ian Sommerville
소프트웨어공학의 목적
- 높은 품질의 소프트웨어 시스템 생산
- 낮은 비용(예산에 맞게)으로 생산(cost-effective)
- 제시간에 사용자의 요구가 만족되는 시스템 생산
소프트웨어공학이 중요한 이유
- 모든 선진국의 경제는 소프트웨어에 의존한다
- 소프트웨어 공학 지출은 모든 선진국에서 GNP의 상당한 부분을 차지한다
- 종종 소프트웨어 비용이 시스템 비용을 지배한다
- 소프트웨어는 유지보수 비용이 개발 비용보다 더 많이 든다.수명이 긴 시스템의 경우 유지보수 비용이 개발 비용의 몇 배가 될 수 있다
- 점점 더 많은 시스템이 소프트웨어로 제어된다.
소프트웨어공학의 관점
소프트웨어 공학은 광범위하고 여러 학문이 연관된 주제로 다음과 같은 지식을 필요로 한다.
- 소프트웨어 프로세스
- 설계, 코딩 및 분석
- 도구 및 환경
- 소프트웨어 프로젝트 관리
- 버전관리
- 품질보증
- 기타 지식
- 하드웨어 특성
- 인적 요인(GUI)
- 기술 의사소통과 문서화
소프트웨어 특성
소프트웨어는 다음으로 구성되는 아이템 또는 객체의 집합이다
- 프로그램
- 문서
- 데이터 등.
소프트웨어는 개발되거나 설계된 것이며, 제조되지 않는다. 고전적으로,
- 프로세스 개발에 집중
- 사람들의 활동에 집중
대부분의 S/W는 기존 구성 요소를 이용해 조립되지 않고 맞춤 제작된다.
소프트웨어는 마모되지 않는다. 하드웨어는 오래 사용하면 성능이 저하된다. 하드웨어 실패 곡선은 모양 때문에 욕조 곡선이라 불리기도 하며, 처음에는 실패율이 높지만 오류를 해결하면 실패율이 낮은 상태로 지속되다가, 오래 사용하면 다시 실패율이 치솟는다. 그러나 소프트웨어는 처음 개발할 때 실패율이 높다가 오류를 해결한 후에는 문제없이 사용할 수 있다(이상적인 상황). 그러나 시간이 지나면 설치 환경이 달라지거나 사용자의 요구가 달라져 이것을 시스템에 반영해야하고, 부작용으로 일시적으로 실패율이 치솟을 수 있다.
또한 문서화는 소프트웨어의 중요한 측면이다. 그러나 보통 즐거운 활동으로 여겨지지는 않는다.
시스템은 시스템이 구축될 때 항상 (거의) 변경사항을 해결하도록 되어 있다.
소프트웨어 개발은 왜 힘든가?
- 소프트웨어가 보이지 않음(보이지 않음)
- 내재적 복잡성을 감소시킬 수 없음: 비선형적으로 증가하는 노력(복잡성)
- 제작되지 않음/대부분 일회성 시스템(고객을 위해 맞춤형으로 제작된 단일 제품)(적합성)
- 소프트웨어는 완성 직후 진화하고 있다(변경성)
- 소프트웨어 개발의 순차적 성격
- 완전 자동화할 수 없음
- 의사소통이 요구됨
- 관리의 어려움
- 소프트웨어 공학의 짧은 역사
- 테스팅
- 예를 들어, 두 개의 32bit 입력이 있는 모듈을 테스트 하려면 하나의 테스트 케이스를 테스트 하는데 0.0000001초가 걸린다고 할때 58494년이 걸린다.
- 테스터의 능력에 따라 성능은 40배 차이가 난다.
- 임베디드 시스템 개발에서는 테스트가 더욱 복잡해진다. 테스트를 완료할 방법이 없다. 실패를 반복하기 어렵고, H/W는 안정적이지 않다. H/W가 준비되지 않으면 테스트 환경을 구축하기가 쉽지 않다.
소프트웨어와 관련된 미신
관리자
- 우리는 소프트웨어를 만들기 위한 표준과 절차를 가지고 있기 때문에 개발자들이 알아야 할 모든 것을 가지고 있다.
- 우리는 최첨단 소프트웨어 개발 도구를 가지고 있다.
- 우리가 예정보다 늦으면 프로그래머를 더 늘릴 수 있다.
- 좋은 관리자는 어떤 프로젝트든 관리할 수 있다.
고객
- 프로그램 작성을 시작하려면 일반적인 목표만으로도 충분하다. 자세한 내용은 나중에 작성할 수 있습니다.
- 소프트웨어는 유연하기 때문에 요구사항 변경을 수용하기 쉽다.
실무자
- 프로그램이 작성되고 실행되면 우리의 일은 끝난다.
- 프로그램이 실행되기 전까지는 프로그램의 품질을 평가할 방법이 없다.
- 소프트웨어 프로젝트의 산출물은 작동되는 프로그램이 유일하다.
개발과 유지보수
소프트웨어 유지보수 비용은 일반적으로 개발 비용보다 두 배나 비싸다. 왜냐하면 소프트웨어가 사용되는 시간이 길기 때문이다. 소프트웨어 제품이 최종 목표가 아니다. 유지보수가 더 중요하다.
에러
에러는 문서(35%), 코딩(30%), 기능 또는 기능을 잘못이해함(15%), 논리설계(20%)에서 나타난다.
에러가 빨리 발견될수록 좋다. 그러나 많은 에러가 개발자보다 외부 테스터나 사용자에 의해 발견된다. 많은 에러가 Acceptance와 Operation에서 발견된다(Requirement, Design, Code, Test, Acceptance, Operation 순으로 에러 비용이 높아진다.)
소프트웨어 애플리케이션
시스템 소프트웨어
다른 프로그램에게 서비스를 제공하는 프로그램이다. OS, 드라이버, 파일관리자가 있다.
실시간 소프트웨어
real world이벤트 발생 시 모니터링, 분석 및 제어하는 프로그램이다. 제한된 시간안에 반응해야한다.
비즈니스 소프트웨어
비즈니스 운영 또는 경영상의 의사 결정을 용이하게 한다. MIS(Management Information Systems 등)
엔지니어링 및 과학 소프트웨어
천문학 등에서 나오는 대량의 데이터를 고속처리하거나 데이터 과학 프로그램. CAD 등이 있다.
임베디드 소프트웨어
읽기 전용 메모리에 설치되어있고, 소비자 및 산업 시장의 제품 및 시스템을 제어하는 데 사용된다. 매우 제한된 기능만 수행한다.
인공지능 프로그램
기계가 생각하게 하고, 데이터를 학습하여 예측하는 프로그램 non-numerical algorithm을 사용한다.
소프트웨어공학의 기술 추세
1960년대 이전 : SW의 탄생
기계어로 구현된 SW가 탄생하였다.
1960~1980 : SW 생산성 향샹
대형화된 프로젝트의 효율성 향상을 위해 공동제작 SW도구 등장
1980~2000 : SW 품질 개선
Sw를 안정적으로 개발할 수 있는 프로세스 기반의 관리방법론 창립
2000년대 이후 : SW가치창출
SW의 서비스화 및 SW의 가치를 창출하기 위한 새로운 SW 탄생 예고
참고 문헌
- Roger S. Pressman, Bruce R. Maxim, “Software Engineering”(9th edition), MCGrawHill,2019
- 김치수 저, “소프트웨어 공학”, 한빛아카데미, 2021
댓글남기기