- ES Español
- EN English
2.13. Software Engineering (SE)
As far back as the early 1970s, British computer scientist Brian Randell allegedly said, "Software engineering is the multi-person construction of multi-version programs.'' This is an essential insight: while programming is the skill that governs our ability to write a program, software engineering is distinct in two dimensions: time and people.
First, a software engineering project is a team endeavor; being a solitary programming expert is insufficient. Skilled software engineers must demonstrate expertise in communication and collaboration. Programming may be an individual activity, but software engineering is a collaborative one, deeply tied to issues of professionalism, teamwork, and communication.
Second, a software engineering project is usually "multi-version.'' It has an expected lifespan; it needs to function properly for months, years, or decades. Features may be added or removed to meet product requirements. The engineering team itself will likely change. The technological context will shift, as our computing platforms evolve, programming languages change, dependencies upgrade, etc. This exposure to matters of time and change is novel when compared to a programming project: it isn't enough to build a thing that works, instead it must work and stay working. Many of the most challenging topics in tech share "time will lead to change'' as a root cause: backward compatibility, version skew, dependency management, schema changes, protocol evolution.
Software engineering presents a particularly difficult challenge for learning in an academic setting. Given that the major differences between programming and software engineering are time and teamwork, it is hard to generate lessons that *require* successful teamwork and that faithfully present the challenges of time. Additionally, some topics in software engineering will be more authentic and more relevant if our learners experience collaborative and long-term software engineering projects *in vivo* rather than in the classroom. Regardless of whether that happens as an internship, involvement in an open-source project, or full-time engineering role, a month of full-time hands-on experience has more available hours than the average software engineering course.
Thus, a software engineering curriculum must focus on concepts needed by most new-graduate hires, and that either are novel for those who are trained primarily as programmers, or that are abstract concepts that may not get explicitly stated/shared on the job. Such topics include, but are not limited to:
- Testing
- Teamwork, collaboration
- Communication
- Design
- Maintenance and evolution
- Software engineering tools
All evidence suggests that the role of software in our society will continue to grow for the foreseeable future. Additionally, the era of "two programmers in a garage'' seems to have drawn to a close. Most important software these days is a team effort, building on existing code and leveraging existing functionality. The study of software engineering skills is a deeply important counterpoint to the everyday experience of computing students - we must impress on them the reality that few software projects are managed by writing from scratch as a solo endeavor. Communication, teamwork, planning, testing, and tooling are far more important as our students move on from the classroom and make their mark on the wider world.
Although most CS graduates will go on to an industry position that requires this material, the CS Core topics presented here are of value regardless of whether graduates go on to industry or academia.
2.13.1. SE/Team Collaboration and Dynamics (CS Core: 2 hrs, KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Effective communication, including oral and written, as well as formal (email, docs, comments, presentations) and informal (team chat, meetings). Technical and Professional Communication , Team Communication and Culture
- Common causes of team conflict, and approaches for conflict resolution.
- Cooperative programming:
- Pair programming or Swarming
- Code review
- Collaboration through version control enumerate
- Roles and responsibilities in a software team: Ethics Codes and Legal Accountability , Professional Responsibility and Public Policy , Professional Values, Nature and Continuing Development , Ethical Dissent and Cultural Context , Workplace Ethics
- Advantages of teamwork
- Risks and complexity of such collaboration enumerate
- Team processes - responsibilities for tasks, effort estimation, meeting structure, work schedule
Learning Outcomes:
Core:
- Follow effective team communication practices [Analyze]
- Articulate the sources of, hazards of, and potential benefits of team conflict - especially focusing on the value of disagreeing about ideas or proposals without insulting people [Articulate]
- Facilitate a conflict-resolution and problem-solving strategy in a team setting [Analyze]
- Collaborate effectively in cooperative development/programming [Analyze]
- Propose and delegate necessary roles and responsibilities in a software development team [Propose]
- Compose and follow an agenda for a team meeting [Compose]
- Facilitate through involvement in a team project, the central elements of team building, establishing healthy team culture, and team management including creating and executing a team work plan [Create]
2.13.2. SE/Diversity, Stakeholders and Distributed Teams (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Core
- Importance of team diversity and inclusivity. Technical and Professional Communication , Team Communication and Culture
- Interfacing with stakeholders, as a team:
- Management & other non-technical teams
- Customers
- Users enumerate
- Risks associated with physical, distributed, hybrid, and virtual teams - including communication, perception, structure, points of failure, mitigation, and recovery, etc.
Learning Outcomes:
Core:
- Promote the importance of and benefits that diversity and inclusivity brings to a software development team [Defend]
- Reference, as a team, the importance of, and strategies to interface with stakeholders outside the team on both technical and non-technical levels [Reference]
- Enumerate the risks associated with physical, distributed, hybrid, and virtual teams and possible points of failure and how to mitigate against and recover/learn from failures [Enumerate]
2.13.3. SE/Version Control and CI/CD (CS Core: 1 hr, KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Software configuration management and version control: Software Development Practices
- Configuration in version control, reproducible builds/configuration.
- Version control branching strategies. Development branches vs release branches. Trunk-based development.
- Merging/rebasing strategies, when relevant. enumerate
- Release management.
- Testing tools including static and dynamic analysis tools. Software Development Practices , Information Flow and Non-Interference , Injection and Input Validation , Memory Safety and Types , Malware Analysis and Advanced Security
- Software process automation:
- Build systems - the value of fast, hermetic, reproducible builds, compare/contrast approaches to building a project.
- Continuous Integration (CI) - the use of automation and automated tests to do preliminary validation that the current head/trunk revision builds and passes (basic) tests.
- Continuous Deployment (CD) - the use of automation to automatically release every change that passes the automated tests to the production environment, ensuring frequent and reliable deliveries.
- Dependency management - updating external/upstream dependencies, package management, SemVer. enumerate
Learning Outcomes:
Core:
- Describe the difference between centralized and distributed software configuration management [Describe]
- Describe how version control can be used to help manage software release management [Describe]
- Identify configuration items and use a source code control tool in a small team-based project [Analyze]
- Describe how available static and dynamic test tools can be integrated into the software development environment [Describe]
- Understand the use of CI/CD systems as a ground-truth for the state of the team's shared code (build and test success) [Explain]
2.13.4. SE/Development Environment and IDE (CS Core: 1 hr, KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Design and communication tools (docs, diagrams, common forms of design diagrams like UML).
- Tool integration concepts and mechanisms. Software Development Practices
- Use of modern IDE facilities - debugging, refactoring, searching/indexing, ML-powered code assistants, etc. Software Development Practices
Learning Outcomes:
Core:
- Describe the issues that are important in selecting a set of tools for the development of a specific software system, including tools for requirements tracking, design modeling, implementation, build automation, and testing [Describe]
- Demonstrate the capability to use software tools in support of the development of a software product of medium size [Demonstrate]
2.13.5. SE/Requirements Engineering (KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Describe functional requirements using, for example, use cases or user stories.
- Using at least one method of documenting and structuring functional requirements.
- Understanding how the method supports design and implementation.
- Strengths and weaknesses of using a specific approach. enumerate
- Properties of requirements including consistency, validity, completeness, and feasibility.
- Requirements elicitation.
- Sources of requirements, for example, users, administrators, or support personnel.
- Methods of requirement gathering, for example, surveys, interviews, or behavioral analysis. enumerate
- Non-functional requirements, for example, security, usability, or performance, also called as Quality Attributes. Sustainable Design and Pervasive Computing , Environmental Footprint of Computing Systems , Systemic Effects and Social Context
- Risk identification and management, including ethical considerations surrounding the proposed product. Ethics Codes and Legal Accountability , Professional Responsibility and Public Policy , Professional Values, Nature and Continuing Development , Ethical Dissent and Cultural Context , Workplace Ethics
- Communicating and/or formalizing requirement specifications.
Learning Outcomes:
Core:
- Compare different methods of eliciting requirements along multiple axes [Compare]
- Identify differences between two methods of describing functional requirements (e.g., customer interviews, user studies) and the situations where each would be preferred [Analyze]
- Identify which behaviors are required, allowed, or barred from a given set of requirements and a list of candidate behaviors [Analyze]
- Collect a set of requirements for a simple software system [Analyze]
- Identify areas of a software system that need to be changed, given a description of the system and a set of new requirements to be implemented [Analyze]
- Identify the functional and non-functional requirements in a set of requirements [Analyze]
2.13.6. SE/Requirements Evolution and Estimation (KA Core: 1 hr) ↑ Back to top
Topics:
Non Core
- Prototyping a tool for both eliciting and validating/confirming requirements.
- Product evolution: when requirements change, how to understand what effect that has and what changes need to be made.
- Effort estimation:
- Learning techniques for better estimating the effort required to complete a task;
- Practicing estimation and comparing it to how long tasks take;
- Effort estimation is quite difficult, so students are likely to be way off in many cases, but seeing the process play out with their own work is valuable. enumerate
Learning Outcomes:
NonCore:
- Create a prototype of a software system to validate a set of requirements - building a mock-up, MVP, etc [Create]
- Estimate the time to complete a set of tasks, then compare estimates to the actual time taken [Estimate]
- Determine an implementation sequence for a set of tasks, adhering to dependencies between them, with a goal to retire risk as early as possible [Determine]
- Write a requirement specification for a simple software system [Write]
2.13.7. SE/Principles and Software Architecture (CS Core: 1 hr, KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- System design principles. System Reliability
- Levels of abstraction (e.g., architectural design and detailed design)
- Separation of concerns
- Information hiding
- Coupling and cohesion enumerate
- Software architecture. System Reliability
- Design paradigms
- Top-down functional decomposition/layered design
- Data-oriented architecture
- Object-oriented analysis and design
- Event-driven design enumerate
- Standard architectures (e.g., client-server and microservice architectures including REST discussions, n-layer, pipes-and-filters, Model View Controller)
- Identifying component boundaries and dependencies enumerate
- Programming in the large vs programming in the small. System Reliability
- Code smells and other indications of code quality, distinct from correctness. Security Design and Controls Engineering , Threat Analysis and Security Engineering , Trusted Computing and Privacy Engineering
Learning Outcomes:
Core:
- Identify the standard software architecture of a given high-level design [Analyze]
- Select and use an appropriate design paradigm to design a simple software system and explain how system design principles have been applied in this design [Evaluate]
- Adapt a flawed system design to better follow principles such as separation of concerns or information hiding [Create]
- Identify the dependencies among a set of software components in an architectural design [Analyze]
2.13.8. SE/API Design and Modeling (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Core
- API design principles
- Consistency
- Consistent APIs are easier to learn and less error-prone
- Consistency is both internal (between different portions of the API) and external (following common API patterns) enumerate
- Composability
- Documenting contracts
- API operations should describe their effect on the system, but not generally their implementation
- Preconditions, postconditions, and invariants enumerate
- Expandability
- Error reporting
- Errors should be clear, predictable, and actionable
- Input that does not match the contract should produce an error
- Errors that can be reliably managed without reporting should be managed enumerate enumerate
- Identifying and codifying data invariants and time invariants
- Structural and behavioral models of software designs
Learning Outcomes:
Core:
- Design an API for a single component of a large software system, including identifying and documenting each operation's invariants, contract, and error conditions [Design]
- Evaluate an API description in terms of consistency, composability, and expandability [Evaluate]
- Expand an existing design to include a new piece of functionality [Create]
2.13.9. SE/Software Design Quality and Evaluation (CS Core: 1 hr, KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Data design Data Modeling
- Data structures
- Storage systems enumerate
- Requirement traceability
- Understanding which requirements are satisfied by a design enumerate
Non Core
- Design modeling, for instance with class diagrams, entity relationship diagrams, or sequence diagrams
- Measurement and analysis of design quality
- Principles of secure design and coding Security Design and Controls Engineering , Threat Analysis and Security Engineering , Trusted Computing and Privacy Engineering
- Principle of least privilege
- Principle of fail-safe defaults
- Principle of psychological acceptability enumerate
- Evaluating design tradeoffs (e.g., efficiency vs reliability, security vs usability)
Learning Outcomes:
Core:
- Design a set of data structures to implement a provided API surface [Design]
- Identify which requirements are satisfied by a provided software design [Analyze]
NonCore:
- Translate a natural language software design into class diagrams [Translate]
- Adapt a flawed system design to better follow the principles of least privilege and fail-safe defaults [Create]
- Contrast two software designs across different qualities, such as efficiency or usability [Contrast]
2.13.10. SE/Coding Practices (CS Core: 1 hr, KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Practical small-scale testing Software Development Practices
- Unit testing
- Test-driven development - This is particularly valuable for students psychologically, as it is far easier to engage constructively with the challenge of identifying challenging inputs for a given API (edge cases, corner cases) a priori. If they implement first, the instinct is often to avoid trying to crash their new creation, while a test-first approach gives them the intellectual satisfaction of spotting the problem cases and then watching as more tests pass during the development process. enumerate
- Documentation Software Development Practices
- Interface documentation - describe interface requirements, potentially including (formal or informal) contracts, pre and post conditions, invariants.
- Implementation documentation should focus on tricky and non-obvious pieces of code, whether because the code is using advanced language features, or the behavior of the code is complex. (Do not add comments that re-state common/obvious operations and simple language features.)
- Clarify dataflow, computation, etc., focusing on what the code is.
- Identify subtle/tricky pieces of code and refactor to be self-explanatory if possible or provide appropriate comments to clarify. enumerate enumerate
- Coding style Software Development Practices
- Style guides
- Commenting
- Naming enumerate
- "Best Practices'' for coding: techniques, idioms/patterns, mechanisms for building quality programs Software Development Practices , Information Flow and Non-Interference , Injection and Input Validation , Memory Safety and Types , Malware Analysis and Advanced Security
- Defensive coding practices
- Secure coding practices and principles
- Using exception handling mechanisms to make programs more robust, fault-tolerant enumerate
- Debugging Software Development Practices
- Logging
- Use of libraries and frameworks developed by others Software Development Practices
Learning Outcomes:
Core:
- Write appropriate unit tests for a small component (several functions, a single type, etc.) [Write]
- Write appropriate interface and (if needed) implementation comments for a small component [Write]
- Describe techniques, coding idioms and mechanisms for implementing designs to achieve desired properties such as reliability, efficiency, and robustness [Describe]
- Write robust code using exception handling mechanisms [Write]
- Describe secure coding and defensive coding practices [Describe]
- Select and use a defined coding standard in a small software project [Use]
- Compare and contrast integration strategies including top-down, bottom-up, and sandwich integration [Compare]
- Describe the process of analyzing and implementing changes to code base developed for a specific project [Describe]
- Describe the process of analyzing and implementing changes to a large existing code base [Describe]
2.13.11. SE/Large-Scale Construction and Process (CS Core: 1 hr, KA Core: 2 hrs) ↑ Back to top
Topics:
Non Core
- Larger-scale testing
- Test doubles (stubs, mocks, fakes)
- Dependency injection enumerate
- Work sequencing, including dependency identification, milestones, and risk retirement
- Dependency identification: Identifying the dependencies between different tasks
- Milestones: A collection of tasks that serve as a marker of progress when completed. Ideally, the milestone encompasses a useful unit of functionality.
- Risk retirement: Identifying what elements of a project are risky and prioritizing completing tasks that address those risks. enumerate
- Potential security problems in programs Information Flow and Non-Interference , Injection and Input Validation , Memory Safety and Types , Malware Analysis and Advanced Security
- Buffer and other types of overflows
- Race conditions
- Improper initialization, including choice of privileges
- Input validation enumerate
- Documentation (autogenerated)
- Development context: "green field'' vs existing code base
- Change impact analysis
- Change actualization enumerate
- Release management
- DevOps practices
Learning Outcomes:
NonCore:
- Rewrite a simple program to remove common vulnerabilities, such as buffer overflows, integer overflows and race conditions [Apply]
- Write a software component that performs some non-trivial task and is resilient to input and run-time errors [Write]
2.13.12. SE/Verification and validation Concepts (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Core
- Verification and validation concepts
- Verification: Are we building the thing right?
- Validation: Did we build the right thing? enumerate
- Why testing matters: Does the component remain functional as the code evolves?
- Testing objectives
- Usability
- Reliability
- Conformance to specification
- Performance
- Security enumerate
Learning Outcomes:
Core:
- Explain why testing is important [Explain]
- Distinguish between program validation and verification [Distinguish]
- Describe different objectives of testing [Describe]
2.13.13. SE/Test Planning and Types (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Core
- Test kinds
- Unit
- Integration
- Validation
- System enumerate
- Stylistic differences between tests and production code: DAMP vs DRY - more duplication is warranted in test code.
- Test planning and generation
- Test case generation, from formal models, specifications, etc.
- Test coverage
- Test matrices
- Code coverage - how much of the code is tested?
- Environment coverage - how many hardware architectures, operating systems, browsers, etc. are tested? enumerate
- Test data and inputs enumerate
Learning Outcomes:
Core:
- Compare and contrast the different types and levels of testing (regression, unit, integration, systems, and acceptance) [Compare]
- Describe techniques for creating a test plan and generating test cases [Describe]
- Create a test plan for a medium-size code segment which includes a test matrix and generation of test data and inputs [Create]
- Implement a test plan for a medium-size code segment [Implement]
2.13.14. SE/Advanced Testing Practices (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Core
- Test development
- Test-driven development
- Object oriented testing, mocking, and dependency injection
- Opaque-box (previously, black-box) and transparent-box (previously, white-box) testing techniques
- Test tooling, including code coverage, static analysis, and fuzzing enumerate
- Verification and validation in the development cycle
- Code reviews
- Test automation, including automation of tooling
- Pre-commit and post-commit testing
- Tradeoffs between test coverage and throughput/latency of testing
- Defect tracking and prioritization: reproducibility of reported defects enumerate
- Domain specific verification and validation challenges
- Performance testing and benchmarking
- Asynchrony, parallelism, and concurrency
- Safety-critical
- Numeric enumerate
Learning Outcomes:
Core:
- Identify the fundamental principles of test-driven development methods and explain the role of automated testing in these methods [Analyze]
- Discuss issues involving the testing of object-oriented software [Debate]
- Describe mocking and dependency injection and their application [Describe]
- Undertake, as part of a team activity, a code review of a medium-size code segment [Evaluate]
- Describe the role that tools can play in the validation of software [Describe]
- Automate the testing in a small software project [Design]
- Explain the roles, pros, and cons of pre-commit and post-commit testing [Explain]
- Discuss the tradeoffs between test coverage and test throughput/latency and how this can impact verification [Debate]
- Use a defect tracking tool to manage software defects in a small software project [Use]
- Discuss the limitations of testing in certain domains [Debate]
2.13.15. SE/Testing Tools and Analysis (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Non Core
- Verification and validation tooling and automation
- Static analysis
- Code coverage
- Fuzzing
- Dynamic analysis and fault containment (sanitizers, etc.)
- Fault logging and fault tracking enumerate
- Test planning and generation
- Fault estimation and testing termination including defect seeding
- Use of random and pseudo random numbers in testing enumerate
- Testing asynchronous, parallel, and concurrent systems
- Verification and validation of non-code artifacts (documentation, training materials)
Learning Outcomes:
NonCore:
- Describe and compare different tools for verification and validation [Describe]
- Automate the use of different tools in a small software project [Design]
- Explain how and when random numbers should be used in testing [Explain]
- Describe approaches for fault estimation [Describe]
- Estimate the number of faults in a small software application based on fault density and fault seeding [Estimate]
- Describe techniques and issues with testing asynchronous, concurrent, and parallel software [Describe]
- Create a test plan for a medium-size code segment which contains asynchronous, concurrent, and/or parallel code, including a test matrix and generation of test data and inputs [Create]
- Describe techniques for the verification and validation of non-code artifacts [Describe]
2.13.16. SE/Performance Testing and Benchmarking (CS Core: 1 hr, KA Core: 1 hr) ↑ Back to top
Topics:
Non Core
- Performance testing and benchmarking
- Throughput and latency
- Degradation under load (stress testing, FIFO vs LIFO handling of requests)
- Speedup and scaling
- Amdahl's law
- Gustafson's law
- Soft and weak scaling enumerate
- Identifying and measuring figures of merits
- Common performance bottlenecks
- Compute-bound
- Memory-bandwidth bound
- Latency-bound enumerate
- Statistical methods and best practices for benchmarking
- Estimation of uncertainty
- Confidence intervals enumerate
- Analysis and presentation (graphs, etc.)
- Timing techniques enumerate
Learning Outcomes:
NonCore:
- Describe throughput and latency and provide examples of each [Describe]
- Explain speedup and the different forms of scaling and how they are computed [Explain]
- Describe common performance bottlenecks [Describe]
- Describe statistical methods and best practices for benchmarking software [Describe]
- Explain techniques for and challenges with measuring time when constructing a benchmark [Explain]
- Identify the figures of merit, construct and run a benchmark, and statistically analyze and visualize the results for a small software project [Analyze]
2.13.17. SE/API Compatibility and Versioning (KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Hyrum's Law/The Law of Implicit Interfaces
- Backward compatibility
- Compatibility is not a property of a single entity, it's a property of a relationship.
- Backward compatibility needs to be evaluated in terms of provider + consumer(s) or with a well-specified model of what forms of compatibility a provider aspires to/promises. enumerate
- Versioning
- Semantic Versioning (SemVer)
- Trunk-based development enumerate
Learning Outcomes:
Core:
- Identify both explicit and implicit behavior of an interface and identify potential risks from Hyrum's Law [Analyze]
- Identify changes that can be broadly considered "backward compatible,'' potentially with explicit statements about what usage is or is not supported [Analyze]
- Evaluate whether a proposed change is sufficiently safe given the versioning methodology in use for a given project [Evaluate]
2.13.18. SE/Refactoring Techniques (KA Core: 1 hr) ↑ Back to top
Topics:
Core
- Refactoring
- Standard refactoring patterns (rename, inline, outline, etc.)
- Use of refactoring tools in IDE
- Application of static-analysis tools (to identify code in need of refactoring, generate changes, etc.)
- Value of refactoring as a remedy for technical debt enumerate
Non Core
- "Large Scale'' Refactoring - techniques when a refactoring change is too large to commit safely (large projects), or when it is impossible to synchronize change between provider + all consumers (multiple repositories, consumers with private code).
- Express both old and new APIs so that they can co-exist.
- Minimize the size of behavior changes.
- Why these techniques are required, (e.g., "API consumers I can see'' vs "consumers I can't see''). enumerate
Learning Outcomes:
Core:
- Consider inputs from static analysis tools and/or Software Design principles to identify code in need of refactoring [Analyze]
- Refactor the implementation of an interface to improve design, clarity, etc. with minimal/zero impact on existing users [Create]
NonCore:
- Plan a complex multi-step refactoring to change default behavior of an API safely [Plan]
2.13.19. SE/Reliability Concepts (KA Core: 2 hrs) ↑ Back to top
Topics:
Core
- Concept of reliability as probability of failure or mean time between failures, and faults as cause of failures
- Identifying reliability requirements for different kinds of software
- Software failures caused by defects/bugs, and so for high reliability the goal is to have minimum defects - by injecting fewer defects (better training, education, planning), and by removing most of the injected defects (testing, code review, etc.)
- Software reliability, system reliability and failure behavior
- Defect injection and removal cycle, and different approaches for defect removal
- Compare the "error budget'' approach to reliability with the "error-free'' approach and identify domains where each is relevant.
Learning Outcomes:
Core:
- Describe how to determine the level of reliability required by a software system [Describe]
- Explain the problems that exist in achieving very high levels of reliability [Explain]
- Understand approaches to minimizing faults that can be applied at each stage of the software lifecycle [Explain]
2.13.20. SE/Reliability Engineering (KA Core: 1 hr) ↑ Back to top
Topics:
Non Core
- Software reliability models
- Software fault tolerance techniques and models
- Contextual differences in fault tolerance (e.g., crashing a flight critical system is strongly avoided, crashing a data processing system before corrupt data is written to storage is highly valuable) enumerate
- Software reliability engineering practices - including reviews, testing, practical model checking
- Identification of dependent and independent failure domains, and their impact on system reliability
- Measurement-based analysis of software reliability - telemetry, monitoring and alerting, dashboards, release qualification metrics, etc.
Learning Outcomes:
NonCore:
- Demonstrate the ability to apply multiple methods to develop reliability estimates for a software system [Demonstrate]
- Identify methods that will lead to the realization of a software architecture that achieves a specified level of reliability [Analyze]
- Identify ways to apply redundancy to achieve fault tolerance [Analyze]
- Identify single-point-of-failure (SPF) dependencies in a system design [Analyze]
2.13.21. SE/Formal Methods ↑ Back to top
Topics:
Non Core
- Formal specification of interfaces
- Specification of pre- and post- conditions
- Formal languages for writing and analyzing pre- and post-conditions. enumerate
- Problem areas well served by formal methods
- Lock-free programming, data races
- Asynchronous and distributed systems, deadlock, livelock, etc. enumerate
- Comparison to other tools and techniques for defect detection
- Testing
- Fuzzing enumerate
- Formal approaches to software modeling and analysis
- Model checkers
- Model finders enumerate
Learning Outcomes:
NonCore:
- Describe the role formal specification and analysis techniques can play in the development of complex software and compare their use as validation and verification techniques with testing [Describe]
- Apply formal specification and analysis techniques to software designs and programs with low complexity [Apply]
- Explain the potential benefits and drawbacks of using formal specification languages [Explain]