domingo, 15 de febrero de 2015

GESTIÓN DE CALIDAD



INTRODUCCION

En esta clase vimos que la obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y pruebas del software que permitan uniformar la filosofía de trabajo, en áreas de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

GESTIÓN DE CALIDAD


La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad.En términos generales la calidad de software puede definirse como el grado en que un conjunto de características inherentes al software cumple con unos requisitos explícitos e implícitos. 

La obtención de un software con calidad implica la utilización de metodologías o procedimientos, estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.












La gestión de calidad se la implanta por medios tales como:

1. Planificación de la Calidad del Software.
Es la parte de la Gestión de la Calidad encargada de realizar el proceso administrativo de desarrollar y mantener una relación entre los objetivos y recursos de la organización; y las oportunidades cambiantes del mercado.


2. Control de la Calidad del Software.
Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad. Son las inspecciones, revisiones y pruebas para asegurar la calidad del producto centradas en 2 objetivos fundamentales:
  1. Mantener bajo control un proceso.
  2. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
3. Aseguramiento de la Calidad del Software.
Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Se trata de una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería del software.
Se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El aseguramiento de la calidad del software engloba:
  • Un enfoque de gestión de calidad.
  • Métodos y herramientas de Ingeniería del Software.
  • Revisiones técnicas formales aplicables en el proceso de software.
  • Una estrategia de prueba multiescala.
  • El control de la documentación del software y de los cambios realizados.
  • Procedimientos para ajustarse a los estándares de desarrollo del software.
  • Mecanismos de medición y de generación de informes.
4. Mejora de la Calidad del Software

Las auditorías según el estándar ISO 19011:2002 se define como: proceso sistemático, independiente y documentado para evaluar el estado actual (evidencias de la auditoría) y evaluarlas de manera objetiva con el fin de determinar la extensión en que se cumplen los criterios de auditoría.
Una Auditoría de Calidad tiene como objetivo:
  • Mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza.
  • Suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos.
GESTIÓN DE CAMBIOS

La salida del proceso de software es información que puede dividirse en tres categorías amplias:
1) programas de cómputo (tanto en el nivel de fuente como en formatos ejecutables).
2) productos de trabajo que describen los programas de cómputo (dirigidos a varios participantes). 3) datos o contenido (incluidos dentro del programa o externos a él).
 Los ítems que comprenden toda la información producida como parte del proceso de software se llaman colectivamente configuración del software. Conforme avanza el trabajo de ingeniería de software, se crea una jerarquía de ítems de configuración del software (ICS): un elemento de información nominado que puede ser tan pequeño como un solo diagrama UML o tan grande como el documento de diseño completo. Si cada ICS simplemente conduce a otros ICS, dará como resultado poca confusión. Por desgracia, en el proceso entra otra variable: el cambio, que puede ocurrir en cualquier momento, por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [Ber80] establece: “Sin importar dónde se esté en el ciclo de vida del sistema, el sistema cambiará, y el deseo por cambiar persistirá a lo largo del ciclo de vida.”
 
¿Cuál es el origen de estos cambios?
 La respuesta a esta pregunta es tan variada como los mismos cambios. Sin embargo, existen cuatro fuentes fundamentales de cambio:

•  Nuevas condiciones empresariales o de mercado dictan los cambios en los requerimientos del producto o en las reglas empresariales.

•  Nuevas necesidades de los accionistas demandan modificación a los datos producidos por los sistemas de información, a la funcionalidad que entregan los productos o a los servicios que ofrece un sistema basado en computadora.
 
•  La reorganización o crecimiento/reducción de la empresa produce cambios en las prioridades proyectadas o en la estructura del equipo de ingeniería de software.
•  Restricciones presupuestales o de calendario causan una redefinición del sistema o del producto.

Improve business agility and reduce risk with ITIL Change Management software

CONCLUSIÓN

No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificación se da a los procesos, la correcta consecución de los mismos garantizaría un buen software. No se puede medir al software como tal, sino los atributos que la conforman, tales métodos de medida deben ser exactos.
El usuario final mide la calidad del software según lo que tenga o no, es en ese sentido que la calidad del software depende de quien la juzgue. 
BIBLIOGRAFÍAS

Corujo, H. (2010). Gestión de la Calidad. Consultado el 3 de febrero del 2015. En línea. Formato (HTML). Disponible en: http://www.liderdeproyecto.com/articulos/gestion_de_la_calidad.html

Roger S. Pressman (2010), Ingeniería del Software un enfoque Práctico, 7ma. ed. México: Mc Graw Hill.

GESTION DE RIESGO



INTRODUCCION


 En esta clase vimos que la gestión de riesgos es el primer paso para que la empresa sea consciente de las vulnerabilidades que tienen sus activos y las amenazas que pudieran materializar esas vulnerabilidades. Es deber de la empresa conocer los riesgos a los que se enfrenta para establecer contramedidas y aclarar responsabilidades.


RIESGO DE UN PROYECTO

El Riesgo de un proyecto es un evento o condición incierto que, si se produce, tiene un efecto positivo o negativo sobre almenos uno de los objetivos del proyecto, en tiempo, coste, alcance o calidad.Un riesgo puede tener una o más causas y, si se produce, uno o más impactos. Las condiciones de riesgo pueden incluir aspectos del entorno del proyecto o de la organización que pueden contribuir al riesgo delproyecto, tales comoprácticas deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, múltiples proyectos concurrentes o la dependencia de  participantes externos que no pueden ser controlados. 

 DECISIONES Y RIESGOS

  • La mayoría de las decisiones, incluyendo las más sencillas, involucran riesgo. Es importante determinar lo más pronto posible los criterios de éxito, elementos claves en  la evaluación de riesgos.
  • A medida que se añadan criterios de éxito a la toma de decisiones, ésta se hace más  complicada y se necesita más juicio para tomar la decisión.
  • Cuando se incrementa la complejidad tecnológica en los proyectos aumenta el nivel de riesgo de los mismos, y por lo tanto,  es indispensable contar con una metodología formal para evaluar los efectos de la toma de decisiones.

ADMINISTRACIÓN DE RIESGOS DE PROYECTO

El rol o propósito esencial de la administración de riesgos es la de mejorar el desempeño del proyecto via la sistemática identificación, valoración y administración de los riesgos del proyecto.

COMPONENTES DEL RIESGO

El riesgo tiene tres componentes primarios:

  1. Un evento, (un cambio no deseado).
  2. Una probabilidad de ocurrencia de ese evento.
  3. El Impacto de ese evento, (cantidad apostada o en riesgo).
 






CONCLUSIÓN

El proceso de gestión de riesgos debería lograr un balance efectivo en coste entre la aplicación de controles de seguridad  y las amenazas significativas. Para concluir este tema, la gestión de riesgo sirve para  analizar, administrar y controlar el riesgo que tiene un proyecto,
BIBLIOGRAFÍAS

Lizaraso, C. (2009). GESTIÓN DE RIESGOS DE SEGURIDAD OCUPACIONAL EN PROYECTOS DE INGENIERÍA. Consultado el 27 de enero del 2015. En línea. Formato (PDF). Disponible en: http://www.laseguridad.ws/consejo/consejo/html/memorias/Memorias_Complementarias_Congreso_39/archivos/conferencias/Gestion_de_riesgos_de_SEGURIDAD_OCUPACIONAL_de_proyectos.pdf

GESTIÓN DE REQUERIMIENTOS PRESUPUESTO Y TIEMPO



INTRODUCCION

 En esta clases esxpusimos sobre la  Gestión de Proyectos de Software, entre estas gestiones estaban las de requerimientos presupuesto y tiempo, explicando que la gestión de requerimientos permitiendo la administración de requerimientos funcionales y técnicos.

GESTIÓN DE REQUERIMIENTOS

 La gestión de requerimientos es una forma sistemática de obtener, organizar y documentar los requerimientos de un sistema. También se lo define como un proceso que establece y mantiene un acuerdo entre el cliente y el equipo de proyecto acerca de los cambios de requerimientos del sistema; una de sus técnicas especiales es manejar el alcance del proyecto fijando los recursos disponibles como son tiempo, personal, y dinero.

GESTIÓN DE PRESUPUESTO

Tiene como objetivo principal garantizar que el capital disponible será suficiente para obtener todos los recursos necesarios para que se ejecuten los trabajos del proyecto. Esta gestión incluye todos los procesos necesarios para planificar, estimar, preparar y controlar los costos del proyecto.

GESTIÓN DE TIEMPO

La gestión del tiempo del proyecto asegura que el proyecto se lleve a cabo en los plazos previstos. Para ello hay que definir la secuencia de actividades a realizar, así como su duración y coordinación. También hay que tomar acciones en la gestión del tiempo:
  • Definir claramente el objetivo del proyecto.
  • Determinar que tareas se requiere.
  • Determinar el programa de actividades.
  • Asignar recursos a dichas actividades.
  • Seguir los costos y compararlos con el presupuesto.
  • Buena calidad de los informes sobre el estado y avance del proyecto.


CONCLUSIÓN

En fin estas tres gestiones están interrelacionadas entre sí, ya que el presupuesto, el tiempo y requerimientos dependen de la magnitud o alcance del proyecto. la gestión de requerimientos hace que el cliente participe con el equipo de trabajo de desarrollo del sistema, la gestión de presupuesto se analiza, estima y se controla los gastos durante el proyecto y por último la gestión del tiempo es la que controla si el proyecto se avanza o se termina durante los plazos previstos.

 BIBLIOGRAFÍAS

Roger S. Pressman (2010), Ingeniería del Software un enfoque Práctico, 7ma. ed. México: Mc Graw Hill.

Inteco (2008). Guía práctica de gestión de requisitos. Consultado el 20 de enero del 2015. En línea. Formato (PDF). Disponible en: https://www.incibe.es/file/NRDmviQoTbI_jZcyjTYRlw

lunes, 26 de enero de 2015

Casos de Uso

INTRODUCCIÓN.

En esta clase se planteó la función principal del caso de uso que es visualizar desde el punto de vista del usuario lo cual es la función primordial, todos los diagramas diagrama tiene su función y es necesario para cada uno de las resoluciones de los problemas.

MARCO TEÓRICO
Casos de Uso

Un caso de uso capta un contrato que describe el comportamiento del sistema en distintas condiciones en las que el sistema responde a una petición de alguno de sus participantes. En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias específicas.
Un  lineamiento de tareas o interacciones, una descripción basada en un formato o una representación diagramática. Sin importar su forma, un caso de uso ilustra el software o sistema desde el punto de vista del usuario final.
El primer paso para escribir un caso de uso es definir un conjunto de “actores” que estarán involucrados en la historia. Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el contexto de la función y comportamiento que va a describirse. Los actores representan los papeles que desempeñan las personas (o dispositivos) cuando opera el sistema. Con una definición más formal, un actor es cualquier cosa que se comunique con el sistema o producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando utiliza el sistema.
Es importante notar que un actor y un usuario final no necesariamente son lo mismo. Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras que un actor representa una clase de entidades externas (gente, con frecuencia pero no siempre) que sólo tiene un papel en el contexto del caso de uso.
Una vez identificados los actores, es posible desarrollar casos de uso. Que debe responder un caso de uso:
• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?
• ¿Cuáles son los objetivos de los actores?
• ¿Qué precondiciones deben existir antes de comenzar la historia?
• ¿Qué tareas o funciones principales son realizadas por el actor?
• ¿Qué excepciones deben considerarse al describir la historia?
• ¿Cuáles variaciones son posibles en la interacción del actor?
• ¿Qué información del sistema adquiere, produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
• ¿Qué información desea obtener el actor del sistema?
• ¿Quiere el actor ser informado sobre cambios inesperados?
Considerando la situación en la que el propietario de la casa usa el panel de control, a continuación se plantea el caso de uso básico para la activación del sistema
1. El propietario observa el panel de control de CasaSegura para determinar si el sistema está listo para recibir una entrada. Si el sistema no está listo, se muestra el mensaje no está listo en la pantalla de cristal líquido y el propietario debe cerrar físicamente ventanas o puertas de modo que desaparezca dicho mensaje [el mensaje no está listo implica que un sensor está abierto; por ejemplo, que una puerta o ventana está abierta].

2. El propietario usa el teclado para introducir una clave de cuatro dígitos. La clave se compara con la que guarda el sistema como válida. Si la clave es incorrecta, el panel de control emitirá un sonido una vez y se reiniciará para recibir una entrada adicional. Si la clave es correcta, el panel de control espera otras acciones.

3. El propietario selecciona y teclea permanecer o fuera para activar el sistema. La entrada permanecer activa sólo sensores perimetrales (se desactivan los sensores de detección de movimiento interior). La entrada fuera activa todos los sensores.

4. Cuando ocurre una activación, el propietario observa una luz roja de alarma.

Diagrama de caso de uso.
CONCLUSIÓN.

El caso de uso es la interacción entre el actor y el sistema para así dar a conocer de como el usuarios o actores van interactuar en el sistema.
BIBLIOGRAFÍA


Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición


DIAGRAMAS DE COMPONENTES (DESPLIEGUE Y SECUENCIA)

INTRODUCCIÓN.

En esta se dio a conocer el diagrama de despliegue que el cual se especifica los detalles para la construcción de sistema así mismo en diagrama de secuencia la cual muestra la interacción de los componentes de una forma temporal.

MARCO TEÓRICO
Diagrama de despliegue.
Los diagramas de despliegue se utilizan para visualizar los aspectos estáticos de estos nodos físicos y sus relaciones y para especificar sus detalles para la construcción.






DIAGRAMA DE SECUENCIA
Se utilizan para modelar el paso de mensajes entre objetos, se modela un diagrama de secuencia para cada caso de uso.

Representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.

Muestra la interacción de los objetos que componen un sistema de forma temporal, es decir, ordenadas según el tiempo en que tienen lugar.





CONCLUSIÓN.
Los diagramas son importante de realizarlos ya que dan una visión general de los detalles del sistema así mismo el de clases pero este de forma temporal, es decir, ordenadas según el tiempo en que tienen lugar.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición


Kendall, J; Kendall, K.2011. Análisis y diseño de sistemas. 8va edición.

DIAGRAMAS DE COMPONENTES (CLASES - ACTIVIDADES - ESTADOS)


INTRODUCCIÓN.
En esta se dio a conocer el diagrama de clase la cual es una representación visual de cómo se representa los modelos de objetos especifica los detalles para la construcción de sistema así mismo en diagrama de secuencia la cual muestra la interacción de los componentes de una forma temporal, los diagramas de actividad permiten describir como un sistema implementa su funcionalidad en el momento de llevar a cabo un proceso, los diagrama de estados en si se utiliza para ver el comportamiento de las clases.
MARCO TEÓRICO
Diagrama de clases
En los diagramas de clases, se describen el objeto y las estructuras de información que se utilizan en la aplicación, tanto de forma interna como en la comunicación con los usuarios. Un diagrama de clases es una descripción visual de los posibles sistemas. Un diagrama de clases y un diagrama de objetos son las alternativas de representación de modelos de objetos, aunque los diagramas de clases prevalecen más que los de objetos. Normalmente se puede construir un diagrama de clases y ocasionalmente uno de objetos para ilustrar las estructuras de datos más complejas. Una clase es una ícono que se representa como una caja, la que se divide en tres partes, con el nombre de la clase en la parte superior, la lista de sus atributos en la segunda y la lista de sus operaciones o métodos en la última.

Diagrama de Actividades.
Son utilizados para modelar el comportamiento de los casos de uso, objetos u operaciones y se usan además para elaborar modelos de flujo de trabajo. Muestran el flujo entre objetos e información y capturan las acciones de una actividad y sus resultados.
Los diagramas de actividad permiten describir como un sistema implementa su funcionalidad las actividades modelan el comportamiento dinámico de un procedimiento, transacción o caso de uso haciendo énfasis en el proceso que se lleva a cabo.
Los diagramas de actividad es uno de los elementos de modelado que son mejor comprendidos por todos, ya que son herederos directos de los diagramas de flujo, pero los diagramas de actividad son más expresivos que los diagramas de flujo. 
Diagrama de estados
La secuencia de estados en  caso de uso, indicando qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que generan. Se utilizan para modelar el comportamiento de los objetos en el sistema. Los diagramas de estado son útiles para describir el comportamiento de clases y sistemas que han sido concebidos haciendo uso de un modelo de estados. En un modelo de estados se identifican las situaciones en la que el comportamiento o capacidad de respuesta con cualitativamente diferentes.
CONCLUSIÓN.
Los diagramas de clases describen el objeto es decir sus métodos y sus atributos lo que da una visión general del objeto además se visualiza las relaciones entre las clases del sistema, los diagrama de actividades son parecido a diagrama de flujo pero lo diagrama de actividad permiten describir su funcionalidad del proceso, Los diagramas de estado son útiles para describir el comportamiento de clases lo cual se utiliza para ver el comportamiento de los objetos.


BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición
Kendall, J; Kendall, K.2011. Análisis y diseño de sistemas. 8va edición.