Ingeniería de Software : Introducción a la gestión de procesos de software

Parte A) Definiciones.

1. Requerimientos.

Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto.

2. Documento de especificación de requerimientos.

Es un documento que contiene las especificaciones de la funcionalidad del sistema y sus restricciones, el dominio del problema, un glosario, a quién va dirigido, su objetivo.

Implica la culminación de la tarea del análisis de sistemas. Dicha especificación se logra estableciendo una completa descripción de las clases que colaboran, su función y el comportamiento del sistema.

Debe lograr 3 objetivos:

§ Describir lo que requiere el usuario
§ Establecer una base para la creación de un diseño de software
§ Definir un conjunto de requisitos que se puedan validar una vez que se ha construido el software.

De esta manera, se logran establecer las bases para un buen diseño de sistemas, documentando una descripción del problema que el software va a resolver al definir las clases principales que lo componen, así como los atributos y métodos, además de las relaciones que existen entre ellas.

3. Riesgo.

Es un problema potencial que puede ocurrir o no, su análisis ayuda al equipo de SW a comprender y manejar la incertidumbre. El riesgo puede ser anticipado, identificado y analizado durante la planeación del proyecto.

Cuando se analizan los riesgos es importante cuantificar el grado de incertidumbre y de pérdida asociado con el riesgo.

4. Administración del riesgo.

Al tomar decisiones durante esta etapa acerca de dichas cuestiones, lo primero y más importante que debe considerar son los riesgos de su proyecto. ¿Cuáles son los factores que pueden descarrilarlo? Cuanto mayor sea el riesgo, habrá que prestarle más atención.

1. Riesgos de requerimientos. ¿Cuáles son los requerimientos del sistema? El gran peligro es que se construya el sistema erróneo, un sistema que no haga lo que quiere el cliente. Durante la etapa de elaboración, usted deberá entender bien los requerimientos y sus prioridades relativas.

2. Riesgos tecnológicos. ¿Cuáles son los riesgos tecnológicos que habrá de enfrentar? Plantéese las siguientes preguntas:

a. Va a usar objetos. ¿Tiene ya la suficiente experiencia en el trabajo?

b. Se le ha aconsejado que use Java y la Web. ¿Qué tan bien funciona esta tecnología? ¿Puede en realidad proporcionar las funciones que los usuarios necesitan?

3. Riesgos de habilidades. ¿Puede conseguir la asesoría y los expertos que necesita?

4. Riesgos políticos. ¿Existen fuerzas políticas que se puedan interponer en su camino y afectar seriamente el proyecto?

5. Gestión del proceso de desarrollo de sistemas de software.

Actividad que se encarga de planificar, organizar, administrar, dirigir y controlar, los recursos así como el tiempo y los avances del proyecto que va generando, así como las actividades que implica el desarrollo del sistema y las subactividades, optimizando así el trabajo y generando resultados más favorables.

6. Planeación de los recursos del proyecto de software, recursos, recursos humanos, procesos y metodologías, y herramientas y equipo.

Enfocar la atención en las metas del proyecto, riesgos potenciales y problemas que puedan interferir con estas, determinando el curso que se seguirá a lo largo de la duración del proyecto, determinando las actividades y el tiempo en que se llevaran a cabo, la administración de recursos, y las herramientas que se utilizaran en este.

7.- Cronograma de actividades o calendario.

Designa la programación predeterminada de los trabajos para todos los recursos asignados a un proyecto.

Los trabajos son los esfuerzos que se realizan para cumplir con cada tarea asignada en el proyecto. A la vez las tareas se pueden clasificar en:

· Tarea predecesora: es la que debe de comenzar o terminar antes de que pueda comenzar alguna otra.

· Tarea sucesora: Es una area que depende del comienzo o fin de otra tarea precedente.

Se debe llevar una planeación para que las tareas sean comenzadas y terminadas en el tiempo adecuado de acuerdo a la naturaleza del proyecto.

Para elaborar una buena planeación se recomienda:

· Listar actividades en una columna.

· Calcular el tiempo para cada actividad.

· Indicar los tiempos en forma de barras horizontales.

· Ordenar cronologicamente las tareas.

· Ajustar los tiempos o las secuencias de las actividades.

8.-Gráfica de Gantt

9.-CPM o Ruta crítica

Es utilizado cuando se tiene con certeza la duración de cada actividad. Es posible determinar cuanto tiempo puede retardarse una actividad pero sin retardar al proyecto.

10.-PERT

Con PERT el tiempo de duración de las actividades no se conoce con exactitud, de tal forma, PERT emplea una distribución de probabilidad para determinar los tiempos de culminación. La incertidumbre que se tiene se calcula por medio de la desviación estandar de cada actividad.

La distribución de probabilidad se define:

1. Una probabilidad pequeña de alcanzar el tiempo más optimista, simbolizada por a.

2. Una probabilidad pequeña de alcanzar el tiempo más pesimista, simbolizada por b.

3. Un solo tiempo más probable que estaría para moverse libre entre los dos extremos, es decir entre a y b. Simbolizado por m.

T = (a + 4m +b)/6

También es necesario conocer la variación en los tiempos inciertos de las actividades. Esto se calcula mediante la desviación estándar de los tiempos de actividad.

DE = (b-a)/6

Redes

Las redes muestran una secuencia a seguir y las relaciones de precedencia de las actividades, ordenando de manera general las diferentes etapas del proyecto.

Una red se representa por medio de un diagrama que se conforma por un conjunto de nodos que se conectan por lineas llamadas arcos.

Las actividades se representan por arcos dirigidos y los nodos se usan para representar la culminación de un grupo de actividades.

Para entender como se representan las relaciones, supongase que la actividad A precede a una actividad B.

Ahora supongase que las actividades A y B deben concluirse antes de que la actividad C pueda iniciar.

Finalmente supongamos que la acitividad A precede a B y a C

De tal suerte que dada una lista de actividades, y las actividades antecedentes, un diagrama de red puede construirse con base a las siguientes reglas:

· Existe un nodo de inicio que representa el comienzo del proyecto.

· Existe un nodo final que representa la culminación del proyecto.

· Deben de enumerarse los nodos del diagrama de tal suerte que el nodo inicial siempre tendra un numero menor que el nodo final.

· Una actividad no puede ser representada por mas de un arco dentro de la red.

· Dos nodos pueden conectarse a lo más por un arco.

Para no violar las últimas dos reglas es necesario utilizar un actividad dummy, la cual permite establecer las relaciones antecedentes apropiadas, estas actividades no consumen tiempo.

Supongase que dos actividades A y B preceden a la actividad C y ambas pueden comenzar al mismo tiempo, entonces se procede a utilizar una actividad dummy.

Los calculos de la ruta critica incluyen dos fases.

· Recorrido de avance, donde los cálculos empiezan en el nodo inicial y siguen hacia delante hasta el nodo final. En cada nodo se calcula un numero que representa el tiempo de ocurrencia mas temprano del evento correspondiente.

· Recorrido de retroceso, los cálculos empiezan desde el nodo final hasta el inicial. En cada nodo se calcula un numero que representa el tiempo de ocurre más tardio del evento correspondiente.

Cálculo del recorrido de avance

En el recorrido de avance se hace el cálculo de los inicios más próximos de todos los eventos. Este cálculo debe llevarse a cabo primero con todos los eventos que conectan directamente con el evento inicial; después con todos los que conectan directamente con estos eventos y así sucesivamente hasta alcanzar el evento final del proyecto.

El tiempo de inicio más próximo para un nodo i se representa con ES(i) es el tiempo

más próximo en que un evento correspondiente al nodo i puede ocurrir.

ES(i) se calcula de la siguiente manera:

Paso 1. Encontrar cada evento previo al nodo i que está conectado por un arco al nodo i. Estos eventos son los antecesores inmediatos del nodo i.

Paso 2. Para el ES en cada antecesor inmediato del nodo i se le suma la duración de la actividad que conecta a ese antecesor inmediato con el nodo i.

Paso 3. ES(i) es igual al valor máximo de las sumas obtenidas en el paso 2. Si i = 1, el evento de inicio , entonces convencionalmente, para los cálculos de ruta crítica el valor ES(1) para ese evento es igual a 0.

B)Ejemplos

1. Requerimientos y documento de especificación de requerimientos: tareas y actividades del proceso de requerimientos, ejemplo de plantilla, que incluya posibles rubros que contiene un documento de especificación de requerimientos.

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

La función principal de un analista del software (o ingeniero de requisitos) es llevar a cabo las actividades necesarias para cumplir con las cinco áreas de esfuerzo. Para lo cual hace uso de las siguientes técnicas:

1. Entrevistas

2. Talleres

3. Observación

4. Encuestas

5. Revisión documental

6. Uso de especificaciones formales para requerimientos (formatos estándar de documentos, UML, etc.)

Las actividades del proceso son:

1. Comprensión del dominio

2. Recolección de requisitos

3. Clasificación

4. Resolución de conflictos

5. Priorización

6. Verificación de requisitos

7. Análisis

Actividades de la Ingeniería de Requisitos. [SOMMERVILLE, 2002]

La ingeniería de requisitos incluye dos actividades principales: la obtención de requisitos, que da como resultado una especificación del sistema que el cliente comprende, y el análisis, que da como resultado un modelo de análisis que los desarrolladores pueden interpretar sin ambigüedad. [BRUEGGE, 2002]

2. Riesgo y administración del riesgo, posibles rubros que incluye la gestión del riesgo. Ejemplo de una matriz de riesgo.

3. Gestión del proceso de desarrollo de sistemas de software, particularmente en la fase de planeación del de la implementación y programación considere lo siguiente:

• Una persona de soporte técnico, por ejemplo, un programador de mantenimiento llamado A, necesita corregir un programa que fue escrito por otro programador B, que utilizó su propia convención para nombrar variables.

Suponga el programador A, descubre que otro programa escrito por un tercer programador C también se debe modificar como parte de la primera corrección. Si programador de C también utilizó su propio conjunto de convenciones para nombrar a las mismas variables, entonces se puede imaginar la inherente confusión potencial en el aprendizaje de otro conjunto de variables y realizar cambios en el código que afectan a las mismas variables referenciadas con diferentes nombres. Este tipo situaciones pueden convertirse en una pesadilla que aumenta los costos y esfuerzos invertidos, además de que es un tipo de riesgo potencial para la introducción de nuevos errores.

• ¿De qué manera puede prevenirse este tipo de situaciones? Explique su respuesta y proponga una solución.

Ya que las variables utilizadas por el programador B y las variables utilizadas por el programador C eran las mismas, se puede prevenir nombrando a las variables de la misma manera, de esta manera seria mucho más sencillo identificar a las variables que son las mismas y poder centrar su atención en corregir el programa.

Propongo que al momento de diseñar los programas, si se utilizan las mismas variables en estos, se llegue a un acuerdo y se generalice el nombre de las variables.

4. Planeación de los recursos del proyecto de software, recursos, recursos humanos, procesos, metodologías, herramientas y equipo.

• Ejemplo de una matriz de habilidades del personal del equipo de desarrollo de software, que son necesarias después de que los administradores de proyectos de software revisan los requisitos del producto y el análisis. Por ejemplo, puede considerar: líder de proyecto, analista de requerimientos, diseñador, programador, analista de pruebas, por mencionar algunos.

5. Ejemplo de calendario o cronograma de actividades del desarrollo de un sistemade software.

6. Ejemplo de Gráfica de Gantt.

7. Ejemplo simple de método de ruta crítica - CPM.

CONCLUSIÓN

Entender y analizar los requisitos es el paso más importante a la hora de desarrollar un sistema de software, éstos deben de ser entendibles y sin ambigüedades; considerar el riesgo dentro del proyecto nos ayuda a manejar la incertidumbre. Es importante tener diagramas que nos ayuden a manejar el problema del software, de esta forma será más entendible; podemos hacer casos de uso. Otro paso importante es la documentación de los requerimientos, en este documento entenderemos qué hará nuestro proyecto, cuál será su objetivo, etc. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.