BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
'Beyond Programming'에 해당되는 글 13건
2012.06.15 13:27

소프트웨어 이전의 제품들은 대부분이 물리적인 제약을 받는 것들이었습니다. 당연 설계 방법 또한 이를 고려해야 합니다. 하지만 소프트웨어는 이전의 제품들과는 달리 물리적인 제약을 받지 않는 특징을 가지고 있습니다. 그 능력을 최대한 활용하는 설계방법이 적응형 설계(adaptive design)입니다. 적응형 설계는 설계자들에게 니즈가 점진적으로 펼쳐질 때 그들의 제품도 적응할 수 있도록 하는 것입니다.

 

적응형 설계를 할 때 프로세스는 어떻게 되나?  

Rather than starting with a specification that states the requirements for a specific response to a real-world problem (i.e., hardware's product orientation), the designers would be able to model alternative responses to the need.

Rather than trying to anticipate all the implications of a set of requirements or a design (i.e., hardware's forward looking perspective), the designers would concentrate on the accuracy of their interpretation of the requirements and design.

Rather than trying to maintain the design separate from the product (i.e., hardware's dual realization), the design also would be the product.

Thus, the software-based model would be problem oriented, feedback driven, and employ a unified (as-built) specification.

 

적응형 설계는 1단계 프로세스로 자동화가 요구됩니다. 제품중심의 기존의 CASE와는 다른 지원 환경이 요구됩니다. 저자는 그러한 환경으로 TEDIUM을 제시합니다.

저자가 TEDIUM을 팔려고 하지 않듯이 우리도 TEDIUM에 대해서 그리 관심은 없습니다. 그래서 해당 내용에 대한 자세한 내용은 언급하지 않으려 합니다. 그러나 결국 우리는 새로운 TEDIUM을 만들어야만 하는 운명에 처할 것입니다. 그래서 몇 가지 도움이 될 만한 것들과 저자가 최종적으로 부탁하는 내용만 짚고 넘어가려 합니다.  

TEDIUM은 개발 중인 애플리케이션에 대해 알려진 모든 것을 담고 있는 애플리케이션 데이터베이스(ADB)를 관리합니다. 구현은 ADB로부터 생성되고, 유지보수는 ADB 수준에서 수행됩니다. 적응형 설계 관점에서 보면 ADB는 구축된(as-built) 명세로서의 개념모델입니다.

TEDIUM에서의 개발 프로세스는 점진적입니다. 설계자는 ADB에 명세를 입력합니다. ADB의 명세의 일부가 충분히 완전해지면 테스트될 수 있는 구현을 생성합니다. 설계자는 부분적인 구현이 원하는 대로 수행될 때까지 명세를 정제합니다.

생성된 프로그램은 기능적으로 완전하고 제품수준의 품질을 가지고 있기 때문에 검증된 후에 사용할 수 있는 제품으로 받아들여집니다. 최종 제품은 이러한 방법으로 점진적으로 구축됩니다.

 

ADB의 스키마는? ADB는 Singles, Collections, Pairs와 같은 세 가지 추상수준으로 제시합니다.

Singles. This is the minimal representation of an item at its highest level of abstraction (e.g., a type). The single hides all information about the item's structure while preserving information that is unique to the item (e.g., predicates on its use).
Collections. This is an ordered grouping of singles (e.g., a relation). The collection establishes semantic associations among singles. At the next higher level of abstraction, every collection is a single.
Pairs. This is a special type of collection, composed of two singles such that the second is functionally dependent on the first (e.g., a relation with a key). The pair establishes a unique identifier for certain collections.

 

I therefore conclude that application development environments for the next century must address three principal deficiencies of our present approach. In short,
We need as-built, adaptable specifications. The use of fixed specifications results in the design of what can be built rather than what is needed; it also constrains the extent of change to what can be changed rather than what needs to be changed.
We must learn to model concepts in the world. If a representation scheme is to be effective for applications in-the-world, then it must be able to model application concepts. Because concepts vary from one application class to another, two levels of conceptual modeling are needed: one that provides a general, domain-independent framework, and a second (normally built on the first) that is application-class specific.
We need to move beyond programming. Although there are many domains in which the formalisms of programming are appropriate, most are within the disciplines of computer science and computer engineering. This is too narrow a base for the applications of the 21st century.

 

RSMer's Page

변화에 열려 있는 open requirement를 다루면서 정형화된 개념모델과 그를 기반으로한 자동화를 동시적으로 이야기하는 것은 쉽지 않은 사고입니다. 행위형식화가 가고자 하는 방향도 이와 같습니다.

저자가 이 글을 쓴지 꽤 오랜 시간이 지났지만 저자의 바램은 이루어지지 않은 것으로 보입니다. 형식화하는 쪽은 제품중심적인 사고를 그대로 가지고 가고 있으며, 변화에 열려 있는 쪽은 변화에 대한 대응만을 강조하며 가고 있는 듯 합니다.

개인적으로 결국 이리 저리 돌아가겠지만 궁극은 언제나 두 방향이 합쳐지는데 있다고 생각합니다. 저자의 생각처럼 21세기에 개발이 이렇게 되지는 않았지만 궁극은 당신이 생각한 방향으로 가지 않겠느냐라는 말로 저자를 위로하면서 세미나를 마치려고 합니다. 

12장은 TEDIUM에 대한 사례이므로 세미나에서 제외합니다. 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.06.08 11:50

이번 장에서는 기존의 설계 방법들을 살펴보면서 앞으로 본격적으로 다룰 적응적 설계가 갖추어야 할 것들이 무엇일지에 대해서 언급합니다.

 

소프트웨어 개발 프로세스는 크게 문제지향인가 제품지향인가로 나눌 수 있습니다. 이 두 접근법의 큰 차이는 요구사항을 고정된 것으로 보느냐 그렇지 않느냐에 있습니다. 문제지향은 요구사항이 고정되어 있지 않다고 가정하고 제품지향은 문제가 고정되어 있다고 가정합니다.

소프트웨어 개발은 일반적으로 문제를 이해하는 단계와 해결책을 구축하는 단계로 나뉩니다. 문제 이해의 결과를 개념모델(conceptual model)이라 하고 해결책 구축의 결과를 정형모델(formal model)이라고 합니다. 이 두 모델을 도출해내는 기본적인 가정은 개념모델은 정형화하기 어려운가 그렇지 않은가 입니다. 

저자는 적응적 설계(adaptive design)를 제시합니다. 이것은 문제지향적이고, 문제영역을 정형화하고 해결책 영역을 자동화함으로 한 단계의 개발프로세를 갖습니다.

Adaptive design paradigm proposed in this book is problem oriented. Therefore, adaptive design seeks to put a domain-oriented face on its formality. Those who develop and analyze methods naturally recognize, and must respond to, these tensions.

I am convinced that the fully automated paradigm is the proper path to process improvement, and my implementation of adaptive design employs this approach.

Conceptual (descriptive) models offer guidelines for design decisions and validation; formal (prescriptive) models establish criteria for acceptance and correctness. The conceptual models describe an external reality, and the formal models prescribe the behavior of the software product being developed.

 

소프트웨어 개발에는 다양한 경쟁적인 목표를 가지고 긴장을 유발하는 것들이 있습니다. 개발 프로세스는 이러한 것들에 대응해야 합니다.

Problem and product. The process begins with a conceptual understanding of a need and concludes with the delivery of a formal, operational response to that need. That is, it begins with a problem and ends with a product. This places the designers in the dilemma of viewing their task as either one of looking out to the dynamic problem or stabilizing a solution within a requirements specification and then creating a product to satisfy that specification.

Validity and correctness. These are two independent quality attributes, and most methods favor a temporal division of their confirmation. That is, once we establish validity, the focus is on correctness. However, correctness is relative to the fixed criteria of the specification, and validity is subject of the dynamics and uncertainty of the problem space.

Formality and comprehension. Clearly, the software process must produce formal models. However, where there is a poor cognitive fit between the concept and the formal model, the assessment of validity suffers and productivity is impaired. Too often, we rely on the perceived expressiveness of informality and tolerate formalisms that degrade comprehension.

Fun and tedium. This is the tension between what people enjoy doing versus what must be done. Clearly, creativity is enhanced as we move to fun, while thoroughness and accuracy involve tedium.

Management and development. Management abstracts a project as a discrete model with events, and it associates development status with event status; in contrast, developers operate opportunistically and often find the events artificial. It follows, then, that one may model a management view of the process, but not the process itself.

Hardware and software development models. The initial lack of experience in software development led to the adapting the technological design methods of hardware to software. We must gain the confidence to overcome our successful heritage (based on the hardware model) and exploit
the unique properties of software.

Tradition and change. The software process is a socially determined activity, and its structure has evolved over time. Where the risk is low, moves to a new technology and investments in ancillary tools are favored. In contrast, a paradigm shift implies social restructuring with a high risk. Thus, we must manage the tension between incremental, but minor changes, and the need for a fundamental restructuring.

 

 

RSMer's Page

RSM은 대리연습을 비정형 요구사항을 다루고, 행위형식화를 통해 정형 요구사항을 다룹니다.

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.05.31 16:40

소프트웨어 개발은 문제해결이라 할 수 있기 때문에 소프트웨어 개발을 위해서는 문제를 이해하고 해결책을 설계하고 구축해야 합니다. 소프트웨어 개발 프로세스들도 이를 반영해서 먼저 문제영역을 다루고 그 다음에 해결책 영역을 다룹니다. 문제를 이해하기 위해 분석하고 해결책을 설계하고 검증하고 구축합니다.

폭포수 모델과 같은 기존의 소프트웨어 개발 프로세스는 요구사항을 분명히 정의할 수 있다는 가정을 갖고 있습니다. 이런 가정하에서 요구사항을 잘 정의하여 개념모델을 만들고 이를 기반으로 정형화된 소프트웨어모델을 만들어 구현하는 두 개의 큰 단계를 갖는 프로세스가 가능해 집니다.  

그러나 요구사항을 분명히 정의하기는 쉽지 않습니다. 소프트웨어가 환경을 바꾸는 것이라고 할 때 소프트웨어가 개발되어 사용되기 시작하면 환경이 바뀌기 때문에 이전 환경에 맞게 정의된 요구사항은 적합하지 않은 것이 됩니다. 또한 개발 도중에도 환경이 바뀔 수 있습니다.

The essential software process involves two classes of analysis. The first looks out to the problem space (conceptual modeling) and the second focuses on the implementation space (formal modeling). In earlier decades, there was the perception that the needs could be defined accurately (i.e., the requirements were closed), and the conceptual models were in fact quite close to the formal models (e.g., engineering applications that could be described effectively in FORTRAN). As we move to more open problems (open both in initial understanding and change over time), the gulf between the expression of the concept and its formal representation widens. We have two choices. We can continue to rely on the two-step model with its notion of a build-to specification. The two major deficiencies of this model are, first, that the special role of the specification inhibits iteration and refinement, and second, that the cognitive distance between the conceptual and formal models can act as a deterrent to problem
understanding.

 

저자는 두 단계 프로세스의 대안으로 한 단계 프로세스를 제안합니다. 두 단계를 하나의 단계로 줄이기 위해서 두 번째 단계를 자동화하자고 합니다. 이는 특별한 아이디어가 아니라 프로그래밍 언어에 있어 컴파일과 마찬가지의 원리입니다.

사실 이러한 아이디어의 가능성은 그리 크지 않습니다. 여러 가지 이유를 댈 수 있겠지만 제가 가장 크게 생각하는 두 가지 이유는 다음과 같습니다.

1. 문제 영역에 있는 사람들과 커뮤니케이션 가능하면서 해결책 영역에 맞도록 형식화하는 표현방법을 고안하는 것은 쉽지 않습니다. 컴파일의 성공은 해결해야 하는 문제가 같은 도메인에 있었기 때문에 가능했을 것입니다.

2. 문제영역을 표현하는 방법을 배우는 노력이 너무 클 수 있습니다. 학습 곡석이 크면 도입의 장점을 얻기 전에 포기되기 때문입니다.

어떻게 이것을 가능하게하는가도 중요하지만, 제시된 방법이 정말 사용될 것인가도 중요합니다.  

The alternative that I propose is to create expressive representations for the problem domain that can be transformed automatically into an implementation. Here the conceptual model of the product will constitute an as-built specification, and it can adapt as the domain requirements evolve.
This is not a particularly new idea; in fact, this is exactly what a "draw" program does. The challenge, of course, lies in the ability to find a rich representation scheme for the target domain and to establish how representations appropriate for that domain can be mapped into computer instructions.

 

저자는 소프트웨어 개발에 대한 메타포는 조각의 메타포에 더 적당하다고 주장합니다. 저 또한  소프트웨어의 고유한 특징인 유연성을 잘 반영하는 것은 조각 메타포라고 생각하고 이를 지지합니다.  

This approach employs an architect metaphor in which the architect works with models and drawings until the client is satisfied that the proposed building will satisfy her objectives. Once the plans are accepted, construction begins, and—because changes are very expensive—modifications are discouraged. That is not how architects really work; it is recognized that there will be some degree of openness throughout the process. In more dynamic applications, such as those with open requirements, a sculptor metaphor is more appropriate. The sculptor works with the materials and adjusts his goals as he interacts with the process. Although the process begins with sketches and analysis, fidelity to the initial goals is relatively unimportant. The process stops when the object is aesthetically pleasing, and the object's delivery constitutes its as-built specification. Of course, software, unlike a sculpture, is never complete, and so the process of sculpting never ends.

 

RSMer's Page

행위형식화는 문제영역의 행위를 직접적으로 정형화함으로 개념화 단계에서 직접적으로 정형모델을 사용합니다.

행위형식화는 객체모델에 대한 개념을 올바르게 갖고 있다면 추가적인 노력 없이 배울 수 있습니다. 또한 극히 절제된 방식으로 모델요소를 사용하기 때문에 매우 짧은 시간 내에 문제영역의 전문가들이 모델을 이해할 수 있고 커뮤니케이션이 가능합니다. 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.05.24 22:18

설계는 환경을 바꾸는 것이라고 생각하면, 환경의 변화에 영향을 받는 이해관계자들이 설계과정 중에 적극적으로 참여하는 것은 당연한 것입니다. 설계는 이러한 이해관계자들에 의해 영향을 받습니다.

Design is the conscious modification of the human environment.

This final chapter of Part II explores design in-the-world with particular emphasis on how it affects, and is affected by, the stakeholders. I use the title "Participatory Design" to distinguish this orientation from the historical approach to product development—what I have called "technological design."

 

소프트웨어시스템 개발에 참여하는 이해관계자들이 개발 초기 부터 시스템에 대한 분명한 개념을 갖기는 어렵습니다. 시행착오를 거쳐 학습을 하면서 점점 더 자신들이 원하는 모습으로 만들어가는 것입니다.

Design is a process of learning and a social activity.

There is process at work in which the designers come to learn what the users need and the users come to recognize what the technology can do. The result is a dialectic, an expansion, as perceptions evolve and a restructured solution emerges.

Adaptive design facilitates discovery during the modification of the human environment (i.e., design). It builds on existing knowledge to create new knowledge.

 

1부와 2부를 통해서 저자는 정말 어려운 이야기를 많이 했습니다. 이제 정말 저자가 하고 싶은 이야기가 나옵니다. 과연 어떤 이야기가 나올지 기대합시다.

 

RSMer's Page

이 장에서는 사용자와 시스템의 상호작용에 대한 많은 이야기를 합니다.

사용이란 것이 행위의 요구정보라는 것을 깨닫는다면 사실 이러한 이야기들은 그다지 큰 의미를 갖지 못하게 됩니다.  

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.05.16 14:21

이 장에서는 소프트웨어 설계프로세스를 본격적으로 살펴보기 앞서 공학(engineering)이나 건축과 같은 도메인에서의 설계프로세스를 살펴봅니다.

 

보통 설계하면 기술설계를 생각합니다. '설계가 환경을 바꾸는 것'이라는 관점을 가져야만 설계에 있어 기술 외에도 다양한 차원의 것들을 고려할 수 있습니다.

외부환경의 변경되면 설계 또한 이에 대응하여 변경되어야 합니다. 이런 관점에서 보면 설계는 의사결정이라기 보다는 sense making이라고 할 수 있습니다.  

The notion of sense making implies a collective context in which we must make sense of a situation, inherently social, interpret it, and make sense with others through conversation and action in order to reach agreement,

이런 관점에서 보면, 설계자 또한 환경의 일부가 되기 때문에 설계는 한 개인의 머리에서 나올 수 있는 것이 아닙니다. 

Design is not what is in an individual's head; rather it is something created by the social action of collaboration.

 

설계는 단순히 정형화된 일련의 절차로 가능한 것이 아닙니다. 설계는 중요한 tension들에 대해 대응하는 것입니다.

Design is not, as some textbooks would have us believe, a formal, sequential process that can be summarized in a block diagram"

As I have described it, design is characterized by its responses to its underlying tensions: form and context, the artistic and the analytic, the architect and his client, the activity and its management, the objectworld and the process-world.

 

설계는 모든 것을 다 아는 상태에서 시작하지 않습니다. 잘 모르는 상태에서 시작합니다. 잘 모르는 상태이니 실패하게 됩니다. 실패는 실패로 끝나지 않고 학습을 유도합니다. 실패를 통해 배웁니다. 학습을 통해 더 많은 것을 알게 되고 그에 따라 성공의 확률은 높아집니다. 성공은 해결책으로 반영됩니다.

Most design, he asserts, is on ill-defined problems (i.e., not copying). The search for a solution is a process of trial and error. Goal clarification proceeds in parallel with the search for solutions. During the process, there are failures, lessons, and occasional successes. The failures restrict the design space (i.e., resolve misfits), the learning expands the designer's ability, and the successes are worked into the solution. It is expected that the problem may change as the result of the design activity. "Part of the designer's skill is in understanding what the design is really supposed to accomplish. A mistake novices often make is to fixate on the original statement of design criteria"

 

 

RMSer's Page

RSM의 행위형식화 또한 위에서 설명하는 설계와 같이 잘 모르는 상태에서 시작합니다. 실패를 통해 학습하고 이를 통해 성공을 이끌어내고 해결책을 구축해갑니다. TDD 또한 그렇습니다.   

RSM에서는 이러한 과정에 좀 더 인간적인 특징을 반영하여 대리라는 개념을 사용합니다.  

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.05.07 19:31

사람들은 자신에게 주어진 상황속에서 문제를 이해하고 해결책을 설계해서 자신이 살아가고 있는 세상을 바꾸어 나갑니다. 이와 같은 이유로 설계과정의 상황성에 대해서 알아볼 필요가 있습니다.

저자는 이를 위해 이 장에서 액티비티 이론(activity theory), 성찰 실천(relective practice), 편향(bias)과 오류(error)와 이성의 역할(the role of the rational) 살펴봅니다.

In this chapter I explore the situatedness of the design process. I begin with an overview of activity theory (which is referenced by some of the new design methods), move on to the idea of reflective practice, and
then conclude with an examination of bias, error, and the role of the rational.

 

읽기 쉽지 않은 텍스트 입니다. 액티비티 이론은 다음 두 개의 을 먼저 읽고 시작하는 것이 좋을 것 같습니다. http://blog.naver.com/gaia92?Redirect=Log&logNo=120049911460, http://bit.ly/IB1Gox

 

저자는 액티비티 이론을 통해서 무엇을 말하고 싶은걸까?

In what I have called technological design, we begin with a set of requirements (i.e., goals) and operate at the level of the action in the creation of operational tools. Activity theory suggests that if we are to move to some higher level of design (e.g., the adaptive design of Part III), then we must perform the analysis at the level of the activity and retain the flexibility to experiment with the actions necessary to realize the activity.

 

왜 성찰(reflection)에 대해서 이야기하는가?

기술적 합리성 문제해결 모델에서는 우리가 지식체계를 가지고 특별한 문제에 대해 지식을 합리적으로 적용함으로 문제를 해결할 수 있다고 말합니다. 하지만 실제로 지식은 상황에 대한 대응으로 만들어집니다. 문제를 해결해야 하는 당사자의 이해를 벗어나는 상황이 발생했을 때 성찰을 통해서 상황과의 상호작용을 통해서 문제를 해결해 나갑니다.   

 

왜 이성과 편향과 오류를 이야기 하는가?

인간은 상황에서 편향과 오류를 일으키는 존재입니다.

Perhaps what we see as bias and error is the clash between what humans have gained through coping in-the-world (i.e., everyday experience) and the scientifically founded normative rules for interpreting that experience.

 

RSMer's Page

액티비티 이론에 대한 부분은

RSM의 전체와 부분, 컬레보레이션과 부분, 전체와 컬레보레이션이 부분의 컨텍스트가 된다는 것, 부분의 역할이 어떻게 주어지는지를 생각하면서 좀 더 깊이 있게 읽으면 좋겠습니다.

 

액티비티를 다음과 같이 세 수준으로 나누는 것은 인상적입니다.

Activity-Motive, Action-Goal, Operation-Condition(주어진 조건)  

 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.04.30 15:42

설계는 환경을 바꾸는 것입니다. 설계는 사람이 하는 활동으로 인간 환경을 바꾸는 것입니다.

왜 바꿀까요? 뭔가 문제가 있으니까 바꾸려고 하겠죠. 이런 관점에서 보며 설계는 문제에 대한 해결책을 구하는 것이라고 할 수 있습니다.

Design is a human activity that seeks to alter the human environment.

 

컴퓨터는 인간이 지식으로 표현할 수 있는 것에 기반하여 구축될 수 있습니다. 정형화된 지식이어야 합니다. 결국 우리는 소프트웨어를 개발하기 위해서 인간 지식의 성질을 알아야만 합니다.

Part II investigates the nature of human knowledge: what is known, knowable, and formally representable. Scientific knowledge is a subset of human knowledge, expertise is the richest form of human knowledge, and only formally represented knowledge can be modeled in-thecomputer.

 

이 장은 다양한 관점들(인지과학, 생태학, 전문성, 복잡성)을 가지고 인간의 문제해결에 대해서 살펴봅니다. 또 내용이 어려워 집니다. 저자는 여기서 다루는 것들에 대한 해결책으로 adaptive design을 제시합니다. 여기서 복잡하게 각각을 자세히 다루기 보다는 3부에서 필요한 부분만 취해서 이해하는 것이 더 쉬워보입니다.

 

RSMer's Page

RSM에서는 data를 fact로, information을 구조화된 fact로, knowledge를 행위수행규칙으로 설명합니다. 아래의 설명과 이를 비교하면서 좀 더 깊이 생각해보세요. 가치가 추가되었다는 것은 어떤 의미일까요?

Data are the items given to the analyst, information is the data organized in a some useful fashion (i.e., data with value added), and knowledge is the cumulative experience in the manipulation, exchange, and creation of information.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.04.25 11:57

컴퓨팅 기술에 대한 이해는 컴퓨터 이전에 있던 기술에 대한 경험을 기반으로 합니다. 이러한 이유로 소프트웨어는 컴퓨터 이전의 다른 제품들과 비교했을 때 타고난 유연성을 가졌음에도 불구하고 다른 제품을 만드는 방법과 유사하게 개발되어왔습니다.

It is about the mismatch between software's inherent flexibility and the methods now used in software's construction.

 

소프트웨어 개발 방법은 기존의 방법들과는 다른 소프트웨어의 타고난 유연성을 적극적으로 활용하는 개발 방법이 요구됩니다. 저자는 이러한 개발 방법으로 adaptive design을 언급합니다.

Part III identifies one such normative model, called adaptive design, and demonstrates its efficacy.

 

소프트웨어는 환경을 바꾸기 위해 개발됩니다. 따라서 소프트웨어 설계에 있어 환경에 대한 고려가 있어야 합니다. 전통적인 설계방식은 technological design라고 합니다. 환경을 고려한 설계를 ecological design이라고 합니다.

Whereas technological design begins with a concern for the technological issues affecting the design and its realization, ecological design begins with the human environment in which design is initiated, conducted, and evaluated. (In Part III I contrast these perspectives as product oriented and problem oriented.) A shift to ecological design implies a reassessment of the methods and techniques deemed essential to technological design. Therefore, the remainder of Part II focuses on the issues affecting design in the human environment.

 

인류는 근본을 찾기 위한 꿈을 가지고 있습니다. 그러나 그것은 단지 꿈일 뿐입니다. 우리가 아는 지식은 인식에 의한 것으로 인식의 컨텍스트를 갖습니다. 우리가 해야 할 최선은 아는 것을 더 정제하고 향상시키는 것입니다. 그것이 허용될 때 까지...

Toulmin observes that the "dream of foundationalism—i.e., the search for a permanent and unique set of authoritative principles for human knowledge—proves to be just a dream" (p. 174). All we are required to do is use our experience critically and discriminatingly, refining and improving our inherited ideas, and determining more exactly the limits to their scope" (p. 179). "The key problem is no longer to ensure that our social and national systems are stable; rather, it is to ensure that intellectual and social proedures are more adaptive" (p. 185).

 

이후의 장들에서는 어떤 내용을 다룰까?

What we are concerned with here is the much larger issue of the practice of design (technological, aesthetic, and artificial). This practice occurs in the environment to be altered, and it involves the interactions of people and their environment. At least four roles can be identified: There is the sponsor who seeks to modify the environment, the designer who produces a representation of the modification, the implementor who realizes the representation, and the user who interacts with or is affected by the implementation. A single individual may play all four roles, or there may be multiple individuals playing each role. It follows, therefore, that we cannot consider the practice of design without first starting with an understanding of people, how they respond to breakdowns (e.g., the discovery of a need), and how they solve problems. These are the topics of Chapters 5 and 6. With this background established, Chapters 7 and 8 turn to the practice of design in its most general form.

 

 

RSMer's Page

이 장의 4.3에는 하이데거가 등장해서 책 읽기를 어렵게 합니다. 이 기회에 하이데거 책 한권 정도 읽기를 권합니다. 읽을 때 저자가 얻은 설계의 통찰을 생각하면서 읽으면 더 좋을 거 같습니다.

저자가 이 내용을 설명하기 위해 인용하는 Herbert Dreyfus 교수의 홈페이지가 있습니다. http://socrates.berkeley.edu/~hdreyfus/

이 내용과 관련해서 좀 더 깊이 있는 생각을 해 볼 필요가 있습니다. RSM의 다음 내용을 다시 한 번 깊이 있게 읽어보시기 바랍니다. http://umlcert.tistory.com/608

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.04.18 19:18

3장까지가 1부를 구성합니다. 1부의 목적은 새로운 설계의 시대에 필요한 통찰을 얻기 위해 과학과 기술에 대해 살펴보는 것입니다. 2장에서는 과학에 대해서 살펴보았고, 이번 장에서는 기술에 대해서 살펴볼 것입니다.  

The goal of Part I is to lay out the scientific and technological foundations for this new era of design. In the chapter just concluded, we have seen how the Legend of science has become tarnished.

전통적인 관점에서는 과학이 지식을 발견하고, 기술이 그 지식을 적용하는 것으로 과학과 기술의 관계를 설명합니다.

Science discovers knowledge and engineering applies that knowledge.

오늘날에는 과학과 기술의 이러한 관계는 의심을 받기 시작합니다. 과학은 발견만 하는 것이 아니라 설계도 하고, 기술은 설계만 하는 것이 아니라 발견도 합니다.   

Science relies on design to support its discovery, and technology engages in discovery to improve its designs. Thus, it should not surprise us to find that there is no clear demarcation between the scientific and the technological.

Both physics and engineering science are discovery processes; the former is concerned with the natural phenomena of interest to the scientific community, and the latter concentrates on manmade and natural phenomena as they affect the artifacts to be designed. There is no division between the two categories of knowledge, and both disciplines engage in design. For science, it is design for discovery, and for technology it is discovery for design. Mirror-image twins. 

 

저자는 과학의 목적은 실체에 대한 모델을 만드는 것이라고 합니다. 과학과 기술을 다른 것으로 보지 않기 때문에 이 둘의 목적은 모델을 만드는 것이라 할  수 있다고 합니다. 

I began by stating that the goal of science is to model reality (i.e., to gain knowledge about the phenomenal world), and I have just asserted that there is no clear division between science and technology, between discovery and design. It follows, therefore, that the goal of science/technology extends to modeling what exists independent of humanity (which includes humanity as a component of the environment) and also to modeling aspects of humanity, such as its artifacts, the process of constructing its artifacts, and so on. By the logic of my argument, we now must model virtually everything. I am not sure that I can accept this challenge, but it will be useful to explore its consequences.

 

전통적인 관점에서의 과학은 수학과 논리에 의존해서 행할 수 있는 매우 좁은 범위의 실체에 대해 모델링해왔습니다. 소프트웨어 개발은 수학과 논리로 표현할 수 없는 모호한 부분 또한 모델링해야 하기 때문에 과학모델보다 더 나은 것을 찾아야 합니다.

The science of computer technology is that of a free phenomena.

 

 

RSMer's Page

"Discovery and Design"  RSM의 "생성과 사용"만큼 멋진 제목입니다.

멋지긴 한데 읽어내기는 쉽지 않습니다. 읽어내는데 너무 시간이 걸리면 정리된 내용만 확인하시고 넘어가셔도 됩니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2012.04.09 17:17

저자는 두 가지 관점에서 과학을 다룹니다. 하나는 철학으로서의 과학이고 다른 하나는 인간제도로서의 과학입니다. 이장은 첫 번째 관점을 다루는 부분입니다. 두 번째 관점은 2부에서 다룹니다.

 

저자는 왜 과학에 집착하는 걸까? 

We know that the software process is a transformation from the identification of a need in the world into a set of computer programs that operate in the computer.
The process begins with an idea, a concept, something that may defy a complete description, and it ends with the delivery of a formal model that executes in the computer. As we have seen, there is a fundamental tension in this transformation, a tension between what we want and how we make it work, between the requirements in the world and their realization in the computer, between the subjective and the objective, the conceptual and the formal. This book seeks to resolve that tension.

Science faces a similar problem, and so I start by examining its solutions. Science begins with something very complex and poorly represented—the real world—and its goal is to describe aspects of that reality with theories and models. We know that science is successful. It is reasonable to look, therefore, into its strengths and limitations for insight into resolving the software process' central tension.

 

왜 과학철학인가?

The philosophers of science study the scientists' actions and characterize what science is and how it ought to be conducted.

본문의 내용은 안 읽고 가는 것이 정신 건강에 좋을 것 같습니다. 이번 기회에 과학철학에 대해 관심을 가졌고, 그와 관련된 책 한 권 정도 읽은 것으로 만족하고 넘어가겠습니다.

 

과학철학을 살펴본 저자의 결과는 무엇인가?

This brief introduction to the philosophy of science holds no hope for the discovery of any preexisting guidelines for computer science. We must design our own science, and its criterion for success will be how well it serves us.

 

 

RSMer's Page

과학은 관찰자의 입장에서 시작하는 것으로 창조에 대한 추측을 할 뿐입니다. 추측을 통해 답을 구하는 것은 쉽지 않습니다. 그래서 과학은 최선의 방법이 될 뿐입니다.

소프트웨어 개발은 생성과 사용에 대한 것입니다. 문제영역인 도메인은 사용의 관점을 강조하고, 해결책 영역인 소프트웨어는 생성의 관점을 강조합니다. 저자가 말하는 tension은 생성과 사용이 무엇인지를 알고 그들이 어떻게 관련되는지를 알면 해소됩니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
prev"" #1 #2 next

티스토리 툴바