Changes between Version 5 and Version 6 of SDG


Ignore:
Timestamp:
Sep 6, 2023 2:48:08 AM (20 months ago)
Author:
admin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SDG

    v5 v6  
    194194이관 단계의 목적은 소프트웨어 제품을 프로젝트 팀 외부의 사용자에게 이관하는 것이다.  
    195195 
    196  
    197  
    198  
     196=== 10.2. WORKFLOW (워크플로우) === 
     197 
     198==== 10.2.1. BUSINESS MODELING (비즈니스 모델링) ==== 
     199Business model describes product concept and business process to assure a common understanding among all stakeholders of what product is planned and what business process needs to supported in the organization.  
     200 
     201비즈니스 모델은 조직에서 어떤 제품이 기획되고 어떤 비즈니스 프로세스가 지원될 필요가 있는지를 이해당사자 사이에 공통의 이해를 도모하기 위해 제품 컨셉과 비즈니스 프로세스를 기술한다.  
     202 
     203The deliverable of business modeling workflow is a software development plan. 
     204 
     205비즈니스 모델링의 산출물은 소프트웨어 개발 계획 문서이다. 
     206 
     207==== 10.2.2. REQUIREMENT (비즈니스 모델링) ==== 
     208The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer (product manager?) to agree on that description.  
     209 
     210요구사항 워크플로우의 목표는 시스템이 무엇을 할 지를 기술하고, 개발자와 고객이 기술한 바에 대해 동의할 수 있게 하는 것이다.   
     211 
     212The deliverable of requirements workflow is a risk management plan, a cyber security checklist and a software requirement specification.  
     213 
     214요구사항 워크플로우의 산출물은 리스크 관리 계획 문서, 사이버 보안 점검표, 소프트웨어 요구사항 문서이다. 
     215 
     216==== 10.2.3. ANALYSIS AND DESIGN (분석 및 설계) ==== 
     217The goal of the Analysis and Design workflow is to show how the system will be realized in the implementation phase.  
     218 
     219분석과 설계 워크플로우의 목표는 구현 워크플로우에서 시스템을 어떻게 실현시킬 지를 보는 것이다.  
     220 
     221The deliverables of analysis and design workflow is a software architecture.  
     222분석과 설계 워크플로우의 산출물은 소프트웨어 아키텍처이다. 
     223 
     224==== 10.2.4. IMPLEMENTATION (구현) ==== 
     225The purpose of implementation is: 
     226 - To define the organization of the code, in terms of implementation subsystems organized in layers. 
     227 - To implement classes and objects in terms of components (source files, binaries, executables, and others) 
     228 - To verify the developed components as units. 
     229 - To integrate the results produced by individual implementers (or team), into an executable system.  
     230 
     231구현 워크플로우의 목적은 다음과 같다: 
     232 - 계층적으로 구조화된 서브시스템 구현의 관점에서 코드의 구성을 정의한다.  
     233 - (소스 파일, 바이너리 파일, 이진 파일 등등의) 구성요소의 관점에서 클래스와 객체를 구현한다.  
     234 - 개발된 구성요소를 소프트웨어 단위(software unit)로써 검증한다.  
     235 - 개별적인 구현자(또는 팀)에 의해 생산된 결과를 실행가능한 시스템으로 통합한다.  
     236 
     237The deliverables of implementation workflow are detailed requirement specification, design specification, source code and software specification plan 
     238 
     239구현 워크플로우의 산출물은 상세 요구사항 문서, 설계 문서, 소스 코드 및 소프트웨어 검증 계획 문서이다. 
     240 
     241==== 10.2.5. VERIFICATION & VALIDATION (검증) ==== 
     242The purpose of verification is: 
     243 - To verify the interaction between objects 
     244 - To verify the proper integration of all components of the software 
     245 - To verify that all requirements have been correctly implemented 
     246 - To identify and ensure defects are addressed prior to the deployment of the software 
     247 
     248검증의 목적은 다음과 같다: 
     249 - 객체간 인터랙션(상호작용)을 검증한다.  
     250 - 소프트웨어의 모든 구성요소가 적절하게 통합되었는지를 검증한다.  
     251 - 모든 요구사항이 올바르게 구현되어 있는지를 검증한다.  
     252 - 소프트웨어를 배포하기 전에 결함을 식별하고 해결한다. 
     253 
     254The deliverables of verification workflow are software verification reports, risk management report and software validation report.  
     255 
     256검증 워크플로우의 산출물은 software verification reports와 risk management report 및 software validation report이다. 
     257 
     258==== 10.2.6. DEPLOYMENT (배포) ==== 
     259The purpose of the deployment workflow is to successfully produce product releases, and deliver the software to its end users.  
     260 
     261배포 워크플로의 목적은 제품을 성공적으로 출시해서 최종 사용자에게 소프트웨어를 전달하는 것이다.  
     262 
     263The deliverables of the deployment workflow are installable software, and release note. 
     264 
     265배포 워크플로우의 산출물은 설치가능한 소프트웨어와 릴리즈 노트이다. 
     266 
     267==== 10.2.7. PROJECT MANAGEMENT (프로젝트 관리) ==== 
     268Software Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to deliver, successfully, a product in which meets the needs of customers and the users.  
     269 
     270소프트웨어 프로젝트 경쟁하는 목표들을 조율하고, 리스크를 관리하고 제약사항을 극복하여 성공적으로 고객과 사용자의 필요를 충족시키는 제품을 전달하는 행위이다.  
     271 
     272The deliverables of project management workflow are Software development plan and project meeting minutes.  
     273 
     274프로젝트 관리의 산출물은 소프트웨어 개발 계획 문서와 프로젝트 회의록이다. 
     275 
     276==== 10.2.8. CONFIGURATION AND CHANGE REQUEST MANAGEMENT ==== 
     277The purpose of the configuration and change request management workflow is to trace why, when, and by whom any deliverable was changed.  
     278 
     279형상관리와 변경요청 관리 워크플로우의 목적은 이유, 시기 그리고 누구에 의해 산출물이 변경되었는지를 추적하는 것이다.  
     280 
     281The deliverables of the configuration and change request management workflow are configuration items and change requests. 
     282 
     283형상관리와 변경요청 관리 워크플로우의 산출물은 형상관리 아이템들과 변경요청 사항들이다.  
     284 
     285Change request management workflow are activities for the problem resolve management process. 
     286 
     287변경 요청 관리 워크플로우는 문제 해결 관리 프로세스를 위한 활동이다. 
     288 
     289==== 10.2.9. ENVIRONMENT (개발환경) ==== 
     290The purpose of the environment workflow is to provide the software development organization with the software development environment – both processes and tools – that are needed to support the development team.  
     291 
     292환경 워크플로우의 목적은 소프트웨어 팀을 지원하기 위해 필요한 소프트웨어 개발 환경(프로세스와 도구)을 소프트웨어 개발 조직에게 제공하는 것이다. 
     293 
     294The deliverable of the environment workflow is a software development plan for a project.  
     295 
     296환경 워크플로우의 산출물은 소프트웨어 개발 계획 문서이다. 
     297 
     298=== 10.3. 산출물 === 
     299The process recommends software development documents (or deliverables) depending on Phase like as: 
     300소프트웨어 개발 프로세스는 프로젝트 단계별로 다음과 같은 소프트웨어 개발 문서 (또는 산출물) 권장한다: 
     301 
     302== 11. 소프트웨어 형상관리 == 
     303 
     304=== 11.1. 소프트웨어 형상관리 도구 === 
     305소프트웨어 형상 관리 도구를 사용해야 한다.  
     306 
     307=== 11.2. 소프트웨어 버전 === 
     308소프트웨어 버전 형식은 다음과 같다: 
     309 - major.minor.patch.build 
     310 
     311위에서,  
     312 - major는 주요한 기능이 추가되었을 때 증가시킨다. 
     313 - minor는 기능이 개선되거나 단순한 기능이 추가되었을 때 증가시킨다. 
     314 - patch는 출시된 버전의 오류를 해결했을 때 증가시킨다. 
     315 - build는 전체 integration build를 할 때마다 증가시킨다.  
     316 
     317=== 11.3. 소프트웨어 버전 트리 === 
     318소프트웨어 버전은 다음과 같이 관리한다: 
     319Figure: 소프트웨어 버전 트리 
     320 
     321 
     322위에서, 
     323 - Tagging은 버전을 포함해야 하며, 전체 integration build가 성공하면, build 번호를 증가시켜야 한다.  
     324 - Branching은 configuration item을 다르게 유지해야(evolving) 할 경우에 추가한다.  
     325 - Commit을 할 경우에는 CR 번호 및 타이틀을 포함해야 한다.  
     326 
     327== 12. 소프트웨어 변경 및 문제 해결 관리 == 
     328 
     329=== 12.1. 소프트웨어 변경 및 문제 해결 관리 도구 === 
     330소프트웨어 변경 및 문제 해결 관리 도구를 사용해야 한다.  
     331 
     332=== 12.2. 소프트웨어 변경 및 문제 해결 절차  === 
     333 
     334Figure: 소프트웨어 변경 및 문제 해결 절차  
     335 
     336CR을 등록할 경우 Reporter는 다음 사항을 명시한다: 
     337 - 시스템 버전 
     338 - 변경 요청 사항 요약 (title) 
     339 - 변경 요청 사항 상세 내용. 가능하면, 재발생 스텝을 포함한다. 
     340 
     341== 13. 소프트웨어 개발 환경 == 
     342 
     343=== 13.1. 소프트웨어 개발 도구 === 
     344각 프로젝트는 소프트웨어 빌드를 포함하여 개발 도구 명시한다.  
     345 
     346=== 13.2. 소프트웨어 통합 === 
     347매일 빌드를 수행할 경우, Daily integration을 수행하며, 프로세스는 다음과 같다: 
     348 
     349=== 13.3. 소프트웨어 설치 파일 === 
     350프로젝트는 소프트웨어 설치 파일을 이용하여 소프트웨어를 배포한다. (OS 이미지 제외) 
     351 
     352=== 13.4. 서버 URL === 
     353각 프로젝트는 사용하는 서버에 대해 URL을 포함한 정보를 명시한다.  
    199354 
    200355[.. SDE]