1 Definición del problema\x0d\\x0d\ 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 y?" intente resolverlo, obviamente es ciego, solo perderá tiempo y dinero y el resultado final puede no tener sentido. Aunque la necesidad de definir el problema exactamente es obvia, en la práctica puede ser el paso que más se pasa por alto. \x0d\\x0d\ A través del trabajo en la fase de definición del problema, el analista de sistemas debe producir un informe escrito sobre la naturaleza del problema, los objetivos del proyecto y la escala. A través de entrevistas y encuestas con usuarios reales del sistema y jefes de departamentos que utilizan el sistema, el analista escribe brevemente su comprensión del problema y analiza cuidadosamente este informe escrito en reuniones con usuarios y jefes de departamentos que utilizan el sistema para aclarar cualquier ambigüedad. , corregir el entendimiento incorrecto y finalmente elaborar un documento que sea satisfactorio para ambas partes. \x0d\\x0d\ La fase de definición del problema es la fase más corta en el ciclo de vida del software y generalmente toma solo un día o menos. \x0d\\x0d\2 Estudio de viabilidad\x0d\\x0d\ La pregunta clave que debe responderse en esta etapa: "¿Existe una solución factible al problema identificado en la etapa anterior? Para responder a esta pregunta, ¿hay que realizar un análisis del sistema?" Los ingenieros necesitan llevar a cabo un proceso de diseño y análisis de sistemas muy comprimido y simplificado, es decir, un proceso de análisis y diseño a un nivel alto más abstracto. \x0d\\x0d\ 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 y explorar si vale la pena resolverlo y si existe una solución factible. . \x0d\\x0d\ 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, sobre esta base, la escala y los objetivos del proyecto deben determinarse de manera más 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. \x0d\\x0d\ Los resultados del estudio de viabilidad son una base importante para que el jefe del departamento usuario tome una decisión sobre si continuar con el proyecto. En términos generales, sólo se consideran aquellos proyectos en los que es probable que la inversión genere mayores beneficios. vale la pena continuar. Las etapas posteriores al estudio de viabilidad requerirán una mayor inversión en mano de obra y recursos materiales. Detener a tiempo proyectos en los que no vale la pena invertir puede evitar mayores desperdicios. \x0d\\x0d\3Análisis de requisitos\x0d\\x0d\ La tarea en esta etapa todavía no es resolver el problema específicamente, sino determinar con precisión "qué debe hacer el sistema de destino para resolver este problema". lo tiene. \x0d\\x0d\ Los usuarios comprenden los problemas que enfrentan y saben qué se debe hacer, pero a menudo no pueden expresar de manera completa y precisa sus requisitos, y mucho menos cómo usar las computadoras para resolver sus problemas. Los desarrolladores de software saben cómo usar el software para implementar lo que las personas; Pregunte, pero los requisitos específicos para un usuario específico 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 información completamente para llegar a un modelo lógico del sistema que haya sido 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. \x0d\\x0d\ El modelo lógico del sistema determinado en la etapa de análisis de requisitos es la base para el diseño e implementación posteriores del sistema objetivo, por lo que debe reflejar de manera precisa y completa los requisitos del usuario. Los analistas de sistemas suelen ser expertos en software informático. Por lo general, a los expertos técnicos les gusta comenzar a trabajar en diseños específicos rápidamente. Sin embargo, una vez que los analistas comienzan a hablar sobre los detalles del diseño del programa, se desconectarán de los usuarios y les impedirán continuar haciendo sus solicitudes y sugerencias. . El método de diseño y análisis estructural utilizado en la ingeniería de componentes 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, que solo puede ingresar a la siguiente etapa después de la confirmación del usuario. tendencia a precipitarse hacia diseños concretos. \x0d\\x0d\4Diseño general\x0d\\x0d\ La pregunta clave que debe responderse en esta etapa es: "En resumen, ¿cómo debería resolverse este problema? \x0d\\x0d\ Primero, varias opciones posibles". considerarse solución.
Por ejemplo, ¿deberían completarse algunas de las funciones principales del sistema de destino automáticamente mediante computadoras o manualmente, si se utilizan computadoras?, ¿deberían usarse sistemas de archivos o bases de datos tradicionales para el almacenamiento de información? Por lo general, se deben considerar al menos los siguientes tipos de posibles soluciones:\x0d\\x0d\ Soluciones de bajo costo. El sistema sólo puede completar el trabajo más necesario y no puede realizar ningún trabajo adicional. \x0d\\x0d\ Solución de costo 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 planteó 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. \x0d\\x0d\ Sistema "perfecto" de alto costo. Un sistema de este tipo tiene todas las funciones y características que un usuario pueda desear. \x0d\\x0d\ 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 recomendar una mejor solución basada en sopesar completamente los pros y los contras de varias buenas opciones. (mejor solución) y desarrollar planes detallados para implementar el sistema recomendado. Si el usuario acepta el sistema recomendado por el analista, puede comenzar el otro trabajo importante de esta fase. \x0d\\x0d\ El trabajo anterior ha determinado la estrategia para resolver el problema y qué programas se necesitan para el sistema de destino, 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 en la etapa de diseño general es diseñar la estructura del software, es decir, determinar en qué módulos consta el programa y la relación entre los módulos. La estructura del software suele representarse mediante un diagrama de jerarquía o un diagrama de estructura. \x0d\\x0d\5Diseño detallado\x0d\\x0d\ La etapa de diseño general propone soluciones al problema de una manera más abstracta y general. La tarea de la etapa 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?" \x0d\\x0d\ La tarea de esta etapa no es escribir el programa. , sino para diseñar el programa con especificaciones detalladas. Estas especificaciones funcionan de forma muy parecida 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 el código del programa real. \x0d\\x0d\6 Codificación y pruebas unitarias \x0d\\x0d\ La tarea clave en esta etapa es escribir módulos de programa correctos que sean fáciles de entender y mantener. \x0d\\x0d\ Los programadores deben seleccionar un lenguaje de programación de alto nivel apropiado (use 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 en programas escritos en el lenguaje seleccionado. programa y pruebe cuidadosamente cada módulo escrito. \x0d\\x0d\7 Pruebas integrales \x0d\\x0d\ La tarea clave en esta etapa es hacer que el software cumpla con los requisitos predeterminados a través de varios tipos de pruebas (y la depuración correspondiente). \x0d\\x0d\ 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 pruebas unitarias de acuerdo con una estrategia seleccionada basada en la estructura de software diseñada y realizar las pruebas necesarias en el programa durante el proceso de ensamblaje. 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). \x0d\\x0d\ Si es necesario, el sistema de destino se puede probar e inspeccionar más a fondo mediante pruebas in situ o funcionamiento en paralelo. \x0d\\x0d\ Para permitir que los usuarios participen activamente en la prueba de aceptación y utilicen el sistema de manera correcta y efectiva después de que el sistema se ponga en operación de producción, los usuarios generalmente necesitan recibir capacitación de manera formal o informal. \x0d\\x0d\ A través del análisis de los resultados de las pruebas de software, se puede predecir la confiabilidad del software y, 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. \x0d\\x0d\ El plan de prueba, el plan de prueba detallado y los resultados reales de la prueba deben guardarse en documentación formal como parte integral de la configuración del software.
\x0d\\x0d\8Mantenimiento de software\x0d\\x0d\ La tarea clave de la fase de mantenimiento es hacer que el sistema satisfaga permanentemente las necesidades de los usuarios a través de diversas actividades de mantenimiento necesarias. \x0d\\x0d\ Generalmente existen cuatro tipos de actividades de mantenimiento: mantenimiento correctivo, que significa diagnosticar y corregir errores de software descubiertos durante el uso; mantenimiento adaptativo, que significa modificar el software para adaptarse a los cambios en el entorno y mantenimiento de perfección; significa, según los requisitos del Usuario, mejorar o ampliar el software para hacerlo más completo. mantenimiento preventivo significa modificar el software para prepararlo con anticipación para futuras actividades de mantenimiento; \x0d\\x0d\ Aunque la etapa de mantenimiento no se divide en etapas más pequeñas, de hecho, cada actividad de mantenimiento debe pasar por plantear los requisitos de mantenimiento (o informar problemas), analizar los requisitos de mantenimiento, proponer requisitos de mantenimiento y proponer planes de mantenimiento y aprobar. El plan de mantenimiento, determinar el plan de mantenimiento, modificar el diseño del software, modificar el programa, probar el programa, revisar y aceptar una serie de pasos, por lo que es esencialmente un proceso de definición y desarrollo de software comprimido y simplificado. \x0d\\x0d\ Todo debe hacerse proponiendo 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, modificando diseños de software, modificando programas, probando programas, y revisar la aceptación y una serie de pasos, por lo que es esencialmente un proceso completo comprimido y simplificado de definición y desarrollo de software.