Software Engineering Wikiclass | Lecture / Course Revisions

A Software Engineering Lecture by Steven Choy

Lecture Overview: What you have studied in Software Engineering, Overview on Course Contents and Examination

Overview on Course Contents and Examination

Final Examination

May 5, 2009, 09:30-12:30
3-hours, closed-book, written examination

     3 hours, 100 marks
     180 minutes, 100 marks
     1.8 minutes per mark
     ~30 minutes to do one long question
     ~7 minutes to do one short question

Part A - Answer 8 compulsory questions, amount to 40 marks
Part B - Answer 3 out of 4 optional questions, amount to 60 marks
Do not bring calculator and dictionary
No explicit Java programming questions

Revisions Materials

Lecture Notes: Lecture#1 to Lecture#18
Textbook: All except Chapters 9 and 12.
Tutorial materials - Practical and programming works are less important

Scope of Examination

Software Requirements (At least one long question)
- Lectures 5-6 + Chapters 4-5
Software Design (At least one long question)
- Lectures 7, 8, 9, 10 + Chapters 6, 7, 8
Implementation and Testing (At least one long question)
- Lectures 12, 13, 14 + Chapters 10, 11
Configuration and Project Management (At least one long question)
- Lectures 15, 16 + Chapters 3, 13, 14
Modeling with UML
Software Engineering Activities and Processes
Software Engineering Life Cycle
Software Engineering Methodologies
- Lectures 2, 3, 4, 17, 18, 19 + Chapters 1, 2, 15, 16

Revision on major topics

Requirement Elicitation (Chapter 4)

Types of requirements: functional, nonfunctional, constraints
Nonfunctional requirements: concepts, categorization (e.g. FURPS+ model), and examples
Requirement criteria: correctness, completeness, consistency, realism, traceability, verifiability
Greenfield engineering, re-engineering, and interface engineering
Requirement elicitation activities: what are they?
- Identifying functional requirements
- Identifying non-functional requirements
- Identifying actors
- Identifying scenarios
- Identifying use cases
- Refining use cases
- Identifying relationships among use cases

Requirement Analysis (Chapter 5)

Functional modeling with use case diagrams
- relationships between two use cases: include and extend
Benefits and function of use case modeling
Static modeling with class diagrams
Dynamic modeling with sequence diagrams
Dynamic modeling with statechart diagrams
Object types: entity, boundary, and control
Requirement analysis activities
Difference between elicitation and analysis

System Design Part 1 (Chapter 6)

Decomposing the system

Coupling and cohesion
Benefits of low coupling and high cohesion
Layers and partitions, open and closed architecture
Software architectural styles
- Repository, Model-View-Controller, Client-Server, 3-tire, 4-tier, Pipe and filter
Benefits of using software architectural style in general
Benefits of each architectural style

System Design Part 2 (Chapter 7)

Addressing Design Goals

System design activities

There are a number of activities that are needed to ensure that subsystem decomposition address all the nonfunctional requirements and can account for any constraints during the implementation phase. What are these activities?

What does it mean by boundary conditions?

System Design Part 3 (Chapter 8)

Reusing Pattern Solutions

Application-domain objects and solution-domain objects
The Liskov Substitution Principles
Delegation and inheritance in design patterns
Software Design Patterns

Three main categories: creational, structural, behavorial

Particular design patterns: Bridge pattern, Adapter pattern, Strategy pattern, Abstract Factory pattern, Command pattern, Composite pattern, The Observer Pattern

Their concepts, diagrams, and applicability

Abstract Factory Design Pattern
Strategy Design Pattern
Bridge Design Pattern

Mapping models to code (Chapter 10)

Model transformation
Forward engineering
Reverse engineering
- (Be clear about reverse engineering and re-engineering)
Refactoring
Simple ideas and practice of refactoring
Design by Contract or Programming by Contract

Testing (Chapter 11)

Difference between verification and validation
Types of testing:
- unit test, integration test, system test:
Types of system testing:
- Functional test, performance test, acceptance test, installation test
What is regression testing?
Black-box testing vs. white-box testing
Integration testing strategy
- Bottom up integration, top-down integration
- Pros and cons of different approaches
Functions of test driver and test stub

Software Configuration Management (Chapter 13)

What is the purpose of SCM?
SCM activities (concepts only):
- Configuration item identification
- Promotion management
- Release management
- Change management
- Branch management
- Variant management
Persons and roles in SCM
- Configuration manager, change control board, developer, auditor
Concepts and terminology
- What are configuration item, baseline, SCM directories, version, revision, and release
Difference between version, revision, release, and branches
Difference between promotion and release
Examples of configuration items
Can you draw class diagram to model various concepts of SCM?
- Promotion, Release, Master Directory, Repository, Version, Configuration Item, and CM Aggregate

Project Management (Chapter 14)

Project management concepts
Can you draw diagram to model various concepts of software project
- work, task, activity, project function, work product, project deliverable, internal work product, set of work products, outcome
Project management activities
- Planning - Specify what to be achieved and work out a plan; Plan for schedule, resources including manpower and budget
- Organizing - Organize your project team in terms of role and responsibilities
- Controlling - Monitor the progress and ensure everything is on track
- Terminating
Elements of a software project management plan

    1. Introduction
    2. Project organization
    3. Managerial process
    3.3 Risk management
    3.4 Monitoring and controlling mechanism
    4. Technical process
    5. Work elements, schedule, and budget

What are work package, work product, project baseline, and project deliverable?
Scheduling
- Activity network diagrams and critical path determination
- What are critical path, non-critical path, and slack time?
Project Organization
- Functional organization
- Project-based organization
- Matrix organization
- Advantages and disadvantages of each type
- When to use which

Software Life Cycle (Chapter 15)

Basic Concepts of CMM
- The importance of CMM, how CMM is used in practice
- The Five Maturity Levels
Sequential activity-centered models
- Pros and cons
Unified software development process
- RUP characteristics - Iterative, use-case driven, architecture driven
- RUP phases - Inception, Elaboration, Construction, Transition

Software Methodologies (Chapter 16)

Main features, principles and best practices of Rational Unified Process (RUP)
The four phases of RUP
Core values, principles and best practices of XP
Agile Software Methodologies
- Principles behind Agile Methodologies
- Core values of Agile development:

Modeling with UML (Chapter 2)

UML diagrams

Use case diagrams
Class diagrams
Sequence diagrams
Statechart diagrams
Activity diagrams
Functions of these diagrams
- Static models
- Dynamic models
You should know how to draw these diagrams based on a given problem or description

Important Documents in Software Development

Requirements Analysis Document (RAD) - (P.151 and P. 199 of the Textbook)
System Design Document (SDD) - (p. 282 of the textbook)
Object Design Document (ODD) - (p. 373 of the textbook)
Test Plan, Test Case Specifications - (p.474 of the textbook)
Software Configuration Management Plans (SCMP) - (p.561 of the textbook)
Software Project Management Plan - (p.586 of the textbook)

What are the benefits of using software architectural style?

The use of an appropriately chosen architectural style furnishes a system with the desirable characteristics to meet the system design goals.
The allocation of classes to subsystems will be simpler.
The naming of specific architectural styles enhances the communication of the project team because the technically oriented team members will immediately understand the design.

What are the benefits and uses of Use Case Diagrams?

Use case diagrams are helpful in three areas.

determining features (requirements) - New use cases often generate new requirements as the system is analyzed and the design takes shape.
communicating with clients - Their notational simplicity makes use case diagrams a good way for developers to communicate with clients.
generating test cases - The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

Refer to the textbook and lecture notes whenever you are not familiar with topics discussed in this revision lecture.
Well plan your time to do revision and examination preparation.

Thanks for Reading

If you would rather like to have this lecture note in printed format, please click the print action link in the top right corner.

If you find any problem in this lecture note, please feel free to tell Steven by steven@findaway.hk

Course Revisions