Taller de proyectos. 1: Refinar los requerimientos del software

Taller de proyectos. 2. Especificación de casos de uso de sistemas

Muestra el uso del RSA para la creación de un modelo de negocios: modelo de casos de uso con actores y casos de uso de negocio, y modelo de análisis con trabajadores y entidades de negocio.

Made available in DSpace on 2016-06-02T19:05:28Z (GMT). No. of bitstreams: 1 1803.pdf: 1717533 bytes, checksum: 1210db8814aa3022bcdf784743d9e6f4 (MD5) Previous issue date: 2007-01-29 / The objective of this paper was to implement an initial version of a development support environment named COCAR based on the Use Case Model. Even though the conception and some features of this environment are the outcome of several other master papers, this work emphasises the relevance of the Use Case Point metric (PCU). This metric strengthens the usage of estimates which are of fundamental importance for the calculation of a system development time. Furthermore, such a metric is associated to one of the main drivers of a software product quality, which is the ability to meet delivery time. With the advent of the object oriented development paradigm, the Use Case Point metric based on the Use Case Model has been highlighted. However, given the lack of formality and standardization, specifying and building these models a PCU metric may be jeopardized. In the scope of this work, there have been relevant contributions to building such an environment implementing a technique called TUCCA which helps with the model standardization, a functionality that supports the insertion of system requirements in the environment and the generation of PCU as in the model generated by TUCCA application. In the assessment process of the COCAR environment an informal case study, in which a specification of actual software from a development company, has been carried out, producing Use Case Models, PCU s and effort estimates, both compared against the industry benchmarks. The results of this research showed that for this particular situation the output from the COCAR environment were very close to those defined by the industry. / Este trabalho teve como objetivo a implementação de uma versão inicial de um ambiente de apoio ao desenvolvimento de software, denominado COCAR, baseado no Modelo de Casos de Uso. A concepção e as funcionalidades desse ambiente são frutos de alguns trabalhos de mestrado, sendo que no contexto deste trabalho deu-se ênfase à métrica Pontos de Caso de Uso (PCU). Essa métrica dá subsídios à aplicação de técnicas de estimativas, as quais são fundamentais para o cálculo do tempo de desenvolvimento de um sistema, o qual está associado a uma das características principais relacionadas à qualidade de um produto de software, que é o atendimento de seu prazo de entrega. Com o advento do paradigma de desenvolvimento orientado a objeto, tem ganhado destaque os Pontos de Caso de Uso, que se baseia no Modelo de Casos de Uso da UML. Porém, dada a falta de formalidade e padronização na especificação e construção desses modelos, a métrica de PCU pode ficar comprometida. Assim, no contexto deste trabalho contribui-se para a construção desse ambiente implementando-se uma técnica denominada TUCCA, que ajuda nessa padronização do modelo, uma funcionalidade que apóia a inserção dos requisitos do sistema no ambiente, e a geração dos PCU, com base no modelo gerado com a aplicação da TUCCA. Para a avaliação do ambiente COCAR foi realizado um estudo de caso informal, no qual uma especificação de software real, de uma empresa de desenvolvimento de software foi submetida ao ambiente COCAR, gerando-se o Modelo de Casos de Uso bem como o PCU e a estimativa de esforço, os quais foram comparados àqueles gerados pela indústria. Os resultados deste pequeno estudo mostraram que, para esta situação específica, os resultados apresentados pelo ambiente COCAR foram bastante semelhantes àqueles definidos pela indústria.

Video que muestra la creación de artefactos relativos al modelo de negocio, según RUP.

Made available in DSpace on 2014-06-12T16:00:36Z (GMT). No. of bitstreams: 2 arquivo6806_1.pdf: 3125791 bytes, checksum: d312e759783582d509c1403b479df91e (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / No ciclo de vida de desenvolvimento de software, especificação de requisitos é uma atividade muito propensa a definições incorretas. Isto geralmente acontece porque esses documentos são normalmente escritos em linguagem natural, tornando muito alta a possibilidade de introduzir ambiguidades e interpretações errôneas. Por outro lado, a utilização de linguagem natural traz simplicidade e flexibilidade ao se especificar requisitos, considerando que esta é uma notação que pode ser compreendida tanto pelo cliente quanto pelo desenvolvedor. Uma vez que projetos de software possuem documentos precisos, engenheiros de software que tenham bom conhecimento em linguagens formais podem criar manualmente uma especificação formal com o propósito de validar as propriedades do sistema. No entanto, esta criação manual pode não cobrir todos os requisitos ou podem conter inconsistências. Desta forma, a geração automática de modelos formais a partir de documento de requisitos parece ser uma boa solução para este problema. Para alcançar este objetivo, os documentos de requisitos devem ser simples, diretos, uniformes e sem ambuiguidades. Para que isto aconteça, Linguagens Naturais Controladas (Controlled Natural Languages - CNL) são comumente utilizadas. Este trabalho faz parte do projeto de Pesquisa e Desenvolvimento do CIn Brazil Test Center (CInBTCRD), que é uma cooperação entre a Motorola e o Centro de Informática da Universidade Federal de Pernambuco (CIn-UFPE). Em primeiro lugar, este trabalho propõe uma linguagem restrita (CNL) para definir casos de uso contendo uma noção de estado, os quais consideram dados de entrada, saída, guarda e atualização de variáveis, como um complemento para a descrição textual. Depois disso, uma tradução automática dessa linguagem para a algebra de processos CSP foi proposta, a fim de permitir a análise formal de requisitos e geração de casos de teste. Finalmente, foi realizada a implementação e integração desta linguagem e sua tradução para CSP em uma ferramenta conhecida como TaRGeT, cujo propósito é a geração de casos de teste a partir de documentos de casos de uso que seguem um template padrão e são escritos utilizando uma CNL. A TaRGeT original não era capaz de lidar com definições de dados e as manipulações destes dados, e utiliza sistemas rotulados por transição (labelled transition systems) em vez de CSP, como formalismo. Para ilustrar as técnicas propostas neste trabalho, um estudo de caso foi realizado no ambiente da Motorola, adaptando um exemplo de caso de uso real da indústria de modo a encaixá-lo no nosso template. O documento de caso de uso considera situações de envio e recebimento de SMS/MMS, contendo uma feature com 7 casos de uso, incluindo definições e manipulações de dados, relacionamentos entre casos de uso e 6 fluxos alternativos. O CSP gerado contém 570 linhas de código e a verificação de suas propriedades foi checada com sucesso utilizando-se a ferramenta FDR, um verificador de modelo para CSP

FundaÃÃo de Amparo à Pesquisa do Estado do Cearà / RÃSUMà Ce travail fait une analyse comparative concernant lâemploi des pronoms tu / vous, on /nous et des verbes assister et aller (demandant ou non la prÃposition) dans le langage parlà à Fortaleza, oà nous avons cherchà à identifier les faits (linguistiques et/ou extralinguistiques) qui influent aux choix lexicales et syntactiques du peuple de Fortaleza et observer les variables linguistiques qui se prÃsentent en tant que cas de norme (dâemploi majeur) et cas dâusage (dâemploi mineur). Pour ce, nous avons seletionnà 24 informants: 14 du PORCUFORT â Portugais Oral Culte de Fortaleza (Code C1) et 10 du corpus  Le langage parlà à Fortaleza â Dialogues entre Informants et Documentateurs â matÃriaux dâÃtude  (Code C2), vu que ceux du 1er corpus sont de niveau supÃrieur complet, oà leur Ãge varie de 25 à 67 ans, et ceux du 2Ãme corpus sont du premier ou du second degrà complet et/ou incomplet, oà leur Ãge varie de 14 à 39 ans. LâinterprÃtation des rÃsultats a dÃmontrà que la priorità dâune variante lexicale et dâune variante syntactique, au dÃtriment dâautre(s), a lieu selon le contexte socio-interactionnel / pragmatique, spÃcialement en ce qui concerne la rÃalisation de lâinterview de chaque corpus (selon le type dâacte de parole), la  motivation tÃmatique  et le rÃle jouà aussi bien par le documentateur que par lâinformant dans le processus interactif; et non pas par rapport à ce qui est dÃterminà par la tradition grammaticale, en tant que  bon usage  ou  usage correct  de la langue. Ainsi, en ce qui concerne les variantes lexicales et syntactiques, respectivement, se prÃsentent comme cas de norme: vous / on (ayant tous le verbe à la 3Ãme personne du singulier); le verbe assister + objet direct et aller sans complÃment de lieu, au dÃtriment des  formes usuelles  selon la tradition grammatical; tu (verbe à la 2Ãme personne du singulier); nous (verbe à la 1Ãre personne du pluriel); le verbe assister + objet indirect et aller + à ou POUR + complÃment de lieu. De ce fait, ces derniÃres, aussi que les formes verbales: assister, avec ommision du complÃment verbal ; aller + complÃment de lieu (sans prÃposition) et aller + EN + complÃment de lieu, paraissent en tant que cas dâusage dans le langage parlà à Fortaleza. Mots-clefs: parler de Fortaleza, analyse comparative, cas de norme, cas dâusage. / RESUMO Este trabalho apresenta uma anÃlise comparativa quanto ao emprego dos pronomes tu/vocÃ, a gente/nÃs e dos verbos assistir e ir (regidos ou nÃo de preposiÃÃo) na linguagem falada em Fortaleza, em que procuramos identificar os fatores (lingÃÃsticos e/ou extralingÃÃsticos) que influenciam as escolhas lexicais e sintÃticas feitas pelos fortalezenses e examinar quais variÃveis lingÃÃsticas se configuram como casos de norma (de emprego majoritÃrio) e casos de uso (de emprego minoritÃrio). Para tanto, selecionamos 24 sujeitos: 14 do PORCUFORT â PortuguÃs Oral Culto de Fortaleza (CÃdigo C1) e 10 do corpus âA linguagem falada em Fortaleza â DiÃlogos entre Informantes e Documentadores â materiais para estudoâ (CÃdigo C2), sendo que os do primeiro corpus possuem nÃvel superior completo, com faixa etÃria que varia de 25 a 67 anos; e os do segundo corpus, 1 ou 2 Grau (in)completo, com faixa etÃria que varia de 14 a 39 anos. Pela interpretaÃÃo dos resultados, concluÃmos que a priorizaÃÃo de uma variÃvel lexical e de uma sintÃtica em detrimento de outra(s) se faz de acordo com o contexto sÃcio-interacional /pragmÃtico, em especial devido à maneira como a entrevista se dà em cada corpus (ao tipo de registro), a uma âmotivaÃÃo temÃticaâ e ao papel desempenhado tanto pelo documentador quanto pelo informante no processo interativo; e nÃo de acordo com o que à prescrito pela tradiÃÃo gramatical como âbom usoâ ou âuso corretoâ da lÃngua. Assim, concernente Ãs variantes lexicais e sintÃticas, respectivamente, configuram-se como casos de norma: vocà / a gente (ambos com verbo na 3 pessoa do singular); assistir+objeto direto e ir, com omissÃo do complemento de lugar, em detrimento das âformas padronizadasâ pela tradiÃÃo gramatical: tu (com verbo na 2 pessoa do singular); nÃs (com verbo na 1 pessoa do plural); assistir+objeto indireto e ir+A ou PARA+complemento de lugar. Por conseguinte, estas, juntamente com as formas verbais: assistir, com omissÃo do complemento verbal; ir+complemento de lugar (sem preposiÃÃo) e ir+EM+complemento de lugar, sÃo tidas como casos de uso na linguagem falada em Fortaleza. Palavras-chave: falar de Fortaleza; anÃlise comparativa; casos de norma; casos de uso.

No description available.

En cualquier tipo de centro educativo existen diversos procesos que permiten organizar y administrar los recursos académicos de la institución. Estos procesos manejan como recurso principal la información de los alumnos, profesores, aulas, laboratorios, cursos y planes curriculares. Lo que se busca es manejar los recursos ordenadamente e integrarlos para que se encuentren a disposición del cliente final de toda institución educativa: el estudiante. Dichos procesos se realizan cada cierto lapso de tiempo. Uno de ellos es la construcción de horarios, la cual se realiza cada periodo académico por coordinadores o responsables de dicho proceso. Se requiere la formalización del proceso de construcción de horarios, como es su documentación; asimismo, que siga las mejores prácticas de los usuarios tales como orden, facilidad y agilidad de realización y finalmente, reducción de los niveles de error. Por todo este diagnóstico es que resulta útil, desde el punto de vista práctico, contar con la información necesaria de manera rápida, confiable y de fácil administración. Es por ello que en los siguientes capítulos se va a explicar el proceso de construcción de horarios en las carreras y áreas de la Universidad Peruana de Ciencias Aplicadas (UPC), así como un análisis del mismo y de los posibles puntos de mejora. Por último, se procederá a presentar el proyecto que tiene como objetivo principal el desarrollo de un producto software que sirva como herramienta de ayuda a los encargados de realizar el proceso de construcción de horarios. Se tienen como objetivos específicos los siguientes puntos: • Recoger los requerimientos de las diferentes fuentes de información del proceso de construcción de horarios de la UPC durante la fase de concepción del proyecto. • Presentar una propuesta para automatizar las tareas dentro de la construcción de horarios por medios de flujos de procesos durante la fase de concepción del proyecto. Esto permite finalmente la agilización del proceso. • Dar soporte a los encargados de realizar la construcción de horarios al momento de crear secciones y asignar horarios de los cursos que se dictarán en el siguiente ciclo. • Controlar la información relacionada a la disponibilidad de profesores y aulas para realizar la construcción de horarios y mostrar información adicional a lo largo del proceso que ayude al usuario en la toma de decisiones dentro del sistema. Además, la asignación de áreas y cursos a los profesores. • Ordenar la información relacionada a las notas del ciclo actual de los alumnos, sus cursos aprobados y el plan curricular en vigencia para obtener información valiosa como la cantidad aproximada de alumnos hábiles por curso y cantidad de cruces de alumnos entre los cursos. • Desplegar el producto software en los servidores de la UPC en la fase de Transición para el área de Computación e Informática. Finalmente, al concluir el proyecto, para verificar que el Sistema de Horarios haya cumplido todos los requerimientos y objetivos planteados, se usó el producto para construir los horarios del ciclo 2009-01 los cuales fueron probados y aprobados por Rosario Villalta. / Tesis

Made available in DSpace on 2016-06-02T19:05:28Z (GMT). No. of bitstreams: 1 1792.pdf: 1793786 bytes, checksum: 8e3f39a83c69deddf07abe1063163387 (MD5) Previous issue date: 2008-01-29 / The objective of this work was to implement an initial version of a development support environment, based on the Use Case Model, named COCAR. The conception and the features of this environment are the result of several master papers. In the scope of this work, the main subject under study has been requirement management, although concerning its implementation, functionalities related to other previous works have also been contemplated. This environment prop up a few software development tasks, aiming at leveling up qualitity throughout the process. It is well know that one of the principal characteristics related to software product quality is that the product should meet the user requirements. In requirement engineering, the comunication between the user and the developer is stated in the Requirement Document and based on it, the requeriment can be modelled, for instance, by means of the Use Case Model. Despite the efforts invested in gathering requirements with the user, it is know that they are very likely to be ammended during the development process. A fundamental factor for the maintainance of the overall quality is that such modifications to the requirements occur in a monitored and foreseeable way. The ability to describe and follow a requirement life-cycle within the software development process is denominated requirement traceability. As the requirement document represents what binds the user and the developers, if traceability is obtained from that point onwards, the quality of the development process tend to increase and this permits monitoring since its earliest phases. This paper contribution to the implementation of the environment COCAR, includes features such as: registering the requirement of a system, generating of a Use Case Model, requirement management (mainly what concerns traceability between the Requirement Document and the Use Case Model), providing traceability metrics found in academic literature and the possibility of determining the relationship between the requirements. Based on the data provided by the tool, it is easy to perceive that they are highly relevant to any system development planning or following up, which can be an important pragmatic contribution to the improvement of software development and software products. / Este trabalho teve como objetivo a implementação de uma versão inicial de um ambiente de apoio ao desenvolvimento de software, baseado no Modelo de Casos de Uso, denominado COCAR. A concepção e as funcionalidades desse ambiente são frutos de alguns trabalhos de mestrado. No contexto deste trabalho o objetivo principal de estudo foi o gerenciamento de requisitos, embora, em termos de implementação, funcionalidades relacionadas a outros trabalhos anteriores foram também contempladas. Esse ambiente apóia algumas atividades do desenvolvimento de software, procurando aumentar a qualidade ao longo desse processo. Sabe-se que uma das principais características relacionadas à qualidade de um produto de software é que este atenda aos requisitos do usuário. Na Engenharia de Requisitos, a comunicação entre usuário e desenvolvedor é registrada no Documento de Requisitos, sendo que, a partir deste, os requisitos podem ser modelados, por exemplo, por meio de Modelos de Casos de Uso. Apesar dos esforços em levantarem-se as necessidades junto ao usuário, sabe-se que os requisitos solicitados serão alterados durante o processo de desenvolvimento. Um ponto fundamental para que a qualidade seja mantida é que essas alterações ocorram de forma controlada e previsível. A capacidade de descrever e acompanhar a vida de um requisito dentro do processo de desenvolvimento de software é chamada rastreabilidade de requisitos. Como o documento de requisitos representa o elo entre o usuário e os desenvolvedores, caso a rastreabilidade seja obtida a partir desse ponto, a qualidade do processo de desenvolvimento tende a ser melhor e a permitir um controle desde suas fases iniciais. A contribuição deste trabalho para a implementação do ambiente COCAR incluiu as funcionalidades de registro dos requisitos de um sistema, a geração do Modelo de Casos de Uso e o gerenciamento de requisitos, sobretudo no que diz respeito aos aspectos de rastreabilidade, entre o Documento de Requisitos e o Modelo de Casos de Uso, oferecendo métricas de rastreabilidade propostas na literatura e possibilidade de determinação do relacionamento entre os requisitos. Com base nas informações oferecidas pela ferramenta, pode-se perceber que elas são de grande valia para o planejamento e acompanhamento do desenvolvimento de um sistema, o que pode ter uma grande contribuição prática para a melhoria da qualidade do processo e do produto.