República bolivariana de Venezuela

Ministerio del poder Popular Para La Educación Superior Universitaria

UPTP “Juan de Jesus Montilla”
Guanare-Portuguesa

Ingeniería del
software
(Unidad I)

Bachilller:
Yorjan Sandoval
CI: 28.200.164
Seccion: 332
 Fundamentos de sistema

Definición: Sistema de Información (SI) Un SI, es un tipo especializado de sistema

que puede definirse de muchas maneras. Es un conjunto de elementos que
interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. Es
un conjunto de elementos o componentes interrelacionados para recolectar,
manipular y diseminar datos en información y para proveer un mecanismo de
retroalimentación en pro del cumplimiento de un objetivo.

Organización:
• Entrada: actividad consistente en la recopilación y captura de datos.
• Procesamiento: conversión o transformación de datos en salida.
• Salida: información útil, por lo general bajo la modalidad de documentos
y/o informes.
• Retroalimentación: salida que sirve para hacer cambios en las
actividades de entrada o procesamiento.

Proceso:
 Sistema:
Un sistema de información es un conjunto interconectado de medios, métodos
y personal empleado para almacenar, procesar y emitir información para lograr
los objetivos de gestión. En las condiciones modernas, el principal medio
técnico de procesamiento de la información es una computadora personal. La
mayoría de los sistemas de información modernos no transforman información,
sino datos. Por lo tanto, a menudo se les llama sistemas de procesamiento de
datos.

En cuanto al grado de mecanización de los procedimientos de conversión de la

información, los sistemas de procesamiento de datos se dividen en sistemas de
procesamiento manual, sistemas de procesamiento de datos mecanizados,
automatizados y automáticos.

Estructura de sistema:
• Entrada: actividad consistente en la recopilación y captura de datos.
• Procesamiento: conversión o transformación de datos en salida.
• Salida: información útil, por lo general bajo la modalidad de documentos
y/o informes.
• Retroalimentación: salida que sirve para hacer cambios en las
actividades de entrada o procesamiento.

Sistema de Información (SI)

Un SI, es un tipo especializado de sistema que puede definirse de muchas maneras.
Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las
actividades de una empresa o negocio. Es un conjunto de elementos o componentes
interrelacionados para recolectar, manipular y diseminar datos en información y para
proveer un mecanismo de retroalimentación en pro del cumplimiento de un objetivo.
Tipos y usos de los SI
 1. SI Transaccionales
2. SI de Soporte a la toma de decisiones
• Sistemas de apoyo para la toma de decisiones (DSS)
• Sistemas de apoyo para la toma de decisiones en grupo (GDSS)
• Sistemas expertos para la toma de decisiones (EDSS)
• SI para ejecutivos (EIS)
• Sistemas expertos de apoyo a la toma de decisiones

3. SI Estratégicos

SI Transaccionales: Logran la automatización de los procesos operativos dentro de

una organización. Su función primordial consiste en procesar transacciones.
Típicamente, es el primer tipo de SI que se implanta en las organizaciones. Muestran
una intensa entrada y salida de información. Este tipo de sistema constituyen la
plataforma de información de los SI para la toma de decisiones.

SI de apoyo a la toma de decisiones: Suelen introducirse después de haber

implantado los SI transaccionales La información que generan sirve de apoyo al
proceso de toma de decisiones que. Suelen ser intensivos en cálculos y escasos en
entradas y salidas de información. No suelen ahorrar mano de obra. Suelen ser
interactivos y amigables.SI Estratégicos Este tipo de SI tienen como objetivo en las
organizaciones lograr ventajas competitivas, a través del uso de las TI. Su función es
lograr ventajas que los competidores no poseen, como lo pueden ser ventajas en
costos y servicios diferenciados con clientes y proveedores. Apoyan al proceso de
innovación de productos y procesos dentro de la empresa.

Ciclo de vida de los SI

Un SI, nace, se desarrollo y muere. Se debe tener claro que un SI no necesariamente
se implementa en forma computacional, sin embargo, es muy fácil demostrar que la
computación es la mejor herramienta de la que disponemos para entregar y mantener
la información requerida.
Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un
tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un
periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta
la necesidad de construir un sistema de software hasta que este es retirado, se
identifican varias etapas que en conjunto se denominan el ciclo de vida del software y
en cada caso, en función de cuales sean las características del proyecto, se
configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas:
especificación y análisis de requisitos, diseño del sistema, implementación del
software, aplicación y pruebas, entrega y mantenimiento. Un aspecto esencial dentro
de las tareas del desarrollo del software es la documentación de todos los elementos
y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la
fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las
diferentes fases como un apartado especial para recalcar su importancia en el
conjunto del desarrollo del software.

Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo
de vida son:
Análisis: Construye un modelo de los requisitos.

Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la

estructura en la que descompone el sistema y la interfaz de usuario.

Codificación: Construye el sistema. La salida de esta fase es código ejecutable.

Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.

Validación: es el proceso de comprobar que lo que se ha especificado es lo que el

usuario realmente quería.

Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el
sistema siga funcionando y adaptándose a nuevos requisitos.

Paradigmas:
El agigantado cambio frente al manejo y uso social de la información delinean
poderosamente un cambio paradigmático, que envuelven a las organizaciones y les
exige asimilar esos cambios dramáticos como sinónimo de éxito y prosperidad, es
por ello que el tratadista Joel Barker en su obra “Paradigmas” , define lo siguiente:
“Un paradigma es un conjunto de reglas y disposiciones (escritas o no) que hace dos
cosas:
1) Establece o define límites
2) Indica cómo comportarse dentro de los límites para tener éxito.”

Los paradigmas ilustran la manera como ejecutar las instrucciones para ejecutar una
tarea y lograr los objetivos propuestos, lo que conlleva a la idea de los límites y las
reglas a seguir para no traspasarlos. Sucedía que las organizaciones venían
actuando entre ciertos límites sociales y comerciales, pero éstos fueron
transformándose al igual que sus instrucciones y reglas, los límites se fueron
tornando invisibles y la soñada aldea global fue materializándose y refinándose cada
vez más, y es aquí precisamente, donde los cambios paradigmáticos denotan la
transformación de instrucciones y de reglas, entonces el cambio hace ostensible
aquello de que las organizaciones tengan como blanco la transformación de sus
paradigmas como ruta a la llamada longevidad organizacional, que también promulga
el tratadista Joel Arthur Barker frente al tema de los paradigmas.

Las organizaciones manejan aglomerados de paradigmas gerenciales, de

mercadotecnia, de finanzas, de ventas, de cultura organizacional, etc. y obviamente
manejan el paradigma de la información. La integración y manejo sistémico de éstos
aglomerados pueden asegurar la supervivencia de las organizaciones.

Rol de analista de sistemas:

El analista de sistemas evalúa de manera sistemática el funcionamiento de un
negocio mediante el examen de la entrada y el procesamiento de datos y su
consiguiente producción de información, con el propósito de mejorar los procesos de
una organización. Muchas mejoras incluyen un mayor apoyo a las funciones de
negocios a través del uso de sistemas de información computarizados. Esta
definición pone énfasis en un enfoque sistemático y metódico para analizar y en
consecuencia mejorar lo que sucede en el contexto específico creado por un negocio.
Nuestra definición de analista de sistemas es amplia. El analista debe tener la
capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en
computadoras. El analista desempeña diversos roles, en ocasiones varios de ellos al
mismo tiempo. Los tres roles principales del analista de sistemas son el de consultor,
experto en soporte técnico y agente de cambio.
 Ingeniería del software

Conceptos básicos:
¿Qué se entiende por Software?: “Conjunto de programas, instrucciones y reglas
informáticas para ejecutar ciertas tareas en una computadora.”
- RAE

“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]

Como vemos en esta definición mucho más exacta, se incluye la documentación y los
datos como parte de lo que se conoce como Software.

¿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
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

Atributos de calidad
Atributos de calidad Atributos de calidad (también cualidades del so ware) son
características no funcionales que se consideran deseables en un sistema de so
ware. Sin embargo, no todos los sistemas de so ware deben tener en cuenta todos
estos atributos o cualidades, algunas serán más importantes que otras dependiendo
del sistema, y ciertamente no se pueden maximizar todas a la vez. Se establece una
diferencia entre cualidades y requerimientos, porque algunas de ellas pueden
incorporarse como entrada al diseño por un camino distinto al del análisis (por
ejemplo, como restricciones de arquitectura o influencias del entorno).

Simplicidad: Simplicidad es la ausencia de complejidad o dificultades. En el

desarrollo de so ware puede resultar de interes
diferenciar entre complejidades esenciales y accidentales.

Complejidad esencial: las que son propias o intrínsecas al problema que se desea
solucionar. Es natural que un problema complejo tenga soluciones con algún grado
de complejidad.

complejidades accidentales: aquellas que surgen por malas decisiones de diseño.

Naturalmente, se intentará evitar diseñar soluciones que sean más complejas de lo
que el problema requiere. Determinar si una dificultad en un diseño o programa es
esencial o accidental, nos permite atacar las dificultades accidentales, buscando
soluciones más simples.
Correctitud, consistencia, completitud:

• Correctitud: Ausencia de errores. Consistencia:Coherencia entre las

operaciones que realiza el usuario.

• Completitud:Capacidad del sistema para realizar todas las operaciones que

usuario podría requerir.

Robustez: Robusto es un sistema que goza de buena salud y que brinda garantías de
que va a continuar teniendo buena salud. Algunos síntomas de un sistema robusto
son: la capacidad de ser modificado sin introducir errores (opuesto a error prone)
durabilidad del sistema funcionando correctamente (no aparecen errores aleatorios)
Diferentes usuarios tendrán diferentes visiones de la robustez del sistema.

Flexibilidad: También llamada modificabilidad, es la capacidad para admitir cambios

que pueden ser necesarios tanto por un cambio de requerimientos como por la
detección de un error que debe ser corregido. Una variante de flexibilidad es la
extensibilidad, es decir, la posibilidad de agregar nuevos requerimientos.

Performance: La performance es una medida de la eficiencia en el uso de recursos

del sistema ejecutándose, por ejemplo:
• Uso de procesador
• Uso de redes
• Memoria
• Almacenamiento permanente (discos rígidos, etc).
... o cualquier otro recurso físico.

Escalabilidad: Es la capacidad de un sistema para trabajar con diferentes cantidades

de trabajo, como cambios en el volumen de datos o flujo de pedidos. Con frecuencia
se estudia la escalabilidad de un sistema hacia arriba, es decir, se mide la capacidad
del sistema para manejar, por ejemplo, un mayor volumen de datos. La medida de
escalabilidad no requiere que el sistema funcione intacto en las nuevas condiciones,
en cambio es una medida de la facilidad con la que se lo puede adaptar al nuevo
entorno, por ejemplo, si está preparado para que yo agregue un servidor más a un
clúster eso se podría considerar escalable. También puede ser de utilidad analizar la
flexibilidad hacia abajo, es decir, la posibilidad de un sistema de adaptarse a un
entorno más sencillo. En estos casos, se analiza, por ejemplo, la posibilidad de evitar
el uso de recursos que encarecen el sistema y podrían no ser indispensables, por
ejemplo ejecutar toda la aplicación en un único servidor en lugar de cada capa en uno
distinto o bien reemplazar determinados componentes adquiridos por otros de menor
costo de licencia. Un error común es confundir escalabilidad con extensibilidad.

Seguridad: Algunas visiones de la seguridad son:

• Comprobar la identidad de las personas que intentan acceder al sistema.
• Garantizar que sólo las personas específicamente autorizadas pueden ver
determinada porción de la información del sistema
• Garantizar que sólo las personas específicamente autorizadas pueden
modificar determinada porción de la información del sistema o bien realizar
determinadas acciones.

Usabilidad: La facilidad con la que el sistema o componente se puede utilizar o bien

aprender a utilizar.

Constructibilidad: La constructibilidad es una medida inversa a la complejidad de la

construcción del sistema. Las decisiones de diseño pueden afectar severamente la
dificultad para construir ese sistema.

Visión general del proceso de desarrollo de software:

Es proceso es afectado por la creatividad y juicio de las personas involucradas. En el
desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente
a la naturaleza del producto obtenido. Un proceso de desarrollo de software tiene
como propósito la producción eficaz y eficiente de un producto software que reúna los
requisitos del cliente.
Es actividades requeridas para desarrollar un sistema de software de alta calidad y
proporciona el marco de trabajo desde el cual se puede establecer un plan detallado
para el desarrollo del software. Actividades: Diseño, validación, evolución,
especificación.

El papel del usuario dentro del proceso de desarrollo de software

Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de
desarrollo de software, mayores serán las probabilidades de éxito que tenga el
mismo.

No obstante es importante hacer algunas matizaciones:

• El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por
parte de los usuarios, si no se consigue interpretar con precisión lo que quieren
y no se dinamiza un feedback continuo de los mismos durante todo el proceso
de desarrollo, se incrementarán las posibilidades de que algún requisito
funcional no se haya recogido adecuadamente o de que se haya realizado un
software con una usabilidad incómoda para los usuarios.

• Es importante que entre el grupo usuarios asignados al proyecto haya usuarios

que vayan a estar implicados en el futuro uso del sistema de información, es
decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos”
o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino
que es fundamental que participen usuarios que después se tengan que poner
el mono de trabajo y vayan a trabajar con el software.

• Los analistas están para ayudar y para colaborar con los usuarios en la
especificación y diseño de la solución, pero no están para “dar lecciones” a los
usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su
trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre
 tendrá una justificación que sólo se entendería si realmente estuviéramos
haciendo su trabajo durante un tiempo y viéramos los problemas con los que
se enfrentan cotidianamente.

• Es fundamental documentar el proyecto, en primer lugar con la documentación

que se especifique en las normativas de desarrollo de la organización para la
que se realiza el servicio, con las matizaciones que indique el Director del
Proyecto, en segundo lugar con la documentación que establezcan las
normativas internas de calidad de tu organización (no requerirá un sobre-
esfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior
sumarle toda la documentación de trabajo que sea necesaria para trabajar con
los usuarios, que no tienen por qué entender de modelos de datos, de
diagramas de casos de uso, etc…, es más, es un error trabajar con los usuarios
utilizando dichas herramientas, ya que estas son de utilidad técnica y no
hablan el mismo lenguaje de los usuarios.

Modelos de desarrollo de software

Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales
cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus
necesidades. En ocasiones puede que una combinación de varios modelos sea
apropiado.

Modelo de cascada: El modelo de cascada muestra un proceso donde los

desarrolladores han de seguir las siguientes fases de forma sucesiva:
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase,
comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente
fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de
control formal de cambio). Las revisiones también se utilizan para asegurar que la
fase anterior ha sido totalmente finalizada; los criterios para completar una fase se
conocen frecuentemente con el término inglés "gate" (puerta). Este modelo
desaconseja revisitar y revisar fases que ya se han completado. Esta falta de
flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores
de modelos más flexibles.

Modelo de espiral: La principal características del modelo en espiral es la gestión de

riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988
por Barry Boehm, combinando algunos aspectos clave de las metodologías del
modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un
área que para muchos no jugó el papel que requiere en otros modelos: un análisis
iterativo y concienzudo de los riesgos, especialmente en el caso de sistema
complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con
el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
crear planes con el propósito de identificar los objetivos del software,seleccionados
para implementar el programa y clarificar las restricciones en el desarrollo del
software;
Análisis de riesgos: una evaluación analítica de programas seleccionados, para
evaluar como identificar y eliminar el riesgo; la implementación del proyecto:
implementación del desarrollo del software y su pertinente verificación; Modelo de
espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las
opciones y limitaciones para facilitar la reutilización de software, la calidad del
software puede ayudar como una meta propia en la integración en el desarrollo del
producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que
destacan:

El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que

acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en
los desarrolladores así como la predisposición a gastar más para solventar los temas,
por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a
gran escala.

Si la implementación del riesgo de análisis afectará de forma esencial los beneficios

del proyecto, no debería utilizarse este modelo.

Los desarrolladores de software han de buscar de forma explícita riesgos y

analizarlos de forma exhaustiva para que este modelo funcione.

La primera fase es la búsqueda de un plan para conseguir los objetivos con las
limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por
medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un
prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es
conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último,
se evalúan los resultados y se inicia el diseño de la siguiente fase.
 modelado de sistema:
La ingeniería de sistemas de computadora es un proceso de modelado. Tanto si el
punto de mira está en la visión global o en la visión detallada, el ingeniero crea
modelos que:

• Definan los procesos que satisfagan las necesidades de la visión en

consideración;
• Representen el comportamiento de los procesos y los supuestos en los que
se basa el comportamiento;
• Definan explícitamente las entradas exógenas y endógenas de información al
modelo;
• Representen todos las uniones (incluyendo las salidas) que permitan al
ingeniero entender mejor la visión.

Para desarrollar el modelo del sistema, se emplea un esquema del modelado del
sistema. El ingeniero de sistemas asigna elementos a cada una de las cinco regiones
de tratamiento del esquema:
1. Interfaz de usuario,
2. Entrada,
 3. Tratamiento y control del sistema,
4. Salida
5. Mantenimiento y auto comprobación.

El esquema del modelado del sistema permite al analista crear una jerarquía en
detalle, donde en el nivel más alto de dicha jerarquía se encuentra el diagrama de
contexto del sistema. Este diagrama establece el límite de información entre el
sistema que se está implementando y el entorno en que va a operar. En otras
palabras, define todos los suministradores externos de información que emplea el
sistema, toda los consumidores externos de información creados por el sistema y
todas las entidades que se comunican a través de la interfaz o realizan
mantenimiento y autocomprobación.