소프트웨어 생명 주기

• 소프트웨어 생명 주기는 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈것
• 생명주기 유형
  • 폭포수 모형
  • 프로토타입 모형
  • 나선형 모형
  • 애자일 모형

폭포수 모형

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

프로토타입 모형

• 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

나선형 모형

• 나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
• 보헴이 제안
• 주요활동 : 계획 수립 → 위험 분석 → 개발 및 검증 → 고객평가 → 계획수립...

애자일 모형

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
• 폭포수 모형과 대조적
• 대표적인 개발 모형 : 스크럼, XP, 칸반, Lean, 기능 중심 개발

소프트웨어 공학

• 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다

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

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

---

스크럼 기법

스크럼

• 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 팀원 스스로가 스크럼 팀을 구성하고 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다

스크럼팀

• 제품 책임자
  • 요구사항이 담긴 백로그를 작성하는 주체
  • 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정
• 스크럼 마스터
  • 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할을 수행함
• 개발팀
  • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 제품 개발을 수행함

스크럼 개발 프로세스

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

---

XP 기법

XP

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

XP의 개발 프로세스

릴리즈 계획 수립 → 이터레이션 → 승인 검사 → 소규모 릴리즈

XP의 주요 실천 방법

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

---

개발 기술 환경 파악

개발하고자 하는 소프트웨어와 관련된 운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈소스를 사용할 때 주의해야 할 내용을 제시한다

운영체제

• 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어이다
• 고려사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

DBMS

• 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어이다
• 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템
• 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

WAS (웹 애플리케이션 서버)

• 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다 (정적인 콘텐츠의 경우 웹 서버가 담당)
• 고려사항 : 가용성, 성능, 기술 지원, 구축 비용

오픈 소스

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

---

요구사항 정의

요구사항

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건이다
• 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공한다
• 유형 : 기능 요구사항, 비기능 요구사항, 사용자 요구사항, 시스템 요구사항

기능 요구사항

• 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항이다
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지에 대한 사항
• 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능

비기능 요구사항

• 품질이나 제약사항과 관련된 요구사항이다
• 시스템 장비 구성 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 품질 요구사항 : 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등
• 제약사항

사용자 요구사항

• 사용자 관점에서 본 시스템이 제공해야 할 요구사항이다

시스템 요구사항

• 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항이다
• 소프트웨어 요구사항이라고도 한다

---

요구사항 개발 프로세스

요구사항 개발 프로세스

• 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동이다
• 프로세스가 진행되기 전 타당성 조사가 선행되어야 한다
• 프로세스 : 도출 → 분석 → 명세 → 확인

요구사항 도출

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

요구사항 분석

• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정이다
• 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다
• 사용되는 도구 : 자료 흐름도, 자료 사전

요구사항 명세

• 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미
• 기능 요구사항을 모두 기술
• 비기능의 경우 필요한 것만 기술

요구사항 확인

• 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동이다
• 이해관계자들이 검토해야 함
• 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리를 수행

요구공학

• 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

요구사항 명세 기법

1. 정형 명세 기법
   • 수학적 원리 기반, 모델 기반
   • 수학적 기호, 정형화된 표기법
   • 요구사항을 정확하고 간경하게 표현 가능
   • 표기법이 어려워 사용자가 이해하기 어려움
   • VDM, Z, Petri-net, CSP 등
2. 비정형 명세 기법
   • 상태/기능/객체 중심
   • 일반 명사, 동사 등의 자연어를 기반으로 서술/다이어그램으로 작성
   • 자연어의 사용으로 작성자에 따라 다를수 있어 일관성이 떨어지고, 해석이 달라질 수 있음
   • FSM, Decision Table, ER모델링, State Chart 등

---

요구사항 분석

요구사항 분석

• 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미
• 사용자의 요구를 정확하게 추출하여 목표를 정한다

구조적 분석 기법

• 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 도형 중심의 분석용 도구와 분석 절차를 이용하여 상용자의 요구사항을 파악하고 문서화
• 하향식 방법을 사용하여 시스템을 세분화할 수 있음
• 분석의 중복을 배제할 수 있음
• 분석 기법 도구 : 자료 흐름도, 자료 사전, 소단위 명세서, 개체 관계도, 상태 전이도, 제어 명세서

자료 흐름도

• 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
• 자료 흐름 그래프, 버블 차트라고 함
  

자료 사전

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

---

요구사항 분석 CASE와 HIPO

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

• 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미
• 요구사항 분석용 CASE
  • SADT
    • 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구
    • SoftTech 사 에서 개발
    • 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
  • SREM = RSL/REVS
    • TRW 사가 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 도구
    • RSL과 REVS를 사용하는 자동화도구
  • PSL/PSA
    • PSL, PSA를 사용하는 미시간 대학에서 개발한 도구
  • TAGS
    • 시스템 공학 방법 응용에 대한 자동 접근 방법
    • 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

HIPO

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

---

UML의 개요

UML

• 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
• 럼바우, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합
• UML 의 구성요소 : 사물, 관계, 다이어그램

사물

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

1. 구조 사물
   • 시스템의 개념적, 물리적 요소를 표현
   • 클래스, 유스케이스, 컴포넌트, 노드
2. 행동 사물
   • 시간과 공간에 따른 요소들의 행위를 표현
   • 상호작용, 상태머신 등
3. 그룹 사물
   • 요소들을 그룹으로 묶어서 표현
   • 패키지
4. 주해 사물
   • 부가적인 설명이나 제약조건 등을 표현
   • 노트

---

UML (관계)

관계

• 사물과 사물 사이의 연관성을 표현
• 종류 : 연관, 집합, 포함, 일반화, 의존, 실체화

연관 관계

• 2개 이상의 사물이 서로 관련되어 있는 관계
• 사물 사이를 실선으로 연결하여 표현
• 화살표로 방향성을 지정
• 양방향의 경우 화살표 생략, 실선으로 연결
• 다중도를 선위에 표기
  

집합 관계

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

포함 관계

• 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명주기를 함께한다
• 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현

일반화 관계

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

의존 관계

• 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
• 영향을 주는 사물이 영향을 받는 사물쪽으로 점선 화살표를 연결하여 표현

실체화 관계

• 사물이 할 수 있거나 해야하는 기능으로, 서로를 그룹화 할 수 있는 관계
• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현

---

UML (다이어그램)

다이어그램

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

구조적 다이어그램

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

행위 다이어그램

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

스테레오 타입

• UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것

1. ⟪include⟫ : UML 요소에 포함 관계에 있는 경우
2. ⟪extends⟫ : UML 요소에 확장 관계에 있는 경우
3. ⟪interface⟫ : 인터페이스를 정의하는 경우
4. ⟪exception⟫ : 예외를 정의하는 경우
5. ⟪constructor⟫ : 생성자 역할을 수행하는 경우

---

유스케이스 다이어그램

기능 모델링

• 사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 그림으로 표현하는 것
• 기능 모델링 종류 : 유스케이스, 액티비티 다이어그램

유스케이스 다이어그램

• 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것
• 사용자의 요구사항을 분석하기 위한 도구

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

1. 시스템/시스템 범위 : 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
2. 액터
   • 시스템과 상호작용을 하는 모든 외부 요소
   • 주로 사람이나 외부 시스템을 의미
3. 유스케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
4. 관계
   • 유스케이스 다이어그램에서 관계는 액터와 유스케이스, 유스케이스와 유스케이스에서 나타남
   • 나타날 수 있는 관계 : 포함 관계, 확장 관계, 일반화 관계

---

활동 다이어그램

활동 다이어그램

• 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
• 하나의 유스케이스 안에서 혹은 유스케이스 사이에 발생하는 복잡한 처리의 흐름을 명확하게 표현 가능
  

활동 다이어그램의 구성 요소

1. 액션(Action) / 액티비티(Activity)

   • 액션은 더이상 분해할 수 없는 단일 작업이다.
   • 액티비티는 몇 개의 액션으로 분리 될 수 있는 작업이다.
   • 액션, 액티비티 모두 테두리가 둥근 사각형으로 표현

2. 제어흐름

   • 실행의 흐름을 화살표로 표현한다.

3. 시작 노드

   • 액션이나 액티비티가 시작됨을 의미한다.
   • 하나의 다이어그램 안에는 하나의 시작점만 존재하며 검은색 원으로 표현한다.

4. 종료 노드

   • 액티비티 안의 모든 흐름이 종료됨을 의미한다.
   • 하나의 다이어그램안에 여러개의 종료 노드가 있을 수 있으나 일반적으로 하나만 표현한다.
   • 검은색원을 포함한 원으로 표현한다.

5. 조건(판단) 노드

   • 조건에 따라 제어의 흐름이 분리됨을 표현한다.
   • 마름모로 표현하며 들어오는 제어 흐름은 한개 이고 나가는 제어 흐름은 여러 개이다.

6. 병합 노드

   • 여러 경로의 흐름이 하나로 합쳐짐을 표현한다.
   • 마름모를 표현하며, 들어오는 제어 흐름은 여러개이고 나가는 제어흐름은 한개이다.

7. 포크(Fork) 노드

   • 액티비티의 흐름이 분리되어 수행됨을 표현한다.
   • 굵은 가로선으로 표현하며 들어오는 액티비티 흐름은 한개이고 나가는 액티비티 흐름은 여러 개이다.

8. 조인(Join) 노드

   • 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한다.
   • 굵은 가로선으로 표현하며, 들어오는 액티비티 흐름은 여러 개이고 나가는 액티비티 흐름은 한개이다.

9. 스윔레인(Swim Lane)

   • 액티비티 수행을 담당하는 주체를 구분한다.
   • 가로 또는 세로 실선을 그어 구분한다.