목차
-
1. 소프트웨어 생명 주기
-
2. 스크럼
-
3. XP
-
4. 현행 시스템 파악
-
5. 개발 기술 환경 파악
-
6. 요구사항 정의
-
7. 요구사항 개발 프로세스
-
8. 요구사항 분석
-
9. 요구사항 분석용 CASE
-
10. HIPO
-
11. UML
-
12. UML - 관계
-
13. UML - 다이어그램
-
14. 기능 모델링과 종류 (유스케이스, 활동 다이어그램)
-
15. 정적 모델링과 클래스 다이어그램
-
16. 동적 모델링과 종류 (시퀀스, 커뮤니케이션, 상태 다이어그램)
-
17. 패키지 다이어그램
-
18. 소프트웨어 개발 방법론
-
19. 소프트웨어 재사용과 재공학, CASE
-
20. 비용 산정 기법
-
21. 하향식 비용 산정 기법
-
22. 상향식 비용 산정 기법
-
23. 프로젝트 일정 계획
-
24. 소프트웨어 개발 표준
-
25. 소프트웨어 개발 방법론 테일러링
-
26. 소프트웨어 개발 프레임워크
1. 소프트웨어 생명 주기
소프트웨어 생명 주기(Software Life Cycle)
- 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.
- 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현한다.
- 대표적인 생명 주기 모형은 아래와 같이 있다.
- 폭포수 모형
- 프로토타입 모형
- 나선형 모형
- 애자일 모형
폭포수 모형(Waterfall Model)
- 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다.
- 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
- 고전적 생명 주기 모형이라고 한다.
- 모형을 적용한 경험과 성공 사례가 많다.
- 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.
프로토타입 모형(Prototype Model)
- 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형이다.
- 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
나선형 모형(Spiral Model)
- 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형이다.
- 폭포수 모형과 프로토 타입 모형의 장점에 위험분석 기능을 추가한 모형이다.
- 보헴이 제안하였다.
- 중간에 누락되거나 추가된 요구사항을 첨가할 수 있다.
- 계획하고 분석한 뒤 개발하고 평가한다.
![]()
애자일 모형(Agile Model)
- 애자일은 요구사항의 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발하는 모형이다.
- 어느 특정 개발 방법혼이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 말한다.
- 폭포수 모형과 대조적이다.
- 대표적인 개발 모형이다.
애자일 개발의 4가지 핵심 가치
- 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
- 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
- 계약 협상보다는 고객과 협업에 더 가치를 둔다.
- 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.
소프트웨어 공학
- 소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방은으로 연구된 학문이다.
- 여러 가지 방법론과 도구, 관리기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.
- 소프트웨어 공학의 기본 원칙
- 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
- 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.
2. 스크럼
스크럼(Scrum)
- 팀이 중심이 되어 개발의 효율성을 높이는 기법이다.
- 팀원 스스로가 스크럼 팀을 구성하고, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다.
스크럼 팀
- 제품책임자 : 요구사항이 담긴 백로그를 작성하는 주체
- 스크럼 마스터 : 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행한다.
- 개발팀 : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행한다.
* 백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록
스크럼 개발 프로세스
| 프로세스 | 내용 |
| 스프린트 계획 회의 | 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의이다. |
| 스프린트 | 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행한다. |
| 일일 스크럼 회의 | 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의이다. 남은 작업 시간은 소멸 차트에 표시한다. |
| 스프린트 검토 회의 | 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의이다. |
| 스프린트 회고 | 정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것이다. |
* 제품 백로그 : 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록이다
* 소멸차트 : 스프린트에서 작업의 진행 상황을 확인할 수 있게 시간의 경과에 따라 남은 작업 시간을 그래프로 표현한 것이다.
- 스크럼 개발은 계획하고 스프린트 하면서 회의한 뒤 검토하고 회고한다.
3. XP
XP(eXtreme Programming)
- 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
- XP의 5대 핵심 가치
- 의사소통
- 단순성
- 용기
- 존중
- 피드백
XP 개발 프로세스
| 프로세스 | 내용 |
| 릴리즈 계획 수립 | 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것이다. 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 한다. |
| 이터레이션 | 실제 개발 작업을 진행하는 과정으로 보통 1~3주 정도의 기간으로 진행된다. |
| 승인 검사 | 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트다. |
| 소규모 릴리즈 | 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것 |
XP의 주요 실천 방법
| 실천 방법 | 내용 |
| 짝 프로그래밍 (Pair Programming) |
다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성한다. |
| 공동 코드 소유 (Collective Ownership) |
개발 코드에 대한 권한과 책임을 공동으로 소유한다. |
| 테스트 주도 개발 (Test-Driven Development) |
개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확하게 파악한다. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용한다. |
| 전체 팀 (Whole Team) |
개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 한다. |
| 계속적인 통합 (Continuous Integration) |
모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합된다. |
| 리팩토링 (Refactoring) |
프로그램 기능의 변경 없이 시스템을 재구성한다. 리팩토링의 목적 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함이다. |
| 소규모 릴리즈 (Small Release) |
릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다. |
4. 현행 시스템 파악
현행 시스템 파악 절차
| 프로세스 | 현행 시스템 | 내용 |
| 1단계 | 시스템 구성 파악 | 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술한다. |
| 시스템 기능 파악 | 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시한다. | |
| 시스템 인터페이스 파악 | 단위 업무 시스템간에 주고 받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시한다. | |
| 2단계 | 아키텍쳐 구성 파악 | 최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성한다. |
| 소프트웨어 구성 파악 | 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시한다. | |
| 3단계 | 하드웨어 구성 파악 | 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화 적용 여부를 명시한다. |
| 네트워크 구성 파악 | 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성한다. |
5. 개발 기술 환경 파악
개발 기술 환경 파악의 개요
개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스를 사용할 때 주의해야 할 내용을 제시한다.
운영체제
- 운영체제는 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어이다.
- 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종이다.
- 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공한다.
- 운영체제 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술지원
- 주변기기
- 구축 비용
데이터베이스 관리 시스템(DBMS)
- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어이다.
- 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템이다.
- 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리한다.
- DBMS 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 상호 호환성
- 구축 비용
웹 애플리케이션 서버(WAS)
- 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어이다.
- 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공한다.
- 주로 데이터베이스 서버와 연동해서 사용한다.
- 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 구축 비용
오픈 소스(Open Source)
- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어이다.
- 오픈 소스 라이선스를 만족한다.
- 오픈 소스 관련 요구사항 식별 시 고려사항
- 라이선스의 종류
- 사용자 수
- 기술의 지속 가능성
6. 요구사항 정의
요구사항
- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
- 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다.
- 요구사항의 유형
- 기능 요구사항
- 비기능 요구사항
- 사용자 요구사항
- 시스템 요구사항
기능 요구사항
- 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
- 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
- 시스템이 반드시 수행해야 하는 기능
- 사용자가 시스템을 통해 제공받기를 원하는 기능
비기능 요구사항
- 품질이나 제약사항과 관련된 요구사항
- 시스템 장비 구성 요구사항
- 성능 요구사항
- 인터페이스 요구사항
- 데이터를 구축하기 위해 필요한 요구사항
- 테스트 요구사항
- 보안 요구사항
- 품질 요구사항
- 가용성
- 정합성
- 상호 호환성
- 대응성
- 이식성
- 확장성
- 보안성
- 제약사항
- 프로젝트 관리 요구사항
- 프로젝트 자원 요구사항
사용자 요구사항
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항이다.
- 사용자를 위한 것으로, 친숙한 표현으로 이해하기 쉽게 작성된다.
시스템 요구사항
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현된다.
- 소프트웨어 요구사항이라고도 한다.
7. 요구사항 개발 프로세스
요구사항 개발 프로세스
- 요구사항 개발 프로세스는 개발 대상에 대한 요구 사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동이다.
- 요구사항 개발 프로세스가 진행되기 전에 타당성 조사가 선행되어야 한다.
- 도출 -> 분석 -> 명세 -> 확인 순서이다.
요구사항 도출
- 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별된다.
- 소프트웨어 개발 생명주기 동안 지속적으로 반복된다.
- 요구사항을 도출하는 주요 기법
- 청취와 인터뷰
- 설문
- 브레인스토밍
- 워크샵
- 프로토타이핑
- 프로토타입을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업이다.
- 가장 단순한 형태 : 설명을 위해 종이에 대략적인 순서의 형태를 그려 보여주는 것이다.
- 유스케이스 : 사용자의 요구사항을 기능 단위로 표현하는 것
요구사항 분석
- 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.
- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동이다.
- 비용과 일정에 대한 제약을 설정한다.
- 타당성을 조사하며 요구사항 문서를 정의화하고, 목표를 설정한다.
- 서로 상충되는 요구사항이 있으면 이를 중재하는 과정이다.
- 요구사항 분석에 사용되는 대표적인 도구들
- 자료흐름도 : 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법이다. 버블차트라고도한다.
- 자료사전 : 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이다. 메타데이터라고도 한다.
요구사항 명세
- 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미한다.
- 기능 요구사항을 빠짐없이 기술한다.
- 비기능 요구사항은 필요한 것만 기술한다.
- 구체적인 명세를 위해 소단위 명세서가 사용될 수 있다.
요구사항 확인
- 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토하는 활동이다.
- 이해 관계자들이 검토해야 한다.
- 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리를 수행한다.
요구공학
- 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문이다.
- 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트의 실패를 최소화하는 것을 목표로 한다.
요구사항 명세 기법
- 요구 사항 명세기법은 크게 정형과 비정형으로 나뉜다.
| 구분 | 정형 | 비정형 |
| 기법 | 수학적 원리, 모델 기반 | 상태,기능,객체 중심 |
| 작성 방법 | 수학적 기호, 정형화된 표기법 | 일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성 |
| 특징 | 요구사항을 정확하고 간결하게 표현할 수 있다. 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있어 완전한 검증이 가능하다. 표기법이 어려워 사용자가 이해하기 어렵다. |
자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라 다를 수 있다. 그렇기에 일관성이 떨어지고 해석이 달라질 수 있다. 내용의 이해가 쉬워 의사소통이 용이하다. |
| 종류 | VDM, Z, Perti-net, CSP ... | FSM, Decision Table, ER모델링, State Chart ... |
8. 요구사항 분석
요구사항 분석
- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동이다.
- 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
- 요구사항을 문서를 정의화한다.
- 요구를 정확하게 추출하여 목표를 설정한다.
구조적 분석 기법
- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석방법이다.
- 도형중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화한다.
- 하향식 방법을 사용하여 시스템을 세분화할 수 있다.
- 분석의 중복을 배제할 수 있다.
- 구조적 분석 기법 도구
- 자료 흐름도
- 자료 사전
- 소단위 명세서
- 개체관계도
- 상태전이도
- 제어 명세서
자료 흐름도
- 자료의 흐름 및 변환 과정과 기능을 동형 중심으로 기술하는 방법이다.
- 자료 흐름 그래프, 버블 차트라고도 한다.
- 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다.
- 자료 흐름도의 구성요소
- 프로세스(Process) : 자료를 변환시키는 시스템의 한 부분(처리 과정)
- 자료흐름(Data Flow) : 자료의 이동이나 연관관계
- 자료 저장소(Data Store) : 자료 저장소(파일, 데이터베이스)
- 단말(Terminator) : 시스템과 교신하는 외부 개체
자료 사전
- 자료 흐름도에 있는 자료를 더 자세하게 정의하고 기록한 것이다.
- 데이터를 설명하는 데이터이다.
- 자료 사전에서 사용되는 표기 기호
- 자료의 정의 : = | ~로 구성되어 있다.
- 자료의 연결 : + | 그리고
- 자료의 생략 : () | 생략 가능한 자료
- 자료의 선택 : [] | 또는
- 자료의 반복 : {} | 하단 : n번 이상 반복, 상단 : 최대 n번 반복, 상하단 : 하단이상 상단 이하로 반복
- 자료의 설명 : ** | 주석
9. 요구사항 분석용 CASE
요구사항 분석용 CASE
- 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구이다.
- 대표적인 CASE
- SADT
- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구이다.
- 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구이다.
- softTech 사에서 개발했다.
- SREM
- RSL과 REVS를 사용하는 자동화 도구이다
- RSL : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어이다.
- REVS : RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 명세서를 출력하는 요구사항 분석기이다.
- RSL과 REVS를 사용하는 자동화 도구이다
- PSL/PSA
- PSL : 문제 기술 언어이다.
- PSA : PSL로 기술한 요구사항을 분석하여 보고서를 출력하는 문제 분석기이다.
- 미시간 대학에서 개발하였다.
- TAGS
- 시스템 공학 방법 응용에 대한 자동 접근 방법이다.
- 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구이다.
- SADT
10. HIPO
HIPO
- 시스템 실행과정인 입력, 처리, 출력의 기능을 표현한 것이다.
- 하향식 소프트웨어 개발을 위한 문서화 도구이다.
- 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
- 기호, 도표 등을 사용하므로 보기 쉽고, 이해하기도 쉽다.
- HIPO Chart : 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것
- 가시적 도표
- 총체적 도표
- 세부적 도표
11. UML
UML
- 시스템 개발 과정에서 의사소통이 원활하게 이뤄지도록 표준화한 대표적인 객체 지향 모델링 언어이다.
- 럼바우, 부치, 제이콥슨 등의 객체지향 방법론의 장점을 통합하였다.
- OMG에서 표준으로 지정하였다.
- UML의 구성요소
- 사물
- 관계
- 다이어그램
사물
- 다이어그램 안에서 관계가 형성될 수 있는 대상을 의미한다.
- 모델을 구성하는 가장 중요한 기본 요소이다.
- 사물의 종류
- 구조적
- 시스템의 개념적, 물리적 요소를 표현한다.
- 클래스, Use Case, Component, Node 등
- 행위적
- 시간과 공간에 따른 요소들의 행위를 표현한다.
- 상호작용, 상태머신 등
- 그룹
- 요소들을 그룹으로 묶어서 표현한다.
- 패키지
- 주해
- 부가적인 설명이나 제약조건 등을 표현한다.
- 노드
- 구조적
12. UML - 관계
관계
- 사물과 사물 사이의 연관성을 표현하는 것이다.
- 관계의 종류
- 연관
- 집합
- 포함
- 일반화
- 의존
- 실체화
연관 관계
- 2개 이상의 사물이 서로 관련되어 있는 관계다.
- 사물 사이를 실선으로 연결하여 표현한다.
- 방향성은 화살표로 나타낸다.
- 양방향의 경우 실선으로만 연결한다.
- 다중도를 선 위에 표기한다.
- 다중도 : 연관에 참여하는 객체의 개수
집합 관계
- 하나의 사물이 다른 사물에 포함되어 있는 관계이다.
- 서로 독립적이다.
- 속이 빈 마름모를 통해 연결한다.
포함 관계
- 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계이다.
- 서로 독립될 수 없고, 생명주기를 함께한다.
- 속이 채워진 마름모를 통해 연결한다.
일반화 관계
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계이다.
- 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.
- 속이 빈 화살표로 연결한다.
의존 관계
- 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계이다.
- 하나의 사물과 다른 사물이 소유관계는 아니지만, 사물의 변화가 다른 사물에도 영향을 미치는 관계이다.
- 점선 화살표로 연결한다.
실체화 관계
- 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화할 수 있는 관계이다.
- 속이 빈 점선 화살표로 연결한다.
13. UML - 다이어그램
다이어그램
- 사물과 관계를 도형으로 표현한 것이다.
- 정적 모델링에서는 주로 구조적 다이어그램을 사용한다
- 동적 모델링에서는 주로 행위 다이어그램을 사용한다
구조적 다이어 그램의 종류
| 종류 | 내용 |
| 클래스 다이어그램 | 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다. |
| 객체 다이어그램 | 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현한다. 럼바우의 객체지향 분석 기법에서 객체 모델링에 활용된다. |
| 컴포넌트 다이어그램 | 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현한다. 구현 단계에서 사용된다. |
| 배치 다이어그램 | 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다. 구현 단계에서 사용된다. |
| 복함체 구조 다이어그램 | 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다. |
| 패키지 다이어그램 | 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현한다. |
행위 다이어그램의 종류
| 종류 | 내용 |
| 유스케이스 다이어그램 | 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용한다. 사용자와 사용 사례로 구성된다. |
| 시퀸스 다이어그램 | 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현한다. |
| 커뮤니케이션 다이어그램 | 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현한다. |
| 상태 다이어그램 | 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현한다. 럼바우의 객체지향 분석 기법에서 동적 모델링에 활용된다. |
| 활동 다이어그램 | 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라표현한다. |
| 상호작용 개요 다이어그램 | 상호작용 다이어그램 간의 제어 흐름을 표현한다. |
| 타이밍 다이어그램 | 객체 상태 변화와 시간 제약을 명시적으로 표현한다. |
스테레오 타입
- UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것이다.
- 길러멧이라고 부르는 겹화살괄호( <<>>) 사이에 표현할 형태를 기술한다.
| 표현 | 뜻 |
| <<interface>> | 인터페이스 클래스 |
| <<abstract>> | 추상화 클래스 |
| <<enumeration>> | 열거형 타입 클래스 |
| <<utilty>> | 인스턴스가 없는 static 메서드만 모아둔 클래스 |
| <<create>> | 생성자 |
14. 기능 모델링과 종류 (유스케이스, 활동 다이어그램)
기능 모델링
- 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것이다.
- 개발될 시스템의 전반적인 형태를 기능에 초점을 맞춰 표현한다.
- 기능 모델링의 종류
- 유스케이스 다이어그램
- 액티비티 다이어그램
유스케이스 다이어그램
- 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있도록 사용자 관점에서 표현한 것이다.
- 외부 요소와 시스템 간의 상호 작용을 확인할 수 있다.
- 사용자의 요구사항을 분석하기 위한 도구로 사용된다.
- 시스템의 범위를 파악할 수 있다.
유스케이스 다이어그램의 구성요소
| 구성요소 | 내용 |
| 시스템 | 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것이다. |
| 액터 | 시스템과 상호작용을 하는 모든 외부요소 주로 사람이나 외부 시스템을 의미한다. 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당된다. 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관등이 될 수 있다. |
| 유스케이스 | 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것이다. |
| 관계 | 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있다. 유스케이스에서 나타날 수 있는 관계 : 포함, 확장, 일반화 관계 |
*포함관계 : 2개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계이다.
원래의 유스케이스에서 새롭게 포함되는 유스케이스에 점선 화살표를 연결한 뒤, <<\include>>라고 표기한다.
* 확장관계 : 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계이다.
확장될 유스케이스에서 원래의 유스케이스 쪽으로 점선화살표를 연결한 뒤, <<\extends>>라고 표기한다.
활동 다이어그램
- 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것이다.
- 하나의 유스케이스 안에서 혹은 유스케이스 사이에 발생하는 복잡한 처리의 흐름을 명확하게 표현할 수 있다.
- 자료흐름도와 유사하다.
활동 다이어그램의 구성요소
| 구성요소 | 내용 |
| 액션 / 액티비티 | 액션 : 더 이상 분해할 수 없는 단일 작업이다. 액티비티 : 몇 개의 액션으로 분리될 수 있는 작업이다. |
| 시작 노드 | 액션이나 액티비티가 시작됨을 표현한 것이다. |
| 종료 노드 | 액티비티 안의 모든 흐름이 종료됨을 표현한 것이다. |
| 조건(판단) 노드 | 조건에 따라 제어의 흐름이 분리됨을 표현한 것이다. 들어오는 제어 흐름은 1개이고, 나가는 제어 흐름은 여러 개이다. |
| 병합 노드 | 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것이다. 들어오는 제어 흐름은 여러개이고, 나가는 제어흐름은 1개이다. |
| 포크 노드 | 액티비티의 흐름이 분리되어 수행됨을 표현한 것이다. 들어오는 액티비티 흐름은 1개이고, 나가는 액티비티 흐름은 여러개 이다. |
| 조인 노드 | 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것이다. 들어오는 액티비티 흐름은 여러개 이고, 나가는 액티비티 흐름은 1개이다. |
| 스윔레인 | 액티비티 수행을 담당하는 주체를 구분하는 선 가로 또는 세로 실선을 그어 구분한다. |
15. 정적 모델링과 클래스 다이어그램
정적 모델링
- 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것이다.
- 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점에서 표현한다.
- 정적 모델링은 객체들을 클래스로 추상화하여 표현한다.
- UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램이다.
클래스 다이어그램
- 클래스와 클래스가 자신을 가지는 속성, 클래스 사이의 관계를 표현한 것이다.
- 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램이다.
- 시스템 구성요소를 문서화하는 데 사용된다.
클래스 다이어그램의 구성요소
| 구성요소 | 내용 |
| 클래스 | 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한 것이다. 일반적으로 3개의 구획으로 나워 클래스의 이름, 속성, 오퍼레이션을 표기한다. 속성 : 클래스의 상태나 정보를 표현한다. 오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수(메소드) 라고도 한다. |
| 제약 조건 | 속성에 입력될 값에 대한 제약 조건이나 오퍼레이션 수행 전 후에 지정해야 할 조건이 있다면 이를 적는다. 클래스 안에 제약조건을 기술할 때는 중괄호를 이용한다. |
| 관계 | 관계는 클래스와 클래스 사이의 연관성을 표현한다. 클래스 다이어그램에 표현하는 관계에는 연관, 집합, 포함, 일반화, 의존 관계가 있다. |
클래스 다이어그램 - 연관 클래스
- 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스이다.
- 두 클래스의 연관 관계를 나타내는 선의 가운데로 부터 점선을 연관 클래스로 이어 표시한다.
- 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정한다.
16. 동적 모델링과 종류 (시퀀스, 커뮤니케이션, 상태 다이어그램)
동적 모델링
- 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것이다.
- 시스템 내부 구성 요소들 간에 이뤄지는 동작이라는 관점에서 표현한다.
- 시스템이 실행될 때 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점을 둔다.
- 동적 모델링의 종류
- 시퀀스 다이어그램
- 커뮤니케이션 다이어그램
- 상태 다이어그램
시퀀스 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것이다.
- 각 동작에 참여하는 시스템이나 객체들의 수행기간을 확인할 수 있다.
- 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현한다.
시퀀스 다이어그램의 구성요소
| 구성요소 | 내용 |
| 액터 | 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미한다. |
| 객체 | 메시지를 주고받는 주체이다. |
| 생명선 | 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현한다. 객체 소멸(X)이 표시된 기간까지 존재한다. |
| 실행상자 | 객체가 메시지를 주고 받으며 구동되고 있음을 표현한다. |
| 메시지 | 객체가 상호작용을 위해 주고 받는 메시지다. |
| 객체 소멸 | 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것이다. |
| 프레임 | 다이어그램의 전체 또는 일부를 묶어 표현한 것이다. |
커뮤니케이션 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것이다.
- 동작에 참여하는 객체들 사이의 관계를 파악하는 데 사용된다.
- 클래스 다이어그램에서 관계가 표현 됐는지 점검하는 용도로도 사용된다.
- 초기에는 협업 다이어그램이라고도 불렸다.
커뮤니케이션 다이어그램의 구성 요소
| 구성요소 | 내용 |
| 액터 | 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미한다. |
| 객체 | 메시지를 주고받는 주체이다. |
| 링크 | 객체들 간의 관계를 표현한 것이다. 액터와 객체, 객체와 객체 간에 실선을 그어 표현한다. |
| 메시지 | 객체가 상호 작용을 위해 주고받는 내용이다. 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현한다. 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표시한다. |
상태 다이어그램
- 상태 다이어그램은 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태변화를 그림으로 표현한 것이다.
- 객체의 상태란 객체가 갖는 속성 값의 변화를 의미한다.
- 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용된다.
- 시스템에서 상태변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그린다.
상태 다이어그램의 구성 요소
| 구성 요소 | 내용 |
| 상태 | 객체의 상태를 표현한 것이다. |
| 시작 상태 | 상태의 시작을 표현한 것이다. |
| 종료 상태 | 상태의 종료를 표현한 것이다. |
| 상태 전환 | 상태 사이의 흐름, 변화를 화살표로 표현한 것이다. |
| 이벤트 | 상태에 변화를 주는 현상이다. 이벤트에는 조건, 외부신호, 시간의 흐름 등이 있다. |
| 프레임 | 상태 다이어그램의 범위를 표현한 것이다. |
17. 패키지 다이어그램
패키지 다이어그램
- 유스케이스나 클래스 등의 요소들을 그룹화한 패키지간의 의존 관계를 표현한 것이다.
- 패키지는 또 다른 패키지의 요소가 될 수 있다.
- 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.
패키지 다이어그램의 구성요소
| 구성요소 | 내용 |
| 패키지 | 객체들을 그룹화 시킨 것이다. 단순 표기법 : 패키지 안에 패키지 이름만 표현한다. 확장 표기법 : 패키지 안에 요소까지 표현한다. |
| 객체 | 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들이다. |
| 의존관계 | 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현한다. 스테레오타입을 이요해 의존 관계를 구체적으로 표현할 수 있다. 의존관계의 표현 형태는 사용자가 임의로 작성할 수 있으며, 대표적으로 import와 access가 사용된다 |
18. 소프트웨어 개발 방법론
소프트웨어 개발 방법론
- 소프트웨어 개발, 유지보수 등에 필요한 수행방법과, 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것이다.
- 소프트웨어 개발 방법론의 목적
- 소프트웨어의 생산성과 품질의 향상
- 주요 소프트웨어 개발 방법론
- 구조적 방법론
- 정보공학 방법론
- 객체지향 방법론
- 컴포넌트 기반 방법론
- 제품 계열 방법론
- 애자일 방법론
구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론이다.
- 이해가 쉽고 검증이 가능한 프로그램 코드를 생성하는 것이 목적이다.
- 분할과 정복 원리를 적용한다.
- 개발 절차
타당성 검토 단계 → 계획 단계 → 요구사항 단계 → 설계 단계 → 구현 단계 → 시험 단계 → 운용/유지보수 단계
정보공학 방법론
- 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 통합 및 적용하는 자료 중심의 방법론이다.
- 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는 데 적합하다.
- 개발 절차
정보 전략 계획 수립 단계 → 업무 영역 분석 단계 → 업무 시스템 설계 단계 → 업무 시스템 구축 단계
객체지향 방법론
- 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 객체들을 조립해서 소프트웨어를 구현하는 방법론이다.
- 구성요소
- 객체 : 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
- 클래스 : 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입이다.
- 메시지 : 객체들 간에 상호작용을 하는 데 사용되는 수단으로, 객체에게 어떤 행위를 하도록 지시하는 명려 또는 요구사항이다.
- 기본 원칙
- 캡슐화 : 데이터와 데이터를 처리하는 함수를 하나로 묶는 것이다.
- 정보 은닉 : 캡슐화에서 가장 중요한 개념으로, 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것이다
- 추상화 : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에 중점을 두어 개략화 하는 것이다.
- 상속성 : 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것이다.
- 다형성 : 메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력이다.
- 개발절차
요구 분석 단계 → 설계 단계 → 구현 단계 → 테스트 및 검증 단계 → 인도 단계
컴포넌트 기반 방법론
- 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론이다.
- 컴포넌트의 재사용이 가능하여 시간과 노력을 아낄 수 있다.
- 개발 절차
개발 준비단계 → 분석 단계 → 설계 단계 → 구현 단계 → 테스트 단계 → 전개 단계 → 인도 단계
제품 계열 방법론
- 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론이다.
- 임베디드 소프트웨어를 만드는데 적합하다.
- 영역 공학과 응용공학으로 구분된다.
- 영역 : 영역분석, 영역 설계, 핵심 자산을 구현하는 영역이다.
- 응용 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역이다.
19. 소프트웨어 재사용과 재공학, CASE
소프트웨어 재사용
- 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것이다.
- 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법이다.
- 기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용한다.
- 방법
- 합성 중심 : 전블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로 블록 구성방법이라고도 한다.
- 생성 중심 : 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법, 패턴 구성방법이라고도 한다.
소프트웨어 재공학
- 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상하는 것이다.
- 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하기 때문에 유지보수의 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법이다.
- 이점
- 품질 향상
- 생산성 증가
- 수명 연장
- 오류 감소
CASE(COMPUTER AIDED SOFTWARE ENGINEERING)
- 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것이다.
- 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구이다.
- 주요 기능
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원
20. 비용 산정 기법
소프트웨어 비용 산정
- 개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 확인하여 개발 계획 수립에 필요한 비용을 산정하는 것이다.
- 기법
- 하향식 비용 산정 기법
- 상향식 비용 산정 기법
소프트웨어 비용 결정 요소
- 프로젝트 요소 : 제품 복잡도, 시스템 크기, 요구되는 신뢰도
- 자원요소 : 인적자원, 하드웨어 자원, 소프트웨어 자원
- 생산성 요소 : 개발자의 능력, 개발 기간
21. 하향식 비용 산정 기법
하향식 비용 산정 기법
- 과거의 유사한 경험을 바탕으로 전문지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법이다.
- 전체 비용을 산정한 후 각 작업별 비용을 세분화한다.
- 기법
- 전문가 감정 기법
- 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법이다.
- 델파이 기법
- 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법이다.
- 전문가 감정 기법
22. 상향식 비용 산정 기법
상향식 비용 산정 기법
- 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법이다.
- 주요 기법
- LOC(원시 코드 라인 수) 기법
- 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법이다.
- 개발비용 = 노력(인월) X 투입인원
- 비관치 : 가장 많이 측정된 코드 라인 수
- 낙관치 : 가장 적게 측정된 코드 라인 수
- 기대치 : 측정된 모든 코드 라인 수의 평균
- 개발 단계별 인월수 기법
- LOC 기법을 보완하기 위한 기법이다.
- 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정한다.
- 수학적 산정 기법
- LOC(원시 코드 라인 수) 기법
수학적 산정 기법
- 경험적 추정 모형, 실험적 추정 모형이라고 한다.
- 개발 비용 산정의 자동화를 목표로 한다.
- 주요 기법
- COCOMO 모형
- PUTNAM 모형
- 기능 점수(FP) 모형
COCOMO 모형
- LOC(원시코드 라인 수)에 의한 비용 산정 기법이며 , 보헴이 제안했다.
- COCOMO의 소프트웨어 개발 유형
- 조직형(ORGARNIC) : 기관 내부에서 개발된 중소 규모의 소프트웨어이다. 5만 라인 이하의 소프트웨어 개발 유형이다.
- 반분리형(SEMI-DETACHED) : 조직형과 내부형의 중간, 30만 라인 이하의 소프트웨어 개발 유형이다.
- 내장형(EMBEDDED) : 초대형 규모 30만 라인 이상의 소프트웨어 개발 유형이다.
PUTNAM 모형
- 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형이다.
- Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
기능 점수 모형
- 소프트웨어의 기능을 증대시키는 요인별로 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 기법이다.
- 알브레히트가 제안하였다.
- 소프트웨어 기능 증대 요인
- 자료 입력(입력 양식)
- 정보 출력(출력 보고서)
- 명령어(사용자 질의수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
비용 산정 자동화 추정 도구
- SLIM
- RAYLEIGH-NORDEN 곡선과 PUTNAM 예측 모델을 기초로 하여 개발된 자동화 도구
- ESTIMACS
- 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구
23. 프로젝트 일정 계획
프로젝트 일정 계획
- 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순서와 일정을 정하는 것이다.
- 프로젝트 일정 계획에 사용되는 기능
- WBS : 개발 프로젝트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조
- PERT / CPM : 프로젝트의 지연을 방지하고 계획대로 진행되도록 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해, 비용을 적게 사용하면서 최단시간 내 계획 완성을 위한 프로젝트 일정 방법
- 간트차트
PERT(Program Evaluation and Review Technique)
- 프로젝트에 필요한 전체작업의 상호관계를 표시하는 네트워크이다.
- 각 작업 별 다음과 같이 단계를 나누어 종료시기를 정한다.
- 낙관적인 경우
- 가능성이 있는 경우
- 비관적인 경우
CPM(Critical Path Method, 임계경로 기법)
- 프로젝트에 필요한 작업을 나열하고, 작업에 필요한 소요기간을 예측하는 데 사용하는 기법이다.
- 가장 길게 걸리는 임계경로, 즉 최장경로를 구하면 된다.
간트 차트
- 프로젝트의 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표이다.
- 시간선 차트라고도한다.
- 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있다.
24. 소프트웨어 개발 표준
소프트웨어 개발 표준
- 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준이다.
- 주요 소프트웨어 개발 표준
- ISO / IEC 12207
- CMMI(능력 성숙도 통합 모델)
- SPICE(소프트웨어 처리 개선 및 능력 평가 기준)
ISO / IEC 12207
- ISO(국제표준화 기구)에서 만든 표준 소프트웨어 생명주기 프로세스이다.
- 프로세스 구분
- 기본 생명 주기 프로세스
- 획득, 공급, 개발, 운영, 유지보수
- 지원 생명 주기 프로세스
- 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상관리, 문제해결
- 조직 생명 주기 프로세스
- 관리, 기반 구조, 훈련, 개선
- 기본 생명 주기 프로세스
CMMI(Capability Maturity Model Integration)
- 소프트웨어 개발 조직의 업무 능력 및 조직 성숙도를 평가하는 모델이다.
- 소프트웨어 공학연구소에서 개발하였다.
- CMMI의 소프트웨어 프로세스 성숙도
- 초기 : 작업자의 능력에 따라 성공여부 결정
- 관리 : 특정 프로젝트 내 프로세스 정의 및 수행
- 정의 : 조직의 표준 프로세스를 활용하여 업무 수행
- 정량적 관리 : 프로젝트를 정량적으로 관리 및 통제
- 최적화 : 프로세스 역량 향상을 위해 지속적인 프로세스 개선
SPICE(Software Process Improvement and Capability Determination)
- 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준이다.
- 공식 명칭은 ISO/IEC 15504
- SPICE의 구성
- 고객-공급자 프로세스
- 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성된다.
- 구성요소 : 인수, 공급, 요구 도출, 운영
- 프로세스 수 : 10개
- 공학 프로세스
- 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는 데 사용되는 프로세스로 구성된다.
- 구성요소 : 개발, 소프트웨어 유지보수
- 프로세스 수 : 9개
- 지원 프로세스
- 소프트웨어 생명 주기에 서 다른 프로세스에 의해 이용되는 프로세스로 구성된다.
- 구성 요소 : 문서화, 형상, 품질 보증, 검증, 확인, 리뷰, 감사, 품질 문제해결
- 프로세스 수 : 8개
- 관리 프로세스
- 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성된다.
- 구성요소 : 관리, 프로젝트 관리, 품질 및 위험 관리
- 프로세스 수 : 4개
- 조직 프로세스
- 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성된다.
- 구성요소 : 조직배치, 개선활동 프로세스, 인려관리, 기반 관리, 측정 도구, 재사용
- 프로세스 수 : 9개
- 고객-공급자 프로세스
- SPICE의 프로세스 수행 능력 단계
- 0. 불완전 : 구현되지 않았거나 목적을 달성하지 못한 단계
- 1. 수행 : 수행되고 목적이 달성된 단계
- 2. 관리 : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
- 3. 확립 : 정의된 프로세스가 수행되는 단계
- 4. 예측 : 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
- 5. 최적화 : 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계
- 0. 불완전 : 구현되지 않았거나 목적을 달성하지 못한 단계
- SPICE의 구성
25. 소프트웨어 개발 방법론 테일러링
소프트웨어 개발 방법론 테일러링
- 소프트웨어 개발방법론의 절차, 사용기법 등을 수정 보완하는 작업이다.
- 수행 절차
- 프로젝트 특징 정의 → 표준 프로세스 선정 및 검증 → 상위 수준의 커스터마이징 → 세부 커스터마이징 → 테일러링 문서화
소프트웨어 개발 방법론 테일러링 고려사항
- 내부적 기준
- 목표 환경 : 시스템의 개발 환경과 유형이 서로 다른 경우 테일러링이 필요하다.
- 요구사항 : 프로젝트의 생명 주기 활동에서 개발, 운영, 유지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우 테일러링이 필요하다.
- 프로젝트 규모 : 비용, 인력, 기간 등 프로젝트의 규모가 서로 다른 경우 테일러링이 필요하다.
- 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력 등이 서로 다른 경우 테일러링이 필요하다.
- 외부적 기준
- 법적 제약사항 : 프로젝트별로 적용될 IT Compliance가 서로 다른 경우 테일러링이 필요하다.
- 품질 표준 기준 : 금융, 제도 등의 분야별 표준 품질 기준이 서로 다른 경우 테일러링이 필요하다.
26. 소프트웨어 개발 프레임워크
소프트웨어 개발 프레임워크
- 소프트웨어 개발에 공통적으로 사용되는 구성요소와 아키텍처를 일반화하여 제공해 주는 반제품 형태의 소프트웨어 시스템이다.
- 소프트웨어 개발 프레임워크의 주요 기능
- 예외 처리
- 트랜잭션 처리
- 메모리 공유
- 데이터 소스 관리
- 서비스 관리
- 쿼리 서비스
- 로깅 서비스
- 사용자 인증 서비스
- 소프트웨어 개발 프레임워크 종류
- 스프링 프레임 워크
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다.
- 동적인 웹사이트 개발을 위함이다.
- 전자정부 표준 프레임 워크의 기반 기술로 사용되고 있다.
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다.
- 전자정부 프레임워크
- 대한민국의 공공부문 정보화 사업 시 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크이다.
- 닷넷 프레임 워크
- Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크이다.
- 스프링 프레임 워크
소프트웨어 개발 프레임워크의 특성
- 모듈화
- 캡슐화를 통해 모듈화를 강화하고, 설계 및 구현 변경에 따른 영향 최소화함으로 소프트웨어 품질 향상한다.
- 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이하다.
- 재사용성
- 재사용 가능한 모듈을 제공함으로 예산 절감, 생산성 향상, 품질 보증이 가능하다.
- 확장성
- 다형성을 통한 인터페이스 확장, 다양한 형태와 기능을 가진 애플리케이션 개발이 가능하다.
- 제어의 역흐름
- 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상한다.
'자격증 > 정보처리기사' 카테고리의 다른 글
| [정보처리기사] 실기 요약 정리 화면 설계 (10) | 2023.07.19 |
|---|---|
| [정보처리기사] 실기 요약 정리 인터페이스 구현 (8) | 2023.07.18 |
| [정보처리기사] 실기 요약 정리 서버 프로그램 구현 (8) | 2023.07.18 |
| [정보처리기사] 실기 요약 정리 통합 구현 (9) | 2023.07.18 |
| [정보처리기사] 실기 요약 정리 데이터 입/출력 구현 (9) | 2023.07.17 |
1. 소프트웨어 생명 주기
소프트웨어 생명 주기(Software Life Cycle)
- 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.
- 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현한다.
- 대표적인 생명 주기 모형은 아래와 같이 있다.
- 폭포수 모형
- 프로토타입 모형
- 나선형 모형
- 애자일 모형
폭포수 모형(Waterfall Model)
- 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다.
- 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
- 고전적 생명 주기 모형이라고 한다.
- 모형을 적용한 경험과 성공 사례가 많다.
- 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.
프로토타입 모형(Prototype Model)
- 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형이다.
- 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
나선형 모형(Spiral Model)
- 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형이다.
- 폭포수 모형과 프로토 타입 모형의 장점에 위험분석 기능을 추가한 모형이다.
- 보헴이 제안하였다.
- 중간에 누락되거나 추가된 요구사항을 첨가할 수 있다.
- 계획하고 분석한 뒤 개발하고 평가한다.
![]()
애자일 모형(Agile Model)
- 애자일은 요구사항의 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발하는 모형이다.
- 어느 특정 개발 방법혼이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 말한다.
- 폭포수 모형과 대조적이다.
- 대표적인 개발 모형이다.
애자일 개발의 4가지 핵심 가치
- 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
- 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
- 계약 협상보다는 고객과 협업에 더 가치를 둔다.
- 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.
소프트웨어 공학
- 소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방은으로 연구된 학문이다.
- 여러 가지 방법론과 도구, 관리기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.
- 소프트웨어 공학의 기본 원칙
- 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
- 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.
2. 스크럼
스크럼(Scrum)
- 팀이 중심이 되어 개발의 효율성을 높이는 기법이다.
- 팀원 스스로가 스크럼 팀을 구성하고, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다.
스크럼 팀
- 제품책임자 : 요구사항이 담긴 백로그를 작성하는 주체
- 스크럼 마스터 : 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행한다.
- 개발팀 : 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행한다.
* 백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록
스크럼 개발 프로세스
| 프로세스 | 내용 |
| 스프린트 계획 회의 | 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의이다. |
| 스프린트 | 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행한다. |
| 일일 스크럼 회의 | 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의이다. 남은 작업 시간은 소멸 차트에 표시한다. |
| 스프린트 검토 회의 | 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의이다. |
| 스프린트 회고 | 정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것이다. |
* 제품 백로그 : 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록이다
* 소멸차트 : 스프린트에서 작업의 진행 상황을 확인할 수 있게 시간의 경과에 따라 남은 작업 시간을 그래프로 표현한 것이다.
- 스크럼 개발은 계획하고 스프린트 하면서 회의한 뒤 검토하고 회고한다.
3. XP
XP(eXtreme Programming)
- 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
- XP의 5대 핵심 가치
- 의사소통
- 단순성
- 용기
- 존중
- 피드백
XP 개발 프로세스
| 프로세스 | 내용 |
| 릴리즈 계획 수립 | 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것이다. 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 한다. |
| 이터레이션 | 실제 개발 작업을 진행하는 과정으로 보통 1~3주 정도의 기간으로 진행된다. |
| 승인 검사 | 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트다. |
| 소규모 릴리즈 | 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것 |
XP의 주요 실천 방법
| 실천 방법 | 내용 |
| 짝 프로그래밍 (Pair Programming) |
다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성한다. |
| 공동 코드 소유 (Collective Ownership) |
개발 코드에 대한 권한과 책임을 공동으로 소유한다. |
| 테스트 주도 개발 (Test-Driven Development) |
개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확하게 파악한다. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용한다. |
| 전체 팀 (Whole Team) |
개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 한다. |
| 계속적인 통합 (Continuous Integration) |
모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합된다. |
| 리팩토링 (Refactoring) |
프로그램 기능의 변경 없이 시스템을 재구성한다. 리팩토링의 목적 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함이다. |
| 소규모 릴리즈 (Small Release) |
릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다. |
4. 현행 시스템 파악
현행 시스템 파악 절차
| 프로세스 | 현행 시스템 | 내용 |
| 1단계 | 시스템 구성 파악 | 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술한다. |
| 시스템 기능 파악 | 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시한다. | |
| 시스템 인터페이스 파악 | 단위 업무 시스템간에 주고 받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시한다. | |
| 2단계 | 아키텍쳐 구성 파악 | 최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성한다. |
| 소프트웨어 구성 파악 | 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시한다. | |
| 3단계 | 하드웨어 구성 파악 | 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화 적용 여부를 명시한다. |
| 네트워크 구성 파악 | 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성한다. |
5. 개발 기술 환경 파악
개발 기술 환경 파악의 개요
개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스를 사용할 때 주의해야 할 내용을 제시한다.
운영체제
- 운영체제는 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어이다.
- 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종이다.
- 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공한다.
- 운영체제 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술지원
- 주변기기
- 구축 비용
데이터베이스 관리 시스템(DBMS)
- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어이다.
- 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템이다.
- 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리한다.
- DBMS 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 상호 호환성
- 구축 비용
웹 애플리케이션 서버(WAS)
- 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어이다.
- 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공한다.
- 주로 데이터베이스 서버와 연동해서 사용한다.
- 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
- 가용성
- 성능
- 기술 지원
- 구축 비용
오픈 소스(Open Source)
- 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어이다.
- 오픈 소스 라이선스를 만족한다.
- 오픈 소스 관련 요구사항 식별 시 고려사항
- 라이선스의 종류
- 사용자 수
- 기술의 지속 가능성
6. 요구사항 정의
요구사항
- 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약 조건
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다.
- 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다.
- 요구사항의 유형
- 기능 요구사항
- 비기능 요구사항
- 사용자 요구사항
- 시스템 요구사항
기능 요구사항
- 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
- 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
- 시스템이 반드시 수행해야 하는 기능
- 사용자가 시스템을 통해 제공받기를 원하는 기능
비기능 요구사항
- 품질이나 제약사항과 관련된 요구사항
- 시스템 장비 구성 요구사항
- 성능 요구사항
- 인터페이스 요구사항
- 데이터를 구축하기 위해 필요한 요구사항
- 테스트 요구사항
- 보안 요구사항
- 품질 요구사항
- 가용성
- 정합성
- 상호 호환성
- 대응성
- 이식성
- 확장성
- 보안성
- 제약사항
- 프로젝트 관리 요구사항
- 프로젝트 자원 요구사항
사용자 요구사항
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항이다.
- 사용자를 위한 것으로, 친숙한 표현으로 이해하기 쉽게 작성된다.
시스템 요구사항
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현된다.
- 소프트웨어 요구사항이라고도 한다.
7. 요구사항 개발 프로세스
요구사항 개발 프로세스
- 요구사항 개발 프로세스는 개발 대상에 대한 요구 사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동이다.
- 요구사항 개발 프로세스가 진행되기 전에 타당성 조사가 선행되어야 한다.
- 도출 -> 분석 -> 명세 -> 확인 순서이다.
요구사항 도출
- 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 개발자와 고객 사이의 관계가 만들어지고 이해관계자가 식별된다.
- 소프트웨어 개발 생명주기 동안 지속적으로 반복된다.
- 요구사항을 도출하는 주요 기법
- 청취와 인터뷰
- 설문
- 브레인스토밍
- 워크샵
- 프로토타이핑
- 프로토타입을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업이다.
- 가장 단순한 형태 : 설명을 위해 종이에 대략적인 순서의 형태를 그려 보여주는 것이다.
- 유스케이스 : 사용자의 요구사항을 기능 단위로 표현하는 것
요구사항 분석
- 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.
- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동이다.
- 비용과 일정에 대한 제약을 설정한다.
- 타당성을 조사하며 요구사항 문서를 정의화하고, 목표를 설정한다.
- 서로 상충되는 요구사항이 있으면 이를 중재하는 과정이다.
- 요구사항 분석에 사용되는 대표적인 도구들
- 자료흐름도 : 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법이다. 버블차트라고도한다.
- 자료사전 : 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이다. 메타데이터라고도 한다.
요구사항 명세
- 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미한다.
- 기능 요구사항을 빠짐없이 기술한다.
- 비기능 요구사항은 필요한 것만 기술한다.
- 구체적인 명세를 위해 소단위 명세서가 사용될 수 있다.
요구사항 확인
- 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토하는 활동이다.
- 이해 관계자들이 검토해야 한다.
- 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리를 수행한다.
요구공학
- 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문이다.
- 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트의 실패를 최소화하는 것을 목표로 한다.
요구사항 명세 기법
- 요구 사항 명세기법은 크게 정형과 비정형으로 나뉜다.
| 구분 | 정형 | 비정형 |
| 기법 | 수학적 원리, 모델 기반 | 상태,기능,객체 중심 |
| 작성 방법 | 수학적 기호, 정형화된 표기법 | 일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성 |
| 특징 | 요구사항을 정확하고 간결하게 표현할 수 있다. 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있어 완전한 검증이 가능하다. 표기법이 어려워 사용자가 이해하기 어렵다. |
자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라 다를 수 있다. 그렇기에 일관성이 떨어지고 해석이 달라질 수 있다. 내용의 이해가 쉬워 의사소통이 용이하다. |
| 종류 | VDM, Z, Perti-net, CSP ... | FSM, Decision Table, ER모델링, State Chart ... |
8. 요구사항 분석
요구사항 분석
- 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동이다.
- 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
- 요구사항을 문서를 정의화한다.
- 요구를 정확하게 추출하여 목표를 설정한다.
구조적 분석 기법
- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석방법이다.
- 도형중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화한다.
- 하향식 방법을 사용하여 시스템을 세분화할 수 있다.
- 분석의 중복을 배제할 수 있다.
- 구조적 분석 기법 도구
- 자료 흐름도
- 자료 사전
- 소단위 명세서
- 개체관계도
- 상태전이도
- 제어 명세서
자료 흐름도
- 자료의 흐름 및 변환 과정과 기능을 동형 중심으로 기술하는 방법이다.
- 자료 흐름 그래프, 버블 차트라고도 한다.
- 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다.
- 자료 흐름도의 구성요소
- 프로세스(Process) : 자료를 변환시키는 시스템의 한 부분(처리 과정)
- 자료흐름(Data Flow) : 자료의 이동이나 연관관계
- 자료 저장소(Data Store) : 자료 저장소(파일, 데이터베이스)
- 단말(Terminator) : 시스템과 교신하는 외부 개체
자료 사전
- 자료 흐름도에 있는 자료를 더 자세하게 정의하고 기록한 것이다.
- 데이터를 설명하는 데이터이다.
- 자료 사전에서 사용되는 표기 기호
- 자료의 정의 : = | ~로 구성되어 있다.
- 자료의 연결 : + | 그리고
- 자료의 생략 : () | 생략 가능한 자료
- 자료의 선택 : [] | 또는
- 자료의 반복 : {} | 하단 : n번 이상 반복, 상단 : 최대 n번 반복, 상하단 : 하단이상 상단 이하로 반복
- 자료의 설명 : ** | 주석
9. 요구사항 분석용 CASE
요구사항 분석용 CASE
- 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구이다.
- 대표적인 CASE
- SADT
- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구이다.
- 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구이다.
- softTech 사에서 개발했다.
- SREM
- RSL과 REVS를 사용하는 자동화 도구이다
- RSL : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어이다.
- REVS : RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 명세서를 출력하는 요구사항 분석기이다.
- RSL과 REVS를 사용하는 자동화 도구이다
- PSL/PSA
- PSL : 문제 기술 언어이다.
- PSA : PSL로 기술한 요구사항을 분석하여 보고서를 출력하는 문제 분석기이다.
- 미시간 대학에서 개발하였다.
- TAGS
- 시스템 공학 방법 응용에 대한 자동 접근 방법이다.
- 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구이다.
- SADT
10. HIPO
HIPO
- 시스템 실행과정인 입력, 처리, 출력의 기능을 표현한 것이다.
- 하향식 소프트웨어 개발을 위한 문서화 도구이다.
- 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
- 기호, 도표 등을 사용하므로 보기 쉽고, 이해하기도 쉽다.
- HIPO Chart : 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것
- 가시적 도표
- 총체적 도표
- 세부적 도표
11. UML
UML
- 시스템 개발 과정에서 의사소통이 원활하게 이뤄지도록 표준화한 대표적인 객체 지향 모델링 언어이다.
- 럼바우, 부치, 제이콥슨 등의 객체지향 방법론의 장점을 통합하였다.
- OMG에서 표준으로 지정하였다.
- UML의 구성요소
- 사물
- 관계
- 다이어그램
사물
- 다이어그램 안에서 관계가 형성될 수 있는 대상을 의미한다.
- 모델을 구성하는 가장 중요한 기본 요소이다.
- 사물의 종류
- 구조적
- 시스템의 개념적, 물리적 요소를 표현한다.
- 클래스, Use Case, Component, Node 등
- 행위적
- 시간과 공간에 따른 요소들의 행위를 표현한다.
- 상호작용, 상태머신 등
- 그룹
- 요소들을 그룹으로 묶어서 표현한다.
- 패키지
- 주해
- 부가적인 설명이나 제약조건 등을 표현한다.
- 노드
- 구조적
12. UML - 관계
관계
- 사물과 사물 사이의 연관성을 표현하는 것이다.
- 관계의 종류
- 연관
- 집합
- 포함
- 일반화
- 의존
- 실체화
연관 관계
- 2개 이상의 사물이 서로 관련되어 있는 관계다.
- 사물 사이를 실선으로 연결하여 표현한다.
- 방향성은 화살표로 나타낸다.
- 양방향의 경우 실선으로만 연결한다.
- 다중도를 선 위에 표기한다.
- 다중도 : 연관에 참여하는 객체의 개수
집합 관계
- 하나의 사물이 다른 사물에 포함되어 있는 관계이다.
- 서로 독립적이다.
- 속이 빈 마름모를 통해 연결한다.
포함 관계
- 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계이다.
- 서로 독립될 수 없고, 생명주기를 함께한다.
- 속이 채워진 마름모를 통해 연결한다.
일반화 관계
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계이다.
- 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.
- 속이 빈 화살표로 연결한다.
의존 관계
- 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계이다.
- 하나의 사물과 다른 사물이 소유관계는 아니지만, 사물의 변화가 다른 사물에도 영향을 미치는 관계이다.
- 점선 화살표로 연결한다.
실체화 관계
- 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화할 수 있는 관계이다.
- 속이 빈 점선 화살표로 연결한다.
13. UML - 다이어그램
다이어그램
- 사물과 관계를 도형으로 표현한 것이다.
- 정적 모델링에서는 주로 구조적 다이어그램을 사용한다
- 동적 모델링에서는 주로 행위 다이어그램을 사용한다
구조적 다이어 그램의 종류
| 종류 | 내용 |
| 클래스 다이어그램 | 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다. |
| 객체 다이어그램 | 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현한다. 럼바우의 객체지향 분석 기법에서 객체 모델링에 활용된다. |
| 컴포넌트 다이어그램 | 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현한다. 구현 단계에서 사용된다. |
| 배치 다이어그램 | 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다. 구현 단계에서 사용된다. |
| 복함체 구조 다이어그램 | 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다. |
| 패키지 다이어그램 | 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현한다. |
행위 다이어그램의 종류
| 종류 | 내용 |
| 유스케이스 다이어그램 | 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용한다. 사용자와 사용 사례로 구성된다. |
| 시퀸스 다이어그램 | 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현한다. |
| 커뮤니케이션 다이어그램 | 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현한다. |
| 상태 다이어그램 | 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현한다. 럼바우의 객체지향 분석 기법에서 동적 모델링에 활용된다. |
| 활동 다이어그램 | 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라표현한다. |
| 상호작용 개요 다이어그램 | 상호작용 다이어그램 간의 제어 흐름을 표현한다. |
| 타이밍 다이어그램 | 객체 상태 변화와 시간 제약을 명시적으로 표현한다. |
스테레오 타입
- UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것이다.
- 길러멧이라고 부르는 겹화살괄호( <<>>) 사이에 표현할 형태를 기술한다.
| 표현 | 뜻 |
| <<interface>> | 인터페이스 클래스 |
| <<abstract>> | 추상화 클래스 |
| <<enumeration>> | 열거형 타입 클래스 |
| <<utilty>> | 인스턴스가 없는 static 메서드만 모아둔 클래스 |
| <<create>> | 생성자 |
14. 기능 모델링과 종류 (유스케이스, 활동 다이어그램)
기능 모델링
- 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것이다.
- 개발될 시스템의 전반적인 형태를 기능에 초점을 맞춰 표현한다.
- 기능 모델링의 종류
- 유스케이스 다이어그램
- 액티비티 다이어그램
유스케이스 다이어그램
- 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있도록 사용자 관점에서 표현한 것이다.
- 외부 요소와 시스템 간의 상호 작용을 확인할 수 있다.
- 사용자의 요구사항을 분석하기 위한 도구로 사용된다.
- 시스템의 범위를 파악할 수 있다.
유스케이스 다이어그램의 구성요소
| 구성요소 | 내용 |
| 시스템 | 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것이다. |
| 액터 | 시스템과 상호작용을 하는 모든 외부요소 주로 사람이나 외부 시스템을 의미한다. 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당된다. 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관등이 될 수 있다. |
| 유스케이스 | 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것이다. |
| 관계 | 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있다. 유스케이스에서 나타날 수 있는 관계 : 포함, 확장, 일반화 관계 |
*포함관계 : 2개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계이다.
원래의 유스케이스에서 새롭게 포함되는 유스케이스에 점선 화살표를 연결한 뒤, <<\include>>라고 표기한다.
* 확장관계 : 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계이다.
확장될 유스케이스에서 원래의 유스케이스 쪽으로 점선화살표를 연결한 뒤, <<\extends>>라고 표기한다.
활동 다이어그램
- 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것이다.
- 하나의 유스케이스 안에서 혹은 유스케이스 사이에 발생하는 복잡한 처리의 흐름을 명확하게 표현할 수 있다.
- 자료흐름도와 유사하다.
활동 다이어그램의 구성요소
| 구성요소 | 내용 |
| 액션 / 액티비티 | 액션 : 더 이상 분해할 수 없는 단일 작업이다. 액티비티 : 몇 개의 액션으로 분리될 수 있는 작업이다. |
| 시작 노드 | 액션이나 액티비티가 시작됨을 표현한 것이다. |
| 종료 노드 | 액티비티 안의 모든 흐름이 종료됨을 표현한 것이다. |
| 조건(판단) 노드 | 조건에 따라 제어의 흐름이 분리됨을 표현한 것이다. 들어오는 제어 흐름은 1개이고, 나가는 제어 흐름은 여러 개이다. |
| 병합 노드 | 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것이다. 들어오는 제어 흐름은 여러개이고, 나가는 제어흐름은 1개이다. |
| 포크 노드 | 액티비티의 흐름이 분리되어 수행됨을 표현한 것이다. 들어오는 액티비티 흐름은 1개이고, 나가는 액티비티 흐름은 여러개 이다. |
| 조인 노드 | 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것이다. 들어오는 액티비티 흐름은 여러개 이고, 나가는 액티비티 흐름은 1개이다. |
| 스윔레인 | 액티비티 수행을 담당하는 주체를 구분하는 선 가로 또는 세로 실선을 그어 구분한다. |
15. 정적 모델링과 클래스 다이어그램
정적 모델링
- 사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적인 구조를 표현한 것이다.
- 시스템에 의해 처리되거나 생성될 객체들 사이에 어떤 관련이 있는지를 구조적인 관점에서 표현한다.
- 정적 모델링은 객체들을 클래스로 추상화하여 표현한다.
- UML을 이용한 정적 모델링의 대표적인 것이 클래스 다이어그램이다.
클래스 다이어그램
- 클래스와 클래스가 자신을 가지는 속성, 클래스 사이의 관계를 표현한 것이다.
- 시스템을 구성하는 요소에 대해 이해할 수 있는 구조적 다이어그램이다.
- 시스템 구성요소를 문서화하는 데 사용된다.
클래스 다이어그램의 구성요소
| 구성요소 | 내용 |
| 클래스 | 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한 것이다. 일반적으로 3개의 구획으로 나워 클래스의 이름, 속성, 오퍼레이션을 표기한다. 속성 : 클래스의 상태나 정보를 표현한다. 오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수(메소드) 라고도 한다. |
| 제약 조건 | 속성에 입력될 값에 대한 제약 조건이나 오퍼레이션 수행 전 후에 지정해야 할 조건이 있다면 이를 적는다. 클래스 안에 제약조건을 기술할 때는 중괄호를 이용한다. |
| 관계 | 관계는 클래스와 클래스 사이의 연관성을 표현한다. 클래스 다이어그램에 표현하는 관계에는 연관, 집합, 포함, 일반화, 의존 관계가 있다. |
클래스 다이어그램 - 연관 클래스
- 연관 관계에 있는 두 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스이다.
- 두 클래스의 연관 관계를 나타내는 선의 가운데로 부터 점선을 연관 클래스로 이어 표시한다.
- 연관 클래스의 이름은 연관 관계의 이름을 이용해 지정한다.
16. 동적 모델링과 종류 (시퀀스, 커뮤니케이션, 상태 다이어그램)
동적 모델링
- 시스템의 내부 구성 요소들의 상태 변화 과정과 과정에서 발생하는 상호 작용을 표현한 것이다.
- 시스템 내부 구성 요소들 간에 이뤄지는 동작이라는 관점에서 표현한다.
- 시스템이 실행될 때 구성 요소들 간의 메시지 호출, 즉 오퍼레이션을 통한 상호 작용에 초점을 둔다.
- 동적 모델링의 종류
- 시퀀스 다이어그램
- 커뮤니케이션 다이어그램
- 상태 다이어그램
시퀀스 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것이다.
- 각 동작에 참여하는 시스템이나 객체들의 수행기간을 확인할 수 있다.
- 클래스 내부에 있는 객체들을 기본 단위로 하여 그들의 상호 작용을 표현한다.
시퀀스 다이어그램의 구성요소
| 구성요소 | 내용 |
| 액터 | 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미한다. |
| 객체 | 메시지를 주고받는 주체이다. |
| 생명선 | 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현한다. 객체 소멸(X)이 표시된 기간까지 존재한다. |
| 실행상자 | 객체가 메시지를 주고 받으며 구동되고 있음을 표현한다. |
| 메시지 | 객체가 상호작용을 위해 주고 받는 메시지다. |
| 객체 소멸 | 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것이다. |
| 프레임 | 다이어그램의 전체 또는 일부를 묶어 표현한 것이다. |
커뮤니케이션 다이어그램
- 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것이다.
- 동작에 참여하는 객체들 사이의 관계를 파악하는 데 사용된다.
- 클래스 다이어그램에서 관계가 표현 됐는지 점검하는 용도로도 사용된다.
- 초기에는 협업 다이어그램이라고도 불렸다.
커뮤니케이션 다이어그램의 구성 요소
| 구성요소 | 내용 |
| 액터 | 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미한다. |
| 객체 | 메시지를 주고받는 주체이다. |
| 링크 | 객체들 간의 관계를 표현한 것이다. 액터와 객체, 객체와 객체 간에 실선을 그어 표현한다. |
| 메시지 | 객체가 상호 작용을 위해 주고받는 내용이다. 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현한다. 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표시한다. |
상태 다이어그램
- 상태 다이어그램은 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태변화를 그림으로 표현한 것이다.
- 객체의 상태란 객체가 갖는 속성 값의 변화를 의미한다.
- 특정 객체가 어떤 이벤트에 의해 상태 변환 과정이 진행되는지 확인하는 데 사용된다.
- 시스템에서 상태변환 이벤트를 확인할 필요가 있는 객체만을 대상으로 그린다.
상태 다이어그램의 구성 요소
| 구성 요소 | 내용 |
| 상태 | 객체의 상태를 표현한 것이다. |
| 시작 상태 | 상태의 시작을 표현한 것이다. |
| 종료 상태 | 상태의 종료를 표현한 것이다. |
| 상태 전환 | 상태 사이의 흐름, 변화를 화살표로 표현한 것이다. |
| 이벤트 | 상태에 변화를 주는 현상이다. 이벤트에는 조건, 외부신호, 시간의 흐름 등이 있다. |
| 프레임 | 상태 다이어그램의 범위를 표현한 것이다. |
17. 패키지 다이어그램
패키지 다이어그램
- 유스케이스나 클래스 등의 요소들을 그룹화한 패키지간의 의존 관계를 표현한 것이다.
- 패키지는 또 다른 패키지의 요소가 될 수 있다.
- 대규모 시스템에서 주요 요소 간의 종속성을 파악하는 데 사용한다.
패키지 다이어그램의 구성요소
| 구성요소 | 내용 |
| 패키지 | 객체들을 그룹화 시킨 것이다. 단순 표기법 : 패키지 안에 패키지 이름만 표현한다. 확장 표기법 : 패키지 안에 요소까지 표현한다. |
| 객체 | 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들이다. |
| 의존관계 | 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현한다. 스테레오타입을 이요해 의존 관계를 구체적으로 표현할 수 있다. 의존관계의 표현 형태는 사용자가 임의로 작성할 수 있으며, 대표적으로 import와 access가 사용된다 |
18. 소프트웨어 개발 방법론
소프트웨어 개발 방법론
- 소프트웨어 개발, 유지보수 등에 필요한 수행방법과, 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것이다.
- 소프트웨어 개발 방법론의 목적
- 소프트웨어의 생산성과 품질의 향상
- 주요 소프트웨어 개발 방법론
- 구조적 방법론
- 정보공학 방법론
- 객체지향 방법론
- 컴포넌트 기반 방법론
- 제품 계열 방법론
- 애자일 방법론
구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론이다.
- 이해가 쉽고 검증이 가능한 프로그램 코드를 생성하는 것이 목적이다.
- 분할과 정복 원리를 적용한다.
- 개발 절차
타당성 검토 단계 → 계획 단계 → 요구사항 단계 → 설계 단계 → 구현 단계 → 시험 단계 → 운용/유지보수 단계
정보공학 방법론
- 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 통합 및 적용하는 자료 중심의 방법론이다.
- 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는 데 적합하다.
- 개발 절차
정보 전략 계획 수립 단계 → 업무 영역 분석 단계 → 업무 시스템 설계 단계 → 업무 시스템 구축 단계
객체지향 방법론
- 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 객체들을 조립해서 소프트웨어를 구현하는 방법론이다.
- 구성요소
- 객체 : 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
- 클래스 : 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입이다.
- 메시지 : 객체들 간에 상호작용을 하는 데 사용되는 수단으로, 객체에게 어떤 행위를 하도록 지시하는 명려 또는 요구사항이다.
- 기본 원칙
- 캡슐화 : 데이터와 데이터를 처리하는 함수를 하나로 묶는 것이다.
- 정보 은닉 : 캡슐화에서 가장 중요한 개념으로, 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것이다
- 추상화 : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에 중점을 두어 개략화 하는 것이다.
- 상속성 : 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것이다.
- 다형성 : 메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력이다.
- 개발절차
요구 분석 단계 → 설계 단계 → 구현 단계 → 테스트 및 검증 단계 → 인도 단계
컴포넌트 기반 방법론
- 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론이다.
- 컴포넌트의 재사용이 가능하여 시간과 노력을 아낄 수 있다.
- 개발 절차
개발 준비단계 → 분석 단계 → 설계 단계 → 구현 단계 → 테스트 단계 → 전개 단계 → 인도 단계
제품 계열 방법론
- 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론이다.
- 임베디드 소프트웨어를 만드는데 적합하다.
- 영역 공학과 응용공학으로 구분된다.
- 영역 : 영역분석, 영역 설계, 핵심 자산을 구현하는 영역이다.
- 응용 : 제품 요구 분석, 제품 설계, 제품을 구현하는 영역이다.
19. 소프트웨어 재사용과 재공학, CASE
소프트웨어 재사용
- 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것이다.
- 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법이다.
- 기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용한다.
- 방법
- 합성 중심 : 전블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로 블록 구성방법이라고도 한다.
- 생성 중심 : 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법, 패턴 구성방법이라고도 한다.
소프트웨어 재공학
- 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상하는 것이다.
- 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하기 때문에 유지보수의 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법이다.
- 이점
- 품질 향상
- 생산성 증가
- 수명 연장
- 오류 감소
CASE(COMPUTER AIDED SOFTWARE ENGINEERING)
- 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것이다.
- 객체지향 시스템, 구조적 시스템 등 다양한 시스템에서 활용되는 자동화 도구이다.
- 주요 기능
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원
20. 비용 산정 기법
소프트웨어 비용 산정
- 개발에 소요되는 인원, 자원, 기간 등으로 소프트웨어의 규모를 확인하여 개발 계획 수립에 필요한 비용을 산정하는 것이다.
- 기법
- 하향식 비용 산정 기법
- 상향식 비용 산정 기법
소프트웨어 비용 결정 요소
- 프로젝트 요소 : 제품 복잡도, 시스템 크기, 요구되는 신뢰도
- 자원요소 : 인적자원, 하드웨어 자원, 소프트웨어 자원
- 생산성 요소 : 개발자의 능력, 개발 기간
21. 하향식 비용 산정 기법
하향식 비용 산정 기법
- 과거의 유사한 경험을 바탕으로 전문지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법이다.
- 전체 비용을 산정한 후 각 작업별 비용을 세분화한다.
- 기법
- 전문가 감정 기법
- 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법이다.
- 델파이 기법
- 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법이다.
- 전문가 감정 기법
22. 상향식 비용 산정 기법
상향식 비용 산정 기법
- 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법이다.
- 주요 기법
- LOC(원시 코드 라인 수) 기법
- 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법이다.
- 개발비용 = 노력(인월) X 투입인원
- 비관치 : 가장 많이 측정된 코드 라인 수
- 낙관치 : 가장 적게 측정된 코드 라인 수
- 기대치 : 측정된 모든 코드 라인 수의 평균
- 개발 단계별 인월수 기법
- LOC 기법을 보완하기 위한 기법이다.
- 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정한다.
- 수학적 산정 기법
- LOC(원시 코드 라인 수) 기법
수학적 산정 기법
- 경험적 추정 모형, 실험적 추정 모형이라고 한다.
- 개발 비용 산정의 자동화를 목표로 한다.
- 주요 기법
- COCOMO 모형
- PUTNAM 모형
- 기능 점수(FP) 모형
COCOMO 모형
- LOC(원시코드 라인 수)에 의한 비용 산정 기법이며 , 보헴이 제안했다.
- COCOMO의 소프트웨어 개발 유형
- 조직형(ORGARNIC) : 기관 내부에서 개발된 중소 규모의 소프트웨어이다. 5만 라인 이하의 소프트웨어 개발 유형이다.
- 반분리형(SEMI-DETACHED) : 조직형과 내부형의 중간, 30만 라인 이하의 소프트웨어 개발 유형이다.
- 내장형(EMBEDDED) : 초대형 규모 30만 라인 이상의 소프트웨어 개발 유형이다.
PUTNAM 모형
- 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형이다.
- Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
기능 점수 모형
- 소프트웨어의 기능을 증대시키는 요인별로 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 기법이다.
- 알브레히트가 제안하였다.
- 소프트웨어 기능 증대 요인
- 자료 입력(입력 양식)
- 정보 출력(출력 보고서)
- 명령어(사용자 질의수)
- 데이터 파일
- 필요한 외부 루틴과의 인터페이스
비용 산정 자동화 추정 도구
- SLIM
- RAYLEIGH-NORDEN 곡선과 PUTNAM 예측 모델을 기초로 하여 개발된 자동화 도구
- ESTIMACS
- 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구
23. 프로젝트 일정 계획
프로젝트 일정 계획
- 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 소작업의 순서와 일정을 정하는 것이다.
- 프로젝트 일정 계획에 사용되는 기능
- WBS : 개발 프로젝트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조
- PERT / CPM : 프로젝트의 지연을 방지하고 계획대로 진행되도록 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해, 비용을 적게 사용하면서 최단시간 내 계획 완성을 위한 프로젝트 일정 방법
- 간트차트
PERT(Program Evaluation and Review Technique)
- 프로젝트에 필요한 전체작업의 상호관계를 표시하는 네트워크이다.
- 각 작업 별 다음과 같이 단계를 나누어 종료시기를 정한다.
- 낙관적인 경우
- 가능성이 있는 경우
- 비관적인 경우
CPM(Critical Path Method, 임계경로 기법)
- 프로젝트에 필요한 작업을 나열하고, 작업에 필요한 소요기간을 예측하는 데 사용하는 기법이다.
- 가장 길게 걸리는 임계경로, 즉 최장경로를 구하면 된다.
간트 차트
- 프로젝트의 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표이다.
- 시간선 차트라고도한다.
- 이정표, 작업 일정, 작업 기간, 산출물로 구성되어 있다.
24. 소프트웨어 개발 표준
소프트웨어 개발 표준
- 소프트웨어 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준이다.
- 주요 소프트웨어 개발 표준
- ISO / IEC 12207
- CMMI(능력 성숙도 통합 모델)
- SPICE(소프트웨어 처리 개선 및 능력 평가 기준)
ISO / IEC 12207
- ISO(국제표준화 기구)에서 만든 표준 소프트웨어 생명주기 프로세스이다.
- 프로세스 구분
- 기본 생명 주기 프로세스
- 획득, 공급, 개발, 운영, 유지보수
- 지원 생명 주기 프로세스
- 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상관리, 문제해결
- 조직 생명 주기 프로세스
- 관리, 기반 구조, 훈련, 개선
- 기본 생명 주기 프로세스
CMMI(Capability Maturity Model Integration)
- 소프트웨어 개발 조직의 업무 능력 및 조직 성숙도를 평가하는 모델이다.
- 소프트웨어 공학연구소에서 개발하였다.
- CMMI의 소프트웨어 프로세스 성숙도
- 초기 : 작업자의 능력에 따라 성공여부 결정
- 관리 : 특정 프로젝트 내 프로세스 정의 및 수행
- 정의 : 조직의 표준 프로세스를 활용하여 업무 수행
- 정량적 관리 : 프로젝트를 정량적으로 관리 및 통제
- 최적화 : 프로세스 역량 향상을 위해 지속적인 프로세스 개선
SPICE(Software Process Improvement and Capability Determination)
- 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준이다.
- 공식 명칭은 ISO/IEC 15504
- SPICE의 구성
- 고객-공급자 프로세스
- 소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어의 정확한 운용 및 사용을 위한 프로세스로 구성된다.
- 구성요소 : 인수, 공급, 요구 도출, 운영
- 프로세스 수 : 10개
- 공학 프로세스
- 시스템과 소프트웨어 제품의 명세화, 구현, 유지보수를 하는 데 사용되는 프로세스로 구성된다.
- 구성요소 : 개발, 소프트웨어 유지보수
- 프로세스 수 : 9개
- 지원 프로세스
- 소프트웨어 생명 주기에 서 다른 프로세스에 의해 이용되는 프로세스로 구성된다.
- 구성 요소 : 문서화, 형상, 품질 보증, 검증, 확인, 리뷰, 감사, 품질 문제해결
- 프로세스 수 : 8개
- 관리 프로세스
- 소프트웨어 생명 주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성된다.
- 구성요소 : 관리, 프로젝트 관리, 품질 및 위험 관리
- 프로세스 수 : 4개
- 조직 프로세스
- 조직의 업무 목적 수립과 조직의 업무 목표 달성을 위한 프로세스로 구성된다.
- 구성요소 : 조직배치, 개선활동 프로세스, 인려관리, 기반 관리, 측정 도구, 재사용
- 프로세스 수 : 9개
- 고객-공급자 프로세스
- SPICE의 프로세스 수행 능력 단계
- 0. 불완전 : 구현되지 않았거나 목적을 달성하지 못한 단계
- 1. 수행 : 수행되고 목적이 달성된 단계
- 2. 관리 : 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
- 3. 확립 : 정의된 프로세스가 수행되는 단계
- 4. 예측 : 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
- 5. 최적화 : 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계
- 0. 불완전 : 구현되지 않았거나 목적을 달성하지 못한 단계
- SPICE의 구성
25. 소프트웨어 개발 방법론 테일러링
소프트웨어 개발 방법론 테일러링
- 소프트웨어 개발방법론의 절차, 사용기법 등을 수정 보완하는 작업이다.
- 수행 절차
- 프로젝트 특징 정의 → 표준 프로세스 선정 및 검증 → 상위 수준의 커스터마이징 → 세부 커스터마이징 → 테일러링 문서화
소프트웨어 개발 방법론 테일러링 고려사항
- 내부적 기준
- 목표 환경 : 시스템의 개발 환경과 유형이 서로 다른 경우 테일러링이 필요하다.
- 요구사항 : 프로젝트의 생명 주기 활동에서 개발, 운영, 유지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우 테일러링이 필요하다.
- 프로젝트 규모 : 비용, 인력, 기간 등 프로젝트의 규모가 서로 다른 경우 테일러링이 필요하다.
- 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력 등이 서로 다른 경우 테일러링이 필요하다.
- 외부적 기준
- 법적 제약사항 : 프로젝트별로 적용될 IT Compliance가 서로 다른 경우 테일러링이 필요하다.
- 품질 표준 기준 : 금융, 제도 등의 분야별 표준 품질 기준이 서로 다른 경우 테일러링이 필요하다.
26. 소프트웨어 개발 프레임워크
소프트웨어 개발 프레임워크
- 소프트웨어 개발에 공통적으로 사용되는 구성요소와 아키텍처를 일반화하여 제공해 주는 반제품 형태의 소프트웨어 시스템이다.
- 소프트웨어 개발 프레임워크의 주요 기능
- 예외 처리
- 트랜잭션 처리
- 메모리 공유
- 데이터 소스 관리
- 서비스 관리
- 쿼리 서비스
- 로깅 서비스
- 사용자 인증 서비스
- 소프트웨어 개발 프레임워크 종류
- 스프링 프레임 워크
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다.
- 동적인 웹사이트 개발을 위함이다.
- 전자정부 표준 프레임 워크의 기반 기술로 사용되고 있다.
- 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크이다.
- 전자정부 프레임워크
- 대한민국의 공공부문 정보화 사업 시 정보 시스템의 구축을 지원하기 위해 필요한 기능 및 아키텍처를 제공하는 프레임워크이다.
- 닷넷 프레임 워크
- Windows 프로그램의 개발 및 실행 환경을 제공하는 프레임워크이다.
- 스프링 프레임 워크
소프트웨어 개발 프레임워크의 특성
- 모듈화
- 캡슐화를 통해 모듈화를 강화하고, 설계 및 구현 변경에 따른 영향 최소화함으로 소프트웨어 품질 향상한다.
- 프레임워크는 개발 표준에 의한 모듈화로 인해 유지 보수가 용이하다.
- 재사용성
- 재사용 가능한 모듈을 제공함으로 예산 절감, 생산성 향상, 품질 보증이 가능하다.
- 확장성
- 다형성을 통한 인터페이스 확장, 다양한 형태와 기능을 가진 애플리케이션 개발이 가능하다.
- 제어의 역흐름
- 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상한다.
'자격증 > 정보처리기사' 카테고리의 다른 글
| [정보처리기사] 실기 요약 정리 화면 설계 (10) | 2023.07.19 |
|---|---|
| [정보처리기사] 실기 요약 정리 인터페이스 구현 (8) | 2023.07.18 |
| [정보처리기사] 실기 요약 정리 서버 프로그램 구현 (8) | 2023.07.18 |
| [정보처리기사] 실기 요약 정리 통합 구현 (9) | 2023.07.18 |
| [정보처리기사] 실기 요약 정리 데이터 입/출력 구현 (9) | 2023.07.17 |
