Trabajo Ingeniera de Software

Nombre: Marcelo Fuentes C.Ramo: Ingeniera de SoftwareFecha de entrega: 30-03-2015

ndicePortada ---------------------------------------------------------------------------1ndice ---------------------------------------------------------------------------2Introduccin ---------------------------------------------------------------------3Desarrollo ------------------------------------------------------------------------4Ciclo de vida clsico o en cascada----------------------------------------4Construccin de prototipos--------------------------------------------------5Modelo evolutivo---------------------------------------------------------------6Tcnicas de generacin CCMI---------------------------------------------10Que es ITIL?---------------------------------------------------------------------12Paradigma orientado a objetos---------------------------------------------17Que es BPMN?-----------------------------------------------------------------18Conclusin----------------------------------------------------------------------23 Bibliografa----------------------------------------------------------------------24

Introduccin

Actualmente el software se ha vuelto un elemento relevante en nuestra sociedad, actuando como productor de servicios y facilitando actividades cotidianas y profesionales del ser humano. En la industria del software las mejoras en el hardware son apresuradas y para hacer uso de estas tecnologas se necesita de un software de mayor complejidad. A parte de ms complejo, se necesita que sea confiable, de calidad, que satisfaga al cliente y que se desarrolle en el menor tiempo posible.

El termino ingeniera de software se refiere al establecimiento y uso de principios robustos de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione eficientemente sobre mquinas reales, los modelos descritos a lo largo del trabajo nos guiaran al desarrollo correcto y eficiente de un software.

A)Ciclo de vida clsico o en cascadaEste enfoque del desarrollo desoftwareha sido el ms utilizado y en la actualidad, pese a la aparicin de metodologasgiles, sigue siendo la solucin predominante, si bien, en cada organizacin o en cada deproyectose puede llevar a cabo con ciertas variantes. Anlisis: Esta fase comprendera desde la posible obtencin de unos objetivos o requisitos iniciales para determinar la viabilidad del sistema y escrutar las distintas alternativas de solucin, pasando por la elaboracin del catlogo de requisitos, hasta la realizacin de casos de uso, prototipado de pantallas e informes, como una primera especificacin del plan de pruebas. Diseo: El anlisis describe el sistema sin entrar en caractersticas propias de la implementacin, es en esta fase donde se adapta ese anlisis generalista a la solucin concreta que se quiere llevar a cabo, definindose la arquitectura general del sistema de informacin, su divisin en subsistemas de diseo, el modelo de datos lgico, el modelo de clases (en el caso de un diseo orientado a objetos), la especificacin detallada del plan de pruebas, etc Codificacin: En esta fase se realiza la construccin del sistema de informacin y las pruebas relacionadas con dicho proceso, como son las unitarias, integracin y de sistema, as como otras actividades propias de las etapas finales de un desarrollo como es la realizacin de la carga inicial de datos (si bien en muchos casos se deja esto para cuando el producto est en produccin) y/o la construccin del procedimiento de migracin. Pruebas: En esta etapa se realizara la instalacin del sistema en un entorno de pruebas lo ms parecido posible al de produccin (entorno de preproduccin) donde se realizaran las pruebas de implantacin (que verifican principalmente aspectos no funcionales) y las de aceptacin, donde los usuarios validan que el sistema hace lo que realmente esperaban (sin que se deba olvidar que los lmites los establecen los modelos realizados previamente y que han debido ser validados). Por ltimo se realizara la implantacin del sistema en el entorno de produccin. Mantenimiento: Una vez que el sistema se encuentra en produccin, se realizarn sobre el mismo diversas tareas de mantenimiento, que en funcin de su naturaleza se clasifican en correctivos, evolutivos, adaptativos y perfectivos. Estas tareas de mantenimiento sern consecuencia de incidencias y peticiones reportadas por los usuarios y los directores usuarios.En el ciclo de vida clsico en funcin de las modificaciones y/o correcciones que se realizan en una etapa ser necesario la vuelta a fases previas para hacer coherente el proceso de desarrollo y los modelos.

CONSTRUCCION DE PROTOTIPOSA menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humana mquina, entonces en este caso cuando utilizamos la construccin de prototipos.

El paradigma de construccin de prototipos se inicia con la comunicacin. El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms definicin. Entonces se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en la forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el usuario final. El diseo rpido conduce a la construccin de un prototipo. Despus, el prototipo lo evala el usuario y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que se debe hacer.

MODELO EVOLUTIVO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin.Los modelos Iterativo Incremental y Espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo.La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Existen dos tipos de desarrollo evolutivo: Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el enfoque incremental de desarrollocomo una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce tambin bajo las siguientes denominaciones:

Mtodo de las comparaciones limitadas sucesivas. Ciencia de salir del paso. Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa interactiva de Construccin de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado ncleo.

En una visin genrica, el proceso se divide en 4 partes:

Anlisis Diseo Cdigo Prueba

Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminar siendo la solucin completa requerida por el cliente, pero stas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con ms urgencia, de los puntos ms importantes del proyecto, los requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versin.

De este modo podemos terminar una aplicacin ejecutable (primera versin) que podr ser entregada al cliente para que ste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efecte para hacer mejoras en el producto. Estas nuevas mejoras debern esperar a ser integradas en la siguiente versin junto con los dems requerimientos que no fueron tomados en cuenta en la versin anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino nicamente correccin de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de requisitos funcionales y ser el cliente quien se encarga de priorizar que funcionalidades son mas importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregar. La asignacin de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Tcnicas de generacin (CMMI, ITIL) CMMI (Capability Maturity Model Integration)Qu es CMMI?CMMI son las siglas deCapability Maturity Model Integration. Es un modelo desarrollado por elSoftware Engineering Institutepara la mejora de los procesos de las empresas de software que califica las compaas segn su nivel de madurez. Por proceso se entiende un conjunto de fases sucesivas que llevan a la obtencin de un resultado, y por nivel de madurez, el grado de calidad que alcanzan los procesosCMMI establece una serie de buenas prcticas que las empresas deben cumplir para ser consideradas de un grado de madurez determinado a la hora de generar resultados. Pero ojo: CMMI no te dicecmollevar a cabo estas prcticas, simplemente te indica qudebes cumplir. Es cosa de cada empresa buscar el modo de cumplir con dichas prcticas (y es aqu donde comienza el gran negocio de los consultores en torno a CMMIExisten tres tipos de CMMI, nombrados comoconstelacionespor algn gur de las altas esferas. Est la constelacinCMMI for Acquisition, para la mejora de procesos de contratacin externa, laCMMI for Services, para el establecimiento y la entrega de servicios y CMMI for Development, para la mejora del desarrollo de productos (software).

Los niveles de madurez de CMMICMMI est representado escalonadamente en 5 niveles de madurez, que califican a las empresas segn la calidad de su proceso de produccin. Estos niveles, adems de por su correspondiente ordinal (del 1 al 5), se conocen por el adjetivo que los describe: Inicial, Gestionado, Definido, Cuantitativamente gestionado y el ms alto de todos, Optimizado. Veamos brevsimamente en qu consiste cada uno de ellos.Nivel 1 (Inicial): La organizacin no sigue conscientemente las prcticas especificadas en el modelo CMMI, pero de una forma u otra consigue que sus productos salgan al mercado. Supone una gran dependencia de los llamados hroes, profesionales sobresalientes que con su esfuerzo y habilidad personal sacan a la empresa del atolladero. La organizacin no genera conocimiento y la prdida de estos hroes supone generalmente la prdida de la capacidad acumulada.

Nivel 2 (Gestionado): Supone el cumplimiento, por parte de cada proyecto, de varias reas de proceso de CMMI relacionadas con la gestin de requisitos, la planificacin, la monitorizacin, la gestin de la configuracin, el aseguramiento de la calidad, el acuerdo con los proveedores y la medicin y anlisis de los procesos. Se trata de asegurar que las buenas prcticas se mantengan independientemente de los vaivenes coyunturales que afecten a la organizacin. El conocimiento reside en la organizacin.Nivel 3 (Definido): En este nivel, los procesos ya no slo se definen de manera independiente para cada proyecto sino que toda la organizacin goza de unas pautas comunes. Se instaura una serie de procesos que, llevando la explicacin al paradigma de la orientacin a objetos, suponen la clase sobre la cual se instancian los proyectos. En resumidas cuentas, la empresa goza de una plantilla bien caracterizada que al ser aplicada a cada caso particular, genera un proyecto.Nivel 4 (Cuantitativamente gestionado): Llegados a este punto, la organizacin ya no slo gestiona los proyectos mediante procesos bien definidos, sino que adems, se fijan objetivos tangibles que los procesos deben cumplir en lo relativo a su calidad, de manera que se analizan estadsticamente los procesos, propiciando una exactitud y predictibilidad, si se me permite el palabro, de la que no goza el nivel anterior.Nivel 5 (Optimizado): En el nivel ms alto de CMMI, la organizacin entera experimenta una optimizacin continua de los procesos a travs de la innovacin en los mismos y de las mejoras tecnolgicas. Se modifican y reconducen los procesos en funcin de los defectos revelados durante el anlisis estadstico.Y cmo se le reconoce oficialmente a una organizacin su nivel de madurez?La evaluacin, conocida como Appraisal, del grado de madurez de una empresa es llevada a cabo por un equipo que debe estar formado, segn el mtodoSCAMP(Standard CMMI Appraisal Method for Process Improvement), por un evaluador oficial (Lead Appraiser) formado por elSEIy por un conjunto de personas que deben haber recibido el curso de introduccin a CMMI y entre las que se puede encontrar, y de hecho es lo habitual, personal de la propia organizacin. Este enfoque de que gente de la propia organizacin evale el grado de madurez que su empresa merece puede parecer chocante, y con razn. Sin embargo de una forma u otra el complejo mtodo SCAMPI se las apaa para asegurar la objetividad, o al menos eso garantiza el SEI.

Se trata de una prueba exigente, que puede llegar a durar varias semanas, durante las cuales, entre otras cosas, se recogen y analizan las evidencias de cumplimiento de las reas de proceso a evaluar y se entrevista a los involucrados en la organizacin. Al finalizar laAppraisal, el evaluador emite un informe que debe ser confirmado en Estados Unidos por nuestros amigos del SEI

ITIL (Information Technology Infrastructure Library)Que es ITIL?Los departamentos de informticas; por la complejidad de sus procesos, de sus activos, de sus profesionales, de su deslinde del resto de la organizacin, y en general, por su difcil e indescifrable entramado, requieren de un conjunto de metodologas y herramientas que los ayuden a prestar sus servicios de una manera eficaz y efectiva. Por muchos aos, todo estuvo centralizado y controlado desde una especie de jefatura superior. Sin embargo, con el advenimiento de Internet, la complejidad de los negocios, la globalizacin, la fuerte competencia, y la necesidad de sobrevivir en un contexto cada vez ms enrarecido, los directores de informtica han necesitado herramientas que les ayuden a aadir valor y al mismo tiempo les permita gestionar sus recursos, en muchos casos intangibles y estratgicos, de manera ptima. ITIL es una de esas herramientas que saltan a la palestra para proporcionar al gerente IT la ayuda necesaria para que pueda lograr los objetivos organizaciones de manera productiva.ITIL (Information Technology Infrastructure Library) es un conjunto de mejores prcticas (procedimientos, tcnicas, mtodos, o actividades eficientes y efectivos en proporcionar un determinado resultado), enmarcadas en un conjunto de procesos (biblioteca) cuyo objetivo es organizar de manera productiva y holstica los diferentes servicios que proporciona el departamento de tecnologa de la informacin (informtica) de una organizacin.Definido en los aos 80 y popularizado durantes los 90s, ITIL trata de poner en cintura a los departamentos de informtica, al organizar el caos generado por la generacin Cliente/Servidor, concepto que estuvo influenciado por la conocida tendencia de sistemas abiertos (Open Systems), compuesta por herramientas tecnolgicas (Hadware, Software y Telecomunicaciones) integradas de manera armnica, e interactuando perfectamente entre s. Todo despus de un fuerte dominio de mercado por parte del gigante azul IBM.Creado por laOGC(Office of Government Commerce) del Reino Unido (www.itil.co.uk), y popularizado por analistas, consultores, y empresas de software, ITIL se ha convertido en un estndar de facto, presenta entre sus principales beneficios los siguientes: 1) abre el camino a un concepto en boga (el Gobierno IT) que trata de auditar y controlar de alguna manera las decisiones de inversin y presupuesto de muchos departamentos de IT, 2) introduce un orden en los elementos tcnicos y tecnolgicos que conformar la infraestructura informtica de una organizacin, relaciona esos elementos, facilitando la gestin y legalidad de todos sus componentes, y en general, 3) trata de ahorrar el coste de la prestacin de servicios de IT en el largo plazo. En resumen, se trata de una nueva moda informtica, que trata de cubrir las mismas deficiencias que han prevalecido siempre, y que de algn modo han legitimado la evolucin conceptual y pragmtica de la informtica.La visin que tiene ITIL de la informtica en la empresa, al menos hasta la versin 2, es en trminos de Servicios. Es decir, las unidades de negocios de cualquier organizacin demandan y/o son usuarias de servicios informticos. Dichos servicios son enumerados y reflejados en un catlogo de servicios, el cual es negociado entre el cliente (el que paga por el servicio en la organizacin), y los gestores informticos. A su vez dichos servicios son utilizados por los usuarios finales (end-users) en los procesos neurlgicos y de apoyo de la organizacin.Para poder cumplir con los acuerdos de servicios con los clientes (denominadosService Level Agreements SLA), la biblioteca ITIL se divide en dos (2) grandes bloques:1)Soporte a los Servicios IT, y2)Entrega o Provisin de Servicios.A su vez, cada una de las dos (2) grandes bibliotecas que conforman ITIL se divide en los siguientes procesos:

Cada uno de estos procesos tiene vida y/o autonoma propia. Organizndose de acuerdo a sus necesidades. Quizs el ms popular y utilizado es el Service Desk (el cual es una funcin organizacional), la gestin de incidencias, la de problemas y gestin de cambios.Reviste comentario especial la gestin de configuracin, la cual es la garante y depositara de todos los tems de configuracin de la infraestructura, y todo lo hace, almacenando y relacionando dicha informacin en una base de datos conocida popularmente como la CMDB (Configuration Management Data Base). Base de Datos que juega un rol estelar y central en la introduccin e implantacin de ITIL en una organizacin.ITIL es un intento interesante de organizar y poner en cintura a los departamentos de informtica o IT. Persigue, entre otras cosas, el ahorre de costes en el largo plazo, as como el incremento en productividad y eficiencia de los informticos.Algunas debilidades de ITIL se manifiestan en lo complejo y costoso que resulta su implantacin en grandes organizaciones, no sin mencionar la cuasi imposible tarea de mantener actualizada y perfectamente funcionando la CMDB, el control de los cambios, y entornos multi-culturales, donde una vasta mayora de empresas contratan outsourcing del Service Desk por razones de estrategia de negocios y ahorro de costes.Nuevas versiones de ITIL aparecern e irn realizando correcciones a las mejores prcticas, el ciclo de la tecnologa seguir su curso, nuevos conceptos, herramientas, tecnologas y tcnicas emergern, y validarn si el concepto de ITIL es una intento vlido de mantener en orden, sin duda alguno, uno de los departamentos ms difciles de gestionar para la alta gerencia de cualquier organizacin.Para clarificar el concepto, la figura 1 presenta una puesta en marcha estndar simulada de ITIL en una organizacin. Tericamente se describen los puntos y pasos para su efectiva implantacin.Como funciona ITILPaso 1 y 2 (a) Todo comienza con la organizacin como gran demandante de servicios informticos, el cliente o el que asigna y decide el presupuesto para estos servicios de la organizacin acuerda o negocia los acuerdos de servicios (SLA) con la direccin de informtica. Se crea un catalogo de servicios, costes, tiempos, y otras condiciones de los servicios que prestar informtica a la organizacin. Por ejemplo, servicios de e-Mail, Intranet, ERP, CRM, Internet, impresin, entre otros.Paso 3 (b) Una vez puestos en marcha los servicios se define e instala un departamento o unidad de Service Desk (escritorio de ayuda), el cual ser el punto de contacto de los usuarios de los servicios con el departamento de informtica. Se trata de un nico punto de comunicacin de los usuarios con informtica, en donde se podrn abrir incidencias y nuevos requerimientos de servicios.Paso 3 (c) Los responsables del Service Desk, reciben y registran las solicitudes de los usuarios. En casos de incidentes de los servicios, primero buscan en la base de datos de errores conocidos o una especie de base de datos de conocimientos, para verificar si la solucin al incidente existe, y as dar la solucin al usuario de forma inmediata.Paso 3 (d) En caso de no poder solucionar el incidente al usuario, el operador de Service Desk lo escala a la persona apropiada para que lo soluciones. En otras palabras se pasa a la Gestin de Incidentes para que se busque la solucin al usuario.Paso 4 (e) Si el incidente es recurrente y/o no es encontrado, se pasa a la Gestin de problemas en donde se buscar la solucin definitiva. De ser posible se escala a proveedores externos (por ejemplo IBM, SUN, etc.) para que ayude en la solucin del mismo. Una vez solucionado el problema, se documenta e incorpora a la base de datos de errores conocidos.Paso 4 (f) Muchas veces los usuarios solicitan nuevos servicios a la gerencia de informtica. Service Desk en este caso abre una peticin de servicios y lo pasa a la Gestin del Cambio para que se abra un Cambio y se proceda, previa evaluacin por parte de un comit asesor (CAB), con su implementacin. Un cambio es toda peticin de servicios que cambia la infraestructura informtica de la organizacin.Paso 4 (g) La gestin de versiones se refiere, como su nombre lo indica, al mantenimientos de versiones de software por parte de la direccin informtica. Abarca la gestin tecnolgica y control legal de las versiones de software instaladas en la infraestructura de la organizacin.Paso 4 (h) La base de datos de configuracin o CMDB mantiene el inventario de todos los tems de configuracin (por ejemplo, PCs, impresoras, software, documentacin, personas, etc.) de la organizacin, la cual es accedida y actualizada por los diferentes procesos que conforman ITIL.Pasos 2 (i), (j), (k) y (l) Son necesarios y estratgicos para mantener los servicios informticos operando de manera efectiva y eficaz. Y tambin utilizan a la CMDB como referencia y consulta de los componentes de la infraestructura informtica.

Figura 1 Cmo funciona ITILB) Paradigma orientado a objetos

Laprogramacin orientada a objetosoPOO(OOPsegn sussiglaseningls) es unparadigma de programacinque usaobjetosy sus interacciones, para disear aplicaciones y programas de computadoras. Est basado en varias tcnicas, incluyendoherencia, abstraccin,polimorfismoy encapsulamiento.Unparadigma de programacinrepresenta un enfoque particular ofilosofa para la construccin del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas.

En la POO las entidades centrales son los objetos, que son tipos de datos que encapsulan con el mismo nombre estructuras de datos, operaciones o algoritmos que manipulan esos datos.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.Propiedades de un ModeloABSTRACCINEs la propiedad que permite representar las caractersticas esenciales de un objeto sin preocuparse de las restantes caractersticas. Se centra en la vista externa de un objeto de modo que sirve para separar el comportamiento esencial de un objeto, de su implementacin.ENCAPSULAMIENTOEs la propiedad que permite asegurar que el contenido de la informacin de un objeto esta oculta al mundo exterior, es decir el objeto A no conoce lo que hace el objeto B y viceversa.La encapsulacin permite la divisin de un programa en mdulos, esos mdulos se implementan mediante clases, de forma que una clase representa la encapsulacin de una abstraccin.MODULARIDADEs 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 si y de las partes restantes.JERARQUIAEs la propiedad que permite una ordenacin de las abstracciones, las dos jerarquas ms importantes de un sistema complejo son:Estructuras de clases (jerarqua Es-Un: Generalizacin/Especificacin)Estructuras de objetos (jerarqua Parte-De: Agregacin)

C) BPMN Que es BPMN?es una notacin grfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). BPMN fue inicialmente desarrollada por la organizacinBusiness Process Management Initiative(BPMI), y es actualmente mantenida por elObject Management Group (OMG), despus de la fusin de las dos organizaciones en el ao2005. El principal objetivo de BPMN es proporcionar una notacin estndar que sea fcilmente legible y entendible por parte de todos los involucrados e interesados del negocio (stakeholders). Entre estos interesados estn los analistas de negocio (quienes definen y redefinen los procesos), los desarrolladores tcnicos (responsables de implementar los procesos) y los gerentes y administradores del negocio (quienes monitorizan y gestionan los procesos). En sntesis, BPMN tiene la finalidad de servir como lenguaje comn para cerrar la brecha de comunicacin que frecuentemente se presenta entre el diseo de los procesos de negocio y su implementacin.Actualmente hay una amplia variedad de lenguajes, herramientas y metodologas para el modelado de procesos de negocio. La adopcin cada vez mayor de la notacin BPMN como estndar, ayudar a unificar la expresin de conceptos bsicos de procesos de negocio as como conceptos avanzados de modelado

SimbologiaEventosEstn representados grficamente por un crculo y describen algo que sucede (lo contrario de las Actividades que son algo que se hace). Los eventos tambin pueden ser clasificados como Capturado o Lanzado.Evento InicialActa como un disparador de un proceso. Se representa grficamente por un crculo de lnea delgada y dentro del crculo esta relleno de color verde. Este evento permite Capturar.Evento FinalIndica el final de un proceso. Est representado grficamente por un crculo de lnea gruesa y dentro del crculo esta relleno del color rojo. Este evento permite Lanzar.Evento IntermedioIndica que algo sucede entre el evento inicial y el evento final. Est representado grficamente por un crculo de doble lnea simple y dentro del crculo relleno de color naranja. Este evento puede Capturar o Lanzar.

ActividadesSe representan por un rectngulo con sus vrtices redondeados y describe el tipo de trabajo que ser realizado.

TareaUna tarea representa una sola unidad de trabajo que no es o no se puede dividir a un mayor nivel de detalle de procesos de negocio sin diagramacin de los pasos de un procedimiento.

SubprocesoSe utiliza para ocultar o mostrar otros niveles de detalle de procesos de negocio, cuando se minimiza un subproceso se indica con un signo ms contra de la lnea inferior del rectngulo, cuando se expande el rectngulo redondeado permite mostrar todos los objetos de flujo, los objetos de conexin, y artefactos. Tiene, de forma auto-contenida, sus propios eventos de inicio y fin; y los flujos de proceso del proceso padre no deben cruzar la frontera.

Compuertas (Control de Flujo)Se representan por una figura de diamante y determinan si se bifurcan o se combinan las rutas dependiendo de las condiciones expresadas.

Objetos de conexinpermitirn conectar cada uno de losobjetos de flujo. Hay tres tipos: Secuencias, Mensajes y Asociaciones. Flujo de SecuenciaEst representado por lnea simple continua y flechada; y muestra el orden en que las actividades se llevarn a cabo. Elflujo de secuenciapuede tener un smbolo al inicio, un pequeo diamante indica uno de un nmero deflujos condicionalesdesde una actividad, mientras que una barra diagonal (slash) indica elflujo por defectodesde una decisin o actividad con flujos condicionales.Flujo de MensajeEst representado por una lnea discontinua con un crculo no relleno al inicio y una punta de flecha no rellena al final. Esto nos dice, que el flujo de mensaje atraviesa la frontera organizativa (por ejemplo, entre piscinas). Un flujo de mensaje no puede ser utilizado para conectar actividades o eventos dentro de la misma piscina

AsociacionesSe representan por una lnea punteada. Se suele usar para conectar artefactos o un texto a un objeto de flujo y puede indicar muchas direccionalidades usando una punta de flecha no rellena (hacia el artefacto ). La no direccionabilidad podra usarse con el artefacto o un texto est asociado con una secuencia o flujo de mensaje

LosCarriles de Nadoson un mecanismo visual de actividades organizadas y categorizadas, basados en organigramas funcionales cruzados y enBPMNconsta de dos tipos:PiscinaRepresenta los participantes principales de un proceso, por lo general, separados por las diferentes organizaciones. Una piscina contiene uno o ms carriles (en la vida real, como una piscina olmpica). Una piscina puede ser abierta (por ejemplo, mostrar el detalle interno), cuando se presenta como un gran rectngulo que muestra uno o ms carriles, o cerrada (por ejemplo, esconder el detalle interno), cuando se presenta como un rectngulo vaco que se extiende a lo ancho o alto del diagrama.

CarrilUsado para organizar y categorizar las actividades dentro de una piscina de acuerdo a su funcin o rol; y se presenta como un rectngulo estrecho de ancho o de alto de la piscina. Un carril contiene objetos de flujo, objetos de conexin y artefactos.

LosArtefactospermiten a los desarrolladores llevar algo ms de informacin al modelo o diagrama. De esta manera, el modelo o diagrama se hace ms legible. Son tres artefactos predefinidos y son:Objetos de DatosMuestra al lector cual es el dato que deber ser requerido o producido en una actividad.

GruposSe representan por un rectngulo de lneas discontinuas y vrtices redondeados. El Grupo se utiliza para agrupar diferentes actividades pero no afecta al flujo dentro de un diagrama.

AnotacinSe utiliza para darle al lector una descripcin entendible del modelo o diagrama

EJEMPLO

Conclusin

Como conclusin se puede entender que trabajar con software tiene su grado de dificultad y todo lleva un proceso, es muy bueno que mtodos habituales como modelos nutran la administracin y las practicas tcnicas deficientes de programadores y teniendo un mejor enfoque de la empresa y sus procesos. Cabe destacar que el primer paso hacia la formulacin de soluciones prcticas para la ingeniera de software es el compromiso de las realidades en este campo.

Bibliografa

http://es.wikipedia.org/wiki/Business_Process_Model_and_Notationhttps://www.bizagi.com/docs/BPMNbyExampleSPA.pdfhttp://www.eduardoriol.com/cmmi-para-principiantes-y-iii/http://www.eduardoriol.com/cmmi-para-principiantes-i/http://www.itmadrid.com/blog/que-es-itil/http://www.notodocodigo.com/blog/paradigma-orientado-a-objetos/http://www.monografias.com/trabajos14/paradigma/paradigma.shtmlhttp://procesosoftware.wikispaces.com/Modelo+Espiralhttp://www.academia.edu/6362716/METODO_EN_CASCADAhttp://tema3isoftware.blogspot.com/p/modelos-de-desarrollo-tecnicas-y.htmlhttp://procesosoftware.wikispaces.com/Modelo+Incrementalhttp://es.slideshare.net/NesMey/paradigma-orientado-a-objetos-4954115