Main Flashcards

Question

Principle of agile methods: Customer involvement

Answer 1

Customers should be closely involved throughout the development process. Their role is to provide and prioritize new system requirements and to evaluate the iterations of the system.

Answer 2

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.

Answer 3

Expect the system requirements to change and so design the system to accommodate these changes.

Answer 4

Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

Answer 5

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 ‘Tasks’.

Answer 6

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.

Answer 7

Enough design is carried out to meet the current requirements and no more

Answer 8

An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented.

Answer 9

Developers work in pairs, checking each other's work and providing the support to always do a good job. * They sit together at the same computer * Pairs are created dynamically so that all team members work with each other * The knowledge sharing is very important, it removes the risks when a team member leaves.

Answer 10

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.

Answer 11

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.

Answer 12

Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity

Answer 13

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.

Answer 14

* Incremental planning * Small releases * Simple design * Test-first development * Refactoring * Pair programming * Collective ownership * Continuous integration * Sustainable pace * On-site customer

Answer 15

* The chicken is involved but the pig is commited * On agile projects: * Pig = Developers * Chicken = Everyone else who contribute but do not commit to any work.

Answer 16

* Complete task list * Priority by product owner * Declar value for all tasks * Pitfalls: * Imprecise tasks * Superficial value-setting

Answer 17

* Agreed sprint length * Choose from the top (most valued by the product owner) * Effort decided solely by the developers * Pitfalls: * Superficial estimation * Superficial decomposition * Interference from chickens * Working on self-defined tasks * Unclear visualisation of progress * Unclear definitions of tasks' states

Answer 18

* Natural language * Structured natural language * Design description languages * Graphical notations * Mathematical specifications

Answer 19

The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

Answer 20

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

* Requirements reviews * Systematic manual analysis of the requirements * Prototyping * Using an executable model of the system check requirements * Test-case generation * Developing tests for requiremetns to check testability

Answer 25

* 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 * Traceability policies * These policies define the relationship between each requirement and between the requirements and the system design that should be recorded * Tool support * Tools that may be used range from specalist requirements management systems to spreadsheets and simple database systems

Answer 26

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

Answer 27

* 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. "*Real-time systems are often event-driven, with minimal data processing. F.x. a landline phone switching system responds to events such as 'reciever off hook' by generating a dial tone"*

Answer 28

1. A computation independent model (CIM) 1. These model the important domain abstractions used in a system. CIMs are sometimes called domain models. **TODO Bedre forklaring** 2. A platform independent model (PIM) 1. 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. 3. Platform specific models (PSM) 1. 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.

Answer 29

Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system. * It 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.

Answer 30

Four layers: 1. User interface 2. User interface management, Authentication and authorization 3. Core business logic/application functionality, Systems utilities 4. Systems support (OS, database etc.)

Answer 31

An executable software system is developed.

Answer 32

Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements.

Answer 33

Implementation is the process of realizing the design as a program.

Answer 34

* A design pattern is a way of reusing abstract knowledge about a problem and its solution. * A pattern is a description of the problem and the essence of its solution. * It should be sufficiently abstract to be reused in different settings. * Pattern descriptions usually make use of object-oriented characteristics such as inheritance and polymorphism.

Answer 35

* Name * A meaningful pattern identifier. * Problem description. * Solution description. * Not a concrete design but a template for a design solution that can be instantiated in different ways. * Consequences * The results and trade-offs of applying the pattern.

Answer 36

* Name * Observer. * Description * Separates the display of object state from the object itself. * Problem description * Used when multiple displays of state are needed. * Solution description * See slide with UML description. * Consequences * Optimisations to enhance display performance are impractical.

Answer 37

* The abstraction level * At this level, you don’t reuse software directly but use knowledge of successful abstractions in the design of your software. * The object level * At this level, you directly reuse objects from a library rather than writing the code yourself. * The component level * Components are collections of objects and object classes that you reuse in application systems. * The system level * At this level, you reuse entire application systems.

Answer 38

* Most software is developed on one computer (the host), but runs on a separate machine (the target). * More generally, we can talk about a development platform and an execution platform. * A platform is more than just hardware. * It includes the installed operating system plus other supporting software such as a database management system or, for development platforms, an interactive development environment. * Development platform usually has different installed software than execution platform;; these platforms may have different architectures.

Answer 39

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

Answer 40

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

Answer 41

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

Answer 42

1. Start by identifying the increment of functionality that is required. This should normally be small and implementable in a few lines of code. 2. Write a test for this functionality and implement this as an automated test. 3. 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. 4. Implement the functionality and re-run the test. 5. Once all tests run successfully, you move on to implementing the next chunk of functionality.

Answer 43

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

Answer 44

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

Answer 45

* Alpha testing * Users of the software work with the development team to test the software at the developer’s site. * Beta testing * A 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 testing * Customers 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.

Answer 46

* Refactoring is the process of making improvements to a program to slow down degradation through change. * You can think of refactoring as ‘preventative maintenance’ that reduces the problems of future change. * Refactoring involves modifying a program to improve its structure, reduce its complexity or make it easier to understand. * When you refactor a program, you should not add functionality but rather concentrate on program improvement.

Answer 47

Reengineering takes place after a system has been maintained for some time and maintenance costs are increasing. You use automated tools to process and reengineer a legacy system to create a new system that is more maintainable.

Answer 48

* Duplicate code * The same or very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required. * Long methods * If a method is too long, it should be redesigned as a number of shorter methods. * Switch (case) statements * These often involve duplication, where the switch depends on the type of a value. The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing. * Data clumping * Data clumps occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program. These can often be replaced with an object that encapsulates all of the data. * Speculative generality * This occurs when developers include generality in a program in case it is required in the future. This can often simply be removed.

Answer 49

The project plan, which is created at the start of a project, is used to communicate how the work will be done to the project team and customers, and to help assess progress on the project.

Answer 50

* At this stage, you know more about the system requirements but do not have design or implementation information * Create a plan with enough detail to make decisions about the project budget and staffing. * This plan is the basis for project resource allocation * The startup plan should also define project monitoring mechanisms * A startup plan is still needed for agile development to allow resources to be allocated to the project

Answer 51

* A project plan is created that records the work to be done, who will do it, the development schedule and the work products. * Managers use the plan to support project decision making and as a way of measuring progress.

Answer 52

* The planning game is based on user stories that reflect the features that should be included in the system. * The project team read and discuss the stories and rank them in order of the amount of time they think it will take to implement the story. * Stories are assigned ‘effort points’ reflecting their size and difficulty of implementation * The number of effort points implemented per day is measured giving an estimate of the team’s ‘velocity’ * This allows the total effort required to implement the system to be estimated

Answer 53

The estimate of future effort requirements is based on the manager’s experience of past projects and the application domain. Essentially, the manager makes an informed judgment of what the effort requirements are likely to be.

Answer 54

In this approach, a formulaic approach is used to compute the project effort based on estimates of product attributes, such as size, and process characteristics, such as experience of staff involved. * Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: * Effort = A x SizeB x M * A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes. * The most commonly used product attribute for cost estimation is code size. * Most models are similar but they use different values for A, B and M.

Answer 55

* An empirical model based on project experience. * Well-documented, ‘independent’ model which is not tied to a specific software vendor. * Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. * COCOMO 2 takes into account different approaches to software development, reuse, etc.

Answer 56

* Supports prototyping projects and projects where there is extensive reuse. * Based on standard estimates of developer productivity in application (object) points/month. * Takes software tool use into account. * Formula is * PM = ( NAP ´ (1 - %reuse/100 ) ) / PROD * PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

Answer 57

* Estimates can be made after the requirements have been agreed. * Based on a standard formula for algorithmic models * PM = A x SizeB x M where * M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED;; * A = 2.94 in initial calibration, * Size in KLOC, * B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity.

Answer 58

Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc.

Answer 59

It addresses the identified risks

Answer 60

* Uncertainty * Loss * Project risks * Technical risks * Business risks * Known risks, predictable risks, and unpredictable risks

Answer 61

* Risk identification * Risk analysis * Risk prioritisation * Risk mitigation * Risk monitoring * Risk management

Answer 62

* Systematically identify known and predictable risks to the software project * Generic risks potentially threaten all software projects * Product-‐specific risks are specific to the technology, the people, the project’s context * Risk frameworks are useful

Answer 63

1. Commitment from top managers (software and customer) 2. Commitment from end‐users 3. Requirements fully understood 4. Involvement of customers 5. Realistic end‐user expectations 6. ... "*Ranked based on a large study with many respondents across many companies*"

Answer 64

* Product size (PS) * Business impact (BI) * Customer characteristics (CCh) * Customer communication (CCo) * Tools (To) * Technologies (Te) * Staff size and experience (SSE)

Answer 65

* Performance risks (PR): * the degree to which the product will satisfy requirements and that the requirements are right * Cost risk (CR): * the degree to which the project budget will be met * Support risk (SuR): * the degree to which the software will be easy to modify, adapt, and enhance * Schedule risk (SeR): * the degree to which the project schedule will be met

Answer 66

* For all risks: * Establish category and likelihood * Estimate impact (catastrophic, critical, marginal, negligible) * Describe consequences

Answer 67

Quality is a reflection of one or more peoples’ assessment of correspondance between their expectations and experience of a product or a service.

Answer 68

* Large projects: Cheaper in the beginning than small projeckt but very costly later on. * Small projects: Still cheap in the beginning, not that much more expensive later on. * Indirect costs of error correction: * The remaining work depends on poor quality work done previously. * Preventive costs * Better planning, education of devs * Monitoring costs * Evaluation, peer review, code inspection * Testing

Answer 69

At the organizational level, quality management is concerned with establishing a framework of organizational processes and standards that will lead to high-quality software.

Answer 70

* At the project level, quality management involves the application of specific quality processes and checking that these planned processes have been followed. * At the project level, quality management is also concerned with establishing a quality plan for a project. The quality plan should set out the quality goals for the project and define what processes and standards are to be used.

Answer 71

* Is done by a team that is separate from the devs * Checks that the project maintains the organizational standards and goals

Answer 72

* Large project: * The quality document is important since it ensures continuity of development as the team changes over time. * Small project: * Needs less documentation * Should focus on establishing a **quality culture**

Answer 73

* ISO 9001, the most general of the quality management standards, applies to organizations that design, develop and maintain products, including software. * It sets out general quality principles, describes quality processes in general and lays out the organizational standards and procedures that should be defined. * These should be documented in an organizational quality manual.

Answer 74

**ER DER BÅDE 9000 OG 9001 ELLER ER DET EN STAVEFEJL?** * Some customers require suppliers to be ISO 9000 certified although the need for flexibility here is increasingly recognised. * Quality standards and procedures should be documented in an organisational quality manual. * An external body may certify that an organisation’s quality manual conforms to ISO 9000 standards. * The ISO 9001 certification is inadequate because it defines quality to be the conformance to standards. * It takes no account of quality as experienced by users of the software. For example, a company could define test coverage standards specifying that all methods in objects must be called at least once. * Unfortunately, this standard can be met by incomplete software testing that does not include tests with different method parameters. So long as the defined testing procedures are followed and test records maintained, the company could be ISO 9001 certified.

Answer 75

* A group examines part or all of a process or system and its documentation to find potential problems. * Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. * There are different types of review with different objectives * Inspections for defect removal (product);; * Reviews for progress assessment (product and process);; * Quality reviews (product and standards).

Answer 76

* A group of people carefully examine part or all of a software system and its associated documentation. * Code, designs, specifications, test plans, standards, etc. can all be reviewed. * Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management.

Answer 77

* Pre-review activities * Pre-review activities are concerned with review planning and review preparation * The review meeting * During the review meeting, an author of the document or program being reviewed should ‘walk through’ the document with the review team. * Post-review activities * These address the problems and issues that have been raised during the review meeting.

Answer 78

* Many projects are done by distributed teams * Remote reviewing can be done with shared documents supporting annotations and comments.

Answer 79

* Checklist of common errors should be used to drive the inspection. * Error checklists are programming language dependent and reflect the characteristic errors that are likely to arise in the language. * In general, the 'weaker' the type checking, the larger the checklist. * Examples: Initialisation, Constant naming, loop termination, array bounds, etc.

Answer 80

* Data faults: * Are all program variables initialized before their values are used? * Have all constants been named? * Should the upper bound of arrays be equal to the size of the array or Size -1? * If character strings are used, is a delimiter explicitly assigned? * Is there any possibility of buffer overflow? * Control faults: * For each conditional statement, is the condition correct? * Is each loop certain to terminate? * Are compound statements correctly bracketed? * In case statements, are all possible cases accounted for? * If a break is required after each case in case statements, has it been included? * Input/output faults: * Are all input variables used? * Are all output variables assigned a value before they are output? * Can unexpected inputs cause corruption?

Answer 81

* Quality management in agile development is informal rather than document-based. * It relies on establishing a quality culture. * The agile community is fundamentally opposed to what it sees as the bureaucratic overheads of standards-based approaches and quality processes as embodied in ISO 9001.

Answer 82

* Check before check-in * Programmers are responsible for organizing their own code reviews with other team members before the code is checked in to the build system. * Never break the build * Team members should not check in code that causes the system to fail. Developers have to test their code changes against the whole system and be confident that these work as expected. * Fix problems when you see them * If a programmer discovers problems or obscurities in code developed by someone else, they can fix these directly rather than referring them back to the original developer.

Answer 83

* The review process in agile software development is usually informal. * In Scrum, there is a review meeting after each iteration of the software has been completed (a sprint review), where quality issues and problems may be discussed. * In Extreme Programming, pair programming ensures that code is constantly being examined and reviewed by another team member.

Answer 84

It's GIT and SVN (Version control) * Software systems are constantly changing during development and use. * Configuration management (CM) is concerned with the policies, processes and tools for managing changing software systems. * You need CM because it is easy to lose track of what changes and component versions have been incorporated into each system version. * CM is essential for team projects to control changes made by different developers

Answer 85

Components and systems are changing several times per day in agile development, so it is impossible without CM tools.

Answer 86

A specific version of the system ## Footnote *A baseline is a collection of component versions that make up a system. Baselines are controlled, which means that the versions of the components making up the system cannot be changed. This means that it is always possible to recreate a baseline from its constituent components.*

Answer 87

The creation of a new codeline from a version in an existing codeline. The new codeline and the existing codeline may then develop independently.

Answer 88

A codeline is a set of versions of a software component and other configuration items on which that component depends.

Answer 89

The process of ensuring that versions of systems and components are recorded and maintained so that changes are managed and all versions of components are identified and stored for the lifetime of the system.

Answer 90

Anything associated with a software project (design, code, test data, document, etc.) that has been placed under configuration control. There are often different versions of a configuration item. Configuration items have a unique name.

Answer 91

A sequence of baselines representing different versions of a system.

Answer 92

The creation of a new version of a software component by merging separate versions in different codelines. These codelines may have been created by a previous branch of one of the codelines involved.

Answer 93

A version of a system that has been released to customers (or other users in an organization) for use. * Major releases * Deliver significant new functionality * Minor releases * Repair bugs and fix customer problems

Answer 94

A shared database of versions of software components and meta-information about changes to these components.

Answer 95

The creation of an executable system version by compiling and linking the appropriate versions of the components and libraries making up the system.

Answer 96

An instance of a configuration item that differs, in some way, from other instances of that item. Versions always have a unique identifier.

Answer 97

A private work area where software can be modified without affecting other developers who may be using or modifying that software.

Answer 98

There are two types of version control systems: * Centralized systems, where there is a single master repository that maintains all versions of the software components that are being developed. Subversion is a widely used example of a centralized VC system. * Distributed systems, where multiple versions of the component repository exist at the same time. Git is a widely-used example of a distributed VC system.

Answer 99

* Backup * Restore from local version * Offline development * Developers can compile and test the entire system on their local machines and test the changes that they have made. *Essential in open source development!*

Answer 100

* The development organization sets a delivery time (say 2 p.m.) for system components. * If developers have new versions of the components that they are writing, they must deliver them by that time. * A new version of the system is built from these components by compiling and linking them to form a complete system. * This system is then delivered to the testing team, which carries out a set of predefined system tests * Faults that are discovered during system testing are documented and returned to the system developers. They repair these faults in a subsequent version of the component.

Answer 101

* Formal document naming schemes and management in a database * The configuration database should record information about changes and change requests * A consistent scheme of version identification should be established using version numbers, attributes or change sets * System releases include executable code, data, configuration files and documentation * System building involves assembling components into a system * Tools are available to support all CM activities * Tools may be stand‐alone or may be integrated systems which integrate support for version management, system building and change management

Answer 102

* Build automation * Automated migration and deployment * Test automation * Continuous integration * Corporate CM organization

Answer 103

* Hardware failure * Hardware fails because of design and manufacturing errors or because components have reached the end of their natural life. * Software failure * Software fails due to errors in its specification, design or implementation. * Operational failure * Human operators make mistakes. Now perhaps the largest single cause of system failures in socio-technical systems.

Answer 104

The probability that the system will be up and running and able to deliver useful services to users.

Answer 105

The probability that the system will correctly deliver services as expected by users.

Answer 106

A judgment of how likely it is that the system will cause damage to people or its environment.

Answer 107

A judgment of how likely it is that the system can resist accidental or deliberate intrusions.

Answer 108

A judgment of how well a system can maintain the continuity of its critical services in the presence of disruptive events such as equipment failure and cyber attacks.

Answer 109

* Availability * Reliability * Safety * Security * Resilience

Answer 110

* There are interactions and dependencies between the layers in a system and changes at one level ripple through the other levels * Example: Change in regulations (society) leads to changes in business processes and application software. * For dependability, a systems perspective is essential * Contain software failures within the enclosing layers of the STS stack. * Understand how faults and failures in adjacent layers may affect the software in a system.

Answer 111

Keep more than a single version of critical components so that if one fails then a backup is available. * Redundant and diverse components should be independent so that they will not suffer from ‘common-mode’ failures * For example, components implemented in different programming languages means that a compiler fault will not affect all of them.

Answer 112

Provide the same functionality in different ways in different components so that they will not fail in the same way. * Redundant and diverse components should be independent so that they will not suffer from ‘common-mode’ failures * For example, components implemented in different programming languages means that a compiler fault will not affect all of them.

Answer 113

A process that has a defined process model that is used to drive the software production process. Data must be collected during the process that proves that the development team has followed the process as defined in the process model.

Answer 114

A process that does not rely on individual interpretation and judgment. The process can be repeated across projects and with different team members, irrespective of who is involved in the development.

Answer 115

The system is developed in such a way that human error is avoided and thus system faults are minimised. The development process is organised so that faults in the system are detected and repaired before delivery to the customer.

Answer 116

Verification and validation techniques are used to discover and remove faults in a system before it is deployed.

Answer 117

The system is designed so that faults in the delivered software do not result in system failure.

Answer 118

* Functional reliability requirements define system and software functions that avoid, detect or tolerate faults in the software and so ensure that these faults do not lead to system failure. * Software reliability requirements may also be included to cope with hardware failure or operator error. * Reliability is a measurable system attribute so non-functional reliability requirements may be specified quantitatively. These define the number of failures that are acceptable during normal use of the system or the time in which the system must be available.

Answer 119

Safety is a property of a system that reflects the system’s ability to operate, normally or abnormally, without danger of causing human injury or death and without damage to the system’s environment. It is important to consider software safety as most devices whose failure is critical now incorporate softwarebased control systems.

Answer 120

1. The system may be software-controlled so that the decisions made by the software and subsequent actions are safety-critical. Therefore, the software behaviour is directly related to the overall safety of the system. 2. Software is extensively used for checking and monitoring other safety-critical components in a system. This software is safety-critical because, if it fails, other components may fail and cause an accident. * For example, all aircraft engine components are monitored by software looking for early indications of component failure.

Answer 121

* Safety engineering processes are based on reliability engineering processes * Planbased approach with reviews and checks at each stage in the process * General goal of fault avoidance and fault detection * Must also include safety reviews and explicit identification and tracking of hazards

Answer 122

* Regulators may require evidence that safety engineering processes have been used in system development * For example: * The specification of the system that has been developed and records of the checks made on that specification. * Evidence of the verification and validation processes that have been carried out and the results of the system verification and validation. * Evidence that the organizations developing the system have defined and dependable software processes that include safetyassurance reviews. There must also be records that show that these processes have been properly enacted.

Answer 123

* Agile methods are not usually used for safety-critical systems engineering * Extensive process and product documentation is needed for system regulation. Contradicts the focus in agile methods on the software itself. * A detailed safety analysis of a complete system specification is important. Contradicts the interleaved development of a system specification and program. * Some agile techniques such as test-driven development may be used

Answer 124

* Formal methods can be used when a mathematical specification of the system is produced. * They are the ultimate static verification technique that may be used at different stages in the development process: * A formal specification may be developed and mathematically analyzed for consistency. This helps discover specification errors and omissions. * Formal arguments that a program conforms to its mathematical specification may be developed. This is effective in discovering programming and design errors.

Answer 125

* Involves creating an extended finite state model of a system and, using a model checker, checking that model for errors. * The model checker explores all possible paths through the model and checks that a user-specified property is valid for each path. * Model checking is particularly valuable for verifying concurrent systems, which are hard to test. * Although model checking is computationally very expensive, it is now practical to use it in the verification of small to medium sized critical systems.

Answer 126

* Require specialized notations that cannot be understood by domain experts. * Very expensive to develop a specification and even more expensive to show that a program meets that specification. * Proofs may contain errors. * It may be possible to reach the same level of confidence in a program more cheaply using other V & V techniques.

Answer 127

* A safety case is: * A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment. * Arguments in a safety case can be based on formal proof, design rationale, safety proofs, etc. Process factors may also be included. * A software safety case is usually part of a wider system safety case that takes hardware and operational issues into account.

Answer 128

* System reuse * Complete systems, which may include several application programs may be reused. * Application reuse * An application may be reused either by incorporating it without change into other or by developing application families. * Component reuse * Components of an application from sub-systems to single objects may be reused. * Object and function reuse * Small-scale software components that implement a single well-defined object or function may be reused.

Answer 129

An application type is generalized around a common architecture so that it can be adapted for different customers. * Application frameworks rely on object-oriented features such as polymorphism to implement extensions. **Product lines** need not be object-oriented (e.g. embedded software for a mobile phone) * Application frameworks focus on providing technical rather than domain-specific support. **Product lines** embed domain and platform information. * **Product lines** often control applications for equipment. * Software **product lines** are made up of a family of applications, usually owned by the same organization.

Answer 130

**This was under the explanation of product lines:** * Application frameworks rely on object-oriented features such as polymorphism to implement extensions. Product lines need not be object-oriented (e.g. embedded software for a mobile phone) * Application frameworks focus on providing technical rather than domain-specific support. Product lines embed domain and platform information. * Product lines often control applications for equipment. * Software product lines are made up of a family of applications, usually owned by the same organization

Answer 131

* Design time configuration * The organization that is developing the software modifies a common product line core by developing, selecting or adapting components to create a new system for a customer. * Deployment time configuration * A generic system is designed for configuration by a customer or consultants working with the customer. Knowledge of the customer’s specific requirements and the system’s operating environment is embedded in configuration data that are used by the generic system.

Answer 132

Large-scale systems that encapsulate generic business functionality and rules are configured for an organization. * A number of modules to support different business functions. * A defined set of business processes, associated with each module, which relate to activities in that module. * A common database that maintains information about all related business functions. * A set of business rules that apply to all data in the database.

Answer 133

* Selecting the required functionality from the system. * Establishing a data model that defines how the organization’s data will be structured in the system database. * Defining business rules that apply to that data. * Defining the expected interactions with external systems. * Designing the input forms and the output reports generated by the system. * Designing new business processes that conform to the underlying process model supported by the system. * Setting parameters that define how the system is deployed on its underlying platform.

Answer 134

It is a development process that is geared towards reuse * Independent components specified by their interfaces. * Component standards to facilitate component integration. * Middleware that provides support for component inter-operability.

Answer 135

* The component is an independent, executable entity. It does not have to be compiled before it is used with other components. * The services offered by a component are made available through an interface and all component interactions take place through that interface. * The component interface is expressed in terms of parameterized operations and its internal state is never exposed.

Answer 136

* CBSE for reuse focuses on component development. * Components developed for a specific application usually have to be generalised to make them reusable. * A component is most likely to be reusable if it associated with a stable domain abstraction (business object). * For example, in a hospital stable domain abstractions are associated with the fundamental purpose - nurses, patients, treatments, etc.

Answer 137

* Should reflect stable domain abstractions * Should hide state representation * Should be as independent as possible * Should publish exceptions through the component interface ## Footnote There is a trade-off between reusability and usability: * The more general the interface, the greater the reusability but it is then more complex and hence less usable.

Answer 138

* Large-scale systems that do not just include software and hardware but also people, processes and organizational policies. * Sociotechnical systems are often ‘systems of systems’ i.e. are made up of a number of independent systems.

Answer 139

* Technical computer-based systems * Include hardware and software but not humans or organizational processes. * Off the shelf applications, control systems, etc. * Sociotechnical systems * Include technical systems plus people who use and manage these systems and the organizations that own the systems and set policies for their use. * Business systems, command and control systems, etc.

Answer 140

* Emergent properties * Properties of the system of a whole that depend on the system components and their relationships. * Non-deterministic * They do not always produce the same output when presented with the same input because the systems’s behaviour is partially dependent on human operators. * Complex relationships with organisational objectives * The extent to which the system supports organisational objectives does not just depend on the system itself.

Answer 141

* Different stakeholders have their own views about whether or not a system is ‘successful’ * Success is a judgment and cannot be objectively measured. * Success is judged using the effectiveness of the system when deployed rather than judged against the original reasons for procurement.

Answer 142

Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. *In practice, most practical processes include elements of both plan-driven and agile approaches.*

Answer 143

In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. *In practice, most practical processes include elements of both plan-driven and agile approaches.*

Answer 144

* Everyone responsible for software development is committed to creating products of high quality. * Teams are encuraged to take responsibility for the quality of their work and to develop new approaches to quality improvement.

Answer 145

MDA metoden anbefaler at man laver tre forskellige typer af abstrakte system modeller: * Computational independent model * Modellere de vigtige domæne abstraktioner i systemet. * Fx. en patient log CIM hvor man beskriver patienter, konsultanter osv. * Platform independent model * Modellere operativ systemet uden reference til dets implementation * Ofte ved brug af UML der viser en statisk struktur af systemet. * Platform specific model * Transformation af PIM. * En PSM pr platform

Answer 146

* Technology risks * Risici der stammer fra det software eller hardware der bliver brugt til at udvikle systemet * People risks * Risici der er associeret med personerne i udviklingsholdet. * Organizational risks * Risici der stammer fra organisations miljøet hvor softwaren bliver udviklet. * Tools risks * Risici der stammer fra de software redskaber der bruges til at udvikle systemet. * Requirements risks * Risici der stammer fra ændringer af kundekrav og processen af håndtere disse ændringer. * Estimation risks * Risici der stammer fra estimeringen af forventede ressourcer krævet for at bygge systemet.

Main Flashcards

(171 cards)