TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Product Quality Through Change Management (1999)

20 点作者 luu6 个月前

3 条评论

CharlieDigital6 个月前
I worked for a number of years working on a &quot;validated&quot; commercial-off-the-shelf system for big pharma; one of the first of its kind. Typically, all software supporting &quot;GxP&quot; (GCP = Good Clinical Practice, GMP = Good Manufacturing Practice, et.) processes must go through this process of validation (to degrees, determined by risk).<p>The term &quot;validated&quot; here typically refers to the GAMP5 &quot;V model&quot; of building software releases where there is a direct correlation between the various stages of build and release to some documentation (requirement, specification, design, install procedure, and test procedure).<p>By far, this was probably the highest quality software I&#x27;ve built in my career. Given the scope of what we were delivering for large enterprise pharma customers, our defect rate was surprisingly low. This is a system that&#x27;s used every day in tens of thousands of clinical trial sites around the world.<p>An interesting aspect of change management in GxP validated software is that <i>the process starts with identifying the documents that are going to be affected</i>. In other words, when we start a release, we would work with the sponsor (like a Merck or Pfizer) and the teams would make a &quot;change request&quot; document that inventoried which documentation would be affected. For example: which original requirements are to be updated, which specifications are changed, which installation procedures need to be updated, which test scripts are affected, etc.<p>This process is incredibly onerous and time consuming, but also ensures that not only is the output very high quality and low defect, but also well documented. I often thought that this is probably one area that is ripe for disruption, especially with LLMs. (It is also one of the reasons why it is rare to see startups building software that supports GxP processes).<p>(For most teams, I think that Basecamp&#x27;s &quot;Shape Up&quot; [0] is probably the most balanced change management process that yields acceptable speed, minimal wasted effort, while still allowing space for high quality software to be built.)<p>When I think about this period of my career, I often think about an article <i>They Write the Right Stuff</i> [1] on how NASA&#x27;s tolerances are perhaps at the extreme end of human perfection in software. A great read!<p>[0] <a href="https:&#x2F;&#x2F;basecamp.com&#x2F;shapeup" rel="nofollow">https:&#x2F;&#x2F;basecamp.com&#x2F;shapeup</a><p>[1] <a href="https:&#x2F;&#x2F;www.fastcompany.com&#x2F;28121&#x2F;they-write-right-stuff" rel="nofollow">https:&#x2F;&#x2F;www.fastcompany.com&#x2F;28121&#x2F;they-write-right-stuff</a>
jmaaloe6 个月前
<i>To achieve the goal we must:<p>1. understand what is valuable, 2. make sure that our efforts are focused on what is valuable, then 3. deliver something more valuable than before.<p>Understanding what is valuable is the key to the whole process. It&#x27;s achieved by &quot;requirements management&quot; [CMMI1.02, p86]</i><p>Uh uh I LOVE when &quot;the key to the whole process&quot; of figuring out what &quot;valuable&quot; is, is a quick, off-hand reference to another doc. Since it&#x27;s literally the key to the success of this whole operation let&#x27;s visit that CMMI1.02, page 86 real quick to learn &quot;requirements management&quot;:<p><i>The term &quot;requirements&quot; refers to product and product component requirements that are received by or generated by the project, including those requirements levied on the project by the organization. The requirements are both technical and non-technical. The practices in the Requirements Management process area are the source for the current, approved set of requirements upon which all of the practices in the other project process areas act. The project takes appropriate steps to ensure that the agreed-upon set of requirements is managed to support the planning and execution needs of the project. When a project receives requirements from an approved requirements provider, the requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into the project&#x27;s plans. After agreement between the requirements provider and the requirements receiver, commitment to the requirements is obtained from the project participants who have to do project activities and implement the requirements. The project manages changes to the requirements as they evolve during the project and identifies any inconsistencies that occur between the plans and work products and the requirements. Part of the management of requirements is to capture requirements changes and rationale and maintain bi-directional traceability among source requirements and all product and product component requirements. CMMI-SE&#x2F;SW, v1.02 Staged Representation Maturity Level: 2, Requirements Management 87 This process area is tightly coupled with the Requirements Development and the Technical Solution process areas, which address the processes for transforming stakeholder needs into product requirements and deciding how to allocate or distribute requirements among the product components. The practices in the Requirements Management process area should be done concurrently with the practices in the Requirements Development process area and the Technical Solution process area when those practices are implemented.</i><p>That&#x27;s for point 1 of this simple 3 step process. I bet steps 2-3 are just as straight forward.
rudasn6 个月前
(1999) but still looks relevant!
评论 #42115567 未加载