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.
