Featured Columns within the software design and implementation course, this has now rippled forward to a review of the content of our software engineering course, and has caused me to rethink our capstone project. Anne's emphasis has been on Highsmiths's [1] interaction, cooperation and collaboration within the software process. Her students have applied various agile methodologies and techniques as discussed in [1] such as pair programming, SCRUM, and feature driven development. So, in rethinking this process, I find myself wrestling with the core distinctions between programming-in-thesmall and programming-in-the-large. Key questions such as what is programming? come to mind. Is programming the implementation of a design , as my colleague Bob Roggio has recently suggested? Or, is it something else, the core activity of software development, around which a whole series of often confounding models and translation processes have evolved? Then also, what is rigour in the software process? The most agile methods such as extreme programming [5] seem to concentrate on the code, the code and nothing but the code. But without supporting documentation to drive the thinking, and communicate the intentions to project stakeholders such as sponsors, users, development colleagues, future maintainers of the software, and
/lp/association-for-computing-machinery/abet-s-general-accreditation-criteria-to-apply-to-all-computing-BK6BZXazgg