Adsense

miércoles, 25 de junio de 2008

Export cxGrid (QuantumGrid) to Excel

Debe estar la unidad

cxGridExportLink

se lama el procedimiento:

procedure ExportGridToExcel(const AFileName: string; AGrid: TcxGrid; AExpand: Boolean = True; ASaveAll: Boolean = True; AUseNativeFormat: Boolean = True; const AFileExt: string = ‘xls’);

Y listo. a continuación lo que dice la ayuda:

Description

Use the ExportGridToExcel method to export the grid control’s content into an XLS file. The target file’s name is specified by the AFileName parameter. Note that you should not specify the file’s extension using this parameter. The extension will be automatically replaced with the AFileExt parameter value.

The grid control whose content is to be copied is specified by the AGrid parameter. Note that only the currently active root level’s content will be exported. Excel export doesn’t support master-detail data.

The AExpand parameter indicates whether to export all records displayed within the exported level including records hidden within collapsed groups. If this parameter value is True, the grid expands all group and master records before exporting. If this parameter value is False, the records’ expanded state remains unchanged and only visible records’ content is written to the file.

The ASaveAll parameter indicates whether to export all or selected records. Set the parameter to False to export only the current selection. In grid mode, this parameter value is ignored and all records are exported.

If the AUseNativeFormat parameter is True, the export routine tries to convert display text of grid cells to the corresponding Excel format (Currency, Date, Time or Float). If you specify an editor to an item, the display text of all cells in the item is converted to a proper MS Excel format according to the following table:


An editor assigned to a grid cell The corresponding MS Excel format
TcxCurrencyEdit Currency
TcxMaskEditProperties or TcxCalcEditProperties Currency, if the editor is bound to the field whose values are formatted as currency values (see the field’s Currency property).Otherwise, Number.
TcxDateEdit Date
TcxTimeEdit Time
TcxSpinEdit Number
Note: if columns don’t use editors listed above, values from that columns are exported as strings regardless of the AUseNativeFormat parameter value. If a particular cell’s text cannot be converted to the required format (if the cell contains invalid characters, for instance) or the data type of an underlying data field does not exactly correspond to the data type associated with the assigned editor (for instance, a numeric data field used to store currency values), it is exported as a string.

If the AUseNativeFormat parameter value is False, all values are exported as strings.

martes, 17 de junio de 2008

Segunda pregunta de la muerte de Javier García

"La hipótesis que cobra mayor fuerza, según explicaron funcionarios del Cicpc"
Según porque llevaba unas  maletas... que no se llevó.
También porque iba a llevarse la camioneta de García... en la que tampoco se montó.
¿Qué clase de robo es ese?
 A todos los que han tenido en Venezuela una mala experiencia con la delincuencia les pregunto ¿Los ladrones han tenido un poco dominio del idioma Español?
Eso es lo que se lee y relee en todos los medios. Deberian ser más detallados.

Ejemplo de Toma de Decisiones

En toda organización ocurren situaciones en que se deben elegir entre dos o más opciones que son cruciales para el éxito o fracaso de la misma. Es por ello que en el proceso de la toma de decisiones se debe tomar en cuenta un proceso o técnicas para elegir la opción más adecuada.

Pero el proceso de toma de decisiones no sólo es relevante en el mundo empresarial, ya que en el mundo actual se presentan nuevos retos, nuevas situaciones que dependen de una decisión acertada que puede ser crucial para la vida. Es por ello que a continuación se desarrolla un ejemplo práctico de toma de decisiones relacionado con la Informática.

Definición del problema.

Se desea llevar a cabo la creación de una empresa que tenga relación con la informática, pero no se conoce específicamente las funciones que tendría la empresa y qué tipo de soluciones puede ofrecer.

Diagnosticar las causas.

- La informática es muy amplia, abarca especialidades como redes, inteligencia artificial, bases de datos, procesamiento de datos, análisis de sistemas, seguridad informática, programación concurrente, diseño de Sitios Web, etc. Debido a tal amplitud de tópicos, la empresa debe especializarse en un tema en especial.

-La idea de surgir como profesional en la carrera de informática e implementar el desarrollo endógeno y contribuir en pro de la sociedad venezolana.

Objetivos de la decisión.

- Seleccionar la alternativa que más se ajuste a nuestros conocimientos y posea una gran demanda en el mercado.
- Obtener una remuneración justa con los servicios que brinde la empresa.
Desarrollar alternativas.

- Desarrollo de Sitios Web.
- Consultoría de Software.
- Consultoría de Redes.
- Análisis de Sistemas.

Evaluación de Alternativas.

Desarrollo de Sitios Web

¿Es viable esta alternativa?
Si es viable, ya que los Sitios Web están en boga de todas las compañías y posee gran demanda en el mercado. Además se poseen los conocimientos necesarios para el desarrollo.

¿Es una solución satisfactoria?
Si, ya que como el mercado es amplio, habrán muchas oportunidades para la empresa.

¿Cuáles son las posibles consecuencias para la organización?
- Se requerirán equipos necesarios para el desarrollo Web.
- Se debe obtener un conjunto de proveedores de servicios de Internet que sean confiables.
- Se deben llevar a cabo campañas publicitarias.
- La compañía puede requerir un personal especializado en otras ramas como marketing, diseño gráfico, etc.

Consultoría de Software
¿Es viable esta alternativa?
Si es viable, ya que las consultoras de software se requieren para solucionar los problemas que existen en una empresa o un entorno determinado.

¿Es una solución satisfactoria?
No, ya que desarrollar una empresa que se dedique a este ámbito empresarial requiere que se tome en cuenta la asesoría de software en las organizaciones, ya que tal rama no es muy conocida en la sociedad venezolana.
¿Cuáles son las posibles consecuencias para la organización?
 Las consecuencias pueden ser negativas, ya que si no es reconocida la relevancia de la consultoría de software, la empresa puede cerrar por falta de demanda.
Consultoría de Redes
¿Es viable esta alternativa?
 Si, ya que posee mucha aceptación en el mercado actual, por lo que hay mucho potencial de capitalizar clientes.

¿Es una solución satisfactoria?
 No, ya que los conocimientos sobre esta rama de la informática son poco conocidos por parte de los integrantes de la empresa.

¿Cuáles son las posibles consecuencias para la organización?
La poca preparación podría ocasionar altos gastos de capacitación del personal.
Si no se lleva a cabo la preparación del personal se arriesga a la compañía a ofrecer un mal servicio y no se tendría prestigio por parte de la empresa.

Análisis de Sistemas.
¿Es viable esta alternativa?
Si. Ya que el desarrollo de todo software requiere una fase de análisis y es una etapa crucial en todo el proceso.

¿Es una solución satisfactoria?
 No. Ya que usualmente las empresas desean que se lleven a cabo las tareas de análisis y desarrollo de las aplicaciones.

¿Cuáles son las posibles consecuencias para la organización?
 Las empresas pueden no preferir los servicios dado que sólo se limitan a una etapa del desarrollo de software. 

Selección de la mejor opción.

Se ha decidido que la empresa a crear se especialice en el campo del desarrollo de Sitios Web, ya que es una opción viable y la más satisfactoria para los creadores de la empresa. 

Implantación de la decisión y monitoreo.

Para llevar a cabo la ejecución de la decisión, se deben llevar a cabo los pasos pertinentes para la creación de una empresa y se debe equipar con la infraestructura requerida para el desarrollo de Sitios Web. Para el monitoreo de las condiciones de la compañía, se decidió realizar reportes de ganancias cada cuarto del año.

El proceso de toma de decisiones no debe tomarse a la ligera y deben considerarse todas las posibilidades y analizar lo positivo y lo negativo de cada decisión potencial. Éste proceso requiere que sea llevado a cabo de forma rápida y certera en el mundo de hoy lo exige así.

 También es muy importante tener un conocimiento muy amplio de cada una de las posibles decisiones para tener una mejor visión de las cosas e incrementar las posibilidades de elegir la decisión correcta.

Que Achantada Microsoft: Firefox 3, Opera 9.5 y ellos?

Microsoft, una compañía que ni apoyo ni repudio sino que me da igual... no ha lanzado una nueva version de su navegador web. Eso se ve feo.

Microsoft en el mundo del PC necesita reinventarse y traer nuevas  cosas no más de lo mismo por dios. Los reproductores de mp3 portatiles por ejemplo ¿por qué no inventarse un SO que usen todos? ¿Por qué son tan restringidos en vez de ser más abiertos? ¿Qué tal un SO para mi vehículo? compatible con todo mi mundo microsoft.

¿que le paso al facebook? ¿caido facebook?

Trato de entrar al facebook y nada de nada no entra.

Facebook, la red social del momento es para mi no una pagina, sino un email 2.0. Antes todos tenian un  email pero... ¿como averiguabas el mail de tus compañeros de kinder? facebook arreglo ese peo porque todo el mundo está allá. Basta con escribir el nombre preguntar un poco y ya.

Tanta demanda debe causar muuuchos quebraderos de cabeza y muchos cuellos de botella.

lunes, 16 de junio de 2008

Palabras que buscan en mi blog

En 24 horas la gente ha entrado a este blog escribiendo en google las siguientes palabras:

110 25.00% javier garcia periodista  
28 6.36% javier garcia gay  
23 5.23% javier garcia rctv  
18 4.09% muerte javier garcia  
9 2.05% muerte de javier garcia  
7 1.59% javier garcia periodista rctv  
7 1.59% javier garcia periodista de rctv  
6 1.36% javier garcia muerte  
6 1.36% periodista de rctv muerto  
5 1.14% javier garcia gay?  
5 1.14% muerte de javier garcia periodista  
5 1.14% muerte de javier garcia periodista de rctv  
4 0.91% javier garcía periodista  
4 0.91% javier garcia periodista asesinado  
4 0.91% javier garcia era gay  
4 0.91% asesinado javier garcia  
4 0.91% que paso con periodista de rctv  
4 0.91% esposa e hijos del periodista javier garcia  
4 0.91% javier garcia rctv gay  
4 0.91% javier garcias periodista  
3 0.68% javier rctv  
3 0.68% muerte periodista rctv  
3 0.68% muerte javier garcia periodista  
3 0.68% caso javier garcia  
3 0.68% periodista muerto de rctv  
3 0.68% muerto javier garcia  
3 0.68% muerte javier garcia rctv  
3 0.68% muerte de javier garcia rctv  
3 0.68% foto del periodista javier garcia  
3 0.68% muerte periodista javier garcia  
3 0.68% como fue la muerte de javier garcia  
2 0.45% javier garcia asesinado  
2 0.45% era gay periodista javier garcia????????'  
2 0.45% javier garcia and gay  
2 0.45% rctv javier garcia  
2 0.45% javier garcia periodista  
2 0.45% javier garcia es gay  
2 0.45% javier garcia su muerte  
2 0.45% muere periodista de rctv  
2 0.45% javier garcia muerto  
2 0.45% formato de carta de renuncia  
2 0.45% periodista muerto rctv  
2 0.45% javier garcia muerte gay  
2 0.45% periodista javier garcia gay  
2 0.45% javier garcia periodista de rctv era gay  
1 0.23% javier garcia gay periodista muerto  
1 0.23% javier garcía gay  
1 0.23% javier garcia periodista  
1 0.23% que paso realmente javier garcia  
1 0.23% como fue la muerte de javier garcia periodista de rctv  
1 0.23% cheats para halo 3  
1 0.23% foto javier garcia rctv  
1 0.23% rctv periodista muerto  
1 0.23% foto de la muerte de javier garcia  
1 0.23% foto de javier garcia rctv  
1 0.23% javier garcia periodsita de rctv  
1 0.23% periodista muerto javier  
1 0.23% lo ultimo sobre la muerte de javier garcia  
1 0.23% tipo de rctv que mataron  
1 0.23% muerte del periodistas de rctv  
1 0.23% javier garcia periodista rctv gays?  
1 0.23% javier garcia. periodista rctv venezuela  
1 0.23% periodista muerto rctv gay  
1 0.23% javier garcia muerte  
1 0.23% rctv asesinado gay  
1 0.23% garcia periodista rctv  
1 0.23% gay javier garcia  
1 0.23% javier garcia rctv era casado?  
1 0.23% javier garcia (periodista)  
1 0.23% daniel garcia rctv  
1 0.23% muerte de unos de los periodistas de rctv  
1 0.23% javier garcia muerto  
1 0.23% javier garcia periodista era gay  
1 0.23% asesinato de jarvier garcia periodista de rctv  
1 0.23% javier garcia periodista venezolano  
1 0.23% javier garcia periodista foto  
1 0.23% javier garcia - periodista  
1 0.23% gays periodista garcia  
1 0.23% formato carta de renuncia  
1 0.23% javier garcia periodista de rctv  
1 0.23% movil muerte javier garcia  
1 0.23% javier garcia gay??  
1 0.23% periodista muerto de rctv javier garcia  
1 0.23% javier garcias periodista de rctv  
1 0.23% muerte del periodista javier garcia fotos fotos  
1 0.23% murio periodista de rctv javier garcia  
1 0.23% muerte periodista rctv  
1 0.23% javier garcia novia rctv  
1 0.23% javer garcia gay  
1 0.23% formato de renuncia  
1 0.23% javier garcia periodista gay  
1 0.23% javier garcia, periodista rctv  
1 0.23% muerte de javier garcia. periodista  
1 0.23% como fue la muerte de javier garcia de rctv  
1 0.23% crimen de periodista de rctv  
1 0.23% quien asesino a javier garcia  
1 0.23% como fue la muete de javier garcia  
1 0.23% javier garcia>periodista  
1 0.23% que es una carta de renuncia  
1 0.23% colonia gays de la muerte de javier garcia  
1 0.23% javier garcia r.c.t.v  
1 0.23% quie era el periodista javier garcia  
1 0.23% que paso con el periodista de rctv javier garcia  
1 0.23% javier muerto gay rctv  
1 0.23% muerte de javier garcia fotos  
1 0.23% el ultimo adios al periodista javier garcia de rctv  
1 0.23% javier garcia era gay?  
1 0.23% muerte del periodista de rctv javier garcia  
1 0.23% era casado javier garcia el periodista??  
1 0.23% javier garcia su muerte rctv  
1 0.23% javier garcia movil del asesinato gay  
1 0.23% puds ventajas  
1 0.23% murio javier garcia rctv  
1 0.23% muerte de javier garcia de rctv  
1 0.23% fotos de el venezolano javier garcia muerto  
1 0.23% fotos de javier garcia periodista  
1 0.23% periodista de rctv javier garcia  
1 0.23% javier periodista muerto de rctv  
1 0.23% la muerte de javier garcia rctv  
1 0.23% javier garcía, periodista de rctv.  
1 0.23% rctv muerte de javier garcia  
1 0.23% video del ultimo adios de javier garcia periodista  
1 0.23% javier garcia periodista asesinado fotos  
1 0.23% periosista rctv gay  
1 0.23% muerte de javier garcias periodista de rctv  
1 0.23% nombres y fotos de todos los periodistas de rctv  
1 0.23% javier garcia lo mato gay  
1 0.23% formatos de carta de renuncia  
1 0.23% muerte javier garcia gay?  
1 0.23% esposa del periodista javier garcia  
1 0.23% como mataron a javier garcia periodista de rctv?  
1 0.23% causas de la muerte de javier garcia fue pasional  
1 0.23% javier garcía muerte gay periodista  
1 0.23% fondos para presentaciones  
1 0.23% mataron a periodista de rctv  
1 0.23% la muerte del periodista de rctv  
1 0.23% javie garcia periodista rctv muerto  
1 0.23% muerto javier garcia el mundo  
1 0.23% javier garcias rctv  
1 0.23% javier garcias de rctv era gay  
1 0.23% el periodista javier garcia era gay  
1 0.23% javier garcia periodista como murio venezuela  
1 0.23% muerte de javier garcia era gay  
1 0.23% muere javier garcia periodista de rctv  
1 0.23% fotos muerte del periodista de rctv  
1 0.23% renuncia formato  
1 0.23% formato de carta de renuncio  
1 0.23% javier garcìa es gay  
1 0.23% muerte javier garcias  
1 0.23% ejemplo de una carta labopral  
1 0.23% muerte de javier garcia gay  
1 0.23% javier garcia.periodista rctv fotos  
1 0.23% muerte de periodista de rctv javier garcia  
1 0.23% javier garcia gay periodista rctv muerto  
1 0.23% muerte periodista garcia  
1 0.23% fotos muerte de peridista javier garcia  
1 0.23% fotos muerte de periodista javier garcia  
1 0.23% mataron al periodista de rctv javier garcia  
1 0.23% muerto javier  
1 0.23% formato de una liquidacion de las prestaciones sociales 2008
1 0.23% periodista de rctv asesinado  
1 0.23% javier garcía muerto  
1 0.23% rctv garcia  

domingo, 15 de junio de 2008

Ha muerto Javier García Periodista de RCTV ¿Era Gay?

Hace minutos me acabo de enterar la muerte de Javier Garcia un carajo joven talentoso y con futuro. Lo comenté con todos mis amigos online y dado que no se conoce ni como lo mataron ni nada hice la pregunta de rigor:

¿Era Gay?

Es de todos conocido que muchas muertes misteriosas, de las que no revelan muchos datos ocurren a estas personas. A los que les pregunté me dijeron que pensaron también en eso. Esperamos más noticias para ver que rayos pasó y que esa pregunta fea no pase por nuestras mentes. No lo digo por mamar gallo sino que a uno le viene a la mente eso.

Fuera la que fuere una vida humana no puede ser quitada sino por Dios. Quien lo haya hecho deberá ser castigado.

Inyectarse o consumir esteroides anabolicos

Hoy he visto en national geographic un programa que deseaba mucho ver sobre los esteroides. En este caso hablemos de los esteroides anabolizantes que son los que se usan para ganar músculos pues están los esteroides corticoides que son para otras cosas... como para tratar alergias y el asma, estos no te harán musculoso ni tienen que ver con los esteroides anabolizantes en nada de lo que nos interesa acá.

Este post va dirigido a la gente que piensa consumir esteroides y diré lo que pienso...

Los esteroides no deben ser consumidos por adolescentes: En esta etapa de la vida se está desarrollando el hombre. El intentar consumir esteroides trae consecuencias feas: acné, detiene el desarrollo de los huesos y cosas por el estilo. Inclusive el mega mass te puede llenar la cara de espinillas, lo vi en esos tiempos. Así que mi humilde opinión es que tu vida comienza y ni siquiera eres joven. Trata de entrenar lo más natural posible. Crea la disciplina suficiente para entrenar y tener una buena base muscular. Los esteroides realmente no son necesarios para levantar chicas, para darte a respetar entrena karate o algo así pues con eso no comes tamaño jejeje.

Conclusión: Un adolescente no debe consumirlos. A estas edades las razones son muy superficiales para hacerlo y si necesitas destacar en un deporte y no lo logras natural plantea otras metas antes de consumir esteroides y atrofiarte el desarrollo.

Se habla demasiado mal de los esteroides: Cuando ves los efectos colaterales de los esteroides te pintan que si tan sólo los ves te pueden suceder cosas que te vas a dormir con pesadillas. En lo que vi en el documental decían que para la ciencia era muy difícil concluir los efectos secundarios de los esteroides porque era un peo reunir una muestra significativa de individuos para estudiarlos. Sin embargo si hay gente que ha muerto y ha sufrido daños que van desde simple hepatitis hasta derrames cerebrales... pero OJO bajo un prolongado y alto consumo, y es allí donde pienso: Si tomas mucha caña te jodes el hígado, si comes mucho cochino se te tapan las venas y te mueres, si no duermes mucho te jodes. Con respecto a los cambios eufóricos, emocionales y psicológicos pienso que no son causados por ellos sino que la gente que tiene problemas mentales y se los inyecta (quizás esos mismos problemas los llevan a consumir) hacen que estos males se aviven mas.

Conclusión: Si te inyectas bastante y por mucho tiempo es como quien come mucho o quien bebe mucho se enferma ¿verdad? te pasará lo mismo SOLO si consumes mucho y por mucho tiempo es muy probable que te dañes el hígado, satures de colesterol tus arterias, dañes tu corazón y las bolas se te van a poner chiquiticas y te puedes morir. Debes considerar consultar un psicólogo antes de meterte eso porque si eres medio tostao o te pones depre los esteroides acentuarán los síntomas.

Inyectarse los esteroides es un riesgo... ¿quieres tomarlo nada más para verte mas musculoso? (si lo haces con precaución y poco tiempo es muy probable que no te vaya a hacer daño, si tienes tendencia a adicciones puede que lo hagas prolongadamente y te causes daño) ¿La razón por la que lo deseas es tan importante como para tomar ese riesgo?

Recuerda que hay un trastorno llamado Vigorexia que es un vicio creado en nuestra sociedad superficial, tal vez no seas tu quien quiera meterse esteroides sino que sea tu trastorno de Vigorexia quien te está pidiendo que te inyectes esas nalgas.

sábado, 14 de junio de 2008

Como hacer palomitas con el Teléfono Celular

He aquí un mito supuestamente comprobado: si colocas unas palomitas de maiz sin explotar entre 4 celulares y los haces repicar estas se volveran cotufas.


He aqui como supuestamente se hace el truco:


Cell Phone Popcorn Hoax Revealed - video powered by Metacafe

viernes, 13 de junio de 2008

Con-cafe habla ya Sobre mipunto.com

Con-cafe ya se ha hecho eco del cierre súbito de mipunto.com

http://www.con-cafe.com/index.php/2008/06/13/¿desaparece-mipuntocom-y-movistarnetve

Que cierre tan feo ¿cómo quedó la gente que tenia sus cuentas mail mipunto.com? ¿Por qué tan violento? ¿Eso era otra empresa que no era de movistar?  porque tremendra raya que tiene la trasnacional. Mal servicio celular y ahora quitan un servicio de internet.

Es feo... da mal aspecto, ni un comunicado ni nada...

Por cierto mi post sobre el cierre de mipunto fue primero que el de con-cafe lero lero jejejeje

que paso con mipunto.com?

Me disponía a usar el cómodo servicio de recargar mi movistar por la tdc (irónico pero útil). Y al entrar a www.mipunto.com me en vez de toparme con la página entro veo esto:



Qué rayos pasó? busqué en google mipunto, entré al link y entró a lo mismo.

¿Qué ocurrió con mipunto? ¿Se les olvidó pagar el dominio? ¿quebró?

Movistar anda extraña.

domingo, 8 de junio de 2008

Frase de Snoop Dog

"Mucha gente le gusta engañarte y decirte que tu no eres inteligente si nunca fuiste al colegio. Pero el sentido común manda sobre todo. Es lo que aprendí vendiendo crack"

"A lot of people like to fool you and say that you're not smart if you never went to college, but common sense rules over everything. That's what I learned from selling crack"

Tomado de Perez Hilton

viernes, 6 de junio de 2008

Los 5 mejores antivirus

... Según Lifehacker (link) preguntaron a sus usuarios cuales eran los mejores antivirus. La respuesta (desconcertante para mí) fue la siguiente (creo que en orden de preferencia)

AVG Anti-Virus (Freeware and Shareware) (link)
NOD32 (Shareware) (link)
Avast Antivirus (Freeware and Shareware) (link)
Avira AntiVir (Freeware and Shareware) (link)
Kaspersky Anti-Virus (Shareware) (link)

Esta lista es de preferencia... lo que la gente prefiere usar. Es la voz del pueblo...

Mi consejo es que no tomen en cuenta esta lista y usen o NOD32 o Kaspersky. Los demás son basura.

miércoles, 4 de junio de 2008

Proceso Unificado de Desarrollo (PUD)

Reseña Histórica del Proceso Unificado de Desarrollo (PUD)

El PUD es el resultado de 30 años de desarrollo y uso práctico. Se puede dividir el transcurso de su desarrollo en tres etapas: desde la publicación de “Objectory Method” publicado en 1987 como resultado del éxito del método Ericsson, pasando por el “Objectory Rational Process” (Desarrollado por IBM Rational entre 1996-1997) hasta el Proceso Unificado de Rational (publicado en 1998).

El Método Ericsson

El estudio del origen del PUD, se remonta a 1967, donde la compañía Ericsson modelaba un sistema entero como una serie de bloques interconectados. Los bloques de más bajo nivel se incorporaban a subsistemas de mayor nivel, con lo que se lograba que el sistema fuera más manejable. Los bloques, eran identificados estudiando los “Casos de Negocio” (actuales casos de uso) que se definían con anterioridad. Cada caso de negocio permitía detallar los bloques que debían cooperar para llevarlo a cabo.

Al tener adjudicada la responsabilidad de cada bloque, se preparaba su especificación. Las actividades de diseño generaban un conjunto de diagramas de bloques estáticos con sus interfaces, agrupados en subsistemas (su semejante en la actualidad son los diagramas de clases ó paquetes de UML).

El producto primogénito de las actividades de diseño radica en la descripción de la arquitectura de software, la cual consistía en la comprensión de los requisitos más críticos, junto con una breve descripción de cada bloque y el agrupamiento de éste en subsistemas. Luego, eran representadas en diagramas la descripción e interconexiones de los bloques. El método era adelantado a su tiempo, ya que los clientes no acostumbraban a que se representaran los productos de software en forma similar a los datos de proyectos de ingeniería.

El método Ericsson es esencialmente el que actualmente se conoce como “desarrollo basado en componentes”. Comprobó su efectividad de diseño modular al brindar la posibilidad de instalar cada bloque ejecutable o modificado sobre la marcha de un sistema de telecomunicaciones en ejecución el 100 por ciento de su tiempo (era sumamente improductivo detener un sistema de tal magnitud simplemente para hacer cambios).

Objectory

Ivar Jacobson fue el principal desarrollador de la metodología empleada en Ericsson. Deja la compañía en 1987 y funda Objectory AB en Estocolmo. Como fruto de 8 años de trabajo en su compañía, él y sus colaboradores desarrollan un proceso denominado “Objectory” (Abreviatura de “Object Factory” en español, fábrica de objetos). El empleo de esta metodología se extendió en diversas industrias además de las de telecomunicaciones, y en muchos países aparte de Suecia.

Es en Objectory donde se define con su nombre al Caso de Uso, y se desarrolla una técnica para su representación. La idea se amplió, y como consecuencia los casos de uso que dirigían el desarrollo se hicieron más claros, dando pié al origen de la metodología que guíe al desarrollador e informe al usuario.

Surgen los flujos de trabajo, representados por una serie de modelos: requisitos-casos de uso, análisis, diseño, implementación y prueba. Cada modelo representaba una perspectiva del sistema, éstos permiten al desarrollador realizar una traza sobre un caso de uso a través de la secuencia de modelos hasta el código fuente cuando surgen problemas (incluso puede volverse hacia atrás).

Objectory aportó ideas sobre cómo diseñar procesos generales sobre los que opera un negocio, ya que eran aplicables los mismos principios. El desarrollo de Objectory transcurrió en una serie de versiones, desde la 1.0 de 1988 a la primera versión interactiva: Objectory 3.8. El método fue publicado en un libro en 1995.

El Proceso Objectory de Rational

A finales de 1995, Objectory AB es adquirida por Rational Software Corp. Inmediatamente, surge la especial urgencia de unificar los principios básicos subyacentes en los procesos de desarrollo existentes, y se optó por unir lo mejor de cada uno. Al momento de fusionarse, Objectory 3.8 había probado la creación y modelado de un proceso de producción de software de manera similar a un producto, dando origen a una arquitectura original de desarrollo y contaba con una serie de modelos que documentaban el resultado del proyecto. Sin embargo, aunque correctamente desarrollado en lo referente a modelado de casos de uso, análisis y diseño, no se encontraba bien desarrollado en áreas como la gestión de requisitos aparte de los casos de uso, implementación y pruebas.

Es en esta parte, donde entra la experiencia y práctica de Rational, mejorando el proceso y originando Objectory 4.1 en 1997. Entre las mejoras que lo conforman se encuentran el añadir fases de desarrollo y la aproximación iterativa controlada.

Es de hacer notar, que se desarrolló también una definición muy precisa de la arquitectura, que fue considerada una de las partes más significativas de la organización del sistema, y se representó por medio de vistas arquitectónicas de los modelos. El desarrollo iterativo se convirtió en una metodología que usaba como directriz los riesgos considerados en primer lugar por la arquitectura. Cabe destacar que UML se encontraba en fase de desarrollo, y se une como el lenguaje de modelado del Proceso Objectory de Rational (Rational Objectory Process, ROP). Philippe Kruchten realizó mejoras del ROP, reforzando elementos como la gestión de proyecto.

El Lenguaje Unificado de Modelado

A principios de los 90, surgió la necesidad de un lenguaje de modelado visual y consistente, que permitiera expresar los resultados de las extensas variedades de metodologías Objeto Orientadas que existían.

Por esta razón, Grady Booch, Autor del método Booch y James Rumbaugh, desarrollador principal de OMT (Object Modeling Technique), quienes trabajaban juntos en rational, comenzaron a unificar sus metodologías. El fruto de esta unión es la versión 0.8 del Método Unificado (Unified Modeling Language ó UML), publicado en Octubre de 1995.

Casi en el mismo momento, Ivar Jacobson se incorpora a laborar en Rational y se une para la producción de la versión 0.9 de UML. El esfuerzo de unión incluía a otros expertos en el área e involucró empresas como IBM, HP y Microsoft. Luego de pasar por el proceso de estandarización el OMT (Object Management Group) publica en noviembre de 1997 la versión estándar de UML 1.1.

El Proceso Unificado de Rational

A partir de 1997, Rational se fusiona y adquiere otras empresas fabricantes de herramientas que ampliaron mucho más el proceso Objectory de Rational. Para 1998 Se había convertido en un proceso capaz de soportar el ciclo de vida de desarrollo en su totalidad, integraba una riqueza de aportaciones de las más diversas fuentes de autores.
Reseña Histórica de los Autores del PUD
Grady Booch

Según Rational.com Grady Booch es reconocido internacionalmente por su innovador trabajo en la ingeniería y modelado de software. Recibió su título de grado en ciencias en la Academia de la Fuerza Aérea de los Estados Unidos en 1977, y su maestría de ciencias en ingeniería eléctrica en la Universidad de California en Santa Bárbara en 1979.

Ha pertenecido a la compañía IBM Rational en calidad de Jefe Científico desde su fundación en 1981. Booch es uno de los desarrolladores originales del Lenguaje Unificado de Modelado (UML, en inglés) y fue también desarrollador de varios productos de IBM Rational. Ha servido como arquitecto y mentor arquitectónico de numerosos proyectos de software de intensa complejidad desarrollados alrededor del mundo.

Grady ha sido autor de 6 libros Best Seller, entre los que están: “UML Users Guide” y “Object - Oriented Analysis with Applications”. También ha publicado cientos de artículos técnicos sobre ingeniería de software, incluyendo publicaciones a principios de los 80 que originaron el término y la práctica del Diseño Orientado a Objetos.

Actualmente es miembro de Association for Computing Machinery (ACM), Institute of Electrical and Electronics Engineers (IEEE) , the American Association for the Advancement of Science (AAAS) y Computer Professionals for Social Responsibility (CPSR). Está afiliado en calidad de Fellow en ACM, IBM, World Technology Network y Software Development Forum Visionary.

James Rumbaugh

Según Rational.com ha sido uno de los principales desarrolladores de metodologías para el diseño de software del mundo. Realizó sus estudios en el MIT (Massachusetts Institute of Technology), obteniendo el grado de BS. en física. En Caltech obtuvo el grado de magíster en astronomía y un Ph.D. en ciencias de la computación realizado también en el MIT bajo la dirección del Dr. Jack Dennos. Junto con su colega de IBM Rational, Grady Booch e Ivar Jacobson, desarrollaron el Lenguaje Unificado de Desarrollo (UML por sus siglas en inglés), el cual es el estándar adoptado por “Object Management Group” en 1997. James, ha sido el representante líder de IBM Rational a cargo de desarrollos posteriores de UML para la OMG, y ha contribuido en muchos de los conceptos de UML. También ha laborado junto con otros líderes de Rational de otras áreas como IBM Rational Unified Process® y metodologías de desarrollo en tiempo real.

James, mantiene una experiencia en el campo de metodologías de software de más de 30 años. Fue el desarrollador jefe de “Object Modeling Technique” (OMT), una metodología de análisis y diseño objeto orientada, predecesora de UML. Antes de unirse a IBM Rational (1994), trabajó por 25 años en el Centro de Investigaciones y Desarrollo de General Electric de Schenectady, Nueva York. En su tiempo de trabajo en el centro, desarrolló el lenguaje de programación orientado a objetos DSM, el modelo de control de tres estados, la notación de objetos OMT (Cabe mencionar que los fundamentos para el desarrollo de la notación de dicha metodología se desarrollaron por mas de 10 años con la colaboración de Mary Loomis y Ashwin Shah) y una herramienta para la edición gráfica del modelado de objetos.

Su carrera ha cubierto aspectos de la semántica de la computación, herramientas para la productividad de la programación, y aplicaciones que usan algoritmos complejos y estructuras de datos. Desarrolló el Sistema de Gráfico de Flujo, un sistema de gráfico interactivo genérico por controlar una red de plan que diseña los trabajos, incluso la dirección de versiones múltiples de datos y coordinación de flujo de información entre las aplicaciones; recibiendo una patente por los conceptos mencionados anteriormente. Además, desarrolló algoritmos para la reconstrucción de imágenes, optimizando dicho proceso de manera sorprendente. Algoritmos para el despliegue de imágenes tridimensionales en tiempo real. Finalmente es el autor de los libros: Guía de Usuario de UML Manual de Referencia de UML El Proceso de Desarrollo de Software Unificado.

Ivar Jacobson

Fue el creador del “Objectory method” y fundador de “Objectory AB” En Suecia. Actualmente se encuentra retirado, pero fue anteriormente Vicepresidente de Ingeniería de Negocios en Rational Software, donde se involucró en el desarrollo de UML. Ivar Jacobson es bien conocido por ser pionero y por 25 años de experiencia en el uso de la metodología objeto orientada para el diseño de sistemas de gran escala y de tiempo real. Su trabajo a gran escala y arquitectura de reutilización fue elemento clave para el éxito de “AXE telecommunications switch” de Ericsson.

Es el autor principal de dos libros de gran importancia en la programación Orientada a Objetos: “Object-Oriented Software Engineering” y “Business Process Reengineering with Object Technology”. Jacobson es también conocido por la invención de los Casos de Uso y el proponer modelos separados para el análisis y el diseño, ya que para sistemas complejos a gran escala, es de mayor utilidad mantener un modelo de objetos idealizado del sistema que muestre cómo los objetos pueden colaborar para reunir los requerimientos funcionales.

Aspectos generales de la metodología

Según Booch, Rambaugh y Jacobson, (2000) El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades para transformar los requisitos de un usuario en un sistema software. Sin embargo, el Proceso Unificado es más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud diferentes tamaños de proyectos.

El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas.

El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial del Proceso Unificado. No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres fases claves: dirigido por casos de uso, centrado en la arquitectura, e interactivo e incremental. Esto es lo que hace único al Proceso Unificado.
Características de la metodología

Según Booch, Rambaugh y Jacobson, (2000, p. 4-6) PUD está dirigido por casos de usos, está centrado en la arquitectura y es un proceso iterativo e incremental.

El Proceso Unificado está dirigido por casos de usos

Un sistema de software ve la luz para dar servicios a sus usuarios. Por tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. Los casos de uso han sido adaptados casi universalmente para la captura de requisitos de sistemas software en general.

El termino usuario (actores) no sólo hace referencia a usuarios humanos sino a otros sistemas. En este sentido, el termino usuario representa alguien o algo que interactúa con el sistema que estamos desarrollando; como respuesta al usuario el sistema lleva a cabo una secuencia de acciones que proporcionan al usuario un resultado importante.

Una interacción de este tipo es un caso de uso; un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de usos representan los requisitos funcionales. La captura de requisitos tiene dos (2) objetivos: encontrar los verdaderos requisitos y representarlos de un modo adecuado para los usuarios, clientes y desarrolladores,

Todos los casos de uso juntos constituyen el modelo de casos de uso; los casos de uso no son sólo una herramienta para especificar los requisitos de un sistema: También guían su diseño, implementación, y prueba; esto es, guían el proceso de desarrollo.

De este modo, los casos de uso no sólo inician el proceso de desarrollo sino que le proporciona un hilo conductor Dirigido por caso de uso quiere decir que el proceso de desarrollo sigue un hilo; avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los casos de uso se especifican, se diseñan, y los casos de finales son la fuente a partir de la cual se construyen casos de prueba.

Aunque es cierto que los casos de uso guían el proceso no se desarrollan aisladamente. Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso guían la arquitectura del sistema y la arquitectura del sistema influye en la selección de los casos de uso. Por tanto, tanto la arquitectura del sistema como los cosos de uso maduran según avanza el ciclo de desarrollo.

El proceso unificado está centrado en arquitectura

El papel de la arquitectura software es parecido al papel que juega la arquitectura en la construcción de edificios. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura brinda una clara perspectiva del sistema completo, necesaria para controlar el desarrollo. Un sistema software es una única entidad por lo que es útil presentar el sistema desde diferentes perspectivas para comprender mejor el diseño. Estas perspectivas son vistas del modelo del sistema. Todas estas vistas representan la arquitectura.

La arquitectura surge de las necesidades de la empresa, como las perciben los usuarios y los inversores y se reflejan en los casos de uso. Sin embargo, también se ve influida por la estructura, el comportamiento y por muchos otros factores, como la funcionalidad, el rendimiento, la flexibilidad, la reutilización, la facilidad de comprensión, las restricciones y los compromisos económico, tecnológicos y la estética. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado.

Los sistemas se simulan para darle una forma. Es esta forma, la arquitectura, debe diseñarse para permitir que el sistema evolucione, no sólo en su desarrollo inicial, sino también a lo largo de las futuras generaciones. Para encontrar esa forma se debe trabajar sobre la compresión general de las funciones clave, es decir, sobre los casos de uso clave del sistema. La arquitectura se necesita para: comprender el sistema, organizar el desarrollo, fomentar la reutilización y hacer evolucionar el sistema.

El Proceso Unificado es iterativo e incremental

El desarrollo de un producto software supone gran esfuerzo que puede durar varios meses hasta posiblemente un año o más. Es práctico dividir el trabajo en partes más pequeñas o microproyectos. Cada microproyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, al crecimiento del producto; las iteraciones deben estar controladas; esto es, se deben seleccionar y ejecutar de una forma planificada.

La selección de lo que se implementará se basa en una iteración en dos factores. En primer lugar, la iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteración trata los riesgos más importantes

Fases dentro de un ciclo

El desarrollo de un ciclo se realiza a lo largo del tiempo. Según Booch, Rambaugh y Jacobson, (2000) Cada ciclo se divide a su vez en 4 fases:

• Inicio: es la fase en que se plantea una descripción del producto final, a partir de una buena idea y se presenta el análisis de negocio para el producto.

• Elaboración: se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura del sistema.

• Construcción: es la fase en que se crea el producto, añadiendo el software terminado a la arquitectura, convirtiendo la línea base de la arquitectura en el sistema completo. La descripción evoluciona hasta convertirse en un producto preparado para ser entregado al usuario.

• Transición: abarca el período en el que el producto es una versión beta, en la cual un reducido número de usuarios con experiencia prueba el producto, para informar sus defectos y deficiencias.

Para poder realizar el desarrollo de las fases se deben tomar en cuenta los flujos de trabajo (requisitos, análisis, diseño, implementación y prueba).

Los requisitos

La captura de los requisitos en algunas oportunidades resulta un poco complicada, esta es la acción de descubrir, luego de realizar ciertas averiguaciones, lo que los usuarios desean que los desarrolladores de software construyan.

El flujo de trabajo de los requisitos tiene como objetivo fundamental guiar el desarrollo hacia el sistema correcto. Esto mediante una buena descripción de los requisitos del problema que permite un buen entendimiento entre los clientes o usuarios y los desarrolladores del sistema.

Análisis

En este flujo se representa el análisis de los requisitos que se describen en la captura de los requisitos. El propósito de realizar esta acción es conseguir la comprensión de los requisitos más precisa y una descripción de estos que nos ayude a estructurar mejor el sistema entero.

En el análisis se utiliza un lenguaje que se basa en un modelo de objetos conceptual, al cual se le llama modelo de análisis. El modelo de análisis permite refinar los requisitos y razonar sobre los aspectos internos del sistema.

Una de las razones por las cuales es importante analizar los requisitos en la forma de un modelo de análisis es que el modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su modificación y en forma general, su mantenimiento.

Diseño

El diseño no es más que la modelación del sistema en la cual encontramos su forma para que soporte todos los requisitos. El resultado del análisis, es decir, el modelo de análisis representa una entrada esencial en el diseño. Entre los objetivos del diseño encontramos los siguientes: obtener una comprensión en profundidad de los requisitos y restricciones relacionadas con los lenguajes de programación, componentes reutilizables, sistemas operativos, tecnologías de distribución y concurrencia, tecnología de interfaz de usuario, tecnologías de gestión de transacciones, entre otras.

Implementación

Aquí se toma en cuenta el resultado del diseño y se realiza la implementación del sistema en términos de componentes, es decir, ficheros de código fuente, scripts, ficheros de códigos binarios, ejecutables y similares.

La implementación tiene varios propósitos entre los cuales se pueden citar los siguientes:

• Planificar las integraciones de sistema necesarias en cada iteración.

• Asignar componentes ejecutables a nodos en el diagrama de despliegue para distribuir el sistema.

• Implementar las clases y subsistemas encontrados durante el diseño.

• Probar los componentes individualmente, y a continuación integrarlos compilándolos y enlazándolos en uno o más ejecutables, antes de ser enviados para ser integrados y llevar a cabo las comprobaciones del sistema.

Prueba

En este flujo de trabajo se verifica el resultado de la implementación probándose cada construcción, incluyéndose las construcciones finales del sistema que serán entregadas a los usuarios.

Entre los propósitos de la prueba se tienen:

• Planificar las pruebas necesarias en cada iteración.

• Diseñar e implementar las pruebas creando los casos de pruebas que especifican qué probar, creando los procedimientos de pruebas que especifican como realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.

• Llevar a cabo las diferentes pruebas y manejar los resultados de cada una sistemáticamente.

Ventajas y Desventajas del PUD

Ventajas

• Las iteraciones y construcciones proporcionan reducen la proporción de las tareas, grupos de trabajo y permiten un constante control de riesgos y realimentaciones.

• Permite un lenguaje común como lo es UML, convirtiendo al desarrollo de software una disciplina de ingeniería en vez de meramente escribir código.

• Al emplear las tecnologías de componentes, se puede emplear la reutilización, reduciendo el tiempo y los costes de desarrollo.

Desventajas

• Todo el proceso como tal, se encuentra muy ligado al método, lo que puede ocasionar inconvenientes al tratar de combinar con otras metodologías.

• A pesar de su desarrollo, el método aún no incluye una metodología totalmente explícita para el control de las actividades de gestión.

Herramientas de modelado que utilizan la metodología PUD

Según Booch, Rambaugh y Jacobson, (2000) Las herramientas son buenas para automatizar procesos repetitivos, mantener las cosas estructuradas, incrementar la productividad y la calidad, gestionar grandes cantidades de información y guiarnos un camino de desarrollo concreto.
Sin un soporte por herramientas que automatice la consistencia a lo largo del ciclo de vida, será difícil mantener actualizado los modelos y la implementación. El desarrollo iterativo e incremental será más difícil, acabara siendo inconsistente, o requerirá gran cantidad de trabajo manual para actualizar documentos y mantener así la consistencia.

A medida que se introduce un soporte por herramientas, se obtiene un proceso diferente, más formal. Podemos incluir nuevas actividades que seria poco práctico realizar sin herramientas. Podemos trabajar de una manera mas precisa durante el ciclo de vida entero: se puede utilizar un lenguaje de modelado formal como UML para asegurar que caca modelo es consistente internamente con relación a otros modelos. Se puede utilizar un modelo y a partir de el generar partes de otro (por ejemplo del diseño a la implementación y viceversa).

Las herramientas que implementan un proceso automatizado deben ser fáciles de usar. Hacerlas muy manejables significa que los desarrolladores de herramientas deben considerar seriamente la forma en que se lleva acabo el desarrollo del software.

El desarrollo del proceso y su soporte por herramientas debe tener lugar de manera simultánea. En cada versión del proceso debe haber también una versión de las herramientas. En cada versión debe darse ese equilibrio. Alcanzar casi el ideal de este equilibrio nos llevara varias iteraciones, y las sucesivas iteraciones deben guiarse por la retroalimentación de los usuarios entre versiones.

Un ejemplo significativo de una herramienta en el contexto de soporte del proceso unificado es la herramienta de modelado para UML. UML es lenguaje visual. Como tal, se le suponen características comunes en muchos productos de dibujo como edición, dar formato, hacer zoom, imprimir, dar color y diseño automático. Además de esas características UML define reglas sintácticas que especifican como combinar elementos del lenguaje. Por tanto, la herramienta debe ser capaz de garantizar que se cumplen esas reglas. Esta posibilidad esta fuera del alcance de los productos de dibujos habituales donde no se comprueban reglas.

UML requiere un cierto número de reglas semánticas que también requieren soporte. Estas herramientas pueden incluirse en la herramienta de modelado, bien como de cumplimiento obligado inmediato o rutinas bajo demanda que reconocen el modelo y comprueban si hay errores comunes, o buscan faltas de compresión semánticas o sintácticas.

Mediante el uso de UML como lenguaje estándar, el mercado experimentara un soporte por herramientas mucho mejor que el que nunca haya tenido ningún lenguaje de modelado. Esta oportunidad de un soporte mejor es debida en parte a la definición precisa de UML. También puede atribuirse al hecho de que UML es hoy en día un estándar industrial ampliamente utilizado. En lugar de haber fabricantes de herramientas compitiendo para dar soporte a muchos lenguajes de modelado diferentes, el juego esta en encontrar ahora al que mejor soporte UML. Este nuevo juego es mejor para los usuarios y clientes del software. Entre las herramientas que soportan todos los aspectos del ciclo de vida del software:

• Gestión de requisitos: se utiliza para almacenar, examinar, revisar, hacer el seguimiento y navegar por los diferentes requisitos de un proyecto de software.

• Modelado visual: se utiliza para automatizar el uso de UML, es decir, para modelar y ensamblar una aplicación visualmente. Con esta herramienta conseguimos la integración con entornos de programación y aseguramos que el modelo y la implantación siempre son consistentes.

• Herramientas de Programación: proporcionan una gama de herramientas, incluyendo editores, compiladores, depuradores, detectores de errores y analizadores de rendimiento.

• Aseguramiento de la calidad: se utiliza para probar aplicaciones y componentes, es decir, para registrar y ejecutar casos de prueba que dirigen la prueba de un IGU y de las interfaces de un componente. En un ciclo de vida iterativo, la prueba de regresión es aun mas esencial que en el desarrollo convencional. La automatización de los casos de prueba es esencial para conseguir una productividad alta. Además muchas aplicaciones también necesitan ser expuestas a pruebas de estrés y de carga.

Modelos de PUD

En PUD, ofrece una serie de modelos que permiten llevar a cabo todas las representaciones del producto software deseado.

• Modelo de Casos de Uso: un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. El modelo de Casos de Uso brinda la posibilidad de representar los casos de uso y su relación con todos los usuarios involucrados en el sistema.

• Modelo de Análisis: este Modelo tiene dos finalidades: refinar con más detalle los casos de uso y a su vez establecer la asignación inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento.

• Modelo de Diseño: con el se definen la estructura estática del sistema en la forma de subsistemas, clases e interfases. También, permite representar los casos de uso en forma de colaboraciones entre los subsistemas, clases e interfaces.

• Modelo de Implementación: incluye componentes, (que representan al código fuente) y la correspondencia de las clases con los componentes.

• Modelo de Despliegue: define todos los nodos físicos (ordenadores) y la correspondencia de los componentes con esos nodos.

• Modelo de Prueba: un caso de prueba es un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados, desarrollados para un objetivo concreto. El modelo describe los casos de prueba que verifican si el sistema implementa correctamente su especificación, definida en los casos de uso.

Diagramas de UML

Para Booch, Rambaugh y Jacobson (ob. cita, p.82), los distintos diagramas que se pretenden obtener de un sistema mediante UML son:

• Diagramas de casos de uso.
• Diagramas de clases.
• Diagramas de comportamiento o interacción. Entre ellos:

• Diagramas de estado.
• Diagramas de actividad.
• Diagramas de secuencia.
• Diagramas de colaboración.

• Diagramas de implementación.
• Diagrama de componente.
• Diagrama de plataforma.

Explicar cómo se construyen y para qué se utilizan cada uno de los diagramas supondría mucho tiempo. A continuación se procede a explicar brevemente algunos aspectos importantes:

Diagramas de casos de uso.

Para Booch, Rambaugh y Jacobson (ob. cita, p.84), un caso de uso es una secuencia de operaciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y otros sistemas. Un actor es una entidad externa al sistema que se modela y que puede interactuar con él. Un ejemplo de actor puede ser un usuario o cualquier otro sistema.

Diagramas de Clases.

Para Booch, Rambaugh y Jacobson (ob. cita, p.83), muestra un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, junto con sus contenidos y las relaciones que se establecen entre ellos.

Diagramas de interacción o comportamiento.

Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:


• Diagramas de secuencia: para Booch, Rambaugh y Jacobson (ob. cita, p.84), modelan las interacciones entre un conjunto de objetos, ordenadas según el instante en que tienen lugar.


• Diagramas de colaboración: para Booch, Rambaugh y Jacobson (ob. cita, pp.84-85), muestran la interacción entre varios objetos y los enlaces que existen entre ellos.


• Diagramas de actividad: para Booch, Rambaugh y Jacobson (ob. cita, p.85), son similares a los diagramas de flujo de otras metodologías Orientadas a Objetos.

• Diagramas de estado: Para Booch, Rambaugh y Jacobson (ob. cita, p.85), representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a los eventos recibidos.

Diagramas de componentes.

Para Booch, Rambaugh y Jacobson (ob. cita, p.83), muestran las dependencias entre los distintos componentes software, incluyendo componentes de código fuente, binarios y ejecutables. Un componente es un fragmento de código software que se utiliza para mostrar dependencias en tiempo de compilación o en tiempo de ejecución.

Café Sci (2004) Grady Booch
[Documento en línea]
Disponible: http://coloradocafesci.org/Booch.htm
[Consulta, 2004, Octubre 15]

Cangénova, R (2004) Editorial
[Documento en línea].
Disponible: http://www.arcride.edu.ar/appei/revistas/r26a4.htm
[Consulta: 2004, Octubre 17]

Guerrero, L. (2003) Clase 23 - Proceso Unificado de Desarrollo
[Documento en línea].
Disponible: http://www.dcc.uchile.cl/~luguerre/cc51h/clase23.html
[Consulta: 2004, Octubre 10]

Hinchcliffe, D. (2004) Ivar Jacobson
[Documento en línea]
Disponible: http://c2.com/cgi/wiki?IvarJacobson
[Consulta: 2004, Octubre 17]

Jacobson, I.., Booch, G. y Rumbaugh, J. (2000) El Proceso Unificado de Desarrollo de Software. España: Addison Wesley.

Rational (2002) Though Leaders: James Rumbaugh
[Documento en línea]
Disponible: http://www-306.ibm.com/software/rational/bios/rumbaugh.html
[Consulta, 2004, Octubre 10]

Prueba de integración de software

Prueba de integración
La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté deacuerdo con el que dicta el diseño.

Tipos de integración
 Integración descendente, es una estrategia de integración incremental a la construcción de la estructura de programas, en el cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía comenzando por el control principal (Programa principal). Los módulos subordinados de control principal se incorporan en la estructura en la estructura, bien, de forma primero-en-profundidad, bien primero-en-anchura.

 Integración ascendente, es donde la construcción del diseño empieza desde los módulos más bajos hacia arriba (módulo principal), el procesamiento requerido de los módulos subordinados siempre esta disponible y elimina la necesidad de resguardo.
La sección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

Prueba de validación y verificación
Al conjunto de actividades que aseguran que el software implementa correctamente una función específica se denomina verificación. La validación se refiere a un conjunto de actividades que aseguran que el software construido se ajusta a los requerimientos y necesidades del cliente.
La definición de verificación validación envuelve lo que se conoce como calidad del software. Las revisiones técnicas formales ayudan (inspección) ayudan a asegurar la calidad de los productos, a lo largo del proceso la medición y l control se aplica sobre cada elemento de una construcción del software. La prueba construye un elemento importante desde el que se puede evaluar la calidad y, de forma más practica, de cubrir los errores.
Una vez que se culmino la etapa de integración se puede decir que el software esta completamente ensamblado, se ha encontrado y corregido errores de la interfaces y se puede comenzar una serie final de prueba del software. La prueba de validación se logra cuando la expectativas razonable del cliente se cumplen en donde incluye la especificación de requisitos, documentos en donde se describen los atributos del software que son visibles para el usuarios, esta información forma la base del enfoque a la prueba de validación.
Cuando se construye el software para llevar a cabo de validación es casi imposible que el desarrollador pueda prever como un cliente usara realmente el programa es por ello se hace una serie de prueba de aceptación que puede permitir que un cliente valide todos los requisitos, se puede dar el caso de las pruebas alfa y beta

Prueba del Sistema

Un clásico problema de la prueba del sistema es la delegación de culpabilidad. Esto ocurre cuando se descubre un error t cada uno de los creadores de cada elemento del sistema echa la culpa del problema a otros, para evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo siguiente:

 Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.
 Lleva a cabo una serie de pruebas que simulan la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.
 Registrar los resultados de las pruebas como “evidencias” en el caso de señalamientos informales.
 Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.

La prueba del sistema se basa en otras técnicas de pruebas, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema:

1) Prueba de Recuperación: es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.
2) Prueba de Seguridad: intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema negando asi el servicio a otras personas a demas de producir errores a proposito en el sistema o debe curiosear los datos publicos intentando encontrar una clave de acceso al sistema.
3) Prueba de Resistencia: esta diseñada para enfrentar a los problemas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar tirar el sistema. Para lograr esto se puede tomar en consideración lo siguiente:
 Diseñar pruebas especiales que generen 10 o mas interrupciones por segundo.
 Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar como responden las funciones de entrada.
 Ejecutar casos de prueba que requieran al maximo de memoria o de espacio en disco.
 Diseñar casos de prueba que produzcan excesivas busquedas de datos almacenados en el disco.

Métodos de migración de un sistema de software anterior a un sistema nuevo

{de donde saqué esta información no encontré el autor. Lo que se decir es que no es mío}
Conversión
La conversión consiste en el cambio del sistema anterior con el sistema nuevo así como los métodos para llevarla a cabo y verificación de que la conversión se haya efectuado correctamente
Existen cuatro métodos para efectuar una conversión en un sistema, en donde cada método tiene ventajas y desventajas entre los mismos..

Sistemas paralelos
Este método es un modelo seguro, ya que el sistema nuevo funciona al mismo tiempo que el sistema anterior; debido a que si encuentran fallas en al sistema nuevo, al anterior permanece en constante funcionamiento sin perdidas de tiempo, ni de información. Una desventaja muy notable as que este método de conversión es muy costoso ya que se duplican los recursos humanos.

Conversión directa
El sistema anterior será reemplazado por el nuevo sistema, ya que la organización confía plenamente en el nuevo sistema. Obligando así a los usuarios a que hagan funcionar al nuevo sistema encontrando en él nuevos métodos y controles.

Enfoque piloto
En este método se implanta el nuevo sistema en una parte de la organización. Con base a retroalimentación se hacen cambios y el sistema se instala en el resto de la organización mediante algunos otros métodos. La desventaja es que el nuevo sistema puede dar la impresión de que el nuevo sistema no es confiable, ni está libre de errores.

Conversión por etapas
Se implanta el nuevo sistema de manera gradual, reemplazando partes del sistema anterior, permitiendo a los primeros usuarios aprovechar las ventajas del nuevo sistema, así como la capacitación de los mismos, llevando a cabo la instalación de una nueva etapa una vez que fue aceptada sin hacer uso necesario de recursos extras,

Plan De Conversión
El plan de conversión incluye une lista de actividades para llevar a acabo la implantación del nuevo sistema y ponerlo en operación.
El plan de conversión debe prevenir los posibles problemas y la forma de enfrentarlos implementando planes de emergencia adecuados. Algunos problemas que se presentan comúnmente son:
- Documentos perdidos
- Variación entre datos de los formatos nuevos y anteriores
- Errores en la conversión de datos Extravío de datos o pérdida de archivos
- Omisión en algunos pasos de la conversión

Acondicionamiento De Las Instalaciones
El cliente o el ingeniero de sistemas presentará una lista de especificaciones para el cableado eléctrico y los contactos, necesidades de aire acondicionado, controles de humedad y exigencias de espacio, lo más recomendable es tener el local antes de la llegada del equipo.

Capacitación De Operadores Y Usuarios Para Operar El Sistema
Como consecuencia la calidad de capacitación recibida por el personal que manipulará el sistema ayuda u obstruye, y puede llegar a impedir, la implantación exitosa de un sistema de información. Tanto operadores como los usuarios del sistema requieren de capacitación.

Capacitación de operadores
La mayoría de los sistemas dependen del personal de Centro de Cómputo. La capacitación que el personal reciba debe de asegurar que puedan manejar todas las operaciones posibles, tanto rutinarias como extraordinarias. La capacitación que reciba el operador también debe contemplar al personal de capture de datos,
Como parte de la capacitación se le debe dar al personal una lista de formas de resolver los problemas y que identifique los posibles problemas y solución, así como datos personales de las personas a quién buscar cuando surjan problemas inesperados.

Capacitación de usuarios
La capacitación de usuarios incluye la identificación de problemas, determinando si el problema que surge es ocasionado por hardware o por software, o por algo realizado por los mismos usuarios que ocasione la falla del sistema,
No hay nada más desesperante que trabajar con un sistema y que suceda un problema y no ser capaz de determinar si es falla del propio sistema, del equipo o de los usuarios. El lugar para prevenir estos casos es durante la capacitación.
Las actividades de manipulación de los datos que recibe le mayor atención en le capacitación de usuarios son la captura de datos, la formulación de consultas y el borrados de los registros de datos. Le mayor parte de le capacitación de los usuarios tiene que ver con la operación del sistema en sí. La capacitación en la codificación de los datos marca la paute en el proceso de captures partir de las transacciones, o en la preparación de datos necesarios para las actividades de apoyo a les decisiones.

Métodos de capacitación
La capacitación a operadores y usuarios se puede manifestar de diferentes formas. Las actividades de capacitación se pueden llevar a cabo en las instalaciones de los proveedores, locales rentados. Los métodos y contenido de la capacitación varia de acuerdo e la fuente y del lugar de le capacitación

Instalación Y Pruebas Del Usuario Para Aceptación Del Sistema
En la instalación y prueba del usuario, son algunas actividades que realiza el usuario con el fin de verificar el sistema si funciona con el hardware diferente al hardware de desarrollo, tal como su instalación y funcionamiento en general, en esta etapa se abarcan cuatro aspectos importantes
La prueba de entrada
La prueba de salida
Prueba de la base de datos,
Prueba de los controles.

El metodo híbrido para pruebas de software

{de donde saqué esta información no encontré el autor. Lo que se decir es que no es mío}
MÉTODO HÍBRIDO


Es el método de prueba más completo que se le puede aplicar a un software, ya que consiste en aplicar los siguientes métodos:


Ø Método de Caja Negra (Análisis de Fronteras): se estudian las salidas del sistema ante diferentes entradas.

Ø Método de Caja Blanca (Cobertura Ciclomática de Caminos): al observar el diagrama y aplicar las ecuaciones sacadas del teorema de Grafos, se obtiene la ecuación NC = E À+2, siendo NC la complejidad del grafo, E los lados y N los nodos.

Ø Pruebas de Malicia: la prueba de malicia consiste en ejecutar casos que no estén contemplados en el diseño. Los datos son valiosos para el desarrollo de software.

AUTÓMATA DE ESTADOS


Los Autómata de Estados reducen significativamente los nodos de un diagrama dinámico, simplificando la lectura y entendimiento del diseño, así se podrá facilitar la detención de los puntos débiles del programa. Los pasos para convertir un diagrama dinámico en un Autómata de Estados son los siguientes:


1) Expandir recursivamente autómatas anidados.

2) Explicitar transiciones implícitas.

3) Eliminar o absorber transiciones .

4) Crear estados iniciales y finales.

5) Se debe probarlas condiciones de los eventos condicionales.

6) Especificar intervalos.

DESARROLLO DE SISTEMAS


Estrategias de Pruebas del Software


Una prueba es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Una estrategia de prueba de software integra las técnicas de diseño de casos de prueba en un conjunto de pasos bien planeados que dan como resultado la correcta construcción del software. Proporciona una guía para los desarrolladores del software, para la organización de control d calidad y para el cliente.

Prueba de Unidad


La prueba de unidad centra el proceso de verificación en la menor unidad de diseño de software. Se prueba la interfaz del módulo para asegurar que la información fluya de forma adecuada, desde y hacia la unidad del programa que está siendo probada. Se analizan las estructuras de datos, se prueban las condiciones límite, se activan los caminos básicos de las estructuras de control y también se prueban todos los caminos de manejo de errores.


Antes de iniciar cualquier otra prueba, es preciso probar el flujo de los datos del módulo, ya que si los datos no entran correctamente, todas las demás pruebas no tienen sentido.
Prueba de integración


La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con el que dicta el diseño.
Tipos de integración


Ø Integración descendente: es una estrategia de integración incremental a la construcción de la estructura de programas, en el cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía comenzando por el control principal (Programa principal). Los módulos subordinados de control principal se incorporan en la estructura en la estructura, bien, de forma primero-en-profundidad, bien primero-en-anchura.


Ø Integración ascendente: es donde la construcción del diseño empieza desde los módulos más bajos hacia arriba (módulo principal), el procesamiento requerido de los módulos subordinados siempre esta disponible y elimina la necesidad de resguardo.


La sección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.
Prueba de validación y verificación


Al conjunto de actividades que aseguran que el software implementa correctamente una función específica se denomina verificación. La validación se refiere a un conjunto de actividades que aseguran que el software construido se ajusta a los requerimientos y necesidades del cliente.

La definición de verificación validación envuelve lo que se conoce como calidad del software. Las revisiones técnicas formales ayudan (inspección) ayudan a asegurar la calidad de los productos, a lo largo del proceso la medición y l control se aplica sobre cada elemento de una construcción del software. La prueba construye un elemento importante desde el que se puede evaluar la calidad y, de forma más practica, de cubrir los errores.

Una vez que se culmino la etapa de integración se puede decir que el software esta completamente ensamblado, se ha encontrado y corregido errores de la interfaces y se puede comenzar una serie final de prueba del software. La prueba de validación se logra cuando la expectativas razonable del cliente se cumplen en donde incluye la especificación de requisitos, documentos en donde se describen los atributos del software que son visibles para el usuarios, esta información forma la base del enfoque a la prueba de validación.

Cuando se construye el software para llevar a cabo de validación es casi imposible que el desarrollador pueda prever como un cliente usara realmente el programa es por ello se hace una serie de prueba de aceptación que puede permitir que un cliente valide todos los requisitos, se puede dar el caso de las pruebas alfa y beta.
Prueba del Sistema


Un clásico problema de la prueba del sistema es la delegación de culpabilidad. Esto ocurre cuando se descubre un error t cada uno de los creadores de cada elemento del sistema echa la culpa del problema a otros, para evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo siguiente:


Ø Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.

Ø Lleva a cabo una serie de pruebas que simulan la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.

Ø Registrar los resultados de las pruebas como “evidencias” en el caso de señalamientos informales.

Ø Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.


La prueba del sistema se basa en otras técnicas de pruebas, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema:


1) Prueba de Recuperación: es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.

2) Prueba de Seguridad: intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema negando así el servicio a otras personas a demás de producir errores a propósito en el sistema o debe curiosear los datos públicos intentando encontrar una clave de acceso al sistema.

3) Prueba de Resistencia: está diseñada para enfrentar a los problemas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar tirar el sistema. Para lograr esto se puede tomar en consideración lo siguiente:

Ø Diseñar pruebas especiales que generen 10 o mas interrupciones por segundo.

Ø Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar como responden las funciones de entrada.

Ø Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco.

Ø Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en el disco.
Prueba de Validación de Requerimientos


Luego de culminarlas pruebas de integración, se realiza la última etapa de pruebas, la cual evaluará el sistema final con miras a su presentación frente al cliente. En esta prueba se verificará si el programa cumple con las especificaciones formales establecidas por el cliente. El primer paso es evaluar el sistema colocándose en la posición del diente, verificando la funcionalidad y requisitos de rendimiento, luego se revisa cuidadosamente la configuración que consiste en ver que todos los elementos se han desarrollado apropiadamente y están suficientemente detallados para soportarlas fases de mantenimiento durante el ciclo de vida del software.


Para finalizar, se realizarán las pruebas alfa y beta, donde el usuario estará en contacto directo con el software. El la prueba alfa, el usuario (o usuarios) probaran el sistema con la presencia directa del programador, el cual anotará todos los problemas que haya tenido el cliente. En la prueba beta, el sistema es cedido al usuario para que lo use as su ámbito común, sin la presencia del programador, pasando por escrito los errores encontrados al sistema.
Depuración


La depuración es el proceso que resulta en la eliminación de un error, ya que intenta hacer corresponder el sistema con una causa, llevando así a la corrección del error. El proceso de depuración siempre tiene uno de los dos resultados:


Ø Se encuentra el error, se corrige y elimina.

Ø No se encuentra la causa del error: en este caso es cuando la persona encargada de la depuración debe sospechar la causa, en donde debe diseñar casos de prueba que ayuden a confirmar sus sospechas y el trabajo se regresa a la corrección del error de una forma interactiva.


La depuración tiene como objetivo principal encontrar y corregir la causa de un error en el software, existen 3 enfoques que se pueden proponer en la depuración los cuales son:


Ø Eliminación de causas: se manifiesta mediante inducción o deducción. Los datos relacionados con la ocurrencia del error se organizan para llegar a las posibles causas; se desarrolla una lista de las causas y se llevan a cabo las pruebas para eliminar cada una.

Ø Fuerza bruta: es la categoría probablemente la mas común y la menos eficiente en le momento de aislar la causa del error del software en donde se confía que en algún lugar de la gran cantidad de información producida nos puede llevar finalmente al éxito, lo mas frecuente es que se desperdicie tiempo y esfuerzo.

Ø Vuelta atrás: es el enfoque más normal para la depuración, que se puede usar con gran éxito en programas pequeños. Partiendo de donde se detecta el error hacia atrás en el código fuente hasta llegar al a posición del error.

Mantenimiento del Software
Etapas del Mantenimiento


El mantenimiento es mucho más que una corrección de errores. Se puede describir en tres actividades:


Ø Mantenimiento correctivo: esta actividad del mantenimiento es debido a que no es razonable que en la prueba de software se haya descubierto los errores de un gran sistema de software. Durante el uso de cualquier programa se encuentran errores y estos son informados al personal de desarrollo. Este proceso incluye el diagnóstico y corrección de uno o más errores.

Ø Mantenimiento adaptativo: es una actividad que modifica el software para que interaccione adecuadamente ante un cambio en su entorno (hardware nuevo, sistemas operativos avanzados, cambios monetarios, etc.).

Ø Mantenimiento perfectivo: La tercera actividad del mantenimiento se da cuando existe software que tiene un gran éxito. A medida que se utiliza el software algunos usuarios hacen observaciones sobre recomendaciones para nuevas posibilidades ó sobre modificaciones a las funciones ya existentes ó sobre mejoras en general. Para satisfacer estas peticiones se lleva a cabo el mantenimiento perfectivo siendo una actividad que genera un mayor esfuerzo empleado en el mantenimiento de software.
Características del Mantenimiento


La fase del mantenimiento abarca dos aspectos importantes:


Ø Mantenimiento no estructurado: es cuando sólo se dispone del código fuente. Se evalúa a menudo como complicado, debido a la pobre documentación interna, que causa una mala interpretación de características delicadas como estructuras de datos, interfaces, etc.

Ø Mantenimiento estructurado: Si existe una detallada información del software, se inicia el mantenimiento con la evaluación de la documentación del diseño, se determinan las características estructurales más importantes, el rendimiento y la interfaz de software.


El costo de mantenimiento genera algunas veces insatisfacción al cliente cuando la petición o modificación no se puede atender en un tiempo razonable.
Efectos Secundarios del Mantenimiento


La modificación al software en los códigos fuente es peligrosa. Algunas veces hemos escuchado “pero si todo lo que realicé fue cambiarle una sentencia”, lamentablemente cada vez que se introduce un cambio en un proceso lógico muy complejo, la posibilidad del error aumenta. FREEDMAN y WEINBERG definen tres grandes categorías de efectos secundarios del mantenimiento:


Ø Efectos secundarios sobre el código: con el hecho de realizar un sencillo cambio sobre una sola sentencia puede a veces tener resultados desastrosos. El cambio inadvertido de algún símbolo muchas veces pueden acarrear problemas trágicos.

Ø Efectos secundarios sobre las bases de datos: Durante el mantenimiento frecuentemente se hacen cambios sobre determinados elementos de una estructura de datos o sobre la propia estructura de datos. Los efectos secundarios sobre las bases de datos regularmente suceden por las modificaciones sobre la estructura de la información del software.

Ø Efectos secundarios sobre la documentación: los efectos secundarios en la documentación son debidos a que no se reflejan las modificaciones hechas en el código fuente sobre la documentación respectiva, no llevando a cabo un registro y/o actualización de los códigos fuente modificados.

Implantación
Conversión


La conversión consiste en el cambio del sistema anterior con el sistema nuevo así como los métodos para llevarla a cabo y verificación de que la conversión se haya efectuado correctamente

Existen cuatro métodos para efectuar una conversión en un sistema, en donde cada método tiene ventajas y desventajas entre los mismos:


Ø Sistemas paralelos: este método es un modelo seguro, ya que el sistema nuevo funciona al mismo tiempo que el sistema anterior; debido a que si encuentran fallas en al sistema nuevo, al anterior permanece en constante funcionamiento sin perdidas de tiempo, ni de información. Una desventaja muy notable as que este método de conversión es muy costoso ya que se duplican los recursos humanos.

Ø Conversión directa: el sistema anterior será reemplazado por el nuevo sistema, ya que la organización confía plenamente en el nuevo sistema. Obligando así a los usuarios a que hagan funcionar al nuevo sistema encontrando en él nuevos métodos y controles.

Ø Enfoque piloto: en este método se implanta el nuevo sistema en una parte de la organización. Con base a retroalimentación se hacen cambios y el sistema se instala en el resto de la organización mediante algunos otros métodos. La desventaja es que el nuevo sistema puede dar la impresión de que el nuevo sistema no es confiable, ni está libre de errores.

Ø Conversión por etapas: se implanta el nuevo sistema de manera gradual, reemplazando partes del sistema anterior, permitiendo a los primeros usuarios aprovechar las ventajas del nuevo sistema, así como la capacitación de los mismos, llevando a cabo la instalación de una nueva etapa una vez que fue aceptada sin hacer uso necesario de recursos extras.
Plan de Conversión


El plan de conversión incluye une lista de actividades para llevar a acabo la implantación del nuevo sistema y ponerlo en operación.

El plan de conversión debe prevenir los posibles problemas y la forma de enfrentarlos implementando planes de emergencia adecuados. Algunos problemas que se presentan comúnmente son:

Ø Documentos perdidos.

Ø Variación entre datos de los formatos nuevos y anteriores.

Ø Errores en la conversión de datos Extravío de datos o pérdida de archivos.

Ø Omisión en algunos pasos de la conversión.


Acondicionamiento De Las Instalaciones


El cliente o el ingeniero de sistemas presentará una lista de especificaciones para el cableado eléctrico y los contactos, necesidades de aire acondicionado, controles de humedad y exigencias de espacio, lo más recomendable es tener el local antes de la llegada del equipo.
Capacitación De Operadores Y Usuarios Para Operar El Sistema


Como consecuencia la calidad de capacitación recibida por el personal que manipulará el sistema ayuda u obstruye, y puede llegar a impedir, la implantación exitosa de un sistema de información. Tanto operadores como los usuarios del sistema requieren de capacitación.
Capacitación de operadores


La mayoría de los sistemas dependen del personal de Centro de Cómputo. La capacitación que el personal reciba debe de asegurar que puedan manejar todas las operaciones posibles, tanto rutinarias como extraordinarias. La capacitación que reciba el operador también debe contemplar al personal de capture de datos,

Como parte de la capacitación se le debe dar al personal una lista de formas de resolver los problemas y que identifique los posibles problemas y solución, así como datos personales de las personas a quién buscar cuando surjan problemas inesperados.
Capacitación de usuarios


La capacitación de usuarios incluye la identificación de problemas, determinando si el problema que surge es ocasionado por hardware o por software, o por algo realizado por los mismos usuarios que ocasione la falla del sistema,

No hay nada más desesperante que trabajar con un sistema y que suceda un problema y no ser capaz de determinar si es falla del propio sistema, del equipo o de los usuarios. El lugar para prevenir estos casos es durante la capacitación.

Las actividades de manipulación de los datos que recibe le mayor atención en le capacitación de usuarios son la captura de datos, la formulación de consultas y el borrados de los registros de datos. Le mayor parte de le capacitación de los usuarios tiene que ver con la operación del sistema en sí. La capacitación en la codificación de los datos marca la paute en el proceso de captures partir de las transacciones, o en la preparación de datos necesarios para las actividades de apoyo a les decisiones.
Métodos de capacitación


La capacitación a operadores y usuarios se puede manifestar de diferentes formas. Las actividades de capacitación se pueden llevar a cabo en las instalaciones de los proveedores, locales rentados. Los métodos y contenido de la capacitación varia de acuerdo e la fuente y del lugar de le capacitación
Instalación Y Pruebas Del Usuario Para Aceptación Del Sistema

En la instalación y prueba del usuario, son algunas actividades que realiza el usuario con el fin de verificar el sistema si funciona con el hardware diferente al hardware de desarrollo, tal como su instalación y funcionamiento en general, en esta etapa se abarcan cuatro aspectos importantes:

Ø La prueba de entrada: implica asegurarse que las formas electrónicas e impresas, junto con la estructuras de codificación cumple con las guías y especificaciones de diseño. También se prueba si el usuario final ingresa bien los datos.

Ø La prueba de salida: consiste en la generación de un reporte, su entrega al usuario y la determinación que satisface las necesidades de información.

Ø La prueba de la base de datos: son un conjunto de pruebas que aseguran que la base de datos contempla la satisfacción total de las demandas planteadas.

Ø La prueba de los controles: su propósito fundamental es asegurar que los mismos se encuentren en su lugar y trabajen según se planteó.

martes, 3 de junio de 2008

Conjugacion en Infinitivo Pretérito y Perfecto de Verbos en alemán fuertes e irregulares más importantes

scheiden = partir                         schied     hat/ist geschieden
scheinen = brillar, parecer         schien     hat geschienen
schreiben = escribir                    schrieb   hat geschrieben
schreien = gritar                         schrie      hat geschrie(e)n
schweigen = callar                      schwieg   hat geschwiegen
steigen = subir                            stieg         ist gestiegen
treiben = practicar, accionar    trieb         hat/ist getrieben
verzeihen = perdonar               verzieh     hat verziehen
weisen = mostrar                       wies          hat gewiesen

beißen = morder                       biß             hat gebissen
gleichen = igualarse                  glich          hat geglichen
gleiten = resbalar                      glitt           ist geglitten
greifen = tomar, coger              griff          hat gegriffen
kneifen = pellizcar                    kniff          hat gekniffen
leiden = sufrir                           litt             hat gelitten
pfeifen = silbar                          pfiff          hat gepfiffen
reißen = arrancar                     riß             hat gerissen
reiten = cabalgar                      ritt            hat/ist geritten
schleichen = deslizarse            schlich       ist geschlichen
schleifen = afilar                       schliff        hat geschliffen
schmeißen = tirar                    schmiß      hat geschmissen
schneiden = cortar                   schnitt      hat geschnitten
streichen = pintar, untar        strich         hat gestrichen
streiten = disputar                  stritt          hat gestritten
weichen = ceder                      wich           ist gewichen

bewerben (bewirbt) = solicitar             bewarb       hat beworben
brechen (bricht) = romper                    brach          hat/ist gebrochen
empfehlen (empfiehlt) = recomendar  empfahl     hat empfohlen
erschrecken (erschrickt)=asustar        erschrak    hat/ist erschrocken
gelten (gilt) = ser válido                         galt             hat gegolten
helfen (hilft) = ayudar                            half             hat geholfen
nehmen = tomar                                     nahm          hat genommen
sprechen (spricht) = hablar                  sprach         hat gesprochen
stechen (sticht) = pinchar                     stach           hat gestochen
stehlen (stiehlt) = robar                        stahl            hat gestohlen
sterben (stirbt) = morirse                    starb            ist gestorben
treffen (trifft) = encontrar                    traf              hat getroffen
werfen (wirft) = arrojar                        warf             hat geworfen

beginnen (beginnt) = comenzar           begann        hat begonnen
gewinnen (gewinnt) = ganar                 gewann       hat gewonnen
schwimmen (schwimmt) = nadar        schwamm   hat-ist geschwommen
spinnen (spinnt) = hilar                        spann           hat gesponnen

kommen = venir                                   kam              ist gekommen

fechten (ficht) = esgrimir                   focht              hat gefochten
flechten (flicht) = trenzar                   flocht             hat geflochten
heben (hebt) = elevar                         hob                hat gehoben
melken (melkt) = ordeñar                 molk              hat gemolken
quellen (quillt) = manar                     quoll               ist gequollen
schmelzen (schmilzt) = fundirse       schmolz         hat/ist geschmolzen
schwellen (schwillt) = hincharse      schwoll            ist geschwollen

essen (ißt) = comer                            aß                    hat gegessen
fressen (frißt) = comer, devorar     fraß                  hat gefressen
geben (gibt) = dar                              gab                  hat gegeben
geschehen (geschieht) = ocurrir      geschah          ist geschehen
lesen (liest) = leer                               las                  hat gelesen
messen (mißt) = medir                      maß               hat gemessen
sehen (sieht) = ver                              sah                hat gesehen
treten (tritt) = dar un paso, pisar      trat              hat/ist getreten
vergessen (vergißt) = olvidar             vergaß        hat vergessen

bitten (bittet) = pedir, rogar            bat                hat gebeten
liegen (liegt) = yacer, estar situado lag                 hat gelegen
sitzen (sitzt) = estar sentado            saß               hat gesessen

fahren (fährt) = viajar, conducir       fuhr             hat/ist gefahren
graben (gräbt) = cavar                       grub            hat gegraben
laden (lädt) = cargar                           lud               hat geladen
schaffen (schafft) = crear                   schuf           hat geschaffen
schlagen (schlägt) = pegar, golpear   schlug        hat geschlagen
tragen (trägt) = llevar                         trug           hat getragen
wachsen (wächst) = crecer                 wuchs        ist gewachsen
waschen (wäscht) = lavar                   wusch        hat gewaschen


blasen (bläst) = soplar                        blies            hat geblasen
braten (brät) = freír, asar                  briet           hat gebraten
fallen (fällt) = caer                               fiel              ist gefallen
fangen (fängt) = captar, coger            fing           hat gefangen
hängen (hängt) = colgar                     hing            hat gehangen
halten (hält) = parar(se), sostener    hielt           hat gehalten
lassen (läßt) = dejar                             ließ            hat gelassen
raten (rät) = aconsejar                         riet            hat geraten
schlafen (schläft) = dormir                   schlief       hat geschlafen

gehen (geht) = ir                                   ging             ist gegangen

heißen (heißt) = llamarse                     hieß             hat geheißen

laufen (läuft) = correr                          lief                 ist gelaufen

stoßen (stoßt) = empujar                    stieß              hat/ist gestoßen

brennen (brennt) = arder                  brannte           hat gebrannt
denken (denkt) = pensar                    dachte            hat gedacht
kennen (kennt) = conocer                  kannte           hat gekannt
nennen (nennt) = nombrar                nannte            hat genannt
rennen (rennt) = correr                       rannte          ist gerannt
senden (sendet) = enviar                    sandte            hat gesandt
stehen (steht) = estar (de pie)           stand             hat gestanden
wenden (wendet) = girar                    wandte          hat gewandt

bringen (bringt) = traer                      brachte          hat gebracht

erlöschen (erlischt) = apagarse           erlosch           ist erloschen
schwören (schwört) = jurar                 schwor           hat geschworen

betrügen (betrügt) = engañar             betrog            hat betrogen
lügen (lügt) = mentir                            log                   hat gelogen

dürfen (darf) = estar permitido          durfte             hat gedurft
müssen (muß) = estar obligado a         mußte           hat gemußt

können (kann) = poder                         konnte            hat gekonnt
mögen (mag) = gustar                          mochte           hat gemocht

rufen (ruft) = llamar                             rief                   hat gerufen

tun (tut) = hacer                                       tat                hat getan

werden (wird) = llegar a ser                   wurde          ist geworden

wissen (weiß) = saber                               wußte         hat gewußt