lunes, 20 de mayo de 2013

CALIDAD EN EL DESARROLLO DEL SOFTWARE

Al conjunto de cualidades que determinan su utilidad. Es decir el cumplimiento de los requisitos especificados como eficiencia, flexibilidad, corrección, mantenimiento, seguridad e integridad.

Desde el punto de vista del cliente, calidad del software es el grado en que un cliente o usuario percibe que el producto software satisface sus necesidades. Desde el punto de vista industrial del producto, calidad del software es la habilidad de un producto software de satisfacer una especificación de requerimientos.



MODELOS DE GESTIÓN DE SOFTWARE
  • CMMI: Orientado a mejora de procesos en diferentes niveles de madurez, más hacia proyectos específicos. 
  • Norma ISO/IEC 12007: Orientado al proceso de ciclo de vida del Software. 
  • METRICA3: Orientado al modelo e implementación. 
  • Norma ISO 15504: Orientado a la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de Software.


Principales características que hacen a un software de calidad

  • Mantenibilidad: el software debe ser diseñado de tal manera, que permita ajustarlo a los cambios en los requerimientos del cliente. Esta característica es crucial, debido al inevitable cambio del contexto en el que se desempeña un software. 
  • Confiabilidad: incluye varias características además de la confiabilidad, como la seguridad, control de fallos, etc. 
  • Eficiencia: tiene que ver con el uso eficiente de los recursos que necesita un sistema para su funcionamiento. 
  • Usabilidad: el software debiera ser utilizado sin un gran esfuerzo por los usuarios para los que fue diseñado, documentado, etc.

DOCUMENTACIÓN DURANTE EL DESARROLLO DEL SOFTWARE

La documentación se suele clasificar en función

de las personas o grupos a los cuales está dirigida:
•Documentación para los desarrolladores
•Documentación para los usuarios
•Documentación para los administradores o soporte técnico

Documentación para los desarrolladores
  • Es aquélla que se utiliza para el propio desarrollo del producto y, sobre todo, para su mantenimiento futuro. 
  • Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas.
  • En este sentido, todas las fases de un desarrollo deben documentarse: requerimientos, análisis, diseño, programación, pruebas, etc.. 
  • Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un caso particular es el de UML, que analizamos en otra obra. 
  • De todas maneras, los diagramas son muy útiles, pero siempre y cuando se mantengan actualizados, por lo que más vale calidad que cantidad.
Documentación para los usuarios

  • La documentación para usuarios es todo aquello que necesita el usuario para la instalación, aprendizaje y uso del producto. Puede consistir en guías de instalación, guías del usuario, manuales de referencia y guías de mensajes 
  • Los usuarios no leen los manuales a menos que nos les quede otra opción, se recurre a los manuales solamente cuando se produce un error o se desconoce cómo lograr algo muy puntual, y recién cuando la ayuda en línea no satisface las necesidades del usuario.
  • Es incluso deseable proveer un software tutorial que guíe al usuario en el uso del sistema, con apoyo multimedia, y que puede llegar a ser un curso online. 
  • Buena parte de la documentación para los usuarios puede empezar a generarse desde que comienza el estudio de requisitos del sistema.
Documentación para administradores
  • También soporte técnico, a veces llamada manual de operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. 
  • Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. 
  • Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo

METODOLOGÍA PARA DESARROLLO DE SOFTWARE

Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, Planear y controlar el proceso de desarrollo en sistemas de información.

A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.

El framework para metodología de desarrollo de software consiste en:
  • Una filosofía de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software
  • Herramientas, modelos y métodos para asistir al proceso de desarrollo de software
Estos frameworks son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo documentada en algún tipo de documentación formal.

Enfoques de desarrollo de software


Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:

  • Modelo en cascada: Framework lineal. : Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implementación, pruebas (validación), la integración, y mantenimiento. 
  • Prototipado: Framework iterativo:  dedicada al desarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar.
  • Incremental: Combinación de framework lineal e iterativo: Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.
  • Espiral: Combinación de framework lineal e iterativo.
  • RAD: Rapid Application Development, framework iterativo.

ADMINISTRACIÓN DE UN PROYECTO DE INGENIERÍA DE SOFTWARE



La administración de proyectos de desarrollo de software consiste en gestionar el desarrollo de un producto, dentro del plazo previsto y con los fondos establecidos. Como esto requiere recursos humanos , la administración del proyecto involucra no sólo la organización técnica y las habilidades organizativas, sino también el arte de dirigir un equipo de personas. La administración de un proyecto no es una actividad insignificante, puede ser tan trascendente como desarrollar la arquitectura.


La administración de un proyectos comprende:
•Estructura (Elementos organizativos involucrados)
•Proceso administrativo (Responsabilidades y supervisión de participantes)
•Proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo)
•Programa (organización de los tiempos en los que deben realizarse los trabajos)


Los objetivos que pretende una correcta administración de proyectos son:

  • Introducir el concepto de “Administración de proyectos”
  • Organizar equipos de trabajo.
  • Especificar planes de administración de proyectos.
  • Definir y eliminar riesgos.
  • Estimar costos desde el inicio de proceso.
  • Programar el proyecto a alto nivel.
Factores de la administración de un proyecto.
La administración de un proyecto debe controlar los siguientes factores:
  • El costo total del proyecto, por ejemplo, aumentar o disminuir los gastos.
  • Las capacidades del proyecto, como añadir o eliminar características funcionales.
  • La calidad del producto, como aumentar el tiempo entre fallos de una cierta severidad.
  • La duración del proyecto, por ejemplo, reducir el tiempo programado un 20% o posponer un mes la fecha de terminación
La calidad,la capacidad los costos y los tiempos de realización son magnitudes que hay que gestionar a los largo de un proyecto. El grado en el que estos cuatro factores pueden controlarse dependen de la naturaleza del proyecto.

▪ Aunque los costos pueden estar prefijados de antemano, frecuentemente se dispone de flexibilidad.
▪ La capacidad del proyecto puede re negociarse en función de la evolución del proyecto.
▪ La calidad también puede variar, es decir; cuando la calidad se establece baja, se disminuye los costos de
corto plazo, pero se incrementan los costos de largo plazo debido al costo de mantenimiento y la insatisfacción de los clientes. Si se establece una calidad excesiva, el costo de desarrollo se puede hacer  inaguantable. 
▪ Negociar el tiempo frente a cualquiera de las otras magnitudes es también algo habitual.

Diagrama polar de las variables de un proyecto.

El diagrama polar permite visualizar la evolución de estas cuatro magnitudes durante el desarrollo de un proyecto. El origen representa el valor menos favorable de cada variables, y los valores previstos como meta se dibujan a igual distancia del origen. Con ello el proyecto previsto corresponde a un cuadrado. Por ejemplo, en la línea izquierda de capacidades, la meta es obtener el 100% de las capacidades previstas, mientras que el origen es ninguna capacidad concedida.
En el estado real de un proyecto, las magnitudes tendrán diferentes valores de los deseados, y si se unen resulta un cuadrilátero sólido que tanto en cuanto mas se aproxime al cuadrado representa un mayor equilibrio en el desarrollo del proyecto.


Secuencia de actividades de administración de un proyecto.

  • Comprender el contenido, alcance y tiempos del proyecto.
  • Identificar el proceso de desarrollo, como métodos, herramientas, lenguajes, documentación, ayudas.
  • Determinar la estructura organizativa, elementos de la organización involucrados.
  • Identificar el proceso administrativo, establecer la responsabilidades de los participantes.
  • Programar el proceso, organigramas en los que se fijan los tiempos de ejecución de cada actividad.
  • Establecer un equipo de personas, se buscan y contrata el equipo de personas.
  • Analizar los riesgos y buscar sus paliativos.
  • Enumerar los producto que debe generar el proyecto.

Administración del proyecto

1. El ingrediente principal para producir software es el equipo humano:
􀂄 Profesionalidad: Tienen responsabilidades sociales
􀂄 Trabajo en equipo:Organización de las funciones e interacciones
􀂄 Liderazgo: Marca la dirección del trabajo basado en la experiencia.
2. Perspectiva de la empresa
􀂄 El objetivo es obtener negocio
􀂄 El personal se ve como un recurso mas del que hay que hacer uso.
3. Perspectiva de la administración
􀂄 Posición media entre el negocio y los intereses de los ingenieros.
􀂄 La solución es el liderazgo: Habilidad para extraer el deseo natural de colaborar de los ingenieros y participar de modo activo en una actividad exitosa.
􀂄 En los grandes proyectos los lideres son administrativos, en los pequeños técnicos.
4. Perspectiva del ingeniero
􀂄 Quieren tener trabajo interesante.
􀂄 Oportunidades para ser reconocidos y recompensados.
􀂄 Relación


Criterios para organizar las reuniones de trabajo

1. Planificar los tiempos de planteamiento, discusión y conclusiones.
2. Llevar preparado una primera versión del producto objeto de la reunión.
3. Exigir que las reuniones comiencen a su hora.
4. Registrar las decisiones que requieren acciones.
5. Llevar un control del tiempo:
􀂄 Haga excepciones cuando la discusión es productiva.
􀂄 Interrumpa una discusión excesiva.
6. Mantener la discusión dentro del tema.
7. Enviar por e-mail los aspectos que requieren acciones y el resumen de las decisiones.


Organización de un equipo.

1. Se selecciona un líder
􀂄 Asegura que se activen todos los aspectos del proyecto.
􀂄 Resuelve las diferencias.
􀂄 Propone las primeras tentativas
􀂄 Busca que el equipo lo acepte.
2. Se designan y documentan las responsabilidades
􀂄 Líder del equipo: Propone y mantiene
􀂄 Responsable de gestión de la configuración
􀂄 Responsable de calidad
􀂄 Responsable de administración de requisitos
􀂄 Responsable de diseño
􀂄 Responsable de implementación
3. Designar y respaldar a cada responsable
􀂄 Cada responsable debe estar respaldado por otro, que lo suple en caso de baja.


Identificación y eliminación de riesgos

Un riego es cualquier hecho que puede ocurrir a lo largo de la ejecución de un proyecto y que afecta de forma negativa a su desarrollo.
Si los factores de riesgo se reconocen con prontitud, se pueden prevenir su efecto o cambiar su enfoque para minimizar su efecto. Debe adoptarse una “mentalidad de riesgo” permanente.
Las cuatro actividades básicas de la gestión de riesgos son:
􀂄 Identificar los riesgos.
􀂄 Planificar su eliminación.
􀂄 Dar prioridades a los riesgos para su eliminación.
􀂄 Eliminar o atenuar.

viernes, 3 de mayo de 2013

PROCESO DEL SOFTWARE


Es un conjunto estructurado de actividades requeridas para desarrollar un sistema de software

Entre las actividades, tenemos:


  • Identificación y análisis de los requerimientos
  • Diseño
  • Construcción
  • Implementación
  • Mantenimiento


ANÁLISIS





Aquí identificamos los requerimientos del usuario, estos se pueden dar mediante un proceso de comunicación entre el cliente y el ingeniero de software.
Estableciendo las funciones que deberán realizar el software según las necesidades dadas por el cliente después de haber dialogado con el mismo.
Para poder dialogar correctamente con nuestro cliente, debemos prestar mucha atención al mismo, con el debido respeto., también debemos saber preguntar y responder todas las dudas e interrogantes que nuestro cliente pueda tener.
Luego de tener una idea clara de que va a realizar nuestro software, debemos ver la infraestructura con la que cuenta el cliente para poder implantar el software, ver si el resultado final puede o no de alguna forma decirlo correr en el hardware de la empresa. es aquí donde entra el análisis de los requerimientos, los cuales los da el ingeniero de software una vez dialogado con el cliente y sus necesidades.




DISEÑO



Es crear no solo los formularios principales del sistema, sino establecer una serie de parámetros de como van a estar formado cada uno de los formularios del sistema, es decir; tamaño de los formularios  colores, botones y demás, en otras palabras estandarizar las características del sistema en cuestiones gráficas, ya que el usuario es el que va a interactuar con el sistema propiamente hablando.
Para lograr un diseño acorde con las necesidades del cliente, se debe crear prototipos del sistema, pueden ser formularios solo gráficos o con pocas funcionalidades y con estos ir por ejemplo en unta entrevista con el cliente para ver si el prototipo es de gusto de él o no.



CONSTRUCCIÓN



Es cuando ya se dispone a programar el sistema, tiene que ver con toda la tarea codificación del sistema.
Se debe entender el problema y los conceptos básicos del diseño. Y  seguidamente se debe escoger un lenguaje de programación que satisfaga las necesidades y proporcionen las herramientas que faciliten el trabajo. En la codificación se debe entender la arquitectura del diseño, en la validación se debe estar seguro de realizar pruebas y corregir los errores que se hayan descubierto.


IMPLEMENTACIÓN



La demandas de los clientes en un software siempre son:

  • Exactitud
  • Cordialidad
  • Flexibilidad
  • Confiabilidad
  • Atención
En la implementación se está hablando de una vez realizado el programa y visto que funcione, se lo instala en la empresa del cliente para su funcionamiento.
Propiamente hablando, la implementación es la entrega del producto final al cliente, conjuntamente con los manuales instructivos de uso del sistema y de programación.



MANTENIMIENTO



Es una proceso de mejora continua del producto final para obtener la satisfacción del cliente.