Está en la página 1de 9

Facultad de Informática y Ciencias

Aplicadas

Catedrático:
Ing. Marlon Giovanni Martínez Pérez
Asignatura:
ESTANDARES DE PROGRAMACIÓN
Tarea:
¿Que mata los equipos de desarrollo de
Software?
Sección:
02
Estudiante
Núñez Iglesias, José Moisés
Carné
25-3542-2018

San salvador, 4 de junio del 2022


Contenido

Introducción ....................................................................................1
Objetivo general ............................................................................2
Objetivos específicos .....................................................................2
Que mata los equipos de desarrollo de software .........................3
Mala estimación de tiempos .........................................................4
Desconocimiento de la tecnología ................................................5
Insuficiente administración de los riesgos ....................................5
Escatimar en el control de calidad .................................................6
Diseño inadecuado .........................................................................7
Motivación débil ............................................................................8
Conclusión .......................................................................................8
Introducción
El software representa una pieza importante para dar soporte a
muchas de las necesidades encontradas en diversos dominios
industriales y se ha convertido en una actividad centrada en los
humanos, razón por la cual su éxito o fracaso depende del trabajo
en equipo
Al momento de definir software podríamos verlo como una
herramienta que nos sirve para agilizar nuestro trabajo, en los
juegos que usamos en Facebook, las aplicaciones de nuestro
smartphone, todo lo que usamos en la computadora fue creado por
un equipo de desarrollo, pequeño, grande, distribuido o local,
Como todo proyecto el software tiene un ciclo para desarrollarse y
consta de una serie de pasos que se van completando en diferentes
tiempo; este ciclo de desarrollo de software depende directamente
de la metodología que utilizamos para este desarrollo, y no es más
que una serie de pasos/tareas que tenemos que seguir como en
cualquier otro proyecto, no hay nada escondido, nada mágico
excepto la gran mente del equipo de desarrollo y las creaciones
para tener una experiencia única al utilizar la aplicación o el
paquete de software.
Objetivos

Objetivo General:
Desarrollar un análisis sobre que mata los equipos de desarrollo de
Software.

Objetivos Específicos:
1. Dar algunos consejos para evitar que un proyecto de software
fracase.

2. Hablar sobre los errores comunes en el desarrollo de software

3. Hacer observaciones sobre errores de desarrollo de software.

4. Observar cómo fracasa un proyecto de software al no estar


preparados para su desarrollo
¿Que mata los equipos de desarrollo de Software?
Es innegable la importancia que los sistemas de información
juegan en la actualidad. La diversidad de aplicaciones es tan amplia
que resulta poco probable encontrar áreas del quehacer humano
donde no haya intervenido una computadora y, por lo tanto, el
software. Aunque tenemos la idea generalizada que el software es
infalible, lo cierto es que los errores y fallas son mucho más
frecuentes de lo que pensamos. En este sentido, el mal diseño de un
sistema, la falta de estándares adecuados en el desarrollo de
programas o las malas prácticas de programación, conllevan no
solo fallas en los resultados de uno o más procesos sino millonarias
pérdidas económicas, tecnológicas y hasta humanas.
Aquí listo algunos errores en el desarrollo de software que podrían
llevar al fracaso de este.

1. Mala estimación de tiempos


¡Vaya!, Me dijiste que me costaría 5 y se tardaría 12… ¿Qué salió
mal? Si bien la estimación de tiempos y costo es un arte, también
es un proceso que tiene técnicas para estimar y acercarse bastante a
una buena cotización. Tener una mala estimación de tiempos y
costo afecta a ambas partes, a ti como cliente y al proveedor. Lo
que puedes revisar antes de aceptar una cotización que hace sentido
a tu presupuesto, es verificar o indagar lo siguiente:

• ¿El proveedor tuvo reuniones conmigo para realizar un


preanálisis?
• ¿Me pidió acercarse conmigo para resolver alguna duda?
• ¿Me pidió documentación que le ayude a estimar?
• ¿Vino y me hizo una presentación de la cotización y del
entendimiento de mis requerimientos?
• ¿Entendió y expresó lo que necesito?
Si al preguntar lo anterior, alguno de estos puntos no estuvo
presente durante el proceso, puede ser un indicio de que tu
proyecto tiene un alto riesgo de sufrir cambios durante su
ejecución, estos cambios van relacionados directamente a tiempo y
costo.

2. Desconocimiento de la tecnología
La mayoría de los desarrolladores son conocedores de varios
lenguajes y tecnologías informáticas.
Sin embargo, las aplicaciones empresariales actuales de múltiples
capas son un enredo complejo de muchos lenguajes y plataformas
de software.
Estos niveles incluyen la interfaz de usuario, la lógica empresarial
y la gestión de datos, y pueden interactuar a través de middleware
con sistemas de recursos empresariales y aplicaciones heredadas
escritas en lenguajes arcaicos.
Pocos desarrolladores conocen todos estos lenguajes y tecnologías,
y tienen suposiciones incorrectas sobre cómo funcionan otras
tecnologías.
Esto llega a ser la fuente principal de los defectos no funcionales
que causan interrupciones dañinas, corrupción de datos y fallas de
seguridad durante la operación.
La mejor manera de mitigar esta causa es entrenar a los
desarrolladores en diferentes tecnologías, realizando revisiones
entre pares con otros desarrolladores que trabajen en diferentes
aspectos de la aplicación.

3. Insuficiente administración de los riesgos


¿Qué es un riesgo en el desarrollo de proyectos de software? Un
riesgo es un evento o condición incierta que, si sucede, tiene un
efecto en por lo menos uno de los objetivos del proyecto. Hay
distintos tipos de riesgos.
1. Riesgos asociados con los usuarios. Incluyen la falta de
compromiso de la alta gerencia de la organización y la
insuficiente participación de los usuarios. Estos factores no
siempre están al alcance del líder del proyecto.
2. Factores de riesgo asociados al líder del proyecto. La
incapacidad para juzgar el alcance del sistema y con la pobre
identificación de la funcionalidad requerida. Estos factores si
deben ser controlados por el líder del proyecto.
3. Factores asociados a la ejecución del proyecto, tales como
personal inadecuado, metodología de desarrollo inapropiada,
fallas en la definición de roles y responsabilidades, pobre
planeación y control del proyecto. Estos factores
generalmente si son considerados y controlados por el líder
del proyecto.
4. Factores de riesgo asociados al entorno, que se enfoca
principalmente en los cambios en la gerencia organizacional
y que podrían afectar al proyecto.
Los factores de las categorías 2 y 3 son los que afectan
directamente a que los proyectos sean culminados en el tiempo y
con el presupuesto previsto. De esta forma, los proyectos
pobremente ejecutados o con un alcance inestable y requerimientos
vagos, normalmente, no son culminados exitosamente. Los factores
de las dos categorías restantes no siempre afectan el éxito en los
procesos de un proyecto.

4. Escatimar en el control de calidad


El aseguramiento de la calidad es una etapa primordial en tu
proyecto de software, pues en esta etapa se permite validar todos
los puntos de quiebre y cruciales en la operación de un negocio
dado y hacia el cual está encaminado el software.
Es muy importante que se destine al menos un 30% del tiempo del
desarrollo de tu proyecto para las pruebas que el departamento de
calidad ejecuta, estimar un tiempo menor no es recomendable, pues
según los expertos no se puede realmente garantizar que el
software pueda realizar todo lo esperado de la manera correcta, aun
siendo cuando la funcionalidad a validar ya sea por más conocida,
pues cada proyecto tiene variables que los hace diferentes; se vale
totalmente preguntarle a tu proveedor qué porcentaje está
destinando al aseguramiento de la calidad y en qué momentos lo
ejecutará.

5. Diseño inadecuado
Si bien es realmente cierto que sin un buen análisis no se puede
tener un buen diseño, por ser actividades que por lo regular van de
la mano no todo es totalmente dependiente del análisis, pues se
puede tener el mejor de los análisis, pero un diseño deficiente.
Siempre es recomendable estar pendiente de los entregables de esta
fase, que por lo regular los más comunes son un prototipo o
wireframes de lo que será la interfaz de usuario, sin embargo, a tu
cliente, puedes hacerle llegar un diagrama entidad-relación de la
base de datos junto con su diccionario de datos y diagrama de
clases, al menos, pues de esta manera se podrán dar cuenta que lo
que se comunicó en la fase de análisis es lo que se está
construyendo como el esqueleto de su proyecto.
Ten muy en cuenta que el diseño es el “esqueleto” de tu proyecto,
cualquier error importante no detectado, o bien, detalles no
contemplados podrían llevar a tu proyecto a transformase en un
“Frankenstein”.

6. Motivación débil
Cuando de equipos de trabajo se trata, la motivación es un aspecto
crucial para tener en cuenta y cuidar en los miembros de un equipo.
Cuando el personal está totalmente motivado garantiza en gran
medida el éxito del proyecto, pues las tareas a realizar se ejecutan
con total plenitud, hacen “suyo” la labor y por consecuencia dan lo
mejor de sí, obteniendo un producto estable y de calidad.
Uno como líder de proyecto se puede dar cuenta fácilmente de la
motivación de su equipo, si y sólo si conoce bien la personalidad
de cada uno, pues es importante aprender a leer todas las señales,
incluso el lenguaje corporal, que también habla y mucho.

Conclusión
Cuando los proyectos de software fracasan, generalmente es debido
a problemas de trabajo en equipo y no a aspectos técnicos, por
tanto, para construir y mantener relaciones de trabajo eficaces se
necesitan metas comunes, un entorno de trabajo amigable, plan de
acción acordado y liderazgo apropiado.
Cada miembro del equipo también necesita comprender las
fortalezas y debilidades de otros, soportar a sus compañeros de
equipo, y estar dispuesto a solicitar su ayuda cuando se necesite.
el desconocimiento del negocio también no solo provoca mala
calidad de software, esto puede llevar al fracaso total del proyecto.
Si no se cuenta con expertos del negocio en el diseño de la solución
es muy probable que el proyecto fracase. El contar con expertos
levantando requerimientos y no diseñando la solución, no
soluciona el problema.

También podría gustarte