Ingeniería de

Software

Ing. Fabricio Medina Palacios, MDPR

 ¿Qué es el Software?
Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos
asociados, que forman parte de las operaciones de un sistema de computación. IEEE 729 [5]
 ¿Qué es el Software?

Según Pressman, R. 2010 “El software de computadora es el producto que construyen los
programadores profesionales y al que después le dan mantenimiento durante un largo tiempo.
Incluye programas que se ejecutan en una computadora de cualquier tamaño y arquitectura,
contenido que se presenta a medida de que se ejecutan los programas de cómputo
e información descriptiva tanto en una copia dura como en formatos virtuales que engloban
virtualmente a cualesquiera medios electrónicos.
La ingeniería de software está formada por un proceso, un conjunto de métodos (prácticas) y
un arreglo de herramientas que permite a los profesionales elaborar software de cómputo de
alta calidad.”
¿Qué se entiende por Ingeniería del Software?

“Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño y

construcción de programas de computadora y la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción
de software“ - B. Bohem

En esta definición del proceso de desarrollo Software, se introduce como parte inherente del
producto a obtener, la perspectiva de las necesidades de usuario a las que debe dar respuesta:
“Aquellos en los que las necesidades del usuario se traducen en requerimientos, estos se
transforman en diseño y este a su vez se implementa en código que es probado, documentado y
certificado para su uso” - G. Booch, I. Jacobson, y J. Rumbaugh [6]
¿Qué se entiende por Ingeniería del Software?

En la siguiente, se introducen los conceptos de rentabilidad y fiabilidad y la operatividad en entornos

reales: “La Ingeniería del Software trata del establecimiento de los principios y métodos de la
ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales.” -
F. L. Bauer [7]

Y según otra de las definiciones que aporta la IEEE, se introduce el concepto de cuantificación del
proceso:

1) La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y

mantenimiento del software; es decir, la aplicación de ingeniería al software. 2) El estudio de
enfoques como en (1). - IEEE 610.12 [5]
¿Qué es Ingeniería del Software?

Como compendio de los conceptos barajados en las definiciones expuestas se propone la

siguiente definición de I. del Software:

“La aplicación práctica, sistemática, disciplinada y cuantificable del conocimiento científico

para realizar el análisis de las necesidades del usuario y obtener el software y la
documentación asociada requerida para su desarrollo, operación y mantenimiento de manera
rentable, fiable, certificada y que opere en máquinas reales.”
¿Qué es Ingeniería del Software?

La ingeniería de software es una

especialidad que consiste en sistemas,
instrumentos y técnicas que se emplean en
el desarrollo de los programas informáticos.
¿Conceptos Básicos de la Ingeniería del Software?

Esta especialidad manifiesta la actividad del programa, que es la labor fundamental para el
momento de la creación de un software.
La ingeniería de software, también, incorpora el análisis precedente de la situación, el bosquejo
del proyecto, el desarrollo del software, el ensayo necesario para comprobar su funcionamiento
correcto y poner en funcionamiento el sistema.
.
¿Conceptos Básicos de la Ingeniería del Software?

El ingeniero de software se ocupa de toda la gestión del proyecto para que éste pueda
evolucionar en un lapso de tiempo determinado y con los recursos previsto para el proyecto.

Los Ingenieros de Software deben:

 Adoptar un enfoque sistemático para la realización de su trabajo.
 Emplear los instrumentos y tecnología adecuados, para dar con la solución del problema
planteado, según las limitaciones de desarrollo y a los recursos disponibles.
.
La ingeniería de software aplica diferentes normas y métodos que permiten obtener mejores
resultados, en cuanto al desarrollo y uso del software, mediante la aplicación correcta de estos
procedimientos se puede llegar a cumplir de manera satisfactoria con los objetivos
fundamentales de la ingeniería de software.

Entre los objetivos de la ingeniería de software están:

• Mejorar el diseño de aplicaciones o software de tal modo que se adapten de mejor manera a
las necesidades de las organizaciones o finalidades para las cuales fueron creadas.
• Promover mayor calidad al desarrollar aplicaciones complejas.
• Brindar mayor exactitud en los costos de proyectos y tiempo de desarrollo de los mismos.
.
• Aumentar la eficiencia de los sistemas al introducir procesos que permitan medir mediante
normas específicas, la calidad del software desarrollado, buscando siempre la mejor calidad
posible según las necesidades y resultados que se quieren generar.
• Una mejor organización de equipos de trabajo, en el área de desarrollo y mantenimiento de
software.
• Detectar a través de pruebas, posibles mejoras para un mejor funcionamiento del software
desarrollado.
Mejorar el diseño de aplicaciones o software
de tal modo que se adapten de mejor manera
a las necesidades de las organizaciones o
finalidades para las cuales fueron creadas.
Promover mayor calidad al desarrollar
aplicaciones complejas.
Brindar mayor exactitud en
los costos de proyectos y
tiempo de desarrollo de
los mismos.
Brindar mayor exactitud en
los costos de proyectos y
tiempo de desarrollo de
los mismos.
Aumentar la eficiencia de los
sistemas al introducir procesos que
permitan medir mediante normas
específicas, la calidad del software
desarrollado, buscando siempre la
Institute of Electrical and Electronics
mejor calidad posible según las Engineers
necesidades y resultados que se
quieren generar.
Una mejor organización de equipos
de trabajo, en el área de desarrollo
y mantenimiento de software.
Detectar a través de pruebas,
posibles mejoras para un mejor
funcionamiento del software
desarrollado.
 Realizar un proyecto de software no es tan fácil, es por esto que se emplean modelos de procesos
del software, existe una estructura general de ingeniería de software que consta de cinco
actividades comunicación, planeación, modelado, construcción y despliegue; pero están
actividades forman parte de la base para la creación de nuevos modelos de procesos, puesto que
un modelo no es aplicable para todo tipo de proyecto.

 El desarrollo de un software es un proceso que no solo permite cumplir el objetivo de

desarrollarlo, sino que también es un proceso de aprendizaje reiterativo, ya que permite
documentar la información además de construir un software de calidad.

 Anteriormente no existía un modelo de proceso, pero con el pasar del tiempo fueron
inventado modelos de modo que se permita al desarrollador llevar un orden de desarrollo y
como todo producto tiene un proceso, el software, al ser un producto también lo tiene, en
este apartado estudiaremos el proceso general de un software y el modelo de proceso
prescriptivo cascada.
Proceso del software
Es importante antes de comenzar definir ¿qué es un proceso?; un proceso es una serie de
pasos a seguir, que permite mantener el control, estabilidad y organización para las actividades,
desde el punto de vista técnico el proceso de un software se define como una estructura que
define actividades, métodos y herramientas con el fin de obtener un software de calidad.
Un proceso de software efectivo habilita a la organización a incrementar su productividad al
desarrollar software.
Modelo de proceso general
La ingeniería de software incorpora cinco actividades generales: comunicación, planeación,
modelado, construcción y despliegue, estas actividades están conformadas por actividades
sombrilla; las actividades sombrilla están dentro de las actividades generales y contribuyen al
desarrollo del software, ya que permiten dar seguimiento, control y administración asegurando
así la obtención de un producto de calidad.
El proceso del software tiene las siguiente características:
Modelo de proceso general
El proceso del software tiene las siguientes características:
 Flujo de proceso
En el flujo de proceso se describe el orden de cómo se van a ejecutar las actividades y también
se describe el tiempo que va durar cada actividad. Hay tres tipos de flujo de proceso
 Flujo de proceso lineal
El flujo de proceso lineal se realiza en una secuencia que empieza desde la comunicación hasta
y termina en el despliegue.
 Flujo de proceso iterativo
Dentro del flujo de proceso iterativo se repiten las actividades una y otra vez mientras sea
necesario para avanzar con la siguiente actividad.
 Flujo de proceso evolutivo
Las actividades son ejecutadas en forma circular y en cada círculo que realice es
una versión mejorada del producto.
.
 Flujo de proceso en paralelo
Ejecuta una o dos actividades en paralelo, es decir al mismo tiempo que se ejecuta otra
actividad
El proceso requiere una metodología con 5 etapas:

1. Análisis de requerimientos: Se extraen los requisitos del producto de software. En esta

etapa la habilidad y experiencia en la ingeniería del software es crítica para reconocer
requisitos incompletos, ambiguos o contradictorios. Usualmente el cliente/usuario tiene
una visión incompleta/inexacta de lo que necesita y es necesario ayudarle para obtener la
visión completa de los requerimientos. El contenido de comunicación en esta etapa es
muy intenso ya que el objetivo es eliminar la ambigüedad en la medida de lo posible.
2. Especificación: Es la tarea de describir detalladamente el software a ser escrito, de una
forma rigurosa. Se describe el comportamiento esperado del software y su interacción con
los usuarios y/o otros sistemas.

3. Diseño y arquitectura: Determinar como funcionará de forma general sin entrar en detalles
incorporando consideraciones de la implementación tecnológica, como el hardware, la red,
etc. Consiste en el diseño de los componentes del sistema que dan respuesta a las
funcionalidades descritas en la segunda etapa también conocidas como las entidades de
negocio. Generalmente se realiza en base a diagramas que permitan describir las
interacciones entre las entidades y su secuenciado.
4. Programación: Se traduce el diseño a código. Es la parte más obvia del trabajo de
ingeniería de software y la primera en que se obtienen resultados «tangibles». No
necesariamente es la etapa más larga ni la más compleja aunque una especificación o
diseño incompletos/ambiguos pueden exigir que, tareas propias de las etapas anteriores se
tengan que realizarse en esta.

5. Prueba: Consiste en comprobar que el software responda/realice correctamente las tareas

indicadas en la especificación. Es una buena praxis realizar pruebas a distintos niveles (por
ejemplo primero a nivel unitario y después de forma integrada de cada componente) y por
equipos diferenciados del de desarrollo (pruebas cruzadas entre los programadores o
realizadas por un área de test independiente).
6. Documentación: Realización del manual de usuario, y posiblemente un manual técnico con
el propósito de mantenimiento futuro y ampliaciones al sistema. Las tareas de esta etapa
se inician ya en el primera fase pero sólo finalizan una vez terminadas las pruebas.
7. Mantenimiento: En esta etapa se realizan un mantenimiento correctivo (resolver errores) y
un mantenimiento evolutivo (mejorar la funcionalidades y/o dar respuesta a nuevos
requisitos).
¿Son 5 o 7 etapas?. No es un error. La sexta etapa, documentar, se tiene que llevar a cabo
absolutamente en todas y aunque no es una etapa propiamente dicha pero es tan importante
que debe ser mencionada explícitamente.
Por último la etapa del mantenimiento, sobre todo para ampliar el sistema con nuevas
funciones, debe tener las «subetapas» 1 a 5 si se quiere abordar con garantías.
 En ingeniería del software y el desarrollo de sistemas, un requerimiento es una necesidad
documentada sobre el contenido, forma o funcionalidad de un producto o servicio.

Los requerimientos son declaraciones que identifican atributos, capacidades, características

y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga
valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué
elementos y funciones son necesarias para un proyecto.

En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los

requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida
por la etapa de diseño del sistema/software.
Características de los requisitos del Software
La recogida de requisitos de sofware es la fundación de la totalidad del proyecto de desarrollo
software. Por ello, debe de ser clara, correcta y bien definida.
Una completa especificación de requisitos Software debe ser:

• Clara • Verificable
• Correcta • Priorizada
• Consistente • Sin ambigüedades
• Coherente • Trazable
• Comprensible • Origen creíble
• Modificable
Ingeniería de requisitos
El proceso de recogida de información, análisis y documentación sobre los requisitos software
des del cliente, se conoce como ingeniería de requisitos. El objetivo de este tipo de Ingeniería es
el de desarrollar y mantener un documento de especificación de requisitos del sistema de forma
sofisticada y descriptiva.
Proceso de la Ingeniería de requisitos
Es un proceso que consta de cuatro pasos:
 Estudio de viabilidad
 Recogida de requisitos
 Requisitos del Software
 Validación de los requisitos de Software
Estudio de viabilidad
Cuando el cliente se acerca a la organización para obtener el producto deseado desarrollado,
expone una idea aproximada de las funciones que el software debe cumplir y qué características
se esperan del mismo.
Refiriéndose a esta información, los analistas elaboran un estudio detallado sobre la viabilidad
del sistema deseado y de sus funcionalidades, para proceder a desarrollarlo.
Este estudio de viabilidad se centra en el objetivo de la organización. El estudio analiza la
materialización práctica del producto software respecto a su implementación, la contribución de
proyecto a la organización, los límites de costes, y según los objetivos y valores de la
organización. Explora aspectos técnicos del proyecto y del producto, como la utilidad, el
mantenimiento, la productividad y la capacidad de integración.
El resultado o output de esta fase debe ser un informe del estudio de viabilidad, conteniendo
comentarios adecuados y recomendaciones para la gestión sobre si se debe tirar adelante o no el
proyecto.
Recogida de requisitos
Si el informe de viabilidad es positivo en relación a tomar el proyecto, la siguiente fase empieza
con la recolección de requisitos por parte del consumidor. Analistas e Ingenieros se comunican
con el cliente y los consumidores para conocer sus ideas sobre qué debe aportar el software y
qué características quieren que incluya éste.
Requisitos del Software
El SRS es un documento creado por los analistas de sistema después de recoger los requisitos.
El SRS define cómo va a interactuar el sofware que quiere crearse con el hardware, las interfaces
externas, la velocidad operativa, el tiempo de respuesta del sistema, la portabilidad del software
en las diversas plataformas, el mantenimiento, la velocidad de reponerse después de
estropearse, su seguridad, calidad, limitaciones, etc.
Los requisitos recibidos por parte del cliente se escriben en lenguaje natural. Es responsabilidad
del analista de sistemas documentar sobre los requisitos en lenguaje tecnológico para que
puedan ser útiles y comprendidos por el equipo de desarrollo de software.
Validación de los requisitos de Software
Después del desarrollo de los requisitos, los que se mencionen en este documento serán
validados. El usuario puede que pida soluciones ilegales y poco prácticas, y los expertos puede
que interpreten los requisitos de forma incorrecta. Estos resultados se incrementan en coste si
no se cortan de raíz. Los requisitos se pueden evaluar en contraste con las siguientes
condiciones:
 Si pueden ser implementados de manera práctica.
 Si son válidos a nivel de funcionalidad y dominio del software
 Si hay alguna ambigüedad
 Si se han completado
 Si se pueden demostrar
 Definición de Requerimientos
 Una declaración en un Lenguaje Natural incluye los diagramas de los servicios del
sistema y sus límites operacionales. Escrito para clientes.
 Especificación de Requerimientos
 Un documento estructurado con descripción o detalle de los servicios del sistema.
Escrito como un contrato entre el cliente y el contratista.
 Especificación de Software
 Descripción detallada de software, la cual, puede servir como una base para diseño o
implementación. Escrito para desarrolladodres.
Definición de Requerimientos

1. El Software proporciona significado de representación y acceso a

archivos externos creados por otras herramientas.

Especificación de Requerimientos
1.1 El usuario debe proporcionar facilidades para definir el tipo de archivos externos.
1.2 Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será
aplicada para el archivo.
1.3 Cada tipo de archivo externo será representado como un icono específico mostrado al
usuario.
1.4 Las facilidades proporcionadas para la representación del icono en un tipo de archivo
externo será definido por el usuario.
1.5 Cuando un usuario selecciona una representación de icono de un archivo externo, el
efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo ex-
terno al archivo representado por la selección del icono.
 Gerencia de Cliente
Definición de Usuarios Finales del Sistema
Requerimientos Ingenieros de Clientes
Gerencia de Contratistas
Arquitectos del Sistema

Usuarios Finales del Sistema

Especificación de
Ingenieros de Cliente
Requerimientos
Arquitectos del Sistema
Desarrolladores de Software

Especificación de (Quizá) Ingenieros de Clientes

Software Arquitectos del Sistema
Desarrolladores de Software
 Estudio de Factibilidad
 Encuentran los usuarios actuales que sus necesidades son satisfechas dada la tecnología
y el presupuesto disponible?
 Análisis de Requerimientos
 Encontrar que el sistema requiere del mantenimiento de intereses.

 Definición de Requerimientos
 Definir los requerimientos en una forma comprensible para el cliente.

 Especificación de Requerimientos
 Define los requerimientos en detalle.
Estudio de Análisis de
Factibilidad Requerimientos

Definición de
Reporte de Requerimientos
Factibilidad

Especificación
Modelos del de Requerimientos
Sistema
Definición de
Requerimientos
Documento de
Requerimientos Especificación de
Requerimientos
 Es la declaración oficial de lo que es requerido para que el
sistema sea desarrollado.
 Incluye la definición y especificación de requerimientos.
 No es un documento de diseño. Tanto como sea posible,
es un conjunto de lo que es el sistema y como lo hará.
 Especificación de la conducta externa del sistema.
 Especificar los límites de la implementación.
 Fácil de cambiar.
 Sirve como una herramienta de referencia para mantenimiento.
 Recuerda el ciclo de vida del sistema, esto es, predice cambios.
 Proporciona respuestas características a un evento no esperado.
 Introducción.
 Describe la necesidad de crear el sistema y cuales son sus objetivos.

 Glosario.
 Define los términos técnicos usados.

 Modelos del Sistema.

 Define los modelos que muestran los componentes del sistema y las relaciones entre
ellos.
 Definición de Requerimientos Funcionales.
 Define los servicios que serán proporcionados.
 Definición de Requerimientos No-funcionales.
 Definir las limitantes del sistema y el proceso de desarrollo.

 Evolución del Sistema.

 Definir las suposiciones fundamentales en las cuales el sistema se
basa y se anticipan los cambios.
 Especificación de Requerimientos.
 Especificación detallada de los requerimientos funcionales del
sistema.
 Apéndices.
 Descripción de la plataforma de Hardware del Sistema.
 Requerimientos de la base de Datos (quizá como un modelo ER)

 Indice.
Consiste en preguntar al cliente, a los usuarios y a los que están
involucrados en los objetivos del sistema o producto y sean expertos
en los temas, investigar cómo los sistemas o productos se ajustan a
las necesidades del negocio, y finalmente, cómo el sistema o
producto va a ser utilizado en el día a día.
 Una relación de necesidades y características

 Un informe del alcance del sistema

 Una lista de clientes, usuarios y otros intervinientes

 Prototipos para definir mejor los requisitos

 Escenarios que permiten ver al sistema o producto bajo diferentes

condiciones operativas.
La técnica de obtención de requisitos más usada es llevar a cabo una reunión
o entrevista preliminar.

 Preguntas de contexto libre : Se enfocan sobre el cliente, los objetivos generales y los
beneficios esperados.

 Preguntas de identificación de participantes y beneficios medibles.

 Preguntas dirigidas a la eficacia de la reunión

Un modelo es una visión abstracta de un sistema que ignora algunos detalles del sistema.
Pueden desarrollarse modelos complementarios del sistema para mostrar el contexto, las
interacciones, la estructura y el comportamiento del sistema.
Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo,
son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del
desarrollo de software.
 Codificar y corregir
 Modelo en cascada
 Desarrollo evolutivo
 Desarrollo formal de sistemas
 Desarrollo basado en reutilización
 Desarrollo incremental
 Desarrollo en espiral
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
Escribir código y corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño,
validación, y mantenimiento.
Este modelo tiene tres problemas principales:
 Después de un número de correcciones, el código puede tener una muy mala estructura, hace
que los arreglos sean muy costosos.
 Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por
lo que es rechazado o su reconstrucción es muy cara.
 El código es difícil de reparar por su pobre preparación para probar y modificar.
 El primer modelo de desarrollo de software que se publicó en 1970. Éste toma las actividades
fundamentales del proceso de especificación, desarrollo, validación y evolución y las
representa como fases separadas del proceso.

El modelo en cascada consta de las siguientes fases:

 Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los
usuarios del sistema. Se busca hacer esta definición en detalle.
 Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece
la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los
componentes del sistema.
 Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se
realizan pruebas de cada unidad.
 Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se
entrega el conjunto probado al cliente.
 Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en
marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de
implementación. Se identifican nuevos requisitos.
 Cada fase tiene como resultado documentos que deben ser aprobados por el usuario.
 Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la
corrección de los problemas encontrados en fases previas.
En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las
distintas fases de desarrollo.
Algunos problemas que se observan en el modelo de cascada son:
 Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de
documentos.
 Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las
siguientes fases.
 Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o
corregidos de una forma poco elegante.
 Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el
largo tiempo de entrega del producto.
 Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a
cambios en los requisitos.
 Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como
parte de proyectos grandes.
 La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla y generar N versiones hasta que se desarrolle
el sistema adecuado.
 Actividades concurrentes: especificación, desarrollo y validación, se realizan durante el
desarrollo de las versiones hasta llegar al producto final.
 Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que
las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Existen dos tipos de desarrollo evolutivo:

 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras.
El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.
 Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar
para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza
por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para
experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.
Entre los puntos favorables de este modelo están:

 La especificación puede desarrollarse de forma creciente.

 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en
una mejora de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del
cliente.
Entre los puntos favorables de este modelo están:

 La especificación puede desarrollarse de forma creciente.

 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en
una mejora de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del
cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:

 Proceso no Visible: Los administradores necesitan entregas para medir el progreso.

 Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen
cada versión del sistema.
 Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la
estructura del software haciendo costoso el mantenimiento.
 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que
pueden ser incompatibles con otras o que poca gente sabe utilizar.
 Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o
medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar
documentación para cada versión.
 Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se
puede hacer un prototipo global del sistema y posteriormente re implementarlo con un
acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se
pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando
un enfoque exploratorio.
 Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un
programa ejecutable.
 Ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales:
especificación (incluyendo validación) y transformación.
 Las características principales de este paradigma son: la especificación es formal y ejecutable
(constituye el primer prototipo del sistema), la especificación es validada mediante
prototipación. Posteriormente, a través de transformaciones formales la especificación se
convierte en la implementación del sistema, en el último paso de transformación se obtiene
una implementación en un lenguaje de programación determinado. El mantenimiento se
realiza sobre la especificación (no sobre el código fuente), la documentación es generada
automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante
parches sobre la implementación).
 Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un
programa ejecutable.
 Ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales:
especificación (incluyendo validación) y transformación.
 Las características principales de este paradigma son: la especificación es formal y ejecutable
(constituye el primer prototipo del sistema), la especificación es validada mediante
prototipación. Posteriormente, a través de transformaciones formales la especificación se
convierte en la implementación del sistema, en el último paso de transformación se obtiene
una implementación en un lenguaje de programación determinado. El mantenimiento se
realiza sobre la especificación (no sobre el código fuente), la documentación es generada
automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante
parches sobre la implementación).
Observaciones sobre el desarrollo formal de sistemas:
 Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las
pruebas que verifican la correspondencia con la especificación no son necesarias.
 Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad
importantes.
 Requiere desarrolladores especializados y experimentados en este proceso para llevarse a
cabo.
Fuertemente orientado a la reutilización. Este modelo consta de 4 fases:
 Análisis de componentes: Se determina qué componentes pueden ser utilizados para el
sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
 Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los
componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos,
hay que seguir buscando componentes más adecuados (fase 1).
 Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema.
Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar
este marco.
 Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los
componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad
separada.
Las ventajas de este modelo son:
 Disminuye el costo y esfuerzo de desarrollo.
 Reduce el tiempo de entrega.
 Disminuye los riesgos durante el desarrollo.
Desventajas de este modelo:
 Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no
cumpla las expectativas del cliente.
 Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores
del sistema.
Dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:
 Desarrollo Incremental.
 Desarrollo en Espiral..
Sugiere el enfoque incremental de desarrollo como una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirir experiencia con el sistema. Es una combinación del Modelo de
Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las
decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,
dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un
buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.
Entre las ventajas del modelo incremental se encuentran:
 Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema.
 Pueden empezar a usarlo desde el primer incremento.
 Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.
 Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.
 Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos
módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
 Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
 Cada incremento debe aumentar la funcionalidad.
 Es difícil establecer las correspondencias de los requisitos contra los incrementos.
 Es difícil detectar las unidades o servicios genéricos para todo el sistema.
El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto
por Boehm 1988. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de
actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:

 Definición de objetivos: Se definen los objetivos y las restricciones del proceso y del
producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se
elaboran estrategias alternativas dependiendo de estos.
 Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado.
Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a
cabo los pasos para reducir los riesgos.
 Desarrollo y validación: Elegir modelo de desarrollo Elegir modelo de desarrollo, algunos
autores lo denominan metamodelo o modelo paramétrico.
 Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del
proyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es
una actividad importante en la administración del proyecto.
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se
determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las
alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación,
prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.
 Se usa un prototipo para dar al usuario una idea concreta de lo que va a hacer el
sistema.
 Se aplica cada vez más cuando la rapidez de desarrollo es esencial
 Prototipado evolutivo: el prototipo inicial se refina progresivamente hasta
convertirse en versión final
 Prototipado desechable: de cada prototipo se extraen ideas buenas que se usan para
hacer el siguiente, pero cada prototipo se tira entero
SECUENCIA DE PASOS

 Comienza con la recolección de requisitos

 Cliente y desarrolladores definen los objetivos del software.
 Además, identifican los requisitos conocidos y aquellos que ser más definidos.
 Aparece un diseño rápido centrado en los aspectos visibles para el cliente
 El diseño rápido lleva a la construcción de un prototipo.
 El prototipo lo evalúa el cliente y lo utiliza para refinar los requisitos
 El proceso se reitera... ¿desechando el prototipo?
¿Cuál es el modelo de proceso más adecuado?
Cada proyecto de software requiere de una forma de particular de abordar el problema.
Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en
cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de
criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos
identificados, entre otros).
En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la
selección de un modelo de proceso [10], la medida utilizada indica el nivel de efectividad del
modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un
nivel de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos ):
 Concepto
 Información y datos
 Tipos de Sistemas de información
Un sistema de información es un
conjunto de componentes que
interactúan entre sí para entregar
información a un usuario.

Esos componentes pueden ser:

hardware, software, personas,
recursos y los datos.
 Liliana
17/08/1986

Femenino
León
Datos

Los datos son la mínima unidad semántica, y se corresponden con elementos primarios de información que por
sí solos son irrelevantes como apoyo a la toma de decisiones. También se pueden ver como un conjunto discreto
de valores, que no dicen nada sobre el por qué de las cosas y no son orientativos para la acción.

Un número telefónico o un nombre de una persona, por ejemplo, son datos que, sin un propósito, una utilidad
o un contexto no sirven como base para apoyar la toma de una decisión. Los datos pueden ser una colección de
hechos almacenados en algún lugar físico como un papel, un dispositivo electrónico (CD, DVD, disco duro...), o
la mente de una persona. En este sentido las tecnologías de la información han aportado mucho a recopilación
de datos.

Como cabe suponer, los datos pueden provenir de fuentes externas o internas a la organización, pudiendo ser
de carácter objetivo o subjetivo, o de tipo cualitativo o cuantitativo, etc.
Información

La información se puede definir como un conjunto de datos procesados y que tienen un significado (relevancia,
propósito y contexto), y que por lo tanto son de utilidad para quién debe tomar decisiones, al disminuir su
incertidumbre. Los datos se pueden transforman en información añadiéndoles valor:

• Contextualizando: se sabe en qué contexto y para qué propósito se generaron.

• Categorizando: se conocen las unidades de medida que ayudan a interpretarlos.
• Calculando: los datos pueden haber sido procesados matemática o estadísticamente.
• Corrigiendo: se han eliminado errores e inconsistencias de los datos.
• Condensando: los datos se han podido resumir de forma más concisa (agregación).

Por tanto, la información es la comunicación de conocimientos o inteligencia, y es capaz de cambiar la forma en

que el receptor percibe algo, impactando sobre sus juicios de valor y sus comportamientos.
Información = Datos + Contexto (añadir valor) + Utilidad (disminuir la incertidumbre)
.
Los sistemas de información dependen de otros subsistemas componentes para poder llevar a cabo las
actividades de entrada, proceso, salida, almacenamiento y control que convierten recursos de datos en
productos de información. Estos subsistemas incluyen personas, hardware, software, procedimientos y datos.
En lo que sigue se detalla sobre cada uno de ellos.

• Personas: Un sistema de cómputo involucra una variada gama de personas relacionadas con el mismo,
puesto que su construcción, mantenimiento y uso representan una labor con cierto grado de complejidad. Se
pueden dividir en dos grandes grupos: Los usuarios finales y los especialistas o profesionales.

• Los usuarios finales son aquellos que operan o interaccionan directamente con el sistema a través de una
estación de trabajo o incluso, quienes reciben reportes e información generada por el sistema.
.
• Entre los profesionales se encuentran: Los analistas de los sistemas de información, encargados de idear soluciones cuando
se requiere un nuevo sistema, actualizarlo, modificarlo o reconstruirlo; los programadores, que crean los programas de
cómputo que forman parte de los sistemas de información; los administradores del sistema, encargados de mantener el
sistema en buenas condiciones; los capacitadores, que instruyen y preparan a los usuarios para la utilización del sistema.

• Hardware: Consiste en los equipos, dispositivos y medios necesarios que constituyen la plataforma física mediante la cual,
el sistema de información puede funcionar. Se incluyen aquí, por supuesto, los que permiten las comunicaciones y los
enlaces de red. Estos recursos son, por ejemplo, computadoras, monitores, impresoras, disquetes o componentes de
almacenamiento de información externos, disco óptico, papel de impresión, cableado de red, y otros.

• Software o programas: Son el componente lógico, es decir, los programas, las rutinas e instrucciones que conforman el
sistema de información. Se les suele denominar aplicación de sistema de información. Es así como los sistemas de
información pueden tener aplicaciones particulares, por ejemplo, para el área de ventas, de contabilidad, de personal o de
compras. La aplicación que conforma un sistema de información completo contiene subconjuntos de programas que se
encargan de apoyar las distintas actividades propias de la organización.
.
Clasificación de los 6 tipos de sistemas de información más relevantes
Los tipos de sistemas de la información más populares pueden clasificarse de la siguiente
forma:

1. Sistemas de procesamiento de transacciones

Los sistemas de procesamiento de transacciones (TPS por sus siglas en inglés) son los sistemas
empresariales básicos que sirven al nivel operacional de la organización.
Un sistema de procesamiento de transacciones es un sistema computarizado que realiza y
registra las transacciones rutinarias diarias necesarias para el funcionamiento de la empresa. Se
encuentran en el nivel más bajo de la jerarquía organizacional y soportan las actividades
cotidianas del negocio.
2. Sistemas de control de procesos de negocio

Los sistemas de control de procesos de negocio (BPM por sus siglas en inglés) monitorizan y
controlan los procesos industriales o físicos, como puede ser la refinación de petróleo,
generación de energía o los sistemas de producción de acero en una planta siderúrgica.

Por ejemplo, en una refinería de petróleo se utilizan sensores electrónicos conectados a

ordenadores para monitorizar procesos químicos continuamente y hacer ajustes en tiempo real
que controlan el proceso de refinación. Un sistema de control de procesos comprende toda una
gama de equipos, programas de ordenador y procedimientos de operación.
3. Sistemas de colaboración empresarial

Los sistemas de colaboración empresarial (ERP por sus siglas en inglés) son uno de los tipos de
sistemas de información más utilizados. Ayudan a los directivos de una empresa a controlar el
flujo de información en sus organizaciones.

Se trata de uno de los tipos de sistemas de información que no son específicos de un nivel
concreto en la organización, sino que proporcionan un soporte importante para una amplia
gama de usuarios. Estos sistemas de información están diseñados para soportar tareas de
oficina como sistemas multimedia, correos electrónicos, videoconferencias y transferencias de
archivos.
4. Sistemas de Información de Gestión

Los sistemas de información de gestión (MIS por sus siglas en inglés) son un tipo de sistemas de
información que recopilan y procesan información de diferentes fuentes para ayudar en la toma de
decisiones en lo referente a la gestión de la organización.

Los sistemas de información de gestión proporcionan información en forma de informes y estadísticas. El

siguiente nivel en la jerarquía organizacional está ocupado por gerentes y supervisores de bajo nivel. Este
nivel contiene los sistemas informáticos que están destinados a ayudar a la gestión operativa en la
supervisión y control de las actividades de procesamiento de transacciones que se producen a nivel
administrativo.

Los sistemas de información de gestión utilizan los datos recogidos por el TPS para proporcionar a los
supervisores los informes de control necesarios. Los sistemas de información de gestión son los tipos de
sistemas de información que toman los datos internos del sistema y los resumen en formatos útiles como
informes de gestión para utilizarlos como apoyo a las actividades de gestión y la toma de decisiones.
5. Sistemas de apoyo a la toma de decisiones

Un sistema de apoyo a la toma de decisiones o de soporte a la decisión (DSS por sus siglas en
inglés) es un sistema basado en ordenadores destinado a ser utilizado por un gerente particular
o por un grupo de gerentes a cualquier nivel organizacional para tomar una decisión en el
proceso de resolver una problemática semiestructurada.

Los sistemas de apoyo a la toma de decisiones son un tipo de sistema computarizado de

información organizacional que ayuda al gerente en la toma de decisiones cuando necesita
modelar, formular, calcular, comparar, seleccionar la mejor opción o predecir los escenarios.

Los sistemas de apoyo a la toma de decisiones están específicamente diseñados para ayudar al
equipo directivo a tomar decisiones en situaciones en las que existe incertidumbre sobre los
posibles resultados o consecuencias. Ayuda a los gerentes a tomar decisiones complejas.
6. Sistemas de Información Ejecutiva

Los sistemas de información ejecutiva (EIS por sus siglas en inglés) proporcionan un acceso
rápido a la información interna y externa, presentada a menudo en formato gráfico, pero con la
capacidad de presentar datos básicos más detallados si es necesario. Los sistemas información
ejecutiva proporcionan información crítica de una amplia variedad de fuentes internas y
externas en formatos fáciles de usar para ejecutivos y gerentes.

Un sistema de información ejecutiva proporciona a los altos directivos un sistema para ayudar a
tomar decisiones estratégicas. Está diseñado para generar información que sea lo
suficientemente abstracta como para presentar toda la operación de la empresa en una versión
simplificada para satisfacer a la alta dirección.
En informática, podemos entender como seguridad la característica de un sistema informático,
(ya sean sistemas operativos, servicios o aplicaciones), que nos indica que está libre de todo
peligro, daño o riesgo, y que es, en cierta manera infalible. Como esta característica, es muy
difícil de conseguir (según la mayoría de los expertos, imposible), se suaviza la definición de
seguridad y se pasa a hablar de fiabilidad, que es la probabilidad de que un sistema se
comporte tal y como se espera de él. Por tanto, se habla de tener sistemas fiables en lugar de
sistemas seguros.
De los sistemas informáticos, se dice que son seguros si cumplen las siguientes características:

Confidencialidad:
Requiere que la información sea accesible únicamente por las entidades autorizadas. De esta
manera, se dice que un documento (o archivo o mensaje) es confidencial si y sólo si puede ser
comprendido por la persona o entidad a quien va dirigida o esté autorizada. En el caso de un
mensaje esto evita que exista una intercepción de este y que pueda ser leído por una persona
no autorizada.

Por ejemplo, si Andrea quiere enviar un mensaje a Bruno y que solo pueda leerlo Bruno,
Andrea cifra el mensaje con una clave (simétrica o asimétrica), de tal modo que solo Bruno
sepa la manera de descifrarlo, así ambos usuarios están seguros de que solo ellos van a poder
leer el mensaje.
Integridad:

Es la cualidad de un mensaje, comunicación o

archivo, que permite comprobar que no se ha
producido manipulación alguna en el original, es
decir, que no ha sido alterado.

Teniendo como muestra el ejemplo anterior. El

destinatario compara ambas funciones resumen,
(se trata de una función que produce un valor
alfanumérico que identifica cualquier cambio que
se produzca en el mensaje), y si estas funciones
son iguales, quiere decir que no ha existido
manipulación en el mismo.
Disponibilidad:

Se trata de la capacidad de un servicio, de unos

datos o de un sistema, a ser accesible y utilizable
por los usuarios (o procesos) autorizados cuando
estos lo requieran. Supone que la información
pueda ser recuperada en el momento en que se
necesite, evitando su pérdida o bloqueo.

Hay que tener en cuenta que, tanto las amenazas

como los mecanismos para contrarrestarlas, suelen
afectar a estas tres características de forma
conjunta. Así por ejemplo, fallos del sistema que
hacen que la información no sea accesible pueden
llevar consigo una pérdida de integridad.
Generalmente tienen que existir los tres aspectos
descritos para que haya seguridad..
Dependiendo del entorno en que un sistema trabaje, a sus responsables les interesará dar
prioridad a un cierto aspecto de seguridad. Por ejemplo, en un sistema militar se antepondrá la
confidencialidad de los datos almacenados o transmitidos sobre su disponibilidad. En cambio,
en un servidor de archivos en red, se priorizará la disponibilidad frente a la confidencialidad. En
un entorno bancario, la faceta que más ha de preocupar a los responsables del sistema es la
integridad de los datos, frente a su disponibilidad o su confidencialidad: es menos grave que un
usuario consiga leer el saldo de otro que el hecho de que ese usuario pueda modificarlo.

Junto a estos tres conceptos fundamentales se suelen estudiar conjuntamente la autenticación

y el no repudio.
Autenticación:
La autenticación es la situación en la cual se puede verificar que un documento ha sido elaborado (o
pertenece) a quien el documento dice.

Aplicado a la verificación de la identidad de un usuario, la autenticación se produce cuando el usuario

puede aportar algún modo de que se pueda verificar que dicha persona es quien dice ser, a partir de ese
momento se considera un usuario autorizado. Se suele realizar mediante un usuario o login y una
contraseña o password.

No repudio o irrenuncibilidad: Está estrechamente relacionado con la autenticación y permite probar la

participación de las partes en una comunicación. Existen dos posibilidades:

No repudio en origen: El emisor no puede negar el envío. La prueba la crea el propio emisor y la
recibe el destinatario.
No repudio en destino: El receptor no puede negar que recibió el mensaje porque el emisor tiene
pruebas de la recepción. En este caso la prueba irrefutable la crea el receptor y la recibe el emisor.
Si la autenticidad prueba quién es el autor o el propietario de un documento y cuál es su
destinatario, el no repudio prueba que el autor envió la comunicación (no repudio en origen) y
que el destinatario la recibió (no repudio en destino).

Al grupo de estos tres objetivos de la seguridad se les conoce como CIDAN, nombre sacado de
la inicial de cada característica. La relación de los mismos se presenta en la figura siguiente:
En la imagen superior se ilustra como se relacionan los diferentes servicios de seguridad,
unos dependen de otros jerárquicamente, así si no existe el de más abajo, no puede aplicarse
el superior. De esta manera, la disponibilidad se convierte en el primer requisito de
seguridad, cuando existe esta, se puede disponer de confidencialidad, que es imprescindible
para conseguir integridad, para poder obtener autenticación es imprescindible la integridad
y por ultimo el no repudio solo se obtiene si se produce previamente la autenticación.
Alta disponibilidad
La alta disponibilidad se refiere a la capacidad de que
aplicaciones y datos se encuentren operativos para los
usuarios autorizados en todo momento y sin
interrupciones, debido principalmente a su carácter
crítico. El objetivo de la misma es mantener nuestros
sistemas funcionando las 24 horas del día, 7 días a la
semana, 365 días al año, manteniéndolos a salvo de
interrupciones.
Existen dos tipos de interrupciones:

Las interrupciones previstas, que se realizan cuando paralizamos el sistema para realizar cambios o
mejoras en nuestro software.

Las interrupciones imprevistas, que suceden por acontecimientos imprevistos (como un apagón, un
error del hardware o del software, problemas de seguridad, un desastre natural, virus, accidentes,
caídas involuntarias del sistema).

Las métricas comúnmente utilizadas para medir la disponibilidad y fiabilidad de un sistema son:
Existen dos tipos de interrupciones:

Las interrupciones previstas, que se realizan cuando paralizamos el sistema para realizar cambios o
mejoras en nuestro software.

Las interrupciones imprevistas, que suceden por acontecimientos imprevistos (como un apagón, un
error del hardware o del software, problemas de seguridad, un desastre natural, virus, accidentes,
caídas involuntarias del sistema).

Existen distintos niveles de disponibilidad del sistema. Según el tiempo aproximado de inactividad
por año se determina el porcentaje de disponibilidad. El mayor nivel de exigencia de alta
disponibilidad acepta 5 minutos de inactividad al año, con lo que se obtiene una disponibilidad de 5
nueves: 99.999%.