Mi hermano pequeño está arrodillado desnudo en la nieve y pidiendo respuestas. Incluso los hombres fuertes pueden entrar. Les ruego a todos que respondan con entusiasmo. Esto influye en mi futuro.
Ingeniería de software
La ingeniería de software siempre ha carecido de una definición unificada. Muchos académicos y organizaciones han dado sus propias definiciones:
Boehm: utiliza el conocimiento científico y tecnológico moderno. diseñar y construir programas informáticos y la documentación relacionada necesaria para desarrollar, operar y mantener estos programas.
IEEE: La ingeniería de software es un enfoque sistemático para desarrollar, operar, mantener y reparar software.
Fritz Bauer: Establezca y utilice principios de ingeniería sólidos para obtener de forma económica un software fiable que pueda ejecutarse eficazmente en máquinas reales.
El marco de la Ingeniería del Software (Ingeniería de Software) se puede resumir en: objetivos, procesos y principios.
(1) Objetivo de la ingeniería de software: producir productos que sean correctos, utilizables y asequibles. La corrección se refiere al grado en que un producto de software logra la funcionalidad prevista. La usabilidad se refiere al grado en que la estructura básica, la implementación y la documentación del software están disponibles para los usuarios. El costo apropiado se refiere a la medida en que el costo total del desarrollo y operación del software cumple con los requisitos del usuario. Hay muchos problemas que resolver en la realización de estos objetivos, tanto en la teoría como en la práctica, lo que limita la selección de procesos, modelos de procesos y métodos de ingeniería.
(2) Proceso de ingeniería de software: los pasos necesarios para producir un producto de software que en última instancia pueda cumplir con los requisitos y alcanzar los objetivos de ingeniería. El proceso de ingeniería de software incluye principalmente el proceso de desarrollo, el proceso de operación y el proceso de mantenimiento. Cubren actividades tales como requisitos, diseño, implementación, validación y mantenimiento. Las actividades de requisitos incluyen análisis de problemas y análisis de requisitos. El análisis de problemas obtiene definiciones de requisitos, también conocidas como especificaciones de requisitos de software. El análisis de requisitos genera especificaciones funcionales. Las actividades de diseño generalmente incluyen diseño de esquema y diseño detallado. El diseño general establece toda la estructura del sistema de software, incluidas descripciones de subsistemas, módulos y niveles relacionados, y definiciones de interfaz para cada módulo. El diseño detallado produce descripciones de módulos que pueden ser utilizadas por los programadores, incluidas descripciones de estructuras de datos y descripciones de procesamiento en cada módulo. Las actividades de implementación convierten los resultados del diseño en código de programa ejecutable. Las actividades de confirmación se ejecutan a lo largo de todo el proceso de desarrollo para lograr una confirmación posterior a la finalización para garantizar que el producto final cumpla con los requisitos del usuario. Las actividades de mantenimiento incluyen ampliación, modificación y mejora durante el uso. Junto al proceso anterior, también existen procesos de gestión, procesos de soporte, procesos de formación, etc.
(3) Los principios de la ingeniería de software se refieren a los principios que se deben seguir durante el proceso de desarrollo de software en torno al diseño de ingeniería, el soporte de ingeniería y la gestión de ingeniería.
¿Qué principios se deben seguir en la ingeniería de software?
Se han propuesto los siguientes cuatro principios básicos en torno al diseño de ingeniería, el soporte de ingeniería y la gestión de ingeniería:
(1 ) Seleccionar el modelo de desarrollo apropiado
Este principio es relevante para el diseño de sistemas. En el diseño de sistemas, los requisitos de software, los requisitos de hardware y otros factores se restringen e influyen mutuamente y, a menudo, requieren compensaciones. Por lo tanto, es necesario reconocer la variabilidad de las definiciones de requisitos y adoptar modelos de desarrollo apropiados para garantizar que los productos de software cumplan con los requisitos del usuario.
(2) Adoptar métodos de diseño apropiados
En el diseño de software, generalmente es necesario considerar las características del software como modularidad, abstracción y ocultación de información, localización, consistencia y adaptabilidad. . Los métodos de diseño apropiados facilitan la implementación de estas características para lograr los objetivos de la ingeniería de software.
(3) Proporcionar soporte de ingeniería de alta calidad
Si un trabajador quiere hacer bien su trabajo, primero debe afilar sus herramientas. En ingeniería de software, las herramientas y entornos de software son muy importantes para respaldar el proceso de software. La calidad y el costo de un proyecto de ingeniería de software dependen directamente de la calidad y eficacia del soporte brindado al proyecto de ingeniería de software.
(4) Preste atención a la gestión de la ingeniería de software
La gestión de la ingeniería de software afecta directamente el uso efectivo de los recursos disponibles, la producción de productos de software que cumplan los objetivos y la mejora de la capacidad de producción de las organizaciones de software. Por lo tanto, una ingeniería de software eficaz sólo se puede lograr cuando el proceso de software se gestiona de forma eficaz.
La ingeniería de software es una disciplina de ingeniería que guía el desarrollo y mantenimiento de software informático.
Utilizar conceptos, principios, técnicas y métodos de ingeniería para desarrollar y mantener software, combinando técnicas de gestión correctas probadas y comprobadas con los mejores métodos técnicos disponibles actualmente, esto es ingeniería de software.
La ingeniería de software enfatiza el uso de la metodología del ciclo de vida y diversas técnicas de análisis y diseño estructural.
Fueron desarrollados en la década de 1970 en respuesta a la creciente complejidad del software de aplicación, los largos ciclos de desarrollo y la frecuente insatisfacción de los usuarios con los productos de software. Una estrategia comúnmente utilizada por los humanos a la hora de resolver problemas complejos
es "dividirlos individualmente", que es una estrategia de descomponer el problema y luego resolver cada subproblema por separado
. La metodología del ciclo de vida utilizada en ingeniería de software consiste en descomponer los complejos problemas del desarrollo y mantenimiento de software desde una perspectiva temporal
y dividir el largo ciclo de vida del software en varias etapas, cada etapa tiene
relativamente independiente. /p>
tareas y luego complete gradualmente las tareas en cada etapa. Al desarrollar software utilizando la metodología de la ingeniería de software,
comience desde el análisis lógico abstracto de la tarea y desarrollela etapa por etapa. La finalización de las tareas de la etapa anterior es la premisa y fundamento para iniciar el trabajo en la siguiente etapa, y la finalización de las tareas de la última etapa suele ser
la solución propuesta en la etapa anterior. ización más concreta, añadiendo más detalles físicos. Existen estándares estrictos para el comienzo y el final de cada etapa. Para dos etapas adyacentes, el estándar final de la etapa anterior es el mismo que el estándar de inicio. Antes del final de cada etapa, se debe realizar una revisión técnica formal y estricta
y una revisión de gestión para comprobar los resultados de desarrollo de esta etapa tanto desde el aspecto técnico como de gestión.
Esta etapa se considera final; si la inspección falla, se debe realizar el retrabajo necesario y revisar nuevamente el retrabajo.
Uno de los principales criterios de revisión es que en cada etapa se debe entregar documentación de alta calidad "actualizada" (es decir, completamente consistente con el software que se está desarrollando) para garantizar que al final del proyecto de desarrollo de software Recibir
una configuración de software completa y precisa para su uso. Los documentos son herramientas de comunicación. Describen de forma clara y precisa
lo que se sabe sobre el proyecto hasta este momento y establecen las bases para los siguientes pasos. Además, los documentos también sirven como memorandos. Si están incompletos, es posible que se haya olvidado algún trabajo.
Estos detalles faltantes deben completarse antes de pasar a la siguiente etapa del ciclo de vida. Al completar las tareas en cada etapa del ciclo de vida, se debe utilizar un método técnico sistemático (análisis estructural o tecnología de diseño estructural) que sea adecuado para las características de las tareas en esa etapa.
Dividir el ciclo de vida del software en varias etapas Las tareas de cada etapa son relativamente independientes y sencillas
Facilita la división del trabajo y la colaboración entre diferentes personas, reduciendo así el coste. de todo el proyecto de desarrollo de software grado de dificultad, adoptar técnicas de gestión científica y buenos métodos técnicos en cada etapa del ciclo de vida del software, y comenzar desde la tecnología y la gestión antes del final de cada etapa. >
Se lleva a cabo una revisión estricta desde dos perspectivas, y la siguiente etapa de trabajo se iniciará solo después de pasar la prueba. Esto permite que todo el proceso del proyecto de desarrollo de software se lleve a cabo de manera ordenada y garantiza la calidad. del software.
Calidad, mejorando especialmente la mantenibilidad del software. En resumen, la adopción de la metodología de ingeniería de software puede mejorar en gran medida la tasa de éxito del desarrollo de software y la productividad del desarrollo de software también puede mejorar significativamente.
Actualmente existen muchas formas de dividir las etapas del ciclo de vida del software. La escala del software, el tipo, el método de desarrollo,
El entorno de desarrollo y la metodología utilizada durante el desarrollo afectan la división del ciclo de vida del software. etapas. Un principio básico que se debe seguir al dividir las etapas del ciclo de vida del software es hacer que las tareas en cada etapa sean lo más independientes posible. La naturaleza de cada tarea en la misma etapa debe ser lo más clara posible. reduciendo así la complejidad de las tareas en cada etapa, simplificando la conexión entre las diferentes etapas y favoreciendo la organización y gestión de proyectos de desarrollo de software. En términos generales, el ciclo de vida del software consta de tres períodos: definición del software, desarrollo del software y mantenimiento del software, y cada período se divide en varias etapas. La siguiente discusión está dirigida principalmente al software de aplicación y es básicamente aplicable al software del sistema.
La tarea del período de definición de software es determinar el objetivo general que debe completar el proyecto de desarrollo de software, determinar la viabilidad del proyecto
y derivar las estrategias que se deben utilizar para lograrlo; lograr los objetivos del proyecto y las funciones que el sistema debe completar; estimar los recursos y costos necesarios para completar el proyecto y desarrollar un cronograma del proyecto. El trabajo en este período generalmente se denomina análisis del sistema
y lo completa el analista del sistema. El período de definición del software generalmente se divide en tres fases, a saber, definición del problema, estudio de viabilidad y análisis de requisitos.
El período de desarrollo diseña e implementa específicamente el software definido en el período anterior. Suele estar compuesto por las siguientes cuatro etapas:
Diseño general, diseño detallado, codificación y pruebas unitarias. Pruebas integrales.
La principal tarea durante el periodo de mantenimiento es hacer que el software satisfaga las necesidades de los usuarios de forma permanente. Específicamente, cuando se encuentran errores durante el uso del software, deben corregirse cuando cambia el entorno, el software debe modificarse para adaptarse al nuevo entorno cuando los usuarios tienen nuevos requisitos. El software debe mejorarse de manera oportuna para cumplir; nuevas necesidades de los usuarios. Por lo general, el período de mantenimiento no
se divide en etapas, sino que cada actividad de mantenimiento es esencialmente un proceso de definición y desarrollo comprimido y simplificado
.
A continuación se presentan brevemente las tareas básicas y los criterios finales de cada etapa del ciclo de vida del software.
1 Definición del problema
La pregunta clave que se debe responder en la etapa de definición del problema: "¿Cuál es el problema a resolver si no sabes cuál es?" , intentar Resolver este problema es obviamente ciego y solo hará perder tiempo y dinero. El resultado final puede no tener sentido. Aunque la necesidad de definir claramente el problema es obvia, en la práctica puede ser el paso que más se pasa por alto.
A través de su trabajo en la fase de definición del problema, el analista de sistemas debe producir un informe escrito sobre la naturaleza, los objetivos de ingeniería y
tamaño del problema. A través de entrevistas y encuestas con los usuarios reales del sistema y los jefes de los departamentos usuarios, el analista
escribe brevemente su comprensión del problema y lo discute cuidadosamente en la reunión entre los usuarios y los jefes. de los departamentos usuarios
Escriba un informe para aclarar cualquier ambigüedad, corregir cualquier entendimiento incorrecto y finalmente producir un documento que satisfaga a ambas partes
La fase de definición del problema es la fase más corta del ciclo de vida del software y generalmente toma solo un día o incluso menos
tiempo.
2 Estudio de Viabilidad
La pregunta clave a responder en esta etapa: "Existen soluciones factibles a los problemas identificados en la etapa anterior
"Para Para responder a esta pregunta, los analistas de sistemas deben realizar un proceso de diseño y análisis del sistema muy comprimido y simplificado, es decir, un proceso de análisis y diseño a un nivel alto más abstracto.
El estudio de viabilidad debe ser relativamente breve. La tarea en esta etapa no es resolver el problema específicamente, sino estudiar el alcance del problema.
Explorar si el problema vale la pena. resolver y si es factible la solución.
Los informes sobre los objetivos y el alcance del proyecto durante la fase de definición del problema suelen ser vagos. La etapa del estudio de viabilidad
debe derivar un modelo lógico de alto nivel del sistema (generalmente representado por un diagrama de flujo de datos) y, en base a esto, determinar más la escala y los objetivos del proyecto.
de forma precisa y específica. Luego, el analista estima con mayor precisión los costos y beneficios del sistema. Una de las principales tareas de esta etapa es un análisis cuidadoso de costo/beneficio del sistema propuesto.
Los resultados del estudio de viabilidad son una base importante para que el jefe del departamento tome una decisión sobre si continuar con el proyecto. En términos generales, sólo la inversión es probable que consiga mayores beneficios. aquellos que vale la pena continuar
. Las etapas posteriores al estudio de viabilidad requerirán una mayor inversión en mano de obra y recursos materiales. Terminar oportunamente los proyectos que no valen la inversión puede evitar mayores desperdicios.
3 Análisis de requisitos
La tarea en esta etapa todavía no es resolver el problema específicamente, sino determinar con precisión "para resolver este problema,
el sistema de destino debe hacer "Qué" determina principalmente qué funciones debe tener el sistema de destino.
Los usuarios comprenden los problemas que enfrentan y saben qué se debe hacer, pero a menudo no pueden expresar sus requisitos de manera completa y precisa
Y mucho menos cómo usar las computadoras para resolver sus problemas; los desarrolladores de software saben
cómo utilizar el software para implementar los requisitos de las personas, pero los requisitos específicos de usuarios específicos no están del todo claros. Por lo tanto, los analistas de sistemas
deben trabajar estrechamente con los usuarios durante la etapa de análisis de requisitos e intercambiar completamente información para llegar a un modelo lógico del sistema
confirmado por los usuarios. El modelo lógico del sistema suele estar representado por diagramas de flujo de datos, diccionarios de datos y breves descripciones de algoritmos.
El modelo lógico del sistema determinado en la etapa de análisis de requisitos es la base para el posterior diseño e implementación del sistema objetivo, por lo que
debe reflejar de forma precisa y completa los requisitos del usuario. Los analistas de sistemas suelen ser expertos en software informático y a los expertos técnicos generalmente les gusta comenzar rápidamente con diseños específicos. Sin embargo, una vez que los analistas comienzan a hablar sobre los detalles del diseño del programa, desconectarán a los usuarios para que no puedan continuar haciendo sus solicitudes y sugerencias. El método de diseño y análisis estructural utilizado en la ingeniería de software estipula criterios finales específicos para cada etapa. La etapa de análisis de requisitos debe proporcionar un modelo lógico del sistema completo y preciso. La siguiente etapa solo se puede ingresar después de la confirmación del usuario, lo que puede prevenir y superar de manera efectiva. Tendencia a precipitarse hacia un diseño específico.
4 Diseño general
La pregunta clave que debe responderse en esta etapa es: "En resumen, ¿cómo se debe resolver este problema?" En definitiva, se deben plantear varias consideraciones para posibles soluciones. Por ejemplo, si algunas de las funciones principales del sistema de destino se completan automáticamente mediante computadoras o manualmente si se usan computadoras, si se usa procesamiento por lotes o interacción persona-computadora, almacenamiento mediante un sistema de archivos tradicional o una base de datos... Normalmente debería considerar al menos
las siguientes categorías de posibles soluciones:
Soluciones de bajo coste. El sistema solo puede completar el trabajo más necesario y no puede hacer más.
Solución de coste medio. Un sistema de este tipo no sólo puede realizar bien las tareas previstas y ser fácil de usar, sino que también puede tener ciertas funciones y características que no están especificadas específicamente por el usuario. Aunque el usuario no
estableció estos requisitos específicos, el analista del sistema concluyó, basándose en su conocimiento y experiencia, que estas capacidades
adicionales resultarían valiosas en la práctica.
Sistema "perfecto" de alto coste. Un sistema de este tipo tiene todas las funciones y características que un usuario pueda desear.
Los analistas de sistemas deben utilizar diagramas de flujo del sistema u otras herramientas para describir cada sistema posible, estimar los costos y beneficios de cada
opción y deben sopesar completamente las diversas opciones. desventajas del sistema (la mejor solución) y desarrollar un plan detallado para implementar el sistema recomendado. Si el usuario acepta el sistema recomendado por el analista, se podrá completar la otra tarea principal de esta etapa.
El trabajo anterior ha determinado la estrategia para resolver el problema y qué programas se necesitan para el sistema objetivo, pero ¿cómo diseñar
estos programas? Un principio básico del diseño estructural es que el programa debe ser modular, es decir, un programa grande debe estar compuesto por muchos módulos de tamaño moderado organizados en una estructura jerárquica razonable. La segunda
tarea principal de la fase de diseño general es diseñar la estructura del software, es decir, determinar en qué módulos consta el programa y las
relaciones entre los módulos. La estructura del software suele representarse mediante un diagrama de jerarquía o un diagrama de estructura.
5 Diseño de detalle
La etapa de diseño general propone soluciones al problema de una forma más abstracta y general.
La tarea de la fase de diseño detallado
es concretar la solución, es decir, responder a la siguiente pregunta clave: "¿Cómo debería implementarse este
sistema específicamente
La tarea en esta etapa no es escribir el programa, sino diseñar las especificaciones detalladas del programa. La función de dichas especificaciones es muy similar a los planos de ingeniería que suelen utilizar los ingenieros en otros campos de la ingeniería. Deben contener los detalles necesarios a partir de los cuales los programadores puedan escribir código de programa práctico.
Normalmente se utiliza el diagrama HIPO (diagrama jerárquico más diagrama de entrada/proceso/salida) o el lenguaje PDL (Process Design Language
) para describir los resultados del diseño detallado.
6 Codificación y pruebas unitarias
La tarea clave en esta etapa es escribir módulos de programa correctos que sean fáciles de entender y mantener.
Los programadores deben elegir un lenguaje de programación de alto nivel apropiado (usar lenguaje ensamblador si es necesario) en función de la naturaleza del sistema de destino y el entorno real, y traducir los resultados detallados del diseño a un programa escrito en el. idioma elegido
, y pruebe cuidadosamente cada módulo escrito.
7 Pruebas integrales
La tarea clave en esta etapa es hacer que el software cumpla con los requisitos predeterminados
mediante varios tipos de pruebas (y la correspondiente depuración).
Las pruebas más básicas son las pruebas de integración y las pruebas de aceptación. La llamada prueba de integración consiste en ensamblar los módulos que han sido probados mediante la prueba unitaria de acuerdo con una estrategia seleccionada basada en la estructura de software diseñada
y realizar los procedimientos necesarios en el programa durante el proceso de ensamblaje. /p>
prueba. La llamada prueba de aceptación consiste en aceptar el sistema objetivo por parte del usuario (o con la participación activa del usuario) de acuerdo con las especificaciones (generalmente determinadas durante la etapa de análisis de requisitos).
Si es necesario, el sistema de destino se puede probar e inspeccionar más a fondo mediante pruebas in situ o funcionamiento en paralelo.
Para que los usuarios participen activamente en la prueba de aceptación y utilicen el sistema correctamente
eficazmente después de que el sistema se ponga en funcionamiento, generalmente es necesario que el usuario, formal o informalmente, capacitación.
La confiabilidad del software se puede predecir mediante el análisis de los resultados de las pruebas de software; a la inversa, en función de los requisitos de confiabilidad del software
también se puede determinar cuándo puede finalizar el proceso de prueba y depuración. fin.
El plan de prueba, el plan de prueba detallado y los resultados reales de la prueba deben guardarse
en documentación formal como un componente integral de la configuración del software.
8 Mantenimiento del software
La tarea clave de la fase de mantenimiento es hacer que el sistema satisfaga permanentemente las necesidades del
usuario a través de diversas actividades de mantenimiento necesarias.
Suele haber cuatro tipos de actividades de mantenimiento: mantenimiento correctivo, que consiste en diagnosticar y corregir errores de software descubiertos durante el uso; mantenimiento adaptativo, que consiste en modificar el software para adaptarse a los cambios del entorno, <; /p>
mejorar o ampliar el software para hacerlo más completo según los requisitos del usuario, mantenimiento preventivo, es decir, modificar el software para prepararlo para futuras actividades de mantenimiento
por adelantado.
Aunque la fase de mantenimiento no se divide en fases más pequeñas, de hecho, cada actividad de mantenimiento
debe pasar por el proceso de plantear los requisitos de mantenimiento (o informar problemas) y analizar el proceso de mantenimiento. requisitos, presentar requisitos de mantenimiento, proponer
planes de mantenimiento, aprobar planes de mantenimiento, determinar planes de mantenimiento, modificar el diseño de software, modificar programas, probar programas,
revisar y aceptar y una serie. de pasos, por lo que, en esencia, lo anterior es un proceso de desarrollo y definición de software comprimido y simplificado.
Todo debe hacerse planteando requisitos de mantenimiento (o informando problemas), analizando requisitos de mantenimiento, proponiendo requisitos de mantenimiento, proponiendo
planes de mantenimiento, aprobando planes de mantenimiento, determinando planes de mantenimiento y modificando diseños de software Una serie de pasos como modificar el programa, probar el programa, revisión y aceptación, etc. Por lo tanto, es esencialmente un proceso de definición y desarrollo de software comprimido y simplificado.