이전 포스트에서 나왔던 "research question"을 포함해서, systematic literature review를 하기 위해 필요한 plan 과정에 대해 배우기 위해 읽은 논문.

정말 간략하게 읽었다.

5. Planning

5.1. 필요성

어떤 현상에 대해서 철저하게, 편향되지 않은 방법으로 모든 정보를 요약해보고 싶은 필요가 있을 때에 systematic reviews를 진행하게 된다. 리뷰를 진행하기 전에, 연구자들은 systematic review가 정말 필요한지 확실히 해야 한다. 특히 연구자들은 존재하는 systematic review 를 검토해보아야 한다.

-> 나는 "Android Static Analysis"의 최근 동향과 문제점에 대해서 알고 싶어 논문을 작성하게 되었고, 현재 시점(2022.1.)을 기준으로 가장 최근 서베이 논문은 2017년에 진행되었으며, 국내 논문 기준으로 해당 주제에 대해 발표된 논문은 1개도 없다.

5.3. The Research Questions

research question을 구체화하는 것은 systematic review에서 가장 중요한 부분이다.

• 검색 과정은 research question이 포함되어있는 기초가 되는 연구들을 확인해야 한다. (기초가 되는 연구들을 먼저 본 후에 검색을 하라 이런 의미인 것 같음.)
• 데이터 추출 과정은 질문에 답을 하기 위한 데이터 항목들을 추출해야 한다.
• 데이터 분석 과정은 질문에 답이 되는 방향으로 데이터를 통합해야 한다.

Question Types

예를 들면,

• 기술의 영향력을 평가
• 기술이 받아들여지는 빈도나 수치를 평가하거나, 프로젝트 성공의 수치를 평가
• 기술과 관련된 비용과 리스크 요소를 식별
• 기술의 신뢰성, 퍼포먼스, 비용 모델 측면에서의 영향력을 식별
• 특정 기술이나 소프트웨어를 도입하는 데에 있어서의 비용적 이익 분석

질문을 설정하는 것이 가장 중요하다.

• 연구자 뿐만 아니라 실제로 사용하는 사람에게도 의미있고 중요한 것이어야 한다.
• (연구 결과가) 현재의 방식에 변화를 가져오거나, 현재의 방식의 가치에 자신감을 더해주어야 한다.
• 일반적인 믿음과 실제 사이에 차이점을 식별해주어야 한다.

그럼에도 불구하고, 연구자의 흥미에 중점적으로 질문을 하는 systematic review들이 있다. 그런 리뷰들은 미래의 연구 활동에 대해 식별하고 범위를 구체화하는 질문들을 한다. 예를 들면 PhD 논문으로의 systematic review는 연구 학생의 작업을 위한 현재의 기반을 식별하여야 한다.

Question Structure

의학 분야에서는 이런 식으로 평가한다.

• Population, intervention으로 영향을 받는 사람들.
• Intervention, 2~3가지 대체 치료제 사이에서의 비교
• Outcomes, 의학적 및 경제적인 요소들.

이걸 소프트웨어 엔지어링에 적용하면,
Population은, 아래와 같을 것이다.

• 특정 엔지니어들(테스터, 매니저)
• 소프트웨어 엔지니어들
• 응용 영역. IT 시스템, 명령, 제어 시스템 등
• 산업 그룹.

Intervention은, 특정 이슈를 처리하는 소프트웨어 방법론, 도구, 기술, 절차 등등이다. 이것을 꼭 Comparison 과정을 통해 기존에 사용되던 기술과 비교하여야 한다.

Outcomes는, 향상된 신뢰성, 감소된 생산 비용, 시간 감소 등등이 될 것이다.

Context, 대부분의 학계에서 이루어지는 실험에서는 학생 연구원을 사용하고, 조그마한 규모에서 실험을 수행한다. 이러한 실험은 산업에서 실제적으로 일어나는 것들을 대표하지 못한다. 특정 systematic review는 그러한 실험들을 배제하는 것을 선택해야할지도 모른다.

-> 나는 아래와 같이 research question을 설정하였다.
주제 : Android Static Analysis에 대한 Survey

• RQ1. Android Static Analysis에서의 Challenge는 무엇이며, 각각의 연구가 이를 어떤 식으로 해결하는지
• RQ2. 각 도구들의 정확성은 실제로 어떤지(벤치마크 셋에서)
• RQ3. 각 도구들이 정말로 실제 앱들에 적용 가능한지