Data type refactoring

We have been able to make all the changes required by our client. To have this possible, we make some slight changes to the classes.

We also decided to change the data types of “year” and “month” from the “clsPayroll” class because its easier to sort and search (for the year-to-date calculations especially). We’ll upload another demo video soon…

Team meeting to discuss changes

We met this evening to go over how to best implement the changes required by our client without re-coding or having to change major parts of the software. And we were able to find a solution for the 2 main changes of making the hourly rate for the employees dependant on the employee, and also for making the payroll editable.

Unique hourlyRate

Firstly, we decided that creating an “hourlyRate” field in the “clsEmployee” class would do the job, and we could save this hourlyRate (per employee) to the clsRate object (that is aggregate of clsPayroll) field of the same name.

i.e., clsRate.hourlyRate = clsEmployee.hourlyRate

In this way, we only have to assign the hourlyRate value from clsEmployee while saving a payroll instead of clsRate. And the other claculations follow the same!

BEFORE

NOW

editPayroll

We will add a new method to the clsEmployee class, editEmployee(), so that if the month and year of a new payroll being added match, the user will be prompted to overwrite.

So basically, the structural changes come to only the clsEmployee class.

Renaming

We will change all captions on the windows, or in the VB project names to reflect the new name our client decided.

Year-to-date totals

We have to make an algorithm for this, and we also decided to clean up the code that calculates the yearly totals on the ledger class, and perhaps integrate it into the classes instead of having it as a GUI code. This will be the major work.

“The princess needs a new name!”

In the movie, “The Never-ending story”, the fantasy land of Fantasia was slowly disappearing… the problem was the princess of Fantasia needed a new name!

Similarly, our client wants “Piccolo” to get a new name… ” Payroll System”, so its done because we want to save our Fantasia too!

Towards the Release candidate!

The four of us met with Dr. Odinma yesterday around 2:30PM to 3:30PM, and showed him our Test version. He has told us to make 3 changes:

• Make payrolls overwritable
• Employees should each have their own hourly pay rates
• Year-to-date total (total salary, deductions, etc from beginning of year to current month on payslip) should show up on the payslip

We are now going to spend till the next week, Monday, and then hopefully get the RC done.

“Meet the Client”

The four of us met today and have planned to meet our client tomorrow at 2PM to showcase the Test version. Testing still continues, but we will integrate any errors corrected along with any modification the client wants together into the RC version.

Demo Video

Here’s a demo of the test version. The next version is the RC, hopefully coming out by Wednesday…

Test version out!

Yes! We have finished the test version. Malachay and Hamman had met on Friday to do the preliminary testing, and the errors were fixed during the week. All of our pre-project objectives have finally been met, and we have some pretty good features integrated into the software…

• Web-enabled : This was originally an “after-thought” feature we were planning on if there was enough time. Because we are using XML as our backend, we can generate HTML files out of them by using appropriate XSL stylesheets. We were finally able to implement this using the xslTransform class provided in VB
• Auto-calculations : All the necessary calculations on salaries are done automatically
• Graceful degradation : We have paid attention to error handling a lot, and we even have a crash log implemented so that whenever “background” errors happen, the user isn’t bothered by them, but at the same time, we can get details about them.
• Easy modifications : We have always had flexibility in mind while designing the objects and code, so that we could make any changes the client wants ASAP. As an example of this, we had discovered a slight flaw in the code logic that would wrongly re-calculate salaries if an employee became a union member or opted for a pension plan at a later time after being added. But we did not have to change the object design at all, just the code implementation of the objects and we were done!
• Printable reports : Payslips can be previewed and printed out. This was possible after we made use of the Printer control in VB
• User story : And more importantly, all the features required by the user story are in! We meet our client in this week to get a “go-ahead”

New timeline, again :(

Well, after so many delays and changes to the timeline, we finally settled on this one. It seems attainable and sustainable too, because right now we are on schedule!

The main refactoring was to eliminate so many versions prior to the release candidate. Now we complete an initial “test” version and build on it to make the RC version and so on.

Lacing the code

The code is really all done, so we can now add exception handlers. We were avoiding this so that the code doesn’t get distorted with additional lines.

As we move into blank-box testing today, its important from the user’s point of view that they don’t get an unhandled exception error. From the developer’s point of view, we also need to track any errors that might occur and crash the application, so we will also be adding code for saving all errors to a log file.

We have also refined the code by making use of the With…End With statement in VB, which allows us to reference properties and methods of objects within the block without writing the whole object name again and again…

BEFORE

employeeData.employees(cboEmployee.SelectedIndex).name = newName

employeeData.employees(cboEmployee.SelectedIndex).unionMember= False

AFTER

With employeeData.employees(cboEmployee.SelectedIndex)

.name = newName

.unionMember= False

End With

Clearly the use of With…End With makes the code easier to read! Imagine referencing a property of a payroll object from an array of payrolls aggregated in an array of employees!

Adieu to addRate() and findRate()

When we began the actual GUI coding dealing with objects from the clsPayroll class, we realized that in the current user story, we don’t have any situation where we would need to find previous rates. Also, we found it more efficient to pass a new object to the “rate” property of clsPayroll objects instead of calling the addRate() method. So we are removing these two methods from our design.