Exposicion 2

Convirtiendo en Analista
Esta redacta que grandes analistas de requisitos crecen, no se forman. Ya que el
trabajo incluye muchas "habilidades blandas" que están más orientadas a las
personas que a las tecnológicas. Todos los analistas deben decidir cuáles de los
conocimientos y habilidades corresponden a su situación y buscar activamente la
información que les permita hacer un trabajo de primera clase. Patricia Ferdinandi
(2002) describe los niveles de habilidad que los analistas de requisitos junior, deben
exhibir en varias categorías: experiencia práctica, ingeniería, gestión de proyectos,
técnicas y herramientas, calidad y personalidad.
2.3.2.1 El antiguo usuario

Estas personas tienen un conocimiento sólido del negocio y el entorno laboral, y
pueden ganarse fácilmente la confianza de sus antiguos colegas. Comprende la
forma del usuario y conocen los sistemas y procesos comerciales existentes.
En el lado negativo, que los antiguos usuarios que ahora tienen el rol de analistas
se ha visto que saben poco sobre ingeniería de software o cómo comunicarse con
los técnicos. Ya que no están familiarizados con las técnicas de modelado de
análisis, expresarán toda la información en forma textual. Los usuarios que se
conviertan en analistas de requisitos deberán aprender más sobre el aspecto
técnico del desarrollo de software para poder representar la información en las
formas más apropiadas para sus diferente audiencias.
2.3.2.2 El antiguo desarrollador

Los gerentes de proyecto que carecen de un analista de requisitos esperan que un
desarrollador haga el trabajo. Desafortunadamente, las habilidades y la
personalidad necesarias para el desarrollo de requisitos no son las mismas que las
necesarias para el desarrollo de software. Algunos desarrolladores tienen poca
paciencia con los usuarios pero , muchos desarrolladores reconocen la importancia
del proceso de requisitos y están dispuestos a trabajar como analistas cuando sea
necesario. Aquellos que disfrutan colaborar con los clientes para comprender las
necesidades que impulsan el desarrollo de software son buenos candidatos para
especializarse en el análisis de requisitos.
2.3.2.3 El experto en la materia

Ralph Young (2001) recomienda que el analista de requisitos sea un experto en la
materia, en lugar de ser un usuario típico si los requisitos son razonables, cómo
amplían el sistema existente, cómo la arquitectura propuesta debe diseñarse y los
impactos en los usuarios, entre otras áreas ". Algunas organizaciones de desarrollo
de productos contratan usuarios expertos de sus productos que tienen una amplia
experiencia en el dominio de sus empresas para que actúen como analistas o como
representantes de los usuarios. un experto en el dominio podría especificar los
requisitos del sistema para satisfacer sus propias preferencias, en lugar de abordar
las necesidades legítimas de las diversas clases de usuarios.
2.4 Proceso de Requerimientos

Son proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de
requerimientos (IR) es entregar una especificación de requisitos de software
correcta y completa
1. 7 Técnicas para obtener requerimientos de software.
2. 1. - Análisis de documentación.
3. 2.- Observación.
4. 3.- Entrevistas.
5. 4.- Encuestas o cuestionarios.
6. 5.- Mesas de trabajo (Workshops)
7. 6.- Tormenta de ideas.
8. 7.- Historia del usuario
2.4.1 Modelos de Proceso

es una simplificación o abstracción de un proceso real.
Podemos definir un modelo de procesos del software como una representación
abstracta de alto nivel de un proceso software.
Cada modelo es una descripción de un proceso software que se presenta desde
una perspectiva particular. Alternativamente, a veces se usan los términos ciclo de
vida y Modelo de ciclo de vida.
Cada modelo describe una sucesión de fases y un encadenamiento entre ellas.
Existe una gran variedad
2.4.2 Actores del Proceso

Un actor es una persona (o quizás otro sistema) que interactúa con el sistema para
realizar un casos de uso. Provee una representación de alto nivel de los requisitos
de usuario.
ACTORES EN EL DESARROLLO
DE SOFTWARE.
ROL DEL USUARIO.
EL CLIENTE DEBE ADOPTAR NUEVAS CUALIDADES ALGUNAS DE ELLAS MUY
SIMILARES A LAS DE UN PROGRAMADOR CONSERVANDO AL MISMO TIEMPO
LA ESENCIA DE LO QUE NECESITA EL SISTEMA. ¡
ROL DEL DISEÑADOR

ES EL ENCARGADO DE GENERAR EL DISEÑO DEL SISTEMA
ROL DEL ANALISTA
ES TENER LA HABILIDAD DE PODER ESTUDIAR UN PROBLEMA DE
UNA COMPLEJIDAD DETERMINANDA,
.
ROL DEL DESARROLLADOR
EXPLORAR LOS DISTINTOS AMBIENTES EN EL QUE EL SISTEMA
PUEDE SER DESARROLLADO.
ROL DEL PROBADOR
EL TESTER ES EL ENCARGADO DE ASEGURAR LA CALIDAD DE
CADA UNO DE LOS PRODUCTOS (DOCUMENTOS, PROTOTIPOS)
ROL DEL INTEGRADOR
Los implementadores entregan sus componentes probados dentro
de un espacio de trabajo de integración, mientras que los
integradores los combinan para producir una estructura.
2.4.3 Soporte y Gestión del Proceso
El objetivo principal de esta actividad es gestionar

los requisitos del sistema software a desarrollar,
ocupándose principalmente de la gestión de los
problemas en los requisitos
 Proceso de Gestión de la Documentación del Software.

Consiste en registrar la documentación producida por un
proceso o por las actividades del ciclo de vida de un proyecto,
para que dichos documentos sean accesibles por miembros de la
empresa o usuarios implicados.
 Proceso de Gestión de la Configuración del Software.
Establecer y mantener de la integridad de todos los productos de
trabajo de un proceso o proyecto y hacerlos disponibles para las
partes involucradas.
 Proceso de Aseguramiento de Calidad del Software.
Proporciona la seguridad necesaria para que los productos y
procesos software implicados en los proyectos sean conformes a
los requisitos especificados y se ajustan a los planes establecidos.
En este proceso debemos asegurar que se cumple el modelo de
calidad del producto software, para ello nuestro producto debe
cumplir las siguientes propiedades:
Proceso de Verificación del Software.
Determina que los productos software cumplen con los
requisitos especificados para ellos.
 Proceso de Validación del Software.
Determina si los requisitos especificados para un determinado
proyecto cumplen su uso específico.
 Proceso de Revisión del Software.
Ayudar a asegurar que el desarrollo del software satisface a las
partes involucradas.
 Proceso de Resolución de Problemas del Software.
Proveer mecanismos para la creación de procesos capaces de
resolver problemas y tomar acciones correctivas para remover
nuevos problemas detectados.
2.4.4 Mejora y Calidad del Proceso

es una práctica ampliamente extendida, cuyo objetivo es controlar la calidad del
software a través de la institucionalización y mejora continua de los procesos que se
utilizan para su desarrollo. Para ello, a lo largo de los últimos años han ido
surgiendo diferentes modelos para evaluar y mejorar la capacidad de los procesos
de desarrollo software y la madurez de las fábricas de software, entre los que se
puede destacar CMMI e ISO/IEC 15504.

Exposicion 2

Cargado por

Copyright:

Formatos disponibles

Exposicion 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Exposicion 2

Cargado por

Copyright:

Formatos disponibles

2.3.2.1 El antiguo usuario

2.3.2.2 El antiguo desarrollador

2.3.2.3 El experto en la materia

2.4 Proceso de Requerimientos

2.4.1 Modelos de Proceso

2.4.2 Actores del Proceso

ROL DEL DISEÑADOR

2.4.3 Soporte y Gestión del Proceso

El objetivo principal de esta actividad es gestionar

 Proceso de Gestión de la Documentación del Software.

2.4.4 Mejora y Calidad del Proceso

También podría gustarte