진행 중인 공공 프로젝트

현재 Half million 짜리 공공분야의 BPM 구축 프로젝트를 하고 있다. 여기서 맡은 일은 소프트웨어 구축 이전에 프로세스 설계 및 업무 디자인 그리고 이와 관련된 소프트웨어 아키텍처 구축이다. 이때의 소프트웨어 아키텍처는 웹서비스 기반의 유연한 구조가 가장 중요한 부분으로 이 프로젝트의 핵심이다.

아쉬운 것은 RUP를 사용하는데 전체 개발자가 7명 밖에 안된다는 것이다.

RUP에는 원래 업무 프로세스를 정의하는 단계가 비중있게 다루어지지 않아서, 산출물 및 개발 프로세스를 정의하는 단계가 쉽지 않았다. 다행이 다른 개발자들이 나의 업무를 많이 맡아 주어서 어렵사리 다른 개발프로세스를 정의할 수 있었다.

개발 프로세스를 어느정도 다시 정의하긴 했지만...
7명의 개발자에 효과적인 RUP를 한다는 것은 현실적으로 많이 부담이 되었다. 특히나 개발 기간이 짧아 산출물 중심의 개발을 해야하고 신기술을 사용하여 개발자들의 가파른 Learning Curve에 따른 시간적 비용을 생각한다면 더더욱 어려운 면이 있다.

공식적으로 XP를 적용하지는 못해지만,
어느새 뒤를 돌아보면 매우 잦은 회의와, 코드의 공유 (사실 여기에는 CVS의 사용하면서
Commit을 자주하여 새로운 부분의 코드를 공유하자는 의견이 있었고 모두 동의한 탓이 컸다.)
그리고 잦은 단위 테스트가 있었다.

의도하지는 않았지만, 나와 개발자들의 프로젝트 진행 패턴이 어느새 XP적으로 되어가고 있었다. 아마도 산출물은 Fluxuation을 하면서 나올 것 같다.

Management of software reuse with Web services

- Technical issues doing XP #1 -

Software reuse has been a major issue on how to cut down the cost of software project. The characteristics of software components are inherently different with other industrial products in the aspect of reuse. Although pieces of software component that show similar functionality, a subtle difference how their interface is implemented or which language they were developed with makes these components totally distinguished things from each others with the view point of management. Since which module can communicate with this component or how this can be merged into new software would determine the cost required and tasks of building components, the manager of software project regards these characteristics related to the reuse as important factors that affect the whole project.

Evolution of technology has something to do with this issue indirectly or directly. Implementers of software solutions have been trying to find better ways to deal with reusability, connectivity, and usability to mention. Re-usability processes and concepts have brought to bear a new way of developing solutions, where the elements of the system are scattered all over the world or local area network. System construction mostly deals with the exploring, finding and usage of ready-made functionality. This functionality could have been created by an organization’s developers or might have been borrowed or bought from a provider of the functionality. One of questions that need answering is: how developers make component feasible and have compatibility for extension to other module to decrease the cost of project and increase the flexibility of the product.

Object orient language makes it possible that we can isolate functionality as component and engraft portability. But in many cases, we have faces its limitations that do not allow globally interoperable communication. The two components from different technology don’t talk each other. Bean from EJB has no way to be merged into COM from Microsoft, because of its different language and protocol spec. Low level standardization such as language specific protocol does not provide advantages in varies organization using various technology. With higher level of concept then implementation specific languages, managers want to focus on business more. It is web services technology that emerges satisfying this requirement in some degree. In this paper, I will write on what are web services and how to utilize this technology with the view point of reuse. The software reuse, consequently, allows us to concentrate on the designing of business model rather than implementation itself. Managers now need to prepare to set up strategy that reveals the factors on cost-downing management and effective maintenance of project using this technology. I will discuss what should be considered to achieve effective adoption of this reuse-allowable technology and how to reduce cost with maintaining or increasing of quality of product by adopting this web services in STP project as an example.

The whole report is linked, password for pdf is "park"
Management of software reuse with Web services.pdf

The Effect of the metaphor on development

Metaphor was the least understood of all 12 practices of XP. This lack of concrete definition has made us uncomfortable in the initial stage of the project. Some of members grumbled that why we should prepare metaphor on our project when the due for assignment of metaphor was coming. That was because I and other members spent already huge amount of time to understand the requirement from the paper and we finally became able to get relatively concrete concept of the “Probe” system. But If the paper had contained a kind of metaphor it’s system, then we could have understand easier and we don’t have to trouble of finding satellites related papers for two days to understand what the “experiment” implied.

Anyway we prepared metaphor for the probe system. We actually didn’t utilize the terms much in our metaphor during the project. However since I was not familiar with the probe system, I kept them in mind when I implemented the specific part which I frankly didn’t understand practically. Although there were not such things that without metaphor it was impossible or very hard to implement, it did help me to understand the probe system easily.

Whenever my pair would say, “How do you plan to order a command to attitude computer” or “How could I implement the command module.” The word “command” in the sentence sounded like the command from a team leader of “Expeditionary team.” And also when I said “command”, in some degree it meant the command of the metaphor. Probably my pair must understand that term in the same line with me
Metaphor has been like picture over drawn on the jigsaw puzzle that leaded us to put the puzzle together in additional to the hard clue of the shape of the puzzle.

In the end, if it were the project on the more complicated and unfamiliar system, we might have failed the project without metaphor which made the communication with other members effectively. It might be really as hard as we would put jigsaw puzzle together without picture on it.

An Essay when I met XP for the first time

It’s my first time to adopt agile process, XP, formally trying to follow all 12 practices among many other, so called, agile methodologies such SCRUM, Crystal and so on. Through my past projects, I have realized that even a group of strong players can fail badly if they didn’t work as a tem. In terms of this, I set the highest priority at the co-work through continuous communication supported by some XP practices.

At the beginning of the project, the “Simple Design” which we followed first gave us many valuable opportunities with which we could cope with unexpected situation. The first one was member change, which required us to explain whole design or plan to new member. But at that time what we have done was no more than entity design and small bunch of implementation, there were no complicated things. As a result, this simple design makes it easier not only to communicate with new member, but also to talk with original members. We designed simple and did everything simple. I insisted that we don’t have to adopt complex IDE tool such as “ECLIPS” as long as it is not required. By the end of the project all that we utilized was “java.exe” and “notepad.exe” at the command line. But doing simple didn’t mean we implemented small amount. In spite of small amount of code, my pair coded almost every day and the total amount of code was over 1000 lines including discarded codes. Efficient communication encouraged us to have collective ownership to the degree that at the end of this project whoever of my team could explain whatever it is about the project.

This simple design unconsciously help me do work with sustainable pace. This moderate pace conserved my energy and alertness, so that I didn’t feel burden throughout the project. Only exception of this rule, named, “40 hours work” is now when I am writing this essay.
As the essence of planning game is the division of responsibility between business and development, with a virtual customer – we are developers and customers at a time until cycle 2-, with short iteration and frequent releases, planning game have us get used to the rhythm of the project. I didn’t lose a sense for how fast my pair is going. Based on this sense, my pair was able to determine how long our project will take. If it had been engaged with real budget, I could have guessed how much it would cost better.

Testing was executed basically twice at a time before and after integration. For this we used nonblocking source control that could be realized by both parts of pair’s having whole test skeleton which always properly work without any change of other part’s module, because as far as this project was concerned, the integration was about communication by socket. It’s hard to test and integration continuously in limited time but it gave us bug free production. In the long run, XP was very impressive and helpful in that we could realize important factors in project by letting us following 12 practices which earlier I have been thought trivial. And it was successful.

Several questions on XP

1. Why do we want the manager to make all decisions.
A. If the manager does, we don’t have to communicate for that and can be free from the responsibility for the decision.


2. What does the coach do?
A. As a development partner, the coach would be available
B. Sets long term refactoring goal and help developers make good refactoring to the right way toward the goal.
C. As a technical supporter, the coach help the individuals do their roles such as testing, refactoring,
D. Explains the process the upper-level manager


3. What event would demand intervention?
When serious problems which can be solved by members or as current status are occurred such as
A. Critical technical problems
B. Personnel changes
C. Wrong development direction


4. What characteristics does a XP workspace have?
A. The XP team members need to be able to see each other to hear other’s sudden question and answer freely. For this, wall between members should be low enough to talk each other.
B. When a member programs, it should be open to other members. All the machine for development is put in open space.
C. There might be private space where members may make phone calls and do something private things.
D. To refresh members and other objectives that we talk each other in informal way gathering without specific formal intention, we need to reserve small space that has couches, some toys and so on


5. What are the items “business” is best suited to decide ?
A. The scope or timing of release with the business aspect
B. The relative priorities of proposed features according to the clients’ needs
C. The exact scope of proposed features
D. The final technical decision that is already revised by technical manager and proved to the thing that selecting one things or another has no differences in technical aspect.

Fundamental concept of object

From object-oriented language such as C++, small-talk and java to architecture such as CORBA, COM, EJB have a object concept as their basic model. Basically, the concept of object currently accepted as architecture things might be defined simply as models of entities or concepts. For example, an object can model an animal, a date, an employee, a particle (whatever), or even a compiler. The important characteristic if an object is its identity, which is fixed for the life of the object regardless of the object is its behavior or properties. This identity is represented by an object reference.

And the concept that helps the object as accessories are the operations and interfaces. An operation is a behavior offered by an object that is known to the outside user. The action of sending request to an object is equivalent to the action of invoking an operation on an object. This operation may cause some changes in the encapsulated state of the object. Generally, interface is a collection of operations offered by that object. The three models mentioned above are same with this definition.

Object itself can be inherited by its behavior. The inheritance concept in object might be come true various ways. Through the inheritance of interface, CORBA and EJB do this. And COM model does this by object aggregation or containment.
Object has life time that can be subjected under its properties or controlled by outer policy. During the incarnated state of object, it can retain its status information or does not possess its data despite of its active state. Depending on this properties object can be divided by state and stateless object. And also, to sustain data out of its lifetime, object can use other repository for its persistency.

As result, including that object a model of entities or concept, four things mentioned above - identity, interfaces, inheritance, lifetime- can be fundamental concept.

The IMI Process

In Step 1 of the approach, the major architectural elements, i.e. component, connector, ports and constraints in CCA, are assumed to be composed of objects and their relationships. Mapping a CCA architecture to implementation elements is a key activity in this step. In this activity, how to realize these elements is considered based on the architectural elements identified. For connector, many implementation approaches can be applied. For example, to transfer a simple string from a class to another class, a string buffer can be used and to transfer complex data types from a process to another process, socket communication or middleware can be used. Depending on the implementation choices of connectors and components, implementation of the ports may become different. For instance, the use of middleware requires the ports to be the message sender instance or the message receiver instance of the middleware.
In Step 2, once the implementation elements per each architectural element have been decided, the functional and non-function requirements are distributed among architectural elements. Distributing non-functional requirements to architectural elements is not as simple as with functional requirements because quality attributes that represent non-functional requirements can be supported both implicitly and explicitly by the architectural elements. When an architectural element is used in order to support a specific quality attribute, the attribute can be assigned to the element.
Step 3 consists of three sub-steps. In Step 3A, for each functional requirement, objects that are needed to satisfy the requirement has to be identified. Of course, it is sufficient to identify the objects within the component boundary according to the baseline assumption of this approach. At the same time, the simple relationship between the objects can be considered briefly.
And in Step 3B, OO design patterns are considered. A design pattern gives us a generic solution that solves a family of recurring problems in a certain context [11]. The design patterns listed in Table 2 are the candidates that can provide a proven way to realize the architectural elements.
This step is required because OO design can be difficult without applying design patterns. Also, by considering proven design patterns before starting design developers can make better designs than by considering them later. Considering the quality attributes and requirements, the patterns that can be applied to the components for the Metadirectory system can be listed up as in Table 2.
Lastly, in Step 3C, the objects identified and the relationships between them are rearranged based on the selected design patterns. The basic method invocation sequence of an object can be determined from the design patterns and also the base-line of object relationships are rearranged based on the patterns.

IMI Approach In XP

Some practitioners use Object-Oriented Design (OOD) itself as the architecture description of a software system instead of using the emerging architectural concepts and notations. Although some OOD concepts can be used to address some architectural design issues, and doing so is popular among software developers, there are significant differences in capabilities and benefits between them. The level of abstraction that the OOD paradigm provides does not cover all the aspects required for architectural design.
I propose a systematic method of developing OO designs from architectural designs that is consistent with the Component and Connector Architecture (CCA). In this method, an Intermediate Model (IM) is introduced between the architecture model and OO design to narrow the gap between the two widely different abstraction levels. I call this the Intermediate Model Introduction (IMI) approach. We apply the IMI approach to an industry project to demonstrate the method and to show its efficacy.

프로젝트 초기 단계에서의 교육

프로젝트 초기 단계에서 프로젝트 전반에 대한 프로세스(engineering process or managerial process)에 관해서 교육을 들은 적이 있습니까?

규모가 좀 큰 경우는 간혹 프로세스에 관한 교육을 하고 서로의 지켜야할 사항에 대해서 곰감대를 가지는 경우가 있던데, 대부분의 경우 그냥 시작... 저의 크고 작은 약 20여 번에 걸친 프로젝트 경험에 의하면 그러했습니다. 운 좋게 금융, 공공, 학교, 개인, 통신의 프로젝트를 골고루 해볼 경험이 있었는데. 프로세스에 대한 교육을 제대로 해본 경험은 없었습니다.

요구사항이 없었기 때문이 아닌가 하는데, 고객이 원하는 것이 산출물이었으므로 그외의 것은 모두 무시되거나 경시되는 분위기였습니다. 일반화의 오류를 각오하고 말한다면.. 모두가 거의 이렇지 않을까요?

예전에는 이런 현실을 탓했습니다. 왜냐면 프로세스는 품질을 위해서 지켜야할 가장 기본 적인 것이거든요. 성질이 급한 탓인지 품질을 위해서 프로세스를 중시하는 것이 아니라 품질을 논할 그 주체 산출물에만 너무 신경을 쓰는 그런 분위기에 많이 아쉬워 했던 것도 사실입니다.

그러나 한발 뒤로 물러나 생각해 보면, 프로세스를 중시하는 것은 아마도 영원히 이루기 힘든 일이지 않나 싶습니다. 그 이유에 대해서는 다음에 좀 자세히 더 이야기하기로 하고.. 현실을 고려한 해결 책은? 이라는 질문에 수백 페이지에 달하는 프로세스 핸드북을 가진 기존의 방법론은 그리 feasibility(!)가 있어 보이지 않습니다. 현장의 개발자들은 너무나도 바쁘고, 머리속과 마음속이 복잡하기 때문입니다. (머리속이 복잡한 것은 해야할 것이 많기 때문... 그럼 마음속이 복잡한 것은..아마도 잘못 길들여진 고객과 불합리한 하도급의 관행.. 때문이 아닐까요? 인터뷰에 응한 많은 개발자들이 머리속 보다 마음속이 더 복잡하다고 했습니다...)

서로 지켜야할 기본 원리만을가진 그런 방법론은 없을까? Kent Beck의 XP... 그 원리들은 소프트웨어 프로젝트의 가장 중요한 산출물인 코드에 촛점을 맞추고 있습니다. 현재 잘 돌아가는 소프트웨어 코드 뿐만 아니라 이후 의 필연적인 코드변경에도 능동적인 코드를 생산해 내게 하는 그런 원리들을 담고 있습니다.

진정한 성공을 원한다면 한번쯤 고려해 봐도 될듯..

UP and Architecture and OOD 

XP의 반론에 대하여

어느 책에선가 XP의 강점 중인 하나인 변화에 능동적이라는 것에 대해서

비판한 글을 읽은 적이 있다. 소위 말하는 해킹 신드롬에 빠질 수도 있다는 것.

 

고객의 말을 듣다보면 변화를 해야할 때가 있다. 그 변화가 또 다른 변화를

고려해두고 만들어 지기 때문에 XP는 변화에 매우 강하다고 하지만

뒤집에 이야기하면 항상 변화하는 것은 안정화와 거리가 멀기 때문에

해킹 신드롬이 주는 오류에 빠질 수도 있다는 문제가 생길 수 있는 것 처럼 보인다.

 

다행 스럽게도, XP의 변화는 변화를 위한 변화가 아니다.

변화에 닫힌 구조가 가지는 문제점이 없다는 의미가 오히려 더 강한 편이다.

변화에 열려 있다고 해서 항상 변한다는 생각하면 이건 오해에 가까울 것이다.

 

XP에서의 변화의 끝은 단위 테스트의 성공과 통합 테스트의 성공을 의미한다.

그러나 프로젝트가 끝났다고해서 그 소프트웨어가 더이상 변하지 않을 것이라고

생각하는 것보다 어리석은 것이 없다는 것을 염두해 두기 바란다.

 

basic XP seats 

시작하며

성공했다고 알려진 다수의 프로젝트가 진정 성공한 것들일까? 그 소프트웨어 시스템에 몇 년 후에도 여전히 성공이라는 단어를 붙일 수 있을까? 급변하는 IT 환경 속에서는, 성공한 프로젝트의 소프트웨어 시스템이라 하더라도 언제 어떻게 성공이라는 단어에 도전장을 받을지 모른다. 소프트웨어에서의 도전장이란 기본적인 품질 요소의 지속성뿐만 아니라 환경의 변화에 따른 시스템의 변화에 대한 요구를 의미할 것이다. 현재의 성공이라는 기준이 미래에도 성립하려면 겉 모습뿐만 아니라 미래에 대한 요구를 충분히 받아 들일 수 있는 요소를 가지고 있어야 할 것이다. 단순히 예측된 값만 성공적으로 출력해내는 시스템이 아니라 코드 하나하나가 변화를 받아 들일 수 있을 뿐 아니라 안정적이고도 유연한 구조를 가지고 있어야 한다. 다시 말하면 제대로 만들어져야 한다.

제대로 만들기 위한 방안을 한번 고민해보자..