1과목 소프트웨어 설계 요구사항 확인 001 ~ 007
001. 소프트웨어 생명 주기
- 소프트웨어 생명 주기 : 소프트웨어 개발 단계와 각 단계별 주요 활용, 활동 결과에 대한 산출물로 표현.
- 폭포수 모형 : 한 단계가 완전히 끝나야만
- 프로토타입 모형 : 요구사항 파악 위해 실제 개발될 소프트웨어에 대한 프로토타입 구축
- 나선형 모형 (점진적 모형) : 계획 - 분석 - 개발 - 평가 여러번 반복
- 애자일 모형 : 고객의 요구사항 변화에 민첩하게 대응하기 위해 일정한 개발 주기를 반복.
핵심가치 :
1) 프로세스, 도구 < 개인, 상호작용
2) 문서 < 실행되는 SW
3) 계약 협상 < 고객과 협업
4) 계획 따르기 < 변화에 반응하는 것
002. 스크럼 기법
- 스크럽 기법 : 팀이 중심이 되어 팀원 스스로 스크럼 팀을 구성/ 개발 작업 모든 것을 스스로 해결할 수 있어야 함.
1) 제품 책임자 (PO) : 개발 제품에 대한 이해도가 높고 요구사항을 책임지고 의사결정하고 작성할 사람.
- 백로그 작성
- 제품 테스트, 주기적으로 요구사항 우선순위 갱신
2) 스크럼 마스터 (SM) : 객관적인 시각에서 조언을 해주는 가이드.
- 일일 스크럼 회의 주관, 진행사항 점검, 개발과정 발생된 장애요소 공론화하여 처리
3) 개발팀 (DT) : PO/SM 제외 모든 팀원.
- 스크럼 개발 프로세스 : 제품 백로그 - 스프린트 계획 회의 - 스프린트 - 일일 스크럼 회의 - 스프린트 검토 회의 - 스프린트 회고
1) 제품 백로그 : 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록. 사용자 스토리를 기반으로 전체 일정 계획 (릴리즈 계획) 수립
2) 스프린트 계획 회의 : 이번 스프린트에서 할 작업을 대상으로 단기 일정 수립. >> Task 작업 단위로 분할하여 개발자별로 수행할 작업 목록 (스프린트 백로그) 작성
3) 스프린트 : 실제 개발작업 진행. 보통 2~4주 정도. Task를 대상으로 속도 추정하여 개발 담당자에게 할당.
(Todo, In progress, Done)
4) 일일 스크럼 회의 : 매일 약속된 시간에 15분 정도 짧은 시간동안 진행 상황 점검.
5) 스프린트 검토 회의 : 부분/전체 완성 제품이 요구사항에 잘 부합되는지 테스팅. 1주 당 1시간 이내.
6) 스프린트 회고 : 스프린트 주기를 되돌아보며 확인. 해당 스프린트가 끝난 시점.
003. XP 기법 (eXtreme Programming)
- XP 기법 : 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발
- 핵심가치 : 의사소통, 단순성, 용기, 존중, 피드백
- 개발 프로세스
1) 사용자 스토리 : 고객 요구사항 시나리오로 표현. 기능단위 구성
2) 릴리즈 계획 수립 : 몇 개 스토리가 적용되어 부분적으로 기능이 완료된 제품 제공(릴리즈)에 대한 일정 수립
3) 스파이크 : 기술 문제에 대한 위험 감소를 위해 별도로 만드는 간단한 프로그램 (처리할 문제 외의 다른 조건 무시)
4) 이터레이션 : 하나의 릴리즈를 더 세분화한 단위. 1~3주 정도의 기간.
5) 승인 검사 (인수 테스트) : 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트. (고객이 직접 수행)
6) 소규모 릴리즈 : 고객의 반응 기능별로 확인 최종 결과물을 고객에게 전달
- 주요 실천 방법
1) Pair programming : 다른 사람과 함께. 개발에 대한 책임 공동
2) Collective Ownership : 개발 코드에 대한 권한과 책임 공동
3) Test-Driven Development : 실제 코드 작성전 테스트 케이스 먼저 작성.
4) Whole Team : 개발 참여 모든 구성원이 자신의 역할에 대한 책임
5) Continuous Integration : 모듈 단위로 나눠서 개발된 코드들 > 작업 마무리마다 통합
6) Design Improvement or Refactoring : 기능 변경 없이 단순화, 유연성 강화 등 시스템 재구성
7) Small Releases : 릴리즈 기간 짧게 반복하여 요구변화에 신속히 대응
004. 현행 시스템 파악
파악 절차
1) 시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 파악
2) 아키텍처 구성 파악 - 소프트웨어 구성 파악
3) 하드웨어 구성 파악 - 네트워크 구성 파악
1) 시스템 구성 파악 : 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요기능들 명시
2) 시스템 기능 파악 : 단위 업무 시스템이 제공하는 기능 > 주요기능/ 하부기능/ 세부기능으로 구분
3) 시스템 인터페이스 파악 : 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형 , 주기 등 명시
4) 아키텍처 구성 파악 : 기간 업무 수행에 어떤 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현.
5) 소프트웨어 구성 파악 : 단위 업무 시스템별로 업무 처리위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등 명시
6) 하드웨어 구성 파악 : 서버의 주요 사양과 수량, 이중화의 적용 여부 명시
(** 서버의 이중화 : 운용 서버의 장애 시 대기 서버로 서비스를 계속 유지할 수 있도록 운용 서버의 자료 변경이 예비 서버에도 동일하게 복제되도록 관리하는 것)
7) 네트워크 구성 파악 : 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성.
005. 개발 기술 환경 파악
- 개발 기술 환경 : 개발하고자 하는 소프트웨어와 관련된 운영체제/데이터베이스 관리 시스템/ 미들웨어 등 선정할 때 고려해야 할 사항 기술, 오픈소스 사용시 주의해야 할 내용 제시.
(** 미들웨어 : 운영체제와 해당 운영체제에 의해 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어)
1) 운영체제 : 컴퓨터 시스템 자원 관리, 사용자가 컴퓨터를 편리하고 효율적으로 사용하도록 환경을 제공하는 소프트웨어.
(Windows, UNIX, Linux, Mac OS, iOS, Android)
- 고려사항 : 가용성/ 성능/ 기술 지원/ 주변 기기/ 구축 비용
2) 데이터베이스 관리 시스템 (DBMS) : 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성, 관리해주는 소프트웨어.
(Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis)
- 고려사항 : 가용성/ 성능/ 기술 지원/ 상호 호환성(JDBC, ODBC와의 호환여부)/ 구축 비용
3) 웹어플리케이션 서버 (WAS) : 사용자의 요구에 따라 변하는 동적 콘텐츠를 처리하기 위해 사용되는 미들웨어.
(Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere)
고려사항 : 가용성/ 성능/ 기술 지원/ 구축 비용
4) 오픈소스 : 누구나 제한 없이 사용가능한 소스코드
고려사항 : 라이선스 종류, 사용자 수, 기술의 지속 가능성.
006. 요구사항 정의
- 요구사항 : 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명/ 정상적으로 운영되는데 필요한 제약조건
- 유형
1) 기능 요구사항
2) 비기능 요구사항 : 시스템 장비 구성 요구사항, 성능 요구사항, 인터페이스 요구사항, 데이터 요구사항, 테스트 요구사항, 보안 요구사항, 품질 요구사항, 제약사항, 프로젝트 관리 요구사항, 프로젝트 지원 요구사항
3) 사용자 요구사항
4) 시스템 요구사항
- 개발 프로세스
1) 도출 (Elicitation) : 시스템, 사용자, 개발 관련된 사람들이 서로 의견 교환/ 요구사항이 어디있는지, 어떻게 수집할 것인지 식별하고 이해하는 과정 (인터뷰, 설문, 워크샵, 프로토타이핑, 유스케이스)
2) 분석 (Analysis) : 개발 대상에 대한 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 걸러냄. (자료 흐름도, 자료 사전)
3) 명세 (Specification) : 분석 요구사항을 바탕으로 모델 작성, 문서화. (기능 요구사항 빠짐없이 명확하게 기술.)
- 요구사항 명세서 (SRS) : 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건 등 명시.
- 정형 명세 기법 : 요구사항 정확&간결/ 표기법이 어려움 (VDM, Z, Petri-net, CSP)
- 비정형 명세 기법 : 자연어 사용-주관적/ 의사소통 용이 (FSM, Decision Table, ER모델링, State Chart)
4) 확인 (Validation) : 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토.
007. 요구사항 분석
: 사용자의 요구사항을 이해하고 문서화하는 활동.
도구 : UML, 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도 (ERD), 상태 전이도(STD), 제어 명세서 등
1) 자료 흐름도 (Data Flow Diagram)
: 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법. (자료흐름 그래프, 버블차트)
1) 프로세스(process) : 자료 변환시키는 시스템의 한 부분. 원이나 둥근 사각형으로 표시하고 프로세스 이름을 기입
2) 자료 흐름 (data flow): 자료의 이동(흐름)이나 연관관계. 화살표 위에 자료이름 기입
3) 자료 저장소 (data store) : 시스템에서의 자료 저장소(파일, 데이터베이스). 도형 안에 저장소 이름 기입
4) 단말 (terminator) : 시스템과 교신하는 외부 개체. 입력데이터가 만들어지고 출력 데이터를 받는다. 도형 안에 이름 기입.
2) 자료 사전 (Data Dictionary)
: 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것. (메타 데이터)
| = | 자료의 정의 (~로 구성되어 있다) |
| + | 자료의 연결 (그리고) |
| ( ) | 자료의 생략 (Optional) |
| [ | ] | 자료의 선택 (또는) |
| { } | 자료의 반복 |
| * * | 자료의 설명(주석) |