본문내용
1. 소프트웨어 공학 개요
1.1. 소프트웨어 공학의 정의
소프트웨어 공학의 정의는 최소의 비용으로 고품질의 소프트웨어를 개발하고 유지보수하기 위한 모든 기법을 총칭한다. 소프트웨어는 개발, 운용, 유지보수에 필요한 모든 정보와 프로그램으로 구성되어 있다. 소프트웨어는 비가시성, 복잡성, 적합성, 동적행위성, 비마모성, 상품성, 견고성 등의 특징을 가지고 있다. 좋은 소프트웨어의 특성에는 이해 용이성, 수정 용이성, 관리 용이성, 재사용 용이성, 테스트 용이성, 확실성, 효율성 등이 있다. 소프트웨어는 시스템 소프트웨어, 응용 소프트웨어, 임베디드 소프트웨어, 패키지 소프트웨어 등으로 분류된다. 소프트웨어 위기는 규모가 커짐에 따라 발생하는 문제점이며 이를 해결하기 위해서는 자동화된 기술 사용, 문서화 등의 개선이 필요하다. 신뢰성은 고장 없이 운영될 수 있는 확률이고, 가용성은 특정 시점에 서비스할 수 있는 확률이다. 고장은 설계와 개발과정에 유입된 오류에 의해서만 발생하므로 결함 회피, 결함 탐지 및 제거, 결함 내성 등을 적용해야 한다. 소프트웨어 개발 프로세스에는 인력(P), 문제(P), 프로세스(P)가 포함되며 계획, 요구분석, 설계, 구현, 테스트, 유지보수의 단계로 이루어진다.
소프트웨어 프로세스 모델에는 폭포수 모델, 프로토타이핑 모델, 나선형 모델, V 모델, 일정중심 설계모델, 진화적 출시모델, 통합 프로세스(RUP), 애자일 프로세스, 익스트림 프로그래밍(XP), 스크럼(Scrum) 등이 있다. 폭포수 모델은 각 단계가 순차적으로 진행되며 이전 단계의 산출물이 필요한 특징이 있다. 프로토타이핑 모델은 초기에 구현을 시작하고 그 버전을 다듬어 가는 진화적 프로세스이다. 나선형 모델은 위험관리가 추가된 프로세스 모델로, 위험요소를 확인하고 그에 대한 대안을 분석한다. V 모델은 각 단계마다 검증과 확인 단계가 있어 신뢰도가 높은 시스템 개발에 유용하다. 일정중심 설계모델은 최종목표와 출시 일정이 명확하지 않은 상태로 시작하는 모델이다. 진화적 출시모델은 단계별로 증분을 정의하여 점증적으로 개발한다. 통합 프로세스(RUP)는 비즈니스 관점에 초점을 둔 반복적이고 점증적인 프로세스이다. 애자일 프로세스는 빠른 속도로 자주 출시하고 요구사항 변화에 민첩하게 대응하는 특징이 있다. 익스트림 프로그래밍(XP)은 고객의 적극적인 참여가 특징이며, 스크럼(Scrum)은 경험적 관리기법을 사용한다.
프로젝트 관리와 계획에는 문제의 범위 설정, 타당성 분석, 노력 추정, 일정 계획, 조직 계획 등이 포함된다. 문제의 범위는 사용자 관점에서 작성해야 하며, 타당성 분석에는 경제적, 기술적, 법적 타당성이 고려된다. 노력 추정은 하향식 방법, 상향식 방법, 델파이법 등이 사용된다. 일정 계획에는 WBS, CPM 네트워크, PERT, 간트차트 등이 활용된다. 조직 계획은 경험 많은 사람과 적은 사람의 적절한 혼합이 중요하다.
요구 분석 단계에서는 기능적 요구사항과 비기능적 요구사항을 정의한다. 도메인 요구사항은 도메인의 제약과 특징을 나타내며 요구사항 추출 방법으로는 관찰, 인터뷰, 프로토타이핑 등이 활용된다. 구조적 분석은 기능적 관점에서 다루고, 객체지향 분석은 사용사례로 표현한다. 요구분석 명세서는 사용자와 개발자 간 계약서 역할을 하며 완벽성, 명확성, 일관성 등의 평가기준이 있다. 요구공학 프로세스 단계에는 타당성 조사, 요구사항 추출 및 분석, 요구사항 명세화, 요구사항 검증 등이 포함된다.
모델링에는 데이터 중심 설계, 처리 중심 설계, 개념적 설계, 논리적 설계, 물리적 설계가 있다. 개체, 관계, 개체타입, 관계타입 등의 개념을 사용하여 ERD로 표현한다. 정규화는 릴레이션 스키마를 변형하여 데이터 중복을 최소화한다. 데이터베이스 설계 및 모델링에서도 유사한 절차가 적용된다. 구현 단계에서는 코딩 지침, 리팩토링, 인스펙션, 정적 분석, 단위 테스트 등을 수행한다.
테스트에는 블랙박스 테스트, 화이트박스 테스트, 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 등의 절차가 포함된다. 테스트의 목적은 오류 발견, 요구사항 충족 확인, 명세 충족 확인, 결함 예방 등이다. 유지보수에는 수정, 적응, 완전, 예방 등의 종류가 있으며 형상관리, 역공학, 재공학, 재사용 등의 개념이 활용된다.
1.2. 소프트웨어 특징
소프트웨어는 비가시성이 있어 무형적이다. 또한 개발 과정이 복잡하여 높은 복잡성을 가지고 있다. 그리고 환경 변화에 대응할 수 있는 적합성이 있다. 소프트웨어는 하드웨어상에서 동작하는 동적행위성을 가지고 있으며, 소모되거나 닳지 않는 비마모성의 특징이 있다. 또한 구매할 수 있는 상품성과 수정하기 어려운 견고성을 지니고 있다. 이처럼 소프트웨어는 다양한 특징을 가지고 있어 복잡하면서도 강력한 기능을 발휘할 수 있다.
소프트웨어의 이해 용이성은 사용자가 쉽게 이해할 수 있어야 함을 의미한다. 수정 용이성은 수정이 가능해야 함을, 관리 용이성은 수정하기 쉽도록 구현되어야 함을 나타낸다. 재사용 용이성은 소프트웨어의 재사용이 가능해야 함을 뜻하며, 테스트 용이성은 테스트하기 쉬워야 함을 의미한다. 마지막으로 소프트웨어는 신뢰성, 보안성, 안전성, 가용성 등 다양한 확실성을 확보해야 하며, 효율성도 갖추어야 한다.
이처럼 소프트웨어에는 다양한 특징이 존재하며, 이러한 특징들은 소프트웨어의 성능과 품질을 결정하는 데 중요한 역할을 한다. 이해 용이성, 수정 용이성, 관리 용이성, 재사용 용이성, 테스트 용이성, 확실성, 효율성 등의 특징은 소프트웨어 공학에서 핵심적으로 다루어지는 사항들이다.
1.3. 좋은 소프트웨어 특성
이해하기 쉬운 소프트웨어는 사용자가 쉽게 이해할 수 있다. 수정하기 쉬운 소프트웨어는 변경이 편리하다. 관리하기 쉬운 소프트웨어는 유지보수가 용이하다. 재사용하기 쉬운 소프트웨어는 다른 환경에서도 활용 가능하다. 테스트하기 쉬운 소프트웨어는 오류 검출이 용이하다. 확실한 소프트웨어는 신뢰성, 보안성, 안전성, 가용성을 겸비하고 있다. 효율적인 소프트웨어는 자원을 낭비하지 않는다.
이해하기 쉬운 소프트웨어는 사용자가 쉽게 이해할 수 있다. 사용자 친화적인 인터페이스와 간단한 기능으로 구성되어 있어 사용자가 쉽게 학습하고 사용할 수 있다. 또한 명확한 문서화를 통해 소프트웨어의 기능과 사용법을 쉽게 습득할 수 있다.
수정하기 쉬운 소프트웨어는 변경이 편리하다. 소프트웨어의 구조가 유연하고 모듈화되어 있어 특정 기능을 손쉽게 수정하거나 추가할 수 있다. 또한 유지보수를 위한 충분한 문서화가 되어 있어 변경 사항을 쉽게 반영할 수 있다.
관리하기 쉬운 소프트웨어는 유지보수가 용이하다. 소프트웨어의 구조가 단순하고 일관성 있게 설계되어 있어 오류 수정 및 기능 개선이 수월하다. 또한 체계적인 형상관리와 테스트 체계를 갖추고 있어 지속적인 관리가 가능하다.
재사용하기 쉬운 소프트웨어는 다른 환경에서도 활용 가능하다. 소프트웨어의 구조가 모듈화되어 있고 독립적인 기능 단위로 설계되어 있어 다른 프로젝트에서도 손쉽게 재활용할 수 있다. 또한 관련 문서화가 잘 되어 있어 이해와 적용이 용이하다.
테스트하기 쉬운 소프트웨어는 오류 검출이 용이하다. 소프트웨어의 구조가 명확하고 모듈화되어 있어 각 기능 단위별로 체계적인 테스트가 가능하다. 또한 테스트 케이스 작성과 자동화가 용이하여 다양한 상황에 대한 테스트를 효율적으로 수행할 수 있다.
확실한 소프트웨어는 신뢰성, 보안성, 안전성, 가용성을 겸비하고 있다. 엄격한 요구사항 관리와 철저한 테스트를 통해 오류와 취약점이 최소화되어 있다. 또한 적절한 인증 및 권한 관리, 데이터 암호화 등의 보안 대책이 마련되어 있어 안전하게 운영될 수 있다.
효율적인 소프트웨어는 자원을 낭비하지 않는다. 하드웨어 자원 및 네트워크 대역폭, 메모리 등의 사용을 최적화하여 시스템 전체의 성능을 향상시킨다. 또한 불필요한 기능이나 코드를 제거하여 소프트웨어 자체의 크기와 복잡도를 최소화한다.
이와 같이 좋은 소프트웨어는 사용자 친화성, 유지보수성, 재사용성, 테스트 용이성, 안전성, 효율성 등의 특성을 갖추고 있다. 이를 통해 사용자의 요구를 효과적으로 만족시키고, 개발 및 운영 비용을 절감할 수 있다.
1.4. 소프트웨어 분류
소프트웨어는 그 목적과 기능에 따라 크게 시스템 소프트웨어, 응용 소프트웨어, 임베디드 소프트웨어, 패키지 소프트웨어의 4가지로 분류된다.
시스템 소프트웨어는 컴퓨터 하드웨어를 관리하고 제어하며, 그 위에서 동작하는 다른 소프트웨어를 지원하는 프로그램이다. 운영체제(OS)와 데이터베이스 관리 시스템(DBMS) 등이 이에 해당한다.
응용 소프트웨어는 사용자의 특정한 요구사항을 충족시키기 위해 개발되는 프로그램이다. 문서 작성기, 스프레드시트, 웹 브라우저 등이 대표적인 예이다.
임베디드 소프트웨어는 특정한 하드웨어 장치 내에 내장되어 동작하는 프로그램이다. 자동화 설비, 통신 장비, 자동차 등에 내장되어 해당 기기의 기능을 수행한다. 임베디드 소프트웨어는 확장성이 떨어지는 편이다.
패키지 소프트웨어는 다수의 사용자를 대상으로 범용적으로 개발되어 판매되는 프로그램이다. 오피스 제품군, 그래픽 편집기, 회계 프로그램 등이 이에 해당된다. 패키지 소프트웨어는 사용자의 특정 요구사항을 충족시키기 어려운 단점이 있다. 최근 클라우드 컴퓨팅의 확산으로 인해 SaaS(Software as a Service) 형태의 패키지 소프트웨어가 증가하고 있다.
이처럼 소프트웨어는 그 목적과 용도에 따라 다양한 분류가 가능하며, 각 분류별로 고유한 특성과 장단점이 있다. 소프트웨어 개발 시에는 이러한 분류를 고려하여 적절한 소프트웨어 유형을 선택하는 것이 중요하다.
1.5. 소프트웨어 위기와 브룩스 법칙
소프트웨어 개발 규모가 커짐에 따라 다양한 문제점이 발생하고 있다. 먼저, 요구사항이 점점 복잡해지고 늘어남에 따라 개발 기간이 지연되는 문제가 있다. 또한 프로젝트에 참여하는 인원이 증가하면서 관리와 조정의 어려움이 증가하고 있다. 이러한 소프트웨어 위기를 해결하기 위해서는 자동화된 기술 사용, 철저한 문서화 등의 개선 노력이 필요하다.
브룩스 법칙은 이러한 소프트웨어 위기와 관련된 핵심 내용이다. 브룩스 법칙에 따르면 인원을 추가한다고 해서 개발 기간이 단축되지 않는다. 오히려 인력이 늘어나면 의사소통과 조정의 복잡성이 증가하여 개발 기간이 더 늘어날 수 있다. 이는 소프트웨어 개발의 특성상 모든 작업이 연관되어 있어 새로운 인력의 투입만으로는 생산성 향상에 한계가 있기 때문이다. 따라서 소프트웨어 위기를 해결하기 위해서는 단순히 인력을 늘리는 것보다는 자동화된 기술 사용, 철저한 문서화 등의 개선 노력이 필요하다.
소프트웨어 개발 규모가 점점 커짐에 따라 다양한 문제점이 발생하고 있다. 먼저, 요구사항이 점점 복잡해지고 늘어남에 따라 개발 기간이 지연되는 문제가 있다. 또한 프로젝트에 참여하는 인원이 증가하면서 관리와 조정의 어려움이 증가하고 있다. 이러한 소프트웨어 위기를 해결하기 위해서는 자동화된 기술 사용, 철저한 문서화 등의 개선 노력이 필요하다.
브룩스 법칙은 이러한 소프트웨어 위기와 관련된 핵심 내용이다. 브룩스 법칙에 따르면 인원을 추가한다고 해서 개발 기간이 단축되지 않는다. 오히려 인력이 늘어나면 의사소통과 조정의 복잡성이 증가하여 개발 기간이 더 늘어날 수 있다. 이는 소프트웨어 개발의 특성상 모든 작업이 연관되어 있어 새로운 인력의 투입만으로는 생산성 향상에 한계가 있기 때문이다. 따라서 소프트웨어 위기를 해결하기 위해서는 단순히 인력을 늘리는 것보다는 자동화된 기술 사용, 철저한 문서화 등의 개선 노력이 필요하다.
소프트웨어 개발 규모가 점점 커짐에 따라 요구사항이 복잡해지고 개발 기간이 지연되는 문제, 참여 인원이 증가하면서 관리와 조정의 어려움이 발생하는 등 다양한 소프트웨어 위기가 나타나고 있다. 이를 해결하기 위해서는 자동화된 기술 사용, 철저한 문서화 등의 개선 노력이 필요하다.
브룩스 법칙은 이러한 소프트웨어 위기와 관련된 핵심 원리이다. 브룩스 법칙에 따르면 인원을 늘린다고 해서 개발 기간이 단축되지 않는다. 오히려 인력이 증가하면 의사소통과 조정의 복잡성이 커져 개발 기간이 더 늘어날 수 있다. 이는 소프트웨어 개발 작업이 모두 연관되어 있어 단순히 인력을 추가하는 것만으로는 생산성 향상에 한계가 있기 때문이다. 따라서 소프트웨어 위기를 극복하기 위해서는 자동화와 문서화 등의 개선 노력이 필요하며, 인력 증가만으로는 해결책이 되지 못한다.
1.6. 신뢰성과 가용성
고장이란 시스템이 기대되는 서비스를 제공하지 못하는 상태이며, 고장의 원인은 설계와 개발과정에서 유입된 결함에 있다. 신뢰성이란 고장 없이 운영될 수 있는 확률을 의미하고, 가용성이란 특정 시점에 서비스할 수 있는 확률을 의미한다. 신뢰성을 높이기 위해서는 결함 회피, 결함 탐지 및 제거, 결함 내성 등의 방법을 적용해야 한다.
시스템의 신뢰성을 높이기 위해서는 시스템 설계 단계부터 사용자가 기대하는 서비스를 제공할 수 있도록 하고, 운영 중에 발생할 수 있는 오류나 고장을 최소화해야 한다. 이를 위해서는 시스템의 아키텍처와 구현 과정에서 결함을 최소화할 수 있는 설계 기법을 적용해야 한다. 또한 시스템 운영 중에 발생할 수 있는 오류나 고장을 신속하게 감지하고 대응할 수 있는 모니터링 및 장애 관리 체계를 갖추어야 한다.
가용성을 높이기 위해서는 시스템의 중복성을 확보하거나 고장 시 신속한 복구가 가능하도록 설계해야 한다. 시스템의 중요도와 위험도에 따라 적절한 수준의 가용성을 확보해야 하며, 이를 위한 백업 및 복구 전략, 장애 대응 체계 등이 필요하다.
신뢰성과 가용성은 시스템 품질 수준을 결정하는 핵심 요소이다. 따라서 소프트웨어 개발 생명주기 전반에 걸쳐 이를 고려하여 설계, 구현, 테스트, 운영 등의 활동을 수행해야 한다. 또한 사용자의 요구사항과 시스템의 중요도에 따라 적절한 수준의 신뢰성과 가용성을 확보하기 위한 노력이 필요하다.
1.7. 개발 프로세스
개발 프로세스는 소프트웨어 공학의 핵심 단계이다. 개발 프로세스는 소프트웨어 개발의 전체적인 프로세스를 정의하며, 요구사항 분석, 설계, 구현, 테스트, 유지보수 등의 세부 단계로 구성된다.
먼저, 요구사항 분석 단계에서는 사용자의 요구사항을 정의하고 이를 체계적으로 기술한다. 다음으로, 설계 단계에서는 소프트웨어의 구조와 기능을 상위 수준에서 정의하며, 데이터와 처리 로직을 설계한다. 구현 단계에서는 설계된 내용을 프로그래밍 언어로 구현하며, 코딩 지침과 인스펙션, 정적 분석 등을 통해 코드의 품질을 관리한다. 테스트 단계에서는 블랙박스 테스트와 화이트박스 테스트를 수행하여 소프트웨어의 기능과 품질을 확인한다. 마지막으로 유지보수 단계에서는 소프트웨어의 결함을 수정하고 변경사항을 반영하며, 형상관리와 역공학, 재공학 등의 기법을 활용한다.
각 단계에서는 체계적인 프로세스와 기법을 활용하여 소프트웨어의 품질과 생산성을 높인다. 예를 들어, 요구사항 분석 단계에서는 구조적 분석과 객체지향 분석 기법을 사용하고, 설계 단계에서는 데이터 중심 설계, 처리 중심 설계, 정규화 등의 방법론을 적용한다. 구현 단계에서는 코딩 지침, 리팩토링, 정적 분석 등을 통해 코드의 품질을 관리하며, 테스트 단계에서는 다양한 테스트 기법을 활용하여 결함을 체계적으로 발견하고 수정한다. 마지막으로 유지보수 단계에서는 형상관리와 역공학, 재공학 기법을 통해 소프트웨어의 변경과 개선을 원활하게 수행한다.
이와 같이 개발 프로세스는 소프트웨어 개발의 전체적인 수명 주기를 정의하며, 각 단계에서 다양한 기법과 방법론을 활용하여 소프트웨어의 품질과 생산성을 높인다. 이를 통해 최종적으로 사용자의 요구사항을 충족하는 고품질의 소프트웨어를 개발할 수 있다.
2. 소프트웨어 프로세스 모델
2.1. 폭포수 모델
폭포수 모델은 순차적으로 진행되는 소프트웨어 개발 프로세스이다. 다음 단계는 이전 단계가 끝나고 산출물(문서)이 나와야 넘어갈 수 있으며, 바로 전 단계에 결함이 있으면 다시 돌아갈 수 있지만 전전 단계로는 이동할 수 없다. 직능 중심의 프로젝트 조직이 가능하고, 크고 복잡한 오래 지속되는 프로젝트에 적합하다. 그러나 요구사항에서 지연이 발생할 경우 다음 단계들 모두 지연되며, 요구변경 수용이 어렵고 재사용을 위한 기회가 없다는 단점이 있다. 또한 최종단계까지 가야 결과물이 나오는 특성이 있다.
2.2. 프로토타이핑 모델
프로토타이핑 모델은 진화적 프로세스 모델이며, 폭포수 모델과 프로토타입을 결합한 모델이다. 사용자 요구가 불명확하고 요구사항 변화가 많은 경우에 적합하다. 구현 전 단계를 계속 반복하며 프로토타입에 요구사항들을 반영해 나간다. 사용자의 추가 요구사항이 없을 때 최종 프로토타입이 만들어진다. 프로토타입은 사용자 인터페이스를 중심으로 설계한다. 충분한 요구사항 반영이 가능하지만, 인력 및 비용 산정이 어렵다. 중간 과정 산출물이 없어 고객에게 빠르게 완성될 수 있다는 착각을 줄 수 있다. 따라서 프로토타입 모델은 사용자 요구가 불명확하고 지속적인 변화가 예상되는 경우에 적합하다. 구현 전 단계를 계속 반복하며 프로토타입을 발전시켜 나가기 때문에 사용자 요구사항을 잘 반영할 수 있다. 하지만 인력 및 비용...
