• Author / Uploaded
• jorge castro

Citation preview

Contenido Inicio de Ingeniería de Software Descripción general de ingeniería de software Ciclo de vida del desarrollo de programas Gestión de proyectos de software Requisitos de Software Conceptos básicos de diseño de software Herramientas de análisis y diseño Estrategias de diseño de software Diseño de interfaz de usuario de software Complejidad del diseño de software Implementación de software Descripción general de las pruebas de software Mantenimiento del software Descripción general de herramientas CASE

Descripción general de ingeniería de software Primero, comprendamos qué representa la ingeniería de software. El término se compone de dos palabras, software e ingeniería. El software es más que un simple código de programa. Un programa es un código ejecutable, que sirve para algún propósito computacional. El software se considera una colección de código de programación ejecutable, bibliotecas asociadas y documentación. El software, cuando se hace para un requisito específico, se llama producto de software. La ingeniería, por otro lado, se trata de desarrollar productos, utilizando principios y métodos científicos bien definidos.

La ingeniería de software es una rama de ingeniería asociada con el desarrollo de productos de software utilizando principios, métodos y procedimientos científicos bien definidos. El resultado de la ingeniería de software es un producto de software eficiente y confiable.

Definiciones IEEE define la ingeniería de software como: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software; es decir, la aplicación de la ingeniería al software. (2) El estudio de enfoques como en la declaración anterior.

Fritz Bauer, un informático alemán, define la ingeniería de software como: La ingeniería de software es el establecimiento y uso de principios sólidos de ingeniería para obtener económicamente un software que sea confiable y funcione de manera eficiente en máquinas reales.

Evolución del software El proceso de desarrollo de un producto de software utilizando principios y métodos de ingeniería de software se conoce como evolución de software. Esto incluye el desarrollo inicial del software y su mantenimiento y actualizaciones, hasta que se desarrolle el producto de software deseado, que satisfaga los requisitos esperados.

La evolución comienza desde el proceso de recopilación de requisitos. Después de lo cual los desarrolladores crean un prototipo del software previsto y lo muestran a los usuarios para obtener sus comentarios en la etapa inicial del desarrollo del producto de software. Los usuarios sugieren cambios, en los que varias actualizaciones consecutivas y mantenimiento continúan cambiando también. Este proceso cambia al software original, hasta que se logra el software deseado. Incluso después de que el usuario haya deseado tener el software disponible, la tecnología avanzada y los requisitos cambiantes obligan al producto de software a cambiar en consecuencia. Volver a crear software desde cero y ser uno a uno con los requisitos no es factible. La única solución factible y económica es actualizar el software existente para que cumpla con los últimos requisitos.

Leyes de evolución del software Lehman ha dado leyes para la evolución del software. Dividió el software en tres categorías diferentes: 

Tipo S (tipo estático): este es un software que funciona estrictamente de acuerdo con especificaciones y soluciones definidas . La solución y el método para lograrlo, ambos se entienden inmediatamente antes de la codificación. El software de tipo s

está menos sujeto a cambios, por lo tanto, este es el más simple de todos. Por ejemplo, programa de calculadora para cálculo matemático. 

Tipo P (tipo práctico): este es un software con una colección de procedimientos. Esto se define exactamente por lo que pueden hacer los procedimientos. En este software, se pueden describir las especificaciones, pero la solución no es obvia al instante. Por ejemplo, software de juegos.



Tipo E (tipo incrustado): este software funciona estrechamente como un requisito del entorno del mundo real . Este software tiene un alto grado de evolución, ya que hay varios cambios en las leyes, impuestos, etc. en las situaciones del mundo real. Por ejemplo, software de comercio en línea.

Evolución del software E-Type Lehman ha dado ocho leyes para la evolución del software E-Type: 

Cambio continuo: un sistema de software de tipo E debe continuar adaptándose a los cambios del mundo real; de lo contrario, será cada vez menos útil.



Complejidad creciente: a medida que evoluciona un sistema de software de tipo E, su complejidad tiende a aumentar a menos que se trabaje para mantenerlo o reducirlo.



Conservación de la familiaridad: la familiaridad con el software o el conocimiento sobre cómo se desarrolló, por qué se desarrolló de esa manera particular, etc., debe mantenerse a cualquier costo para implementar los cambios en el sistema.



Crecimiento continuo: para un sistema de tipo E destinado a resolver algunos problemas comerciales, su tamaño de implementación de los cambios crece de acuerdo con los cambios en el estilo de vida de la empresa.



Reducción de la calidad: un sistema de software tipo E disminuye su calidad a menos que se mantenga rigurosamente y se adapte a un entorno operativo cambiante.



Sistemas de retroalimentación: los sistemas de software de tipo E constituyen sistemas de retroalimentación de múltiples niveles y múltiples bucles y deben tratarse como tales para ser modificados o mejorados con éxito.



Autorregulación: los procesos de evolución del sistema de tipo E se autorregulan con la distribución de productos y medidas de proceso cercanas a lo normal.



Estabilidad organizacional: la tasa de actividad global efectiva promedio en un sistema de tipo E en evolución es invariable durante la vida útil del producto.

www.postparaprogramadores.com /

Síguenos en Instagram para que estés al tanto de los nuevos libros de programación. Click aqui

Paradigmas de software Los paradigmas de software se refieren a los métodos y pasos que se toman al diseñar el software. Hay muchos métodos propuestos y están en funcionamiento hoy, pero necesitamos ver en qué parte de la ingeniería del software se encuentran estos paradigmas. Estos se pueden combinar en varias categorías, aunque cada una de ellas está contenida entre sí:

El paradigma de programación es un subconjunto del paradigma de diseño de software que además es un subconjunto del paradigma de desarrollo de software.

Paradigma de desarrollo de software Este paradigma se conoce como paradigmas de ingeniería de software donde se aplican todos los conceptos de ingeniería relacionados con el desarrollo de software. Incluye varias investigaciones y recopilación de requisitos que ayudan a construir el producto de software. Consiste en -



Recopilación de requisitos



Diseño de software



Programación

Paradigma de diseño de software Este paradigma es parte del desarrollo de software e incluye:  

Diseño Mantenimiento



Programación

Paradigma de programación Este paradigma está estrechamente relacionado con el aspecto de programación del desarrollo de software. Esto incluye  

Codificación Pruebas



Integración

Necesidad de ingeniería de software La necesidad de la ingeniería de software surge debido a la mayor tasa de cambio en los requisitos del usuario y el entorno en el que está trabajando el software. 

Software grande: es más fácil construir un muro que una casa o edificio, del mismo modo, ya que el tamaño del software se convierte en una gran ingeniería que tiene que avanzar para darle un proceso científico.



Escalabilidad: si el proceso del software no se basara en conceptos científicos y de ingeniería, sería más fácil recrear un nuevo software que escalar uno existente.



Costo: a medida que la industria del hardware ha demostrado sus habilidades y la gran fabricación ha bajado el precio de la computadora y el hardware electrónico. Pero el costo del software sigue siendo alto si no se adapta el proceso adecuado.



Naturaleza dinámica: la naturaleza siempre creciente y adaptable del software depende en gran medida del entorno en el que trabaja el usuario. Si la naturaleza del software siempre está cambiando, se deben realizar nuevas mejoras en la existente. Aquí es donde la ingeniería de software juega un buen papel.



Gestión de calidad: un mejor proceso de desarrollo de software proporciona un producto de software mejor y de calidad.

Características del buen software. Un producto de software se puede juzgar por lo que ofrece y qué tan bien se puede usar. Este software debe satisfacer los siguientes motivos: 

Operacional



Transicional



Mantenimiento

Se espera que el software bien diseñado y diseñado tenga las siguientes características:

Operacional Esto nos dice qué tan bien funciona el software en las operaciones. Se puede medir en: 

Presupuesto



Usabilidad



Eficiencia



Exactitud



Funcionalidad



Confianza



Seguridad La seguridad



Transicional Este aspecto es importante cuando el software se mueve de una plataforma a otra:  

Portabilidad Interoperabilidad



Reusabilidad



Adaptabilidad

Mantenimiento Este aspecto resume qué tan bien un software tiene las capacidades para mantenerse en el entorno siempre cambiante:  

Modularidad Mantenibilidad



Flexibilidad



Escalabilidad

En resumen, la ingeniería de software es una rama de la informática, que utiliza conceptos de ingeniería bien definidos necesarios para producir productos de software eficientes, duraderos, escalables, dentro del presupuesto y a tiempo.

Ciclo de vida del desarrollo de programas

Software Development Life Cycle, SDLC para abreviar, es una secuencia bien estructurada y estructurada de etapas en ingeniería de software para desarrollar el producto de software previsto.

Actividades SDLC SDLC proporciona una serie de pasos a seguir para diseñar y desarrollar un producto de software de manera eficiente. El marco SDLC incluye los siguientes pasos:

Comunicación Este es el primer paso donde el usuario inicia la solicitud de un producto de software deseado. Se pone en contacto con el proveedor de servicios e intenta negociar los términos. Presenta su solicitud a la organización proveedora de servicios por escrito.

Recopilación de requisitos En este paso, el equipo de desarrollo de software trabaja para llevar a cabo el proyecto. El equipo mantiene conversaciones con varias partes interesadas del dominio del problema y trata de sacar tanta información como sea posible sobre sus requisitos. Los requisitos se contemplan y segregan en requisitos de

usuario, requisitos del sistema y requisitos funcionales. Los requisitos se recopilan utilizando una serie de prácticas como se indica: 

estudiando el sistema y el software existentes u obsoletos,



realización de entrevistas a usuarios y desarrolladores,



refiriéndose a la base de datos o



recolectando respuestas de los cuestionarios.

Estudio de factibilidad Después de reunir los requisitos, el equipo elabora un plan aproximado de proceso de software. En este paso, el equipo analiza si se puede hacer que un software cumpla con todos los requisitos del usuario y si existe alguna posibilidad de que el software deje de ser útil. Se descubre si el proyecto es financieramente, práctica y tecnológicamente factible para que la organización lo tome en cuenta. Hay muchos algoritmos disponibles, que ayudan a los desarrolladores a concluir la viabilidad de un proyecto de software.

Análisis del sistema En este paso, los desarrolladores deciden una hoja de ruta de su plan e intentan presentar el mejor modelo de software adecuado para el proyecto. El análisis del sistema incluye la comprensión de las limitaciones del producto de software, los problemas relacionados con el sistema de aprendizaje o los cambios que se deben realizar de antemano en los sistemas existentes, identificar y abordar el impacto del proyecto en la organización y el personal, etc. El equipo del proyecto analiza el alcance del proyecto y planifica el cronograma y recursos en consecuencia.

Diseño de software El siguiente paso es reducir el conocimiento completo de los requisitos y el análisis en el escritorio y diseñar el producto de software. Las entradas de los usuarios y la información recopilada en la fase de recopilación de requisitos son las entradas de este paso. El resultado de este paso viene en forma de dos diseños; Diseño lógico y diseño físico. Los ingenieros producen metadatos y diccionarios de datos, diagramas lógicos, diagramas de flujo de datos y, en algunos casos, pseudocódigos.

Codificación Este paso también se conoce como fase de programación. La implementación del diseño del software comienza en términos de escribir código de programa en el lenguaje de programación adecuado y desarrollar programas ejecutables sin errores de manera eficiente.

Pruebas

Una estimación dice que el 50% de todo el proceso de desarrollo de software debe ser probado. Los errores pueden arruinar el software desde el nivel crítico hasta su propia eliminación. Los desarrolladores realizan las pruebas de software mientras los desarrolladores codifican y los expertos realizan pruebas exhaustivas en varios niveles de código, como pruebas de módulos, pruebas de programas, pruebas de productos, pruebas internas y pruebas del producto al final del usuario. El descubrimiento temprano de errores y su solución es la clave para un software confiable.

Integración Es posible que el software deba integrarse con las bibliotecas, bases de datos y otros programas. Esta etapa de SDLC está involucrada en la integración de software con entidades del mundo exterior.

Implementación Esto significa instalar el software en las máquinas de los usuarios. A veces, el software necesita configuraciones posteriores a la instalación al final del usuario. El software se prueba para portabilidad y adaptabilidad y los problemas relacionados con la integración se resuelven durante la implementación.

Operación y mantenimiento Esta fase confirma la operación del software en términos de mayor eficiencia y menos errores. Si es necesario, los usuarios reciben capacitación o se les ayuda con la documentación sobre cómo operar el software y cómo mantenerlo operativo. El software se mantiene a tiempo actualizando el código de acuerdo con los cambios que tienen lugar en el entorno o la tecnología del usuario final. Esta fase puede enfrentar desafíos de errores ocultos y problemas no identificados del mundo real.

Disposición A medida que transcurre el tiempo, el software puede disminuir en el frente de rendimiento. Puede quedar completamente obsoleto o puede necesitar una intensa actualización. Por lo tanto, surge una necesidad apremiante de eliminar una parte importante del sistema. Esta fase incluye el archivo de datos y los componentes de software necesarios, el cierre del sistema, la planificación de la actividad de disposición y la terminación del sistema en el momento adecuado de finalización del sistema.

Paradigma de desarrollo de software El paradigma de desarrollo de software ayuda al desarrollador a seleccionar una estrategia para desarrollar el software. Un paradigma de desarrollo de software tiene su propio conjunto de herramientas, métodos y procedimientos, que se expresan claramente y definen el ciclo de vida del desarrollo de

software. Algunos de los paradigmas de desarrollo de software o modelos de proceso se definen de la siguiente manera:

Modelo de cascada El modelo de cascada es el modelo más simple del paradigma de desarrollo de software. Dice que todas las fases de SDLC funcionarán una tras otra de manera lineal. Es decir, cuando finaliza la primera fase, solo se iniciará la segunda fase y así sucesivamente.

Este modelo supone que todo se lleva a cabo y se lleva a cabo perfectamente según lo planeado en la etapa anterior y no hay necesidad de pensar en los problemas pasados que pueden surgir en la siguiente fase. Este modelo no funciona sin problemas si quedan algunos problemas en el paso anterior. La naturaleza secuencial del modelo no nos permite regresar y deshacer o rehacer nuestras acciones. Este modelo es más adecuado cuando los desarrolladores ya han diseñado y desarrollado software similar en el pasado y conocen todos sus dominios.

Modelo iterativo Este modelo lidera el proceso de desarrollo de software en iteraciones. Proyecta el proceso de desarrollo de manera cíclica repitiendo cada paso después de cada ciclo del proceso SDLC.

El software se desarrolló primero a muy pequeña escala y se siguen todos los pasos que se tienen en cuenta. Luego, en cada próxima iteración, se diseñan, codifican, prueban y agregan más funciones y módulos al software. Cada ciclo produce un software, que es completo en sí mismo y tiene más características y capacidades que el anterior. Después de cada iteración, el equipo de gestión puede trabajar en la gestión de riesgos y prepararse para la próxima iteración. Debido a que un ciclo incluye una pequeña porción de todo el proceso de software, es más fácil administrar el proceso de desarrollo, pero consume más recursos.

Modelo espiral El modelo espiral es una combinación de ambos, el modelo iterativo y uno del modelo SDLC. Puede verse como si elige un modelo SDLC y lo combina con un proceso cíclico (modelo iterativo).

Este modelo considera el riesgo, que a menudo pasa desapercibido para la mayoría de los otros modelos. El modelo comienza con la determinación de objetivos y limitaciones del software al comienzo de una iteración. La siguiente fase es la creación de prototipos del software. Esto incluye análisis de riesgos. Luego se usa un modelo SDLC estándar para construir el software. En la cuarta fase del plan de la próxima iteración se prepara.

V - modelo El principal inconveniente del modelo de cascada es que pasamos a la siguiente etapa solo cuando la anterior está terminada y no hubo posibilidad de volver si algo se encuentra mal en etapas posteriores. V-Model proporciona medios para probar el software en cada etapa de manera inversa.

En cada etapa, se crean planes de prueba y casos de prueba para verificar y validar el producto de acuerdo con los requisitos de esa etapa. Por ejemplo, en la etapa de recopilación de requisitos, el equipo de prueba prepara todos los casos de prueba en correspondencia con los requisitos. Más tarde, cuando el producto se desarrolla y está listo para la prueba, los casos de prueba de esta etapa verifican el software contra su validez para cumplir con los requisitos en esta etapa. Esto hace que tanto la verificación como la validación vayan en paralelo. Este modelo también se conoce como modelo de verificación y validación.

Modelo Big Bang Este modelo es el modelo más simple en su forma. Requiere poca planificación, mucha programación y muchos fondos. Este modelo está conceptualizado en torno a la gran explosión del universo. Como dicen los científicos, después del Big Bang, muchas galaxias, planetas y estrellas evolucionaron como un evento. Del mismo modo, si reunimos mucha programación y fondos, puede lograr el mejor producto de software.

Para este modelo, se requiere una cantidad muy pequeña de planificación. No sigue ningún proceso o, en ocasiones, el cliente no está seguro de los requisitos y las necesidades futuras. Por lo tanto, los requisitos de entrada son arbitrarios. Este modelo no es adecuado para grandes proyectos de software, pero es bueno para aprender y experimentar. Para una lectura en profundidad sobre SDLC y sus diversos modelos, haga clic aquí.

Gestión de proyectos de software El patrón de trabajo de una empresa de TI dedicada al desarrollo de software puede verse dividido en dos partes:  

Creación de software Gestión de proyectos de software

Un proyecto es una tarea bien definida, que es una colección de varias operaciones realizadas para lograr un objetivo (por ejemplo, desarrollo y entrega de software). Un proyecto puede caracterizarse como: 

Cada proyecto puede tener un objetivo único y distinto.



El proyecto no es una actividad de rutina u operaciones cotidianas.



El proyecto viene con una hora de inicio y una hora de finalización.



El proyecto termina cuando se logra su objetivo, por lo tanto, es una fase temporal en la vida útil de una organización.



El proyecto necesita recursos adecuados en términos de tiempo, mano de obra, finanzas, material y banco de conocimiento.

Proyecto de software Un proyecto de software es el procedimiento completo de desarrollo de software, desde la recopilación de requisitos hasta las pruebas y el mantenimiento, realizado de acuerdo con las metodologías de ejecución, en un período de tiempo específico para lograr el producto de software previsto.

Necesidad de gestión de proyectos de software. Se dice que el software es un producto intangible. El desarrollo de software es una especie de flujo completamente nuevo en los negocios mundiales y hay muy poca experiencia en la creación de productos de software. La mayoría de los productos de software están hechos a medida para satisfacer los requisitos del cliente. Lo más importante es que la tecnología subyacente cambia y avanza con tanta frecuencia y rapidez que la experiencia de un producto puede no aplicarse al otro. Todas estas restricciones comerciales y ambientales conllevan riesgos en el desarrollo de software, por lo tanto, es esencial administrar los proyectos de software de manera eficiente.

La imagen de arriba muestra restricciones triples para proyectos de software. Es una parte esencial de la organización del software entregar productos de calidad, mantener el costo dentro de las restricciones presupuestarias del cliente y entregar el proyecto según lo programado. Hay varios factores, tanto internos como externos, que pueden afectar este triángulo de triple restricción. Cualquiera de los tres factores puede afectar severamente a los otros dos. Por lo tanto, la gestión de proyectos de software es esencial para incorporar los requisitos del usuario junto con las limitaciones de presupuesto y tiempo.

Gerente de proyectos de software Un gerente de proyecto de software es una persona que asume la responsabilidad de ejecutar el proyecto de software. El administrador de proyectos de software conoce perfectamente todas las fases de SDLC por las que pasaría el software. El gerente de proyecto nunca puede involucrarse directamente en la producción del producto final, pero controla y administra las actividades involucradas en la producción. Un gerente de proyecto monitorea de cerca el proceso de desarrollo, prepara y ejecuta varios planes, organiza los recursos necesarios y adecuados, mantiene la comunicación entre todos los miembros del equipo para abordar los problemas de costo, presupuesto, recursos, tiempo, calidad y satisfacción del cliente. Veamos algunas responsabilidades que un gerente de proyecto asume:

La gestión de personas 

Actuar como líder del proyecto



Lesión con partes interesadas



Gestionar recursos humanos



Configuración de jerarquía de informes, etc.

Proyecto de gestión 

Definición y configuración del alcance del proyecto



Gestión de actividades de gestión de proyectos.

 

Monitoreo de progreso y desempeño Análisis de riesgos en cada fase.



Tome las medidas necesarias para evitar o salir de problemas.



Actuar como portavoz del proyecto

Actividades de gestión de software La gestión de proyectos de software consta de una serie de actividades, que incluyen la planificación del proyecto, la determinación del alcance del producto de software, la estimación del costo en varios términos, la programación de tareas y eventos y la gestión de recursos. Las actividades de gestión del proyecto pueden incluir:  

Planificación de proyectos Gestión del alcance



Estimacion del proyecto

Planificación de proyectos La planificación del proyecto de software es una tarea que se realiza antes de que la producción del software realmente comience. Está allí para la producción de software, pero no implica ninguna actividad concreta que tenga ninguna conexión de dirección con la producción de software; más bien es un conjunto de procesos múltiples, que facilita la producción de software. La planificación del proyecto puede incluir lo siguiente:

Gestión del alcance Define el alcance del proyecto; Esto incluye todas las actividades, el proceso debe hacerse para hacer un producto de software entregable. La gestión del alcance es esencial porque crea límites del proyecto al definir claramente lo que se haría en el proyecto y lo que no se haría. Esto hace que el proyecto contenga tareas limitadas y cuantificables, que pueden documentarse fácilmente y, a su vez, evita la sobrecarga de costos y tiempo. Durante la gestión del alcance del proyecto, es necesario:



Definir el alcance



Decidir su verificación y control



Divida el proyecto en varias partes más pequeñas para facilitar la administración.



Verificar el alcance



Controle el alcance incorporando cambios al alcance

Estimacion del proyecto Para una gestión efectiva es imprescindible una estimación precisa de varias medidas. Con una estimación correcta, los gerentes pueden administrar y controlar el proyecto de manera más eficiente y efectiva. La estimación del proyecto puede incluir lo siguiente: 

Estimación del tamaño del software. El tamaño del software puede estimarse en términos de KLOC (Kilo Line of Code) o calculando el número de puntos de función en el software. Las líneas de código dependen de las prácticas de codificación y los puntos de función varían según los requisitos del usuario o del software.



Estimación de esfuerzo Los gerentes estiman los esfuerzos en términos de requisitos de personal y horas hombre requeridas para producir el software. Para la estimación del esfuerzo, se debe conocer el tamaño del software. Esto puede derivarse de la experiencia de los gerentes, los datos históricos de la organización o el tamaño del software se pueden convertir en esfuerzos mediante el uso de algunas fórmulas estándar.



Estimación del tiempo Una vez que se estiman el tamaño y los esfuerzos, se puede estimar el tiempo requerido para producir el software. Los esfuerzos requeridos se segregan en subcategorías según las especificaciones de requisitos y la interdependencia de varios componentes de software. Las tareas de software se dividen en tareas, actividades o eventos más pequeños por Work Breakthrough Structure (WBS). Las tareas se programan día a día o en meses calendario. La suma de tiempo requerida para completar todas las tareas en horas o días es el tiempo total invertido para completar el proyecto.



Estimación de costos Esto podría considerarse como el más difícil de todos porque depende de más elementos que cualquiera de los anteriores. Para estimar el costo del proyecto, se requiere considerar: o

o

Tamaño del software Calidad del software Hardware Software o herramientas adicionales, licencias, etc. Personal calificado con habilidades específicas de la tarea. Viajes involucrados

o

Comunicación

o o o o

o

Entrenamiento y apoyo

Técnicas de estimación de proyectos Discutimos varios parámetros relacionados con la estimación del proyecto, como el tamaño, el esfuerzo, el tiempo y el costo. El gerente de proyecto puede estimar los factores enumerados utilizando dos técnicas ampliamente reconocidas:

Técnica de descomposición Esta técnica asume el software como producto de varias composiciones. Hay dos modelos principales: 

La estimación de la línea de código se realiza en nombre del número de líneas de códigos en el producto de software.



La estimación de puntos de función se realiza en nombre del número de puntos de función en el producto de software.

Técnica de estimación empírica Esta técnica utiliza fórmulas derivadas empíricamente estimaciones. Estas fórmulas se basan en LOC o FP. 

para

hacer

Modelo de Putnam Este modelo está hecho por Lawrence H. Putnam, que se basa en la distribución de frecuencia de Norden (curva de Rayleigh). El modelo de Putnam asigna el tiempo y los esfuerzos necesarios con el tamaño del software.



COCOMO COCOMO significa COnstructive COst MOdel, desarrollado por Barry W. Boehm. Divide el producto de software en tres categorías de software: orgánico, semi-separado e integrado.

Programación de proyectos La programación del proyecto en un proyecto se refiere a la hoja de ruta de todas las actividades que se realizarán con el orden especificado y dentro del intervalo de tiempo asignado a cada actividad. Los gerentes de proyecto tienden a definir varias tareas y a proyectar hitos y organizarlos teniendo en cuenta varios factores. Buscan tareas que se encuentran en una ruta crítica en el cronograma, que son necesarias para completar de manera específica (debido a la interdependencia de la tarea) y estrictamente dentro del tiempo asignado. La disposición de las tareas que se encuentra fuera de la ruta crítica tiene menos probabilidades de impactar en todo el cronograma del proyecto. Para programar un proyecto, es necesario: 

Divide las tareas del proyecto en una forma más pequeña y manejable



Descubre varias tareas y correlacionalas



Estimación del tiempo requerido para cada tarea



Divida el tiempo en unidades de trabajo.



Asigne un número adecuado de unidades de trabajo para cada tarea.



Calcular el tiempo total requerido para el proyecto de principio a fin

Administracion de recursos Todos los elementos utilizados para desarrollar un producto de software pueden asumirse como recursos para ese proyecto. Esto puede incluir recursos humanos, herramientas productivas y bibliotecas de software. Los recursos están disponibles en cantidad limitada y permanecen en la organización como un conjunto de activos. La escasez de recursos dificulta el desarrollo del proyecto y puede retrasarse con respecto al cronograma. La asignación de recursos adicionales aumenta el costo de desarrollo al final. Por lo tanto, es necesario estimar y asignar recursos adecuados para el proyecto. La gestión de recursos incluye: 

Definir el proyecto de organización adecuado creando un equipo de proyecto y asignando responsabilidades a cada miembro del equipo



Determinar los recursos requeridos en una etapa particular y su disponibilidad



Administre los recursos generando solicitudes de recursos cuando sean necesarios y desasignándolos cuando ya no sean necesarios.

Proyecto de Gestión de Riesgos La gestión de riesgos implica todas las actividades relacionadas con la identificación, el análisis y la provisión de riesgos predecibles y no predecibles en el proyecto. El riesgo puede incluir lo siguiente:  

Personal experimentado que abandona el proyecto y que entra personal nuevo. Cambio en la gestión organizacional.



Cambio de requisito o requisito de interpretación errónea.



Subestimación del tiempo y los recursos requeridos.



Cambios tecnológicos, cambios ambientales, competencia empresarial.

Proceso de gestión de riesgos Existen las siguientes actividades involucradas en el proceso de gestión de riesgos: 

Identificación: tome nota de todos los riesgos posibles que pueden ocurrir en el proyecto.



Categorizar: clasifique los riesgos conocidos en intensidad de riesgo alta, media y baja según su posible impacto en el proyecto.



Administrar: analiza la probabilidad de ocurrencia de riesgos en varias fases. Haga un plan para evitar o enfrentar riesgos. Intenta minimizar sus efectos secundarios.



Supervisar: controle de cerca los riesgos potenciales y sus síntomas iniciales. También controle los efectos de los pasos tomados para mitigarlos o evitarlos.

Ejecución y Monitoreo de Proyectos En esta fase, las tareas descritas en los planes del proyecto se ejecutan de acuerdo con sus cronogramas. La ejecución necesita monitoreo para verificar si todo va de acuerdo con el plan. Monitorear es observar para verificar la probabilidad de riesgo y tomar medidas para abordar el riesgo o informar el estado de varias tareas. Estas medidas incluyen: 

Monitoreo de actividad: todas las actividades programadas dentro de alguna tarea se pueden monitorear día a día. Cuando se completan todas las actividades de una tarea, se considera completa.



Informes de estado: los informes contienen el estado de las actividades y tareas completadas dentro de un período de tiempo determinado, generalmente una semana. El estado se puede marcar como terminado, pendiente o en progreso, etc.



Lista de verificación de hitos: cada proyecto se divide en múltiples fases en las que se realizan tareas principales (hitos) según las fases de SDLC. Esta lista de verificación de hitos se prepara una vez cada pocas semanas e informa el estado de los hitos.

Gestión de comunicación de proyectos La comunicación efectiva juega un papel vital en el éxito de un proyecto. Cierra las brechas entre el cliente y la organización, entre los miembros del equipo y otros interesados en el proyecto, como los proveedores de hardware. La comunicación puede ser oral o escrita. El proceso de gestión de la comunicación puede tener los siguientes pasos: 

Planificación : este paso incluye las identificaciones de todos los interesados en el proyecto y el modo de comunicación entre ellos. También considera si se requieren medios de comunicación adicionales.



Compartir : después de determinar varios aspectos de la planificación, el gerente se enfoca en compartir la información correcta con la persona correcta en el momento correcto. Esto mantiene a todos los involucrados en el proyecto actualizados con el progreso del proyecto y su estado.



Comentarios : los gerentes de proyectos utilizan diversas medidas y mecanismos de comentarios y crean informes de estado y rendimiento. Este mecanismo asegura que las aportaciones de varios interesados lleguen al gerente del proyecto como su retroalimentación.



Cierre : al final de cada evento importante, al final de una fase de SDLC o al final del proyecto en sí, se anuncia formalmente el cierre administrativo para actualizar

a todas las partes interesadas mediante el envío de un correo electrónico, la distribución de una copia impresa del documento o por otro medio de comunicación efectiva.

Después del cierre, el equipo pasa a la siguiente fase o proyecto.

Gestión de la configuración La gestión de la configuración es un proceso de seguimiento y control de los cambios en el software en términos de requisitos, diseño, funciones y desarrollo del producto. IEEE lo define como "el proceso de identificar y definir los elementos en el sistema, controlar el cambio de estos elementos a lo largo de su ciclo de vida, registrar e informar el estado de los elementos y las solicitudes de cambio, y verificar la integridad y corrección de los elementos". En general, una vez que se finaliza el SRS, hay menos posibilidades de que el usuario requiera cambios. Si ocurren, los cambios se abordan solo con la aprobación previa de la alta gerencia, ya que existe la posibilidad de que se sobrepasen los costos y el tiempo.

Base Se asume una fase de SDLC si está en línea de base, es decir, la línea de base es una medida que define la integridad de una fase. Una fase se establece como base cuando todas las actividades correspondientes están terminadas y bien documentadas. Si no fuera la fase final, su salida se usaría en la siguiente fase inmediata. La gestión de la configuración es una disciplina de administración de la organización, que se encarga de la ocurrencia de cualquier cambio (proceso, requerimiento, tecnológico, estratégico, etc.) después de que se base una fase. CM mantiene el control de cualquier cambio realizado en el software.

Cambio de control El control de cambios es función de la gestión de la configuración, lo que garantiza que todos los cambios realizados en el sistema de software sean coherentes y se realicen de acuerdo con las normas y reglamentos de la organización. Un cambio en la configuración del producto pasa por los siguientes pasos: 

Identificación : una solicitud de cambio llega desde una fuente interna o externa. Cuando la solicitud de cambio se identifica formalmente, se documenta adecuadamente.



Validación : se verifica la validez de la solicitud de cambio y se confirma su procedimiento de manejo.



Análisis : el impacto de la solicitud de cambio se analiza en términos de cronograma, costo y esfuerzos requeridos. Se analiza el impacto general del posible cambio en el sistema.



Control : si el posible cambio afecta a demasiadas entidades en el sistema o es inevitable, es obligatorio obtener la aprobación de las altas autoridades antes de incorporar el cambio en el sistema. Se decide si vale la pena incorporar el cambio o no. Si no es así, la solicitud de cambio se rechaza formalmente.



Ejecución : si la fase anterior determina ejecutar la solicitud de cambio, esta fase toma las medidas apropiadas para ejecutar el cambio, realiza una revisión exhaustiva si es necesario.



Cerrar solicitud : el cambio se verifica para una correcta implementación y fusión con el resto del sistema. Este cambio recientemente incorporado en el software se documenta adecuadamente y la solicitud se cierra formalmente.

Herramientas de gestión de proyectos El riesgo y la incertidumbre se multiplican con respecto al tamaño del proyecto, incluso cuando el proyecto se desarrolla de acuerdo con las metodologías establecidas. Hay herramientas disponibles, que ayudan a la gestión eficaz del proyecto. Algunos se describen:

Gráfico de gantt Los diagramas de Gantt fueron ideados por Henry Gantt (1917). Representa el cronograma del proyecto con respecto a los períodos de tiempo. Es un gráfico de barras horizontales con barras que representan actividades y tiempo programado para las actividades del proyecto.

Gráfico PERT El gráfico PERT (técnica de evaluación y revisión del programa) es una herramienta que representa el proyecto como diagrama de red. Es capaz de representar gráficamente los principales eventos del proyecto en forma paralela y consecutiva. Los eventos, que ocurren uno tras otro, muestran dependencia del evento posterior con respecto al anterior.

Los eventos se muestran como nodos numerados. Están conectados por flechas etiquetadas que representan la secuencia de tareas en el proyecto.

Histograma de recursos Esta es una herramienta gráfica que contiene barras o gráficos que representan la cantidad de recursos (generalmente personal calificado) necesarios a lo largo del tiempo para un evento (o fase) del proyecto. El histograma de recursos es una herramienta eficaz para la planificación y coordinación del personal.

Análisis de ruta crítica

Esta herramienta es útil para reconocer tareas interdependientes en el proyecto. También ayuda a encontrar la ruta más corta o la ruta crítica para completar el proyecto con éxito. Al igual que el diagrama PERT, a cada evento se le asigna un marco de tiempo específico. Esta herramienta muestra la dependencia del evento asumiendo que un evento puede pasar al siguiente solo si se completa el anterior. Los eventos se organizan de acuerdo con la hora de inicio más temprana posible. La ruta entre el nodo inicial y el final es una ruta crítica que no se puede reducir aún más y todos los eventos deben ejecutarse en el mismo orden.

Requisitos de Software Los requisitos de software son una descripción de las características y funcionalidades del sistema de destino. Los requisitos transmiten las expectativas de los usuarios del producto de software. Los requisitos pueden ser obvios u ocultos, conocidos o desconocidos, esperados o inesperados desde el punto de vista del cliente.

Ingeniería de requisitos El proceso para reunir los requisitos de software del cliente, analizarlos y documentarlos se conoce como ingeniería de requisitos. El objetivo de la ingeniería de requisitos es desarrollar y mantener un documento sofisticado y descriptivo de 'Especificación de requisitos del sistema'.

Proceso de ingeniería de requisitos Es un proceso de cuatro pasos, que incluye:  

Estudio de factibilidad Recopilación de requisitos



Especificación de requisitos de software



Validación de requisitos de software

Veamos el proceso brevemente:

Estudio de factibilidad Cuando el cliente se acerca a la organización para desarrollar el producto deseado, se le ocurre una idea aproximada sobre qué funciones debe realizar el software y qué características se esperan del software. En referencia a esta información, los analistas hacen un estudio detallado sobre si el sistema deseado y su funcionalidad son factibles de desarrollar. Este estudio de viabilidad está enfocado hacia el objetivo de la organización. Este estudio analiza si el producto de software puede

materializarse prácticamente en términos de implementación, contribución del proyecto a la organización, limitaciones de costos y según los valores y objetivos de la organización. Explora aspectos técnicos del proyecto y el producto, tales como usabilidad, mantenibilidad, productividad y capacidad de integración. El resultado de esta fase debe ser un informe de estudio de factibilidad que debe contener comentarios y recomendaciones adecuadas para la administración sobre si el proyecto debe llevarse a cabo o no.

Recopilación de requisitos Si el informe de viabilidad es positivo para emprender el proyecto, la siguiente fase comienza con la recopilación de los requisitos del usuario. Los analistas e ingenieros se comunican con el cliente y los usuarios finales para conocer sus ideas sobre qué debe proporcionar el software y qué características desean que incluya el software.

Especificación de requisitos de software SRS es un documento creado por el analista de sistemas después de que se recopilan los requisitos de varias partes interesadas. SRS define cómo el software previsto interactuará con el hardware, las interfaces externas, la velocidad de operación, el tiempo de respuesta del sistema, la portabilidad del software en varias plataformas, la capacidad de mantenimiento, la velocidad de recuperación después de un bloqueo, la seguridad, la calidad, las limitaciones, etc. Los requisitos recibidos del cliente están escritos en lenguaje natural. Es responsabilidad del analista de sistemas documentar los requisitos en lenguaje técnico para que puedan ser comprendidos y útiles por el equipo de desarrollo de software. SRS debería tener las siguientes características: 

Los requisitos del usuario se expresan en lenguaje natural.

 

Los requisitos técnicos se expresan en lenguaje estructurado, que se utiliza dentro de la organización. La descripción del diseño debe escribirse en pseudocódigo.



Formato de formularios e impresiones de pantalla GUI.



Notaciones condicionales y matemáticas para DFD, etc.

Validación de requisitos de software Después de desarrollar las especificaciones de requisitos, los requisitos mencionados en este documento se validan. El usuario puede solicitar una solución ilegal y poco práctica o los expertos pueden interpretar los requisitos incorrectamente. Esto resulta en un gran aumento en el costo si no se corta de raíz. Los requisitos pueden verificarse contra las siguientes condiciones:



Si se pueden implementar prácticamente



Si son válidos y según la funcionalidad y el dominio del software



Si hay alguna ambigüedad



Si están completos



Si se pueden demostrar

Proceso de obtención de requisitos El proceso de obtención de requisitos se puede representar utilizando el siguiente diagrama:



Recopilación de requisitos: los desarrolladores discuten con el cliente y los usuarios finales y conocen sus expectativas del software.



Requisitos de organización: los desarrolladores priorizan y organizan los requisitos en orden de importancia, urgencia y conveniencia.



Negociación y discusión: si los requisitos son ambiguos o existen algunos conflictos en los requisitos de varias partes interesadas, si lo son, se negocia y discute con las partes interesadas. Los requisitos pueden entonces ser priorizados y razonablemente comprometidos. Los requisitos provienen de varias partes interesadas. Para eliminar la ambigüedad y los conflictos, se discuten para mayor claridad y corrección. Los requisitos poco realistas se ven comprometidos razonablemente.



Documentación: todos los requisitos formales e informales, funcionales y no funcionales se documentan y se ponen a disposición para el procesamiento de la próxima fase.

Técnicas de obtención de requisitos La obtención de requisitos es el proceso para conocer los requisitos para un sistema de software previsto mediante la comunicación con el cliente, los usuarios finales, los usuarios del sistema y otras personas interesadas en el desarrollo del sistema de software. Hay varias formas de descubrir los requisitos.

Entrevistas Las entrevistas son un medio fuerte para recopilar los requisitos. La organización puede realizar varios tipos de entrevistas, tales como: 

Las entrevistas estructuradas (cerradas), donde cada información que se reúne se decide de antemano, siguen firmemente el patrón y el tema de discusión.



Entrevistas no estructuradas (abiertas), donde la información para recopilar no se decide de antemano, es más flexible y menos sesgada.



Entrevistas orales



Entrevistas escritas



Entrevistas individuales que se realizan entre dos personas al otro lado de la mesa.



Entrevistas grupales que se realizan entre grupos de participantes. Ayudan a descubrir cualquier requisito faltante ya que muchas personas están involucradas.

Encuestas La organización puede realizar encuestas entre varias partes interesadas mediante consultas sobre sus expectativas y requisitos del próximo sistema.

Cuestionarios Se entrega a todas las partes interesadas un documento con un conjunto predefinido de preguntas objetivas y opciones respectivas para que respondan, que se recopilan y compilan. Una deficiencia de esta técnica es que, si una opción para algún problema no se menciona en el cuestionario, el problema podría dejarse desatendido.

Análisis de tareas El equipo de ingenieros y desarrolladores puede analizar la operación para la cual se requiere el nuevo sistema. Si el cliente ya tiene algún software para realizar cierta operación, se estudia y se recopilan los requisitos del sistema propuesto.

Análisis de dominio Todo software pertenece a alguna categoría de dominio. Las personas expertas en el dominio pueden ser de gran ayuda para analizar requisitos generales y específicos.

Lluvia de ideas Se lleva a cabo un debate informal entre las diversas partes interesadas y todos sus aportes se registran para un análisis de requisitos adicional.

Prototipos La creación de prototipos está construyendo una interfaz de usuario sin agregar funcionalidad detallada para que el usuario interprete las características del producto de software previsto. Ayuda a dar una mejor idea de los requisitos. Si no hay un software instalado en el extremo del cliente para referencia del desarrollador y el cliente no conoce sus propios requisitos, el desarrollador crea un prototipo basado en los requisitos mencionados inicialmente. El prototipo se muestra al cliente y se anota la retroalimentación. La retroalimentación del cliente sirve como entrada para la recopilación de requisitos.

Observación

Un equipo de expertos visita la organización o el lugar de trabajo del cliente. Observan el funcionamiento real de los sistemas instalados existentes. Observan el flujo de trabajo al final del cliente y cómo se tratan los problemas de ejecución. El equipo mismo saca algunas conclusiones que ayudan a formar los requisitos esperados del software.

Características de los requisitos de software La recopilación de requisitos de software es la base de todo el proyecto de desarrollo de software. Por lo tanto, deben ser claros, correctos y bien definidos. Las especificaciones de requisitos de software completas deben ser: 

Claro



Correcto



Consistente



Coherente



Comprensible



Modificable



Verifiable



Priorizado



Inequívoco



Trazable Fuente creíble



Requisitos de Software Deberíamos tratar de entender qué tipo de requisitos pueden surgir en la fase de obtención de requisitos y qué tipos de requisitos se esperan del sistema de software. En términos generales, los requisitos de software deben clasificarse en dos categorías:

Requerimientos funcionales Los requisitos relacionados con el aspecto funcional del software entran en esta categoría. Definen funciones y funcionalidades dentro y desde el sistema de software. Ejemplos  

Opción de búsqueda dada al usuario para buscar desde varias facturas. El usuario debe poder enviar cualquier informe a la gerencia.



Los usuarios pueden dividirse en grupos y los grupos pueden recibir derechos separados.



Debe cumplir con las normas comerciales y las funciones administrativas.



El software se desarrolla manteniendo intacta la compatibilidad con versiones anteriores.

Requerimientos no funcionales Los requisitos, que no están relacionados con el aspecto funcional del software, entran en esta categoría. Son características implícitas o esperadas del software, que los usuarios suponen. Los requisitos no funcionales incluyen: 

Seguridad



Inicio sesión



Almacenamiento



Configuración



Actuación



Costo



Interoperabilidad



Flexibilidad



Recuperación de desastres Accesibilidad



Los requisitos se clasifican lógicamente como 

Debe tener : El software no puede decirse operativo sin ellos.



Debería : Mejorar la funcionalidad del software.



Podría haber : El software todavía puede funcionar correctamente con estos requisitos. Lista de deseos : estos requisitos no corresponden a ningún objetivo del software.



Mientras se desarrolla el software, 'Debe tener' debe implementarse, 'Debería tener' es un tema de debate con las partes interesadas y la negación, mientras que 'podría tener' y 'lista de deseos' pueden mantenerse para actualizaciones de software.

Requisitos de interfaz de usuario La interfaz de usuario es una parte importante de cualquier software o hardware o sistema híbrido. Un software es ampliamente aceptado si es    

fácil de operar respuesta rápida manejo efectivo de errores operacionales proporcionando una interfaz de usuario simple pero consistente

La aceptación del usuario depende en gran medida de cómo puede usar el software. La IU es la única forma en que los usuarios perciben el sistema. Un sistema de software que funcione bien también debe estar equipado con una interfaz de usuario atractiva, clara, consistente y receptiva. De lo contrario, las funcionalidades del sistema de software no se pueden utilizar de manera

conveniente. Se dice que un sistema es bueno si proporciona medios para usarlo eficientemente. Los requisitos de la interfaz de usuario se mencionan brevemente a continuación: 

Presentación del contenido



Navegación fácil



Interfaz simple



Sensible



Elementos de IU consistentes



Mecanismo de retroalimentación



Configuración por defecto



Diseño intencionado



Uso estratégico de color y textura.



Proporcionar información de ayuda



Enfoque centrado en el usuario



Configuración de vista basada en grupos.

Analista de sistemas de software El analista de sistemas en una organización de TI es una persona que analiza los requisitos del sistema propuesto y garantiza que los requisitos se conciban y documenten de manera correcta y correcta. El rol de un analista comienza durante la Fase de Análisis de Software de SDLC. Es responsabilidad del analista asegurarse de que el software desarrollado cumpla con los requisitos del cliente. Los analistas de sistemas tienen las siguientes responsabilidades:  

Análisis y comprensión de los requisitos del software previsto. Comprender cómo contribuirá el proyecto en los objetivos de la organización



Identificar fuentes de requerimiento

 

Validación de requerimiento Desarrollar e implementar un plan de gestión de requisitos.



Documentación de los requisitos comerciales, técnicos, de proceso y de producto.



Coordinación con los clientes para priorizar requisitos y eliminar y ambigüedad.



Finalizar los criterios de aceptación con el cliente y otras partes interesadas.

Métricas y medidas de software Las medidas de software pueden entenderse como un proceso de cuantificación y simbolización de varios atributos y aspectos del software. Las métricas de software proporcionan medidas para varios aspectos del proceso de software y el producto de software. Las medidas de software son requisitos fundamentales de la ingeniería de software. No solo ayudan a controlar el proceso de desarrollo de software, sino que también ayudan a mantener excelente la calidad del producto final.

Según Tom DeMarco, un (Ingeniero de software), "No puede controlar lo que no puede medir". Por su dicho, está muy claro cuán importantes son las medidas de software. Veamos algunas métricas de software: 

Medidas del tamaño: LOC (líneas de código), calculadas principalmente en miles de líneas de código fuente entregadas, denotadas como KLOC. Function Point Count es una medida de la funcionalidad proporcionada por el software. El recuento de puntos de función define el tamaño del aspecto funcional del software.



Métrica de complejidad: la complejidad ciclomática de McCabe cuantifica el límite superior del número de rutas independientes en un programa, que se percibe como la complejidad del programa o sus módulos. Se representa en términos de conceptos de teoría de grafos mediante el uso de gráficos de flujo de control.



Métricas de calidad: los defectos, sus tipos y causas, las consecuencias, la intensidad de la gravedad y sus implicaciones definen la calidad del producto. El número de defectos encontrados en el proceso de desarrollo y el número de defectos informados por el cliente después de que el producto se instala o entrega al final del cliente, definen la calidad del producto.



Métricas de proceso: en varias fases de SDLC, los métodos y herramientas utilizados, los estándares de la compañía y el desempeño del desarrollo son métricas de proceso de software.



Métricas de recursos: el esfuerzo, el tiempo y los diversos recursos utilizados representan métricas para la medición de recursos.

Conceptos básicos de diseño de software El diseño de software es un proceso para transformar los requisitos del usuario en una forma adecuada, que ayuda al programador en la codificación e implementación del software. Para evaluar los requisitos del usuario, se crea un documento SRS (Especificación de requisitos de software), mientras que para la codificación y la implementación, se necesitan requisitos más específicos y detallados en términos de software. El resultado de este proceso se puede utilizar directamente en la implementación en lenguajes de programación. El diseño de software es el primer paso en SDLC (Software Design Life Cycle), que mueve la concentración del dominio del problema al dominio de la solución. Intenta especificar cómo cumplir los requisitos mencionados en SRS.

Niveles de diseño de software El diseño de software produce tres niveles de resultados: 

Diseño arquitectónico: el diseño arquitectónico es la versión abstracta más alta del sistema. Identifica el software como un sistema con muchos componentes que interactúan entre sí. En este nivel, los diseñadores tienen la idea del dominio de la solución propuesta.



De alto nivel Design- Los de alto nivel se rompe diseño el 'solo componente entidad de múltiples' concepto de diseño arquitectónico a la vista menos abstraído de los subsistemas y módulos y representa su interacción entre sí. El diseño de alto nivel se centra en cómo el sistema junto con todos sus componentes se pueden implementar en forma de módulos. Reconoce la estructura modular de cada subsistema y su relación e interacción entre sí.



Detalla Diseño- ofertas de diseño detallado con la parte de implementación de lo que se ve como un sistema y sus subsistemas en los dos diseños anteriores. Es más detallado para los módulos y sus implementaciones. Define la estructura lógica de cada módulo y sus interfaces para comunicarse con otros módulos.

Modularización La modularización es una técnica para dividir un sistema de software en múltiples módulos discretos e independientes, que se espera que sean capaces de realizar tareas de forma independiente. Estos módulos pueden funcionar como construcciones básicas para todo el software. Los diseñadores tienden a diseñar módulos de manera que puedan ejecutarse y / o compilarse por separado e independientemente. El diseño modular sigue involuntariamente las reglas de la estrategia de resolución de problemas 'divide y vencerás', esto se debe a que hay muchos otros beneficios asociados con el diseño modular de un software. Ventaja de modularización: 

Los componentes más pequeños son más fáciles de mantener.



El programa se puede dividir en función de aspectos funcionales.



El nivel deseado de abstracción se puede traer al programa



Los componentes con alta cohesión pueden reutilizarse nuevamente



La ejecución concurrente puede ser posible



Deseado desde el aspecto de seguridad

Concurrencia En el pasado, todo el software debe ejecutarse secuencialmente. Por ejecución secuencial queremos decir que la instrucción codificada se ejecutará una tras otra, lo que implica que solo una parte del programa se activará en un momento dado. Digamos que un software tiene múltiples módulos, entonces solo uno de todos los módulos se puede encontrar activo en cualquier momento de ejecución. En el diseño de software, la concurrencia se implementa dividiendo el software en múltiples unidades independientes de ejecución, como módulos, y ejecutándolos en paralelo. En otras palabras, la concurrencia proporciona capacidad al software para ejecutar más de una parte del código en paralelo entre sí. Es necesario que los programadores y diseñadores reconozcan esos módulos, que pueden ejecutarse en paralelo.

Ejemplo La función de corrección ortográfica en el procesador de textos es un módulo de software que se ejecuta junto con el procesador de textos.

Acoplamiento y Cohesión Cuando un programa de software se modulariza, sus tareas se dividen en varios módulos en función de algunas características. Como sabemos, los módulos son un conjunto de instrucciones juntas para lograr algunas tareas. Sin embargo, se consideran como una entidad única, pero pueden referirse entre sí para trabajar juntas. Existen medidas por las cuales se puede medir la calidad de un diseño de módulos y su interacción entre ellos. Estas medidas se llaman acoplamiento y cohesión.

Cohesión La cohesión es una medida que define el grado de intradependencia dentro de los elementos de un módulo. Cuanto mayor es la cohesión, mejor es el diseño del programa. Hay siete tipos de cohesión, a saber: 

Cohesión coincidente: es una cohesión no planificada y aleatoria, que podría ser el resultado de dividir el programa en módulos más pequeños en aras de la modularización. Debido a que no es planeado, puede causar confusión a los programadores y generalmente no es aceptado.



Cohesión lógica: cuando los elementos categorizados lógicamente se unen en un módulo, se llama cohesión lógica.



Cohesión emporal: cuando los elementos del módulo se organizan de manera que se procesan en un punto similar en el tiempo, se denomina cohesión temporal.



Cohesión de procedimiento: cuando los elementos del módulo se agrupan, que se ejecutan secuencialmente para realizar una tarea, se denomina cohesión de procedimiento.



Cohesión comunicacional: cuando los elementos del módulo se agrupan, que se ejecutan secuencialmente y funcionan en los mismos datos (información), se denomina cohesión comunicacional.



Cohesión secuencial: cuando los elementos del módulo se agrupan porque la salida de un elemento sirve como entrada para otro y así sucesivamente, se denomina cohesión secuencial.



Cohesión funcional: se considera el mayor grado de cohesión, y es muy esperado. Los elementos del módulo en cohesión funcional se agrupan porque todos contribuyen a una única función bien definida. También se puede reutilizar.

Acoplamiento El acoplamiento es una medida que define el nivel de interdependencia entre los módulos de un programa. Indica a qué nivel los módulos interfieren e interactúan entre sí. Cuanto más bajo sea el acoplamiento, mejor será el programa.

Hay cinco niveles de acoplamiento, a saber: 

Acoplamiento de contenido: cuando un módulo puede acceder directamente o modificar o hacer referencia al contenido de otro módulo, se denomina acoplamiento de nivel de contenido.



Acoplamiento común: cuando varios módulos tienen acceso de lectura y escritura a algunos datos globales, se denomina acoplamiento común o global.



Control de acoplamiento: dos módulos se denominan control acoplado si uno de ellos decide la función del otro módulo o cambia su flujo de ejecución.



Acoplamiento de sello: cuando varios módulos comparten una estructura de datos común y trabajan en diferentes partes, se denomina acoplamiento de sello.



Acoplamiento de datos: el acoplamiento de datos es cuando dos módulos interactúan entre sí mediante el paso de datos (como parámetro). Si un módulo pasa la estructura de datos como parámetro, el módulo receptor debe usar todos sus componentes.

Idealmente, ningún acoplamiento se considera el mejor.

Verificación de diseño La salida del proceso de diseño de software es documentación de diseño, pseudocódigos, diagramas lógicos detallados, diagramas de proceso y una descripción detallada de todos los requisitos funcionales o no funcionales. La siguiente fase, que es la implementación del software, depende de todos los resultados mencionados anteriormente. Entonces es necesario verificar la salida antes de pasar a la siguiente fase. Cuanto antes se detecte cualquier error, mejor será o podría no detectarse hasta que se pruebe el producto. Si los resultados de la fase de diseño están en forma de notación formal, entonces se deben usar sus herramientas asociadas para la verificación; de lo contrario, se puede usar una revisión exhaustiva del diseño para la verificación y validación. Mediante el enfoque de verificación estructurada, los revisores pueden detectar defectos que podrían ser causados por pasar por alto algunas condiciones. Una buena revisión de diseño es importante para un buen diseño de software, precisión y calidad.

Análisis de software y herramientas de diseño El análisis y diseño de software incluye todas las actividades, que ayudan a la transformación de la especificación de requisitos en implementación. Las especificaciones de requisitos especifican todas las expectativas funcionales y no funcionales del software. Estas especificaciones de requisitos vienen en forma de documentos legibles y comprensibles para el ser humano, para los cuales una computadora no tiene nada que hacer. El análisis y diseño de software es la etapa intermedia, que ayuda a transformar los requisitos legibles por humanos en código real.

Veamos algunas herramientas de análisis y diseño utilizadas por los diseñadores de software:

Diagrama de flujo de datos El diagrama de flujo de datos es una representación gráfica del flujo de datos en un sistema de información. Es capaz de representar el flujo de datos entrantes, el flujo de datos salientes y los datos almacenados. El DFD no menciona nada sobre cómo fluyen los datos a través del sistema. Hay una diferencia prominente entre DFD y Diagrama de flujo. El diagrama de flujo muestra el flujo de control en los módulos del programa. Los DFD representan el flujo de datos en el sistema en varios niveles. DFD no contiene ningún control o elementos de ramificación.

Tipos de DFD Los diagramas de flujo de datos son lógicos o físicos. 

DFD lógico : este tipo de DFD se concentra en el proceso del sistema y el flujo de datos en el sistema. Por ejemplo, en un sistema de software bancario, cómo se mueven los datos entre diferentes entidades.



DFD físico : este tipo de DFD muestra cómo se implementa realmente el flujo de datos en el sistema. Es más específico y cercano a la implementación.

Componentes DFD El DFD puede representar el origen, el destino, el almacenamiento y el flujo de datos utilizando el siguiente conjunto de componentes:



Entidades : las entidades son el origen y el destino de los datos de información. Las entidades están representadas por rectángulos con sus respectivos nombres.



Proceso : las actividades y acciones tomadas en los datos están representadas por rectángulos circulares o de bordes redondeados.



Almacenamiento de datos : hay dos variantes de almacenamiento de datos: puede representarse como un rectángulo con ausencia de ambos lados más pequeños o como un rectángulo abierto con un solo lado faltante.



Flujo de datos : el movimiento de los datos se muestra mediante flechas puntiagudas. El movimiento de datos se muestra desde la base de la flecha como su fuente hacia la punta de la flecha como destino.

Niveles de DFD 

Nivel 0 : el nivel más alto de abstracción DFD se conoce como Nivel 0 DFD, que representa todo el sistema de información como un diagrama que oculta todos los

detalles subyacentes. Los DFD de nivel 0 también se conocen como DFD de nivel de contexto.



Nivel 1 : el DFD de nivel 0 se desglosa en DFD de nivel 1 más específico. El Nivel 1 DFD representa los módulos básicos en el sistema y el flujo de datos entre varios módulos. El Nivel 1 DFD también menciona procesos básicos y fuentes de información.



Nivel 2 : en este nivel, DFD muestra cómo fluyen los datos dentro de los módulos mencionados en el Nivel 1. Los DFD de nivel superior se pueden transformar en DFD de nivel inferior más específicos con un nivel de comprensión más profundo a menos que se logre el nivel de especificación deseado.

Gráficos de estructura

El gráfico de estructura es un gráfico derivado del diagrama de flujo de datos. Representa el sistema con más detalle que DFD. Desglosa todo el sistema en los módulos funcionales más bajos, describe las funciones y subfunciones de cada módulo del sistema con mayor detalle que el DFD. El diagrama de estructura representa la estructura jerárquica de los módulos. En cada capa se realiza una tarea específica. Aquí están los símbolos utilizados en la construcción de diagramas de estructura: 

Módulo : representa el proceso, subrutina o tarea. Un módulo de control se bifurca a más de un submódulo. Los módulos de biblioteca son reutilizables e invocables desde cualquier módulo.



Condición : está representado por un pequeño diamante en la base del módulo. Representa que el módulo de control puede seleccionar cualquiera de las subrutinas en función de alguna condición.



Saltar : se muestra una flecha apuntando dentro del módulo para representar que

el control saltará en el medio del submódulo.



Bucle : una flecha curva representa el bucle en el módulo. Todos los submódulos cubiertos por bucle repiten la ejecución del módulo.



Flujo de datos : una flecha dirigida con un círculo vacío al final representa el flujo

de datos. 

Flujo de control : una flecha dirigida con un círculo relleno al final representa el

flujo de control.

Diagrama HIPO El diagrama HIPO (Hierarchical Input Process Output) es una combinación de dos métodos organizados para analizar el sistema y proporcionar los medios de documentación. El modelo HIPO fue desarrollado por IBM en el año 1970. El diagrama HIPO representa la jerarquía de módulos en el sistema de software. El analista utiliza el diagrama HIPO para obtener una vista de alto nivel de las funciones del sistema. Descompone funciones en subfunciones de manera jerárquica. Representa las funciones realizadas por el sistema. Los diagramas HIPO son buenos para fines de documentación. Su representación gráfica facilita a los diseñadores y gerentes obtener una idea gráfica de la estructura del sistema.

A diferencia del diagrama IPO (Input Process Output), que representa el flujo de control y datos en un módulo, HIPO no proporciona ninguna información sobre el flujo de datos o el flujo de control.

Ejemplo Ambas partes del diagrama HIPO, la presentación jerárquica y la tabla IPO se utilizan para el diseño de la estructura del programa de software, así como la documentación del mismo.

Inglés estructurado La mayoría de los programadores desconocen el panorama general del software, por lo que solo confían en lo que sus gerentes les dicen que hagan. Es responsabilidad de la administración de software superior proporcionar información precisa a los programadores para desarrollar un código preciso pero rápido. Otras formas de métodos, que utilizan gráficos o diagramas, a veces pueden ser interpretados de manera diferente por diferentes personas. Por lo tanto, los analistas y diseñadores del software presentan herramientas como el inglés estructurado. No es más que la descripción de lo que se

requiere para codificar y cómo codificarlo. El inglés estructurado ayuda al programador a escribir código libre de errores. Otras formas de métodos, que utilizan gráficos o diagramas, a veces pueden ser interpretados de manera diferente por diferentes personas. Aquí, tanto el inglés estructurado como el pseudocódigo intentan mitigar esa brecha de comprensión. El inglés estructurado es el que utiliza palabras simples en inglés en el paradigma de programación estructurada. No es el código definitivo, sino una especie de descripción de lo que se requiere para codificar y cómo codificarlo. Los siguientes son algunos tokens de programación estructurada. IF-THEN-ELSE, DO-WHILE-UNTIL

Analyst utiliza la misma variable y nombre de datos, que se almacenan en el Diccionario de datos, lo que hace que sea mucho más sencillo escribir y comprender el código.

Ejemplo Tomamos el mismo ejemplo de autenticación de clientes en el entorno de compras en línea. Este procedimiento para autenticar al cliente se puede escribir en inglés estructurado como: Enter Customer_Name SEEK Customer_Name in Customer_Name_DB file IF Customer_Name found THEN Call procedure USER_PASSWORD_AUTHENTICATE() ELSE PRINT error message Call procedure NEW_CUSTOMER_REQUEST() ENDIF

El código escrito en inglés estructurado se parece más al inglés hablado día a día. No se puede implementar directamente como un código de software. El inglés estructurado es independiente del lenguaje de programación.

Pseudocódigo El pseudocódigo se escribe más cerca del lenguaje de programación. Puede considerarse como lenguaje de programación aumentado, lleno de comentarios y descripciones. El seudocódigo evita la declaración de variables, pero se escriben utilizando algunas construcciones de lenguaje de programación real, como C, Fortran, Pascal, etc. El pseudocódigo contiene más detalles de programación que el inglés estructurado. Proporciona un método para realizar la tarea, como si una computadora estuviera ejecutando el código.

Ejemplo Programa para imprimir Fibonacci hasta n números. void function Fibonacci Get value of n; Set value of a to 1; Set value of b to 1; Initialize I to 0 for (i=0; i< n; i++) { if a greater than b { Increase b by a; Print b; } else if b greater than a { increase a by b; print a; } }

Tablas de decisiones Una tabla de decisiones representa las condiciones y las acciones respectivas que deben tomarse para abordarlas, en un formato tabulado estructurado. Es una herramienta poderosa para depurar y prevenir errores. Ayuda a agrupar información similar en una sola tabla y, al combinar tablas, ofrece una toma de decisiones fácil y conveniente.

Crear tabla de decisiones Para crear la tabla de decisiones, el desarrollador debe seguir cuatro pasos básicos:  

Identificar todas las condiciones posibles que se abordarán. Determinar acciones para todas las condiciones identificadas



Crear máximas reglas posibles



Definir acción para cada regla.

Los usuarios finales deben verificar las Tablas de decisión y últimamente pueden simplificarse eliminando reglas y acciones duplicadas.

Ejemplo Tomemos un ejemplo simple del problema diario con nuestra conectividad a Internet. Comenzamos identificando todos los problemas que pueden surgir al iniciar Internet y sus respectivas posibles soluciones.

Enumeramos todos los posibles problemas en condiciones de columna y las acciones prospectivas en Acciones de columna.

Condiciones

Comportamiento

Condiciones / acciones

Reglas

Shows conectados

norte norte norte norte Y

Ping está funcionando

norte norte Y

Y

Abre el sitio web

Y

norte Y

Comprobar cable de red

X

Comprobar enrutador de internet

X

norte Y

Y

norte norte Y Y

X

norte Y norte

X

Reiniciar el navegador web Contactar con el proveedor de servicios

YY

X X

X

X

X

X

X

X

No hacer nada Tabla: Tabla de decisiones - Solución de problemas internos de Internet

Modelo de entidad-relación El modelo de entidad-relación es un tipo de modelo de base de datos basado en la noción de entidades del mundo real y la relación entre ellas. Podemos mapear el escenario del mundo real en el modelo de base de datos ER. El modelo ER crea un conjunto de entidades con sus atributos, un conjunto de restricciones y relación entre ellas. El modelo ER se utiliza mejor para el diseño conceptual de la base de datos. El modelo ER se puede representar de la siguiente manera:



Entidad : una entidad en el modelo ER es un ser del mundo real, que tiene algunas propiedades llamadas atributos . Cada atributo se define por su conjunto de valores correspondiente, llamado dominio .

Por ejemplo, considere una base de datos de la escuela. Aquí, un estudiante es una entidad. El estudiante tiene varios atributos como nombre, identificación, edad y clase, etc. 

Relación : la asociación lógica entre entidades se denomina relación . Las relaciones se asignan con entidades de varias maneras. Las cardinalidades de mapeo definen el número de asociaciones entre dos entidades. Mapeo de cardinalidades: o o

doce y cincuenta y nueve de la noche uno a muchos

o

muchos a uno

o

muchos a muchos

Diccionario de datos El diccionario de datos es la recopilación centralizada de información sobre datos. Almacena el significado y el origen de los datos, su relación con otros datos, el formato de datos para su uso, etc. El diccionario de datos tiene definiciones rigurosas de todos los nombres para facilitar a los usuarios y diseñadores de software. El diccionario de datos a menudo se hace referencia como repositorio de metadatos (datos sobre datos). Se crea junto con el modelo DFD (Diagrama de flujo de datos) del programa de software y se espera que se actualice cada vez que se modifique o actualice DFD.

Requisito del diccionario de datos Se hace referencia a los datos a través del diccionario de datos al diseñar e implementar software. El diccionario de datos elimina cualquier posibilidad de ambigüedad. Ayuda a mantener sincronizado el trabajo de los programadores y diseñadores mientras se usa la misma referencia de objeto en todo el programa. El diccionario de datos proporciona una forma de documentación para el sistema de base de datos completo en un solo lugar. La validación de DFD se lleva a cabo utilizando el diccionario de datos.

Contenido El diccionario de datos debe contener información sobre lo siguiente 

Flujo de datos



Estructura de datos

 

Elementos de datos Almacenes de datos



Procesamiento de datos

El flujo de datos se describe mediante DFD como se estudió anteriormente y se representa en forma algebraica como se describe.

=

Compuesto de

{}

Repetición

()

Opcional

+

Y

[/]

O

Ejemplo Dirección = Casa No + (Calle / Área) + Ciudad + Estado ID del curso = Número del curso + Nombre del curso + Nivel del curso + Grados del curso

Elementos de datos Los elementos de datos consisten en Nombre y descripciones de Datos y Elementos de control, almacenes de datos internos o externos, etc. con los siguientes detalles: 

Nombre primario



Nombre secundario (alias)

 

Caso de uso (Cómo y dónde usar) Descripción del contenido (notación, etc.)



Información complementaria (valores preestablecidos, restricciones, etc.)

Almacén de datos Almacena la información desde donde los datos ingresan al sistema y existen fuera del sistema. El almacén de datos puede incluir: 

Archivos o o o



Interna al software. Externo al software pero en la misma máquina. Externo al software y al sistema, ubicado en diferentes máquinas.

Mesas o Convenio de denominación o

Propiedad de indexación

Procesamiento de datos Hay dos tipos de procesamiento de datos: 

Lógico: como el usuario lo ve



Físico: como lo ve el software

Estrategias de diseño de software El diseño de software es un proceso para conceptualizar los requisitos de software en la implementación de software. El diseño del software toma los requisitos del usuario como desafíos e intenta encontrar una solución óptima. Mientras se conceptualiza el software, se establece un plan para encontrar el mejor diseño posible para implementar la solución deseada. Existen múltiples variantes de diseño de software. Vamos a estudiarlos brevemente:

Diseño estructurado El diseño estructurado es una conceptualización del problema en varios elementos de solución bien organizados. Básicamente se trata del diseño de la solución. El beneficio del diseño estructurado es que brinda una mejor comprensión de cómo se resuelve el problema. El diseño estructurado también facilita que el diseñador se concentre en el problema con mayor precisión. El diseño estructurado se basa principalmente en la estrategia de "divide y vencerás", donde un problema se divide en varios problemas pequeños y cada problema pequeño se resuelve individualmente hasta que se resuelve todo el problema. Los pequeños problemas se resuelven mediante módulos de solución. El diseño estructurado enfatiza que estos módulos estén bien organizados para lograr una solución precisa. Estos módulos están ordenados en jerarquía. Se comunican entre ellos. Un buen diseño estructurado siempre sigue algunas reglas para la comunicación entre múltiples módulos, a saber: Cohesión : agrupación de todos los elementos relacionados funcionalmente. Acoplamiento : comunicación entre diferentes módulos. Un buen diseño estructurado tiene alta cohesión y bajos arreglos de acoplamiento.

Diseño orientado a funciones En el diseño orientado a funciones, el sistema se compone de muchos subsistemas más pequeños conocidos como funciones. Estas funciones son capaces de realizar tareas importantes en el sistema. El sistema se considera como una vista superior de todas las funciones. El diseño orientado a funciones hereda algunas propiedades del diseño estructurado donde se utiliza la metodología de dividir y conquistar. Este mecanismo de diseño divide todo el sistema en funciones más pequeñas, que proporcionan medios de abstracción al ocultar la información y su

funcionamiento. Estos módulos funcionales pueden compartir información entre ellos mediante el paso de información y el uso de información disponible a nivel mundial. Otra característica de las funciones es que cuando un programa llama a una función, la función cambia el estado del programa, que a veces no es aceptable por otros módulos. El diseño orientado a funciones funciona bien donde el estado del sistema no importa y el programa / funciones funcionan en la entrada en lugar de en un estado.

Proceso de diseño 

Se ve todo el sistema como el flujo de datos en el sistema por medio del diagrama de flujo de datos.



DFD muestra cómo las funciones cambian los datos y el estado de todo el sistema.



El sistema completo se divide lógicamente en unidades más pequeñas conocidas como funciones en función de su funcionamiento en el sistema.



Cada función se describe en general.

Diseño orientado a objetos El diseño orientado a objetos trabaja alrededor de las entidades y sus características en lugar de las funciones involucradas en el sistema de software. Estas estrategias de diseño se centran en las entidades y sus características. Todo el concepto de solución de software gira en torno a las entidades comprometidas. Veamos los conceptos importantes del diseño orientado a objetos: 

Objetos: todas las entidades involucradas en el diseño de la solución se conocen como objetos. Por ejemplo, persona, bancos, empresa y clientes son tratados como objetos. Cada entidad tiene algunos atributos asociados y tiene algunos métodos para realizar en los atributos.



Clases: una clase es una descripción generalizada de un objeto. Un objeto es una instancia de una clase. La clase define todos los atributos que puede tener un objeto y los métodos que definen la funcionalidad del objeto. En el diseño de la solución, los atributos se almacenan como variables y las funcionalidades se definen mediante métodos o procedimientos.



Encapsulación: en OOD, los atributos (variables de datos) y los métodos (operación en los datos) se agrupan y se denomina encapsulación. La encapsulación no solo agrupa información importante de un objeto, sino que también restringe el acceso a los datos y métodos del mundo exterior. Esto se llama ocultar información.



Herencia: OOD permite que clases similares se acumulen de forma jerárquica donde las clases inferiores o subclases pueden importar, implementar y reutilizar variables y métodos permitidos desde sus superclases inmediatas. Esta propiedad de OOD se conoce como herencia. Esto facilita la definición de clases específicas y la creación de clases generalizadas a partir de clases específicas.



Polimorfismo: los lenguajes OOD proporcionan un mecanismo en el que los métodos que realizan tareas similares pero varían en argumentos pueden tener el mismo nombre. Esto se llama polimorfismo, que permite que una sola interfaz

realice tareas para diferentes tipos. Dependiendo de cómo se invoque la función, se ejecuta la parte correspondiente del código.

Proceso de diseño El proceso de diseño de software se puede percibir como una serie de pasos bien definidos. Aunque varía según el enfoque de diseño (orientado a funciones u orientado a objetos, puede tener los siguientes pasos involucrados: 

Se crea un diseño de solución a partir de un sistema requerido o un diagrama de secuencia del sistema utilizado anteriormente.



Los objetos se identifican y agrupan en clases en nombre de la similitud en las características de los atributos.



Se define la jerarquía de clases y la relación entre ellas.



El marco de la aplicación está definido.

Enfoques de diseño de software Aquí hay dos enfoques genéricos para el diseño de software:

Diseño de arriba hacia abajo Sabemos que un sistema está compuesto por más de un subsistema y contiene varios componentes. Además, estos subsistemas y componentes pueden tener su conjunto de subsistemas y componentes y crear una estructura jerárquica en el sistema. El diseño de arriba hacia abajo toma todo el sistema de software como una entidad y luego lo descompone para lograr más de un subsistema o componente basado en algunas características. Cada subsistema o componente se trata como un sistema y se descompone aún más. Este proceso continúa ejecutándose hasta que se alcanza el nivel más bajo del sistema en la jerarquía de arriba hacia abajo. El diseño de arriba hacia abajo comienza con un modelo generalizado de sistema y sigue definiendo la parte más específica del mismo. Cuando todos los componentes están compuestos, todo el sistema comienza a existir. El diseño de arriba hacia abajo es más adecuado cuando la solución de software debe diseñarse desde cero y se desconocen detalles específicos.

Diseño de abajo hacia arriba El modelo de diseño ascendente comienza con los componentes más específicos y básicos. Continúa con la composición de un nivel superior de componentes mediante el uso de componentes básicos o de nivel inferior. Sigue creando componentes de nivel superior hasta que el sistema deseado no evoluciona como un solo componente. Con cada nivel superior, aumenta la cantidad de abstracción.

La estrategia de abajo hacia arriba es más adecuada cuando se necesita crear un sistema a partir de algún sistema existente, donde las primitivas básicas se pueden usar en el sistema más nuevo. Los enfoques de arriba hacia abajo y de abajo hacia arriba no son prácticos individualmente. En cambio, se usa una buena combinación de ambos.

Diseño de interfaz de usuario de software La interfaz de usuario es la vista de la aplicación front-end con la que el usuario interactúa para usar el software. El usuario puede manipular y controlar el software y el hardware mediante la interfaz de usuario. Hoy en día, la interfaz de usuario se encuentra en casi todos los lugares donde existe tecnología digital, desde computadoras, teléfonos móviles, automóviles, reproductores de música, aviones, barcos, etc. La interfaz de usuario es parte del software y está diseñada de tal manera que se espera que proporcione al usuario una visión del software. La interfaz de usuario proporciona una plataforma fundamental para la interacción humanocomputadora. La interfaz de usuario puede ser gráfica, basada en texto, basada en audio y video, dependiendo de la combinación subyacente de hardware y software. La interfaz de usuario puede ser hardware o software o una combinación de ambos. El software se vuelve más popular si su interfaz de usuario es:   

Atractivo Fácil de usar



Sensible en poco tiempo Claro para entender



Consistente en todas las pantallas de interfaz

La interfaz de usuario se divide en dos categorías: 

Interfaz de línea de comando



Interfaz gráfica del usuario

Interfaz de línea de comando (CLI) CLI ha sido una gran herramienta de interacción con las computadoras hasta que surgieron los monitores de video. CLI es la primera opción de muchos usuarios técnicos y programadores. CLI es la interfaz mínima que un software puede proporcionar a sus usuarios. La CLI proporciona un símbolo del sistema, el lugar donde el usuario escribe el comando y lo alimenta al sistema. El usuario debe recordar la sintaxis del comando y su uso. Las CLI anteriores no estaban programadas para manejar los errores del usuario de manera efectiva.

Un comando es una referencia basada en texto para un conjunto de instrucciones, que se espera que el sistema ejecute. Existen métodos como macros, scripts que facilitan la operación del usuario. La CLI usa menos cantidad de recursos informáticos en comparación con la GUI.

Elementos CLI

Una interfaz de línea de comandos basada en texto puede tener los siguientes elementos: 

Símbolo del sistema : es un notificador basado en texto que muestra principalmente el contexto en el que trabaja el usuario. Es generado por el sistema de software.



Cursor : es una pequeña línea horizontal o una barra vertical de la altura de la línea, para representar la posición del carácter mientras se escribe. El cursor se encuentra principalmente en estado de parpadeo. Se mueve a medida que el usuario escribe o elimina algo.



Comando : un comando es una instrucción ejecutable. Puede tener uno o más parámetros. La salida en la ejecución del comando se muestra en línea en la pantalla. Cuando se produce la salida, se muestra el símbolo del sistema en la siguiente línea.

Interfaz gráfica del usuario La interfaz gráfica de usuario proporciona al usuario medios gráficos para interactuar con el sistema. La GUI puede ser una combinación de hardware y software. Usando GUI, el usuario interpreta el software.

Por lo general, la GUI consume más recursos que la de la CLI. Con tecnología avanzada, los programadores y diseñadores crean diseños complejos de GUI que funcionan con más eficiencia, precisión y velocidad.

Elementos GUI GUI proporciona un conjunto de componentes para interactuar con software o hardware. Cada componente gráfico proporciona una forma de trabajar con el sistema. Un sistema GUI tiene los siguientes elementos, tales como:



Ventana : un área donde se muestran los contenidos de la aplicación. El contenido de una ventana se puede mostrar en forma de iconos o listas, si la ventana representa la estructura del archivo. Es más fácil para un usuario navegar en el sistema de archivos en una ventana de exploración. Windows se puede minimizar, redimensionar o maximizar al tamaño de la pantalla. Se pueden mover a cualquier lugar de la pantalla. Una ventana puede contener otra ventana de la misma aplicación, llamada ventana secundaria.



Pestañas : si una aplicación permite ejecutar varias instancias de sí misma, aparecerán en la pantalla como ventanas separadas. La interfaz de documentos con pestañas ha aparecido para abrir varios documentos en la misma ventana. Esta interfaz también ayuda a visualizar el panel de preferencias en la aplicación. Todos los navegadores web modernos usan esta función.



Menú : el menú es una matriz de comandos estándar, agrupados y colocados en un lugar visible (generalmente arriba) dentro de la ventana de la aplicación. El menú puede programarse para aparecer u ocultarse con los clics del mouse.



Icono : un icono es una imagen pequeña que representa una aplicación asociada. Cuando se hace clic en estos iconos o se hace doble clic, se abre la ventana de la aplicación. Icon muestra aplicaciones y programas instalados en un sistema en forma de imágenes pequeñas.



Cursor : los dispositivos que interactúan, como el mouse, el panel táctil y el lápiz digital, se representan en la GUI como cursores. El cursor en pantalla sigue las

instrucciones del hardware casi en tiempo real. Los cursores también se denominan punteros en los sistemas GUI. Se utilizan para seleccionar menús, ventanas y otras características de la aplicación.

Componentes de la GUI específicos de la aplicación Una GUI de una aplicación contiene uno o más de los elementos de la GUI enumerados: 

Ventana de aplicación : la mayoría de las ventanas de aplicación utilizan las construcciones proporcionadas por los sistemas operativos, pero muchas usan sus propias ventanas creadas por el cliente para contener el contenido de la aplicación.



Cuadro de diálogo : es una ventana secundaria que contiene mensajes para el usuario y solicita que se tomen medidas. Por ejemplo: la aplicación genera un diálogo para obtener la confirmación del usuario para eliminar un archivo.



Cuadro de texto : proporciona un área para que el usuario escriba e ingrese datos basados en texto.



Botones : imitan los botones de la vida real y se utilizan para enviar entradas al software.



Botón de radio : muestra las opciones disponibles para la selección. Solo se puede seleccionar uno entre todos los ofrecidos.



Casilla de verificación : funciones similares a la casilla de lista. Cuando se selecciona una opción, la casilla se marca como marcada. Se pueden seleccionar varias opciones representadas por casillas de verificación.



Cuadro de lista: proporciona una lista de elementos disponibles para la selección. Se puede seleccionar más de un elemento.

Otros componentes impresionantes de la GUI son:  

Deslizadores Caja combo



Cuadrícula de datos



La lista desplegable

Actividades de diseño de interfaz de usuario Hay una serie de actividades realizadas para diseñar la interfaz de usuario. El proceso de diseño e implementación de la GUI es similar al SDLC. Cualquier modelo se puede utilizar para la implementación de GUI entre Cascada, Iterativo o Modelo Espiral. Un modelo utilizado para el diseño y desarrollo de GUI debe cumplir con estos pasos específicos de GUI.



Recopilación de requisitos de GUI : a los diseñadores les gustaría tener una lista de todos los requisitos funcionales y no funcionales de GUI. Esto se puede tomar del usuario y su solución de software existente.



Análisis del usuario : el diseñador estudia quién va a utilizar la GUI del software. El público objetivo es importante a medida que los detalles del diseño cambian de acuerdo con el nivel de conocimiento y competencia del usuario. Si el usuario tiene conocimientos técnicos, se puede incorporar una GUI avanzada y compleja. Para un usuario novato, se incluye más información sobre procedimientos del software.



Análisis de tareas : los diseñadores deben analizar qué tarea debe realizar la solución de software. Aquí en GUI, no importa cómo se haga. Las tareas se pueden representar de forma jerárquica tomando una tarea principal y dividiéndola en subtareas más pequeñas. Las tareas proporcionan objetivos para la presentación de la GUI. El flujo de información entre subtareas determina el flujo de contenido de GUI en el software.



Diseño e implementación de la GUI : los diseñadores, después de tener información sobre los requisitos, las tareas y el entorno del usuario, diseñan la GUI y la implementan en el código e incorporan la GUI con software de trabajo o ficticio en segundo plano. Luego es probado por los desarrolladores.



Pruebas : las pruebas de GUI se pueden realizar de varias maneras. La organización puede tener una inspección interna, la participación directa de los usuarios y el lanzamiento de la versión beta son algunos de ellos. Las pruebas pueden incluir usabilidad, compatibilidad, aceptación del usuario, etc.

Herramientas de implementación de GUI Hay varias herramientas disponibles con las que los diseñadores pueden crear una GUI completa con un clic del mouse. Algunas herramientas pueden integrarse en el entorno de software (IDE).

Las herramientas de implementación de GUI proporcionan una poderosa variedad de controles de GUI. Para la personalización del software, los diseñadores pueden cambiar el código en consecuencia. Existen diferentes segmentos de herramientas GUI según su uso y plataforma diferentes.

Ejemplo GUI móvil, GUI de computadora, GUI de pantalla táctil, etc. Aquí hay una lista de algunas herramientas que son útiles para construir GUI:  

FLUIDO AppInventor (Android)



LucidChart



Wavemaker



Estudio visual

Interfaz de usuario Reglas de oro Se menciona que las siguientes reglas son las reglas de oro para el diseño de GUI, descritas por Shneiderman y Plaisant en su libro (Diseño de la interfaz de usuario). 

Esfuércese por la coherencia : se deben requerir secuencias consistentes de acciones en situaciones similares. Se debe utilizar una terminología idéntica en las indicaciones, menús y pantallas de ayuda. Se deben emplear comandos consistentes en todo momento.



Permita que los usuarios frecuentes usen atajos : el deseo del usuario de reducir la cantidad de interacciones aumenta con la frecuencia de uso. Las abreviaturas, las teclas de función, los comandos ocultos y las funciones de macro son muy útiles para un usuario experto.



Ofrecer comentarios informativos : para cada acción del operador, debe haber comentarios del sistema. Para acciones frecuentes y menores, la respuesta debe ser modesta, mientras que para acciones poco frecuentes e importantes, la respuesta debe ser más sustancial.



Diálogo de diseño para producir el cierre : las secuencias de acciones deben organizarse en grupos con un principio, un medio y un final. La retroalimentación informativa al completar un grupo de acciones brinda a los operadores la satisfacción del logro, una sensación de alivio, la señal de abandonar los planes de contingencia y las opciones de sus mentes, y esto indica que el camino por delante está claro para prepararse para el próximo grupo de acciones.



Ofrezca un manejo simple de errores : en la medida de lo posible, diseñe el sistema para que el usuario no cometa un error grave. Si se comete un error, el sistema debería poder detectarlo y ofrecer mecanismos simples y comprensibles para manejar el error.



Permitir la reversión fácil de acciones : esta característica alivia la ansiedad, ya que el usuario sabe que los errores se pueden deshacer. La reversión fácil de acciones fomenta la exploración de opciones desconocidas. Las unidades de reversibilidad pueden ser una sola acción, una entrada de datos o un grupo completo de acciones.



Apoye el locus de control interno : los operadores experimentados desean sentir que están a cargo del sistema y que el sistema responde a sus acciones. Diseñe el sistema para que los usuarios sean los iniciadores de acciones en lugar de los que responden.



Reduzca la carga de memoria a corto plazo : la limitación del procesamiento de información humana en la memoria a corto plazo requiere que las pantallas se mantengan simples, se consoliden varias pantallas de página, se reduzca la frecuencia de movimiento de la ventana y se asigne suficiente tiempo de entrenamiento para códigos, mnemotécnicos, y secuencias de acciones.

Complejidad del diseño de software El término complejidad significa estado de eventos o cosas, que tienen múltiples enlaces interconectados y estructuras altamente complicadas. En la programación de software, a medida que se realiza el diseño del software, la cantidad de elementos y sus interconexiones gradualmente emergen para ser enormes, lo que se vuelve demasiado difícil de entender de inmediato. La complejidad del diseño de software es difícil de evaluar sin utilizar métricas y medidas de complejidad. Veamos tres medidas importantes de complejidad de software.

Medidas de complejidad de Halstead En 1977, el Sr. Maurice Howard Halstead introdujo métricas para medir la complejidad del software. Las métricas de Halstead dependen de la implementación real del programa y sus medidas, que se calculan directamente desde los operadores y los operandos desde el código fuente, de manera estática. Permite evaluar el tiempo de prueba, vocabulario, tamaño, dificultad, errores y esfuerzos para el código fuente C / C ++ / Java. Según Halstead, "Un programa de computadora es una implementación de un algoritmo considerado como una colección de tokens que se pueden clasificar como operadores u operandos". Las métricas de Halstead piensan que un programa es una secuencia de operadores y sus operandos asociados. Define varios indicadores para verificar la complejidad del módulo. Parámetro

Sentido

n1

Número de operadores únicos.

n2

Número de operandos únicos

N1

Número de ocurrencia total de operadores

N2

Número de ocurrencia total de operandos

Cuando seleccionamos el archivo fuente para ver sus detalles de complejidad en Metric Viewer, el siguiente resultado se ve en Metric Report:

Métrico

Sentido

Representación matemática

norte

Vocabulario

n1 + n2

norte

Talla

N1 + N2

V

Volumen

Longitud * Vocabulario Log2

re

Dificultad

(n1 / 2) * (N1 / n2)

mi

Esfuerzos

Dificultad * Volumen

si

Errores

Volumen / 3000

T

Tiempo de prueba

Tiempo = Esfuerzos / S, donde S = 18 segundos.

Medidas de complejidad ciclomática Cada programa abarca declaraciones para ejecutar con el fin de realizar alguna tarea y otras declaraciones de toma de decisiones que deciden qué declaraciones deben ejecutarse. Estas construcciones de toma de decisiones cambian el flujo del programa. Si comparamos dos programas del mismo tamaño, el que tenga más declaraciones de toma de decisiones será más complejo ya que el control del programa salta con frecuencia. McCabe, en 1976, propuso la Medida de Complejidad Ciclomática para cuantificar la complejidad de un software dado. Es un modelo basado en gráficos que se basa en las construcciones de toma de decisiones del programa, como las declaraciones if-else, do-while, repeat-until, switch-case y goto. Proceso para hacer un gráfico de control de flujo: 

Romper el programa en bloques más pequeños, delimitados por construcciones de toma de decisiones.



Cree nodos que representen cada uno de estos nodos. Conecte los nodos de la siguiente manera:



o Si el control puede ramificarse del bloque i al bloque j

Dibujar un arco o Del nodo de salida al nodo de entrada

Dibuja un arco.

Para calcular la complejidad ciclomática de un módulo de programa, utilizamos la fórmula: V(G) = e – n + 2

Where e is total number of edges n is total number of nodes

La complejidad ciclomática del módulo anterior es e = 10 n = 8 Cyclomatic Complexity = 10 - 8 + 2 = 4

Según P. Jorgensen, la Complejidad Ciclomática de un módulo no debe exceder 10.

Punto de función Es ampliamente utilizado para medir el tamaño del software. Function Point se concentra en la funcionalidad proporcionada por el sistema. Las características y la funcionalidad del sistema se utilizan para medir la complejidad del software. El punto de función cuenta con cinco parámetros, denominados Entrada externa, Salida externa, Archivos internos lógicos, Archivos de interfaz externa y Consulta externa. Para considerar la complejidad del software, cada parámetro se clasifica además como simple, promedio o complejo.

Veamos los parámetros del punto de función:

Entrada externa Cada entrada única al sistema, desde el exterior, se considera como entrada externa. Se mide la unicidad de la entrada, ya que no hay dos entradas que tengan los mismos formatos. Estas entradas pueden ser datos o parámetros de control. 

Simple : si el recuento de entrada es bajo y afecta menos archivos internos



Complejo : si el recuento de entrada es alto y afecta a más archivos internos



Promedio : entre simple y complejo.

Salida externa Todos los tipos de salida proporcionados por el sistema se cuentan en esta categoría. La salida se considera única si su formato de salida y / o procesamiento son únicos. 

Simple : si el recuento de salida es bajo



Complejo : si el recuento de salida es alto



Promedio : entre simple y complejo.

Archivos internos lógicos Cada sistema de software mantiene archivos internos para mantener su información funcional y funcionar correctamente. Estos archivos contienen datos lógicos del sistema. Estos datos lógicos pueden contener tanto datos funcionales como datos de control.



Simple : si el número de tipos de registro es bajo



Complejo : si el número de tipos de registro es alto



Promedio : entre simple y complejo.

Archivos de interfaz externa El sistema de software puede necesitar compartir sus archivos con algún software externo o puede necesitar pasar el archivo para su procesamiento o como parámetro a alguna función. Todos estos archivos se cuentan como archivos de interfaz externos. 

Simple : si el número de tipos de registro en el archivo compartido es bajo



Complejo : si el número de tipos de registro en el archivo compartido es alto



Promedio : entre simple y complejo.

Consulta externa Una consulta es una combinación de entrada y salida, donde el usuario envía algunos datos para preguntar como entrada y el sistema responde al usuario con la salida de la consulta procesada. La complejidad de una consulta es más que Entrada externa y Salida externa. Se dice que la consulta es única si su entrada y salida son únicas en términos de formato y datos. 

Simple : si la consulta necesita un procesamiento bajo y produce una pequeña cantidad de datos de salida



Complejo : si la consulta necesita un proceso alto y produce una gran cantidad de datos de salida



Promedio : entre simple y complejo.

A cada uno de estos parámetros en el sistema se le asigna un peso de acuerdo con su clase y complejidad. La siguiente tabla menciona el peso dado a cada parámetro: Parámetro

Sencillo

Promedio

Complejo

Entradas

3

44

66

Salidas

44

55

77

Investigación

3

44

66

Archivos

77

10

15

Interfaces

55

77

10

La tabla anterior arroja puntos de función sin procesar. Estos puntos de función se ajustan según la complejidad del entorno. El sistema se describe utilizando catorce características diferentes:



Transmisión de datos



Procesamiento distribuido



Objetivos de rendimiento



Carga de configuración de la operación



Tasa de transacción



Entrada de datos en línea,



Eficiencia del usuario final



Actualización en línea



Lógica de procesamiento compleja



Reutilización



Facilidad de instalación



Facilidad operacional



Múltiples sitios



Deseo de facilitar los cambios.

Estos factores de características se clasifican de 0 a 5, como se menciona a continuación: 

Sin influencia

 

Incidental Moderar



Promedio



Significativo



Esencial

Todas las clasificaciones se resumen como N. El valor de N varía de 0 a 70 (14 tipos de características x 5 tipos de clasificaciones). Se usa para calcular Factores de Ajuste de Complejidad (CAF), usando las siguientes fórmulas: CAF = 0.65 + 0.01N

Luego, Puntos de función entregados ( FP ) = CAF x FP sin procesar

Este FP se puede usar en varias métricas, como: Costo = $ / FP Calidad = Errores / FP Productividad = FP / persona-mes

Implementación de software En este capítulo, estudiaremos los métodos de programación, documentación y los desafíos en la implementación de software.

la

Programación estructurada En el proceso de codificación, las líneas de código siguen multiplicándose, por lo tanto, el tamaño del software aumenta. Gradualmente, se vuelve casi

imposible recordar el flujo del programa. Si uno olvida cómo se construyen el software y sus programas, archivos y procedimientos subyacentes, se vuelve muy difícil compartir, depurar y modificar el programa. La solución a esto es la programación estructurada. Alienta al desarrollador a usar subrutinas y bucles en lugar de usar saltos simples en el código, lo que aporta claridad en el código y mejora su eficiencia. La programación estructurada también ayuda al programador a reducir el tiempo de codificación y organizar el código correctamente. La programación estructurada indica cómo se codificará el programa. La programación estructurada utiliza tres conceptos principales: 

Análisis de arriba hacia abajo : siempre se hace un software para realizar un trabajo racional. Este trabajo racional se conoce como problema en el lenguaje del software. Por lo tanto, es muy importante que comprendamos cómo resolver el problema. Bajo el análisis de arriba hacia abajo, el problema se divide en pequeños pedazos donde cada uno tiene algún significado. Cada problema se resuelve individualmente y los pasos se indican claramente sobre cómo resolver el problema.



Programación modular : durante la programación, el código se divide en un grupo más pequeño de instrucciones. Estos grupos se conocen como módulos, subprogramas o subrutinas. Programación modular basada en la comprensión del análisis de arriba hacia abajo. Desalienta los saltos usando declaraciones 'goto' en el programa, lo que a menudo hace que el flujo del programa no sea rastreable. Los saltos están prohibidos y se fomenta el formato modular en la programación estructurada.



Codificación estructurada : en referencia al análisis de arriba hacia abajo, la codificación estructurada subdivide los módulos en unidades de código más pequeñas en el orden de su ejecución. La programación estructurada usa una estructura de control, que controla el flujo del programa, mientras que la codificación estructurada usa una estructura de control para organizar sus instrucciones en patrones definibles.

Programacion Funcional La programación funcional es un estilo de lenguaje de programación, que utiliza los conceptos de funciones matemáticas. Una función en matemáticas siempre debe producir el mismo resultado al recibir el mismo argumento. En lenguajes de procedimiento, el flujo del programa se ejecuta a través de procedimientos, es decir, el control del programa se transfiere al procedimiento llamado. Mientras el flujo de control se transfiere de un procedimiento a otro, el programa cambia su estado. En la programación de procedimientos, es posible que un procedimiento produzca resultados diferentes cuando se llama con el mismo argumento, ya que el programa en sí puede estar en un estado diferente mientras lo llama. Esta es una propiedad, así como un inconveniente de la programación de procedimientos, en la que la secuencia o el momento de la ejecución del procedimiento se vuelve importante. La programación funcional proporciona medios de cálculo como funciones matemáticas, lo que produce resultados independientemente del estado del programa. Esto hace posible predecir el comportamiento del programa.

La programación funcional utiliza los siguientes conceptos: 

Funciones de primera clase y de orden superior : estas funciones tienen la capacidad de aceptar otra función como argumento o devuelven otras funciones como resultados.



Funciones puras : estas funciones no incluyen actualizaciones destructivas, es decir, no afectan a ninguna E / S ni memoria y, si no están en uso, pueden eliminarse fácilmente sin obstaculizar el resto del programa.



Recursión : la recursión es una técnica de programación en la que una función se llama a sí misma y repite el código del programa, a menos que coincida alguna condición predefinida. La recursión es la forma de crear bucles en la programación funcional.



Evaluación estricta : es un método para evaluar la expresión pasada a una función como argumento. La programación funcional tiene dos tipos de métodos de evaluación, estrictos (ansiosos) o no estrictos (perezosos). La evaluación estricta siempre evalúa la expresión antes de invocar la función. La evaluación no estricta no evalúa la expresión a menos que sea necesaria.



λ-calculus : la mayoría de los lenguajes de programación funcionales utilizan λcalculus como sus sistemas de tipos. Las expresiones λ se ejecutan al evaluarlas a medida que ocurren.

Common Lisp, Scala, Haskell, Erlang y F # son algunos ejemplos de lenguajes de programación funcionales.

Estilo de programación El estilo de programación es un conjunto de reglas de codificación seguidas por todos los programadores para escribir el código. Cuando varios programadores trabajan en el mismo proyecto de software, con frecuencia necesitan trabajar con el código del programa escrito por algún otro desarrollador. Esto se vuelve tedioso o, a veces, imposible, si todos los desarrolladores no siguen un estilo de programación estándar para codificar el programa. Un estilo de programación apropiado incluye el uso de nombres de funciones y variables relevantes para la tarea prevista, el uso de sangría bien colocada, el código de comentarios para la conveniencia del lector y la presentación general del código. Esto hace que el código del programa sea legible y comprensible para todos, lo que a su vez facilita la depuración y la resolución de errores. Además, el estilo de codificación adecuado ayuda a facilitar la documentación y la actualización.

Pautas de codificación La práctica del estilo de codificación varía con las organizaciones, los sistemas operativos y el lenguaje de codificación en sí. Los siguientes elementos de codificación pueden definirse bajo las pautas de codificación de una organización: 

Convenciones de nomenclatura : esta sección define cómo nombrar funciones, variables, constantes y variables globales.



Sangría : este es el espacio que queda al comienzo de la línea, generalmente 2-8 espacios en blanco o una sola pestaña.



Espacio en blanco : generalmente se omite al final de la línea.



Operadores : define las reglas de escritura de operadores matemáticos, de asignación y lógicos. Por ejemplo, el operador de asignación '=' debe tener espacio antes y después, como en "x = 2".



Estructuras de control : las reglas de escribir if-then-else, case-switch, while-until y para declaraciones de flujo de control únicamente y de forma anidada.



Longitud de línea y ajuste : define cuántos caracteres deben estar allí en una línea, principalmente una línea de 80 caracteres. El ajuste define cómo se debe ajustar una línea, si es demasiado larga.



Funciones : define cómo deben declararse e invocarse las funciones, con y sin parámetros.



Variables : menciona cómo se declaran y definen variables de diferentes tipos de datos.



Comentarios : este es uno de los componentes de codificación importantes, ya que los comentarios incluidos en el código describen lo que realmente hace el código y todas las demás descripciones asociadas. Esta sección también ayuda a crear documentaciones de ayuda para otros desarrolladores.

Documentación de software La documentación del software es una parte importante del proceso del software. Un documento bien escrito proporciona una gran herramienta y un medio de repositorio de información necesario para conocer el proceso del software. La documentación del software también proporciona información sobre cómo usar el producto. Una documentación bien mantenida debe incluir los siguientes documentos: 

Documentación de requisitos : esta documentación funciona como una herramienta clave para que el diseñador de software, el desarrollador y el equipo de prueba realicen sus tareas respectivas. Este documento contiene toda la descripción funcional, no funcional y de comportamiento del software previsto. La fuente de este documento puede ser datos previamente almacenados sobre el software, que ya están ejecutando software al final del cliente, la entrevista, los cuestionarios y la investigación del cliente. En general, se almacena en forma de hoja de cálculo o documento de procesamiento de texto con el equipo de gestión de software de alta gama. Esta documentación funciona como base para el desarrollo del software y se utiliza principalmente en las fases de verificación y validación. La mayoría de los casos de prueba se crean directamente a partir de la documentación de requisitos.



Documentación de diseño de software : estas documentaciones contienen toda la información necesaria, necesaria para construir el software. Contiene: (a) Arquitectura de software de alto nivel, (b) Detalles de diseño de software, (c) Diagramas de flujo de datos, (d) Diseño de base de datos Estos documentos funcionan como repositorio para que los desarrolladores implementen el software. Aunque estos documentos no brindan detalles sobre

cómo codificar el programa, brindan toda la información necesaria que se requiere para la codificación y la implementación. 

Documentación técnica : los desarrolladores y los codificadores reales mantienen estas documentaciones. Estos documentos, en su conjunto, representan información sobre el código. Mientras escriben el código, los programadores también mencionan el objetivo del código, quién lo escribió, dónde será requerido, qué hace y cómo lo hace, qué otros recursos usa el código, etc. La documentación técnica aumenta la comprensión entre varios programadores que trabajan en el mismo código. Mejora la capacidad de reutilización del código. Hace que la depuración sea fácil y rastreable. Hay varias herramientas automatizadas disponibles y algunas vienen con el lenguaje de programación en sí. Por ejemplo, Java viene con la herramienta JavaDoc para generar documentación técnica de código.



Documentación del usuario : esta documentación es diferente de todo lo explicado anteriormente. Todas las documentaciones anteriores se mantienen para proporcionar información sobre el software y su proceso de desarrollo. Pero la documentación del usuario explica cómo debería funcionar el producto de software y cómo debería utilizarse para obtener los resultados deseados. Estas documentaciones pueden incluir procedimientos de instalación de software, guías prácticas, guías de usuario, método de desinstalación y referencias especiales para obtener más información, como actualización de licencias, etc.

Desafíos de implementación de software El equipo de desarrollo enfrenta algunos desafíos al implementar el software. Algunos de ellos se mencionan a continuación: 

Reutilización de código : las interfaces de programación de los lenguajes actuales son muy sofisticadas y están equipadas con enormes funciones de biblioteca. Aún así, para reducir el costo del producto final, la administración de la organización prefiere reutilizar el código, que fue creado anteriormente para algún otro software. Los programadores enfrentan grandes problemas para las comprobaciones de compatibilidad y para decidir cuánto código reutilizar.



Gestión de versiones : cada vez que se emite un nuevo software al cliente, los desarrolladores deben mantener la documentación relacionada con la versión y la configuración. Esta documentación debe ser muy precisa y estar disponible a tiempo.



Target-Host : el programa de software, que se está desarrollando en la organización, debe diseñarse para máquinas host en el extremo del cliente. Pero a veces, es imposible diseñar un software que funcione en las máquinas de destino.

Descripción general de las pruebas de software La prueba de software es una evaluación del software con respecto a los requisitos recopilados de los usuarios y las especificaciones del sistema. Las pruebas se realizan a nivel de fase en el ciclo de vida de desarrollo de software o a nivel de módulo en el código del programa. Las pruebas de software se componen de Validación y Verificación.

Validación de software La validación es el proceso de examinar si el software satisface o no los requisitos del usuario. Se lleva a cabo al final del SDLC. Si el software cumple con los requisitos para los que fue creado, se valida. 

La validación asegura que el producto en desarrollo cumple con los requisitos del usuario.



La validación responde a la pregunta: "¿Estamos desarrollando el producto que intenta todo lo que el usuario necesita de este software?".



La validación enfatiza los requisitos del usuario.

Verificación de software La verificación es el proceso de confirmar si el software cumple con los requisitos comerciales y se desarrolla siguiendo las especificaciones y metodologías adecuadas. 

La verificación asegura que el producto que se está desarrollando cumple con las especificaciones de diseño.



La verificación responde a la pregunta: "¿Estamos desarrollando este producto siguiendo firmemente todas las especificaciones de diseño?"



Las verificaciones se concentran en el diseño y las especificaciones del sistema.

Los objetivos de la prueba son: 

Errores : estos son errores de codificación reales cometidos por los desarrolladores. Además, hay una diferencia en la salida del software y la salida deseada, se considera como un error.



Falla : cuando existe un error, se produce una falla. Una falla, también conocida como error, es el resultado de un error que puede causar fallas en el sistema.



Falla : se dice que la falla es la incapacidad del sistema para realizar la tarea deseada. La falla ocurre cuando existe una falla en el sistema.

Manual vs pruebas automatizadas Las pruebas pueden realizarse manualmente o utilizando una herramienta de prueba automatizada: 

Manual : esta prueba se realiza sin la ayuda de herramientas de prueba automatizadas. El probador de software prepara casos de prueba para diferentes secciones y niveles del código, ejecuta las pruebas e informa el resultado al gerente. Las pruebas manuales consumen mucho tiempo y recursos. El probador necesita confirmar si se usan o no los casos de prueba correctos. La mayor parte de las pruebas implica pruebas manuales.



Automatizado Esta prueba es un procedimiento de prueba realizado con la ayuda de herramientas de prueba automatizadas. Las limitaciones con las pruebas manuales se pueden superar utilizando herramientas de prueba automatizadas.

Una prueba debe verificar si se puede abrir una página web en Internet Explorer. Esto se puede hacer fácilmente con pruebas manuales. Pero para verificar si el servidor web puede soportar la carga de 1 millón de usuarios, es bastante imposible probarlo manualmente. Existen herramientas de software y hardware que ayudan al probador a realizar pruebas de carga, pruebas de estrés y pruebas de regresión.

Enfoques de prueba Las pruebas se pueden realizar en base a dos enfoques: 

Prueba de funcionalidad



Pruebas de implementación

Cuando se prueba la funcionalidad sin tener en cuenta la implementación real, se conoce como prueba de caja negra. El otro lado se conoce como prueba de caja blanca donde no solo se prueba la funcionalidad sino que también se analiza la forma en que se implementa. Las pruebas exhaustivas son el método más deseado para una prueba perfecta. Se prueba cada valor posible en el rango de los valores de entrada y salida. No es posible probar todos y cada uno de los valores en el escenario del mundo real si el rango de valores es grande.

Prueba de caja negra Se lleva a cabo para probar la funcionalidad del programa. También se llama prueba de "comportamiento". El probador en este caso, tiene un conjunto de valores de entrada y los resultados deseados respectivos. Al proporcionar la entrada, si la salida coincide con los resultados deseados, el programa se prueba 'bien', y de lo contrario es problemático.

En este método de prueba, el probador no conoce el diseño y la estructura del código, y los ingenieros de prueba y los usuarios finales realizan esta prueba en el software. Técnicas de prueba de caja negra: 

Clase de equivalencia : la entrada se divide en clases similares. Si un elemento de una clase pasa la prueba, se supone que se pasa toda la clase.



Valores límite : la entrada se divide en valores finales superiores e inferiores. Si estos valores pasan la prueba, se supone que todos los valores intermedios también pueden pasar.



Gráfico de causa-efecto : en ambos métodos anteriores, solo se prueba un valor de entrada a la vez. Causa (entrada): el efecto (salida) es una técnica de prueba en la que las combinaciones de valores de entrada se prueban de manera sistemática.



Prueba por pares : el comportamiento del software depende de múltiples parámetros. En las pruebas por pares, los múltiples parámetros se prueban por pares para sus diferentes valores.



Pruebas basadas en estado: el sistema cambia de estado al proporcionar entrada. Estos sistemas se prueban en función de sus estados y aportes.

Prueba de caja blanca Se lleva a cabo para probar el programa y su implementación, con el fin de mejorar la eficiencia o la estructura del código. También se conoce como prueba 'estructural'.

En este método de prueba, el probador conoce el diseño y la estructura del código. Los programadores del código realizan esta prueba en el código. Las siguientes son algunas técnicas de prueba de caja blanca: 

Prueba de flujo de control : el propósito de la prueba de flujo de control para configurar casos de prueba que cubran todas las declaraciones y condiciones de ramificación. Las condiciones de la rama se prueban para que sean verdaderas y falsas, de modo que se puedan cubrir todas las declaraciones.



Prueba de flujo de datos : esta técnica de prueba hace hincapié en cubrir todas las variables de datos incluidas en el programa. Comprueba dónde se declararon y definieron las variables y dónde se usaron o cambiaron.

Niveles de prueba Las pruebas en sí pueden definirse en varios niveles de SDLC. El proceso de prueba se ejecuta en paralelo al desarrollo de software. Antes de saltar a la siguiente etapa, se prueba, valida y verifica una etapa. Las pruebas por separado se realizan solo para asegurarse de que no quedan errores ocultos o problemas en el software. El software se prueba en varios niveles:

Examen de la unidad Mientras codifica, el programador realiza algunas pruebas en esa unidad de programa para saber si está libre de errores. La prueba se realiza bajo un

enfoque de prueba de caja blanca. Las pruebas unitarias ayudan a los desarrolladores a decidir que las unidades individuales del programa funcionan según los requisitos y están libres de errores.

Pruebas de integración Incluso si las unidades de software funcionan bien individualmente, es necesario averiguar si las unidades integradas juntas también funcionarían sin errores. Por ejemplo, pasar argumentos y actualizar datos, etc.

Prueba de sistema El software se compila como producto y luego se prueba como un todo. Esto se puede lograr usando una o más de las siguientes pruebas: 

Prueba de funcionalidad : prueba todas las funcionalidades del software según el requisito.



Pruebas de rendimiento : esta prueba demuestra la eficacia del software. Prueba la efectividad y el tiempo promedio que tarda el software en realizar la tarea deseada. Las pruebas de rendimiento se realizan mediante pruebas de carga y pruebas de esfuerzo en las que el software se somete a una alta carga de usuarios y datos en diversas condiciones ambientales.



Seguridad y portabilidad : estas pruebas se realizan cuando el software está diseñado para funcionar en varias plataformas y se accede por número de personas.

Test de aceptación Cuando el software está listo para entregar al cliente, tiene que pasar por la última fase de prueba donde se prueba la interacción y respuesta del usuario. Esto es importante porque incluso si el software cumple con todos los requisitos del usuario y si al usuario no le gusta la forma en que aparece o funciona, puede ser rechazado. 

Pruebas alfa : el propio equipo de desarrolladores realiza pruebas alfa utilizando el sistema como si se estuviera utilizando en un entorno de trabajo. Intentan descubrir cómo reaccionaría el usuario ante alguna acción en el software y cómo el sistema debería responder a las entradas.



Prueba beta : después de que el software se prueba internamente, se entrega a los usuarios para que lo usen en su entorno de producción solo con fines de prueba. Este todavía no es el producto entregado. Los desarrolladores esperan que los usuarios en esta etapa traigan problemas diminutos, que se omitieron para asistir.

Pruebas de regresión Cada vez que un producto de software se actualiza con un nuevo código, característica o funcionalidad, se prueba exhaustivamente para detectar si hay algún impacto negativo del código agregado. Esto se conoce como prueba de regresión.

Documentación de prueba Los documentos de prueba se preparan en diferentes etapas:

Antes de la prueba Las pruebas comienzan con la generación de casos de prueba. Los siguientes documentos son necesarios para referencia: 

Documento SRS - Documento de requisitos funcionales



Documento de política de prueba : describe hasta qué punto deben realizarse las pruebas antes de lanzar el producto.



Documento de estrategia de prueba : menciona aspectos detallados del equipo de prueba, matriz de responsabilidad y derechos / responsabilidad del gerente de prueba y el ingeniero de prueba.



Documento de matriz de trazabilidad : este es un documento SDLC, que está relacionado con el proceso de recopilación de requisitos. A medida que surgen nuevos requisitos, se agregan a esta matriz. Estas matrices ayudan a los evaluadores a conocer la fuente del requisito. Se pueden rastrear hacia adelante y hacia atrás.

Mientras se prueba Es posible que se requieran los siguientes documentos mientras se inicia y se realiza la prueba: 

Documento de caso de prueba : este documento contiene una lista de las pruebas que deben realizarse. Incluye plan de prueba de unidad, plan de prueba de integración, plan de prueba del sistema y plan de prueba de aceptación.



Descripción de la prueba : este documento es una descripción detallada de todos los casos de prueba y procedimientos para ejecutarlos.



Informe de caso de prueba : este documento contiene un informe de caso de prueba como resultado de la prueba.



Registros de prueba : este documento contiene registros de prueba para cada informe de caso de prueba.

Después de la prueba Los siguientes documentos pueden generarse después de la prueba: 

Resumen de prueba : este resumen de prueba es un análisis colectivo de todos los informes y registros de prueba. Resume y concluye si el software está listo para ser lanzado. El software se lanza bajo el sistema de control de versiones si está listo para iniciarse.

Pruebas versus control de calidad, garantía de calidad y auditoría

Necesitamos entender que las pruebas de software son diferentes del control de calidad del software, el control de calidad del software y la auditoría del software. 

Aseguramiento de la calidad del software : estos son medios de monitoreo del proceso de desarrollo de software, mediante los cuales se garantiza que todas las medidas se toman según los estándares de la organización. Esta supervisión se realiza para garantizar que se siguieron los métodos de desarrollo de software adecuados.



Control de calidad del software : este es un sistema para mantener la calidad del producto de software. Puede incluir aspectos funcionales y no funcionales del producto de software, que mejoran la buena voluntad de la organización. Este sistema se asegura de que el cliente reciba un producto de calidad para sus requisitos y el producto certificado como "apto para su uso".



Auditoría de software : esta es una revisión del procedimiento utilizado por la organización para desarrollar el software. Un equipo de auditores, independiente del equipo de desarrollo, examina el proceso, el procedimiento, los requisitos y otros aspectos del software SDLC. El propósito de la auditoría de software es verificar que el software y su proceso de desarrollo cumplan con los estándares, reglas y regulaciones.

Descripción general del mantenimiento del software El mantenimiento de software es una parte ampliamente aceptada de SDLC hoy en día. Representa todas las modificaciones y actualizaciones realizadas después de la entrega del producto de software. Existen varias razones por las cuales se requieren modificaciones, algunas de ellas se mencionan brevemente a continuación: 

Condiciones del mercado : las políticas, que cambian con el tiempo, como los impuestos y las restricciones introducidas recientemente, como la forma de mantener la contabilidad, pueden provocar la necesidad de modificaciones.



Requisitos del cliente : con el tiempo, el cliente puede solicitar nuevas características o funciones en el software.



Modificaciones de host : si cambia el hardware o la plataforma (como el sistema operativo) del host de destino, se necesitan cambios de software para mantener la adaptabilidad.



Cambios en la organización : si hay algún cambio en el nivel comercial en el extremo del cliente, como la reducción de la fortaleza de la organización, la adquisición de otra compañía, la organización para incursionar en nuevos negocios, puede surgir la necesidad de modificar el software original.

Tipos de mantenimiento En la vida útil del software, el tipo de mantenimiento puede variar según su naturaleza. Puede ser solo una tarea de mantenimiento de rutina como algún error descubierto por algún usuario o puede ser un gran evento en sí mismo según el tamaño o la naturaleza del mantenimiento. Los siguientes son algunos tipos de mantenimiento basados en sus características:



Mantenimiento correctivo : esto incluye modificaciones y actualizaciones realizadas para corregir o corregir problemas, que son descubiertos por el usuario o concluidos por los informes de error del usuario.



Mantenimiento adaptativo : esto incluye modificaciones y actualizaciones aplicadas para mantener el producto de software actualizado y en sintonía con el mundo cambiante de la tecnología y el entorno empresarial.



Mantenimiento perfecto : esto incluye modificaciones y actualizaciones realizadas para mantener el software utilizable durante un largo período de tiempo. Incluye nuevas características, nuevos requisitos de usuario para refinar el software y mejorar su confiabilidad y rendimiento.



Mantenimiento preventivo : esto incluye modificaciones y actualizaciones para evitar futuros problemas del software. Su objetivo es atender los problemas, que no son significativos en este momento pero que pueden causar serios problemas en el futuro.

Costo de mantenimiento Los informes sugieren que el costo de mantenimiento es alto. Un estudio sobre la estimación del mantenimiento del software encontró que el costo de mantenimiento es tan alto como el 67% del costo del ciclo completo del proceso del software.

En promedio, el costo del mantenimiento del software es más del 50% de todas las fases SDLC. Hay varios factores que provocan que el costo de mantenimiento aumente, como:

Factores del mundo real que afectan el costo de mantenimiento 

La edad estándar de cualquier software se considera hasta 10 a 15 años.



Los softwares más antiguos, que estaban destinados a funcionar en máquinas lentas con menos memoria y capacidad de almacenamiento, no pueden mantenerse desafiantes frente a los softwares mejorados que vienen recientemente en el hardware moderno.



A medida que avanza la tecnología, resulta costoso mantener el software antiguo.



La mayoría de los ingenieros de mantenimiento son novatos y utilizan el método de prueba y error para corregir el problema.



A menudo, los cambios realizados pueden dañar fácilmente la estructura original del software, lo que dificulta cualquier cambio posterior.



Los cambios a menudo quedan sin documentar, lo que puede causar más conflictos en el futuro.

Factores finales del software que afectan el costo de mantenimiento 

Estructura del programa de software



Lenguaje de programación



Dependencia del entorno externo.



Fiabilidad y disponibilidad del personal.

Actividades de mantenimiento IEEE proporciona un marco para actividades de proceso de mantenimiento secuencial. Se puede usar de manera iterativa y se puede extender para que se puedan incluir elementos y procesos personalizados.

Estas actividades van de la mano con cada una de las siguientes fases:



Identificación y rastreo : implica actividades relacionadas con la identificación de requisitos de modificación o mantenimiento. Es generado por el usuario o el sistema mismo puede informar a través de registros o mensajes de error. Aquí, el tipo de mantenimiento también se clasifica.



Análisis : la modificación se analiza por su impacto en el sistema, incluidas las implicaciones de seguridad y protección. Si el impacto probable es severo, se busca una solución alternativa. Un conjunto de modificaciones requeridas se materializa en especificaciones de requisitos. Se analiza el costo de modificación / mantenimiento y se concluye la estimación.



Diseño : los nuevos módulos, que deben reemplazarse o modificarse, están diseñados según las especificaciones de requisitos establecidas en la etapa anterior. Los casos de prueba se crean para validación y verificación.



Implementación : los nuevos módulos se codifican con la ayuda del diseño estructurado creado en el paso de diseño. Se espera que cada programador realice pruebas unitarias en paralelo.



Prueba del sistema: la prueba de integración se realiza entre los módulos recién creados. Las pruebas de integración también se llevan a cabo entre los nuevos módulos y el sistema. Finalmente, el sistema se prueba como un todo, siguiendo procedimientos de prueba regresivos.



Prueba de aceptación : después de probar el sistema internamente, se prueba su aceptación con la ayuda de los usuarios. Si en este estado, el usuario se queja de algunos problemas que se abordan o se señalan para abordar en la próxima iteración.



Entrega : después de la prueba de aceptación, el sistema se implementa en toda la organización mediante un pequeño paquete de actualización o una instalación nueva del sistema. La prueba final se lleva a cabo en el extremo del cliente después de que se entrega el software. Se proporciona un centro de capacitación si es necesario, además de la copia impresa del manual del usuario.



Gestión del mantenimiento: la gestión de la configuración es una parte esencial del mantenimiento del sistema. Se ayuda con herramientas de control de versiones para controlar versiones, semi-versiones o gestión de parches.

Reingeniería de software Cuando necesitamos actualizar el software para mantenerlo en el mercado actual, sin afectar su funcionalidad, se llama reingeniería de software. Es un proceso minucioso donde se cambia el diseño del software y se reescriben los programas. El software heredado no puede seguir sintonizándose con la última tecnología disponible en el mercado. A medida que el hardware se vuelve obsoleto, la actualización del software se convierte en un dolor de cabeza. Incluso si el software envejece con el tiempo, su funcionalidad no lo hace. Por ejemplo, inicialmente Unix se desarrolló en lenguaje ensamblador. Cuando surgió el lenguaje C, Unix fue rediseñado en C, porque trabajar en lenguaje ensamblador era difícil.

Aparte de esto, a veces los programadores notan que pocas partes del software necesitan más mantenimiento que otras y también necesitan reingeniería.

Proceso de reingeniería  

Decide qué volver a diseñar. ¿Es todo el software o parte de él? Realice ingeniería inversa para obtener especificaciones del software existente.



Reestructurar el programa si es necesario. Por ejemplo, cambiar programas orientados a funciones en programas orientados a objetos.



Reestructurar los datos según sea necesario.



Aplique los conceptos de ingeniería avanzada para obtener un software rediseñado.

Hay pocos términos importantes utilizados en la reingeniería de software

Ingeniería inversa Es un proceso para lograr la especificación del sistema analizando a fondo y entendiendo el sistema existente. Este proceso puede verse como un modelo SDLC inverso, es decir, tratamos de obtener un nivel de abstracción más alto analizando niveles de abstracción más bajos. Un sistema existente es un diseño implementado previamente, del cual no sabemos nada. Luego, los diseñadores realizan ingeniería inversa al mirar el código e intentar obtener el diseño. Con el diseño en mano, intentan concluir las especificaciones. Por lo tanto, ir en reversa del código a la especificación del sistema.

Programa de reestructuración Es un proceso para reestructurar y reconstruir el software existente. Se trata de reorganizar el código fuente, ya sea en el mismo lenguaje de programación o de un lenguaje de programación a uno diferente. La reestructuración puede tener una reestructuración del código fuente y una reestructuración de datos o ambas. La reestructuración no afecta la funcionalidad del software, pero mejora la confiabilidad y la facilidad de mantenimiento. Los componentes del programa, que causan errores con mucha frecuencia, se pueden cambiar o actualizar con la reestructuración. La fiabilidad del software en una plataforma de hardware obsoleta se puede eliminar mediante la reestructuración.

Ingeniería Adelante La ingeniería avanzada es un proceso para obtener el software deseado a partir de las especificaciones disponibles que se redujeron mediante ingeniería inversa. Se supone que ya se realizó alguna ingeniería de software en el pasado. La ingeniería avanzada es igual que el proceso de ingeniería de software con solo una diferencia: se lleva a cabo siempre después de la ingeniería inversa.

Reutilización de componentes Un componente es una parte del código del programa de software, que ejecuta una tarea independiente en el sistema. Puede ser un módulo pequeño o un subsistema en sí mismo.

Ejemplo Los procedimientos de inicio de sesión utilizados en la web pueden considerarse como componentes, el sistema de impresión en el software puede verse como un componente del software. Los componentes tienen una alta cohesión de funcionalidad y una menor tasa de acoplamiento, es decir, funcionan de forma independiente y pueden realizar tareas sin depender de otros módulos. En OOP, los objetos que se diseñan son muy específicos para su preocupación y tienen menos posibilidades de ser utilizados en algún otro software.

En la programación modular, los módulos están codificados para realizar tareas específicas que se pueden utilizar en varios otros programas de software. Hay una vertical completamente nueva, que se basa en la reutilización de componentes de software, y se conoce como Ingeniería de Software Basada en Componentes (CBSE).

La reutilización se puede hacer en varios niveles. 

Nivel de aplicación : cuando se utiliza una aplicación completa como subsistema de software nuevo.



Nivel de componente : donde se utiliza el subsistema de una aplicación.



Nivel de módulos : donde se reutilizan los módulos funcionales. Los componentes de software proporcionan interfaces que se pueden utilizar para establecer comunicación entre diferentes componentes.

Proceso de reutilización Se pueden adoptar dos tipos de métodos: manteniendo los mismos requisitos y ajustando los componentes o manteniendo los mismos componentes y modificando los requisitos.



Especificación de requisitos: se especifican los requisitos funcionales y no funcionales, que un producto de software debe cumplir, con la ayuda del sistema existente, la entrada del usuario o ambos.



Diseño : este también es un paso estándar del proceso SDLC, donde los requisitos se definen en términos de lenguaje de software. Se crea la arquitectura básica del sistema en su conjunto y sus subsistemas.



Especificar componentes : al estudiar el diseño del software, los diseñadores segregan todo el sistema en componentes o subsistemas más pequeños. Un diseño de software completo se convierte en una colección de un gran conjunto de componentes que trabajan juntos.



Buscar componentes adecuados : los diseñadores recomiendan el repositorio de componentes de software para buscar el componente correspondiente, en función de la funcionalidad y los requisitos de software previstos.



Incorporar componentes : todos los componentes coincidentes se empaquetan para darles forma de software completo.

Descripción general de las herramientas de casos de software CASO significa C omputer Un ided S oftware E ngineering. Significa, desarrollo y mantenimiento de proyectos de software con la ayuda de varias herramientas de software automatizadas.

Herramientas CASE Las herramientas CASE son un conjunto de programas de aplicación de software, que se utilizan para automatizar las actividades SDLC. Los administradores de proyectos de software, analistas e ingenieros utilizan herramientas CASE para desarrollar un sistema de software. Hay varias herramientas CASE disponibles para simplificar varias etapas del ciclo de vida del desarrollo de software, como herramientas de análisis, herramientas de diseño, herramientas de gestión de proyectos, herramientas de gestión de bases de datos, herramientas de documentación, por nombrar algunas. El uso de herramientas CASE acelera el desarrollo del proyecto para producir el resultado deseado y ayuda a descubrir fallas antes de avanzar con la siguiente etapa en el desarrollo de software.

Componentes de herramientas CASE Las herramientas CASE se pueden dividir en términos generales en las siguientes partes según su uso en una etapa SDLC particular: 

Repositorio central : las herramientas CASE requieren un repositorio central, que puede servir como fuente de información común, integrada y coherente. El repositorio central es un lugar central de almacenamiento donde se almacenan las especificaciones del producto, los documentos de requisitos, los informes y diagramas relacionados y otra información útil sobre la gestión. El repositorio central también sirve como diccionario de datos.



Herramientas de mayúsculas: las herramientas de mayúsculas y minúsculas se utilizan en las etapas de planificación, análisis y diseño de SDLC.



Herramientas de minúsculas: las herramientas de minúsculas se utilizan en la implementación, prueba y mantenimiento.



Herramientas integradas de casos: las herramientas integradas de CASE son útiles en todas las etapas de SDLC, desde la recopilación de requisitos hasta las pruebas y la documentación.

Las herramientas CASE se pueden agrupar si tienen una funcionalidad, actividades de proceso y capacidad similares para integrarse con otras herramientas.

Alcance de las herramientas de casos El alcance de las herramientas CASE abarca todo el SDLC.

Tipos de herramientas de casos Ahora revisamos brevemente varias herramientas CASE

Herramientas de diagrama Estas herramientas se utilizan para representar los componentes del sistema, los datos y el flujo de control entre varios componentes de software y la estructura del sistema en forma gráfica. Por ejemplo, la herramienta Flow Chart Maker para crear diagramas de flujo de última generación.

Herramientas de modelado de procesos El modelado de procesos es un método para crear un modelo de proceso de software, que se utiliza para desarrollar el software. Las herramientas de modelado de procesos ayudan a los gerentes a elegir un modelo de proceso o modificarlo según los requisitos del producto de software. Por ejemplo, EPF Composer

Herramientas de gestión de proyectos Estas herramientas se utilizan para la planificación de proyectos, la estimación de costos y esfuerzos, la programación de proyectos y la planificación de recursos. Los gerentes deben cumplir estrictamente la ejecución del proyecto con cada paso mencionado en la gestión de proyectos de software. Las herramientas de gestión de proyectos ayudan a almacenar y compartir información del proyecto en tiempo real en toda la organización. Por ejemplo, Creative Pro Office, Trac Project, Basecamp.

Herramientas de documentación La documentación en un proyecto de software comienza antes del proceso del software, abarca todas las fases del SDLC y después de la finalización del proyecto. Las herramientas de documentación generan documentos para usuarios técnicos y usuarios finales. Los usuarios técnicos son en su mayoría profesionales internos del equipo de desarrollo que se refieren al manual del sistema, manual de referencia, manual de capacitación, manuales de instalación, etc. Los documentos del usuario final describen el funcionamiento y procedimientos del sistema, como el manual del usuario. Por ejemplo, Doxygen, DrExplain, Adobe RoboHelp para documentación.

Herramientas de análisis Estas herramientas ayudan a reunir los requisitos, comprueban automáticamente cualquier inconsistencia, inexactitud en los diagramas, redundancias de datos u omisiones erróneas. Por ejemplo, Accept 360, Accompa, CaseComplete para análisis de requisitos, Visible Analyst para análisis total.

Herramientas de diseño Estas herramientas ayudan a los diseñadores de software a diseñar la estructura de bloques del software, que puede desglosarse en módulos más pequeños utilizando técnicas de refinamiento. Estas herramientas proporcionan detalles de cada módulo e interconexiones entre módulos. Por ejemplo, diseño de software animado

Herramientas de gestion de configuracion Se lanza una instancia de software en una versión. Las herramientas de gestión de configuración se ocupan de  

Gestión de versiones y revisiones. Gestión de configuración de línea de base



Gestión de control de cambios

Las herramientas CASE ayudan en esto mediante el seguimiento automático, la gestión de versiones y la gestión de versiones. Por ejemplo, Fossil, Git, Accu REV.

Cambiar herramientas de control Estas herramientas se consideran parte de las herramientas de administración de configuración. Se ocupan de los cambios realizados en el software después de que se fija su línea base o cuando se lanza el software por primera vez. Las herramientas CASE automatizan el seguimiento de cambios, la administración de archivos, la administración de códigos y más. También ayuda a hacer cumplir la política de cambio de la organización.

Herramientas de programación Estas herramientas consisten en entornos de programación como IDE (Integrated Development Environment), biblioteca de módulos incorporados y herramientas de simulación. Estas herramientas proporcionan una ayuda integral en la creación de productos de software e incluyen características para simulación y pruebas. Por ejemplo, Cscope para buscar código en C, Eclipse.

Herramientas de prototipos El prototipo de software es una versión simulada del producto de software previsto. Prototype proporciona una apariencia inicial del producto y simula pocos aspectos del producto real. Las herramientas de creación de prototipos CASE vienen esencialmente con bibliotecas gráficas. Pueden crear interfaces de usuario y diseño independientes del hardware. Estas herramientas nos ayudan a construir prototipos rápidos basados en la información existente. Además, proporcionan simulación de prototipo de software. Por ejemplo, el compositor prototipo de Serena, Mockup Builder.

Herramientas de desarrollo web Estas herramientas ayudan a diseñar páginas web con todos los elementos aliados como formularios, texto, guiones, gráficos, etc. Las herramientas web también proporcionan una vista previa en vivo de lo que se está desarrollando y cómo se verá una vez finalizado. Por ejemplo, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Herramientas de aseguramiento de calidad El aseguramiento de la calidad en una organización de software es monitorear el proceso de ingeniería y los métodos adoptados para desarrollar el producto de software a fin de garantizar la conformidad de la calidad según los estándares de la organización. Las herramientas de control de calidad consisten en herramientas de configuración y control de cambios y

herramientas de prueba de software. Por ejemplo, SoapTest, AppsWatch, JMeter.

Herramientas de mantenimiento El mantenimiento del software incluye modificaciones en el producto de software después de que se entrega. El registro automático y las técnicas de informe de errores, la generación automática de tickets de error y el análisis de causa raíz son pocas herramientas CASE, que ayudan a la organización del software en la fase de mantenimiento de SDLC. Por ejemplo, Bugzilla para el seguimiento de defectos, HP Quality Center.