Madurez del desarrollo de software

El proceso de desarrollo de software involucra la realización de muchas tareas, las cuales son divididas en etapas o fases dependiendo el ciclo de desarrollo. La realización correcta de estas tareas en cada fase va a permitir tener un grado de certeza mayor al ir avanzado de fases, es decir, si desde el comienzo voy bien es más probable que termine bien.

Pienso que por esta razón el autor Graing Larman en su libro “UML y patrones” hace tanto énfasis en la etapa de  análisis, ya que propone herramientas con las cuales se asegure el entendimiento de las necesidades del cliente para posteriormente trasformar esas necesidades en una aplicación funcional.

Pero no solo el inicio garantiza la entrega de un buen producto de software, hay varios factores, tratare de mencionar los que considero más importantes:

Administración deficiente de los proyectos:

De la buena gestión de un líder de proyecto va a depender mucho el éxito del proyecto, algunas de las cosas que el líder puede hacer para una buena administración es realizar una calendarización para la entrega del producto, contemplando días laborales, jornada de trabajo, capital humano disponible, entregas o avances al cliente para obtener retroalimentación. De esta calendarización va a depender la estimación de los costos ya que se realiza en base al tiempo invertido.

Otras cuestiones en las que un líder falla es a la hora de manejar conflictos entre el equipo de trabajo, obviamente, en un ambiente laboral agradable la comunicación es mas efectiva y el trabajo es mas rápido. Además el líder debe cuidar el cierre de los proyectos ya que de ello va a depender futuras contrataciones, un buen cierre sería: brindar seguimiento al cliente (soporte técnico)  y entrega de manuales.

Falta de recursos

A veces para los proyectos no se tiene la tecnología adecuada para realizar o implementar las aplicaciones (hardware, software) o el personal (analistas, programadores, tester) no tiene las competencias para hacer frente al problema, por lo que será necesario capacitar el personal existente y/o contratar.

Mala definición de los requerimientos

Si un cliente esta familiarizado con la tecnología será mas fácil entender sus necesidades a diferencia de un cliente que no, en estos casos la etapa de análisis será mas complicada y se tendrá que invertir mas tiempo.

No se usan estándares de desarrollo

El hecho se usar estándares en etapas de análisis, diseño y  programación traerá beneficios para el proyecto como puede ser; usos de métodos probados, además, la integración mas fácil de personal, por que  bastara ver los documentos del proyecto para entender el problema y  las futuras actualizaciones al sistema se facilitaran por la misma razón.

Realización insuficiente o nula de pruebas en etapas iníciales

Como decía al comienzo de la lectura la etapa inicial es la más importante, entonces no hay que esperar a ver una aplicación funcional para encontrar defectos o ver si es lo que el cliente deseaba.

¿Entonces como esta la madurez de desarrollo de software?

Creo que el desarrollo de software no a alcanzado su madurez porque los desarrolladores no han echado mano de todas las herramientas, métodos y procedimientos que actualmente están a su alcance, sin embargo, si consideró que hay procesos de desarrollo maduros, es decir, que te guían en cada una de las fases de desarrollo y te dicen que hacer al momento de presentarse alguna situación.

Pienso que si los equipos de desarrollo mejoran en estos aspectos los sistemas serian más confiables, con menos defectos, entregados a tiempo, seria más fácil manejar la complejidad y los cambios, lo que nos llevara a la satisfacción del cliente.

Diego Torres Medina

Introducción:


El siguiente tema a tratar es sobre la madurez del desarrollo de software, el cómo se ha ido manejando y los problemas que ha venido acarreando esta situación.

Desarrollo:
Por principio al hablar de que ha habido una madurez en el desarrollo de software ha sido en buena parte porque este se ha tenido que ir dando. Uno de los puntos más importantes en cuanto por que ha habido crisis en el desarrollo de software es el hecho de que a lo largo del construcción del software hay muchos cambios que en buena medida se tienen que hacer por petición de los clientes y esto a su vez acarrea varios problemas; Sin embargo en dos puntos no estoy muy de acuerdo sobre causas de la crisis, la primera seria sobre la complejidad que supone la tarea de programar, puesto que creo que si en buena parte el programar no es una tarea sencilla, tampoco es la tarea mas difícil que pueda haber y sobre todo porque en estos tiempos hay muchas herramientas, manuales y soporte que nos brindan la oportunidad de programar de manera mas rápida y no tan imposible.


Y el otro punto que mi opinión varia es la de que todavía no hay herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa; cuando al contrario ay herramientas tecnológicas que ayudan a llevar esa parte si bien en mi opinión muchas de las personas que llevan este tipo de proyectos más bien no saben que existen dichas herramientas o a su vez no saben utilizarlas debidamente para realmente sacarle provecho a estas.


Algo extra después del funcionamiento del software se nos señalaba es la calidad de este aunque digo que si bien el software muchas veces no tiene calidad no creo que sea porque esté en crisis sino mas bien depende mucho de la empresa o el lugar donde este se fabrique y claro depende mucho el país no es lo mismo: México, Usa, Alemania, Japón, Perú, mucho depende de los procesos y las normas que sigan y todo esto beneficiara en buena parte a la calidad final que tendrá el software.


Un punto en el que si estoy de acuerdo es el hecho de que si bien cada vez es más recurrente que los sistemas tengan muchos defectos, fallen o estos a su vez no se usen, bien podría ser porque a la hora de su elaboración no se llevan a cabo las pruebas necesarias para poder encontrar los errores desde entonces y poder corregirlos de inmediato y no cuando ya el producto este en uso.


Ahora bien cuando se nos señalaba también sobre lo de los mitos que hay a la hora de desarrollar software varios pueden ser reales como el hecho de que en varias empresas dedicadas al desarrollo tienen libros de estándares y procedimientos pero si muchas veces los empleados los omiten o ni siquiera saben que existen estas guías, otro punto es el hecho de que se tienen las mejores computadoras pero no solo eso es necesario para poder elaborar software funcional y de buena calidad se necesita más que eso, también no por el hecho de que a un proyecto que ya está en proceso le metamos más gente quiere decir que por eso se van a cortar los tiempos o se recompensara el tiempo perdido, al contrario tal vez se atrase mas el desarrollo del software.


Por último se deben de dar cuenta los programadores que si bien su trabajo es ese la tarea ahí no termina pues hay mucho más que hacer después de esa tarea que es sólo una parte de los elementos del software, además de que estoy seguro que la documentación proporciona el fundamento para un buen desarrollo.


Conclusión:

Para mi si se desea que el desarrollar software realmente tenga una madurez relevante se le tiene que dar gran importancia a lo que son las pruebas, dentro de todo el desarrollo de este puesto que nos ahorraran mucho tiempo después y sobre todo tener una clara y excelente comunicación con el cliente. Y pues para terminar creo que seguirán pasando los años y el desarrollo de software seguirá siendo una tarea algo compleja por todo lo que a esta la rodea errores humanos, fallos mecánicos y defectos en general, sin embargo si se hacen las planeaciones debidas, se tiene buena comunicación con o los clientes y sobre todo se hacen pertinentes verificaciones y validaciones del software. Esta tarea de desarrollar software se irá haciendo una tarea más placentera y tranquila para todos los que nos involucramos en este trabajo.


Ensayo: criticas a la madurez del desarrollo del software

Materia: Tecnologías Emergentes 3

Lic. Informática 9to. Semestre

Docente: I.S.C Fernando Osiel Peñaloza Avila

Alumno: Manuel Alejandro Magaña Álvarez.

Fecha: 16 de Agosto del 2010

Ensayo sobre la madurez del software

El desarrollo de sw hablando en términos mundiales se ha visto opacado por las deficiencias en las que se ha visto envuelto, ya que existe un porcentaje muy elevado de proyectos que fracasan por diferente razones entre las que destacan las siguientes:

· Mala planeación en cuanto costos y tiempos de entrega

· Se construyen sistemas que no satisfacen las necesidades de los clientes, por lo que nadie los utiliza

· Los sistemas son muy limitados por lo que al querer agregarle módulos no se puede y se vuelven obsoletos.

Por esto y muchas razones mas los gastos para desarrollar sw se vuelven exorbitantes y los resultados positivos de este son muy pocos.

Por si fuera poco actualmente el software elevó su demanda, los sistemas que los clientes piden son cada vez mas complejos y exigen la mayor calidad posible, por lo tanto, las empresas desarrolladoras que luchan por mantenerse en el mercado, intentan disminuir sus deficiencias mejorando sus procesos haciendo uso de metodologías como CMMI, apoyándose de herramientas y modelos con la finalidad de tener una empresa competitiva.

Por lo que si bien falta mejorar en mucho, desde mi punto de vista esta es la causa por lo que muchos proyectos fracasan, hoy en día la mentalidad de los equipos de trabajo es muy pobre, la mayor parte de las empresas de nuestro país piensan que el entretenerse en documentar sus proyectos, probarlos y capacitarse constantemente es perdida de tiempo, sin embargo se ha comprobado que es necesario no solo contar con la mejor tecnología sino tener una buena planeación, comunicación, mucho trabajo en equipo así como seguir metodología y modelos que si bien no dejarán nuestros proyectos con 0% errores los disminuirán enormemente y de esta forma podremos brindar un mejor servicio con la mas alta calidad posible a nuestros clientes.

Con esto quiero enfatizar que la preparación y superación constante de todo el equipo debe ser algo que debemos practicar diariamente, basta de ser personas mediocres y cómodos que nos conformamos con un “haber que sale”, o un “a mi no me toca” necesitamos ser personas comprometidas primeramente con nosotros mismos, con nuestro trabajo y sobre todo con el desarrollo de México y el mundo.

Elaborado por Alejandra López Bedolla

PONGAN SU CORREO AQUI!!

Dejenme aqui sus correos de gmail para poder mandarles la invitacion y asi puedan publicar entradas como colaboradores!! dejenlo como comentario

Críticas a la madurez del desarrollo de Software.

Según estadísticas publicadas en los últimos años arrojan en general que cerca del 70% de los proyectos de software fracasan ya sea por el abandono del proyecto o porque el software terminado jamás se usa o no cumplieron con los requisitos del cliente.

De acuerdo con la información recopilada a través de internet e identificado a mi punto de vista 5 principales causas que potencializan el fracaso de los proyectos de software.

1. Requerimientos incompletos o mal especificados. Esta causa para mi es la más importante, porque las necesidades que dan lugar a que el cliente opte por el desarrollo de un software deben ser cubiertas con dicho producto de software, de lo contrario el software que se haya desarrollado no cumplirá con estos requerimientos y el software nunca cumplirá la función para la que fue desarrollado.

2. Cambios constantes en los requerimientos. Generalmente cuando el analista de software hace la recolección de requerimientos, casi siempre quedan pequeños detalles que modificar, pero a veces estas modificaciones no se documentan y esto involucra que las revisiones técnicas o los casos de prueba se diseñen de manera errónea y estas pruebas ya no sean aplicables o terminen estando mal diseñados.

3. Mal diseño del cronograma de actividades. Esto pasa frecuentemente en equipos de desarrollo de software que tienen poca experiencia y por lo mismo tienden a asignar el tiempo incorrecto a las diversas actividades por ejemplo, existen actividades que necesitan mucho tiempo, por ejemplo en el análisis de requerimientos pero no se le destinan los días u horas suficientes, esto puede causar dos errores, el primero es que los requerimientos queden documentados de forma muy simple y no lo suficientemente definidos y detallados ó el segundo, que se detallen de forma correcta los requerimientos, pero esto retrasa al equipo de trabajo con demasiado tiempo que el tiempo de realización del proyecto se sobre calendariza y se incumple en el tiempo de entrega del proyecto con el cliente.

4. Definición irreal del alcance del proyecto. Como en el punto anterior, la falta de inexperiencia de los equipos de desarrollo, les es muy complicado determinar los módulos funcionales y requerimientos que solicita el cliente que si está a su alcance cubrir con el sistema que se vaya desarrollar, por ejemplo, existen ocasiones que el cliente tiene la idea que cualquier cosa que soliciten en su sistema, es posible desarrollarse. Pero esto no es verdad, existen requerimientos que ya sea por falta de conocimientos del equipo de desarrollo o la falta del acceso a nueva tecnología, esto entre otras cosas similares causan que no se cumplan las expectativas del cliente, que le proyecto fracase y se pierda credibilidad ante nuestros clientes.

5. El mal uso de metodologías. Muchas veces en los equipos de desarrollo no se toma en cuenta el uso de metodologías y ciclos de vida para el desarrollo de software, esto principalmente es por la falta de conocimiento de dichas técnicas o simplemente la forma de pensar de los desarrolladores, muchos piensan que el hecho de hacer tanta documentación es una pérdida de tiempo que se podría utilizar en la programación del software. Debemos de tomar en cuenta que como en todo proceso, todas las actividades se deben de documentar con el fin de que si se requiere hacer un cambio, o se detecta algún error, sea más fácil la identificación de la etapa del ciclo de vida y la actividad en que se inyecto dicho error.

De todo esto mi conclusión es, que los equipos de desarrollo de software deben aplicar la metodología más adecuada al tipo de software que vayan a desarrollar ya que esto nos reduce de forma muy significativa el tener errores en nuestro proyecto y si los llegara a haber, tendríamos una forma eficaz y eficiente de poderlos encontrar y efectuar un plan de acción para la corrección y prevención de estos, es importante señalar que, a mi punto de vista no es recomendable seguir una metodología al pie de la letra, sino que debemos adecuar esta metodología a nuestro proyecto y no nuestro proyecto a la metodología, ya que ningún proyecto de software es igual a otro pero siempre llevando esta metodología como una guía efectiva para el desarrollo de nuestros proyectos y productos de software.

Elaborado por: Erik Alberto Custodio García.

Las pruebas de software son:

* Una investigación llevada a cabo para proporcionar información sobre la calidad del producto
* Proporciona una visión objetiva, independiente del software para permitir a la empresa conocer y comprender los riesgos a la aplicación del el software.
* Proceso de validación y verificación de un programa de software.

Testing: proceso de evaluación de un producto desde un punto de vista crítico, donde la persona que realiza las pruebas somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción. Una práctica común es que el proceso de pruebas de un programa sea realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes de sacarlo al mercado.

Apha es versión anterior en el proceso de desarrollo, en la que el programa, aunque incompleto, dispone de funcionalidad básica y puede ser testeado.

Release To Market: Dónde se comprueba cada funcionalidad del programa completo en entornos de producción.

Es importante tener en cuenta que:
* Las pruebas nunca podrá identificar todos los defectos en el software solo puede proporciona una crítica o una comparación del estado y el comportamiento del producto frente a las espectativas iniciales.
* Un estudio realizado por el NIST en 2002 los informes de que los errores de software cuestan a la economía EE.UU. 59,5 mil millones dólares anualmente. Más de un tercio de este coste podría evitarse si las mejores pruebas de software se realizó.

Un poco de historia:
La separación de la depuración de las pruebas fue presentado por Glenford J. Myers en 1979.
"una prueba exitosa es aquella que encuentra un error" quien clasificados en 1988 las fases y objetivos en las pruebas de software en las etapas siguientes:

• Hasta 1956 - Depuración-orientada
• 1957-1978 - Demostración orientada
• 1979-1982 - destrucción orientado
• 1983-1987 - Evaluación orientada
• 1988-2000 - Prevención orientadas








http://en.wikipedia.org/wiki/Software_testing

Datos de la comunidad

Página principal: http://groups.google.com.mx/group/temergentes3
Registense para tener acceso y tambien en este blog!