SoC에 대해서는 많은 정의가 있지만 본인은 SoC를 쉽게 개발단위로 본다.   반복적 개발 기법에서 한스텝에서 개발 되어야할 단위이다.  그럼 왜 Concern으로 나누는가?  전체를 한번에 구현할 수 없으니 나누는 것이고 나누어서 개발하는 단위가 된다.  반복적 기법의 목적은 심각한 문제를 앞단에서 발견해서 해결하자는 것이고 그렇다면 앞단에 개발할 Concern은 중요성이 높은 Concern으로 선택하여야 한다.  그러나 이 중요성에 대한 기준이 없고 정말 중요하다는 것을 아는것은 어려운 일이다.  그렇다보니 Concern을 나누고 구현을 했음에도 문제가 뒷단에 발생할 수 있다.   Concern을 나누는 중요한 포인트는 두가지 크기와 중요도이다.  얼마나 적정한 크기로 나누냐에 따라 모듈간의 의존성 및 복잡성의 상관관계를 갖으며 중요도에 따라 크리티컬한 문제를 찾아 해결하는 시점을 결정하게 된다.  프로젝트의 불확실성을 최대한 낮추기 위한 노력이지만 이는 경험에 따라 차이가 날것이라 생각된다.   또한 개발 코드는 매일 빌드되지 않으면 살아있는 코드가 아니다라는 정의 아래 매일 빌드되야 되며 매일 빌드하기 위해서는 Auto 빌드가 가능해야한다.  Auto 빌드중 Unit Test 코드를 한번 수행하여 변경이 다른 모듈에 영향을 미치는지에 대한 유무도 체크하여야 한다.

그래서 새로운 프로세스와 툴을 도입하기 위해서는 반드시 교육이 선행되어야 하며 모든 구성원들의 수준을 동일하게 끌어 올려야 효과 또한 끌어 올릴 수 있다.   프로젝트 성격에 따른 프로세스와 툴의 선정과 선정된 프로세스와 툴에 대한 팀원의 내재화가 반드시 필요하다.

- 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.

- Eye Candy looks good but isn’t nutritious.
Programer have to think that i am making unless software.  You must always consider what benefit can you give user.

- Typing is faster than navigation.
We use mouse because of convenience of mouse in the GUI but keyboard is more faster than mouse
os software offer keyboard shortcut.  In spite of to offer menubar, there are shortcuts because typing is more faster than naviation.  Improvement in speed can be better productivity.  Gamer use keyboard shortcut in playing game.

- Context switching eats time.
there are many method to reduce time of context switching.  If so, when we show different view, keyboard and mouse are input task.  To change between keyboard and mouse regard as context switching so you have to reduce context swiching.

Software is modified frequently because view point between the teams is different.  Stakeholder try to reduce the gap.  To reduce the gap need process and method.  All of information are shared with team members.

- Availability

- Performance

- Scalability

- Manageability

- Flexibility

- Portability

There are many Non-Fuctional Features.  It is defficult to balance those features in the design of system architecture.  if system leave many logs for system maintainability, it can decrease performance.  It is import to balanace feature of system. there is trade off among features.

There are documents for report and It is not used after report. There haven’t traceability among documents; in this case the documents aren’t used because contents are different each other.  You have to make just necessary document.  Also you have always to consider traceability among documents to increase accuracy of requirements.  The documents are saved in the public repository for easy of share.  Team member have to notice changed facts to know the facts.  If you make documents without a purpose, the documents can’t give any advantage. As a result documents just become waste.  Traceability is one of important points.  For example, test case and design are made from requirements. It is based on code.  When requirements are changed, you have to reflect changed facts in the requirements specification.  Next test case, design and code must be changed base on requirements through process.  If you don’t that way, you can’t understand specification because content of documents is different each other.  As a result the documents aren’t worth.

We can reduce cost of development through easy of test. Then let’s see several methods for efficient testing.

Basic work is definition of requirements correctly and applies to test case.  Incorrect test cases make much confusion during the testing.  Requirements are changed by the customer on the development and testing.  Changed requirements tend to not apply to test case. As a result changed requirements aren’t tested by QA, it is just modified by developer. Changed requirements are applied to test case immediately to solve this problem.

Developer want to make software in own way, developer hate to point out own source code and feel source code to the work. Os source code is developed complicate and difficulty. It doesn’t consider to test and developer thinks testing isn’t related with him.

Software must been designed and implemented as testable architecture to easy of testing.  You can make Interface and Mock object to use in testing.  Relations of function have to simple and call depth have to reduce for unit test.  Debugging and analyzing of test result have to simple. These are considered with developer.   Improvement of testability is mission of tester, developer and all members.

테스트는 왜 어려운 것인가?  테스트가 어려운 이유를 몇가지 생각해 보고자 한다.

1. 너무 복잡한 기능의 조합.

- 시스템의 다양한 기능들이 존재하게 된다.  이 기능이 조합될 경우는 무수히 많은 케이스가 있는데 이 많은 케이스를 모두 테스트 할 수 없으므로 테스트 되지 않은 잠재 오류를 내포하게 된다.

2. 실 환경과 동일한 테스트 환경의 부재

- 테스트는 가능한한 동일한 환경에서 테스트해야만 잠재 오류를 많이 찾아낼 수 있으나 실제적으로 불가능한 경우가 많다.  고층 건물의 엘리베이터를 테스트 하고자 테스트용 고층 건물을 만들수는 없다.

3. 테스트 마인드 부재

- 테스트는 단순한 노동으로 생각하고 기피하는 경향이 많다.  정확한 테스트하기 위해서는 테스팅 방법론이나 시스템에 대한 이해가 바탕이 되어야 한다.  테스트를 기피하는 업무가 아니라 전문가로 인정하는 환경 뿐만 아니라 테스터 또한 전문가로써의 자질을 겸비해야 한다.

4. 계속적인 요구사항 변경

- 개발에서도 힘들어 하지만 테스팅에서도 힘든것 중의 하나가 계속적인 요구사항 변경이다.  요구사항이 변경되면 변경된 내용이 QE팀까지 전달되어 테스팅 오류를 줄여야 하나 급한 나머지 개발에서는 개발하고 이를 전달하지 않아 테스터가 잘못된 테스팅을 진행하는 경우가 있다.  이를 줄이기 위해 변경 프로세스안에서 신속하게 개발과 테스팅에 변경사항이 반영될 수 있도록 해야 할 것이다.

5. 시간적 제약

- 개발된 소프트웨어를 테스트하는데 충분한 시간 확보가 필요하여 개발 초기에는 넉넉하게 테스팅 계획을 수립하게 된다.  그러나 프로젝트가 지연되면 테스팅을 진행할 수 없어 테스팅 일정도 함께 지연이 된다.  그러면 개발 지연 만큼 테스팅 일정이 뒤로 밀려나야 맞지만 정해진 일정이 있으므로 테스팅의 일정이 줄여서라도 정해진 일정해 맞춰야하는 일정에 대한 압박이 있게 된다.  이렇게 되면 충분한 테스트를 하지 못하고 많은 오류를 안으채 출시가 되게 되고 이는 고스란히 소비자의 불만으로 되돌아 오게 된다.

이 외에도 테스트가 어려운 점이 많이 있다.  많은 경험과 기술을 겸비한 숙련된 테스터가 우리 소프트웨어 산업에서도 많이 생기기를 바란다.