Week 15 (starting 21 Jan 2008) - Final Revision & Exam Prep

Lets’ recap the objectives of the module when we first started the lesson:

1. To introduce the concepts and best practices of software engineering
2. To be familiar with the process improvement model CMMI and software quality issues
3. To learn software modeling using UML and the discipline of requirement management

Upon completion of the module, you should

1. understand the concepts and best practices of software engineering
2. familiar with waterfall and Unified Process software development approaches
3. adopt Software Assurance and Control methods
4. apply software quality tools such as Pareto-chart and cause-effect diagram to analyze software problems and to suggest improvements
5. construct software models using Unified Modeling Language
6. perform requirement management and development using Object Oriented approach

In conclusion, we want you to learn how to accomplish your software development work within budget (resources and costs) and time and to meet customers’ expectations.

As for the exam preparation, pay attention to the followings:

1. Software processes – their importance in an Enterprising IT organization, i.e why are processes needed to develop software
2. Best Practices - know at least 2 best practices (and describe them in more details) for project planning, monitoring and control, requirement management. For example, if “Milestone driven approach” is a best practice for planning, explain why.
3. Unified Process (UP) development approach – what are the benefits to customers and what does Iterative and Incremental mean
4. UML – know how to create class diagram with the class names, attributes and use generalization relationship to link among them.
5. Project schedule – know how to interpret Gantt chart. For example, the task list, the duration and the milestones.
6. Use case modeling - know how to construct use case diagram. Will highlight common mistakes in Quiz#2 during practical this week
7. Use case analysis – know how to interpret Sequence Diagram and to identify the responsibilities of the analysis objects, the purpose for different types of analysis objects
8. Pareto chart – construct Pareto-chart and identify errors and suggest improvements. In the exam, you will use graph paper to construct the Pareto-chart.
9. Revise all questions in quiz #1 and #2, visit the blog and do the exercises if published there.

All the best to your coming exam and we shall meet again on 20 Feb 08 Wednesday 9am at the exam hall. Remember to bring your certified calculator.

Week 14 (starting 14 Jan 2008)

We have looked into use case analysis this week. This is to analyze the details of the use cases by :

1. Identifying the analysis objects - i.e. to identify the boundary, controller and entity objects.
2. Assigning the responsibilities to these objects - i.e. to derive from the use case description the tasks that each of the analysis objects need to do and assign to them these tasks

There are 3 types of analysis objects :

1. Boundary objects - these are usually the user interfaces (eg online forms, menu options..etc). The purpose of the boundary objects is to allow users to submit the requests for the sysetm to process.
2. Controller objects - these are the intelligent objects that contain the business processing logic. The purpose of the controller objects is to co-ordinate how to process the request submitted.
3. Entity objects - these are the objects that store information. The purpose of the entity objects is to provide information when processing the request.

When analyzing a use case, we will

1. use ONE boundary object to represent the user interfaces and interfaces to external system
2. use ONE controller object to co-ordinate the steps of processing the request
3. use AS MANY AS NEEDED entity objects to store the different types of information
4. use sequence diagram to present the details of the responsibilities assigned

Consider the Trigger download of Student and Module information use case from the Student Attendance System case study.

• The system administrator will submit the download request of student and module information from EIS. Once the information is downloaded, they will be stored respectively in the Student and Module objects.
• In this case, there are 2 boundary objects : one (DownloadForm) to submit the download request and the other (IEIS) is to interface to the external system EIS.

The sequence diagram for the analysis is shown below.

What are the responsibilities assigned to the DownloadForm object?

With this, we end all the topics to be covered in this module. Next week, we will do revision.

Week 13 (starting 7 Jan 2008)

Once the information is gathered from the customers about what they wanted of a software system, the requirements can be documented by:

• Constructing a use case diagram showing the use cases and the actors (human users and external system)
• Writing the use case description for each use case

The use case diagram will give you an overview of the software system to be developed. It indicates :

1. What are the functions to be provided (each one is represented by a use case)
2. Who are using the system (i.e. the actors)
3. Any external system to interface with

An example is shown below. It shows a Course Management System to be developed with 4 intended functions and the people using it are the students, the professors and the registrar. There is one existing system at the customer's office to interface with and that is Billing System.

The use case descriptions will give you step-by-step instructions of how each use case is being executed. The description will also indicate how these users interact with the system and eventually with the expected outcome.

A good use case description will give you an idea how a use case will be executed. It describes:

1. What inputs are needed
2. How the system will process the request
3. What is the expected outcome if the use case is executed successfully
4. What are 'exceptions' to handle (in the alternate flow)

An example is shown below to describe how to

Use Case Title : Register for Course Pre-condition: The student must log in successfully to the system before this use case begins. Post-condition : The student schedule is created upon successfully registering the course. Basic Flow:

1. The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student.
2. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings.
3. Once the student has made his/her selections, the system creates a schedule for the student containing the selected course offerings.
4. For each selected course offering on the schedule not already marked as “enrolled in”, the system verifies that the Student has the necessary prerequisites, that the course offering is open, and that there are no schedule conflicts.
5. The system then adds the Student to the selected course offering. The course offering is marked as “enrolled in” in the schedule.
6. The schedule is saved by the system.

Alternate Flow:

1a. Course Registration is closed. A message is displayed to inform the student that no registration is allowed and the use case terminates. 4a. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts A message is displayed to allow the student to re-select other course offering and submit the registration.

With all these, you will be able to document user requirements. Next week, we will look into use case analysis - i.e. to further understand what really needs to be done for the use case.

Week 12 (starting 31 Dec 2007)

Happy New Year and welcome back to school after the X'mas break. We are now going into the last topic of the module - Requirement Management and we will cover the following areas in this topic:

1. Best Practices of Requirement Management
2. Requirments Documentation in Use Case format
3. Requirements Analysis using Boundary, Control and Entity objects

In this blog, I will highlight the first part.

What are the best practices for Requirement Managment? We will focus the ones mentioned below.

1. Understand what requirements are - there are 2 types of requirements : Functional and Non-Functional. Functional requirements are specific functions to be performed by the system (i.e. the features to be provided) eg. Rent book, Return book, sign up as member in a Library Book Renting System. Non-functional requirements are requiements that describe the operational quality of the system, eg. how many users can borrow books online at the same time without affecting the system response time (this is related to system performance issue). We need to cover both types of requirements when we build a software system.
2. Gather the requirements using appropriate techniques - we can prepare questions and interview the customers, observe how the customer works in their operatioal environment or conduct survey to find out what the customers want. We may need to combine a few of these techniques to come out with the complete requirements.
3. Evlaute the requirements to confirm its accuracy - dont assume what you have gathered from the customers are correct. Always have review meeting with the customers to find out any mis-understanding or mistakes before you baseline the requirements for subsequent implementation.
4. Handle changes to requirements properly - we can properly handle the changes by following the steps indicated in the change request workflow as shown below.

Next week, we will go into the documentation of the requirments using the use case approach.