República Bolivariana de Venezuela

Ministerio de poder popular para la educación Universitaria

Universidad Politécnica Territorial José Antonio Anzoátegui

(UPTJAA)

Proceso de Desarrollo de Software

Profesor : Integrantes:

Ing. Luis Cayamo Hernández Centeno Andrés José

C.I. N°: 26.009.783

Llovera Martínez Betzimar María

C.I. N°:26.632.527
 Proceso de Desarrollo de Software: 

Un proceso, se define como una serie de operaciones usadas en la creación de un

producto. Un proceso de software se puede definir de las siguientes formas:

Un proceso de software define el conjunto de tareas, que tienen que ser realizadas
para producir un producto de software de alta calidad. En otras palabras, este es
el enfoque que se toma para el desarrollo del software.

Es el proceso que se sigue para construir el producto de software desde la

concepción de una idea, hasta la entrega y el retiro final del sistema.

Las características de un proceso de software se resumen a continuación:

 Comprensión: Este requiere claridad y declaración de la naturaleza explicita

de la definición del proceso.

 Visibilidad: Se refiere a la capacidad de observar la salida de arias

actividades del proceso, de manera que se mida el proceso del progreso.
 Confiabilidad: Se refiere a la capacidad del proceso para evadir errores o
detectar errores y manejarlos antes de que estos avancen en el producto.

 Robustez: Se refiere a la capacidad del proceso de no detenerse a pesar de

problemas inesperados.

 Facilidad de mantenimiento: Se refiere a la cantidad de modificaciones que

pueden hacerse al sistema de software sin introducir errores.

 Facilidad de verificación: Un proceso es verificable si sus propiedades

pueden ser fácilmente verificadas.

 Rapidez: Se refiere a la agilidad y rapidez del proceso para ser capaz de

entregar un producto final a partir de las especificaciones.

 Facilidad de soporte: Se refiere a la posibilidad de que las actividades del

proceso sean soportadas por un conjunto de herramientas automatizadas.

 Facilidad de aceptación: Se refiere a la capacidad del proceso a ser

aceptado y usado por el equipo de ingenieros.
  Facilidad de adaptación: Se refiere a la capacidad del proceso a ser
modificado para satisfacer las necesidades de cambio en el ambiente de
desarrollo.

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 y la Herencia.

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
[Link] 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 [Link] 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 [Link] 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).

Características:
 Modelado del mundo real
 Datos Abstractos
 Abstracción de datos
 Encapsulamiento
  Ocultamiento de la información
 Clase
 Objeto
 Interfaz e Implementación
 Métodos
 Mensajes
 Herencia
 Agregación
 Polimorfismo
 Tipo
 Rol
 Paquete

Tipos de Componentes y caraterísticas:

1. 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.

2. 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
[Link] y [Link].

3. 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.
 Características:

-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.

Está ndares 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

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

PROCESO UNIFICADO DE DESARROLLO:

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.

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.
 FASES:

El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su

mejor desarrollo. Estas fases ayudando tanto a la elaboración como a la
resolución de problemas.

 Inicio
En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se
presenta un modelo, visión, metas, deseos del usuario, plazos, costos y
viabilidad.

 Elaboración
En esta fase se obtiene la visión refinada del proyecto a realizar, la
implementación iterativa del núcleo de la aplicación, la resolución de
riesgos altos, nuevos requisitos y se ajustan las estimaciones.

 Construcción
Esta abarca la evolución hasta convertirse en producto listo incluyendo
requisitos mínimos. Aquí se afinan los detalles menores como los diferentes
tipos de casos o los riesgos menores
.
 Transición
En esta fase final, el programa debe estar listo para ser probado, instalado
y utilizado por el cliente sin ningún problema. Una vez finalizada esta fase,
se debe comenzar a pensar en futuras novedades para la misma.
Desde el punto de vista Técnico: el proyecto está formado por los flujos de
trabajo fundamentales: captura de requerimientos, análisis, diseño,
implementación y pruebas.
Tantos el punto de vista Gerencial como el Técnico concuerdan en: La
iteración .

Disciplinas:

Las disciplinas se dividen en dos categorías, las de procesos y las de soporte. 

A continuación se detalla de las disciplinas con el desglose de los artefactos que se
construirán en cada diciplina. 

 Disciplinas de proceso: 

•Modelado de negocio 
-Presentación del proyecto 
-Proceso del Negocio 
-Documento de Cruce: Proceso-Actividad-CNU 
-Modelo de dominio de negocio 
-Glosario Organizacional 

•Requerimientos 
-Documento de relevamiento 
-Especificación de requerimientos (funcionales, no funcionales) 

•Análisis 
-Casos de uso trazo Grueso 
-Casos de uso trazo fino 
-Prototipo de pantalla 
-Documento de trazabilidad de Proceso-Actividad-CUN 
-Modelo de análisis (Diagrama de secuencia, Diagrama de Clases) 

•Diseño 
-Modelo de datos (DER) 
-Modelado de diseño 
-Definición de Arquitectura 

 Disciplinas de soporte: 

•Gestión del calidad 

-Plan de calidad 
-Revisión técnica formal o por pares (RTF) 
-Checklist de verificación 

•Gestión de cambio y configuraciones 

-Documento de configuración 
-Documento de trazabilidad 

 Gestión de proyecto 
 -Plan del proyecto 
-Minutas de reuniones con el cliente 
-Documento Post-mortem 

Introducció n a los Procesos Á giles de Desarrollo:

 El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería
de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de
vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza
riesgos desarrollando software en cortos lapsos de tiempo. El software
desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar
de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación,
análisis de requerimientos, diseño, codificación, revisión y documentación. Una
iteración 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 iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades
del proyecto. Los métodos ágiles enfatizan las comunicaciones cara a cara en vez
de la documentación. La mayoría de los equipos ágiles están localizados en una
simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en
inglés). La oficina debe incluir revisores, escritores de documentación y ayuda,
diseñadores de iteración y directores de proyecto. Los métodos ágiles también
enfatizan que el software funcional es la primera medida del progreso. Combinado
con la preferencia por las comunicaciones cara a cara, generalmente los métodos
ágiles son criticados y tratados como "indisciplinados" por la falta de
documentación técnica.

FUNDAMENTOS DE LOS PROCESOS Á GILES DE DESARROLLO:

  El auge de la tecnología, y el objetivo de agilizar y automatizar los procesos en el
desarrollo de software, llevan a la necesidad de implantar Metodologías de
Desarrollo de Software que ayuden a entregar un producto de calidad en tiempo y
costo estimados, las metodologías ágiles de desarrollo de software han
despertado interés gracias a que proponen simplicidad y velocidad para crear
sistemas. Entre los Elementos claves de los procesos ágiles de desarrollo
tenemos:

-Análisis como una actividad constante

-Simplicidad
-Poca documentación
-Testeos diarios
-Integraciones
-Diseño evolutivo
Algunos métodos ágiles de desarrollo de software:
Crystal Clear
Proceso Unificado de Rational (RUP)
Essential Unified Process (EssUP)
Feature Driven Development (FDD)

Introducció n al Modelado:
 El auge de la tecnología, y el objetivo de agilizar y automatizar los procesos en el
desarrollo de software, llevan a la necesidad de implantar Metodologías de
Desarrollo de Software que ayuden a entregar un producto de calidad en tiempo y
costo estimados, las metodologías ágiles de desarrollo de software han
despertado interés gracias a que proponen simplicidad y velocidad para crear
sistemas. Entre los Elementos claves de los procesos ágiles de desarrollo
tenemos:

Características:
-Iterativo e Incremental
-Dirigido por los casos de uso
-Enfocado en los riesgos
-Centrado en la arquitectura

El Lenguaje de Modelado Unificado (UML)

Una exigencia de la gran mayoría de instituciones dentro  de su Plan Informático

estratégico, es que los desarrollos de software bajo una arquitectura en Capas, se
formalicen con un lenguaje estándar y unificado.

Es decir, se requiere  que cada una de las partes que comprende el desarrollo de
todo software de diseño orientado a objetos, se visualice, especifique y documente
con lenguaje común.

Se necesitaba un lenguaje que fuese  gráfico, a fin de especificar y documentar un

sistema de software, de un modo estándar incluyendo aspectos conceptuales tales
como procesos de negocios y funciones del sistema.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente

UML, el cual cuenta con una notación estándar y semánticas esenciales para el
modelado de un sistema orientado a objetos.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los

métodos para expresar un diseño. El proceso indica los pasos que se deben
seguir para llegar a un diseño. La estandarización de un lenguaje de modelado es
invaluable, ya que es la parte principal del proceso de comunicación que requieren
todos los agentes involucrados en un proyecto informático. Si se quiere discutir un
diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así
el proceso que se siguió para obtenerlo.