Hello, and welcome to the course Engineering Practices for Building Quality Software. This course will expand on many aspects of the software development process model that you may have already learned from other resources or courses, especially if you've already completed the other courses within this specialization. Quality is an elusive concept. What does it mean to be good? There are a number ways we can look at quality, and a lot of different perspectives to view that quality. And unfortunately, those measures of quality can conflict with each other. What is good for one stakeholder may not be good for another. Even more, increasing quality for someone might directly decrease quality in the eyes of another stakeholder. Even improving quality for one user type can make another user type feel as though their quality has gone down even if it hasn't. Quality is something that every stakeholder wants, they want quality for their money. We as developers and engineers want quality to be created from our work and users want what they use to be of good quality as well. This course is meant to provide you with an introduction into these various perspectives and measures of quality. Over the next four modules, we're going to be investigating the quality practices across these four groups, Design, Architecture and Security Implementation, which is development, and finally, in Testing and Deployment. If you're looking for requirements quality practices, these are covered quite effectively through the prior courses in this specialization. Quality practice in the maintenance life cycle stage is most commonly found in bug fixing and refactoring areas. We aren't covering those directly in this course, but following the quality practices in these areas, especially Design, Implementation, and Testing, should provide benefits throughout the maintenance lifespan of your software systems. Starting off, we'll tackle quality in software design. We'll begin by defining what good design means from the software development perspective. Then we'll look at quality metrics, quantitative measures of software quality criteria, data-driven decision-making can't happen without the data. So, you'll learn some effective metrics to support your quality arguments. Software design patterns are effectively best practice solutions to common problems. By having a vocabulary of design patterns, not only can you better communicate design with your teams but you'll have a toolbox of ready-made and easily adaptable solutions with the backing of the entire design community at your disposal. Architectural concerns are those that sit above the solution space. Making decisions about software in the enterprise viewpoint, means identifying the outer pressures on the system and how the system will meet those goals. Doing this can be a very difficult thing to do without planning. Everybody wants their software to be secure and usable and performant and a bunch of other good things. But how secure does it need to be, do we have the skills and tools to make that happen? Can we get them? And once you've made all those decisions, you still need to prove it, the software will be easy to use. What does that mean to be easy to use? How easy, for whom? How long do they need to use the system before it's easy? Especially when you're working under contract, it's important to know how you're going to meet those requirements. The third module is Implementation. Here we'll investigate an array of lectures and readings to help you gain an appreciation of not only what's out there but how it can help you provide quality throughout the development process. Code style, it's one thing to develop software on your own. It's entirely another to code with a team. It's difficult enough to understand code with which you're not familiar even if it's your code that you wrote six months ago. Adding in unfamiliar format and convention, only compounds the problem. Following a coding standard aims to at least reduce confusion by establishing a single benchmark against which the format and naming conventions can be compared to ensure consistency within a code base. And tools can help your team remain in compliance. Debuggers are mystical objects to those unfamiliar. But for those who take just a short time to become acquainted with them, they can save you and your team countless hours by providing debugging mechanisms that go beyond adding print statements where you think there are problems. Documentation, but at least this time it's documentation that's in the code. This is more than just repeating what the code does, it's about why and how, the intent of the code and other considerations like things you tried but didn't work. So that future readers including future you, don't repeat past mistakes and can quickly understand the purpose of the code being read. From comments to self-documenting code, we'll look at a few methods of providing benefits of documentation without leaving the home row of your keyboard. Build process is something that many developers never think about, Alt, Tab, Up arrow, and Enter, are all some coders ever use. But a true engineer knows that repeatability and scripting are not only time savers but far less error-prone. Making use of today's and even last decade's build tools can make the development process much more consistent and reliable. Last we'll tackle two topics which often get neglected. Testing is incredibly important and will become even more so as the code we develop has higher and higher chances of making it into the hands or watches or fridges or cars of our users. The activities in this module will help you understand what it means to do good testing and will give you a perspective of how leading with testing rather than seeing it as an end-stage task can help improve the quality of software. Continuous integration is something that has very quickly become popular, even for individual developers. And Continuous Deployment and its new cousin, Continuous Delivery, are concepts following just behind. How we go about incorporating our code into the team's code and how that code gets built and even delivered to the user directly is something that has more and more support for automated performance and improved success. This course is intended to take you beyond what the system will do to how the system should do it and how well. Quality is usually in the eye of the beholder, which means you need to consider all the viewpoints within the system space before you can decide what quality actually is and how to accomplish it. Each of the six areas that we will investigate will show you the ways we consider and measure quality. It's a delicate balance between what users, clients, developers, testers, and others, each see as quality regardless of the stage you're at in the lifecycle. But by identifying these quality concerns early and measuring them often, we can do a much better job of being successful at building our software.
