SW란?

 컴퓨터에게 동작 방법을 지시하는 명령어 집합의 모음

SW의 성질: 

물질적인 성질이 없음.  <-> 물질적 성질이 있는 것

소프트웨어 <-> 하드웨어

개발 비용의 대부분은 -> 인건비

마모 X  -> 유지 보수 필요

SW 공학이란?

SW 개발에 공학기술을 더하는 것.

ㄴ공학 기술?  

무엇가를 만든다

좋은 SW 기준:

상호운용성: 다른 시스템과 공존하며 협력할 수 있는 정도

이식성 : 다른 환경에서도 동작할 수 있는 능력

유지보수성: SW의 변경이 용이한 정도

SW 신뢰도: 사용자가 SW를 신뢰하는지

조건( 오랜 시간 작동, 치명적 오류X, 오류 발생시 무난히 복구, 고장 빈도, 고장 간격 중)

정확성: 신뢰도 문제 X 대신 정확성 떨어짐

성능: 컴퓨터 시스템이 처리할 수 있는 작업량

사용성: 본래의 목적으로 효율성 있게 사용할 수 있는가

검사성: 좋은 SW인지 검사할 수 있는가?

추적성: 요구사항, 소스코드 등 관계를 추적할 수 있는가?

SW 프로세스 모델이란? 

SW를 만드는 과정을 의미

좋은 프로세스 모델 -> 전이 과정에서 생기는 문제를 최소화

생산, 진화 추상화 -> 특정 시각으로 표현

소프트웨어 프로세스란? 

누가 언제 어떻게 만들지 육하원칙에 따라 절차를 정의

장:  1)프로세스 모델을 통해 전체 프로세스 이해의 도움을 줌

2)시스템 개발 환경 추적 가능

프로세스 모델을 알아보자

성장형(계획을 세우고 깨져본다, P)

폭포수 모델:  한 방향으로만 진행된다.

타당성 조사) 투입 비용 대비 이익 비용 산출

요구 분석과 명세) 문제 해결을 위해 갖추어야 하는 조건이나 능력

설계 단계) what -> how로 변환하는 과정 

코딩 & 단위 테스트) 코드를 짠게 실제로 돌아가는지 테스트

통합 & 시스템 테스트) 최종적으로 시스템이 돌아가나 확인

유지보수) 말 그대로 유지보수

장점)  선형 모델로 이해가 쉬움, 체계적 문서화 가능 

단점) 요구사항 완벽 적용

변경 수용 x

대형 프로젝트 사용 x 

시스템 동작 -> 후반부 전반 x /

반복 진화형 모델:  초기 버전을 만들고 수정해가면서 시스템을 완성하는 방식

ㄴ 피드백을 계속 받는다고 생각하면 편함.

고려사항) 중소형 시스템에 적합 

대형에서 사용자 인터페이스 만드는데 적합

장점) 점점 시간이 지나면서 요구가 완성된다. 

단점) 관리가 어려움. 수정이 어려워 유지보수 힘들 수 있음.

프로토타이핑 방법: 스케치 그려보는 것

장점: 개발자와 사용자간에 의사소통이 명확해짐.

사용자 교육 효과 있음.

단점: 문서화가 힘듬. 

테스트 선행 개발: 기준을 잡고 그 기준을 통과하는 코드를 만들 것

계획형( J유형)

점증적 모델: 쓰레드처럼 여러개로 분할 -> 재조립 

장점: 사용자가 이른 시기에 시스템 사용 

단점: 증분 개발전 요구사항 정의해야 함, 적당한 크기로 증분 어려움

*증분 찾아보기 

나선형 모델: 나선환처럼 계속해서 목표-> 대안->평가 -> 다음 이런 식으로 순환

장점: 위험관리로 성공 가능성 높일 수 있음

단점: 모델이 복잡하고 경험이 부족하여 증명 X

협업형(F 유형)

애자일 방법: 협업과 코드를 강조 

익스트림 프로그래밍: 빠른 피드백, 지속적 개선, 고객도 개발팀의 일원 ( 매드맥스 )

짝 프로그래밍: 두 사람이 짝이 되어 한 사람은 코딩, 한 사람은 검사를 수행

스프린트:  계획 -> 일일 스크럼 -> 스프린트 회고 -> 스프린트 리뷰로 구성.

짧은 회의를 지속적으로 하고 과정에서 피드백,  리뷰, 백로그를 작성함. 

Sprint: 전속력으로 달린다는 의미. 즉, 팀이 일정 작업을 완성하는 짧은 기간을 의미함. 

*백로그: 팀이 일정 시간 안에 해야 할 모든 업무를 작성한 문서를 의미함.

정의: 명시된 요구사항을 만족시키는 정도 

고객의 기대나 사용 목적에 부합한 정도

소프트웨어 품질의 분류:

품질 관점

 사용자 관점, 개발자 관점, 프로젝트 관리자 관점

외부 특성: 밖으로 보이는 사용자에게 보이는 특성

내부 특성: 개발자 관점의 품질 특성(개발 문서나 코드)

소프트웨어 제품의 품질 표준:

외부 매트릭:  실행중인 sw를 측정

내부 매트릭: sw 산출물 자체를 측정

ISO9000시리즈: 품질 관리 시스템과 기본 용어를 설명

ISO9001시리즈: 9001 인증은 품질 관리 문화가 잘 정착되었다는 것을 의미

CMMI: 조직의 개발 프로세스 성숙도를 평가하는 모델

소프트웨어 품질 보증(SQA):

개발 과정 전체에 관여, 시스템에 요구되는 품질 속성을 정의

품질 제어:

절차에 따라 개발이 되고 있는가? O

품질 목표를 만족하는가? O

목표: 결합을 발견하고 수정함 

신뢰도:

결합 -> 고장으로 이어지지 않거나

결과가 심각하지 않다면 신뢰도가 있음

좋은 SW -> 신뢰도, 품질

23-08-09

소프트웨어설계란? 

시스템을 구성하는 서브시스템들과 그들 간의 관계를 파악

전체적인 시스템과 제어 구조를 설계

설계던 테스트던 기본적 원리 숲 -> 나무 

설계 원리 - 추상화: 

추상화란 내부의 상세한 내용은 생략하고 외부 행위만을 기술하는 것

/

아키텍쳐 설계:

시스템의 구조를 정하는 초기 설계

ㄴ 건축

구조적 설계:

구조적 분석의 결과물을 통해 아키텍쳐를 설계하고 

모듈을 개발하는 방법 

계층형 아키텍쳐:

추상 기계 모델이라 하며 시스템을 계층별로 구성

3계층 아키텍쳐:

사용자 인터페이스, 애플리케이션 로직, 저장소의 3계층으로 분리하여

시스템을 구성

사용자 인터페이스 -> 사용자와의 상호작용을 담당

/

데이터 중심 아키텍쳐: 

대규모의 데이터를 공유하는 소프트웨어 시스템에 사용

데이터 공유에 효율적

데이터 흐름 아키텍쳐:

사용자 간섭 없이 데이터 스트림에 일련의 변환 

작업을 적용하는 시스템에 적합함

트랜잭션 분석에 의한 구조도 설계:

데이터 흐름 유형이 트랜잭션 흐름인 경우 사용

/

애플리케이션 로직 -> 애플리케이션이 필요로하는 기능을 담당

저장소 계층은 데이터의 관리를 담당

/

P2P 아키텍쳐: 

서브시스템들은 클라이언트와 서버 양쪽의 역할을 수행

MVC 아키텍처: 

관리하는 모델 (M), 그것을 사용자에게 보 주는 뷰(V), 사용자와의 상호작용을

제어하는 (C)로 분류

정의: 결함을 찾기 위한 용도로 테스트를 함

소프트웨어 테스트 원칙: 

자신이 작성한 프로그램 -> X

ㄴ 나에게 유리한 쪽으로 작성 우려

개발 조직이 테스트 -> X

ㄴ 위와 비슷한 이유로

후반부에 소홀히 -> X 

ㄴ 손X 처럼 되면 안되겠지

 끝까지 살펴봐야지 

테스트 케이스를 버리지 말고 -> 활용 

ㄴ 추후에 활용할 수 있기 때문

오류가 발견된 곳 -> 추가 오류 가능성 

ㄴ 도미노 효과 비슷한 개념

중요 순위:

1) 전체 시스템 - 숲을 봐라

2) 오래된 기능 - 오래된 나무 점검

3) 예외적인 상황 - 그 외에 위험 사항 체크 ( 동물, 곤충)

4) 새로운 기능 - 새로운 나무 다시 살펴보기

단계별 테스트: 

단위테스트:

개별적 모듈을 독립적으로 확인하는 단계

하향식 통합: 

최상위 모듈부터 하위 모듈까지 차례로 통합시킴

상향식 통합:

하위 모듈부터 최상위 모듈까지 차례로 통합시킴

샌드위치 테스트: 

상향식과 하향식을 조합한 방식

\

통합 테스트:

단위 테스트된 모듈을 통합하여 결함을 발견하는 단계

시스템 통합 방식:

모듈을 모두 개발한 후 한꺼번에 통합

\

회귀 테스트: 

변경 결과로 새로운 버그가 생기지 않았나 살펴보는

테스트

시스템 테스트: 

완전한 시스템이 구축된 후 테스트

코딩스타일이란? 

프로그램 작성 시 준수해야 하는 지침이나 관행

표준 코딩 스타일을 지켜면, 가독성과 유지보수성이 높아지고 결함 빈도가 감소됨 

문서화: 코드 일부에 설명글을 작성하는 것

코드 스멜: 프로그램 안에 존재하는 배드 스멜을 감지하는 것. 

리팩토링: 기능적 행위를 바꾸지 않고 구조를 개선하는 것으로 

가독성과 유지보수성을 높이고 복잡성을 줄이기 위함 

소프트웨어 유지보수:

유지보수가 필수적임

재공학: 

기존 시스템의 이해도 개선, 재사용성 향상을 위한 작업

 아키텍쳐를 바꾸는 경우 많은 비용 소모

역공학: 

메뉴얼, 설계 문서 등을 만드는 과정

소프트웨어 형상 관리:

중요기능을 구현하는 관련 요소들의 집합

변화 발전하는 소프트웨어 시스템을 관리하기 위한

표준과 절차를 개발하고 사용하는 것.

재사용: 

개발 및 유지보수 비용 절감

소프트웨어 척도: 

모듈화, 모듈의 복잡성, 모듈의 가독성, 요구사항의 추적성, 문서화 정도

프로젝트 관리:

예산과 일정의 제약으로 관리가 필요

프로젝트 계획: 

얼마의 비용으로 누구에 의하여 언제까지 행해야 하는가?

소프트웨어 일정 계획:

WBS: 프로젝트 관리를 위한 기초 자료

PERT: 작업 패키지 순서에 관한 정보로 방향 그래프

CPM: 임계 경로 방법

간트 차트: 막대 모양으로 병행 순서 보여줌 

SW 규모의 산정: 라인수(loc) 비용 산정 방법과의 연결이 용이하고 가시적임

FP(기능 점수): 기능의 규모를 측정하기 위한 단위

UFP(미보정 기능 점수): 자료의 규모로 기능을 측정

VAF(보정 계수): * 찾아보기 14개의 복잡도 항목의 영향도를 계산하고 모두 합하여 총 영향도를 계산한다고 함

AFP(보정 기능 점수):  *구체적으로 찾기

SW 개발 비용 산정:

개발 비용 산정에는 대표적으로 몇가지 요소가 있다

1) 과거 데이터와 프로젝트 특성을 고려

2) 투입되는 인력을 고려

비용 산정 방법의 분류: 

판단에 의한 방법: 전문가의 판단, 델파이 기법, 작업분해 등

모델을 이용한 기법: 알고리즘 모델, 유추에 의한 산정

COCOMO: 기본형 -> 소규모 프로젝, 까다롭지 않은 요구사항

중간형: 중규모 프로젝, 요구사항의 혼재

내장형: 대규모 프로젝, 엄격한 제약 조건 

팀 구성 방식: 

매트릭스 조직: 기능 부서 관리자와 프로젝트 부서 관리자의 지배를 받음 , 구성원 전체가 의사결정에 참여 BUT 의사결정 늦고, 책임 소재 모호함. 

책임 프로그래머팀은 중앙형임 

계층형 팀 -> 중앙 + 분산형 

위험 분석과 관리: 

불활식성으로 인한 잠재적인 문제 

위험 요인을 예측 분석하여 대책을 세우는 것. 

위험 요인이란? 

제품의 품질이 낮고 성능에 영향을 주는 위험 

대책: 

회피: 피함

최소화: 위험을 줄임

긴급 대책: 최악에 대비 

:

23-08-05

사용자 요구 분석이란?

문제 해결이나 목적 달성을 위해 사용자가 필요로하는 조건이나 목적

요구사항을 정하고 분석.

FURPS+

HP에서 개발한 분류 모델로, 

F -> 기능적 요구 사항  URPS -> 비기능적 요구 사항 ( 더 중요)

요구 공학 프로세스

요구 공학:  시스템 목표와 기능, 제약 사항을 결정

타당성 조사: 시스템이 목적에 부합하는지?

일정에 맞춰 개발할 수 있는지?

다른 시스템과 통합될 수 있는지?

요구사항 수집과 분석

요구사항 수집은 고객과 시스템 분석가가 의사소통

요구사항 수집 -> 요구사항 분류 -> 요구사항 간의 충돌 해결 -> 우선 순위 매기기 

비 현실적 요구 X 

타협 

서로 다른 요구사항 X 

JAD:

설계 과정에 고객과 사용자를 참가시키는 방법

-> 의사소통 증가, 빠른 합의를 이끔

요구사항 문서화:

시스템의 고객, 사용자를 위해 만듬

기술적, 전문적 요구 피할 것. 

요구사항 검토:

개발 팀이 요구사항의 의미를 설명하고 클라이언트가 오류가 있는지

검토하는 것

고객, 개발자 모두 상세히 검토해야 함.

요구사항 관리: 

요구사항은 변화하고 진화함. 

시스템에 대한 이해가 높아질 수록, 새로운 요구사항 + 변화

요구사항 모델링:

객체지향 분석:

객체를 찾고 객체 간의 관계를 바탕으로 요구사항을 구체화, 정형화 함.

가끔 기술적 지식의 부족, 의견 불일치로 미뤄지는 경향이 있음.

구조적 분석:  분할 정복, 하향식 기능 분해 방법을 사용한 분석 방법

1) 그래픽 표현에 기초함.

2) 다루기 쉬운 조각들로 나눔

3) 시스템 모델을 사용하여 분석가와 사용자가 의사소통 함

구조적 분석에 사용하는 SW 공학 원리

추상화의 원리: 복잡함 -> 핵심만 추출

형식화의 원리: 단계별로 결과물을 문서화

분할과 정복: 큰 문제를 작고 독립적인 문제들로 나누어 푸는 것

계층화: 분할된 모듈을 트리구조로 나눔

SW 시스템을 보는 세가지 관점:

정보 관점: 데이터 간의 관계를 규명

기능 관점: 어떤 기능을 어떻게 상호작용하고

 입력이 어디서 나와서 어떻게 변화되어 나가는가?(데이터 흐름)

동적 관점: 외부 자극에 어떻게 반응하는가에 대한 상태 표현

데이터 흐름도:

데이터의 흐름을 보여주는 다이어그램 

입력 -> 어떤 결과가 나오는지 단계적 처를 보여줌

23-08-09

객체지향 분석

문제 도메인을 분석해서 개념 모델을 작성

결과물은 시스템이 기능적으로 무엇을 수행하는지 설명

객체지향 설계

결과물은 시스템을 어떻게 만들 것인가 설명

고려해야 할 것)

응답 시간,  처리율, 실행 플랫폼, 개발 환경, 프로그래밍 언어를 고려

요구사항 추출

요구 공학: 

고객이 이해할 수 있는 명세서 작성  -> 요구사항 추출을 위한 활동

액터 찾기: 

액터를 찾기 위한 질의 

액터란? 의미를 명확히 하기 위해 사용되는 ulm의 확장법이다.

유지보수나 감독 일을 하는 사용자 그룹

시나리오 찾기:

시스템의 기능을 이야기 식으로 기술한 것.

시스템이 수행해 주길 바라는 작업

유스케이스 찾기: 

유스케이슬란, 유사 기능의 모든 사례를 의미한다. 

해당 기능의 모든 사례를 명세

유스케이스의 기본 구성:

유스케이스의 발생 조건과 종료 조건을 기술:

유스케이스 상세화: 

유스케이스의 완전성과 정확성을 위한 작업 

통신관계: 유스케이스와 이것을 시작시키는 액터 또는 유스케이스와

통신하는 액터 사이의 관계 

확장 관계:  기본 유스케이스와 확장 유스케이스로 분리됨 

포함 관계: 중복성을 줄이기 위해 공통 유스케이스로 분리하는 것 

확장 관계와 포함 관계의 비교: 

기본 유스케이스는 완전한 유스케이스 

확장 유스케이스는 예외적 상황이나 드물게 일어나는 행위임 

시스템 설계 

분석 모델을 시스템 설계 모델로 변환하는 일

설계 목표: 시스템의 품질

설치, 시작, 종료 및 예외 사항 명시

객체 설계: 응용 객체 -> 구현 객체 

객체 설계 작업은 재사용, 인터페이스 명세, 재구조화, 최적화가 있음 

통합 프로세스: 

여러 개발 방법론의 장점을 통합한 프로세스를 뜻함. 

특징: 반복적이고 점진적임

*  up 생명주기라는 말이 나오는데 통합 프로세스랑 어떤

관계고 무슨 상관이 있는지 찾아보기

유스케이스 분석의 필요성 :

프로젝트 초기 단계에서 목표 시스템을 정확히 이해하고 세부 기능을

파악해야 함. 

+ 사용자와의 의견 차이를 좁히고 변경의 여지를 줄이는 과정 

요구사항 분석: 

사용자 요구사항을 분석하는 일

구조화보다는 정확성, 완전성, 일관성등을 검토