INSTITUTO TECNOLGICO DE TUXTEPEC

Fundamentos De Sistemas De Informacin

Actividad:

Resumen
Tercer semestre Grupo A
Presentado por: Correos: Turno:

Matutino

Ftima De Jess Martnez Lpez Iliana Pioquinto Barradas Itzayana Prez Ibez Indira Said Santiago Santiago Graciela Avendao Mendoza Mariano CDG

fatii-lopez1@hotmail.com jewel_iliz77@hotmail.com itza_120293@hotmail.com said_santiago@hotmail.com dominick_147@hotmail.com castromariano@facebook.com

Profesor:

Ma. De Los ngeles Martnez Morales

7/10/2012

PROCESOS DEL CICLO DE VIDA

El proceso de vida se divide en dos etapas: Las de los PROCESOS PRINCIPALES que son:

Adquisicin Suministro Desarrollo Explotacin mantenimiento PROCESOS DE SOPORTE Documentacin Gestin de configuracin Aseguramiento de calidad Verificacin Validacin Revisin conjunta auditoria resolucin de problemas PROCESOS DE LA ORGANIZACIN gestin mejora infraestructura formacin proceso de adaptacin

PROCESOS PRINCIPALES

Este proceso es til a los desarrolladores, usuarios del software durante su ciclo de vida

PRCESOS DE ADQUISICIN
Este proceso es sobre las tareas que el comprador, el cliente o el usuario realizan para adquirir un sistema o producto (servicio) software. Tambin en la Preparacin y publicacin de una solicitud de ofertas. En la Seleccin del suministrador del software. Y en la Gestin de los procesos desde la adquisicin hasta la aceptacin del producto.

PROCESOS DE SUMINISTRO
Se inicia al preparar una propuesta para atender una peticin de un comprador, o por la firma de un contrato con el comprador para proporcionarle un producto software. Tambin identifica los procesos y recursos para gestionar bien el proyecto. Desarrolla los planes del proyecto y ejecuta los planes del mismo hasta la entrega del producto software al comprador.

PROCESOS DE DESARROLLO
Esta contiene las actividades realizadas por el desarrollador. Y se sigue una serie de puntos como:

Implementacin del proceso. Anlisis de requisitos del Sistema. Diseo de la arquitectura del Sistema. Anlisis de los requisitos del Software. Diseo de la arquitectura del Software. Diseo detallado del software. Codificacin y prueba del Software. Integracin del software. Prueba del software. Integracin del sistema.
3

Prueba del sistema. Instalacin del software. Soporte del proceso de aceptacin del software.

PROCESO DE EXPLOTACIN
Se define a la explotacin del software y del soporte del mismo. El sistema debe ser operado de acuerdo con la documentacin del usuario en su entorno previsto. Se puede desarrollar un plan para llevar a cabo las actividades y tareas de este proceso. Tambin el proceso para comprobar el producto software en su entorno de operacin, enviando informes de problemas y peticiones de modificacin al proceso de mantenimiento.

PROCESO DE MANTENIMIENTO
El software o la documentacin necesitan ser modificado, debido a problemas o a necesidades de mejora o adaptacin como: nuevos errores detectados, necesidad de mejoras y migracin a un nuevo entorno operativo.

PROCESO DE SOPORTE
Sirve de apoyo al resto de procesos.

PROCESOS DE DOCUMENTACIN
Registra la informacin producida por cualquier proceso o actividad del ciclo de vida. Tambin gestiona los documentos necesarios para todas las personas involucradas en el software.

PROCESO DE GESTIN DE LA CONFIGURACIN

La configuracin del software involucra: programas, documentacin, y datos. En aplicaciones grandes, la gestin de la configuracin del software se convierte en un problema.

PROCESO DE ASEGURAMIENTO DE LA CALIDAD

Aporta confianza en que los procesos y los productos Software del ciclo de vida cumplen con los requisitos especificados y se ajustan a los planes establecidos. Y el
4

Aseguramiento de la calidad puede ser: interno o externo. Usa resultados de otros procesos de apoyo: verificacin, validacin, auditoras, etc.

PROCESO DE VERIFICACIN
Existen dos tipos horizontal y vertical. Verificacin horizontal: si los productos software de cada fase del ciclo de vida cumplen los requisitos impuestos sobre ellos en las fases previas. Verificacin vertical: Estamos construyendo correctamente el producto?

PROCESO DE VALIDACIN
Indica si el sistema o software final cumple con las necesidades del usuario. Tambin se puede validar una especificacin. Puede ser realizado por una organizacin de servicios independiente (proceso de validacin independiente).

PROCESODE REVISIN CONJUNTA

Evaluar el estado del software y sus productos en una actividad del ciclo de vida o fase del proyecto. Se realiza durante todo el ciclo de vida: a nivel de gestin, a nivel de gestin.

PROCESO DE AUDITORIA Tipos de auditora informtica:

De explotacin De sistemas De comunicaciones De desarrollo de proyectos De seguridad Fraudes y delitos econmicos producidos en las empresas (a veces por los propios empleados, sin conocimiento de la direccin) Problemas en privacidad y seguridad (auditoria de seguridad informtica, tanto lgica como fsica) La correccin de los datos de entrada (auditoria informtica de datos) Problemas de diseo del sistema informtico
5

LA INGENIERA DE SOFTWARE EN EL MODELO DE DESARROLLO DEL SOFTWARE LIBRE

La ingeniera de software es aquella que crea y mantiene las aplicaciones tecnolgicas y lo principal es aplicar este software con el fin de que estos sean ms rpidos, a menor costo, y de mayor calidad. El software libre es aquel que al ser obtenido puede ser usado, copiado, estudiado, modificado y redistribuido libremente. El modelo de desarrollo del SL es atpico y no convencional, se basa de un entorno distribuido y colaborar programando porciones del software o en diferente tareas especificas, surgi de manera natural.

La evolucin del modelo de desarrollo del software libre Aos 60-70 Necesidad de los mismos informticos. Programacin en ASM y C. El software se opone4 tal cual, si da problemas ellos mismos lo arreglan. 1972 : TCP-IP (protocolo) 1974 : PDP-11 (Unix de Berkley) 1975 : Emacs (entorno completo) 1976 : Vi (editor de texto) Aos 80 Requerimientos del movimiento, principalmente dev-tools y commapps. Programacin en C, C++ y lenguajes de scripting, gestionada en repositorios de cdigo. Se establecen convenciones y estndares para documentacin. 1981 : BSD 4.1 (OS) 1984 : Latex (procesador de textos) 1986 : CVS (control diversiones) 1987 : Perl (lenguaje) 1987 : GCC (compilador) Aos 90 Integracin de muchos paquetes independientes y despliegue. Aplicaciones afinadas y especializadas para laborar distribuida mente (Internet). Automatas de pruebas y documentacin.
6

 1993: Deban y Slackware (distros de Linux) 1997: Doxygen (automatizacin de documentacin a partir del cdigo fuente) 1998: APT (administrador de paquetes) Actualmente Software para diseno de software. Desarrollo basado en MVC. Herramientas de GESTION de trabajo en grupo. Herramientas de apoyo para GESTION de proyectos. 1998: Bugzilla (administracin de errores y requerimientos). 2000: Umbrello (herramienta case) 2000: PhpGroupWare (gestin de proyectos) 2004: Ruby on Rails (framework dedesarrollo) El modelo de desarrollo del software libre claro que encaja dentro de la ingeniera de software, se fue adecuando de manera natural a travs de los aos, el modelo de desarrollo del software libre tambin aporta a la ingeniera de software nuevas prcticas que antes no eran siguiera imaginadas.

MODELO EN ESPIRAL
En una representacin de la espiral encontramos lo que es la direccin de avance y el esfuerzo acumulado.

Estrategia de resolucin de problemas: *Determinar objetivos, alternativas de solucin y restricciones. *Evaluar alternativas identificar riesgos proponer estrategias de resolucin de riesgos. *Encargo. *Entrega de resultados. *Recapitulacin, propuestas de planificacin. *Verificacin. *Desarrollo.
7

El modelo en espiral tambin est formado por ventajas e inconvenientes. Ventajas: Evaluacin en cada fase que permite cambios de objetivos Funciona bien en proyectos de innovacin. Inconvenientes: -La evaluacin de riesgos es compleja Excesiva flexibilidad para algunos proyectos.

MODELO EVOLUTIVO: *Es el modelo cuyas etapas consisten en expandir incrementos de un producto de software operacional. *El cliente recibe pequeos incrementos del sistema a medida que van siendo desarrollados: distribucin incremental. Caractersticas: Gestionan bien la naturaleza evolutiva del software Son iterativos: construyen versiones de software cada vez ms completas Se adaptan bien: Los cambios de requisitos del producto Fechas de entrega estrictas poco realistas Especificaciones parciales del producto VENTAJAS Es interactivo
8

-Con cada incremento se entrega al cliente un producto operacional , que puede evaluarlo PERSONAL - Permite variar el personal asignado a cada interaccin GESTION RIESGOS TECNICOS - Por ejemplo disponibilidad de hardware especifico INCONVENIENTES La primera interaccin puede plantear los mismos problemas que un modelo lineal secuencial Incrementos: El modelo evolutivo de desarrollo no implica necesariamente entregas incrementales Entregas incrementales implican no solo cdigo, si no tambin manuales de uso Los incrementos deben ser unidades auto contenidas.

Etapas de modelo evolutivo -Entregar al cliente algo til -Medir el valor agregado del incremento -Ajustar el diseo y los objetivos en base a las mediciones.

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin.
9

Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo.

MODELO INCREMENTAL El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. El Modelo Incremental se puede ver aqu en forma grafica: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra ms. - Difcil de evaluar el coste total.

10

- Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo.

Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucre ms. - Difcil de evaluar el costo total. - Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo.

11

Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. - El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. - Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. - Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. - Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. Desventajas: - El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. - Requiere de mucha planeacin, tanto administrativa como tcnica. - Requiere de metas claras para conocer el estado del proyecto.

EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

El Proceso Unificado es un proceso de desarrollo de software conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versin del sistema. RUP es un marco genrico que puede especializarse para una variedad de tipos de sistemas, diferentes reas de aplicacin, tipos de organizaciones, niveles de aptitud y diferentes tamaos de proyectos.
12

RUP est basado en componentes. El software esta formado por componentes software interconectados a travs de interfaces. RUP est dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el rup. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema. Todos los casos de uso juntos constituyen el modelo de casos de uso. Los casos de uso tambin guan el proceso de desarrollo (diseo, implementacin, y prueba). Basndose en los casos de uso los desarrolladores crean una serie de modelos de diseo e implementacin que llevan a cabo los casos de uso. De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, avanza a travs de una serie de flujos de trabajo que parten de los casos de uso.

13

HERRAMIENTAS CASE.

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de Software. CASE se define tambin como: 1. Conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de vida del desarrollo de sistemas de informacin, completamente o en alguna de sus fases. 2. La sigla genrica para una serie de programas y una filosofa de desarrollo software que ayuda a automatizar el ciclo de visa de desarrollo de los sistemas. 3. Una innovacin en la organizacin, un concepto avanzado en la evolucin de tecnologa con un potencial efecto profundo en la organizacin. Se puede ver al CASE como la unin de las herramientas automticas de software y las metodologas de desarrollo de software formales.

CLASIFICACION DE LAS HERRAMIENTAS CASE: No existe una nica clasificacin de herramienta CASE y, en ocasiones, es difcil incluirlas en una clase determinada. Podran clasificarse atendiendo a: 1. 2. 3. 4. Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad.

Las herramientas CASE, en funcin de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente: 1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): Abarca todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbeanch. 2. Herramientas de alto nivel, U-CASE (Upper CASE, CASE superior) o front-end, orientadas a la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: anlisis y dise o.

14

3. Herramienta de bajo nivel, L-CASE (Lower CASE, CASE inferior) o back-end, dirigidas a las ltimas fases del desarrollo: construccin e implantacin. 4. Juego de herramientas o Tools-CASE, son el tipo ms simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontraran las herramientas de reingeniera, orientadas a la fase de mantenimiento.

Tipo de Case
I Case

Ventajas Integra el ciclo de vida. Permite lograr importantes mejoras de productividad a mediano plazo. Permite un eficiente soporte al mantenimiento de sistemas. Mantiene la consistencia de los sistemas a nivel corporativo. Se utiliza en plataforma PC, es aplicable a diferentes entornos, Menor costo Permite lograr importantes mejoras de productividad a corto plazo. Permite un eficiente soporte al mantenimiento de sistemas.

Desventajas No es tan eficiente para soluciones simples, sino para soluciones complejas. Depende del Hardware y del Software. Es costoso. Permite mejorar la calidad de los sistemas, pero no mejora la productividad. No permite la integracin No garantiza la consistencia de los resultados a nivel corporativo. No garantiza la eficiencia del Anlisis y Diseo. No permite la integracin del ciclo de vida.

Upper Case

Lower Case

15