2015년 9월 24일 목요일

성공적인 요구사항 관리를 위한 SW개발팀 간 4가지 협업전략

요구사항이라는 것은 애자일이건 아니건 상관없이 모든 소프트웨어 팀이 직면하게 되는 이슈입니다. 요구사항의 세목을 만드는 것은 많은 시간을 요구하기 때문에, 부적절한 결과를 초래할 수 있습니다. 즉 적절한 시기에 “적절한” 요구사항을 얻기 어렵기 때문에, 각 팀은 요구사항 프로세스를 향상시키기 위한 방법을 발견하기 위해 노력해야 합니다.  

요구사항 관리는 프로젝트의 방향을 결정짓는 매우 중요한 프로세스이나 요구사항 수집을 위한 왕도가 없음에 따라 개발팀 간 이해공유, 우선순위설정, 표준문서화 등을 통해 충분한 협업을 수행하는 방안 등이 중요합니다.

Ⅰ. 이해공유(Shared understanding)
Ⅱ. 우선순위설정(Prioritizing)
Ⅲ. 테스트를 포함한 코딩(Driving coding with tests)
Ⅳ. 요구사항 표준문서화(Documenting requirements)

자바스크립트(Javascript) UI Part 1 - 모듈 패턴

자바스크립트 유효범위의 문제
HTML5 나 웹앱 등 웹 기술로 만들어진 어플리케이션이 속속 등장하고 있습니다 . 이런 웹 어플리케이션을 구현하는 핵심기술은 자바스크립트이나 , 실제로 많은 개발자들은 자바스크립트의 특성을 잘 이해하지 못하여 생기는 문제가 많이 발생하고 있습니다 .
자바스크립트의 특성 중 아쉬운 점은 유효범위가 다소 혼란스러운 점입니다 . 특히 자바나 C 언어를 다루는 개발자가 자바스크립트를 접하게 되면 더욱 그렇게 느껴질 수 있습니다 . 예를 들어 자바스크립트는 블록 유효범위가 없으며 함수 유효범위가 있을 뿐입니다 . 이런 차이를 잘 이해하지 못해서 생기는 문제는 실제로 매우 많습니다 .
이런 특징은 결국 중요 함수나 변수가 공개된 영역 ( 자바스크립트에서는 이를 scope 이라고 표현 ) 으로 노출 된다는 점입니다 . 자바스크립트는 public 이나 private 과 같은 함수나 변수의 노출 범위를 명시적으로 표현 할 수 있는 키워드가 존재하지 않습니다 . 하지만 자바스크립트의 다양한 표현방법을 활용하여 이를 모듈화하면 어느 정도 보호 할 수가 있습니다 .
이러한 방법을 설명할 것이며 , 여기에 나와 있는 방식은 대부분의 실제 웹서비스나 자바스크립트 라이브러리 등에서 많이 사용되고 있는 방법들입니다 .
‘ 어떤 문제가 실제 발생하는 것인지 ?’, ‘ 어떻게 해결 할 수 있는지 ?’ 를 알아보겠습니다.

접근 제어를 위한 모듈화
실제 자바스크립트로 어떻게 구현되는지를 알기 위해서, 실제 코드를 살펴봅니다. 예제 코드에서는 ‘현재 사과의 개수를 확인하는 것’ 과 ‘현재 사과의 개수를 하나 증가’ 하는 함수를 간단히 구현합니다.

예제 1

예제 2

모듈의 재활용
모듈화 패턴은 재활용될 수가 있습니다. 예를 들어 위에서 나온 즉시실행함수에서 어떤 결과를 반환할 수도 있을 것입니다. 그 반환 값에 공개된 함수를 포함하면 되는 것입니다. 코드를 살펴보겠습니다.

예제 5

애자일 적용과 프로젝트를 실패하게 만드는 5가지 공통요인

신속하고 민첩한 개발을 위해 도입한 애자일 개발방법론이 오히려 프로젝트를 실패하게 만드는 경우가 있습니다. 애자일 방법론에 대한 반감은 변화에 대한 단순한 반응은 아닌 애자일을 형편없이 실행하는 조직에 대한 반응일 경우가 대부분임. 애자일 프로젝트는 알지 못하는 사이에 CEO, PM, 계획·교육관련 실수를 하는 사람들, 애자일과 관계없는 개발측면의 문제들로 인해 큰 어려움을 겪고 있습니다.    
이에 따라 애자일 전문가들이 지적하는 애자일의 도입과 실행에서 불거지는 공통적인 실패요인들에 대해 다음과 같이 살펴 도록 합니다.

Ⅰ. 명확한 이유 없이 애자일을 도입하는 경우
Ⅱ. 사업부와 개발부를 별도로 관리하는 경우
Ⅲ. 팀원에게 문화적 변화에 적응할 충분한 시간이 주어지지 않을 경우
Ⅳ. 전체적으로 불충분한 교육을 받게 되는 경우
Ⅴ. 애자일과 상관없는 실패를 애자일 탓으로 돌리는 경우

2015년 9월 23일 수요일

성공적인 프로젝트팀 구성을 위한 5가지 Tip

성공적인 SW프로젝트 수행을 위해서는 조직구성이 가장 중요한 요소임에 따라 효율적/효과적인 팀 운영을 위한 조직원의 규모, 전문성, 고용형태 등에 대한 유용한 의견을 제시합니다.

우선 제너럴리스트 ( Generalist) 를 배치하고 나중에 필요하면 스페셜리스트로 보충하기

제너럴리스트는 프로젝트 전반에 걸쳐 긍정적인 영향을 미침
  • 제너럴리스트는 프로젝트 전반에 도움을 주기 때문에 프로젝트 일정관리가 매우 용이함
  • 그러나 ! 팀원 전체를 제너럴리스트로 구성할 경우에는 프로젝트가 최상경로 (Critical Path) 에서 벗어나서 일정이 길어질 수 있을 수도 있기 때문에 주의를 해야 함

가능하면 스페셜리스트는 필요한 부분에만 활용하기
  • 스페셜리스트들은 전체적인 팀웍을 완성하기 보다는 본인 영역의 일만을 하고 그 외의 다른 일을 하기를 꺼려하는 경향이 일부 ! 있음
  • 스페셜리스트의 전문분야에 적합한 일이 주어지지 않은 경우에는 낭비되는 자원이 되기도 하는 등 전체 프로젝트 차원에서 예산낭비가 되기도 함
  • 이러한 상황 하에서는 리스크의 증가로 프로젝트가 실패할 수도 있고 전체 스케줄 관리가 힘들어지는 원인이 될 수 있음
Ⅰ. 제너럴리스트의 우선 배치
Ⅱ. 파트타임보다는 풀타임 팀원을 우선 고려
Ⅲ. 사공이 많으면 배가 산으로 간다
Ⅳ. 작은 교실이 더욱 좋다
Ⅴ. 허수아비 팀원을 과감히 제외 한다

모바일 보안 위협과 소프트웨어 관점의 보안 가이드

CT 기술이 발전되면서 사용자들이 요구하는 기능들은 점점 복잡해지고 구체화되고 있습니다. 또한 PC 기반의 기술에서 스마트폰 기반의 서비스가 많아지면서 사용자들의 ICT 의존도는 기하급수적으로 높아지고 있습니다. 또한 ICT 기술이 거의 모든 산업에 적용되면서 소프트웨어의 수요도 점차 늘어나고 있습니다.
소프트웨어의 수요가 많아질수록 그에 따른 보안 문제도 함께 많아지게 되는데, 최근에 사용률이 증가하고 있는 모바일의 경우는 보안 문제의 심각성이 더 크게 나타나고 있습니다. 최근 1년 동안 모바일 디바이스를 대상으로 한 보안 관련 조사에서 전체 모바일 기기의 68%가 악성 코드와 보안 위협에 노출되고 있는 것으로 나타났습니다. 특히 핀테크로 대변되는 모바일 결제 서비스의 위험이 가장 두드러지게 발생되고 있습니다.
모바일 디바이스는 PC보다 훨씬 더 많은 개인 정보를 가지고 있어 스마트폰 대중화 이후, 모바일 환경 속에서의 안전한 연결, 컨텐츠 보안, 모바일 디바이스 간의 보안이 확보된 호환 등에 많은 연구 개발이 이루어지고 있으며, 모바일 디바이스를 활용한 서비스 들에 대한 보안 연구도 활발히 진행되고 있습니다.
이번 회에서는 모바일에 대한 최근 보안 위협 트렌드와 소프트웨어 관점의 보안 가이드, 그리고 모바일 보안 구축 방법과 사례에 대해 살펴보기로 합니다.

보안 위협 트렌드

  • 디바이스 보안
  • 네트워크 보안
  • 플랫폼 보안

소프트웨어 관점의 모바일 보안 가이드

  • 소프트웨어 보안 취약점의 유형
  • 소프트웨어 보안 취약점의 점검

모바일 시스템의 보안 구축 방법과 사례

자세히 보기 →

2015년 9월 22일 화요일

SW 품질과 생산성 향상을 위한 개발 절차와 인증

우리가 매일 일상적으로 먹는 ‘밥’. 이 밥도 잘 지어 먹으려면 절차와 요건이 있습니다.
쌀을 사서(혹은 농사를 짓고, 수확한 후 찧어서), 여러 번 씻고, 물을 적당히 맞추고, 가열해서, 뜸을 잘 들여야ㅡ 비로소 맛있는 밥 한 그릇을 먹을 수 있는 것입니다.

이렇게 밥 한 그릇을 짓는 데에도 적절한 순서와 필수 요소들이 많음에도 불구하고,정작 훨씬 더 복잡하고 예민하게 진행되어야 할 소프트웨어 개발 현장에서 이러한 과정과 요건들이 제대로 갖춰지지 않은 경우가 많습니다. 그래서 등장하게 된 것이 바로 'SP품질인증제도'입니다. 소프트웨어 공학센터 SW품질인증팀의 정도균 수석을 만나 SP품질인증제도의 모든 것을 알아보았습니다.



SP품질 인증 체계도

















[SW공학 동영상6화] Engineering Process of Automotive SPICE

Introduction to Automotive SPICE / ISO 26262
  • Automotive SPICE v2.5
  • Automotive SPICE v3.0
  • ISO 26262 Overview
  • ISO 26262 Safety Lifecycle