Diseño de Sistemas – Presentación del Proyecto Final

DISEÑO DE SISTEMAS

“Formato de Presentación de
Proyecto Final”

Organización del Trabajo

Año 2016

1
 Diseño de Sistemas – Presentación del Proyecto Final

Portada
Colocar portada referente al proyecto.

Título del Proyecto

Especificar el título completo del proyecto, nombre de la carrera, nombre de la materia, año,
autores, L.U., mail de contacto. (Letra Arial, Tamaño 18)

Formato de Presentación
Hoja A4.

Títulos: Fuente Arial tamaño 16

Subtítulos: Fuente Arial Tamaño 14

2,5 cm de margen de cada lado

Letra de Texto: Arial Tamaño 11

Índice de Contenidos, de tablas y de figuras.

Antecedentes de Software
Son todos aquellos trabajos de software que preceden al que se está realizando, pero que además
guarda mucha relación con los objetivos del estudio que se aborda.

Justificación
La justificación explica de forma convincente el motivo por el qué y para qué se va a realizar una
investigación o un proyecto.

Para efectuar la justificación es necesario entender bien el asunto que se va a investigar o a

realizar, para explicar el por qué es conveniente desarrollar la investigación o el proyecto, además
de los beneficios que se conseguirán al solucionar la problemática que se expone.

2
 Diseño de Sistemas – Presentación del Proyecto Final

Objetivos Generales
Los objetivos generales corresponden a las finalidades genéricas de un proyecto o entidad.

No señalan resultados concretos no directamente medibles por medio de indicadores pero sí que
expresan el propósito central del proyecto. Tienen que ser coherentes con la misión de la
entidad. Nos debemos preguntar ¿por qué se hace el proyecto?

Los objetivos generales se concretan en objetivos específicos.

Objetivos específicos
Se derivan de los objetivos generales y los concretan, señalando el camino que hay que seguir
para conseguirlos. Indican los efectos específicos que se quieren conseguir aunque no explicitan
acciones directamente medibles mediante indicadores. Nos debemos preguntar ¿para qué se hace
el proyecto?

Requisitos funcionales y no funcionales de un

Sistema
Un requisito funcional define una función del sistema de software o sus componentes. Una
función es descrita como un conjunto de entradas, comportamientos y salidas. Los requerimientos
funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades
específicas que se supone, un sistema debe cumplir. Los requerimientos de comportamiento para
cada requerimiento funcional se muestran en los casos de uso. Son complementados por los
requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.

Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los

comportamientos del sistema.

Típicamente, un analista de requisitos genera requisitos funcionales después de realizar los casos
de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un
proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos
(casos de uso y requisitos) se complementan en un proceso bidireccional.

Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta
información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para
seguir al mismo durante el desarrollo del producto.

El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y
concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser
descubiertas por interacción con usuarios, inversores y otros expertos en la organización.

3
 Diseño de Sistemas – Presentación del Proyecto Final

Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de

software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un
sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos
funcionales. Por tanto, se refieren a todos los requisitos que no describen información a guardar,
ni funciones a realizar.

Algunos ejemplos de requisitos no funcionales típicos son los siguientes:

 rendimiento
 disponibilidad
 accesibilidad
 usabilidad
 estabilidad
 portabilidad
 costo
 operatividad
 interoperabilidad
 escalabilidad
 concurrencia
 mantenibilidad
 interfaz

En esta etapa se deberá presentar:

 Portada, Título del Proyecto y Formato.

 Antecedentes de software.
 Justificación del proyecto, incluyendo la descripción del problema.
 Objetivos generales y específicos.
 Requisitos funcionales y no funcionales del sistema.

MÉTODO DEL CICLO DE VIDA DE DESARROLLO DE

LOS SISTEMAS
El método del Ciclo de vida para el desarrollo de sistemas (SDLC) es el conjunto de actividades
que los analistas, diseñadores y usuarios realizan para desarrollan e implantar un sistema de
información. Esta sección examina cada una de las seis actividades que constituyen el ciclo de vida
de desarrollo de sistemas. En la mayor parte de las situaciones dentro de una empresa todas las
actividades están muy relacionadas, en general son inseparables, y quizá sea difícil determinar el
orden de los pasos que se siguen para efectuarlas. Las diversas partes del proyecto pueden

4
 Diseño de Sistemas – Presentación del Proyecto Final

encontrarse al mismo tiempo en distintas fases de desarrollo; algunos componentes en la fase de

análisis mientras que otros en etapas avanzadas de diseño.

Investigación preliminar
Cuando se formula la solicitud del sistema comienza la primera actividad de sistemas, la
investigación preliminar, esta actividad tiene 3 (tres) partes

Aclaración de la solicitud: Antes de considerar cualquier investigación de sistemas, la solicitud del

proyecto debe examinarse para determinar con precisión lo que el solicitante desea. La solicitud
del proyecto debe estar claramente planteada.

Estudios de factibilidad

El proyecto debe ser factible de desarrollarse. El estudio de factibilidad, es una tarea que suele
estar organizada y realizada por los analistas de sistemas. El estudio consume aproximadamente
entre un 5% y un 10% del costo estimado total del proyecto, y el período de elaboración del
mismo varía dependiendo del tamaño y tipo de sistema a desarrollar.

Factibilidad Técnica

Es una evaluación que demuestre que el sistema puede ponerse en marcha y mantenerse,
mostrando evidencias de que se ha planeado cuidadosamente, contemplado los problemas que
involucra y mantenerlo en funcionamiento.

Debemos hacernos las siguientes preguntas; El trabajo para el proyecto: ¿Puede realizarse con el
equipo actual? ¿Existe personal disponible para desarrollarlo? ¿Se necesita nueva tecnología?

Factibilidad Económica

Los beneficios que se obtienen del sistema deben ser superiores a los costos, lo que significa que
la inversión que se está realizando es justificada por la ganancia que se generará. Para ello es
necesario trabajar con un esquema que contemple los costos y las ventas:
Costos: Debe presentarse la estructura de los costos contemplando costos fijos y variables.
Ventas: En este punto el precio del producto o servicio es fundamental, ya que determina el
volumen de ventas, por lo que debe explicarse brevemente cómo se ha definido éste. Debe
mostrarse también estimaciones de ventas (unidades y en dinero) para un periodo de al menos 1
año, justificando cómo se han calculado (a través de investigaciones de mercado, estadísticas
anteriores, etc).

Factibilidad Operacional:

Se refiere a que debe existir el personal capacitado requerido para llevar a cabo el proyecto y así
mismo, deben existir usuarios finales dispuestos a emplear los productos o servicios generados
por el proyecto o sistema desarrollado. Si se desarrolla el sistema: ¿Será utilizado? ¿Existirá
resistencia al cambio por parte del los usuarios que van a utilizar el proyecto que dé como
resultado la disminución de los beneficios del proyecto?

5
 Diseño de Sistemas – Presentación del Proyecto Final

Aprobación de la solicitud: No todos los proyectos solicitados son deseables o factibles. Algunas
organizaciones reciben tantas solicitudes de sus empleados que sólo es posible atender unas
cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los
planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo común es que
los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando esto
ocurre, la administración decide qué proyectos son los más importantes y decide el orden en que
se llevarán a cabo. Muchas organizaciones desarrollan sus planes para sistemas de información
con el mismo cuidado con el que planifican nuevos productos y programas de fabricación o la
expansión de sus instalaciones. Después de aprobar la solicitud de un proyecto se estima su costo,
el tiempo necesario para terminarlo y las necesidades de personal; con esta información se
determina dónde ubicarlo dentro de la lista existente de proyectos. Más adelante, cuando los
demás proyectos se han completado, se inicia el desarrollo de la aplicación propuesta.

En esta etapa se deberá presentar:

 Factibilidad técnica
 Factibilidad económica
 Factibilidad operativa

Determinación de los requerimientos del sistema

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la
parte de la empresa u organización que se encuentra bajo estudio, es por esa razón que el proceso
de adquirir información se denomina, con frecuencia, investigación detallada. Los analistas, al
trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para
dar respuesta a las siguientes preguntas clave: ¿Qué es lo que se hace?

¿Cómo se hace?
¿Con qué frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o de decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema?
¿Si existe un problema, qué tan serio es?
¿Si existe un problema, cuál es la causa que lo origine?

Para contestar estas preguntas, el analista conversa con varias personas para reunir los detalles
relacionados con los procesos de la empresa u organización, sus opiniones sobre porqué ocurren
las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Se emplean entrevistas
para obtener esta información o cuestionarios cuando no es posible entrevistar, en forma
personal, a los miembros de grupos grandes dentro de la organización. Asimismo, las
investigaciones detalladas requieren el estudio de manuales y reportes, la observación en

6
 Diseño de Sistemas – Presentación del Proyecto Final

condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y
documentos con el fin de comprender el proceso en su totalidad. Conforme se reúnen los detalles,
los analistas estudian los datos sobre requerimientos con la finalidad de identificar las
características que debe tener el nuevo sistema, incluyendo la información que deben producir los
sistemas junto con características operacionales tales como controles de procesamiento, tiempos
de respuesta y métodos de entrada y salida.

En esta etapa se deberá presentar:

 Entrevistas y cuestionarios formales con las correspondientes preguntas hacia

los interesados en el proyecto.
 Informes, documentos del sistema antiguo a fin de determinar los cambios que
debe producir el sistema a desarrollarse.
 Procesos del sistema conducidos por CASOS DE USO.

Diseño del sistema

El diseño de un sistema de información produce los detalles que establecen la forma en la que el
sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas
en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de
desarrollo del software, a la que denominan diseño físico.

Los analistas de sistemas comienzan el proceso de diseño identificando los reportes y demás
salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisión los datos
específicos para cada reporte y salida. Es común que los diseñadores hagan un bosquejo del
formato o pantalla que esperan que aparezca cuando el sistema esté terminado. Lo anterior se
efectúa en papel o en la pantalla de una terminal utilizando para ello alguna de las herramientas
automatizadas disponibles para el desarrollo de sistemas.

El diseño de un sistema también indica los datos de entrada, aquellos que serán calculados y los
que deben ser almacenados. Así mismo, se escriben con todo detalle los procedimientos de
cálculo y los datos individuales. Los diseñadores seleccionan las estructuras de archivo y los
dispositivos de almacenamiento, tales como discos, cintas magnéticas o incluso archivos de papel.
Los procedimientos que se escriben indican cómo procesar los datos y producir las salidas.

7
 Diseño de Sistemas – Presentación del Proyecto Final

Los documentos que contienen las especificaciones de diseño representan a éste de muchas
maneras (diagramas, tablas, y símbolos especiales). La información detallada del diseño se
proporciona al equipo de programación para comenzar la fase de desarrollo de software.

Los diseñadores son los responsables de dar a los programadores las especificaciones de software
completas y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores
contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores
cuando utilizan las especificaciones del diseño.

En esta etapa se deberá presentar:

 Diagrama de Entidad Relación Extendido, en caso de trabajar con Base de Datos

relacionales.
 Modelo relacional y modelo de la base de datos en forma gráfica
 U.M.L
o Diagramas de Clases orientadas a Base de Datos
o Diagrama de Clases orientada al Diseño Arquitectónico de Software
o Diagrama de Secuencia de los movimientos más importantes del
sistema.
o Maquinas de estado
o Diagramas de actividad.
 Layouts del sistema, incluyendo informes.

Desarrollo del software

Los encargados de desarrollar software pueden instalar (o modificar y después instalar) software
comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección
depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la
disponibilidad de los programadores. Por regla general, los programadores (o analistas
programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente

8
 Diseño de Sistemas – Presentación del Proyecto Final

de profesionales. En empresas pequeñas donde no hay programadores, se pueden contratar

servicios externos de programación.

Los programadores también son responsables de la documentación de los programas y de

proporcionar una explicación de cómo y por qué ciertos procedimientos se codifican en
determinada forma. La documentación es esencial para probar el programa y llevar a cabo el
mantenimiento una vez que la aplicación se encuentra instalada.

En esta etapa se deberá presentar:

 Código fuente con documentación interna (lo codificado por el alumno)

Prueba de sistemas

Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para

asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo con las
especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como
entradas conjuntos de datos de prueba para su procesamiento y después se examinan los
resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas
observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa
antes de que la organización implante el sistema y dependa de él.

En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribió
los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean
completas e imparciales y, por otra, que el software sea más confiable.

Kendall & Kendall divide las pruebas en cuatro (4) tipos:

1) Pruebas de programas con datos de prueba. El analista conjuntamente con los programadores
comienzan a probar el sistema modulo por modulo para determinar si los modulo y cada
aplicación de ejecuta de manera correcta utilizándose para la prueba datos ficticios. Cuando se
realice este tipo de prueba la relación que pueda tener los módulos o las aplicaciones

2) Pruebas de enlace con datos de prueba, se utiliza para determinar errores que puedan existir
entre los enlaces o comunicación que se programa entre dos sistemas o entre dos módulos este
tipo de prueba se realiza con el analista utilizándose para ello datos ficticios

3) Prueba completa de sistema con datos de prueba, se realiza con datos ficticios utilizándose para

9
 Diseño de Sistemas – Presentación del Proyecto Final

ello una parte muy pequeña de la organización para aplicar lo que se conoce como las pruebas alfa
detectando errores funcionales.

4) Pruebas completas del sistema con datos reales, son pruebas betas que se realizan con casi la
totalidad de los usuarios quienes interactúan con el sistema para detectar errores

En esta etapa se deberá presentar:

Propuesta de implementación

 Pruebas manuales (Informe estadístico manual)

 Pruebas del sistema automatizadas (Selenium, JMeter, testLink)

Se deberá agregar:

 Metodologías ágiles con Scrum (Seguimiento 1 Sprint de 30 días)

Implantación (o implementación) y Evaluación

La implantación es el proceso de verificar e instalar nuevos equipos, entrenar a los usuarios,

instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.

Dependiendo del tamaño de la organización que empleará la aplicación y el riesgo asociado con su
uso, puede elegirse comenzar la operación del sistema sólo en un área de la empresa (prueba
piloto), por ejemplo en un departamento o con una o dos personas. Algunas veces se deja que los
dos sistemas, el viejo y el nuevo, trabajen en forma paralela con la finalidad de comparar los
resultados. En otras circunstancias, el viejo sistema deja de utilizarse determinado día para
comenzar a emplear el nuevo al día siguiente. Cada estrategia de implantación tiene sus méritos
de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la
estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema
se encuentre libre de problemas.

Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo las
organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con
el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento

10
 Diseño de Sistemas – Presentación del Proyecto Final

a las aplicaciones; realizar cambios y modificaciones en el software, archivos o procedimientos

para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las
organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua,
los sistemas de información deben mantenerse siempre al día. En este sentido, la implantación es
un proceso en constante evolución.

La evaluación de un sistema se lleva a cabo para identificar los puntos débiles y fuertes. La
evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

 Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su

facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información,
confiabilidad global y nivel de utilización.
 Impacto organizacional: Identificación y medición de los beneficios para la organización en
áreas tales como finanzas (costos, ingresos y ganancias), eficiencia operacional e
impacto competitivo. También se incluye el impacto sobre el flujo de información
interno y externo.
 Opinión de los administradores: Evaluación de las actitudes de directivos y administradores
dentro de la organización así como de los usuarios finales.
 Desempeño del desarrollo: La evaluación del proceso de desarrollo de acuerdo con criterios
tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares,
y otros criterios de administración de proyectos. También se incluye la valoración de los
métodos y herramientas utilizados en el desarrollo.

Desafortunadamente la evaluación de sistemas no siempre recibe la atención que merece. Sin

embargo, cuando se conduce en forma adecuada proporciona mucha información que puede
ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.

Esta etapa se evaluará en la Mesa de Examen Final de la materia considerando que

cada alumno que expone EN FORMA INDIVIDUAL debe tener conocimiento de todo el Ciclo
de Vida de Sistemas:

 Análisis
 Diseño
 Codificación
 Prueba

11
 Diseño de Sistemas – Presentación del Proyecto Final

Las Conclusiones
Se le llama también síntesis y no es más que la interpretación final de todos los datos con los
cuales se cierra la investigación iniciada. Sintetizar es recomponer lo que el análisis ha separado,
integrar todas las conclusiones y análisis parciales en un conjunto coherente que cobra sentido
pleno.

Características de las conclusiones.

1.- Es la síntesis final de la investigación realizada.

2.- Engloba todos los aspectos parciales.
3.- Es integradora por cuanto toma en cuenta todos los datos e informaciones.
4.- Puede ser enumeradas o no, pero en todo caso, debe ser suficientemente razonada,
convincente y desprendida de los hechos propios de la investigación, concretamente de las tablas
y demás representaciones gráficas.
5.- Está necesariamente en una interrelación directa con cualquiera de las variables
planteadas en el problema seleccionado.
6.- Puede o no utilizar cifras explicativas, expuestas en los cuadros, cuestión muy usual
en los informes técnicos. Por ejemplo el desempleo subió en el período 2001-2002 al 19%, así se
incorporaron a este sector de la población unos 2.000.000 venezolanos, cifra superior en un 3% al
período 2000-20001.
7.- Las conclusiones implican una evaluación final de la investigación ¿Qué obtuve? ¿Qué
logré? ¿Cuáles son esos resultados?
8.- Las conclusiones están referidas, sólo al trabajo investigado, independientemente de
otras investigaciones similares.
9.- Las conclusiones pueden o no confirmar la hipótesis planteada en el marco teórico.
10.-Las conclusiones pueden generar otras investigaciones, el conocimiento no es finito,
es más que todo aproximativo, siempre nos estaremos acercando a la verdad.
11.- Las conclusiones deben plantearse con un alto margen de seguridad, por lo cual es
recomendable los términos afirmativos. Alguna duda sobre algún aspecto particular de la
investigación debe quedar expresamente señalado y esto no debe incidir en la estructura
fundamental de las conclusiones.

Anexos
Los Anexos son un apéndice del trabajo que podemos insertar al final del mismo, antes de la
bibliografía. Se trata de reproducciones de documentos auténticos e imprescindibles, que han sido
utilizados o ilustran aspectos del trabajo. No todos los trabajos los requieren. Son oportunos
siempre que faciliten e ilustren la lectura del estudio.

12
 Diseño de Sistemas – Presentación del Proyecto Final

Esta etapa se deberá presentar:

 Conclusiones.
 Anexos.

Profesores:

Ing. Fabián Leguizamón

Lic. Gustavo Ariel Paszco

13