¿Crees que hay una brecha entre la investigación en informática y los problemas de ingeniería de software? Por ejemplo, ¿los ingenieros de software tienen que preocuparse alguna vez por el "factorización y el isomorfismo gráfico" o por algunos problemas complejos de informática si tienen que ... decir, construir un sitio web de carrito de compras? Probablemente no.
¿Y si hay una desconexión entre la informática y los ingenieros que crean aplicaciones? ¿Es así como deberían existir la ingeniería y la ciencia? ¿Los ingenieros analizarán años y años de trabajos de investigación para resolver un problema particular que tienen?
Edit-1: Después de pensarlo, la ciencia general probablemente tenga el mismo problema. Estoy seguro de que hay importantes químicos que trabajan en compañías como McDonald's y Taco Bell que tienen la tarea de hacer una hamburguesa mejor y más fácil de fabricar.
fuente
Respuestas:
En la mayoría de los puestos de ingeniería de software, los problemas fundamentales de informática rara vez aparecen, por una de dos razones:
La razón por la que tantos ingenieros de software están construyendo sistemas de información que son triviales desde un punto de vista teórico, es simplemente porque son necesarios. La forma en que nuestro mundo está actualmente automatizado es probablemente menos del 0.01% de lo que se podría lograr. Por lo tanto, en las próximas décadas probablemente construiremos principalmente sistemas e interfaces de información. Una vez que tengamos esos, algunos problemas fundamentales comenzarán a aparecer.
Estos problemas existen actualmente, por ejemplo, con respecto a la escalabilidad, el enhebrado, etc., pero son simplemente una parte extremadamente pequeña de todo lo que hay que hacer. Entonces, la razón por la cual las compañías están construyendo sistemas de información relativamente triviales una y otra vez es porque (1) las personas los necesitan y (2) es mucho más fácil (y más lucrativo) que resolver problemas fundamentales.
fuente
Mi experiencia es que el desarrollo de software comercial / práctico va a la zaga de la investigación académica en más de 5 a 30 años. Uno de los plazos más rápidos desde un artículo académico innovador hasta un producto de envío comercial fue SQL. El documento fue publicado en 1969, IBM y otros dedicaron mucho tiempo y esfuerzo a tratar de hacer productos viables, y el primer producto comercialmente viable real fue el software relacional, la compañía ahora llamada Oracle.
Los lenguajes funcionales fueron desarrollados por investigadores en la década de 1960. ¿Cuántos son de uso común hoy? Algunos. En estos días se están usando mucho más que fuera de los muros cubiertos de hiedra de las universidades. Pero tardó tres décadas en hacerlo.
Si. Lo hago todo el tiempo. Cuando trabajaba en una empresa que fabricaba redes de área de almacenamiento, muchos de los productos que comenzaban a enviarse se describieron en documentos de investigación publicados entre 5 y 6 años antes.
Otro ejemplo involucraba un problema llamado "emparejamiento de pacientes". Los humanos son buenos para mirar cosas como
Chem. Dept.oDepartment of Chemistryy determinar que tales cosas son idénticas. La mayoría de los algoritmos tienen dificultades para determinar tales cosas. Estaba trabajando en una empresa que manejaba recetas electrónicas de medicamentos, informes de laboratorio y reclamos de seguros. Hubiera sido útil poder (anónimamente) poder tener datos a largo plazo que cubran la eficacia y efectividad de los tratamientos para los pacientes. Tal cosa habría tenido que depender de la capacidad de determinar la cercanía de las cuerdas. Durante la década de 1990, la mayoría de los investigadores en esta área desaparecieron en el proyecto Genoma Humano, y la mayor parte de su trabajo desapareció de la web (con NDA y propiedad intelectual, todo lo que inventaron estas personas desaparece de la web cuando van a trabajar para la industria privada). Después del 911, los nombres coincidentes se convirtieron en un problema de "seguridad nacional" (hay alrededor de 25 formas de deletrear Mohammed en inglés, y alrededor de una docena de formas de deletrear Osama) y muchos de los restantes también desaparecieron. Así que unoEl inventor / empresa tenía un producto que le permitía relacionar personas y relaciones llamado " analizador de relaciones no obvias " que terminó desapareciendo en un complemento para DB2. Tendrás que cavar mucho en los papeles. Quizás no si haces carros de compras, pero es bastante común hacerlo en otros proyectos.Tesis: detección adaptativa de registros de bases de datos aproximadamente duplicados y el enfoque de integración de bases de datos para el descubrimiento de información .
Biblioteca que implementa algunas de las funciones de la tesis .
fuente
Los informáticos académicos son muy buenos con lo siguiente:
Todo lo anterior son cosas útiles para la ingeniería de software. De hecho, sería indispensable tener al menos un informático en un equipo de ingeniería de software.
Sin embargo, la forma en que se enseña la informática y las reglas de acreditación ABET exacerban el problema (si se puede llamar un problema). Los informáticos no tienen mucho conocimiento de las siguientes áreas clave de ingeniería de software.
Puedo seguir y seguir, pero creo que he hecho mi punto.
La ingeniería de software hoy en día es una disciplina propia que toma prestada de la informática, pero hoy impulsa la tecnología y la vida humana. Realmente necesitas el cerebro de un ingeniero para sobresalir en él. Todos los informáticos no están hechos para ser grandes ingenieros de software. Por supuesto, lo contrario tampoco será cierto.
fuente
De hecho, argumentaría que para construir un buen sitio web de carrito de compras, es absolutamente necesario emplear algoritmos difíciles.
Supongamos que desea predecir los comportamientos de los usuarios en función de compras anteriores. Eso va a tomar mucho más que
a+b=chacerlo de manera efectiva. ¿Qué tal los hábitos de compra basados en una serie de factores diferentes, como la edad, el sexo, la ubicación geográfica, etc.?En mi propia línea de trabajo, uso diario de algoritmos complejos en renderizado, IA, etc.
En resumen, si piensa en una característica específica (es decir, solo un carrito de compras), lo más probable es que esté pensando en implementaciones deficientes. Comience a pensar en implementaciones de google o amazon y estoy seguro de que comenzará a ver dónde sería útil (o obligatorio) saber o al menos estar familiarizado con algoritmos complejos.
fuente
Los ingenieros de software de resolución de problemas tienen una enorme superposición con la investigación en ciencias de la computación, y también con la investigación matemática y estadística.
Diseñar un sitio web no es ingeniería de software, incluso si integra algún código de carrito de compras. Está diseñando.
Incluso la 'codificación' no es necesariamente ingeniería de software: conozco a muchos codificadores que no se considerarían nada acerca de ingenieros aproximados. El código puede ser tan simple como la manipulación de cadenas o escribir fórmulas de Excel.
Obviamente, no toda la ingeniería de software se superpondrá con la investigación científica (hay muchas otras responsabilidades en el trabajo), pero he leído muchos artículos publicados para determinar el algoritmo o enfoque óptimo para los problemas. Estos problemas pueden surgir solo una vez al año (el resto del tiempo estoy escribiendo validación de UI o lo que sea), pero esa es la naturaleza de mi entorno de trabajo.
fuente
No.
Falso. Utilizan herramientas que dependen de que esto se haga correctamente.
De hecho, todas tus relaciones de amigo de amigo en Facebook son un gran problema de teoría de grafos. Muy complejo. Muy grande. Muy teorico.
Si. Algunas personas crean aplicaciones que están claramente descalificadas. He visto muchas cosas realmente de mala calidad construidas por "profesionales" pagados que deberían haber estado haciendo otra cosa, más útil con su tiempo.
"Debería" no tiene sentido. Es la forma en que existe.
Si. A menudo. Por eso me suscribo a la Biblioteca Digital ACM. http://portal.acm.org/ Es esencial para abordar problemas que no son triviales.
fuente