728x90
반응형
SMALL

PaaS 기반의 SW개발 방법론 대두 배경

예전에 소프트웨어를 개발할려면 C, C++ 와 같은 저수준 Language나 Power Builder, Visual-Vasic 같은
고수준 언어를 이용해서 개발하면서 프린터같은 HW 및 OS단까지 직접 제어를 하도록 코딩하는 경우
가 많았다.  하지만 오늘날에는 SW 개발 그 자체에 집중해 보다 민첩하고 완성도 높은 제품을 만들어내는
것이 중요하게 여겨지고 있다. 이에 따라 인프라와 미들웨어, 기타 개발지원도구들을 포함한 PaaS 형태의
SW 개발환경 서비스가 주목받고 있다. 

<출처 : 정보관리기술사 118회 동기모임 - 두드림 >

오늘날 기업의 모든 인프라와 IT 자원이 서비스로 옮겨가고 있다(Everyting as a Service).
처음에는 IT 자원을 공유하는 개념으로만 출발했지만 지금은 SaaS가 빠르게 발전하고 있다.
이는 SW개발환경 역시 마찬가지다. OS 위에서 컴파일러를 사용한 개발언어 중심으로 애플리케이션을
개발하던 1세대에 비해, 오늘날 5세대 SW개발환경은 클라우드 환경에서 제공되는 IaaS/PaaS를 활용해
HW를 직접 도입하거나 설정하지 않고도 SW를 개발하고 있다.
클라우드 기반의 SW개발환경은 기존에 비해 매우 높은 생산성을 가질 수 있다. 이는 HW를 구매하고
설치하는 시간, 개발을 위한 프레임워크나 운영서버 등을 구성하는 시간 등 개발환경 구성에 투입되는
상당한 시간들을 개발에 집중할 수 있기 때문이다. PaaS 기반의 SW개발환경을 사용하면 거의
대부분의 시간을 직접적인 SW개발에만 투자할 수 있다. 또한 개발환경을 안정적으로 운영하는
과정이 필요없어 최소한의 인력만으로 SW를 개발할 수 있으며, 비즈니스 성장 등에 따라 서비스를
민첩하고 탄력적으로 운영할 수 있다.
(발췌 : ITDaily : http://www.itdaily.kr/news/articleView.html?idxno=93897)


PaaS 기발 SW개발 사례

■"SW 개발-배포-운영까지 클라우드 기반으로"

삼성SDS는 약 10년전 삼성SDS는 국내와 해외를 포함해 6개의 데이터센터를 운영했지만 올해엔
국내외 15개 데이터센터를 운영하고 서버와 스토리지 네트워크 등 주요 인프라는 10배 이상으로 늘렸다.
윤심 클라우드사업부장(부사장)은 "삼성 SDS는 클라우드 환경을 감안해 앱 개발단계부터 배포, 운영까지
모두 클라우드 시스템을 이용토록 삼성SDS 플랫폼서비스(PaaS)를 개발했다"고 말했다. 덩치 큰 앱은
여러개의 모듈로 나눠 부품처럼 일부만 수정해 갱신하게 한다.
개발한 앱을 여러개 사업 현장에 배포할때도 클라우드에서 한번에 할 수 있도록 자동화했다.
개발팀이 수정한 앱은 운영팀이 즉시 공유할 수 있도록 '데브옵스(DevOps)'라는 개발·운영팀 공유도구도
제공한다.
(기사 : 파이낸셜뉴스 / "삼성SDS PaaS로 덩치 큰 앱도 부품처럼 일부만 수정")


PaaS 기반의 SW 개발 방법론 주요 구성요소

구분 구성요소 설명
PaaS laaS
(Infra as a Service)
서버, 스토리지, 네트워크 등의 인프라들을 가상화하여, 인프라
를 쉽게 사용할 수 있도록 서비스 형태로 구축해 놓은 시스템
PaaS Engine PaaS 핵심 기능이 동작하도록 지원
개발 플랫폼 CI/CD 등 Application 개발 환경을 제공함
SW
개발
방법론
SCRUM Product Backlog를 Sprint 단위로 분할 한 후 빠른 반복을 통하
여 개발하는 Agile 기법
- 구현 할 수 있는 최소 수준의 조건이 완성 되는대로 즉각적으로
고객의 피드백을 받는 방식
- 진척 관리를 위해 Burn Down Chart 등을 활용함.
DDD
(도메인 주도 개발)
기술 중심이 아닌 비즈니스 중심 언어를 사용하여 이해관계자
가 공통의 관점을 공유
MSA
(마이크로 서비스
아키텍처)
애플리케이션을 작고 독립된 서비스 단위로 개발/연계하여 전
체 시스템을 중단하지 않고 작은 서비스 단위로 빠르게 변경, 배
포, 대체, 확장
DevOps 개발과 운영, QA를 단일팀으로 구성하여 신속하게 개발 운영하
는 조직 구성 방안

                                  < 출처 : 정보관리기술사 118회 모임 : 두드림 >


PaaS 기반의 SW 개발 수행 절차

< 출처 : 정보관리기술사 118회 모임 : 두드림 >

 

728x90
반응형
LIST
728x90
반응형
SMALL

에자일(Agile) 개발방법론의 종류에는 여러가지가 있지만 그중에서도 XP와 SCRUM이 제일 많이 통용된다
두 방법은 어떤 잛은 주기의 개발기간과 개발내용을 반복적으로 수행하는 측면에서는 동일하다.

XP (Extreme Programming) 의 등장배경과 정의

개발을 하기위해 사용자로부터 요구사항을 듣고 분석및 설계의 바탕이 되는 요구사항을 정의해야 하는데
실제 요구사항의 분석이 쉽지는 않다. 또한 사용자 입자에서도 자기가 원하는 요구사항을 명확하게
생각해내서 제시하는 것 또한 어려운 상황이다. 어리다 보니 불필요한 다량의 문서작업으로 인해 개발자의
의욕을 저하시키게 된다.
그래서 사용자의 요구사항을 한꺼번에 받는 방식이 아닌 반복형 모델의 개발주기를 극단적으로 짧게
함으로써 프로그래머가 설계,구현,시험 활동을 전체 SW개발기간에 걸쳐 조금씩 자주 실시하도록 하는 
개발방법이 XP (Extreme Programming)  이다. 

XP (Extreme Programming) 의 특징

  ① 짧은 개발주기 반복
  프로토타입이 일찍 자주 만들어짐
  개발계획이 프로젝트 진행동안 계속 변화됨


XP (Extreme Programming) 의 4원칙

원칙 설명 12가지 기본원리
의사소통
(Communication)
고객과 개발자와의 의사소통을 중요시 User Story 카드
Pair Programming
On site Customer
단순성
(Simplicity)
지금 해야할 일에 대해서 가장 효율적인 디자인이나 코딩을 하는 것이 좋다. Simple Design
Metaphore
피드백
(Feedback)
즉각적인 피드백을 통해 빠른 의사결정
그래서 XP는 항상 코드가 실행가능한 상태유지
On Site Customer
Small Release
Test
Refactoring
용기
(Courage)
 - XP는 개발자들이 자신감있게 변화를 수용 할 수 있도록 그 환경
   을 만들어 준다
- Spike, Small Relase등으로 고객요구사항에 대응하는 용기
Small Release

 

 

XP (Extreme Programming) 의 12가지 기본원리

기본원리 설명
Planning Game 개발계획 수립
 - 고객과 다양한 스토리카드를 통한 개발계획 작성
Small Release 짧은 배포주기
 - 매우 짧은 주기로 모듈 업데이트
Metaphore 문장형태로 시스템 아키텍쳐 기술
공통의 Naming System 개발
고객과 개발자간 의사소통 언어
Pair Programming 개발자 2명이 공동 작업을 한다.
Collective Ownership 공동소유
 - 시스템에 존재하는 코드는 언제 누구든지 수정 가능
Continuous Integration 지속적인 통합
 - 작업이 끝날때마다 지속적으로 통합되고 동시에 테스트 된다
Simple Design 단순설계
 - 현재의 비즈니스 가치에 집중
 - 내일을 고려하는 디자인은 최대한 배제한다.
 - Refactoring 을 통해 개선
Test  - 항상 단위 테스트를 작성한다.
 - TFD (Test First Development) : 테스트 수행 후 검증코드로 작성해  나감
 - 실제 코드를 작성하기 전에 먼저 테스트를 작성해 봄으로써 자신이 무엇을 
   해야하는지 스스로 깨우칠 수 있다.
Refactoring  - 기능변화 없이 중복제거, 단순화, 유연성 추가
 1.Method 정의 - 지나치게 긴 Method 를 분리
                      - 지나치게  긴 문장을 Method를 사용하여 단순화
 2.위치이동 - Method난 변수 위치를 적절한 Class로 이동
 3.캡슐화 - 멤버변수를 Get/Set 사용하여 캡슐화
 4.조건문 단순화 - 긴 조건문을 분할하거나 method 화 하여 단순화
 5.이름변경 - 이해하기 쉬운 이름으로 변경
 6.Indentation - 가독성이 있는 Indent로 재포맷
주40시간 주40시간
On-Site Customer 고객상주
 - 프로젝트팀에 고객이 상주하여 즉각적인 의사소통과 피드백
 - 품질향상의 필수요소
Coding Standard 코드표준을 통한 효과적인 의사소통
 - 자신의 코드에 개발자의 이름, 연락처
 - 주석



SCRUM 

정의 짧은 개발주기에 반복적, 점진적 방법으로 개발  
역할 Scrum Team  - 일정 우선순위에 대한 권한 가짐
 - Product Backlog 에서 Sprint 기간만큼 가져와서 Spring Backlog로
   삼는다.
 - 4~5명 개발자
  Product Owner
(제품책임자/스폰서)
 - Product Backlog 관리
  Scrum Master Owner와 Team간의 의사소통
프로세스 회의 Sprint Planning Meeting 스프린트가 시작할 때 열림다.
회의는 하루종일
모두 참석
Daily Scrum Meeting 15 분 동안 서서
Spring Review Meeting
(with 고객)
 - 한달간의 스프린트를 마쳤을 때 잠재적
   으로 출시가능한 소프트웨어를 고객에
   게 Review 받는다.
 - 가능한한 비공식적
Sprint Retrospective Meeting
(with 팀)
Master와 팀원은 다음 단계에서 개선해야 할 사항 검토
즉흥적인 데모요청을 거부하고 기능구현항목의 동결을 보장받는 대신, 
납기내에 Sprint 목표달성


XP와 SCRUM 비교

  XP SCRUM
형태  - 엔지니어링 방법 초점
 - 프로그램 실천법에 집중
 - Framework는 미포함 (X)
 - 개발 프로세스를 위한 Framework
 - 관리및 조직적 실천법에 집중
 - 특정 엔지니어링 방법 미포함
개발주기 1~2 주 4~6주
변경사항수용 Refactoring을 통한 변경사항 수용
즉 요구사항 변경 발생 인정
Refactoring을 통한 변경사항 수용
즉 요구사항 변경 발생 인정
우선순위 결정 Customer Team
공통점 Agile 방법론으로 짧은 개발주기로 반복 개발




728x90
반응형
LIST
728x90
반응형
SMALL

에자일(Agile) 개발 방법론의 탄생 배경

보통 소프트웨어를 개발하는 과정을 보면 우선 사용자로부터 요구사항수집을 해서 분석을 하고
설계를 하고 개발하고 테스트를 해서 최종 Release 하는 방식으로 전통적인 방식이다.
일명 '폭포수(Waterfall)' 방식이라고 하는데  가장 많이 사용되는 개발방법이다.
이 전통적인 폭포수 개발 기법이 지닌 단점은 지나치게 계획과 절차에 의존한다는 것이다. 각 단계별로 
완료가 되어야 다음 단계로 넘어갈 수 있다. 물론 각 단계에 걸쳐 제어의 증가가 가능하지만, 이미 계획과
절차가 고정되어 있기 때문에 중간에 기능이나 프로세스의 변경사항이 발생하면 이를 반영하기가 어려운
개발방법론중에 하나다 . 즉 프로젝트가 이미 진행 중인 상황에서 프로젝트 범위가 변경될 때 유연성이 극히 떨어진다
또한 빈틈없는 계획과 단계별 엄격한 심사(Gate Review)를 중시하다 보면 당연히 시간과 비용의 낭비가 증가하게 된다.
하나의 오류가 발생하면 이를 해결하기 위해 이전 단계로 거슬러 올라가서 다시 내려와야 하기 때문에 납기일 준수가
쉽지 않게 된다.  소프트웨어 개발 업계에서 관행화된 납기일 지연과 반복되는 야근, 그리고 이에 따른 스트레스로 개발자들의 번아웃(Burn-out)이 빈번하게 발생하는 것도 이와 무관치 않다.
애자일 방식은 이런 단점을 개선할 수 있다는 기대를 받으며 1990년대에 처음 등장하였다.
대표적으로 Microsoft사의 익스플로러 개발에 적용을 해서 성공한 걸로 이름이 알려지기 시작했다. 
Microsoft사는 그 다시 웹브라우저 시장을 장악하고 있던 넷스케이프를 이기기 위해 Internet Explorer 개발
프로젝트를 가동했는데 이때 Agile 방식을 적용했다. 즉 전체 요구사항의 30% 정도 개발된 알파 버전을 공개했고
그 이후 feedback 을 수용해서 50% 정도 개발된 버전을 공개하였다.. 이런 식으로 feedback과 공개를 반복해가면서
프로젝트를 진행해.. 결국 대성공을 거두었다.

<폭포수 (Waterfall) 모델 >


에자일 (Agile) 의 정의

Agile 이란 단어의 뜻은 '민첩한' 이라는 뜻이다. 먼가 개발을 민첩하게 한다는 뜻이겠지요..
Agile 방법론이란 짧은 단위로 개발계획을 세워서 개발을 진행해서 Relase 한 후 고객의 Feedback을
받아서 바로 다음 개발계획에 적용나가는 Cycle을 반복함으로써 고객의 요구사항 변화에 신속하고
유연하게 대처할 수 있는 개발 방법론이다.
전통적인 폭포수(Waterfall) 모델은 개발이 다 끝나야 고객에게 시제품을 보여 줄수 있기 때문에
고객의 요구사항 변경에 대응을 바로 못하지만, 에자일(Agile)은 개발단위를 짧게 (보통 1~2주) 잡음
으로써 고객은 바로 시제품을 보고 feedback을 줄 수 있어서 변경사항을 반영하기가 수월하다. 
예를 들면.. 요리사가 레시피를 보고 그대로 요리를 한 후 손님에게 가져다 주는 방식이 폭포수모델
이라고 한다면, 에자일모델은 요리사가 요리를 하면서 중간중간 맛을 보면서 요리를 하는 방식이라고
할수있다.. (적절한 비유인가요?? ㅋㅋ)

< 에자일 (Agil) 모델 >


에자일(Agile)의 선언

  ① 프로세스/도구보다는  -> 개인과의 소통을 더 중요시
  ② 문서 보다는              -> 동작하는 S/W을 더 중요시
  ③ 계약/협상 보다는       -> 고객과의 협력을 더 중요시 
  ④ 계약준수 보다는        -> 변화에 대응을 더 중요시


에자일(Agile) 개발방법론의 특징

 ① Predictive 하기 보다는 Adaptive 한 방법론  (변화에 반응하는 것이 계획을 준수하는 것보다 우선함)  
 ② 프로세스 중심이 아닌 사람중심의 방법론  (개인간의 의사소통이 프로세스나 도구보다 우선함)
 ③ 동작하는 소프트웨어가 포괄적인 문서보다 우선함.
 ④ 고객과의 협력이 계약협상보다 우선함.


에자일(Agile) 개발방법론의 종류

종류 설명
XP (Exterem Programming) 4가지 가치와 12가지 실천항목. 
테스트강조,  1~3주 Iteration
User Stories, Spike, Test, Iteration
SCRUM 프로젝트를 Sprint 단위로 분리
팀은 매일 Scrum 미팅으로 계획수립 (15분)
DSDM Dynamic Systems Development Method
기능모델 , 설계와구현, 수행 3단계 사이클
영국만 사용
FDD Feature Driven Development
짧은 iteration (2주)
5단계 프로세스 반복


에자일(Agile) 개발방법론의 단점

에자일 방법론은 현재 대세로 자리 잡고 있는 개발방법론에는 틀림이 없다.
하지만 필드에서는 인식이 그렇게 좋은 편은 아니다.. '무한수정방법론' 이라고도 불리울 정도로
    자칫 고객의 요구사항을 계속 반영하다보면은 계속 수정을 할수밖에 없는 상황에 내몰리게 된다
    PM (Projecct Manager)가 적당한 선에서 요구사항을 짤를껀 짤라줘야 하는 , 즉 PM의 역할에 따라
    일의 양이 달라질 수 있다.
계획대로 짧은 주기의 작업이 완료될려면 팀원의 능력이 그 만큼 따라주어야 한다. 
    팀내 팀원들의 능력이 같이 않기 때문에 한 팀원의 performance  에 따라 전체 개발기간이 좌우
    될 수있다.. A 팀원의 능력이 1.5 이고 B팀원의 능력이 0.5  이면 전체 능력은 0.5에 맞춰질 수
    있기 때문이다  따라서 팀내의 역량이 부족하다 싶을때에는 매뉴얼화와 그것을 지속적으로 가르쳐줄 수
    있는 시스템이 우선되어야 한다. 그래서 충분히 역량을 발휘하기 좋은 시점이 올때 에자일방식 진행을
    시도하는것이 좋다. 

 

728x90
반응형
LIST

+ Recent posts