T. Lethbridge, "What Knowledge is Important to a Software Professional,"IEEE Computer, May 2000 (33:5). pp. 44 - 50.
Reports on a survey of the knowledge practicing software developers find useful, and the extent to which they learned it during their formal education rather than on the job. Finds mathematics over-emphasized in formal education relative to its perceived importance on the job.
J. Bentley, "Programming Pearls: Writing Correct Programs," Communications of the ACM, Dec. 1983 (26:12). pp. 1040 - 1045.
Recounts experiences using binary search in classes offered to practicing engineers, and the difficulty they had devising correct pseudocode for it; explores how attention to loop invariants and assertions makes it easier to get the subtle points of the algorithm right.
E. Ciapessoni et al., "From Formal Models to Formally Based Methods: An Industrial Experience," ACM Transactions on Software Engineering and Methodology, Jan. 1999 (8:1). pp. 79 - 113.
Discusses a particular method and its transition from laboratory to industry, with a collection of success stories.
E. Clarke et al., "Formal Methods: State of the Art and Future Directions," ACM Computing Surveys, Dec.1996 (28:4), pp. 626 - 643.
Surveys the formal methods literature as of the mid-1990's, with many synopses of successful applications.
S. Gerhart, D. Craigen, and T. Ralston, "Experience with Formal Methods in Critical Systems," IEEE Software, Jan. 1994. pp. 21 - 28.
Reports in detail on the impact of formal methods on four safety- or security-critical projects, and in less detail on the impact on eight projects in other areas; finds a generally, but not universally, positive impact of using formal methods.
A. Hall, "Using Formal Methods to Develop an ATC Information System," IEEE Software, Mar. 1996. pp. 66 - 76.
A developer describes the use of formal methods in developing an air traffic control subsystem, finding them generally beneficial.
P. Larson, J. Fitzgerald, and T. Brooks, "Applying Formal Specification in Industry," IEEE Software, May 1996 (13:3), pp. 48 - 56.
Describes a head-to-head comparison of the development of a "trusted gateway" system both with and without formal specifications, attributing numerous advantages of the formally-specified system over the informal one to the use of formalism.
S. Pfleeger and L. Hatton, "Investigating the Influence of Formal Methods," IEEE Computer, Feb. 1997 (30:2), pp. 33 - 43.
An independent review of the impact of formal methods on the air traffic control subsystem described by Hall above. While less enthusiastic than Hall, the authors cautiously conclude that use of formal methods in conjunction with other techniques did improve software quality.
A. Sobel, "Empirical Results of a Software Engineering Curriculum Incorporating Formal Methods," Proceedings of the 31st SIGCSE Technical Symposium on Computer Science Education (SIGCSE Bulletin 32:1), Mar. 2000. pp. 157 - 161.
Describes a software engineering curriculum built around six courses involving formal specification and verification techniques. Comparisons of students in this sequence to students in a traditional sequence at the same institution found that the formally trained students better prepared to develop and understand software than the traditionally trained ones.
A. E. K. Sobel and M. R. Clarkson, "Formal Methods Application: An Empirical Tale of Software Development," IEEE Transactions on Software Engineering, Mar. 2002 (28:3). pp. 308 - 320.
Describes an experiment to test whether students of the formal methods curriculum described in the Sobel "Empirical Results..." paper cited above had better "complex problem solving skills" than students from a software engineering program without formal methods but otherwise identical to the first. Teams of students from each group were given an elevator control problem to solve and various measures of the quality of the resulting programs were compared. Most significantly, the formal methods teams (6) all produced correct programs, while only 45.5% of the non-formal-methods teams (5 of 11) did. Measures of conciseness and complexity were not statistically different between the groups.
N. Fenton, S. Pfleeger, R. Glass, "Science and Substance: A Challenge to Software Engineers," IEEE Software, July 1994, pp. 86 - 95.
Points out that a number of software engineering claims, including those for the benefit of formal methods, have not been subjected to experimental confirmation.
D. Butcher and W. Muth, "Predicting Performance in an Introductory Computer Science Course," Communications of the ACM, Mar. 1985 (28:3), pp. 263 - 268.
Correlates the performance of first-semester computer science students in their first course to a variety of background variables, finding ACT math score to be one of the most important performance predictors.
P. Byrne and G. Lyons, "The Effect of Student Attributes on Success in Programming," Proceedings of the Sixth Annual Conference on Innovation and Technology in Computer Science Education, June 2001, pp. 49 - 52.
Correlates various background factors to final exam scores for students in an introductory programming course for non-computing majors at an Irish university. Finds a statistically significant positive correlation between final exam score and scores on a secondary school "leaving exam" in mathematics.
K. Devlin, "The Real Reason Software Engineers Need Math," Communications of the ACM, Oct. 2001 (44:10). pp. 21 - 22.
Points out that mathematics and computer science are related by the importance of abstraction to both, and speculates that education in mathematics should therefore lead to improved ability in computer science.
J. Konvalina, S. Wileman, and L. J. Stephens, "Math Proficiency: A Key to Success for Computer Science Students," Communications of the ACM, May 1983 (26:5), pp. 377 - 382.
Compares students who withdrew from a first computer science course to ones who stayed in it on eight demographic variables (as part of validating a computer science success predictor test developed by the authors), finding that total mathematical background was one of the significant differences between students who withdrew and students who didn't.
M. Stein "Mathematical Preparation as a Basis for Success in CS-II," The Journal of Computing in Small Colleges, Mar. 2002 (17:4), pp. 28 - 38.
Looks at differences in success in CS2 based on a number of background factors, including whether students had taken a discrete math course as opposed to a calculus course, and general mathematical maturity. Finds weak evidence that general mathematical maturity and calculus contribute to success in CS2, but no statistically significant evidence that discrete math does.
B. Wilson and S. Shrock, "Contributing to Success in an Introductory Computer Science Course: A Study of Twelve Factors," Procedings of the 32nd SIGCSE Technical Symposium on Computer Science Education, Feb. 2001, pp. 184 - 188.
Correlates midterm exam score in an introductory computer science course to twelve candidate success predictors, finding that math background was the second most significant predictor.