[정처기 실기] 소프트웨어 설계 - (1) 요구사항 확인1

 

---

Part1. 소프트웨어 설계

소프트웨어 설계 혹은 소프트웨어 디자인은 소프트웨어 문제 해결과 계획 과정이다.

 

1. 요구사항 확인 1

 

 

---

001. 소프트웨어 생명 주기 (Software Life Cycle)

소프트웨어 생명 주기

• 소프트웨어 생명 주기(Software Life Cycle)은 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.
• 소프트웨어 기획부터 설계, 운용, 유지보수까지를 일련의 주기로 보고 이를 효과적으로 설계하기 위한 것이다.
• ex > 폭포수 모델, 프로토타입 모델, 나선형 모델, 애자일 모델, ...

 

 

---

002. 폭포수 모델 (Waterfall Model)

폭포수 모델 (Waterfall Model)

 

• 폭포수 모델은 이전 단계로 돌아갈 수 없다는 전제 하에 각 단계를 확실히 매듭 짓고 그 결과를 철저하게 검토해 승인 과정을 거친 후에 다음 단계를 차례로 진행하는 방법론이다.
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모델이다.
• 고전적 생명 주기 모델이라고도 한다.

 

 

---

003. 프로토타입 모델 (Prototype Model)

프로토타입 모델

• 프로토타입 모델은 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 프로토타입을 만들어 최종 결과물을 예측하고, 고객의 피드백을 통해 개선, 보완해 결과물을 만들어 나가는 모델이다.
• 따라서, 고객의 요구사항이 모호하거나 프로젝트 중 변경 가능성이 많은 경우 적합한 모델이다.
• 폭포수 모델의 사용자 피드백 부분을 보완한 사용자 중심의 프로세스 모델이다.

 

 

---

004. 나선형 모델 (Spiral Model)

나선형 모델

• 나선형 모델은 소프트웨어 개발 시 위험을 최소화하기 위해 점진적으로 시스템을 완성해 나가는 프로세스 모델이다.
• 4가지 주요 활동을 나선을 따라 돌듯이 여러 번에 걸쳐서 반복하며, 위험 분석 단계를 통해 위험 가능성을 최소화한다.
• 보헴(Boehm)이 제안했으며, 위험이 큰 대형 시스템 구축에 적합한 모델이다.
• 4가지 주요 활동
  • 계획 수립 - 프로젝트 계획 수립, 요구사항 분석, 단계별 목표 수립
  • 위험 분석 - 위험 식별, 정량/정성적 분석 및 평가, 위험 평가 결과에 따른 근거, 개발 여부 결정
  • 개발 - 구현 대상 기능에 대한 실제구현, 단위 테스트 수행
  • 고객 평가 - 고객에 의한 시스템 평가 및 향후 목표 계획

 

 

 

---

005. 애자일 모델 (Agile Model)

애자일 모델

• 애자일은 '민첩한', '기민한'이라는 의미로, 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모델이다.
• 기존의 폭포수 모델은 1910년대 산업 공정에 적용하기 위한 모델이었으며, 전통적인 소프트웨어 개발에도 적용되었으나 시대가 발전하면서 빠르게 변화해야 하는 소프트웨어 개발 시장에는 적합하지 않았고, 이를 개선하기 위해 애자일 모델이 만들어졌다.
• 대표적인 개발 모형으로는 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 기능 중심 개발(FDD; Feature Driven Development) 등이 있다.

 

 

---

006. 애자일 개발 4가지 핵심 가치

애자일 소프트웨어 개발 선언

• 프로세스와 도구보다는 개인과 상호작용을,
• 방대한 문서보다 실행되는 소프트웨어를,
• 계약 협상보다는 고객과 협업을,
• 계획을 따르기 보다 변화에 반응하는 것을,

 

 

---

007. 소프트웨어 공학 (SE; Software Engineering)

• 소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문으로 여러 가지 방법론과 도구, 관리 기법들을 통해 소프트웨어의 품질과 생산성 향상을 목적으로 한다.
• 시스템 개발의 초기 단계부터 시스템이 사용된 후 유지 보수되기까지의 소프트웨어 개발과 관련된 모든 측면을 의미하며, 단순히 기술적인 개발 과정 뿐만 아니라 프로젝트 관리, 개발 도구와 메소드 등과 같이 소프트웨어 제작에 있어 도움을 줄 수 있는 모든 것을 의미한다.
• 소프트웨어 공학의 기본 원칙
  • 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
  • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
  • 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

 

 

 

---

008. 스크럼 (Scrum)

스크럼

• 스크럼은 소규모로 구성된 팀으로 개발의 효율성을 높이는 기법이다.
• 스크럼 팀
  • 제품 책임자 (PO; Product Owner)
    • 고객의 요구사항이 담긴 백로그(Backlog)를 작성하는 주체
    • 이해관계자들 중 개발된 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정
  • 스크럼 마스터 (SM; Scrum Master)
    • 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함
  • 개발팀 (DT; Development Team)
    • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행함

관련 자료

 

 

 

---

009. 스크럼 개발 프로세스

스크럼 개발 프로세스

• 스프린트 계획 회의 (Sprint Planning Meeting) - 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
• 스프린트 (Sprint) - 실제 개발 작업을 진행하는 과정으로, 보통 2 ~ 4주 정도의 기간 내에서 진행함
• 일일 스크럼 회의 (Daily Scrum Meeting) - 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의
• 스프린트 검토 회의 (Sprint Review) - 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
• 스프린트 회고 (Sprint Retrospective) - 정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

 

 

---

010. XP (eXtreme Programming)

eXtreme Programming

• XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
• XP의 5가지 핵심 가치
  • 의사소통 (Communication)
  • 단순성 (Simplicity)
  • 용기 (Courage)
  • 존중 (Respect)
  • 피드백 (Feedback)

 

 

---

011. XP의 주요 실천 방법

• Pair Programming (짝 프로그래밍)
  • 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성한다
• Collective Ownership (공동 코드 소유)
  • 개발 코드에 대한 권한과 책임을 공동으로 소유한다.
• Test-Driven Development (테스트 주도 개발)
  • 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악한다.
  • 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크)를 사용한다.
• Whole Team (전체 팀)
  • 개발에 참여하는 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 한다.
• Continuous Integration (계속적인 통합)
  • 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합된다.
• Refactoring (리팩토링)
  • 프로그램 기능의 변경 없이 시스템을 재구성한다.
  • 목적 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함임
• Small Releases (소규모 릴리즈)
  • 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다.

 

 

 

---

012. 데이터베이스 관리 시스템 (DBMS; DataBase Management System)

• 데이터베이스 관리 시스템은 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어다.
• DBMS 관련 요구사항 식별 시 고려사항
  • 가용성
  • 성능
  • 기술 지원
  • 상호 호환성
  • 구축 비용

 

 

---

013. 웹 어플리케이션 서버 (WAS; Web Application Server)

WAS

• 웹 애플리케이션 서버는 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어다.
• 웹 애플리케이션 서버 관련 요구사항 식별 시 고려사항
  • 가용성
  • 성능
  • 기술 지원
  • 구축 비용

 

 

---

014. 오픈 소스 (Open Source)

• 오픈 소스는 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 소프트웨어다.
• 오픈 소스 관련 요구사항 식별 시 고려사항
  • 라이선스의 종류
  • 사용자 수
  • 기술의 지속 가능성

 

 

---

015. 요구사항

• 요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건이다.
• 말 그대로 소프트웨어를 개발하는데 필요한 요구사항이며, 소프트웨어가 어떤 기능을 제공하기를 바라는지, 어떤 제한사항이 있는지 설정하는 것이다.
• 요구사항의 기능적 분류로 기능적 요구사항, 비기능적 요구사항, 도메인 요구사항이 있다.

 

 

---

016. 기능적 요구사항 (Functional Requirements)

• 기능적 요구사항은 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련한 요구사항이다.
• 시스템 입출력으로 무엇이 포함되어야 하는지에 대한 사항
• 시스템이 어떤 데이터를 저장하고 연산해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능
• 즉, 시스템 서비스가 상세하게 기술되어 있는 문장이다.

 

 

---

017. 비기능적 요구사항 (Non-functional Requirements)

• 비기능적 요구사항은 품질이나 제약에 관련된 요구사항이다.
• 기능적 요구사항을 수행할 때 문제점이 되는 제한사항들이 비기능적 요구사항이 될 수 있다.
• 장비 구성, 성능, 인터페이스, 테스트, 보안 등 시스템 서비스에 관련한 부분을 제외한 제약사항이 될 수 있다.

 

 

---

018. 요구사항 개발 프로세스

요구사항 개발 프로세스

• 요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 뒤 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동이다.
• 요구사항 개발 프로세스가 진행되기 전에 타당성 조사(Feasibility Study)가 선행되어야 한다.
• 요구사항 개발은 요구사항 관리와 함께 요구공학(Requirement Engineering)의 한 요소이다.
• 요구사항 개발 프로세스의 4단계
  • 도출(Elicitation) - 인터뷰, 워크숍, 프로토타이핑과 같이 요구사항을 찾아내기 위한 모든 활동
  • 분석(Analysis) - 요구사항을 더욱 자세하고 정확하게 이해하며 분석 수행
  • 명세(Specification) - 수집된 요구사항을 문서화
  • 검증(Verification) - 요구사항이 정확하고 올바르게 작성되었는지 확인

 

 

---

019. 요구사항 명세 (Requirement Specification)

• 요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미한다.
• 기능 요구사항을 빠짐없이 기술하며, 비기능 요구사항은 필요한 것만 기술한다.
• 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 사용될 수 있다.

 

 

---

020. 요구사항 명세 기법

• 정형 명세 기법
  • 수학적 원리 및 모델 기반
  • 수학적 기호, 정형화된 표기법
  • 요구사항을 정확하고 간결하게 표현할 수 있음
  • 주로 Z 기법을 사용해 사용자의 요구사항을 표현함
  • 종류
    • VDM - 시스템의 비기능적인 요구사항을 제외한 기능적인 요구사항만 한정되며 이와 관련한 기능 요구 명세와 검증 설계에 관해 적절한 표기법인 검증 방법을 제공함

      

      Vienna Development Method

    • Z - 논리를 기반으로 한 Calculus적 표현을 사용해 여러 특성을 VDM보다 함축적으로 표현함

      

      Z schema

    • Petri-net - 그래프에 의한 표기법을 제공하며, 병렬 처리를 기술할 때 유한상태기계의 한계성을 극복하도록 고안

      

      Petri-net

• 비정형 명세 기법
  • 상태/기능/객체 중심
  • 일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
  • 자연어 사용으로 일관성이 떨어지고 해석이 달라질 수 있으나 내용의 이해가 쉬워 의사소통이 용이하다
  • 종류
    • FSM, Decision Table, ER모델, State Chart(SADT), ...

 

 

---

022. 자료 흐름도 (DFD; Data Flow Diagram)

자료 흐름도

• 자료 흐름도는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법이다.
• 자료 흐름 그래프, 버블 차트라고도 한다.
• 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다.
• 구성 요소
  • 프로세스 (Process) - 자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며 처리, 기능, 변환, 버블이라고도 함
  • 자료 흐름 (Data Flow) 자료의 이동(흐름)이나 연관관계를 나타냄
  • 자료 저장소 (Data Store) - 시스템에서의 자료 저장소(파일, DB)를 나타냄
  • 단말 (Terminator) - 시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음

 

 

---

023. 자료 사전 (DD; Data Dictionary)

• 자료 사전은 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이다.
• 데이터를 설명하는 데이터로, 메타 데이터라고도 한다.
• 표기 기호

Data Dictionary

 

 

 

---

024. 요구사항 분석용 CASE (자동화 도구)

• 요구사항 분석용 CASE는 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구를 말한다.
• 대표적인 요구사항 분석용 CASE : SADT, SREM(=RSL/REVS), PSL/PSA, TAGS

 

 

 

---

025. SADT (Structured analysis and design technique)

• SADT는 시스템 정의, 소프트웨어 요구사항 분석, 시스템 소프트웨어 설계를 위한 도구다.
• SoftTech사에서 개발했으며 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구다.

 

 

---

026. HIPO (Hierarchy Input Process Output)

HIPO Chart

• HIPO는 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법으로 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것이다.
• 하향식 소프트웨어 개발을 위한 문서화 도구이다.
• 시스템의 기능을 여러 개의 고유 모듈로 분할해 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 한다.

 

 

---

027. UML (Unified Modeling Language)

UML 예시

• UML은 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어이다.
• 즉, 설계도를 그리기 위한 통합적인 모델링 언어다.
• UML의 구성 요소로는 사물(Things), 관계(Relationship), 다이어그램(Diagram)이 있다.

 

---

028. 관계 (Relationships)

UML 관계

• 관계는 사물과 사물 사이의 연관성을 표현하는 것이다.
• 관계의 종류
  • 연관 관계
  • 집합 관계
  • 포함 관계
  • 일반화 관계
  • 의존 관계
  • 실체화 관계

 

---

029. 연관 관계 (Association)

연관 관계

• 연관 관계는 2개 이상의 사물이 서로 관련되어 있는 관계이다.
• 사물 사이를 실선으로 연결해 표현한다
• 방향성은 화살표로 표현한다.
• 양방향 관계인 경우 화살표를 생략하고 실선으로만 연결한다.
• 다중도를 선 위에 표기한다.

 

 

---

030. 집합 관계 (Aggregation)

집합 관계

• 집합 관계는 하나의 사물이 다른 사물에 포함되어 있는 관계이다.
• 포함하는 쪽과 포함되는 쪽은 서로 독립적이다.
• 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결해 표현한다.

 

 

---

031. 포함 관계 (Composition)

포함 관계

• 포함 관계는 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계이다.
• 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명주기를 함께 한다.
• 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결해 표현한다.
• ex> 문 - 키 관계 - 문을 열 수 있는 키는 하나이며, 다른 문은 열 수 없다. 문이 없어지면 키도 더 이상 필요하지 않다.

 

 

 

---

032. 일반화 관계 (Generalization)

일반화 관계

• 일반화 관계는 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계이다.
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.
• 구체적인 사물에서 일반적인 사물 쪽으로 속이 빈 화살표를 연결해 표현한다.

 

 

---

033. 의존 관계 (Dependency)

연관 관계와 의존 관계

• 의존 관계는 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계이다.
• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계이다.
• 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계이다.
• 일반적으로 한 클래스가 다른 클래스를 사용하는 관계이다.
• 영향을 주는 사물이 영향을 받는 사물쪽으로 점선 화살표를 연결해 표현한다.

 

---

034. 실체화 관계 (Realization)

실체화 관계

• 실체화 관계는 사물이 할 수 있거나 해야하는 기능으로, 서로를 그룹화할 수 있는 관계이다.
• 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계이다.
• 사물에서 기능쪽으로 속이 빈 점선 화살표를 연결해 표현한다.
• ex> 비행기와 새는 둘다 날 수 있으므로 날 수 있다는 행위로 그룹화할 수 있다.

 

---

035. 다이어그램 (Diagram)

다이어그램

• 다이어그램은 사물과 관계를 도형으로 표현한 것이다.
• 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 준다.
• 정적 모델링에서는 주로 구조적 다이어그램을 사용한다.
• 동적 모델링에서는 주로 행위 다이어그램을 사용한다.

 

---

036. 구조적 다이어그램의 종류

• 클래스 다이어그램 (Class Diagram)
  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다.
• 객체 다이어그램 (Object Diagram)
  • 클래스에 속한 객체들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계롤 표현한다.
  • 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용된다.
• 컴포넌트 다이어그램 (Component Diagram)
  • 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현한다.
  • 구현 단계에서 사용된다.
• 배치 다이어그램 (Deployment Diagram)
  • 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다.
  • 구현 단계에서 사용된다.
• 복합체 구조 다이어그램 (Composite Structure Diagram)
  • 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다.
• 패키지 다이어그램 (Package Diagram)
  • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들 간의 관계를 표현한다.

 

---

037. 행위 다이어그램의 종류

• 유스케이스 다이어그램 (Use Case Diagram)
  • 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용한다.
  • 사용자(Actor)와 사용 사례(Use Case)로 구성된다.
• 시퀀스 다이어그램 (Sequence Diagram)
  • 상호작용하는 시스템이나 객체들이 주고받는 메시지를 표현한다.
• 커뮤니케이션 다이어그램 (Communication Diagram)
  • 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현한다.
• 상태 다이어그램 (State Diagram)
  • 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지를 표현한다.
  • 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용된다.
• 활동 다이어그램 (Activity Diagram)
  • 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현한다.
• 상호작용 개요 다이어그램 (Interaction Overview Diagram)
  • 상호작용 다이어그램 간의 제어 흐름을 표현한다.
• 타이밍 다이어그램 (Timing Diagram)
  • 객체 상태 변화와 시간 제약을 명시적으로 표현한다.

 

---

038. 스테레오 타입 (Stereo Type)

스테레오 타입

• 스테레오 타입은 UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것이다.
• 길러멧(Guilemet)이라고 부르는 겹화살괄호(≪≫) 사이에 표현할 형태를 기술한다.