Tutto Flashcards

1
Q

Quali sono i processi dello sviluppo di un software?

A

Specifiche – definire cosa il sistema deve fare;Progettazione e implementazione – definire la progettazione e l’implementazione del sistema;Validazione – controllare che il sistema fa ciò che vuole il cliente; (diverso da “verifica”: controllare se il sistema faccia una certa cosa);Evoluzione – cambiare il software in base al cambiamento dei bisogni del cliente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Cosa include la descrizione di un processo, oltre alla scelta di un data model, progetto di interfacce…?

A

Prodotti - output;Ruoli - ossia le responsabilità delle persone;Pre e Post condizioni - quello che è vero prima e dopo un’attività.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Qual è la differenza tra processi agile e plan-driven?

A

Agile - la pianificazione è incrementale ed è più facile modificare il processo riflettendo le modifiche dei requisiti del cliente;
Plan-driven - tutte le attività sono pianificate in anticipo e il progresso è misurato in base a questo piano.
In generale i processi di solito includono sia elementi agile che plan-driven, e non ce n’è uno più giusto.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Quali sono i modelli di processi software?

A

Modello Waterfall - è un modello plan-driven. Si inizia dalle specifiche, si sviluppa, e quando si finisce si testa dall’inizio. Ci sono fasi distinte e separate di specifica e sviluppo, e la fase successiva non inizia finchè quella precedente non è terminata;Sviluppo incrementale - può essere agile o plan-driven. Attività di specifica, sviluppo e validazione sono intervallate;Integrazione e Configurazione - può essere agile o pla-driven. Il sistema si costruisce assemblando e configurando elementi già esistenti.In generale, i processi sono un mix di questi tre modelli.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Quali sono i problemi del modello waterfall?

A

Una partizione inflessibile del progetto in stages distinti rende difficile rispondere a cambiamenti dei requisiti del cliente. Questo modello infatti è adatto sono in quei casi in cui i requisiti siano ben definiti e le modifiche siano ridotte al minimo.Spesso nei casi in cui ci sia un grande software con stage divise tra varie aziende, questo modello diventa obbligatorio per coordinare il lavoro.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Quali sono i benefici dello sviluppo incrementale?

A
  • Il costo del riadattamento ai cambiamenti dei requisiti del clienti sono ridotti;- è più facile ricevere feedback dal cliente sullo sviluppo del lavoro;- è più veloce consegnare e sviluppare software utilizzabile dal cliente.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Quali sono i problemi dello sviluppo incrementale?

A
  • Il processo non è visibile, quindi diventa difficile misurare il progresso del software; inoltre è costoso la produzione della documentazione che cambia ad ogni versione;- la struttura si degrada a ogni aggiunta di software; introdurre ogni pezzetto è sempre più difficile e costoso.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Quali sono i vantaggi e gli svantaggi di riutilizzare componenti software già esistenti?

A

Vantaggi - costi ridotti, rischi minimi, sviluppo più veloce;Svantaggi - requisiti compromessi (il software riutilizzato può non rispecchiare totalmente i requisiti del cliente); poco controllo sull’evoluzione del software (potrebbe essere dismesso dall’azienda che lo produce).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Cos’è il processo delle specifiche e l’engineering dei requisiti di un software?

A

Il processo di stabilire quali servizi sono richiesti e i vincoli dello sviluppo del software.L’engineering dei requisiti consiste nelle fasi:- Tirare fuori i requisiti e analizzarli. Cosa si aspetta il cliente da questo software?- specifica chiara e dettagliata dei requisiti- controllo della validità di questi requisiti, fanno ciò che il cliente vuole?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Cos’è il processo di progettazione e implementazione di un software?

A

Il processo di conversione delle specifiche di sistema in un sistema eseguibile.Si progetta una struttura software che realizza le specifiche;si traduce questa struttura in un programma eseguibile.Spesso queste due attività sono intervallate.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Quali sono le attività del processo di progettazione di un software?

A

Progettazione dell’architettura - identificare la principale struttura del sistema, le principale componenti (sottosistemi e moduli) e le loro relazioni;Progettazione del database - progettare il sistema delle strutture dati e come sono rappresentate in un database;Progettazione interfaccia - progettare le interfacce tra le varie componenti;Selezione e progettazione delle componenti - cercare componenti già scritte da poter riutilizzare, in alternativa progettarle da zero.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

In cosa consiste il processo di implementazione di un software?

A

Il software è implementato sviluppando i programmi.Questo processo si intervalla con quello di progettazione.La programmazione è un’attività individuale senza procedimenti standard.Il debugging è l’attività di trovare errori e correggerli.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

In cosa consiste il processo di validazione di un software?

A

Verifica e validazione (V&V) vogliono mostrare la conformità di software alle specifiche e ai requisiti del cliente.Consiste nel controllare e revisionare i processi e testare il sistema. Testare il sistema consiste nell’eseguire i programmi con vari test cases.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Quali sono le fasi del testing?

A

Component testing - testare le singole componenti in modo indipendente;System testing - Testare il sistema nella sua interezza;Customer testing - testare con i dati del cliente per controllare che il sistema soddisfa i bisogni reali del cliente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

In cosa consiste il processo di evoluzione di un software?

A

Il software è intrinsecamente flessibile e può cambiare.I requisiti cambiano al cambiare del contesto del business, e così il software deve cambiare ed evolvere.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is software?

A

Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

What are the attributes of good software?

A

Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

What is software engineering?

A

Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use.Engineering disciplineUsing appropriate theories and methods to solve problems bearing in mind organizational and financial constraints.All aspects of software productionNot just technical process of development. Also project management and the development of tools, methods etc. to support software production.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

What are the fundamental software engineering activities?

A

Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation.Software development, where the software is designed and programmed.Software validation, where the software is checked to ensure that it is what the customer requires.Software evolution, where the software is modified to reflect changing customer and market requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

What is the difference between software engineering and computer science?

A

Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

What is the difference between software engineering and system engineering?

A

System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

What are the costs of software engineering?

A

Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

What are the best software engineering techniques and methods?

A

While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

What differences has the web made to software engineering?

A

The web has led to the availability of software services and the possibility of developing highly distributed service-based systems. Web-based systems development has led to important advances in programming languages and software reuse.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Essential attributes of good software

A

Maintainability - Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment.Dependability and security - Software dependability includes a range of characteristics including reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system.Efficiency - Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilisation, etc.Acceptability - Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

General issues that affect software

A

Heterogeneity Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices. Business and social change Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software. Security and trust As software is intertwined with all aspects of our lives, it is essential that we can trust that software. ScaleSoftware has to be developed across a very wide range of scales, from very small embedded systems in portable or wearable devices through to Internet-scale, cloud-based systems that serve a global community.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Application types

A

Stand-alone applications These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. Interactive transaction-based applications Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications. Embedded control systems These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. Batch processing systems These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Entertainment systems These are systems that are primarily for personal use and which are intended to entertain the user. Systems for modeling and simulation These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. Data collection systems These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing. Systems of systems These are systems that are composed of a number of other software systems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Issues of professional responsibility

A

Confidentiality Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.Competence Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence.Intellectual property rights Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected.Computer misuse Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Quali sono i metodi dell’agile e che caratteristiche hanno?

A

I metodi usati dall’agile:- hanno il focus sul codice piuttosto che sulla progettazione- hanno un approccio iterativo allo sviluppo software- consegne rapide e evoluzioni rapide per rispondere ai cambiamenti dei requisitie sono:Customer involvement ** - Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.Incremental delivery** - The software is developed in increments with the customer specifying the requirements to be included in each increment.People not process -The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes.Embrace change - Expect the system requirements to change and so design the system to accommodate these changes.Maintain simplicity - Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

In cosa consiste lo sviluppo agile?

A

Specifiche, progettazione e implementazione sono intervallate.Il sistema viene sviluppato come una serie di versioni e incrementi.Frequenti consegne di nuove versioni per valutazioni.Esteso uso d strumenti di supporto come test automatici per aiutare lo sviluppo.Documentazione minima, e focus sul codice.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

In cosa consiste la tecnica agile dell’extreme programming (XP)?

A

Incremental planning - Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘TasksSmall releases - The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.Simple design - Enough design is carried out to meet the current requirements and no more.Test-first development - An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.Refactoring - All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.Pair programming - Developers work in pairs, checking each other’s work and providing the support to always do a good job.Collective ownership - The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything.Continuous integration - As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass.Sustainable pace - Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivityOn-site customer - A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

In cosa consiste la tecnica agile dello User stories for requirements?

A

In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements.User requirements are expressed as user stories or scenarios.These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

In cosa consiste la tecnica agile del refactoring?

A

Conventional wisdom in software engineering is to design for change. It is worth spending time and effort anticipating changes as this reduces costs later in the life cycle.XP, however, maintains that this is not worthwhile as changes cannot be reliably anticipated.Rather, it proposes constant code improvement (refactoring) to make changes easier when they have to be implemented.Programming team look for possible software improvements and make these improvements even where there is no immediate need for them.This improves the understandability of the software and so reduces the need for documentation.Changes are easier to make because the code is well-structured and clear.However, some changes requires architecture refactoring and this is much more expensiveRe-organization of a class hierarchy to remove duplicate code.Tidying up and renaming attributes and methods to make them easier to understand.The replacement of inline code with calls to methods that have been included in a program library.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

In cosa consiste la tecnica agile del Test-first development?

A

Testing is central to XP and XP has developed an approach where the program is tested after every change has been made.XP testing features:Test-first development.Incremental test development from scenarios.User involvement in test development and validation.Automated test harnesses are used to run all component tests each time that a new release is built.Writing tests before code clarifies the requirements to be implemented.Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.Usually relies on a testing framework such as Junit.All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

In cosa consiste la tecnica agile del Customer involvement?

A

The role of the customer in the testing process is to help develop acceptance tests for the stories that are to be implemented in the next release of the system. The customer who is part of the team writes tests as development proceeds. All new code is therefore validated to ensure that it is what the customer needs. However, people adopting the customer role have limited time available and so cannot work full-time with the development team. They may feel that providing the requirements was enough of a contribution and so may be reluctant to get involved in the testing process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

In cosa consiste la tecnica agile del Test automation?

A

Test automation means that tests are written as executable components before the task is implemented These testing components should be stand-alone, should simulate the submission of input to be tested and should check that the result meets the output specification. An automated test framework (e.g. Junit) is a system that makes it easy to write executable tests and submit a set of tests for execution. As testing is automated, there is always a set of tests that can be quickly and easily executedWhenever any functionality is added to the system, the tests can be run and problems that the new code has introduced can be caught immediately.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

In cosa consiste la tecnica agile del Problems with test-first development?

A

Programmers prefer programming to testing and sometimes they take short cuts when writing tests. For example, they may write incomplete tests that do not check for all possible exceptions that may occur. Some tests can be very difficult to write incrementally. For example, in a complex user interface, it is often difficult to write unit tests for the code that implements the ‘display logic’ and workflow between screens. It difficult to judge the completeness of a set of tests. Although you may have a lot of system tests, your test set may not provide complete coverage.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

In cosa consiste la tecnica agile del Pair programming?

A

Pair programming involves programmers working in pairs, developing code together.This helps develop common ownership of code and spreads knowledge across the team.It serves as an informal review process as each line of code is looked at by more than 1 person.It encourages refactoring as the whole team can benefit from improving the system code.In pair programming, programmers sit together at the same computer to develop the software.Pairs are created dynamically so that all team members work with each other during the development process.The sharing of knowledge that happens during pair programming is very important as it reduces the overall risks to a project when team members leave.Pair programming is not necessarily inefficient and there is some evidence that suggests that a pair working together is more efficient than 2 programmers working separately.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Cos’è lo Scrum?

A

Scrum is an agile method that focuses on managing iterative development rather than specific agile practices.There are three phases in Scrum. The initial phase is an outline planning phase where you establish the general objectives for the project and design the software architecture. This is followed by a series of sprint cycles, where each cycle develops an increment of the system. The project closure phase wraps up the project, completes required documentation such as system help frames and user manuals and assesses the lessons learned from the project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Cos’è il Product backlog?

A

This is a list of ‘to do’ items which the Scrum team must tackle. They may be feature definitions for the software, software requirements, user stories or descriptions of supplementary tasks that are needed, such as architecture definition or user documentation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Cos’è lo ScrumMaster?

A

The ScrumMaster is responsible for ensuring that the Scrum process is followed and guides the team in the effective use of Scrum. He or she is responsible for interfacing with the rest of the company and for ensuring that the Scrum team is not diverted by outside interference. The Scrum developers are adamant that the ScrumMaster should not be thought of as a project manager. Others, however, may not always find it easy to see the difference.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Cos’è uno sprint?

A

A development iteration. Sprints are usually 2-4 weeks long.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Cos’è il Architectural design

A

Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system.Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Advantages of explicit architecture

A

Stakeholder communicationArchitecture may be used as a focus of discussion by system stakeholders.System analysisMeans that analysis of whether the system can meet its non-functional requirements is possible.Large-scale reuseThe architecture may be reusable across a range of systemsProduct-line architectures may be developed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Architecture and system characteristics

A

PerformanceLocalise critical operations and minimise communications. Use large rather than fine-grain components.SecurityUse a layered architecture with critical assets in the inner layers.SafetyLocalise safety-critical features in a small number of sub-systems.AvailabilityInclude redundant components and mechanisms for fault tolerance.MaintainabilityUse fine-grain, replaceable components.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

4 + 1 view model of software architecture

A

A logical view, which shows the key abstractions in the system as objects or object classes. A process view, which shows how, at run-time, the system is composed of interacting processes. A development view, which shows how the software is decomposed for development.A physical view, which shows the system hardware and how software components are distributed across the processors in the system.Related using use cases or scenarios (+1)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Architectural patterns

A

Patterns are a means of representing, sharing and reusing knowledge.An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments.Patterns should include information about when they are and when the are not useful.Patterns may be represented using tabular and graphical descriptions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

The Model-View-Controller (MVC) pattern

A

Description - Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model.When used - Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown. Advantages - Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes made in one representation shown in all of them. Disadvantages - Can involve additional code and code complexity when the data model and interactions are simple.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Layered architecture pattern

A

Used to model the interfacing of sub-systems.Organises the system into a set of layers (or abstract machines) each of which provide a set of services.Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.However, often artificial to structure systems in this way.DescriptionOrganizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system.When usedUsed when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security.AdvantagesAllows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system.DisadvantagesIn practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Repository architecture pattern

A

Sub-systems must exchange data. This may be done in two ways:Shared data is held in a central database or repository and may be accessed by all sub-systems;Each sub-system maintains its own database and passes data explicitly to other sub-systems.When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an efficient data sharing mechanism.DescriptionAll data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository. When usedYou should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. You may also use it in data-driven systems where the inclusion of data in the repository triggers an action or tool.AdvantagesComponents can be independent—they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place. DisadvantagesThe repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Client-server architecture pattern

A

Distributed system model which shows how data and processing is distributed across a range of components.Can be implemented on a single computer.Set of stand-alone servers which provide specific services such as printing, data management, etc.Set of clients which call on these services.Network which allows clients to access servers.DescriptionIn a client–server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them.When usedUsed when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable.AdvantagesThe principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services. DisadvantagesEach service is a single point of failure so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Pipe and filter architecture pattern

A

Functional transformations process their inputs to produce outputs.May be referred to as a pipe and filter model (as in UNIX shell).Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems.Not really suitable for interactive systems.DescriptionThe processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing. When usedCommonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs.AdvantagesEasy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system.DisadvantagesThe format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Application architectures

A

Application systems are designed to meet an organisational need.As businesses have much in common, their application systems also tend to have a common architecture that reflects the application requirements.A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements.Use of application architecturesAs a starting point for architectural design.As a design checklist.As a way of organising the work of the development team.As a means of assessing components for reuse.As a vocabulary for talking about application types.

54
Q

Examples of application types

A

Data processing applicationsData driven applications that process data in batches without explicit user intervention during the processing.Transaction processing applicationsData-centred applications that process user requests and update information in a system database.Event processing systemsApplications where system actions depend on interpreting events from the system’s environment.Language processing systemsApplications where the users’ intentions are specified in a formal language that is processed and interpreted by the system.examplesTwo very widely used generic application architectures are transaction processing systems and language processing systems.Transaction processing systemsE-commerce systems;Reservation systems.Language processing systemsCompilers;Command interpreters.

55
Q

Transaction processing systems

A

Process user requests for information from a database or requests to update the database.From a user perspective a transaction is:Any coherent sequence of operations that satisfies a goal;For example - find the times of flights from London to Paris.Users make asynchronous requests for service which are then processed by a transaction manager.

56
Q

Server implementation

A

These systems are often implemented as multi-tier client server/architectures (discussed in Chapter 17)The web server is responsible for all user communications, with the user interface implemented using a web browser;The application server is responsible for implementing application-specific logic as well as information storage and retrieval requests; The database server moves information to and from the database and handles transaction management.

57
Q

Web-based information systems

A

Information and resource management systems are now usually web-based systems where the user interfaces are implemented using a web browser. For example, e-commerce systems are Internet-based resource management systems that accept electronic orders for goods or services and then arrange delivery of these goods or services to the customer. In an e-commerce system, the application-specific layer includes additional functionality supporting a ‘shopping cart’ in which users can place a number of items in separate transactions, then pay for them all together in a single transaction.

58
Q

Language processing systems

A

Accept a natural or artificial language as input and generate some other representation of that language. May include an interpreter to act on the instructions in the language that is being processed.Used in situations where the easiest way to solve a problem is to describe an algorithm or describe the system dataMeta-case tools process tool descriptions, method rules, etc and generate tools.

59
Q

Compiler components

A

A lexical analyzer, which takes input language tokens and converts them to an internal form.A symbol table, which holds information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated.A syntax analyzer, which checks the syntax of the language being translated. A syntax tree, which is an internal structure representing the program being compiled.A semantic analyzer that uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text. A code generator that ‘walks’ the syntax tree and generates abstract machine code.

60
Q

Cos’è il System modeling?

A

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

61
Q

Quali sono i vari tipi di System modeling?

A

Context models - where you model the context or environment of the system.Interaction models - where you model the interactions between a system and its environment, or between the components of a system.Structural models - where you model the organization of a system or the structure of the data that is processed by the system.Behavioral models - where you model the dynamic behavior of the system and how it responds to events.

62
Q

Quali sono i UML diagram types?

A

Activity diagrams, which show the activities involved in a process or in data processing .Use case diagrams, which show the interactions between a system and its environment. Sequence diagrams, which show interactions between actors and the system and between system components.Class diagrams, which show the object classes in the system and the associations between these classes.State diagrams, which show how the system reacts to internal and external events.

63
Q

Quali sono gli usi dei graphical models?

A

As a means of facilitating discussion about an existing or proposed systemIncomplete and incorrect models are OK as their role is to support discussion.As a way of documenting an existing systemModels should be an accurate representation of the system but need not be complete.As a detailed system description that can be used to generate a system implementationModels have to be both correct and complete.

64
Q

Cosa sono i Context models?

A

Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.Social and organisational concerns may affect the decision on where to position system boundaries.Architectural models show the system and its relationship with other systems

65
Q

Cosa sono i System boundaries?

A

Fanno parte dei context models.System boundaries are established to define what is inside and what is outside the system.They show other systems that are used or depend on the system being developed.The position of the system boundary has a profound effect on the system requirements. Defining a system boundary is a political judgmentThere may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization.

66
Q

Cosa sono i Process perspective?

A

Fanno parte dei context models.Context models simply show the other systems in the environment, not how the system being developed is used in that environment.Process models reveal how the system being developed is used in broader business processes.UML activity diagrams may be used to define business process models.

67
Q

Cosa sono gli interaction models?

A

Modeling user interaction is important as it helps to identify user requirements. Modeling system-to-system interaction highlights the communication problems that may arise. Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. Use case diagrams and sequence diagrams may be used for interaction modeling.

68
Q

Cos’è lo Use case modeling?

A

Use cases were developed originally to support requirements elicitation and now incorporated into the UML.Each use case represents a discrete task that involves external interaction with a system.Actors in a use case may be people or other systems.Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

69
Q

Cosa sono le structural models?

A

Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing. You create structural models of a system when you are discussing and designing the system architecture.

70
Q

Cosa osno i Class diagrams?

A

Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes that indicates that there is some relationship between these classes. When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

71
Q

Cosa sono i Behavioral models?

A

Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment. You can think of these stimuli as being of two types:Data Some data arrives that has to be processed by the system.Events Some event happens that triggers system processing. Events may have associated data, although this is not always the case.

72
Q

Cosa sono i Data-driven modeling?

A

Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing. Data-driven models show the sequence of actions involved in processing input data and generating an associated output. They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system.

73
Q

Cosa sono gli Event-driven modeling?

A

Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone. Event-driven modeling shows how a system responds to external and internal events. It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.

74
Q

Cosa sono i State machine models?

A

These model the behaviour of the system in response to external and internal events.They show the system’s responses to stimuli so are often used for modelling real-time systems.State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.Statecharts are an integral part of the UML and are used to represent state machine models.

75
Q

Cos’è la Model-driven engineering?

A

Model-driven engineering (MDE) is an approach to software development where models rather than programs are the principal outputs of the development process. The programs that execute on a hardware/software platform are then generated automatically from the models. Proponents of MDE argue that this raises the level of abstraction in software engineering so that engineers no longer have to be concerned with programming language details or the specifics of execution platforms.

76
Q

Cos’è la Model driven architecture?

A

Model-driven architecture (MDA) was the precursor of more general model-driven engineeringMDA is a model-focused approach to software design and implementation that uses a subset of UML models to describe a system. Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

77
Q

Quali sono i Types of model?

A

A computation independent model (CIM) These model the important domain abstractions used in a system. CIMs are sometimes called domain models. A platform independent model (PIM) These model the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events.Platform specific models (PSM) These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

78
Q

Program testing

A

Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use. When you test software, you execute a program using artificial data. You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes. Can reveal the presence of errors NOT their absence.Testing is part of a more general verification and validation process, which also includes static validation techniques.

79
Q

Program testing goals

A

To demonstrate to the developer and the customer that the software meets its requirements. For custom software, this means that there should be at least one test for every requirement in the requirements document. For generic software products, it means that there should be tests for all of the system features, plus combinations of these features, that will be incorporated in the product release. The first goal leads to validation testingTo discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification. Defect testing is concerned with rooting out undesirable system behavior such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption.The second goal leads to defect testing

80
Q

Validation and defect testing

A

Validation testingTo demonstrate to the developer and the system customer that the software meets its requirements A successful test shows that the system operates as intended.Defect testingTo discover faults or defects in the software where its behaviour is incorrect or not in conformance with its specification A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system.

81
Q

Verification vs validation

A

Verification: “Are we building the product right”.The software should conform to its specification.Validation: “Are we building the right product”.The software should do what the user really requires.

82
Q

V & V confidence

A

Aim of V & V is to establish confidence that the system is ‘fit for purpose’.Depends on system’s purpose, user expectations and marketing environmentSoftware purposeThe level of confidence depends on how critical the software is to an organisation.User expectationsUsers may have low expectations of certain kinds of software.Marketing environmentGetting a product to market early may be more important than finding defects in the program.

83
Q

Inspections and testing

A

Software inspections Concerned with analysis of the static system representation to discover problems (static verification)May be supplement by tool-based document and code analysis.Software testing Concerned with exercising and observing product behaviour (dynamic verification)The system is executed with test data and its operational behaviour is observed.

84
Q

Software inspections

A

These involve people examining the source representation with the aim of discovering anomalies and defects.Inspections not require execution of a system so may be used before implementation.They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.).They have been shown to be an effective technique for discovering program errors.

85
Q

Advantages of inspections

A

During testing, errors can mask (hide) other errors. Because inspection is a static process, you don’t have to be concerned with interactions between errors.Incomplete versions of a system can be inspected without additional costs. If a program is incomplete, then you need to develop specialized test harnesses to test the parts that are available. As well as searching for program defects, an inspection can also consider broader quality attributes of a program, such as compliance with standards, portability and maintainability.

86
Q

Inspections and testing

A

Inspections and testing are complementary and not opposing verification techniques.Both should be used during the V & V process.Inspections can check conformance with a specification but not conformance with the customer’s real requirements.Inspections cannot check non-functional characteristics such as performance, usability, etc.

87
Q

Development testing

A

Development testing includes all testing activities that are carried out by the team developing the system. Unit testing, where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces.System testing, where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions.

88
Q

Unit testing

A

Unit testing is the process of testing individual components in isolation.It is a defect testing process.Units may be:Individual functions or methods within an object Object classes with several attributes and methods Composite components with defined interfaces used to access their functionality.

89
Q

Object class testing

A

Complete test coverage of a class involvesTesting all operations associated with an object Setting and interrogating all object attributes Exercising the object in all possible states.Inheritance makes it more difficult to design object class tests as the information to be tested is not localised.

90
Q

Automated testing

A

Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention.In automated unit testing, you make use of a test automation framework (such as JUnit) to write and run your program tests. Unit testing frameworks provide generic test classes that you extend to create specific test cases. They can then run all of the tests that you have implemented and report, often through some GUI, on the success of otherwise of the tests.

91
Q

Automated test components

A

A setup part, where you initialize the system with the test case, namely the inputs and expected outputs.A call part, where you call the object or method to be tested.An assertion part where you compare the result of the call with the expected result. If the assertion evaluates to true, the test has been successful if false, then it has failed.

92
Q

Testing strategies

A

Partition testing, where you identify groups of inputs that have common characteristics and should be processed in the same way. You should choose tests from within each of these groups.Guideline-based testing, where you use testing guidelines to choose test cases. These guidelines reflect previous experience of the kinds of errors that programmers often make when developing components.

93
Q

Partition testing

A

Input data and output results often fall into different classes where all members of a class are related.Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member.Test cases should be chosen from each partition.

94
Q

Testing guidelines (sequences)

A

Test software with sequences which have only a single value.Use sequences of different sizes in different tests.Derive tests so that the first, middle and last elements of the sequence are accessed.Test with sequences of zero length.

95
Q

General testing guidelines

A

Choose inputs that force the system to generate all error messages Design inputs that cause input buffers to overflow Repeat the same input or series of inputs numerous times Force invalid outputs to be generated Force computation results to be too large or too small.

96
Q

Component testing

A

Software components are often composite components that are made up of several interacting objects. For example, in the weather station system, the reconfiguration component includes objects that deal with each aspect of the reconfiguration. You access the functionality of these objects through the defined component interface. Testing composite components should therefore focus on showing that the component interface behaves according to its specification. You can assume that unit tests on the individual objects within the component have been completed.

97
Q

Interface testing

A

Objectives are to detect faults due to interface errors or invalid assumptions about interfaces.Interface typesParameter interfaces Data passed from one method or procedure to another.Shared memory interfaces Block of memory is shared between procedures or functions.Procedural interfaces Sub-system encapsulates a set of procedures to be called by other sub-systems.Message passing interfaces Sub-systems request services from other sub-systems

98
Q

Interface errors

A

Interface misuseA calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order.Interface misunderstandingA calling component embeds assumptions about the behaviour of the called component which are incorrect.Timing errorsThe called and the calling component operate at different speeds and out-of-date information is accessed.

99
Q

Interface testing guidelines

A

Design tests so that parameters to a called procedure are at the extreme ends of their ranges.Always test pointer parameters with null pointers.Design tests which cause the component to fail.Use stress testing in message passing systems.In shared memory systems, vary the order in which components are activated.

100
Q

System testing

A

System testing during development involves integrating components to create a version of the system and then testing the integrated system.The focus in system testing is testing the interactions between components. System testing checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces. System testing tests the emergent behaviour of a system.

101
Q

System and component testing

A

During system testing, reusable components that have been separately developed and off-the-shelf systems may be integrated with newly developed components. The complete system is then tested.Components developed by different team members or sub-teams may be integrated at this stage. System testing is a collective rather than an individual process. In some companies, system testing may involve a separate testing team with no involvement from designers and programmers

102
Q

Use-case testing

A

The use-cases developed to identify system interactions can be used as a basis for system testing.Each use case usually involves several system components so testing the use case forces these interactions to occur.The sequence diagrams associated with the use case documents the components and interactions that are being tested.

103
Q

Test-driven development

A

Test-driven development (TDD) is an approach to program development in which you inter-leave testing and code development.Tests are written before code and ‘passing’ the tests is the critical driver of development. You develop code incrementally, along with a test for that increment. You don’t move on to the next increment until the code that you have developed passes its test. TDD was introduced as part of agile methods such as Extreme Programming. However, it can also be used in plan-driven development processes.

104
Q

TDD process activities

A

Start by identifying the increment of functionality that is required. This should normally be small and implementable in a few lines of code.Write a test for this functionality and implement this as an automated test. Run the test, along with all other tests that have been implemented. Initially, you have not implemented the functionality so the new test will fail. Implement the functionality and re-run the test. Once all tests run successfully, you move on to implementing the next chunk of functionality.

105
Q

Benefits of test-driven development

A

Code coverage Every code segment that you write has at least one associated test so all code written has at least one test.Regression testing A regression test suite is developed incrementally as a program is developed. Simplified debugging When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified. System documentation The tests themselves are a form of documentation that describe what the code should be doing.

106
Q

Regression testing

A

Regression testing is testing the system to check that changes have not ‘broken’ previously working code.In a manual testing process, regression testing is expensive but, with automated testing, it is simple and straightforward. All tests are rerun every time a change is made to the program.Tests must run ‘successfully’ before the change is committed.

107
Q

Release testing

A

Release testing is the process of testing a particular release of a system that is intended for use outside of the development team. The primary goal of the release testing process is to convince the supplier of the system that it is good enough for use.Release testing, therefore, has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use. Release testing is usually a black-box testing process where tests are only derived from the system specification.

108
Q

Differenza tra Release testing and system testing?

A

Release testing is a form of system testing.Important differences:A separate team that has not been involved in the system development, should be responsible for release testing.System testing by the development team should focus on discovering bugs in the system (defect testing). The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).

109
Q

Requirements based testing

A

Requirements-based testing involves examining each requirement and developing a test or tests for it.Mentcare system requirements:If a patient is known to be allergic to any particular medication, then prescription of that medication shall result in a warning message being issued to the system user.If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this has been ignored.

110
Q

User testing

A

User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing. User testing is essential, even when comprehensive system and release testing have been carried out. The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.

111
Q

Types of user testing

A

Alpha testingUsers of the software work with the development team to test the software at the developer’s site.Beta testingA release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers.Acceptance testingCustomers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems.

112
Q

Cos’è il Requirements engineering?

A

The process of establishing the services that acustomer requires from a system and the constraints under which it operates and is developed.The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process

113
Q

Differenza tra User requirements e System requirements?

A

User requirementsDichiarazioni in un linguaggio naturale, più diagrammi (schemi) dei servizi forniti e i loro limiti operativi. Scritto per i clienti.System requirementsUn testo strutturato contenente una descrizione dettagliata delle funzioni di sistema, dei servizi e dei limiti operativi. Definisce cosa dovrebbe essere implementato e quindi fare parte del contratto tra cliente e azienda

114
Q

Cos’è un System stakeholders e che tipi di stakeholders esistono?

A

Any person or organization who is affected by the system in some way and so who has a legitimate interestStakeholder types:End usersSystem managersSystem ownersExternal stakeholders

115
Q

Cosa sono i Functional requirements?

A

Describe functionality or system services.Depend on the type of software, expected users and the type of system where the software is used.Functional user requirements may be high-level statements of what the system should do.Functional system requirements should describe the system services in detail.ExamplesA user shall be able to search the appointments lists for all clinics.The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number.

116
Q

Cosa sono i non-Functional requirements?

A

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.Process requirements may also be specified mandating a particular IDE, programming language or development method.Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

117
Q

Quali sono le 3 macro categorie di non-Functional requirements?

A

Product requirementsRequirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.Organisational requirementsRequirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.External requirementsRequirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.ExamplesProduct requirementThe Mentcare system shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.Organizational requirementUsers of the Mentcare system shall authenticate themselves using their health authority identity card.External requirementThe system shall implement patient privacy provisions as set out in HStan-03-2006-priv.

118
Q

Cosa sono i Requirements engineering processes?

A

The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.However, there are a number of generic activities common to all processesRequirements elicitation;Requirements analysis;Requirements validation;Requirements management.In practice, RE is an iterative activity in which these processes are interleaved.

119
Q

Cos’è la Requirements elicitation?

A

Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.

120
Q

In quali fasi si divide la Requirements elicitation?

A

Requirements discoveryInteracting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.Requirements classification and organisationGroups related requirements and organises them into coherent clusters.Prioritisation and negotiationPrioritising requirements and resolving requirements conflicts.Requirements specificationRequirements are documented and input into the next round of the spiral.

121
Q

Cos’è la Requirements specification?

A

The process of writing donw the user and system requirements in a requirements document.User requirements have to be understandable by end-users and customers who do not have a technical background.System requirements are more detailed requirements and may include more technical information.The requirements may be part of a contract for the system developmentIt is therefore important that these are as complete as possible.

122
Q

Quali sono i modi in cui si può scrivere un system requirements specification ?

A

Natural language - The requirements are written using numbered sentences in natural language. Each sentence should express one requirementStructured natural language - The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.Design description languages - This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.Graphical notations - Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.Mathematical specifications - These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

123
Q

Cosa sono gli Use cases?

A

Use-cases are a kind of scenario that are included in the UML. Use cases identify the actors in an interaction and which describe the interaction itself.A set of use cases should describe all possible interactions with the system.High-level graphical model supplemented by more detailed tabular description (see Chapter 5).UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

124
Q

Qual è la struttura di un requirements document ?

A

Preface - this should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction - This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the softwareGlossary - This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.User requirements definition - Here, you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified.System architecture - This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.System requirements specification - This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined.System models - This might include graphical system models showing the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution - This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.Appendices - These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions. Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index - Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.

125
Q

Cos’è il Requirements validation?

A

Concerned with demonstrating that the requirements define the system that the customer really wants.Requirements error costs are high so validation is very importantFixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

126
Q

Cosa controlla il Requirements checking?

A

Validity. Does the system provide the functions which best support the customer’s needs?Consistency. Are there any requirements conflicts?Completeness. Are all functions required by the customer included?Realism. Can the requirements be implemented given available budget and technologyVerifiability. Can the requirements be checked?

127
Q

Quali sono le Requirements validation techniques?

A

Requirements reviewsSystematic manual analysis of the requirements.PrototypingUsing an executable model of the system to check requirements. Covered in Chapter 2.Test-case generationDeveloping tests for requirements to check testability.

128
Q

Cos’è il Requirements management?

A

Requirements management is the process of managing changing requirements during the requirements engineering process and system development.New requirements emerge as a system is being developed and after it has gone into use.You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.

129
Q

Quali sono le Requirements management decisions?

A

Requirements management decisions:Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced with other requirements. A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section.Traceability policies These policies define the relationships between each requirement and between the requirements and the system design that should be recorded. Tool support Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.

130
Q

Cos’è il Requirements change management?

A

Deciding if a requirements change should be acceptedProblem analysis and change specification During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request.Change analysis and costing The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change.Change implementation The requirements document and, where necessary, the system design and implementation, are modified. Ideally, the document should be organized so that changes can be easily implemented