1과목 : 소프트웨어 설계 (1장. 요구사항 확인 : 주요 키워드 정리)

1장 요구사항 확인

 

1-0. 소프트웨어 생명주기

- 소프트웨어 개발 단계와 각 단계별 주요 활동. 소프트웨어 생명주기라고도 함.

ex) 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형

 

1-1. 폭포수 모형

- 소프트웨어 개발도 이전 단계로 돌아갈 수 없음.

- 각 단계를 확실하게 매듭지어야 함.

- 두 개 이상의 과정을 병행할 수 없음.

- 메뉴얼 작성 필요.

 

1-2. 프로토타입 모델

- 기능적인 부분만 중점(인터페이스 중점)

- 폭포수 모형의 단점을 보완한 모델

- 견본 시제품을 만들어 최종 결과물을 예측.

 

1-3. 나선형 모델

- 계획 - 분석 - 개발 - 평가의 순서대로 반복

- 여러 번의 개발 과정을 거침.

- 점진적 개발, 위험관리, 최소화가 목적

 

1-4. 애자일 모델

- 절차와 모델보다는 고객과의 상호작용을 중심.

- 문서 보다는 고객 중심.

ex) 스크럼, XP 등등

 

1-4-1. 스크럼 기법

- 팀이 중심이 되어 개발의 효율성을 높인다는 의미

- 역할

• 제품 책임자 : 의사결정자, 백로그의 우선순위 지정
• 스크럼 마스터 : 일일책의 주관, 개발 가이드
• 개발 팀: 개발자, 디자이너, 테스터 등 모든 인원
• 프로세스 :
  • 백로그 : 요구사항을 우선 순위에 따라 모아놓은 목록
  • 계획회의 : 스프린터 일정 수립, 개발자 별로 스프린터 백로그 작성
  • 스프린터 진행 : 할일, 진행중, 완료
  • 일일 회의 : 스크럼 마스터 주도, 소멸차트 활용
  • 검토 회의 : 주별, PO 지도, 백로그 업데이트
  • 회고 : 지난 일정 돌아보기, 개선점 찾기

 

1-4-2. XP 기법

- 짧고 반복적인 개발 주기, 고객의 적극적 참여를 통한 가시성 향상, 소규모 인원의 개발 프로젝트에 효과적임.

- 핵심 가치 : 피존용단소(피드백, 존중, 용기, 단순화, 소통)

- 개발 프로세스:

• 사용자 스토리 : 고객의 요구사항
• 릴리즈 계획수립 : 부분과 전체의 개발일정 수립
• 스파이크 : 기술 및 기능 확인을 위해 간단히 만드는 프로그램
• 이터레이션 : 릴리즈를 좀 더 세분화 한 단위
• 승인 검사 : 부분 소프트웨어가 릴리즈 되면 고객이 직접 평가
• 소규모 릴리즈 : 릴리즈 별로, 고객의 피드백 확인 가능.

 

1-5. 현행 시스템 파악

- 구기인 아소하네

• 구 : 시스템 구성 파악 (기간 업무와 지원 업무의 주요 기능을 파악)
• 기 : 시스템 기능 파악 ( 주요 기능별 세부 기능들을 목록형으로 표시)
• 인 : 시스템 인터페이스 파악 ( 주고받는 데이터의 형식, 프로토콜 파악)
• 아 : 아키텍처 구성 파악 ( 모든 업무 시스템의 구성과 동작원리를 표현)
• 소 : 소프트웨어 구성 파악 ( 종류 및 라이센스의 적용방식과 비용)
• 하 : 하드웨어 구성 파악 ( 클라이언트의 주요 사양과 수량, 이중화 적용)
• 네 : 네트워크 구성 파악 ( 구성도 작성, 논리적 위치, 보안 취약점, 유지보수)

 

1-6. 개발기술 환경 파악

• 운영체제 : 시스템 자원관리, 하드웨어 제어를 위한 인터페이스
• DBMS : 데이터베이스 관리 시스템, 종속성과 중복성 해결, DB에 대한 모든 권한과 책임이 있음
• 웹 어플리케이션 서버(WAS) : 동적 콘텐츠를 처리를 위한 미들웨어, DB서버와 미들웨어를 연동한다
  (미들웨어 : 서버와 클라이언트 중간에 위치하여, 클라이언트 대신 복잡한 처리를 함.)
• 공통 고려사항
  • 가용성, 성능, 비용, 기술지원

 

1-7. 요구사항 정의

- 요구사항 : 서비스에 대한 설명 및 제약조건

• 기능 요구사항 : 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
• 비기능 요구사항 : 품질이나 제약사항과 관련된 요구사항
• 사용자 요구사항 : 사용자 관점에서 본 시스템이 제공해야 할 요구사항
• 시스템 요구사항 : 개발자 관점에서 본 시스템이 제공해야할 요구사항

- 요구사항 개발 프로세스 : 도출 -> 분석 -> 명세 -> 확인

• 요구사항 도출 : 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 식별하고 이해하는 과정
• 요구사항 분석 : 요구사항 중 이해되지 않는 부분을 걸러내기 위한 과정
• 요구사항 명세 : 분석된 요구사항을 바탕으로 모델을 작성하고 문서화 하는 것
• 요구사항 확인 : 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

- 요구 공학 : 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

- 요구사항 명세기법 : 정형 명세 기법(수학적 원리 기반, 모델기반), 비정형 명세 기법(상태/기능/객체 중심)

 

1.8 요구사항 분석기법 종류

• 구조적 분석 기법 ( 사용자의 요구사항을 파악, 분석가와 사용자간의 대화가 용이)
• 자료 흐름도(DFD, 요구사항 분석에서의 자료의 흐름) (ex. 프로세스, 자료흐름, 자료 저장소, 단말)
• 자료 사전( 자료 흐름도에 있는 자료를 더 자세히 정의한 것)
  • = : 자료 정의, + : 자료의 연결, () : 자료의 생략, [] : 자료의 선택, {} : 자료의 반복, **: 자료의 설명

 

1-9. 요구사항 분석 자동화 도구

• CASE 
  • 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술함.
  • 종류 : SADT, SREM, PSL/PSA, TAGS
    • SADT : 블록 다이어그램을 채택한 자동화 도구
    • SREM : RSL과 REVS를 사용하는 자동화 도구
    • PSL/PSA : PSL과 PSA를 사용하는 자동화 도구
    • TAGS : 통합 자동화 도구
• HIPO
  • 하향식 소프트웨어 개발을 위한 문서화 도구, 시스템의 분석 및 설계나 문서화할 때 주로 사용.
  • 종류 : 가시적 도표, 총체적 도표, 세부적 도표

 

1-10. UML

- 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 언어

- 종류 ( 사물, 관계, 다이어그램)

• 사물 : 모델을 구성하는 가장 중요한 기본 요소
• 관계 : 사물과 사물의 연관성
  • 연관 관계 : 2개 이상의 사물이 서로 연관 ( ex. 사람 → 집)
  • 집합 관계 : 하나의 사물이 다른 사물에 포함 ( ex. 컴퓨터◇-프린터)
  • 포함 관계 : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계 ( ex. 문◆-키)
  • 일반화 관계 : 하나의 사물이 다른 사물에 비해 일반적, 구체적 표현 ( ex. 아메리카노, 에스프레소 -▷커피)
  • 의존 관계 : 서로에게 영향을 주는 짧은 시간 동안만 연관관계를 유지 ( ex. 등급 '''''''> 할인율 )
  • 실체화 : 서로를 그룹화 할 수 있는 관계 ( ex. 비행기, 새 '''''''▷ 날 수 있는)
• 다이어그램 : 사물과 관계를 도형으로 표현한 것
  • 구조적 다이어그램(배컴복객클패)
    • 배치 다이어그램, 컴포넌트 다이어그램, 복합체 구조 다이어그램, 객체 다이어그램, 클래스 다이어그램, 패키지 다이어그램
  • 행위 다이어그램(상상유시커타활)
    • 상태 다이어그램, 상호작용 다이어그램, 유스케이스 다이어그램, 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 타이밍 다이어그램, 활동 다이어그램
• 스테레오 타입 : UML에서 기본기능 이외에 추가적인 기능을 표현 한것 << >>
  • <<include>> : 포함, <<extends>> : 확장, <<interface>> : 인터페이스 정의,
  • <<exception>> : 예외 정의, <<constructor>> : 생성자
• 주요 UML 다이어그램
  • 유스케이스 다이어그램 : 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현
  • 클래스 다이어그램 : 시스템을 구성하는 클래스, 클래스 사이의 관계를 표현
  • 시퀀스 다이어그램 : 시스템이나 객체들이 메시지를 주고 받으며 시간의 흐름에 따라 상호작용하는 과정을 그림으로 표현