소프트웨어공학 포털 블로그

2016년 6월 10일 금요일

DevOps는 무엇인가

DevOps

서비스나 제품의 릴리즈를 위해서 개발/운영/QA 활동 등이 서로 협업하여 장애없이 서비스나 어플리케이션을 빠르게 릴리즈 하는 방법

Agile, DevOps 뭐가 다른거야

소프트웨어 프로세스(Software Process, SP) 모델의 정의

소프트웨어 프로세스(이하 SP) 품질인증 제도는 소프트웨어 및 정보시스템을 개발 관리하는 국내 소프트웨어 기업 및 개발조직의 소프트웨어 프로세스 품질 향상과 신뢰성 확보를 목적으로 소프트 웨어 프로세스 품질역량 수준을 심사하여 등급을 판정하는 제도이다.

SP 품질인증은 소프트웨어 프로세스 품질인증 기준에 대한 만족여부를 심사를 통해 판단하여 부여 된다. SP 품질인증 기준은 5개 영역, 17개 평가항목, 76개 세부평가 항목으로 구성되었다. 5개의 영역을 구체적으로 살펴보면 프로젝트 관리 영역, 개발 영역, 지원영역, 조직관리 영역 및 프로세스 개선 영역으로 구성되어 있다.

프로젝트 관리 영역은 다시 프로젝트 계획, 프로젝트 통제, 협력업체 관리와 같은 3개의 평가항목 으로, 개발영역은 요구사항 관리, 분석, 설계, 구현 및 테스트가 포함되는 5개 평가항목으로, 지원 영역은 품질보증, 형상관리, 측정 및 분석과 같은 3개의 평가항목으로 구성되어 있으며 이들 3개의 영역이 2등급 영역이다. 3등급 영역인 조직 프로세스 관리는 기반구조 관리, 구성원 교육을 포함하는 2개의 평가항목으로 구성되고, 프로세스 개선 영역은 정량적 프로세스 관리, 문제해 결, 프로세스 개선 관리를 포함한 3개의 평가항목으로 구성되었다.

기존 SW공학수준 조사에서 프로세스 수준 분석은 CMMI 만을 기준으로 이루어졌기 때문에 SP 품 질인증에 대한 관심도 증가라는 상황과 맞물려 소프트웨어 프로세스 품질인증 기준에 따른 프로세 스 수준 분석의 필요성이 제기되었으며, 소프트웨어 프로세스 품질인증 기준에 따른 프로세스 수준 에 대한 데이터 확보가 필요하게 되었다.

이러한 필요성에 대응하고자 SP 품질인증 기준의 분석이 수행되었으며, SP 기준의 프로세스 수준 분석은 CMMI Level 3 수준에 맞는 2등급에 포함되는 3개 영역에 대하여 42개 세부평가항목을 기준으로 11개 평가항목에 대한 점수를 산정하여 분석하였다.

SW와 SW공학 - SW로 국가시스템 변혁

SW의 선도적 적용으로 공공서비스 질 제고

- 대국민 서비스 등 분야별 특성에 맞는 민간역량 활용 확대

* 과거 8년간 정보화 예산은 총 예산의 1%(3.3조원) 수준, 이중 50%가 유지관리

- 빅데이터 등을 활용한 과학적 국정운영* 확대(조기경보시스템 등)
* 예) 위키(Wiki) 방식(인터넷을 통해 시민의 참여와 협력 등 집단지성을 기반으로 문제 해결)으로 국정현안 해결 지원

‘정부’ - ‘SW산업’이 공생 발전하는 시스템 형성

- 공공 SW사업이 민간시장을 축소*하는 것을 사전 검증 평가하는 절차를 도입하는 ‘SW영향평 가제도’ 도입 방안 검토

* 개발된 SW의 무료배포, 기존 민간 서비스를 공공서비스로 제공하는 사례 등

- 불공정 발주관행(특정규격 명시 등)을 집중적으로 모니터링 개선 조치하고 상용SW 분리발주 제도의 실효성 강화 추진

- 공공SW사업 수 발주체계 개선(SW발주기술지원센터 설치 운영 등)

- 벤치마크테스트 SP인증* 등을 통한 품질향상으로 SW신뢰성 제고
* SW 프로세스 인증 : SW개발 방법 과정 등이 우수한 기업 인증제도

2016년 6월 9일 목요일

SW 유지보수 적용사례 – 적용 효과

• 개발 업무 진행상황의 가시성 향상
– 적용 전에는 개발자들이 무슨 일에 보틀넥이 걸려있으며 어떤 애로사항이 있는지 알기 어려워 팀장 입장에서 업무 진행 현황을 일일이 물어보아야 파악 할 수 있었는 데 지금은 타스크 보드와 데일리 미팅을 통하여 일일이 물어보 지 않아도 팀원들이 어떤 문제에 애로사항이 있으며 어떤 업무에 버틀넥이 있는지 쉽게 알개 되었고 당면한 문제 점들을 바로 바로 해결할 수 있게 되었다.

• 통합테스트 단계에서 발생하는 결함 감소
– 평균적으로 QA팀에서 개발팀으로 매달 8~9여건 정도의 크고 작은 재 작업 요청이 있었으나 애자일을 적용하고
나서부터는 1~2건 정도로 줄어든 상태이며 그나마도 마이너한 작업이 되어 품질이 많이 향상되었다. (70% 이상 감소)

• 개발과정의 효율성이 높아지고 생산성 향상
– 상호간의 협업 증대로 월별 처리건수 향상 (50% 이상 향상)

SW 개발에서 나타나는 전형적인 이슈와 문제점

1. 프로젝트 일정 및 태스크 공수 추정의 신뢰성 부족
• 전형적인 일정 및 공수 추정 형태
– 소수의 개발리더(전문가)를 중심으로 단독 추정
– 경영진및고객이제시한일정에WBS를끼워맞추는형태로일정개발

문제점
- – 리더가 본인이나 잘하는 사람을 기준으로 공수를 추정하다 보니 항상 프로
  젝트 공수가 부족
- – 개인의 편차가 심하며 공수 추정의 신뢰성이 떨어짐
- – 알려지지 않은(Unknown) 리스크를 고려한 일정 버퍼가 부족
애자일 해법
- – 전문가 집단 추정(Planning Poker ) 기법을 활용하여 평균 공수를 추정함으
  로써 추정의 신뢰성을 향상
- – 평균 공수 추정에 따른 일정 산정과 알려지지 않은(Unknown) 리스크를 고 려한 일정 버퍼 삽입

2. 업무 성과 및 품질 불량으로 관리자와 팀원 간의 갈등 발생

전형적인 갈등 상황
- – 팀원은리더의일방적지시에따라업무를진행하다보니해당업무에대한완 료 기준이 서로 상이함
- – 태스크초기일정미준수에따른비난이나질책이발생
- – 팀원이수행한태스크점검시결함이자주발생하는것에실망
애자일 해법
- – 스프린트계획시고객및리더,팀원이함께토론하여해당업무혹은요구사
  항에 대한 완료기준을 명확하게 설정함(Test Driven)
- – 리더는 태스크 일정 수행의 불확실성을 인식하고 태스크 장애요소 해결에 집중
- – 업무 수행에 대한 책임을 개인 책임보다는 팀 책임으로 설정하고
- – 완료조건에크로스및QA테스트검증포함

3. 수동적인 팀원들의 자세 및 낮은 사기

전형적인 상황
- – 업무계획시팀원의참여부족
- – 업무수행의타당성및명확한목표가부재
- – 대부분의 업무할당이 리더의 일방적 지시로 이루어짐
- – 리더의 업무 관여로 업무수행의 자율성이 부족
- – 유지보수 조직은 잘해야 본전
애자일 해법
- – 릴리즈 및 스프린트 계획 시 팀원들이 주도적으로 업무를 계획하게 유도
- – 스프린트 계획 시 사용자와 개발자가 업무수행의 타당성과 대안을 토론함
- – 팀원들이 본인들이 잘할 수 있는 업무태스크를 스스로 선택하고 업무를 진행(Self-organizing)
- – 팀원에게 업무수행의 자율성을 보장하고 리더는 문제해결에만 집중함
- – 팀원과 함께 스프린트 목표(정성적/정량적)를 설정하고 리더는 이에 대한 피드백을 주기적으로 제공
- – 주기적인 1:1 팀원 코칭

4. 프로젝트 및 팀 구성원들간의 소통 및 협력 부족

전형적인 상황
- – 리더와 팀원, 리더와 리더간의 업무소통은 활발하게 이루어지나 팀원과 팀원, 타 팀원간의 소통과 협력은 부족
- – 팀간에 발생하는 이슈 및 문제들이 리더들 미팅을 통해서만 해결됨
애자일 해법
- – 데일리 스탠드업 미팅, 스프린트 리뷰, 회고, 오픈 스페이스 미팅 등을 활용하여 팀원들간의 소통과 협력을 제고
- – 개인책임이아닌팀책임업무수행
- – 동료평가 및 절대평가를 통한 팀원간의 협력 증진

5. 요구사항의 불확실성과 잦은 변경

전형적인 상황
- – 고객 요구사항이 초기에 개략적으로 도출되며 제품 구현 후에 자주 변경됨
- – 요구사항의 불확실성으로 인하여 범위 베이스라인 설정과 변경통제가 어려움
애자일 해법
- – 주어진 일정과 비용 내에서 우선순위가 높은 기능 중심으로 개발
- – 사용자스토리중심의릴리즈계획과상세태스크중심의스프린트계획으로구분하여전체범위및일정관리
- – 요구사항에 대한 우선순위 관리와 스프린트 단위로 요구 변경을 통제함

6. 개발 산출물 및 업무 회의 과다

전형적인 상황
- – 고객사혹은내부표준프로세스준수에따른개발산출물과다발생
- – 고객이나 개발팀에게 의미 없는 산출물이 대량 발생
- – 수시로발생하는각종업무회의로인하여실제일은저녁에나가능
애자일 해법
- – 고객 및 개발팀에게 실질적으로 가치가 있는 산출물을 정의(유지보수에 필요한 산출물 중심)
- – 스프린트 회고를 통하여 불필요한 산출물과 회의를 지속적으로 제거
  (표준 프로세스는 준수해야 할 프로세스라기보다는 개선해야 할 프로세스로 인식)
- – 아침회의는 데일리 스탠드업 미팅 시 혹은 이후에 바로 수행함으로써 업무시간과 회의시간을 구분
- – 회의 방식을 Push 방식에서 Pull 방식으로 전환

7. 고객 및 사용자의 참여 부족

전형적인 상황
- – 현업이 바쁜 관계로 프로젝트 참여가 제한적이며 보통 분석 및 테스트단계에 주로 참여
- – 많은 경우 요구사항을 명확히 제시하지 못하며 개발자를 과신하는 경향이 있음
애자일 해법
- – 프로젝트 초기에 제품책임자들을 선정하고 이들로 하여금 사용자 의견을 수렴
- – 스프린트 단위로 사용자들의 피드백을 참조하여 개발
- – 제품책임자들은 스프린트 계획과 리뷰에 참여하여 개발자들과 개발기간 동안 밀접하게 소통해야 함
- – 고객과개발팀이활발하게소통할수있는프로젝트관리및커뮤니케이션도구제공

8. 진척상황의 불투명성 • 전형적인 상황
– 주간단위로 팀원들의 업무 진행상황을 점검하고 있으나 팀원들이 현재 어떤 업무에 어려움이 있고 도움이 필요한지 실시간으로 파악하기는 어려움
• 애자일 해법

– Visual Task Board를 활용하여 업무진행상황 및 이슈를 실시간으로 파악
– 데일리 스탠드업 미팅을 통하여 업무 진행현황과 장애요소, 이슈를 자연스럽게 파악하고 해결

Project Management 목표

2016년 6월 8일 수요일

[사전규격공개] GCS 3차과제 품질점검 및 컨설팅 지원용역(건설, 플랫폼 부문)

사전규격공개를 통한 의견을 수렴하오니 , 관련 있는 여러분의 소중한 의견 부탁드립니다 .

자세한 사항은 NIPA 전자계약시스템 로그인 후 입찰관리 - 제안요청서사전공개에서 확인하실 수 있습니다 .

* 사업명 : GCS 3 차과제 품질점검 및 컨설팅 지원용역 ( 건설 , 플랫폼 부문 )
* 공개기간 : 2016. 6. 12. 까지
* NIPA 전자계약시스템 바로가기 http://cont.nipa.kr

끝 .

피드 구독하기: 글 ( Atom )