월간 인터넷에서 각 회사의 제품을 받는 데로
제공해주기로 했습니다. (이 점은 걱정이 필요 없을 듯)
즉 벤지마크 테스트 팀에 합류하실 분들에게는 이 제품들이
제공 된다는 것이죠. :)
일단 제품은 1월 초에 연속적으로 받기로 했습니다.
>
>그리고.. 이런 시험을 해볼려면..
>평가 항목과 기준을 설정해야 할테고..
>몸으로 때우는 일들이 있겠고..
>상당한 부담이 되는 일들이 있을텐데
>그리고 이런 시험에 대한 경험자들 조언도 들어볼 필요가 있겠고..
>만만치 않은 일이 될듯 한데
>진행 방식이나 절차 등에 대한 무슨 복안이라도 있나요?
>팀이 구성되는 것이 적절할 것 같은데..
>지원자 모집도 있어야 하지 않을까요?
>
제 생각에는 이번 일을 통해 다음과 같은 성과를 얻을 수 있을 것 같습니다.
1. 국내 인트라넷 제품 평가의 기본적인 기준, 또는 성능상의 기준점을
만들 수 있다는 점입니다. 이것만으로도 상당한 유의미성을 가질 수
있다고 생각합니다.
2. 만약 성능평가까지 이루어진다면 평가 방법론 또는 분석방법론에 대한
지침 또한 얻을 수 있다는 것이라고 생각합니다. 물론 이것이 한번에
완벽하게 잘되리라고는 생각하지 않습니다. 그 시발점을 만든다는 정도에
의미를 둔다면 이후에는 좋은 방법론이 나올 수 있으리라 생각합니다.
3. 국내 인트라넷 관련 Co-work의 출발점이 될 수 있다고 생각합니다.
물론 힘든일도 많으리라 생각됩니다. 설치, 분석등등 노가다 성향의 일들도
있을 테지만, 일의 범위를 축소하고 적절히 역활분담을 한다면
크게 부담되진 않으리라 생각합니다. 이번 일에서 해야 되는 일은 다음과 같이
우선 순위에 따라 구분될 수 있을 것 같습니다.
1. 설치 : 제품들을 모두 설치를 해야 되겠지요. 이것만 해도 상당한 협조가
필요할 부분이라 생각됩니다.
2. 분석기준 마련 : 지금 논의되는 분석 항목들과 기준들을 명확히 나누는
것이죠.
3. 분석 : 기준 항목들에 근거해 분석해 나가는 작업입니다. 물론 이 작업도
상당한 노력이 필요한 부분인 것 같습니다.
4. 성능 평가 방법론 마련 : 이 부분은 일단 공통분모를 찾아 '정형화' 시키는
것이
급선무라고 생각되는데요. 국내에 이런 방법론이 있는지도 미지수니까요..
5. 성능 평가 : 여기까지 되면 좋겠지만, 인력과 능력이 된다면 시도 해볼
수도 있다는
단서를 달고 시작해야 될 것 같습니다.
6. 향후 방향 제시 : 이것은 구체적은 아니더라도 마지막 결론 정도로
아이디어를 내는
정도로 마무리할 수 있다고 생각합니다.
7. 최종 원고 작성
이 정도 범위에서 논의해서 작업량과 범위를 결정해야 할 것 같습니다.
물론 선결되어야 하는 것은 팀을 확정해야 하는 것이죠. :)
(자원자는 두손,두발을 들어주시얍~ 오옷~ 김용운씨 안바뿌세요 ?)
뒷부분은 다른 분 의견을 더 들어보고 정리해서
제 의견을 다시 말씀드리도록 하죠. :)
>>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로 할 것이냐..
scalability는 제 생각에는 replication과 연관된 서버 분리성이
가능하는가라는 점에 촛점을 맞춘 것이었습니다. 말이 더 어려운가요 ? 히히~
>
>> . 응용 프로그램 호환성
>> . 지원 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)
>
>위에서 나열했던 항목들을 이 네 가지 범주로 구분하여 각 항목별
>평가를 하는 방식이 좋을듯 합니다. 안정성은 성능 부문에 넣으면
>될 듯 하고..
>
그럼 나중에 다시 이 네가지 범주로 구분해 보도록 하죠.
>-----
>
>근데.. 하긴 할 거예요?
>보통 일 아닐듯 한데......
>
예.. 모두 다 하는 것은 아닙니다. 유연성을 갖고 시작한다는 거죠.
언젠가 해야되는 일 아닌가요 ?