※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※
1. 소프트웨어 위기
1960년대 많은 프로젝트들이 완성되지 못하고 실패하며, F.L.바우어가 1968년 독일 가미시에서 열린 첫번째 나토 SW 공학 학회에서 처음 사용한 단어이다.
실패의 이유는 다양한데, 다음과 같다.
- 프로젝트 예산 초과
- 프로젝트 일정 지연
- 결과물(소프트웨어)의 품질이 낮음
- 결과물이 요구사항을 만족하지 못함
- 결과물이 (여러 이유로 인해) 고객의 손에 전달되지 못함.
이로 인해 소프트웨어공학이 생겨났다.
The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software (IEEE 610)
즉, 소프트웨어공학은, 소프트웨어의 개발, 운영 및 유지 보수는 체계적이고 규율적이며 정량적인 접근 방법을 적용하는 것, 즉 공학적 접근(도구, 프로세스, 방법론을 이용한 접근)을 말한다.
SWEBOK(Software Engineering Body Of Knowledge)
- ACM과 IEEE Computer Society에서 발간한 소프트웨어 엔지니어가 반드시 갖춰야할 능력을 구성한 지식영역들의 묶음
1-1. 현황
(자료의 수치는 각 자료들마다 조금씩 다를 수 있음)
후술하겠지만, 애자일이라는 방법이 좋긴 하지만, 여전히 waterfall 모델을 사용하는 곳이 많다.
2. 소프트웨어 개발 프로세스
소프트웨어의 개발 과정
- 요구사항 개발: 고객으로부터 개발하고자 하는 소프트웨어의 요구사항을 수집, 분석, 명세, 검증하는 단계
- 설계: 요구사항을 만족하는 여러 해결책을 제시, 이중 가장 최적화된 해결책을 선정
- 구현: 실제 서비스의 형태로 제공할수 있도록 개발
- 테스트: 요구사항대로 동작하는지 시험
2-1. 예시: 달력
고객 요구
- 년,월,일을 입력하면 요일을 출력하는 프로그램
분석
- 입력 범위? : 1년 1월 1일 ~ 1만년 12월 31일
- 입력 양식?: 년, 월, 일 순서대로 질문 받고 사용자 입력, 입력 범위 벗어날 때, 재질문
- 출력?: 요일
구현
- 요구대로 서비스를 개발
테스트
- 제대로 작동하는가?
- 잘못된 입력에 대한 처리
3. 유지보수
종류
- corrective maintenance (수정 유지보수)
- 소프트웨어의 오류가 발견되었을 때, 이를 수정하는 작업
- adaptive maintenance (적응)
- 운영체제, 인프라 환경 변화로 인해 이를 수용하도록 수정하는 작업
- perfective maintenance (완전)
- 기능, 성능 개선, 새로운 기능 추가, 사용하지 않는 기능 삭제 등을 위해 수정하는 작업
- perventive maintenance (예방)
- corrective maintenance와 달리, 앞으로 일어날 오류(latent)가 발생하기 전에 미연에 방지할 수 있도록 수행하는 작업
유지보수의 비율
4. SDLC Model
소프트웨어의 요구사항, 개발, 운영, 폐기까지의 전 과정을 기술하는 프레임워크
대표적인 Model
- Waterfall Model
- RAD
- lean startup
- Agile Process
- DevOps
5. Waterfall Model (폭포수 모델)
- 가장 전통적인 모델이다.
- 다른 모델들의 기반이 된다.
- 하나의 개발과정이 끝나야만 다음 과정으로 넘어갈 수 있다. → 선형적
특징
- 순차적이고 계획 주도적인 개발 과정이다.
- 이 전 단계가 완료된 후, 다음 단계를 수행한다.
- 문제가 잘 정의되어있고, 예측가능하며, 큰 변화가 없는 시스템을 개발할 때 잘 적용된다.
- 단계별 목표가 명확하기 때문에, 단계별 산출물 역시 명확하다.
- 사용자의 요구가 초기 이후에는 받아들여지기 힘들다.
문제점
- 최종 개발된 SW가 고객이 원하는 것이 아니라면?
- 프로젝트동안 새로운 요구사항이 생기거나, 기존의 요구사항이 변경된다면?
1:10:100 법칙
기본적인 뜻
- 1: 불량이 생겼을 때 즉시 고치는데 들어가는 비용
- 10: 문책이 두려워 불량을 숨긴채 시장에 출시했을 때 비용
- 100: 고객 손에 들어가 손해 배상 청구가 들어왔을때의 비용
소프트웨어 프로젝트
→ 일찍 찾아내 고칠수록 적은 비용이 든다.
6. Iron triangle
Scope(할 일), Resources, Scedule 이 셋이 긴밀한 관계를 맺고 있으며 이 셋은 소프트웨어의 품질에 영향을 미친다는 뜻이다.
- quality는 scope에 반비례, resources, schedule과 비례
- scope가 커지면 resources, schedule도 더 필요할 수 있다.
- scope 고정하고 resources 줄이면 quality 감소
- 브룩스 법칙: 비용(인적 자원등)을 더 투자해도 시간이 줄어들지 않을 수 있다. (비용 투자 > 시간?)
- 비용과 시간은 반비례 관계를 맺지 않는 경향이 있다.
Waterfall model과 Iron triangle
waterfall model은 scope를 고정한 채로 resources와 schedule을 조정한다. 무엇을 만들지 초기 단계에서 명확히 정하고 진행하기 때문이다.
'대학교 > 소프트웨어공학론' 카테고리의 다른 글
| 5. 요구사항 개발 프로세스 (1) | 2023.04.24 |
|---|---|
| 4. 요구사항 (0) | 2023.04.24 |
| 3. scrum (0) | 2023.04.24 |
| 2. rad, lean startup, agile, DevOps (2) | 2023.03.28 |
