정보처리기사 실기 1단원

1 요구사항 확인

1-1 소프트웨어 개발 방법론

소프트웨어 생명주기(SDLC)

• 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

생명주기 모델종류

• 폭포수 모델
  • 소프트웨어 개발 시 단계를 확실히 마무리 지은 후 다음단계로
  • 고전적 생명주기 모델
  • 요구사항 변경 어려움

• 프로토타이핑 모델
  • 고객이 요구한 주요 기능을 프로토타입으로 구현

• 나선형 모델
  • 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 완벽한 시스템 개발

• 반복적 모델
  • 반복적으로 개발하여 완성시키는 모델

소프트웨어 개발 방법론

• 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법,절차,기법

개발 방법론 종류

• 구조적 방법론(Structured Development)
  • 전체 시스템을 기능에 따라 나누어 개발하고 이를 통합하는 분할과 정복 접근 방식 방법론
  • 나씨 - 슈나이더만 차트(논리의 기술에 중점을 둔 도형식 표현 방법)

• 정보공학 방법론(Information Engineering Development)
  • 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화한 방법론

• 객체지향 방법론(Object-Oriented Development)
  • 객체라는 기본 단위로 시스템을 분석 및 설계하는 방법론
  • 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템 적용하는 방법론

• 컴포넌트 기반 방법론(CBD: Component Based Development)
  • 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론

• 애자일 방법론
  • 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발

• 제품 계열 방법론(Product Line Development)
  • 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
  • 영영 공학, 응용 공학

• 애자일 방법론 유형
  • XP
    • 5가지 가치
      • 용기(courage)
      • 단순성(simplicity)
      • 의사소통(communication)

      • 피드백(FeedBack)

      • 존중(respect)
    • 12가지 기본원리
      • 짝 프로그래밍(Pair programming)

      • 공동 코드 소유(Collective OwnerShip)

      • 지속적인 통합(continuous integration)
      • 계획세우기(planning process)
      • 작은릴리즈(Small Release)
      • 메타포어(Metaphor) : 고객과 개발자간의 의사소통
      • 간단한 디자인(simple desigm)
      • 테스트 기반 개발(Test Driven Develop) : 테스트 먼저 수행하고 코드작성
      • 리팩토링(refactoring)
      • 40시간 작업
      • 고객 상주(on site customer)
      • 코드 표준(coding standard)

• 스크럼 : 정해진 시간,장소에서 짧은 시간의 개발 하는 팀을 위한 프로젝트 관리 중심 기법
  • 백로그 : 제품과 프로젝트에 대한 요구사항
  • 스프린트 : 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
  • 스크럼 미팅 : 매일 15분 정도의 미팅으로 To-do-list 계획수립
  • 스크럼 마스터 : 프로젝트 리더
  • 스프린트 회고 : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 확인,기록
  • 번 다운 차트 : 남아 있는 백로그 대비 시간을 그래픽적으로 표현한 차트

• 린 : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질 향상시키는 방법론
  • JIT,칸반보드 사용
  • 7가치 원칙
    • 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

객체 지향 분석(OOA : Object Oriented Analysis)

• 사용자의 요구사항을 분석하여 문제와 관련된 관계를 정의하여 모델링하는 기법

• 종류

  • OOSE : 야콥슨
  • OMT : 럼바우(객->동->기)
  • OOD : 부치

비용산정 모형

• 소프트웨어 규모파악을 통한 비용산정 방식
  • 하향식 산정방법
    • 경험이 많은 전문가에게 비용 산정을 의뢰
      • 전문가 판단, 델파이 기법
  • 상향식 산정 방법
    • 세부적인 요구사항과 기능에 따라 필요한 비용 계산방식
      • 코드라인수, Man Month, COCOMO모형, 푸트남 모형, 기능점수 모형

코드 라인수 모형(LOC)

• 코드 라인 수의 낙관치, 중간치, 비관치 측정
• 예측치 : 낙관치+4중간치+비관치 / 6

Man Month 모형

• LOC / 월간 생산성

COCOMO 모형

• 보햄이 제안한 모형으로 프로그램 규모에 따라 비용 산정
  • 조직형 : 5만 라인 이하
  • 반분리형 : 30만 라인 이하
  • 임베디드형 : 30만 라인 이상

푸트남 모형

• 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정
• Rayleigh-Norden 곡선 노력 분포도 사용

기능점수 모형(FP)

• 기능의 점수를 계산하여 비용 산정 방식
• 기능점수 : 총 기능 점수 [0.65+(0.1총 영향도)]

일정 관리 모델

• 일정관리 모델은 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델

• 종류

  • 주 공정법(CPM) : 수행 순서가 얽혀 있는 프로젝트 일정을 계산, 가장 긴 시간을 걸리는 경로 계산
  • PERT : 비관치,중간치, 낙관치 3점 추정방식
  • 중요 연쇄 프로젝트 관리(CCPM) : 지원제약사항 고려하여 계산

1-2 현행 시스템 분석

소프트웨어 아키텍쳐

• 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 관계를 표현하는 시스템 구조,구조체

소프트웨어 아키텍쳐 프레임워크

• 소프트웨어 아키텍쳐가 표현하는 내용, 과계를 제공하는 기술표준
• 구성요소
  • 아키텍처 명세서 : 아키텍처 기록하기 위한 산출물
  • 이해관계자 : 시스템 갭라에 관련된 사람
  • 관심사(concerns) : 시스템에 대해 이해관계자들의 서로 다른 의견과 목표
  • 관점 (viewPoint): 개별 뷰를 개발할때 토대가 되는 패턴,양식
  • 뷰 : 전체시스템 표현
  • 근거(rationale) : 아키텍쳐 결정 근거
  • 목표(mission) : 시스템 사용,운영 목적
  • 환경 : 시스템 영향을 주는 요인
  • 시스템 : 구현체

소프트웨어 아키텍처 4+1 뷰

• 유스케이스 뷰 : 유스케이스 또는 아키텍처 도출,설계,검증
  • 사용자,설계자,개발자,테스트 관점
• 논리 뷰 (Logical view) : 기능적인 요구사항이 어떻게 제공되는지 설명
  • 설계자 개발자 관점
• 프로세스 뷰 : 자원의 효율적인 사용, 병행실행, 비동기 이벤트 처리 표현
  • 개발자, 시스템 통합자 관점
• 구현 뷰(implemetation view): 정적인 소프트웨어 모듈의 구성 보여주는 뷰
• 배포 뷰(deployment view) : 어떻게 배치되는지 매핑해서 보여주는 뷰

소프트웨어 아키텍처 패턴

• 소프트웨어 설계할 때 참조할 수 있는 전형적인 해결방식
  • 계층화 패턴(layerd pattern) : 시스템을 계층으로 구분하여 구성
  • 클라이언트 서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성하는 패턴
  • 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용가능, 서브 시스템이 입력데이터를 받아 처리
  • 브로커 패턴 : 컴포넌트 들로 이루어진 분산 시스템에서 사용, 브로커 컴포넌트는 컴포넌트간의 통신을 조정하는 역할 수행
  • 모델 뷰 컨트롤러 ; MVC패턴

소프트웨어 아키텍쳐 비용 평가모델

• SAAM : 경험이 없는 조직에서 활용가능
• ATAM : 아키텍처 품질 속성을 만족시키는지 평가
• CBAM : ATAM 바탕의 시스템 아키텍어 분석 중심
• ADR : 소프트웨어 아키텍처 구성요소간의 응집도 평가모델
• ARID : 특정 부분에 대한 품질요소 집중하는 비용평가 모델

디자인 패턴

• 생성 : 클래스 정의, 객체 생성 방식 구조화
• 구조 : 클래스, 객체 조합
• 행위 : 상호 작용 방법

생성 패턴

• Builder : 복합 객체 생성
• Prototype : 일반적인 원형 만듬
• FatoryMethod : 상위 클래스에서 객체 생성하는 인터페이스 정의, 하위 클래서에서 인스턴스 생성
• Abstract Fatory : 동일한 주제의 다른 팩토리 묶음
• Singleton : 한 클래스에 한 객체만 존재

구조 패턴

• Bridge : 계층 연결
• Decorage : 기능을 추가해 나감
• Facade : 단순한 인터페이스
• Flyweight : 클래스의 경량화
• Proxy : 실체 객체에 대한 대리 객체, 정보은닉
• Composite : 부분-전체계층 표현,단일 객체와,복합객체 동일하게
• Adapter : 맞춰주는 역할

행위 패턴

• Mediator : 중간에서 통제
• Interpreter : 해석
• Iterator : 접근방법
• TemplateMethod : 일부분을 서브클래스로 캡슐화
• Observer : 한 객체의 상태가 바꾸면 그 객체에 의존하는 객체들에게 연락이감
• State : 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조
• Visitor : 클래스의 메서드가 각 클래스를 돌아다님
• Command : 요구사항을 캡슐화
• Strategy : 행위객체를 클래스로 캡슐화
• Memento : undo기능, 작업취소
• Chain of Responsibility : 하드코딩 되어있을때

DBMS : 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리

미들웨어 : 분산 컴퓨팅 환경에서 응용프로그램과, 프로그램이 운영되는 환경 간 원만한 통신이 이루어지도록 제어하는 소프트웨어

1-3 요구사항 확인

요구공학(Requirements Engineering)

• 사용자의 요구가 반영된 시스템을 개발하기 위해 도출,분석,명세,확인 검증 하는 활동

인터뷰 : 이해관계자와 직접적인 대화

브레인스토밍 : 말을 꺼내기 쉬운 분위기로 만들어 하는 회의

델파이 기법 : 전문가의 경험적 지식을 통한 문제해결

롤 플레잉 : 역할 연기

워크숍 : 단기간의 집중적인 노력을 통해 정보 공유

설문조사 : 설문지, 여론조사

비정형 명세 기법 : 자연어 기반

정형 명세 기법 : 수학적인 원리와 표기기법 사용

동료 검토 : 2~3명이 진행하는 리뷰형태

워크 스루 : 회의 전 자료를 배포해 희의 진행

인스펙션 : 저작자 외의 다른 팀이 검사

감사(Audit) : 계획 절차를 지키고 있는지 독립적으로 평가

기술리뷰(Technical Review) : 정의된 계획 명세 준수하는지 검토

관리 리뷰(management review) : 프로젝트 진행사항 검토

1-4 분석 모델 확인하기

분석 모델 검증

• 요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석보델에 대해 확인하는 활동

유스케이스 모델 검증 : 액터,유스케이스 명세서 점검