공동응용설계
Joint application design![]() | 이 글은 실제 정보를 전달하지 않고 주관적으로 주제를 홍보하는 문구를 담고 있다.(2021년 11월) (이 를 과 시기 |
공동응용프로그램설계(JAD)는 기업의 새로운 정보시스템을 개발하면서 사업요건을 수집하기 위해 동적시스템개발방식(DSDM)의 라이프사이클 영역에서 사용되는 프로세스다."JAD 프로세스에는 사용자 참여 강화, 개발 가속화, 규격 품질 향상 등의 접근법도 포함되어 있다.""지식인력과 IT전문가가 때로는 며칠씩 만나 시스템의 비즈니스 요구사항을 정의하고 검토하는 워크숍"으로 구성된다.[1]참석자들은 제품이 마지막에 필요한 보고서와 정보를 제공하도록 보장할 고위 관리 공무원들을 포함한다.이는 "기업정보서비스(IS) 부서가 더 짧은 시간 내에 사용자와 보다 효과적으로 일할 수 있도록 하는 관리 프로세스"로 작용한다.[2]
JAD 워크샵을 통해 지식 근로자와 IT 전문가는 새로운 정보 시스템에 관한 양 당사자 간의 어려움이나 차이점을 해결할 수 있다.워크숍은 당사자 간의 모든 불확실성을 보장하고 의사소통을 잘못하지 않도록 돕기 위해 세부 안건을 따른다.의사소통의 오류는 그 과정에서 나중에 다루지 않으면 훨씬 더 심각한 영향을 미칠 수 있다.(주요 참가자와 효과적인 JAD를 위한 주요 단계는 아래를 참조하십시오.)결국, 이 과정은 설계자와 최종 사용자 모두에게 실현 가능하고 호소력 있는 새로운 정보 시스템을 초래할 것이다.
"JAD 디자인은 널리 호평을 받고 있지만, 실제로 그 효과에 대해서는 거의 알려져 있지 않다."Journal of Systems and Software에 따르면, JAD가 시스템 개발 결과에 어떤 영향을 미치는지 결정하기 위해 JAD 관행을 사용하는 3개 기관에서 현장 연구가 수행되었다.연구 결과는 조직들이 JAD 방법을 사용함으로써 시스템 개발 결과에서 다소 개선된 결과를 얻었음을 시사한다.JAD 사용은 작고 명확하게 초점을 맞춘 프로젝트에서 가장 효과적이었고 대규모 복합 프로젝트에서는 덜 효과적이었다.2010년부터 국제 촉진자 협회(IAF)는 촉진 워크샵인 la JAD의 중요성을 측정하여 상당한 가치를 찾아냈다.[3]
기원
공동응용이란 원래 1970년대 중반 뉴욕전화회사 시스템개발센터가 댄 지엘란의 지시로 개척하고 성공적으로 전개한 소프트웨어 개발 과정을 기술하기 위해 사용한 용어다.이 방법론의 일련의 놀랄 만큼 성공적인 구현에 이어, Gielan은 다양한 포럼에서 방법론, 이점 및 모범 사례에 대해 광범위하게 강의했다.당시 Saskatchewan의 Regina에 있는 IBM Canada의 수석 시스템 엔지니어였던 Arnie Lind는 1974년에 공동 애플리케이션 설계를 만들고 이름을 지었다.이는 애플리케이션 개발자가 특정 부서나 직무 기능의 세부사항을 학습한 후 기능 또는 부서에 대한 애플리케이션을 개발하는데 수개월을 소비해야 하는 기존 방법의 개선이었다.상당한 개발 지연 외에도, 이 프로세스는 애플리케이션 개발에 몇 년이 걸리고 애플리케이션 사용자가 완전히 수용하지 못하는 결과를 낳았다.
어니 린드의 생각은 간단했다: 애플리케이션 개발자들이 사람들의 직업에 대해 배우게 하기 보다는, 일을 하는 사람들에게 애플리케이션 쓰는 법을 가르치는 것이 어떨까?Arnie는 이 개념을 IBM Canada의 부사장 Carl Corcoran(나머지 IBM Canada의 사장)에게 던졌고, Carl은 시범 프로젝트를 승인했다.아니와 칼은 칼 코르코란이 아니 린드의 이니셜이 JAL(존 아놀드 린드)이라는 것을 깨닫고 공동 애플리케이션 물류라는 약자를 거부하자 공동 애플리케이션 설계의 약자인 방법론을 함께 JAD라고 명명했다.
그 시범사업은 서스캐처원 정부의 응급실 사업이었다.Arnie는 JAD 방법론을 개발하고, 주로 응급실의 간호사와 관리자들이 참여하는 1주일의 세미나를 준비했지만, 일부 애플리케이션 개발 인력도 포함시켰다.이 프로젝트는 1주일간의 세미나가 전통적인 애플리케이션 개발의 평균 18개월에 비해 1개월도 안 되는 기간에 코드화되고 구현되는 상세한 애플리케이션 프레임워크를 만들어냈기 때문에 큰 성공을 거두었다.그리고 사용자 자신이 시스템을 설계했기 때문에, 그들은 즉시 응용 프로그램을 채택하고 좋아했다.시범 프로젝트 이후 IBM은 JAD 방법론을 IBM 하드웨어에서 실행되는 컴퓨팅 애플리케이션을 보다 신속하게 구현할 수 있는 방법으로 보고 매우 지지했다.
어니 린드는 그 후 13년간 IBM 캐나다에서 JAD 방법론을 계속 개발하고, JAD 세미나를 전 세계를 여행하며 IBM 직원들에게 JAD의 방법과 기법을 교육했다.JAD는 IBM 캐나다 전역에서 광범위하게 수행되었고, 이 기술은 미국의 IBM에도 전파되었다.어니 린드는 토니 크로포드, 척 모리스 등 JAD를 공연하기 위해 IBM 캐나다에서 여러 사람을 훈련시켰다.어니 린드는 1987년 IBM에서 은퇴했으며, 캐나다, 미국, 아시아 전역에서 컨설팅 방식으로 JAD를 가르치고 공연했다.
JAD 과정은 1970년대 후반 IBM의 토니 크로포드와 척 모리스에 의해 공식화되었다.그 후 캐나다 국제 논문에 배치되었다.JAD는 미국으로 돌아가기 전에 잠시 동안 IBM 캐나다에서 사용되었다.처음에 IBM은 그들이 판매한 소프트웨어 프로그램인 코픽스(COPICS)를 판매하고 실행하기 위해 JAD를 이용했다.여러 용도(시스템 요건, 곡물 엘리베이터 설계, 문제 해결 등)에 폭넓게 적응했다.토니 크로포드는 이후 JAD-Plan을 개발했고 그 후 JAR(공동 적용 요건)을 개발했다.1985년에 Gary Rush는 JAD와 그 파생어인 FAST에 대해 Computerworld에서 썼다.[4]
원래, JAD는 다양한 배경과 의견을 가진 시스템 개발자와 사용자들을 생산적이고 창조적인 환경에서 함께 하도록 설계되었다.그 회의는 품질 요건과 규격을 얻기 위한 방법이었다.구조화된 접근방식은 시스템 분석가의 전통적인 직렬 인터뷰에 대한 좋은 대안을 제공한다.그 후 JAD는 비 IT 작업뿐만 아니라 더 광범위한 IT 작업(JAD 적용 가능성을 확장하기 위해 1985년 Gary Rush가 만든 촉진형 애플리케이션 사양 기법 - FAST에 대한 정보 읽기)을 포함하도록 확장되었다.[5]
주요 참여자
- 임원 스폰서
- 프로젝트를 차용하는 임원, 시스템 소유자.그들은 결정을 내리고 필요한 전략, 계획 및 방향을 제공할 수 있을 만큼 조직 내에서 충분히 높아야 한다.
- 주제별 전문가
- 이들은 성공적인 워크숍을 위해 필요한 비즈니스 사용자, IS 전문가, 외부 전문가들이다.이 그룹은 회의의 중추적인 역할을 한다. 그들은 변화를 주도할 것이다.
- 진행자/세션 리더
- 미팅을 하고 그룹을 미팅 의제로 유지하여 트래픽을 지시한다.촉진자는 회의의 일부로 해결할 수 있는 문제 및 후속 조사 및 해결을 위해 회의 종료 시 배정해야 할 문제를 파악할 책임이 있다.촉진자는 참가자에게 봉사하며 회의에 정보를 제공하지 않는다.
- 스크리브/모델러/레코더/문서 전문가
- 회의 진행 상황을 기록하고 공표하며, 회의에 정보를 제공하지 않는다.
- 감시자들
- 일반적으로 프로젝트에 할당된 애플리케이션 개발 팀의 구성원.그들은 참가자들 뒤에 앉아 조용히 절차를 관찰해야 한다.
9개의 주요 단계
- 프로젝트 목표 및 제한 사항 식별:워크숍과 프로젝트 전체에 대한 명확한 목표를 갖는 것은 필수적이다.사전 워크샵 활동인 기획과 범위 지정은 워크숍 스폰서와 참가자들의 기대를 모았다.범위 지정은 프로젝트의 범위에 포함되는 비즈니스 기능을 식별한다.또한 프로젝트 설계와 구현 복잡성을 모두 평가하려고 한다.프로젝트의 정치적 민감성을 평가해야 한다.이것은 과거에 시도된 적이 있는가?몇 번이나 잘못된 출발이 있었는가?구현 실패 횟수사이징은 중요하다.최상의 결과를 위해 시스템 프로젝트의 크기를 조정하여 전체 설계(화면 및 메뉴 바로 아래)가 8일에서 10일 이내에 설계될 수 있도록 해야 한다.
- 중요한 성공 요인 식별:개발 프로젝트와 연구 중인 비즈니스 기능 모두에 있어 중요한 성공 요인을 파악하는 것이 중요하다.계획된 변경이 효과적이었는지 어떻게 알 수 있을까?성공은 어떻게 측정될 것인가?결과 평가를 위한 계획은 전체 운영 수명 동안 구현된 시스템의 효과와 품질을 판단하는 데 도움이 된다.
- 프로젝트 결과물 정의:일반적으로 워크샵의 결과물은 문서와 설계다.작업장 문서의 형식과 세부사항 수준을 정의하는 것이 중요하다.어떤 종류의 도표가 제공될 것인가?어떤 종류의 서사가 제공될 것인가?처음부터 지원 다이어그램 작성에 CASE 도구를 사용하기 시작하는 것이 좋다.사용 가능한 도구의 대부분은 다이어그램 작성 능력이 우수하지만, 일반적으로 서술적 지원이 약하다.그 서술은 당신의 표준 워드 프로세싱 소프트웨어로 가장 잘 만들어진다.
- 작업장 활동 일정 정의:워크숍의 길이는 1일에서 5일까지 다양하다.프로젝트의 초기 워크샵은 3일 이상이어야 한다.참가자들의 역할, 서로, 그리고 환경에 익숙해지기 위해서는 첫날의 대부분을 필요로 한다.둘째 날은 서로 이해하는 법을 배우고, 문제와 관심사를 소통하는 공통의 언어를 개발하는 데 보낸다.셋째 날이면 모두가 함께 문제를 해결하고 진정한 생산성이 달성된다.초기 워크숍이 끝난 후, 팀 구성이 완료되었다.예를 들어 프로토타입을 검증하기 위해 프로젝트의 후속 단계에 대해 더 짧은 워크샵을 예약할 수 있다.다만 초기 워크숍의 팀 심리를 재정립하는 데는 1시간에서 3시간이 소요된다.
- 참가자를 선택하십시오.이들은 성공적인 워크숍을 위해 필요한 비즈니스 사용자, IT 전문가, 외부 전문가들이다.변화를 주도할 모임의 진정한 '뒷골'들이다.
- 작업장 자료 준비:워크샵에 앞서 프로젝트 매니저와 진행자가 분석을 수행하고 예비 디자인이나 밀짚맨을 구축하여 워크샵에 집중한다.워크숍 자료는 문서화, 워크시트, 다이어그램, 심지어 조사 대상 비즈니스 기능을 이해하는 데 도움이 되는 소품으로 구성된다.
- 작업장 활동 및 실습 구성:촉진자는 작업장의 최종 산출물을 지향하는 중간 산출물을 제공하는 작업장의 연습과 활동을 설계해야 한다.사전 워크샵 활동은 이러한 워크샵 연습을 설계하는 데 도움이 된다.예를 들어, Business Area Analysis의 경우 어떤 내용이 포함되어 있는가?분해도?높은 수준의 개체-관계도?정규화된 데이터 모델?상태 전환 다이어그램?종속성 다이어그램?위의 모든 것?위의 내용 중 아무것도?환경에 적합한 기술 다이어그램의 수준을 정의하는 것이 중요하다.다이어그램에서 가장 중요한 것은 사용자가 이해해야 한다는 것이다.다이어그램 선택이 이루어지면 촉진자 설계는 그룹이 해당 다이어그램을 개발하도록 하기 위해 워크샵 의제로 연습한다.워크샵은 서로에 대해 쌓기 위해 연속적으로 지향하는 연습과 평행한 연습을 각 하위 팀과 함께 문제의 한 부분을 작업하거나 다른 기능 영역에 대해 동일한 작업을 수행한다.촉진자가 주도하는 고강도 운동은 집단에 활력을 불어넣어 특정한 목표를 향해 나아가게 한다.저강도 연습은 결정 전에 상세한 논의를 할 수 있다.토론에는 전체 그룹 또는 팀이 문제를 해결하고 전체 그룹이 고려할 수 있는 제한된 수의 제안을 제시할 수 있다.참여자를 통합하기 위해 촉진자는 서로 다른 부서에서 유사한 전문지식을 가진 사람들을 매칭할 수 있다.참가자가 서로에게서 배울 수 있도록 촉진자는 전문지식을 혼합할 수 있다.워크숍의 조직적, 문화적, 정치적 목적을 달성하기 위해 하위팀 구성원을 혼합하고 일치시키는 것은 촉진자의 몫이다.워크숍은 기술 수준과 정치 수준 모두에서 운영된다.합의와 소통을 구축하고, 그 과정에서 이슈를 조기에 몰아내는 것이 촉진자의 일이다.근본적인 비즈니스 문제를 해결할 수 없다면 시스템의 기술적 구현에 대해 걱정할 필요가 없다.
- 작업장 참가자를 준비, 알림 및 교육:워크샵의 모든 참가자는 프로젝트의 목표와 제한사항 및 워크샵의 예상 결과물을 숙지해야 한다.참가자에 대한 브리핑은 워크숍 1~5일 전에 실시해야 한다.이 브리핑은 참가자들이 널리 분산되어 있는 경우 텔레컨퍼런스로 참조할 수 있다.브리핑 문서는 숙지 가이드, 브리핑 가이드, 프로젝트 범위 정의 또는 관리 정의 가이드 또는 기타 적절해 보이는 것으로 불릴 수 있다.8~12쪽 분량의 문서로 참가자들에게 프로젝트 범위에 대한 명확한 정의를 제공한다.브리핑 자체는 2시간에서 4시간 정도 진행된다.그것은 모든 사람들이 워크숍으로 나아가기 위해 필요한 심리적 준비를 제공한다.
- 작업장 물류 조정:작업장은 현장 밖에서 개최하여 방해를 피해야 한다.프로젝터, 스크린, PC, 테이블, 마커, 마스킹 테이프, 포스트 잇 노트 등 많은 소품을 준비해야 한다.구체적인 시설과 소품이 필요한 것은 촉진자의 몫이다.그것들은 단순한 플립차트에서 전자 화이트보드까지 다양하다.어쨌든, 방의 배치는 참가자들의 의사소통과 상호작용을 촉진해야 한다.
이점
- JAD는 요구사항 도출 프로세스와 관련된 시간과 비용을 절감한다.2-4주 동안 정보를 수집할 뿐만 아니라 다양한 시스템 사용자가 동의한 요건이 파악된다.JAD에 대한 경험을 통해 기업은 미션 크리티컬 작업의 방법론인 Double Helix와 같이 훨씬 더 동적인 방식으로 시스템 분석 프로세스를 사용자 정의할 수 있다.
- JAD 세션은 전문가들을 한자리에 모아 그들의 견해를 공유하고, 다른 사람들의 견해를 이해하고, 프로젝트 소유의식을 발전시킬 수 있는 기회를 제공하는데 도움을 준다.
- JAD 구현 방법은 "시중에서 최초로 사용할 수 있는 가속화된 설계 기법이며 아마도 가장 잘 알려져 있을 것"으로 어느 조직에서나 쉽게 적용할 수 있기 때문에 잘 알려져 있다.
- CASE 도구를 JAD 워크샵에 쉽게 통합하여 세션 생산성을 향상시키고 시스템 분석가에게 논의 및 사용 준비가 된 모델을 제공한다.
과제들
- JAD 세션을 위한 다각적인 준비가 없다면, 전문가들의 귀중한 시간은 쉽게 낭비될 수 있다.JAD 세션 주최자가 평가 대상 시스템의 요소를 연구하지 않을 경우, 잘못된 문제를 해결하고, 잘못된 사람을 초청하여 참여시킬 수 있으며, 부적절한 문제 해결 자원을 사용할 수 있다.
- JAD 워크숍 참가자는 문제의 관련 영역에 대한 대부분의 의견을 제공할 수 있는 직원을 포함해야 한다.참가자 선발 과정에서 각별한 주의가 필요한 이유다.이 그룹은 새로운 시스템과 상호 작용할 다양한 부서의 직원들뿐만 아니라 조직 사다리의 서로 다른 계층의 직원들로 구성되어야 한다.참가자의 관점이 상충될 수 있지만, 미팅을 통해 참가자는 다른 관점에서 문제를 볼 수 있다.JAD는 기본 프로세스에 대한 더 나은 이해와 함께 더 나은 모델 개요를 밝혀낸다.
- 촉진자는 가장 목소리가 큰 참가자뿐만 아니라 모든 참가자가 자신의 의견, 아이디어, 생각을 제시할 기회를 가질 수 있도록 해야 할 의무가 있다.
참조
- ^ Haag, Stephen; Cummings, Maeve; McCubbrey, Donald J. (2006). "Phase 2: Analysis". Information Management Systems for the Information Age. McGraw-Hill Ryerson. ISBN 978-0-07-281947-2.
- ^ Jennerich, Bill (November 1990). "Joint Application Design: Business Requirements Analysis for Successful Re-Engineering". Archived from the original on 2009-02-21. Retrieved 2009-02-06.
- ^ Rush, Gary (2013-06-06). "How Significant is the Value of Facilitation?". MGR Consulting. Retrieved 2021-11-22.]
- ^ 1985년 10월 7일 컴퓨터월드, 19권 40호, 깊이 페이지 ID/11에서 ID/16까지(47~52페이지)의 "시스템 요구 사항을 정의하는 FAST 방법"여기 성적증명서.
- ^ JAD FAST FoCuSeD™ 구조 촉진 기술[1]).
참고 문헌 목록
- Yatco, Mei C. (1999). "Joint Application Design/Development". University of Missouri-St. Louis. Retrieved 2009-02-06.
- Soltys, Roman; Anthony Crawford (1999). "JAD for business plans and designs". Archived from the original on 2009-03-13. Retrieved 2009-02-06.
- Dennis, Alan R.; Hayes, Glenda S.; Daniels, Robert M., Jr. (Spring 1999). "Business Process Modeling with Group Support Systems". Journal of Management Information Systems. 15 (4): 115–142. doi:10.1080/07421222.1999.11518224. Retrieved 2015-05-14.
- Botkin, John C. "Customer Involved Participation as Part of the Application Development Process". Archived from the original on 1998-12-01. Retrieved 1999-11-09.
{{cite web}}
:날짜 값 확인:accessdate=
(도움말) - Moeller, Walter E. "Facilitated Information Gathering Sessions: An Information Engineering Technique". Retrieved 2010-03-22.
- Bill Jennerich "Joint Application Design -- 성공적인 재엔지니어링을 위한 비즈니스 요구사항 분석." 18:50, 2006년 6월 26일 (UTC)[2] 마지막 업데이트 시간 알 수 없음.1999년 11월 14일 접속.
- 게리 러쉬 "JAD - 그것의 역사와 진화 - MGR 컨설팅 뉴스레터"2006년 7월 [3]
- 1984년 12월 24일, "JAD Project Aids Design," Computerworld, 제18권 52번, 페이지 31과 38, "JAD Project Aids Design"의 게리 러쉬.[4]
- Davidson, E.J (1999). "Joint application design (JAD) in practice". Journal of Systems and Software. Elsevier BV. 45 (3): 215–223. doi:10.1016/s0164-1212(98)10080-8. ISSN 0164-1212.
- Gottesdiener, Ellen; 협업별 요구사항: 정의 필요를 정의하기 위한 워크숍, 애디슨 웨슬리, 2002, ISBN 0-201-78606-0.
- Wood, Jane and Silver, Denise; John Wiley & Sons Inc., ISBN 0-471-04299-4