사용자:Teguri/소프트웨어 개발 프로세스

위키백과, 우리 모두의 백과사전.

소프트웨어 개발 프로세스는 소프트웨어 제품 개발 시에 적용해야하는 구조이다. 같은 말로 소프트웨어 생명 주기(software life cycle)와 소프트웨어 프로세스(software process)를 들 수 있다. 그러한 프로세스를 위해 몇 가지 소프트웨어 프로세스 모델이 존재하며, 각각의 모델은 프로세스 진행을 위해 필요한 작업이나 활동에 대한 접근방법을 기술하고 있다.

프로세스와 메타 프로세스(meta-process)[편집]

소프트웨어 개발 조직의 규모가 커짐에 따라, 프로세스 방법론들이 만들어졌다. 프로세스 방법론 중 많은 것들이 방위산업에서 나왔다. 이는 미 정부가 계약 수주의 요건으로 평가 기반의 프로세스 모델을 요구하기 때문이다. 참고로 소프트웨어 생명 주기를 선택하고, 적용하고, 감시하는 방법을 기술한 국제 표준은 ISO 12207이다.

Capability Maturity Model (CMM)은 가장 선두에 있는 모델 중 하나이다. CMM은 독립적인 평가를 통해 소프트웨어 개발 조직이 얼마나 정의된 프로세스를 잘 지키는 지에 대한 등급을 매기는 모델이며, 이는 프로세스 자체의 품질이나 결과물인 소프트웨어에 대한 평가에 우선하여 이루어진다. CMM은 서서히 CMMI으로 대체되었다. ISO 9000은 문서와 함께 프로세스를 공식적으로 조직하는 표준을 기술한다.

Software Process Improvement Capability Determination (SPICE, ISO 15504)는 "소프트웨어 개발 프로세스의 평가를 위한 프레임워크"이다. 이 표준은 프로세스 간의 비교를 위한 분명한 모델을 세우는 것을 목적으로 한다. SPICE는 CMM이나 CMMI 만큼 널리 사용되고 있다. SPICE를 이용해 프로세스를 관리하고, 제어하고, 안내하며, 소프트웨어 개발 과정을 모니터링 할 수 있는 모델을 세울 수 있다. 세워진 모델을 이용하여 실제로 소프트웨어 개발 조직이나 개발 팀이 소프트웨어 개발을 위해 수행하여야 하는 활동을 측정할 수 있다. 측정된 정보를 활용하여 프로젝트의 약점이나 개선사항을 분석하고, 반대로 강점을 찾아 기존의 실행방식에 통합하여 계속해서 발전시킬 수 있다.

식스 시그마(Six Sigma)는 회사의 운영 성과를 측정하고 이를 더욱 향상시키기 위해, 데이터와 통계분석을 이용하여 프로세스 변화을 관리하는 방법이다. 이는 제조와 서비스 관련한 프로세스 상의 결함을 식별하고 감소시키는 활동을 통해 적용된다. 허용되는 결함은 전체 중에서 최대 100만분의 3 또는 4를 넘지 않아야 한다. 그러나 식스 시그마는 제조 관점이 강하며, 소프트웨어 개발과의 관련성을 위해서는 추가적인 연구가 필요하다.

소프트웨어 개발 프로세스 개요[편집]

도메인 분석[편집]

완전히 새로운 소프트웨어 응용을 개발하던, 기존의 응용을 수정하거나 추가 보완하던지에 상관없이, 대개 새로운 소프트웨어 개발의 첫번째 단계는 "도메인 분석"이라고 알려진 작업을 수행하는 것이다. 개발자나 분석가들은 일반적으로 새로운 소프트웨어가 해결하고자 하는 응용 분야에 대해 충분한 지식을 가지기 어렵기 때문에, 가장 처음으로 해야할 일은 개발될 소프트웨어의 해당 응용 분야, 소위 도메인에 대한 조사를 수행하는 것이 된다. 따라서 해당 응용 분야에 대한 기존 지식이 많으면 많을수록, 도메인 분석에 소요되는 시간은 줄어들 것이다. 이 일의 또다른 목적은 요구사항 분석가가 이후에 실제로 응용분야의 전문가들과의 대화를 통해 요구사항을 분석하고 수집함에 있어, 해당응용 분야의 익숙한 용어들을 사용하게 하여, 대화에 있어 좀더 깊은 이해가 가능하도록 만드는 것이다. 서로 사용하는 용어가 다른 경우에 응용 분야의 전문가들은 그 대화를 진지하게 임하지 않을 수 있다. 그런 이유로, 이 단계는 요구사항을 수집하고 분석하는데 매우 중요한 준비 단계이다. 다음 인용은 도메인 분석을 소흘히한 요구사항 분석가가 전문가와 대화시에 발생할 수 있는 문제 상황을 잘 묘사하고 있다. "저는 선생님이 제가 말했다고 생각하시는 내용을 잘 이해하고 있다고 믿는 것을 알고 있습니다만, 그럼에도 저는 선생님이 들었다고 생각하시는 것이 제가 의미한 바가 정확히 맞는지 의심스럽습니다."[1]

소프트웨어 구성요소 분석[편집]

소프트웨어 제품을 만드는데 있어 가장 중요한 작업은 요구사항을 뽑아내는 것이다. 대개 고객들은 그들이 원하는 것을 알지만, 원하는 것을 만족시키기 위해 소프트웨어가 해주어야 하는 일에 대해서는 모른다. 반면에 경험 있는 전문 소프트웨어 개발자조차도 불완전하고, 모호하며, 모순적인 요구사항 데이터를 만들어 내는 경우가 많다. 현재 개발 중인 버전을 고객에게 자주 보여 줌으로써, 부정확한 요구사항으로 인한 위험을 줄일 수 있다.

소프트웨어 명세[편집]

소프트웨어 명세는 작성될 소프트웨어에 대해 가능한 엄격한 방법을 통해 정확히 기술하는 작업니다. 안정이 중시되는(safety-critical) 소프트웨어 시스템의 경우에는 소프트웨어 개발 전에 명세 작업이 주의 깊게 이루어지긴 하지만, 실제적으로 가장 성공적인 명세는 기존에 이미 만들어진 응용 소프트웨어를 이해하고 이를 조정하는 과정에서 작성된 것이다. 명세는 안정적으로 유지되어야 하는 외부 인터페이스의 경우에 가장 중요하다.

소프트웨어 아키텍처[편집]

소프트웨어 시스템의 아키텍처는 해당 시스템의 추상화된 표현이라 말할 수 있다. 아키텍처를 통해 소프트웨어 시스템이 현재의 제품 요구사항을 만족시킬 수 있는지 뿐 아니라, 미래에 있을 수 있는 요구사항을 해결할 수 있는지도 판단할 수 있다. 또한 아키텍처 단계는 해당 소프트웨어 시스템과 다른 소프트웨어 제품들 간의 인터페이스를 설명하며, 기반이 되는 하드웨어나 호스트 운영체제를 설명한다.

구현(또는 코딩)[편집]

코딩을 통한 구현이 소프트웨어 개발 프로세스 중 가장 눈이 보이는 단계이기는 하지만, 꼭 가장 많은 부분을 차지하는 것은 아니다.

소프트웨어 테스팅[편집]

구현된 소프트웨어가 고객 요구사항과 명세에 적합한지, 유닛, 모듈, 컴포넌트 단위에서 기대되는 정상 결과를 보여주는지, 기반 하드웨어/OS/환경에서의 통합 시 문제가 없는지, 소프트웨어 운용 상의 문제는 없는지를 시험한다.

소프트웨어 문서화[편집]

매우 중요하지만, 흔히 지나치는 단계 중의 하나가 문서화이다. 소프트웨어 생명 주기 각 단계 별로 다음 단계의 작업을 위해 결과물에 대한 문서화가 필요하며, 문서화를 통해 조기에 문제점과 버그를 발견하고, 향후 유지 보수 시에 생산성을 높일 수 있다.

소프트웨어 교육과 지원[편집]

많은 수의 소프트웨어 프로젝트가 실제 프로젝트의 결과물을 사용하는 최종 사용자를 생각하지 않고, 개발과정에만 집중하는 것으로 인해 실패하고 있다. 흔히 사람들은 변화에 저항하고 친숙하지 않은 영역에 들어서는 것을 피하려고 한다. 그러한 이유로 소프트웨어를 배포하는데 있어 가장 열성적인 사용자들에게 흥미와 확신을 주고, 중립적인 사용자들을 지원 세력으로 만들어, 결과적으로 전체 사용자들이 새로운 소프트웨어를 받아들이게 하는 사용자 교육과 지원이 매우 중요하다. 또한 사용자 교육을 통해 사용자들의 다양한 질문과 피드백을 받아 다음 버전 소프트웨어 개발에 반영할 수도 있다.

소프트웨어 유지보수[편집]

소프트웨어 배포 후에 이를 유지보수하고 기능을 향상하는 작업을 하다보면, 새로운 문제와 사용자 요구사항이 계속해서 생겨나서, 처음 소프트웨어를 개발하는데 투여된 시간보다 더 많은 시간을 유지보수에 써야하는 경우가 많다. 소프트웨어 진흥원의 조사에 따르면 우리나라의 패키지 소프트웨어에 대한 유지보수 서비스 시장 금액은 전체 패키지 소프트웨어 시장의 21%에 달하나 이는 미국의 51%에 비하면 절반에 불과하다고 밝혔다.소프트웨어 진흥원, <패키지 SW 유지보수 서비스 실태 조사>[출처 필요], 그러나 이 통계는 다소 오해의 여지가 있다. 유지 보수 작업중 일부만이 기존 코드의 버그를 고치는 작업이고, 대부분은 새로운 기능 요구사항을 만족시키기 위한 확장에 투여되여, 이는 사실상 새로운 소프트웨어를 개발하는 것이기 때문이다.

프로세스 모델[편집]

수십년 동안 소프트웨어 전문가들은 소프트웨어 개발 시 사용 가능한 반복가능하고 예측가능한 프로세스 또는 방법론을 찾아 생산성과 품질을 향상시키는 데 노력을 기울여 왔다. 어떤 진영은 무질서하게 보이는 소프트웨어 개발 작업을 체계화하고 형식화하기 위해 시도했다. 그리고 다른 진영에서는 프로젝트 관리 기법을 소프트웨어 구현에 적용하고자 했다. 프로젝트 관리 없이 소프트웨어 프로젝트를 진행하면 납품 기한을 넘기거나 정해진 예산을 초과 사용하는 안좋은 결과가 나타날 수가 있다. 기능, 비용, 납품 스케줄 등에서 기대를 충족시키지 못하는 대다수의 소프트웨어 프로젝트들은 대개 효과적인 프로잭트 관리가 수행되지 않은 것이다.

폭포수(Waterfall) 프로세스[편집]

가장 잘 알려지고 가장 오래된 소프트웨어 프로세스는 폭포수 모델이다. 이 모델에서 개발자들은 (대략적으로) 다음 단계를 따라야 한다.

  • 요구사항을 기술한다.
  • 요구사항을 분석한다.
  • 해결을 위한 접근 방법을 설계한다.
  • 해결을 위한 소프트웨어 프레임워크를 설계한다.
  • 코드를 개발한다.
  • 코드를 테스트(대개 단위 테스트)하고 시스템 테스트를 수행한다.
  • 완료된 소프트웨어를 배포하고
  • 배포 후 유지보수를 진행한다.

각 단계가 완료된 이후, 프로세스 상의 다음 단계를 진행한다. 이는 마치 건설인들이 집을 지을때 기본 골격이 세워진 이후에는 집의 기초를 재설계하지 않는 것과 같다.

There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact this is where the domain of requirements management comes in which includes change control.

This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management." Studies of the failure rate of the DOD-STD-2167 specification, which enforced waterfall, have shown that the more closely a project follows its process, specifically in up-front requirements gathering, the more likely the project is to release features that are not used in their current form [출처 필요].

Often the supposed stages are part of joint review between customer and supplier, the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills.

점증적인(Iterative) 프로세스[편집]

점증적 개발 [1]은 prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.

Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software [출처 필요], but have the drawback from a business perspective that they do not provide long-term planning capability [출처 필요]. In essence, the Agile approach claims it will provide the most bang for the buck, but won't say exactly when that bang will be or how big a buck will ultimately be required.

However, polls show gains, sometimes significant. For example, a survey, published in August 2006 by Version One and Agile Alliance and based on polling more than 700 companies shows the following benefits of Agile approach (http://www.agilejournal.com/articles/from-the-editor/agile-survey-results%3a-solid-experience-and-real-results.html). The survey was repeated in August 2007 with about 1,700 respondents (http://www.agilejournal.com/articles/from-the-editor/agile-survey-results%3a-widespread-adoption,-emphasis-on-productivity-and-quality.html). Here are some results:

1. Accelerated time to market. 

  a.	2006: 10% or higher improvements reported by 86% of respondents  
  b.	2007: 10% or higher improvements reported by 90% of respondents  
  c.	2006: 25% or higher improvements reported by 60% of respondents
  d.	2007: 25% or higher improvements reported by 54% of respondents

2. Increased productivity. 

  a.	2006: 10% or higher improvements reported by 87% of respondents  
  b.	2007: 10% or higher improvements reported by 83% of respondents  
  c.	2006: 25% or higher improvements reported by 55% of respondents
  d.	2007: 25% or higher improvements reported by 55% of respondents

3. Reduced software defects. 

  a.	2006: 10% or higher improvements reported by 86% of respondents  
  b.	2007: 10% or higher improvements reported by 85% of respondents  
  c.	2006: 25% or higher improvements reported by 55% of respondents
  d.	2007: 25% or higher improvements reported by 54% of respondents

4. Reduced cost. 

  a.	2006: 10% or higher improvements reported by 63% of respondents  
  b.	2007: 10% or higher improvements reported by 28% of respondents  
  c.	2006: 25% or higher improvements reported by 26% of respondents
  d.	2007: 25% or higher improvements reported by 28% of respondents

Stability of results on a broader set of respondents suggests that we see the actual trend.

Other interesting improvements reported, among them: • Enhanced ability to manage changing priorities • Alignment between IT and business goals • Improved team moral • Reduced project risk

There is also an interesting chart at http://versionone.com/Resources/AgileBenefits.asp that shows Agile development value proposition in comparison to traditional development.

Extreme Programming, XP, is the best-known iterative process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.

While Iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.

Critics of iterative development approaches point out that these processes place what may be an unreasonable expectation upon the recipient of the software: that they must possess the skills and experience of a seasoned software developer. The approach can also be very expensive if iterations are not small enough to mitigate risk; akin to... "If you don't know what kind of house you want, let me build you one and see if you like it. If you don't, we'll tear it all down and start over." By analogy the critic argues that up-front design is as necessary for software development as it is for architecture. The problem with this criticism is that the whole point of iterative programming is that you don't have to build the whole house before you get feedback from the recipient. Indeed, in a sense conventional programming places more of this burden on the recipient, as the requirements and planning phases take place entirely before the development begins, and testing only occurs after development is officially over.

In fact, a relatively quiet turn around in the Agile community has occurred on the notion of "evolving" the software without the requirements locked down. In the old world this was called requirements creep and never made commercial sense. The Agile community has similarly been "burnt" because, in the end, when the customer asks for something that breaks the architecture, and won't pay for the re-work, the project terminates in an Agile manner.

These approaches have been developed along with web based technologies. As such, they are actually more akin to maintenance life cycles given that most of the architecture and capability of the solutions is embodied within the technology selected as the back bone of the application.

Refactoring is claimed, by the Agile community, as their alternative to cogitating and documenting a design. No equivalent claim is made of re-engineering - which is an artifact of the wrong technology being chosen, therefore the wrong architecture. Both are relatively costly. Claims that 10%-15% must be added to an iteration to account for refactoring of old code exist. However, there is no detail as to whether this value accounts for the re-testing or regression testing that must happen where old code is touched. Of course, throwing away the architecture is more costly again. In fact, a survey of the "designless" approach paints a picture of the cost incurred where this class of approach is used (Software Development at Microsoft Observed). Note the heavy emphasis here on constant reverse engineering by programming staff rather than managing a central design.

Test Driven Development (TDD) is a useful output of the Agile camp but raises a conundrum. TDD requires that a unit test be written for a class before the class is written. Therefore, the class firstly has to be "discovered" and secondly defined in sufficient detail to allow the write-test-once-and-code-until-class-passes model that TDD actually uses. This is actually counter to Agile approaches, particularly (so-called) Agile Modeling, where developers are still encouraged to code early, with light design. Obviously to get the claimed benefits of TDD a full design down to class and responsibilities (captured using, for example, Design By Contract) is necessary. This counts towards iterative development, with a design locked down, but not iterative design - as heavy refactoring and re-engineering negate the usefulness of TDD.

Formal methods[편집]

Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behavior by designing a system of finite state machines.

Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine).

Formal methods are most likely to be applied in avionics software, particularly where the software is safety critical. Software safety assurance standards, such as DO 178B demand formal methods at the highest level of categorization (Level A).

Formalization of software development is creeping in, in other places, with the application of OCL (and specializations such as JML) and especially with MDA allowing execution of designs, if not specifications.

Another emerging trend in software development is to write a specification in some form of logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, is an example. There is also work on mapping some version of English (or another natural language) automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems that support bidirectional English-logic mapping and direct execution of the logic is that they can be made to explain their results, in English, at the business or scientific level.

같이 보기[편집]

몇가지 소프트웨어 개발 방법의 예:

관련 주제:

참고문헌[편집]

  1. ↑ Appears in Roger S. Pressman, Software Engineering (A practitioner's approach), 5th edition, 2000, Mc Graw-Hill Education, ISBN 978-0071181822; 그러나 이 문장은 다른 책들에서도 그 인용을 찾을 수 있다. (Richard Nixon, Robert McCloskey, Alan Greenspan). 아마도 이 문장은 수십년 전 익명의 학계 농담에서 그 기원을 찾을 수 있을 것이다.

바깥 고리[편집]

원본 주소 "https://ko.wikipedia.org/w/index.php?title=사용자:Teguri/소프트웨어_개발_프로세스&oldid=21284815"