Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
PRINCIPIOS QUE GUÍAN LA PRÁCTICA создатель Mind Map: PRINCIPIOS QUE GUÍAN LA PRÁCTICA

1. Conocimientos de la Ing. de Software: Para programar computadoras es necesario conocer los detalles tecnológicos específicos.

2. PRINCIPIOS QUE GUÍAN TODA ACTIVIDAD ESTRUCTURAL

2.1. Principios de comunicación

2.1.1. 1. Escuchar.

2.1.2. 2. Antes de comunicarse, prepararse.

2.1.3. 3. Alguien debe facilitar la actividad.

2.1.4. 4. Es mejor la comunicación cara a cara.

2.1.5. 5. Tomar notas y documentar las decisiones.

2.1.6. 6. Perseguir la colaboración.

2.1.7. 7. Permanecer centrado; hacer módulos con la discusión.

2.1.8. 8. Si algo no está claro, hacer un dibujo.

2.1.9. 9. a) Una vez que se acuerde algo, avanzar. b) Si no es posible ponerse de acuerdo en algo, avanzar. c) Si una característica o función no está clara o no puede aclararse en el momento, avanzar.

2.1.10. 10. La negociación no es un concurso o un juego. Funciona mejor cuando las dos partes ganan.

2.2. Principios de planeación

2.2.1. 1. Entender el alcance del proyecto.

2.2.2. 2. Involucrar en la actividad de planeación a los participantes del

2.2.3. 3. Reconocer que la planeación es iterativa.

2.2.4. 4. Estimar con base en lo que se sabe.

2.2.5. 5. Al definir el plan, tomar en cuenta los riesgos.

2.2.6. 6. Ser realista.

2.2.7. 7. Ajustar la granularidad cuando se defina el plan.

2.2.8. 8. Definir cómo se trata de asegurar la calidad.

2.2.9. 9. Describir cómo se busca manejar el cambio.

2.2.10. 10. Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran.

2.3. Principios de modelado

2.3.1. 1. El equipo de software tiene como objetivo principal elaborar software, no crear modelos.

2.3.2. 2. Viajar ligero, no crear más modelos de los necesarios.

2.3.3. 3. Tratar de producir el modelo más sencillo que describa al problema o al software.

2.3.4. 4. Construir modelos susceptibles al cambio.

2.3.5. 5. Ser capaz de enunciar un propósito explícito para cada modelo que se cree.

2.3.6. 6. Adaptar los modelos que se desarrollan al sistema en cuestión.

2.3.7. 7. Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos.

2.3.8. 8. No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para comunicar contenido, la representación es secundaria.

2.3.9. 9. Si su instinto dice que un modelo no es el correcto a pesar de que se vea bien en el papel, hay razones para estar preocupado.

2.3.10. 10. Obtener retroalimentación tan pronto como sea posible.

2.3.11. Requerimientos de los principios de modelado.

2.3.11.1. 1. Debe representarse y entenderse el dominio de información de un problema.

2.3.11.2. 2. Deben definirse las funciones que realizará el software.

2.3.11.3. 3. Debe representarse el comportamiento del software (como consecuencia de eventos externos).

2.3.11.4. 4. Los modelos que representen información, función y comportamiento deben dividirse de manera que revelen los detalles en forma estratificada (o jerárquica).

2.3.11.5. 5. El trabajo de análisis debe avanzar de la información esencial hacia la implementación en detalle.

2.3.12. Principios del modelado del diseño.

2.3.12.1. 1. El diseño debe poderse rastrear hasta el modelo de requerimientos.

2.3.12.2. 2. Siempre tomar en cuenta la arquitectura del sistema que se va a construir.

2.3.12.3. 3. El diseño de los datos es tan importante como el de las funciones de procesamiento.

2.3.12.4. 4. Las interfaces (tanto internas como externas) deben diseñarse con cuidado.

2.3.12.5. 5. El diseño de la interfaz de usuario debe ajustarse a las necesidades del usuario final. Sin embargo, en todo caso debe resaltar la facilidad de uso.

2.3.12.6. 6. El diseño en el nivel de componentes debe tener independencia funcional.

2.3.12.7. 7. Los componentes deben estar acoplados con holgura entre sí y con el ambiente externo.

2.3.12.8. 8. Las representaciones del diseño (modelos) deben entenderse con facilidad.

2.3.12.9. 9. El diseño debe desarrollarse en forma iterativa. El diseñador debe buscar más sencillez en cada iteración.

3. PRINCIPIOS FUNDAMENTALES:

3.1. Principios que guían el proceso

3.1.1. 1. Ser ágil.

3.1.2. 2. En cada etapa, centrarse en la calidad.

3.1.3. 3. Estar listo para adaptar.

3.1.4. 4. Formar un equipo eficaz.

3.1.5. 5. Establecer mecanismos para la comunicación y coordinación.

3.1.6. 6. Administrar el cambio.

3.1.7. 7. Evaluar el riesgo.

3.1.8. 8. Crear productos del trabajo que agreguen valor para otros.

3.2. Principios que guían la práctica

3.2.1. 1. Divide y vencerás.

3.2.2. 2. Entender el uso de la abstracción.

3.2.3. 3. Buscar la coherencia.

3.2.4. 4. Centrarse en la transferencia de información.

3.2.5. 5. Construir software que tenga modularidad eficaz.

3.2.6. 6. Buscar patrones.

3.2.7. 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes.

3.2.8. 8. Tener en mente que alguien dará mantenimiento al software.

3.3. Principios generales que amplían el proceso y práctica:

3.3.1. 1) agregar valor para los usuarios finales

3.3.2. 2) mantenerlo sencillo

3.3.3. 3) fijar la visión (del producto y el proyecto)

3.3.4. 4) reconocer que otros consumen (y deben entender) lo que usted produce

3.3.5. 5) abrirse al futuro

3.3.6. 6) planear la reutilización

3.3.7. 7) ¡pensar!

4. Principios de construcción

4.1. Principios de codificación.

4.1.1. Principios de preparación

4.1.2. Principios de programación

4.1.3. Principios de validación

4.2. Principios de la prueba.

4.3. 1. Todas las pruebas deben poder rastrearse hasta los requerimientos del cliente.

4.4. 2. Las pruebas deben planearse mucho antes de que den comienzo.

4.5. 3. El principio de Pareto se aplica a las pruebas de software.

4.6. 4. Las pruebas deben comenzar “en lo pequeño” y avanzar hacia “lo grande”.

4.7. 5. No son posibles las pruebas exhaustivas.

5. Principios de despliegue

5.1. 1. Deben manejarse las expectativas de los clientes.

5.2. 2. Debe ensamblarse y probarse el paquete completo que se entregará.

5.3. 3. Antes de entregar el software, debe establecerse un régimen de apoyo.

5.4. 4. Se deben proporcionar a los usuarios finales materiales de aprendizaje apropiados.

5.5. 5. El software defectuoso debe corregirse primero y después entregarse.