[소프트웨어 공학 및 개발 방법론 학습 노트

소프트웨어 공학 및 개발 방법론 학습 노트

Ⓐ Section 1. 소프트웨어 생명주기

① 소프트웨어 생명 주기

• 소프트웨어를 개발하기 위한 과정을 각 단계별로 나누는 것.

②폭포수 모형

• 각 단계를 확실히 매듭짓고 그 결과를 검토하여 승인 과정을 거친 후 다음 단계를 진행하는 개발 방법론.
  • 가장 오래되고 전통적인 소프트웨어 생명주기 모형. 경험과 성공 사례가 제일 많다.
  • 결과물이 명확하게 산출.
  • 보완: 요구사항 변경에 취약하고, 초기 단계에서 모든 요구사항을 정의해야 하는 단점이 있습니다. 실제 적용 시에는 요구사항이 명확하고 변경 가능성이 낮은 프로젝트에 적합합니다. ③ 프로토타입 모형 (Prototype model, 원형 모형?)
• 실제 개발된 소프트웨어에 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형.

  • 보완: 요구사항을 명확히 하는 데 유용하지만, 프로토타입 개발에 추가적인 시간과 비용이 소모될 수 있습니다. 요구사항이 불명확하거나 사용자 인터페이스에 대한 검증이 필요한 프로젝트에 적합합니다. ④ 나선형 모형 (Spiral models 정신적 모형)

  • 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 개발하는 모형.
  • → 4가지 주요 활동: 계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가
  • 보완: 위험을 효과적으로 관리하고 변경에 유연하게 대처할 수 있지만, 복잡하고 비용이 많이 들 수 있습니다. 위험 요소가 높고 대규모 프로젝트에 적합합니다. ⑤ 애자일 모형 (Agile Model)
  • 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형.
  • 일을 빠르고 낭비 X ↔ 고객과의 소통 ㅋ
  • 대표적인 개발 모형: 스크럼(Scrum), XP, 칸반, 린, 기능 중심 개발
  • 보완: 변화에 유연하게 대처하고 빠른 피드백을 받을 수 있지만, 초기 설계가 부족할 수 있고, 계획 변경에 대한 부담이 있을 수 있습니다. 요구사항 변화가 잦고 불명확한 프로젝트에 적합합니다.
    • 애자일 방법론 확장: 스크럼과 XP 외에 칸반, 린 등의 다른 애자일 방법론에 대한 설명과 비교 분석을 추가하여 더 다양한 상황에 적용할 수 있도록 할 수 있습니다.
    • 각 모델의 장단점 심화: 각 개발 모델의 장단점을 단순히 나열하는 것에서 더 나아가, 실제 프로젝트에서 어떤 모델을 선택해야 하는지, 상황에 따른 적합한 모델 선택 기준을 제시할 수 있습니다.
    • 하이브리드 모델: 폭포수 모델과 애자일 모델을 혼합하여 사용하는 하이브리드 모델에 대한 설명과 실질적인 활용 사례를 추가하여 융통성 있는 개발 전략을 제시할 수 있습니다. ⑥ 애자일 개발 4가지 핵심 가치
  • 개인과 상호작용, 실행되는 SW, 고객과 협업, 변화에 반응. ⑦ 소프트웨어 공학
  • 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문.
  • 여러 가지 방법론과 도구, 관리 기법들을 동원하여 소프트웨어 품질과 생산성 향상을 목적으로 합니다.
  • 소프트웨어 공학의 기본 원칙: 계속적으로 검증, 품질이 유지되도록 지속적으로 검증, 기록을 유지.
    • 최신 동향 반영:
      • DevOps: 최근 소프트웨어 개발 및 운영의 핵심 트렌드인 DevOps에 대한 내용이 부족합니다. CI/CD (지속적 통합/지속적 배포), 인프라 자동화 등의 개념을 추가하여 실제 개발 환경에서 어떻게 적용되는지 설명할 수 있습니다.
      • 클라우드 네이티브: 클라우드 환경에서 개발 및 배포하는 방식인 클라우드 네이티브와 관련된 내용이 부족합니다. 컨테이너, 쿠버네티스 등의 개념을 추가하여 현대적인 개발 환경에 대한 이해를 높일 수 있습니다.
      • 마이크로서비스 아키텍처 (MSA): 모놀리식 구조에서 마이크로서비스 아키텍처로 변화하는 추세에 맞춰 MSA의 장단점, 구현 방식 등을 추가하여 좀 더 심층적인 내용을 다룰 수 있습니다.

ⓒ 스크럼 기법

• 스크럼
  • 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 스크럼 팀
  • 제품 책임자: 요구사항이 담긴 백로그 (Backlog)를 작성하는 주체, 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고, 의사를 결정할 사람들로 선정.
  • 스크럼 마스터 가이드 역할
  • 개발팀: 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
• 스크럼 개발 프로세스
  • Product Backlog → Sprint Backlog → 스프린트 수행, 일일 스크럼 회의, 스프린트 검토 회의, 스프린트 회고
  • 스프린트 계획 회의: 제품 백로그 ㅋ 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의.
  • 스프린트: 실제 개발 작업을 진행하는 과정으로, 보통 2~4주
  • 일일 스크럼: 매일 약속된 시간 15분
  • 스프린트 검토 회의: 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅 모든 회의
  • 스프린트 회고: 정해진 규칙 준수여부 및 개선할 점 확인 기록
    • 방법론의 심층 분석:
      • 애자일 방법론 확장: 스크럼과 XP 외에 칸반, 린 등의 다른 애자일 방법론에 대한 설명과 비교 분석을 추가하여 더 다양한 상황에 적용할 수 있도록 할 수 있습니다.

Ⓑ XP (extreme Programming) 기법.

• XP (extreme Programming): XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상시키는 방법입니다.
• XP의 5가지 핵심 가치
  • 의사소통
  • 단순성
  • 용기
  • 존중
  • 피드백
• XP 개발 프로세스
  • 릴리즈 계획 수립: 부분 혹은 전체 개발 완료 시점에 대한 일정 수립.
  • 몇 개의 스트러 적용 → 부분적 기능의 구현 제품을 제공하는 것을 릴리즈라고 합니다.
  • 이터레이션: 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도의 기간으로 진행됨.
  • 승인 검사: 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트.
  • 소규모 릴리즈: 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것.
• XP의 주요 실천 방법
  • Pair Programming: 다른 사람들과 함께 프로그래밍을 함께 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성합니다.
  • Collective Ownership: 개발 코드에 대한 권한과 책임은 공동으로 소유합니다.
  • Test Driven Development: 테스트 케이스를 먼저 작성하면 자신이 무엇을 해야 할지 정확히 파악합니다.
  • Whole Team: 모든 구성원 (고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 합니다.
  • Continuous Integration: 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합됩니다.
  • Refactoring (리팩토링): 변경 시 시스템을 재설계. 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위함입니다.
  • Small Release: 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있습니다.
    • 방법론의 심층 분석:
      • 애자일 방법론 확장: 스크럼과 XP 외에 칸반, 린 등의 다른 애자일 방법론에 대한 설명과 비교 분석을 추가하여 더 다양한 상황에 적용할 수 있도록 할 수 있습니다.

Ⓒ 개발 기술 환경 파악

① 개발 기술 환경 파악 개요.

• 오픈 소스를 사용할 때 주의해야 할 내용을 제시. ② 운영체계(OS).
  • 컴퓨터 시스템의 자원을 효율적으로 관리, 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어.
  • 운영체제 관련 요구사항: 가용성, 성능, 기술지원, 구현성, 구축비용. ③ 데이터베이스 관리.
  • 사용자와 데이터베이스 사이에서 정보를 생성해주고, 데이터베이스를 관리해 주는 소프트웨어.
  • DBMS
    • 가용성, 성능, 기술지원, 상호호환성, 구축비용 ④ 웹 애플리케이션 서버 (WAS, Web Application Server)
  • 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어입니다. ⑤
  • 제한 없이 사용할 수 있도록 소스코드로 공개한 소프트웨어입니다.
    • 최신 동향 반영:
      • DevOps: 최근 소프트웨어 개발 및 운영의 핵심 트렌드인 DevOps에 대한 내용이 부족합니다. CI/CD (지속적 통합/지속적 배포), 인프라 자동화 등의 개념을 추가하여 실제 개발 환경에서 어떻게 적용되는지 설명할 수 있습니다.
      • 클라우드 네이티브: 클라우드 환경에서 개발 및 배포하는 방식인 클라우드 네이티브와 관련된 내용이 부족합니다. 컨테이너, 쿠버네티스 등의 개념을 추가하여 현대적인 개발 환경에 대한 이해를 높일 수 있습니다.
      • 마이크로서비스 아키텍처 (MSA): 모놀리식 구조에서 마이크로서비스 아키텍처로 변화하는 추세에 맞춰 MSA의 장단점, 구현 방식 등을 추가하여 좀 더 심층적인 내용을 다룰 수 있습니다.

Ⓐ 요구사항 정의.

① 개요

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 운영되는데 필요한 제약조건, 유지보수 과정에서 필요한 기준과 근거를 제공.
  • 요구사항의 유형
    • 기능 요구사항, 비기능 요구사항, 사용자 요구사항, 시스템 요구사항 ② 기능 요구사항
  • 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
    • 시스템 입력 → 무엇이 되어야하나.
    • 연산을 수행하여야 하는데 대한 시험
    • 시스템을 통해 제공받기를 원하는 기능. ③ 비기능 요구사항.
  • 품질이나 제약사항과 관련된 요구사항입니다.
    • 시스템 구성 요구사항.
    • 성능 테스트
    • 인터페이스 요구사항
    • 데이터를 구축하기 위해 필요한 요구사항
    • 테스트 요구사항
    • 보안 요구사항
    • 품질 요구사항: 가용성, 정합성, 상호 호환성, 대중성, 이식성, 학습성, 보안성 등
    • 제약사항.
      • 프로젝트 관리 요구사항
      • 프로젝트 지원 요구사항 ④ 사용자 요구사항.
  • 사용자 관점에서 본 시스템이 제공해야 할 요구사항입니다. ⑤ 시스템 (System requirement)
  • 개발자 관점에서 본 시스템 전체가 사용자나 또 시스템에 제공해야 할 요구사항
    • 요구사항 분석 심화:
      • 요구사항 관리: 요구사항이 변경될 때 어떻게 추적하고 관리해야 하는지, 요구사항 변경 관리 프로세스에 대한 내용을 추가할 수 있습니다.
      • 비기능 요구사항 상세화: 성능, 보안, 사용성 등 비기능 요구사항을 좀 더 구체적으로 설명하고, 각 요구사항을 어떻게 측정하고 검증할 수 있는지 방법론을 제시할 수 있습니다.
      • 요구사항 분석 도구: 요구사항 분석에 활용되는 다양한 도구 (예: Jira, Confluence, Visio)를 소개하고, 각 도구의 특징과 활용법을 설명할 수 있습니다.

Ⓑ 요구사항 개발 프로세스

• 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동입니다.
  • 타당성 조사가 선행되어야 합니다.
  • 요구사항 개발은 요구공학의 한 요소입니다.
    • 도출 → 분석 → 명세 → 확인
• 요구사항 도출 (Requirement Elicitation, 요구사항 수집)
  • 요구사항 도출은 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항을 어떻게 수립했는지 식별하고 확인하는 과정입니다.
  • 개발자와 고객 사이에 의견이 대립하고 이해관계자가 식별됩니다.
  • 요구사항을 도출하는 주요 기법
    • 청취와 인터뷰
    • 설문
    • 브레인 스토밍
    • 회의
    • 프로토타이핑
    • 유스케이스
    • 워크숍
    • 프로토타이핑
    • 유스케이스
• 요구사항 분석 (Requirement Analysis)
  • 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을
• 요구사항 명세 (Requirement Specification)
  • 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미합니다.
  • 기능 요구사항을 빠짐없이 기술합니다.
• 요구사항 확인 (Requirement Validation)
  • 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토하는 활동
    • 요구사항 분석 심화:
      • 요구사항 관리: 요구사항이 변경될 때 어떻게 추적하고 관리해야 하는지, 요구사항 변경 관리 프로세스에 대한 내용을 추가할 수 있습니다.
      • 비기능 요구사항 상세화: 성능, 보안, 사용성 등 비기능 요구사항을 좀 더 구체적으로 설명하고, 각 요구사항을 어떻게 측정하고 검증할 수 있는지 방법론을 제시할 수 있습니다.
      • 요구사항 분석 도구: 요구사항 분석에 활용되는 다양한 도구 (예: Jira, Confluence, Visio)를 소개하고, 각 도구의 특징과 활용법을 설명할 수 있습니다.
• ⑥ 요구공학 (Requirements Engineering)
  • 요구 사항은 정의하고, 분석 및 관리하는 프로세스로 연구하는 학문입니다.
• ⑦ 요구사항 명세 기법
  • 정형 명세 기법
  • 비정형 명세 기법
    • 상태/기능 액체 중심
    • 기업
    • 수학적 원리 기반, 모델 기반
    • 일반 명사, 동사 등의 자연어를 기반으로
  • 특징
    • 요구사항을 통합하고 간결하게 표현할 수 있습니다. 자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라
    • 요구사항에 대한 결과가 작성자에 관여지없이 다를 수 있어 일관성이 떨어짐, 해석 결과가 다를 수
    • 일관성이 있으면 완전성 검증이 가능합니다.
    • 표기법이 어려워 사용자가 이해하기 어렵습니다.

007 (B) 요구사항 분석.

① 요구사항 분석.

• 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동입니다.
  • 비용과 일정에 대한 검토성, 요구를 정확하게 추출합니다. ② 구조적 분석 기법.
  • 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법입니다.
    • 분석 요구와 분석 절차를 이용하여 요구사항을 파악하고 문서화합니다.
    • 하향식 방법을 사용하여 시스템을 세분화합니다.
    • 분석 도구
      • 자료 흐름도 (DFD)
      • 자료 사전 (DD)
      • 개체 관계도 (ERD)
      • 상태 전이도 (STD)
      • 소단위 명세서 (Mini - Spec)
      • 제어 명세서
  • 자료 흐름도.
    • 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법입니다.
    • 그래프, 버블 차트라고도 합니다.
    • 구조적 분석 기법이라고도 합니다.
    • 자료 흐름도 기본 기호
      • 프로세스: 자료를 변환시키는 시스템의 한 부분 (처리과정을 나타내며 처리 기능, 변화)
      • 버블이라고도 합니다. 표기법 O, 둥근 원, 모서리 없는 사각형
      • 자료 흐름: 자료의 이동(흐름)이나 연관 관계를 나타냄 화살표 →
      • 자료 저장소: 시스템에서의 자료 저장소 (파일, 데이터베이스)를 나타냄 물품대자
      • 단말: 시스템과 교신하는 외부 개체로, 입력데이터가 만들어지고 출력데이터를 받습니다.
  • 자료 사전 (DD, Data Dictionary)
    • 자료 사전은 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것입니다.
    • 데이터를 설명하는 데이터, 즉 데이터의 데이터는 메타데이터라고 합니다.
    • 기호 자료의 정의: (=) : ~ 로 구성되어 있습니다.
    • 자료의 연열: (+) : 그리고 (and)
    • 자료의 생략: [()] : 생략 가능한지
    • 자료의 선택: [{}] : 또는 (or)
    • 자료의 반복: {(m)} : Heration of
      • ① : 2번 이상 반복
      • ② Gr : 최대 m번 이상 반복 안됨
      • @ Im : m번 반복하고 반송
    • 자료의 설명: 주석 (Comment)

008 : 요구사항 분석 CASE & HIPO

• 요구사항 분석용 CASE (자동화 도구)
  • 요구사항을 자동으로 분석, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미합니다.
• 대표적인 요구사항 분석용 CASE
  • SADT: 소프트웨어 분석, 시스템 소프트웨어 설계를 위한 도구
  • SREM = RSL/CREUS: 요구사항을 명확히 기술하도록 할 목적으로 개발된 도구
  • PSL/PSA: PSL과 PSA를 사용하는 자동화 도구
  • TAGS: 시스템 설정 방법, 응용에 대한 자동적인 방법, 중심 자동적으로?
• HIPO (Hierarchy Input Process Output)
  • HIPO는 시스템 설계자들의 입력, 처리, 결과의 기능을 모두 표현한 것입니다.
  • 하향식 소프트웨어 개발을 위한 문서화 도구입니다.
  • 기능과 자료의 의존 관계를 동시에 표현할 수 있습니다.
  • 이해하기 쉽습니다.
  • 인터페이스를 계층 구조로 표현한 것을 HIPO chart 라고 합니다.
• HIPO 차트의 종류
  • 가시적 도표 (Visual Table of Contexts, 도식표)
  • 총괄적 도표 (Overview Diagram, 총괄 도표, 개요도)
  • 세부적 도표 (Detail Diagram)

009 (8) UML (Unified Modeling Language) 의 개요

• UML (Unified Modeling Language)
  • 시스템 개발 과정에서 상호 간의 의사소통이 원활하게 이루어지도록 표준화된 대표적인 객체 지향 모델링 방식입니다.
  • 기존 객체 지향 방법론의 단점을 통합했습니다.
  • Oonta 에서 봉준으로 통합했습니다.
  • UML의 구성 요소
    • 사물 (Things)
    • 관계 (Relations)
    • 다이어그램 (Diagram)
  • 사물 (Things)
    • 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말합니다.
    • 구조 사물: 시스템이 개념적, 물리적으로 습득을 표현합니다.
      • 클래스 (Class), 유스케이스 (UseCase), 컴포넌트 (Component), 인터페이스 (Interface), 노드(Node) 등
    • 행동 사물: 시간과 공간에 따른 요소들의 행위를 표현합니다.
      • 상호작용 (Interaction), 상태 머신 (State Machine)
    • 그룹 사물: 요소들을 그룹으로 묶어서 표현 패키지
    • 주해 사물: 부가적인 설명, 제약조건들을 표현합니다.
      • UML 확장:
        • 다양한 UML 다이어그램: 클래스 다이어그램 외에도 유스케이스 다이어그램, 시퀀스 다이어그램, 상태 다이어그램 등 다양한 UML 다이어그램의 작성법과 활용법을 추가하여 실질적인 모델링 능력을 향상시킬 수 있습니다.
        • 모델링 실습: 단순히 이론적인 설명뿐 아니라, 간단한 예시 프로젝트를 기반으로 직접 UML 모델링을 해보는 실습 내용을 추가하여 이해도를 높일 수 있습니다.

010 - Ⓐ UML - 관계 (Relationship)

• 관계 (Relationships)
  • 사물과 사물 사이의 연관성을 표현하는 것입니다.
  • 연관 관계
    • 2개 이상의 사물이 서로 연관되어 있는 관계입니다.
    • 사물 사이를 실선으로 연결하여 표현합니다.
    • 양방향 관계의 경우 화살표, 생략 시 실선으로만 연결합니다.
    • 다중도로 선 위에 표기합니다.
    • 다중도
      • 1 : 한 개의 객체가 연관되어 있습니다.
      • n : 여러 개의 객체가 연관되어 있습니다.
      • 0..1 : 연관된 객체가 없거나 하나만 존재합니다.
      • 0..* : 연관된 객체가 없거나 다수일 수 있습니다.
      • 1..* : 연관된 객체가 최소한 1개 이상입니다.
      • m..n : 연관된 객체가 최소 m에서 최대 n개입니다.
      • • : 연관된 객체가 0개 이상 입니다.
  • 집합의 관계 (Aggregation)
    • 하나의 사물이 다른 사물에 포함되어 있는 관계입니다.
    • 포함하는 훕과 포함되는 훅은 서로 독립입니다.
    • 포함되는 폼 (본체, part)에서 포함하고 화살표, 속이 빈 마름모를 연결합니다.
  • 포함 (Composition) 관계
    • 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계입니다.
    • 서로 독립할 수 없고 생명주기를 함께합니다.
    • 포함과 즉 속이 채워진 마름모로 연결하여 포함합니다.
  • 일반화 (Generalization) 관계
    • 사물이 다른 사물에 비해 더 일반적이나 구체적인 관계입니다.
    • 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념은 하위라고 부릅니다.
    • 구체적 (하위) 사물에서 일반적 (상위)인 사물 쪽으로 속이 빈 화살표를 연결합니다.
  • 의존 (Dependency) 관계
    • 서로에게 영향을 주는 짧은 시간 동안 연관을 유지하는 관계입니다.
    • 사물의 변화가 다른 사물에도 영향을 주는 관계입니다.
    • 사물 (제공자) 쪽으로 점선 화살표를 연결하여 표현합니다.
  • 실체화 (Realization) 관계

    • 사용자가 할 수 있거나 해야 하고 기능으로의 세포로 규정할 수 있는 관계입니다.