Empresas de software y empresas que no son de software
Empresas que no son de software
Análisis de requisitos-diseño del esquema-codificación del programa-pruebas del programa-entrega de software-aceptación del cliente- mantenimiento de código
Almacén de software
Análisis de requisitos - Diseño de esquema - Diseño detallado - Codificación de programas - Pruebas de programas - Entrega de software - Aceptación del cliente - Mantenimiento de código
Análisis de requisitos
p>Antes de la aparición de un software, sólo algunas personas tenían la idea, necesito algo como esto (quiero tener un bebé) para gestionar mis cosas. En este momento, cuando surge una idea y es necesaria, acudirá al analista de demanda de la empresa de software para consulta. En este momento, un software está preñado, lo que equivale a iniciar el desarrollo. El análisis de requisitos consiste en describir las funciones generales después de escuchar los requisitos. Utilice Word o Axure para dibujar una demostración sencilla para que la vean los usuarios. Después de varias confirmaciones, el analista de requisitos finalmente confirmará si la función está completa y luego pasaremos al siguiente paso: diseñar el esquema.
Diseño general
¿Qué hace principalmente esta función? Muchas empresas piensan que es innecesario, pero en realidad es muy necesario. Esto equivale a planificar primero cómo superar el embarazo de forma segura. Para el software, es la lógica de procesamiento del software, cómo va un proceso, qué módulos se necesitan, cómo ejecutarlo, cuántas interfaces se necesitan, cómo mantenerlo en el futuro, etc. ¿Por qué hacer estas cosas para prepararse para el siguiente paso: el diseño detallado?
Diseño detallado
Algunas personas dicen que el diseño detallado es un paso muy problemático, pero en realidad no es un paso muy problemático. Creo que este es el paso más difícil. El diseño detallado se utiliza principalmente para confirmar detalles, como el nombre de la interfaz, el nombre del controlador, cuántos controladores hay y quién los llamará. Esto no puede estar mal, porque los programadores deben observar este desarrollo más adelante. Como sea que lo llames, lo escriben, por lo que el error aquí significa que eventualmente cometerán errores al codificar.
Código de cultivo
Muchas personas piensan que esto es solo una imitación y escriben directamente después de leer el libro de diseño. Esta es la teoría, pero ¿por qué todavía hay tantos errores? Gran parte del motivo no es el diseño (por supuesto que es posible), pero gran parte del motivo se debe a irregularidades. También está la cuestión de si las personas de un equipo de proyecto pueden trabajar juntas para procesar el código y cómo mejorar la eficiencia de la codificación. Todos estos problemas son problemas que surgen durante el proceso de codificación. Esto equivale a si las mujeres embarazadas comen según la normativa al ejecutar esa comida fija.
Prueba del programa
Este paso es muy importante, probar. No podemos decir que los usuarios lo utilizarán directamente después de escribirlo. Esto no es realista. Lo que tenemos que hacer es realizar primero una prueba sistemática al departamento de pruebas. Por supuesto, esta prueba no coincide con lo que piensan los usuarios. Pueden ser violentos. Cuando los usuarios normales lo utilizan, pueden ver el efecto con un solo clic. Pero al realizar la prueba, hacen clic como locos. Saben que se detendrán cuando piensen que no hay nadie más violento que ellos en el mundo. Por supuesto, este es un buen probador, muchas pruebas no serán así. Piensan que no hay ningún problema en el uso normal, pero de hecho, si un software es bueno o no depende en gran medida de la solidez de las pruebas de los evaluadores. Finalmente, simplemente escriba un informe de prueba.
Entrega del software
Si no hay problemas después de la prueba, puede escribir un manual de instalación, que en realidad es una guía del usuario.
Aceptación del cliente
Tras la entrega, tras una sencilla prueba, el cliente sintió que era lo que pensaba, por lo que recibió la mercancía y pagó.
Mantenimiento de Code Farmer
¿Todo estará bien después de la aceptación? Por supuesto que no. Un software tendrá problemas después de usarse durante un período de tiempo, por lo que siempre será necesario que alguien lo mantenga. Por supuesto, no significa que tengas que mantenerlo solo porque hayas señalado el problema. La razón principal es que el software cambia de funcionalidad según las diferentes necesidades. Este proceso también es un proceso de mantenimiento. ¿Cuántas generaciones se ha actualizado QQ? ¿No es solo un proceso de mantenimiento?
Proyecto Reconstrucción
Este es un proyecto. Si surge una nueva tecnología, la funcionalidad permanece sin cambios por el bien de la experiencia del usuario. Por ejemplo, antes se escribió usando SSH, pero la velocidad de ejecución era muy baja. Con SpringBoot todo el mundo lo está utilizando y la respuesta de los usuarios es muy buena.
Luego, en este momento, es necesario transformar el proyecto y utilizar nueva tecnología para volver a implementar las funciones anteriores.
Eso es básicamente todo. Además, las personas cuidadosas pueden ver que las empresas que no son de software no tienen diseños detallados. Explica por qué esto es simple. De hecho, el diseño detallado requiere mucho tiempo. Las empresas que no son de software no dedican este tiempo al diseño. Simplemente te dicen los requisitos directamente. Los codificadores sólo necesitan codificar directamente. Generalmente no hay requisitos sobre qué tecnología y marco utilizar.