Deprecated: Function eregi() is deprecated in http://elblogdelprofesto.blogspot.com/ on line 3

CALIDAD DEL SOFTWARE


Calidad: Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.

Software: Conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.

ISO: siglas de International Organisation for Standardization, Organización Internacional de Normalización, organismo encargado de coordinar y unificar las normas nacionales. En 1926, 22 países se reunieron para fundar una federación internacional de los comités nacionales de normalización, la ISA (International Standardizing Associations). Este organismo fue sustituido en 1947 por la ISO, cuya sede está situada en Ginebra. Cada país miembro está representado por uno de sus institutos de normalización, y se compromete a respetar las reglas establecidas por la ISO relativas al conjunto de las normas nacionales. Esta institución tiene por tarea desarrollar la normalización con carácter mundial y, a tal efecto, pública normas internacionales conocidas como "normas ISO", que intentan acercar las normas nacionales de cada Estado miembro. La ISO es un organismo consultivo de las Naciones Unidas.



Las ventajas de implantar un sistema de gestión de la calidad son las siguientes:

1. Aumento de beneficios.
2. Aumento del número de clientes.
3. Motivación del personal.
4. Fidelidad de los clientes.
5. Organización del trabajo.
6. Mejora de las relaciones con los clientes.
7. Reducción de costes debidos a la mala calidad.
8. Aumento de la cuota de mercado.


Los factores de la calidad del software y los defectos
Originalmente, la calidad de un programa o sistema se evaluaba de acuerdo al número de defectos por cada mil líneas de código.

En 1988, un estudio realizado en los EEUU, demostró que se introducían cerca de sesenta defectos por cada mil líneas de código (60 def/KLOC), hoy se le adicionan otros factores a la calidad del software.

Los factores que determinan la calidad del software se clasifican en tres grupos:

1. Operaciones del producto: características operativas

2. Corrección: Grado en que un programa satisface sus especificación y logra los objetivos marcados por el usuario. (¿Hace lo que se le pide?).

3. Fiabilidad: Grado en que se puede esperar que un programa lleve a cabo las funciones esperadas con la precisión requerida. (¿Lo hace de forma fiable todo el tiempo?).

4. Eficiencia: Cantidad de recursos de computadoras y de código requeridos por el programa para realizar sus funciones con los tiempos de respuesta adecuados. (¿Qué recursos hardware y software necesito?).

5. Integridad: Grado en que puede controlarse el acceso al software o a los datos por usuarios no autorizados. (¿Puedo controlar su uso?).

6. Facilidad de uso: Esfuerzo necesario para aprender, utilizar, preparar las entradas e interpretar las salidas de un programa. (¿Es fácil y cómodo de manejar?).

7.Revisión del producto: capacidad para soportar cambios.

8. Facilidad de mantenimiento: Esfuerzo requerido para localizar y arreglar un error en un programa. (¿Puedo localizar los fallos?).

9. Flexibilidad: Esfuerzo requerido para modificar un programa. (¿Puedo añadir nuevas opciones?).

10. Facilidad de prueba: Esfuerzo requerido para probar un programa de forma que se asegure que realiza la función requerida. (¿Puedo probar todas las opciones?).
Transición del producto: adaptabilidad a nuevos entornos.

11. Portabilidad: Esfuerzo requerido para transferir un programa desde un entorno HW y/o SW a otro. (¿Podré usarlo en otra máquina?).

12. Reusabilidad: Grado en que un programa o componente SW se puede reutilizar en otras aplicaciones. (¿Podré utilizar alguna parte del software en otra aplicación?).

13. Interoperatividad: Esfuerzo requerido para acoplar un sistema con otras aplicaciones o sistemas. (¿Podrá comunicarse con otras aplicaciones o sistemas informáticos?).

Métricas de la calidad software

Es difícil, y en algunos casos, imposible, desarrollar medidas directas de los factores de calidad del software. Cada factor de calidad Fc se puede obtener como combinación de una o varias métricas:

Fc= c1 * m1 + c2 * m2 + … + cn * mn

Ci: factor de ponderación de la métrica i, que dependerá de cada aplicación específica.

mi: métrica i.

(Habitualmente se puntúan de 0 a 10 en las métricas y en los factores de calidad).

Métricas para determinar los factores de calidad:

a. Facilidad de auditoria.
b. Exactitud.
c. Normalización de las comunicaciones.
d. Completitud.
e. Concisión.
f. Consistencia.
g. Estandarización de los datos.
h. Tolerancia de errores.
i. Eficiencia de la ejecución.
j. Facilidad de expansión.
k. Generalidad.
l. Independencia del hardware.
m. Instrumentación.
n. Modularidad.
ñ. Facilidad de operación.
o. Seguridad.
p. Autodocumentación.
q. Simplicidad.
r. Independencia del sistema software.
s. Facilidad de traza.
t. Formación.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

PLAN DE PRUEBAS DE SOFTWARE


El Plan de Pruebas
El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.
Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación, integración e integración).

Un plan de pruebas incluye:

1. Identificador del plan.
Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicionalmente la versión y fecha del plan.

2. Alcance
Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Items a probar
Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4. Estrategia
Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej. 100% de las fronteras, 60% de los caminos ciclomáticos... La estrategia también explicita el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.

5. Categorización de la configuración
Explicita las condiciones bajo las cuales, el plan debe ser:
Suspendido,
Repetido;
Culminado.
En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qué punto, ya que puede ser necesario repetir algunas pruebas. Los criterios de culminación pueden ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.

6. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora de pruebas.

7. Procedimientos especiales
Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.

8. Recursos
Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas (p. ej. el sistema de operación), cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar (p. ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo.
La sección incluye un estimado de los recursos humanos necesarios para el proceso. También se indican cualquier requerimiento especial del proceso: actualización de licencias, espacio de oficina, tiempo en la máquina de producción, seguridad.


9. Calendario
Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.

10. Manejo de riesgos
Explicita los riesgos del plan, las acciones mitigantes y de contigencia.

11. Responsables
Especifica quién es el responsable de cada una de las tareas previstas en el plan.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Metodología para Requisitos del Sistema

Les dejo un metodología para la obtención y presentación de reportes para los requisitos del sistema.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Disciplinas Fundamentales

Acá les dejo ebook de la materia, para que estudien... 

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Relaciones entre CU: extends

El CASO DE USO A extends al CASO DE USO B si SIEMPRE que se ejecuta el caso de uso B, si se cumple la condición C, entonces se ejecuta el caso de uso A


  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Relaciones entre CU: includes

El CASO DE USO A includes al CASO DE USO B si SIEMPRE que se ejecuta el caso de uso A, se ejecuta el caso de uso B

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Suspendidas la Clases de Hoy

Estimad@s las clases de hoy se suspenden pero no la entrega de trabajo por lo que espero en mi correo hasta las 23:59 los trabajos.
elprofecesarvalenzuela@gmail.com

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Elementos de Diagramas de Casos de Uso


  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Quest del Computin N°2

1.- De que se componen los ciclos de vidas. 

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se van produciendo(realimentación). Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Entregables: son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software).

2.- Cuales son las principales diferencias entre distintos modelos de ciclo de vida. 

• El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o en el extremo, toda la historia del producto con su desarrollo, fabricación y modificaciones posteriores hasta su retirada del mercado.
• Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto, o de la organización.
• La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).

3.- Que es un modelo de ciclo de vida de software

• Es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas etapas.
• Describe las fases principales de desarrollo de software.
• Define las fases primarias esperadas de ser ejecutadas durante esas fases.
• Ayuda a administrar el progreso del desarrollo.
• Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo de software.
• En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y la elección de un modelo para un determinado tipo de proyecto es realmente importante; el orden es uno de estos puntos importantes.

4.- Ventajas del Modelo en Cascada.

• El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación. Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.
• Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.
• Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables específicos y un proceso de revisión. Las fases son procesadas y completadas de una vez.

 5.- Definición Modelo Iterativo.

• Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos.
• Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente.
• Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

6.- Comparación del modelo espiral en relación a los otros modelos.


• La distinción más destacada entre el modelo en espiral y otros modelos de software es la tarea explícita de evaluación de riesgos. Aunque la gestión de riesgos es parte de otros procesos también, no tiene una representación propia en el modelo de proceso. Para otros modelos la evaluación de riesgos es una sub-tarea, por ejemplo. Además no hay fases fijadas para la especificación de requisitos, diseño y pruebas en el modelo en espiral. Se puede usar prototipado para encontrar y definir los requisitos.
• La diferencia entre este modelo y el modelo de ciclo incremental es que en el incremental se parte de que no hay incertidumbre en los requisitos iniciales; en este, en cambio, se es consciente de que se comienza con un alto grado de incertidumbre. En el incremental suponemos que conocemos el problema y lo dividimos. Este modelo gestiona la incertidumbre.
7.- Para aprender UML necesitan aprende ciertos conceptos Básicos, estos son:


• Clase: Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases.
• Abstracción: Se Refiere a quitar las propiedades y acciones de un objeto para dejar sólo aquellas que sean necesarias.
• Herencia: Se refiere a la compartición de atributos y operaciones basada en una relación jerárquica entre varias clases.
• Polimorfismo: Permite que una misma operación pueda llevarse a cabo de forma diferente en clases diferentes.
• Encapsulamiento: es cuando un objeto trae consigo funcionalidad, esta última se oculta.
• Envío de mensajes Un sistema de Objetos Trabaja en conjunto. Esto se logra medi• Asociaciones: La multiplicidad en un importante aspecto de las asociaciones, Indica la cantidad de objetos de una clase que se relacionan con otro objeto en particular de la clase asociada.
• Agregación: Es cuando los objetos se integran pero conservan su independencia.
• Composición: El concepto de composición es similar al de la agregación, pero sus objetos que lo integran no tendrán su independencia. ante el envío de mensajes entre ellos y el objeto receptor ejecutará la operación o funcionalidad, esta última se oculta.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Enterprice Architect 7.5 Español


Ahora esta Disponible la version en español, solo deber instalar la aplicación siguiendo el método de instalación que le indica el programa y listo... Enterprice Architect en Español...

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Elementos Básicos para EA


  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Quest del Computin N° 1

Toda la información esta disponible en la guía N°1, adjunta en este blog.
1.- En las etapas del software defina que es una PRUEBA. Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica que las pruebas sean efectuadas por alguien distinto al programador que la programó.

 2.- Los Componentes o capas que forman parte de la ingeniería del software son: Procesos: un marco de trabajo que ayuda al jefe de proyecto a controlar la gestión del proyecto y las actividades de ingeniería. Métodos: las actividades técnicas requeridas para la creación de productos de trabajo. Herramientas: la ayuda automatizada para los procesos y métodos. 

3.- En las 4 p del software los participantes se clasifican en : 
Gestores Ejecutivos: Definen los aspectos del negocio. 
Gestores de Proyecto: Planifican, motivan y controlan a los profesionales que participan en el proyecto. Profesionales: Proporcionan la habilidades técnica necesarias para el DS. 
Clientes: Especifican y entregan los requerimientos del SW. 
Usuario Final: Interactúan directamente con el Software. 

4.- indique las ventajas del modelo en V. Es un modelo simple y fácil de utilizar. En cada una de las fases hay entregables específicos. Tiene una alta oportunidad de éxito sobre el modelo en cascada debido al desarrollo de planes de prueba en etapas tempranas del ciclo de vida. Es un modelo que suele funcionar bien para proyectos pequeños donde los requisitos son entendidos fácilmente. 

5  .- Indique las desventajas del modelo en Incremental. Para el uso de este modelo se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada. Entre los inconvenientes que aparecen en el uso de este modelo podemos destacar los siguientes: Cada fase de una iteración es rígida y no se superponen con otras. Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio. 

6.- Indique y defina brevemente las 4 regiones del Modelo Espiral. La tarea de planificación: para definir recursos, responsabilidades, hitos y planificaciones La tarea de determinación de objetivos: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas La tarea de análisis de riesgos: para evaluar riesgos tanto técnicos como de gestión La tarea de ingeniería: para diseñar e implementar uno o más prototipos o ejemplos de la aplicación

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Prueba Primera Unidad . 23 de mayo

Este Miércoles 23 de mayo prueba equivalente al 15% de la nota del semestre. Se encuentra disponible en el link de descarga la guía con toda la materia de la primera unidad. El objetivo central de la prueba es que el alumno pueda Identificar y determinar los eleme ntos característicos de la Ingeniería de Software.
Esta disponible la Guía de la unidad I en el enlace Descarga de Documento o puedes bajarla desde aquí..

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Sparx Systems Enterprise Architect 7.5.844


Enterprise Architect combina el poder de la última especificación UML 2.1 con alto rendimiento, interfaz intuitiva, para traer modelado avanzado al  escritorio, y para el equipo completo de desarrollo e implementación. Con un gran conjunto de características y un valor sin igual para el dinero, EA puede equipar a su equipo entero, incluyendo analistas, evaluadores, administradores de proyectos, personal del control de calidad, equipo de desarrollo y más, por una fracción del costo de algunos productos competitivos. Verifique el rango completo de las herramientas y características case en detalle. 

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

IBM Software Rational Rose Enterprise

Rational Rose Enterprise es la mejor elección para el ambiente de modelado que soporte la generación de código a partir de modelos en Ada, ANSI C++, C++, CORBA, Java™/J2EE™, Visual C++® y Visual Basic®. Como todos los demás productos Rational Rose, proporciona un lenguaje común de modelado para el equipo que facilita la creación de software de calidad más rápidamente.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS