S/W 생명 주기, 스크럼, XP, 현행 시스템 파악

1. S/W 생명 주기

- S/W를 개발하기 위해 정의, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

- S/W 개발 단계, 각 단계별 주요 활동, 그 활동의 결과로 표현됨

- 모델있음

- 모델 종류

• 폭포수 모델
• 프로토타입 모델
• 나선형 모델
• 애자일 모델
• etc.

 

※ S/W 공학
- S/W 의 위기 극복을 위해 연구된 학문
- S/W 품질 및 생산성 향상을 위해 여러 가지 방법론, 도구, 관리 기법이 있음
- 기본 원칙
1. 현대적인 프로그래밍 기술을 계속적으로 적용
2. 개발된 S/W 의 품질 유지를 위해 지속적으로 검증
3. S/W 개발 관련 사항 및 결과를 명확하게 기록

 

1 - 1) 폭포수 모델  Waterfall Model

- 각 단계를 확실히 끝내고 다음 단계로 넘어가는 개발 방법론

- 이전 단계로 못 돌아감

- 특징

• 가장 오래되고 폭넓게 사용함  (전통적, 고전적)
• 선형 순차적 모형  (한 단계가 끝나야 다음으로 갈 수 있음)
• 매뉴얼 작성해야함  (매뉴얼 : 프로그램들의 사용 및 운영에 대한 내용이 기술된 문서)
• 2개 이상의 과정이 병행하여 수행되지 않음

폭포수 모델

 

 

1 - 2) 프로토타입 모델   Prototype Model

- 실제 개발될 S/W의 시제품 을 만들어 최종 결과물을 예측함

- 특징

• 시제품은 사용자 와 시스템 사이의 인터페이스에 중점을 두어 개발
• 개발이 완료되고 오류가 발생하는 단점 (폭포수 모델 단점) 을 보완

프로토타입 모델

 

1 - 3) 나선형 모델  Spiral Model

- 폭포수 & 프로토타입의 장점 + 위험 분석 기능 추가한 모델

- 특징

• 여러 번의 개발 과정을 통해 점진적으로 완벽한 최종 S/W 개발  (점진적)
• 목적 : 개발 시 발생 가능한 위험을 관리 및 최소화
• 정밀함
• 유지보수 필요 X
• 누락 또는 추가된 요구사항 첨가 가능
• 순서 : 계획 수립  >  위험분석  >  개발 및 검증  >  고객 평가

나선형 모델

 

1 - 4) 애자일 모델   Agile Model

- 일정한 주기를 반복하며 개발하는 모델

- 고객의 요구사항 변화에 유연하게 대응 가능

- 특징

• 어느 특정 개발 방법론이 아님
• 고객과의 소통에 초점을 맞춘 방법론
• 기업 활동 전반에 걸쳐 사용
• 스프린트 (Sprint)  or  이터레이션(iteration) 이란 짧은 개발 주기를 반복하며
• 반복되는 주기마다 결과물에 대한 고객 평가 및 요구를 적극 수용
• 각 개발 주기에서 고객의 요구사항에 우선순위를 만들어 개발 진행
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합

- 모델 예시 : 스크럼, XP, 칸반, Lean 등등

애자일 모델

- 핵심가치 4가지

• 프로세스 및 도구 < 개인과 상호작용
• 방대한 문서 < 실행되는 S/W
• 계약 협상 < 고객과 협업
• 계획 이행 < 변화 반응

- 개발 12가지 실행 지침

1. 유용한 S/W 를 빠르고, 지속적으로 제공
2. 개발 막바지라도 요구사항 변경 적극 수용
3. 몇 주 단위로 실행되는 S/W 제공
4. 고객과 개발자가 프로젝트 기간엔 협업
5. 개발에 대한 참여 의지가 확실한 사람들로 팀 구성, 필요한 개발 환경+지원 제공, 일 잘 마무리 하도록 신뢰
6. 같은 사무실에서 면전에서 의견을 나눔
7. 개발의 진척도 확인 1차 기준은 작동하는 S/W
8. 지속 가능한 개발 장려, 일정한 속도로 개발 진행
9. 기술적 우수성 및 좋은 설계에 지속적 관심을 가지면 민첩성 향상
10. 단순화 추구
11. 최상의 아키텍처, 명확한 요구사항, 최상의 설계는 자기 스스로 일을 주도하는 조직적인 팀에서 나옴
12. 더 효과적인 팀이 되는 방안을 정기적으로 고민하고 그에 따라 팀의 행동을 조정

- 폭포수 모델 VS 애자일 모델

구분	폭포수	애자일
새로운 요구사항 반영	어려움	지속적으로 반영
고객과의 의사소통	적음	지속적임
테스트	마지막에 모든 기능을 테스트	반복되는 일정 주기가 끝날 때마다 테스트
개발 중심	계획, 문서 (매뉴얼)	고객

 

 

2. 스크럼 기법

- 애자일 모델 중 하나

- 팀이 중심이 되어 개발 효율성을 높임

- 구성

• 제품 책임자  (PO: Product Owner)
• 스크럼 마스터  (SM: Scrum Master)
• 개발팀  (DT: Development Team)

 

1)  PO  제품 책임자

- 보통 개발 의뢰자나 사용자가 담당

- 역할

• 이해관계자들 의견 종합하여 제품에 대한 요구사항을 작성
• 백로그 작성, 백로그에서 우선순위 지정
• (백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록)
• 제품 테스트 수행
• 주기적으로 요구사항의 우선순위 갱신

※ 팀원들도 백로그에 스토리 추가 가능 but 우선순위 지정은 불가능

(스토리 : 백로그에 담겨질 요구사항)

 

2)  SM  스크럼 마스터

- 역할

• 객관적인 시각에서 조언
• 가이드 역할
• 스크럼 회의 주관하여 진행 사항 점검 및 개발 과정에서 발생한 장애 요소를 공론화하여 처리

 

3)  DT  개발팀

- PO, SM 제외 나머지 개발에 참여하는 모든 사람

- 개발자, 디자이너, 테스터 등등

- 보통  7 ~ 8 명이 적당

 

 

2 - 1) 스크럼 개발 프로세스

 

스크럼 프로세스

1} 제품 백로그  Product Backlog

- 제품 개발에 필요한 모든 요구사항 (User Story) 을 우선순위에 따라 나열한 목록

- 지속적으로 업데이트 됨

- 백로그에 적힌 요구사항을 토대로 릴리즈 계획 (전체 일정 계획) 수립

 

 

2} 스프린트 계획 회의  Sprint Planning Meeting

- 백로그 중 이번 스프린트에서 작업할 양을 정하고 그에 맞춰 단기 일정 수립

- 스프린트에서 처리할 요구사항을 태스크 (Task) 라는 단위로 나눔

- 나눈 태스크를 개발자별로 각각의 스프린트 백로그 (Sprint Backlog) 에 작성

 

3} 스프린트  Sprint

- 실제 개발 작업을 진행하는 과정

- 보통 2 ~ 4 주 정도의 기간내애 진행

- 스프린트 백로그에 있는 태스크 에 대한 속도 (Velocity) 를 추정하고 개발 담당자에게 태스크를 할당

- 속도 (Velocity) : 한번의 스프린트에서 한 팀이 감당 가능한 제품 백로그의 양 을 추정치로 나타낸거

- 할당된 태스크 는 보통 3 가지 상태를 가짐

• 할 일 (To Do)
• 진행 중 (In Progress)
• 완료 (Done)

 

4} 일일 스크럼 회의  Daily Scrum Meeting

- 매일 약속된 시간에 약 15분 정도로 진행 상황 점검

- 보통 서서 회의 진행

- 남은 작업 시간은 소멸 차트에 표시

- SM 은 발견된 장애 요소 해결을 도와줌

 

5} 스프린트 검토 회의  Sprint Review

- 부분 or 전체 완성 제품이 요구사항과 잘 부합되는지 테스트 함

- 스프린트의 1 주당 1 시간 내에 진행

- PO 는 피드백 정리 후 제품 백로그에 업데이트

 

6} 스프린트 회고  Sprint Retrospective

- 스프린트 주기 돌아보며 정해놓은 규칙 준수 잘 했는지, 개선할 점은 없는지 등을 확인 및 기록

- 해당 스프린트가 끝난 시점이나 일정 주기로 수행

 

 

 

3. XP 기법

- 애자일 모델 중 하나

- eXtreme Programming (XP) 기법

- 고객의 참여 & 개발 과정의 반복을 극대화 해서 개발 생산성을 향상 시킴

- 특징

• 짧고 반복적인 개발 주기
• 단순한 설계
• 고객의 적극적인 참여
• 빠르게 개발하는 것이 목적
• 릴리즈 기간을 짧게 반복  >  고객의 요구사항 잘 반영하고 있는 것을 보여줌
• (릴리즈 : 일부 요구사항이 적용되어 부분적으로 기능이 완료된 제폼을 제공하는 것)
• 소규모 인원의 개발 프로젝트에 효과적

- 핵심 가치 5 가지

1. 의사소통  (Communication)
2. 단순성  (Simplicity)
3. 용기  (Courage)
4. 존중  (Respect)
5. 피드백   (Feedback)

 

3 - 1) XP 개발 프로세스

XP 개발 프로세스

 

1} 사용자 스토리  User Story

- 고객의 요구사항을 간단한 시나리오로 표현한 거

- 내용 구성 : 기능 단위, 간단한 테스트 사항 (Test Case)

 

2} 릴리즈 계획 수립  Release Planning

- 부분 or 전체 개발 완료 시점에 대한 일정 수립

 

3} 스파이크  Spike

- 요구사항의 신뢰성을 높임 및 기술 문제의 리스크 감소 목적으로 만든 프로그램

 

4} 이터레이션  Iteration

- 하나의 릴리즈를 더 세분화 한 단위

- 1 ~ 3 주 정도 진행

- 이 기간 중 새로운 스토리 작성 가능

- 작성된 스토리는 진행 중인 이터레이션 or 다음 이터레이션에 포함 가능

 

5} 승인 검사  Acceptance Test, 인수 테스트

- 하나의 이터레이션 안에 계획된 릴리즈 단위의 부분 완료 제품을 테스트 함

- 사용자 스토리에 작성한 테스트 사항을 고객이 직접 수행

- 테스트 과정 중 생긴 오류 사항은 다음 이터레이션에 포함

- 테스트 이후 새로운 요구사항 작성 및 요구사항의 우선순위 변경 가능

- 테스트 완료되면 다음 이터레이션 진행

 

6} 소규모 릴리즈  Small Release

- 고객의 요구사항에 더 유연한 대응 가능

- 고객의 반응을 기능별로 확인 가능

- 이터레이션이 모두 완료되면 고객이 최종 테스트를 수행하고 최종 결과물을 고객에게 전달

- 릴리즈가 최종 완제품이 아니면 다음 릴리즈 일정에 맞게 개발 진행

 

 

7}  XP 주요 실천 방법 (Practice)

실천 방법	내용
Pair Programming (짝 프로그래밍)	다른 사람과 함께 프로그래밍 함으로써 개발에 대한 공동 책임을 나눠 갖는 환경을 조성함
Collective Ownership (공동 코드 소유)	개발 코드에 대한 권한과 책임을 공동으로 소유
Test-Driven Development (테스트 주도 개발)	개발자가 실제 코드를 작성하기 전 테스트 케이스를 먼저 작성해서 자신이 무엇을 해야할지 정확히 파악 테스트가 지속적으로 진행 가능하도록 자동화된 테스팅 도구 (구조, 프레임 워크)를 사용
Whole Team (전체 팀)	개발에 참여하는 모든 구성원 (고객 포함) 들은 각자의 역할이 있고 그에 대한 책임을 가짐
Continuous Integration (계속적인 통합)	모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합
Design Improvement (디자인 개선) or Refactoring (리팩토링)	프로그램 기능의 변경 없이, 단순화, 유연성 강화 등으로 시스템을 재구성
Small Releases (소규모 릴리즈)	릴리즈 기간을 짧게 반복해서 고객의 요구 변화에 신속히 대응

 

 

 

4. 현행 시스템 파악

- 시스템을 새로 개발하려면 개발 범위를 명확히 설정해야함

- 그래서 현행 시스템의 구성, 제공 기능, 시스템 간의 전달 정보, 사용되는 기술 요소, S/W, H/W, 네트워크의 구성등 파악함

- 절차

현행 시스템 파악 절차

 

1)  시스템 구성 파악

- 현행 시스템 구성 2 가지로 구분

• 조직의 주요 업무 담당하는 기간 업무
• 이를 지원하는 지원 업무

- 조직 내에 있는 모든 정보 시스템 현황 파악 가능하도록

- 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시함

 

2)  시스템 기능 파악

- 현행 시스템의 기능은 단위 업무 시스템이 현재 제공하는 기능들을

- 주요 기능, 하부 기능, 세부 기능으로 구분하여 계층형으로 표시

 

3)  시스템 인터페이스 파악

- 현행 시스템의 인터페이스에 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계유형, 주기 등을 명시

- 고려할 점

• 데이터를 어떤 형식으로 주고 받는지
• 통신규약은 무엇을 사용하는지
• 연계 유형은 무엇인지 등등

※  데이터 형식 : XML, 고정 포맷, 가변 포맷 등등

※  통신규약 : TCP/IP, X25 등등

※  연계 유형 : EAI, FEP 등등

 

4)  아키텍처 구성 파악

- 현행 시스템의 아키텍처 구성은 기간 업무 수행에 어떠한 기술 요소들이 사용되는지

- 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성

- 아키텍처가 단위 업무 시스템별로 다른 경우 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 표현

 

5)  S/W 구성 파악

- S/W 구성에는 단위 업무 시스템별로 업무 처리를 위해 설치된

- S/W 들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시

- 시스템 구축비용 면에서 S/W 비용이 많이 들어감

- 그래서 상용 S/W 의 경우 라이선스 적용 방식의 기준 및 보유한 라이선스의 파악이 중요

 

6)  H/W 구성 파악

- H/W 구성에는 단위 업무 시스템들이 운용되는 서버의 주요 사양, 수량, 이중화의 적용 여부를 명시

- 서버의 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요 여부가 결정됨

- (서버의 이중화 : 운용 서버 장애 시 대기 서버로 서비스를 계속 유지 가능하도록 관리하는 것)

- 현행 시스템에 이중화가 적용되면 새로 구성될 시스템도 이중화가 필요

- 이로 인한 비용 증가 및 시스템 구축 난이도 상승을 고려해야 함

 

7)  네트워크 구성 파악

- 네트워크 구성은 업무 시스템들의 네트워크 구성 파악이 가능하도록

- 서버의 위치, 서버 간의 네트워크 연결방식을 네트워크 구성도로 작성

- 네트워크 구성도로 서버들의 물리적인 위치 관계 파악, 보안 취약성 분석 및 대응 가능

- 네트워크에 장애가 발생한 경우 원인 파악 및 복구에 용이