IEEE Software Special Issue: Development Tools: Difference between revisions
| Line 17: | Line 17: | ||
** phone: +49 176 23522758 |
** phone: +49 176 23522758 |
||
** fax: +49 62277845917 |
** fax: +49 62277845917 |
||
* Arthur Ryman |
* Arthur Ryman, IBM Rational |
||
** IBM Toronto Lab, 8200 Warden Avenue, D3/XJ6, Markham, Ontario, L6G 1C7 Canada |
|||
** ryman@ca.ibm.com |
|||
** phone: +1-905-413-3077 |
|||
** fax: +1-905-413-4920 |
|||
== Introduction and Relevance == |
== Introduction and Relevance == |
||
Revision as of 05:17, 31 May 2007
Proposed Title
Clear, crisp, meaningful. Try to make it no more than 5 words.
Proposals:
- The Software Developer's Workbench
- Software Development Infrastructur
- Software Development Tools
Proposers’ Information
Names, affiliations, and contact information (postal address, electronic address, telephone number, and fax number).
- Diomidis Spinellis
- Simon Helsen, SAP AG
- Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
- shelsen@computer.org
- phone: +49 176 23522758
- fax: +49 62277845917
- Arthur Ryman, IBM Rational
- IBM Toronto Lab, 8200 Warden Avenue, D3/XJ6, Markham, Ontario, L6G 1C7 Canada
- ryman@ca.ibm.com
- phone: +1-905-413-3077
- fax: +1-905-413-4920
Introduction and Relevance
Explain the theme and how it fits in the larger context of software engineering. Make sure to define the central terms and concepts. Describe the proposal’s relevance to IEEE Software readers: importance, timeliness, target audience, and so on. Examine recent publications, including other focus sections of IEEE Software, to convince the evaluators that the theme complements other work or fills a gap.
Focus
Detail particular questions that will be addressed or perspectives that will be described. If other publications have addressed similar themes, how will this focus section differ? Describe what readers will learn and whether this information is available elsewhere.
Organization
Discuss what kind of contributions or parts you want the special issue to include. It should include:
a. An introduction written by the GEs, probably including a tutorial or overview of concepts and terminology, enabling readers unfamiliar with the topic to understand the articles. Do not summarize the articles, but instead explain how they relate to the topic and to each other. Your introduction should also contain a sidebar on related references.
b. A balanced selection of refereed articles and non-refereed pieces. We recommend that you engineer the content for alignment with the special issue’s vision rather than simply select the top N submissions with the best reviews. The preferred way to provide balance is by using a Point-Counterpoint article (PCP) that highlights conflicting views related to the theme. (As an example, see the March/April 2000 issue.) Alternatively, the special issue might comprise a variety articles suggesting significantly different points of view on a subject. (For example, see the July/August 1991 issue.) Roundtable discussions representing the views of several experts are also popular. (For example, see the “Viewpoints” article in the September/October 2006 special issue on testing). Consult with the Magazine Assistant regarding the PCP and Roundtable process and formats.
List of Potential Reviewers and Authors
Balance academics with industrial and governmental contributors (the latter where appropriate). State preliminary contacts that have been made. Remember that IEEE Software is a refereed publication; all solicited manuscripts (except for the Point-Counterpoint and Roundtable articles) must be refereed and are not guaranteed acceptance. The majority of manuscripts that finally appear in the issue will likely be the result of your solicitation. Propose a credible plan for assuring enough high-quality submissions.
Potential Contributors/Authors
| Name | Affiliation | contacted/willing? (C/W) | Subject | |
|---|---|---|---|---|
| Andreas Zeller | University of Saarland, Germany | [1] | on debugging tools | |
| Lawrence Mandel | IBM | [2] | on Web Service tools | |
| Erik Meyer | Microsoft | on MS dev tools | ||
| Robert Fuhrer | IBM Research | [3] | on Safari | |
| Mads Torgersen | Microsoft | [4] | on MS dev tools | |
| Peri Tarr | IBM Research | [5] | on CME | |
| Li-Te Cheng | IBM Research | [6] | on JAZZ | |
| Brett Porter | Merger inc and Apache | [7] | on Maven | |
| Bill Pugh | University of Maryland | [8] | on FindBugs | |
| Daniel Fuchs | Sun Microsystems | [9] | on JMX | |
| Dave Miller | Mozilla Foundation | [10] | on Bugzilla | |
| Krzysztof Czarnecki | University of Waterloo | [11] | (general) | |
| Jeff Gray | University of Alabama | [12] | (general) | |
| Martin Fowler | Independent consultant | [13] | (general) | |
| Neil Harrison | Utah Valley State College | [14] | (general) | |
| Karl Frank | Northrop-Grumman | [15] | (general) |
Potential Reviewers
| Name | Affiliation | contacted/willing? (C/W) | |
|---|---|---|---|
| Markus Voelter | Independent Consultant | [16] | C/W |
| Steve Cook | Microsoft | [17] | C/W |
| Boris Gruschko | SAP | [18] | C/W |
| Christof Ebert | Vector Consulting | [19] |
Call for Articles
Create a Call for Articles based on your focus. This is often where the “rubber hits the road” on a topic: a good call is specific and clear. Create a Call for Articles based on your focus. The Call for Articles must be open. Pre-acceptance is not permitted and invited submissions are not exempt from the peer-review process with the exception of Point-Counterpoint and Roundtable pieces. Include the following texts in the Call for Articles:
Manuscripts must not exceed 5,400 words including figures and tables, which count for 200 words each. Submissions in excess of these limits may be rejected without refereeing. The articles we deem within the theme's scope will be peer-reviewed and are subject to editing for magazine style, clarity, organization, and space. We reserve the right to edit the title of all submissions. Be sure to include the name of the theme or special issue you are submitting for.”
Articles should have a practical orientation, and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments are not appropriate. Articles should be novel. IEEE Software does not re-publish material published previously in other venues, including other periodicals and formal conference/workshop proceedings, whether previous publication was in print or in electronic form.
Refer interested authors to you for more information about the focus and to the magazine assistant (MA) at software@computer.org for author guidelines and submission details.
Software development tools have become an indispensable part of the modern software development process. They are required to manage software complexity, global team coordination, legacy software maintenance, software migration, agile software development, localization, etc. Such tools address virtually all aspects of the software development lifecycle and are used to
- improve the quality of produced software (e.g. profilers, automated test environments, bug finders, debuggers, etc.)
- automate the software production process (e.g. compilers, program generators, GUI creation tools, wizards, etc.)
- ease the process of producing code (e.g. intelissense editors and sophisticated IDEs)
- increase the reliability and maintainability of software under construction (e.g. version control systems, continuous build integration, reproducible night builds, etc.)
- improve communication inside development teams (e.g. requirement, feature, and bug tracking; WIKI's)
- improve customer communication and feedback (e.g. customer issue management and handling)
- manage and synchronize documentation (e.g. documentation generators)
- track quality changes over the development lifecycle (e.g. automated performance measurements)
- improve the ability to maintain released products (e.g. lifecycle management tools, remote debugging)
The special issue on "software development infrastructure" solicits papers, which describe how tools can generally improve the software development lifecycle process. Articles may address specific trends; compare existing tools and approaches; or provide an in-depth analysis of the benefits and drawbacks of a particular tool. Articles should be backed by working software or empirical evidence.
Qualifications of the Guest Editors (GEs)
In addition to technical qualifications, highlight your experience as editors, in IEEE Software and other publications. Attach a biography of up to one page for each GE, including a list of the five most relevant publications. Two GEs are preferable to one. At least one GE must reflect an industrial and practical viewpoint. In addition to technical qualifications, highlight your experience as editors in IEEE Software and other publications. Include a short biography for each GE, including a list of the 5 most relevant publications. Two GEs are preferable to one. At least one GE must reflect an industrial and practical viewpoint. Consider involving a member of the Editorial or Advisory board as a GE. Note that GEs co-author an introductory piece for the special issue, but they cannot submit articles or appear as co-authors on any of the included articles.
Notes
Here we put our notes for putting together the issue.
Elements of the software development workbench
- IDEs (eclipse, VS, netbeans, etc.)
- Debuggers
- Profilers
- Static code analysis
- Test tools (testing, test coverage, etc.)
- SCM
- Issue/bug tracing management
- Build management
- Lifecycle management
Interesting/specific tools
- Code quality management
- Findbugs
- Junit and Emma
- SCM
- Subversion
- CVS
- Issue trackers
- Bugzilla
- Jira
- Build management
- JAZZ
- Maven
- Cruise Control
- Lifecycle management
- JMX
- General tooling infrastructures
- Eclipse as an OS for development tools
- Visual Studio and software factories
- Safari as meta-modeling toolkit
- Concern Manipulation Environment (CME)