우봉수
2023. 3. 16. 17:08
2023. 3. 16. 17:08
소프트웨어 특성 정보
- 소프트웨어 개발 비용
- 분석 및 설계 40%, 코드 개발 20%, 테스트 40%
- 소프트 웨어 개발 및 유지 보수
- 개발 비용 33%, 운영 및 유지 비율 67%
- 소프트웨어 개발 시 오류의 근원
- 문서화 및 기타 오류 35%, 코드 작성 오류 30%, 로직 설계의 오류 20%, 기능의 잘못된 이해 15%
소프트웨어 공학의 목표
- 사용자의 요구사항을 충족시키는 품질 좋은 소프트웨어 개발
- 개발 대상의 명확화: 소프트웨어의 모호성을 없애주는 것이 중요하다!
- 개발 과정의 체계화
- 개발 수명주기 지원
소프트웨어 개발 순서
- 계획
- 요구사항 분석: 개발하고자 하는 소프트웨어에 대한 요구사항을 고객으로 부터 수집하고 명세하는 단계
- How? 보다는 What에 초점을
- 요구 분석 절차: 자료수집 -> 요구사항 도출 -> 문서화 -> 검증
- 요구 분석 분류
- 기능 요구사항: 사용자가 원하는 기능
- 비기능 요구사항: 품질, 제약 사항
- 설계: 고객의 요구사항을 만족하기 위한 여러 해결책을 제시하고 이 중에서 가장 최적화된 해결책을 선정하는 단계
- 구현: 고객의 요구사항을 실제 서비스의 형태로 제공할 수 있도록 개발하는 단계
- 테스트: 개발된 프로그램이 고객의 요구대로 동작이 되는지를 시험하는 단계
- 유지보수
- 수정 유지보수: 소프트웨어의 오류가 발견되었을 때 수정
- 적응 유지보수: 운영체계나 인프라 환경 등이 변화되었을 때 이 변화를 수용하도록 프로그램을 수정하는 작업
- 완전 유지보수: 기능이나 성능을 개선하거나 새로운 기능을 추가하기 위하여 프로그램을 수정하는 작업
- 예방 유지보수: 수정 유지보수를 하지 않게 끔 오류 상황을 미연에 방지될 수 있도록 수행하는 작
Code-and-fix 모델
- 요구사항 분석 단계와 설계 단계가 없다
- 대상: 개발될 소프트웨어가 매우 소규모이면서 매우 간단한 경우에 사용된다.
- 요구사항에 대한 명세를 따로 작성하지 않기 때문에 매우 짧은 기간 동안만 사용되는 경우에 이용
- ex: 간단한 학교 주간 과제
- 우연히 발견된 오류를 수정하는 디버깅에 중심을 둠
waterfall 모델
- 가장 전통적인 모델
- 다른 모델의 기반
- 선형적
- 각 단계마다 생성되는 산출물에 확인 절차를 거친다.
- 요구사항분석
- 초기 개발 단계에서는 고객의 모든 요구사항이 완벽하게 수집되어야 한다. (요구 분석 문서화)
- 요구 분석 문서를 기준으로 사용자에게 이상유무를 확인 받고 설계 절차로 넘어간다.
- 설계
- 아키텍쳐 설계(상위 설계)
- 하위 설계(모듈 세부 내용)
- 객체 지향 방법론에 따라 설계를 한다
- 구현
- 테스트
- 개발자 또는 사용자 시각에 따른 분류
- 사용되는 목적에 따른 분류
- 프로그램의 실행 요구 여부에 따른 분류
- 품질 특성에 따른 분류
- 소프트웨어 개발 단계에 따른 분류
- 유지보수
- 장점
- 관리가 용이하다
- 체계적으로 문서화할 수 있다.
- 요구사항의 변화가 적은 프로젝트에 적합하다.
- 문제점: 고객의 모든 요구사항이 완벽하게 수집되어야 하며 일단 요구사항이 수집되고 분석되어 명세가 완료되었으면 더 이상 요구사항은 변경 되지 않아야 한다.
- 요구사항의 변화에 기민하게 대처하지 못함
- 앞 단계가 완료되어야 수행할 수 있음
- 각 단계마다 작성도니 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류가 발생하지 않음
- 사용자가 중간에 가시적인 결과를 볼 수 없어 답답해할 수 있다.
애자일 프로세스
- 반복적이고 점진적인 개발 방법
- 한번에 조립하는 방식에서 큰 규모의 작업을 짧은 주기를 갖는 이터레이션으로 분할 하고 점진적으로 규모를 키우면서 완성하는 방법
- 추구하는 가치
- 포괄적인 문서화 보다는 동작하는 소프트웨어에 더 중요한 가치를 둔다.
- 계획에 따르기보다는 변화에 대한 대응에 보다 많은 가치를 둔다
- 코드 중심의 개발
결론
- 전통적 개발 방식은 제품을 만들기 위한 작업 단계들에 중점을 두고 있는 반면 애자일 방법은 제품에 의해 고객에게 전달되는 가치에 중심을 두고 있다.