Republica Bolivariana de Venezuela.

Ministerio del Poder Popular para la Educaion Universitaria.

Fundacion Mision Sucre.

Aldea Universitaria U.E.N:"Dr.Jesus Maria Portillo."

Fines de Semana.

Municipio Baralt,Edo.Zulia.

Unidad Curricular:Ingenieria del Software.

Trayecto II-I

Unidad III

PROCESO DE DESARROLLO DE SOFTWARE

Profesora: ING.Yilmaris Villasmil

Triunfador:Br.Julio Hernandez

Mene Grande:Viernes 30 de Junio de 2023.

INDICE

1).Introduccion

2).Fundamentos del Enfoque Orientado a Objetos

3).Caracteristicas

4).Desarrollo de Componentes

5).Tipos de Componentes

6).Caracteristicas de los Componentes

7).Estandares en el Proceso de Desarrollo de software

8).Documentacion y Artefactos

9).Metodologias Empleadas:Proceso Unificado de Desarrollo(UP del ingles Unified Process)

10).Fases de Desarrollo

11).Disciplinas

12).Conclucion

13).Bibliografia

INTRODUCCION

El Proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software, es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral. La gran cantidad de organizaciones de desarrollo de software implementan metodologías para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato.

El estándar internacional que regula el método de selección, implementación y monitoreo del ciclo de vida del software es ISO 12207.

Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión de proyectos para la creación del software. Sin una gestión del proyecto, los proyectos de software corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en términos de funcionalidad, costes o tiempo de entrega, una gestión de proyectos efectiva es algo imprescindible.

Algunas organizaciones crean un grupo propio (Software Engineering Process Group, abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la organización.

1).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 Abstracción, el Encapsulamiento, la Modularidad, la Herencia y Polimorfismo.

Fundamento 1: Abstracción

Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son relevantes, con el objetivo de concentrarse en aquellos que si lo son. Una abstracción denota las características 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 diseño orientado a objetos.

Los mecanismos de abstracción son usados en el EOO para extraer y definir del medio a modelar, sus características y su comportamiento. Dentro del EOO son muy usados mecanismos de abstracción: la Generalización, la Agregación y la clasificación.

· La generalización es el mecanismo de abstracción 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 través de la generalización, la superclase almacena datos generales de las subclases, y las subclases almacenan sólo datos particulares. La especialización es lo contrario de la generalización. Por ejemplo; La clase Médico es una especialización de la clase Persona, y a su vez, la clase Pediatra es una especialización de la superclase Médico.

· La agregación es el mecanismo de abstracción por el cual una clase de objeto es definida a partir de sus partes (otras clases de objetos). Mediante agregación se puede definir por ejemplo un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos periféricos. El contrario de agregación es la descomposición.

· La clasificación consiste en la definición de una clase a partir de un conjunto de objetos que tienen un comportamiento similar. La ejemplificación es lo contrario a la clasificación, y corresponde a la instanciación 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 representación 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 información separando el aspecto correspondiente a la especificación de la implementación; de esta forma, distingue el "qué hacer" del "cómo hacer". La especificación es visible al usuario, mientras que la implementación se le oculta. El encapsulamiento en un sistema orientado a objeto se representa en cada clase u objeto, definiendo sus atributos y métodos con los siguientes modos de acceso:

· Público (+): Atributos o Métodos que son accesibles fuera de la clase. Pueden ser llamados por cualquier clase, aun si no está relacionada con ella.

· Privado (-): Atributos o Métodos que solo son accesibles dentro de la implementación de la clase.

· Protegido (#): Atributos o Métodos que son accesibles para la propia clase y sus clases hijas (subclases).

Los atributos y los métodos que son públicos 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 métodos, incluyendo entonces algunos de consulta para ver los valores de los atributos. El método constructor (Nuevo, New) siempre es Público.

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 módulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros módulos. En un mismo módulo se suele colocar clases y objetos que guarden una estrecha relación. El sentido de modularidad está muy relacionado con el ocultamiento de información.

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 jerarquía de clasificaciones. Permite la definición de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programación Diferencial), evitando repetición de código y permitiendo la reusabilidad.

Las clases heredan los datos y métodos de la superclase. Un método heredado puede ser sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple (cada clase tiene sólo una superclase) o múltiple (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 múltiple).

Fundamento 5: Polimorfismo

Es una propiedad del EOO que permite que un método tenga múltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecución del método. El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o están relacionados en términos de inclusión. En este tipo de polimorfismo, los métodos son interpretados en el contexto del objeto particular, ya que los métodos con nombres comunes son implementados de diferente manera dependiendo de cada clase.

Por ejemplo, el área de un cuadrado, rectángulo y círculo, son calculados de manera distinta; sin embargo, en sus clases respectivas puede existir la implementación del área bajo el nombre común Área. En la práctica y dependiendo del objeto que llame al método, se usará el código correspondiente.

Ejemplos:

Superclase: Clase Animal

Subclases: Clases Mamífero, Ave, Pez.

Se puede definir un método Comer en cada subclase, cuya implementación cambia de acuerdo a la clase invocada, sin embargo el nombre del método 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 numéricos, el operador + significa suma algebraica de los mismos, en cambio si por lo menos uno de los operandos es un String o Carácter, el operador es la concatenación de cadenas de caracteres.

2).Caracteristicas: Las características siguientes son las más importantes:

· Abstracción: Denota las características 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 cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño 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 abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

· Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

· Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos 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 abstracción. La aplicación entera se reduce a un agregado o rompecabezas de 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 invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

· Herencia: Las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. 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 común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

· Recolección de basura: La recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, 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 asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

APLICABILIDAD ORIENTADA A OBJETOS.

A lo largo de la historia de la programación, los lenguajes y las metodologías han pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de programación orientados a objetos pretenden aportar simplicidad a la tarea de programación de grandes aplicaciones.

Cuando se crearon las primeras computadoras todavía no existían los lenguajes de programación, tal como ahora los entendemos. El lenguaje ensamblador puede considerarse como el primer lenguaje de programación propiamente dicho. Permitía al usuario un diálogo más fluido con la máquina a través de instrucciones que tenían relación directa con el conjunto de operaciones que la máquina podía realizar.

A partir de este momento empezó la evolución de los lenguajes de programación. _cada uno tenía su entorno definido y aunque en realidad todos los lenguajes son polivalentes (en teoría, con cualquiera de ellos se puede desarrollar cualquier programa de gestión o científico). Pronto apareció la especialización funcional. Así, COBOL (Common Business Orientated Language) se introdujo como lenguaje mainframe para el diseño de aplicaciones de gestión.; FORTRAN (Formula Translator) para el diseño de aplicaciones científicas; APL (A Programming Language) para el cálculo matemático, etc.

A medida que el software tomaba importancia, aparecieron los primeros problemas relacionados con la programación. Al tiempo que aumenta elvolumen de un programa, disminuye el control del mismo por parte del programador y la capacidad de este de dar mantenimiento.

En un intento de solucionar estos problemas aparecen las metodologías de programación. Una metodología es un conjunto de reglas destinadas a simplificar las tareas de diseño, estimación de costes, desarrollo y mantenimiento de un sistema informático. A menudo se ven acompañadas con unas herramientas (CASE: Computer Aided Software Engeneering) que permiten la elaboración estructurada y documentada de los sistemas informáticos.

DISEÑO DE APLICACIONES Y ELECCIÓN DE ENTORNO.

En entorno de programación implica tanto el lenguaje de programación como al empleo de una determinada metodología.

Los lenguajes de programación no se producen por generación espontánea y se ven influidos en gran manera por la forma en la que los profesionales piensan que se debe programar. De esta manera se crea un conjunto de reglas para simplificar la tarea de programación. Generalizadas y codificadas, se convierten en <<principios>> de los que surgen los lenguajes de programación en un afán por darles soporte.

Estos <<principios>> son modelos que proporcionan técnicas que , a su vez, deben aplicarse en el diseño e implementación de los programas. Estas técnicas nos indican la forma de resolver los distintos problemas que surgen a la hora de programar.

Decimos que un lenguaje de programación <<soporta>> un conjunto de <<principios>> si el lenguaje simplifica la aplicación de estas técnicas. A estos <<principios>> se les denomina metodologías de programación.

Las metodologías de programación son modelos sobre como diseñar e implementar los programas. Diferentes modelos tienen como resultado diferentes técnicas. Que cada técnica sea distinta no implica que una sea la verdadera y que las demás falsas. Por el contrario, las metodologías se complementan entre sí. Lo que todas las metodologías tienen en común es la premisa de que hay que partir de abstracciones que corresponden a elementos del problema a resolver, y que la implementación de la solución se debe realizar mediante un conjunto de módulos preferiblemente reutilizables.

Las metodologías orientadas a objetos se centran en las estructuras de datos que sin embargo se relegan a un segundo plano en los modelos procedurales. La base de esta metodología es que una estructura de datos debe contener las operaciones que los modifican. La técnica que se utiliza para obtener esta <<abstracción de datos>> es la encapsulación de los mismos en una estructura conocida como clase.

El accesos a los datos contenidos en la clase se realiza mediante las operaciones que la propia clase define. Por tanto, la metodología orientada a objetos complementa el punto de vista procedural de operaciones realizadas sobre un flujo de datos, al asociar a cada dato el conjunto de operaciones que lo modifican. Como podrá ver, ambos enfoques son complementarios.

Para ilustrar las diferencias entre las aproximaciones orientadas a procedimientos y las orientadas a objetos, considere el diseño de un <<compilador>>

El compilador es un programa que a partir de un conjunto de fichero fuente (programa) construye el código objeto que posteriormente se convierte en programa. Para realizar su trabajo, el compilador lee el fichero fuente y separa de él las variables y las instrucciones. Las variables constituyen la tabla de símbolos del programa, mientras que las instrucciones se organizan en un árbol sintáctico donde se plasman todas la referencias que realizan los mandatos y funciones entre sí.

El modelo mejor establecido es el basado en funciones (procedural) que trata de la construcción de un programa como una colección de funciones. Las metodologías proporcionan una gruía sobre cómo diseñar, organizar e implementar las funciones que componen un programa.

La programación orientada a objetos está basada en un modelo de construcciones de programas como un conjunto de clases. El diseño orientado a objetos identifica los tipos que representan los distintos objetos en el programa. Las operaciones a realizar con cada uno delos objetos son, al igual que en el modelo procedural, los pasos destinados a solucionar el problema. El objeto sirve además de módulo que puede reutilizarse para la solución de un problema de similares características en otro programa.

Ninguna metodología resuelve con acierto todos los tipos de problemas. La programación requiere una especialización como la que se produce en la ingeniería pero todavía no es posible identificarla como una ciencia. Las técnicas a emplear se han de utilizar con exquisito cuidado, sin perder de vista el objetivo de resolver un determinado problema.

Actualmente existe la tendencia de identificar la programación con una disciplina Como la ingeniería. Sin embargo, debe considerarse más como un arte como la arquitectura, donde se unen la inspiración y el dominio de la técnica.

Para la elección de un determinado entorno debemos fijar los criterios necesarios, como los que describimos a continuación.:

Tamaño de la aplicación.

Cuanto mayor sea el volumen de información a procesar, mas necesidad habrá de estructurar dicha información de forma que se fácil su manipulación.

3).Desarrollo de Componentes:

Un componente de software es una unidad modular de un programa software con interfaces y dependencias bien definidas que permiten ofertar o solicitar un conjunto de servicios o funcionales. La programación orientada a componentes (que también es llamada basada en componentes) es una rama de la ingeniería del software, con énfasis en la descomposición de sistemas ya conformados en componentes funcionales o lógicos con interfaces bien definidas usadas para la comunicación entre componentes.

Se considera que el nivel de abstracción de los componentes es más alto que el de los objetos y por lo tanto no comparten un estado y se comunican intercambiando mensajes que contienen datos.

Cuando se necesita el acceso a un componente o cuando este debe ser compartido entre distintas redes, se recurre a procesos como la serialización para entregar el componente a su destino.

La capacidad de ser reutilizado (reusability), es una característica importante de los componentes de software de alta calidad. Un componente debe ser diseñado e implementado de tal forma que pueda ser reutilizado en muchos programas diferentes.

Requiere gran esfuerzo y atención escribir un componente que es realmente reutilizable. Para esto, el componente debe estar:

Completamente documentado.
Probado intensivamente:

Debe ser robusto, comprobando la validez de las entradas.
Debe ser capaz de pasar mensajes de error apropiados.

Diseñado pensando en que será usado de maneras imprevistas.

Otras características incluyen:

Ser intercambiable.
Poseer interfaces definidas.
Ser cohesivos.

Es una unidad autocontenida que encapsula el estado y el comportamiento de varios clasificadores. También se podría decir que es un tipo clasificador con la diferencia de que no tiene características propias, pero contiene las clases que definen las características. Un componente proporciona una vista encapsulada de la funcionalidad definida por las clases contenidas. Un componente es una parte física del sistema. Cada componente tiene un nombre, el cual puede ser un nombre simple o un nombre de ruta.

4.Tipos de Componentes:

Componentes de despliegue o distribución (Deployment)

Estos componentes se usan para formar un sistema ejecutable. Un ejemplo de tal componente es la librería de enlace dinámico y los archivos ejecutables. Otros ejemplos son los componentes COM+, Enterprise Java Beans, componentes CORBA y objetos de base de datos.

Componentes de Producto de Trabajo

Estos componentes son parte del proceso de desarrollo que es esencial para el sistema. Algunos ejemplos de componentes de producto de trabajo son los archivos fuente, archivos de datos y tablas. Ellos son los archivos fuente y archivos de datos que se usan para crear los componentes de distribución como AgenteAnalizado.Java y AnalizadorDatos.txt.

Componentes de Ejecución

Estos componentes son el resultado de un sistema que se está ejecutando. Cuando un DLL es instanciado como un componente COM+, es un ejemplo de un componente de ejecución.

5).Cracteristicas de los Componentes:

 - La característica fundamental de un componente es la habilidad de definir interfaces.

- Es una unidad ejecutable que puede ser implantada independientemente.

 - Puede ser sujeto de composición por terceras partes, es decir, una compañía o un desarrollador puede llegar y tomar el componente y agregarlo a lo que esté haciendo, o sea haría una composición de componentes.

- Un componente no tiene estado.

 - Se puede tomar a los componentes de software como una analogía a los componentes electrónicos.

6).Estandares en el Proceso de Desarrollo de Software:

ISO Es el organismo encargado de promover el desarrollo de normas internacionales de fabricación, comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica. Su función principal es la de buscar la estandarización de normas de productos y seguridad para las empresas u organizaciones a nivel internacional. Estándares ISO existentes: ISO 9001, 9000–3, 9004–2, ISO/IEC 12207, ISO/IEC 15504 (SPICE) Algunos estándares existentes:

Estándares para datos

Estándares de codificación

Estándares estructurales

Estándares de documentación

Estándares de proceso software

Estándares para otras actividades

Ejemplos de estándares en ingeniería del software

IEEE Standards Collection Software Engineering – 1998 Edition

IEEE Std. 610.12-1990, Glossary of Software Engineering Terminology

IEEE Std. 829-1983, Standard for Software Test Documentation

IEEE Std. 830-1993, Recommended Practice for Software Requirements Specifications.

IEEE Std. 990-1987, Recommended Practice for Ada as a Program Design Language.

IEEE Std. 1045-1992, Standard for Software Productivity Metrics

IEEE Std. 1062-1987, Recommended Practice for Software Acquisition

IEEE Std. 1063- 1987, Standard for Software User Documentation

IEEE Std. 1219-1992, Standard for Software Maintenance.

7).Documentacion y Artefactos:

La documentación no es más que la debilidad más frecuente en productos e instalaciones informáticos. Cabe mencionar que los actores que intervienen en el ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.

Un artefacto es una pieza de información 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 visión o la lista de riesgos.

Un modelo, por ejemplo un diagrama de casos de uso o el modelo de diseño.

Un elemento dentro de un modelo, tal como una clase, un caso de uso o un subsistema.

Ejecutables, por ejemplo el ejecutable del prototipo.

Código fuente.

Las actividades tienen artefactos como entrada y salida. Los roles usan artefactos para ejecutar actividades y producen artefactos durante la ejecución de sus actividades. Los artefactos son la responsabilidad sencilla del rol, creando responsabilidades fáciles de identificar y entender, promoviendo la idea de que cada pieza de información 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 podrían 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 análisis y diseño, la implementación, las pruebas, la configuración y administración de cambios, el ambiente de desarrollo, entre otros.

8).Metodologias Empleadas:

-Proceso Unificado de Desarrollo(UP del ingles Unified Process)

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también 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 nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

Características

Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. El proceso dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

Lenguaje unificado de modelado

El Lenguaje unificado de modelado no es el sucesor de la oleada de metodos de analisis y diseno orientados a objetos que surgio a finales de la decada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los metodos de Booch, Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance ha llegado a formar parte fundamental de la Ingeniería de Software tras su estandarización en 1997 con el OMG (Object Management Group o Grupo de administracion de objetos).

¿Por qué analizar y diseñar?

En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del código. Después de todo, los diagramas son solo imagenes bonitas. Ningun usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, Pag 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qué lo hará y como le ayudara a usted cuando llegue el momento de escribir el codigo. No existe una evidencia empirica adecuada que demuestre si estas tecnicas son buenas o malas; Pero lo que si es cierto es que es de considerable ayuda para las etapas de mantenimiento en proyectos de mediana/avanzada envergadura.

La metodología de UP, es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria.

El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto.

9).Fases de Desarrollo:

Fase de Inicio.

· Es la fase más pequeña del proyecto e, idealmente, debe realizarse también en un periodo de tiempo pequeño (una única iteración).

· El hecho de llevar a cabo una fase de inicio muy larga indica que se esta realizando una especificación previa excesiva, lo que responde más a un modelo en cascada.

· Objetivos:

o   Establecer una justificación para el proyecto.
o   Establecer el ámbito del proyecto.
o   Esbozar los casos de uso y los requisitos clave que dirigirán las decisiones de diseño.
o   Esbozar las arquitecturas candidatas.
o   Identificar riesgos.
o   Preparar el plan del proyecto y la estimación de costes.

· El hito de final de fase se conoce como Hito Objetivo del Ciclo de Vida.

Fase de Elaboración.

· Durante esta fase se capturan la mayoría de los requisitos del sistema.

· Los objetivos principales de esta fase serán la identificación de riesgos y establecer y validar la arquitectura del sistema.

· Base de Arquitectura Ejecutable:

· La arquitectura se valida a través de la implementación de una Base de Arquitectura Ejecutable: se trata de una implementación parcial del sistema que incluye los componentes principales del mismo.
· Al final de la fase de elaboración la base de arquitectura ejecutable debe demostrar que soporta los aspectos clave de la funcionalidad del sistema y que muestra la conducta adecuada en términos de rendimiento, escalabilidad y coste.

· Al final de la fase se elabora un plan para la fase de construcción.

· El hito arquitectura del ciclo de vida marca el final de la fase.

Fase de construcción.

· Es la fase más larga de proyecto.

· El sistema es construido en base a lo especificado en la fase de elaboración.

· Las características del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo.

· El resultado de cada iteración es una versión ejecutable de software.

· El hito de capacidad operativa inicial marca el final de la fase.

Fase de transición.

· En esta fase el sistema es desplegado para los usuarios finales.

· La retroalimentación recibida permite incorporar refinamientos al sistema en las sucesivas iteraciones.

· Esta iteración también cubre el entrenamiento de los usuarios para la utilización del sistema.

· El hito de lanzamiento del producto marca el final de la fase.

10).Disciplinas:

Modelado del negocio.

· El objetivo es establecer un canal de comunicación entre los ingenieros del negocio y los ingenieros del software.

· Los ingenieros del software deben conocer la estructura y dinámica de la organización objetivo (el cliente), los problemas actuales y sus posibles mejoras.

· Se plasma en la identificación del modelo del dominio en el que se visualizan los aspectos básicos del dominio de aplicación.

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 descripción.

Análisis y diseño.

· Describe como el software será realizado en la fase de implementación.

· Se plasma en un modelo de diseño que consiste en una serie de clases (agrupadas en paquetes y subsistemas) con interfaces bien definidos.

· También contiene descripciones de cómo los objetos colaboran para realizar las acciones incluidas en los casos de uso.

Implementación.

· Se implementan las clases y objetos en términos de componentes (ficheros fuentes, binarios, ejecutables, entre otros).

Prueba.

· Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los objetos como unidades, la integración entre objetos, la implementación de todos los requisitos, entre otros.

Despliegue.

· Se crea la versión externa del producto, se empaqueta, se distribuye y se instala en el lugar de trabajo. También se da asistencia y ayuda a los usuarios.

Gestión de configuraciones y cambios.

· Gestiona aspectos como los sistemas de control de versiones.

· Controla las peticiones de cambios clasificándolas según su estado (nueva, registrada, aprobada, asignada, completa, entre otros).

· Los datos se almacenan en una base de datos y se pueden obtener informes periódicos.

· Herramientas como Rational ClearQuest o Bugzilla.

Gestión del proyecto.

· Encargada de definir los planes del proyecto global, los planes de fase y los planes de iteración.

Entorno.

· Se centra en las actividades necesarias para configurar el proceso de un proyecto.

· El objetivo es proveer a la organización de desarrollo software de un entorno de trabajo (que incluye procedimientos y herramientas) que soporten al equipo de desarrollo.

Estructura del Proceso Unificado

Arquitectura lógica de tres capas de una aplicación cliente/servidor

CONCLUSION

El desarrollo de software es uno de los pilares fundamentales de la Informática y al cual se dedican muchas horas de esfuerzos en universidades, centros de investigación y empresas de todos los tamaños.

Conforme la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco mas fácil. También surgen nuevos modelos de proceso de desarrollo y nuevas metodologías que tratan de adaptar la manera de trabajar a las necesidades concretas de una organización y de sus proyectos. Es importante conocer bien estos modelos, para tener un esquema mental que nos permita gestionar proyectos y organizar equipos de manera racional, cuando abordemos el desarrollo de software, especialmente en el caso de aplicaciones grandes y complejas.

BIBLIOGRAFIA

- https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=0CAIQw7AJahcKEwiI7KjnqY-AAxUAAAAAHQAAAAAQAg&url=https%3A%2F%2Fes.wikipedia.org%2Fwiki%2FProceso_del_desarrollo_del_software&psig=AOvVaw2FUOFbNiVaY7uNbHfWCS1V&ust=1689461019527845&opi=89978449

- https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=0CAIQw7AJahcKEwiI7KjnqY-AAxUAAAAAHQAAAAAQBw&url=https%3A%2F%2Fdesarrolloweb.com%2Farticulos%2Fprocesos-desarrollo-software&psig=AOvVaw2FUOFbNiVaY7uNbHfWCS1V&ust=1689461019527845&opi=89978449

- https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=web&cd=&ved=0CAIQw7AJahcKEwiI7KjnqY-AAxUAAAAAHQAAAAAQCw&url=https%3A%2F%2Fintelequia.com%2Fblog%2Fpost%2Fciclo-de-vida-del-software-todo-lo-que-necesitas-saber&psig=AOvVaw2FUOFbNiVaY7uNbHfWCS1V&ust=1689461019527845&opi=89978449

TRAYECTO II-I /ALDEA PORTILLO

miércoles, 19 de julio de 2023

ELECTRONICA-REPARACION DE TV.

STV8172A = ECG 1788 =TDA8172A, TDA9302H, LA78040N, LA78041, LA78045,AN5522, STV9302B, LA78141, TDA8177, STV9325

viernes, 14 de julio de 2023

Unidad III-Proceso de Desarrollo de Software