| rdfs:comment
| - Em engenharia de software e , suportabilidade é um dos aspectos da qualidade de software que se refere à habilidade dum suporte técnico de instalar, configurar e monitorar produtos computacionais, identificar exceções ou falhas, depurar ou isolando problemas até a fonte, e prover manutenção de software ou hardware a fim de solucionar um problema ou restaurar o produto a um estado funcional. Incorporar recursos de suportabilidade num projeto tipicamente resulta em maior eficiência na manutenção, reduzindo custos operacionais. (pt)
- 在軟體工程及計算機工程中，服務性（serviceability）也稱為可支持性（supportability），是一種非功能性需求，是IBM提出的RAS中的一項。服務性是指技術服務人員安裝、配置及監控電腦產品，提供硬體或軟體服務的能力，也包括在出現例外情形或故障時排除問題，使產品可以正常運作的相關能力，包括針對故障除錯或隔離故障，進行根本原因分析等。服務性的提昇一般也代表產品維護效率的提昇，同時減少了營運的成本，保持業務的持續性。 以下是一些有關服務性的機能：
* 在有異常事件時，自動送出電子郵件或傳送文字訊息至傳呼機。
* 网络监控
*
* /
* 記錄，例如
* 執行路徑及（或）區域變數及全域變數
* 子程序的進入點及結束點，包括其傳入值及傳出值
* 例外處理區塊的進入點及其狀態
* 軟體升級
* ，指產品的設計可以在不需技術人員的介入下，由例外事件中復原的機能
* 硬體更換或升級計劃，而產品的設計可以在電腦系統停工期最短的條件下，進行有效率的硬體升級（例如熱插拔元件） 服務性工程一般也包括了一些例行性系統維護相關的特點（參見營運管理與維護（OAM））。 (zh)
- In software engineering and hardware engineering, serviceability (also known as supportability) is one of the -ilities or aspects (from IBM's RAS(U) (Reliability, Availability, Serviceability, and Usability)). It refers to the ability of technical support personnel to install, configure, and monitor computer products, identify exceptions or faults, debug or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit of solving a problem and restoring the product into service. Incorporating serviceability facilitating features typically results in more efficient product maintenance and reduces operational costs and maintains business continuity. (en)
|
| has abstract
| - In software engineering and hardware engineering, serviceability (also known as supportability) is one of the -ilities or aspects (from IBM's RAS(U) (Reliability, Availability, Serviceability, and Usability)). It refers to the ability of technical support personnel to install, configure, and monitor computer products, identify exceptions or faults, debug or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit of solving a problem and restoring the product into service. Incorporating serviceability facilitating features typically results in more efficient product maintenance and reduces operational costs and maintains business continuity. Examples of features that facilitate serviceability include:
* Help desk notification of exceptional events (e.g., by electronic mail or by sending text to a pager)
* Network monitoring
* Documentation
* Event logging / Tracing (software)
* Logging of program state, such as
* Execution path and/or local and global variables
* Procedure entry and exit, optionally with incoming and return variable values (see: subroutine)
* Exception block entry, optionally with local state (see: exception handling)
* Software upgrade
* Graceful degradation, where the product is designed to allow recovery from exceptional events without intervention by technical support staff
* Hardware replacement or upgrade planning, where the product is designed to allow efficient hardware upgrades with minimal computer system downtime (e.g., hotswap components.) Serviceability engineering may also incorporate some routine system maintenance related features (see: Operations, Administration and Maintenance (OA&M.)) A service tool is defined as a facility or feature, closely tied to a product, that provides capabilities and data so as to service (analyze, monitor, debug, repair, etc.) that product. Service tools can provide broad ranges of capabilities. Regarding diagnosis, a proposed taxonomy of service tools is as follows:
* Level 1: Service tool that indicates if a product is functional or not functional. Describing computer servers, the states are often referred to as ‘up’ or ‘down’. This is a binary value.
* Level 2: Service tool that provides some detailed diagnostic data. Often the diagnostic data is referred to as a problem ‘signature’, a representation of key values such as system environment, running program name, etc. This level of data is used to compare one problem’s signature to another problem’s signature: the ability to match the new problem to an old one allows one to use the solution already created for the prior problem. The ability to screen problems is valuable when a problem does match a pre-existing problem, but it is not sufficient to debug a new problem.
* Level 3: Provides detailed diagnostic data sufficient to debug a new and unique problem. As a rough rule of thumb for these taxonomies, there are multiple ‘orders of magnitude’ of diagnostic data in level 1 vs. level 2 vs. level 3 service tools. Additional characteristics and capabilities that have been observed in service tools:
* Time of data collection: some tools can collect data immediately, as soon as problem occurs, others are delayed in collecting data.
* Pre-analyzed, or not-yet-analyzed data: some tools collect ‘external’ data, while others collect ‘internal’ data. This is seen when comparing system messages (natural language-like statements in the user’s native language) vs. ‘binary’ storage dumps.
* Partial or full set of system state data: some tools collect a complete system state vs. a partial system state (user or partial ‘binary’ storage dump vs. complete system dump).
* Raw or analyzed data: some tools display raw data, while others analyze it (examples storage dump formatters that format data, vs. ‘intelligent’ data formatters (“ANALYZE” is a common verb) that combine product knowledge with analysis of state variables to indicate the ‘meaning’ of the data.
* Programmable tools vs. ‘fixed function’ tools. Some tools can be altered to get varying amounts of data, at varying times. Some tools have only a fixed function.
* Automatic or manual? Some tools are built into a product, to automatically collect data when a fault or failure occurs. Other tools have to be specifically invoked to start the data collection process.
* Repair or non-repair? Some tools collect data as a fore-runner to an automatic repair process (self-healing/fault tolerant). These tools have the challenge of quickly obtaining unaltered data before the desired repair process starts. (en)
- Em engenharia de software e , suportabilidade é um dos aspectos da qualidade de software que se refere à habilidade dum suporte técnico de instalar, configurar e monitorar produtos computacionais, identificar exceções ou falhas, depurar ou isolando problemas até a fonte, e prover manutenção de software ou hardware a fim de solucionar um problema ou restaurar o produto a um estado funcional. Incorporar recursos de suportabilidade num projeto tipicamente resulta em maior eficiência na manutenção, reduzindo custos operacionais. (pt)
- 在軟體工程及計算機工程中，服務性（serviceability）也稱為可支持性（supportability），是一種非功能性需求，是IBM提出的RAS中的一項。服務性是指技術服務人員安裝、配置及監控電腦產品，提供硬體或軟體服務的能力，也包括在出現例外情形或故障時排除問題，使產品可以正常運作的相關能力，包括針對故障除錯或隔離故障，進行根本原因分析等。服務性的提昇一般也代表產品維護效率的提昇，同時減少了營運的成本，保持業務的持續性。 以下是一些有關服務性的機能：
* 在有異常事件時，自動送出電子郵件或傳送文字訊息至傳呼機。
* 网络监控
*
* /
* 記錄，例如
* 執行路徑及（或）區域變數及全域變數
* 子程序的進入點及結束點，包括其傳入值及傳出值
* 例外處理區塊的進入點及其狀態
* 軟體升級
* ，指產品的設計可以在不需技術人員的介入下，由例外事件中復原的機能
* 硬體更換或升級計劃，而產品的設計可以在電腦系統停工期最短的條件下，進行有效率的硬體升級（例如熱插拔元件） 服務性工程一般也包括了一些例行性系統維護相關的特點（參見營運管理與維護（OAM））。 (zh)
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
![[cxml]](/fct/images/cxml_doc.png)
![[csv]](/fct/images/csv_doc.png)
![[text]](/fct/images/ntriples_doc.png)
![[turtle]](/fct/images/n3turtle_doc.png)
![[ld+json]](/fct/images/jsonld_doc.png)
![[rdf+json]](/fct/images/json_doc.png)
![[rdf+xml]](/fct/images/xml_doc.png)
![[atom+xml]](/fct/images/atom_doc.png)
![[html]](/fct/images/html_doc.png)