Laboratory airflow visualization. Contact Grading Overview Requirements Objectives Schedule Resources Course_Policies
Laboratory airflow visualization.
Disclaimer. This is an individual page at the Naval Postgraduate School. Disclaimer. It contains links to external sites.
Instructor: Dr. Mark E. Nissen
Office: Ingersoll 310
Telephone: 831-656-3570
E-mail: MNissen@nps.navy.mil
WWW: http://web.www.nps.navy.mil/~menissen
Distance class: M/W 1500 – 1650, Ro-260; lab: W 1700 – 1750, Ro-260.
Residence class: Tu/Th 1000 – 1150, In-267; lab: Th 1200 – 1250, In-267.
Office hours: Tu 1300 – 1400, by appointment, and via e-mail (any time).
Return to Contents
Useful links
These online resources can be helpful, not only for the class, but for your future work in software acquisition.
Acquisition reform
Return to Contents
Software is not only ubiquitous, it is imperative. Information technology is deeply embedded within nearly every high-performance system in use today, and many of the highest-performing weapon systems could not be mission-effective without software. This applies to flight control systems, radar tracking and fire control systems, C4I systems, autonomous mission planning systems, and many others. Even the infantryman is beginning to rely on software for enhanced battlefield performance. Indeed, the software fraction of weapons systems life cycle cost has grown to be quite large, and its fraction is increasing at an increasing rate.
However, when compared with weapon system hardware development, software engineering represents a nascent discipline, which reflects a high variance of methods, tools, technologies and results. Coupled with steadily-increasing computing power, software requirements perennially stretch the technological envelope and are frequently tied to schedules that challenge even the most mature engineering disciplines. Hence, software engineering represents one of the highest risk areas in modern weapon systems development, and its share of program risk increases exponentially with the growing dependence on weapon systems software. This makes embedded weapons systems software a very difficult acquisition problem.
The purpose of this course is to help students learn the most important principles and techniques of software acquisition. The course includes research, education, training and experiential components. Through current research, the instructor brings many of the latest developments in software acquisition and engineering into the classroom and helps students visualize and prepare to manage in the software domain likely to exist over the next 5-10 years. Educationally, the course addresses key principles of software acquisition and takes a process-innovation approach. Students learn how and why software is unique and study both textbook theory and practical cases associated with its acquisition and innovation, in the commercial sector as well as the Department of Defense (DoD). Training involves direct exposure to the DoD processes for software acquisition and assimilation of the best commercial practices and military lessons learned for procurement and program management. Students learn to critique, as well as perform in, the current acquisition system, with an emphasis on anticipating future acquisition reform and effecting process innovation.
The experiential component involves hands-on usage of current techniques and tools employed in software acquisition and direct responsibility for software acquisition and software engineering projects. Students learn to integrate and apply their relevant education and training in an hyper-realistic, demanding environment called TOPGUN. Because every graduate is increasingly likely to be responsible for some aspect of weapons system software acquisition, this course helps to prepare them for their first encounter. Drawing from the TOPGUN school, the students must "train like they fight, and fight like they train." Because so many software acquisitions fail, this education and training can be critical for surviving the first encounter. As in the dogfight, surviving one's first software acquisition represents the key challenge to returning to learn from a second and third.
Click here for image of the B-2 first flight
Return to Contents
Return to Contents
Return to Contents
Return to Contents
Requirements include readings, the TOPGUN project, student synopses, cases, exam and quizzes, participation and lab work.
Students are expected to read all assigned materials in preparation for class. Readings highlighted in bold text on course schedule should be read, and understood, in advance of class. See reading techniques for assistance with this requirement. Readings are listed in their order of priority in the Course Schedule. Other readings listed as references in the Course Schedule provide background, supplementary and reference information. These can be particularly useful to fill gaps in students' backgrounds, prepare for synopses and exams, and pursue areas of specific interest. See instructor for copies.
The project entails team activities involving software acquisition and software engineering. Half of the teams operate as program management offices (PMOs) for Web-based software projects, and the other teams operate as contractors to develop the required software systems. The teams begin the course by taking responsibility for a fielded system (e.g., in PDSS) and spend the first half of the term understanding, validating and updating this IOC software release. But their primary focus in on preparing for implementation of the FOC software upgrade. At the project midpoint, teams switch roles to experience work on the other side of the contract, and students are expected to change jobs at this point as well. The project is not particularly demanding technically, but it requires exactly the same kinds of planning, organization, coordination, technical management, communication, documentation and oversight that are involved in major software development programs; hence, students gain direct experience with both the acquisition and engineering of software and learn first-hand how to manage typical activities (e.g., IPT management, requirements development, software specification, RFP/proposal preparation, analysis and design, testing and debugging, configuration management, documentation, maintenance & support), which can be difficult, even for a technically-simple project!
The project requires a synthesis of the course material, in addition to creative design and evaluation, and it is useful for developing software project-management skills. These represent very high level pedagogical elements according to the Bloom Taxonomy. Written project materials, oral project briefings and work in the IPT environment are designed to help develop communication and group-work skills. Through the project's IPT work, students must learn to lead and influence peers--that is, without necessarily being in charge. In many cases, students must read and understand project-related course materials, concepts and techniques well in advance of their presentation in class. And students must rely on their classmates to develop specialized expertise (e.g., through synopsis preparation). See project guidelines for assistance with the project requirement. Also see the current C-SAWS project Web site.
Synopses are designed for students to acquire specialized expertise necessary for effective software project management. By distributing synopsis topics among the many students in a particular class, they develop different areas of expertise, which contributes to the realism and efficacy of their IPT experiences. Moreover, oral and written communications represent key managerial skills for military, government and business leaders alike. With the predominance of IPTs and advent of oral contracting, critical-listening and interaction skills are now becoming increasingly important in acquisition. To practice and enhance these skills, students work in small (e.g., 2-3 person) teams to prepare synopses of selected course material and present this material to the class. Limited opportunities for extra-credit work are sometimes available through additional synopsis presentations on topics deemed critical by the class. Presenters are expected to effectively communicate the key elements of course material to classmates, whom must in turn interact with the presenters to ensure understanding of and appreciation for the key points. Synopsis topics are critical to effective software program management, of C-SAWS as well as future acquisition programs well beyond the course. See synopsis schedule and guidelines for assistance with this requirement.
Cases are assigned as an integral part of the course readings. The purpose of case analyses is to ground students' course knowledge in historical, current and relevant software programs. This requires the application of concepts, principles, tools and techniques learned in class, in addition to analysis of real-world programs and design of program-management solutions. See case guidelines for assistance with this requirement. One innovation case (listed in the Course Schedule) is thoroughly analyzed and presented by each student. Innovation represents a structured approach to double-loop learning (e.g., thinking "out of the box") and is imperative for leaders and managers in the acquisition environment of today and tomorrow.
The exam tests students' ability to integrate the readings with lectures, cases and discussions and to critically apply the principles, concepts and applications covered in the course. The exam tests students' broad knowledge and understanding at a high level--but also requires detailed understanding of select, key areas--and requires understanding, application, synthesis and some creativity/design--as opposed to short-term memorization and "data dumping." Exams require individual effort and are conducted on an "open book" basis. Most students find the exam to be very challenging, time-consuming and educational.
Quizzes are given periodically—some are announced in advance, some may not be—to test students' point knowledge on specific topics and to reinforce learning in critical areas.
Student participation in class is expected. Participation includes effective discussion in class; quality weighs more heavily than quantity along this dimension. But every student is expected to be prepared to make contributions in each class session. And student questions and points are expected to be informed by the assigned readings. Indeed, if students do not read assigned materials in advance of class and ask informed questions when they do not understand important concepts and points, they are unlikely to pass the course. Students are strongly encouraged to share their operational experiences and insights with the class through relevant discussion.
Students are expected to attend and participate in all lab sessions. These sessions are intended to enable students to acquire and develop "hands on" skills and provide an excellent forum, facility and occasion for students to perform much of their project work. Although a separate grade is not assigned for the lab component of the course, lab work will indirectly affect the students' project grades and be figured directly into the participation grade.
Students require access to a computer equipped with word processing, e-mail and Web browsing software. Some software will be made available in the labs and demonstrated in class, but students are required to locate and learn to use these systems and applications on their own. Web publishing, site-management, ftp and project-management tools are becoming increasingly important for project work. As with every aspect of the course, the instructor remains available and eager to assist when significant problems are encountered.
Click here for image of the Reengineering practice in a pixel.
Return to Contents
The schedule is a Web document that lists each class topic, assigned reading, and due date for every assignment.
Return to Contents
(aka Dr. Mark's Ten Commandments)
Return to Contents
Page updated 11 January 2001.
