SISTEMAS DE INFORMACION

Es un conjunto de elementos orientados al tratamiento y administración de datos e

información, organizados y listos para su uso posterior, generados para cubrir una
necesidad u obje9vo

DATO - INFORMACION – CONOCIMIENTO

DATO: Situaciones reales, y se representan por medio de símbolos

INFO: Datos al ser interpretados, adquieren un significado

Conocimiento: Dado un contexto, la información, se convierte en conocimiento

REQUERIMIENTO
Un requerimiento define las funciones, capacidades o atributos intrínsecos de un sistema
de so6ware, en otras palabras, describe como un sistema debe comportarse

• Funcional: Los requerimientos funcionales son las descripciones explicitas del

comportamiento que debe tener una solución de so>ware y que información debe
manejar.

• No funcional: Los requerimientos no funcionales definen las caracterísBcas o

cualidades generales que se esperan de un sistema y establecen restricciones sobre
el producto, el proceso de desarrollo de so>ware y establecen restricciones
externas que el so>ware debe lograr

STAKEHOLDERS

• Es un individuo, grupo u organización que puede afectar, verse afectado, o

percibirse a sí mismo como posible afectado por una decisión, actividad o
resultado de un proyecto.

• Los Stakeholders son personas que tienen interés en el Producto/proyecto.

• Los Stakeholders son la fuente de requerimientos.

Clasificación de Requerimientos

Requerimientos de negocio:
Comprenden las metas, obje9vos y resultados esperados que describen porque la
inicia9va de cambio (el proyecto) se está desarrollando.
Pueden aplicar a toda una empresa. Área de negocio o una inicia9va especifica.
Ejemplos:
○ Automa9zar la ges9ón de relaciones con el cliente a objeto de reducir el
9empo de respuesta promedio en 70% en los próximos 6 meses.
○ Op9mizar la toma de pedidos del cliente a objeto de duplicar la can9dad
de pedidos que se pueden procesar en un mes (aumentarla en 100%).

Requerimientos de los interesados:

○ Estos requisitos describen cuales son las necesidades de los interesados,
para ayudarles a lograr los obje9vos y requerimientos de sus áreas de
negocio. También se les suele conocer como requerimientos de los
usuarios.
○ Pueden servir de puente para vincular los requerimientos del negocio con
los de la solución.
○ Ejemplos:
○ Necesitamos un mecanismo que reciba los pedidos de los clientes por un
medio en línea.
○ Necesitamos que los pedidos de cliente recibidos en línea sean asignados
automá9camente al analista que los procesará, según el 9po de cliente y
área de la industria en el que este de desempeña.

Requerimientos de la solución:
• Requerimientos funcionales.
• Requerimientos no funcionales.

Requerimientos de transición:

Los requisitos de transición describen las capacidades y condiciones que debe

cumplir la solución para facilitar la transición entre la situación actual y la nueva,
pero que ya no serán necesarias una vez que sea culminado el cambio.

Se diferencian de los demás 9pos de requerimientos en que son temporales.

Los requerimientos de transición abarcan tópicos como las conversiones de

datos, entrenamiento y con9nuidad del negocio.
ESPECIFICACION DE REQUERIMIENTOS.

La especificación de requerimientos es el proceso de escribir, en un documento de

requerimientos, los requerimientos del usuario y del sistema, de forma detallada

De manera ideal, los requerimientos del usuario y del sistema deben ser claros, sin
ambigüedades, fáciles de entender, completos y consistentes

Elicitación

El concepto de “Elicitación” está vinculado estrechamente a la primera fase de la

adquisición y análisis de requerimientos dado que su propósito es ganar conocimientos
relevantes del problema, que se u=lizarán para producir una especificación formal del
so@ware necesario para resolverlo.

Para que sirve?:

• Definir el proceso de desarrollo de requerimientos

• Definir la visión y alcance del sistema

• Identificar los tipos y clases de usuarios seleccionando los usuarios claves

(stakeholders)

• Establecer las técnicas de elicitación apropiadas

• Aplicar las técnicas de elicitación para identificar los requerimientos del usuario

• Aplicar las técnicas de elicitación para identificar las restricciones del usuario

• Analizar los problemas encontrados en el proceso de elicitar.

• Solucionar los problemas encontrados

Técnicas de Elicitación

• Entrevistas:

Son reuniones en las que se plantean una serie de preguntas para obtener las
correspondientes respuestas en el contexto de un determinado dominio de
problemas (Cerradas-Abiertas)

• Estudio de documentación:

El estudio de documentación consiste en realizar una lectura en profundidad

basada en documentos sobre el dominio del problema del sistema a desarrollar.

Manuales de procedimientos y funciones, informes generados por el sistema

actual, normativas y legislaciones, manuales de usuario del sistema actual

• Observación:

IR IN SITU AL LUGAR A OBSERVAR. Además, se debe intentar que los

resultados de la práctica profesional sean observables en el entorno real de
trabajo.

• JAD (Joint Application Development):

Es una técnica de definición de requisitos y de diseño de la interfaz de

usuario, basada en reuniones participativas entre clientes, directiva y
desarrolladores

• Tormenta de ideas:

Es una sesión de trabajo estructurada orientada para obtener la mayor

cantidad de ideas posibles.

• Talleres de trabajo:

Es una técnica efectiva para obtener información rápidamente de varias

personas.

Es recomendable tener una agenda predefinida y preseleccionar a los

participantes, siguiendo buenas prácticas para reuniones efectivas.
 Se puede uBlizar un material común sobre el cual enfocar la atención y
conversar, por ejemplo una presentación con un desglose del proceso que se
está estudiando o un flujograma.

• Historias de Usuario:

Las historias de usuario, son una aproximación simple al levantamiento de

requerimientos de software, en la cual la conversación pasa a ser más
importante que la formalización de requerimientos escritos. (Como-Quiero-
Para)

Triple Restricción

Tiempo

Alcance Costo

• Tiempo (¿Cuándo?)

• Expresa la duración del proyecto, aquí se deben controlar en la fase de

seguimiento que las acBvidades se ejecuten en Bempo y forma.

• El líder deberá tener presente la fase en que se encuentra el proyecto y el

estado de las acBvidades en ejecución.

• Costo (¿Cuánto?)

• Es el costo de los recursos materiales y humanos que se deberán uBlizar en

proyecto de acuerdo al alcance definido y el Bempo pacto.
• Alcance (¿Qué?)

Delimita los objeBvos del proyecto en entregables para el cliente. En el desarrollo

de so>ware es aquello que se construirá y entregará.

Suele tener forma de un documento que es pactado y firmado por las partes
involucradas.

Indicadores de Fases

Se puede decir que el cronograma de un proyecto esta correctamente planificado

si el % de Bempo asignado a los recursos se corresponde con los siguientes
indicadores:

Inicio 10%

Planificación 15%

Ejecución y Control 70%

Cierre 5%

• Características para la buena gestión de proyectos:

Que sea visible y público: que el proyecto no sea una caja negra, dar visibilidad
y conocimiento a la empresa de lo que se está desarrollando.

Que sea medible: significa que en cualquier punto del proyecto podemos decir:
vamos al 30%, 40%, vamos atrasados, etc.

Que sea predecible: queremos saber que sucederá la semana que viene, que
recursos deberemos contratar para el mes entrante, etc.

Que sea repeBble: debemos tener una metodología que permita enfocar todos
los proyectos de la misma forma para poder replicarla en otros proyectos.
LAS 4 P
Personas:
Son los principales autores de un proyecto de So>ware, compuestos por
arquitectos, desarrolladores, ingenieros de pruebas, y personal de GesBón
Proceso:
El término proyecto hace referencia a la planificación o concreción de un
conjunto de acciones/ tareas que se van a llevar a cabo para conseguir un
fin determinado, unos objeBvos concretos, estos pueden ser un producto,
un servicio o un resultado
Proyecto:
La gesBón de proyectos debe asegurar que se mantenga la relación de
equilibrio entre tres factores claves
Tiempo

Alcance Costo

Productos:
Son los artefactos diseñados a lo largo del proyecto, incluyen a:
Especificación de Requerimientos de so>ware
Arquitectura de So>ware
Modelos de Diseño
Código Fuente - Componentes
Casos de prueba
Test automaBzados
Documentación de gesBón
Producto

MODELOS DE PROCESOS

• Modelo en Cascada:

Es un enfoque lineal y secuencial donde cada fase (como requerimientos, diseño,

implementación, pruebas) debe completarse antes de comenzar la siguiente. No
hay retroceso a fases anteriores una vez que se ha avanzado. Es útil cuando los
requisitos son muy claros y fijos.
• Modelo Incremental:
Combina elementos de los modelos lineal y prototipos. Desarrolla el software en
incrementos o módulos pequeños, añadiendo funcionalidades con cada nueva
versión. Permite la retroalimentación y adaptaciones tras cada incremento,
siendo flexible a los cambios de requerimientos.

• Modelo de Proceso Evolutivo:

Existen dos formas de enfrentar el cambio y los requerimientos nuevos de un

sistema:

Proto9pos de sistema:
• Se desarrollar una versión del sistema o parte del mismo.
• Comprobar los requerimientos del cliente.
• Fac9bilidad de Desarrollo

Espiral o Incrementos
o Se entregan al cliente incrementos del sistema para su experimentación
en un entorno operativo.
o Si se aprueba el incremento, de detalla el requerimiento se desarrolla.

Ventajas:
§ Este modelo es útil cuando el cliente conoce los objetivos generales para
el software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida.
§ También ofrece un mejor enfoque cuando el responsable del desarrollo
del software está inseguro de la eficacia de un algoritmo, de la
adaptabilidad de un sistema operativo o de la forma que debería tomar la
interacción humano-máquina.

Desventajas:
● Se prioriza la velocidad dejando de lado la calidad, muchas veces transmi9r
esto puede generar problemas.
● Es pos de la velocidad hay veces que no se toman decisiones apropiadas en el
desarrollo y a la larga pasan a ser parte del sistema y del mantenimiento.
● Puede tener excesivos cambios
MODELO ESPIRAL (EVOLUTIVO)

- El modelo espiral es un enfoque realista para el desarrollo de sistemas y de

sogware a gran escala. Como el sogware evoluciona a medida que el proceso
avanza, el desarrollador y cliente comprenden y reaccionan mejor ante los
riesgos en cada nivel de evolución.

- El modelo espiral usa proto9pos para reducir riesgos y esto puede ser usado en
cualquier parte del proyecto.

- Este modelo contempla los riesgos en todas las etapas del proyecto

- Es un modelo complicado de encarar ya que permanentemente se está

controlando los posibles riesgos y para ello se requiere bastante experiencia en
este campo.

El modelo de desarrollo concurrente (EVOLUTIVO)

En ocasiones llamado ingeniería concurrente, permite que un equipo de sogware

represente elementos itera9vos y concurrentes de cualquiera de los modelos de
proceso descritos en esta presentación.

Por ejemplo, la ac9vidad de modelado definida para el modelo espiral se logra por
medio de invocar una o más de las siguientes acciones de sogware:

§ Hacer proto9pos,
§ Análisis
§ Diseño.

Pros
§ Excelente para proyectos en los que se conforman grupos de trabajos
independientes.
§ Proporciona una imagen exacta del estado actual de un proyecto.
Contras
§ Sino se dan las condiciones indicadas no es aplicable.
§ Sino existen grupos de trabajo no es aplicable.
• Modelo de Casos de Uso

Diagrama de casos de uso

Diagrama de Secuencia
Diagrama de estado - ac2vidad

Diagrama de secuencia
DIAGRAMA DE ENTIDAD-RELACION (DER)

Diagrama de contexto