Web viewActividades / Productos de Trabajo: Tareas. Teoría. Actividad de Aprendizaje....

Actividades / Productos de Trabajo

Tareas Teoría Actividad de AprendizajeInstrucciones DG y PW

1. Fundamentación

Pantalla 1¿Qué es la

ingeniería de Software?

Ingeniería de software es una disciplina que ofrece métodos y técnicas para desarrollar y mantener software.

Algunas definiciones de Ingeniería de software son:

DW y PW: Se publica como va. Esquema solo en imagen.

Pantalla 2 La Especificación de Requisitos Software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto Actividad 1

Especificación de requisitos

de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (Como por ejemplo restricciones en el diseño o estándares de calidad).

Básicamente, un requisito del software es unacaracterística que se debe exhibir para solucionar uncierto problema en el del mundo real. La guía se refiere a requisitos de “software” porque se refiere alos problemas que se tratarán por el software. Por lo tanto, un requisito del software es una característicaque se debe exhibir por el software desarrollado oadaptado para solucionar un problema particular.

¿Por qué son importantes los requisitos?

Un proceso efectivo de la Especificación de Requisitos se enfoca en la intersección de intereses de todos los Stakeholders.

Cliente Patrocinador Responsable de Administración de Proyectos Específicos (RAPE) Responsable de Gestión de Proyectos (RGPY) Responsable de Desarrollo y Mantenimiento de Software (RDM) Analistas Usuarios Desarrolladores Etc,

Definición de Requisito de Software

Una condición que debe ser cumplida para que el cliente encuentre ACEPTABLE el producto o servicio proporcionado. Una condición o capacidad necesitada por un usuario para solucionar un problema o lograr un objetivo. (IEEE Standard Glossary of Software

Engineering Terminology (1990) ) Constituyen la definición del sistema que se va a construir o mejorar Los requisitos son una especificación de lo que debe estar implementado. Son descripciones de cómo el sistema debe comportarse, o una

propiedad o atributo del sistema. Puede ser una restricción en el proceso de desarrollo del sistema. Un requisito es una propiedad que un producto debe tener para proveer valor a un Stakeholder.

Las especificaciones de Requisitos no incluyen:

Instrucciones: Elabora un documento de Especificación de requisito. Para el desarrollo de esta actividad toma como referencia lo siguiente:

Anexo 1(dms_anexo_1.docx)

Plantilla: Especificación de Requisitos

(dms_especificacion_de_requisitos_plantilla.doc)

Al finalizar tu actividad, coloca una copia de la misma en la tu carpeta de trabajo titulada: DMS para que sea retroalimentada por tu Asesor(a

DW y PW: favor de generar un menú interactivo, el cual muestre la información correspondiente a cada enunciado, misma aué aparece debajo del menú en color gris.

Al darle clic en cada uno de las palabras en negritas que aparezcan su definición (tooltip)

Stakeholders: «quienes pueden afectar o son afectados por las actividades del proyecto ». Partes involucradas en el proyecto.

Cambios

Figura 1: Sustituir palabras:

Requerimientos por “Requisitos”, Ejemplo: Requerimientos del negocio seria “Requisitos del negocio”.

SRS por “Especificación de Requisitos”

Detalles de diseño o implementación Información de planeación de proyecto, o información de pruebas. Una solicitud informal de alguien en una reunión, un pasillo o un elevador o una llamada telefónica Solicitudes de clientes por medio de encuestas, correos electrónicos o buzones de sugerencias Observaciones o comentarios durante reuniones de ventas o de publicidad

Para que sea un requisito: Debe ser solicitado formalmente Debe ser documentado Debe ser analizado formalmente para verificar el impacto en el proyecto Debe ser aprobado

Características que deben de tener los requisitos: Completo Correcto Factible Necesario Priorizado No ambiguo Verificable Rastreable

Algunos de los riesgos de requisitos más comunes:

Participación insuficiente del usuario Requisitos que crecen progresivamente Requisitos ambiguos Especificación mínima Pasar por alto clases de usuarios Planeación incorrecta

Las organizaciones que implementan un buen proceso de ingeniería de requisitos pueden cosechar múltiples beneficios.Los posibles beneficios que se podrían disfrutar en cuanto ahorro de tiempo y dinero:

1. Menos defectos en los requisitos2. Reducir el retrabajo3. Disminución de propiedades innecesarias4. Rápido desarrollo5. Disminución de la falta de comunicación6. Menos caos7. Estimaciones más aproximadas8. Satisfacción del cliente y del equipo

Existen niveles de requisitos

Figura 1 Niveles de Requisitos

Para analizar algunos otros puntos que correspondientes a las especificaciones de requisitos, descarga el siguiente documento:

Especificaciones de requisitos

DW y PW: favor de ligar el documento correspondiente

Pantalla 3Casos de Uso

¿Qué es un caso de uso?

Describen una interacción típica entre un usuario (actores) y un sistema de cómputo. Es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje Produce algo de valor para algún actor como el cálculo de algún resultado Describe qué hace un sistema pero no especifica cómo lo hace El caso de uso capta alguna función visible para el usuario. El caso de uso puede ser pequeño o grande. El caso de uso logra un objetivo discreto para el usuario. Un caso de uso debe ser simple, claro y conciso

¿Para que sirven los casos de uso?

Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento Como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este

¿Cómo se representan?

Un caso de uso se representa en UML como un óvalo:

Figura 2 Nombre del Caso de Uso

En UML, un actor se representa de la siguiente manera:

Actividad 2

Instrucciones: Descarga el siguiente documento:

dms_anexo_2.docx (dms_anexo_2.docx)

Revísalo y con base en el mismo desarrolla las siguientes actividades:

1.- Realiza el diagrama de casos de uso del sistema. Este diagrama debería tener al menos una relación de inclusión o de extensión.

2.- Toma de la pregunta anterior los dos casos de uso relacionados por la extensión o los dos casos de uso relacionados por la inclusión y con base en ello realiza tus respectivas descripciones textuales completas.

Al finalizar tu actividad, coloca una copia de la misma en la tu carpeta de trabajo titulada: DMS para que sea retroalimentada por tu Asesor(a

DW y PW: favor de generar un menú interactivo, el cual muestre la información correspondiente a cada enunciado, misma aué aparece debajo del menú en color gris.

Figura 3 ActorActores

Representa un conjunto de roles que los usuarios de los casos de uso juegan al interactuar con éstos Representa un rol que es jugado por una persona, un dispositivo hardware u otro sistema que interactúe con nuestro sistema Se puede definir categorías generales de actores (como cliente) y especializarlos (como Cliente Comercial) a través de relaciones de

generalización Un actor y un caso de uso se pueden comunicar a través de una asociación en donde cada uno de ellos pueden enviar y recibir mensaje.

Figura 4 Ejemplo de actores

Para analizar algunos otros puntos correspondientes a los casos de uso, descarga el siguiente documento:

Casos de uso

Pantalla 4Técnicas para recolectar

Existen diversas técnicas de recolección de requisitos:

Entrevistas

Cuestionarios

Talleres de Recolección de Requisitos

Lluvia de Ideas

Observar cómo trabajan los usuarios

Prototipos

Casos de uso (Escenarios)

Técnicas

requisitos

Pantalla 5Análisis y Diseño: Descripción Arquitectónica

La vista arquitectural de un sistema es abstracta, proporcionando detalles acerca de la implementación, los algoritmos, la representación de datos e incluso el comportamiento y la interacción entre elementos (cajas negras - black box).

Actividad 3

Instrucciones: Descarga el siguiente documento: Anexo 1

DW y PW:

Implicaciones de la definición

Para profundizar en el estudio de este tema, descarga y revisa el siguiente documento:

Análisis y Diseño: Descripción Arquitectónica

(dms_anexo_1.docx)

Revísalo y con base en el mismo Diseñar la vista Física y vista lógica.

Al finalizar tu actividad, coloca una copia de la misma en la tu carpeta de trabajo titulada: DMS para que sea retroalimentada por tu Asesor(a)

Pantalla 6Análisis y Diseño: Descripción Detallada

Presiona cada uno de los botones para visualizar la información correspondiente: Actividad 5

En base al anexodms_anexo_1.docxRealizar las siguientes actividades:

¿Qué es el Diseño del Sistema?

Definición lógica de la forma en que se construye el software que cumplirá con los requisitos El CÓMO del sistema Incluye:Funciones, módulos, tablas, bases de datos, clases, hardware, componentes, etc.

¿Qué es UML?

El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos. UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños. UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los

objetos de un sistema programado. Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch, Rumbaugh (OMT:

ObjectModelingTechnique) y Jacobson (OOSE: Object-OrientedSotfwareEngineering). UML es un lenguaje de modelado que sirve para visualizar, especificar ,construir y documentar un sistema software.

UML para visualizar

Símbolos con semántica bien definida. UML transciende al lenguaje de programación. Modelo explícito, que facilita la comunicación.

UML para especificar Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. UML cubre la especificación del análisis, diseño e implementación de un sistema software.

UML para construir

No es un lenguaje de programación

Descargar Anexo: Anexo 1(dms_anexo_1.docx)

1.- Realice el diagrama de clases2.- Realice el diagrama de secuencia

¿Qué es UML?UML para visualizarUML para construir

Pero sus modelos pueden conectarse a una gran variedad de lenguajes de programación

UML para documentar

UML cubre la documentación de un sistema:o Requisitoso Arquitecturao Diseñoo Código fuenteo Planificacióno Pruebaso Prototiposo Versiones

Los 9 diagramas de UML

Figura 12 Diagramas de UML

Para profundizar en el estudio de este tema, descarga y revisa el siguiente documento:

Diagrama de casos de usoPantalla 7Documentación de Código

La documentación interna de un programa incluye elementos cuyo objetivo es facilitar la inteligibilidad del mismo.No es lo mismo tardar 5 minutos en entender un código que tardar un par de horas en intentar saber que es lo que hace porque no tiene unos buenos comentarios y no está correctamente estructurado. La mayoría de los desarrollos de sistemas se llevan a cabo por parte de un equipo. Una buena documentación interna del código que se está desarrollando favorece la comunicación entre los distintos miembros del equipo, mejorando su productividad.

Los tres elementos más significativos de la documentación de código son la elección de nombres significativos, los comentarios y la indentación. Veremos, a continuación, cada uno de ellos:

Elección de nombres significativos

La elección de nombres significativos para los identificadores (tanto de constantes, como variables, funciones...) es crucial para que un programa sea inteligible.

Consideremos las siguientes sentencias

código:

e = v * t espacio = velocidad * tiempo

La primera de las sentencias es más concisa, pero la segunda aporta mucha más información al lector de la misma.

El nombre de los identificadores debe elegirse de forma que no deje lugar a duda sobre su objetivo o el significado del valor que va a contener.

Comentarios

La posibilidad de expresar comentarios en lenguaje natural como parte del listado del código fuente es algo que aparece en todos los lenguajes de programación. Los comentarios permiten al programador comunicarse con otros lectores del código, resultando una clara guía de comprensión durante las etapas de mantenimiento.

Indotación

La forma en que el código fuente aparece en el listado supone una importante contribución a la legibilidad del mismo. La indentación realza las construcciones lógicas y los bloques del código.

No es lo mismo:

CódigoC:

#include <stdio.h>

int main (){int y, a;for (y=0;y<=10;y++)for (a=0;a<=10;a++)printf("%i x %i = %in", y, a, y*a); return 0; }

Que:

CódigoC:

#include <stdio.h>

int main (){int y, a;for (y=0;y<=10;y++)for (a=0;a<=10;a++)printf("%i x %i = %in", y, a, y*a);

return 0; }

Aunque ejecute lo mismo. El segundo trozo de código es más legible que el primero.

Notación Húngara

Es un método ampliamente usado sobre todo para convención de nombres de variables. El inventor de esta notación, Charles Simonyi, nació en Hungría, por eso el nombre. Consiste en tener variables autodocumentadas agregando un prefijo de tres caracteres o menos para indicar su tipo. Las abreviaturas de los tipos de datos pueden variar dependiendo del lenguaje de programación.

Algunos ejemplos:

b Booleano (int)by BYTE o UCHAR (unsigned char)c Carácter (un byte)dw Entero largo de 32 bits sin signo (doubleword)f Flags empaquetados en un entero de 16 bitsh Manipulador de 16 bits (handle)l Entero largo de 32 bitslbl Objeto Labellp Puntero a entero largo de 32 bitslpfn Puntero largo a una función que devuelve un enterolpsz Puntero largo a una cadena terminada con ceron Entero de 16 bitsp Puntero a entero de 16 bitse Enumeraciónpt Coordenadas (x, y) empaquetadas en un entero de 32 bitsrgb Valor de color RGB empaquetado en un entero de 32 bitssz Cadena terminada en cerotxt Cajas de textow Entero corto de 16 bits sin signo (word)

En un sentido más categórico, si tengo un contador, primero van las letras que me dicen que es un número entero (n) y luego el nombre de la variable que sea significativo para su uso.

Por ejemplo un contador que me sirve para saber cuántos hay conectados en una página:

intnContPerPag; n de número entero, Cont de contador, Per de personas, Pag de pagina.

Notación camello

La notación Camel consiste en escribir los identificadores con la primera letra de cada palabra en mayúsculas y el resto en minúscula: EndOfFile. Se llama notación “Camel” porque los identificadores recuerdan las jorobas de un camello. Existen dos variantes:

Existen en principio dos variantes de esta notación, la UpperCamelCase y la lowerCamelCase. La principal diferencia entre ambas es que en el caso del upper la primera letra siempre se escribirá en mayúscula mientras que en la segunda la primera palabra siempre será entera en minúsculas.

UpperCamelCase: la primera letra es mayúscula.

lowerCamelCase: la primera letra es minúscula.

En el lenguaje Java, se usa la notación CamelCase en identificadores para clases. La notación Camel se utiliza también en publicidad y marcas comerciales: PlayStation, easyJet, etc

MoProSoft Pantalla 8¿Qué es MoProSoft?

El Modelo de Procesos para la Industria de Software (MoProSoft) es un conjunto integrado de procesos de Gestión e Ingeniería de Software, compuesto por prácticas reconocidas.

MoProSotf

¿Por qué se desarrolló MoProSoft?

Para sugerir a las organizaciones que se dedican al desarrollo y mantenimiento de software, el tipo de prácticas que les pueden ayudar a mejorar su forma de trabajar y por lo tanto su desempeño.

Esta fue la apuesta que motivó a la SE para apoyar este proyecto para convertirlo en la norma mexicana para la industria de software.

¿Para quién es MoProSoft?

MoProSoft está dirigido tanto a empresas como a áreas internas dedicadas al desarrollo y/o mantenimiento de software.

Las organizaciones que no cuentan con procesos establecidos pueden usar el modelo ajustándolo de acuerdo a su contexto y necesidades, mientras que las organizaciones con procesos establecidos pueden usarlo como referencia para identificar elementos faltantes.

¿Cómo se distingue MoProSoft de modelos de procesos similares?

Tiene una estructura de procesos acorde a la estructura de las organizaciones de software (Alta Dirección, Gerencia y Operación) que no tiene ningún otro modelo.

Destaca el papel de la Alta Dirección en la planeación estratégica, como promotor del buen funcionamiento de la organización, a lo que no se atreve ningún otro modelo para esta industria.

Integra los elementos para la administración de proyectos en un sólo proceso.

Está orientado a mejorar los resultados en las organizaciones de desarrollo de software, contribuyendo a los objetivos de negocio y no simplemente es un marco de referencia para una certificación o evaluación.

Sirve de base para las organizaciones que no cuentan con procesos establecidos y como punto de referencia para las organizaciones que ya tienen procesos establecidos.

No requiere de una estructura organizacional compleja para poder ser aplicado. Se adapta a la organización de cualquier tamaño, sobre todo a la pequeña y mediana.

Establece un mecanismo para mantener el capital intelectual y para hacer un uso adecuado de los recursos materiales de la organización.

Está basado en los principales estándares internacionales, que aplican a la industria de software, pero siendo práctico.

Sirve de base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2008 o CMMI-DEV.

Es fácil de entender y aplicar.

Pantalla 9Arquitectura

Categorías de Procesos

El modelo de procesos MoProSoft tiene tres categorías de procesos: Alta Dirección, Gerencia y Operación que reflejan la estructura típica de una organización.

Actividad _ Cuestionario.

Instrucciones: Tomando como referencia la información presentada en este tema responde a las preguntas que se presenta a continuación. Al finalizar tu actividad, da clic en el botón guardar para que esta quede registrada en tu carpeta de trabajo.

¿Qué significan las siglas MoProSoft?

¿Qué es MoProSoft?

DW, PW: Animar los esquemas que estén en e pequeño y al darle clic a cada uno este se haga grande. En la caso del esquema de categorías se debe presentar con todo y la información que aparece debajo del mismo. En el caso del esquema de la estructura general favor de quitar el color de gestión de negocios.

Nota: Las actividades

Figura 9Categorías

La categoría de Alta Dirección contiene el proceso de Gestión de Negocio.

La categoría de Gerencia está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización.

La categoría de Operación está integrada por los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software.

¿Para qué se puede utilizar MoProSoft?

¿Cómo se distingue MoProSoft de modelos de procesos similares?

¿Cuál es la función de los procesos de la Categoría de Alta Dirección?

¿Cuál es la función de los procesos de la Categoría de Gerencia?

¿Cuál es la función de los procesos de la Categoría de Operación?

deben aparecer la final de la pantalla.

PropósitoEs la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos omodificados cumpliendo con los requerimientos especificados.

3. Desarrollo y Mantenimi

ento de Software

a. PropósitoPropósitoEs la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados.

Actividades

1. Responda las siguientes preguntas

¿Cuál es el propósito del proceso de Desarrollo y Mantenimiento de Software?

¿Cuáles son los resultados esperados en la implementación efectiva del proceso de Desarrollo y Mantenimiento de Software?

b. Objetivos e Indicadores

Los objetivos establecen una forma específica, medible, alcanzable y acotada en el tiempo de lograr el propósito del proceso. Cada objetivo tiene uno o más indicadores que guían la medición del mismo

Objetivos e Indicadores

O3 Llevar a cabo las actividades de las fases de un ciclo mediante el cumplimiento del Plan de Desarrollo actual. I3 (O3)I3 (O3) Las actividades planificadas en cada fase de un ciclo se realizan conforme a lo establecido en el Plan de Desarrollo.

Actividades


¿Cuáles son los indicadores que podrían utilizarse para evaluar la efectividad del cumplimiento de los objetivos del proceso de Desarrollo y Mantenimiento de Software?

c. Roles Involucrados

Roles involucrados

En cada proceso están definidos los roles responsables por la ejecución de las prácticas. Los roles se asignan al personal de la organización de acuerdo a sus habilidades y capacitación para desempeñarlos.

¿Qué es un rol? Un rol es responsable por un conjunto de actividades de uno o más procesos. Un rol puede ser asumido por una o más personas de tiempo parcial o completo.

En el proceso de Desarrollo y Mantenimiento de Software, participan los siguientes roles:

Rol Capacitación

Actividades


En el contexto de MoProSoft, ¿Qué es un rol?

¿Cuáles son los roles involucrados en el proceso Desarrollo y Mantenimiento de Software?

¿Qué rol es el responsable por la ejecución del proceso?

¿Qué rol valida la ejecución del proceso y el cumplimiento de su propósito?

¿Cuál es la responsabilidad principal del RDM?

¿Cuáles serían las funciones del RDM en una organización?

DW, PW: Animar el esquema de Roles involucrados por actividad. Al colocar el cursor encima de cada rol. desplegar la información correspondiente, especificada a continuación:

Responsable de la Administración del Proyecto Específico (RAPE)

Capacidad de liderazgo con experiencia en la toma de decisiones, planificación estratégica, manejo de personal y desarrollo de software.

Responsable de Desarrollo y Mantenimiento deSoftware (RDM)

Conocimiento y experiencia en el desarrollo y mantenimiento de software.

Responsable de la Administración del Proyecto Específico (RAPE) - Autoridad -

Capacidad de liderazgo con experiencia en la toma de decisiones, planificación estratégica, manejo de personal y desarrollo de software.

Responsable de Desarrollo y Mantenimiento deSoftware (RDM) - Responsable -

Analista Conocimiento y experiencia en el desarrollo y mantenimiento de software.

Analista (AN) Conocimiento y experiencia en la obtención, especificación y análisis de los requisitos.

Diseñador de Interfaz de Usuario (DU) Conocimiento en diseño de interfaces de usuario y criterios ergonómicos.

Diseñador (DI) Conocimiento y experiencia en el diseño de la estructura de los componentes de software.

Programador (PR) Conocimiento y/o experiencia en la programación, integración y pruebas unitarias.

Responsable de Manuales (RM) Conocimiento en las técnicas de redacción y experiencia en el desarrollo y mantenimiento de software.

Equipo de Trabajo (ET) Conocimiento y experiencia de acuerdo a su rol.Cliente (CL) Interpretación del estándar de la especificación de

requisitos.Usuario (US) Ninguna.

Roles involucrados por actividad

Analista (AN)Conocimiento y experiencia en la obtención, especificación y análisis de los requisitos.

Diseñador de Interfaz de Usuario (DU)Conocimiento en diseño de interfaces de usuario y criterios ergonómicos.

Diseñador (DI)Conocimiento y experiencia en el diseño de la estructura de los componentes de software.

Programador (PR)Conocimiento y/o experiencia en la programación, integración y pruebas unitarias

Responsable de Manuales (RM)Conocimiento en las técnicas de redacción y experiencia en el desarrollo y mantenimiento de software.

Equipo de Trabajo (ET)

Conocimiento y experiencia de acuerdo a su rol.

Cliente (CL)

Interpretación del estándar de la especificación de requisitos.

Usuario (US)Ninguna.

d. Procesos relacionados Procesos relacionados

La relación entre procesos se establece mediante la identificación de los productos de trabajo de Entrada y Salida y la definición de las responsabilidades de los roles que participan en más de un proceso.

Los procesos relacionados con el proceso de Desarrollo y Mantenimiento de Software son: Administración de Proyectos Específicos

La siguiente imagen ilustra la relación entre los procesos

Actividades


¿Cómo se relacionan los procesos de MoProSoft?

¿Cuáles son los procesos relacionados con el proceso Desarrollo y Mantenimiento de Software?

DW, PW: Animar el esquema de Procesos Relacionados. La animación debe de ser secuencialmente donde aparecerá primero el recuadro de todos los procesos, después ser el siguiente orden

1. Flecha en dirección a Gestión de Proyectos.

2. Flecha en dirección a Gestión de Procesos.

3. Flecha en dirección a Gestión de Recursos.

4. Flecha en dirección a Desarrollo y Mantenimiento de

.

Cuál es la relación entre estos procesos?

El proceso de Desarrollo de Software busca lograr un entendimiento claro de las necesidades del cliente para generar un producto consistente que cumpla con sus necesidades. Solamente se relaciona con el proceso de Administración de Proyectos Específicos, el cual le proporciona un Plan de Desarrollo.

El Plan de Desarrollo es la principal entrada para este proceso, contiene todo lo necesario para que el RDM pueda realizar sus actividades de su proceso. (Descripción del producto, Entregables, Equipo de Trabajo y Calendario del proyecto).

Software

e. Ciclo de actividades

El modelo de procesos MoProSoft considera 5 niveles de madurez (1-5), siendo el nivel 1 el nivel menor de madurez. El nivel 1 denominado Proceso Realizado consiste en obtener los resultados o salidas esperadas de los procesos definidos en MoProSoft, por lo que las actividades y las tareas que se definen en este modelo simplificado han sido delimitadas para cumplir con este nivel. En los niveles superiores de madurez se van incorporando nuevas prácticas a los procesos, lo que permitirá ejercer un mayor control sobre su ejecución.

Ciclo de Actividades

El proceso de Desarrollo y Mantenimiento de Software se compone de uno omás ciclos de desarrollo. Cada ciclo está compuesto de las siguientes fases:

• Inicio: Revisión del Plan de Desarrollo por los miembros del Equipode Trabajo para lograr un entendimiento común del proyecto y paraobtener el compromiso de su realización.

• Requisitos: Conjunto de actividades cuya finalidad es obtener ladocumentación de la Especificación de Requisitos y Plan dePruebas de Sistema, para conseguir un entendimiento común entre elcliente y el proyecto.

• Análisis y Diseño: Conjunto de actividades en las cuales se analizanlos requisitos especificados para producir una descripción de laestructura de los componentes de software, la cual servirá de basepara la construcción. Como resultado se obtiene la documentación delAnálisis y Diseño y Plan de Pruebas de Integración.

Actividades

1. Conteste las siguientes preguntas

¿Qué actividades componen el flujo del proceso de Desarrollo y Mantenimiento de Software?

¿Cuáles son las actividades esperadas en el Nivel 1 para el proceso de Desarrollo y Mantenimiento de Software

¿Cuáles son los productos que se generan en cada una de ellas?

¿Qué roles participan en cada actividad?

DW, PW: Animar el esquema de Actividades. La animación debe de ser secuencialmente donde aparecerá primero el recuadro de Plan de Desarrollo, después ser el siguiente orden

1. Fase de Inicio2. Fase de Requisitos.3. Fase de Análisis y

Diseño4. Fase Construcción5. Fase de

Integración y Pruebas

6. Fase de Cierre7. Entregable8. Llamada Ovalada

• Construcción: Conjunto de actividades para producir Componente(s)de software que correspondan al Análisis y Diseño, así como larealización de pruebas unitarias. Como resultado se obtienen el (los)Componente(s) de software probados.

• Integración y Pruebas. Conjunto de actividades para integrar y probarlos componentes de software, basados en los Planes de Pruebas deIntegración y de Sistema, con la finalidad de obtener el Software quesatisfaga los requisitos especificados. Se genera la versión finaldel Manual de Usuario, Manual de Operación y Manual deMantenimiento. Como resultado se obtiene el producto de Softwareprobado y documentado.

• Integración y Pruebas. Conjunto de actividades para integrar y probarlos componentes de software, basados en los Planes de Pruebas deIntegración y de Sistema, con la finalidad de obtener el Software quesatisfaga los requisitos especificados. Se genera la versión finaldel Manual de Usuario, Manual de Operación y Manual deMantenimiento. Como resultado se obtiene el producto de Softwareprobado y documentado.

• Cierre: Integración final de la Configuración de Software generada enlas fases para su entrega. Identificación y documentación de lasLecciones Aprendidas. Generación del Reporte de Mediciones ySugerencias de Mejora.

Para generar los productos de cada una de estas fases se realizan lassiguientes actividades:

· Distribución de tareas, se asignan las responsabilidades de cadamiembro del Equipo de Trabajo de acuerdo al Plan de Desarrollo.

Actividades

En la imagen, claramente se puede apreciar (mediante las líneas y flechas) la relación entre las seis actividades del proceso de Desarrollo y Mantenimiento de Software, siendo la Fase de Inicio el inicio del ciclo de las actividades

Todas las actividades con sus respectivas flechas de relación.

4. Fase de

Inicio

A1 Fase de Inicio

• Fase de Inicio: Revisión del Plan de Desarrollo por los miembros del Equipode Trabajo para lograr un entendimiento común del proyecto y paraobtener el compromiso de su realización.

Minuta

A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual paralograr un entendimiento común y obtener su compromiso con el proyecto.

Como primera tarea de este proceso el Responsable de Desarrollo y Mantenimiento de Software ,elRDM) se debe de reunir con el equipo de trabajo para revisar el Plan de Desarrollo actual y obtener un entendimiento común y el compromiso con el proyecto. Esta reunión puede ser de manera formal o informal.

Formal Minuta de reunión con el equipo de trabajo donde se obtenga el entendimiento común del Plan de desarrollo y el compromiso con el proyecto.

Informal Comunicación directa con el equipo de trabajo, sin generar evidencia alguna.

5. Diagrama de flujo de la fase de Inicio

Actividad de aprendizaje

Fase de Inicio

A continuación se identifican las tareas esperadas a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.

Actividades

1. Diseñar un diagrama de

A1. Fase de InicioRol Descripción de la tarea

ET A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual paralograr un entendimiento común y obtener su compromiso con el proyecto.

flujo

Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A1. Fase de Inicio y los productos generados en cada una de ellas.

Para realizar este ejercicio, se puede consultar el Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos). (ver anexo MoProSoft v1.3 - Por Niveles de Capacidad de Procesos.pdf)

Nota: Considerar solamente las tareas correspondientes a Nivel 1 de madurez del proceso de Desarrollo y Mantenimiento de Software.

El diagrama de flujo de trabajo deberá reflejar:- Tareas- Roles responsables- Productos (documentos o

artefactos) generados

A continuación se presentan un esquema de diagrama de flujo, a manera de ejemplo:

Recomendaciones

Para el diseño del diagrama de flujo puede utilizarse simbología básica, notación 1UML o notación 2BPMN y/o usar herramientas de apoyo como por ejemplo Microsoft Visio, StarUML o BizAgiProcessModeler.

1UML - Lenguaje Unificado de Modelado (por sus siglas en inglés, UnifiedModelingLanguage).2BPMN- Notación para el Modelado de Procesos de Negocio (por sus siglas en inglés, Business ProcessModelingNotation).

6. Fase de Requisitos

A2 Fase de Requisitos

• Fase Requisitos: Conjunto de actividades cuya finalidad es obtener ladocumentación de la Especificación de Requisitos y Plan dePruebas de Sistema, para conseguir un entendimiento común entre elcliente y el proyecto.

Minuta

A2.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo alPlan de Desarrollo actual.

Como primera tarea de cada actividad del proceso de Desarrollo y Mantenimiento de Software, el RDM se debe de reunir con el equipo de trabajo, para asignarle las tareas correspondientes de la fase de requisitos. La asignación de tareas es de acuerdo al rol a desempeñar de los miembros del equipo de trabajo, según lo establece el Plan de Desarrollo actual. Esta reunión puede ser de manera formal o informal.

Formal Minuta de reunión con el equipo de trabajo donde se asignen tareas según su rol de acuerdo al Plan de Desarrollo.

Informal Comunicación directa con el equipo de trabajo, para asignarle tareas según su rol, sin generar evidencia alguna.

a. Especificación de Requisitos

A2.2. Documentar o modificar la Especificación de Requisitos.

•Identificar y consultar fuentes de información (clientes, usuarios, sistemas previos, documentos, etc.) para obtener nuevos requisitos. •Analizar los requisitos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto. •Elaborar o modificar el prototipo de la interfaz con el usuario.•Generar o actualizar la Especificación de Requisitos.

Guías para la especificación de requisitos

Usar siempre palabras como “debe”, “deberá”, “permitirá”, “podrá” y evitar palabras como “podría”, “debería”, “tal vez”. Asignar un identificador único a cada requisito. Para los Requisitos No Funcionales que son Atributos de Calidad, especificar métricas de cómo el requisito se debe cumplir y no dejar frases tales

como “que lo haga rápido”, “que lo haga bien”, entre otras. Es mejor especificar cosas como “que responda en menos de 30 segundos”, “que se inserten el 100% de los registros”, etc.

Jamás suponer o asumir algo Especificar todo lo más claro posible pues hay que tomar en cuenta que los que diseñarán el sistema son otras personas. Cuidar el no incluir palabras ambiguas, un síntoma sería que dos personas entendieran cosas distintas del requisito.

Especificación de Requisitos: Documento que se compone de una introducción y una descripción de requisitos.a) introducción - descripción general del software y su uso en el ámbito de negocio delcliente;b) descripción de requisitos:i) funcionales - necesidades establecidas que debe satisfacer el software cuando esusado en condiciones especificas, las funcionalidades deben ser adecuadas, exactas yseguras;ii) interfaz con usuario - definición de aquellas características de la interfaz de usuarioque permiten que el software sea fácil de entender, aprender, que generesatisfacción y con el cual el usuario pueda desempeñar su tarea eficientemente,incluyendo la descripción del prototipo de la interfaz;interfaces externas – definiciónde las interfaces con otro software o con hardware;iv) confiabilidad - especificación del nivel de desempeño del software con respecto a lamadurez, tolerancia a fallas y recuperación;v) eficiencia - especificación del nivel de desempeño del software con respecto al tiempoy a la utilización de recursos;vi) mantenimiento - descripción de los elementos que facilitarán la comprensión y larealización de las modificaciones futuras del software;vii) portabilidad - descripción de las características del software que permitan sutransferencia de un ambiente a otro;viii) restricciones de diseño y construcción - necesidades impuestas por el cliente;ix) interoperatividad – la capacidad de que dos o más sistemas o componentes puedanintercambiar información y usarla;x) reusabilidad - propiedad de todo producto o subproducto de software o parte de él,para que pueda aprovecharse o utilizarse por varios usuarios como producto final oen el desarrollo del propio software o la realización de otros productos software;xi) legales y reglamentarios - necesidades impuestas por leyes, reglamentos, entreotros.

Utilizar alguna de las técnicas de recolecciónpara hacer el levantamiento de requisitos.

Actividad 7

Generarel documento de Especificación de requisitos considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Descargar ejemplo:Especificación de requisitos (dms_especificacion_de_requisitos.doc)

Plantilla propuesta para realizar la actividad:

Descargar plantilla:Especificación de requisitos

(dms_especificacion_de_requisitos_plantilla.doc)

Nota: Si no utiliza la plantilla propuesta para el documento Especificación de Requisitos, debe de asegurarse que la plantilla que utilicen contenga como mínimo todas las siguientes puntos:

1. Introducción.2. Funcionales.3. Interfaz con usuario.4. Interfaces con otro software y hardware.5. Confiabilidad.6. Eficiencia.7. Mantenimiento.8. Portabilidad.9. Interoperatividad.10. Reusabilidad.11. Restricciones de diseño y construcción.12. Legales y reglamentarios.

Nota 2: Si los requisitos del proyecto piloto no contemplan algún requisito mencionado en la lista superior, no borrar el elemento, solo especificar que no tiene ese tipo de requisito

Ejemplo: Requisitos de Reusabilidad: El software no tiene requisitos de reusabilidad.

Actividad 8

En base a los requisitos del proyecto piloto elaborar un prototipo de interfaz con el usuario.

b. Manual de Usuario Preliminar

A2.10. Documentar la versión preliminar del Manual de Usuario o modificar el manualexistente.

Documentar la versión preliminar del Manual de usuario en base a los requisitos obtenidos por el cliente, y el prototipo de interfaz de usuario, El manual de usuario preliminar puede contener solamente la descripción del prototipo y su funcionalidad. En la fase de integración y pruebas se realizara la documentación definitiva del Manual de Usuario.

Actividad 9

Elaborar el documento de Manual de Usuario preliminar del proyecto piloto a presentar en la verificación.

Descargar ejemplo:Manual de Usuario (dms_manual_de_usuario.doc)


Descargar plantilla:Manual de Usuario

(dms_manual_de_usuario_plantilla.doc)

c. Configuración de Software

A2.13. Incorporar Especificación de Requisitosy Manualde Usuario a la Configuración de Software.

Conjunto consistente de productos de software, que incluye:a) Especificación de Requisitos;b) Análisis y Diseño;c) Software;d) Manual de Usuario;e) Manual de Operación;

Recolectar el documento de Especificación de Requisitos y el Manual de Usuario Preliminar e incorporarlos a la Configuración de software

Actividad 10

Generar la Configuración de Software en un archivo comprimido (zip o rar) con el documento de Especificación de requisitos y manual de usuario preliminar del proyecto piloto y subirla como tarea para revisión.

Nota: Únicamente las versiones finales de los documentos de Especificación de requisitos y manual de usuario preliminar.

7. Diagrama de flujo de la Fase de Requisitos


Fase de Requisitos


A2. Fase de RequisitosRol Descripción de la tarea

RDM A2.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo alPlan de Desarrollo actual.

AN CL US DU

A2.2. Documentar o modificar la Especificación de Requisitos.

•Identificar y consultar fuentes de información (clientes, usuarios, sistemas previos, documentos, etc.) para obtener nuevos requisitos. •Analizar los requisitos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto.

Actividades

2. Diseñar un diagrama de flujo

Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A2. Fase de requisitosy los productos generados en cada una de ellas.

Para realizar este ejercicio, se puede consultar el Modelo de

•Elaborar o modificar el prototipo de la interfaz con el usuario.•Generar o actualizar la Especificación de Requisitos.

RM A2.10. Documentar la versión preliminar del Manual de Usuario o modificar el manualexistente.

RDM A2.13. Incorporar Especificación de Requisitosy Manualde Usuario a la Configuración de Software.

Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos). (ver anexo MoProSoft v1.3 - Por Niveles de Capacidad de Procesos.pdf)





RecomendacionesPara el diseño del diagrama de flujo puede utilizarse simbología básica, notación 1UML o notación 2BPMN y/o usar herramientas de apoyo como por ejemplo Microsoft Visio, StarUML o BizAgiProcessModeler.

1UML - Lenguaje Unificado de Modelado (por sus siglas en inglés, UnifiedModelingLanguage).

2BPMN- Notación para el Modelado de Procesos de Negocio (por sus siglas en inglés, Business ProcessModelingNotation).

8. Fase de Análisis y Diseño

A3Fase de Análisis y Diseño

• Análisis y Diseño: Conjunto de actividades en las cuales se analizanlos requisitos especificados para producir una descripción de laestructura de los componentes de software, la cual servirá de basepara la construcción. Como resultado se obtiene la documentación delAnálisis y Diseño y Plan de Pruebas de Integración.

Minuta



Formal • Minuta de reunión con el equipo de trabajo donde se asignen tareas según su rol de acuerdo al Plan de Desarrollo. Informal• Comunicación directa con el equipo de trabajo, para asignarle tareas según su rol, sin generar evidencia alguna.

a. Análisis y Diseño

A3.2. Documentar o modificar el Análisis

Documento que contiene la descripción textual y gráfica de la estructura de los componentes de software. Actividad 12

y Diseño:

•Analizar la Especificación de Requisitos para generar la descripción de laestructura interna del sistema y su descomposición en subsistemas, y éstos a suvez en componentes, definiendo las interfaces entre ellos.

•Describir el detalle de la apariencia y el comportamiento de la interfaz con base enla Especificación de Requisitos de forma que se puedan prever los recursospara su implementación.

•Describir el detalle de los componentes que permita su construcción de maneraevidente.

•Generar o actualizar el Análisis y Diseño.

¿Cuál es la estructura del sistema? ¿Qué componentes lo forman? ¿Cómo se relacionan esos componentes? ¿Cuál es el detalle de cada componente? ¿Cómo debo construir cada componente? ¿Cómo podré probar cada componente?

¿Qué lleva el documentode análisis y diseño?

Descripción Arquitectónica. Contiene la estructura interna del sistema, es decir, la descomposición en subsistemas. Así como la identificación de los componentes que integran los subsistemas y las relaciones de interacción entre ellos.

Descripción Detallada. Contiene el detalle de los componentes que permita de manera evidente su construcción y prueba en el ambiente de programación.

Actividades principales del diseño

Interacción entre los objetos: Diagrama de Interacción Estructura estática del sistema: Diagrama de Clases

Interacción entre objetos

Figura 51 Ejemplo Diagrama de Interacción

Estructura estática

Generarel documento de análisis y diseño considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Descargar ejemplo:Análisis y diseño (dms_analisis_y_diseño.doc)

Descargar ejemplo:Análisis y diseño – Modelo Funcional(dms_analisis_y_diseño_modelo_funcional.doc)


Descargar plantilla:Análisis y diseño(dms_analisis_y_diseño_plantilla.doc)

Descargar plantilla:Análisis y diseño– Modelo Funcional

(dms_analisis_y_diseño_modelo_funcional_plantilla.doc)

Nota: Si no utiliza la plantilla propuesta para el documento análisis y diseño, debe de asegurarse que la plantilla que utilicen contenga como mínimo las siguientes puntos:

Descripción Arquitectónica y descripción detallada

Figura 51 Ejemplo Diagrama de Clases

b. Configuración de Software

A3.10. Incorporar Análisis y Diseño a la Configuración de Software.


Recolectar el documento de Análisis y Diseño e incorporarlos a la Configuración de software

Actividad 13

Agregar el documento Análisis y Diseño del proyecto piloto a la Configuración de Software (archivo “rar” o “zip”), y subirla como tarea, para revisión.

Nota: Únicamente la versión final del documento de Análisis y Diseño.

9. Diagrama de flujo de la Fase de Análisis y Diseño


Fase de Análisis y Diseño


A3. Fase de Análisis y DiseñoRol Descripción de la tarea


Actividades


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A3. Fase de análisis y diseño y los

AN DIDU

A3.2. Documentar o modificar el Análisis y Diseño:• Analizar la Especificación de Requisitos para generar la descripción de la estructura interna del sistema y su descomposición en subsistemas, y éstos a su vez en componentes, definiendo las interfaces entre ellos.• Describir el detalle de la apariencia y el comportamiento de la interfaz con base en la Especificación de Requisitos de forma que se puedan prever los recursos para su implementación.• Describir el detalle de los componentes que permita su construcción de manera evidente.• Generar o actualizar el Análisis y Diseño.

RDM A3.10. Incorporar Análisis y Diseño a la Configuración de Software.

productos generados en cada una de ellas.








10. Fase de Construcción

A4Fase de Construcción

• Construcción: Conjunto de actividades para producir Componente(s)de software que correspondan a los definidos en la fase de análisis y Diseño, así como larealización de pruebas unitarias. Como resultado se obtienen el (los)Componente(s) de software probados.

Minuta A4.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo alPlan de Desarrollo



Informal

actual. Comunicación directa con el equipo de trabajo, para asignarle tareas según su rol, sin generar evidencia alguna.

a. Componentes

A4.2. Construir o modificar el(los) Componente(s) de software:•Implementar o modificar Componente(s) con base a la parte detallada del Análisisy Diseño.

En base al documento análisis y diseño, construir el software utilizando el lenguaje de programación especificado en el documento de Especificación de Requisitos, elemento requisitos de diseño y construcción.

Actividad 13

Construir los componentes e ir subiendo avances semanalmente sobre el progreso de estos.

b. Configuración de Software

A4.5. Incorporar Componentes a la Configuración de Software.


Recolectar los componentes e incorporarlos a la Configuración de software

Actividad 14

Agregar los componentes de software a la Configuración de Software (archivo “rar” o “zip”), y resguardarla en la Base de Conocimiento de la organización

.

11. Diagrama de flujo de la Fase de Construcción


Fase de Construcción


A4. Fase de ConstrucciónRol Descripción de la tarea


PR A4.2. Construir o modificar el(los) Componente(s) de software:• Implementar o modificar Componente(s) con base a la parte detallada del Análisis Diseño.

RDM A4.5. Incorporar Componentes a la Configuración de Software.

Actividades


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A4. Fase de construcción y los productos generados en cada una de ellas.








12. Fase de integración y Pruebas

A5Fase de Integración y Pruebas

• Integración y Pruebas. Conjunto de actividades para integrar y probarlos componentes de software, con la finalidad de obtener el Software quesatisfaga los requisitos especificados. Se genera la versión finaldel Manual de Usuario y Manual de Operación. Como resultado se obtiene el producto de Softwareprobado y documentado.

Minuta




Informal Comunicación directa con el equipo de trabajo, para asignarle tareas según su rol, sin generar evidencia alguna.

a. Software

A5.2. Realizar integración.•Integrar los componentes en subsistemas o en el sistema del Software

Integrar los componentes en subsistemas o en el sistema Software

b. Manual de Operación

A5.3. Documentar el Manual de Operación o modificar el manual existente.

Documento electrónico o impreso que contenga la información indispensable para la instalación y administración del software, así como el ambiente de operación (sistema operativo, base de datos, servidores, etc.), éste deberá ser redactado en términos comprensibles al personal responsable de la operación.

Elementos propuestos para el manual de operación:• Configuración

– Pasos de Instalación• Software• Base de Datos• Aplicación

– Pasos de Parametrización• Configuración de Base de Datos• Configuración del Software

• Ambiente de Operación– Hardware y Software

• Características

Actividad 16

Generarelmanual de operación considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Descargar ejemplo:Manual de Operación(dms_manual_de_operacion.doc)


Descargar plantilla:Manual de Operación

(dms_manual_de_operacion_plantilla.doc)

c. Manual de Usuario

A5.8. Documentar el Manual de Usuario o modificar el existente.

Documento electrónico o impreso que describe la forma de uso del software con base a la interfaz del usuario. Éste deberá ser redactado en términos comprensibles a los usuarios.

Preguntas que deben hacerse para hacer el Manual de Usuario

1. ¿Qué hace el software, para qué sirve? Describir en forma breve que hace el software, cuál es su utilidad. Explicando primero a grandes rasgos de qué se trata el software y después tratando los diferentes puntos específicos relacionados al software.

2. ¿Cómo funciona el software?Explicar la manera en que el software hace las cosas pues puede haber muchas formas distintas de obtener un resultado final o de hacer algo.

3. ¿Cuales son los conceptos usados por el programa?Explicar los diferentes conceptos involucrados en el programa.La idea es explicar con más detalle lo que significa cada cosa.

4. ¿Qué necesita saber el usuario para usar el programa?Explicar una "guía breve" que será como un compendio, y aparte tendrá todo tipo de instrucciones para usar el programa, así como ejemplos, tutoriales y recomendaciones. Además explicar cuestiones como: ¿Qué necesita tener o conseguir antes de instalarlo?, ¿Cómo instalarlo?, ¿Cómo configurar el programa?

Actividad 17

Generarelmanual de usuario considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.

Nota: Actualizar el manual de usuario preliminar a Manual de Usuario (versión final)

Descargar ejemplo:Manual de Usuario (dms_manual_de_usuario.doc)


Descargar plantilla:Manual de Usuario

(dms_manual_de_usuario_plantilla.doc)

d. Configuración de Software

A5.11. Incorporar Software, Manual de Operación y Manual de Usuario a la Configuración de Software.


Recolectar el manual de operación y el manual de usuario e incorporarlos a la Configuración de software

Actividad 18

Agregar el Software, manual de operación y manual de usuario a la Configuración de Software (archivo “rar” o “zip”), y resguardarla en la Base de Conocimiento de la organización

Actividad 19

Subir la ultima versión de la configuración de Software para revisión que contenga únicamente los siguientes documentos:

1. Especificación de Requisitos2. Análisis y Diseño

3. Manual de Usuario4. Manual de Operación

13. Diagrama de flujo de la fase de Integración y Pruebas


Fase de Integración y Pruebas


A5. Fase de Integración y PruebasRol Descripción de la tarea

RDM A5.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.

PR RPU

A5.2. Realizar integración. Integrar los componentes en subsistemas o en el sistema del Software

RM A5.3. Documentar el Manual de Operación o modificar el manual existente.

RM A5.8. Documentar el Manual de Usuario o modificar el existente.

RDM A5.11. Incorporar Software, Manual de Operación y Manual de Usuario a de Software.

Actividades


Utilizando la notación, simbología o herramienta que considere más indicada, desarrolle un diagrama de flujo, donde se especifiquen las tareas de la actividad A5. Fase de Integración y Pruebas y los productos generados en cada una de ellas.






Web viewActividades / Productos de Trabajo: Tareas. Teoría. Actividad de Aprendizaje....

Documents

Transcript of Web viewActividades / Productos de Trabajo: Tareas. Teoría. Actividad de Aprendizaje....