domingo, 30 de mayo de 2010

14. Técnicas de recopilación de información en los procesos de desarrollo de software.



Entrevistas y cuestionarios: estos son empleados para reunir información proveniente de personas o de grupos.  Durante la entrevista, el analista conversa con el encuestado.
El cuestionario es una serie de preguntas relacionadas con varios aspectos de un sistema. 
Los encuestados son usuarios de los sistemas existentes o usuarios en potencia del  sistema a desarrollar. Estos pueden ser gerentes o empleados que proporcionan datos para el sistema a desarrollarse  o que serán afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma. 
Sistemas existentes: esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser implementado.  En ellos se observan las interfaces de usuario, el  tipo de información que se maneja y cómo es manejada, así mismo,  se  analizan las distintas salidas que los sistemas producen como son: listados, consultas, etc., estos brindan nuevas ideas sobre cómo presentar la información. 
Lluvia de ideas (Brainstorm): este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable",  "imposible", etc. 
Las reglas básicas a seguir son:
  • Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas. 
  • Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque si no se crea un ambiente hostil que no alienta la generación de ideas.
  • Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil. 
  • A veces ocurre que una idea resulta en otra idea, y otras veces se puede relacionar varias ideas para generar una nueva. 
  • Escribir las ideas sin censura
Casos de Uso: los casos de uso son una técnica para especificar el comportamiento de un sistema. Estos ayudan a capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje, en palabras del IVAR JACOBSON "Describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario"  
Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. 
“Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente, se han convertido en una característica fundamental de la notación UML (Lenguaje de modelado unificado), que se utiliza para describir modelos de sistemas orientados a objetos”.  

13. Modelo en cascada


Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que para iniciar otra etapa debe esta esperar a que termine la anterior.

Un ejemplo de un modelo en cascada es:

  1. Análisis de requisitos
  2. Diseño del Sistema
  3. Diseño del Programa
  4. Codificación
  5. Pruebas
  6. Implantación
  7. Mantenimiento

En algunas ocasiones se utiliza solo las siguientes etapas:


De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo.

Fases del modelo en cascada


Análisis de requerimientos

 

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema

 

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución identificando grandes módulos y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

Diseño del Programa

 

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación

 

Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.

Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas

 

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser puesto

Implantación

 

El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto.

Durante la explotación del sistema de software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios. 


12. Observación y técnica STROBE


El analista de sistemas recurre a una forma crítica estructurada para el análisis de los requerimientos de información. La aplicación exitosa del STROBE requiere que el analista observe explícitamente siete elementos concretos que por lo general se encuentren en las oficinas.

1.    Ubicación de la oficina: Uno de los primeros elementos que el analista de sistemas debe observar es la ubicación de la oficina de un tomador de decisiones específico con respecto a otras oficinas. Las oficinas accesibles tienden a aumentar la frecuencia de la interacción, los mensajes informales, mientras que las oficinas inaccesibles tienden a disminuir la frecuencia de la interacción y a aumentar los mensajes orientados a las tareas.

2.    Colocación del escritorio: La colocación de un escritorio en la oficina puede ofrecer pistas sobre la manera en que el tomador de decisiones ejerce su autoridad. El analista de sistema debe observar la distribución de los muebles de la oficina, y en particular la colocación del escritorio.

3.    Equipo fijo de oficina: Archiveros, libreros y otro equipo grande influyen en la categoría de equipo fijo de oficina. Si no hay equipo, es probable que el tomador de decisiones almacene muy pocos artículos de información por sí mismo. En caso contrario, se asume que el tomador de decisiones valora mucho la información.

4.    Accesorios: El termino accesorios se refiere a todo el equipo pequeño usado para procesar la información, incluso las computadoras de bolsillo, calculadoras, PCs, plumas, lápices y reglas. Si se posee este equipo probablemente lo que indica el tomador de decisiones es que ocupa su equipo más allá de su oficina.

5.    Fuentes externas de información: Un analista de sistemas necesita saber qué tipo de información usa el tomador de decisiones. La observación del tipo de publicaciones almacenadas en la oficina puede revelar si el tomador de decisiones recurre a la información externa (revistas de comercio, recortes de periódico sobre otras compañías de industria) o se basa en la información interna (informes de la compañía, correspondencia de la oficina, manuales de políticas).

6.    Iluminación y color de oficina: La iluminación y el color de la oficina juegan un papel importante por lo que contar con estos factores ayudara a tener una tendencia a la comunicación personal. Un ejecutivo en una oficina iluminada cálidamente recuperará más información de manera informal.

7.    Vestimenta de los tomadores de decisiones: Un analista de sistemas puede darse una idea de la credibilidad de los gerentes de la organización al observar la vestimenta que usan en el trabajo. El hecho de que los líderes vistan de manera casual tiende a abrir las puertas para una toma de decisiones más participativo, pero a menudo propicia la pérdida de credibilidad en la organización si la cultura predominante valora la ropa tradicional y conservadora.



11. La herramienta CASE



Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) estas aplicaciones funcionas como reductoras de tiempo así mismo pero siempre dirigidas hacia la productividad de software. Básicamente estas aplicaciones engloban un gran círculo de manejos como lo son el cálculo, el diseño, la documentación  al igual en la detección de errores, pero lo más común es que se usen como apoyo en métodos
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Trabajando con ellos por sus objetivos los cuales son:
  1. Mejorar la productividad en el desarrollo y mantenimiento del software.
  2. Aumentar la calidad del software.
  3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
  4. Mejorar la planificación de un proyecto
  5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
  6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
Aunque se deben de tener en cuenta varios aspectos como lo son el ciclo de vida, así mismo la plataforma en la que se implementara no dejando olvidado la funcionalidad para la que fue creado y para que será usado.

10. Modelo espiral en el proceso de software


Es un método que se utiliza en ingeniería de software para representar el ciclo de vida de un software. Se utiliza para dividir los estados o etapas que pasa un software desde el principio hasta el final que ya está en el mercado. Básicamente el modelo consiste es una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro hasta el final del mismo.
Para este modelo en cada vuelta del modelo se toman diferentes consideraciones entre ellas están.
Objetivos: Que necesidad debe cumplir el Producto
Alternativas: Diferentes formas de conseguir los objetivos entre ellas tenemos tres:
1.- Características: Experiencia del personal y requisitos a cumplir.
2.- Formas de Gestión del Sistema
3.-Riesgo asumido en cada Alternativa
Desarrollar y Verificar: programar y probar el software
Se planificaran los pasos y se volverá a empezar la espiral, a misma que tiene una forma de caracola.
Dentro de la caracola podemos encontrar dos dimensiones radial  y angular
La angular representa el avance del proyecto, dentro de un ciclo y la radial aumenta el costo  del proyecto, ya que con cada nueva iteración el tiempo de desarrollo es cada vez mas tardado.
Este tipo de modelo es utilizado en proyectos como la realización de un Sistema Operativo 

9. Modelo incremental en el proceso de software



Quiero hacer mención que para poder dar una síntesis sobre el modelo incremental en el proceso de software se tiene que hablar casi por fuerza sobre el modelo lineal también conocido como modelo en cascada.
Este modelo consta de seis etapas donde abarca prácticamente un proceso completo en cuestión de programación.
En resumen trata que el modelo en cascada  no se puede o no permite retroceder una vez realizada la programación del diseño que se tenga ya hecho. El programador en este modelo tiene que ir validando paso a paso la programación desarrollada y de este modo quede así validado.
Una vez entregado el sistema al cliente se tendrá que ir haciendo su respectivo mantenimiento y actualizaciones o en su caso correcciones.
Así pues el modelo incremental tiene las ventajas de poder hacer un diseño, si este se ha llevado a cabo y al final el programador no ha quedado satisfecho o es su caso el cliente tiene inconvenientes con el software, el programador puede volver  llevar  cabo partes de la programación sin necesidad de tener que hacer un análisis completo de lo que se ha estado programando.
Este sistema es pues de gran ventaja en cuestión de programación. Ya que se ha obtenido la ventaja de tener esa parte de actualización del modelo. La ventaja de poder programar sin necesidad de comenzar desde cero.

8. Proceso software Personal

El Proceso Personal de Software es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro “An introduction to the Personal Software Process” se dirige ahora a ingenieros principiantes.
El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administración de configuraciones y Administración de requerimientos.
El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. Los siguientes son los niveles
y las KPAs que se manejan en cada uno:
Nivel 2 - Inicial:
- Seguimiento y control de proyectos
- Planeación de los proyectos
Nivel 3 - Repetible:
- Revisión entre colegas.
- Ingeniería del producto de software.
- Manejo integrado del software.
- Definición del proceso de software.
- Foco del proceso de software.
Nivel 4 - Definido:
- Control de calidad.
- Administración cuantitativa del proyecto.
Nivel 5 - Controlado:
- Administración de los cambios del proceso.
- Administración del cambio tecnológico.
- Prevención de defectos.
El PSP tiene varias fases:
PSP0: Proceso Base.
PSP0.1: Complementos al proceso base.
PSP1 y PSP1.1: Planeación personal.
PSP2 y PSP2.1: Control de calidad personal.
PSP3: Programas más grandes.
I T C G
Atendiendo a la premisa de que existe una fuerte relación entre las habilidades de los ingenieros de software y la calidad de los productos que desarrollan, las actividades establecidas en PSP están orientadas al conocimiento, administración y mejora de sus habilidades al construir programas.

 En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts.

7. Diccionario de datos


Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.
Metadatos: son datos que describen otros datos



6. Ingeniería de software


Es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad.
Esta ingeniería trata con áreas muy diversas de la  informática y de las ciencias de la computación,  tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet.
Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:
         Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
         Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software (Bohem, 1976).
         Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
         Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).
Arquitectura
La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software.