Mostrando entradas con la etiqueta proyecto. Mostrar todas las entradas
Mostrando entradas con la etiqueta proyecto. Mostrar todas las entradas

viernes, 22 de diciembre de 2017

¿Por qué dicen que Java para nuevos proyectos en el futuro será obsoleto?

Dato Curioso:
¿Por qué dicen que Java para nuevos proyectos en el futuro será obsoleto?

En lo personal aborrezco Java: a mi juicio tomó las cosas malas de C++ (sobre todo la sintaxis) y tardó décadas en tomar las cosas buenas como las clases y funciones genéricas (y aún no toma cosas como la sobrecarga de operadores, espero que algún día lo haga).
Es un lenguaje, además, en el que hay que escribir demasiado hasta para las cosas más simples y que te obliga a usar el paradigma orientado a objetos aunque no sea el más apropiado para un problema de negocios dado - prefiero los lenguajes multi-paradigma como C++ o Perl que los creados por fanáticos religiosos de un paradigma - como Java o Haskell donde a fuerzas debes programar en el paradigma de objetos/funcional, respectivamente, aunque no sea lo más natural en ese problema de negocios.
Sin embargo, reconozco que Java tiene algo: una INMENSA cantidad de líneas de código ya escritas, una GIGANTESCA cantidad de clases y bibliotecas ya escritas que hacen casi todo lo imaginable, y una ENORME cantidad de programadores que lo conocen - así como libros para aprender/profundizar en él, cursos, foros en línea, consultores, programas de certificación, etc.
Java es, básicamente, el nuevo COBOL. Y este otro lenguaje horrible de la época de mi padre se niega a morir por exactamente las mismas razones que Java: hay una gigantesca cantidad de líneas de código en COBOL que requieren mantenimiento, de vez en cuando esas aplicaciones requieren que se les incorporen nuevas funcionalidades - normalmente es más práctico programarlas en COBOL mismo que hacerlas en otro lenguaje y complicarse la vida pasando información de un lado a otro.
En lo personal yo preferiría que todo nuevo desarrollo, si tiene a ser en un lenguaje orientado a objetos, fuera en uno agradable de usar como Ruby, Smalltalk o Kotlin. No me acaba de agradar C# pero tiene cosas hermosas como LINQ, destructores determinísticos (otra cosa que Java jamás quiso tomar de C++) y adoptó las cerraduras y las funciones anónimas muchos años antes que Java. Es más, a veces creo que hasta preferiría C++.
Pero en un plano más cercano a la tierra estoy consciente que Java no se va a ir a ningún lado, para bien o para mal. Y un administrador que está pensando en qué lenguaje pedir que se desarrolle el nuevo sistema para su empresa no sufrirá en lo absoluto para conseguir programadores si decide que sea en Java. Para bien o para mal, sigue y seguirá habiendo Java para rato.

¿Cuál es la mejor manera de planear y ejecutar un proyecto grande de software?

Que tal, el dia de hoy daremos respuesta a la pregunta:

¿Cuál es la mejor manera de planear y ejecutar un proyecto grande de software?

 imagen de : https://www.codejobs.biz

 

 

Yo consideraría los siguientes aspectos:
  • El ratio o tasa de fracaso de los proyectos crece exponencialmente con el tamaño de los mismos. Por poner un ejemplo, en empresas grandes solo el 9% de los proyectos son exitosos. No es únicamente por el tamaño del software sino por la cantidad de personas, criterios y decisiones que participan.
  • En el Chaos Report se establecen los factores de éxito de los proyectos obtenidos en la encuesta, mismos que te pueden servir de guía:
  1. Involucramiento del usuario
  2. Apoyo ejecutivo (sponsorship)
  3. Un claro enunciado de los requerimientos
  4. Planificación adecuada
  5. Expectativas realistas
  6. Hitos más pequeños
  7. Personal competente
  8. Apropiamento de la solución
  9. Una visión clara y objetivos
  • Adoptar prácticas formales de gestión de proyectos (como las del PMI) te pueden ayudar con la mayoría de los factores enunciados. Dale mucha importancia a la gestión de los riesgos, lo que te permitirá ser proactivo y no reactivo. También a la gestión de la calidad, porque hasta el 65% del costo del proyecto se puede ir en pruebas y corrección de defectos
  • Tendrás el problema de estimar el tiempo y el costo, lo cual no es posible si no se conoce el tamaño y para esto requieres conocer la totalidad de los requerimientos. En mi opinión conviene invertir al inicio del proyecto en el entendimiento de todos los requerimientos (aunque cambien más adelante) ya que esto nos permitirá hacer estimaciones (usando Puntos de Función), conocer más a fondo a los usuarios y sus expectativas, identificar riesgos y planificar mejor el proyecto. Estos requerimientos se pueden establecer como línea de partida (baseline) junto con un proceso de gestión de cambios que facilitará incorporar cambios de manera ordenada
  • En la parte técnica:
    • Una estrategia que te conviene definitivamente es desarrollar el proyecto de manera iterativa e incremental. De ninguna manera uses el ciclo de vida de cascada. Scrum puede servir para guiar el ciclo de vida pero es complicado adaptarlo para proyectos muy grandes (no imposible pero toma tiempo en la organización) . En todo caso, apóyate en un Scrum master
    • Te recomiendo usar el prototipado, en 3 vertientes:
      • Prototipos utilizados para reducir el riesgo técnico. Por ejemplo, si va a utilizar tecnología que no se ha probado antes en la organización puedes establecer actividades para hacer pruebas técnicas desde el principio del proyecto e ir reduciendo los riesgos (y establecer alternativas si no funciona)
      • Prototipos de interfaz para reducir el riesgo con el usuario. Existen muchas herramientas que te permiten hacer maquetas del sistema sin necesidad de programar y esto te permite reducir el riesgo de que el usuario vea algo que ya ha sido codificado y no le guste
      • Prototipos de interfaz con otros sistemas o librerías. Hacerlo al inicio te permite asegurar que la conexión con otros sistemas o librerías externas funciona adecuadamente
    • Definir la Arquitectura de alto nivel del software, esto es, los mecanismos y componentes del más alto nivel. Esto es mejor hacerlo al inicio
    • Busca a los mejores programadores que puedas pagar, procúrales lo que necesitan (silencio, no interrupciones, cubículos privados, computadoras/ordenadores potentes con pantallas grandes y doble monitor) y déjalos trabajar . Minimiza las reuniones y maximiza la comunicación asíncrona con ellos. El avance y los problemas que enfrentan se pueden informar vía correo o a través de un software. Las únicas reuniones presenciales (obligatorias) son para que entiendan los requerimientos
    • Procesos de soporte que requerirás:
      • Gestión de cambios
      • Gestión de configuración
      • Gestión de calidad

 
biz.