The Object-Relational Impedance Mismatch

posted Jun 20, 2010, 9:15 PM by Kuwon Kang

The Object-Relational Impedance Mismatch 

처음으로 보게된 글이다.

데이터베이스의 테이블들을 객체로 표현할 때 생길 수 밖에 없는 임피던스 불일치에 대한 내용이다.

한번 쯤 깊이 읽어볼 만한 기사인 것 같다.

Unified Process

posted Jun 20, 2010, 9:13 PM by Kuwon Kang

Unified Process

From Wikipedia, the free encyclopedia

The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP).

Profile of a typical project showing the relative sizes of the four phases of the Unified Process.




The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The Rational Unified Processis, similarly, a customizable framework. As a result it is often impossible to say whether a refinement of the process was derived from UP or from RUP, and so the names tend to be used interchangeably.

The name Unified Process as opposed to Rational Unified Process is generally used to describe the generic process, including those elements which are common to most refinements. The Unified Process name is also used to avoid potential issues of copyright infringement since Rational Unified Process and RUP are trademarks of IBM. The first book to describe the process was titled The Unified Software Development Process (ISBN 0-201-57169-2) and published in 1999 by Ivar JacobsonGrady Booch and James Rumbaugh. Since then various authors unaffiliated with Rational Software have published books and articles using the name Unified Process, whereas authors affiliated withRational Software have favored the name Rational Unified Process.

[edit]Unified Process topics

[edit]Iterative and Incremental

Diagram illustrating how the relative emphasis of different disciplines changes over the course of the project

Software development process
Activities and steps
Requirements · SpecificationArchitecture · DesignImplementation · TestingDeployment · Maintenance
Agile · Cleanroom · Data modelIterative · RAD  · RUP  · SpiralWaterfall · XP · Scrum  · V-Model
Supporting disciplines
Configuration managementDocumentationQuality assurance (SQA)Software engineeringProject managementUser experience design
Performance analysisDebugger

This box: view  talk  edit

The Unified Process is an iterative and incremental development process. The Elaboration, Construction and Transition phases are divided into a series of timeboxed iterations. (The Inception phase may also be divided into iterations for a large project.) Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g.Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.

[edit]Use Case Driven

In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.

[edit]Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.

[edit]Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.

[edit]Project Lifecycle

The Unified Process divides the project into four phases:

  • Inception
  • Elaboration
  • Construction
  • Transition

[edit]Inception Phase

Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it is usually an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process.

The following are typical goals for the Inception phase.

  • Establish a justification or business case for the project
  • Establish the project scope and boundary conditions
  • Outline the use cases and key requirements that will drive the design tradeoffs
  • Outline one or more candidate architectures
  • Identify risks
  • Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.

[edit]Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an Executable Architecture Baseline. This is a partial implementation of the system which includes the core, most architecturally significant, components. It is built in a series of small, timeboxed iterations. By the end of the Elaboration phase the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the Construction phase. At this point the plan should be accurate and credible, since it should be based on the Elaboration phase experience and since significant risk factors should have been addressed during the Elaboration phase.

The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

[edit]Construction Phase

Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one becomes the start of a new iteration. Common UML (Unified Modelling Language) diagrams used during this phase include Activity, Sequence, Colaboration, State (Transition) and Interaction Overview diagrams.

The Initial Operational Capability Milestone marks the end of the Construction phase.

[edit]Transition Phase

The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations. The Transition phase also includes system conversions and user training.

The Product Release Milestone marks the end of the Transition phase.


posted Jun 20, 2010, 9:03 PM by Kuwon Kang

삼성 SDS Anyframe Enterprise IDE개발팀을 제가

팀원들과 함께 Eclipse OpenUp방법론으로 개발을 하고 있습니다.

총 6번의 이터레이션이 수행되었습니다.

이터레이션 주기는 1개월이었습니다.

현재는 후임자가 팀을 이끌고 있습니다.

XP+SCRUM+Lean을 다 섞어서 만든 Eclipse 방법론 입니다.

기본적으로는 SCRUM 틀과 비슷합니다.

다만 용어나 기타 몇 가지가 다를 뿐인데 몇 가지 효과적인 결과에 대해서
올려 봅니다.

1. Standing meeting
매일 아침 15분 이하 미팅을 하는데 팀원들이 매우 좋은 반응을 보입니다.
해야할 일과 문제들이 잘 정리되어서 좋다.
하루하루 집중할 수 있는 원동력이 된다.

2. Burndown chart.
Scrum에서 사용하는 방법인데 내가 해야할 일을(work items list)를 기간단위로
정리해서 개발을 하고, 실제 해당 계획(estimation)된 데이터를 개발자가 assign하여 개발시
시간을 업데이트 합니다. 더 늘어 날 수 도 있고 더 적어 질 수 있습니다.
하지만 남은 시간이 중요한 거죠. 끝내냐 못끝내냐, chart의 기울기가 떨어지지 않느냐? 머 이런
감독이 burndown차트를 통해 관리되니 프로젝트의 위험과 방향, 재 정비등과 같은 매우 큰 장점들이
있는 것 같습니다.

3. Pair programming.
정확히 이야기하면 pair programming은 아닙니다.
다만 제가 각각의 팀원들의 코드를 assist해주고 frame code를 짜주고 설명하고
개발을 리드하는 방식입니다.
장점은 기술을 잘 모르고 스킬이 부족한 개발자들에게 좋은 설계를 유도하고 코드 수준의
설계까지 도와주면서 디자인 패턴이나 리펙토링, TDD스킬을 높여주게 되어 결국 팀원들도
향상된 개발 스킬을 성장시킬 수 있게 되는 것 같습니다.

4. Review(Design, Code).
실제 개발 시 Design을 먼저하고 Review를 합니다. Architect와 개발자들이 함께 모여
설계의 장단점과 좋은 안을 제시하고 적용합니다.
Use case로 시작하여 Module View등을 만들고 실제 Class diagram까지 정리하는데 이를 통해
개발자들을 구체적인 설계까지 들어가도록 합니다.
Code리뷰는 팀원들이 개발한 코드의 위험성이나 유지보수 측면에서 가능성 있는 문제를 정리하고
실제Refactor할 수 있는 내용은 가능한 그 자리에서 제가 Refactoring을 시연합니다.
팀원들은 이 내용을 함께 토론하고 공유하게 됩니다.

5. 점진적 설계.
불필요한 설계는 하지 않습니다. 다만 핵심을 제대로 파악하고 설계하여 확장성과 변화에
초점을 마추고 고객이 제시한 내용을 설계하고 개발합니다.
명확하지 않거나 모호한 요건은 가능한 다음 ITERATION으로 넘기거나 연기합니다.

6. TDD & Refactoring
매우 좋은 것은 TDD의 파워입니다.
제품의 품질 뿐만 아니라 시너지가 나게 되면 개발을 떠욱 빠르고 쉽게할 수 있는
기반이 되는 것이 바로 TDD인 것 같습니다.
예전에 C++을 할땐 Visual Studio로 Refactoring을 하는 것은 거의 불가능햇습니다.
j2ee로 와서 Eclipse를 사용하더 보니 Refactoring의 힘을 다시한번 느끼게 됩니다.
사실 Refactoring을 잘 할 수 있는 건 Eclipse의 덕분이라고 해도 과언이 아닌 것 같습니다.
팀원들도 TDD와 Refactoring을 배우면서 매우 큰 배움과 개발의 도움을 얻고 있습니다.

7. Iteration
한달 단위로 개발을 진행하고 있습니다. 모든 개발 계획과 과정이 명확해져 개발
릴리즈 관리가 철저해집니다.
개발자들도 명확하게 그 기간을 이해하고 스스로 진행하게 되어 너무 좋은 것 같습니다.
중간 릴리즈들 통해 팀원들 스스로 긴장감과 집중력을 높이게 되고 Iteration일정에 대한
목표과 계획을 잘 인지하고 있어 매우 만족할 만한 Iteration결과가 나오는 것 같습니다.

물론 현재 조직은 OpenUp을 쓰기게 매우 적절한 환경을 가지고 있습니다.

진행을 하면서 느낀건 팀원의 능력과 철학, 자세가 애자일을 잘 이해하고 있다면
그 팀의 효율과 생산성을 캔트백이 이야기하는 것처럼 정말 상상을 초월할 것 같다는
생각이 자주 들곤 합니다.


1-3 of 3