[정보처리기사/필기] 1장. 요구사항 확인(1)

Happy Jiwon·2023년 1월 3일
2

정보처리기사

목록 보기
1/5
post-thumbnail

시작하기 전...

학교 편입하고 4학년.... 드디어 !!!!! 정보처리기사 필기 자격이 생겼다!!! ㅜㅜ
그래서 공부한 내용을 바탕으로 정리해볼 예정이다 후후.. 필기 준비하시는 분들 저와 같이 합격해주세요 감사합니다.

[소프트웨어 설계] 1장. 요구사항 확인

먼저 1과목은 소프트웨어 설계로 요구사항 확인, 화면 설계, 애플리케이션 설계, 인터페이스 설계가 있다. 이번 블로그에는 요구사항 확인에 대해 요약해볼 예정이다.
가보자고~~~!


1. 소프트웨어 생명 주기

1-1) 소프트웨어 생명주기 개념

소프트웨어 생명 주기는 소프트웨어 개발 방법론 의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.

💡 소프트웨어 개발 방법론이란??
소프트웨어 개발과 유지보수 등에 필요한 여러 가지 작업들의 수행 방법과 이러한 작업들을 좀 더 효율적으로 수행하기 위해 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것

소프트웨어 생명주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라 하며, 소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임이라고도 한다.

일반적으로 사용되는 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있다.

다음 4가지 모형에 대해 설명하겠다.

1-2) 폭포수 모형 (Waterfall Model)

  • 폭포수 모형은 한 단계가 완전히 끝나야만 다음 단계로 넘어가는 개발 방법론이라는 것을 우선 기억하자!!!
  • 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용
  • 선형 순차적 모형
  • 모형을 적용한 경험과 성공사례가 많음
  • 결과물이 명확하게 산출되어야 함
  • 두 개 이상의 과정 ➜ 병행 수행 X
  • 제품의 일부가 될 매뉴얼을 작성해야 함
  • 개발이 완료된 시점에서 오류가 발견되는 단점이 있음

💡 소프트웨어 공학(SE: Software Engineering)
소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이며 여러가지 방법론과 도구, 관리 기법들을 통해 소프트웨어의 품질과 생산성을 향상시킬 목적으로 한다.
💡매뉴얼
프로그램들의 사용과 운영에 대한 내용이 기술되어 있는 문서

폭포수 모형 개발 과정

타당성 검토 ➜ 계획 ➜ 요구분석 ➜ 설계 ➜ 구현(코딩) ➜ 시험(검사) ➜ 유지보수

1-3) 프로토타입 모형 (Prototype Model, 원형 모형)

  • 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측 하는 모형이다.
  • 인터페이스 중점
  • 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점 보완한 모형

프로토타입 모형 개발 과정

(시작) 요구수집 ➜ 빠른 설계 ➜ 프로토타입 구축 ➜ 고객 평가 ➜ 프로토 타입 조정 ➜ 구현(끝)

1-4) 나선형 모형(Spiral Model, 점진적 모형)

  • 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
  • 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로 점진적 모형이라고도 한다.
  • 개발하면서 발생할 수 있는 위험을 관리하고 최소화 하는 것을 목적
  • 유지보수 과정 필요 없음

나선형 모형 개발 과정

계획 수립 ➜ 위험 분석 ➜ 개발 및 검증 ➜ 고객 평가 (의 반복)

1-5) 애자일 모형(Agile Model)

  • 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 개발과정을 진행함
  • 기업 활동 전반에 걸쳐 사용
  • 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발 주기 반복, 그 결과물에 대한 고객의 평ㄱ와 요구를 적극 수용함

    💡 애자일 모형을 기반으로 하는 소프트웨어 개발 모형
    스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Develpment) , 기능 중심 개발(FDD: Feature Driven Develpment(, DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery)등이 있다.

구분폭포수 모형애자일
새로운 요구사항 반영어려움지속적으로 반영
고객과 의사소통적음지속적
테스트마지막반복되는 일정 주기가 끝날 때 마다 테스트
개발 중심계획, 문서 (매뉴얼)고객

애자일 개발 4가지 핵심 가치
1. 프로세스, 도구 보단 개인과 상호작용에 더 가치를 둔다.
2. 방대한 문서보단 SW
3. 계약 협상 보단 고객과의 협업
4 게획을 따르기 보단 변화에 반응


2. 스크럼(Scrum) 기법

2-1) 스크럼 개념

팀이 중심이 되어 개발의 효율성을 높인다는 의미를 중점으로 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다.

2-2) 제품 책임자 (PO: Product Owner)

  • 이해관계자들 중 개발 제품에 대한 이해도가 높고, 요구사항을 책임지며 의사 결정할 사람으로 선정(주로 개발 의뢰자나 사용자가 담당)

  • 요구사항이 담긴 백로그(Backlog)를 작성하고 우선순위를 지정

  • 팀원들이 백로그를 추가할 수 있지만 우선순위 지정 불가

  • 테스트를 수행하면서 주기적으로 우선순위 갱신

    💡 이해 관계자
    소프트웨어 개발과 관련해서 의뢰자, 개발자, 사용자 등을 나타낸다.

    💡 백로그(Backlog)
    제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록

2-3) 스크럼 마스터 (SM: Scrum Master)

  • 객관적인 시각에서 조언을 해주는 가이드 역할을 수행

2-4) 개발팀(DT: Development Team)

  • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원(디자이너, 테스터 등 모든 사람이 대상)
    • 최대 인원은 7~8명

스크럼 개발 프로세스

제품 백로그 (Product Backlog)

  • 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열
  • 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획(Release Plan)을 수행한다.

스프린트 계획 회의 (Sprint Planning Meeting)

  • 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립
  • 스프린트 백로그를 작성

스프린트 (Sprint)

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

일일 스크럼 회의 (Daily Scrum Meeting)

  • 모든 팀원이 매일 약속된 시간에 약 15분 정도 짧은 시간동안 진행 상황 점검
  • 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와준다.

스프린트 검토 회의(Sprint Review)

  • 완성 제품이 요구사항에 잘 부합되는지 테스팅 수행
  • 제품 책임자는 개선할 사항에 대한 피드백 정리 후 다음 스프린트에 반영할 수 있도록 제품 백로그 업데이트

스프린트 회고 (Sprint Retrospective)

  • 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행
  • 규칙을 잘 준수했는지, 개선할 점은 없는지 확인 및 기록

💡 속도 (Velocity)
한 번의 스프린트에서 한 팀이 감당할 수 있는 제품 백로그의 양에 대한 추정치.


3. XP(eXtreme Programming) 기법

3-1) XP(eXtreme Programming)의 개념

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

💡 릴리즈(Release)
몇 개의 요구사항이 적용되어 부분적으로 기능이 완료된 제품을 제공

💡 가시성(Visibility)
일반적으로 대상을 확인할 수 있는 정도이다.
릴리즈 기간을 짧게 반복하며 개발 과정에서 일부 기능이 구현될 때마다 고객에게 이를 확인시켜주면, 고객은 요구사항이 잘 반영되고 있음을 직접적으로 알 수 있다는 의미이다.

XP의 5가지 핵심 가치
의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)


XP 개발 프로세스

XP의 주요 실천 방법
1. 짝 프로그래밍 (Pair Programming)
2. 공동 코드 소유(Collective Ownership)
3. 테스트 주도 개발 (Test-Driven Development)
4. 전체 팀 (Whole Team)
5. 계속적인 통합(Continous Integration)
6. 디자인 개선(Design Improvement) 또는 리팩토링 (Refactoring)
7. 소규모 릴리즈 (Small Release)


4. 현행 시스템 파악

1단계) 시스템 구성, 기능, 인터페이스 파악
2단계) 아키텍처, 소프트웨어 구성 파악
3단계) 하드웨어, 네트워크 구성파악

4-1) 시스템 구성 파악

현행 시스템의 구성은 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술

4-2) 시스템 기능 파악

단위 업무 시스템이 현재 제공하는 기능들을 주요 기능하부 기능, 세부 기능으로 구분하여 계층형으로 표현한다.

4-3) 시스템 인터페이스 파악

단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시하고 반드시 고려해야 한다.

데이터 형식 : XML, 고정 포맷, 가변 포맷 등
통신 규약: TCP/IP, X25 등
연계 유형: EAI, FEP 등

4-4) 아키텍처 구성 파악

현행 시스템 아키텍처 구성은 기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성

4-5) 소프트웨어 구성 파악

단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시한다.

4-6) 하드웨어 구성 파악

단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 이중화의 적용 여부를 명시한다.
이중화가 적용된 경우 비용증가와 시스템 구축 난이도가 높아질 가능성을 고려해야 함

4-7) 네트워크 구성 파악

업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성한다.


5. 개발 기술 환경 파악

개발 기술 환경의 정의

운영체제, 데이터베이스 관리 시스템, 미들웨어 등을 선정할 때 고려사항을 기술하고, 오픈소스 사용 시 주의사항을 제시한다.

5-1) 운영체제(OS, Operating System)

운영체제는 컴퓨터 시스템의 자원들을 효율적으로 관리하고 사용할 수 있도록 환경을 제공하는 소프트웨어이다.

💡 운영체제의 종류
Windows, UNIX, Linux, Mac OS, iOS, Android

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



5-2) 데이터베이스 관리 시스템(DBMS)

사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어

💡 DBMS 종류
Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis

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



5-3) 웹 애플리케이션 서버 (WAS)

정적인 콘텐츠 처리를 하는 웹 서버와 달리 동적인 콘텐츠 처리하기 위해 사용되는 미들웨어

💡 WAS 종류
Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere

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



오픈소스 사용에 따른 고려사항 : 라이선스의 종류, 사용자 수, 기술 지속 가능성


생각보다 분량이 넘 많아서 다음에 계속..... ㅋ

profile
공부가 조은 안드로이드 개발자

0개의 댓글