Artifacts VS OPA

1 过程财富库的含义 CMMI中提到的organizational process assets 通常翻译为组织过程资产或者是组织过程财富，可以简写为OPA。 什么是OPA呢？按照V1.3中的术语定义： Artifacts that relate to describing, implementing, and improving processes. Examples of these artifacts include policies, measurement descriptions, process descriptions, process implementation support tools. The term “process assets” is used to indicate that these artifacts are developed or acquired to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value. (See also “process asset library.”) 对上述的定义需要这么来理解： （1） the artifacts of describing processes，描述过程的制品，如方针、度量元定义、过程定义、规程定义、指南等； （2） the artifacts of implementing processes，实施过程的制品，如文档模板、过程裁剪报告、检查单等； （3） the artifacts of improving processes，改进过程的制品，如过程改进建议、经验教训总结等； 之所以用”assets”这个单词是从投资回报的角度来讲，过程财富不是只有投入没有产出的，是可以给我们带来回报的，过程财富服务于商业目标的。 在OPD过程域中SP 1.7 Establish Rules and Guidelines for Teams中还描述了在组织过程资产中还包括了： 团队结构指南； 团队信息指南； 团队授权和职责指南； 建立沟通渠道、授权和扩编指南； 团队负责人筛选准则等。 由以上可以看出，凡事在组织内有共享价值的与管理有关的资料都可以称为过程财富。 2 过程财富库中的内容 对于过程财富库在CMMI中做了如下的定义： A library of information used to store and make process assets available that are useful to those who are defining, implementing, and managing processes in the organization. This library contains process assets that include process related documentation such as policies, defined processes, checklists, lessons learned documents, templates, standards, procedures, plans, and training materials. 对于过程财富库中的内容在SP 1.5 Establish the Organization’s Process Asset Library中作了如下的举例： 过程财富库中包含了如下的内容： 组织级的方针； 过程描述； 规程（如估算规程）； 开发计划； 采购计划； 质量保证计划； 培训材料； 过程支持工具（如检查单）； 经验教训报告等。 在这个举例中，列举的3个计划，可以理解为是计划的模板，而不是某个项目的具体计划，如果是理解为某个项目的具体计划也应该是典型文档。 在组织级过程财富库中还应该包含的内容： 过程的裁剪指南； 组织级的生命周期模型定义； 项目组的过程裁剪记录。 在CMMI中还有一个概念：组织标准过程集，即组织级的所有标准过程定义，根据以上定义，这应该是组织过程财富库的子集。 是否项目组的所有文档都应该纳入组织过程财富库中呢？ 否！在组织过程财富库中的文档如果包含的是项目组的具体文档则应该仅仅是那些有价值的典型文档，是优秀的典型文档或者是拙劣的典型文档。 在CMMI中还包含了一个概念：组织级度量库，在组织级度量库中存放的是组织级采集的以及经过组织级分析后的度量数据。从概念上是不包含在组织级过程财富库中，在实践中可以认为也包含在组织过程财富库中。

===Artifacts ===

Artifacts 也是人们的造物，他们帮助其他开发者理解开发一套软件背后的思路。继而支撑着开发领导者做出下一步的决定，让他们对下一步流程有更明朗的理解。

Typically, a software development team will come up with a list of necessary artifacts for a piece of software before coding anything. These include things like risk assessments, source code, diagrams, and use cases. This is done during the research phase of the project.

Developing a piece of software without any of this is like building a house without blueprints. The process would be a huge mess, and crucial pieces would inevitably be left out. In this way, getting all your artifacts together is one of the most crucial parts of the software development life cycle.

Once all the initial artifacts are compiled, a development team can begin programming and building the actual program. Throughout this process, further artifacts might be developed. These can come up at any time and include everything from new sketches

Some artifacts, like the end-user agreement, may need to be built after the software is complete for total accuracy. These may be added in before the program is compiled and sent out for consumption.

Software Artifacts

There are a lot of different parts of any given piece of software that can be artifacts. Here are a few of the most common examples.

Use Cases

Use cases are descriptions of how users are meant to perform tasks on a given program, website, or piece of software. These relate directly to the function of the site, making them important artifacts.

Unified Modeling Language (UML)

UML is a way of visualizing and plotting out the way a piece of software works. It works to map out links, processes, etc.

Like use cases, UML doesn’t directly help software run, but it’s a key step in designing and programming a piece of software.

Class Diagrams

Like UML, a class diagram is a way to map out the structure of a piece of software or application. Class diagrams are used to map out links and processes that happen between clicks in a more visual way.

Images

Any images used to help develop the piece of software are considered artifacts. These might be example images used to help in the design of the product, or preliminary design images. It could even be simple sketches and diagrams used to help map out the software.

Software Documents

The majority of the artifacts are software documents. Any document that describes the characteristics or attributes of a piece of software is an artifact. These can relate to the software’s architecture, technical side, end-user processes, and marketing.

The majority of these artifacts won’t even cross the mind of the user. They’re meant for developers and those who might be interested in the software from a large-scale business perspective

Source Code

The source code is the language used to program a given piece of software. It’s not the physical code itself, but the system that allows that code to work. This, too, is an artifact according to software developers.

Meeting Notes

Yes, even meeting notes are artifacts in the world of software design. This may include full transcripts of meetings, or just jotted notes. Important design choices and aspects may have been made during these meetings, making it important to include these in your repository.

Risk Assessments

A risk assessment offers a look at the potential risks and downfalls of a piece of software. It helps tell a developer what not to do and lists problems that the developer needs to find a way around. In some ways, these are some of the most crucial artifacts for developers to consider.

Prototypes

Any prototype of your program is an artifact. These might be fully-functioning pieces of the software or previews of certain parts of the program. Either way, they help a developer see what has been done and tried, and give them an idea of where to go next.

The Compiled Application

Once the piece of software is fully developed, it’s compiled into a usable application. This is the final artifact, and one of the only ones a typical user will care about. The compiled application will let the user install it onto their machine, and use it as its meant to be used.

There may be a number of these in the artifact repository. There could be different versions, from early prototypes to experimental builds and the final compilation.

Why Are Artifacts Important?

Artifacts are important to hold onto throughout the development process of any piece of software, and even long after.

Without each and every artifact, it can make developing a piece of software much more difficult over time. This is especially true if development switches hands. When a new developer is put on a project, one of the first things they’ll want to do is go through the artifacts to get an idea of how the software works.

If an artifact is missing, that leaves a developer in the dark. This is why most artifacts are kept in a repository. This lets relevant developers access the artifacts at any time, all from one place.

What Is an Artifact Repository?

An artifact repository is a location for all of the necessary artifacts that might be used to develop a piece of software. It is often hosted on a local server or in the cloud for easy access by developers.

Using an artifact repository is absolutely necessary for all software development. It makes a complex task easier by giving developers all the resources they need in one place. It helps cut down on searching and gives developers the ability to move, add, and delete artifacts with ease.

There are three types of artifact repositories used in software development:

Remote Repository: A remote repository is hosted on a remote URL, sometimes by a third-party company. You cannot add new artifacts to a remote repository, but you can remove them.

Local Repository: A local repository is stored in-house, usually on a dedicated server.

Virtual: A combination of the two above. This repository is held under one URL, allowing access to local and remote artifact files. This lets you add and remove artifacts from each repository with ease.

There are a few key functions artifact repository software handles for the developers. Versioning support is one of these. The software will keep track of when each artifact is built, and apply a version to each build of the software.

Repository software can also help keep important artifacts, and delete ones that become irrelevant. This may happen when a new version of a given artifact is uploaded to the repository.

Of course, the most important factor of a good artifact repository is privacy and permissions. The software will keep all these artifacts private, and require a password to access.

The Types of Artifacts

There are three main categories that software artifacts fall under. These are code-related artifacts

Code Artifacts

Every program is made up of codes, and each coded process produces artifacts. These include:

Test Suites: Coded test to run against the program in order to make sure a certain process is working

Setup Scripts: Allow the program to run on a given machine

Complied Code: The final, compiled code that goes out to the user

Test Output: Logs and information that comes from the testing process

Code artifacts are unavoidable, important by-products of the coding process. They let a developer test the ins and outs of their software, allowing them to perfect it for the user.

Understanding Software Artifacts

So, what is an artifact? Essentially, it’s the skeleton of any given program. From documents to code tests to sketches, all of these are important artifacts for any developer.

No piece of software is complete without a host of artifacts, from diagrams to meeting notes and the source code itself. You can’t escape them, but you can better understand what they are and why they’re so important to keep track of. Hopefully, this guide has helped you understand software artifacts just a little more.

If you’re a researcher or publisher looking for a way to maintain and distribute your records, see what the ARTiFACTS team can do for you. Make sure to contact us with any questions or comments.

===OPA===

-------参考----------

https://www.zhihu.com/question/455298119

https://blog.csdn.net/dylanren/article/details/6229874