소프트웨어 공학 1차시

소프트웨어의 정의

• 프로그램 : 프로그래밍한 원시 코드(source code)
• 소프트웨어 : 프로그램 뿐만 아니아 그 이상의 것도 포함하는 매우 포괄적인 개념

 

 

소프트웨어의 분류★

• 관리 소프트웨어 :
  • 자료를 받아들여 가공한 후 정보를 제공하는 소프트웨어
  • 주로 DB에 자료를 저장한 후 검색을 통해 사용자가 원하는 형태로 정보를 제공 ( 인터넷 뱅킹, 종합정보 시스템, 예약 시스템 등)
• 제어 소프트웨어 :
  • '각종 센서를 이용하거나 기기들의 동작을 제어하는 소프트웨어 ( 교통 신호 제어, 의료기기 제어, 공장장비 제어 등)
  • 사용자 메뉴얼
• 임베디드 소프트웨어 
  • 장비나 기기에 내장된 형태의 소프트웨어 ( 가전제품 내의 소프트웨어, 각종 공정제어 시스템 네의 소프트웨어)
  • 변경이 어려뭄
  • 개발방법과 프로세스가 달라 별도 분야로 취급
• 주문형 소프트웨어
  • 특정 고객의 수요를 만족하기 위해 개발된 소프트웨어
  • 웹사이트, 항공 - 교통 제어 시스템, 재정관리 시스템 등
• 패키지형 소프트웨어
  • 일반적으로 공개된 시장에서 판매, 범용 소프트웨어라고도 함
  • 주문형 대비 저렴하고 신뢰도가 높지만, 특정 기관의 요구에 맞지 않을 수 있음
• 리얼타임 소프트웨어
  • 제어, 모니터링 소프트웨어
  • 신속한 반응, 안정성 확보가 매우 중요
• 자료처리 소프트웨어
  • 비즈니스 업무 처리에 사용
  • 자료의 정확성과 보안이 관건
  • 일괄 처리
• 두 가지 성격 (리얼타임 + 자료처리)을 동시에 지닌 소프트웨어
  • 전화 통신 시스템 : 전화는 리얼타임, 청구는 자료처리

 

소프트웨어의 특징

• 제조가 아닌 개발
  1. 제조 : 개인 능력에 따라 차이가 크지 않으므로 능력에 따른 결과물의 차이는 크지 않음
  2. 소프트웨어 개발 과정은 제조와 달리 개인 능력에 따라 차이가 큼
• 소모가 아닌 품질 저하
  • 하드웨어 : 오래 사용하면 부품이 닳고 기능도 떨어짐
  • 소프트웨어 : 닳지 않으며 또한 시간이 지나도 고장 빈도가 높지 않음, 사용 시작 단계부터 사용자의 요구가 계속 발생

 

소프트웨어의 당면 과제

• 소프트웨어 개발의 느린 발전 속도
  • H/W의 발전 : PC 및 스마트 폰의 발전 속도(크기, 속도, 성능)
  • S/W의 발전 속도 : DOS ~ Windows 11
• 새로운 소프트웨어에 대한 사용자의 요구의 증가
  • S/W의 발전 속도가 미처 따라가지 못함
  • H/W와 S/W의 개발 방법의 근본적인 차이 때문
  • (해결 방안) CBD 개발 방법론

 

소프트웨어 공학

• 소프트웨어 공학의 학문적 정의 :
  • 품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획읳 세우고, 새발하며, 유지 맟 관리하는 전 과정에서 공학, 과학 및 수학적 원라와 방법을 적용해 필요한 이론과 기술 및 도구 들에 관해 연수하는 학문 → 소비자가 만족해야

 

 

---

 

 

주먹구구식 모델 - Build & fix, Code & fix, 즉흥적 소프트웨어 개발 모델

• 공식적인 가이드라인이나 프로세스가 없는 개발 방식
• 즉흥적 소프트웨어 개발 꼬는 코딩과 수정 모델이라고 함
• 코드를 작성해 제품을 만든 후에 요구분석, 설계, 유지보수에 대해 생각
• 첫 번째 버전의 코드를 작성해 제품을 완성한 귀 작성된 코드에 문제가 있으면 수정해서 해결하고 문제가 없으면 사용

 

주먹구구식 모델의 단점

• 정해진 개발 순서나 각 단계별로 문서화된 산출물이 없어 관리 및 유지보수가 매우 어려움
• 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍퍼를 만들 수도 없음
• 개발자가 일을 효과적으로 나눠 할 수도 없음
• 프로젝트 진척 상황을 거의 파악할 수 없음
• 코딩을 먼저 하므로 수정할 가능성이 많은데, 여러 번 수정하다 보면 사독성이 높았던 프로그램의 구조가 나빠져 수정이 매우 어려워짐

 

선형 순차적 모델 - Classic life cycle

• 폭포에서 물이 떨어지듯이 다음 단계로 넘어가는 모델
• 소프트웨어 공학의 대명사로 여겨질 만큼 초기에 개발된 전통적인 모델
• 공장 생산 라인의 작업 프로세스와 유사한데, 표준 프로세스를 정해 소프트웨어를 순차적을로 개발

 

폭포수 모델의 개발 절차

• 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계,  구현, 테스트, 유지보수의 각 단계가 하향식으로 진행
• 각 단계가 끝날 때 마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 나아감

 

V 모델

• 폭포수 모델의 변형으로, 테스트 단계를 추가 확장해 테스트 단계가 분석 및 설계와 어떻게 관련되어 있는지를 나타냄
• 폭포수 모델이 산출물 중심이라면, V 모델은 각 개발 단계를 검증하는 데 초점을 두므로 오류를 줄일 수 있음

 

단계적 개발 모델

• 개발자가 먼저 릴리스 1을 개발해 사용자에게 제공하면 사용자가 이를 사용
• 사용자가 릴리스 1을 사용하는 동안 개발자는 다음 버전인 릴리스 2를 개발
• 개발과 사용을 병행하는 과정을 반복해 진행하면서 완료
• 릴리스를 구성하는 방법에 따라 점증적 개발 방법과 반복적 개발 방법으로 나뉨

점증적 개발 방법 : 개발 범위의 증가

• 중요하다고 생각되는 부분부터 차례로 개발한 후 그 일부를 사용하면서 개발 범위를 점차 늘려 가는 방식
• 돈이 부족 할 경우 사용하기도함
• 점증적 방법 - 소프트웨어 개발
  • 요구분석 명세서에 명시된 시스템 전체를 기능에 따라 독립성 높은 서브 시스템으로 분할
  • 각 서브 시스템을 단계적으로 하나씩 릴리스 해 완성하는 방법
• 점증적 방법의 장점과 단점
  • 한꺼번에 많은 비용을 들이지 않아도 됨

반복적 개발 방법 : 품질의 증가

• 초기에 시스템 전체를 일차적으로 개발해 인도한 후, 각 서브 시스템의 기능과 성능을 변경 및 보강해 완성도를 높임
• 초기의 요구사항이 불분명한 경우에 적합

 

통합 프로세스 모델

• 폭포수 모델은 각 단계별로 깔끔하게 정리되어 있지만 사용자의 요구사항이 많으면 민첩하게 대처할 수 없음
• 폭포수 모델의 문제점을 해결하기 위해 작업을 계속해서 반복 수행하는 반복적 개발 방법론이 등장
• 통합 프로세스 모델은 반복적 생명주기를 기반으로 하는 모델 중 가장 많이 사용

통합 프로세스 모델의 절차

• 통합 프로세스 모델의 개발 과정은 크게 4단계 (도이브 구체화, 구축, 전이)로 나뉨
• 도입 단계
  • 구현, 테스트, 배치 작업은 거의 없고 '비즈니스 모델링'과 요구사항 정의' 관련 작업이 가장 많이 이루어짐
• 구체화 단계
  • 비즈니스 모델링과 요구사항 정의 작업은 점차 줄고, 대신 분석 및 설계 작업이 크게 이루어짐
  • 설계 결과에 따른 구현(코딩) 작업, 구현에 대한 단위 테스트가 조금씩 시작
• 구축 단계
  • 구현 작업이 가장 많이 이루어짐
  • 비즈니스 모델링과 요구사항 정의 작업은 점차 줄고, 분석 및 설계 작업도 구체화 단계보가 줄어듦
• 전이 단계
  • 이행 단계라고도 하며 사용자를 위한 제품을 완성하는 단계
  • 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일을 수행

애자일 프로세스 모델

• 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론
• 가벼운 프로세스 방법론의 공통적인 특성을 정의

애자일의 기본 가치

• 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
• 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
• 계약과 협상 중심이 아닌, 고객과의 협력을 중시

애자일의 원칙

• 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것
• 동작 가능한 소프트웨어를 짧으면 2주, 길면은 2개월 간격으로 자주 고객에게 전달. 

애자일 프로세스 모델 : 스크럼

• 소프트웨어 개발 보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론
• 경험적 관리 기법 중 하나
• 구체적인 프로세스를 명확하게 제시하지 않음