0:00 Hello and welcome to Professional Practice.
0:04 This week we're talking about quality, in particular how we measure and manage quality.
0:13 So how do we measure quality? So the standard way of measuring quality and or reliability is to measure the number of defects.
0:26 So then that begs the question, what is a defect? Well, a defect is anything that does not behave in accordance with the requirements.
0:34 A defect could be a bug or a fault in the application, which impacts the software from that functionality performance.
0:42 Or it could be a failure when a user finds that when they press on a button,
0:48 the behavior is not what they expected or takes them someplace that they didn't want to go.
0:55 Importantly, what may be considered a defect in one product may not be considered a defect for another.
1:01 It's all about whether the requirements for a particular system or application omit.
1:06 For example, if I'm not concerned,
1:08 my website doesn't look good on a mobile phone and that users will only be using the website on the desktop, then that's not an issue.
1:17 However, if somebody else like Sam needs the website to operate well on a mobile, then that then does become a defect.
1:26 So what is an acceptable level of defect? So the and this is where when you get into quality systems, they have a fair bit of variation.
1:39 But the general comment would be the fewer, the better.
1:42 A couple of you may have heard of Six Sigma, which aims to achieve 3.1 errors, 3.4 error, sorry, per 1 million error opportunities.
1:56 One thing I have some familiarity with is Crosbie, which recognizes as an objective zero defects.
2:04 So the idea is that even the Six Sigma level of defects is not acceptable and we should strive for zero defects.
2:12 If we want quality software. So what defects should be our priority?
2:22 Another way that people manage deepfakes is to highlight the severity and also the priority.
2:31 So usually it's a number system with one being the highest severity, one being the highest.
2:37 So generally severity one issue is when the system doesn't work and there's no work around priorities.
2:45 The urgency to some extent that relates to the priority of the system, but also to the severity of the issue of the error.
2:58 So why do we need severity and priority?
3:01 Well, many times we have more defects than we can handle in any given day, and we need a way of managing them.
3:11 So generally, prioritizing them on severity and urgency is the best way that we've found.
3:20 Okay. He's a conceptual model that I like to use for managing deepfakes.
3:28 It's called the fake model. It really has its roots more in the waterfall model of development.
3:34 But I think the context behind it quite applicable.
3:39 In particular, it highlights the getting requirements and fixing requirements that are not correct or even
3:48 in fact to try to solve the problem is very costly because it often involves a lot of design,
3:55 whereas you standard coding error or bug fix can often be filled fixed much more easily.
4:03 This is quite important and quite worthwhile thinking about in an agile context.
4:11 So when you're thinking about quality in an Agile.
4:17 Scenario. It's worth looking at the problem statement, the design and.
4:26 As well as all use of stories with every iteration,
4:30 because often you may find that the problem you're trying to solve for your users does evolve over time and tweaking or
4:38 changing your problem statement between iterations may actually avoid developing the wrong thing for your customer.
4:50 Some of the strategies to balance and strategies to improve and ensure quality and reliability.
4:58 So when we look at quality, it's best to think about preventing defects rather than rectifying them.
5:05 One of the truisms of quality is that testing doesn't actually help you create quality.
5:11 It only tells you when you have bad quality or poor quality.
5:15 So when we look at looking at preventing defects of values in a project,
5:20 we need to look at that project or our system as more than just a technical component,
5:26 but rather we need to think about something that's made up of people, processes as well as technology.
5:31 An example is a use of a road. The whole road system is made of people.
5:36 That is the drivers of pedestrians, the processes, which is the road rules and the technology,
5:42 the vehicles, the traffic lights, the control systems behind them.
5:47 The road system is a good example of what is important to look at a whole system when trying to rectify failures.
5:53 Because of use, it just goes through a red light.
5:56 It may be an issue with the traffic light not operating correctly, or it might be a defect of the user not concentrating.
6:04 There are different types of system and each system has different levels of defects which you consider acceptable.
6:11 I want to focus on three classified classifications.
6:16 We tend to talk about them as critical systems.
6:20 The first one is safety critical systems or life critical systems.
6:25 These are whether if a system is a system whose failure or malfunction will result in the death or serious injury to people.
6:33 Losses, severe damage to property or environmental harm.
6:38 For example, computer based systems in aviation, chemical processes, nuclear power plants.
6:45 A failure of these systems endangers human lives directly or indirectly through environmental pollution.
6:52 The next category is mission critical systems. These are systems that are essential to the survival of the business organization.
7:00 When a mission critical system fails or is interrupted, its operations are significantly impacted.
7:07 For example, electric power systems for businesses that are heavily dependent on electricity, such as an electric aluminum manufacturer.
7:16 Business critical systems, a system whose failure may result in a very high cost for a business using that system.
7:24 For example, when a when part of a banking system goes down,
7:33 the high cost of failure for critical systems means that the acceptable level of defects really should be zero.
7:47 Another way of ensuring quality. Another strategy is to understand stakeholder requirements.
7:56 This helps prevent defects in failure and particularly big ones where important client needs or expectations are not met by what you develop.
8:08 Or even reliability factors that the client may have or the user may have are not met.
8:17 So before you start your project,
8:18 the following question should be well understood by the team to determine what the client or users expect from the systems.
8:26 What functions and features of the product are needed.
8:30 In other words, what the quality is. So firstly, who are the target users and what are the requirements?
8:37 It's important to understand who the target user is and what they require as a side point.
8:42 Sometimes the target user requirements may be different.
8:46 To those of the client, for example, if the client wants to add complicated features to a product.
8:53 Yet the users prefer a simple experience. This will be risky to the quality of the product as the user's expectations may not be met.
9:02 What problem is the product trying to solve?
9:05 Knowing what product the problem the product is trying to solve and what requirements are important can help the team
9:11 focus on the features that will make the user expectations and needs and therefore help ensure a quality product.
9:21 What features a user is expecting from the quality product?
9:25 How will they? How, how and where will the users use the product?
9:30 Knowing how and where the users will use the product will help determine the features you develop.
9:35 For example, will they be using it as an app on the go on a mobile device?
9:40 Will they be sitting at their desk? What metrics do you want to measure to measure the success for the product?
9:47 Understanding how clients intend to measure the success of the product will help determine how
9:54 features are developed to achieve these metrics and help to ensure expectations of the client.
10:00 A met. Reliability considerations.
10:07 What we need to think about when we think about reliability was a few main factors, particularly load.
10:13 How many users do you expect to use the system at peak talent?
10:18 How long do you expect users to use the product for each time? What do you expect them to do while they are using the product?
10:25 Understanding these questions helps determine the light load capacity the product.
10:30 Do you just need to be authorized to access the product? This is an important security concern.
10:37 How will the software be secured from unauthorized access?
10:41 How will the software be protected from database attacks?
10:45 And how will updates to the software be implemented?
10:49 Understanding all these questions can help determine if the.
10:56 What do you need to do to ensure the reliability of the software?
11:01 Okay. So the important point to note is that security and I guess what our cybersecurity
11:09 colleagues do is critical to ensuring the reliability of the product.
11:16 All right.
11:19 So some other things that you may want to do and they should all be applicable to your IEEE project, but you'll probably run into that work.
11:30 Firstly, use make sure you have good user stories and scenarios.
11:35 You know that in IEEE we we, we emphasize user stories,
11:39 but having good quality user stories that really reflect what the user is trying to achieve and what they're doing and what they're trying to achieve,
11:50 written from a user's perspective, are really essential to understanding what you need to do to write quality software.
12:00 Doing good design.
12:01 Sometimes we we skimp on design as a process, sitting down, doing prototypes, coming up with multiple designs to meet the user requirements.
12:11 Testing those designs, revisiting them. Usability testing are all essential to ensuring quality.
12:20 And then the final thing is testing there.
12:24 As I said before, testing doesn't ensure. Particularly just doing a unit test at the end doesn't ensure you're going to have a quality product.
12:36 All it does is tell you when you don't have one.
12:39 However, if you test as you go through the stages and think back to the very model, if you validate your problem statement.
12:49 With users. If you test your design by prototyping it and analyzing it, if you do test chips,
12:58 if you do paired programing with your coding, then all those things will contribute to you building a quality system.
13:10 Once again, just to emphasize that if you put the user in the center and keep them involved at all stages,
13:19 then you're likely to end up with a much higher quality product than if you talk to the users at the start.
13:27 Do you work and then throw them a product to user acceptance test?
13:34 Just one final thing that might be worth considering is.
13:40 Training abuses sometimes. You might write a system which doesn't require training, but and that's ideally the case.
13:48 But if you do, the quality of the training of the users also impacts the overall perception of the quality of the system.
13:57 All right. Well, thank you. I think that's all for today and that's all for quality.
14:02 I wish you luck with your chapter and your first assignment to.