This document provides an overview of quality management concepts and techniques for software engineering. It discusses quality assurance, software reviews, formal technical reviews, statistical quality assurance, software reliability, and the ISO 9000 quality standards. The document includes slides on these topics with definitions, descriptions, and examples.
Following presentation answers:
- Why do we need evolution?
- What happens if we do not evolve the software?
- What are the types of software evolution?
- What are Lehman's laws
- What are the strategies for evolution?
Following presentation answers:
- Why do we need evolution?
- What happens if we do not evolve the software?
- What are the types of software evolution?
- What are Lehman's laws
- What are the strategies for evolution?
This ppt covers the following topics
Software quality
A framework for product metrics
A product metrics taxonomy
Metrics for the analysis model
Metrics for the design model
Metrics for maintenance
This ppt covers the following topics
Software quality
A framework for product metrics
A product metrics taxonomy
Metrics for the analysis model
Metrics for the design model
Metrics for maintenance
All software engineering works toward a single goal: to produce high-quality software
Software quality assurance (SQA) is an umbrella activity that is applied throughout the software process.
The SQA activities and technical review help us in ensuring the quality of software product
In this technique, test cases are developed using the use cases of the system. A use case encompass the various actors and their interactions with the system. Use cases cover the complete transactions from start to finish. These test cases depict the actual use of software by the end user.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
zkStudyClub - Reef: Fast Succinct Non-Interactive Zero-Knowledge Regex ProofsAlex Pruden
This paper presents Reef, a system for generating publicly verifiable succinct non-interactive zero-knowledge proofs that a committed document matches or does not match a regular expression. We describe applications such as proving the strength of passwords, the provenance of email despite redactions, the validity of oblivious DNS queries, and the existence of mutations in DNA. Reef supports the Perl Compatible Regular Expression syntax, including wildcards, alternation, ranges, capture groups, Kleene star, negations, and lookarounds. Reef introduces a new type of automata, Skipping Alternating Finite Automata (SAFA), that skips irrelevant parts of a document when producing proofs without undermining soundness, and instantiates SAFA with a lookup argument. Our experimental evaluation confirms that Reef can generate proofs for documents with 32M characters; the proofs are small and cheap to verify (under a second).
Paper: https://eprint.iacr.org/2023/1886
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
4. Quality Management
Quality Concepts
Variation control is the heart of quality control
Form one project to another, we want to
minimize the difference between the predicted
resources needed to complete a project and the
actual resources used, including staff,
equipment, and calendar time
Quality of design
Refers to characteristics that designers specify
for the end product
4
5. Quality Management
Quality of conformance
Degree to which design specifications are
followed in manufacturing the product
Quality control
Series of inspections, reviews, and tests used to
ensure conformance of a work product to its
specifications
Quality assurance
Consists of a set of auditing and reporting
functions that assess the effectiveness and
completeness of quality control activities
5
6. Quality Management
• Cost of Quality
Prevention costs
Quality planning, formal technical reviews, test
equipment, training
Appraisal costs
In-process and inter-process inspection,
equipment calibration and maintenance, testing
Failure costs
rework, repair, failure mode analysis
External failure costs
Complaint resolution, product return and
replacement, help line support, warranty work
6
7. Software Quality Assurance
• Software quality assurance (SQA) is the concern of
• every software engineer to reduce cost and improve
• product time-to-market.
• A Software Quality Assurance Plan is not merely
• another name for a test plan, though test plans are
• included in an SQA plan.
• SQA activities are performed on every software
• project.
• Use of metrics is an important part of developing a
• strategy to improve the quality of both software
• processes and work products.
7
8. Software Quality Assurance
• Definition of Software Quality serves to emphasize:
1.Conformance to software requirements is the foundation
from which software quality is measured.
2. Specified standards are used to define the development
criteria that are used to guide the manner in which
software is engineered.
3.Software must conform to implicit requirements (ease of
use, maintainability, reliability, etc.) as well as its explicit
requirements.
8
9. SQA Activities
• Prepare SQA plan for the project.
• Participate in the development of the project's software
• process description.
• Review software engineering activities to verify compliance
• with the defined software process.
• Audit designated software work products to verify compliance
• with those defined as part of the software process.
• Ensure that any deviations in software or work products are
• documented and handled according to a documented
• procedure.
• Record any evidence of noncompliance and reports them to
• management.
9
10. Software Reviews
• Purpose is to find errors before they are
• passed on to another software engineering
• activity or released to the customer.
• Software engineers (and others) conduct
• formal technical reviews (FTRs) for software
• quality assurance.
• Using formal technical reviews (walkthroughs
• or inspections) is an effective means for
• improving software quality.
10
11. Formal Technical Review
• A FTR is a software quality control activity performed by
software engineers and others.The objectives are:
1. To uncover errors in function, logic or implementation for
any representation of the software.
2. To verify that the software under review meets its
requirements.
3. To ensure that the software has been represented
according to predefined standards.
4. To achieve software that is developed in a uniform
manner and
5. To make projects more manageable.
11
12. Formal Technical Review
Review meeting in FTR
• The Review meeting in a FTR should abide to
the following constraints
1. Review meeting members should be between
three and five.
2. Every person should prepare for the meeting
and should not require more than two hours of
work for each person.
3. The duration of the review meeting should be
less than two hours.
12
13. Formal Technical Review
• The focus of FTR is on a work product that is requirement specification, a
detailed component design, a source code listing for a component.
• The individual who has developed the work product i.e, the producer informs
the project leader that the work product is complete and that a review is
required.
• The project leader contacts a review leader, who evaluates the product for
readiness, generates copy of product material and distributes them to two or
three review members for advance preparation .
• Each reviewer is expected to spend between one and two hours reviewing
the product, making notes
13
14. Formal Technical Review
• The review leader also reviews the product and establish an agenda for the
review meeting
• The review meeting is attended by review leader, all reviewers and the
producer.
• One of the reviewer act as a recorder,who notes down all important points
discussed in the meeting.
• The meeting(FTR) is started by introducing the agenda of meeting and then
the producer introduces his product. Then the producer “walkthrough” the
product, the reviewers raise issues which they have prepared in advance.
• If errors are found the recorder notes down
14
15. Review reporting and Record
keeping
• During the FTR, a reviewer( recorder) records all issues
that have been raised
• A review summary report answers three questions
1. What was reviewed?
2. Who reviewed it?
3. What were the findings and conclusions?
• Review summary report is a single page form with
possible attachments
• The review issues list serves two purposes
1. To identify problem areas in the product
2. To serve as an action item checklist that guides the
producer as corrections are made
15
16. Review Guidelines
• Review the product, not the producer
• Set an agenda and maintain it
• Limit debate and rebuttal
• Enunciate problem areas, but don’t attempt to solve every problem
noted
• Take return notes
• Limit the number of participants and insist upon advance
preparation.
• Develop a checklist for each product i.e likely to be reviewed
• Allocate resources and schedule time for FTRS
• Conduct meaningful training for all reviewer
• Review your early reviews
16
17. Software Defects
• Industry studies suggest that design activities
• introduce 50-65% of all defects or errors
• during the software process
• Review techniques have been shown to be up
• to 75% effective in uncovering design flaws
• which ultimately reduces the cost of
• subsequent activities in the software process
17
18. Statistical Quality Assurance
• Information about software defects is collected
• and categorized
• Each defect is traced back to its cause
• Using the Pareto principle (80% of the defects
• can be traced to 20% of the causes) isolate
• the "vital few" defect causes
• Move to correct the problems that caused the
• defects in the "vital few”
18
19. Six Sigma for Software Engineering
• The most widely used strategy for statistical quality assurance
• Three core steps:
• 1. Define customer requirements, deliverables, and project goals via well-defined
• methods of customer communication.
• 2. Measure each existing process and its output to determine current quality
• performance (e.g., compute defect metrics)
• 3. Analyze defect metrics and determine vital few causes.
• For an existing process that needs improvement
• 1. Improve process by eliminating the root causes for defects
• 2. Control future work to ensure that future work does not reintroduce causes of
• defects
• If new processes are being developed
• 1. Design each new process to avoid root causes of defects and to meet
• customer requirements
• 2. Verify that the process model will avoid defects and meet customer
• requirements
19
20. Software Reliability
• Defined as the probability of failure free operation of a
• computer program in a specified environment for a specified
• time period
• Can be measured directly and estimated using historical and
• developmental data
• Software reliability problems can usually be traced back to
• errors in design or implementation.
• Measures of Reliability
• Mean time between failure (MTBF) = MTTF + MTTR
• MTTF = mean time to failure
• MTTR = mean time to repair
• Availability = [MTTF / (MTTF + MTTR)] x 100%
20
21. ISO 9000 Quality Standards
• Quality assurance systems are defined as the
• organizational structure, responsibilities, procedures,
• processes, and resources for implementing quality
• management.
• ISO 9000 describes the quality elements that must
• be present for a quality assurance system to be
• compliant with the standard, but it does not describe
• how an organization should implement these
• elements.
• ISO 9001:2000 is the quality standard that contains
• 20 requirements that must be present in an effective
• software quality assurance system.
21