동적모델 설계 응용 SW엔지니어링 과정 1

김원종·2023년 7월 20일

왜 소프트웨어 개발이 어려울까??

의사소통의 문제
- 소프트웨어 개발 과정에 참여하는 다양한 역할자 (프로젝트 관리자, 품질 관리자, 개발자 , 사용자 등) 간의 의사 소통 오류
시스템의 순차 특성
- 3차원적인 실세계의 서비스를 2차원 평면에서 프로그램 코드로 나열
개발에 의한 결과물
- 조립이나 공식에 의한 문제풀이가 아닌 개발자의 지적 활동에 의한 산출물
프로젝트 복잡성
- 프로젝트마다 개발 기간, 개발자 수 , 사용자 수준 등의 차이로 인하여 유연한 관리 필요
다양한 관리 이슈
- 요구사항 변경 관리 , 일정 관리 , 코드 버전 관리 등 다수의 활동간의 오케스트레이션

인공지능 시대의 소프트웨어 위기

4차 산업 혁명 시대
- 초연결 , 초융합 ㅡ초지능
- 인공지능 , 빅데이터 ,가상현실 Iox , 사이버물리 시스템
인공지능 소프트웨어의 범람
- 인공지능을 기반으로 하는 다양한 학습 모델 출현
- 지도학습 , 준지도학습 , 비지도학습 , 강화학습 등 다양한 기계학습 알고리즘 활용 증대
- 인공지능과 기계학습 기반의 소프트웨어 개발 및 활용 증대
  - 정보 서비스 분야 , 자율 제어 분야 ,모바일 분야 등 활용 영역 증대
- 인공지능 소프트웨어의 위기
  - 기계학습 결과에 대한 정확성 , 신뢰성 ,안정성 등의 문제
    - 윤리 및 도덕적인 영역에서의 인공지능의 편향성 문제

소프트웨어 공학적 기법

구조적 프로그래밍 : 1970년대
- 포트란 , 코볼, C 등의 절차적 프로그래밍 언어의 등장
- 이해하기 쉽고 ,체계적인 논리를 표현할수 있는 공학적 접근 방법
  - 구조적 분석 및 구조적 설계 방법론 : 자료흐름도 ,구조차트 등
- 모듈화 개념과 단계적 상세화 개념
객체지향 프로그래밍 : 1980년대
- 클래스 개념의 출현 : 캡슐화 , 정보은닉 , 상속 ,다형성
- C++,C#,Java,Python 등의 언어 출현
- 실세계의 묘사가 직관적이며 , 재사용을 강조하는 공학적 접근 방법
- UML 기반 객체지향 분석 및 설계
소프트웨어 컴포넌트와 재사용 : 1990년대
- 소프트웨 컴포넌트 : 재사용 가능한 명세 및 코드의 묶음
- 재사용으로 인한 개발의 신속성 및 품질 향상
- 컴포넌트 기반 소프트웨어 개발 방법론
- 오픈소스 소프트웨어(OSS) 재사용을 통한 소프트웨어 개발 확대

소프트웨어 공학적 원리

엄격성과 정형성
- 소프트웨어는 개발자의 경험과 지식에 의존적인 창의적, 공학적 활동의 산출물
- 소프트웨어 개발은 주어진 시간과 비용에서 명확하게 개발되어야 하는 엄격성
관심사의 분할
- 복작한 문제를 단순한 문제로 분리하여 적용하는 소프트웨어 개발활동
- 소프트웨어 개발 과정의 분할 : 요구사항 분석 -> 설계 -> 구현 -> 테스팅 등의 단계로 분할
- 소프트웨어 테스트 과정의 분할 : 단위 테스트 -> 통합 테스트 -> 시스템 테스트 등으로 분할
모듈화
- 독립적인 기능을 갖는 프로그램의 조작
- 높은 응집력과 낮은 결합력을 갖는 소프트웨어 구조 설계
추상화
- 세부사항은 감추고 대표적인 속성으로 대상물을 정의한는 공학적 원리
- 대상물에 대한 직관적인 이해를 높이고 관심사를 잘 표현할 수 있음.
- 예 : 함수 정의 , 매크로 함수 , 객체 ,추상데이타 타입 등
변경의 예측
- 소프트웨어 개발과정에서 변경 발생은 피할 수 없는 사건
- 변경을 대처하기 위한 공학적 방법의 적용이 요구됨
- 변경이 발생할 것으로 예상되는 부분을 모듈화 구조로 분리
일반화
- 다양한 플랫폼, 다양한 환경 , 다양한 사용자를 지원하기 위한 원리
- 하드웨어 성능이나 사양에 의존적이지 않는 소프트웨어 개발
점진성
- 단계적이며 순차적으로 소프트웨어를 개발하고자 하는 공학적 원리
- 작은 단위의 소프트웨어를 반복 개발하면서 전체 시스템을 완성
- 단계적인 개발과 배포를 통한 사용자 피드백의 수집과 반영
명세화
- 소프트웨어 개발 과정 및 대상물에 대한 정보를 체계적으로 기술하는 원리
- 팀 기반의 개발 활동을 지원하기 위한 정보의 공유 지원
- 지속적으로 진화하는 소프트웨어에 대한 이력서

소프트웨어 프로세서의 필요성

소프트웨어 프로세스란
- 소프트웨어 개발 과정을 체계적으로 계획, 관리할 의도 아래 서로 관련 있는 활동을 단계로 분리하여 정의한것
소프트웨어 프로세스 필요성
- 요구사항 만족도 향상 -> 수정 및 재개발 비용 절감 -> 품질 관리 가능 -> 프로젝트 성공

소프트웨어 생명 주기

소프트웨어 방버론의 바탕이 되는 것.
소프트웨어 개발을 위해 정의,운용,유지보수 등의 과정을 단계별로 나눈 것.
개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고 개별적인 모형을 사용할 수도 있다.
일반적으로 폭포수 모형,프로토타입 모형, 나선형 모형 ,애자일 모형이 있다.
폭포수 모델
- 가장 오래되고 폭넓게 사용된 전통적인 모형
- 폭포의 물이 아래로 떨어지는 것처럼 순차적인 단계로 소프트웨어를 개발하는것
- 각 단계마다 정해진 소프트웨어 문서를 작성
  - 작성된 문서는 사용자 확인 과정을 거쳐 다음 단계의 입력으로 사용됨
- 폭포수 모델의 단점
  - 개발 과정에서 요구되는 변경을 수용하기 어렵고
    - 입력으로 사용되는 이전 단계의 결과물에 오류가 잔존하는 경우,다음 단계에 영향을 줌
- 폭포수 모델의 변형
  - 피드백이 가능한 폭포수모델
    - 각 단계를 중첩하여 진행하는 폭포수 모델(점진적모델) 등
점진적 모델의 전략
- 개발 및 배포 : 개발자는 실사용자가 원하는 것을 개발하여 제공한다
- 측정 및 모니터링 : 배포된 부분에 대한 사용자 유용성을 평가한다.
- 조정 및 수정 : 모니터링 결과를 설계와 구현에 반영한다.
점진적 모델의 이점
- 새로운 제품 개발 시 사용자의 요구사항이나 변경을 반영할 시간이 주어진다
- 변경을 쉽게 수용할 수 있다.
- 점진적,단계적 개발을 통해 사용장에게 사용 가능한 소프트웨어 시스템을 신속하게 전달할 수 있다.
점진적 모델의 문제점
- 각 빌드에 대한 테스트와 통합이 반복적으로 수행되어 오버헤드가 발생할 수 있다.
- 사용자 피드백을 반영하면 이미 개발된 시스템의 구조화가 무너질수 있다.
프로토타입 모델
- 점진적 모델의 한 유형으로 , 개발 및 배포 , 사용자 만족도 측정 , 조정 및 수정을 통한 시스템 개발 전략을 기반으로 소프트웨어 시스템 개발
- 기능 메뉴 (혹은 버튼) 만 포함하는 사용자 인터페이스의 원형을 보여주거나 사용자에게 중요하다고 판돤되는 핵심 모듈만 우선적으로 개발하여 사용자에게 제공하고 이를 통해 사용자의 요구사항을 만족했는지 여부를 판단하고, 이를 바탕으로 최종 시스템을 구현

프로토타입 모델의 이점
- 사용자 요구사항을 검증하여 개발 비용과 시간을 단축할 수 있다.
- 프로토타입을 통해 사용자와 개발자 혹은 개발자 간 의사소통이 이루어져 상호 동일한 개념을 확보할 수 있다.

나선형 모델
- 소프트웨어 시스템 개발 시 위험을 최소화 하기 위해 점진적으로 전체 시스템으로 개발해나가는 모델로 소프트웨어 개발 과정이 반복적이고 점진적으로 진행되는 나선 모양
- 목표 설정 ->위험분석 ->구현 및 테스트 0> 평가 및 다음 단계 수립의 활동 반복
나선형 모델의 장점
- 체계적인 위험 관리로 위험성이 큰 프로젝트를 수행하기에 적합하다.
- 사용자 요구사항을 더욱 상세히 적용할 수 있다.
나선형 모델의 단점
- 프로젝트 기간이 길다 .
- 반복되는 사이클이 많아질수록 프로젝트 관리가 어렵다.

V모델
- 폭포수 모델의 확장한 Verification and Validation 모델
  -V 모양의 왼쪽은 아래 방향으로 내려가면서 폭포수 모델에 따른 소프트웨어 개발 과정이 진행하고 코딩 단계 이후에는 다시 오른쪽으로 올라가면서 테스트 과정이 단계별로 수행

애자일 방법론
- 기민한 , 좋은 것을 빠르고 낭비 없게 만드는 개발을 가능하게 해주는 방법론 전체
- 대표적인 애자일 방법론들
  - 동적 시스템 개발 방법 , 데인 포크너
  - 익스트림 프로그래밍, 캔트 벡 .에릭 콤마
  - 스크럼 , 켄스와버 .제프서더랜드
애자일의 적용 원리
- 고객 만족을 가능한 한 빨리 이끌어내고, 유연한 소프트웨어를 지속적으로 사용자에게 제공한다.
- 개발 과정에서 늦은 시점일지라도 유구사항 변경을 적극 수용한다.
- 실행 가능한 소프트웨어를 1~2주일에 한번씩 사용자에게 배포한다.
- 사용자와 개발자 간 친밀한 미팅을 거의 매일 수행한다.
- 프로젝트는 신뢰할 수 있고 동기가 부여된 개인을 중심으로 진행한다.
- 의사소통을 위해 가능하면 한 곳에 모여 대화한다.
스크럼 프로세스 :반복적 개발의 관리 관점을 강조
스크럼 프레임워크
-
- 솔루션에 포함할 기능 및 개선점에 대한 우선순위를 부여한다
- 개발 주기는 30일 정도로 하며, 개발 주기마다 실제 동작할 수 있는 결과를 제공한다.
- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공한다.
- 날마다 15분 정도 회의하라

소프트웨어 설계 프로세스 - 현행 시스템 파악

현행 시스템 파악
- 시스템 구성 , 시스템 간의 전달 정보 ,사용되는 기술 요소, 소프트웨어 ,하드웨어 , 네트워크 구성 등을 파악
시스템 구성 파악
- 주요 업무를 담당하는 기간업무와 이를 지원하는 지원 업무로 구분
시스템 기능 파악
- 단위 업무 시스템이 제공하는 기능들을 주요 기능, 하부 기능 , 세부 기능으로 구분하고 계층형으로 표시
시스템 인터페이스 파악
- 단위 업무 시스템 간에 주고받는 데이터의 종류 , 형식 ,프로토콜 ,연계유형 , 주기 등을 파악
아키텍처 구성 파악
- 어떤 기술 요소들이 사용되고 있는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성
소프트웨어 구성 파악
- 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명 , 용도, 라이선스 적용 방식, 라이선스 수 등을 명시
하드웨어 구성 파악
- 시스템들이 운용되는 서버의 주요 사양과 수량 , 그리고 이중화의 적용 여부를 명시
네트워크 구성 파악
- 서버의 위치 , 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성

요구사항의 중요성에 대한 Swing Tree Cartoon

요구사항
- 실세계의 문제를 해결하는 데 도움을 줄 제품이나 시스템에 부여되는 필요 사항 또는 제약 사항을 의미
- 소프트웨어 시스템이 수행해야 할 것과 소프트웨어 시스템에 있어야 할 특성을 기술한 문장
특성
- 전체 소프트웨어 개발 수명주기에서 가장 중요한 요소, 소프트웨어 개발의 기준
- 다양한 스테이크홀더로부터 도출, 소프트웨어가 무엇을 해야 하는가를 표현
- 초기 시스템 요청보다 상세한 요구사항 목록으로 구체화
- 기능적인 요구사항, 비기능적 요구사항
- 소프트웨어에 대한 품질 요소 포함가능
- 고객과 개발자간 의사소통의 수단,분석 과정과 설계 과정을 거치며 지속적으로 변화
- 요구사항의 문제점을 늦은 단계에서 발견하면 이를 수정하기 위한 많은 비용 발생
- 프로젝트 실패의 가장 중요한 이유 : 명확하지 못한 요구사항 정의

시스템 요구사항
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현
- 소프트웨어 요구사항이라고도 한다.
사용자 요구사항
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항
- 사용자를 위한 것으로 친숙한 표현으로 이해하기 쉽게 작성

요구사항 정의 품질

요구사항 정의에 나타나는 치명적 과실
- 노이즈 발생 : 관련 없는 정보가 포함되거나 모호한 표현이 존재하는 경우
- 침묵 발생 : 언급되어야 할 사항이 누락되는 경우
- 과도한 스펙 명세 : 아직 결정되지 않는 구현 관련 사항이 포함되는 경우
- 모순 발생 : 전후 내용에 일관성이 없는 경우
- 모호성 : 하나의 표현이 여러 가지 의미로 해석되는 경우
- 전방 참조 : 아직 정의하지 않은 사항을 앞서 참조하는 경우
- 사실이 아닌 기대 사항 : 사실에 근거하지 않고 막연한 추측과 기대에 근거하는 경우

요구사항 수집 기법 - 대면 수집 기법

그룹회의
- 제품의 기능적 요구 사항과 품질 요구 사항에 대한 결과나 아이디어를 얻기 위해 사용자 대표 그룹과 회의하여 요구 사항을 도출하는 방법이다.
워크숍
- 소수의 전문가 집단이 모여 브레이스토밍 방식으로 회의를 진행하여 요구 사항을 도출하는 방법이다.
시나리오 작성
- 소프트웨어 시스템과 사용자 간의 상호 작용을 시나리오 형식으로 작성하여 시스템에 대한 요구 사항을 도출하는 방법이다. 유스케이스,사용자 스토리 등의 기법들이 있다.
시스템 인터페이스 분석
- 시스템 인터페이스 분석 방법은 다른 요구 사항 도출 방법과 달리 독립적으로 수행되는 방법으로, 개발 대상 시스템과 연계할 다른 시스템에 대한 조사를 수행한다. 시스템 인터페이스 분석을 통해 주로 시스템 간 데이터 교환 및 서비스에 관한 기능 요구 사항을 도출한다.
문서 분석
- 문서 분석은 소프트웨어 요구 사항을 도출하기 위해 기존의 문서를 조사하는 방법이다.(시스템 sw요구 사항 도출에 유용한 문서로는 이전 제품이나 선도 제품의 요구사항 명세,시스템 아키텍처,유지-보수 이력, 사용자 및 시스템 메뉴얼 등이다.)
- 개발할 sw 제품이 준수해야 하는 산업 표준이나 규제 등도 매우 중요한 분석 대상 문서이다. 기존 sw 제품을 대체할 목적인 경우 문서 분석을 통해 반드시 유지해야 하는 기능과 그렇지 않은 기능을 파악해야한다.
- 이해관계자가 이야기해 주지 않은 내용을 문서 분석을 통해서 파악할 수 있다는 장점이 있다.
관찰
- 소프트웨어의 미래 사용자가 수행하는 활동을 살펴보는 활동
- 관찰의 목적 : 매일 수행하는 일이라 중요하다고 생각하지 않는 업무 처리 과정을 찾기
- 업무 수행 주기 를 파악해서 해당 시기를 놓치지 말아야함
소셜 네트워크
- 시간과 공간의 제약 없이 다수 사용자에게서 요구사항을 수집하고자 할때 활용
- 다수 고객에게서 다양한 정보를 얻을 수 있으
- 비정형 데이터 형식으로 정보가 포스팅되고, 응답 내용에 약어나 비속어 등이 포함될 수 있음 수집 정보를 웹 크롤링하여 자연어 처리 기법 등을 이용해 정보를 추출하는 과정 필요
요구사항 정의서

정해진 틀은 아니지만 이런 방식을 지켜야 좋다!!

요구사항 분석

SW 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동
요구사항 타당성 조사와 비용 일정에 대한 제약 설정
소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화 해야 한다.
요구 사항을 기술할 때는 요구 사항의 확인 , 요구 사항의 검증 비용 추정 등의 작업들이 가능하도록 충분하고 정확하게 기술해야 한다.
분석 기법으로는 기능 분할 , 유스케이스와 사용자 스토리, 개념 모델링 등을 사용한다.

기능분할
- 시스템 관점에서 외부에 제공해야 하는 서버스를 유형별로 최하위 단위 구성요소에 도달할 때까지 분할해 가는 방식으로 분석하는 방법이다.

유스케이스와 사용자 스토리
- 유스케이스란 시스템 경계 밖에 위치한 액터가 특정 목적을 달성하기 위해 시스템이 제공하는 기능을 이용하여 시스템과 일련의 상호 작용을 주고받는 시나리오로 나타낸 것이다.

유스케이스 표기법

개념 모델링

실세계 문제에 대한 모델링이 소프트웨어 요구 사항 분석의 핵심이며, 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.
유스케이스 다이어그램 , 데이터 흐름 모델 , 상태 모델, 목표 기반 모델, 사용자 인터액션, 객체모델 , 데이터 모델 등과 같은 다양한 모델을 작성할 수 있다. 대부분의 모델링 표기법은 UML 을 사용
우선순위가 가장 높은 요구사항은 전체 비용 중 가장 작은 부분을 차지하지만, 전체 제품의 가장 큰 부분을 제공한다. 우선순위 할당을 위해 아래와 같은 기법을 사용한다. 기법이 효과적이라면 간단한 기법일수록 바람직하다

할까/말까

모든 우선순위 할당 방법 중 가장 간단한 것은 요구 사항 목록 작업을 수행할 이해관계자 그룹을 확보하고 , 요구 사항 각각에 대해 할지 말지 양자택일을 하는 것이다.

짝 비교와 순위 나누기

요구 사항 목록의 순위를 나눌 경우 모든 것들에 대해 짝 비교를 하게 되므로 쌍의 구성원 중 어떤 것이 높은 우선순위인지 판단할 수 있다. 전체 시스템의 모든 기능적 요구 사항에 대해서는 아니지만 기능의 세분화 수준에서는 이 방법이 효과적일 수 있다.

3단계 규모조정

일반적인 운선순위 할당 접근 방식은 요구 사항을 세 가지 범주로 나누는 것이다. 높은 중간 낮음 으로 나누는 것인데 , 우선순위의 조정은 주관적이고 부정확하다. 이러한 조정을 유용하게 하기 위해서는 이해관계자의 규모 조정에서 사용하는 방법이 무엇인지 합의해야한다. 한가지 방법으로는 중요성과 긴급성이라는 두 항목을 고려하는 것이다. 즉 다음과 같은 네가지 조합을 준다 .

요구 사항 순위 할당

요구사항 명세화

소프트웨어 요구 사항 명세서 정의

예시

요구 사항 검증하기

SW 요구 사항 검증
- SW 요구 사항 검증이란 SW 개발의 기준선이 되는 요구 사항 명세서가 올바르게 작성되었는지 점검하는 것을 의미한다.

SW 요구 사항 검증과 확인의 차이
- SW 제품을 만드는 각 공정의 중간 산출물의 품질의 지속적으로 점검하는 두 가지 점검 방식은 크게 검증과 확인으로 나뉜다. 먼저, IEEE-STD-610 에서는 두 용어를 다음과 같이 정의하고 있다 . 한마디로 두 용어를 구분하면 , 검증은 제품을 올바르게 만들고 있는지를 점검하는 것인 반면, 확인은 올바른 제품을 만들었는지를 점검하는 것이라고 할 수 있다.