domingo, 14 de octubre de 2012



INGENIERÍA DEL SOFTWARE
2DO CUESTIONARIO

1. Realizar un pequeño mural con recortes periodísticos acerca de lo que las empresas están requiriendo en el área de la informática.




 2. Análisis y Diseño estructurado de nuestro proyecto


D.E.R



DIAGRAMA DE COMPONENTES


DIAGRAMA DE CLASES


DIAGRAMAS DE CASOS DE USOS





DIAGRAMA DE ESTADO



3. Calcule las métricas orientadas al tamaño, punto de función y ampliadas, así como las métricas de calidad.



PSEUDOCODIGO FARMACIA JERUSALÉN

Main()
{
Int opción;
Do{
Print(“MENU”);
Print(“1. Ingresar producto”);
Print(“2. Ingresar Proveedor”);
Print(“3. Devolución Producto”);
Print(“4. Salir);
read(opción);
switch(opcion)
{
Case 1:IngresarProducto();
             Break;
Case 2:IngresarProveedor();
             Break;
Case 3:devolucion();
             Break;
Default: print(“OPCION INVALIDA”);
             Break;
}
While(opcion !=4);
}

IngresarProducto() {
Int id,cantidad;
String nombre;
Print (“ID Producto:”);
Read (id);
Print (“Nombre del producto:”);
Read (nombre);
Print (“Cantidad:”);
Read (cantidad);
Guardar(id,nombre,cantidad);
}

IngresarProveedor()
{
Int id;
String nombre;
String dirección;
String  telefono;
Print (“id de Proveedor:”);
Read (id);
Print (“Nombre:”);
Read (nombre);
Print (“Direccion:”);
Read (direccion);
Print (“Telefono:”);
Read (telefono);
Guardar(id,nombre,dirección,telefono);
}

Devolucion()
{
Int idprod, idprv , cantidad;
Time fecha;
Print (“ID Producto:”);
Read (idprod);
Print (“ID Proveedor:”);
Read (idprv);
Print (“Cantidad devuelta:”);
Read (cantidad);
Print (“Fecha de devolucion:”);
Read (fecha);
Guardar(id,nombre,cantidad);
}

 POSIBLES RIESGOS DEL SW GENERICOS





4. Preparar material Didáctico acerca de la garantía de calidad y gestión de configuración del software.

GARANTIA DE CALIDAD DEL SOFTWARE (SQA/GCS)


La tendencia de la calidad
La tendencia de la calidad se ha utilizado desde los años cuarenta con el objetivo de obtener una alta calidad del producto tanto en ahorro de costes y en una mejora general, para ello se basa en la terminología de GTC (gestión de calidad total) normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.
Los dos primeros pasos se centran en la mejora del proceso, el tercer paso se centra en el usuario del producto y finalmente el cuarto paso va más allá del producto se centra en la utilización del producto en el mercado.

Garantía de calidad del software
Para tener una garantía de calidad del software debe existir una concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo claramente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.

Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
Muchas de las veces existe un conjunto de requisitos implícitos que a menudo no se mencionan por ejemplo: el deseo por facilitar el uso y un buen mantenimiento. Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software no se logra.

Puntos importantes:
1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
3.Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

Problemas de fondo
La historia de la garantía de calidad en el desarrollo de software es paralela a la historia de la calidad en la creación de hardware. Durante los primeros años de la informática (los años cincuenta y sesenta), la calidad era responsabilidad únicamente del programador. Durante los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares para desarrollo de software y se han extendido rápidamente a los desarrollos de software en el mundo comercial

Ampliando la definición presentada anteriormente, la garantía de calidad del software (SQA) es un «patrón de acciones planificado y sistemático» que se requiere para asegurar la calidad del software.

El grupo de SQA sirve como representación del cliente en casa. Es decir, la gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente.

Actividades de SQA
La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes los ingenieros de software que realizan trabajo técnico y un grupo de SQA que tiene la responsabilidad de la Planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes-.
Los ingenieros de software afrontan la calidad (y realizan garantía de calidad) aplicando métodos técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de software bien planificadas.

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad. El Instituto de Ingeniería del Software recomienda un conjunto de actividades de SQA que se enfrentan con la planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes. Éstas son las actividades que realizan(o facilitan) un grupo independiente de SQA:
Establecimiento de un plan de SQA para un proyecto.
El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de garantía de calidad realizadas por el equipo de ingeniería del software y el grupo SQA son gobernadas por el plan. El plan identifica:
evaluaciones a realizar,
auditorias y revisiones a realizar,
estándares que se pueden aplicar al proyecto,
procedimientos para información y seguimiento de errores
documentos producidos por el grupo SQA,
realimentación de información proporcionada al equipo de proyecto del software.

Cuál es el papel de un grupo de SQA
Participación en el desarrollo de la descripción del proceso de software del proyecto. El equipo de ingeniería del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa, los estándares internos del software, los estándares impuestos externamente (por ejemplo: 1SO 9001), y a otras partes del plan de proyecto del software.
Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido. El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones.
Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software. El grupo de SQA revisa los productos seleccionados; identifica, documenta y sigue la pista de las desviaciones; verifica que se han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al gestor del proyecto.
Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables o en los productos técnicos.
Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.


GESTION DE LA CONFIGURACION DEL SOFTWARE (GCS/SCM)

LINEA BASE.
          Especificación o producto que se ha revisado “formalmente” y sobre la que se ha llegado a un acuerdo y, que de ahí en adelante, sirve como base para un desarrollo posterior y que puede cambiarse sólo a través de procedimientos formales de control de cambios.

Elementos de configuración del software
  • Es un documento completo de casos de prueba o un componente de un programa dado.
  • Estos se organizan como objetos de configuración.
  • Especificacion de diseño.
    • Diseño arquitectonico.
    • Diseño de datos.
    • Diseño de modulos.

Diseño de interfaces
El proceso de GCS.
  • Garantiza la calidad del software, su responsabilidad principal es el control de cambios.
  • También es importante de las distintas versiones del software, de las auditorias de la configuración  del software para asegurar que se desarrollen adecuadamente y de la generación de informe sobre los cambios realizados en la configuración.
La GCS llevan a la definición de 5 preguntas
(1). Identificación de objetos en la configuración del software
  • Se identifican 2 tipos de objetos.
  • Objeto básico.
Es una unidad de texto creada por el ingeniero de software durante el análisis, diseño, codificación o pruebas.
  • Objeto compuesto.
Es una colección de objetos básicos.
(2). Control de versiones.
  • Combina procedimientos y herramientos para gestionar las versiones de los objetos de configuración creados durante el proceso del software.

(3). Control de cambios.
  • Para cada cambio aprobado se genera una orden de cambio de ingenieria (OCI), que describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisión y de auditoria.
(4). Auditoria de la configuración.
  • La identificación, el control de versiones y el control de cambios ayudan al equipo de desarrollo de software a mantener un orden.
  • Se plantea las siguientes preguntas.
Ø  Se ha hecho el cambio especificado en la OCI?
Ø  Se han especificado la fecha del cambio y el autor?
Ø  Se han seguido procedimientos de GCS para señalar el cambio, registrarlo y divulgarlo?
Ø  Se han actualizados adecuadamente todos los ECS relacionados?
(5). Informe de estado.
  • Llamada también contabilidad de estado.
  • Que pasó?
  • Quién lo hizo?
  • Cuándo pasó?
  • Qué mas se vio afectado?


Resumen.
La GCS es una actividad de protección que se aplica a lo largo de todo el proceso del software. Una vez se ha desarrollado y revisado un objeto de configuración, se convierte en una línea base. El control de versiones es un conjunto de procedimientos y herramientas que se usan para gestionar el uso de los objetos. El control de cambios es una actividad procedimental que aseguran la calidad y la consistencia a medida que se realizan cambios en los objetos de la configuración.





sábado, 13 de octubre de 2012





INGENIERÍA DEL SOFTWARE
(1er Cuestionario en conjunto con el 1er Sistemático)


1.Explicación de las características del Software.
2.Ejemplos en donde se aplica las características del Software.
3.Explicación de las capas de desarrollo del Software.
4. Explicación mediante un paquín de los diferentes mitos y realidades en el desarrollo del Software
5.Explicación de los modelos de desarrollo del Software


                                                                         

       Explicación de las características del SW

El software no se fabrica, se desarrolla
Los software son desarrollados o construidos mediante la intervención de un grupo de personas trabajando en  conjunto de acuerdo a algún estudio previo del problema presente en cierta entidad que requiera de un sw. Y se dice que no se fabrica porque  no se hace a partir de sus componentes o a través de maquinas.

El software no se estropea, se desactualiza
Básicamente lo que le sucede a los sw con el tiempo es la desactualización quedando estos obsoletos o estropeados para los ojos de los usuarios finales. Pero esto no quiere decir que no se le pueda dar el debido mantenimiento para dichas actualizaciones acordes a las nuevas necesidades del cliente.

El sw no se ensambla se construye a medida
Respecto a la creación de los software se tienen que crear  como ya habíamos expuesto anteriormente, mediante algún estudio previo del problema presente en cierta entidad. Y no siempre es funcional ensamblar cierto sw creado para determinada empresa en otra a la que los requisitos sean aparentemente los mismo, hablando acorde al desarrollo funcional de está con la otra.


        Ejemplos de la aplicación del Software.



    


      Explicación de las capas del desarrollo del sw.

Calidad: en esta etapa se abordan afondo los requisitos que necesita  nuestro software (¿Qué es lo que necesita nuestro sw para ser funcional?), se realizan una cierta cantidad de pruebas para ver la funcionalidad del sw y entregar al final que se ajuste a las necesidades del cliente.

Procesos: en esta etapa se define el ¿Cómo realizaremos, nuestro software? basándonos en el estudio ya analizado en la primer etapa. Se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

Métodos: Nos indican como construiremos nuestro software, apartir del análisis de requisitos, diseño, pruebas y mantenimiento incluyendo las actividades de modelado definiendo el ¿A través de que, realizaremos nuestro sw?

Herramientas: definimos el ¿Con qué desarrollaremos nuestro sw? Luego de haber pasado cada una de las etapas ya anteriores, auxiliándonos de las herramientas CASE para dicho desarrollo.


ESCENARIOS EN DONDE SE REFLEJA LOS MITOS Y REALIDADES DEL SW. EN CUANTO A GESTON, CLIENTE Y EQUIPO DESARROLLADOR.

   





APLICACIÓN DE LOS MODELOS DE DESARROLLO

Modelo lineal: la aplicación del modelo lineal la apreciamos en todo en transcurso del desarrollo del software ya que este modelo está basado en la creación progresiva del software.

Modelo de desarrollo Rápido: al igual que el modelo lineal el modelo de desarrollo está implícito en todo el desarrollo del sw, a diferencia que este está enfocado en el trabajo interno del grupo desarrollador del sw. Ej.: La planeación del buen desempeño de un software realizado por el grupo desarrollador.

Modelo de incremental: Si bien este modelo está basado en la corrección del sw. A medida de que vamos desarrollando nuestro software se nos presentaran una serie de errores que tenemos que corregir es ahí donde se hace presente el modelo incremental el cual nos permite ir avanzado progresivamente en la creación de nuestro sw, ya que este es flexible.

Modelo Espiral: Este modelo es aquel que nos permite darle mantenimiento y/o actualización a nuestro sw basado en las nuevas necesidades del cliente para éste.

Modelo de Desarrollo Concurrente: este modelo lo aplicamos mucho antes de empezar a crear nuestro sw, ya que este nos define los requisitos que necesita nuestro sistema para ser funcional, en este modelo es donde se realiza el análisis de requisitos.


Primer Sistemático


Sabiendo las características de los sw, ¿cómo se aplicarían a un sw contable?
“El Software no se implementa, se construye a medida”planteo esta característica ya que cierto software creado para “x” entidad financiera puede no suplir las necesidades de la otra entidad a la cuales los requisitos son aparentemente los mismos, por eso decimos que un software se tiene que construir a medida.

Mencione las diferencias entre un tipo de aplicación de sw y otro
Véase en los ejemplos de la aplicación del software, al principio del capítulo

Realice un paquín Ilustrado, Explicando gráficamente los mitos y realidades de la Ing. del SW
Véase en los ESCENARIOS EN DONDE SE REFLEJA LOS MITOS Y REALIDADES DEL SW. EN CUANTO A GESTON, CLIENTE Y EQUIPO DESARROLLADOR, al principio del capítulo


Explicación del grafico del pastel
Véase en la Explicación de las capas del desarrollo del sw, al principio del capítulo


Elabore un cuadro sinóptico con las fases genéricas que se practican durante el proceso del sw




 Proponga una situación en donde usted tenga que hacer uso del hito que se expresa en el marco del trabajo común de la Ing. del sw


Los Hitos se refieren a la toma de decisiones para llevar a cabo determinada tarea.
Ej.:
Cuando vamos a desarrollar un sistema, luego de haber concluido el análisis del sistema, tenemos que tomar los caminos más viables para llevar a cabo dicho desarrollo en donde  incluyamos costos económicos, recursos disponibles, cantidad de personas en el equipo desarrollador, etc.