Estas son las distribuciones de actividades para el III Parcial:
Jean Carlo:
- Empezar el Documento explicando los actores
- Incluir las imagenes de los casos de uso en el Documento
- Explicar en detalle que hace cada caso de uso
Lenin:
- Llenar los Diagramas de Casos de Uso para cada caso de uso de los tres diagramas de caso de uso presentados en el documento.
- Incluir en el Documento con Impresiones de Pantalla todos los casos de uso terminados.
Fausto:
- Realizar el diagrama de entidad relacion para el modelo.
- Incluir el diagrama de actividades en el documento.
Jefry:
- Realizar la investigacion de Diagramas de Clases.
- Entregar investigacion en la fecha indicada.
lunes, 9 de agosto de 2010
Preguntas Capitulo 7
7.1 Mencione quienes podrían ser los skateholders en un sistema de registro de estudiantes universitarios. Explique porque es casi inevitable que los requerimientos de diferentes skateholders entren en conflicto de alguna forma.
R-/ Pues los skateholder son las personas o grupos que se verán afectados por el sistema, directa o indirectamente. En un sistema de registro de estudiantes podrían ser los estudiantes, los catedráticos, las personas de administración, las instituciones bancarias. Es inevitable que los requerimientos de los skateholders entren en conflicto porque los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos
7.5 Utilizando su conocimiento de cómo funciona un cajero automático de un banco, desarrolle un conjunto de casos de uso que podrían servir como una base para entender los requerimientos de un sistema de un cajero automático.
R-/ Los casos de uso para un cajero automático podrían ser:
1. Identificación
2. Realizar Retiro
3. Obtener Saldo de Cuenta
4. Obtener Últimos Movimientos
5. Cambiar de PIN
6. Realizar otras transacciones bancarias
7.6 De un ejemplo de un tipo de sistema en el que los factores sociales y políticos pueden influir fuertemente en los requerimientos del sistema. Explique por que estos factores son importantes en el ejemplo.
R-/ Para mí un tipo de sistema en el que los requerimientos políticos y sociales pueden influir podría ser un sistema para control de registro de personas en el cual sus necesidades de toma de información pueda cambiar de acuerdo a las legislaciones del gobierno. Otro podría ser un sistema de control de votaciones electorales en el cual los datos a registrar puedan cambiar de acuerdo al cambio en las planillas y las papeletas de votación.
7.8 ¿Por qué las matrices de rastreo son difíciles de manejar cuando existen muchos requerimientos en el sistema? Diseñe un mecanismo de estructuración de requerimientos, basado en puntos de vista, que pueda ayudar a reducir el tamaño del problema.
R-/ Las matrices de rastreo pueden utilizarse cuando se tienen que gestionar un número pequeño de requerimientos, pero son difíciles de manejar y caras de mantener para sistemas grandes con muchos requerimientos. Para sistemas con requerimientos grandes, se debería de captar la información de rastreo en una base de datos de requerimientos en la que cada requerimiento este explícitamente vinculado a los requerimientos relacionadas
7.9 Cuando se hacen cambios de emergencia en los sistemas, el sistema software puede tener que modificarse antes de que los cambios en los requerimientos se aprueben. Sugiera un modelo de proceso para hacer estas modificaciones que asegure que el documento de requerimientos y la implementación del sistema no sean compatibles.
R-/ Pues sugeriría un modelo de proceso denominado por componentes o versiones, en el cual se puedan desarrollar paralelamente los requerimientos pendientes de modificar en un componente aparate del sistema actual para que no perjudique el desempeño actual de la aplicación y al momento de aprobarlos y adaptarlos a producción ya solo se integre el componente que fue desarrollado y probado antes de ser puesto en producción.
R-/ Pues los skateholder son las personas o grupos que se verán afectados por el sistema, directa o indirectamente. En un sistema de registro de estudiantes podrían ser los estudiantes, los catedráticos, las personas de administración, las instituciones bancarias. Es inevitable que los requerimientos de los skateholders entren en conflicto porque los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos
7.5 Utilizando su conocimiento de cómo funciona un cajero automático de un banco, desarrolle un conjunto de casos de uso que podrían servir como una base para entender los requerimientos de un sistema de un cajero automático.
R-/ Los casos de uso para un cajero automático podrían ser:
1. Identificación
2. Realizar Retiro
3. Obtener Saldo de Cuenta
4. Obtener Últimos Movimientos
5. Cambiar de PIN
6. Realizar otras transacciones bancarias
7.6 De un ejemplo de un tipo de sistema en el que los factores sociales y políticos pueden influir fuertemente en los requerimientos del sistema. Explique por que estos factores son importantes en el ejemplo.
R-/ Para mí un tipo de sistema en el que los requerimientos políticos y sociales pueden influir podría ser un sistema para control de registro de personas en el cual sus necesidades de toma de información pueda cambiar de acuerdo a las legislaciones del gobierno. Otro podría ser un sistema de control de votaciones electorales en el cual los datos a registrar puedan cambiar de acuerdo al cambio en las planillas y las papeletas de votación.
7.8 ¿Por qué las matrices de rastreo son difíciles de manejar cuando existen muchos requerimientos en el sistema? Diseñe un mecanismo de estructuración de requerimientos, basado en puntos de vista, que pueda ayudar a reducir el tamaño del problema.
R-/ Las matrices de rastreo pueden utilizarse cuando se tienen que gestionar un número pequeño de requerimientos, pero son difíciles de manejar y caras de mantener para sistemas grandes con muchos requerimientos. Para sistemas con requerimientos grandes, se debería de captar la información de rastreo en una base de datos de requerimientos en la que cada requerimiento este explícitamente vinculado a los requerimientos relacionadas
7.9 Cuando se hacen cambios de emergencia en los sistemas, el sistema software puede tener que modificarse antes de que los cambios en los requerimientos se aprueben. Sugiera un modelo de proceso para hacer estas modificaciones que asegure que el documento de requerimientos y la implementación del sistema no sean compatibles.
R-/ Pues sugeriría un modelo de proceso denominado por componentes o versiones, en el cual se puedan desarrollar paralelamente los requerimientos pendientes de modificar en un componente aparate del sistema actual para que no perjudique el desempeño actual de la aplicación y al momento de aprobarlos y adaptarlos a producción ya solo se integre el componente que fue desarrollado y probado antes de ser puesto en producción.
miércoles, 21 de julio de 2010
Actividades de Tarea II Parcial
Las asignaciones de desarrollo de la Tarea de Desarrollo Diagramas de Actividades y Casos de Uso de la Propuesta UTH Virtual Grupo CALIF son:
FAUSTO A. MORAZAN:
Diagramas de Actividades
Desarrollo de Informe de Actividades y Casos de Uso
JEAN CARLO MOLINERO:
Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA:
Defiinicion de Plantillas de Caso de Uso
Exposicion de la Tarea:
LENIN RICARDO PINEDA Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA Diagramas de Actividades y Plantillas de Casos de Uso
Entrega de Informacion al Catedratico:
JEFFRY RAMON ZELAYA
FAUSTO A. MORAZAN:
Diagramas de Actividades
Desarrollo de Informe de Actividades y Casos de Uso
JEAN CARLO MOLINERO:
Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA:
Defiinicion de Plantillas de Caso de Uso
Exposicion de la Tarea:
LENIN RICARDO PINEDA Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA Diagramas de Actividades y Plantillas de Casos de Uso
Entrega de Informacion al Catedratico:
JEFFRY RAMON ZELAYA
lunes, 19 de julio de 2010
Diagrama de Caso de Uso Alarma
Un Sistema sencillo de alarma contra ladrones Capitulo 2 Figura 2.6 de Libro de Texto
miércoles, 14 de julio de 2010
Ejercicios del Capítulo 6
6.1 Identifique y comente brevemente cuatro tipos de requerimientos que se pueden definir para un sistema informático.
R-/ Requerimientos del Usuario:
Son declaraciones de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimientos Funcionales:
Son declaraciones de los servicios que debe proporcionar el sistema.
Requerimientos no Funcionales:
Son restricciones de los servicios o funciones ofrecidas por el sistema.
Requerimientos del Dominio:
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y las restricciones de ese dominio.
6.2 Comente los problemas de la utilización del lenguaje natural para definir los requerimientos del usuario y del sistema, y muestre, utilizando pequeños ejemplos, como el estructurar el lenguaje natural en formularios puede ayudar a evitar algunas de estas dificultades.
R-/ Falta de Claridad:
A veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer.
Confusión de Requerimientos:
No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la información para el diseño.
Conjunción de Requerimientos:
Diversos requerimientos diferentes se pueden expresar de forma conjunta como un único requerimiento.
6.3 Descubra las ambigüedades u omisiones en la siguiente declaración de requerimientos de una parte de un sistema expendedor de billetes.
Un sistema automático de expedición de billetes vende billetes de tren. Los usuarios seleccionan su destino e introducen una tarjeta de crédito y un número de identificación personal. El billete de tren se expide y se carga su cuenta a la tarjeta de crédito. Cuando el usuario presiona el botón de inicio, se activa un menú que muestra los posibles destinos, junto con un mensaje para el usuario que le indica que seleccione el destino. Una vez que se ha seleccionado un destino, se pide a los usuarios que introduzcan su tarjeta de crédito. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transacción de crédito se haya validado, se expide el billete.
R-/ Creo que la ambigüedad es saber si la tarjeta se debe pedir antes o después, porque para emitir el billete sin saber los datos de la persona o sin saber si su tarjeta cubre el valor del destino donde desea viajar o si el emisor de la tarjeta no está en línea, etc No se puede continuar una transacción si no se dispone de ciertos factores que la final podrían causar desgaste o malestar por los usuarios del sistema.
6.4 Vuelva a redactar la descripción anterior utilizando el enfoque estructurado descrito en este capítulo. Resuelva de forma apropiada las ambigüedades identificadas
R-/ Función: Expedición de Billetes de Tren a Clientes de forma automatizada
Descripción: Emitir billetes de tren a un destino especificado por el usuario y cancelado con el uso de una tarjeta de crédito.
Entradas: Selección del Destino del Viaje.
Salida: La impresión del boleto hacia el destino respectivo.
Acción: El cliente introduce la tarjeta de crédito para validar su identificación, selecciona el destino al que quiere viajar y una vez realizado esto verifica el monto del boleto y lo carga a su tarjeta de crédito para luego imprimir el boleto
6.7 Describa 4 tipos de requerimientos no funcionales que pueden existir en un sistema. De ejemplos de cada uno de estos tipos de requerimientos.
R-/ Requerimientos del Producto:
Ejemplo: los requerimientos de rendimiento en la rapidez de ejecución del sistema.
Requerimientos Organizacionales:
Ejemplo: Los Estándares en los procesos que deben utilizarse; los requerimientos de implementación, como los lenguajes de programación
Requerimientos Externos:
Ejemplo: No se debe revelar al personal del sistema ninguna información personal de los usuarios
6.8 Redacte un conjunto de requerimientos no funcionales para el sistema expendedor de billetes, especificando su fiabilidad y su respuesta en el tiempo.
R-/ Requerimientos del Producto:
La interfaz del usuario se puede implementar de forma táctil de manera que el usuario no utilice ni teclado o más y en ambiente de navegador de internet.
Requerimientos Organizacionales:
La Documentación del Desarrollo y Manejo del Sistema debe entregarse en un formato de fácil lectura y de compresión sencilla para el usuario pueda consultarlos en línea.
Requerimientos Externos:
El sistema debe tener conectividad con los sistemas externos de control de tarjetas de crédito para validar la información del usuario en línea.
6.10 Ha obtenido un trabajo con un usuario de software quien ha contratado a su anterior compañía para desarrollar un sistema. Usted descubre que la interpretación de su compañía actual de requerimientos es diferente de la tomada por su anterior compañía. Comente que haría en tal situación. Usted sabe que los costes de su compañía actual se incrementaran si las ambigüedades no se resuelven. También tiene una responsabilidad de confidencialidad para su anterior compañía.
R-/ Pues lo que haría es evaluar la experiencia con mi compañía anterior de desarrollo que esta mas empapada de los requerimientos que exige como usuario y la experiencia de implementación de la misma para tratar de transmitir estos requerimientos a la compañía de desarrollo nueva y así llegar a la unificación de requerimientos sin ambigüedades
R-/ Requerimientos del Usuario:
Son declaraciones de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimientos Funcionales:
Son declaraciones de los servicios que debe proporcionar el sistema.
Requerimientos no Funcionales:
Son restricciones de los servicios o funciones ofrecidas por el sistema.
Requerimientos del Dominio:
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y las restricciones de ese dominio.
6.2 Comente los problemas de la utilización del lenguaje natural para definir los requerimientos del usuario y del sistema, y muestre, utilizando pequeños ejemplos, como el estructurar el lenguaje natural en formularios puede ayudar a evitar algunas de estas dificultades.
R-/ Falta de Claridad:
A veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer.
Confusión de Requerimientos:
No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la información para el diseño.
Conjunción de Requerimientos:
Diversos requerimientos diferentes se pueden expresar de forma conjunta como un único requerimiento.
6.3 Descubra las ambigüedades u omisiones en la siguiente declaración de requerimientos de una parte de un sistema expendedor de billetes.
Un sistema automático de expedición de billetes vende billetes de tren. Los usuarios seleccionan su destino e introducen una tarjeta de crédito y un número de identificación personal. El billete de tren se expide y se carga su cuenta a la tarjeta de crédito. Cuando el usuario presiona el botón de inicio, se activa un menú que muestra los posibles destinos, junto con un mensaje para el usuario que le indica que seleccione el destino. Una vez que se ha seleccionado un destino, se pide a los usuarios que introduzcan su tarjeta de crédito. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transacción de crédito se haya validado, se expide el billete.
R-/ Creo que la ambigüedad es saber si la tarjeta se debe pedir antes o después, porque para emitir el billete sin saber los datos de la persona o sin saber si su tarjeta cubre el valor del destino donde desea viajar o si el emisor de la tarjeta no está en línea, etc No se puede continuar una transacción si no se dispone de ciertos factores que la final podrían causar desgaste o malestar por los usuarios del sistema.
6.4 Vuelva a redactar la descripción anterior utilizando el enfoque estructurado descrito en este capítulo. Resuelva de forma apropiada las ambigüedades identificadas
R-/ Función: Expedición de Billetes de Tren a Clientes de forma automatizada
Descripción: Emitir billetes de tren a un destino especificado por el usuario y cancelado con el uso de una tarjeta de crédito.
Entradas: Selección del Destino del Viaje.
Salida: La impresión del boleto hacia el destino respectivo.
Acción: El cliente introduce la tarjeta de crédito para validar su identificación, selecciona el destino al que quiere viajar y una vez realizado esto verifica el monto del boleto y lo carga a su tarjeta de crédito para luego imprimir el boleto
6.7 Describa 4 tipos de requerimientos no funcionales que pueden existir en un sistema. De ejemplos de cada uno de estos tipos de requerimientos.
R-/ Requerimientos del Producto:
Ejemplo: los requerimientos de rendimiento en la rapidez de ejecución del sistema.
Requerimientos Organizacionales:
Ejemplo: Los Estándares en los procesos que deben utilizarse; los requerimientos de implementación, como los lenguajes de programación
Requerimientos Externos:
Ejemplo: No se debe revelar al personal del sistema ninguna información personal de los usuarios
6.8 Redacte un conjunto de requerimientos no funcionales para el sistema expendedor de billetes, especificando su fiabilidad y su respuesta en el tiempo.
R-/ Requerimientos del Producto:
La interfaz del usuario se puede implementar de forma táctil de manera que el usuario no utilice ni teclado o más y en ambiente de navegador de internet.
Requerimientos Organizacionales:
La Documentación del Desarrollo y Manejo del Sistema debe entregarse en un formato de fácil lectura y de compresión sencilla para el usuario pueda consultarlos en línea.
Requerimientos Externos:
El sistema debe tener conectividad con los sistemas externos de control de tarjetas de crédito para validar la información del usuario en línea.
6.10 Ha obtenido un trabajo con un usuario de software quien ha contratado a su anterior compañía para desarrollar un sistema. Usted descubre que la interpretación de su compañía actual de requerimientos es diferente de la tomada por su anterior compañía. Comente que haría en tal situación. Usted sabe que los costes de su compañía actual se incrementaran si las ambigüedades no se resuelven. También tiene una responsabilidad de confidencialidad para su anterior compañía.
R-/ Pues lo que haría es evaluar la experiencia con mi compañía anterior de desarrollo que esta mas empapada de los requerimientos que exige como usuario y la experiencia de implementación de la misma para tratar de transmitir estos requerimientos a la compañía de desarrollo nueva y así llegar a la unificación de requerimientos sin ambigüedades
jueves, 1 de julio de 2010
Ejercicios del Capítulo 5
5.1 ¿Explique porque la intangibilidad de los sistemas de software plantea problemas para la gestión de proyectos de software.
R-/ Porque no se puede ver ni tocar, los gestores de proyectos no pueden ver el progreso, confían en otros para elaborar la documentación necesaria para revisar el progrreso.
5.2 Explique porque los mejores programadores no siempre son los mejores gestores de software. La respuesta puede tener como base la lista de actividades de gestión dadas en la sección 5.1.
R-/ Porque los gestores de software debe tener la capacidad y experiencia para crear y validar los planes de desarrollo de software y para ello deberían tener experiencia de cada una de esas labores, por lo tanto es bien difícil que un programador se involucre en todas esas labores a menos que ya tenga un buen tiempo de interactuar en diferentes áreas del proceso de desarrollo de software.
5.3Explique porque el proceso de planificación de proyectos es iterativo y porque un plan se debe revisar continuamente durante el proyecto de software.
R-/Es un proceso iterativo porque mientras dure el proyecto se deben repetir como un While: la revisión de la programación, el inicio de las actividades, revisar el progreso, revisar las estimaciones de los parámetros del proyecto, actualizar la programación del proyecto, todo esto se debe repetir hasta que se de por terminado el proyecto. El plan debe revisarse continuamente conforme la información se hace disponible acerca del progreso del proyecto, Mientras las metas globales del negocio cambien en necesario cambios en el proyecto.
5.7 La Figura 5.5 señala la duración de las tareas para las actividades del proyecto de software. Suponga que hay un serio retraso no anticipado y que en lugar de requerir 10 dias, la tarea T5 requiere 40 días. Revise la red de actividades resultante, resaltando el nuevo camino critico. Diseñe un nuevo grafico de barras que muestre como se podría reorganizar el proyecto
R-/
5.9 Además de los riesgos que se muestran en la figura 5.11, identifique otros seis posibles riesgos en los proyectos de software.
R-/ Otros Riesgos Posibles pueden ser:
Renuncia: La Posible renuncia de uno o parte del equipo de trabajo, encargado de el desarrollo del proyecto o de la programación de componentes.
Feriados o Vacaciones: La no inclusión de las vacaciones de los empleados o los días feriados que son derechos laborales de los empleados de la empresa desarrolladora.
Enfermedad: Enfermedades eventuales a los miembros del equipo de desarrollo del software que atrase la continuidad de una tarea.
5.10 Los contratos de precio prefijado, donde el contratista ofrece un precio fijo para completar el sistema, pueden ser utilizados para traspasar los riesgos del proyecto del cliente al contratista. Si algo va mal, el contratista asumirá la diferencia. Indique de qué modo el uso de contratos puede incrementar la probabilidad de aparición de riesgos.
R-/ Pues de tal forma que si los riesgos que aparecen en el transcurso del proyecto de desarrollo, no están estipulados en el contrato, el cliente no está obligado a ser responsable del atraso por los mismos y la espera de ellos. Por lo tanto es necesario consensuar una clausula en la cual se estipule un margen de tiempo mínimo y máximo para poder entregar el proyecto y asi pueda quedar un tiempo prudencial por posibles eventualidades fuera del control de ambas partes.
5.11 Su jefe le ha solicitado que entregue un software en un tiempo que solo puede ser posible cumplir preguntando al equipo del proyecto se desea trabajar horas extras sin pago alguno. Todos los miembros del equipo tienen hijos pequeños. Comente si debería aceptar esta petición de su jefe o si debería persuadir al equipo para dar su tiempo a la organización más que a sus familias. ¿Qué factores podrían ser significativos en la decisión?
R-/ Pues creo que en los casos de los programadores esto no sería muy aceptable, ya que el cansancio y agotamiento mental pueden influir en la velocidad en la que avanza el proyecto. Además los factores familiares, siempre son indispensables atender como primera urgencia más que cualquier otra cosa. En mi caso personal no aceptaría esta petición de forma continua sino de forma alternada y platicada con el equipo para programar a voluntad que todos se puedan quedar ciertos días en tiempo extra sin pago alguno pero con incentivos como la comida y el transporte.
5.12 Como programador, se le ofrece un ascenso como gestor de proyecto, pero su sensación es que puede tener una contribución más efectiva en un papel técnico que en uno administrativo. Comente cuando debería aceptar ese ascenso.
R-/ Creo que si como técnico he desarrollado varios proyectos de desarrollo, sería aceptable tomar el ascenso ya que si estoy bien empapado de la labor técnica es posible aprender lo necesario a la gestión del proyecto siempre y cuando se dé un tiempo de prueba para poder entender cuáles son las responsabilidades de mi puesto.
R-/ Porque no se puede ver ni tocar, los gestores de proyectos no pueden ver el progreso, confían en otros para elaborar la documentación necesaria para revisar el progrreso.
5.2 Explique porque los mejores programadores no siempre son los mejores gestores de software. La respuesta puede tener como base la lista de actividades de gestión dadas en la sección 5.1.
R-/ Porque los gestores de software debe tener la capacidad y experiencia para crear y validar los planes de desarrollo de software y para ello deberían tener experiencia de cada una de esas labores, por lo tanto es bien difícil que un programador se involucre en todas esas labores a menos que ya tenga un buen tiempo de interactuar en diferentes áreas del proceso de desarrollo de software.
5.3Explique porque el proceso de planificación de proyectos es iterativo y porque un plan se debe revisar continuamente durante el proyecto de software.
R-/Es un proceso iterativo porque mientras dure el proyecto se deben repetir como un While: la revisión de la programación, el inicio de las actividades, revisar el progreso, revisar las estimaciones de los parámetros del proyecto, actualizar la programación del proyecto, todo esto se debe repetir hasta que se de por terminado el proyecto. El plan debe revisarse continuamente conforme la información se hace disponible acerca del progreso del proyecto, Mientras las metas globales del negocio cambien en necesario cambios en el proyecto.
5.7 La Figura 5.5 señala la duración de las tareas para las actividades del proyecto de software. Suponga que hay un serio retraso no anticipado y que en lugar de requerir 10 dias, la tarea T5 requiere 40 días. Revise la red de actividades resultante, resaltando el nuevo camino critico. Diseñe un nuevo grafico de barras que muestre como se podría reorganizar el proyecto
R-/
5.9 Además de los riesgos que se muestran en la figura 5.11, identifique otros seis posibles riesgos en los proyectos de software.
R-/ Otros Riesgos Posibles pueden ser:
Renuncia: La Posible renuncia de uno o parte del equipo de trabajo, encargado de el desarrollo del proyecto o de la programación de componentes.
Feriados o Vacaciones: La no inclusión de las vacaciones de los empleados o los días feriados que son derechos laborales de los empleados de la empresa desarrolladora.
Enfermedad: Enfermedades eventuales a los miembros del equipo de desarrollo del software que atrase la continuidad de una tarea.
5.10 Los contratos de precio prefijado, donde el contratista ofrece un precio fijo para completar el sistema, pueden ser utilizados para traspasar los riesgos del proyecto del cliente al contratista. Si algo va mal, el contratista asumirá la diferencia. Indique de qué modo el uso de contratos puede incrementar la probabilidad de aparición de riesgos.
R-/ Pues de tal forma que si los riesgos que aparecen en el transcurso del proyecto de desarrollo, no están estipulados en el contrato, el cliente no está obligado a ser responsable del atraso por los mismos y la espera de ellos. Por lo tanto es necesario consensuar una clausula en la cual se estipule un margen de tiempo mínimo y máximo para poder entregar el proyecto y asi pueda quedar un tiempo prudencial por posibles eventualidades fuera del control de ambas partes.
5.11 Su jefe le ha solicitado que entregue un software en un tiempo que solo puede ser posible cumplir preguntando al equipo del proyecto se desea trabajar horas extras sin pago alguno. Todos los miembros del equipo tienen hijos pequeños. Comente si debería aceptar esta petición de su jefe o si debería persuadir al equipo para dar su tiempo a la organización más que a sus familias. ¿Qué factores podrían ser significativos en la decisión?
R-/ Pues creo que en los casos de los programadores esto no sería muy aceptable, ya que el cansancio y agotamiento mental pueden influir en la velocidad en la que avanza el proyecto. Además los factores familiares, siempre son indispensables atender como primera urgencia más que cualquier otra cosa. En mi caso personal no aceptaría esta petición de forma continua sino de forma alternada y platicada con el equipo para programar a voluntad que todos se puedan quedar ciertos días en tiempo extra sin pago alguno pero con incentivos como la comida y el transporte.
5.12 Como programador, se le ofrece un ascenso como gestor de proyecto, pero su sensación es que puede tener una contribución más efectiva en un papel técnico que en uno administrativo. Comente cuando debería aceptar ese ascenso.
R-/ Creo que si como técnico he desarrollado varios proyectos de desarrollo, sería aceptable tomar el ascenso ya que si estoy bien empapado de la labor técnica es posible aprender lo necesario a la gestión del proyecto siempre y cuando se dé un tiempo de prueba para poder entender cuáles son las responsabilidades de mi puesto.
martes, 8 de junio de 2010
Tareas Asignadas en Proycto UTH-Vitual GRUPO CALIF
Estas son las labores asignadas a los integantes de nuestro grupo(CALIF)
Integrantes del Grupo (CALIF):
Fausto A. Morazan (Coordinador)
Lenin Ricardo Pineda
Jeffry Zelaya
Jean Carlo Molinero
SITUACION ACTUAL DEL CLIENTE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En este punto estaremos realizando un estudio completo de los servicios actuales que ofrece la universidad y así mismo se describirá cuales de estos servicios se ofrecen de forma virtual y cuáles no. También se realizara un estudio de las necesidades actuales y la manera de realizar más eficientemente tales operaciones a través de la ayuda de una solución virtual.
Este estudio comprende también la investigación de equipo actual con el que se cuenta para desarrollar la propuesta, software actual y necesidades de inversión, así como investigación de la infraestructura actual para ver si existe la necesidad de realizar alguna inversión para el desarrollo de la propuesta en cada una de las áreas.
HISTORIA DEL SOFTWARE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En esta sección se realizara una investigación del software actual con el que cuenta actualmente la institución así como la tecnología de información que se tiene para realizar las interfaces necesarias para el acceso de UTH Virtual
DISEÑO DE LA PROPUESTA
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
De acuerdo a la revisión de la situación actual del cliente y realizando una revisión de lo que existe y lo que no, la Propuesta UTH-Virtual tendrá las siguientes áreas de acceso específico de acuerdo a la necesidad de cada usuario.
TIEMPO ESTIMADO DE DESARROLLO
El Desarrollo de tal propuesta se realizara en base al siguiente cronograma:
1. Investigación sobre la Información a Publicar
ASIGANDO AL INTEGRANTE (JEAN CARLO MOLINERO)
2. Investigación sobre Servicios Actuales (Lenin Pineda)
ASIGANDO AL INTEGRANTE (LENIN PINEDA)
3. Diseño de Pantallas Finales que serán desarrolladas para cada una de las propuestas finales en el desarrollo de la la Propuesta.
ASIGANDO A LOS INTEGRANTES (LENIN PINEDA Y JEAN CARLO MOLNERO)
4. Diseño de Propuesta Final
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
Integrantes del Grupo (CALIF):
Fausto A. Morazan (Coordinador)
Lenin Ricardo Pineda
Jeffry Zelaya
Jean Carlo Molinero
SITUACION ACTUAL DEL CLIENTE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En este punto estaremos realizando un estudio completo de los servicios actuales que ofrece la universidad y así mismo se describirá cuales de estos servicios se ofrecen de forma virtual y cuáles no. También se realizara un estudio de las necesidades actuales y la manera de realizar más eficientemente tales operaciones a través de la ayuda de una solución virtual.
Este estudio comprende también la investigación de equipo actual con el que se cuenta para desarrollar la propuesta, software actual y necesidades de inversión, así como investigación de la infraestructura actual para ver si existe la necesidad de realizar alguna inversión para el desarrollo de la propuesta en cada una de las áreas.
HISTORIA DEL SOFTWARE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En esta sección se realizara una investigación del software actual con el que cuenta actualmente la institución así como la tecnología de información que se tiene para realizar las interfaces necesarias para el acceso de UTH Virtual
DISEÑO DE LA PROPUESTA
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
De acuerdo a la revisión de la situación actual del cliente y realizando una revisión de lo que existe y lo que no, la Propuesta UTH-Virtual tendrá las siguientes áreas de acceso específico de acuerdo a la necesidad de cada usuario.
TIEMPO ESTIMADO DE DESARROLLO
El Desarrollo de tal propuesta se realizara en base al siguiente cronograma:
1. Investigación sobre la Información a Publicar
ASIGANDO AL INTEGRANTE (JEAN CARLO MOLINERO)
2. Investigación sobre Servicios Actuales (Lenin Pineda)
ASIGANDO AL INTEGRANTE (LENIN PINEDA)
3. Diseño de Pantallas Finales que serán desarrolladas para cada una de las propuestas finales en el desarrollo de la la Propuesta.
ASIGANDO A LOS INTEGRANTES (LENIN PINEDA Y JEAN CARLO MOLNERO)
4. Diseño de Propuesta Final
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
Suscribirse a:
Entradas (Atom)
