Research Paper

Robert Young

English 250

Section PN

3/31/14

The Processes and Procedures Used to Handle Communication in Small Group Software Engineering

Most of my life, I have wanted to be the guy that writes the programming behind video games. Whenever I play one, I ask myself, “How would I implement this if I were a developer?” In order to understand this question more, I need to know how exactly developers develop the programs they make. A little bit of google searching told me that usually they work in small groups of developers, usually between 4 or 5 people to up to 50, depending on the project. This led me to another question: how do they know what is done and what isn’t done? How do they communicate between each other to see what bugs have developed, what bugs have been fixed, etc.? So I did a little bit more research. It turns out the answer is a little bit more complex than I had thought.

A software development team uses several different forms of communication varying from email to phone calls to meetings to conferences to just having a conversation. Each one has its pros and cons. For instance, e-mails are better for requesting something to be done, while phone calls would be better for trying to explain how something works. Meetings and conferences are like checkpoints to see what all has been done, as well as what needs done next. If two people are working on the same code, they would probably want to be in the same room communicating verbally with each other.

Other forms of communication that Software Engineers can use in a small group setting include storyboards, which are big flow charts that tell software engineers how a program should be designed. If put technically, it would be how each of the classes interact with each other, what methods they need to implement, etc. To put it non-technically, imagine a set of Legos. Each developer would be working on making a brick, and when the project is done, the Legos make up the entire piece of software. When a certain part of the program (or Lego brick) is done, the step on the flow chart can be crossed off on the storyboard. Usually, a storyboard is put in a place where everyone can see it fairly easily. It makes it really easy to update all of the developers on the progress of a piece of software.

However, in addition to the different types of communication they use internally, Software engineers have to communicate with a consumer to know exactly what they need to build. This is where it gets interesting. The consumer and the developer usually have different ways of communicating their ideas. The Consumer will probably try and describe what he wants in words, and the developer will have to try to interpret those words in the correct way for the consumer to be happy. As Keith Edwards and Robert Puckett put it, “Clients can exhibit difficulty in communicating specifications and are unaware of constraints on the software developers” (Edwards, and Puckett). Since most software engineering projects nowadays are fairly large, the consumer may have trouble finding the right words to describe what they want. There is not a really good way around this. One solution was to have “technical communicators,” or people who are really good at interpreting the client’s specifications and translating them into specifications that developers can understand.

Probably the most important type of communication the code itself. By reading code, developers can figure out exactly what is happening in a program. To use my metaphor above, each developer would be able to tell where a brick goes by looking at it. How big it is, and what color it is all help a developer tell how exactly to implement it in their piece of software. In large programs, developers often leave comments that explain what each method does and what each class is for. Trying to read uncommented code in a large program would be like trying to read a thousand-page book in Spanish. Granted, the developers know the language the code is in, so try to imagine you know some Spanish. Since it isn’t your first language, it is still pretty dang hard to understand, but possible. To use my metaphor above, each developer would be able to tell where a brick goes by looking at it. How big it is, and what color it is all help a developer tell how exactly to implement it in their piece of software.

Works Cited

Edwards, H. Keith, Robert R. Puckett, and Art Jolly. "Analyzing Communication Patterns in Software Engineering Projects." Software Engineering Research and Practice. 2006. Edwards, Puckett, and Jolly analyze the communication methods used by Software Engineers in order to see what is good and what is bad, aiming at other researchers with the same questions. The author makes no assumptions, getting all their information from other sources, without emphasizing any single aspect of communication. There is no bias or omissions.

Communication Effectiveness v. Richness of Communication. Digital image. Agile Modeling. N.p., n.d. Web. 12 Mar. 2014. This image is not directed toward any particular audience, and only serves as a visual for the effectiveness for different types of communication. No assumptions or major omissions were made. There would be nothing to gain from altering this image, so bias can be assumed to be negligible.

Al-Rawas, Amer, and Easterbrook, Steve. Communication Problems in Requirements Engineering a Field Study / by Amer Al-Rawas and Steve Easterbrook. Eds. Easterbrook, S. M. and Administration United States. National Aeronautics and Space. Washington, DC : Springfield, Va.: Washington, DC : National Aeronautics and Space Administration ; Springfield, Va. : National Technical Information Service, distributor, 1996. Print. In this article, the authors attempt to identify the problems that occur when gathering the requirements for a Software Engineering Project. Directed toward other engineers who might find use with this information, this article emphasizes communication between the developers and the end users. There is no bias or slant in the article, and the evidence does support the main points, but there is no discussion on the topic of communicating the requirements between a small group of individuals.

McChesney, Ian R., and Séamus Gallagher. "Communication and Co- Ordination Practices in Software Engineering Projects." Information and Software Technology 46.7 (2004): 473-89. Print. The main idea of this source is to get a grasp of what types of communication take place between software engineers as they develop software. The article is aimed at other researchers that may be interested in the subject. The author emphasizes only the communication in the small group, and omits the communication with the client. There is no bias or slant, as it is a peer-reviewed article. The evidence supports the main points.

"Software Engineering-Coordination and Communication Issues - Best Online Tutorials | Source Codes | Programming Languages." 1000 Source Codes. 1000 Source Codes, n.d. Web. 07 Apr. 2014. This article is about the types of communication that software Engineers use, but not really how they use them. This article is focused on a more general audience and can be related to by pretty much everybody. It focuses more on the types of communication, and less on how those communications are actually used.