Ambientes De Servicio
Páginas: 72 (17860 palabras)
Publicado: 14 de noviembre de 2013
UNIDAD 2. INGENIERIA DE REQUISITOS
Dentro de la Ingeniería de Software, hay una disciplina que se denomina Ingeniería de Requisitos. Está orientado a desarrollar requisitos a través de un proceso cooperativo e interactivo de analizar el problema, documentar las observaciones resultantes y checar lo obtenido.
Tradicionalmente se distinguen 3 actividades principales de la Ingeniería deRequisitos: captura o elicitación, modelado y validación de requisitos.
Los requisitos de un sistema de software se suelen clasificar en funcionales y no funcionales. Los funcionales son descripciones de lo que el sistema hace o debe hacer. Los no funcionales son restricciones globales sobre como debe construirse y funcionar el sistema.
A menudo, también se mencionan otros requisitos.Denominados Organizacionales, que engloban las razones de la creación del sistema, las restricciones del ambiente en el que el sistema funciona y el significado de los requisitos del sistema.
UML presta ayuda en la modelación de los requisitos funcionales, no así con los no funcionales. Respecto al organizacional, se puede hacer un modelo de negocios usando un diagrama de UML fuera de su uso habitual.1En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversionistas, que pueden entrar en conflicto entre ellos.
El propósitode la Ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
La Ingeniería de requisitos implica todas las actividades del ciclo de vida dedicadas a:
La educción (llamada también elicitación, por una mala traducción deelicitation) de los requisitos del usuario.
El análisis y negociación de requisitos para derivar requisitos adicionales.
La documentación de los requisitos como especificación.
La validación de los requisitos documentados contra las necesidades de usuario.
Así como los procesos que apoyan estas actividades.2
2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS
En un importante hospital español ocurrióhace unos años un sucedo del que puede extraerse no solo sarcásticos comentarios sobre la capacidad de determinadas compañías para llevar a cabo un desarrollo de software a nivel profesional, sino también interesantes lecciones sobre la dificultad de las actividades de obtención de requisitos.
Todo comenzó cuando un consultor recién titulado fue enviado por su empresa, una compañía de desarrollode software a medida, a la unidad de cuidados intensivos del hospital en cuestión. Su encargo era estudiar la forma de trabajo del personal, como paso previo al desarrollo de un sistema informático integral que mejoraría la eficacia en la gestión dela unidad. Es posible que otros consultores (o él mismo) fueran enviados a otras unidades simultáneamente, pero los autores solo cuentan coninformación de lo que ocurrió en la unidad de cuidados intensivos.
Tras un primer contacto optimista, donde la mayor parte del personal se ofreció colaborar, el consultor (que acudía puntualmente a tomar notas y preguntar a los médicos y enfermeras sobre como desarrollaban su trabajo) expresó públicamente su certeza en que el trabajo concluiría “como mucho, en un par de meses”. Algo sorprendente, puescualquier persona medianamente familiarizada con la obtención de los requisitos de un sistema de software de tal complejidad es consciente de que esto no suele ser tarea de “un par de meses”. Así, y contrariamente a su vaticinio, el trabajo se prolongó durante más de seis meses, tiempo en el que se emplearon cientos de horas de trabajo a la postre inútiles, pues el proyecto fue finalmente...
Dentro de la Ingeniería de Software, hay una disciplina que se denomina Ingeniería de Requisitos. Está orientado a desarrollar requisitos a través de un proceso cooperativo e interactivo de analizar el problema, documentar las observaciones resultantes y checar lo obtenido.
Tradicionalmente se distinguen 3 actividades principales de la Ingeniería deRequisitos: captura o elicitación, modelado y validación de requisitos.
Los requisitos de un sistema de software se suelen clasificar en funcionales y no funcionales. Los funcionales son descripciones de lo que el sistema hace o debe hacer. Los no funcionales son restricciones globales sobre como debe construirse y funcionar el sistema.
A menudo, también se mencionan otros requisitos.Denominados Organizacionales, que engloban las razones de la creación del sistema, las restricciones del ambiente en el que el sistema funciona y el significado de los requisitos del sistema.
UML presta ayuda en la modelación de los requisitos funcionales, no así con los no funcionales. Respecto al organizacional, se puede hacer un modelo de negocios usando un diagrama de UML fuera de su uso habitual.1En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversionistas, que pueden entrar en conflicto entre ellos.
El propósitode la Ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
La Ingeniería de requisitos implica todas las actividades del ciclo de vida dedicadas a:
La educción (llamada también elicitación, por una mala traducción deelicitation) de los requisitos del usuario.
El análisis y negociación de requisitos para derivar requisitos adicionales.
La documentación de los requisitos como especificación.
La validación de los requisitos documentados contra las necesidades de usuario.
Así como los procesos que apoyan estas actividades.2
2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS
En un importante hospital español ocurrióhace unos años un sucedo del que puede extraerse no solo sarcásticos comentarios sobre la capacidad de determinadas compañías para llevar a cabo un desarrollo de software a nivel profesional, sino también interesantes lecciones sobre la dificultad de las actividades de obtención de requisitos.
Todo comenzó cuando un consultor recién titulado fue enviado por su empresa, una compañía de desarrollode software a medida, a la unidad de cuidados intensivos del hospital en cuestión. Su encargo era estudiar la forma de trabajo del personal, como paso previo al desarrollo de un sistema informático integral que mejoraría la eficacia en la gestión dela unidad. Es posible que otros consultores (o él mismo) fueran enviados a otras unidades simultáneamente, pero los autores solo cuentan coninformación de lo que ocurrió en la unidad de cuidados intensivos.
Tras un primer contacto optimista, donde la mayor parte del personal se ofreció colaborar, el consultor (que acudía puntualmente a tomar notas y preguntar a los médicos y enfermeras sobre como desarrollaban su trabajo) expresó públicamente su certeza en que el trabajo concluiría “como mucho, en un par de meses”. Algo sorprendente, puescualquier persona medianamente familiarizada con la obtención de los requisitos de un sistema de software de tal complejidad es consciente de que esto no suele ser tarea de “un par de meses”. Así, y contrariamente a su vaticinio, el trabajo se prolongó durante más de seis meses, tiempo en el que se emplearon cientos de horas de trabajo a la postre inútiles, pues el proyecto fue finalmente...
Leer documento completo
Regístrate para leer el documento completo.