Thinking ISsues: the three p's of capstone project performance
Thinking ISsues: the three p's of capstone project performance
复制标题
思考问题：顶点项目绩效的三个要点
DOI：
10.1145/1595453.1595468
复制
发表时间：
2009
期刊：
影响因子：
--
通讯作者：
T. Clear
中科院分区：
文献类型：
--
作者：
T. Clear
对学生在顶点项目中的表现进行评估会引发一些问题，Fincher及其同事在其优秀的著作中对此进行了很好的阐述。但仍有一些问题有待讨论。经常被选择用于项目评估的工件倾向于将主要重点放在项目工作的结果、结果或“产品“上。当然，在专业背景下，这是关键因素，即项目在工作系统方面提供了预期的结果。然而，这种交付的“工作系统”有多好，以及它能保持多久，是进一步隐藏的“产品”标准？软件专业人员在最后期限的压力下，很容易在设计或代码质量上偷工减料。因此，本应按时按预算交付的系统实际上将在整个使用寿命期间成本激增，由于维护证明是昂贵的和危险的，简单地引入最容易预见的变化-但是，随着开发团队的长期发展，这当然就成了别人的问题.支持系统寿命的设计，软件工程学科自然应该转向“过程”来帮助管理开发并确保一定程度的质量和一致性。然而，这种对过程的依赖也没有被证明是圣杯。阿利斯泰尔·科伯恩的博士论文[2]有力地解释了这一失败的一些原因。方法学家的处方太笼统，太复杂，难以理解，应用起来太麻烦，而且不适合项目团队。作为回应，敏捷运动将主要重点放在“实践”上，通过这些实践，技能和纪律的结合使创造力和创新在开发过程中蓬勃发展，同时保持与“客户”的对话并定期交付高质量的工作软件。然而，这些“做法“本身在应用时需要一定程度的专业技能。一位担任一家大型咨询公司风险管理总监的同事不久前向我透露，他喜欢“敏捷”项目，因为这些项目为他提供了大部分清理“火车残骸”的业务。不管敏捷的有效性如何，在研究背景下的问题是：
Assessment of student performance on capstone projects raises a number of issues, which are well addressed in the excellent book by Fincher and colleagues [1]. Yet some issues still remain to be discussed. The artifacts frequently selected for project assessment tend to place a primary emphasis on result of the project work, the outcome or the " product ". Of course in a professional context that is the key factor, namely that the project delivers it's intended outcome in terms of a working system for instance. Yet how good is that delivered 'working system', and for how long will it remain so, are further hidden 'product' criteria? It is all too easy for software professionals under pressure of deadlines to cut corners on design or code quality. So the system supposedly delivered on time and on budget will actually balloon out in cost over its full lifetime of use, as maintenance proves costly and risky simply to introduce the most readily foreseeable of changes – but then that becomes someone else's problem of course as the development team has long moved on… Given the difficulty of specifying not only functional requirements but maintainability criteria and standards for software designs that support system longevity, it is natural that the software engineering discipline should turn to " process " to help manage development and ensure some degree of quality and consistency. Yet this reliance on process has not proven to be the Holy Grail either. The doctoral thesis by Alistair Cockburn [2] cogently explains some of the reasons for this failure. The methodologists' prescriptions are too generic, too complicated to understand, too cumbersome to apply and not situated in the context of the project team. In response the agile movement have placed primary emphasis on " practices " through which the marrying of skill and discipline enable creativity and innovation to flourish in the development process, while maintaining dialogue with the " customer " and regularly delivering high quality working software. Yet these " practices " in themselves require a degree of professional skill in their application. A colleague who was the Director of Risk Management for a major consultancy firm confided to me not long ago that he loved " agile " projects as they gave him the majority of his business in mopping up " train wrecks'. Regardless of the efficacy of agile, the question in a study context is: …