정보처리기사 1과목 - 소프트웨어 설계

소프트웨어 생명 주기 

 

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

 

소프트웨어 개발단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물 표현(계획 - 과정 - 결과가 전부 내포)

 

 

폭포수 모형(Waterfall Model)

 

• 각 단계마다 확실하게 매듭짓고 넘어갈 수 있는 선형 순차적 모형
• 고전적 생명 주기 모형
• 매뉴얼 작성
• 결과물 산출이 명확해야댐
• 두 개 이상의 과정이 병행 수행 (x)

 

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

 

프로토타입 모형(Prototype Model)

 

사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형

 

• 시제품을 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 폭포수 모형의 단점 보완

 

나선형 모형(Spiral Model)  - 보헴

 

폭포수와 프로토타입에 위험분석을 추가

 

계획 및 정의  -> 위험분석 -> 공학적 개발 -> 고객 평가

 

애자일 모형(Agile Model) - 애자일(: 민첩한, 기민한)

 

고객의 다양한 요구 사항의 변화에 유연하게 대응하기 위해 일정한 개발 주기를 반복으로 하는 것

 

애자일 모형은 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발주기 반복

그 결과물에 대한 고객의 평가와 요구를 적극 수용한다.

 

요구 사항 적합 : 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항

 

 

스크럼 기법

 

스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형 - 즉 팀워크를 가장 중요하게 인식하는 기법

 

요구사항 적합 : self-oraganizing - 팀 구성  cross-functional - 스스로 해결

 

스크럼팀 구성 : 제품 책임자, 스크럼 마스터, 개발팀

 

제품 책임자(PO: product owner)

 

이해관계자들 중 개발될 제품에 대한 이해도 높아야댐

요구사항이 담긴 백로그를 작성

팀원들도 백로그를 작성할 수 있지만 우선순위를 지정할 수 없다.

 

백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여

스토리 : 백로그에 담겨질 요구사항은 단어 형태로 표현된 것이 아니라 '고객'은 상품 주문을 위해 로그인을 수행해야한다와 같은 이야기를 서술하는 형태를 표현 - 백로그에 작성되는 요구사항을 스토리 또는 사용자 스토리라고 합니다.

 

스크럼 마스터(SM : Scrum Master)

 

스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할 

일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소 공론화

 

개발팀(DT : Development Team)

 

제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.

보통 최대 인원은 7 - 8 명 적당

 

스크럼 개발 프로세스 

 

제품 백로그 -> 스프린트 계획 회의  -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

 

 

제품 백로그

 

스토리 나열

 

스프린트 계획 회의

 

스프린트할 작업 대상으로 단기 일정 수립

요구 사항을 나눠서 작업할 수 있게 태스크(Task)라는 작업 단위로 분활 후 스프린트 백로그 작성

 

스프린트

 

실제 개발 진행 과정 : 보통 2주 - 4주

태스크 선정 시 개발자가 원하는 방향을 들어준다

개발 담당자에게 할당된 태스크는 보통 to do in progress done 상태로 갖는다.

 

일일 스크럼 회의 

 

모든 팀원은 매일 약속된 시간에 약 15분 정도의 짧은 시간 내에 진행 상황 점검

소멸 차트 표시(Burn-down Chart)

스크럼 마스터는 발견된 장애 요소를 해결할 수 있게 도모

 

스프린트 검토회의 

 

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

주당 한시간 진행

제품 책임자는 피드백을 정리한 후 제품 백로그 업데이트

 

스프린트 회고 

 

스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 확인

 

 

XP(eXtreme Prgramming)

 

XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

 

짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여

릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성 높임

릴리즈 테스트마다 고객을 직접 참여 및 확인

비교적 소규모 인원의 개발프로젝트

 

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

 

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

 

사용자 스토리(user story)

 

고객의 요구 사항을 간단하게 시나리오 짜는 것

내용은 기능 단위

 

릴리즈 계획 수립

 

몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 합니다.

부분 혹은 전체 개발 완료 시점에 대한 일정 수립

 

스파이크 

요구 사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램

처리할 문제 외의 것은 신경쓰지 말자

 

이터레이션

 

하나의 릴리즈를 더 세분화 한 단위를 이터레이션이라고 함

일반적으로 1 - 3 주 정도의 기간으로 진행

이 기간 중에 새로운 스토리가 작성 가능하며

 

승인검사 

하나의 이터레이션 안에서 계획된 릴리즈 단위 부분 완료 제품이 구현되면 수행하는 테스트

고객이 직접 수행 가능

테스트 과정에서 발견한 오류사항은 다음 이터레이션에 포함

 

소규모 릴리즈

릴리즈를 소규모로 하게 되면, 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항을 유연하게 받아드릴 수 있음

 

XP의 주요 실천 방법

 

 

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

 

현행 시스템 파악

 

절차

 

새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공 기능, 시스템 간의 전달 정보, 사용되는 기술 요소, 소프트웨어, 하드웨어, 그리고 네트워크의 구성 등을 파악 

 

1단계 : 시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악

2단계 : 아키텍처 구성 파악, 소프트웨어 구성 파악

3단계 : 하드웨어 구성 파악, 네트워크 구성 파악

 

시스템 구성 파악

 

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

 

내 프로그램의 업무 순서를 정의하자

 

시스템 기능 파악 

 

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

 

각 업무 관련된 기능을 어떤식으로 처리할 지 기능 수료

 

시스템 인터페이스 파악

 

현행 시스템의 인터페이스에는 단위 업무 시스템 간에 주고 받는 데이터의 종류, 형식, 프로토콜, 연계 유형은 무엇인지 등을 반드시 고려해야 한다.

 

아키텍처 구성 파악

 

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

 

아키텍처가 단위 업무 시스템별로 다른 경우에는 가장 핵심이 되는 업무 처리 시스템을 기준으로 표현

 

소프트웨어 구성 파악

 

소프트웨어 구성에는 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 제품들 명시 

 

하드웨어 구성 파악

네트워크 구성 파악

 

운영체제 선택시 고려사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축비용

데이터베이스 관리시스템 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축비용

웹 어플리케이션 서버 고려사항 : 가용성 성능, 기술 지원, 구축 비용

 

 

요구사항의 개념 및 특징

 

요구사항은 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대란 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타냄 

 

요구사항의 유형은 기능 요구 사항, 비기능 요구사항, 사용자 요구사항, 시스템 요구 사항

 

요구사항 개발 프로세스

 

도출 분석 명세 확인 

 

도출

 

인터뷰, 설문, 브레인스토밍

 

브레인스토밍 : 3인 이상이 자유롭게 의견을 교환하면서 독창적인 아이디어를 산출

프로토타이핑 : 

유스케이스 : 사용자 요구사항을 기능 단위로 표현

 

형상관리 

 

소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램

프로그램을 설명하는 문서, 데이터 등을 통칭하여 형상이라고 합니다.

 

 

요구사항 분석 기번 

 

요구사항 분류

 

개념 모델링

 

요구사항 할당

요구사항 협상 

정형분석

 

요구사항 확인기법

 

요구사항 검토 

프로토타이핑

모델검증 

인수테스트 - 사용자 인수 테스트 운영상의 인수 테스트 계약 인수 테스트 규정 인수 테스트, 알파 검사 베타 검사

 

 

사용자 인터페이스 

 

사용자 인터페이스는 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어를 의미 

 

사용자 인터페이스의 세 가지 분야

 

정보 제공과 전탈을 위한 물리적 제어에 관한 분야

콘텐츠의 상세적인 표현과 전체적인 구성에 관한 분야

모든 사용자가 편리하고 간편하게 사용하도록 하는 기능에 관한 분야

 

특징 

 

소프트웨어 영역 중 가장 많은 변화가 일어남

편리성과 가독성을 높이면서 작업시간을 단축 

정보 제공자와 공급자 간의 매개 역할

사용자 인터페이스를 설계하기 위해서는 소프트웨어 아키텍처를 반드시 숙지 

 

구분

 

CLI :  콘솔에서 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스

GUI : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스 

NUI : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스 

 

 

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

 

직관성

유효성

학습성

유연성

 

설계지침

 

사용자 중심

일관성

단순성

결과 예측 가능 

가시성 

표준화 

접근성 

명확성

오류 발생 해결

 

UI 표준 및 지침 

 

표준 : 전체 시스템에 포함된 모든 UI에 공통적으로 적용될 내용으로, 화면 구성이나 화면 이동 등이 포함

지침 : UI 요구사항, 구현 시 제약 사항 등 UI 개발 과정에서 꼭 지켜야 할 공통의 조건을 의미

 

웹 표준 : 웹에서 사용되는 규칙 또는 기술을 의미하는 것으로, 웹 사이트 작성 시 이용하는 HTML, JAVASCRIPT 등의 대한 규정 , 웹 페이지가 다른 기종이나 플랫폼에서도 구현되도록 제작

 

웹 접근성 : 누구나 이용가능하도록 보장

 

웹 호환성  : 하드웨어나 소프트웨어 등이 다른 환경에서도 모든 이용자에게 동등한 서비스를 제공하는 것을 의미 

 

UI 설계 도구 

 

유스케이스(Use Case)

 

유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술

 

품질 요구사항 

 

소프트웨어의 품질은 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소트프웨어 특성의 총체 

 

 

ISO / IEC 9126

 

소프트웨어의 품질 특성과 평가를 위한 표준 지핌으로서 국제 표준으로 널리 사용

소프트웨어의 품질에 대한 요구사항을 기술하거나 개발중인 또는 개발이 완료된 소프트웨어의 품질 평가 등에 사용

ISO / IEC 9126 -> ISO / IEC 25010DMFH ROWJD

 

 

기능성 : 적절성/정합성 정밀성/정확성 상호운용성 보안성 준수성 

신뢰성 :  성숙성 고장 허용성 회복성

사용성 : 이해성 학습성 운용성 친밀성

효율성 : 시간 효율성 자원 효율성

유지 보수성 : 분석성 변경성 안정성 시험성

이식성 : 적용성 설치성 대체성 공존성

 

 

UI 프로토타입의 개요

 

프로토타입은 사용자 요구사항을 기반으로 실체 동작하는 것처럼 만든 동적인 형태

 

UI 시나리오 문서 작성 원칙 

 

개발자가 전체적인 UI의 기능과 작동 방식을 한눈에 이해할 수 있도록 구체적으로 작성 -> 계층 구조 및 플로차트 표기법 작성

 

모든 기능에 공통적으로 적용될 UI 요소와 인터랙션을 일반 규칙으로 정의 

대표 화면의 레이아웃과 그 화면에 속할 기능을 정의 

인터랙션의 흐름을 정의 화면간 인터랙션의 순서 분기 조건 루프 명시

예외 상황에 대비한 다양한 케이스를 정의 한다.

 

인터랙션 : 사용자와 시스템을 연결하는 것이 UI라면 인터랙션은 UI를 통해 시스템을 사용하는 일련의 상호작용입니다. 쉽게 말해 마우스로 화면의 어떤 아이콘을 클릭하면 화면이 그에 맞게 반응하는 것을 말합니다.

 

UI 시나리오로 문서의 요건 

 

완전성 

일관성 

이해성 

가독성 

수정 용이성

추적 용이성

 

HCI(HUMAN COMPUTER INTERACTION OR INTERFACE)

 

HCI는 사람이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문으로, 최종 목표는 시스템을 사용하는 데 있어 최적의 사용자 경험을 만드는 것

 

UX(USER EXPERIENCE)

 

UX는 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험을 말한다. 단순히 기능이나 절차상의 만족뿐만 아니라 사용자가 참여, 사용, 관찰하고 상호교감을 통해서 알 수 있는 가치 있는 경험

 

주관성

정황성

총체성

 

소프트웨어 아키텍처의 설계 

 

소프트웨어의 골격이 되는 기본 구조이자 소프트웨어를 구성하는 요소들의 관계를 표현하는 시스템의 구조 또는 구조체 

 

소프트웨어 아키텍처 설계의 기본 원리는  모듈화, 추상화, 단계적 분해, 정보 은닉 

 

모듈화(Modularity)

 

모듈화란 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미 

 

추상화(Abstraction)

 

추상화는 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구제화시켜 나가는 것입니다.

 

추상화의 유형

 

과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법

데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법

제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

 

단계적 분해(Stepwise Refinement)

 

단계적 분해는 Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위 중요 개념으로부터 하위 개념으로 구체화시키는 분할 기법입니다.

 

정보 은닉(Information Hiding)

 

정보 은닉은 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

 

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

 

소프트웨어 아키텍처의 품질 속성은 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지를 확인하기 위해 품질 평가 요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분 

 

시스템 측면 

 

성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확정성, 기타 속성

 

비즈니스 측면 

 

시장 적시성, 비용과 혜택, 예상 시스템 수명, 기타 속성

 

아키텍처 측면 

 

개념적 무결성, 정확성, 완결성 구축가능성, 기타 속성

 

아키텍처 패턴

 

레이어 패턴 

 

레이어 패턴은 시스템을 계층으로 구분하여 구성하는 고전적인 방법 중 하나이다.

 

레이어 패턴은 각가의 서브시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 됨

 

클라이언트 - 서버 패턴 

 

클라이언트-서버 패턴은 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴 

 

객체지향 

 

객체지향은 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 기계적인 부품들을 조립하여 제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법