martes, 17 de mayo de 2011

Requisitos -

  1. Ingeniería delSoftware
    Requerimientos del Software.
    Lic. Maria Segovia

  1. ¿Qué son los requisitos o requerimientos?
    Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .
    • Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.
    • Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.
    • Una representación documentada de una condición o necesidad.
  2. Que se considera como un requisito
    • Una facilidad a nivel usuario Ej.: ‘el procesador de palabras debe incluir un verificador de ortografía y un comando de corrección’
    • Una propiedad muy general del sistemaEj.: ‘el sistema debe asegurar que la información personal nunca se haga disponible sin autorización’
    • Una restricción específica del sistema Ej.: ‘el sensor debe ser activado 10 veces por segundo’
    • Una restricción para el desarrollo del sistema Ej.: ‘el sistema debe ser desarrollado usando Ada’
    • Cómo llevar a cabo algún cálculo Ej.: ‘la nota final debe ser calculada sumando las notas del examen, proyecto y cursada del estudiante basado en la siguiente fórmula nota final = nota_exam + 2 * nota_proy + 2/3 * nota_cursada’
  3. Que se considera como un requisito
    • Propiedades del dominio: “Cosas” en el dominio de aplicación que son verdaderas independientemente que se construya o no el sistema de software
    • Requisitos: “Cosas” en el dominio de aplicación que se desean sean verdaderas mediante la construcción del sistema de software
    • Especificación: descripción de comportamiento (y datos) que el programa tiene que tener para cumplir los requisitos
    • Sólo puede ser descrito en términos de los fenómenos compartidos por la máquina y el dominio de aplicación
  4. Actores relacionados con el sistema
    Llamados Stakeholder. Entidad que será afectada por el sistema y que tienen una influencia directa o indirecta sobre los requisitos del sistema.
    • Usuarios finales del sistema
    • Gerentes involucrados en los procesos organizacionales influenciados o que influencian al sistema
    • Ingenieros responsables por el desarrollo y mantenimiento del sistema,
    • Clientes de la organización
    • Cuerpos externos tales como autoridades reguladoras o de certificación.
  5. Levantamiento de requisitos
    Definición de requisitos
    • Expresa en lenguaje natural o con diagramas los servicios y restricciones operacionales del sistema. Se genera con la información proporcionada por el cliente.

Especificación de Requisitos

    • Documento estructurado que describe con detalle los servicios del sistema. A veces llamado especificación funcional. Escrito como contrato con el cliente.

Especificación de software

    • Escrito para los diseñadores. Sirve de base para el diseño y desarrollo del sistema.
  1. Documento de requisitos
    El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software.
    Nombres:
    Especificación funcional,
    Definición de requisitos,
    Especificación de los requisitos de software
  2. Documento de requisitos
    El documento describe:
    • Los servicios y funciones que el sistema debería proveer.
    • Las restricciones bajo las cuales el sistema debe operar
    • Las propiedades generales del sistema, es decir, restricciones sobre las propiedades emergentes del sistema
    • Definiciones de otros sistemas con los cuales el sistema se debe integrar.
    • Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos.
    • Restricciones sobre el proceso usado para desarrollar el sistema
    • glosario
  3. Usuarios del documento de requisitos
    Especifican los requisitos y los leen para chequear que atienden sus necesidades. Especifican cambios en los requisitos.
    Clientes del sistema
    Usan los documentos de requisitos para planificar una propuesta (oferta) para el sistema y planificar el proceso de desarrollo.
    Gerentes
    Usan los requisitos para entender qué sistema tiene que ser desarrollado.
    Ingenieros de sistemas
    Usan los requisitos para desarrollar pruebas de validación para el sistema.
    Ingenieros de prueba de sistemas
    Usan los requisitos para ayudar a entender los sistemas y las relaciones entre sus partes.
    Ing. de mantenimiento de sistemas
  4. Modelo IEEE/ANSI 830-1998
    Introducción
    • 1.1.Propósito del documento de requisitos
    • 1.2.Alcance del proyecto
    • 1.3.Definiciones, acrónimos y abreviaturas
    • 1.4.Resumen del resto del documento

DescripciónGeneral

    • 2.1.Perspectiva del producto
    • 2.2.Funciones del producto
    • 2.3.Características de los usuarios
    • 2.4.Limitaciones generales
    • 2.5.Suposiciones y dependencias

Requisitos Específicos

    • 3.1.Requisitos funcionales, no funcionales

Apéndices
Índice

  1. Ingeniería de requisitos (RE)
    • RE trata la identificación del propósito de un sistema de software y el contexto en el cual será usado.
    • RE actúa como un puente entre las necesidades del mundo real de los clientes y otros actores afectados
    • Trata sobre los objetivos del mundo real para los sistemas de software, servicios provistos y restricciones.
    • Trata sobre el comportamiento del sistema y su evolución a través del tiempo.
  2. Importancia de la RE en el desarrollo de Software
    Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta repararlo.
    Muchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron. Muchos podrían detectarse tempranamente
    Se cometen muchos errores de requisitos
    Impacto de los errores en la etapa de requisitos
    El software resultante puede no satisfacer a los usuarios.
    Las interpretaciones múltiples de los requisitos pueden causar desacuerdos entre clientes y desarrolladores.
    Es imposible que a través del testeo el software satisfaga sus requisitos.
    Puede gastarse tiempo y dinero construyendo el sistema erróneo.
  3. Actividades del proceso de la RE
  4. Técnica JAD (JointAplicationDesigner)
    • Permite a los usuarios, diseñar sistemas en forma conjunta, en sesiones grupales.
    • Gibson y Jackson afirman que los resultados aumentan de un 20% a un 60%.
    • Promueve la cooperación, el entendimiento y el trabajo grupal entre distintos grupos de usuarios.
  5. Roles del JAD
    • Líder de la sesión.
    • Representante de los usuarios.
    • Especialista.
    • Analista.
    • Representante de SS.
    • Patrocinador (sponsor) ejecutivo o dueño del sistema.
  6. Líder de Sesión
    • Facilitador de JAD.
    • Dirige el proceso.
    • Facilita el debate y la preparación de documentos.
    • Trata con el sponsor de JAD para acordar quién debe asistir las reuniones.
    • Acordar la agenda con los participantes.
  7. Plan JAD
    • Dura entre uno y cinco días.
    • El líder de la sesión guía a los participantes a lo largo de ocho tareas predefinidas. Ellas son:

Orientación.
Definición de requerimientos de alto nivel .
Límites y alcances del sistema .
Identificar y estimar tiempos de los Diseños JAD.
Identificar los participantes de los Diseños JAD.
Programar días y horarios para los Diseños JAD.
Acordar los puntos y consideraciones de la documentación a generar del Plan JAD.
Concluir la sesión.

  1. Diseño JAD. Sesión de Diseño
    • Dura aproximadamente entre tres y diez días.
    • El líder de la sesión guía a los participantes a lo largo de las siguientes tareas:

Orientación.
Revisión y refinación de los requerimientos y alcance del Plan JAD.
Desarrollar diagrama de flujo del trabajo.
Desarrollar descripción del flujo de trabajo.
Identificar funciones y grupos de datos del sistema.
Especificar los requerimientos de procesamiento.
Acordar los puntos y consideraciones de la documentación a generar del Diseño JAD.
Concluir la fase de sesión.

  1. Libros de Trabajo
    • Formas predefinidas para los grupos, para que sean completadas durante la sesión.
    • Formularios de participantes.
    • Formularios de resultados.
    • Formularios de estimaciones.
    • Formularios de salidas por pantalla.
    • Formularios de reportes.
    • Formularios de descripción de interfaces y de descripción de funciones.
  2. JAD y el proceso de Requerimientos
    • La articulación del concepto de producto, requerimientos, medición de resultados.
    • Análisis de problemas.
    • Estudios de factibilidad y análisis de opciones de costo-beneficio.
    • Análisis y modelado.
    • La documentación de requerimientos.
  3. JAD y la comunicación humana
    La identificación de varios puntos de vista.
    La conciliación de los puntos de vista.
    La revisión por parte del usuario de los modelos desarrollados.
    El análisis de los propios problemas del usuario y la identificación de la necesidad de cambio.
  4. Análisis de puntos de función (FPA)
    • Mide el tamaño del software desde el punto de vista del usuario. Medir la funcionalidad del producto.
    • Es independiente de la tecnología usada para el desarrollo e implementación.
    • Se aplica a partir de los documentos de requerimientos y a lo largo del ciclo de vida del software.
    • Los enfoques para estimar Puntos Función (FunctionPoints - FP) facilitan la estimación temprana de un proyecto de software (costo, esfuerzo, cronograma) cuando los requerimientos no están completamente definidos.
  5. Medición
    • Es una práctica de administración Probada en el tiempo.
    • No se puede administrar lo que no se puede medir.
    • Un 40% de proyectos fracasan por falta de administración,
    • Herramienta para determinar el tamaño del requerimiento, extrapolar la productividad y la calidad.
    • Se mide para entender y mejorar procesos.
  6. Clases de medición
    • Medición: Cuantificación directa.

Estatura de una persona.

    • Cálculo: Cuantificación indirecta.

A partir de la combinación de medidas se obtiene el valor del atributo de interés.
Ejemplo: medir la velocidad a partir de la distancia y el tiempo.

  1. Medición del Software
    • Se miden las características para saber si los requerimientos son consistentes y completos.
    • Los administradores de proyectos miden procesos y productos para determinar tiempos de entrega y costos.
    • Incluyen las siguientes actividades:

Estimación de costo y esfuerzo.
Medidas de productividad.
Recolección de datos.
Medidas de calidad y confiabilidad.
Performance.
Complejidad.
Métodos y herramientas.

  1. Beneficios de la medición
    • Entender que está ocurriendo en el desarrollo y mantenimiento para mejorar las relaciones entre actividades.
    • Control de lo que ocurre en el proyecto, para predecir lo que ocurrirá y los cambios a realizar.
    • Mejorar los procesos y productos, aumentando las revisiones del diseño se incrementa la calidad.
  2. Medición del tamaño del sistema
    Tamaño del procesamiento de información
    • Entradas
    • Salidas.
    • Otros

Requerimientos técnicos.

    • Performance.
    • Facilidad de uso.
    • otros

Tamaño del sistema desde los requerimientos del usuario

  1. Beneficios del FPA
    • Mejorará la definición de los requerimientos.
    • Comunicar requerimientos funcionales.
    • Estimar esfuerzo, agenda y costos basado en requerimientos.
    • Evaluar la factibilidad de un proyecto.
    • Administrar los cambios.
    • Mejorará el mantenimiento y soporte.
    • Medir la productividad.
    • Verificar la completitud.
  2. Resumen de Objetivos
    ¿Qué son los requerimientos o Requisitos?
    Necesidades, objetivos y actores relacionados con los requerimientos
    Importancia de la Ingeniería de Requisitos en la práctica
    Levantamiento y Recolección de Requerimientos.
    Técnicas más usadas: Método JAD y FPA

martes, 10 de mayo de 2011

Ingenieria de software.
Indice
1. Introducción
2. Objetivos de la ingeniería de software
3. Competitividad
4. Estrategias para su desarrollo
5. Método del ciclo de vida clásico
6. Método de desarrollo por análisis estructurado
7. Diccionario de datos.
8. Diagrama de estructura de datos
9. Gráfica de estructura
10. Etapas del método de prototipos
11. Coordinación y Gestión del proyecto.
12. Mediciones y estimaciones
13. Reingeniería e ingeniería inversa
1. Introducción
Este término fue introducido a finales de los 60 a raíz de la crisis del software.
Esta crisis fue el resultado de la introducción de la tercera generación del hardware.
El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y
mejoro la calidad y eficiencia en el software producido
La crisis se caracterizo por los siguientes problemas:
• Imprecisión en la planificación del proyecto y estimación de los costos.
• Baja calidad del software.
• Dificultad de mantenimiento de programas con un diseño poco estructurado, etc.
Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la
compra.
Tambien se requiere una serie de características como fiabilidad, facilidad de mantenimiento y
de uso, eficiencia, etc.
2. Objetivos de la ingeniería de software
En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los
problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la
ingeniería de software.
• mejorar la calidad de los productos de software
• aumentar la productividad y trabajo de los ingenieros del software.
• Facilitar el control del proceso de desarrollo de software.
• Suministrar a los desarrolladores las bases para construir software de alta calidad en
una forma eficiente.
• Definir una disciplina que garantice la producción y el mantenimiento de los productos
software desarrollados en el plazo fijado y dentro del costo estimado.
Objetivos de los proyectos de sistemas
Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes
razones: "Las cinco C "
Capacidad
Las actividades de la organización están influenciadas por la capacidad de ésta para procesar
transacciones con rapidez y eficiencia.
Los sistemas de información mejoran esta capacidad en tres formas.
* Aumentan la velocidad de procesamiento:
Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de
cálculos tediosos y comparaciones repetitivas.
Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento
acelerado.
*Aumento en el volumen:
La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los
procedimientos existentes. Quizá éstos resulten inadecuados para satisfacer las demandas
actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la
introducción de procesamiento computarizado, si el sistema existente es manual. Es poco
probable que únicamente el aumento de la velocidad sea la respuesta. El tiempo de
procesamiento por transacción aumenta si se considera la cantidad de actividades comerciales
de la empresa junto con su patrón de crecimiento.
* Recuperación más rápida de la información:
Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse en cuenta
donde almacenarlos y como recuperarlos cuando se los necesita.
Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rápida la
información.
Costo
* Vigilancia de los costos:
Para determinar si la compañía evoluciona en la forma esperada, de acuerdo con lo
presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y
gastos generales.
La creciente competitividad del mercado crea la necesidad de mejores métodos para seguir los
costos y relacionarlos con la productividad individual y organizacional.
* Reducción de costos:
Los diseños de sistemas ayudan a disminuir los costos, ya que toman ventaja de las
capacidades de cálculo automático y de recuperación de datos que están incluidos en
procedimientos de programas en computadora. Muchas tareas son realizadas por programas
de cómputo, lo cual deja un número muy reducido de éstas para su ejecución manual,
disminuyendo al personal.
Control
*Mayor seguridad de información:
Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para
su lectura por medio de una máquina, es una seguridad difícil de alcanzar en un medio
ambiente donde no existen computadoras.
Para aumentar la seguridad, generalmente se desarrollan sistemas de información
automatizados. El acceso a la información puede estar controlado por un complejo sistemas de
contraseñas, limitado a ciertas áreas o personal, si está bien protegido, es difícil de acceder.
*Menor margen de error: (mejora de la exactitud y la consistencia)
Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que
siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera,
consistencia y con exactitud: por otra parte se efectúan todos los pasos para cada lote de
transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefónicas,
ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no
se produzcan errores.
Comunicación
La falta de comunicación es una fuente común de dificultades que afectan tanto a cliente como
a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la
comunicación y facilitan la integración de funciones individuales.
* Interconexión: ( aumento en la comunicación)
Muchas empresas aumentan sus vías de comunicación por medio del desarrollo de redes para
este fin, dichas vías abarcan todo el país y les permiten acelerar el flujo de información dentro
de sus oficinas y otras instalaciones que no se encuentran en la misma localidad.
Una de las características más importantes de los sistemas de información para oficinas es la
transmisión electrónica de información, como por ejemplo, los mensajes y los documentos.
* Integración de áreas en las empresas:
Con frecuencia las actividades de las empresas abarcan varias áreas de la organización, la
información que surge en un área se necesita en otra área, por ejemplo.
Los sistemas de información ayudan a comunicar los detalles del diseño a los diferentes
grupos, mantienen las especificaciones esenciales en un sitio de fácil acceso y calculan
factores tales como el estrés y el nivel de costos a partir de detalles proporcionados por otros
grupos.
Competitividad
Los sistemas de información computacionales son un arma estratégica, capaz de cambiar la
forma en que la compañía compite en el mercado, en consecuencia éstos sistemas mejoran la
organización y la ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la
compañía tienen capacidades mas avanzadas para el procesamiento de información, entonces
los sistemas de información pueden convertirse en una "desventaja competitiva".
Una organización puede ganar ventaja competitiva a través de sus sistemas de información de
diferentes formas.
* Asegurar clientes:
Como los clientes son los más importante para una organización, los directivos buscan
diferentes formas para conseguir nuevos clientes y mantener los que tienen. Para eso las
empresas proporcionan:
1- Mejores precios
2- Servicios exclusivos.
3- Productos diferentes.
La ventaja en precios se observa continuamente en la actividad comercial (sí el producto es
exclusivo o distinto entonces tener el liderazgo en precios bajos quizás no sea el objetivo a
alcanzar).
La estrategia eficaz de precios a menudo se alcanza al desarrollar sistemas de información por
razones tales como reducción de costos y ganancia en la exactitud.
Generalmente cuando una compañía puede ofrecer servicios exclusivos y atraer clientes, es
posible que los competidores no sean capaces de atraer a los clientes de la compañía.
* Dejar fuera a los competidores:
Pasar sobre los competidores puede ser un inconveniente si ellos se encuentran la forma para
duplicar los logros de la compañía, los sistemas de información pueden ser la base para dejar
fuera del mercado a la competencia ya sea el disuadir sus intentos por ingresar al mercado o
creándoles obstáculo para su entrada.
*Mejores acuerdos con los proveedores:
En los negocios, los proveedores también tienen importancia estratégica. Una manera de
utilizar los sistemas de información para favorecer arreglos con los proveedores es ofreciendo
un mejor precio. Disminuyendo los costos.
*Formar bases para nuevos productos
Los sistemas de información también forman la base de muchos productos y servicios nuevos.
Los servicios de base de datos experimentan un crecimiento común en todas las industrias.
Productos que van desde programas personales hasta planes de construcción pueden hacerse
a la medida del cliente gracias al procesamiento de información.
Una cosa es clara, es necesario que los sistemas entren en operación y que trabajen de
manera confiable.
4. Estrategias para su desarrollo
Los sistemas de información basados en computadoras sirven para diversas finalidades que
van desde el procesamiento de las transacciones de una empresa hasta proveer de la
información necesaria para decidir sobre asuntos que se presentan con frecuencia.
En algunos casos los factores que deben considerarse en un proyecto de sistema de
información, como el aspecto más apropiado de la computadora o la tecnología de
comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre los empleados de la
empresa y las características específicas que el sistema debe tener se pueden determinar de
manera secuencial. Todas estas situaciones están determinadas por tres métodos básicos:
5. Método del ciclo de vida clásico
El método del ciclo de vida para desarrollo de sistemas es el conjunto de actividades que los
analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de
información.
El método del ciclo de vida para el desarrollo de sistemas consta de las siguientes actividades:
1) Investigación preliminar
La solicitud para recibir ayuda de un sistema de información pueden originarse por una
persona, cuando se formula la solicitud comienza la primera actividad del sistema. Esta
actividad tiene tres partes:
*Aclaración de la solicitud
Antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe
examinarse para determinar con precisión lo que el solicitante desea; ya que muchas
solicitudes que provienen de empleados y usuarios no están formuladas de manera clara.
*Estudio de factibilidad
En la investigación preliminar un punto importante es determinar que el sistema solicitado sea
factible. Existen tres aspectos relacionados con el estudio de factibilidad, que son realizados
por los general por analistas capacitados o directivos:
-Factibilidad técnica.
Estudia si el trabajo para el proyecto, puede desarrollarse con el software y el personal
existente, y si en caso de necesitar nueva tecnología, cuales son las posibilidades de
desarrollarla (no solo el hardware).
-Factibilidad económica.
Investiga si los costos se justifican con los beneficios que se obtienen, y si se ha invertido
demasiado, como para no crear el sistema si se cree necesario.
-Factibilidad operacional:
Investiga si será utilizado el sistema, si los usuarios usaran el sistema, como para obtener
beneficios.
* Aprobación de la solicitud
Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo es posible
atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben
incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente,
aunque lo común es que los miembros del equipo de sistemas estén ocupados en otros
proyectos. Cuando esto ocurre, la administración decide que proyectos son los más
importantes y el orden en que se llevarán acabo.
Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para
terminarlo y las necesidades de personal
2) Determinación de los requisitos del sistema.
Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de
una empresa para dar respuesta a ciertas preguntas claves.
Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles
relacionados con los procesos de la empresa. Cuando no es posible entrevistar, en forma
personal a los miembros de grupos grandes dentro de la organización, se emplean
cuestionarios para obtener esta información.
Las investigaciones detalladas requieren el estudio de manuales y reportes, la observación en
condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas
y documentos con el fin de comprender el proceso en su totalidad.
Reunidos los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de
identificar las características que debe tener el nuevo sistema.
3)Diseño del sistema.(diseño lógico)
El diseño de un sistema de información responde a la forma en la que el sistema cumplirá con
los requerimientos identificados durante la fase de análisis.
Es común que los diseñadores hagan un esquema del formato o pantalla que esperan que
aparezca cuando el sistema esta terminado, se realiza en papel o en la pantalla de una
terminal utilizando algunas de las herramientas automatizadas disponibles para el desarrollo de
sistemas.
También se indican los datos de entrada, los que serán calculados y los que deben ser
almacenados. Los diseñadores seleccionan las estructuras de archivo y los dispositivos de
almacenamiento. Los procedimientos que se escriben indican cómo procesar los datos y
producir salidas.
Los documentos que contienen las especificaciones de diseño representan a éste mediante
diagramas, tablas y símbolos especiales.
La información detallada del diseño se proporciona al equipo de programación para comenzar
la fase de desarrollo de software.
Los diseñadores son responsables de dar a los programadores las especificaciones de
software completas y claramente delineadas.
4) Desarrollo de software (diseño físico).
Los encargados de desarrollar software pueden instalar software comprado a terceros o
escribir programas diseñados a la medida del solicitante. La elección depende del costo de
cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los
programadores.
Los programadores son responsables de la documentación de los programas y de explicar su
codificación, esta documentación es esencial para probar el programa y hacer el
mantenimiento.
5) Prueba de sistemas.
Durante esta fase, el sistema se emplea de manera experimental para asegurarse que el
software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la
forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de
datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones
se permite que varios usuarios utilicen el sistema, para que los analistas observen si tratan de
emplearlo en formas no previstas, antes de que la organización implante el sistema y dependa
de él.
En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que
escribió los programas originales; para asegurarse de que las pruebas sean completas e
imparciales y, por otra, que el software sea más confiable.
6) Implantación y evaluación.
La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios,
instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.
Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se
considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de
desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.
Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso
de constante evolución.
La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La
evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
• Evaluación operacional
Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de
respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de
utilización.
• Impacto organizacional
Identificación y medición de los beneficios para la organización en áreas como finanzas
(costos, ingresos y ganancias), eficiencia operacional e impacto competitivo.
- Opinión de los administradores
Evaluación de las actitudes de directivos y administradores dentro de la organización así como
de los usuarios finales.
• Desempeño del desarrollo
La evaluación del proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo
de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración
de proyectos.
Cuando la evaluación de sistema se conduce en forma adecuada proporciona mucha
información que puede ayudar a mejorar la efectividad de los esfuerzos cuando la evaluación
de sistemas se conduce en forma adecuada proporciona mucha información que puede ayudar
a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.
6. Método de desarrollo por análisis estructurado
Muchos especialistas en sistemas de información reconocen la dificultad de comprender de
manera completa sistemas grandes y complejos. El método de desarrollo del análisis
estructurado tiene como finalidad superar esta dificultad por medio de:
1. la división del sistema en componentes y
2. la construcción de un modelo del sistema.
El método incorpora elementos tanto de análisis como de diseño
El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la
aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema)
separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento,
etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde
será utilizado.
El análisis estructurado es un método para el análisis de sistemas manuales o automatizados,
que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar
modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o
proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para
asegurar que no se omite ningún detalle pertinente.
Componentes
Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un
sistema junto con las relaciones entre estos componentes.
Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o
automatizado.
Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y
lenguajes que permiten a los analistas describir actividades importantes que forman parte del
sistema.
Reglas: estándares para describir y documentar el sistema en forma correcta y completa.
Diseño Estructurado.
El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado
que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.
El objetivo del Diseño Estructurado es programas formados por módulos independientes unos
de otros desde el punto de vista funcional.
El Diseño Estructurado es una técnica específica para el diseño de programas.
La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de
naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos.
Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de
flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes
junto con los datos que un módulo pasa a otro cuando interacciona con él.
Análisis de flujo de datos.
Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro
del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los
diccionarios de datos.
Herramientas
Las herramientas muestran todas las características esenciales del sistema y la forma en que
se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma
verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con
sus acciones.
Diagrama de flujo de datos
Es el modelo del sistema. Es la herramienta mas importante y la base sobre la cual se
desarrollan otros componentes.
El modelo original se detalla en diagramas de bajo nivel que muestran características
adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos
cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes
detalles para que el analista comprenda la parte del sistema que se encuentra bajo
investigación.
El diagrama físico de datos da un panorama del sistema en uso, dependiente de la
implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de
personas, nombres o números de formato y documento, nombres de departamentos, archivos
maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de
procedimientos.
El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es
independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin
considerar los dispositivos específicos y la localización de los almacenes de datos o personas
en el sistema. Sin indicarse las características físicas.
Notaciones: son cuatro símbolos, que fueron desarrollados y promovidos la mismo tiempo por
dos organizaciones: Yourdon y Gane y Sarson.
Flujo de datos: son movimientos de datos en una determinada dirección, desde un origen hasta
un destino. Es un paquete de datos.
Yourdon Gane y Sarson
Proceso: son personas, procedimientos o dispositivos que utilizan o producen datos. No
identifica el componente físico
Fuente o destino de los datos: pueden ser personas, programas, organizaciones u otras
entidades que interactúan con el sistema pero que se encuentre fuera.
Almacenamiento de datos: es un lugar donde se guardan los datos. El almacenamiento de
datos puede representar dispositivos tanto computarizados como no computarizados.
Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre
descriptivo. Los nombres de los procesos reciben un numero para poder identificarlos, este
numero tiene un valor adicional cuando se estudian los componentes que integran un proceso
especifico
7. Diccionario de datos.
Contiene las características lógicas de los sitios donde se almacenan los datos del sistema,
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.
Razones para su utilización:
1. Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades
de datos, aun en los sistemas mas chicos hay gran cantidad de datos.
Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles. Por
eso se registra la información, ya sea sobre hoja de papel o usando procesadores de
texto. Los analistas mas organizados usan el diccionario de datos automatizados
diseñados específicamente para el análisis y diseño de software.
2. Para asignarle un solo significado a cada uno de los elementos y actividades del
sistema.
Los diccionarios de datos proporcionan asistencia para asegurar significados comunes
para los elementos y actividades del sistema y registrando detalles adicionales
relacionadas con el flujo de datos en el sistema, de tal manera que todo pueda
localizarse con rapidez.
3. Para documentar las características del sistema, incluyendo partes o componentes así
como los aspectos que los distinguen. Tambien es necesario saber bajo que
circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren. Produciendo
una comprensión mas completa. Una vez que las características están articuladas y
registradas, todos los participantes en el proyecto tendrán una fuente común de
información con respecto al sistema.
4. Para facilitar el análisis de los detalles con la finalidad de evaluar las características y
determinar donde efectuar cambios en el sistema.
Determina si son necesarias nuevas características o si están en orden los cambios de
cualquier tipo.
Se abordan las características:
* Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo
mientras se emplea el sistema.
* Preguntas: solicitudes para la recuperación o procesamiento de información para
generar una respuesta especifica.
* Archivos y bases de datos: detalles de las transacciones y registros maestros que son
de interés para la organización.
* Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar
transacciones y datos
5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un
informe. Aun en los manuales, se revelan errores.
Contenido de un registro del diccionario
El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los
elementos datos y estructura de datos.
Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si mismos
no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos.
Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que describen
los datos utilizados o producidos por el sistema.
Cada uno esta identificado con:
Un nombre: para distinguir un dato de otro.
Descripción: indica lo que representa en el sistema.
Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso este dato.
Longitud: porque es de importancia de saber la cantidad de espacio necesario para cada dato.
Valores de los datos: porque en algunos procesos solo son permitidos valores muy específicos
para los datos. Si los valores de los datos están restringidos a un intervalo especifico, esto
debe estar en la entrada del diccionario.
Estructura de datos: es un grupo de datos que están relacionados con otros y que en conjunto
describen un componente del sistema.
Descripción:
Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes
combinaciones ya sea individualmente o en conjunción con alguna otra.
Relación secuencial: define los componentes que siempre se incluyen en una estructura de
datos.
Relación de selección: (uno u otro), define las alternativas para datos o estructuras de datos
incluidos en una estructura de datos.
Relación de iteración: (repetitiva), define la repetición de un componente.
Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteración.
Notación
Los analistas usan símbolos especiales con la finalidad de no usar demasiada cantidad de
texto para la descripción de las relaciones entre datos y mostrar con claridad las relaciones
estructurales. En algunos casos se emplean términos diferentes para describir la misma
entidad (alias) estos se representan con un signo igual (=) que vincula los datos.
8. Diagrama de estructura de datos
Es una descripción de la relación entre entidades (personas, lugares, eventos y objetos) de un
sistema y el conjunto de información relacionado con la entidad.
Finalidades:
1. Verificar los requerimientos de información.
2. Describir los datos asociados con las entidades.
3. Mostrar la relación entre entidades.
4. Comunicar los requerimientos de datos a un diseñador de archivos o administrador de
la base de datos.
Notación
Una común se usa al preparar los diagramas de estructura de datos. Las entidades se
representan mediante rectángulos, con el nombre de la entidad en la parte de arriba y una lista
de atributos que describan la entidad. Cada entidad se puede identificar mediante un atributo
llave.
Uso en el diseño de archivo.
El uso de los diagramas de estructura de datos requiere que el analista haga preguntas
importantes acerca de la entidad a describir. La llave de registro, identifica de una forma única
a la cuenta. Los demás detalles son los atributos.
Además de los componentes básicos existen dos elementos adicionales esenciales:
* Apuntadores atributos: enlazan dos entidades mediante la información común, usualmente un
atributo llave en uno y un atributo (no llave) en el otro.
* Apuntadores lógicos: identifican las relaciones entre las entidades, sirven para obtener
acceso inmediato a la información en una entidad, definiendo un atributo llave en otra entidad.
Usualmente se indican en la parte inferior del diagrama, son los enlaces con las demás
entidades incluidas en el diagrama.
Compartir datos entre las aplicaciones.
Cada sistema se puede desarrollar por separado, guardando los datos de los estados de
cuenta aparte de los datos del inventario. Al desarrollar mas sistemas y crecer su utilidad, muy
seguido existe la necesidad de integrar los sistemas para permitir que la información sea
compartida por mas de un sistema.
Redundancia e integridad:
Si cada sistema se desarrolla en forma independiente, la información puede ser almacenada al
menos una vez en cada sistema, éste además de requerir espacio de almacenamiento extra,
esta duplicación es llamada redundancia, para reducir la integridad de la información; cuando
se duplica información es muy probable de que los detalles no coincidan o que no todos sean
actualizados. Resultando la perdida de integridad en los datos, pudiendo ser corregido
mejorando los procedimientos.
Se puede evitar del todo disminuyendo la redundancia de datos en los archivos.
9. Gráfica de estructura
Muestra con símbolos la relación entre los módulos de procesamiento y el software de la
computadora. Describen la jerarquía de los módulos componentes y los datos que serán
transmitidos entre ellos. Incluye el análisis de las transformaciones entrada-salida y el análisis
de transacción.
Las flechas con una circunferencia indican datos, mientras que las que tienen un circulo
representa información de control de programa, tales como notas o condiciones de error.
Diagrama de contexto
Se pueden usar diagramas de flujos de datos para representar el sistema a cualquier nivel de
abstracción. El diagrama de flujo de dato de nivel 0 se llama diagrama de contexto y en él el
sistema esta representado por un solo proceso, que identifica cual es la función principal del
sistema, mostrando además, los flujos de información que lo relacionan con otros sistemas: las
entidades externas. El diagrama de contexto tiene una gran importancia puesto que resume el
requisito principal del sistema de recibir ciertas entradas, procesarlas de acuerdo con
determinada función y generar ciertas salidas. A partir del diagrama de contexto se puede ir
construyendo nuevos diagramas que vayan definiendo con mayor nivel de detalle lo flujos de
datos y procesos de transformación que ocurren en el sistema, de forma que al final obtenemos
una jerarquía de diagramas.
Método del desarrollo por prototipos
Los sistemas pueden desarrollarse con métodos y lenguajes de programación convencionales,
aunque no tengan todas las características y toques finales de un sistema terminado. Quizás
los informes no tengan encabezados, logos, etc., falten controles de entradas y procesamiento.
Lo importante es el ensayo, y hallar los requerimientos.
Los generadores de aplicaciones, son programas que sirven para hacer otros programas, son
un apoyo en la construcción de prototipos, permitiendo definir la estructura visual de las
pantallas, los registros de entrada y el formato de los informes.
En algunos casos donde el sistema no será utilizado frecuentemente, puede convertirse el
prototipo en el sistema terminado, o bien, cuando no son muchos los beneficios que se
obtienen.
Razones para desarrollar prototipos de sistemas
Los requerimientos de información no siempre están bien definidos, pueden ser demasiados
vagos aún al formular el diseño. En otros casos, es probable que una investigación de sistemas
bien llevada, de como resultado un conjunto muy amplio de requerimientos de sistemas, pero
construir un sistema que satisfaga a todos ellos quizás necesite del desarrollo de nueva
tecnología.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de diseñar e
implantar sistemas no tienen información ni experiencia, o también donde existen situaciones
de riesgo y costos elevados, y aquellas donde el diseño propuesto es novedoso y aún no ha
sido probada.
La información obtenida con su uso se aplica en un nuevo diseño que se emplea, otra vez,
como prototipo y que revela más información valiosa sobre diseño. El proceso se repite las
veces que sea necesario para revelar los requerimientos esenciales del diseño.
Maquetas
Cuando se comienza el desarrollo, tiene por objetivo presentar a los usuarios y/o clientes la
apariencia del sistema final. Los usuarios pueden manifestar su opinión.
Ambos métodos son muy útiles para establecer la viabilidad del proyecto y definir acuerdos
sobre los objetivos y resultados esperados.
10. Etapas del método de prototipos
1- Identificación de requerimientos conocido.
La determinación de los requerimientos de una aplicación es tan importante para el método de
desarrollo de prototipo como lo es para los métodos del ciclo clásico de desarrollo de sistemas
o análisis estructurado (aunque las tácticas son diferentes). Por consiguiente, antes de crear el
prototipo, los analistas y usuarios deben trabajar juntos para identificar los requerimientos
conocidos que tiene que satisfacerse. Para hacerlo determinan los fines para lo que servirá el
sistema y el alcance de sus capacidades.
2- Desarrollo de un modelo de trabajo
Es útil comenzar el proceso de construcción del prototipo con el desarrollo de un plan general
que permita a las personas conocer lo que se espera de ellas y del proceso de desarrollo. Es
difícil, y en ocasiones imposibles, fijar una fecha tentativa de terminación. La experiencia con el
sistema es la que determina eventualmente cuando en sistema esta terminado.
Para comenzar la primera iteración, usuarios y analistas identifican de manera conjunta los
datos que son necesarios para el sistema y especifican la salida que debe producir la
aplicación.
Las decisiones de diseño necesarias para desarrollar la salida del sistema cambian muy poco
en relación con las tomadas en otros métodos de desarrollo. Sin embargo, con un prototipo, se
espera que las especificaciones iniciales estén incompletas.
En el desarrollo de un prototipo se preparan los siguientes componentes:
*El lenguaje para el diálogo o conversación entre el usuario y el sistema
*Pantallas y formato para la entrada de datos
*módulos esenciales de procesamiento
*Salida del sistema
Al construir el prototipo se deben seguir los estándares para datos que emplea la organización.
En esta etapa es más importante la rapidez con que se construye el prototipo que la eficiencia
de operación. Es por esto que el analista no intenta optimizar la velocidad de operación del
sistema
Durante la evaluación los analistas de sistemas desean capturar 3)El prototipo y el usuario
Es responsabilidad del usuario trabajar con prototipo y evaluar su característica y operación. La
experiencia con el sistema bajo condiciones permite obtener la familiaridad indispensable para
determinar los cambios o mejoras que sean necesarios así como la eliminación de
características inadecuadas o innecesarias.
4)Revisión del prototipo
información sobre los que les gusta y los que les desagrada a los usuarios. La información
obtenida tendrá influencia sobre las características de la siguiente versión de la aplicación.
Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo. El analista
es el responsable de realizar las modificaciones.
5) Repetición del proceso las veces que sea necesario.
El proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha
evolucionado lo suficiente como para incluir todas las características necesarias o cuando ya
es evidente que no se obtendrá mayor beneficio.
6) El abandono o dejarlo como esta:
Cuando se verifica de que no es posible desarrollar el sistema para satisfacer los objetivos
deseados, ya sea por la tecnología existente o por el factor economico.
11. Coordinación y Gestión del proyecto.
La gestión del proyecto presupone establecer condiciones para el desarrollo del mismo.
Involucra actividades de: planificación, estimación de recursos, seguimiento y control y
evaluación del proyecto.
• La planificación de proyectos se define como la predicción de la duración de las
actividades y tareas a nivel individual.
• La estimación se define como la predicción de personal, esfuerzo y costo que se
requerirá para terminar todas las actividades y productos conocidos asociados con el proyecto.
El tamaño del producto a desarrollar es una de las primeras tareas en la gestión del proyecto.
El tamaño se define como la cantidad de código fuente, especificaciones, casos de prueba,
documentación del usuario y otros productos tangibles que son salida del proyecto, éste se
basa principalmente en la experiencia de proyecto anteriores.
• El seguimiento de proyectos es la recolección de datos y su acumulación sobre
recursos consumidos, costos generados asociados con un proyecto. La medición en los
proyectos de desarrollo de software es una actividad fundamental para la mejora de la
productividad, el costo y la calidad del producto final.
Proceso de Iniciación del Proyecto.
Abarca aquellas actividades de creación de la estructura del proyecto. Durante este ciclo se
define el ciclo de vida del software para este proyecto y se establecen en los planes para su
gestión. Se estiman y asignan los recursos necesarios a fin de ejecutar las distintas tareas que
demanda el proyecto. Se identifican y seleccionan estándares, metodologías y herramientas
para la gestión y ejecución del mismo y, por último, se prepara y establece un plan para su
implementación adecuada y oportuna. El plan de Gestión del Proyecto Software que conducirá
el desarrollo se produce como culminación de este proceso.
12. Mediciones y estimaciones
El software al ser intangible, no tener peso, ni volumen, ni superficie, etc. se mide a través de
diversos aspectos clave en el desarrollo. La medición determina cuales son los aspectos y
proporcionan métodos para medirlos.
La medición y estimación atacan los tres problemas claves de la ingeniería del software:
1. Estimar costos y recursos en un proyecto software
2. Garantizar la calidad del producto final
3. Mejorar la productividad del ingeniero de software durante el desarrollo.
Teniendo en cuenta estos objetivos, las métricas se centran en cuatro aspectos:
Para estimar los recursos es necesario tener en cuenta una serie de factores de riesgo que
influyen sustancialmente en la precisión de las estimaciones de los recursos humanos
necesarios para la realización del proyecto. Los mas importantes son:
*Complejidad de la tarea.
*Modificaciones permitidas a lo largo del desarrollo
*Experiencia previa de los desarrolladores
*Duración fijada del proyecto.
*Estructuración del problema y de las tareas.
*Disponibilidad de datos e información suministrada por el usuario.
*Disponibilidad y facilidad de comunicación con el usuario.
Además de las fases estándar del desarrollo, hay que tener en cuenta la coordinación y
seguimiento del proyecto que suponen una importante carga de trabajo y que son olvidadas
durante la planificación o no se le dedica mucho.
El costo global se compone de las partidas de viajes, hardware (nuevo o actualización),
software (en caso de comprar algún paquete para el desarrollo), gastos comunes, y personal
que es el mas influyente, ya que el costo de un proyecto es directamente proporcional a los
recursos humanos.
El proceso engloba todas las actividades y fases que se llevan a cabo durante la realización del
proyecto. Se persigue determinar si en cada fase los resultados producidos se corresponden
con los esperados y en establecer un control sobre los recursos estimados para cada una de
las fases.
El producto incluye cualquier documento o software desarrollado que se genere durante el
proceso completo. En las medidas de productos software existen medidas directas (costo del
proyecto, esfuerzo empleado, líneas de código implementadas, etc.) y medidas indirectas
( funcionalidad, fiabilidad, eficiencia, facilidad de mantenimiento, etc.).
Herramientas para el desarrollo de sistemas
Las herramientas son cualquier dispositivo que, empleándose adecuadamente, mejora el
desempeño del desarrollo de sistemas de información.
Se agrupan en las tres siguientes herramientas automatizadas:
Herramientas de tipo Front-end
Automatizan las primeras actividades del proceso de desarrollo de sistemas.
Esta herramienta proporciona soporte para el desarrollo de modelos gráficos de sistemas y
procesos
Los diagramas de flujo son representativos de este tipo de herramientas.
Herramientas para análisis
Éstas herramientas ayudan a los especialistas en sistemas a documentar un sistema existente,
ya sea manual o automatizado. También sirve para determinar los requerimientos de una
nueva aplicación. Incluye:
- Herramientas para recolección de datos: capturan detalles que describen sistemas y
procedimientos en uso. Documentan procesos y actividades de decisión, se utilizan para
apoyar la tarea de identificar requerimientos.
- Herramientas para diagramación: crean representaciones gráficas de sistemas y actividades.
Apoyan el dibujo y revisión de diagramas de flujos de datos e iconos asociados con el análisis
estructurado. Incluyen programas para representación en diagramas de flujo.
- Herramientas para el diccionario: registran y mantienen descripciones de los elementos del
sistema, como grupo de datos, procesos, alimentos de datos, etc. Frecuentemente
proporcionan la capacidad de examinar las descripciones del sistema, para decidir si son
incompletas o inconsistentes.
Herramientas para diseño
Apoyan el proceso de formular las características que el sistema debe tener para satisfacer los
requerimientos deseados durante las actividades de análisis. Incluye:
- Herramienta de especificación: apoyan el proceso de formular las características, como por
ejemplo deben tener una aplicación como entradas, salidas, procesamientos específicos de
control.
- Herramienta para presentación: se utilizan para describir la posición de datos, mensajes, y
encabezados sobre las pantallas de las terminales, informes y otros medios de entradas y
salidas.
Los analistas utilizan las herramientas para el diseño de sistemas desde el inicio de la era de
las computadoras. Ahora a las herramientas se le están dando un nuevo significado en el
diseño de software.
Herramientas de tipo back-end
Su finalidad es ayudar al analista a formular la lógica del programa, los algoritmos de
procesamiento y la descripción física de datos.
Tambien ayudan a la intersección con los dispositivos (para entrada y salida). Estas actividades
convierten los diseños lógicos del software en un código de programación; este es que da
existencia a la aplicación.
Herramientas para el desarrollo
Ayudan al analista a trasladar los diseños en aplicaciones funcionales. Incluye:
- Herramientas para ingeniería Software: apoyan el proceso de formular diseños de software,
incluyendo procesamientos y controles.
- Generadores de códigos: producen el código fuente y las aplicaciones a partir de
especificaciones funcionales bien articuladas
- Herramientas para pruebas: apoyan la fase evaluación de un sistema. Incluyen facilidades
para examinar la correcta operación del sistema.
Herramientas integrales
Proporcionan un ambiente que automatiza tareas claves a lo largo del proceso de desarrollo.
Estas herramientas facilitan el diseño, administración y mantenimiento del código. Brinda un
ambiente eficiente para crear, almacenar, manipular y documentar sistemas.
13. Reingeniería e ingeniería inversa
Los conceptos de reingeniería e ingeniería inversa están ligados al desarrollo de software a
gran escala, donde una mejora en proceso de este desarrollo supone un aumento en la
competitividad de la empresa.
Aunque hay que tener en cuenta que esta mejora es, en general a largo plazo (normalmente de
uno a dos años) ambas actividades, están orientadas a automatizar el mantenimiento de
aplicaciones. Esta es una tarea que consume gran cantidad de recursos, por lo que cualquier
reducción en el tiempo y recursos empleados en ella supone una importante mejora en la
productividad del proceso. Este es el principal objetivo de la reingeniería. Se trata, de analizar
el código o el diseño actual y modificarlo con la ayuda de herramientas automáticas para
traducirlos a códigos mas estructurados, y más eficientes.
Dentro de la reingeniería, el proceso de pasar del código a una descripción de mas alto nivel es
lo que se denomina:
Ingeniería inversa.
La reingeniería e ingeniería inversa prolongan la vida del software.
Dado que es una labor estratégica, es conveniente conocer cuando conviene realizar la tarea
de reingeniería para una aplicación y cuándo es más rentable sustituirla e implementar una
nueva. Las aplicaciones para el primer paso, son aquellas en la que se produce las siguientes
situaciones:
• Fallos frecuentes, que son difíciles de localizar
• Son poco eficientes, pero realizan la función esperada
• Dificultades en la integración con otros sistemas
• Calidad pobre del software final
• Resistencia a introducir cambios
• Pocas personas capacitadas para realizar modificaciones
• Dificultades para realizar pruebas
• El mantenimiento consume muchos recursos
• Es necesario incluir nuevos requisitos, pero los básicos se mantienen.
Desarrollo de software con y para reuso
El desarrollo de software con reúso consiste en desarrollar una aplicación usando software ya
existente. Cualquier profesional lo utiliza
El desarrollo de software para reuso consiste en la construcción de un sistema con la intención
de reutilizar partes de él en futuros desarrollos. Con software a gran escala, un buen
profesional con experiencia puede desarrollarlo.
Estudios realizados determinan que la práctica de reutilización del software en un proyecto
aumenta la productividad durante el desarrollo de dicho proyecto.
Sin embargo, la reutilización del software no cubre solo el reuso de códigos, abarca todo un
amplio de posibilidades en los diferentes niveles, metodología, ciclos de vida, planes del
proyecto, especificaciones de requisitos, diseños, arquitectura software, planes de validación,
juegos de prueba y documentación.


-------------------------------------------------------------------------------------
La Ingeniería de Software, a nivel mundial, es
una disciplina relativamente nueva y todavía en
búsqueda de madurez.
• Existe una resistencia al rigor y la formalidad y
una escasa predisposición al análisis detallado
de requerimientos del usuario, el diseño con
enfoque técnico, y por ende la práctica tiende a
seguir un proceso de implementación directa a
través del ciclo de prueba-error que no resulta
adecuado para soluciones informáticas de alta
complejidad y/o gran envergadura.
-----------------------------------------------------------------

¿Qué fracasa en el desarrrollo de SW?
• Problema 1. Es muy difícil para el I. SW
aprender lo suficiente del negocio para poder ver
los requerimientos del sistema a través de los ojos
del usuario.
• Problema 2. La comunidad usuaria no conoce
aún lo suficiente de tecnología, como para saber lo
que es factible y lo que no lo es.
• Problema 3. El I. SW puede rápidamente verse
abrumado por los detalles, tanto los detalles del
negocio, como por los detalles técnicos del nuevo
sistema.
---------------------------------------------------------

¿ Qué fracasa en el desarrrollo de SW?
• Problema 4. El documento donde ubicamos los
detalles de un nuevo sistema (especificación del
sistema) constituye un contrato efectivo entre el
departamento de usuario y el grupo de desarrollo.
Este documento no es efectivo para la
negociación, por lo tanto recién una vez
implantado el sistema tienen algo para entender,
y podrán reaccionar en ese momento, y será tarde.
• Problema 5. Las especificaciones técnicas para los
programadores y diseñadores limitan la libertad
de los mismos, y normalmente son físicos
prematuramente.
---------------------------------------------------------------

Qué es la Ingeniería de Software?
• La ingeniería del software pretende utilizar
los recursos computacionales de tal
manera que se produzcan soluciones
eficientes y eficaces a los problemas
informáticos, el éxito de un proyecto
involucra elementos como la planeación,
la administración y la utilización de
metodologías de desarrollo de software.


Un software de calidad debe ser eficaz, es decir,
que debe realizar las funciones establecidas, debe ser
amigable. Un usuario debe utilizar el software porque
produce resultados confiables, realiza todas las
operaciones que se requieren, ejecuta las operaciones
en un tiempo aceptado y es fácilmente usado por el
grupo de usuarios a quien este dirigido.
• Un software de calidad debe ser eficiente, es decir
el costo de su desarrollo tomando todos los recursos y el
costo de su operación debe ser tal que las
organizaciones involucradas en su desarrollo y uso
obtengan el máximo beneficio o por lo menos un
beneficio aceptable en un período de tiempo establecido.


La relación de la Ingeniería del Software
con otras áreas de la Ciencia de la
Computación.
• La relación de la Ingeniería de Software
con otras disciplinas.


Principios de la Ingeniería de
Software.
– Rigor y formalidad.
– Separación de intereses.
– Modularidad.
– Abstracción.
– Anticipación al cambio.
– Generalidad.
– Incrementalidad.


Software: su naturaleza y sus
cualidades
– Se define el término Software como el conjunto
de partes que interactúan entre si para alcanzar
un objetivo, partes hechas por el hombre y que
interactúan o son controlados por una o más
computadoras.


Componentes de un software automático:
•HW
•Sistemas Bases
•Personas: los que operan el sistema, los que
proveen su material de entrada y consumen
su material de salida, y los que proveen
actividades de procesamiento manual en un
sistema.
•Datos: la información que el sistema recuerda
durante un periodo.
•Procedimientos: las políticas formales e
instrucciones de operación del sistema.


Papel del Ingeniero de Software.
• como Consultor: Se contrata personal externo, para
realizar innovaciones en la organización.
• como Especialista de Apoyo: Es el personal
interno/externo, que se dedica a realizar tareas de
desarrollo, mantenimiento, implementacion de
sistemas.
• como Agente de Cambio: Personal externo ó
interno, contratado para ser especialista de apoyo,
incorporando al ambiente laboral innovaciones en
cuanto a metodología, administración, etc. a través de
la implementación de sistemas de información.


Cualidades del Ingeniero de Software
1. IMAGINACIÓN
2. CAPACIDAD DE CRITICA
3. CAPACIDAD ANALITICA
4. PERSISTENCIA
5. CLARIDAD DE RACIOCINIO
6. VISION DE CONJUNTO
7. ESPIRITU DE EQUIPO
8. HUMILDAD
9. SATISFACIÓN PROFESIONAL
10.CAPACIDAD DE COMUNICACIÓN


Habilidades Especiales del Ingeniero de
Software:
• Innovador : explorar aplicaciones novedosas y mas útiles de las
computadoras así como formas nuevas de hacer negocios.
• Mediador: el medio ambiente es "distintos tipos de usuarios" , los
cuales frecuentemente están en desacuerdo entre sí.
• Lider de proyecto : debe manejar recursos humanos
(programadores).


CUÁLES SON LOS OBJETIVOS
DEL MODELADO?
• Nos ayudan a visualizar como es o queremos que
sea un sistema.
• Nos permiten especificar la estructura o el
comportamiento de un sistema.
• Nos proporcionan plantillas que nos guían en la
construcción de un sistema
• Documentan las decisiones que hemos adoptado
durante el proceso del desarrollo del software
que estamos creando.


Participantes en el Juego de Sistemas
•USUARIOS:
–Operacional
– Supervisor
– Ejecutivo
• ADMINISTRACION
• AUDITORES, PERSONAL DE CONTROL DE CALIDAD
• ANALISTAS DE SISTEMAS
•DISEÑADORES DE SISTEMAS
• PROGRAMADORES
• PERSONAL DE OPERACIONES


Los modelos de datos se construyen por
tres motivos principales:
•Para individualizar las características
importantes del proyecto dejando de lado las
menos importantes;
•Para discutir las alteraciones y correcciones
de los requisitos del usuario a más bajo costo
y con un mínimo de riesgo;
•Para confirmar que se entiende el ambiente
del usuario a tal punto de poder
documentarlo para que los proyectistas y
programadores puedan construir el proyecto

--------------------------------------------------------------