Monday, April 7, 2014

Graduate and Professional Student Research Conference Thingamajigger

Robert Young
English 250
Section PN
4/7/14
Graduate and Professional Student Research Conference

The only think I was really able to go to was the thesis competition toward the end of the day, so I didn’t have a lot of options to choose from when I decided what topic to write this paper about. Luckily, two of the theses that were discussed had to do with my major. One presentation, by Micheal Curtis, a student in Human Computer Interaction, was about how you could temporarily cure motion sickness caused by differences in virtual reality and real life (for example, when your eyes tell you you are moving forward, but actually, you are moving sideways). I thought this was cool because virtual reality, to me, is kind of like a video game. You use controls to move around while you yourself are staying in one place, which is hard for your brain to comprehend. Anyway, the solution that this guy was going to research was doing some sort of physical activity or puzzle or something of the sort to get the virtual part and the real life part of your brain back in sync. 

Wednesday, March 12, 2014

Annotated Bibliography

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.
           
Cherry, Sébastien, and Pierre N. Robillard. "Communication problems in global software development: Spotlight on a new field of investigation." (2004): 48-52. The main point of this article is to point out the inefficiencies of groups that communicate over distance. Aimed at other software engineers who may find the information useful, this article goes over means of communication that are not face-to-face. There is no bias or slant in the source, and the evidence supports the main points, but the article focuses only on long-distance communication.

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.

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.

Hainey, Thomas, et al. "Evaluation of a Game to Teach Requirements Collection and Analysis in Software Engineering at Tertiary Education Level." Computers & Education 56.1 (2011): 21-35. Print. Hainey seeks to come up with a way to better prepare software engineers for real-life software engineering positions by developing a game-based learning application to teach requirements collection. Directed toward other researchers who may be interested in this approach, Hainey emphasizes the use of games over conventional methods in order to teach Software Engineers how to gather requirements for their projects, without assuming much, getting information from several other sources. There is no bias or notable omissions in this article.
           
Knorzer, Oliver, and Powree. Richard's Guide to Software Development. Digital image.Sandra and Woo. N.p., 19 Nov. 2012. Web. 12 Mar. 2014. This is an image that depicts the software development process as a cat, and in each frame, a different version of the cat is displayed. The author is trying to help visualize the things that go into software development for common people. It emphasizes the work that goes into a project, as well as the results of that work, but doesn’t focus on communication alone. Is there bias? Probably. It is a webcomic, designed to be more funny than true.

Liu, C., Sandell, K., and Welch, L. “Teaching Communication Skills in Software Engineering Courses,” Proceedings of the 2005 American Society for Engineering Education Conference and Exposition, Session 2461. 2005. The main point of this article was to find the best way to teach communication skills to students in computer science and software engineering. This article is geared toward professors who should be teaching these communication skills.

Maiocchi, Marco. "Software Engineering." Future Generation Computer Systems 7.1 (1991): 23-29. Print. Maiocchi seeks to provide other researchers with an overview of what software engineers contribute to software production. The author does not emphasize over any single software engineering role, and doesn’t make any assumptions as all required information is found and cited in external sources. There is no bias, or notable omissions.

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.

Poyhonen, P. J. "Structuring Routine Interactions in Software Engineering." Managing Complexity in Software Engineering. By Richard Mitchell. Hitchin: Peregrinus on Behalf of the Institution of Electrical Engineers, 1990. 167-79. Print.

Ruff, S., and M. Carter. "Communication Learning Outcomes from Software Engineering Professionals: A Basis for Teaching Communication in the Engineering Curriculum." 2009. 1-6. Print.

"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.






Wednesday, February 26, 2014

Textual Analysis

Robert Young
English 250
Section PN
2/24/2014
Forget Foreign Languages and Music. Teach Our Kids to Code: An Analysis
What would you think of a five-year-old trying to program a computer: and succeeding? “Forget Foreign Languages and Music. Teach Our Kids to Code,” by Brendan I Koerner, a columnist for Wired magazine, proves that this is possible. Children can learn the basic principles of programming in their early years, despite the public opinion that programming is something that is above the level of kindergarteners and elementary school students. To prove this point, Koerner quotes Paul Gibson, a Computer Science teacher in France, references several programs that attempt to teach programming at a younger age, and making comparisons between computer languages and music and foreign languages.
In this article, the point is more that you can teach programming principles at a young age rather than the code language itself. The difference is that programming principles have more to do with problem solving skills and less to do with  code syntax and actually writing statements and executing them. Basically, he’s teaching them how to come up with pseudo-code rather than the actual code itself. They come up with the steps they need to take in order to solve a problem, then have the instructor implement them. In order to teach the language itself, and get all of the syntax correct, the children do, indeed have to learn how to read and write. Otherwise, they won’t have a clue what they just wrote down. A solution to this would be Drag and Drop programming (something that I have personal experience with), where symbols are used instead of words to come up with algorithms. Then the children won’t have to worry about the syntax or how things are spelled or anything like that. This is exactly what Koerner is trying to convey when he says “Kindergarteners cannot become C++ ninjas, but they can certainly start to develop the skills that will eventually cement lifelong fluency in code.”
In the second paragraph, Koerner quoted that Gibson was able to teach “Rudimentary Java to 8- and 9-year olds.” In the next paragraph, he claims that Gibson was successful in teaching kindergarteners “how to create graph algorithms” and “write a tic-tac-toe program.” Later in the paragraph, Gibson was quoted “Children aged from 5-11 have so much potential for learning about algorithms and computation that it would be a shame to wait until they are teenagers before we teach them the foundations.” This statement appeals to the audience through their feelings, calling it “a shame” to not teach programming principles this early in childhood. If a parent were to read this, they would want their child to learn the principles of programming in school. Quoting Paul Gibson was extremely successful in proving that children can learn the basics of programming principles at a young age.
Toward the end of this article, Koerner brings up some of the other programs that are trying to teach kids how to program. In one of these, “children as young as 4 are using a language called Cherp to make robots perform household chores.” Another “challenges kids to code their own versions of Frogger.” The initiative to teach children to code is gaining speed. It isn’t just a few people here and there that think it is a good idea, it is becoming broader as more research is conducted. This section of the article is especially effective in proving that children are capable of learning programming because he is able to cite specific cases where it has already happened.

In conclusion, this article did a very good job at proving that children can program. Specific sources have been cited that say children have already started programming. Gibson was teaching Java to 8- and 9-year-olds and getting kindergarteners to program tic-tac-toe, while other people were helping kids program their own game, as well as telling robots how to do their chores. Koerner also relates learning programming languages to learning foreign languages, saying that they learn languages so easily because of the way their brains work at such a young age.

Sunday, February 16, 2014

Rhetorical Visual Analysis of Richard's Guide to Software Development

Robert Young
Visual Rhetorical Analysis
English 250
Section PN
Richard’s Guide to Software Development: A Visual Analysis
This image was published in November of 2012 on a website called “Sandra and Woo,” which is an internet site used for web comics like this. Therefore, it would be correct to assume that this piece’s purpose is to entertain: that’s what comics are supposed to do. Most of the people viewing this comic are normal people that have some idea what software development is actually about, but haven’t really been in-depth in the field. For instance, someone who is interested in becoming a software engineer, but hasn’t actually programmed anything, or pretty much anybody else.
In this image, the cat is being used as an analogy for a computer program that has been, or is being, developed. There are several different frames, each one for a different perspective on how a program is made or what a program is like in each stage of development.
In the first frame, the cat is kind of just a sketch, just like when a Software Engineer has the very first idea for his program. You have a basic idea of what it looks like, but not necessarily exactly what it will look like or what it does. It hasn’t actually been started yet, and there will be a lot of work to do, just like a program needs to be developed before it can actually become what it was intended to be. When I went back to look at this later, I noticed that some parts of this first frame are done in great detail, like the head, while others are just barely started, like the legs. This may be because some parts of a program have to be explained a lot for it to make sense, while other parts make sense intuitively.
The second frame is a representation of how much time has been spent on each part of the program. Notice that the larger percentages of time are spent on things that are just kind of off to the side, like the tail and legs instead of the torso, or head, which is kind of like more time was spent on bonus features instead of the main program. This isn’t always a bad thing. Sometimes you get done with the main part of the program, and would like to add some features, but the features are actually more complicated than the main part of the program. Usually programmers use things called functions, and these functions help out the main part of the program. On a cat, the legs help the cat move around. One of the more complicated parts of the cat, the tail, helps keep its balance, which is extremely difficult to simulate, and may take more time to perfect than the rest of the cat. It is things like that you have to take into consideration.
The next two frames go together. One is labeled “How the Software looks before the beta test,” and depicts the cat with its hind legs missing. In the analogy to a computer program, this would mean that some features are missing, but most of the main functionality is there. After the beta test, in the second of these two frames, the missing functions are there again, but now different features are missing. This kind of helps explain that no program is ever complete. Every time you change something, it seems like it caused something else to be broken. In this case, adding the hind legs accidentally removed the front legs.
The first frame in the second row is labeled “How the software is advertised.” It displays a ferocious-looking tiger. This cat does look a lot better than the other cats on the page. It is depicted as a tiger that could supposedly run at up to sixty miles an hour and swallow a small child whole, even though the cat that is illustrated in the rest of the image probably wouldn’t be able to do that. This relates to Software Engineering because software often claims to do things that it actually doesn’t do very well, if at all. From personal experience, some applications on the Windows Store claim to do things that they don’t actually do. I won’t list specific examples because most of those have been fixed now.
The frame with the giant question mark is the one that was most interesting to me. It is labeled “What the customer really wanted.” Since the frame consists mainly of just the ginormous question mark, it indicates that nobody really knows (or cares) what the customer really wanted. They are going to get the cat-program even if they wanted a dog-program or even something completely unrelated, such as a flower-program. This is something that I myself do not necessarily agree with. If Software Engineers are unable to produce exactly what customers want, then why have them? The software engineers have to have something to work towards, even if not everything is explicitly stated for them. What the customers want is known to the Software Engineers, they just might think of a different way to do it than the customer wanted.
The second-to-last frame, the cat with the arm sticking out of its back and the elephant trunk growing out of its nose seems a little out-of-place. To me it looks like features were added that weren’t really wanted (or intended). It is kind of symbolizing a computer bug. It is a side effect that wasn’t expected or intended, but is part of the program anyway. In software engineering, bugs can sometimes be hard to get rid of, and getting rid of them can sometimes lead to more problems. To relate this to the picture, I don’t think this cat would appreciate us chopping off the arm on its back, and it could create a very large mess that would be a pain to get rid of.
The final frame of this strip depicts a human, probably the developer, with the cat. He is happy with what he has created it, even if it is a little bit strange or not what was expected. It shows that software engineers actually care about what they do, even if other people think it is strange. They like their program, even if it isn’t working quite right or looks strange. The “toot” is in their for comedic value, I suppose.
All of these things are more or less true about Software Development, from what I have seen so far. I’m not so sure about the giant question mark about what the customers want, but the rest of the details seem pretty solid. I’ve done my fair share of programming, and I’ve seen most of these things in action.



Works Cited

Knorzer, Oliver, and Powree. “Software Engineering, Now With Cats!” Sandra and Woo. N.p., 12 Nov. 2012. Web. 16 Feb. 2014. http://www.sandraandwoo.com/2012/11/19/0430-software-engineering-now-with-cats/

Monday, February 10, 2014

Software Engineering Visual Communication: Basically, a flow chart.

Since Software Engineers don't use a heck of a lot of visual communication between other software engineers, flow charts and storyboards are all of the things that I could come up with for pictures. Storyboards are like a task list that is put up in a common area for all of the software engineers to see. A flow chart, like the one below, would be used to help other software engineers understand how a particular piece of code works.


This is an example of a flowchart that software engineers would use to help visualize a program. This particular example probably comes from a space shooter or water battle or something like that.

The audience: other software engineers who want to see how the code works or are developing the code themselves. Any other audience would look at this and go "What the heck is this?" If they looked at it a bit longer, they could easily figure out what it is for, but a lot of people won't.

The meaning: There is a lot of things that take place in a single frame of a game. This flowchart is what a program does every 1/60th of a second or so (depending on the speed of the computer). There are a lot of things on this flow chart, and since the first thing on it is "is frame end?" it suggests that this flowchart would execute every single frame of a game.

Wednesday, February 5, 2014

Everything's an Argument Ch 6 Thought Piece

Robert Young
English 250
Section PN
2/5/14
Everything’s an Argument: Chapter 6 Thought Piece
This chapter was all about rhetorical analyses. To be honest, I have done some of these before, and I didn’t think they were much fun, but after reading this chapter I can see how some people could have fun with it. It could almost be like a game, making arguments back and forth, analyzing each other’s writing until one of the sides is defeated. I don’t know if I would like that very much, but I know that some people would really enjoy it.
I think part of the reason that I wouldn’t be good at something like a rhetorical analysis is that I am not very good at coming up with my own arguments. I think part of the reason for this is that I was forced to come up with arguments about things that I didn’t really care anything about in high school, like whether the drinking age should be lower than what it is now or not. I don’t really plan on drinking a whole ton of alcohol, even after I turn 21, so interest on this topic was very low for me, and I didn’t have a lot of fun. However, if we were arguing over something like the impact of violence in video games, I would be a little bit more help. I have played several video games, and a few of them were pretty violent, like Star Wars: Battlefront, or Call of Duty. Even though most of the games that I play aren’t really violent, I would still have more to do with that argument than I would with the drinking age. I guess what I am trying to say is that perspective matters. If you don’t care about something you are arguing for, your arguments will seem weaker automatically.

Anyway, on the topic of the rhetorical analysis itself, I don’t really see the point. I was told in my programming class that things go a lot smoother if you don’t try to figure out why everything works, as long as they do. That completely makes sense to me. If you tried to do a rhetorical analysis on every newspaper article you saw, you would go absolutely insane. We all know that advertisements usually try to get us to buy something, newspaper articles try to inform us, etc. As a computer programmer, I won’t really need to know why advertisements work unless I am designing them myself. I will have to write documentation on any program that I write, but I probably won’t ever have to analyze other people’s writing to see what exactly they are trying to do.