정보처리기사(필기) 1과목 정리

최명수·2023년 2월 20일

1과목 소프트웨어 설계

소프트웨어 생명 주기

1)폭포수모형

  • 가장오래되고 가장 폭넓게 사용된 고전적 생명 주기 모형
  • 한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형
  • 단계별 정의 및 산출물이 명확
  • 개발 중간에 요구사항의 변경이 용이하지 않음
  • 타당성검토 -> 계획 -> 요구분석 -> 설계 -> 구현(코딩) -> 테스트(검사) -> 유지보수 (#분설구테유)

2)프로토타입모형

  • 견본(시제)품을 만들어 최종 결과물을 예측하는 모형
  • 인터페이스 중점을 두어 개발
  • 개발 중간에 요구사항의 변경이 용이

3)나선형모형

  • 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
  • 점진적 개발 과정 반복으로 요구사항 추가 가능
  • 정밀하고 유지보수 과정 필요 없음
  • 계획 및 정의 -> 위험분석 -> 공학적개발 -> 고객 평가
    (#계위개고)

4) 애자일 모형

  • 애자일은 민첩함,기민함 의미
  • 변화에 유연하게 대응
  • 일정한 주기(iteration, sprint)를 반복하면서 개발과정 진행
  • 절차와 도구보다 고객(개인)과의 소통에 초점을 맞춤
    ex)XP(eXtreme Programming), 스크럼(Scrum), 칸반(Kanban), 크리스탈(Crystal), 린(LEAN)
    (#엑스칸크린)
    +기능 중심 개발

스크럼(Scrum)기법

  • 팀원 스스로가 스크럼 팀 구성
  • 개발 작업에 관한 모든 것을 스스로 해결해야 함
  • 스프린트는 2~4주 정도의 기간으로 진행

1) 재품책임자(PO, Product owner)

  • 요구사항이 담긴 백로그(Backog)를 작성하는 주체
  • 백로그에 대한 우선순위를 지정, 이해관계자들의 의견을 종합

2) 스크럼 마스터(SM, Scrum Master)

  • 일일 스크럼 회의 주관
  • 팀원들을 통제하는 것이 목표가 아님

3) 개발팀(DT, Developemnt Team)

  • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
  • 최대 인원 7~8명

4) 스크럼 개발 프로세스

  • 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 -> 스크럼 검토회의 -> 스프린트 회고
    (#계스일검회)

XP기법

1) XP(eXtreme Programming)의 핵심 가치

  • 용기, 단순성, 의사소통, 피드백, 존중
    (#용단의피존)

2) 개발 프로세스

  • 사용자스토리 -> 릴리즈 계획 수립 -> 스파이크 -> 이터레이션 -> 승인검사 -> 소규모 릴리즈

3)) XP의 기본원리

  • Whole Team(전체 팀)
  • Small Releases(소규모 릴리즈)
  • Test_Driven Development(테스트 주도 개발)
  • Continuous Intergration(계속적인 통합)
  • Collective Ownership(공동 소유권)
  • Pair Prograaming(짝프로그래밍)
  • Design Improvement(디자인 개선) 또는 Refactoring(리팩토링)
    (#전소테 계공짝디)

개발 기술 환경 파악

1) 운영체제(OS, Operation System)

  • 하드웨어가 아닌 소프트웨어
  • Windows, UNIX, Linux, Mac OS | IOS, ANDROID 등등
  • 고려사항 : 가용성, 성능 | 기술지원, 구축비용, 주변 기기
    (#가성기구주)

2) 미들웨어(Middleware)

  • 운영체제와 응용 프로그램 사이에서 추가적인 서비스를 제공하는 소프트웨어

3) 데이터베이스 관리 시스템(DBMS; Database, Management System)

  • 사용자와 데이터베이스(DB) 사이에서 정보를 생성하고 DB를 관리하는 소프트웨어
  • 데이터베이스(DB)의 구성, 접근 방법, 유지관리에 대한 모든책임을 짐
  • JDBC(Java, Database, Connectivity,자바), ODBC(Open Database Connectivity, 응용프로그램)
  • Oracle, MySQL, SQLite, MongoDB, Redis 등등
  • 고려사항 : 가용성, 성능 | 기술지원, 구축비용, 상호호환성
    (#가성기구호)

4) 웹 어플리케이션 서버(WAS; Web Application Server)

  • 정적인 콘텐츠를 처리하는 웹 서버(Web Serer)와 반대됨
  • 동적인 컨텐츠를 처리하가 위해 사용되는 미들웨어(=소프트웨어)
  • 데이터 접근, 세션관리, 트랜잭션 관리 등을 위한 라이브러리를 제공
  • Tomcat, JEUS, WebLogic, JBoss, Jetty, Resin 등등
  • 고려사항 : 가용성, 성능 | 기술지원, 구축비용
    (#가성기구)

5) 오픈소스(Open Source)

  • 누구나 별다른 제한 없이 사용할 수 있도록 소스코드를 무료로 사용할 수 있게 공개한 것
  • 라이선스의 종류, 사용자 수, 기술의 지속 가능성(고려사항)
    (#라사지)

요구사항 정의

1) 기능 요구사항

  • 기능, 입력, 출력, 저장, 수행 등등

2) 비기능 요구사항

  • 성능, 품질, 제약사항, 호환성, 보완 등등

3) 요구사항 개발 프로세스

  • 도출(Elicitation)/추출 -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)/검증(Valification)
    (#도분명확 #추분명검)

4) 요구사항 분석 기법

  • 요구사항 분류
  • 개념 모델링(UML)
  • 요구사항 할당
  • 요구사항 협상
  • 정형 분석
    (#분개할협정)

5) 요구사항 확인 기법

  • 요구사항 검토
  • 프로토타이핑
  • 모델 검증
  • 인수 테스트(알파테스트, 베타테스트)
    (#검프모인)

UML

1) UML(Unified Modeling Language)의 구성 요소

  • 사물
  • 관계
  • 다이어그램
    (#사관다)

2) 사물(Things)

  • 구조
  • 행동
  • 그룹
  • 주해
    (#구행그주)

― ◇ ◆ ―▷ --> --▷

3) 관계(Relationships)

  • 연관(――)
  • 집합(◇)
  • 포함(◆)
  • 일반화(―▷)
  • 의존(-->)
  • 실체화(--▷)
    (#연집포 일의실)

4) 구조적, 정적 다이어그램(Diagram)

  • 클래스(Class)
  • 객체(Object)
  • 컴포넌트(Component)
  • 배치(Deployment)
  • 복합체 구조(Composite Structure)
  • 패키지(Package)
    (#클객컴포배복패)
  • *컴포넌트 다이어그램, 배치 다이어그램은 구현 단계 에서 사용되는 다이어 그램

5) 행위, 동적 다이어그램

  • 유스케이스(Use Case, 사용사례)
  • 시퀀스(Sequence, 순차)
  • 커뮤니케이션(Communication, 협업)
  • 상태(State)
  • 활동(Activity)
  • 상호작용 개요(Interaction Overview)
  • 타이밍(Timing)
    (#유시커 상활호타)

사용자 인터페이스(UI, User interface)

1) UI의 구분

  • CLI(Command Line Interface) : 텍스트 형태로 이뤄진 인터페이스
  • GUI(Graphical User Interface) : 마우스로 선택해 작업을 하는 그래픽 환경의 인터페이스
  • NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
  • VUI(Voice User Interface) : 사람의 음성으로 기기를 조작하는 인터페이스
  • OUI(Organic User Interface) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

2) UI의 기본원칙

  • 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야함
  • 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 함
  • 학습성 : 누구나 쉽게 배우고 익힐 수 있어야함
  • 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화 해야 함
    (#직유학연)

3) 웹의 3요소

  • 웹 표준(Web Standards)
  • 웹 접근성(Web Accessibility)
  • 웹 호환성(Cross Browsing)
    (#표접호)

4) UI 설계 도구

  • 와이어프레임(Wireframe) : 레이아웃을 협의하거나 공유하기 위해 사용
  • 스토리보드(Story Board) : 최종적으로 참고하는 작업 지침서, 작업 산출물(디스크립션)
  • 프로토타입(Prototype) : 인터랙션을 적용해 실제 구현된 것처럼 테스트가 가능한 동적인 모형
  • 목업(Mockup) : 실제 화면과 유사한 정적인 모형
  • 유스케이스(Use Case): 사용자 측면 요구사항을 다이어그램 형식으로 묘사(유스케이스 명세서)
    (#와스프목유)

5) UI 프로토타입

  • 장점 : 사용자를 설득하고 이해시키기 쉬움, 개발 시간을 줄일 수 있음, 사전 오류 발견 가능
  • 단점 : 반복적인 개선 및 보완 작업으로 인한 작업 시간 증가 및 자원 소모, 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능성
    (#페이퍼 프로토타입, 디지털 프로토타입, HTML/CSS)

6) UI 시나리오 문서 요건

  • 이해성 : 누구나 쉽게 이해할 수 있도록 설명
  • 완전성 : 최대한 상세하게 기술
  • 일관성 : 일관성 유지
  • 가독성 : 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함
  • 수정 용이성 : 수정 및 개선이 쉬워야 함
  • 추적 용이성 : 변경사항에 대해서 쉽게 추적할 수 있어야 함

7) 기타

  • HCI(Human Computer Interaction or Interface) : 사람 과 컴퓨터의 상호작용을 연구해서 사람이 컴퓨터를 편리하게 사용하도록 만드는 학문

  • UX(User Experience): 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 총체적인 경험
    (주관성, 정황성, 총체성)

품질 요구사항

1) 국제 제품 품질 표준

  • ISO/IEC 9126
  • ISO/IEC 12119 : 테스트 절차 포함
  • ISO/IEC 14598 : 별로 수행해야 할 제품 평가활동 규정
  • ISO/IEC 25010: SW 품질 평가 통합 모델 , SQuaRE로도 불리며 위 3개 표준을 통합

2) ISO/IEC 9126

  • 기능성:요구사항을 정확하게 만족하는 기능을 제공하는가?
    (적절성(적합성), 정확성, 상호 운용성, 보안성, 호환성)
  • 신뢰성:요구된 기능을 정확하고 일관되게 오류 없이 수행하는가?
    (성숙성,결함 허용성, 회복성)
  • 사용성 : 사용자가 정확하게 이해하고 사용하는가?
    (이해성,학습성,운용성,친밀성)
  • 효율성 : 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리하는가?
    (시간효율성, 자원 효율성)
  • 유지 보수성: 환경의 변화에 소프트웨어를 쉽게 개선, 확장, 수정할 수 있는가?
    (분석성, 변견성, 안정성, 시험성)
    -이식성: 소프트웨어를 다른 환경에서도 쉽게 적용 할 수 있는가?
    (적용성, 설치성, 대체성, 공존성)

(#기신사 효유이)

3) ISO/IEC 14598

  • 반복성
  • 재현성
  • 공정성
  • 객관성

4) 국제 프로세스 품질 표준

  • ISO/IEC 9001

  • ISO/IEC 12207 : 기본프로세스, 조직프로세스 ,지원 프로세스

  • ISO/IEC 15505(SPICE): 불완전 -> 수행 -> 관리 -> 확립 -> 예측 -> 최적화

  • CMMI : 조직차원의 성숙도를 평가하는 단계별 표현과 프로세스 영역별 능력도를 평가하는 연속적 표현이 있음

소프트웨어 아키텍처

  • 사용자의 비기능적 요구사항으로 나타난 제약 반영
  • 기능적 요구사항을 구현하는 방법을 찾는 해결 과정

(#모추단정)
1) 모듈화(Modularity)

  • 시스템 기능들을 모듈 단위로 나눠 소프트웨어의 성능 및 재사용성을 향상시키는 것
  • 모듈의 크기 크게하면 : 모듈 개수 적음 | 모듈 간 통합 비용 적음 | 모듈 하나의 개발 비용 큼
  • 모듈의 크기 작게하면 : 모듈 개수 많음 | 모듈 간 통합 비용 큼

2) 추상화(Abstraction)

  • 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시키는 것
  • 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악
  • 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표하는 표현으로 대체
  • 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표하는 표현으로 대체

3) 단계적 분해(Stepwise Refinement)

  • Niklaus Wirth에 의해 제안된 하향식 설계 전략
  • 추상화의 반복에 의해 세분화
  • 소프트웨어 기능에서부터 시작해 절차적으로 구체화
  • 상세한 내역은 가능한 뒤로 미루어 진행

4) 정보은닉(Information Hiding)

  • 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
  • 정보 은닉을 통한 독립적 모듈 수행 가능
  • 모듈 변경시 영향을 받지 않아 수정,시험,유지보수 용이

0개의 댓글