Proven Steps and Guidelines for Building Quality Software

UPI Study › Courses › Software Engineering › Free lessons › Lesson 1.6 Free with a free account

Proven Steps and Guidelines for Building Quality Software

Software Engineering · Chapter 1: Foundations of Software Engineering and Process ModelsSection 1.6 · lesson 6 of 1038 min · free with a free account

← Designing with Objects: The OOAD ApproachNext lesson: Walking Through the Systems Development Life Cycle →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Separation of concerns, modularity, abstraction - and knowing how far to take them.

  • Explain what a design guideline is, and why engineers share them
  • Define separation of concerns, and spot it in a real system
  • Define modularity, cohesion, coupling, and abstraction
  • Explain the quality attributes they protect, and the risk of rigid use

Transcript

Everything said in the video, section by section (1,077 words). Read along, or search it.

Foundations of Software Engineering and Process Models

Guidelines for Quality Software

Good software is rarely the result of reinventing every decision. This section sets out three of the most widely used design guidelines, separation of concerns, modularity, and abstraction. And the qualities they protect, along with why applying them too rigidly can backfire.

2 Teams, 1 Reservation System

Same Skill, Different Results

Imagine two teams asked to build the same reservation system. Team A treats every decision as brand new. Screen code reads straight from the database, business rules are scattered, and one long function handles everything. Team B works from a small set of principles nobody had to reinvent. Keep unrelated concerns apart. Build in self-contained pieces with clear interfaces. And hide detail behind simple names. Six months in, Team B can hand a new hire one piece of the system, without a week of explanation. A change to confirmation emails carries no risk to the seating chart. Team A's project has become something nobody wants to touch. Both teams had competent programmers. What separated them was working from guidelines generations of engineers had already tested.

Design Guidelines

Strong Defaults, Not Rigid Rules

A design guideline is a broadly validated rule of thumb, distilled from decades of practice. Experienced engineers apply it by default, rather than deriving a fresh answer for every decision. A guideline is not a rigid rule enforced by a tool. It is a strong default that still requires judgment, and can be set aside for a specific, considered reason. The guidelines here are structural. They describe how to shape software so it stays understandable and changeable as it grows, whatever it does. They are not the same as organization-wide quality management, or the techniques for making a running system reliable. Those come later in the course.

Figure 1

Separation of Concerns

Separation of concerns says that each distinct part of a problem, called a concern, should be handled by its own part of the software. When concerns are tangled, a change made for one reason risks breaking something unrelated. A reservation app shows the idea cleanly, with three layers. Presentation is what the customer sees and clicks. Redesigning a button's color stays inside it. Business logic decides whether a booking is valid, and a table is free. Changing the rule for how late a booking may run stays inside it. Data access stores and retrieves booking records. Switching to a new database engine stays inside it. Keeping them apart means a change to any one can be made, tested, and trusted, without rechecking the other two.

Modularity

Self-Contained Pieces, Clear Interfaces

Modularity says a system should be divided into modules. Each is a self-contained unit that does its job through a clearly defined interface, without the rest of the system knowing how it works inside. Two properties decide whether a module is well designed. Cohesion is how closely the responsibilities inside one module belong together. A highly cohesive module does one job. Coupling is how much one module depends on another module's internal details. Low coupling means a module can be changed, replaced, or tested largely on its own. The guideline in one line. Aim for high cohesion inside a module, and low coupling between modules. A module mixing unrelated jobs is hard to reuse. Modules reaching into each other's internals are hard to change safely.

Abstraction

Use It Without Knowing How It Works

Abstraction says a piece of software should be usable through a simple description of what it does, without its user understanding how. A developer calling a sort function does not need to know which sorting technique it uses. A driver pressing the accelerator does not need to understand the engine. Both rely on a simplified interface standing in for hidden detail. The same idea repeats at every level of a computing system. Hardware sits at the base. The operating system abstracts it, the programming language abstracts the operating system, and application code relies on the language. So a programmer writing an app never has to think about electrical signals. Abstraction and modularity work together. A module's interface is the abstraction it presents, and modularity gives abstraction a boundary to live at.

Table 3

What the Guidelines Protect

These guidelines are not pursued for their own sake. Each protects practical qualities. Understandability means working out what code does without tracing the whole system. Separation of concerns and abstraction support it most. Maintainability means making a change confidently, without side effects elsewhere. Low coupling supports it. Reusability means using a well-defined piece again, in a different context. High cohesion supports it. And testability means checking a piece on its own, without the rest of the system running. Modularity and abstraction support it.

Table 4

Guidelines, Not Guarantees

Each guideline is a default calibrated for the ordinary case, not a formula to maximize. Structure has diminishing, and eventually negative, returns. Too little structure gives tangled concerns. One module handles the screen, the rules, and the data, so no change is safe. Too much gives over-fragmentation. Trivial logic is split across dozens of tiny modules, and following one behavior means chasing it through many files. A leaky abstraction still forces its user to know the hidden detail, so it fails exactly when it is needed most. And tight coupling lets one module reach into another's internals, so one team's change breaks another team's code without warning. Imagine a team that splits every few lines of logic into its own module. Newcomers spend their time tracing one behavior across dozens of files. The guideline was not wrong. It was applied past the point where it served the qualities it exists to protect.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. A design guideline is a broadly validated rule of thumb, applied by default and set aside only for a specific reason. Separation of concerns means each distinct part of a problem, is handled by its own part of the software. Modularity divides a system into self-contained modules. An interface is the part of a module others may see and call. Cohesion is how closely a module's responsibilities belong together. Coupling is how much modules depend on each other's internals. And abstraction presents what something does, while hiding how it does it.

Key Takeaways

What to Carry Forward

To pull this together. A design guideline is a strong default, not a rigid law, and it still requires judgment. Separation of concerns keeps presentation, business logic, and data access apart, so a change in one does not endanger the others. Modularity aims for high cohesion within modules, and low coupling between them. Abstraction lets software be used through what it does, hiding how, and depends on modular boundaries. And applied mechanically, past the point where they help, these guidelines produce failures of their own, like over-fragmentation and leaky abstractions.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Proven Steps and Guidelines for Building Quality Software

What is separation of concerns in software design?
Separation of concerns means each distinct part of a problem should be handled by its own part of the software. A reservation app might use three layers: presentation for what users see, business logic for rules such as whether a table is free, and data access for storing records. A change to one layer can then be made and tested without rechecking the other two.
What is the difference between cohesion and coupling?
Cohesion measures how closely the responsibilities inside one module belong together, while coupling measures how much one module depends on another module's internal details. The guideline is high cohesion within modules and low coupling between them. A highly cohesive module does one job and is easier to reuse, and a loosely coupled module can be changed, replaced or tested largely on its own.
What is abstraction in software engineering?
Abstraction means presenting what a piece of software does while hiding how it does it. A developer calling a sort function does not need to know which sorting technique it uses. The idea repeats in layers: the operating system abstracts the hardware, a programming language abstracts the operating system, and application code relies on the language. A module's interface is the abstraction it presents.
Can software design principles like modularity be applied too much?
Yes. Design guidelines are strong defaults, not formulas to maximize, and structure has diminishing and eventually negative returns. Over-fragmentation splits trivial logic across dozens of tiny modules, so following one behavior means chasing it through many files. A leaky abstraction still forces users to know hidden details. Apply a guideline only as far as it serves understandability, maintainability, reusability and testability.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →