miércoles, 13 de julio de 2011

articulos

República Bolivariana de Venezuela
Ministerio del P.P.  para la Educación  Universitaria
Instituto Universitario Tecnología de los Llanos
Informatica  trayecto II  trimestre II  “ sección 03”.
Valle de la Pascua  Edo - Guarico.




                                                               ciclo de vida de sistemas

 





Prof:                                                                                                                            Integrantes :






INTRODUCCION AL CICLO DE VIDA DE UN SISTEMA:
VASS diseña una estructura marcada por la especializacion

VASS Media es uno de los principales referentes del Grupo como firmaespecializada en consultoría y desarrollo de proyectos de Internet y servicios de Marketing Online, con más de 13 años de experiencia en el mercado.
Fabricación de software
VASS es una organización en constante evolución que pretende consolidar su oferta de producto bajo una única marca. Un ejemplo de su actividad lo constituye la creación el pasado año de VASSLabs para el desarrollo de software propietario y así abrir un nuevo frente dentro de la compañía para posicionarse como fabricante de software. La finalidad es ofrecer tecnología innovadora y soluciones a medida con roadmaps, actualizaciones, soporte y servicios profesionales.
Como primer paso, VASSLabs ha desarrollado una primera línea de productos propietaria, Clarive, enfocada a la gestión del Ciclo de Vida del Software y automatización de procesos ITIL, a la espera de la introducción de nuevas líneas de productos. VASSLabs participa además en proyectos OpenSource y utiliza un sistema de distribución basado en el Software Appliance o en SaaS. Rodrigo González, máximo responsable de VASSLabs, describe el interés de la nueva empresa por “buscar que nuestros clientes se alejen de los patrones de soluciones de integración ad-hoc hacia el software planeado, estructurado y soportado”.


En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia.
Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea unsistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia uorganización.

Gobierno central transfiere más de 5 millones para que la tecnología entre en las aulas de la Región

AULAS DIGITALES DEL SIGLO XXI
El delegado del Gobierno ha señalado que "este programa garantiza una educación basada en las tecnologías digitales, más próxima al alumnado y acorde con los tiempos que corren".
A su juicio, "se está contribuyendo de forma real y práctica a poner en marcha las aulas digitales del siglo XXI dotadas de la infraestructura tecnológica y de conectividad básicas en las aulas de los colegios murcianos".
También ha destacado que "esta iniciativa del Gobierno de España, puesta en marcha hace tres años, aunque por primera vez en la Región de Murcia, supone grandes cambios en la educación de nuestros jóvenes, con la introducción del ordenador personal ultraportátil como un recurso del alumno y no del centro, extendiéndose a los domicilios y a las familias de los alumnos, incluso fuera del horario lectivo y del calendario escolar".
Hasta ahora este Programa estaba cofinanciado por las Comunidades Autónomas, pero ante la necesidad de cumplimiento del objetivo de déficit que deben alcanzar este año no resultará obligatorio, quedando a su voluntad aportar dinero o no en el desarrollo del programa Escuela 2.0, añadió en rueda de prensa.
De hecho, el Programa Escuela 2.0 entró en funcionamiento en el año 2009, y con las comunidades autónomas que lo pusieron en marcha ya se han distribuido entre los alumnos más de 630.000 ordenadores portátiles, cerca de 144.000 profesores han recibido formación específica en nuevas tecnologías, y se han acondicionado alrededor de 27.000 aulas digitales.
Dado que esta sería la primera vez que el Programa se pusiera en marcha en la Región de Murcia, se podría llegar a 487 Centros Educativos, distribuir ordenadores portátiles a 15.230 alumnos y acondicionar unas 790 aulas digitales. Además, unos 1.500 profesores recibirían la formación específica necesaria.
Además, el delegado del Gobierno ha informado de que, por acuerdo del Consejo de Ministros, la Región de Murcia recibirá este año del Ministerio de Educación un total de 3.917.000 para la aplicación del Plan de extensión e impulso del primer ciclo de Educación Infantil Educa 3.
Así, tal y como se acordó en el marco de la Comisión General de la Conferencia Sectorial de Educación, el reparto del fondo de 100 millones de euros entre las Comunidades Autónomas destinados en 2011 a la creación de plazas públicas en esta etapa educativa se hace teniendo en cuenta los siguientes criterios: Población de 0 a 2 años el 1 de enero de 2011: 94%; Superficie: 4,2%; Dispersión de la población: 1,2% e Insularidad: 0,6%.

 

 

 

Retrospectiva de Nintendo parte III: Nintendo 64 – N64

Poco a poco nos vamos acercando a Project Café. Pero antes de llegar a este momento, seguimos reviviendo la trayectoria de la gran N en la industria de los videojuegos. Hoy es el turno del Nintendo 64. 
Hemos recorrido 1985 con el lanzamiento americano del NES y 1991 con el SNES. De esta manera, llegamos a la tercera generación de Nintendo en sistemas caseros, acercándonos cada vez más a la sexta generación que nos traerá con eRetrospectiva de Nintendo Parte II: Super Nintendo Entertainment System (SNES)
Y ahora, sin más preámbulos, retroanalizamos uno de los lanzamientos más llamativos en la historia de los videojuegos, aquella consola que durante su etapa de desarrollo fue conocida como "Ultra" o "Project Reality", y que en verdad logró llevar las franquicias de Nintendo a un nuevo nivel. Con ustedes... Nintendo 64
l Project Café en el E3 201

Sabemos que Sony no se preocupó por ello y aun así sacó adelante su propia consola de 32 bits en 1995, el PlayStation, con todo lo que la historia nos ha enseñado y la nueva guerra de consolas que ese mismo hecho inició. Por su parte, Nintendo probó suerte con la realidad virtual estereoscópica en 4 colores rojizos y negros, de esta manera y como experimento de mercado desarrollo el Virtual Boy, que si bien no fue el sucesor directo del SNES ni un sistema casero, merece su mención en la historia.
En un principio, el Virtual Boy iba ser un casco de realidad virtual con pantalla todo color y libertad de movimiento, pero por limitaciones y costos quedó relegado a una consola portable, más no portátil, que en su procesador de 32 bits prometía grandes dosis de profundidad y realismo que en parte cumplía, de no haber sido por el agotamiento que generaba en la vista y la escasa cantidad de títulos realizados: 20.
A pesar de tener solo tonalidades rojas, el Virtual Boy fue una consola potente e innovadora para su época con pequeñas y olvidadas joyas como Mario Tennis y Wario Land, cuyo modo de plataformas de desplazar el personaje al fondo de la pantalla se puede ver reutilizado en Donkey Kong Country Returns para Wii.





     

Los puntos débiles del coche eléctrico

La autonomía, el punto de carga y el precio de este tipo de vehículos son las principales preocupaciones entre los conductores -La mitad de los potenciales clientes adquirirían estos automóviles si costaran menos que los de motores de combustión

  







El dispensador se convierte en cable eléctrico para estos nuevos vehículos que sólo necesitan un punto de luz para cargar su batería.  daniel acker
L. GASCÓN VALENCIA 
El coche eléctrico es el futuro, y se terminará imponiendo, como señalan los fabricantes y el ministro de Industria, Miguel Sebastián. Lo que ya no está tan claro es el tiempo que deberá pasar hasta que se haga un hueco razonable en el débil mercado de la automoción. Las dudas están en la cabeza de los conductores, que no lo terminan de ver claro. Una encuesta realizada por Accenture a 7.000 personas de 13 países trata de poner en orden esas dudas que provocan recelo a la hora de adquirir un coche eléctrico, cuando el 60% reconocen que estarían dispuestos a comprarlo. De ellos, un 68% dice que durante los próximos tres años. 
El estudio "Vehículos eléctricos: cambiando percepciones y minimizando riesgos", evidencia que la mayoría de los encuestados ponen reparos sobre la desconfianza respecto a los sistemas de carga de energía
Al 85 % de los encuestados les preocupa, sobre todo, en la insuficiente de la autonomía de la batería para cubrir las necesidades diarias. Ocho de cada diez cuestionan la disponibilidad de puntos de carga, mientras que siete de cada diez considera que los tiempos de carga de los coches exclusivamente eléctricos es muy largo.
De hecho, más de la mitad de de los conductores quiere que estos nuevos coches gocen de una autonomía de más de 400 km, si bien el 51% reconoce que usa el coche menos de 40 kilómetros diarios. También algo más de la mitad, el 53%, de los entrevistados considera que una autonomía de carga equivalente a la del depósito lleno de un vehículo convencional sería un gran impulso a la hora de renovar su coche. Estas preferencias de los consumidores suponen un importante desafío para las compañías eléctricas, al incrementar los costes y la complejidad de la gestión de la red y las infraestructuras de carga de energía. 
El estudio también aporta una cuestión que compete a las compañías eléctricas y a los proveedores del servicio de carga, ya que siete de cada diez conductores se decantaría por adquirir vehículos híbridos enchufables, que funcionen también en gasolina o diesel cuando la batería está bajando. Las razones que alegan son la dificultad y la incertidumbre sobre cómo será el modelo de gestión de los puntos de carga eléctricos. 
Pasado, presente y futuro son categorías unidas de forma inseparable en los procesos de construcción social. Las identidades individuales y colectivas se construyen día a día, sobre la interpretación de un pasado que se establece como guía para el futuro. Por eso, el pasado está indefectiblemente sujeto a un debate interpretativo. Es más, como nos recuerda Zizek, «el debate ideológico fundamental es acerca de la definición actual de un pasado que siempre prefigura el futuro». En este sentido, tres momentos son claves en nuestra memoria. Tres momentos cuya interpretación histórica configura el futuro de Euskal Herria como nación: el pasado Estado independiente de Navarra nos espera en el futuro. Los vencidos en la guerra civil -izquierdistas y/o abertzales-, nos muestran las alianzas posibles y necesarias para alcanzarlo. Y, como no podía ser de otro modo, se ha abierto ya la pugna ideológica respecto al valor de la lucha en el pasado reciente, la que se inicia a finales de los cincuenta, con el surgimiento de ETA.
Está abierta la veda del pasado para los sociólogos palatinos, intérpretes interesados cuando se trata de analizar procesos de cambio: la mayoría no ha pasado del funcionalismo mertoniano, más o menos camuflado. Por eso, les repugna el conflicto, definido siempre como patología social: los que luchan son inadaptados, locos, tontos útiles, o malos. Por eso mitifican a los traidores y arrepentidos, confundiendo la catequesis, el análisis de la evolución individual y los procesos sociales. Si no tuviéramos posibilidad de arrepentirnos no pasaríamos de la pura ataraxia. Para este acercamiento académico, tan aplaudido en los medios dominantes, nunca hay razones políticas para luchar. Peor aún, nunca las ha habido: «es un viaje a ninguna parte». Sólo algunos pasados consensuados son reivindicables: como si la resistencia francesa no hubiera matado alemanes, tan personas como cualquiera, por otra parte.
Criticando la labor de muchos científicos sociales al hilo de mayo del 68, Kristin Ross nos advierte de la despolitización de la memoria: un conflicto político se convierte en rebelión generacional o mera manifestación de una contracultura más o menos simpática, una moda lampedusiana: «todo cambia para que nada cambie». Esa es una de las vías de despolitización del pasado: la «modalización». La otra, más grave, si cabe, es la «moralización de la memoria». Así, el conflicto vasco ha sido «una corrupción moral, una perversidad social... a la que sólo algunos ciudadanos espiritualmente superiores se ha enfrentado con arrojo admirable». En fin, que el análisis sociológico o político de ahora se reduzca a esta visión roma de la realidad no es muy edificante. A los analistas se nos pide que anticipemos lo que se dirá sobre estos cincuenta años dentro de cincuenta, y no conozco ningún episodio histórico conflictivo que con cierta perspectiva se lea únicamente en clave moral binaria: malos y buenos. Es más, ni siquiera el episodio más trágico de la reciente historia -Auschwitz-, está cerrado en lo que atañe a la reflexión ética, como nos recuerda Agamben: hay que distinguir la responsabilidad por el daño del arrepentimiento moral. No sea que la mera catarsis moral particular impida un análisis ético y político profundo de lo que unos y otros han hecho bien o mal durante estos años de guerra en Euskal Herria. A veces la moral es una niebla espesa que nos impide asumir nuestros errores -los de todos-, y aprender a diseñar una vida buena colectiva, es decir, a vivir éticamente, sin culpa ni responsabilidad.
En esa misma línea, Charles Tilly, cuya principal virtud fue la de intentar explicar los procesos sociales sin verse en la necesidad de condenarlos o aplaudirlos, nos ofrece una lectura politológica de nuestro tiempo: estaríamos asistiendo al fin de un largo ciclo de protesta/democratización iniciado a mediados de los años setenta del pasado siglo. Lo que ha estado en juego es la definición de las demandas sociales/políticas admisibles por el sistema político y el equilibrio entre las mismas una vez integradas en el mismo. La democratización nunca es un proceso pacífico, y, en muchas ocasiones el conflicto en torno a la democratización adquiere contenidos violentos. En nuestro caso, se han conectado y retroalimentado en una larga y dolorosa espiral dos temores, y dos disonancias cognitivas, o contradicciones insuperables.
En primer lugar, por un lado, en el seno del abertzalismo radical, existía el temor de que el sistema democrático instaurado tras la muerte de Franco jamás reconociera el derecho de autodeterminación entendido como imprescindible para la continuidad de un proyecto nacional vasco. Mientras tanto, por el lado sistémico, existía el temor de que una minoría apoyada en el uso de la violencia consiguiera introducir una demanda -la autodeterminación-, en situación de ventaja respecto a otras que pudieran ser mayoritarias según criterios cuantitativos y, que, además, su introducción pusiera en peligro el proyecto nacional español.
En segundo lugar, la disonancia de ETA estribaba en que pretendía democratizar el sistema apelando a instrumentos no democráticos. La disonancia se acentuó en su caso a partir de la elaboración de la «alternativa democrática» en abril de 1995, en tanto en cuanto ese discurso democrático no podía convivir sin incoherencia insuperable con la praxis armada. En el otro lado, la disonancia por parte del Estado residía en que el discurso «cualquier proyecto político es posible sin violencia» no tenía una base real.
La inmadurez del enfrentamiento condujo a un callejón sin salida en el que todos podían tener parte de razón: ETA y su comunidad de referencia pensó que la violencia era la única forma de arrebatar a España el derecho de autodeterminación, entendido como clave para la subsistencia nacional. Y los gestores del sistema, desde su lógica, tenían alguna razón para poner límites a la democratización planteada por ETA: peligraba su proyecto de transición democrática limitada.
Los procesos de democratización se desarrollan en la tensión irresoluble entre lo ideal y lo posible, tensión resuelta según la relación de fuerzas existente en cada momento. En ese punto de tenso equilibrio, simplemente confluyen formas distintas de entender la democracia y su alcance. Por eso, la dimensión ética no es ajena a ninguno de los adversarios: cuando un periodo de violencia política ocupa decenios, la situación no se define absolutamente a partir del marco «la locura criminal de unas pocas personas carentes de ninguna legitimidad y un sistema político legítimo que no hace sino defenderse». Tampoco a partir del marco especular «la lucha armada está justificada por la opresión de un Estado ilegítimo que vulnera las ansias de libertad de todo un pueblo». El conflicto se sostiene en el tiempo porque es una pugna entre éticas distintas, entre legitimidades fluctuantes en competencia. Entre disonancias cognitivas más o menos gestionables. El grado de incoherencia y credibilidad/viabilidad del discurso y la praxis conectada al mismo es el que determina el grado de legitimidad social de cada uno de los contendientes, y el que, normalmente determina el momento y contenido del final del ciclo.
El fin del ciclo democratizador es multifactorial, pero básicamente se resuelve por la apertura de diversas ventanas de oportunidad que pueden permitir resolver los temores y las disonancias cognitivas existentes en los discursos de los adversarios principales. Resumiendo: el proyecto independentista puede (debe) prescindir de ETA para avanzar políticamente, superada ya una larga fase de «agonía nacional» de la mano de la misma autonomía que el independentismo ha impulsado y combatido, de modo sólo aparentemente paradójico. Y el Estado puede (debe) abordar determinadas cuestiones, como la autodeterminación, sin que peligre necesariamente su estabilidad en un contexto europeo en el que, tras 1989, esa reivindicación democrática se vive ya con entera normalidad. Este es el punto de madurez que permite cerrar el ciclo. Por eso es irrelevante el momento negociador: éste ya se ha producido de facto, aunque falte su concreción en el ámbito de la reforma institucional. Todo se andará.
Pensar que estos cuarenta años «no han servido para nada» es un acercamiento reaccionario a la realidad. Al contrario, como nos recuerda Tilly, ni uno sólo de los derechos de los que hoy disfrutamos, desde la autonomía territorial a las vacaciones pagadas, se ha conseguido sin luchar. Y tampoco se mantendrán en el futuro en ausencia de una movilización política continuada. Otra cosa es que los objetivos deban enseñar a los medios y que, éstos, no sólo deben ser eficaces -que también-, sino que deben medir siempre sus consecuencias éticas a la luz de lo que está en juego en cada momento. Ahora bien, siendo conscientes de que ayer como hoy, mañana y siempre, «sólo la lucha paga».

viernes, 3 de junio de 2011

INTEGRANTES DE BLOG


REPUBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACION SUPERIOR
INSTITUTO UNIVERSITARIO TECNOLOGICO DE LOS LLANOS
VALLE DE LA PASCUA—ESTADO GUARICO
PNF INFORMATICA SECCION “3”



CICLO DE VIDA DE SISTEMAS




PROFESOR:CIPRIANO INFANTE
INTEGRANTES DEL BLOG:
RUIZ F JOSE MIGUEL
ESTRADA MANUEL

RAMOS EDUARDO

EXPOSICION





































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.