|
|
| (142 intermediate revisions by 14 users not shown) |
| Line 1: |
Line 1: |
| − | As observed in Part of 1 this body of knowledge, software is usually prominent in modern systems architectures and is often the glue for integrating complex system components. Software engineering and systems engineering are not merely related disciplines; they are intimately intertwined; see [[Intertwined Disciplines and the SEBoK]].
| + | ---- |
| − | | + | '''''Lead Authors:''''' ''Dick Fairley, Tom Hilburn'', '''''Contributing Authors:''''' ''Ray Madachy, Alice Squires'' |
| − | The SEBoK explicitly recognizes and embraces the intertwining between SE and SwE, which includes defining the relationship between the SEBoK and the Guide to The Software Engineering Body of Knowledge (SWEBOK), which is published by the IEEE (Abran et al. 2004).
| + | ---- |
| − | [external link: http://www.swebok.org]
| + | Software is prominent in most modern systems architectures and is often the primary means for integrating complex system components. {{Term|Software Engineering (glossary)|Software engineering}} and {{Term|Systems Engineering (glossary)|systems engineering}} are not merely related disciplines; they are intimately intertwined. (See [[Systems Engineering and Other Disciplines]].) Good systems engineering is a key factor in enabling good software engineering. |
| − | | |
| − | This knowledge area describes the nature of software, provides an overview of the 2004 SWEBOK Guide, describes the concepts that are shared by systems engineers and software engineers, and indicates the similarities and difference in how software engineers and systems engineers apply those concepts and use common terminology in similar and different ways.
| |
| | | | |
| − | ==On the Nature of Software==
| + | The SEBoK explicitly recognizes and embraces the intertwining between systems engineering and software engineering, as well as defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK) (Bourque, and Fairley 2014; IEEE Computer Society 2022). |
| | | | |
| − | The nature of the software medium has many consequences for systems engineering of software-intensive systems. Fred Brooks has famously observed that four properties of software, taken together, differentiate it from other kinds of engineering artifacts (Brooks 1995):
| + | This knowledge area describes the nature of software, provides an overview of the SWEBOK, describes the concepts that are shared by systems engineers and software engineers, and indicates the similarities and difference in how software engineers and systems engineers apply these concepts and use common terminology. It also describes the nature of the relationships between software engineering and systems engineering and describes some of the methods, models and tools used by software engineers. |
| | | | |
| − | #complexity
| + | ==Topics== |
| − | #conformity
| + | Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs, in turn, are divided into topics. This KA contains the following topics: |
| − | #changeability
| + | *[[Software Engineering in the Systems Engineering Life Cycle]] |
| − | #invisibility
| + | * [[The Nature of Software]] |
| | + | *[[An Overview of the SWEBOK Guide]] |
| | + | *[[Key Points a Systems Engineer Needs to Know about Software Engineering]] |
| | + | *[[Software Engineering Features - Models, Methods, Tools, Standards, and Metrics]] |
| | | | |
| − | Brooks states:
| + | ==Discussion== |
| | + | Software engineers, like systems engineers: |
| | + | *engage in analysis and design, allocation of requirements, oversight of component development, component integration, verification and validation, life cycle sustainment, and system retirement. |
| | + | *work with or as a component specialist (for example, user interface, database, computation, and communication specialists) who construct or otherwise obtain the needed software components. |
| | + | *adapt existing components and incorporate components supplied by customers and affiliated organizations. |
| | | | |
| − | <blockquote>Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).</blockquote>
| + | These commonalities would make it appear that software engineering is merely an application of systems engineering, but this is only a superficial appearance. The differences between the two disciplines arise from two fundamental concerns: |
| | + | #Differences in educational backgrounds (traditional engineering disciplines for SE and the computing disciplines for SWE) and work experiences that result in different approaches to problem solving, and |
| | + | #Different ways of applying shared concepts based on the contrasting natures of the software medium and the physical media of traditional engineering. |
| | | | |
| − | The complexity of software thus arises from the large number of unique, interacting parts in a software system. The parts are unique because they are encapsulated as functions, subroutines, or objects and invoked as needed rather than being replicated. Software parts have several different kinds of interactions, including serial and concurrent invocations, state transitions, data couplings, and interfaces to databases and external systems. Depiction of a software entity often requires several different design representations to portray the numerous static structures, dynamic couplings, and modes of interaction that exist in computer software. A seemingly “small” change in requirements is one of the many ways that complexity of the product may affect management of a project. Complexity within the parts and in the connections among parts may result in a large amount of rework for a “small” change in requirements, thus upsetting the ability to make progress according to plan. For this reason, many experienced software engineers say there are no small requirements changes. Complexity can also hide defects that may not be discovered immediately and thus require additional, unplanned rework later.
| + | Table 1 itemizes some of the shared concepts that are applied in different ways by systems engineers and software engineers. Each discipline has made contributions to the other. Table 1 indicates the methods and techniques developed by systems engineers adapted for use by software engineers and, conversely, those that have been adapted for use by systems engineers. |
| − | | |
| − | Software must conform to exacting specifications in the representation of each part, in the interfaces to other internal parts, and in the connections to the environment in which it operates. A missing semicolon or other syntactic error can be detected by a compiler but a defect in the program logic, or a timing error may be difficult to detect when encountered in operation. Unlike software, tolerance among the interfaces of physical entities is the foundation of manufacturing and assembly; no two physical parts that are joined together have, or are required to have, exact matches. There are no corresponding tolerances in the interfaces among software entities or between software entities and their environments. Interfaces among software parts must agree exactly in numbers and types of parameters and kind of couplings. There are no interface specifications for software stating that a parameter can be “an integer plus or minus 2%.”
| |
| − | | |
| − | Lack of conformity can cause problems when an existing software component cannot be reused as planned because it does not conform to the needs of the product under development. Lack of conformity might not be discovered until late in a project, thus necessitating development and integration of an acceptable component to replace the one that cannot be reused. This requires unplanned allocation of resources and can delay product completion. Complexity may have made it difficult to determine that the reuse component lacked the necessary conformity until the components it would interact with were completed.
| |
| − | | |
| − | Changeability is Brooks’ third factor that makes software development difficult. Software coordinates the operation of physical components and provides most of the functionality in software-intensive systems . Because software is the most easily changed element (i.e., the most malleable) in a software-intensive system, it is the most frequently changed element, particularly in the late stages of a development project or during system sustainment. This does not, however, mean that software is easy to change because of complexity and the need for conformity in software. Changing one part of a software system often results in undesired side effects in other parts of the system that must then be changed.
| |
| − | | |
| − | The fourth of Brooks’ factors is invisibility. Software is said to be invisible because it has no physical properties. While the effects of executing software on a digital computer are observable, software itself cannot be seen, tasted, smelled, touched, or heard; our five human senses are incapable of directly sensing software; software is thus an intangible entity. Work products such as requirements specifications, design documents, source code, and object code are representations of software but they are not the software. At the most elemental level, software resides in the magnetization and current flow in an enormous number of electronic elements within a digital device. Because software has no physical presence, software engineers use different representations, at different levels of abstraction, in an attempt to visualize the inherently invisible entity.
| |
| − | | |
| − | In addition to the four essential properties of software (complexity, conformity, changeability, and invisibility), one additional factor distinguishes software from other kinds of engineering artifacts (Fairley 2009):
| |
| − | | |
| − | <blockquote>software projects are team-oriented, intellect-intensive endeavors.</blockquote>
| |
| − | | |
| − | Clearly, other kinds of engineers, including systems engineers engage in team-oriented problem solving but, unlike other engineering artifacts, there is no fabrication phase for software. Software is composed from the thoughts of software engineers and flows though their fingers onto a keyboard and into a computer. Software teams are necessary because it would take too much time for one person to develop a modern software system and because it is unlikely that one individual would possess the necessary range of skills. It has been observed that the issues of team-oriented software development is similar to the issues that would be encountered if a team of authors were to write a novel as a collaborative project (Fairley 2009).
| |
| − | | |
| − | Software and software projects are unique for the following reasons:
| |
| − | | |
| − | *Software has no physical properties
| |
| − | *Software is the product of intellect-intensive teamwork
| |
| − | *Productivity of software developers is more widely variable than productivity in other engineering disciplines
| |
| − | *Estimation and planning for software projects is characterized by a high degree of uncertainty
| |
| − | *Risk management for software projects is predominantly process-oriented
| |
| − | *Software alone is useless; software is always part of a larger system
| |
| − | *Software is the most frequently changed element of systems that incorporate software
| |
| − | | |
| − | ==An Overview of the SWEBOK Guide==
| |
| − | | |
| − | The Preface to the 2004 version of the Guide to the Software Engineering Body of Knowledge states external link: http://www.swebok.org]:
| |
| − | | |
| − | <blockquote>The purpose of the Guide to the Software Engineering Body of Knowledge is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the Body of Knowledge supporting that discipline.</blockquote>
| |
| − | | |
| − | Version 3 of the SWEBOK Guide is being developed and will be completed in late 2011 or early 2012. Version 3 of the SWEBOK Guide contains 15 knowledge areas:
| |
| − | | |
| − | *Software Requirements
| |
| − | *Software Design
| |
| − | *Software Construction
| |
| − | *Software Testing
| |
| − | *Software Engineering Methods
| |
| − | *Software Maintenance
| |
| − | *Software Configuration Management
| |
| − | *Software Quality
| |
| − | *Software Engineering Process
| |
| − | *Software Engineering Management
| |
| − | *Software Professional Practice
| |
| − | *Software Economics
| |
| − | *Computing Foundations
| |
| − | *Mathematical Foundations
| |
| − | *Engineering Foundations
| |
| − | | |
| − | The description of each knowledge area includes an introduction, a descriptive breakdown of topics and sub-topics, recommended references, references for further reading, and a list of standards most relevant to the knowledge area.
| |
| − | | |
| − | The following table indicates the correspondences between SWEBOK knowledge areas and SEBoK knowledge areas. The similarities and differences are described below [{Systems Engineering and Software Engineering: Similarities and Differences}].
| |
| − | | |
| − | Table 1. Correspondences between SWEBOK and SEBoK Knowledge Areas
| |
| − | | |
| − | <blockquote>NOTE: Table 1 To be completed</blockquote>
| |
| − | | |
| − | The SWEBOK Guide also contains a chapter on related disciplines, which include:
| |
| − | | |
| − | *Computer Engineering
| |
| − | *Business Management
| |
| − | *Project Management
| |
| − | *Quality Management
| |
| − | *Systems Engineering
| |
| − | | |
| − | The related disciplines are those that share a boundary, and often a common intersection, with software engineering. The SWEBOK Guide does not characterize the knowledge of the related disciplines but rather indicates how those disciplines interact with the software engineering discipline.
| |
| − | | |
| − | ==Systems Engineering and Software Engineering: Similarities and Differences==
| |
| − | | |
| − | In order to describe the methods and techniques shared by software engineering and systems engineering, it is helpful to distinguish between the engineering of software and the construction of software. Software engineers, like systems engineers, engage in analysis and design, allocation of requirements, component integration, verification and validation, re-engineering of software systems, life cycle sustainment, and system retirement. Software specialists, who are often called programmers, construct software by engaging in detailed design, writing of code, unit testing, and integration of the software components. Programmers often modify existing software or obtain software components from libraries and publicly accessible (open) sources. Software engineers, like systems engineers, work with component specialists (e.g., user interface, database, computation, communication specialists) who construct or otherwise obtain the needed software components. Software engineers, like systems engineers, may be component specialists for certain kinds of components; they engage with other kinds of software component specialists as necessary. Sometimes, software engineers, like systems engineers, adapt existing components and incorporate components supplied by customers and affiliated organizations.
| |
| − | | |
| − | Each discipline has made contributions to the other. Table 1 indicates the methods and techniques developed by systems engineers adapted for use by software engineers, and conversely those that have been adapted for use by systems engineers. [reference Fairley’s ASEE paper] | |
| | | | |
| | <div style="text-align: center;"> | | <div style="text-align: center;"> |
| − | Table 1. Adaptation of Methods Across Systems Engineering and Software Engineering | + | <blockquote>'''Table 1. Adaptation of Methods Across SE and SWE (Fairley and Willshire 2011''') Reprinted with permission of Dick Fairley and Mary Jane Willshire. All other rights are reserved by the copyright owner. <nowiki>*</nowiki> |
| | + | </blockquote> |
| | </div> | | </div> |
| − |
| |
| | {| align="center" | | {| align="center" |
| | |- | | |- |
| Line 105: |
Line 40: |
| | | | | | |
| | *Stakeholder Analysis | | *Stakeholder Analysis |
| − | *Requirements Engineering | + | *Requirements Engineering |
| − | *Functional Decomposition | + | *Functional Decomposition |
| − | *Design Constraints | + | *Design Constraints |
| − | *Architectural Design | + | *Architectural Design |
| − | *Design Criteria | + | *Design Criteria |
| − | *Design Tradeoffs | + | *Design Tradeoffs |
| | *Interface Specification | | *Interface Specification |
| | *Traceability | | *Traceability |
| − | *Configuration Management | + | *Configuration Management |
| − | *Systematic Verification And Validation | + | *Systematic Verification and Validation |
| | | | |
| | | | | | |
| − | *Model-Driven Development | + | *Model-Driven Development |
| − | *Uml-Sysml | + | *UML-SysML |
| − | *Use Cases | + | *Use Cases |
| − | *Object-Oriented Design | + | *Object-Oriented Design |
| − | *Iterative Development | + | *Iterative Development |
| − | *Agile Methods | + | *Agile Methods |
| − | *Continuous Integration | + | *Continuous Integration |
| − | *Incremental V&V
| + | *Process Modeling |
| − | *Process Modeling | + | *Process Improvement |
| − | *Process Improvement | + | *Incremental Verification and Validation |
| − | | |
| − | |}
| |
| − | | |
| − | Software engineers, like systems engineers, are often involved in managing the technical aspects of a project or program. Thus, software engineers, like systems engineers need to understand how project management techniques, such as those included in the Project Management Institute’s Body of Knowledge (PMBOK®) are applied to technical management of software projects [insert references 2 and 3 plus an internal link to Systems Engineering and Project Management]
| |
| − | | |
| − | These commonalities would make it appear that software engineering is merely an application of systems engineering but this is only a surface appearance. The differences between the two disciplines arise from two fundamental issues:
| |
| − | | |
| − | *Differences in educational backgrounds and work experiences that result in different uses of shared terminology and different ways of applying the problem solving techniques listed in Table 1. | |
| − | | |
| − | *Differences in application of shared terminology based on the contrasting natures of the software medium and the physical media of traditional engineering
| |
| − | | |
| − | '''Education and Work Experience'''
| |
| − | | |
| − | Systems engineers typically receive traditional engineering educations based on continuous mathematics and physics; as a result, systems engineers, being traditional engineers, are strongly oriented to metrics and models. Software engineering education and work experience are typically based on discrete mathematics and information theory; software engineers approach problem solving from an algorithmic point of view. Systems engineers often think algorithmically and software engineers use metrics and models but the predominant mindsets and approaches to problem solving of systems engineers and software engineers are observably different.
| |
| − | | |
| − | '''Shared Terminology'''
| |
| | | | |
| − | Systems engineers and software engineers use common terms to denote different concepts. For example, "performance" is used by systems engineers to denote the entire operational envelope of a system whereas software engineers use "performance" to mean response time and throughput of a software-intensive system. "Iterative development" also had different connotations: Iteration cycle for software development may occur on a daily or weekly basis while the physical nature of physical system components typically involves iterative cycles of longer durations (sometimes months). Configuration management and version control have different connotations between the two disciplines: the frequent iterations of software development result in frequent incremental versions of evolving software, often on a weekly basis; whereas baselining of physical artifacts under development typically occurs at infrequent intervals. Risk management for development of hardware components is often concerned with issues such as supply chain management, material science, and manufacturability. In software engineering risk management often focuses on issues based on problems of communication and coordination within software development team, among software teams, and between software developers and other team members such as hardware developers, technical writers and those who perform independent verification and validation. The term "prototyping" also creates confusion: A hardware prototype is a typically a first, fully functioning version of a system. In software, prototyping is primarily used for two reasons: 1) as a mechanism to elicit requirements by iteratively evolving mock-ups of user interfaces and 2) as an experimental implementation of some limited elements of a system to explore and evaluate alternative algorithms.
| + | |} |
| | | | |
| − | Better understanding of these issues will enable systems engineers and software engineers to better communicate and to coordinate their work activities.
| + | The articles in this knowledge area give an overview of software and software engineering aimed at systems engineers. It also provides more details on the relationship between systems and software life cycles and some of the detailed tools used by software engineers. As systems become more dependent on software as a primary means of delivering stakeholder value, the historical distinction between software and systems engineering may need to be challenged. This is a current area of joint discussion between the two communities which will affect the future knowledge in both SEBoK and SWEBoK. |
| | | | |
| | ==References== | | ==References== |
| | | | |
| − | ===Citations=== | + | ===Works Cited=== |
| | | | |
| − | (Brooks 1995) Brooks, Fred. 1995. The Mythical Man-Month, Anniversary Edition. Boston, Massachusetts: Addison Weslley Longman Inc. | + | Bourque, P. and Fairley, R.E. (eds.). 2014. ''[[Guide to the Software Engineering Body of Knowledge (SWEBOK)]]''). Los Alamitos, CA, USA: IEEE Computer Society. Accessed May 25, 2023. Available at http://www.Swebok.org |
| | | | |
| − | (Fairley 2009) Fairley, Richard E. 2009. Managing and Leading Software Projects. Hoboken, New Jersey: John Wiley and Sons.
| + | Fairley, R.E. and Willshire M.J., 2011. ''Teaching systems engineering to software engineering students'', ''CSEET ''2011, Software Engineering Education and Training, p: 219-226, ISBN: 978-1-4577-0349-2. |
| | | | |
| − | (SWEBOK 2004) Abran et al. 2004. Guide to the Software Engineering Body of Knowledge (SWEBOK. Piscataway, New Jersey: The Institute of Electrical and Electronic Engineers, Inc.
| + | IEEE Computer Society. 2022. SWEBOK Guide Version 4.0 beta. Accessed August 28, 2023. Available at <nowiki>https://waseda.app.box.com/s/elnhhnezdycn2q2zp4fe0f2t1fvse5rn</nowiki>. |
| | | | |
| | + | ===Primary References=== |
| | | | |
| − | ===Primary References===
| + | Bourque, P. and R.E. Fairley (eds.). 2014. ''[[Guide to the Software Engineering Body of Knowledge (SWEBOK)]]''. Los Alamitos, CA, USA: IEEE Computer Society. Accessed May 25, 2023. Available at http://www.Swebok.org |
| | | | |
| − | (Brooks 1995) Brooks, Fred. 1995. [[The Mythical Man-Month]], Anniversary Edition. Boston, Massachusetts: Addison Weslley Longman Inc.
| + | Brooks, F. 1995. ''[[The Mythical Man-Month]],'' Anniversary Edition. Boston, MA, USA: Addison Wesley Longman Inc. |
| | | | |
| − | (Fairley 2009) Fairley, Richard E. 2009. [[Managing and Leading Software Projects]]. Hoboken, New Jersey: John Wiley and Sons.
| + | Fairley, R.E. 2009. ''[[Managing and Leading Software Projects]].'' Hoboken, NJ, USA: John Wiley and Sons. |
| | | | |
| | ===Additional References=== | | ===Additional References=== |
| | | | |
| − | (SWEBOK 2004) Abran et al. 2004. Guide to the Software Engineering Body of Knowledge (SWEBOK). Piscataway, New Jersey: The Institute of Electrical and Electronic Engineers, Inc.
| + | Pressman, R. 2009. ''Software Engineering: A Practitioner's Approach.'' 7th Ed. New York, NY, USA: McGraw Hill. |
| | | | |
| | + | Schneidewind, N. 2009. ''Systems and Software Engineering with Applications''. New York, NY, USA: Institute of Electrical and Electronics Engineers. |
| | + | |
| | + | Sommerville, I. 2010. ''Software Engineering.'' 9th Ed. Boston, MA, USA: Addison Wesley. |
| | + | |
| | ---- | | ---- |
| − | ====Article Discussion====
| |
| − | [[{{TALKPAGENAME}}|[Go to discussion page]]]
| |
| − | <center>[[Related Disciplines|<- Previous Article]] | [[Related Disciplines|Parent Article]] | [[The Nature of Software|Next Article ->]]</center>
| |
| | | | |
| − | ==Signatures==
| + | <center>[[Related Disciplines|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Software Engineering in the Systems Engineering Life Cycle|Next Article >]]</center> |
| − | --[[User:Bkcase|Bkcase]] 19:07, 22 August 2011 (UTC) (on behalf of Dick Fairley)
| + | |
| | + | <center>'''SEBoK v. 2.10, released 06 May 2024'''</center> |
| | | | |
| − | [[Category: Part 6]][[Category:Knowledge Area]] | + | [[Category: Part 6]] |
| | + | [[Category:Knowledge Area]] |
Lead Authors: Dick Fairley, Tom Hilburn, Contributing Authors: Ray Madachy, Alice Squires
Software is prominent in most modern systems architectures and is often the primary means for integrating complex system components. Software engineeringSoftware engineering and systems engineeringsystems engineering are not merely related disciplines; they are intimately intertwined. (See Systems Engineering and Other Disciplines.) Good systems engineering is a key factor in enabling good software engineering.
The SEBoK explicitly recognizes and embraces the intertwining between systems engineering and software engineering, as well as defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK) (Bourque, and Fairley 2014; IEEE Computer Society 2022).
This knowledge area describes the nature of software, provides an overview of the SWEBOK, describes the concepts that are shared by systems engineers and software engineers, and indicates the similarities and difference in how software engineers and systems engineers apply these concepts and use common terminology. It also describes the nature of the relationships between software engineering and systems engineering and describes some of the methods, models and tools used by software engineers.
Topics
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs, in turn, are divided into topics. This KA contains the following topics:
Discussion
Software engineers, like systems engineers:
- engage in analysis and design, allocation of requirements, oversight of component development, component integration, verification and validation, life cycle sustainment, and system retirement.
- work with or as a component specialist (for example, user interface, database, computation, and communication specialists) who construct or otherwise obtain the needed software components.
- adapt existing components and incorporate components supplied by customers and affiliated organizations.
These commonalities would make it appear that software engineering is merely an application of systems engineering, but this is only a superficial appearance. The differences between the two disciplines arise from two fundamental concerns:
- Differences in educational backgrounds (traditional engineering disciplines for SE and the computing disciplines for SWE) and work experiences that result in different approaches to problem solving, and
- Different ways of applying shared concepts based on the contrasting natures of the software medium and the physical media of traditional engineering.
Table 1 itemizes some of the shared concepts that are applied in different ways by systems engineers and software engineers. Each discipline has made contributions to the other. Table 1 indicates the methods and techniques developed by systems engineers adapted for use by software engineers and, conversely, those that have been adapted for use by systems engineers.
Table 1. Adaptation of Methods Across SE and SWE (Fairley and Willshire 2011) Reprinted with permission of Dick Fairley and Mary Jane Willshire. All other rights are reserved by the copyright owner. *
Systems Engineering Methods
Adapted to Software Engineering
|
Software Engineering Methods
Adapted to Systems Engineering
|
- Stakeholder Analysis
- Requirements Engineering
- Functional Decomposition
- Design Constraints
- Architectural Design
- Design Criteria
- Design Tradeoffs
- Interface Specification
- Traceability
- Configuration Management
- Systematic Verification and Validation
|
- Model-Driven Development
- UML-SysML
- Use Cases
- Object-Oriented Design
- Iterative Development
- Agile Methods
- Continuous Integration
- Process Modeling
- Process Improvement
- Incremental Verification and Validation
|
The articles in this knowledge area give an overview of software and software engineering aimed at systems engineers. It also provides more details on the relationship between systems and software life cycles and some of the detailed tools used by software engineers. As systems become more dependent on software as a primary means of delivering stakeholder value, the historical distinction between software and systems engineering may need to be challenged. This is a current area of joint discussion between the two communities which will affect the future knowledge in both SEBoK and SWEBoK.
References
Works Cited
Bourque, P. and Fairley, R.E. (eds.). 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK)). Los Alamitos, CA, USA: IEEE Computer Society. Accessed May 25, 2023. Available at http://www.Swebok.org
Fairley, R.E. and Willshire M.J., 2011. Teaching systems engineering to software engineering students, CSEET 2011, Software Engineering Education and Training, p: 219-226, ISBN: 978-1-4577-0349-2.
IEEE Computer Society. 2022. SWEBOK Guide Version 4.0 beta. Accessed August 28, 2023. Available at https://waseda.app.box.com/s/elnhhnezdycn2q2zp4fe0f2t1fvse5rn.
Primary References
Bourque, P. and R.E. Fairley (eds.). 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). Los Alamitos, CA, USA: IEEE Computer Society. Accessed May 25, 2023. Available at http://www.Swebok.org
Brooks, F. 1995. The Mythical Man-Month, Anniversary Edition. Boston, MA, USA: Addison Wesley Longman Inc.
Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley and Sons.
Additional References
Pressman, R. 2009. Software Engineering: A Practitioner's Approach. 7th Ed. New York, NY, USA: McGraw Hill.
Schneidewind, N. 2009. Systems and Software Engineering with Applications. New York, NY, USA: Institute of Electrical and Electronics Engineers.
Sommerville, I. 2010. Software Engineering. 9th Ed. Boston, MA, USA: Addison Wesley.
< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024