Papel Evolutivo del Software

El software tiene un papel dual: Es un producto y un vehículo mediante el cual se entrega un producto. Como producto, ofrece la potencia de cómputo presentada como hardware ó por una red accesible mediante hardware local. El software es un transformador de información.

En su papel de vehículo para la entrega de un producto, el software actúa como la base para el control de la computadora, la comunicación de información y la creación y el control de otros programas.

El software entrega el producto más importante: información.

Las características que hacen al software bien diferente de las otras cosas que realiza el ser humano:

1. El software es un elemento lógico y no físico de un sistema.
2. El software se desarrolla, no se manufactura:

Los costos del software se centran en la ingeniería.

El hardware sufre los efectos cumulativos del polvo, la humedad, los abusos, las temperaturas extremas, etc. El software no se ve afectado con estas condiciones ambientales y de tiempo.

El software se deteriora por la introducción de cambios, los cuales dan la posibilidad de que entren nuevos errores en el software, que luego son subsanados.

Es el producto que los Ing. de software construyen y después mantienen en el largo plazo.

1. Incluye las instrucciones (programas de computadora) que al ejecutarse proporcionan las características, funciones y el grado de desempeño deseado.
2. la estructura de datos que permiten que los programas manipulen información de manera adecuada y
3. los documentos, tanto físicos como virtuales, que describen la operación y el uso de los programas.

1. Software de Sistemas (colección de programas escritos para servir a otros programas).
2. Software de Aplicación (Consiste en programas independientes que resuelven una necesidad de negocios específicos).
3. Software Científico y de Ingeniería (Se caracterizaba por algoritmos “devoradores de números”).
4. Software Empotrado (Reside dentro de la memoria de sólo lectura del sistema y con él se implementan y controlan características y funciones para el usuario final y el sistema mismo).
5. Software de Línea de Productos (Diseñado para proporcionar una capacidad específica y la utilización de muchos clientes diferentes, se puede enfocar en un nicho de mercado limitado o dirigirse hacia los mercados masivos).
6. Aplicaciones basadas en la Web (Son un conjunto de archivos de hipertexto ligados que presenta información mediante texto y algunas gráficas).
7. Software de Inteligencia Artificial (Utiliza algoritmos no numéricos en la resolución de problemas complejos que es imposible abordar mediante un análisis directo).

El IEEE creó una definición de ingeniería del software:

Es la aplicación de un enfoque sistemático, disciplinado y cuantitativo al desarrollo, operación y mantenimiento del software.

Se requiere disciplina, pero también adaptabilidad y agilidad.

Sistemático: no se hace de cualquier forma. Establece pautas de cómo hacer las cosas.

Disciplinado: nos pusimos de acuerdo en la mejor manera de hacer las cosas.

Cuantitativo: si no cuantificó, no puedo mejorar. No sé como estoy haciendo las cosas. Si hago algo bien, lo repito.

Establece una base sólida para el diseño y la construcción. Sin ella, el software resultante tiene una alta probabilidad de no satisfacer las necesidades del cliente.

Etapas de la Ingeniería de Requisitos

Inicio:

• Empieza la relación. La primera impresión es la que cuenta. Formular una estrategia si comenzar con bajo perfil o pisando fuerte.
• Entender lo que el cliente quiere.
• Comprensión básica del problema.
• Identificar las personas que quieren la solución.
• Definir el ámbito y la naturaleza del problema a resolverse

Obtención:

• Identificar usuarios clave.
• Ayuda al cliente a definir sus necesidades.
• Obtener información no es sólo escuchar, sino buscar.
• Identificar si el problema es volátil o perdurará en el tiempo.
• Identificar los Objetivos

Necesidades

Utilización del sistema

Problemas de ámbito: Límite del sistema mal definido, detalles innecesarios.

Problemas de comprensión: Clientes/Usuarios no están seguros de lo que necesitan.

O puede pasar que:

El usuario no tenga buena onda;

Que tenga buena onda pero no sepa,

Que sepa, pero no sepa explicar,

Que no sepamos entender,

Que sepa, sepa explicar, pero que tenga miedo a ser echado.

Que sea un proyecto nuevo que jamás se hizo.

Problemas de volatilidad: Cambian en el transcurso del tiempo.

Se deben recopilar los requisitos organizadamente, para superar estos problemas.

Formato pregunta y respuesta solo sirve para la etapa inicial, no sirve para obtener requisitos detallados.

Un equipo de recopilación de requisitos, un equipo de participantes y desarrolladores trabajan juntos para identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos para la solución.

Elaboración:

Se refinan, modifican y expanden la información de los requisitos básicos.

Se desarrolla un modelo técnico refinado de las funciones, características y restricciones del software.

La clave es describir el problema de una forma que establezca una base firme para el diseño.

Negociación:

Usualmente clientes/usuarios piden más de lo que se puede lograr.

Conflicto de requisitos entre diferentes clientes/usuarios.

El IR debe conciliar estos conflictos mediante negociación. Negociar una solución razonable.

Identificación y análisis de los riesgos asociados a los requisitos.

Estimaciones del esfuerzo requerido para su desarrollo, impacto en el costo y tiempo de entrega.

Proceso iterativo, los requisitos se eliminan, combinan o modifican de forma que cada parte alcance cierto grado de satisfacción.

El objetivo es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (Tiempo, gente, presupuesto, etc.).

Especificación:

Documento escrito, conjunto de modelos gráficos, prototipo, etc. que especifica la solución sin ambigüedades.

Se puede utilizar una plantilla estándar.

Sirve como base para las actividades de Ing. de Software subsecuentes.

Validación:

Se evalúa la calidad del producto del trabajo de la IR.

Examina las especificaciones para asegurarse que todos los requisitos se han establecido precisamente (buscan errores de contenido o interpretación, necesidades de clarificación, información faltante, inconsistencias, conflictos entre requisitos o requisitos inalcanzables).

Revisión técnica formal (ing., Clientes, usuarios y otros).

Gestión de Requisitos:

Administrar los requisitos conforme estos se transforman en un sistema.

Conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.