payroll system development duration

[bash2death]

---

the first three features that you have already done were the basic foundation of the payroll system...leaving it in its current state is already functional.

ang kad2ng other features na close jud 2 xa pag sugud lang daan sa RD?? i mean DAPAT ba jud naa xa??

kanang biometrics ug online bai kay, provided nga ang usa kay mu duk2 sa biometrics unya ang usa kay mu duk2 sa online in parallel, tan-aw nko mga 14-21 man days guro bai...dala nana learning sa biometrics, testing and bug fixing unya slack time in case naay mu absent or mawala ana nga time period...=__=

[boypahak]

MarkCuering: yes, online attendance is quite easy to implement, we thought of using google maps to locate an employee's location but as of now we have no idea how we could integrate it into our system

-_-: after sa defense ang deployment, wala na mi labot sa maintenance, pero incase naa mga kulang sa system siguro they will contact us if naa sila ipa change. pero most probably ihatag namo ang code para sila na lng mag edit kung naa sila gusto nga changes. basically two computers ang gamiton ani, one for employees na mag time-in ug time-out and one for the payroll master for the payroll processing. we don't have a strong grasp of networking but naa ko amigo sa company na NA so this is no problem.

cebugdev: hehe, actually testing like data entry, for example fill out an employee's DTR for 1 month. ga test man pud mi while ga code. tomorrow will be our schedule for testing sa client and i think daghan changes ipahimo ani. first testing pa ni

bash2death: yeah, it already has its basic functionalities so it's a working system. katong mga features dapat naa xa kai mao may expected sa client. katong requirements definition namo naa ang mga accountant sa company mao to gipangsulti nila tanan ilang gusto. nag yes rapud mi. lesson learned gihapon ni para sa amoa nga dapat kabalo pud mi mu dili sa mga ginapang demand sa mga client. kai dili tungod ga computer ta mahimo na nato tanan. ang nahitabo aning system namo karon is nahimo syang HR(lates, absences, leaves), DTR, and payroll system. so makaingon ko nga big project sya. regarding sa biometrics, gi assign nako ni sya sa isa ka member, lol, wala man nakuha. dili pud ko ma ka take over kai ga assist ko sa head programmer kung unsay dagan sa system. mao siguro na short mi sa time.

guys pasingit ko, patabang ko gamay.

naa mi table for DTR. here are the fields

ID - to uniquely identify each row
EMPLOYEE ID - foreign key, to specify that these row belongs to a certain employee
DATE
TIME IN
TIME OUT
UNDERTIME - para ni sa deductions kung pila iyang undertime

in 1 month naay 24(or depende kung pila ka working days kana nga month) ka entries ang isa ka employee. kana sya if wala syay absent. kung absent sya then wala syay record sa database kai dili man sya maka time-in ug maka time-out. unsaon namo pag determine if naa syay absent?

[-_-]

not sure if effective ni ako suggestion, you could try na mag set ug schedule when mo ingon ang system na ang usa ka employee absent, say inig ka 12pm, if OL 24/7 na inyo machine then scheduled task nya na mag mark sa katong wala ni log until that time as "absent", suggestion lang nako ni dili ko sure sa intricacies and if ang inyo machine 24/7 ga andar

[personalmgt]

I think ang major sayop diri nga thread is the word "planning".

When you say planning, that means agreed na ang tanan, nothing will change bla bla bla.

I've been into a lot of development and I dread the word planning. Because everytime I hear it, I think of your client nagging you about "change this, change that, I don't want that". Labi na if walay kasulatan or contract na that's final.

If you're writing this Payroll system from scratch (no existing system, whether computerized or not), prepare for that nagging.

If you're writing it from a framework, then you're onto a good start! Remember to document at least with comments lang!

If not, just remember to comment your lines.

I'm saying this because on that situation, you have to be really flexible. If the project doesn't get finished before your OJT ends, then at least you have a good amount of comments/documentation for the succeeding analysts and programmers to work on.

I've had clients like this and the only thing I wanted to do is to punch them in the face or screw them over. But seriously, no project takes a lot of time basta programmer magbuot. It's the client that screws you, a lot. This comic should give you more insight about it: How a Web Design Goes Straight to Hell - The Oatmeal

[Andruid80]

not sure if effective ni ako suggestion, you could try na mag set ug schedule when mo ingon ang system na ang usa ka employee absent, say inig ka 12pm, if OL 24/7 na inyo machine then scheduled task nya na mag mark sa katong wala ni log until that time as "absent", suggestion lang nako ni dili ko sure sa intricacies and if ang inyo machine 24/7 ga andar

yes, buhat ka ug schedule job para mo check sa logs sa mga tawo. if ang employee absent on that day i flag nimo as absent or simple remarks "NO LOG". with that, mka identify naka if ang employee naay logs or wala. Btw, you need to consider also the leave filed by the employee. didto nana daugon nimo sa scripts..

botyok, i deploy nana oi..

[-_-]

I think ang major sayop diri nga thread is the word "planning".

When you say planning, that means agreed na ang tanan, nothing will change bla bla bla.

I've been into a lot of development and I dread the word planning. Because everytime I hear it, I think of your client nagging you about "change this, change that, I don't want that". Labi na if walay kasulatan or contract na that's final.

If you're writing this Payroll system from scratch (no existing system, whether computerized or not), prepare for that nagging.

If you're writing it from a framework, then you're onto a good start! Remember to document at least with comments lang!

If not, just remember to comment your lines.

I'm saying this because on that situation, you have to be really flexible. If the project doesn't get finished before your OJT ends, then at least you have a good amount of comments/documentation for the succeeding analysts and programmers to work on.

I've had clients like this and the only thing I wanted to do is to punch them in the face or screw them over. But seriously, no project takes a lot of time basta programmer magbuot. It's the client that screws you, a lot. This comic should give you more insight about it: How a Web Design Goes Straight to Hell - The Oatmeal

heheh kahinomdom nuon ko sa ako softeng na class tungod ani. Baseline jud, nya dapat document tanan requirements dayon, hmm kung naay mga functionalities na dili kaya be honest and transparent na dili kaya and negotiate about it, dili lang puro tando, at least ma set ang scope and realistic sya

[MarkCuering]

I think ang major sayop diri nga thread is the word "planning".

When you say planning, that means agreed na ang tanan, nothing will change bla bla bla.

I've been into a lot of development and I dread the word planning. Because everytime I hear it, I think of your client nagging you about "change this, change that, I don't want that". Labi na if walay kasulatan or contract na that's final.

If you're writing this Payroll system from scratch (no existing system, whether computerized or not), prepare for that nagging.

If you're writing it from a framework, then you're onto a good start! Remember to document at least with comments lang!

If not, just remember to comment your lines.

I'm saying this because on that situation, you have to be really flexible. If the project doesn't get finished before your OJT ends, then at least you have a good amount of comments/documentation for the succeeding analysts and programmers to work on.

I've had clients like this and the only thing I wanted to do is to punch them in the face or screw them over. But seriously, no project takes a lot of time basta programmer magbuot. It's the client that screws you, a lot. This comic should give you more insight about it: How a Web Design Goes Straight to Hell - The Oatmeal

just sharing lang, during we received the project technical specification, we plan base on that, if there are any changes we charge it as VO "variation order".

cguro ibat iba ang paraan ng mga company, Im involve also in planning and yes no projects was done base on the original plan, there's always around 10 or 20 major revision and 100 minor revisions.


just sharing lang, at the moment we received the project's technical specification, we plan base on that, if there are any changes we charge it as VO "variation order".

cguro ibat iba ang paraan ng mga company, Im involve also in planning and yes no projects was ever completed base on the original plan, there's always around 10 or 20 major revision and perhaps around 100 minor revisions. ang iba pa-bunos nlng sa owner.

so everytime a plan has change, its an opportunity to get variation order it means that the future income will be higher than the original contract.

there are customers rin na medyo difficult to handle, feels that sometimes they're doing some sort of "delaying tactics" again, its pretty normal, and get used to it on how to handle.

[bash2death]

about sa imung query about sa DTR to know if naay absent or wala...kuwang ra kaau na nga table bai...what if ni file diay ug leave ang employee..or holiday diay ana nga time...and many more reasons....

complex au ang kani xa nga query if sa DTR lang ta magsalig...buggy na xa and i'm sure mag YAWYAW nang interested ana nga feature...

for now...ako pa nmu himui na lang ug Crystal Report or Excel Report(preferable) ang taga taga accounting (since sila man guro assigned mag ihap sa sweldo sa taw) unya ibutang did2 tanan DTR ani nga time period...kamu na diskarte unsaun na xa pag display...

nka experience pud ko ani nga problem before...aq na lang gi daug sa UI(C#) ang pag compute sa attendance...

naa pud ko comment bro, murag kulang pud na ang imu DTR nga table bai...instead of undertime nga column...naa pud unta ka expected time in and expected time out...dli man gud most of the time nga 8-5 ang sched sa usa ka taw...what if diay naa sila shifting...with this pwede nimu ma compute ang undertime or ovetime...mas scalable pa jud xa...hehehe ^_^

[jorjie]

Sakto ra na ang 1 month duration basta kahibalo lang ka sa flow of the system.

[sanggano_boy]

1 member only for testing? dba waste of resource ni cya? pwedi ra man each member mo perform ug unit testing or ang client nnyu ang mo perform sa testing.
if i assign ni cya ug something na makatabang sa nyung time then mas mopaspas guro mo oi..

Testers are not a waste of resource, lahi ra mo test ang programmer kaysa pro na tester, sometimes ang programmer ma overlook niya ang mga details and the biases will come specially on large projects,

so, if you want your system to be of good quality then have it tested by another person excluding the programmer who made it.

Programmers will always do the initial testing, and the testers will do the refine testing. Testing should be done by testers or the user of the program itself.


- Cebujobline.com Post unlimited Jobs for Free, apply online