Embed Size (px)
Citation preview
CAPITULO II MARCO TEORICO SOBRE ARQUETIPOS, SISTEMAS, SOFTWARE, ESTANDARES Y ESTRATEGIA. A. ARQUETIPOS Un arquetipo es un modelo o prototipo de una obra material o intelectual. Idea
ejemplar de las cosas, modelo ideal.
1. GENERALIDADES SOBRE MODELOS Los modelos, suministran una guía con el fin de ordenar las diversas actividades
técnicas en el proyecto de desarrollo de software e intentan suministrar un marco
para la administración en el desarrollo y el mantenimiento. Aunque todos ellos son
compatibles unos con otros, un proyecto puede decidir cuáles enfoques son más
útiles en situaciones especiales.
El identificar los riesgos en proyectos, evaluar su impacto, monitorear y controlar
el avance del desarrollo del proyecto, permite al desarrollador aumentar las
posibilidades de éxito de un proyecto o, minimizar las posibilidades de fracaso de
éste.
Una reorientación de los actuales Sistemas de Información debe dejar de lado los
criterios y modelos seguidos hasta ahora y debe determinar aquellos aspectos
que ofrezcan un diseño integrado, más estándar y de fácil evolución en el tiempo.
Entre los principales aspectos a considerar en el nuevo diseño están:
• Obtener una visión total e integrada del Sistema de Información para el
conjunto de la Organización.
• Crear y definir normas y estructuras de diseño.
• Empezar a orientar la construcción de los Sistemas de Información bajo
conceptos de componentes para la fabricación de información, contemplando
la reutilización de los módulos, la especialización de funciones y la
conectividad entre todo el conjunto de piezas que la integran.
• Orientar los Sistemas de Información hacia los Usuarios y Clientes.
• La mejora de la calidad percibida por el Cliente y los profesionales.
• El incremento de la calidad productiva.
• La mejora de la utilización y uso de los recursos.
1.1 Importancia de los Modelos
Los modelos por una parte suministran una guía para los ingenieros de software
con el fin de ordenar las diversas actividades técnicas en el proyecto; por otra
parte, suministran un marco para la administración del desarrollo y el
mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de
control intermedios y monitorear el avance.
2. CONCEPTO DE MODELOS
Arquetipo o punto de referencia para imitarlo o reproducirlo.1
Representación en pequeño de alguna cosa.2
Esquema teórico, de un sistema o una realidad compleja, que se elabora para
facilitar su comprensión y el estudio de su comportamiento.
Simulación de un sistema que existe en un mundo real, la creación de un modelo
pretende una mejor comprensión de un prototipo (el sistema que sé esta
modelando) mediante la revisión o modificación de las características de un
modelo, el usuario puede hacer inferencias acerca del comportamiento del
prototipo.
1 Diccionario de la Lengua Española, Editorial Espasa Calpe, Vigésima segunda edición 2000 2 Ídem
3. CLASIFICACIÓN DE LOS MODELOS Existen diversos modelos para la elaboración de software, en este documento se
muestran los más conocidos y utilizados
3.1 Modelo del Ciclo de Vida.
El ciclo de vida es el conjunto de actividades que los analistas, diseñadores y
usuarios realizan para desarrollar e implantar un sistema de información.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se
mueve un proyecto de desarrollo de software.
El método de Ciclo de Vida para desarrollo de sistemas consta de varias fases
las cuales varían de un autor a otro3, las cuales se definen así:
a) Identificación de problemas, oportunidades y objetivos.
b) Determinación de los requerimientos de información.
c) Análisis de las necesidades del sistema.
d) Diseño del sistema recomendado.
e) Desarrollo y documentación del software.
f) Prueba y mantenimiento del sistema.
g) Implantación y evaluación del sistema.
3.2 Modelo Cascada.
Este es el más básico de todos los modelos, y sirve como bloque de construcción
para los demás modelos de ciclo de vida. La visión del modelo cascada del
desarrollo de software es muy simple; dice que el desarrollo de software puede
ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de
metas bien definidas, y las actividades dentro de una fase contribuyen a la
satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la
fase.
3 Según kendal & kendal, Análisis y Diseño de Sistemas, pg. 7
El modelo de ciclo de vida cascada, captura algunos principios básicos:
a) Planear un proyecto antes de embarcarse en él.
b) Definir el comportamiento externo deseado del sistema antes de diseñar su
arquitectura interna.
c) Documentar los resultados de cada actividad.
d) Diseñar un sistema antes de codificarlo.
e) Testar un sistema después de construirlo.
3.3 Modelo de Prototipos
El prototipo es dado a los usuarios, clientes o representantes de ellos,
posibilitando que ellos lo experimenten. Estos individuos luego proveen la
retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo
proporcionado, quienes capturan en la documentación actual de la especificación
de requerimientos la información entregada por los usuarios para el desarrollo del
sistema real. El prototipado puede ser usado como parte de la fase de
requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos).
3.3.1 Modelo de Prototipado de Requerimientos
El prototipado de requerimientos es la creación de una implementación parcial de
un sistema, para el propósito explícito de aprender sobre los requerimientos del
sistema. Un prototipo es construido de una manera rápida tal como sea posible.
El Prototipado ha sido usado frecuentemente en la década de los 90’s, porque la
especificación de requerimientos para sistemas complejos tiende a ser
relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es
mucho más fácil proveer retroalimentación convenientemente basada en la
manipulación, desde un prototipo, en vez de leer una especificación de
requerimientos potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos están
incorporados, un prototipo generalmente se construye con los requerimientos
entendidos más pobremente.
3.3.2 Modelo de Desarrollo Evolutivo
Construye una serie de grandes versiones sucesivas de un producto. Sin
embargo, mientras que la aproximación incremental presupone que el conjunto
completo de requerimientos es conocido al comenzar, el modelo evolutivo asume
que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y
sólo los que son bien comprendidos son seleccionados para el primer incremento.
Los desarrolladores construyen una implementación parcial del sistema que
recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen
retroalimentación a los desarrolladores. Basada en esta retroalimentación, la
especificación de requerimientos es actualizada, y una segunda versión del
producto es desarrollada y desplegada. El proceso se repite indefinidamente.
3.4 Modelo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son
enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema,
reservando otros aspectos para niveles posteriores. El desarrollo incremental es
el proceso de construcción siempre incrementando subconjuntos de
requerimientos del sistema.
Además el modelo incremental consta de lo siguiente:
a) Combina elementos del modelo de cascada (aplicados repetitivamente) con
la filosofía interactiva de construcción de prototipos.
b) El primer incremento es un producto esencial (núcleo), se afrontan requisitos
básicos y muchas funciones extras (conocidas o no) quedan para los
siguientes incrementos.
c) El cliente usa el producto central y en base a la utilización y/o evaluación se
desarrolla un plan para el incremento siguiente.
d) Este proceso se repite hasta que se elabora el producto completo.
e) Es interactivo, al igual que el de construcción de prototipos y otros enfoques
evolutivos. Pero a diferencia del modelo de construcción de prototipos, el
modelo incremental entrega un producto operacional en cada incremento.
f) Es útil cuando la dotación de personal no está disponible para una
implementación completa. El primer incremento se pueden implementar con
pocas personas. Si el producto central es bien recibido, se pueden añadir
más personal.
3.5. Modelo Espiral
En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno
completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo
ejecutado, se pueden seguir estos cuatros pasos:
a) Determinar qué se quiere lograr.
b) Determinar las rutas alternativas que se pueden tomar para lograr estas
metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar
la mejor.
c) Seguir la alternativa seleccionada en el paso b.
d) Establecer qué se tiene terminado.
3.6. Modelo Concurrente.
Como el modelo espiral, el modelo concurrente provee una meta-descripción del
proceso software. Mientras que la contribución primaria del modelo espiral es en
realidad que esas actividades del software ocurran repetidamente, la contribución
del modelo concurrente es su capacidad de describir las múltiples actividades del
software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades
que ocurren en algún tiempo del proceso de desarrollo de software.
En vez de confinar las actividades de ingeniería de software a una secuencia de
pasos, define una red de actividades.
Todas las actividades de la red existen simultáneamente con otras.
Los sucesos generados dentro de una actividad, o en algún otro lado de la red de
actividad, inician las transiciones entre los estados de otra actividad.
3.7. Modelo sobre Técnicas de Cuarta Generación (4GL)
a) Permite especificar el software usando lenguajes especializados o
notaciones gráficas que describan el problema.
b) Requiere usar alguna herramienta CASE (Computer-Aided Software
Engineering) con herramientas tales como: SQL (Structured Query
Language), generador de reportes, base de datos, definidores de pantallas,
generadores de código, generador de gráficas, hoja de cálculo.
c) Idealmente el cliente describe los requisitos, que son traducidos
inmediatamente a un prototipo operativo.
d) En aplicaciones pequeñas, se puede ir directamente a la implementación
usando un lenguaje de cuarta generación (4GL).
e) En aplicaciones grandes, el uso de 4GL sin diseño provocará los mismos
problemas que los otros paradigmas (poca calidad, mantenimiento pobre y
mala aceptación del cliente).
f) El uso de 4GL permite al desarrollador centrarse en la representación de los
resultados deseados.
g) Para transformar una implementación 4GL en un producto, el desarrollador
debe dirigir una prueba completa, hacer una buena documentación y ejecutar
el resto de las actividades de integración requeridas en los otros paradigmas.
Además, el software desarrollado con 4GL debe ser construido de modo que
facilite el mantenimiento.
B. SISTEMAS 1. GENERALIDADES DE SISTEMAS El término “sistema” es de uso común. Se habla de sistemas educativos, de
sistemas de computación, de sistemas de teología, y de muchos otros. Los
conceptos de sistemas proveen una infraestructura útil para la descripción y
comprensión de muchos fenómenos organizacionales incluyendo las
características de los sistemas de información. Los sistemas pueden ser
abstractos o físicos.
Un Sistema Abstracto, es una disposición de manera ordenada de ideas
interdependientes o artefactos.
Un Sistema Físico es un conjunto de elementos que operan conjuntamente para
cumplir un objetivo. Un modelo general de un sistema físico es la entrada, el
proceso y la salida. Las características que definen y que delinean un sistema
configuran su límite. El sistema está por dentro de los límites; el medio ambiente
está por fuera de los límites.
Cada sistema está compuesto de “subsistemas”, los cuales a su vez son parte de
otros subsistemas; cada subsistema delineado por sus límites. Las
interconexiones y las interacciones entre los subsistemas se llaman interfaces.
Las interfaces ocurren en el límite y toman la forma de entradas y de salidas.
2. CONCEPTO DE SISTEMAS4
Colección organizada de componentes que se optimizan para que funcionen
como un todo.
Es un conjunto o disposición de procedimientos o programas relacionados de
manera que juntos forman una sola unidad.
4 www.monografias.com/trabajo6 2002 Documentación de Sistemas
Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera
ordenada mostrando un plan lógico en la unión de las partes.
Un método, plan o procedimiento de clasificación para hacer algo.
3. CLASIFICACIÓN DE SISTEMA.
Existen diferentes clases de sistemas dentro de las cuales están:
a) Sistemas Determinísticos
Un sistema determinístico opera de una manera predecible. La interacción
entre las partes se conoce con certeza. Si se tiene la descripción de un
estado del sistema en un momento dado además de una descripción de su
operación, el siguiente estado del sistema se puede dar con exactitud, sin
error.
b) Sistemas Probabilísticos
El sistema probabilístico se puede definir en términos de comportamiento
probable; hay un cierto grado de error que siempre está asociado a la
predicción de lo que hará este sistema.
c) Sistemas Cerrados
Un sistema es cerrado cuando ningún elemento de afuera entra y ninguno
sale fuera del sistema. Estos alcanzan su estado máximo de equilibrio al
igualarse con el medio (entropía, equilibrio). En ocasiones el término sistema
cerrado es también aplicado a sistemas que se comportan de una manera
fija, rítmica o sin variaciones, como sería el caso de los circuitos cerrados.
d) Sistemas Abiertos
Los sistemas abiertos intercambian información, materiales o energía con el
medio ambiente incluyendo el azar y entradas no definidas. Los sistemas
abiertos tienden a tener forma y estructura que les permiten adaptarse a los
cambios de su medio ambiente en tal forma que puedan continuar su
existencia. Son auto-organizados en el sentido de que modifican su
organización en respuesta a las condiciones cambiantes.
e) Sistemas Artificiales
Los sistemas artificiales son creados, no ocurren en la naturaleza. Los
sistemas artificiales están diseñados para apoyar los objetivos de los
diseñadores y de los usuarios. Manifiestan, en consecuencia, las
características del sistema que soportan.
f) Sistemas HOMBRE-MAQUINA
Los sistemas de información son generalmente sistemas hombre-máquina (o
sistemas usuario-máquina) de modo tal que ambos desempeñan algunas de
las actividades en el cumplimiento de una meta ( por ejemplo una toma de
decisión). Los elementos de las máquinas ( hardware y software) son
relativamente cerrados, y determinísticos, mientras que los elementos
humanos del sistema son abiertos y probabilísticos. Son posibles varias
combinaciones de hombre máquina. Un balance apropiado en la división de
funciones, es decisivo para el desempeño exitoso de cada uno de los
componentes en el cumplimiento de sus objetivos; de esta manera la división
entre el hombre y la máquina variará de aplicación en aplicación.
4. ANALISIS Y DISEÑO DE SISTEMAS 4.1 Generalidades del Análisis y Diseño de Sistemas.
Dentro de las organizaciones, el análisis y diseño de sistemas se refiere a
examinar la situación de una empresa con el propósito de mejorarla con métodos
y procedimientos más adecuados.
El desarrollo de sistemas puede considerarse, en general, formado por dos
grandes componentes: el análisis de sistemas y el diseño de sistemas.
El análisis de sistemas, es el proceso de clasificación e interpretación de hechos,
diagnóstico de problemas y empleo de la información para recomendar mejorar el
sistema.
El diseño de sistemas es el proceso de planificar, reemplazar o completar un
requerimiento organizacional existente. Pero antes de llevar a cabo esta
planeación es necesario comprender, en su totalidad, el viejo sistema y
determinar la mejor forma en que se pueden, sí es posible, utilizar las
computadoras para hacer la operación más eficiente.
4.2 Importancia del Análisis y Diseño de Sistemas
En una organización o empresa, el análisis y diseño de sistemas, es el proceso de
estudiar su situación con la finalidad de observar cómo trabaja y decidir si es
necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el
analista de sistemas.
Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un
estudio de sistemas para detectar todos los detalles de la situación actual de la
empresa. La información reunida con este estudio sirve como base para crear
varias estrategias de diseño. Los administradores deciden qué estrategias seguir.
Los gerentes, empleados y otros usuarios finales que se familiarizan cada vez
más con el uso de computadoras están teniendo un papel muy importante en el
desarrollo de sistemas.
Todas las organizaciones son sistemas que actúan de manera recíproca con su
medio ambiente recibiendo entradas y produciendo salidas. Los sistemas que
pueden estar formados por otros sistemas se denominan sub-sistemas y
funcionan para alcanzar los fines de su implantación.
4.3 Análisis de Sistemas
La función del Análisis puede ser dar soporte a las actividades de un negocio, o
desarrollar un producto que pueda venderse para generar beneficios. Para
conseguir este objetivo, un sistema basado en computadoras hace uso de seis
elementos fundamentales:
a) Software: programas de computadora, con estructuras de datos y su
respectiva documentación que hacen efectiva la logística, metodología o
controles de requerimientos del programa.
b) Hardware: dispositivos electrónicos y electromecánicos, que proporcionan
capacidad de cálculos y funciones rápidas, exactas y efectivas que
proporcionan una función externa dentro de los sistemas.
c) Personal: son los operadores o usuarios directos de las herramientas del
sistema.
d) Base de Datos: gran colección de información organizada y enlazada al
sistema a la que se accede por medio del Software.
e) Documentación: manuales, formularios y otra información descriptiva que
detalla o da instrucciones sobre el empleo y operación del programa.
f) Procedimientos: pasos que definen el uso específico de cada uno de los
elementos o componentes del sistema y las reglas de su manejo y
mantenimiento.
Un Análisis de Sistemas se lleva a cabo teniendo en cuenta los siguientes
objetivos en mente:
a) Identificar las necesidades del Cliente.
b) Evaluar que conceptos tiene el cliente del sistema para establecer su
Viabilidad.
c) Realizar un análisis técnico y económico.
d) Asignar funciones al Hardware, Software, Personal, Base de Datos, y otros
elementos del sistema.
e) Establecer las restricciones de presupuestos y planificación temporal.
f) Crear una definición del sistema que forme el fundamento de todo el
trabajo de Ingeniería.
4.4 Diseño de Sistemas
El diseño es una representación significativa de algo que se va a construir. Se
puede efectuar el seguimiento basándose en los requisitos del usuario, y al mismo
tiempo la calidad se puede evaluar y cotejar con el conjunto de criterios
predefinidos.
El diseño comienza con el modelado de los requisitos, se trabaja para transformar
este modelo y obtener cuatro niveles de detalle de diseño:
a) La estructura de datos.
b) Arquitectura del sistema.
c) Representación de la interfaz.
d) Detalles a nivel de componente.
Durante cada una de las actividades del diseño, se aplican los conceptos y
principios básicos que llevan a obtener una alta calidad.
4.5 Etapas del Diseño
El Diseño de Sistemas se define como el proceso de aplicar ciertas técnicas y
principios con el propósito de definir un dispositivo, un proceso o un sistema, con
suficientes detalles como para permitir su interpretación y realización física.
Encierra cuatro etapas:
a) Diseño de los Datos.
Trasforma el modelo de dominio de la información, creado durante el
análisis, en las estructuras de datos necesarios para implementar el
Software.
b) Diseño Arquitectónico.
Define la relación entre cada uno de los elementos estructurales del
programa.
c) Diseño de la Interfaz.
Describe cómo se comunica el Software consigo mismo, con los sistemas
que operan junto con él y con los operadores y usuarios que lo emplean.
d) Diseño de Procedimientos.
Transforma elementos estructurales de la arquitectura del programa. La
importancia del Diseño del Software se puede definir en una sola palabra
Calidad, dentro del diseño es donde se fomenta la calidad del proyecto. El
Diseño es la única manera de materializar con precisión los requerimientos
del cliente.
El diseño debe implementar todos los requisitos explícitos contenidos en el
modelo de análisis y debe acumular todos los requisitos implícitos que desea el
cliente.
Debe ser una guía que puedan leer y entender los que construyan el código y los
que prueban y mantienen el Software.
El Diseño debe proporcionar una completa idea de lo que es el Software,
enfocando los dominios de datos, funcional y comportamiento desde el punto de
vista de la Implementación.
El Diseño del Software es un proceso y un modelado a la vez. El proceso de
Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir
todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la
calidad del desarrollo del proyecto con un conjunto de revisiones técnicas.
4.6. Diseño de la Salida.
En este caso salida se refiere a los resultados e informaciones generadas por el
Sistema. Para la mayoría de los usuarios la salida es la única razón para el
desarrollo de un Sistema y la base de evaluación de su utilidad.
4.7. Diseño de Archivos.
Incluye decisiones con respecto a la naturaleza y contenido del propio archivo,
como si se fuera a emplear para guardar detalles de las transacciones, datos
históricos o información de referencia. Entre las decisiones que se toman durante
el diseño de archivos, se encuentran las siguientes:
a) Los datos que deben incluirse en el formato de registros contenidos en el
archivo.
b) La longitud de cada registro, con base en las características de los datos que
contenga.
c) La secuencia a disposición de los registros dentro del archivo .
d) La estructura de almacenamiento que puede ser secuencial, indexada o
relativa.
4.8 Diseño de Interacciones con la Base de Datos.
La mayoría de los sistemas de información ya sean implantado en sistemas de
cómputos grandes o pequeños, utilizan una base de datos que pueden abarcar
varias aplicaciones, por esta razón estos sistemas utilizan un administrador de
base de datos, en este caso el diseñador no construye la base de datos sino que
consulta a su administrador para ponerse de acuerdo en el uso de esta en el
sistema.
5. DESARROLLO DE SOFTWARE
5.1 Generalidades del Desarrollo de Software
Uno de los factores que más influyen en el proceso de desarrollo de software y
que prácticamente acompaña a toda aplicación es el hecho de que en su mayoría,
no hay forma de tener todos los requerimientos corregidos antes del desarrollo del
software. Muchas veces los requerimientos emergen a medida que la aplicación o
parte de ella esta disponible para experimentación práctica. En todos los casos, el
trabajo comienza con la determinación de objetivos, alternativas y restricciones,
paso que a veces se llama recolección preliminar de requisitos.
El cambio es una propiedad intrínseca del software. Hoy en día el software debe
poseer un enfoque evolutivo, un sistema debe evolucionar para acomodar la
naturaleza evolutiva de los grandes sistemas. El software cambia
constantemente, debido a la necesidad de repararlo (eliminando errores no
detectados anteriormente) como a la necesidad de apoyar la evolución de los
sistemas a medida que aparecen nuevos requerimientos o cambian los antiguos.
El proceso de desarrollo o elaboración de software es un conjunto de actividades
que varían según la organización y el tipo de sistema que se desarrolla, por lo que
la gestión exige disponer de un modelo.
Son características de un proceso de software: claridad, fiabilidad, visibilidad,
robustez, facilidad de soporte, facilidad de mantenimiento, aceptación y rapidez
5.2 Factibilidad de Realizar un Proyecto (Software).
Las investigaciones preliminares examinan la factibilidad del proyecto, la
posibilidad de que el sistema sea de utilidad para la organización. Se estudian las
pruebas factibles siguientes:
a) Factibilidad Técnica.
Entre los aspectos técnicos comunes que aparezcan durante la etapa de
factibilidad de la investigación, se incluyen los siguientes:
a.1) ¿Se cuenta con la tecnología adecuada?
a.2) ¿El sistema propuesto ofrecerá respuestas adecuadas a las
peticiones sin importar él numero de usuarios?
El análisis de factibilidad técnica evalúa si el equipo y software están disponibles
(o, en el caso del software, si puede desarrollarse) y si tienen las capacidades
técnicas requeridas por cada alternativa del diseño que se esté considerando. Los
estudios de factibilidad técnica también consideran las interfases entre los
sistemas actuales y nuevo.
Los estudios de factibilidad técnica también consideran si la organización tiene el
personal que posee la experiencia técnica requerida para diseñar, implementar,
operar y mantener el sistema propuesto. Si el personal no tiene esta experiencia,
puede entrenársele o pueden emplearse nuevos o consultores que la tengan. Sin
embargo, una falta de experiencia técnica dentro de la organización puede llevar
al rechazo de una alternativa particular.
b) Factibilidad Financiera y Económica
Un sistema que puede ser desarrollado desde el punto de vista técnico y que,
además, será utilizado, debe ser una buena inversión para la organización. Los
beneficios financieros deben igualar o exceder a los costos. Las cuestiones
económicas y financieras formuladas, tienen el propósito de estimar lo siguiente:
b.1) El costo de llevar a cabo el sistema
b.2) El costo de inversión de equipo (hardware) y el costo del software para
realizar la aplicación.
b.3) Beneficios a obtener.
c) Factibilidad Operacional
Esta factibilidad comprende una determinación de la probabilidad de que un
nuevo sistema se use como se supone. Deberían considerarse cuatro aspectos
de la factibilidad operacional por lo menos.
Primero, un nuevo sistema puede ser demasiado complejo para los usuarios de la
organización o los operadores del sistema. Si lo es, los usuarios pueden ignorarlo
o bien usarlo en tal forma que cause errores o fallas en el sistema.
Segundo, un sistema puede hacer que los usuarios se resistan a él como
consecuencia de una técnica de trabajo, miedo a ser desplazados, intereses en el
sistema antiguo u otras razones. Para cada alternativa debe explorarse con
cuidado la posibilidad de resistirse al cambio al nuevo sistema.
Tercero, un nuevo sistema puede introducir cambios demasiado rápido para
permitir al personal adaptarse a él y aceptarlo. Un cambio repentino que se ha
anunciado, explicado y “vendido” a los usuarios con anterioridad puede crear
resistencia. Sin importar qué tan atractivo pueda ser un sistema en su aspecto
económico si la factibilidad operacional indica que tal vez los usuarios no
aceptarán el sistema o que su uso resultará en muchos errores o en una baja en
la moral, el sistema no debe implantarse.
Una última consideración es la probabilidad de la obsolescencia subsecuente en
el sistema. La tecnología que ha sido anunciada pero que aún no está disponible
puede ser preferible a la tecnología que se encuentra en una o más de las
alternativas que se están comparando, o cambios anticipados en las prácticas o
políticas administrativas pueden hacer que un nuevo sistema sea obsoleto muy
pronto. En cualquier caso, la implantación de la alternativa en consideración se
convierte en impráctica.
Un resultado frecuente de hallazgos negativos acerca de la factibilidad
operacional de un sistema es que éste no se elimina sino que se simplifica para
mejorar su uso.
Otras posibilidades son que los programas de relaciones públicas o de
entrenamiento estén diseñados para enfocarse a sobreponerse a la resistencia a
un nuevo sistema, o se desarrollan formas para hacer fases en el nuevo sistema
en un largo periodo para que el cambio total, que traumatizaría a los usuarios u
operadores, se convierta en una serie de pequeños cambios.
5.3 Etapas del Desarrollo de Software
El desarrollo de software implica la puesta en marcha de las siguientes etapas:
a) Análisis.
b) Diseño.
c) Implementación.
d) Prueba.
e) Instalación.
f) Mantenimiento.
5.4 Riesgo en el Desarrollo de Software
En primer lugar definir en forma precisa lo que es el riesgo en el desarrollo de
software resulta un tanto difícil; por lo que riesgo implica:
• Incertidumbre. El acontecimiento que caracteriza al riesgo puede o no
puede ocurrir.
• Pérdida. Si el riesgo se convierte en una realidad, ocurrirán consecuencias
no deseadas o pérdidas.
Se tiene riesgo al disponer de una información inadecuada o imprecisa, este
hecho se puede reducir disponiendo de información que reduzca incertidumbres.
El riesgo inherente en las actividades es una medida de la incertidumbre de los
resultados por lo que se puede decir que a menor información mayor riesgo en el
desarrollo de software.
El riesgo latente en el desarrollo de software también puede afectar al mejor
modelo que se está aplicando para su desarrollo, por lo mismo, se debe saber
qué modelo aplicar ante el desarrollo de cada sistema.
De acuerdo al nivel de incertidumbre y el grado de pérdidas asociado con cada
riesgo se pueden determinar las siguientes categorías:
a) Riesgos del proyecto: amenazan al plan del proyecto.
b) Riesgos técnicos: amenazan la calidad y la planificación temporal del
software que hay que producir y si se convierte en realidad, la
implementación puede llegar a ser difícil o imposible.
c) Riesgos del negocio: amenazan la viabilidad del software a construir.
d) Riesgos conocidos: son los que se pueden determinar después de una
cuidada evaluación del plan del proyecto.
5.5 Visibilidad del Proceso de Desarrollo de Software
Dada la naturaleza intangible del proceso de desarrollo de software es necesario
la elaboración de un documento que permita seguir la marcha del proceso de esta
manera se está logrando que el proceso de software sea visible a otros posibles
usuarios tomando en cuenta lo siguiente:
1. No formular documentos más de lo necesario lo cual encarece el proceso.
2. El tiempo que se necesita para revisar y aprobar un proceso es
significativo.
5.6 Fundamentos de Desarrollo de Software
Existen dos conceptos importantes a considerar en los sistemas de
procesamiento de la información como son:
1. Hardware. Conjunto de componentes físicos de una computadora.
2. Software. Conjunto de programas que controlan el funcionamiento de una
computadora.
Es muy importante saber que un programador de computadora es antes que nada
una persona que resuelve problemas de un modo riguroso y sistemático; es decir
haciendo uso de la metodología necesaria para resolver problemas mediante
programas.
5.7 Resolución de Problemas a través de un Software
La principal razón para que las personas aprendan a desarrollar software en
general y los lenguajes de programación en particular es utilizar la computadora
como una herramienta para la resolución de problemas. La resolución de un
problema se puede dividir en tres fases:
a) Análisis del problema.
b) Diseño o desarrollo de un algoritmo.
c) Resolución del algoritmo en la computadora.
Para el desarrollo de software se utilizan diferentes tipos de lenguajes entre los
que se tienen:
a. Lenguaje de Bajo Nivel
Los lenguajes de bajo nivel son más fáciles de utilizar que los lenguajes
máquina, pero, al igual que ellos, dependen de la máquina en particular. El
lenguaje de bajo nivel por excelencia es el ensamblador y las instrucciones
utilizadas son conocidas como nemotécnicas; el programa original escrito en
ensamblador se denomina programa fuente.
Son ventajas de los lenguajes de bajo nivel: la facilidad de codificación y la
mayor velocidad de cálculo.
Son desventajas de los lenguajes de bajo nivel: la dependencia total de la
máquina (lo que impide la transportabilidad de los programas) y la formación
de los programadores es más compleja que la correspondiente a los
programadores de alto nivel porque no sólo son requeridas las técnicas de
programación, sino también el conocimiento del interior de la máquina.
b. Lenguaje de Alto Nivel.
Los lenguajes de alto nivel son los más utilizados por los programadores ya
que están diseñados para que las personas escriban y entiendan los
programas de un modo mucho más fácil que los lenguajes de máquina y
ensambladores.
Son ventajas de los lenguajes de alto nivel: el tiempo de formación de los
programadores es relativamente corto comparado con otros lenguajes, la
escritura de programas se basa en reglas sintácticas similares a los lenguajes
humanos, las modificaciones y puesta a punto de los programas son más
fáciles, la reducción del coste de los programas y la transportabilidad.
Son desventajas de los lenguajes de alto nivel: el incremento del tiempo de
puesta a punto, no se aprovechan los recursos internos de la máquina, el
aumento de la ocupación de memoria y el tiempo de ejecución de los
programas es mucho mayor.
C. SOFTWARE 1. CONCEPTO DE SOFTWARE5
Conjunto de programas, instrucciones y reglas informáticas para ejecutar o crear
ciertas tareas en una computadora.
Programas de computadora en contraste con el equipo físico en el que son
ejecutados (hardware).
Por convención el software se divide en dos categorías, software de sistemas,
programa necesario para operar la computadora y programas de aplicación que
permiten a los usuarios desarrollar tareas, utilizando la computadora.
2. CONTROL DE CALIDAD DEL SOFTWARE
2.1 Calidad en el Software
Los desarrolladores de software convergen en que un software de alta calidad es
una de las metas más importantes que deben cumplir; pero es difícil definir la
calidad, ya que el software en su gran extensión, como entidad intelectual es 5 www.monografias.com/trabajo7 2002 Análisis y Diseño de Sistemas
difícil de caracterizar la calidad que posee en comparación con los objetos físicos;
sin embargo sí existen las medidas de características de un programa ante las
cuales se tienen: Complejidad ciclomática, cohesión, números de puntos de
función, líneas de código.
Una interpretación de calidad del software tiende al rendimiento establecido, los
estándares de desarrollo explícitamente documentados y las características
implícitas que se esperan de todo software desarrollado profesionalmente; es
decir hacer énfasis en:
• Los requisitos del software son la base de las medidas de la calidad, lo que
se traduce a que si existe una falta de concordancia de los requisitos
entonces se da una falta de calidad.
• Estándares específicos definen un conjunto de criterios de desarrollo que
guían la manera en que se desarrolla el software
• El software debe cumplir con los requisitos explícitos; pero también con los
implícitos (por ejemplo facilidad de mantenimiento) ya que de no ser así la
calidad del software no será fiable.
La calidad en el desarrollo de software se puede clasificar en dos tipos como son:
a. LA CALIDAD DEL DISEÑO. Se refiere a las características que especifican los
desarrolladores de software para un producto lo que significa que el software
se desarrolla, no se fabrica. El coste está fundamentalmente en el proceso de
diseño, no en la posterior producción en serie, y los errores se introducen
también en el diseño, no en la producción. Por lo tanto es importante destacar
que la calidad de un producto software debe ser considerada en todos sus
estados de evolución (especificaciones, diseño, códigos). No basta con
verificar la calidad del producto una vez finalizado cuando los problemas de
mala calidad ya no tienen solución o su reparación es muy costosa.
b. LA CALIDAD DE CONCORDANCIA. Es el grado de cumplimiento de las
especificaciones de diseño durante su realización
2.2 Control, Garantía y Coste de Calidad
El Control de Calidad es una serie de inspecciones, revisiones y pruebas
utilizadas a lo largo del ciclo de desarrollo para asegurar que cada requerimiento
cumple con los requisitos que le han sido asignados. Las actividades de control
de calidad pueden ser manuales, completamente automáticas o una combinación
de herramientas automáticas e interacción humana.
La Garantía de Calidad o el Aseguramiento de la Calidad, consiste en la auditoria
y las funciones de información de la gestión. El objetivo de la garantía de calidad
es; proporcionar la gestión, para informar de los datos necesarios sobre la calidad
del producto, por lo que se va adquiriendo una visión más profunda y segura de
que la calidad del producto está cumpliendo sus objetivos.
El Coste de calidad, incluye todos los costes acarreados en la búsqueda de la
calidad o en las actividades relacionadas con la obtención de la calidad. Se
realizan estudios sobre el coste de calidad para proporcionar una línea base del
coste actual de calidad, para identificar oportunidades de reducir este coste, y
para proporcionar una base normalizada de comparación.
Los costes de calidad se pueden dividir en costes asociados con la prevención, la
evaluación y los fallos.
Entre los costes de prevención se incluyen: planificación de la calidad, revisiones
técnicas formales, equipo de pruebas y formación.
Entre los costes de evaluación se incluyen actividades para tener una visión más
profunda de la condición del producto; como por ejemplo: inspección en el
proceso y entre procesos, calibrado y mantenimiento del equipo y pruebas.
Los costes de fallos son los costes que desaparecerían si no surgieran defectos
antes de la entrega de un producto a los clientes. Los costes de fallos se pueden
dividir en: costes de fallos internos y costes de fallos externos.
Los Costes de Fallos Internos, se producen cuando se detecta un error en el
producto antes de la puesta en marcha
Los Costes de Fallos Externo, son los que se asocian a los defectos encontrados
una vez entregado el producto al cliente.
2.3 Factores de Calidad en el Software
Los factores que afectan a la calidad del software se pueden categorizar en dos
grupos:
• Factores que se pueden medir directamente (defectos por punto de
función).
• Factores que se pueden medir solo indirectamente (facilidad de uso o de
mantenimiento)
El modelo de calidad de software organiza los factores en dos ejes o puntos de
vista desde los cuales el usuario puede contemplar la calidad de un producto,
basándose en once factores de calidad organizados en torno a los dos ejes y a su
vez cada factor se desglosa en otros criterios:
Puntos De
Vista O Ejes
Factor Criterios
OPERACIÓN
DEL
PRODUCTO
Facilidad de uso
- Facilidad de operación: Atributos del software que determinan
la facilidad de operación del software.
-Facilidad de comunicación: Atributos del software que
proporcionan entradas y salidas fácilmente asimilables.
- Facilidad de aprendizaje: Atributos del software que facilitan la
familiarización inicial del usuario con el software y la transición del
modo actual de operación.
- Formación: El grado en que el software ayuda para permitir que
nuevos usuarios apliquen el sistema.
Integridad
- Control de accesos: Atributos del software que proporcionan
control de acceso al software y los datos que maneja.
- Facilidad de auditoría: Atributos del software que facilitan la
auditoría de los accesos al software.
- Seguridad: La disponibilidad de mecanismos que controlen o
protejan los programas o los datos.
Corrección
- Completitud: Atributos del software que proporcionan la
implementación completa de todas las funciones requeridas.
- Consistencia: Atributos del software que proporcionan
uniformidad en las técnicas y notaciones de diseño e
implementación.
- Trazhabilidad o rastrehabilidad: Atributos del software que
proporcionan una traza desde los requisitos a la implementación
con respecto a un entorno operativo concreto.
Fiabilidad
- Precisión: Atributos del software que proporcionan el grado de
precisión requerido en los cálculos y los resultados.
- Tolerancia a fallos: Atributos del software que posibilitan la
continuidad del funcionamiento bajo condiciones no usuales.
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
- Simplicidad: Atributos del software que posibilitan la
implementación de funciones de la forma más comprensible
posible.
- Exactitud: La precisión de los cálculos y del control.
OPERACIÓN
DEL
PRODUCTO
Eficiencia
- Eficiencia en ejecución: Atributos del software que minimizan el
tiempo de procesamiento.
- Eficiencia en almacenamiento: Atributos del software que
minimizan el espacio de almacenamiento necesario.
Facilidad de
mantenimiento
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
- Simplicidad: Atributos del software que posibilitan la
implementación de funciones de la forma más comprensible
posible.
- Consistencia: Atributos del software que proporcionan
uniformidad en las técnicas y notaciones de diseño e
implementación.
- Concisión: Atributos del software que posibilitan la
implementación de una función con la menor cantidad de códigos
posible.
- Auto descripción: Atributos del software que proporcionan
explicaciones sobre la implementación de las funciones.
Facilidad de
prueba
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
- Simplicidad: Atributos del software que posibilitan la
implementación de funciones de la forma más comprensible
posible.
- Auto descripción: Atributos del software que proporcionan
explicaciones sobre la implementación de las funciones.
- Instrumentación: Atributos del software que posibilitan la
observación del comportamiento del software durante su ejecución
para facilitar las mediciones del uso o la identificación de errores.
REVISIÓN
DEL
PRODUCTO
REVISION
DEL
PRODUCTO
Flexibilidad
- Auto descripción: Atributos del software que proporcionan
explicaciones sobre la implementación de las funciones.
- Capacidad de expansión: Atributos del software que posibilitan
la expansión del software en cuanto a capacidades funcionales y
datos.
- Generalidad: Atributos del software que proporcionan amplitud a
las funciones implementadas.
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
Reusabilidad
- Auto descripción: Atributos del software que proporcionan
explicaciones sobre la implementación de las funciones.
- Generalidad: Atributos del software que proporcionan amplitud
a las funciones implementadas.
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
-Independencia entre sistema y software: Atributos del software
que determinan su dependencia del entorno operativo.
- Independencia del hardware: Atributos del software que
determinan su dependencia del hardware.
Interoperabilidad
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
- Compatibilidad de comunicaciones: Atributos del software que
posibilitan el uso de protocolos de comunicación e interfaces
estándar.
- Compatibilidad de datos: Atributos del software que posibilitan el
uso representaciones de datos estándar.
- Estandarización en los datos: El uso de estructuras de datos y
de tipos estándar a lo largo de todo el programa.
Portabilidad
- Auto descripción: Atributos del software que proporcionan
explicaciones sobre la implementación de las funciones.
- Modularidad: Atributos del software que proporcionan una
estructura de módulos altamente independientes.
-Independencia entre sistema y software: Atributos del software
que determinan su dependencia del entorno operativo.
- Independencia del hardware: Atributos del software que
determinan su dependencia del hardware.
D. ESTÁNDARES 1. GENERALIDADES DE ESTANDARES
La Organización Internacional de Normalización (ISO) es una federación mundial
de organismos nacionales de normalización cuyos comités técnicos elaboran las
normas internacionales.
Todos los organismos miembros interesados en una materia y para la cual se
haya instituido un comité técnico, tienen el derecho de estar representados en
dicho comité.
Los proyectos de normas internacionales (DIS) adoptados por los comités
técnicos son enviados a los organismos miembros para su votación.
En 1985 la Comunidad Económica Europea emitió una resolución donde ponía de
manifiesto la necesidad de aproximación técnica de las empresas europeas para
la correcta implantación del libre mercado, así mismo instaba a los organismos
de estandarización a buscar una normativa que asegurase la conformidad de
servicios, productos, sistemas y procesos a la que pudiesen acogerse las
empresas con el fin de lograr esta conversión técnica.
En el año 1987 se adopta en Europa a través del Comité Europeo de
Normalización (CEN) la serie de normas ISO 9000 como referencia para la
certificación de sistemas de calidad. En 1994 estas normas son revisadas y
nuevamente en el año 2000, tal como establecen los protocolos ISO que obligan a
revisar las normas cada 5 años.
Las ISO 9000:2000 están compuestas por 4 normas básicas, complementadas
con un número reducido de otros documentos ( guías, informes técnicos y
especificaciones técnicas) que con mayor claridad de lenguaje establecen las
siguientes características principales: incrementar el compromiso de la dirección,
orientación a los procesos, incluir la satisfacción del cliente y mejora continua.
ESTRUCTURA DE LAS ISO 9000:2000
a) ISO 9000:2000. Sistema de Gestión de Calidad, principios y vocabularios
donde se establece la terminología y definiciones utilizadas en ella.
b) ISO 9001:2000. Los Requerimientos del Sistema de Gestión de Calidad, para
su utilización como un medio de asegurar la conformidad de los productos y
servicios y puede ser utilizada con fines de certificación
c) ISO 9004:2000. Recomendaciones sobre todos los aspectos de un Sistema de
Gestión de Calidad, para mejorar las prestaciones globales de una
organización.
d) ISO1 9011:2000. Auditorias, todas estás han sido modificadas por las
siguientes directrices:
• Simplicidad de uso y vocabulario actualmente utilizado por las
organizaciones.
• Aplicable a todas las categorías genéricas de productos (hardware,
software, materiales procesados y servicios).
• Gestión orientada a “Aproximación a procesos”
• Es un camino hacia la gestión de calidad total
• Orientación hacia la mejora continua y la satisfacción del cliente.
• Compatibilidad con otros sistemas de Gestión (ISO 14000)
Gestionar una organización incluye gestionar la calidad entre otras disciplinas, por
ello las normas ISO 9000:2000 se han basado en los 8 principios de gestión de
calidad preparados por expertos internacionales en calidad y tomadas como
directrices, estos ocho principios son:
a) Organización Enfocada al Cliente: las organizaciones dependen de sus
clientes y por tanto deben comprender las necesidades actuales y futuras,
cumplir con los requisitos de los clientes y esforzarse en sobrepasar las
expectativas de los mismos.
b) Liderazgo: Las organizaciones deben fomentar el liderazgo, éstas crean el
ambiente en el cual el personal puede llegar a involucrase totalmente en el
logro de los objetivos de la organización.
c) Participación del Personal: El personal es la esencia de la organización y
su total implicación posibilita que sus capacidades sean usadas para el
beneficio de la organización.
d) Enfoque al Proceso: Los resultados deseados se consiguen más
eficazmente cuando los recursos y actividades se gestionan como un
proceso.
e) Enfoque del Sistema hacia la Gestión: Identificar, entender y gestionar un
sistema de procesos interrelacionados, mejorar la eficacia de una
organización.
f) Mejora Continua: es un objetivo permanente de la organización.
g) Toma de Decisiones por Datos: las decisiones eficaces se basan en el
análisis de los datos y la información.
h) Relación Beneficiosa con los Suministradores: las relaciones mutuamente
beneficiosas entre la organización y sus suministradores intensifica la
capacidad de ambas organizaciones para crear valor.
2. CONCEPTO DE ESTANDAR Estándar: En computación conjunto de reglas o especificaciones que definen la
arquitectura de un dispositivo de hardware, un programa o un sistema operativo
Estándar: Tipo, modelo, patrón.
Estandarización: Normalización en la composición de los productos lo que suele
ir acompañado de una reducción del numero de modelos de fabricación
3. GESTION ESTANDAR Hoy en día en todo el mundo reconoce que la alta calidad del producto se traduce
en ahorro de coste y en una mejora general por lo que existe la gestión total de
calidad lo cual genera los siguientes pasos:
1. El primer paso se llama Kaizen y se refiere a un sistema de mejora continua
del proceso.
El objetivo de kaizen es desarrollar un proceso que sea visible, repetible y
mensurable.
2 . El segundo paso, invocado una vez que se ha alcanzado kaizen , se llama
atarimae hinshitsu; en este paso se examina lo intangible que afecta el
proceso y se trabaja para optimizar su impacto en el proceso.
3. El tercer paso llamado kansei se centra en el usuario del software.
4. El último paso llamado miryokuteki hinshitsu amplía la preocupación de la
gestión más allá del producto inmediato; es decir el objetivo es detectar
productos nuevos y beneficiosos, o aplicaciones que sean una extensión de un
sistema ya existente basado en computadora.
Un sistema de garantía de calidad se puede definir como la estructura
organizativa, responsabilidades, procedimientos, procesos y recursos para
implementar gestión de calidad
Las normas ISO 9000
Las normas ISO9000 son la normalización al servicio de la calidad.
Los objetivos de las normas ISO-9000, son:
• Homogenizar el lenguaje relacionado con el concepto de calidad.
• Dar las líneas directrices que permitan crear un Sistema de Calidad.
Las normas de calidad aplicables al desarrollo de software son cinco:
• ISO-9000: definiciones y guías para la utilización de las normas.
• ISO-9004: enfoque operacional para poner en marcha un sistema de
calidad.
• ISO-9001, 9002 y 9003: enfoque de la calidad en situaciones contractuales
(cliente-proveedor)
• ISO 9001: diseño y desarrollo de productos
• ISO 9002: producción e instalación
• ISO 9003: control y pruebas finales, es la guía para la aplicación de la
norma ISO-9001 en el caso concreto de Productos de Software.
E. ESTRATEGIA 1. CONCEPTO Consiste en determinar los objetivos y las metas fundamentales a largo plazo,
adoptar las políticas correspondientes y asignar los recursos necesarios para
llegar a esas metas.6
6 Estrategia,Diseño y Ejecución, José Nicolás Marín y Eduardo Luis Montiel,.
Se supone que la estrategia realmente abarca todas las actividades críticas de
una empresa; ofrece un sentido de unidad, dirección y propósito y facilita a la
empresa a asimilar los cambios de entorno.
El significado del término estrategia, proviene de la palabra griega Strategos,
jefes de ejército; tradicionalmente utilizada en el terreno de las operaciones
guerreras. En los últimos años el concepto de estrategia ha evolucionado de
manera tal que, sobre la base de este ha surgido una nueva escuela de
administración y una nueva forma de dirigir a las organizaciones, llamada
“administración estratégica”.
El empleo del término estrategia en administración significa mucho más que las
acepciones militares del mismo. Para los militares, la estrategia es sencillamente
la ciencia y el arte de emplear la fuerza armada de una nación para conseguir
fines determinados por sus dirigentes.
La estrategia en administración, es un término difícil de definir y muy pocos
autores coinciden en el significado de la estrategia. Pero la definición de
estrategia surge de la necesidad de contar con ella.
Por estrategia para la administración básicamente se entiende la adaptación de
los recursos y habilidades de la organización al entorno cambiante, aprovechando
oportunidades y evaluando riesgos en función de objetivos y metas.
2. DIMENSIONES DE LA ESTRATEGIA 2.1 La estrategia como pauta coherente, unificadora e integradora de las
decisiones. Fuerza principal para un plan detallado, completo e integrador.
Como tal, la estrategia da origen a planes que garantizan el logro de los
objetivos básicos de la empresa. Esto supone que la estrategia es consistente,
explícita, proactiva.
2.2 La estrategia como medio para establecer objetivos a largo plazo, programas
de acción y prioridades en la distribución de recursos. Esta opinión clásica
considera la estrategia como el medio de hacer explícitas las metas u objetivos
de una organización en el largo plazo; de definir los principales programas de
acción que se necesitan para alcanzar sus objetivos y de asignar los recursos
necesarios.
Para que éste concepto resulte útil, se necesita primero que los objetivos
empresariales a largo plazo, una vez establecidos no se modifiquen, a menos
que sea indispensable; sí se cambiaran frecuentemente, el valor de este
enfoque disminuiría. Nada puede ser más debilitante para una empresa que la
reorientación errática de sus objetivos sin razones de peso. Los cambios
continuos de dirección estratégica crean confusión entre los que tienen
intereses en una empresa, sobre todo entre sus clientes, empleados y
accionistas.
Para alcanzar la eficacia estratégica es necesaria la concordancia entre los
objetivos, programas estratégicos y la asignación de recursos
globales ( humanos, financieros, tecnológicos y físicos ).
2.3 La estrategia como definición del ámbito en el que va a competir la empresa.
Desde hace tiempo se ha reconocido que una de las inquietudes principales,
con relación a la estrategia, es determinar las actividades a que la empresa se
dedica, o puede dedicarse. Este concepto exige que los estrategas adopten
las decisiones de crecimiento, diversificación y posicionamiento.
Un paso clave es la segmentación apropiada de la empresa. Esta
segmentación es crucial en el análisis empresarial, el posicionamiento
estratégico, la asignación de recursos y la administración de cartera.
También ayuda a identificar explícitamente el campo de acción: dónde y cómo
va a competir la empresa.
2.4 La estrategia como respuesta a las oportunidades y amenazas externas, a las
fortalezas y debilidades internas, para alcanzar la ventaja competitiva.
Según ésta perspectiva, el propósito básico de la estrategia es alcanzar una
ventaja sobre los competidores claves, sostenible a largo plazo. Tal punto de
vista, sustentado por la mayor parte de los enfoques analíticos modernos
reconoce lo siguiente:
a. El objetivo fundamental de una empresa es alcanzar la ventaja competitiva
a largo plazo sobre sus competidores. Estas ventajas presuponen
comprender a cabalidad los factores externos e internos, que afectan
profundamente a la organización. Externamente, una empresa debe
reconocer el atractivo y las tendencias relativas de su industria y las
características de los principales competidores. Esto ayuda a descubrir las
oportunidades y amenazas con las cuales se debe enfrentar. Internamente
una empresa debe identificar sus capacidades competitivas.
b. La estrategia busca una concordancia viable entre el ambiente externo de
la empresa y sus capacidades internas. El papel de la estrategia no se
considera simplemente como una reacción pasiva a las oportunidades y
amenazas que le presenta el entrono, sino de la organización, para
satisfacer las exigencias de un entorno continuamente cambiante.
2.5 La estrategia como sistema lógico para diferenciar las tareas gerenciales en
los niveles corporativos, empresarial, y funcional. Los diversos niveles
jerárquico gerenciales muy diferentes que la estrategia debe reflejar.
a. El nivel corporativo, es responsable de las tareas de mayor alcance:
definir la misión global de la empresa; examinar las propuestas de negocios;
identificar y explotar los nexos entre las unidades empresariales diferentes,
aunque relacionadas, y asignar los recursos con un sentido de prioridad
estratégica.
b. El nivel empresarial, es responsable de realzar la posición competitiva de
cada unidad empresarial frente a un medio ambiente y a la competencia.
c. El nivel funcional, es responsable de desarrollar capacidades en áreas
claves como finanzas, infraestructura administrativa, recursos humanos,
tecnología, proveeduría, logística, distribución, mercadeo, ventas y servicios.
Además de desarrollar estas capacidades es responsable de integrarlas
armoniosamente.
2.6 La estrategia es la expresión de los beneficios, económicos y no económicos,
que la empresa pretende dar a los grupos de interés. La estrategia consiste
en encargarse de los que tienen interés en esa compañía. En una
organización con fines de lucro, el resultado financiero es un objetivo
importante.
3. EL ANÁLISIS FODA
El análisis FODA es una herramienta que permite conformar un cuadro de la
situación actual de la empresa u organización, permitiendo de esta manera
obtener un diagnóstico preciso que permita en función de ello tomar decisiones
acordes con los objetivos y políticas formulados.
El término FODA es una sigla conformada por las primeras letras de las palabras
Fortalezas, Oportunidades, Debilidades y Amenazas (en inglés SWOT: Strenghts,
Weaknesses, Oportunities, Threats). De entre estas cuatro variables, tanto
fortalezas como debilidades son internas de la organización, por lo que es posible
actuar directamente sobre ellas. En cambio las oportunidades y las amenazas son
externas, por lo que en general resulta muy difícil poder modificarlas.
• Fortalezas: son las capacidades especiales con que cuenta la empresa, y
por lo que se posiciona en un lugar privilegiado frente a la competencia.
Recursos que se controlan, capacidades y habilidades que se poseen,
actividades que se desarrollan positivamente.
• Oportunidades: son aquellos factores que resultan positivos, favorables,
explotables, que se deben descubrir en el entorno en el que actúa la
empresa, y que permiten obtener ventajas competitivas.
• Debilidades: son aquellos factores que provocan una posición desfavorable
frente a la competencia, recursos de los que se carece, habilidades que no
se poseen, actividades que no se desarrollan positivamente.
• Amenazas: son aquellas situaciones que provienen del entorno y que
pueden llegar a atentar incluso contra la permanencia de la organización.
FODA es un concepto muy simple y claro, pero detrás de su simpleza residen
conceptos fundamentales de la Administración.
Se tiene un objetivo: convertir los datos del universo (según se perciba ) en
información, procesada y lista para la toma de decisiones (estratégicas en este
caso). En términos de sistemas, se tiene un conjunto inicial de datos (universo a
analizar), un proceso (análisis FODA) y un producto, que es la información para la
toma de decisiones (el informe FODA que resulta del análisis FODA).
![ManualUsuario Ruter Telefonica Vista Amper 7868[1]](https://img.pdfslide.es/doc/110x75/5571fa7a4979599169924dab/manualusuario-ruter-telefonica-vista-amper-78681.jpg)
