Sistemas De Informacion I - Unidad I.pdf

Sistemas de

Información I

LIC. CLAUDIO D. FERNANDEZ 2019

¡Bienvenidos! Nos presentamos… Nombre y Apellidos. Especialidad y ciclo de estudios. ¿Trabaja, además de estudiar? ¿Qué espera del curso? Lic. Claudio Darío Fernandez - [email protected]

OBJETIVOS ❑

Conocer las características del Proceso de Obtención de Requerimientos.

❑

Poder discriminar según la taxonomía los requerimientos, confeccionar el documento de visión y alcance.

❑

Conocer los propósitos y utilidad de la modelización.

❑

Entender los conceptos básicos de la orientación a objeto.

❑

Conocer los propósitos y poder realizar los distintos diagramas que posee el UML como notación para la modelización de sistemas.

❑

Conocer la metodología del Proceso Unificado para la realizar la construcción de software.

❑

Poder entender las diferencias entre las distintas metodologías ágiles y poder aplicarlas

Contenidos Programáticos ❑

UNIDAD TEMATICA 1: TEORIA GENERAL DE SISTEMAS

❑

UNIDAD TEMATICA 2: REQUERIMIENTOS E INTRODUCCION

❑

UNIDAD TEMATICA 3: EL PARADIGMA ORIENTADO A

❑

UNIDAD TEMATICA 4: DIAGRAMAS UML

❑

UNIDAD TEMATICA 5: METODOLOGIAS DE DESARROLLO

❑

UNIDAD TEMATICA 6: SISTEMAS COLABORATIVOS

A UML

OBJETO USANDO UML

DE SOFTWARE

Bibliografía ❑ James Rumbaugh, Ivar Jacobson, Grady Booch El Lenguaje Unificado de Modelado Manual de Referencia Addison Weesley 2000

❑ James Rumbaugh, Ivar Jacobson, Grady Booch El Proceso Unificado de Desarrollo de Software Addison Weesley 2000

❑ Joseph Shmuller Aprendiendo UML en 24 horas Prentice Hall 2000

Contenidos Programáticos – Unidad 1 ❑

1.1. Teoría general de sistemas.

❑

1.2. Ciclo de vida de desarrollo de sistemas.

❑

1.3. Sistema de Información: administración.

Las tres habitaciones Tienes que elegir entre tres habitaciones: a) En la primera, hay un incendio. b) La segunda está llena de tigres que no han comido en 3 meses. c) Y la tercera está llena de asesinos con ametralladoras cargadas. ¿Qué habitación escogerías?

Vender la verdad Un fabricante afirmó que, si la gente de mediana edad dijera la verdad con más frecuencia, él vendería muchísimos más productos. ¿Qué fabricaba? La anciana, el amigo y la pareja

Una noche de fuerte tormenta, vas conduciendo por la ciudad cuando ves en una parada de autobús a tres personas: – Un viejo amigo que te salvó la vida. – Una anciana que parece a punto de morir. – La pareja perfecta que siempre has querido conocer. Sólo puedes escoger a un pasajero ¿A quién llevarías en tu coche?

1.1. Teoría General de Sistemas

▪

La Teoría General de Sistemas (T.G.S.) es una materia que cada día ha adquirido mayor importancia y más adherentes en el campo científico.

▪

La T.G.S. a través del análisis de las totalidades y de las interacciones de éstas y de las externas con su medio es en la actualidad una poderosa herramienta que permite la explicación de los fenómenos que se suceden en la realidad y también hace posible la predicción de la conducta futura de esa realidad.

Orígenes Sistema

synistanai (reunir)

synistêmi (mantenerse juntos)

El término es introducido en la Filosofía entre el año 500 y 200 a. C. por Anáxoras, Aristóteles, Sexto Empírico y los Estóicos.

Específicamente se le atribuyen al filósofo alemán George Wilhem Friedrich Hegel (1770 – 1831) Y posteriormente al biólogo alemán Ludwig von Bertalanffy (1901-1972) por sus trabajos publicados entre 1950 y 1968

▪ La T.G.S. es una disciplina lógico-matemática, puramente formal en si misma pero aplicable a las varias disciplinas empíricas, es decir basadas en la experiencia u observación. Seria análoga a la teoría de la probabilidad, que siendo una disciplina matemática formal, es aplicable a campos de lo mas diverso.

▪ Se desprende de un principio clave que es la noción de la totalidad orgánica (holismo). Desde el punto de vista de la T.G.S. la realidad es única y es una totalidad que se comporta de acuerdo a una determinada conducta.

▪ La T.G.S. al abordar esa totalidad debe llevar consigo una visión integral y total. Es un enfoque de análisis para encarar fenómenos (complejos) como si fueran un sistema, como un todo, con toda sus partes interrelacionadas e interactuando entre si. ▪ Esto significa que es necesario disponer de mecanismos interdisciplinarios, ya que de acuerdo al enfoque reduccionista con que se ha desarrollado el saber científico hasta nuestra época, la realidad ha sido dividida y sus partes han sido explicadas por diferentes ciencias.

¿Qué es un Sistema? Es un conjunto de elementos interdependientes e inter-actuantes o un grupo de unidades combinadas que forman un todo organizado. Sistema es un conjunto o combinaciones de cosas o partes formando un todo unitario.

Todo sistema debe tener: • Estabilidad: Permite que el sistema funcione eficazmente frente a las acciones de los factores externos al mismo. • Adaptabilidad: Para que el sistema sea capaz de evolucionar. dinámicamente con arreglo en su entorno. • Eficiencia: Por lo cual el sistema atiende su objetivo. • Sinergia: Capacidad de actuación de un sistema total en mayor magnitud que la suma de las partes que lo componen.

Tipos de Sistemas Constitución

Naturaleza

Físicos

Cerrados

Abstractos

Abiertos

Tipos de Sistemas - según su constitución: Sistemas Físicos o Concretos

Sistemas Abstractos

Equipos, maquinaria, objetos.

Conceptos, planes, hipótesis, ideas. Software

Hardware

Tipos de Sistemas - según su naturaleza: Sistemas Cerrados

Sistemas Abiertos

✓ No presentan intercambio con el medio ambiente que los rodea.

✓ Presentan intercambio con el ambiente, a través de entradas y salidas.

✓ Opera con muy pequeño intercambio de energía y materia con el ambiente.

✓ Intercambian energía y materia con el ambiente .

✓ Son herméticos a cualquier influencia ambiental.

✓ No pueden vivir aislados.

✓ Su comportamiento es determinístico y programado.

✓ Son adaptativos para sobrevivir.

Tipos de Sistemas: Confrontación entre Teoría de Sistema Cerrado y de Sistema Abierto El sistema cerrado 

El sistema cerrado no puede sobrevivir en la medida en que no consigue responder de forma eficaz a los cambios continuos y rápidos del ambiente

El sistema abierto 

El sistema abierto ofrece al ambiente los productos que necesita y si es el caso, crea en el la necesidad de dichos productos, pues únicamente así garantiza la absorción de los productos y la provisión de insumos

Parámetros de los Sistemas

ENTRADAS Información Energía Recursos Materiales

TRANSFORMACION O PROCESAMIENTO

SALIDAS Información Energía Recursos Materiales

AMBIENTE

AMBIENTE

Son constantes arbitrarias que caracterizan, por sus propiedades, el valor y la descripción dimensional de un sistema específico o de un componente del sistema. El concepto de sistema abierto se puede aplicar a diversos niveles de enfoque: al nivel del individuo, del grupo, de la organización y de la sociedad.

Parámetros de los Sistemas 1. Entrada o Insumo o Impulso (INPUT) ✓ Proveed el material o la energía para la operación del sistema 2. Salida o Producto o Resultado (OUTPUT) ✓ Finalidad para la cual se reunieron elementos y relaciones del sistema. 3. Procesamiento, Procesador o Transformador (THROUGHPUT) ✓ Mecanismo de conversión de las entradas en salidas o resultados. 4. Retroacción o Retroalimentación o Retroinformación (FEEDBACK) ✓ Función de retorno del sistema que tiende a comparar la salida con un criterio preestablecido. 5. Ambiente o Medio ✓ Medio que envuelve externamente el sistema . La supervivencia de un sistema depende de su capacidad de adaptarse, cambiar y responder a las exigencias y demandas del ambiente externo.

Caract. Básicas del Análisis Sistémico ✓

Punto de vista Sistemático

✓

Enfoque dinámico

✓

Multidimensional y Multinivelado

✓

Multimotivacional

✓

Probabilístico

✓

Multidisciplinaria

✓

Descriptivo

✓

Multivariable

✓

Adaptativa

Aplicaciones

CIBERNETICA

TEORIA DE LA INFORMACION

TEORIA DE JUEGOS

TEORIA DE DESICIONES

TOPOLOGIA

ANALISIS FACTORIAL

INGENIERIA DE SISTEMAS

INVESTIGACION DE OPERACIONES

Para reflexionar “Por la falta de un clavo fue que la herradura se perdió. Por la falta de una herradura fue que el caballo se perdió. Por la falta de un caballo fue que el caballero se perdió. Por la falta de un caballero fue que la batalla se perdió. Y así como una batalla, fue que un reino se perdió. Y todo porque fue un clavo el que faltó”. Jacula Prudentum (1651) Recopilación hecha por George Herbert

Sistema de Información

Se considera: ▪

una actividad como un conjunto de tareas

▪

una tarea como una acción que transforma entrada en salida.

Abarca: ▪

toda la vida del sistema : desde su concepción hasta su fin.

▪

El ciclo de desarrollo : es un sub conjunto del ciclo de vida

▪

empieza en el análisis

▪

finaliza en la entrega del sistema al usuario.

▪ El Ciclo de Vida de un sistema de información (SDLC, Systems Development life cycle) es una metodología usada para facilitar el desarrollo de los sistemas.

1.2. ▪ Es un enfoque por fases para el análisis y diseño cuya premisa consiste en que los Ciclo de elsistemas se desarrollan mejor utilizando un ciclo especifico de actividades del vida de analista y el usuario. (Kendall & Kendall). ▪ Ayudan a los gestores de proyecto con la desarrollo planificación y la puesta en marcha de un sistema de información el cual debe software cumplir con los requisitos del usuario, debe ser completado a tiempo y dentro de los límites del presupuesto.

Etapas del Procesos de Desarrollo de Metodología Kendall & Kendall Software 1. Identificación de problemas, oportunidades y objetivos

3. Análisis de las necesidades del sistema

2. Determinación de los requerimientos de información

5. Desarrollo y documentación del software

4. Diseño del sistema recomendado

7. Implantación y evaluación del sistema

6. Pruebas y mantenimiento del sistema

FASES del Ciclo SDLC, Systems Development life cycle

FASE 1. Identificación de problemas, oportunidades y objetivos En esta etapa se deberá descubrir lo que la organización intenta realizar, luego determinar si el uso de los sistemas de información apoyaría a la organización para alcanzar sus metas. Observación directa del entorno.

FASE 2. Determinación de los requerimientos de información Esto se hace a partir de los usuarios particularmente involucrados, para determinar los requerimientos de información dentro de una organización pueden utilizarse diversos instrumentos, los cuales incluyen: muestreo, el estudio de los datos y formas usadas para la organización, la entrevista, los cuestionarios; la observación de la conducta de quien tomó las decisiones.

FASES del Ciclo SDLC, Systems Development life cycle

FASE 3. Análisis de las necesidades del sistema Se analizan las necesidades propias del sistema. También se analizan las decisiones estructuradas por realizar, que son decisiones donde las condiciones, condiciones alternativas, acciones y reglas de acción

FASE 4. Diseño del sistema recomendado Se usa la información recolectada con anterioridad y se elabora el diseño lógico de sistemas de información, esta etapa también incluye el diseño de los archivos o la base de datos que almacenará aquellos datos requeridos por quien toma las decisiones en la organización.

FASES del Ciclo SDLC, Systems Development life cycle

FASE 5. Desarrollo y documentación del software Dentro de las técnicas estructuradas para el diseño y documentación del software se tienen: método HIPO, los diagramas de flujo, los diagramas UML y el pseudocódigo. Es aquí donde se transmite al programador los requerimientos de programación. Diseño y Codificación. FASE 6. Pruebas y mantenimiento del sistema Todo sistema de información debe probarse antes de ser utilizado, ya que el costo es menor si se detectan los problemas antes de que entre en funcionamiento. FASE 7. Implantación y evaluación del sistema. Esta es la última etapa del desarrollo del sistema, esto incluye el adiestramiento que el usuario requerirá. Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado.

FASE I. Identific. problemas, oportun. y objetivos Intervienen los analistas y diferentes miembros de la organización: • Aplicación de entrevista para recolectar información. • Sintetizar la información recolectada para construir objetivos. • Estimar el alcance del proyecto. • Identificar si existe una necesidad, problema u oportunidad. • Identificar las reglas del negocio. • Documentar resultados. • Estudiar los riesgos del proyecto. • Presentar un informe de viabilidad/factibilidad. • Trazar objetivos/planes de ejecución

FASE I. Identific. problemas, oportun. y objetivos En este momento el analista deberá evaluar todos los problemas/riesgos existentes, normalmente son detectados por terceros y para esto es llamado el analista, también se debe saber que desea la empresa como objetivo para así, lograr que el sistema computarizado logre cumplirlos. Los resultados se dan a través de un informe y la administración es la que decidirá si continuar o no con el proyecto propuesto.

FASE I. Identificación de problemas, oportunidades y objetivos Errores Comunes. ❖

Abreviar las etapas iniciales del proceso de desarrollo de software (planificación y análisis, generalmente) para pasar directamente a la "construcción" del sistema.

❖

No gestionar adecuadamente los cambios que inevitablemente ocurren durante el proyecto.

❖

Reducir la interacción con el cliente.

❖

No informar de pequeños retrasos pensando que más tarde se recuperará el tiempo perdido.

FASE II. Determinación de los requerimientos de información. Determinar los requerimientos de Información es el ¿Qué?. Lo primero que debemos hacer para construir un sistema es averiguar qué es exactamente lo que tiene que hacer el sistema. Esta etapa en el ciclo de vida del software corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer).

FASE II. Determinación de los requerimientos de información. El analista debe comprender la información que necesitan los usuarios para poder lograr todas sus actividades, deberá determinar que tipo de herramientas se utilizarán y para ello deberá pensar en métodos interactivos para los requerimientos tanto de muestreos como de datos impresos, métodos que no interfieran con el usuario y así los encargados, tomar las decisiones para elaborar prototipos de dicho sistema. Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

FASE II. Determ. los requerimientos de información. • Deberemos cumplimentar las siguientes tareas: revisión de los objetivos, identificar el dominio, investigar la razón por la cual se implementa el sistema actual, recolectar información sobre los procedimientos y operaciones que se desempeñan actualmente. • Detallar específicamente: Quiénes son los involucrados, cuál es la actividad, regla y restricciones del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada función, la manera en que se desempeñan los procedimientos actuales. • Elaborar una lista detallada y organizada de todos los procedimientos. • Separar requerimientos funcionales y no funcionales. Adicionar al informe de la primera fase, esta nueva información.

FASE III. Análisis de las necesidades del sistema. Al comenzar esta fase se deberá evaluar las dos fases anteriores y con esta información se realizará: • Modelado de las entradas, los procesos y las salidas de las funciones ya identificadas. • Se elaborará un diccionario de datos y sus especificaciones. • Se elaborarán diagramas de procesos de cada función. • Se elaborará una propuesta del sistema con todos los diagramas de operaciones y de procesos. • Se realizará el análisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto económico, técnico y operacional (estudio de factibilidad) • Se estimará en un diagrama de Gantt el tiempo que tomará desarrollar el sistema.

FASE III. Análisis de las necesidades del sistema. Estas tareas se llevarán a cabo utilizando herramientas tales como diagramas de flujo, UML, entre otros posibles, para graficar las entradas, los procesos y las salidas de las funciones del sistema. Con la ayuda del diagrama de flujo de datos se iniciará con el diccionario de datos que enliste completamente los datos utilizados en el sistema y sus funciones o especificaciones. En esta fase podría hacerse una propuesta del sistema

FASE IV. Diseño del sistema recomendado. Al igual que la fase anterior, se toma en cuenta las fases anteriores para comenzar con el diseño lógico de nuestro sistema, con ello se busca los procedimientos precisos para la captura de datos y que estos sean correctos, facilitando la entrada eficiente de datos mediante técnicas de diseño como pantallas y formularios. El analista interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. Recordemos que esta fase representa el ¿Cómo?. Cómo vamos a diseñar todo lo que hemos analizado en las fases anteriores.

FASE IV. Diseño del sistema recomendado. En esta fase deberemos: • Realizar el diseño lógico de todo el sistema. • Elaborar procedimientos precisos para la captura de los datos que se ingresarán. • Elaborar el diseño de la base de datos. • Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función. • Diseñar controles y procedimientos de respaldos que protejan al sistema y datos. • Producir los paquetes específicos de programas/diagramas para los programadores. • Elaborar una lista de las funciones genéricas y de las que será obligatorio crear.

FASE IV. Diseño del sistema recomendado. Un software bien diseñado debe exhibir determinadas características: ▪

Su diseño debería ser modular. Sus módulos deberían encargarse de una tarea concreta y sólo de una y estar débilmente acoplados entre sí (para facilitar el mantenimiento del sistema). Cada módulo debería ofrecer a los demás módulos, interfaces bien definidas y ocultar sus detalles de implementación.

▪

Debe ser posible relacionar las decisiones de diseño tomadas con los requerimientos del sistema que las ocasionaron (algo que se suele denominar "trazabilidad de los requerimientos").

▪

Es necesario abordar el diseño de la base de datos.

▪

También hay que diseñar las aplicaciones que permitirán al usuario utilizar el sistema como así también las interfaces y los distintos componentes en que se descomponen las aplicaciones.

FASE V. Desarrollo y documentación del software. Una vez que tenemos definido el ¿Qué? (Determinación de Requerimientos)y el ¿Cómo? (Diseño) podemos dar paso a la etapa de Desarrollo, pero nunca antes. Antes de empezar a escribir el código de nuestro desarrollo o crear la base de datos, necesitamos tener bien en claro la problemática que debemos resolver. El analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software.

FASE V. Desarrollo y documentación del software. Se trabaja de manera conjunta con los programadores para el desarrollo de software necesarios y originales. Para esta fase debemos de seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite nuestro trabajo y un lenguaje de programación apropiado para el tipo de sistema que vayamos a construir. La elección de estas herramientas dependerá en gran parte de las decisiones de diseño que hayamos tomado hasta el momento y del entorno en el que nuestro sistema deberá funcionar.

FASE V. Desarrollo y documentación del software. Para llevar a cabo esta fase deberemos: • Evaluar los procedimientos que va a ser desarrollados por el programador. • Mostrar y explicar cada procedimiento, función y operación al programador. • Elaborar manuales de procedimientos internos del sistema. • Elaborar manuales externos de ayuda a los usuarios del sistema. • Elaborar demostraciones para los usuarios y la interacción con distintas interfaces. • Elaborar actualizaciones para los diferentes procedimientos. • Elaborar un informe con el tiempo que se llevó construir cada procedimiento.

FASE V. Desarrollo y documentación del software. Recordatorio: A la hora de programar, deberemos procurar que nuestro código no resulte indescifrable. Para que nuestro código sea legible, debemos elegir cuidadosamente los identificadores de nuestras variables, seleccionar algoritmos y estructuras de datos adecuadas para nuestro problema, mantener la lógica de nuestra aplicación lo más sencilla posible, comentar adecuadamente el texto de nuestros programas y, por último, facilitar la interpretación visual de nuestro código mediante el uso de sangrías y líneas en blanco que separen distintos bloques de código.

FASE V. Desarrollo y documentación del software. Recordatorio: Control de versiones En todo proyecto de desarrollo de software resulta fundamental una adecuada gestión de la configuración del software, más conocida control de versiones

FASE VI. Pruebas y mantenimiento del sistema. En esta etapa de depuración, deberemos: • Realizar la programación de las pruebas del sistema. • Realizar un instrumento para evaluar el sistema de información. • El programador deberá elaborar un resumen de las pruebas del sistema. • El analista deberá realizar un informe de sus pruebas y discutirlo con el programador. • Elaborar la planificación de las horas del mantenimiento del sistema. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos.

FASE VI. Pruebas y mantenimiento del sistema. Se prueba el sistema antes de ponerlo en completo funcionamiento y así será mucho menos costoso al encontrar los problemas que tenga antes de que el usuario comience a implementarlo o usarlo, una parte de esta prueba la hacen los programadores por su cuenta y otra la llevan a cabo de manera conjunta con el analista del sistema, empezando con datos de muestras y luego con datos reales del sistema actual

FASE VI. Pruebas y mantenimiento del sistema. La búsqueda de errores en la etapa de pruebas puede adaptar distintas formas, en función del contexto y de la fase del proyecto en la que nos encontremos: ▪

Las pruebas de unidad sirven para comprobar el correcto funcionamiento de un componente concreto de nuestro sistema. Es este tipo de pruebas, el "probador" debe buscar situaciones límite que expongan las limitaciones de la implementación del componente, ya sea tratando éste como una caja negra ("pruebas de caja negra") o fijándonos en su estructura interna ("pruebas de caja blanca"). Resulta recomendable que, conforme vamos añadiéndole nueva funcionalidad a nuestras aplicaciones, vayamos creando nuevos tests para medir nuestro progreso y también repitamos los antiguos para comprobar que lo que antes funcionaba sigue funcionando.

FASE VI. Pruebas y mantenimiento del sistema. La búsqueda de errores en la etapa de pruebas puede adaptar distintas formas, en función del contexto y de la fase del proyecto en la que nos encontremos: ▪

Las pruebas de integración son las que se realizan cuando vamos juntando los componentes que conforman nuestro sistema y sirven para detectar errores en sus interfaces.

FASE VI. Pruebas y mantenimiento del sistema. •

Una vez "finalizado" el sistema, se realizan pruebas alfa por parte de la empresa encargada del desarrollo del sistema. Estas pruebas, realizadas desde el punto de vista de un usuario final, pueden ayudar a pulir aspectos de la interfaz de usuario del sistema

•

Cuando el sistema no es un producto a medida, sino que se venderá como un producto en el mercado, también se suelen realizar pruebas beta. Estas pruebas las hacen usuarios finales del sistema ajenos al equipo de desarrollo y pueden resultar vitales para que un producto tenga éxito en el mercado.

FASE VI. Pruebas y mantenimiento del sistema. •

En sistemas a medida, se suele realizar un test de aceptación que, si se supera con éxito, marcará oficialmente el final del proceso de desarrollo y el comienzo de la etapa de mantenimiento.

•

Por último, a lo largo de todo el ciclo de vida del software, se suelen hacer revisiones de todos los productos generados a lo largo del proyecto, desde el documento de especificación de requerimientos hasta el código de los distintos módulos de una aplicación. Estas revisiones, de carácter más o menos formal, ayudan a verificar la corrección del producto revisado y también a validarlo (comprobar que se ajusta a los requerimientos reales del sistema).

FASE VI. Pruebas y mantenimiento del sistema. Podemos citar tres tipos de mantenimientos: ▪

Eliminar los defectos que se detecten durante su vida útil (mantenimiento correctivo), lo primero que a uno se le viene a la cabeza cuando piensa en el mantenimiento de cualquier cosa.

▪

Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistema ha de funcionar sobre una nueva versión del sistema operativo o en un entorno hardware diferente, por ejemplo.

▪

Añadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponen características deseables que supondrían una mejora del sistema ya existente.

FASE VII. Implantación y evaluación del sistema. Ya en la etapa de instalación del software desarrollado, tenemos que planificar/testear el entorno en el que el sistema debe funcionar, tanto hardware como software: equipos necesarios y su configuración física, redes de interconexión entre los equipos y de acceso a sistemas externos, sistemas operativos, bibliotecas y componentes suministrados por terceras partes, etcétera.

FASE VII. Implantación y evaluación del sistema. Para ello debemos: • Planificar gradualmente la conversión del sistema anterior. • Instalar los equipos de hardware necesarios para el funcionamiento del software creado. • Capacitar a los usuarios en el manejo de equipos y software creados. • Evaluar la adaptabilidad de los usuarios al sistema. • En esta última fase se debe capacitar no solo a los usuarios si no que también a todas las personas que puedan tener tanto un contacto directo como indirecto con el mismo, esta capacitación la imparten los fabricantes en conjunto con los analistas del sistema.

FASE VII. Implantación y evaluación del sistema. El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar a la fase previa y modificar el trabajo realizado.

Modelos de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.Describe las fases principales de Desarrollo de software. Ayuda a administrar el progreso del Desarrollo, y prove un espacio de trabajo para la definicion de un detallado proceso de Desarrollo.

Modelos de Ciclo de Vida

Es un proceso (normativo) que provee una solución (modelo) para el desarrollo de un sistema. Identifica etapas y secuencia en el Desarrollo. Encapsula el conocimiento de casos pasados Facilita el desarrollo de nuevos casos Etapas: Identificación de requerimientos, Diseño (lógico y físico), implantación, testeo y Puesta en marcha, operación, y mantención

Modelos de Ciclo de Vida

Ventajas •„ Evita partir de cero en cada proyecto. • Pone el énfasis en el proyecto mismo, en vez de la forma de desarrollarlo • Comúnmente aceptado (lenguaje común) Desventajas • Inflexibilidad en la adaptación a casos particulares. • Bajo nivel de cuestionamiento al adoptarlo.

Modelos de Ciclo de Vida

Modelos de Ciclo de Vida

Modelos de Ciclo de Vida – Espiral El modelo espiral de Boehm consta de una serie de ciclos. Cada uno empieza identificando sus objetivos, alternativas y restricciones. hace especial hincapié en la prevención de riesgos: Se evalúa las alternativas respecto a los objetivos tomando en cuenta las restricciones. Una vez finalizado se plantea el próximo ciclo. Este modelo define cuatro actividades principales: ▪

Planificación (determinar los objetivos, alternativas y restricciones del proyecto)

▪

Análisis de riesgos (análisis de alternativas e identificación/resolución de riesgos),

▪

Ingeniería (desarrollo del producto)

▪

Evaluación (revisión por parte del cliente y valoración de los resultados obtenidos de cara a la siguiente iteración).

En cada iteración alrededor de la espiral se construyen versiones cada vez más completas del software.

Modelos de Ciclo de Vida – Espiral

Modelos de Ciclo de Vida – Espiral Una vez realizado el primer ciclo se vuelve ha empezar. Cada ciclo se completa con una revisión. Las características del método Espiral son: ▪

Existe conocimiento explicito de las diferentes alternativas a alcanzar

▪

La identificación de riesgos asociado a cada alternativa y como resolverlos.

▪

División de proyecto en ciclos, y cada uno con un acuerdo final de ciclo

▪

El modelo se adapta a cualquier tipo de actividad

Modelos de Ciclo de Vida – Clásico o Cascada El modelo de ciclo de vida clásico, también denominado "modelo en cascada", se basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre. Es el modelo mas antiguo, propuesto por Winston Royce en1970. Es un modelo orientado en las actividades Algunas Características: ✓

Se pasa, en orden, de una etapa a la siguiente sólo tras finalizar con éxito las tareas, de verificación y validación, propias de la etapa. Si resulta necesario, únicamente se da marcha atrás hasta la fase inmediatamente anterior.

✓

Ayuda a prevenir que se sobrepasen la fecha de entrega y los costos esperados

✓

Al final de cada fase técnicos y usuarios tienen la oportunidad de revisar el proceso del proyecto.

Modelos de Ciclo de Vida – Clásico o Cascada Ciclo de Vida Clásico o Cascada - Fortalezas ❑

Fácil entendimiento e implementación

❑

Ampliamente utilizado y conocido (En teoría)

❑

Refuerza buenos hábitos: definir antes que diseñar, diseñar antes que codificar

❑

Identifica entregables e hitos

❑

Orientado a documentos

❑

Funciona bien en productos maduros y equipos débiles

Modelos de Ciclo de Vida – Clásico o Cascada Ciclo de Vida Clásico o Cascada – Debilidades ▪

Los proyectos reales raramente siguen el flujo secuencial de actividades que propone este modelo. (REALIDAD VS DISEÑO/ficción)

▪

No aprovecha la iteración, ni el desarrollo exploratorio

▪

Es difícil para el cliente establecer todos los requisitos al comienzo del proyecto (entre otras cosas, porque hasta que no vea evolucionar el proyecto no tendrá una idea clara de qué es lo que realmente quiere).

▪

Dificultar para integrar administración del riesgo

▪

La versión operativa del sistema se entrega en la etapa final del proyecto, es decir hacer cambios es difícil y costoso, también esto hace que se detecten errores graves muy tarde.

Modelos de Ciclo de Vida – Clásico o Cascada FASE 1. Identificación FASE 2. Determinación FASE 3. Análisis FASE 4. Diseño FASE 5. Desarrollo FASE 6. Pruebas FASE 7. Implantación

Modelos de Ciclo de Vida – en V ❑

El mayor inconveniente del modelo de cascada es que solo se pasa a la siguiente fase cuando se completa la anterior, por tanto no es posible volver atrás si se encuentra algún error en las etapas posteriores. El Modelo V aporta opciones de evaluación del software en cada etapa de manera inversa.

❑

En cada etapa, se crea la planificación de las pruebas y los casos de pruebas para verificar y validar el producto según los requisitos de la etapa. Por ejemplo, en la etapa de recolección de requisitos, el equipo de evaluadores prepara las pruebas de caso correspondientes a los requisitos. Más tarde, cuando el producto se desarrolla y está preparado para ser evaluado, las pruebas de caso en esta etapa verifican el software y su validez según sus requisitos.

❑

Esto hace que tanto la verificación como la validación vayan en paralelo. Este modelo también se conoce como modelo de validación y verificación.

Modelos de Ciclo de Vida – en V

Modelos de Ciclo de Vida – en V

Modelos de Ciclo de Vida – Prototipado Desarrollo de prototipos El prototipado permite al cliente evaluar en forma temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo con las expectativas y las funcionalidades acordadas. Esto en manera especial si el cliente es capaz de definir un conjunto general de objetivos para el sistema que hemos de construir, pero no identifica los requisitos detallados. En otros casos, puede que nosotros no estemos seguros de la eficiencia de un algoritmo, de la capacidad de nuestro diseño para soportar los requerimientos del sistema o de la forma en que debe diseñarse la interfaz de usuario.

Modelos de Ciclo de Vida – Prototipado Desarrollo de prototipos En cualquiera de estas situaciones, resulta adecuado construir un prototipo, ya que da una idea concreta de lo que va a hacer el sistema, aunque no poseen la funcionalidad total del sistema, y se aplica cuando la rapidez de desarrollo es esencial. De cada prototipo se extraen ideas buenas que se usan para el siguiente prototipo (usar y tirar)

Modelos de Ciclo de Vida – Clásico o Cascada Prototipos FASE 1. Identificación

FASE 2. Determinación FASE 3. Análisis

FASE 4. Diseño FASE 5. Desarrollo

PROTOTIPO

FASE 6. Pruebas PROTOTIPO

PROTOTIPO

FASE 7. Implantación

Modelos de Ciclo de Vida – Prototipos

Modelos de Ciclo de Vida – Iterativos ANALISIS

ANALISIS

ANALISIS

DISEÑO

DISEÑO

DISEÑO

CODIFICACION

CODIFICACION

CODIFICACION

PRUEBAS

PRUEBAS

PRUEBAS

VERSION 1

VERSION 2

VERSION N

Los modelos iterativos consisten en descomponer un proyecto de desarrollo de software en una serie de subproyectos de menor envergadura. Estos subproyectos deben diseñarse de tal forma que cada uno de ellos aporte funcionalidad nueva para el sistema desde el punto de vista del usuario final del mismo.

Modelos de Ciclo de Vida – Iterativos Promueven una mejor comunicación con el usuario/cliente, ya que se dispondrá antes, de una versión operativa del sistema, aunque sea de funcionalidad reducida. Estas versiones intermedias del producto ayudan a la eliminación de malentendidos que pueden surgir en la etapa de obtención de requerimientos. Además, ayudan a que el usuario se forme una idea más clara de lo que realmente necesita.

Modelos de Ciclo de Vida – ¿Cascada o Iterativos? El modelo de desarrollo más adecuado para un proyecto dependerá del tipo de sistema que se ha de construir: ▪

En general, se elegirá un modelo cascada cuando los requerimientos se conocen bastante bien y son estables, cuando el diseño será similar al de otros sistemas con los que tenemos experiencia, cuando los integrantes del equipo de desarrollo ya se conocen y están familiarizado con el entorno de desarrollo.

▪

En la práctica, sin embargo, los modelos iterativos se adaptan mejor a la realidad del desarrollo de software (especialmente en sistemas medianos y grandes). Seleccionaremos un modelo iterativo cuando los requerimientos no se conocen con exactitud o se prevé que puedan cambiar en el futuro, cuando el diseño del sistema es complejo o no tiene precedentes para nosotros, cuando el proyecto en sí es arriesgado económicamente y cuando podamos controlar el costo de futuros cambios en el sistema.

Modelos de Ciclo de Vida – Metodo Agil - Scrum La agilidad en el corazón de los proyectos

Ser ágil significa ser una persona con ligereza y flexibilidad en los movimientos corporales, lo mismo se aplica a los ciclos de vida

Modelos de Ciclo de Vida – Metodo Agil - Scrum Desde el punto de vista del usuario:

• Scrum es un proceso ágil que permite focalizar en la entrega del mayor valor de negocio en el menor plazo. • El negocio fija las prioridades. Los equipos se autogestionan para determinar la mejor manera de entregar las funcionalidades de mayor prioridad. • Permite inspeccionar software listo para ser liberado en forma rápida y continua. • Al final de cada iteración se puede ver el software funcionando. • Se decide liberarlo como está o continuar mejorándolo durante otra iteración.

Modelos de Ciclo de Vida – Metodo Agil - Scrum Scrum desde el punto del equipo de trabajo:

• Equipos autoorganizados. • Usa reglas generativas para crear un entorno ágil para la ejecución de proyectos. • No se prescriben prácticas de ingeniería. • El producto avanza en una serie de iteraciones o (“sprints”) de 1 a 4 semanas. • Los requerimientos son capturados como ítems en la lista “Product backlog”. • Es uno de los “procesos ágiles”.

Scrum, un mix de métodos inspirados en sus primos: Los elementos de Lean Management: • Adaptación • Introspección • Uso de post-it • Gran interés por la calidad

Los elementos de Kanban: • Escritura de las necesidades del cliente en una etiqueta • Visualización del workflow del trabajo actual • Enfoque empírico

Los elementos del método eXtreme Programming (XP): • Realizar entregas frecuentes • Implementar un ritmo de trabajo duradero • Hace que el cliente sea una parte integrante del proyecto • Responsabilizar al equipo • Implementar las pruebas • Utilizar un Planning Poker para la estimación.

1.3. Sistema de Información: administración. La administración de un proyecto de sistema de información, consta de los siguientes pasos o procesos: • Iniciar el Proyecto • Supervisar y controlar el proyecto • Administrar la calidad del proyecto

1.3. Sistema de Información: Iniciar el Proyecto. Al iniciar un nuevo proyecto de sistema de información, llevaremos a cabo los siguientes pasos: • Responsable: Gerente del Proyecto • Entregable: Plan de Administración del Proyecto de Software (SPMP) • Propósito: • Establecer la correspondencia entre las actividades y el modelo del ciclo de vida del software • Asignar recursos al proyecto • Establecer el ambiente del proceso • Realizar la planeación de la administración del proyecto.

1.3. Sistema de Información: Iniciar el Proyecto. Básicamente el inicio de un nuevo proyecto de sistema de información, en general es: • • • • •

Definir el plan de tareas Definir el cronograma Definir el presupuesto Definir la organización del proyecto Definir el ambiente del proyecto: • Establecer los estándares • Establecer la Comunicación • Establecer los procedimientos de reunión y reporte • Establecer la metodología de desarrollo • Establecer las Herramientas de Desarrollo.

1.3. Sistema de Información: Supervisión y control del Proyecto. Bajo las tareas de Supervisión y Control, en general:

• Responsable: Gerente del Proyecto • Entregable: Plan de Administración del Proyecto de Software (SPMP) actualizado • Propósito: • Analizar los riesgos • Realizar la planificación de contingencias • Administrar el proyecto • Conservar registros • Implementa el modelo de reporte de problemas.

1.3. Sistema de Información: Administración de la Calidad Bajo las tareas de Administración de Calidad, en general:

• Responsable: Equipo de administración de Calidad • Entregable: Plan de Administración de la Calidad • Propósito: • Planear la administración de la calidad del software • Definir métricas • Administrar la calidad del software • Identificar las necesidades de mejora de calidad.

1.3. Sistema de Información: Administración de la Calidad Bajo las tareas de Administración de Calidad, en general:

• Responsable: Equipo de administración de Calidad • Entregable: Plan de Administración de la Calidad • Propósito: • Planear la administración de la calidad del software • Definir métricas • Administrar la calidad del software • Identificar las necesidades de mejora de calidad.