2.13 Ingeniería de Software (SE)

Ya a principios de la década de 1970, el informático británico Brian Randell supuestamente dijo: "La ingeniería de software es la construcción multi-persona de programas multi-versión". Esta es una visión esencial: mientras que la programación es la habilidad que gobierna nuestra capacidad para escribir un programa, la ingeniería de software es distinta en dos dimensiones: tiempo y personas.

Primero, un proyecto de ingeniería de software es un esfuerzo de equipo; ser un experto en programación solitario es insuficiente. Los ingenieros de software calificados deben demostrar experiencia en comunicación y colaboración. La programación puede ser una actividad individual, pero la ingeniería de software es colaborativa, profundamente ligada a cuestiones de profesionalismo, trabajo en equipo y comunicación.

Segundo, un proyecto de ingeniería de software suele ser "multi-versión". Tiene una vida útil esperada; necesita funcionar correctamente durante meses, años o décadas. Las funcionalidades pueden agregarse o eliminarse para cumplir con los requisitos del producto. El propio equipo de ingeniería probablemente cambiará. El contexto tecnológico cambiará, a medida que evolucionen nuestras plataformas informáticas, cambien los lenguajes de programación, se actualicen las dependencias, etc. Esta exposición a cuestiones de tiempo y cambio es novedosa en comparación con un proyecto de programación: no basta con construir algo que funcione; debe funcionar y seguir funcionando. Muchos de los temas más desafiantes en tecnología comparten "el tiempo conducirá al cambio" como causa raíz: compatibilidad con versiones anteriores, desfase de versiones, gestión de dependencias, cambios de esquema, evolución de protocolos.

La ingeniería de software presenta un desafío particularmente difícil para el aprendizaje en un entorno académico. Dado que las principales diferencias entre la programación y la ingeniería de software son el tiempo y el trabajo en equipo, es difícil generar lecciones que requieran un trabajo en equipo exitoso y que presenten fielmente los desafíos del tiempo. Además, algunos temas de ingeniería de software serán más auténticos y relevantes si nuestros estudiantes experimentan proyectos colaborativos y a largo plazo in vivo en lugar de en el aula. Independientemente de que esto suceda como una pasantía, la participación en un proyecto de código abierto o un rol de ingeniería a tiempo completo, un mes de experiencia práctica a tiempo completo tiene más horas disponibles que el curso promedio de ingeniería de software.

Por lo tanto, un plan de estudios de ingeniería de software debe centrarse en los conceptos necesarios para la mayoría de los nuevos contratados graduados, y que son novedosos para aquellos que se capacitan principalmente como programadores, o que son conceptos abstractos que pueden no declararse/compartirse explícitamente en el trabajo. Tales temas incluyen, entre otros:

Todas las pruebas sugieren que el papel del software en nuestra sociedad seguirá creciendo en el futuro previsible. Además, la era de "dos programadores en un garaje" parece haber llegado a su fin. La mayoría del software importante hoy en día es un esfuerzo de equipo, que se basa en código existente y aprovecha la funcionalidad existente. El estudio de las habilidades de ingeniería de software es un contrapunto profundamente importante a la experiencia cotidiana de los estudiantes de informática: debemos impresionarles con la realidad de que pocos proyectos de software se gestionan escribiendo desde cero como un esfuerzo en solitario. La comunicación, el trabajo en equipo, la planificación, las pruebas y las herramientas son mucho más importantes a medida que nuestros estudiantes pasan del aula y dejan su huella en el mundo.

Aunque la mayoría de los graduados en CS ocuparán un puesto en la industria que requiere este material, los temas del CS Core presentados aquí son valiosos independientemente de si los graduados van a la industria o a la academia.

KA Core Tier1 Core Tier2 Electivo
2.13.1 Colaboración y Dinámica de Equipo     No
2.13.2 Diversidad, Stakeholders y Equipos Distribuidos     No
2.13.3 Control de Versiones y CI/CD     No
2.13.4 Entorno de Desarrollo e IDE     No
2.13.5 Ingeniería de Requisitos     No
2.13.6 Evolución y Estimación de Requisitos     No
2.13.7 Principios y Arquitectura de Software     No
2.13.8 Diseño de API y Modelado     No
2.13.9 Calidad y Evaluación del Diseño     No
2.13.10 Prácticas de Codificación     No
2.13.11 Construcción a Escala y Proceso     No
2.13.12 Conceptos de verificación y validación     No
2.13.13 Planificación y Tipos de Pruebas     No
2.13.14 Prácticas Avanzadas de Pruebas     No
2.13.15 Herramientas y Análisis de Pruebas     No
2.13.16 Pruebas de Rendimiento y Evaluación Comparativa     No
2.13.17 Compatibilidad y Versionado de API     No
2.13.18 Técnicas de Refactorización     No
2.13.19 Conceptos de Confiabilidad     No
2.13.20 Ingeniería de Confiabilidad     No
2.13.21 Métodos Formales     No



Subsecciones
Generado por Ernesto Cuadros-Vargas , Sociedad Peruana de Computación-Peru, basado en el modelo de la Computing Curricula de IEEE-CS/ACM