4 Software-Development Fundamentals #1166
Description
4장 소프트웨어 개발 기본
소프트웨어에서도 성공으로 가는 길은 기본을 충실히 하는 것이다.
뛰어난 인재가 있거나 일정위주 개발법에 능통하다 할지라도,
기본을 중심으로 노력하지 않으면 일정 달성에 실패할 심각한 위험에 처하게 된다.
소프트웨어 공학 기본을 권하는 이유는 '옳기' 때문에 또는 품질을 강조하기 때문이다.
'옳기' 때문이 아니라도 비용과 출시 기간을 줄일 수 있으므로 사용해야 한다.
10개 회사에서 최고 프로젝트를 검토한 결과, 발 에셀은 다음과 같은 결론을 내렸다.
"최고 프로젝트는 기본을 바탕으로 최고가 되었다는 사실은 주목할 만한 발견이다.
우리 모두가 우수한 소프트웨어를 개발하기 위한 기본을 알고는 있다.
그러나 이 기본을 제대로 적용하지 않아서 프로젝트 대부분은 결국 문제를 일으킨다.(Hetzel 1993)."
4.1 관리 기본
소프트웨어 공학 연구소(SEI)는 프로젝트 관리 규율을 세우지 않은 상태에서 소프트웨어 공학 규율을 세우려는 회사는 결국 실패함을 여러 차례 발견했다(Burlton 1992).
예측과 일정 수립
성공하는 프로젝트의 일정 수립 과정 세 단계
- 프로젝트 크기 예측
- 그 크기의 제품을 만드는 데 드는 노력을 예측
- 일정 예측
계획 수립
필립은 자신의 고전 Managing Programming Project에서 형편없는 계획 수립이 문제의 원인으로 가장 자주 떠오른다고 지적했다(Metzger 1981).
빌 에셀은 성공한 프로젝트를 검토한 결과, 세부업무와 일정을 정하기 위한 치밀한 사전 계획이 이런 프로젝트의 특징임을 발견했다(Hetzel 1993).
- 예측과 일정 수립
- 프로젝트 팀 인원 수, 필요한 기술 능력, 인력 투입 시점, 실제 참여할 개발자 결정
- 팀 조직 결정
- 사용할 생명주기 모델 선택
- 위험 관리
- 제품 기능 집합 통제 전략 결정, 제품 일부에 대한 구매 또는 구현 전략 결정
감독
빌 에셀은 프로젝트 현황에 대한 정확한 측정과 감독이 성공한 프로젝트에서 공통적으로 나타남을 발견했다.
정확한 현황 측정은 우수한 계획수립을 통해 가능했으며, 이를 통한 프로젝트 관리가 결정적인 성공 요인이었다(Hetzel 1993).
Figure 4-1. Progress visibility for different kinds of projects. Efficient development provides much better visibility than typical development.
케이퍼스 존스는 "소프트웨어 진행상황 감독이 너무나 빈약해서 여러 악명높은 소프트웨어 재난은 출시예정 당일에야 발견했을 정도다"라고 말한다(Jones 1995b).
1987년에서 1993년 사이에 현장 59곳을 평가한 후, 소프트웨어 공학 연구소(SEI)는 그 중 75%가 프로젝트 감독 감시를 개선할 필요가 있음을 발견했다(Kitson and Masters 1993).
개선을 시도하고 다시 재평가 했을 때, 실패한 회사의 가장 큰 문제 역시 프로젝트 계획 수립과 감독 감시 분야에 있었다(Baumert 1995).
측정
효율적인 개발을 위해 소프트웨어 측정에 대한 기본 지식이 필요하다.
수집할 자료의 양이나 수집 방법 등 성과지표 수집에 관한 사안을 이해해야 한다.
현황, 품질, 생산성을 분석하기 위해 사용하는 성과지표에 대한 지식 또한 있어야 한다.
개발 속력을 파악하고 장기적인 관점에서 개발 속력 증감 여부를 알기 위해 기본적인 성과지표 자료를 수집할 필요가 있다.
기본적인 관리에 대한 읽을 거리
- Weinberg, Gerald M. Quality Software Management, Vol. 1: Systems Thinking. New York: Dorset House, 1992.
- Weinberg, Gerald M. Quality Software Management, Vol. 2: First-Order Measurement. New York: Dorset House, 1993.
- Weinberg, Gerald M. Quality Software Management, Vol. 3: Congruent Action. New York: Dorset House, 1994.
- Weinberg, Gerald M. Quality Software Management, Vol. 4: Anticipating Change, New York: Dorset House, 1996.
- Pressman, Roger S. A Manager's Guide to Software Engineering. New York: McGraw-Hill, 1993.
- Carnegie Mellon University/Software Engineering Institute. Tfye Capability Maturity Model: Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley, 1995.
- Thayer, Richard H., ed. Tutorial: Software Engineering Project Management. Los Alamitos, Calif.: IEEE Computer Society Press, 1990.
- Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, 1988.
- DeMarco, Tom. Controlling Software Projects. New York: Yourdon Press, 1982.
- Metzger, Philip W. Managing a Programming Project, 2d Ed. Englewood Cliffs, N.J.: Prentice Hall, 1981.
- Grove, Andrew S. High Output Management. New York: Random House, 1983.
4.2 기술 기본
Figure 4-2. Findings for "Use of Modern Programming Practices" factor(Vosburgh et al. 1984). You can't achieve top productivity without making extensive use of "modern programming practices" —what this chapter calls "technical fundamentals."
그림 4-2는 전형적인 실수에서 언급한 내용이고 교훈의 한 예이다.
기술 기본을 적용해도 그 자체로 생산성을 높일 수 없다.
현대적인 기법을 활용해도 그렇지 않은 프로젝트보다 낮은 생산성을 보여주기 때문이다.
래리 콘스탄틴은 오스트레일리아 컴퓨터 학회가 주최한 소프트웨어 대회(Australian Computer Socciety Software Challenge)에 대해 얘기했다.(Constantine 1995b).
언스트 앤 영(Ernst & Young, 다국적 회계 법인)에서 출전한 팀은 단계적인 개발과 중간 출시로 이루어진 정식 개발 방법론을 따르기로 결정했다.
처음에 뒤쳐졌으나 결국 선두로 나서서 우승했다. 선두에 나선 팀은 소스코드 관리를 효율적으로 하지 않은 전형적인 실수 때문에 발목을 잡힌 것이다.
운이 좋았다면 언스트 앤 영 팀보다 선두에 있었던 팀이 우승할 수도 있었지만, 몇 달 뒤 다른 쾌속 개발 시험에 참가했고 또 우승했다.
개발 기본 강조가 그렇게 짧은 시간에 큰 차이를 만들 수 있다면 6개월, 12개월 프로젝트에서는 상상할 수 없을 정도의 차이가 생길 것이다.
요구사항 관리
8천개가 넘는 프로젝트에 대한 조사에서 일정 초과, 예산 초과, 기능 미흡을 초래하는 가장 큰 이유 세 가지는
사용자 참여 부족, 미흡한 요구사항, 요구사항 변경으로 밝혀졌으며 이들 모두가 요구사항 관리와 관련이 있다(Standish Group 1994).
소프트웨어 공학 연구소(SEI)에서 수행한 조사 또한 같은 결론인데,
검토한 프로젝트 절반 이상이 불충분한 요구사항 관리 때문에 문제를 겪었다(Kitson and Masters 1993).
요구사항 관리 기본은 다음과 같다.
- Requirements-analysis methodologies including structured analysis, data structured analysis, and object-oriented analysis
- System-modeling practices such as class diagrams, dataflow diagrams, entity-relationship diagrams, data-dictionary notation, and state-transition diagrams
- Communication practices such as Joint Application Development(JAD), user-interface prototyping, and general interview practices.
- The relationships between requirements management and the different lifecycle models including evolutionary prototyping, staged releases, spiral, waterfall, and code-and-fix.
요구사항 관리는 두 가지 측면에서 개발을 가속화한다.
첫째,
요구사항 수집은 느긋하게 하는 경향이 있다. 수준을 높여 미리 작업한다면 전체 개발 기간을 단축시킬 수 있다.
둘째,
처음에 요구사항을 제대로 파악하는데 드는 비용은 나중에 구현, 유지보수 단계에서 드는 비용보다 1/50, 1/200 까지 적다(Boehm and Papaccio 1988).
일반적인 프로젝트에서 요구사항이 변경하는 비율은 20%이다.
관리를 위해 요구사항 변경을 줄이는 것과 변경에 드는 비용을 줄이는 것이 있다.
변경 비율을 25%->10%로, 비용을 1/5 -> 1/10 까지 줄여 이 둘을 합친다면 쾌속 개발이 안될 이유가 없다.
설계
집을 짓기 전에 청사진을 그리는 게 당연하듯이 소프트웨어도 아키텍처와 설계서를 작성하는 과정도 당연하다.
시스템 테스트 단계에서 설계 결함을 발견해 고치려면 설계 단계에서 처리할 경우보다 시간이 약 10배 더 든다(Dunn 1984).
모듈 방식과 정보은닉은 설계 기본으로 구조적 설계와 객체지향 설계의 기초가 되는 개념이다.
모듈 방식과 정보은닉을 논하지 못하는 개발자는 드리블을 할 줄 모르는 농구 선수와 같다.
아키텍처와 설계 관련한 기본 주제는 다음과 같다.
- Major design styles (such as object design, structured design, and data structure design)
- Foundational design concepts (such as information hiding, modularity, abstraction, encapsulation, cohesion, coupling, hierarchy, inheritance, polymorphism, basic algorithms, and basic data structures)
- Standard design approaches to typically challenging areas (including exception handling, internationalization and localization, portability, string storage, input/output, memory management, data storage, floating-point arithmetic, database design, performance, and reuse)
- Design considerations unique to the application domain you're working in (financial applications, scientific applications, embedded systems, real-time systems, safety-critical software, or something else)
- Architectural schemes (such as subsystem organization, layering,
subsystem communication styles, and typical system architectures)
• Use of design tools
설계를 하지 않고 시스템 개발은 가능하긴 하다.
그러나 설계는 구현, 일정 수립, 감독, 관리를 위한 기본이며 효과적인 설계만이 개발 속력을 최대화할 수 있다.
구현
이 시점에 이미 성공과 실패를 결정하는 기본이 갖춰졌다고 볼 수 있다.
요구사항 관리와 설계 이 두 가지가 구현보다 개발 일정에 더 큰 영향을 미친다.
구현은 일정 단축을 비약적으로 할 수는 없다.
상세하고 노동 집약적인 활동기기 때문에 제대로 수행해야 하기 때문이다.
처음부터 코드 퀄리티가 형편 없다면 나중에 또 고쳐야 하는데 두 번 손을 대는 행위는 절대적으로 비효율적이다.
설계가 미흡하면 핵심 부분을 다시 작성해야 할 수 있다. 반면 구현 그 자체에서 심각한 일은 거의 발생하지 않는다.
그러나 구현이 미흡하면 찾아서 고치는데 오래 걸리는 어려운 결점이 생기기도 한다.
구현 기본은 다음 주제를 포함한다.
- Coding practices (including variable and function naming, layout, and documentation)
- Data-related concepts (including scope, persistence, and binding time)
- Guidelines for using specific types of data (including numbers in general, integers, floating-point numbers, characters, strings, Booleans, enumerated types, named constants, arrays, and pointers)
- Control-related concepts (including organizing straight-line code, using conditionals, controlling loops, using Boolean expressions, controlling complexity, and using unusual control structures such as goto, return, and recursive procedures)
- Assertions and other code-centered error-detection practices
- Rules for packaging code into routines, modules, classes, and files
- Unit-testing and debugging practices
- Integration strategies (such as incremental integration, big-bang integration, and evolutionary development)
- Code-tuning strategies and practices
- The ins and outs of the particular programming language you're using
- Use of construction tools (including programming environments, groupwork support such as email and source-code control, code libraries, and code generators)
이런 기본에 충실하려면 시간이 좀 들지만 프로젝트 전반에 걸쳐 시간을 절약할 수 있다.
개발 기본 강조는 위험 관리만큼이나 시간을 절약할 수 있는 방법이다.
판독 불가능한 쥐집(rat's nest) 같은 코드는 구현 기본에 충실하면 막을 수 있다.
(현재는 스파게티 코드라는 용어를 많이 쓰는 것 같다.)
소프트웨어 구성 관리
Software Configuration Management(SCM)는 프로젝트 부산물 관리법으로 개발 기간 동안 프로젝트가 일관된 상태를 유지하도록 한다.
변경요청 검토, 변경사항 감독, 여러 버전 관리, 부산물 복사본 보관 등을 포함한다.
흔한 관리 대상은 소스코드 중심이지만, 요구사항 명세서, 계획서, 설계서, 테스트 케이스, 결함 보고서, 사용자 문서, 자료, 기타 개발에 사용된 업무를 관리대상으로 할 수 있다.
SCM을 품질보증 방법 중 하나로 보는 시각이 있는데 이는 개발 일정에 미치는 영향이 중립적이거나 부정적이라는 의미가 포함된다.
하지만 개발 속력을 최대화 하는 데 있어서 SCM은 결정적이다.
자동화된 소스 코드 관리 부재는 매우 비능률적인 현상이다.
소프트웨어 공학 연구소(SEI)는 1987년 ~ 1993년 사이 현장 조사를 실시했는데, 회사의 50% 이상이 구성 관리를 개선해야 한다는 걸 발견했다. (Kitson and Masters 1993).
구성관리가 부족하면 작은 프로젝트에서는 전체 비용이 약간 증가했지만 큰 프로젝트에서는 성공과 실패를 좌우하는 항목 중 하나였다(Jones 1994).
개발 기본에 관한 읽을 거리
요구사항 관리
- Yourdon, Edward. Modern Structured Analysis, New York: Yourdon Press, 1989.
- Hatley, Derek J., and Imtiaz A. Pirbhai. Strategies for Real-Time System Specification. New York: Dorset House Publishing, 1988.
- Gause, Donald C., and Gerald Weinberg. Exploring Requirements: Quality Before Design. New York: Dorset House, 1989.
설계
- Plauger, P. J. Programming on Purpose: Essays on Software Design. Englewood Cliffs, N.J.: PTR Prentice Hall
- McConnell, Steve. Code Complete. Redmond, Wash.: Microsoft Press, 1993.
- Yourdon, Edward, and Larry L. Constantine.Stru-ctured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Englewood Cliffs, N.J.: Yourdon Press, 1979
- Page-Jones, Meilir. The Practical Guide to Structured Systems Design, 2d Ed. Englewood Cliffs, N.J.: Yourdon Press, 1988.
- Booch, Grady. Object Oriented Analysis and Design: With Applications, 2d Ed. Redwood City, Calif.: Benjamin/Cummings, 1994,
- Goad, Peter, and Edward Yourdon. Object-Oriented Design. Englewood Cliffs, N.J.: Yourdon Press, 1991.
구현
- McConnell, Steve. Code Complete. Redmond, Wash.: Microsoft Press, 1993.
- Marcotty, Michael. Software Implementation. New York; Prentice Hall, 1991.
- Bentley, Jon. Programming Pearls. Reading, Mass.: Addison-Wesley, 1986.
- Bentley, Jon. More Programming Pearls: Confessions of a Coder. Reading, Mass.: Addison-Wesley, 1988.
- Maguire, Steve. Writing Solid Code. Redmond, Wash.: Microsoft Press, 1993.
소프트웨어 구성관리
- Bersoff, Edward H. et al. Software Configuration Management. Englewood Cliffs, N.J.: Prentice Hall, 1980.
- Babich, W. Software Configuration Management. Reading, Mass.: Addison-Wesley, 1986.
- Bersoff, Edward H., and Alan M. Davis. "Impacts of Life Cycle Models on Software Configuration Management," Communications of 'the ACM 34, no. 8 (August 1991): 104-118.
4.3 품질보증 기본
제품에 결함이 너무 많으면 개발자는 구현보다 정정에 더 많은 시간을 보내게 된다.
처음부터 결함을 만들지 않는게 낫다는 건 많은 회사가 이미 경험해서 알고 있다.
결함을 없애는 열쇠는 처음부터 품질보증 기본에 충실하는 것이다.
일부 프로젝트의 경우 설계와 코드 검토, 테스트 기간을 줄여서 잃어버린 시간을 보충해 보려 한다.
하지만 품질 향상(결함률 저하)과 개발 기간 단축은 같이 움직이기 때문에 이 결정은 최악의 결정이 된다.
그림 4-3은 결함률과 개발 기간의 관계를 보여준다.
Figure 4-3. Relationship between defect rate and development time. In most cases, the projects that achieve the lowest defect rates also achieve the shortest schedules.
개발 기간을 엄청나게 늘이지 않는 이상 더 낮출 수 없는 극단적으로 낮은 결함률을 달성할 수도 있는데
우주선 생명유지 장치 같은게 아니라면 보통 소프트웨어에는 그렇게 시간을 들일 필요는 없다.
케이퍼 존스는 프로젝트 4000여개를 조사한 결과낮은 품질이 일정 초과를 일으키는 가장 빈번한 이유라고 보고했다(Jones 1994).
소프트웨어 공학 연구소(SEI)는 60%가 넘는 회사가 불충분한 품질보증으로 곤한을 겪는다고 보고했다.(Kitson and Masters 1993)
95% 지점은 매우 중요하다. 여기서 최단 일정, 최소 노력, 최고 사용자 만족을 이루는 점이 보이기 때문이다(Jones 1994).
일정이 촉박한 프로젝트는 품질 보증을 대충한다. 이유는 출시에 30일 밖에 없어서라는 꼬리를 붙인다.
제품을 빨리 완성하도록 압박을 받으므로 지름길을 택하도록 내몰리게 된다.
일정 압박에 개발한 제품에서 보통보다 네 배까지 많은 결함을 발견할 수 있다(Jones 1994).
일정에 문제가 있다면 영리하게 일하는 것 보다 열심히 일하는 것에 집착한다.
요구사항, 설계, 구현 결함으로 인한 재작업 비용이 전체 개발 비용의 40% ~ 50%를 차지하는 건 여러 연구를 통해 밝혀졌다(Jones 1986a, Boehm 1987a).
결함 방지 작업에 1시간을 쓰면 수정에 3시간 ~ 10시간 가량을 단축할 수 있다(Jones 1994).
최악의 경우 구현 후 요구사항 문제 수정에 드는 비용이 요구사항 단계에서 수정하는 데 드는 비용보다 50배 ~ 200배가 더 든다(Boehm and Papaccio 1988).
결함의 60%가 설계 시점에 생긴다는 사실을 고려하면 시스템 테스트 이전에 결함을 발견해 시간을 절약할 수 있다. (Gilb 1988)
오류 유발성 모듈
오류 유발성 모듈이란 비정상적으로 많은 결함을 일으키는 모듈을 말한다.
IBM은 IMS 프로젝트에서 결함 5%가 모듈 7% 내에서 발생하는 현상을 발견했다(Jones 1991).
베리 뵘은 모듈 20%에서 결함 80%가 발생한다고 보고했다(Boehm 1987b).
개발 속력이 정말 중요하면 오류 유발성 모듈을 찾아내고 다시 설계하는 활동을 수행하라.
오류 결함률이 코드 1000줄당 10개를 넘으면 다시 검토해서 설계 구현을 할지 결정해야 한다.
그 이상 엉멍진창이거나 너무 복잡하거나 처음부터 다시 설계하고 구현한다.
테스트
가장 일반적인 품질보증 방법은 의심의 여지없이 실행 테스트이다.
여기에는 개발자가 자신의 코드가 동작하는지 검사하는 단위 테스트가 있고
다른 하나는 별도의 테스터가 시스템이 의도한대로 동작하는지 확인하는 시스템 테스트가 있다.
단위 테스트는 10% ~ 50%의 결함을 발견할 수 있고, 시스템 테스트는 20% ~ 60% 정도 발견할 수 있다. 둘 다 하면 총 결함 발견율을 60% 미만이 된다(Jones 1986a).
테스트는 개발 속력 관점에서는 미운 오리 새끼이다.
철저하게 할수록 개발 속력이 늦춰지지만, 대체로 일정에 직접적으로 영향을 미치지는 않는다.
품질이 너무 낮아서 출시를 미뤄야 하는 건 테스트를 하면서 확인할 수 있다.
테스트는 일정에 영향을 미치는 나쁜 소식을 전하는 관문이다.
쾌속 개발 관점에서 이 나쁜 소식을 어떻게 대처할지 미리 계획을 세워두는 게 좋다.
기술 검토
결함을 발견하기 위해 사용하는 모든 종류의 검토를 얘기한다.
검토 회의
검토 회의는 개발자들이 품질 향상을 목적으로 기술업무를 검토하는 회의를 뜻한다.
테스트 전에 결함을 발견할 수 있으므로 쾌속 개발에 유용하다.
검토 회의에서 30% ~ 70% 까지 오류를 발견할 수 있다(Myers 1979, Boehm 1987b, Yourdon 1989b).
코드 검사
검토 회의 보다는 공식적인 방식이며 코드에만 적용한다.
나사 소프트웨어 공학 연구소의 실험에서 코드 검사는 테스트 보다 두 배나 많은 오류를 발견했다(Card 1987).
이는 코드 검사와 테스트를 함께 수행하는게 일정을 줄이는 데 훨씬 효과적임을 알려준다.
정밀 검토
검토할 작업 결과를 개발자들에게 나눠주고, 개발자들이 설명할 때 검토자가 오류를 지적하면
그걸 서기가 오류 내용과 대응 방안을 기록해 검토 보고서를 작성한다.
이걸 개발 공정의 효율성을 분석하고 향상하는데 이용한다.
정밀 검토는 테스트 전에 결함을 발견하는 데 효과적이다.
60% ~ 90% 까지 결함을 발견할 수 있어서 검토 회의나 테스트 보다 훨씬 낫다.
개발 초기에 사용하면 10%에서 30%까지 개발 일정을 단축할 수 있다(Gilb and Graham 1993).
대규모 프로그램을 대상으로 정밀 검토에 들인 1시간이 유지보수에서 평균 33시간을 줄일 수 있어서 테스트 보다 20배나 효율적이다.(Russell 1991).
기술 검토에 대한 주석
검토를 통해서 테스트에서 놓친 다른 종류의 결함을 발견할 수 있다(Myers 1978 Rasili, Selby and Hutchens 1986).
결함을 초기에 발견하므로 일정 단축에 효과적이다.
검토는 결함 증상과 원인을 동시에 발견하므로 결함당 비용 측면에서 더 효율적이다.
또한 검토는 개발자들이 좋은 개발법에 관한 지식을 공유할 수 있는 기회를 제공해 장기적으로 쾌속 개발 달성 능력을 증가시킨다.
품질보증 기본에 관한 읽을 거리
소프트웨어 품질
- Glass, Robert L. Building Quality Software. Englewood Cliffs, N.J.: Prentice Hall, 1992.
- Chow, Tsun S., ed. Tutorial: Software Quality Assurance: A Practical Approach, Silver Spring, Md.: Computer Society Press, 1985.
테스트
- Myers, Glenford J. The Art of Software Testing. New York: John Wiley & Sons, 1979.
- Hetzel, BIll. The Complete Guide to Software Testing, 2nd Ed.Wellesley, Mass: QED Information Systems, 1988.
검토와 정밀검토
- Gilb, Tom, and Dorothy Graham. Software Inspection. Workingham, England: Addison-Wesley, 1993.
- Freedman, Daniel P., and Gerald M. Weinberg. Handbook of Walkthroughs, Inspections and Technical Reviews, 3rd Ed. New York: Dorset House, 1990.
4.4 지시에 따르기
개발자와 관리자가 지시에 따르지 않아 프로젝트가 실패하는 경우가 있다.
기본을 익히지 않고 소프트웨어 개발은 가능하다. 그리고 가끔 빨리 개발도 한다.
그러나 대부분의 결과를 판단해 보면 기본을 습득하지 않으면 빨리 개발하는 데 필요한 프로젝트 통제력을 확보하지 못한다.
페인트칠의 경우 개집을 칠한다고 하면 그냥 칠해도 그럴싸할 수 있다.
하지만 보잉747을 칠한다고 하면 매뉴얼대로 칠하는게 맞다.
일정 문제가 있는 소프트웨어 프로젝트를 생각해 보면 대부분 개집보다는 큰 집이거나 조금 더 큰 프로젝트 정도일 것이다.
이런 프로젝트에서는 개발 기본이 시간을 절약한다.
페인트를 칠해야 하는 엄격함을 따르지 않아도 되고 이해만 제대로 하면 융통성을 발휘할 수 있다.
기본을 무시해도 된다. 하지만 그에 따르는 위험은 각오해야 한다.
읽을 거리
여기 소개하는 책 두 권은 소프트웨어 개발 기본을 설명하는 책이다.
- Sommerville, Ian. Software Engineering, 6th Ed. Reading, Mass.: Addison-Wesley, 1996.
- Pressman, Roger S. Software Engineering: A Practitioner's Approach, 3rd Ed. New York: McGraw-Hill, 1992.