TEMA 2.3 ESPECIFICACIÓN DE REQUERIMIENTOS

La especificación de los requerimientos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar.  Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como  requisitos funcionales.
Recomendaciones para hacer una buena especificación de requerimientos:
Completa: Todos los requerimientos deben estar reflejados en ellas.
Correcta: El software debe de cumplir con los requisitos de la especificación.
Modificable: Aunque todo requerimiento es modificable, se refiere a que se debe de ser facilmente modificable.

TEMA 2.2 OBSERVACION Y ANÁLISIS DE REQUERIMIENTOS

Existe un gran número de técnicas para obtener requerimientos. A continuación describo las más utilizadas. Hay que aclarar que ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas para obtener requerimientos completos.

Entrevistas

La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una mayor preparación y experiencia por parte del analista. La entrevista se puede definir como un “intento sistemático de recoger información de otra persona” a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la información necesaria. Es muy importante la forma en que se plantea la conversación y la relación que se establece en la entrevista.

Estos son algunos de los aspectos más importantes a tener en cuenta al realizar entrevistas:

• Preparación. Es necesario documentarse e investigar la situación de la organización analizando los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que están solamente en la mente del entrevistado y que no son accesibles por otros medios como la observación o el análisis de documentos.
• Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-down, comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que aportan detalles importantes de la operación.
• Duración. Una entrevista debería durar a lo sumo un par de horas.
• Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

TEMA 2.1 ESTUDIO DE FACTIBILIDAD

El estudio de factibilidad es un instrumento que sirve para orientar la toma de decisiones en la evaluación de un proyecto y corresponde a la última fase de la etapa pre-operativa o de formulación dentro del ciclo del proyecto. Se formula con base en información que tiene la menor incertidumbre posible para medir las posibilidades de éxito o fracaso de un proyecto de inversión, apoyándose en él se tomará la decisión de proceder o no con su implementación.

VENTAJAS Y DESVENTAJAS DE LAS METODOLOGÍAS TRADICIONALES 

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada [42]. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas podemos citar:

• RUP (Rational Unified Procces)

• MSF (Microsoft Solution Framework)

• Win-Win Spiral Model

• Iconix

VENTAJAS Y DESVENTAJAS DE METODOLOGÍAS ÁGILES

• La primera y la que, a mi parecer es la más importante, es que estas metodologías ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como después poder modificarlos evitando grandes pérdidas en cuanto a costes, motivación, tiempo…
• El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolución gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.
• Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologías, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeño intervalo de tiempo un pequeño “trozo” del proyecto al cliente, y si éste quiere cambiarlo, solo se habrá perdido unas semanas de trabajo. Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la pérdida de todo ese trabajo.
• Importancia de la simplicidad al eliminar trabajo innecesario

Pero claro, aunque las ventajas sean muy apetecibles, estas metodologías también presentan inconvenientes que hay que asumir cuando se decide trabajar con ellas. Estos son:

• Falta de documentación del diseño. Al no haber documentación es el código (junto con sus comentarios) lo que se toma como documentación.
• Problemas derivados de la comunicación oral. No hace falta decir que algo que está escrito “no se puede borrar”, en cambio, algo dicho es muy fácil crear ambigüedad.
• Fuerte dependencia de las personas.
• Falta de reusabilidad derivada de la falta de documentación
• Restricciones en cuanto a tamaño de los proyectos
• Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.

   

CONFERENCIA CIBETIC

En la primera conferencia que tuvimos la verdad fue bastante mala ya que fue una vídeo conferencia y tuvieron bastantes errores técnicos y lamentablemente no se entendió nada de lo que nos estaba comentando aunque creo que era una de las mas importantes de esa conferencia y por desgracia no entendí nada.

La segunda conferencia nos hablo de las redes que en la vida cotidiana son muy importantes en la actualidad . 

AUDITORIAS

PERFIL DE UN AUDITOR

Las características de un auditor constituyen uno de los temas de importancia en el proceso de realizar una auditoria dentro de una empresa, ya que en el recae la responsabilidad de practicarla y lograr los resultados necesarios para proponer las medidas necesarias para elevar el desempeño.

PROCESOS DE AUDITORIA

Documentos de solicitud

Después de notificar a la organización de la próxima auditoria, el auditor normalmente solicita los documentos que figuran en una lista de comprobación preliminar. Éstos pueden incluir una copia del informe de alguna auditoria anterior, las declaraciones bancarias originales, los recibos y libros de contabilidad. Además, el auditor puede solicitar cartas de la organización, junto con copias de las actas de la junta y del comité, así como copias de los estatutos y reglas permanentes.

Preparación de un plan de auditoría

El auditor consultará la información contenida en los documentos y planes para especificar la forma en que la auditoría se llevará a cabo. Un taller de riesgo puede llevarse a cabo para identificar posibles problemas. Un plan de auditoría se redactará en este momento.

Programar una reunión abierta

La alta gerencia y el personal administrativo clave serán invitados a una reunión abierta en la que se presentará el alcance de la auditoría por parte del auditor. Debe determinarse un marco de tiempo, así como cualquier otra cuestión que tenga que ver con este rubro, como el tema de las vacaciones programadas. Los jefes de departamento pueden informar al personal sobre las entrevistas con el auditor.

La realización de trabajo de campo

El auditor tomará la información que ha obtenido de la sesión pública y puede usarla para finalizar el plan de auditoría. El trabajo de campo se llevará a cabo con los miembros del personal, quienes deben revisar los procedimientos y procesos. El auditor verificará el cumplimiento de las políticas y procedimientos. Los controles internos deben ser evaluados para asegurarte de que sean adecuados. El auditor puede discutir los problemas que puedan surgir para dar a la organización una oportunidad de respuesta.

Redacción de un informe

El auditor debe preparar un informe que detalle los hallazgos de la auditoría. En el informe se incluyen los errores matemáticos, problemas contables y pagos autorizados, pero no así las deudas y otras discrepancias; deben enumerarse otras preocupaciones de la auditoría. El auditor entonces debe escribir un comentario que describa los hallazgos de la auditoría y las soluciones recomendadas para los problemas.

Configuración de una reunión de cierre

El auditor solicita una respuesta de la dirección que indique si está de acuerdo o en desacuerdo con los problemas descritos en el informe, una descripción del plan de acción de la administración para hacer frente al problema y una fecha de finalización prevista. En la sesión de clausura, todas las partes involucradas deben discutir el informe y las respuestas de la administración. Si hay algunos asuntos pendientes, deben resolverse en este punto.