This is the (tentative) course schedule. While I call it tentative, we will have to stick to it, in terms of deliverables, since we have the end date of April 10th for the lab. At most a grace of a week can be given for any team which is unable to demo on April 10th. But, considering that Major exams will start in the week of April 16th, this is NOT advised.

LAB 1 - Jan. 3, 2012: Introduction and How to write Makefiles

 LAB 2 - Jan. 10, 2012: How to use gdb

There will be a demo of how to use gdb in the Seminar room at 2pm using the C program debug.c. Then, you will download the ordered doubly linked list program and debug it using gdb. You will first write the Makefile for this code. Then, for debugging, you will need to come up with test cases that you will test on this code, document them, try them out, fix the code and write a report at the end of the lab as to how you fixed the various bugs in the program.

Specification of the Doubly Linked List program:

The program takes two command line arguments: an input file which will contain the list of numbers to be added to the ordered list. The second argument contains the operations to be performed and the ID on which it is to be performed, one per line, i.e., the format of the second file will be as follows:

d 2

s 5

a 98

LAB 3 - Jan. 17, 2012: Work on the specification document of the respective project by each team. It will be good if you can follow the guidelines for the SRS document in the IEEE Templates link given below.

 LAB 4 - Jan. 24, 2012: Work on the design document of your project. At the end of this lab, you need to produce the high level architecture of your project. This involves identifying the modules, the interfaces between modules and the API specification.

At the end of this, you should also identify which team member is doing which module(s) and/or functionality. After this, the entire development and testing will be individual until Integration Testing starts.

You will present the design of the document using the format specified in the IEEE Templates from the UT Dallas Faculty link. I will give a further detailed template when it comes to the detailed design of the modules.

LAB 11 - Mar. 6/13, 2012: Unit Test Plan preparation has to be done. Some of the Techniques for Unit Testing may be understood to prepare the unit test plan. Please also refer to the IEEE templates that has a Software Test Document (STD) template.

IMPORTANT NOTE: Each Test case MUST be numbered uniquely. To achieve this across multiple developers, evolve a naming mechanism for your project such as having test case naming with the following format: where stands for the module code (such as IE for Index Engine, FT for Forwarding Table, AET for Active Edge Table and so on).

Each module owner has to develop the test plan. Code coverage is the percentage of lines of code of your software that are tested by your test cases. If every single line is executed as a result of a union of all your test cases, this is 100% code coverage. Typically, a large software never has 100% code coverage. But, proper design of unit and integration test cases leads to a good coverage for small projects.

Special Note to GUI developers: A GUI developer has to ensure that all the proper validations on user inputs are done. This is one of the most important design issues in GUI - remember that "TO ERR IS HUMAN" and to catch it is the duty of the software that interfaces with the human. Otherwise, the software will crash on unexpected inputs.