Introducción a la gestión de procesos de software

Requerimientos: es una necesidad documentada. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto.

2. Documento de especificación de requerimientos: Es en documento donde se redactan los requerimientos funcionales y no funcionales de un proyecto estos nos sirven para conocer el modelo del negocio

3. Riesgo: Es la posibilidad de que ocurra un peligro que no permita el correcto funcionamiento del programa o la elaboración del proyecto.

4. Administración del riesgo: Es el gestionamiento  de los riesgos para eliminar o reducir la posibilidad de que ocurra un peligro que no permita el correcto funcionamiento del programa o la elaboración del proyecto.

5. Gestión del proceso de desarrollo de sistemas de software: Es administrar de manera adecuada los recursos con los que se cuentan para desarrollar el ciclo de vida de software en todas sus etapas desde el planeamiento,implementacion,pruebas.

.

6. Planeación de los recursos del proyecto de software, recursos recursos humanos, Procesos y metodologías, y herramientas y equipo: Es gestionar todos los recursos del proyecto tanto de software como de hadware con una planeación especifica esta puede ser por diagramas de actividades

7. Calendario o cronograma de actividades: calendario de trabajo o de actividades es una  muy importante herramienta en la gestión de proyectos. en el se anotan las actividades y quien lo realizara

8. Gráfica de Gantt: Es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de esto, el diagrama de Gantt no indica las relaciones existentes entre actividades

9. Método de ruta crítica - CPM.:(Crítical Path Method), el segundo origen del método actual, fue desarrollado también en 1957 en los Estados Unidos de América, por un centro de investigación de operaciones para la firma Dupont y Remington Rand, buscando el control y la optimización de los costos de operación mediante la planeación adecuada de las actividades componentes del proyecto

10. PERT:(Program Evaluation and Review Technique) desarrollo por la Armada de los Estados Unidos de América, en 1957, para controlar los tiempos de ejecución de las diversas actividades integrantes de los proyectos espaciales, por la necesidad de terminar cada una de ellas dentro de los intervalos de tiempo disponibles. Fue utilizado originalmente por el control de tiempos del proyecto Polaris y actualmente se utiliza en to

Tareas de análisis

El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo:

1.      Reconocimiento del problema

2.      Evaluación y síntesis

3.      Modelado

4.      Especificación

5.      Revisión

Todos los métodos de análisis se relacionan por un conjunto de principios operativos:

1.      Debe representarse y entenderse el dominio de la información de un problema.

2.      Deben definirse las funciones que debe realizar el software.

3.      Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos),

4.      Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente).

5.      El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.

Además de los principios operativos mencionados anteriormente, se sugiere un conjunto de principios directrices para la ingeniería de requerimientos:

           

1.      Entender el problema antes de empezar a crear el modelo de análisis.

2.      Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina.

3.      Registrar el orden y la razón de cada requerimiento,

4.      Usar múltiples planteamientos de requerimientos.

5.      Priorizar los requerimientos.

Tipos de requisitos

Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.

Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)

MATRIZ DE RIESGOS

Como sabéis, el primer paso en la gestión de estos riesgos suele ser realizar un inventario de todos los riesgos que pueden afectar a nuestra organización. Una vez obtenido este inventario de riesgos, se deben analizar para evitar riesgos duplicados o equivalentes, agrupar los riesgos por áreas para proponer planes de actuación y contingencia conjuntos y facilitar las tareas de monitorización posteriores.

Pero sobre todo para realizar una priorización que permita realizar una gestión ordenada y sistemática. Esta priorización suele realizarse mediante la construcción de una matriz de riesgos, en la que se representen claramente la probabilidad de ocurrencia de los riesgos y, al mismo tiempo, la gravedad de las consecuencias que acarrean (impacto o coste).

Este sería un ejemplo:

Este sería un ejemplo de matriz de habilidades:

.

Este eria un ejemplo de cronograma de actividades:

Este sería un ejemplo de grafica de gantt:

Este sería un ejemplo de ruta critica:

Modelos de proceso de desarrollo del software

¿Qué es un proceso?

Un conjunto de tareas ordenadas que tienen como objetivo alcanzar o cumplir algunas metas.

¿Qué es un modelo de proceso de desarrollo del software?

Un conjunto de tareas ordenadas que tienen como objetivo producir soluciones de software.
¿Qué es un modelo?

Un modelo es una representación de una realidad compleja. Modelar es desarrollar una descripción lo más exacta posible de un sistema y de las actividades llevadas a cabo en él.

Cuando un proceso es modelado, con ayuda de una representación gráfica (diagrama de proceso), pueden apreciarse con facilidad las interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, así como identificar los subprocesos comprendidos. Al mismo tiempo, los problemas existentes pueden ponerse de manifiesto claramente dando la oportunidad al inicio de acciones de mejora.

El modelado de procesos, así como su nombre lo indica, tiene 2 aspectos que lo definen: el modelado y los procesos. Frecuentemente, los sistemas, conjuntos de procesos y subprocesos integrados en una organización, son difíciles de comprender, amplios, complejos y confusos; con múltiples puntos de contacto entre sí y con un buen número de áreas funcionales, departamentos y puestos implicados. Un modelo puede dar la oportunidad de organizar y documentar la información sobre un sistema.

Diagramado

Diagramar es establecer una representación visual de los procesos y subprocesos, lo que permite obtener una información preliminar sobre la amplitud de los mismos, sus tiempos y los de sus actividades.

La representación gráfica facilita el análisis, uno de cuyos objetivos es la descomposición de los procesos de trabajo en actividades discretas. También hace posible la distinción entre aquellas que aportan valor añadido de las que no lo hacen, es decir que no proveen directamente nada al cliente del proceso o al resultado deseado. En este último sentido cabe hacer una precisión, ya que no todas las actividades que no proveen valor añadido han de ser innecesarias; éstas pueden ser actividades de apoyo y ser requeridas para hacer más eficaces las funciones de dirección y control, por razones de seguridad o por motivos normativos y de legislación.

Diagramar es una actividad íntimamente ligada al hecho de modelar un proceso, que es por sí mismo un componente esencial en la gestión de procesos de negocios.

 Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en el que se encuentran cuatro etapas distintas

ESTADO ACTUAL (STATUS QUO):

 «representa el estado

actual de sucesos».

DEFINICIÓN DE PROBLEMAS:

identifica el problema específico a resolverse; el

DESARROLLO TÉCNICO :

resuelve el problema a través de la

aplicación de alguna tecnología

INTEGRACIÓN DE SOLUCIONES:

ofrece los resultados (por ejemplo: documentos,

programas, datos, nueva función comercial, nuevo producto)

a los que solicitan la solución en primer lugar.

Con independencia del modelo de proceso que se

seleccione para un proyecto de software, todas las etapas coexisten simultáneamente en algún nivel de detalle. las cuatro etapas tratadas anteriormente se aplican igualmente al análisis de una aplicación completa y a la generación de un pequeño segmento de código.

MODELO LINEAL SECUENCIAL

Llamado algunas veces «ciclo de vida básico» o modelo en cascada», el modelo lineal secuencial sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento

Análisis de los requisitos del software.

Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero («analista») del software debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento de interconexión.

Diseño.

se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo).

Generación de código.

El diseño se debe traducir en una forma legible por la máquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de

código se realiza mecánicamente.

Pruebas.

 Una vez que se ha generado el código, comienzan las pruebas del programa. detección de errores y asegurar que la entrada definida produce resultados  reales de acuerdo con los resultados requeridos.

¿Por qué algunas veces falla el modelo lineal?

• A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos.

• El cliente debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará disponible hasta que el proyecto esté muy avanzado

 

Modelo de Construcción

De Prototipos

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición.

 

El diseño rápido se centra en una representación de aspectos del software que serán visibles para el usuario/cliente (enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo.

 

En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar y se tiene que tirar, porque incluso la mejor planificación no es omnisciente como para que esté perfecta la primera vez.

La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

 

La construcción de prototipos puede ser problemática por las siguientes razones:

• El cliente ve una versión de trabajo del software, sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo.
• Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible
   
  

 

Modelo DRA

 

El Desarrollo Rápido de Aplicaciones (DRA)es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a «alta velocidad» del modelo lineal secuencial en el que se logra el desarrollo

rápido utilizando una construcción basada en componentes.

 

 

Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional» dentro de períodos cortos de tiempo (por ejemplo: de 60 a 90 días)

Modelado de Gestión.  El flujo de información entre las funciones de gestión se  modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa?

Modelado de datos. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o

recuperar un objeto de datos.

Generación de aplicaciones. En lugar de crear software con lenguajes de programación de tercera generación, trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). Se utilizan herramientas para facilitar la construcción del software.

Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Modelos Evolutivos de Proceso Del Software

 

Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez mas completas del software.

 

El modelo incremental: El modelo incremental combina elementos del modelo lineal secuencial con la filosofía

interactiva de construcción de prototipos. el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal

produce un «incremento» del software suplementarias .

 

Modelo Espiral

 

Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. La Figura 2.8 representa un modelo en espiral que contiene seis regiones de tareas:

 

Comunicación con el cliente- las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.

análisis de riesgos- las tareas requeridas para evaluar riesgos técnicos y de gestión.

ingeniería- las tareas requeridas para construir una o más representaciones de la aplicación.

construcción y acción- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica)

evaluación del cliente- las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar. Desgraciadamente, esto raramente ocurre. En realidad el cliente y el desarrollador entran en un proceso de negociación, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o características del sistema

frente al coste y al tiempo de comercialización

Modelo	Silla
Ciclo de Vida	Silla
Proceso	Barco
Método	Miércoles
Métodología	Miércoles
Herramienta	Martes
Paradigma	Martes