Unc-method: un método de desarrollo de software basado en problemas

Abstract

Los ingenieros de software emplean los métodos de desarrollo para garantizar la entrega puntual, el cumplimiento de los presu-puestos y la calidad de las aplicaciones de software. Existen dos tipos de métodos de desarrollo: los dirigidos por planes, y los á-giles. Ambos, aún presentan problemas: se refieren a la solución en lugar de pensar en el problema, usan artefactos formales o semiformales y dejan el manejo de la consistencia en manos de los analistas. En este artículo se define UNC-Method, un méto-do de desarrollo de software basado en problemas, que se viene desarrollando en la Universidad Nacional de Colombia y que se usa en la Escuela de Sistemas como parte del entrenamiento en desarrollo metodológico de software a los estudiantes de di-cha universidad durante los últimos cinco años. UNC-Method combina artefactos tradicionales del desarrollo de software (como los diagramas de UML y las interfaces gráficas de usuario) con enfoques no tradicionales en dicha disciplina (como los diagra-mas causa-efecto, los diagramas de objetivos de KAOS y los esquemas preconceptuales) en un esfuerzo por resolver los proble-mas antes mencionados. Además, se ejemplifica el método con un caso de estudio.

Software engineers use development methods to guarantee on-time delivery, keeping to budget and quality in their software applications. There are two kinds of development methods: plan-driven and agile methods. Both of them still have problems; these refer to resolving problems instead of thinking about them, they use informal or semi-formal artefacts and they leave consis-tency management to the analysts. The UNC-method (a problem-based software development method) is defined in this paper. The UNC-method is currently being developed in the Universidad Nacional de Colombia; it has been used by students from the School of Systems as part of their training in methodological software development during the last five years. The UNC-method is a mixture of well-known artefacts (i.e. UML diagrams and graphical user interfaces) and non-traditional approaches (e.g. cause-and-effect diagram, KAOS goal diagrams and pre-conceptual schemas) used in trying to overcome the aforementioned pro-blems. A case study is also used for exemplification purposes.