1. 소프트웨어 설계 핵심요약

001. 소프트웨어 생명 주기

 

1. 소프트웨어 공학

• 소프트웨어의 위기를 극복하기 위한 방은으로 연구된 학문이다.
• 소프트웨어의 개발, 운영, 유지보수에 대한 체계적인 접근 방법이다.
• 소프트웨어의 품절과 생산성을 향상시킬 목적으로 한다.
• 경제적인 비용을 들여 신뢰성 높은 소프트웨어를 개발하기 위해 공학적 원리를 정립하고 이를 적용하는 것이다.

 

2. 소프트웨어 공학의 기본 원칙

• 현대적인 프로그래밍 기술을 계속적으로 적용해야 한다.
• 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

 

3. 폭포수 모형(Waterfall Model)

• 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론이다.
• 보헴(Boehm)이 제시한 고전적 생명 주기 모형이다.
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형이다.
• 개발 과정에서 발생하는 요구사항을 반영하기 어렵다.

 

4. 프로토타입 모형(Prototype Model, 원형 모형)

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.
• 시제품은 의뢰자나 개발자 모두에게 공동의 참조 모델이 된다.
• 시스템의 일부 혹은 시스템의 모형을 만다는 과정으로서 요구된 소트프웨어를 구현하는데, 이는 추후 구현단계에서 사용될 골격 코드가 된다.
• 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어를 구현하는 방법이다.
• 단기간 제작 목적으로 인하여 비효율적인 언어나 알고리즘이 사용될 수 있다.

 

5. 나선형 모델(Spiral Model, 점진적 모형)

• 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.
• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것이다.
• '계획 수립 → 위험 분석 → 개발 및 검증 → 고객평가' 과정이 반복적으로 수행된다.
• 핵심 기술에 문제가 있거나 사용자의 요구사항이 이해하기 어려운 경우에 적합한 모델이다.

 

6. 애자일 모형(Agile Model)

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행한다.
• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형

       - 스크럼(Scrum)

       - XP(eXtreme Programming)

       - 칸반(Kanban)

       - 린(Lean)

       - 크리스탈(Crystal)

       - ASD(Adaptive Software Development)

       - 기능 중심 개발(FDD: Feature Driven Development)

       - DSDM(Dynamic System Development Method)

       - DAD(Disciplined Agile Delivery) 등

 

 

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

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

 

 

002. 스크럼(Scrum) 기법

1. 스크럼(Scrum) 팀

• 제품 책임자(PO; Product Owner)

       - 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당한다.

       - 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체이다.

       - 요구사항에 담긴 백로그(Backlog)를 작성하고 백로그에 대한 우선순위를 지정한다.

 

• 스크럼 마스터(SM; Scrum Master)

       - 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행함

 

• 개발팀(DT; Development Team)

       - 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.

 

 

2. 스크럼 개발 프로세스

• 제품 백로그(Product Backlog) : 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록
• 스트린트 계획 회의(Sprint Planning Meeting): 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
• 스프린트(Sprint) : 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행함
• 일일 스크럼 회의(Daily Scrum Meeting) : 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행사항을 점검함
• 스프린트 검토 회의(Sprint Review) : 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 진행함
• 스프린트 회고(Sprint Retrospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록함

 

 

003. XP(eXtreme Programming)

1. XP(eXtreme Programming)의 개요

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.
• 대표적인 애자일 개발 방법론 중 하나이다.
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극정인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.
• 자동화된 테스팅 도구를 사용하여 테스트를 지속적으로 수행한다.

 

2. XP의 핵심 가치

• 의사소통(Communication)
• 단순성(Simplicity)
• 용기(Courage)
• 존중(Respect)
• 피드백(Feedback)

 

3. XP 개발 프로세스

• 사용자 스토리(User Story) : 고객의 요구사항을 간단한 시나리오로 표현한 것
• 릴리즈 계획 수립(Release Planning) : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함
• 스파이크(Spike) : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
• 이터레이션(Iteration) :  하나의 릴리즈를 더 세분화 한 단위를 위한 이터레이션(Iteration)이라고함
• 승인 검사(Acceptance Test, 인수 테스트) : 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
• 소규모 릴리즈(Small Release) : 릴리즈를 소규모로 하게 되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응할 수 있음

 

4. XP의 주요 실천 방법

• Pair Programming(짝 프로그래밍) : 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성함
• Collective Ownership(공동 코드 소유) : 개발 코드에 대한 권한과 책임을 공동으로 수행함
• Coutiuous Integration(계속적인 통합) : 모듈 단위로 나워서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통함됨
• Refactoring(리팩토링) : 프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템의 내부 구조를 재구성함

 

 

004. 현행 시스템 파악

1. 현행 시스템 파악 절차

• 1단계: 시스템 구성, 시스템 기능, 시스템 인터페이스 파악
• 2단계: 아키텍처 구성, 소프트웨어(DBMS, 운영체제 등) 구성 파악
• 3단계: 하드웨어 구성, 네트워크 구성 파악

 

 

005. 개발 기술 환경 파악

1. DBMS  분석시 고려사항

• 가용성
• 성능
• 기술 지원
• 상호 호환성
• 구축 비용

 

2. WAS(Web Application Server)

• 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다.
• 종류: Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등

 

 

006. 요구사항 정의

1. 기능 요구사항

• 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능

 

2. 비기능 요구사항

• 성능 요구사항: 처리 속도 및 시간, 처리량 등의 요구사항
• 보안 요구사항: 시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
• 품질 요구사항: 품질 평가 대상에 대한 요구사항

 

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

도출(Elicatation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)

 

 

4. 요구사항 도출(Requirement Elicitation, 요구사항 수집)

• 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정이다.
• 요구사항 도출 기법: 청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등

 

5. 요구사항 명세 기법

구분	정형 명세 기법	비정형 명세 기법
기법	• 수학적 원리 기밥 • 모델 기반	상태 / 기능 / 객체 중심
작성 방법	수학적 기호, 정형화 된 표기법	• 자연어를 기반으로 작성 • 다이어그램으로 작성
특징	요구사항을 정확하거 간결하게 표현	• 일관성이 떨어짐 • 의사소통이 용이함
종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER ahepffld, State Chart(SADT) 등

 

 

6. 요구사항 확인(요구사항 검증)

• 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는지 확인(Validation)하는 것이 필요하다.
• 요구사항이 실제 요구를 반영하는지, 서로 상충되는 요구사항은 없는지 등을 점검한다.
• 개발이 완료된 후 문제가 발견되면 재작업 비용이 발생할 수 있으므로 요구사항 검증은 매우 중요하다.
• 요구사항 검정 과정을 통해 모든 문제를 확인할 수 있는 것은 아니다.

 

 

007. 요구사항 분석

1. 요구사항 분석의 개요

• 소프트웨어 개발의 실제적인 첫 단계러 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미한다.
• 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지를 결정한다.
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다.
• 사용자의 요구사항은 예외가 많고 지속적으로 변경하므로 열거와 구조화가 어렵다.
• 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 중재하는 과정이다.
• 요구사항 분석을 위해 UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-spec), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등의 도구를 이용한다.

 

2. 자료 흐름도의 구성 요소

기호	표기법
프로세스(Process)
자료 흐름(Data Flow)
자료 저장소(Data Store)
단말(Terminator)

 

 

3. 자료 흐름도 작성 지침

• 자료 흐름은 처리(Process)를 거쳐 변화될 때마다 새로운 이름을 부여한다.
• 어런 처리(Process)가 출력 자료를 산출하기 위해서는 반드시 입력 자료가 발생해야 한다.
• 상위 단계의 처리(Process)와 하위 자료 흐름도의 자료 흐름은 서로 일치되어야 한다.
• 입력 화살표가 있다고 하여 반드시 출력 화실표가 있어야 하는 것은 아니다.

 

4. 자료 사전의 표기 기호

기호	의미
=	자료의 정의: ~로 구성되어 있다(is composed of)
+	자료의 연결: 그리고(and)
( )	자료의 생략: 생략 가능한 자료(Optional)
[ | ]	자료의 선택: 또는(or)
{ }	자료의 반복: Iteration of
* *	자료의 설명: 주석(Comment)

 

 

 

008. 요구사항 분석 CASE와 HIPO

1. SADT

• SoftTech 사에서 개발한 구조적 분석 및 설계 도구이다.
• 블록 다이어그램을 채택한 자동화 도구이다.

 

2. HIPO

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다.
• 하향식 소프트웨어 개발을 위한 문서화 도구이다.
• 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
• 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
• 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 한다.
• HIPO Chart의 종류: 가시적 도표(Visual Table of Contents), 총계적 도표(Overview Diagram), 세부적 도표(Detail Diagram)

 

 

009. UML(Unified Modeling Language)

1. UML의 개요

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

 

2. 사물(Thing)

• 모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다.
• 종류

       - 구조 사물(Structural Things)

       - 행동 사물(Behavioral Things)

       - 그룹 사물(Grouping Things)

       - 주해 사물(Annotation Things)

 

 

3. 의존(Dependency) 관계

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

 

4. 실체화(Realization) 관계

• 사물이 할 수 있거나 해야 하는 기능(오퍼레이션, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현한다.
• 한 사물이 다른 사물에게 오퍼레이션을 수행하도록 지정하는 의미적 관계이다.

 

5. 일반화(Generalization) 관계

• 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다.
• 예를 들어 차는 버스, 트럭, 택시보다 일반적인 개념이고 반대로 버스, 트럭, 택시는 차보다 구체적인 개념이다.

 

6. 구조적(정적) 다이어그램의 종류

• 클래스 다이어그램
• 객체(Object) 다이어그램
• 컴포넌트 다이어그램
• 배치(Deployment) 다이어그램
• 복합체 구조(Conposite Structure) 다이어그램
• 패키지 다이어그램

 

7. 행위(동적) 다이어그램의 종류

• 유스케이스 다이어그램
• 순차(Sequence) 다이어그램
• 커뮤니케이션 다이어그램
• 상태(State) 다이어그램
• 활동(Activity) 다이어그램
• 상호작용 개요(Interaction Overview) 다이어그램
• 타이밍 다이어그램

 

8. 상태(State) 다이어그램

• 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현한다.
• 객체들 사이에서 발새아는 이벤트(event)에 의한 객체들의 상태 변화를 그림으로 표현한다.
• 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용된다.

 

9. 활동(Activity) 다이어그램

• 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른. 처리의 흐름을 순서에 따라 표현한다.
• 오퍼레이션이나 처리 과정이 수행되는 동안 일어나는 일들을 단계적으로 표현한다.

 

10. 스테레오 타입(Stereotype)

• UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용한다.
• 길러멧(Guilemet)이라고 부르는 겹화살괄호(《》) 사이에 표현할 형태를 기술한다.

 

 

010. 주요 UML 다이어그램

1. 유스케이스 다이어그램의 구성 요소

• 시스템/시스템 범위: 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현함
• 액터: 시스템과 상호작용을 하는 모든 외부 요소로, 사람이나 외부 시스템을 의미함

       - 주액터: 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당함

       - 부액터(시스템 액터): 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관 등이 될 수 있음

• 유스케이스: 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것
• 관계(Relationship): 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있으며, 연관 관계, 포함 관계, 확장 관계, 일반화 관계를 표현할 수 있음

 

2. 유스케이스 확장 관계

• 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계이다.

 

3. 클래스 다이어그램 - 오퍼레이션(Operation)

• 클래스가 수행할 수 있는 동작으로, 함수(메소드,Method)라고도 한다.

 

4. 순차 다이어그램의 개요

• 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것이다.
• 순차 다이어그램은 시스템이나 객체들의 상호 작용과정에서 주고받는 메시지를 표현한다.
• 순차 다이어그램에서 수직 방향은 시간의 흐름을 나타낸다.

 

5. 순차 다이어그램의 구성 요소

• 액터(Actor)
• 객채(Object)
• 생명선(Lifeline)
• 실행 상자(Active Box)
• 메시지(Message)
• 회귀 메시지(Reply/Return Message)
• 제어 블록(Loop)