Please enable JavaScript.
Coggle requires JavaScript to display documents.
Actividades Estructurales de la Ingeniería de Software - Coggle Diagram
Actividades Estructurales de la Ingeniería de Software
Comunicación
Escuchar
Enfocarse en lo que dice el hablante más que en posibles respuestas
Evitar parecer arrogante o poco agradable
Antes de comunicarse, prepararse
Dedicar tiempo a realmente comprender el problema antes de consultarlo con otros
Realizar investigaciones propias para entender el lenguaje del negocio
Preparar una agenda para una reunión si es su responsabilidad conducirla
Alguien debe facilitar la actividad
Toda reunión debe de tener un líder que haga las siguientes cosas:
Mantener la conversación dirigida hacia una dirección positiva
Ser un mediador en caso de conflictos
Garantizar que los demás principios se cumplan
Es mejor la comunicación cara a cara
Intentar estar siempre presente en reuniones con información relevante para poder aclarar posibles puntos de confusión y para facilitar el uso de otras herramientas como dibujos
Tomar notas y documentar las decisiones
Mantener un "secretario" que mantenga minutas de todas las reuniones
Esto se hace para evitar que detalles importantes se olviden en el futuro
Perseguir la colaboración
Genera confianza entre los miembros del equipo
Crea un objetivo común para el grupo
Permanecer centrado; hacer módulos con la discusión
Entre más gente hay, más facil es perder el enfoque
Modularizar y separar partes de la conversación para abandonar un módulo sólamente cuando ya el tema se haya resuelto
Si algo no está claro, hacer un dibujo
La conversación verbal tiene sus limitaciones
Crear bocetos y esquemas para facilitar la comunicación
Con respecto a los avances:
1) Una vez se acuerde algo, avanzar
2) Si no es posible ponerse de acuerdo en algo, avanzar
3) Si una función no está clara o aún no se puede aclarar, avanzar
La comunicación requiere tiempo, por lo cual a veces en vez de iterar indefinidamente en un tema, a veces es más ágil iniciar con algo base y luego refinar
Intentar que ambas partes ganen
No tratar la comunicación como una competencia, sino como colaboración mutua
Negociar funciones, tiempos de entrega, etc de tal manera que ayude a llevar al equipo a cumplir su objetivo común.
Planeación
Entender el alcance del proyecto
Definir el alcance para darle un destino al equipo de software
Involucrar en la actividad de planeación a los participantes del software
Estos facilitan tomar en cuenta las prioridades a la hora de planificar el proyecto
Importante para negociar el orden de entrega
Reconocer que la planeación es iterativa
El plan para un proyecto nunca está grabado en piedra
Es muy probable que el panorama cambie para cuando inicie un proyecto, por lo cual se deberá de ajustar a los cambios
Los modelos de proceso iterativos requieren que se repita la planeación luego de cada incremento, tomando en cuenta posibles cambios
Estimar con base en lo que se sabe
Recordar que el objetivo de la estimación es sacar posible tiempo y esfuerzo requerido para el trabajo que se va a realizar
Si las cifras que basan estas estimaciones no son confiables, la estimación tampoco lo será
Al definir en plan, tomar en cuenta los riesgos
Facilita la elaboración de planes de contingencia
El proyecto siempre se deberá de ajustar si alguno de estos riesgos termina ocurriendo
Ser realista
Nadie trabaja al 100% todos los días
Siempre habrá ruido en la comunicación
Las omisiones y la ambigüedad son parte de la vida
Los cambios ocurren
Considerar los siguientes hechos:
Incluso los mejores ingenieros cometen errores
Ajustar la granularidad cuando se defina el plan
La granularidad va de poca a mucha en lo que avanza el tiempo y el proyecto
Enfocarse principalmente en detalles significativos cuando se trata de grandes lapsos de tiempo o algo que esté muy a futuro
Granularidad: el nivel de detalle que se adopta cuando se desarrolla un plan
Definir cómo se trata de asegurar la calidad
Se debe de identificar la forma en la que se buscará asegurar la calidad
Programar revisiones técnicas si se planean realizar
Planear de manera explícita si se debe de utilizar programación por parejas
Describir cómo se busca manejar el cambio
Toda planeación se puede cancelar sin un buen control de los cambios
Identificar de qué forma se van a realizar dichos cambios
Algunas preguntas guía son:
¿El cliente tiene la posibilidad de solicitar un cambio en cualquier momento?
Si se solicita un cambio, ¿está obligado el equipo a implementarlo de inmediato?
¿Cómo se evalúan el
efecto y el costo del cambio?
Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran
Evaluar diariamente el avance
Cuando se detecten desviaciones al plan, se debe de reajustar el plan
Modelado
El objetivo principal del equipo es hacer software, no crear modelos
Recordar que los principios Agile se enfocan en la entrega de software funcional
Evitar modelos que retrasen el proceso sin dar una cantidad de perspectiva con suficiente valor
Viajar ligero, no crear más modelos de lo necesario
Cada modelo nuevo requiere tiempo
Cuando se realicen cambios, tener más modelos de lo necesario exigirámás tiempo para actualizarlos
Tratar de producir el modelo más sencillo que describa al problema o al software
Mayor simplicidad en el modelado llevará a un producto final más simple y eficiente
Modelos sencillos ayudarán a crear un software más fácil de integrar y mantener
Los modelos sencillos son más fáciles de entender, comunicar y criticar, lo que llevará a un producto final más óptimo
Construir modelos susceptibles al cambio
En lo que se modifican los requisitos, se tienden a olvidar los modelos debido a que se sabe que estos van a cambiar
Recordar que los modelos servirán como base durante toda la construcción del producto
Ser capaz de enunciar un propósito explícito para cada modelo que se cree
Preguntar por qué se está realizando un modelo antes de crearlo
Si no hay una razón explícita, no hay motivo para gastar tiempo en el modelo
Adaptar los modelos que se desarrollan al sistema en cuestión
Es posible que la notación del modelo tenga que cambiar dependiendo del tipo de software que se esté creando
Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos
Enfocarse en lo práctico sobre lo perfecto
Si se gasta mucho tiempo en un modelo, su valor disminuye
Modelar pensando en las siguientes etapas de la ingeniería de Software
No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para comunicar contenido, la comunicación es secundaria
Lo más importante del modelado es comunicar las ideas, no apegarse a una notación específica
Si un modelo logra comunicarse correctamente, ya con eso logró su objetivo
Si su instinto dice que un modelo no es correcto a pesar de que se vea bien en papel, hay razones para preocuparse
La experiencia nos deja saber qué partes del modelado, por tan bien que se vean, causarán complicaciones
Pensar nuevamente en cómo realizar el módulo si se encuentra dudando en alguna parte del modelado
Obtener retroalimentación lo antes posible
Todo modelo debe de ser validado por el equipo
Se debe de confirmar que el modelo cumple con los objetivos a gran escala
La retroalimentación temprana ayuda a corregir errores de modelado
Construcción
Con respecto a la preparación, asegurarse de:
Entender el problema que se trata de resolver
Comprender los principios y conceptos básicos del diseño
Elegir el lenguaje de programación correcto para el software que se creará
Seleccionar un ambiente de programación que tenga las herramientas necesarias para facilitar el trabajo del desarrollador
Planificar las pruebas unitarias que se aplicarán al terminar el componente a codificar
Con respecto a la programación, asegurarse de:
Aplicar la programación estructurada para restringir sus algoritmos
Pensar en aplicar la programación por parejas
Seleccionar estructuras de datos que satisfagan las necesidades del diseño
Entender la arquitectura del software y asegurar que se mantenga la coherencia al crear las interfaces
Mantener la lógica condicional lo más sencilla posible
Crear lazos anidados que sean fáciles de probar
Utilizar nombres intuitivos para las variables y seguir los estándares locales de programación
Escribir código que se documente a sí mismo
Crear una imagen visual que ayude a entender el código, usando por ejemplo lineas con sangría y en blanco
Con respecto a la validación, asegurarse de:
Realizar el recorrido cuando sea apropiado (una vez se haya terminado su primer intento de codificación
Llevar a cabo pruebas unitarias y corregir los errores detectados
Rediseñar el código
Principios de las pruebas:
Una prueba es el proceso de correr un programa con el objetivo de encontrar un error
Un buen caso de prueba es aquel que tiene alta probabilidad de encontrar un error no detectado previamente
Una prueba exitosa es aquella que detecte un error no detectado hasta el momento
Principios de la construcción
Todas las pruebas deben de poder rastrearse hasta los requerimientos del cliente
Los errores de mayor prioridad son aquellos que no permitan cumplir los requerimientos planteados en la comunicación
Las pruebas deben planearse mucho antes de que se realicen
Estas se deben de planear apenas se termine el modelo de requerimientos
todas las pruebas pueden planearse y diseñarse antes de generar cualquier código
El principio de Pareto aplica a todas las pruebas de software
80% de los errores no detectados nacen del 20% de los componentes del programa
Se debe de hacer un análisis para poder determinar cuáles podrían ser estos componentes problemáticos
Las pruebas deben comenzar en lo pequeño y avanzar hacia lo grande
Enfocarse en componentes individuales al principio
En lo que avanzan las pruebas, enfocarse en grupos integrados de componentes y luego de esto en el sistema completo
Las pruebas exhaustivas no son posibles
Despliegue
Deben manejarse las expectativas del cliente
Es muy común que el cliente espere más de lo que se está entregando, lo cual puede crear daños de moral
Se debe siempre de comunicar claramente lo que el software puede hacer y lo que no se puede hacer
Debe ensamblarse y probarse el entregable completo
Ensamblar un ejecutable del software con todos los archivos de apoyo que se necesiten
Se deben de realizar pruebas exhaustiva con dicho ejecutable
Establecer un régimen de apoyo antes de la entrega
Planificar cómo se manejará el apoyo post-entrega al cliente, y preparar los materiales que sean necesarios para este mismo apoyo
Proporcionar materiales de aprendizaje
Preparar manuales de uso para usuarios finales del aplicativo
Se debe de entregar más que solamente el software
Corregir el software defectuoso antes de la entrega
Entregar software de baja calidad con la intención de arreglarlo más adelante es un error, ya que genera incomodidad del lado del cliente.
El cliente más fácil se acuerda de un producto de mala calidad que de uno de buena calidad
