Entorno de desarrollo interno versus desarrollo de software [cerrado]


13

En la industria, se hace una distinción entre un entorno de 'desarrollo interno' donde los desarrolladores de software escriben código que será utilizado por la propia empresa y un entorno adecuado de 'desarrollo de software' donde el software se construye para ser vendido / distribuido para el publico.

Entre otros, una diferencia obvia entre los dos es que una empresa orientada al desarrollo de software generalmente se adherirá a algún tipo de ciclo de vida de desarrollo de software, como redacción de especificaciones, pruebas, construcción, etc., mientras que la tienda orientada a la empresa generalmente hacer las cosas de una manera más informal, ya que ellos mismos son los usuarios finales y siempre pueden arreglar algo que no se hizo bien.

Como estudiante (como la mayoría de los otros estudiantes), esperaba terminar trabajando en un entorno de desarrollo de software, pero terminé obteniendo mi primer puesto en una empresa que opera de manera más interna.

A veces, me pregunto si me estoy perdiendo la experiencia completa de desarrollo de software. ¿Hay una base para este sentimiento? ¿Debo buscar unirme a un entorno de desarrollo de software adecuado?


99
Creo que estás sobre generalizando. Las metodologías utilizadas no tienen nada que ver con los productos internos versus los proyectos vendidos comercialmente. He trabajado en un producto enviado que fue desarrollado muy ad-hoc, ignorando muchas de las que se considerarían mejores prácticas. También he trabajado en proyectos internos que tenían especificaciones detalladas, conjuntos de pruebas y una gran cantidad de prácticas de control de calidad.
Thomas Owens

Ambas preguntas que ha planteado solo pueden ser respondidas por usted mismo.
leo

66
En mi humilde opinión, su problema no tiene nada que ver con perderse en la empresa interna frente a la compañía de software. Parece que está sufriendo de estar en un entorno de desarrollo no estructurado y no tener un mentor fuerte que lo ayude a seguir las mejores prácticas.
maple_shaft

1
Ya sea que el software se desarrolle para la venta o para uso interno, todo se llama "desarrollo de software". Comercial podría ser un término mejor que lo que usted llama "desarrollo de software".
Caleb

1
Está combinando dos dimensiones del desarrollo de software: proceso de desarrollo ad-hoc vs estructurado, y desarrollo interno vs desarrollo de producto. El grado de cada uno puede variar de forma independiente.
Sean McMillan

Respuestas:


13

En mi experiencia, la distinción que hace entre "en casa" y "producto distribuible" es falsa.

Hay empresas que toman en serio su proceso de desarrollo de software y otras que no. Si están "en casa" o "a medida" o "envoltura retráctil" tiende a no entrar tanto (aunque si son proveedores de "envoltura retráctil", si no tienen un proceso, probablemente no estarán en el negocio por largo).

Debe buscar un lugar que tenga los estándares de desarrollo que está buscando; al entrevistar, debe hacer estas preguntas para asegurarse de que el lugar sea de su agrado a este respecto (así como en otros).


Estaba escribiendo algo similar a esto cuando publicaste. +1 solo para la última oración, aunque todos son puntos válidos.
Thomas Owens

@ThomasOwens - Sí, vi tu comentario a la pregunta después de publicar mi respuesta y esperaba una respuesta tuya también;)
Finalizado el

10

Puedes leer este articulo

http://www.joelonsoftware.com/items/2007/12/04.html

de Joel Spolsky, que se ocupa exactamente de su pregunta.

Estoy en una posición en la que tuve que trabajar tanto en los últimos años: un producto de software de tamaño medio que se vendió y algunos programas internos. Según esa experiencia, puedo decirle que hay diferencias entre esas dos plataformas, pero la situación no es tan mala como la describió Joel.

Por ejemplo, la mayor parte de nuestro software interno solo debe ejecutarse en un entorno muy restringido. Muchas herramientas solo funcionan con una determinada hoja de cálculo o versión de base de datos, con un entorno de red específico, con un número restringido de usuarios, no se necesita una rutina de instalación, etc. Eso hace que muchas cosas sean más fáciles y rápidas de desarrollar en comparación con las nuevas características introducidas en Nuestro producto de envío. Por otro lado, eso no significa que mi código para los programas "internos" tenga una calidad inferior o esté escrito de una manera más "informal".


6

Hace mucho tiempo, leí un libro sobre Agile Project Management (ojalá pudiera recordar el título), donde el autor distinguió los sistemas en función de sus niveles de tolerancia a los defectos del sistema. La tolerancia a los defectos puede variar desde muy alta, por ejemplo, una utilidad utilizada por otros desarrolladores (donde los errores son simplemente un inconveniente), hasta muy baja, por ejemplo, un sistema que ejecuta soporte vital para astronautas (donde un error podría ser potencialmente mortal).

El punto del autor fue que la metodología de desarrollo (y la formalidad) debían ser alcanzados a la tolerancia a fallas (o criticidad) del sistema. Creo que esta distinción es la más importante, en lugar de distinguir entre desarrollo interno versus software para distribución general.

Imagine un hospital que tiene desarrolladores internos que crean sistemas de registros médicos que podrían afectar la calidad de la atención médica. En este caso, la tienda interna probablemente sería más rigurosa que una consultoría de sitios web, que está creando productos web para ser utilizados por el público en general.


3

He trabajado para empresas de software, agencias de marketing, empresas de telecomunicaciones y bancos, una cosa que diré es que la cultura y la industria de la empresa determinan el nivel de procesos aplicados. El entorno más riguroso, lento, restrictivo y probado que jamás haya experimentado fue el desarrollo interno de un banco. La más informal fue una agencia de marketing.

Recomiendo aprender de esta experiencia y usarla para decidir su dirección futura para su próximo trabajo. La industria del desarrollo de software no es una ciencia, es arte / ciencia, de ahí la variación y las diferencias de una compañía a otra. Es más importante que aprenda a hacer las cosas bien con respecto a su código. Si bien es útil tomar nota mental de las fallas o la falta de procesos, cuando su gerente puede implementar mejores procesos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.