소프트웨어 공학

1. 소프트웨어의 정의

소프트웨어 공학을 검색해보면 프레스만이라는 사람이 자주 등장한다.

프레스만의 정의에 따르자면 소프트웨어는 실행 시 원하는 기능과 성능을 제공하며,

프로그램이 정보를 적절하게 조작할 수 있도록 해주는 자료구조이다.

프로그램 운영 및 사용을 기술하는 문서 이다.

프레스만이 저술한 소프트웨어의 특징은 다음과 같다.

유형성 : 설계도안 등은 시각적 형태를 가진다.
무형성 : 완제품의 구조가 코드 안에 숨어 있어 파악하기 힘들다.
동적 행위성 : 하드웨어 상에서 동작하는 프로그램이다.
상품성 : 사용자가 구매 의사에 따라서 구매할 수 있다.
견고성 : 구조 변경이나 수정이 용이하지 않다.
비제조성 : 제조되는 것이 아니라 개발된다.
복제성 : 프로그램은 쉽게 복제할 수 있다.
변경성 : 일반적으로 소프트웨어는 변경이 가능하다.
시험성 소프트웨어는 절차에 따른 테스트를 요구한다.

날이 갈 수록 소프트웨어의 수요는 늘었지만 소프트웨어 개발은 어렵고 문제점이 많았다 이것을 소프트웨어 위기라 하며 이것을 극복하고자 소프트웨어 공학이 도입되었다.

2. 소프트웨어 공학의 정의

소프트웨어 개발 운용 유지보수 등의 생명주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다. 공학을 소프트웨어에 적용하는 것.
소프트웨어 공학은 다음과 같이 다양하다.

요구사항 : 요구사항의 추출, 분석, 명세, 검증 등 요구공학 분야가 독립적으로 존재한다.
설계 : 보통 전산 지원 소프트웨어 공학(CASE) 도구로 이루어지며 UML과 같은 표준 형식을 사용한다.
개발 : 프로그래밍 언어로 소프트웨어를 구축한다.
시험 :
유지보수 : 소프트웨어가 시간이 지난 후에 문제를 일으킬때 향상 시켜야 한다.
형상관리 : 버전과 소스제어가 표준화 되고 구조적인 방법으로 관리 해야한다.
공학관리 : 프로젝트 관리와 밀접하다.
개발프로세스 : 소프트웨어 구축 과정에 관한 것이며, 애자일, 폭포수 등

많은 이론이 존재하며 발전되어 왔다.

품질 : 제품 품질과 프로세스 품질로 나눌 수 있다. 제품 품질은 제품 자체가 가지는 품질이며, 프로세스 품질은 프로세스를 통해 생산되는 것과 관련된 품질이다.

3.1 기획

3.1.1 Engineering Onepager

프로젝트 규모가 작아 SRS등을 작성할 정도가 아닌것을 한 페이지로 정리하는 것을 말한다.

프로젝트가 작더라도 작성하면 공식 리뷰를 거쳐 여러사람의 의견이나 도움을 공식적으로 받을 수 있고 다른 팀에게 공유가 되어 지식공유에 도움이 된다.

구성요소로는 다음과 같다.

1. Project Description

1-1. 배경 (프로젝트 시작하게 된 배경) (상세설명)

1-2. 목적 및 특징

1-3. 내용

프로젝트 상세 개요, 프로젝트 범위 한정

1-4. 프로젝트 관련 이력 및 기존 진행상황

2. Project Output

2-1. 산출물의 형태

2-2. 산출물의 버전

3. Business and Marketing Justification

4. Risk Asessment

5. Resource and Scheduling Details

5-1. 투입 인력

5-2. 개발 일정

5-2-1. 전체 일정

5-2-2. 마일스톤

5-2-2-1. 000 모듈 일정

5-2-2-2. 000 모듈 일정

6. Technical Description

6.1 기능들

6.2 기능들

6.3 기능들

7. 타 프로젝트/제품과의 연관성

3.2 요구분석

3.2.1 SRS(Software Requirement Specification)

소프트웨어 요구사항 표준

Specification 혹은 Spec이라고도 불린다.

IEEE830에서 문서 작성하는 가이드가 있으며 미국 국방부 표준 문서이다.

소프트웨어가 수행하는 작업과 수행할 것으로 예상되는 방법을 설명한다.

상위레벨 요구사항을 개발하기 위해 사용되는 방법, 룰, 툴 등을 정의한다.

일반적인 SRS에는 다음이 포함된다.

목적
전반적인 설명
특정 요구사항

3.2.2 SRS를 사용하는 이유

소프트웨어 요구사항은 전체 프로젝트의 기초이다.

개발에 참여하는 모든 팀이 따라야 하는 프레임 워크를 마련한다.

요구사항을 충족하는데 도움이 된다.

전체 개발 시간과 비용을 최소화 할 수 있다.

3.2.3 요구분석 예시

구체적인 기능

회원가입, 사진업로드, 게시판 ...

제약 조건

스마트폰 기종 호환성 범위
SNS 가입시 카카오톡 페이스북 등 에서 제공하는 정보가 다름.
목표 정립
게시판과 채팅 등을 통해 소통이 원활 해야함.

<주의사항> : 발주자는 대체로 아이디어가 정립되어 있지 않으며, 구체화 시켜 주어야 함.

클라이언트는 개발자의 관점에서 설명하기 보다는 사업적인 관점에서 설명하는 경우가 많음.

구체적인 스케치 또는 플로우를 가져오는 경우가 적으며, 이때 원활한 커뮤니케이션을 위해 필요한 것이 기획 스토리 보드이다.

이중에서도 요구사항 분석인 ‘기능정의서’ 와 ‘IA(메뉴 구조도)’, ‘정책 정의서’가 필요함

이 과정에서 기능 추가, 또는 경쟁 서비스를 참고하여 벤치마킹하기도 한다.

요구사항 분석이 제대로 시행된 경우

실무 개발진 과 디자이너들이 기획 설계도를 보고, 납기일에 맞춰 정확하게 작업물을 완성 할 수 있다.

요구사항 분석이 안된 경우

납기일 준수가 이뤄지지 않으며, 개발 실무진이 클라이언트 의도와는 다르게 임의로 구현하게 된다.

3.2.4 WBS(Work-breakdown structure)

WBS(작업분해도) 프로젝트의 범위와 최종산출물을 세부요소로 분할한 계층적 구조

전체 업무를 분류하여 구성요소로 만든 후 각 요소를 평가하고 일정 별로 계획하며 그것을 완수할 수 있는 사람에게 할당해 주는 역할을 한다.

작성법은 다음과 같다.

전체를 큰 단위로 분할
각각의 부분에 대해 좀 더 작은 단위로 분해하여, 계층적으로 구성
워크 패키지 작업(부분을 구성하는 일련의 작업단위)
담당인원을 배치 및 구성도 완료

3.2.5 간트차트

프로젝트 활동이 언제 시작되고 언제 종료 되었는지 쉽게 이해할 수 있다.

간트 차트의 세로축에는 WBS에서 도출된 프로젝트의 활동을 나열하고 가로축에는 활동별 시작일지와 종료일자를 막대(Bar)형태로 연결하여 표현한다.

활동의 진행사항과 자원할당이 효과적으로 표현되고 작성하기가 용이해서 주로 프로젝트 팀간의 의사소통을 위해 사용한다.

3.2.6 마일스톤의 정의

WBS를 기반으로 팀이 프로젝트의 최종 산출물을 생산하기 위한 목표를 설정하고, 그 목표를 중요한 하위 목표들로 세분하여 각각의 하위 목표들에 마감시한을 할당한 것이다. 프로젝트의 전체적인 그림을 보고자 할 때 사용된다.

마일스톤 차트는 WBS에서 도출된 모든 활동을 표현하는 것이 아니라 프로젝트 단계별로 준수해야 하는 중요한 사안들에 대한 내용만을 표현하는 차트이다.

주로 포함되는 것은 다음과 같다.

주요한 중간산출물의 완료일
프로젝트 일정에 영향을 미치는 외부요인의 완료일
주요 의사결정 시점
고객또는 상위 관리자에게 보고해야하는 주요 사안
프로젝트 시작일 및 종료일

마일스톤을 정하는 유용한 방법중 하나는 각 수명주기 단계에서 각각의 산출물의 완료 시점을 정하는 것이다.

3.2.7 간트차트와 마일스톤의 차이

프로젝트 팀원간의 의사소통을 위해서는 간트 차트를 사용하며,

경영진이나 고객 등과 의사소통을 위해서는 마일스톤 차트를 이용한다.

3.3 설계

3.3.1 설계 명세서(Software Design Standards)의 정의

설계에 대한 표준을 담고 있는 문서이다.

소프트웨어 아키텍쳐와 하위레벨 요구사항을 개발하기 위해 사용되는 방법, 룰 그리고 툴을 정의한다.

SDS를 작성하기 위해서 구체적으로 아래와 같은 내용이 포함된다.

설계 작성 방법
네이밍 규칙
허용된 설계 방법상에 적용되는 조건

ex)스케쥴, 인터럽트와 이벤트기반 아키텍쳐의 사용, 다이나믹 태스킹, 재진입, 전역데이터, 예외처리, 이러한 것이 사용되는 이유

디자인툴 사용에 대한 제약
설계에 대한 제약

ex) 재귀호출, 다이나믹 객체, 데이터별칭, 압축된 표현의 배제

복잡도 제한

ex) 중첩된 호출 혹은 조건절의 최대 레벨, 무조건적인 분기, 코드 컴포넌트의 진입/ 진출점의 수

요구사항 분석이 큰 목표와 방향을 정하는 것이라면 설계는 작업을 착실히 수행하기 위해 구체적인 설계도를 만드는 단계이다.
고객에게 도출한 요구사항을 구체화하여 시스템 구현을 준비하는 단계이다.

3.4 구현

3.4.1 SCS(Software Code Standards)

소프트웨어를 코딩하기 위해 사용되는 프로그래밍 언어, 방법, 룰, 툴을 정의한다.

SCS를 통해 개발자들이 공통적으로 따라야 할 규칙을 정함으로 통일성과 안정성을 확보할 수 있다.

SCS에는 다음과 같은 항목이 포함된다.

사용될 프로그래밍 언어, 정의된 subSet, 프로그래밍 언어에 대한 구문, 데이터 동작, 언어의 사이드이펙트를 명백하게 정의하는 데이터
라인수 제한, 들여쓰기, 공백라인 사용과 같은 소스코드 문서화 표준
컴포넌트, 서브프로그램, 변수 그리고 상수에 대한 네이밍 규칙
소프트웨어 컴포넌트간의 커플링 정도 허용된 코딩 규칙에 부과되는 조건과 제약, 그리고 이러한 것을 사용하는 이유
코딩툴의 사용에 대한 제약

3.5 테스트

3.5.1 QA의 정의

품질 보증을 뜻한다.

어플로 예를 들자면 데이터는 너무 많이 소모하지 않는지, 메모리는 적절히 분배하는지, 동일한 ID로 다른 핸드폰에서 로그인시 정보가 제대로 이관되는지, 등 사용자 관점에서 판단할 수 있는 검증 활동을 말한다.

3.5.2 QC의 정의

품질 관리를 뜻한다.

품질 요구사항을 만족시키기 위해 사용되는 운영상의 기법 및 활동을 말한다.

어플로 예를 들자면 구매가 잘 되는지 포인트가 잘 적립 되는지, 기획과 동일하게 진행되는지 확인한다.

3.5.3 Testing의 정의

품질 보증 프로세스 내에서 품질 평가 활동을 모니터링하고 요구 사항을 충족하는지 관찰하는 업무를 수행한다.

결함 발견을 위한 활동이다.

3.5.3.1 소스코드 공개 에 따른 테스팅은 다음과 같다.

블랙박스 테스팅 : 내부설계를 고려하지 않으며 고객의 요구사항이 담긴 프로그램 명세서를 기반으로 테스팅 된다.
화이트 박스 테스팅 : 블랙박스와는 반대로 내부 설계를 고려한 테스팅이며, 소프트웨어와 코드의 동작을 알고 있어야 한다.

3.5.3.2 제품 개발 절차에 따른 테스팅은 다음과 같다.

유닛 테스팅 : 소프트웨어 컴포넌트, 모듈 대상 테스팅을 의미하며, 일반적인 테스터가 아니라 프로그래머에 의해 수행된다.
통합 테스팅 : 프로그램이 통합된 이후에 결합된 기능들을 검증하기 위한 통합 모듈 테스팅이다.

시스템 테스팅 : 각각의 요구사항에 대해 전체 시스템이 테스트 된다. 전체 요구사항 명세에 기반한 블랙박스 타입 테스팅이다.
알파 테스팅 : 개발 마지막 부분에서 수행하는 테스팅으로서 가상의 유저 환경을 조성될 수 있다.
베타 테스팅 : 일반적인 유저에 의해 완료되는 테스팅이다. 프로그램 상용화 이전 최종 테스팅을 의미한다.
인수 테스팅 : 일반적으로 개발된 시스템이 고객이 명세한 요구사항을 충족했는지를 검증하기 위해 사용된다. 사용자 혹은 고객이 인수 테스팅을 통한 결과를 보고서 인수 할지 결정하기 위해 수행한다.
리그레션 테스팅 : 어플리케이션의 모든 모듈 및 기능에 대한 수정 사항을 테스팅 하는 것이다. 모든 시스템을 커버하는 것이 어렵기에 일반적으로 자동 테스팅이 사용된다.

3.5.4 REACT에서의 테스팅

3.5.4.1 React Component Test :

컴포넌트 트리 렌더링 : 간략화된 테스팅 환경 및 출력값이 확실한 경우

완성된 앱에서 테스트 : 현실적 브라우저 환경, E2E(End-to-End)테스트

React는 컴포넌트 단위로 테스트 로직을 정해줄 수 있다.

컴포넌트를 테스팅 할때는 다음과 같다.

특정 props에 따라 컴포넌트가 잘 렌더링 되는지 확인
이전에 렌더링 했던 결과와 현재 렌더링 한 결과가 일치하는지 확인
특정 Dom 이벤트를 예상하여 원하는 변화가 제대로 발생하는지 확인
렌더링 된 결과물을 이미지로 저장하여 픽셀을 확인하고 일치하는지 확인, 스토리북을 이용하여 테스팅 하는것이 효율적임.

일반적으로 단위 테스트란 어플리케이션 일부를 독립적으로 테스트하는 것.

메서드를 테스트하는 또 다른 메서드이며 유닛 테스팅으로 진행된다.

통합 테스트

서로 다른 부분(각 컴포넌트)이 모여 특정 상황에서 잘 엮여서 작동하는지 확인
ex) 특정 컴포넌트의 Props가 자손 컴포넌트에 전달 되었는지 확인

전체 테스트

어플리케이션을 브라우저 환경에서 테스트하는 것을 말한다.
ex) ID, PW 를 입력한 뒤 백엔드 서버로 Form을 제출하는 과정

React 단위 테스트

Testing basic component rendering
testing props
Testing state
Testing event handlers

PropTypes(정적 타입 검사를 하기 위한 도구)

1
2
3
4
5
6
7
8
9
10
11
12

import PropTypes from 'prop-types';
 
class Greeting extends React.Component {
  render() {
    return (
      <h1>Hello, {this.props.name}</h1>
    );
  }
}
Greeting.propTypes = {
  name: PropTypes.string
};
Colored by Color Scripter

cs

위처럼 PropTypes를 선언하여 오류를 미리 예방할 수 있다.
PropTypes 선언으로 인해 가독성을 향상 시킬 수 있다.

React Component를 테스트하기 위해서 Facebook에서 만든 Jest가 테스트 프레임워크로 많이 쓰인다.

컴포넌트 렌더링 등과 같은 동작 테스트에서는 Enzyme, @testing-library/react 가 많이 사용된다.

Snapshot Test(Jest)

스냅샷 테스팅은 컴포넌트를 주어진 설정으로 렌더링하고, 그 결과물을 파일로 저장한다. 그 다음 테스트 할 때 이전의 결과물과 일치하는지 확인 하는 방식이다.

장점

테스트를 작성하기 쉽다
의도하지 않은 변경을 빠르게 감지할 수 있다.

단점

테스트에 대한 명확한 의도를 파악하기 어렵다.
테스트가 실패할 수 있는 여러 상황중 어느것이 문제인지 찾기 어렵다.
테스트에 실패했을 때 버그라고 인지하지 못하고, Snapshot을 업데이트할 수도 있다.

3.5.5 스토리북의 정의

스토리북은 테스트 도구라기 보다는 UI 개발 환경에 가깝다.

스토리북의 목적은 “UI 컴포넌트를 어플리케이션 외부의 독립된 환경에서 개발할 수 있도록” 하는 것이다. 하지만 일반적인 테스트 도구가 모듈 혹은 함수를 어플리케이션 외부의 독립된 환경에서 실행해서 결과를 검증할 수 있도록 돕는다는 것을 생각하면, 스토리북도 테스트 도구의 역할을 일부 수행하고 있음을 알 수 있다.

3.6 유지보수

3.6.1 소프트웨어 유지보수(Maintenance)

소프트웨어 생명주기의 마지막 단계이다.

구현,테스팅,소프트웨어 전개, 유지보수의 단계로 이루어진다.

제품이 출시된 후 환경변화 및 사용자 요구변화에 따라 소프트웨어를 지속적으로 업데이트 하는 일이 유지보수 단계에서 이루어진다.

유지보수가 용이하도록 구축되어야 하며, 구조를 쉽게 변경 할 수 있도록 설계해야 하고 구현 단계에서 쉽게 읽고, 이해하고, 변경할 수있는 코드를 생성해야 한다.

소프트웨어 유지보수는 전체 생명주기 비용의 50%이상을 차지한다.

3.6.2 효율적인 유지보수를 방해하는 요인

비구조적인 코드

유지보수 인력의 시스템에 대한 지식이 불충분

개발 문서의 부재 또는 문서 업데이트가 안되어 내용이 안 맞거나 불충분

소프트웨어 유지보수에 대한 올바른 인식 부족

3.6.3 소프트웨어 유지보수의 유형 4가지

수리 유지보수 : 최종 사용자가 보고한 버그를 수정

적응 유지보수 : 개발 환경 변화 또는 신규 환경에 소프트웨어를 맞추는 작업

완전지향 유지보수 : 새로운 또는 변경된 사용자 요구사항을 반영하여 소프트웨어 업데이트(시스템 성능, 사용자 인터페이스를 향상시키기 위한 개선)

예방 유지보수 : 문서 업데이트, 코멘트 추가, 시스템 모듈 구조 개선, 코드 최적화 같은 시스템 유지보수성을 개선한다.

[1] ~ [2] http://blog.naver.com/PostView.nhn?blogId=ndb796&logNo=221113459330

[3.1] https://www.abctech.software/

[3.2.1],[3.3],[3.4]https://imnow.tistory.com/entry/23-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%ED%91%9C%EC%A4%80%EB%AC%B8%EC%84%9C-%E2%80%93-SRS-SDS-SCS

[3.2.3] https://leanstarter.co/process/

[3.2.5] https://miaow0111.tistory.com/7

[3.5.1] ~ [3.5.3] https://blog.naver.com/PostView.nhn?blogId=suresofttech&logNo=220822794548

[3.5.3] https://eehoeskrap.tistory.com/14

[3.5.4] https://velog.io/@danbii/React%EC%97%90%EC%84%9C-Test%ED%95%98%EA%B8%B0

[3.6] https://grapevine9700.tistory.com/304

저작자표시 비영리 변경금지

Study For Programming

소프트웨어 공학 정리

목차