UNIDAD 1.

FUNDAMENTOS DE LA INGENIERIA DE SOFTWARE

1.1 DEFINICIONES
La ingeniería de software es una disciplina formada por un conjunto de métodos,
herramientas y técnicas que se utilizan en el desarrollo de los programas
informáticos (software).
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.
1.2 HISTORIA DE LA INGENIERIA DE SOFTWARE
Hoy en día, el software tiene un papel dual. Es producto y canal de distribución de
este. Como producto, ofrece la potencia de cómputo presentada como hardware
de una computadora o, de manera más global por una red de computadoras
accesible mediante hardware local y de acceso físico. Sin importar el lugar en que
resida el software, ya sea en un celular o dentro de una computadora central, éste
es un transformador de información; realiza la producción, el manejo, la
adquisición, la modificación, el despliegue o la transmisión de la información que
puede ser tan simple como un solo bit o tan compleja como una presentación
multimedia. En su papel de vehículo para la entrega de un producto, el software
actúa como la base para el control de la computadora (Sistemas Operativos), la
comunicación de información (redes), y la relación y el control de otros programas
(utilerías de software y ambientes).

PRIMERA ERA
(1950 – 1965)

 Se trabajaba con la idea de “Codificar y Corregir”.

 No existía un planteamiento previo.
 No existía documentación de ningún tipo.
 Existencia de pocos métodos formales y pocos creyentes en ellos.
 Desarrollo a base de prueba y error.
SEGUNDO ERA
(1965 – 1972)

 Se busca simplificar código.

 Aparición de Multiprogramación y Sistemas Multiusuarios.
 Sistemas de Tiempo Real apoyan la toma de decisiones.
 Aparición de Software como producto. (Casas de Software).
 Se buscan procedimientos para el desarrollo del Software.

TERCERA ERA
(1972 – 1985)

 Nuevo Concepto: Sistemas Distribuidos.

 Complejidad en los Sistemas de Información.
 Aparecen: Redes de área local y global, y Comunicadores Digitales.
 Amplio Uso de Microprocesadores.

CUARTA ERA
(1985 - 1995)

 Impacto Colectivo de Software.

 Aparecen: Redes de Información, Tecnologías Orientadas a Objetos.
 Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia
Artificial.
 La información como valor preponderante dentro de las Organizaciones.
QUINTA ERA
(2000 hasta hoy en día)
Utiliza algunos requisitos de las eras anteriores solo que aumenta la
omnipresencia de la web, la reutilización de información y componentes de
software.
 Codificar: Transformar mediante las reglas de un código la formulación de
un mensaje.
 Hardware: Componente físico de la computadora. Por ejemplo: el monitor,
la impresora o el disco rígido. El hardware por sí mismo no hace que una
máquina funcione.
 Multiprogramación: Se denomina multiprogramación a la técnica que
permite que dos o más procesos ocupen la misma unidad de memoria
principal y que sean ejecutados al "mismo tiempo “.
1.3. PRINCIPIOS BASICOS DE LA INGENIERIA DE SOFTWARE
Un principio es una ley importante y es requerida en un sistema de pensamiento.
La práctica de la ingeniería de software se centra en estos siete principios:
Primer principio: La razón que exista todo
Esto responde a la pregunta ¿Esto agrega valor real al sistema?, cada paso o
actividad antes de ponerla en práctica, se tiene que tomar en cuenta si agrega
valor al sistema.
Segundo principio: Mantenerlo sencillo.
Todo sistema debe ser diseñado para ser sencillo, lo más posible. Esto lo hace
más fácil de usar y también mantenible. Sin embargo, esto no quiere decir que
deben descartarse características o que el software tenga errores.
Tiene que ser sencillo, pero bien codificado, es decir cumpliendo su objetivo y con
calidad.
Tercer principio: Mantener la visión.
Tener la visión clara es fundamental en el desarrollo de un software, conocer a
donde se tiene que llegar a las pautas necesarias para tener un concepto del
proyecto. Tener un arquitecto que pueda mantener la visión y que obligue a su
cumplimiento garantiza un proyecto de software muy exitoso.
Cuarto principio: Otros consumirán lo que usted produce.
Al desarrollarse un software, se tiene que tomar en cuenta que alguien será el
usuario o varias personas serán las que ocupen el producto, además habrá
alguien que lo documente, que depure el código o le de mantenimiento e incluso
ampliar el sistema. Por tal motivo como desarrolladores tenemos que construir el
sistema pensando en la audiencia.
Quinto principio: Ábrase al futuro.
El avance tecnológico tanto en hardware como en software se da en meses ya no
en años, por lo cual un dispositivo queda obsoleto al poco tiempo. El software
tiene un tiempo de vida útil lo cual le da valor, sin embargo, pierde este valor por
los cambios que se dan al quedar obsoletas plataformas de hardware u otros
elementos.
Los sistemas que lo logran, son los que se mantienen y que fueron diseñados para
eso, para ello está el principio “Nunca diseñes sobre algo iniciado”.
Sexto principio: Planee por anticipado la reutilización.
La reutilización ahorra tiempo y esfuerzo, pero no hay que llevarlo al extremo
puesto que no puede cumplir con los requerimientos del proyecto principal.
Reutilizar código es beneficios, pero es un reto tener un alto nivel del mismo. Para
esto es necesario planificación y reflexión, utilizando técnicas adecuadas.
Séptimo principio: Pensar
Al pensar en hacerlo es probable que se haga bien, y si sale mal volver a pensar,
esto proporciona conocimientos y experiencia.
Hay que pensar con intensidad aplicándolo a los principios antes mencionados,
esto hará que la recompensa sea enorme.
“Pensar en todo con claridad antes de emprender la acción casi siempre produce
mejores resultados”.
1.4 MODELOS Y PROCESOS
Modelo en cascada o clásico
En ingeniería de software el modelo en cascada―también llamado desarrollo en
cascada o ciclo de vida clásico―se basa en un enfoque metodológico que ordena
rigurosamente las etapas del ciclo de vida del software, esto sugiere una
aproximación sistemática secuencial hacia el proceso de desarrollo del software,
que se inicia con la especificación de requisitos del cliente y continúa con la
planificación, el modelado, la construcción y el despliegue para culminar en el
soporte del software terminado.
Modelo de prototipos
En ingeniería de software, el modelo de prototipos pertenece a los modelos de
desarrollo evolutivo. Este permite que todo el sistema, o algunos de sus partes, se
construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos
en los que se aseguren que el desarrollador, el usuario, el cliente estén de
acuerdo en lo que se necesita así como también la solución que se propone para
dicha necesidad y de esta manera minimizar el riesgo y la incertidumbre en el
desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean
analizados y prescindir de ellos a medida que se adhieran nuevas
especificaciones, es ideal para medir el alcance del producto, pero no se asegura
su uso real.
Este modelo principalmente se aplica cuando un cliente define un conjunto de
objetivos generales para el software a desarrollarse sin delimitar detalladamente
los requisitos de entrada procesamiento y salida, es decir cuando el responsable
no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de
la manera en que interactúa el hombre y la máquina.
Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al
cliente a entender de mejor manera cuál será el resultado de la construcción
cuando los requisitos estén satisfechos.
Modelo en espiral
El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un
modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la
construcción de prototipos con los aspectos controlados y sistemáticos del modelo
en cascada, es decir, cuando se aplica este modelo, el software se desarrolla en
una serie de entregas evolutivas (ciclos o iteraciones), cada una de estas
entregando prototipos más completas que el anterior, todo esto en función del
análisis de riesgo y las necesidades del cliente. Aunque el modelo espiral
representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede
ser muy complicado y por lo cual su uso en el ámbito real es muy escaso.
Modelo de desarrollo por etapas
Es un modelo en el que el software se muestra al cliente en etapas refinadas
sucesivamente. Con esta metodología se desarrollan las capacidades más
importantes reduciendo el tiempo necesario para la construcción de un producto;
el modelo de entrega por etapas es útil para el desarrollo de la herramienta debido
a que su uso se recomienda para problemas que pueden ser tratados
descomponiéndolos en problemas más pequeños y se caracteriza principalmente
en que las especificaciones no son conocidas en detalle al inicio del proyecto y por
tanto se van desarrollando simultáneamente con las diferentes versiones del
código.
En este modelo pueden distinguirse las siguientes fases:
 Especificación conceptual.
 Análisis de requisitos.
 Diseño inicial.
 Diseño detallado (codificación, depuración, prueba y liberación).
 Cuando es por etapas, en el diseño global estas fases pueden repetirse
según la cantidad de etapas que sean requeridas.
 Entre sus ventajas tenemos:
 Detección de problemas antes y no hasta la única entrega final del
proyecto.
 Eliminación del tiempo en informes debido a que cada versión es un
avance.
 Estimación de tiempo por versión, evitando errores en la estimación del
proyecto general.
 Cumplimiento a la fecha por los desarrolladores.
 Modelo incremental o iterativo
 Artículo principal: Desarrollo iterativo y creciente
 Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo
de software, creado en respuesta a las debilidades del modelo tradicional
de cascada, es decir, este modelo aplica secuencias lineales como el
 modelo en cascada, pero de una manera iterativa o escalada según como
avance el proceso de desarrollo y con cada una de estas secuencias
lineales se producen incrementos (mejoras) del software.

Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede
incorporar el paradigma de construcción de prototipos, ya que como se mencionó
anteriormente, este tipo de modelo es iterativo por naturaleza, sin embargo, se
diferencia en que este busca la entrega de un producto operacional con cada
incremento que se le realice al software.
Este desarrollo incremental es útil principalmente cuando el personal necesario
para una implementación completa no está disponible.
Modelo estructurado
Este modelo ―como su nombre lo indica― utiliza las técnicas del diseño
estructurado o de la programación estructurada para su desarrollo, también se
utiliza en la creación de los algoritmos del programa. Este formato facilita la
comprensión de la estructura de datos y su control. Entre las principales
características de este modelo se encuentran las siguientes:
 Generalmente se puede diferenciar de una manera más clara los procesos
y las estructuras de datos.
 Existen métodos que se enfocan principalmente en ciertos datos.
 La abstracción del programa es de un nivel mucho mayor.
 Los procesos y estructuras de datos son representados jerárquicamente.
Este modelo también presenta sus desventajas entre las cuales podemos
mencionar algunas:
 Se podía encontrar datos repetidos en diferentes partes del programa.
 Cuando el código se hace muy extenso o grande su manejo se complica
demasiado.
En el modelo estructurado las técnicas que comúnmente se utilizan son:
 El modelo entidad-relación, esta técnica se relaciona principalmente con los
datos.
 El diagrama de flujo de datos, esta es utilizada principalmente para los
procesos.
Modelo orientado a objetos
Estos modelos tienen sus raíces en la programación orientada a objetos y como
consecuencia de ella gira en torno al concepto de clase, también lo hacen el
análisis de requisitos y el diseño. Esto además de introducir nuevas técnicas,
también aprovecha las técnicas y conceptos del desarrollo estructurado, como
diagramas de estado y transiciones. El modelo orientado a objetos tiene dos
características principales, las cuales ha favorecido su expansión:
Permite la reutilización de software en un grado significativo.
Su simplicidad facilita el desarrollo de herramientas informáticas de ayuda al
desarrollo, el cual es fácilmente implementada en una notación orientada a objetos
llamado UML.

Modelo RAD (rapid application development)

El RAD (rápido application development: ‘desarrollo rápido de aplicaciones’), es un
modelo de proceso de software incremental, desarrollado inicialmente por James
Maslow en 1980, que resalta principalmente un ciclo corto de desarrollo.
Esta es una metodología que posibilita la construcción de sistemas
computacionales que combinen técnicas y utilidades CASE (Computer Aided
Software Engineering), la construcción de prototipos centrados en el usuario y el
seguimiento lineal y sistemático de objetivos, incrementando la rapidez con la que
se producen los sistemas mediante la utilización de un enfoque de desarrollo
basado en componentes.35
Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso
RAD permite que un equipo de desarrollo cree un producto completamente
funcional dentro de un periodo muy limitado de tiempo sin reducir en lo más
mínimo la calidad del mismo.36
Modelo de desarrollo concurrente
El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las
personas actúan simultáneamente o al mismo tiempo. Este tipo de modelo se
puede representar a manera de esquema como una serie de actividades técnicas
importantes, tareas y estados asociados a ellas.
El modelo de proceso concurrente define una serie de acontecimientos que
dispararan transiciones de estado a estado para cada una de las actividades de la
ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se
contempla una inconsistencia del modelo de análisis. Esto genera la corrección del
modelo de análisis de sucesos, que disparara la actividad de análisis del estado
hecho al estado cambios en espera. Este modelo de desarrollo se utiliza a
menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un
sistema cliente/servidor se compone de un conjunto de componentes funcionales.
Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define
actividades en dos dimensiones: una división de sistemas y una división de
componentes. Los aspectos del nivel de sistemas se afrontan mediante dos
actividades: diseño y realización.
La concurrencia se logra de dos maneras:
  Las actividades del sistema y de componente ocurren simultáneamente y
pueden modelarse con el enfoque orientado a objetos descrito
anteriormente;
 Una aplicación cliente/servidor típica se implementa con muchos
componentes, cada uno de los cuales se pueden diseñar y realizar
concurrentemente.
En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de
desarrollo de software y proporciona una imagen exacta del estado actual de un
proyecto. En vez de confinar actividades de ingeniería de software a una
secuencia de sucesos, define una red de actividades, todas las actividades de la
red existen simultáneamente con otras. Los sucesos generados dentro de una
actividad dada o algún otro lado de la red de actividad inicia las transiciones entre
los estados de una actividad.
PROCESOS
Proceso unificado del desarrollo de software
Es de vital importancia seguir un proceso unificado del desarrollo de ingeniería del
software al aplicarlo, esta abarca con el tiempo de vida adherible o esperado.
El proceso en la ingeniería del software es un conjunto de actividades,
herramientas y resultados que harán posible la creación de un producto de
software, puede ser utilizado para una gran cantidad de tipos de sistemas de
software, para diferentes áreas de aplicación, diferentes tipos de organizaciones,
diferentes niveles de competencia y diferentes tamaños de proyectos, la relación
de todo esto cumple con un enfoque disciplinado y responsable que pretende
crear software de muy alta calidad que satisfaga las necesidades de los usuarios
finales, dentro de un calendario y presupuesto predecible.
De esta manera las actividades involucradas en el desarrollo de software, el
mantenimiento que se le dé al mismo, abarcan la vida del sistema desde la
definición de requisitos hasta la culminación de su uso. Todo esto bajo un marco
de referencia llamado modelado de ciclo de vida de software.
Procesos del ciclo de vida
Procesos principales:
 Adquisición
 Suministro
 Desarrollo
 Explotación
 Mantenimiento
 Procesos de la organización (generales)
 Gestión
  Mejora
 Infraestructura
 Formación

Procesos de soporte:
 Documentación
 Gestión de la configuración
 Aseguramiento de la calidad
 Verificación
 Validación
 Revisión conjunta
 Auditoría
 Resolución de problemas
Nuevos procesos:
 Usabilidad
 Evaluación de productos
 Recursos Humanos.
 Gestión de "assets"
 Gestión de petición de cambios
 Gestión del programa de reutilización
 Ingeniería del dominio
El proceso unificado tiene dos dimensiones:
 Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo
de vida del proceso a lo largo de su desenvolvimiento
 Un eje vertical que representa las disciplinas, las cuales agrupan
actividades de una manera lógica de acuerdo a su naturaleza.

La primera dimensión representa el aspecto dinámico del proceso conforme se va

desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).
La segunda dimensión representa el aspecto estático del proceso: cómo es
descrito en términos de componentes del proceso, disciplinas, actividades, flujos
de trabajo, artefactos y roles.
El refinamiento más conocido y documentado del proceso unificado es el RUP
(proceso unificado racional).
El proceso unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos específicos. De
la misma manera, el proceso unificado de racional, también es un marco de
trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del proceso unificado o del
RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
1.5 MEDICION
La medición está totalmente ligada al desarrollo de software, es un aspecto clave
para la planificación y gestión de proyectos, en forma general podemos decir que
es un evaluador para poder generar calidad en el producto final
Validez en la medición para poder efectuar principios generales, expresarlos en
forma numérica o del mundo real.
 Entidad: Objeto que se va caracterizando mediante medición de sus
atributos.
 Atributo: Característica medible de una entidad
 Medición: Proceso donde se le asignan numero o símbolo de resultado a
las entidades
 Medida: Asignación de un símbolo o número a una entidad para
caracterizar un atributo
Un conjunto de valores que permite establecer relaciones entre medidas, se
delimita por un punto de partida y un punto de finalización.
Escala Nominal
Formada por categorías donde no existe ningún orden.
Escala ordinal
Usa categorías y también usa un orden especifico
Escala intervalo
En ingeniería de software es el valor de referencia inicial.
Escala de ratio
Permite llevar un análisis completo, con valores de referencia estableciendo
proporciones.
Escala Absoluta
determina el número de entidades y de personas involucradas, algo más general
Medidas con más profundidad, directas e indirectas
Medidas directas:
Son las que se extraen de la entidad sin necesidad de ningún atributo.

Medidas indirectas:
 son las que dependen de otras medidas
 Medidas objetivas son las que cuyo valor no depende del observador
 Medidas subjetivas son en donde las personas que realiza la medición
introducen valores de resultados
 Las metricas miden adecuadamente el atributo de la entidad a medir,
analisis de cómo se medira.
 Las metricas deben tener unas propiedades para poder estudiar a
profundidad sobre lo que se va hacer
 Las métricas deben ser evaluadas de forma experimental, el método
empírico ayuda a evaluar.
Los tipos de entidades que la ingeniería de software puede medir son:
 Productos: Cualquier artefacto o entregable, resultado de actividades del
ciclo de vida de del software
 Procesos: Todas las actividades generadas en un ciclo de vida, todo se
mide dependiendo del estado del proceso
 Recursos: Cualquier entrada de actividad
 Medidas de tamaño de los sistemas: Indicador de legibilidad del código,
para su facil mantenimiento.
 Medidas de complejidad de software: herramienta para medir la
complejidad del software McCabe Halsted.
 Medida de documentación: Permite precisar la documentación de todo el
ciclo de vida del software
 Medida de reutilización: Reutilización de documentos, recursos, código, etc
 Medidas de eficiencia: medida que garantiza la evaluación de todos los
componentes del sistema
 Medidas relacionadas con el proceso: incluye el tiempo y el esfuerzo
cuando se empieza desarrollar.
 Medidas relacionadas con el recurso: la productividad sera igual al tamaño
sobre el esfuerzo.
 Medición personal: mide a los grupos o equipos del personal.
 IEEE 1061-1998
 GQM (Conjunto de métricas)
 PSM-ISO/IEC 15939