CapÃtulo 1 : Ingeniería de software
En el ámbito del desarrollo de software, la ingeniería de software se refiere a un enfoque basado en la ingeniería. En el proceso de desarrollo de software, un profesional conocido como ingeniero de software lleva a la práctica el proceso de diseño de ingeniería.
A pesar de que las frases "programador" y "codificador" son sinónimos de "ingeniero de software", solo se refieren al componente de construcción del trabajo normal de un ingeniero de software.
Un ingeniero de software es responsable de aplicar un proceso de desarrollo de software, que incluye definir, implementar, probar, administrar y mantener sistemas de software, así como crear y actualizar el proceso de desarrollo a través de la aplicación del proceso.
No fue hasta la década de 1960 que la ingeniería de software fue reconocida como un subcampo distinto de la ingeniería.
Se creía que el desarrollo de la ingeniería de software sería un proceso difícil. Los problemas incluían software que no estaba terminado en absoluto o que superaba el presupuesto, superaba los plazos, requería una depuración y un mantenimiento sustanciales y no cumplía con los requisitos de los clientes. A veces, el software ni siquiera estaba terminado.
En 1968, la Organización del Tratado del Atlántico Norte (OTAN) organizó la primera conferencia de ingeniería de software, en la que se discutieron temas relacionados con el software. Con el fin de facilitar la creación de software, se diseñaron pautas y métodos más efectivos.
Varias fuentes diferentes han sido citadas como los orígenes del término "ingeniería de software". "Computers and Automation" publicó una lista de servicios prestados por las corporaciones en la edición de junio de 1965 de la publicación. La palabra fue utilizada de una manera más oficial en la edición de agosto de 1966 de Communications of the Association for Computing Machinery (Volumen 9, número 8) en el artículo "Carta del Presidente a los Miembros de la ACM" escrito por Anthony A. Oettinger. Además de esto, está relacionado con el nombre de una conferencia de la OTAN que se celebró en 1968 y fue dirigida por el profesor Friedrich L. Bauer. Mientras las misiones Apolo estaban en curso, Margaret Hamilton proporcionó una descripción del campo de la "ingeniería de software" con el fin de dar credibilidad a las actividades que se realizaban. El término "crisis de software" se usaba comúnmente para describir la situación en ese momento. Frederick Brooks y Margaret Hamilton pronunciarán los discursos principales en las sesiones plenarias de la 40ª Conferencia Internacional sobre Ingeniería de Software (ICSE 2018), que se celebra para conmemorar el medio siglo del campo de la "Ingeniería de Software".
El Software Engineering Institute (SEI) fue creado en 1984 como un centro de investigación y desarrollo que contaba con el apoyo del gobierno federal. Su sede se encuentra en el campus de la Universidad Carnegie Mellon en Pittsburgh, Pensilvania, en los Estados Unidos de América.
El Programa de Procesos de Software SEI fue establecido por Watts Humphrey con la intención de obtener una comprensión y administrar de manera efectiva el proceso de ingeniería de software. El Modelo de Integración de Madurez de Capacidades para el Desarrollo (CMMI-DEV) se desarrolló como resultado de los Niveles de Madurez de Procesos que se introdujeron inicialmente. Este modelo esbozó la forma en que el Gobierno de los Estados Unidos analiza las capacidades de sus equipos de desarrollo de software.
El Cuerpo de Conocimiento de Ingeniería de Software (SWEBOK) es una compilación de las mejores prácticas contemporáneas para la ingeniería de software que han sido compiladas por el subcomité ISO/IEC JTC 1/SC 7 y publicadas. Estas mejores prácticas son universalmente reconocidas. En general, se acepta que la ingeniería de software es una de las categorías más importantes de computadoras.
Las definiciones significativas de ingeniería de software incluyen las siguientes:
Aún menos oficialmente, la frase también se ha utilizado de la siguiente manera:
La frase "ingeniería de software" fue popularizada por Margaret Hamilton mientras trabajaba en el programa Apolo. El trabajo debe ser considerado tan seriamente como otras contribuciones al crecimiento de la tecnología, y se eligió el término "ingeniería" para reconocer que este debería ser el caso. Hamilton proporciona el siguiente uso del término:
Era la primera vez que alguien había oído hablar del término, al menos no en nuestro mundo, cuando se me ocurrió inicialmente. Había sido una broma durante una cantidad considerable de tiempo. Disfrutaban burlándose de mí por tener nociones tan extremas. El día en que uno de los expertos en hardware más respetados compartió con todo el mundo en una reunión que estaba de acuerdo conmigo en que el proceso de construcción de software también debería considerarse una disciplina de ingeniería, al igual que el proceso de construcción de hardware, fue un día que vivirá mucho tiempo en la memoria. Habíamos conseguido su aceptación y la de los demás en la sala como parte de un campo de la ingeniería por derecho propio, y esto no se debía a que aceptara el nuevo "término" en sí mismo; Más bien, era porque nos habíamos ganado su aceptación.
Existe un gran desacuerdo entre los críticos sobre la definición de ingeniería de software o la legitimidad de la ingeniería de software como materia dentro de la ingeniería. David Parnas ha afirmado que la ingeniería de software es, en realidad, un tipo de ingeniería o ingeniería en general. Este no es el caso, según Steve McConnell, pero cree que debería ser así. La afirmación de que la programación es tanto un arte como una ciencia fue hecha por Donald Knuth. Con respecto a los Estados Unidos de América, Edsger W. Dijkstra afirmó que los términos ingeniería de software e ingeniero de software se habían utilizado en exceso.
El proceso de obtener, analizar, especificar y validar los requisitos de software es lo que se conoce como ingeniería de requisitos. Hay tres opciones para los requisitos de software: dominio, no funcional y funcional.
Los comportamientos previstos, a menudo conocidos como salidas, se describen mediante los requisitos funcionales. Preocupaciones como la portabilidad, la seguridad, la mantenibilidad, la confiabilidad, la escalabilidad, el rendimiento, la reutilización y la flexibilidad son ejemplos de los tipos de cosas que se especifican en los requisitos no funcionales. Estas restricciones se pueden dividir en las siguientes categorías: restricciones de interfaz, restricciones de rendimiento (incluidos aspectos como la velocidad de reacción, la seguridad y el espacio de almacenamiento), restricciones operativas, restricciones del ciclo de vida (incluidas cosas como la portabilidad y la capacidad de mantenimiento) y restricciones económicas. Es necesario tener una comprensión del funcionamiento del sistema o programa para poder expresar adecuadamente las necesidades no funcionales. En el contexto de los proyectos, los requisitos de dominio se refieren a las características que están asociadas con una categoría o dominio en particular.
El proceso de desarrollo de planos de alto nivel para software se conoce como un ejemplo de diseño de software. Hay ocasiones en las que el diseño se divide en niveles:
La programación, también conocida como codificación, pruebas unitarias, pruebas de integración y depuración, son los pasos típicos involucrados en la creación de software. Estos pasos son necesarios para poner el diseño en acción. "Las pruebas de software están relacionadas, pero son distintas de las pruebas de software informático", "Solución de problemas"
En la mayoría de los casos, el programador es el responsable de las pruebas durante esta fase. El objetivo de esta prueba es garantizar que el código funcione de acuerdo con su diseño y determinar cuándo el código está listo para pasar al siguiente nivel de prueba.
El propósito de las pruebas de software es proporcionar a las partes interesadas información sobre la calidad del software que se está probando. Esto se logra a través de una investigación empírica y técnica realizada.
Cuando las pruebas se especifican de una manera distinta de la construcción, a menudo las llevan a cabo ingenieros de pruebas o técnicos de control de calidad en lugar de los programadores responsables de escribirlas. Además de llevarse a cabo a nivel del sistema, se considera un componente de la calidad del programa.
El proceso de estudiar los programas informáticos con respecto a un elemento en particular, como el rendimiento, la solidez o la seguridad, se conoce como análisis de programas.
El mantenimiento de software es el proceso de proporcionar soporte para el software después de su lanzamiento. Puede incluir, entre otros, aspectos como la corrección de errores, la optimización, la eliminación de funciones que no se utilizan o se descartan y la mejora de las funciones que ya existen.
En la mayoría de los casos, el mantenimiento representa entre el cuarenta y el ochenta por ciento del costo total del proyecto.
Tener un conocimiento práctico de programación informática es necesario para seguir una carrera como ingeniero de software. En 2004, la IEEE Computer Society produjo el SWEBOK, que ahora se ha publicado como ISO/IEC Technical Report 1979:2005. Este documento describe el cuerpo de conocimientos que la organización recomienda a un ingeniero de software graduado con cuatro años de experiencia para que pueda comprender.
Un número significativo de ingenieros de...
