노는 게 제일 좋아

일반적으로 6가지로 나눌 수 있다. 위의 그림같이 일어난다. 용어부터 설명하자면 Caller는 callee를 부르는 주체 -> 함수를 부르는 routine을 말함. Callee는 Calling을 당하는 대상 -> 불려지는 함수를 말함 1. 메인 루틴에 $a0부터 $a3까지 argument register에 해당 파라미터를 가져다 놓음 -> 4개의 레지스터이므로 최대 4개까지의 파라미터를 보낼 수 있음. (Callee가 이용할 수 있게) 2. Caller가 Callee에게 제어를 넘김 -> 즉 Caller 루틴이 멈추고 Callee 가 실행된다는 말이다. 3. Callee가 실행되면 Callee가 필요한 자원들을 받기 위해 메모리를 할당 받는다. (보통 stack에 할당) 4. Callee 본연의 역할 수..

이제 전자가 존재할 확률이 50%인 페르미 레벨도 배웠으니까 캐리어에 대해 공부해보자 전하 캐리어 분포 다이어그램이다. **4번째 그림에서 왜 전자가 가장 밑에 쏠려서 안정된 위치에 있는 것보다 조금 위에 전자가 더 많냐면 state가 Ec 조금 위에 몰려있어서 그렇다. 페르미 레벨을 다시 해석해보면 f(E) : 전자가 있을 확률 , 1-f(E) 전자가 없을 확률 = 정공이 있을 확률 이렇게 볼 수도 있다. 이제 가장 중요한 캐리어 농도에 대해서 알아볼 것이다. 우선 들어가기 전 알아놓고 가자 Dc(E) dE : (단위부피당) E and E + dE 사이에 존재하는 energy state의 개수 f(E) Dc(E) dE : (단위부피당) E and E + dE 사이에 존재하는 전자의 개수 단위 부피당 c..

Fermi-Dirac Statistics : 각 에너지 state에 전자가 존재할 확률을 의미 Ef : Fermi Level or Fermi Energy (전자 존재 확률 = 1/2) 통상적으로 fermi level을 기준으로 그 이하에는 전자가 차있고 fermi level이상에는 전자가 거의 없다고 생각할 수 있다. 그림을 보면서 이해하자 * 열적 평형상태(Thermal equilibrium)에서의 페르미 준위 : 열적 평형상태에 있는 시스템에 대하여 단 하나의 페르미 준위만 존재한다. (페르미 준위가 기울어지거나 불연속적이지 않다.) 다시 말해서 모든 지점에 대해서 같다는 것이다. ** 볼츠만 근사한 페르미 레벨 구하는 공식은 꼭 알아야 한다. 증명하는 것은 어렵지 않다. 2가지 물질이 있고 서로 전..

https://www.youtube.com/watch?v=QJncFirhjPg 영상의 요약 및 정리 Hosting cloud 서버를 구축한다. 사람들이 이용하기 시작하고 그 사람들은 사람들을 끌어들이고 점점 사람이 많아진다. 서버는 한정되어 있는데 사람이 많아져 제대로 수행할 수 없다. 그렇다고 서버를 늘리는 것은 자본이 많이 든다. 그리고 항상 24시간 내내 서버비용은 들지만 24시간 내내 요청이 항상 많은 것도 아니다. 그래서 무턱대고 늘릴 순 없다. 그에 대한 대안이 cloud 서버다. 클라우드 서버는 내가 원하는 만큼 빌릴 수 있고 쓴 만큼 돈을 내면 된다. 그리고 클라우드는 네트워크만 연결되어 있다면 어디서든 접근 가능하다. 또한 클라우드 서버는 엄청난 크기를 가지고 있기 때문에 서버를 늘려야 ..

요구 분석 단계의 전반적인 측면을 알았다면 요구 추출에 대해서 알아보자 요구 추출이란 소프트웨어 개발에서 특별히 중요한 작업으로 사용자가 무엇은 원하는지 결정을 내리는 작업이며 여러가지 기법을 통해서 얻어진다. 요구 추출에는 세 가지 단계의 작업이 필요하다 1. 응용에 대한 정보 출처 파악 2. 응용에 대한 정보 취합 3. 요구와 제한 사항의 정의 요구 추출은 응용 분야에 대한 정보를 모으는 것부터 시작된다. 그러한 요구 추출을 위한 정보를 모으는 방법 또한 여러가지다. 고객의 발표 문헌 조사 업무 절차와 양식 조사 관련자들 설문지 사용자와의 인터뷰 브레인 스토밍 회의 사용 스토리 또는 사용사례 작성 위 방법을 통해서 정보를 모은다. ++위 방법을 통해서 얻은 요구는 우선순위로 나누면 좋다. 1. 절대적..

이제 계획은 다 세웠으니까 실제로 프로젝트를 진행해봐야겠지? 그러면 이제 고객의 요구(requirement)가 뭔지를 분석해야 요구에 맞는 소프트웨어를 개발하겠지? 그래서 이번엔 요구분석에 대해 알아보려고 한다. 요구 분석이란 새 시스템이나 변경할 시스템의 요구를 결정하는 작업으로 개발자, 관리자, 사용자 모두가 참가해서 서로의 상충되는 요구를 조정하는 단계이다. 이 단계를 잘못하면 프로젝트를 완료해도 망한 소프트웨어가 나올 게 뻔해지니까. 정말 중요한 단계다. 실제로 개발의 첫 단계로 요구 분석을 진행한다. 요구 분석은 다시 두 가지 단계로 나뉜다. 분석 단계와 요구 명세서 작성 단계 분석 단계에서는 현재 상태를 파악하고 요구를 정의하고 문제 해결과 구현될 시스템의 목표를 도출한다. 명세서 작성 과정에..

비용, 일정 예측도 했으니까 이제 누가 할 지를 짜야겠지? 그렇다면 팀은 어떻게 짤지 알아보자 축구팀 짜듯이 그냥 엎어라 뒤쳐라 하면 될까? 묵찌? 그렇게 하면 프로젝트 작살난다. 개개인의 역할을 정의하고 프로젝트에 적절히 할당해서 목표를 이뤄야한다. 비용, 일정 다 잘 예측해도 사람을 제대로 배치 안하면 망한다. //경찰한테 집에 불난 것 끄라하면 제대로 하겠나? 소방관한테 맡겨야지 그래서 서로 협력도 잘하고 상호 작용도 잘 이뤄지게 팀을 짜야한다. 각설하고 소프트웨어 개발은 조금 다른 특징을 가지고 있어서 조직 구성 방법에 따라 품질이 달라질 수 있다. //축구 포메이션이랄까? 선수는 같아도 포메이션 마다 성적이 다른 느낌?? 팀을 구성하는데 고려할 점을 살펴보자 그 후 방법을 살펴볼 것이다. 1. ..

그렇다면 이제 진짜로 일정, 날짜 같은 것을 예측해야겠지? 출시 예정일 같은 것들을 알아야 광고도 찍고 홍보도 하지 그래서 이번엔 스케줄링을 알아보려고 한다. 일정 계획(Scheduling) 개발할 소프트웨어의 규모와 인력 총량이 결정되었으면 이제는 상세한 일정을 잡아야한다. 개발 프로세스를 이루는 소작업들을 파악해서 소작업들의 순서와 일정을 정하는 일, 바로 스케줄링이다. 다시 말해서, 개발 프로세스 모델을 결정하고, 소작업, 산출물, 이정표들을 설정하는 과정이다. 일정계획은 간단하게 4단계라고 말할 수 있다. 1. 작업분해 (Work Breakdown Structure) 2. CPM (Critical Path Method) 네트워크 작성 3. 최소 소요 기간을 구함 4. 간트 (Gannt) 차트 도출..

저번 글에서 말했는데 LOC 산정이 힘들어서 기능점수로 규모를 파악할 수도 있다고 했다. 그래서 이번엔 기능 점수에 대해 알아보려고 한다. **COCOMO II에서 기능점수를 이용한다. 기능 점수란 소프트웨어 시스템이 가지는 기능을 정량화한 것이다. LOC의 예측은 힘들기 때문에 시스템이 가질 기능의 개수로 규모를 판단하는 것이다. ** 이 방법은 경험 중심적인 방법으로 비즈니스 응용 분야의 소프트웨어 개발비용 산정에 정확하다고 한다. ** 기능 점수를 이용해서 예측하려면 생산성 메트릭이 있어야한다. 다시 말해서 단위 시간당 프로그래머의 생산성을 기능 점수로 표현한 자료가 있어야한다. 기능 점수(function points)  소프트웨어 규모를 측정하는 방법  기능적 요구 사항이 중심이 되는 측정 방..

프로젝트 계획 작업에서는 비용 예측과 기간 예측이 정말 정말 중요하다. 그래서 그러한 예측은 어떻게 하는지 알아보자. 소프트웨어 개발 비용의 대부분은 인력에 대한 비용이라서 대부분 MM(man - month)로 초점이 맞춰져있다. 그 이유는 소프트웨어는 다른 공학과는 다르게 원자재라는 것이 거의 없다. 인건비 + 하드웨어 + 소프트웨어 비용 + 사무실, 재료비 등 이것이 비용의 전부인 경우가 많다. 그 또한 인건비가 대부분이라 비용 예측이 사실 노력 예측이라고 말해도 과언이 아니다. 그렇다면 노력 예측은 어떻게 해야하는 것일까? 건축 공사와 달리 개발자 중심 개발자의 능력에 따른 생산성의 차이 다양한 개발 프로세스로 인한 표준화/자동화의 어려움 사람 by 사람이다 보니까 예측이 너무 어렵다. 그래도 비용..