개인정보보호, 소프트웨어 정책
1. 소프트웨어
■ 소프트웨어는 컴퓨터 프로그램과 이와 관련된 데이터·정보·문서를 총칭함
○ 컴퓨터의 기계적인 부분(H/W)을 동작시키기 위한 프로그램(Program)과 이와 관련된 데이터(Data)와 정보(Information)·문서(Documentation)를 의미
–만들어지면 수정이 불가능한 Hard-ware와 달리 프로그램은 변경이 가능하다는 의미로 Software로 명칭
–음악에서 악기를 하드웨어에 비유한다면, 악보는 소프트웨어에 비유됨
■ 소프트 웨어의 특징
– 상품성 : 소프트웨어는 상품적 가치를 가진다.
– 견고성 : 일부 수정하게 된 것이 전체 소프트웨어가 영향을 준다.
– 복잡성 : 개발과정이 복잡하고 비 표준이기 때문에 관리가 어렵다.
– 순응성 : 사용자의 요구에 맞추어 적절히 변화한다.
– 비가시성 : 소프트웨어의 구조가 코드에 숨어있다.
– 비마모성 : 소프트웨어는 마모되거나 소멸되지 않는다.
– 비제조성 : 하드웨어처럼 제작되는 것이 아니라 논리적 절차에 의해 만들어진다.
– 비과학성 : 수학이나 과학보다는 조직,인력,시간,비용,절차 등이 중심이 된다.
■ 소프트웨어의 분류
○시스템SW는 운영체제(OS)와 펌웨어(컴파일러, 유틸리티 등)로 구성되며, 응용 SW의 실행이나 개발을 지원하지만, 응용SW에 의존적이지 않으며, 컴퓨터 시스템의 일부로 공급되는 SW
–운영체제로는 Windows, Unix, Linux, Android, iOS, Mac OS X 등이 있음
○응용SW는 운영체제 상에서 사용자에게 다양한 작업을 할 수 있도록 해 주는 SW
–오피스 SW, 컴퓨터 통신 SW, 멀티미디어 SW, 분석 SW, 커뮤니케이션 SW, 사무용 SW, 데이터베이스 SW, 게임 SW 등이 있음
Software는 하드웨어를 동작 시켜 사용자가 작업을 편리하게 수행하도록 하는 프로그램과 자료구조 등을 총칭한다.
소프트웨어는 프로그램뿐만 아니라 프로그램의 개발, 운용 및 유지보수에 관련된 모든 문서와 정보를 포함한다.
프로그램은 작업 실행 시 요구되는 기능과 성능을 제공해 주는 명령어들의 집합.
2. 시스템의 정의
시스템(system)은 각 구성요소들이 상호작용하거나 상호의존하여 복잡하게 얽힌 하나의 집합체다. 또는 이 용어는 복잡한 사회적 체계의 맥락에서 구조와 행동을 통제하는 규칙들의 집합체를 일컫기도 한다.” 시스템(system)”은 라틴어 systēma에서 결국 그리스어 systēma로부터 유래한다.
■ 시스템의 구성요소
– 입력 : 처리방법, 처리할 데이터, 조건을 시스템에 투입하는 것.
– 처리 : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것.
– 출력 : 처리된 결과를 시스템에서 산출하는 것.
– 제어 : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것.
– 피드백 : 출력된 결과가 목표에 불만족 시에 목표달성을 위해 반복처리 하는 것.
– Software Crisis : 소프트웨어 위기는 여러 가지 원인에 의해 소프트웨어 개발속도가 하드웨어 개발속도를 따라가지 못해 생기는 사용자들의 불만 문제가 발생함을 말한다.
3.소프트웨어 공학(Software Engineering)
소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문이며, 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상이 목적으로 경제적으로 신뢰도 높은 소프트웨어를 만들기 위한 방법, 도구와 절차들의 체계이다.
소프트웨어 공학은 안정적이며 효율적으로 작동하는 소프트웨어의 생산과 유지보수 활동을 체계적이고 경제적으로 수행하기 위해 계층화 기술을 사용한다.
■ 계층화 기술
– Tool : 절차와 방법을 자동 또는 반 자동으로 처리하는 기능을 제공하는 것으로, 대표적으로 CASE(자동화 기술)를 사용한다.
– Method : 소프트웨어를 구축하는 기술적인 방법을 제공하는 것.
– Process :소프트웨어 공학의 기반이 되는 것으로, 개발방법과 도구가 사용되는 순서를 의미하며, 계층화 기술들을 결합시켜 합리적으로 소프트웨어를 개발하고 유지시키는 역할을 한다.
■ 소프트웨어 공학의 기본원칙
– 현대적인 프로그래밍 기술을 계속적으로 적용한다.
– 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
– 소프트웨어 개발관련 사항 및 결과에 대한 명확한 기록을 유지 해야 한다.
■ 소프트웨어의 생산성(Productivity)을 좌우하는 요소
– 개발자의 능력
– 프로젝트의 복잡도와 성격
– 관리 기술
– 기술 수준
– 원활한 의사 전달
4. 소프트웨어 생명주기(Software Lifecycle)
소프트웨어 제품의 개념 형성에서 시작하여 운용/유지 보수에 이르기까지 변화의 전 과정. 대상이 되는 소프트웨어의 규모나 종류, 개발 방법론에 따라서 단계의 구분 방법이나 명칭이 다르다. 소프트웨어 생명 주기에는 요구 분석, 설계, 실현, 품질 보증, 도입/검수, 운용/유지 보수의 여러 단계와 경우에 따라서는 사용 정지 단계가 포함된다. 이들 단계는 중복되기도 하고 반복되기도 한다.
■ 소프트웨어 생명주기의 역할
– 프로젝트 비용산정과 개발 계획을 수립할 수 있는 기본 골격이 된다.
– 프로젝트 진행 방향을 명확하게 파악하게 한다.
– 용어 및 기술의 표준화를 가능하게 한다.
– 프로젝트 관리를 용이하게 한다
– 여러 소프트웨어 간에 상호 일관성을 유지하게 한다.
5. 소프트웨어 생명주기 모델(Software Lifecycle Model)
■ 폭포수 모델(Waterfall Model)
폭포수 모형은 소프트웨어 공학에서 가장 오래된 생명주기 모형으로 고전적 생명주기 모형로 소프트웨어 개발과정의 앞 단계가 끝나야 다음단계로 넘어갈 수 있는 순차적 모형이다.
– 각 단계가 끝난 후에는 다음 단계를 위해 결과물이 명확하게 산출되어야 한다.
– 두개 이상의 과정이 병행하여 수행되지 않는다.
– 개발순서 : 타당성검토–> 계획–>요구분석–>설계–>구현(코딩)–>테스트–>유지보수
– 장점 : 모형의 적용경험과 성공 사례가 많으며, 단계별 정의가 분명하고, 전체 공조(단계)의 이해가 용이 하다. 또, 단계별 산출물이 정확하여 개발공정의 기준을 잘 제시한다.
– 단점 : 처음부터 사용자들이 모든 요구사항들을 명확하게 제시해야 하며, 현실적으로 오류 없이 다음단계로 진행하는 것이 매우 어렵다.(개발 중 사용자 의견반영 어려움 ) 또, 개발된 프로그램을 운용할 때 검출되지 않은 오류로 인해 사용자들의 인내심이 필요.
■ 프로토타입 모델(Prototype Model)
프로토타입 모형(원형모형)은 사용자의 요구 사항을 정확히 파악하기 위해 시제품(프로토타입)을 만들어 최종 결과물을 예측 하는 모형으로 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
– 프로토타입이 곧 최종 목표 프로그램의 골격 코드가 된다.
– 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모델의 단점을 보완
– 프로토타입은 요구분석단계에서 사용하며, 개발이 승인되면 다른 모델을 채택.
– 프로토타입 모델은 소프트웨어 생명주기에서 유지보수가 없어지고, 개발단계 안에 유지보수가 이루어 지는 것으로 볼 수 있다.
– 개발 순서 : 요구수집–>빠른설계–>프로토타입–>고객평가–>시제품조정–>구현–>
– 장점 : 요구사항을 충실히 반영하여 변경이 용이하고, 의뢰자가 시제품을 볼 수 있으며 개발자와 의뢰자 에게 공동의 참조모델을 제공한다.(개발자에게는 Tracer Code가 됨)
– 단점 : 미리 제작된 소프트웨어를 사용할 경우 실제와의 차이가 혼동을 줄 수 있으며, 단기간제작으로 인하여 비효율적인 언어나 알고리즘을 채택할 수 있다.
■ 나선형모델(Spiral Model)
나선형 모형(Spiral Model)은 폭포수 모형과 프로토 타입의 모형의 장점에 위험분석 기능을 추가한 모형으로 프로토 타입을 지속적으로 발전시켜 최종 소프트웨어를 개발하면서 생길 수 있는 위험을 관리하고 최소화 하는 것을 목적으로 한다.
– 개발순서 : 나선형 모델은 업무영역(Task Region)이라는 여러 개의 작업단위로 나뉘며, 계획 및 정의–>위험분석–>공학적 개발—>고객평가
(Planning) (Risk Analysis) (Engineering) (Customer Evaluation) 의 순서로 계속적으로 이루어져 발전해 나간다.
– 계획 및 정의(Planning) : 개발 목적, 제약 조건 등을 설정한다.
– 위험 분석(Risk Analysis) : 위험 요소를 분석하고, 기능 선택의 우선순위를 지정한다.
– 공학적 개발(Engineering) : 개선된 한 단계 높은 수준의 프로토 타입을 개발한다.
– 고객 평가(Customer Evaluation) : 개발된 결과(프로토 타입)을 평가 한다.
– 장점 : 가장 현실 적인 모형으로, 대규모 프로젝트나 큰 시스템에 적합하며, 점진적으로 개발과정이 반복되므로 누락되거나 첨가된 요구사항을 다룰 수 있고, 정밀하며, 유지보수가 필요 없다. 또한 위험 분석 단계 에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로써 완성도 높은 소프트웨어를 만들 수 있다.
– 단점 : 위험성 평가에 크게 의존하기에 이를 발견 못하면 반드시 문제가 발생한다. 비교적 최신의 기법이므로 폭포수 모델이나, 프로토 타입 모델보다 널리 사용되지 않는다.
■ RAD(rapid application development ) 모델
– RAD 모델은 짧은 개발 주기 동안 소프트웨어를 개발하기 위한 순차적 프로세스 모델로 시제품화(prototyping)의 방법으로 폭포수(waterfall)형과 같은 종래의 소프트웨어 개발 방법보다 더 짧은 기간에 정보 시스템을 완성시키는 것. 시제품화란, 이용자에게 시스템의 완성 이미지를 보여 주면서 요구 분석/기본 설계 등을 추진하는 방법이다. 실제로 화면이나 장표 모델을 작성해서 이용자가 그때까지의 요구한 사항을 제공한다. RAD는 일반적으로 소수의 개발팀이 이용자를 끌어 들여서 개발 작업을 진행하는데, 그 순서는 ㉠시스템 분석자가 최종 이용자로부터 요구 사항을 듣고 시스템 규격을 결정하고 ㉡시스템 엔지니어가 시제품 계획을 작성하면 ㉢이 계획을 실제로 가동시켜서 이용자에게 평가 확인 요청을 한다. 그래서 이용자가 시제품에 만족하면 ㉠/㉢의 작업을 반복해서 시제품을 완성한다.
■ V 모델(V-model)
V 모델(V-model)은 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나로 볼 수 있다. 아래 방향으로 선형적으로 내려가면서 진행되는 폭포수 모델과 달리, 이 프로세스는 오른쪽 그림과 같이 코딩 단계에서 위쪽으로 꺾여서 알파벳 V자 모양으로 진행된다. V 모델은 개발 생명주기의 각 단계와 그에 상응하는 소프트웨어 시험 각 단계의 관계를 보여준다.
V 모델은 소프트웨어 개발의 각 단계마다 상세한 문서화를 통해 작업을 진행하는 잘 짜인 방법을 사용한다. 또한 테스트 설계와 같은 테스트 활동을 코딩 이후가 아닌 프로젝트 시작 시에 함께 시작하여, 전체적으로 많은 양의 프로젝트 비용과 시간을 감소시킨다.