Introduccion

1.1- Resumen ejecutivo (Maximo 2 paginas)

ES UNA EMPRESA DE REGIMEN GUBERNAMENTAL

Por lo que no es un proyecto de beneficio econmico directamente pero si un impacto en el
recimiento de la institucin aunado a esto una mejor calidad en los jvenes que estudian
actualmente en la misma


VISION DE PROYECTO

Revisar y detectar los problemas con los que cuenta la universidad as mismo poder mejorar
el nivel de infraestructura en el plantel esto mejorando la calidad educativa en los jvenes
as mismo esto brindando mejores servicio y proyectando un crecimiento en poco tiempo.
Otro factor indispensable es contribuir a que se exploten los recursos con los que cuenta
actualmente la universidad,


Metas

Mantener una conectividad de red estable y en ptimas condiciones


Diseo del Sistema

A partir de la informacin recolectada y posteriormente analizada, se comenz adesarrollar
el prototipo de red, que permitiera una comunicacin entre los equipos


Proyecto

El proyecto esta planeado en etapas para no afectar las las actividades de los alum n labores
administrativas por lo cual esto se entreg en diagra o de los tiempos requeridos para
implementar la red


Razones para instalar redes

Principalmente es para compartir recursos, como discos, impresoras y etc. etc. entre otras
ms importantes:



Disponibilidad del software de redes.

Trabajo en comn
Actualizacin del software
Copia de seguridad de los datos.
Uso compartido.


Descripcion de problema

Se detestaron problemas con los cervicios informaticos que no permitia ingresar los datos
de los alumnus en la base de datos de la escuela. Fallas de comunicaciony estabilidad en las
redes internas del instituto, actualisar los softwares obsoletos, y obtimisar los equipos de la
escuela


El propsito de la gestin de requerimientos es asegurar que el proyecto cumple con las expectativas de
sus clientes y de sus interesados, tanto externos como internos, siendo el proceso que garantiza el
vnculo entre lo que esperan los clientes y usuarios, y lo que los equipos de proyecto tienen que
desarrollar.

Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los proyectos de
desarrollo de software donde adquieren todo su sentido, garantizando el proceso y sirviendo de
referencia para asegurar y controlar los cambios que en el proyecto puedan surgir (trazabilidad). A
menudo, incluye la elaboracin de planes especficos para diferentes aspectos como la recoleccin,
gestin e integracin de los requerimientos.


Definicin de requerimiento y Stakeholders (Interesados)

Un requerimiento es la condicin o capacidad que debe tener un sistema, producto, servicio o
componente para satisfacer un contrato, estndar, especificacin, u otros documentos formalmente
establecido.

Son todas aquellas caractersticas observables que cualquier interesado desea que estn contenidas
en el sistema. Como requisitos se incluyen las necesidades, deseos y expectativas del patrocinador,
cliente, usuarios, y otros interesados.

Como requerimiento se podra establecer:


Una capacidad necesaria para un cliente o usuario que soluciona un problema o consigue
un objetivo.
Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del proyecto.
Una restriccin impuesta por algn interesado

Definiendo el concepto de stakeholder (interesado) como alguien que est afectado por el proyecto que
se desarrolla, podremos encontrar que hay de dos tipos:

Usuarios: Aquellos que utilizaran el sistema.
Clientes: aquellos que requieren el sistema y son los responsables de su validacin o aprobacin.

Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces podremos
encontrarnos que hay un conflicto entre los requerimientos de ambos. En la mayora de los casos,
los requerimientos de los clientes tienen prioridad sobre los requerimientos de los usuarios.



Descripcion de propuesta


Analisis del problema
o Equipos demasiado lentos en arrancar
o Problemas de la cada de red
o Actualizacin de software ya que son muy obsoletos los que se tienen
y dar mantenimiento a los equipos y programas
o Problemas de seguridad para restringir paginas para los alumnos
o Los procesadores de los equipos son muy viejos y dificultar el trabajo
o Actualizar la informacin de la pgina web para mayor atractivo para
los interesados
o Implementar una base de datos para un mejor control de la
informacin de los alumnos
o Mejorar la comunicacin del personal de la empresa y entre los
equipos de computo
o Administracin del inventario del hardware del rea de
Comunicaciones
o Asesoramiento al personal con los nuevos equipos




2.2- Analisis de factibilidad
Los recursos son los medios utilizados por las empresas para ejecutar sus actividades y de esta
manera alcanzar sus objetivos. En las empresas hay gran cantidad de recursos tales como: personas,
mquinas, dinero, materiales, etc., los cuales son obtenidos del medio ambiente exterior y entran a la
empresa a cumplir diferentes funciones las cuales son:
Unos son procesados y transformados en bienes o servicios para luego ser distribuidos entre los
consumidores o usuarios, quienes se hallan ubicados en el medio ambiente externo.
Otros recursos ingresan a la empresa como procesadores o transformadores, efectuando su accin
sobre los anteriores. Algunos contribuyen a la consecucin de nuevos recursos para la empresa.
Otros ayudan a la colocacin de los bienes y servicios producidos en el medio ambiente externo.
Otros se dedican a coordinar las acciones de los dems recursos, para que stas se encaminen hacia
la consecucin de los objetivos empresariales.
Los recursos pueden ser propios o en calidad de prstamo lo importante es la funcin que cumplen
dentro de la empresa. Los resultados que presenta la empresa que pueden ser bienes o servicios por
su venta permiten la continuidad en su funcionamiento. La empresa no slo tiene influencia en la
comunidad por sus productos sino que el salario pagado a sus empleados permite que se compren
otros productos, los impuestos pagados por la empresa permiten obras sociales y su control a los
desperdicios permita la conservacin del medio ambiente.
RECURSOS BSICOS DE LA EMPRESA

Los recursos se clasifican en:
Recursos Humanos
Recursos Financieros
Recursos Materiales o Fsicos
Recursos Tecnolgicos
Recursos Administrativos











































Anlisis de Requerimientos
El propsito de la gestin de requerimientos es asegurar que el proyecto cumple con las expectativas de sus clientes y
de sus interesados, tanto externos como internos, siendo el proceso que garantiza el vnculo entre lo que esperan los
clientes y usuarios, y lo que los equipos de proyecto tienen que desarrollar.
Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los proyectos de desarrollo de
software donde adquieren todo su sentido, garantizando el proceso y sirviendo de referencia para asegurar y controlar
los cambios que en el proyecto puedan surgir (trazabilidad). A menudo, incluye la elaboracin de planes especficos para
diferentes aspectos como la recoleccin, gestin e integracin de los requerimientos.
Definicin de requerimiento y Stakeholders (Interesados)
Un requerimiento es la condicin o capacidad que debe tener un sistema, producto, servicio o componente para
satisfacer un contrato, estndar, especificacin, u otros documentos formalmente establecido.
Son todas aquellas caractersticas observables que cualquier interesado desea que estn contenidas en el sistema.
Como requisitos se incluyen las necesidades, deseos y expectativas del patrocinador, cliente, usuarios, y otros
interesados.
Como requerimiento se podra establecer:
Una capacidad necesaria para un cliente o usuario que soluciona un problema o consigue un objetivo.
Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del proyecto.
Una restriccin impuesta por algn interesado

Definiendo el concepto de stakeholder (interesado) como alguien que est afectado por el proyecto que se desarrolla,
podremos encontrar que hay de dos tipos:
Usuarios: Aquellos que utilizaran el sistema.
Clientes: aquellos que requieren el sistema y son los responsables de su validacin o aprobacin.

Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces podremos encontrarnos que
hay un conflicto entre los requerimientos de ambos. En la mayora de los casos, los requerimientos de los clientes tienen
prioridad sobre los requerimientos de los usuarios.
Caractersticas de los requerimientos
Un requerimiento debe cumplir ciertos criterios y caractersticas:
nico: El requerimiento debe poder ser interpretado inequvocamente de una sola manera.
Verificable: Su implementacin debe poder ser comprobada. El test debe dar como resultado CORRECTO o
INCORRECTO.
Claro: Los requerimientos no deben contener terminologa innecesaria. Deben ser establecidos de forma clara y
simple.
Viable (realstico y posible): El requerimiento debe ser factible segn las restricciones actuales de tiempo, dinero y
recursos disponibles.
Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita el requerimiento o bien si la
retirada de dicho requerimiento no tiene ningn efecto

Adems de los criterios para los requerimientos individuales, para el conjunto de ellos debe cumplirse:
Independiente: Para comprender el requerimiento no debe ser necesario el conocimiento de otro.
Consistente: No debe existir ningn conflicto entre requerimientos. Los conflictos pueden ser: - Directos: Cuando
ante una misma situacin, cabe esperar comportamientos diferentes. - Indirectos: Se produce cuando no es posible
cumplir con dos requisitos al mismo tiempo, aunque describan funcionalidades distintas.
No redundante: Cada requerimiento debe ser formulado una sola vez, y no sobreponerse con otros requerimientos.
Completo: Un requerimiento debe ser especificado teniendo en cuenta todas las condiciones que puedan ocurrir.

Organizacin y estructura de la gestin de requerimientos Segn el origen y caractersticas, los requisitos pueden
dividirse en diferentes tipos., que pueden representarse en forma de pirmide, en cuyo nivel superior se sitan las
necesidades de los interesados. En los niveles ms bajos son caractersticas, casos de uso y requisitos
complementarios tal como se muestra en la figura:
Necesidad: Un interesado demanda un
requerimiento.
Caracterstica: Un servicio proporcionado por el sistema, por lo general formulado por un analista de negocios.
Caso de uso: Una descripcin del comportamiento del sistema descrito como una secuencias de acciones.
Requisito complementario: Otro requisito (generalmente no funcional) que no puede ser contemplado en los casos
de uso.
Caso de prueba: Una especificacin de las entradas necesarias para una prueba, las condiciones de ejecucin y
resultados esperados. Tiene el papel de comprobar si los casos de uso derivados de los casos de prueba y los requisitos
complementarios se aplican correctamente.
Escenario: Una secuencia especfica de acciones o una ruta de acceso especfica a travs de un caso de uso.
Ayudan a derivar en casos de uso a partir de los casos de prueba y facilitan el diseo e implementacin a travs de los
casos de uso.

Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican diferentes niveles de detalle. Cuanto
menor sea el nivel, ms detallado es el requisito. Sin embargo, corresponde a los analistas de negocio decidir el nivel de
detalle en cada nivel, aunque no sera incorrecto establece requisitos muy detallados en el nivel de necesidades.
Trazabilidad
La trazabilidad de los requerimientos se refiere a la documentacin de la vida de cada uno de ellos, y debe permitir
seguir el historial desde su formulacin original hasta el momento actual. Cada cambio realizado debe por tanto ser
documentado para conseguir dicha trazabilidad. Incluso la implementacin de las caractersticas determinadas por los
requerimientos debe poder ser trazada.
Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario final, etc... Todas y cada una de ellas
tienen diferentes requerimientos para el producto. Utilizando la trazabilidad, puede seguirse el historial
de una caracterstica implementada hasta las personas o grupos que la solicitaron durante la generacin de los
requerimientos, permitiendo un rpido anlisis en cada fase del proyecto para:
Determinar la visin original y permitir una discusin controlada de los cambios en el alcance.
Determinar qu elementos se vern afectados cuando consideramos agregar un nuevo requerimiento o modificar uno
ya existente.
Verificar que el requerimiento contempla todos lo que el interesado solicit.
Evitar el Gold Platting: Verificar que la aplicacin no implementa funcionalidades no demandadas por el cliente.

Diferencia entre requerimiento y requisito
en Anlisis y Diseo de Sistemas de
Informacin.
Qu es un requerimiento/requisito?
Caractersticas de los requerimientos
Los requerimientos deben especificarse antes de intentar comenzar la construccin del producto, sin ellos no podr ser
posible llevar a cabo las etapas de diseo y construccin correctamente. Los mismos pueden verse como una
declaracin abstracta de alto nivel de un servicio que el sistema debe proporcionar, como una definicin matemtica
detallada y formal. Los requisitos cumplen una doble funcin ya que son la base para una oferta de contrato, por lo tanto
deben estar abiertos a la interpretacin. Adems son la base para redactar el contrato en s mismo.
Los requisitos una vez establecidos y documentados, sufren cambios continuos, en este sentido, no se trata la obtencin
ni el anlisis de los mismos, se trata de su gestin, es decir, el seguimiento respecto a los cambios que se generan
durante el ciclo de vida del proyecto y las herramientas de gestin de requisitos que auxilian y/o automatizan estas
tareas. El uso de herramientas para auxiliar la gestin de requisitos se ha convertido en un aspecto importante de la
Ingeniera de Sistemas y el diseo. Considerando el tamao y la complejidad del desarrollo, las herramientas vienen
siendo algo esencial. Las herramientas que los gestores de requisitos utilizan para automatizar los procesos de
Ingeniera de Requisitos han disminuido el trabajo duro en el mantenimiento de requisitos, aadiendo beneficios
significativos al reducir errores. Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de
requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en
grupo. A continuacin se presentan las ms importantes.
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su
capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o
del proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos
que vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la
informacin suficiente para su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin,
no debe causar confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los
siguientes mtodos de verificacin, inspeccin, demostracin o pruebas.
Tipos de requisitos
Los requerimientos pueden dividirse en varios tipos dentro de ellos, se har referencia a los siguientes:
Requisitos de usuario
Requisitos del sistema
Requisitos funcionales
Requisitos no funcionales

Requisitos de usuario
Declaraciones en lenguaje natural y en diversos diagramas de los servicios del sistema y de las restricciones bajo las
que debe operar.
1.- El sistema debe permitir representar y acceder a archivos externos creados por otras herramientas.
2. Sentencias muy generales sobre lo que el sistema debera hacer.
Requisitos del sistema
Un documento estructurado que determina las descripciones detalladas de los servicios de sistema. Escrito como
contrato entre el cliente y el contratista.
1.- El usuario deber poder definir el tipo de un nuevo archivo externo.
2.- Cada tipo de archivo tendr una herramienta asociada, que se le aplicar. 3.- Cada tipo de archivo se representar
con un icono especfico.
4.- El usuario deber poder definir el icono que representa un tipo de archivo externo.
5.- Cuando el usuario selecciona un icono que representa un archivo externo, el efecto es aplicar la herramienta
asociada con este tipo de archivo al archivo representado por el icono seleccionado.
Requisitos funcionales
Declaracin de los servicios que el sistema debe proporcionar, cmo debe reaccionar a una entrada particular y cmo se
debe comportar ante situaciones particulares. Describen la funcionalidad del sistema, y dependen del tipo de software,
del sistema a desarrollar y de los usuarios del mismo.
Por lo general se describen mejor a travs del modelo de Casos de uso y los Casos de uso como tal. Por lo tanto los
requerimientos funcionales especifican el comportamiento de entrada y salida del sistema y surgen de la razn
fundamental de la existencia del producto.
Requisitos no funcionales
Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Restricciones que afectan
a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estndares,
etc.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema,
como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, etc.
1.- Sobre el Anlisis de Requerimientos. Los requerimientos son aquellas cosas que un cliente espera resolver o un
usuario espera ver resuelto, y no es lo que el tcnico desea hacer. Cuando se hace Anlisis de Requerimientos se
desea aclarar y dejar muy claro los que quieren usuarios, clientes y operadores. Se usan diversas herramientas de
modelado y el analista debe tener un fuerte manejo personas. Es un anlisis situado slo en requerimientos. 2.- Sobre el
Anlisis de Requisitos. Los requisitos son aquello que el sistema-solucin debe hacer o cumplir. Los requisitos suelen
confundirse como requerimientos pero en realidad los ltimos son un subconjunto extendido de los primeros. Cuando se
hace Anlisis de Requisitos se desea explicitar requisitos sin entrar en requerimientos. Aunque muchos requisitos se
derivan directamente de requerimientos, otros surgen de la experiencia y aplicacin de la tcnica que tengan por
prctica los analistas. Suelen usarse diversas herramientas de modelado de orientacin a aspectos lgicos y de
implantacin de sistemas.
Las actividades de este proceso se agrupan en dos grandes bloques.

En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseo de detalle del sistema de
informacin. La realizacin de estas actividades exige una continua realimentacin. En general, el orden real de
ejecucin de las mismas depende de las particularidades del sistema de informacin y, por lo tanto, de generacin de
sus productos.

En la actividad Definicin de la Arquitectura del Sistema, se establece el particionamiento fsico del sistema de
informacin, as como su organizacin en subsistemas de diseo, la especificacin del entorno tecnolgico, y sus
requisitos de operacin, administracin, seguridad y control de acceso. Se completan los catlogos de requisitos y
normas, en funcin de la definicin del entorno tecnolgico, con aquellos aspectos relativos al diseo y construccin que
sea necesario contemplar. Asimismo, se crea un catlogo de excepciones del sistema, en el que se registran las
situaciones de funcionamiento secundario o anmalo que se estime oportuno considerar y, por lo tanto, disear y probar.
Este catlogo de excepciones se utiliza como referencia en la especificacin tcnica de las pruebas del sistema.
El particionamiento fsico del sistema de informacin permite organizar un diseo que contemple un sistema de
informacin distribuido, como por ejemplo la arquitectura cliente/servidor, siendo aplicable a arquitecturas multinivel en
general. Independientemente de la infraestructura tecnolgica, dicho particionamiento representa los distintos niveles
funcionales o fsicos del sistema de informacin. La relacin entre los elementos del diseo y particionamiento fsico, y a
su vez, entre el particionamiento fsico y el entorno tecnolgico, permite una especificacin de la distribucin de los
elementos del sistema de informacin y, al mismo tiempo, un diseo orientado a la movilidad a otras plataformas o la
reubicacin de subsistemas.
El sistema de informacin se estructura en subsistemas de diseo. stos a su vez se clasifican como de soporte o
especficos, al responder a propsitos diferentes.
Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalacin, y
generalmente estn originados por la interaccin con la infraestructura tcnica o la reutilizacin de otros sistemas, con
un nivel de complejidad tcnica mayor.
Los subsistemas especficos contienen los elementos propios del sistema de informacin, generalmente con una
continuidad de los subsistemas definidos en el proceso de Anlisis del Sistema de Informacin.

Tambin se especifica en detalle el entorno tecnolgico del sistema de informacin, junto con su planificacin de
capacidades (capacity planning), y sus requisitos de operacin, administracin, seguridad y control de acceso.
El diseo detallado del sistema de informacin, siguiendo un enfoque estructurado, comprende un conjunto de
actividades que se llevan a cabo en paralelo a la Definicin de la Arquitectura del Sistema. El alcance de cada una de
estas actividades se resume a continuacin:
Diseo de la Arquitectura de Soporte, que incluye el diseo detallado de los subsistemas de soporte, el
establecimiento de las normas y requisitos propios del diseo y construccin, as como la identificacin y definicin de
los mecanismos genricos de diseo y construccin.


Diseo de la Arquitectura de Mdulos del Sistema, donde se realiza el diseo de detalle de los subsistemas
especficos del sistema de informacin y la revisin de la interfaz de usuario.
Diseo Fsico de Datos, que incluye el diseo y optimizacin de las estructuras de datos del sistema, as como su
localizacin en los nodos de la arquitectura propuesta.

En el caso de Diseo Orientado a Objetos, conviene sealar que el diseo de la persistencia de los objetos se lleva a
cabo sobre bases de datos relacionales, y que el diseo detallado del sistema de informacin se realiza en paralelo con
la actividad deDiseo de la Arquitectura de Soporte, y se corresponde con las siguientes actividades:
Diseo de Casos de Uso Reales, con el diseo detallado del comportamiento del sistema de informacin para los
casos de uso, el diseo de la interfaz de usuario y la validacin de la divisin en subsistemas.
Diseo de Clases, con el diseo detallado de cada una de las clases que forman parte del sistema, sus atributos,
operaciones, relaciones y mtodos, y la estructura jerrquica del mismo. En el caso de que sea necesario, se realiza la
definicin de un plan de migracin y carga inicial de datos.

Una vez que se tiene el modelo de clases, se comienza el diseo fsico en la actividadDiseo Fsico de Datos, comn
con el enfoque estructurado.
Una vez finalizado el diseo de detalle, se realiza su revisin y validacin en la actividadVerificacin y Aceptacin de la
Arquitectura del Sistema, con el objeto de analizar la consistencia entre los distintos modelos y conseguir la aceptacin
del diseo por parte de los responsables de las reas de Explotacin y Sistemas.
El segundo bloque de actividades complementa el diseo del sistema de informacin. En l se generan todas las
especificaciones necesarias para la construccin del sistema de informacin:
Generacin de Especificaciones de Construccin, fijando las directrices para la construccin de los componentes del
sistema, as como de las estructuras de datos.
Diseo de la Migracin y Carga Inicial de Datos, en el que se definen los procedimientos de migracin y sus
componentes asociados, con las especificaciones de construccin oportunas.
Especificacin Tcnica del Plan de Pruebas, que incluye la definicin y revisin del plan de pruebas, y el diseo de las
verificaciones de los niveles de prueba establecidos. El catlogo de excepciones permite, de una forma muy gil,
establecer un conjunto de verificaciones relacionadas con el propio diseo o con la arquitectura del sistema.
Establecimiento de Requisitos de Implantacin, que hace posible concretar las exigencias relacionados con la propia
implantacin del sistema, tales como formacin de usuarios finales, infraestructura, etc.

Finalmente, en la actividad de Presentacin y Aprobacin del Diseo del Sistema de Informacin, se realiza una
presentacin formal y aprobacin de los distintos productos del diseo.
Requisitos funcionales
Declaracin de los servicios que el sistema debe proporcionar, cmo debe reaccionar a una entrada particular y cmo se
debe comportar ante situaciones particulares. Describen la funcionalidad del sistema, y dependen del tipo de software,
del sistema a desarrollar y de los usuarios del mismo.
Por lo general se describen mejor a travs del modelo de Casos de uso y los Casos de uso como tal. Por lo tanto los
requerimientos funcionales especifican el comportamiento de entrada y salida del sistema y surgen de la razn
fundamental de la existencia del producto.
Requisitos no funcionales
Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Restricciones que afectan
a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estndares,
etc.
Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema,
como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, etc. Algunas propiedades de los requerimientos no
funcionales que hacen al producto atractivo, usable, rpido o confiable, son las siguientes:
Clasificacin de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus caractersticas no pueden ser
tratados iguales. Por ejemplo, los requerimientos de entrenamiento de personal no son tratados de la misma manera que
los requerimientos de una conexin a Internet.
La siguiente es una recomendacin de como pueden ser clasificados los requerimientos aunque cada proyecto de
software pueda usar sus propias clasificaciones.
Requerimientos del "entorno"

El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos
que se clasifican en esta categora por que:
El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. Ejemplos del
entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como congestin en los
dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los requerimientos.
Requerimientos "ergonmicos"

El mas conocido de los requerimientos ergonmicos es la interface con el usuario o GUI (Graphic User Interface). En
otras palabras, los requerimientos ergonmicos son la forma en que el ser humano interactua con el ser sistema.
Requerimientos de Interface

La interface es como interactua el sistema con el ser humano o con otros sistemas (el enfoque es prcticamente el
opuesto a los requerimientos ergonmicos), La interface es la especificacin formal de los datos que el sistema recibe o
manda al exterior. Usualmente se especifica el protocolo, el tipo de informacin, el medio para comunicarse y el formato
de los datos que se van a comunicar.
Requerimientos funcionales

Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa el Que? Y no el Como?.
Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte
del cdigo del sistema.
Requerimientos de desempeo

Estos requerimientos nos informan las caractersticas de desempeo que deben de tener el sistema. Que tan rpido?,
Que tan seguido?, Cuantos recursos?, Cuantas transacciones? .
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeo de un
sistema es tan crtico como su funcionamiento.
Disponibilidad (en un determinado periodo de tiempo)

Este tipo de requerimientos se refiere a la durabilidad, degradacin, potabilidad, flexibilidad, contabilidad y capacidad de
actualizacin. Este tipo de requerimientos es tambin muy importante en sistemas de tiempo real puesto que estos
sistemas manejan aplicaciones crticas que no deben de estar fuera de servicio por periodos prolongados de tiempo.
Entrenamiento

Este tipo de requerimientos se enfoca a las personas que van usar el sistema. Que tipo de usuarios son?, Que tipo de
operadores?, Que manuales se entregarn y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de cdigo dentro de el sistema, son muy
importantes en el proceso de diseo ya que facilitan la introduccin y aceptacin de el sistema en donde ser
implementado.
Restricciones de diseo

Muchas veces las soluciones de un sistema de software son normadas por leyes o estndares, este tipo de normas caen
como "restricciones de diseo".
Materiales

Aqu se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir los
costos de industrializacin del sistema.
Bibliografa
http://www.liderdeproyecto.cooct.-13m/manual/los_requerimientos.html 24/10/2013
http://manuel.cillero.es/doc/metrica-3/procesos-principales/desarrollo/dsi 24/10/2013
http://www.monografias.com/trabajos92/gestion-requisitos/gestion-requisitos.shtml#queesunrea 24-oct.-
13
http://www.oocities.org/txmetsb/req-mgm-3.htm 24-oct.-13

1. INTRODUCCIN
1. Propsito

El Propsito del proyecto es mejorar la calidad en la infraestructura de la
universidad para aumentar el nmero de matrcula en la institucin, as mismo
contribuir a que los alumnos cuenten con los recursos y la estabilidad necesaria en
el funcionamiento para que puedan realizar sus tareas del mismo modo facilitar a
los profesores el buen funcionamiento en sus equipos para no estar retrasando
procesos de revisin y preparacin de clase aunado a esto en los procesos
administrativos se reflejara mayor agilidad al realizar trmites y servicios
solicitados por alumnos y por oficinas centrales,
Agrandes rasgos se optimizara y se dejara funcionando de manera estable todos
los servicios informticos
2. Fundamentos

Los fundamentos en que se basa el proyecto es en la necesidad que hay en la
institucin est necesidad se a derivado a que los procesos son tardados
traspapelados y en ocasiones tambin se perjudica el aprendizaje de los alumnos
ya que ellos no estn contando con las herramientas necesarias para poder
mejorar el nivel de estudios,
Por otra parte se ha llevado un estudio que muestra la inconformidad y las
necesidades que presentan los procesos administrativos por lo cual se est
trabajando en base a la informacin recopilada en la institucin
3. Alcance

El alcance del proyecto es mantener la estabilidad en la red de la escuela usando
las los estndares de cableado estructurado, esto siempre y cuando no se vea
afectada por factores externos como el caso en que el proveedor de servicio de
internet tuviese algn problema en su infraestructura y esto ocasiones que no
tengamos el servicio
de internet y sin este no poder poner en lnea nuestros servicios
Otro de los alcances son que cado persona, sea coordinador, personal
administrativo y/o Profesores tengan acceso a los recursos con los que cuenta en
la universidad y del mismo modo sean productivos estos recursos
4. Definiciones, acrnimos y abreviaturas

Cableado estructurado: es el cable de red de las computadoras lo que sirve para
conectarlas a la red.
Estndares: hace referencia a los procesos establecidos para llevar un orden en el
cableado
Recursos: son los equipos de los cuales se puede hacer uso para mejorar los
servicios (impresoras, computadoras, fax etc.)
5. Referencias

http://docente.ucol.mx/al940435/public_html/estandares.htm
http://redes2010.wordpress.com/estandares-de-red/
1. Descripcin general del proyecto
1. Tcnicas de recopilacin de informacin usadas (tarea T3)

Escogimos la entrevista porque nos dio mucha facilidad para poder obtener
informacin del usuario acerca de los problemas que presenta en los equipos de
cmputo.
Nuestras preguntas estn dirigidas para un pequeo grupo de personas del mismo
departamento, se realizar las mismas preguntas para diferentes departamentos
para que cada una de ellas proponga una solucin para sus equipos y llegar a una
solucin en general

2. Datos obtenidos con la aplicacin de las tcnicas (tarea T3)


mantenimiento a los equipos y programas


interesados
e datos para un mejor control de la informacin de los
alumnos
computo

s nuevos equipos

2. Requerimientos y restricciones
1. Requerimientos funcionales

2. Requerimientos no funcionales
3. Tabla de requerimientos elaborada en clase
3. Conclusin

Gracias a los datos obtenidos en las entrevistas y a los requerimientos que solicita
cada rea que conforman a la universidad nos a brindado un amplio panorama
para poder revisar los puntos estratgicos y crticos sobr los cuales tendremos
que enfocarnos para as poder tener un buen servicio y por consecuencia la
universidad pueda crecer y llegar a ser una de las universidades con mayor
competencia nivel acadmico
1. Aspectos relevantes















Diagrama de flujo















Topologia de red






Conclusiones generales
El desarrollo del anterior proyecto nos ha permitido adquirir conocimientos de vital
importancia que ms tarde nos sern tiles cuando sea necesario analizar, disear e
implementar una red.
En el diseo de una implementacin de red es necesario conocer con precisin el
reglamento existente de las instituciones a las cuales se est llevando a cabo el mismo,
apegarse a las normas establecidas para la instalacin de los servicios.
Al seleccionar hardware y software lo ideal es optar por lo mejor y lo que ms se acomode
a nuestras necesidades, jams se debe adquirir elementos de segunda mano ya que
pueden salir muy costosos en el futuro o incrementar los costos en el proyecto