브레인스토밍 회의
브레인스토밍은 여러 명으로부터 정보를 얻는 효과적인 방법입니다. 일반적으로는 그룹으로 테이블에 앉아 아이디어를 내는 목적으로 특정 토픽에 대하여 토론합니다. 하지만 인터뷰와 같이 브레인스토밍 과정에 체계를 더하면 더 많은 정보를 추출하는데 도움이 됩니다. 훈련된 요원이 주재하여 브레인스토밍 과정을 정돈하는 것이 성공하는 키 중의 하나입니다.
브레인스토밍 과정을 구성하고 효과적으로 수행하는 방법은 다음과 같다.
- 관련자 모두가 참여하는 회의를 소집한다. 효과적인 브레인스토밍 작업은 5명 내지 30명이 참여하여야 한다.
- 브레인스토밍 회의를 운영하고 리드할 수 있는 경험이 많은 사람을 회의 주재자로 선정한다. 주재자는 원할 경우 토의에 참여할 수도 있다.
- 테이블에 참석자를 배석시키고 작업할 종이를 많이 준다.
- 토론을 유도할 질문을 정한다. 이것이 중요한 작업이다. 유도 질문은 참석자들이 예, 아니오 식의 대답이 아닌 짧은 문장의 대답이 나올 수 있는 질문이 되어야 한다. 유도 질문은 회의를 소집한 사람, 주재자, 간단한 토론, 브레인스토밍 후 투표에 의하여 결정한다.
- 참여자에게 다음 지시에 따라 질문한다.
- A. 답이 쉽든지 어렵든지 유도 질문에 대하여 대답을 생각하게 한다.
- B. 종이 위에 답을 한두 줄로 적되 한 장에 하나의 아이디어만 적게 한다.
- C. 답을 적은 종이를 옆에 앉은 참석자에게 돌려 보아 생각해 보게 한다.
- D. 옆에 앉은 참석자가 적은 답을 보면 자신의 아이디어를 내는 데 자극이 된다.
- 5번 단계를 5~15분 정도 계속하되 아이디어가 더 이상 없을 때는 중단한다.
- 테이블을 주위를 돌아가면서 모두 앞에 있는 종이에 적힌 아이디어를 읽게 한다. 설명이 필요하면 원래 작성한 참석자가 간단히 부연 설명한다 (익명으로 한다면 설명하지 않을 수도 있음). 사회자 또는 간사가 아이디어를 칠판에 쓰고 그룹 전체가 간단히 토의할 수도 있다.
- 일정시간 동안이 지난 후 모든 아이디어를 칠판에 기록한 후 우선순위를 정하기 위하여 투표를 할 수도 있다. 예를 들면 모든 참석자가 가장 중요하다고 생각하는 답에 투표권을 준다.
브레인스토밍은 두 가지 장점을 가지고 있습니다. 먼저 그룹에 있는 참석자가 다른 사람의 아이디어에 자극 받아 열정을 가지고 많은 아이디어를 동시에 창안하려 노력하게 됩니다. 둘째로 위에서 설명한 바와 같이 익명성이 보장되어 내향적이고 소심한 사람들이 효과적으로 이야기할 수 있습니다. 이런 사람은 확신이 결여되어 자신의 아이디어가 좋지 않다고 생각한다.
JAD(Joint Application Development) 방법은 브레인스토밍과 관련됩니다. JAD에서 개발자는 고객과 사용자를 격리된 장소에서 사나흘 동안 만납니다. 회의 시간 대부분을 요구를 정의하기 위한 공동 작업에 할애한다. 정기적인 브레인스토밍과 문서화에 대한 협의 작업이 포함될 수도 있습니다. 참석자들은 하나의 그룹으로 작업할 수도 있고 특정 문제에 대하여 작업하는 여러 개의 작은 그룹으로 나눌 수도 있습니다. 최종 결과는 요구 문서로 작성되어야 합니다.
중요한 규칙은 참여자 어느 누구도 다른 업무로 중단하거나 방해받어서는 안 됩니다. 즉 JAD 회의는 학회나 수련회처럼 참석자가 근무하는 사무실이 아닌 다른 곳에서 이루어져야 합니다. 작업은 업무시간 뿐만 아니라 밤에 할 수도 있기 때문입니다.
JAD 회의를 집중적으로 한다면 수개월에서 수일에 걸친 요구 분석에 필요한기간을 단축할 수 있습니다.
프로토타이핑
프로토타입은 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램입니다. 프로토타이핑의 목적은 소프트웨어 엔지니어의 아이디어에 대한 피드백을 조기에 받아서 요구 사항을 취합하는 것입니다.
가장 단순한 프로토타입의 형태는 사용자 인터페이스를 종이에 그린 것입니다. 시스템이 수행될 때 무엇이 일어날지를 설명하기 위하여 고객과 사용자에 게 보이는 화면을 순서대로 그린 것이다. 아이디어를 추출하고 피드백을 받기에 적합하며 적은 노력으로 만들 수 있습니다. 종이 위에 그린 프로토타입은 만들기 쉬워서 여러 개를 병행하여 만들기에 적합합니다. 여러 개를 병행하여 만드는 것은 다수의 소프트웨어 엔지니어가 자신의 시스템에 대한 관점으로 별개의 프로토타입을 생성하는 것입니다. 그 결과들을 평가하고 그 중에 제일 좋은 기능을 시스템의 요구로 정합니다.
프로토타입으로 가장 흔한 것이 프로토타이핑 전용 언어 (rapid prototyping language)로 시스템의 모의(mock-up) 사용자 인터페이스를 만드는 것입니다.
래피드 프로토타이핑 언어는 사용자 인터페이스의 중요한 부분을 디스플레이 하기 위하여 신속하게 코드를 작성하게 합니다. 하지만 복잡한 시스템의 최종 버전을 생성하기 위하여 유익한 점을 제한하는 여러 가지 약점을 가지고 있습니다. 우선 비효율적이며 강인하고 융통성 있는 설계를 만드는 데 한계가 있습니다. 사용자는 프로토타입을 어느 정도까지는 실제와 같이 사용할 수 있다. 하지만 사용자 인터페이스 배후에 있는 여러 가지 사항, 즉 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가능하다. 프로토타입은 사용자로부터 피드백을 받아 계속 바꾸어야 한다. 하지만 아키텍처를 디자인하는데 노력할 필요는 없다. 설계한 것을 유지하기도 어렵고 버그가 많을 것이기 때문이 다. 프로토타입은 바로 최종 시스템으로 전환시키지 말고 요구를 취합하는 도 구로만 사용하는 것이 좋다.
사용자 인터페이스를 프로토 타이핑하는 것과 더불어 시스템의 다른 측면, 예를 들면 알고리즘이나 데이터베이스를 프로토타이핑 하기 위하여 사용하기도 한다. 모든 프로토타입은 현재 발굴된 아이디어를 시험하고 검증하며 새로운 아이디어를 창출하려는 목적으로 만든다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)