| I think,the project tasks should split into two parts in

 | order to explicitly who is doing what(that is the most important problem

 | of a couple worker).And it should be equal working for each task.



Part of what this project should be about teaching you is how to manage

working in a team, rather than working as individuals.   But, yes, to get

things done, you need to divide up the work - you can't both do everything,

that would be insane, nor can one person do everything, that's not the

way things are supposed to work.



But you need to (or should) divide it up amongst yourselves - rather than

having me assign tasks to you, that way you get to see some of the

extra work involved in a non-trivial project.



Nothing you do is ever going to be "equal" - there's no way to make that

happen - apart from anything else, different people do the same task with

different degrees of difficulty (it is harder for some people than others).

That is, if the job gets split into two pieces, that look equally

difficult, or to require equal amounts of work, one person might get

something to do that turns out to be easy for them, while the other

"equal" task is very difficult for the other one.   Or, if things get

split so that each does equal amounts of actual work, the result might

end up appearing that 90% of the work was done by one, and only 10% by

the other (because the first found the 90% to all be quite easy, and the

other found the 10% to be difficult).



How to split things and be reasonable depends upon the group - some people

simply prefer to take it in turns to work on the code, each making

improvements to what the other left, adding more, and fixing bugs, then

leaving it for the other to work on next.



Others prefer to each work on their own defined piece, independently.



Each of those has advantages and disadvantages.



As a breakdown ...



 | 1. The capture program and filter engine

 | 2. The collect program and report gen.



That isn't exactly what I would recommend - first, because (2) is

likely to be quite a bit less work than (1), but also because (2)

can't really do all that much useful until (1) has done a lot (there

has to be at least a definition of what is available to be collected,

and the format it can be obtained, before it makes any sense to think

about how to collect it, or how to put it in files).



If you want to split things, I'd suggest more along the lines of

initially concentrating on just (1) above, with one person handling

the input language, and generation of the internal form of the

specification, and the other taking that and capturing and counting packets,

and then making that available over the net.



That division is likely to be more equal, and while to be useful the

first of those sub-parts needs to generate code for the 2nd to use to

decide what packets to capture, the 2nd part can capture based upon

a hand generated specification to start.



 | I'm not sure.Is this suitable,if the project is forked into 2 parts like

 | this.So what do you think about this idea?



It shouldn't become two projects - if two separate projects was the goal,

then that was what would have been created at the start - working as a team

(with the extra difficulties and challenges that causes) is part of all

of this - not just producing some code.    Once you get outside the

university and start working somewhere, yo'll find that almost everywhere has

teams to do the work, not individuals.



If you're having any problems working as a team, you should talk to me

about them - or perhaps to make it easier for you, talk to one of the

co-advisors (so you can talk in Thai).   It is important that any problems

get fixed as early as possible.