Transcript Unidad_01 - Facultad de Ingeniería

Universidad Nacional de la Patagonia San Juan Bosco
Facultad de Ingeniería
Cátedra: Análisis y Diseño de Sistemas
Unidad 1: Software y Sistemas
•
Introducción
– Actualmente, el software ha superado al hardware como la clave de
muchos sistemas basados en computadoras. Tanto si se utiliza la
computadora para llevar un negocio, controlar un producto o capacitar
un sistema, el software es el factor que marca la diferencia. Lo que
diferencia a una compañía de su competidora es la suficiencia y
oportunidad de la información dada por el software (y las bases de
datos relacionales).
– Un sistema puede ser definido como un conjunto interrelacionado de
componentes que se ven como un todo y trabajan juntos para realizar
una función común o alcanzar un objetivo. Constituye una
combinación compleja de recursos tales como seres humanos,
materiales, equipos, hardware (HW), software (SW), datos, etc.
•
Importancia del Software
– Durante las tres primeras décadas de la informática, el principal
desafío era el desarrollo de hardware, de forma que se redujera el
costo de procesamiento y almacenamiento de datos.
– Hoy, el problema es diferente. El principal desafío es mejorar la calidad
(y reducir el costo) de las soluciones basadas en computadoras,
soluciones que se implementan con el software.
2
•
La evolución del Software – Primera Era (1950-1965 aprox.)
– Durante los primeros años de desarrollo de las computadoras, el
hardware sufrió continuos cambios, mientras que el software se
contemplaba simplemente como un añadido.
– Existían pocos métodos sistemáticos para la programación.
– El desarrollo del software se realizaba virtualmente sin planificación,
hasta que los planes comenzaron a descalabrarse y los costos a crecer.
– Durante este período se utilizaba la orientación por lotes en la
mayoría de los sistemas.
– Lo normal era que el HW fuera de propósito general.
– El SW se diseñaba a medida para cada aplicación y tenía una
distribución relativamente pequeña.
– La mayoría del SW se desarrollaba y era utilizado por la misma
persona u organización. La misma persona lo escribía, lo ejecutaba
y si fallaba, lo depuraba.
3
•
La evolución del Software – Segunda Era (1965-1975 aprox.)
– En la segunda era de la evolución de los sistemas de computadora, la
multiprogramación y los sistemas multiusuario introdujeron
nuevos conceptos de interacción hombre-máquina.
– Las técnicas interactivas abrieron un nuevo mundo de aplicaciones
y nuevos niveles de sofisticación del HW y del SW.
– Los sistemas de tiempo real podían recoger, analizar y transformar
datos de múltiples fuentes, controlando así los procesos y produciendo
salidas en milisegundos en lugar de en minutos.
– La segunda era se caracterizó también por el establecimiento del
software como producto y la llegada de las casas de SW. El SW ya
se desarrollaba para tener una amplia distribución. Todos esos
programas tenían que ser corregidos cuando se detectaban fallos,
modificados cuando cambiaban los requisitos de los usuarios o
adaptados a nuevos dispositivos de HW que se hubieran adquirido.
Estas actividades se llamaron mantenimiento de software.
– El esfuerzo gastado en el mantenimiento de SW comenzó a absorber
recursos en una medida alarmante. Aún peor, la naturaleza
personalizada de muchos programas los hacía virtualmente imposibles
de mantener. Había comenzado una crisis del software.
4
•
La evolución del Software – Tercer Era (1975-1985 aprox.)
– La tercer era se caracteriza por el procesamiento distribuido.
– Procesamiento distribuido: varias computadoras, cada una ejecutando
funciones concurrentemente y comunicándose con alguna otra.
– Incrementó la complejidad de los sistemas informáticos.
– Las redes de área local y de área global, las comunicaciones digitales
supusieron una fuerte presión sobre los desarrolladores de software.
– La tercera era también se caracteriza por la llegada y el amplio uso de
los microprocesadores y las computadoras personales.
– El hardware de las computadoras se ha convertido rápidamente en un
producto estándar, mientras que el software que se suministre con
ese hardware, es lo que marca la diferencia.
5
•
La evolución del Software – Cuarta Era (1985-2000 aprox.)
– La cuarta era del software está empezando ahora.
– Las tecnologías orientadas a los objetos están desplazando
rápidamente a los enfoques de desarrollo de software más
convencionales en muchas áreas de aplicación.
– Las técnicas de cuarta generación para el desarrollo de software ya
están cambiando la forma en que algunos segmentos de la comunidad
informática construyen los programas de computadora.
– Conforme
nos
movemos
en
la
Cuarta
era,
continúan
intensificándose los problemas asociados con el SW de
computadoras:
 La sofisticación del HW ha dejado desfasada nuestra capacidad de
construir SW que pueda explotar el potencial del HW.
 Nuestra capacidad de construir nuevos programas de aplicación no
puede dar abasto a la demanda de nuevos programas.
 Nuestra capacidad de mantener programas existentes está
amenazada por el mal diseño y el uso de recursos inadecuados.
– Como respuesta a la crisis del software, muchas industrias están
adoptando prácticas de Ingeniería de software.
6
•
La evolución del Software – Etapa actual (principios del tercer
milenio)
– Componentes y arquitecturas software reutilizables
– Web semántica: Web extendida y basada en el significado, se apoya
en lenguajes universales
– Computación ubicua: integración de la informática en el entorno de la
persona
– Interfaces multimodales: es un mismo servicio que se presta
independientemente de la terminal por la que se accede
•
Problemas persistentes en la evolución
–
–
–
–
•
El SW nunca explota las posibilidades plenas del HW
El desarrollo del SW no es tan rápido como su demanda
La sociedad depende de las computadoras y necesitamos SW fiable
Los programas no son escalables ni mantenibles por culpa de diseños
pobres y recursos inadecuados
¿Aumentan estos problemas?
7
El Software - Definición
•
–
Existen varias definiciones según Pressman, algunas serían:
1.
Instrucciones (programas de computadora) que cuando se ejecutan
proporcionan una función y el comportamiento deseado
Estructuras de datos que facilitan a los programas manipular
adecuadamente la información
Documentos que describen la operación y el uso de programas
2.
3.

Para poder comprender lo que es el software es importante
examinar las características que lo diferencian de otras cosas que
los hombres pueden construir.
8
El Software – Características
•
–
1.
–
2.
3.
El SW es un elemento del sistema que es lógico, en lugar de físico.
Por lo tanto, tiene características considerablemente distintas a las
del HW:
El Software se desarrolla, no se fabrica en el sentido clásico
Ambas actividades requieren la construcción de un producto, pero
los métodos son diferentes. Los costes del software se encuentran
en la ingeniería.
El Software no se estropea, se deteriora
La mayoría del software se construye a medida, en vez de
ensamblar componentes existentes.
Según Pressman:
•
–
–
–
Curva de fallos del Hardware.
Curva ideal de fallos del Software.
Curva real de fallos del Software.
9
Curvas de Fallos - Curva de Fallos del HW
•
La figura siguiente describe para el HW, la proporción de fallos como
una
función
del
tiempo.
Esa
relación,
es
denominada
frecuentemente “curva de la bañera”.
–
Estropeado
Defectos fabricación
Indice de fallos
Obsolescencia
Tiempo
10
Curvas de Fallos (Cont.) - Curva idealizada de fallos del software
– El SW no es susceptible a los males del entorno que hacen que el HW
se estropee. Por lo tanto, en teoría, la curva de fallos para el SW
tendría la forma que muestra la siguiente figura.
– Los defectos no detectados harán que falle el programa durante las
primeras etapas de su vida. Una vez que se corrigen y suponiendo que
no se introducen nuevos errores, la curva se aplana. Esa figura es una
gran simplificación de los modelos reales de fallos de SW. Sin embargo
la implicación es clara, el SW no se estropea. ¡Pero se deteriora!
Defectos fabricación
Indice de fallos
•
Obsolescencia
Mismo nivel hasta obsoleto
Tiempo
11
Curvas de Fallos (Cont.) - Curva real de fallos del software
•
–
–
Durante su vida, el software sufre cambios (mantenimiento).
Conforme se hacen los cambios, es bastante probable que se
introduzcan nuevos defectos, haciendo que la curva de fallos tenga
picos como se ve en la figura.
Defectos fabricación
Indice de fallos
Cambio
Cambio
Cambio
Obsolescencia
Curva ideal
12
•
Componentes del Software
– Las componentes del software se crean mediante una serie de
traducciones que hacen corresponder los requisitos del cliente con
un código ejecutable en la máquina.
– Se traduce un modelo de requisitos (Prototipo) a un diseño. Se
traduce el diseño del software a una forma de lenguaje que especifica
las estructuras de datos, los atributos procedimentales y los requisitos
que atañen al software. La forma en lenguaje es procesada por un
traductor que la convierte en instrucciones ejecutables en máquina.
– La reusabilidad es una característica importante para un componente
de software de alta calidad. Es decir, el componente debe diseñarse e
implementarse para que pueda volver a usarse en otros programas
diferentes.
– Los componentes de software se construyen mediante un lenguaje de
programación que tiene un vocabulario limitado, una gramática
definida explícitamente y reglas bien formadas de sintaxis y
semántica.
13
•
Aplicaciones del software
– El SW puede aplicarse en cualquier situación en la que se haya
definido
previamente
un
conjunto
específico
de
pasos
procedimentales.
– Para determinar la naturaleza de una aplicación de SW hay dos
factores importantes que se deben considerar: el contenido y el
determinismo de la información:
 El contenido se refiere al significado y a la forma de la
información de entrada y salida.
 El determinismo de la información se refiere a la predecibilidad
del orden y el tiempo de llegada de datos.
•
Software de Sistemas
– El SW de sistemas es un conjunto de programas que han sido escritos
para servir a los otros programas. P.e. compiladores, editores y
utilidades de gestión de archivos.
– Algunas características son:
 Fuerte interacción con el HW
 Operación concurrente
 Recursos compartidos
 Gestión de procesos complicada
 Estructura de datos complejas
14
•
Software de Tiempo Real
– El SW que mide, analiza, controla sucesos del mundo real conforme
ocurren, se denomina de Tiempo Real.
– Entre los elementos del SW de Tiempo Real se incluyen:
 Un componente de adquisición de datos que recolecta y da
formato a la información recibida del entorno externo
 Un componente de análisis que transforma la información según
lo requiera la aplicación
 Un componente de control/salida que responda al entorno
externo
 Un componente de monitorización que coordina todos los demás
componentes, de forma que pueda mantenerse la respuesta en
tiempo real
– Algunas características son:
 Tiempo de respuesta crítico: magnitud de milisegundos
 Interacción directamente con dispositivos físicos y sensores
 Requisitos de rendimiento críticos
 Programación de bajo nivel
 Concurrencia
15
•
Software de Gestión
– El procesamiento de información comercial constituye la mayor de las
áreas de aplicación de SW.
– Algunos ejemplos son:
 Proceso de información comercial (nóminas, clientes, inventarios):
manejan gran volumen de datos, complejidad de la información
 Sistemas transaccionales: soportan las operaciones diarias de un
negocio (pedidos, compras, etc.); los requisitos, los datos y el
procesamiento se conoce y está bien estructurado
 Análisis
de
datos:
Aplicaciones
de
consultas
(query),
Datawarehouse (almacenamiento de versiones históricas de
entradas a la base de datos, registros de transacciones y datos
históricos)
 Soporte a la toma de decisiones: herramienta de usuario final,
análisis “what – if”, estadísticas, tendencias, etc.
 Software de computadoras personales: herramientas de escritorio,
SW para ocio, etc.
 Aplicaciones Web: SW accedido a través de un browser
16
•
Software de Ingeniería y Científico
– El SW de ingeniería y científico está caracterizado por los algoritmos
de manejo de números. Van desde la astronomía a la vulcanología.
– Algunas características son:
 Algoritmos de tratamiento numérico: simulación, estadística, CAD
 Diseño de algoritmos y estructuras de datos
 Cálculo intensivo
 Paralelización
•
Software Empotrado
– Los productos inteligentes se han convertido en algo común en casi
todos los mercados de consumo e industriales.
– El SW empotrado reside en memoria de sólo lectura y se utiliza
para controlar productos y sistemas de los mercados industriales y de
consumo. P.e. el control de las teclas de un horno de microondas.
17
•
Software de Computadoras Personales
– El mercado del SW de las computadoras personales ha germinado en
la tercer era.
 El procesamiento de textos
 Las hojas de cálculo
 Los gráficos por computadora
 Entretenimientos
 Gestión de bases de datos
 Aplicaciones financieras, de negocios y personales
 Redes o acceso a bases de datos externas son sólo algunas de
cientos de aplicaciones.
•
Software de Inteligencia Artificial
– El software de inteligencia artificial (IA) hace uso de algoritmos no
numéricos para resolver problemas complejos para los que no son
adecuados el cálculo o el análisis directo.
– Algunos ejemplos son:
 Sistemas expertos
 Reconocimiento de patrones
 Demostradores de teoremas
18
•
Crisis del Software
– Muchos observadores de la industria han caracterizado los problemas
asociados con el desarrollo del SW como una crisis. Sin embargo, lo
que realmente tenemos puede ser algo bastante diferente.
– Si hablamos de crisis del SW, el término alude a un conjunto de
problemas que aparecen en el desarrollo del SW de computadoras.
– Cabe aclarar que los problemas no se limitan al SW que no funciona
correctamente.
– El mal abarca los problemas asociados a:
 Cómo desarrollar software
 Cómo mantener el volumen cada vez mayor de software existente
 Cómo poder esperar mantenernos al corriente de la demanda
creciente de software.
– Aunque se puede criticar la referencia a crisis, las frases resultan útiles
por referirse a verdaderos problemas que se encuentran en todas las
áreas del desarrollo del SW.
19
Problemas
•
–
Los problemas que afligen al desarrollo del software se pueden
caracterizar bajo muchas perspectivas diferentes, pero los
responsables de los desarrollos de software se centran sobre los
aspectos de fondo:
1.
La planificación y estimación de costos son frecuentemente muy
imprecisas
La productividad de la comunidad del software no se corresponde
con la demanda de sus servicios
La calidad del software no llega a veces a ser aceptable
2.
3.
20
•
Problemas (Cont.)
– Tales problemas son sólo las manifestaciones más visibles de otras
dificultades del software:
 No tenemos tiempo de recoger datos sobre el proceso de
desarrollo del software. Sin datos históricos como guía, la
estimación no ha sido buena y los resultados previstos muy
pobres. Sin una indicación sólida de la productividad, no podemos
evaluar con precisión la eficacia de las nuevas herramientas,
técnicas o estándares.
 La insatisfacción del cliente con el sistema terminado se
produce demasiado frecuentemente. Los proyectos de desarrollo
del SW se acometen frecuentemente con sólo una vaga indicación
de los requisitos del cliente. Normalmente, la comunicación entre
el cliente y el que desarrolla el SW es muy escasa.
 La calidad del software es normalmente cuestionable. Hemos
empezado a comprender recientemente la importancia de la
prueba sistemática y técnicamente completa del SW.
 El SW existente puede ser muy difícil de mantener. La tarea de
mantenimiento del SW se lleva la mayor parte de todo el dinero
invertido en el SW. El mantenimiento no se ha considerado un
criterio importante en la aceptación del SW.
– Todos los problemas pueden corregirse  Enfoque de ingeniería al
desarrollo del software, junto con la mejora continua de las
técnicas y de las herramientas.
21
•
Causas
– Los problemas asociados con la crisis de SW se han producido por el
propio carácter del SW y por los errores de las personas encargadas
del desarrollo del mismo.
– El SW es un elemento lógico y por lo tanto, el éxito se mide por la
calidad de una única entidad en vez de por muchas entidades
fabricadas. El SW no se rompe. Si se encuentran fallos, lo más
probable es que se introdujeran inadvertidamente durante el
desarrollo y no se detectaran durante la prueba. Reemplazamos las
partes defectuosas durante el mantenimiento, pero tenemos muy
pocas piezas de repuesto, incluso ninguna  el mantenimiento incluye
normalmente la corrección o modificación de diseño.
– Frecuentemente, los responsables del desarrollo del SW han sido
ejecutivos de nivel medio y alto, sin conocimiento de SW. Un antiguo
axioma de gestión dice: Un buen gestor puede gestionar cualquier
proyecto si está dispuesto a aprender nuevas técnicas que pueden
utilizarse para medir el desarrollo del proyecto, a aplicar métodos
efectivos de control, a ignorar la mitología y a llegar a conocer la
tecnología que cambia rápidamente.
– Todos nos resistimos al cambio. Sin embargo, es verdaderamente
irónico que, mientras el potencial de cálculo (HW) experimenta
enormes cambios, la gente de SW, responsable de aprovechar dicho
potencial, se oponga a los cambios cuando se discuten y se resista al
cambio cuando se introduce. Puede que ésta sea la causa real de la
22
crisis del SW.
•
Mitos del Software
– Las actitudes y hábitos son difíciles de modificar y, cuando vamos
hacia la quinta década del SW, todavía se cree en algunos de los mitos
del SW.
•
Mitos de Gestión
– Mito: Tenemos un libro que está lleno de estándares y procedimientos
para construir SW. ¿No le brinda a mi gente lo que necesita saber?
– Realidad: Está muy bien que el libro exista, pero ¿se usa? ¿Conocen
los trabajadores su existencia? ¿Refleja las prácticas modernas de
desarrollo de software? ¿Es completo? En muchos casos, la respuesta
a todas esas preguntas es NO.
– Mito: Nuestra gente dispone de las herramientas de desarrollo de
software más avanzadas  les compramos las PC’s más nuevas.
– Realidad: Se necesita mucho más que el último modelo de
computadora para desarrollar SW de gran calidad.
– Mito: Si fallamos en la planificación podemos añadir más
programadores y recuperar el tiempo perdido.
– Realidad: El desarrollo de SW no es un proceso mecánico. Añadir
gente a un proyecto de SW retrasado, lo retrasa aún más. Cuando se
añaden nuevas personas, la necesidad de aprender y comunicarse con
el equipo puede y hace que se reduzca la cantidad de tiempo gastado
en el desarrollo productivo. Puede añadirse gente, pero sólo de una
manera planificada y bien coordinada.
23
•
Mitos del Cliente
– Mito: Una declaración general de los objetivos es suficiente para
comenzar a escribir los programas
– Realidad: Una mala definición inicial es la principal causa del trabajo
baldío en SW. Es esencial una descripción formal y detallada del
ámbito de la información, funciones, rendimiento, interfaces, ligaduras
del diseño y criterios de validación. Estas características pueden
determinarse sólo después de una exhaustiva comunicación entre el
cliente y el analista.
– Mito: Los requisitos del proyecto cambian continuamente, pero los
cambios pueden acomodarse fácilmente, ya que el SW es flexible.
– Realidad: Es verdad que los requisitos del SW cambian, pero el
impacto del cambio varía según el momento en que se introduzca.
Impacto
de Cambio
Definición
Desarrollo
Después de la Entrega
24
•
Mitos del Desarrollador
– Mito: Una vez que escribimos el programa y hacemos que funcione,
nuestro trabajo ha terminado.
– Realidad: Alguien dijo una vez Cuanto más pronto se comience a
escribir código, más se tardará en terminarlo. Entre el 50% y el
70% de todo el esfuerzo dedicado a un programa se realizará después
de que se le haya entregado el SW al cliente por primera vez.
– Mito: Hasta que no tengo el programa ejecutándose, realmente no
tengo forma de comprobar su calidad.
– Realidad: Desde el principio del proyecto se puede aplicar uno de los
mecanismos más efectivos para garantizar la calidad del SW, la
revisión técnica formal. La revisión del SW es un filtro de calidad
que se ha comprobado que es más efectivo que la prueba para
encontrar ciertas clases de defectos de SW.
– Mito: Lo único que se entrega al terminar el proyecto es el programa
funcionando.
– Realidad: Un programa que funciona es sólo una parte de una
configuración del SW que incluye todos los elementos como: el plan, la
especificación
de requisitos, diseño,
estructuras
de datos,
especificación de prueba.
 El reconocimiento de las realidades del SW es el primer paso hacia la
formulación de soluciones prácticas para su desarrollo.
25
Atributos de un buen producto de SW
•
–
Así como los servicios que proveen, los productos de SW tienen un
cierto número de atributos asociados que reflejan la calidad de ese
software. Estos atributos no están directamente asociados con lo
que el software hace. Más bien, reflejan su comportamiento durante
su ejecución, en la estructura y organización del programa fuente y
en la documentación asociada.
–
El conjunto específico de atributos que se espera de un sistema de
software depende obviamente de su aplicación. Esto se generaliza
en el conjunto de atributos que se describe a continuación, el cual
tiene las características esenciales de un sistema de software bien
diseñado.
–
Existen diferentes aspectos de calidad:
 Interna: medible a partir de las características intrínsecas,
como el código fuente
 Externa: medible en el comportamiento del producto, como en
una prueba. Son los atributos más difíciles, ya que no pueden
ser medidos de manera directa.
26
•
Atributos de un buen producto de SW (Cont.)
1.
Factores Externos: Detectados por los usuarios. Son los factores
que realmente interesan (objetivo):






Facilidad de mantenimiento: debe poder evolucionar para
adaptarse a las necesidades de cambio de los clientes
Confiabilidad: no debe causar daños físicos o económicos en el
caso de fallo del sistema. Fiabilidad, seguridad y protección
Eficiencia: capacidad del SW para proporcionar un desempeño
apropiado, en relación con la cantidad de recurso utilizado, bajo
condiciones establecidas
Usabilidad: Esfuerzo necesario para aprender, operar, preparar
entradas e interpretar la salida de un programa. Debe tener una
interfaz de usuario apropiada y documentación adecuada
Reusabilidad: capacidad de que un SW pueda utilizarse en un
contexto diferente al de su creación
Portabilidad: facilidad de transferir productos SW a diferentes
plataformas
27
•
Atributos de un buen producto de SW (Cont.)
2.
Factores Internos: Únicamente percibidos por los desarrolladores.
Son un medio para conseguir la calidad externa:









Facilidad de traza
Modularidad
Tolerancia a fallos
Eficiencia de ejecución
Eficiencia de almacenamiento
Legibilidad
Facilidad de expansión
Independencia del sistema y HW
Estandarización de datos y comunicaciones
28
•
Paradigmas de la Ingeniería de Software
– El mal que ha infectado el desarrollo del SW no va a desaparecer de la
noche a la mañana.
– Reconocer los problemas y sus causas y demoler los mitos del SW son
los primeros pasos hacia las soluciones. Pero las propias soluciones
tienen que:
 Proporcionar asistencia práctica a la persona que desarrolla SW
 Mejorar la calidad del software
 Permitir al mundo del SW mantenerse en paz con el mundo del
HW
– No existe un único enfoque mejor para solucionar el mal del SW. Sin
embargo, podemos conseguir una disciplina para el desarrollo del
software  llamada Ingeniería del Software:
 Mediante la combinación de métodos completos para todas las
fases del desarrollo del SW
 Mejores herramientas para automatizar estos métodos
 Bloques de construcción más potentes para la implementación del
SW
 Mejores técnicas para la garantía de calidad de software
 Una filosofía predominante para la coordinación, control y gestión
29
•
Ingeniería de software – Definición
– La ingeniería del software (IS) surge de la ingeniería de sistemas y
de HW. Abarca un conjunto de tres elementos clave:
 Métodos
 Herramientas
 Procedimientos
– Estos tres elementos facilitan al gestor controlar el proceso del
desarrollo del software y suministrar a los que practiquen dicha
ingeniería las bases para construir SW de alta calidad de una forma
productiva.
– En los párrafos que siguen, examinaremos brevemente cada uno de
estos elementos.
30
•
Ingeniería de software – Definición (Cont.)
– Los métodos de la ingeniería de software indican cómo construir
técnicamente el software.
– Abarcan un amplio espectro de tareas que incluyen:
 Planificación y estimación de proyectos
 Análisis de requerimientos del sistema y del software
 Diseño de estructuras de datos, arquitectura de programas y
procedimientos algorítmicos
 Codificación
 Prueba
 Mantenimiento
– Los métodos de la ingeniería de software introducen frecuentemente
una notación especial orientada a un lenguaje o gráfica y un
conjunto de criterios para calidad de SW. En resumen el método
consiste en:
 Formulación del problema
 Análisis del problema
 Búsqueda de soluciones
 Elección de la solución más adecuada
 Especificación de la solución
31
•
Ingeniería de software – Definición (Cont.)
– Las herramientas de la IS suministran un soporte automático o
semiautomático para los métodos. Hoy existen herramientas para
soportar cada uno de los métodos mencionados anteriormente.
– Los procedimientos de la IS son el pegamento que junta los métodos
y las herramientas y facilita un desarrollo racional y oportuno del SW.
Los procedimientos definen la secuencia en la que se aplican los
métodos, las entregas (documentos, informes, etc.), los controles que
ayudan a asegurar la calidad y coordinar los cambios, y las directrices
que ayudan a los gestores del SW a evaluar el progreso.
– La IS está compuesta por una serie de pasos que abarcan los
métodos, las herramientas y los procedimientos antes mencionados.
Estos pasos se denominan frecuentemente Paradigmas de la IS. La
elección de un paradigma para la IS se lleva a cabo de acuerdo con la
naturaleza del proyecto y de la aplicación, los métodos y herramientas
a usar y los controles y entregas requeridos.
– El trabajo que se asocia a la IS se puede dividir en tres fases
genéricas:
Definición,
Desarrollo
y Mantenimiento.
Con
independencia del área de aplicación, tamaño o complejidad del
proyecto. Cada fase se enfrenta con una o varias cuestiones de las
destacadas anteriormente.
32
•
Fases de la IS
– La Fase de Definición se centra sobre el qué. Es decir, durante la
definición, quien desarrolla el SW intenta identificar qué información
ha de ser procesada, qué función y rendimiento se desea, qué
comportamiento del sistema, qué interfases van a ser establecidas,
qué restricciones de diseño existen, y qué criterios de validación se
necesitan para definir el sistema correcto. Aunque los métodos
dependen del paradigma, las tareas principales son: ingeniería de
sistemas (o de información), la planificación del proyecto de SW y el
análisis de los requisitos.
– La Fase de Desarrollo se centra en el cómo. Es decir, durante el
desarrollo un ingeniero de software intenta definir cómo han de
diseñarse las estructuras de datos, cómo ha de implementarse la
función como una arquitectura del SW, cómo han de implementarse
detalles procedimentales, cómo ha de realizarse la prueba. Las tareas
son: diseño del SW, generación de código y prueba de SW.
– La Fase de Mantenimiento se centra en el cambio asociado a la
corrección de errores (correctivo), a las adaptaciones requeridas a
medida que evoluciona el entorno de del software (adaptativo), a
cambios debidos a las mejoras producidas por requisitos cambiantes
del cliente (perfectivo) y a mejoras en las características internas del
producto para hacerlo más mantenible (preventivo).
33
•
Herramientas CASE
– Son herramientas que combinan software, hardware y bases de datos
de la ingeniería de software para crear un entorno que facilite el
desarrollo del software. Ofrecen soporte al proceso SW automatizando
algunas de sus actividades.
– En cuanto a la clasificación de las herramientas CASE, Sommerville
establece que se pueden realizar diferentes clasificaciones en función
de diversas perspectivas:
 Perspectiva funcional: se clasifican de acuerdo a su función
específica en herramientas de planificación, herramientas de
soporte, herramientas de documentación, etc.
 Perspectiva de proceso: se clasifican de acuerdo a las
actividades del proceso SW que soportan.
 Perspectiva de integración: se clasifican de acuerdo a cómo se
organizan en unidades de integración que ofrecen soporte a una o
más actividades del proceso SW.
34
•
Beneficios de las herramientas CASE
– Facilitan la verificación y mantenimiento de la consistencia de la
información
– Facilitan el establecimiento de estándares en el proceso de desarrollo y
documentación
– Facilitan el mantenimiento del sistema y las actualizaciones de su
documentación
– Facilitan la aplicación de las técnicas de una metodología
– Brindan disponibilidad de funciones automatizadas tales como:
obtención de prototipos, generación de código, generación de
pantallas e informes, generación de diseños físicos de bases de datos,
verificadores automáticos de consistencia
– Facilitan la aplicación de técnicas de reutilización y reingeniería
– Facilitan la planificación y gestión de los proyectos
35
•
Ciclos de vida del desarrollo de software
– El Ciclo de Vida del Desarrollo de software es un proceso por el cual
los analistas de sistemas, los ingenieros de software, los
programadores y los usuarios finales (stakeholders) elaboran sistemas
de información y aplicaciones informáticas.
– Para realizar un efectivo análisis de sistemas necesitamos
herramientas de modelización  métodos.
– Los propósitos de tener un ciclo de vida del proyecto son:
 Definir las actividades a realizar en el proyecto de desarrollo del
sistema.
 Lograr consistencia entre los distintos proyectos de desarrollo en la
misma organización.
 Proveer puntos de control al administrador del proyecto que lo
guíen en la toma de decisiones.
36
•
Tipos de modelos de procesos - Modelo Lineal o Secuencial: Ciclo
de Vida Clásico
– Han sido ampliamente utilizados:
 Ofrecen grandes facilidades a los gestores para controlar el
progreso de los proyectos
 Proponen un enfoque sistemático, secuencial, para el desarrollo
del SW
 Comienza en un nivel de sistemas y progresa con el análisis,
diseño, codificación, pruebas y mantenimiento
 Fases separadas en la especificación y el desarrollo
– La filosofía de estos modelos de proceso no es realista:
 No se ajusta al proceso de desarrollo de SW
 Raramente sigue un flujo secuencial sino que exige diversas
iteraciones
 No ofrece un soporte adecuado a las técnicas de desarrollo
basadas en objetos y componentes
37
•
Tipos de modelos de procesos – Ciclo de Vida Clásico
– También llamado modelo en cascada, exige un enfoque sistemático y
secuencial del desarrollo del software que comienza en un nivel del
sistema y progresa a través del análisis, diseño, codificación, prueba y
mantenimiento.
– Modelizado a partir del ciclo de vida de una ingeniería, el paradigma
del ciclo de vida abarca las siguientes actividades:
 Ingeniería y análisis de sistemas: Debido a que el software es
siempre parte de un sistema mayor, el trabajo comienza estableciendo
los requisitos de todos los elementos del sistema y luego asignando
algún subconjunto de estos requisitos al software. La ingeniería y el
análisis de sistemas abarca los requisitos globales del sistema con una
pequeña cantidad de análisis y de diseño a un nivel superior.
38
•
Tipos de modelos de procesos – Ciclo de Vida Clásico (Cont.)
 Análisis de los requisitos del SW: El proceso de recopilación de los
requisitos se centra e intensifica especialmente para el SW. Para
comprender la naturaleza de los programas que hay que construir, el
ingeniero de software debe comprender el ámbito de la información
del software, así como la función, el rendimiento y las interfaces
requeridas. Los requisitos, tanto del sistema como del SW, se
documentan y se revisan con el cliente.
 Diseño: El diseño de SW es realmente un proceso multipaso que se
enfoca sobre cuatro atributos distintos:
 La estructura de los datos
 La arquitectura del software
 El detalle procedimental
 La caracterización de la interfaz
El proceso de diseño traduce los requisitos en una representación del
SW que pueda ser establecida de forma que obtenga la calidad
requerida antes de que comience la codificación (SQA). El diseño se
documenta y es parte de la configuración del SW.
 Codificación: El diseño debe traducirse en una forma legible para la
máquina. El paso de codificación realiza esta tarea. Si el diseño se
realiza de una manera detallada, la codificación puede realizarse
mecánicamente.
39
•
Tipos de modelos de procesos – Ciclo de Vida Clásico (Cont.)
 Prueba: Una vez que se ha generado el código, comienza la prueba
del programa. La prueba se centra en la lógica interna del software,
asegurando que todas las sentencias se hayan probado, y en las
funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.
 Mantenimiento: El SW indudablemente sufrirá cambios después de
que se entregue al cliente. Los cambios ocurrirán debido a que se
hayan encontrado errores, a que el software debe adaptarse a
cambios de entorno externo, o debido a que el cliente requiera
ampliaciones funcionales o del rendimiento  El mantenimiento de
software aplica cada uno de los pasos precedentes del ciclo de vida a
un programa existente en vez de a uno nuevo.
40
•
Tipos de modelos de procesos – Ciclo de Vida Clásico - Problemas
 Los proyectos reales raramente siguen el flujo secuencial que propone
el modelo. Siempre hay iteraciones y se crean problemas en la
aplicación del paradigma.
 Normalmente es difícil para el cliente establecer al principio
explícitamente todos los requisitos. El ciclo de vida clásico lo requiere
y tiene dificultades en acomodar posibles incertidumbres que pueden
existir al comienzo de muchos proyectos.
 No estará disponible una versión operativa del programa hasta llegar a
las etapas finales del proyecto. Un error importante no detectado
hasta que el programa esté funcionando puede ser desastroso.
 Los responsables del desarrollo del SW siempre se retrasan
innecesariamente, ya que algunos miembros del equipo del proyecto
deben esperar a otros para completar tareas dependientes.
 Es un modelo monolítico  hasta llegar a las etapas finales del
desarrollo no habrá una versión operativa del programa, lo que influye
negativamente en el descubrimiento a tiempo de errores o
incongruencias en los requisitos.
•
Consideraciones finales
–
–
–
–
Tiene un lugar destacado en la IS
Proporciona una plantilla para adecuar otros métodos
Es muy utilizado
Tiene problemas pero es mejor que desarrollar sin guías
41
•
Tipos de modelos de procesos – Ciclo de Vida Estructurado
42
•
Tipos de modelos de procesos – Ciclo de Vida Estructurado (Cont.)
– Actividad 1: La encuesta
– Empieza cuando el usuario solicita que una o más partes de su
sistema se automaticen. Los objetivos son:
 Identificar a los usuarios responsables y crear un campo de actividad
inicial del sistema. Esto puede comprender la conducción de una serie
de entrevistas para determinar qué usuarios estarán comprendidos.
 Identificar las deficiencias actuales en el ambiente del usuario. Esto en
general comprenderá una lista de funciones que hacen falta o que se
están llevando a cabo insatisfactoriamente en el sistema actual.
 Establecer metas y objetivos para un sistema nuevo. Esto puede ser
una simple lista narrativa que contenga las funciones existentes que
deben reimplementarse, las nuevas que necesitan añadirse y los
criterios de desempeño del nuevo sistema.
 Determinar si es factible automatizar el sistema y, de ser así, sugerir
escenarios aceptables. Esto implicará algunas estimaciones bastantes
rudimentarias y aproximadas del costo y tiempo necesarios para
construir un sistema nuevo, y los beneficios que se derivarán de ello.
 Preparar el esquema que se usará para guiar el resto del proyecto.
Este esquema incluirá toda la información que se lista anteriormente,
además de identificar al administrador responsable del proyecto.
También pudiera describir los detalles del ciclo de vida que seguirá el
resto del proyecto.
43
•
Tipos de modelos de procesos – Ciclo de Vida Estructurado (Cont.)
– Actividad 2: El análisis de sistemas
– El propósito principal de la actividad de análisis es transformar sus dos
entradas principales, las políticas del usuario y el esquema del
proyecto, en una especificación estructurada.
– Actividad 3: El diseño de sistemas
– La actividad de diseño se dedica a asignar porciones de la
especificación a procesadores adecuados y a labores apropiadas
dentro de cada procesador. Dentro de cada labor, la actividad de
diseño se dedica a la creación de una jerarquía apropiada de módulos
de programas y de interfases entre ellos para implementar la
especificación creada en el análisis. Además, la actividad de diseño se
ocupa de la transformación de modelos de datos de entidad-relación
en un diseño de base de datos.
– Actividad 4: Implantación ó Implementación
– Esta actividad incluye la codificación y la integración de módulos en un
esquema progresivamente más completo del sistema final.
– Actividad 5: Generación de pruebas de aceptación
– La especificación estructurada debe contener toda la información
necesaria para definir un sistema que sea aceptable desde el punto de
vista del usuario. Por eso, una vez generada la especificación, puede
comenzar la actividad de producir un conjunto de casos de prueba de
aceptación desde la especificación estructurada.
44
•
Tipos de modelos de procesos – Ciclo de Vida Estructurado (Cont.)
– Actividad 6: Garantía de calidad
– La garantía de calidad también se conoce como la prueba final o la
prueba de aceptación. Esta actividad requiere como entradas datos de
la prueba de aceptación generada en la actividad 5 y el sistema
integrado producido en la actividad 4.
– Actividad 7: Descripción del procedimiento
– El resultado es el manual para el usuario.
– Actividad 8: Conversión de bases de datos
– En algunos proyectos, la conversión de bases de datos involucra más
trabajo que el desarrollo de programas de computadora para el nuevo
sistema. En otros casos, pudiera no haber existido una base de datos
que convertir. En caso general, esta actividad requiere como entrada la
base de datos actual del usuario, al igual que la especificación del
diseño producida por medio de la actividad 3.
– Actividad 9: Instalación
– La actividad final es la instalación, sus entradas son el manual del
usuario producido en la actividad 7, la base de datos convertida que se
creó con la actividad 8 y el sistema aceptado producido por la
actividad 6.
45
•
Tipos de modelos de procesos – Modelo V
– Es una variación del modelo en cascada que demuestra cómo se
relacionan las actividades de prueba con las de análisis y desarrollo.
Presenta una implementación ascendente.
– Se puede identificar una ventaja principal con respecto al Modelo
Cascada, y se refiere a que involucra chequeos de cada una de las
etapas del modelo de cascada.
– Demuestra que el desarrollo de las pruebas se efectúa de manera
síncrona con el desarrollo del programa. Mientras que el modelo
clásico centra su atención en los documentos y artefactos producidos,
el modelo en V lo hace en la actividad y exactitud.
– No contempla la posibilidad de retornar a etapas inmediatamente
anteriores, cosa que en la realidad puede ocurrir.
– Se toma toda la complejidad del problema de una vez y no en
iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.
46
•
Tipos de modelos de procesos – Modelos Basados en Prototipos
– Un prototipo es un modelo experimental de un sistema o de un
componente de un sistema que tiene los suficientes elementos que
permiten su uso. Es una solución parcial que describe la interacción
entre el hombre y la máquina, mostrando parte de su funcionalidad no
optimizada. Este modelo presenta un componente iterativo que facilita
involucrar a los clientes/usuarios en el desarrollo del SW para ayudar a
éstos a comprender los requisitos.
– Pueden presentar diferentes enfoques en la utilización de los
prototipos en el ciclo de vida:
 Enfoque desechable: el propósito del prototipo es validar algún
aspecto del sistema, sirviendo, como herramienta auxiliar a la
especificación de requisitos y el diseño. Este enfoque suele
derivar en un modelo lineal una vez que el prototipo ha
cumplido su misión.
 Enfoque evolutivo: el prototipo se utiliza como alternativa de
ciclo de vida. Es la base de los modelos de proceso evolutivos.
 Enfoque mixto: conocido como prototipado operativo, combina
ambos tipos de prototipos.
47
•
Tipos de modelos de procesos – Ciclo de vida de Prototipos
– Un cliente a menudo define un conjunto de objetivos generales para el
software pero no identifica los requisitos detallados de entrada,
procesamiento o salida. En otros casos, el responsable del desarrollo
del software puede no estar seguro de la eficacia de un algoritmo, de
la capacidad de adaptación del sistema operativo, o de la forma en
que debería tomarse la interacción hombre-máquina. En éstas y en
muchas otras situaciones, un paradigma de construcción de prototipos
puede ofrecer el mejor enfoque.
– El paradigma de construcción de prototipos comienza con la
recolección de requisitos. El desarrollador y el cliente encuentran y
definen los objetivos globales para el software, identifican los
requisitos conocidos, y las áreas del esquema en donde es obligatoria
más definición. Entonces aparece un diseño rápido. El diseño rápido se
centra en una representación de esos aspectos del software que serán
visibles para el usuario/cliente. El diseño rápido lleva a la construcción
de un prototipo. El prototipo lo evalúa el usuario/cliente y lo utiliza
para refinar los requisitos de SW a desarrollar. La interacción ocurre
cuando el prototipo satisface las necesidades del cliente, a la vez que
permite que el desarrollador comprenda mejor lo que necesita hacer.
 El prototipo puede servir como primer sistema pero se recomienda
tirar.
48
•
Tipos de modelos de procesos – Ciclo de vida de Prototipos Problemas
1.
2.
3.
4.
El cliente ve lo que parece ser una versión de trabajo del software,
sin tener conocimiento que es el prototipo y sin saber que con prisa
de hacer que funcione, no se ha tenido en cuenta la calidad del
software global o la facilidad de mantenimiento a largo plazo.
Cuando se le informa que el producto se debe construir otra vez
para que se puedan mantener los niveles altos de calidad, el cliente
no lo entiende y pide que se apliquen unos pequeños ajustes para
que se pueda hacer del prototipo un producto final. De forma
demasiado frecuente la gestión de desarrollo de SW es muy lenta.
El desarrollador a menudo hace compromisos de implementación
para hacer que el prototipo funcione rápidamente. Se puede utilizar
un sistema operativo o lenguaje de programación inadecuado
simplemente porque está disponible y porque es conocido. Un
algoritmo eficiente se puede implementar simplemente para
demostrar capacidad. Después de algún tiempo, el desarrollador
debe familiarizarse con estas selecciones, y olvidarse de las razones
por las que son inadecuadas. La selección menos ideal ahora es una
parte integral del sistema.
Al usuario le desagrada que se deseche código.
Relajación de los desarrolladores.
49
•
Tipos de modelos de procesos – Ciclo de vida de Prototipos –
Problemas (Cont.)
– Aunque pueden surgir problemas, la construcción de prototipos puede
ser un paradigma efectivo para la ingeniería de software. La clave es
definir las reglas del juego al comienzo; es decir, el cliente y el
desarrollador se deben poner de acuerdo en que el prototipo que se
construya para servir como un mecanismo de definición de requisitos.
Entonces se descarta, y se realiza la ingeniería del software con una
visión hacia la calidad y la facilidad de mantenimiento.
50
Tipos de modelos de procesos – Modelos basados en Métodos
Formales
•
–
–
–
1.
2.
3.
–
1.
2.
3.
El modelo de métodos formales comprende un conjunto de
actividades que conducen a la especificación matemática del
software de computadora.
Los métodos formales permiten que un ingeniero de software
especifique, desarrolle y verifique un sistema basado en
computadora aplicando una notación rigurosa y matemática.
Ventajas:
La ambigüedad, lo incompleto y la inconsistencia se descubren y se
corrigen fácilmente.
Los métodos formales de diseño sirven como base para la
verificación de programas.
Sirven de base para la generación automática de código.
Desventajas:
El desarrollo es bastante caro y lleva mucho tiempo.
El estudio de los métodos es costoso.
Es difícil establecer modelos formales como mecanismo
comunicación con los clientes.
de
51
Tipos de modelos de procesos – Modelos Evolutivos (Iterativos
e Incrementales)
•
–
–
El SW al igual que todos los sistemas complejos evoluciona con el
tiempo. Estos modelos se caracterizan porque permiten desarrollar
versiones cada vez más completas del SW teniendo en cuenta la
naturaleza evolutiva del SW.
Los modelos evolutivos son iterativos. Se caracterizan por la forma
en que permiten a los ingenieros de SW, desarrollar versiones cada
vez más completas del producto SW, que puede ir entregándose al
cliente en forma de incrementos.
52
Tipos de modelos de procesos – El modelo incremental
•
–
–
–
–
Combina elementos del ciclo de vida clásico (aplicados
repetidamente) con la filosofía interactiva de construcción de
prototipos.
El modelo incremental aplica secuencias lineales de forma
sorprendente de la misma forma que progresa el tiempo en el
calendario.
Cada secuencia lineal produce un incremento de software. Cuando
se utiliza un modelo incremental, el primer incremento a menudo es
un producto esencial (núcleo). Es decir, se afrontan requisitos
básicos, pero muchas funciones suplementarias quedan sin extraer.
El cliente utiliza el producto central. Como resultado de utilización y
/ o evaluación, se desarrolla un plan para el incremento siguiente. El
plan afronta la modificación del producto central a fin de cumplir
mejor las necesidades del cliente y la entrega de funciones, y
características adicionales. Este proceso se repite siguiendo la
entrega de cada incremento, hasta que se elabore el producto
completo.
Los primeros incrementos son versiones desmontadas del producto
final, pero proporcionan la capacidad que sirve al usuario y también
proporciona una plataforma para la evaluación por parte del
usuario.
53
Tipos de modelos de procesos – El modelo incremental (Cont.)
•
–
Es útil cuando el personal no está disponible para una
implementación completa en cuanto a la fecha límite de gestión que
se haya establecido para el proyecto. Los primeros incrementos se
pueden implementar con menos personas. Si el proyecto central es
bien recibido, se puede añadir más personal para implementar el
incremento siguiente. Además, los incrementos se pueden planear
para gestionar riesgos técnicos.
54
Tipos de modelos de procesos – El modelo en espiral
•
–
Es un modelo de proceso de software evolutivo que acompaña la
naturaleza interactiva de construcción de prototipos con los
aspectos controlados y sistemáticos del ciclo de vida clásico. Se
proporciona el potencial para el desarrollo rápido de versiones
incrementales del software. En el modelo espiral, el software se
desarrolla en una serie de versiones incrementales. Durante las
primeras iteraciones, la versión incremental podrá ser una versión
en papel o un prototipo. Durante las primeras iteraciones, se
producen versiones cada vez más completas de ingeniería del
sistema.
55
Tipos de modelos de procesos – El modelo en espiral (Cont.)
•
–
El modelo en espiral se divide en un número de actividades
estructurales, también llamadas regiones de tareas. Existen entre
tres y seis regiones de tareas, entre ellas están:
 Comunicación el cliente: Las tareas requeridas para
establecer comunicación entre el desarrollador y el cliente
 Planificación: Las tareas requeridas para definir recursos, el
tiempo y otras informaciones relacionadas con el proyecto.
 Análisis de riesgo: Las tareas requeridas para evaluar los
riesgos técnicos y de gestión.
 Ingeniería: Las tareas requeridas para construir una o más
representaciones de aplicación.
 Construcción y adaptación: Las tareas requeridas para
construir probar, instalar y proporcionar soporte al usuario.
 Evaluación del cliente: Las tareas requeridas para obtener la
reacción del cliente según la evaluación de las representaciones
del software creadas durante la etapa de ingeniería e
implementada durante la etapa de instalación
56
Tipos de modelos de procesos – El modelo en espiral (Cont.)
•
–
–
Cada una de las regiones está poblada de un conjunto de tareas que
se adaptan a las características del proyecto que va emprenderse.
Para proyectos pequeños, el número de tareas y su formalidad es
bajo. Para proyectos mayores y más críticos, cada región contiene
tareas que se definen para lograr un nivel de más alto de
formalidad.
Cuando empieza este proceso evolutivo, el equipo de ingeniería del
software gira alrededor del espiral en la dirección de las agujas del
reloj, comenzando por el centro. El primer circuito del espiral
produce el desarrollo de una especificación de productos; los pasos
siguientes en el espiral se podrían utilizar para desarrollar un
prototipo y progresivamente versiones más sofisticadas de software.
Cada paso de la región de planificación produce ajustes en el plan
del proyecto. El costo y la planificación se ajustan según la reacción
ante la evaluación del cliente. Además, el gestor del proyecto ajusta
el número planificado de iteraciones requeridas para completar el
software.
57
Tipos de modelos de procesos – El modelo en espiral (Cont.)
•
–
–
–
A diferencia del modelo de proceso clásico que termina cuando se
entrega el software, el modelo espiral puede adaptarse y aplicarse a
lo largo de la vida del software.
En la figura se define un eje de punto de entrada en el proyecto.
Cada uno de los cubos situados a los largo del eje representan el
punto de arranque para un tipo diferente de proyecto. Un proyecto
de desarrollo de conceptos comienza en el centro del espiral y
continuará hasta que se completa el desarrollo del concepto. Si el
concepto se va a desarrollar dentro de un producto real, el proceso
procede a través del cubo siguiente y se inicia un nuevo proyecto de
desarrollo. El producto nuevo evolucionará a través de iteraciones
alrededor del espiral siguiendo el camino que limita la región algo
más brillante que el centro. Un flujo de proceso similar aparece para
otros tipos de proyectos.
En esencia, el espiral cuando se caracteriza de esta forma,
permanece operativa hasta que el software se retira. Hay veces en
que el proceso está inactivo, pero siempre que se inicie un cambio,
el proceso arranca en el punto de entrada adecuado.
58
Tipos de modelos de procesos – El modelo en espiral (Cont.)
•
–
–
El modelo en espiral es un enfoque realista del desarrollo de
sistemas y de software a gran escala. Como el software evoluciona,
a medida que progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos en cada uno de los
niveles evolutivos. El modelo en espiral utiliza la construcción de
prototipos como mecanismo de reducción de riesgos, pero lo que es
más importante, permite a quien lo desarrolla aplicar el enfoque de
construcción de prototipos en cualquier etapa de evolución del
producto. El modelo en espiral demanda una consideración directa
de los riesgos técnicos en todas las etapas del proyecto, y si se
aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemáticos.
El modelo espiral no es la panacea. Requiere una considerable
habilidad para la evaluación del riesgo, y cuenta con esta habilidad
para el éxito. Si un riesgo importante no fue descubierto y
gestionado, indudablemente surgirán problemas. Finalmente, el
modelo en sí mismo es relativamente nuevo y no se ha utilizado
tanto como los paradigmas lineales secuenciales o de construcción
de prototipos. Todavía tendrán que pasar muchos años antes que se
determine con absoluta certeza la eficacia de este nuevo e
importante paradigma.
59
Tipos de modelos
Reutilización
•
–
–
–
de
procesos
–
Modelos
basados
en
Esta aproximación se basa en la existencia de un número
significativo de elementos reutilizables. El proceso de desarrollo, se
centra en la integración de estos elementos en un sistema, en lugar
de desarrollarlo desde cero.
Incorpora muchas características del modelo en espiral. Es evolutivo
por naturaleza.
El proceso tiende a estructurarse en dos subprocesos distintos y
separados:
 El desarrollo para reutilización: construcción de elementos
reutilizables dentro de un dominio concreto.
 El desarrollo con reutilización: construcción de aplicaciones
utilizando elementos reutilizables.
60
Tipos de modelos de procesos – El modelo DRA
•
–


El desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso
del ciclo de vida clásico que enfatiza un ciclo de vida de desarrollo
extremadamente corto. El modelo DRA es una adaptación a alta
velocidad del ciclo de vida clásico en el que se logra el desarrollo
rápido utilizando un enfoque de construcción basado en
componentes. Si se comprenden bien los requisitos y se limita el
ámbito del proyecto, el proceso DRA permite al equipo de desarrollo
crear un sistema completamente funcional dentro de períodos
cortos de tiempo. Cuando se utiliza principalmente para aplicaciones
de sistemas de información, el enfoque DRA comprende las
siguientes fases:
Modelado de gestión: El flujo de información entre las funciones
de gestión se modela de forma que responda a las siguientes
preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué
información se genera? ¿Quién la genera? ¿A dónde va la
información? ¿Quién la procesa?
Modelado de datos: El flujo de información definido como parte de
la fase de modelado de gestión refina como un conjunto de objetos
de datos necesarios para apoyar la empresa. Se definen las
características de cada uno de los objetos y relaciones entre estos
objetos.
61
•
Tipos de modelos de procesos – El modelo DRA (Cont.)



Modelado de procesos: Los objetos de datos definidos en la fase
de modelado de datos quedan transformados para lograr el flujo de
información necesario para implementar una función de gestión. Las
descripciones se crean para añadir, modificar, suprimir, o recuperar
un objeto de datos.
Generación de aplicaciones: El DRA asume la utilización de
técnicas de cuarta generación. En lugar de crear software con
lenguajes de programación de tercera generación, el proceso DRA
trabaja para volver a utilizar componentes de programas ya
existentes (cuando es posible) o a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas
automáticas para facilitar la construcción del software.
Prueba y entrega: Como el proceso DRA enfatiza la reutilización,
ya se han comprobado muchos de los componentes de los
programas. Esto reduce tiempo de pruebas. Sin embargo, se deben
probar todos los componentes nuevos y se deben ejercitar todas las
interfaces a fondo.
62
•
Tipos de modelos de procesos – El modelo DRA (Cont.)
63
Tipos de modelos de procesos – El modelo DRA (Cont.)
•
–
Las limitaciones de tiempo impuestas en un proyecto DRA
demandan ámbito en escalas. Si una aplicación de gestión puede
modularse de forma que permita completarse cada una de las
funciones principales en menos de tres meses, es el candidato del
DRA. Cada una de las funciones puede ser afrontada por un equipo
DRA diferente y ser integradas en un solo conjunto.
–
Problemas:
 Para proyectos grandes aunque por escalas, el DRA requiere
recursos humanos suficientes como para crear el número
correcto de equipos DRA.
 DRA requiere clientes y desarrolladores comprometidos en las
rápidas actividades necesarias para completar un sistema en un
marco de tiempo abreviado. Si no hay compromiso, por ninguna
de las partes constituyentes, los proyectos DRA fracasarán.
64
•
Tipos de modelos de procesos – El modelo DRA (Cont.)





No todos los tipos de aplicaciones son apropiados para DRA.
Si un sistema no puede modularizarse adecuadamente, la
construcción de los componentes necesarios para DRA será
problemático.
Si está en juego el alto rendimiento, y se va a conseguir el
rendimiento convirtiendo interfaces en componentes de
sistemas, el modelo DRA puede que no funcione.
DRA no es adecuado cuando los riesgos técnicos son altos. Esto
ocurre cuando una nueva aplicación hace uso de tecnologías
nuevas, o cuando el nuevo software requiere un alto grado de
interoperatividad con programas de computadoras ya existentes.
DRA enfatiza el desarrollo de componentes de programas
reutilizables.
65
Tipos de modelos de procesos – Técnicas de 4 Generación
•
–
–
–
–
–
Abarca un amplio espectro de herramientas de software que tienen
algo en común: todas facilitan al ingeniero del SW la especificación
de algunas características del software de alto nivel.
Luego, la herramienta genera automáticamente el código fuente
basándose en la especificación del técnico.
Cada vez parece más evidente que cuanto mayor sea el nivel en que
se especifique el SW, más rápido se podrá construir el programa.
El paradigma T4G para la ingeniería del software se orienta hacia la
posibilidad de especificar el software usando formas de lenguaje
especializado o notaciones gráficas que describan el problema que
hay que resolver en términos que los entienda el cliente.
Actualmente, un entorno para el desarrollo de software que soporte
el paradigma T4G puede incluir todas o algunas de las siguientes
herramientas:
 Lenguajes no procedimentales de consultas de bases de datos
 Generación de informes
 Manejo de datos
 Interacción y definición de pantallas
 Generación de códigos
 Capacidades gráficas de alto nivel
 Capacidades de hoja de cálculo
66
Tipos de modelos de procesos – Técnicas de 4 Generación
(Cont.)
•
–
–
–
T4G comienza con el paso de reunión de requisitos. Idealmente, el
cliente describe los requisitos, que son, a continuación, traducidos
directamente a un prototipo operativo. Sin embargo, en la práctica
no se puede hacer eso. El cliente puede que no esté seguro de lo
que necesita; puede ser ambiguo en la especificación de hechos que
son conocidos, y puede que no sea capaz o no esté dispuesto a
especificar la información en la forma en que puede utilizar una
herramienta T4G. Por esta razón, el diálogo cliente-desarrollador
descrito por los otros paradigmas sigue siendo una parte esencial
del enfoque T4G.
Para proyectos pequeños se puede ir de la recolección de requisitos
a la implementación usando lenguajes de cuarta generación (L4G).
Sin embargo, es necesario un mayor esfuerzo para desarrollar una
estrategia de diseño para el sistema, incluso si se utiliza un L4G. El
uso de T4G sin diseño (para proyectos grandes) causará dificultades
(poca calidad, mantenimiento pobre, mala aceptación del cliente)
que se encuentran cuando se desarrolla software mediante los
enfoques convencionales.
Para transformar una implementación T4G en un producto, el que lo
desarrolla debe dirigir una prueba completa, desarrollar con sentido
una documentación y ejecutar el resto de las actividades de
integración requeridas en los otros paradigmas.
67
Tipos de modelos de procesos – Técnicas de 4 Generación
(Cont.)
•
–
–
–
1.
2.
3.
Ventajas
 Reducciones en el tiempo de desarrollo.
 Mejora en la productividad.
Desventajas
 Las herramientas actuales de T4G no son más fáciles de utilizar
que los lenguajes de programación.
 El código fuente producido por tales herramientas es ineficiente.
 El mantenimiento de grandes sistemas es cuestionable.
Estado actual
El uso de T4G ha crecido considerablemente y ahora es un enfoque
viable para muchas de las diferentes áreas de aplicación. Junto con
las herramientas de ingeniería de software asistida por computadora
(CASE) y los generadores de código, T4G ofrece una solución fiable
a muchos problemas de software.
Los datos recogidos en compañías que usan T4G parecen indicar
que el tiempo requerido para producir software se reduce mucho
para aplicaciones pequeñas y de tamaño medio, y que la cantidad
de análisis y diseño para aplicaciones pequeñas también se reduce.
EL uso de T4G para grandes trabajos de desarrollo exige el mismo o
más tiempo de análisis, diseño y prueba, perdiéndose así un tiempo
sustancial que se ahorra mediante la eliminación de la codificación. 68
Metodologías
•
–
–
–
–
–
El uso de una metodología permite el dominio del proceso descrito.
Una metodología es el conjunto de métodos que se siguen en una
investigación científica. Una metodología SW es un enfoque, una
manera de interpretar la realidad o la disciplina en cuestión.
Se elaboran a partir del marco definido por uno o varios ciclos de
vida.
Desde una perspectiva de Ingeniería de SW, una metodología:
 Describe cómo se organiza un proyecto
 Establece el orden en el que la mayoría de las actividades tienen
que realizarse y los enlaces entre ellas
 Indica
cómo
tienen
que
realizarse
algunas
tareas
proporcionando las herramientas concretas e intelectuales
Con una metodología se intentan cubrir las siguientes necesidades:
 Mejores aplicaciones
 Mejor proceso de desarrollo
 Establecer un proceso estándar en una organización
69
Metodologías - Definición
•
–
Conjunto de componentes que especifican: cómo dividir un proyecto
en etapas, qué tareas se llevarán a cabo en cada etapa, qué salidas
se producen y cuándo deben producirse, qué restricciones se
aplican, qué herramientas van a ser utilizadas, cómo se gestiona y
se controla el proyecto.
–
Otra definición: conjunto de procedimientos, técnicas, herramientas
y un soporte documental que ayuda a los desarrolladores a realizar
un SW.
70
Metodologías - Características
•
–
Una metodología debe cubrir:
 Un proceso de ciclo de vida completo, que comprenda aspectos
tantos del negocio como técnicos
 Un conjunto completo de conceptos y modelos que sean
internamente consistentes
 Una colección de reglas y guías
 Una descripción completa de artefactos a desarrollar
 Una notación con la que trabajar, idealmente soportada por
diversas herramientas CASE y diseñada para una usabilidad
óptima
 Un conjunto de técnicas probadas
 Un conjunto de métricas, junto con asesoramiento sobre calidad,
estándares y estrategias de prueba
 Identificación de los roles organizacionales
 Guías para la gestión de proyectos y aseguramiento de la
calidad
 Asesoramiento para la gestión de bibliotecas y reutilización
71
Metodologías - Clasificación
•
–
–
–
–
Estructuradas: Proponen la creación de modelos del sistema que
representen los procesos, los flujos y la estructura de datos de una
manera descendente. Se pasa de una visión general del problema, a
un nivel de abstracción sencillo.
Esta visión se puede enfocar hacia:
 Un punto de vista funcional del sistema (Metodologías
orientadas a procesos): Se enfocan en el proceso, por ejemplo:
Merise, Yourdon Systems Method YSM, Structured Systems
Analysis and Design Method SSADM, Métrica v3.0
 La estructura de datos (Metodologías orientadas a datos): Se
enfocan en la Entrada y Salida, por ejemplo: Jackson Structured
Design JSD, Warnier-Orr
Orientadas a estados y transiciones: Están dirigidas a la
especificación de sistemas de tiempo real o sistemas que tienen que
reaccionar continuamente a estímulos internos y externos (eventos
o sucesos). Por ejemplo las metodologías de Ward y Mellor y de
Hatley y Pirbhai.
Orientadas al diseño del conocimiento: Esta aproximación se
encuentra aún en una fase temprana de desarrollo. Utiliza técnicas y
conceptos de Inteligencia Artificial para especificar y generar
sistemas de información. Por ejemplo KADS (Knowledge Acquisition
and Development System), IDEAL.
72
Metodologías – Clasificación (Cont.)
•
–
–
–
–
–
Orientadas a objetos: Se fundamenta en la integración de los
datos y procesos. Este paradigma se concibe como un conjunto de
objetos que se comunican entre sí mediante mensajes. El objeto
encapsula datos y operaciones.
Este enfoque facilita la reutilización del SW.
Algunos ejemplos:
 Metodologías dirigidas por los datos: Object Modeling Technique
(OMT), Fusion
 Metodologías dirigidas por las responsabilidades: Responsibility
Driven Desgin (RDD)
 Metodologías dirigidas por los casos de uso: Proceso Unificado
 Metodologías dirigidas por estados: Metodología de Shlaer y
Mellor
Orientadas al desarrollo de sistemas hipermediales:
Pretenden sistematizar la creación de aplicaciones Web dentro de un
proceso de creación de SW bien definido. Por ejemplo Hypermedia
Design Model (HDM), Web Site Design Method (WSDN)
Basadas en métodos formales: Se basan en teorías matemáticas
que permiten una verdadera aproximación científica y rigurosa al
desarrollo de sistemas de información y SW asociado, por ejemplo
OO-Method.
73
•
Proceso Unificado
– El Proceso Unificado es más que un simple proceso, es un marco de
trabajo genérico que puede especializarse para una gran variedad de
sistemas SW, para diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de aptitud y diferentes tamaños de
proyectos.
– El proceso de desarrollo de SW es un conjunto completo de
actividades necesarias para convertir los requisitos de usuario en un
conjunto de artefactos que conforman un producto SW, y para
convertir los cambios sobre esos requisitos en un nuevo conjunto de
artefactos.
– El proceso hace referencia a un contexto que sirve como plantilla que
pueda reutilizarse para crear instancias de ella.
– Las actividades relacionadas conforman disciplinas o flujos de trabajo.
Su identificación parte de la identificación de los trabajadores y de los
artefactos para cada tipo de trabajador, describen como fluye el
proceso a través de los trabajadores (se representan mediante
“calles”).
74
•
Proceso Unificado - Características
- Está basado en componentes
- Utiliza UML
- Es un proceso conducido por casos de uso. Dirigen las actividades de
desarrollo, creando y validando la arquitectura del sistema, definiendo
los casos de prueba y procedimientos, planificando iteraciones,
creando la documentación de usuario y desplegando el sistema. Los
casos de uso enlazan las disciplinas de Requisitos, Análisis, Diseño,
Implementación y Prueba.
- Está centrado en la arquitectura. La arquitectura se representa
mediante vistas del modelo. Se seleccionan escenarios, se identifican
las clases principales, se estructura en subsistemas, capas y se
definen interfaces, se implementan prototipos de arquitectura y se
evalúa la misma mediante iteraciones.
- Es iterativo e incremental. En cada iteración se identifican y
especifican los casos de uso relevantes, se crea un diseño basado en
la arquitectura seleccionada, se implementa el diseño mediante
componentes y se verifica que los componentes satisfacen los casos
de uso. Si una iteración cumple con sus objetivos, se pasa a la
siguiente. En cada iteración se va desarrollando el sistema de forma
incremental.
- Puede extenderse y especializarse para una gran variedad de sistemas
SW (es flexible)
- Permite gran variedad de estrategias de ciclos de vida
75
•
UML
– Es una notación estándar para el desarrollo de sistemas usando el
enfoque OO. Es una notación en evolución, aún en desarrollo.
Comenzó en 1994 como esfuerzo de Booch y Rumbaugh quienes
definieron el estándar. Luego Jacobson se unió al equipo. En 1997 UML
fue entregado a OMG (Object Management Group) como propuesta de
notación y metamodelo OO.
– UML es un lenguaje de modelado que sirve para visualizar, especificar,
construir y documentar un sistema SW.
– Los diagramas de UML son los siguientes:
 Análisis en el contexto organizacional: Diagramas de CU
 Análisis y Diseño desde la perspectiva estática: Diagrama de Clase
y Diagrama de Objetos
 Análisis y Diseño desde la perspectiva dinámica: Diagrama de
Secuencia, Diagrama de Colaboración y Diagrama de Estados
 Implementación: Diagrama de Componentes y Diagrama de
Despliegue
– En sistemas de envergadura es conveniente hacer una división en
subsistemas. En UML esto se representa con el concepto de package
(paquete). Un paquete es una agrupación de elementos modelados.
Los paquetes pueden estar anidados dentro de otros. La relación entre
paquetes se establece mediante conexiones de dependencia. Una
relación de dependencia se simboliza por una flecha punteada.
76
•
UML (Cont.)
– El concepto de paquete permite organizar los CU por subsistemas.
– UML es un lenguaje de modelado que sirve para visualizar, especificar,
construir y documentar un sistema SW.
 Lenguaje de visualización: facilita la comunicación de los modelos
conceptuales a otros y disminuye errores al permitir hablar el
mismo
lenguaje.
Permite
interpretar
los
modelos
sin
ambigüedades, ya que UML tiene una semántica bien definida.
 Lenguaje de especificación: especificación significa construir
modelos precisos, no ambiguos y completos. UML especifica las
decisiones de análisis y diseño que deben llevarse a cabo, como
así también las de implementación.
 Lenguaje de construcción: no es un lenguaje de programación,
pero sus modelos pueden ser conectados a una variedad de
lenguajes de programación, como Java, C++, Visual Basic. Se
puede generar código a partir de un modelo UML y aún hacer
ingeniería inversa.
 Lenguaje
de
documentación:
documenta
requerimientos,
arquitectura, diseño, codificación, plan de proyecto, prueba,
prototipo, versiones de SW.
77
•
UML - Objetivos
- Establecer un lenguaje visual de modelado, expresivo y sencillo en su
uso
- Mantener una independencia de los procesos de modelado y de los
lenguajes de programación
- Establecer bases formales
- Integrar las mejores prácticas
- Imponer un estándar mundial
•
UML - Algunos conceptos
– Producto: El producto que se obtiene es un sistema de SW. El
sistema lo componen todos los “artefactos” necesarios para
representarlo de forma comprensible.
– Artefacto: Término general para cualquier tipo de información
creada, producida, cambiada o utilizada por los trabajadores en el
desarrollo del sistema. El artefacto más importante del Proceso
Unificado es el “modelo”.
78
•
UML - Algunos conceptos (Cont.)
– Un sistema posee una colección de modelos y las relaciones entre
ellos.
– Modelo: Es una abstracción del sistema. Recogen diferentes
perspectivas del sistema (desde el punto de vista de analistas,
diseñadores,
usuarios,
jefe
de
proyecto,
etc.).
Describe
completamente aquellos aspectos del sistema que son relevantes al
propósito del modelo.
– Existen diversos modelos:
 Modelos de Casos de uso: Diagramas de casos de uso, secuencia,
colaboración y actividad (Modelado de requerimientos)
 Modelos de Análisis y Diseño: Diagramas de clases, objetos,
secuencia, colaboración y actividad (Modelado de la estructura y
de interacción)
 Modelo de Despliegue: Diagramas de despliegue, secuencia y
colaboración.
 Modelo de Implementación: Diagramas de componentes,
secuencia y colaboración.
 Modelo de Pruebas: Todos los diagramas.
79
•
Elementos del Proceso Unificado
– Fases del ciclo de vida: La división temporal necesita puntos de
control.
– Puntos de control o hitos (separan las etapas, fases e iteraciones):
En estos puntos los participantes del proyecto revisan el progreso del
mismo, se identifican los riesgos y se evalúa la situación global del
proyecto.
– Disciplinas o flujos de trabajo (organizan las actividades de gestión
y desarrollo): El resultado de las actividades de los flujos de trabajo
son los artefactos.
– Artefactos: cualquier tipo de información producida por los
desarrolladores de un sistema (diagramas UML, código, ejecutables,
casos de prueba, etc.). Se construyen de forma incremental.
80
•
La vida del Proceso Unificado
– El proceso unificado se repite a lo largo de una serie de ciclos de
desarrollo que constituyen la vida de un sistema. Cada ciclo de
desarrollo concluye con una versión entregable del producto.
– Cada ciclo consta de cuatro fases:
 Inicio: se define el alcance del proyecto y se desarrollan los casos
de negocio.
 Elaboración: se planifica el proyecto, se especifican en detalle la
mayoría de los casos de uso y se diseña la arquitectura del
sistema.
 Construcción: se construye el producto.
 Transición: el producto se convierte en versión beta, se corrigen
los problemas y se incorporan mejoras sugeridas en la revisión.
81
•
Plan de Negocio (Plan de Empresa)
– Debido a los cambios constantes del ámbito empresarial surge la
necesidad conceptual, metodológica y de gestión, de introducir un
instrumento que permita concretar las estrategias en términos
técnicos, económicos, tecnológicos y financieros en las entidades, este
instrumento se denomina mundialmente: Plan de Negocio.
– En dicho plan se debe argumentar tanto a corto como mediano plazo
una descripción detallada de los servicios y productos que se ofrecen,
las oportunidades de mercados que se poseen, y cómo está dotada la
organización de recursos tangibles e intangibles, que le permitan
determinada competitividad y diferenciación entre los competidores.
– Es un documento escrito que evalúa todos los aspectos de la
factibilidad económica de la iniciativa comercial con una descripción y
análisis de sus perspectivas empresariales.
 Un plan de negocios es un documento escrito y conciso, preparado por
una organización (o su equipo) donde se describe el negocio actual, la
situación del mercado, las futuras acciones y estrategias de
implementación.
82
•
Plan de Negocio (Cont.)
– Su objetivo consiste en comunicar la idea del negocio y establecer
credibilidad frente a diferentes públicos con argumentos sólidos para
vender la idea. También constituye una gran herramienta para que la
organización evalúe la viabilidad y realice un seguimiento de su
implementación.
– El Plan de Negocio muestra en un documento el o los escenarios
futuros y más probables con todas sus variables, con el fin de facilitar
un análisis integral que pueda ser presentado a otras partes
involucradas en el proyecto (inversionistas, socios, bancos,
proveedores, clientes).
83
•
Plan de Negocio – Ventajas
– Existen múltiples ventajas de su uso, podemos citar algunas:
1. Evita invertir fondos sin conocer la posibilidad de mercado para el
producto
2. Obliga a la organización a buscar información que puede ser
estadística o de la experiencia colectiva para detallar datos.
3. Indica la estructura humana que lo hará posible
4. Reporta la rentabilidad esperada de la idea de negocio.
5. Permite determinar el dinero que la empresa necesita para sus
diversas actividades.
6. Ayuda a que la empresa pueda alcanzar sus metas. Los errores se
cometen en el papel, eso posibilita reducir los fracasos.
7. Es una herramienta de diseño. La organización va dando forma
mental a su negocio antes de darle forma real.
8. Herramienta de reflexión. El escribir de una forma organizada y
coherente las estrategias empresariales y la forma de alcanzar las
metas obliga a la reflexión.
9. Herramienta de comunicación. El plan facilita la necesaria
coordinación entre los diferentes departamentos y personas de la
empresa.
10.Herramienta de Gestión de Recursos Humanos. El plan sirve de
guía para planificar las necesidades de formación y distribuir las
responsabilidades.
84
•
Plan de Negocio – Contenido básico
– Proponemos un contenido básico o estándar para plan de negocio con
el siguiente formato:









Resumen ejecutivo.
Descripción del negocio.
Productos y servicios.
Descripción del sector.
Estrategia de comercialización.
Gestión y personal.
Protección y normativas.
Plan de puesta en marcha.
Información adicional (optativo).
85
•
•
Plan de Negocio – Contenido básico (Cont.)
Resumen Ejecutivo
– Sólo puede ser preparada cuando finalice la elaboración del Plan de
Negocios y debe ser colocada al principio del documento.
– Es una síntesis descriptiva, en la que se destaca lo que se considera
importante.
– Debe contener:
 La descripción de la empresa o proyecto y la proyección de sus
productos y servicios.
 La estructura organizativa, los propietarios y la gerencia de la
empresa.
 Sus principales iniciativas y objetivos.
 Las oportunidades de mercado.
 Las principales ventajas competitivas.
 Los componentes de su estrategia de comercialización.
 Las principales proyecciones económicas y financieras.
86
•
•
Plan de Negocio – Contenido básico (Cont.)
Descripción del negocio
– Compuesta por:
 Historia del negocio: Si la firma ya existe, describa cuándo y por
quién fue iniciada y los cambios más importantes que hayan
ocurrido durante su trayectoria. Si se trata de un nuevo
emprendimiento, señale algunas de las razones por las que usted
quiere iniciar el mismo.
 Objetivo general y formas de alcanzarlo: Es una visión a largo
plazo de lo que usted desea de su empresa. En algunos casos,
conviene hacer referencia a las estrategias y filosofías de negocio
o para mostrar los esfuerzos que su empresa dedica para
desarrollar buenas relaciones con los clientes y con su personal.
 Objetivos: Con el propósito de verificar si su negocio se está
desarrollando en orden a estos objetivos en el corto plazo. Se
puede fijar los objetivos relacionados con ocupar una posición
deseada del mercado, las ventas o cualquier otro objetivo que sea
importante para el negocio  Deben ser efectivos, simples, y
mensurables.
 Localización y recursos: Describa dónde se localiza su empresa y
qué facilidades dispone. Puede incluir una descripción del lugar, del
tipo y magnitud de las instalaciones que posee, del equipo, y si es
propietario de los inmuebles. Además, explique cuáles son las
ventajas -si las hubiera87
•
•
Plan de Negocio – Contenido básico (Cont.)
Productos y servicios
– Compuesto por:
 Descripción de productos y/o servicios: Describa brevemente los
productos y/o los servicios que su empresa vende o venderá.
 Características destacables de sus productos y/o servicios:
Explique cuáles son las razones que hacen que sus productos o
servicios sean los elegidos en el mercado y de qué manera se
diferencian de los de sus competidores.
 Producción: Describa cómo serán producidos sus productos o
servicios. Puede destacar los recursos humanos y materiales
utilizados y el proceso productivo que utiliza o utilizará.
 Futuros productos y servicios: ¿Tiene planes para actualizar los
productos o servicios existentes o para ofrecer otros nuevos? Si
así fuera, describa brevemente lo que planea hacer.
 Ventajas competitivas en la producción de productos y servicios:
¿Hay algún aspecto destacable en su capacidad de producción que
puede significar una ventaja con respecto a sus competidores? P.
e. ¿ posee personal especializado, nueva tecnología, insumos a
menores costos, etc.?
88
•
•
Plan de Negocio – Contenido básico (Cont.)
Descripción del sector
 Estudios de Mercado: En este punto, sería útil que comente si ha
efectuado alguna investigación del mercado en que se
desenvuelve. P. e. una encuesta a actuales y potenciales clientes.
 Tamaño del sector: Describa el tamaño del sector en el cual su
empresa funciona o funcionará. Factores que determinan esa
dimensión: el monto total de las ventas, el número de las
unidades vendidas, la cantidad de empresas, el empleo total.
Puede incluir cualquier otra estadística sobre el crecimiento del
sector.
 Principales segmentos de los productos o servicios: Un sector
económico puede estar constituido por un determinado número de
productos. P. e. en el de la industria panadera pueden definirse un
conjunto de bienes, tales como pan de harina de trigo, pan
integral, facturas, galletas, etc. Trate de explicar los productos que
integran su actividad, destacando el tamaño y las características
de los segmentos en los que su empresa deberá competir.
 Principales segmentos del mercado: ¿Quiénes participan en el
sector en el cual usted vende sus productos o servicios? Divida su
mercado en grupos de clientes, destacando las características y
tamaño de los mismos. ¿Tiene previsto cuál es o va ser su
participación en esos segmentos?
89
•
•
Plan de Negocio – Contenido básico (Cont.)
Descripción del sector
– Compuesta por:
 Proceso y criterio de compras de los clientes: Es importante saber
cómo y por qué los clientes compran sus productos o los de su
competencia. Por ejemplo, qué importancia tiene el precio, la
calidad, las garantías o el servicio de pos-venta que usted ofrece,
en la toma de decisiones de compra de sus clientes. Explique
resumidamente cómo los criterios del proceso de compra pueden
variar en cada uno de los segmentos de mercado o del producto.
 Descripción de los participantes del sector: Describa, en términos
generales, los tipos de empresas que compiten en su sector.
 Tendencias clave en el sector: Lo único que es constante en un
negocio es el cambio. ¿Cuáles son las tendencias dominantes en
su actividad? Estas tendencias podían incluir cambios en
tecnología,
productos,
moda,
mercados,
regulaciones
o
condiciones económicas. ¿Cuáles de esas tendencias afectarán a
su empresa en los próximos años?
 Visión del sector: Considere qué productos tienen las mayores
oportunidades de crecimiento en los próximos años y por qué, y
para cuáles se puede esperar una declinación en las ventas.
90
•
•
Plan de Negocio – Contenido básico (Cont.)
Estrategia de comercialización
– Compuesta por:
 Mercado objetivo: En la sección anterior, se describió el mercado
de su actividad. ¿A qué clientes o segmentos de mercado su
empresa apuntará específicamente? P. e. se puede definir su
mercado objetivo por tipo cliente y por región geográfica. ¿Cómo
sus mercados pueden cambiar durante el período de su Plan de
Negocios?
 Descripción de los competidores principales: Enumere a sus
competidores principales y proporcionar una descripción abreviada
de sus negocios en términos de la localización, producción,
estrategias de comercialización y posición en el mercado.
 Análisis de la posición competitiva: Se trata de comparar su
negocio con el de sus competidores. ¿De qué manera su empresa
tendrá una ventaja competitiva sobre sus competidores y de qué
forma podrá encontrar alguna desventaja competitiva?
 Estrategia de precios: ¿Cómo establecerá los precios de sus
productos o servicios? ¿Cómo son en relación con los de sus
competidores?
91
•
•
Plan de Negocio – Contenido básico (Cont.)
Estrategia de comercialización
– Compuesta por:
 Estrategia de distribución: Cómo distribuirá sus productos y/o
servicios a sus mercados. Dónde están ubicados sus clientes, y
cómo llegará a ellos, tanto para la venta como en la pos-venta.
 Estrategia de Promoción: Tener un buen producto o servicio no es
una garantía de éxito. Usted tiene que hacer conocer sus
productos o servicios e informarles cómo y dónde pueden
adquirirlos. Describa cómo hará para que se conozcan. Destaque
las actividades que usted emprenderá con ese objetivo. P. e.
inversión en publicidad, demostraciones comerciales, mailing,
telemarketing y cualquier otro medio de promoción que utiliza o
utilizará para llegar a sus potenciales clientes.
92
•
•
Plan de Negocio – Contenido básico (Cont.)
Gestión y personal
– Compuesta por:
 Estructura de su organización: Describa la organización de su
empresa. Comente cuánto personal dispone habitualmente y
cuánto piensa tener en los próximos años.
 Personal de gerencia: Haga una lista con una breve descripción
con el cargo que cada uno ocupa, las funciones principales y la
experiencia en cada caso. Considere las fortalezas y debilidades
del personal de gerencia y de otros, y de qué manera se propone
tratar esas debilidades.
 Personal: Explique, si necesita personal, cómo va a cubrir el o los
cargos que no son de nivel gerencial en su empresa señalando el
perfil y nivel de experiencia que necesita y los salarios que estima
pagar y si dicho personal requiere de algún tipo de entrenamiento
que usted está en condiciones de suministrar o si acudirá a la
capacitación externa.
 Mercado de trabajo: Contemple qué factores pueden afectar la
capacidad de identificar el personal que necesita y mantenerlo en
su negocio.
 Métodos de producción: Explique si su empresa puede variar el
método de producción y si ha hecho estimaciones del costo de esa
variación. P. e. trabajar en dos turnos o más.
93
•
•
Plan de Negocio – Contenido básico (Cont.)
Protección y normativas
– Integrada por:
 Protección a la Propiedad Intelectual: En el caso de que sus
procesos, productos o servicios, se encuentren protegidos por
Patentes, Propiedad intelectual, Marcas, Licencias, Permisos u
otros tipos de protección, descríbalos brevemente.
 Cuestiones normativas: ¿Qué tipo de disposiciones normativas
pueden afectar su actividad en forma directa? ¿Su negocio
requiere de licencias o permisos? ¿Qué medidas ha contemplado
para cumplir con las mencionadas normativas ?
94
•
•
Plan de Negocio – Contenido básico (Cont.)
Plan de puesta en marcha
– Implementación:
– ¿Cuándo se iniciarán las principales actividades contenidas en su Plan
de Negocios, y quiénes serán los responsable de llevarlas a cabo?
¿Cuándo finalizarán las mismas?
•
Información adicional (optativo)
– Toda aquella información que considere necesaria para complementar
lo detallado anteriormente.
95
•
Bibliografía
 Ingeniería de software: Un enfoque práctico – 5° Edición de Roger S.
Pressman - Editorial Mc Graw Hill. 2002
 Análisis Estructurado Moderno de Edward Yourdon – Editorial: Prentice
Hall
 El lenguaje Unificado de Modelado de Booch, Rumbaugh y Jacobson –
Addison-Wesley, 1999
 Guía para empresarios PyMEs para elaborar un Plan de Negocios
96