CS302: Software Engineering (2021.B.01)

Watch this video of the first day in a software engineering course at Harvard University. 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 the systematic process to complete a course similar to this one, especially the SDLC projects (Unit 10). The video mentions a number of software tools for software development. Do not be overwhelmed, 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. As you proceed through this course, these items will appear as controversies and opportunities to evaluate other alternatives.

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

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 quality models. Notice the priority of quality factors and how software quality can be measured.

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.

This is a summary of software development models. Read this summary 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.

Read this section. As you read, consider the various roles professionals play in software development processes.

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 good information, so take notes and/or find the time to watch and listen more than once. Pay particular attention to Scrum as it is one of the most widely used Agile methodologies nowadays.

This is a very complete overview of object-oriented programming with references to a number of different object languages. As you watch the video be sure to list each component of an object-oriented language as well as a brief descriptive statement. As you complete the subunits on UML, note how each component is diagrammed.

Read this section, which 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.

Read this article, and compare the summary of diagram types with those in your notes. UML 2.0 added three new diagrams: instance, role, and internal structure. An internet search for UML 2.0 diagrams will provide a number of examples, especially modeling software vendor sites.

Unified Modeling Language (UML) is a graphical modeling language that provides the syntax for describing the major artifacts of software systems. Read this section to understand the purpose of UML.

UML is managed as a de facto industry standard by the Object Management Group (OMG). This article includes a review about UML History, Definition and its main diagrams.

Watch this video. The lecture provides information to introduce UML as a tool for software engineers. After watching the video, write a summary that answers the following question: what is UML?

Watch this video. The lecture provides a discussion of the use case diagram in UML. Can you describe each component of a use case diagram?

A diagram is the graphical presentation of a set of elements. UML has a lot of different diagrams. Read this section, and make sure you can differentiate between different diagrams.

Watch this video. The lecture provides an overview of state machines and the state diagram in UML. What is the purpose of the state diagram?

Watch this video. The lecture provides a discussion of the class diagram in UML. What is the purpose of the class diagram?

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

Watch this video. The lecture provides a discussion of using UML for object-oriented design.

Modeling is the designing of 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.

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?

Also pay special attention to the section of 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.

Analysis emphasizes an investigation and understanding of the problem domain and requirements, rather than a solution. Read this section to learn more about some of the terms and concepts related to requirements and their types. These terms can seem ambiguous at first, but we will quickly learn how they relate to one another.

Data gathering is the interaction between the software engineer (in this case a business analyst) and the customers (including users). There are many techniques for gathering data, including interviews, meetings, observations, questionnaires, reviewing software, reviewing internal documents, and reviewing external documents. Read this section to differentiate between them and pay attention to the main advantages and disadvantages of each one of these techniques.

Read this section and identify the data gathering techniques most useful for each 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 main features of requirements.

This section introduces the software requirements process, orienting the remaining 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 with creating a conceptual model of the problem domain. A conceptual model shows a static view of associations between concepts. This section defines conceptual modeling and reviews the main components of it.

Conceptual models are models of entities from the problem domain that are configured to reflect their real-world relationships and dependencies. This section explains several kinds of models 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 expertise of the software engineer, the process requirements of the customer, and the availability of methods and tools.

Use cases are a powerful way of modeling what the system needs to do. Read this section to learn about use case diagrams and how they capture functional requirements.

Find out what components are in a use case diagram (actors, extensions, stereotypes and notes), how to depict different interactions and features for which people use the application and how to map these features into a use case diagram. As you read this section, keep in mind that a use case diagram cares about WHAT, not HOW.

System Behaviour can be described using sequence diagrams. These can help in visualizing 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 this section, keep in mind that sequence diagram diagram cares about HOW, not WHAT.

Software design is an activity that identifies software components and their relationships based on a customer’s requirements. Design is about how to solve a problem. This section gives detailed information about main software design concepts and principles such as abstraction, coupling and cohesion, and encapsulation.

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 go through the examples, pay attention to 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 as a class attribute or not? How would you determine class methods?

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 is an example of a complete project that reviews what we've discussed so far 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 we've discussed in this unit.

Read this section to learn about the main elements, patterns, quality attributes, and principles of software architecture, including encapsulation, polymorphism, and dependencies. Pay attention to design patterns and their importance in software design.

The goal of design is to map the requirements of the application 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, as well as 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 has a strong emphasis on 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 methodology (1991) 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 as well as 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 quickly to gain familiarity with OOD, which you will apply in Unit 10.

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 configuration management (SCM) is a critical element of software engineering. Read about the benefit 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.

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

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 the use of various testing strategies, including black-box, white-box, top-down, and bottom-up.

In this section, you will learn about two kinds of testing 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).

In this section, see how ABC Video designs testing to validate that specification, design, and coding mesh with functional and non-functional requirements of the system.

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 not satisfactory (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 being separate, and indeed they do 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 all the time, the project manager has to manage change throughout the software development cycle from acquisition, supply, development, operation, and then maintenance. The guiding principles, techniques, and tools for change management are discussed in this chapter.

The notion of "quality" is not as simple as it may seem. For any engineered product, there are many desired qualities relevant to a particular project. The section explains software quality fundamentals, including the main SQM processes: quality assurance, verification, validation, review, and audit.

Watch these videos, which outline a case study in software engineering. As you watch, you may wish to reference the transcripts for each video, which can be found here for the first lecture and here for the second lecture.

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 the proper use of the software engineering process presented in this course.

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).