Al principio esta solito. En mi soledad intente hacer un proyecto individual. Pero! PERO! el profe me dijo… «ve con ellos». Y yo «enserio?». «si» el profe dijo. Y fui con ellos. Fue asi como me integre al equipo de Raul y Miguel. Descarte mi idea y me junte a complementar la de ellos. Fue asi como juntos mejoramos el proyecto que ellos ya tenian y corregimos las notaciones que nos dio el profe en su feedback. Espero que este proyecto pueda terminar y poder cumplir con todos los puntos y requisitos que el profe nos aviente. WUUUJUUU!
Herramienta de evaluacion y administracion de proyectos para DOCSA
Herramienta de visualización de progreso para DOCSA
DOCSA es una constructora en Sinaloa que se encarga de construir obras públicas con presupuesto proveído por el gobierno. Docsa es una compañía ya establecida pero que no ha invertido mucho en el área de software y sus sistemas, y se busca hacer una herramienta remota donde se pueda ver el progreso de las construcciones en cuestión de cómo va la obra, cuanto se ha gastado en cuestión de recursos o de dinero, entre otras cosas. Esta herramienta busca ayudar la toma de decisiones ya que se manejan múltiples obras a la vez y tener todo en papel y por departamento segmentado en diferentes nodos dificulta la actualización de los datos y la comunicación entre departamentos.
Nombre del Decision Maker: Gabriel Avilés Robles
Visión: Poder administrar múltiples proyectos de la compañía de Docsa a tiempo real y con datos exactos a la situación actual de estos.
Caso de negocio para el software: En etapas tempranas del proyecto la empresa firmará horas de servicio profesional pero si el proyecto se lanza con éxito y se sigue trabajando en él, se me emplea con un salario para seguir agregando componentes y darle mantenimiento a los existentes.
Esfuerzo Preliminar y objetivos de calendario: Durante el semestre se tiene que terminar un prototipo remoto que se pueda utilizar en dos plataformas, en computadora y en tableta. Antes de esto se deben de generar prototipos locales de interfaces y de funcionamiento 1 a 1 para probar funcionalidades antes de usarlo con múltiples dispositivos.
Esfuerzo y estimados del calendario: Para inicios de verano cuando se pueda tener juntas presenciales con la empresa, se tiene que terminar un mvp que se comunica con un servidor y esto con diferentes dispositivos al mismo tiempo. Pero antes de esto, se planea tener prototipos con la funcionalidad básica pero progresando poco a poco durante el semestre. El primer prototipo se planea para finales de marzo con la funcionalidad mínima, y este va a ir progresando cada dos semanas con componentes extras de visualización u otras features que el cliente busque.
Principales riesgos:
- Hacer funcionalidades de manera incorrecta a la que el cliente buscaba por no tener mucha comunicación entre cliente y desarrollador
- Que las actividades de la escuela interrumpan o retrasen las entregas del proyecto
- Que la herramienta no sea lo suficientemente útil como para reemplazar la forma de trabajo actual
- Que los trabajadores no se puedan adaptar a nuevas tecnologías
- Que la transición de formas de trabajo atrasen mucho la empresa
- Que el cliente visualice un producto diferente al entregado
- Que el cliente busque alternativas sin avisar a este proyecto
- Problemas que se puedan causar al montarlo en un servidor
- Que pasen cosas en la empresa y que no se probaron en testing que causen probemas en la aplicacion
- Diseñar una interfaz amigable
Guia para la interfaz del usuario: El usuario debe tener su cuenta para acceder a la aplicación y debe tener su perfil con información sobre el. El usuario debe tener formas de alimentar la aplicación con información sobre su trabajo y el estado del proyecto que está manejando. El usuario debe ser capaz de visualizar de diferentes formas la información a la cual este tiene acceso.
Especificaciones del manual de usuario: Abra un manual específico al usuario y sus capacidades dentro de la aplicación, con pasos detallados de como usarla y cómo sacarle mayor provecho.
Plan de desarrollo de software: El desarrollo de software es hecho por una persona, así que primero se tiene que diseñar antes de codear todas las posibles formas de uso. Se usarán diagramas para modularizar el programa y segmentarlo en funcionalidades más importantes y después de tener claro en qué consta el proyecto empezar a codear y hacer el prototipo.
The Tar Pit (Reflexión)
The programming System Product
Un programa puede ser algo muy simple, donde su funcion pueda ser util pero de la manera en la que esta hecho no tan efectivo. Es por eso que este se puede convertir a un «programming product» o a un «programming system» donde su utilidad y costo de produccion aumentan.
En el programming product hace del programa algo que pueda ser corregido, testeado o expendido por quien sea. Las entradas pueden variar dependiendo de la situacion por lo que se tiene que generalizar para cualquier uso. Este programa puede costar 3 veces mas qeu uno ya especifico.
En el programming system se tienen multiples programas que se sincronizan para cumplir tareas mas grandes donde se tiene todas las comunicaciones y actividades en formatos estandarizados y las entradas y salidas se definen previamente en interfaces. Las pruebas deben ser extensivas probando cualquier tipo de caso que se pueda dar a llevar. Estos programas cuestan mas entre mas componentes tiene.
The Joys of the Craft
Existen varias razones por la cual los programadores. Los programadores les gusta poder diseñar cosas nuevas que nacieron del abstracto y se convirtio en un producto real. A los programadores les gusta poder ver que sus productos le ayudan a la gente y que los demas puedan tener mejor estilo de vida o puedan solucionar sus problemas con un producto que uno creo. A los programadores les gusta poder encontrar las respuestas a un problema complejo que necesito de mucha concentracion y conocimiento. El programador siempre esta aprendiendo y eso es algo que le trae satisfaccion ya que cada vez se autocompleta y se hace mejor academico y mejor persona.
Habilidades de supervivencia
Planeacion
El exito de un proyecto yace en la planeacion. Es una etapa en la que se considera los requerimientos de lo que se quiere lograr, los objetivos, el alcance, las herramientas que se ocuparan y hasta los errores que se pueden llevar acabo durante el desarrollo del proyecto.
Existen varias herramientas de planeacion y entre ellas esta:
- Plan de desarrollo de software: Este plan describe los pasos que se llevaran acabo para desarrollar el proyecto, que funciones, que modulos y que prototipos se desarrollaran y en que order.
- Estimados de proyecto: Da datos cuantitativos de lo que se puede necesitar en el proyecto, desde dinero hasta staff o software de desarrollo entre otras cosas.
- Estimacion de revisiones: planes de tiempo en los que se puede evaluar el progreso, hacer correcciones o cambios para poder seguir adelante.
- Aseguramiento de calidad: planeacion de formas de demostrar la calidad del producto a la manera en la que se desarrolla.
- Etapas de entrega del proyecto: una agenda detallada en la manera en la que se entregaran avances del proyecto.
Hay otras herramientas que se pueden presentar aqui como el diseño detallado, la arquitectura y los requerimientos, estos son escenciales para el futuro del proyecto.
Manejo de riesgos
Es un tipo de planeacion donde se considera solamente los riesgos, buscando los posibles errores no solo en codigo, pero tambien en recursos del equipo, manejo de empleados, seguridad dentro del proyecto, estudio de casos de fallo y como prevenirlos.
Control de Proyecto
Controlar el proyecto se refiere a controlar el proyecto y no a la gente. Se tiene que identificar los recursos que se necesita para poder desarrollar el producto, la metodologia de trabajo que llevara acabo la gente independientemente de quien sea, administrar los cambios en los requerimientos para que el proyecto solo sea afectado por los requerimientos aceptados para no alargar el plazo de entrega. Crear estanderes de programacion que se tiene que seguir para poder traficar el codigo en la organizacion sin que haya problemas de comunicacion y desarrollar un plan especifico de trabajo para que la gente que lo trabaje solo siga instrucciones y pasos para que no haya ambigüedades al momento de trabajar.
Visibilidad del producto
Aqui se trabaja la visibilidad del proyecto y como no solo los programadores pero todos puedan ver el status actual del proyecto y asi se pueda identificar oportunidades de mejora o posibles errores que se puedan generar.
Manejo del personal
Como identificar talento, creatividad y preparacion en los programadores y alentarlos a que busquen la vision del cliente a lo posible y no bloquearlos para que el desarrollo del proyecto fluya.
Involucramiento del usuario
Se necesita trabajar junto con el usuario cuando ya se tienen prototipos del producto ya que el usuario al final va a usar el producto asi que se tiene que trabajar alrededor de lo que al usuario le agrade y cambiar las cosas que opacan el interes de usar la aplicacion.
Minimalismo
Las aplicaciones hoy en dia son lo mas digeribles y faciles de usar para que el usuario no necesite instrucciones para poder emplear el producto. De esta manera no batalla para hacer uso de sus funciones y puede ver si se queda con el producto o no. Si se le pone obstaculos como la necesidad de tutoriales, el usuario posiblemente busque otra alternativa al producto ofrecido.
Conceptos de Supervivencia
La palabra proceso tiene muchos significados cuando nos encontramos en el mundo de desarrollo de software. Estos significados por lo general puede ser: utilizar todos los requerimmientos para escribir codigo, utilizar procedimientos sistematicos para controlar los requerimientos en cuestion de agregar más, llevar acabo revisiones de los requerimientos, diseños y del codigo, crear implementaciones que nos diran que hacer primero y que hacer despues en cuestion de desarrollo de funciones para el producto, entre otras definiciones.
Tambien tiene significados negativos no siempre ciertos por la comunidad, como el que un proceso es algo tardado y estricto pero al final ineficiente, este tipo de personas cree que para hacer un buen producto se requiere contratar a los mejores del campo, cuando en realidad el proceso y la administracion de desarrollo tienen un papel muy importante en cuestion a la calidad del producto.
Con este tipo de pensamiento no se le dedica su tiempo para diseñar planes, agendas y dividir tareas y termina el producto siendo no tan bueno por no querer gastar tiempo «productivo» en la planeacion y diseño. Por esto se puede llevar a acabo los siguientes escenarios:
- Change control: Cuando el equipo acepta como si nada todos los requerimientos que el cliente quiere y sin organizacion el proyecto se va retrasando costando más cada vez.
- Quality assurance: Proyectos donde no se arreglan los bugs o posibles casos de error en etapas tempranas provocando que al final se tengan arduas e intensas sesiones de debugging para arreglar el producto.
- Uncontrolled revisions: Cuando no se tiene un chequeo por errores y al final se detectan causando que se tenga que reescribir el programa y se tenga que rediseñar.
- Defect tracking: no se tiene control de los errores encontrados y estos se pueden olvidar ocasionando que el producto se lance al mercado con errores.
- System integration: Cuando se trabaja por separado y al momento de integral, al final de proyecto, se ocasionan problemas al momento de unir todos los componentes.
Otra objecion a utilizar procesos definidos es que segun esto la creatividad e inspiracion de los programadores se trunca y se lastima. Pero al final de cuentas un proyecto se debe definir lo mas especifico posible para que todos los involucrados tengan una idea clara de con que se esta trabajando, que se necesita y que se puede hacer para continuar con el trabajo.
Una de las maneras de poder trancisionarse a un sistema de procesos definidos es analizar el estado actual del proyecto y graficarlo para poder ver que partes necesitan cambios, y asi designar tareas necesarias para tener un mejor progreso.
Tambien se puede dividir el proyecto en upstream y downstream, el primero enfocandose mas a la parte de planeacion y diseño considerando requerimientos y objetivos, mientras que la segunda es simplemente el desarrollo y las pruebas. Es bueno identificar estos factores ya que se tiene que buscar que el primero quede lo mas cercano a perfecto para que los errores que se puedan producir en el upstream no afecten terriblemente al downsteam.
Algo que puede afectar negativamente el proyecto es que las proyecciones y visiones que se tienen en el upstream van mucho mas lejos de lo que se tiene en el downstream ocasionando problemas y interrupciones en futuras etapas.
Pruebas de sobrevivencia de un proyecto
Mas adelante se compartira un test que se puede hacer a los proyectos de diferentes prespestivas para saber el estado de «salud» del proyecto y poder prevenir fallos asi como tomar precauciones para resolver problemas que se puedan presentar durante éste.
En este test por cada uno que se cumpla se pone 3, si talvez 2 y si no 1. Y puedes ver el resultado sumando todos los reactivos y comparandolos con la siguiente tabla:
Este test te puede orientar a saber el estado actual del proyecto y poder reaccionar dependiendo de lo que este pasando.
La sobrevivencia en los proyectos de software
Por lo general los proyectos de software no prosperan. Son escasos los productos finales y exitosos comparado con los proyectos que se iniciaron alrededor de esos productos. Esto se debe a que se tiene que tener un buen ambiente en la administracion de proyecto y se tienen que considerar varias cosas para poder buscar el exito de tales.
Es normal que un usuario busque el producto perfecto, que se ejecute en el menor tiempo posible, que sea robusto y que no tenga ningun error. Pero para los desarrolladores y administradores de dichos productos sean programas, aplicaciones, entre otros con el hecho de tener el producto final y sacarlo al mercado es mas que suficiente para llamar al proyecto exitoso.
En realidad, cuando uno conoce los costos de los proyectos y las tareas que se necesitan, un buen proyecto tiene cierto margen de error para que sea un «buen» proyecto siempre y cuando se cumplan los tiempos en los que las tareas se tienen que terminar.
Cuando se habla de las necesidades de un proyecto de software una de las analogias más importantes para poder entender bien lo que se requiere es utilizar el diagrama de Maslow.
(De abajo para arriba)
- Necesidades de supervivencia: Asi como para Maslow las necesidades mas basicas son las fisicas y obligatorias para vivir, las necesidades de supervivencia de un proyecto son aquellas cosas fisicas que se requieren para desarrollar un proyecto de software, como lo son: tener el equipo fisico de trabajo, que el proyecto no se cancele en ningun momento, que las oficinas o areas de trabajo no tengan interrupciones o fachadas que obstruyan al momento de trabajar, entre otras cosas
- Necesidades de seguridad: Esto para Maslow es que la persona no tenga estres de inseguridad y tenga miedo constante de que algo pase. Para un proyecto esto se traduce a que las promesas y compromisos sean claros y que esten presentes. Que exista un contrato que dice que se espera y que se tiene que hacer para que un integrante del equipo no sienta una falta de proposito dentro del proyecto y que sepa bien claro que tiene que hacer y para cuando tiene que hacerlo.
- Sentimiento de pertenencia: Esta es una muy basica pero esencial y es que dentro de los equipos de trabajo se tenga buenas dinamicas de interaccion entre integrantes y que no existan cruces entre personas que puedan causar que la productividad baje. Esto promueve mejor trabajo en equipo y comunicación de logros o necesidades para poder seguir adelante.
- Autoestima: Esto en el contexto de desarrollo de un proyecto, es que el proyecto enorgullesca a quien lo trabaja. Que ningun miembro sienta que lo que hace no es necesario o no tiene un proposito bueno, si no que vean la importancia del producto y se esfuercen para lograr los objetivos
- Autorealizacion: Que el proyecto aun terminado tenga tracendencia en la carrera de los integrantes y que hayan aprendido nuevas cosas que puedan emplear en el futuro.
Las entes involucradas en el proyecto tambien deben de tener derechos establecidos ya seas el manager, el cliente o el trabajador. Estos derechos deben promover el progreso del proyecto y el beneficio que todos los involucrados reciben. Estos derechos pueden ser, en el caso del cliente; establecer objetivos que el proyecto debe cumplir o saber el progreso que el proyecto esta llevando. Asi como para el que lo trabaja debe tener el derecho a saber las metas del proyecto y los tiempos de entrega, o cambios en los objetivos del proyecto despues de que este haya empezado.
How can you wire when you are wireless?!? Security wise, obviously.
So. Wireless Security is very important, you get me. Everything is wireless and we cannot everything if everything is not secure. You feel me. So…. how can we wireless secure? You may ask me.. then…
CHECK OUT THIS POST YOU DAMN FOOL AND GET EDUCATED!
I collabed with Rodolfo Padró and created that beauty above.
You have activated my Trap card!
A very important part of our education in Information Security for us up and coming security experts is to learn about security countermeasures. A countermeasure is an action, process, device or system that can prevent or mitigate the effects of threats to our systems.
Countermeasures can take form of hardware, software or procedures. In these sense lets just list some possible countermeasures one can take against those meany mean threats out there in the world:
In the software department we can see countermeasure as:
- personal firewalls
- application firewalls
- anti-virus software
- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhh
- aiuda esto se va a descontrolar
- pop-up blockers
- spyware detection/removal programs
In the hardware department, apart from preventing the IP address of all users visible in the internet, we can also do:
- biometrics authentication systems
- physical restriction of access to computers and peripherals
- intrusion detectors
- alarms
And finally procedures we can take countermeasures as.
- frequent deletion of stored cookies and temporary files from Web browsers
- regular scanning for viruses and other malware
- regular installation of updates and patches for operating systems
- refusing to click on links that appear within e-mail message
- refraining from opening e-mail messages
- staying away from questionable web sites
- regularly baking up data on external media.
There are also many particular scenarios that need special treatment, some of them are:
- Encrypting data that is not used and is just resting in our databases for future use.
- Administrate access management with different powers in different accounts as in manager and employee and such.
- We can encrypt the network layer in order to prevent unwanted queries of our information
- We have to frequently patch our existing programs in order to fix flaws in our systems
There are also many things that we may have missed, but for that we need to keep studying and researching the ever growing ways to attack systems and to prevent those attacks.
This post was made in collaboration with Rodolfo Padró from https://rodolfopadro.wordpress.com/ Check out his other post about Security and other stuff hehe xd
Give me a N! NETWORK! Give me a S! SECURITY!
Network security is one of the application of everything we’ve learned so far. So … CHECK MY FRIENDS RODO POST!!!!! #panickingOfExcitement
Check his take on network security here: https://rodolfopadro.wordpress.com/2016/11/24/making-network-security-great-again/
lazynesstothemax 