진형아빠이야기

안녕하세요.

진형아빠입니다.

이번에는 '대기업 병과 죽어가는 조직' 에 관한 이야기를 하려고 합니다.


저는 이것을 읽어보고는 매우 감명을 받았습니다. 제가 그간 거치던 대기업이라는 이름의 조직들에서 자주 보이던 문제를 제대로 잡아 낸듯 합니다.



저는 최근에 빠름을 강조하는 통신기업에서 일하면서 더욱더 이런 대기업병을 겪은듯 합니다. 


여기서 점점 무기력해지는 제 자신이 싫어서 큰 결단과 선택을 했지만 대부분의 많은 분들은 선택지가 없어서 힘들어 하는것으로 알고 있습니다.

이런 병에 걸리면 치료도 힘들뿐더러...전염까지 되서 ㅜㅜ

하지만 고치려는 노력을 하면 할 수 록 더욱 조직에서 멀어지게 되니 이 또한 아이러니라고 할 수 있겟습니다.


이런것을 느낄때면 제가 개발자로 살아간다는것이 얼마나 다행인지 모릅니다. 

개발자로서 최소한 자유로운 선택을 할 수 있는 여지가 좀있네요. 저는 오늘도 완벽한 자유를 꿈꾸며 발버둥 치고 잇습니다.

여러분은 어떤가요?


출처 : http://venturesquare.net/3621

신고

Comment +0

VRB라는것을 해보게 되면서 한번 검색해보았습니다.


VRB

수주 이전에 수주 관련 전략 및 가치성에 대해 검토하는 회의체. 수주 가치 평가는 공공 사업과 같은 대형 프로젝트 수주 전에 각 분야 전문가로 구성된 회의체에서 사업의 수익성을 철저히 분석하여 저가의 출혈 경쟁 방지 및 이윤 극대화를 도모하는 제도이다. 국내외 IT 업체를 중심으로 수주 가치 평가(VBR)를 도입하여 수주율을 높이고, 이익을 증대하는 성과를 거두고 있다.


정의는 이렇게 되었습니다. 

역시 제가 몰랐던게 당연합니다.!!!

수주율을 높이고 이익을 증대해서 성과를 거두고 있다니...현실과 괴리가 잇는거 아닐까요? ㅋㅋ


신고

Comment +0

소프트웨어 경영/개발 컨설턴트로서 많은 소프트웨어 회사들에게 소프트웨어의 효율적인 개발 방법을 전파하고 있는 전규현님이 블로그에 올린 글을 공유합니다.

http://techit.co.kr/7263

실제로 저는 공정분리 프로젝트, 실제로 막장이라 불리는 데쓰마치 프로젝트의 비지니스 분석설계 전문가로 한동안 활동하다가 회의? 신물? 이라는것을 느끼고 지금은 도망나온 분석-설계-개발자 입니다.

아래의 글을 읽어보니 글을 쓰신 전규현님은 SI의 프로세스의 정확한 통찰과 인싸이트를 가지고 있다는 생각이 듭니다. 실제 필드에서 전사했던 녀석이 보는 관점도 크게 다르지 않습니다.

여기에 덧붙이지만 일정이라는 지독한넘 이야기를 해야겟지만 그 이야기만 해도 3박4일 내내해도 모자를 판이기에 이번에는 블로그의 글만 소개해드리겠습니다.


필자는 업계의 여러 사람과 얘기할 기회가 많다. 최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다. SI회사의 오랜 바람 중의 하나가 “공정분리”이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

“공정분리”가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.”공정분리”는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다. 최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.

그래서 진행한 것이 해외에서 “분석/설계”를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 “구현”만 하면 되도록 하는 프로세스를 만든 것이다. 실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 “구현”은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다. 이렇게 공정을 분리하려면 “분석/설계” vs “구현” 보다는 “분석” vs “설계/구현”이 더 낫다.

설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 “설계/구현”을 할 수 있기 때문이다. 여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.

더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 이렇게 제대로 “공정분리”를 하기 위해서 대전제가 하나 있다.바로 “분석”역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다. 현재의 분석역량은 기껏해야 “기능”분석과 약간의 “비기능”을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다.

필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다. 시행착오를 겪는 시간은 짧을수록 좋다.


신고

Comment +0

프로젝트를 진행하다 보면 관리가 매우 중요해진다.

그러한 관리기법중의 하나인 RACI차트를 알아보자.

RACI는 (responsible, accountable, consulted, informed의 준말) 조직적인 프레임워크 내에서 업무의 수행책임(R), 소명책인(A) , 의견개진(C) , 정보파악(I)의 유무를 파악하는 차트이다.


백문이 불여일견, 백견이 불여일타 라고 햇다.

일타를 할수는 없으니 일견을 해보도록 하자.

아래와 같은 그림은 RACI차트를 보여주고 있다. 



신고

Comment +0


RTSP (real time streaming protocol)

RTSP는 월드와이드웹 상에서 스트리밍 데이터를 제어하는 방법에 대한 표준안이다. RTSP는 미국 컬럼비아 대학과 넷스케이프 및 RealNetworks 등에 의해 수행된 작업으로부터 비롯되었으며, 표준으로 지정 받기 위해 IETF에 제출되었다.

RTSP도 H.323과 마찬가지로, 멀티미디어 콘텐츠 패킷 포맷을 지정하기 위해 RTP를 사용한다. 그러나 H.323이 적당한 크기의 그룹간에 화상회의를 하기 위해 설계된 데 반해, RTSP는 대규모 그룹들에게 오디오 및 비디오 데이터를 효율적으로 브로드캐스트 하기 위한 목적으로 설계되었다.

신고

'All that IT > SW 공학' 카테고리의 다른 글

SI업체들의 공정분리 오해에 관한 글...  (0) 2012.07.24
RACI 차트에 관해서...  (0) 2012.06.26
RTSP의 용어 정의  (0) 2012.06.18
IPv6 IP 부여방식  (2) 2012.06.18
[암호] 암호 알고리즘 설명  (0) 2012.06.07
무선랜 표준 802.11 시리즈 정보  (0) 2012.06.06

Comment +0


IPv6에서 IP 부여방법에는 크게 3가지가 있습니다.

 

1. 수동 설정 - IPv4에서 수동으로 고정 ip 설정하는 방식과 비슷함

실제로는 IPV6의 주소가 길기 때문에 잘 사용하지 않음



2. Stateful 주소 자동 설정 - IPv4에서 DHCP 서버를 이용하여 주소를 분배하는 방식과 비슷함

IPv6용의 DHCP구성이 너무 어려운데다가 서버를 두어야 하는 불편함에 거의 사용하지 않음


3. Stateless 주소 자동 설정 - 네트워크 주소는 라우터에서 받아오고 호스트 주소는 MAC주소를 변환하여 이용함.

IPX와 비슷한 방식, DHCP서버도 필요없습니다. 제일 많이 사용하는 방식이죠.




IPv6주소는 총 128bit로 구성되어있으며 64bit의 네트워크 주소와 64bit의 인터페이스 주소로 구분됩니다.

일반적으로 64bit의 네트워크 주소는 라우터에서 받아오며 인터페이스의 주소 64bit는

랜카드의 mac주소를 eui-64bit로 변환하여 사용됩니다.

 


예를 들어서 mac 주소 0011:2244:5566 을 기준으로 설명하면..

 

 

[1] MAC주소 중간에 FFFE 삽입


   MAC(48bit) = company_id(24bit) : extension_id(24bit)


   eui-64 =  company_id(24bit) : FFFE : extension_id(24bit)

 

   00 11 : 22 FF : FE  44 : 55 66

 

 


[2] universal, group bit 첨가

 

   c : company_id
   u : universal/local bit (1: universal, 0: local)
   g : individual/group bit (1: group, 0: individual)
   m : manufacturer-selected extension identifier

 

   cccc ccug : cccc cccc : cccc cccc : 1111 1111 : 1111 1110 : mmmm mmmm : mmmm mmmm : mmmm mmmm

 


  실제로 쓸때는 공인ip, 유니캐스트이므로 u는 1, g는 0을 이용합니다.

   cccc cc10 : cccc cccc : cccc cccc : 1111 1111 : 1111 1110 : mmmm mmmm : mmmm mmmm : mmmm mmmm

 


   02 11 : 22 FF : FE  44 : 55 66


  결론, 211:22ff:fe44:5566

 


신고

'All that IT > SW 공학' 카테고리의 다른 글

RACI 차트에 관해서...  (0) 2012.06.26
RTSP의 용어 정의  (0) 2012.06.18
IPv6 IP 부여방식  (2) 2012.06.18
[암호] 암호 알고리즘 설명  (0) 2012.06.07
무선랜 표준 802.11 시리즈 정보  (0) 2012.06.06
RDF(Resource Description Framework) for 시맨틱 웹  (1) 2012.06.06

Comment +2


대칭 암호화(Symmetric Cryptography) 개요


1. 특징 : 암호화 복호화 속도가 빠름 > 비대칭 키

    키의 배포 문제와 확장성에 문제가 발생, 대응법 : 일회용 키 사용

    오픈 될 확률이 공개키에 비해 높다.


2. 대칭키 암호 시스템(성능 높고, 키 길이 짧음, 알고리즘 단순성)

    Stream 방식 : 1 Bit 단위 XOR연산(HW 방식)

        * 난수(True Random No) : OTPad

        * 의사난사(Pseudo Random No) : RC4

    Block 방식 : Block 단위 S‐Box, P‐Box 알고리즘(SW 방식)

        * Feistel 구조 : DES, 3DES

        * SPN 구조 : AES

        * 기타 : IDEA(E‐mail 암호화, PGP)


3. 목적 : (대용량) Data 암호화


Ex) 대칭키가 부인방지가 안 되는 이유? 송신자와 수신자가 동일한 키를 보유하기 때문

Ex) n명으로 구성된 시스템에서는 N(N‐1)/2 개의 키의 서로 다른 키가 요구 됨.


DES(Data Encryption Standard, 1세대)


1. 목적 : Data Encryption Standard


2. 암호화 원리 : Substitution(S‐Box) + Permutation(P‐Box)


3. Round 횟수 : 16회


4. Why Crack : 키의 길이가 짧다.


5. 유효한(실제의) Key 길이 : 전체 길이(64Bit) = 56 bit + 8 bit(Parity Bit)

    * 64비트 블록 길이


6. 사례 : Kerberos


7. crack time? 4번!! 제일 근접한 것 선택

    * 안전성은 주로 “S‐Box”들에 의존



Triple‐DES(2세대)


1. 특징 : DES보다 256배 강함, DES Crack 대응하기 위해 개발

    - 보안성은 향상 시켰으나, 가용성이 떨어짐. 3단계를 거쳐서 암호화


2. 암호화 원리 : 암호화‐암호화‐암호화, 암호화‐복호화‐암호화


3. Round 횟수 : 48회

     * 비슷한 환경에서 AES가 항상 3‐DES보다 빠르다.



AES(Advanced Encryption Standard, 3세대)


 128비트의 블록을 위한 대칭적인 블록 암호


 128, 192, 256비트의 키 사이즈를 제공해야 함.


 designed to be efficient in both hardware and software across a variety of platforms : 하드웨어 및 소프트웨어 플랫폼에 걸쳐 설계, 구현 용이


 SMART Card 탑재되어 Data 암호화


 SPN 구조


IDEA(International Data Encryption Algorithm)


 16개의 더 작은 블록으로 나누어 지며, 8주기(Round)를 지닌다.


 PGP 암호화 소프트웨어에서 사용된다.


 암호시스템의 유형 : 스트림 암호화 블록 암호


1. 블록 암호 : 평문과 암호문의 블록으로 작업

 Diffusion(P‐Box), Confusion(S‐Box)

 S/W 적합, 한번에 암호화되는 메시지 단위가 일정 길이의 블록


2. 스트림 암호 : 1 비트식 암호화 하는 방식

 블록 암호화보다 속도가 빠르다.

 하드웨어 구현에 적합, 주로 무선 암호화 방식

 단점 : 상당한 비용과 자원이 소모

* XOR(eXclusive OR) : 하나만 1인 경우 그 결과는 1이다.

* Like a One‐time pad = Vernam Cipher


Electronic codebook(ECB)


 각 블록을 독립적으로 암호화

 DES의 가장 기본적이 Mode

 매우 짧은 메시지를 암호화 하는데 사용, 예) Initialization vector

 심각한 약점이 있음(Pattern 노출 될 수 있다. KPA)를 허용


* Input size = Out size(64bit)

* 독립적 수행, 오류가 전파되지 않는다.

* 병렬적 수행

* 성능 향상, 단순한 형태

* 짧은 문장 암호화 적합(Password 암호화, Initialization vector 난수)


Cipher‐block chaining(CBC)


 Blocks are “chained” together

 보안성 향상

 IV 사용(공개해도 무방)

 단점 : 에러의 영향을 받는다, 연결되어 있다 보니, 에러가 누적된다.

Ex) Replay Attack 방지법? Seg no, Time Stamps, 난수(IV)


비대칭 암호화


1. 이산 대수 원리 : DH(원조, 키 교환 전용), DSA(디지털 서명 알고리즘), DSS(표준)

* Key 길이 : 1024 ~ 2048 bit, ElGamal


2. 소인수 분해 원리 : RSA(범용적), Rabin

* Key 길이 : 1024 ~ 2048 bit


3. 타원 곡선 원리 : ECC

* Key 길이 : 160bit(SW, HW 구현이 용이), Smart card 적용(부인방지, 인증)


4. 공개키 사용 원리

 암호화 키와 복호화 키는 동일한 사람의 키 쌍이어야 한다.

 키는 암호화/복호화 중 한번만 사용 된다.

 타인의 개인키는 사용 할 수 없다.

* 송신자, 개인키 ‐> 송신자, 공개키 : 메시지에 대한 인증, 부인방지

* 수신자, 공개키 ‐> 수신자, 개인키 : 기밀성(대칭키 암호화/교환)


암호학에 관한 참조하면 좋은 사이트  : http://blog.naver.com/kimsumin75/20052758036

신고

'All that IT > SW 공학' 카테고리의 다른 글

RTSP의 용어 정의  (0) 2012.06.18
IPv6 IP 부여방식  (2) 2012.06.18
[암호] 암호 알고리즘 설명  (0) 2012.06.07
무선랜 표준 802.11 시리즈 정보  (0) 2012.06.06
RDF(Resource Description Framework) for 시맨틱 웹  (1) 2012.06.06
디스크 스케쥴링 기법  (0) 2012.06.01

Comment +0


안녕하세요.

이번에는 무선랜의 표준인 802.11 시리즈 형제들에 대해서 알려드리려고 합니다.


IEEE 802.11은 흔히 무선랜와이파이(Wi-Fi)라고 부르는 좁은 지역(Local Area)을 위한 컴퓨터 무선 네트워크에 사용되는 기술로, IEEE의 LAN/MAN 표준 위원회 (IEEE 802)의 11번째 워킹 그룹에서 개발된 표준 기술을 의미한다.

기술의 발전을 보자면.. 다음과 같이 발전을  했습니다.

802.11 -> 802.11b -> 802.11a -> 802.11g -> 802.11n -> 802.11i


802.11 (초기 버전)

802.11은 2Mbps의 최고속도를 지원하는 무선 네트워크 기술로, 적외선 신호나 ISM 대역인 2.4GHz 대역 전파를 사용해 데이터를 주고 받으며 여러 기기가 함께 네트워크에 참여할 수 있도록 CSMA/CA 기술을 사용한다. 하지만 규격이 엄격하게 정해지지 않아서 서로 다른 회사에서 만들어진 802.11 제품 사이에 호환성이 부족했고 속도가 느려서 널리 사용되지 않았다.

802.11b

802.11b는 802.11 규격을 기반으로 더욱 발전시킨 기술로, 최고 전송속도는 11Mbps이나 실제로는 CSMA/CA 기술의 구현 과정에서 6-7Mbps 정도의 효율을 나타내는 것으로 알려져 있다.

표준이 확정되자마자 시장에 다양한 관련 제품이 등장했고, 이전 규격에 비해 현실적인 속도를 지원해 기업이나 가정 등에 유선 네트워크를 대체하기 위한 목적으로 폭넓게 보급되었으며, 공공장소 등에서 유무상 서비스를 제공하는 업체도 생겨났다.

802.11a

세 번째로 등장한 전송방식인 802.11a는 5GHz 대역의 전파를 사용하는 규격으로, OFDM 기술을 사용해 최고 54Mbps까지의 전송 속도를 지원한다.

5GHz 대역은 2.4GHz 대역에 비해 다른 통신기기(무선 전화기, 블루투스 기기 등)와의 간섭이 적고, 더 넓은 전파 대역을 사용할 수 있다는 장점이 있지만, 신호의 특성상 장애물이나 도심 건물 등 주변 환경의 영향을 쉽게 받고, 2.4GHz 대역에서 54Mbps 속도를 지원하는 802.11g 규격이 등장하면서 현재는 널리 쓰이지 않고 있다.

802.11g

네 번째로 등장한 802.11g 규격은 a 규격과 전송 속도가 같지만 2.4GHz 대역 전파를 사용한다는 점만 다르다. 널리 사용되고 있는 802.11b 규격과 쉽게 호환되어 현재 널리 쓰이고 있다.

802.11n

 이 부분의 본문은 IEEE 802.11n-2009입니다.

802.11n은 상용화된 전송규격이다. 2.4GHz 대역과 5GHz 대역을 사용하며 최고 600Mbps 까지의 속도를 지원하고 있다. 처음 Draft 1.0 이 확정되었을 때, 대한민국의 경우 기술규격 내 주파수점유대역폭의 문제(2개의 채널점유)로 최대150Mbps이하로 속도가 제한되었으나 2007년 10월 17일 전파연구소의 기술기준고시로 300Mbps이상까지 사용할 수 있게 되었다. 이 기술의 최종 표준안은 2008년 말 제정될 예정이었으나 2009년 9월 11일에서야 IEEE 802.11n-2009이 표준안으로 제정되었고 대한민국에 현재 상용화되어 있다. 다른 규격보다 승인 규격이 엄격하고 출력 규제가 심하여, 일부 회사에서는 이 규제를 지키지 않고 있다. IEEE 802.11n-2009 표준은 최대 600Mbps까지 대역폭을 넓힐 수 있다.


그 외에도 부가 기준 표준으로는 다음과 같은 녀석들이 있습니다.

  • IEEE 802.11d - 지역 간 로밍용 확장 기술 (2001)
  • IEEE 802.11e - QoS, 패킷 버스팅 등 기능 확장 기술 (2005)
  • IEEE 802.11f - 인터 엑세스 포인트 프로토콜
  • IEEE 802.11h - 유럽용 5GHz 대역 전송방식 (2004)
  • IEEE 802.11i - 보안 확장 (2004)
  • IEEE 802.11j - 일본용 전송 방식 (2004)
  • IEEE 802.11k - 전파 자원 측정 확장 기술
  • IEEE 802.11p - 빠르게 움직이는 운송 수단을 위한 무선 접속 기술
  • IEEE 802.11r - 빠른 로밍
  • IEEE 802.11s - ESS 메쉬 네트워킹
  • IEEE 802.11t - 무선 성능 예측(WPP)
  • IEEE 802.11u - 802.11 기반이 아닌 네트워크와의 상호 연동
  • IEEE 802.11v - 무선 네트워크 관리
  • IEEE 802.11w - 보호된 관리 프레임

신고

Comment +0

안녕하세요. 이번에 설명해드리는것은 RDF라는 개념입니다.

시맨틱 웹과 함께 기존의 XML로는 한계가 있어서 탄생한 메타데이터 지원 언어라고 생각하시면 되겟습니다.


RDF(Resource Description Framework)는 인터넷과 웹 상의 메타데이터(데이터에 대한 정의나 설명)를 지원하기 위한 기반구조를 제공하기 위하여 월드 와이드 웹 컨소시엄(W3C)에 의해 개발되고 있는 규격이다. 

RDF 사용의 예를 들면, 웹페이지에 관한 데이터는 주제, 부제, 작성일자, 저자 등으로 나뉘어질 수 있는데, 이러한 데이터를 XML 태그에 의해 지시될 수 있는 필드 내에 넣으면, 검색엔진을 통해 보다 훌륭한 검색을 할 수 있게 된다. 

RDF는 웹자원의 자동화 처리에 초점을 두고 있는 것이다. 예를 들면, 날짜는 텍스트로 보기보다는 날짜는 그냥 날짜로 인식하는 것이다. 

RDF 모델과 구문규격은 1999년 2월 22일에 W3C의 권고사항이 되었다. 


다음은  XML 과 RDF의 차이점입니다.

1. 현행 웹기술이 가지는 한계점과 시멘틱웹

   가. 현행 웹의 한계점과 개선노력

       - HTML 방식의 단순 링크위주의 구조적 연결 지향

       - 자원들간의 의미적 연결의 부족 및 정보검색의 비효율성 문제 발생

   나. 현행 웹 한계점 극복을 위한 시멘틱 웹

       - 웹자원에 의미를 부여하고 이를 통해 의미적 검색이 가능하도록 하는

         차세대 웹 기술

       - URI/유니코드, XML, RDF, 온톨로지, Agent등이 핵심 기술임.

 

2. 의미적 연결을 위한 핵심 웹자원기술 언어. RDF

   가. RDF 정의

       <그림>

       - 웹자원에 대한 의미성을 부여하기 위해 자원과 속성, 속성값등의 3차원 구조를

         표현함으로서 메타데이타를 정의할 수 있는 기술언어

       - 시멘틱웹 기본사상인 의미적 연결을 위해 온토로지와 함께 핵심기술로 인식

   나. RDF 구성요소

       - 리소스

       - Statements

       - Property

 

3. RDF의 주요특징 과 XML과의 비교

   가. 웹자원기술언어 발전과정상의 XML과 RDF 비교

          SGML -> HTML -> XML -> RDF

          - SGML -> HTML : 웹활성화 초기, 단순한 웹페이 전달을 위한 표현수단

          - HTML,SGML -> XML  : 표현위주 HTML 한계 및 데이타로서의 웹자원 기술 요구

          - XML,HTML,SGML  -> RDF  : 의미적 연관성에 대한 기술 한계 극복 노력

   나. XML과 RDF 특징 비교

       목적

       핵심요소

       핵심기술

       표현대상

       활용분야

       장점

       단점

    

4. 시멘틱웹의 활성화를 위한 주요과제 및 기술적 동향

   가. 주요과제

       - 시멘틱웹 접근성 : 다양한 베스트 사례 구축 및 편의성 있는 화면 구성

       - 비즈니스 모델 : 다양한 응용시스템 구축을 통한 비즈니스 모델 개발 중요

       - 시멘틱웹 엔지니어링 : RDF 기술, 온토로지 구축관련 도구 및 방법론 개발

       - 기존 웹자원의 재활용 : Annotation기술등을 활용한 웹자원 구성

       - 차세대 연구과제 : 웹자원 검증 및 보완(Proof, Logic, 전자서명등)

   나. 기술적 동향

       1) 시멘틱웹서비스 연구

          - 분산컴퓨팅 모델인 웹서비스 기술을 접목하여 분산된 웹서비스 자원을

            지능적이고 자율적인 형태로 검색, 자동 통합을 구현하는 기술

          - W3C, DERI진영의 시멘틱 웹서비스 연구 다양 : WSMO, WSMA등

       2) u-IT839등의 소프트인프라웨어에 대한 관심 집중

          - 기존 HW중심에서 SW중심의 정책 변화 : 시멘틱웹등 중요성 인지등

신고

Comment +1

  • 작성하신 진형아빠의 개발이야기 :: RDF(Resource Description Framework) for 시맨틱 웹 글 잘 보았습니다.. 아래 자격증관련 정보도 있네요..

    유망 직종 및 모든 자격증에 대한 자료를 무료로 제공 받을수 있습니다..

    유망 자격증을 종류별로 무료 자료 신청가능하다고 하네요..

    신청 해보세요 -> http://license119.com/newki

안녕하세요. 이번에 포스팅 할 내용은 디스크 스케쥴링에 관한 내용입니다.


디스크에서 자료를 읽어 오기 위한 알고리즘이라고 생각하시면 됩니다.


우선 디스크의 평가기준을 삼는 3가지를 알려드리면...

1. 단위 시간당 처리량

2. 평균 응답시간

3. 응답시간의 예측성


이제는 기법들에 대해서 설명하겟습니다.

1.FCFS(First Come First Serve)

가장 공평한 입출력 요청 큐에 들어온 순서대로 처리하는 방식입니다. 근데 공평한데 이걸 실제로 사용하지는 않습니다. 큐의 순서대로 하기 때문에 회전수에 대해서 최적화가 되어 있지 않기 때문입니다.


2.SSTF(Shortest Seek Time First)

탐색 거리가 짧은 요청이 먼저 처리되는 기법입니다. 이 방식은 탐색거리의 최소화와 단위 시간당 처리량이 높다는 장점이 있습니다. 하지만 응답시간의 예측성이 낮기 때문에 무기한 대기와 같은 현상이 나타날수 있습니다.


3.SCAN

이건 그냥 스캔입니다. SSTF와 동일하게 동작을 하지만 진행 방향상의 가장 짧은 거리의 요청이 먼저 서비스를 받게 됩니다. 이 방식은 SSTF의 무한 대기를 해결해줍니다. 실제로 디스크들이 현재 사용하는 알고리즘의 근간입니다.


4. C-SCAN(Circular SCAN)

SCAN과 동일하지만 헤드가 바깥에서부터 안쪽으로 이동하면서 처리하는 방식입니다. 응답시간의 예측이 가장 높은 방식이라고 할 수 있습니다. 


5. sector queueing(섹터 큐잉)

고정 헤드의 알고리즘으로 회전 지연 시간만 고려하면 된다. seek time 은 없다. 

신고

Comment +0