| 1. Identity statement | ||||
| Reference Type | Conference Paper (Conference Proceedings) | |||
| Site | mtc-m16b.sid.inpe.br | |||
| Holder Code | isadg {BR SPINPE} ibi 8JMKD3MGPCW/3DT298S | |||
| Repository | dpi.inpe.br/ce@80/2007/01.12.14.26 (restricted access) | |||
| Last Update | 2007:04.09.20.24.56 (UTC) administrator | |||
| Metadata Repository | dpi.inpe.br/ce@80/2007/01.12.14.26.02 | |||
| Metadata Last Update | 2018:06.05.03.33.44 (UTC) administrator | |||
| Citation Key | Mendonca:2007:SyVeBr | |||
| Title | The System Verification Breakdown Method  | |||
| Format | Print; CD-ROM; On-line. | |||
| Year | 2007 | |||
| Access Date | 2024, Apr. 27 | |||
| Secondary Type | CI | |||
| Number of Files | 3 | |||
| Size | 2938 KiB | |||
| 2. Context | ||||
| Author | Mendonca, Cassio H. | |||
| Affiliation | Instituto Nacional de Pesquisas Espaciais - INPE | |||
| Author e-Mail Address | chmendonca1977@yahoo.com.br | |||
| Editor | Loureiro, Geilson Curran, Ricky | |||
| e-Mail Address | chmendonca1977@yahoo.com.br | |||
| Conference Name | ISPE International Conference on Concurrent Engineering, 14 (CE 2007). | |||
| Conference Location | São José dos Campos | |||
| Date | 2007, July 16-20 | |||
| Publisher | Instituto Nacional de Pesquisas Espaciais (INPE) | |||
| Publisher City | São José dos Campos | |||
| Pages | 63-70 | |||
| Book Title | Proceedings | |||
| Organization | Instituto Nacional de Pesquisas Espaciais (INPE) | |||
| History (UTC) | 2007-02-26 15:39:17 :: chmendonca1977@yahoo.com.br -> ce2007 :: 2007-03-29 12:42:21 :: ce2007 -> chmendonca1977@yahoo.com.br :: 2007-04-09 20:37:43 :: chmendonca1977@yahoo.com.br -> ce2007 :: 2007-04-12 21:44:30 :: ce2007 -> administrator :: 2007-05-18 15:20:41 :: administrator -> ce2007 :: 2007-05-21 14:36:12 :: ce2007 -> administrator :: 2018-06-05 03:33:44 :: administrator -> marciana :: 2007 | |||
| 3. Content and structure | ||||
| Is the master or a copy? | is the master | |||
| Content Stage | completed | |||
| Transferable | 1 | |||
| Keywords | verification method block diagram coverage tests requirements reuse test cases generation system sub-system interfaces | |||
| Abstract | High integrated and complex systems are more and more scattered and common in people lives. Even without the exact feeling of this means, they hope for the best product. This desire implicate in system manufactures improve knowledgement and create solutions with more advanced technologies to satisfy consumers expectations. No much time ago, world saw the emergence of cell phones. In that time this technology was expansive and it was not so good, for instance, the coverage of signal was not so spread, batteries had no longer charge duration, displays only show the phone numbers and they have a nickname of "brick" because the excessive weight and size. Compare that with actual cell phones. Anyone can go to shop and buy a small one with voice recorder, integrated camera, internet access, expansible memories, among other features. It is only one brief and single example to demonstrate how the integrated system comes up in our lives and it could be replaced by video games, automobiles, domestics equipments, personal cares, computers, medicine among others. Manufacturers of high integrated systems need ensure that products will not cause problems to health or lives during them normal and abnormal operation and, of course, they must execute the desired work. The process to ensure correct implementation and development called System Verification. Verification have been done at the end of process development, but it have resulted in difficulties to manufacturers because is very expansive and hard to implement any required modifications at the end of development process. Thus, many manufactures have started verification process at begin of development, decreasing erroneous implementations. The usual way to advance verification tests is create mathematical models and simulate them in computers to verify normal and abnormal behavior. This is very useful during system development, but there are any problems that should be considerate: Which tests cases should be performed in models? Does the model have enough feature and functionalities implemented? Are the tests results as expected? A good approach to answer these questions is creating test cases procedures to know if models satisfy required necessities. But, how do create tests procedures without know completely the system under tests? At begin of development process, engineers write system description and system requirements thus, tests procedures should be done against these documents. This paper is intended to show an intuitive method possible to apply in any cases, using block diagrams, that assists generate test cases procedures, since when development starts, making relationship among system interfaces, subsystems and functions, enabling tests traceability and tests coverage analysis. In cases where manufacturer develops same kind of products, the block diagram will be easily reused to a new one, including or removing systems, subsystems and functions, adapting it to new features and project requirements. | |||
| Area | ETES | |||
| Type | Systems Engineering | |||
| doc Directory Content | access | |||
| source Directory Content |
| |||
| agreement Directory Content | there are no files | |||
| 4. Conditions of access and use | ||||
| Language | en | |||
| Target File | paper.pdf | |||
| User Group | administrator chmendonca1977@yahoo.com.br administrator | |||
| Visibility | shown | |||
| Read Permission | deny from all and allow from 150.163 | |||
| 5. Allied materials | ||||
| Host Collection | lcp.inpe.br/ignes/2004/02.12.18.39 cptec.inpe.br/walmeida/2003/04.25.17.12 | |||
| 6. Notes | ||||
| Mark | 1 | |||
| Empty Fields | archivingpolicy archivist callnumber contenttype copyholder copyright creatorhistory descriptionlevel dissemination documentstage doi edition group identifier isbn issn label lineage mirrorrepository nextedition nexthigherunit notes numberofvolumes orcid parameterlist parentrepositories previousedition previouslowerunit progress project readergroup resumeid rightsholder schedulinginformation secondarydate secondarykey secondarymark serieseditor shorttitle sponsor tertiarymark tertiarytype url versiontype volume | |||
| 7. Description control | ||||
| e-Mail (login) | marciana | |||
| update | ||||