{"id":28812347,"url":"https://github.com/tpdlshdmlrkfmcla/software_engineering_finalexam","last_synced_at":"2026-01-31T22:32:27.816Z","repository":{"id":168141332,"uuid":"640949162","full_name":"tpdlshdmlrkfmcla/Software_Engineering_Finalexam","owner":"tpdlshdmlrkfmcla","description":"소프트웨어공학 기말고사 정리입니다.","archived":false,"fork":false,"pushed_at":"2023-06-12T14:52:17.000Z","size":521,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-06-18T13:58:25.447Z","etag":null,"topics":["cpm","criticalpath","software-engineering"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tpdlshdmlrkfmcla.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-05-15T13:11:53.000Z","updated_at":"2023-06-13T11:36:39.000Z","dependencies_parsed_at":"2023-06-17T12:00:48.782Z","dependency_job_id":null,"html_url":"https://github.com/tpdlshdmlrkfmcla/Software_Engineering_Finalexam","commit_stats":null,"previous_names":["chihyeonwon/software_engineering_finalexam","wonttan/software_engineering_finalexam","wonchihyeon/software_engineering_finalexam","chihyunwon/software_engineering_finalexam","mr-won/software_engineering_finalexam","user20252228/software_engineering_finalexam","tpdlshdmlrkfmcla/software_engineering_finalexam"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/tpdlshdmlrkfmcla/Software_Engineering_Finalexam","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpdlshdmlrkfmcla%2FSoftware_Engineering_Finalexam","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpdlshdmlrkfmcla%2FSoftware_Engineering_Finalexam/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpdlshdmlrkfmcla%2FSoftware_Engineering_Finalexam/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpdlshdmlrkfmcla%2FSoftware_Engineering_Finalexam/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tpdlshdmlrkfmcla","download_url":"https://codeload.github.com/tpdlshdmlrkfmcla/Software_Engineering_Finalexam/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tpdlshdmlrkfmcla%2FSoftware_Engineering_Finalexam/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28958341,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-31T22:20:19.638Z","status":"ssl_error","status_checked_at":"2026-01-31T22:18:07.061Z","response_time":128,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cpm","criticalpath","software-engineering"],"created_at":"2025-06-18T14:40:24.721Z","updated_at":"2026-01-31T22:32:27.803Z","avatar_url":"https://github.com/tpdlshdmlrkfmcla.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Software_Engineering_Finalexam\n소프트웨어공학 기말고사 정리입니다.\n임계영역(Critical Path)를 구하는 문제 출제\n[사이버국가고시센터](https://www.gosi.kr/)\n```\n시험 : 테스트 커버리지 예상문제, 수정\n\n8장 강의노트 \n\n결함 테스팅은 시스템 동작 중단, 시스템과의 원치 않는 상호작용, 잘못된 계산 및 데이터 손상과 바람직하지 않은 시스템 동작을 막는 것과 관련이 있음.\n\n첫 번째 목표는 검증 테스팅 : 테스트 케이스 집합을 이용하여 시스템이 정확하게 수행되는 것을 예상\n두 번째 목표는 결함 테스팅\n\n테스트 케이스 : 테스트를 위한 케이스별 입력과 예상 결과\n\n살충제 패러독스 : 동일한 테스트가 계속적으로 반복될 때 더 이상 새로운 버그를 발견하지 못하는 현상\n\n블랙박스 테스팅 : 입력과 결과 테스트 케이스를 작성\n\n검증(Verifiation) : 제품을 올바르게 만들고 있는가? product right?\n소프트웨어가 명세화된 기능적, 비기능적 요구사항을 만족하는지 검사\n확인(Validation) : 올바른 제품을 만들고 있는가? right product?\n소프트웨어가 고객의 기대를 만족하도록 보장하는 것\n\nV \u0026 V (검증과 확인) -\u003e 소프트웨어 시스템이 목적과 일치한다는 신뢰성을 확보\n\n소프트웨어 인스펙션 : 컴퓨터에서 실행시킬 필요가 없는 정적 V\u0026V 기술\n장점 : 오류 간의 상호작용에 대해 염려 X, 시스템이 비록 불완전하더라도 추가 비용없이 검사,\n프로그램의 결함뿐만 아니라 표준의 준수, 호환성, 유지보수에 대해서도 검토 가능\n문서 검토를 위한 정형 기법, 결함의 탐지가 목적\n\n소프트웨어 테스트 : 컴퓨터에서 실행시키는 동적 V\u0026V 기술\n명세서와 일치하는지를 점검 가능, 고객의 실제 기대를 만족하는 가는 점검 X\n성능, 유용성과 같은 비기능적 특성은 점검X\n\n인스펙션과 테스트 모두 V\u0026V 프로세스 동안 사용됨, 반대 성격의 검증 기술이 아님\n\n개발 테스팅\n단위(결함 테스팅) : 메소드, 클래스, 복합 컴포넌트\n컴포넌트\n시스템 테스팅\n\n자동화된 테스트 컴포넌트 : 설정(테스트 케이스(입력, 예상 출력), 호출(객체, 메서드 호출), 단언 부분(호출 결과를 예상결과와 비교, 참이면 성공, 거짓이면 실패)\n\n테스트 기법(요구사항 명세서에 기반을 둔 블랙박스 테스트와 구현에 기반을 둔 화이트박스 테스트로 구분)\n\n블랙박스 테스트 : 소프트웨어 내부의 로직, 알고리즘을 고려하지 않고 명세서에 기술되어 있는 소프트웨어의 동작을 토대로 실시하는 테스트, 입력데이터를 제공하여 실행결과만을 관측함으로써 오류를 찾는다.\n예 : 동등 분할법, 경곗값 분석법, 원인 결과 그래프 기법, 릴리스 테스팅, 기능 테스팅\n\n동등 분할법 : 무효한 입력을 주고 무효한 입력에 대한 반응으로 일어날 예외\n같은 범위에 속하는 입력 데이터에 대해 동일한 실행 결과를 얻을 수 있는 것\n\n경곗값 분석 : 경험적으로 많은 오류가 입력 데이터의 경곗값 근처에서 발생하고 있다고 알려져 있으므로 입력데이터로 경곗값과 경곗값으로부터 조금 떨어진 값을 사용\n\n테스트 케이스 설계 지침 : 버퍼 오버플로우가 일어나도록 설계, 같은 입력 또는 일련의 입력을 반복, 유효하지 않은 출력이 생성되도록, 계산 결과가 너무 크거나 작게 만든다.\n\n원인 결과 그래프 : 입출력의 인과간계를 원인 결과 그래프로 표현, \n\n화이트박스 테스트 : 테스트 케이스를 선정하는 기준이 필요, 프로그램을 커버하는 범위를 커버리지라고 함\n모든 경로를 실행하는 것이 목표지만 이를 모두 테스트하는 완전 경로 테스트는 사실상 불가능함\n예로 다양한 커버리지 기법, 기본 경로 테스트 기법 등\n\n문장 커버리지 : 프로그램 내의 모든 문장들을 한 번 이상 실행하도록 요구하는 기준\n테스트케이스를 결정하는 것이 수월, 분기와 반복과 같은 경우 오류를 못찾을 수도 있음\n일반적으로 사용하기에는 미흡한 기준\n\n분기 커버리지 : 결정 커버리지 : 각 결정문의 참과 거짓인 분기를 적오도 한 번 이상 실행하는 기준\n\n조건 커버리지 : 결정 내 존재 하는 각 조건들의 참과 거짓을 한 번 이상 실행하도록 하는 테스트 기법\n\n결정/조건 커버리지 : and, or에 따라 조건을 미리 판단하는 마스크가 발생\n\n다중조건 커버리지의 문제점 : 테스트 케이스의 수가 경로의 수보다 적어지는 루프 구조일 경우의 문제\n\n기본 경로 테스트 : 독립적인 경로 모두를 수행하는 것을 목적으로 하는 구조 테스트\n\n인터페이스 테스팅 지침, 오류 종류\n매개변수 : 널 포인터 매개변수를 가지고 테스트\n공유 메모리 : 컴포넌트 순서를 바꾸도록 설계 \n프로시저 : 호출될 때 컴포넌트가 실패하는 테스트 설계\n메시지 전달(스트레스 테스팅)\n\n인터페이스 오류 클래스 : 인터페이스 오용, 오해, 타이밍 오류\n\n시스템 테스팅 : 실제 시스템이 운영될 환경과 가장 가까운 환경으로 구축하고 명세서에 기술된 기능과  성능등이 구현되어 잇는지를 검사, 동작을 확인 - 크게 기능, 성능 테스트로 구분\n\n기능 : 명세서에 기술된 기능을 만족하는가\n성능 : 비기능적요구사항을 평가하기 위해 다양한 테스트를 실시\n시스템 테스팅 - 통합 테스트 \n\n통합 후 함께 동작하는 컴포넌트들이 바르게 호출되고 적절하게 데이터를 전달하는 지를 검사\n\n하향식 통합 - 시스템의 전체 골격이 먼저 개발되고 컴포넌트들이 추가\n상향식 통합 - 네트워크 및 데이터베이스 접근과 같은 공통적인 서비스를 통합하고 나서 기능 컴포넌트들을 추가\n\n하향식 테스트의 장점과 단점을 기술하라. (하위 : 스터브)\n프로그램 전체에 영향을 줄 가능성이 높은 상위 모듈 및 인터페이스의 오류를 조기 검출 가능\n일부가 완성되지 않아도 프로그램 전체의 개요를 테스트 가능\n\n단점 : 테스트의 초기 단계에서 작업의 분산화가 어렵다.\n\n상향식 테스트의 장점과 단점을 기술하라. (상위 : 드라이버)\n장점 : 초기 단계에서 병행적으로 여러 개의 모듈을 테스트 할 수 있다.\n\n단점 : 프로그램 전체에 영향을 줄 가능성이 높은 모듈 및 인터페이스의 오류의 발견이 지연\n\n혼합식 테스트 : 상향식, 하향식 테스트 기법을 혼합하여 각각의 장점을 결합하는 것을 목적으로 하는 테스팅 기법\n기본적으로는 하향식으로 통합하고 스터브의 작성이 곤란한 부분이나 하위에 존재하는 중요한 부분에 대해서 상향식으로 모듈을 통합해서 테스트하는 방식\n\n빅뱅 테스트 : 모든 모듈들을 개별적으로 테스트한 후에 각 모듈을 모두 한 번에 통합하는 테스팅\n소규모 프로그램이나 프로그램의 일부에 대해서 실시하는 경우가 많음\n\n점증적 통합과 테스팅 : 애자일 방법에서는 새로운 증분을 통합할 때마다 회귀 테스트 진행\n회귀 테스팅(regression testing) : 프로그램의 변경으로(증분의 통합으로) 새로운 버그가 생기지 않았는지 점검하기 위해 이전의 테스트를 다시 실행, 비용이 많이 드는 기법이라 자동화도구 JUnit의 지원이 없으면 비실용적이다.\n\n테스트 주도 개발(TDD) : 테스트는 코딩 이전에 작성되고 테스트를 통과해야만 개발이 진행됨\nXP와 같은 애자일 기법의 일부로 도입, 그러나 계획 주도 개발에서도 사용될 수 있음\n\n테스트 주도 개발(TDD)의 장점을 서술하라.\n코드 커버리지 : 작성하는 모든 코드 세그먼트에 대해서 하나 이상의 테스트가 있게 됨\n회귀 테스트 : 회귀 테스트 스위트는 프로그램이 개발됨에 따라 점증적으로 개발\n단순화된 디버깅 : 테스트가 실패하면 문제가 있는 것이 분명하므로 디버깅 도구가 불필요\n시스템 문서화 : 테스트 자체는 코드가 수행해야 하는 작업을 설명하는 문서 형식\n\n릴리스 테스팅 : 외부에서 사용할 시스템의 특정 릴리스를 테스팅하는 프로세스\n시스템이 시스템 공급자에게 확신시키는 목표이므로 오직 시스템 명세서로부터만 유도되는\n블랙박스 테스팅 프로세스이며 시스템 테스팅의 한 형태이다.\n\n릴리스 테스팅과 시스템 테스팅의 차이점을 설명하시오.\n릴리스 테스팅은 시스템이 요구사항과 일치하고 고객이 사용하기에 충분하다는 것을 보장하는 확인 점검 프로세스(검증 테스팅)에 해당하고\n개발팀에 의한 시스템 테스팅은 시스템에 있는 버그를 발견하는 데 집중하는 결함 테스팅이다.\n\n요구사항 기반 테스팅 : 요구사항을 검토하여 테스트를 설계하는 것\n시나리오 테스팅 : 전형적인 사용 시나리오를 만들어 이 시나리오를 테스팅 케이스르 개발하는데 사용\n기능 테스팅 : 시스템이 명세서를 만족하여 고객의 신뢰를 높이도록 하는 블랙박스 테스팅, 릴리스 테스트라고도 함\n성능 테스팅 : 애초에 설계된 이상으로 소프트웨어 시스템에 스트레스를 주는 것을 의미하므로 스트레스 테스팅이라고도 함, 네트워크를 기반으로 한 분산 시스템에서 특히 중요함\n사용자 테스팅 : 사용자 혹은 고객은 사용자나 고객이 입력을 제공하고 시스템 테스팅에 관한 조언을 하는 테스팅 프로세스의 한 단계, 알파, 베타, 인수테스팅이 있다.\n\n알파 : 사용자를 특정할 수 없는 경우 개발자가 사용자의 입장이 되어서 수행하는 알파 테스팅\n베타 : 잠재적 사용자들 중 일부에게 시험적으로 사용해보도록 하는 베타 테스팅\n인수 : 고객이 시스템을 테스트하는 인수 테스트\n\n애자일 기법에서 고객/사용자는 개발 팀의 일원이 되어 시스템의 수용가능성에 대한 의사결정을 담당\n테스트는 사용자/고객에 의해 정의된다. 고객/사용자가 이해관계자를 대표할 수 있어야 함\n\n9장 소프트웨어 진화\n\n브라운필드(brownfield) 소프트웨어 개발 : 오염되었거나 개발이 진행되지 않고 유휴지가 되고있는 상황\nHopkins, Jenkins는 소프트웨어 시스템이 다른 소프트웨어에 의존적인 환경에서 개발되고 관리되어야하는 상황을 나타내는 용어를 브라운 필드\n\n변경의 식별과 진화는 시스템 사용 기간 내내 계속됨\n\n개발과 진화의 중요한 차이를 서술하시오.\n변경 구현의 첫 번째 단계는 프로그램의 이해 즉 원래의 시스템 개발자는 변경 구현에 책임이 없다.\n\n긴급한 변경 요구가 있을 때는 어떻게 해야 하는가?\n긴급한 변경은 소프트웨어 공학 프로세스의 모든 단계를 거치지 않고 구현되어야 함\n\n진화는 빈번한 시스템 릴리스에 기반을 두는 개발 프로세스의 연속이다.\n\n인도(Handover) 문제란 무엇인가?\n개발팀이 애자일 기법을 사용했지만 진화팀은 애자일 기법이 익숙하지 않아 계획 기반 접근법을 선호하는 경우\n-\u003e 즉 개발팀과 진화팀의 기법 선호 차이를 나타냄\n\n개발팀(애자일기법) 진화팀(계획기반)일 때\n진화팀은 자동화된 테스트를 처음부터 시작, 시스템의 코드는 애자일 개발에서 예상하는 대로 리팩토링 수정되지 않을 수 있다.\n\n개발팀(계획기반) 진화팀(애자일기법)일 때\n진화팀은 진화를 위한 상세한 문서화를 기대하지만 애자일 프로세스에서는 지원되지 않음\n\n레거시 시스템(Legacy System)\n레거시 시스템은 새로운 시스템 개발에는 더 이상 사용되지 않는 언어와 기술에 의존하는 구형 시스템\n사회기술적 시스템: 기술적 시스템을 사용하거나 기술적 시스템과 상호작용하는 프로세스와 사람을 포함\n-\u003e 조직의 정책과 규칙에 의해 통제됨\n\n레거시 시스템의 계층 : 하드웨어 - 플랫폼 - 응용 - 비즈니스\n\n레거시 시스템의 경우 교체하는 데 비용이 너무 많이 들고 리스크가 너무 크기 때문에 비즈니스에서는 이 시스템을 계속 사용한다. \n\n레거시 시스템 교체가 위험한 이유를 서술하라.\n레거시 시스템은 완전한 명세서가 거의 없다.\n비즈니스 프로세스와 레거시 시스템이 서로 밀접하게 얽혀 동작하기 때문이다.\n새로운 시스템으로 교체하는 것은 본질적으로 위험이 따른다. 예상치 못한 문제, 즉 개발이\n지연되거나 예산을 초과할 수 있기 때문이다.\n프로그래밍 스타일에 일관성이 없다.\n데이터 오류, 중복 등등\n\n조직(회사)는 레거시 시스템을 진화시키기 위한 전략을 선택해야 한다.\n시스템을 완전히 폐기하고 새로운 시스템을 대체할 것인가.\n사용중이던 레거시 시스템의 유지보수를 계속할 것인가.\n유지보수성을 향상시키기 위해 시스템을 대체하기 보다 변환하는 시스템 재공학을 진행할 것인가.\n\n레거시 시스템의 분류 (품질과 비즈니스에 따른)\n\n낮은 품질, 낮은 비즈니스 가치\n-\u003e 이 시스템은 폐기되어야 함\n\n낮은 품질, 높은 비즈니스 가치\n-\u003e 유지보수 비용이 높음 -\u003e 재공학되거나 적절한 시스템을 쓸 수 있으면 대체\n\n높은 품질, 낮은 비즈니스 가치\nCOTS로 대체, 완전히 폐기하거나 유지\n\n높은 품질, 높은 비즈니스 가치\n정상적인 시스템 유지보수를 계속하며 계속 운영 결정.\n\n비즈니스 가치 평가는 상이한 관점을 고려해야함 상이한 이해당사자와 인터뷰 및 결과 분석을 통한\n\n비즈니스 가치 평가의 요소(이슈)\n시스템 이용 : 가끔 사용하거나 소규모 팀이 사용한다면 비즈니스 가치는 낮다고 볼 수 있다.\n지원되는 비즈니스 프로세스 : 비효율적인 비즈니스 프로세스를 이용한다면 가치는 낮다.\n시스템 확실성 : 만일 시스템이 믿을 수 없어 비즈니스 고객에게 직접 영향을 주면 가치는 낮다.\n시스템 출력 : 시스템의 출력에 비즈니스가 좌우된다면 시스템은 높은 비즈니스 가치를 가진다.\n\n특이하게 시스템 출력에 의해 좌우된다면 높은 비즈니스를 가진다.\n시스템 품질 평가\n비즈니스 프로세스 평가 : 비즈니스 프로세스가 비즈니스의 현재 목표를 얼마나 잘 지원하는가 ?\n환경 평가 : 시스템의 환경에 얼마나 효율적이고 유지하는데 얼마나 많은 비용이 소모되는가?\n애플리케이션 평가 : 애플리케이션 소프트웨어의 시스템의 품질은?\n\n비즈니스 프로세스 평가 방법\n-\u003e 시스템 이해당사자로부터 답을 찾기 위해 관점 지향 접근법을 이용\n\n관점 지향 접근법 (Viewpoint-Oriented approach)\n-\u003e 동일한 기능을 처리하기 위해 상이한 프로세스를 이용하는가 \n즉 어떤 시스템을 구현하는 데 있어서 동일한 기능(웹 기반 주문)이 이용된다면 낮은 비즈니스를 가진다고 \n판단하는 것이 관점 지향 접근법\n\n시스템 평가\n시스템 변경 요구 횟수가 많을 수록 시스템의 품질이 떨어짐\n인터페이스의 수가 많을수록 일관성이 없고 중복될 가능성이 있음\n이용하는 데이터의 양이 증가할 수록 데이터의 일관성이 떨어지고 오류가 있을 가능성이 높음\n오래된 데이터를 정리하는 일은 매우 비용이 많이 들고 시간을 소모하는 프로세스\n\n프로그램 진화 역학\n\nLehman의 법칙 : 프로그램이 유용한 상태로 유지되려면 지속적으로 변경되어야 한다.\n하지만 진화하는 프로그램이 변경됨에 따라 구조가 엉망이 된다.\n\n소프트웨어 유지보수 : 사용자에게 전달된 이후의 소프트웨어 변경 프로세스가 소프트웨어 유지보수\n변경은 기존 컴포넌트를 수정하고 시스템에 새로운 컴포넌트를 추가하는 것으로 구현된다.\n\n유지보수의 유형\n소프트웨어의 결함을 수리하기 위한 유지보수 -\u003e 수정 유지보수\n소프트웨어를 상이한 운영 환경에 적응하기 위한 유지보수 -\u003e 적응 유지보수 \n시스템의 기능을 추가하거나 수정하기 위한 유지보수 -\u003e 완전 유지보수\n장래의 유지보수성 혹은 신뢰성을 개선하거나 미리 예방 수단을 강구하는 유지보수 -\u003e 예방 유지보수\n\n수정, 적응, 완전, 예방 (비율은 완전 유지보수가 높다, 즉 새로운 기능을 추가하거나 수정하기 위한 유지보수가 제일 많은 비중을 차지 한다.)\n\n유지보수의 비용 : 대개 개발비용보다 크다. 기술적, 비기술적 요인 모두 영향을 받는다.\n유지보수를 하면 할수록 추가적인 유지보수를 더욱 어렵게 만든다.\n소프트웨어의 노후성에 따라 보수 비용이 높아질 수 있음\n\n복잡도 척도 : 제어구조, 데이터 구조, 객체, 메서드, 모듈의 크기\n프로세스 척도 : 수정, 유지보수 요청 횟수, 변경 요구를 구현하는데 걸리는 평균 시간\n\n소프트웨어 재공학 : 레거시 시스템의 일부 혹은 전체를 기능의 변경 없이 재구조화 혹은 재작성\n\n소프트웨어 재공학의 장점을 서술하라.\n새로운 소프트웨어를 개발하는 데 발생하는 인력 관리, 명세화 문제 등에서 리스크를 감소시킬 수 있다.\n또한 새로운 소프트웨어를 개발하는 비용보다는 재공학 비용이 훨씬 적다.\n\n재공학 프로세스 활동(재공학 안에 역공학이 있음)\n소스코드 변환 : 코드를 새로운 언어로 변환\n역공학 : 프로그램을 이해하기 위해 분석\n프로그램 구조 개선 \n프로그램 모듈화\n데이터 재공학\n\n리팩토링 : 변경에 따른 프로그램의 품질 저하를 늦추어 프로그램을 개선하는 프로세스\n미래의 변경 문제를 예방하는 예방 유지보수로 생각할 수 있음\n기능을 추가하기 보다 프로그램의 개선에 초점을 맞추어야 한다.\n\n리팩토링과 재공학의 차이 (적용되는 시기, 상황이 다름, 리팩토링은 프로세스 전반에 걸쳐서, 재공학은 유지보수 이후 거듭된 유지보수 비용 증가를 막기 위함)\n재공학은 시스템이 일정 시간 유지보수되고 나서 유지보수 비용이 증가하고 있을 때(유지보수 비용은 유지보수를 거듭할 수록 증가함) 발생한다. 유지보수성이 더 좋은 새로운 시스템으로 만들기 위해 레거시 시스템을 처리하고 재공학하는데 자동화 도구를 사용하는 것을 의미\n\n리팩토링은 개발 및 진화 프로세스 전반에 걸쳐 개선하는 지속적인 프로세스, 유지보수 비용과 유지보수의 어려움을 증가시키는 구조 및 품질의 저하를 방지하기 위함\n\n리팩토링과 재공학 모두 유지보수 비용을 낮추거나 유지보수성이 좋도록 개선하기 위한 방범임은 똑같다.\n\n프로그램 코드의 악취(Bad Smell)의 예는 무엇인가?\n\n중복 코드 : 동일하거나 매우 유사한 코드가 프로그램의 여러 곳에 포함되어 있음\n-\u003e 이렇게 중복되는 코드는 하나의 메서드나 함수로 구현하여 호출함으로써 제거\n\n길이가 긴 메서드 : 길이가 너무 긴 메서드는 다수의 짧은 메서드들로 재설계, 분할\n\nSwitch (case) 문 : 값의 타입에 의존하는 switch문은 종종 중복을 포함하게 된다.\n\n데이터 군집 : 데이터 항목의 동일한 그룹이 프로그램의 여러 곳에서 반복적으로 나타날 때\n-\u003e 모든 데이터를 캡슐화하는 객체로 만들어서 대체한다.\n\n추측에 근거한 일반성 : 개발자들이 앞으로 필요한 경우를 대비하여 프로그램의 일반성을 포함할 때 발생한다.\n\n22장 프로젝트 관리\n리스크 분류 기준 : 프로젝트, 제품, 비즈니스 리스크\n직원교체, 기술의 변화, 제품의 경쟁\n\n리스크 분석 : 리스크의 발생 가능성과 심각성을 평가\n리스크 관리 전략에는 어떤 것이 있는 가?\n리스크 회피 전략 : 위험이 발생할 가능성을 줄임\n최소화 전략 : 리스크의 영향을 줄임\n리스크 비상 계획 : 최악의 경우를 대비해 준비하고, 리스크를 다루는 전략\n\n리스크 감시(monitoring)\n리스크들이 발생할 가능성이 증가 또는 감소했는지를 판단하기 위해 정기적으로 평가\n리스크의 영향 정도가 변화했는 지에 대해 평가\n\n인간 관리\n인간 욕구의 계층 구조 : 생리적, 안전, 사회적 ,명예 욕구 -\u003e 자아 실현 욕구\n\n인간 관리의 방법의 예를 드시오.\n개인에 대한 동기를 부여한다.\n\n23장 프로젝트 계획 수립\n\n제안서 계획 수립 단계 : 시스템 가격 설정에 사용될 정보를 제공하는 것\n가격 책정에는 인건비, 하드웨어, 소프트웨어 비용 등을 고려하여 소프트웨어 개발 비용을 추정\n\n개발 계획 수립 : 프로그램 일정, 비용 추정 및 리스크를 정기적으로 수정\n\n프로젝트 일정관리 활동 : 프로젝트를 작업으로 나누고 각 작업을 완료하는 데 필요한 시간과 자원을 예측, 작업 종속성을 최소화하여 다른 작업이 완료되기를 기다리는 동안 발생하는 지연을 방지\n\n일정관리 문제 : 지연된 프로젝트에 사람을 추가하는 것은 나중에 소통의 오버헤드 때문에 더 지연되게 만듬\n-\u003e Brooks의 법칙\n\n프로젝트 액티비티(활동)\n프로젝트 액티비티는 가장 기본적인 계획 수립요소\n작업을 완료하기 위한 person-days 또는 person-months로 나타내는 노력 추정치\n액티비티가 완료되어야 하는 마감일(deadline)\n정의된 종료점\n\n이정표(Milestone)은 프로세스 활동의 종료점\n산출물(Deliverables)는 고객에게 전달되는 프로젝트 결과\n폭포수 모델은 진척 사항에 관한 이정표의 직접적인 정의를 가능하게 함\n\n임계경로(Critical Path) : 액티비티 네트워크의 가장 긴 경로\n임계경로 상의 작업은 지연되면 문제가 발생하지만 T8과 같이 임계 경로 상의 작업이 아니므로 전체 일정에 무영향\n\n바차트(간트 차트) : Slack time(여유 시간) 파란색\n\n\n\n\nA-B-D-F-G-I = 7+5+4+15+12 = 43\nA-B-D-H-I = 7+5+4+10 = 26\n\nA-C-D-F-G-I = 7+10+4+15+12 = 48\nA-C-D-H-I = 31\n\nA-C-E-F-G-I = 7+10+6+15+12 = 50\nA-C-E-H-I = 7+10+6+10 = 33\n\n임계 경로 CPM = 50 (가장 긴 경로)\n\n임계 경로가 중요한 이유 1가지 서술 : CPM 임계 경로를 구하는 방법은 작업의 개발기간을 하나의 숫자로 확정적으로 예측이 가능하다.\n\n\n애자일 계획 수립 : 이터레이션(짧은 개발 주기의 반복)　: 일일 스크럼\n\n애자일 계획 수립 단계 : 릴리스 계획 수립 : 수개월 앞을 내다보고 시스템 릴리즈에 포함되어야 하는 기능들에 대한 결정들을 함\n\n반복 계획 수립 : 단기 전망을 가지고 시스템의 다음 증분에 대한 계획 수립에 집중\n\n작업 할당 : 작업 계획 수립 단계 동안 개발자들이 스토리를 개발 작업으로 분할\n\n소프트웨어 인도 : 소프트웨어 증분은 각 프로젝트 반복이 끝날 때에 항상 인도됨\n증분이 허용된 시간 내에 완료될 수 없으면 작업 범위를 축소\n인도 일정은 결코 연장되지 않음\n\n추정 기법 : 소프트웨어 개발 비용(노력, 공수)를 추정할 필요가 잆음\n경험에 기반한 기법 : 과거 프로젝트의 경험과 이러한 프로젝트에서 소요된 노력에 기초함\n문제점 : 새로운 소프트웨어 프로젝트가 이전 프로젝트와 비슷하지 않을 때, 개발 기술이 빠르게 변화하므로 이러한 기술에 익숙하지 않을 경우, 과거의 경험은 노력 추적에 도움이 되지않고 더 어려워진다.\n\n알고리즘 비용 산정 모델 : 노력은 관리자가 추정하는 제품, 프로젝트, 프로세스 속성의 수학 함수를 이용하여 추정됨\n\nEffort = A *　Size의 B승 * M\n\nA는 상수, Size는 규모 추정치, B는 비경제 반영 지수, M은 제품 프로세스 인간 속성을 반영\n\nCoCoMo 비용 산정 모델 : Bohem에 의해 발표된 알고리즘 모델\n규모는 KDSI으로 추정 \n공수(Person Month) = a(KDSI)의 b승\n프로젝트의 유형에 따라 적용 식이 다름\n\nCOCOMO 2는 소프트웨어 개발, 재사용 등에 상이한 접근법을 적용\n\n초기 설계 모델 : PM = A * Size의 B승 * 승수 M(비용 인자)\n\nA=2.94 Size-\u003eKLOC(코드규모), 지수항 B(1.1~1.24사이에서 결정), \nM(승수) : 개발자, 비기능적 요구사항, 개발 플랫폼의 친숙성 등을 반영\n\n포스트 아키텍처 모델 : 초기 설계 모델과 동일한 식, 승수가 17개로 더 많음\n코드 규모 KLOC의 추정 방식 : 코드의 라인 수(새로운 코드의 라인 수)\n지수항 B -\u003e 1.17\n\n25장 형상 관리 \n\n소프트웨어 시스템의 새로운 버전은 다음의 경우에 작성\n1. 상이한 기계나 운영체제를 위해\n2. 상이한 기능의 제공\n3. 특정 사용자 요구사항에 맞추기 위해\n형상관리는 진화하는 소프트웨어 시스템과 관련됨\n1. 시스템 변경은 팀 단위의 활동\n2. 형상 관리는 시스템에 대한 변경에 포함된 비용과 노력을 관리하는 것이 목적임\n진화하는 소프트웨어 제품을 관리하기 위한 절차와 표준을 개발하고 적용하는 것을 포함\n형상 관리는 더욱 일반적인 품질 경영 프로세스의 일부일 수 있음\n형상 관리에 릴리스될 때, 소프트웨어 시스템은 때때로 추가적인 개발의 출발점으로써\n기준점(baselines)이라고 부름\n\n추가적인 개발의 출발점 -\u003e 기준점(baseline) 베이스라인\n\n형상관리 표준\n형상 관리는 조직 내에 적용되는 표준의 집합에 항상 기초\n표준은 항목들이 어떻게 식별되고, 변경이 어떻게 제어되며, 새로운 버전들이 어떻게 관리되는지를 정의\n표준은 외부의 형상 관리 표준(예 : 형상관리를 위한 IEEE표준)에 기초할 수 있음\n일부 기존의 표준들은 폭포수 프로세스 모델에 기초하므로, 진화적인 개발을 위한 새로운 형상 관리 표준이 필요\n\n빈번한 시스템 구축\n프로세스의 초기에 컴포넌트 간의 상호작용을 통해 나오는 문제를 찾기가 더 쉬움\n이것은 단위 테스트를 통해 장려됨\n발견되고 수정된 문제들을 추적하기 위한 엄격한 변경 관리 프로세스가 요구\n\n형상 관리 활동\n형상 식별(Identification) : 형상 관리를 할 항목을 식별하는 것\n형상 제어(Control) : 형상에 대한 변경요청이 있을 경우, 변경 여부와 활동을 통제하는 것\n형상 상태보고(Status Accounting) : 형상 변경에 대한 내용을 기록하고 보고하는 것\n형상 감사(Audit) : 형상 항목이 요구사항에 맞도록 잘 변경되었는지를 확인하는 것\n\n식별(Identification), 제어(Control), 상태보고(Status Accounting), 감사(Audit)\n\nCCB 형상 통제 위원회(Configuration Control Board)\n\n애자일 개발과 CM\n하루에도 몇 번씩 컴포넌트와 시스템이 변경되는 애자일 개발은 CM 툴을 사용하지 않고는 불가능\n컴포넌트의 최종 버전은 공유 프로젝트 저장소에 보관되며 개발자들은 이를 자신의 작업공간에 복사\n개발자들은 코드를 변경한 다음 테스팅을 위해 시스템 구축 도구를 사용하여 자신의 컴퓨터에 새로운 시스템을 생성\n일단 변경사항이 만족되면 수정된 구성요소를 프로젝트 리포지토리에 반영\n\n멀티 버전 시스템 \n대형 시스템의 경우, 단 하나의 '동작' 버전이 있는 것은 아님\n서로 다른 개발 단계에서 시스템의 여러 버전이 항상 존재\n상이한 시스템 버전들의 개발에 여러 팀이 관련됨\n\n큰 번호(버전 번호), 작은 번호(릴리스 번호)\n개발할 때 수정하는 건 버전번호 -\u003e 사용자에게 릴리즈되는 번호가 다르다.\n코드라인과 베이스 라인\n코드라인은 소스 코드의 일련의 버전들이고, 나중 버전들은 이전의 버전들로부터 유도됨\n일반적으로 코드라인은 시스템의 컴포넌트들에 적용되므로 각 컴포넌트의 상이한 버전들이 존재\n베이스라인은 특정 시스템의 정의\n따라서 시스템에 포함되는 컴포넌트 버전들을 명시하고 사용된 라이브러리, 설정 파일 등을 명시함\n베이스라인은 시스템의 특정 버전에 어떤 컴포넌트들이 포함되어야 하는 지를 정의한 형상 언어를 사용하여 명시될 수 있음\n베이스 라인은 완성된 시스템의 특정 버전을 종종 다시 생성해야 하므로 중요\n예를 들어, 어떤 고객이 사용하고 있는 시스템에서 오류를 발견하고 신고하면, 수정 작업을 위해 고객에게 인도되었던 시스템 버전을 다시 생성\n코드라인이 모여서 베이스라인\n베이스라인이 모여서 메인라인\n\n코드라인과 베이스라인 메인라인 그림을 채워넣는 문제 출제\n\n코드라인\nA -\u003e A1.1 -\u003e A1.2 -\u003e A1.3 (Codeline A)\nB -\u003e B1.1 -\u003e B1.2 -\u003e B1.3 (Codeline B)\nC -\u003e C1.1 -\u003e　C1.2 -\u003e C1.3 (Codeline C)\n\n라이브러리나 외부 컴포넌트\nL1, L2, Ex1, Ex2\n\n베이스라인은 이런 코드라인과 라이브러리, 외부 컴포넌트들 중에 선택해서 합치면 베이스라인\n\n베이스라인의 묶음을 메인라인\n\n버전 관리\n버전 관리는 코드라인과 베이스라인을 관리하는 프로세스다.\n버전관리는 소프트웨어 컴포넌트들과 이 컴포넌트들이 사용되는 시스템의\n여러 버전들을 추적 관리하는 프로세스\n또한 이런 버전들에 대해 여러 개발자들이 수행하는 변경 작업이 서로 방해받지 않도록 하는 것을 포함\n\n버전 관리 시스템\n버전 관리(VC) 시스템은 컴포넌트의 여러 버전들을 식별,저장,접근 제어를 함.\n현대 버전 관리 시스템의 두가지 유형\n중앙집중 시스템 : Subversion\n분산 시스템 : Git\n버전과 릴리즈를 식별\n변경 이력 기록\n독립적인 개발\n프로젝트 지원\n저장소 관리\n\n\n공용 저장소와 개인 작업공간\n컴포넌트를 수정할 때, 개발자는 컴포넌트를 저장소에서 자신의 작업공간으로 복사(check-out)하고, 이 복사본에 대해 작업을 수행\n개발자가 변경 작업을 완료하면, 변경된 컴포넌트들을 저장소로 반납(check-in)\n여러 사람이 동시에 한 컴포넌트에 대해 작업하면, 각각은 저장소로부터 컴포넌트에 대해 체크아웃해야 함, 만약 어떤 컴포넌트가 체크아웃되었으면, VC 시스템은 해당 컴포넌트의 체크아웃을 원하는 사용자에게 이미 누군가에 의해 체크아웃되었음을 경고\n\n분산 버전 관리\n마스터 저장소가 개발팀에 의해 생성되는 코드를 유지하는 서버에 생성\n필요한 파일들의 단순한 체크아웃 대신 개발자는 프로젝트 저장소의 사본을 생성하여 자신의 컴퓨터에 설치\n개발자는 자신의 컴퓨터에 설치된 개인 저장소에서 필요한 파일 작업을 수행하고, 새로운 버전을 유지\n변경이 끝나면 commit을 통해 이 변경이 반영되어 개인이 저장소가 변경, 그 다음 개발자는 이 변경들이 프로젝트 저장소에 반영되도록 push\n분산 버전관리의 장점\n1. 저장소에 대해 백업 매커니즘을 제공\n2. 네트워크 연결이 되지 않는 상황에서도 개발자들은 변경이 반영되도록 할 수 있음\n3. 프로젝트 작업 지원 : 개발자들은 자신의 컴퓨터에서 전체 시스템을 컴파일하고 테스트할 수 있으며, 자신이 수행한 변경에 대한 테스트를 할 수 있음\n\n오픈 소스 개발\n분산 버전 관리는 오픈 소스 개발에 필수적\n개발자들은 자신의 컴퓨터에 있는 개인 저장소뿐만 아니라 공용 서버 저장소도 유지하여, 자신들이 변경한 컴포넌트들의 새 버전들을 서버 저장소로 내보냄(push) 그 다음 언제 이런 변경들을 최종 프로젝트 저장소로 가져올지 pull 결정하는 것은 오픈 시스템의 관리자가 결정\n코드라인은 분기되고 합병될 수 있다.\n\n시스템 구축\n시스템을 구성하는 소스파일이나 데이터 파일, 라이브러리들을 컴파일하고 링크해서 실행 가능한 하나의 주 시스템을 만드는 것이 시스템 구축이라고 한다.\n자동화된 빌드 시스템(컴파일러, 구축 스크립트들)\n\n개발, 구축, 타겟 플랫폼\n개발할 때 사용하는 -\u003e 개발 시스템\n버전관리 및 빌드서버 -\u003e 구축 시스템\n타겟 시스템\n\n지속적인 통합\n그림을 보고 무엇을 뜻하는 가? Continueous Integretion : 지속적인 통합 \n대표적인 도구로 Jenkins이 있습니다.\n개발하다가 변경사항을 반영하고 구축하고 테스트한다음에 새로운 베이스라인으로 반영한다.\n\n소스 코드와 목적 코드의 링킹\n\n자바 파일(.java) 컴파일하면 클래스 파일이 나오는데 이 클래스 파일이\n자바 파일이 수정된 자바 파일의 클래스 파일은 아니기 때문에 클래스 파일이\n어떤 자바 파일의 클래스 파일인지를 알기 위해서 타임스탬프를 사용할 수 있다.\n타임 스탬프(언제 컴파일되었는지)가 맞는 것이 자바 - Time Based identification\n자바 - 클래스 파일마다 다른 체크섬을 비교한다. - Cheksum Based identification\n\n변경 관리 프로세스\n변경하고 나서 얻는 결과를 예측하고 비용이 많이 들어가는 변경은 줄이고 \n어떤 컴포넌트가 변경되었는지를 추적하는 프로세스가 변경 관리 프로세스이다.\nChange Request 변경 요청을 하면 변경을 체크하고 변경이 유효하면 변경을 등록,\n소프트웨어 수정을 하는 개발 및 테스트 진행하고 변경을 적용한다.\n형상관리 위원회 CCB에서 최종적으로 베이스라인에 반영할지를 결정한다.\n\n릴리스 계획에 영향을 미치는 요인들\n경쟁 : 대중 시장 소프트웨어인 경우 시장 점유 확보를 위해 릴리스\n마케팅 요구 :  마케팅 부서의 요구에 맞춰서 릴리스\n플랫폼 변화 : 운영체제 플랫폼의 새로운 버전의 릴리스\n시스템의 기술적 변화 : 시스템의 심각한 결함이 보고\n\n\n```\n## 형상 관리\n```\n소프트웨어 시스템의 새로운 버전은 다음의 경우에 작성\n1. 상이한 기계나 운영체제를 위해\n2. 상이한 기능의 제공\n3. 특정 사용자 요구사항에 맞추기 위해\n\n형상관리는 진화하는 소프트웨어 시스템과 관련됨\n1. 시스템 변경은 팀 단위의 활동\n2. 형상 관리는 시스템에 대한 변경에 포함된 비용과 노력을 관리하는 것이 목적임\n\n진화하는 소프트웨어 제품을 관리하기 위한 절차와 표준을 개발하고 적용하는 것을 포함\n형상 관리는 더욱 일반적인 품질 경영 프로세스의 일부일 수 있음\n형상 관리에 릴리스될 때, 소프트웨어 시스템은 때때로 추가적인 개발의 출발점으로써\n기준점(baselines)이라고 부름\n\n형상관리 표준\n\n형상 관리는 조직 내에 적용되는 표준의 집합에 항상 기초\n표준은 항목들이 어떻게 식별되고, 변경이 어떻게 제어되며, 새로운 버전들이 어떻게 관리되는지를 정의\n표준은 외부의 형상 관리 표준(예 : 형상관리를 위한 IEEE표준)에 기초할 수 있음\n일부 기존의 표준들은 폭포수 프로세스 모델에 기초하므로, 진화적인 개발을 위한 새로운 형상 관리 표준이 필요\n```\n\n## 빈번한 시스템 구축\n```\n프로세스의 초기에 컴포넌트 간의 상호작용을 통해 나오는 문제를 찾기가 더 쉬움\n이것은 단위 테스트를 통해 장려됨\n발견되고 수정된 문제들을 추적하기 위한 엄격한 변경 관리 프로세스가 요구\n```\n\n## 형상 관리 활동\n```\n형상 식별(Identification) : 형상 관리를 할 항목을 식별하는 것\n형상 제어(Control) : 형상에 대한 변경요청이 있을 경우, 변경 여부와 활동을 통제하는 것\n형상 상태보고(Status Accounting) : 형상 변경에 대한 내용을 기록하고 보고하는 것\n형상 감사(Audit) : 형상 항목이 요구사항에 맞도록 잘 변경되었는지를 확인하는 것\n```\n\n## CCB 형상 통제 위원회(Configuration Control Board)\n\n## 형상 관리(CM)\n```\nCM이 필요한 이유는 버전에 어떤 변경과 컴포넌트 버전에 포함되었는 지를 놓치기 쉽다.\nCM은 상이한 개발자에 의해 수행된 변경을 관리하기 위해 팀 프로젝트에 필수\n```\n\n## 애자일 개발과 CM\n```\n하루에도 몇 번씩 컴포넌트와 시스템이 변경되는 애자일 개발은 CM 툴을 사용하지 않고는 불가능\n\n컴포넌트의 최종 버전은 공유 프로젝트 저장소에 보관되며 개발자들은 이를 자신의 작업공간에 복사\n\n개발자들은 코드를 변경한 다음 테스팅을 위해 시스템 구축 도구를 사용하여 자신의 컴퓨터에 새로운 시스템을 생성\n\n일단 변경사항이 만족되면 수정된 구성요소를 프로젝트 리포지토리에 반\n```\n\n## 멀티 버전 시스템\n```\n대형 시스템의 경우, 단 하나의 '동작' 버전이 있는 것은 아님\n서로 다른 개발 단계에서 시스템의 여러 버전이 항상 존재\n상이한 시스템 버전들의 개발에 여러 팀이 관련됨\n```\n\n## 큰 번호(버전번호) 작은 번호(릴리스 번호)\n```\n개발할 때 수정하는 건 버전번호 -\u003e 사용자에게 릴리즈되는 번호가 다르다.\n```\n## 코드라인과 베이스 라인\n```\n코드라인은 소스 코드의 일련의 버전들이고, 나중 버전들은 이전의 버전들로부터 유도됨\n\n일반적으로 코드라인은 시스템의 컴포넌트들에 적용되므로 각 컴포넌트의 상이한 버전들이 존재\n\n베이스라인은 특정 시스템의 정의\n\n따라서 시스템에 포함되는 컴포넌트 버전들을 명시하고 사용된 라이브러리, 설정 파일 등을 명시함\n\n베이스라인은 시스템의 특정 버전에 어떤 컴포넌트들이 포함되어야 하는 지를 정의한 형상 언어를 사용하여 명시될 수 있음\n\n베이스 라인은 완성된 시스템의 특정 버전을 종종 다시 생성해야 하므로 중요\n예를 들어, 어떤 고객이 사용하고 있는 시스템에서 오류를 발견하고 신고하면, 수정 작업을 위해 고객에게 인도되었던 시스템 버전을 다시 생\n\n코드라인이 모여서 베이스라인\n베이스라인이 모여서 메인라인\n```\n## 버전 관리\n```\n버전 관리는 코드라인과 베이스라인을 관리하는 프로세스다.\n버전관리는 소프트웨어 컴포넌트들과 이 컴포넌트들이 사용되는 시스템의\n여러 버전들을 추적 관리하는 프로세스\n또한 이런 버전들에 대해 여러 개발자들이 수행하는 변경 작업이 서로 방해받지 않도록 하는 것을 포함\n```\n## 버전 관리 시스템\n```\n버전 관리(VC) 시스템은 컴포넌트의 여러 버전들을 식별,저장,접근 제어를 함.\n현대 버전 관리 시스템의 두가지 유형\n\n중앙집중 시스템 : Subversion\n분산 시스템 : Git\n\n버전과 릴리즈를 식별\n변경 이력 기록\n독립적인 개발\n프로젝트 지원\n저장소 관리\n```\n## 공용 저장소와 개인 작업공간\n```\n컴포넌트를 수정할 때, 개발자는 컴포넌트를 저장소에서 자신의 작업공간으로 복사(check-out)하고, 이 복사본에 대해 작업을 수행\n개발자가 변경 작업을 완료하면, 변경된 컴포넌트들을 저장소로 반납(check-in)\n\n여러 사람이 동시에 한 컴포넌트에 대해 작업하면, 각각은 저장소로부터 컴포넌트에 대해 체크아웃해야 함, 만약 어떤 컴포넌트가 체크아웃되었으면, VC 시스템은 해당 컴포넌트의 체크아웃을 원하는 사용자에게 이미 누군가에 의해 체크아웃되었음을 경고\n```\n## 분산 버전 관리\n```\n마스터 저장소가 개발팀에 의해 생성되는 코드를 유지하는 서버에 생성\n필요한 파일들의 단순한 체크아웃 대신 개발자는 프로젝트 저장소의 사본을 생성하여 자신의 컴퓨터에 설치\n개발자는 자신의 컴퓨터에 설치된 개인 저장소에서 필요한 파일 작업을 수행하고, 새로운 버전을 유지\n변경이 끝나면 commit을 통해 이 변경이 반영되어 개인이 저장소가 변경, 그 다음 개발자는 이 변경들이 프로젝트 저장소에 반영되도록 push\n\n분산 버전관리의 장점\n1. 저장소에 대해 백업 매커니즘을 제공\n2. 네트워크 연결이 되지 않는 상황에서도 개발자들은 변경이 반영되도록 할 수 있음\n3. 프로젝트 작업 지원 : 개발자들은 자신의 컴퓨터에서 전체 시스템을 컴파일하고 테스트할 수 있으며, 자신이 수행한 변경에 대한 테스트를 할 수 있음\n```\n## 오픈 소스 개발\n```\n분산 버전 관리는 오픈 소스 개발에 필수적\n개발자들은 자신의 컴퓨터에 있는 개인 저장소뿐만 아니라 공용 서버 저장소도 유지하여, 자신들이 변경한 컴포넌트들의 새 버전들을 서버 저장소로 내보냄(push) 그 다음 언제 이런 변경들을 최종 프로젝트 저장소로 가져올지 pull 결정하는 것은 오픈 시스템의 관리자가 결정\n\n코드라인은 분기되고 합병될 수 있다.\n```\n## 시스템 구축\n```\n시스템을 구성하는 소스파일이나 데이터 파일, 라이브러리들을 컴파일하고 링크해서 실행 가능한 하나의 주 시스템을 만드는 것이 시스템 구축이라고 한다.\n\n자동화된 빌드 시스템(컴파일러, 구축 스크립트들)\n```\n## 개발, 구축, 타겟 플랫폼\n```\n개발할 때 사용하는 -\u003e 개발 시스템\n버전관리 및 빌드서버 -\u003e 구축 시스템\n타겟 시스템\n```\n## 지속적인 통합\n```\n그림을 보고 무엇을 뜻하는 가? Continueous Integretion : 지속적인 통합 \n대표적인 도구로 Jenkins이 있습니다.\n\n개발하다가 변경사항을 반영하고 구축하고 테스트한다음에 새로운 베이스라인으로 반영한다.\n```\n## 소스 코드와 목적 코드의 링킹\n```\n자바 파일(.java) 컴파일하면 클래스 파일이 나오는데 이 클래스 파일이\n자바 파일이 수정된 자바 파일의 클래스 파일은 아니기 때문에 클래스 파일이\n어떤 자바 파일의 클래스 파일인지를 알기 위해서 타임스탬프를 사용할 수 있다.\n타임 스탬프(언제 컴파일되었는지)가 맞는 것이 자바 - Time Based identification\n\n자바 - 클래스 파일마다 다른 체크섬을 비교한다. - Cheksum Based identification\n```\n\n## 변경 관리 프로세스\n```\n변경하고 나서 얻는 결과를 예측하고 비용이 많이 들어가는 변경은 줄이고 \n어떤 컴포넌트가 변경되었는지를 추적하는 프로세스가 변경 관리 프로세스이다.\n\nChange Request 변경 요청을 하면 변경을 체크하고 변경이 유효하면 변경을 등록,\n소프트웨어 수정을 하는 개발 및 테스트 진행하고 변경을 적용한다.\n\n형상관리 위원회 CCB에서 최종적으로 베이스라인에 반영할지를 결정한다.\n```\n## 릴리스 계획에 영향을 미치는 요인들\n```\n경쟁 : 대중 시장 소프트웨어인 경우 시장 점유 확보를 위해 릴리스\n마케팅 요구 :  마케팅 부서의 요구에 맞춰서 릴리스\n플랫폼 변화 : 운영체제 플랫폼의 새로운 버전의 릴리스\n시스템의 기술적 변화 : 시스템의 심각한 결함이 보고\n```\n## 보안성 공학\n```\n애플리케이션 시스템의 보안을 명세화하고 설계하는 데 초점을 맞추어 보안\n\n사용자 및 허가 관리, 시스템 소프트웨어 배치와 유지보수, 공격 감시, 탐지 및 복구\n```\n## 보안 위험 관리\n```\n위험 평가 -\u003e 시스템 획득 결정 이전에 시작하여 개발 프로세스 동안 계속되는 단계적 프로세스이다.\n\n위험 평가의 단계적 프로세스 : 사전 위험 평가, 생명주기 동안의 위험 평가\n\n사전 위험 평가 : 전체 시스템에 관한 보안 요구사항을 유도하는 것\n사전 위험 평가의 필수 단계\n\n자산 식별 -\u003e 보호할 필요성이 있는 시스템 자산인가?\n\n생명주기 위험 평가 : 보호되어야 할 필요성이 있는 것에 대한 더욱 상세한 정보를 알게되고\n시스템의 취약점에 관해 알게 된다. 시스템 아키텍처와 데이터 구성에 관한 지식을 활용하면서\n기술 선택에 관련된 취약점의 예시를 들 수 있다는 것이 사전 위험 평가와의 중요한 차이점이다.\n```\n## 보안을 위한 설계\n```\n1. 아키텍처 설계 : 어떤 아키텍처 설계 결정이 시스템의 보안에 영향을 미치는가?\n2. 좋은 실무 관행(설계 지침) : 안전한 시스템을 설계할 때 받아들일 만한 좋은 실무 관행은 무엇인가?\n3. 배치를 위한 설계 : 시스템이 사용을 위해 배치될 때 어떤 취약점이 있는가?\n\n보안을 유지하는 시스템 아키텍처 설계 시 고려사항\n보호 (protection) : 시스템이 어떻게 구성되어야 중요한 자산이 외부 공격에 보호될 수 있는 가?\n분산 (distribution) : 시스템 자산이 어떻게 분산되어야 공격의 영향을 최소화할 수 있는 가?\n\n계층 아키텍처 \u003c- 중요한 자산을 낮은 수준에 두고 그 주위에 다양한 보호 계층을 두는 계층아키텍처가 \n보안에 적합한 아키텍처이다.\n\n데이터 보호가 중요한 요구사항이라면 서버에 구축된 보호 메커니즘을 가진 클라이언트-서버 아키텍처를 사용한다.\n\n서비스 거부 공격이 주요위험이라면 애플리케이션 시스템을 위한 분산 객체 아키텍처를 사용할 수 있다.\n\n정답 -\u003e 계층, 클라이언터-서버, 분산 객체 아키텍처\n\n계층마다 요구하는 수준의 보호를 두어 계층화된 보호 아키텍처를 둔다.  \n애\n```\n## 시스템 복원성\n```\n시스템 복원성 : 시스템이 공격을 받았거나, 혹은 공격이나 시스템 장애의 결과로 부분적으로 손상을 입은 후 필수적인 비즈니스 중심 서비스나 임무 중심 서비스를 합법적인 사용자에게 계속적으로\n제공하는 능력을 말한다.\n\n가용성을 유지하는 것이 복원성의 핵심이다.\n인식, 저항, 복구, 회복\n\n네 단계 프로세스 : 시스템 이해, 중요한 서비스 식별, 공격 모의실험, 생존가능성 분\n```\n## 소프트웨어 재사용 대상\n```\n시스템 재사용\n애플리케이션 재사\n컴포넌트 재사용\n객체와 함수 재사용\n```\n## 소프트웨어 재사용\n```\n대부분의 공학 분야에서, 다른 시스템에서 이용된 기존의 컴퓨터를 결합하는 방식으로 설계가 이루어짐\n소프트웨어 공학은 원점에서 개발하는 것에 초점을 맞추어왔으나 현재는 체계적인 소프트웨어 재사용에 기반을 둔 설계 프로세를 채택하는 것이 필요하다는 인식을 하게 됨\n```\n## 소프트웨어 재사용 장점\n```\n소프트웨어를 재사용했을 때 얻는 장점을 서술하라.\n\n가속화 개발\n전문가의 효과적인 활용\n신뢰성 증가\n낮은 개발 비용\n프로세스 리스크 감소\n표준 준수\n```\n\n## 소프트웨어 재사용 문제점\n```\n컴포넌트 라이브러리의 생성, 유지보수 및 사용\n재사용 컴포넌트의 검색, 이해 및 적용\n유지보수 비용 증가 : 재사용되는 컴포넌트들은 바이너리코드 즉 소스코드가 없기 때문에 유지보수할 때 어려운 점이 발생한다.\n지원 도구의 부족\nNIH (not-invented-here) 증후군 : 부분적으로 신뢰와 관계가 있고, 부분적으로 소프트웨어를 처음부터 \n작성하는 것은 다른 사의 소프트웨어를 재사용하는 것보다 더 도전적인 것으로 인식된다는 사실과 관계\n(내가 개발한 건 믿는데 남이 개발한 건 찝찝하다, 신뢰의 문제가 발생)\n```\n\n## MVC 패턴 (Model View Controller)\n```\n사용자 입력 -\u003e(컨트롤러 상태) -\u003e 모델 수정(모델 상태) \u003c-\u003e 뷰 상태\n```\n\n## 프레임워크의 제어 역전(역행)\n```\nhook 메서드 -\u003e 마우스클릭을 처리하는 메서드\n이 메서드는 애플리케이션의 적절한 애플리케이션의 특화클래스를 호출하도록 설계해야 한다.\n\n특화된 애플리케이션 컴포넌트 안에 설정 가능한 애플리케이션 컴포넌트 안에 핵심 컴포넌트\n```\n\n## 제품 라인을 위한 기반 시스템의 설정\n```\n도메인의 핵심, 고유한 컴포넌트 라인을 제품 라인이라고 한다.\n제품 라인을 위한 기반 시스템을 설정할 때는 해당 도메인의 공통적인 핵심 컴포넌트를 설정하고\n설정가능한 애플리케이션 컴포넌트, 설정 x 특화된 애플리케이션 컴포넌트\n```\n\n## 자원 관리 시스템의 아키텍처\n```\n자원 관리 시스템의 제품 라인은 다음과 같다.\n\n상호작용 : 사용자 인터페이스\nI/O 관리 : 사용자 인증, 자원 관리, 쿼리 관리\n자원 관리 \n데이터베이스 관리\n```\n## 제품 인스턴스 개발\n```\n이해당사자 요구사항 추출 -\u003e 최적의 시스템 인스턴스의 선택 -\u003e 요구사항재조정 or 기존 시스템 적응 -\u003e 신규 시스템 인스턴스 제공\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftpdlshdmlrkfmcla%2Fsoftware_engineering_finalexam","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftpdlshdmlrkfmcla%2Fsoftware_engineering_finalexam","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftpdlshdmlrkfmcla%2Fsoftware_engineering_finalexam/lists"}