[TOPCIT] 01소프트웨어 개발_1. 소프트웨어 공학 개요

1. 소프트웨어 공학 개요

1.1 소프트웨어 공학의 배경과 목적

소프트웨어 공학 정의

• 요구사항 분석에서부터 유지보수에 이르기 까지 전과정(생명주기)에 걸쳐 예상되는 어려움을 해결하기 위한 체계적인 관리와 효율적 업무 수행을 지원해주는 기술, 기법
  => 프로세스, 인력, 기반 인프라 기술의 3가지 핵심 요소를 균형있게 유지해야한다.

소프트웨어 공학 배경

• 소프트웨어에 대한 수요가 급증하고
  => 재사용성을 높여 효율적인 소프트웨어를 개발하기 위한 방법들을 연구
  => 시장에서 우위를 선점하기 위해 개발 시간을 단축해야 했다
  이로인해 개발 생산성을 높이는 방법에 대한 연구가 본격화 되었고 애자일 방법론이 본격적으로 도입되었다.

소프트웨어 공학의 4가지 중요요소

1. 방법(프로젝트 계획수립, 자료구조, 알고리즘, 코딩, 테스트 등)
2. 도구(소프트웨어 개발을 지원하는 시스템)
3. 절차(방법, 도구를 결합하여, 합리적이고 적시에 개발할 수 있도록 함)
4. 사람(인적자원)

1.2 소프트웨어 개발 생명주기

정의

사용자 환경 및 문제점 이해부터 운용/유지 보수까지의 모든 과정

• 일반적인 소프트웨어 개발 생명주기

  타당성검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수

목적

프로젝트 비용산정과 개발 계획 수립, 기본 골격 구성, 용어의 표준화, 프로젝트 관리

소프트웨어 생명주기 선정

• 프로젝트에 존재하는 리스크/불확실성을 최소화 시킬수 있어야 함
• 폭포수 모델, 프로토타입모델, 진화모델, 점증적모델 등이 대표적인 생명주기 모델임

V 모델

• 시스템의 요구사항이 모두 식별되고 명확할 때 이상적인 생명주기 모델
• 프로젝트에 적용, 관리하기가 용이
• 프로젝트의 검증 및 확인을 강조하는 모델
• 전체 개발 주기동안 개발 활동과 이에 해당하는 테스트 활동이 병행 되어진다.
• 테스트 동안 결함이 발견되었을 경우, 개발 활동의 어느 단계를 재 수행되어야 하는지 알 수 있다.
• 표준 통신 프로토콜을 구현하는 프로젝트는 V 모델이 잘 적용될 수 있는 전형적인 프로젝트의 예이다.

VP 모델(V Model with Prototyping)

• 프로토타이핑(Prototyping): 시스템에 대한 이해 또는 리스크, 불확실성 요소와 같은 이슈를 해결하기 위해 시스템 혹은 시스템의 일부분을 빠르게 개발하는 방법
• 개발자와 고객이 공통적인 이해를 이끌어 낼 수 있다.
• 프로젝트의 불확실성 요소나 리스크를 줄일 수 있다.
• 두 가지 접근방법으로 수행 가능
  • 접근방법1 : 문제가 명확하지 않을 때 적용가능
    1. 불확실성 요소를 정의
    2. 해결책을 찾고, 이를 적용하기 위한 방법을 정의
    3. 해결책을 적용해 본다(반복 수행될 수 있음)
    4. 적용 결과를 통해 불확실성 요소의 원인을 찾는다.
  • 접근방법2: 적용하려는 해결책에 리스크나 불확실성 요소가 존재하는 경우
    1. 불확실성 요소를 정의
    2. 선택 가능한 해결책을 열거, 선택 기준 정의
    3. 선택 기준에 따라 해결책을 평가
    4. 가장 적합한 해결책 선택

점증적 모델

• 핵심이 되는 부분을 먼저 개발하여 동작 가능하게 만든 후, 나머지 기능을 구현하는 방식이다
• 개발 시간을 줄일 필요가 있을 경우 유용한 모델
• 대부분의 요구사항이 정의되어 있지만, 시간이 지남에 따라 개선 여지가 있는 경우에 유용한 모델
• V 모델 및 VP모델 모두 적용 가능

진화 모델

• 전체 시스템에 대한 개발 단계를 여러 번 반복
• 하나의 시스템이 개발되어 사용되면서 변경 사항이 도출되고, 이 변경사항은 다음 시스템 개발에 반영
• 시스템 개발 시간을 줄일 필요가 있을 경우 유용한 모델
• 시스템 명세가 전체적으로 불분명한 경우 적합한 모델
• 제품의 개선이 지속적으로 요구되는 경우에 적합한 모델이다.

1.3 소프트웨어 개발 방법론

소프트웨어 개발 방법론의 필요성

• 개발 경험의 축적 및 재활용을 통한 개발 생산성을 향상
• 효과적인 프로젝트 관리
• 공식 절차와 산출물을 제시하고 표준용어를 통일하여 의사소통 수단 제공
• 각 단계별 검증과 승인된 종료를 통해 일정 수준의 품질 보증

소프트웨어 개발 방법론 비교

소프트웨어 개발 단계

1. 요구사항 분석: 무엇을 개발할 것인지 결정 -> 소프트웨어 개발 기간과 비용의 초과, 품질 저하를 방지할 수 있음
2. 설계: 시스템 구조를 결정 -> 품질과 안정감에 영향을 준다 -> 안정감이 낮으면 유지보수도 어려움
3. 구현: 설계 명세를 기반으로 프로그래밍
4. 테스팅: 평가

1.4 애자일 개발 방법론

• 애자일 방법론 종류: 스크럼, XP, 린 소프트웨어 개발 방법론

XP

• XP는 반복적 개발방법론의 일종이다. 프로젝트 수행과정에 여러 번의 반복이 있으며 테스트 결과에 따라 반복적으로 업무를 수행한다.
• XP 개발절차 및 용어
  

  

  • 유저 스토리: 요구사항 수집, 의사소통 도구를 말하고 기능단위의 필요한 내용을 간단하게 기재
  • 스파이크: 어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램으로서, 사용자 스토리의 신뢰성 증대, 기술 문제의 위험을 감소하는 목적을 가짐
  • 릴리즈 계획: 전체 프로젝트에 대한 계획을 수립하여 하나의 반복을 1~3주로 나구고 균일하게 유지
  • 승인 테스트: 릴리즈 전 인수 테스트로서 고객이 직접 수행
  • 작은 릴리즈: XP 주기의 마지막 단계이고 소규모로 빈번하게 배포하면 고객에게 여러 이득을 조기에 제공할 수 있다.
• XP 가치
  1. 의사소통: 고객, 개발자, 관리자들간의 의사소통을 통해 문제해결
  2. 단순성: 불필요한 복잡성을 제거하여 설계를 단순명확하도록 유지
  3. 피드백: 최대한 빨리 최대한 많은 피드백으로 개선에 활용한다.
  4. 용기: 요구사항 및 기술 변경에 용감하게 대처, 단숨함을 추구하고 피드백을 강화
  5. 존중: 템에 속한 다른 사람들을 중요하게 여기지 않고 프로젝트를 제대로 할 수는 없다.
• XP 실천 방법
  

  

  .PNG)

스크럼

• 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경험적 관리기법의 대표적인 형태이다.
• 역할자 유형
  • 제품 책임자: 계획 수립 시점에 핵심 역할을 담당하지만 스프린트 시작 후에는 가능한 관여하지 않는다.
  • 스크럼 마스터: 팀의 업무를 방해하는 요소 제거에 노력한다.
  • 스크럼 팀: 최소 5명에서 9명으로 구성된다
• 스크럼 프로세스
  • 스프린트: 1~4주 단위의 반복개발기간을 가리킨다.
  • 3가지 미팅: 일일 스크럼, 스프린트 계획, 스프린트 리뷰
  • 3가지 산출물: 제품 백로그, 스프린트 백로그, 소멸 차트
  • 제품 백로그: 기능의 우선순위를 정리한 목록, 정의된 기능을 사용자 스토리라고 한다.
  • 스프린트 백로그: 하나의 스프린트 동안 개발할 목록
  • 소멸 차트: 개발을 완료하기까지 남은 작업량을 보여주는 그래프
  • 스프린트 게획: 각 스프린트에 대한 목표를 세우고 진행할 항목을 선택
  • 일일 스크럼: 매일 15분간 프로젝트 진행상황을 공유하는 회의
  • 스프린트 리뷰: 스프린트 동안 작업한 결과를 데모하고 피드백을 받는다.
• 특징
  • 투명성: 프로젝트의 상태나 문제점을 효과적으로 파악
  • 타임박싱: 시간을 제한함으로써 프로젝트 진행에만 집중
  • 커뮤니케이션: 문제점을 공유하고, 사용자 스토리의 구현 난이도, 시간을 토론
  • 경험주의 모델: 프로젝트에 참여하는 개개인의 경험을 중요시한다. 스크럼은 기본적인 구조만 동일할 뿐 실제로 팀(구성인원)마다 달라지는 것을 인정한다.