- 글쓴시간
- 분류 문화,취미
드디어 디아블로가 내손에 들어왔습니다.
월급 받으면 사겠다는 약속
지켰습니다. ㅠ_ㅠ
얼마나 플레이할 수 있을지는 또다른 이야기이지만요.
윈디하나의 블로그
윈디하나의 누리사랑방. 이런 저런 얘기
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 문화,취미
크라이시스 3(Crysis 3)
크라이시스 3의 플레이 이미지가 나왔습니다.이정도면 전에 올린 배틀 필드보다도 더 향상된거 같네요. (나중에 나온거니 당연하겠습니다만)
크라이시스 3 공식 스샷(리사이즈)
늪지대 그래픽은 오브젝트가 많고 어둡기 때문에 대충(?) 그려도 티가 안 납니다만, 확대해놓고 봐도 이정도면 수준급이군요.
크라이시스 3 공식 스샷(리사이즈)
이정도 돌리려면 필요한 사양이 얼마나 될까요? 1080p에서 돌리려고 해도 GTX680가지고도 안될지도 모른단 생각이 드네요. 최소사양이 현재 GT450으로 되어있고 DirectX 11 지원 필수라네요.
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT
- 주로 SI나 군수 산업에서 하는 개발 프로세스에서, 기술 검토 및 회의를 많이 한다. 특히 군수 산업의 경우, 프로젝트 진행시에 거쳐가야 할 회의가 많다. 군수 산업은 참조할 사이트가 없기 때문이다. 군수 관련된 정보는 공개가 안 되어있고, 타국과 공유도 안되기 때문에 스스로 개발해야 하는 만큼 회의가 많다. SI에서는 이중 일부만 몇개 하는 정도로 보면 된다.
- 회사마다 다르지만 SRR, PDR 정도는 해야 한다는게 내 지론. 기본 설계만 같이 모여서 하고 나머지는 필요할때 회의하면 된다.
체계요구사항 검토회의(SRR, System Requirement Review)
체계기능 검토회의(SFR, System Function Review)
체계설계 검토회의(SDR, System Design Review)
기본설계 검토회의(PDR, Preliminary Design Review)
상세설계 검토회의(CDR, Critical Design Review)
최종설계 검토회의(FDR, Final Design Review)
시험준비 검토회의(TRR, Test Readiness Review)
체계검증 검토회의(SVR, System Verification Review)
기능적 형상확인(FCA, Functional Configuration Audit)
생산준비 상태검토(PRR, Production Readiness Review)
물리적 형상확인(PCA, Physical Configuration Audit)
사업관리 검토회의(PMR, Project Management Review)
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT
※ 비용 산정 방식에는 크게 아래의 3가지가 있다.
- FP: Function Point(기능 점수)
- LOC: Line of Code(코드의 라인수)
- M/M: Man per Month(월간 인력수)
※ FP는 요구 사항별로 점수(난이도)를 매기고, 인력에도 인력이 구현 가능한 점수를 매긴후에, 각각을 대입해 비용을 산정한다. 자세히 설명하기엔 길기 때문에 하단의 링크를 가보자.
※ LOC는 코드 라인당 얼마 하는 식으로 비용을 산정한다. 1줄의 코드 라인을 작성하는데 걸리는 시간이 다르기 때문에 올바른 비용 산정방식은 아니다.
※ M/M 은 요구 사항을 수행할 수 있는 시간을 계산한 후 인력의 급수(초급, 중급, 고급, 특급, ...)에 따라 비용을 산정한다. A라는 요구사항은 "중급 인력이 1개월동안 수행해야 요구사항을 만족할 수 있음"의 경우 "A 요구사항은 중급 1M/M 이 필요"하다고 말한다. 투입되는 인력에겐 보통 "월급"을 주기 때문에, M/M 으로도 산정하는 경우가 많다.
※ M/M과 유사한걸로 M/D와 M/H 가 있다. M/D는 Man per Day(일간 인력수), M/H는 Man per Hour(시간당 인력수)다. 한달은 20일, 하루는 8시간으로 계산해 환산하면 된다.
※ 보통 인력 비용 산정에 대해서는 발주처에서 가이드가 나온다. FP로 산정할지 M/M으로 산정할지 말이다.
※ 요즘엔 기능점수위주로 산정한다고는 하지만 아직도 M/M위주로 가는 곳이 적지 않다. FP방식은 FP를 산정하고 검증하는데 전문 인력이 필요하기 때문이다. 전문 인력이 없는 곳에서는 LOC나 M/M 밖에 산정되질 않는다.
※ 그렇다고는 해도 LOC는 좀 너무했다는 느낌. 개발자의 능력을 검증하는건, 개발자 능력 검증 방법을 수십년동안 연구한 사람들도 어렵다고 하는 거라 말이다.
----
기능 점수 산정: http://windy.luru.net/1847
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음
- 글쓴시간
- 분류 기술,IT/하드웨어 정보
쿼드코어에 하이퍼쓰레드 지원 모델. 코어당 2쓰레드를 쓸 일은 거의 없긴 하지만, 어째 기분은 괜찮음. 전 직장에서도 쿼드코어(Core2 Quad Q8300)였지만 하이퍼쓰레드는 지원되지 않았다. 그렇다고 지금 쓰는 CPU가 딱히 빠르다고 느껴지지는 않음. 놋북에서 인코딩할 것도 아니고 말이다.
놋북용이라 TDP는 45W로 매우 낮은 편. 그렇다고 놋북 쓰기에 발열이 없는건 아니다. 프로그래밍 하는데도 디버깅 할 때면 약간 따뜻해지는듯.
4코어, 8쓰레드이긴 하지만, 그다지 8쓰레드의 느낌은 안 나는듯. 인코딩을 한번 돌려봐야 느낄 수 있으려남.
캐시
- 응답
- RSS / ATOM 피드를 통해 답글을 트랙할 수 있음