[소프트웨어설계] 1. 소프트웨어공학과 개발 방법론

소프트웨어

• 개념: Program, DataStructure, Document
• 특징: 상품성, 복잡성, 변경 가능성, 복제성, 순응성, 비가시성
• 분류: 시스템 소프트웨어, 응용소프트웨어, 미들웨어 소프트웨어

시스템

• 개념: 저장, 처리, 가공해 출력할 수 있도록 설계, 구현된 정보체계
• 기본 요소: input, output, control, feedback, process

소프트웨어 위기 Software Crisis

• 원인: 개발 비용 증가, 인건비 상승, 성능 및 신뢰성 부족 등

소프트웨어 공학 Software Engineering

• 개념: 경제적으로 신뢰도 높은 소프트웨어를 만들기 위한 방법
• 등장 배경: 시간과 비용 부족, 품질 수준 부족, 유지 보수 역할의 증대, 크고 복잡한 소프트웨어에 대한 수요 증가
• 분류: 생명주기 모형, 프로세스 모형, 품질 관리, 유지 보수
  • 생명주기 모형: 폭포수, 프로토타입, 나선형, 애자일 개발 방법론
  • 프로세스 모형: ISO/IEC 12207, CMMI
  • 품질관리: 테스트, 코드리뷰, 정적분석
  • 유지보스: 버그 수정, 기능 추가, 기술 업그레이드
• 기본 원칙:
  • 최신 프로그램 언어, 최신 알고리즘 사용 현황 확인
  • 문서화를 통한 명확성 유지
• 공학적으로 좋은 소프트웨어 조건
  • 잠재적 에러 최소화
  • 유지 보수성 쉬워야 함
• 계층 구조: 도구, 방법론, 프로세스

---

소프트웨어 재공학 Software Reengineering

• 개념: 소프트웨어의 위기를 개발의 생산성이 아닌 유지 보수의 생산성으로 해결하려는 방법
• 재구조화: 재공학의 한 유형으로 설계의 변경 없이 프로그램을 개선하는 것
• 목표: 재사용 수월하게 함, 수명 연장
• 과정: Analysis → Restructuring → Reverse Engineering → Migration

소프트웨어 재사용 Software Reuse

• 기본 기술: 생성중심(모듈화), 합성 중심(모델화)
  • 모듈화: 재사용 단위를 찾아 발전, 전자칩
  • 모델화: 모듈을 생산성 있게 조립

재공학	재사용
개선하거나 수정	다른 소프트웨어에서 사용

리팩토링

겉으로 보이는 동작의 변화 없이 내부구조를 변경하는 것

 

CASE

• 개념: 자동화, 다이어그램을 쉽게 작성하게 해주는 소프트웨어 도구, 커뮤니케이션 증대
• 제공 기능: 전체 단계 연결, 자동화, 문서화 및 명세화, 표준화
• 원천기술: 구조적 기법, 프로토타이핑 기술, 정보저장소 기술
• 장점: 모듈의 재사용성, 문서화의 용이성, 시스템 수정 및 유지보수 축소
• 단점: 적응성 부족(템플릿 기반의 접근방식), 복잡성, 비용, 제한적인 협업, 문서화의 부족
• 분류: 상위, 하위, 통합

요구사항 분석을 위한 CASE 도구

• 개념: 요구사항을 자동으로 분석하고, 분석 명세서를 기술하도록 개발된 도구, DB를 모두가 이용 가능
• 종류: SADT(구조적 분석 및 설계도구)

---

소프트웨어 설계 방법론

소프트웨어 생명 주기 SDLC: Software Development Life Cycle

• 개념: 소프트웨어 제품의 개념 형성~운용/유지보수 까지의 변화의 모든 과정
• 타당성 검토→개발 계획→ 요구사항 분석 → 설계 → 구현→ 테스트→ 운용→ 유지보수
  • Requirement Analysis: 명세서 작성, 시스템 구성요소 및 인터페이스 등을 정의
  • Design: 시스템의 구조 설계
  • Implementation: 소프트웨어 개발, 프로그래밍, 테스팅, 디버깅 등의 작업 수행
  • Testing: 요구사항을 충족하는 지 테스트
  • Maintenance: 요구사항에 부합하도록 유지 보수 수행, 버그수정, 기능 개선 등

폭포수 모형 Waterfall Model

• 고전적 생명주기 모형
• 타당성 검토 → 계획→Requirement Analysis → Design → Implementation → Testing → Maintenance
• 장점:
  • 예측 가능성 증가
  • 단계별 문서화 작업 필요
  • 순차적인 접근 방법
  • 오래됨
• 단점
  • 오류가 생겨 거꾸로 되돌아가는 상황 불가
  • 초기에 요구사항을 완벽히 수집, 분석해야 해 요구사항 변경이 어려움
  • 각 단계 완료 후 다음 단계이므로 전체 개발 기간이 길어짐
  • 요구를 만족하는 지는 최종적인 성과물이 완성되어야 함

HIPO (HierarchyInputProcessOutput) ⭐

• 개념: 구조적 분석 및 설계 방법론 중 하나
• 구성: 가시적 도표(Visual Table of Contents), 총체적 다이어그램(Overview Diagram), 세부적 다이어그램(Detail Diagram)
• 특징:
  • 하향식 소프트웨어 개발을 위한 문서화 도구
  • 계층적 구조
  • 입력, 처리, 출력을 각각 분리해 분석 및 설계
  • 보기 쉽고 이해하기 쉬워 수정 및 유지보수 쉬움

	폭포수 모형	HIPO
접근 방법	단계별 직선적인 순차적 접근 방식	계층적 구조를 이용한 구조적 분석 및 설계
구성 요소	요구사항 분석→ 설계 → 구현 → 검증 → 유지 보수	입력, 처리, 출력으로 구분된 계층적 구조
장점	개발 비용과 시간 감소	명확한 계획수립이 가능해 대규모 프로젝트에 적합
단점	초기 요구사항 분석에 문제가 발생하면 전체 프로젝트에 영향	초기 분석이 복잡하고 시간이 많이 소요

 

나선형 모형 Spiral Model

• 개념: 반복적인 작업을 수행하는 점증적 생명주기 모형
• 특징:
  • 유지 보수 과정 필요 없음
  • 위험을 최소화 하는 것이 목적
• 계획 수립 → 위험 분석→ 개발 및 검증 → 고객 평가 및 다음 단계 수립

프로토타입 모형 Prototype Model

• 개념: 시제붐을 미리 만들어 최종 결과물을 예측하는 모형
• 특징:
  • 요구사항의 변경이 용이
  • 요구사항이 불명확한 경우 적용하기 좋음
  • 개발 중 발생한 요구사항 쉽게 반영
  • 공동의 참조모델을 제공
  • 실제 소프트웨어와의 차이 발생 가능
• 장점:
  • 요구사항 수집의 정확성 향상
  • 시간 및 비용 절감
  • 고객 만족도 향상
  • 효율적인 협업 및 의사소통
• 단점:
  • 초기에 대량의 개발자나 사용자 참여가 필요
  • 프로토타입 개발로 인한 추가비용 발생
  • 최종 목표가 명확하지 않으면 프로토타입 개발 어려움

	상향식	하향식
시작점	컴포넌트 먼저 설계 Element Function	Main User Function
인터페이스 정의	모듈의 완성된 후 정의	모듈 설계 초기에 정의
통합	모듈 완성 후 통합	모듈을 점차 조합하여 통합
장점	기능 추가 쉬움, 모듈의 독립성 높음	통합이 쉽고 설계가 명확
단점	시스템 전체 파악 어렵고 설계 복잡	기능 구현 어려움, 모듈의 독립성 낮음

 

V-모델⭐

• 특징:
  • 폭포수 모형 + 시스템 검증 + 테스트 작업
  • 신뢰도 높은 시스템 개발 생명주기 초반부터 테스트 작업

• 장점:
  • 개발 초기부터 테스트를 수행해 결함을 초기에 발견해 수정 가능
  • 모든 개발 단계에서 요구사항 준수하는 지 확인 가능
  • 단계마다 검증 및 확인 단계가 있어 개발 과정의 진행 상황을 파악하기 쉬움
  • 테스트 케이스의 누락 최소화
• 단점:
  • 많은 비용과 시간 소요
  • 요구사항 변경 어려움, 변경되면 요구사항에 해당하는 모든 단계 수정해야 함
  • 위험 요소가 있는 경우 테스트 케이스 추가하지 않으면 결함 발생 가능성 높아짐

애자일 Agile 개발 방법론

• 개념:
  • 고객과의 협업에 초점을 둔 다양한 방법론 전체를 일컫는 것
• 특징:
  • 짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션의 변화
• 종류:
  • XP, SCRUM, FDD, …
• Agile선언문: 문서중심이 아닌, 실행할 수 있는 소프트웨어 중시
  • 프로세스, 도구 → 개인과의 소통
  • 완벽한 문서 → 실행되는 소프트웨어
  • 계약 협상 → 고객과의 협업
  • 계획을 따르는 것 → 변경에 대한 응답
• 장점:
  • 빠른 개발 및 출시
  • 요구사항 변경에 대한 대응이 빠름
  • 개발자의 참여와 역할 강조
  • 너무 많은 변화에는 문제점 발생 가능
• 단점:
  • 관리가 부족할 수 있으므로 관리자는 더욱 노력해야 함
  • 대규모 팀의 경우 협업이 어려움
  • 고객의 참여가 미흡하면 요구사항에 대한 정확한 파악이 어려워 짐

---

XP (eXtreme Programming)

• 개념:
  • 요구사항이 시시각각 변동이 심한 경우 적합
  • 요구에 맞는 소프트웨어를 신속하게 제공하는 것을 목표
  • 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법
  • 적응성에 높은 가치
  • 구조적 방법론이 아닌 애자일 방법론 중 하나
• 핵심 가치: Communication, Simplicity, Feedback, Courage(용기), Respect(존중)
• 절차
  • User Story : 사용자의 요구사항을 간단한 시나리오로 표현, 고객에 의해 작성됨
  • Release Planning : 부분적으로 기능이 완료된 제품을 제공하는 것의 일정 수립
  • Iteration : 하나의 릴리즈를 세분화한 단위, 1~3주 단위로 진행
  • Acceptance Test : 릴리즈 단위 개발이 구현 된 후 고객이 직접 테스트, 오류가 발견되면 다음 Iteration에 추가하고 완료 후에는 다음 Iteration을 진행
  • Small Release : 릴리즈 단위를 기능별로 세분화하면 고객의 반응을 기능 별로 확인 가능, 최종 완제품일 경우 고객에 의한 최종 테스트 진행 후 고객에게 제공

• XP의 12가지 실천 사항 Practice
  1. Pair Programming : 두 사람이 짝이 되어 한 사람은 코딩, 다른 사람은 검사를 수행
  2. Planning Game : 게임처럼 목표를 구고 기획 수행
  3. Test Driven Development : 단위 테스트 후 실제 코드 작성
  4. Whole Team : 고객을 프로젝트 팀원으로 상주
  5. Continuous Integration : 상시 빌드 및 배포가 가능한 상태로 유지
  6. Design Improvement : 불필요한 기능 제거 및 리팩토링
  7. Small Releases : 필요한 기능들만 갖춘 간단한 시스템을 빠르게 배포
  8. Coding Standards : 표준화된 코드 작성
  9. Collective Ownership : 소스코드는 모든 개발자가 언제라도 수정가능
  10. Simple Design : 가장 간결한 디자인 상태 유지
  11. System Metaphor : 최종 개발 되어야 할 시스템 구조를 조망
  12. Sustainable Pace : 초과 근무 지양

SCRUM

• 개념
  • 요구사항 변경에 신속하게 대처할 수 있도록 반복적이고 점짐적인 팀중심의 소프트웨어 개발 방법론
  • 팀 구성, 역할, 일정 결과물 등을 정하는 것
• 특징
  • 팀원 스스로 팀을 구성 - Self Organizing
  • 개발 작업에 관한 모든 것을 팀원 스스로 해결 - Cross Functional
• 가치: 확약, 전념, 정직, 존중, 용기
• 기본 원리
  • 스프린트 단위로 개발
  • 행하는 작업은 고정, 반복주기(2~4주)마다 이해 관계자에게 진척도 보고
  • 정해진 시간을 철저히 지켜야하고 완료된 모든 작업은 제품 백로그에 기록됨
• 담당자별 역할
  • 제품 책임자(Product Owner) : 개발 의뢰자, 사용자, 요구사항을 파악해 기능 목록(Product Backlog)을 작성
  • SCRUM Master : 업무 배분, 원칙과 가치를 지키도록 지원
  • SCRUM Team : 제품 책임자, 스크럼 마스터를 제외한 팀원
• Product Backlog → Sprint → Sprint Planning Meeting → Daily SCRUM Meeting → Finished Work → Sprint Review → Sprint Retrospective
  • Product Backlog: 요구사항(User Story)을 우선순위에 따라 나열한 목록, 지속적으로 업데이트
  • Sprint: 작은 단위의 개발 업무, 2~4주 마다 진척도 보고
  • Sprint Planning Meeting: 백로그에서 진행할 항목을 선택하고 선택한 스프린트에 대한 단기 일정 수립
  • Daily SCRUM Meeting : 진행 상황만 점검
  • Sprint Review : 개발자와 사용자 같이 참석해 검토
  • Sprint Retrospective : 스프린트에서 수행한 활동과 결과물을 살펴봄