Ir al contenido principal

Unidad 2. Proceso de administración de proyectos de TI

 2.1 Inicio.

2.1.1 Reconocer las técnicas de recolección de requerimientos en proyectos de TI

Los requerimientos del proyecto le ayudan a entender los objetivos, entregables, alcance y otra información relativa al producto. También debería descubrir alguna información preliminar y de alto nivel acerca de los entregables del proyecto. 

A continuación se muestran algunas de las técnicas de recolección de requerimientos:

  • DFC Esta técnica incluye entrevistas y documentación de la organización con las cuales se construye la tabla de opinión del interesado. Esta tabla se analiza con diagramas, matrices y métodos de evaluación para extraer los requisitos esperados e intentar obtener requisitos innovadores. También esta técnica requiere una alta interacción con el analista.
  • Tormenta de ideas (Brainstorming) Es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de captura, cuando los requisitos son todavía muy difusos. También se requiere participación intensiva del analista.
  • Introspección Esta técnica recomienda que el analista se ponga en el lugar del interesado y trate de imaginar cómo desearía éste la aplicación de software. Basado en estas suposiciones, el analista entrega recomendaciones al interesado sobre la funcionalidad que debería tener dicha aplicación. El problema radica en que un analista no es un tipo normal de interesado, pues posee un conocimiento técnico más elevado; por ello, es posible que entre las recomendaciones haya cosas que el interesado aún no necesita o que incluso no sabe que necesitará en un futuro. En este caso, el discurso se refiere más a la solución que al dominio del problema.
  • Entrevistas Se realizan con los usuarios o interesados clave. Direccionan al usuario hacia aspectos específicos del requerimiento a levantar. Son útiles para obtener y documentar información detallada sobre los requerimientos y sus niveles de granularidad. Pueden ser entrevistas formales o informales. Una clave es mantenerse enfocado en los objetivos de la entrevista. Las preguntas abiertas son útiles para identificar información faltante. Las preguntas cerradas son útiles para confirmar y validar información. El éxito de las entrevistas depende del grado de conocimiento del entrevistador y entrevistado, disposición del entrevistado de suministrar información, buena documentación de la discusión y en definitiva de una buena relación entre las partes.
  • Historia del usuario Las historias de usuario, son una aproximación simple al levantamiento de requerimientos de software, en la cual la conversación pasa a ser más importante que la formalización de requerimientos escritos. Es recomendable que sean escritas por el mismo cliente o interesado (con apoyo del facilitador si es necesario), con énfasis en las funcionalidades que el sistema deberá realizar. Al redactar una historia de usuario deben tenerse en cuenta describir el Rol, la funcionalidad y el resultado esperado de la aplicación en una frase corta. Las historias de usuario son una de las técnicas más difundidas para levantar requerimientos de software en metodologías ágiles.

2.2 Identificar las necesidades y expectativas de las partes interesadas en proyectos de TI


Una parte interesada es toda aquella persona interna y/o externa u organización que tiene o puede tener capacidad para afectar en la actividad de nuestra organización: clientes, proveedores, trabajadores, propietarios de una organización, inversores, competidores, legisladores, organismos públicos, la sociedad en general.

¿Cómo identificamos las partes interesadas en ISO 9001:2015?


Al ser una nueva tarea dentro de la norma ISO 9001:2015, este punto nos puede resultar confuso así que te listaré algunas claves para que puedas realizar una selección inicial que ya irás afinando con el tiempo y la experiencia. 
  • Tener en cuenta aquellos con los que la empresa tiene una responsabilidad legal, operativa o fiscal, no olvidando aquellas partes interesadas con las que se tienen establecidos contratos, así como las leyes vigentes o las políticas o prácticas vigentes, como por ejemplo socios de negocios, administraciones, subcontratados, etc.
  • Personas que tienen influencia para impedir o impulsar la actividad de la empresa, como pueden ser, por ejemplo, accionistas o ONGs.
  • Tener en cuenta aquellas personas y empresas que se encuentren en las zonas donde la empresa interactúa ya que pueden ser afectadas por la actividad de la empresa y, a su vez, influyen en la buena marcha de esta.
  • Clientes 
  • Proveedores
  • Personas que tienen una representación clara de grupos de interés como representantes sindicales
Referencias.

Comentarios

Publicar un comentario

Entradas más populares de este blog

Análisis Y Sintesis De Información

Análisis Y Sintesis De Información ¿Qué es una síntesis?   Una síntesis es un escrito donde se exponen las ideas principales de un texto tras su análisis y comprensión. Estas ideas se corresponden con la opinión del autor y ayuda a una mejor comprensión del mismo para facilitar su entendimiento o estudio, por lo que son expresadas con las palabras de la persona que redacta la síntesis. En una síntesis analizamos estas ideas y las expresamos desde nuestro punto de vista, aunque también deban corresponderse con la opinión del autor. Es decir, debemos de comprender el texto, analizarlo, agrupar sus ideas y luego escribirlas pasadas por nuestro propio filtro. Cómo hacer una síntesis Para redactar una síntesis sobre un ensayo o texto leído debemos de seguir los siguientes pasos: 1)           Leer el texto con atención una primera vez. 2)           Releer el texto, pero esta vez subrayando las ideas principales 3)           Asegúrese de haber entendido correctamente
Publicar un comentario
Leer más

Metodologías de Desarrollo tradicionales: cascada, modelo en V y espiral.

Metodologías de Desarrollo tradicionales MODELO V El Método-V es una representación gráfica del ciclo de vida del desarrollo del sistema. Resume los pasos principales que hay que tomar en conjunción con las correspondientes entregas de los sistemas de validación. La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema. La parte derecha de la V representa la corriente donde se comprueba el sistema (contra las especificaciones definidas en la parte izquierda). La parte de abajo, donde se encuentran ambas partes, representa la corriente de desarrollo.          La corriente de especificación consiste principalmente de: ·           Especificaciones de requerimiento de usuario ·           Especificaciones funcionales ·           Especificaciones de diseño La corriente de pruebas, por su parte, suele consistir de: ·           Calificación de instalación ·           Calificación operacional ·           Calificación de ren
Publicar un comentario
Leer más

Modelado UML

Modelado UML El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso. Semántica y Notación Una de las metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación. La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado.  El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:
Publicar un comentario
Leer más