Cómo construir un gran software

Cómo construir un gran software

Word Count:
723

Resumen:
En este artículo voy a explicar las 10 falacias de desarrollo de software de mi empresa evita. Al evitar estos mitos y concentrarse en la excelencia, podemos hacer que el software de gran calidad.


Palabras clave:
software, los mitos, las grandes, las falacias, el desarrollo


Cuerpo del artículo:
En este artículo voy a explicar las 10 falacias de desarrollo de software de mi empresa evita. Al evitar estos mitos y concentrarse en la excelencia, podemos hacer que el software de gran calidad.

Mito 1) El software debe ser diseñado en detalle antes de que comience el desarrollo, de manera que un plan claro puede ser fuera de layed.

La verdad) El más complejo es un diseño, más como el software de diseño en sí es. Mediante el perfeccionamiento de un diseño, a continuación, escribiendo el software para que el diseño, está escrito de manera eficaz el trabajo dos veces. En cambio, al hacer solamente algunos bocetos de diseño simple y modelado de datos en lugar de un libro-como el diseño, un equipo de desarrollo bien puede crear un shell para el software y perfeccionar de manera eficiente hacia el producto terminado. Este proceso de refinamiento crea prototipos naturales, permite una fácil adaptación cuando los problemas imprevistos que se plantean por un diseño (o criado como nuevas preocupaciones por un cliente), y el proceso total toma mucho menos tiempo. Para conseguir esto requiere de un equipo unido, la habilidad y experiencia, pero no es la mejor opción para la mayoría de las situaciones.

Mito 2) Hay muchos programadores, diseñadores, analistas y usuarios.

La verdad) Al estructurar el desarrollo para que todos los desarrolladores a conseguir algo de exposición a cada parte del proceso de desarrollo, las competencias pueden ser compartidas y un mayor conocimiento puede ser adquirida. Si los desarrolladores se les anima a utilizar el software en realidad luego se puede utilizar esa experiencia para pensar en las mejoras que de otro modo no habría salido a la luz.

Mito 3) Un equipo feliz es un equipo productivo.

La verdad) Un equipo de personas con una amplia variedad de habilidades naturales, la experiencia y la preocupación, que critica entre sí y afirma con vehemencia en los detalles más pequeños, se abrirá y se resuelven cuestiones que de otro modo nunca se iban a abordar. Un horno de la argumentación implacable es la mejor manera de forjar el entendimiento y alcanzar la perfección.

Mito 4) Es importante, entendemos que nuestra dirección y que no comprometan con ella.

La verdad) La vida es compromiso, y el compromiso no es una debilidad. Siempre habrá problemas (como la eficiencia, el presupuesto, la facilidad de uso, potencia, alcance, y la necesidad de internacionalización de fácil) que no puede ser alcanzado de forma simultánea, sin tal compromiso.

Mito 5) Sabemos lo que quiere el cliente, sabemos cuáles son los problemas.

La verdad) Sin constante re-evaluación, es fácil perder de vista el objetivo. Los desarrolladores a menudo se enfrentan con problemas a resolver que consideran que los problemas, cuando estos se encuentran separados de hecho de los objetivos reales del mercado y puede llegar a ser totalmente irrelevante. Los desarrolladores siempre debe comprender los objetivos de mercado y ser capaces de adaptarse al otro las cosas cambian, o incluso los propios objetivos de cambio.

Mito 6 más grande) es mejor. Las características son cool.

La verdad) Características fácilmente puede confundir a los usuarios, y su valor real siempre debe considerarse en el costo de la confusión. En algunos casos, es razonable que en realidad eliminar características de trabajo debido a esas preocupaciones.

Mito 7 bis) El cliente siempre tiene la razón.

La verdad) La mayoría de los clientes tratar de no parecer ignorantes frente a los desarrolladores de software, y por lo tanto, la frase sus propuestas de manera técnica. El efecto es que a menudo las sugerencias no son realmente apropiadas, porque no está fundada en una sólida comprensión de las cuestiones técnicas.

Mito 7 ter) El cliente es a menudo mal.

La verdad) Aunque las necesidades de los clientes a menudo no son mejor atendidas por hacer literalmente lo que dicen, ellos siempre saben lo que quieren y por qué lo quiere - y por lo general de muy buena razón. Entender y adaptarse a lo que dicen, discutir con ellos, pero nunca ignorar.

Mito 8) Comentario su código mucho.

La verdad) Código de Buen necesita apenas comentarios, gracias a las alternativas de uso sensato de nombres y espacios en blanco son mejores. Los comentarios deben sólo ha explicar la no evidente, o proporcionar la documentación de la API estándar.

Mito 9) Tal y como se necesita, tal y como es grande.

La verdad) Un mal trabajador culpa a sus herramientas. Si bien algunas herramientas de desarrollo sustancialmente la ayuda al desarrollo, un buen desarrollador puede hacer grandes resultados en la mayoría de las cosas que se les sirve. Hay algunas excepciones, como Microsoft Access, o en lenguaje ensamblador, pero en general la diferencia en los resultados de calidad es mucho mayor debido a las habilidades de los desarrolladores de la calidad de sus herramientas.

Mito 10) El cliente deberá entender si hay un sistema eficiente y fácil de usar interfaz.

La verdad) La interfaz no sólo tiene que ser fácil de usar, tiene que ser navigatable sin una comprensión global de los sistemas. Pantallas deben ser auto-descriptivo.