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:

• 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.
• https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978ZWUzZjgyOWEtZDQ5MS00ZjQ3LTkyODItNmQwMjEwY2NjMjYw&hl=es
• RUP
• http://audiemangt.blogspot.com/2010/05/metodologia-agil-proceso-unificado-de.html
• 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

CASO DE USO VALIDAR PEDIDO

https://spreadsheets.google.com/ccc?key=0ArJ9SPOPl978dFR3SzIxcE53UmJub0FzVE03YUxlTmc&hl=es&authkey=COLiv_cI#gid=0

https://spreadsheets0.google.com/ccc?authkey=CJe9j50B&hl=es&key=tgb30pBzI8NY_XM38BP0Q5g&hl=es&authkey=CJe9j50B#gid=0

Ejemplo Minuta

https://docs.google.com/document/d/15tUQqmtDgimTTzaIK1057YGDRORR773vO_wKoyMCZLg/edit?hl=es#

Diagrama UML de entrega de Factura al Cliente

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

Diagrama Casos de uso Embarques

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

IBM Software - DOORS Product line

IBM Software - DOORS Product line

Software para administración de requerimientos.

http://public.dhe.ibm.com/software/dw/demos/rdoors/doors_final1.html?S_CMP=rnav

Rational DOORS Requirements Professional 3.0 M7a (Beta 1) Downloads - Jazz Community Site

Rational DOORS Requirements Professional 3.0 M7a (Beta 1) Downloads - Jazz Community Site

Ingenieria requerimientos

Ingenieria requerimientos

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"

U-Cursos :: CC31B-1 Desarrollo de Software de Aplicación :: Material Docente

U-Cursos :: CC31B-1 Desarrollo de Software de Aplicación :: Material Docente

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 '. "

¿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

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!"

CASOS DE USOS

http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

Confiabilidad de software - Tesis y monografías

Confiabilidad de software

Fundamentos de Confiabilidad en el desarrollo del software

Fundamentos de Confiabilidad en el desarrollo del software

Ingeniería de la confiabilidad

Ingeniería de la confiabilidad

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."

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"

Calidad de software - Wikipedia, la enciclopedia libre

Calidad de software - Wikipedia, la enciclopedia libre

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."

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"

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:

1. 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.
2. El factor olla de oro: demuestre que en lo alto de la montaña hay oro en abundancia, del cual todos podrán disfrutar.
3. 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.
4. 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.

Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.rar - download now for free. File sharing. Software file sharing. Free file hosting. File upload. FileFactory.com

Ingenieria.de.Software.-.Ian.Sommerville.7ma.Edicion.PRENTICE-HALL.rar - download now for free. File sharing. Software file sharing. Free file hosting. File upload. FileFactory.com:

The Mythical Man Month Descarga English

4shared.com - almacenamiento y uso compartido de archivos gratis - descarga

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"

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."

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."

Material de una materia similar de una universidad de Guadalajara

Temario

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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."

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"

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"

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."