Webex Meetings 도구 모음에 대해 운영 체제 및 브라우저 지원
매달 Webex Meetings 릴리즈는 테스트되며, 월별 출시되는 현재 미리 보기 및 모든 6개월 Windows 10 릴리즈에 대해 인증됩니다.
Webex Meetings 는 제한적으로 Windows Server 2012 R2 및 2016을 지원합니다. Webex 미팅, 생산 도구 및 데스크탑 응용프로그램에 대해 사용자에게 관리자 권한이 없는 경우, 관리자가 Webex Meetings 응용프로그램 및 생산 도구를 설치해야 합니다.
Mac OS X
FedRAMP-규정 준수 Webex Meetings 사이트에는 Mac OS 10.13 이상이 필요합니다.
Mac OS X 10.7부터 Apple은 더 이상 Mac 운영 체제의 일부로 Java를 제공하지 않습니다. 이전에 Webex Meetings 는 처음으로 사용하는 사용자가 미팅 응용프로그램을 다운로드하려면 Java 브라우저 플러그인에 의존해야 했기 때문에 Java를 설치하지 않은 사용자들은 미팅에 참여하기 어려웠습니다. Java에 대한 의존이 제거되었습니다. 대신 사용자는 작은 플러그인을 설치하도록 요청받게 됩니다. 해당 플러그인이 설치되면 나머지 미팅 응용프로그램 설치를 처리하고 미팅을 시작합니다.
Safari 6.X 및 Safari 7에서 처음으로 Events (기본형) 을 사용하여 이벤트를 시작하거나 참여하는 경우에 문제가 발생합니다. Webex 를 설치한 후 Safari는 이벤트를 시작하거나 참여하려고 하는 사이트에 대한 플러그인을 신뢰하도록 요구합니다. 이후 페이지는 새로 고침되지만 이벤트에 참여하지는 않습니다. 참여하려면 원래 선택한 링크로 돌아가십시오. 해당 위치에서 성공적으로 참여할 수 있습니다.
다음 Webex 서비스를 사용할 수 있습니다.
참석자에 대한 웹캐스트 모드는 Windows Server 2008 64비트, Windows Server 2008 R2 64비트, Mac OS 10.13 및 Mac OS 10.14를 지원하지 않습니다.
Webex Support는 2021년 4월 1일에 EOL(사용 종료)된 Java 클라이언트를 사용하기 때문에 Mac OS에서 더 이상 지원되지 않습니다.
Linux (Web App) (32비트/64비트)
OpenSuSE 13.x 이상
다음 Webex 서비스는 웹 앱에서 Linux에 대해 사용할 수 있습니다.
참석자에 대한 웹캐스트 모드는 OpenSuSE 13.x 이상, Fedora 18 이상, Red Hat 6 이상 및 Debian 8.x 이상을 지원하지 않습니다.
Webex Training (참석자)
Webex Meetings 웹 앱에서 Linux의 알려진 문제 및 제한 사항:
일부 Linux 버전을 사용할 때 Firefox에서 비디오, 내 컴퓨터로 전화 및 콘텐츠 공유 기능이 작동하게 하려면 사용자가 "Cisco Systems, Inc.에서 제공하는 OpenH264 비디오 코덱" 플러그인을 직접 설치하고 활성화해야 합니다.
WebRTC 화면 공유 API와 관련된 문제로 인해 콘텐츠 공유는 Wayland를 디스플레이 관리 시스템(예: Fedora 25 이상)으로 사용하는 Linux 버전에서 작동하지 않습니다.
H.264 코덱 문제로 인해 Fedora 28에서 비디오를 보내고 받는 기능은 작동하지 않습니다.
Linux 클라이언트는 종단 간 암호화에 대해 지원되지 않습니다.
Webex Meetings 데스크탑 앱에서 사용할 수 있는 Linux에 대한 추가 기능의 자세한 정보는 Web App 지원되는 운영 체제 및 브라우저를 참조하십시오.
Chrome OS 지원
Google Chrome OS에 대한 지원은 현재 Webex Meetings Web App(웹 기반 미팅 클라이언트 지원) 및 Webex Meetings Android 앱(다운로드할 수 있는 미팅 클라이언트 지원)을 통해 사용할 수 있습니다.
무엇이 지원되는지에 대한 자세한 내용은 Web App 지원되는 운영 체제 및 브라우저를 참조하십시오.
Webex Meetings 모바일 앱(버전 11.0 이상)은 Google Play를 통해 Android 앱을 공식적으로 지원하는 모든 Chrome 장치에서 지원됩니다.
최소 시스템 요구 사항
Windows
Internet Explorer 11 (32비트/64비트)
Edge 브라우저는 Webex Meetings , MT4 멀티터미널 시스템 요구사항 Webex Training, Webex Webinars , Events (기본형) 및 Webex Support에서 미팅, 이벤트, 교육 세션 또는 지원 세션의 시작 및 참여를 위해서만 지원됩니다.
Mozilla Firefox 52 이상은 Windows에서 완전히 지원됩니다. Firefox 51 및 이전 버전은 지원되지 않습니다. 해당 브라우저 버전에서 미팅에 참여하거나 미팅을 시작하려고 할 때 사용자는 이 정보를 설명하는 메시지를 수신합니다.
Mozilla Firefox ESR은 지원되지 않습니다.
Chrome 최신 32비트/64비트
Win Edge Chromium은 록다운 고객을 포함하여 모든 고객에 대해 지원됩니다.
Slido 통합(및 향후 앱) 및 Facebook 및 Facebook Workplace 실시간 스트리밍 기능을 사용하려면 Windows 시스템에서 WebView2 구성 요소가 필요합니다.
Mac OS X
Firefox 52 이상은 Mac OS X에서 완전히 지원됩니다. Firefox 51 이하의 버전은 지원되지 않습니다. 해당 브라우저 버전에서 미팅에 참여하거나 미팅을 시작하려고 할 때 사용자는 이 정보를 설명하는 메시지를 수신합니다.
소프트웨어 설계 시 요구사항의 개념 및 특징
.
소프트웨어를 설계할 때 요구되는 사항들이 있는데, 어떤 문제들을 해결하기 위해 제공하는 서비스에 대한 정보와 정상 작동되는데 필요한 제약조건을 의미한다. 이는 소프트웨어 개발이나 유지보수의 과정에서 필요한 근거와 기준을 제시하며 개발하고자 하는 소프트웨어 전반에 걸친 내용을 파악할 수 있게 하는 근거로서, 개발에 관여하는 모든 이해관계자간의 의사소통을 원활히 하는 것에 도움을 준다. 개발 대상에 대해 요구사항을 체계적으로 도출하고 이를 분석한 결과를 명세서에 정리하고 마지막으로 이를 확인하고 테스트하는 일련의 구조화된 활동을 통해서 요구사항이 개발되는데, 이런 과정을 요구사항 개발 프로세스라고 한다. 요구사항 명세서란 분석된 요구사항을 바탕으로 작성된 문서를 의미한다. 명세서를 작성할 때는 사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성되어야한다. 설계과정에서 잘못된 부분이 확인되면 그 내용을 추적할 수 있어야한다. 개발 프로세스가 해당 사업의 목적에 부합하는지, 예산은 적절하게 책정되었는지 등에 대한 정보를 수집하고 평가한 보고서를 토대로 타당성 조사가 우선 진행되어야 한다.
요구사항의 유형 및 특징
일반적으로 정의하는 내용에 따라서 기능 요구사항과 비기능 요구사항으로 구분하며, 기술 관점과 대상의 범위에 따라서 사용자 요구사항과 시스템 요구사항으로 구분된다. 기능 요구사항(Functional Requirements)은 시스템이 어떤 기능을 하고 무엇을 하는지에 대한 사항을 기술한다. 시스템의 입출력이 포함해야 할 내용과 시스템이 저장 또는 연산해야 할 테이터에 관한 사항도 포함한다. 시스템이 반드시 수행해야 하는 처리와 사용자가 시스템을 통해서 제공받기 원하는 기술에 관한 요구사항이다. 비기능 요구사항(Non-Functional Requirements)은 또다시 여러 종류의 요구사항으로 나뉘는데, 시스템 장비 구성 요구사항은 하드웨어, 소프트웨어 등의 시스템 장비 구성에 대한 요구사항을 나타낸다. 성능 요구 사항은 소프트웨어의 처리 속도와 처리량, 시간 등 성능에 관한 사항이다. 인터페이스 요구사항은 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항으로, 다른 시스템과 이 정보 교환에 사용되는 프로토콜과의 연계도 포함하여 기술한다. 데이터 요구사항은 데이터를 구축하는데 필요한 초기자료 구축 및 데이터 변환을 위한 데이터를 위한 요구사항이다. 테스트 요구사항은 구축된 시스템이 정상 작동하는지, 도입되는 장비의 성능을 테스트하고 점검하기 위한 요구사항이다. 보안 요구사항은 시스템의 데이터나 기능, 운영 접근을 통제하기 위한 요구사항이다. 품질 요구사항은 관리가 필요하거나 품질 평가 대상에 대한 항목에 대한 요구사항으로, 가용성, 신뢰성, 사용성, 이식성, 확장성, 정합성, 보안성 등으로 구분하여 기술해야 한다. 가용성이란 사용자가 해당 시스템을 사용자고자 할 때 언제라도 사용할 수 있는 정도를 의미한다. 정합성은 데이터의 값이 서로 모순 없이 일관되는 정도, 이식성은 다양한 하드웨어 환경에서도 해달 시스템을 운용 가능하도록 쉽게 수정할 수 있는지에 대한 정도이다. 확장성은 규모나 범위를 넓힐 수 있는 정도를 측정한 것이다. 제약사항은 시스템의 설계 구축, 운영과 관련해서 사전에 파악된 기술에 관한 법이나 제도 등에 대한 제약 조건을 말한다. 프로젝트 관리 요구사항은 프로젝트의 원활한 수행을 위한 관리 방법에 대한 요구사항이다. 프로젝트 지원 요구사항은 프로젝트의 원활한 수행을 위한 방법이나 지원이 가능한 사항에 대한 내용을 포함한다. 사용자 요구사항(User Requirements)은 사용자의 관점에서 접근했을 때 시스템이 제공해야 할 요구사항이다. 사용자를 위한 것이므로 친숙한 표현과 이해하기 쉬운 단어로 기술해야 한다. 시스템 요구사항(System Requirements)은 개발자의 관점에서 바라본 것으로, 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항을 정의한다. 사용자 요구사항과 비교해서 전문적이고, 기술적인 용어를 사용하여 작성한다. 소프트웨어 요구사항이라고도 한다.
수담연구소 공식 블로그
시스템 요구사항은 일반적으로 고객과 당신 회사의 마케팅 부서에 의해서 제공되지만 그 개발은 상당히 복잡하다 . 요구사항은 Preliminary TAC analysis, Human factors, Operator tasks, Operational hazard analysis, System hazard analysis, Safety verification 그리고 Operational analysis 와 같은 여러 소스로부터 올 수 있다 . 그것은 시스템 요구사항과 시스템 컨셉의 한 세트를 만들어 낸다 .
역주 ) 여기서 영어로 된 부분은 시스템 안전성 분석과 관련된 복잡한 용어들이어서 억지로 한글 번역을 하지 않고 영문 그대로 적었다 . DO-178 을 진행하기 위해서 시스템 안전성 분석에 대해서 잘 알고 있다면 좋기는 하겠지만 너무 방대하고 복잡한 내용들이다 . 일단 시스템 요구사항은 기본적으로 시스템 안전성 분석에서 출발한다는 점 , 그리고 그 과정이 상당히 복잡하다는 정도로만 이해하고 넘어가자 . ( 참고 포스팅: 29 DO-178과 System Safety (1))
소프트웨어는 시스템 설계에 맞도록 준수되어야 한다 . 함수를 분석해서 기술하고 아키텍처를 설계하라 . 모든 컴포넌트들을 보여주는 정의와 블록다이어그램과 함께 일반적으로 여러 개의 백업 프로세스들과 컴포넌트들을 보여주는 시스템 아키텍처를 설계하는 엔지니어들이 있다 .
예를 들어 우리가 작업했던 한 프로젝트는 운송용 항공기상의 모터컨트롤러에 대한 시스템이었다 . 그것은 환경 시스템의 컨트롤을 위한 FPGA 였다 . 비록 시스템 설계는 이루어 졌지만 소프트웨어 요구사항이 아직 개발되지 않은 상태였다 . 프로세스의 출력은 확실히 시스템 기능 요구사항 데이터이다 . 일반적으로 우리는 이것을 고객으로부터의 요구사항 , 즉 시스템이 무엇을 하기로 되어 있는가에 대한 것이라고 생각한다 . 어떤 경우에는 시스템 요구사항을 개발하고 설계하며 그것의 타당성을 확인하는 조직이 있을지 모른다 . 실제 물리적인 제품 혹은 프로토타입이라도 가지는 것이 도움이 된다 . 왜냐하면 타당성이 확인되거나 증명되지 않은 요구사항들로 소프트웨어를 개발하는 것은 어렵기 때문이다 . 요구사항에 대한 타당성 입증은 단지 소프트웨어 레벨에서가 아니라 시스템 레벨에서 수행된다 .
시스템 기능과 요구사항 정의
HW, SW 그리고 인터페이스의 통합
시스템 기능 요구사항 데이터
시스템 아키텍처와 설계 데이터
확인 / 검증 그리고 시험 결과
프로세스 동안에 생성된 문제점 리포트
Systems Accomplishment Summary
단지 하드웨어와 소프트웨어 개발뿐만 아니라 시스템에 대한 요구사항 개발 과정에서도 문제점 리포트가 생성된다 . 시스템 엔지니어들은 시스템 레벨 문서를 추적하는데 익숙해야 한다 .
또한 System Accomplishment Summary 가 있다 . 이 데이터는 전체 시스템 개발과 확인 그리고 시험 단계 동안에 달성된 것들을 취합한다 . FAA 는 시스템 명세 프로세스에 대해서는 ( 소프트웨어에 대한 DO-178B 와 같은 ) 요구사항을 가지고 있지 않다 . 그래서 그것은 어떤 시스템들이 항공기에 탑재되는지를 말해주는 제품에 대한 인증 계획에서 참조된다 . 그리고 그들은 소프트웨어 관점에서 당신에게 필요한 모든 것들이라고 할 수 있는 ATP, DO-160 그리고 시스템 레벨 통합과 시험을 포함하는 시스템 검증을 요구할 것이다 . 소프트웨어 검증뿐만 아니라 시스템 상위 레벨 시험이 당신 전략의 일부가 될 수 있다 .
역주 ) 여기서 중요한 것은 시스템 요구사항은 공식적으로 DO-178 의 일부가 아니라는 점이다 . 저자의 말처럼 그냥 참고하는 자료일 뿐이고 거기서 소프트웨어 위험레벨만 잘 받아올 수 있으면 된다 . 일종의 참고자료로만 활용되는 것이다 . 그리고 또 하나 중요한 점은 소프트웨어에 대한 시험을 할 때 , 시스템 레벨에서의 시험이 중요하다는 점이다 . 소프트웨어 레벨에서만 시험을 하게 되면 완전한 시험이 될 수 없다 . 소프트웨어가 탑재된 시스템에서 그 소프트웨어의 기능이 확인되어야 제대로 된 시험이 된다는 의미이다 . 시스템에 대해서 설명하는 이번 절 전반적으로 이런 철학이 기반이 된다는 점을 기억하자 .
시스템 요구사항 상세 . 시스템 안전성 분석은 우리에게 안전성과 관련된 요구사항을 제공한다 . 일단 두 개의 프로세스가 완료되면 하드웨어와 소프트웨어에 대한 할당이 이루어 진다 . 어떤 요구사항은 중복되고 따라서 하드웨어 혹은 소프트웨어 어느 쪽으로든 혹은 필요하다면 양쪽 모두로의 추적이 이루어져야 한다 . 이에 대한 다양한 방법들이 있다 . 어떤 사람들은 그저 시스템 요구사항을 하드웨어와 소프트웨어로 분리하고 구분해서는 요구사항에 대한 스펙을 만들어 낸다 . 만약 당신이 툴을 사용한다면 그것은 가장 좋은 방안이다 . 만약 DOORS 를 사용한다면 당신의 표에 또 다른 칼럼을 생성하고 소프트웨어와 하드웨어를 구분한 다음 나누어서 관리하라 . 만약 당신이 하나의 프로세스로써 문서를 사용한다면 분리된 문서를 작성하라 . 그러한 모든 요구사항들은 시스템 요구사항과 설계로의 추적성을 가지고 있어야 한다 .
시스템 요구사항 할당
만약 당신이 할당 프로세스를 하고 있다면 그것이 전이 시점이다 . 진입과 진출 기준은 무엇이었는가 ? 당신은 그런 기준 혹은 전이 프로세스를 만족했는가 ? 만약 요구사항을 작성할 수 있는 시스템 요구사항 기술자 혹은 시스템 엔지니어를 발견한다면 그 사람에게 돈을 더 많이 주고 계속 옆에 두어라 . 그는 정말 그럴 만한 가치가 있다 . 시스템 요구사항을 작성하는 것은 단지 과학적인 방법이 아니라 하나의 예술이다 .
역주 ) 중간중간 ‘ 전이 ’ 라는 말이 나온다 . 한글로 번역하면 좀 어색한데 쉽게 말해서 개발과정의 한 단계에서 다른 단계로 넘어간다는 말이다 . ‘ 설계 ’ 단계에서 ‘ 코딩 ’ 단계로 넘어간다와 같은 식이다 . DO-178 에서는 이렇게 한 단계를 넘어갈 때 정해진 기준을 만족하고 그것을 증명할 증빙을 제출해야 한다 . 원칙적으로는 기준을 만족하지 못한다면 다음 단계로 넘어갈 수 없다 .
잘 작성된 요구사항이 핵심이다 . 당신은 그것을 요구하지 않으면 필요한 것을 얻지 못할 가능성이 많다 . 만약 시스템이 구체화되지 않으면 엔지니어는 자신의 방식으로 구체화할 것이다 . 만약 어떤 것이 50ms 의 사이클로 구동해야 한다면 그렇게 분명히 언급하고 특정되어야 한다 . 마음속에 특정 사이클을 가지고 있을 때에는 “ 빠르게 ” 라는 말을 사용하지 마라 .
역주 ) 개발자라면 실제 현장에서 코딩을 할 때 각자가 알고 있는 것을 머릿속에 떠올리고 그것을 기준으로 코딩을 하는 경우가 많을 것이다 . 가만히 생각해보면 그런 식으로 코딩을 하다 보면 어떤 값 (value) 과 관련된 부분을 코딩해야 할 때 대충 짐작으로 값을 생각해서 코딩하게 되는 경우가 있을 수 있다 . DO-178 에서는 이것을 허용하지 않는다 . 만약 그 값을 모르겠다면 팀장 혹은 책임자에게 근거를 물어보고 확인해서 근거를 가지고 코딩을 해야 한다 . 위의 설명은 바로 이런 부분을 이야기하는 것이다 .
“ 잘 작성된 요구사항은 모든 종류의 시스템에 핵심이다 . 당신은 요구하지 않으면 당신이 원하는 것을 얻지 못할 가능성이 높다 .”
Ian Alexander, Richard Stevens
“ 어떤 제품의 품질은 MT4 멀티터미널 시스템 요구사항 MT4 멀티터미널 시스템 요구사항 그것에 투입되는 원재료의 질에 달려있다 . 빈약한 요구사항으로는 훌륭한 소프트웨어를 만들어 낼 수 없다 .
Karl E. Wiegers
각각의 요구사항은 적절하게 끌어내고 분석되고 문서화되고 검증되어야 한다 .
각각의 요구사항은 정확성 , 타당성 , 필요성 , 우선순위 , 모호하지 않음 그리고 검증가능성과 같은 요구되는 특성들이 평가되어야 한다 .
품질은 원재료에 의지한다 . 따라서 빈약한 요구사항으로는 훌륭한 소프트웨어를 만들어 낼 수 없다 . DO-178B 는 요구사항으로 시작하고 당신은 요구사항으로부터 소프트웨어를 작성한다 . 그룹의 조직화된 이론이 수행될 때 일부 시스템 엔지니어들은 요구사항을 요구사항툴에 작성하기를 원한다 . 그렇게 할 수 있다면 우리는 개발 사이클에서 잘 진행되는 것이다 . 시스템 엔지니어들은 데이터를 변경하기 위한 요구사항을 추적하지 않거나 문제점 리포트를 작성하지 않음으로써 개발 프로세스의 사이클을 줄이기를 원할 지 모른다 . 하지만 이것은 많은 문제점을 낳을 것이다 . 시스템 엔지니어들은 프로세스를 정의하고 따라야 한다 . 각각의 요구사항은 적절하게 유도되고 분석되고 문서화되고 검증되어야 한다 .
역주 ) 사실 개발에서 요구사항의 중요성은 누구나 인정할 것이다 . 하지만 현실에서는 그 중요한 요구사항이 단순히 문서로 정리하는 것 만으로 끝나는 경우가 많다 . DO-178 은 요구사항에서 출발해서 요구사항으로 끝이 난다 . 그 만큼 모든 과정이 요구사항에 기반해서 돌아간다는 말이다 . 그런데 현장에서 보면 DO-178 을 진행하면서도 이를 명확하게 인식하지 못한다는 느낌을 많이 받게 된다 . 지금까지 해 오던 대로 똑같이 진행하는 것이다 . 이런 자세로는 인증과정을 제대로 거칠 수가 없다 . 대충하면 되겠지라고 생각하고 넘어가다가는 모든 것을 다시 처음부터 시작해야 할 수도 있다 . 돈도 부족하고 시간도 부족한 개발 현실에서 이는 모두에게 불행한 상황을 만들게 될 것이다 .
정확성 – 기능이 명확히 전달될 수 있도록 정확하게 작성되어야 함
실행가능성 – 시스템과 환경의 알려진 허용치와 제약내에서 구현가능해야 함
필요성 – 실제 “ 고객 ” 의 필요성 혹은 외부 장비 , 외부 인터페이스 혹은 표준을 준수할 필요가 있는 것을 문서화해야 함
우선순위 – 필수인가 ? 얼마나 필수인가 ?
모호하지 않음 – 한 사람이든 여러 사람이든 요구사항에 대해서 오직 하나의 해석만이 있어야 함
검증가능한 – 각각의 요구사항이 제품에 제대로 구현되었는지를 확인하기 위해 디바이스상의 시험 혹은 검사 , 시연과 같은 접근이 가능해야 함
소스로부터 요구사항으로 추적가능해야 한다 !
역주 ) 위의 내용은 DO-178 에서 요구사항 작성의 원칙이다 . 하나의 요구사항에 대해서 위의 원칙을 대응시켜봤을 때 모든 것에 대해서 ‘OK’ 라고 할 수 있어야 한다 . 쉬울 것 같지만 절대 쉬운 것이 아니다 . ( 참고 포스팅: 1. DO-178과 소프트웨어 요구사항(Software Requirements))
모든 요구사항은 우선순위가 필요하다 . 훌륭한 아키텍처 설계에서 시동에 대한 요구사항은 첫 번째 우선순위를 부여받는다 . 만약 이성적인 두 사람이 요구사항을 보았을 때 그들 사이에 모호함이 없어야 하며 동일한 답을 얻어야 한다 . 만약 요구사항이 검증받을 수 없다면 제대로 작성된 것이 아니다 . 요구사항을 보았을 때 그 요구사항에 대한 시험을 작성할 수 있어야 한다 .
파생 요구사항은 엔지니어링 경험에서 그려진 설계 결정사항이지만 정당성이 필요하다 . 이러한 파생된 기능들이 구현될 것이다 . 시스템에 포함될 코드는 하위레벨 요구사항으로 추적되어야 한다 .
역주 ) 설명이 좀 중구난방인 느낌이 있지만 어쨌든 여기에서도 DO-178 요구사항 작성의 원칙을 설명하고 있다 . DO-178 만의 고유한 항목으로 파생요구사항이라는 것이 있는데 이것은 상위레벨 요구사항으로의 추적성을 가지고 있지 않은 일종의 독자적인 요구사항이다 . 자세한 설명은 다른 곳에서 나오겠지만 고객이 요구하는 것이 아니라 개발자가 자신들의 필요에 의해서 ( 대체로 설계과정에서 선택되는 경우가 많다 ) 정의하는 요구사항이라고 설명할 수 있다 .
그리고 위에서 “ 하위레벨 요구사항으로 추적되어야 한다 ” 는 것은 소스코드가 하위레벨에 근거해서 작성되는 것이기 때문에 파생된 기능에 대한 소스코드는 하위레벨 요구사항 중 파생요구사항과 추적성으로 연결되어야 한다는 말이다 .
이것은 정의와 의미의 세계이다
당신의 계층을 이해하라
내가 소스 일부를 가지고 설계 내용을 작성한다고 가정해보자 . 그것이 요구사항인가 ? 누가 말하느냐에 따라서 다를 것이다 . 누군가는 그렇다고 말하고 반면에 우리는 그렇지 않다고 말하고 싶다 . 그것은 하나의 설계 내용이고 소프트웨어 개발자에게 맡겨야 할 부분이다 . 설계는 반드시 코드 이전에 작성되어야 한다 .
역주 ) 소스코드를 가지고 설계나 요구사항을 작성하는 것은 리버스 엔지니어링이라고 할 수 있다 . DO-178 에서도 그것이 가능하다 . 그런데 리버스 엔지니어링을 실제로 진행하는 케이스를 보게 되면 대체로 설계와 요구사항이 코드를 그대로 따라가는 경향이 있다 . 설계든 요구사항이든 이런 식으로 작성하는 것은 좋은 방법이 아니다 . 원칙적으로 설계는 코드 이전에 작성되어야 하는 것이며 따라서 리버스 엔지니어링의 결과도 그런 형태로 설계와 요구사항이 작성될 수 있어야 한다 . 물론 실제로 진행하기에 상당히 어려운 작업이 아닐 수 없다 .
특성 (Feature) 이 하나의 요구사항인가 ? 만약 그렇다면 그것이 어디에 명시되어 있는가에 달려있다 . 할당자 , 기능 , 고객 , 개념 , 상위레벨 하드웨어 , 아키텍처 , 설계 그리고 상세 요구사항이라는 말들이 있다 . 당신이 무엇이라고 부르든 상관없이 그것들은 모두 일정 부분 요구사항이다 . 기능과 MT4 멀티터미널 시스템 요구사항 관련되고 코드를 생성하는 것과 관련된다면 어떤 사람들에게는 어떤 형태에서는 요구사항인 것이다 .
역주 ) DO-178 에서는 요구사항을 상위레벨 요구사항과 하위레벨 요구사항으로 구분한다 . 합쳐서 요구사항이라고 할 수도 있겠지만 개념적으로 차이가 많아서 두 개를 통칭하는 경우는 잘 없다 . 그런데 위의 그림과 설명은 그 두 가지가 다소 혼재되어 있다 . 시스템 요구사항의 개념도 포함되어 있다 . 사실 왜 이렇게 설명하는지 잘 이해가 안되지만 어쨌든 그런 구분을 고려하지 않고 통칭해서 볼 때 요구사항에 대한 용어가 이렇게 다양할 수 있다는 점을 보여주려는 의도가 아닌가 싶다 .
소프트웨어는 상위레벨 요구사항과 하위레벨 요구사항으로 구분한다 . 하드웨어는 개념설계 요구사항과 상세설계 요구사항을 가진다 . 서로 다른 이름으로 불리지만 사실 같은 것이다 . 중요한 점은 분리된다는 것이다 . DO-178B 는 요구사항에 대해서 둘 혹은 그 이상 레벨을 요구한다는 점에서 소프트웨어 “ 표준 ” 중에서 독특하다 . 대부분의 회사들은 상위와 하위의 두 레벨을 제공한다 . 하지만 당신이 원한다면 중간 레벨들을 가질 수 있다 . 핵심은 더 하위 레벨의 요구사항을 고려하기 전에 더 상위 레벨의 요구사항 ( 단순하게 “ 상위레벨 ” 요구사항이라고 칭함 ) 을 먼저 고려해야 한다는 것이다 . 이것은 요구사항 개발에 대한 빅뱅 방식의 포괄적인 접근에 대비해서 단계별 개선 프로세스를 보장한다 . 간단하지 않고 ( 그리고 요구사항 작성은 사실 하나의 예술적 과학이다 ) 요구사항에 대한 이러한 두 레벨이 순서대로 필요하다는 것은 적어도 약간의 개선이 진행될 것이라는 것을 보장한다 .
역주 ) DO-178 에서는 요구사항을 상위레벨 요구사항과 하위레벨 요구사항으로 구분한다고 했다 . 그리고 작성 순서는 상위레벨을 먼저 작성하고 하위레벨을 작성하게 된다 . 이를 단순한 구분이 아니라 상위레벨은 고객 관점 , 하위레벨은 개발자 관점으로 이해하자 . 개발자 관점이라는 것은 결국 개발자가 소스코드를 작성하기 위한 기준이 된다는 의미이다 .
얼마나 깊게 분해할지에 대해서 유의하라 . 몇 년 전 우리는 공군폭격기를 위한 자체방어 및 디스플레이 시스템에 대해서 일한 적이 있다 . 주요 엔지니어로써 우리는 방법론을 살펴보고 구조적 코딩 및 구조적 명세 분석을 사용했다 . 비행기가 제작되는데 왜 100 억불이나 소요되었는지 이해하려고 확인하다 보니 코드의 모든 라인마다 거품이 있었다 . 그들은 소위 거품이 될 때까지 계속해서 분해하고 또 분해한 것이었다 . 우리는 10 에서 12 레벨까지 내려가는 분해를 확인했는데 그것은 불필요하고 효율적이지 않으며 너무 많은 유지가 필요했다 . 평균적으로 하나의 요구사항에 적어도 15 ~ 20 라인의 코드로 충분하다라고 하는 우리의 경험법칙을 기억하라 .
역주 ) 위의 설명은 결국 소스코드 한 줄 마다 요구사항이 정의되어 있더라는 말을 하는 것으로 이해가 된다 . 그야말로 요구사항과 소스코드가 1:1 로 매칭되는 수준인 것이다 . 누가 이렇게까지 하겠냐 싶지만 , 세상에는 우리가 상상하지 못하는 수많은 일이 일어나고 있는 것도 사실이다 .
당신은 하위레벨 요구사항을 결정하면 거기에서 멈추어야 한다 . 요구사항으로부터 코드를 작성할 수 있다면 멈추어라 . 그 후에 그것이 하위레벨인지 상위레벨인지 논쟁하지 마라 . 아무도 MT4 멀티터미널 시스템 요구사항 신경쓰지 않는다 . 하지만 기억할 것은 가정은 제거되어야 한다는 점이다 . 개발자가 더 이상 가정하지 않아도 될 정도까지 분해하라 . 만약 고객이 제공한 특성으로부터 코드를 작성할 수 있고 , 그것을 이해할 수 있고 그런 레벨로 분해되어 있다면 당신은 당신 자신을 위한 상위 그리고 하위레벨 요구사항을 만들 필요가 없다 . 그런 요구사항들로부터 코드로의 흐름과 추적을 보여줄 수 있는 한 당신은 멈출 수 있다 . DO-178B 와 DO-254 는 하위레벨 요구사항이 첫 번째 코드를 구현할 수 있다고 말한다 . 요구사항은 식별 가능하고 추적가능해야 한다 .
역주 ) DO-178 에서 상위레벨 요구사항과 하위레벨 요구사항을 무조건 MT4 멀티터미널 시스템 요구사항 작성해야 하는 것은 아니다 . 저자의 말처럼 고객 요구사항에서 바로 코딩을 할 수 있다면 굳이 중간단계의 형식적인 문서를 만들 필요가 없다 . 물론 그럼에도 불구하고 그것을 허용하고 그렇게도 인증을 받을 수 있다 . DO-178 의 철학을 보여주는 부분이라고 할 수 있다 .
“ 하위레벨 요구사항은 소소코드를 구현하는데 사용될 수 있다 .” DO-178B Section 5.2
“ 상세 설계 데이터는 요구사항과 일치하는 하드웨어 아이템을 구현하기 위해 필요한 데이터를 기술한다 .” DO-254 Section 10.3.2.2
요구사항은 식별 가능하고 추적가능해야 한다 .
그래픽 혹은 문서화를 표시하기위한 툴 사용은 필수이다 .
식별하고 추적하기 위한 툴 사용은 필수이다 .
하위레벨 요구사항과 설계 구문을 어떻게 식별할 지에 대해서 유의하라 .
분해 레벨은 마지막 아이템을 정의한다 .
우리는 현대화된 항공 시스템에서의 추적성이 툴 없이도 수행될 수 있다고 믿지 않는다 . 우리는 요구사항을 기술하면서 “shall” 이라는 단어를 사용한 회사와 일한 적이 있다 . 그들은 그것을 설계 구문이라고 부르기를 원했지만 회사 관례에서는 “shall” 은 요구사항에 대한 구분이었다 . 설계 구문의 모든 “shall” 은 요구사항이 되었고 각각은 시험을 요구한다 . 그래서 그들은 수많은 추가 시험을 작성했다 . 우리는 그 요구사항들을 제거하고 설계 구문이 되도록 만드는 것을 해결하는 데 6 개월을 소비했다 . 어떻게 분해하고 얼마나 깊게 할 것인지에 대해서 조심하라 . 왜냐하면 그것은 매우 비용이 많이 들 수 있기 때문이다 . 당신은 모든 요구사항을 시험해야 하지만 설계 결정사항에 대해서 불필요한 요구사항 기반의 시험을 추가적으로 작성하기를 원하지는 않는다 .
역주 ) 갑자기 “shall” 이 나와서 무슨 말인가 싶은 MT4 멀티터미널 시스템 요구사항 분들이 있을 것 같은데 이것은 DO-178 에서 요구사항을 작성할 때 요구사항 문구에 “shall” 을 포함하도록 하기 때문에 나온 내용이다 . 예를 들면 아래와 같은 식이다 .( 보통 아래와 같이 shall 을 굵게 표시해서 눈에 띄게 하는 경우가 많다 .)
“ABC software shall receive 32bit data from DEF module.”
저자의 사례는 설계 문서를 작성하면서 일반적인 설명과 요구사항을 작성한 구문을 구분없이 모두 “shall” 을 넣어서 작성했다는 말이다 . 보통 설계문서가 수백 페이지가 된다고 보면 문서 전체가 요구사항으로 뒤덮힌 상태가 된 것이다 . 그런 상태로 DO-178 인증을 진행한다면 DER 은 “shall” 이 포함된 모든 문구를 요구사항으로 인식하고 그 모든 것들에 대한 시험을 요구하게 된다 . 문서부터 새로 뜯어고쳐야 하는 상황인 것이다 .
Mac Installer Tray Icon 개발
현재 진행 상황 :
- 터미널에서 명령어를 사용하여 실행 결과에 따라 Tray Icon의 색상이 변경되는 Application 개발 중입니다.
진행 계획 :
- 계약 후 즉시 착수 - 개발 1주 - 테스트 1주
필요 요소 :
- Mac Installer Tray Icon 개발
배포 환경/개발환경/언어
- Jamf-Pro/Xcode/Swift, Shell
주요 개발 업무 :
- 설치 시 Tray Icon 생성
- 터미널 명령어를 실행하고 실행 결과(텍스트)에 따라 Tray Icon의 색상 변경
제약사항 :
1) Tray Icon이 생성되어야 합니다.
2) High Sierra 이상을 대상으로 설치해야 합니다.
자격요건
- MacOS 인스톨러 개발 경험자
우대사항
- SKT Jamf-Pro 환경에서 배포/개발한 경험 보유자
결과물
- .pkg 파일
- 개발 소스코드
모집 요건
지원 전 질문
지원서 작성시 클라이언트의 질문에 답변해 주세요.
Tray Icon은 맥OS 우측 상단에 표시되는 아이콘을 의미합니다. , 을 의미하는 두가지 아이콘은 저희가 제공해 드릴 예정입니다. 연결상태 확인은 저희가 별도로 설치하는 프로그램 명령어를 터미널을 통해서 실행하고 결과에 따라 아이콘을 변경하는 기능을 합니다.
모집 중인 다른 프로젝트
영상분석서버 통합관리 클라이언트 프로그램 개발
이 프로젝트의 클라이언트는 사업자 또는 신원 정보 인증을 완료하였습니다.
Andorid 앱 서버 이전 세팅 지원(방문 필요)
이 프로젝트의 클라이언트는 사업자 또는 신원 정보 인증을 완료하였습니다.
프로젝트 개요 : - Andorid 앱 서버 이전 세팅 지원 현재 준비 상황 : - 기 운영 중인 프로그램이 있습니다 - 이를 다른 서버에 설치하고, 설치 방법을 알려주시면 됩니다. 필요 요소 : - 레거시 분석/파악 - 서버 이전, 세팅 - 인수인계 개발환경/언어/방식 : - Eclipse, Spring framework, Tomcat, Oracle 요구 사항 : - 내부 서버실에 세팅, 운영 중이던 Android 앱 이전 작업이 필요합니다. - 다른 지역의 내부 서버실에 세팅하는 작업이 필요합니다. - 2~3회 정도 방문이 필요하며, 1회 레거시 분석/파악, 2회 테스트, 실제 서버 세팅, 인수인계 작업이 필요합니다. - 사무실 위치 : 서울시 강북구 - DB 마이그레이션 등의 작업은 포함하지 않습니다. 산출물 : - 서버 이전 세팅 - 인수인계 문서(협의 필요)MT4 멀티터미널 시스템 요구사항
MT4 멀티터미널 시스템 요구사항
소 개
4 차사업 개념을 토대로 인텔리전트 공장은 기계 모니터링 및 사전유지보수에 중점을 두고 혁신적인 제조기술을 도입하기 위해 노력하고 있습니다 . 이는 생산 절차를 최적화하는 데 중요한 부분을 차지합니다 . 관례적인 정기 유지보수 또는 긴급 고장 수리와 달리 사전유지보수 기능은 숨겨진 결함을 미리 탐지합니다 . 금속절단 밴드톱 기계 ( metal-cutting band saw) 를 예로 들 수 있습니다 . 장비제조업체는 수천 번의 절단 작업으로 톱 칼날 또는 기타 부품이 마모된 후에 데이터를 수집 및 분석하여 사전예측을 하기 때문에 공장 관리자는 파손된 기계를 수리하기 위해 긴급하게 부품업자를 소환할 필요가 없습니다 . 사전예측은 기계의 가동 휴지 시간을 줄이고 전반적인 공장의 생산성의 향상과 동시에 완성품의 품질을 향상시킵니다 .
사전 유지보수 시스템은 장비데이터를 수집하기 위해 데이터 수집카드를 내장한 팬리스 컴퓨터를 사용합니다 . 이를 위해 기계 제어 캐비닛에 하드웨어를 추가로 탑재하면 공간이 부족해지며 , 캐비닛 내부의 복잡한 유선 설치는 외관에도 영향을 미칠 뿐만 아니라 유지보수 및 관리를 어렵게 합니다 . 공간제약적인 해당 기계를 위해 , 어드밴텍은 소형 팜사이즈 데이터 수집 (DAQ) 컴퓨터를 특수 제작하여 장비제조업체가 사전유지보수 시스템을 기계와 쉽게 통합하도록 하였습니다 . 동시에 사용자를 위한 커스터마이징 서비스의 제공뿐만 아니라 데이터 수집의 정확성을 최적화하였으며 , 전문적인 산업용 디자인을 통해 하이 - 엔드 제품 이미지를 창조하고 시장경쟁력을 강화하였습니다 .
시스템 요구사항
정밀 기계 및 전기 기술을 제공하는 한 대만 기업은 다양한 금속가공을 위해 산업용 밴드톱 기계를 생산하여 세계적으로 유명한 장비 제조업체가 되었습니다 . 40 년전에 설립된 해당기업은 100 가지 종류 이상의 절단 시스템을 제작하였습니다 . 해당 제품은 전세계 80 개국 이상에서 판매될 정도로 인정받은 제품이며 , 유명 기업인 지멘스 ( Siemens) , 슈나이더 일렉트릭 ( Schneider Electric) , 보잉 (Boeing) 사 역시 해당 제품을 도입하였습니다 . 4 차 산업의 장점을 활용하여 제품의 가치를 향상시키고자 해당기업은 혁신적인 애플리케이션 개발에 적극적으로 투자하였습니다 . 그 중 밴드톱 기계에 도입하기 원하는 특징은 기계 모니터링 및 사전 유지보수 기능입니다 .
해당기업은 초기 개발 단계에서 미국산 USB 데이터 수집 하드웨어 제품을 사용할 계획이었습니다 .
면밀한 평가작업 후 , 금액이 높은 부품인 USB 데이터 수집 제품이 새로운 기술이 제공하는 경쟁력과 장점에 악영향을 미친다는 사실을 깨달았습니다 . 해당 데이터 수집 카드를 장착한 컴퓨터는 상당한 공간을 차지하며 복잡한 유선으로 인해 실용성이 낮기 때문입니다 . 이에 해당 기업은 더 나은 솔루션을 모색하기로 결정했습니다 .
사전 유지보수에 대한 요구사항을 충족하기 위해서는 멀티 - 채널 MT4 멀티터미널 시스템 요구사항 MT4 멀티터미널 시스템 요구사항 아날로그 I/O( 기계 정보 수집을 위한 신속한 샘플링 지원 ), 멀티 - 채널 디지털 I/O( 기계 제어 ), 네트워크 포트 ( 백엔드 관리 시스템으로 데이터 업로드 ) 와 같은 특정 기술에 대한 명확한 설명이 필요합니다 . 산업용 금속 밴드톱 기계는 드라이브 모터를 가동하거나 중지할 때마다 발생하는 전기 노이즈와 절단 시 발생하는 먼지 , 진동 , 충격에 노출된 거친 환경에서 주로 사용됩니다 . 해당 솔루션은 이러한 도전과제에 부응하는 정확한 정보 제공이 요구됩니다 .
시스템 설명
어드밴텍 MIC-1810 제품은 PC 기반 제어 플랫폼과 통합된 신호조정 , 프로세싱 변환을 지원하는 세계 최초 임베디드 데이터 수집 컴퓨터 모듈입니다 . 해당제품을 밴드톱 제어 캐비닛에 설치한 후 MIC-1810 와 전류 센서 및 RTD (Resistance Temperature Detector) 센서와 연결하면 장비 제조업체는 유지 및 대체가 필요한 부품의 벨류를 보여주는 머신 모델링을 위해 데이터를 정확하게 수집하여 사전 유지보수를 구현할 수 있습니다 .
어드밴텍은 MIC-1810 제품의 크기를 축소하여 기존의 임베디드 컴퓨터를 개선하였습니다 . MIC-1810 은 불필요한 시스템 기능을 제거하고 팬리스 디자인을 도입한 손바닥 크기의 제품입니다 . 제품에 내장된 터미널 블록은 센서 시그널 라인과 직접 연결되어 공간을 줄이고 몇몇 배선을 제거해줍니다 . 또한 , 해당제품은 DIN 레일 마운팅으로 모든 종류의 기계제어 캐비닛과 분산형 박스와 호환이 가능하며 , 진동과 먼지 차단은 거친 환경에서도 시스템을 안정적으로 운영하게 합니다 .
멀티 I/O 채널 기능을 갖춘 MIC-1810 은 전기 전류 및 온도 시그널을 제공하는 아날로그 인풋 채널을 통해 실시간 모니터링을 지원합니다 . 또한 , 디지털 인풋 및 아웃풋 채널을 통해 제조공정 제품의 모션을 제어하며 , 이더넷 포트를 통해 머신 정보를 클라우드로 업로드하여 원격모니터링 합니다 .
소프트웨어 측면에서 WebAccess/MCM 와 MIC-1810 제품은 소프트웨어 개발 툴이자 , 브라우저 기반 머신 모니터링 시스템입니다 . 사용자는 소프트웨어 라이센스 요금을 지불할 필요가 없으며 , 엔지니어는 프로그래밍이 필요 없는 단순한 설정을 토대로 사전 유지보수 시스템을 설계합니다 . 해당 소프트웨어 제품은 시스템 설계의 완성을 가속화하는 다양한 모니터링 기능을 제공합니다 . 예를 들어 , 수집된 신호는 실제 물리적 실체 (physical quantities) 로 직접 변환되며 , 사상표 (mapping table) 를 만들어 사용자의 시간을 절약합니다 . FFT( 고속 푸리에 변환 : Fast Fourier Transform) 로 인한 노이즈 필터 기능은 시그널 분석을 단순화하며 , 즉각적인 신호 파형 (signal Waveform) 을 보여주기 위한 오실로스코프 (oscilloscope) 는 장치가 제대로 작동하는지 확인해줍니다 . WebAccess/MCM 은 클라우드를 통해 기계 데이터를 수집하여 명확하고 쉬운 관리를 위해 시각 디스플레이 기능을 제공합니다 .
0 개 댓글