Posted on April 10, 2009 by qnnp
RUP를 1년 넘게 접하면서 많은 점을 느꼈다. RUP가 Key로 내세우는 장점이 있지만 진행도중에 수많은 예외사항이 발생한다는 것이고 이는 어느 프로세스 다 마찬가지인것 같다. 그러나 이 수많은 예외사항에 대해 어떻게 해야하는지에 대한 지침이 모두 정확히 제공되지 않으므로 프로세스대로 진행하기란 어렵고 또한 프로세스가 장점으로 내세우는것을 모두 얻어내기란 힘든것 같다. RUP에서 중요시하는 몇가지 Key가 있다. 이는 SoC(Separation of Concerns), Auto and Daliy Build, Unit Test, Iteration 이다.
Read more »
Filed under: Uncategorized | Leave a Comment »
Posted on April 10, 2009 by qnnp
많은 프로세스와 많은 툴에 투자하여 프로세스와 툴에서 원하는 결과를 얻을 수 있을것이라 생각되지만 현실은 다르다. 팀의 모든 구성원이 프로세스와 툴에 대한 내재화가 부족하다면 정상적으로 프로젝트가 진행되지 않고 오히려 혼란만 가중될 뿐이다. 프로세스를 프로젝트에 정확히 적용시키며 툴에 대한 활용을 극대화하기 위해서는 모든 구성원이 프로젝트를 진행하는데 있어 한몸같이 움직일때 기대하는 성과를 얻을 수 있다. 모든 팀원의 내제화 없는 프로세스와 툴은 의사소통의 혼란을 초래할 뿐만 아니라 프로세스나 툴이 하나의 업무로 여겨지게 된다. 그 결과 프로세스와 툴이 오히려 프로젝트 지연의 원인이 되기도 한다.
Read more »
Filed under: Process | Leave a Comment »
Posted on November 11, 2008 by qnnp
There are several tip to be productive programer. Be summarized about productivity as programmer in developing and using software
- Concentrate on essence, not ceremony.
Concentrate on basic that is easy of use and effectiveness.
- The usefulness of an application list is inversely proportional to its length.
Use of application is in inverse proportion to count of application, if many applications are installed in your computer, list of application is complicated and finding application is difficult. Storage of computer is waste as installed many applications. If project leader force to use tools selected thoughtlessly, developer will confuse in practice of project.
Read more »
Filed under: Process | Leave a Comment »
Posted on November 5, 2008 by qnnp
Staged Delivery is a model of software development lifecycle. We usually used waterfall model. But waterfall model find serious problem to step of testing therefore maintenance cost is increased and schedule is delayed in the end of project. As a result iteration method proposed to resolve the problem in the software process. Iteration method repeats steps of requirements analysis, design, implements, testing to the unit of Concern. Therefore it find bug in the software as far as possible.
But it is difficult if you don’t know about whole domain because you can’t seperate the unit of module so you can’t develop the high priority module early.
Read more »
Filed under: Process | Leave a Comment »
Posted on October 11, 2008 by qnnp
software design is tool of communication with stakeholder. If design document exist just as document, it isn’t used by project members. This is just document. UML isn’t that image but that have to use communication tool. stakeholder have to understand the system through UML diagrams .
Read more »
Filed under: Architecture & Design | Leave a Comment »
Posted on October 2, 2008 by qnnp
Non-Functional Features
- Availability
- Performance
- Scalability
- Manageability
- Flexibility
- Portability
Read more »
Filed under: Architecture & Design | Leave a Comment »
Posted on August 16, 2008 by qnnp
Many people develop software through cooperation.Therefore developer has to define interface as a rule. Protocol is a rule for communication. Interface is a rule for software. The rule hasn’t to be modified developer’s way because it breaks a rule. If interface is defined and exposed in the outside, caller who just knows interface definition call it. Even if caller doesn’t know implements, caller can use interface. For example when you design framework of communication in the infrastructure layer, you can define it as interface. Module of application layer can use function through import. There are several check points. Read more »
Filed under: Architecture & Design | Tagged: Interface | Leave a Comment »
Posted on August 14, 2008 by qnnp
When you practice project, many documents are made by team members. It is made for an individual or output of process. Process requires many documents that have influence on work. But the problem is all of documents not need to project. Also traceability among documents is one of important points.
Read more »
Filed under: Requirements Engineering | Tagged: Documents, Traceability | Leave a Comment »
Posted on July 31, 2008 by qnnp
We can do many practice for easy of test. But it isn’t independent on the development, it has relation with development.
We can reduce cost of development through easy of test. Then let’s see several methods for efficient testing.
Read more »
Filed under: Test & Verification | Tagged: Testing | Leave a Comment »
Posted on July 28, 2008 by qnnp
개발이 완료되고 테스트를 무사히 마쳐서 제품이 출시되지만 실제 사용자로 부터 수많은 문제점이 발견되어 돌아오게 된다. 왜 그렇게 많은 테스트를 했음에도 불구하고 그러는 것일까? 테스터가 테스트를 잘못해서 그런것일까? 그건 아니다. 테스터는 정해진 품질 규격에 맞을때 까지 테스트 하였으며 모든 테스트케이스를 소프트웨어가 만족 했기 때문에 승인을 한것이다. 소프트웨어 테스트는 필터와 같아서 테스팅을 수행하는 동안 오류가 계속적으로 걸러지게 된다. 이 테스트라는 필터는 완벽하게 걸러내기란 불가능하게 된다. 일정이 결정되어 있는데 계속해서 테스트만 할 수 없는일 아닌가. 적정한 수준에서의 합의가 필요한 것이다. ^^ Read more »
Filed under: Test & Verification | Tagged: Test | Leave a Comment »