Análise e Modelação de Requisitos

A área de requisitos de software trata a aquisição, análise, especificação, validação e manutenção de requisitos do software. Entende-se por requisitos as propriedades que os sistemas (ainda em projecto) devem vir a manifestar aquando da sua realização. Os requisitos do software exprimem as necessidades e as constrições que são colocadas a um sistema de software e que devem ser tidas em conta aquando do seu desenvolvimento. Esta área é já reconhecida como de primordial importância para a indústria de software, dado o impacto que as suas actividades geram na estabilização e gestão de todo o processo de desenvolvimento de software.

Programa resumido

• Processo de engenharia de requisitos;
• Levantamento de requisitos;
• Análise de requisitos;
• Especificação e modelação de requisitos;
• Validação de requisitos;
• Gestão de requisitos.

Resultados de Apreendizagem Específicos

• Definir qual a intervenção que a equipa de engenharia de requisitos deve executar ao nível de todo os processo de engenharia de software, explicitando o envolvimento formal dos stakeholders, ao longo de todo o processo de engenharia de requisitos.
• Tratar a forma como devem ser capturados os requisitos, bem como as técnicas que devem ser utilizadas para ajudar as diversas fontes de requisitos (humanos e não humanos) a "libertá-los" correctamente.
• Detectar e resolver conflitos entre os requisitos capturados, definir a fronteira do sistema em projecto e como ele interactua com o seu meio ambiente, bem como transformar requisitos do sistema em requisitos de software.
• Tratar o documento de requisitos do ponto de vista da sua estrutura, qualidade e verificabilidade, normalmente organizado em duas partes distintas: (1) o documento de definição de requisitos que descreve os requisitos do utilizador; (2) a especificação dos requisitos de software que estabelece o acordo entre os clientes e os fornecedores do sistema de software.
• Examinar o documento de requisitos a fim de garantir que ele descreve o sistema pretendido, à custa, por exemplo, da execução de inspecções (ou revisões formais) do documento, ou da prototipagem rápida das suas interfaces.
• Gerir a alteração dos requisitos, garantir uma semântica bem definida para os mesmos, assim como rastreá-los ao longo de todo o processo de desenvolvimento.

-- 08 May 2007

8 Mai Site criado.

• Análise e Modelação de Requisitos - 5 ECTS
• Arquitecturas de Software - 5 ECTS
• Métodos Formais no Projecto de Software - 5 ECTS
• Usabilidade e Interacção - 5 ECTS
• Projecto Integrado - 10 ECTS

-- 08 May 2007

Projecto Integrado

Com esta unidade curricular pretende-se integrar, num único projecto de cariz implementacional (relativo à execução das actividades de desenvolvimento de software), as competências desenvolvidas nas restantes unidades curriculares deste módulo. A fase de implementação é um acto fundamental da engenharia de software, ou seja, consiste na construção de software de acordo com o pretendido e a funcionar correctamente, através da combinação de actividades de codificação, validação e teste. A implementação de software está intimamente ligada à concepção, visto que a primeira deve transformar em suporte tecnológico (código) as arquitecturas concebidas e descritas pela segunda. Esta transformação tende a ser cada vez mais automática, pois existem sub-tarefas perfeitamente repetitivas e mecanicistas. Assim, é na implementação de software que a utilização de ferramentas se mostra mais crítica.

Considera-se desejável que o projecto integrado funcione segundo a abordagem PLEE (Project-Led Engineering Education). Assim, as temáticas a ministrar nas restantes unidades curriculares devem contribuir directamente para a execução do projecto, o que obriga a uma coordenação entre todos os docentes envolvidos, de forma a que esta unidade curricular seja, de facto, um projecto de desenvolvimento de software que integra um conjunto muito alargado das valências previstas. Em especial, espera-se que o enfoque das restantes disciplinas seja fortemente condicionado pelas temáticas incluídas no projecto.

Programa resumido

• Desenvolvimento de um projecto integrador com a inclusão de todos os conhecimentos focados nas restantes unidades curriculares
• Tratamento, numa óptica de projecto, da componente de testes do sistema software, abrangendo os testes unitários de integração e carga.

Resultados de Apreendizagem Específicos

• Construir, em equipa, sistemas de software complexos, de acordo com o pretendido e a funcionar correctamente, através da combinação de actividades de análise, concepção, codificação, validação e teste.
• Aplicar, em contextos práticos, os conhecimentos adquiridos no módulo, em projecto de exigência similar ao que os encontrarão na indústria, quando profissionais.
• Utilizar ferramentas (meta-CASE, frameworks IDEs), nomeadamente no contexto das actividades menos criativas e nas quais o ser humano tem mais tendência para cometer erros.
• Usar normas, para garantir a uniformidade processual e notacional e para permitir a interoperabilidade e portabilidade das soluções.

-- 08 May 2007

Usabilidade e Interacção

A Usabilidadee é uma propriedade da interacção entre um dado sistema e os seus utilizadores definida pela norma ISO 9241-11 como "a eficácia, eficiência e satisfação com que determinados utilizadores, atingem determinados objectivos em ambientes específicos". Assegurar a usabilidade de um sistema software corresponde, assim, a desenvolvê-lo por forma a que os utilizadores possam atingir os seus objectivos da forma o mais eficiente e satisfatória possível. Questões como a definição e avaliação de objectivos de usabilidade, análise de tarefas, ou definição das metáforas e paradigmas de interacção mais apropriados a um dado contexto, têm impacto em todo o processo de desenvolvimento, desde a análise de requisitos até à implementação, passando pela concepção e avaliação dos sistemas. A Engenharia da Usabilidade agrega um conjunto de métodos, técnicas e ferramentas, derivadas da área de Interacção Humano-Computador, que permitem tornar a usabilidade um factor central no desenvolvimento de software.

Programa resumido

• Fundamentos de IHC: Modelos e Teorias (modelos cognitivos, o computador, modelos de interacção).
• Engenharia da usabilidade: definição do problema (estudo dos utilizadores, análise de tarefas); definição de requisitos e objectivos de usabilidade; concepção do sistema (estilos de interacção, desenho conceptual, guidelines); avaliação de usabilidade (avaliação empírica, avaliação analítica, o Usability Maturity Model - ISO 18529.
• Prototipagem rápida de interfaces: diferentes tipos de protótipos; Toolkits; ambientes de desenvolvimento; prototipagem e avaliação.
• Arquitecturas software para sistemas interactivos: identificação de padrões, arquitecturas para aplicações interactivas móveis.

Resultados de Apreendizagem Específicos

• Identificar os diferentes tipos de modelos relevantes no processo de engenharia de usabilidade.
• Aplicar técnicas de análise de usabilidade.
• Desenvolver uma interface com utilização de toolkits e componentes existentes, criando para tal uma arquitectura software de suporte ao sistema interactivo.

-- 08 May 2007

50 Recent Changes in TWiki Web retrieved at 16:21 (GMT)

See also: RSS feed, recent changes with 50, 100, 200, 500, 1000 topics, all changes

Sumário

A análise e a concepção são actividades incluídas no processo de desenvolvimento de software. O desenvolvimento refere-se às fases do ciclo de vida responsáveis pelo projecto de construção de sistemas, incluindo ainda a implementação (também designada de construção). Excluem-se, por exemplo, os estudos de viabilidade económica, as tarefas de manutenção e a utilização efectiva do sistema.

A unidade curricular de "Análise e Concepção de Software", do Mestrado de Informática da Universidade do Minho, tem como principal objectivo dotar os estudantes de competências tecnológicas, científicas e metodológicas no contexto do desenvolvimento (e mais concretamente nas tarefas de análise e concepção) de sistemas de software de elevada complexidade, para obter soluções correctas e fiáveis recorrendo aos princípios básicos da engenharia.

Esta unidade, cujos módulos internos que a consubstanciam correspondem a 30 ECTS, organiza-se em torno de quatro áreas científicas, definidas no IEEE/ACM Curriculum Guidelines for Software Engineering [SE 2004]:

• MAA - Software Modeling & Analysis
• DES - Software Design
• VAV - Software V&V
• PRF - Professional Practice

Para frequentar esta unidade, os alunos devem possuir as competências associadas às duas seguintes SEEK (Software Engineering Educational Knowledge) Areas [SE 2004]:

• CMP - Computing Essentials (Computer Science foundations, Construction technologies, Construction tools, Formal construction methods)
• FND - Mathematical & Engineering Fundamentals (Mathematical foundations, Engineering foundations for software, Engineering economics for software)

Estas competências são, grosso modo, obtidas pelos alunos que frequentam as licenciaturas de 1º ciclo em TIC da U.Minho. Em concreto, espera-se que os alunos sejam capazes de construir programas usando métodos rigorosos de especificação e linguagens de programação e de pôr a executar os programas escritos, usando as ferramentas adequadas (editores, compiladores, interpretadores, depuradores, IDEs).

O aluno interessado por esta unidade será aquele que, após formação na área da programação de computadores, pretende complementar essas suas competências tecnológicas, com uma vertente mais vocacionada para a execução de actividades de desenvolvimento de software, segundo uma abordagem de engenharia (engenheiro de software, engenheiro de requisitos, analista de sistemas, arquitecto de software).

A avaliação é feita por exame global único e aborda os assuntos tratados em todos os módulos que cosntituem a unidade curricular.

Coordenação Científica

• João M. Fernandes
• Fernando Mário Martins
• Olga M. Pacheco
• António J. Esteves
• Ricardo J. Machado

Classificação ACM

• Software / SOFTWARE ENGINEERING / General / Standards: 3 ECTS
• Software / SOFTWARE ENGINEERING / Requirements/Specifications: 7 ECTS
• Software / SOFTWARE ENGINEERING / Design Tools and Techniques: 7 ECTS
• Software / SOFTWARE ENGINEERING / Coding Tools and Techniques: 5 ECTS
• Software / SOFTWARE ENGINEERING / Software Architectures: 6 ECTS
• Information Systems / INFORMATION INTERFACES AND PRESENTATION / User Interfaces: 2 ECTS

-- 08 May 2007

Education/ACS Web Preferences

The following settings are web preferences of the Education.ACS web. These preferences overwrite the site-level preferences in TWiki.TWikiPreferences and Main.TWikiPreferences, and can be overwritten by user preferences (your personal topic, eg: TWikiGuest in the Main web).

Web Preferences Settings

These settings override the defaults for this web only. See full list of defaults with explanation. Many of the settings below are commented out. Remove the # sign to enable a local customisation.

Natural Skin configuration

• Set SKIN=nat

• Set SKINSTYLE = Plain
• Set STYLEBORDER = thin
• Set STYLEBUTTONS = off
• Set STYLESIDEBAR = left
• Set STYLEVARIATION = none
• Set STYLESEARCHBOX = off

• Set PAGETITLE = Análise e Concepção de Software

• Set NATWEBLOGO = Análise e Concepção de Software

• Set WEBCOPYRIGHT = Copyright © by the contributing authors. Ideas, requests, problems? Send feedback.

• List of topics of the Education/ACS web:
  • #Set WEBTOPICLIST = Changes | Index | Search | Go

• Web-specific background color: (Pick a lighter one of the StandardColors).
  • Set WEBBGCOLOR = #D0D0D0
  • Note: This setting is automatically configured when you create a web

• Image, URL and alternate tooltip text of web's logo.
  Note: Don't add your own local logos to the TWikiLogos topic; create your own logos topic instead.

• Set WEBLOGOURL = WebHome
• Set #WEBLOGOIMG =
• Set WEBLOGOIMG =
• Set WEBLOGOALT = Análise e Concepção de Software

• List this web in the SiteMap. If you want the web listed, then set SITEMAPLIST to on, do not set NOSEARCHALL, and add the "what" and "use to..." description for the site map. Use links that include the name of the web, i.e. Education/ACS.Topic links.
  Note: Unlike other variables, the setting of SITEMAPLIST is not inherited from parent webs. It has to be set in every web that is to be listed in the SiteMap
  
  • Set SITEMAPLIST = on
  • Set SITEMAPWHAT = Análise e Concepção de Software
  • Set SITEMAPUSETO =
  • Note: Above settings are automatically configured when you create a web

• Exclude web from a web="all" search: (Set to on for hidden webs).
  • Set NOSEARCHALL =
  • Note: This setting is automatically configured when you create a web

• Prevent automatic linking of WikiWords and acronyms (if set to on); link WikiWords (if empty); can be overwritten by web preferences:
  • #Set NOAUTOLINK =
  • Note: You can still use the [[...][...]] syntax to link topics if you disabled WikiWord linking. The <noautolink> ... </noautolink> syntax can be used to prevents links within a block of text.

• Default template for new topics for this web:
  • WebTopicEditTemplate? : Default template for new topics in this web. (Site-level is used if topic does not exist)
  • TWiki.WebTopicEditTemplate: Site-level default topic template

• Comma separated list of forms that can be attached to topics in this web. See TWikiForms for more information.
  • Set WEBFORMS =

• Users or groups who are not / are allowed to view / change / rename topics in the Education/ACS web: (See TWikiAccessControl). Remove the # to enable any of these settings. Remember that an empty setting is a valid setting; setting DENYWEBVIEW to nothing means that anyone can view the web.
  • #Set DENYWEBVIEW =
  • #Set ALLOWWEBVIEW =
  • #Set DENYWEBCHANGE =
  • #Set ALLOWWEBCHANGE = JoaoMiguelFernandes
  • #Set DENYWEBRENAME =
  • #Set ALLOWWEBRENAME = JoaoMiguelFernandes

• Users or groups allowed to change or rename this WebPreferences topic: (e.g., TWikiAdminGroup)
  • #Set ALLOWTOPICCHANGE = JoaoMiguelFernandes
  • Set ALLOWTOPICRENAME = JoaoMiguelFernandes

• Web preferences that are not allowed to be overridden by user or topic preferences:
  • Set FINALPREFERENCES = NOSEARCHALL, ATTACHFILESIZELIMIT, WIKIWEBMASTER, WEBCOPYRIGHT, WEBTOPICLIST, DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE, ALLOWWEBCHANGE, DENYWEBRENAME, ALLOWWEBRENAME

Help on Preferences

• A preference setting is defined by:
  3 or 6 spaces * Set NAME = value
  Example:
  • Set WEBBGCOLOR = #FFFFC0
• A preferences setting can be disabled with a # sign. Remove the # sign to enable a local customisation. Example:
  
  • #Set DENYWEBCHANGE = UnknownUser
• Preferences are used as TWikiVariables by enclosing the name in percent signs. Example:
  • When you write variable %WEBBGCOLOR% , it gets expanded to #D0D0D0
• The sequential order of the preference settings is significant. Define preferences that use other preferences first, i.e. set WEBCOPYRIGHT before WIKIWEBMASTER since %WEBCOPYRIGHT% uses the %WIKIWEBMASTER% variable.
• You can introduce your own preferences variables and use them in your topics and templates.

Related Topics

• TWiki.TWikiPreferences, Main.TWikiPreferences - site-level preferences
• TWikiUsers - list of user topics. User topics can have optional user preferences
• TWikiVariables - list of common %VARIABLES%
• TWikiAccessControl - explains how to restrict access by users or groups

Tools

• Rename, move or delete this web:
  • Rename/move/delete web..., looking for references in all public webs - See also: ManagingWebs

Web Search

Search: \.*

Tópicos

• Apresentação
• Objectivos
• Resultados de Aprendizagem
• Módulos
  • AMR
  • AS
  • MFPS
  • UI
  • PI

Avisos