1.1 CONCEPTOS BÁSICOS DE INGENIERÍA DE SOFTWARE
Software
Programas de cómputo y su documentación asociada: requerimientos, modelos de diseño y manuales de usuario El software puede ser desarrollado para un cliente en particular o para un mercado general.
El software puede ser:
Genérico: desarrollado para venderse a múltiples clientes (Excel, Word, etc.).
A la medida: desarrollado bajo demanda del cliente a un desarrollador específico.
Ingeniería de Software
Una disciplina de la Ingeniería que concierne a todos los aspectos de la producción de software Los Ingenieros de Software deben:
¿Cuál es la diferencia entre Ingeniería de Software y Ciencias Computacionales?
¿Qué es un proceso de software?
Un conjunto estructurado de actividades cuya meta es el desarrollo o evolución de un software.
Algunas actividades genéricas en todos los procesos
De software son:
¿Qué es un modelo de proceso de software?
Representación formal y simplificada de un proceso de software, presentada desde una perspectiva específica.
1.2 1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE
Hoy en día, el software tiene un papel dual. Es producto y canal de distribución de este. Como producto, ofrece la potencia de cómputo presentada como hardware de una computadora o, de manera más global por una red de computadoras accesible mediante hardware local y de acceso físico. Sin importar el lugar en que resida el software, ya sea en un celular o dentro de una computadora central, éste es un transformador de información; realiza la producción, el manejo, la adquisición, la modificación, el despliegue o la transmisión de la información que puede ser tan simple como un solo bit o tan compleja como una presentación multimedia. 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 (Sistemas Operativos), la comunicación de información (redes), y la relación y el control de otros programas (utilerías de software y ambientes).
El software entrega el producto más importante de nuestro tiempo: información. Transforma los datos personales (por ejemplo, las transacciones financieras de un individuo) de forma que los datos sean más útiles en un contexto local; maneja información alrededor del mundo (Internet) y proporciona los medios para adquirir información en todas sus formas.
El papel del software de computadora ha experimentado un cambio significativo en un periodo un poco mayor a 50 años. Las mejorías sustanciales en el desempeño del hardware, los cambios profundos en las arquitecturas de cómputo, los enormes incrementos en las capacidades de memoria y almacenamiento, y la amplia variedad de opciones de salida y entrada han propiciado el surgimiento de sistemas más elaborados y complejos basados en computadoras.
El papel del software de computadora ha experimentado un cambio significativo en un periodo un poco mayor a 50 años. Las mejorías sustanciales en el desempeño del hardware, los cambios profundos en las arquitecturas de cómputo, los enormes incrementos en las capacidades de memoria y almacenamiento, y la amplia variedad de opciones de salida y entrada han propiciado el surgimiento de sistemas más elaborados y complejos basados en computadoras.
1.3 ETAPAS DEL DESARROLLO DE SOFTWARE
En la ingeniería del software el término fases de desarrollo expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión importante de un producto pasa generalmente a través de una etapa en la que se agregan las nuevas características (etapa alfa), después una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los bugs importantes (etapa estable). Las etapas intermedias pueden también ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los términos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compañías usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las características reales son raramente secretas.
ALPHA/ ALFA
Es la primera versión del programa, la cual es enviada a los verificadores para probarla.
Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse a una fase donde un producto todavía es inestable, aguarda todavía a que se eliminen los errores o a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos.
El nombre se deriva de alfa, la primera letra en el alfabeto griego.
BETA
Una versión beta o lanzamiento beta representa generalmente la primera versión completa del programa informático o de otro producto, que es posible que sea inestable pero útil para que las demostraciones internas y las inspecciones previas seleccionen a clientes. Algunos desarrolladores se refieren a esta etapa como inspección previa (preview) o como una inspección previa técnica (technical preview [TP]). Esta etapa comienza a menudo cuando los desarrolladores anuncian una congelación de las características del producto, indicando que no serán agregadas más características a esta versión y que solamente se harán pequeñas ediciones o se corregirán errores. Las versiones beta están en un paso intermedio en el ciclo de desarrollo completo. Los desarrolladores las lanzan a un grupo de probadores beta o betatesters (a veces el público en general) para una prueba de usuario. Los probadores divulgan cualquier error que encuentran y características, a veces de menor importancia, que quisieran ver en la versión final. Cuando una versión beta llega a estar disponible para el público en general, a menudo es extensamente probada por los tecnológicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado. Generalmente los desarrolladores de las versiones betas del software gratuito o de código abierto los lanzan al público en general, mientras que las versiones beta propietarias van a un grupo relativamente pequeño de probadores. En febrero de 2005, ZDNet publicó un artículo acerca del fenómeno reciente de las versiones beta que permanecían a menudo por años y que eran utilizadas como si estuvieran en nivel de producción. Observa que Gmail, igual que las noticias de Google, por ejemplo, estuvieron en beta por un período de tiempo muy largo (5 años). Esta técnica puede también permitir a un desarrollador retrasar el ofrecimiento de apoyo total o la responsabilidad de ediciones restantes. Los receptores de betas altamente propietarias pueden tener que firmar un acuerdo de no revelación. Como esta es la segunda etapa en el ciclo de desarrollo que sigue la etapa de alfa, esta se nombra como la siguiente letra griega beta.
1.4 CLASIFICACIÓN EN LA TECNOLOGÍA EN EL DESARROLLO DE SOFTWARE (TECNOLOGÍA ESTRUCTURADA, PROGRAMACIÓN ORIENTADA A OBJETOS).
DIFERENCIAS ENTRE ESTRUCTURADO Y ORIENTADO A OBJETOS
La idea orientada a objetos
Los conceptos de análisis y diseño orientados a objetos fueron desarrollados para dar soporte a una tecnología de programación O-O. El desarrollo de esta tecnología de programación no fue una evolución instantánea, sino la evolución de un conjunto, de conceptos algo desconectados que han sido puestos juntas para formar un paradigma para la ingeniería de software. Por ejemplo, la programación O-O, su concepto de encapsulación de la Idea de ingeniería de software de la abstracción de datos, y su concepto de herencia a partir de la idea da base de datos de generalización v especialización.
Debido a que el análisis y diseño O-O está fuertemente relacionado con la programación O-O, debemos explorar brevemente este contexto de programación O-O antes de proceder al análisis y diseño O-O, Seis ideas básicas caracterizan a la programación O-O; (1) objetos, (2) clases, (3) mensajes, (4) encapsulación. (5) herencia y (6) polimorfismo.
1.5 Análisis estructurado
El análisis tradicional de sistemas (que se caracteriza por especificaciones tipo novela victoriana) empezó a cambiar a fines de los años 70. La mayoría de las organizaciones que ahora usan el análisis estructurado basan su enfoque en los primeros textos de DeMarco, Gane y Sarson, y Weinberg y otros, al igual que en seminarios, videos y otros materiales de capacitación basados en dichos libros.
Sin embargo, varios años de experiencia práctica con el análisis estructurado clásico han señalado un buen número de áreas en las que es necesario hacer cambios b extensiones. Los principales cambios son:
El énfasis en la construcción de modelos "físicos actuales" y "lógicos actuales" del sistema del usuario se han demostrado que es políticamente peligroso. A menudo, el equipo encargado del proyecto pasaba tanto tiempo (a veces hasta seis meses, un año o más) estudiando el sistema anterior, que todo mundo sabía que iba a desecharse y reemplazarse con el nuevo, que el proyecto acababa siendo cancelado por un usuario impaciente antes de que el equipo pudiera darse a la tarea de estudiar el nuevo sistema propuesto. Esto no quiere decir que hayamos decidido evitar modelar el sistema actual del usuario en todos los casos, sino que simplemente lo reconocemos con una actividad políticamente peligrosa, a la que con toda probabilidad se tendrá que minimizar, si no eliminar del todo en el mundo real.
El análisis estructurado clásico hacía una distinción difusa y poco definida entre los modelos físicos (que hacen suposiciones acerca de la tecnología de la implantación o están predispuestos por ésta) y los modelos lógicos (que son completamente independientes de la tecnología de implantación); de hecho, aun los términos lógico y físico confunden a muchos. McMenamin y Palmer contribuyeron con ideas importantes a esta área e incluso ha cambiado parte de la terminología: ahora nos referimos a modelos esenciales (modelos de la "esencia" del sistema) en lugar de modelos lógicos, y a modelos do implantación en lugar de modelos físicos cada vez son más las organizaciones que están usando las técnicas del análisis estructurado para construir sistemas en tiempo real.
El análisis estructurado clásico hacía una distinción difusa y poco definida entre los modelos físicos (que hacen suposiciones acerca de la tecnología de la implantación o están predispuestos por ésta) y los modelos lógicos (que son completamente independientes de la tecnología de implantación); de hecho, aun los términos lógico y físico confunden a muchos. McMenamin y Palmer contribuyeron con ideas importantes a esta área e incluso ha cambiado parte de la terminología: ahora nos referimos a modelos esenciales (modelos de la "esencia" del sistema) en lugar de modelos lógicos, y a modelos do implantación en lugar de modelos físicos cada vez son más las organizaciones que están usando las técnicas del análisis estructurado para construir sistemas en tiempo real.
1.6 HERRAMIENTAS “CASE”
Conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software
Los estados en el Ciclo de Vida de desarrollo de un Software son:
Instalación.
CASE se define también como:
Las herramientas CASE permiten a las compañías competir más efectivamente usando estos sistemas desarrollados nuevamente para compararlos con sus necesidades de negocio actuales. En un mercado altamente competitivo, esto puede hacer la diferencia entre el éxito y el fracaso. Las herramientas CASE también permiten a los analistas tener más tiempo para el análisis y diseño y minimizar el tiempo para codificar y probar.
GLOSARIO DE DEFINICIONES BÁSICAS DE CASE:
CASE: Ayuda por Computadora a la Ingeniería de Software.
TECNOLOGÍA CASE: Una tecnología del software que mantiene una disciplina de la ingeniería automatizada para el desarrollo de software, mantenimiento y dirección de proyecto, incluye metodologías estructuradas automatizadas y herramientas automatizadas.
HERRAMIENTA CASE: Una herramienta del software que automatiza (por lo menos en parte) una parte del ciclo de desarrollo de software.
SISTEMA CASE: Un conjunto de herramientas CASE integradas que comparten una interface del usuario común y corren en un ambiente computacional común.
KIT de HERRAMIENTAS CASE: Un conjunto de herramientas CASE integradas que se han diseñado para trabajar juntas y automatizar (o proveer ayuda automatizada al ciclo de desarrollo de software, incluyendo el análisis, diseño, codificación y pruebas.
METODOLOGÍA CASE: Un automatizable metodología estructurada que define una disciplina e ingeniería como un acercamiento a todos o algunos aspectos del desarrollo y mantenimiento de software.
PUESTO DE TRABAJO para CASE: Una estación de trabajo técnica, diseñada a 32 bits o computadora personal equipada con Herramientas Case que automatiza varias funciones del ciclo.
PLATAFORMA de HARDWARE para CASE: Una arquitectura de hardware con uno, dos o tres sistemas puestos en línea, que proveen una plataforma operativa para las Herramientas Case.