소프트웨어 설계 - 1. 요구사항 확인

1. 소프트웨어 설계

 1) 요구사항 확인

  A. 소프트웨어 생명주기 : 소프트웨어 개발과정을 단계별로 나눈 것

폭포수 모델(Waterfall Model)	각 단계를 한번씩만 거침(되돌릴 수 있음). 단계별 철저한 검증 필요/매뉴얼 작성 불필요.
프로토타입 모형(Prototype Model)	디자인과 기능 중심으로 견본 개발 후 최종 개발 추후 발견될 오류 방지
스파이럴 모델(Spiral Model)	계획-분석(검증)-개발-평가(오류방지)의 단계를 반복 폭포수와 프로토타입의 장점 흡수하여 점진적 개발. 많은 사람의 요구사항을 반영하는 소프트웨어 개발에 용이.
스파이럴 모델(Spiral Model)	요구사항 반영 및 고객과의 의사소통 빈도를 낮추는 것이 목표. 여러 개발방법을 아우르는 모델.

  a. 폭포수 모형(Waterfall Model) : 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수 

    - 각 단계를 확실히 매듭지어야 함 

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

    - 매뉴얼 작성 필요 

    - 개발 완료 후 발견된 오류 해결 불가능 

  b. 프로토타입 모형(Prototype Model):요구수집 -> 빠른설계 -> 프로토타입구축 -> 고객평가 -> 프로토타입조정 -> 구현 -> 요구수집

    - 인터페이스 중심으로 개발 : 빠른 설계 -> 프로토타입 구축 (디자인, 마감처리 무시, 최대한 기능적인 부분만 구현)

    - 폭포수 모형의 단점 보완 : 프로토 타입 조정(개발 후, 발생하는 오류를 해결 못하는 점을 보완)

  c. 스파이럴 모델(Spiral Model) : 계획-분석-개발-평가 단계를 여러번 반복하여, 소프트웨어의 완성도를 점진적으로 향상시킴 

    - 계획-분석-개발-평가의 반복

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

    - 점진적 개발 : 정밀함, 유지보수 불필요 

    - 위험관리, 최소화가 목적 

  d. 애자일 모형(Agile Model) : 절차 -> 상호작용, 문서 -> 소프트웨어, 계약 -> 고객과의 상호작용과 협업, 계획 -> 변화에 반응

 

B. 스크럼 기법(Scrum)

   a. 스크럼 기법(Scrum) : 팀 중심, 제품 책임자, 스크럼 마스터, 개발팀으로 구성됨

    - 제품 책임자(PO) : 의사결정자, 백로그의 우선순위 지정

    - 스크럼 마스터(SM) : 일일 회의 주관, 개발 가이드

    - 개발팀(DT) : 개발자 뿐 아니라 디자이너, 테스터 등 모든 인원 

    - 프로세스 

       ->백로그 : 요구사항을 우선순위에 따라 모아놓은 목록 

       -> 계획 회의 : 스프린트 일정 수립, 개발자 별로 스프린트 백로그 작성

       -> 스프린트 : 할 일, 진행, 완료의 상태 

       -> 일일 회의 : 스크럼 마스터 주도, 소멸차트 활용

       -> 검토 회의 : 주별, PO주도, 백로그 업데이트

       -> 회고 : 지난 일정 되돌아보기, 개선점 찾기

 

  C. XP 기법 (eXtreme Programming)

      - 짧고 반복적인 개발 주기, 고객의 적극적 참여를 통한 가시성 향상

      - 소규모 인원의 개발 프로젝트에 효과적

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

      - 개발 프로세스 

        -> 사용자 스토리 : 고객의 요구사항

        -> 릴리즈 계획 수립 : 부분과 전체의 개발 일정 수립

        -> 스프이크 : 기술 및 기능확인을 위해 간단히 만드는 프로그램

        -> 이터레이션 : 릴리즈를 좀 더 세분화 한 단위

        -> 승인 검사 : 부분 소프트웨어가 릴리즈 되면 고객이 직접 평가 

        -> 소규모 릴리즈 : 릴리즈 별로 고객의 피드백 확인 가능 

 

  D. 시스템 파악 : 시스템 개발 범위를 명확하게 설정

       - 시스템 구성 : 기간(주요) 업무와 지원 업무의 주요 기능 파악

       - 시스템 기능 : 주요 기능별 세부 기능들을 계층형으로 표시

       - 시스템 인터페이스 : 주고 받는 데이터의 형식, 프로토콜 파악 

       - 아키텍쳐 구성 : 주요 업무 시스템의 구성과 동작원리를 표현

       - 소프트웨어 구성 : 종류 및 라이선스의 적용방식과 개수

       - 하드웨어 구성 : 서버의 주요 사양과 수량, 이중화 적용 여부

       - 네트워크 구성 : 구성도 작성. 물리적 위치, 보안 취약점, 유지보수 

 

  E. 개발 기술 환경 파악 

       - 운영체제 : 시스템 자원관리, 하드웨어 제어를 위한 인터페이스 

          -> 고려사항 : 주변기기 지원여부

       - DBMS : 데이터베이스 관리를 위한 시스템, 종속성과 중복성 해결. DB에 대한 모든 권한과 책임이 있음

          -> 고려사항 : 상호 호환성, 데이터 이중화

       - WAS : 동적 콘텐츠 처리를 위한 미들웨어, DB서버와 연동

          -> 미들웨어 : 서버와 클라이언트 중간에 위치, 클라이언트 대신 복잡한 처리를 하기 위함

          -> 고려사항 : 다양한 옵션 

       - 공통 고려사항 : 가용성, 성능, 비용, 기술지원

       - 오픈소스 : 라이선스 종류, 기술 지속가능성, 사용자 수 

 

  F. 요구사항 정의/분석/확인

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

          -> 기능 : 기능 자체

          -> 비기능 : 기능의 품질, 제약사항

          -> 사용자 : 쉬운 표현 사용

          -> 시스템 : 개발자 입장, 전문용어  

       - 요구사항 개발 프로세스 : 도출(의사소통) > 분석 > 명세(문서화) > 확인

          -> 분석 : 타당성 조사, 특정 기준으로 분류 

                - 개념 모델링 : 단순화, 개념적 표현, 객체간 관계와 종속성 분석

                - 협상 : (기능과 비기능, 필요자원, 서로)의 요구사항이 충돌하는 경우

                - 정형분석 : 마지막 단계, 구문과 의미를 갖는 언어 사용, 수학적 기호로 표현

          -> 확인 : 검증

                - 검토 : 일반적, 고객대표 포함

                - 모델검증 : 정적(논리적) 검증, 실행안함

                - 프로토타이핑 : 지속적인 프로토타입 작성, 사전 피드백 

                    - 단점 : 프로토타입에만 집중, 비용부담, 과대평가 

                - 인수테스트 : 사용자 입장에서 요구사항 체크(계획 필요)

 

  G. UML(Unified Modeling Language)

       - 배치 다이어그램 : 물리적인 자원의 위치를 표시하는 것으로 구현단계에서 사용됨 

       - 사물의 종류 중, (구조, 행동, 주해)를 제외한 나머지 하나는 그룹임 

       - 시퀀스, 상태, 활동은 동적인 행위를 표현하기 위한 것

       - 컴포넌트와 배치는 UML 다이어그램 중, 구현단계에서 사용하기 적절함

       - 점선 화살표는 의존, 실체화 관계에서 처럼 일시적인 관계를 표현할 때 사용되는 선임

       - 다중도 표현에서 '다수' => '*' 와 '또는' => '..'

       - 포함관계는 자동차와 열쇠의 관계를 표현하기 가장 적절한 관계임

구조적 다이어그램
종류	키워드
클래스	구조
객체	관계
컴포넌트	구현, 인터페이스
복합체 구조	내부 구조
패키지	그룹

행위 다이어그램
유스케이스	모델링
시퀀스	메시지
커뮤니케이션	메시지 + 연관관계
상태	상태 변화
활동	로직 흐름
상호작용 개요	제어 흐름
타이밍	시간제약