unidad 2 planificacion y modelado

UNIDAD 2

PLANIFICACION DEL SISTEMAS

Objetivo: Realizará la planificación de

un proyecto de software de una

organización

UNIDAD II / PLANIFICACION DEL SISTEMA

38

2.1. PLANIFICACIÓN DEL TIEMPO

Uno de los factores más conocidos por los participantes de un proyecto es el del tiempo.

Podrán no conocer el costo financiero, podrán no conocer que recursos (que también

integran los costos, porque al final también se traducen en gastos) se utilizan en dicho

proyecto, pero lo que si se suele saber es para cuando el proyecto debe estar concluido.

Por lo tanto, el tiempo es la delimitación más conocida. Todo proyecto está

sujeto al tiempo, a una duración. La mayoría de los proyectos tienen una fecha límite

para la que el proyecto deberá estar concluido. Además, el proyecto posiblemente

disponga de una serie actividades que se deben cumplir.La duración de las tareas es el

periodo de tiempo que transcurre entre la fecha de comienzo de una tarea y su fecha de

finalización.

¿Como podemos establecer la duración de una tarea?

¿Existe alguna técnica que nos ayude a definirla?

LA DURACIÓN DE LAS TAREAS SE ESTABLECE APLICANDO ALGUNO DE ESTOS FACTORES:

• La Historia: Consiste en establecer una consultoría sobre similares proyectos

realizados con anterioridad y recoger datos históricos. Como se hicieron, cuanto duraron

sus tareas. etc.

• La Participación: Consiste en contar con personas que tengan experiencia en

proyectos idénticos (mismo) aunque sean bajo otras circunstancias.

• La Intuición: Contar con personas que hayan realizado un proyecto con similares

características.

• La Indeterminación.: Hacer una estimación, a veces no basada en nada

concreto. (por impulsos).

2.2. EVALUACION DEL COSTO BENEFICIO

FACTORES EN EL COSTO DEL SOFTWARE

Existen muchos factores que influyen en el costo de un producto de programación. El

efecto de estos factores es difícil de estimar y, por ende también lo es el costo del

esfuerzo en el desarrollo o en el mantenimiento.


39

Entre los factores que afectan se observan, en forma primordial, las capacidades

individuales del personal asignado al proyecto y su familiaridad con el área de aplicación,

la complejidad del producto, el tamaño de éste, el tiempo asignado, el nivel de

confiabilidad, el nivel tecnológico utilizado; la disponibilidad, familiaridad y estabilidad del

sistema donde se desarrolla el producto.

ESTIMACIÓN DE COSTOS

Al principio, el costo del software constituía un pequeño porcentaje del costo total de los

sistemas basados en computadora. Un error considerable en las estimaciones del costo

del software tenía relativamente poco impacto. Hoy en día, el software es el elemento

más caro de la mayoría de los sistemas informáticos. Un gran error en la estimación del

costo puede ser lo que marque la diferencia entre beneficios y pérdidas. Sobrepasarse

en el costo puede ser desastroso para el equipo de desarrollo.

La estimación del costo y del esfuerzo del software nunca será una ciencia

exacta. Son demasiadas las variables humanas, técnicas, de entorno, políticas que

pueden afectar al costo final del software y al esfuerzo aplicado para desarrollarlo. Sin

embargo, la estimación del proyecto de software puede dejar de ser un oscuro arte para

convertirse en una serie de pasos sistemáticos que proporcionen estimaciones con un

grado de riesgo aceptable.

PARA REALIZAR ESTIMACIONES SEGURAS DE COSTOS Y ESFUERZOS TENEMOS VARIAS OPCIONES POSIBLES:

• Dejar la estimación para más adelante (obviamente, ¡podemos realizar una

estimación al cien por cien fiable tras haber terminado el proyecto!).

• Basar las estimaciones en proyectos similares ya terminados.

• Utilizar «técnicas de descomposición» relativamente sencillas para generar las

estimaciones de costo y de esfuerzo del proyecto.

• Desarrollar un modelo empírico para el cálculo de costos y esfuerzos del

software.

Desafortunadamente, la primera opción, aunque atractiva, no es práctica. Las

estimaciones de costos han de ser proporcionadas a priori. Sin embargo, hay que

reconocer que cuanto más tiempo esperemos, más cosas sabremos, y cuanto más

sepamos, menor será la probabilidad de cometer serios errores en nuestras

estimaciones.


40

La segunda opción puede funcionar razonablemente bien si el proyecto actual es

bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares.

Desafortunadamente. La experiencia anterior no ha sido siempre un buen indicador de

futuros resultados.

Las opciones restantes son métodos viables para la estimación del proyecto de

software. Desde un punto de vista ideal, se deben aplicar conjuntamente las técnicas

indicadas. Usando cada una de ellas como comprobación de las otras.

Las técnicas de descomposición utilizan un enfoque de «divide y vencerás» para

la estimación del proyecto de software.

Dentro de la mayor parte de las organizaciones, la estimación de costos de la

programación se basa en las experiencias pasadas. Los datos históricos se usan para

identificar los factores de costo y determinar la importancia relativa de los diversos

factores dentro de la organización. Lo anterior, por supuesto, significa que los datos de

costos y productividad de los proyectos actuales deben ser centralizados y almacenados

para un empleo posterior. La estimación de costos puede llevarse acabo en forma

jerárquica hacia abajo o en forma jerárquica hacia arriba (Bottom-Up).

La estimación jerárquica hacia abajo

Se enfoca primero a los costos del nivel del sistema, así como a los costos de manejo

de la configuración, del control de calidad, de la integración del sistema, del

entrenamiento y de las publicaciones de documentación. Los costos del personal

relacionado se estiman mediante el examen del costo de proyectos anteriores que

resulten similares.

La estimación jerárquica hacia arriba

Primero se estima el costo del desarrollo de cada módulo o subsistema; tales costos se

integran para obtener un costo total.

Esta técnica tiene la ventaja de enfocarse directamente a los costos del sistema,

pero se corre el riesgo de despreciar diversos factores técnicos relacionados con

algunos módulos que se desarrollarán. La técnica subraya los costos asociados con el

desarrollo independiente de cada módulo o componente individual del sistema, aunque

puede fallar al no considerar los costos del manejo de la configuración o del control de

calidad.


41

En la práctica, ambas técnicas deben desarrollarse y compararse para que

iterativamente se eliminen las diferencias obtenidas.

PARA ANALIZAR UN ANÁLISIS DE COSTO-BENEFICIO SE DEBE TOMAR EN CUENTA LAS SIGUIENTES RECOMENDACIONES:

Para obtener el costo.

1.-Identificar primeramente el costo de la inversión más importante de acuerdo a su

monto.

2.-Identificar los costos complementarios consecuencia del punto1.

Para obtener el beneficio

Es necesario que los beneficios que genere un proyecto sean traducidas al mismo tipo

de unidad que se manejan en los costos para que estos puedan ser comparados y por lo

tanto se facilite la toma de decisiones.

PARA OBTENER ESTA INFORMACIÓN SE RECOMIENDA LO SIGUIENTE:

• Identificar todo el problema que se pretenda resolver con la implantación del

proyecto.

• Cada problema debe ser traducido a la unidad de referencia del costo y

referenciado a una cierta unidad de tiempo, por ej. Costo por día, por hora, etc.

2.3. ESTUDIO DE VIABILIDAD

Todos los proyectos son posibles: ¡si se tiene infinitos recursos y tiempo!

Desgraciadamente, el desarrollo de un sistema o producto basado en

computadora es muy probable que esté plagado de escaséese de recursos y de fechas

de entrega difíciles (o totalmente no realistas). Es necesario y prudente evaluar la

viabilidad de un proyecto cuanto antes. Se pueden evitar meses o años de esfuerzo,

miles o millones de dólares y un bochorno profesional indecible si se reconoce un

sistema mal concebido en la pronta fase de definición. La viabilidad y el análisis de

riesgo están relacionados de muchas maneras. Si el riesgo del proyecto es alto la

viabilidad de producir software de calidad se reduce. Durante la ingeniería de producto,

sin embargo, concentramos nuestra atención en cuatro áreas principales de interés:


42

Viabilidad económica.

Una evaluación del costo de desarrollo sopesado con los ingresos netos o beneficios

obtenidos del sistema o producto desarrollado.

Viabilidad técnica.

Un estudio de función, rendimiento y restricciones que puedan afectar a la consecución

de un sistema aceptable.

Viabilidad legal.

Determinar cualquier infracción, violación o responsabilidad legal en que se podría

incurrir por el desarrollo del sistema.

Viabilidad alternativa.

Una evaluación de los enfoques alternativos al desarrollo del sistema o producto.

No es necesario un estudio de viabilidad para sistemas en que la justificación

económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no

existe ninguna alternativa razonable.

Sin embargo, si falla alguna de las condiciones anteriores, se debería hacer un

estudio del área en cuestión.

La justificación económica incluye una amplia gama de aspectos a tener en

cuenta como son el análisis de costes/beneficios, las estrategias de ingresos de la

empresa a largo plazo, el impacto en otros productos o centros de beneficios, coste de

recursos necesarios para el desarrollo y crecimiento potencial del mercado.

La viabilidad tecnológica es frecuentemente el área más difícil de valorar en esta

etapa del proceso de ingeniería del producto. Como los objetivos, funciones y

rendimiento son poco claros, cualquier cosa parece posible si se hacen las suposiciones

correctas. Es esencial que el proceso de análisis y definición se realice en paralelo con

una valoración de la viabilidad técnica. De esta manera se pueden juzgar

especificaciones concretas a medida que se establecen.


43

2.4. PLANIFICACION DE LA DOCUMENTACION

Plan de documentación. Su función es definir y controlar la documentación asociada

con el proyecto.

La buena documentación proporciona una explicación de la forma en que opera

el sistema y qué características tienen los modelos y algoritmos utilizados en él. Muchos

paquetes de hoja de cálculo y de ayuda para la toma de decisiones guardan todos estos

detalles en forma automática a medida que se van especificando.

Aunque esta información es transparente para el usuario, se puede recuperar cuando

sea necesario ya sea en forma impresa o a través de una pantalla. Muchos lenguajes de

cuarta generación son auto-documentados, lo que significa que los propios programas

son tan fáciles de entender que ellos se convierten en su propia documentación. La

lectura del código explica lo que hace el programa.

IMPORTANCIA DE LA DOCUMENTACION

La documentación de los programas es un aspecto sumamente importante, tanto

en el desarrollo de la aplicación como en el mantenimiento de la misma.

Mucha gente no lo hace parte del desarrollo y no se da cuenta de que pierde la

posibilidad de la reutilización de parte del programa en otras aplicaciones, sin necesidad

de conocerse el código al dedillo. La documentación de un programa empieza a la vez

que la construcción del mismo y finaliza justo antes de la entrega del programa o

aplicación al cliente. Así mismo, la documentación que se entrega al cliente tendrá que

coincidir con la versión final de los programas que componen la aplicación. Una vez

concluido el programa, los documentos que se deben entregar son una guía técnica, una

guía de uso y de instalación.

TIPOS DE DOCUMENTACIÓN:

La documentación que se entrega al cliente se divide claramente en dos categorías:

Interna: Es aquella que se crea en el mismo código, ya puede ser en forma de

comentarios o de archivos de información dentro de la aplicación.

Externa: Es aquella que se escribe en cuadernos o libros, totalmente ajena a la

aplicación en si. Dentro de esta categoría también se encuentra la ayuda electrónica.


44

La guía técnica

En la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación de

la aplicación y las pruebas realizadas para su correcto funcionamiento.

Generalmente este documento esta diseñado para personas con conocimientos de

informática, generalmente programadores. El principal objetivo es el de facilitar el

desarrollo, corrección y futuro mantenimiento de la aplicación de una forma rápida y fácil.

ESTA GUÍA ESTA COMPUESTA POR TRES APARTADOS CLARAMENTE DIFERENCIADOS:

• Cuaderno de carga: Es donde queda reflejada la solución o diseño de la

aplicación.

Esta parte de la guía es únicamente destinada a los programadores. Debe estar

realizado de tal forma que permita la división del trabajo

• Programa fuente: Es donde se incluye la codificación realizada por los

programadores. Este documento puede tener, a su vez, otra documentación para su

mejor comprensión y puede ser de gran ayuda para el mantenimiento o desarrollo

mejorado de la aplicación. Este documento debe tener una gran claridad en su escritura

para su fácil comprensión.

• Pruebas: Es el documento donde se especifican el tipo de pruebas realizadas a

lo largo de todo el proyecto y los resultados obtenidos.

La guía de uso

Es lo que comúnmente llamamos el manual del usuario. Contiene la información

necesaria para que los usuarios utilicen correctamente la aplicación. Este documento se

hace desde la guía técnica pero se suprimen los tecnicismos y se presenta de forma que

sea entendible para el usuario que no sea experto en informática. Un punto a tener en

cuenta en su creación es que no debe hacer referencia a ningún apartado de la guía

técnica y en el caso de que se haga uso de algún tecnicismo debe ir acompañado de un

glosario al final de la misma para su fácil comprensión.

La guía de instalación

Es la guía que contiene la información necesaria para implementar dicha aplicación.

Dentro de este documento se encuentran las instrucciones para la puesta en marcha del

sistema y las normas de utilización del mismo. Dentro de las normas de utilización se

incluyen también las normas de seguridad, tanto las físicas como las referentes al

acceso a la información.


45

GUIA PARA ELABORAR UN REPORTE

Formato del reporte escrito

El formato del escrito depende de la cantidad de información disponible, la complejidad

del asunto, la naturaleza del trabajo y otros factores que se toman en cuenta para la

preparación de bosquejos. Puede estar determinada por los reglamentos de la

institución, organización o empresa.

A CONTINUACIÓN SE MUESTRA EL FORMATO PARA LA ELABORACIÓN DEL REPORTE DE UN PROYECTO:

1. Portada.

2. Índice.

3. Introducción.

4. Justificación.

5. Objetivos generales y específicos.

6. Problemas resueltos.

7. Alcances y limitaciones de las soluciones.

8. Procedimientos y descripción de las actividades realizadas.

9. Resultados (planos, gráficas, prototipos, programas, etc.).

10. Conclusiones y recomendaciones.

11. Referencias bibliográficas.

2.5. GESTION DE LA CONFIGURACION DE SOFTWARE

Se denomina Gestión de la Configuración el conjunto de procesos destinados a asegurar

la validez que todo producto obtenido durante cualquiera de las etapas del desarrollo de

un Sistema de Información (S.I.), a través del estricto control de los cambios realizados

sobre los mismos y de la disponibilidad constante de una versión estable de cada

elemento para toda persona involucrada en el citado desarrollo. Estos dos elementos

(control de cambios y control de versiones de todos los elementos del S.I.) facilitan

también el mantenimiento de los sistemas al proporcionar una imagen detallada del

sistema en cada etapa del desarrollo.


46

La gestión de la configuración se realiza durante todas las fases del desarrollo de un

sistema de información, incluyendo el mantenimiento y control de cambios, una vez

realizada la puesta en producción.

La gestión de la configuración del software es uno de los procesos clave para

toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor

organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos

de producción. Durante el proceso de construcción de un software, los cambios son

inevitables.

Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han

analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones

que pueden ocurrirle al software dentro de todo el proceso de ingeniería.

“El arte de coordinar el desarrollo de software para minimizar…la confusión, se

denomina gestión de la configuración. La gestión es el arte de identificar, organizar y

controlar las modificaciones que sufre el software…la meta es maximizar la productividad

minimizando errores.”

LOS CAMBIOS DENTRO DEL DESARROLLO DEL SOFTWARE PUEDEN OCURRIR EN CUALQUIER MOMENTO POR LO TANTO DEBEMOS ESTAR PREPARADOS, LAS ACTIVIDADES DE CGS SIRVEN PARA:

• Identificar el cambio de nuestro software.

• Controlar ese cambio.

• Garantizar que el cambio quede bien implantado.

• Informar el cambio.

La gestión de configuración del software no es un mantenimiento del software, el

mantenimiento es la etapa final de la ingeniería hasta que se retire el producto del

equipo, la CGS es un conjunto de actividades de seguimiento y control que comienzan

cuando se inicia el proyecto de desarrollo del software y termina sólo una vez que el

software queda fuera de circulación.

Desgraciadamente, en el proceso de ingeniería del software existe una variable

importantísima que entra en juego, el cambio.


47

La primera Ley de la ingeniería de sistemas establece: “Sin importar en que momento del

ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo

persistirá a lo largo de todo el ciclo de vida”.

Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar el sistema?

¿Que produce los en el sistema cambios? La respuesta a estas interrogantes se puede

encontrar en cuatro aspectos fundamentales y a menudo muy tradicionales dentro del

desarrollo del software:

• Nuevos requisitos del negocio o condiciones que dictan los cambios en las

condiciones del producto o en las normas comerciales.

• Nuevas necesidades del los clientes que demandan la modificación de los datos

producidos por un sistema basado en computadora.

• Reorganización y/o reducción del volumen comercial que provoca cambios en las

prioridades del proyecto o en la estructura del equipo de ingeniería del software.

• Restricciones presupuestarias o de planificaciones que provocan una redefinición

del sistema o del producto.

La gestión de configuración del software realiza un conjunto de actividades

desarrolladas para gestionar y registrar los cambios a lo largo del ciclo de vida del

software de computadora.

La GCS es una actividad de garantía de calidad del software que se aplica en todas las

fases del proceso de ingeniería del software.

LINEAS BASE

Una línea base es un concepto de gestión de configuración del software que nos ayuda a

controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define

una línea base como: Una especificación o producto que se ha revisado formalmente y

sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base

para un desarrollo posterior y que puede cambiarse solamente a través de

procedimientos formales de control de cambios.

En el contexto de la ingeniería del software definimos una línea base como un

punto de referencia en el desarrollo del software y que queda marcado por el envío de

uno o más elementos de configuración del software (ECS) y la aprobación de ECS

obtenido mediante una revisión técnica formal.


48

Por ejemplo, los elementos de una especificación de diseño se documentan y se revisan.

Se encuentran errores y se corrigen cuando todas las partes de las especificaciones se

han revisado corregido y aprobado, la especificación de diseño se convierte en línea

base. Solo se pueden realizar cambios futuros en la arquitectura del software

(contenidos en la especificación del diseño) tras haber sido evaluados y aprobados.

ELEMENTO DE CONFIGURACIÓN DE SOFTWARE

Un elemento de la configuración del software es la información creada como parte del

proceso de ingeniería un ECS (elemento de configuración de software) es un

documento, un conjunto completo de casos de prueba o un componente de un programa

dado.

Los siguientes ECS son el objetivo de las técnicas de gestión de configuración y forman

un conjunto de líneas base:

1) Especificación del sistema

2) Plan de proyecto

3) Especificación de requisitos

4) Prototipo ejecutable o “en papel”

5) Manual de usuario preliminar

6) Especificación de diseños

7) Descripción del diseño de datos

8). Descripción del diseño arquitectónico

9) Descripciones del diseño de los módulos

10) Descripciones del diseño de interfaces

11) Descripciones de los objetos (si se utilizan técnicas de P.O.O)

12) Listados del código fuente

13). Plan y procedimiento de pruebas


49

14) Casos de prueba y resultados registrados

15) Manuales de operación de y de instalación

16) Programas ejecutables

17) Módulos, código ejecutable

18) Módulos enlazados

19) Descripción de la base de datos

20) Esquema y estructura de archivos

21) contenido inicial

22) Manual del usuario final

23) Documentos de mantenimiento

24). Informes de problemas del software

25) Peticiones de mantenimiento

26). Ordenes de cambios e ingeniería

Es importante considerar poner las herramientas de desarrollo de software bajo control

de configuración. Es decir congelar la versiones de editores, compiladores y otras

herramientas CASE utilizadas durante el desarrollo, un cambio en las versiones

utilizadas puede que produzca resultados diferentes que la versión original.

Los ECS se organizan como objetos de configuración que deben ser catalogados

por la base de datos del proyecto con un nombre único. Un ECS tiene un nombre y

atributos, y está conectado a otros objetos mediante relaciones.


50

La figura se muestra el modelo de datos de los elementos de al configuración,

cada objeto esta relacionado con otro, si se lleva a cabo un cambio sobre un objeto la

interrelaciones señalan a que otros objetos afectará.

EL PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE

La GCS es un elemento importante de garantía de calidad es responsable de controlar

los cambios. Sin embargo también se debe identificar los ECS individuales.

El proceso se puede definir en cinco tareas de CGS:

• Identificación

• Control de versiones

• Control de cambios

• Auditorias de configuración

• Generación de informes

AUDITORIA DE LA CONFIGURACION

¿Cómo podemos asegurar que el cambio se ha implementado correctamente?

La respuesta es doble:

1) Revisiones técnicas formales

2)Aauditorias de configuración del software.


51

Las revisiones técnicas formales se centran en la corrección técnica del elemento de

configuración que ha sido modificado. Los revisores evalúan el ECS para determinar la

consistencia con otros ECS, las omisiones o los posibles efectos secundarios.

Una auditoria de configuración del software complementa la revisión técnica

formal al comprobar características que generalmente no tiene en cuenta la revisión.

La auditoria se plantea y responde con las siguientes preguntas:

• ¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporado

modificaciones adicionales?

• ¿Se ha llevado a cabo una revisión técnica formal para evaluar la corrección

técnica?

• ¿Se han seguido adecuadamente los estándares de ingeniería de software?

• ¿Se han "recalcado" los cambios en el ECS?¿Se han especificado la fecha del

cambio y el autor?¿Reflejan los cambios los atributos del objeto de configuración?

• ¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y

divulgarlo?

• ¿Se han actualizado adecuadamente todos los ECS relacionados?

INFORMES DE ESTADO

La generación de informes de estado de la configuración es una tarea de GCS que

responde a las siguientes preguntas:

1) ¿Qué pasó?

2) ¿Quién lo hizo?

3) ¿Cuándo pasó?

4) ¿Que más se vio afectado?

La generación de informes de estado de la configuración desempeña un papel

vital en el éxito del proyecto de desarrollo de software. Cuando aparece involucrada

mucha gente es muy fácil que no exista una buena comunicación.


52

Pueden darse errores entre las personas desarrolladoras del software. El IEC ayuda a

eliminar esos problemas, mejorando la comunicación entre todas las personas

involucradas.

La gestión y configuración del software identifica, controla audita e informa de las

modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido

distribuido a los clientes. La configuración se organiza de tal forma que sea posible un

control organizado de los cambios. La configuración del software está compuesta por un

conjunto objetos interrelacionados, denominados elementos de configuración del

software, que son provocados par la actividades del desarrollo, de la ingeniería del

software.

Las líneas base nos permiten guiarnos para desarrollar los cambios, los objetos

forman un asociación que refleja las variantes y relaciones creadas, el control de

versiones son procedimientos y herramientas que ayudan a gestionar el uso de los

objetos. El control de cambios es una actividad procedimental que asegura la calidad en

los cambios del los ECS. La auditoria de configuración es una actividad de SQA

(Aseguramiento de la calidad del software) para asegurar la calidad durante los cambios.

Durante el proceso de construcción de un software, los cambios son inevitables.

Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han

analizado o pronosticado correctamente. La finalidad de la Gestión y configuración del

Software el conocer la estructura de procesos y herramientas para aplicar dentro de la

construcción del software que nos ayudan a controlar los cambios. Es importante

considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el

proceso de ingeniería para asegurar su control y calidad.

unidad 2 planificacion y modelado

Documents