Designing uncomplicated software

The Agile Manifesto prescribes less focus on tools and processes, and more focus on human interactions. This is avery important and powerful concept; however, many development organizations have interpreted it in terms ofno procedures and no processes. This is understandable as many activities, such as the design workflow, are thanklessand laborious. When a proper design is missing, the resulting source code may become overly complicated anddifficult to maintain. The software design does not have to be arduous as this workflow can be done without painthrough an adaptation called Responsibility-Driven Design. This adaptation assigns personalities to the internalcomponents of the software to humanize the operation. The new design workflow is completely compatible withagile concepts such as customer interaction, and produces a credible candidate architecture ultimately resulting inthe creation of a less complicated software.El Manifiesto Ágil prescribe disminuir el foco en las herramientas y procesos para centrarlo en las interacciones humanas. Este es un concepto muy importante y potente; sin embargo, muchos equipos de desarrollo lo han traducido en términos de no procedimientos y no procesos. Esto es comprensible ya que muchas actividades, entre ellas el flujo de trabajo del diseño, son ingratas y laboriosas. Cuando no se realiza un diseño apropiado, el resultado puede ser un código demasiado complejo y difícil de mantener. El diseño de un software no tiene que ser arduo y el flujo de trabajo puede aliviarse con una adaptación denominada “diseño conducido por la responsabilidad” (Responsibility-Driven Design). Esta adaptación asigna personalidades a los componentes internos del software para humanizar la tarea. El nuevo flujo de diseño es completamente compatible con los conceptos de agilidad, como la interacción con el cliente, y produce una arquitectura candidata con credibilidad que resultará en la creación de un software no complicado

A life cycle for creating an uncomplicated software

Modern software development life cycle models tend to be less formal and less rigid then Waterfall based models of the past. However, creating software without following even the most basic of plans often results in poorly structured, faulty, and hard to maintain software. This paper proposes a practical development model for the purpose for software development. Following some sort of plan produces better code than no plan at all. This model has been shown to be successful even with inexperienced developers

Metrics to understand future maintenance effort required of a complicated source code

An enduring engineering problem is the creation of a source code too complicated for humans to review and understand. A consequence of a complicated source code is that it requires more effort to be implemented and maintained. Exacerbating the problem is a lack of a proper understanding of exactly what the words “complicated” and “complex” mean, as the definitions of these words are often misconstrued. Some systems are indeed inherently complex, but this does not mean they must be complicated. In our research, several opensource projects were evaluated using software metrics to map the complicatedness of a source code with the ongoing effort to sustain the project. The results of our research show that a relationship exists between a complicated source code and the maintenance effort. It is clear that adhering to proper coding practices and avoiding a complicated code can result in a much more manageable future maintenance effort.Un problema de ingeniería duradero es la creación de código fuente demasiado complicado para que los humanos lo revisen y comprendan. Una consecuencia del código fuente complicado es que requiere más esfuerzo para implementar y mantener. Lo que exacerba el problema es la falta de una comprensión adecuada de lo que significan exactamente las palabras “complicado” y “complejo”, ya que estas definiciones a menudo se interpretan mal. Algunos sistemas son realmente intrínsecamente complejos, pero esto no significa que deban ser complicados. En nuestra investigación, se evaluaron varios proyectos de código abierto utilizando métricas de software para mapear la complejidad del código fuente con el esfuerzo continuo para mantener el proyecto. Los resultados de nuestra investigación muestran que existe una relación entre el código fuente complicado y el esfuerzo de mantenimiento. Está claro que adherirse a las prácticas de codificación adecuadas y evitar el código complicado puede resultar en un esfuerzo de mantenimiento futuro mucho más manejable