2015년 8월 29일 토요일

[소프트웨어 프로세스 품질인증]

품질인증 기준 및 심사준비 가이드


1. 품질인증 기준

2. 심사 준비 가이드
   I. 소프트웨어프로세스 품질인증 제도
  II. 소프트웨어프로세스 품질인증 기준
 III. 소프트웨어프로세스 품질인증 심사
 IV. 소프트웨어프로세스 품질인증 획득

Summary
소프트웨어프로세스 품질인증 제도(이하 ‘프로세스 인증제도’라 한다.)는 소프트웨어 기업 및 개발조직의 소프트웨어프로세스(프로젝트 관리, 개 발, 지원, 조직 관리, 프로세스 개선) 품질역량 수준을 심사하여 등급을 판정하는 제도입니다.

프로세스 인증제도는 소프트웨어 및 정보시스템을 개발 관리하는 국내 소프트웨어 기업 및 개발조직의 소프트웨어프로세스 품질 향상과 신뢰성 확보를 목적으로 제정되었습니다. 소프트웨어프로세스 품질인증 제도는 소프트웨어프로세스 품질인증 기관(인증기관), 소프트웨어프로세스 품질인증 기준(인증기준), 소프트웨어 프로세스 품질인증 지침(인증지침)의 3가지 구성요소로 운영됩니다.


성공적인 유저 인터페이스 디자인을 위한 8가지 기본원칙

애플리케이션을 개발하고, 출시한 뒤에 시장 반응에 의해 실망해 본 경험은 누구나 있을 것 입니다. 마케팅에 시간과 돈을 많이 투자한다고 해서 볼품없고 헷갈리며 불친절한 유저 인터페이스가 극복되는 것은 아닙니다. 즉, 유저 인터페이스가 애플리케이션의 성패를 좌우합니다. 예를 들어, 모두가 애플과 같이 될 수는 없으나 가장 친절하고 매력적이며 눈길을 끌고 간단한 유저 인터페이스를 지향할 수는 있습니다. 유저 인터페이스의 성공적인 원칙은 다음과 같습니다.

유저 (User) 를 이해하라
만약 사용자를 설득하기 원한다면, 유저의 마음을 이해하는 것이 필요함. 즉,‘ 사용자는 누구인가’에서 시작해서‘유저는 무엇이 필요한지’를 생각한다면 거기에서부터 작업은 향상됨.

단순한 것이 아름답다
유저 인터페이스를 디자인할 때 단순함은 핵심임에 따라 유저 인터페이스에 화려함을 덧붙이기 전에‘ 이것이 필수적인가’또는‘이것이 인터페이스에 실질적으로 어떤 것을 덧붙여주는가’를 스스로에게 질문해야 함. 가장 좋은 유저 인터페이스 디자인은 가장 단순한 것임.

색 (Color) 을 현명하게 사용하라
색은 특히‘행동의 촉구’가 되도록 제작된 특별한 요소들로 관심을 이끄는 분명한 방법임. 빨간색이 좋은 예로, 빨간색은 행동의 색으로‘지금 다운로드’, ‘지금 플레이’, ‘여기를 클릭’에 주목할 것을 요구하나 빨간색은 또한 위험의 의미와 연관되어 있기 때문에 빨간색을 남용하면 안 됨.

일관성을 유지하라
당신의 유저를 안심시킬 수 있기 때문에 일관성은 필수적인 것임 . 폰트와 레이아웃에서부터 언어와 주제에 이르기까지 일관성은 모든 곳에서 요구됨.

처음 사용하는 유저를 도와줘라
처음 사용하는 유저를 사용안내 비디오테이프에 맡기거나 , 유저가 거의 방문하지 않는 헬프 데스크로 보내는 대신 , 유저를 안내할 수 있는 “ 온디멘드 (on demand)” 설명서를 첨부하는 것이 좋음 . 이러한 설명서는 GPS 나 관광가이드와 같은 역할을 하는 것으로써 , 앱의 핵심적인 특징들 사이로 유저를 호위하거나 유저가 임무를 완수하도록 도와줌.

유저의 성과를 인정하라
유저가 숙달되는 순간 , 인터페이스는 유저에게 보상하고 유저의 성과를 인정해야 함 . 더 이상 복잡한 과제에 실패하게 하지 말고 , 유저는 비교적 빨리 키보드를 손쉽게 사용하고 인터페이스의 복잡한 측면을 사용하는 것에 익숙해지도록 해야 함.

시험하고 반복하라
계속적으로 변하는 유저 인터페이스 때문에 유저를 멀어지게 만드는 것은 결코 바람직한 것이 아니지만 , 5 년 동안 똑같은 유저 인터페이스를 유지하는 것 역시 바람직하지 않기 때문에 경쟁자들이 앞서게 될 것임 . 모든 사람이 웹사이트의 특별한 디자인에 애착을 가질 수 있으나 , 그것들은 때때로 수정되고 업데이트되고 손질될 필요가 있음.

포기하지 말라 
유저 인터페이스 디자인은 예술이자 과학임 . 최고의 유저 인터페이스를 디자인하고자 할 때 모든 가변성과 더불어 문제들에 직면할 것임 . 첫 번째 , 두 번째 , 세 번째 그리고 아마 네 번째 장애물조차 걸려 넘어진다고 해서 , 이것이 프로젝트를 계속해서는 안 된다는 것을 의미하는 것은 아님.

Predicting Software Quality: SW 품질 예측 방법

품질은 SW 개발에 있어 탁월한 설계 , 사용용이성 , 속도 , 안정성 , 보안 , 정확성 등을 생각나게 하는 긍정적인 단어입니다 . 이러한 속성들 중 몇 가지는 측정가능하고 , 몇 가지는 주관적이라 할 수 있습니다 . 우리는 이러한 요소들을 통틀어 품질이라고 부릅니다 . 보편적인 이 관점에서 결함이 적을수록 높은 품질을 의미합니다 . 결함 /KLOC(kilo lines of code), 평균고장수명 (Mean time to failure) 과 같은 척도 (measure) 는 이러한 개념을 가지고 있습니다 . 유용한 척도의 결과 값이 좋으면 소프트웨어에 문제가 없다는 것을 나타내고 , 품질이 좋다고 이해합니다 .

용인되는 수준의 품질은 부수적인 결함들이 많다는 것을 의미하진 않습니다 . 중요한 것은 소프트웨어 패키지가 특색이 많고 , 많이 사용되어지고 , 적당한 가격을 가지는 것입니다 . 이것들로 판매자는 이익을 내고 시장 지배력을 가집니다 . 패키지를 사용하면서 사용자들이 부딪히는 문제들이 패키지를 사용하지 않는 것보다 낮은 수준일 때 , 제품의 품질을 용인되는 ( 받아들일 만한 ) 수준이라고 합니다 .

2015년 8월 28일 금요일

사용자경험 분석 시 범하기 쉬운 5가지 흔한 실수

애자일 소프트웨어 개발 방법론을 사용할 때, User Story를 사용해서 대부분의 요구사항을 수집합니다. User Story는 "의사소통 대상과 대상별 요구사항“의 간결한 형태와 수락기준으로 구성됩니다. User Story는 간결하지만 잘 작성하는 것이 무척 어려운 작업입니다. User Story 작성 시 흔히 범하는 5가지를 실수를 검토해봄으로써 올바른 User Story 작성법을 살펴보도록 합니다.

[5 가지 흔한 실수들]

1. 단일 사용자를 위한 User Story
  • 예 : “ 사용자로써 나는 광고를 관리할 수 있기 원한다 . 왜냐하면 기한이 만료되고 실수가 있는 광고를 제거할 수 있기 때문이다 .”
  • 언뜻 보면 모든 요소가 있어서 User Story 로 별 문제가 없어 보임
  • 특색에 맞게 사용자를 살펴보면 광고관리를 이해하고 수행하는 사용자는 광고 조정을 하는 포탈 관리자나 모든 광고 목록을 가지고 상황에 따라 광고들을 교체하는 광고주들을 뜻함
  • 페르소나나 역할을 놓치고 있음
2. 제품 소유자를 위한 User Story
  • 예 : “ 제품의 소유자로써 나는 광고를 지울 수 있는 시스템을 원한다 . 왜나하면 사용자들이 광고를 지울 수 있기 때문이다 .”
  • 모든 요소들이 있지만 뭔가 어색함
  • ‘ 당신이 무엇을 원한다 . 당신은 그것을 가지고 있다 ’ 는 형식으로 User Story 를 쓰는 사람이 단지 하고 싶은 행위에 초점을 두고 있으며 , 사용자 기대에 대한 단서를 주는 역할이나 페르소나가 없음
3. 개발자를 위한 User Story
  • 예 : “ 개발자로써 나는 폴더 위젯을 재배치하기를 원한다 . 왜냐하면 나는 폴더 위젯을 유지하고 싶기 때문이다 .”
  • 기술적인 백로그 (Technical backlog) 나 기술적인 요구사항의 대표하는 예임
  • 이와 같은 User Story 는 기술적 채무 (Technical Debt) 으로도 불리며 , 기술적 채무는 소프트웨어 업데이트 , 리팩토링 (Refactoring), 프레임웍의 교체와 같은 유지보수 관련 필수적인 일을 포함함
  • 고객을 위한 가치를 대변하지는 않고 , 애자일 관점에서 매 주기의 마지막에 비즈니스적 가치를 수반해함
  • 역할에 페르소나를 붙여 사용자관점에서 기술하는 예로 ‘ 상업적인 사용자로서 나는 동시에 여러 검색을 할 수 있는 시스템을 원한다 . 왜냐하면 나는 일을 좀 더 빨리 하고 싶기 때문이다 .’ 를 둘 수 있음
  • 수락기준들은 향상을 측정 가능하고 테스트 가능하도록 정의해야 함
  • 예 : ‘ 한 사용자가 동시에 5 가지 검색을 할 수 있음 ’
4. 고객을 위한 비즈니스 가치나 혜택이 없음
  • 예 : “ 상업 광고주로써 나는 필터링 옵션을 원한다 ”
  • 역할도 있고 니즈도 있지만 이유와 비즈니스 가치가 없음
5. 수락기준이나 만족조건이 없음
  • 수락기준이 없는 것은 개발업무를 잘못 정의하거나 잘못된 평가로 시작해서 전체를 오류덩어리로 만들 수 있음
  • 이해부족으로 Story 가 테스트를 통과하지 못할 수도 있고 Test Case 가 다른 기준들을 적용할 수도 있음
  • 수락기준은 요구사항을 명확하게 이해하고 주기별 결과물을 받아들일지는 결정하는 중요한 역할을 함
  • 수락기준을 만드는 좋은 방법은 '~ 한다면 어떻게 될까 ?(What if ... ?)', ' 어디서 (Where) ...?', ' 언제 (When) ... ?', ' 어떻게 (How) ... ?' 와 같은 질문을 해보는 것임
  • 예제들을 사용해서 가정들을 제거해서 간결하게 만들어보면 Story 가 세련되어지고 재구성되고 좀 더 작은 Story 로 나뉘어질 것임 

애자일 프로젝트 매니저가 갖춰야 할 3가지 필요기술

애자일 프로세스의 도입은 SW공학과 IT 프로젝트 측면에서 폭발적으로 늘고 있습니다. 애자일 프로젝트 매니저는 팀을 성공적으로 이끌기 위해서 애자일 기법들에 제대로 이해하고 사용해야 합니다. 사용자 경험 분석 등 요구사항분석을 통해 업무를 정의하고, Burn-down, Burn-up 차트 등을 이용하여 일의 진행사항을 체크하고, 용어의 통일이나 클라우드 컴퓨팅 등을 활용하여 팀 전체간의 의사소통을 원활하게 등 애자일 기법과 툴을 잘 활용해야 합니다.

*애자일 기본사항 (Agile fundamentals)
애자일 ALM 에서 프로젝트 매니저는 개발팀이 사용하고 있는 개발 프레임웍 (Scrum, XP, Kanban or 애자일 기법 조합 ) 에 대해 잘 이해하고 있어야 함.

추적 (Tracking) 과 척도 (Metric)
애자일 ALM 에서 프로젝트 매니저 훈련의 중요한 부분은 일의 진행사항을 추적하는데 사용되는 척도를 명확하게 이해하는 것임.

협업 (Collaboration)
애자일 기법들을 제대로 이해하고 진행상황을 올바로 측정하고 추적하는 것과 더불어 애자일 ALM 환경 상에서 프로젝트 매니저는 협업의 중요성을 잘 이해해야 함.

성공적인 요구사항관리를 위한 3가지 커뮤니케이션(협업) 유형

협업은 요구사항을 관리하는데 매우 중요한 요소입니다. 협업은 SW 개발자와 최종 사용자간의 협업, 고객 그룹들 사이의 협업, 회사 내부적인 협업의 3가지 형태가 있습니다. 이 3가지 형태의 협업을 잘 활용하여 요구사항을 효과적으로 관리하는 것은 경쟁력 있는 SW를 개발하는 데 도움이 됩니다.

◆ 세 가지 형태의 협업유형
  • 첫 번째 형태는 SW 개발자와 최종 사용자간의 대화임.
  • 두 번째 형태는 고객 그룹 사이에 활발하게 나타나는 의사소통임.
  • 세 번째 형태는 회사 내부적으로 발생하는 의사소통임.

2015년 8월 27일 목요일

소프트웨어 모델링

모델 존재의 이유
<문제와 답 사이의 디딤돌>
  • 문제와 연결성
  • 답과의 연결성
  • 모델 자체의 완전성 및 정확성



자세히 보기 →