1

Introdusction to Software Engineering1. 소프트웨어 공학 소개

2. 소프트웨어 공학 방법론

3. 프로젝트 관리론

4. Requirements Engineering (요구 공학)

2

1. 소프트웨어공학소개

- 개념 및 정의

- Software Project failures (실패 요인 분석)

- 성공 요인 분석

소프트웨어공학에관한여러정의들…

The systematic approach to the development, operation, maintenance, and retirement of software. - IEEE Computer SocietyThe disciplined application of engineering, scientific, and mathematical principles and methods to the economicalproduction of quality software. - Watts HumphreyMulti-person construction of multi-version software (i.e., program family) - D.L. Parnas

소프트웨어의특성

Complexity

Changeability4 하드웨어에비해, 수정은용이하지만저렴하지는않음

4 소프트웨어는초기개발비용보다는유지/보수하는데많은비용이필요하므로, 처음에체계적으로개발해야만경제적으로유지/보수/확장을할수있음

Longevity4 “소프트웨어제품”은오랜시간에걸쳐수정/보완/확장되어야만함

소프트웨어개발의기술적인어려움

“소프트웨어”는소스코드뿐만아니라개발과정에서생성된관련된문서일체를포함함

개발과정에서요구사항등이수시로바뀌기때문에, 소프트웨어개발이어려움

4A moving target요구되는신뢰도에따라, 개발과정에서행해져야하는분석의종류나 “깊이”도다양함4원자력발전소제어소프트웨어의경우, 개발과정전체에걸친안전성분석이필수

4또한고신뢰도의보안이요구되는소프트웨어의경우 (e.g., Secure OS, 방화벽, 또는침입탐지시스템등) 보호프로파일의만족여부에관한정형검증이필요한경우도있음

Common Criteria (CC) Evaluation Assurance Levels (EALs)

6

소프트웨어개발의기술적인어려움

적용분야뿐만아니라소프트웨어프로젝트의규모또한다양하며, 필요한개발및프로젝트관리기술도다름

Size of project

Small: Medium: Large: V. Large:

By numbers of people

1 to 5 people

5 - 30 people

30 - 50 people

> 50people

By dollar amount

< $500K $500 - $3M $3 M - $10 M

>$10 M

By lines of code

< 5K LOC

5K to 50 K LOC

50K to 500K LOC

> 500K LOC

By time to deliver

< 6 month 7 mo to 1 year

1 – 3 years > 3 years

7

대규모소프트웨어프로젝트관리의어려움

8

소프트웨어공학의비용과효용성

소규모프로젝트의경우, 체계적인소프트웨어공학원칙의적용은비용을증가시킬수있으나, 대규모프로젝트의경우, 소프트웨어공학은선택이아닌필수사항

소프트웨어공학기술의다양성…

공통적인기술들4 소프트웨어개발방법론, 프로세스정의및개선 (e.g., CMM, CMMI,

SPICE, …), 요구공학, 객체지향및컴포넌트기술, UML 2.0, Software Architecture, 형상관리기술, 테스팅, 품질관리, 프로젝트관리기술, …

그외특정분야에따라필요한기술들4 Software Product Line, …4 정형명세및검증기술 (Statecharts, Message Sequence Charts,

Model Checking, Theorem Proving, …)4 실시간소프트웨어성능검증기술 (Rate Monotonic Analysis, Worst

Case Execution Time Analysis, …)4 Model Driven Architecture, …4 .NET, J2EE, J2ME, XML, Web Services, …4 임베디스소프트웨어의경우 PLC (programmable logic controllers) 프로그래밍및분석기술이필요함 (e.g., Ladder Diagram, Function Block Diagram, …)

10

IEEE Software Engineering Standards

http://shop.ieee.org/A standard is an approved, documented, and available set of criteria used to specify and evaluate the adequacy of an action or objectProcess standards 4 IEEE-Std 1074-1997, IEEE Standard for Developing Software Life

Cycle Processes 4 IEEE Std 1012-1998, IEEE Standard for Software Verification and

Validation Product standards4 IEEE Std 829-1998, IEEE Standard for Software Test

Documentation4 IEEE Std 830-1998, IEEE Recommended Practice for Software

Requirements Specifications

11

Software Project Failures and Lessons to be Learned

소프트웨어위기

많은소프트웨어개발프로젝트에서흔히나타남

한통계자료에의하면 55%의프로젝트는비용초과, 68%는개발기간초과, 그럼에도불구하고 88%는수정/보완을해야만했다고함

소프트웨어위기: 계획과비교했을때비용초과, 개발기간초과, 성능또는기능면에서만족스럽지않은소프트웨어가개발되는경우

원래비용또는개발기간등에관한계획자체가비현실적이었을수있지만, 거의대부분의소프트웨어개발프로젝트에서겪는현상

13

Software Runaway Projects

Robert Glass, Software Runaways: Monumental Software Disaster프로젝트실패의주요원인이소프트웨어개발에있고, 개발기간또는비용이원래계획보다 2배이상초과한경우, Runaway project로규정하고이유를분석.4 많은경우, 원래계획자체가비현실적일수있지만, 2배이상차이가생긴다면실패한프로젝트로볼수있음

실패한프로젝트의경우, 대부분은그원인이여러가지요소에기인함

실패의원인은기술적인요인보다는관리적인측면이더많음

개발비용의초과 (62%)보다는개발기간의초과 (89%) 사례가많음

14

실패한프로젝트의주요원인들

Project objectives not fully specified (51%)Bad planning and estimating (48%)Technology new to organization (45%)Inadequate/no project management methodology (42%)Insufficient senior staff on the team (42%)Poor performance by suppliers of hardware/software (42%)

15

실패한소프트웨어프로젝트에대한분석

실패한프로젝트의 75% 이상이개발또는계획초기단계부터실패의징후가나타나기시작함

프로젝트실패의대부분 (72%)은관리자보다는프로젝트팀내부에서문제로부각됨

“신기술”이프로젝트실패의주요원인이될수있음4 “technology new to the organization”4 개발팀이신기술을충분이이해하거나습득하지못하는경우, 기술을충분히활용하지못해서실패할수있음

실시간소프트웨어의경우, performance requirement 때문에실패한프로젝트가많음

4 개발초기부터 performance에대한고려및분석이꼭필요함

16

실패요인 1: 개발목표가분명하지않은경우

요구사항을제대로분석하지못한경우, 실패할가능성이높음4 “꼭필요한”요구사항과 “제공되면좋을지도모르는”희망사항을엄격하게나누고분석해야함

4 요구사항이애매모호하게기술된경우

4 요구사항이개발도중지나치게많이바뀌는경우

Denver 국제공항의화물처리소프트웨어4 상대적으로간단한시스템을 (적절한대비또는분석없이) 대규모의복잡한환경에사용하려함

Florida의Welfare 시스템4 Centralized system을너무쉽게분산시스템으로확장/적용한경우

AAS (미국항공기관제시스템)4 시스템의규모나복잡도에관한철저한분석이없이개발을시작한경우

4 개발시작후 10여년이지난후에도기술적으로가능한지여부에대한논의가있음

17

실패요인 2: Bad planning and estimating

Management by schedule (deadline)”의경우일정에대한지나친강조로각과정에서작업이소홀하게행해짐

4 일정을맞추는것이 –실제작업의완성도에관계없이 –프로젝트의최대목표가되어버림

4 형상관리나에러관리가제대로행해지지않음

프로젝트의범위나목표가분명하지않은상태에서, 성공적인프로젝트의수행을기대하기어려움

“On Technology”4 시스템에저장된파일이름의 index를구하는간단한프로젝트로시작하여, 파일의내용까지 index를하고, fuzzy search기능까지추가하는것으로프로젝트의규모가무분별하게확장된경우

18

실패요인 3: Technology new to Organization

“신기술”에대한충분한교육또는 pilot project없이프로젝트에적용되는경우4 Scalability에대한검증이없이적용될수있음4 꼭필요한기능을제공하지못할수도있음을미리파악하지못하는경우, 실패한가능성이높음

“신기술”은화려하고, 이론적으로는쉽게적용될수있을것같지만, 실제로는신기술의습득에는많은시간과비용이드는것이현실

FoxMeyer Drug Co. 4 SAP을이용한실시간제고관리시스템 (Client-Server architecture)4 소규모의 simulation을통하여적용하기로결정하였으나, 하루 50만건의

transaction을처리하지못한다는것을뒤늦게발견New Jersey Division of Motor Vehicle4 Ideal이라는 4th generation language를충분한시험없이적용하였으나실패

19

실패요인 4:Poor Project Management

개발팀의규모또는기술수준을제대로파악하지못하는경우

프로젝트에하청업자를비롯한여러조직의인원이같이참여하는경우

프로젝트의관리가가끔또는 “대충대충”행해지는경우

20

실패한프로젝트에대한대처방법들…

Extending the schedule (85%)Better project management procedures (54%)More people (53%)More funds (43%)Pressure on suppliers by withholding payment (38%)Reduction in scope of project (28%)New outside help (27%)Better development methodologies (25%)Pressure on suppliers by threat of litigation (20%)Change of technology used on the project (13%)Abandoning the project (9%)Other (9%)

21

Software Failure and Critical Failure Factor*

Organizational contextHostile culturePoor reporting structures

Management of projectOver-commitmentPolitical pressure

Conduct of the project4 Initiation phase

Technology focusedLure of leading edgeComplexity underestimated

4 Analysis and design phasePoor consultationDesign by committeeTechnical fix for management problemPoor procurement

4 Development phaseStaff turnoverCompetencyCommunication

4 Implementation phaseReceding deadlinesInadequate testingInadequate user training

* From Stephen Flowers, Software Failure: Management Failure, Amazing stories and cautionary tales

22

CFF: Organizational Context

프로젝트가잘못되고있을경우, 이러한문제를제기하는사람이“희생양”이되거나또는해결사역할을하도록문제를떠맡게되는경우, Senior management가 프로젝트의문제점에대해초기에제대로보고받고적절한조치를취할수있는기회가없어질우려가있음

주의해야하는사항들

4 문제점을제기한사람에게불이익이생기지않도록

Do not shoot the messenger 4 문제제기를한사람에게해결책까지마련하도록시키지말도록

4 누군가반드시실패에대한대가를치러야하는 fear-based management가되지않도록

23

CFF: Organizational Context

권장해야하는사항들

4 가능하면프로젝트의진도및문제점에대한객관적이고사심없는보고를받도록

4 일에방해가되지않는범위내에서정기적으로프로젝트의진도에관한확인하는일

4 필요에따라서객관적인평가가필요하다면외부의자문을받아프로젝트의현황및문제점을파악하도록

“open” project 문화의정착4 프로젝트참여자들의건설적인비판을권장

4 경우에따라서는, 팀원들이돌아가면서비판자의역할을하도록권장

24

CFF: Project Initiation Phase

시스템을개발하기전에사용자들의업무습관/패턴을잘파악할것4 (임의로) 개발된시스템에실제사용자들의업무패턴을맞추도록강요해서는안됨

“첨단기술”이라고해서반드시프로젝트에도움이되는것은아닐수있으므로, 꼭필요한지또는도움이되는지를분석할것

시스템전체의규모및복잡도에대해꼼꼼한분석을행할것. 많은경우, 프로젝트를수주하기위해 feasibility study 및예산결정과정에서복잡도가축소되거나간략화할수있는가능성이있음

25

CFF: Analysis and Design Phase

“Customer”또는 “major stakeholder”와충분한상의를할것“Design by committee”를피할것4 관점/목표/이해관계가다를수있음을기억할것4 Conceptual integrity는제품의품질에중요한영향을미침

26

CFF: Implementation Phase

개발인원의변동은있을수있으므로, 관리자는이에대비하고계획을세워야함

그러나, 잦은그리고반복되는개발인원의변경은프로젝트가뭔가잘못되고있다는증상일가능성이높음

4 개발팀의의욕이상실될위험이있음

프로젝트가원래의기일 (deadline, milestone)을어기기시작할경우, 관리자는원인에대한충분한분석을해야함충분하지않은시험또는사용자에대한교육은아마도프로젝트가제대로진행되고있지않을가능성이높다는증상

27

성공요인분석 (Microsoft 사례)

28

왜마이크로소프트사에서배울필요가있는가?

MS사의제품의경우, 초기에는품질및개발일정에많은문제가있었음MS의제품중일부는 (특히Windows 경우) 아직도소프트웨어의품질에문제가있음

4 원래예정보다출시가늦는경우가흔하며

4 테스팅을마치고출시된제품에서치명적인보안결점이발견되는경우가자주있으며

4 제품간의데이터교환이나호환에문제가있는경우가종종있으며

4 알수없는이유로프로그램이응답하지않는경우가흔히있음

그럼에도불구하고, MS사의방대하고복잡한소프트웨어제품을개발하고지속적인유지/보수를통하여많은제품이시장우위를지킨다는것은잘알려져있음

4 Windows XP의경우, 일부언론보도에의하면 70,000,000 줄이상의코드로구성되어있다고함

따라서, MS사의소프트웨어개발사례에서타회사특히 application software개발업체또는 SI업체에서배울만한교훈이많이있음

29

Microsoft Secrets

Organizing and Managing the Company4 Find “Smart” people who know the technology and the business

Managing Creative People and Technical Skills4 Organize small teams of overlapping functional specialists

Competing with Products and Standards4 Pioneer and Orchestrate Evolving Mass Markets

Defining Products and Development Processes4 Focus creativity by evolving features and “fixing” resources

Developing and Shipping Products4 Do everything in parallel with frequent synchronization

Building a Learning Organization4 Improve through continuous self-critiquing, feedback, and sharing

Attack the Future!

30

MS소프트웨어프로젝트관리원칙

Smart people and small teams4 소프트웨어의개발자의경우, 개인별능력차이가 10배에서 20배까지도날수있다는통계를생각하면너무나도당연한원칙

4 소수의인원으로구성된개발팀은의사결정과정도신속하고 communication overhead가적으므로효율적

A development process that allows large teams to work like small teams4 컴포넌트기반의소프트웨어방법론이보편화되기전에도, 소프트웨어개발과정에서의복잡도를최소화하려는노력을강조

4 하나의제품을다수의 feature set으로나누고, 각각의 feature set을다른팀에서개발Product architectures that reduce interdependencies among teams4 정보은닉 (information hiding) 개념의적용

Nearly all new product development done on one site4 다국어지원이필요한제품의경우에도 Redmond 본사에서개발4 신속하고일관성있는의사결정이가능해짐

People working on the same machines they build products for4 개발환경과사용환경이상이한경우, 테스팅과정이비효율적일수있음

31

MS 소프트웨어프로젝트관리원칙

A single main development language4 90년대초반까지는특별한경우가아니면모든프로젝트는 C 언어사용4 그후 C++를거쳐서, 지금은 C#으로통일4 개발인력이다른팀으로옮기게되는경우빠른시간에새로운업무에적응할수있음

4 소수의그러나강력한프로그래밍및분석도구를사용할수있음

Large capital investments to support people4 소프트웨어개발은노동집약적이고창의적인작업이므로, 쾌적한환경 (예: 개별사무실)에서더높은생산성을기대할수있음

Internal use of their own engineering tools4 프로그래밍및분석도구를타회사에의존하여생길수있는위험요인을배제

4 많은경우, 내부사용을목적으로개발된도구들이독립적인제품으로발전하였음 (예. VisualTest및형상관리도구)

More than one person who understands the product detailsManagers who both create the product and make the technical decisions4 매니저가제품에대한깊이있는기술적인이해없이단순한관리자로전락하는것을막기위함

4 제품에대한기술적인결정과정에서생길수있는실수의가능성을줄일수있음

32

MS소프트웨어프로젝트관리원칙

Quick decision making on technical-versus-business trade-offs4 실무자에의한, 신속한의사결정을중시하는회사의개발문화를반영함

An enormous feedback loop from customers4 “beta testers”4 시제품의배포를통하여결점및추가되어야할기능등에대한의견수집

4 “best tester”는제품검증의책임을사용자들에게일부전가한다는비난도있음Deliberate efforts to learn from past projects4 하나의프로젝트가끝날때마다개발자들이토론과분석을통해, 각프로젝트에서성공및실패요인을분석하고그결과를문서화하고경험을공유함

4 하나의프로젝트에서배운교훈을다른프로젝트에도 “신속하고값싸게”전파하기위한노력

4 90년대중반까지는 Bill Gates가직접참여할정도로경영진에서중요시함.

33

Defining Products and Development Processes

Focus creativity by evolving features and “fixing” resourcesDivide large projects into multiple milestone cycles with buffers and no separate product maintenance4 Waterfall 개발방법론이아닌 incremental 개발방법론채택4 상대적으로짧은개발기간과 life cycle을채택4 각프로젝트의개발일정은자율적으로 (그러나상당히빡빡하게) 결정하고추진함.

4 각 cycle에서 20~30%의일정을 buffer time으로할당Sync-and-stabilize approachDaily builds

34

Synch-and-Stabilize Development Approach

Planning Phase: Define product vision, specification, and schedule

Development Phase: Feature development in 3 or 4 sequential subprojects that each results in a milestone release* Subproject 1: First 1/3 of features. Most critical features and shared components* Subproject 2: Second 1/3 of features* Subproject 3: Final 1/3 of features. Least critical features.

Stabilization Phase: Comprehensive internal and external testing, final product stabilization, and ship

35

2. Software공학방법론

36

Why Software Process Model?

Definition and documentation of the activities to be performed, their orders, and the expected deliverables4 Essential for disciplined, repeatable, and systematic software

development4 Defines exit criteria4 Different factors (domain, quality assurance, complexity, etc)4 Elaborate process definition (or process programming) possible

Waterfall model, incremental model, prototyping model, spiral model are best known

Waterfall Model

R equ irem ent sd efi ni ti on

S y st em andso ftware d es ig n

Im pl em ent a t io nand u ni t t est in g

Int egr a t io n an ds ys tem t est in g

Op erat io n an dm ain ten ance

Key characteristics4 Sequential: Successful production of required deliverables (e.g., documents)

and completion of proper reviews allow transition to the next phase4 Document-driven:4 “Loop back” may occur

Waterfall Model and Typical Deliverables

Activity Output documentsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan

Draft user manualArchitectural design Architectural specification, System test planInterface design Interface specification, Integration test planDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation

Reviews and Dependancies

System Requirements

Software Requirements

Preliminary Program Design

Detailed Program Design

Analysis

Testing

Operation

Translation Design into Code

Preliminary Design Phase Implementation and Operation PhaseDetailed Design Phase

Software Requirements Review Preliminary

Design Review Critical

Design Review

Test Procedures Review

Software Acceptance Review

System Specification

Test Plan

Functional Design Document

Interface Control Documents

Software Requirements Specification

Test Procedures

Detailed Design Document

Test Report Operating

Instructions Version Description Document

40

Application of Waterfall model at NASA

Strictly sequential in principle, parallel activities in practice

Waterfall Model and Evaluation

Widely used in large-scale software development (especially so in defense industry or large SI projects)Documentation overhead is sometimes considered excessiveProbably OK with well-understood and low-risk projectsMay not be suitable to UI-heavy projectsMeasurement and monitoring of “real progress” is not as easy as it may appearMaintaining consistency among documents and proper configuration management essentailIntegration (or integration testing) is known to be difficult and time-consuming task

Incremental Model

“mini-Waterfall” development repeatedEarly customer feedback possible

43

Incremental Model and Evaluation

Easier, compared to waterfall model, to monitor progress Configuration management is likely to be more important and “messier” if several releases are to be concurrently supportedSoftware features are prioritized

Prototyping

Exploratory (evolutionary) vs. Throw-away Prototyping does not necessarily mean “ad hoc” or “hacking”

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

OutlineRequirements

Evolutionary prototyping

Throw-away prototyping

Usually to better understand (sometimes subtle but real) customer requirements

Outlinerequirements

Developprototype

Evaluateprototype

Specifysystem

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Rapid Prototyping Experience

Gordon and Bieman, Rapid Prototyping: Lessons Learned, IEEE Software, 1995/139 projects4 Military, commercial, academic

0

2

4

6

8

10

12

14

16

18

Military Commercial Academic

0

5

10

15

20

25

Small Medium Large

48

Rapid Prototyping

Prototyping was generally considered successful

0

5

10

15

20

25

30

35

Success Failure ?

0

5

10

15

20

25

Throwaway Evolutionary ?

Rapid Prototyping: Process Attributes

0

5

10

15

20

25

Decreased Increased Not Stated

Cost

0

5

10

15

20

25

Increased Decreased Not Stated

End user participation

Rapid Prototyping and Potential Risk

May create unrealistic expectation on schedulePrototyping is NOT risk-free but generally a promising approach

Spiral Model

A Risk-driven Approach to the Software Process

Riskanalys is

Riskanalys is

Riskanalys is

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept o fOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit tes t

Integr ationtestAccep tance

testServ ice Develop, verifynext-level p roduct

Evaluate alternativesiden tify, resolve risks

Determine ob jectivesalternatives and

constraints

Plan next phase

Integrationand test p lan

Developmentplan

Requirements planLife-cycle plan

REVIEW

52

CBD 방법론: Impact of InternetInternet, more specifically Web, is reshaping everything of enterprises,4 And forcing them to radically re-think the ways in which they do business

And, eCommerce, eBusiness, B2B, and B2C emerge as one of the biggest markets4 Since internet makes it possible

To share knowledge globally and For everyone to interact each other

Rate of change in Business is becoming faster than IT’s capacity to deliver

CYCLE TIMES -- 1970s & 1980s

CYCLE TIMES -- 1990s12 - 18 MONTHS

7 YEARS

Normal IT Capacity to Delivery

53

CBD 방법론: Business Implications of Software Change

Rate ofchange

Rate ofchange Opportunities

Business

Software

Business Degreeof risk

Time

When it takes longer to change the software than to change the business, the business is at risk

Software

Time

When software changes faster than the business, the business creates strategic opportunities

54

How to Survive in the Internet Age

Rapid changes in technology

Keywords: - Rapid changes in technology- Integration

Higher Competition

Shortfall in IT

resources

Integrated approaches to business analysis and software design

Plan to have a solution easy to adapt to rapidly changing technologies

How to Survive

55

Component-Based Development

Traditional development-from-scratch is inadequate in Internet EraConcentrate on the point of high-value to make your solution unique And, finish conventional work by assembling components from GUI to system packages such as ERP and SCM

Increase business opportunity

High value

Other standard packages

ERP SCM GUIs

Development by integration Concentrate on

the differentiator fromcompetitors

56

What is Component?

Independently deployable unit of software, 4 The behavior of which is encapsulated in terms of a set of interfaces4 That is executable without additional efforts4 That is interoperable with other components through an infrastructure,

called component model4 That provides comprehensible documents

57

What is Component Based Development?

Component

ReusableService

Semantics

Repository

System

System Under Assemble

Select

Composible

Executable

Understand

Assembly

Compile

58

Characteristics of CBD

Key characteristics of components are4 Separation of interfaces from components, and4 Guarantee of encapsulation

It enables “plug&play” because the implementation of components only depends on other interfaces4 We does not care the internal of components any more when they

conform to the required interfaces4 That is, we can integrate or replace components freely

CBD views a system as the network of 4 Components and 4 Their interfaces

We refer to this network as Component Architecture

59

CBD Methodology :

Reuselibrary

Separate componentdevelopment methodologyspecifies how componentsare created and maintained

Determinereuse options

Develop screensIn an external tool

60

CBD Methodology :

requirementsIterate andField application

Third cycle, etc

First cycle(focus on coreFunctionality)

Second cycle(improveand expand)

61

General Requirements for CBD Methodology

Methodology must include 4 Identification of purchase and reuse opportunities4 System and component specification4 Component construction4 Application assembly4 Harvesting

Methodology must be supported by a repository

Methodology requires clear roles4 Component developer and application assembler4 System designer4 Librarian

62

Existing CBD Methodologies

Unified Process(Rational Corp.)Catalysis(Icon Computing Corp.)SELECT( Corp.)CBD/e(Castek Corp.)CBD96 ( Corp.)

63

RUP Reference

Rational’s site4 http://www.rational.com

Book4 Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified

Software Development Process, Addison-Wesley, 1999

64

Catalysis Reference

Resources in Web4 http://www.catalysis.org4 http://www.platinum.com/consult/crc/crc.htm (Catalysis

resource center in Platinum Corps.)

Papers4 S. Kent, et el., “Component Composition in Business and

System Modeling,” Proceedings of OOPSLA97

Book4 D. F. D’Souza and A. C. Will,, Objects, Components, and

Frameworks with UML, the Catalysis Approach Addison-Wesley, 1999

65

SELECT Reference

Book4 Paul Allen, Stuart Frost, Component-Based Development for

Enterprise Systems applying the SELECT PerspectiveTM, CAMBRIDGE university press, 1998

Paper4 임춘봉역, “차세대응용시스템개발을위한 CBD 실용방법론 –

SELECT Perspective”, white paper, Princeton Softech, Jan.,2000(http://www.princetonsoftech.com/index.asp)

66

CBD/e Reference

Castek’s homepage4 http://www.castek.com

Component Headquarter’s homepage4 http://www.cbd-hq.com

Papers4 W.D.Burg, S. Hawker, D. Hale, K. McInnis, A. Parrish, S. Sharpe and R.

Woolridge, “Exploring a Comprehensive CBD Method : Use of CBD/e in Practice”, 3rd Int’l Workshop on Component-based Software Engineering, 2000

4 K. McInnis, “An Overview of CBD/e”, Technical Reports, Castek Corp.1999Book4 J. Cheeseman and J. Daniels, UML Components : A Simple Process for

Specifying Componet-based Software, Addison-Wesley, 2001

67

CBD96 Reference

Resources in Web4 http://www.castek.com/hotnews/harmon_cab_letter.html

Paper4 Sterling Software, “The CBD96 Standard Version 2.0”, Technical

Report, December 1997.

68

3. 프로젝트관리론

69

효율적인프로젝트관리의중요성

효율적으로프로젝트를관리한다고해서프로젝트가반드시성공한다는보장을할수없음

그러나, 제대로관리되지않는프로젝트가성공할가능성은낮음프로젝트를효율적으로관리하려면, 경험을바탕으로, 일어날수있는상황들을예측하고이에대한대처방법등을미리생각하고각각의선택에대한장점.단점을분석하고기록해둘필요가있음계획이수립되고, 각단계별로예상되는결과물등이정해져있어야프로젝트의성공적인진행여부를판단할수있음

많은소프트웨어프로젝트는유사한점이많으나, 각각의프로젝트는고유의특성을가지고있으므로, 프로젝트계획또한특화 (또는tailoring)될필요가있음4 The product is intangible4 The product is uniquely flexible4 The software development process is not standardized

소프트웨어개발프로젝트관리가어려운이유

소프트웨어의개발이단순하고반복적인작업이아니므로, 얼마나걸릴지예측하는것이매우어려움. 주관적인요소가많으므로Cocomo등비용및기간을산출하는방법이있으나, 여러가지변수가있을수있음

소프트웨어의특성상요구사항이자주변하기때문에원래계획대로진행될가능성이적음을이해해야함

소프트웨어개발의경우, 생산성이투입된인력의숫자와반드시비례하는것이아님

Mythical Man-Month

IBM사의 OS/360 운영체제소프트웨어개발과관련한교훈들Adding manpower to a late software project makes it later. That is, people and time are not interchangeable in software development

perfectly partitionable task

unpartitionable task

partitionable task requiring communication

task with complex interrelationship

소프트웨어 개발

Mon

ths

MenTime versus number of workers

mythical man-month

All programmers are optimists: All will go well.4 소프트웨어개발자는작업의어려움이나필요한기간등을낙관적으로

(경우에따라서는비현실적일정도로) 예측하는경향이있음Our estimating techniques, built around cost-accounting, confuse effort and progressAdding manpower to a late software project makes it later4 가장핵심적인교훈.문제가있는프로젝트에추가인원을투입하는경우, 정도의차이는있을수있지만, 작업의재분배및조정, 새로추가된인력에대한교육및학습기간, 추가적으로발생하는 communication overhead 때문에더늦어지는경우가비일비재함

소프트웨어개발프로젝트에서생각해야하는점들

유능한프로젝트관리자는개발인원중연 20~30% 정도는여러가지의이유로 (예: 퇴사, 소속팀변경등) 개발인원이바뀌는것이보통이므로, 이에대한적절한대비를해야함.프로그래머가소프트웨어의개발에실제로전념할수있는시간은전체일과시간의작은일부분밖에되지않음을이해해야함.

Writing Programs

13%

Personal 13%

Mail 5%

Job Communication

32%

Miscellaneous 15%

Training 6%

Reading Programs & Manuals 16%

74

프로젝트관리프로세스

프로젝트 관리계획

프로젝트통제/제어

프로젝트평가

Feedback

75

프로젝트관리계획을위해꼭필요한요소들

목표 : 목표및범위가분명하지않은프로젝트라면여러가지시행착오를더거치게될가능성이높으므로비용절감, 기간단축, 개발되는소프트웨어의품질또는생산성향상등에바람직하지않음

접근방법및프로젝트수행원칙의수립4 전략(Strategies)4 정책(Policy)

프로젝트매니저 (PM) 및참여인력의능력을존중하고, 자율권을부여하는것이중요소프트웨어개발은특히개발자의능력에따라, 프로젝트의성패가좌우되며, 개인별생산성의차이는 10~20배까지도날수있으므로, 동기부여가성공의핵심

4 절차(Procedures)프로젝트의진행과정에서빈번히일어날수있는여러상황 (예: 요구사항의변경)에대한절차를기술

참여인력간의의사소통을원활하게하고, 갈등의소지를줄여줌

76

프로젝트계획/통제의어려움

비용, 일정, 요구사항등은서로배타적인면이있음4 비현실적인기대는금물.

그외여러요소 (예: 개발인력의변경)등에효율적으로대처해야함4 개발인력의경우, 약

20%정도는여러가지이유로교체되는것이보편적

4 유능한프로젝트관리자는이러한상황을가정하고, 대처방법을준비함

처음계획대로아무런차질없이완료되는프로젝트는없다는점을명심해야함

77

“Balance”

“You can have your software cheap, soon, good; choose any two”

프로젝트계획및요구사항을기술한문서는프로젝트를시작하기위한최소한의요건

소프트웨어의개발이아닌, 구매 (acquisition)의경우또한계획의수립이필요

If the software is:If the software is:Cheap and soon: it wonCheap and soon: it won’’t be good t be good Cheap and good: it wonCheap and good: it won’’t be soont be soonSoon and good: it wonSoon and good: it won’’t be cheapt be cheap

78

프로젝트관리계획의핵심요소들

• Schedules for the timely completion of tasks 작업을제때끝낼수있는시간계획• Estimation of effort 필요한노력의예측• Adequate resources needed to execute the tasks 작업을수행에필요한충분한자원• Allocation of tasks 작업의배분• Assignment of responsibilities 책임부여• Quantification of risks associated with the tasks or the process itself 작업또는고정자체에관련된위험을계량화• Quality control measures to be employed throughout the process 공정전반에걸친품질제어수단• Costs associated with the process execution 공정수행에관련된비용• Provision of environment and infrastructure. 환경또는기반시설의제공

•• Schedules for the timely completion of tasks Schedules for the timely completion of tasks 작업을작업을 제때제때 끝낼끝낼 수수 있는있는 시시간간 계획계획•• Estimation of effort Estimation of effort 필요한필요한 노력의노력의 예측예측•• Adequate resources needed to execute the tasks Adequate resources needed to execute the tasks 작업을작업을 수행에수행에 필요한필요한 충충분한분한 자원자원•• Allocation of tasks Allocation of tasks 작업의작업의 배분배분•• Assignment of responsibilities Assignment of responsibilities 책임책임 부여부여•• Quantification of risks associated with the tasks or the processQuantification of risks associated with the tasks or the process itself itself 작업작업또는또는 고정고정 자체에자체에 관련된관련된 위험을위험을 계량화계량화•• Quality control measures to be employed throughout the process Quality control measures to be employed throughout the process 공정공정 전전반에반에 걸친걸친 품질품질 제어제어 수단수단•• Costs associated with the process execution Costs associated with the process execution 공정공정 수행에수행에 관련된관련된 비용비용•• Provision of environment and infrastructure. Provision of environment and infrastructure. 환경환경 또는또는 기반시설의기반시설의 제공제공

79

프로젝트계획문서의예

Software project management plans (overall) 소프트웨어프로젝트관리계획 (전반적인)Budget plans 예산계획Verification and validation (V&V) plans 검증및확인계획Software testing plans (sometimes part of V&V plans) 소프트웨어시험계획 (종종검증및확인계획의일부가됨)Software configuration management plans 소프트웨어형상관리계획

Software quality assurance plans 소프트웨어품질보증계획Data conversion plans 자료변환계획Logistics support plans 물자공급계획Software engineering standards to be followed 준수해야할소프트웨어공학표준

80

IEEE Software Project Management Plan

IEEE-Std 1058-1998, Standards for Software Project Management Plan4 Software products to be delivered 인도할소프트웨어제품4 Organizational relationships between stakeholder 이해관계자들사이의조직적인관계

4 Roles and responsibilities 역할과책임4 Development methods and tools 개발방법론과도구4 Reporting and control mechanisms 보고및제어구조4 Tasks, schedule, and budget 작업, 시간계획그리고예산4 Resources required 필요한자원4 Plans for updating the plan 계획을갱신하기위한계획

많은프로젝트의경험에서도출된그리고모든소프트웨어프로젝트에서필수적으로고려해야하는최소한의요소들

Checklist처럼활용할수있음.

81

IEEE Standard

Front Matter1. Overview 개요2. References 참고문헌3. Definitions 정의4. Project Organization 프로젝트조직5. Managerial Processes 관리공정6. Technical Processes 기술공정7. Supporting Process Plans 공정계획의지원8. Additional Plans 추가적인계획Annexes 부록Index

82

1. Overview 개요

1.1 Project Summary 프로젝트요약4 요약문서의경우, 전체를읽지않아도핵심적인내용을파악할수있도록구성4 자세한내용을필요로하는경우, 어느부분을더읽어야하는지 reference를포함해야함

4 1.1.1 Purpose, Scope, and Objectives 의도, 범위, 목적4 1.1.2 Assumptions and Constraints 가정및제약조건

흔히간과하기쉬운사항들. 팀원들마다각자가이해하는가정/제약조건등이틀릴수있음을명심해야함

구체적으로쓰여져있는경우 –혹시틀리더라도 –수정/타협이가능함4 1.1.3 Project Deliverables 고객에인도할프로젝트결과물4 1.1.4 Schedule and Budget Summary 시간계획과예산요약

1.2 Evolution of the SPMP 소프트웨어프로젝트관리계획의진화4 프로젝트계획이수정되는경우, 어떤절차를거쳐서수정/보완되어야하는지명시

83

References and Definitions 참고문헌과정의

프로젝트에서사용하게되는관련문서및용어를정리

같은용어라도각자의전문분야또는배경에따라다른뜻으로해석하는경우가있으므로, 원활하고일관성있는의사소통을위해필요한정의를명시해야함

다수의인원이협력해야하는프로젝트의경험이없는경우, 이러한사항들은 “요식행위”또는 “행정/관료주의”처럼보일수있음

84

4. Project Organization 프로젝트조직

4.1 External Interfaces 외부인터페이스4 프로젝트의범위를명시하는것이중요함

4.2 Internal Structure 내부구조4.3 Roles and Responsibilities 역할과책임4 각자의책임과권한을명시하는것은프로젝트의관리에꼭필요한

사항

85

5. Managerial Process Plans 관리공정계획

5.1 Project Start-Up Plan 프로젝트시작계획5.2 Estimation Plan 예측계획4 5.2.1 Cost and Schedule Plan 비용과시간계획

초기의예측이틀릴수있지만, 어떤방법으로산정이되었는지등을기록해두어야보완/수정을제대로할수있음.

4 5.2.2 Staffing Plan 직원확보계획4 5.2.3 Resource Acquisition Plan 자원확보계획4 5.2.4 Project-Staff Training Plan 프로젝트구성원교육계획

일부해당사항이없다고판단되는항목의경우에는, 해당사항이없음을명시하는것이바람직함.

86

5. Managerial Process Plans 관리공정계획

5.3 Work Plan 작업계획4 5.3.1 Work Activities 작업활동4 5.3.2 Schedule Allocation 시간배분

Bar chart 또는다른방법으로도식화할것4 5.3.3 Resource Allocation 자원배분4 5.3.4 Budget Allocation 예산배분

비용의경우도, 미리계획을하지않지않거나 (C-17 소프트웨어개발에서그랬듯이) 또는지속적인관리를통해모니터링을하지않으면, 문제가발생한다하여도모를수있음

87

5. Managerial Process Plans 관리공정계획

5.4 Control Plan 제어계획4 요구사항또는일정등에변경이필요한경우따라야하는절차를기술

4 개발되는소프트웨어의품질에직접적인영향을미치지않으나, 이러한 “사소해보이는”절차등을기술하지않고 “편리한대로”처리하는경우발생할수있는낭비및지연을생각해야함

4 5.4.1 Requirements Control Plan 요구사항제어계획4 5.4.2 Schedule Control Plan 시간계획제어계획4 5.4.3 Budget Control Plan 예산제어계획4 5.4.4 Quality Control Plan 품질제어계획4 5.4.5 Reporting Plan 보고계획4 5.4.6 Metrics Plan Metrics계획

5.5 Risk Management Plan 위험관리계획5.6 Project Closeout Plan프로젝트마감계획

88

6. Technical Process Plans 기술공정계획

6.1 Process Model 공정모델4 프로세스계획이정립되고문서화되어야, 참여인력들간에혼란을피할수있음

6.2 Methods, Tools, and Techniques 방법론, 도구, 기법6.3 Infrastructure Plan 기반설비계획6.4 Product Acceptance Plan 프로젝트승인계획4 이러한계획이없다면, 나중에프로젝트의평가나종료시에혼란이생김

4 프로젝트초기에는여러가지정보가없거나불분명하지만, 그래도“아는만큼”성실하고자세하게기록해두는것이중요

89

7. Supporting Process Plans 지원공정계획

7.1 Configuration Management Plan 형상관리계획7.2 Verification and Validation Plan검증및확인계획7.3 Documentation Plan 문서계획7.4 Quality Assurance Plan 품질보증계획7.5 Reviews and Audits Plan 검토및감사계획7.6 Problem Resolution Plan 문제해결계획7.7 Subcontractor Management Plans 하도급자관리계획

7.8 Process Improvement Plan공정향상계획

90

프로젝트계획변경

정기적인 (예: 매월) 검토를통해서계획대로진행되고있는지또는별도의보완/수정이필요한지결정해야함4 예상하지못했던요구사항의대폭적인변경등이일어날수있음

“검토를위한검토”또는 “요식행위”와유사한검토는피해야함4 프로젝트가만일제대로진행되고있지않다면, 가능한빨리발견하고효율적인대처방법을찾아야하기때문

4 관리자의입장에서는, 프로젝트가제대로진행되고있다는결론을내리고싶을것이므로, “매력적인유혹”이될수있음

프로젝트의계획등이변경되는경우, 모든참여자들이이해하고동의하는것이필수. 프로젝트일정등의이유로변경된계획을문서화/공식화하는작업을회피하는경우, 더큰혼란및지연이생길수있음을명심해야함

91

Organizational Structure 조직구조

프로젝트수행을위해필요한 task 및권한을명시함.4 Definition of tasks 작업정의4 Sizing of tasks 작업크기4 Grouping of tasks 작업의그룹4 Authority and communication between tasks 작업들간의권한부여와의사소통

4 …

소프트웨어개발프로젝트의조직

Chief programmer team방법을제일선호함4 제품의 conceptual integrity를향상시킬수있으며, 각 subsystem간의의존도를줄여서유지및보수가용이해짐.

4 1980년대의 Cohesion 및 Coupling 정의에의한모듈화에관한연구결과가, 2000년이후에는 Software Architecture에관한연구로발전되고있음

영화의경우, 감독과제작자의역할이잘정의되어있고분리되어있는것처럼, 소프트웨어의개발에서도 Manager와 chief architect (또는 chief programmer)의역할을나누어야함소프트웨어개발에있어서초기단계 (계획및요구사항수집/분석)와테스팅단계에충분한시간을할당해야함

4 요구사항의분석이제대로되지않으면, 경우에따라서는고객의필요를충족시키지못하는소프트웨어가개발될수있음

4 이런경우의재작업은무척이나비용이많이들고낭비적인작업

4 테스팅의경우, 경험에의하면전체개발비용의반정도가소요되므로특히효율적으로수행되어야함.

Chief Programmer Team

모든소프트웨어개발프로젝트에최선의방법은아닐수있으나, 가장효과적인방법으로전반적으로인식되고있음

각팀은너무많지않은 (3~8명정도의) 인원으로구성하는것이좋음4 Communication 및 Management overhead를최소화할필요가있음

Higher Management

Programmer Programmer Librarian Backup Programmer

Customer

Chief Programmer

Project External Library

Computer, Project Internal Library

94

프로젝트팀과팀구조

가능하면유연하고의사결정과정을빠르게.팀은 5명에서 10명정도로.가능하면 management overhead를줄일수있도록.Virtual team등인터넷이나다양한통신수단을이용하여, 원격으로협동작업을할수도있음

4 그러나, 왜 Microsoft가모든제품의개발은한곳 (“Redmond Campus”)에서하려고고집하는지생각해볼필요가있음

95

Responsibility Matrix의예

Jim Schmid John Doe Fred Jones Jan Smith Joe Barnes Tammy More Tim Korbal Chris Mane Jane Flikins Mark Roland Katy Croft Sam Johnson Anne Masson Dave Wilson Barry Sims Judy Pierce

Project MgmtPkg1 Pkg2 Pkg3 Pkg4 Quality

AssurancePkg 8Pkg 7Pkg6Pkg5 Config Mgmt.

Req. Def.

Integration & Test

Product Mgmt

Pkg1 Pkg2 Pkg3 Pkg4 Pkg5 Pkg6 Pkg7 Pkg8

Key Text Editor Form Letters Word Processing Spreadsheet Graphics Language Development Debug/Test Management Tools

Designated Person Responsible Supporting Role

X S

XX

XX

XX

XX

X

XX

X X

SS S S S

X

S S

Meredith, J.R. and S.J. Mantel, Jr., Project Management: A Managerial Approach, John Wiley & Sons, Inc., NY, 1985, pages 510.

96

Responsibility Matrix

Single point failure를피해야함Backup (또는 supporting role)을지정할것Project task를명시해야 responsibility matrix를완성할수있음.4 적절한프로젝트의계획수립이중요함

97

프로젝트매니저가해야하는중요한일들…

적합한조직구조의선택하기

적합한팀구조의선택하기

프로젝트외부인터페이스를확인하고접촉하기

외부인터페이스의책임과의무를기록하고공표하기

프로젝트의내부적책임과의무를할당하고문서화하기

…팀원에게동기를부여하고, 동기를부여하고, 또동기를부여하기

98

Project 통제

원래계획대로완벽하게진행되는프로젝트는없기때문.예산이변하고, 시간계획이변하고, 요구사항이변하고, 자원이변하고…프로젝트관리를위해monitoring해야하는사항들4 Expenditures vs. budget4 Milestones vs. schedule4 Productivity vs. expectations4 Quality vs. requirements4 Progress vs. goals4 …효율적인관리를위해서는, 자료 (Metric)에의거한합리적인판단이필수

99

프로젝트가잘못되는흔한이유들…

Not knowing the status of the projectKnowing and not doing anything about itNot updating plans to reflect realityNot preparing contingency (backup) plansWaiting too long to invoke a contingency plan…각프로젝트가끝날때마다, 배운교훈을정리하고다음프로젝트에서긍정적으로활용하는것이필수.

100

프로젝트관리를위해널리쓰이는방법들…

Software reviews -- Control of the project statusSoftware audits -- Control of the project complianceSoftware peer reviews -- Identification of software and system errorsSoftware quality assurance -- Control of the processSoftware configuration management (SCM) -- Control of the documentsSoftware verification and validation (V&V) -- Control of the project software products

101

4. Requirements Engineering

102

요구사항의개념

요구사항(requirements) 이란?4 고객(customer)이시스템으로부터원하는서비스4 시스템을개발하는동안에만족시켜야할제약(constraints)4 시스템이사용되는동안만족시켜야할제약

요구사항은시스템설계의기반이된다.요구사항은구현의정확성을판단하는기준이된다.요구사항은시험시테스트케이스(test case)를 (자동으로) 생성하는기반이된다.

요구사항의특성

시스템의외적인행위(external behavior)에대해객관적으로기술해야한다.구현단계에서지켜야제약을명시해야한다.유지보수를위해참조할수있어야한다.예기치못한상황에대한대응방안의성격을나타내야한다. 추적가능해야한다(traceable)정확해야하며, 일관되어야하며, 완전해야하며, 모호하지않아야하며, 이해하기쉬워야한다. 시스템이개발되거나사용되는동안발생할수있는요구사항의변화에대비해계획을세우는것은필수적이다.

요구사항의종류

지속되는요구사항(Enduring requirements)4 고객이조직에서수행되는핵심작업으로부터도출된안정적인요구사항

변동되는요구사항(Volatile requirements)4 시스템의개발이나사용과정에서변하는요구사항

요구사항의변경을반영하는작업이많은노력을필요로하지않도록요구사항의문서를구성하여야한다.

추적가능성(traceability)

요구사항의추적가능하다는것은각각의요구사항은그출처(source) 및그와관련이있는다른요구사항과서로연결되어있어야한다는의미이다.

추적가능성이요구사항명세가가져야할특성이하나로관련된요구사항을얼마나쉽게찾아낼수있는가를나타낸다.

추적을가능하게하기위한기법

4 모든요구사항에고유한번호를부여한다.4 관련된요구사항들을 이고유번호를사용하여서로참조하도록한다. 4 관련된요구사항들을포함하는각요구사항문서를위한상호참조행렬(cross-reference matrix)을생성한다. 서로다른종류의관계를표현하기위해여러개의행렬이필요할수도있다.

106

비기능적요구사항

시스템이만족해야하는특성(properties)과제약(constraints)을규정한다. 시스템이가져야하는신뢰도(reliability), 반응시간, 메모리요구등에대한요구사항이이에해당된다. 제약은입출력장치의수용능력, 시스템의표현형태(representation) 등이될수있다.

비기능적요구사항은기능적요구사항보다더중요할수있다. 왜냐하면비기능적요구사항을만족시키지못하는시스템은쓸모가없기때문이다.

기능적과비기능적요구사항은요구사항명세에구별하여기술하는것이원칙이나, 현실적으로이것은어려운일이다. 왜냐하면대개요구사항들은개별적인기능에대한제약으로기술되기보다는전체시스템요구사항에대한기술되기때문이다.

또한, 어떤요구사항이기능적인지비기능적인지를판단하는것이어려운경우도있다. 예를들어안전성에대한요구사항은비기능적인특성과관련이있으나이를만족시키기위한새로운기능이시스템에추가되어야할수있기때문이다.

107

요구공학개념과중요성

요구공학(requirements engineering) 이란?4 요구사항을확립해나가는프로세스(process)

요구공학의중요성

4 고객과개발자가요구사항의의미를서로다르게이해하는경우(의사소통의실패) 시스템개발이실패할가능성증대

4 시스템이사용되는동안발견되는오류의상당부분이요구사항의오류에서파생된것

108

요구공학프로세스

응용분야(application domain)에따라적합한프로세스도달라진다.안전성이중요한시스템(safety-critical systems)의경우에적합한프로세스의예

FeasibilityFeasibilitystudystudy

FeasibilityFeasibilityreportreport

SystemSystemmodelsmodels

RequirementsRequirementsanalysisanalysis

RequirementsRequirementsdefinitiondefinition

RequirementsRequirementsspecificationspecification

Definition ofDefinition ofrequirementsrequirements

RequirementsRequirementsdocumentdocument

Specification of Specification of requirementsrequirementsactivity

artifact

요구공학의어려움

추상화수준의차이: 이해관계자들은서로상이한추상화수준(level of abstraction)에서요구사항을표현한다.

어떤문제들은너무복잡해서시스템개발중에완전하게이해하거나엄밀하게기술할수가없다.4 적용분야(application domain)을이해해야한다.4 잘못된의사소통으로인해오해가발생할여지가많다.

모든요구사항을기술하지못하는것이보통이며(incomplete), 요구사항들사이에모순이있는경우도많다(inconsistent).

더나쁜것은, 요구사항이항상변한다는것이다.

110

요구사항의기술

요구사항은목적과대상에따라다양한형식과추상화수준(level of abstraction)으로기술될수있다.

시스템이제공해야하는서비스와시스템사용될때만족시켜야하는제약을고객을위해기술하는경우에는자연어(natural language: 일상생활에서사용하는언어)와도표(diagram)를사용하여알기쉽게기술하는것이좋다.

개발자를위한소프트웨어기술(software description)는설계와구현의기반이될수있도록더상세하게 (경우에따라서는정형기법을사용하여) 기술할수있다.

판단근거 (Requirements Rationale)

특정요구사항이선택된이유, 즉요구사항의판단근거(requirements rationale)를함께기술하는것이중요하다.

판단근거를토대로개발자는요구사항의적용될분야와요구사항이현재의형식으로기술되어있는이유를더잘이해할수있다.

이는요구사항의변경이필요한경우에더중요하다. 판단근거를이용할수있는경우에는요구사항의변경으로인해예상치못한결과가발생하는것을줄일수있기때문이다.

요구사항문서의예

서론4 시스템에대한필요성과함께어떻게사업목적(business objectives)에맞출것인가를기술한다.

용례4 사용된기술용어를정의한다.시스템모델4 시스템컴포넌트들과이들간의관계를보여주는모델을정의한다.기능적요구사항의정의4 제공되어야하는서비스를기술한다.비기능적요구사항에대한정의4 시스템과개발프로세스에부여되는제약을기술한다.시스템의진화4 시스템이근거하고있는기초적인가정과예상되는변화를기술한다.요구사항명세4 기능적인요구사항에대한세부명세

부록4 시스템하드웨어플랫폼기술4 Database 요구사항 (ER 모델과같은)색인

요구사항문서의또다른예

제품기능및특징

개발, 작동, 유지보수환경외부인터페이스와자료흐름

기능적인요구사항

성능요구사항

예외상황처리

먼저구현되어야할기능들의집합과구현의우선순위

예상할수있는변경과기능향상

수락조건(acceptance criteria)설계힌트와지침

상호참조색인

용례

요구사항검증/검토

요구사항의검증(validation)과검토(review)는요구사항이기술하고있는시스템이고객이정말로원하는시스템임을확인하는작업이다.요구사항에오류가개입되는경우그수정비용이크므로이러한검증작업은매우중요하다.요구사항이완성된후가아니라작성되고있는동안에도정기적인검토가필요할것이다.검토는완전한문서작성을수반하는형식적일수도있지만(formal review), 비형식적으로진행될수도있다 (informal review). 프로젝트의이해관계자, 즉개발자, 고객그리고사용자들사이의충분하고정확한의사소통은초기단계에발생하는여러문제를해결할수있게해준다.

요구공학분야의산업체경험

요구사항의기술에는자연어가가장빈번하게사용되고있으나, 그한계또한잘이해되고있다.

개선방향

4 엄격한명세언어의사용

4 시스템모델의작성 (Petri Nets, Statecharts 등을사용)

정형명세(formal specification): 느리지만꾸준하게산업체에서받아들여지고있다.

116

자연어의문제점

요구사항의기술에는주로자연어가사용되며, 이와더불어그림과표가보충적으로사용되는것이일반적이다. 그러나자연어기술은다음과같은문제를가진다.4 모호성이잠재되어있다: 자연어의경우같은단어라도상황에따라다른의미를지닐수있으며, 또사람에따라다른의미로사용될수있다. 따라서동일한요구사항을서로다르게이해할위험이있다.

4 요구사항의혼동: 기능적인(functional) 요구사항과비기능적(non-functional) 요구사항이뒤섞여기술되는경우가많다.

4 요구사항의융합: 여러가지요구사항이한꺼번에기술되어설계및구현과연결이어려운경우가발생한다.

자연어기술의대안들

구조화된(structured) 자연어요구사항명세언어(requirements specification languages)정형적인 (수학적인) 명세4 수많은표기법, 접근법, 분석기법등이제안되었음4 정형기법(formal methods)을받아들이는실무자들이점차늘어나고있음

4 산업체에서의경험에의해그효과가인정된정형기법들

MSC (Message Sequence Charts), Petri Nets and Design/CPN, Statecharts and STATEMATE, Z, …

정형명세

명시적이고엄밀하게정의된문법과의미(syntax and semantics)를가지는언어로기술됨4 기계적인검증을지원한다

4 의사소통을위한정확한수단이다.4 유용한문서로서기능한다.

실행가능명세 Executable Specification4 행위적의미(operational semantics)를가지는정형명세4 시뮬레이션, 코드생성

많은정형명세들은시각적으로표현된다.4 Statecharts, MSC, Petri Nets, …

많은정형명세들이도구를지원한다. 4 도구의사용은정형명세와이에기반한검증과정을용이하게한다.

참고문헌4 Hall, Seven Myths of Formal Methods, IEEE Software, 1990/94 Bowen and Hinchey, Seven more myths of formal methods, PRG-TR, 1994

119

정형명세의예

Statecharts4 반응형(reactive) 내장형(embedded) 시스템의명세에많이

사용되는정형명세

언어

4 명세는시각적으로

작성되고표현된다.4 명세가가지는의미는

수학적으로정의된다.

STATEMATE Magnum4 Statecharts 명세를지원하는도구

4 시뮬레이션과정형

검증을지원한다.

명세출처

4 STATEMATE MAGNUM User Manual

정형기법의적용사례

모델의생성과분석을통한요구사항의식별

4 Petri Nets, Colored Petri Nets, CMPN, …4 Statecharts4 Fault Tree Analysis

소프트웨어요구사항명세에대한사례연구들

4 Software Cost Reduction (SCR) Project4 TCAS Project

실시간프로세스제어시스템을위한완전성판단기준(Completeness Criteria for Real-Time Process Control Systems)

121

Q & A