viernes, 15 de octubre de 2010

LENGUAJE UNIFICADO DE MODELADO - UML-

CONCEPTO DE UML

el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad;

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

CASOS DE USO

CONCEPTUALIZACION

En ingenieria del softwre, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Ventajas

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor
(su usuario) al hacer uso del sistema.

ANALISIS DE REQURIMIENTOS

Concepto de Requerimiento.

En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingenieria de sistemas o la ingenieria del software.

Requerimientos funcionales: 
Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso serán llevados a la práctica. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.
Como se define en la ingenieria de requisitos, los requisitos funcionales establecen los comportamientos del sistema.

Requerimientos no funcionales:
Un requisito no funcional es, en la ingenieria de sistemas y la ingenieria de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.
Los requisitos no funcionales más habituales son la estabilidad, la portabilidad y el costo.

lo mas sobresaliente a mi criterio es la gestion de requerimientos y la forma como esta distribuida:

Reglas generales de la gestión de requerimientos

En la gestión de requerimientos como en el resto de las tareas en un proceso de ingeniería de software, que generalmente es más complejo de lo que uno quisiera, aplican una serie de reglas son útiles a la hora de tomar una decisión de qué hacer y que no hacer.
  1. ORO: Mientras más simple mejor. Esta es como una moneda de oro, que tiene dos caras: por una cara manejar los requerimientos de la manera más sencilla posible hará más fácil la administración de los requerimientos. Por la otra cara, si no se recoge toda la información necesaria para la administración, la información que en las manos del responsable del proyecto es útil, pierde su aplicación al estar incompleta. Es decir, simple no es incompleta.
  2. PLATA: La redundancia de información es siempre un problema. Un análisis no cuidadoso puede caer fácilmente en redundancia de información, colocando requerimientos del sistema o características de la solución como necesidades de la organización, o bien repitiendo información para rellenar los niveles de información comprometidos. El análisis de sistemas es, de por sí, un adelanto de la programación del sistema, en el que cada componente tiene una misión, y los componentes no está para construirlos una y otra vez, por el contrario se construyen una vez, se colocan en el lugar adecuado y se utilizan las veces que sean necesaria, esto es, los requerimientos se escriben una vez y se escriben de manera simple, se les da la clasificación adecuada, y se trazan las veces necesarias.
  3. BRONCE: Los requerimientos no desaparecen porque no se tengan en cuenta. En física, la ley de la conservación de la materia enuncia: "la materia no se crea ni se destruye, se transforma", en ingeniería de software el equivalente sería la ley de la gestión de los requerimientos: "los requerimientos no se acomodan o se desaparecen, se descubren". Una solución informática a un problema de negocio tienen una cantidad de requerimientos intrínsecos que provienen del negocio. El no tomarlos en cuenta no significa que el sistema no los necesite, sino que no han sido tomados en cuenta y que a la larga, los mismos han de ser desarrollados. La diferencia está en el momento en que son descubiertos y el estado de ánimo con el que terminará la parte que deba pagar la diferencia (bien sea el proveedor o el cliente). No tomar en cuenta los requerimientos desde un inicio, está más que probado, que es más costoso que hacer un buen análisis que los contemple. El no encontrarlos supone, en el mejor de los casos, inexperiencia de la parte que hace el análisis, y en el peor, mala intención en el descubrimiento de los mismos. Para la parte que hace el análisis, en realidad, ninguno de los dos escenarios son buenos.

DIAGRAMAS: GANTT VS PERT


El diagrama de Gantt, gráfica de Gantt o carta Gantt es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias.

En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las diferentes unidades minimas de trabajo y los grupos de tareas.



El método PERT, al igual que el grafo Gantt, parte de la división del proyecto en un conjunto de trabajos individuales que reciben el nombre de actividades. Una actividad es cualquier operación o tarea que es necesario ejecutar para la realización de un proyecto. Toda actividad supone el consumo de recursos (materiales, mano de obra, etc.) y, sobre todo, el consumo de tiempo. Una actividad puede ser tanto una operación activa como una espera que implica un consumo de tiempo. Así, cuando se lleva a cabo la construcción de un edificio, la solicitud de la licencia de la obra representa una actividad sin la cual el resto de operaciones no pueden iniciarse. Junto al concepto de actividad, el método PERT emplea el de etapa o suceso. El suceso representa una fecha en el calendario, un punto en el tiempo, que indica el comienzo o el fin de una actividad específica del proyecto.

El principio fundamental del método PERT puede resumirse del modo siguiente: Para que la ejecución de una actividad siguiente a una etapa, es decir, que sale de dicha etapa, pueda ser comenzada, es preciso que todas las actividades que la preceden, es decir, que finalizan en dicha etapa, hayan sido terminadas.




martes, 14 de septiembre de 2010

CONSTRUCCION DE SISTEMAS DE INFORMACION

1. ¿Qué actividades transforman datos simples en información útil en un sistema de información? ¿Qué relación tienen con la retroalimentación?

a) La alimentación o insumo: captura datos dentro de la organización o del entorno que la rodea,
El procesamiento: transforma esos datos en algo que tenga sentido, y
El producto o salida: transfiere la información a la persona o lugar donde deba ser aprovechada.
b) Para que los sistemas de información trabajen de una forma adecuada es necesario estarlos supervisando y qué mejor que la retroalimentación, es decir, cuando la información ya llegó a la persona indicada y ésta observó alguna anomalía o mejora que se puede dar, provoca con ello que la entrada al sistema pueda ser modificada o ampliada según se ocupe, con lo cual la información de salida puede mejorar y mejora el sistema de información.

2. ¿Cuál es la relación entre un sistema de información, la institución y su entorno?

Los sistemas de información son construidos a partir de la institución, es decir, la institución existe primero que el sistema de información, pero una vez que se tiene un sistema de información bien desarrollado, ahora, la empresa es la que subsiste o continúa existiendo, gracias a la eficiencia de sus sistemas de información.

3. ¿Cuáles son los principales retos de administración involucrados en la construcción, operación y mantenimiento de los sistemas de información en la actualidad?

Los principales retos de los sistemas de información son:
El reto estratégico de los negocios
Todo debe de estar en continua mejora, las empresas que no rediseñan sus productos o que no rediseñan a la organización en sí misma, cometen el peor de los errores y esto los lleva a cavar su propia tumba, la institución deja de ser productiva y pierde mercado.
El reto de la globalización
Debido a la globalización de la economía se requiere de comercio internacional, de romper barreras de lenguaje para llegar a un mayor número de consumidores potenciales, la empresa que no cuente con un sistema de información preciso para que pueda ver las tendencias de los mercados internacionales y aprovechar las oportunidades de negocios, está muerta.

El reto de la arquitectura de la información
La organización como tal debe de tener una filosofía común y no debe de estar separada en islas incomunicadas, es decir debe de haber un objetivo común, una mentalidad que todos y cada uno de los empleados de la misma se identifique.
El reto de la inversión en los sistemas de información
La pregunta principal que nos planteamos es ¿será redituable la inversión que hagamos en la mejora de nuestro equipo de computo, de telecomunicaciones? ¿Nos generará una mayor ganancia?
El reto de la responsabilidad y el control
En los sistemas de información están involucrados personas, estas personas podrían hacer un mal uso de los sistemas de información, por lo tanto debemos de planear una estrategia para hacer confiables a estas personas, ya sea haciendo más robustos nuestros sistemas de seguridad, estar monitoreando a los empleados o tenerles una confianza enorme y pensar que nunca serían capaces de hacer un daño a su propia institución, ¿cómo actuar? Depende de usted mismo.

4. Existen seis clases principales de sistemas de información en las instituciones actuales:
a. Los Sistemas de Procesamiento de Operaciones (SPO) al nivel operativo;
b. Sistemas del Trabajo de Conocimiento (STC);
c. Sistemas de Automatización en la Oficina (SAO) al nivel de conocimientos;
d. Sistemas de Información para la Administración (SIA);
e. Sistemas para el Soporte a Decisiones (SSD) al nivel gerencial; y,
f. Sistemas de Soporte Gerencial (SSG) al nivel estratégico.

5. ¿Cuáles son las principales características de los 6 tipos de Sistemas de Información en las empresas? ¿Qué funciones desempeñan? Dar ejemplos de cada uno de ellos.

Los sistemas de Procesamiento de Operaciones (SPO) al nivel operativo

Sistemas computarizados que realizan y registran las operaciones diarias de rutina necesarias para la operación de la empresa; dan servicio al nivel operativo de la institución. Las tareas, los recursos y las metas del nivel operativo de la institución están previamente definidos y altamente estructurados.
Características: ensanchan la frontera entre la institución y su entorno. Enlazan a los clientes con el almacén de la empresa, con la fábrica y con la administración. Son los principales generadores de información para otro tipo de sistemas.
Son el único lugar donde los administradores obtienen evaluaciones inmediatas del funcionamiento de la institución e información muy anterior del funcionamiento de la misma. Pueden considerarse como sistemas de procesamiento de sistemas institucionales que informan a los administradores sobre el estado de las operaciones internas y las relaciones de la empresa con el medio ambiente externo, y dan apoyo a otros sistemas de información que facilitan la toma de decisiones a los administradores.

Sistemas del Trabajo de Conocimiento (STC)

Sistemas de información que ayudan a los trabajadores del conocimiento en la creación e integración de nuevos conocimientos para la institución.

Sistemas de Automatización en la Oficina (SAO) al nivel de conocimientos

Sistemas computarizados, como el procesador de palabra, correo electrónico y sistemas de programación, que han sido diseñados para incrementar la productividad de los empleados que manejan información en la oficina.

Sistemas de Información para la Administración (SIA)

Sistemas de cómputo al nivel de administración de la institución, que sirven a las funciones de planeación, control y toma de decisiones proporcionando informes compilados de rutina y de excepción. Han limitado fuertemente las capacidades de análisis, ya que emplean modelos muy sencillos para presentar la información. Son orientados casi exclusivamente a hechos internos.

Sistemas para el Soporte a Decisiones (SSD) al nivel gerencial

Sistemas de cómputo al nivel de administración de la institución, que combinan información y modelos sofisticados de análisis para dar apoyo a la toma semi-estructurada y estructurada de decisiones.
Los SSD se diferencian de los SIA en diversas maneras. Los SSD tienen capacidades de análisis más avanzadas que permiten que quien los usa emplee diversos modelos para analizar la información. Estos sistemas dependen de la información interna de los SPO y de los SIA, y con frecuencia se sirve de información suministrada por fuentes externas. Los SSD tienden a ser más interactivos, pues facilitan a los usuarios un acceso sencillo a la información y a los modelos analíticos a través de instrucciones amigables de computadora.

Sistemas de Soporte Gerencial (SSG) al nivel estratégico

Los directivos emplean una clase de sistemas de información llamados Sistemas de Soporte Gerencial (SSG) para la toma de las decisiones. Los SSG sirven al nivel estratégico de la institución, dirigen las decisiones no estructuradas y crean un ambiente generalizado de computación y comunicación en vez de proporcionar alguna aplicación fija o capacidad específica. Los SSG están diseñados para incorporar información sobre eventos externos, pero también obtienen información resumida de los SIA y SSD internos. Emplean el software de gráficas más avanzado y pueden dar gráficas e información de muchas fuentes de manera inmediata a la oficina del director general o a una sala de juntas.
Los SSG no están diseñados en primera instancia para resolver problemas específicos. En vez de ello, proporcionan capacidad generalizada de computación y telecomunicaciones que puede ser aplicada a muchas situaciones. Hacen un menor uso de los modelos analíticos. Operan de manera más abierta.

6. Explique 3 cualidades de la información y diga porqué es importante para la empresa.

Para que la información tenga valor, es muy importante que cumpla 3 requisitos o cualidades:

Que sea veraz: Esto es, información verídica y contrastable con la realidad.
Que sea oportuna: Quiere decir, obtener la información precisa en el momento adecuado.
Que sea relevante: Esto es, información que sea de importancia y no meros datos sin vínculo alguno.

7. ¿Cuál es la diferencia entre Análisis de Sistemas y Diseño de Sistemas?

Análisis de Sistemas

El Análisis de Sistemas es la ciencia encargada del análisis de sistemas grandes y complejos y la interacción entre esos sistemas. Esta área se encuentra muy relacionada con la Investigación de operaciones. También se denomina Análisis de Sistemas a una de las etapas de construcción de un sistema informático, que consiste en relevar la información actual y proponer los rasgos generales de la solución futura.
Los sistemas en relación con el Análisis de Sistemas están relacionados con cualquier campo tales como: procesos industriales, administración, toma de decisiones, procesos, protección al medio ambiente, etc.
Los Analistas de Sistemas utilizan la metodología matemática para obtener los detalles de los sistemas a los cuales se encuentran analizando.

Diseño de Sistemas
El Diseño de Sistemas es el arte de definir la arquitectura de hardware y software, componentes, módulos y datos de un sistema de cómputo para satisfacer ciertos requerimientos. Es la etapa posterior al Análisis de Sistemas.
El Diseño de Sistemas tiene un rol más respetado y crucial en la industria de procesamiento de datos. La importancia del software multiplataforma ha incrementado la ingeniería de software a costa de los Diseños de Sistemas.
Los métodos de Análisis y Diseño orientado a objetos se están volviendo en los métodos más ampliamente utilizados para el Diseño de Sistemas. El UML se ha vuelto un estándar en el Análisis y diseño orientado a objetos. Es ampliamente utilizado para el modelado de sistemas de software y se ha incrementado su uso para el Diseño de Sistemas que no son software así como organizaciones.

8. ¿Qué es la factibilidad (viabilidad)? Nombrar y describir cada una de las cuatro principales áreas de la factibilidad.

La investigación preliminar examina la factibilidad del proyecto, la posibilidad de que el sistema sea de utilidad para la organización; a saber en 4 áreas:

Factibilidad operacional: se refiere al hecho de que sí trabajará o no el sistema si este se llega a desarrollar, preguntas claves aquí son:

* ¿Existe apoyo suficiente para el proyecto por parte de la administración?, ¿Y por parte de los usuarios?
* Los métodos que actualmente se usan en la empresa, ¿son aceptados por los usuarios?
* ¿Los usuarios han participado en la planeación y desarrollo del proyecto?, ¿Cómo lo han hecho?
* ¿El sistema propuesto causará perjuicios?
* ¿Producirá resultados pobres en alguna área?
* ¿Se perderá control en alguna área específica?
* ¿Se perderá la facilidad de acceso a la información?
* ¿La productividad de los empleados será menor después de instalado el sistema?
* ¿Los clientes se verán afectados por la implantación?

Factibilidad Técnica:
* ¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?
* ¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos requeridos para usar el nuevo sistema?
* ¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin importar el número y ubicación de los usuarios?
* Si se desarrolla el sistema, ¿se puede crecer con facilidad?
* ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos?

Factibilidad financiera y económica: un sistema puede ser factible desde el punto de vista técnico y operacional, pero si no es factible económicamente para la organización no puede ser implantado. Las cuestiones económicas y financieras formuladas por los analistas deben incluir:
* El costo de llevar a cabo la investigación completa de sistemas.
* El costo del hardware y software para la aplicación.
* Beneficios en la forma de reducción de costos o de menos errores costosos.
* El costo si nada sucede (si el proyecto no se lleva a cabo).

Factibilidad legal: (Licencias, normas, políticas).
Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal en que se podría incurrir al desarrollar el Sistema.
Alternativas. Una evaluación de los enfoques alternativos del desarrollo del producto o Sistema.
El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia.

9. ¿Qué son requerimientos de información? ¿Por qué es difícil determinarlos correctamente?

Determinación de los requerimientos de información:
Esto se hace a partir de los usuarios particularmente involucrados, para determinar los requerimientos de información dentro de una organización pueden utilizarse diversos instrumentos, los cuales incluyen: muestreo, el estudio de los datos y formas usadas por la organización, la entrevista, los cuestionarios; la observación de la conducta de quien toma las decisiones, así como de su ambiente.
En esta etapa se hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus tareas.

10. Describir cada una de las etapas del ciclo de vida de los sistemas.

CICLO DE VIDA
Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Las principales etapas a realizar en cualquier ciclo de vida son:
1. Análisis: Construye un modelo de los requisitos.
2. Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.
3. Codificación: Construye el sistema. La salida de esta fase es código ejecutable.
4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
5. Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.
Las etapas constan de tareas. La documentación es una tarea importante que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida.

11. ¿Cuáles son las ventajas y desventajas del desarrollo de un sistema de información usando el modelo de ciclo de vida lineal - secuencial de los sistemas?

Ventajas
Se tiene todo bien organizado y no se mezclan las fases.
Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar.

Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.

12. ¿Qué significa prototipo del sistema de información?

Modelo de prototipos

En Ingeniería de software el desarrollo con prototipación, también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

13. ¿Bajo qué condiciones es el uso de prototipos un enfoque útil de sistemas? ¿Qué tipos de problemas puede ayudar a resolver?

Este método resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.
Problemas Candidatos
Para decidir si el prototipo debe incluirse o no en el Ciclo de Desarrollo de Sistema de Información, el profesional considera los siguientes factores:
* Problemas no estructurados, novedosos y complejos, de información personalizada del usuario, ya que sus salidas no son predecibles y definidas.
* Problemas de ambiente Inestable, el profesional también debe evaluar el contexto del sistema.

14. ¿Cuáles son las ventajas del modelo de ciclo de vida de cascada?

Ventajas
Se tiene todo bien organizado y no se mezclan las fases.
Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar.

15. ¿Bajo qué condiciones es el uso de modelo de ciclo de vida de espiral un enfoque útil de sistemas? ¿Cuáles son sus ventajas?

Desarrollo en espiral
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.
Ventajas
El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
Reduce riesgos del proyecto.
Incorpora objetivos de calidad.
Integra el desarrollo con el mantenimiento, etc.
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

16. ¿Qué dimensiones influyen sobre el nivel de riesgo en cada proyecto de desarrollo de sistemas?

Análisis de Riesgos:
El análisis de riesgos es algo vital para una buena gestión del proyecto, y sin embargo, a pesar de todo, se emprenden muchos proyectos sin que se hayan considerado los riesgos concretos.
El análisis de riesgos consiste realmente en una serie de pasos de control de los riesgos que nos permiten “combatirlos”:
* Identificación de riesgos.
* Estrategias de control de riesgos.
* Resolución de riesgos.
* Supervisión de riesgos.
Estos pasos se aplican a lo largo del proceso de ingeniería del software.

17. ¿Qué técnicas de administración de proyectos pueden ser usadas para controlar el riesgo en los proyectos?

Técnicas del software de administración de proyectos

Programación
Una de las tareas más comunes en la administración es la de programar y hacer seguimiento a una serie de acontecimientos; la complejidad de esta tarea puede variar considerablemente, dependiendo de las necesidades de la organización de que se trate, de el/los usuario/s y de cómo se utiliza la herramienta. Algunos desafíos comunes incluyen:

0 Acontecimientos que dependen el uno del otro de diversas maneras.
1 Recursos humanos disponibles para trabajar en las diversas tareas.
2 Incertidumbres en las estimaciones de la duración de cada tarea.
3 Ordenación de las tareas para satisfacer los plazos.
4 Interferencia entre múltiples proyectos, para satisfacer distintos requerimientos simultáneos.

Cálculo de la Ruta Crítica
En muchos proyectos complejos, habrá una trayectoria crítica o serie de acontecimientos que dependan uno del otro y que sus duraciones determinen directamente la longitud del proyecto entero. Algunos usos del software (por ejemplo, soluciones de la matriz de la estructura de dependencia) pueden destacar estas tareas, que son las que concentrarán el esfuerzo de seguimiento y optimización.

Abastecimiento de la información
El software de planeamiento de proyectos necesita proporcionar mucha información a diversas personas, para justificar el tiempo que se lleva usándolo. Los requisitos típicos podrían incluir:
5 Listas de tareas para la gente, y la programación de la asignación de los recursos.
6 Información descriptiva acerca de cuánto tiempo tomarán las tareas para terminarse.
7 Detección temprana de riesgos del proyecto.
8 Información sobre carga de trabajo, por la planeación de días festivos.
9 Información histórica sobre cómo han progresado los proyectos, y en particular, cómo se relaciona el desempeño planeado con el actual.

18. ¿Qué estrategias pueden ser usadas para vencer la resistencia de los usuarios a los proyectos de desarrollo de sistemas?

a. Comunicar la necesidad de cambio.
b. Obtener una visión compartida.
c. Generar el compromiso de los líderes.
d. Facilitar la participación del personal.
e. Pensar sobre la organización en forma integrada.
f. Medir el Performance.

19. ¿Qué es una entrevista y por qué es útil en el desarrollo de software?

¿QUÉ ES UNA ENTREVISTA?
Es una conversación entre dos o más personas que tiene como finalidad la obtención de información o respuestas a los interrogantes planteados sobre un tema propuesto.

Es un diálogo, donde una de las partes busca recoger informaciones y la otra es la fuente de esas informaciones.

Quienes responden a una entrevista pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta.

Objetivos de la Entrevista:
* Obtener la mayor información posible de individuos, grupos o procesos.
* Facilitar la recolección de información o datos.
* Permitir la posibilidad de aclarar dudas, orientar las situaciones o problemas y resolver las dificultades que pueda tener la persona entrevistada.

20. ¿Cuáles son las ventajas de cada uno de los tipos de estructuras de entrevistas?

Existen 2 tipos de entrevista, así como 3 tipos de estructura para realizarla. Los tipos de entrevistas son:
Abiertas: permiten al usuario que es el entrevistado expresar más de lo que se le pregunta.
Cerradas: se limita al usuario a responder preguntas de una lista.
Las estructuras son:
Pirámide: comienza con los detalles, y se abre a preguntas más generales.
Embudo: comienza con aspecto generales y termina con preguntas más cerradas.
Diamante: esta técnica combina las dos anteriores.