※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 3. 커널과 시스템 호출 응용프로그램의 자원 접근 문제 오늘날의 운영체제는 다중프로그래밍 운영체제이다 문제 응용 프로그램이 직접 하드웨어에 접근하면 충돌 및 훼손 가능성 매우 큼 ex) 타 응용 프로그램이 적재된 메모리 훼손, 또는 만들어둔 파일 삭제 및 훼손, 커널이 적재된 영역 훼손 해결 응용프로그램의 모든 하드웨어 직접접근 불허, 오직 커널만이 가능 구체적인 해결 메모리 공간을 사용자 공간(응용프로그램 적재)과 커널 공간(커널 적재)으로 분리 CPU의 실행모드를 사용자 모드와 커널 모드로 분리 응용프로그램은 사용자모드에서만, 커널 코드는 커널모드에서만 because, 사용자 공간에서 커널 공간 직접접근 못하게 하기 위해, 접근 시도시 응용프로그..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 1. 컴퓨터 시스템과 하드웨어 컴퓨터 시스템 계층 응용 프로그램층 : 사용자와 가장 가까운 계층. 운영체제층 : 그림처럼 사용자가 하드웨어로 직접 접근하는 것을 막는다. 하드웨어층 계층의 특징 사용자 : 응용프로그램과 GUI, 툴을 이용해 컴퓨터를 활용함 운영체제 : 하드웨어에 대한 배타적 독점 권한 → 사용자는 하드웨어에 직접 접근할 수 없고, 오직 운영체제를 통해 접근 ∴ 운영체제는 응용프로그램과 하드웨어간의 중계를 담당한다. 그리고 사용자가 하드웨어에 대해 몰라도 컴퓨터를 사용할 수 있도록 한다. 컴퓨터 하드웨어 구성 CPU (Central Processing Unit, 중앙 처리 장치) instruction 해석하여 실행 n비트 cpu -> ..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 1. 도출 설명 비즈니스 분석가가 이해관계자로부터 목표 시스테에 바라는 요구를 식별하는 단계 요구사항 도출 기법 인터뷰 직접 대화를 통해 요구사항 도출 개인, 소규모 그룹을 대상으로 실시 → 통제 수월 라포, 경청 범위에서 벗어나면 안됨 폐쇄적 X, 개방형 질문 O 폐쇄적 질문 : y/n과 같이 미리 정해진 해답을 가지는 질문. 보통 확인 용도 개방형 질문 : 답이 정해지지 않음. 상세한 정보 획득 용도 5 Whys 기법으로 문제의 근본 원인 식별 워크숍 이해관계자들의 협업을 통핸 요구사항 도출 및 정의 다양힌 이해관계자들, facilitator(촉진자), 서기 참여 특정 주제 기반의 의견 공유 다양한 이해관계자의 요구사항 동시 도출 의견 충돌 해소..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 요구사항의 중요성 아직도 많은 프로젝트들은 도전중이다(https://codejin.tistory.com/250) 프로젝트의 성공, 도전, 실패의 주 원인은 요구사항에 있다. 즉, 요구사항이 잘 되는지 안되는지는 곧 해당 프로젝트의 흥망성쇠를 결정하는 셈이다. 요구사항이란? 문제 해결을 위해 무엇을 구현해야 하는가에 대한 명세 시스템이 동작한느 방법, 속성, 혹은 특성을 설명 시스템 개발 프로세스의 일종의 제약 조건 요구사항 분류 위로 갈수록 범위가 크다(추상적이다) / high level이다 Business requirements why? 이윤증가, 비용절감, 이윤 방어, 미래에 소용될 수 있는 비용 절감 제품을 개발함으로써 얻을 수 있는 이득을 명..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ Scrum scrum이란 agile 방법론의 한 종류 agile은 하나의 방법론이기 때문에, agile 원칙을 지키는 방법론들은 모두 agile 방법론이라고 할 수 있다. scrum 역시 agile 방법론을 지키는 방법론이고, 즉 agile 방법론의 한 종류이다. scrum process agile에서의 iteration을 scurm에서는 sprint라고 한다. sprint의 소요시간은 해당 프로젝트 시행동안 고정된다. 2주면 2주, 10일이면 10일 sprint가 끝나고 잠재적으로 출 시할 수 있는 제품을 increment라고 한다. sprint backlog sprint 기간동안 해야할 일이 담긴 목록 Product backlog에서 우선순위에 ..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 1. RAD 정의 Rapid Application Development의 약자로, 앱(프로젝트)의 빠른 개발을 위한 모델로, 사용자의 지속적 참여하에 빠르게 프로그램을 개발하기 위한 개발 라이프 사이클 모델. waterfall 모델과는 정반대로 사용자(고객)의 지속적 참여하에 빠르게 application을 개발하는것이 목표 사용자가 지속해서 참여하기 때문에 사용자는 개발 과정에서 지속적인 피드백을 전달하고, 개발자는 이러한 피드백을 개발과정에서 반영하여 지속적으로 개선 개발자는 빠른 개발을 위해 app의 자동 생성 도구를 사용하여 개발 특징 고객 참여: 고객의 요구사항 정의, 분석, 설계 신속개발: 기술위험 적음 짧은 개발주기: 코드 재사용 및 자동..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 1. 정의 사용자와 하드웨어 사이에서 중계 역할을 하며, 프로그램의 실행을 관리하고 제어하는 시스템 소프트웨어 컴퓨터가 켜질 때 처음 적재되어, 나머지 모든 프로그램의 실행을 제어하고, 사용자의 요청을 처리하는 소프트웨어 컴퓨터의 자원을 독점적으로 관리하는 특별한 소프트웨어 단어별 분석 자원 하드웨어 자원 - CPU, 캐시, 메모리, 키보드, 마우스, 디스플레이, 하드디스크, 프린터 등등 소프트웨어 자원 - 응용 프로그램 데이터 자원 - 파일, DB등 독점 자원에 관한 모든 권한은 운영체제에 있다. 자원 할당, 공유, 액세스, 입출력 ex) 파일 생성 - 디스크 빈 공간 관리, 파일 저장 위치 관리, IO 등 관리(관리자, supervisor) 실행..
※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※ 1. 소프트웨어 위기 1960년대 많은 프로젝트들이 완성되지 못하고 실패하며, F.L.바우어가 1968년 독일 가미시에서 열린 첫번째 나토 SW 공학 학회에서 처음 사용한 단어이다. 실패의 이유는 다양한데, 다음과 같다. 프로젝트 예산 초과 프로젝트 일정 지연 결과물(소프트웨어)의 품질이 낮음 결과물이 요구사항을 만족하지 못함 결과물이 (여러 이유로 인해) 고객의 손에 전달되지 못함. 이로 인해 소프트웨어공학이 생겨났다. The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that ..
