196 | | |
197 | | |
198 | | |
| 196 | === 10.2. WORKFLOW (워크플로우) === |
| 197 | |
| 198 | ==== 10.2.1. BUSINESS MODELING (비즈니스 모델링) ==== |
| 199 | Business 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 | |
| 203 | The deliverable of business modeling workflow is a software development plan. |
| 204 | |
| 205 | 비즈니스 모델링의 산출물은 소프트웨어 개발 계획 문서이다. |
| 206 | |
| 207 | ==== 10.2.2. REQUIREMENT (비즈니스 모델링) ==== |
| 208 | The 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 | |
| 212 | The 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 (분석 및 설계) ==== |
| 217 | The goal of the Analysis and Design workflow is to show how the system will be realized in the implementation phase. |
| 218 | |
| 219 | 분석과 설계 워크플로우의 목표는 구현 워크플로우에서 시스템을 어떻게 실현시킬 지를 보는 것이다. |
| 220 | |
| 221 | The deliverables of analysis and design workflow is a software architecture. |
| 222 | 분석과 설계 워크플로우의 산출물은 소프트웨어 아키텍처이다. |
| 223 | |
| 224 | ==== 10.2.4. IMPLEMENTATION (구현) ==== |
| 225 | The 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 | |
| 237 | The 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 (검증) ==== |
| 242 | The 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 | |
| 254 | The 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 (배포) ==== |
| 259 | The purpose of the deployment workflow is to successfully produce product releases, and deliver the software to its end users. |
| 260 | |
| 261 | 배포 워크플로의 목적은 제품을 성공적으로 출시해서 최종 사용자에게 소프트웨어를 전달하는 것이다. |
| 262 | |
| 263 | The deliverables of the deployment workflow are installable software, and release note. |
| 264 | |
| 265 | 배포 워크플로우의 산출물은 설치가능한 소프트웨어와 릴리즈 노트이다. |
| 266 | |
| 267 | ==== 10.2.7. PROJECT MANAGEMENT (프로젝트 관리) ==== |
| 268 | Software 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 | |
| 272 | The 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 ==== |
| 277 | The purpose of the configuration and change request management workflow is to trace why, when, and by whom any deliverable was changed. |
| 278 | |
| 279 | 형상관리와 변경요청 관리 워크플로우의 목적은 이유, 시기 그리고 누구에 의해 산출물이 변경되었는지를 추적하는 것이다. |
| 280 | |
| 281 | The deliverables of the configuration and change request management workflow are configuration items and change requests. |
| 282 | |
| 283 | 형상관리와 변경요청 관리 워크플로우의 산출물은 형상관리 아이템들과 변경요청 사항들이다. |
| 284 | |
| 285 | Change request management workflow are activities for the problem resolve management process. |
| 286 | |
| 287 | 변경 요청 관리 워크플로우는 문제 해결 관리 프로세스를 위한 활동이다. |
| 288 | |
| 289 | ==== 10.2.9. ENVIRONMENT (개발환경) ==== |
| 290 | The 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 | |
| 294 | The deliverable of the environment workflow is a software development plan for a project. |
| 295 | |
| 296 | 환경 워크플로우의 산출물은 소프트웨어 개발 계획 문서이다. |
| 297 | |
| 298 | === 10.3. 산출물 === |
| 299 | The 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 | 소프트웨어 버전은 다음과 같이 관리한다: |
| 319 | Figure: 소프트웨어 버전 트리 |
| 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 | |
| 334 | Figure: 소프트웨어 변경 및 문제 해결 절차 |
| 335 | |
| 336 | CR을 등록할 경우 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을 포함한 정보를 명시한다. |