WHAT IS SOFTWARE ENGINEERING?
The IEEE Computer Society defines software engineering as “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. The study of approaches as in .”
They concluded that an engineering profession is characterized by several components:
- An initial professional education in a curriculum validated by society through accreditation
- Registration of fitness to practice via voluntary certification or mandatory licensing
- Specialized skill development and continuing professional education
- Communal support via a professional society
- A commitment to norms of conduct often prescribed in a code of ethics
This Guide contributes to the first three of these components. Articulating a Body of Knowledge is an essential step toward developing a profession because it represents a broad consensus regarding what a software engineering professional should know.
The Guide to the Software Engineering Body of Knowledge (SWEBOK) was established with the following five objectives:
1. To promote a consistent view of software engineering worldwide
2. To clarify the place—and set the boundary—of software engineering with respect to other disciplines such as computer science, project management, computer engineering, and mathematics
3. To characterize the contents of the software engineering discipline
4. To provide a topical access to the Software Engineering Body of Knowledge
5. To provide a foundation for curriculum development and for individual certification and licensing material
The SWEBOK Knowledge Areas (KAs)
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software quality
Related disciplines
Computer engineering
Project management
Computer science
Quality management
Management
Software ergonomics
Mathematics
Systems engineering
1. SOFTWARE REQUIREMENTS KA
A requirement is defined as a property that must be exhibited in order to solve some real-world problem.
The first knowledge subarea is Software Requirements Fundamentals. It includes definitions of software requirements themselves, but also of the major types of requirements: product vs. process, functional vs. nonfunctional, emergent properties. The subarea also describes the importance of quantifiable requirements and distinguishes between systems and software requirements.
The second knowledge subarea is the Requirements Process, which introduces the process itself, orienting the remaining five subareas and showing how requirements engineering dovetails with the other software engineering processes. It describes process models, process actors, process support and management, and process quality and improvement.
The third subarea is Requirements Elicitation, which is concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.
The fourth subarea, Requirements Analysis, is concerned with the process of analyzing requirements to - Detect and resolve conflicts between requirements. - Discover the bounds of the software and how it must interact with its environment. - Elaborate system requirements to software requirements.
Requirements analysis includes requirements classification, conceptual modeling, architectural design and requirements allocation, and requirements negotiation.
The fifth subarea is Requirements Specification. Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: system definition, system requirements specification, and software requirements specification. The subarea describes all three documents and the underlying activities.
The sixth subarea is Requirements Validation, the aim of which is to pick up any problems before resources are committed to addressing the requirements. Requirements validation is concerned with the process of examining the requirements documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.
The seventh and last subarea is Practical Considerations. It describes topics which need to be understood in practice. The first topic is the iterative nature of the requirements process. The next three topics are fundamentally about change management and the maintenance of requirements in a state which accurately mirrors the software to be built, or that has already been built. It includes change management, requirements attributes, and requirements tracing. The final topic is requirements measurement.
2. SOFTWARE DESIGN KA
According to the IEEE definition [IEEE 610.12-90], design is both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process.” The KA is divided into six subareas.
The first subarea presents Software Design Fundamentals, which form an underlying basis to the understanding of the role and scope of software design. These are general software concepts, the context of software design, the software design process, and the enabling techniques for software design.
The second subarea groups together the Key Issues in Software Design. They include concurrency, control and handling of events, distribution of components, error and exception handling and fault tolerance, interaction and presentation, and data persistence.
The third subarea is Software Structure and Architecture, the topics of which are architectural structures and viewpoints, architectural styles, design patterns, and, finally, families of programs and frameworks.
The fourth subarea describes Software Design Quality Analysis and Evaluation. While there is a entire KA devoted to software quality, this subarea presents the topics specifically related to software design. These aspects are quality attributes, quality analysis, and evaluation techniques and measures.
The fifth subarea is Software Design Notations, which are divided into structural and behavioral descriptions.
The last subarea describes Software Design Strategies and Methods. First, general strategies are described, followed by function-oriented design methods, object-oriented design methods, data-structure-centered design, component- based design, and others.
3. SOFTWARE CONSTRUCTION KA
Software construction refers to the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. The KA includes three subareas.
The first subarea is Software Construction Fundamentals. The first three topics are basic principles of construction: minimizing complexity, anticipating change, and constructing for verification. The last topic discusses standards for construction.
The second subarea describes Managing Construction. The topics are construction models, construction planning, and construction measurement.
The third subarea covers Practical Considerations. The topics are construction design, construction languages, coding, construction testing, reuse, construction quality, and integration.
4. SOFTWARE TESTING KA
Software Testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior. It includes five subareas.
It begins with a description of Software Testing Fundamentals. First, the testing-related terminology is presented, then key issues of testing are described, and finally the relationship of testing to other activities is covered.
The second subarea is Test Levels. These are divided between the targets of the tests and the objectives of the tests.
The third subarea is Test Techniques. The first category includes the tests based on the tester’s intuition and
experience. A second group comprises specification-based techniques, followed by code-based techniques, fault-based techniques, usage-based techniques, and techniques relative to the nature of the application. A discussion of how to select and combine the appropriate techniques is also presented.
The fourth subarea covers Test-Related Measures. The measures are grouped into those related to the evaluation of the program under test and the evaluation of the tests performed.
The last subarea describes the Test Process and includes practical considerations and the test activities.
5. SOFTWARE MAINTENANCE KA
Once in operation, anomalies are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle commences upon delivery, but maintenance activities occur much earlier. The Software Maintenance KA is divided into four subareas.
The first one presents Software Maintenance Fundamentals: definitions and terminology, the nature of maintenance, the need for maintenance, the majority of maintenance costs, the evolution of software, and the categories of maintenance.
The second subarea groups together the Key Issues in Software Maintenance. These are the technical issues, the management issues, maintenance cost estimation, and software maintenance measurement.
The third subarea describes the Maintenance Process. The topics here are the maintenance processes and maintenance activities.
Techniques for Maintenance constitute the fourth subarea. These include program comprehension, re-engineering, and reverse engineering.
No hay comentarios:
Publicar un comentario