Wanna be a thinker

용어

• LAN : 캠퍼스, 건물, 한 층의 협소한 네트워크
• WAN : 도시, 국가 간을 묶는 광범위한 네트워크(여러 LAN을 결합)
• Host : IP 주소가 부여된 컴퓨터
• Standalone : 네트워크 접속 없이 컴퓨터를 사용하는 형태
• Batch Processing : 처리할 프로그램을 일정 시간 축적하여, 일괄 처리하는 방식
• OS : 컴퓨터의 CPU, 메모리, 주변 기기, 실행 프로그램을 관리하는 소프트웨어
• Multi Vendor : 인터넷을 경유한 서로 다른 기종 간의 접속
• Downsizing : 컴퓨터의 성능 향상으로 대형 컴퓨터를 소형 컴퓨터로 대체
• Mac(Media Access Control) : 물리적인 매체간의 접속을 제어

개요

1. 컴퓨터 네트워크의 개요 및 등장 배경
1. 컴퓨터의 다양화, 소형화, 가격 저하로 보급이 확산
2. 네트워크를 통해 컴퓨터 간 정보 공유, 빠른 송수신이 가능
3. 사적인 네트워크간 결합이 활발히 이루어져 인터넷이 탄생
4. 인터넷의 보급이 정보의 공유를 촉진
2. 컴퓨터와 네트워크의 발전사
1. 1950년대 : Batch Processing
• 대규모 계산을 위해서만 컴퓨터를 사용
• 잡지식
• Batch처리를 위해 COBOL, FORTRAN 언어가 개발
2. 1960년대 : Time Sharing System(TSS)
• TSS에서는 여러 단말이 하나의 컴퓨터를 사용
• 네트워크와 컴퓨터의 결합이 시작
• 잡지식
• TSS는 Star형 네트워크 구성
• 유저가 단말을 통해, 직접 컴퓨터를 조작
• TSS의 OS에 의해, 컴퓨터가 여러 프로그램을 동시에 처리
• 동시 처리를 통해, 가상적으로 단말과 컴퓨터간 1:1로 통신
• 대화형 조작이 실현
• TSS 용으로 Basic 언어가 개발
3. 1970년대 : 컴퓨터간 통신
• 컴퓨터의 소형화, 저가화로 기업이 컴퓨터를 도입
• 사무 처리의 효율화를 위해 컴퓨터 간의 데이터 송수신 기술이 실현
• 잡지식
• 이전에는 자기 테이프, 플로피 디스크 등 외부 매체를 이용하여 컴퓨터간 데이터 이동
4. 1980년대 : 컴퓨터 네트워크 등장
• 다른 종류의 컴퓨터 간의 통신을 위해 네트워크가 등장
• Windows 시스템의 등장으로, 여러 프로그램의 동시 사용을 실현
• 네트워크와 Windows 시스템을 결합하여, 네트워크 내의 서로 다른 컴퓨터 자원을 자유로이 활용
5. 1990년대 : 인터넷의 보급
• 값싸게 여러 메이커의 컴퓨터를 접속해 시스템을 구축하기 위한 Downsizing, Multi vendor가 유행
• WWW에 의한 웹 서비스의 보급으로 여러 메이커가 각자의 통신 기술을 인터넷에 대응
6. 2000년대 : 인터넷 기술이 중심
• 개별적으로 발전한 기술을 도입하여 인터넷이 발달
• 예로, 전화망을 기반으로 구축된 인터넷은 IP망으로 대체
• IP망 위에 전화, TV, 컴퓨터 통신, 인터넷이 구축
• 컴퓨터 외에도 인터넷에 접속
7. 모든 것의 핵심은 TCP/IP
• 인터넷 기술 = TCP/IP
• 다양한 통신 기술을 결합하는 응용성을 보유
3. 프로토콜
1. 개요
• 컴퓨터간 통신하기 위한 약속
• 프로토콜만 일치하면 메이커, CPU, OS 등의 차이는 무의미
• 통신을 위해서는 물리적 단계에서 응용 프로그램의 종류까지 명확한 약속이 필요
• 사람으로 치면 언어(영어, 일본어, 한국어 등)
2. 패킷 교환
• 패킷은 '소포'라는 뜻
• 큰 데이터를 작은 데이터로 분할한 것
• 패킷에 헤더를 부착하여 송신자, 수신자, 패킷내용 등을 지정
• 많은 컴퓨터가 한 회선을 공유해도 헤더를 통해, 목적지에 도달 / 재조립이 가능
• 프로토콜은 헤더의 작성법, 해독법에 대한 약속을 정의한 것
4. 프로토콜 표준화
1. 표준화란?
• 서로 다른 메이커의 네트워크 장비 간 통신할 수 있도록 공통된 프로토콜을 제정
2. 배경
• 컴퓨터의 사용량은 증가, 하지만 기업별 프로토콜이 달라, 타 기업 네트워크 장비와 통신할 수 없는 문제 발생
• 회사의 부도, 서비스 중단 등으로, 고객은 모든 장비를 타사의 장비로 교체해야 하는 문제 발생
• 호환성에 대한 니즈가 증가가 네트워크 오픈화, 멀티 벤더화로 직결
3. 대표적 모델
• OSI(Open Systems Interconnection, 개방형 시스템간 상호 접속)
• ISO(International Organization for Standardization, 국제 표준화 기구)에 의해 제정
• 통신에 필요한 기능을 7 계층으로 분할
• TCP/IP
• IETF(Inter Engineering Task Force)라는 민간 조직에서 표준화
• 인터넷 상의 Defact Standard로 자리 매김
5. 프로토콜 계층화
1. 계층화란?
• 복잡한 네트워크 프로토콜을 단순화 하기 위해, 기능에 따라 여러 계층으로 분할
• 각 층은 하위층에서 특정 서비스를 제공 받아, 상위층에 특정 서비스를 제공
2. 장점
• 각 층이 독립하여, 변경에 의해 타 층에 영향이 없음
• 단순화 되므로, 프로토콜을 만들기 쉬움
• 각 층마다 책임이 명확함
3. 프로토콜과 인터페이스
• 인터페이스 : 상위층과 하위층이 서로 서비스를 주고 받는 것에 대한 약속
• 프로토콜 : 통신 상대의 같은 계층과의 통신에 대한 약속
4. OSI 참조 모델
• 각 층은 역할에 따라 구분된다.
• Application
• 응용 프로그램의 통신 관련 부분을 정한다.
• 전자 메일, 파일 전송, 원격 접속 등
• Presentation
• 상하위층간 데이터 포맷을 상호변환한다.
• 기기 고유의 포맷 또는 네트워크 공통 포맷
• Session
• 데이터 전송을 관리한다.
• 논리적 통신로인 커넥션의 확립 / 절단, 전송할 데이터의 길이 등을 관리
• Transport
• 목적지의 Application 계층까지 데이터를 전송한다.
• 통신을 하는 양 쪽 노드에서만 처리가 일어난다.
• Network
• 목적지까지 데이터를 전송한다.
• 주소 체계, 전송 경로의 선택도 담당한다.
• Data Link
• 물리적으로 연결된 노드 간 통신을 가능하게 한다.
• 2진수의 숫자열을 의미를 가지는 덩어리인 프레임으로 나누어 상대에게 전달한다. (프레임의 생성, 수신)
• Physical
• 디지털 신호(비트열)와 아날로그 신호(전압의 고저 혹은 점멸)를 상호 변환한다.
• 케이블이나 커넥터의 형상을 규정한다.
• OSI 참조 모델에 의한 통신처리
• 각 층의 프로토콜은, 헤더 등 데이터 포맷과 데이터 처리 수순 등을 구체적으로 정의하고 있다.
• Application 층
• 송신 시
• 메시지, 수신자 등에 대한 메타데이터를 패킷에 부착한다.
• 수신 시
• 헤더와 패킷을 분리하여 해석한 후, 비휘발성 메모리에 보존한다.
• 수신 불가 시, 에러 메세지를 반환한다.
• Application 고유의 에러 처리도 Application 층의 역할이다.
• Presentation 층
• 이기종 간의 데이터 표현 형식의 정합성을 보장한다.
• 송신 시
• 컴퓨터 고유의 데이터 표현 형식을 네트워크 공통 표현 방식으로 변환한다.
• Presentation 층 간의 데이터 부호화 방식 식별을 위해 헤더를 부착한다.
• 수신 시
• 데이터 부호화 방식 식별을 위해 헤더와 패킷을 분리한다.
• 네트워크 공통 표현 방식을 컴퓨터 고유의 데이터 표현 형식으로 변환한다.
• Session 층
• 목적지로의 통신로 확보, 데이터 송신 준비 등 가상 커넥션을 확립한다.
• 커넥션 확립, 데이터 전송 등의 타이밍을 관리한다.
• 헤더에 데이터의 전송 수순에 대한 정보를 담아 부착한다.
• Transport 층
• 실제 커넥션의 확립 / 절단한다.
• 데이터 전송의 신뢰성을 보장한다.
• 데이터 도착 여부 확인
• 데이터 미도착, 데이터 파손시 재송신
• Network 층
• 목적지를 특정하기 위한 IP주소, 포트 등의 정보를 헤더에 담아 송신할 패킷에 부착한다.
• Data Link 층
• 물리적 통신 매체로 연결된 기기 간 데이터 송수신을 가능하게 한다.
• Physhical 층
• 0과 1의 디지털 데이터를 전압이나 빛의 펄스로 변환하여 물리적 통신매체에 흘려 보낸다.
• 직접 접속된 기기간 식별하기 위해 MAC 주소가 사용된다.
• 헤더에 MAC 주소가 포함된 정보를 담아 패킷에 부착한다.

■좋은 요건 정의서의 필수조건

• 전문 지식을 몰라도 내용을 이해할 수 있다.
• IT분야의 전문 지식이 없는 고객을 고려하여, 이해하기 쉽도록 작성한다.
• IT분야의 전문 용어나 전문 지식을 되도록이면 사용하지 않도록 한다.
• 이해하기 어렵게 작성되어 있으면, 결과물을 이미지할 수 없게 되고, 고객의 불신감이 싹트게 된다.
• 고객과 개발사의 역할 / 책임의 분담을 명확히 한다.
• 가능한 한, 정량적으로 작성한다.
• 배경, 기능은 가능한 정량적으로 작성해야, 시스템을 둘러싼 상황을 명확히 할 수 있다.
• 단, 이 단계에서 근거 없는 숫자를 작성하는 것은 위험하기 때문에 어디까지나 가능한 선에서 작성한다.
• 하지 않을 것을 명확히 한다.
• 요건 정의서에 기술된 내용이 하지 않을 것인지, 아직 정해지지 않은 것인지를 명확히 할 수 있어, 애매한 해석을 방지할 수 있다.
• 문체나 표기를 통일한다.
• 읽기 쉬운 문장도 품질의 하나이기 때문에, 문체 / 표기 / 용어 등을 통일한다.

■요건 정의서 작성 흐름

1. 요건 정의 계획 작성
2. 업무 요건의 정리
1. 현행 업무의 정리
2. Hearing 실시, 과제 분석, 해결책 검토
3. 새로운 업무를 검토
4. 시스템화 범위의 검토
3. 시스템 요건의 정리
1. 플랫폼의 검토
2. 기능 요건과 비기능 요건의 정리
4. 정리 / 견적
1. 요건 정의서 작성
2. 기본 설계 이후의 계획 작성
3. 견적 산출

1. 요건 정의 계획 작성

• 성과물
• 요건 정의 설계서
• 시스템화 방침을 명확히 하여, 요건 정의의 스케줄과 체제도를 작성한다.
• 5W2H를 명확히 한다.

2. 업무 요건의 정리

시스템 요건에 앞서 업무 요건을 정리해야 한다.

고객도 현재 상황에 대한 분석이 충분치 않은 상태에서 Hearing하더라도,

제대로 요건을 끌어내지 못하거나, 나중에 가서 새로운 기능의 추가가 요구될 수 있기 때문이다.

• 현행 업무의 정리
  • 현행 업무 흐름
  • 업무 처리 정의서
• 성과물
• 업무의 있어야 할 모습(To-be)과 현재 상황(As-is)간의 갭이 업무 과제가 된다.
• 과제를 빠짐 없이 추려내기 위해, 현재의 업무(As-is)의 정리가 중요하다.
• 현재 업무를 정리하는 수법은 다양하지만, 업무 흐름도를 작성하는 것이 일반적이다.
• 흐름도 상에 다 쓸 수 없는 상세한 내용은, 업무처리정의서에 기재한다.

• Hearing 실시, 과제 분석, 해결책 검토
  • Hearing결과 일란
  • 문제 / 영향 / 원인 / 대책 일란
  • 업무 상의 문제, 과제를 추려 낸다.
  • Hearing한 내용은, 일란표로 정리하여 나중에 확인할 수 있도록 한다.
• 성과물
• 업무 부문의 Hearing을 하며, 과제를 분석하여 대책을 검토하는 과정이다.
• 이 때의 대책은, 시스템화에 의한 대책 뿐만이 아닌, 업무 프로세스나 체제의 변경 등을 포함한다.
• Hearing 실시

• 과제 분석
• Hearing한 결과를 바탕으로, 문제 / 영향 / 원인을 구조적으로 정리한다.
• 문제로부터 정리하면 좋다.
• 영향에 대해서는, 그래서 뭐?를 반복하여 매상 / 코스트 / 고객만족도 / 준수법규(complaiance)와 같은 경영 레벨의 관점으로 연결한다.원인에 대해서는, 왜?를 반복하여 업무 프로세스 / 시스템 / 제도, 룰 / 조직, 담당자 / 설비, 기기와 같은 관점에서 정리하면 대책을 검토하기 쉽다.각 문제에 대해 우선순위를 정해두면, 해결책의 검토 대상을 한정하거나, 시스템화의 대책 범위를 결정할 때 도움이 된다.

• 해결책 검토
• 핵심적인 원인에 대한 대책을 검토한다.
• 업무 프로세스 / 시스템 / 제도, 룰 / 조직, 담당자 / 설비, 기기와 같은 관점에서 정리하면 대책을 검토하기 쉽다.
• 시스템의 관점에서 검토한 대책이, 시스템 요건으로 이어진다.

• 새로운 업무를 검토
  • 신 업무 흐름도
• 성과물
• 현행 업무의 자료에 검토한 해결책을 반영시킨다.
• 현행의 데이터 흐름이나 유즈케이스를 정리한 경우, 개선 후의 자료도 정리 한다.
• 시스템화 범위의 검토
  • 시스템화의 대상 범위
• 성과물
• 문제 분석과 해결책의 검토 후, 시스템화 범위가 바뀌었을 가능성이 있기 때문에 검토한다.
• 구체적으로는 요건 정의를 개시했을 때 설정한 5W 2H의 Where(대상 범위)나 How(실현 수단)를 체크한다.
• 고객이 요구한 기능이 실현 가능한지 판단하여 탑재할 기능을 고객과 함께 결정한다.
• 요구 내용 중 시스템화 할 범위를 명확히 해야, 도중에 사양 버그로 인해 두 번 일하지 않는다.
• 당초와 비교해 시스템화 범위가 확대된 경우, 범위를 좁히거나 프로젝트 예산을 늘릴 필요가 있다.(요건 정의 스케줄이 연장되기도 한다.)

3. 시스템 요건의 정리

시스템화 범위나 플랫폼의 변경이 없는지 재검토 후, 시스템의 기능 요건과 비기능 요건을 구체화하는 작업이다.

• 플랫폼 검토
  • 하드웨어 구성
  • 소프트웨어 구성
  • 네트워크 구성
• 성과물
• 플랫폼이란, 시스템 기능을 제공하기 위한 네트워크, 하드웨어, 운영체제, 미들웨어를 의미한다.
• 앞에서의 시스템화 범위의 검토의 결과를 토대로, 필요한 플랫폼을 정리한다.
• 플랫폼의 변경은, 프로젝트에 큰 영향을 끼치기 때문에, 제대로 검토할 필요가 있다.
• 기능 요건과 비기능 요건의 정리
  • 시스템 기능 : 시스템 기능 계층도
  • 화면 : 화면 일란 / 화면 전이도 / 화면 레이아웃
  • 장표 : 장표 일란 / 장표 레이아웃
  • 데이터 : ER도 / 엔티티 일란 / 엔티티 정의서
  • 외부 인터페이스 : 외부 시스템 관련도 / 외부 인터페이스 일란 / 외부 인터페이스 정의서
  • 사용성 및 접근성
  • 시스템 방식
  • 규모
  • 성능
  • 신뢰성
  • 확장성
  • 상위호환성
  • 계속성
  • 정보 보안
  • 정보 시스템 가동 환경
  • 테스트
  • 이행
  • 인수인계
  • 교육
  • 운용
  • 보수
• 기능 요건 : 업무를 대행 또는 지원하는 기능
• 비기능 요건 : 성능 / 신뢰성 / 조작성 등, 기능 이외의 요건
• 기능 요건의 성과물
• 비기능 요건의 성과물

4. 요건 정의 정리 / 견적

• 요건 정의서 정리
  • 요건 정의서
• 성과물
• 여지껏 작성한 자료를 정리하는 작업이다.
• 시스템 설계 직전의 공정이기 때문에, 시스템의 전체상에서 세분화한 기능까지, 가능한 상세하게 기입해야 한다.
• 서면 내용은 고객의 요구를 만족한, 상호간 협의 및 합의가 된 내용이어야 한다.
• 기본 설계 이후의 계획 작성
  • WBS
• 성과물
• 요건 정의서 작성 후, 기본 설계 이후의 작업을 추려내어 스케줄을 세운다.
• 여기서 작성한 자료는 견적이나 후속 공정에서의 스케줄, 비용 관리에도 사용한다.

• 견적 산출
  • 견적서
  • 유추 견적
  • 과거의 비슷한 프로젝트로부터 견적을 유추하는 방법이다.
  • 예산 획득 시 등, 상류 공정의 초기 견적에서 사용되는 경우가 많으나, 정밀도가 낮기 때문에 요건 정의 이후에는 거의 사용되지 않는 수법이다.
  • 모수(母数：パラメトリック) 견적
  • 기능 수, 화면 수 등의 계수를 곱하여 견적을 산출한다.
  • 계수의 설정에 따라 견적의 정밀도가 바뀌지만, 이용 실적이 많은 기업에서는 계수의 신뢰성이 높고, 고객 기업의 이해도 얻기 쉽기 때문에 가장 많이 사용되는 수법이다.
  • BottomUp 견적
  • 프로젝트의 작업을 추려 내어, 공정 수를 산출하는 방법이다.
  • 작업 베이스로 견적을 내기 때문에, 가장 정밀도가 높고, 프로젝트 개시 후의 스케줄 / 비용 관리에도 유용할 수 있다.
• 성과물
• 요건 정의서 작성 후, 시스템 개발의 견적을 산출하여, 예산을 오버하지 않았는지 체크한다.
• 다음과 같은 대표적인 견적을 내는 수법이 있다.

※요약

1. 어떻게 진행할 지 계획을 세운다.
2. 기존 업무를 어떻게 바꾸고 싶은지 정리한다.
3. 이를 위해, 어떤 시스템이 필요한지 정리한다.
4. 요건 정의서로써 정리하여, 견적을 낸다.

■용어

• 요건 정의서
• 실현할 기능 등을 조정한 정보를 고객에게 제출하기 위해 개발측에서 작성하는 것이다.
• 업무 요건
• 기존 업무 흐름을 분석, 문제를 추출하여, 문제를 해결할 새로운 업무 흐름을 정의한 것이다.
• 시스템을 의식하지 않고, 업무에만 중점을 두어, 요건을 추려 낸다.
• 시스템 요건
• 업무 요건에서 정의한 새로운 업무 흐름을 만들기 위해, 어떻게 시스템화 할 지 방향성을 결정한 것이다.
• 기능 요건
• 시스템 요건에서 정한 시스템화의 방향성을 바탕으로, 시스템에 필요한 기능을 검토한 것이다.
• 데이터, 시스템의 종류 / 구조, 시스템이 처리할 수 있는 내용 등에 대해 작성한다.
• 비기능 요건
• 비기능 요건이란, 고객이 기능면 이외에서 요구하는 시스템 성능, 효율성, 보안, 보수 / 운용 서비스 등의 요건을 의미한다.

■개요

요건 정의서는 고객의 요구와 그 요건을 어떻게 이룰 것인가? 즉, 어떻게 시스템화 할 것인가?를 문장으로 정리한 것이다.

시스템 개발의 기반이 되며, 운용 개시 후까지 영향을 끼치기 때문에 시스템적인 모순이 없어야 하며, 고객과의 인식에 착오가 있어서는 안된다.

■목적

• 고객과의 인식을 맞추어, 개발 후 고객의 인식과 다른 결과물을 내지 않는 것이다.
• 시스템 개발에 있어, 무엇을 위해 무엇을 만드는지를 명확히 하는 것이다.

■요건 정의 수법

• 기존 업무 흐름과 시스템을 파악한다.
• 기존 시스템이나 업무 흐름에 해결할 문제가 있기 때문에 요구가 있는 것이다.
• 기존 업무 흐름과 시스템을 알아야, 어떤 부분이 문제인지, 어떻게 해결할 것인지를 알 수 있다.
• 요건 정의를 꼼꼼히 하기 위해, 보수 담당자나 시스템 사용자에게도 Hearing을 해야 한다.
• 요건 정의에 드는 비용을 최소화 하기 위해, 문제를 이해하여 해결책을 내야할 필요가 있다.
• 요구 정의서와 요건 정의서를 작성함에 있어, 고객과 협의 한다.
• 요구 정의서란, 고객이 해결하고자 하는 과제나, 도입하고자 하는 시스템에 대한 요구를 정리한 서류이다.
• 요건 정의서가 요구 정의서 대로 작성되었는지 고객과 함께 확인한다.
• 고객과의 협의는 공정 수의 삭감, 일을 두 번 하지 않기 위해 중요하다.
• 정중한 요건 정의서를 만들어 공유한다.
• 요건정의서는 고객과 개발자 간 인식의 착오를 일으키지 않도록, 최대한 상세하게 작성한다.
• 최종적인 결과물을 이미지할 수 있도록 작성하여 관계자 간에 합의가 되어야 한다.
• 담당자를 명확히 한다.
• 고객이 할 일과 SE가 할 일을 명확히 나누어야, SE가 고객의 일까지 떠맡지 않는다.
• 역할분담이 명확해야 불필요한 업무로 인한 공정 수의 압박을 피할 수 있다.

■요건 정의서의 작성 방법

• 요건 정의서 기술 항목(필수)

• 요건 정의서 기술 항목(옵션)

■WPF(Windows Presentation Foundation)란?

WinForm의 부족한 기능 및 디자인 기능을 대처하기 위해서 등장한 디자인 특화 사용자 인터페이스이다.

■등장배경

2002년 WinForm이 등장하여 Windows 응용 프로그램 개발을 주도했다.

이후 비디오, 미디어, 애니메이션, 2D/3D 그래픽 등을 다이나믹하게 사용하고 싶은 요구가 생겨났다.

이러한 기술들은 독립, 분산되어 있었고 통합하여 개발하기 위해서는 각각의 기술을 모두 이해해야 했다.

통합된 기술에 대한 수요가 있었고, 이에 부응하여 WPF이 개발되었다.

■특징

- Windows API를 사용하는 WinForm과 달리, DirectX 기반으로 동작한다.

- 윈도우를 생성하는 네이티브 함수인 CreateWindow는 창에만 한정되고 나머지는 직접 그리기 때문에, 버튼의 각도를 변경하는 등 WinForm에서 기능상 한계로 불가능한 것이 가능해졌다.

- UI 구현에 XAML(eXtensible Application Markup Language)을 사용한다.

- WinForm과 달리 모던한 디자인 패턴을 적용할 수 있다.

- WinForm과 달리 디자이너와 분리된 상태의 협업이 가능하다.

■용어

XAML

- 선언적으로 UI를 구현하는데 사용되는 XML 기반 태그 언어이다.

- 창, 대화 상자, 페이지 및 사용자 정의 컨트롤을 만들고 이러한 항목을 컨트롤, 도형 및 그래픽으로 채우는 데 사용된다.

출처

ojc.asia/bbs/board.php?bo_table=WPF&wr_id=2

namu.wiki/w/C%23