NOTE2 - 제 2 부 소프트웨어 개발 실체와...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 제 2 부 소프트웨어 개발 실체와 패러다임 3장. 소프트웨어 개발의 실체 4장. 소프트웨어 시스템 개발 패러다임 3-1 3장. 소프트웨어 개발의 실체 3-2 소프트웨어 공학 정의 ■ 소프트웨어 공학은 실제 효과적으로 작동할 수 있는 우수한 소프트웨어를 최적의 비용으로 얻기 위하여 사용하는 견고한 엔지니어링 원칙 ■ 소프트웨어 공학은 경영학, 경제학, 전산학 및 시스템 공학적인 문제 해결 원리에 기초 ■ 허용하는 예산과 시간 범위 안에서 효과적으로 소프트웨어 제품을 개발하고 유지 보수하는 활동과 관련된 기술적, 관리적 원리 ■ 소프트웨어 공학의 주요 목표는 소프트웨어 제품의 품질을 향상시키고 생산성 및 사용자 만족도를 증진시키는 데 있다. 3-3 3.1 소프트웨어와 관련된 질문들 1. 소프트웨어 시스템을 개발하는 데 드는 비용 중 프로그래밍(코딩)에 드는 비용은 어느 정도 인가? a. 20% b. 30% c. 40% d. 50% 2. 중간 사이즈의 소프트웨어 시스템을 개발할 때 한 프로그래머가 일년에 만드는 실행코드(executable code)는 평균 몇 줄(line)이나 될까? a. 5,000줄 이하 b. 5,000 ~ 10,000줄 c. 10,000 ~ 15,000줄 d. 15,000줄 이상 3. 사용자에게 배달되는 소프트웨어 시스템의 실행코드 1000줄당 예상 되는 오류의 개수는? a. 4개 미만 b. 4 ~ 6 개 c. 7 ~ 9 개 d. 10개 이상 4. 사용자가 발견하는 소프트웨어 시스템의 오류는 어떤 것에 기인하 는 경우가 많은가? a. 설계의 오류 b. 프로그래밍의 오류 c. 제안서와 사용자 요구사항에 대한 잘못된 이해 d. 테스팅의 오류 5. 소프트웨어 시스템을 유지, 보수하는 데 드는 비용이 개발비용의 몇 배 정도 될까? a. 0.5 b. 1 c. 1.5 d. 2 3-4 오류의 발견 시점과 소요 비용 100 75 50 25 Base 요 구 사 항 분석 ■ 디자인 코딩 테스팅 유지보수 오류의 발견이 늦어질수록 오류를 고치는 비용이 증가한다. 3-5 소프트웨어 위기의 원인 ■ 소프트웨어 생산성이 사용자들의 서비스에 대한 요구를 따라가지 못한다. - 고객의 기대치는 점점 커지고 생산성은 증대되지 않는다. (생산성/수요 = 1.8 / 100) (단위 : 조 ) 450 400 350 300 250 200 150 100 50 0 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 3-6 소프트웨어 위기의 원인(계속) ■ 소프트웨어 품질이 향상되지 못하고 유지보수가 힘들다. - 제안서만 가지고는 사용자의 요구사항에 대한 정확한 내용을 파악할 수 없는 경우가 대부분 - 프로젝트 시작시 확실한 요구사항과 목표를 세우기가 어렵다. - 사용자가 볼 수 있는 작동하는 시스템은 공정 후반부에 가서야 얻을 수 있다. - 주요한 결점들이 후반부에 발견되어 시스템 전체에 큰 재난을 초래하는 경우가 많다. - 기존의 소프트웨어를 유지 보수하는 것이 매우 힘들며 많은 비용 소요 3-7 소프트웨어 위기의 원인(계속) ■ 소프트웨어 품질이 향상되지 못하고 유지보수가 힘들다. - 컴퓨터 하드웨어의 데이터 처리 및 저장능력이 급속도로 증가 - 소프트웨어의 유지 보수에 소요되는 비용도 증가 - 현재 시스템 개발에 있어 소프트웨어에 드는 비용은 하드웨어 비용을 능가하는 것이 대부분 - 소프트웨어의 품질 관리는 하드웨어보다 더 어렵다. 컴퓨터 시스템 소요 비용 100% 하드웨어 소프트웨어 1965 1970 1975 1980 1985 1990 1995 3-8 소프트웨어 위기의 원인(계속) ■ 관리자나 엔지니어들이 새로운 기법들에 대하여 잘 모르며 과거의 경험에 의하여 코딩에 접근하는 경우가 많다. ■ 기업에서는 장기적인 안목에서 관리자와 개발자들에 대한 교육과 훈련을 지속적으로 제공해야 한다. ■ 프트웨어의 경우 체계적인 접근 방법이 많지 않은 것도 소프트웨어의 품질 향상을 어렵게 하는 한 요인 ■ 프로젝트 개발 일정과 소요비용 예측이 매우 부정확 3-9 3.3 소프트웨어 위기의 해결책 ■ 소프트웨어 개발 실무 경험이 없는 사람들이 체계적인 소프트웨어 개발 방법의 필요성이나 중요성을 인식 ■ 소프트웨어 개발은 기술적인 문제 뿐만 아니라 관리적인 측면에서 조직적으로 문제를 극복하려는 노력을 요구 ■ 참여한 모든 사람들이 문제점에 대한 정확한 인식과 목표를 가지고 그것을 해결하기 위한 방법과 과정을 공유할 때 프로젝트는 성공적으로 완수될 수 있다. 3 - 10 3.4 소프트웨어에 대한 오해 ■ 소프트웨어는 여러 면에서 오해를 받고있다. ■ 소프트웨어와 관계가 있는 관리자, 고객, 엔지니어들이 가지고 있는 오해를 분석 3 - 11 3.4.1 관리자의 오해 ◉ 소프트웨어 개발에 관한 좋은 책들이 있고 책안에 개발 표준과 단계가 제시되어 있어 우리에게 필요한 모든 것을 제공할 것이다. ◉ 개발자들에게 필요한 최신 기계나 CASE 도구를 도입 하였으니 좋은 제품을 빠른 시일 내에 만들 수 있을 것이다 ◉ 엔지니어들이 요구분석을 하고 있으면 생산적이지 못한 일을 하고 있는 줄 안다. ◉ 공정이 지연되면 인력을 더 투입하면 해결된다. 3 - 12 3.4.2 고객의 오해 ◉ 목표에 대한 개략적인 기술만 해놓으면 충분하다. 세부적인 것은 나중에 채워 넣으면 된다. ◉ 사용자의 요구사항은 계속 변하며 소프트웨어는 유연성이 있어 쉽게 변경을 수용할 수 있다. 3 - 13 3.4.3 엔지니어의 오해 ◉ 일단 프로그램이 만들어지고 작동하면 우리의 임무는 끝난다. ◉ 시스템을 작동시켜 보기 전까지는 품질을 평가할 방법이 없다. ◉ 프로젝트의 결과는 작동하는 프로그램뿐이다. 3 - 14 4장. 소프트웨어 시스템 개발 패러다임 3 - 15 패러다임(Paradigm) ■ 바라보는 눈, 관점(view), 시각, 기본틀 ■ 바라보는 방식은 사고와 행동의 원천 ■ 소프트웨어 시스템 개발 패러다임 : 높은 품질의 소프트웨어 시스템을 체계적으로 만들기 위해 필요한 개발 방법, 개발 환경 및 관리에 대한 틀을 설정 3 - 16 소프트웨어 개발 방법론 ■ 소프트웨어 개발 방법론은 개발 방법, 개발 환경, 개발 관리 등을 포함하여 이루어져 있으며 이를 소프트웨어 공학 패러다임 이라고 한다. ■ 많이 사용되고 있는 4가지 패러다임 - 폭포수 모델 (Waterfall Model) 원형 (Prototyping) 패러다임 나선형 모델(Spiral Model) 4세대 기법 (4th Generation Techniques) ■ 패러다임의 선정은 프로젝트의 성격, 소요되는 기간, 방법과 도구 등에 의해 이루어진다. 3 - 17 4.1 폭포수 모델(Waterfall Model) ■ 고전적 라이프 사이클 패러다임이라고도 부름 ■ 다른 공학에서도 많이 사용되는 전형적인 기법 ■ 요구사항 분석, 설계, 구현(프로그래밍), 시험 및 유지보수의 순서로 시스템의 개발이 이어짐 ■ 소프트웨어 개발을 단계적으로 정의한 체계적이며 순차적인 접근 방법을 사용하고 있다. ■ 가장 오래되고 널리 사용되는 패러다임 ■ 개념 정립에서 구현까지 하향식 접근 방법을 사용하여 높은 추상화 단계에서 낮은 추상화 단계로 옮겨가는 모델 ■ 각 단계가 끝날 때마다 과정의 끝을 알리고 그 다음 단계로 진행 3 - 18 폭포수 모델의 실제 적용 ■ 실제로 소프트웨어 시스템을 개발하다 보면 개발 단계의 겹쳐지는 부분이 나타난다. ■ 각 단계의 진행 과정에서 문제가 발생되어 그 이전 단계로 피드백 되는 경우가 나타난다. ■ 앞의 폭포수 모델에 피드백이 요구되어 순환되는 모습을 나타내고 있다. 각 개발 단계는 약간의 피드백이 이루어진 후 문서나 결과물이 동결되고, 그 다음 단계로 넘어가는 것이 일반적이다. 요구사항 분석 요구사항 분석 설계 설계 구현 시험 시험 유지보수 유지보수 < 그림 4.1 폭포수 모델 > 3 - 19 폭포수 모델의 단계 1. 요구사항 분석 : - 사용자 요구사항을 정의하기 위하여 시스템의 요구사항 수집 - 시스템의 목표를 정하는 과정으로 그 결과물은 요구사항 명세서 2. 설계 : - 설계는 요구사항 분석과정에서 모아진 요구사항을 설계도면에 옮기는 것 - 설계 과정은 물리적(physical) 실현의 첫 단계 - 설계 단계의 결과물은 설계 명세서 3. 구현 : - 시스템의 기능이 수행가능한 모습으로 나타남 - 구현은 프로그래밍 또는 코딩이라고 부름 - 프로그래밍의 결과는 컴퓨터 프로그램 3 - 20 폭포수 모델의 단계(계속) 4. 시험 : - 품질보증 활동의 중요한 일부분 - 사용자 요구사항, 설계, 구현의 전 과정에 대한 최종 점검을 포함 - 시험은 제품의 오류를 발견하고 수정하는 과정 - 최소한의 시간과 비용을 투자해서 최대한의 확률로 오류를 찾아낼 수 있도록 이루어져야 한다. 5. 유지보수: - 여러 변경 사항에 대해 적응하는 활동이며 변화에 대비하는 과정 - 수정 유지보수, 적응 유지보수, 기능추가 유지보수, 관리 유지 보수 3 - 21 폭포수 모델의 장단점 ■ 프로젝트 진행과정을 세분화하여 관리 용이(장점) ■ 대부분 순환이 발생하기 때문에 순차적인 흐름을 따라가는 데 어려움이 있다. ■ 또한 고객이 원하는 요구사항을 초기에 구체적으로 기술하기 어렵다. ■ 작동하는 시스템이 프로젝트의 후반부에 가서야 얻어짐으로써 중요한 문제점이 뒤에 발견된다는 단점 ■ 다음의 패러다임들은 폭포수 모델의 변형으로, 단계를 통합하거나 또는 새로운 단계를 추가하여 단계의 순환적 적용을 포함함으로써 폭포수 모델의 문제점을 극복하려 하고 있다. 3 - 22 4.2 원형(Prototyping) 패러다임 ■ 시스템 개발시 고객이 목표를 정의하였으나 요구되는 속성을 어떻게 만족시킬 수 있을지 모르는 경우가 자주 있다. ■ 사용자 자신이 원하는 것이 무엇인지 구체적으로 모르거나 그들의 요구가 어떻게 변경될지 잘 알지 못하는 때도 있다. ■ 또한 엔지니어들이 고객의 요구를 불완전하게 이해하고 있는 경우도 흔히 있을 수 있다. ■ 이런 경우를 대비해 간단한 시제품 (prototype)을 만들어 보여주는 것이 원형 패러다임 ■ 원형 패러다임은 폭포수 모델의 단점을 보완하기 위해 점진적으로 시스템을 개발하여 나가는 접근 방법 3 - 23 원형 패러다임의 활용 ■ 사용자로부터 피드백을 시스템 개발 초기에 얻어낼 수 있다. ■ 시제품을 통해 이전에 밝혀지지 않았던 사용자의 요구사항을 구체적 으로 규명 ■ 특히 프로젝트 초기에 요구사항이 확실치 않거나 모든 요구사항을 미리 뽑아낼 수 없는 불안정한 상황일 때 프로젝트를 쉽게 제어 관리 ■ 더욱 빨리 필요한 요구사항을 뽑아내고 시스템에 반영시킬수록 더 안정되고 좋은 품질의 시스템을 생산 ■ 시스템에 대한 이해와 품질 향상을 위하여 사용 ■ 시제품은 사용자와 시스템간의 인터페이스에 초점을 맞추어 개발 ■ 피드백을 얻어낸 후 시제품을 버리는 경우도 있고, 원하는 시스템 의 기능 중 중요한 부분만 구현하여 피드백을 얻은 후 계속 발전시켜 완제품을 만들어 낼 수도 있다. 3 - 24 시제품 개발을 통하여 얻어지는 장점 ■ 시스템의 기능이 사용자에게 보여짐으로써 개발자와 사용자의 오해가 규명된다. ■ 생각지 못하였던 기능과 서비스가 발견된다. ■ 사용하기 어렵거나 혼돈을 일으키는 기능들이 규명되어 명료화된다. ■ 분석가나 개발자는 불완전하거나 일치하지 않는 요구사항을 시제품을 통하여 발견할 수 있다. ■ 완전하지 못하지만 작동하는 시스템을 만들어 가능성과 유용성을 관리자에게 보여줄 수 있다. ■ 시제품은 고품질 시스템의 요구사항을 명세화할 수 있는 기초를 제공한다. 3 - 25 원형 패러다임의 진행과정 ■ 개발팀은 고객 및 사용자와의 대화를 통하여 전반적인 기능을 파악 하고, 우선 간단히 설계를 한 후 시제품을 만들어 사용자에게 보여주게 된다. ■ 사용자는 시제품을 보고 만들어질 완제품의 모습 파악 ■ 사용자는 시제품에 대하여 평가하고 그 결과는 시제품을 향상 시키거나 완제품을 만들어가는 데 반영 시작 끝 요구사항 분석 완제품 생산 시제품 설계 시제품 정제 시제품 개발 고객의 시제품 평가 < 그림 4.2 원형 패러다임 > 3 - 26 원형 패러다임의 각 단계 1. 요구사항 분석 단계 - 이 과정은 폭포수 모델의 요구사항 분석단계와 유사 - 고객으로부터 받은 일부의 요구 사항만 정의하고, 완전치 않은 요구사항에 대하여 윤곽을 잡아 놓는다. - 추가적인 정의가 필요한 부분은 시제품이 개발된 후 계속 정제해 나간다. 2. 시제품 설계 단계 - 원형에 대한 설계를 한다. - 사용자들이 볼 수 있는 면에 초점을 맞춤 - 시제품 개발의 목표가 확립되고 시제품에 포함될 시스템의 기능 들이 골라진다. - 시제품에 포함되는 것과 시제품에서 배제되어야 하는 것이 무엇 인지 규명하는 것은 중요 3 - 27 원형 패러다임의 각 단계(계속) 3. 시제품 개발 단계 - 일반적으로 성능, 다른 시스템과의 인터페이스 등에 대한 것은 판단하기 어려워 중요하게 다루어지지 않는다. - 오류를 관리하고 다루는 면은 무시되거나 기초 수준 정도로 구현 - 시제품의 신뢰도와 프로그램 품질 수준은 떨어진다. - 이 단계의 목표는 '어떻게 하면 시제품을 빨리 만들 수 있겠는가' 이다. 4. 고객의 시제품 평가 단계 - 원형 패러다임의 가장 중요한 단계라 할 수 있다. - 시제품은 고객에 의해 평가되고, 개발될 소프트웨어의 요구 사항을 구체적으로 정제하기 위해 사용 - 이를 통해 요구사항의 오류을 발견하고 규명할 수 있게 되며, 추가되어야 하는 요구사항을 찾아 낼 수 있다. 3 - 28 원형 패러다임의 각 단계(계속) 5. 시제품 정제 단계 - 사용자가 원하는 것을 만족시키기 위해 시제품에 대한 조율이 필요 - 시제품이 어떻게 고쳐져야 하는지 결정하고 다음 단계의 시제품이 빠르게 만들어 질 수 있도록 한다. - 이 시제품은 다시 고객에게 평가되는 순환을 하게 되며 고객이 요구사항에 대하여 만족할 때까지 계속 6. 완제품 생산 단계 - 이 단계의 목표는 원하는 시스템을 개발하는 것 - 만약 원형을 버리고 새 시스템을 개발해야 한다면, 이 단계는 완전한 폭포수 모델의 생명 주기를 따르거나 4세대 기법(4GT)의 사용이 가능 3 - 29 시제품의 다른 용도들 ■ 시제품은 실제 제품이 만들어져 사용자에게 배달되기 전, 사용자를 교육 훈련시키는 데 사용 ■ 이는 원형 개발의 중요한 장점 중에 하나로 시스템이 개발되어 사용자가 실제로 사용하기까지의 시간을 줄여 줄 수 있다. ■ 시제품은 시스템 테스트를 하며 연속적으로 사용될 수 있다. 이는 시제품과 최종단계의 제품에 같은 테스트가 적용될 수 있음을 의미한다. ■ 만 이 두 시스템이 같은 결과를 보여준다면 최종단계의 제품이 제대로 만들어 졌거나 테스트 케이스 (test case)가 잘못되어 오류를 발견하지 못하는 경우이다. ■ 만약 결과가 다르게 나오면 최종 시스템에 결함이 있음을 의미 한다. 시제품은 테스트 케이스의 검증을 미리하여 시스템 테스트에 들어가는 노력을 줄여줄 수 있다. 3 - 30 원형 패러다임의 한계점 ■ 만들어질 완제품이 어떨 것이라는 것에 대한 오해를 불러일으킬 수 있다. ■ 시제품에서 완제품으로 옮겨가는 데 많은 변화가 예상될 수 있다. ■ 시스템의 극한 상황 등에 대한 성능 평가가 어렵다. ■ 다른 시스템들과의 교류 및 통합 등에 대한 결과가 쉽게 얻어지지 않는다는 것도 그 한계점이다. ■ 원형 패러다임은 이러한 문제점들에도 불구하고 쉽고 빠르게 시제품을 만들 수 있는 도구들의 개발에 힘입어 많은 응용 분야에서 효과적으로 활용되고 있다. 3 - 31 4.3 나선형(Spiral) 패러다임 ■ 폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위험 분석 (risk analysis)을 추가하여 만든 것 ■ 이러한 접근 방법을 선택할 것인가의 문제는 전적으로 위험의 수위에 달려있다. ■ 시스템을 개발하면서 생기는 위험을 관리하고 최소화하려는 것이 이 패러다임의 주 목적 ■ 나선을 돌면서 점진적으로 완벽한 시스템 개발 ■ 각 나선은 4단계로 나뉘어져 있다. - 계획 및 정의(planning and definition) 단계 위험 분석(risk analysis) 단계 개발(engineering) 단계 고객 평가(customer evaluation) 단계 3 - 32 나선형 패러다임 계획및 정의 위험 분석 초기 위험 분석 요구사항 분석과 계획 수립 다음 단계 위험 분석 고객의 평가 반영 계속 추진할 것인지에 대한 결정 첫 번째 시제품 고객 평가 다음 단계 시제품 고객 평가 개발 < 그림 4.3 나선형 모델> 3 - 33 나선형 모델의 각 단계 1. 계획 및 정의 단계 - 요구사항을 모으고 프로젝트 계획을 수립 - 나선형 싸이클의 시작은 성능, 기능을 비롯한 시스템의 목표를 규명하는 것에서 시작 - 시스템의 목표와 제약조건에 대한 차선책이 평가, 고려될 수 있다. - 이러한 평가과정은 프로젝트 위험의 원인을 규명하는 데 효과적으로 사용 2. 위험 분석 단계 - 여기서는 초기 요구사항에 근거하여 위험이 규명된다. - 정보를 찾아내는 활동을 통하여 불확실성과 위험을 줄여나갈 수 있다. - 프로젝트를 '계속 진행할 것인지(Go)', 또는 '중단할 것인지(NoGo)'를 결정하는 작업이 이루어진다. 3 - 34 나선형 모델의 각 단계(계속) 3. 개발 단계 - 이 과정은 위험에 대한 평가가 있은 다음 이루어진다. - 이 단계에서는 '어떠한 패러다임이 적용되여 시스템 개발이 이루어 질 것인가'하는 개발 모델을 결정한다. - 이 단계는 시제품을 개발하거나 최종 제품을 만드는 과정이라 볼 수 있다. 4. 고객 평가 단계 - 이는 앞의 결과를 사용자가 평가하는 과정 - 고객에 의해 시스템에 대한 평가가 이루어지고, 고객은 시스템의 수정을 요구하기도 한다. - 엔지니어링의 결과는 시뮬레이션 모델, 시제품, 또는 실제 시스템 일 수 있다. 고객의 평가에 의하여 다음 결과물 계획 3 - 35 나선형 패러다임의 장점과 한계점 ■ 나선형 모델은 비용이 많이 들고 시간이 오래 걸리는 큰 시스템을 구축해 나가는 데 가장 현실적인 접근 방법 예: 초고속 정보통신망 개발, 큰 국책사업, 대형사업 ■ 성과를 보면서 조금씩 투자하여 위험 부담을 줄일 수 있는 이상적 방법이 나선형 모델이다. ■ 모델 자체가 앞의 두 모델보다 더 복잡하여 프로젝트 관리 자체를 어렵게 만들 가능성이 많다. ■ 많은 고객을 상대로 하는 상업용 제품에 적용하기 힘들다. ■ 상대적으로 새로운 접근 방법이며 많이 사용되지 않아 충분한 검증을 거치지 못하였다는 단점을 가지고 있다. ■ 객체지향 소프트웨어 개발 방법론은 원형 패러다임과 나선형 패러다임 등 점진적인 시스템 개발을 가능케하는 우수한 기법 3 - 36 4.4 4세대 기법 (4th Generation Techniques) ■ CASE를 비롯한 자동화 도구들을 이용하여 요구사항 명세서로부터 실행코드를 자동으로 생성할 수 있게 하여주는 방법 ■ 이 도구들은 사람이 사용하는 고급 언어 수준에서 요구사항이 명시되면 실행될 수 있는 제품으로의 전환을 가능하게 한다. ■ 그러나 현재 4GT 도구들은 고급언어를 실행코드로 바꾸어 줄 만큼 정교하지 못하다. ■ 이러한 고급 언어의 모호성을 해결하기 위해 형식 규격 언어로 표현하려는 노력이 진행 ■ 형식 규격 언어를 사용하면 명세서를 해석하고 이해하는 데 정확성을 기할 수 있으며 개발과정의 자동화를 이룰 수 있다는 큰 장점 예: EER 모델로 만들어진 명세서에서 데이터베이스의 코드가 생성 3 - 37 4세대 기법의 한계점 ■ 아직 성능면에서 뛰어나지 못하여 불필요한 많은 양의 코드를 생성하고 유지보수에 어려운 점이 남아있다. ■ 현재 4세대 기법은 많이 활용되고 있지 못한 상황이다. ■ 많은 CASE 도구들이 코드생성을 지원해 주고 있으므로 생산성에 대한 요구와 소프트웨어 위기를 해결하기 위해 앞으로 여러 응용 분야에 폭넓게 사용될 것이다. 3 - 38 4.5 소프트웨어 제작 방법의 공통점 ■ 시스템 제작의 공통점은 다음의 3가지로 요약되어 설명될 수 있다. - 시스템의 정의 (definition) 단계, - 시스템의 개발 (development) 단계, - 시스템의 유지보수 (maintenance) 단계 ■ 소프트웨어 개발에서도 앞의 어느 패러다임을 선택하든 이 세 가지는 중요한 의미를 갖는다. 3 - 39 ...
View Full Document

This note was uploaded on 11/15/2011 for the course ECON 101 taught by Professor David during the Spring '11 term at Kwansei Gakuin University.

Ask a homework question - tutors are online