|
||||
|
1. 전통적인 정보시스템 개발 단계 - 요구분석 : 사용자의 요구분석을 추출 - 분석단계 : 명세서(시스템이 처리해야할 정보 / 시스템이 제공해야할 기능) 작성 - 설계단계 : 개발팀이 어떻게 구현할지 기술, 모듈단위로 시스템을 분할, 모듈의 알고리즘과 데이타구조를 '설계서'에 기술 - 구현단계 : 프로그램언어로 설계단계의 내용을 토대로 구현 - 유지보수 : 시스템이 설치되고, 결함을 제거하거나 기능을 확장하기 위한 변경 - 퇴출 : 10~15년 유지보수 후엔 유용한 서비스를 제공하지 못하기에 퇴출 2, 수정 유지보수, 완전 유지보수, 적응 유지보수 - 수정 유지보수 : 시스템의 결함을 조치하는 것, 산출물에 결함이 있다면 이를 수정하는 유지보수 - 완전 유지보수 : 고객의 요구에 의해 시스템의 기능을 확장하면서 발생하는 유지보수 - 적응 유지보수 : 시스템이 운용되는 환경의 변화로 인한 유지보수 3. 회귀결함(Regression Fault)이란 무엇이며, 피할 수 있는 방법은? - 시스템 한곳에서 변경이 발생하면 다른 무관한 곳에 결함이 유발되는 것으로 설계과정에서 시스템을 독립적인 모듈로 구성해서 독립성을 높여주면 회귀결함을 어느정도 피할 수 있음 4. 밀러의 법칙은 무엇이며, 이 법칙이 의미하는 프로세스는? - 사람이 한번에 처리할 수 있는 정보의 양이 7개로 제한되어 있기에 요구사항중 중요한 7가지를 먼저 처리후에 다음으로 중요한 7개의 요구사항을 처리후 계속적으로 통합하는 방식의 프로세스로써 점증적 프로세스이다. 5. 시스템 개발 방법 중 반복점증적 방법론의 장점 - 시스템이 올바르게 구현되고 있는지 점검할 수 있는 기회가 많아짐. : 결함을 발견하고 수정할 수 있는 기회 제공, 비용 절감 - 아키텍처가 확고한지 조기에 시험해서 결정 가능 : 아키텍처(Architecture) : 시스템을 구성하는 컴포넌트 모듈과 이들을 결합하는 방법 : 견고성(robustness) : 확장이나 변경이 용이한 특성 - 위험을 조기에 완화할 수 있게 해줌 : 조기에 적절한 의사결정을 내릴 수 있음 - 시스템이 항상 실행 가능한 형태로 존재한다는 점. : 시스템의 변경/수정 사항을 조기에 발견 가능 : 사용자의 두려움 최소화, 시스템의 기능 습득 용이 6. 객체지향 방법론의 주요 특징(상속, 정보은닉, ... ) 현금카드와 신용카드는 속성의 많은 부분이 일치 - 두 카드를 일반화하여 하나의 Bank Card(은행카드) 클래스를 만들고, 그것을 상속하여 쓰는 것이 바람직함 상속은 객체지향 특징 중 필수, 일반화(generalization)의 구현 정보은닉이 이루어지면, 회귀결함(regression faults) 를 없앨 수 있음. 정보은닉의 사용 시스템은 독립적인 클래스들로 구성됨 각각의 클래스들은 메시지를 전달함으로써 통신을 함 7. 객체지향 방법론에서 일반화 관계(generalization), 집합 관계(aggregation), 연관관계(association)에서 적절한 방법을 이용하여 사람의 몸을 표현하기 8. 비즈니스 모델을 수립하기 위해 필요한 정보를 얻기 위한 방법들(인터뷰, 설문서,...)의 특징 1. 구조적 인터뷰 : 특별히 미리 계획된 질문 : 폐쇄형 질문(close-ended) : 명확한 대답 요구 2. 비구조적 인터뷰 : 연결 질문 : 개방형 질문(open-ended) : 자유 답변 : 광범위한 정보 제공( 자유로운 대답 유도) : 필요한 정보와 관련된 내용 범위 내에 있어야 함 - 인터뷰를 하는 면접자가 업무영역에 충분히 정통해 있어야 함. 면접자가 고객이 필요로 하는 것을 인터뷰 전에 결정하였다면 인터뷰는 무의미해질 수 있음. 면접자는 선입견 없이 신중하게 듣는 태도로 인터뷰에 임해야 함 3. 설문서 : 많은 구성원들의 요구사항 수렴에 유용 : 높은 정확성(신중하게 작성된 의견) : 비구조적 인터뷰가 더 좋은 정보 도출할 수 있다. - 설문서는 미리 계획된 것들이므로, 응답의 결과에 따라 추가적인 부연 질문을 제시할 방법이 없음 4. 양식 : 각종 보고서나 전표 등의 여러 양식 : 직무명세서(무슨 업무를 어떻게 수행하는지를 파악가능) 5. 관찰법 : 비디오 카메라 등의 활용 : 종업원들의 협조가 매우 중요( 프라이버시 침해 문제) : 테이프 분석에 긴 시간이 소요 9. 통합프로세스에는 엔티티, 화면, 통제 클래스가 있다. 각 클래스들이 표현하는 것은? 엔티티 클래스는 시스템이 정보를 오랫동안 유지해야하는 경우에 지정하는 클래스이다. 초기 클래스 모델링을 통해서 속성등을 함께 결정한다. 기능-클래스-동적모델링을 통해서 정제함. 화면클래스 - 일반적으로 입력화면, 출력화면, 보고서등이 클래스로 모델화 된 것이 화면클래스이다. 통제클래스 - 중요한 연산을 수행하는 엔티티는 통제클래스가 될 수 있다. 10. 상호작용 다이어그램(interaction diagram)은 순차 다이어그램(sequence diagram)과 협력 다이어그램(collaboration diagram)으로 나누어지는데, 사용사례 내 특정 시나리오의 실현을 표현한다. 11. 수정(versiom)과 변종(vatiation)의 예를 들어보면? 수정 - 정보시스템이 구축된 이후에 산출물(문서와 모듈을 포함하는)에 오류가 발생할 경우 그 문제점을 해결하여 나온 산출물이 새로운 버전의 시스템이 되다. 변종 - 한 정보시스템에서 각각 새로운 환경에서의 실행을 위해서 병렬적으로 존재. 예로 한 PC에 레이져와 잉크젯 프린터가 있으면 두 개의 프린터 드라이버가 공존하게 된다. 12. 실행기반(execution-based) 테스트와 비실행기반(nonexecution-based) 테스트란 무엇이며, 그 종류에는 어떠한 것들이 있는가. - 실행기반 : 컴퓨터 상에서 실행하고 그 결과물을 검사 ->현재의 오류를 찾아내기 위해 노력해야함. 효용성, 신뢰성, 견고성, 성능, 정확성에 대한 실행기반 테스트 필요 효용성 - 시스템이 고객의 요구를 어느정도까지 만족시키는지에 대한 척도(얼마나 쉽고, 유용한 기능을 수행하며, 다른 시스템과 비교해서 비용적 우월성이 있는지 판단) 신뢰성 - 시스템의 실패 빈도와 위험정도를 측정하는 기준(얼마나 자주 실패하는지와 얼마나 나쁜 영향을 미치는지에 대한 측정) 견고성 - 운영조건의 범위, 타당한 데이터에 대하여 의미없는 결과가 나올 가능성, 의미없는 데이터에 대한 나오는 결과의 허용성등으로 측정(비정상적 데이터 입력시 잘못된 데이터라고 판단하는게 좋음) 성능 - 반응시간 또는 공간에 관련된 제약을 얼마만큼 만족시키는지 측정. 명세서에 반응이 2초라고하면 실제로 그 제약이 만족하는지 측정 정확성 - 명세서에기술된 내용이 모두 적용이 되었는지 또한 중요 블랙박스 테스트 - 실제 정보 시스템의 기능이 작동하는지 검사 화이트박스 테스트 - 단순한 기능 기반이 아닌 직접 코드를 검사. 실행되는 모든 코드 검사 - 비실행기반 : 문서나 명세서를 꼼꼼하게 읽고 확인 13. 파일과 데이터베이스의 차이점 데이터베이스는 논리적 구조로 된 데이터의 집합체로서 그 구조는 다르지만 물리적으로 기록된다는 점은 파일과 같습니다. 데이터베이스는 DBMS 를 통해서 데이터에 대한 핸들링을 하며 실제 DBMS가 물리적인 파일의 내용을 핸들링합니다. 또한 사용자 권한과 같은 다양한 기능을 제공하고 다양한 독립적 플렛폼에서 유동적으로 연동이 가능합니다. 반면 파일은 사용자가 직접 소스코드를 작성하여 세세한 내용을 핸들링해야 하며 범용으로 사용이 어렵습니다. 14. 용어 설명 (1) 아웃소싱 기업 업무의 일부 프로세스를 경영 효과 및 효율의 극대화를 위한 방안으로 제3자에게 위탁해 처리하는 것을 말한다. 다른 의미로는 외부 전산 전문업체가 고객의 정보처리 업무의 일부 또는 전부를 장기간 운영·관리하는 것을 뜻하기도 한다. (2) 제안요청서(RFP: Request For Proposal) 하드웨어 및 소프트웨어를 취득할 때, 제조사에 제안서의 제출을 의뢰하기 위해 작성하는 서류, 또는 그 의뢰를 하는 것. (3) 이동표적 문제(Moving Target Problem) 요구사항의 변경으로 인하여 발생하는 문제로 해결책이 없음. (4) 사용사례(use case) 시스템이 수항할것으로 기대되는 기능을 말한다. 일정한 기능에 대한 모든 가능한 시나리오를 나타낸 것이다. (5) 정보시스템의 형상(configuration) 시스템의 버젼이나 기능적 또는 물리적인 특성들을 일컫는 말 형상 관리 : 시스템 형상 요소의 기능적 특성이나 물리적 특성을 문서화하고 그들 특성의 변경을 관리하며, 변경의 과정이나 실현 상황을 기록·보고하여 지정된 요건이 충족되었다는 사실을 검증하는 것, 또는 그 과정. | ||||
