일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 버스시간표
- 가톨릭
- Lover
- 설계도
- 일기처럼 보이는 뻘글
- 광주-해남
- 정보보호론
- swap
- 추가채용
- 일기처럼 보이는 잡글
- 정보
- 해남종합버스터미널
- 반복문
- 끄적끄적
- 잡담만설
- 슈퍼탱크대작전
- 전산직
- 오블완
- 말씀새기기
- 리안이
- 해남버스터미널
- 천주교
- NICU
- 육아일기
- 오늘의토픽
- 일상
- 컴퓨터일반
- 티스토리챌린지
- 슈퍼탱크럼블
- c언어
- Today
- Total
목록9급 공무원 (91)
리안이와 함께하는 세상
: 업무 활동 중심의 방법론으로 정형화 된 절차 및 도형 중심의 도구를 사용하여 사용자 유구 사항 파악 및 문서화 하는 기법* 특징 - 정보와 정보의 구조를 중심으로 분석, 설계 구현 - 정형화된 분석절차에 따라 사용자 요구 사항을 파악하고 도형 중심의 다이어그램을 이용하여 문서화 - GOTO 분기 대신 3개의 논리구조로 구성하여 프로그램 흐름의 복잡성 감소 > 3개의 논리구조 : 순차(Sequencing), 선택(Selection), 반복(Iteration)* 장·단점 - 장점 > 일괄 처리 방식인 자료변환을 중심으로 하는 응용 S/W개발에 적합 > 소프트웨어 및 시스템 개발의 전형적인 접근법(기능은 사용자의 1차적 요구사항) - 단점 > 기능은 업무영역에서 불안정한 요소 > 데이터가 은닉되지 않음 >..
: 조직에서 수행을 향상시키기 위해 업무절차들을 체계화하는 일 (= 역량 성숙도 모형 결합)* Level : Initial(초기) > Managed(관리) > Defined(정의) > Quantitatively Managed(정량적 관리) > Optimizing(최척화) Level 1 Initial : 소프트웨어 개발 프로세스가 거의 없는 상태 > 성패가 개인의 역량에 달림, Level 2 Managed : 프로젝트를 위한 표준 프로세스가 존재 > 일정이나 비용과 같은 관리 프로세스 중심 > 목표 및 활동이 정량적으로 측정되지는 못함Level 3 Defined : 조직을 위한 표준 프로세스가 존재 > 모든 프로젝트는 조직의 프로세스를 가져다 상황에 맞게 조정하여 승인 받아 사용Level 4 Quantit..
: 프로그램의 규모에 의한 비용예측 모형 > 미리 준비된 식과 표를 이용하여 비용을 산정한다. > 소프트웨어 개발 견적에 가장 널리 이용되고 있는 방법 * 계층 : Basic, Intermediate, Detail 1. Basic COCOMO : 스프트웨어의 츠기와 개발 모드에 의해 구함 2. Intermediate COCOMO : Basic의 확장, 15개의 비용요소 가미하여 곱한 가중치 를 이용하여 구함 3. Detail COCOMO : 시스템을 세분화(모듈, 서브시스템) 하여 Intermediate 적용 * 프로젝트 모드 : Organic, SemiDetached, embedded 1. Organic : 5만 라인 이하의 프로젝트에 적합(소규모 팀이 개발하는 잘 알려진 응용 시스템) 2. Semid..
* 생명주기 : 폭포수(waterfall), 프로토타입(prototype), 익스트림 프로그래밍(XP), 나선형(Spiral) ...※ 일반적인 개발 단계 : 계획(Planning) > 분석(Analysis) > 설계(Design) > 구현(Implementation) > 유지보수(Maintenance) 1. 폭포수 모델 * - 정해진 단계와 일정에 따라 구체적인 중간 산출물을 만들어 냄. - 요구사항이 이해하기 쉽고, 시스템 개발 중 급격한 변경이 없는 경우 효과적 - 각 단계가 확실히 끝나야 다음 단계로 넘어간다 - 단계별 매뉴얼을 작성해야한다. - 단계별로 명확한 산출물이 있다. - 한 단계의 문제점을 해결하기 위해 이전단계로 피드백 되어야 한다. - 개발이 완료되고 사용하기 전까지 사용자 의견을 ..
: 논리적 시스템 요소: 유형성 > 시각적 형태를 가진다(분석 or 설계 문서) ※ 무형성(비가시성) > 완제품의 구조가 코드안에 숨어있어 파악하기 힘들다.: 동적행위성 > 하드웨어 상에서 작동하는 프로그램이다.: 상품성 > 사용자가 구매의사에 따라 살 수 있다.: 견고성 > 구조변경이나 수정이 용이하지 않다. / 일부의 수정으로 소프트웨어 전체에 영향을 준다.: 비마모성 > 닳거나 소멸되지 않는다.: 비제조성 > 제조가 아니라 개발된다. not like 하드웨어: 비조립성: 비과학성 > 개발자체는 과학적이지 않고, 조직, 인력, 시간, 비용, 절차 등이 중심이다.: 복잡성 > 개발과정이 복잡하고 표준화되어있지 않아 이해와 관리가 어렵다.: 순응성 > 사용자의 요구나 환경변화에 적절히 변경할 수 있다.:..
: 자료를 검색할 때, 탐색이나 첨자가 아닌, 내용에 의해 필요한 자료에 도달하는 기법 > 사전 찾아보는거랑 비슷함. > 해시 테이블을 이용해 탐색을 수행한다. (자료가 해시테이블에 저장됨) > 자료를 찾아주는 함수를 해싱 함수라 한다. > 서로 다른 자료가 해싱 함수에 의해 같은 값을 생성하는 경우, 충돌(Collision)이라고 한다. > 탐색 시간이 O(1)에 가깝다! (엄청 빠르제?) > 공간 사용률이 70% ~ 80% 에 이르면 성능 저하가 나타난다! (공간을 포기하고 성능을 선택한다!) * 해싱 함수(Hashing Function): 어떤 키 K에 대한 테이블의 주소를 계산하기 위한 방법 > 주어진 키 값으로부터레코드(원하는 자료)가 저장되어 있는 주소를 산출해낼 수 있는 공식! - 충돌(co..