viernes, 10 de marzo de 2017

PARCIAL 2
UNIDAD 2. ANALISIS DE REQUERIMIENTOS
En este segundo parcial en la materia de análisis y diseño de sistemas trabajamos la segunda unidad que se llama análisis de requerimientos sobre proyectos consistes en cuatro subtemas muy importantes que desempeñan el desarrollo de los proyectos de una manera concisa  los cuales son los siguientes:
Técnicas de Recolección de datos: esta parte se representa como la obtención de información que te ayudara a saber las problemáticas las cuales pude solucionar tu proyecto además tiene como objetivo sacar estadísticas de características que puede solucionar y administrar tu proyecto para poder proponer las soluciones más específicas que sean más favorables para el proyecto.
Análisis de requerimientos: Se refiere al análisis de resultados de la obtención de información en nuestro caso de nuestro proyecto realizamos una encuesta para saber las problemáticas y una entrevista donde obtuvimos puntos vista de varias personas sobre las problemáticas que quiere solucionar nuestro proyecto después de esto trabajamos en obtener más información sobre las problemáticas que mencionaron en la entrevista y sobre ,a encuesta graficamos sus estadísticas para mejor manejo de la información
Casos de uso: Identifica de manera muy compleja como va a trabajar nuestro proyecto con los usuarios o respecto a la solución que quiere llegar nuestro proyecto la representamos en un diagrama de como funcionaria el manejo de nuestro proyecto con los usuarios que  lo usarían esto lo realizamos de esta manera para que los usuarios entendieran cual es el objetivo del proyecto.
Documentación de requisitos: En esta parte de la unidad representamos dos características muy importantes y muy indispensables sobre el proyecto que son requerimientos funcionales y requerimientos no  funcionales.

¿Qué son los requerimientos funcionales?
Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.
¿Qué son los requerimientos no Funcionales?

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.


Bibliografías

Monografias. (s.f). Obtenido de Requerimientos de informacion: http://www.monografias.com/trabajos12/recoldat/recoldat.shtml
Recoleccion de informacion. (l). Obtenido de monografias: http://www.monografias.com/trabajos16/recoleccion-datos/recoleccion-datos.shtm
Requerimientos de Datos. (s.f.). Obtenido de monografias: http://www.monografias.com/trabajos18/recoleccion-de-datos/recoleccion-de-datos.shtml

http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requerimiento.pdf  http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm                                                                            

Casos de uso . (s.f.). Obtenido de http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf                                                                                   

Junta de Andalucia. (s.f.). Obtenido de http://www.juntadeandalucia.es/servicios/madeja/contenido/libro-pautas/182



Procesos para planear la programación de proyectos.

Planificación y programación de proyectos
En términos generales, Planificar un proyecto consiste en definir los objetivos, el trabajo a realizar, los recursos disponibles, el plazo y el presupuesto. Más concretamente, en la fase de planificación debemos:
1.    Definir el proyecto, especificando los objetivos, recursos disponibles, tiempo necesario y presupuesto general.
2.    Dividir el trabajo (fases, departamentos, servicios.
3.    Dividir el trabajo en actividades o tareas.
4.    Representar el diagrama de descomposición del trabajo adecuado.
5.    Establecer las relaciones de precedencia entre actividades.
6.    Estimar la duración de las actividades determinando los recursos implicados y estimando las necesidades de éstos por parte de las actividades.
Por otra parte, programar es establecer un calendario de ejecución del proyecto. Por tanto, una buena programación debe tener en cuenta tiempos, recursos y costes.
Objetivos y ámbito del proyecto
La clave para empezar con éxito un proyecto es que tengamos los términos de referencia bien establecidos. Para ello, debemos conocer la autoridad y el patrocinador, los objetivos, el ámbito, las restricciones, los costes y /o presupuesto, los recursos, las entregas, las fases del proyecto, las estrategias, riesgos, hipótesis, roles y responsabilidades.
Un aspecto muy importante para mantener el apoyo de la organización es que los objetivos del proyecto estén en perfecta conexión con los de aquella y además que se hagan explícitos. En síntesis podemos decir que las principales razones para el establecimiento de objetivos son:
· Proporcionar una dirección
· Enfocar los resultados
· Permitir que se lleven a cabo los planes
· Priorizar y organizar el trabajo
· Motivar al personal
· Comunicar el propósito del proyecto
· Permitir que se reconozca el éxito
 En general, los objetivos deben ser:
· Coherentes y alineados con los objetivos de la organización
· Alcanzables
· Consistentes
· Fáciles de entender
· Pocos en número
El éxito en las funciones de planificación y control depende de la correcta definición del ámbito del proyecto y el diagrama de descomposición del trabajo puede ser una herramienta muy útil en este sentido. Este diagrama es similar a un diagrama de organización. La parte superior del diagrama representa el proyecto, que es subdividido en elementos más pequeños en el siguiente nivel, hasta que en el nivel inferior aparecen los paquetes de trabajo. Podemos decir que el diagrama de descomposición del trabajo es un prerrequisito, que une el proyecto a nivel global con el método del camino crítico. Este método requiere una completa lista de las actividades del proyecto, que pueden ser desarrolladas a partir de los paquetes de trabajo.                                                                         El diagrama de descomposición del trabajo deberá poner de manifiesto el ámbito del proyecto y la responsabilidad de cada paquete de trabajo. El diseño del diagrama debe contemplar un balance adecuado entre las distintas disciplinas y localizaciones del proyecto. No hay estructuras que sean mejores que otras, algunas pueden ser adecuadas para unos ámbitos y malas para otros. La construcción del diagrama es similar a un gráfico de organización en el que cada nivel sucesivo representa una subdivisión del nivel superior. Cada elemento del diagrama debe identificarse con una breve descripción. . En cuanto al número de niveles adecuado a establecer el diagrama lo normal son tres o cuatro, aunque se pueden hacer los que se estimen oportuno. La figura 2.1 representa el proyecto de realización de una encuesta. Cada paquete de trabajo puede ser dividido, si es necesario, en una lista completa de actividades o tareas. Estas actividades son las que aparecerán en el Diagrama de Precedencias del proyecto.                                                                                               En general, existen otras formas de diseñar el diagrama de descomposición del trabajo como la subdivisión del proyecto en fases, localización, por centro de coste, departamentos, productos o cualquier otro concepto que la empresa utilice para agrupar costes o actividades. Los nodos del diagrama suelen numerarse de forma que los diferentes nodos que nacen en un nodo común, heredan de este los dígitos y añaden uno más, diferente para cada uno.
Actividades o tareas del proyecto
En general suele ser conveniente dividir el proyecto en paquetes de trabajo, ya que permite descomponerlo en partes claramente identificables. Cada una de estas partes puede descomponerse en actividades o tareas a realizar, interdependientes entre sí.
Las actividades deben tener las siguientes características:
· Ser mensurables en términos de tiempo, recursos, esfuerzo y coste
· Tener un producto final como resultado
· Tener un comienzo y un fin claro
· Ser responsabilidad de una sola persona
La información que necesitamos de cada actividad podemos resumirla como sigue:
· Descripción de la tarea
· Inputs o precondiciones necesarios
· Requerimientos de recursos con costes
· Tiempo estimado                                                                                                                                                                     
Existe un tipo especial de tarea, con duración nula, que podríamos llamar fechas clave o hitos del proyecto. Los hitos son una forma de conocer el avance del proyecto sin estar familiarizado con el mismo y simbolizan un logro, un punto, un momento en el proyecto. Muchas veces se utilizan, entre otras cosas, para:
· Proporcionar una medida del progreso del proyecto
· Comunicarse con la gente que no forma parte del equipo del proyecto
· Enfocar la atención sobre los resultados
Asignación de duraciones a las actividades                                                                                                                                          

Una vez que tenemos el proyecto dividido en actividades debemos asignar una duración a las mismas. En general, la asignación de tiempos se hará basándonos en datos históricos. Es muy importante que todas las personas implicadas en la estimación de la duración de las actividades -entre las que deben estar las que harán el trabajo- conozcan los objetivos de tiempo, coste y calidad del proyecto, lo que implica realmente la tarea y qué es lo que debe dar como resultado.

Bibliografía

Programacion en Proyectos. (s.f.). Obtenido de Metas y especificacion de programacion en proyectos: http://www.spw.cl/proyectos/programacion.htm
Programacion estratejica de proyectos. (s.f). Obtenido de Planeacion de proyectos: http://www.monografias.com/trabajos102/planeacion-estrategica-de-proyectos/planeacion-estrategica-de-proyectos.shtml
Tecnicas de Programacion en proyectos. (s.f.). Obtenido de Programacion: http://www.spw.cl/proyectos/apuntes2/cap_10.htm
Programacion estratejica de proyectos. (s.f). Obtenido de Planeacion de proyectos: http://www.monografias.com/trabajos102/planeacion-estrategica-de-proyectos/planeacion-estrategica-de-proyectos.shtml
Tecnicas de Programacion en proyectos. (s.f.). Obtenido de Programacion: http://www.spw.cl/proyectos/apuntes2/cap_10.htm