lunes, 22 de mayo de 2017

INTRODUCCIÓN A LOS PROCESOS ÁGILES DE DESARROLLO

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.


Uso de la herramienta Cake en el modelado Las herramientas Cake

Uso de la herramienta Cake en el modelado Las herramientas Cake (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas o programas informáticos destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.


domingo, 21 de mayo de 2017

Símbolos y Notaciones de los Diagramas

Diagramas, Símbolos y Notación
Un diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete.
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La información está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional.
Hay cuatro clases de construcciones gráficas que se usan en la notación de UML : íconos, símbolos bidimensionales, rutas y cadenas.
Un icono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas.
Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas.
Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. un segmento no debería existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos.
Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyacente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama.



Tipos de Diagrama de clases

Diagrama de clases

Ejemplo de diagrama de clases de una Universidad.
En ingeniería de software, un diagrama de clases enLenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.
Índice
  [ocultar] 
Miembros
UML proporciona mecanismos para representar los miembros de la clase, como atributos y métodos, así como información adicional sobre ellos.
Visibilidad
Para especificar la visibilidad de un miembro de la clase (es decir, cualquier atributo o método), se coloca uno de los siguientes signos delante de ese miembro:

+
Público
-
Privado
#
Protegido
/
Derivado (se puede combinar con otro)
~
Paquete

Ámbitos
UML especifica dos tipos de ámbitos para los miembros: instancias y clasificadores y estos últimos se representan connombres subrayados.
  • Los miembros clasificadores se denotan comúnmente como “estáticos” en muchos lenguajes de programación. Su ámbito es la propia clase.
    • Los valores de los atributos son los mismos en todas las instancias
    • La invocación de métodos no afecta al estado de las instancias
  • Los miembros instancias tienen como ámbito una instancia específica.
    • Los valores de los atributos pueden variar entre instancias
    • La invocación de métodos puede afectar al estado de las instancias(es decir, cambiar el valor de sus atributos)
Para indicar que un miembro posee un ámbito de clasificador, hay que subrayar su nombre. De lo contrario, se asume por defecto que tendrá ámbito de instancia.
Relaciones

Una relación es un término general que abarca los tipos específicos de conexiones lógicas que se pueden encontrar en los diagramas de clases y objetos. UML presenta las siguientes relaciones:
Relaciones a nivel de instancia

Enlace

Un enlace es la relación más básica entre objetos.
Asociación



Ejemplo de diagrama de clases con una asociación de dos clases (en inglés)
Una asociación representa a una familia de enlaces. Una asociación binaria (entre dos clases) normalmente se representa con una línea continua. Una misma asociación puede relacionar cualquier número de clases. Una asociación que relacione tres clases se llama asociación ternaria.
A una asociación se le puede asignar un nombre, y en sus extremos se puede hacer indicaciones, como el rol que desempeña la asociación, los nombres de las clases relacionadas, su multiplicidad, su visibilidad, y otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional, agregación (en la que se incluye la composición) y reflexiva. Las asociaciones unidireccional y bidireccional son las más comunes.
Por ejemplo, una clase vuelo se asocia con una clase avión de forma bidireccional. La asociación representa la relación estática que comparten los objetos de ambas clases.
Agregación



Ejemplo de diagrama de clases con una agregación entre dos clases (en inglés)
La agregación es una variante de la relación de asociación “tiene un”: la agregación es más específica que la asociación. Se trata de una asociación que representa una relación de tipo parte-todo o parte-de.
Como se puede ver en la imagen del ejemplo (en inglés), un Profesor 'tiene una' clase a la que enseña.
Al ser un tipo de asociación, una agregación puede tener un nombre y las mismas indicaciones en los extremos de la línea. Sin embargo, una agregación no puede incluir más de dos clases; debe ser una asociación binaria.
Una agregación se puede dar cuando una clase es una colección o un contenedor de otras clases, pero a su vez, el tiempo de vida de las clases contenidas no tienen una dependencia fuerte del tiempo de vida de la clase contenedora (deel todo). Es decir, el contenido de la clase contenedora no se destruye automáticamente cuando desaparece dicha clase.
En UML, se representa gráficamente con un rombo hueco junto a la clase contenedora con una línea que lo conecta a la clase contenida. Todo este conjunto es, semánticamente, un objeto extendido que es tratado como una única unidad en muchas operaciones, aunque físicamente está hecho de varios objetos más pequeños.
Diagramas[editar]
  • El diagrama de clases puede tener como ejemplo: una clase que seria un objeto o persona misma en la cual se especifica cada acción y especificación.
  • Propiedades de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.
  • El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.
  • Presenta las clases del sistema con sus relaciones estructurales y de herencia.
  • El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.


Elementos para interpretar el modelado del software

El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el Object Management Group (OMG).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado RacionalRational Unified Process o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que programación estructurada es una forma de programar como lo es la orientación a objetos, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML solo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.



PROCESO UNIFICADO DE DESARROLLO
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 JacobsonGrady 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 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.

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.                              






Metodología Empleada en el Proceso de Desarrollo del 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.


viernes, 19 de mayo de 2017

Desarrollo de Componentes

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.




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




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





Tipos de Componentes y Caraterísticas


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


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.


Fundamentos del Enfoque Orientado a Objetos y Caraterísticas

La orientación a objetos ofrece una solución que ayuda a los desarrolladores a hacer corresponder el mundo real tan cerca como sea posible al dominio de la solución. Cabe mencionar que existen muchas metodologías que permiten soluciones para problemas complejos. En la orientada a objetos se basa en modelar el mundo real y ha ganado importancia significativa en los últimos tiempos. En la orientación a objetos se trabaja con objetos en el sistema que interactúan unos con otros a través de mensajes. La orientación a objetos proporciona los recursos para ocuparse de los objetos de un sistema complejo. 
El análisis y diseño de un sistema desde una perspectiva orientada a objetos forma el núcleo de un sistema.
                                           



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


jueves, 18 de mayo de 2017

Proceso de Desarrollo del 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.

Después de haber discutido las características del proceso de desarrollo de software, se presenta a continuación las diferentes fases del proceso de desarrollo de software.

  • Fase de definición esta fase se concentra principalmente en que tiene que ser completado por el proceso de software.
  • Fase de desarrollo esta fase enfoca en el cómo los requerimientos de un sistema y el software serán completados.
  • Fase de mantenimiento esta fase se enfoca en cambio, el mantenimiento incluye la corrección de errores y la adaptación, conforme evoluciona el entorno del software.