Topic | Name | Description |
---|---|---|
Course Syllabus | Course Syllabus | |
1.1: An Overview of Software Engineering | Introduction to Software Engineering | 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. |
1.2: What Is Software Engineering? | The History of Software | 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. |
Six Degrees of Computer Science | 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? |
|
1.3: Software Applications | Fundamentals of Software Engineering | 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? |
1.4: Software Quality | Software Quality: Definitions and Strategic Issues | 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. |
1.5: Software Engineering Code of Ethics and Professional Practices | Ethics and Professional Practices | |
2.1: Software Development Life Cycle (SDLC) | Software Development Life Cycle | The software development life cycle (SDLC) consists of several phases.
Read this section to explore the software life cycle and these main
phases. |
2.2: Life Cycle Models | Software Development Approaches | 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. |
Software Development Models | 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. |
|
2.3: Software Development Team Roles | Introduction to Software Systems | Read this section. As you read, consider the various roles professionals play in software development processes. |
2.4: Software Development Methodologies | Introduction to Software Engineering/Methodology | 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? |
Software Development Life Cycle Methodologies | 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. |
|
3.1: Object-Oriented Concepts | Object-Oriented Programming | 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. |
Object-Oriented Terms | 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. |
|
3.2: An Overview of UML | What is Unified Modeling Language? | 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. |
Fundamentals of UML | 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. |
|
Introduction to UML in Software Engineering | 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. |
|
Introduction to UML | 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? |
|
Use Cases | 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? |
|
3.3: UML Diagrams | Fundamentals of UML Diagrams | 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. |
UML State 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? |
|
UML Class Diagrams | Watch this video. The lecture provides a discussion of the class diagram in UML. What is the purpose of the class diagram? |
|
UML Activity Diagrams | Watch this video carefully as an example of modeling. What is the purpose of an activity diagram? How would you create an activity diagram? |
|
3.4: Modeling Concepts | Object-Oriented Design | Watch this video. The lecture provides a discussion of using UML for object-oriented design. |
UML as a Modeling Tool | 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. |
|
4.1: What are Requirements and Data Types? | Data Gathering for Application Development | 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. |
Writing Software Requirements | 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. |
|
Object-Oriented Analysis | 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. |
|
4.2: Requirements and Data Gathering Techniques | Data Collection Techniques | 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. |
4.3: Data Collection Techniques for Various Application Types | Data Gathering Techniques for Each Application Type | Read this section and identify the data gathering techniques most useful for each application type. |
5.1: Requirements Fundamentals | Fundamentals of Requirements Analysis | 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. |
5.2: The Requirements Process | The Requirements Process | 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. |
5.3: Conceptual Modeling | Conceptual Modeling in Object-Oriented Analysis | 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 Modeling in Requirements Analysis | 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. |
|
5.4: Use Case Diagrams | Use Case Concepts in Object-Oriented Analysis | 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. |
More on UML Use Case Diagrams | 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. |
|
5.5: Sequence Diagrams | UML Sequence Diagrams | During the requirements analysis phase, the system can be treated as a single "black box", which means that we can look at the system's behavior (what it does) without explaining how it does it. Read this section to see an example of a simplified trace diagram
that shows only system input events. This is called a system sequence diagram. |
More on UML Sequence Diagrams | 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. |
|
6.1: Software Design Principles | Software Design | 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. |
6.2: Architectural Design | UML Collaboration Diagrams | 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? |
UML Class Diagrams | 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. |
|
Technical Documentation | 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. |
|
6.3: Software Design Approaches | Software Architecture in Practice | 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. |
Process-Oriented 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. |
|
Data-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. |
|
Object-Oriented Design | 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. |
|
7.1: History of Programming | Object-Oriented Implementations | Watch and listen carefully to this video. What is the difference between OOL and OOD? |
7.2: Choosing Implementation Languages | Software Construction | 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). |
7.3: Version Control Systems | Software Configuration Management | 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. |
8.1: Software Testing Terminologies | Testing Terminology | 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). |
8.2: Software Testing Strategies | Software Testing | 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. |
Testing Strategies | 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). |
|
8.3: Software Test Coverage | Test Plan for ABC Video Order Processing | 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. |
9.1: Project Management | Project Management | 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). |
Software Engineering Management | 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. |
|
9.2: Change Management and Quality Control | Change Management | 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. |
Software Quality Management | 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. |
|
10.1: Preparation and Case Studies | Software Engineering Case Study | 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. |
Teaching Software Development | 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. |
|
10.2: Capstone Activity | Design Modification and Quality Control Activity | 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). |
Course Feedback Survey | Course Feedback Survey |