IT자격증

함수종속관계가 아래와 같다
     A -> BC,  CD -> E,  B -> D,  E -> A

1) A 가 후보키인지..
    A->BC 이므로 분해규칙에 의해  A->B , A->C     => B,C 결정가능
    A->B 이고 B->D 이므로 이행규칙에 의해 A->D   => D 결정가능
    A->D 이면 첨가규칙에 의해 CA -> CD 이고 CD->E 이므로  
                   이행규칙에 의해 CA->E     => E  결정가능

2) B 가 후보키인지..
    B->D 이면 첨가규칙에 의해 CB -> CD 이고 CD->E 이므로 CB->E   => D, E  결정가능
    CB->E 이고 E->A 이므로     => A 결정가능 , C 는 불가능                       

3) BC 가 후보키인지..
    B->D 이므로 첨가규칙에 의해 BC->CD 이므로                => C,D 결정가능
    BC->CD 이고 CD->E 이므로 이행규칙에 의해 BC->E      =>  E 결정가능
    BC->E 이고 E->A 이므로 이행규칙에 의해 BC->A          =>  A 결정가능

4) E 가 후보키인지..
    E->A 이고 A가 후보키 이므로  모든 원소 결정가능


----------------------------------------------------------------------------------------------
문) 릴레이션 R(A,B,C,D) 에서 다음과 같은 함수적 종속성이 성립할 때,이 릴레이션의 키는 ?
      B->C , (A,B)->D ,  C->D

답) 

   A 가 키라면 D만 찾을수 있고
    B 가 키라면 D, C 만 찾고 A는 못찾고
    (B,C) 가 키라면 역시 A는 못찾음
    따라서 (A,B) 가 키   

정보시스템 감리기준의 구성

  제1장 총칙
  제2장 감리 실시시기 및 인력배치
  제3장 감리 업무절차
  제4장 감리법인 등록 및 관리
  제5장 감리원의 교육 및 자격
  제6장 보칙

   [별표1] 감리대가 산정기준
   [별표2] 감리제안서 기술평가 기준
   [별표3] 감리교육 면제 기준



감리 실시시기

감리인력 배치기준

감리 제안서 주요내용

감리제안서 기술평가 항목

- 평가항목은 감리대상사업의 유형 및 특성에 따라 가감 조정
- 총 배점한도는 100점이며, 각 평가항목별 배점한도는 30점 이내



[출처 : 118회 정보관리기술사 모임 - 두드림]

구조적 방법론 (1970년대)

정보공학적 방법론 (1980년대)

객체지향 방법론 (1990년대)

CBD 방법론 (2000년대)

 - 재사용이 가능한 Component의 개발 또는 상용 컴포넌트들을 조합하여 어플리케이션 개발

RAD (Rapid Application Development)

- 조직이 전략적으로 중요한시스템을 빠르게 개발하면서도 개발비용을 줄이고 
   품질을 유지할 수 있게 해주는 방법론.
 - 제한된 범위의 단독시스템을 CASE를 사용하여 신속하게 개발하는 방법.
 - CAST Tool을 이용해서 고객과 같이 개발
 - 1~3개월 정도 소요
 - 위험이 낮은 Project에 적합
 - 단계 : JRP(분석) -> JAD(설계) -> 구축.운영
 - 필수요건 : ① SWAT
                  ② Database (Repository)
                  ③ Timebox (요구사항 관리)
                  ④ CASE ( 상위CASE - 요구사항 분석,설계
                                  중위CASE - 설계
                                  하위CASE - 소스코드)

RUP (Rational Unified Process)

UML을 기반으로 한 객체지향 소프트웨어 프로세스 모델
 - 예정된 일정과 예산에서 고객이 만족할 수 있는 소프트웨어 개발
 - Jacobson의 UseCase Driven 방법을 도입한 방법론이다.
 - 소프트웨어 개발의 전체 생명주기를 지원하는 프로젝트 FrameWork 이다.
 - 각 단계를 반복하면서 위험요소를 줄일 수 있다.
 - 반복을 하기 때문에 개발도중 요구사항 변경,환경변화등에 유연하게 대처가 가능
 - UseCase기반 , 아키텍쳐 중심 , 반복 점진적 개발 프로세스
 - 게발기간이 길고 대규모 시스템에 적합
단점 : 내용자체가 방대해서 처음 객체지향 방법론을 접하는 사람에게는 어렵다

                       * 인식,정련,구축,전이 단계는 각각 반복을 할 수 있다.

Clean Room Model

 - 시스템의 가장 핵심이 되는 부분을 최초 Increment(실행 가능한 프로토타입) 
   로 개발하여  사용자에게 피드백을 하여 새로운 요구를 끄집어 내거나 개발
   계획 자체를 다시 고쳐서 반복해서 증가분 소프트웨어를 개발시스템에 
   추가하여 가는 생각을 기초로 하고있다.
 - 소트프웨어를 정형적으로 명세화하고 여러 증분 (Increment)으로 나누어
   별도로 개발하고 검증하되 신뢰성을 결정하기 위해 통계적으로 테스트 한다.

1. 폭포수 모델

      - 개념 정립에서 구현까지 하향식 접근방법 (높은 추상화 단계 -> 낮은 추상화 단계)
      - 응용분야가 단순하고 잘 알고있는경우에 적합
      - 비전문가가 사용할 시스템 개발에 적합
      - 단계별 결과물이 명확해야 한다.
      - 설계와 코딩 및 테스트를 지연시킬 우려가 있다.
      - 시스템의 요구가 설계단계로 넘어가기전에 동결됨을 가정
     - 문서와 결과물 도출에 중점.
     -  단점 : 프로토타입과 재사용의 기회가 줄어든다
                 일정에 융통성이 없으며 이전단계로의 회귀,반복이 계속 된다면 소요자원이 계속 
                 증가할수 있다
                 최종단계가 가야지 결과물을 알수있다.
                 초기에 요구사항 정의가 어려움.
                 중요한 문제점의 발견이 늦어짐.
     - 용도 : 이미 잘알고 있는 문제나 연구중심의 소프트웨어 개발에 적합
                위험이 적은 프로젝트에 적합
                유사한 프로젝트 경험이 있는 경우
                요구사항이 명확히 정의되어 있는 경우


프로토타이핑 모델

      - 요구사항을 초기에 명세하기가 어려운 경우 적합 (요구사항이 모호함)
      - 프로토타입에는 사용자의 경험으로 가치있는 의견을 회수할 만한 기능만을 포함시킨다.
      - 예외처리, 회복, 표준이나 형식의 준수와 같은 것은 포함시키지 않는다.
      - 품질보다는 빠르게 만들어야 한다.
      - 장점 : 요구사항 도출이 용이.
                 시스템의 이해와 품질 향상
                 개발자와 사용자간 의사소통 원활
                 개발의 타당성 검증.
      - 단점 : 발주자가 프로토타입이 최종결과라 믿고 곧 소프트웨어가 개발될꺼라고 오해
                 폐기에 따른 비경제성
                 프로토타입이 전체시스템의 일부분임에도 불구하고 발주자가 개발일정 단축을 
                 요구할수 있어 품질을 저하시킬 수 있다.
               : 프로토타입이 과대선전되어 인수해야할 제품보다 더 많은 기능을 기대하게 된다.
               : 프로토타이핑 과정을 관리,통제 하기 어렵다
               : 중간과정을 점검할 수 있는 일정표와 산출물이 어렵다.
               : 발주자의 참여을 계획하는 것이 쉽지않다.             
      - 종류 : 실험적 프로타이핑 - 시제품 폐기
                 진화적 프로타이핑 - 나선형 모델


나선형 모델

      - 위험분석을 기반으로 한 반복개발
      - 선형모델의 체계적인 측면과 프로토타이핑의 반복적 특성을 결합시킨 형태의 모델
      - 계획수립 - 위험분석 - 개발 - 평가 
      - 대규모시스템을 개발하는데 적합
      - 각 확장단계에서 발생될 위험에 대한 이해와 대책이 가능하다.
      - 비선형적이며 반복적으로 개발이 진행되므로 소프트웨어 품질 중 강인성을 높일수 
       있는 방법이다.
      - 재정적, 기술적으로 위험부담이 큰 경우 위험분석을 해나가면서 시스템 발전
      - 요구사항이나 아키텍쳐를 이해하기 어렵거나, 근본적으로 성능에 문제가 되는 경우
     - 장점 : 정확한 사용자 요구사항 파악
                : 위험부담 감소
                : 품질확보
      - 단점 : 프로젝트 개발에 많은 시간 소요
                 프로젝트 관리에 어려움 
                 충분한 검증 미흡 (참조 사이트가 적음)


점증적 모델

      - 사용자 요구사항의 일부분 또는 제품의 일부분을 반복적으로 개발하여 최종제품을 
        완성하는 모델
         (폭포수모델 + 프로토타이핑 모델 + 나선형 모델)
      - 폭포수모델의 변형으로 증분을 따로 개발 후 통합하는 방법으로 포로토타입의 
        반복개념을 선형순차모델의  요소들에 결합시킨 것.
      - 프로토타이핑과 같이 반복적이나 각 점증이 갖는 제품 인도에 초점
      - Big Bang 릴리스를 보완하려는 방법이다.
      - 릴리스를 여러 번 나누어서 하면서 기능을 확장 개발해 나가는 방법
      ① 점증(증분)적(Incremental) 방법 : 기능별로 하나씩 개발하면서 릴리스 
      ② 반복(진화)적(Iterative) 방법 : 처음부터 전체기능을 개발하되 릴리스할때마다 
                                                그 기능을을 더 완벽히 개발
      - 장점 : 릴리스할때마다 사용자로부터 피드백을을 받아 사용자의 요구사항을
                 빠르게 반영할 수 있다.
               : 증분을 정확히 계획하고, 릴리스한다는 점에서 진화적 모형과는 다르며
              , 고객에게 모든 증분을
               릴리스하고 고객의 우선순위를 고려한다는 점에서 agile 방법론과 비슷하다.


V 모델

      - 폭포수모델에 시스템검증과 테스트 작업을 강조한 것이다.
      - 폭포수모형은 문서와 결과물에 중점을 두는 반면, V모델은 작업과 결과의 
         검증에 초점을 둔다,.
      - 장점 : 모든 단계에 확인과 검증 과정이 있어 오류를 줄일 수 있다
      - 단점 : 생명주기의 반복을 허용하지 않아 변경을 다루기가 쉽지않다.
                 작업이 종료되고 리뷰 후에는 관련된 결과물이 동결된다.
     - 적합 : 높은 신뢰성이 필요한 응용분야 (의료제어시스템, 원전제어시스템...)
                요구의 명세가 확실하여 개발하는 동안 변경이 없는경우에만 적합

소프트웨어 안전성 분석의 필요성

소프트웨어의 규모가 커지고,복잡해지고, SW가 우리 생활 전반을 관리.지원.통제.조종하는 
영역이 날로 커지고 있지만 소프트웨어의 기능적 실패(Failure)를 발생시키는 위험(Hazard)
요소를 파악하고 사전 예방하는 것이 어려워지고 있다. 
이런 기능적 실패는 곧 대형사고로도 이어질수 있는데.. 예를 들면 안전 필수 시스템
(자율주행자동차, 원자력, 항공, 철도)에서의 기능적 사고는 소프트웨어적 문제를 넘어서
인명피해, 환경오염 등으로 이어지므로 기능적 실패 방지를 위해 예산과 인력 투입과 더불어
, SW의 안전성 분석 노력이 필요하다.


소프트웨어 안전성 분석의 개념

정의	시스템이 만족해야 할 안전성을 만족하는지 확인하는 활동 - 수용 또는 허용 가능한 위험성을 분류하고 설계, 제작 및 운영 단계에서 각종 안전    기능 또는 안전대책을 마련하여 위험성 크기를 줄이는 활동
목적	위험 식별, 위험 영향분석, 위험 원인 분석 - 분석 기법에 따라 한 가지 이상의 목적을 달성할 수 있기 때문에 목적에 따라 기법    선택
특징	① 귀납적〮◌연역적 방식 구분 : 위험과 위험의 원인을 도출하는 방법으로 구분 ② 상향식〮◌하향식 기법 구분 : 안전성 분석 수행 시 시스템을 바라보는 관점으로 구분 ③ 정성적〮◌정량적 결과 : 정성적은 도출이 쉽고 비용 절감, 정량적은 객관적이지만 복잡 ④ 분석시기, 분석가의 전문성 요구정도 : 사용 시기, 적용 대상, 분석 범위 등의 결정

                        < 출처 : 118회 정보관리기술사 모임 - 두드림 >



소프트웨어 안전성 분석 기법 소개

FTA (Fault Tree Analysis)

● 정의
- 특정 사고에 대한 연역적 해석을 통해 사건 사고의 원인 파악 및 설비결함, 작업 실수 등을
  발견 및 분석하는 기법
- 시스템의 기능과 고장에 대한 정보를 트리 구조로 제공
- 위험이 발생할 원인들을 분석할 수는 있으나, 위험을 찾아내는 기법은 아님.
- 항공,전자공학,원자력 등 다양한 분야에서 사용되고 있음
-  Root에 의도하지 않은 이벤트를 두고, 이를 발생시킬 수 있는  
   잠재적인  faulty event 또는 normal mode를 노드(node)로 표현
   하고 이것들은 and/or 를 사용해 시각화해서 보여주는 방식.
● 장점 : 개발의 모든 단계에서 사용가능함.

FMEA (Failure Mode and Effects Analysis)

●정의
- 컴포넌트(서브시스템) 자체에 고장발생 원인이 개입되는 것을 피하기 위한 기법이다.
  그래서 주로 분석/설계단계에서 고장발생원인을 사전에 제거하기 위한 목적으로 활용
- 고장 발생의 원인 및 중대 사고에 영향을 미치는 직접적인 원인인 서브시스템이나
  컴포넌트의 잠재적 고장 유형을 분석하는 기법 
- 심각도/발생도/검출도를 통해 고장으로 인한 시스템 영향 정량적 분석 
- 분석 결과에 따라 우선순위(RPN)을 부여하여 대응방안 수립
- 존재하고 있는 잠재적인 고장, 문제, 오류들이 사용자단까지 가기전에
  찾고(Identify), 정의하고(define), 제거하는(eliminate) 방식
- 먼저 모든 컴포넌트를 리스트형태로 정의하고, 각각의 고장모드(Failure Mode) 가
  영향을 미칠(Effects Analysis) 모든 컴포넌트, 시스템을 정의하고 각각의 고장모드의
  가능성과 심각성을 개선하는 단계로 진행

HAZOP (Hazard and Operability Analysis)

●정의
이 방법은 위험과 시스템운영상의 위협요소를 조사하는 기법이다.
기본적으로 시스템을 검토하고 잠재적인 위험을 찾는 것이 목적이며
브레인스토밍 단계에서 Guide Word를 이용한다는 특징이 있다.
- 시스템의 기능요건과 같은 매개번수와 가이드워드의 조합을 통해서 예상치 못한 
  동작과 그에 따른 영향을 분석하는 기법
- 도출된 행위가 시스템의 안전에 어떤 영향을 미칠수 있는 지 분석

- 보통 공장설비 프로세스에 존재하는 해저드(Hazard)와 운용상의 문제점
  (Operability Problems)을 찾아내는 정성적 분석 기법이다.
- HAZOP 분석은 시스템의 원래 의도한 설계와 차이가 있는 변이(deviations)를
  일련의 가이드워드(guidewords)를 활용하여 체계적으로 식별해 낸다

● HAZOP 분석 절차

 1) 분석대상 노드(Node) 선정
     - 어떤 프로세스상의 주요 변화가 발생하여 Hazard 와 운영상의 문제점이 발생
       할 가능성이 있는 프로세스의 한 부분을 말한다.
        ex) 액체온도가 변경되는 열교환기,  압력증가가 발생하는 펌프시스템

 2) 프로세스 파라미터 선정
     - 위험요인을 가진 시스템 구성요소의 물리적 특성
        ex) 온도,압력,

 3) 가이드워드(Guide word) 적용
     - 가이드워드는 분석 팀 멤버들이 프로세스 파라미터의 가능한 변이(deviations)를
       생각(상상)해 내는데 도움이 되는 짤막한 단어/문구들이다.
     - 가이드워드의 역할은 일련의 표준 질문을 프로세스 파라미터에 반복적으로
       적용하여 정상 조건으로부터 벗어나는 변이(deviations)를 체계적이고 일관성 있게
       도출하도록 해주는 것이다
     ex) 가이드워드

 4) 의도한 정상 설계에서 벗어나는 변이(deviations) 식별

• 가이드워드를 선정된 프로세스 파라미터에 적용하여 발생 가능한 변이(deviation)를
  찾는다.
  예를 들어 가이드워드 "No"가 파라미터 "flow"에 적용되면 "no flow" 라는 하나의
  deviation이 생성됨
• 아래와 같이 가이드워드와 프로세스 파라미터를 조합하는 매트릭스를 활용한다.
• 모든 가이드워드+파라미터조합이 의미 있는 것은 아니므로 매트릭스 상의
  빈 칸이 존재(분석이 필요 없는 경우)

 5) 변이를 초래하는 원인(causes) 파악

• 변이(deviation)가 발생하는 이유를 찾는다. 특정 변이를 초래하는 원인(causes)이
  한 가지 이상일 수도 있다.
• 발생 가능성이 지나치게 낮은 원인은 분석 팀의 판단에 따라 리스트에서 제외될
  수도 있다.
• 원인의 유형으로 크게 세 가지가 있다.
  - 사람 에러(Human error): 오퍼레이터, 설계가, 제조자, 기타 관련 작업자의 행위로
                                     인해 심각한 결과를 초래하는 위험이 발생
  - 장비 오류(Equipment failure): 기계적, 구조적, 운용상의 결함으로 인해 위험 발생
  - 외부 요인(External events): 외부 요인이 노드 운용에 영향을 주어 위험을 발생시킴
                                       (예, 정전, 수도 공급 중단, 날씨, 지진, 유관 노드의 장애 등)

 6) 변이로 인한 결과(consequences) 파악

     - 변이 발생에 따른 결과(피해, 문제점)를 파악한다.
       즉, 해당 변이가 시설 셧다운이나 제품 품질 저하 같은 프로세스 해저드(process hazards)
       와 운용 문제(operability problems)를 야기하는지 분석한다.
     - 변이의 영향은 안전성(safety), 환경(environmental), 경제성(economic) 측면에서 따져볼
        수 있다.

 7) 변이의 안전책(Safeguards) 고려

 8) HAZOP 분석 프로세스 반복 및 결과 보고서 작성

<발췌 : https://grapevine9700.tistory.com/216 >

소프트웨어를 개발하는 프로그래머라면 누구나 Refactoring 의 필요성을 공감하지만
실제 Refactoring을 하는 건 솔직히 엄두가 안난다.. 왜냐.. 괜히 잘 돌아가는 프로그램을
건드렸다가 에러라도 나면 어쩌나 하는 두려움이 들기 때문이다.
처음부터 코딩을 할때 어떤 코딩 Rule을 지키면서 한다면 그나마 refactoring 할 이유가
적어지지만 실제 코딩을 하다보면 결국 소스가 흔히 말하는 지저분하게 될수 밖에 없다.
중복되는 소스, 하나의 Function에 많은 기능을 구현, 캡슐화 대신 직접 멤버변수 참조 등
의 코딩 (Code Smell) 을 하게 된다는 말이다..

간단하게 Refactoring의 사례를 살펴보면 다음과 같아.
 - 기능변화 없이 중복제거, 단순화, 유연성 추가
   1.Method 정의 - 지나치게 긴 Method 를 분리
                       - 지나치게  긴 문장을 Method를 사용하여 단순화
   2.위치이동 - Method난 변수 위치를 적절한 Class로 이동
   3.캡슐화 - 멤버변수를 Get/Set 사용하여 캡슐화
   4.조건문 단순화 - 긴 조건문을 분할하거나 method 화 하여 단순화
   5.이름변경 - 이해하기 쉬운 이름으로 변경
   6.Indentation - 가독성이 있는 Indent로 재포맷


Refactoring 정의 및 개념

1. 원래 기능은 유지하면서 낮은 가독성, 중복된 로직, 확장 제한적 코드 등 
   (코드 스멜, Code Smell)을 제거함으로써 SW 내부 구조를 개선하여 코드 품질을 향상시키는
   SW 개선 기법
2. 외부 기능을 변경하지 않으면서 내부 구조를 개선하는 방법으로, Refactoring을 할 때는 기능을
   추가해서는 안 되고, 단지 코드의 구조에만 신경을 써야 한다.

Refactoring 대상 , Code Smell 종류

리펙토링(Refactoring) 주요 기법

PaaS 기반의 SW개발 방법론 대두 배경

예전에 소프트웨어를 개발할려면 C, C++ 와 같은 저수준 Language나 Power Builder, Visual-Vasic 같은
고수준 언어를 이용해서 개발하면서 프린터같은 HW 및 OS단까지 직접 제어를 하도록 코딩하는 경우
가 많았다.  하지만 오늘날에는 SW 개발 그 자체에 집중해 보다 민첩하고 완성도 높은 제품을 만들어내는
것이 중요하게 여겨지고 있다. 이에 따라 인프라와 미들웨어, 기타 개발지원도구들을 포함한 PaaS 형태의
SW 개발환경 서비스가 주목받고 있다. 

오늘날 기업의 모든 인프라와 IT 자원이 서비스로 옮겨가고 있다(Everyting as a Service).
처음에는 IT 자원을 공유하는 개념으로만 출발했지만 지금은 SaaS가 빠르게 발전하고 있다.
이는 SW개발환경 역시 마찬가지다. OS 위에서 컴파일러를 사용한 개발언어 중심으로 애플리케이션을
개발하던 1세대에 비해, 오늘날 5세대 SW개발환경은 클라우드 환경에서 제공되는 IaaS/PaaS를 활용해
HW를 직접 도입하거나 설정하지 않고도 SW를 개발하고 있다.
클라우드 기반의 SW개발환경은 기존에 비해 매우 높은 생산성을 가질 수 있다. 이는 HW를 구매하고
설치하는 시간, 개발을 위한 프레임워크나 운영서버 등을 구성하는 시간 등 개발환경 구성에 투입되는
상당한 시간들을 개발에 집중할 수 있기 때문이다. PaaS 기반의 SW개발환경을 사용하면 거의
대부분의 시간을 직접적인 SW개발에만 투자할 수 있다. 또한 개발환경을 안정적으로 운영하는
과정이 필요없어 최소한의 인력만으로 SW를 개발할 수 있으며, 비즈니스 성장 등에 따라 서비스를
민첩하고 탄력적으로 운영할 수 있다.
(발췌 : ITDaily : http://www.itdaily.kr/news/articleView.html?idxno=93897)

PaaS 기발 SW개발 사례

■"SW 개발-배포-운영까지 클라우드 기반으로"

삼성SDS는 약 10년전 삼성SDS는 국내와 해외를 포함해 6개의 데이터센터를 운영했지만 올해엔
국내외 15개 데이터센터를 운영하고 서버와 스토리지 네트워크 등 주요 인프라는 10배 이상으로 늘렸다.
윤심 클라우드사업부장(부사장)은 "삼성 SDS는 클라우드 환경을 감안해 앱 개발단계부터 배포, 운영까지
모두 클라우드 시스템을 이용토록 삼성SDS 플랫폼서비스(PaaS)를 개발했다"고 말했다. 덩치 큰 앱은
여러개의 모듈로 나눠 부품처럼 일부만 수정해 갱신하게 한다.
개발한 앱을 여러개 사업 현장에 배포할때도 클라우드에서 한번에 할 수 있도록 자동화했다.
개발팀이 수정한 앱은 운영팀이 즉시 공유할 수 있도록 '데브옵스(DevOps)'라는 개발·운영팀 공유도구도
제공한다.
(기사 : 파이낸셜뉴스 / "삼성SDS PaaS로 덩치 큰 앱도 부품처럼 일부만 수정")


PaaS 기반의 SW 개발 방법론 주요 구성요소

                                  < 출처 : 정보관리기술사 118회 모임 : 두드림 >


PaaS 기반의 SW 개발 수행 절차