�ݺ�ߣshows by User: AnnMarieNeufelder

�ݺ�ߣshows by User: AnnMarieNeufelder / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: AnnMarieNeufelder / Wed, 08 Feb 2023 22:40:52 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: AnnMarieNeufelder Reliable software in a continuous integration/continuous deployment (CI/CD) environment /slideshow/reliable-software-in-a-continuous-integrationcontinuous-deployment-cicd-environment/255770421 reliablesoftwareinadevsecopsenvironment-230208224052-cf41f5c5
When the Waterfall software development model was first published it was not the intent to have multi-year development cycles. However, once this very bad practice became institutionalized it was difficult to change. The Agile Manifesto helped to change that only to result in convenient myths about continuous integration/continuous development. Contrary to popular belief having better and more reliable software is one of the key goals of CI/CD. The shorter cycles, daily reviews and code a little test a little approach has been correlated to more reliable software for decades. While CI/CD does minimize the risk of the long development cycles, it doesn't mitigate every risk. For example, it won't fix software engineers who don't understand the industry or product. It won't fix an insufficient level of rigor in testing. It won't fix designing/testing for success while ignoring designing/testing for failure. The primary purpose of CI/CD was to have data so that future sprints/releases could be more successful. Yet many software organizations fail to collect, analyze or learn from the previous sprints. Engineering leaders often have unrealistic expectations that Agile fixes everything. Even the best CI/CD environments can still experience failure from overlooking one key risk or overlooking one key failure mode. ]]>
When the Waterfall software development model was first published it was not the intent to have multi-year development cycles. However, once this very bad practice became institutionalized it was difficult to change. The Agile Manifesto helped to change that only to result in convenient myths about continuous integration/continuous development. Contrary to popular belief having better and more reliable software is one of the key goals of CI/CD. The shorter cycles, daily reviews and code a little test a little approach has been correlated to more reliable software for decades. While CI/CD does minimize the risk of the long development cycles, it doesn't mitigate every risk. For example, it won't fix software engineers who don't understand the industry or product. It won't fix an insufficient level of rigor in testing. It won't fix designing/testing for success while ignoring designing/testing for failure. The primary purpose of CI/CD was to have data so that future sprints/releases could be more successful. Yet many software organizations fail to collect, analyze or learn from the previous sprints. Engineering leaders often have unrealistic expectations that Agile fixes everything. Even the best CI/CD environments can still experience failure from overlooking one key risk or overlooking one key failure mode. ]]> Wed, 08 Feb 2023 22:40:52 GMT /slideshow/reliable-software-in-a-continuous-integrationcontinuous-deployment-cicd-environment/255770421 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Reliable software in a continuous integration/continuous deployment (CI/CD) environment AnnMarieNeufelder When the Waterfall software development model was first published it was not the intent to have multi-year development cycles. However, once this very bad practice became institutionalized it was difficult to change. The Agile Manifesto helped to change that only to result in convenient myths about continuous integration/continuous development. Contrary to popular belief having better and more reliable software is one of the key goals of CI/CD. The shorter cycles, daily reviews and code a little test a little approach has been correlated to more reliable software for decades. While CI/CD does minimize the risk of the long development cycles, it doesn't mitigate every risk. For example, it won't fix software engineers who don't understand the industry or product. It won't fix an insufficient level of rigor in testing. It won't fix designing/testing for success while ignoring designing/testing for failure. The primary purpose of CI/CD was to have data so that future sprints/releases could be more successful. Yet many software organizations fail to collect, analyze or learn from the previous sprints. Engineering leaders often have unrealistic expectations that Agile fixes everything. Even the best CI/CD environments can still experience failure from overlooking one key risk or overlooking one key failure mode. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/reliablesoftwareinadevsecopsenvironment-230208224052-cf41f5c5-thumbnail.jpg?width=120&height=120&fit=bounds" /> When the Waterfall software development model was first published it was not the intent to have multi-year development cycles. However, once this very bad practice became institutionalized it was difficult to change. The Agile Manifesto helped to change that only to result in convenient myths about continuous integration/continuous development. Contrary to popular belief having better and more reliable software is one of the key goals of CI/CD. The shorter cycles, daily reviews and code a little test a little approach has been correlated to more reliable software for decades. While CI/CD does minimize the risk of the long development cycles, it doesn't mitigate every risk. For example, it won't fix software engineers who don't understand the industry or product. It won't fix an insufficient level of rigor in testing. It won't fix designing/testing for success while ignoring designing/testing for failure. The primary purpose of CI/CD was to have data so that future sprints/releases could be more successful. Yet many software organizations fail to collect, analyze or learn from the previous sprints. Engineering leaders often have unrealistic expectations that Agile fixes everything. Even the best CI/CD environments can still experience failure from overlooking one key risk or overlooking one key failure mode.

Reliable software in a continuous integration/continuous deployment (CI/CD) environment from Ann Marie Neufelder

]]> 48 0 https://cdn.slidesharecdn.com/ss_thumbnails/reliablesoftwareinadevsecopsenvironment-230208224052-cf41f5c5-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 IEEE 1633 Recommended Practices for Reliable Software /slideshow/ieee-1633-recommended-practices-for-reliable-software/255770358 ieee1633executivesummary-230208223005-9a75e8bb
The IEEE 1633 provides practical guidance for developing reliable software and making key decisions that include reliability. There are qualitative and quantitative tasks starting from the beginning of the program until deployment. These methods are applicable for agile and incremental development environments. In fact, they work better in an agile environment. This document has practical step by step instructions for how to identify failure modes and root cause, identify risks that are often overlooked, predict defects before the code is even written, plan staffing levels for testing and support, evaluate reliability during testing, and make a release decision. Examples of the techniques are provided. This document was written by people who have real world experience in making software more reliable while still on time and within budget. It covers software failure modes effects analysis, software fault trees, software defect root cause analysis, reliability predictions, defect density predictions, software reliability benchmarking, software reliability growth estimation, developing a reliability driven test suite, allocating reliability to software, evaluating the portion of the total system failures that will be caused by the software, and managing software for reliability. The working group is chaired by Ann Marie Neufelder who is the global leader in reliable software. The document will be updated in 2023 for the Common Defect Enumeration and relationship with DevSecOps. ]]>
The IEEE 1633 provides practical guidance for developing reliable software and making key decisions that include reliability. There are qualitative and quantitative tasks starting from the beginning of the program until deployment. These methods are applicable for agile and incremental development environments. In fact, they work better in an agile environment. This document has practical step by step instructions for how to identify failure modes and root cause, identify risks that are often overlooked, predict defects before the code is even written, plan staffing levels for testing and support, evaluate reliability during testing, and make a release decision. Examples of the techniques are provided. This document was written by people who have real world experience in making software more reliable while still on time and within budget. It covers software failure modes effects analysis, software fault trees, software defect root cause analysis, reliability predictions, defect density predictions, software reliability benchmarking, software reliability growth estimation, developing a reliability driven test suite, allocating reliability to software, evaluating the portion of the total system failures that will be caused by the software, and managing software for reliability. The working group is chaired by Ann Marie Neufelder who is the global leader in reliable software. The document will be updated in 2023 for the Common Defect Enumeration and relationship with DevSecOps. ]]> Wed, 08 Feb 2023 22:30:05 GMT /slideshow/ieee-1633-recommended-practices-for-reliable-software/255770358 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) IEEE 1633 Recommended Practices for Reliable Software AnnMarieNeufelder The IEEE 1633 provides practical guidance for developing reliable software and making key decisions that include reliability. There are qualitative and quantitative tasks starting from the beginning of the program until deployment. These methods are applicable for agile and incremental development environments. In fact, they work better in an agile environment. This document has practical step by step instructions for how to identify failure modes and root cause, identify risks that are often overlooked, predict defects before the code is even written, plan staffing levels for testing and support, evaluate reliability during testing, and make a release decision. Examples of the techniques are provided. This document was written by people who have real world experience in making software more reliable while still on time and within budget. It covers software failure modes effects analysis, software fault trees, software defect root cause analysis, reliability predictions, defect density predictions, software reliability benchmarking, software reliability growth estimation, developing a reliability driven test suite, allocating reliability to software, evaluating the portion of the total system failures that will be caused by the software, and managing software for reliability. The working group is chaired by Ann Marie Neufelder who is the global leader in reliable software. The document will be updated in 2023 for the Common Defect Enumeration and relationship with DevSecOps. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ieee1633executivesummary-230208223005-9a75e8bb-thumbnail.jpg?width=120&height=120&fit=bounds" /> The IEEE 1633 provides practical guidance for developing reliable software and making key decisions that include reliability. There are qualitative and quantitative tasks starting from the beginning of the program until deployment. These methods are applicable for agile and incremental development environments. In fact, they work better in an agile environment. This document has practical step by step instructions for how to identify failure modes and root cause, identify risks that are often overlooked, predict defects before the code is even written, plan staffing levels for testing and support, evaluate reliability during testing, and make a release decision. Examples of the techniques are provided. This document was written by people who have real world experience in making software more reliable while still on time and within budget. It covers software failure modes effects analysis, software fault trees, software defect root cause analysis, reliability predictions, defect density predictions, software reliability benchmarking, software reliability growth estimation, developing a reliability driven test suite, allocating reliability to software, evaluating the portion of the total system failures that will be caused by the software, and managing software for reliability. The working group is chaired by Ann Marie Neufelder who is the global leader in reliable software. The document will be updated in 2023 for the Common Defect Enumeration and relationship with DevSecOps.

IEEE 1633 Recommended Practices for Reliable Software from Ann Marie Neufelder

]]> 186 0 https://cdn.slidesharecdn.com/ss_thumbnails/ieee1633executivesummary-230208223005-9a75e8bb-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Software Failure Modes Effects Analysis Overview /slideshow/software-failure-modes-effects-analysis-overview/230463541 sfmeaoverview-200318124310
How to efficiently and effectively find defects in software that typically aren't found in testing]]>
How to efficiently and effectively find defects in software that typically aren't found in testing]]> Wed, 18 Mar 2020 12:43:10 GMT /slideshow/software-failure-modes-effects-analysis-overview/230463541 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Software Failure Modes Effects Analysis Overview AnnMarieNeufelder How to efficiently and effectively find defects in software that typically aren't found in testing <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/sfmeaoverview-200318124310-thumbnail.jpg?width=120&height=120&fit=bounds" /> How to efficiently and effectively find defects in software that typically aren't found in testing

Software Failure Modes Effects Analysis Overview from Ann Marie Neufelder

]]> 946 0 https://cdn.slidesharecdn.com/ss_thumbnails/sfmeaoverview-200318124310-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 The Top Ten things that have been proven to effect software reliability /slideshow/the-top-ten-things-that-have-been-proven-to-effect-software-reliability-135673556/135673556 softwarereliabilityfactors-190311165811
Several factors have been quantitatively correlated to software reliability]]>
Several factors have been quantitatively correlated to software reliability]]> Mon, 11 Mar 2019 16:58:11 GMT /slideshow/the-top-ten-things-that-have-been-proven-to-effect-software-reliability-135673556/135673556 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) The Top Ten things that have been proven to effect software reliability AnnMarieNeufelder Several factors have been quantitatively correlated to software reliability <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/softwarereliabilityfactors-190311165811-thumbnail.jpg?width=120&height=120&fit=bounds" /> Several factors have been quantitatively correlated to software reliability

The Top Ten things that have been proven to effect software reliability from Ann Marie Neufelder

]]> 402 1 https://cdn.slidesharecdn.com/ss_thumbnails/softwarereliabilityfactors-190311165811-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Five Common Mistakes made when Conducting a Software FMECA /slideshow/five-common-mistakes-made-when-conducting-a-software-fmeca/135653781 5commonmistakesmadewhenconductingsfmecas-190311154035
The software FMECA is a powerful tool for identifying software failure modes but there are 5 common mistakes that can derail the effectiveness of the analysis.]]>
The software FMECA is a powerful tool for identifying software failure modes but there are 5 common mistakes that can derail the effectiveness of the analysis.]]> Mon, 11 Mar 2019 15:40:35 GMT /slideshow/five-common-mistakes-made-when-conducting-a-software-fmeca/135653781 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Five Common Mistakes made when Conducting a Software FMECA AnnMarieNeufelder The software FMECA is a powerful tool for identifying software failure modes but there are 5 common mistakes that can derail the effectiveness of the analysis. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/5commonmistakesmadewhenconductingsfmecas-190311154035-thumbnail.jpg?width=120&height=120&fit=bounds" /> The software FMECA is a powerful tool for identifying software failure modes but there are 5 common mistakes that can derail the effectiveness of the analysis.

Five Common Mistakes made when Conducting a Software FMECA from Ann Marie Neufelder

]]> 1024 7 https://cdn.slidesharecdn.com/ss_thumbnails/5commonmistakesmadewhenconductingsfmecas-190311154035-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Revised IEEE 1633 Recommended Practices for Software Reliability /slideshow/revised-ieee-1633-recommended-practices-for-software-reliability/66653947 ieee1633-161003020217
The 2008 document has been revised and was approved by the IEEE on 9/19/16.]]>
The 2008 document has been revised and was approved by the IEEE on 9/19/16.]]> Mon, 03 Oct 2016 02:02:17 GMT /slideshow/revised-ieee-1633-recommended-practices-for-software-reliability/66653947 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Revised IEEE 1633 Recommended Practices for Software Reliability AnnMarieNeufelder The 2008 document has been revised and was approved by the IEEE on 9/19/16. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ieee1633-161003020217-thumbnail.jpg?width=120&height=120&fit=bounds" /> The 2008 document has been revised and was approved by the IEEE on 9/19/16.

Revised IEEE 1633 Recommended Practices for Software Reliability from Ann Marie Neufelder

]]> 3052 12 https://cdn.slidesharecdn.com/ss_thumbnails/ieee1633-161003020217-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Overview of software reliability engineering /slideshow/overview-of-software-reliability-engineering/65951056 shortoverviewofsre-160912210437
This presentation discusses the types of models that are available and how they can be used to manage software releases.]]>
This presentation discusses the types of models that are available and how they can be used to manage software releases.]]> Mon, 12 Sep 2016 21:04:36 GMT /slideshow/overview-of-software-reliability-engineering/65951056 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Overview of software reliability engineering AnnMarieNeufelder This presentation discusses the types of models that are available and how they can be used to manage software releases. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/shortoverviewofsre-160912210437-thumbnail.jpg?width=120&height=120&fit=bounds" /> This presentation discusses the types of models that are available and how they can be used to manage software releases.

Overview of software reliability engineering from Ann Marie Neufelder

]]> 2941 10 https://cdn.slidesharecdn.com/ss_thumbnails/shortoverviewofsre-160912210437-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 An Introduction to Software �Failure Modes Effects Analysis (SFMEA) /slideshow/an-introduction-to-software-failure-modes-effects-analysis-sfmea/56791498 sfmea2015intro-160107164032
Software Failure Modes Effects Analysis (SFMEA) is an effective tool for identifying what software applications should NOT do. Software testing is often focused on nominal conditions and often doesn't discover serious defects.]]>
Software Failure Modes Effects Analysis (SFMEA) is an effective tool for identifying what software applications should NOT do. Software testing is often focused on nominal conditions and often doesn't discover serious defects.]]> Thu, 07 Jan 2016 16:40:32 GMT /slideshow/an-introduction-to-software-failure-modes-effects-analysis-sfmea/56791498 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) An Introduction to Software �Failure Modes Effects Analysis (SFMEA) AnnMarieNeufelder Software Failure Modes Effects Analysis (SFMEA) is an effective tool for identifying what software applications should NOT do. Software testing is often focused on nominal conditions and often doesn't discover serious defects. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/sfmea2015intro-160107164032-thumbnail.jpg?width=120&height=120&fit=bounds" /> Software Failure Modes Effects Analysis (SFMEA) is an effective tool for identifying what software applications should NOT do. Software testing is often focused on nominal conditions and often doesn't discover serious defects.

An Introduction to Software Failure Modes Effects Analysis (SFMEA) from Ann Marie Neufelder

]]> 42638 22 https://cdn.slidesharecdn.com/ss_thumbnails/sfmea2015intro-160107164032-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 The Top Ten things that have been proven to effect software reliability /slideshow/the-top-ten-things-that-have-been-proven-to-effect-software-reliability/56791348 topten-160107163724
There are many myths about what causes reliable or unreliable software. The proven facts are shown in this presentation.]]>
There are many myths about what causes reliable or unreliable software. The proven facts are shown in this presentation.]]> Thu, 07 Jan 2016 16:37:24 GMT /slideshow/the-top-ten-things-that-have-been-proven-to-effect-software-reliability/56791348 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) The Top Ten things that have been proven to effect software reliability AnnMarieNeufelder There are many myths about what causes reliable or unreliable software. The proven facts are shown in this presentation. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/topten-160107163724-thumbnail.jpg?width=120&height=120&fit=bounds" /> There are many myths about what causes reliable or unreliable software. The proven facts are shown in this presentation.

The Top Ten things that have been proven to effect software reliability from Ann Marie Neufelder

]]> 1901 13 https://cdn.slidesharecdn.com/ss_thumbnails/topten-160107163724-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Top Ten things that have been proven to effect software reliability /slideshow/top-ten-things-that-have-been-proven-to-effect-software-reliability/56791177 topten-160107163401
There are many myths about what causes reliable or unreliable software. However, this presentation shows the facts based on real data from real projects.]]>
There are many myths about what causes reliable or unreliable software. However, this presentation shows the facts based on real data from real projects.]]> Thu, 07 Jan 2016 16:34:01 GMT /slideshow/top-ten-things-that-have-been-proven-to-effect-software-reliability/56791177 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Top Ten things that have been proven to effect software reliability AnnMarieNeufelder There are many myths about what causes reliable or unreliable software. However, this presentation shows the facts based on real data from real projects. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/topten-160107163401-thumbnail.jpg?width=120&height=120&fit=bounds" /> There are many myths about what causes reliable or unreliable software. However, this presentation shows the facts based on real data from real projects.

Top Ten things that have been proven to effect software reliability from Ann Marie Neufelder

]]> 465 7 https://cdn.slidesharecdn.com/ss_thumbnails/topten-160107163401-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Introduction to Software Failure Modes Effects Analysis /slideshow/introduction-to-software-failure-modes-effects-analysis/56784467 sfmea2015intro-160107140242
Software Failure Modes Effects Analysis is a method of identifying what can go wrong with the software. Software testing generally focuses on the positive test cases. The SFMEA focuses on analyzing what can go wrong. ]]>
Software Failure Modes Effects Analysis is a method of identifying what can go wrong with the software. Software testing generally focuses on the positive test cases. The SFMEA focuses on analyzing what can go wrong. ]]> Thu, 07 Jan 2016 14:02:41 GMT /slideshow/introduction-to-software-failure-modes-effects-analysis/56784467 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Introduction to Software Failure Modes Effects Analysis AnnMarieNeufelder Software Failure Modes Effects Analysis is a method of identifying what can go wrong with the software. Software testing generally focuses on the positive test cases. The SFMEA focuses on analyzing what can go wrong. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/sfmea2015intro-160107140242-thumbnail.jpg?width=120&height=120&fit=bounds" /> Software Failure Modes Effects Analysis is a method of identifying what can go wrong with the software. Software testing generally focuses on the positive test cases. The SFMEA focuses on analyzing what can go wrong.

Introduction to Software Failure Modes Effects Analysis from Ann Marie Neufelder

]]> 3566 10 https://cdn.slidesharecdn.com/ss_thumbnails/sfmea2015intro-160107140242-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Predict Software Reliability Before the Code is Written /slideshow/predict-software-reliability-before-the-code-is-written/56752911 approachtoswr-160106185151
You can predict software reliability before the code is even finished. Predictions support planning, sensitivity analysis and also help to avoid distressed software projects and defect pile up.]]>
You can predict software reliability before the code is even finished. Predictions support planning, sensitivity analysis and also help to avoid distressed software projects and defect pile up.]]> Wed, 06 Jan 2016 18:51:51 GMT /slideshow/predict-software-reliability-before-the-code-is-written/56752911 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Predict Software Reliability Before the Code is Written AnnMarieNeufelder You can predict software reliability before the code is even finished. Predictions support planning, sensitivity analysis and also help to avoid distressed software projects and defect pile up. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/approachtoswr-160106185151-thumbnail.jpg?width=120&height=120&fit=bounds" /> You can predict software reliability before the code is even finished. Predictions support planning, sensitivity analysis and also help to avoid distressed software projects and defect pile up.

Predict Software Reliability Before the Code is Written from Ann Marie Neufelder

]]> 1780 10 https://cdn.slidesharecdn.com/ss_thumbnails/approachtoswr-160106185151-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Four things that are almost guaranteed to reduce �the reliability of a software intensive system /slideshow/four-things-that-are-almost-guaranteed-to-reduce-the-reliability-of-a-software-intensive-system-56741617/56741617 neufelder4hings-160106141410
Distressed software projects typically have at least one of the 4 risks shown in the presentation. Avoiding these 4 things is the first step in ensuring software reliability.]]>
Distressed software projects typically have at least one of the 4 risks shown in the presentation. Avoiding these 4 things is the first step in ensuring software reliability.]]> Wed, 06 Jan 2016 14:14:09 GMT /slideshow/four-things-that-are-almost-guaranteed-to-reduce-the-reliability-of-a-software-intensive-system-56741617/56741617 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Four things that are almost guaranteed to reduce �the reliability of a software intensive system AnnMarieNeufelder Distressed software projects typically have at least one of the 4 risks shown in the presentation. Avoiding these 4 things is the first step in ensuring software reliability. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/neufelder4hings-160106141410-thumbnail.jpg?width=120&height=120&fit=bounds" /> Distressed software projects typically have at least one of the 4 risks shown in the presentation. Avoiding these 4 things is the first step in ensuring software reliability.

Four things that are almost guaranteed to reduce the reliability of a software intensive system from Ann Marie Neufelder

]]> 831 6 https://cdn.slidesharecdn.com/ss_thumbnails/neufelder4hings-160106141410-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Four things that are almost guaranteed to reduce �the reliability of a software intensive system /slideshow/four-things-that-are-almost-guaranteed-to-reduce-the-reliability-of-a-software-intensive-system/56740574 neufelder4hings-160106134535
This presentation shows the four things that have been quantitatively associated with distressed software intensive systems. Identifying these 4 things early in the system life cycle is essential for avoiding or mitigating a failed software project.]]>
This presentation shows the four things that have been quantitatively associated with distressed software intensive systems. Identifying these 4 things early in the system life cycle is essential for avoiding or mitigating a failed software project.]]> Wed, 06 Jan 2016 13:45:35 GMT /slideshow/four-things-that-are-almost-guaranteed-to-reduce-the-reliability-of-a-software-intensive-system/56740574 AnnMarieNeufelder@slideshare.net(AnnMarieNeufelder) Four things that are almost guaranteed to reduce �the reliability of a software intensive system AnnMarieNeufelder This presentation shows the four things that have been quantitatively associated with distressed software intensive systems. Identifying these 4 things early in the system life cycle is essential for avoiding or mitigating a failed software project. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/neufelder4hings-160106134535-thumbnail.jpg?width=120&height=120&fit=bounds" /> This presentation shows the four things that have been quantitatively associated with distressed software intensive systems. Identifying these 4 things early in the system life cycle is essential for avoiding or mitigating a failed software project.

Four things that are almost guaranteed to reduce the reliability of a software intensive system from Ann Marie Neufelder

]]> 579 5 https://cdn.slidesharecdn.com/ss_thumbnails/neufelder4hings-160106134535-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://public.slidesharecdn.com/v2/images/profile-picture.png https://cdn.slidesharecdn.com/ss_thumbnails/reliablesoftwareinadevsecopsenvironment-230208224052-cf41f5c5-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/reliable-software-in-a-continuous-integrationcontinuous-deployment-cicd-environment/255770421 Reliable software in a... https://cdn.slidesharecdn.com/ss_thumbnails/ieee1633executivesummary-230208223005-9a75e8bb-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/ieee-1633-recommended-practices-for-reliable-software/255770358 IEEE 1633 Recommended ... https://cdn.slidesharecdn.com/ss_thumbnails/sfmeaoverview-200318124310-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/software-failure-modes-effects-analysis-overview/230463541 Software Failure Modes...