소프트웨어 생명 주기
•
소프트웨어 위기는 소프트웨어 개발속도가 하드웨어 개발 속도를 따라가지 못하기 때문에 발생한다.
•
개략적인 설계를 작성하는 단계는 기본 설계 단계이다. 상세 설계단계는 각 단위 프로그램에 대한 사항을 상세히 기술하는 단계이다.
•
프로토타입 모델은 ‘요구 수집, 설계, 개발구축, 평가, 정제, 생산’ 순으로 진행한다.
•
실제 개발될 소프트웨어에 대한 모형을 미리 만들어 보는 것을 프로토타이핑 모델이라고 합니다.
•
소프트 웨어 개발 생명 주기 모형 중 시제품을 만드는 것은 프로토 타이핑 모델이다.
•
애자일은 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.
•
모듈 중심개발은 애자일 방법론이 아니다.
소프트 웨어 개발 방법론
•
1960년대까지 가장 많이 적용되었던 소프트 웨어 개발 방법은 구조적 방법론이다.
•
정형화된 분석 절차에 따라 요구 사항을 파악하는 것은 구조적 개발 방법론입니다.
•
분할과 정복은 구조적 방법론의 대표적인 특징이다.
•
사용자 요구사하은 애자일 개발 절차의 과정이다. 객체지향 개발 절차는 ‘요구분석’ - 설계 - 구현 - 테스트 및 검증 - 인도 단계로 진행된다.
•
객체지향은 각각의 객체로 프로그램이나 시스템을 구성하는 것을 의미한다.
•
고객의 요구사항 변화에 유연하게 대응하는 방법론은 애자일 방법론이다.
•
정보 시스템 개발 주기를 이용한 대규모 정보 시스템 구축에 적합한 것은 정보공학 방법론이다.
•
짝 프로그래밍은 하나의 컴퓨터로 두사람이 함꼐 프로그래밍하는 것을 말한다.
스크럼 기법
•
스프린트는 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행한다.
•
계획한 내용을 토대로 일정 기간 동안 스프린트를 수행하면서 진행 상황을 매일 점검하고 하나의 스프린트가 끝나면 검토한 후 진행을 되돌아 본다.
eXtreme Programming
•
XP의 다섯 가지 핵심 가치는 의사소통, 단순성, 용기, 존중, 피드백이다.
•
XP의 주요실천 받ㅇ법에는 짝 프로그래밍, 공동 코드 소유, 테스트 주도 개발, 전체 팀, 계속적인 통합, 리팩토링, 소규모 릴리스 등이있다.
•
XP는 테스트가 지속적으로 진행 될 수 있도록 자동화된 테스팅 도구를 사용한다.
•
익스트림 프로그래밍은 애자일 개발 방법론을 기반으로 하는 소프트웨어 개발 모형이다.
요구사항 정의
•
문제는 요구사항 분석이지만, 보기 내용은 요구사항 개발과정, 즉 요구사항 도출, 분석, 명세 과정에서 사용되는 기술을 묻는 문제입니다. 설계 및 코딩은 요구사항 개발이 아니라 소프트웨어 구현 과정에서 사용되는 기술입니다.
•
Z는 정형 명세 기법에서 사용한다.
•
성능, 보안 품질 안정 등에 대한 요구사항은 비기능 요구사항이다.
•
개발에 대한 타당성이 충족되면 도출된 요구사항을 분석하여 정리한 후 확인하는 과정을 진행합니다.
•
검증 과정에서도 모든 요구 사항 문제를 발견하기 어렵다.
요구사항 분석
•
설계 명세서 작성은 설계 과정에서 수행하는 작업이다.
•
비용이 가장 많이 소모되는 관계는 유지보수 관계이다.
•
자료 흐름도의 구성요소는 처리, 자료흐름, 자료저장소, 단말입니다.
•
자료 사전에 이름이 중복되어 있으면 올바른 검색을 할 수가 없다.
•
자료 사전에 사용되는 기호는 반복은 {}, 자료 연결은 +, ( ) 는 자료의 생략
•
자료 흐름도의 자료 저장소가 개체에 해당된다. 이것을 종합적이고 체계적으로 모델링한 것이 개체 관계도 이다.
•
시스템에서의 처리 요소를 자료변환의 관점에서 표시하여 처리요소 데이터에 대한 연산을 내용으로 하며, 원으로 표시하는 것을 PROCESS라 한다.
•
자료 흐름은 점선이 아니라 실선의 화살표로 표시한다.
•
자료흐름도는 하향식 분할 원리를 사용한다.
•
{} 자료의 반복, ()는 자료의 생략, []는 자료의 선택을 나타낸다.
•
시스템 외부에 존재하는 사람이나 조직체를 단말Terminator이라고 한다.
•
관계는 개체관계도의 구성요소이다.
•
자료저장소는 평행선안에 자료 저장소 이름을 기입합니다.
요구사항 분석 CASE와 HIPO
•
HIPO는 하향식 설계방식을 사용한다.
•
HIPO는 도식 목차 (Visual Table of Contents), 총괄도표 (Overview Diagram), 상세 도표 (Detailed Diagram)로 구성됩니다.
•
Overview Diagram 총괄 도표는 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표이고, 도식 목차 (Visual Table of Contents는 HIPO에서 지정된 기능을 계층적으로 나타낸 도표이며, 상세 도표는 총괄 도표에 나타난 기능을 구성하는 기본 요소들을 상세히 기술한 도표이다.
•
HIPO는 Hierarchy Input Process Output의 약자이다.
•
SoftTech사에서 개발, 그리고 블록 다이어그램 채택은 SADT의 대표적인 특징이다.
UML (Unified Modeling Language)
•
더 일반적인지 구체적인지 표현하는 관계는 일반화 관계입니다.
•
UML의 구성 요소는 사물,관계,다이어그램이 있다.
•
스테레오 타입을 표현하는 기호는 겹 화살 괄호이다.
•
의사소통을 위해 통일된 하나의 표현법으로 모델링한 언어는 UML이다.
•
배치 다이어그램은 구조적 다이어 그램에 해당한다.
•
한 객체가 다른 객체에게 기능 (오퍼레이션, 인터페이스)을 수행하도록 지정하는 관계는 실체화 관계입니다.
•
단계 (Phase) 다이어그램은 UML에서 사용하는 다이어그램이 아니다.
•
상태 다이어그램은 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서를 나타내며, 순차 다이어그램은 객체들 사이의 메시지 교환을 나타낸다.
주요 UML다이어그램
•
순차 다이어그램 (Sequence)의 구성 요소에는 Actor, Object, Lifeline, Active Box, Message등이 있다.
•
유스케이스의 다이어그램은 사용자의 요구를 분석하는 데 사용된다.
•
사용자 액터 (주액터)는 시스템을 사용함으로써 이득을 얻는 대상을 의미합니다. 본 시스템과 데이터를 주고받는 연동 시스템을 시스템 엑터(부액터)라고 합니다.
•
연동은 2개 이상의 시스템이 일방이 아닌 상호 간의 동작에 영향을 줄 수 있도록 연결망을 구성하는 것을 의미합니다.
•
원래 프로젝트와 연동이 되는 또 다른 시스템을 외부 시스템이라 합니다.
•
클래스와 클래스 사이의 관계를 나타내는 것은 클래스 다이어그램입니다.
•
순차 다이어그램은 동적 다이어그램이다.
소프트웨어 아키텍처
•
소프트웨어 아키텍처 뷰에는 유스케이스 뷰, 논리적 뷰, 구현 뷰, 배포 뷰, 프로세스 뷰가 있다.
•
모듈화는 재사용이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것을 의미한다.
•
서브 시스템 모듈이 어떻게 구조화 되어 있는지에 중점을 둔 관점은 구현뷰이다.
•
복잡한 개념을 이해하기 쉬운 수준으로 단순화하는 것은 추상화입니다ㅣ.
•
소프트웨어를 사용할 때 혼란스러워하거나 고민하지 않게 하는 편의성을 의미하는 것은 사용성이다. (Usability)
아키텍처 패턴
•
앞 시스템의 처리 결과물을 파이프를 통해 전달받아 처리한 후 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴을 반복하는 것이 파이프 필터 패턴이다.
•
아키텍처 스타일을 설계할 때 개발 시간을 단축하고 비용을 절갑하기 위해 기존 컴포넌트를 사용합니다.
•
필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드가 발생하는 패턴은 파이프 필터 패턴이다.
•
마스터 슬레이브는 구조가 동일하므로 기능도 동일하게 수행할 수 있다. 다만 연산, 통신, 조정 기능은 슬레이브 제어를 위해 일반적으로 마스터가 수행한다.
•
OSI참조 모델은 네트워크 프로토콜을 계층 별로 구분한 모델이다.
•
모델은 서브시스템의 핵심 기능과 데이터를 보관하는 역할을 한다.
•
아키텍처 패턴은 서브 시스템들의 역할을 사전에 정의 할 뿐만 아니라, 시스템 간의 관계를 정리하기 위한 규칙과 지침이 포함되어 있다.
•
클라이언트 서버패턴은 하나의 서버와 다수의 클라이언트로 구성되는 패턴이다.