Generalidades de la Administración de Proyectos

Etiquetas: Administración de Proyectos Informáticos, Conceptos

La Administración de Proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto, coordinando a las personas para completar las tareas con el dinero aprobado para realizar el proyecto.

Un Proyecto es un esfuerzo temporal, que posee inicio y final definidos,  que se lleva a cabo alcanzar un objetivo como pueden ser crear entregables únicos como un producto, servicio o resultado. Surgen como resultado de una necesidad o demanda, un avance tecnológico o requisito legal.

Todo proyecto tiene un director del proyecto, el cual es el responsable de alcanzar los objetivos del proyecto mediante el uso de conocimientos, habilidades, herramientas y técnicas y la aplicación e integración de los procesos de inicio, planificación, ejecución, seguimiento y control, y cierre.

La dirección de proyectos incluye

• Subproyectos: Componentes o partes de un proyecto que facilitan su gestión.
• Programas y Dirección de Programas. Grupos de proyectos relacionados.
• Portafolio y gestión de Portafolio. Grupo de programas , proyectos y otros trabajos que facilitan la gestión efectiva de los mismos, a fin de cumplir con objetivos del negocio.

En cada empresa que gestiona proyectos, es recomendable exista una Oficina de Gestión de Proyectos (PMO), que centralice y coordine la dirección de todos los proyectos, supervise la dirección de los proyectos, programas y una combinación de ambas, orienta la planificación y ejecución de proyectos y subproyectos para que esten vinculados co el objetivo del negocio y proporcione respaldo, asesoría, seguimiento o dirección y responsabilidad para lograr los objetivos de la empresa.

Metodología PMI

El Project Management Internacional (PMI), es la asociación sin fines de lucro más grande del mundo en el área de Administración de Proyectos. Desarrolla y opera el sistema de certificación en Administración de Proyectos más reconocido en el mundo en este momento: Project Management Professional (PMP).

Cico de Vida del Proyecto del Producto

Cico de Vida del Proyecto del Producto

Involucrados den el Proyecto

Involucrados den el Proyecto

Grupos de Procesos y Correspondencia de los Grupos de Procesos

Grupos de Procesos y Correspondencia de los Grupos de Procesos

Hender Orlando Puello Rincón

Ethernet

Etiquetas: Redes de Computadores, Conceptos

Ethernet no es una tecnología para networking, sino una familia de tecnologías para networking que incluye Legacy, Fast Ethernet y Gigabit Ethernet. Las velocidades de Ethernet pueden ser de 10, 100, 1000 ó 10000 Mbps. El formato básico de la trama y las subcapas del IEEE de las Capas OSI 1 y 2 siguen siendo los mismos para todas las formas de Ethernet.

El éxito de Ethernet se debe a los siguientes factores:

• Sencillez y facilidad de mantenimiento.
• Capacidad para incorporar nuevas tecnologías.
• Confiabilidad
• Bajo costo de instalación y de actualización.

E

n 1985, el comité de estándares para Redes Metropolitanas y Locales del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) publicó los estándares para las LAN. Estos estándares comienzan con el número 802.

El estándar para Ethernet es el 802.3. El IEEE quería asegurar que sus estándares fueran compatibles con el modelo OSI de la Organización Internacional de Estándares (ISO). Por eso, el estándar IEEE 802.3 debía cubrir las necesidades de la Capa 1 y de las porciones inferiores de la Capa 2 del modelo OSI. Como resultado, ciertas pequeñas modificaciones al estándar original de Ethernet se efectuaron en el 802.3.

Las diferencias entre los dos estándares fueron tan insignificantes que cualquier tarjeta de interfaz de la red de Ethernet (NIC) puede transmitir y recibir tanto tramas de Ethernet como de 802.3. Básicamente, Ethernet y IEEE 802.3 son un mismo estándar.

Ethernet opera en dos áreas del modelo OSI, la mitad inferior de la capa de enlace de datos, conocida como subcapa MAC y la capa física. 

La Capa 1 incluye

• Interfaces con los medios
• Señales
• Corrientes de bits transportadas en los medios
• Componentes que transmiten la señal a los medios
• Topologías

La Capa 2 se ocupa de las limitaciones de la Capa 1, como son:

• La comunicación con capas de nivel superios. Lo hace con el Control de Enlace Lógico o LLC.
• Identificar a las computadoras. Usa un proceso de direccionamiento.
• Organizar y agrupar bits. Entramado.
• Descifra cual computadora transmitirá los datos binarios. Usa el Control de Acceso a Medios MAC.

Ethernet utiliza direcciones MAC, tambien conocida como Identificador Exclusivo Organizacional (OUI), que tienen 48 bits de largo y se expresan como doce dígitos hexadecimales, donde los primeros seis dígitos identifican al fabricante o al vendedor y los seis dígitos restantes representan el número de serie de la interfaz u otro valor administrado por el proveedor mismo del equipo. A veces son denominadas direcciones grabadas (BIA) ya que estas direcciones se graban en la memoria de sólo lectura (ROM) y se copian en la memoria de acceso aleatorio (RAM) cuando se inicializa la NIC.


En la capa MAC de enlace de datos se agregan encabezados e información final a los datos de la capa superior. El encabezado y la información final contienen información de control destinada a la capa de enlace de datos en el sistema destino. Los datos de las entidades de las capas superiores se encapsulan dentro de la trama de la capa de enlace, entre el encabezado y el cierre, para luego ser enviada sobre la red.


Para mover datos entre una estación Ethernet y otra, a menudo, estos pasan a través de un repetidor. Todas las demás estaciones del mismo dominio de colisión ven el tráfico que pasa a través del repetidor. Un dominio de colisión es entonces un recurso compartido. Los problemas que se originan en una parte del dominio de colisión generalmente tienen impacto en todo el dominio. El tráfico que el repetidor recibe nunca se envía al puerto por el cual lo recibe.

La NIC utiliza la dirección MAC para evaluar si el mensaje se debe pasar o no a las capas superiores el modelo OSI. La NIC realiza esta evaluación sin utilizar tiempo de procesamiento de la CPU permitiendo mejores tiempos de comunicación en una red Ethernet.

En una red Ethernet, cuando un dispositivo envía datos, puede abrir una ruta de comunicación hacia el otro dispositivo utilizando la dirección MAC destino. El dispositivo origen adjunta un encabezado con la dirección MAC del destino y envía los datos a la red. A medida que estos datos viajan a través de los medios de red, la NIC de cada dispositivo de la red verifica si su dirección MAC coincide con la dirección destino física que transporta la trama de datos. Si no hay concordancia, la NIC descarta la trama de datos. Cuando los datos llegan al nodo destino, la NIC hace una copia y pasa la trama hacia las capas superiores del modelo OSI.

En una red Ethernet, todos los nodos deben examinar el encabezado MAC aunque los nodos que están comunicando estén lado a lado. Todos los dispositivos conectados a la LAN de Ethernet tienen interfaces con dirección MAC incluidas las estaciones de trabajo, impresoras, routers y switches.

El entramado es el proceso de encapsulamiento de la Capa 2 (una trama es la unidad de datos del protocolo de la Capa 2) y ayuda a obtener información esencial que, de otro modo, no se podría obtener solamente con las corrientes de bits codificadas: Entre los ejemplos de dicha información se incluye:

• Cuáles son los computadores que se comunican entre sí.
• Cuándo comienza y cuándo termina la comunicación entre computadores individuales.
• Proporciona un método para detectar los errores que se produjeron durante la comunicación.
• Quién tiene el turno para "hablar" en una "conversación" entre computadores.

Hay varios tipos distintos de tramas que se describen en diversos estándares. Una trama genérica tiene secciones denominadas campos, y cada campo está formado por bytes. Los nombres de los campos son los siguientes:

Nombres de Campos
A	B	C	D	E
Campo de inicio de trama	Campo de dirección de trama	Campo de tipo/longitud	Campo de datos	Campo FCS

Todas las tramas contienen información de denominación como, por ejemplo, el nombre del computador origen (dirección MAC) y el nombre del computador destino (dirección MAC), pero la mayoría de las tramas tienen algunos campos especializados.

La razón del envío de tramas es hacer que los datos de las capas superiores, especialmente los datos de aplicación del usuario, lleguen desde el origen hasta el destino.. El paquete de datos incluye el mensaje a ser enviado, o los datos de aplicación del usuario.Puede resultar necesario agregar bytes de relleno de modo que las tramas tengan una longitud mínima para los fines de temporización. Los bytes de control de enlace lógico (LLC) también se incluyen en el campo de datos de las tramas del estándar IEEE. La subcapa LLC toma los datos de protocolo de la red, un paquete IP, y agrega información de control para ayudar a entregar ese paquete IP al nodo de destino.

El campo de Secuencia de verificación de trama (FCS) contiene un número calculado por el nodo de origen en función de los datos de la trama. Entonces, esta FCS se agrega al final de la trama que se envía. Cuando el computador destino recibe la trama, se vuelve a calcular el número FCS y se compara con el número FCS que se incluye en la trama. Si los dos números son distintos, se da por sentado que se ha producido un error, se descarta la trama y se le puede pedir al origen que vuelva a realizar la transmisión.


Hay tres formas principales para calcular el número de Secuencia de verificación de trama:

• Verificación por redundancia cíclica (CRC): Realiza cálculos en los datos.
• Paridad bidimensional: Coloca a cada uno de los bytes en un arreglo bidimensional y realiza chequeos verticales y horizontales de redundancia sobre el mismo, creando así un byte extra, que resulta en un número par o impar de unos binarios. 
• Checksum (suma de verificación) de Internet: Agrega los valores de todos los bits de datos para obtener una suma.

Hender Orlando Puello Rincón

Creando un Nuevo Entorno

Etiquetas: Configuración, Symfony


Symfony 2 tiene tres entornos predeterminados los cuales son Desarrollo, Producción y Test; aparte de estos entornos, es posible crear mas entornos si es necesario.

Para crear el nuevo entorno se debe seguir los siguientes pasos:

1. Crear archivo de configuración.
2. Crear controlador frontal.
3. Acceder a "htp://localhost/app_nuevoEntorno.php"

• Crear el Archivo de Configuración

YML

# app/config/config_nuevoEntorno.yml

imports:
    - { resource: config_prod.yml }

framework:
    profiler: { only_exceptions: false }

XML

<!-- app/config/config_nuevoEntorno.xml -->

<imports>
    <import resource="config_prod.xml" />
</imports>

<framework:config>
    <framework:profiler only-exceptions="false" />
</framework:config>

PHP

// app/config/config_nuevoEntorno.php

$cargador->import(’config_prod.php’)
$contenedor->loadFromExtension(’framework’,
        array(
            ’profiler’ => array(’only-exceptions’ => false),
        )
    );

• Crear Controlador Frontal

<?php

require_once __DIR__.’/../app/bootstrap.php’;
require_once __DIR__.’/../app/AppKernel.php’;

use SymfonyComponentHttpFoundationRequest;

$kernel = new AppKernel(’nuevoEntorno’, false);
$kernel->handle(Request::createFromGlobals())->send();

?>

Hender Orlando Puello Rincón

Ciclo de Vida (Conceptos)

Etiquetas: Conceptos, Ingeniería de Software

“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software”

IEEE/EIA 1074 Standard for Developing Software Life Cycle Proccess (2006)

El Ciclo de Vida del Software define las etapas o fases de un proyecto de desarrollo de software para transformar la información de los usuarios en un producto que satisfaga sus necesidades. El Ciclo de  Vida es representado en modelos, llamados "Modelos del Ciclo de Vida" o "Modelo de Procesos", los cuales ordenan, coordinan y realimentan las etapas y las actividades (las actividades de cada etapa).

“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso”

ISO/IEC 12207 Information Technology / Software Life Cycle Processes (2008)

Todo ciclo de vida debe definir las actividades a realizar en cada etapa y en qué orden, asegurar la consistencia con el resto de los sistemas de información de la organización y proporcionar puntos de control para la gestión del proyecto (calendario y presupuesto), esto es con qué técnicas puede determinar los recursos a utilizar o las personas implicadas en cada actividad entre otras características.

Las etapas o fases del ciclo de vida que contienen los modelos son:

1. Análisis de Requisitos
2. Diseño
3. Codificación (Implementación)
4. Pruebas (unitarias y de integración)
5. Instalación y paso a producción
6. Mantenimiento

Las etapas nombradas anteriormente pueden cambiar su nombre según la normativa seguida para el desarrollo del software, en donde sin embargo las actividades planteadas para el desarrollo de cada etapa se mantienen.

N°	ISO/IEC 12207	IEEE/EIA 12207	IEEE/EIA 1074
1	Adquisición	Adquisición	Identificación o clasificación del Problema o modificación
2	Suministro	Suministro	Análisis
3	Desarrollo	Desarrollo	Diseño
4	Aceptación	Operación	Implementación
5	Explotación	Mantenimiento	Pruebas del Sistema
6	Mantenimiento		Pruebas de Aceptación
7			Liberación de Versión

La ISO/IEC 12207 define los procesos nombrados (los Proceso Principales), ocho Procesos de Soporte y cuatro Procesos de la Organización fuera de un proceso para la adaptación del ciclo de vida a un proyecto en concreto.Ver gráfico de dependencias de Wikipedia.


La IEEE/EIA 12207 define los cinco procesos llamados Procesos Principales, ocho Procesos de Soporte y cuatro Procesos Organizacionales.

Modelos de Ciclo de Vida

Cascada y Derivados

El Modelo de Ciclo de Vida Clásico o Cascada propuesto por Winston Royce en 1970 se caracteriza por seguir de manera lineal las etapas de desarrollo del software aislando cada fase siguiente de la anterior. Los documentos son entregados a la entrada y salida de cada fase como resultado de una o varias revisiones, así, cada fase puede ser desarrollada por equipos diferentes.

Modelo de Ciclo de Vida Clásico

Este modelo es fácil de planificar, el resultado es de una muy buena calidad y permite trabajar con personal poco cualificadas, sin embargo, el definir todos los requerimientos desde el principio, el no tener el producto sino hasta la entrega, no volver fácilmente a la fase anterior y el no tener indicadores fiables del progreso hacen que sea favorable para sistemas que realizaran altas, bajas y actualizaciones sobre un conjunto de datos.

El Modelo de Ciclo de Vida en V basado en el de Cascada, le agregó una subetapa de retroalimentación entre el análisis y el mantenimiento y otra entre el diseño y el debugging. El ciclo de vida diseñado por Alan Davis facilita la corrección y por tal razón es muy aconsejable su uso para desarrollo de software simple pero donde se necesita una confiabilidad muy alta.

Modelo de Ciclo de Vida en V

El Modelo de Ciclo de Vida Sashimi permite un solapamiento entre las fases disminuyendo la generación de la documentación, pero es mucho más dificil controlar el proyecto pues los puntos al final de cada fase no son referencia y si no existe una buena comunicación pueden surgir inconsistencias en el desarrollo.

Modelo de Ciclo de Vida Sashimi

El Modelo de Ciclo de Vida Cascada con Subproyectos divide el proyecto en subetapas para desarrollar en paralelo las diferentes etapas del modelo de ciclo de vida en Cascada. Suele usarse mucho cuando se cuenta con un plantel de programadores numerosos. Es útil por el numero de personas trabajando, pero puede detenerse el proyecto temporalmente por la dependencia entre las subetapas.

Modelo de Ciclo de Vida Cascada con Subproyectos

El Modelo de Ciclo de Vida Iterativo reduce el riesgo de malos entendidos en la etapa de requerimientos. Itera entre varios ciclos de vida en cascada y al final de cada iteración se entrega al cliente una versión del producto el cual evalúa y corrige o propone mejoras. Es ideal para realizar entregas rápidas sin que el proyecto este terminado, cuando los requerimientos no están claros.

Modelo de Ciclo de Vida Iterativo

El Modelo de Ciclo de Vida en Cascada Incremental o simplemente Incremental, resulta difícil de evaluar y de aplicar para sistemas que se van a integrar, además que requiere gestores experimentados y los errores son detectados tarde, sin embargo, involucra más al usuario en el desarrollo y evita proyectos largos entregando algo de valor (prototipos) con cierta frecuencia generando resultados muy positivos.

Modelo de Ciclo de Vida en Cascada Incremental

Prototipado y Derivados

Los Prototipos, derivados del Modelo de Ciclo de Vida por Prototipos, deben ser fáciles de construir y evaluar en la fase del desarrollo, ser baratos, desarrollarse en poco tiempo; es usado frecuentemente para desarrollar software cuando no se conoce exactamente el producto o las especificaciones, pues suaviza la transición entre los requerimientos iniciales y finales por esta misma razón resulta altamente costoso y dificil para la administración en el tiempo.

Modelo de Ciclo de Vida por Prototipos

Enunciado por James Martin, el Modelo de Ciclo de Vida Evolutivo, construye una implementación parcial que satisfaga los requisitos conocidos, para cual usa el usuario para comprender mejor la totalidad de requisitos que desea. Este modelo está fuertemente relacionado con RAD (Desarrollo rápido de Aplicaciones) y con técnicas de desarrollo que contemplen la reutilización; puede ser considerado la nueva versión de "Codificar y Arriglar".

Modelo de Ciclo de Vida Evolutivo

Diseñado por Boehm en el año 1988, el Modelo de Ciclo de Vida en Espiral, toma las bondades del modelo por prototipos e incremental pero dando más importancia al riesgo por incertidumbre e ignorancia de los requerimientos.

Modelo de Ciclo de Vida en Espiral

El modelo en espiral Plantea la Planificación (Requerimientos iniciales o luego de una iteración), el Análisis de Riesgo (Decide si continuar con el desarrollo), la Implementación (Desarrolla Prototipo), y la Evaluación (Por parte del Cliente), los cuales son actividades que envuelven a las etapas de desarrollo.

Orientado a Objetos

El Modelo de Ciclo de Vida Orientado a Objetos, plantea como objetos cada funcionalidad o requerimiento solicitado por el cliente, con sus propiedades o atributos y comportamientos o métodos. Abstrae los requerimientos del usuario favoreciendo la reducción de la complejidad del problema permitiendo el perfeccionamiento del producto. Por lo anterior este modelo es muy versátil y apropiado parapequeños y grandes proyectos.

Modelo de Ciclo de Vida Orientado a Objetos

Imágenes:  Red De Usuarios: Ciclo de Vida del Software.

Fuentes: Mundo Geek: Ciclos de Vida del Software, INTECO-Laboratorio Nacional de Calidad del Software: Ingnería del Software Metodologías y Ciclos de Vida, HananTek: Modelos del Ciclo e vida, Oposiciones TIC: El Ciclo de Vida de los Sistemas, Scribd: Subrayado ISO 12207, Wikipedia: ISO/IEC 12207, Wikipedia: IEEE/EIA 12207, Norma Técnica Peruana:Tecnología de la información Procesos del Ciclo de Vida, Calidad Software 15504:El modelo de Proceso ISO 12207:2008, Scribd: Planificación y Gestión de Sistemas de información. Estandar IEEE 1219 de Mantenimiento del Software, Ingeniería del Software: Modelos de Ciclo de Vida y niveles de Abstracción, Ingeniería de Software: Estándar IEEE 1074:1997, Red De Usuarios: Ciclo de Vida del Software, UNED: Guia para Análisis, Diseño y Mantenimiento del Software, Grupo ALARCOS: Ciclo de Vida del Software

Hender Orlando Puello Rincón - 0152916 Estudiante Ingeniería de Sistemas

Matriz Axiológica (Concepto)

Etiquetas: Gestión de TICS, Conceptos

La matriz axiológica es una representación de los principios y valores de los grupos de referencia de la organización que tiene como fin servir de guia para formular la escala de valores de la misma, y constituirse en un apoyo para diagnosticar a futuro.

Permite evidenciar el significado de los valores y principios corporativos para los diferentes grupos de referencia, ayuda y sirve de guía para la formulación de escala de valores y la verificación de los grupos de referencia.

Pasos

1. Establecer los principios y valores corporativos.
2. Identificar las personas o instituciones con las cuales interactúa la organización para la obtención de los objetivos.
3. Se elabora una matriz que identifique a que grupo de referencia se puede aplicar un determinado principio o valor corporativo.
4. Realizar la matriz axiológica explicando como se aplican o aplicarán los principios y valores en los grupos de referencia asociados.

Fuentes: Gerencia Estratégica de Mercadeo, Matriz Axiológica, Planeación Estratégia de Proyectos Informáticos, Propuesta de Direccionamiento Estratégico, 

Hender Orlando Puello Rincón - 0152916 Estudiante Ingeniería de Sistemas

Colegio Nuestra Señora de Fátima

Etiquetas: Gestión de TICS, Trabajos
El Colegio Nuestra Señora de Fátima de la ciudad de Cúcuta pertenece al Bienestar Social de la Policía Nacional.

Principios y Valores

Misión

Ofrecer un servicio educativo de alta calidad en los niveles de preescolar, básica y media, cimentado en una filosofía humanista, con el fin de contribuir al desarrollo personal, familiar y social de la comunidad policial.

Visión

Al año 2019, los colegios de la Policía Nacional serán reconocidos por su excelencia pedagógica y administrativa, que han contribuido al mejoramiento de la calidad de vida de la comunidad policial y de la sociedad. 

Fuentes: Direccionamiento Estratégico del Colegio nuestra Señora de Fátima de Cúcuta
Hender Orlando Puello Rincón - 0152916
Harbey Briceño - 0152454
Dario Omaña - 0152705

Visión (Conceptos)

Etiquetas: Conceptos, Gestión de TICS
La Visión es una imagen del futuro deseado; ¿Que es lo que realmente queremos? es la pregunta base que debe responder, otras preguntas como ¿Que tipo de organización queremos ser?, ¿En que tipo de negocios debe entrar la organización? apoyan a la elaboración de la visión o también llamada brújula de la organización. También es recomendable que contenga el alcance en cuanto al sector, el crecimiento, el reconocimiento efectivo y el porque ese reconocimiento.

La visión al elaborarse debe ser factible de alcanzar, motivadora e inspiradora, compartida por la mayoría, clara, sencilla, de fácil comunicación y potenciar las capacidades de la organización y la imagen de si misma.

Características

La visión debe:

• Ser formulada por los líderes de3 la organización.
• Contener una dimensión de tiempo. Esto es para poder ser evaluada o orientar el desarrollo de la organización.
• Ser integradora, amplia, detallada, positiva, alentadora, realista, posible, consistente.
• Difundirse al interior de la organización y al exterior de la misma.

Pasos

La visión puede elaborarse siguiendo los pasos a continuación

1. Declarar la Visión.
2. Comprensión del Impacto ambiental.
3. Definición de los clientes.
4. Seleccionar el(los) grupo(s) de productos. Impulsados por tecnología, Clientes, Competencia, Proveedores, Sustitutos, basados en las fortalezas de la empresa, etc.
5. Estimar el potencial de la empresa.
6. Identificar los valores agregados.
7. Seleccionar los productos principales y secundarios.
8. Determinar los proveedores potenciales y las fuentes necesarias para el éxito de los productos ofrecidos y su(s) valor(es) agregado(s).
9. Cuantificar los Criterios de éxito del(los) producto(s).

Fuentes: Gestiopolis: Visión, Trabajo: Misión de una empresa,  El Proceso de Visualización: Visión, Promonegocios: Misión y Visión, Web And Macros: Declaración de la Misión, Visión y Valores de nuestra Organización.
Hender Orlando Puello Rincón - 0152916 Estudiante Ingeniería de Sistemas

Misión (Concepto)

Etiquetas: Conceptos, Gestión de TICS
La misión es la razón de ser de la empresa, es decir la necesidad que satisfacemos. La misión debe corresponder con el propósito general de la organización que es con lo que logra la sostenibilidad o rentabilidad de la misma, debe plasmar lo que es la organización hoy en día y manifestar la cohesión alrededor de objetivos comunes lo cual facilita la resolución de conflictos y motivación del personal.

De que Consta

La misión consta de:

1. La descripción de lo que hace la empresa.
2. Para quien está dirigido el esfuerzo (mercado objetivo).
3. La Presentación de la particularidad o factor diferencial en el mercado.
4. Declararse de tal forma que facilite su uso para evaluarlas actividades de la empresa. Servir como marco.

Lo anterior solo es una guía para la construcción de la misión de una empresa.

A que Preguntas Responde

La misión debe respondes a las siguientes preguntas.

• Quienes Somos? La respuesta describe la Identidad de la empresa.
• Que Buscamos? Muestra el(los) propósito(s) generale(s) de la empresa.
• Porque lo Hacemos? Nombra valores, principios y motivaciones de la empresa.
• Para Quienes Trabajamos? Describe brevemente los clientes de la empresa.

Propósito

Un propósito debe explicar la condición o problema que se busca cambiar, identificar el o los clientes específicos y contener por lo menos un verbo que indique el cambio que generará el producto o servicio de la empresa.


Fuentes: Gestiopolis:Cómo redactar una misión, Trabajo: mision de una empresa, El Proceso de Visualización: Misión, Promonegocios: Misión y Visión, Web And Macros: Declaración de la Misión, Visión y Valores de nuestra Organización
Hender Orlando Puello Rincón - 0152916 Estudiante Ingeniería de Sistemas

Principios del Ingeniero Informático

Etiquetas: Ingeniería de Software

La versión corta del código resume las aspiraciones a un alto nivel de abstracción; las cláusulas que se incluyen en la versión completa proporcionan ejemplos y detalles acerca de cómo estas aspiraciones modifican nuestra manera de actuar como profesionales de la ingeniería de software. Sin las aspiraciones los detalles pueden convertirse en tediosos y legalistas; sin los detalles las aspiraciones pueden convertirse en altisonantes pero vacías; juntas, las aspiraciones y los detalles forman un código cohesivo. 

Los ingenieros de software deberán comprometerse a convertir el análisis, especificación, diseño, implementación, pruebas y mantenimiento de software en una profesión respetada y benéfica. De acuerdo a su compromiso con la salud, seguridad y bienestar social. 

• Sociedad: Los ingenieros del software actuarán de manera coherente con el interés general. 
• Cliente y empresario: Los ingenieros del software deberán actuar de tal modo que se sirvan los mejores intereses para sus clientes y empresarios, y consecuentemente con el interés general. 
• Producto: Los ingenieros del software deberán garantizar que sus productos y las modificaciones relacionadas con ellos cumplen los estándares profesionales de mayor nivel más que sea posible. Juicio: Los ingenieros del software deberán mantener integridad e independencia en su valoración profesional. 
• Gestión: Los gestores y líderes en ingeniería del software suscribirán y promoverán un enfoque ético a la gestión del desarrollo y el mantenimiento del software. 
• Profesión: Los ingenieros del software deberán progresar en la integridad y la reputación de la profesión, coherentemente con el interés general. 
• Compañeros: Los ingenieros del software serán justos y apoyarán a sus compañeros. Persona: Los ingenieros del software deberán participar en el prendizaje continuo de la práctica de su profesión y promoverán un enfoque ético en ella.

Tomado de el blog de una muy buena amiga.


Hender Orlando Puello Rincón

Herramientas

http://www.adelat.org/media/docum/herramientas20/
http://www.neoteo.com/las-20-herramientas-web-imprescindibles.neo
http://www.dreig.eu/caparazon/2008/03/23/entender-la-web-semantica-a-traves-de-las-nuevas-herramientas/
Hender Orlando Puello Rincón - 0152916 Estudiante Ingeniería de Sistemas