preg. del trabajo de ing del sotfwareee

DESARROLLO
1) ACTIVIDADES DEL CICLO DE VIDA DEL DESARROLLO DEL
SOFTWARE

Identificación del sistema. Puede parecer una tontería, pero es más importante
de lo que parece. Hay que saber qué es lo que se quiere hacer y qué es lo que no
se quiere hacer. A la hora de desarrollar un producto de software siempre hay
algo más que se puede hacer. En la realidad unas cosas están enlazadas con
otras, y si se quiere contemplar todo en el software se puede convertir en una
bestia difícil de manejar e inútil. Es necesario establecer LÍMITES. Fijar lo que
debe hacer el software y lo que no. Qué datos debe manejar y cuáles no. Con
quién o qué se debe comunicar y con quién o qué no. Esta es una tarea de
análisis.

Toma de requisitos. Tradicionalmente se ha llamado así a la actividad de
plasmar por escrito o gráficamente, pero de manera lo más formal posible todas
aquellas cosas que el software debe poder hacer. Entendemos por "formal" una
forma de expresarse lo más completa posible y sin ambigüedades, es decir, con
poco o ningún margen a la interpretación. Esta también es una tarea de análisis,
que suele dar como resultado uno o más documentos conocidos como
Especificación de Requisitos del Software (SRS). Existe un intento de
estandarización del SRS por parte del IEEE, el conocido como IEEE-STD-8301998, aunque sus recomendaciones son útiles como punto de partida, su
aplicación total es bastante discutible.

Estudio de procesos. Todas las organizaciones basan su trabajo en procesos.
Digamos que son rutinas más o menos establecidas para tratar un determinado
asunto. Por ejemplo, una zapatería, cuando vende un par de zapatos a un cliente
lo hace siguiendo un proceso... que si cobro los zapatos, doy una factura de tal
manera, lo anoto en el total de caja, lo descuento del almancen... El estudio de
procesos se basa en identificar cuáles son esos procesos, para qué sirven, quién
los realiza. Es una actividad de análisis. Suelen utilizarse diagramas gráficos
para esta labor, como por ejemplo, los antiguos DFD, o los actuales diagramas
de UML.

Reingeniería de procesos. La gran olvidada en la producción del software. A
menudo, los procesos empresariales están viciados por la tradición, la costumbre
y la burocracia. Es bueno pararse a pensar si un proceso puede reorganizarse e
incluso obtener otro equivalente de tal manera que el resultado siga siendo el
mismo pero de manera más eficiente e incluso más eficaz. En muchos casos
puede hacerse. Eso es la reingeniería. Si un proceso es ineficiente o ineficaz y se
automatiza directamente, lo único que conseguiremos es que se muestre más
rápidamente su ineficiencia o ineficacia.

Diseño: Las actividades de diseño cubren todo tipo de decisiones, pero
especialmente las relacionadas con "cómo va a ser el software"... de qué grandes
partes constará, qué tecnología utilizará, cómo se interrelacionan los datos que
va a utilizar. Por hacer un símil con la arquitectura, el diseño es al proyecto de
software como los planos son a un edificio. También forma parte del diseño el
decidir qué pequeñas piezas forman el todo: cuál es la función de cada una de
ellas y cómo se comunica con las demás. El punto de partida para el diseño es la
especificación de requisitos (SRS).

Planificación: Cuando se conoce el diseño, es necesario decidir cómo se
organizará el trabajo hasta la conclusión del proyecto, desde el punto de vista de
la administración de recursos, tanto humanos como materiales, y del tiempo, el
espacio y el dinero. Es una tarea de diseño.

Codificación/Implementación/Programación. Tres nombres para la misma
cosa. Nos referimos a la programación propiamente dicha de cada uno de los
pequeños componentes que formarán el software, siguiendo el diseño. Cada
componente debe realizar la función que se le exige, y debe comunicarse con
otros componentes de la manera que haya sido fijada en el diseño. Es una tarea
de producción.

Integración. Integrar es unir dos o más componentes del proyecto de software y
verificar que todo funciona según lo diseñado, prestando especial atención al
funcionamiento conjunto de los componentes. Integrando, integrando... se
obtiene el proyecto entero. Es una tarea de producción.

Pruebas: Las pruebas son muy importantes en el desarrollo del software.
Consisten en verificar que lo que se está haciendo va bien. Aunque puede haber
muchos tipos de pruebas, se suele hablar al menos de estos grandes tipos
importantes:
o
Las pruebas unitarias, en las que un componente del software se prueba
de manera individual. Es una tarea de producción.
o
Las pruebas de integración, en las que se prueba el funcionamiento
conjunto de dos o más componentes del software. Es una tarea de
producción.
o
Las pruebas de aceptación, en las que se verifica que el software está
cumpliendo los requisitos iniciales. Es una tarea de análisis (o diseño,
según se mire)
o
Las pruebas de carga, en las que se verifica que el sistema será capaz de
soportar ampliamente la carga de trabajo que se exigirá. Es una tarea de
producción (o diseño, según se mire).
o
Y, en mi humilde opinión, y aunque no se mencionan a menudo, las
pruebas de robustez del diseño, en las que se verifica que el diseño es
eficaz, eficiente, hace lo que se le pide y permite responder con solidez a
situaciones imprevistas. Es una tarea de diseño.

Implantación. Implantar un software es ponerlo en marcha en su ubicación
definitiva. Es una tarea de producción.

Explotación. No es una actividad o tarea en sí. Se denomina así al hecho de
utilizar el sistema y sacarle partido.

Mejora. Cuando el sistema está en explotación, es decir, en marcha, a veces es
necesario introducir mejoras. Es una tarea de mantenimiento.

Ampliación. Al igual que con las mejoras, a veces es necesario introducir
nuevas funcionalidades (requisitos) en el producto de software cuando ya está en
marcha. Es una tarea de mantenimiento.

Corrección de errores. Los errores suelen aparecer con frecuencia en el
software cuando está ya en marcha, aun cuando se dedique gran cantidad de
esfuerzo a las pruebas. Es una tarea de mantenimiento. Aunque en general, la
palabra "error" cubre cualquier mal funcionamiento del software, se puede afinar
un poco más, y localizar al menos tres orígenes de mal funcionamiento, y así
hablar de:
o
Defecto: cuando alguna parte del producto del software no se ajusta a su
diseño. En ese caso es apropiada la palabra "defecto", porque el software
fué bien diseñado, pero al codificarlo, algo no se programó tal como fue
diseñado. Por ejemplo, si compro una cafetera eléctrica y mi unidad falla
porque una soldadura está incorrecta, digo que mi unidad está
"defectuosa", aunque probablemente la cafetera fue bien diseñada.
o
Fallo: cuando alguna parte del producto de software no funciona
convenientemente, debido a alguna circunstancia no prevista en el
diseño. Por ejemplo, si en mi oficina en verano hay 50ºC y eso hace que
el disco duro no funcione bien digo "el disco duro está fallando".
Probablemente, el disco duro funcione bien en gran cantidad de
ocasiones, pero el diseñador no previó que tuviera que funcionar a altas
temperaturas.
o
Error: propiamente dicho, lo podemos dejar para aquellos malos
funcionamientos de origen, en principio desconocido.
http://latecladeescape.com/w0/ingenieria-del-software/las-actividades-del-ciclo-de-vidadel-software.html
2) EXPLICAR LOS MODELOS EXISTENTES PARA EL DESARROLLO
DEL SOFTWARE
La ingeniería de software tiene varios modelos, paradigmas o filosofías de
desarrollo en los cuales se puede apoyar para la realización de software, de los cuales
podemos destacar a éstos por ser los más utilizados y los más completos:

Modelo en cascada o Clásico (modelo tradicional)

Modelo en espiral (modelo evolutivo)

Modelo de ponchito

Desarrollo por etapas

Desarrollo iterativo y creciente o Iterativo e Incremental

RAD (Rapid Application Development)

Desarrollo concurrente

RUP (Modelo Racional)

Proceso Unificado
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software#Modelos_de_desarrollo_
de_software
El modelo de desarrollo de software se compone de una mezcla de varios
elementos, entre los que se encuentran la filosofía, el modelo de negocio, y el
licenciamiento. Ni la calidad ni el desempeño dependen del modelo.
- La filosofía detrás del desarrollo de software tiene amplia influencia en los
otros dos elementos. Las razones para el desarrollo pueden incluir la generación de
bienestar, desarrollo de una comunidad, desarrollo intelectual de sus creadores, o la
generación de mejoramiento en el uso de las herramientas, entre otros. La comprobación
de un error en el software, o simplemente la sensación de cumplir un cometido pueden
ser los motores que lleven a un hacker o un creador de un virus a desarrollar programas
de este estilo.
- El modelo de negocio es otro de los elementos que se deben considerar.
Cuando se habla de modelo de negocio, básicamente se debe determinar de donde
proveerán los ingresos. En el desarrollo de software gratuito y/o software libre, se
cuenta en buena parte con recursos de donaciones, y es palpable el desarrollo de estas
aplicaciones por fundaciones que pueden recibir estas donaciones y evitar tributos que
disminuirían el dinero para el desarrollo. En el ámbito comercial, es factible vender el
software en sí, como licenciamiento de uso, comercializar los servicios de implantación
o
de
integración,
o
una
combinación
de
estos
dos
modelos.
Por lo general, tanto alrededor del software comercial como del software libre se
estructuran modelos de negocios que generen ingresos para garantizar la sostenibilidad
de las empresas. No en vano, "quienes producen el software también necesitan comer".
Los productores de software comercial manejan diferentes esquemas en su red de
distribución: algunos lo hacen de forma exclusiva y directa; otros lo hacen a través de
socios de negocios, quienes a su vez agregan valor a través de servicios de implantación
y consultoría, y otros productores prefieren una mezcla de los dos tipos, a selección del
cliente.
- El licenciamiento completa los tres elementos del modelo de desarrollo de
software. De cualquier filosofía o modelo de negocio que se desprenda una aplicación,
siempre hay una licencia de uso. No mas en el mundo de "código abierto" hay casi 50
tipos de licenciamiento, que consigna diferentes derechos y obligaciones. Básicamente
estas licencias, en su esencia, permiten que se cambie el código, pero también exigen
que las modificaciones al código sean compartidas con la comunidad, de tal manera que
todos se puedan beneficiar de los cambios. Es claro entonces, que si partimos de una
aplicación de licencia que permita cambios, para generar aplicaciones de uso estratégico
en la compañía, donde la estrategia y reglas del negocio queden embebidas en la
aplicación, al entregar el código estaríamos también entregando nuestra estrategia, y
para no entregar el código, estaríamos infringiendo la licencia.
http://www.gestiopolis.com/delta/prof/PRO350.html
3) EXPLIQUE CUALES MODELOS ESTUDIADOS EN LA PREGUNTA
ANTERIOR SE ADAPTAN AL DESARROLLO DE NUESTRO PROYECTO.
La filosofía detrás de desarrollo de software porque tiende a incluir la
generación de bienestar, desarrollo de una comunidad, desarrollo intelectual de sus
creadores, o la generación de mejoramiento en el uso de las herramientas, entre otros.
El licenciamiento pues básicamente estas licencias, en su esencia, permiten que
se cambie el código, pero también exigen que las modificaciones al código sean
compartidas con la comunidad, de tal manera que todos se puedan beneficiar de los
cambios.
4) MENCIONE LA IMPORTANCIA QUE TIENE EL USO DE LOS MODELOS
PARA EL DESARROLLO DEL SOFTWARE.
BIBLIOGRAFIA
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software#Modelos_de_desarrollo_
de_software
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software#Modelos_de_desarrollo_
de_software
http://www.gestiopolis.com/delta/prof/PRO350.html
Republica Bolivariana De Venezuela
Ministerio Del Poder Popular Para La Educación Superior
Universidad Bolivariana De Venezuela
Maturín, Edo – Monagas