728x90
* 학기 중 공부했던 내용 정리하는 중...
S/W의 개발 단계는 분석 > 설계 > 구현 > 검증(Testing) 순이다.
| 단계별로 투자 비중이 높은 S/W 분석, 설계 단계 - 과학 관련 S/W(물리학, 천문학, 화학) 구현 단계 - 게임 등 관련 S/W 검증(Testing) 단계 - 인간 생명 등 관련 S/W |
Boehm의 이론
| Verification(검증) - S/W의 요구사항 만족 여부를 검증, 개발자나 Test 수행자의 관점이다. Validation(확인) - 실제 환경에서 고객이 원하는대로의 작동 여부를 확인, 사용자 관점이다. |
검증(Testing)의 종류
| 검증의 종류 Black Box Testing - Spec에 기반을 두고하는 Testing - 내부 소스코드에 대한 Logic은 모르고 Input에 따른 예상 Output을 점검하는 방식 White Box Testing - 프로그램 내부 Logic에 기반을 둔 Testing - 각 Test Case들을 특정 소스코드의 Programs 부분을 수행시켜 에러 여부를 확인하는 방식 |
검증(Testing)의 단계
| 검증 단계 1. 단위(Unit) Testing - 프로그램의 각 단위 Module의 기능별 Testing - ex) Googletest Tool - gtest 2. 통합(Integration) Testing - Module들을 합쳐서 Testing 함 - Interface 문제도 Testing 함 3. System Testing - 요구사항, 보안, 성능, 신뢰성 등을 Testing 함 - α-testing(α-version)과 β-testing(β-version)이 수행 (α-testing: 개발자가 회사 내부에서 Testing, β-testing: 외부 사용자가 Testing) 4. 인수(Acceptance) Testing - 인수 전에 사용자에 의해 실제 운영환경에서 수행 됨 |
유지(Maintenance) 비용
Long-Term 운용 S/W인 경우, 유지/보수 비용이 총 개발 비용의 수배에 이를 수 있기때문에 체계적인 개발로 안정성 있고 유지/보수가 편리한 S/W 개발이 필요
| NIST의 예측 운용 단계에서 프로그램 수정 비용은 설계 단계에서의 수정 비용보다 30배 더 소요된다. (NIST: 미국 국립표준기술연구소) (ISO/IEC 등의 국제 기구에서 S/W의 품질 평가 표준을 세부 분야별로 자세히 정의하고, 각국이 S/W 개발 시 이를 참고하여 수행한다.) |
S/W의 변화
환경 변화 요인
- S/W 수정, 기능 추가, 폐기 처분 > 새로운 버전이 Release 됨
Lehman의 S/W 시스템 변화의 법칙(OS 등에서 실험적으로 유도)
- 지속적인 변경 경향: 대형 S/W인 경우, 변경이 더 경제적일 수 있으나, 변경과 재작성 사이에서 경제성 판단이 필요
- 복잡도의 증가 경향: 지속적인 변경에 의해 특별한 노력이 없는 한 복잡도는 증가함
- 통계적으로 완만한 변화 경향: S/W 개발은 인적자원의 속성임(하루아침에 큰 변화가 오지 않고 완만하게 온다.)
| Lehman 법칙의 의미 1. S/W Maintenance 비용은 필연적으로 발생 - S/W 변경이 용이하고, 시스템 구조 손상을 억제할 수 있도록 체계적인 표준화 기술 채택으로 비용 최소화가 필요 2. 지나친 변경은 회피 - 다른 문제점 발생할 가능성이 있음 3. 프로젝트에 가능한 적은 인원 투입 - 프로그래머의 생산성 향상으로 인한 비용 최소화 |
728x90
'소프트웨어공학' 카테고리의 다른 글
| [S/W] Structured Program의 성격 (0) | 2022.10.26 |
|---|---|
| [S/W] Structured Programming(구조화 프로그래밍) & H/W의 발달 (0) | 2022.10.19 |
| [S/W] S/W Cost Estimation(S/W 비용 추정) (0) | 2022.10.12 |
| [S/W] S/W의 생명 주기(Life-Cycle) (1) | 2022.10.05 |
| [S/W] S/W Engineering(소프트웨어 공학)의 정의 (2) | 2022.09.19 |
