Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

관점산출물AS-ISTO-BE시나리오예상 효과
standard-project
( root module )
전체 프로젝트 구조N/AMaven 표준에 의거한
Root 프로젝트 정보 제공
프로젝트 정보 스펙을 재사용하여
손쉽게 업데이트 및 재사용할
있도록 제공
Project Info
재사용 현실화
lib-module > pom
( library module )
통합 라이브러리 관리용N/ATSF에서 활용할
라이브러리 관리용 프로젝트
 하위 프로젝트에서 참조할
공통 라이브러리를 통합 관리하여
업데이트 및 재사용 하도록 제공
Project Lib
재사용 현실화
core-module > jar
( jsTree module )
jsTree Service Framework source code Jar ProjectN/ATSF + eGovframework 통합
소스코드 Core Jar 프로젝트
 전자정부 표준 프레임워크 기반한
확장된 Tree 서비스 프레임 코드를
제공하여 Object를 생성 및 사용
Core Project
재사용 현실화
web-module > war
( API module )
TSF를 활용한 Backend Api Server ( ROOT.war )

N/ATSF Jar 프로젝트를 활용한
PLE API 웹 어플리케이션 ( N )
 재사용 Core Project를 상속받아
빠르고, 일관된 형태의 API Server
프로젝트를 구성 및 재사용
재사용 프로젝트
활용 극대화
flex-module > flv
( Rich Module )
TSF Api Server를 활용한 Flex Client ( main.flv )N/ATSF API Server 프로젝트를 활용한
Flex Rich Internet Application
 Flex Rich Internet Application을
미리 구현한 구현체
Api Server 활용
클라이언트 다양화
mobile-module > apk
( Mobile App Module )
TSF Api Server를 활용한 Mobile Client ( Main.Apk )N/ATSF API Server 프로젝트를 활용한
Mobile Application
 Android Mobile Native Application을
미리 구현한 구현체
Api Server 활용
클라이언트 다양화

 

 

1.3 문서 규칙

...

프로젝트 결과물의 유형은 다음과 같다.
GitHub Source Code : https://github.com/jstree
Root-Module Pom File : http://www.313.co.kr/nexus/content/repositories/StandardProject/313devgrp/standard-project/
Lib-Module Pom File : http://www.313.co.kr/nexus/content/repositories/StandardProject/313devgrp/lib-module/
Core-Module Jar File : http://www.313.co.kr/nexus/content/repositories/StandardProject/313devgrp/core-module/
Web-Module War File : http://www.313.co.kr/nexus/content/repositories/StandardProject/313devgrp/web-module/
Docker Container File : https://hub.docker.com/r/313devgrp/jstree-service-framework-backend-app/tags/

...

결과물 명칭 : jsTree Service Framework
타겟 버전 : (년도 끝 두자리)XX.(월 끝 두자리)XX.주차 끝 한자리

산출물명대표버전형태위치비고
Root-Module : pom8.12.4프로젝트 정보를 내포하며, 하위 모듈 정보를 기록한 루트 모듈Nexus 
Lib-Module : pom8.12.4Core-Module에서 사용되는 각종 라이브러리를 관리하는 라이브러리 관리 모듈Nexus 
Core-Module : jar8.12.4전자정부프레임워크와 jsTree Service Framework 소스코드를 내포한 핵심 모듈Nexus 
Web-Module : war8.12.4Core-Module 을 활용한 API 서버 구성의 웹 모듈 ( 재사용을 극대화하는 대상 )VM : Tomcat 
Docker Container : File8.12.4각 모듈을 빌드한 결과물을 컨테이너에 포함하여 배포하는 가상화 이미지Docker Hub 

1.7.3 지적재산권

본 프로젝트는 MIT OpenSource License를 적용하였다.

2. 전체 설명

 

2.1 제품 및 서비스 조망

프로젝트 산출물의 전체적인 구성 및 동작, 기능 등에 대해 제품 기획자가 간략하게 서술한다. 본 프로젝트 산출물과 다른 313 DEV GRP 제품(또는 신규 제품)과의 관계 및 연관성, 위치에 대해 정보를 서술한다.

제품의 분류 정보 : "jsTree Service Framework는 Java Service Layer Framework 서비스 모듈이다"본 서비스를 사용하는 환경은 

 

제품조망은 다음과 같은 내용이 필요하다.

 

제품의 분류 정보. 예를 들어"XXXX는 안티바이러스 제품이다." 라거나, "XXX는 고성능 네트워크 침입 차단 제품으로 전용 어플라이언스에서 동작한다."와 같이 서술한다.

자세하지는 않아도 일반적인 제품 사용 환경 기술이 필요하다. 굳이 여기서 기술하지 않는다면 환경에서 상세한 내용을 제공한다.

 

 

 

jsTree Service Framework는 MVC 패턴을 활용하는 어플리케이션에서 서비스 코드를 작성시
확장된 트리 알고리즘을 확장하여 구현하게 하여, 빠르게 구현하고, 풍부한 기능을 제공하며, 일관된 구조로 개발하는 것을 목표로 하는
재사용이 극대화된 서비스 레이어 프레임워크로서,
Struts, Spring, iBatis, Hibernate, 등을 포괄하며, 퍼블릭 클라우드, 및 빅데이터 기술이 모두 구현된 프로젝트이다.

 

2.2 시스템 구성

 

프로젝트 산출물의 전체 시스템 구성도를 서술한다.

 

프로젝트 산출물이 단일 시스템에서 운영되는 경우, 운영체제 내에서 산출물의 위치, 운영체제와 다른 애플리케이션 간 관계도를 제시한다.
프로젝트 산출물이 분할 가능한 여러 개의 서브 시스템으로 분리되어 운영되는 경우, 각 서브 시스템 단위로 구성도를 제시한다.
프로젝트 산출물에 이 개발하지 않은 3'rd party의 제품(예, DB 프로그램, 웹서버 등)을 포함하여 전체 시스템 구성을 제시한다.

 

 

 

2.3 동작 방식

 

시스템 구성도를 기준으로 동작 원리 및 시나리오를 서술한다.

 

 

 

2.4 주요 기능

 

프로젝트의 산출물의 주요 기능을 사용자 관점에서 간략히 서술한다. 상세한 내용은 6장 제품 기능을 참고하도록 한다. 6장에서 기술되는 기능 명세 중 최상위 수준 기능을 열거하고, 간략히 기능을 서술한다.

...

기능

설명

NODE 구현 SPEC

1. 각 노드는 상위 노드(부모 노드)의 아이디 값을 가진다.

2. 각 노드는 형제 노드의 순서값 ( 좌측부터 0 )을 가진다.

3. 각 노드는 Left, Right 좌표값을 가진다.

4. 각 노드는 Root 노드부터의 Level 값을 가진다.

5. 각 노드는 Depth ( Level ) 값을 가진다.

6. 각 노드는 Leaf Node의 타입은 default이며, folder 타입은 branch 노드, Root node는 drive 타입으로 선언한다.

NODE 기능 SPEC

1. 노드(type : branch)를 추가할 수 있다.

2. 노드(type : leaf)을 추가할 수 있다.

3. 노드를 수정 할 수 있다. ( title, domain data )

4. 노드를 삭제 할 수 있다.

5. 노드를 잘라 낼 수 있다. ( Cut )

6. 노드를 복사 할 수 있다.

7. 노드를 붙일 수 있다. ( cut & paste , copy & paste )

8. 노드를 검색 할 수 있다.

API SPEC

1. getChildNode(T)  return List <T extends ComprehensiveTree>;

2. serchNode(T)  return <T extends ComprehensiveTree> List<String>;

3. addNode(T)  return <T extends ComprehensiveTree>;

4. removeNode(T)  return <T extends ComprehensiveTree>;

5. alterNode(T)  return <T extends ComprehensiveTree>;

6. alterNodeType(T)  return <T extends ComprehensiveTree>;

7. moveNode(T, HttpServletRequest request)  return <T extends ComprehensiveTree>;

8. getPaginatedChildNode return List <T extends ComprehensiveTree>;

9. analyzeNode return String;

 

 

2.5 사용자 프로파일

 

프로젝트 산출물의 사용자 특성을 기술한다. 제품 특성에 따라 다른 유형의 사용자가 있을 수 있다. 예를 들어 어플라이언스 기기는 장비의 모든 기능을 제어할 수 있는 관리자, 정보 조회만 허용된 관리자, 그리고 어플라이언스 기가가

 

기가가 제공하는 서비스를 이용하는 일반 사용자, 그리고 제품의 설치단계부터 관리자에게 사용권을 넘기기 전까지 모든 설치과 설정을 담당하는 네트워크 엔지니어로 유형을 나눌 수 있다.

 

사용자 프로파일은 사용자의 사용 환경, 사용 빈도, 제품에서 주로 사용하는 기능, 제품과 IT 지식 수준 등을 포함해야 한다.

 

 

 

2.5.1 예시) 프로파일1: PC사용자

 

V3IS 의 주요 사용자는 Windows 시스템의 관리자 권한을 갖는 사용자들이다.

 

  • 이들은 시스템 전체 제어 권한이 있지만, 안전한 PC의 사용방법은 잘 모른다.
  • 스스로 V3 IS 를 설치할 수도 있지만, 안전한 PC의 사용방법은 잘 모른다.,
  • 안티바이러스 제품은 필요하지만 불편하다고 생각한다.
  • 주로 사용하는 기능들
    • 검사 기능 : 전체검사 & 빠른검사 기능
    • 실시간검사 : 시스템을 느리고 만든다고 믿고 끄는 경우가 많다.
  • 잘 사용하지 않는 기능들PC가 감염된 후에야 제품을 사용하는 경우가 많다.
    • 네트워크 보안 기능들
    • 파일 완전 삭제
    • 업데이트 설정

...

2.5.2 예시) 프로파일2 : 소규모 조직 보안 관리자

 

소규모 조직은 구성원의 역할 분담이 명확하지 않아 다른 업무와 병행해서 관리 책임을 지는 관리자가 주요 사용자가 된다. 보안에 대한 전문 지식을 갖추지 못했기 때문에 관리포인트를 줄이고, 문제가 발생한 PC/서버의 장애, 보안 사고를 처리하고 싶어한다.

 

  • DB,서버 등 다른 시스템을 관리하는 경우가 많다.
  • 개발 업무와 겸직하는 경우도 많다.
  • 투입할 수 있는 예산이 많지 않아 올인원 솔루션을 원한다.
  • 보안 전문 지식이 많지 않다.
  • 주로 사용하는 기능들
    • APC에 의한 원격 설치, 정책 적용 기능
    • 주요 시스템 모니터 기능

...

2.5.3 예시) 프로파일3: TrusGuard SSL VPN 원격 사용자

 

다른 업체에 파견 근무하거나, 컨설팅 등을 수행하는 사용자들

 

 

 

2.6 설계와 구현상 제약 조건

 

프로젝트에 따른 개발 과정에서 고려할 기술적인 제약 조건을 서술한다. 하드웨어 상의 제약조건은 하드웨어 환경에서 기술한다. 프로젝트 산출물 설치에 필요한 애플리케이션, 라이브러리 파일은 소프트웨어 환경에 서술한다.

 

  • 반드시 사용해야 할 기술
  • 사용하지 말아야 할 기술
  • 설계 도구
  • 개발 도구
  • 개발 언어
  • 데이터베이스
  • 준수해야할 개발 규칙(프로그래밍 가이드, 오류코드 가이드)

...

Part

Detail Skill

View Part

html+css, Bootstrap, RequireJS, Bower, Grunt, AngularJS, jQuery, Qunit, Flex, Json, xml, BlazeDS

Server Part

Apache(modjk), ApiGateway(Zulu), Kafka, Nginx, Tomcat, Resin, Jetty, SiteMash, Tiles, FreeMarker, Velocity

Framework Part

Struts, Spring, iBatis, Hibernate, Spring-integration, Spring-security, Spring-Boot, Spring-DW, Spring-WebFlow, Spring-Data(JPA), Spring-Batch, Spring-WebServices, Spring-Mobile, Spring-MVC

Tool Part

Quartz, Ehcache, MemCache, Redis, Apache-Commons, EgovFramework(Component)

CI Part

Junit, Maven, Hudson, Jenkins, Bamboo, Nexus, Jira, Fisheye, Crucible, Confluence, Sonar

Database Part

MySql, Oracle, MS-sql, postgres, Hadoop, Storm, Spark, Cassandra, MongoDB, GraphDB

Mobile Part

Android, PhoneGap

Search Engine Part

Lucene, Elastic Search, Kibana, Logstash, Beats

Management Part

PMBOK, MicroService, CBD, PLE, Prototype, PMS, ALM

Virtual Image Part

Kubernetes - Zookeeper - Docker

Microservice Part

Scala - Netty - Finagle

 

 

 

2.7 가정과 종속 관계

 

본 프로젝트를 수행하기 위해서 필요하거나, 반드시 수행 또는 결정되어야 할 전제조건 또는 선행되어야 할 프로젝트에 대해 기술하여, 그 결과에 따라 본 프로젝트의 어떤 부분에 어떻게 영향을 미칠지를 서술한다. 

 

또한, 통제 불가능한 외부요소에 의해 영향을 받을 수 있는 경우, 그 요소에 대해 서술한다.

 

 

 

2.7.1 예시) APC 4.5 프로젝트

 

V3 IS 9.0은 APC를 통해 원격 설치, 제어가 가능하다. 본 프로젝트의 기본 형상이 제공하는 모든 보안 기능은 APC에 의해 제어가 가능하다. APC 개발 프로젝트는 V3 IS 9.0과 병행한다.

 

  • 프로젝트 개발 문서: 

 

 

 

2.8 하위 호환성

 

신규개발이 아닌 경우, 기존 산출물과의 호환성 방법 및 마이그레이션 방법을 서술한다. 호환성 정보로는 다음과 같은 사항을 제시한다.

 

  • 호환 가능한 이전 버전
  • 호환성을 보장할 수 없는 경우다른 프로젝트 산출물과 함께 사용하는 경우, 연동 가능한 버전 정보
    • 마이그레이션 방법과 마이그레이션 도구 계획
    • 이전 버전에 대한 백포트(backport) 또는 패치 계획

 

 

 

 

 

 

 

 

3. 환경

 

 

 

3.1 설치 환경

 

본 프로젝트의 결과물을 설치하기 위한 하드웨어, 소프트웨어, 네트워크 환경을 기술한다.

 

제품의 설치삭제와 빌드시스템, 마스터의 구성과 설치파일 목록 등에 대한 보다 자세한 사항을 기술해야 할 필요성이 있는 경우 설치요구명세서를 별도로 작성할 것을 권장한다.

 

설치요구명세는 샘플과 템플릿을 이용한다.

 

 

 

3.1.1 하드웨어 환경

 

결과물 설치에 필요한 하드웨어 최소 사양, 권장 사양을 기술한다. 산출물을 여러 시스템에 분리되어 설치해야 하는 경우, 각 설치 대상 시스템 별로 사양을 서술한다.

 

산출물이 전용 어플라이언스에 설치되는 경우, 해당 기기의 하드웨어 사양을 서술한다. 어플라이언스의 하드웨어 사양은 별도 파일로 제공할 수 있다.

 

이때 명시가 필요한 항목은 아래와 같다.

 

장비 모델명(가칭)

CPU 사용(CPU종류, Clock, Core수, CPU개수)

Memory 용량

Flash Disk 용량(Flash 사용시)

NIC 구성(Media 종류, 개수)

LCD 사양(LCD 구성 시)

시리얼 포트 여부

Bypass 사양(NIC 종류별 Bypass 지원 여부)

Power 사양(Dual/Single 여부)

 

  

 



3.1.2 소프트웨어 환경

 

 

 

3.1.2.1 운영체제

 

여기에 명시되는 운영체제는 개발 시에도 중요하지만, 테스팅 단계에서 모두 테스트해야 하므로 명확하게 작성한다. 다음과 같은 요소를 고려해서 작성한다.

 

  • 플랫폼(Windows, Linux, Unix, Android, iOS 등)
  • OS 버전 & 에디션(여러 개의 에디션이 존재한다면)
  • 서비스 팩 또는 패치 요구 사항

 

 

 

3.1.2.2 기타 소프트웨어

 

OS 외에 지원 또는 제한되는 소프트웨어를 명시한다. 예를 들면 DBMS나 웹 브라우저 같은 것들이 고려되어야 하는 경우가 많다. 물론 이름과 버전, 서비스팩, 패치 요구 사항을 정확하게 적어야 한다.

 

 

 

3.1.3 네트워크 환경

 

프로젝트 산출물이 네트워크 연결이 필요한지 명시한다. 어느 시스템(또는 네트워크)과 어떤 통신을 수행하는지는 통신 인터페이스에서 기술한다. 프로젝트 산출물이 네트워크 어플라이언스인 경우, 설치되어 운영하는 네트워크 환경을 명시한다.

 

 

 

3.2 제품 설치 및 설정

 

본 프로젝트의 산출물의 설치나 설정 과정에서 필요한 요구사항을 기술한다. 예를 들어 DBMS나 .NET 프레임워크를 먼저 설치해야 하는 제품이 있을 수 있다. 설치에 필요한 다른 어플리케이션이나 라이브러리 파일을 프로젝트 산출물과 

 

함께 배포하기로 결정했으면, 마스터 구성에 해당 애플리케이션과 라이브러리 파일 목록을 작성한다.

 

또한 제품을 실행하는데 필요한 기본 설정 요소 및 방법에 대한 요구사항을 기술한다. 설치나 설정 변경을 위해 별도의 툴이 필요한 경우에는 그 툴에 대한 부분도 명시한다.

 

어플라이언스 제품은 단일 하드웨어에 여러 소프트웨어를 설치하는 경우가 있을 수 있다. 하드웨어 구성에 따라 설치 방법을 나누어 작성한다.

 

  • 제품 설치에 필요한 사전 준비 조건
  • 단일 머신에 설치하는 경우
  • 여러 머신에 분산 설치하는 경우

 

 

 

3.3 배포

 

 

 

3.3.1 패키지 구성

 

 

 

3.3.1.1 예시) 마스터 CD

 

 

 

3.3.1.2 예시) 온라인 설치 패키지

 

온라인 설치 패키지는 마스터 CD 구성 형식과 다를 수 있다. 설치 프로그램만 제공하는 경우가 많기 때문에 매뉴얼과 기타 유틸리티의 제공 방법(예: ' 홈페이지에서 로그인 후 제품 구매 내역에서 PDF 매뉴얼을 제공한다.' 또는 '마스터 CD와 동일한

 

동일한 구성물을 압축 파일로 다운로드')을 기술해야 한다.

 

 

 

3.3.3 배포 방법

 

본 프로젝트의 산출물 마스터를 어떤 방법으로 배포할 것인지를 서술한다. 예를 들어, CD로 배포하거나, 웹페이지에서만 다운로드 받게 할 수 있다. 어플라이언스 기기는 펌웨어를 전용 장비에 설치해 배포하는 방법을 사용한다.

 

 

 

3.3.4 패치 및 업데이트 방법

 

배포 후 제공할 제품의 패치나 업데이트(엔진이나 시그니처를 사용하는 제품의 경우) 종류와 방법을 명시한다. 스마트 업데이트를 사용해야 하는지 여부와 수동 패치를 위한 설치본 제공 필요 여부 등도 모두 포함된다.

 

 

 

3.4 형상관리

 

 

 

3.4.1 산출물 위치

 

 

 

3.4.1.1 소스코드

 

소스코드는 다음 경로에 저장한다.

 

 

 

 

3.4.1.2 문서

 

문서 소스는 다음 경로에 저장한다.

 

 

  

 

3.4.2 빌드 환경

 

소스의 빌드를 위한 시스템 환경, 빌드 툴, 컴파일러 등에 대해서 명시한다. 기본적으로 모든 소프트웨어 개발은 별도의 빌드 시스템을 사용하는 것을 원칙으로 하며 로컬 빌드는 개발자 개인의 유닛 테스트 목적인 경우를 제외하고 금지한다.

 

 

 

3.5 결함관리

 

이슈관리를 위해 사용할 시스템 및 이슈트래킹 프로세스. 사내 기본 이슈관리 시스템인 WORKS를 사용하고 "제품개발 프로세스"를 따르면 프로세스를 별도로 명시할 필요는 없다.

 

  • WORKS 프로젝트 이름 : 

 

 

 

 

 

4. 인터페이스 요구사항

 

4.1 사용자 인터페이스

...