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

1. Observer Pattern ⓐ Name : Observer ⓑ Description - 본 패턴은 객체 사이에 일 대 다의 종속성을 정의하고 한 객체의 상태가 변하면 종속된 객체에게 통보가 가서 자동으로 업데이트가 일어나게 하는 것이 목적인 패턴이다. - 주로 한 객체에 대한 View(Display)와 State(상태, 데이터)를 나누는 것에 많이 사용된다. ⓒ Problem Description - 하나의 상태에 대해서 다양한 형태로 표현해주는 시스템 개발에 사용된다. ⓓ Solution Description - 두 개의 추상 클래스, Observer, Subject를 이용해서 해결한다. - Observer Object는 Observer Interface로부터 상속받은 객체로써, observe..

* Process improvement - Software process의 향상은, SW의 품질을 높이고, SW개발 비용을 줄인다. - Process improvement를 위해서는 기존 프로세서에 대한 충분한 이해가 필요하다 - Stage 1) Process 현황 분석 : 다음을 측정하여 분석에 사용한다. > 특정 이벤트가 발생하는 횟수 (eg. 수정에 대한 요구) > 프로세스 수행 시간(eg. 요구사항 분석기간) > 특정 이벤트 수행에 필요한 인원수 2) Process analysis > 현재 Process 상의 bottleneck과 weakness를 찾아내는 과정 3) Process change > Process를 바꾼다. * CMM - 프로세스 개선을 위해 현재 프로세스 상태를 파악하는 기준, 척..

* Process Activity 보조활동 - CM(형상관리) - QM(품질관리) * Configuration Management - 눈에 보이는것, version을 관리하는 행동 - 소프트웨어 시스템 변화를 체계적으로 관리하기 위한 원리 및 과정을 정의 - Activity ⓐ Change Management : 요구사항 변화를 추적(Tracking) 관리 ⓑ Version management : 여러 사람이 독립적인 개발시 서로 상충되는 것을 없게 관리 ⓒ System building ⓓ Release Management : 출시 관리 * Configuration Management 용여 - SCI(Software configuration item), CI > 프로젝트 산출물중에서 형상관리 대상으로 지..

* Software change - Software change가 일어나는 이유 1) 새 요구사항의 등장 2) 사업 환경의 변화 3) 에러 발생 4) 새로운 장비의 도입 5) 성능, 신뢰성 향상의 필요 - 위와 같은 이유에 따라서 모든 SW는 이 단계를 피할 수 없다. 또한, 각 회사는 많은 돈을 이 과정에 투자한다. - 소프트웨어 진화 과정은 나선형을 이룬다. * Evolution vs Service - Evolution = S/W + new spec > 현재 SW를 사용하고 있으며, 지속적으로 새 요구사항이 제안되고 구현됨 - Service > 새 요구사항 없이, SW의 환경설정 변경 또는 Bug fix를 해준다. - Phase-out > SW는 계속 사용되지만, evolution과 service를 ..

* Problem Testing - 하고자하는 일을 수행하는가?(validation)를 검사 // validation testing - error가 나는가?(verification)를 검사 // defect testing - test를 수행하는 전재 조건 : 실행 가능한 Program, 인위적인 data 자료 - error가 없다는 것은 검증이 불가능하다. - 먼저, validation testing을 실시(미리 제작된 test case를 활용) - validation testing이 끝나면, defect testing을 실시한다. 그때 생각나는 data를 즉흥적으로 입력하며, 잘못된 data에도 정상적으로 돌아가는지를 파악한다. - 각각의 test는 goal을 정해둔후 실시한다. * V&V confid..

* Design & implementation - 실행 가능한 소프트웨어 System을 개발하는 것 - inter-leaved : design과 implementation은 동시에 발생한다. - Build(구현) or Buy(구매) > 구매 : Commercial off the shelf system(COTS) > 사느냐, 구현하느냐에 따라 System이 달라진다. * Object-Oriented Design Process - 구조적 개발 방법론을 사용하기 때문에 Large-System 개발에 용이 - small system 개발에는 비용적 측면이 비효율 적일 수 있다. * Process stage - Define the context - Design the System Architecture - Ide..

* Software Architecture - System을 구성하는 Sub-System을 분할 및 제어법, 통신법 식별 - 대부분의 System은 최초로 개발되는 것이 없다. > 이미 Architecture가 framework식으로 존재 - 본 단계의 결과물은 Software Architecture Design이다. - 본 단계는 요구사항과 앞으로 일어나는 활동의 연결부분으로 중요한 역할을 한다. - 본 단계는 Specification과 동시에 발생한다. - 아키텍쳐는 큰 관점(in the large)으로 System, 독립적프로그램, 각 System간의 관계등을 정의 작은 관점(in the small)으로 클래스, 컴포넌트, 클래스 간의 관계등을 정의한다. - 장점 > stakeholder commu..

* System modeling - 시스템을 서로 다른 관점에서묘사한 추상적 모델(Abstract models) - 사용처 > Analysts : 시스템의 기능 이해 > 고객과 의사소통 - 일반적으로 UML(Unified Modeling Language)를 통해서 묘사 * 시스템 관점 ⓐ An external perspective(외부적 관점) : 어디까지가 시스템인지를 구분 ⓑ An interaction perspective(상호적 관점) : 시스템의 상호 작용을 정의 ⓒ A structural perspective(구조적 관점) : 시스템의 구조를 표현 ⓓ A behavioral perspective(행동적 관점) : 시간에 따라 어떻게 움직이는 가를 표현 * UML diagram - Type ⓐ A..

* 요구사항 명세서 작성시 중요한 것 ⓐ Natural language specification - 자연언어의 문장과 모호함을 줄이기 위한 그림(다이어그램), 표(테이블)로 이뤄져있다. - standard format을 만들어서 요구사항을 쓰는 형식이다. - 어체는 ~해야한다. ~해야만 한다. ~할 수 있다. 등의 어체로 실현가능성을 나눠서 작성하는 것이 일반적이다. - 글을 읽었을때 컴퓨터공학과 사람이 작성한 것이라는 생각이 안들 도록 해야한다. - 왜 이 소프트웨어가 필요한지 포함 시켜야 한다. - 자연언어의 문제점 > 명확성이 떨어지며, 애매하고 불확실하다. 또한 여러가지 개념이 뭉쳐져서 나타난다. ⓑ Structured specification - 어느 정도 형식을 갖추어서 기술을 한다. > 표 ..

* 요구공학(Requirements Engineering) - 어떤 시스템에서 필요한 서비스(기능)과 제약사항(비기능)을 정의하는 학문 - 요구사항의 기술 방법은 높은 단계의 추상화부터 수학적 기능 명세까지 다양하게 표현이 가능하다. - 요구사항의 종류는 2가지가 있으며 2가지가 하는 일이 다르기 때문에 2종류 모두 작성해준다. ⓐ User requirements - 계약을 성립시키기 위한 요구사항 - 사용자의 요구사항이며, 이를 자연언어와 다이어그램, 표 등을 사용해서 표시한다. - 사용자, 고객을 위해서 작성된 요구사항이며, Client manager, System end-users, Client engineers Contractor managers, System Architects등이 읽는다. ⓑ ..