WO2011031328A2 - Systems and methods for management of projects for development of embedded systems - Google Patents

Systems and methods for management of projects for development of embedded systems Download PDF

Info

Publication number
WO2011031328A2
WO2011031328A2 PCT/US2010/002490 US2010002490W WO2011031328A2 WO 2011031328 A2 WO2011031328 A2 WO 2011031328A2 US 2010002490 W US2010002490 W US 2010002490W WO 2011031328 A2 WO2011031328 A2 WO 2011031328A2
Authority
WO
WIPO (PCT)
Prior art keywords
project
respective
view
objective
requirement
Prior art date
Application number
PCT/US2010/002490
Other languages
French (fr)
Other versions
WO2011031328A3 (en
Inventor
William Gryffyth Stclair
Sumner Augustine Stclair
Original Assignee
Ldra Technology, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US24216409P priority Critical
Priority to US61/242,164 priority
Priority to US30023610P priority
Priority to US61/300,236 priority
Application filed by Ldra Technology, Inc. filed Critical Ldra Technology, Inc.
Publication of WO2011031328A2 publication Critical patent/WO2011031328A2/en
Publication of WO2011031328A3 publication Critical patent/WO2011031328A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/20Software design
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments for testing or debugging software
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/10Requirements analysis; Specification techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management

Abstract

A process management method and system for developing an embedded system using a plurality of project views is disclosed. Each project view is assigned to a different entity. The method includes associating one or more objectives with a respective project view and linking one or more embedded system deliverables to the one or more objectives. The method further includes, for a respective objective: (1) linking at least one functional requirement to the respective objective, and (2) linking at least one test result to the respective objective to validate that the embedded system deliverables linked to the respective objective satisfy the at least one functional requirement. The method also includes presenting, in the respective project view, status information of the objectives assigned to a respective entity.

Description

SYSTEMS AND METHODS FOR MANAGEMENT OF PROJECTS FOR DEVELOPMENT OF EMBEDDED SYSTEMS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This Application claims priority from U.S. Provisional Application No. 61/300,236, filed on February 2, 2010, and from U.S. Provisional Application No. 61/242,164, filed on September 14, 2009. This Application is related to U.S.

Provisional Application No. 61/382,690, filed on September 14, 2010 and U.S. Non- Provisional Application No. 12/078,695, filed on April 3, 2008. The contents of U.S. Provisional Application No. 61/300,236, U.S. Provisional Application No. 61/242,164, U.S. Non-Provisional Application No. 12/078,695 and U.S. Provisional Application No. 61/382,690 are incorporated in their entirety by reference herein.

BACKGROUND OF THE INVENTION FIELD OF THE INVENTION

[0002] Exemplary embodiments of the present invention relate to management of embedded system developments and, more particularly, to systems and methods for managing the development of embedded systems which enable requirements traceability and software testing/verification.

RELATED ART

[0003] In many safety-critical and mission-critical industries, such as the avionics, medical, defense, and nuclear industries, among others, requirements traceability and verification tasks associated with software development projects can consume a significant portion of the project budget. Techniques exist for

automatically capturing requirements information for software development projects from various sources of requirements information into the form of a requirements traceability matrix (RTM), which can be used to trace the implementation of the requirements in source code. The RTM typically includes project-level, customer- defined requirements that specify how the software product should operate as well as low-level design constraints, but not code-level, verification requirements that specify how the software product should be verified. Further, techniques exist for manually testing source code written to implement the requirements and for verifying the requirements.

SUMMARY OF THE INVENTION

[0004] The present invention is embodied as a process management method and system for developing an embedded system using a plurality of project views. Each project view is assigned to a different entity. The method includes associating one or more objectives with a respective project view and linking one or more embedded system deliverables to the one or more objectives. The method further includes, for a respective objective: (1) linking at least one functional requirement to the respective objective, and (2) linking at least one test result to the respective objective to validate that the embedded system deliverables linked to the respective objective satisfy the at least one functional requirement. The method also includes presenting, in the respective project view, status information of the objectives assigned to a respective entity.

[0005] The present invention is also embodied as a process management method and system for developing program code that meets one or more functional requirements using a project view. The method includes associating the one or more functional requirements to a plurality of objectives. Each objective defines an assignment of work to one entity. The method further includes establishing one or more code tests which determine whether the program code meets a respective functional requirement of the one or more functional requirements and validating the program code based on the one or more code tests, as test results. The method also includes storing each respective functional requirement together with the associated objective, corresponding code tests and corresponding test results, as a respective unit and presenting information from one or more respective units as a portion of the project view.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Other objects and advantages of the invention will become apparent to those skilled in the relevant art(s) upon reading the following detailed description of preferred embodiments, in conjunction with the accompanying drawings, in which like reference numerals have been used to designate like elements, and in which: FIGS. 1A and IB illustrate an exemplary environment in which a system for automatically managing software requirements verification can be implemented and an exemplary embodiment of an automated requirements verification tool, respectively;

FIG. 2 illustrates a process flowchart providing exemplary steps for a method of automatically managing software requirements verification;

FIGS. 3A-3E illustrate an exemplary extensible markup language (XML) implementation of a system for automatically managing software requirements verification;

FIGS. 4A-4J illustrate screen captures of an exemplary graphical user interface of a system for automatically managing software requirements verification;

FIG. 5 illustrates an example of selecting, creating, renaming or deleting a group view;

FIG. 6 illustrates an example of editing rules for a given group;

FIG. 7 illustrates an example of parsing based on types;

FIG. 8 illustrates an example of requirements in an Microsoft (MS) Word file;

FIGS. 9 and 10 illustrate examples of a type editor;

FIG. 11 illustrates an example of ungrouped requirements and grouped requirements;

FIG. 12 illustrates an example of a sibling requirement;

FIG. 13 illustrates another example of a sibling requirement;

FIG. 14 is a schematic diagram that illustrates the relationship between logical elements of an embedded process model in accordance with exemplary embodiments of the present invention;

FIG. 15A and 15B illustrate a system for process management in accordance with exemplary embodiments of the present invention;

FIG. 15C illustrates an embedded process model in accordance with exemplary embodiments of the present invention;

FIG. 16 illustrates creation of views in the system of FIGS. 15A and 15B;

FIG. 17 illustrates creation of objectives in the system of FIGS. 15A and

15B; FIG. 18 illustrates an association of objectives to views in an exemplary system engineering view for the system of FIGS. 15A and 15B;

FIG. 19 illustrates creation of asset in the system of FIGS. 15A and 15B;

FIG. 20 illustrates an association of different types of assets to objectives in the system of FIGS. 15A and 15B;

FIG. 21 illustrates properties of an exemplary objective in the system of FIGS. 15A and 15B;

FIG. 22 illustrates team view elements in accordance with exemplary embodiments of the present invention;

FIG. 23 illustrates user rights and views in the system of FIG. 15 A and 15B;

FIG. 24 illustrates a system engineering view in accordance with exemplary embodiments of the present invention;

FIG. 25 illustrates a formal design view in accordance with exemplary embodiments of the present invention;

FIG. 26 illustrates an architecture view in accordance with exemplary embodiments of the present invention;

FIG. 27 illustrates an Integrated Development Environment (IDE) view in accordance with exemplary embodiments of the present invention;

FIG. 28 illustrates a test view in accordance with exemplary embodiments of the present invention;

FIG. 29 illustrates an association of project documents to objectives in the system of FIGS. 15A and 15B;

FIG. 30 illustrates a TBManager™ (TBM) communicating with a third party tool;

FIGS. 31 A and 3 IB illustrate requirements and their traceability within IRQA and subsequent to processing by a plug-in module of IRQA for export to TBM;

FIGS. 32A, 32B and 32C illustrate importation of verification tasks and defect reports from TBM into IRQA;

FIG. 33 illustrates methods of managing import and export of project elements using the plug-in module of IRQA; FIG. 34 is a flow chart illustrating a process management method for developing an embedded system in accordance with an exemplary embodiment of the present invention; and

FIG. 35 is a flow chart illustrating a process management method for developing program code in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION

[0007] What is needed, therefore, is a technique for integrating and automating the requirements traceability and testing/verification tasks of a distributed software development project, including a uniform user interface to help manage highly complex and technical software development projects.

System Overview

[0008] The present invention shall be described by way of exemplary embodiments to which it is not necessary limited. Variations and modifications will occur to these skilled in the art without departing from the scope of invention defined in the claims appended hereto. Absolute statements (that begin with, e.g., "must"), and statements of advantages or other aspects apply to specific exemplary embodiments, and not necessarily to all embodiments covered by the claims.

[0009] Techniques for automated management of software requirements are presented herein that can bridge the gap between high-level requirements traceability tools and low-level source code testing tools across a network of distributed user workspace (e.g. work directories enabled by instances of the invention). The explanation will be by way of exemplary embodiments to which the present invention is not limited.

[0010] FIG. 1 A illustrates an exemplary environment for implementing a system 100 for automated management of software requirements verification. As shown in FIG. 1A, the system 100 can be employed in conjunction with a computer-based system, where the elements can be implemented in hardware, software, firmware, or combinations thereof. As shown in FIG. 1 A, system 100 includes a requirements information source 105, a requirements capture tool 1 10, an automated requirements verification tool 1 15, a static analysis & code coverage tool 120, a unit/integration test tool 125, a network 130, and users 135. Software development projects (e.g., a billing system for a hospital, an inventory tracking system for a store, an avionics display system, etc.) can be defined by requirements. The requirements can specify how the software product should operate when it is implemented. The requirements information source 105, shown in FIG. 1 A, can represent any source of requirements information, including requirement management tools, e.g., Telelogic DOORS®, and IBM Rational RequisitePro®, spread sheet programs, e.g., Microsoft Excel®, word processing programs, e.g., MS Word®, among other sources of requirements information. The requirements capture tool 1 10, can be implemented to capture the requirements information from the requirements information source 105. This information may include requirement identifier and requirement description as well as test case identifier and test case description.

[0011] In one embodiment, the requirements capture tool 110 can use natural language parsing to parse the requirements information. For example, a requirement capture tool, such as the Reqtify™ tool from Geensys (on the web at geensys.com) employs such techniques to generate a RTM from requirements information.

Products, such as LDRA TBreq™, or customized hand-coded systems can be employed to implement the requirements capture tool 110. The parsing of requirements can be performed based on types, as described in more detail below in the subsection entitled "Parsing Based On Types View."

[0012] For example, if software is to be developed for an on-line grocery store, the requirements information source might include an MS Word™ document that specifies, among other requirements, "the on-line grocery store shall maintain a customer account." In this example, the requirements capture tool 110 might capture from the text of the MS Word™ document, the requirement information "maintain account." In another example, the requirements information source might include a DOORS™ module that specifies, among other requirements, "the software must provide fault isolation for all fault types." In this example, the requirements capture tool 110 might capture from the text of the DOORS™ module, the requirement information "Isolate faults."

[0013] In an exemplary embodiment, a software modeling module 190 can be used with the requirement capture tool 1 10. The software modeling module 190 can be implemented by a software modeling tool, such as Telelogic Rhapsody™, Mathworks Simulink™ or National Instruments Labview™. In this exemplary embodiment, the requirements capture tool 1 10 links requirements to architectural artifacts and implementation artifacts in the software modeling tool 190. These architectural and implementation artifacts are thereby implicitly mapped to the resulting source code that is produced by the modeling tool. Thus, each requirement is associated with one or more software architectural model elements. The model elements are propagated to the distributed verification modules for the purposes of implementation, testing and analysis.

[0014] In addition, a modeling tool or a software architectural model can be used to automatically generate source code in which the mapping between requirement and source code is made. In other words, the requirements linked with the architectural and implementation artifacts are implicitly mapped to resulting source code produced by the modeling tool.

[0015] If the software implementation is manually coded, the mapping of requirements to source code is performed using automated requirements verification tool 115 based on the implementation artifacts produced by the modeling tool. The automated requirements verification tool 115 will be described below in detail.

[0016] The static analysis & code coverage tool 120 can be implemented to analyze source code files, which have been written by software developers, to identify procedures in the source code and to assess compliance of the source code with project coding rules and quality metrics. As referred to herein, a "procedure" describes a portion of source code written to implement a requirement. For example, procedures might include functions in the C programming language and classes and member functions in the C++ programming language. Automated software analysis and testing products , such as LDRA Testbed™; Coverity's (on the web at coverity.com) Coverity Prevent Coverity Extend; Programming

Research's (on the web at programmingresearch.com) QA-C, QA-C++ and QA- MISRA; Gimple Software's (on the web at gimpel.com) PC-lint for C/C++ and another Lint based products; Klocwork's (on the web at klocwork.com) inSpect, inSight, inTellect and inForce; Parasoft's (on the web at parasoft.com) C++ Test, C++ Test for Embedded Systems, Code Wizard with Test Case Sniffer; McCabe & Associates' (on the web at maccabe.com) McCabe IQ; Telelogic's Telelogic Logiscope, TAU/Tester and TAU/Logiscope TestChecker; and Testwell's (on the web at testwell.fi) CMT++, Complexity Measures Tool for C/C++ can be employed to implement the static analysis capabilities of the static analysis & code coverage tool 120.

[0017] For the on-line grocery store example, an exemplary source code file

"MaintainAccount.c" for implementing the captured requirement "maintain account" might include the following lines of code:

float MaintainAccountFunction ( )

{

long accntNum;

float balance, avgBalance, ratio;

accntNum = GetSessionAccountNumber ( ) ;

if (accntNum == 0) { return -1; }

balance = GetAccountBalance (accntNum) ;

if (balance <= 0) { FatalError ( "Balance too low

avgBalance = GetAverageAccountBalance ( accntNum)

ratio = balance / avgBalance;

if (ratio < .2)

{

UserMessage ( "Balance is running low");

}

return 0;

}

In this example, the static analysis & code coverage tool 120 might identify the following basic blocks of source code (blocks 4 -6):

60 4 balance =

61 4 GetAccountBalance (

62 4 accntNum ) ;

63 4 if

64 4 (

65 4 balance <= 0

66 4 )

67 5 {

68 5

69 5 FatalError (

70 5 "Balance too low" ) ;

71 5 }

72 6 avgBalance =

73 6 GetAverageAccountBalance (

74 6 accntNum ) ;

75 6 ratio = balance / avgBalance ;

76 6 if 77 6 (

78 6 ratio < .2

79 6 )

After analyzing the source code for compliance with project coding rules, the static analysis & code coverage tool 120 might identify the following code for noncompliance (M) Mandatory:

56 2 {

57 2 return

58 2 - 1 ;

(M) STATIC VIOLATION: 101 S : Function return type inconsistent

67 5 {

68 5

69 5 FatalError (

70 5 "Balance too low" )

(M) VIOLATION : 1 J : Unreachable Code found.

71 5 }

72 6 avgBalance =

73 6 GetAverageAccountBalance (

74 6 accntNum ) ;

75 6 ratio = balance / avgBalance ;

76 6 if

77 6 (

78 6 ratio < .2

(M) STATIC VIOLATION : 96 S : Use of mixed mode arithmetic: float double ratio < .2

79 6 )

For the avionics display system example, an exemplary source code file

"CheckAvionicsDisplay.c" for implementing the captured requirement "maintain account" might include the following lines of code:

int CheckAvionicsDisplay ( )

{

// attempt to start modules. If a module AND its backup fail, // return a negative number indicating the failed module. //

if ( !BITestModulel ( ) ) { if ( ! BackupModulel ( ) ) return -1; } if ( !BITestModule2 () ) { if ( ! BackupModule2 ( ) ) return -2; } if { !BITestModule3 () ) { if ( ! BackupModule3 ( ) ) return -3; }

// everything started up. Return 1 to indicate success.

return 1;

}

In this example, the static analysis & code coverage tool 120 might identify the following basic blocks of source code (blocks 1-7):

37 1 int 38 1 CheckAvionicsDisplay ( )

39 1 {

40 1 //attempt to start modules. If a module & its backup fail

41 1 // return a negative number indicating the failed module.

42 1

43 1 if

44 1 (

45 1 1

46 1 BITestModulel ( )

47 1 )

48 2 {

49 2 if

50 2 (

51 2 1

52 2 BackupModulel ( )

53 2 )

54 3 {

55 3 return

56 3 - l ;

57 4 }

58 5 }

59 6 if

60 6 (

61 6 1

62 6 BITestModule2 ( )

63 6 )

64 7 {

65 7 if

66 7 (

67 7 1

68 7 BackupModule2 ( )

69 7 )

After analyzing the source code for compliance with project coding rules, the static analysis & code coverage tool 120 might identify the following code for noncompliance (M) Mandatory:

37 1 int

38 1 CheckAvionicsDisplay ( )

(M) STATIC VIOLATION: 63 S Empty parameter list to procedure/ funct .

39 1 {

40 1 // attempt to start modules. If a module & its backup fail,

41 1 // return a negative number indicating the failed module.

42 1 //

43 1 if 44 1 (

45 1

46 1 BITestModulel ( )

(M) STATIC VIOLATION : 114 S : Expression is not Boolean.

47 1 )

48 2 {

49 2 if

50 2 (

51 2

52 2 BackupModulel ( )

(M) STATIC VIOLATION : 114 S : Expression is not Boolean.

53 2 )

54 3 {

(M) STATIC VIOLATION : No brackets to then/else {added by analys.

55 3 return

56 3 - 1 ;

57 4 }

58 5 }

59 6 if

60 6 (

61 6 1

62 6 BITestModule2 ( )

(M) STATIC VIOLATION : 114 S : Expression is not Boolean.

63 6 )

67 7

68 7 BackupModule2 ( )

(M) STATIC VIOLATION : 114 S : MISRA-C:2004 12.6 13.2:

Expression is not Boolean.

69 7 )

Moreover, the static analysis & code coverage tool 120 can be reapplied to instrument and measure code coverage in tests run externally. The integration of the static analysis and code coverage (also referred to as dynamic analysis) capabilities of the static analysis & code coverage tool 120 provides the critical basis for the triangulation of test verification and the structural coverage of software abstractions.

[0018] The unit/integration test tool 125 can be implemented to test the source code against the requirements. In an embodiment, the unit/integration test tool 125 can run test cases defining inputs to portions of the source code and expected outputs, and generate results that describe code coverage. For example, the source code can be implemented as a plurality of functions. If a particular function is called and executed during unit/integration testing, then the function can be described as being "covered." Thus, it is typically desirable to have a high percentage of the source code covered. Also, different levels of coverage can be tested during unit/integration testing, such as path coverage, statement coverage, branch coverage, and modified condition/decision coverage (MC/DC). Automation and integration testing software products, such as LDRA TBrun™; Parasoft's (on the web at parasoft.com) C++ Test, C++ Test for Embedded Systems, Code Wizard and Jest with Test Case Sniffer; Vector Software's (on the web at vectorcast.com)

VectorCAST/Ada, VectorCAST/C, VectorCAST RSP for Real-time Embedded Testing and VectorCAST/Cover; IBM Rational (www-

306.ibm.com/software/rational/) Test RealTime; IPL (on the web at ipl.com) Adatest 95 and Cantata ++; Free Software Foundation's (on the web at gnu.org) Cunit,

CPPunit and Junit; and Testwell (on the web at testwell.fi) CTA++, C++ Test Aider, CTC++, Test Coverage Analyzer for C/C++, can be employed to implement the unit/integration test tool 125.

[0019] For the on-line grocery store example, an exemplary test case might test the procedures mapped to the requirement "maintain account," such as float

MaintainAccountFunction(), against the requirement. In this example, the test case might specify that if the GetAccountBalance(accntNum) is called with an input value =3201, the test case would return a value = 1. The coverage results of unit testing in this example might be represented as follows:

—COVERAGE—

- Statement - Desired Coverage(%): 80

Mapped Procedures Passing (%): 89

- Branch Decision - Desired Coverage (%): 60

Mapped Procedures Passing (%): 63

- Path -

Desired Coverage(%): 70

Mapped Procedures Passing(%): 72

[0020] For the avionics display system example, an exemplary test case might test the procedures mapped to the requirement "Isolate faults," such as int

CheckAvionicsDisplayO, against the requirement. In this example, the test case might specify that if the function BITestModule3 ( ) is set to 1 and

BackupModule3() returns 1. The coverage results of unit testing in this example might be represented as follows:

—COVERAGE— - Statement - Desired Coverage (%): 80

Mapped Procedures Passing(%): 61

- Branch Decision - Desired Coverage(%): 60

Mapped Procedures Passing (%): 51

- Path -

Desired Coverage(%): 50

Mapped Procedures Passing(%): 48

[0021] Tracing whether the captured requirements have been implemented in source code and verifying whether the implemented source code operates as desired can be performed manually, but for large software development projects having thousands of requirements, manual tracing and verification of the requirements can quickly become impractical and unmanageable. Accordingly, as shown in FIG. 1 A, the automated requirements verification tool 1 15 can be implemented to bridge the gap between the requirements capture tool 110 and the static analysis and

unit/integration test tools 120 and 125. FIG. IB illustrates an exemplary

implementation of the automated requirements verification tool 1 15 that includes a requirements module 140, a projects module 145, a mapping & analysis module 150, a verification module 155, and a network interface module 160. The LDRA TBmanager™ tool, described herein in conjunction with FIGS. 4A-4J, can be employed to implement the automated requirements verification tool 1 15.

[0022] The requirements module 140 can be configured to define requirements for the software development project based on the requirements information captured by the requirements capture tool 1 10 from the requirements information source 105. The captured requirements information can represent customer-defined, project-level requirements for the software development project, which are referred to herein as "high-level" requirements. In the on-line grocery store example, the captured requirement "maintain account" is an exemplary high-level requirement. High-level requirements, however, do not describe code-level, design requirements necessary for actually implementing the software. Thus, the requirements module 140 can be configured to provide the option of defining additional requirements not captured by the requirements capture tool 1 10.

[0023] For example, the requirements module 140 can be used to define requirements that fulfill part of a high-level requirement, referred to herein as "low-

-14- level" requirements. Low-level requirements can be defined to specify how a portion of the software should be implemented. For example, a low-level requirement might focus on a specific function, aim or goal. In the on-line grocery store example, a low-level requirement called "account name" can be defined for the high-level requirement "maintain account" to establish a name for the account. In another example, the avionics display system, the low-level requirement, "enable named redundant system" is defined for the high-level requirement "Isolate faults" to ensure that only the redundant module identified by Built In Test is enabled.

[0024] The requirements module 140 can also be used to define requirements that are inferred or derived from high-level requirements or low-level requirements, referred to herein as "derived" requirements. Thus, derived requirements may not be captured by the requirements capture tool 110 but can be subsequently created and managed by the automated requirements verification tool 115. In the on-line grocery store example, a derived requirement called "cancel_account" can be defined for the high-level requirement "maintain account" to cancel a maintained account. In another example, the avionics display system, a derived requirement called "damage assessment" can be defined for the high-level requirement "Isolate faults" to facilitate recovery procedure notification.

[0025] The requirements module 140 can further be used to define requirements that are copies of a high-level, low-level or derived requirement, referred to herein as "sibling" requirements. A sibling requirement can be created for the purposes of requirement diversification and task management (e.g., one of the users 135 might write source code to implement a low-level requirement, while another one of the users 135 might verify the implemented source code). As described herein, a sibling requirement can be distinguished by a unique identifier, although it is otherwise identical to the base high-level, low-level, or derived requirement of which it is a copy. In this way, the requirements module 140 can be used to populate the RTM with the captured high-level requirements from the requirements information source 105, as well as with additional low- level, derived, and sibling requirements to enable the automated requirements verification tool 115 to provide automated requirements traceability down to the source code level. [0026] A sibling requirement can be called a verification task. An additional sibling type, or verification task, is called an objective. Objectives are defined to assure conformance with process objectives or qualitative assessments such as requirement validation or proper planning and documentation.

[0027] Another sibling requirement type is associated with defect report generation and resolution. A defect report, the obverse of a requirement, can be generated automatically by the users of the static analysis & code coverage tool 120 or the unit/integration test tool 125. The assignment of defect report spawns a sibling or verification task whose sole purpose is the tracking of defect report to closure.

[0028] The projects module 145 can be configured to establish a project. As referred to herein, a "project" established by the projects module 145 describes an electronic realization of a real- world software development project in that the established project can provide an electronic mechanism for organizing and automating many aspects of the real- wo rid project, including, among other aspects, defining the requirements for the project, assigning users to work on the project, tracing the implementation of the requirements, analyzing and verifying source code files developed to implement the requirements, and tracking defects. The established project can include associated requirements information and source code files written by developers to implement the requirements. In one embodiment, source code previously developed for a requirement can be associated with the project. If source code is not already developed for the requirement, the projects module 145 can facilitate requirements-based development in which assigning the requirement to a user is a precursor to source code development.

[0029] The projects module 145 can be configured to display a hierarchical representation of the associated requirements and source code files for the established project and can provide information on the status of a requirement (e.g., whether the requirement is verified or unverified, the users assigned to work on the requirement, etc.). For example, FIG. 4C, described herein in conjunction with an exemplary user interface, illustrates a Project Tree 412 for the on-line grocery store example showing a hierarchy of requirements and source code files. By linking high-level requirements with their low-level implementations, the projects module 145 can enable project managers to view a requirement-by-requirement breakdown of which requirements' implementations have met coding convention, code coverage levels, and functional testing criteria. In this way, the projects module 145 can provide an integrated requirements traceability and verification matrix. In an embodiment, the projects module 145 can generate a status report summarizing the requirements information for a particular user that can be updated as the project progresses to include code coverage results after unit testing, as described herein, among other information.

[0030] The projects module 145 can be configured to add the users 135 to the project. The users 135 can include any persons working on the project, such as project managers, software developers, test engineers, etc. In an embodiment, the projects module 145 can create "roles" for the project based on groups of the users 135, who are designated to perform similar actions, and to assign the created roles to the users 135. For example, a developer role, a test engineer role, an independent verification and validation (IV V) role, and a quality assurance (QA) role can be created, among others. In an embodiment, a project manager role can be created so that a user assigned the role of project manager can exercise control over virtually all aspects of the requirements verification process and can create other roles, as well as assign roles and requirements to the users 135.

[0031] In an embodiment, permissions can be assigned to the roles to define actions that users assigned to the role can perform. Exemplary permissions include, among others, a create low-level requirements permission, a create derived requirements permission, a make sub-projects permission (e.g., where a sub-project can be established when a requirement is assigned to a user, as described herein), an edit thread properties permission (e.g., where an XML thread can be created for each requirement, as described herein), and a manual verification permission (e.g., to permit a user to access the verification module 155 to review results of the unit testing, code coverage and static analysis as described herein).

[0032] The projects module 145 can also be configured to enable a user with the necessary permissions to assign requirements (i.e., the high-level, low-level, derived, and sibling requirements) defined by the requirements module 140 to the users 135. In one embodiment, assignment of a requirement to a user can establish a corresponding sub-project. A "sub-project," as referred to herein, describes a workspace that the user can access to perform designated tasks associated with their assigned role (e.g., writing source code, analyzing source code files, testing source code files, etc.).

[0033] In one embodiment, the projects module 145 can regulate the operational status of a sub-project to require that users "check-out" a sub-project from the projects module 145 before performing any tasks on the sub-project and "check-in" the sub-project to the projects module 145 upon completion of the task(s). That is, to check-out a sub-project, users can make a copy of their sub-project file for the purpose of performing tasks remotely (e.g., on their own computers) and, to check- in the sub-project, users can copy the modified contents of their sub-project file back into a directory tree for the established project. In this way, the projects module 145 can maintain integrity of the RTM by synchronizing the sub-projects with the current state of the RTM each time the users check-in and check-out their sub- projects. Additionally, as described herein, a create sub-projects permission can be assigned to enable a user to update sub-projects via the projects module 145. For example, as described herein, affected sub-projects should be updated when their corresponding requirements are modified (e.g., due to the addition or deletion of a user).

[0034] The network interface module 160, shown in FIG. IB, can be configured to enable global distribution of the project and provide integrated processes over the communications network 130 (e.g., a LAN, WAN, the Internet, etc.). In an embodiment, the network interface module 160 can enable the users 135 to check-in and check-out their sub-projects from remote locations. Security measures can be implemented, such as establishing a secure connection and requiring the users 135 to logon and supply a password. Additionally, verification status reports can be made globally available. In these ways, the network interface module 160 can be used to perform synchronous or asynchronous operations and to effect a globally-based dynamically updated requirements matrix (both traceability and verification matrix).

[0035] The mapping & analysis module 150, shown in FIG. IB, can be configured to invoke the static analysis & code coverage tool 120. As described herein, the mapping & analysis module 150 can invoke the static analysis & code coverage tool 120 to map procedures identified in source code to the defined requirements for the project. For the on-line grocery store example, the procedures float MaintainAccountFunction(), long GetSessionAccountNumber(), float

GetAverageAccountBalance(long accntNum), float GetAccountBalance(long accntNum) void FatalError(const char * msg), void UserMessage(const char * msg) identified in the exemplary source code file "MaintainAccount.c" can be mapped to the high-level requirement "maintain account." For the avionics display system example, the procedures int CheckAvionicsDisplay(); int BITestModulel(); int BITestModule2(); int BITestModule3(); int BackupModulelO; int

BackupModule2(); int BackupModule3(). An exemplary graphical user interface for mapping procedures to requirements is illustrated in FIG. 4G, which is described herein.

[0036] Additionally, the mapping & analysis module 150 can enable a user to verify a requirement by identifying an analysis requirement verification method and/or a test requirement verification method. For example, in one embodiment, the mapping & analysis module 150 can be used to invoke the static analysis & code coverage tool 120 to provide integrated analysis capabilities, including analyzing the mapped procedures against project coding rules and quality metrics. Additionally, in another embodiment, the mapping & analysis module 150 can be used to invoke the unit/integration test tool 125 to test the mapped procedures against the requirements, as described herein, by running test cases and generating results that describe code coverage. And in another embodiment, the mapping & analysis module 150 can be used to instrument code that will be executed externally and whose execution results (i.e., code coverage results) can subsequently be returned to the mapping & analysis module 150 for the purpose of post-mortem code coverage analysis.

[0037] The verification module 155, shown in FIG. IB, can be configured to verify the defined requirements based on the results of analyses performed on the mapped procedures by the static analysis & code coverage tool 120, as well as results of the unit testing performed on the mapped procedures by the

unit/integration test tool 125. For example, in one embodiment, a user with the necessary permission can use the verification module 155 to select a requirement and view the expected code coverage and the achieved code coverage for the selected requirement (e.g., as percentages of the mapped procedures achieving a desired coverage). If the user is satisfied with the coverage achieved for the selected requirement, the user can maintain the current status of the selected requirement as verified. However, if the user is unsatisfied with the coverage achieved for the selected requirement, the user can change the current status of the selected requirement to unverified. Because un-verifying a requirement modifies that requirement thread, as described herein with respect to the exemplary XML implementation, the user should subsequently update any sub-projects associated with the requirement.

[0038] The verification module 155 can also be configured to create groups under a user, and associate requirements with respective groups. Groups have verification rules assigned to them, such that when a requirement is assigned to a group, a sibling requirement for each verification rule is generated for that (base) requirement. With respect to test verification rules, a sibling or verification task is created for each test case associated with the base requirement. All requirements can be ungrouped requirements initially. Requirements can then be associated with one or more groups.

[0039] Verification rules specify which verification tasks must be completed before the requirement can be considered verified in this exemplary embodiments. What a requirement must satisfy is determined by the verification group that the requirement is in. Verification rules specify not only what verification task must be done; they also specify who should do them. A verification rule can specify that the requirement pass Code Review, and can further specify that Code Review be performed by a certain user or a user of a certain role (e.g., "Tester" or "QA"). Rules may be sequenced, which forces them to be performed in the order listed in the verification group.

[0040] When a verification rule is defined, one or more quality models can be applied. A quality model can set a standard via which the quality of software for a given project can be measure and visualized. A quality model is enforced by the code review and quality review verification tasks. [0041] The code review standards can be defined in a pair of files, a report file (<language>report.dat) and a penalty file (<language>pen.dat). The report file contains the complete set of predefined coding rules. This set of rules can be extended to accommodate a given project. Subsets of the rule set, as defined by published coding standards, are predefined so the user may apply those standards without having intimate knowledge of details of the standard. By viewing the report file, one can see the mapping of these standards to rules and their enforcement. The penalty file can be a legacy mechanism for configuring the code review.

[0042] The quality review standards can be defined in 'metpen.dat'. This file contains a series of analysis measurements which are paired with tolerance thresholds. For instance, cyclomatic complexity measurements, code complexity measurements, unreachable lines measurements, comment-related ratios

measurements. If the complexity exceeds a certain preset threshold, the quality review report will flag it accordingly. As with the 'report.dat' file used for code review, the 'metpen.dat' file may be customized to meet a project's needs.

[0043] The selection of different quality models can be achieved via

combinations of verification rules assigned to groups. When sibling requirements are invoked for code or quality review, the appropriate quality model is applied for testing.

[0044] As mentioned above, a sibling requirement of a verification task is generated for every verification rule that the base requirement must satisfy. For example, if a requirement's verification rule stipulates that it pass code review, then a sibling is made, and if the sibling passes code review, then the requirement is considered as passing code review.

[0045] Accordingly, the automated requirements verification tool 115 can be employed in a software development project to enable automated integration of requirements-based development and verification processes and provide global access to a dynamically-updated traceability and verification requirements matrix to all members of a project team, including management. As described herein, in one embodiment, the automated requirements verification tool 115 can be implemented using the extensible markup language (XML). [0046] In order to automate and make a repeatable process of requirements traceability, a triangulation of the test verification process must be supported. This triangulation includes three vectors: the mapped requirement (a static association including a procedure, an aggregation of procedures, a class or any implementation artifact), the structural coverage (a dynamic metric of code coverage and test case execution) and the test case (the functionality to be exercised). The realization of requirement traceability is greatly complicated by software programming

abstractions such as overloading, multiple inheritance, generic parameterizations and dynamic dispatch tables. The present invention achieves this traceability by integrating its static and dynamic vectors as dictated by the required functionality. The traceability facilitated by the invention, including the use of the static analysis & code coverage tool 120, is extended to instances of the software and its run time artifacts. In addition to the mapped requirement, the test case (or use case) must be explicitly mapped as a predicate for any test-based verification task to be performed.

Process Overview

[0047] FIG. 2 illustrates exemplary steps for a process 200 for electronically managing requirements for software development. Not all of the steps of FIG. 2 have to occur in the order shown, as will be apparent to persons skilled in the art based on the teachings herein. Other operational and structural embodiments will be apparent to persons skilled in the art based on the following discussion. These steps are described in detail below.

[0048] In step 205, a software development project is established. For example, the projects module 145, described in conjunction with FIG. IB, can be employed to implement step 205. In an embodiment, step 205 includes identifying users for the project. In another embodiment, step 205 includes creating a plurality of roles for the project based on groups of the users who are designated to perform similar actions. For example, a project manager role can be created having permission to exercise control over the process 200, and at least one additional role can be created, such as a developer role, a test engineer role, an independent verification and validation role, and a quality assurance role. In this embodiment, step 205 can include assigning permissions to the roles to define the actions that the users can perform, such as a create low-level requirements permission, a create derived requirements permission, a make sub-projects permission, an edit thread properties permission, and a manual verification permission, and step 205 can also include selecting roles for the users.

[0049] In step 210, requirements for the project are defined based on

requirements information captured from a requirements source. For example, the requirements module 140, described in conjunction with FIG. IB, can be employed to implement step 210. In one embodiment, step 210 includes capturing high-level requirements for the project based on the requirements information, and defining at least one additional requirement for the project based on the requirements information. The additional requirement(s) can define a low-level requirement that fulfills part of a captured and allocated high-level requirement for the project, a derived requirement that is inferred from a defined high-level requirement or low- level requirement for the project, and/or a sibling requirement that is a copy of a defined high-level, low-level, or derived requirement for the project. Additional requirements information can include test cases associated with any given requirement. In the absence of test cases defined as part of the original requirements information, the user must enter a test case before performing a test-based verification task.

[0050] In step 212, for each requirement, source code already developed for the requirement is associated with the project. For example, the projects module 145, described in conjunction with FIG. IB, can be employed to implement step 212.

Additionally, if source code is not already developed for a requirement, step 212 can facilitate requirements-based development in which requirements assignment is a precursor to source code implementation. In this embodiment, the association of source code with a project does not occur until step 215. In step 212, corresponding sub-projects can be established when assigning the defined requirements for the project to the users.

[0051] Optionally, the process 200 can include the additional steps of generating a status report for a user summarizing the defined requirements assigned to the user, and updating the status report during the project to include corresponding results of the analyses, code coverage and the unit testing. [0052] In step 215, procedures identified in the source code are mapped to the defined requirements for the project. For example, the mapping & analysis module 150, described in conjunction with FIG. IB, can be employed to implement step 215. In one embodiment, step 215 includes invoking a static analysis tool, such as the static analysis & code coverage tool 120 described in conjunction with FIG. 1 A, to analyze the source code to identify the procedures in the source code. In this embodiment, the static analysis tool can also be invoked to perform analyses on the source code, including applying project coding rules and quality metrics to the associated source code files. Moreover, this static analysis & code coverage tool 120 can be used to instrument and measure code coverage in tests run externally. In another embodiment, step 215 includes invoking a unit test tool, such as the unit/integration test tool 125 described in conjunction with FIG. 1 A, to run test cases on the mapped procedures.

[0053] In step 220, the defined requirements for the project are verified based on results of one or more of analyses, code coverage measurements and unit testing performed on the mapped procedures. For example, the verification module 155, described in conjunction with FIG. IB, can be employed to implement step 220. In one embodiment, step 220 includes verifying the defined requirements for the project if results of the analyses indicate conformance of the source code to the project coding rules and the quality metrics. In this embodiment, the nonconformances can be tracked based on the results of the analyses, and the nonconformances, including providing information regarding disposition of the nonconformances, can be reported. In another embodiment, step 220 includes verifying the defined requirements for the project if the test cases generate desired results.

[0054] In yet another embodiment, step 220 includes the additional steps of providing a status of the defined requirements for the project indicating whether each of the defined requirements is verified or unverified, and generating an integrated requirements traceability and verification matrix to dynamically track implementation of the defined requirements and the status of the defined

requirements. In this embodiment, sub-projects for the project can be established by assigning the defined requirements for the project to users working on the project, and the sub-projects can be synchronized with the integrated requirements traceability and verification matrix.

[0055] Optionally, the process 200 further includes the step of enabling the users to access the project via a communications network. For example, the network interface module 160, described in conjunction with FIG. IB, can be employed to implement the networking step. In an embodiment, the integrity of the requirements traceability and verification matrix can be maintained by monitoring when the users check-out and check-in their corresponding sub-projects over the communications network. In other words, the process 200 can support a unit test workflow scenario that includes requirements traceability and test verification through high-level, low- level and derived requirements and facilitates the mapping of these requirements with source code procedures or methods. The mapped requirements can

subsequently be made available to a developer or a tester for the purposes of test specification creation and test verification. The process 200 can also facilitate the creation of test cases from these test specifications. The process 200 can

automatically trace the results of this unit test scenario back to the requirements sources to ensure requirements traceability matrix (RTM) integrity and user workspace (e.g., project/subproject) security and flexibility in its deployment. In an embodiment, a user can operate on a "checked-in" sub-project, where all tasks performed by the user can be dynamically tracked and updates to the RTM can be synchronized, or the user can operate on a "checked-out" sub-project, where verification tasks can be performed at any location and results can be subsequently synchronized with the current RTM when the user returns to operate on a checked-in sub-project.

Detailed Description of Exemplary XML Implementation

[0056] As described herein, the automated requirements verification tool 115 and the automated requirements management process 200 can be employed in a software development project to bridge the gap between high-level requirement traceability tools and low-level code testing tools and, in one embodiment, can be implemented using XML constructs.

[0057] For example, requirements management data can persist in an XML construct called a "thread," so that each requirement that is tracked has one corresponding XML thread. In this way, as referred to herein, the terms "thread" and "requirement" can essentially be interchangeable, except a thread more accurately describes a requirement-based task and more. For example, as shown in FIG. 3A, a thread 305 can include metadata describing the requirement and its relationship to other requirements 310, as well as prototype information regarding procedures in source code files that are mapped to the requirement 315 and analysis and test result information 320 pertaining to verification of the requirement. All prototype information can be kept in the thread itself, including the code coverage information using a <Prototypex/Prototype> XML block.

[0058] With the exception of hierarchical information (i.e., thread relationship data can be contained in the threads themselves, but all the threads taken together form a cohesive hierarchy), all pertinent information about a thread can be contained in the thread itself. In this way, a thread can largely be a self-contained object, enabling a program to use thread information sensibly without any knowledge of the project the thread belongs to, including user, role, and permission information. For example, FIG. 3C illustrates a project schematic 340 and shows that a thread XML file 345 can be independent from project XML files 350, 355 and 360 that can be used to create a cohesive project and to present the thread information to the users in a useful and intuitive manner.

[0059] The thread definition itself can specify a minimum number and arrangement of fields (also called "elements" when speaking within an XML specific context), which must exist for the data aggregation to be called a "thread" proper. Whether the information put into those fields has any correlation with real- world data is beyond the scope of the thread definition. The definition of a thread is dependent only upon a unique reference identifier (e.g., ref = " " metadata) and not upon the actual string used to make the threads human-readable.

[0060] FIG. 3B illustrates how a thread XML file 335 can be manipulated by a calling application/program 325 through an XML wrapper class called

CXMLWrapper. While it can be possible to read and write directly from/to threads, the CXMLWrapper can be used to enforce the ref = " " XML conventions, thereby ensuring that threads are written and re-written in a consistent, standards-conforming manner. [0061] FIG. 3D illustrates an exemplary representation of a thread in memory. The CXML Wrapper class is based on the CGenericXML Wrapper XML mapper class, which can be implemented to convert an XML file into a hierarchical tree of objects called ReqDataContainers 365. Conceptually, a ReqDataContainer 365 can maintain hierarchical information about itself (e.g., who its parents and children are) and about its own data (e.g., name, unique reference identifier, and data). The CGenericXML Wrapper class can create one ReqDataContainer for each element encountered while reading an XML file. The element's name and unique reference number can be stored, in addition to any data. Hierarchical information can be contextually determined based on relevant factors such as, whether the element has data and the parent element, among other factors. Thus, in the tree of

ReqDataContainers, each ReqDataContainer can be analogous to a node with pointers to its siblings in the tree.

[0062] In the event an element is encountered that does not have a reference number, a reference number can be assigned to the element, beginning at a reasonably high "unknown floor." Thus, a program wishing to retrieve the element's data must know the value of the unknown floor ahead of time, which can be defined in the XMLWrapper.h class, in addition to other factors regarding how many unreferenced elements are being read and have been read. In practice, it can be more effective to define a thread tree by using a unique reference number (or other unique identifier) for each of the elements of a thread instead of relying on automatic assignment of reference numbers. Automatic assignment of reference numbers can be effective, however, to prevent a situation where an entire thread (or trace.xml file) cannot be accessed because a faulty portion of a program did not assign a reference number to one of its new elements.

[0063] Once the CGenericXML Wrapper class creates a ReqDataContainer tree, as shown in FIG. 3D, a calling program can have complete freedom to modify the ReqDataContainer tree. For example, a calling program can add or remove

ReqDataContainers and modify data in existing ReqDataContainers. After a calling program has finished modifying a ReqDataContainer tree, it can call an XML method of the wrapper class called WriteAsXMLQ to have the wrapper class convert the ReqDataContainer tree back into an XML file and write the XML file to a storage device.

[0064] ReqDataContainers 365 can be designed to mimic XML as much as possible. ReqDataContainers need not be categorized based on whether they have data, children, siblings, or any other contextual property. In practice, however, some distinctions among the ReqDataContainers should be implemented so that the data can be organized accordingly.

[0065] The flexible nature of a ReqDataContainer tree implementation can permit different programs to add their own data to the thread without interfering with each other. For example, in one embodiment, defect tracking information and function prototype XML blocks can be added to a thread's "scope" without obfuscating its primary payload, the individual requirement. These are examples of data that is added to threads as individual traceability needs arise (in this case, the extension of verification down to individual functions), and in this way, the approach of encapsulating all data related to the requirement and its traceability information into a single thread can enable flexibility and freedom for user programs. The ReqDataContainer tree implementation can also define a standard way of encoding data. In this way, programs which want to take advantage of features offered by other programs need only understand the XML block convention used in order to build their own functionality around it.

[0066] In one embodiment, classes called RDCPtr, iRDCPtr, and

CWrapperLibrary, can be implemented to (1) organize iterated XML blocks into "stacks" of "vertical data" to avoid the need for contact with a parent node, (2) enable sequential accessing of siblings without the need for communicating with the parent node, and (3) provide a one-to-one correlation between a ReqDataContainer and a single element of a stored XML file.

[0067] Avoiding reliance upon parent nodes for information about child hierarchical relationships can improve the integrity of the code. For example, programs typically need access to all instances of a certain XML block, such as getting prototype information out of a thread. A pseudocode representation of a function which gets prototype information from a thread without using the RDCPtr class can be expressed as follows: ReqDataContainer prototype_parent =

current_thread.GetElement (REF_TEST_SPECIFICATION) ;

ReqDataContainer prototype =

prototype_parent .GetElement (REF_PR0T0TYPE) ; while (prototype != NULL) {

PrintPrototypelnfo (prototype) ;

prototype = prototype_parent . NextElement (prototype ) ;

}

A pseudocode representation of a function which gets prototype information from a thread using the RDCPtr class can be expressed as follows:

RDCPtr prototype = current_thread

-GetElement (REF_TEST_SPECIFICATION)

. GetElement (REF_PROTOTYPE) ;

while (prototype != NULL) {

PrintPrototypelnfo (prototype) ;

prototype = prototype . GetNext () ; [0068] The improvement with regard to code cleanliness between the two implementations can be significant considering that this "list" of prototypes that a thread possesses can be passed around, in its entirety, by passing only the RDCPtr of the first prototype because the first prototype in the list knows the location of the other prototypes. Thus, instead of a function passing around two ReqDataContainer pointers (i.e., one for the element and one for its parent), only one RDCPtr object need be passed around for every function to have access to all the prototypes.

Further, the wrapper class only has to service one application call (i.e., the call which gets the first prototype) and will not need to service other calls to get any additional prototype information. In this way, iterated blocks of XML data can be represented as "vertical" data, as shown in FIGS. 3D and 3E. The first prototype can be treated like any other block of XML, and subsequently read prototype blocks can be "stacked" on top of the first prototype. The RDCPtr class embodies this concept of stacks of ReqDataContainers.

[0069] Thus, the calling program need not interact with a ReqDataContainer directly. All data access can be accomplished via RDCPtrs, which can enable the unique "vertical data" stacking mechanism shown in FIGS. 3D and 3E. Because of their usefulness as smart pointers, RDCPtrs can provide exclusive means of accessing ReqDataContainers. Even if an element has no vertical data (i.e., there is only one iteration of the element), it can still be returned as an RDCPtr. Thus, functions do not need to be overwritten to accept both ReqDataContainers and RDCPtrs, all functions can simply accept an RDCPtr. By passing around one relatively small RDCPtr, the entire calling program can have random or sequential access to the entire vertical stack of data. This feature can enable easier, cleaner, and more concise code implementation. Furthermore, by using RDCPtrs, the calling program need not create or delete ReqDataContainers into or from memory, which can be all handled automatically, as described herein.

[0070] The iRDCPtr class can provide a mechanism for organizing

ReqDataContainers "left and right" into lists. The iRDCPtr class is not used by calling programs but can be used by the backend (e.g., the wrappers used to interface with the XML files) to enable sequential searching through siblings and writing recursive algorithms to search through the ReqDataContainer tree

(ReqDataContainers do not keep" track of their "siblings" in the ReqDataContainer tree). Calling programs can access a child of a ReqDataContainers by index (i.e., by unique reference identifier) and cannot sequentially search through the children of a ReqDataContainer to find the child it needs but, for internal processes, the

CGenericXMLWrapper can use iRDCPtrs to sequentially search through the children of a ReqDataContainer.

[0071] Calling programs should use CWrapperLibrary class to get a wrapper for an XML file. For memory management purposes, the automated requirements verification tool 115 and its backend can use a class to manage allocation and deletion of resources. For example, the CXML Wrapper class can be used to create the ReqDataContainers, RDCPtrs, and iRDCPtrs needed. A calling program can obtain RDCPtrs upon request, and the entire XML file, as represented by the CXMLWrapper, can be created and deleted with the CXMLWrapper. The

CXMLWrapper, in turn, can register all objects (e.g., ReqDataContainers) it creates with a GlobalRDCPool object, which can be emptied by the calling program when it exits.

[0072] Further, the automated requirements verificaiton tool 115 and its backend can use a class called CWrapperLibrary to manage CXML Wrappers in the same way that the GlobalRDCPool class manages RDCPtrs. With CWrapperLibrary, a calling program need not create a wrapper at all. Rather, the calling program can request the ReqDataContainer tree for an XML file. If the ReqDataContainer tree has not yet been built for the requested XML file, the CWrapperLibrary class can be used to create a wrapper, have the wrapper build the ReqDataContainer tree, and pass back to the calling program a pointer to the created wrapper. In this way, CWrapperLibrary can organize all the CGenericXML Wrappers that a calling program is using. For example, if the calling program requests a wrapper that corresponds to "filel trace.xml," CXML Wrapper can search a library of already- built wrappers for a CXML Wrapper object for filel trace.xml. If a CXML Wrapper object for filel trace.xml has already been built, CXML Wrapper can simply pass a pointer to the already-built CXML Wrapper back to the calling program, otherwise CWrapperLibrary can make a new CXML Wrapper for filel trace.xml and pass a pointer to the new object back to the calling program.

[0073] Like RDCPtrs, CXMLWrapper hides allocation of memory from the calling program, so the calling program is not responsible for freeing the object that CWrapperLibrary passes back. Also, when a calling program uses

CWrapperLibrary, all parts of the program can be certain to be working on the same ReqDataContainer tree (a ReqDataContainer is a single element in an XML file, so a tree of ReqDataContainers represents the entire XML file) and the calling program does not have to implement synchronization across the program.

[0074] Typically, a calling program will call the GetFile() method to retrieve the RDCPtr for the file's root element and will not make any further calls to the wrapper. The calling program does not delete the created wrapper. Instead, the EmptyWrappers() method (which also writes all opened wrappers to a storage device) can be used to delete wrappers vicariously. In this way, the

CWrapperLibrary class can be used to ensure that all parts of the automated requirements management program are working on the same ReqDataContainer tree and to facilitate memory management.

[0075] The memory management classes, when used together, can result in an unbroken persistence of RDCPtrs (i.e., the RDCPtr a calling program receives at the beginning of a session is the same RDCPtr the calling program would receive later in the session) to enable parts of the calling program, which use the same

GlobalRDCPool and CWrapperLibrary, to pass RDCPtrs around. Therefore, when the calling program decides to ask the memory management classes to empty themselves can be an important decision. For reasons of memory usage, under certain situations, it may even be desirable to force-empty wrappers and RDCPtrs. This memory management technique can result in an increase in memory usage for the program's lifecycle. Once memory usage reaches a certain level, it is unlikely to increase further, but for programs that might in their lifecycles incur the opening of dozens or even hundreds of XML files, force-emptying the memory management classes can be beneficial. Care should be taken, however, that references to resources managed by the memory management classes are no longer needed after emptying them.

[0076] In one embodiment, the threads can be converted into a SQL format for storage and access over a global network. This process can be supported by a web service that accepts upload requests from the automated requirements verification tool 115. This same web service can generate traceability and verification reports upon request from web users. Additionally this web service can accommodate download requests to the automated requirements verification tool 115. As a consequence of these web services, global project synchronization can be facilitated.

Exemplary Graphical User Interface Implementation

[0077] FIGS. 4A-4J illustrate an exemplary implementation of a graphical user interface (GUI) for a software requirements management tool TBmanager™ developed by LDRA™. TBmanager™ can be employed to facilitate management and allocation of software requirements for development, testing and verification purposes. Persons skilled in the art will understand that the GUI design need not be limited to the design illustrated in FIGS. 4A-4J and that other GUI designs can be implemented. In this embodiment, a project file (e.g., having a ".tbp" extension) can first be created using a requirements capture tool, such as TBreq™, developed by Geensys™, which can capture requirements information for a software development project from sources of requirements information such as Telelogic DOORS® or IBM Rational RequisitePro®, MS Excel®, MS Word®, among other sources of requirements information.

Defining Roles and Users

[0078] FIG. 4A illustrates an exemplary GUI 401 for defining roles for the project during an initial set-up. Roles can be used to group together users who perform similar or related tasks; for example, a role can be created and applied to all of the developers of a project. Each user can be assigned one role. One user can assume the role of project manager. The project manager role can exercise control over every aspect of the requirements management process and can be responsible for creating roles and users and for delegating requirements. For example, the project manager can create and assign a role to grant other users the ability to create roles and users and to delegate requirements.

[0079] As shown in FIG. 4 A, a New Role field 402 of GUI 401 can be used to enter the name of a new role, and the new role can be added by pressing the Add button. Exemplary roles 403 can include a developer role, a GUI designer role, an independent verification and validation (IVV) role, a quality assurance (QA) role, and a test engineer role, among others. As shown in FIG. 4A, the Remove Selected button can be used to remove an added role, and the Import Roles From File button can be selected to import roles that have been defined in a text file or in another project.

[0080] Permissions can be assigned to the roles to enable different levels of functionality for corresponding users, such as by defining the requirements information that the users can access and the actions that they can perform. As shown in FIG. 4A, the Assign Permissions button can be used to assign permissions to the roles 403. Exemplary permissions 404 can include, among others, "Create Low Level (LL) Reqs," which can be assigned to a role to enable corresponding users to create low-level requirements, "Create Derived (DV) Reqs," which can be assigned to a role to enable corresponding users to create derived requirements, "Make SubProjects," which can enable corresponding users to assign users to requirements for the project, "Edit Thread Properties," which can be assigned to a role to enable corresponding users to edit available requirement attributes via a Requirements View described herein, and "Manual Verification," which can be assigned to a role to enable corresponding users to access to a Verification View described herein.

[0081] Roles can be used to diversify allocated requirements among users. In this way, the same requirement (via sibling requirements) can be assigned to two or more users of differing roles, while maintaining traceability of development and verification tasks. For example, the same requirement can be assigned to a developer for coding, QA for testing and IVV for independent validation and verification.

[0082] Similarly, FIG. 4B illustrates an exemplary GUI 405 for defining users for the project. As shown in FIG. 4B, a New User field 406 can be used to enter the name of the new user and to select a corresponding role for the new user, and the new user can be added by pressing the Add button. The added users can be displayed in a Users field 407. A Remove Selected button can be used to remove an added user from the project, and an Import Roles From File button can be selected to import users previously defined in another file.

[0083] Adding news users and roles after setup can be performed safely, when followed by a sub-project update, as described herein. However, once requirements have been assigned to users, as described herein, users and roles should not be deleted. For example, deleting a role can result in a user losing necessary

permission to work on the project and deleting a user can result in a requirement being unassigned. Accordingly, care should be taken when deleting roles and users.

Parsing Based on Types View

[0084] Requirement documents can be imported and parsed. The parsing can be performed based on types. A parsing schema must be described in a Types file. As illustrated in FIG. 7, many types files can be predefined, covering commonly used tools such as diagramming software, e.g., Visio 702; requirement management tools, e.g., DOORS™ 704 and 706, and Rational Requisite Pro 708; word processing programs, e.g., MS Word 710; spreadsheet programs, e.g., Excel 712, and authoring and publishing software, e.g., Framemaker 714. The types file can be a converter so that it can understood how requirements are described in the reference document.

[0085] FIG. 8 illustrates an example of requirements in an MS Word file. As illustrated in FIG. 8, appropriate styles must be applied to the requirement ID 802 and requirement text 804 so that the document can be parsed as the author intends.

[0086] FIGS. 9 and 10 illustrate examples of a type editor. The MS Word style used in the document, including the requirement ID 802 and requirement text 804, must be described in the type editor fields 902 and 1002, so that the MS Word file can be parsed correctly. Groups View

[0087] Verification Groups for a project can be created under a user. FIG. 5 illustrates an example of selecting, creating, renaming or deleting a group view in a "Verification Groups" dialog 500. Referring to FIG. 5, a verification group is created by clicking the "New Group" button 502. A dialog box "Enter Group

Information" 518 appears when the "New Group" button 502 is clicked. The name of the verification group can be entered in the name text field 514. In this example, the group name "High Priority" is entered in the name text field 514. In addition, description "Must be implemented in the current spiral" is entered in the description text field 516. When the "OK" button 520 is clicked, a verification group is created.

[0088] Once a Verification Group is created, a user can highlight the group and click on the "Rules >" button 508 to edit verification rule(s) for a given group. FIG. 6 illustrates an example of editing rules for a given group in an "Edit Rules" dialog 600. Referring to FIG. 6, when the "New" button 610 is clicked, a "New Rule" dialog 616 appears. In the "New Rule" dialog, the rules specify that the requirement must satisfy "Unit Testing" and must be completed by "The Requirement's

Assignee" in text fields 602 and 604. The verification rules available for selection can include: Code Review, Quality Review, System Test, Unit Testing, Sub-System Test and integration Test. It can also be decided whether the user assigned to the requirement is allowed to execute the test, or if another user must execute the test. When the "OK" button 606 is clicked, the new rules are created under the "High Priority" group. The "< Group" 608 button can be used to return to the "Verification Groups" dialog 500. The "Save and Use" button 612 can be used to save the rules for future use. The "Use Existing" button 614 can be used to select saved rules for a given group.

[0089] Referring back to FIG. 5, the "Rename Group" button 504 can be used to rename the group, once created. The "Delete Group" button 506 can be used to delete a group. The "Save and Use" button 510 can be used to save the group information setting for future use. The "Use Existing" button 512 can be used to select saved group information setting for a given group.

[0090] With a group being defined as described above, requirements can be associated with the group. FIG. 11 illustrates an example of ungrouped requirements and grouped requirements. In FIG. 1 1, REQ 1 1102 and REQ 2 1104 are ungrouped requirements. REQ 3 1 106 and REQ 4 1108 are included under the group named "Static Testing."

Sibling Requirement View

[0091] FIG. 12 illustrates an example of a sibling requirement view. In FIG. 12, two sibling requirements 1202 and 1204 correspond with the requirement 1206. Sibling requirement 1202 is for code review, sibling requirement 1204 is for quality review.

[0092] Verification can be driving by the set of sibling requirements, and each requires an individual test run to be executed. A requirement is verified only when all sibling requirement corresponding to the requirement have been verified.

[0093] FIG. 13 illustrates another example of a sibling requirement view. In FIG. 13, sibling requirement 1306 is under the group named "Static Testing" 1304 associated with a developer, named "Sam Brown" 1302. The sibling requirement 1306 indicates that the verification task is code review. In this example, the verification status 1308 of the sibling requirement 1306 is "Passed." It is also indicated that source files named CashRegister.cpp and Backbeat.cpp 1310 and 1312 are associated with the sibling requirement 1306.

Project View

[0094] As shown in FIG. 4C, the GUI can have a tabbed format to provide users with different views (e.g., Project, Verification, Define Requirement, Requirement Information, Assign Users, Map Procedures, and Procedures) that can be selected and actions that can be performed based on their assigned roles. FIG. 4C illustrates a GUI 408 that can be displayed when the Project View tab is selected. The project GUI 408 can display all the requirements assigned to and by the user (e.g., requirements in bold type can represent those assigned to the user and requirements not in bold type can represent those that the user has assigned).

[0095] The project GUI 408 includes a Current Requirement drop-down menu 409, which can be used to select and display a particular requirement for the project. The GUI 408 also includes buttons, such as an Open Project button 410a, which can be used to select a project or subproject file for loading, an Update Sub-Projects button 410b, which can be selected to update/synchronize all currently checked-in sub-projects with recent modifications to the requirements for the project, a Status Report button 410c, which can be selected to display a status report based on the current requirements for the project, an Add Source button 410d, which can be selected to add/upload a source file of code to the current project, a Remove Source button 410e, which can be selected to remove a currently selected source code file from the current project, a Unit Test button 41 Of, which can be selected to launch an external tool for unit testing (e.g., LDRA Testbed™ and TBrun™), and a Setup Wizard button 41 Of, which can be selected to setup roles and users, if the current user has the necessary permission, as described herein. Additional elements of the project GUI 408 include a User Guide button 411, which can be selected to display a user guide, as well as Exit and Save buttons 413 and 414, which can be selected to exit the tool and save the current project, respectively.

[0096] The project GUI 408 can also display a Project Tree 412 to show the requirements that are assigned to the user and any source code files added to the project. The Project Tree 412 can display each requirement by number, name, reference identifier and type, where different icons can be used to represent different types of requirements. Additionally, an "X" symbol can be used over a

requirements icon to indicate that the corresponding requirement is unverified. To view more information about a particular requirement, the user can select the Requirement Information tab, as described herein.

[0097] Updating sub-projects can be performed to distribute modifications to requirements of the project to affected sub-projects. To update sub-projects, users should first check-in their sub-projects. Then, after modifying the requirement (e.g., re-assigning the requirement, un-verifying the requirement, etc.), the Update Sub- Projects button 410b can be selected to disseminate the modification to all of the affected checked-in sub-projects so that when the users subsequently check-out their sub-projects, they can access the modification. While only users working on sub- projects affected by the requirements modification need check-in their sub-projects before updating sub-projects, all users should check-in their sub-projects to make a modification to users (e.g., when adding or removing users to/from the project).

[0098] In one embodiment, a user can generate a status report to display the current status of all requirements associated with the user by selecting the Status Report button 410c. The status report can provide a summary of the requirements assigned to or by the user and can display detailed requirement attributes such as, requirement name, requirement number, requirement document, requirement body, user assigned to the requirement, and the role of the assigned user. As the project progresses and procedures are mapped to the requirements, as described herein, the status report can be updated to include a table of mapped procedures for each requirement. The table can display detailed attributes of the mapped procedures, such as the procedure name, the name and location of the source code file, the path coverage achieved, the branch decision coverage achieved, the MC/DC coverage achieved, and the statement coverage achieved. The achieved coverage fields in the table can remain empty until unit testing of the mapped procedure has been performed, as described herein. After unit testing is performed, these fields can be updated to show the coverage achieved. Additionally, after unit testing is performed, the status report can indicate a percentage of the tested mapped procedures achieving the desired coverage. The status report can also be configured to distinguish how verified and unverified requirements are displayed, for example, by using different color text.

[0100] After requirements have been defined and users have been assigned to the defined requirements, as described herein, source code that has been developed by the users can be added to the project by selecting the Add Source button 410d. Once added, the source code can be displayed in the Project Tree 412. Note that source code files can be added to the project but not to the requirements themselves because procedures in the source code files, not the source code files themselves, can be mapped to the requirements, as described herein. Source code files can also be removed from the project by selecting the source code file to be removed in the Project Tree 412 and pressing the Remove Source button 410e.

Requirement Information View

[0101] FIG. 4D illustrates a GUI 415 that can be displayed when the

Requirement Information tab is selected. The requirement information GUI 415 can display information about the current selected requirement. In particular, the requirement information GUI 415 can group the information about the currently selected requirement into three areas of interest: test configuration, test management and requirement nomenclature. A Test Configuration drop-down menu 416 can be used to view and edit information about the test configuration properties of the currently selected requirement, a Test Management drop-down menu 418 can be used to view and edit information about the test management properties of the currently selected requirement, and a Requirement Nomenclature drop-down menu 417 can be used to view and edit information about the requirement nomenclature of the currently selected requirement. The requirement information GUI 415 includes a View/Edit area 419, in which the selected requirement can be displayed and/or edited. The View/Edit area 419 can be grayed out to indicate when the user is not permitted to edit the value or description associated with the selected requirement information.

Define Requirement View

[0102] During the life span of a project, there can be a need to introduce new requirements or refine existing requirements. To define a requirement, the Define Requirement tab can be selected. FIG. 4E illustrates a GUI 420 that can be displayed when the Define Requirement tab is selected. Using the define requirement GUI 420, the user can create and add low-level or derived requirements to the project, depending on the permissions assigned to the user's corresponding role. As described herein, high-level requirements include requirements captured by the requirement capture tool and imported into the project. Low-level requirements include requirements that are associated with a high-level requirement. Derived requirements include requirements not captured by the requirements capture tool but defined in TBmanager™ and are inferred or derived from high-level or low-level requirements.

[0103] As shown in FIG. 4E, the define requirement GUI 420 includes a

Requirement Name field 421 that can be used to enter the name of the requirement being defined, Requirement Type radio buttons 422 that can be used to select whether the requirement being defined is a derived (DV) or low-level (LL) requirement, and a Reference Requirement drop-down menu 423 that can be used when defining low-level requirements to select the high-level requirement with which the low-level requirement is associated (otherwise "None (DV Requirement)" can be selected). The define requirement GUI 420 also includes a Requirement Number field 424 that can be used to enter the number of the requirement being defined. In one embodiment, each requirement for the project requires a unique identification number, which can be automatically filled in by TBmanager™. The define requirement GUI 420 further includes a Requirement Document Path field 425 that can be used to enter the path to a document detailing the requirement being defined (the Browse button can be used to locate the document), a Requirement Body field 426 that can be used to enter a brief description of the requirement being defined, a Clear button 427 that can be used to clear all fields in the define requirement GUI 420, and a Create LL/DV Requirement button 428 that can be pressed to create the new requirement. In one embodiment, TBmanager™ can automatically use values specified in a template when importing requirements into the project as values for the desired code coverage for the new requirement. Newly defined low-level or derived requirements can be displayed in the Project Tree 412.

[0104] During the life span of a project, it might be necessary to dismiss or ignore a requirement so that it will no longer be considered for verification purposes. A user can select a requirement to be de-allocated in the Project Tree 412 via the project GUI 408 and can de-allocate the selected requirement using a De- allocate/Re-allocate Current Requirement button 429 via the define requirement GUI 420. The De-allocate/Re-allocate Current Requirement button 429 can be configured as a context-sensitive button with respect to the selected requirement so that it toggles between "De-Allocate Current Requirement" and "Re-allocate Current Requirement" as appropriate. Thus, a user can re-allocate a de-allocated

requirement in a similar manner by selecting the de-allocated requirement in the Project Tree 412 via the project GUI 408 and can re-allocate the selected

requirement using the De-allocate/Re-allocate Current Requirement button 429 via the define requirement GUI 420.

Assign Users View

[0105] Having setup the roles and users of the project, users can be assigned requirements to work on by selecting the Assign Users tab. FIG. 4F illustrates a GUI 430 that can be displayed when the Assign Users tab is selected. Using the assign users GUI 430, a user having the necessary permission can assign users to requirements and create sibling requirements. As described herein, a sibling requirement can be created in TBmanager™ for the purposes of requirement diversification and task management and represents a copy of a high-level, low-level or derived requirement for the project. A requirement that is to be assigned can be selected from the Project Tree 412 via the project GUI 408 or from a Current Requirement drop-down menu via the assign users GUI 430.

[0106] The assign users GUI 430 includes an "Assigned to this Requirement" field having a User field 431 that can display a name of a user assigned to the current requirement and a Role field 432 that can display the role assigned to the user. The assign users GUI 430 also includes an "Assign User" field having a Filter by Role drop-down menu 433 that can be used to identify the users 435 for the project who are available for selection based on their corresponding role 434. An Assign to Requirement button 436 can be selected to assign a selected user from the identified users 435 to the current requirement.

[0107] To finish the assignment and create a sub-project for the user, the Save button 414 can be selected via the project GUI 408, followed by the Update Sub- Projects button 410b. In one embodiment, a directory named "Sub-Projects" can be established in the project directory to contain all of the users' sub-projects. Each user can have a separate sub-projects directory that can be automatically created when first assigned a requirement. Users can then open their respective sub-projects to work on assigned requirements. The users can copy their sub-project directories to different machines (e.g., their own workstations or laptops with TBmanager™ installed) to work on assigned requirements. Users can then launch TBmanager™ on their machines, select the Open Project button 410a via the project GUI 408, navigate to their sub-project directory, and select the appropriate sub-project to work on. Users can be asked to login by entering their name. The project GUI 408 can then refresh itself to display the user's project and the assigned requirements.

[0108] The assign users GUI 430 can also be used to create a sibling

requirement, which is a copy of an existing high-level, low-level or derived requirement. The sibling requirement can be identical to the corresponding high- level, low- level or derived base requirement except for a unique identifier assigned to the sibling requirement. A sibling requirement can duplicate a base requirement thread at the time the sibling requirement is created. In this way, sibling requirements can enable a user to assign the same requirement to multiple users having different roles (a sibling cannot be assigned to two users of the same role).

[0109] To create a sibling requirement, one of the users 435 displayed via the assign users GUI 430 can be selected and assigned to the sibling requirement by selecting a Create Sibling Req + Assign button 437. In one embodiment, the user assigned to the sibling requirement should have a different role than the user assigned to the base requirement. A newly created sibling requirement can be viewed via the project GUI 408 and displayed in the Project Tree 412 as a child of the base requirement. Only users with permission to Make Sub-Projects should be enabled to create sibling requirements.

[0110] Because sibling requirements can be considered exact copies of a corresponding base requirement, if the base requirement changes, then all of its associated sibling requirements should be de-allocated, as described herein. Then, new sibling requirements of the modified base requirement can be created and assigned to the appropriate users. If the base requirement has a new procedure assigned to it, has its requirement body changed, or any other change happens that might affect the conditions under which the base requirement can be verified, new sibling requirements should to be created.

Map Procedures View

[0111] FIG. 4G illustrates a GUI 438 that can be displayed when the Map

Procedures tab is selected. Having added source code files developed by the users to the project, as described herein, the map procedures GUI 438 can be used to select an added source code file, analyze the selected source code file for available procedures, and map selected procedures to a current selected requirement. The Project Source Files drop-down menu 439 can be used to select a source code file that has been added to the current project and return a list of procedures 442 found in the selected source code file. For example, the LDRA Testbed™ tool can be invoked to analyze the selected source code file and return the identified list of procedures 442 to TBmanager™.

[0112] The selected source code file can also be analyzed statically and/or interactively for conformance with project coding rules and quality metrics by selecting the Analyze Procedures button 440 and Analyze Interactively button 441, respectively. The LDRA Testbed™ tool can also be invoked to perform the static and/or interactive analysis of the selected source code file. If interactive analysis is desired, the user can perform code review, quality review, and design review analysis. Upon completion of the analysis, the map procedures GUI 438 can display the identified procedures 442 found in the selected source code file. Using the Map to Current Requirement button 444, the user can map particular identified procedures 442 to the current requirement, which can be selected using the Current Requirement drop-down menu or the Project Tree 412 via the project GUI 408. Similarly, the Unmap Selected button 443 can be selected to unmap particular identified procedures 442 from the current requirement. Having mapped procedures to requirements, the user can select the Procedures tab to view a list of the procedures mapped to the current requirement.

Procedures View

[0113] The user can select a mapped procedure of a current requirement and view its corresponding input and output (I/O) variables via a procedure GUI 445, shown in FIG. 4H. The procedures GUI 445 includes a Select Procedure drop-down menu 446, which can be used to select a procedure from those procedures that are mapped to the current requirement. The current requirement can be selected from the Current Requirement drop-down menu or from the Project Tree 412 via the project GUI 408. As a result of selecting a mapped procedure, the procedures GUI 445 can be updated to display the I/O variables of the selected mapped procedure in the I/O Variables field 447. Additionally, the procedures GUI 445 includes a Desired Coverage field 449, which can be used to modify the desired code coverage values (e.g., Statement, Branch, MC/DC, and Path coverage values) for the current requirement, and a Coverage Achieved at Verification field 450, which can be used to view the achieved coverage after unit testing. The Unmap This Procedure button 448 can be selected to unmap the selected mapped procedure from the current requirement.

[0114] Once procedures have been mapped to requirements, unit testing can be initiated. First, a requirement having mapped procedures to be tested can be selected either from the Project Tree 412 or the Current Requirement drop-down menu 409 via the project GUI 408. Next, to initiate the unit test, the source code file containing the procedures that are mapped to the selected requirement can be selected, followed by the Unit Test button 41 Of. An external unit test tool can then be invoked to perform the unit test. For example, LDRA TBrun™ is a unit test tool that can be invoked via the LDRA Testbed™ tool. Using the external test tool, test cases for the mapped procedures can be created. A mapped procedure to be tested can then be selected, inputs and expected outputs for the test case can be entered, and the test case can be run.

[0115] If results of the test case(s) are satisfactory and desired code coverage is achieved, completion of requirement verification should be confirmed. At least one test case for each mapped procedure for a requirement should be performed before confirming completion of requirement verification. After closing the external unit test tool, TBmanager™ can refresh the Project Tree 412 to display the requirement as verified (e.g., the corresponding requirements icon can be displayed without the "X" symbol). The project manager can now review the unit test information for the project to assess the users' work.

Verification View

[0116] Once a user has performed unit testing on the mapped procedure(s) for a requirement, the requirement can be displayed as "verified" in the Project Tree 412, shown in the project GUI 408. Because the unit testing of the mapped procedure(s) may not have achieved the desired coverage, however, the project manager, or other user(s) having the necessary permission, should review the results of the unit testing and decide whether the requirement should actually be considered verified.

[0117] Depending on the permissions assigned to a user, the user can verify whether a requirement has met the desired code coverage by selecting the

Verification tab to access a verification GUI 451 , shown in FIG. 41. To verify a requirement, the user can select the requirement to be verified from the Project Tree 412 via the project GUI 408 or from the Current Requirement drop-down menu via the verification GUI 451. The verification GUI 451 includes a Details field 453 displaying the current status of the selected requirement 452. The Details field 453 indicates the user assigned to the selected requirement 452 and their role, the expected code coverage, and the achieved code coverage, which can be displayed according to percentages of mapped procedures achieving the desired coverage. If the user is satisfied with the coverage achieved for the selected requirement the user can press the Verify button 454 to maintain the current status of the selected requirement as verified. However, if the user is unsatisfied with the coverage achieved for the selected requirement, the user press the Un-verify button 455 to change the current status of the selected requirement to unverified. Because un- verifying a requirement modifies that requirement, the user should update any sub- projects associated with the requirement.

[0118] With respect to verification of sibling requirements, a sibling requirement acts much like a low-level requirement. That is, in order for a base requirement to be considered verified, all of its sibling requirements must be verified first. For example, if a developer user has been assigned a low-level requirement having two sibling requirements, one for an IVV user and another for a QA user, the developer cannot indicate the low-level requirement is verified until the IVV and QA users indicate the corresponding sibling requirements are verified.

[0119] An exemplary usage scenario for TBmanager™ is as follows. First, the project manager can set-up a project based on captured high-level requirements, create low-level, derived and sibling requirements (if appropriate), and assign requirements to users. Users can check-out their respective sub-projects, established when the project manager assigns requirements to the users. That is, the users can make a copy of their sub-projects for the purpose of performing remote operations on the sib-projects. Users can modify the sub-project by mapping procedures and testing and analyzing source code, among other tasks. Users can then check-in their modified sub-projects. That is, the users can copy the updated contents of the sub- projects back into the project's directory tree. The project manager can

subsequently log-in and obtain a complete and current view of all aspects of the project.

Defect View

[0120] FIG. 4J illustrates a GUI 456 that can be displayed when the Defect tab is selected. In one embodiment, a user can track defects in source code for the project via the defects GUI 456. For example, the defects GUI 456 can be used to track defects (i.e., non-conformances) in source code based on the results of the analyses performed by the static analysis tool. As shown in FIG. 4 J, the user can add a defect to be tracked by selecting the "Add Defect" button 457. Added defects 458 are displayed with information about the defect, including, for example, a defect number, date created, status, and user assigned to the defect, as well as information regarding disposition of the defect. Added defects 458 can be also be selected for editing.

[0121] FIG. 14 is a schematic diagram that illustrates the relationship between logical elements of an embedded process model in accordance with exemplary embodiments of the present invention.

[0122] Referring to FIG. 14, an embedded system development project or software development project, for example, may be separated into logical parts to breakdown a large project into objectives 1350 (e.g., a smaller component of the overall project). Each objective 1350 of the project may be tracked as a view 1355 to document the development process, for example, for mission critical systems development. Objective 1350 may be assigned to (or performed by) a role 1360 (e.g., an entity, team, or person) having the skills and abilities to accomplish objective 1350. An objective may use guidance 1365, such as industry or governmental standards (e.g., DO-254 and DO 178B standards, among others) to complete objective 1350. Objective 1350 may generate or use (e.g., produce or consume) assets 1370 (or work products) to perform activities or task to accomplish objective 1350. Assets generally refer to a specific work product mandated

(required) by an objective. Assets 1370 may use examples 1371, guidance 1372, whitepapers 1373, reports 1374 and reusable assets 1375 such as testing procedures. Asset 1370 may be based on a template 1380 (e.g., a generic version of the asset prior to customization).

[0123] Objectives (or team objectives) generally define a range of activities that a project (e.g., an embedded system development project) can perform (e.g., is required/must perform) in order to produce a certifiable product, and may include the compliance substantiation of the range of activities. Objective may be of different types (e.g., different levels) including nominal objectives and differentiated objectives. Nominal objectives generally refer to objective that may identify project level goals and work products (e.g., assets) to be produced. Differentiated objectives generally refers to objectives that may be defined by a team lead and may include a precedent asset or a predicate asset and include specific tasks (typically derived from guidance 1365) that are (e.g., must be) performed to fulfill Objectives. Objectives and tasks may have time based attributes that may include: (1) a start time for the objective or task; (2) a stop time for the objective or task; and/or (3) a total lapsed time for the objective or task, among others. The time based attributes may be presented in any view (or teams views) and/or in Management Dash Board of EPMB (see FIG. 15 A) and may enable the presentation of time based project management metrics to the project manager, team view leads and/or team members.

[0124] In certain exemplary embodiments, the time based attributes may be applied to each objective and/or task. In other exemplary embodiment, one or more time based attributes may be applied selectively via user input by the project manager, team view leads or team members (that has appropriate permissions). As such, views (e.g., project view, team views and/or member views) may be customized in system 1400.

[0125] FIGS. 15A and 15B illustrate a system 1400 for process management of an embedded system in accordance with exemplary embodiments of the present invention.

[0126] Exemplary embodiments of system 1400 may offer a comprehensive and agile process framework for the development, verification and production management of embedded systems. User-defined processes may be monitored and controlled based on the successful completion of "tasks" and the accomplishment of project "objectives". Integral to the monitoring and successful guidance of these processes may be the lifecycle traceability of assets (results) produced by the execution of tasks and then aggregated by TBM 1500 in a Lifecycle Traceability Matrix (LTX) 1442 of Embed-X repository 1441.

[0127] Exemplary embodiments of system 1400 may encompass requirements authoring and requirements capturing capabilities. Both system and development requirements (software and hardware) may be referenced. These requirements are managed as "baselines" that are extended into asset baselines encompassing

Hardware, System Engineering, Formal Design, Architecture, Source Code and

Test. The totality of these baselines are coordinated, synchronized and persisted as a production baseline. [0128] Referring to FIGS. 15A and 15B, system 1400 may includes a process manager (PM) 1405 including an embedded process management board (EPMB) 1410, a change management board (CMB) 1415, a document management board (DMB) 1420, a connector management board (CMBD) 1425 and a production management board (PMB) 1430. EPMB 1410, CMB 1415, DMB 1420, CMBD 1425 and PMB 1430 and EmbedX software backplane 1435 execute in hardware server or computer 1401 of system 1400. System 1400 may store information in memory storage or repository 1441.

[0129] In certain exemplary embodiments Embed-X backplane 1435 may be a server that includes Embed-X management "boards". The EmbedX backplane 1435 may be scalable to serve from 1 to several hundred users and may provide a single management platform for the multiple and varied activities of an embedded system (or software) development, verification and production.

[0130] The software server may process (e.g., EPMB 1410, CMB 1415, DMB 1420, CMBD 1425, PMB 1430 and EmbedX software backplane 1435) for the exemplary system 1400 may be implemented in an Eclipse tool. Memory or repository 1441 may be a database server or other storage device.

Software Overview

[0131] TBM 1500 may manage and control system 1400 (e.g., the Embed-X framework) from an operational and functional perspectives. TBM 1500 may be the hub for Embed-X activities (e.g., all activities), which may occur across a broad range of tools and desktops and as a collector of assets and artifacts produced in the course of a product life cycle.

[0132] TBM 1500 may include a Relationship Engine (RE) 1501 and an Object Manager (OM) 1502. RE 1501 may track all inter-object relationships and may store them in a way that provides retrieval of relationship information. TBM 1500 may query RE 1501 with any combination of objects or relationships, and RE 1501 may efficiently provide, for example, how or whether those objects are related, and/or whether any objects exist with a given relationship. Tracking relationships with RE 1501 may facilitate creation of new views for TBM 1500 because creation of a new view becomes the selection of a project element and which ones of the inter-object relationships to present in a new view. For example, System Engineering (SEV) 1455 may present an objective and its "task-for", "asset-of" , and "artifact-of ' relationships. RE 1500 may handle changes to relationships that happen in member views (subprojects) and may keep those changes synchronized across all user projects. RE 1501 may allow multiple users to manipulate their subprojects independently of each other and have those changes merged together automatically. Conflicts which cannot be automatically resolved may be handled by the project manager or Team View Lead (TVL), for example, as change tasks.

[0133] OM 1502 may maintain a list of objects and their attributes, and may store them in a way. that provides retrieval of the objects and their attributes. TBM 1500 may query OM 1502 with any combination of objects or attributes, and OM 1502 may efficiently provide which objects have the attributes, and/or which objects have an attribute with a particular value, among others. OM 1502 may allow users to change the same objects in their respective member or team views freely by automatically synchronizing changes to attributes. When an attribute is changed in the member or team view, a change history may be maintained, which may be merged with change histories from other member or team views. If the change histories align, TBM 1500 may make the change for all views automatically. If there is a conflict in the change histories (e.g., a requirement's name is changed to "Light Automation" in one view and "Lighting Automation" in another), OM 1502 allows the project manager or TVL to handle the conflict by selecting an attribute change, delegating the selection of an attribute change or rejecting all of the possible changes and notifying via a defect report CMB 1415.

[0134] TBM 1500 may provide an overview of objectives to TVL and/or the Project Manager with team views 1445. Objects may be designated as assets, artifacts and project documents of a team view 1445 in RE 1501, either by import from EPMB 1410 or from within TBM 1500. Objectives may be associated with team views in RE 1 01. Each objective may in turn have its own tasks, assets, and artifacts. The tasks, assets, and artifacts of a particular objective are related via RE 1501.

[0135] Relationships are established in the RE 1501 with a call to

RelationshipEngine::relate(). The code below illustrates how the inputs may be related to a team view x: relationshipEngine->relate (assetl.uid (), input-asset-of", teamViewX. uid 0 ) ;

relationshipEngine->relate (asset2.uid (), input-asset-of", teamViewX . uid 0 ) ;

relationshipEngine->relate (assetN.uid (), input-asset-of", teamViewX. uid 0 ) ;

relationshipEngine->relate (artifactl . uid ( "input-artifact-of", teamViewX . uid ( ) ) ;

relationshipEngine->relate (artifact2.uid ( "input-artifact-of", teamViewX . uid ());

relationshipEngine->relate ( artifactN. uid ( "input-artifact-of", teamViewX. uid ());

relationshipEngine->relate (prjDocl.uid (), input-prj doc-of" ,

teamViewX. uid ());

relationshipEngine->relate (prjDoc2.uid (), input-prjdoc-of",

teamViewX. uid ( ) ) ;

relationshipEngine->relate (prjDocN.uid (), input-prj doc-of" ,

teamViewX. uid ( ) ) ;

[0136] Objectives and their tasks and outputs are related in a similar way. The code below illustrates the relationship among objectives, tasks and outputs:

relationshipEngine->relate (taskl_l.uid (), "task-of", objectvl.uid ()) relationshipEngine->relate (taskl_2.uid (), "task-of", objectvl.uid ()) relationshipEngine->relate (taskl_N.uid (), "task-of", objectvl.uid ()) // establish an asset of objectvl

relationshipEngine->relate (someAsset.uid (), "asset-of", objectvl.uid () relationshipEngine->relate (task2_l.uid (), "task-of", objectv2.uid ()) relationshipEngine->relate (task2_2.uid (), "task-of", objectv2.uid ()) relationshipEngine->relate (task2_N.uid (), "task-of", objectv2.uid ()) // establish an asset of objectv2

relationshipEngine->relate (someOtherAsset.uid (), "asset-of", objectv2.ui ( ) ) ;

[0137] When TBM 1500 populates team view X, it retrieves the inputs:

// get input assets

AssetUIDs teamViewXAssets = relationshipEngine->related (teamViewX. uid

"input-asset-of") ;

// get input artifacts

ArtifactUIDs teamViewXArtifacts = relationshipEngine->related

(teamViewX. uid (), "input-artifact-of") ;

// get input project documents

ProjDocumentUIDs teamViewXProj Docs = relationshipEngine->related

(teamViewX. uid (), "input-prjdoc-of") ;

[0138] TBM 1500 may then pass the retrieved UIDs on to OM 1502 to get information for the GUI: // add each input asset to the GUI

TBwcs assetName;

for (int i = 0; i < teamViewXAssets . size (); ++i)

{

if (objectManager->getAttribute (teamViewXAssets . at (i), "Name", assetName) == OMResult::e Success) addlnputAssetToTeamView (assetName) ; [0139] When a user opens a subproject, the user may select a member view. The member view may be based on a team view, with the user able to view (e.g., only able to view) the assigned tasks, along with the objective that the task is linked to or the objective that the task is for, and the input artifacts, assets, and project documents from the team view.

[0140] If the task is an authoring task, then TBM 1500 or another tool such as IRQ A, may be used to generate the assets, which are related to the authoring task, which in turn relate the authoring task to the objective. Some assets may be related to the task automatically (e.g., requirements authored in IRQA), while others may be manually related to the task via a drag and drop. Assets are related to tasks in the same way as objectives and team views, as illustrated below:

relationshipEngine->relate (authoredAsset.uid (), "asset-of", taskl_l.uid (') ) ;

[0141] If the task is a validation task, the member view may include the asset to be validated. TBM 1500 or another tool may be used to generate artifacts to support validation. Defect reports may be generated by team members or TVL to correct problems discovered during validation.

[0142] TBM 1500 knows which objects to provide to each member view, and is able to safely share these objects amongst its member views. The safeguards in RE 1501 and OM 1502 allow TBM 1500 to provide full access to objects (e.g., all objects), if desired. In most cases, the shared objects may be made read-only to minimize conflicts and enforce good practice. For example, when performing a validation task, the validator should not change the asset being validated. Instead, the validator may generate a defect report to force the original author to correct the problem. OM 1502 may provide a locking mechanism which may guarantee that an object may not be changed. TBM 1500 may uses the locking mechanism to ensure, for example, that the validator does not alter the asset to be validated, as illustrated below:

ob ectManager->lockObject (assetToBeValidated.uid (), true); [0143] Once locked, an object may only be unlocked by the OM that locked it. Each user's project has its individual OM, which imports and exports objects to and from the other project OMs. This ensures that when a TVL assigns a validation task and locks the asset, the asset may not be changed until the TVL allows it to be changed. TBM 1500 may automatically handle (e.g., without user intervention) the locking of assets when the assets are ready for validation, and may unlock the assets if there are outstanding defect reports.

[0144] TRTs are a kind of task shared by groups of users and may be verified by way of a voting system. A vote is an object that records who voted, when they voted, and what they voted (yes or no). Below is exemplary code for implementing the voting object:

TBwcs newVote = getNewVoteld ();

obj ectManager->insert (newVote);

objectManager->setAttribute (newVote, "user", currentUserUid ());

objectManager->setAttribute (newVote, "time", currentTimeStamp ());

objectManager->setAttribute (newVote, "vote", "yes") ; // or "no"

relationshipEngine->relate (newVote, "vote-on", assetBeingValidated.uid ( > ) ;

[0145] When the TVL opens the team view, the votes are collected from the member views. If the most recent vote from each user with a TRT is "yes", then the asset is validated. Below is exemplary code to establish the vote: objectManager->lockOb ect (assetBeingValidated.uid (), false); // unlock the asset so we can set its validation status

obj ectManager->setAttribute (assetBeingValidated.uid (), "validated", "yes") ;

objectManager->lockObject (assetBeingValidated.uid (), true); // lock the asset again

[0146] TBM 1500 may lock the asset after it has been validated to protect against accidental change of the asset, which may then require another round of validation. TATs and Peer Review Tasks are functionally identical to the TRT and may use a similar mechanism.

[0147] EPMB 1410 may configure and setup a development project, may define the development processes and may report on the project status. EPMB 1410 may include a process workflow engine that generates a graphical process model allowing user control and visibility of process activities.

[0148] Although PM 1405 is shown implemented as a set of software boards and a software backplane that is implemented in an Eclipse framework, it is

contemplated that other configurations are possible including implementations using Windows Microsoft Foundation Classes or QT libraries..

[0149] Although a hardware server 1401 is illustrated, one of skill in the art understands that many different hardware architectures for the hardware on which TBM 1500 and backplane software server 1435 may execute including a mainframe system or a client/server system. System 1400 may enable process management functionality for any number of users. As such, one of skill in the art understands that many different software architectures may be implemented with system 1400. The team views described below may operate on any computer (that includes a display) in communicates with system 1400 or on a system integrated with system 1400. For example, it is contemplated that the team views may operate on a mainframe frame terminal on a computer system or on a client via a browser in a client/server environment.

[0150] In certain exemplary embodiments, system 1400 may generate team views 1445 including, for example, a hardware requirements baseline view (HRBV) 1450, a system engineering view (SEV) 1455, a formal design view (FDV) 1460, an architecture view (AV) 1465, an Integrated Development Environment view (IDEV) 1470 and a test view (TV) 1475.

[0151] System 1400 may include, for example, a server 1435 and clients 1481- 1486. Clients 1481-1486 may include one or more display devices. For example, HRBV 1450 may be displayed (viewed) on client 1481, SEV 1455 may be displayed on client 1484, FDV 1460 may be displayed on client 1482, AV 1465 may be displayed on client 1483, IDEV 1470 may be displayed on client 1486 and TV 1475 may be displayed on client 1485. The display and/or ability to write or edit information in the particular view may be based on permissions granted to users, and may be based on their roles in the development project.

[0152] Team views 1445 may be logical partitions that facilitate team

participation in the accomplishment of team objectives (e.g., system engineering or architecture, among others). The logical partitions may be instantiated by the allocation of objectives to a team view 1445 in EP B 1410. Differentiated objective may be assigned within a team view 1445 (e.g., SEV 1455) to a team member (e.g., a team member of the system engineering team).

[0153] System 1400 may organize objectives into the following categories: (1) objectives that mandate (or require) one or more work products or assets; (2) objectives that mandate (or require) validation activities of one or more work products or assets; and/or (3) objectives that mandate (or require) verification activities of one or more work products or assets.

[0154] An asset may include requirements (e.g., functional requirements), architecture, source code, executable source code, or test cases, among others.

System 1400 may use assets as precedents and/or predicates of an objective.

Precedent assets may be used to differentiate work product objectives. For example, the precedent asset for a Low Level Requirement may be a High Level Software Requirement. Predicate assets may be used to differentiate validation and/or verification objectives. For example, an objective that may mandate that a High Level Software Requirement (HLSR) is accurate and consistent may be a validation objective that may uses the HLSR as a predicate for the objective.

[0155] System 1400 may provide physical, functional and operational integrations of multiple tools and capabilities. These may include: (1) requirement traceability tools such as TBreq™ by LDRA, DO-254, Artifacts and ReqTracer by Mentor Graphic, among others; (2) system requirements tools such as IRQA by Visure, DOORS™ by IBM, and TBreq™ by LDRA, among others; (3) design requirements tools such as IRQA by Visure, DOORS™ by IBM, TBreq™ by LDRA, Rhapsody Software by Rhapsody, and SCADE Suite® by Esterel

Technologies, among others; (4) design tools such as LDRA Testbed™ by LDRA, Simulink™ by Mathworks, Artisan Studio™ by Artisan Software Tools, Rhapsody Software by Rhapsody, and Visio by Microsoft, among others; (5) coding tools for C IDE, C++ IDE, JVA IDE, ADA IDE, among others; and test tools such as TBrun by LDRA, LDRA Testbed™ by LDRA, and Coverity™ by Coverity, among others. Within this framework, a user may define a complete and repeatable process that supports the development and certification of a critical system (embedded system or software development) used in industries such as commercial avionics, defense, automotive, nuclear power controls, and medical devices, among others.

[0156] Each asset (e.g., requirements and/or test cases, among others) in system 1400 may be linked to its corresponding physical element, which may be located in LTX 1442. The Embed-X repository 1441 may include LTX 1442. In certain exemplary embodiments, LTX 1442 may include a database, (e.g., a hierarchical database) stored in Embed-X repository 1441 or other storage system. Each artifact (e.g., an output or by-product of a verification or validation task such as reviews, analyses, informal test results and defect reports) in system 1400 may be linked to its corresponding physical element, which may be located in LTX 1442. LTX 1442 may link the project elements (e.g., all of project elements) including assets, artifacts and project documents for a given project into a referenceable and accessible entity.

[0157] LTX 1442 may be viewable in its totality from the project view of TBM 1500 and may be persisted automatically in system 1400. LTX 1442 may be partitioned by individual team views 1445 to permit only the relevant assets, artifacts and project documents to be displayed for a particular team view (e.g., SEV 1455). The relevant assets, artifacts, project documents and other information related to the particular team view (e.g., SEV 1455) may be modified (e.g., added to, deleted from or changed) by the TVL of SEV 1455 and/or team view members of SEV 1455 that may be granted the proper permissions.

[0158] LTX 1442 may provide the basis for Impact Analysis performed by CMB 1415. Traceability among project elements in LTX 1442 may be examined by an impact analysis module 1416 of CMB 1415. Adjacent project elements to the asset to be modified by the change task may be identified as "Suspect Links" which are tracked and resolved to maintain the integrity of LTX 1442 throughout the course of the development project.

[0159] System 1400 may use an Embedded Process Model (EPM) executed within server 1435. EPM may represent synchronization of activities performed in the team views over the course of the project. The EPM may be defined by objectives applied in the context of team views 1445. For example, synchronization of activities by EPM may be defined by the intended progression of activities necessitated to accomplish the objectives associated with each team view 1445. [0160] In certain exemplary embodiments, the EPM may be a meta process model that encompasses one or more literal process models or methodologies such as V-Model, Waterfall or Agile Development, among others. In other exemplary embodiments, the EPM may be a literal process model itself.

[0161] FIG. 15C illustrates an exemplary EPM 1550 in accordance with embodiments of the present invention.

[0162] Referring to FIG. 15C, EPM 1550 may be user customizable Embedded Process workflow model. EPMB 1410 may implement EPM 1550. A user may drag objectives into each view. A view may be represented multiple times with each time containing unique process block(s). One or more process blocks can be assigned to a view. A process block contains at least one objective and an associated task.

[0163] EPM 1550 may include SEV 1455, FDV 1460, AV 1465 IDEV 1470 and TV 1475. EPM may generate a project flow from SEV 1455 to FDV 1460 to AV 1465 to IDEV 1470 and to TV 1475. AV 1465 may be broken down into multiple objectives with multiple team views. For example, IDEV 1470 may include: (1) a first IDE view 1470A with the objectives associated with implement prototype/implement component; (2) a second IDE view 1470B with the objectives associated with design verification testing; (3) a third IDE view 1470C with the objectives associated with code review; and (4) a fourth IDE view 1470D with the objectives associated with change management (e.g., adding to source code baseline). TV 1475 may be broken down into multiple objectives with multiple team views. TV 1475 may include: (1) a first test view 1475A with the objectives associated with a test readiness review; (2) a second test view 1475B with the objectives associated with integration testing; (3) a third test view 1475C with the objectives associated with software system testing; (4) a fourth test view 1475D with the objectives associated with structural coverage testing; (5) a fifth test view 1475E with the objectives associated with residual coverage testing (to achieve coverage not achieved during 1475D). SEV 1455 may be broken down into multiple objectives with multiple team views. SEV 1455 may include: (1) a first system engineering view 1455A with the objectives associated with authoring high level requirements; and (2) a second system engineering view 1455B with the objectives associated with system validation.

[0164] FIG. 16 illustrates creation of views in system 1400 of FIGS. 15A and 15B.

[0165] Referring to FIG. 16, a project administrator or project manager for the development project may initiate the development project at server 1435. EPMB 1410 may display a Graphical User Interface (GUI) for the creation of each of the views (e.g., team views 1445) of the development project. The project manager may choose from a drop-down menu 1610 for the creation of views, menu item 1620 indicating a "New" view may be created. Responsive to selection of menu item 1620, the project manager may select to add a new team view (e.g., by selection of menu item 1630 indicating "View Grouping") or a new individual or member view (by selection of menu item 1640 indicating "View"). In certain exemplary embodiments, the project manager may select a name (and associated attributes of the view) from a list or may manually enter the name. In other exemplary embodiments, the project manager may enter the names of each view selected. The project manager may create any number of individual views or team views.

[0166] FIG. 17 illustrates creation of objectives in system 1400 of FIGS. 15A and 15B.

[0167] Referring to FIG. 17, the project manager may choose from a drop-down menu 1710 for the creation of objectives, menu item 1720 indicating a "New" objective may be created. Responsive to selection of menu item 1720, the project manager may select to add a new objective (e.g., by selection of menu item 1730 indicating "Objectiv"). In certain exemplary embodiments, the project manager may select a name (and associated attributes of the objective) from a list or may manually enter the name. In other exemplary embodiments, the project manager may enter the names of each objective selected. The project manager may create any number of objectives.

[0168] FIG. 18 illustrates an association of objectives to views in the system of FIGS. 15A and 15B.

[0169] Referring to FIG. 18, the project manager may choose to associate each of the objectives for the development project with a team view 1445. The project manager may select, for example, SEV 1455 of system 1400. The project manager may view a list of the created objectives and may select one or more objectives. For example, the project manager may select to link an objective 1820 (Establish First Production Baseline (i.e., indicated by "establish_first_prod_baseline")) to SEV 1455 by selecting objective 1820 in the list of created objectives via "Add" button 1840. The project manager may select to link a different objective 1830 (High-level requirements are compatible with target computer (i.e.,

"hlr_compatible_with_target")) by selecting objective 1830 from the list of created objectives via "Add" button 1840. The project manager may select any number of objectives to link to or associate with a member view or team view.

[0170] Each member view or team view (e.g., SEV 1455) may enable the removal of an objective by selection of a previously linked objective (e.g., objective 1820) in scroll down window 1810 and selection of "Remove" button 1850. Each member view or team view (e.g., SEV 1455) may set an order (sequence for the objectives) using "Up" button 1860 and/or "Down" button 1870 to manually move an objective which is selected in scroll down window 1810, responsive to the sort type "Manual" being set for status selection button 1880. In response to the status selection button 1880 being set to the sort type "Automatic", system 1400 may establish the order of the objectives based on preestablished (or predetermined) rules.

[0171] Although the linkage (association) of objectives is shown relative to SEV 1455, it is contemplated that the project manager or any other person granted permission may link any created objective to any created view.

[0172] In certain exemplary embodiments, SEV 1455 may link to objectives including: (1) algorithms are accurate; (2) allocate System Requirements (SR) to hardware and software; (3) associate system test cases with SR; Define High Level (HL) Hardware Requirements (HR) from allocated SR; (4) define SR; (5) define system test cases; (6) develop HL SR from allocated SR; (7) establish first HR baseline; (8) establish first SR baseline; (9) HL requirements are accurate and consistent; (10) HL requirements are compatible with target computer; (11) HL requirements conform to standards; (12) HL requirements are verifiable; (13) Manage change task; (14) Software HL requirements comply with SR; and/or (15) Software HL requirements are traceable to SR, among others.

[0173] FIG. 19 illustrates creation assets in the system of FIGS. 15A and 15B.

[0174] Referring to FIG. 19, the project manager may choose from a drop-down menu 1910 for the creation of assets, menu item 1920 indicating a "New" asset may be created. Responsive to selection of menu item 1920, the project manager may select to add: (1) a new artifact (e.g., by selection of menu item 1930 indicating "Artifact"); ( In certain exemplary embodiments, the project manager may select a name from a list or may manually enter an asset name. In other exemplary embodiments, the project manager may enter the names of each asset selected. The project manager may create any number of artifacts

[0175] FIG. 20 illustrates properties of an objective and different types of associated assets in the system of FIGS. 15A and 15B.

[0176] Referring to FIG. 20, the project manager (or a user granted permission) may associate one or more input assets and one or more output assets with respective objectives. For example, the project manager may view a list of the associated objectives (e.g., including object 2010) and may select to link (associate an input asset) to objective 2010 (e.g., Develop High Level Software Requirement from allocated System requirement (i.e., indicated by

"dev hlsr from allocated sr")) by selecting objective 2010 from the list and adding input asset 2020 (e.g., System Requirement (i.e., indicated by

"system_requirement")) to mandatory input window 2030 via "Add" button 2040. The project manager may select to link a different asset (e.g., an output asset) to objective 2010 by adding output asset 2050 (High level Software Requirement (i.e., indicated by "hl_software_requirement")) to output window 2055 via "Add" button 2060.

[0177] Although not shown in FIG 20, the project manager may link in a similar manner an optional input to objective 2010 using optional input window 2070 and "Add" button 2075.

[0178] Mandatory input asset (e.g., mandatory input asset 2020) may be removed by selection of the previously linked asset in mandatory input window 2030 and selection of the "Remove" button 2080 associated with mandatory input window 2030. Optional input assets may be removed by selection of a previously linked asset in optional input window 2070 and selection of the "Remove" button 2085 associated with optional input window 2070. Output asset (e.g., output asset 2050) may be removed by selection of the previously linked asset in output window 2055 and selection of the "Remove" button 2090 associated with the output window 2055.

[0179] FIG. 21 illustrates properties of an exemplary objective in the system of FIGS. 15a and 15B.

[0180] Referring to FIG. 21, the project manager (or a person granted permission) may desire to view (browse) any given objective and view which assets may be consumed (as inputs) to the objective and which assets may be produced (as outputs) of the objective. The project manager may select objective 2010 (e.g., Develop High Level Software Requirement from allocated System requirement (i.e., indicated by "dev_hlsr_from_allocated_sr")) for viewing in viewing window 2110. Responsive to the selection: (1) the name of objective 2010 may be presented; (2) any team views 1445 (e.g., SEV 1455) associated with objective 2010 may be presented in team view window 2115; (3) status information for the last completed task (e.g., "HL requirements are developed") may be presented in the status information window 2120; (4) any mandatory input assets (e.g., mandatory input asset 2020) associated with objective 2010 may be presented in mandatory input window 2125: (5) any optional input assets associated with objective 2010 may be presented in optional input window 2140; and (6) any output assets (e.g., output asset 2050) associated with objective 2010 may be presented in output window 2150.

[0181] Viewing window 2110 includes role information including the primary performer (the system engineer) of objective 2010 in primary performer window 2130 and any additional performers of objective 2010 in additional performer window 2135; and a description of the activities (workflow or completed tasks) associated with objective 2010 in main description window 2150.

[0182] Although viewing window 2110 is illustrated for an exemplary objective, it is contemplated that such a viewing window may be included for each objective for the development project. [0183] FIG. 22 illustrates team view elements in the system of FIGS. 15A and 15B.

[0184] Referring to FIG. 22, team views 1445 may be configured using EPMB 1410 and may be imported into TBM 1500 from EPMB 1410. Inputs to a team view 1445 may include assets 2210a, 2210b, ...221 On, artifacts 2220a, 2220b, ...2220n and project documents 2230a, 2230b, ...2230n. For example, such inputs may be used as either a precedent of a task (e.g., an asset), an assessment of a task (e.g., an artifact) or as a reference for a task (e.g., a project document). Tasks may create (e.g., produce or generate) new assets and artifacts in the course of meeting

(satisfying) an objective. For example SEV 1455 may have one TVL and a plurality of objectives 2240a, 2240b, ... 2240n. Each of the objectives 2240a, 2240b, ... 2240n may have a plurality of tasks 2241 a, 2241 b, ... 2241 n; 2246a, 2246b, ... 2246n; and 2251a, 2251b, ... 225 In. Each of the objectives 2240a, 2240b, ... 2240n may have associated (linked) output assets 2243, 2248, 2253 and/or artifacts 2244, 2249 and 2254, respectively. The sequencing of tasks (e.g., tasks 2241a, 2241b, ... 224 In) for objective 2240a may represent a work flow such that one task may be a precedent for the next task in a sequence of tasks.

[0185] For example, as shown in FIG. 21 , SEV 1455 may include an objective 2010 to develop high level system requirements from allocated system requirement. Objective 2010 may have input asset 2020 (i.e., system requirement) and may generate an output asset 2050 (i.e., high level software requirement) to satisfy objective 2010. SEV 1455 may also include one or more validation objectives such as ensuring that the high level requirements are: (1) accurate and consistent; (2) compatible with the target computer; (3) conform to standards such a governmental or industry standards including ISO 26262, DO-178B and IEC-61508. These standard may be incorporated into system 1400 by including templates 1380 for asset creation that conform to the standards and also including the standards in guidance 1372 used as reference to verify and validate that a particular task or objective has been met based on the assets and validation/verification artifacts.

[0186] Each team view 1445 may have a TVL. The role of the TVL may include assigning objectives to team members. Because objectives often apply across a complete range of assets (e.g., requirements, software components (CSCs), and/or source code files, among others), the objective assignments may be differentiated by including the particular asset or assets which are to be validated or verified; or in the case of an objective that mandates the creation of an asset, the precedent asset. For example, in AV 1465, a precedent asset may be the low level requirements that are defined in FDV 1460. The precedent asset may be included with the objective in AV 1465 to define a particular CSC.

[0187] After team members have completed work on an objective, the TVL may launch a review task to determine whether the particular objective has been met. Individual team members may each have their own member view which may be different based on roles assigned to the team members. Each team member may be granted different permissions (read permission, write permission, edit permission, or permission to approve satisfaction of an objective) based on their roles within the team. The view hierarchy may include different project viewing levels, for example: (1) a project view that may be used by the project manager or system administrator; a plurality of team views 1445 (each may be assigned to a different TVL; and (3) a member view (each may be assigned to a different team member or a group of team members may share a group task or objective and have a common member view).

[0188] FIG. 23 illustrates user rights and views in the system of FIGS. 15A and 15B.

[0189] Referring to FIG. 23, TBM 1500 may be started in different view modes. When a user 2310 logs into TBM 1500, a list 2320 of available views A, B or C may be displayed. User 2310 may select, for example, view B. TBM 1500 may execute based on the view configuration (i.e., read and write permission is defined for user 2310). User 2310 may have different permissions for different views A, B and C in list 2310. For example, view C includes only a read permission and views A and B include both read and write permissions. The list 2320 of available views for any user may be based on access rights of the user for the view. For example, a user that does not have either read or write access to a particular view may not have the view listed for selection. In certain exemplary embodiments, the project management may not have access to views below the project view level and TVLs may not have access to views below the team view levels. In other exemplary embodiments, the project manager and TVLs may have access (permissions) for some or all of the views hierarchically below their respective view levels.

[0190] In certain exemplary embodiments, permissions are based on the role user 2310 has within a user group 2330 as a team member of user group 2330. For example, TVL may establish a user group associated with SEV 1455 and may establish a plurality of roles (e.g., system engineer, quality control, developer and systems analyst, among others). The TVL may assign the users in user group 2330 to a respective role such that permissions may be based on the roles assigned to user 2310.

[0191] FIG. 24. illustrates a system engineering view (SEV) 1455 in accordance with exemplary embodiments of the present invention.

[0192] Referring to FIG. 24, SEV 1455 may be populated by system

requirements, high-level requirements and high-level test cases. Test cases may be imported into system 1400 (e.g., the Embed-X system) or may be defined internally. In some exemplary embodiments, high level requirements may be defined in modeling tools such as Mathworks Simulink™ or IBM Rhapsody. The coupling to these tools may use TBreq™ connectors which provide an interface for Simulink™ or Rhapsody to communicate with system 1400. Configuration management 1480 may include TBreq™ connectors to export the high level requirements to TBM 1500 from, for example, third party tools. An exemplary SEV 1455 is illustrated in TBM 1500. In this example, an objective A-2-2 (i.e., Define derived high level requirements) is assigned to SEV 1455 and may be displayed using a default sorting based on an objective sorting mode (i.e., sorted based on objectives). A precedent asset SS 002 (i.e., System Requirement) may be presented below the objective in the objective sorting mode. An authoring task associated to objective A-2-2 with its corresponding task identifier (TI) and the produced assets of requirements

REQ 0004 and REQ 0005 may be presented below the precedent asset SS 002. The sorted items: objective A-2-2, precedent asset SS_002, the authoring task and assets REQ_0004 and REQ 0005 represent a portion of a hierarchical project tree.

[0193] It is contemplated that in certain exemplary embodiments, items may have an indication (e.g., based on color (green for satisfied and red for not satisfied) or other visual indication) whether the item has been satisfied. For example, the authoring task may be indicated to be satisfied based on a visual indication, such as a check mark symbol, adjacent to the authoring task. In order to satisfy the authoring task (and apply a visual indication next to an item, satisfaction of child items associated with the item must first be satisfied such as the produced assets REQ 0004 and REQ 0005 must be complete (e.g., satisfied) before the authoring task is presented as satisfied.

[0194] Although a single objective and three assets are shown in SEV 1455, it is contemplated that any number of differentiated objectives and any number of asset, artifacts and/or project documents may be linked to (e.g., associated with) a project tree or a view.

[0195] FIG. 25. illustrates a formal design view (FDV) 1460 in accordance with exemplary embodiments of the present invention.

[0196] Referring to FIG. 25, FDV 1460 may be populated by low-level requirements and low-level test cases. Test cases may be imported into system 1400 (e.g., Embed-X system) or defined internally. For procedural systems, functional inputs and outputs and global data usage may be defined. For OO, class may be defined pre & post conditions and invariants. In certain exemplary embodiments, low level requirements may be defined in modeling tools such as Simulink™ or Rhapsody. The coupling to these tools may use TBreq™ connectors.

[0197] An exemplary FDV 1460 is illustrated in TBM 1500. In this example, an objective A-2-4 (i.e., Low level requirements are developed) is assigned to FDV 1460 and may be displayed using the objective sorting mode. The precedent asset REQ_0004 (i.e., System Requirement) may be presented below (e.g., hierarchically below) objective A-2-4. An authoring task associated with objective A-2-4 with its corresponding Task Identifier (TI) and the produced asset requirements

REQ LL 0002 and REQ LL 0003 may be presented below the precedent asset REQ_0004.

[0198] FIG. 26. illustrates an architecture view (AV) 1465 in accordance with exemplary embodiments of the present invention.

[0199] Referring to FIG. 26, AV 1465 may be populated by software design components, prototypes and reviews. AV 1465 may have two dimensions. The first dimension may be that of providing links to design documentation and software configuration index. The second dimension may be that of providing traceability links to modeling tools such as Simulink™ or Rhapsody.

[0200] An exemplary AV 1465 is illustrated in TBM 1500. In this example, an objective A-4.11 (i.e., Software architecture is verifiable) is assigned to AV 1465 and may be displayed using the objective sorting mode. The precedent asset

REQ 0002 (i.e., Cleanliness Factor (O Notes) - Cody, Bill) may be presented below (e.g., hierarchically below) objective A-4.11 as well as component description SDD_004 from the Software Design Document. Validation task may be performed by an assigned team member and a team review task for peer review of a validation task may be performed using the artifacts from the validation task and SDD 004 (i.e., Software Design Document).

[0201] FIG. 27. illustrates an IDE view (IDEV) 1470 in accordance with exemplary embodiments of the present invention.

[0202] Referring to FIG. 27, IDEV 1470 may be populated by source code and code reviews. An exemplary IDEV 1470 is illustrated in TBM 1500. In this example, an objective A-5.6 (i.e., Source code is accurate and consistent) is assigned to IDEV 1470 and may be displayed using the objective sorting mode. The precedent asset REQ 0002 (i.e., Cleanliness Factor (O Notes) - Cody, Bill) may be presented below (e.g., hierarchically below) objective A-5.6 as well as component description SDD-004 and its source code SCI 0. The peer review. task performed on source code files Zone.cpp and Tunnel.cpp may also be presented below objective A-5.6. A code review task, which automatically applies a complete set of coding rules to the source code, may be performed in conjunction with the peer review task.

[0203] FIG. 28. illustrates a test view (TV) 1475 in accordance with exemplary embodiments of the present invention.

[0204] Referring to FIG. 28, TV 1475 may be populated by software and system integration test cases. An exemplary TV 1475 is illustrated in TBM 1500. In this example, an objective A-7.4 (i.e., Test coverage of low level requirement) is assigned to TV 1475 and may be displayed using the objective sorting mode. The base Asset REQ 0002 (i.e., Low Level Software Requirement) may be presented below objective A-7.4. A unit test task may include two test case identifiers, TCI and TC2 and may be presented as test articles used to verify REQ_0002. A first test case identifier TCI of the unit test task may include a time based attribute (e.g., total elapsed time) that provides an indication of the elapsed time since the cleaning associated with the test article 1. A second test case identifier TCI of the unit test task may also include a time based attribute that provides an indication of the elapsed time since the cleaning associate with the test article 2.

[0205] Although the teams view are presented sorted in the objective sorting mode, it is contemplated that other sorting arrangements are possible including by assets. The project trees may be sorted by input assets, objectives, tasks and output asset in that sequence. For example, in a default mode (i.e., the objective sorting mode) a list of all the objectives in a particular team view may be presented and under each objective, inputs and outputs asset may be presented. In another mode, any individual asset (e.g., requirements, test cases, source code, among others) may be listed and associated with objectives that are presented underneath.

[0206] FIG. 29. illustrates an association of project documents to objectives in the system 1400 of FIGS. 15A and 15B.

[0207] Referring to FIG. 29, project documents, (e.g., which are references for tasks) may be associated with objectives. From a list 2910 of project documents 2920a, 2920b, ... 2920n associated to a team view 1445, a user (not shown) may add (or drag and drop) a project document (e.g., project document 2920a) onto objective 2930. Responsive to the dropping of the project document 2920a onto objective

2930, TBM 1500 may create a table of contents 2940 which lists sections (e.g., all of the sections) of project document 2920a. Particular sections (e.g., sections 2.2, 3.1, 3.1.1 and 3.1.2) may be selected by a user via checkboxes and may be associated with objective 2930. For example, a display may present table of content 2940 of project document 2920a and may include a plurality of sections. A determination may be made, via user input, as to which sections of project document 2920a are applicable to objective 2930. TBM 1400 may associate the applicable sections (e.g., sections 2.2, 3.1, 3.1.1 and 3.1.2) of project document 2920a with the respective objective 2930. Whenever the objective within a project or subproject is used within system 1400, sections 2.2, 3.1, 3.1.1 and 3.1.2 of project document 2920a may be referenced to differentiated objective 2930. [0208] FIG. 30 illustrates a TBM 3000 communicating with a third party tool 3010 via a plug-in module 3020.

[0209] Referring to FIG. 30, system 1400 may include TBM 3000 and TBM application program interface (API) 3030. A third-party tool 3010 (e.g., IRQA) may include a plug-in module 3020 to communicate with TBM 3000 via TBM API 3030. IRQA is a Requirements Definition and Management (RDM) tool designed to provide support to the Requirements process of a development project and is available from Visure (on the web at visuresolutions.com). In the context of system 1400 (e.g., the Embed-X system), IRQA may be used to support the requirement development and validation process, to define requirements and test cases and to manage traceability information. Plug-in module 3020 (e.g., Embed-X LDRA Plug- in) may interface Visure IRQA 3010 and TBM 3000. Plug-in module 3020 may be installed in IRQA and may use TBMAPI 3030 to exchange data between plug-in module 3020 and TBM 3000. This data exchange may be bidirectional.

[0210] IRQA 3010 may send information (e.g., requirements, test sequences and traceability information) to TBM 3000. The sent information may be displayed in TBM 3000 directly or stored in LTX 1442.

[0211] FIGS. 31 A and 31 B illustrate requirements and their traceability within IRQA 3010 and subsequent to processing by plug-in module 3020 in IRQA for export to TBM 3000.

[0212] Referring to FIG 31 A and 3 IB, the relationship in IRQA 3010 of System Requirements SS_001 to SS_003 and High-Level Requirements REQ_0001 to REQ_0015 is different in IRQA 3010 from TBM 3000. IRQA 3010 uses a relational database with relational tables to store project elements which IRQA 3010 tracks for requirements management. TBM 3000 may store its project elements in a hierarchical data format to provide efficient retrieval of hierarchical project tree information of the project elements. Plug-in module 3020 may convert between the project elements in the relational format of IRQA 3010 and the hierarchical format of TBM 3000. Plug-in module 3020 may also function as an exception processing module to process exception cause by discrepancies between IRQA 3010 and system 1400. For example, plug-in module 3020 may establish (retrofit) requirements into IRQA 3010 when the original requirements were setup externally (e.g., in system 1400).

[0213] In certain exemplary embodiments, TBM 3000 and plug-in module 3020 may catalog the source of requirements (e.g., as imported from IRQA 3010) in order to facilitate proper handling of information (requirements, test sequences and validation tasks, defect reports, and traceability information) across both system 1400 and IRQA 3010. For example, a change to a high level requirement in IRQA 3010 may be propagated to TBM 3000 for proper handling in TBM 3000 and as requirements are satisfied within TBM 3000, the project elements and status information for validating the requirements may be exported to IRQA 3010 via plug-in module 3020 to automatically update (without user intervention) IRQA 3010 regarding its requirements.

[0214] FIGS. 32A, 32B and 32C illustrate importation of verification tasks and defect reports from TBM 3000 into IRQA 3010.

[0215] Referring to FIG. 32A, 32B and 32C, because IRQA 3010 does not include a facility to link project documents and artifacts to assets and may only report status of the assets (e.g., as passed or failed), plug-in module 3020 or TBM 3000 may remove the project documents and artifacts associated with each asset (e.g., the validation task or defect report) and may provide (e.g., may only provide) the status for the assets. For example, validation tasks and status of the validation tasks may be propagated to IRQA 3010 from TBM 3000 via TBMAPI 3030 and Plug-in module 3020 so that each system may maintain current project elements.

[0216] In certain exemplary embodiments, plug-in module 3020 may displays a toolbar (not shown) with at least two buttons in the Requirements view. A first button may allow a user to export requirements to TBM 3000 for a selected project. In case the selected project does not exist in IRQA 3010, the project may be created using a second button that enables input by a system administer or project manager of a file name of the project (and its location) and a name of the project manager.

[0217] FIG. 33 illustrates methods of managing import and export of project elements using plug-in module 3020 of IRQA 3010.

[0218] Referring to FIG. 33, after a user selects a destination TBM project, the user may select one of the block diagrams listed in drop-down window 3300. For example, the user may select the Embed-X Architecture block diagram 3310. The Embed-X Architecture block diagram 3310 includes a system requirements block 3320, a software high-level requirements block 3330 and software low level requirements block 3340 that indicate TBM 3000 top level requirements. Every requirement in TBM links to one of these top level requirements which may be then added to TBM 3000 as children.

[0219] Dialog box 3350 may allow the user to select whether all the elements contained in blocks 3320, 3330 and 3340 of block diagram 3310 for the selected project may be exported, or whether only particular blocks 3320, 3330 or 3340 selected in window 3360 by the user may be exported. The user may select the "Add", "Update" and/or "Remove" operations to export new requirements, update existing requirements or remove requirements if the requirements do not exist anymore.

[0220] In certain exemplary embodiments, plug-in module 3020 may displays a toolbar (not shown) with at least two buttons in the External view. A first button (i.e., Import Verification Tasks) may allow the user to import LDRA Verification Tasks (e.g., all verification tasks) from TBM 3000 into a verification tasks block. If the verification tasks block does not exist, plug-in module 3020 may create the block during the import process. A second button (i.e., Import Documentation Tasks), may allow the user to import LDRA Document Tasks (e.g., all documentation tasks) from TBM 3000 into a Documentation Tasks (DT) block. If the DT block does not exist, plug-in module 3020 may create the DT block during the import process. For either selection, the user may select the access partition where the project elements may be inserted, as well as the ability to perform "Add", "Update" and/or "Remove" operations on these elements.

[0221] In certain exemplary embodiments, Embed-X Workflow allows users to follow the Embedded Process Model in IRQA 3010 using a workflow attribute (e.g., Process Phases that may identify the phase of a requirement (e.g., architecture phase, code review phase, or formal design phase, among others). The Process Phase may be attached to the requirements (e.g., all requirements) in IRQA 3010 to show the phase of the requirement. A requirement may satisfies (move to another phase of the project relative to the process phases attribute) in the following order: (1) Requirements Engineering; (2) Formal Design; (3) Architecture; (4) coding; (5) Design Verification Testing; (6) Code Review; (7) Integration Testing; and (8) System Testing. For example, a requirement should pass (satisfied) all

Requirements Engineering tasks, Formal Design tasks, and Architecture tasks to be in the coding process phase.

[0222] FIG. 34 is a flow chart illustrating a process management method 3400 for developing an embedded system using a plurality of project views in accordance with an exemplary embodiment of the present invention.

[0223] Referring to FIG. 34, each project view may be assigned to a different entity (e.g., a team, a TVL or another organization). At block 3410, computer 1401 may associate one or more objectives (e.g., objective 2010) with a respective project view (e.g., SEV 1455). At block 3420, computer 1401 may link one or more embedded system deliverables (e.g., source code or a test case, among others) to the one or more objectives (objective 2010).

[0224] At block 3430, for a respective objective (objective 2010): linking, by computer 1401, at least one functional requirement (functional requirement 2020) to the respective objective (objective 2010), and linking, by computer 1401, at least one test result to the respective objective 2010 to verify that the embedded system deliverables linked to the respective objective satisfy the at least one functional requirement. At block 3440, a display (e.g., display of client 1484) may present, in the respective project view (e.g., SEV 1455), status information of the objectives assigned to a respective entity (e.g., status information associated with window 2120).

[0225] Computer 1401 may determine the status information or status from the test results linked to objectives associated with the respective project view, and may indicate whether a functional requirement is verified or unverified. For example, computer 1401 may provide a status of each of the objectives associated with the respective project view which indicates whether each of the objectives (and requirements) is satisfied.

[0226] In certain exemplary embodiments, the project manager may manually compare and/or computer 1401 may automatically compare one or more embedded system deliverables with a corresponding test for each objective of the respective project view and computer 1401 may determine the status information of the objectives associated with the project view based on a result of the comparison.

[0227] Presentation of status information may include displaying objectives, corresponding tasks and functional requirements associated with the respective project view, as project view items and indicating, for respective project view items whether the respective items are satisfied. For example, the display of project view items may include displaying the project view items in a hierarchical project tree, as items of the hierarchical project tree and the indication of whether the respective items are satisfied may include visually indicating, for respective items of the hierarchical project tree, whether the respective items are satisfied.

[0228] Computer 1401 may associate one or more tasks with each respective objective. The associated tasks may define a workflow to accomplish the respective objective. For example, a sequence of tasks which are successive to each other may define a workflow such that the output of one task may be used as the input to the next task. Computer 1401 may define the workflow based on sequencing of the associated tasks and may develop the one or more embedded system deliverables in accordance with the defined workflow. Each of the tasks may be associated with one or more verification rules such as industry and governmental standards for testing hardware and software components, Computer 1401 may designate a respective task as being completed after the verification rules associated with the respective task are satisfied.

[0229] In certain exemplary embodiments, the project manager using computer 1401 may establish a development project by identifying users for the development project and assigning objectives to the identified users to establish the plurality of project views.

[0230] In various exemplary embodiments, computer 1401, with user input, may: (1) create a plurality of roles for the development project based on groups of the users who are designated to perform common actions (such as editing test cases, deriving hardware baseline, or developing source code); (2) assign permissions (e.g., grants to read or write information within a view) to the roles to define the common actions that users in the roles are enabled to perform; and (3) select roles for the users from the plurality of created roles. [0231] In some exemplary embodiments, permissions for a user to undertake activities or tasks may be assigned based on roles of the users, as a members of the particular team, and each role may be set at a different level such that the project manager, for example, may view information project-wide (e.g. at the highest level) and a team member may only have limited visibility to project information within the users team (e.g., the team member may have a lower level view).

[0232] In other exemplary embodiments, an integrated requirements traceability and verification matrix (e.g., LTX 1442) may be generated to dynamically track implementation of the functional requirements and status of the functional requirements for the embedded system. The LTX 1442 may be generated to dynamically track each of the objectives associated with the respective project view and the status of the objectives for the embedded system.

[0233] In certain exemplary embodiments, threads may be used to store functional requirements, for example, by creating a thread for each of the functional requirements such that project elements of the threads may each include a functional requirement for the embedded system, one or more verification rules associated with the corresponding functional requirement and one or more verification results. One or more child threads may be added to a parent thread such that the parent thread is verified after (e.g., only after) the one or more child threads are verified.

[0234] System 1400 may use any number of different types of tasks including: (1) an authoring task to define the functional requirements mandated by the respective objective; (2) a validation task to validate an asset; (3) a peer review task to review or analyze an asset; (4) a design task to develop an asset mandated by the respective objective; (5) a test readiness review task to determine readiness of the embedded system for at least acceptance testing; (6) a data or control coupling analysis task to verify assets as mandated by the respective objective; and/or (7) a change task to effect a change to an asset.

[0235] FIG. 35 is a flow chart illustrating a process management method 3500 for developing program code that meets one or more functional requirements using a project view in accordance with an exemplary embodiment of the present invention.

[0236] Referring to FIG. 35, at block 3510, computer 1401 may associate one or more functional requirements to a plurality of objectives. Each objective may define an assignment of work to one entity. At block 3520, computer 1401

(automatically) or a code tester (manually) may establish one or more code tests which determine whether the program code meets a respective functional requirement. At block 3430, the program code may be validated based on the one or more code tests to generate test results. At block 3540, computer 1401 may store each respective functional requirement together with the associated objective, corresponding code tests and corresponding test results, as a respective unit and, at block 3550, a display may present information from one or more respective units as a portion of the project view.

Exemplary Tasks

[0237] A task is an activity launched from TBM 1500 to meet an objective. Certain tasks are native to a particular Team View 1445. For example, an implementation task may be native to IDEV 1470. Other tasks may be generic tasks used by all of the team views, such as the team review task or the change task. A task may automatically link the assets and the artifacts produced in the course of the development project to a Lifecycle Traceability Matrix. Defined below are different types of exemplary tasks used in system 1400 by TBM 1500. For brevity, Usage scenarios are provided for a portion of these exemplary tasks

Exemplary Authoring Task

[0238] An authoring task may be an iterative task with a unique identifier that links one or more parent requirements such as customer, allocated system or HL software requirements with an activity of defining the requirement (for example in IRQ A) mandated by an objective. The results (one or more Assets) produced by the authoring task (e.g., the one or more requirements) are returned by IRQ A to TBM with the task identifier. The authoring task may be native to the SEV 1455 and FDV 1460.

Usage Scenario

Inputs:

Asset: Customer Requirement

Project Document: System Requirement Standards, Software Development Plan 1. For each Customer Requirement (or group of Customer Requirements) an Authoring Task may be performed to create one or more System Requirements (if Objective exists)

a. User may drag the Customer Requirement under the Objective and may select (e.g., right click) the requirement to spawn the Authoring

Task

2. For each Authoring Task, TBM may generate a unique ID. For each requirement associated with an Authoring task, IRQA may return the unique ID with the requirement update to TBM.

a. TBM may display the requirement(s) under the Authoring Task that fathered the requirement(s).

3. Launching an Authoring Task may then launch IRQA.

Outputs:

Asset: System Requirement

Artifacts: Team Review Comments, Team Analysis Comments, Voting Results,

System Requirements Specification Update

Inputs:

Asset: Allocated System Requirement

Project Document: Software Requirement Standards, Software Development Plan

1. For each System Requirement allocated to Software, (or group of System Requirements) an Authoring Task may be performed to create one or more High Level Software Requirements

a. User may drag the allocated System Requirement under the Objective and may select (e.g., right click) the requirement to spawn the

Authoring Task

2. For each Authoring Task, TBM may generate a unique ID. For each requirement associated with an Authoring task, IRQA may return the unique ID with the requirement update to TBM.

a. TBM may display the requirement(s) under the Authoring Task that fathered the requirement(s).

3. Launching an Authoring Task may then launch IRQA. 4. The process may be repeated if the analysis determines a need of a Derived High-Level Software Requirement

Outputs:

Asset: High-Level Software Requirement, Derived High-Level Software Requirement

Artifacts: Team Review Comments, Team Analysis Comments, Voting Results, Software Requirements Specification Update

Inputs:

Asset: High-Level Software Requirement, Derived High-Level Software Requirement

Project Document: Software Requirement Standards, Software Development Plan

1. For each High Level Software Requirement, (or group of HL Software Requirements) an Authoring Task may be performed to create one or more Low Level Software Requirements

a. User may drag the subject High Level Software Requirement under the Objective and may select (e.g., right click) the requirement to spawn the Authoring Task

2. For each Authoring Task, TBM may generate a unique ID. For each requirement associated with an Authoring task, IRQA may return this unique ID with the requirement update to TBM.

a. TBM may display the requirement(s) under the Authoring Task that fathered the requirement(s).

3. Launching an Authoring Task may then launch IRQA.

4. The process may be repeated if analysis determines a need of a Derived Low-Level Software Requirement

Outputs:

Asset: Low-Level Software Requirement, Derived Low-Level Software Requirement

Artifacts: Team Review Comments, Team Analysis Comments, Voting Results, Software Design Specification Update Exemplary Validation Task

[0239] A validation (Val) task may be determined by a category of objectives that mandate validation activities. A Val task may be generic (e.g., may apply across multiple validation objectives) and may link project documents to a validation activity of a particular asset. A Val task may be used to determine the currency, consistency or appropriateness of a particular work product (asset). A Val task may use project documents (e.g., requirements, and development plans, among others) to substantiate an assessment of the asset.

Views: Any view

Usage Scenario

Inputs:

Asset: Any Asset

Project Document: Any Applicable Project Document

1. A Val Task may be spawned by selecting (e.g., right-clicking) on an Asset.

2. An associated Project document may be dragged under the Val Task to link the Project Document and Val task, reference paragraphs may be identified by selecting (e.g., right-clicking) on project document.

3. The validation assessment may be written by selecting (e.g., right-clicking) the Val Task icon to launch the Word editor.

a. The resulting Word document may be linked to the Val Task.

Outputs:

Artifacts: Team Review Comments, Team Analysis Comments, Voting Results, Updates to applicable Project Documents

Exemplary Team Review Task

[0240] A team review task (TRT) may organize a team of reviewers for review of one or more assets. A TRT may be configured and launched by any user with permission. Comments may be added in TBM Notes entry dialog. Alternatively, a Word document may be associated with a TRT. The TRT may record "votes" of individual reviewers. A named TRT may include a test readiness review; another named TRT may include peer review.

Team Views: Any view

Usage Scenario Inputs:

Asset: Any Asset

Project Document: Any Applicable Project Document

1. The one or more Assets may be selected to be reviewed.

2. Up to a specified number (e.g., about 10) team members may be selected to participate in a TRT.

a. Copies of the selected Assets may be distributed to each team member's subproject.

3. TRT comments may be entered in Notes tab associated with Asset under review.

4. TRT Votes may be entered in the Voting Booth associated with the Asset. a. A log of each Team member name and vote may be recorded.

Outputs:

Artifacts: Team Review Comments, Voting Results, Updates to applicable Project Documents.

Exemplary Team Analysis Task

[0241] A Team Analysis Task (TAT) may organize a team of reviewers around an Asset(s). A TAT may be configured and launched by any user with permission. Comments may be added in the TBM Notes entry dialog. Alternatively a Word document may be associated with a TAT. A TAT may record the "vote" of individual reviewers.

Team Views: Any view.

Usage Scenario

Inputs:

Asset: Any Asset

Project Document: Any Applicable Project Document

1. The one or more Assets may be selected to be reviewed.

2. Up to a specified number (.e.g., about 10) team members may be selected to participate in a TAT.

a. Copies of the selected Assets may be distributed to each team member's subproject. 3. TAT comments may be entered in Notes tab associated with Asset under review.

4. TAT Votes may be entered in the Voting Booth associated with the Asset. a. A log of each Team member name and vote may be recorded.

Outputs:

Artifacts: Team Analysis Comments, Voting Results, Updates to applicable Project Documents

Exemplary Design Task

[0242] The design task may be native to AV 1465 and may launch the production of the one or more assets mandated by an objective A2-3 (e.g. software architecture being developed). The link may be one or more low level requirements with a particular computer software component (CSC). The design task may prompt for a description of how the CSC may conform to the associated LL requirements. The design task may link the associated design data presented in a software design document or a modeling tool

Team View: Architecture.

Usage Scenario

Inputs:

Asset: Low Level Requirement

Project Document: Design Description, Computer Software Configuration Index

1. Assignee from subproject may launch Design Task

a. The Design Task may prompt for the Computer Software Configuration Item (CSCI) identifier (which may be available from the Project Team View and/or Production Baseline).

b. The Design Task may prompt for the Computer Software Component (CSC) identifier (which may be available from Project Team View and/or Production Baseline).

c. The Assignee may drag the associated one or more LL Requirements under the Design Task.

d. The Design Task then may prompt for a description of how the associated CSC conforms to the one or more LL Requirements. e. A link to associated design documentation or model may be established

2. Other Assignees may launch additional Design Tasks to work in their respective subprojects.

Outputs:

Asset: Computer Software Component

Artifacts: Team Review Task, Team Analysis Comments, Voting Results, Updates to Software Design Documents

Exemplary Implementation Task

[0243] The Implementation Task (IT), native to the IDE Team View, may launch the production of the Asset(s) mandated by the Objective (Source Code is developed (A2-6)). The IT triangulates the associated Computer Software

Component (CSC), LL Requirement(s) and Source Code function specifications. The IT may provide a link into the IDE tool used to write, edit and compile the source code Assets. Links to associated object code Assets may be established. Team View: IDE view.

Usage Scenario

Inputs:

Asset: Computer Software Component Description

Project Document: Computer Software Configuration Index, Software Detailed Design Document

1. Assignee from subproject may launch an Implementation Task

a. The IT may prompt for the associated CSC.

b. The IT may prompt for the associated LL Requirements

c. The IT may link the assignees IDE/Editor

d. The assignee may add the produced source code to the IT e. The assignee may map the source code to the one or more LL requirements

2. Other Assignees may launch the same Implementation Task to work in their respective subprojects.

Outputs:

Asset: Source Code, Object Code Artifacts: Team. Review Results, Voting Results

Exemplary Peer Review Task

[0244] The peer review (PR) task (e.g., team review task) may facilitate the review of source code by a team. The code review task systematically may apply coding rules to the source code and may allow the peer review to assess the code against the coding rules and may make more analytical assessments about the state of the software implementation.

Team View: IDE view.

Usage Scenario

Inputs:

Asset: Computer Software Component Description

Project Document: Computer Software Configuration Index, Software Detailed Design Document

1. The source code may be selected to be reviewed.

2. Up to a specified number (.e.g., about 10) team members may be selected to participate in a Peer Review (PR).

a. Copies of the selected source code may be distributed to each team member's subproject.

3. Results from Code Review on source code may be launched and/or may be review.

4. PR comments may be entered in the Notes tab and may be associated with the Source Code under review.

5. PR Votes may be entered in the Voting Booth associated with the source code.

a. A log of each Team member name and vote may be recorded.

Outputs:

Asset: Source Code, Object Code

Artifacts: Peer Review Results, Code Review Results, Voting Results

Exemplary Test Readiness Review Task

[0245] The test readiness review task (TRRT) (e.g., Team Review Task) may determine the readiness of a software system for acceptance testing and a subsequent system validation task. The TRRT may consider the informal testing that has been performed on the software and may ensure that outstanding (e.g., all outstanding)

DR's have been remediated.

Team View: Test view.

Usage Scenario

Inputs:

_ Asset: Source Code and Object Code

Artifacts: Informal test documentation and open Defect Reports

Project Document: Software Test Plan and Software Test Procedures

1. The Software Test Plan and Software Test Procedures may be selected for review.

2. Up to a specified number (e.g., 10) team members may participate in the TRRT.

a. Copies of the test documentation may be distributed to each team member's subproject.

3. TRRT Lead reviews may result from informal testing and may ensure that relevant DR's have been closed.

4. TRRT comments may be entered in the Notes tab associated with the test documentation under review.

5. TRRT Votes in the Voting Booth associated with the Software Test Plan may be entered.

a. A log of each Team member name and vote may be recorded.

Outputs:

Artifacts: TRRT results, Voting Results

Exemplary Data Coupling Analysis Task

[0246] The data coupling analysis task (DCAT) is a verification activity that may be performed using LDRA Testbed™. The DCAT may perform the verification of one or more Assets as mandated by the objective. Test coverage of software structure (including data coupling and control coupling) may be achieved (A7-8). The result of a data object analysis performed on the source code may be returned. Team View: Test view.

Usage Scenario Inputs:

Asset: Source Code

Project Document: Relevant Project Document

1. One or more source code Assets to analyze using the DCAT may be selected.

2. The DCAT run command (invoking Data Object Analysis in LDRA Testbed™) may be selected.

3. Results under DCAT may be retrieved.

4. Team Analysis Task on the DCAT results may be run.

Outputs:

Artifacts: DCAT results. Team Review results, Voting Results

Exemplary Control Coupling Analysis Task

[0247] The control coupling analysis task (CCAT) is a verification activity that may be performed using LDRA Testbed™. The CCAT may perform the verification of one or more assets as mandated by the objective, Test coverage of software structure (including data coupling and control coupling) may be achieved (A7-8).

The result of a Procedure Call Coverage analysis performed on the source code may be returned.

Team View: Test view.

Usage Scenario

Inputs:

Asset: Source Code

Project Document: Relevant Project Document

1. The one or more source code Assets to analyze using the CCAT may be selected.

2. The CCAT run command (invoking Procedure Call Coverage Analysis in LDRA Testbed™) may be selected.

3. Results under CCAT may be retrieved.

4. Team Analysis Task on the CCAT results may be run

Outputs:

Artifacts: CCAT results. Team Review results, Voting Results Exemplary Change Task

[0248] A Change Task (CT) may be created at the Change Management Board (CMB) to effect a change to an asset. A CT may be created to resolve a Defect Report (DR) opened in the course of performing a task. The CT may be assigned to a team view for implementation. A TVL may accept the assignment of the CT and may assign it to a team member for execution or the TVL may reject the CT and return it to the CMB for further consideration.

Team Views: Any view.

Usage Scenario

Inputs:

Asset: Any Asset

Project Document: Any Project Document

1. When a DR is created it may be automatically sent to the CMB.

2. The CMB may determine the Disposition of the DR and may enter it in the Disposition field of the DR.

3. If the CMB determines that an Asset change should be made to remediate the DR, CMB may perform an Impact Analysis on the Lifecycle Traceability Matrix (LTX). All impacted Assets, Artifacts and Project Documents may be flagged and may become Suspect Links.

4. A CT may be created, including the Impact Analysis, and may be assigned to a Team View for implementation.

5. The CT may be accepted or rejected by the TVL. If rejected, the TVL may enter the rational in the CT Disposition field. If the TVL accepts the CT, the CT may be assigned to a Team Member for execution.

6. After completing the execution of the CT, the Team Member may return the CT to the Team View for Disposition by the TVL.

7. If the executed CT's Suspect Links have been addressed and the TVL

approves the CT, the CT may be returned to the CMB for final disposition.

8. Suspect Links may be erased by the CMB upon closure of the CT.

Outputs:

Artifacts: Change Task Data, Impact Analysis, CMB closure Report Exemplar LDRA Tasks

[0249] The LDRA tasks are TBM tasks that may have already been

implemented and may be used by TBM as a part of TBreq™. In system 1400 (e.g., Embed-X system), the tasks may be used to launch the LDRA tool suite and may perform specific verification activities.

Exemplary Code Review Task

[0250] The code review task may launch the LDRA Testbed™ static analysis engine to verify the associated source code against a programming standard. Upon verification, data and reports may be generated to show that a programming standard has been enforced. These results may be linked to the code review task and may be used to check if an objective, to which the task is associated, is met.

Exemplary Quality Review Task

[0251] The Quality Review Task may launch the LDRA Testbed™ static analysis engine to verify the associated source code against a quality standard. Upon verification, data and reports may be generated to show that a quality standard has been enforced. These results may be linked to the Quality Review Task and may be used to check if an objective, to which the task is associated, is met.

Exemplary System Test Task

[0252] The system test task may launch the LDRA Testbed™ dynamic analysis engine which may enable the instrumentation, the execution and the coverage analysis of the associated source code. The system test task may be run on source code that may be compiled and verified as part of a system (e.g., on the host or directly on the target). Test cases may be associated to the system test task and may run while (e.g., during) structural coverage is being measured on the source code. Upon verification, data and reports may be generated to show that the expected source code coverage has been achieved. The results may be linked to the system test task and may be used to check if an objective, to which the task is associated, is met.

Exemplary Unit Test Task

[0253] The unit test task may launch the LDRA TBrun unit testing tool to create unit tests (or re-run saved unit tests) and may run a unit test driver (on the host or directly on the target) on the associated source code. Source code structural coverage may be measured with the unit tests. Upon verification, data and reports may be generated to show the unit tests are giving the expected reports and the expected coverage (if measured). These results may be linked to the unit test task and may be used to check if an objective, to which the task is associated, is met. Exemplary Sub-System Test Task

[0254] The sub-system test task may launch the LDRA Testbed™ dynamic analysis engine to enable the instrumentation, the execution and the coverage analysis of the associated source code. The sub-system test task may run on source code that may be compiled and verified as part of a sub-system (on the host or directly on the target). Test cases may be associated to the sub-system test task and may run while structural coverage is being measured on the source code. Upon verification, data and reports may be generated to show that the expected source code coverage has been achieved. These results may be linked to the sub-system test task and may be used to check if an objective, to which the task is associated, is met.

Exemplary Integration Test Task

[0255] The integration Test Task may launch the LDRA Testbed™ dynamic analysis engine to enable the instrumentation, the execution and the coverage analysis of the associated source code. The Integration Test Task may run on source code that may be compiled and verified as part of a sub-system (on the host or directly on the target). Test cases may be associated to the Integration Test Task and may run while structural coverage is being measured on the source code. Upon verification, data and reports may be generated to show achieved. These results may be linked to the Integration Test Task and may be used to check if an Objective, to which the task is associated, is met.

Exemplary Document Task

[0256] The document task is a task to which external documentation (MS-Word, MS-Excel, pdf, and/or xml, among others) may be attached. This task may be used when verification activities are being performed externally (e.g., outside the system 1400 or the LDRA Tool suite). Results data may be attached to a document task. The document task may be used to check if an objective, to which the task is associated, is met. Exemplary Isolation Unit /Module Test Task

[0257] The isolation unit/module test task is a type of unit test task. This task may launch the LDRA TBrun unit testing tool in the isolation unit/module test mode.

Exemplary Unit Test Only Task

[0258] The unit test only task is another type of unit test task. This task may launch the LDRA TBrun unit testing tool in the unit test only mode.

Exemplary Extreme Test Task

[0259] The extreme test task is a further type of unit test task. This task may launch the LDRA TBrun unit testing tool and may allow (enable) the configuration and execution of extreme test cases.

Exemplary Robustness Test Task

[0260] The robustness test task is an additional type of unit test task. This task may launch the LDRA TBrun unit testing tool and may allow the configuration and execution of robust extreme test cases.

Exemplary V-Table Test Task

[0261] The V-table test task is another type of unit test task. This task may launch the LDRA TBrun unit testing tool and may allow the configuration and execution of dynamic dispatch table (V-table) test cases. The V-table test task may test C++ and Java classes.

Exemplary Custom Task

[0262] The custom task is a task to which external documentation (MS-Word, MS-Excel, pdf, and/or xml, among others) may be attached. This task may be used when verification activities are being performed outside the system 1400 or LDRA Tool suite and the user desires to uniquely name a documentation task. Results data may be attached to a custom task. These results may be used to check if an objective, to which the task is associated, is met.

[0263] Table 1 illustrates to which team views 1445 exemplary tasks may be enabled. Table 1 - Summary of enabled tasks (with x) in each team view. Referring to Table 1, enabled tasks for a team view are indicated below. Team Views

System Formal

Tasks Architecture IDE Test

Engineering Design

Exemplary Enabled Enabled

Authoring

Exemplary Enabled Enabled Enabled Enabled Enabled Validation Task

Exemplary Team Enabled Enabled Enabled Enabled Enabled Review Task

Exemplary Team Enabled Enabled Enabled Enabled Enabled Analysis Task

Exemplary

Enabled

Design Task

Exemplary

Implementation Enabled

Task

Exemplary Peer

Enabled

Review Task

Exemplary Test

Readiness Enabled Review Task

Exemplary Data

Coupling Enabled Analysis Task

Exemplary

Control Coupling Enabled Analysis Task

Exemplary Enabled Enabled Enabled Enabled Enabled Change Task

Exemplary Enabled LDRA Tasks

[0264] Users may provide a way to assign Threads to team members. Each User may receive a personalized subproject, containing the Threads (e.g., only the threads) the project manager or TVL has assigned. The User may have a first and last name and a Role, and may optionally have an email address TBM may use to notify users of changes to their subprojects. A Thread may be assigned to only one User at a time and a Thread may be re-assigned (by any User with the appropriate permissions) as many times as desired. A User may have any number of assigned Threads. Each user may have a Role. A User's role may determine the permissions the User has in the user's subproject. The User may be given a different Role at any time by the project manager. In certain exemplary embodiments, the project manager and/or TVL may be the only User who may add, remove, or modify Users. A User may not be removed while the user has assigned Threads. Each User may only log into their respective subproject. This may include the project manager (e.g., it may not be possible for the project manager to log into a subproject in his role as project manager).

[0265] Roles may serve to group Users (team members) together according to the tasks performed. Roles may determine the activities that are available to a User in the user's subproject. The set of activities a Role may allow are a User's permissions. Roles may only be created, removed, and modified by the PM and/or TVL or assignees based on assignment rules. A Role may not be removed while a User of that Role still exists in the role.

[0266] Threads may be the building blocks of traceability in TBM. A Thread may be analogous to a Requirement, though a Thread may be used by TBM to model Verification Tasks, Low-Level Requirements, and Derived Requirements.

Threads may share one or more of the following properties: (1) a Thread may not be verified until all of its children Threads are verified; (2) a Thread may have 0 or more Verification Groups applied (except for Verification Tasks which have at least one Verification Group); (3) a Thread may not be verified unless it has something to verify (e.g. a child Thread or a Verification Group); (4) a Thread may have only one type; and/or (5) a Thread's UID and number may be unique for the project.

[0267] Threads may have a number of states: (1) deallocated; (2) verified; or (3) suspended. Deallocated Threads may be removed from the Thread hierarchy, and may not affect the verification of its parents. The project may behave as though the Thread doesn't exist. Verification Tasks may not be deallocated (e.g., they may only be suspended).

[0268] Verified Threads may satisfied all of its own Verification Rules, and all the Thread's

Children are also verified. Suspending a Verification Task may absolve the base Thread of the need to complete the verification task. If all of a Thread's

Verification Tasks are suspended, the base thread may be considered verified (e.g., if the base thread has no children). Each Thread other than Verification Tasks (VTs) and Documentation Tasks (DTs) may have any number of parents or children. VTs and DTs may have a parent Thread and no children. The parent of a VT or DT may be referred to as the "base" Thread.

[0269] To create a new Thread object, call tbmThread: :blank(), set the number and type of the Thread using tbmTh read : setNumber() and tbmThread : :setType() and then call tbm Project: :add(). The TBwcs string passed to tbmThread :

sefNumber() may be unique across the project.

[0270] To supply the Thread with a name call tbmTh read : setName(). VT and DT Thread creation may be handled automatically by TBmanager, leaving Low- Level, High-Level, and Derived Requirements available for creation.

[0271] Once Threads have been added to a project, operations may be performed on them, such as linking the thread to other requirements, deallocating the thread, marking the thread as verified/unverified and assigning the thread to users. As a default, a Thread may be assigned to the project's currently logged-in user. Threads may not be deleted; the closest operation to deletion may be deallocation.

Deallocating a thread may cause the thread to be removed from the project and may not affect the verification status of its parents. Deallocated threads may not appear as a Requirement in the TBM project tree. A Thread may be reallocated at any time, and may return to the project with its associated VTs and previous verification status.

[0272] Verification Groups may provide a set of Verification Rules that a Thread may satisfy to be considered verified. Verification Groups may be added to the project, then may be applied to individual Threads to force the Threads to satisfy the Verification Rules belonging to the Verification Group. Any number of

Verification Groups may be assigned to any Thread, except maybe VTs; since VTs may represent the completion of individual Verification Rules and may not be assigned Verification Groups directly. Verification Rules may specify the task to be completed and may restrict who may complete the task. Verification Rules may be either assignee restricted (e.g., the base Thread's assignee performs the task), Role restricted (e.g., any User of a given Role may perform the task), or User restricted (e.g., only a given User may perform the task). [0273] TBM may manage data represented in an XML file as a series of

"blocks". A block generally refers to a portion of XML data that describes an object. API objects may represent blocks directly. Blocks may be acquired by calling blank() on a Block-derived object or from another API object.

[0274] Once a block is managed, the block may not be deleted by calling free(). The project object or another relevant object may be requested to delete the block. A call to free() may only be made if it is determined to abort the addition of a block to the project. For example,User creation may be cancelled by:

tbmUser newUser(&myProject);

// get a blank User block

newUser.blank();

// UI to get a first name, last name for user

newUser . setFirst(firstname) ;

ne wUser . setLast(lastname) ;

// UI asks for email, but end user cancels User creation

// frees user's block memory

newUser.free();

the program may leak memory if call free() is not called as shown in example above. Free may not be called if the user is added to the project by:

tbmUser newUser(&myProject);

// get a blank User block

newUser.blank();

// UI to get a first name, last name for user

ne wUser . setFirst(firstname) ;

newUser.setLast(lastname);

// get Role blocks from the project

tbmRoles projectRoles = myProject.roles();

// UI asks for email and role, and end user clicks OK

newUser.setEmail(email);

newUser.setRole(role);

myProject.add(newUser);

[0275] Once the project receives the object, persistence and memory may be automatically handled. Calling newUser.freeQ after myProject.add(newUser) may have no effect. All Block-derived API objects have a public method managed() that may return true if the block is being managed. A block received from another API object, may be managed. If the block is obtained by calling blank(), it may be unmanaged. Note that calling blank() may not free any memory, so calling blankQ twice in a row may result in a memory leak.

[0276] When there are multiple Block-derived objects referring to the same managed block, they may all share the same data underneath. Calling setName() from one object may cause name() to return the new value for the other objects.

[0277] The API uses the following naming conventions: (1) getter methods having the format name0fProperty(), e.g. uid() may return the uid of the object; (2) setter methods having the format setName0fProperty(), e.g. setName(TBwcs) may set the name; (3) methods returning collections may be lowercase versions of the collection name, e.g., tbm Project: :threads() returns Threads (unless the relationship to the object is unclear, in which case the method name may be the relationship, e.g. children() and parents() both return Threads); and (4) methods that use other verbs, e.g. applyX(), assign Y(), addZ(), may use those verbs to match TBM's Graphical User Interface where possible.

[0278] Although the invention has been described in terms of a process management system, it is contemplated that it may be implemented in software on microprocessors/general purpose computers (not shown). In various embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer. This software may be embodied in a tangible computer storage medium, for example, a magnetic or optical disk, or memory card.

[0279] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made within the scope and range of equivalents of the claims and without departing from the invention.

Claims

What Is Claimed Is:
1. A process management method for developing an embedded system using a plurality of project views, each project view being assigned to a different entity, comprising the steps of:
associating one or more objectives with a respective project view;
linking one or more embedded system deliverables to the one or more objectives;
for a respective objective: (1) linking, by a computer, at least one functional requirement to the respective objective, and (2) linking, by the computer, at least one test result to the respective objective to validate that the embedded system
deliverables linked to the respective objective satisfy the at least one functional requirement; and
presenting, in the respective project view, status information of the objectives assigned to a respective entity.
2. The method of claim 1, further comprising the step of:
determining the status information from the test results linked to objectives associated with the respective project view.
3. The method of claim 1, further comprising the step of:
comparing the one or more embedded system deliverables with a
corresponding test for each objective of the respective project view; and
determining the status information of the objectives associated with the project view based on a result of the comparing.
4. The method of claim 1, further comprising the step of associating one or more tasks with each respective objective, the associated tasks defining a workflow to accomplish the respective objective, wherein each of the one or more tasks is associated with one or more validation or verification rules and a respective task is designated as being completed after the validation or verification rules associated with the respective task are satisfied.
5. The method of claim 1, further comprising the steps of:
establishing an embedded system development project by identifying users for the embedded system development project; and
assigning the one or more objectives to the identified users to establish the plurality of project views.
6. The method of claim 5, further comprising the steps of:
creating a plurality of roles for the embedded system development project based on groups of the users who are designated to perform common actions;
assigning permissions to the roles to define the common actions that users in the roles are enabled to perform; and
selecting roles for the users from the plurality of created roles.
7. The method of claim 6, wherein the assigning of permissions to the roles comprises defining each of the roles with different level of privileges for the respective project view.
8. The method of claim 1, further comprising the step of:
providing, in the respective project view, a status of at least one functional requirement indicating whether the functional requirement is verified or unverified.
9. The method of claim 1 , further comprising the step of generating an integrated requirements traceability and verification matrix to dynamically track implementation of the functional requirements and status of the functional requirements for the embedded system.
10. The method of claim 1, further comprising the step of providing a status of each of the objectives associated with the respective project view to indicate whether each of the objectives is satisfied.
11. The method of claim 10, further comprising:
generating an integrated objectives traceability and verification matrix to dynamically track implementation each of the objectives associated with the respective project view and the status of the objectives for the embedded system.
12. The method of claim 1, further comprising the step of:
creating a first thread for each of the functional requirements, wherein elements of the first thread comprises a corresponding functional requirement for the embedded system, one or more verification rules associated with the corresponding functional requirement for the embedded system and one or more verification results.
13. The method of claim 12, further comprising the step of:
adding one or more child threads to the first thread;
wherein the first thread is verified after the one or more child threads are verified.
14. The method of claim 1, further comprising the steps of:
associating one or more tasks with each respective objective, the associated tasks;
defining a workflow to accomplish the respective objective based on sequencing of the associated tasks; and
developing the one or more embedded system deliverable in accordance with the defined workflow.
15. The method of claim 14, wherein the one or more tasks are at least two different types of tasks selected from the group consisting of: (1) an authoring task to defining the functional requirements mandated by the respective objective; (2) a validation task to validate an asset; (3) a peer review task to review or analyze an asset; (4) a design task to develop an asset mandated by the respective objective; (5) a test readiness review task to determine readiness of the embedded system for at least acceptance testing; (6) a data or control coupling analysis task to verify assets as mandated by the respective objective; and (7) a change task to effect a change to an asset.
16. The method of claim 14, further comprising the steps of:
linking at least one asset or artifact with each of the one or more tasks; and associating one or more project documents with the respective objective.
17. The method of claim 1, further comprising the step of:
displaying a table of content of the project document including a plurality of sections;
determining which sections of the project document are applicable to the respective objective; and
associating the applicable sections of the project document with the respective objective.
18. The method of claim 1 , further comprising the step of:
associating one or more types of input to the respective project view.
19. The method of claim 18, wherein the one or more types of input include: (1 ) asset type inputs that include developed embedded system deliverables, (2) artifact type inputs that include assessment documents; or (3) project document type inputs that include project assets, artifacts, project guidelines or standards .
20. The method of claim 1 , wherein the respective project view includes one of: (1) a hardware requirement baseline view; (2) a system engineering view; (3) a formal design view; (4) an architecture view; (5) an integrated design environment view; or (6) a test view.
21. The method of claim 1 , further comprising the steps of:
setting roles associated with different types of users for viewing or writing information associated with the respective project view;
determining a role of a user for a respective project view; responsive to the role for the user being set to enable reading, granting permission to view information for the respective project view;
responsive to the role for the user not being set to enable reading, blocking access to view information for the respective project view.
22. The method of claim 1, wherein the presenting of status information includes:
displaying objectives, corresponding tasks and functional requirements associated with the respective project view, as project view items; and
indicating, for respective project view items whether the respective items are satisfied.
23. The method of claim 22, wherein:
the displaying of project view items includes displaying the project view items in a hierarchical project tree, as items of the hierarchical project tree; and
the indicating of whether the respective items are satisfied includes visually indicating, for respective items of the hierarchical project tree, whether the respective items are satisfied.
24. A process management method for developing program code that meets one or more functional requirements using a project view, comprising the steps of:
associating the one or more functional requirements to a plurality of objectives, each objective defining an assignment of work to one entity;
establishing one or more code tests which determine whether the program code meets a respective functional requirement of the one or more functional
requirements;
verifying the program code based on the one or more code tests, as test results; storing, by a computer, each respective functional requirement together with the associated objective, corresponding code tests and corresponding test results, as a respective unit;
presenting information from one or more respective units as a portion of the project view.
25. The method of claim 24, further comprising the step of for each objective associated with the project view, determining the one or more functional requirements for validating that the respective objective is met.
26. The method of claim 24, further comprising the steps of:
associating one or more tasks with each respective objective, the associated tasks defining a workflow to accomplish the respective objective; and
developing the program code for a respective task in accordance with the defined workflow.
27. The method of claim 24, wherein the storing of the respective unit includes storing the respective unit in a single thread, as thread information.
28. The method of claim 24, wherein the presenting of one of the project view includes viewing the thread information associated with the objectives assigned to an entity.
29. The method of claim 24, further comprising the steps of:
analyzing each respective functional requirement to determine the one or more code tests which determine whether the program code meets the respective functional requirement; and
verifying the developed program code based on the one or more code tests, as the test results.
30. A system for managing a development of an embedded system, the system using a plurality of project views, each project view being assigned to a different entity, comprising:
a process management processor:
for associating one or more objectives with a respective project view; for linking one or more embedded system deliverables to the one or more objectives; for a respective objective: (1) linking at least one functional requirement to the respective objective, and (2) linking at least one test result to the respective objective to validate that the embedded system deliverables linked to the respective objective satisfy the at least one functional requirement; and
a display for presenting, in the respective project view, status information of the objectives assigned to a respective entity.
31. The system of claim 30, wherein the process management processor compares the one or more embedded system deliverables with a corresponding one or more test results for each objective of the respective project view and determines the status information of the objectives associated with the project view based on a result of the comparison.
32. The system of claim 30, wherein the process management processor determines a workflow associated with one or more tasks of a respective objective such that embedded system deliverables are implemented in accordance with the determined workflow.
33. The system of claim 32, wherein:
the display presents a table of content of a project document including a plurality of sections for determining, via user input, which sections of the project document are applicable to the respective objective; and
the process management processor associates the applicable sections of the project document with the respective objective.
34. The system of claim 30, wherein the project management processor, responsive to user input, sets roles associated with different types of users for viewing or writing information associated with the respective project view, determines a role of a user for a respective project view; and determines whether to: (1) grants permission to view information or write information for the respective project view or to block access to view information or to write information for the respective project view in accordance with the set roles.
35. The system of claim 30, wherein the display presents the objectives, corresponding tasks and functional requirements associated with the respective project view, as hierarchical project view items, and indicates, for respective hierarchical project view items, whether the respective items are satisfied.
36. A system for managing a development of program code that meets one or more functional requirements using a project view, comprising:
a processor for:
associating the one or more functional requirements to a plurality of objectives, each objective defining an assignment of work to one entity;
validating the program code based on one or more code tests, as test results, the one or more test codes determining whether the program code meets a respective functional requirement of the one or more functional requirements;
a memory for storing each respective functional requirement together with the associated objective, corresponding code tests and corresponding test results, as a respective thread;
a display for presenting information from one or more respective threads having objectives associated with a respective entity, as the project view.
37. The system of claim 30, wherein:
the processor associates one or more tasks with each respective objective, the associated tasks defining a workflow to accomplish the respective objective; and the program code is developed for a respective task in accordance with the defined workflow.
38. The system of claim 30, further comprising: a memory for storing each respective functional requirement together with the associated objective,
corresponding code tests and corresponding test results, as a unit in a respectively different thread.
39. A tangible computer readable medium storing program code for execution on a computer to implement a process management method for developing an embedded system using a plurality of project views, each project view being assigned to a different entity, the method comprising the steps of:
associating one or more objectives with a respective project view;
linking one or more embedded system deliverables to the one or more objectives;
for a respective objective: (1) linking at least one functional requirement to the respective objective, and (2) linking at least one test result to the respective objective to validate that the embedded system deliverables linked to the respective objective satisfy the at least one functional requirement; and
presenting, in the respective project view, status information of the objectives assigned to a respective entity.
40. A tangible computer readable medium storing program code for execution on a computer to implement a process management method for developing program code that meets one or more functional requirements using a project view, the method comprising the steps of:
associating the one or more functional requirements to a plurality of objectives, each objective defining an assignment of work to one entity;
establishing one or more code tests which determine whether the program code meets a respective functional requirement of the one or more functional
requirements;
verifying the program code based on the one or more code tests, as test results; storing each respective functional requirement together with the associated objective, corresponding code tests and corresponding test results, as a respective unit; and
presenting information from one or more respective units as a portion of the project view.
PCT/US2010/002490 2009-09-14 2010-09-14 Systems and methods for management of projects for development of embedded systems WO2011031328A2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US24216409P true 2009-09-14 2009-09-14
US61/242,164 2009-09-14
US30023610P true 2010-02-01 2010-02-01
US61/300,236 2010-02-01

Publications (2)

Publication Number Publication Date
WO2011031328A2 true WO2011031328A2 (en) 2011-03-17
WO2011031328A3 WO2011031328A3 (en) 2011-07-07

Family

ID=43733009

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2010/002490 WO2011031328A2 (en) 2009-09-14 2010-09-14 Systems and methods for management of projects for development of embedded systems

Country Status (1)

Country Link
WO (1) WO2011031328A2 (en)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013043357A1 (en) * 2011-09-23 2013-03-28 The Mathworks, Inc. Using a requirements framework
WO2013043356A1 (en) * 2011-09-23 2013-03-28 The Mathworks, Inc. Requirements framework
US9063809B2 (en) 2013-01-15 2015-06-23 International Business Machines Corporation Content space environment representation
US9069647B2 (en) 2013-01-15 2015-06-30 International Business Machines Corporation Logging and profiling content space data and coverage metric self-reporting
US9075544B2 (en) 2013-01-15 2015-07-07 International Business Machines Corporation Integration and user story generation and requirements management
US9081645B2 (en) 2013-01-15 2015-07-14 International Business Machines Corporation Software product licensing based on a content space
US9087155B2 (en) 2013-01-15 2015-07-21 International Business Machines Corporation Automated data collection, computation and reporting of content space coverage metrics for software products
US9111040B2 (en) 2013-01-15 2015-08-18 International Business Machines Corporation Integration of a software content space with test planning and test case generation
US9141379B2 (en) 2013-01-15 2015-09-22 International Business Machines Corporation Automated code coverage measurement and tracking per user story and requirement
US9182945B2 (en) 2011-03-24 2015-11-10 International Business Machines Corporation Automatic generation of user stories for software products via a product content space
WO2015179705A1 (en) * 2014-05-21 2015-11-26 Quantum Fuel Systems Technologies Worldwide, Inc. Enhanced compliance verification system
US9202188B2 (en) 2013-08-30 2015-12-01 International Business Machines Corporation Impact analysis of change requests of information technology systems
US9218161B2 (en) 2013-01-15 2015-12-22 International Business Machines Corporation Embedding a software content space for run-time implementation
US9361068B2 (en) 2014-05-21 2016-06-07 International Business Machines Corporation System and method for using development objectives to guide implementation of source code
US9396342B2 (en) 2013-01-15 2016-07-19 International Business Machines Corporation Role based authorization based on product content space
US9513873B2 (en) 2013-09-29 2016-12-06 International Business Machines Corporation Computer-assisted release planning
US9659053B2 (en) 2013-01-15 2017-05-23 International Business Machines Corporation Graphical user interface streamlining implementing a content space
US10169725B2 (en) 2013-10-31 2019-01-01 International Business Machines Corporation Change-request analysis

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030135842A1 (en) * 2002-01-16 2003-07-17 Jan-Erik Frey Software development tool for embedded computer systems
US20080016498A1 (en) * 2001-03-23 2008-01-17 S2 Technologies, Inc. System and method for generating data sets for testing embedded systems
US20080109475A1 (en) * 2006-10-25 2008-05-08 Sven Burmester Method Of Creating A Requirement Description For An Embedded System

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080016498A1 (en) * 2001-03-23 2008-01-17 S2 Technologies, Inc. System and method for generating data sets for testing embedded systems
US20030135842A1 (en) * 2002-01-16 2003-07-17 Jan-Erik Frey Software development tool for embedded computer systems
US20080109475A1 (en) * 2006-10-25 2008-05-08 Sven Burmester Method Of Creating A Requirement Description For An Embedded System

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9182945B2 (en) 2011-03-24 2015-11-10 International Business Machines Corporation Automatic generation of user stories for software products via a product content space
WO2013043356A1 (en) * 2011-09-23 2013-03-28 The Mathworks, Inc. Requirements framework
US8943470B2 (en) 2011-09-23 2015-01-27 The Mathworks, Inc. Requirements framework
US9348889B2 (en) 2011-09-23 2016-05-24 The Mathworks, Inc. Requirements framework
WO2013043357A1 (en) * 2011-09-23 2013-03-28 The Mathworks, Inc. Using a requirements framework
US9513902B2 (en) 2013-01-15 2016-12-06 International Business Machines Corporation Automated code coverage measurement and tracking per user story and requirement
US9081645B2 (en) 2013-01-15 2015-07-14 International Business Machines Corporation Software product licensing based on a content space
US9087155B2 (en) 2013-01-15 2015-07-21 International Business Machines Corporation Automated data collection, computation and reporting of content space coverage metrics for software products
US9111040B2 (en) 2013-01-15 2015-08-18 International Business Machines Corporation Integration of a software content space with test planning and test case generation
US9141379B2 (en) 2013-01-15 2015-09-22 International Business Machines Corporation Automated code coverage measurement and tracking per user story and requirement
US9170796B2 (en) 2013-01-15 2015-10-27 International Business Machines Corporation Content space environment representation
US9075544B2 (en) 2013-01-15 2015-07-07 International Business Machines Corporation Integration and user story generation and requirements management
US9659053B2 (en) 2013-01-15 2017-05-23 International Business Machines Corporation Graphical user interface streamlining implementing a content space
US9612828B2 (en) 2013-01-15 2017-04-04 International Business Machines Corporation Logging and profiling content space data and coverage metric self-reporting
US9069647B2 (en) 2013-01-15 2015-06-30 International Business Machines Corporation Logging and profiling content space data and coverage metric self-reporting
US9256423B2 (en) 2013-01-15 2016-02-09 International Business Machines Corporation Software product licensing based on a content space
US9256518B2 (en) 2013-01-15 2016-02-09 International Business Machines Corporation Automated data collection, computation and reporting of content space coverage metrics for software products
US9063809B2 (en) 2013-01-15 2015-06-23 International Business Machines Corporation Content space environment representation
US9569343B2 (en) 2013-01-15 2017-02-14 International Business Machines Corporation Integration of a software content space with test planning and test case generation
US9396342B2 (en) 2013-01-15 2016-07-19 International Business Machines Corporation Role based authorization based on product content space
US9218161B2 (en) 2013-01-15 2015-12-22 International Business Machines Corporation Embedding a software content space for run-time implementation
US9202188B2 (en) 2013-08-30 2015-12-01 International Business Machines Corporation Impact analysis of change requests of information technology systems
US9513873B2 (en) 2013-09-29 2016-12-06 International Business Machines Corporation Computer-assisted release planning
US10169725B2 (en) 2013-10-31 2019-01-01 International Business Machines Corporation Change-request analysis
US9361068B2 (en) 2014-05-21 2016-06-07 International Business Machines Corporation System and method for using development objectives to guide implementation of source code
WO2015179705A1 (en) * 2014-05-21 2015-11-26 Quantum Fuel Systems Technologies Worldwide, Inc. Enhanced compliance verification system
US9940216B2 (en) 2014-05-21 2018-04-10 International Business Machines Corporation System and method for using development objectives to guide implementation of source code
US10353796B2 (en) 2014-05-21 2019-07-16 International Business Machines Corporation System and method for using development objectives to guide implementation of source code

Also Published As

Publication number Publication date
WO2011031328A3 (en) 2011-07-07

Similar Documents

Publication Publication Date Title
Abran et al. Software engineering body of knowledge
Lano Formal object-oriented development
Yoder et al. Architecture and design of adaptive object-models
Strembeck et al. An approach for the systematic development of domain‐specific languages
US9916134B2 (en) Methods and systems for accessing distributed computing components through the internet
US7793256B2 (en) Methods and systems for supporting and deploying distributed computing components
Feiler et al. Software process development and enactment: Concepts and definitions
US7913230B2 (en) Computer-implemented methods and systems for generating software testing documentation and test results management system using same
Pastor et al. Model-driven architecture in practice: a software production environment based on conceptual modeling
US7600182B2 (en) Electronic data capture and verification
George et al. Object-oriented systems analysis and design
Kazman et al. View extraction and view fusion in architectural understanding
Albin The art of software architecture: design methods and techniques
EP1680741B1 (en) Testing tool for complex component based software systems
EP3144804A1 (en) Design assistance for clinical trial protocols
Braude et al. Software engineering: modern approaches
Basin et al. Model driven security: From UML models to access control infrastructures
McIntosh et al. An empirical study of build maintenance effort
Agarwal et al. Software engineering and testing
Ramsin et al. Process-centered review of object oriented software development methodologies
US8726226B2 (en) Integrated work lists for engineering project change management
Agarwal et al. Object-oriented modeling with UML: a study of developers' perceptions
US20090083268A1 (en) Managing variants of artifacts in a software process
Madhavji et al. Prism-methodology and process-oriented environment
US20110022551A1 (en) Methods and systems for generating software quality index

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10815755

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10815755

Country of ref document: EP

Kind code of ref document: A2