Fundamentos de la Ingienería del Software
República
Bolivariana de Venezuela
Ministerio
del Poder Popular para la Educación
Instituto
Universitario de Tecnología José Antonio Anzoátegui
El
Tigre – Estado Anzoátegui
Fundamentos de la Ingeniería del
Software
Docente:
Integrantes:
Yudelys
Díaz L. Siso CI 30.342.988
E. Andrade CI 30.545.027
F. Bastidas CI 30.645.460
D. Rodríguez CI 30.856.988
T2 – F1 IF01
El Tigre, 27 de mayo del 2022
Software
Son programas específicos que hacen posible la ejecución y realización
de tareas específicas, en contraposición a los componentes físicos que son
llamados hardware. Por ejemplo, los sistemas operativos, aplicaciones,
navegadores web, juegos o programas.
Cualidades de Software
Ø · Correctitud: Un sistema es correcto si resuelve el problema real que causó su desarrollo. La correctitud es una propiedad matemática que establece la igualdad entre el software y su especificación, por lo que cuanto más específica haya sido en las instrucciones, más precisa y sistemática podrá ser su evaluación.
La correctitud puede ser valorada mediante diversas técnicas, algunos de enfoque experimental como las pruebas, otros de enfoque analítico como verificación formal de la correctitud.
Ø · Confiabilidad: Es la calidad que se puede esperar de una aplicación que lleve a cabo las operaciones establecidas y con la claridad requerida. Pueden tenerse aplicaciones correctas diseñadas para requerimientos “incorrectos”, por lo que la correctitud del software puede no ser suficiente para garantizar al usuario que el software se comporta como “es esperado”.
Ø · Robustez: Un programa es robusto si se comporta en forma razonable aún en situaciones que no fueron pronosticadas en la descripción de los requerimientos. La robustez es igual a la distancia del caos, es decir, mientras menor es la distancia al caos, mayor solidez posee el sistema.
Ø · Performance: Se puede medir la eficiencia del sistema de acuerdo a dos dimensiones: Los recursos necesarios que abarcan la construcción y desarrollo del software, y los recursos necesarios que comprende la ejecución de la aplicación.
Cabe destacar, que un sistema es eficiente
cuando se utilizan los equipos computacionales en forma económica. Por ejemplo,
si es muy lento reduce el entendimiento de los usuarios, si usa demasiado
espacio de disco puede ser muy costoso de ejecutar, si utiliza demasiada
memoria puede afectar al resto de las aplicaciones que se están ejecutando
mientras el sistema operativo intenta balancear el uso de la memoria.
Ø · Amigabilidad: Un sistema es amigable cuando el usuario encuentra la interfaz fácil de manejar, la amigabilidad está dada por la habilidad con que el sistema puede configurarse y ajustarse al ambiente de hardware.
Un sistema que produce respuestas erróneas
no es amigable sin importar lo “atractiva” que sea la interfaz de usuario, del
mismo modo que un sistema que produce respuestas más tardías de lo que requiere
el usuario no es amigable, aunque estas respuestas sean desplegadas en colores.
Ø · Verificabilidad: Un software es verificable si sus propiedades pueden ser verificadas sencillamente. Ejemplo, la correctitud o la performance de un sistema son propiedades que concierne comprobar.
La verificabilidad es en general una
cualidad interna, pero a veces puede ser externa, por ejemplo, en muchas
aplicaciones de seguridad crítica, el cliente solicita la verificación de
algunas propiedades.
Ø · Mantenimiento: Es la forma fácil de corregir y remediar fallas que pueda tener algún software. El mantenimiento también puede aplicarse a la reparación los problemas que surgen en la aplicación después de la liberación o agregarle al producto que no estaban en las especificaciones originales.
El mantenimiento abarca un grupo amplio de actividades que
tiene que ver con las modificaciones de un software existente la lograr una
mejora. Existen tres tipos de mantenimiento:
·
El
mantenimiento Correctivo: El mantenimiento correctivo es la
eliminación de errores excedentes presentes en el producto al ser liberado, así
como errores implantados al software durante su mantenimiento.
· Mantenimiento Adaptativo: Involucra el ajuste de la aplicación a ajustes en el entorno, por ejemplo, la creación de hardware o del sistema operativo.
En
este asunto la necesidad de cambios al software no puede ser atribuida a una
particularidad del software en sí mismo como la inhabilidad de prestar cierta
funcionalidad demandada por el usuario o errores residuales, sino que se
producen debido a cambios en su entorno.
·
El
mantenimiento Perfectivo: Implica cambios en el software para
perfeccionar sus cualidades, los cuales se deben a la necesidad de cambiar
las funciones brindadas por el software, añadir nuevas funciones, renovar la
performance, facilitar su manejo, entre otras.
Estos
cambios pueden ser producidos tanto por el ingeniero de software para
perfeccionar el estatus del producto en el mercado, como por el cliente debido
a nuevos requerimientos.
Ø · La Reusabilidad: Se refiere a que una aplicación puede utilizarse en otras aplicaciones. Es complicado lograr reusabilidad, ya que se debe examinar el instante de desarrollar los componentes del software; un modo para conseguir reusabilidad es el manejo de diseño orientado a objetos.
Ø · Portabilidad: Se refiere a la manera en que los clientes pueden acceder a los productos ya que un software portable es mucho más fácil de obtener por los clientes dado que pueden acceder a dicho software. El software es portable si puede ser desarrollado en distintos ambientes, refiriéndose este último tanto a plataformas de hardware como a ambientes de software como puede ser determinado sistema operativo.
Ø · Comprensibilidad: Algunos sistemas de software son más cómodos de comprender que otros, ciertas tareas son sustancialmente más complicadas que otras. La comprensibilidad es una cualidad interna del producto y ayuda a lograr muchas de las otras cualidades como evolucionabilidad y verificabilidad. La comprensibilidad no es más que ejecute su función de acuerdo a lo que el usuario predice.
Ø · Interoperabilidad: Es la destreza que posee un sistema para coexistir e interactuar con otros, por ejemplo, la habilidad de un procesador de texto de incluir gráficas producidas por un paquete de gráficos.
Ø · La Productividad: Es una cualidad del proceso de producción de software, calcula la eficiencia del proceso. Un proceso eficiente resulta en una entrega más rápida del producto. Los ingenieros originan software individualmente a cierta tasa, la cual puede alterarse considerablemente entre individuos con habilidad distinta.
Cuando los individuos forman un equipo, la
productividad de éste es alguna función de las productividades individuales, y
en general esta productividad combinada es menor que la suma de las partes.
Ø · Oportunidad: La oportunidad es una cualidad del proceso que se refiere a la habilidad de liberar el software a tiempo. Esto puede ser un arma de doble filo ya que muchos procesos fracasan en alcanzar los resultados a tiempo. La oportunidad en sí misma no es una cualidad útil, aunque llegar tarde puede llevar a perder oportunidades en el mercado, entregar un producto a tiempo que carece de otras cualidades como confiabilidad o performance, no tiene sentido.
Entregar un producto a tiempo requiere una
agenda planeada cuidadosamente, con un trabajo de estimación acertado y puntos
de revisión especificados claramente y verificables.
Factores de Calidad del Software
La calidad de software es todo el conjunto
de cualidades que determinan su eficacia y utilidad, cumpliendo con las
necesidades tanto implícitas como explícitas del cliente.
Los factores que determinan la calidad de
un software se dividen en tres grupos:
Ø Operaciones del producto: Características
operativas
·
Corrección: Es el
grado en que una aplicación satisface sus especificaciones y consigue los
objetivos encomendados por el cliente.
·
Fiabilidad: Es el
grado que se puede esperar de una aplicación lleve a cabo las operaciones
especificadas y con la precisión requerida.
·
Eficiencia: Es la
cantidad de recursos hardware y software que necesita una aplicación para
realizar las operaciones con los tiempos de respuesta adecuados.
·
Integridad: Consiste
en el grado con que puede controlarse el acceso al software o a los datos a
personal no autorizado.
·
Facilidad
de Uso: Es el esfuerzo requerido para aprender el manejo de una
aplicación, trabajar con ella, introducir datos y conseguir resultados.
Ø Revisión del producto: Capacidad para
soportar cambios.
·
Facilidad
de mantenimiento: Es el esfuerzo requerido para localizar y
reparar errores.
·
Flexibilidad: Se
basa en el esfuerzo requerido para modificar una aplicación en funcionamiento.
·
Facilidad
de Prueba: Es el esfuerzo requerido para probar una
aplicación de forma que cumpla con lo especificado en los requisitos.
Ø Transición del producto: Adaptabilidad a
nuevos entornos.
·
Portabilidad: Es el
esfuerzo requerido para transferir la aplicación a otro hardware o sistema
operativo.
·
Reusabilidad: Se
basa en que partes de una aplicación pueden utilizarse en otras aplicaciones.
·
Interoperabilidad: Es el
esfuerzo necesario para comunicar la aplicación con otras aplicaciones o
sistemas informáticos.
Ingeniería del Software
La Ingeniería de Software es la
rama de la ingeniería que estudia todo lo relacionado con la informática o
sistemas de computación, ya sea la creación de software confiable y de calidad,
con una orientación metódica, ordenada y cuantificable al incremento, ejecución
y conservación del software, y basándose en métodos y técnicas de ingeniería, y
brindando soporte operacional y de mantenimiento.
Sin embargo, la ingeniería de software se
ha convertido en una de las áreas clave en el auge de la tecnología en empresas
y sociedad.
Visión
general del Proceso de desarrollo de Software
En el desarrollo de software hay una serie
de desafíos adicionales, relativos esencialmente a la naturaleza del producto
obtenido. Un proceso de desarrollo de software tiene como propósito la
producción eficaz y eficiente de un producto software que reúna los requisitos
del cliente.
Las actividades requeridas para
desarrollar un sistema de software de alta calidad y proporciona el marco de
trabajo desde el cual se puede establecer un plan detallado para el desarrollo
del software. Actividades: Diseño, validación, evolución, especificación.
El papel del usuario dentro del proceso de
desarrollo de software
Todos sabemos que cuanto mayor sea la
ayuda de los usuarios en un proyecto de desarrollo de software, mayores serán
las probabilidades de éxito que tenga el mismo.
No obstante, es importante hacer algunas
matizaciones:
1)
El proyecto no se hace sólo, porque
incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue
interpretar con precisión lo que quieren y no se dinamiza un feedback continuo
de los mismos durante todo el proceso de desarrollo, se incrementarán las
posibilidades de que algún requisito funcional no se haya recogido
adecuadamente o de que se haya realizado un software con una usabilidad
incómoda para los usuarios.
Estas
circunstancias son fuente de innumerables problemas en las fases finales del
proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el
proyecto, además de crear conflictos con el cliente que pueden perjudicar las
relaciones futuras con el mismo. Esto hace que sea fundamental el papel que
desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales
y analistas programadores.
2)
Es importante que entre el grupo usuarios
asignados al proyecto haya usuarios que vayan aestar implicados en el futuro
uso del sistema de información, es decir, no es suficiente que el equipo de
usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del
resultado del trabajo de la herramienta, sino que es fundamental que participen
usuarios que después se tengan que poner el mono de trabajo y vayan a trabajar
con el software.
Es
importante conseguir la combinación de ambos tipos de usuarios (tampoco es
positivo que en el grupo de usuarios no participen usuarios directores, ya que
pueden existir conflictos entre usuarios que éstos deben solucionar y también
es recomendable que el software no sólo se diseñe para el corto plazo, sino que
sirva para tareas de gestión, planificación, etc… y esta visión la proporcionan
principalmente los usuarios directores), por lo que el jefe de proyectos debe
poner en conocimiento del cliente esta necesidad, como es lógico explicando los
riesgos de que no se aplique esta estrategia.
3)
Los analistas están para ayudar y para
colaborar con los usuarios en la especificación y diseño de la solución, pero
no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer su
trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no
sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si
realmente estuviéramos haciendo su trabajo durante un tiempo y viéramos los
problemas con los que se enfrentan cotidianamente.
La
clave por tanto está en la colaboración y en el diálogo, es decir, se pueden
proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una
vuelta al calcetín de cómo hacen sus tareas, salvo que ellos mismos lo
soliciten y procurando en estos casos y en consenso con los usuarios que los
cambios sean tranquilos.
4)
Es fundamental documentar el proyecto, en
primer lugar con la documentación que se especifique en las normativas de
desarrollo de la organización para la que se realiza el servicio, con las
matizaciones que indique el Director del Proyecto, en segundo lugar con la
documentación que establezcan las normativas internas de calidad de tu
organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de los
casos coincidirá) y a todo lo anterior sumarle toda la documentación de trabajo
que sea necesaria para trabajar con los usuarios, que no tienen por qué
entender de modelos de datos, de diagramas de casos de uso, etc…, es más, es un
error trabajar con los usuarios utilizando dichas herramientas, ya que estas
son de utilidad técnica y no hablan el mismo lenguaje de los usuarios.
Este tipo
documentación, por tanto, no tiene por qué tener los formalismos de la técnica
y tiene como objetivo que el usuario capte lo que el analista está
interpretando y se pueda ir perfilando a partir de esto, tantos requisitos, como
casos de uso, interfaces, etc. Es muy importante trabajar todo esto, ya que
comenzar demasiado pronto con la construcción, es algo muy arriesgado, ya que
los costes de modificar algo en las distintas fases de la construcción pueden
ser muy importantes y provocar que se tengan que reconstruir varias veces
distintas funcionalidades de la aplicación.
Responsabilidad ética y profesional en
ingeniería del software
La ingeniería del software se lleva a cabo
dentro de un marco legal y social que limita la libertad de los ingenieros. Los
ISW deben aceptar que su trabajo comprende responsabilidades más amplias que
simplemente la aplicación de habilidades técnicas.
Deben
comportarse de una forma ética y moral responsable, no basta con poseer
estándares normales de honestidad e integridad. No debería utilizar su
capacidad y sus habilidades para comportarse de forma deshonesta o de forma que
deshonre la profesión de la ingeniería del software.
Existen áreas donde los estándares de
comportamiento aceptable no están acotados por las leyes, sino por la
responsabilidad profesional, algunas de estas son:
Ø · Confidencialidad: Respetar la confidencialidad de sus empleadores o clientes, independientemente de que se haya firmado un acuerdo formal de confidencialidad.
Ø · Competencia: No debe falsificar su nivel de competencia, ni aceptar conscientemente trabajos que están fuera de su capacidad.
Ø · Derechos de propiedad intelectual: Debe ser consciente de las leyes locales que gobiernan el uso de la propiedad intelectual, como los patentes copyright. Debe asegurarse de que la propiedad intelectual de los empleadores y clientes esté protegida.
Ø · Uso inapropiado de las computadoras: No debe emplear sus habilidades técnicas para utilizar de forma inapropiada las computadoras de otras personas. Desde los relativamente triviales (utilizar juegos en las máquinas de un empleado, por ejemplo) hasta los extremadamente serios (difusión de virus).
Ciclo de Vida del Software
Es una secuencia estructurada y bien
definida de las etapas de la ingeniería
de software para desarrollar el software deseado.
Lo describe desde el inicio hasta el
final, con el objetivo de definir las distintas fases intermedias para validar
el desarrollo de la aplicación y confirmar que cumpla con los requisitos de
verificación.
Etapas del
Ciclo de Vida del Software
Las principales etapas que
forman el ciclo de vida de desarrollo de software son:
Ø · Planificación: Son tareas que influyen en el éxito del proyecto, por eso es necesaria una planificación inicial. En esta fase se incluyen tareas como la determinación del ámbito del proyecto, un estudio de viabilidad, análisis de riesgos, costes estimados, asignación de recursos en las distintas etapas, etc.
Ø · Análisis: Es el proceso en el que se trata de descubrir lo que se necesita y cómo llegar a las características que el sistema debe poseer.
Ø · Diseño: Es una etapa complicada, y si la solución inicial no es la más adecuada, habrá que redefinirla. Además, se estudian las posibles implementaciones que hay que construir y la estructura general del software.
Ø · Implementación: Se trata de elegir las herramientas adecuadas en un entorno de desarrollo que haga más sencillo el trabajo y el lenguaje de programación óptimo, esta decisión va a depender del diseño y el entorno elegido. Es importante tener en cuenta la adquisición de productos necesarios para que el software funcione.
Ø · Pruebas: Conseguiremos detectar los fallos que se hayan cometido en etapas anteriores, para que no repercuta en el usuario final. Esta fase del ciclo de vida del software hay que repetirla tantas veces como sea necesaria, ya que la calidad y estabilidad final del software dependerá de esta fase.
Ø Instalación: En
esta fase pondremos el software en funcionamiento.
Ø Uso y mantenimiento: Este
es un momento crucial dentro del ciclo de vida de un software.
Dentro del mantenimiento se pueden
distinguir tres puntos importantes:
·
Correctivo:
Eliminar defectos que se van detectando.
·
Adaptativo:
Adaptarlo a nuevas necesidades.
·
Perfectivo:
Añadir nuevas funcionalidades.
Modelos del ciclo de vida de un software
Entre los modelos de ciclo de
vida del software podemos encontrar los siguientes:
Ø · Modelo en cascada: Es un proceso secuencial en el que el desarrollo va fluyendo de arriba hacia abajo. Aunque en ocasiones ha sido criticado debido a su rigidez, sigue siendo el más seguido a día de hoy. En este modelo del ciclo de vida de un software, se espera a finalizar una etapa para comenzar con la siguiente.
Ø · Modelo V: Como en el modelo en cascada los defectos solo se descubrían al final, cuando empezaba la fase de pruebas, se siguió con el modelo V, en el que las pruebas comienzan lo más pronto posible, para descubrir rápidamente los posibles errores y no esperar al final para mejorarlo.
Ø · Modelo iterativo: Consiste en la iteración de varios ciclos de vida en cascada entregando al cliente una versión mejorada al final de cada iteración para que proponga mejoras, hasta que se satisfagan sus necesidades. Es ideal para proyectos en los que los requisitos no están claros.
Ø · Modelo de desarrollo incremental: Combina el modelo en cascada con el de prototipos y está basado en la filosofía de construir incrementando las funcionalidades del programa. Se sigue un proceso lineal y cada uno de ellos va incrementando funcionalidades del software hasta llegar al producto final.
Ø · Modelo en espiral: Las actividades de este modelo forman una espiral, y cada bucle representa un conjunto de actividades, cada actividad se va eligiendo en función del análisis de riesgos del bucle anterior.
Se necesita un equipo con experiencia para detectar
correctamente los riesgos.
En cada bucle se siguen cuatro tareas:
·
Fijar objetivos
·
Análisis del riesgo
·
Desarrollar, verificar y probar
·
Planificar
Ø · Modelo de prototipos: Comienza con la recolección de requisitos y definición de objetivos globales, llevando a un diseño rápido y a un prototipo. El prototipo es evaluado por el cliente, y nos permite refinar los requisitos hasta llegar a lo que el cliente espera.
Principios, Modelos, Métodos, Metodología
técnicas, actividades y herramientas en el proceso de desarrollo de Software.
Principios
Ø · Eliminar Desperdicios: Desperdicio es todo aquello en lo que invertimos recursos pero que no es traducido en valor para nuestro cliente. Este principio nos advierte que siempre hay que estar en la búsqueda de eliminar desperdicios en nuestro proceso, en cualquiera de las formas que este pueda presentar. Crear Conocimiento: El proceso debiera considerar en todas las áreas que sea posible, transmitir el conocimiento de una forma rápida y eficiente para que el equipo esté lo más nivelado en el entendimiento de lo que se produce, cómo se produce y para qué se produce.
Ø · Calidad Intrínseca: Todas las pequeñas partes que conforman el producto final deben ser construidas con calidad desde el primer momento y no esperar que un proceso futuro sea el encargado de agregarla. Esto se traduce en integración continua, automatización de procesos repetitivos (testing, deploy, etc) y eliminación de código duplicado al momento de detectarlo; pero también en facilitar las discusiones cara a cara por sobre e-mail y en la disponibilidad de personas.
Ø · Tomar decisiones con toda la información (Diferir compromiso): Este principio advierte que no es buena idea tomar decisiones en base a estimados o adivinanzas. Las decisiones se deben postergar hasta el momento en que se tenga la mayor cantidad de información, sin caer en la irresponsabilidad.
Ø · Entregar Rápido: Al entregar rápido se produce un ciclo de feedback óptimo y permite al equipo de desarrollo ajustar su modelo a la realidad con una mayor precisión y menor costo para el proyecto. Esto también se traduce en limitar la cola de tareas pendientes a un mínimo dado, para que siempre el alcance de lo que resta quepa dentro del contexto mental del equipo. Limita el trabajo en curso para cada persona de manera que puedan enfocarse en cada tarea a mano.
Ø · Respetar a las personas: Entrega el poder de tomar decisiones a quienes tienen el conocimiento y experiencia técnica para hacerlo, es decir, quienes implementarán finalmente las decisiones. Realiza entrenamientos internos o externos e incentiva la curiosidad intelectual. Alienta el espíritu por mejorar el oficio.
Ø · Optimizar el todo: Enfoca tus esfuerzos de optimización en el flujo de valor que sale hacia el usuario y no en cada una de las partes que conforman tu proceso, usa una mirada global para optimizar. Siempre ten en tu nómina los mejores profesionales, técnicos y empleados que puedas conseguir, finalmente es el equipo el que hace la diferencia.
Modelos de Proceso de Software
Ø Codificar y corregir (Code-and-Fix): Este
es el modelo básico utilizado en los inicios del desarrollo de software.
Contiene dos pasos:
· · Escribir código
· · Corregir problemas en el código.
Se trata de primero implementar algo de
código y luego pensar acerca de requisitos, diseño, validación, y
Mantenimiento.
Este modelo tiene tres problemas principales:
·
Después de un número de correcciones el código puede tener una muy mala
estructura, hace que los arreglos sean muy costosos.
·
Software no se ajusta a las necesidades del
usuario, por lo que es rechazado o su reconstrucción es muy cara.
·
El código es difícil de reparar por su pobre
preparación para probar y modificar.
Ø Modelo en cascada:
El modelo en cascada consta de las siguientes fases:
· · Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.
· · Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.
· · Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. Departamento de Sistemas Informáticos y Computación.
· · Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
· · Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.
Algunos problemas que se observan en el modelo
de cascada son:
· · Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.
· · Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.
· · Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.
· · Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.
· · Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.
· · Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.
Ø Desarrollo evolutivo
Es el desarrollo de una implantación del
sistema inicial, exponerla a los comentarios del usuario, refinarla en N
versiones hasta que se desarrolle el sistema adecuado.
Una ventaja de este modelo es que se
obtiene una rápida realimentación del usuario, ya que las actividades de
especificación, desarrollo y pruebas se ejecutan en cada iteración.
Existen dos tipos de desarrollo evolutivo:
·
Desarrollo
Exploratorio: El objetivo de este enfoque es explorar con el
usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza
con las partes que se tiene más claras. El sistema evoluciona conforme se
añaden nuevas características propuestas por el usuario.
·
Enfoque
utilizando prototipos: El objetivo es entender los requisitos
del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia
del desarrollo exploratorio, se comienza por definir los requisitos que no
están claros para el usuario y se utiliza un prototipo para experimentar con
ellos.
El prototipo ayuda a terminar de definir
estos requisitos.
Entre los puntos favorables de este modelo
están:
· · La especificación puede desarrollarse de forma creciente.
· · Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.
· · Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
Desde una perspectiva de ingeniería y
administración se identifican los siguientes problemas:
· · Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.
· · Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.
· · Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
Ø Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los
requisitos hasta llegar a un programa ejecutable.
Ø Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los
requisitos hasta llegar a un programa ejecutable.
Observaciones sobre el desarrollo formal
de sistemas:
·
Permite demostrar la corrección del sistema
durante el proceso de transformación. Así, las pruebas que verifican la
correspondencia con la especificación no son necesarias.
·
Es atractivo sobre todo para sistemas donde hay
requisitos de seguridad y confiabilidad importantes.
·
Requiere desarrolladores especializados y
experimentados en este proceso para llevarse a cabo.
Ø Desarrollo basado en reutilización
Como su nombre lo indica, es un modelo
fuertemente orientado a la reutilización.
Este modelo consta de 4 fases ilustradas
en la A continuación se describe cada fase:
1)
Análisis
de componentes: Se determina qué componentes pueden ser
utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para
adecuarlos.
2)
Modificación
de requisitos: Se adaptan (en lo posible) los requisitos para
concordar con los componentes de la etapa anterior. Si no se puede realizar
modificaciones en los requisitos, hay que seguir buscando componentes más
adecuados (fase 1).
3)
Diseño
del sistema con reutilización: Se diseña o reutiliza el
marco de trabajo para el sistema. Se debe tener en cuenta los componentes
localizados en la fase 2 para diseñar o determinar este marco.
4)
Desarrollo
e integración: El software que no puede comprarse, se
desarrolla. Se integran los componentes y subsistemas. La integración es parte
del desarrollo en lugar de una actividad separada.
Este modelo consta de 4 fases ilustradas
en la Figura 9. A continuación se describe cada fase:
1) · Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
2) · Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).
3) · Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.
4) · Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.
Desventajas de este modelo
·
Los “compromisos” en los requisitos son
inevitables, por lo cual puede que el software no cumpla las expectativas del
cliente.
·
Las actualizaciones de los componentes
adquiridos no están en manos de los desarrolladores del sistema.
Procesos iterativos
A continuación, se expondrán dos enfoques
híbridos, especialmente diseñados para el soporte de las iteraciones:
· · Desarrollo Incremental.
· · Desarrollo en Espiral.
Ø Desarrollo incremental
Es una combinación del Modelo de Cascada y
Modelo Evolutivo.
Reduce el rehacer trabajo durante el
proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener
experiencia en el sistema.
Durante el desarrollo de cada incremento
se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento
que se tenga sobre los requisitos a implementar. Si se tiene un buen
conocimiento, se puede optar por cascada, si es dudoso, evolutivo.
Entre las ventajas del modelo incremental
se encuentran:
·
Los clientes no esperan hasta el fin del
desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer
incremento.
·
Los clientes pueden aclarar los requisitos que
no tengan claros conforme ven las entregas del sistema.
·
Se disminuye el riesgo de fracaso de todo el
proyecto, ya que se puede distribuir en cada incremento.
·
Las partes más importantes del sistema son
entregadas primero, por lo cual se realizan más pruebas en estos módulos y se
disminuye el riesgo de fallos.
Algunas de las desventajas identificadas
para este modelo son:
· · Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
· · Cada incremento debe aumentar la funcionalidad.
· · Es difícil establecer las correspondencias de los requisitos contra los incrementos.
· · Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Ø Desarrollo en espiral
Es actualmente uno de los más conocidos y
fue propuesto por Boehm el ciclo de desarrollo se representa como una espiral,
en lugar de una serie de actividades sucesivas con retrospectiva de una
actividad a otra.
Cada ciclo de desarrollo se divide en
cuatro fases:
1) Definición de objetivos: Se
definen los objetivos. Se definen las restricciones del proceso y del producto.
Se realiza un diseño detallado del plan administrativo. Se identifican los
riesgos y se elaboran estrategias alternativas dependiendo de estos.
2) Evaluación y reducción de riesgos: Se
realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse
prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los
pasos para reducir los riesgos.
3) Desarrollo y validación: Se
escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo
que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del
riesgo identificado para esa fase.
4)
Planificación:
Se
determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros,
toma en consideración explícitamente el riesgo, esta es una actividad
importante en la administración del proyecto.
El ciclo de vida inicia con la definición
de los objetivos. De acuerdo a las restricciones se determinan distintas
alternativas. Se identifican los riesgos al sopesar los objetivos contra las
alternativas. Se evalúan los riesgos con actividades como análisis detallado,
simulación, prototipos, etc. Se desarrolla un poco el sistema.
Métodos
Los métodos abarcan una gran gama de
tareas que incluyen análisis de requisitos, diseño, construcción de programas,
pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios
básicos que gobiernan cada área de la tecnología e incluyen actividades de
modelado y otras técnicas descriptivas.
Metodología
Un proceso de software detallado y
completo suele denominarse “Metodología”. Las metodologías se basan en una
combinación de los modelos de proceso genéricos (cascada, evolutivo,
incremental, etc.).
Adicionalmente una metodología debería
definir con precisión los artefactos, roles y actividades involucrados, junto
con prácticas y técnicas recomendadas, guías de adaptación de la metodología al
proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se
utiliza el término “método” para referirse a técnicas, notaciones y guías
asociadas, que son aplicables a una (o algunas) actividades del proceso de
desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.
En actividades de análisis y diseño,
podemos clasificar las metodologías en dos grupos:
Ø Metodologías estructuradas
Los métodos estructurados comenzaron a desarrollarse
a fines de los 70 con la Programación Estructurada, luego a mediados de los
70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de
Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas
de Flujo de Datos). Estas metodologías son particularmente apropiadas en
proyectos que utilizan para la implementación lenguajes de 3ra y 4ta
generación.
Ø Metodologías orientadas a objetos
Su historia va unida a la evolución de los
lenguajes de programación orientada a objeto, los más representativos: a fines
de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++
por Bjarne Stroustrup en 1981 y actualmente Java11 o C# de Microsoft. A fines
de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el
Método Unificado con la ambiciosa idea de conseguir una unificación de sus
métodos y notaciones, que posteriormente se reorienta a un objetivo más
modesto, para dar lugar al Unified Modeling Language (UML)12, la notación OO
más popular en la actualidad.
Ø Metodologías tradicionales (no ágiles)
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.
Todas las propuestas metodológicas antes
indicadas pueden considerarse como metodologías tradicionales. Aunque en el
caso particular de RUP, por el especial énfasis que presenta en cuanto a su
adaptación a las condiciones del proyecto (mediante su configuración previa a
aplicarse), realizando una configuración adecuada, podría considerarse Ágil.
Ø Metodologías ágiles
Un proceso es ágil cuando el desarrollo de
software es incremental (entregas pequeñas de software, con ciclos rápidos),
cooperativo (cliente y desarrolladores trabajan juntos constantemente con una
cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y
modificar, bien documentado), y adaptable (permite realizar cambios de último
momento).
Actividades
Ø · Planificación
La importante tarea a la hora de crear un
producto de software es obtener los requisitos o el análisis de los requisitos.
Los clientes suelen tener una idea más bien abstracta del resultado final, pero
no sobre las funciones que debería cumplir el software.
Una vez que se hayan recopilado los
requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo.
Este documento se conoce como especificación funcional.
Ø · Implementación, Pruebas y Documentación
La implementación es parte del proceso en
el que los ingenieros de software programan el código para el proyecto.
Las pruebas de software son parte esencial
del proceso de desarrollo del software. Esta parte del proceso tiene la función
de detectar los errores de software lo antes posible.
La documentación del diseño interno del
software con el objetivo de facilitar su mejora y su mantenimiento se realiza a
lo largo del proyecto. Esto puede incluir la documentación de un API, tanto
interior como exterior.
Ø · Despliegue y mantenimiento
El despliegue comienza cuando el código ha
sido suficientemente probado, ha sido aprobado para su liberación y ha sido
distribuido en el entorno de producción.
Entrenamiento y soporte para el software
es de suma importancia y algo que muchos desarrolladores de software descuidan.
Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta
inseguridad, es por ello que es fundamental instruir de forma adecuada a los
futuros usuarios del software. El mantenimiento y mejora del software de un
software con problemas recientemente desplegado puede requerir más tiempo que
el desarrollo inicial del software. Es posible que haya que incorporar código que
no se ajusta al diseño original con el objetivo de solucionar un problema o
ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son
muy elevados puede que sea oportuno rediseñar el sistema para poder contener
los costes de mantenimiento.
Técnicas y herramientas
Son un 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.
· · La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.
· · Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.
· · El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:
· · Análisis de datos y procesos integrados mediante un repositorio.
· · Generación de interfaces entre el análisis y el diseño.
· · Generación del código a partir del diseño.
· · Control de mantenimiento.
Ø Tipos de Herramientas CASE
No existe una única clasificación de
herramientas CASE, es difícil incluirlas en una clase determinada. Podrían
clasificarse atendiendo a:
·
Las plataformas que soportan.
·
Las fases del ciclo de vida del desarrollo de
sistemas que abarca.
·
La arquitectura de las aplicaciones que
produce.
·
Su funcionalidad.
Las herramientas CASE, en función de las
fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:
Herramientas integradas, I-CASE
(Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida
del desarrollo de sistemas. Son llamadas también CASE workbench.
Las herramientas I-CASE se basan en una
metodología. Tienen un repositorio y aportan técnicas estructuradas para todas
las fases del ciclo de vida. Estas son las características que les confieren su
mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no
todas ellas son modernas en el sentido de aprovechar la potencia de las
estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de
prototipo.
Herramientas de alto nivel, U-CASE (Upper
CASE - CASE superior) o front-end, orientadas a la automatización y soporte de
las actividades desarrolladas durante las primeras fases del desarrollo:
análisis y diseño.
Una estrategia posible es utilizar una
U-CASE para análisis y diseño, combinada con otras herramientas más modernas
para las fases de construcción y pruebas. En este caso, habría que vigilar
cuidadosamente la integración entre las distintas herramientas.
Selección del modelo apropiado según las
características de los proyectos de software
Cuando se gestiona un proyecto exitoso, es
necesario entender que este puede llegar a fracasar. Según John Reel, existen
10 razones por las cuales un proyecto puede fracasar:
· · El personal de software no entiende las necesidades de los clientes.
· · El ámbito del producto está mal definido.
· · Los cambios se gestionan mal.
· · La tecnología elegida cambia.
· · Las necesidades comerciales cambian.
· · Los plazos de entrega no son realistas.
· · Los usuarios se resisten a la utilización del software.
· · Se pierde el patrocinio.
· · El equipo del proyecto carece de personal con las habilidades apropiadas.
·
Los gestores evitan las mejores prácticas y las
lecciones aprendidas.
Para tener éxito en la consecución de un
proyecto es necesario comenzar con pie derecho, esto se lo logra trabajando
duro para entender el problema y dar una solución adecuada. Se debe rastrear el
proyecto conforme se elabora el producto y se aprueba por parte del grupo de
control de calidad.
Es importante que el gestor del proyecto
tome decisiones inteligentes para no poner en riesgo el desarrollo de la
solución. Por último, se debe analizar los resultados obtenidos para obtener la
experiencia necesaria en la construcción de otros proyectos.
Recomendaciones
ü Los cambios radicales en hardware a partir
de la última mitad del siglo anterior causaron una forzada evolución del
software, lo cual ha generado el establecimiento de modelos, estándares y
redefinición de conceptos que ratifican un establecimiento cada vez más fuerte
de la ingeniería del software a nivel mundial.
ü La gestión de proyectos de desarrollo de
software es motor esencial para el éxito de cualquier proyecto de este tipo. La
gestión debe fraccionarse en las etapas definidas claramente, manteniendo en
cuenta los 4 requisitos indispensables: las personas, el producto, el proceso y
el proyecto.
ü La programación orientada a objetos es una
extensión actual de la tecnología que, si bien ha evolucionado desde mediados
del siglo pasado, presenta hoy día un enfoque y distinto al tradicional.
ü El diseño de la arquitectura es parte
fundamental de los principios de la ingeniería del software y es único en el
sentido de que se organiza en función de los objetos y clases que se definirán.
De hecho, probablemente la parte más difícil del desarrollo de software
orientado a objetos es la identificación de clases necesarias y la forma como
interactúan entre sí.
ü Teniendo en cuenta los principios de
ingeniería del software resumidos en este ensayo, profundizando en cada uno de
ellos y llevando un trabajo juicioso y concienzudo, garantizará el éxito en
cualquier proyecto de construcción de software y en proyectos de otro tipo.
Conclusión
La Ingeniería del Software es la rama de
la ingeniería que crea y mantiene las aplicaciones de software usando
tecnologías y prácticas de las ciencias de la computación, manejo de proyectos,
ingeniería, el ámbito de la aplicación, y otros campos. El Software es la suma
total de los programas de ordenador, procedimientos, reglas, la documentación
asociada y los datos que pertenecen a un sistema de cómputo.
Un paradigma de la programación es una
propuesta tecnológica adoptada por una comunidad de programadores cuyo núcleo
central es incuestionable en cuanto a que unívocamente trata de resolver uno o
varios problemas claramente delimitados. Los métodos de desarrollo de software
son una serie de operaciones usadas para lograr un objetivo y requiere un conjunto
de tareas que tienen que ser realizadas para producir un producto de software
de alta calidad.
Hay que diferenciar modelo de metodología:
el modelo de desarrollo de software es una representación simplificada del
proceso para el desarrollo de software, presentada desde una perspectiva
específica; y la metodología de desarrollo de software es un enfoque
estructurado para el desarrollo de software que incluye modelos de sistemas,
notaciones, reglas, sugerencias de diseño y guías de procesos. Un sistema se
puede modelar mediante, ya sea, una construcción física o analógica, una
representación gráfica o un mapa, un enunciado teórico o un planteamiento
matemático; comúnmente se utiliza un lenguaje de modelado conocido como UML.
El objetivo principal que busca la
ingeniería de software es convertir el desarrollo de software en un proceso
formal, con resultados predecibles. El individuo que desempeña profesionalmente
en esta área se le conoce como ingeniero de software, y se desempeña en áreas
como: Consultor en TIC’s, Administrador de Redes de Computadoras, Administrador
de Bases de Datos, entre otros. El software en su desarrollo pasa por varias
etapas que se pueden agrupar en estos cuatro grandes grupos: Concepción,
desarrollo, prueba y explotación. Hoy en día vivimos en una sociedad digital,
donde el software ha cobrado vital importancia en la vida de todas las
personas, y la ingeniería del software permite mejorar la calidad de estos.
Referencias Bibliográficas
· · https://es.m.wikipedia.org/wiki/Software
· https://softwareblog03.wordpress.com/2017/04/23/cualidades-del-software/
· · https://softwareblog03.wordpress.com/2017/04/24/factores-de-calidad-del-software/
· · https://es.m.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
·· · https://softwarelibre-informatica.blogspot.com/2013/04/principios-modelos-metodos-metodologias.html
· · https://micarrerauniversitaria.com/c-ingenieria/ingenieria-de-software/
Entradas
0 comments:
Publicar un comentario