La verdad que no tengo ni idea, no es muy específica la pregunta. Pero supongo que se refiere más bien a qué tipo de proceso representa, no se si lo que pretende es que des un ejemplo o qué...

Tenes q hacer el diagrama solamente (Red de Petri)

http://www.google.com.ar/images?hl=es&bi...CDAQsAQwAQ

Pero, ya esta hecha la red !
Sigo sin entender que pide jaja.

Alguién resolvió el de normalización ??

Respecto al punto 4 de los VoF

Alguien pudo resolverla? yo no encuentro info a cerca del modelo de ambientes.

Primero que nada, no entiendo la sutileza entre la pregunta del final del 4-12 y la del 11-12.
Una dice:
"En los ejes del modelo de ambientes se puede encontrar la evolución y el crecimiento de experiencia y conocimientos del profesional de sistemas".
En la otra dice:
"En los ejes del modelo de ambientes se puede encontrar el objetivo de la evolución y el crecimiento de la experiencia y conocimientos del profesional de sistemas".

Los ejes del modelo de ambientes son:
• Tipo de Organización que plantea problemas y recibe soluciones de sistemas, o sea, el tipo de empresa (pequeña, mediana, grande, corporacion)
• Tecnología disponible para construir soluciones (pc, red, unix, as400, mainframe)
• Tipo de problema (sistema) a construir (sistemas secuenciales, sistemas online, sistemas de tiempo real, inteligencia artificial...)

Asi que yo podría decir que si, que es VERDADERO.
Lo que dice la teoría es: Cada individuo a través de su experiencia profesional y práctica ira realizando un camino que lo lleve por un eje o por mas de uno, enriqueciendo su capacidad y habilidades para resolver y construir distinto tipos de soluciones de mayor complejidad cada vez.

Igualmente, les subo un archivo que tengo sobre el modelo de Petters y el de Ambientes, espero que les sirva!

Buenas! Una consulta del final del 4-12-10

La pregunta 7 no sería V?
Ya que por ejemplo el SO de un STR tiene quede poder manejar señales cosa que no todos los SO manejan, entre otras características que deben tener.

Según los apuntes que tengo tanto el lenguaje de programación como el SO de un STR deben tener ciertas características particulares.
Puede ser?



Saludos!!!

Leyendo mas a fondo cambiamos varias VoF

Respecto a la 7, es V. Pensamos que no necesariamente se necesitaba de un SO. Pero en el apunte aclara que es un componente.

Gente alguien tiene de donde sacar el punto que habla de la pirámide? pq no lo vi en el cursada y no tengo idea de como es. Gracias!

Saludos!

Esta en el Presman! Pero te paso una imagen para que quede algo por si no lo encontras (por cierto, el peor dibujo. Espero que se entienda)
Lo importante no son los metodos o herramientas que apliques, importa una buena base de Diseño para que el sistema sea "feliz" (que sea facil de mantener, y no se pierda tiempo en decodificar y pruebas)

http://img574.imageshack.us/i/pira.png/

no tengo el pressman por eso jaja muchas gracias!!

Gente algunas dudas...

V o F ?

Los requerimientos funcionales se obtienen mediante entrevistas con usuarios.
El alto y ancho de una carta estructurada no son heurísticas de diseño.

PARA DESARROLLAR
Cómo se especifican los requerimientos ?
LOS REQ FUNCIONALES MEDIANTE MODELOS DE CASO DE USO Y LOS REQ NO FUNCIONALES MEDIANTE UNA ESPECIFICACION ADICIONAL EN FORMA DE TEXTO
Está bien así ?

(16-12-2010 00:15)Cheppak escribió:  Bueno, intentamos resolver los finales con un compañero.
Nos falto en ambos finales el punto 4, porque tenemos poca info del modelo ambiental.

4/12

1) F 2) F 3) V 5) F 6) F 7) F 8) F 9) F 10) F 11) V 12) Prototipado

11/12

1) F 2) V 3) V 5) F 6) F 7) V 8) F 9) V 10) F 11) F 12) Idem 4/12 (ojo tiene mas experiencia! jaja )

Si el apunte queda algo prolijo subo las resoluciones de los ejercicios practicos.

Cheppak, disculpame que te joda, pero estoy resolviendo el ejercicio practico 1 del final del 11-12-2010 (el de la fabrica de auto).
Subir toda la practica es un bardo... Pero podrías poner así mas o menos los casos de uso y como se relacionan (include, extender, etc). Ya que veo que hay varias tomas de deciciones y quiero compararlo con lo que estoy haciendo.
Muchas gracias por todos tus aportes!

Saludos

(17-12-2010 19:12)Unbekant escribió:  Gente algunas dudas...

V o F ?

Los requerimientos funcionales se obtienen mediante entrevistas con usuarios.
El alto y ancho de una carta estructurada no son heurísticas de diseño.

PARA DESARROLLAR
Cómo se especifican los requerimientos ?
LOS REQ FUNCIONALES MEDIANTE MODELOS DE CASO DE USO Y LOS REQ NO FUNCIONALES MEDIANTE UNA ESPECIFICACION ADICIONAL EN FORMA DE TEXTO
Está bien así ?

[Sacado de "Gestion de Requerimientos.pdf"]

Especificación de Requerimientos
• Documento estructurado con descripción o detalle de los servicios del Sistema. Escrito como un contrato ntre el cliente y el contratista.

(La especificación de requerimientos permite establecer una comunicación formal entre los diferentes roles asociados al desarrollo de sistemas de software)

--------

Los requerimientos funcionales se obtienen mediante entrevistas con usuarios ? V

El alto y ancho de una carta estructurada no son heurísticas de diseño. V, no me puedo guiar por el ancho y alto de una carta (o sea, un diagrama) si podria guiarme por el Fan In y el Fan Out.

Mmm disiento con Cheepak en la respuesta de:
El alto y ancho de una carta estructurada no son heurísticas de diseño.

Para mi es Falsa.
Las Heurísticas de diseño son:
Cohesión
Acoplamiento
Envolvente de Forma
Alcances efecto y control
Tamaño de Módulos
Ancho y profundidad
Fan_In / Fan_Out (Abanicos de entrada y de salida)
Desbalances
Trampolines de datos

El ancho y alto tiene que ver con el uso eficaz de la factorización, es decir, de modularizar el sistema. Pensalo como si hubiera un solo modulo de entrada y toooodos los modulos de funciones y eso, colgaran de ese unico modulo.
Y el alto es algo similar, pensalo como si hicieras un unico modulo de entrada con todos modulos en cascada que dependen unos de otros.
Se relaciona un poco con la envolvente de forma, pero a mi me lo dieron como una heurística particular.