CS302 Study Guide

Navigating this Study Guide

Study Guide Structure

In this study guide, the sections in each unit (1a., 1b., etc.) are the learning outcomes of that unit. 

Beneath each learning outcome are:

• questions for you to answer independently;
• a brief summary of the learning outcome topic; and
• and resources related to the learning outcome. 

At the end of each unit, there is also a list of suggested vocabulary words.

How to Use this Study Guide

1. Review the entire course by reading the learning outcome summaries and suggested resources.
2. Test your understanding of the course information by answering questions related to each unit learning outcome and defining and memorizing the vocabulary words at the end of each unit.

By clicking on the gear button on the top right of the screen, you can print the study guide. Then you can make notes, highlight, and underline as you work.

Through reviewing and completing the study guide, you should gain a deeper understanding of each learning outcome in the course and be better prepared for the final exam!

Unit 1: Introduction to Software Engineering

1a. Explain software engineering and what software engineers do

• Why study software engineering?
• Are software engineering, computer science, and other related disciplines, such as computer engineering or information technology, names for the same topics?

We want to study software so that we can write software programs to solve problems or perform useful tasks. Computer Science helps us understand software, while software engineering applies that understanding to developing software systems to solve problems or perform useful tasks. Software engineering also helps us understand the benefits and risks of using software systems. It is changing the scale, scope, and access speed of information – to Big Data, the world, to fractions of a second. The introduction software engineering video illustrates the development of a software solution for a useful task. Software is ubiquitous in our daily lives and the control of our devices – it runs our phones, televisions and entertainment devices, kitchen appliances, medical equipment, cars, airplanes, and defense equipment. It transforms our society, individual and group interactions, business operations, news, government, and health services.

Computer science is the study of algorithms. Computer engineering is the study of hardware devices that can execute algorithms. Information technology and software engineering share techniques, methods, tools, and processes. Software engineering uses project management to plan, monitor, and control projects for software life-cycle activities. Software engineering is engineering and computer science oriented, whereas information technology is project management and technology-oriented. Information technology focuses on the operation and application of software systems.

To review, see Introduction to Software Engineering.

1b. Identify the differences between software engineering, computer science, and computer engineering

• Are software engineering and computer science the same?
• What do Software Engineers do?
• What artifacts or products do software engineers create?
• How do software engineers create them?

Computer Science and Software Engineering overlap topically but differ in emphasis. In software engineering, the focus is on applying computer science to solving useful problems. It assumes we have background knowledge of software. In software engineering, we study the processes for creating software to solve specific problems or perform tasks, the characteristics of software that contribute to a good solution, the description of problems, and software methodologies that guide the efficient and effective development of quality software.

Every discipline is an evolving body of knowledge directed at a fundamental goal. A body of knowledge consists of concepts, principles, and models, particularly for science and engineering disciplines. The Software Engineering body of knowledge aims to develop and maintain useful and needed software systems efficiently and effectively. Software engineers apply this knowledge to achieve that goal.

Software engineers create software systems by applying the Software Engineering body of knowledge to develop a clear description of software needs, called the software requirements, and a series of related software products, including a requirements specification, software design, software implementation, and software tests, and the completed software system.

The artifacts and products are the requirements specification (specification of "what"), design (specification of "what" components and structures comprise the system and "how" the system shall perform), code/implementation (specification of "how" each component shall perform), integration/testing (specification of "how" the system performs).

To create these artifacts and products, software engineers perform a series of phased activities, called the Software Development Life-Cycle (SDLC), that transform the requirements into a software design, activities that alter the design into software code, and activities that change the code into an integrated and verified functional maintainable software system. A software engineer performs these activities as a team member and may take on several technical and management roles. Each phase activity produces an SDLC artifact, using a representation supporting a model to build the desired software product and system. A representation is a technical narrative, diagram, mathematical specification, or programming language procedure that describes the structure of the system and its operation. Each model comprises processes, procedures, methodologies, tools, and techniques. This course discusses three types of models: data-oriented, process-oriented, and object-oriented.

To review, see Fundamentals of Software Engineering.

1c. Categorize software by characteristics and types

• Is software engineering another term for software development?
• Why categorize software?

Software engineering includes software development and other parts of the software life-cycle: defining the problem or task, organizing and managing the resources for efficient and effective software development, and maintaining software products over the life-cycle. It also includes integrating organizational, business, project, and personnel goals, working in teams, communicating with stakeholders, and building and using tools to support software processes. Many of these activities were motivated by the issues of the Software Crisis from 1965-1985. These give a glimpse of the past, current, and future of software engineering.

To address efficiency and effectiveness, we define software categories and terms that help us understand the problems and tasks requiring performance (the problem space). Additionally, as there are typically many software solutions, we identify the characteristics and attributes that describe a desired software system (the solution space). In general, problems can be familiar or unfamiliar and unprecedented, solvable or unsolvable by software; solutions can have limited scale, scope, processing, and access time or involve significant risk.

To review, see The History of Software and Fundamentals of Software Engineering.

1d. Describe the attributes of good software

• How is software quality determined?

Software Engineering addresses both the problem and the solution. We actively seek effective solutions that resolve problems, determine user needs, and maintain high quality commensurate with the importance of the problem or task. We actively define quality as meeting the satisfaction of significant stakeholders' needs, including cost, schedule, functionality, and technology. We document these needs in a Requirements Specification. Some software attributes, like "user-friendliness" and reliability, are quantitative and measurable, while others are qualitative and not easily measured. Attributes actively interrelate in various ways; consider integrity and reliability or maintainability and testability. Review the language used to help us understand software quality by addressing factors contributing to stakeholders' expectations and satisfaction.

To review, see Software Quality.

1e. Explain the code of ethics used in the professional practice of software engineering

• Why does software engineering have a code of ethics for professional practice?

Software engineering activities involve interaction with other members of a project team, with other internal groups, and with external organizations. We must actively safeguard principles, including privacy, confidentiality, and ownership rights of others, and conduct interactions professionally to build and maintain productive and pleasant working relationships. Moreover, software engineers make decisions that can impact others, the software development's success, and the software's operation after deployment. Those decisions affect the software's overall life-cycle phases" cost, schedule, functionality, and quality. It involves a code of ethics, which includes ethical principles, professional responsibilities, and organizational imperatives.

To review, see Ethics and Professional Practices.

Unit 1 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• body of knowledge
• code of ethics
• computer engineering
• computer science
• model
• quality
• representation
• Requirements Specification
• Software Development Life-Cycle (SDLC)
• software engineering

Unit 2: Software Development Life-Cycle

2a. Summarize the software development life-cycle (SDLC)

• What is a software development life-cycle?
• How do methods and methodologies pertain to life-cycles?
• What is a methodology?
• What is a method?
• Why is the period from 1965 to 1985 in the history of computing called the Software Crisis?
• Why do we have methods and methodologies?
• What are the names of the life-cycle models?
• How do life-cycle models support decomposition and composition?

A software life-cycle (SLC) is a model that covers the entire period of a software system from beginning to end (or "retirement"). A SLC has two main parts: Development (SDLC) and Maintenance. These models are primarily software project management tools. They serve as frameworks for identifying and organizing project work products and activities and specifying the sequencing and repetition of activities performed. 

An SDLC identifies development activities (process work breakdown) and project work products (product work breakdown). Methods and methodologies guide how to perform the activities and create the representations, or forms, of the work products. Using an object-orientation method will guide you in performing the analysis to identify classes and objects and specify the requirements with use cases.

Terms used in discussing software engineering are often informal and used as synonyms for other terms with similar but different meanings. For example, "method" and "methodology" are often used as synonyms. However, a method is a tool for performing the steps of a process, while methodology refers to the reasons or justification for using the method. The methodology in software engineering often implies a collection of related methods and tools. For example, an object-oriented methodology is an integrated collection of object-oriented requirements, design, and programming methods and tools.

Software engineering was born during the "software crisis" of 1965-1985. Software methods were one response to the issues of that period. Driven by software development issues and challenges, methods, and methodologies guide building representations and models that support the transition from the problem to an effective and efficient software solution.

You may have heard of the waterfall life-cycle, the most popular early sequential SDLC model. It eventually evolved into an iterative SDLC. As experience in using SDLCs increased and new programming language features emerged, developers introduced newer SDLCs. These include Spiral and Agile. The methodology focuses on the phase methods to create the phase product, and the model focuses on the product built by the methods. 

An SDLC usually has levels or phases of abstraction: analysis, design, implementation, and test phases. The sequencing of SDLCs usually begins with decomposition (in the problem space) via early phases and proceeds with composition (in the solution space) via the latter phases. Composition is often called test, integration, or synthesis. Decomposition is addressed by methods for analysis and design and composition by methods for implementation, integration, and test. The decomposition and composition paradigm will appear again in sections on models for the SDLC phases.

To review, see:

• Software Development Approaches
• Software Development Models
• Introduction to Software Systems
• Software Development Life-Cycle Methodologies
• Software Engineering Methodology

2b. Compare categories of life-cycle models, such as waterfall, incremental, and iterative models

• Why do you think there are categories of life-cycle models?
• What is the key difference between the categories of SDLCs?

Categories of life-cycle models are sequential or waterfall, iterative, and incremental. The earliest life-cycle models were sequential models. These models present a linear path from requirements to a desired system. They work well in an appropriate context: if the requirements are frozen, each phase catches errors made in the previous phase, and the application is well understood. Sequential SDLCs provide a large body of experience identifying their strengths and weaknesses.

Further, as the scope of applications expanded to larger and more complex systems, the risks of a linear sequential model increased. New applications are usually poorly understood, lack fixed requirements, have more development problems, and are subject to frequent change. The essential problem is a change caused by an error or a new specification. To mitigate risk, a life-cycle model must quickly catch errors, identify changes, and repeat phase activities. The development process introduced early implementation (prototyping and spiral) and iteration. The team developed and released the software in stages or cycles until the completion of software development. 

Moreover, we decomposed requirements into smaller, independent modules that we could prioritize and develop concurrently to address complexity and achieve faster implementation. Thus, addressing requirements in increments - earlier and faster, enabled building the software incrementally until the software development was complete. Iterative and incremental both improve software quality; iterative by developing multiple software releases, each improving the software solution; incremental by developing a subsystem solution for each requirements module, each adding features until the software development is complete. 

We have mentioned activities and phase work products (documentation or prototype software). In SDLCs, "who" refers to roles and stakeholders, but only at a group or team level and not at a task or individual level. For SDLCs, we can consider the software engineering team and interacting teams (like system engineering), project management, and customers. "What" refers to the phases, work products, and processes. "When" refers to the ordering of the phases and activities - sequential, concurrent, or iterative, and the start and end of a phase (for example, does coding appear late or early in the development cycle; do the two phases overlap, or are they performed in parallel?). "Where" refers to the location of the activities. "Why" refers to the need or problem that an SDLC addresses. "How" is more applicable to the methods and procedures used to perform the activities, which an SDLC does not usually specify. Each of the pronouns, except for "how", identifies a characteristic of an SDLC.

Using these as characteristics, we can identify two key differences between sequential, on the one hand, and iterative and incremental SDLCs, on the other hand. These differences are "when coding is performed" and the ability to repeat or redo parts of the development as needed early on. Coding appears relatively late in a sequential SDLC but early in an iterative SDLC (as the prototype) and early in an incremental SDLC (as the implementation of a high-priority requirements module. In a sequential SDLC, coding occurs during the coding and testing phases, and we may not catch errors in a sequential SDLC until coding and testing. Sequential SDLCs have the capability for repetition only back to the preceding phase. Iterative and incremental SDLCs can prototype areas with the greatest risk and even build a prototype early in the development cycle. 

To review, see Software Development Models and Introduction to Software Engineering Methodologies.

2c. Describe the differences between software development phases, activities, and deliverables

• How is a software system developed?

Software development phases, activities, and deliverables are elements of an SDLC, a model for planning, managing, and building a software system. The SDLC model organizes the development as a set of phases, including requirements, design, code, and test phases, which evolve a requirements model of a problem into a software system model that satisfies the requirements and, thus, solves the problem and is the software system delivered to the customer. Each phase consists of activities that create artifacts that comprise the phase model and produce a phase product (an artifact delivered to the customer) that is the input to the next phase. 

To review, see Introduction to Software Systems.

2d. List different roles that professionals such as system analysts, developers, and project managers play in software development processes

• What roles and responsibilities could the software engineering team undertake on a software development project?
• What responsibilities might be assigned to external teams?

We assign many roles and responsibilities to a software development project, including technical, administrative, and management, representing the organization, the project, and the project teams. Technical roles are systems, hardware, software, human factors, and process engineering. Administrative roles are hiring, training, cost, and schedule. Management roles are at the enterprise project and team level. Teams correspond to the project and phase activities, such as requirements, design, code, test, risk, measurement, configuration management, quality, and process improvement. 

Furthermore, representatives of other teams working on related or interfaced systems, or at the enterprise or customer levels, also play a part.

To review, see Introduction to Software Systems.

2e. Explain the major methodologies and processes in software engineering, such as Agile, Lean, Spiral, and Unified

• How do we summarize the major methodologies and software development processes?

Spiral is an evolutionary model framework that produces short life-cycle incremental releases (concept, new, enhancement, maintenance) by iterating a linear sequential model (planning, risk, engineering, construction, evaluation).

Unified is an iterative methodology based on UML with four phases, each producing an executable software release at that development phase. 

Agile is an iterative model where each incremental release produces evolving requirements and solutions by self-organizing cross-functional teams.

Lean is an Agile methodology that maximizes software development efficiency by minimizing waste, reducing costs, streaming processes, delivering maximum value to end-users quickly, and maximizing effectiveness by increasing learning and authorizing the development to make decisions.

To review, see Software Development Life-Cycle Methodologies.

Unit 2 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• Agile
• composition
• decomposition
• Lean
• method
• methodology
• phases
• prototype
• software life-cycle (SLC)
• Spiral
• Unified
• waterfall

Unit 3: Software Modeling

3a. Explain object-oriented concepts such as abstraction, encapsulation, and inheritance

• How are object-oriented concepts applied in the SDLC?
• What are the commonly used UML artifacts?
• Why is UML useful?

Software engineering is building models to develop software that solves useful problems. Software engineers build models for each phase of the SDLC. In 1945, George Polya wrote a general theory of problem-solving, "How to Solve It", which is well-known in mathematics but less known in software engineering. It presents a general model for solving problems in any application, not just mathematics, and illustrates important concepts of abstraction, encapsulation, and inheritance. It serves as an example of abstraction for software engineering. When we add domain-specific information, it serves as a requirements model. Adding successive detailed information to an SDLC phase model provides a model for the next sequential phase. Thus, each phase model is an abstraction of the following phase model(s) and encapsulates or hides information about the following phase(s). On the other hand, each phase model inherits essential information from the preceding phase. 

Imagine writing a report that describes a house and comparing that report to a picture or blueprint of the house. Unified Modeling Language (UML) is a "blueprint" model that describes software artifacts at an appropriate level of abstraction. A picture and diagram convey a description of a house more efficiently and effectively than a written report. In contrast, a report has the advantage of communicating more information and more details. However, if we are only interested in a house's architectural style and specific properties, a picture and a relevant diagram represent what we need; they are at an appropriate level of abstraction and hide the details of the less abstract written report.

Unified Modeling Language (UML) is a widely used set of diagrams for documenting and communicating requirements, architecture, and object-oriented software design. UML has several diagram types that describe structure and behavior. These UML diagrams are used to depict structure and behavior.

UML is useful because selected UML diagrams can represent the information we need to develop and communicate for the software life-cycle. It includes information for the development and maintenance phases. Further, we represent object-oriented concepts by corresponding UML diagrams:

• Class structure – class diagrams
• Objects – object diagrams
• Methods – activity diagrams
• Sequence diagrams
• Interaction diagrams
• State diagrams
• Interface – interaction diagrams

To review, see:

• Object-Oriented Programming
• Object-Oriented Terms
• What Is UML?
• Introduction of UML in Software Engineering
• Fundamentals of UML Diagrams

3b. Interpret the context appropriate for main UML diagrams, including but not limited to structure diagrams, class diagrams, and component diagrams

• How can an object-oriented methodology use UML?
• What are the essential object-oriented modeling concepts?

UML is a generally relatively rich language for modeling software solutions to real-world problems, and it applies not just to object-oriented methodologies but to other software development methodologies. Object-oriented methodologies use objects, classes, and methods to build problem domains, designs, and software models. You use UML diagrams to describe these models and see which parts of UML are "essential" for modeling object-oriented development and object-oriented systems. 

The UML diagrams discussed reflect the four principles of Object-orientations (information hiding or encapsulation, abstraction, polymorphism, and inheritance): use case diagram, state diagram, class diagram, activity diagram, and interaction diagram. 

To review, see:

• Fundamentals of UML
• Use Cases
• UML State Diagrams
• UML Class Diagrams
• UML Activity Diagrams

3c. Apply different levels of abstraction at essential object-oriented modeling concepts to enable reusability and flexibility

• What levels of abstraction in object-oriented modeling enable reusability and flexibility?

Object-oriented modeling uses classes, objects, and class relationships (hierarchy, composition) and supports encapsulation, information hiding, polymorphism, and interfaces. All of these promote reuse and flexibility. 

To review, see Object-Oriented Programming and UML as a Modeling Tool.

Unit 3 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• object-oriented modeling
• UML diagrams
• Unified Modeling Language (UML)

Unit 4: Software Requirements Gathering

4a. Identify different types of software requirements and data types

• Why are we interested in data?
• What are some of the properties of data that are relevant to a software development project?
• What are some different types of software requirements?
• How do we decide whether or not to perform a project, phase, activity, or task "in-house" or to outsource?
• How do we decide to whom a project, phase, activity, or task is assigned or awarded to a vendor?

Data types are gathered and analyzed in each development phase to build models. Software engineers collect data about the problem or task at hand. From this data, they specify the information that is needed to solve the problem or perform the task. In addition, they identify the relevant relationships that apply to this information. The resulting data description is a Problem Domain Model, the first SDLC model. This results in the software model requirements specification and builds models for the following SDLC phases. Each model will evolve due to changes, corrections, and improvements as development progresses. 

In the requirements phase, additional information on what is needed is elicited from stakeholders and used with the Problem Domain Model to describe a Requirements Model. In the Design Phase, additional information on processing the data is gathered and used with the Requirements Model and Problem Domain Model to describe a Design Model. The transition from the problem ('what" the problem or task is) to a solution ('how" to solve the problem or the task performed) occurs in the Design Phase. In the Implementation Phase, additional information on the details of the data and how it is processed is gathered and used with the previous models to create the software that solves the problem or performs the needed task. Thus, a data trail guides us in transforming the initial problem domain into a solution model. 

Several properties of data help build the project data models, including the period of the data, its structure, completeness, ambiguity, semantics, volume, privacy, and security. These properties are important considerations in building each of the phase data models. 

We classify software requirements according to various types. Generally, a requirement may be a technical or management requirement. A technical requirement pertains to the development products and the artifacts delivered to the customer or client, including requirements, design, implementation, test, and final system. A management requirement pertains to management control and monitoring of schedule, cost, functionality, quality, and configuration. Name the other types of requirements. 

You probably have been assuming that a software engineering team will develop a software system for a customer or client. While that is the normal role of the team, there are occasions where the team is the customer, and the desired system is outsourced. At the project, phase, activity, or task level, a feasibility study may result in a recommendation to outsource a part or even the entire project. Reasons for outsourcing include lower cost, lack of time or resources, lack of expertise or experience, a company strategic decision, or contract negotiations with a customer. We send a Request for Proposals (RFP) to identify a vendor or subcontractor. Data on the vendor is requested in the RFP and submitted with the vendor proposal. Instead of gathering data, the project is now a data provider to vendor or subcontractor companies. The data types and collection techniques presented in this unit now apply to the vendor or subcontractor. The project now has a different, passive role. 

The assignment of software activities and tasks is consistent with the principles of efficiency and effectiveness. Increasing specialization and availability of open-source subsystems and application libraries means that software purchasing and subcontracting occur more frequently. Once proposals from vendors or subcontractors are received, the project again gathers data, some of which will come from external sources, including the vendor. All of the considerations you have been studying apply application types, data properties, data gathering techniques, professionalism, and ethics. Data accuracy on qualifications, potential misuse of confidential or proprietary information, and potential conflicts of interest are of concern when dealing with vendors and subcontractors. 

To review, see:

• Data Gathering for Application Development
• Writing Software Requirements
• Object-Oriented Analysis

4b. Describe data/requirements gathering techniques used by software engineers

• How do we gather data?
• How do we verify and validate the data?
• What tools are available to support data gathering?

We gather data in each phase of the life-cycle. It is a primary activity in the requirements phase, called requirements gathering in that phase. We gather data from project and company documents, software artifacts, stakeholders, and external sources. 

Depending on the source, data gathered may be ambiguous and subject to interpretation, bias, incomplete, and incorrect. Verification pertains to correctness, while validation pertains to agreement or approval by significant stakeholders. We can corroborate data using multiple internal and external sources, different collection techniques (such as interviews, reviews, documents, and approvals), and different dates or times. Getting multiple sources for the same information is called triangulation.

Generic tools like document or spreadsheet software can support meetings, interviews, and reviews. Management software, in particular configuration management software, may be applicable. We can use software and system requirements engineering tools. Additionally, assessment software tools and documents (model-based assessment for software process improvement, such as CMMI (Capability Maturity Model for Process Improvement) are applicable since they use the same techniques we have discussed. Such is the nature of real problem-domain modeling. 

In later phases in the SDLC, when the transition occurs from the Problem domain to the Solution domain, techniques become more systematic, and special tools become available. As new data analysis, unstructured data, Big Data, and AI tools mature, support will "move" up the abstraction hierarchy – from implementation to design to requirements to problem domain. For example, MAXQDA is an older tool (1989), improved and updated to an AI-assist tool that supports management, transcription, coding, and analysis of interviews, meetings, questionnaire data, and visualization of the results.

To review, see Data Collection Techniques and Data Gathering Techniques for Each Application Type.

4c. Outline data gathering techniques, such as interviews, meetings, or observation, that are most useful for various application types, including transaction processing systems (TPS), decision support systems (DSS), and executive information systems (EIS)

• What are the strengths and weaknesses of data-gathering techniques?
• Which techniques are more efficient or effective for a phase activity?
• Why are professionalism and ethics important for data gathering?

Data characterizes properties (or "dimensions"), and we can use various data-gathering techniques to collect that data. We can use any technique, but we would like to use the most effective and efficient techniques for our application for a given data type. To identify the "best" techniques, we must understand the properties of the data, the strengths and weaknesses of each technique, and the type of data associated with our application. If we understand an application, we will know some of the properties of the data. As we gather data, we will learn more about the data. If we understand the strengths/weaknesses of the techniques, we can select the technique that will be best for our application's data. 

Data gathering and data collection techniques can put a software engineer in situations that put the rights of confidentiality, privacy, and ownership of stakeholders and organizations at risk. Suppose you were a participant in a group interview, and one of the other interviewees revealed what you said to project team members who were not in the interview. No matter what you said in the interview, its revelation could inhibit open discussion in future interviews, resulting in incomplete data. Moreover, what you said in the interview could create a negative impression of you or others in the project. 

To review, see Data Collection Techniques and Data Gathering Techniques for Each Application Type.

Unit 4 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• data types
• Request for Proposals (RFP)
• requirements gathering
• requirements phase
• triangulation
• validation
• verification

Unit 5: Software Requirements Analysis

5a. Interpret fundamental software requirements and analysis terms, such as actors, constraints, and use cases

• What are the key terms for the requirements analysis phase of software development?
• What are the types of software requirements?
• How is the quality of software requirements described?
• What roles work with or use software requirements?
• What are some other attributes of the requirements?

Software requirements analysis aims to specify the problem to be solved or a task to be performed by the software. Second, remember that software may be a subsystem of a larger system, and therefore, the software requirements are subproblems or subtasks of the larger system. Third, software requirements analysis identifies what the software system will do, not how it will do it. OO analysis describes requirements with use case diagrams supplemented with textual information. A use case represents a functional requirement, the actor or role that uses the system by interacting with it via an exchange of information, and constraints that limit the system's behavior. 

We elicit requirements using the data-gathering techniques. Requirements can be functional or non-functional. A functional requirement specifies what the software shall and shall not do. Performance, interface, design, and development standards are non-functional requirements. We write requirements as simple, concise, unambiguous shall statements in a requirements model using diagrams such as use cases and text that express the types and properties of data. The requirements model is the starting model for software development, transformed into models of other life-cycle phases. 

The requirements statements or model is analyzed to determine the attributes of the requirements. We use attributes to determine the quality of the requirements, such as whether the requirements are complete, consistent, traceable, and so on. Complete means that the requirements address all of the needs of the customer or client; consistent means that there are no contradictions between requirements, with the requirements of the larger system of which the software is a part, and with the products of the design and implementation phases, and with management elements. Traceable means that the connection between the requirements, system requirements, design, implementation, and management elements has documentation. We need traceability to software and system tests for validation. 

A requirements engineering role is responsible for the requirements. Requirements have many stakeholders, including customers, software designers, and testers. Name some other stakeholders. We use requirements to validate the software system, design, and implementation. How are the requirements themselves validated? Testers test the software to determine if it satisfies the requirements. Project managers use the requirements model to organize, plan, and manage the project. A requirements change management role is responsible for identifying, approving, and controlling changes to requirements. 

To review, see Review of Fundamentals of Requirement Analysis.

5b. Apply the main activities of software requirements analysis, such as gathering, specification, and verification

• How are requirements obtained?
• What are the main activities of the Requirements Phase?

Data collection techniques have strengths and weaknesses depending on the properties of the data to be collected, and the data properties depend on the type of application. Selecting several data collection techniques with complementary strengths helps maximize the effectiveness and efficiency of data collection.

What is unique about the data for requirements that make it different from other phases? First, since the requirements phase is typically the initial phase, it is the start of data collection. Other phases will have a body of data already collected (such as from other projects or systems) and will add to it. Second, requirements elicitation will likely have the most significant percentage of customer and user interaction and involvement. Third, requirements analysis addresses the definition of the problem or task and what computations the software will do. The other phases address the solution to the problem and how the software will perform the computation. 

The Requirements Phase of a life-cycle development model corresponds to the problem-definition problem-solving stage. A critical step in solving a problem is to thoroughly understand the problem by collecting relevant data, analyzing the data, concisely specifying the problem, and validating the problem specification. For software engineering and the requirements phase of a life-cycle development, these steps are 1) elicit requirements, 2) analyze the requirements, 3) specify them, and 4) verify and validate them. A process describes each step and uses an object-oriented analysis method for execution.

To review, see The Requirements Process.

5c. Describe the conceptual foundation underlying data-oriented, process-oriented, and object-oriented methodologies

• What methods and methodologies guide the requirements phase activities and produce software requirements?
• How do requirements methods help produce the requirements specification?

Process-oriented methods view a system as a hierarchy of processes related by decomposition. A system performs a process, has inputs, and produces outputs. We can decompose a system into component systems (subsystems), each having inputs and outputs at the next level. The decomposition continues until we reach elementary components that cannot decompose.

Data-oriented methods view a system as a collection of data entities and entity relationships. Application relationships determine the processing of the entities and their domain values. Object-oriented methods view a system as a hierarchy of objects related by inheritance. An object is an encapsulated unit of data and methods (functions). Objects interact by messages (for example, calls to the methods of an object). 

In the requirements phase, these methods guide the definition of an initial process model, data model, or object model, respectively, of the problem domain. Depending on the methodology, this initial model helps specify reasonable requirements for processes, data, or objects. In later phases, the methods guide the transformation of the initial model to a solution model for the respective method. 

To review, see Conceptual Modeling.

5d. Describe the analysis activities and their major representations in data-oriented, process-oriented, and object-oriented methodologies

• What are the significant representations used in analysis activities?
• What are the analysis activities used in requirements analysis?

Object-oriented analysis activities are part of the requirements phase. It identifies those objects, processes, attributes, and classes. It assigns processes (methods) to the objects and defines the attributes (data for objects and properties for processes). We typically represent these elements using tables and text. We represent relationships between objects and object classes, intra-object control, and inter-object event processing flow.

A convenient way to list the activities of the requirements analysis phase is via a diagram. For example, the following diagram is functional to list the activities for the object-oriented requirements phase:

Inputs to the phase are on the left side, and outputs are on the right side. We list control elements above the box, including policies, processes, procedures, plans, and constraints. We list resources, support, and tools below the box. We write activities in a box as verbs. This diagram format is called Integration Definition (IDEF). It is a general diagram used in many disciplines to represent process activities. IDEF diagrams, such as the above, can be decomposed into more detailed sub–diagrams. 

Object-oriented methods encompass data-oriented and process-oriented methods, artifacts, and activities. Data-oriented requirements analysis activities and artifacts are data elements resulting from decomposing "problem space" data. Data-oriented requirements analysis is a subsection of a business area analysis. They also identify the main data-oriented analysis artifacts. Process-oriented requirements analysis activities and artifacts result from decomposing the "problem space" functions. Structured systems analysis is an example of a process-oriented method.

To review, see Conceptual Modeling in Object-Oriented Analysis and UML Sequence Diagrams.

Unit 5 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• data-oriented methods
• functional requirement
• Integration Definition (IDEF)
• non-functional requirements
• object-oriented analysis
• process-oriented methods
• requirements analysis
• requirements change management
• requirements engineering
• use case

Unit 6: Software Design

6a. Explain the software design principles used to create well-designed software that is easy to understand, test, modify, and develop

• What are the software design principles?
• What is the purpose of the software design principles?

Design principles include information hiding, modularization, cohesion, and coupling. These principles apply to the "divide and conquer" problem-solving strategy often used in system design. "Divide and conquer" decomposes a large problem or task into smaller ones that we can solve. We may repeat the decomposition several times until reaching a level of solvable problems or tasks. You can see the decomposition of the problem or task in the Requirements Model produced by Requirements Analysis. We use this model to specify the objects and classes. Software Design continues the decomposition to extend the model to a design model that specifies how the problem or task will be solved or performed. The solution will be in terms of solutions to small subproblems and how the subsolutions are composed to solve or perform the requirements.

Design principles guide the decomposition by describing desirable properties of the modules that result from the decomposition: namely, modules that abstract or hide their internal data (information hiding), have minimal connections (low coupling), and have internal elements that are closely related or highly unified (high cohesion).

Software design activities and the decisions made are challenging because they bring about the transition from the problem domain to the solution domain. Design methods that promote design principles guide software design activities, which include data collection at a detailed level. We use that data to extend the requirements model to a design model. Software design principles guide to make the best decisions in carrying out the design activities.

To review, see Software Design.

6b. Apply the main activities of software design, such as creating class diagrams, sequence diagrams, and activity diagrams

• What are the main activities of object-oriented design?

The main activities of object-oriented design are the creation of the software architecture or high-level design and the detailed design. These consist of the organization of the software or static structure and the dynamic structure or behavior of the software components. Class diagrams, sequence diagrams, and activity diagrams represent these. Recall that the names of these diagrams may vary; for example, activity diagrams may be called collaboration or communication diagrams.

To review, see Software Design and UML and Other Modeling Diagrams for Design.

6c. Interpret architectural design in terms of decisions, system organization, modular decomposition, and flow-and-control

• What are the components of software architecture?

Software architecture has two aspects: static and dynamic. The static structure is the set of components, modules, classes, objects, and association relationships: generalization or composition, depending on the methodology. In general, "component" and "module" are terms independent of methodology. The static structure is a description of the decomposition and organization of the components or modules of the design. Dynamic structure is the subset of the fixed structure that corresponds to the flow of control, timing, and concurrency of the execution of the modules.

We often perform software design at two levels: the software architecture level, or high-level design, and a detailed design level. The description of a software architecture should include the decisions made in defining the architecture to address a problem or requirement, having the required degree of quality.

To review, see:

• UML and Other Modeling Diagrams for Design
• UML Collaboration Diagrams
• UML Class Diagrams

6d. Use design diagrams to determine the way data is represented and processes are executed in process-oriented, data-oriented, and object-oriented methodologies

• What are the activities of the Design Phase?
• How are the work products of the design activities represented?

Trace information is captured and recorded to document the transition from the requirements to the design model. This traceability information, for example, links a requirement to the design element(s) that support and satisfy that requirement. Design activities identify the solution domain objects corresponding to the problem domain objects in the requirements model, including human-computer interaction, physical hardware, software services, and object instances.

Using OO design, work products are the design diagrams (like the one shown below) and associated documents.

To review, see:

• Object-Oriented Design
• Data-Oriented Design
• Process-Oriented Design

Unit 6 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• design model
• design principles

Unit 7: Implementation

7a. Differentiate between types of programming languages, including system languages, domain-specific languages, and scripting languages

• What are the activities of the implementation phase?
• What are the implementation or programming activities?
• How are the work products of the implementation activities represented?
• What principles guide the activities of the Implementation Phase?
• Is programming the only activity for Implementation?
• Why is purchasing an issue for software development, particularly the implementation phase?

The implementation phase activities build the programming or implementation model utilizing the requirements and design models and any additional data collected in the implementation phase. As with other models, we capture and document traceability from the design to the implementation model. This traceability information links a requirement to the software code that implements the corresponding design. This traceability is useful in maintenance since a change to a requirement affects the design elements and software code that the requirement traces to. Implementation activities identify the programming language constructs corresponding to the design model elements. 

Implementation activities identify the language constructs to define implementation objects, object attributes, methods, object instances, and messages to realize (build according to) the design specifications. The static and dynamic structures, including class hierarchy and message dynamics, are coded either by programming the code or obtaining it from a code library. We document the code according to coding standards, compile it, review it, test it, package it for the execution environment, and allocate it to the hardware. Updates to the design artifacts, for example, implementation objects and classes, must be added to the class and object diagrams or tables.

Design principles guide coding, incorporating encapsulation or information hiding, modularization, coupling, and cohesion. We created these principles to enhance the quality of the code, including maintainability, reusability, and testability. Since design "determines" code, we also apply these principles to the design. Moreover, these design and programming principles promote non-technical characteristics, such as non-ambiguity or clarity. Other non-technical characteristics derive from non-functional requirements. 

The course emphasizes the early phases of the development life-cycle, the Requirements and Design Phases. The Implementation Phase includes data gathering, analysis, specification, and verification. Data gathering is a continuous activity that applies throughout development to all Phases. For the Implementation Phase, analysis and specification are the programming processes not directly addressed in the course because they are the subject of programming courses, not software engineering.

Data-oriented coding activities and artifacts focus on data coding, values, structure, and processes that operate on data. We updated the design artifacts with implementation information. UML diagrams, except those that depend on inheritance, that pertain to the three sets of activities are applicable for representing data-oriented artifacts.

Process-oriented design activities and artifacts focus on the processes and, then, the data that is the input or output for processing. Updates to the design artifacts using the implementation information. UML diagrams are applicable for representing data-oriented artifacts that pertain to the three sets of activities, except those that depend on inheritance.

Software can be developed, purchased, or reused. The programming activities of the Implementation Phase produce developed software. An RFP procurement process obtains purchased software. We obtain reusable software from open sources or in-house software libraries.

Purchasing hardware, software, or services is an issue for a development project because a part of the development (a phase, activity, subsystem, or component) may not be performed in-house but instead outsourced or acquired. These decisions are made by project management and called make-buy decisions. If the project decision is to purchase hardware, software, or services and the cost is substantial, we use an RFP procurement process. 

To review, see:

• Object-Oriented Implementations
• Software Construction

7b. Identify the characteristics of and select software programming languages, such as systems programming languages and web programming languages

• How is a programming language characterized?
• Why is it beneficial to characterize programming languages?

Programming language characteristics include technical and non-technical properties. Non-technical properties include project management, requirements, quality, and business. Programming language characteristics are helpful information in making a variety of development and project decisions, including what programming language to use for the application or part(s) of the application. We determine what programming assignments to make to members of the team and what additional software tools we may need to support programming, how compatible a language is with a development methodology, what areas of the software should be emphasized in testing, and what impact may affect the maintenance of the software. 

In selecting a programming language for a development project, programming language characteristics may not differentiate between programming languages because most current languages have features that cover most, if not all, of the properties. The difference between languages is in the degree or extent to which they have a given property. In such situations, non-technical properties or requirements often decide a choice. 

To review, see Software Construction and Choosing Implementation Languages.

7c. Explain the benefit of version control systems

• Why is version control important?

A version control system is a software tool that identifies and controls different file, document, or software component versions. It is a subset of a software configuration management system (CMS). 

Development involves numerous changes to files, documents, and software components. Other changes cause changes; for example, a change to a requirement may cause changes to design, code, and test components. Changes may occur due to errors, improvements, and accommodation of multiple types of hardware (like different processors) or software (like programming languages). Also, implementing changes involves shared team activity, which complicates control of the changes. In effect, identifying and controlling components and their changes for a large software development project is complex, and the risk of loss can be significant if versions are lost. 

To review, see Version Control Systems and Software Configuration Management.

Unit 7 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• implementation phase
• programming language characteristics
• version control system

Unit 8: Software Testing

8a. Describe basic software testing terms, such as test case, traceability matrix, and acceptance criteria

• What is software testing?
• When is software testing performed?
• Where is software testing performed?
• Why is software testing performed?
• How is software testing performed?
• Who performs software testing?
• How would you define the test case, traceability matrix, and acceptance criteria?

What: Software testing is a process of executing software to find errors. It is a type of verification. Other types of verification include reviews and analysis. If the software satisfies its specification, it is said to be verified. If it satisfies the user requirements, it is validated. Errors are either errors of omission or errors of commission. Projects also usually categorize errors by severity and by-product, such as design, documentation, and levels 1 and 2. You will find errors in a trouble reporting or ticket system linked to a version control or configuration management system.

When: Software testing is performed primarily in the testing phases of development, after the implementation phase. However, we perform testing with scaffolding software in other phases, such as the design phase. Each test level is verified against the specification for that level (and by implication of all prior levels). Scaffolding software is test software (not part of the application) that provides an environment enabling partial code execution. Testing stops when all test cases and procedures are complete. 

Where: Software testing can be performed in a development, test, or operational environment. 

Why: Software testing is performed to find errors and verify and validate the software against the functional and non-functional requirements. We acquire error data to measure quality factors, predict future errors, and make management and technical/software decisions. 

How: Software testing is performed using test cases, test procedures, test data, operational data, test software, and test tools. Furthermore, we conduct testing management according to a test plan, process, and procedures using test management software. 

Who: Testing is performed by the developers, by project testers, by internal company testers, by external testers, by customer testers, and by software tools. 

A test case is a data record or transaction to test whether a component or the system satisfies its software requirements. A traceability matrix is an actual table or a graph that links artifacts or elements of the artifacts of each SDLC phase to related ones in the other phases. A test traceability matrix does the same for the elements of the Test Phase; for example, it links a test case to software code and to errors it discovers. Test acceptance criteria are the exit conditions for stopping testing. 

To review, see Test Terminology.

8b. Compare the use of various testing strategies, including black-box, white-box, top-down, and bottom-up

• What are the major software testing strategies?

Four major testing strategies are black-box, white-box, top-down, and bottom-up. A module has three parts: input, process, and output. A strategy for testing software includes a way of selecting the test data. 

If the basis of the specified test data is on the design specifications rather than the logic of the software, we refer to the test strategy as black-box testing. In black-box testing, we execute a module with the test or input data and compare the output to the required or expected output. If they match, the test is considered successful; otherwise, it fails. We call it "black-box testing" because we do not utilize the processing part of the module in selecting the test data; we treat it as hidden.

We call the test strategy white-box testing if we use information on the module's processing to choose the input data. For example, suppose a module has two execution paths controlled by a binary condition. We would select test data to exercise each path in white-box testing. In general, a module could have many execution paths, and analysis would determine the test data to target which pathways to execute.

The software design consists of a collection of modules organized as two structures, static and dynamic, in the form of a module hierarchy. For the static structure, the relationships reflect the parts of a module. For the dynamic structure, the relationships reflect the execution paths of the collection. In bottom-up testing, testing begins when the coding of a module at the bottom of the hierarchy executes to completion. We test the parent module when all parts of a module have been coded and tested. Thus, the order of testing proceeds from the bottom of the hierarchy to the top.

In top-down testing, the testing order proceeds from the top of the hierarchy along execution paths. We use test code, known as "scaffolding", to execute a module when only a part of that module is in development. This test code is in addition to the module code and will be replaced by the module code when it becomes available. 

To review, read Test Strategies.

8c. Identify different types of tests, including functional,non-functional, performance, and user tests

• What are the types of tests?
• What is the purpose of testing?

Each of these is either a functional or non-functional type of test. The type of test depends on the following:

1. the requirements and purpose of the test
2. the phase and phase artifacts tested
3. the customer/client/user
4. the type of requirement

A test may fall into several types; for example, if the purpose of a test is verification of a requirement on performance, then it is also a performance or stress test.

There are several reasons for testing: to verify a phase deliverable, to validate the software system, to improve quality, to determine an attribute (such as complexity), to re-test (called regression testing), to gather data (such as to determine the complexity, to support a decision, or to make a prediction)

Each deliverable phase artifact has a corresponding test: requirements test (validation), design test (verification), code test (verification), integration (verification and validation)

When we perform a test by an external group, it is called an acceptance test. The external group could be the customer, client, user, or independent quality/assessment team.

Requirements include product and process requirements, functional, non-functional, and quality.

To review, see Test Terminology and Software Test.

8d. Design a test plan that includes unit, integration, and system levels of test coverage

• What should we include in a software test plan?
• What are the activities of a software test phase?
• In addition to verification and validation, are there other benefits from the test activities?
• What are several types of tools available to support software testing?
• How are tests verified and validated?
• Do data-oriented, process-oriented, and object-oriented methodologies differ, or are they the same concerning testing?

Testing is a critical, costly, and challenging activity that verifies and validates the code, software design, and software requirements. The requirements, design, and implementation phases have corresponding levels of test activities: system, integration, and unit, respectively. We perform each group of tests according to a test plan. A test plan addresses why testing is done (test goals); who does the testing, what we test and coverage; when testing starts, stops, and is redone (regression); where testing occurs; and how it is done. System and quality assurance testing are similar and share test strategies, cases, and scripts. However, quality assurance testing is a pure validation test. Various software tools are available to support the test activities, and those we select are in the test plan. 

Test activities include:

1. test planning
2. test case development
3. test environment development
4. test execution
5. test logging
6. test result evaluation
7. defect recording and tracking

Test activities are described in the test process (what) and test procedures (how to perform processes). 

The test work products are:

1. test plan
2. test cases
3. test environment
4. test results
5. test log
6. test results
7. test defect resolutions

We can see that testing produces benefits in addition to improving the quality of the software. Testing has information and measures about the application system to help make management and technical decisions during further development and maintenance. For example, traceability information identifies the impact of errors on other parts of the system. It helps determine the scope of related changes, the effort needed for regression testing, and the system's complexity. Moreover, we can use defect measures from tests and technical reviews to determine the probability of remaining errors and to target test resources to the parts of the software with the most significant risk. 

Test tools include test management systems, test scaffolding, test case tracing, and defect management systems. As with all technology, test tools change and evolve due to business, economic, or new technological reasons; old tools are replaced or evolve into new ones. However, types and functions remain the same (or extended). 

Logically, data-oriented, process-oriented, and object-oriented methodologies activities are the same. The artifacts and diagrams used by the respective activities differ, particularly in the emphasis on data, process, or objects. Testing is a recursive activity in that tests need to be verified, validated, and themselves tested. The test code used for the first time should be tested, particularly for critical software, in the same way as the system code. The test software's historical performance, test case coverage reviews, and analysis of test results or errors, either found or not found, are also used to verify and validate the test software.

To review, see Test Plan for ABC Video Order Processing and Software Test.

Unit 8 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• acceptance test
• black-box testing
• bottom-up testing
• regression testing
• software testing
• stress test
• test acceptance criteria
• test case
• top-down testing
• traceability matrix
• white-box testing

Unit 9: Project Management

9a. Compare the role of the project manager to that of the software engineer

• What are the SE and PM roles?
• What is the relationship between a software project manager and a software engineer?
• What is unique about managing a software project compared to managing in general?

Two of the roles of a software project team are software engineering (SE) and project management (PM). SE is a technical role, and PM is a management role. The software engineering (SE) role is solely responsible for the technical activities of the life-cycle. The SE and PM have joint responsibility for project planning and allocation of resources, including the assignment of tasks and major application decisions. The project management (PM) role is solely responsible for interfacing with non-project team stakeholders, managing project staff, and monitoring and control. The SE and PM roles are team-oriented: each has sole and shared or joint responsibilities to provide mutual support.

Software project management differs from managing in general. It focuses on:

• software development, software technologies, and software applications
• software requirements engineering and requirements management
• software estimation of cost and schedule
• identification and mitigation of project risks
• requirements, design, and implementation models and management of the transition from the problem space to the solution space
• using data to make decisions that impact the success of a software project

A software project manager manages the software engineering team; plans, tracks, monitors, and controls technical activities and work products of the SDLC phases. A software engineer performs the technical activities and develops the technical work products. A software engineer may perform some technical management functions on a small project. 

Furthermore, a software PM role should ideally be able to define a standard structure for allocation and management of cost, schedule, functionality, and organization of project processes and work products and for managing joint SE-PM responsibilities. Typically, this common structure is a software architecture. For example, the software system architecture can serve as the work breakdown structure. Allocation of cost and time to each structure element produces a project cost and schedule estimate. As design details evolve during the development, detailed work assignments can be identified, cost, and scheduled. The technical nature of this typical structure determines the joint SE-PM areas of responsibility. 

To review, see Project Management and Software Engineering Management.

9b. Describe the areas of responsibilities of a project manager

• What are the responsibilities of the PM in the project management process?

The PM is solely responsible for liaison between the project and external stakeholders, project personnel management, and project monitoring and control. External liaison involves communication, negotiation, and status reporting. What do you include in a status report to a stakeholder? 

The PM performs project personnel management with the support of Human Resources. Project monitoring and control is tracking the project progress against the project plan and taking corrective action when the project progress deviates from the plan. The ability to project from current to future status is a valuable PM skill that identifies problems early when they are usually easier to address. 

The PM process consists of activities that carry out the above three responsibilities. These activities utilize techniques or methods to produce work products, including project organization, work breakdown structures, cost and schedule estimates, task dependency diagrams, critical path, software development and related plans, status, review, and monitoring reports. 

To review, see Project Management.

9c. Apply the concepts of project management, such as planning, scheduling, and execution, in terms of the project, people, change management, and quality control

• What are the activities and artifacts of software project management?
• What topics are included in a Software Development Plan?
• What are the techniques used in the software project and change management activities?

Project performance depends on software project management planning and efficient and effective execution of the project plan. Software PM aims to develop a software system that satisfies the expectations and requirements of the stakeholders. The PM develops a software development plan jointly with SE to achieve this goal. The software development plan (SDP) describes the project's goals, strategy and approach, project activities, project deliverables, PM techniques, cost and time estimates, and progress and quality measures to achieve the goals. Other topics included in an SDP are:

• team roles and shared tasks
• project-specific training.
• project communication mechanisms, such as email, notifications, meetings, reviews and audits, and status reports
• personnel management, monitoring and control, and measurement

A critical component of project monitoring and control is change management, a procedure for change control that requires the user to submit a formal request for a change to the PM. Changes can be classified in several ways:

1. by type, such as eliminating defects, improving performance, or changing functionality
2. as required or optional
3. by priority as emergency, such as mandatory with a required end date, mandatory with an open end date, or low priority

Techniques learned from experience include:

• management heuristics
• cost and schedule monitoring tools
• systematic decision-making approaches
• data analytic and predictive methods

The SDP is the primary monitoring and control document for managing the project. 

To review, see Project Management and Change Management.

Unit 9 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• change management
• project management (PM)
• software development plan (SDP)
• software engineering (SE)

Unit 10: Design Modification and Quality Control

10a. Apply the principles of software modeling to create diagrams using UML

• How does software modeling provide consistent and systematic concepts for guiding software system development?
• How does UML provide standard, consistent diagrams for representing requirements, designs, and software in a systematic, unified manner?

Software engineering builds and maintains software systems to solve problems and perform useful tasks. As problems and tasks became larger, more complex, more diverse, and more critical, software engineering methodologies evolved to systematically guide the predictable development and maintenance of software systems to address them. Early methodologies used for software development emphasized data- or process-orientedness. Later approaches integrated the two perspectives via object orientation. With experience, the concepts and techniques of these methodologies were refined and adapted to better match application characteristics and types that more effectively guided the development and maintenance of software systems, and models evolved, enabled by formal representations to apply, support, and automate the methodologies. 

Modeling begins with the requirements model that defines initial structures. The design model elaborates those initial structures with "essential" or service elements corresponding to programming language constructs. UML was developed to provide industry-standard diagrams for describing object-oriented models for requirements, design, and code in a consistent manner. UML is an example of a language paradigm. The word "paradigm" is a time-dependent view of a body of knowledge. It is a collection of concepts and principles that guide us in thinking about a subject during a given period. One important paradigm for software engineering is that of "language". We specify processes and procedures in various languages, depending on the representation of "who" will perform the activity - man, software, or machine. 

At this time, in the context of the SDLC, for example, requirements are primarily represented using a natural language and UML. Natural language often contains ambiguities; UML brings clarity and consistency to the representation. Informal or formal diagrams represent design; formal programming languages primarily represent implementation; interface or scripting formal languages represent integration and testing. This is important because the representation of objects and associated activities by a language enables us to communicate, study, and understand them and, perhaps, if the language is formal and systematic enough, build tools that support or automate them. The course case studies provide opportunities to demonstrate the use of UML diagrams for software modeling for development.

To review, see Software Engineering Case Study.

10b. Create OO analysis artifacts using the object-oriented methodology to create software analysis and design artifacts

• How is software requirements analysis used in modeling?
• How do models help us understand and communicate what the problem or task is (that is, the requirements)?
• How is object-oriented software design used in modeling?
• How do models help create and communicate how the problem or task will be solved or performed (the design)?

The software specifies how to solve a problem or perform a task. Executing the software on the hardware solves the problem or performs the task. However, the problem or task must first be specified and analyzed to obtain correct, complete, consistent, clear, verifiable, modifiable, and traceable representations. Object-oriented modeling supports these characteristics and applies to many real-world problems and tasks that confront us daily. 

Object-oriented requirements analysis specifies the requirements as use cases and scenarios. OO design refines them using structure and behavior diagrams to determine details to define problem space objects and classes. Software design continues the analysis by refining and adding details to build a design model of solution space objects, classes, messages, and interactions. UML diagrams (class, sequence, activity, and state chart) serve as the OO design artifacts of the OO design model.

The transformation from the OO requirements model to the OO design model involves many decisions. OO methodologies, catalogs of OO design patterns, and OO code libraries aid it. The design model consists of elements corresponding to an object-oriented language's constructs. Thus, the transformation from the design model to the implementation model of object-oriented code is straightforward. The system can generate much of the code if the design model has sufficient detail.

To review, see Software Engineering Case Study and Teaching Software Development.

10c. Create a comprehensive test plan that includes the main levels of software testing, such as acceptance testing, unit testing, integration testing, and system testing

• How is software testing used in modeling?
• How do models help us implement a software system and demonstrate that it satisfies the requirements?
• Does testing depend on the methodology used to develop the software?

Software is analyzed on three levels to produce three corresponding models: requirements, design, and code (or implementation). Similarly, software is synthesized and tested on three levels: unit, subsystem/system integration, and system. A test model is a data model consisting of test cases and procedures. A test case consists of input and output data, relationships between input data and the expected intermediate and final results, and relationships between input data and the decisions or conditions determining the execution of various paths. Test procedures consist of the supporting human operations and test software needed to deliver test case data to the part of the system under testing. 

Software testing is the verification of software by executing it. Created input is used to produce results demonstrating whether the specifications and the requirements are satisfied. Testing is either a black box test or a white box test. In the case of black box testing, tests depend on inputs and compare the final result to the expected result. In white box testing, tests depend on how the logic of the code selects inputs to execute variations of processing and compares all intermediate and final results to the expected results. 

This table relates the test level to the model tested and the model used to determine the tests.

These kinds of testing are mainly independent of methodology. However, the amount of test scaffolding needed and test coverage may vary by programming language.


To review, see Software Engineering Case Study and Design Modification and Quality Control Activity.

Unit 10 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• language paradigm
• test model