Object Oriented Software Syllabus
Periods/week : 3 Periods & 0 Tut /week. Ses. : 50 Exam : 50 Examination (Practical): 3hrs. Credits: 2
Each student group chooses its own platform, subject to approval by the instructor
1. They can design and implement complex software solutions using state of the art software engineering techniques.
2. The have working knowledge of UML, source control, and project management.
3. They have deep knowledge of the technologies they used for implementing their project.
4. They know how to test and document software.
5. They are capable of working as part of a software team and develop significant projects under a tight deadline.
6. They are able to present their work in a professional manner.
Topics to beCovered:
1. Software Engineering Process.
2. Unified Modeling Language (UML).
3. Data Structures and Specification.
4. Object-oriented design.
High. The students are free to chose a project based on the instructor’s approval.
1. Group meetings with faculty: initial proposal, code review, tracer-bullet implementation demo, final demo.
2. Design documents. Write-up.
3. Code documentation.
the students give their final presentations and demos.
Also, each project team meets individually with the instructor at least four times during the semester. The agenda for each of the four meeting is as follows:
1. Team presents project idea and has it approved by instructor. (first month)
2. design/code review. Instructor goes over design/code with the team to point out problems and formalize requirements. Instructor determines requirements for tracer-bullet implementation. (second month)
3. Tracer-bullet implementation demo. Team shows that it has achieved full vertical integration functionality. Instructor notices missed requirements and reminds students of requirements for final project.(beginning of third month).
Final meeting. Verify requirements, design, documentation, testing, write-up, division of labor, etc. (last month).
Sessional Marks Allotment: Monthly Meeting Participation: 10% Monthly Progress Reports: 15% Design/code Document: 15% Presentation: 10%
Prototype Demonstration: 10% Final Project Demonstration: 30% Final Project Report: 10%
General Software Engineering Tips:
Be careful when making major modifications and keep backups! A good motto: There is no such thing as a safe software change.
One of the biggest mistakes that even professional software teams make is modifying code at the last minute.
Either resist the urge to make last minute changes, or keep them isolated and well-marked so that they can be backed out easily if necessary.
Test, test, test!!! You must test your system thoroughly after making any change, no matter how small. Else you will not know if a bug was introduced! You will get no sympathy if you break your system at the last minute.
A good habit to get into: frequently run your program on an extensive test set.
Once you have a prototype, create a set of examples that your program handles correctly. Generate files of the input and the correct output as a test set.
When you make significant changes, run your program on the test set. If the output is different, then you will know that you’ve introduced a bug. (Or if the output is improved, you should update the test set.)
Put together an extensive regression set! If it alerts you to one major bug (and it always does), then it is time well spent.
After verifying that a new change is “safe”, save a version of your entire system! Never, EVER make changes to the saved version – it is a reliable version that you can recover in an emergency.
Get into the habit of documenting your code quickly as you go. If you think you’ll remember why you did something, you are probably wrong.
Computer scientists typically hate to do documentation. One reason is that they leave it all for the end!
Get into the habit of writing small comments as you go. A few comments, explaining what’s happening and why, can make a world of difference.
When you make a change, mark it with your initials, the date, a brief explanation, and an example. This will help enormously if the change needs to be removed or modified, and will prevent thrashing.
Working as a Team:
Be honest and realistic with your teammates when setting goals. If you fail to meet a promised deadline, it affects the whole team, not just you.
Communication is crucial! Don’t make major decisions by yourself, and let people know when you are behind or ahead of schedule.
Try to exploit each other’s strengths.