3. 결론적으로... 이러이러한 제품들에 대해 할테니 사든지
기증받든지 해서 넘겨달라. 그 다음에 일 시작하겠다
이렇게 되어야 하겠습니다.
그리고.. 이런 시험을 해볼려면..
평가 항목과 기준을 설정해야 할테고..
몸으로 때우는 일들이 있겠고..
상당한 부담이 되는 일들이 있을텐데
그리고 이런 시험에 대한 경험자들 조언도 들어볼 필요가 있겠고..
만만치 않은 일이 될듯 한데
진행 방식이나 절차 등에 대한 무슨 복안이라도 있나요?
팀이 구성되는 것이 적절할 것 같은데..
지원자 모집도 있어야 하지 않을까요?
>At 08:35 오전 96-12-30 +0900, joyjoon wrote:
>1. 분석할 제품의 종류와 범위
>
> - IntraWorks (다음커뮤니케이션)
> - CyberOffice (쌍용정보통신)
> - @Offfice (아이넷 기술)
> - Web Office (넥슨)
> - 워크플로.인트라넷 (나눔기술)
> - 핸디오피스 인트라 (핸드소프트)
> - 인트라X (장미디어)
> - 사무혁신탑 (기업전산원)
> - TeamWare (한국후지쯔)
> - DocsOpen (한국ISIS)
>
> 과 같이 포괄적인 것이 되어야 하지 않을까요 ?
> '인트라넷 제품'의 범주를 어느 선에서 해야할지도 결정되어야 할 것 같습니다.
> 즉 1) 인트라넷 구성에 도움을 주는 모든 어플리케이션
> 2) 웹을 중심으로 한 인트라넷 제품
> 3) 기타 웹상에서의 억세스를 지원하는 모든 어플리케이션
> 중에서 어느 범위로든 한정지어야 할 것 같다는 것입니다. 어느 범주가
> 좋은 것일까요 ? :) 제 생각에는 1번이 타당할 것 같은데요.
1번은 너무 넓은 범주라는 생각이 듭니다.
여기에 따르자면 Authoring Tools은 어떡하지요?
저는 위와 같은 분류보다는..
범주 구분 없이 주요 기능들에 대한 지원 여부를 O/X 식으로 표현하는 것은
어떨까 제안합니다. 즉,
- 게시판 기능
- 문서 등록/삭제 및 관리 기능
- 문서 결재 기능 (사용자별 접근 범위 설정)
- 전자우편 기능
- 진도 보고 기능
이런 식으로 주요 기능들에 대한 지원 여부가 표시되면
그것을 기반으로 제품 구입에 충분한 참고 자료가 될듯 합니다.
앞서 말씀하신 범주 구분은 구입하고자 하는 사람들에게
불필요한 정보 아닌가 생각합니다.
>>2. 분석의 기준이 되어야 할 것들
>>
>> . 안정성
>> . Response Time
응답 시간은 주요한 factor가 아닐 것 같습니다.
측정할려고 해도.. 배보다 배꼽이 더 큰 부담이 아닐까
생각들고요.. 로컬 랜이나 기업 내 네트워크에서는
응답 시간이 별로 문제되지 않을 겁니다. 밖으로 나간다
해도 전송 시간이 문제가 되지 응용 프로그램 처리 시간은
사용자 인식도에 별로 영향을 끼치지 않을 것이구요.
>> . Price
>> . Security
>
> Security 는 좀더 구분해야 하지 않을까요 ?
> . 사용자 Authentication 방법 (location ? USER ? Group ?
>Workgroup ?)
> . 사용자 권한 등급 종류
> . 사용자 억세스 등급 종류
보안 등급은 전자 결재 시스템이나 문서 관리 측면에서 중요하죠.
인사 기록 카드를 아무나 볼 수 있게 해서는 안 될 것이고..
고과 자료를 일반 사원이 맘대로 볼 수 있게 하는 것도 그렇고..
그런데.. 사용자 권한 등급은 곧바로 억세스 등급으로 표현되므로
구분할 필요는 없겠습니다. 물론 둘 다 별개로 처리해서 동작하게
만들 수도 있겠지만....
> . UI 및 사용의 편리성
> . 지원 가능한 DB
> . 멀티서버 지원 여부
> . MIS DB와 연동 여부
> . 지원 가능한 H/W Platform
> . 최대 사용자수
> . 동시 가능한 사용자수
> . 시스템 관리의 효율성
위에서 보면 평가자의 감성적 반응에 따라 결과가 전혀 달라질 수 있는
항목이 있네요. 예를 들어, 사용의 편리성이나.. 관리의 효율성 같은..
평가란 계량화의 작업이므로 직접 계량화가 가능한 항목으로 제한하는
것이 좋겠습니다.
> 보통 이런 경우 다음과 같은 내용도 추가 될 수 있을 것 같네요.
> . scalability
이건 의미 정의가 필요하겠습니다. 무엇을 scalability로 할 것이냐..
> . 응용 프로그램 호환성
> . 지원 HTTP 및 HTML spec
> . 지원 가능한 O/S Platform
> . Group messaging tool 지원 여부
> - White board
> - Conferencing (Audio, Video)
> - Scheduling (Private, Group)
> - Multipoint Authoring
> . Admin Tool
> . Workflow 지원 여부
> . Offline 문서의 지원 여부 (FMS, DMS 등)
> . SGML 지원 여부
> . 자바, ActiveX 지원 여부
> . 지원 Application Plugin의 종류
> . 사용자 API 지원 여부
>
> 더 추가 될 것이 많을 것 같은데요.
모르겠는데요. 키득키득...
>>3. 평가 방법론 들
>>
>
> 제 생각에는 일단은 크게 네가지 범주로 구분하는 것이 필요할 것 같습니다.
> 1) 관리 운영 측면
> 2) 일반 사용자 측면
> 3) 호환성 및 확장성
> 4) 성능(Performance)
위에서 나열했던 항목들을 이 네 가지 범주로 구분하여 각 항목별
평가를 하는 방식이 좋을듯 합니다. 안정성은 성능 부문에 넣으면
될 듯 하고..
-----
근데.. 하긴 할 거예요?
보통 일 아닐듯 한데......