In University ☆ In Bucket Place ☆ Hobby & Study Room ☆

* Risk Management - Risk : 원하지 않은 현상이 발생한 것 - 리스크를 미리 식별하고, 위험에 의해서 발생하는 영향력을 최소화하기 위한 관리기법 - Risk category ⓐ Project risks : schedule or resources / 일정 또는 자원 상의 위험성 ex) 사원이 일을 그만 두거나 이직, PM의 교체 ⓑ Product risks : Quality or Performance / 품질 또는 성능 상의 위험성 ex) 툴의 기능이 생각보다 적을 경우 ⓒ Business risks : 조직에서의 커다란 변화 및 사회의 흐름 변화 ex) 기술의 변화 - Risk management process ⓐ Risk identification : 리스크 식별 ⓑ Risk ana..

* Milestones and deliverables - Milestones : 프로젝트 수행간 기억할 만한 날 - Deliverables : Milestones의 결과물로 고객에게 전달되는 결과물 * Project scheduling (프로젝트 일정) - 프로젝트 일정은 Task단위로 분할하여 계획한다.) > Task는 1~2주 안에 끝낼수 있어야 할 분량이어야 한다. > Task간의 의존관계는 적어야한다.(Minimize task dependencies) > Concurrently하게 일이 진행(동시 실행)하게 해야 한다. - Task단위로 언제 어떻게 할 것인지를 정한다. > 각 Task의 종료일, 작업량, 인력 할당 및 수행에 필요한 자원을 식별한다. - Project scheduling을 하는 ..

* Project planning - Software는 눈에 보이지 않는다. 따라서 계획 수립의 힘들고, 예산 선정이 힘들다. - 전체를 분활하고, 각 부분별로 프로젝트인원을 할당(팀을 구성) - 발생 가능한 문제점을 예상하고, 해법을 제시한다. - Project Plan(PP, 프로젝트 계획서) > 프로젝트 시작단계에서 생성 > 개발자와 고객에게 어떤 프로젝트를 수행하는지를 알려줌 > PP는 진행 정도의 기준역할로 진행정도를 파악하도록 도와준다. * Planning Stage(계획 수립 단계) - Proposal stage > 계획이 포함된 제안서(project proposal(pp))를 만듬 - Project start-up phase > 프로젝트 계획서(project plan(PP))를 만듬 > 인..

* Rapid software development - 요즘에는 소프트웨어를 빠르게 개발해야할 사항이 많아졌다. Because, 사업환경의 변화가 빠르기 때문에 이에 대응하여 요구사항이 지속적으로 변하기 때문에 - 명세, 디자인, 구현의 경계를 없엔다. - System version을 여러개로 나눠서 구현을 한다. - IDE(Interactive Development System) tool등을 이용해 UI를 자동 생성한다. * Agile methods - 설계보다 코드(소스)에 중점을 둔다. - 반복적인 접근 방법으로 나눠서 개발을 한다. - 빠르게(빠른 기간내에) 돌아가는 Software를 만든다. - Principles(원리) > 고객을 개발에 참여 시킨다. > Incremental delivery ..

* Boehm's spiral model(보험의 나선형 모델) - "어떻게 개발해야 하는 가"의 과정이 나선형으로 나온다. - Process나 Activity라고 하지 않고 하나의 주기를 Phase라고한다. - 명세, 설계 ... 등 단계가 불분명하다. - 위험 요소를 줄이는 활동을 심하게 한다. - 1~4분위 면은 각각 분위마다 Phase에 관계없이 하는일은 비슷하다. ⓐ Objective setting ( 목적 수립 단계 ) > 2사 분면에 해당하는 것으로, ⓓ에서 설립한 계획의 Phase 목적을 수립하고 검토한다. ⓑ Risk Assessment and reduction > 1사 분면에 해당하는 것으로, ⓐ단계의 문서를 보고 위험요소를 파악하고, 때에 따라 프로토 타입을 만들어서 실험을 해본다. ⓒ..

* Process activities - 기술적 행동(technical activities), 관리적 행동(managerial activities), 통합적 행동(collaborative activities) 함께일어난다. - 4가지의 기본적 프로세스 엑티비티가 존재한다. > specification, development, validation, evolution - 4가지의 기본 프로세스 엑티비티는 다음과 같은 두가지 방법으로 이뤄진다. ⓐ waterfall : 연속적 형태로 발생한다. ⓑ incremental : Interleaved(다음 과정이 이전 과정과 겹침)형태로 발생한다. ex) * Software specification(소프트웨어 명세) - 무슨 서비스를 할 것인가? 이에 필요한 기능이 ..

* Prototype - prototype방식은 Change avoidance유형의 진화 방법이다. - 보고 제품에 대한 느낌을 느낄 수 있는 시연 가능한 겉 껍데기를 만든다. - 프로토타입을 사용하는 때 > 요구사항을 이끌어 낼때 > UI를 만들 때 > 모듈 실험시 다른 모듈에서 오는 값을 생성할 때 - 프로토타입 사용시 장점 > 사용성이 높아진다. > 고객과 밀접해 개발을 진행 할 수 있다. > 개발에 대한 노력 비용이 줄어든다. > 디자인 퀄리트가 상승하며, 유지하기가 좋아진다. > 몰랐던 것에 대한 이해가 높아진다. - 프로토 타입을 만 들 수 있는 도구를 배울 필요가 있다. - Throw-away Prototypes > 프로토 타입은 버리려고 만드는 것이다. > 프로토 타입은 만들 프로그램의 기..

1. The water fall model(Software life cycle model) ※ Integration : Systems가 A System(하나의 시스템)이 될때까지 반복 하는 과 - 위에서 아래로 한단계 단계가 폭포수가 떨어 지듯이 진행 되는 모델 - 하나의 과정이 끝난후 다음 단계로 넘어 가면 이전 단계로 돌아 갈 수 없다.(단반향) - 만약, 어떠한 단계에서 문제가 발생하더라도, 이전 단계로 돌아 갈 수 없기 때문에 우회적인 방법으로 문제를 해결한다. - 관리자 입장에서 계획을 관리하기가 쉽다. - 일을 협동해서 하기가 쉽다. (큰 틀이 주어지기 때문에 각자가 그 틀에 맞춰서 일을 하면 된다.) - 완벽한 설계와 구현이 있기 때문에 현재까지도 많이 사용 되고 있다. - 구현이 끝나고 관..

* Software Process - 소프트웨어 개발을 위해 필요한 활동들의 집합 - 목적 소프트웨어에 따라서 필요한 활동들은 모두 다르지만 공통적인 활동이 몇개 존재한다. > Specification : 명세화, 시스템이 무엇을 해야하는지 기능을 정의하는 단계 > Design and implementation : 시스템 구조를 정의(Architecture Design)하고, 구현하는 단계 > Validation : 검토, 테스트 단계 > Evolution : 유지 보수 및 진화단계 * Software process descriptions(소프트웨어 개발 활동 계획서) - 각 소프트웨어의 개발(Activity) 순서에 따라서 개발 계획서를 작성한다. - 각 단계가 단계별로 꼭 표현이 되어야한다. - 각 ..

* 소프트웨어공학론을 배우는 이유 ⓐ 전문적인(Professional) 소프트웨어 개발을 잘 하기 위한 이론, 방법, 도구들을 알기 위해서 ⓑ 최근 System의 비용은 소프트웨어 비용에 의해서 결정되는 경향이다. - 소프트웨어 개발의 비용을 최소화 하기 위한 법을 알기 위해서 ⓒ 더 나아가 소프트웨어를 개발 하는 것보다 유지 보수하는 비용이 더 많이 든다. - 소프트웨어 유지 비용을 최소화 하기 위한 법을 알기 위해서 ⓓ ⓑ,ⓒ를 통틀어 Cost-Effective Software Development(효율적 비용 소프트웨어 개발)를 위해서 배운다. * Software (Engineering) ⓐ Software = Computer programs + associated documentation. - S..