martes, 31 de mayo de 2011

REPÚBLICA BOLÍVARIANA DE VENEZUELA
MINISTERIO DE EDUCACIÓN SUPERIOR.
INSTITUTO UNIVERSITARIO DE TECNOLOGIA DE LOS LLANOS
PNF EN INFORMATICA TRAYECTO II TRIMESTRE II SECCION 3
VALLE DE LA PASCUA  ESTADO GUARICO.











CICLO DE VIDA
DE SISTEMAS




   PROFESOR:                                                  
CIPRIANO,INFANTE

INTEGRANTES:                  AMATO,RAFAELC.I:17.740.897                                                                                                           LEAL MARIELA C.I:19067.770 
RIOS LUZ MARINA C.I:21.377.903
 JARAMILLO YRALY C.I:20528.557



MAYO 2011

CICLO DE VIDA DE UN SISTEMA
“Es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de información y aplicaciones informáticas”.
(Whitten J., Bentley L., Barlow V. 1996)
EL DESARROLLO  DE SISTEMAS  DE  INFORMACION
Ciclo de Vida = Ciclo de Desarrollo  +  Mantenimiento
METODOLOGIAS
1.  ESTRUCTURADA.
2. ORIENTADO A OBJETO
A medida que se acercaban los 80, el paradigma “orientado a objetos” comienza a madurar como un enfoque de desarrollo software. Se empezaron a hacer diseños de aplicaciones usando la orientación a objetos, pero se quedó atrás el análisis de requisitos para esas aplicaciones.
Actualmente el análisis orientado a objetos (AOO) se va imponiendo como método de análisis, pero no existe unanimidad en cuanto a la metodología a usar.
El primer problema que la programación supone resuelto, es la definición de
objetos y clases. Es labor del AOO y del Diseño Orientado a Objeto (DOO) llevar a cabo esta definición, para obtener aplicaciones de calidad. Así, se puede decir que modelos orientados a objetos para el análisis permiten al ingeniero de software obtener el modelo de un problema representando clases, objetos, atributos y operaciones como elementos de ese modelo.
El desarrollo orientado a objetos no es un método simple. No se basa en la
descomposición funcional, es decir, estudiar el problema de un modo clásico (entrada proceso-salida o por estudio de las estructuras de los datos). Las aplicaciones basadas en los métodos orientados a objeto se analizan, diseñan, implementan y prueban en función de los objetos que las componen.

EL CICLO  TRADICIONAL DE LOS  SISTEMAS DE INFORMACIÓN
EL CICLO TRADICIONAL DE LOS S.I. FASE 1 FASE 2 FASE 3 FASE N FASE N + 1 Desarrollo e Implementación FASES QUE VARIAN DE AUTOR EN AUTOR.
MODELOS PARA EL CICLO DE VIDA DE DESARROLLO DE SOFTWARE
CASCADA
         Análisis de requerimientos
         Especificaciones
         Diseño
         Implementación
         Prueba
         Mantenimiento
ESTRUCTURADO
         Encuesta
         Análisis.
         Diseño.
         Implantación...
         Pruebas
         Control de calidad.
         Procedimientos.
         Conversión B.D.
         Instalación.


ESPIRAL
         Requerimientos
         Análisis de riesgo
         Prototipo 1, 2.
         Res. software
         Validación de Req.
         Análisis de riesgo
         Prototipo 3
         Diseño software
         Validación diseño
         Integración y prueba.

glosario

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR
INSTITUTO POLITÉCNICO DE LOS LLANOS
VALLE DE LA PASCUA; EDO GUÁRICO




Glosario de términos  Ciclo de vida de Sistemas


Facilitador:                                                                       Integrantes:
Cipriano Infante                                       Vega Railyn C.I 19.374.824
                                                                Rodríguez Mariandry C.I 20.527.21
                                                                 Medina Rafael C.I 22.614.753
             Loreto Ronelvy C.I 20.957.343
              Álvarez Marielba C.I 21.663.200



Mayo 2011

Abstracción:
Separar las características que interesan para un modelo de las irrelevantes.
Acoplamiento:
Medida de la complejidad de los interfaces de los módulos.
ActiveX:
Tipo de componente distribuido como binario.
Actividad:
Cada una de las partes en las que se divide una fase.
Actividades, diagrama:
Gráfico de UML que modela el comportamiento interno de una clase.
Actividades, diagrama de:
Gráfico UML que muestra el comportamiento y la participación de las clases en el mismo. Útil para flujos de trabajo.
Actor:
Persona o sistema que juega un papel en la interacción con un sistema.
Agregación:
Relación entre dos clases en la que una es parte de la otra.
Alcance:
Visibilidad de un atributo. Puede ser público, protegido o privado.
Almacén:
Es un conjunto de datos estático. Puede ser un archivo o una base de datos.
Alto nivel, lenguajes:
Son lenguajes con alto nivel de abstracción. Hacen lo mismo que un lenguaje de bajo nivel pero con menos líneas.

Ámbito:
Número de veces que existe el objeto. De instancia: Una por cada instancia de la clase. Archivador: Una única vez, como las variables static de Java.


Análisis:
Etapa donde el problema es la comprensión de las necesidades.
Análisis crítico:
Actividad que se realiza desde el principio del proyecto para localizar los problemas de alto riesgo.
Análisis de valores límite:
Técnica de generación de casos de prueba conjunta con particiones de equivalencia que genera casos de prueba cercanos al máximo o mínimo tamaño de un array o al máximo o mínimo número de iteraciones de un bucle.
Árboles de decisión:
Gráfico en forma de árbol para escribir una especificación de procesos cuando se tiene un conjunto de unas pocas variables y se toman decisiones en función de los valores que tomen.
Asociaciones:
Relación que se establece entre dos o más clases.
Atributo:
Variable de una clase.
Auditoría:
Examen del sistema preferiblemente por parte de una organización no involucrada en el proceso de desarrollo. Tipos: regulares, especiales, sorpresa, de seguimiento, financiera, operacional, de gestión e informática.

Brainstorming:
Técnica poco estructurada de obtención de requisitos en una reunión.

Caja blanca, pruebas:
Pruebas que tienen en cuenta la estructura lógica del programa.

Caja de cristal, pruebas:
Ver caja blanca.
Caja negra, pruebas:
Pruebas que tienen en cuenta las especificaciones.
Calificación:
Atributo que rebaja la cardinalidad de una parte de la asociación entre dos clases.
Cardinalidad:
Número de entidades que están asociadas con otra(s) en una relación.
Cascada:
Ciclo de vida lineal.
CASE:
(Computer Aided Software Engineering) Herramienta para automatizar o facilitar parte o todo el trabajo mecánico (no creativo) de parte o todo el ciclo de vida.
Casos de prueba:
Conjunto de entradas y de salidas esperadas para esas entradas.
Casos de uso:
Método de análisis para una interacción del sistema con el usuario u otro sistema.
Ciclo de vida:
Conjunto de etapas por las que pasa un sistema informático desde su concepción hasta su retirada.
Clase:
Estructura de datos con las operaciones relativas a esos datos.
Clases, diagrama:
Principal tipo de diagrama en UML que muestra las clases y las relaciones que tienen.
Clases de equivalencia:
Agrupaciones de las entradas iguales a efectos de las pruebas.
Cleanroom:
Técnica de generación de software basada en métodos formales para minimizar el número de errores.

Cliente-servidor:
Arquitectura de sistemas distribuidos con una parte que funciona como interfaz (cliente) y otra que gestiona recursos y realiza el trabajo (servidor).
Codificación:
Etapa del ciclo de vida en la que se escribe el código fuente.
Código heredado:
(legacy code) Código de aplicaciones antiguas posiblemente muy remendado y sin documentación.
Cohesión:
Característica de un módulo. Un módulo tiene cohesión si sus tareas son independientes del resto del sistema pero están relacionadas entre sí.
Colaboración, diagrama:
Indica interacciones entre objetos a través de los enlaces que hay entre ellos. Similar al diagrama de secuencia.
Complejidad ciclomática:
Medida de la complejidad de un programa, igual al número de caminos independientes que tiene.
Componentes:
Software pensado para ser reutilizable. Consta de código y datos.
Componentes, diagrama:
Gráfico de UML que muestra la organización y dependencias entre componentes.
Composición:
Es un tipo de agregación en la que cada componente pertenece a un todo y sólo a ese.
Congruencia:
Un método es congruente si tiene un nombre similar a métodos similares, condiciones, orden de argumentos, valor proporcionado y condiciones de error.
Contexto, diagrama:
Representación del sistema y entidades externas que interaccionan con él.

CORBA:
(Common Object Request Broquer Architecture) Sistema distribuido multiplataforma basado en objetos. Cada uno puede ser cliente y servidor.
CRC:
Mecanismo para representar clases e interacciones entre ellas.
Crisis del software:
La consecuencia de escribir código sin plantear seriamente metodologías para el análisis, diseño y mantenimiento.
CVS:
(Concurrent Versioning System) Almacenamiento de ficheros con capacidad de trazar las aportaciones de cada persona y la historia de cada archivo.

Defecto:
El sistema hace algo de forma equivocada. Es la consecuencia de un error y se manifiesta a través de un fallo.
DFD:
(Diagrama de Flujo de Datos) Herramienta del diseño estructurado para modelar la transformación o transacción de la información.
Diccionario de datos:
Descripción detallada de los flujos de datos
Diseño:
Etapa del ciclo de vida en la que se divide el sistema en subsistemas y posteriormente se decide cómo serán las estructuras de datos y algoritmos.
Distribución, diagrama:
Gráfico de UML que refleja la organización del hardware.

Encapsulamiento:
Propiedad por la que un objeto o módulo proporciona al exterior las funciones necesarias para su manejo y no los detalles internos.
Entidad-Relación:
Modelo de datos del diseño estructurado.
Entidades externas:
Personas o sistemas que interaccionan con el sistema.
Entrada/Salida, pruebas:
Ver caja negra.
Entrevistas:
Técnica de obtención de requisitos que consiste en hablar con un usuario.
Error:
Equivocación de un desarrollador en cualquiera de las fases. Produce uno o más defectos.
Especificación:
Traducción de los requisitos del análisis a un documento que sirva para empezar el diseño.
Especificación de control:
Muestran como a partir de señales de control se activan o desactivan procesos del diagrama de flujo de control asociado.
Especificación de procesos:
Concretar en pseudocódigo o en algún lenguaje de programación cómo es un módulo que ya no se puede descomponer más.
Espiral, ciclo de vida:
Ciclo de vida con varias iteraciones. Hace énfasis en el control del riesgo. Típico en la orientación a objetos.
Estados, diagrama:
Representación del comportamiento interno de un sistema.
Estereotipos:
Forma de dar nombre a un elemento que no forma parte del estandar de UML.
Estructurales, pruebas:
Ver pruebas de caja blanca.
Estructuras, diagrama:
Método de descomposición funcional donde el bloque básico es el módulo.
Etapa:
Cada una de las partes de las que se compone el ciclo de vida.
Factor de calidad:
Forma de determinar la calidad de un software. Están divididos en función de criterios de operación, revisión y transición. Cada uno se obtiene a partir de varias métricas.
Fallo:
Manifestación de un defecto.
Flujo de datos:
Representación de datos que se mueven entre procesos o entidades externas.
Flujo de control:
Diagrama que informa sobre cuando y en que orden ocurren los sucesos.
Framework:
Conjunto integrado de componentes que colaboran para proporcionar una arquitectura reutilizable para una familia de aplicaciones.
Fuente, ciclo de vida:
Ciclo de vida para sistemas orientados a objetos.
Funcionales, pruebas:
Ver caja negra.

Generalización:
Ver herencia.
Grafo de flujo:
Representación de un programa usada para el diseño de casos de prueba estructurales.

Herencia:
Mecanismo por el que unas clases mantienen los mismos métodos y propiedades de otras a las cuales amplian.
HIPO, diagramas:
(Hierarchy Input Process Output) Diagrama de diseño que muestra entradas, salidas y funciones.


IDL:
(Interface Definition Languaje) Lenguaje formal para expresar interfaces.
Incremental:
Ciclo de vida derivado del de cascada pero con iteraciones para implementar distintas partes del sistema.
Ingeniería inversa:
Análisis de un producto construido para comprender sus principios de diseño.
Indicador:
Medida numérica para comprobar algo de un modo objetivo. Los hay económicos, financieros, de ocupación laboral y de gestión.
Inspecciones:
Revisión del código sin ejecutarlo. Muy estructurada y realizada por un equipo.
Interfaz:
Conjunto de servicios proporcionados por una clase.

JAD:
(Joint Application Design) Técnica muy estructurada de obtención de requisitos en una reunión.
Java Beans:
Componentes escritos en java.
Jackson, diagramas:
Produce una especificación del programa a partir de una especificación de las entradas y las salidas, que deben ser secuenciales.
JRP:
(Joint Requirements Planning) Subconjunto del JAD para obtención de requisitos de alto nivel.

Lenguaje estructrado:
Pseudocódigo para escribir las especificaciones de proceso.
Línea base:
Puntos de referencia en la gestión de configuración.

Mantenimiento:
Etapa final del ciclo de vida. Consume la mayor parte de los recursos.
Mantenibilidad:
Cualidad de una aplicación que hace que el mantenimiento sea más fácil.
Metodología:
Modo sistemático de fabricar un producto.
Métricas:
Medidas numéricas sobre alguna cualidad de un programa.
Modelo:
Abstracción de la realidad donde se omite lo no esencial.
Módulo:
Cada una de las partes con entidad propia en las que se divide un sistema.
Modularidad:
Propiedad del software. Un programa es modular si está dividido en partes con tareas definidas.
Multiplicidad:
Número de elementos que están en los lados de una relación.
Navegabilidad:
Posibilidad de moverse de una clase a otra utilizando las relaciones que hay entre ellas.
Normalización:
Algoritmos que convierten una base de datos en otra equivalente pero sin anomalias de inserción, borrado y modificación, más eficiente y menos redundante.

Notas:
Explicaciones de los elementos de notación de UML.
Objeto:
Instancia de una clase.



OCL:
(Object Constraint Languaje) Lenguaje formal para expresar restricciones.

Paquetes:
Conjunto de clases relacionadas entre si.
Patrones:
Prototipos de soluciones para problemas conocidos. Los hay de análisis, arquitectónicos, de diseño, de codificación y de organización.
Persistencia:
Característica de un objeto que se puede escribir en disco para posteriormente ser recuperado.
Polimorfismo:
Capacidad de un conjunto de objetos de responder a un mensaje con el mismo nombre o a un objeto de poder responder a un mismo mensaje con distintos parámetros.
Privado:
Tipo de alcance más restrictivo posible. Una propiedad de este tipo solo puede ser accedida dentro de la clase en la que está declarada.
Proceso:
Subsistemas o funciones en las que se divie el sistema.
Protegido:
Tipo de alcance que restringe el acceso a la clase en la que se ha declarado y a sus descendientes.
Prototipo:
Versión reducida de la aplicación final. Se construye para obtener requisitos o para partiendo de él hacer incrementos hasta el sistema final.
Pruebas:
Batería de test que el sistema tiene que superar para ser considerado operativo.
Público:
Tipo de alcance que permite el acceso a cualquier otra clase.

Reducción de riesgos, cascada con:
Ciclo de vida cascada con iteraciones en el análisis y diseño global.
Reingeniería:
Reconstrucción completa de una aplicación antigua utilizando técnicas modernas.
Requisitos funcionales:
Lo que el sistema hace para el usuario.
Requisitos no funcionales:
Características del sistema (fiabilidad, mantenibilidad, etc). Se tienen en cuenta en la fase de diseño.
Responsabilidades:
Descripción de lo que hace una clase.
Revisión:
Las distintas versiones de un elementos software que van surgiendo.

Sashimi, ciclo:
Ciclo de vida en cascada con solapamiento entre las fases.
Secuencias, diagrama:
Gráfico de UML que muestra los mensajes intercambiados entre objetos teniendo en cuenta el tiempo.
Sistema:
Conjunto de elementos que cooperan entre si para proporcionar servicios.
Sistemas, ingeniería de:
Herramientas y metodologías para crear sistemas.
Software, ingeniería del:
Herramientas y metodologías para crear software.

Tarea:
Una etapa (p.ej. el diseño) se descompone en tareas. Una tarea puede realizarse a lo largo de varias etapas, por ejemplo la documentación.
Tablas de decisión:
Forma de escribir una especificación de procesos cuando hay muchas variables y en función de su valor se toman decisiones.
Transición de estados:
Diagrama de UML que refleja los cambios que esperimenta una clase como si fuera un autómata finito.


UML:
(Unified modeling languaje) Notación de facto para el modelado de sistemas orientados a objetos.

V, ciclo de vida en:
Ciclo de vida similar al de cascada pero que toma en consideración el nivel de abstracción de cada una. El análisis valida el mantenimiento y el diseño verifica las pruebas.
Validación:
Comprobación de que el sistema cumple con las especificaciones funcionales y no funcionales.
Variante:
Versión de un elemento software que cohexiste con otra con algunas diferencias.
VCL:
(Visual Component Library) Componente gráfico.
Verificación:
Comprobación de que el sistema funciona correctamente.
Versión:
Un elemento software en un momento dado.

Walkthrough:
Revisión del código sin ejecutarlo. Realizado por un equipo.
Warnier, diagramas:
Representación jerárquica de la estructura de los programas y estructuras de datos.