resumen TIC

Vista previa del material en texto

Las TICS en las organizaciones (Cap 7 tricocci)
· Las firmas han tenido un importante aumento de productividad y una aceleración de procesos de innovación. La “masiva” difusión y disponibilidad de la información y el conocimiento han contribuido al acortamiento de los ciclos de vida de productos.
· El impresionante crecimiento de las comunicaciones y su evolución ha permitido el aumento de negocios de tercerización en países alejados de las casas centrales o clientes.
· Las ganancias por productividad, a menos que sean resguardadas por nuevas técnicas pueden ser rápidamente igualadas por la competencia o “entrantes” a la industria.
· En mercado competitivo, el “punto de equilibrio” (donde se interceptan la oferta y la demanda) es el punto soñado. En un mercado de competencia perfecta se maximiza el excedente del consumidor y es por ello que es tan “beneficioso” para los consumidores. El precio del producto en este tipo de mercados en el largo plazo es el costo variable de producción, por eso no existe renta extraordinaria sino solo la retribución a los factores.
· En un oligopolio, el precio será superior al de la competencia, y la cantidad inferior a la de competencia. Hay una renta extraordinaria. El nuevo excedente del productor avanza sobre el excedente del consumidor en situación de competencia perfecta, reduciendo el excedente del consumidor.
· Si ese “poder” desaparece, los demás competidores o los nuevos entrantes pueden copiarlo, haciendo que se reduzca el excedente del producto devolviéndole al consumidor la porción de renta extraída. 
· La forma de mantener la renta extraordinaria en el tiempo es teniendo una “reserva de mercado” o siendo más innovador que los competidores.
· Lo que comenzó con una mejora del excedente del productor, con el correr del tiempo y por la incorporación de nueva tecnología por parte de los competidores, finalizó en los bolsillos de los consumidores. Un ejemplo serían los cajeros automáticos, que en un principio fueron novedad, pero que la mayoría comenzó a incorporarlo y en la actualidad ningún consumidor optaría por un banco que no provea este servicio; hoy se convirtió en un servicio básico. 
· La creación, difusión y uso del conocimiento permitir a las organizaciones tener una plataforma razonable para producir nuevos productos o nuevas tecnologías de producción, acceder a nuevos negocios, etc. Las verdaderas ventajas, se logran por el proceso de innovación en el cual las TICs juegan un papel necesario (pero no suficiente).
EJEMPLO:
1. Dos bancos estaban analizando las inversiones para proveer servicios de Home Banking y valoraron que les daba una ventaja diferencial que incrementaba sus ingresos.
2. Otros bancos que reaccionaron más tarde decidieron invertir en la provisión de servicios para no perder participación. Esta reacción competitiva, presiona sobre los precios de los servicios A LA BAJA.
3. Finalmente, los nuevos entrantes o los que estaban en el mercado y no tenían el servicio, tuvieron que invertir para poder continuar en el mercado (NUEVA PRESIÓN A LA BAJA).
4. Durante todo el proceso el precio asignable al servicio seguramente no dejo de caer hasta llegar a su costo marginal.
· La introducción de nuevos productos o servicios pueden hacerse en forma aislada, pero al generalizarse puede trasladarse a los procesos básicos de una industria haciendo desaparecer la ventaja. Es allí donde las TICs se convierten en un facilitador de la estrategia.
Inversiones en TICs y ventajas estratégicas:
· Se distingue entre tecnologías propietarias y tecnologías de infraestructura.
· La tecnología propietaria (ej una patente) genera una ventaja sobre la competencia y la misma se mantiene en la medida que no pueda ser replicada o se reemplace por otra innovación.
· La tecnología de la infraestructura (ej un tren o un teléfono), nace siendo propiedad de su creador, pero su verdadero valor está en compartirla.
· La única ventaja que puede tener una firma cuando la tecnología de infraestructura se consolida son ganancias por reducciones de costos (aunque es difícil de sostener).
Creación y uso del conocimiento organización en la Era Digital. La medición de los intangibles:
· En la era digital y del conocimiento, gran parte de la creación de riquezas de una firma está asociada a la generación y uso del conocimiento y a los procesos de innovación que le permiten crear, modificar, y adecuar productos y servicios en forma diferencial respecto de la competencia.
· El factor más relevante del proceso es la persona, quien además agrega todo su conocimiento tácito. Todo alimenta el proceso de innovación. Por ello el capital más valioso que tiene una firma son los intangibles, siendo más importantes que el capital financiero.
· En una firma tenemos un stock físico, pero también hay stock en capital humano y conocimiento de organizaciones que está relacionado con las personas y que aparecen como lo más importantes en medir y gestionar. 
· Debemos tener presente que este capital intangible requiere de mantenimiento de los talentos en términos que su capacidad de producir ganancias se mantenga, no se deprecie. En este caso la inversión tiene un componente de amortización más el incremento del capital de la nueva inversión.
· Hay tres aspectos clave que definen, o en mayor medida lo hacen, el éxito de un sistema y que conforman los pilares o ejes sobre los que se mueve todo proyecto: 
· Costos: es fundamental que los costos y recursos que serán necesarios para llevar adelante el proyecto estén correctamente estimados. Como sabemos, los recursos son escasos para las empresas. Si a mitad del proyecto los costos incrementan mucho más de lo esperado, es posible que el mismo no se pueda completar. 
· Tiempo: el tiempo es también un recurso y define la utilización del resto de los recursos de la empresa (recursos humanos, plata, etc.). La planificación detallada de las tareas del proyecto con su duración estimada lo mejor posible, considerando posibles retrasos, es fundamental para que luego no haya retrasos inesperados que pongan en riesgo el proyecto completo. 
· Alcance: el alcance representa todas las tareas que estarán involucradas en el proyecto. Es muy usual que durante el desarrollo de un proyecto surjan necesidades a cubrir que no se habían contemplado en el momento de la planificación y que representan más tiempos y recursos. 
· Mientras estas variaciones sean leves el proyecto podrá seguir su curso, pero es probable que ante una variación de alcance importante, el proyecto corra riesgos Cualquier modificación o variación que se evidencie en alguno de estos tres ejes, tiene impacto en las otras dos. Esto es lo que se llama triple restricción.
CAPITULO 5
Administración de las inversiones en TICs (cap 8 tricocci)
· los costos en TICs deben ser administrados rigurosamente. Una estrategia de neutralidad al riesgo tecnológico implica la aceptación de la dificultad de ser innovadores sólo con TICs.
· Los proveedores de las TICs están tratando de ser masivos con la tecnología haciendo caer sus precios. Esto permite la posibilidad de acceso de nuevos compradores.
· La posibilidad de acceso de otros a la tecnología hace que se acorten los períodos de recupero de las inversiones en TICs por parte de las firmas, dado que rápidamente los niveles de precios son más accesibles para todos.
Las inversiones en TICs como proyecto de inversión:
· El proceso o emprendimiento productivo financiero es la fuente de costos y beneficios. Los costos estarán referidos a los necesarios para la producción de bienes y servicios, objeto del emprendimiento.
· Los beneficios surgen de la valoración que las personas a las cuales van dirigidos los bienes dan a los mismos. El proyecto tiene una duración en el tiempo; cuando ese tiempo se cumple los “factores de producción” pueden tener un valor residual o no.
· Las organizaciones que formalizan proyectos determinan un ciclo de proyectos o un ciclo de vida de proyectos. Existen las siguientes etapas: formulación; evaluación; ejecución.
· Las etapasde formulación y evaluación forman parte de procesos decisorios complejos. Nos vamos a focalizar en la Evaluación y dentro de ella en la Evaluación Económica de Proyectos.
Evaluando económicamente proyectos de inversión:
· La evaluación económica de proyectos consiste en la medición y comparación de los costos y beneficios del proyecto con el objetivo de determinar la pertinencia de su ejecución respecto de los objetivos planteados y respecto de otros proyectos.
· El proceso de evaluación requiere de costos para su realización, además de disponibilidad de datos para poner realizarlo.
· La evaluación exante permite disminuir incertidumbre sobre la inversión a realizar y verificar que los beneficios netos futuros serán mayores que la inversión inicial y su retorno será mayor que otro proyecto alternativo.
· Los tipos de decisión que podemos evaluar pueden agruparse:
· Decisiones de nuevos negocios.
· Ampliación de los negocios existentes.
· Actualización de los existentes.
Evaluación costo-beneficio en proyectos de TICs:
· Una evaluación costo-beneficio requiere justamente que se reconozcan todos la totalidad de costos y beneficios atribuibles al proyecto que estamos evaluando.
· Para la determinación de costos se puede recurrir al conocimiento adquirido en proyectos anteriores donde se presupuestaron aspectos o temas similares y/o incluso re-utilizar metodologías anteriores.
· Si bien son los aspectos más controlables, se pueden presentar dos problemas:
· El primero se refiere a los costos de implementación: estos pueden ser subvaluados o minimizados. Se debe contar con adecuados planes de contingencia a los efectos de minimizar los impactos en la operación. También se encuentran situaciones de subestimación al considerar las estrategias de conversión (estas estrategias tienen diferentes relaciones de cambio entre costos y riesgos asociados).
Por ejemplo, la conversión de cambio directo tiene costos más bajos de conversión, pero puede presentar riesgo alto (o viceversa).
· Otra área de problema es el cálculo de costos de mantenimiento y soporte en el caos de nuevas tecnologías (donde no existe historia o es de difícil asimilación con alguna tecnología existente): puede apelarse al uso de datos de la industria teniendo en cuenta que los mismos están “sesgado” por las políticas comerciales de proveedores. 
Ejemplo, costos de re-entrenamiento del personal, los costos de mantener tecnologías alternativas, etc.
· Respecto a beneficios podemos clasificarlos por el grado de control que tiene la firma y la posibilidad de ser cuantificados. 
· Beneficios cuantificables controlables: se relacionan con beneficios que se producen por acciones que puede tomar la organización por sí y que tiene un buen grado de certeza. Ejemplo, cuantificación de la cantidad de personal que se eliminará por la implementación del proyecto.
· Beneficios cuantificables no controlables totalmente: son variables que en gran parte dependen de situaciones de contexto, por ejemplo: la competencia, el sector gobierno, clientes, etc.
· Beneficios de difícil cuantificación: categoría más crítica que la anterior. Ejemplo, mejoramiento de la posición competitiva.
Hacia una metodología integral. Los métodos TCO y TVO:
· El TCO (costo total de propiedad) es el método más usado para evaluar proyectos de las TICs, consiste en considerar la totalidad de los costos que plantea un proyecto durante su vida útil. El problema de este método es que no considera beneficios. Es un método simple y usado porque solo incluye aspectos controlables de las variables a considerar.
· El TVO (valor total de propiedad) tiene incluida la idea de considerar todos los costos y los beneficios.
· Una metodología integral debe tener por lo menos 4 pilares mínimos necesarios:
1. Las inversiones en TI deben ser formuladas como proyectos de inversión.
2. Una buena metodología de análisis de costo-beneficio.
3. Un proceso de planeamiento de negocios que comprenda las decisiones de inversión en TI asociadas o como parte de negocios.
4. Adecuación de la estructura organizativa de TI y de las Unidades de Negocios y del sistema de incentivos y compensaciones.
· Elementos de una buena metodología de costo-beneficio:
· Deben considerarse la totalidad de los costos incrementales que se van a requerir y los beneficios incrementales que se producirán por la puesta en práctica de las inversiones. 
· Hay varios componentes que son sub-estimados en las evaluaciones de impactos:
a) Riesgo tecnológico: debemos contar con una matriz de riesgos y alternativas de solución. Y se deben prever los planes de contingencia.
b) Costos de transición: no solo deben considerarse los mayores costos de esta etapa, sino los que se pueden producir por problemas en la operación habitual.
c) Nivel de complejidad e integración: las nuevas decisiones de inversión pueden hacer más completa la estructura vigente de sistemas y producir nuevos costos que no surgen a primera vista. A medida que se eleva el nivel de complejidad, crecen los costos totales y cuando se evalúan los proyectos se pueden tender a subestimar los mismos.
d) Impacto de la flexibilidad: las decisiones de nuevas inversiones pueden resolver soluciones de hoy pero producir problemas en desarrollos futuros. Deben proyectarse escenario a futuro.
e) Aspectos comerciales: las decisiones que implican la elección de proveedores requieren de un análisis de los mismos, ya que nuestros activos estarán asociados a ellos.
· Tanto los costos como beneficios deben ser clasificados en distintas categorías.
· Proceso de planeamiento de negocios. Decidiendo sobre los no cuantificables:
· Es necesario que el CIO trabaje conjuntamente con los demás directores o gerentes de la organización para definir un plan de sistemas del cual surgen decisiones de inversión en TI.
· La priorización de estas inversiones debe estar soportada por los resultados de la evaluación de proyectos realizada por la metodología de costo-beneficio.
· Adecuaciones de la estructura organizativa de TI y de las Unidades de Negocios:
· La implementación de una metodología de TVO requiere de un adecuado proceso de toma de decisiones dentro de un esquema organizativo acorde y un sistema incentivo de las personas claves.
· Se trata de asegurar que lo decidido en la etapa de planeamiento se lleve adelante y se logren los objetivos o beneficios acordados.
· Los responsables de negocio deben preocuparse por como se están desarrollando los proyectos de aplicaciones y tratar que los mismos tengan el apoyo necesario para cumplir los objetivos.
· En la fase de formulación de los planes y las decisiones de inversión, las áreas de los negocios deben involucrarse en la definición de los beneficios.
· No basta con que el CIO se preocupe sólo por el cumplimiento del presupuesto y los tiempos, sino también debe tener con factor de éxito que producto/proyecto genere el valor esperado. Esta generación de valor es compartida con el responsable de los negocios y por lo tanto debe crearse un mecanismo organizativo y de incentivos.
· Con estas modificaciones propuestas se pretende lograr que el CIO y los gerentes de las unidades de negocio, formen una “comunidad”. Esa comunidad estará reflejada en los incentivos económicos que reciben por el cumplimiento de los resultados.
¿Retener o tercerizar funciones? Ese no es el dilema:
· Algunas alternativas para tercerizar actividades:
· Si una meta o proceso se puede expresar en reglas lógicas (procedimiento), pueden ser volcado a una computadora o puede ser explicado a otra persona con bajas probabilidades que sea mal entendido. Procesos con esta característica pueden ser realizados en forma eficiente y eficaz por otros.
· Pero también se han promovido trabajos de más alta habilidad (ej trabajos de ingeniería) los cuales combinan cierto análisis tácito con datos, componentes de reglas y estandarización de procesos.
· En ambos casos deben existir procedimientos de gestión que aseguren el logro de los resultados requeridos. La tercerización implica la administración dela función delegada.
· En el caso que el nivel de eficiencia y la valoración de la actividad son bajos, es conveniente tercerizar. Allí la eficiencia del tercero permite seguramente reducir costo y la realización de la actividad en forma externa no le agrega valor a la firma.
· El caso totalmente opuesto se encuentra cuando el nivel es alto; en este caso el desarrollo con los recursos propios que conocen mejor el negocio y la estrategia de la firma permitirá obtener el máximo valor posible.
El rol del CIO:
· El logro de decisiones conjuntas con las áreas de negocios requiere de superar aspectos organizacionales como la dependencia del CIO. Esta dependencia debe ser equivalente a las que poseen los gerentes de negocios, es decir del máximo nivel de la organización. 
· La dependencia es una muestra de cual es el nivel o importancia que la organización le asigna a la TI y a los Sistemas y de allí la importancia de superación del proceso de reconocimiento de potencialidad de la TI.
· La dependencia del máximo nivel es condición necesaria pero no suficiente. Allí aparecen la necesidad de nuevos roles del CIO, una metodología de la toma conjunta de decisiones con las áreas de negocio y un esquema de incentivos adecuados.
· Se plantean 3 estadíos evolutivos del nivel de complejidad en la cultura de las TICs:
· Estadío 1: generación de registros.
· Estadío 2: análisis de la información.
· Estadío 3: trabajo cooperativo y el desarrollo innovador.
· En el estadio inicial las firmas están focalizadas en resolver los problemas de coyuntura, el foco está puesto en las operaciones y procesos del día a día. Lo importante es captar y registrar los hechos que suceden y dar algun tipo de información agregada de los mismos.
· El foco está puesto en la solución de los problemas, referidos a las actividades tradicionales de TI/SI. El CIO está absorbido por el crecimiento de nuevos sistemas, por la optimización de procesos y de los tiempos, la disponibilidad de las aplicaciones y todo ello con un presupuesto restringido. 
· Tiene una relación con el CEO y se maneja la relación por reportes. La escena está dominada por la continua reducción de costos y la preocupación por mantener los sistemas funcionando.
· En el estadio 2, la situación de la operación normal y habitual está estabilizada. Se orientan a mejorar los procesos de negocio. El objetivo es la eficiencia y la productividad. 
· Las funciones de operación ahora son realizadas correctamente y el foco está en la productividad y calidad. Se produce un alineamiento TI/SI con el negocio (pero aun no la tiene incorporada a su estructura de decisiones estratégicas).
· En el estadio 3, la TI/SI forma parte de los foros de innovación a través de la tecnología, es el motor de transformación de la firma. El CIO, las unidades de negocios y el CEO tienen una interacción natural en el plano de decisiones estratégicas. La TI/SI debe alinearse con la definición estratégica del negocio.
 
¿Como mejorar la relación entre las áreas de negocio y la de TI?:
· Las presiones del entorno hacen que los gerentes de negocios deban conocer con mayor profundidad las necesidades de sus clientes. Las TI pueden ser un buen vehículo entre las firmas y los consumidores.
· Este nuevo rol del CIO requiere un salto a una nueva visión de las necesidades y manera de pensar más innovadoras y que sea vista y sirva de ayuda a las áreas de negocios.
· Esta nueva necesidad implica revisar el proceso de reclutamiento y/o capacitación de los CIOs. Otra forma de mejorar las relaciones y conocimiento de las áreas de negocios y TI es pensar en rotaciones: ejecutivos de negocios trabajando en áreas de TI y viceversa.
Decisiones de compra de software (cap. 9 Tricocci)
· una práctica difundida la última década ha sido la adquisición de productos y servicios de TICs y especialmente los referidos a la compra de software para cumplir necesidades empresariales.
· El proceso que adopta el comprador debe permitir determinar las verdaderas capacidades, fortalezas y debilidades del grupo de productos que se evalúan y como las prestaciones de los productos satisfacen los requerimientos empresariales.
El mercado de TICs y las firmas:
· El mercado de bienes y servicios TICs ha crecido muy fuerte y el segmento referido a software muestra la tasa anual de crecimiento mayor.
· La grane expansión está influenciada por fusiones y adquisiciones que hacen que los oferentes “presionen” a la demanda con intensas campañas comerciales.
· Las empresas de menor tamaño, que tienen generalmente una cultura de TI menos desarrollada y tienden a incluir pocos factores en sus decisiones, suelen ser muy influenciadas por los proveedores de productos.
· Esta menor cantidad de personal dedicado a TI, en muchos casos hace que puedan dedicar menor tiempo al conocimiento de las alternativas disponibles y que sus demandas de productos responden más a las políticas comerciales de sus proveedores.
· Las empresas de mayor tamaño tienen proceso de “gobierno” en sus decisiones más autónomo de las influencias de los mercados, surgiendo generalmente de procesos de planificación más integrados, alineados a los negocios y/o respondiendo a política globales de sus casas matrices.
La decisión de compra como una comparación entre dos modelos:
· El proceso de selección y evaluación de software puede ser asimilado a la búsqueda de la mayor área de intercepción entre dos modelos:
· El modelo objetivo (pretendido por la firma): incluye un modelo de negocios con su esquema funcional, dentro de un contexto tecnológico existente, bajo ciertas características comerciales y económicas.
· El modelo de la oferta: proviene de la elección entre todos los modelos de la oferta elegibles. Deben ser interpretados y comparado con el modelo objetivo. En general estos responden a un modelo de negocios y procesos representativo de las generalidades de la industria.
· Las empresas proveedoras de software deben definir si diseñan productos generalistas u orientados. Debe resolver un trade off (relación de cambio) entre tener una demanda más amplia, pero con más sustitutos cercanos y una demanda más focalizada con menos competencia.
· En el primer caso desarrollan sus productos tratando de abarcar la mayor cantidad de funcionalidades y de la forma más generalista. Tratan de que su modelo comprenda a la mayor cantidad de requerimiento de los modelos objetivos posibles, luego de un proceso de adecuación.
· En el segundo caso, se diseña un producto más ajustado a situaciones particulares que requiere un menor proceso de adecuación al cliente y que tendrá un mercado más reducido.
· El proceso de selección es la determinación de los modelos de la oferta que mejor ajusta al modelo objetivo y la determinación de cuáles son las diferencias.
· Podemos encontrar 3 alternativas para lograr una convergencia total:
1. Adecuar el modelo de la oferta seleccionando para que ajuste al 100% al modelo objetivo. (es un modelo casi imposible de cumplir).
2. Modificar los procesos en la organización a las funcionalidades del modelo de la oferta elegido. Se modifica el modelo objetivo para “acercarlo” al modelo de la oferta. Implica que una cantidad de funcionalidades que son deseadas no se cumplirán o lo harán de una manera diferente.
3. Se aceptan las diferencias entre modelo objetivo y modelo de la oferta. Se resuelven las diferencias por “afuera” del sistema.
· En resumen, casi siempre deberemos decidir sobre las diferencias y la nueva decisión debe ser funcional, técnica y operativamente racional.
Ciclo de vida de los sistemas y el proceso de evaluación-selección de productos y proveedores de software:
· El proceso de evaluación y selección de software debe ser parte de una metodología de ciclo de vida del desarrollo de sistemas. Las etapas 1, 2 y 3 forman parte del proceso de evaluación y selección.
· En la etapa 1 se definen los requerimientos y se debe dar forma final a la matriz de evaluación y selección. Estos requerimientos son funcionales, tecnológicos, económicos y comerciales. Todos enconjunto definen el modelo objetivo.
· En la etapa 2 se realiza la pre-selección para focalizarse en los modelos de la oferta que cubren en mejor medida nuestros requerimientos. Se recolecta la información de proveedores y productos.
· En la etapa 3, es la selección final de la mejor alternativa. Las opciones preseleccionadas son analizadas con mayor detalle, se requieren presentaciones adicionales y se evalúan con un método de costo-beneficio.
· Una enumeración de las actividades de las 3 etapas puede ser:
a) Identificación y especificación de las necesidades.
b) Análisis de los requerimientos y búsqueda de alternativas.
c) Identificación de los posibles proveedores.
d) Evaluar alternativas.
e) Analizar disponibilidad presupuestaria.
f) Evaluar alternativas definitivas con un enfoque costo-beneficio.
g) Negociar.
h) Adquirir.
Dificultades posibles en el proceso de Evaluación y selección de software:
· Dificultad en obtener datos y objetivos sobre las funcionalidades.
· El proceso, desarrollado con profesionalidad, requiere una gran cantidad de tiempo y suele ser visto como tiempo “perdido”.
· La dedicación de los miembros del grupo del proyecto.
· La inexistencia de una metodología de ciclo de vida en la firma.
· La inexistencia de criterios generales de decisión o definidos a niveles pocos apropiados.
· Impacto de la inadecuada información en esa etapa.
Esquema de factores y grados. Matriz de prioridades:
· La matriz de prioridades y requerimientos es una de las herramientas más usadas en los proyectos de selección de software. Es un esquema matricial de factores y grados que ayuda en la selección y evaluación de software. Cada una de las operaciones evaluadas será calificada en relación a la forma que cumplen con los requerimientos de la matriz.
· De las filas:
· Se definen características a evaluar. 
· Cada característica tiene una ponderación. Cada ítem debe tener valores entre 0 y 1, y la suma de todos dará 1.
· Cada característica está formada por un conjunto de variables. Cada variable debe tener una ponderación entre 0 y 1, representando su peso dentro de la característica referida.
· De las columnas:
· Cada columna representa a una opción de mercado de los productos que se están evaluando.
· La intersección de variables y opción debe ser valorada con el esquema de grado definido. Este esquema debe decir en cuanto la opción de mercado cumple con la variable del modelo objetivo (10 es excelente y 1 muy pobre).
· Este mecanismo de cuantificación y comparación matemática tiene un proceso de preparación, instrucción y nivelación del personal que compone al grupo en esta etapa.
· La aplicación de la matemática, multiplicar en cada opción la ponderación por la valoración y sumarla los resultados de los distintos factores, permite obtener un valor final de cada opción para compararla u ordenarla de mayor puntaje a menor.
· En cada proyecto se deberán definir las variables a partir de la fijación de los requerimientos en la etapa de análisis de sistema.
· La ponderación debe contener las funcionalidades requeridas.
· Las variables con mayor grado de ponderación irán de beneficios altos a bajos.
· Es interesante definir si los que van a evaluar software, deben conocer o no las ponderaciones. Es conveniente que sean desconocidas por los evaluadores del software, de forma tal que no se sientan influenciados por las mismas. Luego, las ponderaciones las realizan los responsables de proyectos y puede realizarse una nueva vuelta con los evaluadores.
Como tratar la valoración de los grados:
· Los grados deben ser lo suficientemente amplios con el objetivo de eliminar zonas grises. Cada uno debe tener una definición clara de su valor para eliminar dudas en los evaluadores.
· Si los proyectos son de alto impacto, es conveniente que las opciones sean evaluadas por más de una persona, que todas realicen sus set de calificaciones y que éstas sean un promedio de todas.
· Otra alternativa, es formar un panel de evaluadores donde hay un evaluador principal y un secundario, por cada característica, y una tercera calificación con el resto del grupo como una sola nota.
· En este caso se obtiene tres calificaciones para cada variable, con un peso relativo importante de los “especialistas”.
Ciclos de vida y modelos de desarrollo (cap 11 Briano)
Interrelación entre ciclo de vida, modelos de desarrollo y metodologías de análisis de diseños:
· La aplicación de diferentes tecnologías concurre en la incorporación y puesta en marcha de sistemas de información y comunicaciones. Las principales son:
1) Tecnologías de modelos de desarrollo.
2) Tecnologías de gestión de proyectos para el control del proceso de selección, desarrollo, incorporación y operación de los sistemas.
3) Tecnologías de análisis y diseño de software.
· Cuando nos referimos a “ciclo de vida de una aplicación” estamos incluyendo las diferentes etapas por las que pasa esa aplicación durante su vida.
· En tal sentido podemos conceptualizar en términos generales las siguientes etapas:
1) Definición.
2) Incorporación.
3) Operación o utilización.
4) Abandono.
1) Definición:
· La fase de definición incluye el establecimiento de la visión externa del sistema, sus límites y alcances, la estimación del costo y esfuerzo requerido y la decisión de incorporarlo. Esta etapa, es parte integrante de la priorización para el armado del plan de proyectos.
· Esta tarea es la de mayor impacto en el ciclo de vida y en el costo del sistema. En función de la correcta ejecución de esta tarea se podrán:
a) Identificar las necesidades del usuario.
b) Determinar el alcance del proyecto, enunciando sus funciones y limites, dejando así claro, también, lo no alcanzado.
c) Identificar alternativas de realización.
d) Realizar el calculo de costo-beneficio y el plan global de trabajo de alternativas de solución, incluyendo tanto el desarrollo del proyecto como de la operación posterior.
· Una definición errónea puede llevar a:
· Priorizar un proyecto cuando no corresponde priorizarlo.
· No priorizar un proyecto cuando corresponde priorizarlo
· Dar un alcance excesivo, cuyo cumplimiento trae aparejado un costo que no agrega valor.
· Dar un alcance insuficiente, no cubriendo las necesidades o incurriendo, a posteriori, en mayores costos para cumplirlas.
2) Incorporación:
- La incorporación incluye todas las actividades necesarias para su adquisición y/o construcción y puesta en marcha.
- Esta etapa del ciclo de vida es concomitante con el desarrollo del proyecto y, se encuentra relacionado con el enfoque de ciclo de vida y la metodología de desarrollo que se emplee, la incorporación incluye las siguientes fases o etapas secuenciales:
a) Organización y planeamiento
b) Ejecución y control (análisis y control, adquisición, construcción y prueba y puesta en marcha)
c) Finalización.
- Las metodologías de desarrollo de sistemas atienden cuestiones y artefactos específicos para el desarrollo de sistemas, independientemente de las cuestiones de control de proyectos. Durante la realización del proyecto se deben atender ambas cuestiones (gestión de proyecto y metodología de desarrollo), las que se complementan.
- La puesta en marcha incluye:
a) Entrenamiento a usuarios.
b) Conversión y/o vuelco de datos.
c) Instalación de hardware y relacionados.
d) Prueba operativa, seguimiento y ajustes.
e) Operación inicial del sistema.
- Con la implantación se corona la tarea de desarrollo, verificándose la correcta interpretaciones de los requerimientos del usuario y el buen desarrollo de las tareas posteriores.
3) Operación o utilización:
- La utilización corresponde a la vida útil del sistema, durante la cual estará sometido a mantenimiento, es decir, ampliaciones y correcciones. El mantenimiento, en particular cuando requiere aplicación de significativa cantidad de recursos, debe tratarse como un proyecto en si mismo.
- Durante la etapa de operación del sistema una de las actividades distintivas es la de resolver la continuidad o el abandono.
- Podemos considerar que la continuidad se desaconsejapor los siguientes motivos:
a) Alto costo de mantenimiento que justifica su rediseño.
b) Limitaciones de funcionalidad que impiden realizar las ampliaciones correspondientes, que aconsejan su reemplazo.
c) Funcionalidades cubiertas por otras aplicaciones o falta de necesidad de seguir operando el sistema, por haber dejado de aportar funcionalidades necesarias.
4) Abandono:
- El sistema es dejado de lado, siendo o no reemplazadas sus funcionalidades por otro. En caso de reemplazo, las actividades de transición correspondientes al abandono se deben considerar en el plan del nuevo proyecto.
Modelos de desarrollo:
· Podemos considerar como modelos básicos, de los cuales se desprenden múltiples variantes intermedias y complementarias, los siguientes: por etapas, en cascada, en espiral, incrementales, ágiles.
· Por etapas (stagewise):
· Este modelo considera que las actividades se secuencian una tras la otra, es decir, no comienza la siguiente si no finalizo la anterior. 
· En este enfoque resulta sumamente fácil conceptualizar que tareas atender en cada etapa. La mayor debilidad de este enfoque reside en que como solo se puede ver el sistema cuando se completa el desarrollo, bien sea durante la capacitación como durante la puesta en marcha, recién en esas etapas avanzadas resulta posible detectar la necesidad de realizar una considerable cantidad de modificaciones y ampliaciones sobre lo ya construido para que el sistema cumpla sus fines.
· Es de considerar que a mayor duración del desarrollo resulta mayor el riesgo de necesidad de realizar el “mantenimiento previo a la operación”.
· Esa necesidad de “mantenimiento previo a la operación” puede tener su origen en:
a) Cambios en el contexto.
b) Errores en la definición no detectados hasta ese momento.
c) Errores en la construcción sobre una correcta definición.
- La detección tardía de necesidades de modificación provoca un significativo aumento de costos y una demora en la implementación.
- Asimismo, si el nuevo sistema reemplaza a otro utilizado hasta ese momento durante el plazo de desarrollo, seguramente se deberán realizar tareas de mantenimiento del sistema anterior, duplicándose los costos.
· En cascada (waterfall):
· Con el objetivo de evitar llegar al final del desarrollo sin tener una visión tal del sistema que pueda facilitar la detección en forma temprana de errores, se propone la retroalimentación en cada etapa con una fuerte participación de los usuarios e introducir la utilización de técnicas de simulación temprana del producto a lograr para que el usuario pueda percibir el producto final y, así, determinarse ajustes antes de realizar el desarrollo. Se destaca la necesidad de separar la visión externa del sistema, completando su diseño, de la construcción del mismo.
· Modelo evolutivo o “en espiral”:
· El modelo espiral se basa en la idea de trabajar en una serie de versiones progresivas que agregan una mejora a la anterior, graficadas en cada ciclo de la espiral.
· El modelo se divide en cuatro cuadrantes por un eje vertical, que representa el costo acumulado del proyecto; y un eje horizontal, que representa el creciente nivel de compromiso del usuario y los desarrolladores con la solución alcanzada.
· Las cuatro actividades principales del modelo son representadas en cada uno de los cuatro cuadrantes.
a) Planificación de actividades para la siguiente fase.
b) Determinación de objetivos, alternativas y restricciones.
c) Análisis de alternativas, identificar y resolver riesgos.
d) Desarrollo que, en los primeros ciclos, puede ser el desarrollo de modelos de papel y ciclos subsiguientes, el desarrollo de un prototipo de sistema o de una versión parcial.
- De esta forma un proyecto puede dividirse en diferentes proyectos que se ejecuten en forma paralela (todos ellos a la vez, ejecutados por distintos grupos cuyo producto se integra simultáneamente) o secuencial (proyectos que se desarrollan siguiendo el modelo en espiral, seguidos por otros que son iniciados luego de la finalización del anterior).
· Modelos incrementales impulsados por un producto utilizable:
· Para reducir el riesgo de necesidad de modificaciones previas a la implementación, las metodologías incrementales plantean dividir el sistema en sub-sistemas o módulos mas pequeños definidos estrictamente para ser puestos en marcha independientemente, y cubrir objetivos de negocio.
· En cierta forma puede conceptualizarse como una estrategia de implementación en la cual se concibe el producto final en su conjunto y su desarrolla se secciona, utilizando para su construcción alguno de los modelos vistos. De esta forma los beneficios de utilizar el sistema se obtienen (si bien parcialmente) en etapas tempranas, reduciéndose, asimismo, el riesgo de abandono o cambio significativo sin obtención de beneficios algunos.
· La definición de módulos debe contemplar:
a) El establecimiento de límites y alcances en función de alcanzar resultados específicos de negocios.
b) Su implementación en un plazo breve, ideal tres meses o menos.
c) Los indicadores necesarios para evaluar su cumplimiento.
d) Todas las acciones necesarias para producir los resultados deseados, no solo la implementación del software, sino también los cambios complementarios en políticas, estructuras y procesos.
- La ventaja que presenta la implementación superpuesta es la posibilidad de reducir el tiempo de implementación. Esto a riesgo de aumentar la posibilidad de tener que implementar ajustes en módulos ya avanzados en función de la experiencia de implementación.
- El enfoque escalonado garantiza que antes del inicio de las actividades de cada módulo se recoja la experiencia de la implementación de los anteriores.
- Con relación al enfoque del ciclo de vida el enfoque incremental permite disponer de las ventajas originadas en la utilización del nuevo sistema en forma más temprana. 
- Esto provoca, si el nuevo sistema reemplaza a uno anterior, el abandono de todo o parte del sistema anterior, eliminando la necesidad de mantenimiento de la porción abandonada.
- La implementación de múltiples módulos habitualmente requiere un mayor esfuerzo en la generación de interfaces que la implementación del sistema todo.
· Modelos ágiles:
· Ante demoras en las implementaciones, debido en gran medida a los “ajustes” de implementación y de cambios en los requerimientos durante el plazo de desarrollo, se genero, a fines del siglo pasado, una tendencia hacia procesos de desarrollo que buscaban una fuerte interacción con el usuario y cierta inmediatez en la implementación, englobados bajo la denominación de “métodos ágiles”.
· En líneas generales las metodologías ágiles proponen la realización de desarrollos cortos con alta participación del usuario, sin previa planificación de actividades más allá de una definición de alcances referencial y del tiempo, y son tendientes a una implementación inmediata.
Metodologías de Análisis y diseño (cap 12 Briano)
· Las metodologías son propuestas teóricas para llegar al objetivo de desarrollo de sistemas que incluyen los artefactos (básicamente procesos y herramientas) para llegar al objetivo de desarrollar la aplicación.
· Una metodología, para considerarse como tal, debe responder a una serie de principios dados y articular sus elementos en forma lógica, conformando un sistema de relaciones organizado según un cierto orden.
· Como objetivos últimos de las metodologías podemos mencionar:
a) Describir cómo hacer técnicamente para obtener el producto (proceso).
b) Servir como elemento de comunicación (herramientas de documentación).
· Este último elemento es fundamental tanto para el éxito del proceso de desarrollo, como para la operación (mantenimiento) posterior.
· El proceso de comunicación en el momento de desarrollo es de gran trascendencia para:
a) Lograr que el analista interprete las necesidades, acordando la tarea a realizar.
b) Lograr que los constructores interpreten las especificaciones, construyendo lo diseñado.
Prototipos como herramienta de comunicación:
· Los prototiposson representaciones del sistema en desarrollo para que el analista pueda representar su visión final a los ojos del usuario.
· Según su profundidad pueden limitarse a la visión externa del sistema o simular su comportamiento incluyendo alguna funcionalidad de la aplicación, simulando el ingreso de datos o incluyendo el encadenamiento de pantallas.
· Al presentar el prototipo al usuario se completa el círculo de comunicación, validando los requerimientos y facilitando los ajustes que se detecten.
· El uso de prototipos es una técnica que puede ser aplicada independientemente, tanto del ciclo de vida como de la metodología de desarrollo que se utilice, y puede extenderse a todo el sistema o solo a las funciones identificadas como críticas.
· Encontramos dos metodologías dominantes en la actualidad, la metodología de análisis y diseño estructurado, y la metodología de análisis y diseño orientado a objetos. A ellas se suman una serie de propuestas que toman en gran medida componentes de aquellas.
Metodologías de análisis y diseño estructurado
· Estas metodologías proponen la construcción de “un modelo lógico” del sistema mediante la descomposición gradual de los requerimientos del negocio, para llegar a funciones elementales, sobre las cuales se detallan las especificaciones para programación y se realizan los ajustes necesarios para la implementación física.
· El análisis se realiza desde dos visiones complementarias, la de los datos y la de los procesos: los procesos, específicos para el sistema tratado, interactúan con los datos. Los datos se encuentran disponibles tanto para estos procesos, como para otros que los requieran, en un entorno de integración de múltiples aplicaciones.
Visión desde los procesos:
· La visión de los procesos se realiza utilizando como herramienta el diagrama de flujo de datos (DFD).
· El DFD describe el sistema como una red de procesos conectados, mediante flujos de datos, entre ellos mismas, con agentes externos (usuarios u otras aplicaciones) y con almacenamientos de información.
Visión desde los datos:
· La visión desde los datos llega a la formulación de la estructura lógica de datos requerida para soportar los procesos del sistema, utilizando la técnica de normalización y graficando el resultante en el diagrama de entidad relación.
· La técnica de normalización parte por la identificación de todos los elementos de la base, analiza las relaciones subyacentes entre ellos y permite determinar la mejor forma de organizar los datos en tablas, en función de esas relaciones. Se basa en el estudio profundo de las relaciones subyacentes entre los elementos, a la luz de los requisitos del sistema objeto y la aplicación de principios de álgebra de relaciones.
· El proceso de normalización garantiza que la estructura de datos así determinada es la que mejor representa la realidad subyacente a los datos requeridos por el sistema. Como consecuencia también asegura que tanto el mantenimiento posterior como las ampliaciones y la integración con otros sistemas, que seguramente requerirían el agregado de nuevos datos y/o nuevas tablas con nuevos datos, no va a desnaturalizar la estructura lógica definida.
Metodologías orientadas a objetos: 
· A diferencia de los métodos estructurados, que separan datos de procesos, el enfoque de análisis y diseño orientado a objetos (ADDO) une datos y procesos en artefactos denominados “objetos”.
· Mientras que el enfoque tradicional (y el estructurado) se basa en el análisis de eventos y la determinación de su equivalente lógico, el enfoque OO requiere que esos eventos pertenezcan a un “objeto” identificable.
· Eso supone un avance en cuanto a la reutilización e integración aplicativa con relación a los métodos estructurados, donde los datos son compartidos mientras que los procesos son específicos de cada aplicación.
· Las actividades de desarrollo se centran en los objetos. El software se organiza a partir de los elementos que existen en el dominio del problema.
· La implementación física posterior dependerá de los lenguajes y bases de datos utilizados.
· En términos de ADDO un objeto es todo conjunto cohesionado, integrado por dos componentes esenciales:
a) Atributos (datos organizados).
b) Servicios (referentes lógicos de los procesos de transformación, operaciones, los cuales reciben y entregan información al exterior del objeto por medio de parámetros).
c) Métodos (forma en que se implementan los servicios).
- El armado conjunto de atributos, servicios y métodos se denomina “encapsulado”.
- El encapsulado provoca “ocultamiento de información”, haciendo visibles y accesibles los datos solo mediante los servicios implementados, así:
a) Protege los datos del uso arbitrario.
b) Oculta los detalles de la implantación interna a los usuarios de un objeto, por lo que los usuarios conocen los servicios que puede solicitar el objeto, pero desconocen los detalles de como se llevan a cabo.
c) Al separar el comportamiento del objeto de su implantación, permite la modificación de esta sin que se tengan que modificar las aplicaciones que lo utilizan, en la medida que se mantengan los servicios.
- Los distintos objetos se comunican por “mensajes”. Un mensaje solicita un servicio que ejecute el método apropiado y, en su caso, realice una modificación de datos y/o produzca una respuesta.
- Los objetos tienen las siguientes características:
· Clasificación: Una clase es un grupo de objetos que tiene atributos y comportamientos similares.
· Identidad o instanciación: Objetos con iguales atributos y servicios son distinguibles entre sí, debido a que tienen una característica distintiva de “identidad”.
· Jerarquía y herencia: Las clases se encuentran relacionadas jerárquicamente, y comparten atributos y servicios tomando como base esa relación jerárquica.
· Polimorfismo: Un mismo servicio puede comportarse de manera diferente en distintas instancias de una misma clase, por aplicación de un método diferente.
· Artefactos que resultan de mayor utilidad para la modelización del sistema objeto:
a) Estructurales: 
· Diagrama de clases: Muestran la relación entre clases de objetos.
b) De comportamiento e interacción:
· Diagrama de casos de uso:
· Herramientas de comunicación muy simple y efectiva, que puede utilizarse con cualquier metodología.
· Modelan el dialogo entre un actor y el sistema describiendo la funcionalidad que ofrece el sistema al actor.
· El conjunto de casos de uso del sistema constituyen todas las formas de uso definidas en el sistema.
· Documentan el comportamiento del sistema desde el punto de vista externo, detallando: funciones requeridas para el sistema, los actores y la interacción entre las funciones y los actores.
· Se constituyen en el medio principal para viabilizar el dialogo entre usuario y desarrollador acerca de las funcionalidades en relación al producto a entregar.
· Diagrama de actividades:
· Exponen las actividades de un caso de uso en la forma en que se van dando, incluyendo actividades paralelas y decisiones tomadas.
· Tiene una conformación similar al tradicional cursograma.
· Diagrama de secuencias:
· Muestran la relación entre las diferentes funciones detalladas en los casos de uso y los objetos y servicios que usan funciones requieren.
 Algunas consideraciones sobre la incorporación de sistemas del mercado (paquetes de software):
· Si bien la incorporación de sistemas del mercado no presenta la complejidad de un desarrollo de todas formas, es necesario comparar explícitamente la diferencia entre los requerimientos y las funciones disponibles.
· Si bien estos sistemas ofrecen una funcionalidad estándar flexibilizada en forma paramétrica (modificando ciertos valores en archivos del sistema que provocan que el mismo cambie su comportamiento) es habitual que no cumplan con todos los requerimientos funcionales y de integración con el resto de sistemas de la organización.
· Si fuera necesario cumplir con requerimientos no cubiertos por el paquete ya parametrizado, nos encontraríamos ante la necesidad de modificar el producto,construir agregados por afuera del producto o complementar el producto con tareas manuales.
· Por lo tanto, los requerimientos no cubiertos por el paquete pueden dar lugar a:
a) Incorporar el paquete, sin esos requerimientos.
b) Realizar adecuaciones y desarrollos complementarios para cumplir con esos requerimientos.
c) Alguna situación intermedia.
- La detección y explicitación de la brecha entre requerimientos y disponibilidades debe realizarse en forma temprana, antes de la adquisición misma del paquete, ya que la cobertura de ella puede generar costos tales que, de haberlos conocido anteriormente, podrían haber cambiado la decisión tomada, tanto hacia la adquisición de otro paquete como, incluso, un desarrollo a medida.
- Tanto las adecuaciones como la implementación del paquete en sí mismo, requiere un enfoque de ciclo de vida y metodológico
C4
Los sistemas de información son un activo intangible de las organizaciones:
· Deben producir los beneficios esperados por la organización.
· Sus costos de mantenimiento deben ser controlados y acordes a los beneficios obtenidos.
· La planificación de los mismos debe hacerse en el marco de la planificación de la estrategia de la organización.
Hay aspectos claves que definen el éxito de un sistema y que conforman los pilares o ejes sobre los que se mueve un proyecto:
· Costos: es fundamental que los costos y recursos que son necesarios para llevar adelante el proyecto estén bien estimados. Si a mitad de proyecto los costos incrementan más de lo esperado, es posible que el mismo no se pueda completar.
· Tiempo: la planificación de las tareas del proyecto con la duración estimada lo mejor posible, considerando posibles retrasos, es fundamental para que no haya retrasos inesperados que pongan en riesgo el proyecto completo.
· Alcance: el alcance representa todas las tareas que están involucradas en el proyecto. Es usual que durante el desarrollo del proyecto surjan necesidades a cubrir que no se habían contemplado cuando se planificó.
· Cualquier modificación o variación que se evidencia en alguno de estos tres ejes, tiene impacto en las otras dos. A esto se llama triple restricción.
· Los sistemas de información surgen como un proceso de resolución de problemas de la organización. Estos problemas pueden ser:
· Nuevas necesidades u oportunidades que no existían.
· Necesidades ya resueltas, pero de una manera que requiere de su revisión.
· La introducción de nuevo sistema de información implica más que hardware y software nuevos, requiere:
· El compromiso de la alta gerencia.
· Una clara comunicación a todos los afectados.
· La planificación detallada del mismo y su consecuente seguimiento.
Ciclo de vida:
· Cualquier proyecto se implementación requiere una serie de etapas básicas. A ese conjunto de etapas se lo llama ciclo de vida.
· Por un lado, podemos hablar del ciclo de vida de los proyectos. Desde esa perspectiva se analizan los pasos que deben cumplirse a la hora de definir un nuevo proyecto o modificar algunos sistemas existentes.
· Es importante entender que las tareas no terminan una vez que tenemos el sistema funcionando, sino que se debe seguir gestionando recursos y acciones durante la utilización, incluso a la hora de abandonar el sistema deberá planificarse la forma de hacerlo para evitar impactos negativos en el negocio.
· Podemos hablar de un ciclo de vida del desarrollo de un sistema, es decir, los pasos necesarios para construirlo y que funcione.
· Comprender cada una de estas etapas permite poder realizar una mejor planificación del proyecto o evaluar propuestas presentadas por los proveedores, conociendo diferentes roles que deben estar involucrados, así como los productos que se deben entregar en cada etapa.
· Análisis de requerimientos:
· Los requerimientos especifican qué es lo que el sistema debe hacer (funciones) y las propiedades esenciales y deseables. La captura de los requerimientos tiene objetivo principal la comprensión de lo que los clientes y usuarios esperan que haga un sistema.
· Ya sea que se decida comprar un software “enlatado” o desarrollar uno a medida, el primer paso es definir en detalle cuáles son las características que el sistema deberá tener para cubrir necesidades planteadas.
· Uno de los principales participantes en esta etapa es el analista funcional quien cumple el rol de mediador entre las áreas de negocio y las técnicas. Es el encargado de relevar e interpretar las necesidades de la organización y de documentarlas para que puedan ser utilizadas para diseñar y construir un sistema correctamente.
· El analista debe considerar las necesidades de las personas relacionadas con el sistema: usuarios finales y sus jefes o supervisores, áreas que utilizarán la información, áreas técnicas, etc.
· Todas esas personas que tienen intereses y pueden influir en la creación o uso del nuevo sistema, son llamadas stakeholders. 
· Como no es viable que el analista revise todos los conceptos con cada una de estas personas, se seleccionan personas referentes llamados usuarios claves. Además de ser los principales conocedores del negocio, van a ser los encargados de verificar que los requerimientos sean correctos y completos, y una vez desarrollado el sistema son los responsables de validar que se cumpla con lo requerido.
· Para definir los requerimientos del sistema, el analista realiza entrevistas con los usuarios clave y otros involucrados, en los cuales busca comprender el contexto de la organización y las necesidades propias de cada área.
· Para facilitar la comunicación de las ideas, el analista se vale de diferentes herramientas para el modelado y representación de distintos aspectos del sistema. Por ejemplo, el diagrama de entidad-relación, diagrama de flujo de datos, bocetos de pantallas, etc.
· Finalmente, el analista construye un documento llamado “especificación de requerimientos” en el cual se vuelca toda la información recolectada y modelos definidos.
· Esta etapa es importante ya que:
· Es la base para el diseño y desarrollo del software. Las características que no se incluyan en esta etapa no serán contempladas por el sistema, o bien, implicarán cambios posteriores que tendrán impacto en los tiempos y costos después.
· El componente humano juega un papel importante. Esta etapa tiene un contenido muy alto de comunicación y es común que exista problemas de interpretación.
· Costos: un correcto análisis reduce la posibilidad de que surjan costos inesperados a lo largo del proceso de desarrollo e implementación del sistema.
· Desarrollo:
· Para poder encargar el desarrollo de una solución de sistemas de información, se necesitan recursos y no sólo nos referimos a tiempo y dinero, sino también a los conocimientos necesarios.
· No todas las organizaciones están capacitadas para desarrollar sus propias soluciones, por lo que entonces, en base a la capacidad que tengan y la estrategia que elijan, las organizaciones encararán el desarrollo de una solución de TICs de dos maneras distintas:
· Desarrollo in-house: implica llevar a cabo todo el trabajo desde adentro, utilizando recursos propios.
· Tercerizado: implica la contratación de una empresa especializada en el desarrollo del software.
· La elección de cómo encarar un desarrollo es estratégica ya que cada una de ellas tiene ventajas y desventajas.
· La organización no siempre va a estar dispuesta a asumir riesgos que implica el desarrollo in-house. Al tercerizar el desarrollo, aunque en algunos casos representa una inversión inicial mayor, la organización traslada los riesgos a la empresa a la cual le contrate los servicios correspondientes.
· Todo lo que se realice en el proceso de desarrollo de un sistema debe quedar documentado. La documentación del desarrollo es lo que va a permitir encarar las modificaciones y el re-inicio del ciclo exitosamente, pudiendo entender lo que ya se hizo y detectar dónde se encontraron las oportunidades y fortalezas del sistema.
Roles y ambientes:
· Hay distintos roles que existen y se presentan en el desarrollo de sistemas de información:· Analista funcional: es el que debe entender las necesidades del negocio y asegurarse de que la solución que se va a desarrollar se ajusta a esas necesidades. Cumple la función de mediador entre el usuario o cliente y quien codificará la solución. Va a “traducir” las necesidades para que puedan ser utilizadas para construir el sistema.
· Arquitecto: es el responsable que traducir los requisitos, tal como se define por el analista, es una solución técnica. Es el que va a diseñar el sistema antes de que sea desarrollado. Y cuando e desarrollo se ha iniciado, es responsabilidad del arquitecto realizar un seguimiento.
· Desarrollador: el desarrollo efectivo de una aplicación es hecha por los desarrolladores del equipo. Son quienes llevan las necesidades de negocio a la práctica en forma de código de sistemas.
· Centro de procesamiento de datos/operaciones: son los responsables por la información que se genera en el día a día de la operación de la empresa. Por lo tanto, son los únicos habilitados para acceder al ambiente en donde los usuarios finales operan.
· Usuario clave: es un usuario final que generalmente tiene mucha experiencia en la actividad de la empresa y es miembro del área que utilizará el futuro nuevo sistema. El usuario debe participar en varias etapas de cualquier proceso de desarrollo.
En las etapas de definición (análisis y diseño) su rol es fundamental ya que define y transmite las necesidades de negocio al analista funcional. Una vez pasada la etapa de definiciones, el rol del usuario será acompañar en el desarrollo por posibles consultas que puedan surgir y finalmente realizar las pruebas de aceptación para asegurarse que el sistema desarrollado cumpla con las necesidades del negocio que él mismo estableció.
· Así como existen roles, existen también ambientes en los que se trabaja para poder finalmente alcanzar el producto terminado. Hay tres ambientes:
· El ambiente de desarrollo: es el lugar donde se codificará el sistema. Es donde se traduce a código lo que diseñó el arquitecto y el analista funcional. El desarrollador es el único que puede acceder en este ambiente.
· El ambiente de pruebas: también es conocido como ambiente de calidad. Es un entorno donde se harán las pruebas integrales y de usuario, para detectar posibles errores y por último aprobar la solución final. Tienen acceso tanto el desarrollador como el analista funcional y el usuario clave.
· El ambiente de producción: es el entorno en donde se pondrá a disposición de los usuarios finales la solución desarrollada y aprobada. Es donde los usuarios finales van a realizar su operatoria diaria, y luego se podrán obtener los reportes correspondientes. En este ambiente se tiene acceso a la información real de la actividad de la empresa (es información sensible y en su mayoría confidencial que hay que cuidar).
· Pruebas:
· Una vez diseñado y desarrollado el sistema se deben hacer pruebas que asegure que el desarrollo satisface las necesidades del negocio. Existen distintos tipos de pruebas:
	Unitarias
	De sistemas
	De aceptación
	En el ambiente de desarrollo.
	En el ambiente de pruebas.
	En el ambiente de pruebas.
	Las realiza el desarrollador durante la construcción.
	Las realiza el desarrollador y el analista funcional.
	Las realiza el usuario clave.
	Se prueba el correcto funcionamiento de cada módulo del código para asegurar que cada uno funcione correctamente por separado.
	Buscan desafiar los requerimientos funcionales originales para encontrar errores.
	Son pruebas funcionales sobre el sistema completo y el objetivo es probar que satisfacen la necesidad del usuario.
Metodologías de desarrollo:
· Existen distintas metodologías para encarar el desarrollo. Las principales son:
· Por etapas: su objetivo es cumplir las etapas de forma secuencial.
· En cascada: su objetivo es reducir riesgos, incorporando prototipos y retroalimentación para no llegar al fin del desarrollo sin detectar posibles errores. 
· En espiral: es una evolución del modelo en cascada buscando. Cada nueva versión progresiva mejora la anterior, buscando reducir riesgos de modificaciones. Puede incluir el uso de prototipos e incorpora tareas paralelas y por módulos. 
· Incrementales: destaca la segmentación del sistema en sub-sistemas o módulos más pequeños que puedan ser puestos en marcha en forma independiente y que sean de utilidad para el negocio. 
· Ágiles: proponen la realización de desarrollos cortos con alta participación del usuario clave, poca planificación y con implementación inmediata.
Calidad del software:
· Todas las metodologías y herramientas tienen un único fin que es producir software de gran calidad. 
· Entonces cuando hablamos de calidad, nos referimos al grado en el cual un sistema, componente o proceso satisface los requerimientos especificados en la etapa de análisis y diseño y las expectativas o necesidades del cliente o usuario.
· Para asegurar la calidad de los sistemas y de su desarrollo se deben establecer objetivos claros por medio de: la planificación, el control durante todas las etapas del ciclo de vida y sobre todo la mejora continua.
· El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemáticas necesarias para aportarla confianza en que el producto (software) va a satisfacer los requerimientos del cliente.
Adquisición:
· Cuando decidimos adquirir un software, el ciclo de vida será similar al del desarrollo. Se requiere una etapa de análisis para relevar los requisitos de a organización, una etapa de construcción en la que el sistema se configura de acuerdo con las necesidades, una etapa de pruebas para verificar que funciona de acuerdo a lo requerido y finalmente una etapa de puesta en marcha y posterior mantenimiento.
· Cuando se adquiere un software es necesario evaluar si cumple con las características que buscamos.
· Por eso, cuando adquirimos uno, hay que realizar un proceso de análisis y selección de alternativas. Es necesario utilizar algún método que permita comparar alternativas de la manera más objetiva posible.
· Una herramienta muy útil es la matriz de selección. Se trata de una matriz de doble entrada en la cual se listan en las filas las características requeridas x la organización y en las columnas se ubican las diferentes alternativas de productos/proveedores. Luego a cada opción se le asigna un puntaje en función de cómo cumple cada una de las características requeridas. Finalmente se calcula un puntaje a cada proveedor para poder compararlos bajo el mismo criterio.
· Identificación de requerimientos:
El primer paso antes de tomar cualquier decisión es definir cuáles son las necesidades que queremos cubrir y, de acuerdo con ellas, qué características esperamos que posea nuestra solución, esto es lo que se llama modelo objetivo.
Dado que los requerimientos suelen ser muchos, para facilitar el análisis se agrupan y clasifican. Una clasificación útil es dividir los requerimientos en funcionales, no funcionales y comerciales. Los comerciales tendrán que ver con características del proveedor y del contrato que ofrecen, mientras que los otros con la solución o producto a adquirir (funcionales tiene que ver con el comportamiento del producto, y los no funcionales complementan a los funcionales y describen las condiciones ambientales y las cualidades necesarias para que el producto sea eficaz).
Como no todos los requisitos son igual de importantes, por lo cual es necesario asignarles una ponderación con valores de 0 a 1.
· Identificación de las alternativas:
Una vez definidas nuestras necesidades, es momento de investigar cuáles son los productos disponibles en el mercado y contactar a los proveedores para obtener más información. 
Es recomendable realizar esta tarea luego de definir nuestro modelo objetivo para focalizarnos en las necesidades de la organización.
Al contactar a los proveedores se puede realizar lo que se denomina “Request for Proposal (RFP)” o solicitud de propuesta. Se trata de un documento en el que se presenta información de la organizacióny del proyecto, y se les solicita información sobre las características del producto y servicios ofrecidos. 
A partir de la información recibida, se realiza una pre-selección inicial, descartando aquellos que no cumplan con los requisitos obligatorios. Luego se pueden realizar reuniones con los proveedores para que provean más detalle acerca de la propuesta.
· Evaluación de las alternativas preseleccionadas:
Una vez obtenida la información de las mejores alternativas ofrecidas, necesitamos comprarlas bajo un mismo criterio para definir cuál es la mejor.
En las columnas se ubicarán las alternativas seleccionadas. A continuación, se asignará un puntaje para cada combinación de requisito y alternativa (de acuerdo con la escala y criterios definidos anteriormente)
Como cada ítem posee un peso relativo diferente, se calcula el puntaje asignada multiplicándolo por la ponderación corresponde.
Para realizar la comparación de las alternativas necesitamos obtener un valor único. Volcamos los totales de los valores ponderados totales de cada matriz en una última matriz resumen.
El resultado de la evaluación utilizando la matriz de selección nos permite ver si hay una alternativa que supere a otra ampliamente. En caso de que los resultados sean muy similares será necesario adoptar un criterio adicional para decidir entre ambas.
Las TICs y el crecimiento económico (cap. 6 Tricocci)
· Las Tics aportan al crecimiento económico por varias vías:
· Las mejoras en la producción del sector TICs propiamente dicho.
· Su utilización como un insumo de producción de otros bienes o servicios.
· Contribuyen al crecimiento por el aumento de la productividad de sector No TICs, los cuales son inducidos por la producción y el uso de las mismas. Un ambiente con mayor cantidad de productos tecnológicos aumenta la demanda y sofisticación de los consumidores.
La inversión en TICs y el proceso tecnológico:
· Las mejoras en el aumento del capital humano tienen relación directa con el “factor” conocimiento.
· La inversión en TICs no lleva directamente al crecimiento debido a que su resultado depende de uso y buen aprovechamiento. Cuando las economías comienzan a utilizar información y el conocimiento, el capital humano y la calidad de vida se convierten en palancas claves del desarrollo.
· Una forma de analizar el proceso tecnológico y su influencia en el desarrollo económico es por medio de sus 3 fases: la creación, la adaptación y la utilización de tecnología.
· La inversión en TICs y el aumento de la difusión de información y conocimiento no llevan automáticamente a la innovación. La innovación como proceso creativo, requiere otras competencias, un ambiente propicio de las instituciones y los incentivos adecuados.
· Las TICs pueden potenciar este proceso, pero no reemplazar tales competencias.
El conocimiento en las organizaciones (Cap. 10 Tricocci)
· El impacto de la era digital ha convertido al conocimiento en un bien económico y en el recurso más valioso de las organizaciones modernas.
· Las firmas están siendo “forzadas” a ser innovadoras en productos, procesos y estructuras organizacionales con el fin de que sus nuevos productos generen diferencias extraordinarias por más tiempo.
· El mejor uso de la información, la creación de nuevo conocimiento y su aplicación concreta en el proceso de innovación ese objetivo buscado.
Etapas del ciclo de administración del conocimiento:
· Las etapas son las siguientes:
· Identificar el conocimiento: incluye la identificación del conocimiento creado por la organización y los proveedores de fuentes externas.
· Organizar: incluye la selección, codificación del conocimiento y su disponibilidad.
· Difundir y poner a disposición: el conocimiento de la organización debe ser difundido a los integrantes de la misma.
· Utilizar y aplicar del conocimiento (el hacer): es la verdadera creación del valor del conocimiento para la organización.
· Las personas que trabajan en organizaciones que valoran el conocimiento, se comprometen con el círculo virtuoso de aportar sus conocimientos y tomar nuevo conocimiento que usarían en otros procesos.
Características generales del conocimiento dentro de las organizaciones:
· Las características son:
· Valor del conocimiento: el conocimiento se vuelve valioso para la organización. Puede ser un bien económico en sí mismo o un factor de producción.
· Debe ser parte de la actividad social: el conocimiento se desarrolla en la medida en que se incentiva su intercambio en actividades grupales. El proceso es dinámico y de enriquecimiento de todos los participantes.
· Dinámica del conocimiento: evoluciona rápidamente
· Los procesos con conocimiento incorporado: las firmas que usan las “mejores prácticas de la industria” estarán siendo eficientes, pero si todos los participantes utilizaran las mejores prácticas entonces estarían “empatados”. Se logran diferencias creando un nuevo valor, siendo innovador y creando una nueva “mejor práctica”.
· Proceso cultural hacia la innovación: debe fomentarse una cultura pro- conocimiento e innovación. Esta cultura debe materializarse en un sistema de premios y reconocimiento para retribuir los logros.
· Las TICs: la tecnología de la información y las comunicaciones, por medio de los procesadores, el software, las redes, las bases de datos e internet, forman parte de la infraestructura de captura, almacenamiento y distribución del conocimiento como soporte al ciclo de administración de conocimiento. La generación y uso de nuevo conocimiento es un proceso humano, y la infraestructura es el “facilitador”.
· Hay tres elementos que se relacionan en la administración del conocimiento: los procesos de la organización, los recursos humanos y las TICs. A mayor grado de intersección, mejor y más natural es el proceso.
· Podemos realizar una categorización de ámbito de uso y difusión de conocimiento por distintos estadios:
Conocimiento individual conocimiento grupal conocimiento intra-organizacional conocimiento inter-organizacional.
· La etapa individual si bien puede ser valiosa para el individuo, es la menos relevante desde el proceso de aumento permanente del capital individual, ya que no se comparte y se pierde el proceso virtuoso.
· En el caso de los grupos, hay un mayor intercambio con los grupos primarios a los cuales pertenecen las personas.
· El estadío intra-organizacional es de gran beneficio para la organización porque se integran las distintas miradas del interior de la organización.
· El último estadío correspondiente a inter-organizacional tiene que ver con el intercambio y generación con proveedores y/o clientes con los cuales se tienen alianzas y requiere que se integración en el uso de conocimientos que asegure objetivos comunes y la obtención de beneficios continuos.
La gestión del conocimiento y el aprendizaje organizacional:
· La gestión del conocimiento es un proceso sistémico y cultural.
· Gestionar el conocimiento permite acortar la brecha de aprendizaje organizacional. Hace que las organizaciones no repitan errores del pasado, que tengan memoria activa y desarrolla su capital intelectual.
· Collison y Parcell presentan un esquema de introducción del aprendizaje aplicable a las acciones y procesos. Tienen 3 estadíos de aprendizaje, con la captura continua del conocimiento:
1) El aprender antes implica estudiar y buscar conocimiento ya existente, proveniente de otros equipos de la organización o externos a ella, con el fin de no redescubrir conocimiento. Este tipo de aprendizaje es muy valioso en el ahorro de costos.
2) El aprender durante permite no solo hacer sino discutir y cuestionar el cómo se está haciendo, a los fines de perfeccionar el método y comportamiento de los integrantes del grupo.
3) El aprender después permite el análisis crítico del proceso realizado, el cumplimiento de los objetivos y el uso de los recursos. Se reflexiona sobre lo realizado.
· La captura de conocimiento se realiza en distintos momentos y tiene por objetivo clasificarlo, filtrarloy organizarlo para su posterior disponibilidad a la comunidad de la organización.
· El proceso de aprendizaje dentro de una organización debe estar orientado a la mejora de la rentabilidad t de la competitividad.
· El proceso continuo de creación y uso del nuevo conocimiento e innovación es el puente para lograr ventajas competitivas. 
Estrategia de sistemas y tecnologías de la información (Cap 13 Briano)
El valor de la tecnología informática para la organización:
· Para establecer una estrategia de TICs que agregue valor al negocio debemos tener en cuenta cómo la tecnología puede agregar valor al negocio. La tecnología puede agregar valor por alguna o ambas de dos vertientes, ellas son:
· Reducción de costos.
· Diferenciación.
· La clave del éxito en la estrategia de TICs es determinar en qué aspectos buscar reducir el costo y en cuáles buscar una ventaja competitiva.
· Como regla general podemos considerar que los “impulsores de decisión” de las inversiones en TICs deberían tener en cuenta en forma significativa el nivel de comoditización del componente de que se trate:
· A mayor comoditización del producto/servicio a incorporar, menor el costo.
· A menor comoditización del producto/servicio a incorporar, mayor la diferenciación.
Conceptualización de estrategia:
· Estrategia como intención o plan:
· Esta visión propone el establecimiento de acciones explicitadas de manera deliberada en función de hipótesis previamente establecidas.
· Esta visión originó el llamado “planeamiento estratégico”, obteniéndose como resultado el “plan estratégico” consistente en un extenso documento en el que se detallan las tácticas, los programas, presupuestos y objetivos.
· La realidad de las empresas demostró que el plan estratégico rara vez se cumplía, obligando a su abandono o a continuas revisiones debido a la desconexión entre el plan y la realidad.
· Finalmente se manifestó que el rótulo “planeamiento estratégico” debería ser abandonado, ya que el mismo impidió el pensamiento estratégico.
· Estrategia como resultante o acción:
· Simon en 1945 conceptualizó “estrategia” como la serie de decisiones entre alternativas de comportamiento, conscientes o no, que determinan el comportamiento (individual u organizacional) en un período de tiempo.
· Mintzberg en 1987 señalo que estrategia es un patrón en una secuencia de acciones, una conducta intencional o no a lo largo del tiempo. 
· Estrategia como proceso continuo. Orientación, plan, acción y adaptación:
· Podemos conceptualizar:
· “estrategia planeada” (a priori, planteada en un plan)
· “estrategia ejecutada” (a posteriori, emergente de la realidad)
· En líneas generales se considera a la planificación estratégica sin la abstracción y buscando el establecimiento de grandes líneas de acción que tiendan a los objetivos establecidos.
· La “visión estratégica” nos revela por qué cada estrategia es diferente. Es una mirada que modela la estrategia en su conjunto. La visión estratégica es un acto de creación colectiva realizado en cada organización, irrepetible en otra organización.
· Hay varios modelos que ayudar a realizar el análisis estratégico y su puesta en práctica:
a) Modelo de las cinco fuerzas (Porter):
· Para Porter estrategia se puede definir como un conjunto integrado de acciones que apuntan a mejorar tanto la situación del largo plazo como la fortaleza relativa de la empresa en relación a la competencia, analizando cinco fuerzas:
1. Rivalidad entre los competidores.
2. Amenaza de ingreso de nuevos competidores.
3. Poder de negociación de los compradores.
4. Poder de los proveedores.
5. Amenazas de sustitución del producto.
b) Modelo de la cadena de valor (Porter):
· Se enfoca en la optimización de los procesos necesarios para entregar el producto final desde la obtención de insumos.
c) Modelo de las competencias centrales (Prahalad y Hamel):
· Definen las competencias básicas de la organización como la integración de conocimientos, habilidades y tecnología creadoras de valor de una organización.
· Para competir en el futuro señalan que primero debe desarrollarse una previsión y en función de ella describir una “arquitectura estratégica” que describa los nuevos escenarios y una “intención estratégica” ambiciosa pero alcanzable.
d) Visión basada en los recursos internos (Barney):
· Penrose sostenía que la firma más allá de ser una unidad administrativa, es una colección de recursos productivos.
· Esta visión de Barney toma ese constructo y propone identificar los recursos claves que generan las ventajas competitivas, considerando recursos que sean:
· Valiosos, los que permiten elaborar e implementar estrategias que mejoran eficacia o eficiencia.
· Escasos, disponibles para la empresa en cuestión y con acceso limitado por el resto.
· Difíciles de imitar, por trayectoria, origen o complejidad.
· Difíciles de sustituir.
Estrategias y subestrategias. La estrategia general y la estrategia de SI/TICs:
· Podemos subdividir la estrategia a los efectos de facilitar su análisis, formulación y ejecución. Podemos conceptualizar estrategia:
· Estrategias de nivel superior o corporativo, que es la que atiende a la definición de los lineamientos que tienen impacto en toda la organización.
· Estrategia de negocios, vinculada a una actividad en particular, dado el marco general.
· Estrategias funcionales, principalmente dedicadas a la asignación de recursos para obtener el máximo de ellos.
· Dentro del último encontramos las estrategias que cubre tanto las TICs como las estructuras y procesos vinculados con el uso de las mismas.
· El “Modelo de alineamiento estratégico” está definido por cuatro dominios integrados por dos dimensiones y su cruce. El gran aporte de este modelo es exponer cómo impacta la utilización de la tecnología en los negocios, demostrando la interdependencia existente entre la estrategia del negocio y la estrategia de SI/TI.
· Proponen como dominios:
· Estrategia de negocios.
· Estrategia de tecnologías de información.
· Organización, estructuras y procesos.
· Tecnologías de información.
· Los dos primeros se refieren al planeamiento, cómo piensa la organización el ajuste entre la empresa y su contexto. El objetivo es la efectividad
· La estrategia del negocio y la de la tecnología son de naturaleza adaptativa. La estrategia de sistemas ubica a la organización en el mercado de tecnología. La evaluación e interpretación de la relación de la empresa con los proveedores de tecnología facilita entender las implicaciones que esa relación provocará en la gestión de la infraestructura de sistemas de información.
· Los dos últimos corresponden al ámbito de la acción, cómo se organizan los recursos para ejecutar la estrategia. El objetivo es la eficiencia.
· Proponen los siguientes niveles de alineamiento e integración:
a) Alineamiento directo, horizontal y vertical:
· Entre la estrategia de negocios y la estrategia de TICs: requisito para alcanzar todo el valor que la utilización de TICs puede generar al negocio. La falta de este tipo de alineamiento genera sobrecostos.
· Entre estructuras y procesos en el negocio y entre estructuras y procesos en TICs: relacionada con la capacidad de diseñar, implementar y operar la estrategia en cada ámbito. La falta de este tipo de alineamiento provoca una deficiente implementación de lo planeado.
· Entre estructuras y procesos del negocio y de TICs: relacionadas con la posibilidad de coordinar actividades del negocio y de TICs. La falta de este tipo de alineamientos provoca significativos problemas de eficiencia y tiene impacto negativo en la relación entre estrategias, estructuras y procesos.
b) Alineamiento cruzado entre los dominios:
· Vinculación entre estrategias de negocios y el soporte de TICs: muestran el impacto que la tecnología de la información tienen en los productos y servicios. La falta de esta vinculación profundiza las deficiencias originadas en la falta de alineamiento entre estrategias de negocios y de tecnología.
· Vinculación entre estrategia de tecnología y estructuras