sábado, 26 de marzo de 2011
domingo, 20 de marzo de 2011
Matriz Requerimientos Creando Sistemas
Matriz de requerimientos Creando Sistemas (Mario Abraham, Saul, Ricardo Vasquez) >>> Ver Matriz
sábado, 19 de marzo de 2011
viernes, 18 de marzo de 2011
Utilidad de la medida del software y normativa ISO 9126
Utilidad de la medida del softwareConsecuencia de su proceso interno de asegurar la calidad, cuantificar los atributos que constituyen la calidad para el usuario final, ahí tenemos los resultados cuantitativos. Saber que aquello que al usuario final le interesa lo tenga o no un producto y permita cuantificar almacenar otros productos.
Normativa ISO 9126, medida de la calidad de software descomponiendo atributos, para no tener márgenes de error e interpretación.
Atributo de funcionalidad.
Atributo de capacidad de respuesta frente a errores externos.
Atributo de nivel de seguridad. La calidad no puede existir sin seguridad, un producto sin seguridad seria un producto sin calidad. El observador o usuario final indica que atributos más o menos importantes de seguridad
Normativa ISO 9126, medida de la calidad de software descomponiendo atributos, para no tener márgenes de error e interpretación.
Atributo de funcionalidad.
Atributo de capacidad de respuesta frente a errores externos.
Atributo de nivel de seguridad. La calidad no puede existir sin seguridad, un producto sin seguridad seria un producto sin calidad. El observador o usuario final indica que atributos más o menos importantes de seguridad
CALIDAD, NORMATIVAS, FUNCIONALIDAD, CONFIABILIDAD, CERTIFICACION, MEDICON DE S
Calidad: Es la aptitud de un producto o servicio para satisfacer las necesidades del usuario.
Es la cualidad de todos los productos, no solamente de equipos sino también de programas.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
Adicionalmente se puede seguir los siguientes aspectos para evaluar la calidad del software:
Funcionalidad Confiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Escalabilidad(actualizacion)
Calidad de softwareCaracterísticas propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra a la par con la calidad tradicional, pero un paso atrás, debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene 50 a 30años.
Certificación del software Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI,...)
Normativa ISO 9000Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar; La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.
Medición del softwareEn el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal ya que la descomposición del atributo genérico de calidad en otros sub-atributos se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta.
El concepto de medida va de más a menos, va de lo general a lo concreto y lo concreto es asociado a la métrica, cuya combinación te daría el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemática.
Tipos de medidas Número de errores durante un periodo determinado.
Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
Tamaño de un producto informático (líneas de código)
Métrica de punto función (IBM): relaciona funcionalidades que ofrecía.
Estimación de costes y esfuerzos.
COCOMO
Es la cualidad de todos los productos, no solamente de equipos sino también de programas.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
Adicionalmente se puede seguir los siguientes aspectos para evaluar la calidad del software:
Funcionalidad Confiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Escalabilidad(actualizacion)
Calidad de softwareCaracterísticas propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra a la par con la calidad tradicional, pero un paso atrás, debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene 50 a 30años.
Certificación del software Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI,...)
Normativa ISO 9000Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar; La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.
Medición del softwareEn el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal ya que la descomposición del atributo genérico de calidad en otros sub-atributos se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta.
El concepto de medida va de más a menos, va de lo general a lo concreto y lo concreto es asociado a la métrica, cuya combinación te daría el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemática.
Tipos de medidas Número de errores durante un periodo determinado.
Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
Tamaño de un producto informático (líneas de código)
Métrica de punto función (IBM): relaciona funcionalidades que ofrecía.
Estimación de costes y esfuerzos.
COCOMO
Control y administración de la configuración
Cuando piensa en ingeniería de software, también puede pensar de administración de configuración de software que es el proceso de control de cambios y seguimiento de los nuevos cambios. Dos importantes tareas de administración de configuración de software incluyen el establecimiento de líneas de base y de control de revisiones. La principal preocupación de las empresas practicar este tipo de administración de la configuración es averiguar si puede reproducir las acciones de otra persona (en cuanto a software), tal vez no perfectamente, pero cierra con cambios controlados. Este proceso de reproducción y la comparación de las diferencias son muy importantes para la administración de la configuración de software.
Generalmente normal configurar gestión técnicas se centrarán en la creación de productos simples en un entorno controlado, sin embargo con el software de administración de la configuración aborda los sistemas complejos y cambiante cómo se desarrollan los pequeños incrementos en el entorno controlado.
Configuración de software es la práctica de cómo utilizar los objetos de diferentes variedades y cómo pueden ser gestionados y convertidos en versiones diferentes. Este proceso incluye la creación de códigos de software, el diseño de modelos y documentos y incluso puede incluirse en la realización de la estructura del directorio.
Los propósitos de administración de configuración de software son diferentes y diversas que abarca muchos aspectos diferentes de la creación de software. El primero fue la identificación de la configuración que señala qué códigos, vamos a trabajar con. El siguiente es el control de esa configuración; Esto se utiliza en el lanzamiento de su nuevo producto con sus cambios. A continuación será la contabilidad de la situación del nuevo producto, mediante la grabación de la información relativa a sus componentes. Después de que se hayan completado estos procesos se mueve en la etapa de revisión que garanticen que todos los componentes están completas y sean compatibles con todos los otros componentes.
Otros usos de configuración de software incluyen la gestión de versiones y las herramientas que se va a utilizar para crear las versiones. También garantiza que los usuarios sigan los procesos de desarrollo normal de las organizaciones. Administra el hardware y el software del host para el sistema de la empresa. Equipos de personas permite trabajar juntos para crear y completar un proceso específico. Además de todas estas cosas, el proceso de administración de configuración de software registrará cada único defecto todos el camino de vuelta a su código fuente para que puede solucionarlo antes de que sea un producto terminado.
Generalmente normal configurar gestión técnicas se centrarán en la creación de productos simples en un entorno controlado, sin embargo con el software de administración de la configuración aborda los sistemas complejos y cambiante cómo se desarrollan los pequeños incrementos en el entorno controlado.
Configuración de software es la práctica de cómo utilizar los objetos de diferentes variedades y cómo pueden ser gestionados y convertidos en versiones diferentes. Este proceso incluye la creación de códigos de software, el diseño de modelos y documentos y incluso puede incluirse en la realización de la estructura del directorio.
Los propósitos de administración de configuración de software son diferentes y diversas que abarca muchos aspectos diferentes de la creación de software. El primero fue la identificación de la configuración que señala qué códigos, vamos a trabajar con. El siguiente es el control de esa configuración; Esto se utiliza en el lanzamiento de su nuevo producto con sus cambios. A continuación será la contabilidad de la situación del nuevo producto, mediante la grabación de la información relativa a sus componentes. Después de que se hayan completado estos procesos se mueve en la etapa de revisión que garanticen que todos los componentes están completas y sean compatibles con todos los otros componentes.
Otros usos de configuración de software incluyen la gestión de versiones y las herramientas que se va a utilizar para crear las versiones. También garantiza que los usuarios sigan los procesos de desarrollo normal de las organizaciones. Administra el hardware y el software del host para el sistema de la empresa. Equipos de personas permite trabajar juntos para crear y completar un proceso específico. Además de todas estas cosas, el proceso de administración de configuración de software registrará cada único defecto todos el camino de vuelta a su código fuente para que puede solucionarlo antes de que sea un producto terminado.
OBJETIVO DE DISEÑO DE SOFTWARE
Los 5 objetivos del diseño
Partiendo del diseño de sitios o sistemas como Diseño de la Interacción podemos determinar al menos 5 objetivos para el diseño:
Definir el producto final
Acotar y minimizar los costos
Poner foco en el usuario
Sacar la presión que el diseño implica para el equipo de programación
Hacer creíbles y "cumplibles" los cronogramas
El conocimiento a priori de objetivos genéricos para el diseño de sitios y aplicaciones, más allá del objetivo específico de diseñar dicha
aplicación o sitio, nos permite saber si vamos o no por buen camino. Preguntando por cada objetivo en concreto podemos determinar fácilmente
si estamos o no diseñando en forma acertada.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora. Confundir
decoración con diseño es un error común y que se paga caro. Los objetivos aquí planteados tienen que conseguirse por tanto antes de que se
escriba la primera linea de programación.
Definir el producto final
Definir el producto final antes de empezar a programar es algo tan obvio en la teoría como difícil de encontrar en la práctica.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora.
Otras ciencias más maduras que la informática, como por ejemplo la arquitectura y la ingeniería civil, trabajan el tiempo necesario
para cumplir con este objetivo antes de comenzar con las tareas de campo. Todas las herramientas son válidas: maquetas, planos, memorias
descriptivas, animaciones y un bagaje enorme de técnicas permiten dar visiones completas del producto terminado a los clientes, a los
inversores, a los constructores, a los albañiles, subcontratistas y todos los participantes de la obra sin necesidad de poner el primer
ladrillo. El ejemplo es válido para trasladarlo a la industria informática. En ésta, apenas se conocen los primeros esbozos del sistema,
se comienza a programar, con la ilusión de que programar y diseñar en paralelo ahorra tiempo y dinero. Lamentablemente muchas veces es
considerado entre los programadores una viveza, un rasgo de picardía, obviar el trabajo previo de diseño y documentación.
Partiendo del diseño de sitios o sistemas como Diseño de la Interacción podemos determinar al menos 5 objetivos para el diseño:
Definir el producto final
Acotar y minimizar los costos
Poner foco en el usuario
Sacar la presión que el diseño implica para el equipo de programación
Hacer creíbles y "cumplibles" los cronogramas
El conocimiento a priori de objetivos genéricos para el diseño de sitios y aplicaciones, más allá del objetivo específico de diseñar dicha
aplicación o sitio, nos permite saber si vamos o no por buen camino. Preguntando por cada objetivo en concreto podemos determinar fácilmente
si estamos o no diseñando en forma acertada.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora. Confundir
decoración con diseño es un error común y que se paga caro. Los objetivos aquí planteados tienen que conseguirse por tanto antes de que se
escriba la primera linea de programación.
Definir el producto final
Definir el producto final antes de empezar a programar es algo tan obvio en la teoría como difícil de encontrar en la práctica.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora.
Otras ciencias más maduras que la informática, como por ejemplo la arquitectura y la ingeniería civil, trabajan el tiempo necesario
para cumplir con este objetivo antes de comenzar con las tareas de campo. Todas las herramientas son válidas: maquetas, planos, memorias
descriptivas, animaciones y un bagaje enorme de técnicas permiten dar visiones completas del producto terminado a los clientes, a los
inversores, a los constructores, a los albañiles, subcontratistas y todos los participantes de la obra sin necesidad de poner el primer
ladrillo. El ejemplo es válido para trasladarlo a la industria informática. En ésta, apenas se conocen los primeros esbozos del sistema,
se comienza a programar, con la ilusión de que programar y diseñar en paralelo ahorra tiempo y dinero. Lamentablemente muchas veces es
considerado entre los programadores una viveza, un rasgo de picardía, obviar el trabajo previo de diseño y documentación.
EQUIPO : CARLOS JACOME, FLORENTINO MORENO Y RICHARD CASTELLANOS
Historia
La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por
el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse según Alan Davis como “la aplicación inteligente
de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga
las necesidades de los usuarios.
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba
desarrollando en torno a las problemáticas que ofrecía el software en ese momento.
En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del
propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software
(en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos
(sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que
causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de
veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva
al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la
programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación,
los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la
ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que
si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas
de la ingeniería.
La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por
el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse según Alan Davis como “la aplicación inteligente
de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga
las necesidades de los usuarios.
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba
desarrollando en torno a las problemáticas que ofrecía el software en ese momento.
En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del
propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software
(en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos
(sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que
causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de
veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva
al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la
programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación,
los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la
ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que
si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas
de la ingeniería.
lunes, 14 de marzo de 2011
Y los trabajos???
Al día de hoy no he recibido ninguna tarea de su actividad que tenían que realizar durante la semana pasada y la del sábado. Les recuerdo que para el próximo sábado su proyecto final deberán cubrir:
- Especificación de Requerimientos
- Propuesta de Solución
- Administración de la Configuración
- Plan de Desarrollo del proyecto.
Si tienen dudas me pueden mandar correo, pero es necesario que realicen sus actividades ya que el próximo sábado habrá examen de todos los temas que hemos visto incluyendo los que tenían que investigar para este sábado que paso.
Saludos
sábado, 5 de marzo de 2011
Tareas a realizar la proxima semana
Temas Actividades
| HERRAMIENTAS Y AMBIENTES PARA LA INGENIERÍA DE SOFTWARE 7.1 Desarrollo histórico de herramientas y ambientes. 7.2 Clasificación de herramientas y ambientes de software. 7.3 Herramientas más representativas 7.4 El papel del lenguaje de programación en el ambiente. 7.5 Algunos ejemplos de herramientas. 7.6 Perspectivas de evolución de la Ingeniería de Software | Crear mapa mental de clasificaciones de herramientas y ambientes de software, herramientas representativas. Investigar la historia de las herramientas y ambientes de software Investigación de las perspectivas de evolución de la Ing. Realizar un mismo diagrama (el diagrama de casos de uso que realizaron previamente) en distintas herramientas, identificar la que le resulte más conveniente y escribir el porque en el blog, junto con los diagramas realizados. Buscar 1 programa similar (cada alumno uno distinto) a Balsamiq Mookups y realizar el mookup de una interfaz del sistema relacionada con el caso de uso que han venido trabajando. Avanzar con el proyecto final. |
libro de ingenieria de software de ian summerville
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978NTE2OGFiMDMtNTQ3OC00NTBiLTk0MWItYzcwZjExZTJmYzhh&hl=es&authkey=COLM-YoN
viernes, 4 de marzo de 2011
Mapa mental de lo visto en la materia
Realizado en Mind42.com
http://mind42.com/pub/mindmap?mid=d78c145f-0604-4326-afda-ff11af3bf1c7
http://mind42.com/pub/mindmap?mid=d78c145f-0604-4326-afda-ff11af3bf1c7
Lenguaje Unificado de Modelado - Wikipedia, la enciclopedia libre
Lenguaje Unificado de Modelado - Wikipedia, la enciclopedia libre: "En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados"
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados"
miércoles, 2 de marzo de 2011
sábado, 26 de febrero de 2011
Tareas pendientes:
1.- Seleccionar una herramienta de toma de requerimientos y justificar el porque de dicha elección (se debe buscar que sea la mejor).
2.- Utilizarla para el proyecto final.
Algunas herramientas son:
2.- Utilizarla para el proyecto final.
Algunas herramientas son:
- Active!Focus Analyst Pro
- CARE SteelTrace
- XTie-RT Prosareq
- Focal Point Easy-RM
- RDT PROJECTRICITY
- Reconcile PACE
- SoftREQ Qualica
- REM
3.- Realizar un mapa mental de los temas teóricos vistos en clase.
4.- Investigar sobre metodologías de desarrollo como RUp, XP, etc. e identificar sus principales características:
- 7 mitos de los métodos formales.
- RUP
- Agiles
- http://www.agilemanifesto.org/iso/es/manifesto.html
- Scrum
- XP
- Lean Software Development
Requerimientos
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978NGVmM2RhMGYtNDcyZS00ZTQxLWEwNDMtOTZjM2Y4YWFmZTUy&hl=es&authkey=COnQu7sK
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978MWU5MzU0ZmYtYzFhMS00ZDM4LWJhNDEtYjRmMWYwNDNmNTll&hl=es
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978MWU5MzU0ZmYtYzFhMS00ZDM4LWJhNDEtYjRmMWYwNDNmNTll&hl=es&authkey=CPLui8kL
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978MWU5MzU0ZmYtYzFhMS00ZDM4LWJhNDEtYjRmMWYwNDNmNTll&hl=es
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978MWU5MzU0ZmYtYzFhMS00ZDM4LWJhNDEtYjRmMWYwNDNmNTll&hl=es&authkey=CPLui8kL
Clase 2 Cualidades del software
https://docs.google.com/present/edit?id=0AbJ9SPOPl978ZHJ2YmZtNl83NWM0Nm56a2cy&hl=es
Ciclo de vida y cualidades
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBUQFjAA&url=http://www.fceia.unr.edu.ar/asist/intro-cuali-t.pdf&rct=j&q=Clasificaci%C3%B3n%20de%20las%20cualidades%20del%20software.&ei=fw9fTeu5H432tgO167jFCA&usg=AFQjCNH6nrfGCZk5gAIvbrJed3YVopfg9g&sig2=VUcESgGjbpsmPuwUWbdyNA&cad=rja
Cualidades
https://docs.google.com/present/edit?id=0AbJ9SPOPl978ZHJ2YmZtNl85N3Jmcm5qdGtm&hl=es
Ciclo de vida y cualidades
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBUQFjAA&url=http://www.fceia.unr.edu.ar/asist/intro-cuali-t.pdf&rct=j&q=Clasificaci%C3%B3n%20de%20las%20cualidades%20del%20software.&ei=fw9fTeu5H432tgO167jFCA&usg=AFQjCNH6nrfGCZk5gAIvbrJed3YVopfg9g&sig2=VUcESgGjbpsmPuwUWbdyNA&cad=rja
Cualidades
https://docs.google.com/present/edit?id=0AbJ9SPOPl978ZHJ2YmZtNl85N3Jmcm5qdGtm&hl=es
viernes, 25 de febrero de 2011
confiabilidad de software y tesis
En este trabajo de tesis queremos llegar a aquellos lineamientos que utilizaremos
para implementar Seguridad en Aplicaciones basadas en servicios digitales
en internet para que sean mas confiables y proporcionen Seguridad un servicio de calidad.
Aunque sabemos que actualmente no hay ninguna metodologia que asegure totalmente la Seguridad Y C onfiabilidad en los sistemas de software, en nuestra meta que los servicios digitales en Internet sean toda su plenitud seguros y confiables para que los investigadores que trabajen en desarrolos tecnologicos que sean su minima constante preocupacion referente a la seguridad y confiabilidad.
El exito de esta tesis depende de algunos puntos importantes. Uno de ellos es
que necesitamos saber cuales son las necesidades de los investigadores del CENTIA
que trabajen en desarrollos tecnologicos, ya que sin esta informacion no podremos implementar todos los lineamientos sa seguir para lograr la Seguridad y Confiabilidad en los servicios digitales
en Internet.
Otro punto importante es que si no se ha hecho una adecuada investigacion sobre los temas mas imprtantes a trabajar en esta tesis, tendremos serios problemas a la hora de eswtablecer la Tecnologia y Seguridad.
TESIS
para implementar Seguridad en Aplicaciones basadas en servicios digitales
en internet para que sean mas confiables y proporcionen Seguridad un servicio de calidad.
Aunque sabemos que actualmente no hay ninguna metodologia que asegure totalmente la Seguridad Y C onfiabilidad en los sistemas de software, en nuestra meta que los servicios digitales en Internet sean toda su plenitud seguros y confiables para que los investigadores que trabajen en desarrolos tecnologicos que sean su minima constante preocupacion referente a la seguridad y confiabilidad.
El exito de esta tesis depende de algunos puntos importantes. Uno de ellos es
que necesitamos saber cuales son las necesidades de los investigadores del CENTIA
que trabajen en desarrollos tecnologicos, ya que sin esta informacion no podremos implementar todos los lineamientos sa seguir para lograr la Seguridad y Confiabilidad en los servicios digitales
en Internet.
Otro punto importante es que si no se ha hecho una adecuada investigacion sobre los temas mas imprtantes a trabajar en esta tesis, tendremos serios problemas a la hora de eswtablecer la Tecnologia y Seguridad.
TESIS
IBM Software - DOORS Product line
miércoles, 23 de febrero de 2011
Especificaciones De Requerimientos
Especificaciones De Requerimientos: "El IEEE sugiere la siguiente estructura para los documentos de requerimientos.
1. Introducción
• propósito del documento de requerimientos
• Alcance del producto
• Definiciones, acrónimos y abreviaturas
• Referencias • Resumen del resto del documento
2. Descripción general
• Perspectiva del producto
• Funciones del producto
• características del usuario
• Restricciones generales
• Suposiciones y dependencias"
1. Introducción
• propósito del documento de requerimientos
• Alcance del producto
• Definiciones, acrónimos y abreviaturas
• Referencias • Resumen del resto del documento
2. Descripción general
• Perspectiva del producto
• Funciones del producto
• características del usuario
• Restricciones generales
• Suposiciones y dependencias"
www.navegapolis.net - Herramientas para la gestión de requisitos
www.navegapolis.net - Herramientas para la gestión de requisitos: "Las herramientas comerciales más conocidas son: DOORS, RTM Workshop, Requisite Pro, Caliber-RM.
Carl E. Wiegers tiene un interesante artículo con tablas y recomendaciones comparativas de estas cuatro herramientas.
Otras herramientas comerciales:
Active!Focus Analyst Pro
CARE SteelTrace
XTie-RT Prosareq
Focal Point Easy-RM
RDT PROJECTRICITY
Reconcile PACE
SoftREQ Qualica
Soluciones free sólo conozco REM (Requisite Management). Herramienta gratuita de Amador Durán.
Puede ser útil también 'Especificar y gestionar los requisitos con un Wiki '. "
Carl E. Wiegers tiene un interesante artículo con tablas y recomendaciones comparativas de estas cuatro herramientas.
Otras herramientas comerciales:
Active!Focus Analyst Pro
CARE SteelTrace
XTie-RT Prosareq
Focal Point Easy-RM
RDT PROJECTRICITY
Reconcile PACE
SoftREQ Qualica
Soluciones free sólo conozco REM (Requisite Management). Herramienta gratuita de Amador Durán.
Puede ser útil también 'Especificar y gestionar los requisitos con un Wiki '. "
¿Que es confiabilidad de software?
El ojetivo de este proyecto consiste en establecer un conjunto de lineamientos necesarios para implementar Seguridad en aplicaciones basadas en servicios digitales en internet para logra su confiabilidad y calidad. Estos lineamientos estaran acompañados por las herramientas correspondientes para su implementacion . Es de suma importancia el que los investigadores del CENTIA cuenten con lo lineamientos y herramientas de apoyo a la seguridad de los desarrolos tecnologicos resultados de sus proyectos de investigacion para lograr un trabajo confiabley de calidad.
confiabilidad de software
confiabilidad de software
FreedomBox Foundation (No tiene nada que ver con la clase, es cultura geek)
FreedomBox Foundation: "The FreedomBox Foundation
We are a newly formed Delaware non-profit corporation built to help organize and coordinate the many current freedom box development efforts. Check out our Contact page for ways to reach the foundation.
Check us out on Kickstarter
The process of getting from idea to an organization and from organization to living, breathing, functioning reality can be long and difficult. It has taken the foundation almost a full year to move from idea to organization and events around the world are making it clear we can't wait another year before getting freedom boxes off of the technical design board and into people's lives.
So we're making a break for it and trying to get off the ground in one big push via our Kickstarter push 'Push the FreedomBox Foundation from 0 to 60 in 30 days'. Please take a moment and check it out!"
We are a newly formed Delaware non-profit corporation built to help organize and coordinate the many current freedom box development efforts. Check out our Contact page for ways to reach the foundation.
Check us out on Kickstarter
The process of getting from idea to an organization and from organization to living, breathing, functioning reality can be long and difficult. It has taken the foundation almost a full year to move from idea to organization and events around the world are making it clear we can't wait another year before getting freedom boxes off of the technical design board and into people's lives.
So we're making a break for it and trying to get off the ground in one big push via our Kickstarter push 'Push the FreedomBox Foundation from 0 to 60 in 30 days'. Please take a moment and check it out!"
sábado, 19 de febrero de 2011
viernes, 18 de febrero de 2011
Ingeniería de requisitos - Wikipedia, la enciclopedia libre
Ingeniería de requisitos - Wikipedia, la enciclopedia libre: "Fases de implementación
Desde un punto de vista conceptual, las actividades son de cinco clases.
Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.
Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación.
Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía."
Desde un punto de vista conceptual, las actividades son de cinco clases.
Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.
Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación.
Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía."
Pruebas de software - Wikipedia, la enciclopedia libre
Pruebas de software - Wikipedia, la enciclopedia libre: "Tipos de pruebas
Pruebas unitarias
Pruebas funcionales
Pruebas de Integración
Pruebas de validación
Pruebas de sistema
Caja blanca (sistemas)
Caja negra (sistemas)
Pruebas de aceptación
Pruebas de regresión
Pruebas de carga
Pruebas de prestaciones
Pruebas de recorrido
Pruebas de mutación
Pruebas concurrentes"
Pruebas unitarias
Pruebas funcionales
Pruebas de Integración
Pruebas de validación
Pruebas de sistema
Caja blanca (sistemas)
Caja negra (sistemas)
Pruebas de aceptación
Pruebas de regresión
Pruebas de carga
Pruebas de prestaciones
Pruebas de recorrido
Pruebas de mutación
Pruebas concurrentes"
Desarrollo ágil de software - Wikipedia, la enciclopedia libre
Desarrollo ágil de software - Wikipedia, la enciclopedia libre: "Metodologías ágiles
Algunas metodologías ágiles de desarrollo de software:
Adaptive Software Development (ASD).
Agile Unified Process (AUP).
Crystal Clear.
Essential Unified Process (EssUP).
Feature Driven Development (FDD).
Lean Software Development (LSD).
Kanban.
Open Unified Process (OpenUP).
Programación Extrema (XP).
Scrum."
Algunas metodologías ágiles de desarrollo de software:
Adaptive Software Development (ASD).
Agile Unified Process (AUP).
Crystal Clear.
Essential Unified Process (EssUP).
Feature Driven Development (FDD).
Lean Software Development (LSD).
Kanban.
Open Unified Process (OpenUP).
Programación Extrema (XP).
Scrum."
Fases de RUP
La Bitacora de AudieMan: Metodologia Agil Proceso Unificado de Rational RUP: "RUP ES APROPIADO PARA PROYECTOS GRANDES, REQUIERE EQUIPO CAPAZ DE ADMINISTRAR PROCESOS COMPLEJOS EN VARIAS ETAPAS. RUP ESTA DIRIGIDO POR CASOS DE USO, CENTRADO EN LA ARQUITECTURA Y ES UN PROCESO ITERATIVO INCREMENTAL.
"
"
Download Free UML Tool to draw UML diagrams
Download Free UML Tool to draw UML diagrams: "Download Visual Paradigm for UML 8.1 Community Edition
Get Visual Paradigm for UML Community Edition
FREE for non-commercial use only"
Get Visual Paradigm for UML Community Edition
FREE for non-commercial use only"
miércoles, 16 de febrero de 2011
Como vencer la resistencia al cambio y obtener la colaboración activa de los “stakeholders”
Como vencer la resistencia al cambio y obtener la colaboración activa de los “stakeholders”
Resumiendo, para despertar la colaboración activa de las personas es necesario responder a cuatro factores (y eso separadamente para cada grupo de “stakeholder”), en el siguiente orden:
- El factor cocodrilo: identifique y prepárese para presentar a cada “stakeholder” sus cocodrilos particulares, dejando que ellos vean cuan poderosas son aquellas mandíbulas y cuan inconsecuente y paliativo es el efecto del golpe en el hocico.
- El factor olla de oro: demuestre que en lo alto de la montaña hay oro en abundancia, del cual todos podrán disfrutar.
- El factor muleta: pruebe que los riesgos de la jornada fueron considerados y prevenidos. Si eventualmente algún “stakeholder” señala algún riesgo no previamente considerado, aprenda a oír, entienda y (juntos) traten de encontrar la mejor acción preventiva.
- El factor sirena: explique cómo serán preservados (y hasta ampliados) los beneficios ya conquistados en la realidad actual, por ejemplo construyendo un acuario para llevar a las sirenas a lo alto de la montaña.
1 38 fred brooks - the mythical man-month - cap 1 y 2 - espanol.zip | Fred Brooks - The Mythical Man...
1 38 fred brooks - the mythical man-month - cap 1 y 2 - espanol.zip | Fred Brooks - The Mythical Man...: "Documento
1 38 fred brooks - the mythical man-month - cap 1 y 2 - espanol.zip
Documento .zip de 480KB
Fred Brooks - The Mythical Man-Month - Cap 1 y 2 - En Español. Es una traducción hecha por mi así que no es perfecta.
Subido el 04/04/2008 por Diego Barberio"
1 38 fred brooks - the mythical man-month - cap 1 y 2 - espanol.zip
Documento .zip de 480KB
Fred Brooks - The Mythical Man-Month - Cap 1 y 2 - En Español. Es una traducción hecha por mi así que no es perfecta.
Subido el 04/04/2008 por Diego Barberio"
Bitácora de pacoescriba (39966)
Bitácora de pacoescriba (39966): "La esencia de una entidad software es una construcción de conceptos entrelazados: conjuntos de datos, relaciones entre los datos, algoritmos y llamadas a funciones. Esta esencia nos indica que uno de estos conceptos abstractos construidos tiene muchas representaciones. Sin embargo es muy preciso y muy detallado.
Creo que la parte más dura de construir software es la especificación, diseño y prueba de este concepto construido, no el trabajo de representarlo y comprobar la fidelidad de la representación. Todavía tendremos errores de sintaxis, evidentemente; pero eso es trivial si lo comparamos con los errores conceptuales en la mayoría de los sistemas.
Si esto es cierto, hacer software siempre será algo duro. No hay ninguna bala de plata.
Vamos a considerar las propiedades inherentes a la esencia irreductible de los modernos sistemas de software: complejidad, conformidad, variabilidad e invisibilidad."
Creo que la parte más dura de construir software es la especificación, diseño y prueba de este concepto construido, no el trabajo de representarlo y comprobar la fidelidad de la representación. Todavía tendremos errores de sintaxis, evidentemente; pero eso es trivial si lo comparamos con los errores conceptuales en la mayoría de los sistemas.
Si esto es cierto, hacer software siempre será algo duro. No hay ninguna bala de plata.
Vamos a considerar las propiedades inherentes a la esencia irreductible de los modernos sistemas de software: complejidad, conformidad, variabilidad e invisibilidad."
OTRAS-FUENTES-CURSO-PRACTICO-DE-INGENIERIA-DE-SOFTWARE
OTRAS-FUENTES-CURSO-PRACTICO-DE-INGENIERIA-DE-SOFTWARE: "Objetivo
Un sistema pobremente documentado carece de valor aunque haya funcionado bien en alguna ocasión. En el caso de programas pequeños y poco importantes que sólo se utilizan durante un corto periodo de tiempo, unos cuantos comentarios en el código podrían ser suficientes. No obstante, la mayoría de los programas cuya única documentación es el código, se quedan obsoletos rápidamente y es imposible mantenerlos. El que la dedicación de un poco de esfuerzo a la documentación sea recompensado incluso dentro de los límites de un pequeño proyecto, constituye una sorpresa para la mayoría de los novatos."
Un sistema pobremente documentado carece de valor aunque haya funcionado bien en alguna ocasión. En el caso de programas pequeños y poco importantes que sólo se utilizan durante un corto periodo de tiempo, unos cuantos comentarios en el código podrían ser suficientes. No obstante, la mayoría de los programas cuya única documentación es el código, se quedan obsoletos rápidamente y es imposible mantenerlos. El que la dedicación de un poco de esfuerzo a la documentación sea recompensado incluso dentro de los límites de un pequeño proyecto, constituye una sorpresa para la mayoría de los novatos."
objetivo del diseño
objetivo del diseño
El diseño consiste en decidir la manera en que debe construirse el sistema para satisfacer los requerimientos de los usuarios. Las buenas metodologías de diseño comparten las siguientes características:
- El buen diseño debe motivar la toma de decisiones ayudando a evaluar alternativas. Todo el diseño es acerca de compromisos. Una técnica de diseño debe permitir que el diseñador evalúe su decisión contra otras posibilidades. Por ejemplo, usando el modelo de análisis de eventos acoplado con el esquema de diseño de datos, el diseñador puede simular el volumen de lecturas y escrituras a la base de datos para cualquier evento de negocios dado. Esto permite que el equipo evalúe la factibilidad y desempeño proyectado de una disposición de tabla de base de datos dada y de un esquema de distribución de datos antes de construirlos.
- El diseño necesita ser completo, de tal forma que cubra cada uno de los aspectos principales del software que necesita construirse. Esto causara que se tengan varios tipos diferentes de modelos en la documentación del diseño. Cada modelo está especializado para mostrar un aspecto particular del sistema. Encontrará que los modeladores son particularmente adeptos de la articulación de esos aspectos para los que está orientada la técnica de modelado, pero fallan miserablemente cuando se trata de estirar el modelo más allá de su propósito original. Ningún modelo puede mostrar todas las facetas del sistema funcional completo. Ese sería el sistema mismo.
- El diseño debe ser verificable antes de su construcción. Uno de los propósitos principales del diseño es revisar y discutir la solución antes de lanzarse a la carga y codificarla. Parte del proceso de verificación es su rastreabilidad. Con una buena especificación del diseño se debe ser capaz de demostrar que se satisfarán los requerimientos del proyecto y así mismo se distinguirá entre varias versiones del diseño en cualquier momento.
- Una buena metodología de diseño crea productos diferenciados que son mensurables. Una de las tareas más difíciles de cualquier proyecto es estimar cuando se terminará. Para hacer una estimación el gerente del proyecto debe tomar medidas, la cual involucra el conteo de cosas que necesitan hacerse y la aplicación de algún tipo de medida sobre ellas para estimar que tanto tiempo se llevara el hacerlas. La medición viene, por supuesto, de haber contado estas cosas en el pasado y haber medido que tanto tardo el hacerlas anteriormente. Por lo tanto, una metodología de diseño debe producir componentes discretos lo más pronto posible.
- Por último, pero no menos importante, el diseño debe ser fácilmente aprovechado en el producto final. Debe expresar el uso y la estructura del sistema en una forma muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto proyectos que trataron de usar técnicas de diseño que fueron completamente inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no querría que su arquitecto casero le presentara un plano que fuera tan esotérico que no le diera idea de la forma que tendría la casa en su terreno. El lema de un diseñador es: hacer un mapa de la técnica hacia el destino. Si el sistema va a operar con una base datos relacional se deben escoger tecnicas que sean particularmente adecuadas para el diseño de bases de datos relacionales. Si el sistema empleara un lenguaje orientado a objetos, entonces se deberán usar técnicas de diseño orientado a objetos para las partes del sistema que requieren objetos para lograr sus tareas. Si el sistema incluirá componentes más tradicionales, tales como funciones estructuradas en las rutinas cliente o por lotes en el servidor, entonces son adecuadas técnicas de diseño estructurado más tradicionales para esas partes del sistema.
Análisis y Diseño de Sistemas - Monografias.com
Análisis y Diseño de Sistemas - Monografias.com: "Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo dividen en cinco partes:
Reconocimiento del problema.
Evaluación y Síntesis.
Modelado.
Especificación.
Revisión."
Reconocimiento del problema.
Evaluación y Síntesis.
Modelado.
Especificación.
Revisión."
Diseño de Sistemas - Monografias.com
Diseño de Sistemas - Monografias.com: "El diseñador de sistemas debe tomar las siguientes decisiones:
- Organizar el sistema en subsistemas
- Identificar la concurrencia inherente al problema
- Asignar los subsistemas a los procesadores y tareas
- Seleccionar una aproximación para la administración de almacenes de datos
- Manejar el acceso a recursos globales
- Seleccionar la implementación de control en software
- Manejar las condiciones de contorno
- Establecer la compensación de prioridades"
- Organizar el sistema en subsistemas
- Identificar la concurrencia inherente al problema
- Asignar los subsistemas a los procesadores y tareas
- Seleccionar una aproximación para la administración de almacenes de datos
- Manejar el acceso a recursos globales
- Seleccionar la implementación de control en software
- Manejar las condiciones de contorno
- Establecer la compensación de prioridades"
Objetivos del diseño
Objetivos del diseño: "Los 5 objetivos del diseño
Partiendo del diseño de sitios o sistemas como Diseño de la Interacción podemos determinar al menos 5 objetivos para el diseño:
Definir el producto final
Acotar y minimizar los costos
Poner foco en el usuario
Sacar la presión que el diseño implica para el equipo de programación
Hacer creíbles y 'cumplibles' los cronogramas"
Partiendo del diseño de sitios o sistemas como Diseño de la Interacción podemos determinar al menos 5 objetivos para el diseño:
Definir el producto final
Acotar y minimizar los costos
Poner foco en el usuario
Sacar la presión que el diseño implica para el equipo de programación
Hacer creíbles y 'cumplibles' los cronogramas"
Diseño de Software
Diseño de Software: "El objetivo más importante es :
entregar las funciones requeridas por el usuario (Satisfaga una especificación funcional dada).
Pero además para lograr esto deben considerarse los aspectos de :
Rendimiento : cuán rápido permitirá el diseño realizar el trabajo dado un recurso particular de hardware. Es decir que contemple las limitaciones del medio donde será implementado el sistema, y alcance los requerimientos de performance y uso de recursos.
Control : protección contra errores humanos, máquinas defectuosas, o daños intencionales.
Cambiabilidad : facilidad con la cual el diseño permite modificar el sistema."
entregar las funciones requeridas por el usuario (Satisfaga una especificación funcional dada).
Pero además para lograr esto deben considerarse los aspectos de :
Rendimiento : cuán rápido permitirá el diseño realizar el trabajo dado un recurso particular de hardware. Es decir que contemple las limitaciones del medio donde será implementado el sistema, y alcance los requerimientos de performance y uso de recursos.
Control : protección contra errores humanos, máquinas defectuosas, o daños intencionales.
Cambiabilidad : facilidad con la cual el diseño permite modificar el sistema."
Suscribirse a:
Entradas (Atom)