Hi,
Although this is the second post, it is the first substantive one. This blog should concern CS 460. As this is my first time blogging, I shall presume that the action entails dumping here any and all that goes through my mind pertaining to the topic at hand. Evidently, this is a popular undertaking, though I scarcely discern why. At any rate, the intention is to document my exploits in this, which is to be a software engineering class; I am sure it will serve the purpose, and anyway writing often helps one organize one's thoughts.
The first (and only) item on the agenda concerns my impressions of the Wikipedia article "Software engineering". I think this is best divided into parts, broken down logically below.
My understanding of software engineering involved the design and some aspects of creating large software. It was my understanding that software engineering involved designing a project to be robust, suited to the topic at hand, and modular. Further, when constructing software, tests are built into additional modules developed parallel to the code itself. I have some criticisms concerning some of these aspects, but for now I shall hold my peace.
Most of these perceptions developed from CS 351, which I took Fall 2011. The salient Wikipedia definition calls software engineering the "systematic approach to the analysis, design, assessment, implementation, test[ing], maintenance and reengineering of software". This appears to be a complete definition of the term. The rest of the article is not divided into describing each of these sections. Instead, the topic is approached and viewed from different perspectives (historical, comparative, etc.), all mostly agreeing with my assessments from CS 351. In light of this, I would like to select the points that add to my definition provided in the previous paragraph.
1. Software engineering emerged out of necessity; apparently, programmers couldn't keep track of their increasingly complex programs. Although the article is somewhat vague, I assume the creation of the field emerged as a formalization of various tricks of the trade (for example: putting-code-in-objects-like-functions-and-data-structures-to-avoid-code-reuse becomes "encapsulation"). Also presumably, coders needed an assumed system for how things are done (well of course you store you put all the polygon data in a VBO class--how else would I know how to use it?!). This latter point expands on introductory material presented in CS 351.
2. The profession of being a software engineer is rather roughly defined in the Wikipedia article, but there are at least varying standards and certifications around the world. Also, apparently, fatal on-the-job accidents are rare. Just in case, retrofit your computer with airbags. Outsourcing is less of a problem. From what I have heard from my friends in industry, contract programmers in other countries habitually write very bad code. Perhaps this is why software engineering isn't outsourced--because it can't be. Maybe I'm just being uncharacteristically nationalistic.
3. Software engineering is often bundled with computer science in popular impression and in curricula. While they are in fact similar and related, they are different fields of study. It is my opinion that UNM's computer science program mixes the two rather too much.
4. There is a helpful list of subdisciplines which I found instructive. As of today, they are software requirements, design, construction, testing, maintenance, configuration management, engineering management, process, tools and methods, and quality. Descriptions thereof may be found at the article.
That's all for now. Farewell,
Ian
No comments:
Post a Comment