Web viewLa 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

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

Especificación de requisito

s

La Especificación de Requisitos Software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto 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

Actividad 1

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

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:

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

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

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.

¿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:

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

EntrevistasCuestionariosTalleres de Recolección de RequisitosLluvia de IdeasObservar cómo trabajan los usuariosPrototiposCasos de uso (Escenarios)Técnicas

Pantalla 4Técnicas para recolectar requisitos

Existen diversas técnicas de recolección de 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).

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

Actividad 3

Instrucciones: Descarga el siguiente documento: Anexo 1(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)

DW y PW:

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

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

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

Actividad 5

En base al anexodms_anexo_1.docxRealizar las siguientes actividades:

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

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 texto

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

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.

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?

¿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?

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 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 Mantenimiento de Software

Temas Pantalla

Contenido Actividades Instrucciones Dw Y Pw

a. Propósitosb. objetivos

10 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 o modificados cumpliendo con los requerimientos especificados.

Objetivos e Indicadores

Actividad. Cuestionario PropósitosInstrucciones: Con base en la información revisada, responde las siguientes preguntas.Al finalizar la actividad, da clic en el botón “Guardar” para que esta sea almacenada en tu carpeta de trabajo.

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

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.

Insertar botón actividade

¿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?

¿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

11 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. Ver imagen

Asignación de roles

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

Roles involucrados por actividad:

Rol CapacitaciónResponsable 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.

Actividad. Cuestionario Roles

Instrucciones: Con base en la información revisada, responde las siguientes preguntas.Al finalizar la actividad, da clic en el botón “Guardar” para que esta sea almacenada en tu carpeta de trabajo.

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

¿Cuáles son los roles involucrados en el proceso deDesarrollo 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?

Ligar Ver imagen, con el esquema de los muñequitos.

Ligar actividad

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.

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.

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.

Insertar botón actividad

Cliente (CL)

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

Usuario (US)Ninguna.

d. Procesos relacionados

12 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: Ver imagen Administración de Proyectos Específicos

.

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


Actividad. CuestionarioInstrucciones: Con base en la información revisada, responde las siguientes preguntas.Al finalizar la actividad, da clic en el botón “Guardar” para que esta sea almacenada en tu carpeta de trabajo.

¿Cómo se relacionan los procesos de MoProSoft?

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

Ligar Ver imagen, con el esquema de flujo

e. Ciclo de actividades

13 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 fases donde se realizan ciertas actividades para generar los productos. La distribución de tareas, se asignan las responsabilidades de cada miembro del Equipo de Trabajo de acuerdo al Plan de Desarrollo.En la siguiente imagen, se muestra claramente (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.

Actividad. Cuestionario- Ciclo de actividadesInstrucciones: Con base en la información revisada, responde las siguientes preguntas.Al finalizar la actividad, da clic en el botón “Guardar” para que esta sea almacenada en tu carpeta de trabajo.

¿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?

Animar el esquema de ciclo 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

Pruebas6. Fase de Cierre7. Entregable8. Llamada Ovalada

Coloca el cursor en cada recuadro para visualizar la información

____

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

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

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

• Construcción: Conjunto de actividades para producir Componente(s) de software que correspondan al Análisis y Diseño, así como la realizació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 de Integración y de Sistema, con la finalidad de obtener el Software que satisfaga los requisitos especificados. Se genera la versión final del Manual de Usuario, Manual de Operación y Manual de Mantenimiento. Como resultado se obtiene el producto de Software probado y documentado.

• Cierre: Integración final de la Configuración de Software generada en las fases para su entrega. Identificación y documentación de las Lecciones Aprendidas. Generación del Reporte de Mediciones y Sugerencias de Mejora._____


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

¿Qué roles participan en cada actividad?

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

Al colocar el cursor en cada recuadro aparecerá la información correspondiente en gris.

Ligar actividad Cuestionario

4.Fase de Inicio14

Fase de InicioAnimar el esquema de fase de inicio. Que se presente la imagen y al colocar el cursor en el recuadro ROJO, que aparezca la información correspondiente en gris.

Coloca el cursor en el recuadro rojo para visualizar la información____

•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

Como primera tarea de este proceso el Responsable de Desarrollo y Mantenimiento de Software el RDM 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 Inicio16

Fase de Inicio

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

A1. Fase de InicioRol Descripción de la tareaET A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual para lograr

un entendimiento común y obtener su compromiso con el proyecto.


Actividad. Diseñar Diagrama de FlujoInstrucciones: Utilizando la notación, simbología o herramienta que considere más indicada, desarrolla un diagrama de flujo, donde se especifiquen las tareas de la actividad Fase de Inicio y los productos generados en cada una de ellas.

Para realizar esta actividad puedes consultar el Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos).

Nota: Considera 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 presenta un esquema de diagrama de flujo, a manera de Ejemplo.

Ligar actividad con el documento descargable correspondiente:

Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos.dms_moprosoft_niveles.pdf (carpeta docs_pdf)

Ligar Ejemplo. con la imagen del diagrama que se muestra enseguida.

Tooltip para la referencia:

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

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

Al finalizar coloca el documento en tu carpeta de trabajo para que sea revisado por el Asesor.

6.Fase de Requisitos17 Fase de Requisitos

Coloca el cursor en el recuadro rojo para visualizar la información

_____

•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 el cliente y el proyecto.---------

MINUTA

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.

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

Animar el esquema. Que se presente la imagen y al colocar el cursor en el recuadro ROJO, que aparezca la información correspondiente en color gris.

a. Especificación de Requisitos

18. Guías para la especificación de requisitos Actividad. Especificación de Requisitos. Ligar Especificaciones y Requisitos. con el documento:

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.

Para profundizar en el tema, revisa y descarga el documento Especificaciones y Requisitos.

Insertar botón de actividad

Instrucciones: Genera el documento de Especificaciones de Requisitos, considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.Descarga los documentos: ejemplo y la plantilla para realizar esta actividad. Nota 1: 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 requisitoEjemplo: Requisitos de Reusabilidad: El software no tiene requisitos de reusabilidad.

Asimismo, con base en los requisitos del proyecto piloto, elabora un prototipo de interfaz con el usuario.


dms_t6a_especif_requisitos.pdf (carpeta docs_pdf)

Ligar actividad y los documentos correspondientes para la actividad.Ejemplodms_t6a_ejem_especif_requisitos.doc

Plantilladms_t6a_plantilla_especif_requisitos.doc

Ambos documentos están en la carpeta de docs_act

b. Manual de Usuario Preliminar

c. Configuración de Software

19 Manual de Usuario Preliminar

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.

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 a. Manual de UsuarioInstrucciones: Elabora el Manual de usuario preliminar del proyecto piloto a presentar en la verificación.Para realizar la actividad descarga el Manual de usuario así como la propuesta de plantilla.


Actividad b. Configuración de Software.Instrucciones: Genera 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.

Al finalizar, coloca únicamente en tu carpeta de trabajo las versiones finales de los documentos de Especificación de requisitos y manual de usuario preliminar, para que sea revisado por el Asesor.

Ligar actividad y los documentos correspondientes para la actividad.Manual de usuariodms_t6b_manual_usuario.doc

Plantilladms_t6b_plantilla_manual_usuario.doc

Ambos documentos están en la carpeta de docs_act.

7.Diagrama de flujo de la Fase de Requisitos20 Fase de Requisitos


Actividad. Diagrama de FlujoInstrucciones: 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 Fase de requisitos y los productos generados en cada una de ellas.

Para realizar esta actividad puedes consultar el Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos).

Nota: Considera solamente las tareas correspondientes a



Ligar Ejemplo con la imagen del diagrama que se muestra enseguida.

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


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 presenta un esquema de diagrama de flujo, a manera de ejemplo.

RecomendacionesPara el diseño del diagrama de flujo puedes utilizar simbología básica, notación 1 UML o notación 2 BPMN 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ño21 Fase 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

b. Configuración de Software

22 Análisis y Diseño

Documento que contiene la descripción textual y gráfica de la estructura de los componentes de software. ¿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?

Para profundizar en este tema, revisa y descarga el documento ¿Qué lleva el documento de análisis y diseño?.

Configuración del Software


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


Actividad a. Análisis y Diseño.

Instrucciones: Genera el documento de análisis y diseño, considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.Revisa los siguientes ejemplos y descarga las plantillas propuestas para realizar esta actividad:Ejemplo1,Ejemplo 2:Plantilla 1Plantilla 2

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


Actividad b. Configuración del Software

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.

Al finalizar coloca únicamente en tu carpeta de trabajo, la versión final del documento de Análisis y Diseño, para que sea revisado por el Asesor.

Ligar ¿Qué lleva el documento de análisis y diseño?

dms_t8a_doc_analisis_diseno.doc (carpeta de docs_pdf)

Ligar actividad y los documentos correspondientes para la actividad.Ejemplo1dms_t8a_ejem1_analisis_diseno.doc

Ejemplo2dms_t8a_ejem2_analisis_diseno.doc

Plantilla 1dms_t8a_plantilla1_ analisis_diseno.doc

Plantilla 2dms_t8a_plantilla2_ analisis_diseno.doc

Los cuatro documentos están en la carpeta de docs_act

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



Actividad. Diagrama de Flujo.

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

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


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






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


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.

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


10.Fase de Construcción24 Fase 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



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


a. Componentes

b. Configuraci

25 Componentes

En base al documento análisis y diseño, construir el software utilizando el lenguaje de programación especificado en el documento de

Actividad a. Componentes.

Instrucciones: Construye los componentes e ir

ón de software

Especificación de Requisitos, elemento requisitos de diseño y construcción.

Configuración de Software


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


subiendo avances semanalmente sobre el progreso de estos.De igual manera, agrega 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ón26 Fase de Construcción



Actividad. Diagrama de flujo

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

Para realizar esta actividad, puedes consultar el Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por Niveles de Capacidad de Procesos.




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.







12.Fase de integración y Pruebas27 Fase de Integración y Pruebas Animar el esquema.

Que se presente la imagen y al colocar el cursor en el recuadro

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.

---------------•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 Software probado y documentado.---------------

MINUTA



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

ROJO, que aparezca la información correspondiente en color gris.

a. Softwareb. Manual de

Operación

28 SoftwareIntegrar los componentes en subsistemas o en el sistema Software

Manual de Operación 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. Manual de Operación

Instrucciones: Genera el manual de operación considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.Descarga y revisa el ejemplo y la propuesta de plantilla para realizar esta actividad.

Al finalizar coloca el documento en tu carpeta de trabajo para que sea revisada por el Asesor.

Ligar actividad y los documentos correspondientes.Ejemplodms_t12b_ejem_manual_operacion.doc

Plantilladms_t12b_plantilla_manual_operacion.doc


c. Manual de Usuario

29 Manual de Usuario

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

Actividad. Manual de Usuario

Instrucciones: Generar el manual de usuario considerando el proyecto piloto seleccionado por la organización para la implantación de MoProSoft.Para realizar esta actividad descarga y revisa el ejemplo

Ligar actividad y los documentos correspondientes.Ejemplodms_t12c_ejem_ manual_usuario.doc

Plantilla


y la plantilla propuesta.

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


)

dms_t12c_plantilla_manual_usuario.doc


d. Configuración de Software

30 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 manual de operación y el manual de usuario e incorporarlos a la Configuración de software


Actividad. Configuración de Software.

Instrucciones: Agrega 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.

De igual manera, sube la última 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ño3. Manual de Usuario4. Manual de Operación


Ligar actividad

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

Fase de Integración y Pruebas


Actividad. Diagrama de Flujo.

Instrucciones: 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


Modelo de Procesos para la Industria de Software (MoProSoft) v1.3, por


actividad Fase de Integración y Pruebas 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.




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.


Niveles de Capacidad de Procesos.dms_moprosoft_niveles.pdf (carpeta docs_pdf)




A5. Fase de Integración y PruebasRol Descripción de la tareaRDM 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.

Documents

Web viewLa 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