La comprensión vulgar de la ingeniería de software es utilizar principios de ingeniería para completar la construcción de sistemas de software, con el propósito de que sean "rápidos, buenos, estables y económicos" (rápido: velocidad de desarrollo rápida, ejecución rápida velocidad...; Bueno: buen código, buena calidad, fácil de usar...; estable: estable durante mucho tiempo, estable bajo especificaciones extremas...; Por supuesto, esta es mi interpretación vulgar personal. Para definiciones profesionales, puede consultar Baidu, Google o IEEE.
Mirando hacia atrás en la ingeniería de software, la ingeniería de software es el propósito y la ingeniería es el proceso y los medios. Si hay una mejor manera de lograr el objetivo, ¿por qué tiene que ser la "ingeniería"? ¿Puede ser de otra manera o método? La respuesta es sí. Así que no sigas ciegamente, asegúrate de elegir métodos basados en tu situación real. Nos centramos en objetivos, no en procesos y medios sofisticados. "Para un equipo de desarrollo de software, este puede ser un enfoque 'sistemático, estandarizado y cuantificable', pero para otro equipo, puede ser una carga. Por lo tanto, debemos estandarizar y también adaptarnos ”
La ingeniería de software es una tecnología jerárquica que incluye cuestiones, procesos, métodos y herramientas de calidad. Cualquier método de ingeniería debe basarse en un compromiso con la calidad; el proceso ("gran panorama") define un marco para completar la gestión y control del proyecto de software; el método ("concreto") define una serie de soluciones técnicas; Las herramientas se utilizan para proporcionar procesos y métodos que brindan soporte automatizado o semiautomático. El punto que más fácilmente se pasa por alto es el primero: "problemas de calidad". Es fácil para nosotros entender unilateralmente la ingeniería de software como una serie de procesos y métodos para desarrollar software, e incluso en el proceso de implementación, se convierte en documentos, fórmulas y plantillas que resultan repugnantes para muchos desarrolladores. De hecho, el "enfoque en la calidad" es la base de la ingeniería de software y la fuerza impulsora para la mejora continua de los procesos de software. Sólo aclarando las "preocupaciones de calidad" y los sistemas de evaluación relacionados podremos seleccionar o diseñar procesos, métodos y herramientas apropiados, en lugar de poner el carro delante del caballo. También enfatiza una vez más el punto de vista del párrafo anterior de que "el que se adapta a su propósito es el mejor". Esta también puede ser la diferencia entre expertos y novatos. Los maestros se preocupan más por la "verdad" y "es un buen gato si caza ratones"; los novatos se preocupan mucho por la "forma" y tienden a ignorar la "realidad". Por supuesto, también es posible que los principiantes simplemente no comprendan o no entiendan lo que necesitan lograr.
A continuación, aprendamos algo de la esencia de la práctica del software. Aunque los conocimos hace muchos años, mirando hacia atrás, a medida que nuestra experiencia y nuestra experiencia se vuelven cada vez más abundantes, admiramos a estas personas mayores extranjeras desde el fondo de nuestro corazón. "Cómo solucionarlo" fue escrito en 1945. En este artículo, George Polya enumera la esencia de la resolución de problemas, que corresponde a () la idea del desarrollo de productos de software:
1) comprender el problema (comunicación y análisis
<); p>2) Desarrollar soluciones y programas (modelado y diseño de software);3) Plan de implementación (generación de código);
4) Verificar la exactitud de los resultados (pruebas y Calidad); Aseguramiento);
Los cuatro pasos anteriores son en realidad las ideas y procesos para abordar todos los problemas generales. No importa cuál sea el escenario, el requisito previo para cualquier plan y plan debe ser comprender el problema. Esto aparentemente obvio no es necesariamente "obvio" en el desarrollo de productos de software. Especialmente aquellas necesidades del cliente que implican múltiples niveles de entrega pueden desviarse fácilmente del problema original. Para dar un ejemplo muy común, en el campo del software, algunas empresas involucran muchas cosas profesionales y todos los clientes con los que tratan no son profesionales.
A veces traen los requisitos al departamento de RD, y el departamento de RD puede diseñar los requisitos basándose completamente en la información aportada por estas personas, y estos requisitos diseñados pueden no ser lo que los clientes quieren, o al menos tener mucho que ver con los productos que quieren. Gran brecha. Si se tienen en cuenta los malentendidos u omisiones causados por el diseño de requisitos del personal de RD durante el proceso de desarrollo del producto de software, problemas similares se volverán más comunes y graves. Por lo tanto, desde el personal de primera línea más cercano a los clientes hasta el personal de RD que completa la construcción de productos de software, se necesita un mecanismo para completar la transmisión de problemas. Cuanta menos información se pierda durante el proceso de transmisión, especialmente la información clave, la. mejor será la comprensión del problema. En el proceso de transferencia de la demanda del producto, la comunicación y la retroalimentación del proponente de la demanda original son esenciales.
Finalmente, eche un vistazo a los siete principios resumidos por David Hook en "Siete principios del desarrollo de software" para centrarse en la práctica de la ingeniería de software:
1) Valor existencial: principios básicos, ¿Por qué hacemos esto? ¿Cuál es el valor? ¿Es el valor realmente valioso?
2) Mantenlo simple: simple pero no simplificado. Las iteraciones repetidas, las modificaciones constantes, el mantenimiento y las actualizaciones, la simplicidad pueden eliminar las pesadillas;
3) Mantener la visión: Mantener una visión arquitectónica consistente es la base del éxito del software. De lo contrario, el código se dañará rápidamente;
4) Preste atención a los usuarios: los clientes, el personal de operación y mantenimiento y las personas que se hacen cargo del código son todos usuarios
5) Orientado al futuro: probar la arquitectura del software, responder continuamente al cambio. Nuevos escenarios, nuevos entornos operativos, nuevas necesidades, etc.
6) Planificar la reutilización: Los principios esenciales del desarrollo de software son “abstracción, encapsulación y reutilización”.
7) Piensa detenidamente: posicionamiento claro y pensamiento completo generalmente produce mejores resultados, que es el principio que más fácilmente se pasa por alto;