317 courses ePortfolio Forums Blog FAQ

Software Engineering

Purpose of Course  showclose

Software engineering is a discipline that allows us to apply engineering and computer science concepts in the development and maintenance of reliable, usable, and dependable software. The concept of software engineering was first discussed at the 1968 NATO Science Committee in Germany. Today, many practitioners still debate over the term software engineering, often arguing that this discipline does not meet the criteria of engineering; rather, it should be called software development. There are several areas to focus on within software engineering, such as design, development, testing, maintenance, and management. Software development outside of the classroom is a very complex process, mostly because real-world software is much larger and more complex.

The purpose of this course is to present software engineering as a body of knowledge. The course is designed to present software engineering concepts and principles in parallel with the software development life cycle. The course will begin with an introduction to software engineering, giving you a definition of this body of knowledge, as well as a discussion of the main methodologies of software engineering. You will then learn about the Software Development Life Cycle (SDLC) followed by software modeling using Unified Modeling Language (UML), a standardized general-purpose modeling language used to create visual models of object-oriented software. You will go on to learn about five major phases of the SDLC: requirements gathering, requirements analysis, design, coding/implementation, and testing. You will also learn about project management for the purpose of delivering high-quality software that satisfies customer needs and is within budget.

By the time the course is complete, you will master software engineering concepts, principles, and essential processes of the SDLC; you will demonstrate this knowledge by creating UML artifacts for requirements gathering, analysis as well as design phases using an object-oriented methodology.

Course Information  showclose

Welcome to CS302: Software Engineering. General information on the course and its requirements can be found below.
 
Course Designer: Irene Wong-Bushby
 
Primary Resources: This course is comprised of a range of different free, online materials. However, the course makes primary use of the following materials:
 
The Global Text Project: Sue Conger’s The New Software Engineering (PDF)
 
Requirements for Completion: In order to complete this course, you will need to work through each unit and all of its assigned materials. Pay special attention to Unit 1, as this unit will lay the groundwork for understanding the more advanced, exploratory material presented in later units.
 
Note that you will only receive an official grade on your final exam. However, in order to adequately prepare for this exam, you will need to work through the assigned materials in each unit.
 
In order to pass this course, you will need to earn a score of 70% or higher on the final exam.Your score on the exam will be tabulated as soon as you complete it. If you do not pass the exam, you may take it again.
 
Time Commitment: Completing this course should take you about 135 hours. Each unit includes a time advisory that lists the amount of time you are expected to spend on each subunit. These should help you plan your time accordingly. It may be useful to take a look at these time advisories and to determine how much time you have over the next few weeks to complete each unit, and then to set goals for yourself. For example, completing Unit 1 should take you approximately 20.5 hours. Perhaps you can sit down with your calendar and decide to complete subunit 1.1.1 (a total of 1.5 hours) on Monday night; subunit 1.1.1.1 (a total of 3 hours) on Tuesday night; subunit 1.1.1.2 (a total of 2.5 hours) on Wednesday night; etc.
 
Suggestions/Tips: This course is based on The Global Text Project: Sue Conger’s text The New Software Engineering. Except for Units 3 and 10, you will benefit from going through the course in sequence, as the concepts build on each other throughout the text. If you are already familiar with object-oriented analysis and design (OOAD), you may skip Unit 3 or use Unit 3 as a review. Unit 10 represents a summative review of OOAD, using a case-study approach. This course gives special emphasis to OO, as the OO perspective is compliant with ACM/IEEE’s software engineering curriculum. It may help to take detailed notes as you work through the text, which will help you prepare for your final exam. 

Learning Outcomes  showclose

Upon successful completion of this course, you will be able to:
  • demonstrate mastery of software engineering knowledge and skills, and professional issues necessary to practice software engineering;
  • discuss principles of software engineering;
  • describe software development life cycle models;
  • apply principles of software modeling through UML as a modeling language;
  • identify major activities and key deliverables in a software development life cycle during software requirements and analysis, software design, and software testing;
  • apply the object-oriented methodology in software engineering to create UML artifacts for software analysis and requirements, software design, and software testing;
  • apply project management concepts in a software engineering environment to manage projects, people, and products; and
  • participate as an individual to deliver quality software systems.

Course Requirements  showclose

In order to take this course, you must:

√    have access to a computer;

√    have continuous broadband Internet access;

√    have the ability/permission to install plug-ins or software (e.g. Adobe Reader or Flash);

√    have the ability to download and save files and documents to a computer;

√    have the ability to open Microsoft files and documents (e.g. .doc, .ppt, .xls, etc.);

√    be competent in the English language; and

√    have completed the following courses in The Core Program of the Computer Science discipline: CS101, CS102, CS107, CS201, CS202, and CS301.

Unit Outline show close


Expand All Resources Collapse All Resources
  • Unit 1: Introduction to Software Engineering  

    When dependency on software and computers became more important, software grew in size and became a necessity for businesses and users all over the world. In the last 30 years, we have seen an unparalleled explosion in the amount of software produced and used by our modern society. There is nowa need to set concrete objectives (e.g. functional requirements), predict necessary resources (e.g. cost estimates) to attain those objectives, and manage customers’ expectations.
     
    As you review the material in this unit, compare and contrast software engineering with computer science. These two disciplines are closely related, but they have some differences. It is important to gain this understanding as you review the material in subunit 1.1.1.2. Also, spend some time on the three commonly used methodologies in software engineering (i.e., data-oriented, process-oriented and object-oriented). You will find this central theme (i.e. the three methodologies) repeated in software requirements and analysis as well as software design.

    Unit 1 Time Advisory   show close
    Unit 1 Learning Outcomes   show close
  • 1.1 Software Engineering Overview  
  • 1.1.1 What Is Software Engineering?  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 1: Overview of Software Engineering”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 1: Overview of Software Engineering” (PDF)
       
      Instructions: Read the sections titled “Introduction” and “Software Engineering” in Chapter 1 (pages 1–4). You will use this text throughout the course, so you may want to save a copy of the PDF to your desktop to easily access it as you move through each unit. This text positions software engineering as a multi-trillion dollar investment in typical Fortune 1000 companies. It discusses what software engineering is and defines basic software engineering terms. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and then taking time off to comprehend should take approximately 1 hour and 30 minutes.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 1.1.1.1 History of Software Engineering  
  • 1.1.1.2 Differences between Software Engineering and Computer Science  
  • 1.1.2 Software Applications  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 1: Overview of Software Engineering”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 1: Overview of Software Engineering” (PDF)
       
      Instructions: Read the section titled “Applications” in Chapter 1 (pages 5–23). This reading assignment covers the topics of software characteristics, software responsiveness, types of applications, and applications in business. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      In the section titled “Application Characteristics” (pages 5–13), make sure to carefully review Figure 1-1 on page 6 for an overview of software characteristics.
       
      In the section titled “Application Responsiveness” (pages 13–17), make sure to carefully review Figure 1-12 on page 14 for an overview of two types of software responsiveness.
       
      In the section titled “Applications in Business” (pages 22-23), make sure to carefully review Figure 1-17 on page 22 for an overview of application in business.
       
      Reading this selection, taking notes, and then taking time off to comprehend should take approximately 6 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 1.1.3 Software Quality  
  • 1.2 Software Engineering Methodologies  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 1: Overview of Software Engineering”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 1: Overview of Software Engineering” (PDF)
       
      Instructions: Read the following sections in Chapter 1: “Methodologies” (pages 34–39) and “User Involvement in Application Development” (pages 39–40). Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      A methodology is a body of practices within a discipline (e.g. software engineering). It can contain procedures, techniques, and processes. According to Conger, there are five classes of software engineering methodologies. For the purpose of this course, you will look at the more commonly used data-oriented, process-oriented, and object-oriented (OO) methodologies. This course places special emphasis on the OO methodology. The OO perspective is compliant with ACM/IEEE’s Software Engineering curriculum.
       
      Reading this selection, taking notes, and then taking time off to comprehend should take approximately 1 hour and 30 minutes.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 1.3 Software Engineering Code of Ethics and Professional Practices  
  • Unit 2: Software Development Life Cycle Models  

    Software development life cycle (SDLC) refers to the process of software development. The International Organization for Standardization’s ISO12207, the industry standard for software life cycle processes, describes the development process as consisting of requirements, design, code, and (three levels of) testing. There are different approaches to break down the work when developing software systems. Waterfall, v-shape, prototype, incremental, spiral, etc. are examples of SDLC models. Conceptually, each model provides specific guidance to the sequencing and repetition of life cycle activities to deliver high-quality software systems. The various life cycle models fall into two basic categories: sequential and iterative.
     
    As you review the material in this unit, try to see the similarities in these two categories of life cycle models from the ISO12207 development process perspective (i.e., requirements, design, code, and testing). This will help you grasp the basic concepts of SDLC. This unit connects strongly with Unit 9: Project Management. Choosing and managing a software life cycle process is a central component of project management.

    Unit 2 Time Advisory   show close
    Unit 2 Learning Outcomes   show close
  • 2.1 Software Development Life Cycle (SDLC)  
  • 2.2 Sequential Life Cycle Model  
  • 2.3 Iterative Life Cycle Model  
  • Unit 3: Software Modeling  

    Many believe that good design is fundamental to creating successful software. The first step in software creation is to gather requirements.Notations, such as UML, allow us to articulate complex ideas succinctly and precisely. Designing software requires the use of certain industry standard design tools, and mastery of them is essential to becoming a capable software engineer.
     
    This unit will introduce you to UML, a standardized general-purpose modeling language for creating visual models of object-oriented software. This unit aims to give you a comprehensive understanding of UML, the five fundamental artifacts of UML, and modeling concepts, as well as the modeling concepts’ relationships to the terms system, model, and view.

    Unit 3 Time Advisory   show close
    Unit 3 Learning Outcomes   show close
  • 3.1 Object-Oriented Concepts  
  • 3.2 An Overview of UML  
    • Lecture: Mike Murphy’s “Introduction to UML”

      Link: YouTube: Mike Murphy’s “Introduction to UML” (YouTube)
       
      Instructions: Watch this 8 minute 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?
       
      Watching this lecture, taking notes, and taking time to comprehend should take approximately 1 hour
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 3.2.1 Use Case Diagrams  
    • Lecture: Mike Murphy’s “Use Cases”

      Link: YouTube: Mike Murphy’s “Use Cases” (YouTube)
       
      Instructions: Watch this 11 minute video. The lecture provides a discussion of the use case diagram in UML. Can you describe each component of a use case diagram?
       
      Watching this lecture, taking notes, and taking time to comprehend should take approximately 1 hour and 30 minutes.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 3.2.2 State Diagrams  
    • Lecture: Mike Murphy’s “UML State Diagrams”

      Link: YouTube: Mike Murphy’s “UML State Diagrams” (YouTube)
       
      Instructions: Watch this 12 minute video. The lecture provides an overview of state machines and the state diagram in UML. What is the purpose of the state diagram?
       
      Watching this lecture, taking notes, and taking time to comprehend should take approximately 2 hours.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 3.2.3 Class Diagrams  
    • Lecture: Mike Murphy’s “UML Class Diagrams”

      Link: YouTube: Mike Murphy’s “UML Class Diagrams” (YouTube)
       
      Instructions: Watch this 10 minute video. The lecture provides a discussion of the class diagram in UML. What is the purpose of the class diagram?
       
      Watching this lecture, taking notes, and taking time to comprehend should take approximately 1 hour and 30 minutes.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 3.2.4 Activity and Interaction Diagrams  
  • 3.3 Modeling Concepts  
    • Lecture: Mike Murphy’s “Object-Oriented Design”

      Link: YouTube: Mike Murphy’s “Object-Oriented Design” (YouTube)
       
      Instructions: Watch this 9 minute video. The lecture provides a discussion of using UML for object-oriented design.
       
      Watching this lecture, taking notes, and taking time to comprehend should take approximately 1 hour an 30 minutes.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 3.4 UML 2.0  
  • Unit 4: Software Requirements Gathering  

    Requirements gathering requires the software engineer (in this case, a business analyst) to interact with the stakeholders, including customer and users,to gather/collect information about what the software system being developed needs to do. There is also the situation where vendors are subcontracted to develop all, or some components, of the software systems and/or develop the hardware that the software will run on. In this case, the vendors bid on the subcontract by providing a proposal in responds to a request for proposals. In this unit, you will learn the data/information types, data collection techniques, and data collection and application types. This unit will set the stage for the next two units: Unit 5: Software Requirements Analysis, and Unit 6: Software Design.

    Unit 4 Time Advisory   show close
    Unit 4 Learning Outcomes   show close
  • 4.1 Data Types  
  • 4.2 Requirements/Data Gathering Techniques  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 4: Data Gathering for Application Development”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering“Chapter 4: Data Gathering for Application Development” (PDF)
       
      Instructions: Read “Chapter 4: Data Gathering for Application Development” (pages 87–98). Data collection/gathering is also referred to as requirements gathering. Data gathering is the interaction between the software engineer (in this case a business analyst) and the customers (including users) to obtain/gather data/information about the application to be developed. There are many techniques for gathering data. The data collection techniques include interviews, meetings, observations, questionnaires, reviewing software, reviewing internal document, and reviewing external documents.Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection and taking notes should take approximately 3 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 4.3 Data Collection Technique and Application Type  
  • Unit 5: Software Requirements Analysis  

    Requirements elicitation requires the software engineer to interact with the stakeholder including customer users,to gather information about what the software system needs to do. In this unit, we examine the software engineer’s activities to elicit, to analyze (or translate), to validate and to manage this phase of the life cycle in working with the customerto achieve a common understanding of the customer’s goals. This set of activities is referred to as analysis and focuses on what the application will do, whereas design describes how the application will work (Unit 6: Software Design). There are many ways to elicit and analyze customerrequirements. As introduced in subunit 1.2, the three most commonly used methodologies are data-oriented, process-oriented, and object-oriented. In this unit, we will drive deeper and examine the conceptual foundations, activities, and deliverables underlying each of these methodologies applicable to software requirements and analysis.
     
    As you review the material in this unit, spend some time on the object-oriented methodology as it applies to software requirements and analysis. You will be applying this in a later unit to put it all together in a case study.

    Unit 5 Time Advisory   show close
    Unit 5 Learning Outcomes   show close
  • 5.1 Requirements Fundamentals  
  • 5.1.1 Characteristics of Good Requirements  
  • 5.1.2 Content of Good requirements: Functional and Non-functional  
    • Reading: Institute of Electrical and Electronics Engineers, Inc.: IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications

      Link: Institute of Electrical and Electronics Engineers, Inc.: IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications (PDF)
       
      Instructions: Read sub-sections 5.3.1 through 5.3.6 in section “5.3: Specific Requirements,” on pages 15–18. In addition to the eight characteristics of good SRS, the IEEE recommends both functional and non-functional requirements for good SRS. Functional requirements represent what the system will do to accept and process inputs and generate outputs. For example, for an accounting system, this may be customer statement preparation at the end of the month. Non-functional requirements represent how the system has to be to satisfy system constraints. For example, this may be to prepare all customer statements within a five-hour batch window. As you read the text, note that sub-sections 5.3.1, 5.3.2, and 5.3.4 are classified as functional requirements, whereas sub-sections 5.3.3, 5.3.5, and 5.3.6 are classified as non-functional requirements.
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 2 hours and 30 minutes.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 5.2 Requirements Activities  
    • Reading: Carnegie Mellon’s Software Engineering Institute: A Framework for Software Product Line Practice, Version 5.0: “Requirements Engineering”

      Link: Carnegie Mellon’s Software Engineering Institute: A Framework for Software Product Line Practice, Version 5.0: “Requirements Engineering” (HTML)
       
      Instructions: Read this article. According to Carnegie Mellon’s Software Engineering Institute SEI, there are five techniques—requirements elicitation, requirements analysis, requirements specification, requirements verification, and requirements management—that can be applied systematically in the requirements process. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 1 hour and 30 minutes.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 5.3 Requirements Analysis Methodologies  
  • 5.3.1 Process-Oriented Analysis  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 7: Process-Oriented Analysis”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 7: Process-Oriented Analysis” (PDF)
       
      Instructions: Read “Chapter 7: Process-Oriented Analysis” (pages 227–278). Process-oriented analysis originated with the work of Yourdon-DeMarco and Gane-Sarson. The analysis follows a top-down approach to progressively more detailed levels of process analysis, resulting in context diagrams, data flow diagrams, and data dictionary entities. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehendshould take approximately 5 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 5.3.2 Data-Oriented Analysis  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 9 Data-Oriented Analysis”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 9 Data-Oriented Analysis” (PDF)
       
      Instructions: Read “Chapter 9: Data-Oriented Analysis” (pages 328–390). Information engineering (IE) is the methodology used to illustrate data-oriented analysis. In the data-oriented approach, there is the notion that data are more stable than processes. Business area analysis (BAA), which is the IE term for analysis, begins with an analysis of data followed by business function processes resulting in entity-relationship diagrams (ERDs), data flow diagrams (DFDs), and the entity/process matrix called CRUD matrix (create, retrieve, update, delete).Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 7 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 5.3.3 Object-Oriented Analysis (OOA)  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 11: Object-Oriented Analysis”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 11: Object-Oriented Analysis (PDF)
       
      Instructions: Read the sections beginning with “Object-Oriented Analysis Activities” in “Chapter 11: Object-Oriented Analysis” (pages 463–500). Unlike process-oriented (which is focused on functional thinking) and data-oriented (which is focused on entity thinking) analyses, objected-oriented analysis is focused on object thinking. Data and processes are married early in the process and encapsulated into classes/objects. Object-oriented analysis (and design) represents a paradigm shift in software development. As you read this material, bear in mind that the text illustrates this approach using the Booch notation, which has been supplanted by the Unified Modeling Language (UML). However, much of the Booch notation has been unified in UML (and is therefore still valid)—especially the class diagrams— and classified into whole/part or generalization/specialization classes. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this this selection, taking notes, and taking time to comprehend should take approximately 4 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

    • Assessment: The Saylor Foundation’s “Unit 5 Checkpoint”

      Link: The Saylor Foundation’s “Unit 5 Checkpoint” (PDF)
       
      Instructions: Complete this assessment. When you have completed the assessment, check your answers against the “Unit 5 Checkpoint Guide to Responding”.
       
      Completing this assignment should take approximately 30 minutes.

  • Unit 6: Software Design  

    After requirements and analysis, a software engineer must transform the analysis model into a design model that can be implemented in a specific hardware and software environment. In this unit, we will discuss the principles of design and architecture design. Just as there are various methodologies for requirements analysis, we will drill down from the analysis model(s) to the design model(s) following the three corresponding methodologies (i.e., data-oriented, process-oriented, and object-oriented). 
     
    As you review the material in this unit, spend some time on the object-oriented methodology as it applies to software design. You will be applying this in a later unit to put it all together in a case study.

    Unit 6 Time Advisory   show close
    Unit 6 Learning Outcomes   show close
  • 6.1 Software Design Principles (Information Hiding, Cohesion, Coupling)  
  • 6.2 Architectural Design  
    • Web Media: Carnegie Mellon Software Engineering Institute: Paul Clement’s “Best Practices in Software Architecture”

      Link: Carnegie Mellon Software Engineering Institute: Paul Clement’s “Best Practices in Software Architecture” (MP3)
       
      Instructions: Listen to the architecture portion of the podcast (first 45 minutes). This audio introduces the fundamentals of software architecture design, including runtime and non-runtime qualities, architectural building blocks, etc. The material is not intended to be a step-by-step how to for performing architectural design (which is a huge topic), but rather to induce an appreciation for architectural design when it is done right. Pause as necessary for note-taking.
       
      Listening to this web media,taking notes, and taking time to comprehend should take approximately 2 hours.
       
      Terms of Use: Please respect the copyright and terms of use displayed on the webpage above.

  • 6.3 Software Design Approaches  
  • 6.3.1 Process-Oriented Design  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 8: Process-Oriented Design”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 8: Process-Oriented Design” (PDF)
       
      Instructions: Read “Chapter 8: Process-Oriented Design” (pages 278-327). 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, etc.—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 reading, you will learn about the concepts and terminologies for process-oriented design. This reading covers 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 strengths and weaknesses of process-oriented design. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehendshould take approximately 7 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 6.3.2 Data-Oriented Design  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 10: Data-Oriented Design”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 10: Data-Oriented Design” (PDF)
       
      Instructions: Read “Chapter 10: Data-Oriented Design” (pages 391-458). The 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, etc.—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 reading, 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/software installation and testing in this reading. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 9 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 6.3.3 Object-Oriented Design OOD  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 12: Object-Oriented Design”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 12: Object-Oriented Design” (PDF)
       
      Instructions: Please read “Chapter 12: Object-Oriented Design” (pages 501-553). 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. As discussed in subunit 5.3.3, the Booch notation has been unified with other object-oriented notations (i.e., Rambaugh 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 to Unit 10. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 7 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

    • Assessment: The Saylor Foundation’s “Unit 6 Checkpoint”

      Link: The Saylor Foundation’s “Unit 6 Checkpoint” (PDF)
       
      Instructions: Complete this assessment. When you have completed the assessment, check your answers against the “Unit 6 Checkpoint Guide to Responding”.
       
      Completing this assignment should take approximately 1 hour.

  • Unit 7: Implementation  

    Implementation, also known as programming or coding, is the process of using a programming language to convert specified requirements into software source code and later into compiled code for execution. Programmers can use automated tools to convert design requirements into code.
     
    Sometimes, vendors are subcontracted to develop all or part of the software—and even the hardware that it will run on—according to specified requirements. In these situations, vendors will bid on the subcontract by providing a proposal.

    Unit 7 Time Advisory   show close
    Unit 7 Learning Outcomes   show close
  • 7.1 History of Programming  
  • 7.2 Choosing Implementation Languages  
  • 7.3 Purchasing Hardware and Software  
  • Unit 8: Software Testing  

    Testing is the process of finding errors and is one of the last activities in the software life cycle. In testing, we look to validate that software requirements analysis, software design, and software implementation mesh together correctly to deliver a software system that performs as expected, functionally and non-functionally.
     
    As you review this unit, note the three levels of test plan: unit, integration, and system. Each of these levels of test plan assures the quality of the overall software from varying levels of granularity. In your own practice as a software engineer, be sure to incorporate these levels of testing as this is the last stop before the software goes out the door representing your professional work and code of ethics.

    Unit 8 Time Advisory   show close
    Unit 8 Learning Outcomes   show close
  • 8.1 Software Testing Terminologies  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 17: Testing and Quality Assurance”

      Link: The Global Text Project: Sue Conger’s The New Software EngineeringChapter 17: Testing and Quality Assurance” (PDF)
       
      Instructions: Read the section titled “Testing Terminology” in Chapter 17 (pages 690-694). In this unit, you have 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; subunit 8.2 will look more closely at test strategies (i.e., white-box, black-box, top-down, and bottom-up), and subunit 8.3 will examine more closely levels of testing (i.e., unit test, integration test, and system test). Take notes as you read.
       
      Reading this selection, taking notes, and taking time to comprehend notes should take approximately 1 hour.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 8.2 Software Testing Strategies  
  • 8.3 Software Test Coverage  
  • Unit 9: Project Management  

    Project management in a software engineering environment is unique because of the technical aspects of a software project. The project manager’s role is different from that of the software engineer’s. While software engineers are generally accountable for the technical aspects of a project, the project manager is accountable for organizational aspects.
     
    As you review the materials of the unit, try to connect this unit with what you have already learned about the software development life cycle. You will see that the success of an SDLC depends on people, process and product. Project management is the glue that holds these aspects together.

    Unit 9 Time Advisory   show close
    Unit 9 Learning Outcomes   show close
  • 9.1 Project Management  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 3: Project Management”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 3: Project Management” (PDF)
       
      Instructions: Read “Chapter 3: Project Management” (pages 57-82). As discussed, 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 section titled “Liaison” (pages 67-70) discusses the project manager’s role as a go-between for the technical team and agents who are not members of the technical team (e.g. project sponsor, user, IS management, vendors, etc.) In the section titled “Personnel Management,” (pages 70-74) you will learn that this job entails working with personnel (i.e., human resources) to hire, fire, and provide employees with professional development. The section titled “Monitor and Control” (pages 74-79) explains that project monitoring involves tracking project progress relative to budget. Project control means implementing changes when progress is not satisfactory (e.g. training, revising project plans, etc.). Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 4 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 9.2 Change Management  
    • Reading: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 18: Change Management”

      Link: The Global Text Project: Sue Conger’s The New Software Engineering: “Chapter 18: Change Management” (PDF)
       
      Instructions: Read “Chapter 18: Change Management” (pages 735-764). 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 to maintenance. The guiding principles, techniques, and tools for change management are discussed in this chapter. Take your time in reading and jot down any ideas or notes that stand out to you as particularly useful (or, conversely, confusing).
       
      Reading this selection, taking notes, and taking time to comprehend should take approximately 4 hours.
       
      Terms of Use: This resource is available under a Creative Commons Attribution 3.0 Unported License. It is attributed to Sue Conger and The Global Text Project, and it may be found in its original form here.

  • 9.2.1 Designing for Maintenance  

    Note: This topic is covered in the reading under subunit 9.2. Please focus on the section titled “Designing for Maintenance” on pages 735-741 of the reading. Applications that are designed with change in mind (i.e., flexibility) are easier and less costly to maintain.

  • 9.2.2 Application Change Management  

    Note: This topic is covered in the reading under subunit 9.2. Please focus on the section titled “Application Change Management” on pages 741-749 of the reading. Applications frequently change because of changing business or technical environments. By establishing application change management procedures, the changes may be tracked, reviewed, and prioritized.

  • 9.2.3 Software Management  

    Note: This topic is covered in the reading under subunit 9.2. Please focus on the section titled “Software Management” on pages 749-751 of the reading. A core concept in software management is to decide whether to maintain or to retire the application. When an application no longer works or when maintenance cost is high, the application becomes a potential candidate for retiring.

  • 9.2.4 Configuration Management  

    Note: This topic is covered in the reading under subunit 9.2. Please focus on the section titled “Configuration Management” on pages 751-756 of the reading. Configuration management is the identification, organization, and control of software changes. Software changes are developed over a fixed version of working code (baseline code). This is released and becomes the new baseline for the next set of software changes.

  • 9.2.5 Automated Tools  

    Note: This topic is covered in the reading under subunit 9.2. Please focus on the section titled “Automated Tools for Change Management” on pages 756-759 of the reading. A variety of automated tools exist that can facilitate and increase productivity for change management. These include collaborative work tools, documentation tools, reverse engineering tools, and configuration management tools.

  • 9.3 Unit 9 Assessment  
  • Unit 10: Putting It Together: A Case Study  

    This unit pulls together the object-oriented methodology in software requirements analysis (i.e. Unit 5) and software design (i.e. Unit 6). You will apply UML to demonstrate your understanding of the software development life cycle given a set of user requirements. You will also have the opportunity to apply software testing to assess the quality of your work.

    Unit 10 Time Advisory   show close
    Unit 10 Learning Outcomes   show close
  • 10.1 Preparation  
  • 10.2 Design Modification and Quality Control  
  • Final Exam  

« Previous Unit Next Unit » Back to Top