Why engineer requirements?
Now that we have a better idea of what RE is about,we could ask ourselves whether it is worth the effort. This section discusses why and to what extent the engineering of high-quality requirements is an essential precondition for the success of a software project. We firts review some citations and facts that provide anecdotal evidence about the importance of RE and the consequences of poor RE. Then we discuss the role and critical impact of RE in the software lifecycle from a more general perspective.
Facts, data and citations about the requirements problem
The phrase "requirements problem" refers to software project failures that have been attributed to poor or non-existent requirements.
An old problem
The requirements problem is among the oldest in software engineering. An early empirical study of a variety of software projects revealed that incomplete, inadequate, inconsistent or ambiguous requirements are numerous and have a critical impact on the quality of the resulting software (Bell & Thayer, 1976). These authors concluded that "the requirement for a system do not arise naturally; instead, they need to be engineered and have continuing review and revision". This was probably the firts reference to the phrase "requirements engineering", suggesting the need for systematic, repeatable procedures for building high-quality artefacts.
A consensus has been rapidly growing that such engineering is difficult. As Brooks noted in his landmark paper on the essence and accidents of software engineering, "the hardest single part of building a software system is deciding precisely what to build... Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements" (Brooks, 1987)
Requirements errors are the most expensive software errors
Lots of time and money can be saved if requirements errors and flaws are detected and fixed at the RE stage rather that later. Boehm and Papaccio reported that it cost 5 times more to detect and fix requirements defects during design, 10 times more during implementation, 20 times more during unit testing and up testing and up to 200 times more after system delivery (Boehm & Papaccio, 1988)
The role and stakes of requirements engineering
The bottom line of the previous section is that engineering high-quality requirements is essential, as errors in requirements, assumptions and domain properties tend to be numerous, persistent, costly and dangerous. To support that conclusion, we may also observe the prominent role that RE plays with respect to multiple stakes.
Technical stakes, the requirements document provides a basic for:
- Deriving acceptance test data
- Designing the software architecture and specifying its components/connectors
- Defining quality-assurance checklist
- Writing the documentation and user manuals
- Handling requests for software evolution
Communication stakes: The RD provides the main reference through which the various parties involved in a software project can communicate with each other.
Project management stakes: The RD provides a basic for determining the project costs, requires resources, development steps, milestones, review points and delivey schedules.
Legal stakes: The RD forms the core of the contract linking the software provider, customers and subcontractors (if any)
Certification stakes: Quality norms are increasingly enforces by law or regulations on project in specific domains such as medical, transportation, aerospace or nuclear. They may also be requested by specific customers in other domains. Such norms constrain the development process and products. At the process level, naturity models such as CMMI, SPICE or ISO9001 require RE to be taken seriously. For example, CMMI Maturity Level 2 imposes a requirements a repeatable requirements development process (Ahern et al., 2003)
Economic stakes: The consequences of numerous, persistent and dangerous errors related to requirements can be economically devastating.
Social stakes: When not sufficiently user centred, the RE process may overlook important needs and constraints. This may cause severe deteriorations in working conditions, and a wide range of reactions from partial or diverted use of the software to mere rejection of it.
Such reactions may have severe consequences beyond user diddatisfaction. For example, in the London ambulance system mentioned in the previous section, misuse and rejection of the new system by ambulance drivers were reported to be among the main causes of failure.
 |
| http://www-01.ibm.com/software/data/bigdata/ |
Es un término que hace referencia a una cantidad de datos tal que supera la capacidad del software habitual para ser capturados, gestionados y procesados en un tiempo razonable. El volumen de los datos masivos crece constantemente. En 2012 se estimaba su tamaño de entre una docena de terabytes hasta varios petabytes de datos en un único conjunto de datos.
Ellos tratan con algunos de los tres tipos de Big Data:
Datos estructurados (Structured Data): Datos que tienen bien definidos su longitud y su formato, como las fechas, los números o las cadenas de caracteres. Se almacenan en tablas. Un ejemplo son las bases de datos relacionales y las hojas de cálculo.
Datos no estructurados (Unstructured Data): Datos en el formato tal y como fueron recolectados, carecen de un formato específico. No se pueden almacenar dentro de una tabla ya que no se puede desgranar su información a tipos básicos de datos. Algunos ejemplos son los PDF, documentos multimedia, e-mails o documentos de texto.
Datos semiestructurados (Semistructured Data): Datos que no se limitan a campos determinados, pero que contiene marcadores para separar los diferentes elementos. Es una información poco regular como para ser gestionada de una forma estándar. Estos datos poseen sus propios metadatos semiestructurados que describen los objetos y las relaciones entre ellos, y pueden acabar siendo aceptados por convención. Un ejemplo es el HTML, el XML o el JSON.
0 comentarios:
Publicar un comentario