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 .
Filed under: Architecture & Design | Leave a Comment »
Posted on October 2, 2008 by qnnp
Non-Functional Features
- Availability
- Performance
- Scalability
- Manageability
- Flexibility
- Portability
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 [...]
Filed under: Architecture & Design | Tagged: Interface | Leave a Comment »
Posted on July 16, 2008 by qnnp
아! 전봇대 선이 너무 복잡하다. 개발이 다 된 소프트웨어를 어느날 유지보수를 위해 열어 보았더니 너무 복잡해서 개발 당사자도 한참 소스를 분석하는 경험을 하셨을 것이다. 소프트웨어가 복잡해 지면 개발 뿐만 아니라 유지보수시 영향도가 커져서 오류의 발생율이 높아져 품질과 생산성을 떨어뜨릴 수 있다. 소프트웨어의 초기 버전은 나름 모듈화도 하고 심플하게 개발이 되었을 것이다. 그러나 계속적인 요구사항 변경과 디버깅 [...]
Filed under: Architecture & Design | Tagged: Architecture, Design | Leave a Comment »