These are some observations on independent work in CS, based on my experience over the past few years. Others will certainly have a different take on some of this, so your mileage may differ. The bottom line, however, is the same for everyone: independent work can be a great experience if you put some time and energy into it.
The first problem is finding a topic, so you should be thinking about this the semester before you plan to do IW. (Too late already? Sorry about that -- best get started now.)
If you have a great idea -- something that seems sensible and turns you on -- start talking to faculty members who might be willing to be your advisor. Begin with people who are in the right technical area, since you're most likely to strike a chord there, but talk to others as well -- they may have hidden interests, or they might be interested in branching out, or there might be better personal chemistry, or your first choice might simply be too busy.
Even if you've got an idea that really appeals to you, it might be too big or too small for a semester or a year. Advisors and others can help you adjust the problem to the right size. Many initial ideas are way too big -- if you intend to take on something that thousands have worked on for decades, you probably won't knock it off in a semester as a junior. Lots of problems in AI -- natural language processing, translation, etc. -- are like this, and trying to resolve P=NP might be over-reaching as well. So part of the job is to find a manageable piece of the problem, something about right for a semester or a year.
Sometimes the proposed problem is too small, more like a week of effort than a semester. Here your advisor may be able to help you beef up the idea into something that's an appropriate amount of work. Maybe there's some generalization of your idea, or several related cases that add up.
On the other hand, if you have no clue at all about what to work on, it's time to get started. Think about some area where computers might be used better, or where a better program or tool or language or experimental result might be useful. Think about places where some aspect of computing irritates or frustrates you -- maybe you could do it better. Look at what other students have done in the past few years; again, "I could do that better" is often a good place to start. Think about an area or a language or a tool or a system that you want to learn more about and how to parlay that learning experience into something interesting.
After you've done some homework, you can visit likely advisors more profitably. Most faculty have at least a few ideas that they think might make good projects, or they have ongoing research projects that could use some help. Sometimes talking with a student who has been thinking about potential topics will suggest something to them. But don't just walk into faculty offices hoping for someone to hand you the perfect problem. This is supposed to be your independent work; trying to figure out what to do is a good place to start being independent.
How original does independent work have to be? There's no single answer, and different advisors will have somewhat different notions, so this is a personal opinion. There should be something about what you do that's new, but it's not that the whole thing has to be brand new. Maybe you do a different version of something that's already been done, or you find a different approach, or you experiment with an new combination of things that already exist, or you do a special case that hasn't been looked at carefully, or you revisit something done long ago but attack with modern systems and tools.
Once you've got at least a reasonable notion of what to work on, it's time to think about breaking it into pieces. The ideal is to have a sequence of intended results, such that you could stop at any time and declare success. You don't want to have a project where nothing works until it all works, where everything has to come together at once to make it work at all. You should also avoid projects that require exotic equipment or that depend on other people to do their bit (like filling out surveys, testing your code, etc.).
Now you can sketch out a more detailed plan of what you'll do each couple of weeks throughout the semester. This isn't cast in concrete; it's guaranteed to change as you run into problems, find interesting new things to pursue, and so on.
As you plan, don't forget the various deliverables. You have to give a talk early on; having thought hard about what you intend to do makes your talk this one more believable. You have to give another talk near the end; thinking about what the dozen slides of that talk would look like will help you organize, and give you specific things to work towards. Finally, you have to write a paper describing what you did. Again, figuring out the general shape will provide a target. Be sure to include some time for these in your schedule, and for the inevitable setbacks, other courses, sickness, and having a life.
During the semester you should check in with your advisor pretty frequently, to keep him or her abreast of progress (or aware that you haven't made any). Preparing a weekly or bi-weekly note that says what you did, where you are, and what you intend for the next period is a useful prod; it also helps to answer the advisor's question of whether you're doing anything at all. You should do drafts of talks and the final paper ahead of time; you can get feedback from your advisor and others, and gain some confidence for when the real thing is due.
As it is for one-semester projects, it's even more so for a senior thesis, because you're expected to do something more substantial and you're working on it for twice as long. It's easy to procrastinate when the deadline seems infinitely far away. Don't blow the fall semester.