CONFIDENTIALITY/SECURITY WARNING
이 문서에 포함되어 있는 정보는 313 DEV GRP의 자산이며, 313 DEV GRP의 서면 허락 없이 사용되거나, 재 가공 되거나, 외부로 반출 할 수 없습니다. 이 문서에 대한 열람 및 보관할 수 있는 사람은 분실, 도난, 반출에 대한 책임을 자동 승계하는 것에 대하여 동의하는 자에 한 합니다.
목 차
jsTree Service Framework (TSF) 란.
하나의 스키마 안에서 데이터 집합간의 구조적 관계와
스키마간의 릴레이션을 재사용 가능하게 협업화된 클래스들을 제공하는
서비스 레이어 프레임워크 이다.
본 프로젝트는 아래와 같은 상황에서 jsTree Service Framework를 구축하여 다음과 같은 주요 목적을 달성 할 수 있도록 한다.
프레임워크는 구현 시 패턴을 제공하는 방식이나, 몇 가지 기능적인 부분을 제외한 서비스 구현 설계는 제시하지 않는다. 따라서 프레임워크를 사용하지만, 실제 구현은 패턴화 되지 않고, 요청 별 처리 프로세스를 만드는 방식을 취하다보니 단편화 현상이 발생하고, 이는 개발 일관성과 유지보수성에 악영향을 미치게 된다.
즉, 프레임워크를 사용하여 얻어지는 이득이나, 수준은 일정 범위를 벗어나게 되면, 그 실효성이 없어지는 현상이 일어난다. 이 현상은 서비스 코드를 작성하는 개발자의 수준과 철학이 코드에 반영되게 되며, 실제 프레임워크가 관여할 수 없는 부분이기 때문이다.
즉, 고객의 요구사항이 변경되거나 스펙이 바뀌게 되면, 프레임워크 레이어상의 변경이 아닌 개발 코드의 변경은 프로세스 요청마다 구현한 코드의 개별 구성 별로 변경이 이루어지다 보니 점차 코드의 품질이 저하되는 현상이 발생하게 된다
이에, TSF는 날로 복잡해지고, 급격하게 변화하는 고객의 요구사항을 빠르게 반영하면서 어플리케이션 품질을 일정하게 유지하기 위하여 일관된 객체 모델을 활용, 개발 생산성과 품질 그리고 수시 유지보수에 대한 적응성등을 동시에 보장하는 어플리케이션의 아키텍처가 필요함에 따라 TSF(jsTree Service Framework)를 연구 및 구현하게 되었다.
본 프로젝트의 목적은 확장된 Tree 모델을 활용하여 어플리케이션을 단일 로직에 대응 할 수 있음을 증명하는데 있다. ( 중앙 집중형 아키텍쳐 )
연구 방법은 기반 프레임워크인 Spring, Struts, iBatis, Hibernate등을 기준으로 확장 Tree Model을 구현하며, Service Layer의 API Code를 제공하는데 집중된다.
최종적으로는 TSF 와 Egovframework를 통합 및 적응 할 수 있는 패키지로 이행한다.
또한, Cloud 시대에 대응하기 위하여 Docker 컨테이너화 및 분산 아키텍쳐를 적용하여
보안성, 확장성, 생산성, 성능 및 품질을 강화하여 배포하는데 최종 목적을 가진다.
본 프로젝트의 산출물의 범위와 효과는 다음과 같다.
관점 | 산출물 | AS-IS | TO-BE | 시나리오 | 예상 효과 |
---|---|---|---|---|---|
standard-project ( root module ) | 전체 프로젝트 구조 | N/A | Maven 표준에 의거한 Root 프로젝트 정보 제공 | 프로젝트 정보 스펙을 재사용하여 손쉽게 업데이트 할 수 있도록 제공 | Project Info 재사용 현실화 |
lib-module > pom ( library module ) | 통합 라이브러리 관리용 | N/A | TSF에서 활용할 라이브러리 관리용 프로젝트 | Project Lib 재사용 현실화 | |
core-module > jar ( jsTree module ) | jsTree Service Framework source code Jar Project | N/A | TSF + eGovframework 통합 소스코드 Core Jar 프로젝트 | Core Project 재사용 현실화 | |
web-module > war ( API module ) | TSF를 활용한 Backend Api Server ( ROOT.war ) | N/A | TSF Jar 프로젝트를 활용한 PLE API 웹 어플리케이션 ( N ) | 재사용 프로젝트 활용 극대화 | |
flex-module > flv ( Rich Module ) | TSF Api Server를 활용한 Flex Client ( main.flv ) | N/A | TSF API Server 프로젝트를 활용한 Flex Rich Internet Application | Api Server 활용 클라이언트 다양화 | |
mobile-module > apk ( Mobile App Module ) | TSF Api Server를 활용한 Mobile Client ( Main.Apk ) | N/A | TSF API Server 프로젝트를 활용한 Mobile Application | Api Server 활용 클라이언트 다양화 |
본 문서의 작성과 읽을 때 필요한 규칙은 다음과 같다.
본 문서에서 자주 사용하는 용어 및 약어는 다음 표를 참고한다. 용어/약어가 너무 많아 이곳에 기술하는 것이 부적절한 경우 별도의 장으로 나누어 본 문서의 마지막 장에 서술한다.
표 1-1 문서에서 사용하는 관련 용어/약어
용어/약어 | 의미 |
SRS | 소프트웨어 요구 사항 명세서(Software Requirement Specification) |
SDS | 소프트웨어 설계 명세서(Software Design Specification) |
IRS | 인터페이스 요구 사항 명세서(Interface Requirement Specification) |
TDS | 테스트 설계서(Test Design Specification) |
TCL | 테스트 케이스 일람표(Test Case List) |
화면설계서 | 사용자 인터페이스 설계서 |
디자인 스타일 가이드 | 사용자 인터페이스에 적용할 디자인 스타일 가이드 |
PP | 제품 기획자(Product Planner) |
PM | 프로젝트 관리자(Project Manager) |
PE | 개발자(Program Engineer) |
MK | 세일즈 마케터(MarKeting) |
QAE | 품질보증 담당자(Quality Assurance Engineer) |
CC | CC 인증 담당자(Common Criteria evaluation) |
TW | 기술문서 담당자(Technical Writer) |
UX | 사용자 경험 & 제품 디자인 (User eXperience) |
SA | 시스템/네트워크 엔지니어(Security Architect) |
표 1-2 제품/기술/서비스 용어/약어
용어/약어 | 의미 |
TSF | jsTree Service Framework |
SRS 산출에 사용된 문서와 SVN 경로는 다음과 같다. (다음은 콘텐츠 예시임)
본 문서의 독자는 자신의 역할에 따라 다음 체크리스트를 기준으로 문서를 읽는다.
프로젝트 결과물의 유형은 다음과 같다.
GitHub Source Code : https://github.com/jstree
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.주차 끝 한자리
본 프로젝트와 관련하여 지적재산권화되어야 할 주요 기술이 있다면 해당 기술에 대해서 간략히 기술한다.
본 프로젝트는 MIT OpenSource License를 적용하였다.
프로젝트 산출물의 전체적인 구성 및 동작, 기능 등에 대해 제품 기획자가 간략하게 서술한다. 본 프로젝트 산출물과 다른 313 DEV GRP 제품(또는 신규 제품)과의 관계 및 연관성, 위치에 대해 정보를 서술한다.
제품의 분류 정보 : "jsTree Service Framework는 Java Service Layer Framework 서비스 모듈이다"
본 서비스를 사용하는 환경은
제품조망은 다음과 같은 내용이 필요하다.
제품의 분류 정보. 예를 들어"XXXX는 안티바이러스 제품이다." 라거나, "XXX는 고성능 네트워크 침입 차단 제품으로 전용 어플라이언스에서 동작한다."와 같이 서술한다.
자세하지는 않아도 일반적인 제품 사용 환경 기술이 필요하다. 굳이 여기서 기술하지 않는다면 환경에서 상세한 내용을 제공한다.
프로젝트 산출물의 전체 시스템 구성도를 서술한다.
프로젝트 산출물이 단일 시스템에서 운영되는 경우, 운영체제 내에서 산출물의 위치, 운영체제와 다른 애플리케이션 간 관계도를 제시한다.
프로젝트 산출물이 분할 가능한 여러 개의 서브 시스템으로 분리되어 운영되는 경우, 각 서브 시스템 단위로 구성도를 제시한다.
프로젝트 산출물에 이 개발하지 않은 3'rd party의 제품(예, DB 프로그램, 웹서버 등)을 포함하여 전체 시스템 구성을 제시한다.
시스템 구성도를 기준으로 동작 원리 및 시나리오를 서술한다.
프로젝트의 산출물의 주요 기능을 사용자 관점에서 간략히 서술한다. 상세한 내용은 6장 제품 기능을 참고하도록 한다. 6장에서 기술되는 기능 명세 중 최상위 수준 기능을 열거하고, 간략히 기능을 서술한다.
아래 6장 내용과 비교해서 각 기능간 의존도(dependency)를 포함해야 한다. 어떤 기능이 켜져있거나 동작이 되고 있어야 다른 동작에 영향을 미치는지를 확인할 수 있다.
기능 | 설명 |
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; |
프로젝트 산출물의 사용자 특성을 기술한다. 제품 특성에 따라 다른 유형의 사용자가 있을 수 있다. 예를 들어 어플라이언스 기기는 장비의 모든 기능을 제어할 수 있는 관리자, 정보 조회만 허용된 관리자, 그리고 어플라이언스 기가가
제공하는 서비스를 이용하는 일반 사용자, 그리고 제품의 설치단계부터 관리자에게 사용권을 넘기기 전까지 모든 설치과 설정을 담당하는 네트워크 엔지니어로 유형을 나눌 수 있다.
사용자 프로파일은 사용자의 사용 환경, 사용 빈도, 제품에서 주로 사용하는 기능, 제품과 IT 지식 수준 등을 포함해야 한다.
V3IS 의 주요 사용자는 Windows 시스템의 관리자 권한을 갖는 사용자들이다.
소규모 조직은 구성원의 역할 분담이 명확하지 않아 다른 업무와 병행해서 관리 책임을 지는 관리자가 주요 사용자가 된다. 보안에 대한 전문 지식을 갖추지 못했기 때문에 관리포인트를 줄이고, 문제가 발생한 PC/서버의 장애, 보안 사고를 처리하고 싶어한다.
다른 업체에 파견 근무하거나, 컨설팅 등을 수행하는 사용자들
프로젝트에 따른 개발 과정에서 고려할 기술적인 제약 조건을 서술한다. 하드웨어 상의 제약조건은 하드웨어 환경에서 기술한다. 프로젝트 산출물 설치에 필요한 애플리케이션, 라이브러리 파일은 소프트웨어 환경에 서술한다.
jsTree Service Framework 개발 환경
Development Tool : Eclipse & InteliJ
Development Language : OpenJDK Java ( 1.8 higher )
jsTree Service Framework에서 사용한 기술
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 |
본 프로젝트를 수행하기 위해서 필요하거나, 반드시 수행 또는 결정되어야 할 전제조건 또는 선행되어야 할 프로젝트에 대해 기술하여, 그 결과에 따라 본 프로젝트의 어떤 부분에 어떻게 영향을 미칠지를 서술한다.
또한, 통제 불가능한 외부요소에 의해 영향을 받을 수 있는 경우, 그 요소에 대해 서술한다.
V3 IS 9.0은 APC를 통해 원격 설치, 제어가 가능하다. 본 프로젝트의 기본 형상이 제공하는 모든 보안 기능은 APC에 의해 제어가 가능하다. APC 개발 프로젝트는 V3 IS 9.0과 병행한다.
신규개발이 아닌 경우, 기존 산출물과의 호환성 방법 및 마이그레이션 방법을 서술한다. 호환성 정보로는 다음과 같은 사항을 제시한다.
본 프로젝트의 결과물을 설치하기 위한 하드웨어, 소프트웨어, 네트워크 환경을 기술한다.
제품의 설치삭제와 빌드시스템, 마스터의 구성과 설치파일 목록 등에 대한 보다 자세한 사항을 기술해야 할 필요성이 있는 경우 설치요구명세서를 별도로 작성할 것을 권장한다.
설치요구명세는 샘플과 템플릿을 이용한다.
결과물 설치에 필요한 하드웨어 최소 사양, 권장 사양을 기술한다. 산출물을 여러 시스템에 분리되어 설치해야 하는 경우, 각 설치 대상 시스템 별로 사양을 서술한다.
산출물이 전용 어플라이언스에 설치되는 경우, 해당 기기의 하드웨어 사양을 서술한다. 어플라이언스의 하드웨어 사양은 별도 파일로 제공할 수 있다.
이때 명시가 필요한 항목은 아래와 같다.
장비 모델명(가칭) |
CPU 사용(CPU종류, Clock, Core수, CPU개수) |
Memory 용량 |
Flash Disk 용량(Flash 사용시) |
NIC 구성(Media 종류, 개수) |
LCD 사양(LCD 구성 시) |
시리얼 포트 여부 |
Bypass 사양(NIC 종류별 Bypass 지원 여부) |
Power 사양(Dual/Single 여부) |
여기에 명시되는 운영체제는 개발 시에도 중요하지만, 테스팅 단계에서 모두 테스트해야 하므로 명확하게 작성한다. 다음과 같은 요소를 고려해서 작성한다.
OS 외에 지원 또는 제한되는 소프트웨어를 명시한다. 예를 들면 DBMS나 웹 브라우저 같은 것들이 고려되어야 하는 경우가 많다. 물론 이름과 버전, 서비스팩, 패치 요구 사항을 정확하게 적어야 한다.
프로젝트 산출물이 네트워크 연결이 필요한지 명시한다. 어느 시스템(또는 네트워크)과 어떤 통신을 수행하는지는 통신 인터페이스에서 기술한다. 프로젝트 산출물이 네트워크 어플라이언스인 경우, 설치되어 운영하는 네트워크 환경을 명시한다.
본 프로젝트의 산출물의 설치나 설정 과정에서 필요한 요구사항을 기술한다. 예를 들어 DBMS나 .NET 프레임워크를 먼저 설치해야 하는 제품이 있을 수 있다. 설치에 필요한 다른 어플리케이션이나 라이브러리 파일을 프로젝트 산출물과
함께 배포하기로 결정했으면, 마스터 구성에 해당 애플리케이션과 라이브러리 파일 목록을 작성한다.
또한 제품을 실행하는데 필요한 기본 설정 요소 및 방법에 대한 요구사항을 기술한다. 설치나 설정 변경을 위해 별도의 툴이 필요한 경우에는 그 툴에 대한 부분도 명시한다.
어플라이언스 제품은 단일 하드웨어에 여러 소프트웨어를 설치하는 경우가 있을 수 있다. 하드웨어 구성에 따라 설치 방법을 나누어 작성한다.
온라인 설치 패키지는 마스터 CD 구성 형식과 다를 수 있다. 설치 프로그램만 제공하는 경우가 많기 때문에 매뉴얼과 기타 유틸리티의 제공 방법(예: ' 홈페이지에서 로그인 후 제품 구매 내역에서 PDF 매뉴얼을 제공한다.' 또는 '마스터 CD와 동일한
구성물을 압축 파일로 다운로드')을 기술해야 한다.
본 프로젝트의 산출물 마스터를 어떤 방법으로 배포할 것인지를 서술한다. 예를 들어, CD로 배포하거나, 웹페이지에서만 다운로드 받게 할 수 있다. 어플라이언스 기기는 펌웨어를 전용 장비에 설치해 배포하는 방법을 사용한다.
배포 후 제공할 제품의 패치나 업데이트(엔진이나 시그니처를 사용하는 제품의 경우) 종류와 방법을 명시한다. 스마트 업데이트를 사용해야 하는지 여부와 수동 패치를 위한 설치본 제공 필요 여부 등도 모두 포함된다.
소스코드는 다음 경로에 저장한다.
문서 소스는 다음 경로에 저장한다.
소스의 빌드를 위한 시스템 환경, 빌드 툴, 컴파일러 등에 대해서 명시한다. 기본적으로 모든 소프트웨어 개발은 별도의 빌드 시스템을 사용하는 것을 원칙으로 하며 로컬 빌드는 개발자 개인의 유닛 테스트 목적인 경우를 제외하고 금지한다.
이슈관리를 위해 사용할 시스템 및 이슈트래킹 프로세스. 사내 기본 이슈관리 시스템인 WORKS를 사용하고 "제품개발 프로세스"를 따르면 프로세스를 별도로 명시할 필요는 없다.
필요한 경우 하드웨어 종속적인 요구 사항들을 기술한다. 사용자가 하드웨어(이하 장비)에 접근하기 위해 제공되는 물리적인 인터페이스로서 NIC(Network Interface Card), Serial 포트, LCD, LED 등 인터페이스를 모두 기술한다.
제품이 달성해야 하는 성능 요구 사항 및 성능 목표를 기술한다. 성능 테스트의 Pass/Fail 여부를 판단하는 근거가 되므로, 반드시 정량적으로 측정할 수 있도록 기술한다.
성능 측정 시 사용할 하드웨어 사양을 반드시 기재한다.
성능 측정 시 사용할 소프트웨어 종류와 설정 값을 함께 기술한다.
아래 성능 측정 항목은 프로젝트에 따라 선택 적용하거나 추가할 수 있다.
대상 | 내용 | 비고 |
Hardware | Intel Core2 Duo E6300 DDR3 1G HDD 1TB 7200RPM |
|
OS | Windows 7 Professional SP1 |
|
Software | V3 IS 9.0 |
|
Option | 실시간검사 On 검사 대상 : 모든 파일 추가 검사 : 유해 가능 ASD : On |
|
아래 성능 시험 실패 기준은 V3를 기준으로 한 가상의 목표이므로, 각 프로젝트의 성격에 맞는 성능 목표를 설정한다.
대상 | 내용 | 비고 |
Idel 상태 | CPU : 2% 미만의 CPU 사용량 Pass | (Committed Byte 기준) |
수동검사 시 | 대상 : 소프트웨어 QA팀 엔진테스트 대표 샘플 CPU : 30% 미만 Memory : 150MB 미만 Scan Speed : 대표 샘플 5분 내에 모두 검사 완료 Network : ASD 네트워크 1MB 미만 사용 Disk : 디스크 복사 기간이 미설치보다 5% 미만 저하 Boot Time : 제품 설치 후 부팅시간이 10% 미만 증가 | 옵션 별 다른 성공/실패 기준 적용 명시한다. |
제품이 요구하는 보안성 기준치 요구 사항을 기술한다. 다음의 체크리스트를 활용한다.
최소한의 보안성 요구사항으로 아래 위치의 체크리스트 점검을 본 SRS에 첨부한다.
http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Public/Guideline/보안성 가이드
사용 가능한 암호 알고리즘을 확인한다.
http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Public/Guideline/보안성 가이드
최소한의 제품군 별 취약성으로 다음의 체크리스트가 활용한다.
http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Public/Guideline/보안성 가이드
ISO/IEC 9126은 소프트웨어에 요구되는 품질 특성에 대해서 정의하고 있는 표준이다. 품질 특성은 주특성과 하위의 부특성들로 이루어져 있다. 이 특성들은 모든 소프트웨어에 공통적으로 요구되는 것이기는 하지만, 개발하고자 하는 소프트웨어의 사업적 가치나 투입할 수 있는 비용의 규모, 개발 기간 등에 의해서 적절한 수용 범위를 정하는게 중요하다.
본 절의 내용들은 기능 이외의 요구사항을 도출하는 과정에서 검토해 볼 질문들을 제시하며 선택적으로 적용하면 된다.
따라서 채택한 내용들을 반드시 본 절에 기록할 필요는 없고, 요구 내용에 따라서 나눠져 있는 본 SRS의 여러 항목 중 적절한 부분에 기술하면 된다.
소프트웨어가 특정 조건에서 사용될 때, 명시된 요구(본 SRS 또는 기획서 등 요구사항을 정리한 문서에 명시된 요구사항)와 내재된 요구(요구명세 문서에 적혀있지는 않지만, 당연히 소프트웨어 개발 시에 고려되어야 할 요구사항)를 만족하는 기능을 제공하는 소프트웨어 제품의 능력을 말한다.
요구사항이 소프트웨어에 적절하게 기능으로 제공되었는지 여부를 말한다.
문서(SRS, 도움말, 설명서 등)에 기술되어 있는 기능이 모두 구현될 것.
소프트웨어에 필요한 필수적인 기능이 충분히 구현될 것
올바른 혹은 요구된 결과를 정확하게 제공하는지 여부가 핵심이다.
설계 문서 또는 사용자 문서에 기술된 기능과 구현된 기능 결과의 일치 여부
소프트웨어 동작의 결과값과 문서에 정의된 요구값의 일치 정도
경계값이 정의되어 있을 것
하나 이상의 명세된 시스템 또는 타 소프트웨어와 상호작용할 수 있는지가 핵심이다. 완전히 단독으로 동작하며, 동작 환경에 의존성이 전혀 없는 소프트웨어를 제외하고는 연동이나 호환을 위한 규칙이 필요하다.
그것은 인터페이스, 메시지, 프로토콜 등으로 말할 수 있는데, 표준을 따르거나 별도의 규격을 정할 수도 있다.
권한이 있는 접근을 허용하고, 권한이 없는 접근으로부터 시스템과 데이터를 보호할 수 있는 것이 핵심이다.
기능과 관련된 표준, 관례 또는 법적인 규제를 충족하는 능력을 말한다.
명세된 조건에서 사용될 때 결함을 예방하고, 고장 발생시에도 정해진 성능 수준을 유지하며, 고장으로부터 회복하는 능력을 말한다.
소프트웨어 내의 결함으로 인한 고장을 예방하거나 피해가는 소프트웨어 능력을 말한다.
명세된 인터페이스를 벗어난 입력 또는 소프트웨어의 결함이 발생했을 때에도 명세된 성능 수준을 유지할 수 있는 능력을 말한다.
소프트웨어 제품 사용 중 오류로 인한 영향을 회복하고 정상 사용 가능한 수준으로 회복하는 능력을 말한다.
신뢰성에 관한 규격, 표준, 관례 등을 말하는데, 인증을 필요로 하는 제품의 경우 인증에서 요구하는 규격도 있을 수 있다.
명세된 조건에서 사용될 경우 사용자에 의해 이해되고, 학습되고, 사용되고, 사용자에게 선호되도록 하는 소프트웨어 능력을 말한다.
소프트웨어가 적합한지 그리고 특정 작업과 사용 조건에서 어떻게 사용될 수 있는지를 사용자가 파악할 수 있도록 하는 능력을 말한다.
사용자가 소프트웨어 사용 및 응용을 학습할 수 있도록 하는 능력을 말한다.
사용자가 소프트웨어 제품을 운영하고 제어할 수 있도록 하는 능력을 말한다.
사용자에 의해 선호되는 소프트웨어 제품의 능력을 말한다.
사용성에 관련된 표준, 관례, 유형 안내 및 규제를 충족하는 능력을 말한다.
명시된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 능력을 말한다.
사용자가 소프트웨어에 어떤 특정한 입력을 제공한 후부터 결과를 얻거나 목적을 달성하기까지 소요된 시간으로 평가한다. 사용자가 인내할 수 있는 한계 시간에 대한 고려도 필요하다.
명시된 조건에서 소프트웨어가 그 기능을 수행할 때 적절한 양과 종류의 자원을 사용한다.
효율성과 관련된 표준, 관례, 규격을 충족하는지 여부
한 환경에서 다른 환경으로 전이될 수 있는 소프트웨어 제품의 능력을 말한다.
소프트웨어 내에서 이식의 목적으로 제공되는 것 이외의 활동 혹은 수단을 사용하지 않고 다른 명세된 환경으로 변경할 수 있는 소프트웨어 능력을 말한다.
명세된 환경에 설치될 수 있는 소프트웨어 제품의 능력을 말한다.
컴퓨터의 자원을 공유하는 다른 독립적인 소프트웨어와 공존할 수 있는 소프트웨어 제품 능력을 말한다.
동일한 환경에서 동일한 목적으로 사용되는 다른 소프트웨어를 대체할 수 있는 능력을 말한다.
이식성과 관련된 표준, 관례, 규제 등을 충족할 수 있는지 여부
소프트웨어 제품이 변경되는 능력. 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선, 혹은 개작 등이 포함된다.
소프트웨어의 결함이나 고장의 원인 혹은 변경될 부분들의 식별에 대한 진단을 가능하게 하는 소프트웨어 제품의 능력을 말한다.
명세된 변경이 가능하도록 하는 소프트웨어 제품의 능력을 말한다.
소프트웨어 변경으로 인해 예상치 않는 결과를 최소화하는 소프트웨어 능력을 말한다.
변경된 소프트웨어의 결과를 확인할 수 있는 소프트웨어 제품의 능력을 말한다.
유지보수성과 관련된 표준, 관례, 규제 등을 충족할 수 있다.
제품 메시지와 테크니컬 라이팅 입장에서 국제와(Internationalization, I18N)와 현지화(Localization, L12N)에 대해서 서술한다.
단일 국가나 지역에서만 사용되는 언어가 아닐 수 있으므로 여러 지역에서 사용되는 언어인 경우 지역을 함께 명시하는 것도 좋은 방법이다.
313 DEV GRP Internationalization Guideline 문서 및 관련 공통모듈(ex: AhnI18N2.dll) 적용 여부 등에 대해 기술한다.
특별한 이유가 없다면 언어적인 제약을 피하기 위해 유니코드(UTF-8)를 사용한다.
프로젝트 산출물을 판매 대상 시장에 따라 다국어 작업을 병행하거나, 기준이 될 언어를 지정한다. 여기엔 다음과 같은 내용이 기술되어야 한다.
지원하는 로케일을 기술한다.
본 프로젝트 산출물이 준수해야 하는 법규 준수, 인증(Certification) 획득 필요성 등을 서술한다. 해외에 출시될 제품이라면, 출시 목표 시장에서 준수해야 할 규제항목도 조사해 간략히 서술한다.
어떤 법규를 준수해야 하는지, 획득해야 할 인증은 무엇인지, 받는다면 어떤 인증을 받아야 하는지, 언제 어떤 방법으로 진행하며, 무엇을 준비해야 하는지, 그 비용은 어떻게 되는지 서술한다.(PP/MK 협의 요망)
프로젝트 산출물이 외부 인증을 받아야 하는 경우 인증 준비, 방법, 시기 비용 등을 기술한다.
참고할 외부 인증 사항은 다음과 같다.
프로젝트 산출물을 공공기관에 판매하려면 CC 인증 획득이 필요하다.
장애인 차별 금지법 준수 여부를 기술하고, 시장 및 고객 요구 사항에 따라 해당하는 지침과 지침의 반영 범위를 기술한다.
UX팀의 가이드를 참고하여 작성할 수 있다.
참고)
위 참고자료는 아래 SVN에서 확인 가능하다.
http://svn.313 DEV GRP.co.kr/313 DEV GRPDocUI/Common/자료/외부자료/접근성 관련 자료/국내외 표준 지침 자료
해외 수출용 제품은 전략물자에 해당하는지 확인이 필요하다. 정부에서 운영하는 전략물자관리시스템(http://www.yestrade.go.kr/)에서 확인할 수 있다.
해당 사항이 없다고 판단되는 경우, 본 항목은 N/A 처리한다.
제품 출시 전에 외부 베타 테스트나 필드 테스트 요구 사항이 있다면 서술한다. 마케터나 제품기획자와 협의할 필요가 있다.
상세 일정 및 레퍼런스 사이트 리스트 등은 개발계획서에 명시한다.
외부에서의 테스트나 특정 고객을 이용한 테스트 계획을 서술한다.
공개 소프트웨어(Open Source) 사용 여부와 라이선스 종류 및 중복 등에 대해 서술한다. 라이선스 회피 방법 및 소스 공개 범위와 방법에 대해서도 서술한다.
표 5-1 사용할 오픈 소스 라이선스
제품/라이브러리 명칭 | 라이선스 유형 | 2차 저작물 소스 공개 의무 | 참고 |
BusyBox | GPL v2.0 | O | 품의에 의한 사용 협의 완료 |
Linux kernel | Free BSD | X |
|
주요기능에서 설명되었던 제품 주요 기능을 상세하게 분류하고, 설명한다. 상세화 수준은 작업량이 1~2일 정도로 산정 가능하도록 작성한다.
각 기능에는 입력과 출력, 입력 가능한 기본값과 유효범위, 기본상태가 기술되어야 한다.
특정 환경만 지원하는 기능이 있다면 기술한다.(예: 64bit 환경에서 동작하지 않는 기능, Windows 2000이하에서 동작하지 않는 기능, Vista 이상에서만 동작하는 기능 등.)
Kubernetes : 쿠버네티스는 디플로이 자동화, 스케일링, 컨테이너화된 애플리케이션의 관리를 위한 오픈 소스 시스템
ZooKeeper : 공개 분산형 구성 서비스, 동기 서비스 및 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공
Apache Kafka : 스칼라로 개발한 오픈 소스 메시지 브로커
Api GateWay : Zulu 리퀘스트 프록시 라우팅 서비스
Redis : Remote Dictionary Server의 약자로서, "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템
MicroService : 모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴
Netty (Java) : 높은 성능의 프로토콜 서버 및 클라이언트를 신속한 개발을 위한 비동기 이벤트 드리븐 네트워크 어플리케이션 프레임워크
Hadoop : 하둡은 대용량 데이터를 분산 처리할 수 있는 자바 기반의 오픈 소스 프레임워크
E ( Elastic Search ) : 분산형 RESTful 검색 및 분석 엔진
L ( Logstash ) : 서버측 데이터 처리 파이프라인
K ( Kibana ) : 데이터를 시각적으로 탐색하고 실시간으로 분석
Beats : 서버에 에이전트로 설치하여 다양한 유형의 데이터를 Elastic Search 또는 Logstash에 전송하는 오픈 소스 데이터 발송자
NoSQL : 단순 검색 및 추가 작업을 위한 매우 최적화된 키 값 저장 공간으로, 레이턴시와 스루풋과 관련하여 상당한 성능 이익을 내는 것이 목적
GraphDB : 컴퓨팅에서 그래프 데이터베이스는 시맨틱 쿼리를 위해 노드, 엣지, 프로퍼티와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장하는 데이터베이스