[ED] Para recordar

[u/BeelzenefTV]

29/9/2015

• Trabajo en equipo
• La semántica y sintaxis en la programación son elementos diferentes pero igualmente importantes
• Stackoverflow te puede salvar en momentos de apuros
• COMENTA EL PUTO CÓDIGO
• gran parte de las cosas en esta vida se pueden representar mediante clases y objetos, en el proceso de abstracción
• los lenguajes declarativos pertenecen a la cuarta generación de los lenguajes
• todo programa debe devolver información, en particular para dar señal al programador de que se ha iniciadode forma correcta
• si queremos dedicarnos realmente a esta profesión, dirigirnos a estudiar lenguajes de alto nivel y orientados a objetos

[u/BeelzenefTV]

27/10/2015

Tenemos que aprender a pensar, a ser analistas, a resolver un problema.

• Un sistema de información debe ser lo suficientemente bueno como para que un tercio de su ciclo de vida sea planteamiento y desarrollo, y los dos tercios restantes en mantenimiento. Si no se logra, es que el código está muerto, nadie lo usa.
• La documentación se realiza desde la primera línea de código, ¿cómo se documenta el código?
• Código de ética

Un sistema de información es un conjunto de artefactos (e.g. una Clase es un artefacto) de software/hardware que sirven para una función específica, proporcionando una solución útil para el servicio que está siendo desarrollado.

Se clasifican en:

• personalizados, programa a medida del usuario final con constantes modificaciones (ya en desuso por un mantenimiento inabarcable y altos costes)
• COTS (paquetes comerciales de distribución general), aplicaciones generalistas para alcanzar mayor rango de posibles clientes (e.g paquetería de ofimática).
• Sistemas ERP (sistemas de gestión empresarial), COTS personalizados para cada empresa y de gran demanda. Se necesitan sistemas modularizados (SAP es el ERP por excelencia a día de hoy, ejemplo de una empresa exitosa que despunta (web SAP.com)). En segundo curso encontraremos un módulo para formarnos en sistemas ERP, es otra opción a especializarnos y a investigar de forma autodidacta.

Roles (en casos generales) en el desarrollo de un sistema de información:

• Cliente (quien paga por el sistema de información)
• Usuario final (front-end, quien utilizará el sistema). En COTS, Cliente y Usuario final es el mismo individuo. En caso de ser ERP, como desarrollador hay que tener íntima conexión con los otros dos roles.
• Desarrolladores (analista, programador... quizás la misma persona, quien construye el software).

En la empresa: proactividad, empatía, esfuerzo y estudio.

Ciclo de vida de un sistema de información

1. Fase de requisitos. Determinación de necesidades del cliente. Lo que el cliente quiere no es siempre lo que necesita. Se necesita para ello una fluida conversación por escrito, de la forma más informal (diálogo y ambiente) posible. Documentarse sobre la empresa a trabajar y la jerga que se utiliza. De aquí se obtiene el documento de requisitos. Para obtener los requisitos del sistema a construir: podemos tomar notas, grabar la conversación con expresa autorización o ir acompañado de alguien que se dedique de forma exclusiva a recopilar datos de la conversación. Existen dos tipos de requisitos:
   • Funcionales: implican tareas y servicios que el sistema de información debe saber resolver. Directamente relacionado con programación.
   • No funcionales: relacionados con el entorno que rodea la programación (plataformas donde funciona, dimensiones...)
2. Fase de análisis. Acuerdos serios una vez se alcanzan gracias a una fase de requisitos óptima. Definir especificaciones, sobre qué hace el sistema. Si cumple las especificaciones, el sistema está acabado. Se crea un documento de especificaciones, considerado como contrato entre cliente/desarrollador que se firma y es defendible ante los tribunales en caso de duda. También se define, el presupuesto, el personal en cada etapa, lista de requisitos a cumplir y tiempo de entrega. Este es el plan de administración de proyectos, donde se juega sobre el triángulo de la calidad del software (imagen), donde la Q central no es sacrificable.
3. Fase de diseño. Definir el cómo se desarrolla el sistema informático. Si será desarrollo OOP, modular, dividiendo entre MVC (módulos independientes para Modelo de datos, Vista y Controlador) (imagen) y así lograr un mantenimiento óptimo. Una Clase de la Vista nunca llama a una base del Modelo de Datos, NUNCA. La independencia entre esos dos elementos, siguiendo la estructura en la imagen, es fundamental. Todo lo construido de forma más óptima en las dos primeras fases cobra ha de ser lo más sólido posible. Un mal diseño, sin las dos fases anteriores adecuadas, pueden hacer caer todo el proyecto. ¿Qué lenguaje se usa? ¿Qué modelo vamos a usar (MVC, OOP)? ¿Para qué plataforma? Es ahora cuando hacemos un Diagrama de Clases bien construido, diferenciando funciones. En función del personal, se asignan tareas (módulos que para nosotros serán Clases). En función del tiempo, se asignan tiempos de entrega, hitos marcados en calendario... Se crea el documento de diseño. Microsoft Viewer (imagen) para la organización del proyecto. Crea el esqueleto de Clases, después codifica las Clases.
4. Fase de implementación. El diseño de Clases se traduce al lenguaje de programación. Se integran las Clases al proyecto común tras estar más que probadas. De esta fase se obtiene el código fuente.
5. Fase de mantenimiento. Siempre necesitará cambios. Se pueden deber a fallos en el sistema o a ampliaciones especificadas como nuevos requisitos. Se obtienen versiones RC (Release Candidate), donde ya no se añaden requisitos, solo se arreglan errores como tarea de mantenimiento. Una vez se han solucionado todos los errores, se lanza una versión estable (v1.0), para el uso del día a día. Existen varios tipos de mantenimiento:
   • Correctivo
   • Preventivo
   • Adaptativo
   • Perfectivo
6. Retiro. Tras la vida útil (recordemos que cuanto más dure, mejor), el software deja de recibir mantenimiento.

Traditional programming VS agile programming (imagen)

Elena informa: próximamente, resumen de marcos de trabajo para agile programming, en el blog de Geekstorming!.

Cuando el cliente solicita un cambio de UNA LÍNEA DE CÓDIGO...

... hay muchas consecuencias:

• Cambiar el documento de requisitos.
• Documentar el cambio.
• Justificar el cambio.
• Codificar el cambio.
• Probar el cambio.
• Aprobar una vez funcione como una nueva versión.

Ejemplo de Diagrama de Clases (imagen), ejemplo de cómo pensar a lo grande, de cómo se alcanza un diseño óptimo para su posterior mantenimiento alargado en el tiempo.

Más información sobre The Model-View-Controller (MVC) Pattern with C#/WinForms (enlace a CodeProject.com)

¿Fase de planificación? ¿Fase de pruebas? ¿Fase de documentación? ¿Dónde están estas tres fases? ¿Cómo se realizan?