Documentar Proyectos De Investigación ¿Cómo hacerlo?
Hoy más que nunca es fácil tener acceso a información sobre prácticamente cualquier tema.
Sin embargo, no todas las fuentes son confiables y no pocas son copia y pega de Wikipedia, que si bien te puede sacar de un apuro con su vasta colección de conocimientos colectivos, no es para nada recomendable cuando se trata de documentar un archivo de investigación serio.
No es mi intención añadir un libelo más contra el sitio, Sin embargo, cuando se trata de documentar con fines de investigación científica o académica es necesario recurrir a fuentes serias y profesionales que aseguren la fiabilidad de los datos.
A continuación comparto una presentación donde se describe como realizar una investigación desde su planteamiento, incluyendo la selección de las fuentes con un enfoque formal.
domingo, 2 de abril de 2017
Mega Publicación:
Temas de la Unidad 3 y 4
Hasta ahora solo habíamos cubierto los
aspectos meramente requisitales del proceso de desarrollo de un software,
mismos que ya he expuesto en entradas anteriores de este blog. Sin embargo,
estimado lector, que mi pobre redacción no le induzca a pensar que considero o
que deba considerarse a estos procesos iniciales como algo que deba tomarse a
la ligera.
Estas etapas iniciales son de hecho más
importantes que lo que a continuación expondré, pues lo que sigue no es más que
la concreción de lo que ya fue establecido gracias a esas etapas primeras. Sin
ellas, no existirían esas valiosas pautas que son las que regirán el proyecto
de ahora en más.
Una vez definidos los requerimientos
precisos es tiempo de abordar el tema siguiente.
El siguiente paso implica construir el
software.
Sin embargo este es un proceso complejo
en sí mismo, ¿Cómo proceder?
Actualmente tenemos acceso al conocimiento
de distintas formas como un equipo puede abordar el desarrollo de software. A
continuación haré una breve descripción de lo que son los modelos de desarrollo
de software así como de los principales que hay y como se efectúan. Después
pasaré a hacer exposición de otras herramientas que es necesario tomar en
consideración para esta etapa.
Modelos De Desarrollo De Software
¿Qué son?
Los modelos para el desarrollo de
software son una representación abstracta de un proceso. Cada modelo representa
un proceso desde una perspectiva particular y así proporcione información
parcial sobre el proceso. Éstos modelos generales no son descripciones
definitivas de los procesos del software más bien son abstracciones de los
procesos que se pueden utilizar para el desarrollo del software.
Es decir, dadas las condiciones como se
plantea un software, el modelo ofrece lineamientos generales sobre cómo
proceder en cuanto a su desarrollo. Esto no implica que el equipo, una vez
elegido el modelo que más les conviene, deba seguirlo a rajatabla, puede
adaptarlo y hacerle las adiciones que el proyecto exija. Sin embargo debe
considerarse que apresurar los pasos afectará la calidad del producto final.
Modelos
Cascada
El más básico y conocido.
Se basa en el ciclo convencional de una
ingeniería y su visión es muy simple: el desarrollo de software se debe
realizar siguiendo una secuencia de fases. Cada etapa tiene un conjunto de
metas bien definidas y las actividades dentro de cada una contribuyen a la
satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la
misma. Etapas La nomenclatura de las mismas varía en función de los autores: Ingeniería y Análisis de sistema Análisis de requerimientos Diseño Codificación Prueba Mantenimiento
XP
También conocido como “eXtreme
Programming”.
Catalogado como un “modelo rápido”,
define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en
excelentes condiciones al colocar al cliente en el centro del proceso de
desarrollo, manteniendo una cercana relación con dicho cliente.
Características
Se desarrolla bajo los lineamientos
siguientes:
Los
equipos trabajan directamente con el cliente durante ciclos cortos de una o dos
semanas como máximo.
La
entrega de las versiones del software ocurre muy temprano y en intervalos muy
cortos para maximizar la interacción con el usuario.
Se
pone un excepcional énfasis en la colaboración entre el equipo de desarrollo
mientras trabaja en el código.
El
código se prueba y depura a lo largo del proceso de desarrollo.
Debe
haber indicadores que miden el progreso del proyecto para poder actualizar el
plan de desarrollo.
DRA
Es el proceso de desarrollo de
software diseñado para facilitar y acelerar la creación de aplicaciones, que
permite construir sistemas utilizables en poco tiempo, normalmente en un plazo
de entre 60 a 90 días.
Es una adaptación a "Alta
velocidad" en el que se logra el desarrollo rápido utilizando un enfoque
de construcción basado en componentes.
Características
·Debido
a que el software o aplicación se requiere lo más pronto posible no existe una
especificación del sistema detallada.
·El
software no se desarrolla y utiliza en su totalidad, sino en una serie de
etapas, donde en cada una se incluyen nuevas funcionalidades al sistema.
·Se
desarrollan las interfaces de usuario del sistema utilizando un sistema de
desarrollo interactivo que permite que el diseño de la interfaz se cree
rápidamente dibujando y colando iconos en la interfaz.
·Para
su desarrollo se utilizan herramientas de desarrollo visual para agilizar el
proceso.(UCI)
·Se
necesitan equipos compuestos por alrededor de seis personas, incluyendo desarrolladores
y usuarios de tiempo completo, así como aquellas personas involucradas en los
requisitos.
Espiral
En este modelo, el sistema se
desarrolla en una serie de versiones incrementales. Durante las primeras
iteraciones, la versión incremental podría ser un modelo en papel o un
prototipo. Durante las últimas iteraciones se producen versiones cada vez más
completas de ingeniería del sistema.
Este modelo en espiral se divide en un
número de actividades de marco de trabajo, también llamadas regiones de tareas:
Comunicación con el cliente
Planificación
Análisis de riesgos
Ingeniería
Construcción y acción
Evaluación del cliente
Características
Útil como
enfoque realista del desarrollo de sistemas y de software a gran escala.
Como el
software evoluciona, a medida que progresa el proceso el desarrollador y
el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los
niveles evolutivos.
Utiliza la
construcción de prototipos como mecanismo de reducción de riesgos.
Permite a
quien lo desarrolla aplicar el enfoque de construcción de prototipos en
cualquier etapa de evolución del producto.
Mantiene
el enfoque sistemático de los pasos sugeridos por el ciclo de vida
clásico, pero lo incorpora al marco de trabajo iterativo que refleja de
forma más realista el mundo real.
Demanda
una consideración directa de los riesgos técnicos en todas las etapas del proyecto,
y, si se aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemáticos.
SCRUM
Este modelo está pensado para
proyectos de menor escala o equipos de trabajo pequeños.
Es una metodología ágil y flexible
para gestionar el desarrollo de software, cuyo principal objetivo es maximizar
el retorno de la inversión para su empresa (ROI). Se basa en construir primero
la funcionalidad de mayor valor para el cliente y en los principios de
inspección continua, adaptación, auto-gestión e innovación.
Características
•Enfatiza valores y prácticas de gestión, sin
pronunciarse sobre requerimientos, prácticas de desarrollo, implementación y
demás cuestiones técnicas.
•Hace uso de
Equipos auto-dirigidos y auto-organizados.
•Puede ser
aplicado teóricamente a cualquier contexto en donde un grupo de gente necesita
trabajar junta para lograr una meta común.
•Desarrollo
de software iterativos incrementales basados en prácticas ágiles.
Proceso Unificado De Desarrollo
Es una metodología de desarrollo de
software que está basado en componentes e interfaces bien definidas, y junto
con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar
más utilizada para el análisis, implementación y documentación de sistemas
orientados a objetos.
Es un proceso que puede especializarse
para una gran variedad de sistemas de software, en diferentes áreas de
aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaños de proyecto.
Características
Principales
·Unifica
los mejores elementos de metodologías anteriores.
·Preparado
para desarrollar grandes y complejos proyectos
·Orientado
a Objetos.
·Utiliza
el UML como lenguaje de representación visual.
·Principales
ventajas
·Coste
del riesgo a un solo incremento.
·Reduce
el riesgo de no sacar el producto en el calendario previsto.
·Acelera
el ritmo de desarrollo.
·Se
adapta mejor a las necesidades del cliente.
Fases
Cada fase representa un ciclo de
desarrollo en la vida de un producto de software:
Fase
de concepción o inicio
Tiene por finalidad definir la visión,
los objetivos y el alcance del proyecto, tanto desde el punto de vista
funcional como del técnico, obteniéndose como uno de los principales resultados
una lista de los casos de uso y una lista de los factores de riesgo del
proyecto.
Fase
de elaboración
Tiene como principal finalidad
completar el análisis de los casos de uso y definir la arquitectura del
sistema, además se obtiene una aplicación ejecutable que responde a los casos
de uso que la comprometen.
Fase
de construcción
Está compuesta por un ciclo de varias
iteraciones, en las cuales se van incorporando sucesivamente los casos de uso,
de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por
ejemplo contar en forma temprana con versiones el sistema que satisfacen los
principales casos de uso. Los cambios en los requerimientos no se incorporan
hasta el inicio de la próxima iteración.
Fase
de transición
Inicia con una versión “beta” del
sistema y culmina con el sistema en fase de producción.
Fundamentos De La Programación
Orientada A Objetos
La programación orientada a objetos es
una forma de organizar el código de un programa agrupándolo en objetos. A su vez los objetos son elementos
individuales que contienen información (valores de datos) y funcionalidad.
La utilización de un enfoque orientado
a objetos para organizar un programa permite agrupar partes específicas de la
información junto con funcionalidad o acciones comunes asociadas con dicha
información.
Estos elementos se combinan en un solo
elemento, denominado objeto.
Poder agrupar estos valores y
funciones proporciona varias ventajas, como la capacidad de hacer un
seguimiento de una sola variable en lugar de tener que controlar varias
variables, agrupar funcionalidad relacionada y poder estructurar programas de
maneras que reflejen mejor el mundo real.
A su vez esta se compone por:
Análisis
Orientado a Objetos
Su objetivo es desarrollar un modelo
que describa el software de computadora necesario para satisfacer los
requisitos definidos por el cliente. El modelo de análisis contiene el
funcionamiento y el comportamiento de los elementos del modelo de objetos.
Su propósito es definir todas las
clases, atributos, operaciones y relaciones de comportamiento asociado entre
ellos que sean relevantes al problema que se va a resolver.
Para realizar este análisis se deben
realizar las siguientes tareas:
Identificar
los escenarios o casos de uso
Identificar
las clases
Definir
sus atributos y métodos
Especificar
la jerarquía entre las clases
Representar
las relaciones entre los diferentes objetos del sistema
Modelar
el comportamiento de cada objeto
Repetir
iterativamente las tareas anteriores hasta completar el modelo
Diseño
Orientado a Objetos
Consistente en representar un modelo
de datos que se pueda implementar con algún lenguaje de programación orientado
a objetos (Java, PHP, Python, C++)
Los objetos son componentes
potencialmente reutilizables, lo que hace que el software sea más fácil de
mantener.
El proceso general para el diseño
orientado a objetos tiene varias etapas:
·Comprender
y definir el contexto y los modos de utilización del sistema.
·Diseñar
la arquitectura del sistema.
·Identificar
los objetos principales en el sistema
·Desarrollar
los modelos de diseño.
·Especificar
las interfaces de los objetos.
Diagrama De Casos De Uso
Si bien, el tema de los casos de uso
ya había sido abordado con anterioridad, me tomaré la molestia de recordarnos
que son:
“Un caso de
uso es la imagen de una funcionalidad del sistema, desencadenada en respuesta
al estímulo de un actor o rol externo”
Es decir, se
refiere a las distintas interacciones celebradas entre el software y aquellos
que interactúan con este, sean usuarios u otros sistemas.
Acorde a lo
anterior un diagrama de casos de uso representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en
como los elementos interactúan (operaciones o casos de uso).
Elementos
Un diagrama de
casos de uso contiene:
Actor
Es
el rol que un usuario juega con respecto al sistema. Al hablar de rol es necesario especificar que un Actor no
necesariamente representa a una persona en particular, sino más bien la labor
que realiza frente al sistema.
Caso de uso
Otra vez, pero
dicho con palabras distintas que espero sean más fáciles de recordar, es una operación o tarea específica que se realiza tras una orden
de algún agente externo, sea desde una petición de un actor o bien desde la
invocación desde otro caso de uso.
Relaciones
Pueden ser:
·Asociación
Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha
relación se denota con una flecha simple.
·Dependencia o Instanciación
Es una forma particular de relación entre clases, en la
cual una clase depende de otra, es decir, se instancia. Dicha relación se
denota con una flecha punteada.
·Generalización
Este tipo de relación es uno de los más utilizados,
cumple una doble función dependiendo de su estereotipo, que puede ser de Uso
(<<uses>>) o de Herencia (<<extends>>). Este
tipo de relación está orientada exclusivamente para casos de uso (y no para
actores).
Diagrama
De Clases
Los diagramas
de clases se utilizan para modelar la visión estática de un sistema.
Normalmente contienen: clases, interfaces y relaciones entre ellas: de
asociación, de dependencia y/o de generalización.
Los diagramas de clases también pueden
contener a paquetes o subsistemas, que se usan para agrupar elementos del
modelo en partes más grandes (por ejemplo, paquetes que a su vez contienen a
varios diagramas de clases).
Al igual que otros diagramas, en los diagramas
de clases pueden aparecer notas explicativas y restricciones.
Tuve que resumir bastante los temas, querido lector y traté de darle forma a estos muros de texto para no cansarte, pero si como yo prefieres aprender con dibujitos, letras enormes y colores en todos lados, a continuación te dejo unos links que te podrían ser de utilidad.
Y como hoy me siento generoso déjame ahorrarte unos clicks y presentarte el siguiente video que habla sobre la POO, donde te cuentan todo eso que yo en mi torpeza ignoré... Pero te prevengo que dura una hora, asi que mejor ve sacando las palomitas y el refresco.
