Volume 6, Number 1 - Topics in Software Engineering
Software Engineering principles are taught to cadets at the United States Military Academy at West Point, New York who major or minor in Computer Science. A senior design project is an integral part of two Academy courses. CS407, the first course, is taught to seniors each fall semester. It emphasizes Software Engineering and design principles. Cadets are assigned to project teams and determine specific project requirements with their project advisor. CS408, the second half of the two-course series, is taught to seniors during the winter semester. Students implement and test their project design.
CS407/8, Computer Information Systems Design, is a course with two faces. On one side, it is a Software Engineering course for Computer Science majors. On the other, CS407/8 is an engineering methodology course, which happens to focus on information systems, for cadets who major in the humanities. This duality is the source of unique pedagogical challenges as well as opportunities.
At West Point, all cadets must complete IT105, Introduction to Computing, during their freshman (plebe) year. Central to IT105 is a four-step problem solving process that mimics the engineering thought process (analyze, design, build, and test). The IT105 problem-solving process steps are understanding the problem, designing a solution, writing the code, and testing the code. Since all our students have taken IT105, we use that process to provide a familiar structure to CS407/8. The four major deliverables in CS407/8 are: (1) a requirements specification, (2) a design document, (3) the implementation (code) itself, and (4) a test plan that has been executed by the cadet team involved.
The focus of the first lessons in CS407 is to understand requirements. By the end of the fourth week, instructors have covered the theory of information gathering and systems analysis and have paired cadet teams with their clients so they can immediately apply this newly acquired knowledge to their recently assigned research projects. Instructors check their progress in an informal review, and then let them finish generating their requirements document.
It is essential to force cadets to satisfy the intent of this stage and not just complete a checklist. Most of our cadets are type-A personalities who are not used to slowing down on their way to attacking a problem. They tend to see requirements gathering and systems analysis as an obstacle to be overcome and not as a useful process in its own right. We have found that the teams who make the connection between the requirements document and the rest of their system not only do better, but experience increased satisfaction.
To ensure this stage is handled properly, we use a three-step approach. First, we discuss readings and examples of good and bad requirements. Whenever possible, we use excerpts from the work of previous cadet teams to show current students items that are similar to what they will find in their own projects. Second, we pair teams with their clients immediately, so there is temporal proximity between learning and doing. This just-in-time learning is key to reinforcing the concepts discussed in the classroom. Third, we hold informal, though fairly structured, in-progress reviews to address any questions the cadets may have. We have found that this interim review allows us to find problems and address questions that would not have become apparent until the submission of the final document. It also forces students to get started early.
Through trial and error, we have determined that teams that are the most likely to succeed have a solid design and have done a small amount of exploratory coding at the end of the first semester. Immediately after the requirements specification is due, we teach cadets how to design their systems. Again, this is an application of just-in-time learning aimed at maximizing the applicability of classroom concepts to the cadets' real world problems.
The key difference between this stage and the previous one is that in order to design an implementation cadets must have a solid foundation of knowledge in the technologies and programming languages involved. Therefore, between preliminary and final design, we require cadets to produce a technology prototype. This throwaway artifact is intended to validate the cadets' preliminary design decisions and to demonstrate that each team member is proficient with the core technologies and languages to be used.
The requirement for an individually-graded technology prototype originated from two observations. First, we noticed that cadets would often make poor design decisions because they didn't know much about the tools they would be using. In some cases teams were unable to recover from these early mistakes and could not satisfactorily complete their system. A technology prototype allows teams to validate their decisions early and hopefully avoid costly mistakes.
The second observation leading to the technology prototype deals with what we call the "pizza fetcher" syndrome. The weaker or less aggressive members of many teams became assistants (or "pizza fetchers") to their more proficient teammates. We concluded that this disparity in workloads was due, in many cases, to the misperception that one or more cadets in a team would not be able to write useful code. These same cadets, when forced to perform, invariably produced good programs. Since each cadet has to show basic proficiency, the technology prototype solves this perception problem and allows more equitable and efficient task assignments within teams.
Since we need projects to challenge computer science majors and sequencers (minors), a lot of thought is put into developing a menu of projects that addresses the needs of all cadets. It is relatively easy to determine a project's level of difficulty. If an error is made early on, an instructor can add or remove requirements to ensure the team is challenged, but not overwhelmed. A more difficult need to satisfy is to match problem domains with the backgrounds and interests of cadets. This is particularly important when dealing with cadets who are not computer science majors.
Cadets work on a wide variety of research projects. Many of them produce graduate-level results. Here is a sample of projects from our last two academic years:
Nearly all project teams contain members from several academic disciplines; Computer Science, Electrical Engineering, Mechanical Engineering, Civil Engineering, Systems Engineering, Environmental Engineering, and numerous non-engineering disciplines, for example. This enables cadet teams to analyze problems from several viewpoints. These differing perspectives usually result in a more thorough, and in some cases, more innovative design and implementation.
In order to improve the appeal of a required Computer Science course to Humanities majors, we tailored the nature of several projects to the potential team members. We targeted clients who had projects in the same areas that some of our cadets were majoring. For instance, we presented a project to develop an interactive history time line. Another project, which sought to create an automated return on investment calculator, was appealing to a group of Economics majors. A system that modeled the behavior of a wireless network was attractive to our Mathematics majors because of the probability distribution of the messages traversing the network.
Not all cadets worked on projects, though, that were related to their majors. Some cadets worked on projects related to their chosen military specialties. For instance, cadets on two project teams working to develop systems to track patients for clinics at the local hospital ultimately were commissioned into the Medical Service Corps.
Although set primarily in an academic environment, the senior design projects share many common elements with "real world" software projects. First, students face numerous technical challenges. Projects are designed so that every team is required to learn and apply one or more new technologies in order to complete their project. Second, students have strict schedule requirements. An academic semester is fixed at 16 weeks; all project work must be confined to that time period. Third, students experience management problems. All cadet projects are peer-managed, and like their real world counterparts some projects are managed better than others. Fourth, resources are constrained. And fifth, almost all of the projects are interdisciplinary in nature.
Software projects conducted in an academic environment can provide useful insights for students regarding controlling cost, schedule, and personnel on larger projects and programs. With compressed schedules, resources, and requirements, academic projects are also more sensitive to management changes than other, larger programs and projects. As such, they can become a valuable resource for providing insights into understanding and, hopefully, improving the Software Engineering Process.
LTC Ken Alford is an Assistant Professor teaching Computer Science at the United States Military Academy, West Point, New YORK. He also serves as the department Executive Officer. Ken has spent the past 23 years serving the Army as an automation and acquisition officer in numerous technical and tactical positions. Ken earned a Ph.D. in Computer Science from George Mason University, a Master of Computer Science from the University of Illinois at Urbana-Champaign, an MA degree from the University of Southern California, and a BA degree from Brigham Young University.
MAJ Fernando J. Maymi is an instructor in the Department of Electrical Engineering and Computer Science at the United States Military Academy in West Point, New York. He holds a Masters of Science degree in Computer Science from the Naval Postgraduate School and a Bachelors of Science degree in Computer Science from the United States Military Academy. His research interests include military applications of wireless networks, and network security.
LTC Rachel Borhauer holds a Master of Science degree in Information Systems Engineering fromWestern International University, and a Bachelor of Science degree in Computer Information Systems from Arizona State University. LTC Borhauer is a member of the Computer Science faculty in the Electrical Engineering and Computer Science Department at the United States Military Academy, West Point, New York. She has held a commission in the United States Army for over twenty years, is currently a Lieutenant Colonel. She will be accepting a position as a Program Manager for the United States Army next summer.
Kenneth L. Alford LTC, Ph.D.
Dept of Elec. Eng, and Comp. Sci.
U.S. Military Academy
West Point, NY 10996
Phone: (845) 938-220
[email protected]
URL:
www-external.eecs.usma.edu
![]() |
![]() |
![]() |