[정처기 필기] 1과목 소프트웨어 설계

해피데빙·2024년 6월 25일
0

자격증

목록 보기
1/1
post-thumbnail

1. 소프트웨어

1. 소프트웨어 생명 주기

  • 소프트웨어를 개발하기 위해 정의
  • 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
  • 소프트웨어 개발 단계 : 각 단계별 주요 활동 + 활동의 결과에 대한 산출물
  • 소프트웨어 프로세스 모형 : 소프트웨어 생명 주기를 표현하는 형태
    (= 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임)

2. 소프트웨어 공학

  • 개념: 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
  • 방법 : 여러가지 방법론과 도구, 관리 기법들을 통하여
  • 목적 : 소프트웨어의 품질(결과물)과 생산성(효율성, 성공률) 향상을 목적으로 한다
  • 기본 원칙: 업데이트, 품질 유지, 기록
    - 현대적인 프로그래밍 기술을 계속적으로 적용 필요
    • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증
    • 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록 유지 필요

3. 소프트웨어 생명 주기 모형

1. 폭포수 모형

  • 이전 단계가 제대로 끝나야 다음 단계로 갈 수 있는 선형 순차적 모형
    (이전 단계로 돌아갈 수 없다)
  • 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
    (고전적 생명 주기 모형)

ex. 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현 -> 시험 -> 유지 보수

2. 나선형 모형 (점진적 모형)

  • 보헴이 제안
  • 폭포수 모형의 장점 + 프로토타입 모형의 장점 + 위험 분석 기능 추가
  • 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발 (점진적 모형)
  • 목적: 소프트웨어를 개발하면서 발생할 수 있는 위험 최소화
  • 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고 정밀하며 유지보수 과정이 필요 없다

3. 애자일 모형

  • 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정 진행
  • 어느 특정 방법론이 아님
  • 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론은 통칭한다
  • 기업 활동 전반에 걸쳐 사용된다
  • 애자일 모형을 기반으로 하는 소프트웨어 개발 모형들
    : 스크럼, XP, 칸반, 린, 크리스탈, ASD, 기능 중심 개발, DSDM, DAD 등

1) 애자일 개발 4가지 핵심 가치

  1. 프로세스와 도구 < 개인과 상호작용
  2. 방대한 문서 < 실행되는 SW
  3. 계약 협상 < 고객과 협업
  4. 계획 < 변화에 반응

2) 스크럼의 개요

스크럼
팀이 중심이 되어 개발의 효율성을 높인다는 의미

  • 팀원 스스로가 스크럼 팀을 구성
  • 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다
  • 스크럼 팀 : 제품 책임자, 스크럼 마스터, 개발팀

1️⃣ 제품 책임자(Product Owner) : 의사결정, 의견 수합, 요구사항 작성

  • 이해관계자들 중 개발될 제품에 대한 이해도가 높다
  • 요구사항을 책임지고 의사 결정할 사람
  • 개발 의뢰자나 사용자가 담당
  • 이해 관계자들의 의견을 종합해 제품에 대한 요구사항 작성
  • 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신한다

2️⃣ 스크럼 마스터(Scrum Master) : 조언 및 관리하는 가이드

  • 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할 수행
  • 팀원들을 통제하는 것이 목표는 X
  • 일일 스크럼 회의를 주관하여 진행 사항을 점검하고 개발 과정에서 발생된 장애 요소를 공론화하여 처리

3️⃣ 개발팀(Development Team) : 이외 모두 (비개발자 포함)

  • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
  • 개발자 외에도 디자인, 테스터 등 제품 개발을 위해 참여한 모든 사람이 대상이 된다
  • 보통 최대 인원은 7~8명이 적당

3. 스크럼 개발 프로세스

(1) 제품 백로그

  • 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록

(2) 스프린트 계획 회의

  • 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것

(3) 스프린트

  • 실제 개발 작업을 진행하는 과정
  • 보통 2~4주 정도의 기간 내에서 진행함
  • 스프린트 백로그에 작성된 태스크를 대상으로 속도를 추정한 후 개발 담당자에게 할당함

(4) 일일 스크럼 회의

  • 모든 팀원이 매일 약속된 시간에 약 15분 정도 진행 상황 점검
  • 회의는 보통 서서 진행 남은 직업 시간은 소멸 차트에 표시

(5) 스프린트 검토 회의

  • 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 확인
  • 사용자가 포함된 참석자 앞에서 테스팅을 수행함

(6) 스프린트 회고

  • 스프린트 주기를 되돌아보며 규칙 준수 정도, 개선할 점 확인 및 기록

4. XP와 주요 실천 방법

XP

  • 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
  • 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발
  • 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높인다

xp의 5가지 핵심 가치
: 의사소통, 단순성, 용기, 존중, 피드백

(1) Pair programming
: 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성
(2) 공동 코드 소유
: 개발 코드에 대한 권한과 책임을 공동으로 소유함
(3) 테스트 주도 개발
: 테스트 케이스를 먼저 작성하고 실제 코드를 작성해서 무엇을 해야할지 정확히 파악함
: 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크)를 사용함
(4) 전체 팀
: 개발에 참여하는 모든 구성원(고객 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함
(5) 걔속적인 통합
: 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합됨
(6) 디자인 개선 또는 리팩토링
: 프로그램 기능의 변경 없이, 단순화, 유연성 강화 등을 통해 시스템을 재구성함
(7) 소규모 릴리즈
: 릴리즈 기간을 짧게 반복함으로서 고객의 요구 변화에 신속히 대응 가능

4. 현행 시스템 파악

1단계

  • 시스템 구성 파악
    : 조직의 주요 업무를 담당하는 기간 업무 + 이를 지원하는 지원 업무로 구분하여 기술
  • 시스템 기능 파악
    : 현재 제공하는 기능들 = 주요 기능 + 하부 기능 + 세부 기능으로 구분 (계층형으로 표시)
  • 시스템 인터페이스 파악
    : 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등 명시

2단계

  • 아키텍처 구성 파악
    : 최상위 수준에서 계층별로 표현한 아키텍처 구성도를 작성함
  • 소프트웨어 구성 파악
    : 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함

3단계

  • 하드웨어 구성 파악
    : 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 서버의 이중화의 적용 여부를 명시함
  • 네트워크 구성 파악
    : 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도 작성함

5. 운영체제

1) 컴퓨터 시스템의 자원들을 효율적으로 관리
2) 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어

  • 컴퓨터 사용자 -인터페이스로서 동작하는 시스템 소프트웨어의 일종- 컴퓨터 하드웨어
  • 다른 응용 프로그램이 유용한 작업을 할 수 있도록 환경을 제공해준다
  • 컴퓨터 운영체제의 종류 : windows, unix, linux, mac os 등
  • 모바일 운영체제의 종류 : iOS, Android 등

운영체제 관련 요구사항 식별 시 고려사항
: 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

6. 데이터베이스 관리 시스템(DBMS)

DBMS 관련 요구사항 식별 시 고려사항
: 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

7. 웹 애플리케이션 서버(WAS)

8. 요구사항

1. 요구사항 정의

2. 요구사항 개발 프로세스

3. 요구사항 명세 기법

4. 요구사항 분석의 개요

9. 자료 프름도(DFD)

10. 자료 사전

11. 요구사항 분석을 위한 CASE(자동화 도구)

12. HIPO

13. UML

14. 관계

15. 다이어그램

1. 스테레오 타입

2. 유스케이스 다이어그램

3. 클래스 다이어그램

4. 순차 다이어그램

16. 사용자 인터페이스(UI)

1. 사용자 인터페이스의 특징

2. 사용자 인터페이스의 구분

3. 사용자 인터페이스의 기본 원칙

4. 사용자 인터페이스의 설계 지침

5. 사용자 인터페이스 개발 시스템의 기능

17. UI 설계 도구

18. 품질 요구사항

19. UI 요소

20. 소프트웨어 설계

1. 상위 설계와 하위 설계

2. 소프트웨어 아키텍처 설계의 기본 원리

3. 소프트웨어 아키텍처의 품질 속성

4. 소프트웨어 아키텍처의 설계 과정

21. 협약에 의한 설계

22. 패턴

1. 파이프-필터 패턴

2. 모델-뷰-컨트롤러 패턴

3. 기타 패턴

23. 객체

24. 클래스

25. 캡슐화

26. 상속

27. 다형성

28. 연관성

29. 객체지향 분석의 방법론

1. 럼바우 분석 기법

2. 객체지향 설계 원칙

30. 결합도

31. 응집도

32. 팬인/팬아웃

33. N-S 차트

34. 공통 모듈의 개요

35. 재사용

36. 효과적인 모듈 설계 방안

37. 코드의 개요

1. 개요

2. 코드의 종류

38. 패턴

1. 디자인 패턴

1. 개요

2. 장단점

2. 생성 패턴

3. 구조 패턴

4. 행위 패턴

39. 요구사항 검증 방법

40. 시스템 연계 기술

41. 연계 매커니즘 구성요소

42. 미들웨어

profile
노션 : https://garrulous-gander-3f2.notion.site/c488d337791c4c4cb6d93cb9fcc26f17

0개의 댓글

Powered by GraphCDN, the GraphQL CDN