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