Facultad de Energía, las Industrias y los

Recursos Naturales no Renovables

INGENIERIA DE SOFTWARE II

Consulta

Nombre: Jhony Xavier Mendoza Japon

Docente: ING. José Oswaldo Guamán Quinche MSc

Loja - Ecuador
 Conceptos Fundamentales

Actualmente casi todos los países dependen de complejos sistemas

informáticos. Infraestructuras nacionales y utilidades dependen de sistemas
informáticos, y la mayor parte de los productos eléctricos incluyen una computadora y
software de control. La fabricación industrial y distribución esta completamente
informatizada, como el sistema financiero. Por lo tanto, producir software costeable es
esencial para el funcionamiento de la economía nacional e internacional. (Alfonso
Galipienso, Botia Martinez, Moran Lizan, & Trigueros Jover, 2005)

La ingeniería del software es una disciplina cuya meta es el desarrollo constante

de sistemas de software. Este es abstracto e intangible. No esta restringido por
materiales, o gobernado por leyes físicas o por procesos de manufactura. De alguna
forma, esto simplifica la ingeniería de software ya que no existen limitaciones físicas del
potencial del software. Sim embargo, esta falta de restricciones naturales significa que
el software puede llegar a ser extremadamente complejo y, por lo tanto, muy difícil de
entender (Alfonso Galipienso, Botia Martinez, Moran Lizan, & Trigueros Jover, 2005)

Esta disciplina trasciende la actividad de programación, que es la actividad

principal a la hora de crear un software. El ingeniero de software se encarga de toda la
gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con
el presupuesto previsto.

La ingeniería de software, por lo tanto, incluye el análisis previo de la situación,

el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar
su correcto funcionamiento y la implementación del sistema.

Evolución del Software

La industria del software ya tiene casi setenta años y en este período ha realizado
grandes avances, ya que disponemos de lenguajes de programación más sofisticados,
procesos de desarrollo más maduros, y las aplicaciones que se construyen en la
actualidad son más complejas. De hecho, el software forma parte de nuestras vidas,
está en todos los aparatos que manejamos, medios de transporte, sistemas de
telecomunicaciones, equipos médicos, sistemas de administración pública y financieros,
en el arte, en el ocio y en el entretenimiento. En definitiva, como decía Bjarne Stroustrup:
“Our civilization runs on software”. (Piattini)

• Décadas de los 40 y 50, en estas décadas el coste del hardware era

tremendamente superior al del software, que tenía por lo tanto una importancia
relativa mucho menor. Se consideraba además que el software se podía desarrollar
 de la misma forma que se desarrolla el hardware; y, de hecho, los primeros
ingenieros que se ocupaban del software eran los mismos que desarrollaban el
hardware. (Piattini)
• Década de los 60, el software se diferencia demasiado del hardware para poder ser
tratado de la misma manera. Es la época de los famosos “códigos espagueti” (muy
difíciles de entender incluso por quien lo escribía) y la aparición de “héroes” que
después de varias noches sin dormir conseguían arreglar a último minuto el software
para cumplir los plazos marcados. En el NASA/IEEE Software Engineering
Workshop de 1966; y las conferencias de la OTAN en 1968 y 1969, se analizó la
“crisis del software”, y se plantearon ideas fundamentales como “reutilización” o
“arquitectura software”. En 1968 aparece también el artículo de Dijkstra “Go To
Statement Considered Harmful” que impulsó la programación estructurada. (Piattini)
• Década de los 70, en esta década las organizaciones empezaron a comprobar que
los costes del software superaban a los del hardware. Parnas propone la
descomposición modular y el concepto de ocultamiento de información (information
hiding), Chen el modelo E/R y Royce el modelo de ciclo de vida en cascada. La
formación de los profesionales de la Ingeniería del Software se centra entonces en
las metodologías estructuradas (Piattini)
• Década de los 80. Software Engineering Institute (SEI) de la Universidad Carnegie
Mellon, un modelo de madurez de la capacidad software (SW-CMM) que
desarrollaría Watts Humphrey. En cuanto a la tecnología, se automatiza parte del
ciclo de vida del software, apareciendo la conocida como primera generación de
herramientas CASE, y los lenguajes de programación orientados a objetos que, si
bien empezaron a finales de la década de los sesenta con el lenguaje Simula y en
los setenta con Smalltalk, se difundieron sobre todo en la década de los ochenta con
la aparición de C++, Objective-C y Eiffel. La formación de los profesionales del
software requiere entonces el manejo de las herramientas CASE. (Piattini)
• Década de los 90, durante la cual se desarrollan los modelos relacionados con la
mejora de procesos software, como Ideal, TSP o PSP, y las normas y estándares
de calidad como la ISO 9126, ISO 12207, ISO 9000-3, etc. También durante esta
década se consolida la orientación a objetos (OO) como aproximación para el
desarrollo de sistemas informáticos, apareciendo más de cien metodologías, que
terminan dando lugar a la aparición del Lenguaje de Modelado Unificado (UML) y el
Proceso Unificado (UP). También surgen en los noventa y la década siguiente
multitud de técnicas y conocimientos sobre la construcción de sistemas orientados
a objetos: patrones, heurísticas, refactorizaciones, etc. (Piattini)
• Década de los 2000. Se firma el “Manifiesto Ágil” como intento de simplificar la
complejidad de las metodologías existentes y en respuesta a los modelos “pesados”
tipo CMM, y surgen, los métodos híbridos, que buscan un equilibrio, combinando la
adaptabilidad de los ágiles con la formalidad y documentación de los métodos
rigurosos. Actualmente vivimos el auge de este tipo de métodos, especialmente de
Scrum, y ha sido necesario reciclar a los Ingenieros de Software en la “cultura” y
técnicas ágiles. Cabe destacar también que en esta década se difunden el
Desarrollo Software Dirigido por Modelos (DSDM) y las líneas o familias de
productos software, que suponen un esfuerzo al Ingeniero del Software al trabajar
con modelos de alto nivel como elemento principal del desarrollo y mantenimiento
de software. Otro tema relevante es el Desarrollo Distribuido de Software, que
requiere una formación mucho más amplia del Ingeniero de Software, para resolver
problemas como: comunicación inadecuada, diversidad cultural, gestión del
conocimiento o diferencia horaria, entre otros. (Piattini)
• Década de los 2010 En esta década, además de afianzarse las líneas descritas en
las décadas anteriores, estamos asistiendo a una mayor integración entre la
Ingeniería del Software y la Ingeniería de Sistemas -destacando el papel de los
requisitos no funcionales y, sobre todo, de la seguridad-; la importancia de la
“Ciencia, Gestión e Ingeniería de los Servicios” que requiere un enfoque
interdisciplinar (informática, marketing, gestión empresarial, ciencias cognitivas,
derecho, etc.) a la hora de abordar el diseño de los servicios; la necesidad de adaptar
los métodos de desarrollo de software para trabajar en un “mundo abierto” -crucial
cuando nos enfrentamos a dominios tales como la inteligencia ambiental, las
aplicaciones conscientes del contexto, y la computación pervasiva-; los “Sistemas
de Sistemas Intensivos en Software” (SISOS) con decenas de millones de líneas de
código, decenas de interfaces externas, proveedores “competitivos”, jerarquías
complejas, etc. (Piattini)

Mitos del Software

Los mitos del software creencias erróneas sobre éste y sobre el proceso que se
utiliza para obtenerlo se remontan a los primeros días de la computación. Los mitos
tienen cierto número de atributos que los hacen insidiosos. En la actualidad, la mayoría
de profesionales de la ingeniería de software reconocen los mitos como lo que son:
actitudes equivocadas que han ocasionado serios problemas a los administradores y a
los trabajadores por igual (Pressman, 2010)
 Mitos de la administración. Los gerentes que tienen responsabilidades en el
software, como los de otras disciplinas, con frecuencia se hallan bajo presión para
cumplir el presupuesto, mantener la programación de actividades sin desvíos y mejorar
la calidad. Así como la persona que se ahoga se agarra de un clavo ardiente, no es raro
que un gerente de software sostenga la creencia en un mito del software si eso
disminuye la presión a que está sujeto (incluso de manera temporal). (Pressman, 2010)

Tenemos un libro lleno de estándares y procedimientos para elaborar

Mito software.
¿No le dará a mi personal todo lo que necesita saber?
Tal vez exista el libro de estándares, pero ¿se utiliza? ¿Saben de su
existencia los trabajadores del software? ¿Refleja la práctica moderna
Realidad de la ingeniería de software? ¿Es completo? ¿Es adaptable? ¿Está
dirigido a mejorar la entrega a tiempo y también se centra en la calidad?
En muchos casos, la respuesta a todas estas preguntas es “no”.

Si nos atrasamos, podemos agregar más programadores y ponernos al

Mito corriente
(en ocasiones, a esto se le llama “concepto de la horda de mongoles”).
El desarrollo del software no es un proceso mecánico similar a la
manufactura. En palabras de Brooks [Bro95]: “agregar personal a un
proyecto de software atrasado lo atrasará más”. Al principio, esta
afirmación parece ir contra la intuición. Sin embargo, a medida que se
Realidad
agregan personas, las que ya se encontraban trabajando deben dedicar
tiempo para enseñar a los recién llegados, lo que disminuye la cantidad
de tiempo dedicada al esfuerzo de desarrollo productivo. Pueden
agregarse individuos, pero sólo en forma planeada y bien coordinada.

Mitos del cliente. El cliente que requiere software de computadora puede ser la
persona en el escritorio de al lado, un grupo técnico en el piso inferior, el departamento
de mercadotecnia y ventas, o una compañía externa que solicita software mediante un
contrato. En muchos casos, el cliente sostiene mitos sobre el software porque los
gerentes y profesionales de éste hacen poco para corregir la mala información. Los
mitos generan falsas expectativas (por parte del cliente) y, en última instancia, la
insatisfacción con el desarrollador. (Pressman, 2010)
 Para comenzar a escribir programas, es suficiente el enunciado general
Mito
de los objetivos —podremos entrar en detalles más adelante.
Aunque no siempre es posible tener el enunciado exhaustivo y estable
de los requerimientos, un “planteamiento de objetivos” ambiguo es una
receta para el desastre. Los requerimientos que no son ambiguos (que
Realidad
por lo general se obtienen en forma iterativa) se desarrollan sólo por
medio de una comunicación eficaz y continua entre el cliente y el
desarrollador

Los requerimientos del software cambian continuamente, pero el cambio

Mito
se asimila con facilidad debido a que el software es flexible.
Es verdad que los requerimientos del software cambian, pero el efecto
que los cambios tienen varía según la época en la que se introducen.
Cuando se solicitan al principio cambios en los requerimientos (antes de
que haya comenzado el diseño o la elaboración de código), el efecto
Realidad sobre el costo es relativamente pequeño.16 Sin embargo, conforme
pasa el tiempo, el costo aumenta con rapidez: los recursos ya se han
comprometido, se ha establecido la estructura del diseño y el cambio
ocasiona perturbaciones que exigen recursos adicionales y
modificaciones importantes del diseño.

Mitos del profesional. Los mitos que aún sostienen los trabajadores del
software han sido alimentados por más de 50 años de cultura de programación. Durante
los primeros días, la programación se veía como una forma del arte. Es difícil que
mueran los hábitos y actitudes arraigados. (Pressman, 2010)

Una vez que escribimos el programa y hacemos que funcione, nuestro

Mito
trabajo ha terminado.
Alguien dijo alguna vez que “entre más pronto se comience a ‘escribir el
código’, más tiempo tomará hacer que funcione”. Los datos de la
Realidad
industria indican que entre 60 y 80% de todo el esfuerzo dedicado al
software ocurrirá después de entregarlo al cliente por primera vez.

Hasta que no se haga “correr” el programa, no hay manera de evaluar

Mito
su calidad
Uno de los mecanismos más eficaces de asegurar la calidad del
Realidad software puede aplicarse desde la concepción del proyecto: la revisión
técnica. Las revisiones del software (descritas en el capítulo 15) son un
 “filtro de la calidad” que se ha revelado más eficaz que las pruebas para
encontrar ciertas clases de defectos de software

El único producto del trabajo que se entrega en un proyecto exitoso es

Mito
el programa que funciona.
Un programa que funciona sólo es una parte de una configuración de
software que incluye muchos elementos. Son varios los productos
Realidad terminados (modelos, documentos, planes) que proporcionan la base de
la ingeniería exitosa y, lo más importante, que guían el apoyo para el
software.

La ingeniería de software hará que generemos documentación

Mito
voluminosa e innecesaria, e invariablemente nos retrasará
La ingeniería de software no consiste en producir documentos. Se trata
Realidad de crear un producto de calidad. La mejor calidad conduce a menos
repeticiones, lo que da como resultado tiempos de entrega más cortos.

Preguntas Frecuentes

¿Qué es Software?

Todos los documentos asociados y la configuración de datos que se necesita

para hacer que estos programas operen de manera correcta. Por lo general, un sistema
de software consiste en diversos programas indispensables, archivos de configuración
que se utilizan para ejecutar estos programas. (Alfonso Galipienso, Botia Martinez,
Moran Lizan, & Trigueros Jover, 2005)

¿Qué es la Ingeniería de Software?

Es una disciplina de la ingeniería que comprende todos los aspectos de la

producción de software desde las etapas iniciales de la especificación del sistema, hasta
el mantenimiento de este después de que se utiliza (Alfonso Galipienso, Botia Martinez,
Moran Lizan, & Trigueros Jover, 2005)

¿Cuál es la diferencia entre ingeniera de software y ciencia de la computación?

Esencialmente, la ciencia de la computación se refiere a las teorías y métodos

subyacentes a las computadoras y lo sistemas de software, mientras que la ingeniería
de software se refiere a los problemas prácticos de producir software. Los Ingenieros de
software requieren ciertos conocimientos de ciencia de la computación, de la misma
forma que los ingenieros eléctricos requieren conocimiento de física (Alfonso
Galipienso, Botia Martinez, Moran Lizan, & Trigueros Jover, 2005)

¿Cuál es la diferencia entre ingeniería de software e ingeniería de sistemas?

La ingeniería de sistemas se refiere a todos los aspectos de desarrollo y de la

evolución de sistemas complejos donde el software desempeña un papel principal. Por
lo tanto, la ingeniería de sistemas comprende el desarrollo de hardware, políticas y
procesos de diseño y distribución de sistemas, así como la ingeniera de software.
(Alfonso Galipienso, Botia Martinez, Moran Lizan, & Trigueros Jover, 2005)

¿Qué es un proceso del Software?

Es un conjunto de actividades y resultados asociados que producen un producto

de software. Estas actividades son llevadas a cabo por los ingenieros de software.
Existen cuatro actividades fundamentales de procesos: Especificación del software,
Desarrollo del software, Validación del software y Evolución del software (Alfonso
Galipienso, Botia Martinez, Moran Lizan, & Trigueros Jover, 2005)

¿Cuáles son los costos de la ingeniería del software?

No existe una respuesta sencilla a esta pregunta ya que la distribución de costos

a través de las diferentes actividades en el proceso del software depende del proceso
utilizado y del tipo de software que se vaya a desarrollar. Un ejemplo el software en
tiempo real normalmente requiere validación y pruebas más extensas que lo sistemas
basados en web (Alfonso Galipienso, Botia Martinez, Moran Lizan, & Trigueros Jover,
2005)

¿Qué es un CASE?

Comprende un amplio abanico de diferentes tipos de programas que se utilizan

para ayudar a las actividades del proceso del software, como el análisis de
requerimientos, el modelado de sistemas, la depuración y las pruebas, en la actualidad
estas herramientas incluyen un generador de código que automáticamente genera
código fuente a partir del modelo del sistema y algunas guías de proceso para el
ingeniero de software

Referencias

Alfonso Galipienso, M. I., Botia Martinez, A., Moran Lizan, F., & Trigueros Jover, J. P.
(2005). Ingenieria del Software. Obtenido de Ingenieria de software.Septima
Edicion:
 http://zeus.inf.ucv.cl/~bcrawford/AULA_ICI_3242/Ingenieria%20del%20Softwar
e%207ma.%20Ed.%20-%20Ian%20Sommerville.pdf

Piattini, M. (s.f.). Evolución de la Ingeniería del Software y la formación de profesionales.

Obtenido de REVISTA INSTITUCIONAL DE LA FACULTAD DE INFORMÁTICA
| UNLP:
http://sedici.unlp.edu.ar/bitstream/handle/10915/57358/Documento_completo.p
df-PDFA.pdf?sequence=1&isAllowed=y

Pressman, R. S. (2010). Ingenieria de Software . Obtenido de Ingenieria de Software Un

enfoque practico: http://cotana.informatica.edu.bo/downloads/ld-
Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF