Universidad Nacional De La Patagonia San Juan Bosco Facultad De Ingeniería Cátedra: Análisis Y Diseño De Sistemas

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