Automated Software Engineering Research Group @NCSU

Papers accepted at ESEC/FSE 07 and ICSM 07

Mithun has a paper accepted at ESEC/FSE 2007 (17%), a top 1 conference in software engineering (together with ICSE).

My Peking University colleagues have a paper accepted at : ICSM 2007 (21%), a highly reputed conference in software maintenance.

Congratulations on their achievements!

Posted at 02:39PM Jun 03, 2007 by XIE, TAO in Submission Madness  |  Comments[0]

One pitfall in writing the related work section

In the related work section or elsewhere in a paper, many people tend to compare the proposed approach with the existing approaches in a shallow way, making the justification weak.

For example, your approach may be a static analysis approach and when you compare with previous dynamic analysis approaches, it is bad for you just say "Our approach based on static analysis are different from the existing approaches because they are based on dynamic analysis." It is not enough. You should describe what observable inputs/outputs (benefits) that the internal technical differences in your approach could bring. Here, it is better to say "Our approach based on static analysis are different from the existing dynamic analysis approaches because they require runtime setup and good sets of test suites, which are not required by our approach." You can see that the difference is on the observable inputs.

When you compare your dynamic analysis approach with existing static analysis approaches. You can focus on the difference of the observable outputs. You may say "... because our approach uses precise runtime information, reducing false positives that are produced by existing static
analysis approaches."

This issue has been raised in reviews for one of our past submissions.

"you omit effectiveness rates of a lot of tools in favor of "ours technically works differently on the inside". That is not quite good enough;
the comparison should be on result, not just on "we are technically different"."

You should go through your related work section to see whether you described the differences in observable results/benefits outside beyond just
describing technical differences inside.

Posted at 02:32PM Jun 03, 2007 by XIE, TAO in Technical Writing  |  Comments[0]

The year-end picnic (Pig Pickin')

Dr. Tao Xie, Mithun, Yoonki, and JeeHyun joined the 'Pig Pickin' picnic as of 04-27-2007.
We had great food and enjoyed meeting with other students. The followings are the picture of us !!
pic 1
pic 2

Posted at 11:33AM Apr 30, 2007 by HWANG, JEEHYUN in General  |  Comments[0]

Answers to Global Educator Magazine, Student Section

The Global Educator magzine addresses students of science and engineering. The focus of the magazine is to provide information to students about educational institutions (specifically focusing on engineering and technology) in India and overseas, inform them about developing opportunities in engineering, offer practical tips on how to manage education abroad, carry interviews and profiles of achievers in the field of science, technology, engineering and business as role models.

Below are the answers to the interview questions posed by the Global Educator to me. They will be published in a future issue of the magzine.

1. Could you tell us about your career so far?

I am currently a PhD candidate in the Department of Computer Science at North Carolina State University, Raleigh, North Carolina. I completed my Master of Science degree from the same university in 2003, and Bachelor of Engineering degree from National Institute of Technology - Karnataka (previously KREC), Surathkal, India, in 2001, all in Computer Science. During my graduate studies, I have interned at NEC Europe Network Laboratories, Heidelberg, Germany and IBM T J Watson Research Center, New York. In 2007 summer, I will intern at Microsoft Center for Software Excellence, Seattle.  

2. How did Software Engineering interest you?

I like exploring research ideas that have immediate practical applications; innovations that create impact and are adopted by a very large community. Specifically, my interests in Software Engineering lie in the area of Automated Software Testing and Verification. It is indeed a very satisfying experience to come up with research methodologies that ultimately improve the developer productivity in the software industry. I was introduced to this fascinating world of Software Engineering through the Automated Software Engineering research group (http://ase.csc.ncsu.edu/) led by my advisor Dr. Tao Xie, of which I am currently a part of.

In simple words, my doctoral research focuses on developing efficient techniques to automatically find bugs in software programs. Bugs can have serious implications ? illegal access to a personal computer, failure of a life-saving medical device managed by software, complete network shut down of a large organization, to name a few. Bugs are mainly caused when programmers fail to adhere to certain application-specific, non-syntactic rules in the code that they write. These rules, when documented and available, can be checked against a given program using sophisticated software verification tools such as model-checkers. So far, my doctoral thesis focuses on addressing two problems. (a) Writing rules formally for software verification is hard and error-prone (b) Application-specific rules may not be documented, hence being unavailable. I have proposed and implemented a framework that makes specifying rules for software verification easy. Furthermore, I apply data mining techniques to automatically extract such rules directly from program source code or program execution runs. These rules can then be used to find bugs.

 4. Through your doctoral thesis what would you contribute to the software engineering field?

 The research methodologies that I develop will aid developers in the software industry to adopt sophisticated software verification techniques in their coding cycle effectively, with minimum efforts. Software verification techniques such as model checking can assure total absence of certain classes of bugs. However, developers need to specify property rules formally in order to apply verification tools. Most developers find this specification task a hindrance to their coding efforts as specifying rules formally requires knowledge of the rules themselves (which might not be documented and available) and the formal rule language. Furthermore, specifying rules also requires the knowledge of the internal details of the components used in the software and their source code details. The techniques that I develop in my thesis partly automate the process of finding rules and specifying them for the verification tools. This research result ultimately leads to higher confidence in the software being developed and better quality assurance standards.

5. How has your experience been studying and conducting research in US university?

 Excellent! North Carolina State University has an excellent Computer Science program for students. Students are allowed to choose from a wide variety of courses preparing them to address research problems in different areas of Computer Science. There is an open environment for collaboration within the department and students are given great freedom and guidance to choose research problems that interest them. The curriculum also encourages students to get practical experience outside academia. To my research field, this is an integral component, as we get exposed to real problems that software developers face. The Automated Software Engineering research group, of which I am a part of, has ties with researchers from other universities and industrial research labs around the world. I have been very fortunate to work in few of the leading research labs in my doctoral career so far.

 6. Could you share your experience in technical conferences and during paper presentations?

 Our research group actively publishes in leading Software Engineering conferences. I have been fortunate to attend and participate in a few of them and it is a very rewarding experience. A student needs to have very good communication and presentation skills to get the best out of such conferences. It is about effectively and clearly presenting months or years worth of research work in less than half an hour and getting the audience interested. Leading experts in the field attend these conferences and it is very useful to get constructive feedback from them. Discussion with other conference attendees aid students in identifying problems in their research and also defining newer research problems to solve. This conference interaction leads to collaborations among researchers with similar interests. One also gets to learn about the most current research problems in the field by attending other presentations and key note talks. Conferences are also a great venue to meet with your prospective employers and discuss mutual interests. In summary, meet and talk to as many people you can in such conferences to ?sell? your research and also know about the latest in the field.

7. What innate skills do you feel essential for a PhD aspirant?

 In short, systematic problem solving skills are the most important requirement for a PhD aspirant. There are various components in productive problem solving. The first component is gathering the background knowledge required to conduct research. A PhD student has to know what has been done so far in his field and the emerging trends. A student gathers this knowledge by taking relevant courses and conducting extensive literature survey. A student should be very good at extracting relevant information for the research from the vast body of existing work quickly and effectively. The second component is identifying an interesting problem worthy of solving. This is a major component and takes time. Having a good advisor greatly helps here. The third component is excellent writing and communication skills. These skills are required to effectively publish the research findings and to get constructive feedback from advisors, mentors, and leading experts. In my field it also helps to possess good software development skills, the fourth component. We propose research solutions, implement them as tools, and test their effectiveness on real software subjects. Finally, a student needs to be self-motivated, passionate about the research problem, and dedicated to perform productive research. Some valuable advice on conducting research given by my advisor can be found at:

http://www.csc.ncsu.edu/faculty/xie/advice/

 8. What are your future aspirations?

 My immediate plan after graduation is to work as a software engineering researcher for an industrial research lab with strong publication culture. In my area, research problems are usually motivated by industry needs. After a few years of experience in the industry, I would like to apply for a tenure-track faculty position in reputed universities. As an academician, one has greater freedom in choosing the research problems and collaborations. My prior exposure to the software industry should enable me to address practical problems, the solutions of which would fundamentally advance the field of Software Engineering.

 9. Any comments on the software industry in India?

 The prospects for software industry in India are very bright. Leading software companies such as Microsoft and IBM have set up research labs in India recently. These research labs have strong collaborations with universities all over India. Most software development giants such as Infosys have research wings in house. These collaborations and industrial investment for research tie up practice and research promoting fundamental advances in the field of Software Engineering.  With its man-power and skill, India is soon going to be a software super power, contributing fundamentally to the field of Software Engineering and Computer Science in general. To this end, I personally feel that the government should increase funding grants and support for major universities such as Indian Institute of Technologies (IIT), apart from spawning newer universities for higher education. Graduate-level education in India for engineering and physical sciences is still not up to the mark and a substantial investment here would help transforming India to a knowledge super-power.

Posted at 09:10AM Apr 27, 2007 by ACHARYA, MITHUN in General  |  Comments[1]

How to meet your advisor?

In my view, the major purposes of individual (i.e., one-on-one) meetings include several parts:
(a). Keep the advisor informed on some research details (either the work being done the period before the meeting or the work to be done in the next time period) so that the advisor can give advice or guidance on them
(b). Brainstorm new research ideas and get feedback from the advisor
(c). Allow the advisor to know that you are making progress and going on the right direction/track.
(d). Any other things that the student wants to talk to the advisor (like general career advice, things that happened recently in the group, department, and the research field)

The first advice for students on meeting the advisor is "do sufficient preparation before your meeting with your advisor". I can tell that some students sometimes didn't prepare for their meeting with me. They came in my office and didn't have a meeting agenda in mind. After they used one or two sentences very briefly to inform me what they have done and they are going to do, they stopped and had no specific things to talk about during the rest of the meeting.

Students should list about things to be discussed in mind or in paper. In my early day's meeting with my advisor, I brought in printed hardcopy slides or some note printout. In the beginning of the meeting material, I put a list of items to be discussed if there are more than one item. I have thought carefully how to make full usage of the 30 mins (later 45 mins or 60 mins) that my advisor allocated for me. I usually spent some non-trivial time in preparing materials for my meeting with my advisor (this preparation could also help me to organize the work being done in the passing week and plan out what I am going to do in the next week).

There are two general types of students in terms of their style of meeting the advisor:
1. Have not much to say during the meeting with the advisor
2. Have too much to say during the meeting with the advisor

The first type is more common, I think. Many students often cannot use up the time slot allocated for them (either 1 hour, 30 mins, or 15 mins). They don't seem to have much to say with the advisor. I think a wise student should take full advantage of the allocated time slots.

For both types, the high-level quesiton that the students should ask themselves is: "What do you want from your advisor during this meeting?" Your advisor also had the same question "what do you want from me?". This question would be especially helpful for the second type of students. Usually the second type of students wants to expose to the advisor every tiny detail of the work that they have done or every tiny detail that they are going to do. If a student usually finds that he or she cannot finish the meeting within the time slot, there are two options: one is to request a longer time slot if the student finds that he or she has indeed important things to talk to the advisor, and the other is to rethink whether some of the stuffs that the student is telling are important for the advisor to give advice. That is, after the student explains the tiny details, would he or she expect the advisor to give specific useful advice? Or would the student expect certain advice on the tiny details? If not, than probably the student doesn't need to explain that levels of details to the advisor. One downside faced by the second type of students is that when a student overwelms the meeting with so many tiny details, the big picture is lost and the advisor may lose the opportunity and time to talk to the student on high level more important things.

The first type of students is way more common. They tend to keep many research details to themselve, not discussing these details with the advisor; this way may be acceptable or even preferable when the students are in a late stage that they can have quite high confidence of doing **right** things in **right** ways independently. Then they can focus on high level big pictures and other high level things during their meetings with their advisor. In my late stages of my Ph.D. program, I pretty much go for this way. But for students in early stages, they should discuss more research details with the advisor. One way to fix this issue of not much to say is to do more preparation before the meeting, as mentioned earlier! Before the meeting, think about what you want to disucss to use up the allocated time slot!

Another possible reason that some students have not much to say is that they are busy with their course work and other legitimate things, not being able to spend much time on developing the reseach project or making enough progress; this situation occurs very often when students are in their early stage, taking non-trivial course load. The advisor would often show understanding on the situation. But that doesn't mean that students would skip the meeting or have not much to say in the meeting. In my early stages of Ph.D. program, I didn't or couldn't spend a lot of time in developing research projects, partly because of taking courses and partly because of lack of good research ideas to work on (I struggled on coming up good reseach ideas for quite a while in my early stage of my Ph.D. program). But I still kept routine meetings with my advisor, talking about ideas that I have, talking about my understanding of some papers, talking about other things ... Of course, I needed to spend time on preparing for such meetings especially when the meeting didn't focus on speciifc research details that I developed.

In my Ph.D. program, when I had a meeting with my advisor, I wouldn't leave till I used up all the time allocated to my meeting. When I finished technical parts, if some time still remains, I would talk to my advisor on non-technical, causual stuffs like research community, high level career advice, the advisor's view on certain things, ...

In summary, I hope students can use up and take full advantage of their meeting time slots with the advisor.

Posted at 11:42PM Apr 26, 2007 by XIE, TAO in Research Skills  |  Comments[2]

How can you write "much"?

It is common that students cannot write much when they start writing their first several research papers. Usually conference papers shall have 10 or 11 pages IEEE or ACM conference format but students often don't know how to fill in writing for that many pages.

Based on my experience with improving students' writing, here are some tips for expanding their papers to be longer, richer, and more professional.

For advice in writing each section of a paper, see my slides at:
http://www.csc.ncsu.edu/faculty/xie/publications/writepapers.pdf
Next I am talking about some advice on expanding students' writing on each section.

*. Abstract
An abstract usually consists of the following parts: short motivation (problem), proposed solution, evaluation, and evaluation results. For more detailed guideline on writing an abstract, please see:
http://www.lightbluetouchpaper.org/2007/03/14/how-not-to-write-an-abstract/

*. Introduction
A short introduction can be expanded by adding more background on the problem and how related work addresses (or doesn't address) the problem, the overview of your approach, the evaluation of your approach, and the evaluation results. You can list the main contributions of the paper there and lay out the structure of the rest of the paper in the end of the introduction section.

*. Example
Put an example section in your paper!! Some students still didn't put such a section there. Explain the details of the example and how your approach would work on the example. You can have a background section before the example section if there is much background info to present. But you can also consider to use your example to illustrate the background info.

*. Framework (or Approach)
First give a high-level overview of the approach (no need to turn it into a subsection but just put it as the text immediately after the framework section and before the first subsection. Use a diagram to show the components of the framework. You may have some bullet points to summarize the key features of each component. Then you can put each subsection for each component of the framework. You can use examples (which can be the same as the one described in the example section) to illustrate some key points of each component.

Many students initially used just a few sentences to describe the techniques in each component. When you see that your description is too short, you may see whether a reader could understand the details. Another way to think about it is to see if you provide enough details so that readers can reimplement your approach (not necessarily with the tools or libraries that you will describe in the implementation section).

Sometimes some components may be third-party tools. Many students have the perceptions that they don't need to describe these tools in details but refer the readers to read the cited papers. This is wrong. Your paper needs to be self-contained: if some techniques from third-party are used as an important part of a component, you need to provide enough details. Of course, you need to explicitly cite related papers when these components are not developed by you for the work in this paper.

*. Implementation
Usually this section is not too long. Some common mistakes that students make are to repeat many things that have been described in the framework section. You don't need to. You can list the components and then describe what third-party tools you use or how you implement them. But don't make your implementation section too short. You can double check to see whether you provide enough details so that readers can reimplement your approach exactly as the implementation that you have developed.

*. Experiment
Many students forgot to put in the necessary subsections there such as Objectives, Metrics, and Experiment Setup (including subjects and procedure, etc.). Many students simply put "Experimental Results" there. Even when they put experimental results there, they simply put figures or tables for the results and use a few sentences to describe the results. Students should describe in details what figure x/y axis mean, what table columns mean, etc. Many students rely on readers to read the figures or tables directly without using text to describe them.

In addition, students need to summarize how the experimental results answer the question/objective posed in the beginning of the section.

*. Discussion
Many students don't have a discussion section. Sometimes there are complications or future work, and this discussion section could be good to include these things.

*. Related work
Many students simply list the names of related projects/tools or just one sentence to describe related projects/tools. Students should describe more details about these related projects/tools. One paragraph for one related project/tool is even acceptable for a very related project/tool. In addition, students often forget to compare the difference between the discussed related project/tool with the new project/tool. Usually, the related work section can be easily substantially expanded (of course, when you go beyond your page limit, you can come back to cut short your related work section).

*. Conclusion
Conclusion is usually not long but not too short. Many students have a very short conclusion. It can have similar structure as the abstract: you need to say the motivation/problem, how your tool addresses the problem, the components that you tool has, the evaluation that you conducted, the evaluation results that you got, etc. Optionally you can state your future work here.

*. References
Students tend to cite too few papers, partly because they include too few related projects/tools in the related work section, without knowing enough relevant literature. To fix that, of course, students need to collect more related papers. One way is to upload their PDF draft to http://mondego.calit2.uci.edu/ra/ to collect relevant papers based on text or keyword similarity. Of course searching google with some keywords is also very effective. More other tips are described in my slides on "advice on writing research papers" whose link is listed earlier.

Another way to expand references is to cite representative papers on the same (big) field (e.g., regression testing, test generation, static bug detection, ...) in the introduction.

Final note:

One common bad writing style that I found among students in their early writing is over-use of bullet points. They tend to list things in bullet points. Normally in my papers, except for the main contributions that I want to list in the introduction section, I don't use bullet points often.  Too many bullet points make your writing not so professional. A similar listing effect can be achieved well by using some highlight (bolded) keywords in the beginning of paragraphs (but not bullet points). Sometimes when I try to list things, I simply use "First, ..... Second, .... Third, ....". When these different parts are long enough, I will make paragraphs and start these paragraphs with "First, .." "Second, ...." "Third, ....".
 

Posted at 02:06AM Apr 24, 2007 by XIE, TAO in Technical Writing  |  Comments[0]

Answers to "The Global Educator" Magzine Interview Questions

The Global Educator magzine addresses students of science and engineering. The focus of the magazine is to provide information to students about educational institutions (specifically focusing on engineering and technology) in India and overseas, inform them about developing opportunities in engineering, offer practical tips on how to manage education abroad, carry interviews and profiles of achievers in the field of science, technology, engineering and business as role models.

Below are the answers to the interview questions posed by the Global Educator to me. They will be published in a future issue of the magzine.

1. How did you discover your interest in Software Engineering?

I learned programming in my high school years and found software construction fascinating. In my undergraduate senior year, I participated in software project development in research labs within the university and in companies outside the university. When I got more involved in real-world software development, experiencing real difficulties faced by software practitioners, I became more interested in techniques and tools for addressing these real difficulties in software development. When I had a choice in choosing my research area when pursing my M.S. research at Peking University, I chose to focus on software engineering research. Since then, I have developed strong interest in automated software engineering, with a focus on automated software testing and mining software engineering as well as their applications in practice.

2. Could you tell us about your career so far?

I am currently an Assistant Professor in the Department of Computer Science of the College of Engineering at North Carolina State University since August 2005, after I received my Ph.D. in Computer Science from the University of Washington, advised by David Notkin. Before that, I received an M.S. in Computer Science from the University of Washington in 2002, an M.S. in Computer Science from Peking University in 2000, advised by Hong Mei, and a B.S. in Computer Science from Fudan University in 1997. I lead the Automated Software Engineering Research Group at North Carolina State University. In my career, I have been very fortunate to have great mentors to help me and to have great students to work with.

3. Has teaching always been a career aspiration or did teaching and research interest you over time?

Teaching has always been a career aspiration to me. Teaching students and seeing them grow are always very enjoyable. Teaching students is also a learning process for myself because often the time I learn new research ideas or thinking from students through interactions with them.

4. What are the important skills a person needs to be an academician?

There are many important skills for being a good academician: a good researcher, a good educator, a good collaborator, and a good citizen in the research community. Some important skills include being able to teach and advise students, being able to generate many good research ideas, being able to assess and judge research work, being able to manage and coordinate a team of students and collaborators to carry out research tasks, etc.

5. Do you think faculty members should maintain a good balance of teaching and research?

Both teaching and research are important in a faculty member?s career. Successful teaching can attract good students to the research area, and excite and inspire them to learn more about doing research. On the other hand, successful research can be incorporated in teaching so that students can learn state-of-the-art research in the field and prepare them with important skills for conducting research or solving real-world problems.

6. For a dynamic field like software engineering where in each day brings in new changes in terms of technologies, how do students keep themselves updated since curriculum cannot be changed so fast?

Although new changes in technologies occur frequently, many of these new technologies share the same underlying foundation as previous technologies. So students need to have a deep understanding and grasp of the underlying foundation and then they can easily absorb and adopt the emerging technologies. Furthermore, students shall have the capability of self-learning, self-training, or self-educating in order to keep up with new changes in technologies.

7. For PhD aspirants, how do they decide on their research topics? Could you advise them on the preparation they need to do before entering into a doctorate program and how do they work over the years?

Ph.D. students can decide research topics based on their research interests, their research background and expertise, and the significance and impact of research topics. In other words, students shall work on what interest them most, on what they can do well, and on what matter to software engineering research and practice. In addition, students shall also make sure that the evaluation of research results in research topics can be feasibly conducted (given available resources); otherwise, the students may not be able to convince either researchers or practitioners with their research results. Before students enter into a doctorate program on software engineering, students need to prepare themselves to have strong basic software engineering skills, including design, programming, testing, debugging, maintenance, etc., as well as general problem solving skills. Many research sub-areas in software engineering require building software tools and conducting experiments so the basic software engineering skills would be critical. Over the years in their doctorate programs, students need to learn how to carry out good research and how to write good research papers, and eventually learn how to be independent in research (independently coming up new research ideas and developing them).

8. Are all research projects in software engineering usually a collaboration between academic community and the industry?

Some but not all academic research projects in software engineering involve collaborations with the industry. In these collaborations, the industry can help provide sources of research problems, resources of research infrastructures, platforms of research-result evaluation, transfer of technologies, and supports of funding. Many academic research projects have produced impact on the industry. ACM Special Interest Group on Software Engineering (SIGSOFT) has initiated the Impact project (http://www.sigsoft.org/impact/) to determine the impact of software engineering research upon software engineering practice.

9. Could you talk about the career opportunities open to software engineers?

There are many career opportunities open to software engineers. Like in other areas of computer science, a Ph.D. graduate can seek career opportunities in academia (either research or teaching institutes) or industry (either research labs or companies). An M.S. or B.S. graduate can seek many career opportunities in companies. There are various job types of software engineers, including software testers, software developers, software architects, etc. On April 24, 2006, CNNMoney.com (http://money.cnn.com/magazines/moneymag/moneymag_archive/2006/05/01/8375749/index.htm) reported that software engineers have the best jobs in the US. It said ?software engineers are needed in virtually every part of the economy, making this one of the fastest-growing job titles in the U.S.?

10. Could you name some of the top employers of software engineers in the US?

Some of the top employers of software engineers in the US include Microsoft, IBM, Google, Yahoo, Cisco Systems, Oracle, etc. Many more companies than I can name here employ a large number of software engineers.

Posted at 12:36AM Apr 24, 2007 by XIE, TAO in Research Skills  |  Comments[2]

Become the owner/driver of your research projects

Students have different levels of ownership of their research projects. Sometimes some students feel that they are doing the work primiarly "for their advisor" not primiarly "for themselves". They feel that they need to catch a submission deadline simply because their advisor wants them to make the deadline. I have been trying to pay attention to this issue lately.

In last week's group meeting, I went around the table to ask students to speak out what conference deadlines they want to catch for submitting papers on their research projects rather than being told by me on what deadlines they shall make. It may be just a phycological effect because either the students or I would choose the same deadline to catch but if it is spoken out by the students, I hope the students have more ownership and more incentive in catching up the deadlines.

Students shall take ownership and driving force of their research projects rather than the advisors. We shall explore how to move towards this direction.

Posted at 10:04PM Apr 23, 2007 by XIE, TAO in Research Skills  |  Comments[0]

Think more and write more

Several days ago, I share my Ph.D. writing trails (my writings in my first several years in my Ph.D. program) with my students.

Most of the docs/ideas there didn't lead to a publication (when I look back now, I even wouldn't encourage my own students to pursue those ideas). Students can sense my struggling along the way in my Ph.D. research. At the same time, they can also see the following characteristics that are good for them to learn and have:

(1). actively thinking of new ideas even when these new ideas may not be good ones
(2). actively writing things down even when these writings may not turn into a publication

In addition, they can have a chance to laugh at my writing in my early phases of my Ph.D. research and put red marks on my writings (see how many red marks they can put there) as a "revenge" to my red marks on their paper.:)

Posted at 10:03PM Apr 23, 2007 by XIE, TAO in Idea Generation  |  Comments[0]

Upcoming Conference Submission Deadlines

The first major one is ASE 2007 due June 11:
http://www.cse.msu.edu/ase2007/

The second major one is ICSE 2008 due Sept 14:
http://icse08.upb.de/

How many paper submissions can our group prepare for these two deadlines? I don't know.

I have some concerns there given that our students will go out to work for summer internships in industry around mid May. If students don't get the work done or most of the work done before the summer begins, the chance of getting an ASE submission is low.

After the summer ends, we have only less than one month before the ICSE 2008 deadline. If students don't prepare the work early enough,  it will be tough to make the ICSE 2008 deadline.

Any students who wish to make these deadlines need to make plans early on and work very hard to produce high-quality submissions rather than relaxing and thinking that there are still so many days left before the submission deadlines: in fact no many days left when subtracting the summer internship days...:(

Will see how things turn out after these two deadlines pass.

Posted at 08:00PM Apr 19, 2007 by XIE, TAO in Submission Madness  |  Comments[0]

Research skills required to conduct research (on automated software engineering)

Posted at 07:20PM Apr 19, 2007 by XIE, TAO in Research Skills  |  Comments[4]

The birth of the blog for our NCSU ASE group

I created this blog to foster discussion and collaboration among our NCSU ASE group members and share our thoughts and experiences with people outside of our group. The main topic of the group will be about research but can be about anything related to NCSU ASE group:
http://ase.csc.ncsu.edu/ 

Posted at 07:01PM Apr 19, 2007 by XIE, TAO in General  |  Comments[0]