소프트웨어공학 - 소프트웨어 process

계층화된 기술로서의 소프트웨어공학

Tools
Methods
Process
Quality Focus

• 품질 중점
  • 품질에 대한 조직의 헌신
• 프로세스
  • 소프트웨어 공학의 기초
• 방법
  • 기술적으로 어떻게 하는가
• 도구
  • 약간 자동화된 프로세스와 방법을 지원

일반적인 단계

Definition -> Development -> Support(Maintenance)

정의 Definition

무엇을 할지에 집중하며, 주요 요구사항이 파악된다.

시스템 공학(System engineering)이나 정보 공학(Information Engineering)을 한다. 시스템 공학은 공학과 과학의 여러 분야의 지식을 활용하여 관련 지식을 기획과 개발 단계에 도입하는 기법이다. 정보공학은 컴퓨터과학과 경영학을 융합하여 시스템을 개발하는 것으로, 비즈니스 운영을 지원하는 정보시스템 설계 및 구현이 있다.

또한 프로젝트 관리(계획 및 일정 관리)를 하고, 요구사항 분석을 한다.

개발 Development

어떻게 할지에 집중한다.

소프트웨어를 설계하고, 코드를 만들고, 테스팅을 한다.

유지보수 Maintenance

어떤 것을 변경시킬 지에 집중한다.

결함을 수정하고, 외부 환경과 규칙에 적응하고, 추가 기능을 넣어 향상시킨다.

Umbrella Activities

Umbrella Activties는 모든 소프트웨어 프로세스에 적용되어 품질, 변경, 리스크 관리 등에 도움을 준다.

소프트웨어 프로젝트 추적 및 관리

프로젝트 계획의 진행 상황을 평가하고, 일정에 맞게 진행되도록 필요한 조치를 할 수있게 해준다.

리스크 관리

프로젝트나 품질에 영향을 줄 수 있는 리스크를 관리한다.

소프트웨어 품질 보증

소프트웨어 품질을 보장하기 위한 활동

공식적인 기술 리뷰

다음 단계로 넘어가기전에 오류를 발견하고 수정하는 것을 관리한다.

측정

이해관계자의 요구를 충족시키는 소프트웨어를 제공하는 데 초점을 맞춰 팀을 평가하는 프로세스, 프로젝트, 프로젝트 조치를 정의하고 수집. 다른 모든 프레임워크와 umbrella activities와 함께 사용할 수 있다.

버전 관리(configuration management)

소프트웨어 프로세스 전반에 걸쳐 변경의 영향을 관리한다.

재사용성 관리

제품이나 제품을 구성하는 요소를 재사용하는 기준을 정의하고, 재사용가능한 요소를 만들기 위한 방법을 개발한다.

제품 준비 및 생산

모델, 문서, 로그, 리스트 등을 만드는데 요구되는 것

Capability Maturity Model Integration(CMMI) - 성숙도 모델

현재 진행되고 있는 프로세스의 성숙도를 평가한다. 카네기 멜론 데학교의 Software Engineering Instutute(SEI)에 의해 개발되었다. 개발 조직에서 프로세스 성숙도를 판단할 수 있는 기준을 설정한다. 효과적인 소프트웨어 프로세스의 주요 요소를 설명해준다. -> Key Process Area

미숙하고 임시방편적인 프로세스에서 성숙하고 규율있는 프로세스로의 개선 경로를 설명한다.

소프트웨어 개발 및 유지보수를 계획, 엔지니어링 및 관리하는 업무 방식이 있다.

CMMI의 단계

initial(프로세스 없음) -> Repeatable(규칙화된 프로세스)-> Defined(표준화된 프로세스)-> Managed(예측가능한 프로세스)->Optimizing(지속적 개선 프로세스)

initial

소수의 프로세스가 정의되며 성공은 개인의 노력에 달려 있다.

Repeatable

기본적인 프로젝트 관리 프로세스를 정의한다. 이전에 유사한 애플리케이션을 사용하는 성공한 프로젝트의 방법을 반복한다.

Defined

관리 및 공학 활동이 모두 정의. 모든 프로젝트는 문서화되고, 승인된 프로세스를 사용한다.

Managed

공정 및 제품 품질에 대한 세부적인 측정을 수집한다. 프로세스와 제품 모두 정량적으로 측정하고 관리한다.

Optimizing

정량적 피드백(프로세스나 아이디어 및 기술을 평가하는 과정에서)을 통해 지속적인 프로세스 개선 가능

소프트웨어 프로세스

소프트웨어 제작에 관해 가이드하는 방법. 소프트웨어 제품의 품질은 제품을 만들고 수리하고 개선하는 데 사용되는 프로세스의 품질에 의해 크게 좌우된다. 효과적인 프로세스는 필수 작업, 도구 및 방법, 소프트웨어 개발자의 기술, 훈련 및 동기를 고려해야 한다. 소프트웨어 제품을 생산하고 발전시키는 과정은 정의, 관리 및 측정이 가능하며, 점진적으로 개선될 수 있다.

소프트웨어 프로세스 모델

소프트웨어를 어떻게 개발할 것인가에 대한 전체 흐름을 체계화. 계획 수립부터 폐기까지 다룬다. 각 단계에서 무엇을 해야하는지, 어떤 자원을 사용해야하는지, 각 단계의 순서를 명시하여 관리를 쉽게 한다.

프로젝트의 기본 골격을 세워준다. 즉 일정 수립, 개발 비용 산정, 의사소통 기준, 개발진행 상황 파악을 해주는데 도움을 준다.

소프트웨어 라이프 사이클

소프트웨어 프로세스의 대규모 모델이다. 소프트웨어 제품을 구상할 때 시작하여 제품을 더 이상 사용할 수 없게 되었을 때 종료된다.

소프트웨어 프로세스의 종류

소프트웨어 개발과정 : Overview

• 요구 분석: External view, Modeling(UML), CASE Tools
• 분석 및 설계 : Internal View, Modeling(UML), CASE Tools
• 구현 : Internal view, Programming(C++,java…), Programming Tools

주먹구구식 모델 Build-and-fix model

코딩(구현) -> 제품(고객이 만족할 때 까지 수정)->사용(다시 수정하기도 함)

개발자 한명이 단시간에 작업을 마칠 수 있는 경우에 사용할 수 있는 방법이다.

정해진 개발 순서나 각 단계별 산출물이 없어 관리가 어렵다. 여러 사람이 함께 할 때는 적합하지 않다.

선형 순차적 모델 Linear Sequential Model

소프트웨어 개발의 순차적인 접근이다.

분석 - 설계 - 코드 - 테스트

폭포수 모델

실현가능성 연구 <-> 요구 분석& 설명서 <-> 설계&설명서 <-> 코딩& 모듈 테스팅 <-> 통합 & 시스템 테스팅 <->배달 <-> 유지보수

각 단계마다 상세한 문서가 생성되는 문서 중심의 모델이다. 각 단계에서 산출물이 만들어지고 다음 단계의 입력으로 사용된다. 요구사항의 변화가 적은 프로젝트에 적합하다. 각 단계는 앞 단계에서 산출물을 넘겨주어야 수행할 수 있고, 결과물이 완벽해야 오류가 발생하지 않으며, 사용자가 중간에 가시적인 결과를 보기 힘들다.

각 단계별 문서
요구 분석 - 실현가능성 연구 및 요구의 개요
요구 정의 - 요구 문서
시스템 규격화 - 기능 문서화, 인수 테스트 및 초안 사용 설명서
아키텍처 설계 - 아키텍처 문서, 시스템 테스트 계획
인터페이스 설계 - 인터페이스 문서, 통합 테스트 계획
구체적인 설계 - 설계 문서, 단위별 테스트 계획
코딩 - 프로그램 코드
단위별 테스트 - 테스트 리포트
모듈 테스트 - 모듈 테스트 리포트
통합 테스트 - 통합 테스트 리포트, 사용자 메뉴얼
시스템 테스트 - 시스템 테스트 리포트
인수 테스트 - 최종적인 시스템, 문서

단위 테스트는 개발자가 수행하는 첫번째 테스트로, 구성 요소로 분리하여 테스트한다. 특정 구성요소로 제한되어 철저하게 테스트 할 수 있다.

모듈 테스트는 소프트웨어 제품의 개별 모듈이 요구사항대로 작동하는지 확인하는 것이다.

통합 테스트는 모듈이나 구성 요소를 서브시스템으로 결합한 다음 그룹으로 테스트하는 과정이다.

시스템 테스트는 소프트웨어 제품 전체를 테스트한다. 모든 구성 요소가 기대한 대로 함꼐 작동하는지 요구사항을 충족하는지 확인한다.

인수 테스트는 소프트웨어 제품이 고객의 요구사항 및 사양을 충족하는지 확인하기 위해 수행한다. 이것은 고객 또는 최종 사용자가 수행한다.

실현가능성 연구

제안된 해법의 비용과 이점을 평가한다. 전체적인 문제를 분석한다. 향후 개발 프로세스를 시뮬레이션한다. 여기서 제작되는 문서는 문제의 정의, 다른 해법과 기대되는 이점, 필요한 자원과 비용, 그리고 납기일 등이다.

요구 분석 및 설명서

애플리케이션에 필요한 품질을 파악한다. 기능적 및 비기능적 요구사항이 있다. 어떻게 해야하는지가 아니라 무엇을 해야하는지 명시되어야한다. 고객과 설계자 모두 사용한다. 기능적 요구사항은 3가지 관점에서 볼 수 있다.

A model of data: Entity relationship diagrams
A model of function: Data flow diagrams
A model of control: Control flow diagrams, Petri nets.

설계 및 설명서

해결하는 문제에 대한 솔루션을 제시한다. High-level과 low-level로 나뉘어진다. High-level에서는 시스템은 모듈로 분해하고, 모듈간의 관계를 지정한다. low-level에서는 각 모듈은 실제로 설계한다. 설계에는 데이터, 제어, 외부 인터페이스, 사용자 인터페이스가 있다.

코딩 및 모듈 테스팅

설계한 것은 코드로 변환하고, 시스템의 각 모듈을 테스트한다.

통합 및 시스템 테스팅

이전에 만든 구성 요소(모듈)를 합쳐 응용프로그램을 만든다.

통합 테스트 : 모듈 간 상호작용에 초점을 맞춘다.

시스템 테스트 : 시스템의 기능적 품질과 비기능적 품질의 평가에 초점을 맞춘다.

Delivery and Maintenace

유지 관리는 수정(20%), 새로운 환경에 적응(20%), perfective(60%)가 있다. 많은 오류는 실제로 전달되기 전까지 제거되지 않으며, 전달된 후 제품에 변경사항을 포함시키는 것은 어렵다.

기타

문서화, 검증(품질 검증, 각 단계가 끝날때마다 수행, (리뷰, 설명, 검사) 등의 방법이 있다), 관리(프로세스, 정책, 리소스)

선형 순차적 모델(폭포수 모델)의 평가

• 선형 : 개발은 분석에서 코딩까지 선형적으로 진행된다.
• 엄격 : 각 단계의 결과는 다음 단계로 진행되기 전에는 동결된다.
• 모놀리식 : single delivery date를 지향한다.
• 기여 : 규율화되고, 계획적이며, 관리가능한 접근 방식을 써야한다. 제품을 구현하는 것은 그 목적이 잘 이해될 때까지 연기해야한다.
• 문제점:
  • 리소스를 정확하게 추정하기 어렵다.
  • 고객은 정확한 요구사항을 모르는 경우가 많다.
  • 고객은 모든 요구사항을 명시적으로 설명하기 어려운 경우가 많다.
  • 변화를 예측해야한다는 점을 강조하지 않는다.
  • 다소 관료적인 작업 스타일
  • 실제 프로젝트는 순차적 흐름을 거의 따르지 않는다. 변화는 팀에 혼란을 줄 수 있다.
  • 고객은 인내심을 가져야한다(실제 작동하는 프로그램은 꽤 나중에 이용할 수 있다).
  • 오류가 뒤늦게 발견되면 고치기 어렵다.

프로토타입 모델

요구사항이 불명확하거나 모호할 때, 그리고 실행가능성이 의심스러울 때 효과적이다. 요구사항 수집, 빠른 디자인, 포로토타입 제작(프로토타입은 최초의 시스템으로 고객에게 제출될 수도 있고, 폐기될 수도 있다.)

고객의 요구를 들음 -> 모형 구축/수정 -> 고객이 모형을 테스트함
위 3가지의 반복이다.

프로토타입 모델의 장점

현실적이고 눈에 보인다. 즉 고객이 ‘보면 알겠다’의 태도에 알맞는 모델이며, 고객은 보고 실제로 시도해 볼 수 있다. 고객은 프로토타입을 통해 구체적인 비교 및 구체적으로 요구사항을 만들 수 있다. 고객과 개발자 모두에게 공통된 기준점을 생성하고, 프로젝트에 대한 고객의 참여를 이끈다.

프로토타입 모델의 단점

시제품이 최종 제품, 최종 제품이 거의 만들어졌다는 잘못된 믿음을 줄 수 있으며, 프로토타입을 과대평가하여 최종 시스템에서 더 많은 것을 요구할 수 있다. 특히 관리가 어려운데, 구체적인 단계와 이정표가 부족하기 때문이다. 실제 진행 상황을 평가하기 더 어렵다.

RAD(빠른 응용프로그램 개발) 모델

60~90일과 같은 매우 짧은 시간 내에 완전한 기능을 하는 시스템을 만들기 위해 선형 순차적 모델을 고속으로 만들어 빠른 개발을 가능하게 한다.

각 주요 기능을 3개월 이내에 모듈화할 수 있다면 적합하다. 따라서 시스템을 제대로 모듈화할 수 없다면, 적합하지 않다. 또한 고성능이 요구되고 리스크가 높을 때도 적합하지 않다.

각 주요 기능을 별도의 RAD 팀이 담당하여, 재사용 가능한 구성요소를 사용하고, Object Technology의 초석이다.

Team1 : Business Modeling - Data Modeling - Process Modeling - Applicatoin generation - Testing and turnover

            Team2 : Business Modeling - Data Modeling - Process Modeling - Applicatoin generation - Testing and turnover

                    Team3 : Business Modeling - Data Modeling - Process Modeling - Applicatoin generation - Testing and turnover

RAD 모델의 단점

규모가 큰 프로젝트의 경우, 적절한 수의 RAD 팀을 만들기 위해 충분한 인력이 필요하다. 또한 빠르게 만들기 위해 많은 노력이 필요하다.

진화적 프로세스 모델

• 반복적 프로세스 : 소프트웨어 엔지니어가 점점 더 완벽한 버전의 소프트웨어를 개발할 수 있게 해줍니다.

• Incremental Model : 선형 순차적 모델과 프로토타입 모델 결합. 각 선형 시퀸스는 소프트웨어를 점진적으로 발전시킨다. 인력이 적을 경우 유용하다.

분석 - 설계 - 코딩 - 테스트 -> 첫번째 버전
    분석 - 설계 - 코딩 - 테스트 -> 두번째 버전
        분석 - 설계 - 코딩 - 테스트 -> 세번째 버전
            ...

incremental model은 폭포수 모델의 규율을 각 빌드마다 유지해야한다.

Incremental 모델의 장점과 단점

사용자에게 신제품에 적응할 시간을 제공하고, 변경사항을 쉽게 처리할 수 있다. 자본 지출이 적다.

각각의 추가빌드는 기존 빌드에 통합되어야하고, 좀 더 세심한 설계가 필요하며, 주먹구구식 모델로 쉽게 퇴보할 수 있다.

나선형 모델

소프트웨어는 점점 발전된 릴리스로 개발된다.

Customer Communication -> Planning -> Risk Analysis -> Engineering -> Construction and Release -> Customer Evaluation

의 반복(반복하면서 어떤 것을 개발할지 파악하고, 개발하고, 발전시키며, 유지보수한다)

나선형 모델의 장점과 단점

소프트웨어 수명 전반에 걸쳐 적용이 가능하다. 리스크가 감소하고, 대규모 시스템에 적합하다.

통제가 어렵고, 고객을 설득하기 어렵다.

요소 기반 개발

나선형 모델을 통합한 것

미리 패키지된 소프트웨어 구성요소 (클래스 등)로부터 응용 프로그램을 구성한다. 객체 지향을 사용한다.

높은 재사용성으로 개발시간과 비용을 절감한다.

Formal method model

소프트웨어의 수학적 사양을 쓴다. 엄격한 수학적 표기법을 적용하여 소프트웨어를 명시하고, 개발하고, 검증한다.

장점

모호성, 불완전성, 불일치를 제거한다.

단점

꽤 많은 시간을 소모하고, 이것을 수행할 수 있는 엔지니어가 거의 없다.

참고 문헌

• https://www.britannica.com/topic/systems-engineering
• https://in.indeed.com/career-advice/finding-a-job/system-engineer-vs-software-engineer
• https://engineering.virginia.edu/departments/systems-and-information-engineering
• https://www.indeed.com/career-advice/finding-a-job/network-engineer-vs-system-engineer
• https://www.coursera.org/articles/systems-engineer