 |  |
|
난이도 : 초급 Gu Yi, Lead Software Engineer, IBM
2007 년 11 월 27 일 IBM Workplace Forms 변환 또는 개발 프로젝트를 위한 요구 사항을 모으는 방법을 배워봅시다. Workplace Forms의 기능을 살펴보고, 프로젝트 위험 요소에 대해 알아봅시다.
IBM Workplace Forms 프로젝트는 네 가지 유형으로 나뉜다:
-
변환/개발. 페이퍼 폼에서 Workplace Forms 전자 폼을 만들기.
-
향상. 마법사 페이지와 비즈니스 로직 등의 기능 구현하기.
-
프로세스 리엔지니어링. 특정 비즈니스 프로세스의 시작부터 끝까지 초점을 맞춤으로써 Workplace Forms 플랫폼의 가치를 높이기.
-
통합. 폼을 사전에 채우거나 다른 애플리케이션 시스템들과 정보를 공유하는데 사용되는 백엔드 시스템과 Workplace Forms를 통합하기.
이 글에서는 프로젝트의 첫 번째 유형인 요구 사항 수집 단계에 사용되는 방식을 설명한다. 변환과 개발이다. 이러한 유형의 프로젝트에는 일반적으로 많은 양의 폼들의 개발 또는 변환이 개입되기 때문에, 일반적인 개발 프로젝트와 차별화 시켜야 한다. 폼은 원래 포맷(Adobe PDF, Microsoft Word, Microsoft Excel, JetForm 등)에 기반하여 변환되거나 처음부터 새로 구현될 수 있다.
 | |
이 글의 목표는 여러분이 IBM Workplace Forms 변환/개발 프로젝트를 시작할 때 비즈니스 요구 사항을 이해 및 파악하고 조정할 수 있도록 하기 위함이다. IBM Workplace Forms에 대한 기본적인 지식이 있는 Workplace Forms 개발자와 프로젝트 매니저를 겨냥한 글이다.
Workplace Forms 변환/개발 프로젝트의 정황을 잘 이해하려면 다음 정보가 필요하다:
- 고객/사용자 정보
- 기능적 요구 사항
- 비 기능적 요구 사항
- 프로젝트 제약 조건과 문제
고객 및 사용자 정보
소셜 북마크
|
|
고객의 비즈니스를 이해하는 것은 요구 사항 수집 단계와 전체적인 프로세스 동안의 프로젝트를 이해할 수 있는 열쇠이다. 고객을 알고, 고객의 관점에서 프로젝트를 보고 생각할 수 있어야 한다.
고객 정보에는 Workplace Forms 프로젝트의 목표 사용자 베이스가 되는 고객, 비즈니스 라인, 부서와 관련된 모든 정보가 포함된다. 백그라운드 정보와 개발 사이클에서 결정을 해야 할 정보가 포함된다.
고객에 관한 정보
업계마다 다른 행동 패턴이 있다. 이 정보는 고객의 비즈니스를 이해하고, 프로젝트를 특정 패턴으로 매핑 시키는데 유용하다. 또한, 지식과 경험의 토대가 된다. 고객 정보에는 다음이 포함된다:
-
고객의 백그라운드.
이 회사는 어떤 회사인가?
규모는 어느 정도이며, 어디에 위치해 있는가?
업계에서 고객들의 인지도는 어떠한가?
이 회사의 대표적인 경쟁사는 어디인가?
이 회사는 비즈니스를 시작한 지 얼마나 되었는가?
공기업인가? 사기업인가? 비영리 회사인가?
이러한 정보가 Workplace Forms 프로젝트와는 직접적인 관련이 없을지라도, 이 회사에 대한 어느 정도의 통찰력과, 왜 Workplace Forms 애플리케이션을 구현해야 하는지를 알 수 있다.
대부분의 정보는 고객의 웹 사이트인 Hoovers 웹 사이트와 Google 검색을 통해 찾을 수 있다.
-
이 기술과 관련한 고객 팀의 백그라운드. 전형적인 조직적 구조를 넘어서, 고객의 팀에 익숙해지고, IBM Workplace Forms와 관련 기술에 대한 전문성 레벨을 이해하는 것이 좋다. 어떤 환경에서는, 고객의 팀은 이 기술에 대해 잘 모르기 프로젝트 팀이 고객에게 먼저 워크샵, 데모, 트레이닝을 제공해야 한다. 고객의 팀이 이 기술을 진정으로 이해한 후에야, Workplace Forms 개발 및 고객 팀은 협업할 수 있는 것이다.
프로젝트 목표
Workplace Forms 프로젝트는 새로운 기술을 구현하는 것 보다는 비즈니스 프로세스를 향상시키는데 초점이 맞춰져 있다.
이 프로젝트를 통해 고객이 달성하고자 하는 것과 이 프로젝트가 고객의 비즈니스를 어떻게 향상시킬 수 있는가를 이해하는 것이 중요하다. 사용자 데이터 엔트리 경험 향상인지, 데이터 무결성을 높이는 것인지, 페이퍼 폼을 줄이는 것인지, 프로세싱 시간을 최소화 하는 것인지..목표를 아는 것이 중요하다.
Workplace Forms 프로젝트에는 Straight Through Processing (STP)을 위해 데이터를 나타내고 교환하는 표준 방식이 포함되어 있다. 프론트엔드에서, 데이터가 캡쳐되고, IBM Workplace Forms Viewer 또는 IBM Workplace Forms Webform Server에서 유효성이 검사된다. 데이터는 XML 데이터 인스턴스로서 캡슐화 되는데, 백엔드 시스템에 의해 추출되거나 다른 시스템들과 교환될 수 있다. 데이터 인스턴스는 캡쳐된 데이터가 시스템으로 쉽고 완벽하게 통합될 수 있는지를 확인하는 기존 프로세스의 XML 스키마에 의해 정의된다. 폼 자체는 문서로서 취급되고 콘텐트 관리 시스템에 의해 관리된다. 고객이 이 같은 표준과 프로세스를 갖고 있지 않으면, Workplace Forms 프로젝트 팀은 고객이 이를 정의할 수 있도록 도와야 한다. 폼 자체는 비즈니스 프로세스 워크플로우의 컴포넌트가 된다. 결국, Workplace Forms 프로젝트는 고객이 비즈니스 프로세스를 향상시킬 수 있도록 돕는다.
고객인 이 폼들을 어떻게 사용할 것인가?
폼들이 사용되는 방식은 시스템과 기능적 디자인에 영향을 준다. 예를 들어, 사용자가 백엔드 서버로 폼을 제출하지 않으면, 어떤 데이터 인스턴스와 제출 메커니즘도 디자인에 포함될 필요가 없다. 결국, 전형적인 사용 패턴을 고려해야 한다:
-
Print and fill. 이 기본적인 패턴에서, 폼은 프린트 되고, 어떤 데이터 인스턴스나 UI 로직이 필요하지 않다. 폼은 원래 스팩과 거의 밀접하게 프린트 되어야 한다. 테스팅 대부분이 고객과 사용자가 사용하는 다양한 프린터 유형에 대한 프린트 테스트이다.
이 패턴은 레거시 시스템에 가장 자주 사용된다. 예를 들어, 회사가 채워진 페이퍼 폼을 스캔하고 optical character recognition (OCR)에 의해 폼에서 데이터를 추출할 수 있는 레거시 시스템을 갖고 있다고 해보자. 이 회사가 그 폼을 Workplace Forms로 마이그레이션 하기로 결정할 때, print-and-fill 패턴이 가장 적합하다. 회사는 계속 레거시 시스템을 활용할 수 있기 때문이다.
-
Fill and submit. 이 사용 패턴에서, 폼은 온라인으로 완성되고 백엔드 시스템에 제출된다. 주요 포커스는 사용자 인터페이스와 데이터 인스턴스에 있어야 한다. UI 엘리먼트는 대화식이어야 하며, 데이터 밸리데이션 같은 기본적인 기능이 실행되어야 한다. 또한, 데이터 인스턴스가 UI 엘리먼트와 백엔드 시스템으로 매핑되는 디자인 방식을 해결해야 한다.
-
Fill and print. 이것은 이전 두 개의 패턴들 대화식 폼과 프린트 사용의 결합이다.
누가 폼을 사용하는가?
폼을 누가 사용하는가는 전체적인 사용자 경험에 직접적인 영향을 미친다. 특정 유형의 사용자들은 특수한 사용자 경험 요구 사항을 갖고 있다. 사용자 프로파일을 이해하여 알맞은 인터페이스를 디자인 할 수 있어야 한다. 예를 들어, 다음과 같은 결정을 내려야 한다:
- 마법사 또는 전통적인 폼 데이터 엔트리?
- Split/breakdown 필드 또는 프리 데이터 텍스트 영역?
- 콘텍스트 중심의 도움말 텍스트 또는 전체적인 도움말 페이지?
기능적 요구 사항
기능적 요구 사항들은 폼 로직, 계산, 기술적 상세, 데이터 밸리데이션과 조작, 프로세싱 같은 시스템의 내부 작동을 정의한다. 기능적 요구 사항은 폼의 디자인과 구현에 있어서 기본적인 인풋이 된다.
이 섹션에서 기능이란 IBM Workplace Forms와 직접적으로 연관되어 있다. 각각의 기능은 디자인과 구현에 노력을 들여야 한다. 기존 기능들은 적은 노력이 드는 반면, 다른 것은 더 많은 개발과 테스팅이 필요하다. 기능적 요구 사항이 확실히 정의되지 않으면, 고객이 원하지 않는 것을 개발하게 될지도 모른다.
Workplace Forms 기능
고객/사용자가 요청하는 일반적인 기능을 표 1에 정리했다. 고객과 사용자와 함께 범위를 협상할 때 다음 정보를 활용해야 한다. 이 표의 우선 순위 컬럼을 사용하여 고객의 기능 우선 순위를 구분한다.
표 1. IBM Workplace Forms 기능
| 기능 | 설명 | 개발에 드는 노력 정도 |
|---|
| 마법사 페이지 | 마법사는 논리적 방식 및 제어된 방식으로 데이터 엔트리 프로세스를 통해 사용자를 안내하는 폼 페이지 스타일이다. 이러한 방식은 전통적인 스타일의 폼 페이지 보다 경험이 없는 사용자들이 사용하기에 더욱 편리하다. | Medium-high |
|---|
| XForms 데이터 인스턴스 | 데이터 인스턴스, 바인딩, 인스턴스에 대한 계산이 포함되어 있다. | Medium-high |
|---|
| 동적 테이블 | 동적인 테이블에서 사용자는 행(row)을 추가 및 삭제할 수 있다. | Medium |
|---|
| 멀티-URL 제출 | XForms 제출과 XFDL 제출이 포함되어 있다. 제출은 전체 폼, 전체 데이터 인스턴스 또는 데이터 인스턴스의 일부가 될 수 있다. URL은 정적이거나 또는 지원 애플리케이션을 통해 설정될 수 있다. | Low |
|---|
| 도움말 텍스트와 접근성 텍스트 | 사용자가 폼을 채우는 것을 돕는 폼 상의 각 아이템에 대한 도움말 및 접근성 텍스트이다. | Low |
|---|
| 데이터 밸리데이션 | 이 기능은 데이터 밸리데이션, 우편 번호, 이메일 주소, SSN, 또는 전화 번호를 핸들한다. 일반적으로, 폼 상의 데이터는 우편 번호 또는 이메일 주소 같은 특정 포맷을 갖고 있다. 공통 포맷 외에도, 스트링 또는 숫자 포맷은 폼 스트링 템플릿 또는 정규식으로 표현될 수 있다. 데이터는 특정 리스트 또는 값의 범위에 있는지 확인될 수 있다. | Low-medium |
|---|
| 전산 | 폼에 로직이나 계산을 더한다. 사용자는 이 전산에 공식과 디스크립션을 제공한다. 전산은 XFDL 전산이 되거나 XForms 바인드 계산이 될 수 있다. XForms 바인드는 XPath 식을 사용하여 계산을 실행한다. | Medium-high |
|---|
| 서명 | 서명은 두 개의 요구 사항 카테고리로 나뉜다. 디지털 서명과 수기 서명이 그것이다.
디지털 서명은 폼에 첨부되고 보안 설정에 기반하여 폼을 사용하는 사람을 구분한다. 다양한 유형의 디지털 서명에 대한 자세한 설명은 표 2를 참조하라.
하나의 폼에 여러 개의 중복되는 디지털 서명이 있을 수 있다.
수기 서명은 페이퍼 폼과 비슷한 폼에 적용될 수 있다. 인쇄된 폼 상의 젖은(wet) 서명을 통해 수행되거나, 서명 패드 또는 캡쳐된 서명을 IBM Workplace Forms와 통합하는 소프트웨어와 연결하여 Tablet PC를 사용한다. | Low-medium |
|---|
| 바코드 제너레이터 | 이 기능은 폼에 입력된 데이터 값을 바코드 포맷으로 변환하는 기능이다. Workplace Forms 확장으로 이를 완성할 수 있다. | Low |
|---|
| 기타 확장 | 코드가 제공하지 않은 추가 기능이 필요할 수도 있다. 이 기능은 사용자 개발 Workplace Forms 확장에서 제공될 수 있다. 폼을 프린팅 할 때 시리얼 넘버를 생성하는 것이 한 예이다. 개발 노력은 복잡성과 비례한다. | Medium-high |
|---|
표 2는 서명(Signature) 옵션에 대한 보다 구체적인 설명이다.
표 2. 서명 옵션
| 서명 유형 | 방식 | 설명 및 유스 케이스 시나리오 | 지원 인프라스트럭처 |
|---|
| 디지털 서명 | Clickwrap | Clickwrap 서명은 사용자가 전자 동의를 수락했다는 것에 대한 전자 증거를 얻을 수 있는 간단한 방식을 제공한다. 이러한 유형의 서명은 라이센스 동의에 일반적으로 사용된다. | 없음 |
|---|
| 디지털 서명 | Authenticated Clickwrap | Authenticated Clickwrap은 사용자가 폼에 안전하게 서명할 수 있도록 해준다. 사용자는 아이디와 비밀을 입력함으로써 폼에 서명한다. 폼이 서버로 보내지면, 서버는 사용자의 비밀 또는 패스워드를 데이터베이스로부터 받고, 그 비밀을 사용하여 서명을 확인한다. | 없음 |
|---|
| 디지털 서명 | Generic RSA (Microsoft CryptoAPI, Netscape certificates) | Generic RSA는 사용자의 컴퓨터에서 표준 RSA 디지털 인증서를 자동으로 검색한다. Microsoft CryptoAPI 또는Netscape 인증서가 될 수 있다. 이 폼은 디지털 인증서를 사용하여 서명이 되고 서버로 확인을 위해 제출된다. 앞선 두 개의 방식 보다 안전하다. | PKI 인프라스트럭처 |
|---|
| 디지털 서명 | Entrust signature | Entrust 서명을 사용하여 폼에 서명하고 확인할 수 있도록 하는 옵션이다. Entrust TruePass 기능으로 폼과 폼-프로세싱 애플리케이션들을 보안화 하는데 사용될 수도 있다. | Entrust 소프트웨어 |
|---|
| 수기 서명 | Signature pad | 사용자가 폼에 적용된 수기 서명을 만들 수 있다. 사용자가 수기 서명을 폼에 디스플레이 하고자 할 때 사용된다.
Workplace Forms Viewer는 대부분의 주요 벤더들의 서명 패드를 지원한다. | 서명 패드와 관련 소프트웨어 |
|---|
관련 소프트웨어의 경우, IBM Workplace Forms Catalog를 참조하라.
다른 시스템과의 통합
폼이 다른 시스템들과 통합되는지의 여부와 이들이 통합되는 방식을 이해하는 것이 중요하다. 예를 들어, 사용자가 폼에 데이터를 입력하고, 폼은 데이터를 백엔드 서블릿 또는 웹 서비스를 통해 제출한다. 폼은 다음과 같은 방법들로 통합될 수 있다:
- 폼 과/또는 데이터는 한 개 이상의 URL로 프로세싱을 위해 제출된다.
- 폼 과/또는 데이터는 웹 서비스 호출을 통해 제출된다.
- 폼은 문서 또는 콘텐트 관리 시스템으로 제출된다.
통합에 대한 자세한 내용은 IBM Redbook, Guide to Building and Integrating a Sample Workplace Forms Application을 참조하라.
오리지널 폼 포맷
오리지널 폼 포맷은 다음 중 하나가 될 수 있다:
- 이전 버전의 IBM Workplace Forms
- 자동화 변환 툴(Adobe PDF, Microsoft Word, Microsoft Excel, JetForm 등)에 의해 처리될 수 있는 전자 폼(E-form)
- 자동 변환 툴에 의해 처리될 수 없거나 오리지널 문서에서 잘 변환되지 않는 전자 폼(E-form)
- 스캔 이미지
- 이전 버전이 없음. 폼이 처음부터 완전히 새로 구현되어야 한다.
개발 프로세스와 타임 라인은 오리지널 폼 포맷과 자동화 변환 툴 또는 서비스의 사용에 크게 의존한다.
비 기능적 요구 사항
비 기능적 요구 사항은 시스템이 태스크를 얼마나 빨리 수행하는가 같은 기능 또는 태스크의 다양한 속성들에 대한 제약 조건이다. 이 섹션에서는 폼 프로젝트와 관련된 비 기능적 요구 사항들을 설명하겠다.
룩앤필
룩앤필(Look and feel)은 사용자가 인지하는 사용자 인터페이스의 그래픽 측면을 의미한다. 컬러, 크기, 폰트, 레이아웃, 버튼을 통한 사용자 인터랙션, 텍스트 편집, 기타 컨트롤이 포함된다. 프로젝트에 있어서 룩앤필은 중요하고, 고객은 언제나 매력적이고 편안한 인터페이스를 원한다. 또한, 사용자는 애플리케이션의 모든 폼들이 일관성 있는 룩앤필을 갖기를 원한다.
룩앤필에 대한 요구 사항을 모으는 단계는 다음과 같다:
- 고객에게 스타일 가이드를 갖고 있는지를 확인한다. 갖고 있지 않다면, 고객과 협의하여 컬러, 폰트, 아이콘, 네비게이션 스타일에 대한 선호도를 정한다. 어떤 경우, 고객은 특정 선호도가 없을 수 있으므로, 기존 폼 또는 룩앤필 예제용 다른 시스템 UI를 참조한다.
- 표준을 정의한다. (기존 표준을 활용한다.) 이러한 규칙들은 모호해서는 안된다. 정의에 설명적인 단어를 사용하지 말고, 테스트 및 확인될 수 있는 용어로 UI를 기술한다. 예:
- 데이터 엔트리 레이블은 Arial 10-포인트 폰트이다.
- Next 버튼의 오른쪽 가장자리는 오른쪽 여백 안에서 10픽셀이 되어야 한다.
- 단락 텍스트는 Arial 9-포인트 폰트로 맞춘다.
이 문서에는 1 단계에서 정의된 스타일 정보가 포함되어야 한다.
- 툴바용 포맷을 정의한다. 필요한 브랜딩이나 로고 정보와 필수 버튼들(Print, Save, Submit, 폼 네비게이션 버튼)을 포함시킨다.
- 데모 폼을 만들고 폼 소유자와 함께 (툴바를 포함하여) 데모를 검토한다. 반복적인 UI 개발은 폼의 소유자가 요구 사항을 결정하게끔 하는 가장 빠른 방법이다.
가용성
가용성은 폼의 UI에서 중요한 측면이다. Workplace Forms는 사용자 경험을 커스터마이징 할 수 있는 많은 방식들을 제공하여 데이터 엔트리와 폼의 사용을 가속화 한다. 가용성은 Workplace Forms에서 다음 영역으로 나뉜다:
-
마법사 스타일. 마법사 스타일 폼은 사용자에게 작은 섹션에 이해하기 알맞은 순서로 정보를 입력하도록 도모한다. 데이터 인스턴스를 사용하여 다른 섹션들에 섹션 콘텐트를 매핑하는 것과 마찬가지로, 디자인 동안 섹션의 콘텐트를 올바르게 정의한다. 이러한 방식은 여러 섹션들에 걸쳐 있는 데이터가 단 한번에 입력되도록 한다.
-
페이지 네비게이션. 하나의 폼은 가끔 여러 페이지들로 확장되고, 네비게이션 구조는 사용자를 페이지 순서대로 인도해야 한다. 일반적인 네비게이션 기술로는 Next와 Previous 버튼, 가용 페이지의 드롭다운 리스트, 탭 버튼이 있다.
-
에러 메시지와 도움말 팁. 디자인이 잘 된 폼이라면 도움말이 필요 없지만, 도움말 팁의 필요성을 간과해서는 안된다. 폼의 다양한 인풋 콘텐트와 포맷에 대한 정보를 제공한다.
-
지능적 인풋. 폼이 사용자가 입력한 것에 대응을 할 수 있다. 폼은 필요한 대로 아이템을 숨기거나 디스플레이 할 수 있고, 사용자의 인풋에 따라 자동으로 값을 계산할 수 있다. 이는 데이터 엔트리를 최소화 하고 사용자에게 필수 정보를 제공함으로써 가용성을 높인다.
성능
폼의 성능은 폼을 열고 저장하는 응답 시간으로 평가된다. 폼을 디자인 할 때 다음을 고려하라:
-
폼을 열 때 Workplace Forms Viewer의 반응 시간. 페이지와 아이템의 수와 전산 및 바인딩은 폼의 로딩 시간에 영향을 미친다. 엉성하게 디자인 된 폼은 로딩하는데 수초에서 수분이 걸릴 수 있다. 로딩 시간을 최소화 하려면, 다음 기술 팁을 사용하라:
- 불필요한 옵션을 제거하고, 인스턴스 태그들을 작게 유지하며, 이미지 크기를 줄임으로써 보다 작은 폼을 구현한다.
- 가능하다면 연산과 값 리스트 옵션을 재사용 한다.
- 압축 포맷으로 폼을 저장한다.
- 폼이 로딩될 때 활성화 되는 연산을 단순화 한다.
-
폼 연산 시 Workplace Forms Viewer의 반응 시간. 연산이 복잡하고 여러 필드와 데이터 인스턴스를 포함하고 있다면, 연산을 끝내는 데도 시간이 걸린다. 일반적으로, XForms 바인딩과 이벤트 모델을 사용하여 연산을 실행하면 XFDL 연산과 이벤트 모델을 사용하는 것 보다 더 나은 응답 시간을 보장 받는다. 또한, 가능할 경우 연산을 재사용 하라.
-
폼을 로딩하는 Webform Server의 반응 시간. Webform Server는 처음 열렸을 때 메모리로 폼을 로딩하고, 폼을 HTML로 변환한다. 따라서, 최초의 폼 오프닝(로딩) 시간은 페이지 변경/변환 시간 보다 훨씬 길다.
-
다른 페이지들을 검색하고 연산을 수행하는데 걸리는 Webform Server의 반응 시간. Webform Server는 페이지들 간 네비게이션 속도를 높이는 캐시 메커니즘을 갖고 있다.
-
폼을 프린트 하는 Webform Server의 반응 시간. 웹 폼을 프린트 할 때, Webform Server는 폼을 위한 PNG 이미지를 만들고, 이미지 파일을 브라우저로 다운로드 하여 프린트 한다. 응답 시간에는 이미지를 생성하는데 걸리는 시간과 이미지를 브라우저로 다운로드 하는데 걸리는 시간이 포함된다.
성능에 대한 벤치마크를 설정하는 것도 중요하다. 표준 환경과 허용 가능한 응답 시간은 비 기능적 요구 사항에 명시되어야 한다. 예를 들어, 다음과 같은 벤치마크를 설정한다: Windows PC, 3.0 G CPU, 1 GB 메모리에서 Workplace Forms Viewer에 5 MB 폼을 로딩할 때 5초 미만이 걸린다.
소프트웨어 환경
소프트웨어 환경은 폼 환경을 지원하는데 사용되는 소프트웨어를 의미한다. 다른 소프트웨어가 폼의 작동에 영향을 미친다. 표 3은 Workplace Forms Viewer와 Webform Server용 폼을 디자인 할 때 고려해야 하는 소프트웨어를 보여준다.
표 3. 소프트웨어 환경
| Workplace Forms Viewer | Workplace Forms Webform Server |
|---|
뷰어 버전
운영 체계와 버전
운영 체계의 로케일
Java Virtual Machine (Java IFX 지원에 필요함)
|
클라이언트 브라우저 버전
운영 체계 및 Webform Server 버전
Webform Server가 전개되는 J2EE 컨테이너 버전
|
|---|
하드웨어 환경
하드웨어 역시 폼의 성능과 가용성에 영향을 미치고, 프로젝트를 위해 특별한 개발 및 통합 노력이 필요하다. 폼을 디자인 할 때 다음 사항들을 고려해야 한다:
- 데스크탑 또는 랩탑 클라이언트 설정.
- 수기 서명을 위한 Tablet PC 지원.
- IBM WebSphere Everyplace Access 같은 IBM 제품이 있는 모바일 장치.
보안: 폼의 보안과 무결성
폼의 보안은 대부분 디지털 서명과 관련이 있다. 표 4는 IBM Workplace Forms의 다양한 보안 옵션들이다.
표 4. IBM Workplace Forms의 보안 옵션들
| 보안 옵션 | 설명 | 구현 고려 사항 |
|---|
| 디지털 서명 | 디지털 서명에 대한 자세한 내용은 "Workplace Forms 기능"을 참조하라. | 먼저, 서명의 유형과 얼마나 많은 서명이 필요한지를 결정한다. 그리고 나서, 서명이 확인되는 방법과 폼의 어떤 콘텐트에 어떤 서명을 쓸 지를 고려한다. 인증서가 배포되고 저장되는 방식을 고려한다. |
|---|
| 독자 보안 | 폼을 열고 폼을 읽을 수 있는 사람을 의미한다. | 이 옵션은 Workplace Forms 안 또는 밖에서 구현될 수 있다.
폼 안에서, 다이얼로그 박스가 열려서 사용자의 아이디와 패스워드를 인증하여 폼을 연다. 이것은 Workplace Forms Viewer 확장이나 Workplace Forms 자체를 통해 구현될 수 있다. 이 방식은 폼의 복잡성을 늘린다.
폼 밖에서, 폼 관리 시스템은 Workplace Forms의 액세스를 관리할 수 있다. 이것은 기존 콘텐트 관리 시스템이 재사용 되어 폼을 관리할 수 있으므로 이 방식을 권한다. |
|---|
| Webform Server 보안 | Webform Server와 웹 보안에 대한 액세스 컨트롤이 포함되어 있다. | Workplace Forms 제품은 사용자 인증 또는 보안 액세스 컨트롤을 지원하지 않는다. 폼의 인증을 구현하기 위해서, 커스터마이징 된 서블릿이나 포틀릿을 개발해야 한다. 웹 보안을 위해 HTTPS가 Webform Server에 전개될 수 있다. |
|---|
회사 정책 및 법적 문제
고객의 관점에서 볼 때, 모든 폼은 기업의 정책에 순응해야 하고 법적 문제가 없어야 한다. 따라서, 정책과 법적 문제에 대한 요구 사항을 문서화 하는 것이 중요하다.
프로젝트 관련 주제
이 섹션은 프로젝트 관리와 프로세스에 관한 것이다. 리스크(Risk), 재사용성, 관리 서비스, 폼 배포, 데이터 사전, 파일럿 단계를 설명한다.
리스크
다른 모든 프로젝트와 마찬가지로, 요구 사항 프로세스에서 불특정한 부분이 지연을 유발할 수 있다. 리스크는 기술적 관점과 비즈니스 관점에서 온다. Workplace Forms 서비스 프로젝트의 경우, 다음과 같은 고유의 리스크가 있다:
-
다중 쓰레드와 다이얼로그 박스로 복잡한 Workplace Forms Viewer 확장. Workplace Forms Viewer 확장은 기능을 폼에 추가하는 플러그인이다. C 또는 자바로 개발될 수 있다. 이 확장은 Workplace Forms API를 활용하고, Workplace Forms Viewer에 의해 통제되기 때문에, 복잡한 다이얼로그 박스를 개발하고, 복잡한 핸들링 메커니즘을 요하는 다중 쓰레드를 만든다는 것은 문제가 된다. 일반적으로 이러한 요구 사항은 개발 단계에서 추가의 노력이 든다. 확장 개발에 대한 자세한 정보는 Java API User’s Manual이나 API User’s Manual을 참조하라.
-
통합. 다른 시스템과의 통합은 늘 프로젝트의 위험 요소이다. 통합에 관여한 다양한 팀들은 데이터 교환 표준에 동의해야 하고, 통합 테스팅을 조정해야 한다. 프로젝트의 라이프 사이클 중 가능한 빠르게 시작되어 폼에서 재작업을 줄여야 한다.
-
개선. 고객이 이 폼들을 어떻게 사용하는지에 따라서, UI에 필요한 품질과 정밀도는 향후 개선에 영향을 미친다. 특히 UI 엘리먼트(폰트와 아이템 위치)의 스팩이 폼의 개발에 앞서 잘 정의되지 않을 때 더욱 그렇다. 모든 폼을 만들기 전에 폼 디자인과 개발 표준을 정리하는 것이 좋다. 또한, 픽셀 정밀도 프린팅 요구 사항들로 테스팅이 어려워 질 수 있다.
재사용성
폼에서, 일부 아이템들은 기존 폼의 컨트롤과 비슷할 수도 있고, 재사용 될 수도 있다. 이 개념은 아이템뿐만 아니라, 데이터 인스턴스, 바인딩, 계산, 확장까지 확대된다. 컴포넌트를 재사용 하면 상당한 개발 노력을 줄일 수 있다.
앞으로의 폼에 활용할 수 있는 재사용 가능한 폼 컴포넌트의 라이브러리를 만들어라. 재사용 가능한 컴포넌트로 개발 시간을 가속화 하고, 코드 베이스와 UI에서 일관성을 유지하라.
Workplace Forms에서 컴포넌트를 재사용 하려면, IBM Workplace Forms Designer의 Export Object 함수를 활용하여 객체를 재사용 가능한 아이템으로서 반출한다. 이러한 재사용 가능한 아이템들은 앞으로 사용할 수 있도록 Workplace Forms Designer 팔레트로 반입될 수 있다. Workplace Forms Designer는 리소스를 체크인/체크아웃 하여 ClearCase 플러그인이 설치된 상태에서 CVS 또는 IBM Rational ClearCase를 공유한다. 자세한 내용은 IBM Workplace Forms Designer 사용자 가이드를 참조하라.
관리 서비스
폼은 정적이거나(비용 리포트) 또는 매우 동적일 수 있다. (보험 양식). 결국, 폼 관리 서비스도 중요한 고려 대상이다. 폼이 릴리스 된 후에, 누가 폼을 업데이트 하고, 전개된 시스템에서 어떻게 폼을 업데이트 할 것인가?
폼의 관리에는 다음과 같은 것을 고려해야 한다:
- 수정된 폼이 그때그때 릴리스 되어야 하는가, 아니면 규칙적인 관리 릴리스가 스케줄링 되는가?
- 폼 수정에 대해 사용자 동의가 있어야 하는가? 그렇다면, 어떻게 통신하는가?
- 이전에 제출된 데이터가 보여야 하거나, 새로운 폼에서 사용되어야 하는가? 아니면, 이전 폼이 전개 시에도 남아있는가?
- 폼 버전 넘버를 추적해야 할 필요가 있는가?
- 법적인 이유로 인해 폼의 버전 관리가 되어야 하는가?
폼 배포
폼 배포란 사용자 베이스 내에서 폼이 패키징 되고 선적되는 방식을 의미한다. 표 5는 폼 배포에 사용되는 일반적인 방식이다.
표 5. 폼 배포
| 배포 방식 | 구현 노력 | 설명 |
|---|
| 이메일, FTP, 디스크, 웹 사이트 다운로드를 통해 폼을 배포한다. | 구현이 쉽다. | 이 방법은 분량이 큰 폼의 경우 관리가 어렵다. 사용자 에러를 만들기 쉽다. |
|---|
| 자가 추출 설치 파일 | 구현이 쉽다. | 이 방식은 분량이 큰 폼의 경우 관리가 어렵다. 사용자는 단 하나의 폼만 원할 수 있다. 사용자가 특정 폼을 쉽게 찾기 힘들다. |
|---|
| IBM DB2 Document Management 또는 IBM WebSphere Portal Document Manager 같은 문서 관리 시스템에서 폼 관리하기 | 폼 라이브러리 환경을 전개해야 한다. 고객에게 이미 있다면 쉽다. | 이 방식은 검색과 액세스 컨트롤에 사용하기 쉽다. |
|---|
파일럿 단계
가끔 고객들은 폼에 고급 기능을 필요로 한다. 아이템을 폼으로 드래그&드롭 하는 것으로 이러한 기능을 추가할 수 없다. 폼의 언어와 확장에 기반한 솔루션을 만드는 노력이 필요하다. 파일럿 폼을 구현하여 구현 및 기술이 예상대로 작동하는지를 확인한다. 기술이 요구 사항을 만족시키지 못하면, 고객 폼의 라이브러리용 고급 함수를 복사 및 구현하기 전에 솔루션을 구현한다.
데이터 사전
데이터 사전은 폼 상의 비즈니스 데이터에 대한 설명이고, 고급 기능이다. 데이터 사전은 일반 XML 스키마에 의해 통합되지 않은 관련 폼들(공통 데이터 엘리먼트들)이 있을 경우 필요하다.
표 6은 Workplace Forms 프로젝트에 사용되는 데이터 사전 정의 예제이다.
표 6. 데이터 사전 예제
| 이름 | 설명 | 유형 | 포맷 |
|---|
| Applicant | 보험에 가입한 사람 | Composite. Composed of name, birthday, zip code, address, country, state, telephone | |
|---|
| Applicant’s name | 가입자의 이름 | String | 1-50 characters |
|---|
| Applicant’s zip code | 가입자 주소의 우편 번호 | Number | US zip format |
|---|
| Applicant’s birthday | 가입자의 생일 | Date | MM/DD/YYYY |
|---|
데이터 사전에 있는 정보에 기반하여 XML 스키마가 추출되어 폼에서 XML 데이터 모델을 검사한다.
결론
이 글에서 IBM Workplace Forms 서비스 프로젝트에 필요한 요구 사항을 모으는 방법을 자세히 설명했다. Workplace Forms의 기능을 배우고 프로젝트 리스크에 대해서도 알아보았다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개  | |  | Gu Yi는 IBM China Development Lab의 IBM Software Services for Lotus (ISSL) Emerging Services Team의 소프트웨어 엔지니어 리더를 맡고 있다. 2005년부터 IBM Software Services 프로젝트에 참여하고 있으며, IBM Workplace Forms를 포함한 여러 서비스 프로젝트에 참여하고 있다. IBM WebSphere Portal 분야에서 2년 경력을 쌓았으며, J2EE 개발 분야에서는 4년 동안 경력을 쌓았다. |
기사에 대한 평가
|  |