CS302: Software Engineering

Watch this video of the first day of a software engineering course. The instructor spends the first half of the video exploring a haphazard way to develop a system for putting the class syllabi online. He then discusses some aspects of the systematic process to complete a course similar to this one, especially the Software Development Life Cycle (SDLC) projects in Unit 10. Two of these aspects are models and teams. Models are structures composed of objects representing a software system's development. The video mentions one model called the DOM (Document Object Model). The second aspect describes the performance of systematic processes by a project team, each member responsible for a defined technical or management role. In the video, the class is divided into teams of four students. The video also mentions several software tools for software development. The tools support or implement some of the activities of the SDLC. Stay calm, as this is not a programming course. You may find the 30-day free versions of software modeling useful if you have time to use them in Unit 3.

As you read this article, pay attention to the trends section, which covers the period from 2000 to about 2020. As you proceed through this course, these items will appear as controversies and opportunities to evaluate other alternatives. Software engineering focuses on software development, utilizing processes and procedures enacted by teams or executed by machines, tools, and methods. As you read about trends, ask how they relate to and impact software engineering problems, development processes and procedures, team/role development activities, and application tools and methods. Software engineering processes and procedures include the SDLC, other models, and numerous activities.

This article separates computer science into six other categories, with software engineering being one of them. How is software engineering like computer science? How is software engineering different?

Each category is further described by a spider web diagram, showing the topics covered and the degree of emphasis on each topic. A comparison of computer science and software engineering shows the overlap and differences in topics and emphasis. It positions software engineering as a category of computer science. This categorization contrasts the STEM categorization of four main disciplines: science, technology, engineering, and math. Science discovers general principles and problem-solving techniques. Engineering uses those principles and techniques to develop solutions to problems. Technology uses practices and tools to deploy, operate, and maintain those solutions in practical applications. Both perspectives are helpful. At a higher level of abstraction, the STEM perspective shows that computer science and software engineering have fundamentally different processes. At a more detailed level of abstraction, the six degrees perspective shows the intersection and difference of topic coverages between computer science and software engineering and the other four disciplines.

As you read this article, consider the various types and classes of software. What are some of the crises and myths of software development? How did those indicate the need for software engineering?

In general, software quality is crucial in software engineering. Read this article and explore the various definitions of quality and the types of quality models. Notice the priority of quality factors and how software quality can be measured.

Software engineering activities involve many decisions that impact stakeholders: customers, clients, users, project team members, other projects, the employer company, related companies, the public, the responsible software engineer(s) and project managers, organizations, and the Software Engineering profession. When a project has multiple goals and objectives, tradeoffs are often inevitable. For example, every project has cost, schedule, functionality, and quality goals. An increase in one can negatively impact others: increasing quality(positive impact on users) but can increase cost and schedule for the developer (negative impact).

If a software engineering decision involves a decision that has a significant positive impact on a stakeholder but a significant negative impact on another stakeholder, such as injury or harm to others, the decision is called an ethical dilemma. The ACM (Association of Computing Machinery) and the IEEE Computer Society have promulgated professional codes of ethics. Read this summary article that lists eight guiding principles. Today, with the evolution of computing and networking technology, the impact of software and computer engineering decisions can be global. The risk of loss of privacy, security breaches, false information, fake news, harm on social media, and social platform support of one side over others in controversial issues of society occur frequently. As technology evolves, relevant laws, controls, and adherence to ethical codes must also evolve. After reading this summary, think of ethical dilemmas that could result from ubiquitous AI applications and societal use of virtual reality.

Computing, in general, and software engineering, in particular, has the risk of causing harm to others and society. The ACM Code of Ethics and Professional Conduct highlights the important responsibilities this risk places on software developers, project managers, other project team members, users, stakeholders, instructors, and students. Starting with a policy that "the public good is always the primary consideration", it presents supporting principles and guidance for understanding and applying them.

Reflect on the ethical principles, professional responsibilities, and professional leadership principles. Which principles apply to you as students in this course and to the authors of this course? What software engineering student responsibilities can you infer from the Professional Responsibilities? What can you do in this course that will prepare and enable you to apply Professional Leadership Principles in the future? In your opinion, will compliance with the code ever be enforced? If so, when?

The software development life-cycle (SDLC) consists of several phases. Read this section to explore the software life-cycle and these main phases.

Approaches to software development usually follow one of a few basic models. Read this section about different software development approaches and try to figure out the main advantages and disadvantages of each approach (discussed in the next section).

Read this summary of software development models and try to address the main features of each model. Note that this development approach might be categorized in a different way in other resources.

As you read this section, consider professionals' various roles in software development processes. Each role is associated with activities, functions, and teams.

Software development methodology is used to structure, plan, and control the process of developing an information system. What are different approaches, and what are the basic principles of each approach?

This video contains a lot of information, so take good notes. Pay particular attention to scrum, as it is one of the most widely used agile methodologies.

This is a complete overview of object-oriented programming with references to several object languages. As you watch the video, list each component of an object-oriented language and a brief descriptive statement. As you complete the sections on UML, note how each component is diagrammed.

This section covers basic object-oriented terms, including classes and objects, abstract data types (ADT) and encapsulation, whole or part and generalization or specification classes, inheritance and polymorphism, and messages.

UML is a modeling language used in requirements analysis, design, and programming. It is managed by the Object Management Group (OMG), which publishes updates to the UML as needed. Later versions of UML remove outdated diagrams, add new diagrams, update the syntax of diagrams, fix bugs, or increase the formality of the UML language to support the conversion of UML to a programming language, for example, Java. The semantics of the diagram types for products and behavior (also called "process and procedure", "static and dynamic", or "what and how") that correspond to OO object data and methods do not change.

A use case diagram documents a scenario or the flow of events and operations performed by a system or person. A component diagram documents the system hardware and software components. Study the examples in this section.

While the static diagrams (use case and component diagrams) pertain to a system, the dynamic diagrams (state, sequence, activity, and communication) pertain to key components or a single component for a state diagram. Study the examples in this section.

Unified Modeling Language (UML) is a graphical modeling language that provides the syntax for describing the major artifacts of software systems. UML supports all the phases of SDLC. It is used to build models that address all the software engineering activities and can be mapped to other process or data models used for the SDLC phases.

UML is managed as a de facto industry standard by the Object Management Group (OMG). This article reviews UML's history, definition, and main diagrams. Knowing something about the history of a software engineering topic helps us better understand the topic and its relevance for current and future use.

The lecture provides information to introduce UML as a tool for software engineers. This video includes a slide that depicts the two fundamental types of diagrams: structure and behavior. After watching the video, write a summary that addresses what UML is.

The lecture provides a discussion of the use case diagram in UML. Can you describe each component of a use case diagram? Is a use case a structure or behavior type of model representation in UML?

A diagram is the graphical presentation of a set of elements. UML has a lot of different diagrams. Make sure you can differentiate between different diagrams. Previous sections described UML diagrams; this section elaborates on them using examples.

This video gives an overview of state machines and the state diagram in UML. What is the purpose of the state diagram?

This video discusses class diagrams in UML. What is the purpose of the class diagram?

Watch this example of modeling. What is the purpose of an activity diagram? How would you create an activity diagram?

The lecture discusses using UML for object-oriented design and programming.

Modeling is designing software applications before coding or implementing them in a particular programming language. A model is a representation or simplification of reality. Read about the main principles of modeling in this section. UML is used to model the products and activities of each SDLC phase.

There are many different data dimensions, such as time and volume. Each dimension is important in defining the requirements of applications. Read this section, which discusses these data types. Bear in mind how much and what type of information should be collected.

This article discusses the 2011 revisions to the IEEE 830 standard for requirements analysis. What are the phases of software requirement engineering?

Pay attention to the section on types of software requirements and the unique quality of each type. It is important to identify and include more than just the functional requirements to have a quality system.

This analysis emphasizes investigating and understanding the problem domain and requirements rather than a solution. Read the slides, which illustrate the use of UML in requirements analysis. Read this section to learn more about some of the terms and concepts related to requirements and their types. These terms can initially seem ambiguous, but we will quickly learn how they relate. A walkthrough of a requirements analysis product is provided, illustrating parts of the analysis using POST, a point-of-sale system.

Data gathering is the interaction between the software engineer (a business analyst) and the customers (including users). There are many techniques for gathering data, including interviews, meetings, observations, questionnaires, and reviewing software, internal documents, and external documents. Data gathering is an activity where ethical and professional conduct issues typically arise, particularly regarding privacy, security, responsibility, accountability, and communication.

Read this section and identify the data types needed by each application type. These are summarized in a table that relates application type to the type of data it needs. Using this table (application type/data type needed) and the previous table (data gathering technique – data type obtained), requirements stakeholders can select the most appropriate data gathering techniques. This is illustrated in the combined table that relates data gathering technique to application type.

Systematic requirements analysis is also known as requirements engineering. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. This chapter explains the term requirements analysis and the types and properties of requirements.

This page re-introduces the software requirements process, orienting the five subareas (requirements elicitation, requirements analysis, requirements specification, requirements verification, and requirements management) and showing how the requirements process dovetails with the overall software engineering process.

Requirement analysis is concerned with identifying concepts related to the requirements and creating a conceptual model of the problem domain. A conceptual model shows a static view of associations between concepts. This section reviews OO conceptual modeling and its main components.

Conceptual models are models of entities from the problem domain that are configured to reflect their real-world relationships and dependencies. This section defines requirements, explains requirements analysis, and several types of model diagrams that can be developed. This includes data and control flows, state models, event traces, user interactions, object models, data models, and many others. The model must be selected according to the nature of the problem, the software engineer's expertise, the customer's process requirements, and the availability of methods and tools. The development then transitions from the requirements model to a design model, such that a requirement is allocated to one or more design elements. The section summarizes requirements analysis functions and activities, the use of the requirements, and the products of analysis.

The use case is the first key OO modeling diagram discussed for application in the requirements phase of the SDLC. Use cases are a powerful way of modeling what the system needs to do. "Actors" are key in capturing requirements; the following section elaborates on their use in requirements analysis.

This section goes into more detail on use case diagrams for requirements. What components are in a use case diagram (actors, extensions, stereotypes, and notes)? How are different interactions and features depicted for people who use the application? How are these features mapped into a use case diagram? Remember that a use case diagram cares about "what", not "how". This discussion provides a "big picture" of use cases, their use, and their relationship with "white box" details. These essential elements comprise a use case, rules-of-thumb guidance, the importance of the narrative text connected to a use case diagram, and user stories as an alternative to a use case diagram.

During the requirements analysis phase, the system can be treated as a single "black box", meaning we can look at the system's behavior (what it does) without explaining how it does it. Watch this example of a system sequence diagram for a student admission use case.

System behavior can be described using sequence diagrams. These can help visualize the workflow and how components work with each other. Be sure to understand the main components of a sequence diagram (participants, lifelines, boxes, dividers, and interactions) and how to design it. As you read, remember that the sequence diagram is about "how", not "what". This section includes an example of a sequence diagram and presents sequence diagrams in the context of dynamic diagrams.

Software requirements tools support requirements activities: modeling, analyzing, prioritizing, classifying, managing (planning, scheduling, reviewing, and monitoring), measuring, allocating to design and implementation components, tracing, version and configuration identification and control, and validating. The modeling and diagramming tools, management, measurement, allocation, and configuration management tools are common in each SDLC phase. Formal tools provide support for analysis of correctness, completeness, and consistency; for generation of test cases, use cases, and other UML models; and for translating formal specifications diagrams to requirements specification documents.

This section gives insight into software design principles: abstraction, coupling and cohesion, decomposition and modularization, encapsulation/information hiding, separation of interface and implementation, sufficiency and completeness, and primitiveness. Software architecture discusses architectural views and design strategies (function-oriented, data-oriented, and object-oriented. The transition from "what" (the problem domain) to the "how" (the solution domain) takes place in the design phase from high-level to detail-level design.

We have studied UML diagrams for the requirements phase of the SDLC, particularly use case and sequence diagrams. In addition, we have read about other UML diagrams (like static or structure diagrams) and other concept modeling diagrams (like entity-relation diagrams). We focused on use cases and sequence ones because those provide key support in capturing requirements and transitioning to design. In design, the diagrams created in the Requirements phase are extended by adding details to those diagrams or creating other diagrams (like collaboration diagrams). It is important to recognize the concepts represented in each type of diagram and that a diagram is a language for communicating those concepts. Those concepts can be represented in different ways, involving one type of diagram, several types of diagrams, or a diagram and associated narratives. Recall the detailed textual/narrative information for contracts associated with a use case diagram; also, recall the references we've made to other or optional or additional textual information. These concepts will be elaborated by evolving their diagram representations in the design and construction phases.

A major task of the design phase is creating the interaction diagrams for the system operations. Read this section to learn more about collaboration diagrams. As you review the examples, consider general principles in assigning responsibilities. Ask yourself, how do you determine the relationship between objects? How can you extract the classes? How do you determine whether a mentioned feature can be considered a class attribute? How would you determine class methods?

Watch this video on creating collaboration diagrams. Earlier units and sections have presented UML diagrams, and we have seen that the names of some diagrams vary with different releases of UML. Note that a collaboration diagram is an activity diagram called a "communication diagram".

One part of the software design process is to record the methods corresponding to responsibilities and group these methods in classes. These classes with methods are software classes representing the conceptual classes in the conceptual models. Read this section to walk through the steps of making a class diagram.

This video is an example of a complete project that reviews what we've discussed in this course. What is the difference between functional and non-functional requirements? Give an example of each presented in this sample software project. Which life cycle is it using? The second hour of the video uses an enterprise view to give program examples of the concepts discussed in this unit.

The goal of design is to map the application's requirements to a hardware and software environment. The result of process-oriented analysis – data flow diagrams, data dictionary entities, and so on – is translated into detailed specifications for hardware and software. The main output of process-oriented design includes structure charts, physical databases, and program specifications.

In this chapter, you will learn about the concepts and terminologies for process-oriented design and the steps of process-oriented design, including transaction analysis, transform analysis and structure charts, physical database design, program packages, and program design. You will also learn about the strengths and weaknesses of process-oriented design.

This text uses the Martin (1990) version of Information Engineering to illustrate data-oriented design. The result of data-oriented analysis – entity-relationship diagrams, data flow diagrams, CRUD matrices, and so on – is translated into screen designs, production database designs, action diagrams, procedural structures, and security plans. Compared to other approaches, data-oriented design strongly emphasizes security, recovery, and audit controls, relating each to data and processes in the application.

In this chapter, you will learn about the concepts and terminologies for data-oriented design, analyzing data and defining system controls, and the action diagram. The action diagram shows the processing details for an application in a structured format, which can be translated into programs and modules. You will also learn about menu structure, dialogue flow, and hardware and software installation and testing.

The text uses the Booch (1991) methodology to illustrate object-oriented design. The result of object-oriented analysis is translated into time-event diagrams, Booch diagrams, message communications, service objects, and process diagrams. Collectively, they constitute a set of holistic specifications to effectively allocate functionality over program modules at the lowest level and multiprocessor configurations at the highest level.

The Booch notation has been unified with other object-oriented notations (Rumbaugh and Jacobsen) into Unified Modeling Language (UML). In Unit 10, we will look at another example of object-oriented analysis and design using the UML notation. Therefore, you may skim this chapter to gain familiarity with OOD, which you will apply in Unit 10.

What is the difference between OOL (Object Oriented Language) and OOD?

Construction languages include all forms of communication that a human can use to specify an executable problem solution to a computer. As you read, differentiate between different languages and three general kinds of notation used for programming languages: linguistic (word-like strings of text), Formal (words and text strings backed up by precise, unambiguous, and formal or mathematical definitions), and visual (direct visual interpretation and placement of visual entities).

Software construction includes coding of components, linking with library code, and integration of components to form a complete system. Software construction is an activity where the transition from the solution domain (planning, architecture, design) to the problem or real-world domain starts or increases depending on the software development methodology used. This gives a concise and relevant overview of software construction. It is relevant for all programming languages: old languages like COBOL and FORTRAN, current languages like Java, C++, and Python, internet languages like HTML and JavaScript, and distributed and concurrent programming languages.

Software configuration management (SCM) is a critical element of software engineering. Read about the benefits of control systems and consider issues that might arise in the implementation process. SCM is a supporting software life cycle process that helps development and maintenance activities, assurance activities, and project management in general. We will discuss these further in Unit 9. 

Software Configuration Management is a process for identifying, controlling, and managing software artifacts during the SDLC and the entire life cycle of the developed software system. Beginning with the Software Requirements, project development produces an architectural structure that evolves into an organization of many software components, each of which may have many versions. The versions result from changes to specifications during development, correction of errors, or allocation to multiple hardware platforms and operational environments. A software configuration is an integral subset of the architectural component versions needed to satisfy requirements. Multiple software configurations may be necessary to meet all the requirements. 

As with version control tools, SCM software support has not changed. The SCM processes and procedures have been stable. New technology has not changed them but has improved their "ilities" – usability, adaptability, reliability, and scalability.

This is a quick introduction to many terminologies used in the science (and art) of testing. Do not worry if you do not understand them fully. We will examine these topics more deeply by looking closely at test strategies (white-box, black-box, top-down, and bottom-up) and the testing levels (unit, integration, and system tests).

Unlike physical systems, most of the defects in software are design errors. Read about the important purpose of software testing and differentiate between verification and validation and basic software testing terms. Compare and contrast various testing strategies, including black-box, white-box, top-down, and bottom-up.

In this section, you will learn about two kinds of test strategies: how the logic is tested (via black-box and white-box testing) and how the testing is conducted (by top-down and bottom-up testing).

This section shows the elements of a software test plan and how one company designs testing to validate that specification, design, and coding mesh with the functional and non-functional requirements of the system. The development of a test plan takes into consideration the programming language. Selection of a programming language can involve considering older languages, like COBOL, first used in 1960. Suppose a company has legacy business systems and a project application is well known to the company (meaning that it is a system with precedent) with stable requirements. In that case, COBOL might be a good choice. Indeed, a scan of job openings 70 years after COBOL was first used often finds several openings for COBOL programmers.

As you review this test plan, think about a plan to verify and validate the goals, design (organization and flow), and content of this course, CS302. Recall that at a high enough level of abstraction, the SDLC can be applied to other types of development, including course development.

The software engineer and the project manager provide complementary skills and work collaboratively on shared activities. The three main activities of the project manager are organizational liaison, personnel management, and project monitoring and control. The "Liaison" section discusses the project manager's role as a go-between for the technical team and agents who are not members of the technical team (such as project sponsors, users, IS management, vendors, and so on). In the "Personnel Management" section, you will learn that this job entails working with personnel and human resources to hire, fire, and provide employees with professional development. The "Monitor and Control" section explains that project monitoring involves tracking project progress relative to budget. Project control means implementing changes when progress is unsatisfactory (such as training or revising project plans).

In software engineering, management activities occur at three levels: organizational and infrastructure management, project management, and measurement program planning and control. This section describes the areas of project management, including initiation and scope definition, project planning, project enactment, review and evaluation, and engineering measurement. These subjects are often regarded as separate, and indeed, they possess many unique aspects. Their close relationship has led to their combined treatment in software engineering, as effective management requires a combination of both numbers and experience.

A critical component of project monitoring and control is change management. As business requirements and operating environments change, the project manager has to manage change throughout the software development cycle from acquisition, supply, development, operation, and maintenance. The guiding principles, techniques, and tools for change management are discussed in this chapter and complement what we read earlier.

The notion of "quality" is not as simple as it may seem. For any engineered product, many desired qualities are relevant to a particular project. The section explains software quality fundamentals, including the main SQM processes: quality assurance, verification, validation, review, and audit. Software quality refers to the delivered product of a software development project, but that quality depends on the quality of the "upstream" products from which it was derived, including requirements, design, construction, and the software quality activities that support it during the development, namely, validation, verification, testing, and measurement. Software quality terminology is numerous, informal, formal, and often ambiguous, with multiple categorizations (internal, external, operational, and feature quality). All of this makes software quality interesting to study.

From a domain perspective, software quality applies to both the problem application domain and the solution domains. It applies to all software development activities and all software products. It is interdisciplinary in that it is a topic in management, software engineering, mathematics, statistics, measurement, and more. It intersects the generic categories of human, software, and hardware and refers to the evolving relationships of these generic types. This last observation hints at the next stage in the evolution of computing technology. 

Software quality is a major driving factor for computing technology evolution, which is increasing our capabilities to solve complex problems better, faster, on a larger scale, and with more automation. Generally, the problem domain gets smaller as the solution domain gets larger. The solution domain gets larger as hardware and software support becomes automated. More automation often begins with new abstractions we make in the problem domain, resulting in new relationships between hardware and software, eventually manifesting as automated support tools. We give names to these tools: "cloud computing", big databases, programming languages (front-end, network, back-end, and so on), and AI (natural language translation, image recognition, and machine learning). Indeed, software quality is very interesting.

Watch these videos, which outline a case study in software engineering. 

Pretend you are a teacher for an online course. It can be a struggle for course developers to keep their courses interesting and fun or to encourage students to work together since their classmates are all virtual. Your project for this subunit is to develop a fun interactive game for this class. Watch this interview for inspiration. Develop a problem statement for this project. As a student, you should have plenty of ideas on how you like to study and learn! The game should advocate properly using the software engineering process presented in this course. The model for this process is the perspective of available industry job requirements, expressed as qualities of a future teammate: skills, values, and fun. There are additional perspectives that can be considered, for example, one of the perspectives included in this course: principles, process/data/object abstraction, and useful problem/solution models.

Read these instructions, which pertain to the following assessment. As you complete this activity, make sure you know how to determine major stakeholders and how test plans are designed using different strategies (black-box, white-box, top-down, and bottom-up).