REPBLICA BOLIVARIANA DE VENEZUELAALDEA UNIVERSITARIAREPUBLICA ARGENTINACUMAN-EDO-SUCRE

Ingeniera Del Software

Integrantes:Mrquez FannyAndrades Gnesis

Cuman, Junio de 2015INTRODUCCINLaIngeniera del Softwarees la rama de la ingeniera que crea y mantiene las aplicaciones de software usando tecnologas y prcticas de las ciencias de la computacin, manejo de proyectos, ingeniera, el mbito de la aplicacin, y otros campos. Hay quienes opinan que este proceso debera de llamarse "Desarrollo del Software" frente a Ingeniera del Software. "software es la suma total de los programas de ordenador, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo" y "un producto de software es un producto diseado para un usuario".Su origen se debi a que el entorno de desarrollo de sistemas software adoleca de: Retrasos considerables en la planificacin Poca productividad Elevadas cargas de mantenimiento Demandas cada vez ms desfasadas frente a las ofertas Baja calidad y fiabilidad del producto Dependencia de los realizadores

EL SOFTWAREEstos son los programas informticos que hacen posible la realizacin de tareas especficas dentro de un computador. Por ejemplo Word, Excel, PowerPoint, los navegadores web, los juegos, los sistemas operativos, etc.Se considera que el software es elequipamiento lgico e intangiblede un ordenador. En otras palabras, el concepto de software abarca a todas lasaplicaciones informticas, como los procesadores de textos, las planillas de clculo y los editores de imgenes.

El software es desarrollado mediante distintoslenguajes de programacin, que permiten controlar el comportamiento de una mquina. Estos lenguajes consisten en un conjunto de smbolos y reglas sintcticas y semnticas, que definen el significado de sus elementos y expresiones. Un lenguaje de programacin permite a los programadores del software especificar, en forma precisa, sobre qu datos debe operar una computadora.

CUALIDADES DEL SOFTWARELascualidadesdel software son: Robustez,correccin, eficiencia, amabilidad,extensibilidad,claridad,flexibilidad,mantenibilidad,consistencia,simplicidad,completud, escalabilidad, encapsulamiento,abstraccin, generosidad, reusabilidad, seguridad, utilidad.

Un software esrobustocuando funcionaen forma razonable an en situaciones no anticipadas. Un software escorrectosi se comporta de acuerdo a su especificacin El software se comporta de acuerdo con lo esperado por el usuario. Un software eseficientesi usa sus recursos en forma econmica. Un software esamigablesi sus usuarios lo encuentran fcil de utilizar. Un software esextensiblecuando pueden incorporarse nuevas caractersticas al mismo sin mayor impacto sobre las caractersticas actuales. Un software esflexiblecuando tiene la capacidadpara reflejar cambios percibidos en el dominio de una manera simple y sencilla. Un softwarees msmanteniblecuanto menor esfuerzo requiere para que el sistema siga funcionando en condiciones distintas a las originales e incluso en las originales. Un softwareesconsistentecuandosistema se comportar siempre de la misma manera ante un mismo evento y las tareas similares deben poder realizarse siguiendo pasos similares. Un softwareessimplecuando tanto como en la interfaz como en la implementacin es simple. Es ms importante la simplicidad en la interfaz que en la implementacin. Un softwareescompletocuandocuando contempla todas las posibles situaciones a darse en la prctica. Un software practica elencapsulamientopara poder agruparunidades funcionales me permite que el sistema sea cohesivo, reduciendo la complejidad del sistema y aumentando en cierta forma su flexibilidad. Un softwarees conescalabilidadda facilidad de un sistema pensando originalmente en una cargadeterminada. Puede ser adaptado para soportar una carga mayor.

FACTORES DE CALIDAD DEL SOFTWARELa calidad del software. La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta de calidad.Existen algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que tambin pueden implicar una falta de calidad.La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico.El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software.El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software.El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado.La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin.A partir del siguiente grfico se observa la interrelacin existente entre la Gestin de la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad.

Los factores que determinan la calidad del software se clasifican en tres grupos: Operaciones del producto: caractersticas operativas Correccin:Grado en que un programa satisface sus especificacin y logra los objetivos marcados por el usuario. (Hace lo que se le pide?). Fiabilidad:Grado en que se puede esperar que un programa lleve a cabo las funciones esperadas con la precisin requerida. (Lo hace de forma fiable todo eltiempo?). Eficiencia:Cantidad de recursos decomputadorasy de cdigo requeridos por el programa para realizar sus funciones con los tiempos de respuesta adecuados. (Qu recursoshardwarey software necesito?). Integridad:Grado en que puede controlarse el acceso al software o a los datos por usuarios no autorizados. (Puedo controlar su uso?). Facilidad de uso:Esfuerzo necesario para aprender, utilizar, preparar las entradas e interpretar las salidas de un programa. (Es fcil y cmodo de manejar?). Revisin del producto: capacidad para soportar cambios. Facilidad de mantenimiento:Esfuerzo requerido para localizar y arreglar un error en un programa. (Puedo localizar los fallos?). Flexibilidad:Esfuerzo requerido para modificar un programa. (Puedo aadir nuevas opciones?). Facilidad de prueba:Esfuerzo requerido para probar un programa de forma que se asegure que realiza la funcin requerida. (Puedo probar todas las opciones?). Transicin del producto: adaptabilidad a nuevos entornos. Portabilidad:Esfuerzo requerido para transferir un programa desde un entorno HW y/o SW a otro. (Podr usarlo en otra mquina?). Reusabilidad:Grado en que un programa o componente SW se puede reutilizar en otras aplicaciones. (Podr utilizar alguna parte del software en otra aplicacin?). Interoperatividad:Esfuerzo requerido para acoplar un sistema con otras aplicaciones o sistemas. (Podr comunicarse con otras aplicaciones o sistemas informticos?).

INGENIERA DEL SOFTWAREEs la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software,y el estudio de estos enfoques, es decir, la aplicacin de la ingeniera al software.Integra matemticas, ciencias de la computacin y prcticas cuyos orgenes se encuentran en la ingeniera.

VISIN GENERAL DEL PROCESO DEL DESARROLLO DEL SOFTWAREEs proceso es afectado por la creatividad y juicio de las personas involucradas. En el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente.

Es actividades requeridas para desarrollar un sistema de software de alta calidad y proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Actividades: Diseo, validacin, evolucin, especificacin.

EL PAPEL DEL USUARIO DENTRO DEL PROCESO DE DESARROLLO DE SOFTWARETodos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de desarrollo de software, mayores sern las probabilidades de xito que tenga el mismo.

No obstante es importante hacer algunas matizaciones:

1)El proyecto no se hace slo, porque incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue interpretar con precisin lo que quieren y no se dinamiza un feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarn las posibilidades de que algn requisito funcional no se haya recogido adecuadamente o de que se haya realizado un software con una usabilidad incmoda para los usuarios.

Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, adems de crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que desempean tanto el jefe de proyectos, como el equipo de analistas funcionales y analistas programadores.

2)Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan a estar implicados en el futuro uso del sistema de informacin, es decir, no es suficiente que el equipo de usuarios est formado por idelogos o tericos que se nutrirn del resultado del trabajo de la herramienta, sino que es fundamental que participen usuarios que despus se tengan que poner el mono de trabajo y vayan a trabajar con el software. Es importante conseguir la combinacin de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no participen usuarios directores, ya que pueden existir conflictos entre usuarios que stos deben solucionar y tambin es recomendable que el software no slo se disee para el corto plazo, sino que sirva para tareas de gestin, planificacin, etc y esta visin la proporcionan principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad, como es lgico explicando los riesgos de que no se aplique esta estrategia.

3)Los analistas estn para ayudar y para colaborar con los usuarios en la especificacin y diseo de la solucin, pero no estn para dar lecciones a los usuarios y ensearle cmo deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la ms ortodoxa, siempre tendr una justificacin que slo se entendera si realmente estuviramos haciendo su trabajo durante un tiempo y viramos los problemas con los que se enfrentan cotidianamente. La clave por tanto est en la colaboracin y en el dilogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetn de cmo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en consenso con los usuarios que los cambios sean tranquilos.

4)Es fundamental documentar el proyecto, en primer lugar con la documentacin que se especifique en las normativas de desarrollo de la organizacin para la que se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la documentacin que establezcan las normativas internas de calidad de tu organizacin (no requerir un sobreesfuerzo, ya que en la mayor parte de los casos coincidir) y a todo lo anterior sumarle toda la documentacin de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qu entender de modelos de datos, de diagramas de casos de uso, etc, es ms, es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad tcnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentacin, por tanto, no tiene por qu tener los formalismos de la tcnica y tiene como objetivo que el usuario capte lo que el analista est interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso, interfaces, etc Es muy importante trabajar todo esto, ya que comenzar demasiado pronto con la construccin, es algo muy arriesgado, ya que los costes de modificar algo en las distintas fases de la construccin pueden ser muy importantes y provocar que se tengan que reconstruir varias veces distintas funcionalidades de la aplicacin.

RESPONSABILIDAD PROFESIONAL Y TICA

La ingeniera del software se lleva a cabo dentro de un marco legal y social que limita la libertad de los ingenieros. Los ISW deben aceptar que su trabajo comprende responsabilidades ms amplias que simplemente la aplicacin de habilidades tcnicas. Deben comportarse de una forma tica y moral responsable, no basta con poseer estndares normales de honestidad e integridad. No debera utilizar su capacidad y sus habilidades para comportarse de forma deshonesta o de forma que deshonre la profesin de la ingeniera del software.

Existen reas donde los estndares de comportamiento aceptable no estn acotados por las leyes, sino por la responsabilidad profesional, algunas de estas son:

Confidencialidad.Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad. Competencia.No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que estn fuera de su capacidad. Derechos de propiedad intelectual.Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como las patentes el copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes est protegida.Uso inapropiado de las computadoras. No debe emplear sus habilidades tcnicas para utilizar de forma inapropiada las computadoras de otras personas. Desde los relativamente triviales (utilizar juegos en las mquina de un empleado, por ejemplo) hasta los extremadamente serios (difusin de virus).

Cdigo de tica (ACM/IEEE)

Los ingenieros de software debern comprometerse consigo mismo en convertir el anlisis, especificacin, diseo, desarrollo, prueba y mantenimiento de software en una profesin respetable y beneficiosa. De acuerdo con su compromiso con la salud, seguridad y bienestar del pblico, los ingenieros de software debern apegarse a ocho principios.

PRINCIPIOS DEL CDIGO

Pblico:Los ingenieros de software debern actuar consistentemente con el inters pblico.Cliente y Empleador:Los ingenieros de software debern actuar de una forma determinada que est en los mejores intereses de su cliente y empleador consistente con el inters pblico.Producto:Los ingenieros de software debern asegurar que sus productos y modificaciones relacionadas logren el ms alto estndar profesional posible.Juicio:Los ingenieros de software debern mantener integridad e independencia al emitir su juicio profesional.Gerencia:Los gerentes y lderes de ingeniera de software debern suscribirse y promocionar un enfoque tico para la gerencia de desarrollo y mantenimiento del software.Profesin:Los ingenieros de software debern fomentar la integridad y reputacin de la profesin consistente con el inters pblico.Colegas:Los ingenieros de software debern ser justos y comprensivos con sus colegas.Inters Propio:Los ingenieros de software debern participar en el aprendizaje de por vida del ejercicio de su profesin y debern promover un enfoque tico para el ejercicio de la misma.

CICLO DE VIDA DEL SOFTWARE

Al igual que en otros sistemas de ingeniera, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en funcin de cuales sean las caractersticas del proyecto, se configurar el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificacin y anlisis de requisitos, diseo del sistema, implementacin del software, aplicacin y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentacin de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estar influida por la fase del desarrollo en curso, se explicar de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vida son:

Anlisis:Construye un modelo de los requisitosDiseo:A partir del modelo de anlisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.Codificacin:Construye el sistema. La salida de esta fase es cdigo ejecutable.Pruebas:Se comprueba que se cumplen criterios de correccin y calidad.Validacin:es el proceso de comprobar que lo que se ha especificado es lo que elusuariorealmente quera.Mantenimiento:En esta fase, que tiene lugar despus de la entrega se asegura que el sistema siga funcionando y adaptndose a nuevos requisitos.

PRINCIPIOS MODELOS, MTODOS, METODOLOGA, TCNICAS, ACTIVIDADES Y HERRAMIENTAS EN EL PROCESO DE DESARROLLO DEL SOFTWAREMODELOS DE DESARROLLO DE SOFTWARE

Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debera escoger el ms apropiado para sus necesidades. En ocasiones puede que una combinacin de varios modelos sea apropiado.

Modelo de cascada

El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes fases de forma sucesiva:

Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones tambin se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crtica de los defensores de modelos ms flexibles.

Modelo De EspiralLa principal caractersticas del modelo en espiral es la gestin de riesgos de forma peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologas del modelo de cascada y del desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no jug el papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a travs de algunas iteraciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:Crear planes con el propsito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software; Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para evaluar cmo identificar y eliminar el riesgo;la implementacin del proyecto: implementacin del desarrollo del software y su pertinente verificacin;Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:

El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que acepten este anlisis y acten en consecuencia. Para ello es necesaria confianza en los desarrolladores as como la predisposicin a gastar ms para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios del proyecto, no debera utilizarse este modelo.Los desarrolladores de software han de buscar de forma explcita riesgos y analizarlos de forma exhaustiva para que este modelo funcione.La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por ltimo, se evalan los resultados y se inicia el diseo de la siguiente fase.

Desarrollo Iterativo E Incremental

El desarrollo iterativo recomienda la construccin de secciones reducidas de software que irn ganando en tamao para facilitar as la deteccin de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseo en el caso de clientes que no saben cmo definir lo que quieren.

Desarrollo gil

El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista ms ligero y ms centrado en las personas que en el caso de las soluciones tradicionales. Los procesos giles utilizan retroalimentacin en lugar de planificacin, como principal mecanismo de control. La retroalimentacin se canaliza por medio de pruebas peridicas y frecuentes versiones del software.

Hay muchas variantes de los procesos giles:

En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o "continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los pasos puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada paso completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para proveer metas concretas al desarrollo. Despus se programa el cdigo, que ser completo cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabran cmo mejorar el conjunto de pruebas necesario. El diseo y la arquitectura emergen a partir de la refactorizacin del cdigo, y se da despus de programar.El diseo lo realizan los propios desarrolladores del cdigo. El sistema, incompleto, pero funcional se despliega para su demostracin a los usuarios (al menos uno de los cuales pertenece al equipo de desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la siguiente parte del sistema de ms importancia.

Modelo De Codificacin Y Correccin

El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una estrategia predeterminada, el resultado de una falta de experiencia o presin que se ejerce sobre los desarrolladores para cumplir con una fecha de entrega.2 Sin dedicar tiempo de forma explcita para el diseo, los programadores comienzan de forma inmediata a producir cdigo. Antes o despus comienza la fase de pruebas de software (a menudo de forma tarda) y los inevitables errores que se encuentran han de eliminarse antes de poder entregar el software.

Modelos De Mejora De Procesos

El Capability Maturity Model Integration (CMMI), en espaol Integracin de Modelos de Madurez de Capacidades es uno de los modelos lderes basados en mejores prcticas. Son evaluaciones independientes las que confirman el grado con el que una organizacin siguen sus propios procesos, que no evala la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM y tiene un mbito global, no slo en procesos destinados al desarrollo del software.

ISO 9000

ISO 9000 describe estndares para un proceso organizado formalmente para resultar en un producto y los mtodos de gestin y monitoreo del progreso. Aunque este estndar se cre inicialmente para el sector de produccin, los estndares de ISO 9000 tambin se han aplicado al desarrollo del software. Al igual que CMMI, que una organizacin est certificada con el ISO 9000 no garantiza la calidad del resultado final, slo confirma que se ha seguido los procesos establecidos.

ISO 15504

ISO 15504, tambin conocido como Software Process Improvement Capability Determination (SPICE), en espaol Determinacin de la Capacidad de Mejora del Proceso de Software es un marco para la evaluacin de procesos de software. Este estndar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organizacin o proyecto hace durante el desarrollo del software. Esta informacin se analiza para identificar puntos dbiles y definir acciones para subsanarlos. Tambin identifica puntos fuertes que pueden adoptarse en el resto de la organizacin.MTODOS EN EL PROCESO DE DESARROLLO DE UN SOFTWARE.

Los mtodos formales son soluciones matemticas para resolver problemas de software y hardware a nivel de requisitos, especificacin y diseo. Ejemplos de mtodos formales incluyen el Mtodo B, la red de Petri, la demostracin automtica de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Ms generalmente, se puede utilizar la teora de autmatas para aumentar y validar el comportamiento de la aplicacin diseando un sistema de autmata finito.

Las metodologas basadas en los autmatas finitos permiten especificacin de software ejecutable y evitar la creacin convencional de cdigo.

Los mtodos formales se suelen aplicar en software de aviacin, especialmente si es software de seguridad crtico. Los estndares de aseguramiento del software de seguridad, tales como DO178B demandan mtodos formales en el nivel ms alto de categorizacin (Nivel A).

La formalizacin del desarrollo de software est ganando en fuerza poco a poco, en otros mbitos, con la aplicacin del lenguaje de especificacin OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Model-driven Architecture, que permite la ejecucin de diseos, incluso especificaciones.

Otra tendencia que est surgiendo en el desarrollo de software es la redaccin de especificaciones en algn tipo de lgica (normalmente una variacin de FOL), para acto seguido ejecutar esa lgica como si se tratase de un programa. El lenguaje OWL, basado en lgica descriptiva, es un buen ejemplo. Tambin se est trabajando en enlazar un idioma natural de forma automtica con lgica, lgica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lgica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una caractersticas de los sistemas que apoyan el vnculo bidireccional ingls-lgica y ejecucin directa de la lgica es que pueden explicar sus resultados en ingls en un nivel de negocios o cientfico.

METODOLOGAS PARA EL DESARROLLO DEL SOFTWARE

Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo.La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

ACTIVIDADES EN EL PROCESO DEL DESARROLLO DEL SOFTWARE

Planificacin. Implementacin. Pruebas del software. Documentacin. Entrenamiento. Despliegue Mantenimiento del software.HERRAMIENTAS PARA EL DESARROLLO DE SOFTWARE

Las Herramientas de Ayuda al Desarrollo de Sistemas de Informacin, surgieron para intentar dar solucin a los problemas inherentes a los proyectos de generacin de aplicaciones informticas: plazos y presupuestos incumplidos, insatisfaccin del usuario, escasa productividad y baja calidad de los desarrollos. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE (Computer Aided Software Engineering-Ingeniera de Software Asistida por Ordenador). Otras van dirigidas a mejorar la productividad durante la fase de construccin, como es el caso de los lenguajes de cuarta generacin (4GL-Fourth Generation Language).

Herramientas Para Disear Software

Existe al menos 20 herramientas libres para disear software totalmente libre. Todas utilizan la notacin UML El nivel de avance entre una y otra es notable, casi todas ofrecen como funcionalidad:Diagramas de caso de uso.Diagramas de clases.Diagramas de secuencia. Generacin de cdigo en java, c++, python y php. Algunas entidad-relacin (pero ninguna lo suficientemente avanzada) Pocas herramientas permiten ingeniera reversa, y si lo hacen solo es de lenguajes tipo java o c++.

TCNICAS PARA EL DESARROLLO DE SOFTWARE

La recoleccin de datos es una tcnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de informacin, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observacin, el diagrama de flujo y el diccionario de datos. El anlisis de costo-beneficio es una tcnica analtica que enumera y compara el costo neto de una intervencin con los beneficios que surgen como consecuencia de aplicar dicha intervencin. Para esta tcnica, los costos y los beneficios de la intervencin se expresan en unidades monetarias.

SELECCIN DEL MODELO APROPIADO SEGN LAS CARACTERSTICAS DE LOS PROYECTOS DE SOFTWARECuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Segn John Reel, existen 10 razones por las cuales un proyecto puede fracasar:

1. El personal de software no entiende las necesidades de los clientes.2. El mbito del producto est mal definido.3. Los cambios se gestionan mal.4. La tecnologa elegida cambia.5. Las necesidades comerciales cambian.6. Los plazos de entrega no son realistas.7. Los usuarios se resisten a la utilizacin del software.8. Se pierde el patrocinio.9. El equipo del proyecto carece de personal con las habilidades apropiadas.10. Los gestores evitan las mejores prcticas y las lecciones aprendidas.

Para tener xito en la consecucin de un proyecto es necesario comenzar con pie derecho, esto se lo logra trabajando duro para entender el problema y dar una solucin adecuada. Se debe rastrear el proyecto conforme se elabora el producto y se aprueba por parte del grupo de control de calidad. Es importante que el gestor del proyecto tome decisiones inteligentes para no poner en riesgo el desarrollo de la solucin. Por ltimo, se debe analizar los resultados obtenidos para obtener la experiencia necesaria en la construccin de otros proyectos.

FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos. Estos principios son: la Abstraccin, el Encapsulamiento, la Modularidad y la Herencia.

Fundamento 1: Abstraccin

Es el principio de ignorar aquellos aspectos de un fenmeno observado que no son relevantes, con el objetivo de concentrarse en aquellos que s lo son. Una abstraccin denota las caractersticas esenciales de un objeto (datos y operaciones), que lo distingue de otras clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el problema central del diseo orientado a objetos. Los mecanismos de abstraccin son usados en el EOO para extraer y definir del medio a modelar, sus caractersticas y su comportamiento. Dentro del EOO son muy usados mecanismos de abstraccin: la Generalizacin, la Agregacin y la clasificacin. Lageneralizacines el mecanismo de abstraccin mediante el cual un conjunto de clases de objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son ignoradas. En consecuencia, a travs de la generalizacin, la superclase almacena datos generales de las subclases, y las subclases almacenan slo datos particulares.La especializacin es lo contrario de la generalizacin. Por ejemplo; La clase Mdico es una especializacin de la clase Persona, y a su vez, la clase Pediatra es una especializacin de la superclase Mdico. Laagregacines el mecanismo de abstraccin por el cual una clase de objeto es definida a partir de sus partes (otras clases de objetos). Mediante agregacin se puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos perifricos. El contrario de agregacin es la descomposicin. Laclasificacinconsiste en la definicin de una clase a partir de un conjunto de objetos que tienen un comportamiento similar. La ejemplificacin es lo contrario a la clasificacin, y corresponde a la instanciacin de una clase, usando el ejemplo de un objeto en particular.

Fundamento 2: Encapsulamiento

Es la propiedad del EOO que permite ocultar al mundo exterior la representacin interna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de l. La idea central del encapsulamiento es esconder los detalles y mostrar lo relevante. Permite el ocultamiento de la informacin separando el aspecto correspondiente a la especificacin de la implementacin; de esta forma, distingue el "qu hacer" del "cmo hacer". La especificacin es visible al usuario, mientras que la implementacin se le oculta. El encapsulamiento en un sistema orientado a objeto se representa en cada clase u objeto, definiendo sus atributos y mtodos con los siguientesmodos de acceso: Pblico (+):Atributos o Mtodos que son accesibles fuera de la clase. Pueden ser llamados por cualquier clase, aun si no est relacionada con ella. Privado (-):Atributos o Mtodos que solo son accesibles dentro de la implementacin de la clase. Protegido (#):Atributos o Mtodos que son accesibles para la propia clase y sus clases hijas (subclases). Los atributos y los mtodos que son pblicos constituyen la interfaz de la clase, es decir, lo que el mundo exterior conoce de la misma. Normalmente lo usual es que se oculten los atributos de la clase y solo sean visibles los mtodos, incluyendo entonces algunos de consulta para ver los valores de los atributos. El mtodo constructor (Nuevo,New) siempre es Pblico.

Fundamento 3: Modularidad

Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La modularidad consiste en dividir un programa en mdulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros mdulos. En un mismo mdulo se suele colocar clases y objetos que guarden una estrecha relacin. El sentido de modularidad est muy relacionado con el ocultamiento de informacin.

Fundamento 4: Herencia

Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en una jerarqua de clasificaciones.Permite la definicin de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programacin Diferencial), evitando repeticin de cdigo y permitiendo la reusabilidad.Las clases heredan los datos y mtodos de la superclase. Un mtodo heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple (cada clase tiene slo una superclase) o mltiple (cada clase puede tener asociada varias superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante (herencia mltiple).

Fundamento 5: Polimorfismo

Es una propiedad del EOO que permite que un mtodo tenga mltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecucin del mtodo. El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o estn relacionados en trminos de inclusin. En este tipo de polimorfismo, los mtodos son interpretados en el contexto del objeto particular, ya que los mtodos con nombres comunes son implementados de diferente manera dependiendo de cada clase.Por ejemplo, el rea de un cuadrado, rectngulo y crculo, son calculados de manera distinta; sin embargo, en sus clases respectivas puede existir la implementacin del rea bajo el nombre comn rea. En la prctica y dependiendo del objeto que llame al mtodo, se usar el cdigo correspondiente.Ejemplos: Superclase:Clase AnimalSubclases: Clases Mamfero, Ave, Pez. Se puede definir un mtodo Comer en cada subclase, cuya implementacin cambia de acuerdo a la clase invocada, sin embargo el nombre del mtodo es el mismo. Mamifero.Comer Ave.Comer Pez.Comer Otro ejemplo de polimorfismo es el operador +. Este operador tiene dos funciones diferentes de acuerdo al tipo de dato de los operandos a los que se aplica. Si los dos elementos son numricos, el operador + significa suma algebraica de los mismos, en cambio si por lo menos uno de los operandos es un String o Carcter, el operador es la concatenacin de cadenas de caracteres.

CARACTERSTICAS DEL ENFOQUE ORIENTADO A OBJETOS.

Las caractersticas siguientes son las ms importantes: Abstraccin: Denota las caractersticas esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin. El proceso de abstraccin permite seleccionar las caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstraccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar lacohesinde los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultacin, principalmente porque se suelen emplear conjuntamente. Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos se pueden compilar por separado, pero tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas. Principio de ocultacin: Cada objeto est aislado del exterior, es un mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especfica cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstraccin. La aplicacin entera se reduce a un agregado orompecabezasde objetos. Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms estticos (en "tiempo de compilacin") de polimorfismo, tales como las plantillas y lasobrecarga de operadoresde C++. Herencia: Las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto hereda de ms de una clase se dice que hay herencia mltiple. Recoleccin de basura: La recoleccin de basura o garbage collector es la tcnica por la cual el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignacin o liberacin de memoria, ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie lo est usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el Paradigma de Programacin Orientada a Objetos como C++ uObject Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente.

COMPONENTES FUNDAMENTALES DEL ENFOQUE ORIENTADO A OBJETOS.

Clase:Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciacin es la lctura de estas definiciones y la creacin de un objeto a partir de ellas. Herencia:(Por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos mtodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) tambin se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as para mantener hegemnico el ideal de OOP. Objeto:Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (mtodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase. Mtodo:Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un mtodo puede producir un cambio en las propiedades del objeto, o la generacin de un "evento" con un nuevo mensaje para otro objeto del sistema. Evento:Es un suceso en el sistema (tal como una interaccin del usuario con la mquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede desencadenar un objeto, es decir la accin que genera. Mensaje:Una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus mtodos con ciertos parmetros asociados al evento que lo gener. Propiedad o atributo:Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus caractersticas predeterminadas, y cuyo valor puede ser alterado por la ejecucin de algn mtodo. Estado interno:Es una variable que se declara privada, que puede ser nicamente accedida y alterada por un mtodo del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Componentes de un objeto:Atributos, identidad, relaciones y mtodos. Identificacin de un objeto:Un objeto se representa por medio de una tabla o entidad que est compuesta por sus atributos y funciones correspondientes.

REUSABILIDAD DE COMPONENTES.

Una vez que una clase ha sido escrita, creada y depurada, se puede distribuir a otros programadores para utilizar en sus propios programas. Esta propiedad se llama reusabilidad o reutilizacin. Su concepto es similar a las funciones incluidas en las bibliotecas de funciones de un lenguaje procedimental como C que se pueden incorporar en diferentes programas. En C++, el concepto de herencia proporciona una extensin o ampliacin al concepto de reusabilidad.Un programador puede considerar una clase existente y sin modificarla, aadir competencias y propiedades adicionales a ella. Esto se consigue derivando una nueva clase de una ya existente. La nueva clase heredar las caractersticas de la clase antigua, pero es libre de aadir nuevas caractersticas propias.La facilidad de reutilizar o rehusar el software existente es uno de los grandes beneficios de la POO: muchas empresas consiguen con la reutilizacin de clase en nuevos proyectos la reduccin de los costes de inversin en sus presupuestos de programacin. Las propiedades comunes de varias clases slo necesitan ser implementadas una vez y slo necesitan modificarse una vez si es necesario.

DOCUMENTACIN Y ARTEFACTOSLa documentacin no es ms que la debilidad ms frecuente en productos e instalaciones informticos. Cabe mencionar que los actores que intervienen en el ciclo de vida del software desempean diversos roles. Arquitectos, diseadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.

Un artefacto es una pieza de informacin que es producida o utilizada por procesos. Los artefactos son los elementos son los elementos tangibles de un proyecto, elementos que el proyecto produce o usa mientras se trabaja en busca del producto final. stos, pueden tomar varias formas y formatos, como por ejemplo:

Un documento, tal como la visin o la lista de riesgos. Un modelo, por ejemplo un diagrama de casos de uso o el modelo de diseo. Un elemento dentro de un modelo, tal como una clase, un caso de uso o un subsistema. Ejecutables, por ejemplo el ejecutable del prototipo. Cdigo fuente.

Las actividades tienen artefactos como entrada y salida. Los roles usan artefactos para ejecutar actividades y producen artefactos durante la ejecucin de sus actividades. Los artefactos son la responsabilidad sencilla del rol, creando responsabilidades fciles de identificar y entender, promoviendo la idea de que cada pieza de informacin producida en un proceso de desarrollo requiere un conjunto apropiado de habilidades. Aunque un rol puede ser el propietario de un artefacto, otros roles pueden hacer uso de ste, incluso podran actualizar el artefacto si el rol que va a hacerlo, tiene permiso para hacerlo.En RUP se encuentran conjuntos de artefactos que agrupan artefactos relacionados con el modelo de negocio, los requerimientos, el anlisis y diseo, la implementacin, las pruebas, la configuracin y administracin de cambios, el ambiente de desarrollo, entre otros.

METODOLOGAS EMPLEADOSDesde la ya antigua metodologa Waterfall hasta las modernas tcnicas giles, SOFTENG ha ido adaptando sus procesos internos basndose en la experiencia y el conocimiento, viendo los defectos que planteaba cada metodologa y para minimizarlos. Esta forma de trabajar nos llev a adaptar de manera natural una forma de trabajar gil muy similar a la metodologa Scrum. El siguiente paso lgico era formar a los equipos de trabajo y potenciar la figura del Scrum Master mediante certificaciones oficiales. Como resultado, podemos afirmar que SOFTENG fue una de las primeras empresas del mbito nacional en implementar esta metodologa, obteniendo una mayor satisfaccin por parte de nuestros clientes, unos mejores resultados en los proyectos de desarrollo de software y un gran ambiente de trabajo en nuestros equipos, caldo de cultivo de xitos.PROCESO UNIFICADO DE DESARROLLO (UP DEL INGLS UNIFIED PROCESS) FASES DEL DESARROLLO, DISCIPLINASEl Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, elProceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.El nombreProceso Unificadose usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya queProceso Unificado de RationaloRUPson marcas registradas porIBM(desde su compra deRational Software Corporationen 2003). El primer libro sobre el tema se denomin, en su versin espaola,El Proceso Unificado de Desarrollo de Software(ISBN 84-7829-036-2) y fue publicado en 1999 porIvar Jacobson,Grady BoochyJames Rumbaugh, conocidos tambin por ser los desarrolladores del UML, elLenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trminoProceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre deProceso Unificado de Rational.FASES DE DESARROLLO.Fase De Inicio. Es la fase ms pequea del proyecto e, idealmente, debe realizarse tambin en un periodo de tiempo pequeo (una nica iteracin). El hecho de llevar a cabo una fase de inicio muy larga indica que se est realizando una especificacin previa excesiva, lo que responde ms a un modelo en cascada.

Objetivos: Establecer una justificacin para el proyecto. Establecer el mbito del proyecto. Esbozar los casos de uso y los requisitos clave que dirigirn las decisiones de diseo. Esbozar las arquitecturas candidatas. Identificar riesgos. Preparar el plan del proyecto y la estimacin de costes. El hito de final de fase se conoce como Hito Objetivo del Ciclo de Vida.

Fase de Elaboracin.Durante esta fase se capturan la mayora de los requisitos del sistema. Los objetivos principales de esta fase sern la identificacin de riesgos y establecer y validar la arquitectura del sistema. Base de Arquitectura Ejecutable:La arquitectura se valida a travs de la implementacin de una Base deArquitectura Ejecutable: se trata de una implementacin parcial del sistema que incluye los componentes principales del mismo. Al final de la fase de elaboracin la base de arquitectura ejecutable debe demostrar que soporta los aspectos clave de la funcionalidad del sistema y que muestra la conducta adecuada en trminos de rendimiento, escalabilidad y coste. Al final de la fase se elabora un plan para la fase de construccin. El hito arquitectura del ciclo de vida marca el final de la fase. Fase De Construccin. Es la fase ms larga de proyecto. El sistema es construido en base a lo especificado en la fase de elaboracin. Las caractersticas del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo. El resultado de cada iteracin es una versin ejecutable de software. El hito de capacidad operativa inicial marca el final de la fase.

Fase de transicin. En esta fase el sistema es desplegado para los usuarios finales. La retroalimentacin recibida permite incorporar refinamientos al sistema en las sucesivas iteraciones. Esta iteracin tambin cubre el entrenamiento de los usuarios para la utilizacin del sistema. El hito de lanzamiento del producto marca el final de la fase.

DISCIPLINAS.Modelado del negocio. El objetivo es establecer un canal de comunicacin entre los ingenieros del negocio y los ingenieros del software. Los ingenieros del software deben conocer la estructura y dinmica de la organizacin objetivo (el cliente), los problemas actuales y sus posibles mejoras. Se plasma en la identificacin del modelo del dominio en el que se visualizan los aspectos bsicos del dominio de aplicacin.

Requisitos. El objetivo es describir que es lo que tiene que hacer el sistema y poner a los desarrolladores y al cliente de acuerdo en esta descripcin.Anlisis y diseo. Describe como el software ser realizado en la fase de implementacin. Se plasma en un modelo de diseo que consiste en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidos. Tambin contiene descripciones de cmo los objetos colaboran para realizar las acciones incluidas en los casos de uso.Implementacin. Se implementan las clases y objetos en trminos de componentes (ficheros fuentes, binarios, ejecutables, entre otros).Prueba. Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integracin entre objetos, la implementacin de todos los requisitos, entre otros.Despliegue. Se crea la versin externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. Tambin se da asistencia y ayuda a los usuarios.Gestin De Configuraciones Y Cambios. Gestiona aspectos como los sistemas de control de versiones. Controla las peticiones de cambios clasificndolas segn su estado (nueva, registrada, aprobada, asignada, completa, entre otros). Los datos se almacenan en una base de datos y se pueden obtener informes peridicos. Herramientas como Rational ClearQuest o Bugzilla.

Gestin del proyecto. Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteracin.

Entorno. Se centra en las actividades necesarias para configurar el proceso de un proyecto. El objetivo es proveer a la organizacin de desarrollo software de un entorno de trabajo (que incluye procedimientos y herramientas) que soporten al equipo de desarrollo.

INTRODUCCIN A LOS PROCESOS AGILES DE DESARROLLO. FUNDAMENTOS

Introduccin a los Procesos giles de Desarrollo.

El desarrollo gil de software es un marco de trabajo conceptual de la ingeniera de software que promueveiteracionesen el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo.

El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto. Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpenen ingls). La oficina debe incluir revisores, escritores de documentacin y ayuda, diseadores de iteracin ydirectores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica.

Fundamentos delos Procesos giles de Desarrollo.

El augedela tecnologa, y el objetivodeagilizar y automatizarlosprocesosen eldesarrollo desoftware, llevan a la necesidaddeimplantar MetodologasdeDesarrollodeSoftware que ayuden a entregar un productodecalidad en tiempo y costo estimados, las metodologas gilesdedesarrollodesoftware handespertado inters gracias a que proponen simplicidad y velocidad para crear sistemas.

INTRODUCCIN AL MODELADOElmodeladode sistemassoftwarees una tcnica para tratar con la complejidad inherente a estos sistemas. El uso de modelos ayuda al ingeniero de software a "visualizar" el sistema a construir. Adems, los modelos de un nivel de abstraccin mayor pueden utilizarse para la comunicacin con el cliente.

CARACTERSTICAS DEL MODELADO Abstracto Enfatiza los elementos importantes y oculta los irrelevantes Comprensible Fcil de comprender por los observadores Preciso Representa de forma fiel el sistema que modela Predictivo Se pueden usar para deducir conclusiones sobre el sistema que modela Barato Mucho ms barato y sencillo de construir que el sistema que modela Los modelos de ingeniera eficaces deben satisfacer todas estas caractersticas

CONCLUSINHoy en da el software tiene un doble papel. Es un producto, pero simultneamente es el vehculo para hacer entrega de un producto. Como producto permite el uso del hardware, ya sea, por ejemplo, un ordenador personal o un telfono mvil celular. Como vehculo utilizado para hacer entrega del producto, acta como base de control, por ejemplo un sistema operativo, o un sistema gestor de redes. El software hace entrega de lo que se considera comoel producto ms importante del siglo veintiuno, la informacin. El software transforma datos personales para que sean ms tiles en un entorno local, gestiona informacin comercial para mejorar la competitividad, proporciona el acceso a redes a nivel mundial, y ofrece el medio de adquirir informacin en todas sus formas.Actualmente se considera laIngeniera del Softwarecomo una nueva rea de la ingeniera, y la profesin de ingeniero informtico es una de las ms demandadas, aunque en Espaa los salarios suelen ser bajos para la cualificacin de estos profesionales. La palabra ingeniera tiene una connotacin de prestigio que provoca que muchas ramas del conocimiento tiendan a autodenominarse as.Actualmente existe sobredemanda de profesionales altamente cualificados, sucede principalmente en las grandes industrias, como Google, Facebook, Twitter y otras grandes compaas que ms que competir, combaten entre s para captar a los valiosos egresados de las principales universidades.

BIBLIOGRAFAhttp://www.gcfaprendelibre.org/tecnologia/curso/informatica_basica/empezando_a_usar_un_computador/2.dohttp://definicion.de/software/http://ingenieriadelsoftwareigenesis.blogspot.com/2012/11/cualidades-del-software.htmlhttp://www.monografias.com/trabajos59/calidad-software/calidad-software2.shtmlhttp://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_softwarehttp://softwarelibre-informatica.blogspot.com/2013/04/seleccion-del-modelo-apropiado-segun.htmlhttp://procesodedasarrolo.blogspot.com/2011/11/fundamentos-del-enfoque-orientado_10.htmlhttp://brfranciscoosunaiuty.blogspot.com/2012/07/documentacion-y-artefactos.htmlhttp://informatica-iutll.blogspot.com/2013/03/proceso-unificado-de-desarrollo.htmlhttp://procesodedasarrolo.blogspot.com/2011/11/introduccion-los-procesos-agiles-de.html