INSTITUTO TECNOLOGICO SUPERIOR ESCRCEGA

Organismo Pblico Descentralizado de la Administracin

Pblica del Estado de Campeche

Reporte de instalacin de apache

Materia:
Planificacin y modelado

Alumno:
Olivera Sosa ngel Gabriel
Profesor:
Carolina Novelo Can
Semestre:
VII semestre

Ingeniera en sistemas computacionales

Escrcega, Campeche, a 06 de septiembre 2010.

Requerimientos de procesos
requerimientos de procesos son la especificacin de los estndares de
calidad que se deben utilizar en el proceso, una especificacin que el diseo
debe producir con una herramienta CASE particular y una descripcin del
proceso a seguir.

Requerimientos funcionales
Requerimientos funcionales. Son declaraciones de los servicios que
debe proporcionar el sistema, de la manera en que ste debe reaccionar a
entradas particulares y de cmo se debe comportar en situaciones particulares.
En algunos casos, los requerimientos funcionales de los sistemas tambin
pueden declarar explcitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen lo que el
sistema debe hacer. Estos requerimientos dependen del tipo de software que
se desarrolle, de los posibles usuarios del software y del enfoque general
tomado por la organizacin al redactar requerimientos. Cuando se expresan
como requerimientos del usuario, habitualmente se describen de una forma
bastante abstracta. Sin embargo. los requerimientos funcionales del sistema
describen con detalle la funcin de ste, sus entradas y salidas, excepciones,
etctera. Los requerimientos funcionales para un sistema software se pueden
ex.presar de diferentes formas. A continuacin se presentan algunos ejemplos
de estos requerimientos funcionales para un sistema de biblioteca universitario,
denominado LIBSYS, utilizado por estudiantes y personal docente que solicitan
libros y documentos de otras bibliotecas.
1. El usuario deber tener la posibilidad de buscar en el conjunto
inicial de la base de datos o seleccionar un subconjunto de ella.
2. El sistema deber proporcionar visores adecuados para que el
usuario lea documentos en el almacn de documentos.
3. A cada pedido se le deber asignar un identificador nico
(ID_PEDIDO), que el usuario podr copiar al rea de
almacenamiento permanente de la cuenta.

Estos requerimientos funcionales del usuario definen los recursos especficos

que el sistema debe proporcionar. Dichos requerimientos se toman del
documento de requerimientos del usuario, e ilustran los diferentes niveles de
detalle en que se pueden redactar los requerimientos funcionales (contraste los
requerimientos l y 3). El sistema LIBSYS es una interfaz nica para diferentes
bases de datos de artculos. Esto permite a los usuarios descargar copias de
artculos publicados en revistas. peridicos y publicaciones cientficas. Una
descripcin ms detallada de los requerimientos para el sistema en el cual se
basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniera de
requerimientos (Kontonya y Sommerville, 1998). La impresin en la
especificacin de requerimientos es la causa de muchos de los problemas de la
ingeniera del software. Para un desarrollador de sistema"! es natural dar

interpretaciones de un requerimiento ambiguo con el fin de simplificar su

implementacin. Sin embargo. a menudo no es lo que el cliente desea. Se
deben establecer nuevos requerimientos y hacer cambios en el sistema. Por
supuesto. esto retrasa la entrega de ste e incrementa los costes.
En principio, la especificacin de requerimientos funcionales de un sistema
debe estar completa y ser consistente. La completitud significa que todos los
servicios solicitados por el usuario deben estar definidos. La consistencia
significa que los requerimientos no deben tener definiciones contradictorias. En
la prctica, para sistemas grandes y complejos, es prcticamente imposible
alcanzar los requerimientos de consistencia y completitud. Una razn de esto
es que es fcil cometer errores y omisiones cuando se redactan
especificaciones para sistemas grandes y complejos. Otra razn es que los
stakeholders del sistema (vase el Captulo 7) tienen necesidades diferentes, y
a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando
los requerimientos se especifican por primera vez, por lo que se incluyen
requerimientos contradictorios en la especificacin. Es posible que los
problemas surjan solamente despus de un anlisis ms profundo.

Requerimientos no funcionales
Requerimientos no funcionales. Son restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el
proceso de desarrollo y estndares. Los requerimientos no funcionales a
menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican
a caractersticas o servicios individuales del sistema.

Los requerimientos no funcionales, como su nombre sugiere, son

aquellos requerimientos que no se refieren directamente a las funciones
especficas que proporciona el sistema, sino a las propiedades emergentes de
ste como la fiabilidad, el tiempo de respuesta y la capacidad de
almacenamiento. De forma alternativa, definen las restricciones del sistema
como la capacidad de los dispositivos de entrada/salida y las representaciones
de datos que se utilizan en las interfaces del sistema.
Los requerimientos no funcionales rara vez se asocian con
caractersticas particulares del sistema. Ms bien, estos requerimientos
especifican o restringen las propiedades emergentes del sistema. como se
explic en el Captulo 2. Por lo tanto, pueden especificar el rendimiento del
sistema, la proteccin, la disponibilidad, y otras propiedades emergentes. Esto
significa que a menudo son ms crticos que los requerimientos funcionales
particulares. Los usuarios del sistema normalmente pueden encontrar formas
de trabajar alrededor de una funcin del sistema que realmente no cumple sus
necesidades. Sin embargo. el incumplimiento de un requerimiento no funcional
puede significar que el sistema entero sea inutilizable.
Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de
fiabilidad, no se certificar como seguro para el funcionamiento; si un sistema
de control de tiempo real no cumple sus requerimientos de rendimiento, las

funciones de control no funcionarn correctamente. Los requerimientos no

funcionales no slo se refieren al sistema software a desarrollar. Algunos de
estos requerimientos pueden restringir el proceso que se debe utilizar para
desarrollar el sistema. Ejemplos de requerimientos de procesos son la
especificacin de los estndares de calidad que se deben utilizar en el proceso,
una especificacin que el diseo debe producir con una herramienta CASE
particular y una descripcin del proceso a seguir.
Los requerimientos no funcionales surgen de las necesidades del
usuario, debido a las restricciones en el presupuesto, a las polticas de la
organizacin, a la necesidad de interoperabilidad con otros sistemas software o
hardware, o a factores externos como regulaciones de segu

1. Requerimientos del producto. Estos requerimientos especifican el

comportamiento del producto. Algunos ejemplos son los
requerimientos de rendimiento en la rapidez de ejecucin del
sistema y cunta memoria se requiere; los requerimientos de
fiabilidad que fijan la tasa de fallos para que el sistema sea
aceptable; los requerimientos de portabilidad, y los requerimientos
de usabilidad.
2. Requerimientos organizacionales. Estos requerimientos se
derivan de polticas y procedimientos existentes en la
organizacin del cliente y en la del desarrollador. Algunos
ejemplos son los estndares en los procesos que deben utilizarse;
los requerimientos de implementacin. como los lenguajes de
programacin o el mtodo de diseo a utilizar, y los
requerimientos de entrega que especifican cundo se entregar el
producto y su documentacin.
3. Requerimientos externos. Este gran apartado incluye todos los
requerimientos que se derivan de los factores externos al sistema
y de su proceso de desarrollo. stos pueden incluir los

requerimientos de interoperabilidad que definen la manera en que

el sistema interacta con sistemas de otras organizaciones; los
requerimientos legislativos que deben seguirse para asegurar que
el sistema funcione dentro de la ley. y los requerimientos ticos.
Estos ltimos son puestos en un sistema para asegurar que ser
aceptado por sus usuarios y por el pblico en general.

Estudios de viabilidad
Para todos los sistemas nuevos, el proceso de ingeniera de
requerimientos debera empezar con un estudio de viabilidad. La entrada de
ste es un conjunto de requerimientos de negocio preliminares, una descripcin
resumida del sistema y de cmo ste pretende contribuir a los procesos del
negocio. Los resultados del estudio de viabilidad deberan ser un informe que
recomiende si merece o no la pena seguir con la ingeniera de requerimientos y
el proceso de desarrollo del sistema.
1. Un estudiode viabilidad es unestudio corto y orientado a
resolvervarias cuestiones:
2. Contribuye el sistema a los objetivos generales de la
organizacin?
3. Se puede implementar el sistema utilizando la tecnologa actual
y dentro de las restricciones de coste y tiempo?
4. Puede integrarse el sistemacon otrossistemas existentes en la
organizacin?
La cuestin de si el sistema contribuye a los objetivos del negocio es
crtica. Si no contribuye a estos objetivos, entonces no tiene un valor real en el
negocio. Aunque esto pueda parecerobvio, muchas organizaciones desarrollan
sistemas que no contribuyen a sus objetivos porque no tienen una clara
declaracin de estos objetivos, porque no consiguen definir los requerimientos
del negocio para el sistema o porque otros factores polticos u organizacionales
influyen en la creacin del sistema. Aunque no se trata explcitamente, un
estudio de viabilidad debera ser parte de la fase de Inicio del Proceso
Unificado de Rationa
Llevar a cabo un estudio de viabilidad comprende la evaluacin y
recopilacin de la informacin, y la redaccin de informes. La fase de
evaluacin de la informacin identifica la informacin requerida para contestar
las tres preguntas anteriores. Una vez que dicha informacin se ha
identificado,se debera hablar con las fuentes de informacin para descubrir las
respuestas a estas preguntas. Algunos ejemplos de preguntas posibles son:
1. Cmose las arreglara la organizacin si no se implementara
este sistema?
2. Culesson los problemas con los procesos actuales y cmo
ayudara unsistemanuevo
3. a aliviarlos?
4. Cul es la contribucin directa que har el sistema a los
objetivos y requerimientos del negocio?
5. La informacin se puede obtener y transferir a otros sistemas de
la organizacin?
6. Requiere el sistema tecnologa que no se ha utilizado
previamente en la organizacin?
7. A qu debe ayudar el sistema y a qu no necesita ayudar"

En un estudio de viabilidad, se pueden consultar las fuentes de

informacin, como los jefes de los departamentos donde se utilizar el sistema,
los ingenieros de software que estn familiarizados con el tipo de sistema
propuesto, los expertos en tecnologa y los usuarios finales del sistema.
Normalmente. se debera intentar completar un estudio de viabilidad en dos o
tres semanas. Una vez que se tiene la informacin, se redacta el informe del
estudio de viabilidad. Debera hacerse una recomendacin sobre si debe
continuar o no el desarrollo del sistema. En el informe, se pueden proponer
cambios en el alcance, el presupuesto y la confeccin de agendas del sistema
y sugerir requerimientos adicionales de alto nivel para ste.

Portabilidad
La portabilidad (en ingls porting) es uno de los conceptos clave en la
programacin de alto nivel.
Se define como la caracterstica que posee un software para ejecutarse
en diferentes plataformas, el cdigo fuente del software es capaz de reutilizarse
en vez de crearse un nuevo cdigo cuando el software pasa de una plataforma
a otra. A mayor portabilidad menor es la dependencia del software con
respecto a la plataforma.
El prerrequisito para la portabilidad es la abstraccin generalizada entre
la aplicacin lgica y las interfaces del sistema. Cuando un software se puede
compilar en diversas plataformas (x86, IA64, amd64, etc.), se dice que es
multiplataforma. Esta caracterstica es importante para el desarrollo de
reduccin costos, cuando se quiere hacer una misma aplicacin.
En algunos casos el software es "independiente" de la plataforma y
puede ejecutarse en plataformas diversas sin necesidad de ser compilado
especficamente para cada una de ellas, a este tipo de software se le llama
interpretado, donde un "intrprete" traduce (propiamente interpreta) las
instrucciones a tiempo de ejecucin para que sean entendidas por diferentes
plataformas.