INTRODUCCION A LA INGENIERIA DE SOFTWAREBALOTARIO PARA EL EXAMEN FINAL 20122ING. JESSICA RIOS PADILLA

1. Definicin de: Modelo de Ciclo de Vida del Software.Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los requisitos hasta la finalizacin de su uso2. En qu consiste el Modelo en Cascada? fases, ventajas y desventajas.Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseo, lo cual significa que se harn los cambios necesarios en la codificacin y se tendrn que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto delas etapas.Faces: Ingeniera y Anlisis del SistemaAnlisis de los RequisitosDiseoCodificacinPruebaMantenimiento

Ventajas: Es un modelo sencillo y disciplinado Es fcil aprender a utilizarlo y comprender su funcionamiento Est dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa Ha sido muy usado y, por tanto, est ampliamente contrastado Ayuda a detectar errores en las primeras etapas a bajo costo Ayuda a minimizar los gastos de planificacin, pues se realiza sin problemas

Desventajas: Los proyectos raramente siguen el proceso lineal tal como se defina originalmente el ciclo de vida Es difcil que el cliente exponga explcitamente todos los requisitos al principio El cliente debe tener paciencia pues obtendr el producto al final del ciclo de vida No refleja exactamente cmo se programa realmente el sistema, en el que suele haber un gran componente iterativo Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones El producto final obtenido puede que no refleje todos los requisitos del usuario3. En qu consiste el Modelo en Incremental? fases, ventajas y desventajas.

Una forma de reducir los riesgos es construir solo una parte del sistema, reservando otros aspectos para niveles posteriores.El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema.MODELO DE DESARROLLO INCREMENTAL. En este modelo se desarrolla el sistema para satisfacer un subconjunto de requisitos especificados y en posteriores versiones se incrementa el sistema con nuevas funcionalidades que satisfagan ms requisitos. CARACTERISTICAS. Combina elementos del modelo de cascada con la filosofa interactiva de construccin de prototipos Cada secuencia lineal produce un producto operacional con cada incremento de la misma forma que progresa el tiempo en el calendario El primer incremento es a menudo el ncleo Como un resultado de evaluacin y/o utilizacin se desarrolla un plan para el incremento siguiente, este proceso se repite hasta llegar al producto completo Este modelo es particularmente til cuando la dotacin de personal no es suficiente para una implementacin completa Los primeros incrementos se pueden implementar con menos recursos Si es muy riesgoso desarrollar el sistema completo de una sola vez, entonces debera considerar este modelo VENTAJAS. Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada y utilizar el incremento previo. DESVENTAJAS. Se presupone que todos los requisitos se han definido al inicio. Se requiere de una experiencia importante para definir los incrementos de forma de distribuir en ellos las tareas en forma proporcional Si el sistema a desarrollar es de gran magnitud y se cuenta con un nico grupo para construirlo se corre el riesgo que el desarrollo se prolongue demasiado en tiempo4. En qu consiste el Modelo en Espiral? fases, ventajas y desventajas.

El modelo de la espiral es un modelo orientado a riesgo que divide el proyecto de software en mini proyectos. Cada proyecto se encargar de resolver uno o varios riesgos hasta que estn todos controlados. Una vez que estn los riesgos ms importantes controlados se finaliza igual que el ciclo de vida en cascada.En el ciclo de vida en espiral localizan los riesgos, genera un plan para manejarlos y se establece una aproximacin a la siguiente iteracin. Con cada iteracin se produce una aproximacin al producto final.En el modelo en espiral se comienza con una parte pequea del proyecto y se expande tras reducir los riesgos para la siguiente iteracin.En cada iteracin seguimos los siguientes pasos: Determinar objetivos, alternativas y lmites.Identificar y resolver riesgos.Evaluar las alternativas.Generar entregas de esta iteracin, y comprobar que son correctas.Planificar la siguiente iteracin.Si se decide ejecutar la siguiente iteracin, hay que establecer un enfoque para ella.En este modelo las primeras iteraciones son menos costosas y a medida que se avanza aumenta el costo.Las ventajas de este modelo son: Se disminuyen los riesgos.Al final de cada iteracin se obtienen los puntos de verificacin.Se obtienen con anterioridad indicaciones de cualquier riesgo insuperable.Las desventajas de este modelo son: Un aumento de costos.Es un modelo complicado de llevar a cabo porque exige una gestin concienzuda, atenta y unos conocimientos profundos.5. En qu consiste el Modelo en Prototipado? fases, ventajas y desventajas.

Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: anlisis, diseo, codificacin, prueba y mantenimiento.Ingeniera y anlisis del sistema. Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo todos los requerimientos o elementos del sistema y luego asignando algn subconjunto de estos requerimientos al software; esta versin del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como hardware, personas y bases de datos.La ingeniera y anlisis del sistema abarcan los requerimientos globales a un nivel de sistema con una pequea cantidad de anlisis y diseo a nivel superior. Adems de un anlisis costo beneficio del sistema es decir si toda la inversin que se har para el sistema conviene a los beneficios que traer el mismo.Anlisis de los requerimientos del software. El proceso de recoger los requerimientos se centra y se intensifica especialmente en esta etapa. Para comprender la naturaleza de los programas que hay que construir. El ingeniero de software debe comprender el dominio de la informacin del software, as como la funcin, rendimiento e interfaces requeridas. En esta etapa los requerimientos del sistema se documentan y se analizan con el cliente.

El diseo del software es realmente un proceso multipaso que se enfoca sobre 3 atributos del programa.* Estructura de datos* Arquitectura de software* Detalle procedimental

El diseo traduce los requerimientos en una representacin del software que pueda ser establecida de forma que obtenga la calidad requerida antes que comience la codificacin. Como los requerimientos y el diseo que se documentan forman parte de la configuracin del software.Codificacin. El diseo debe traducirse en una forma legible. El paso de la codificacin ejecuta la tarea de establecer la etapa de diseo legible para la mquina, si el diseo se ejecuta de una manera detallada la codificacin puede realizarse mecnicamente.Prueba. Una vez que se ha generado el cdigo, comienza la prueba del programa, la prueba se enfoca sobre la lgica interna del software asegurando que todas las sentencias se han probado y sobre las funciones externas estoy realizando pruebas para asegurar que la entrada definida producir los resultados que realmente se requieren.Mantenimiento. El software sufrir indudablemente cambios despus que se le entregue al cliente los cambios ocurrirn debido a que se han encontrado errores, causados por cambios del entorno externo por ejemplo un cambio solicitado debido al cambio del Sistema Operativo o dispositivos perifricos, o debido que el cliente requiere aumentos en las funciones del sistema. El mantenimiento del software se aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en lugar de uno nuevo.El ciclo de vida clsico es el ms viejo y ms ampliamente usado paradigma en la ingeniera de software. Sin embargo con el paso de unos cuantos aos se han producido criticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se presentan algunas veces cuando se aplica este paradigma se encuentran:1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre ocurre iteraciones y se crea problemas en la aplicacin del paradigma.2. Normalmente es difcil para el cliente establecer explcitamente el principio todos los requerimientos del sistema. El ciclo de vida clsico requiere esto y tiene dificultades para acomodar posibles incertidumbres que puedan existir al comienzo de dichos proyectos.3. El cliente debe tener paciencia. Una versin funcional del programa no est disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no detectado hasta que el programa est en funcionamiento puede ser desastroso.4. Los responsables del desarrollo se retrasan innecesariamente.

6. Criterios para seleccionar un Modelo de Ciclo de Vida del Software.

Disponibilidad de recursos ya sean econmicos, tiempo, equipos, humano, etc. Entender los requerimientos. Dominio del problema, si se tiene los conocimientos para dar solucin al problema central. Complejidad y magnitud del proyecto.

7. Definicin de: Estudio de Factibilidad.Determinar la factibilidad tcnica, econmica, operativa y jurdica (y de ser necesarias otras) del proyecto.8. En qu consiste la Factibilidad Tcnica, la Factibilidad Econmica y la Factibilidad Operacional?Factibilidad TcnicaEl anlisis de factibilidad tcnica evala si el equipo y software estn disponibles (o, en el caso del software, si puede desarrollarse) y si tienen las capacidades tcnicas requeridas por cada alternativa del diseo que se est considerando. Los estudios de factibilidad tcnica tambin consideran las interfases entre los sistemas actuales y nuevo. Por ejemplo, los componentes que tienen diferentes especificaciones de circuito no pueden interconectarse, y los programas de software no pueden pasar datos a otros programas si tienen diferentes formatos en los datos o sistemas de codificacin; tales componentes y programas no son compatibles tcnicamente. Sin embargo, puede hacerse una interfase entre los sistemas no compatibles mediante la emulacin, la cual son circuitos diseados para hacer que los componentes sean compatibles, o por medio de la simulacin, que es un programa de cmputo que establece compatibilidad, pero con frecuencia estas formas de factibilidad tcnica no estn disponibles o son demasiado costosas.Los estudios de factibilidad tcnica tambin consideran si la organizacin tiene el personal que posee la experiencia tcnica requerida para disear, implementar, operar y mantener el sistema propuesto. Si el personal no tiene esta experiencia, puede entrenrsele o pueden emplearse nuevos o consultores que la tengan. Sin embargo, una falta de experiencia tcnica dentro de la organizacin puede llevar al rechazo de una alternativa particular.

Factibilidad OperacionalEsta factibilidad comprende una determinacin de la probabilidad de que un nuevo sistema se use como se supone. Deberan considerarse cuatro aspectos de la factibilidad operacional por lo menos. Primero, un nuevo sistema puede ser demasiado complejo para los usuarios de la organizacin o los operadores del sistema. Si lo es, los usuarios pueden ignorar el sistema o bien usarlo en tal forma que cause errores o fallas en el sistema.Segundo, un sistema puede hacer que los usuarios se resistan a l como consecuencia de una tcnica de trabajo, miedo a ser desplazados, intereses en el sistema antiguo u otras razones. Para cada alternativa debe explorarse con cuidado la posibilidad de resistirse al cambio al nuevo sistema. Tercero, un nuevo sistema puede introducir cambios demasiado rpido para permitir al personal adaptarse a l y aceptarlo. Un cambio repentino que se ha anunciado, explicado y vendido a los usuarios con anterioridad puede crear resistencia. Sin importar qu tan atractivo pueda ser un sistema en su aspecto econmico si la factibilidad operacional indica que tal vez los usuarios no aceptarn el sistema o que uso resultar en muchos errores o en una baja en la moral, el sistema no debe implantarse.Una ltima consideracin es la probabilidad de la obsolescencia subsecuente en ele sistema. La tecnologa que ha sido anunciada pero que an no est disponible puede ser preferible a la tecnologa que se encuentra en una o ms de las alternativas que se estn comparando, o cambios anticipados en las practicas o polticas administrativas pueden hacerse que un nuevo sistema sea obsoleto muy pronto. En cualquier caso, la implantacin de la alternativa en consideracin se convierte en imprctica.Un resultado frecuente de hallazgos negativos acerca de la factibilidad operacional de un sistema es que ste no se elimina sino que se simplifica para mejorar su uso. Otras posibilidades son que los programas de relaciones pblicas o de entrenamiento estn diseados para enfocarse a sobreponerse a la resistencia a un nuevo sistema, o se desarrollan formas para hacer fases en el nuevo sistema en un largo periodo para que el cambio total, que traumatizara a los usuarios u operadores, se convierta en una serie de pequeos cambios.

Factibilidad EconmicaLos estudios de factibilidad econmica incluyen anlisis de costos y beneficios asociados con cada alternativa del proyecto. Con anlisis de costos/beneficio, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se hace una comparacin de ellos. Primero se comparan os costos esperados de cada alternativa con los beneficios esperados para asegurarse que los beneficios excedan a los costos. Despus la proporcin costo/beneficio de cada alternativa se compara con las proporcionan costo/beneficio de las otras alternativas para identificar la alternativa que sea ms atractiva e su aspecto econmico. Una tercera comparacin, por lo general implcita, se relaciona con las formas en que la organizacin podra gastar su dinero de modo que no fuera en un proyecto de sistemas.

Los costos de implementacin incluyen comnmente el costo remanente de la investigacin de sistemas (ara este propsito, los costos en los que ya se ha incurrido no son relevantes), los costos de hardware y software, los costos de operacin del sistema para su vida til esperada, y los costos de mano de obra, material, energa, reparaciones y mantenimiento. A travs del anlisis de costo/beneficio, la organizacin debe apoyarse en los conceptos tradicionales de anlisis financiero y las herramientas como teora del valor presente, anlisis de costos diferenciales y anlisis de flujos descontados.Algunos costos y beneficios pueden cuantificarse fcilmente. Los beneficios que pueden cuantificarse con facilidad son de dos tipos generales: Ahorros en costos, tales como una disminucin en costos de operacin y aumentos en las utilidades directas. Como un ejemplo de lo ltimo, un cliente podra haber contratado la suministracin de pedidos de una cantidad conocida si la organizacin implanta un sistema que informacin que proporcione al cliente informacin continua acerca del estado de la produccin en proceso de los embarques planeados de mercanca, de tal forma que a los clientes de dicho cliente pueda drseles estimaciones exactas de cundo estar disponible la mercanca.Un problema importante con el anlisis de costos/beneficio es la atencin inadecuada de costos y beneficios intangibles. stos son aspectos de las alternativas de los nuevos sistemas que s afectan los costos y utilidades y deberan evaluarse pero que los afectan en formas que no pueden cuantificarse fcilmente. Los factores intangibles con frecuencia estn relacionados a la calidad de la informacin proporcionada por el sistema y a veces a formas sutiles en que esta informacin afecta a la empresa, tal como alternando las actitudes para que la informacin sea vista como un recurso.

Con frecuencia los diseadores de sistemas no estn a gusto basando sus recomendaciones en intangibles "vagos" que deben estimarse en forma contraria a lo que se llama "hechos Duros" de costos y beneficios fcilmente cuantificables; prefieren justificar sus recomendaciones con datos determinados objetivamente. Cuando se da mayor importancia a los costos y beneficios cuantificables que a los costos y beneficios intangibles, quiz haya una desviacin contra el nuevo sistema por que la mayora de los costos pueden cuantificarse de manera fcil, mientras muchos de los beneficios ms importantes pueden ser intangibles y por lo tanto no se consideran correctamente.Dos beneficios intangibles son el servicio a clientes y mejor informacin administrativa. Por ejemplo, los clientes pueden recibir informacin puntual y exacta acerca de los envos, estados y otros informes ms exactos, y nuevos servicios. Los cajeros electrnicos en los bancos que permiten a los clientes realizar operaciones 24 horas al da y que pueden resultar en un mayor nmero de clientes y utilidades para el banco, son un ejemplo de un servicio al cliente. Adems, un nuevo sistema puede proporcionar una mejor imagen de la organizacin a sus clientes, vendedores, y empleados, que ayuda a atraer ms clientes a que ayuda a retener a los empleados.Los beneficios intangibles importantes pueden ser adquiridos de un nuevo sistema de informacin. Es cierto que el principal mpetu al desarrollar un nuevo sistema puede ser la expectativa de informacin ms exacta y a tiempo, un mejor formato de los informes, o informes que estn ms enfocados a reas particulares de problemas. Por ejemplo, los informes pueden recibirse ms pronto despus del cierre del periodo, o el nuevo sistema puede hacer que la informacin est disponible con base en preguntas durante todo el tiempo. Adems en muchos casos el nuevo sistema proporciona informacin que antes no estaba disponible, como informacin de los costos estndares o incrementos en los costos.Tambin pude haber menos beneficios intangibles obvios. Un nuevo sistema puede proporcionar mejor control sobre las operaciones de la organizacin, o puede ser que la auditora sea ms rpida o a un costo menor. Un beneficio intangible final es que la experiencia obtenida de la investigacin de sistemas y del uso de un sistema de informacin ms avanzado a menudo coloca a la organizacin en una mejor posicin para tomar ventajas de desarrollos futuros en tecnologa de computacin y sistemas de informacin. Por ejemplo, es posible que la experiencia obtenida del desarrollo de una base de datos de personal tenga mucho valor si la organizacin decide implantar una base de datos financiera; no slo estar afectando positivamente l diseo de la base de datos financiera, sino que tambin existir una reduccin en los costos de su desarrollo, que es un ahorro en costos hacia el siguiente proyecto de sistemas que debera considerarse como un beneficio proporcional por el proyecto actual.La mayora de los costos y beneficios intangibles de una alternativa afectan en forma indirecta las utilidades, pero esto es difcil de medir. La siguiente es una forma de cuantificar los costos y beneficios intangibles:1. Identificar las causas y efectos directos. Por ejemplo, el efecto directo de computarizar tareas repetitivas puede ser que un nuevo sistema mejore los trabajos actuales y mejore la moral.2. Identificar los efectos indirectos. Por ejemplo, una mejor moral puede resultar en cerca de 5% menos ausentismo y un 10% menos en el ndice de rotacin de empleados.3. Estimar el impacto econmico de los efectos indirectos para la vida estimada del sistema. Por ejemplo, una reduccin en los retrasos de la programacin y horas extras debidas a la reduccin del ausentismo puede ahorrar casi $2,000 al ao, y una reduccin en los costos de entrenamiento debidos a una reduccin en la rotacin de los empleados puede ahorrar hasta $3,000 al ao. El beneficio total (ahorro en costos) debido a una mejora en los empleos sera entonces $5,000 al ao o de $20,000 para una vida estimada de 4 aos del sistema.Esta forma puede usarse para una gran variedad de costos y beneficios intangibles. Aunque arbitraria y subjetiva, es preferible a ignorar los intangibles. Esta forma puede describirse como hacer tangibles los intangibles.Una forma alternativa es dejar sin cuantificar a los intangibles. Despus, los usuarios y diseadores de sistemas los estudian y llegan a un acuerdo acerca de la importancia relativa de lo cuantificado y de los costos y beneficios intangibles. Sin embargo, con frecuencia los costos y beneficios intangibles no se analizan completamente, y no se hace ningn intento para llegar a un acuerdo acerca de su importancia.

9. Definicin de: Anlisis de Requisitos.

Definicin: el anlisis de requisitos es el proceso de estudio de las necesidades de los usuarios para llegar a una definicin de los requisitos del sistema, de hardware o de software; as como su estudio y refinamiento. Requisito : es una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo. Aplicado a los sistemas es los que debe cumplir o poseer un sistema para satisfacer un contrato, una norma o una especificacin10. En qu se centra la fase de captura de requerimiento y anlisis de un desarrollo?

11. Definicin de Requerimiento.Un Requerimiento es una caracterstica del sistema o una descripcin de algo que el sistema es capaz de hacer con el objeto de satisfacer el propsito del sistema12. Definicin de: Especificacin de Requerimiento.LaEspecificacin de Requisitos Software(ERS) es una descripcin completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto decasos de usoque describe todas las interacciones que tendrn los usuarios con el software. Los casos de uso tambin son conocidos comorequisitos funcionales. Adems de los casos de uso, la ERS tambin contienerequisitos no funcionales(o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseo o la implementacin (Como por ejemplo restricciones en el diseo o estndares de calidad).

13. Aspectos claves en una Lista de Requerimientos (captura y anlisis de requerimientos).

14. Definicin de: Analista. Habilidades con las que debe contar un Analista.

15. Definicin de: Requerimiento Funcional. Ejemplos.Unrequisitofuncionaldefine el comportamiento interno delsoftware: clculos, detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran cmo loscasos de usosern llevados a la prctica. Son complementados por losrequisitos no funcionales, que se enfocan en cambio en el diseo o la implementacin.Como se define en laingeniera de requisitos, los requisitos funcionales establecen los comportamientos del sistema.Tpicamente, un analista de requisitos genera requisitos funcionales luego de diagramar loscasos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseo de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.Un requisito funcional tpico contiene un nombre y un nmero de serie nico y un resumen. Esta informacin se utiliza para ayudar al lector a entender por qu el requisito es necesario, y para seguir al mismo durante el desarrollo del producto.El ncleo del requisito es la descripcin del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interaccin con usuarios, inversores y otros expertos en la organizacin.16. Definicin de: Requerimiento No Funcional. Ejemplos.Unrequisito no funcionaloatributo de calidades, en laingeniera de sistemasy laingeniera de software, unrequisitoque especifica criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a losrequisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen informacin a guardar, ni funciones a realizar.Algunos ejemplos de requisitos no funcionales tpicos son los siguientes:RendimientoDisponibilidadSeguridadAccesibilidadUsabilidadEstabilidadPortabilidadCostoOperatividadInteroperabilidadEscalabilidadConcurrenciaMantenibilidadInterfaz

17. Definicin de: Requerimiento Inverso. Ejemplos.El objetivo de laingeniera inversaes obtener informacin o un diseo a partir de un producto accesible al pblico, con el fin de determinar de qu est hecho, qu lo hace funcionar y cmo fue fabricado.Hoy en da (principios del siglo XXI), los productos ms comnmente sometidos a ingeniera inversa son losprogramas de computadorasy loscomponentes electrnicos, pero, en realidad, cualquier producto puede ser objeto de un anlisis de Ingeniera Inversa.El mtodo se denomina as porque avanza en direccin opuesta a las tareas habituales deingeniera, que consisten en utilizar datos tcnicos para elaborar un producto determinado. En general, si el producto u otro material que fue sometido a la ingeniera inversa fue obtenido en forma apropiada, entonces el proceso es legtimo y legal. De la misma forma, pueden fabricarse y distribuirse, legalmente, los productos genricos creados a partir de la informacin obtenida de la ingeniera inversa, como es el caso de algunos proyectos deSoftware libreampliamente conocidos.Elprograma Sambaes un claro ejemplo de ingeniera inversa, dado que permite asistemas operativosUNIXcompartirarchivoscon sistemasMicrosoft Windows. El proyecto Samba tuvo que investigar informacin confidencial (no liberada al pblico en general por Microsoft) sobre los aspectos tcnicos relacionados con elsistema de archivosWindows. Lo mismo realiza el proyectoWINEpara el conjunto deAPI de WindowsyOpenOffice.orgcon los formatos propios deMicrosoft Office, o se hace para entender la estructura del sistema de archivosNTFSy as poder desarrollardriverspara la lectura-escritura sobre el mismo (principalmente para sistemas basados enGNU/Linux).La ingeniera inversa es un mtodo de resolucin. Aplicar ingeniera inversa a algo supone profundizar en el estudio de su funcionamiento, hasta el punto de que podamos llegar a entender, modificar y mejorar dicho modo de funcionamiento.Pero este trmino no slo se aplica al software, sino que tambin se considera ingeniera inversa el estudio de todo tipo de elementos (por ejemplo, equipos electrnicos, microcontroladores, u objeto fabril de cualquier clase). Diramos, ms bien, que la ingeniera inversa antecede al nacimiento del software, tratndose de una posibilidad a disposicin de las empresas para la produccin de bienes mediante copiado1desde el mismo surgimiento de la ingeniera.En el caso concreto delsoftware, se conoce por ingeniera inversa a la actividad que se ocupa de descubrir cmo funciona un programa, funcin o caracterstica de cuyo cdigo fuente no se dispone, hasta el punto de poder modificar ese cdigo o generar cdigo propio que cumpla las mismas funciones. La gran mayora delsoftware de pagoincluye en su licencia una prohibicin expresa de aplicar ingeniera inversa a su cdigo, con el intento de evitar que se pueda modificar su cdigo y que as los usuarios tengan que pagar si quieren usarlo.La ingeniera inversa nace en el transcurso de laSegunda Guerra Mundial, cuando los ejrcitos enemigos incautaban insumos de guerra como aviones u otra maquinaria de guerra para mejorar las suyas mediante un exhaustivoanlisis.La siguiente figura muestra los procesos que sigue la ingeniera directa, si seguimos ese camino hacia "atrs" (o de manera inversa), hacemos ingeniera inversa, si continuamos con el camino y planteamos cambios (o mejoras), por la derecha, ese camino nos lleva a una reingeniera, si no alteramos el contenido de los modelos obtenidos durante los procesos de la ingeniera inversa y seguimos el camino de la izquierda, eso se llama desarrollar una copia.18. Definicin de: CUS, CUN. Ejemplos.

19. Definicin de: Diagrama de Actividades, Diagrama de Secuencia, Diagrama de Colaboracin, Diagrama de Estados, Diagrama de Clases.

Un diagrama de actividad es un caso especial de un diagrama de estados (otro diagrama de UML, que discutiremos ms adelante en la materia) en donde todos -o al menos la mayora- de los estados son estados de acciones y en donde todas -o al menos la mayora- de las transiciones son disparadas por la finalizacin de las acciones que las alimentan. Un diagrama de actividad est asociado a la implementacin de un caso de uso. El propsito de este diagrama es enfocarse en los flujos manejados por el procesamiento interno (en contraposicin con eventos externos). Se debe usar diagrama de actividad en situaciones donde todos o la mayora de los eventos representan la finalizacin de acciones generadas internamente (esto es, flujo de control procedural). Este tipo de diagrama no es adecuado en situaciones donde ocurren eventos asincrnicos.Teniendo en cuenta que los casos de uso se centran en la interaccin entre el actor y el sistema, y no en el procesamiento interno del sistema durante el caso de uso, aparece la necesidad de utilizar este diagrama para evitar que la documentacin de las actividades que realiza el sistema no est limitada al texto informal de los casos de uso. De esta forma, un caso de uso puede estar acompaado por cero, uno o ms diagramas de actividad.Si resulta necesario, se pueden construir diagramas de actividad jerrquicos, donde una actividad de un diagrama sea descompuesta en actividades menores en un diagrama de nivel inferior.

20. Definicin de: Diseo de Software.La finalidad del Diseo es tener una idea, al menos visual, y genrica de todo el sistema. Un buen anlisis de requisitos, restricciomes, y otros factores que uno considere oportuno considerar puede llevar a un diseo bastante maduro y aproximado de como concebir al software.

21. En qu consiste el Diseo de Datos?

22. Definicin de: Entidad, Atributo, Llave Primaria, Relacin, Cardinalidad, ejemplos.Concepto de base de datosDefiniciones Conjunto de datos homogneos, ordenados de una forma determinada, que se presenta normalmente en forma legible por ordenador (en cinta magntica u otro soporte) y se refieren a una organizacin, materia, o problema determinado" (FID) Sistema formado por un conjunto de datos y un paquete de software para la gestin del mismo, de tal modo que:se controla el almacenamiento de datos redundanteslos datos resultan independientes de los programas que los usanse almacenan las relaciones entre los datos junto con stosse puede acceder a los datos de diversas formas En la actualidad las bases de datos pueden definirse como: Coleccin de datos y/o documentos digitales, que pueden ser homogneos o no, que disponen de sistemas de gestin de bases de datos (relacionales o documentales) y un conjunto de aplicaciones que hacen posible su publicacin, integracin y consulta dentro o fuera de Internet.Bases de datos estructuradas y no estructuradasBases de datos clsicas: formadas por registros, estructurados en campos, y gestionadas por un Sistema de Gestin de Bases de Datos (SGBD) Pueden (opcional) estar integradas en Internet. Pueden ser consultadas a travs de un sitio Web.Bases de datos formadas por archivos o documentos, no estructurados, y no gestionadas por un Sistema de Gestin de Base de Datos. Constituyen una coleccin de documentos a los que se les incorpora un Sistema de Recuperacin de Informacin (SRI)Bases de datos estructuradasBases de datos clsicas formadas por registros, estructuradas en campos y gestionadas por un SGBDBases de datos relacionales (SGBDR): bases de datos de contabilidad, nminas, productos, bases de datos de empresasBases de datos documentales (SGBDD o SRI): bases de datos de informes, de artculos de revistas, de prensa, de tesis doctorales, de bibliografa, opacs, etc.Estructura general de una B.D.Registro y campoRegistro:Conjunto de campos relacionados entre s que contiene datos referidos a un mismo ente u objeto.Tiposde registros: Registros de longitud fija: todos los campos que lo forman son de longitud fija. Registros de longitud variable: uno o varios de los campos que lo integran tiene longitud variable aunque tiene una dimensin mxima que no se sobrepasar. Registros de longitud indefinida: la longitud es imposible de determinar. Incluye marcas de final de campo y de fin de registro.Campo:Lugar fsico de almacenamiento destinado a contener informacin independiente.El tipo de campo determina la clase de datos que pueden introducirse y las clases de operacionesTipos de campos: Alfabticos: letras del alfabeto (A-Z) Numricos: n del sistema decimal (0-9) Alfanumricos: letras y nmerosControl: se utilizan para el gobierno de las unidades a las cuales van destinadasCampos segn funcin en el registro: Literales Numricos Claves Indicadores Cdigos PunterosFileMaker:FileMaker Pro usa el tipo del campo para interpretar los datos cuando se ordenan registros y se efectan clculos:TextoLetras, smbolos y nmerosNmeroNmeros, letras o smbolosFechaSlo fechasHoraSlo horasTipos de campos en FileMaker: Contenedor: Imagen, pelcula, sonido Clculo: El resultado de una frmula de clculo. Sumario: Calcula valores como subtotales, promedios y totales generales de varios registros. Global: Debe utilizarse un solo valor en todos los registros del archivo.Entidad, atributo, relacin Entidad y atributoEntidad: En una B.D se almacena informacin de una serie de objetos o elementos. Estos objetos reciben el nombre de entidad. En el ejemplo de la Librera, libros, clientes y proveedores son entidadesAtributo: De cada entidad se almacenan una serie de datos que se denominan atributos de la entidad. Pueden ser atributos de una entidad cualquier caracterstica o propiedad de sta. Son atributos de la entidad libros: Autor, Ttulo, rea de Edicin, ISBNRelaciones:En una B.D se almacenan adems de las entidades, las relaciones existentes entre ellas. En el ejemplo de la Librera hay relaciones entre: las entidades libros/clientes y las entidades libros/proveedores.Tipo de relaciones:SimplesBiunvocas: de Uno a Uno (1 a 1)ComplejasDe Uno a Muchos (1 a N)De Muchos a Muchos (N a N)

23. En qu consiste el Diseo Estructural?

24. En qu consiste el Diseo Procedimental?

25. Criterios para juzgar la capacidad del mtodo de diseo de conseguir la modularidad y los relaciona con el DOO.

26. Definicin de: Diagrama de Componentes, Diagrama de Despliegue.

27. Principios Bsicos para el Diseo de Interfaces Graficas de Usuario.

28. Evaluacin del Diseo de Interfaz Grafica de Usuario, fases.

29. Caractersticas de una Interfaz.

30. Definicin de: Pruebas de Software.

31. Definicin de: Calidad de Software.

32. Definicin de: Prueba al Azar y Prueba Manual.

33. Principios Bsicos que guan las Pruebas del Software.

34. Definicin de: Prueba de Caja Negra, Prueba de Caja Blanca, que tipo de errores encuentran cada una de estas pruebas.

35. Definicin de: Prueba de Integracin, Prueba de Regresin, Prueba de Recuperacin y Prueba de Seguridad.

36. Definicin de: Prueba Alfa y Prueba Beta.

37. Definicin de: Configuracin de Software.

38. Definicin de: La Ingeniera Reverse.

39. Definicin de: Documentacin de Software.

40. Definicin de: Mantenimiento de Software.

41. Definicin de las cuatro categoras de Mantenimiento de Software: Mantenimiento Correctivo, Mantenimiento Adaptativo, Mantenimiento Perfectivo y Mantenimiento Preventivo.

42. Definicin de las fases por las que un producto liberado atraviesa: Fase de Realce, Fase de Madurez, Fase de Obsolescencia y Fase de Terminacin.

43. Elementos de entrada y salidas en cada una de las fases en el ciclo de desarrollo del software.