符合IEC 62304标准的体系结构定义

Question

我目前的任务是创建符合IEC 62304的软件架构。众所周知，这些规则含糊不清，没有提供任何关于“软件架构”所需内容的真正内容。标准状态

制造商应将医疗设备软件的要求转换为描述软件结构和识别软件项目的文档结构。

现在我去了一所应用计算机科学学校，所以我的大部分教学内容都是关于如何实际编写代码和项目，因此据我所知，我们从未涉及到任何涉及创建软件架构图的内容。

我基本上已经编写了所有的软件，但是为了管理提交的目的，我需要为项目创建这个文档。

总之，我的问题是：“软件架构”到底由什么组成？

Answer 1

我们现在正经历62304的学习曲线。

正如前面的答案所示，这只是你的医疗设备软件的高级视图。

根据标准，您至少应该列出各种模块/组件。组件被定义为由软件项组成。但是，如何定义组件和项完全取决于您。

在我们的例子中，产品通常只有一个组件，很少超过三个。

在基于工程师工作站的GUI项目中，我们有四个组件.GUI、产品逻辑和我们需要集成的现有DLL，以及整个系统所基于的底层数学建模引擎。

体系结构由以下部分组成

1. 图形用户界面，的描述
   • 基本上是一个屏幕列表及其相关的工作流。
   • 与每个屏幕相关联的对象(软件项)的描述

2. 产品逻辑的描述
   • 描述状态机，以及它如何与GUI工作流交互
   • 状态机类(软件项)的描述
   • 对为客户执行的数学建模操作的描述。(细分为各个阶段--每个阶段都是一个软件项目)

3. 对所需DLL、其汤状态等的描述(一个软件项目)
4. 对62304下开发的另一个软件组件的引用

需要记住的一件事是(尽管62304标准的编写方式带来了很大的影响)，您不必先创建架构图，然后在瀑布编码模型中将其固定下来。FDA鼓励使用更灵活的方法，允许您与代码一起开发架构，只要您根据最终设计验证最终架构。因此，从一个简单的体系结构开始，它允许您取得进展，并在您开发代码时保持它的最新。请参阅AAMI的TIR45出版物，以获得一些有文档的理由。

Answer 2

软件体系结构从高层次看软件。这将侧重于不同的软件组件如何相互交互。它还包括外部系统如何与您的软件系统交互，或者是否允许外部系统交互。如果你想到建筑架构师是如何设计建筑的，软件架构师就会设计一个软件系统。这涉及到记录软件系统。一些如何文档化的示例包括创建需求文档、用例文档、类图、状态图、交互图、帮助文件等等。

至于要使用多少细节，我想说的是，当系统没有做客户端试图做的事情时，您会想要使用足够多的细节来有效地描述系统应该做什么以及不同的消息意味着什么。他们将需要帮助文档和词汇表，特别是错误信息。

对于您的团队，我将使用需求和其他各种文档来指定系统的工作方式。这将大大有助于维护和增强。这些要求将有助于指导团队确定何时您有一个成品，工作产品。

Answer 3

标准是模糊的。但人们的期望是，您的QMS流程将被构造为定义您的组织如何使用这些文档。定义文档的需求，如何使用和维护这些文档。为了加强这一点，1995年的“减少文书工作法”(PRA)是为了确保联邦机构，包括林业发展局，不会因联邦政府赞助的信息收集而使公众负担过重；所需的信息是有用的。FDA有着非常普遍的目标，但是如果体系结构文档内容不能达到真正的目的，这是不需要的。

因此，软件架构文档(IMHO)必须为项目中的一组需求服务。我认为，如果该文件：

1. 向评审人员或熟悉产品的新员工传达设计范围的有用理想。
2. 在设计中定义独立的功能块。独立的，独立的，在意义上独立指定，设计，和，测试的组件的设计。
3. 标识到设计中每个组件的可测试接口。
4. 定义项目中用于引用设计组件的一致术语。

当项目细分工作时，架构文档应该是主要的参考，并且应该反映在团队中的领导的认识工程技能、文档的各部分以及V&V是如何处理的。

不过，这不是一个需求文档。它应该给出方框中的片段和过程的上下文和词汇表，但是需求文档应该为所需的功能和测试提供具体的内容。