정보처리기사 필기 요약 - 1. 소프트웨어 설계 (1)

소프트웨어 생명주기

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

소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 개별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현함.

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

소프트웨어 공학의 개념

소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문으로 여러가지 방법론과 도구, 관리 기법들을 통해 소프트웨어의 품질과 생산성 향상을 목적으로 함.

 

소프트웨어 공학의 기본 원칙

현대적인 프로그래밍 기술을 계속적으로 적용해야하며 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야함.

소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야함.

 

폭포수 모형

폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 모형으로 고전적 생명주기 모형이라고도 함. 개발과정의 한 단계가 끝나야만 다음단계로 넘어갈 수 있는 선형 순차적 모형임. 모형을 적용한 경험과 성공사례가 많고 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함.

 

나선형 모형

보헴이 제안한 것으로 폭포수 모형 +프로토타입 모형에 위험분석 기능을 추가한 모형으로 Spiral Model, 점진적 모형이라고도 함. 소프트웨어 개발을 하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 함.

개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고 정밀하며 유지보수 과정이 필요 없음.

 

애자일 모형

애자일은 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하여 빠르고 낭비없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론임. 애자일 모형은 기업활동 전반에 걸쳐 사용됨.

애자일 모형을 기반으로 하는 모형에는 스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능중심개발, DSDM, DAD 등이 있음.

 

애자일 핵심가치

프로세스와 도구보다는 개인과 상호작용에 더 가치를 둠. 방대한 문서보다는 실행되는 SW에 더 가치를 두며 계약 협상보다는 고객과 협업에 더 가치를 둠. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둠

 

스크럼 개요

스크럼은 팀원 스스로가 스크럼 팀을 구성해야하며, 개발작업에 관한 모든 것을 스스로 해결할 수 있어야함.

스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성됨.

 

제품 책임자

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

 

스크럼 마스터

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

 

개발팀

제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 개발자 외에도 디자이너, 테스터등 최대 7~8명으로 구성됨.

스크럼 개발 프로세스

1. 제품 백로그
   제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록.
2. 스프린트 계획 회의
   제품 백로그 중 수행할 작읍을 대상으로 단기 일정을 수립하는 것.
3. 스프린트
   실제 개발 작업을 진행하는 과정으로 보통 2~4주 정도의 기간 내에서 진행. 스프린트 백로그에 작성된 태스크를 대상으로 속도를 추정한 후 개발 담당자에게 할당.
4. 일일 스크럼회의
   모든 팀원이 매일 짧은 시간동안 진행 상황을 점검. 
5. 스프린트 검토회의
   부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅 수행.
6. 스프린트 회고
   스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 확인 및 기록

XP

XP는 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 통해 빠르게 개발하는 것을 목적으로 함. 릴리즈 기간은 짧게 반복하며 고객의 요구사항 반영에 대한 가시성을 높인다.

 

XP의 5가지 핵심 가치

의사소통, 단순성, 용기, 존중, 피드백

 

XP의 주요 실천 방법

• 짝 프로그래밍(Programming) 
  다른사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠갖는 환경을 조성함.
• 공동 코드 소유(Collective Ownership)
  개발 코드에 대한 권한과 책임을 공동으로 소유함
• 테스트 주도 개발(Test-Driven Development)
  개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악함.
  테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용함
• 전체 팀(Whole Team)
  개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야함
• 계속적인 통합(Continuous Integration)
  모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합
• 디자인 개선 또는 리팩토링(Design Improvement & Refactoring) 프로그램 기능의 변경 없이 단순화, 유연성 강화 등을 통해 시스템 재구성
• 소규모 릴리즈(Small Releases)
  릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있음

현행 시스템 파악

1단계

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

2단계

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

3단계

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

운영체제 (Operating System)

컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종으로 다른응용프로그램이 유용한 작업을 할 수 있도록 환경을 제공해줌. 운영체제 종류로는 Windows, Unix, Linux, Mac 등이 있음

 

운영체제 관련 요구사항 식별 시 고려사항

가용성, 성능, 기술지원, 주변기기, 구축 비용

반응형

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

DBMS(DataBase Management System)는 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해 주는 소프트웨어임. DBMS는 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기위해 제안된 시스템으로, 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록관리해줌. DBMS는 데이터베이스의 구성, 접근방법, 유지관리에 대한 모든 책임을 지며 종류에는 Oracle, IBM DB2, Microsoft SQL Server, Redis, SQLite, MongoDB, MySQL 등이 있음.

 

DBMS 관련 요구사항 식별 시 고려사항

가용성, 성능, 기술지원, 상호 호환성, 구축 비용

 

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

WAS란 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어임. 데이터 접근, 세션관리, 트랜잭션 관리 등을 위한 라이브러리를 제공하며 주로 데이터베이스 서버와 연동해서 서용함. 종류로는 Tomcat, WebSphere, WebLogic, GlassFish, JBoss, Jetty, JEUS, Resin 등이 있음.

 

기능 요구사항(Functional requirements)

• 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공 받기를 원하는 기능

비기능 요구사항(Non-functional requirements)

• 시스템 장비 구성 요구사항
  하드웨어, 소프트웨어, 네트워크 등의 시스템 장비 구성에 대한 요구사항
• 성능 요구사항
  처리 속도 및 시간, 처리량, 동적, 정적 적용량, 가용성 등 성능에 대한 요구사항
• 인터페이스 요구사항
  시스템 인터페이스와 사용자 인터페이스에 대한 요구사항으로 다른 소프트웨어, 하드웨어 및 통신 인터페이스, 다른 시스템과의 정보 교환에 사용되는 프로토콜과의 연계도 포함하여 기술
• 데이터 요구사항
  초기 자료 구축 및 데이터 변환을 위한 대상, 방법, 보안이 필요한 데이터 등 데이터를 구축하기 위해 필요한 요구사항
• 테스트 요구사항
  도입되는 장비의 성능 테스트(BMT)나 구축된 시스템이 제대로 운영되는지를 테스트하고 점검하기 위한 테스트 요구사항
• 보안 요구사항
  시스템의 데이터 및 기능, 운영 접근을 통제하기 위한 요구사항
• 품질 요구사항
  관리가 필요한 품질항목, 품질평가 대상에 대한 요구사항으로 가용성, 정합성, 상호호환성, 대응성, 신뢰성, 사용성, 유지관리성, 이식성, 확장성, 보안성 등으로 구분하여 기술
• 제약사항
  시스템설계 구축, 운영과 관련하여 사전에 파악된 기술, 표준, 업무, 법, 제도 등의 제약조건
• 프로젝트 관리 요구사항
  프로젝트의 원활한 수행을 위한 관리 방법에 대한 요구사항
• 프로젝트 지원 요구사항
  프로젝트의 원활한 수행을 위한 지원 사항이나 방안에 대한 요구사항

요구사항 개발 프로세스

• 요구사항 도출(Requirement Elicitation)
  요구사항 도출은 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정으로 주요 기법에는 청취, 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등이 있음
  
  
• 요구사항 분석(Requirement Analysis)
  요구사항 분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정임. 자료흐름도(DFD), 자료사전(DD)등의 도구가 사용됨.
• 요구사항 명세(Requirement Specification)
  요구사항 명세는 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것을 의미함. 구체적인 명세를 위해 소돤이 명세서(Mini-Spec)가 사용될 수 있음
  
  
• 요구사항 확인(Requirement Validation)
  요구사항 확인은 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동임

정형 명세 기법

• 기법: 수학적 원리 기반, 모델 기반
• 작성방법: 수학적 기호, 정형화된 표기법
• 특징: 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있으므로 완전성 검증이 가능함. 요구사항을 정확하고 간결하게 표현할 수 있으나 표기법이 어려워 사용자가 이해하기 어려움.
• 종류: VDM, Z, Petri-net, CSP 등

비정형 명세 기법

• 기법: 상태, 기능, 객체 중심
• 작성방법: 일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
• 특징: 자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라 다를 수 있어 일관성이 떨어지고 해석이 달라질 수 있으나 내용의 이해가 쉬워 의사 소통이 용이함.
• 종류: FSM, Decision Table, ER모델링, State Chart(SADT) 등

요구사항 분석의 개요

사용자의 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정함. 사용자의 요구를 정확하게 추출하여 목표를 정하고, 어떤 방식으로 해결할 것인지 결정.

요구사항 분석을 통한 결과는 소프트웨서 설계 단계에서 필요한 기본적인 자료가 되므로 사용자의 요구사항을 정확하고 일관성있게 문서화해야하며 북석가에 의한 요구사항 분석 필요.

분석을 위한 도구로 UML(Unified Modeling Language), 자료 흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 등의 도구를 이용함.

자료 흐름도(DFD)

자료 흐름도(Data Flow Diagram)는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 자료흐름 그래프, 버블 차트라고도 함.

• 프로세스(Process)
  자료를 변환시키는 시스템의 한 부분을 나타내며 처리, 기능, 변환, 버블이라고도 함. 원이나 둥근 사각형으로 표시하고 그 안에 프로세스 이름을 기입함
• 자료흐름(Data Flow)
  자료의 이동(흐름)이나 연관관계를 나타냄. 화살표 위에 자료의 이름을 기입함.
• 자료 저장소(Data Store)
  시스템에서의 자료저장소를 나타냄. 도형안에 자료저장소 이름을 기입함
• 단말(Terminator)
  시스템과 교신하는 외부 개체로 입력데이터가 만들어지고 출력 데이터를 받음. 도형안에 이름을 기입함

자료사전

자료사전(Data Dictionary)은 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며 이처럼 데이터를 설명하는 데이터를 메타 데이터 라고 한다.

• =
  자료의 정의
• +
  자료의 연결
• ( )
  자료의 생략
• [ | ]
  자료의 선택
• { }
  자료의 반복
• * *
  자료의 설명