CA2497389A1 - Method for development of a software product or family of software products - Google Patents
Method for development of a software product or family of software products Download PDFInfo
- Publication number
- CA2497389A1 CA2497389A1 CA002497389A CA2497389A CA2497389A1 CA 2497389 A1 CA2497389 A1 CA 2497389A1 CA 002497389 A CA002497389 A CA 002497389A CA 2497389 A CA2497389 A CA 2497389A CA 2497389 A1 CA2497389 A1 CA 2497389A1
- Authority
- CA
- Canada
- Prior art keywords
- components
- development
- software
- cycle
- code
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Stored Programmes (AREA)
Abstract
A software product, or family of products, is produced by employing a method that has two main phases - base development and cyclic development, respectively. The base development phase contains unique, non-repetitive steps, that identify technology and product requirements, establish a reference architecture, build reusable component set, define the product look and feel;
build a working prototype, and build a Code Generator application, respectively. The cyclic development phase consists of fixed length cycles. Each cycle contains operational steps, such as: plan the current cycle "N", gather requirements for the next cycle "N+1", design or capture the data schemata, build the data persistence, generate, integrate and customize components, test and deploy requirement components for cycle "N", perform user acceptance testing for cycle "N-1", and repair defects for cycles "N-1", "N-2"..."1", respectively. This method allows to develop software in an operational fashion, faster and more cost effective.
build a working prototype, and build a Code Generator application, respectively. The cyclic development phase consists of fixed length cycles. Each cycle contains operational steps, such as: plan the current cycle "N", gather requirements for the next cycle "N+1", design or capture the data schemata, build the data persistence, generate, integrate and customize components, test and deploy requirement components for cycle "N", perform user acceptance testing for cycle "N-1", and repair defects for cycles "N-1", "N-2"..."1", respectively. This method allows to develop software in an operational fashion, faster and more cost effective.
Description
METHOD FOR DEVELOPMENT OF A SOFTWARE PRODUCT OR
FAMILY OF SOFTWARE PRODUCTS
The present invention relates to a method of developing a software product, or family of products and the resulting software products produced by this method.
GL OSSAR Y OF TERMS
Analysis Process of analyzing the problems and functions to be performed by the software product and break it down into functional groups.
Architecture The fundamental organization of a software product embodied in its components, their visible properties, and the relationships between them and the environment.
Artifact Any product (e.g. document, design model, code) produced during software development Business Component Component logically placed in the Business Tier, called by a Presentation Tier or other Business Component, and which calls other business, persistence, or system components, respectively.
Code Generator A software product built to generate the whole or parts of another software product, based on input data describing some or all aspects of the resulting software product.
Computer Program Any type of computer executable software, including large software systems comprising a multitude of subsystems, subprograms or routines.
Cyclic Development An organization of software development activities following the same sequence and have a constant duration - a cycle.
Deployable Code Code that can be compiled without errors, can be installed in binary format, and run on the target platform.
Design Detailed blueprints of a software application, generally captured in Unified Modeling Language and suitable for code generation.
Development Writing the code that comprises the software product.
Family of Software A set of software products developed to satisfy the requirements of a Products business domain. For example Property & Casualty and Life Insurance applications are part of the family of products for the Insurance industry.
Functional Requirement A description, from the user perspective, of a functional aspect of a software product.
GUI Component Component employed by a software product to render a Graphical User Interface which calls persistence tier or system components, respectively.
Iterative Development In general terms, the act of repeating. For the proposed method, an iteration is the equivalent of an end-to-end cycle of the Cyclic Development Phase.
Interface A specifier for the externally-visible operations of a class"
component, or other classifier (including subsystems) without specification of the internal structure. Each interface often specifies only a limited part of the behaviour of the classifier. Interfaces do not have implementation. They lack attributes, states or associations; they only have operations.
FAMILY OF SOFTWARE PRODUCTS
The present invention relates to a method of developing a software product, or family of products and the resulting software products produced by this method.
GL OSSAR Y OF TERMS
Analysis Process of analyzing the problems and functions to be performed by the software product and break it down into functional groups.
Architecture The fundamental organization of a software product embodied in its components, their visible properties, and the relationships between them and the environment.
Artifact Any product (e.g. document, design model, code) produced during software development Business Component Component logically placed in the Business Tier, called by a Presentation Tier or other Business Component, and which calls other business, persistence, or system components, respectively.
Code Generator A software product built to generate the whole or parts of another software product, based on input data describing some or all aspects of the resulting software product.
Computer Program Any type of computer executable software, including large software systems comprising a multitude of subsystems, subprograms or routines.
Cyclic Development An organization of software development activities following the same sequence and have a constant duration - a cycle.
Deployable Code Code that can be compiled without errors, can be installed in binary format, and run on the target platform.
Design Detailed blueprints of a software application, generally captured in Unified Modeling Language and suitable for code generation.
Development Writing the code that comprises the software product.
Family of Software A set of software products developed to satisfy the requirements of a Products business domain. For example Property & Casualty and Life Insurance applications are part of the family of products for the Insurance industry.
Functional Requirement A description, from the user perspective, of a functional aspect of a software product.
GUI Component Component employed by a software product to render a Graphical User Interface which calls persistence tier or system components, respectively.
Iterative Development In general terms, the act of repeating. For the proposed method, an iteration is the equivalent of an end-to-end cycle of the Cyclic Development Phase.
Interface A specifier for the externally-visible operations of a class"
component, or other classifier (including subsystems) without specification of the internal structure. Each interface often specifies only a limited part of the behaviour of the classifier. Interfaces do not have implementation. They lack attributes, states or associations; they only have operations.
Persistence Component Component logically placed in the Persistence Tier, called by a Business Component and employed to persist data in a data store, using system components.
Prototype Implementation of a fully functional piece of requirements that exercises all the essential functional aspects of the architecture.
Reference Architecture A reference model mapped onto software components, that will cooperatively implement the functionality defined in the reference model. It defines element types, allowed interactions and data flows between components.
Reference Model A division of functionality, together with data flow between the pieces.
A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. Reference Models are heuristic by nature, they are characteristic to mature domains, and are often obtained by domain analysis.
Software Quality The ability of a software product to satisfy functional and non-functional requirements, such as performance, throughput, scalability, availability, and maintainability, respectively.
Test Verification if the software product meets the functional and non-functional requirements, including, if needed, fixing any defects discovered during the test.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic illustration of the method steps for producing a software product according to the prior art waterfall method;
Prototype Implementation of a fully functional piece of requirements that exercises all the essential functional aspects of the architecture.
Reference Architecture A reference model mapped onto software components, that will cooperatively implement the functionality defined in the reference model. It defines element types, allowed interactions and data flows between components.
Reference Model A division of functionality, together with data flow between the pieces.
A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. Reference Models are heuristic by nature, they are characteristic to mature domains, and are often obtained by domain analysis.
Software Quality The ability of a software product to satisfy functional and non-functional requirements, such as performance, throughput, scalability, availability, and maintainability, respectively.
Test Verification if the software product meets the functional and non-functional requirements, including, if needed, fixing any defects discovered during the test.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic illustration of the method steps for producing a software product according to the prior art waterfall method;
Figure 2 is a schematic illustration of the method steps for producing a software product according to the prior art iterative method;
Figure 3 is a schematic illustration of the successive development steps according to an embodiment of the present invention;
Figure 4 is a schematic illustration of an mufti-tier Reference Architecture Figure 5 is a schematic illustration of the team structure for the preferred embodiment of the proposed invention Figure 6 is a graphical illustration of the graphical user interface of the code generation application described by the preferred embodiment of the invention DESCRIPTION OF PRIOR ART
Software Development Methodologies The development of software products, in particular customer specific applications, typically consists of the following main activity groups: requirements gathering, analysis and design, implementation, testing and deployment in production. A software application may consist of a plurality of subsystems, and is partitioned in "tiers", associated with a main function, such as presentation tier, business tier and persistence tier, respectively.
The first traditional method of software development is the waterfall model, illustrated in Figure. 1. The software application is developed by sequentially scheduling the above mentioned activities, and assuming that the in-between artifacts do not change after they have been used as input for the subsequent activity. This approach is very rigid, and cannot handle requirements changes well. The overall development efficiency is low, resulting in high costs and long times to finish the products.
Another approach is iterative development, which is illustrated in Figure 2.
The software development phases are carried out consecutively as in the case of the waterfall model.
The difference is that although all requirements for the product may be gathered at the beginning of the project, the subsequent phases - analysis&design, implementation, testing and deployment are performed for sub-sets of the functional requirements. New functionality is integrated in the existing system iteratively, and the software application is typically completed in a few iterations.
Commercial software development methods are available as well, the best known one being the Rational Unified Process, owned by Rational Software Corporation - acquired by International Business Machines [IBM] in February 2003. Rational Unified Process identifies:
a) six core disciplines which are performed during the life-cycle of a software development project:
business modeling, requirements, analysis & design, implementation, test &
assessment, deployment, and b) three supporting disciplines: configuration & change management, project management and environment, respectively.
The Rational Unified Process also formalizes the roles and responsibilities of the actors performing these disciplines. The software development lifecycle is divided into four phases: inception, elaboration, construction and transition. For each phase one or more disciplines are predominant, while the supporting disciplines require even effort from the inception to the end of the development effort.
The iterations described by the Rational Unified Process are not consistent, their duration, as well as scope may vary based on the project manager decisions. This approach renders the development process non-repeatable, and prone to human errors. Rational Unified Process does not mention the possibility of using code generation as part of the methodology, and does not describe any means of improving the cost-efficiency of the software development process.
Newer methods of software development, known as "Agile Methods" have also been described in literature. These methods put emphasis on team member interaction, they prefer not to include analysis and design as part of the software development step, and advocate constant code refactoring. These methodologies also suggest to minimize the amount of documentation produced during the development of the software product.
In comparison to more traditional methods, Agile methodologies promote fixed duration iterations, thus making the first steps towards a repeatable development process. But they do not promote any techniques to achieve higher cost efficiencies for development activities.
Agile methods improve overall project cost efficiency by cutting down on the amount of artifacts, other than code, produced during the project's life-cycle.
Code Generation Code generation is the technique of building and using software applications to write other software code. The idea behind code generation is to create consistent and high quality software more quickly, and with less human intervention Code generation has been employed in different forms during the software lifecycle development process. There are software design tools that have provided the ability to generate code from design artifacts. But none of the software development methodologies incorporates code generation as a formal step of the development process.
Recently, the Model Driven Development methodology, developed under the auspices of Object Management Group (OMG) promotes a model-centric software development life-cycle, where more complete code could be generated off the software design model and produce executable code when combined with code manually developed. The OMG approach does not describe the concrete details of the methodology, and relies on the ability of software vendor tools to implement its principles.
Code Generation has been described in literature as well, for example the "Code Generation in Action"
book by Jack Herrington, published by Manning in 2003 (ISBN 1-930110-97-9).
The approach is to generate separate code for the different tiers of the applications, based on a meta-model description language, typically XML. However, the book does not describe a software development lifecycle approach that incorporates code generation as an essential step of the development method.
ADVANTAGES OF THE PROPOSED INVENTION
The present invention proposes a software development method with a high degree of operational repeatability by promoting consistent-structure, fixed-duration development cycles. Using this approach, together with better tooling, software development becomes more predictable, with the capacity of yielding higher quality products with at an improved cost efficiency. The method proposed the use of Code Generators as a standard approach, replacing error-prone human development work with standardized artifacts.
The following advantages can be achieved with the present invention:
1. The invention enables faster delivery of large software products, or family of software products by:
~ allowing for a large percentage of code to be generated, rather than written by a developer;
~ allowing for reusable components to be code generated, and subsequently employed by other components, if needed;
~ allowing for generated code to run without any additions, extensions or changes;
~ minimizing the amount of testing needed, as generated code is much less prone to exhibiting defects;
~ providing reusable components at the beginning of the first cycle development phase, rather than identifying them across multiple cycles, and finalizing them across the first couple of cycles;
~ allowing for multiple teams to develop cycles independently, based on the common application framework, base components and essential business components that are first generated;
2. The invention decreases the cost of developing large software products, or family of products by:
~ allowing for smaller teams to deliver a larger amount of code, as a large percentage of code is generated, rather than manually written;
~ minimizing the effort required to test, as generated code has a much smaller amount of defects per number of lines of code;
~ providing test units via the code generator, thus being able to speed up the testing process;
3. The invention increases the software quality by:
~ producing a large percentage of the code in a defect free modality;
~ assuring the conformance of all code to reference architecture, especially due to the code generation of all significant requirement-specific entities;
~ assuring that code meets performance, capacity and scalability qualities, as proven by the prototype used to fine tune the reference architecture;
4. The invention decreases the cost of errors by enabling their early detection during the reference architecture definition, prototyping and first cycle testing, respectively.
Figure 3 is a schematic illustration of the successive development steps according to an embodiment of the present invention;
Figure 4 is a schematic illustration of an mufti-tier Reference Architecture Figure 5 is a schematic illustration of the team structure for the preferred embodiment of the proposed invention Figure 6 is a graphical illustration of the graphical user interface of the code generation application described by the preferred embodiment of the invention DESCRIPTION OF PRIOR ART
Software Development Methodologies The development of software products, in particular customer specific applications, typically consists of the following main activity groups: requirements gathering, analysis and design, implementation, testing and deployment in production. A software application may consist of a plurality of subsystems, and is partitioned in "tiers", associated with a main function, such as presentation tier, business tier and persistence tier, respectively.
The first traditional method of software development is the waterfall model, illustrated in Figure. 1. The software application is developed by sequentially scheduling the above mentioned activities, and assuming that the in-between artifacts do not change after they have been used as input for the subsequent activity. This approach is very rigid, and cannot handle requirements changes well. The overall development efficiency is low, resulting in high costs and long times to finish the products.
Another approach is iterative development, which is illustrated in Figure 2.
The software development phases are carried out consecutively as in the case of the waterfall model.
The difference is that although all requirements for the product may be gathered at the beginning of the project, the subsequent phases - analysis&design, implementation, testing and deployment are performed for sub-sets of the functional requirements. New functionality is integrated in the existing system iteratively, and the software application is typically completed in a few iterations.
Commercial software development methods are available as well, the best known one being the Rational Unified Process, owned by Rational Software Corporation - acquired by International Business Machines [IBM] in February 2003. Rational Unified Process identifies:
a) six core disciplines which are performed during the life-cycle of a software development project:
business modeling, requirements, analysis & design, implementation, test &
assessment, deployment, and b) three supporting disciplines: configuration & change management, project management and environment, respectively.
The Rational Unified Process also formalizes the roles and responsibilities of the actors performing these disciplines. The software development lifecycle is divided into four phases: inception, elaboration, construction and transition. For each phase one or more disciplines are predominant, while the supporting disciplines require even effort from the inception to the end of the development effort.
The iterations described by the Rational Unified Process are not consistent, their duration, as well as scope may vary based on the project manager decisions. This approach renders the development process non-repeatable, and prone to human errors. Rational Unified Process does not mention the possibility of using code generation as part of the methodology, and does not describe any means of improving the cost-efficiency of the software development process.
Newer methods of software development, known as "Agile Methods" have also been described in literature. These methods put emphasis on team member interaction, they prefer not to include analysis and design as part of the software development step, and advocate constant code refactoring. These methodologies also suggest to minimize the amount of documentation produced during the development of the software product.
In comparison to more traditional methods, Agile methodologies promote fixed duration iterations, thus making the first steps towards a repeatable development process. But they do not promote any techniques to achieve higher cost efficiencies for development activities.
Agile methods improve overall project cost efficiency by cutting down on the amount of artifacts, other than code, produced during the project's life-cycle.
Code Generation Code generation is the technique of building and using software applications to write other software code. The idea behind code generation is to create consistent and high quality software more quickly, and with less human intervention Code generation has been employed in different forms during the software lifecycle development process. There are software design tools that have provided the ability to generate code from design artifacts. But none of the software development methodologies incorporates code generation as a formal step of the development process.
Recently, the Model Driven Development methodology, developed under the auspices of Object Management Group (OMG) promotes a model-centric software development life-cycle, where more complete code could be generated off the software design model and produce executable code when combined with code manually developed. The OMG approach does not describe the concrete details of the methodology, and relies on the ability of software vendor tools to implement its principles.
Code Generation has been described in literature as well, for example the "Code Generation in Action"
book by Jack Herrington, published by Manning in 2003 (ISBN 1-930110-97-9).
The approach is to generate separate code for the different tiers of the applications, based on a meta-model description language, typically XML. However, the book does not describe a software development lifecycle approach that incorporates code generation as an essential step of the development method.
ADVANTAGES OF THE PROPOSED INVENTION
The present invention proposes a software development method with a high degree of operational repeatability by promoting consistent-structure, fixed-duration development cycles. Using this approach, together with better tooling, software development becomes more predictable, with the capacity of yielding higher quality products with at an improved cost efficiency. The method proposed the use of Code Generators as a standard approach, replacing error-prone human development work with standardized artifacts.
The following advantages can be achieved with the present invention:
1. The invention enables faster delivery of large software products, or family of software products by:
~ allowing for a large percentage of code to be generated, rather than written by a developer;
~ allowing for reusable components to be code generated, and subsequently employed by other components, if needed;
~ allowing for generated code to run without any additions, extensions or changes;
~ minimizing the amount of testing needed, as generated code is much less prone to exhibiting defects;
~ providing reusable components at the beginning of the first cycle development phase, rather than identifying them across multiple cycles, and finalizing them across the first couple of cycles;
~ allowing for multiple teams to develop cycles independently, based on the common application framework, base components and essential business components that are first generated;
2. The invention decreases the cost of developing large software products, or family of products by:
~ allowing for smaller teams to deliver a larger amount of code, as a large percentage of code is generated, rather than manually written;
~ minimizing the effort required to test, as generated code has a much smaller amount of defects per number of lines of code;
~ providing test units via the code generator, thus being able to speed up the testing process;
3. The invention increases the software quality by:
~ producing a large percentage of the code in a defect free modality;
~ assuring the conformance of all code to reference architecture, especially due to the code generation of all significant requirement-specific entities;
~ assuring that code meets performance, capacity and scalability qualities, as proven by the prototype used to fine tune the reference architecture;
4. The invention decreases the cost of errors by enabling their early detection during the reference architecture definition, prototyping and first cycle testing, respectively.
5. The invention provides a vehicle to optimize the amount of analysis and design work as the executable code is based on two models only: a) architecture model and b) data definition point schemata.
6. The invention provides a vehicle to ensure conformity to an architectural design, as the artifacts produced by the code generator are based on the reference architecture .
7. The invention provides a vehicle to improve the maintainability of the software product, as all business requirements are implemented in a consistent manner, allowing for a faster and easier understanding of the product by the support team.
The present invention provides a method of producing a software product, or a family of products, comprised of two phases - base and cyclic development, respectively. The steps for each phase are described below. The base phase establishes the technical parameters of the software solution, such as technology, architecture, as well as building or acquiring the tools needed for Code Generation. The Cyclic Development Phase leverages the architecture and Code Generation tool produced during the base phase. Cycles are characterized by a) a structured and ordered set of activities they are comprised of and b) their periodicity, generally expressed as time duration. For a given project, the proposed invention assumes all the cycles of the cyclic development phase have the same duration. At the end of each cycle, deployable code, that implements a subset of the product's requirements, is produced.
The notion of "iteration" is widely used in the IT industry, describing a pre-defined set of development activities, that result in working code that partially implements the functional requirements for the software product. From the definition of "cycle" above, it can be seen that in the context of the proposed invention a cycle is an iteration with a fixed duration.
Base Development Phase:
1. Identify the technology requirements;
2. Gather high level requirements;
3. Establish a reference architecture;
4. Build a framework of reusable, requirements-agnostic components;
5. Build a set of base components for the requirement-specific components;
6. Define the graphical user interface templates;
7. Build a prototype to fine tune the architecture;
The present invention provides a method of producing a software product, or a family of products, comprised of two phases - base and cyclic development, respectively. The steps for each phase are described below. The base phase establishes the technical parameters of the software solution, such as technology, architecture, as well as building or acquiring the tools needed for Code Generation. The Cyclic Development Phase leverages the architecture and Code Generation tool produced during the base phase. Cycles are characterized by a) a structured and ordered set of activities they are comprised of and b) their periodicity, generally expressed as time duration. For a given project, the proposed invention assumes all the cycles of the cyclic development phase have the same duration. At the end of each cycle, deployable code, that implements a subset of the product's requirements, is produced.
The notion of "iteration" is widely used in the IT industry, describing a pre-defined set of development activities, that result in working code that partially implements the functional requirements for the software product. From the definition of "cycle" above, it can be seen that in the context of the proposed invention a cycle is an iteration with a fixed duration.
Base Development Phase:
1. Identify the technology requirements;
2. Gather high level requirements;
3. Establish a reference architecture;
4. Build a framework of reusable, requirements-agnostic components;
5. Build a set of base components for the requirement-specific components;
6. Define the graphical user interface templates;
7. Build a prototype to fine tune the architecture;
8. Build an end-to-end Code Generator for requirement-specific components;
9. Gather detailed requirements for the whole project or first cycle only;
Cyclic Development Phase:
Cyclic Development Phase:
10. Plan the current cycle "N";
11. Gather and analyze requirements for the next cycle "N+1";
12. Design;
13. Build the data persistence,if needed;
14. Use the Code Generator and the data schemata to generate requirement specific components;
15. Integrate and customize the generated components as needed;
16. Test the generated and customized components;
17. Deploy the components;
18. Perform user acceptance testing for "N-1" cycle components;
19. Repair defects for code produced during "N-1", "N-2", and previous cycles.
The Steps of the Proposed Invention Step 1- Identify Technology Requirements According to the present invention, as a first step, the technology requirements need to be identified.
Sometimes software applications are required to run on predetermined platforms. In other situations, there are no specific technological requirements, and they may be chosen at will. The outcome of this step is to identify the language in which the software application will be developed, the development and production operating systems, other infrastructure software components, such as, but not exclusively application servers, firewalls, databases, and hardware configurations, respectively.
Step 2 - Gather High Level Requirements In parallel to determining the technology requirements, the product's (or family of products') high level requirements are gathered during Step #2 of the proposed invention. These requirements are detailed enough to establish essential product functionality that will be captured by the reference architecture.
Requirements gathered during this step are both functional and non-functional.
Step 3 - Establish a Reference Architecture Once the target technology has been identified, and high level requirements have been gathered, a reference architecture can be designed as part of Step #3 of the method. The reference architecture is described by a set of views that depict the software solution from different stakeholder perspectives, such as: software components, hardware components, network organization, software deployment, run-time processes, and so on. The number and content of these views are generally determined by product stakeholder needs. At a minimum, the reference architecture shall have the following views: a) functionality, b) software components, c) hardware components and network, d) software components assigned to hardware nodes, and e) data view, respectively.
The software component view of the reference architecture represents the essential elements the software application must implement. This view a) assigns roles and responsibilities to different software application components, b) assigns the tier location of these components, c) mandates the communications patterns between the components, d) identifies the common base components needed to develop business specific components and e) identifies business agnostic reusable components. The reference architecture does not identify specific business components, only requirement-specific component categories, and their interactions with base, framework and other requirement-specific components, respectively. When the definition of the reference architecture is completed, any requirement-specific functionality can be added without having to modify the reference architecture.
Future needs may require adding new reusable components, but they would not affect components already designed and developed.
Step 4 - Build a Framework of Reusable Components The reference architecture identifies a framework of reusable system components to be used by all requirement-specific components and applications developed on that domain. As part of the next step of the method - Step #4 - a framework of reusable components is designed and implemented. Generally, framework components are called "services". A subset of these services may be developed by the team, while others can be licensed from third parties, such as software vendors or open-source groups. This framework represents the backbone of any business functionality that will be developed applying the proposed method. When all the components of the framework have been developed or purchased, a group of code tests is implemented and run. These tests ensure that any future modifications to the framework will be backwards compatible with the first instance of the framework deployed in production.
Step 5 - Build a Set of Base Components The reference architecture also identifies a set of base components that represent the reusable foundation of requirement-specific components to be build during later phases of the project. These base components are designed and implemented as part of Step #5 of the method.
These components are specific to the reference architecture, and are too granular to be available from third party software providers. The development team is generally required to write the code for these components. The base components encapsulate generic code needed by requirement-specific components to perform their roles.
Step 6 - Define the Graphical User Interface (GUI) Templates In parallel to the activities required to define and implement the reference architecture, as well as the high level requirements gathering activities, the look and feel for the graphical user interface is defined during Step #6 of the invention. A set of GUI templates is needed by the Code Generator tool.
Typically, these templates are: a) Search Screen, b) Search Result List Screen, c) Result Detail Screen and d) Data Edit Screen, respectively for data-centric applications. Their number and functionality may vary from project to project. Combinations of the four basic templates may also be required, for example detailing one record data and associated child record list. These templates are synchronized with the results of the prototype (Step #7) , before the project's cyclic development phase starts.
Step 7 - Build Prototype Based on the reference architecture blueprints, the framework of reusable system components and the base components, a prototype is built to fine-tune the architecture characteristics, as part of Slep #7 of the method. This step is necessary to mitigate any technological risks, and set a baseline for the architecture's characteristics, such as performance, throughput (e.g. number of concurrent requests) and scalability. The prototype may be developed based on a generic set of requirements, that reflects the essential functionality of the software application. The generic requirements should exercise all relevant I/O operations, such as persistence (create, read, update and delete), or communicating with other systems, respectively. If additional generic functionality is required, supplemental requirements are used to define the scope of the prototype.
Step 8 - Build Code Generator During the Step #8 of the proposed invention, the Code Generator application is developed.
Alternatively, a third-party code generation product, which meets the need to generated template-based components for a given architecture blueprint, may be employed. The Code Generator output shall match the reference architecture blueprints.
The Code Generation tool may require the architecture's system framework and base components to be available. It may also employ the prototype's components as code templates for the requirement-specific components to be generated, and the GUI templates previously designed during Step #6. The Code Generator builds all the components necessary to deliver essential, end-to-end, user functionality.
For data-centric applications, some of the components that can be generated, but not exclusively, are: a) screens that allows the user to search, view search results, view details, edit, create and delete data entities; b) components needed by the presentation tier to prepare data for viewing or saving; c) business components applying business logic, such as validation and d) persistence tier components, that allow the application to create, read, update and delete database entities and e) any connector type of components that link the different tiers. The graphical user interface shall be based on templates, that can be adapted to each project's needs.
Step 9 - Gather and Analyze Detailed Requirements During Step #9 of the proposed invention, requirements for the first cycle, or for the full project, are gathered based on the high level requirements gathered during Step #2. There is a finish-to-finish dependency between requirements gathering and analysis activities, and building the development infrastructure artifacts. Requirements have to be analyzed for completeness, in the sense that they are at a granularity level that renders them suitable for implementation.
Step 10 - Plan Cycle Once all the activities of the Base Development Phase have been completed, the cyclic development phase can start. During the Step #10 the team plans the development cycle "N", choosing a) the detailed functional requirements to be gathered and b) what detailed functional requirements to implement. The team works on the premise that all development cycles have a fixed duration, that can be decided as soon as the beginning of the project and no later than the inception of the first cycle.
Step 11- Gather and Analyze Detailed Requirements for Next Cycle The activities of Step # 11 consist of requirements gathering for the next cycle "N+1 ", based on the high level requirements identified during Step #2 and the planning Step #9.
Upon completing the gathering activity, the requirements are also analyzed for completeness. If all the project's requirements were gathered during Step #9 of the Base Development phase, this step will not be performed for any of the cycles.
Step 12 - Design Based on the cycle's requirements, the application's data-points schemata is documented or designed as part of the Step #12 of the method. The present invention does not make any assumptions regarding the data persistence mechanisms. If the persistence mechanism is a new database, the database part associated with the requirements of the current cycle is designed. On the other hand, if the data is already persisted (e.g. old databases or legacy systems), the data point schema is documented.
During this design step, the team also analyses for completeness the functionality of the components produced by the Code Generation tool. If additional functionality is required, the team designs the necessary components, while following the reference architecture blueprints.
Step 13 - Build the Data Persistence During the next Step #13 the data persistence mechanism is built, if required.
The present invention does not make any assumptions regarding the data persistence mechanisms, and it may be a relational database or a data file system.
Step 14 - Generate Components During the next Step #14, the Code Generator is employed to produce the code components required for the current cycle "N". Validation rules may be generated as well, if defined by the data-point schemata. The generated components must match the reference architecture blueprints, provide end-to-end functionality without any code changes, and implement essential system functionality.
Step 15 - Integrate and Customize Components The generated code is integrated into the existing code-base during Step #15.
The integration efforts should be minimized by having designed an extensible, "plug and play"
architecture. This is generally achieved by externalizing the configuration of the application, such as inter-screen navigation information, implementation of service interfaces, validation rules. If the requirements ask for more complex functionality, the generated code can be customized during this step.
Customization may include adding specific functionality, such as new algorithms, or inference business rules, respectively.
Customization may also be achieved by adding components providing aggregate transactions, data aggregation or parent-child relationships, respectively.
Step 16 - Test Once the customization is finished, the code is tested as part of Step #16.
Testing shall be comprehensive, following industry best practices. Tests are performed for unit testing and integration testing. Code is generally tested using other code, generically called test components. These may be code generated for business and persistence components, or individually developed for customized code. The test components are subsequently integrated with regression testing tools. The code of the current cycle "N" is tested in the project code base, so no additional integration is required at the end of Step #16.
Step 17 - Deploy Once the code produced during the current cycle has been tested, it can be deployed in a user acceptance testing environment as part of Step #17. The deployment step shall require minimal effort, as the code has already been integrated.
Step 18 - Test for User Acceptance In parallel to the requirements gathering and development activities described as part of steps 10-17 user acceptance testing (UAT) is performed during Step #18. The UAT tests the code developed during the previous cycle "N-1", verifying that all requirements are met. The User Acceptance Testing is generally done by client representatives. The system is tested against the functional requirements which were used as the basis for development. Any gaps or defects identified during this process are logged and the development team addresses them during the current or subsequent cycles, respectively.
Step 19 - Repair Defects The defects identified during Step #18 of the cycle are repaired during Step #19 of the same cycle , or during subsequent cycles. Defects shall be prioritized. The team may be partitioned into a sub-team developing code and another sub-team that repairs defects. The sub-team members may rotate at the end of each individual cycle.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Figure 3 schematically illustrates the steps for producing a software product or family of software products according to a preferred embodiment of the present invention.
The preferred embodiment is applied to the development of a mufti-tier distributed web application employing Java and Java Enterprise Edition technologies, using a new relational database for data storage.
The method has two phases:
1. Base Development Phase 2. Cyclic Development Phase The Base Development Phase occurs only once, while the Cyclic Development Phase may occur as many times as needed. The preferred embodiment of the invention used cycles with the same duration, no shorter than two weeks and no longer than eight weeks. It is recommended to set this duration to six weeks, but each development team should decide on the length of the cycle, within the asserted limits.
The duration of the base development phase relates to the amount of functionality needed to be incorporated in the application framework, the base components and in the code generation. The present invention asserts that the duration of the Base Development Phase should not exceed twelve weeks.
The size of the team depends on the efficiency of the organization and of the individual team members, scope of the project and on the time to market expectations. However, higher efficiencies are achieved with smaller teams, typically not larger than eight developers plus the supporting roles.
A preferred team composition is shown in Figure 4. The roles and responsibilities of different members for a team employing the method proposed by this invention are:
1. Architect - responsible for a) the technical aspects of the project (architecture, design, coding standards); b) timely and cost effective solution delivery; c) management and coordination of team members; and d) interacting with the project's stakeholders, respectively;
2. Business Analyst - responsible for requirements gathering and analysis;
3. Developer - responsible for component design, code development and unit testing;
4. Defect Fixer - responsible to repair the defects identified by the testing team;
5. GUI Designer - responsible to develop the graphical interface templates, and support the development team, from a GUI perspective, during the cyclic development phase;
6. Database Architect - responsible for database design and database tuning;
7. Database Administrator - responsible for database tuning and optimization;
8. Tester - responsible to design and implement test cases that can be used for subsequent regression testing activities and run the test cases per cycle.
At the beginning of the development process, the client must identify the technology requirements of the software product. Technology is defined in terms of hardware platform, operating system, development language, application and database server choices. As mentioned in the above paragraph, the technological decision is to develop a Java/J2EE web application using a relational database for storage. Given the Java choice as a development language, which is operating system independent, choosing the hardware and operating system for the production system can be deferred to a later time, as long as the performance and capacity factors of the development vs.
production environment are known, or can be determined. In order for a relationship database product to be employable for the project, JDBC drivers must be available.
In parallel to technology identification, the team gathers high level requirements, at a detail level good enough to elicit enough information for the reference architecture to be built. Requirements gathering may be carried by talking to clients and subject matter experts with regards the system to be developed.
These requirements include both functional specifications, and non-functional expectations, such as performance, capacity or availability, respectively.
The commitment to a specific technology, and the identification of the high level requirements enables the development team to design the reference architecture. The outcome of the second step is the reference architecture model. The reference architecture is based on architecture and design patterns generally accepted as the best practice to solving common software problems.
The reference architecture also identifies the data definition points. These points are important for automating the code generation of business specific components. For a "N-tier"
application three data definition points are representative: a) persistent storage, b) business facades, and c) views. In very complex situations, the Reference Architecture may have to employ all three data definition points, and define data transformation strategies to obtain fully functional end-to-end code. A less expensive approach is to base the application on one data definition point only. The preferred embodiment of the invention uses the persistent storage as the unique data definition point, and assumes that this definition is sufficient to develop both presentation and business tier code. Teams that will implement this method will have to verify if this assumption is correct within the context of their development environment.
The reference architecture is documented using a software design modeling tool. The resulting model is subsequently used at end of this step to build the framework and base components. Persistent storage may be required by the framework design. Persistency may be achieved employing a database or file storage. If a database is needed to support the framework's technical functionality, it is designed and implemented during this step. A representative, high level Reference Architecture Model for an multi-tier Web application is shown in Figure 5.
Once both the framework and the base components have been developed, the architectural prototype can be developed. The prototype is based on a set of use cases representative for the overall functionality of the system. In the most generic terms, a data-centric web application allows users to search and view search results, create, update and delete a variety of data entities. The prototype can contain only the above mentioned operations for generic entities, such as person, or it may employ more complex functionality, requiring data aggregation, such as the ability to display personal information, as well as addresses on the same screen. The high level requirements and the application type prescribe the basic set of "must-have" functionality . This functional set will be used as input in specifying the requirements for a Code Generation tool. During the prototype development phase, the framework and base components are refined based on non-functional criteria, such as performance, capacity, scalability and maintainability, respectively.
Subsequent to the proof of concept, the prototype's functional components are transformed into templates, by abstracting the common parts and replacing specific variable names and types with placeholders. These templates are used as the starting point for developing the Code Generation application, which is able to produce fully functional, end-to-end code that supports the basic business functionality developed during the prototyping phase. For the preferred embodiment of the invention the following component types are generated:
1. Search View - allows users to input search criteria and submit the request 2. Search Results View - displays search results to user 3. Detail View - allows users to view details of a list entry 4. Edit View - allows users to view and edit details of a list entry and submit the changes 5. New View - allows users to create a new entity and submit the entry 6. View Handler - is a software component type employed to encapsulate logic relating to initiating content retrieval, validation, and adapting and formatting the model, while the View components handle presentation formatting. The Handler components subsequently forward the request to a Business Facade component.
7. Business Facade - provides large granularity interface to its clients by hiding the complexities of the business object interactions. The Business Facade is generally responsible to validate and process the request according to the business functional specifications. After business processing is completed, the Business Facade forwards the request to a Data Access Object if the request involves a create, read, update, or delete (CRUD) operation.
8. Data Access Object - a component of this type provides loose coupling between the business and persistence tiers. The Data Access Object intercepts and services all access to the resource tier, making the implementation details of the resource tiers transparent to the clients. The data in the resource tier can reside in database systems, proprietary systems, other external systems and services.
9. Value Object - provides best techniques and strategies to exchange data across tiers (that is, across system boundaries). This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
10. Filter - this component is responsible to clean inbound data requests and add reference data to outbound responses.
The input for the Code Generation application may be any data schema representation, or physical implementation, such as XMI representation of UML design, Database Definition Language, XML
Schema or a physical database, respectively. The preferred embodiment of the invention uses the physical database as input for the application, together with additional user entered data.
The Code Generation Application can be implemented as a GUI Application or just providing a command line interface to the user. An implementation of the Code Generator as a GUI Application is shown in Figure 6. The preferred implementation of the Code Generation application allows the user to:
1. Connect to a specific database server;
2. Select the database to use for code generation;
3. Select the table for which to generate components;
4. Specify the components' names;
5. Specify the package names for the business facade and helper components;
6. Specify the location of the generated code;
The Code Generation Application may also output other files, such as configuration files, or files containing SQL statements, necessary for the business components to perform CRUD operations.
To complete the Code Generation step, the team needs to test the correctness of the generated code. The preferred embodiment of the invention recommends to generate the code of the previous prototype and use the already developed test cases.
Once the Code Generation Application is completed, the GUI templates are finalized and the requirements for the first cycle have been gathered, the team can start planning the first cycle. The proposed invention requires cycles to have a fixed duration, and recommends this duration to be six weeks. During the planning phase the team decides how much can do within the cycle allocated time.
The planning step shall be completed in one day by the full team.
During the next step the development team needs to identify the data entities relevant to the current cycle and design the database schema. The design must be generic enough to account for other domain specific requirements that may be specified by subsequent cycle requirements.
The design should build on the design of the previous cycles. This is achieved by using a database design tool and using one design model only. The design may be partitioned along the business domain main entity lines, and also include support entities, required by the system framework.
Once the database design is finalized, the physical database can be generated and deployed on the database server. Test data rnay be generated and loaded during this step as well.
Once the database is accessible on the server, the Code Generation Application is employed to produce the business components for the different tables that are used during the cycle. It may well be possible that previously generated components are needed for the current cycle. The exemplified interface of the Code Generation Application uses a one-to-one mapping between tables and components. If data from more than one table has to be shown and maintained by the same set of screens, the Code Generation Application may be designed in such a way that data from multiple tables is allowed to be aggregated on screen, while the entity specific components are still independent of each other.
After code generation, the development team integrates the components into the existing code base.
This integration should not require modifying any of the existing code. In order to employ existing code, some customization of the newly generated components may be needed.
Alternatively, if more effort is spent in defining and developing the Code Generation Application, the tool may provide the capabilities needed to reuse available code.
Once the code is completed, the team will test it. There are many aspects of testing: unit testing, integration testing, end-user testing, performance testing, or load testing, respectively. The team will perform at least unit testing and end-user testing, verifying that the software product meets the functional requirements. Performance and load testing should be performed during the prototype step, and again at the end of the first cycle, to ensure the architecture meets the non-functional requirements.
In parallel to the development activities, the team also gathers requirements for the next cycle.
The client, or a sub-team also performs user acceptance testing.
The cycles end when no more functional requirements are to be implemented. As integration of code is integral to each cycle, there are no specific end of project activities required by the proposed invention.
The Steps of the Proposed Invention Step 1- Identify Technology Requirements According to the present invention, as a first step, the technology requirements need to be identified.
Sometimes software applications are required to run on predetermined platforms. In other situations, there are no specific technological requirements, and they may be chosen at will. The outcome of this step is to identify the language in which the software application will be developed, the development and production operating systems, other infrastructure software components, such as, but not exclusively application servers, firewalls, databases, and hardware configurations, respectively.
Step 2 - Gather High Level Requirements In parallel to determining the technology requirements, the product's (or family of products') high level requirements are gathered during Step #2 of the proposed invention. These requirements are detailed enough to establish essential product functionality that will be captured by the reference architecture.
Requirements gathered during this step are both functional and non-functional.
Step 3 - Establish a Reference Architecture Once the target technology has been identified, and high level requirements have been gathered, a reference architecture can be designed as part of Step #3 of the method. The reference architecture is described by a set of views that depict the software solution from different stakeholder perspectives, such as: software components, hardware components, network organization, software deployment, run-time processes, and so on. The number and content of these views are generally determined by product stakeholder needs. At a minimum, the reference architecture shall have the following views: a) functionality, b) software components, c) hardware components and network, d) software components assigned to hardware nodes, and e) data view, respectively.
The software component view of the reference architecture represents the essential elements the software application must implement. This view a) assigns roles and responsibilities to different software application components, b) assigns the tier location of these components, c) mandates the communications patterns between the components, d) identifies the common base components needed to develop business specific components and e) identifies business agnostic reusable components. The reference architecture does not identify specific business components, only requirement-specific component categories, and their interactions with base, framework and other requirement-specific components, respectively. When the definition of the reference architecture is completed, any requirement-specific functionality can be added without having to modify the reference architecture.
Future needs may require adding new reusable components, but they would not affect components already designed and developed.
Step 4 - Build a Framework of Reusable Components The reference architecture identifies a framework of reusable system components to be used by all requirement-specific components and applications developed on that domain. As part of the next step of the method - Step #4 - a framework of reusable components is designed and implemented. Generally, framework components are called "services". A subset of these services may be developed by the team, while others can be licensed from third parties, such as software vendors or open-source groups. This framework represents the backbone of any business functionality that will be developed applying the proposed method. When all the components of the framework have been developed or purchased, a group of code tests is implemented and run. These tests ensure that any future modifications to the framework will be backwards compatible with the first instance of the framework deployed in production.
Step 5 - Build a Set of Base Components The reference architecture also identifies a set of base components that represent the reusable foundation of requirement-specific components to be build during later phases of the project. These base components are designed and implemented as part of Step #5 of the method.
These components are specific to the reference architecture, and are too granular to be available from third party software providers. The development team is generally required to write the code for these components. The base components encapsulate generic code needed by requirement-specific components to perform their roles.
Step 6 - Define the Graphical User Interface (GUI) Templates In parallel to the activities required to define and implement the reference architecture, as well as the high level requirements gathering activities, the look and feel for the graphical user interface is defined during Step #6 of the invention. A set of GUI templates is needed by the Code Generator tool.
Typically, these templates are: a) Search Screen, b) Search Result List Screen, c) Result Detail Screen and d) Data Edit Screen, respectively for data-centric applications. Their number and functionality may vary from project to project. Combinations of the four basic templates may also be required, for example detailing one record data and associated child record list. These templates are synchronized with the results of the prototype (Step #7) , before the project's cyclic development phase starts.
Step 7 - Build Prototype Based on the reference architecture blueprints, the framework of reusable system components and the base components, a prototype is built to fine-tune the architecture characteristics, as part of Slep #7 of the method. This step is necessary to mitigate any technological risks, and set a baseline for the architecture's characteristics, such as performance, throughput (e.g. number of concurrent requests) and scalability. The prototype may be developed based on a generic set of requirements, that reflects the essential functionality of the software application. The generic requirements should exercise all relevant I/O operations, such as persistence (create, read, update and delete), or communicating with other systems, respectively. If additional generic functionality is required, supplemental requirements are used to define the scope of the prototype.
Step 8 - Build Code Generator During the Step #8 of the proposed invention, the Code Generator application is developed.
Alternatively, a third-party code generation product, which meets the need to generated template-based components for a given architecture blueprint, may be employed. The Code Generator output shall match the reference architecture blueprints.
The Code Generation tool may require the architecture's system framework and base components to be available. It may also employ the prototype's components as code templates for the requirement-specific components to be generated, and the GUI templates previously designed during Step #6. The Code Generator builds all the components necessary to deliver essential, end-to-end, user functionality.
For data-centric applications, some of the components that can be generated, but not exclusively, are: a) screens that allows the user to search, view search results, view details, edit, create and delete data entities; b) components needed by the presentation tier to prepare data for viewing or saving; c) business components applying business logic, such as validation and d) persistence tier components, that allow the application to create, read, update and delete database entities and e) any connector type of components that link the different tiers. The graphical user interface shall be based on templates, that can be adapted to each project's needs.
Step 9 - Gather and Analyze Detailed Requirements During Step #9 of the proposed invention, requirements for the first cycle, or for the full project, are gathered based on the high level requirements gathered during Step #2. There is a finish-to-finish dependency between requirements gathering and analysis activities, and building the development infrastructure artifacts. Requirements have to be analyzed for completeness, in the sense that they are at a granularity level that renders them suitable for implementation.
Step 10 - Plan Cycle Once all the activities of the Base Development Phase have been completed, the cyclic development phase can start. During the Step #10 the team plans the development cycle "N", choosing a) the detailed functional requirements to be gathered and b) what detailed functional requirements to implement. The team works on the premise that all development cycles have a fixed duration, that can be decided as soon as the beginning of the project and no later than the inception of the first cycle.
Step 11- Gather and Analyze Detailed Requirements for Next Cycle The activities of Step # 11 consist of requirements gathering for the next cycle "N+1 ", based on the high level requirements identified during Step #2 and the planning Step #9.
Upon completing the gathering activity, the requirements are also analyzed for completeness. If all the project's requirements were gathered during Step #9 of the Base Development phase, this step will not be performed for any of the cycles.
Step 12 - Design Based on the cycle's requirements, the application's data-points schemata is documented or designed as part of the Step #12 of the method. The present invention does not make any assumptions regarding the data persistence mechanisms. If the persistence mechanism is a new database, the database part associated with the requirements of the current cycle is designed. On the other hand, if the data is already persisted (e.g. old databases or legacy systems), the data point schema is documented.
During this design step, the team also analyses for completeness the functionality of the components produced by the Code Generation tool. If additional functionality is required, the team designs the necessary components, while following the reference architecture blueprints.
Step 13 - Build the Data Persistence During the next Step #13 the data persistence mechanism is built, if required.
The present invention does not make any assumptions regarding the data persistence mechanisms, and it may be a relational database or a data file system.
Step 14 - Generate Components During the next Step #14, the Code Generator is employed to produce the code components required for the current cycle "N". Validation rules may be generated as well, if defined by the data-point schemata. The generated components must match the reference architecture blueprints, provide end-to-end functionality without any code changes, and implement essential system functionality.
Step 15 - Integrate and Customize Components The generated code is integrated into the existing code-base during Step #15.
The integration efforts should be minimized by having designed an extensible, "plug and play"
architecture. This is generally achieved by externalizing the configuration of the application, such as inter-screen navigation information, implementation of service interfaces, validation rules. If the requirements ask for more complex functionality, the generated code can be customized during this step.
Customization may include adding specific functionality, such as new algorithms, or inference business rules, respectively.
Customization may also be achieved by adding components providing aggregate transactions, data aggregation or parent-child relationships, respectively.
Step 16 - Test Once the customization is finished, the code is tested as part of Step #16.
Testing shall be comprehensive, following industry best practices. Tests are performed for unit testing and integration testing. Code is generally tested using other code, generically called test components. These may be code generated for business and persistence components, or individually developed for customized code. The test components are subsequently integrated with regression testing tools. The code of the current cycle "N" is tested in the project code base, so no additional integration is required at the end of Step #16.
Step 17 - Deploy Once the code produced during the current cycle has been tested, it can be deployed in a user acceptance testing environment as part of Step #17. The deployment step shall require minimal effort, as the code has already been integrated.
Step 18 - Test for User Acceptance In parallel to the requirements gathering and development activities described as part of steps 10-17 user acceptance testing (UAT) is performed during Step #18. The UAT tests the code developed during the previous cycle "N-1", verifying that all requirements are met. The User Acceptance Testing is generally done by client representatives. The system is tested against the functional requirements which were used as the basis for development. Any gaps or defects identified during this process are logged and the development team addresses them during the current or subsequent cycles, respectively.
Step 19 - Repair Defects The defects identified during Step #18 of the cycle are repaired during Step #19 of the same cycle , or during subsequent cycles. Defects shall be prioritized. The team may be partitioned into a sub-team developing code and another sub-team that repairs defects. The sub-team members may rotate at the end of each individual cycle.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Figure 3 schematically illustrates the steps for producing a software product or family of software products according to a preferred embodiment of the present invention.
The preferred embodiment is applied to the development of a mufti-tier distributed web application employing Java and Java Enterprise Edition technologies, using a new relational database for data storage.
The method has two phases:
1. Base Development Phase 2. Cyclic Development Phase The Base Development Phase occurs only once, while the Cyclic Development Phase may occur as many times as needed. The preferred embodiment of the invention used cycles with the same duration, no shorter than two weeks and no longer than eight weeks. It is recommended to set this duration to six weeks, but each development team should decide on the length of the cycle, within the asserted limits.
The duration of the base development phase relates to the amount of functionality needed to be incorporated in the application framework, the base components and in the code generation. The present invention asserts that the duration of the Base Development Phase should not exceed twelve weeks.
The size of the team depends on the efficiency of the organization and of the individual team members, scope of the project and on the time to market expectations. However, higher efficiencies are achieved with smaller teams, typically not larger than eight developers plus the supporting roles.
A preferred team composition is shown in Figure 4. The roles and responsibilities of different members for a team employing the method proposed by this invention are:
1. Architect - responsible for a) the technical aspects of the project (architecture, design, coding standards); b) timely and cost effective solution delivery; c) management and coordination of team members; and d) interacting with the project's stakeholders, respectively;
2. Business Analyst - responsible for requirements gathering and analysis;
3. Developer - responsible for component design, code development and unit testing;
4. Defect Fixer - responsible to repair the defects identified by the testing team;
5. GUI Designer - responsible to develop the graphical interface templates, and support the development team, from a GUI perspective, during the cyclic development phase;
6. Database Architect - responsible for database design and database tuning;
7. Database Administrator - responsible for database tuning and optimization;
8. Tester - responsible to design and implement test cases that can be used for subsequent regression testing activities and run the test cases per cycle.
At the beginning of the development process, the client must identify the technology requirements of the software product. Technology is defined in terms of hardware platform, operating system, development language, application and database server choices. As mentioned in the above paragraph, the technological decision is to develop a Java/J2EE web application using a relational database for storage. Given the Java choice as a development language, which is operating system independent, choosing the hardware and operating system for the production system can be deferred to a later time, as long as the performance and capacity factors of the development vs.
production environment are known, or can be determined. In order for a relationship database product to be employable for the project, JDBC drivers must be available.
In parallel to technology identification, the team gathers high level requirements, at a detail level good enough to elicit enough information for the reference architecture to be built. Requirements gathering may be carried by talking to clients and subject matter experts with regards the system to be developed.
These requirements include both functional specifications, and non-functional expectations, such as performance, capacity or availability, respectively.
The commitment to a specific technology, and the identification of the high level requirements enables the development team to design the reference architecture. The outcome of the second step is the reference architecture model. The reference architecture is based on architecture and design patterns generally accepted as the best practice to solving common software problems.
The reference architecture also identifies the data definition points. These points are important for automating the code generation of business specific components. For a "N-tier"
application three data definition points are representative: a) persistent storage, b) business facades, and c) views. In very complex situations, the Reference Architecture may have to employ all three data definition points, and define data transformation strategies to obtain fully functional end-to-end code. A less expensive approach is to base the application on one data definition point only. The preferred embodiment of the invention uses the persistent storage as the unique data definition point, and assumes that this definition is sufficient to develop both presentation and business tier code. Teams that will implement this method will have to verify if this assumption is correct within the context of their development environment.
The reference architecture is documented using a software design modeling tool. The resulting model is subsequently used at end of this step to build the framework and base components. Persistent storage may be required by the framework design. Persistency may be achieved employing a database or file storage. If a database is needed to support the framework's technical functionality, it is designed and implemented during this step. A representative, high level Reference Architecture Model for an multi-tier Web application is shown in Figure 5.
Once both the framework and the base components have been developed, the architectural prototype can be developed. The prototype is based on a set of use cases representative for the overall functionality of the system. In the most generic terms, a data-centric web application allows users to search and view search results, create, update and delete a variety of data entities. The prototype can contain only the above mentioned operations for generic entities, such as person, or it may employ more complex functionality, requiring data aggregation, such as the ability to display personal information, as well as addresses on the same screen. The high level requirements and the application type prescribe the basic set of "must-have" functionality . This functional set will be used as input in specifying the requirements for a Code Generation tool. During the prototype development phase, the framework and base components are refined based on non-functional criteria, such as performance, capacity, scalability and maintainability, respectively.
Subsequent to the proof of concept, the prototype's functional components are transformed into templates, by abstracting the common parts and replacing specific variable names and types with placeholders. These templates are used as the starting point for developing the Code Generation application, which is able to produce fully functional, end-to-end code that supports the basic business functionality developed during the prototyping phase. For the preferred embodiment of the invention the following component types are generated:
1. Search View - allows users to input search criteria and submit the request 2. Search Results View - displays search results to user 3. Detail View - allows users to view details of a list entry 4. Edit View - allows users to view and edit details of a list entry and submit the changes 5. New View - allows users to create a new entity and submit the entry 6. View Handler - is a software component type employed to encapsulate logic relating to initiating content retrieval, validation, and adapting and formatting the model, while the View components handle presentation formatting. The Handler components subsequently forward the request to a Business Facade component.
7. Business Facade - provides large granularity interface to its clients by hiding the complexities of the business object interactions. The Business Facade is generally responsible to validate and process the request according to the business functional specifications. After business processing is completed, the Business Facade forwards the request to a Data Access Object if the request involves a create, read, update, or delete (CRUD) operation.
8. Data Access Object - a component of this type provides loose coupling between the business and persistence tiers. The Data Access Object intercepts and services all access to the resource tier, making the implementation details of the resource tiers transparent to the clients. The data in the resource tier can reside in database systems, proprietary systems, other external systems and services.
9. Value Object - provides best techniques and strategies to exchange data across tiers (that is, across system boundaries). This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
10. Filter - this component is responsible to clean inbound data requests and add reference data to outbound responses.
The input for the Code Generation application may be any data schema representation, or physical implementation, such as XMI representation of UML design, Database Definition Language, XML
Schema or a physical database, respectively. The preferred embodiment of the invention uses the physical database as input for the application, together with additional user entered data.
The Code Generation Application can be implemented as a GUI Application or just providing a command line interface to the user. An implementation of the Code Generator as a GUI Application is shown in Figure 6. The preferred implementation of the Code Generation application allows the user to:
1. Connect to a specific database server;
2. Select the database to use for code generation;
3. Select the table for which to generate components;
4. Specify the components' names;
5. Specify the package names for the business facade and helper components;
6. Specify the location of the generated code;
The Code Generation Application may also output other files, such as configuration files, or files containing SQL statements, necessary for the business components to perform CRUD operations.
To complete the Code Generation step, the team needs to test the correctness of the generated code. The preferred embodiment of the invention recommends to generate the code of the previous prototype and use the already developed test cases.
Once the Code Generation Application is completed, the GUI templates are finalized and the requirements for the first cycle have been gathered, the team can start planning the first cycle. The proposed invention requires cycles to have a fixed duration, and recommends this duration to be six weeks. During the planning phase the team decides how much can do within the cycle allocated time.
The planning step shall be completed in one day by the full team.
During the next step the development team needs to identify the data entities relevant to the current cycle and design the database schema. The design must be generic enough to account for other domain specific requirements that may be specified by subsequent cycle requirements.
The design should build on the design of the previous cycles. This is achieved by using a database design tool and using one design model only. The design may be partitioned along the business domain main entity lines, and also include support entities, required by the system framework.
Once the database design is finalized, the physical database can be generated and deployed on the database server. Test data rnay be generated and loaded during this step as well.
Once the database is accessible on the server, the Code Generation Application is employed to produce the business components for the different tables that are used during the cycle. It may well be possible that previously generated components are needed for the current cycle. The exemplified interface of the Code Generation Application uses a one-to-one mapping between tables and components. If data from more than one table has to be shown and maintained by the same set of screens, the Code Generation Application may be designed in such a way that data from multiple tables is allowed to be aggregated on screen, while the entity specific components are still independent of each other.
After code generation, the development team integrates the components into the existing code base.
This integration should not require modifying any of the existing code. In order to employ existing code, some customization of the newly generated components may be needed.
Alternatively, if more effort is spent in defining and developing the Code Generation Application, the tool may provide the capabilities needed to reuse available code.
Once the code is completed, the team will test it. There are many aspects of testing: unit testing, integration testing, end-user testing, performance testing, or load testing, respectively. The team will perform at least unit testing and end-user testing, verifying that the software product meets the functional requirements. Performance and load testing should be performed during the prototype step, and again at the end of the first cycle, to ensure the architecture meets the non-functional requirements.
In parallel to the development activities, the team also gathers requirements for the next cycle.
The client, or a sub-team also performs user acceptance testing.
The cycles end when no more functional requirements are to be implemented. As integration of code is integral to each cycle, there are no specific end of project activities required by the proposed invention.
Claims (6)
1. A method of producing a software product or family of software products comprising of:
i) A base development phase and, ii) A cyclic development phase.
i) A base development phase and, ii) A cyclic development phase.
2. A method as recited in claim 1 wherein step i) comprises the further step of:
i) Building a framework of reusable components, and a set of reusable base components.
i) Building a framework of reusable components, and a set of reusable base components.
3. A method as recited in claim 2 wherein it comprises the further step of:
i) Building a code generation tool to produce business specific components.
i) Building a code generation tool to produce business specific components.
4. A method as recited in claim 1 wherein step ii) of claim 1 comprises the further steps of:
i) Planning, ii) Designing, iii) Building the persistence data schema, iv) Generating functional components, v) Integrating components into the current code base and extending them as needed, vi) Testing components, vii) Deploying components, viii) Gathering requirements for next development cycle "N+1", ix) User acceptance testing for previous cycle, "N-1", components, and x) Fixing defects for components developed during cycle "N-1"and its predecessors.
i) Planning, ii) Designing, iii) Building the persistence data schema, iv) Generating functional components, v) Integrating components into the current code base and extending them as needed, vi) Testing components, vii) Deploying components, viii) Gathering requirements for next development cycle "N+1", ix) User acceptance testing for previous cycle, "N-1", components, and x) Fixing defects for components developed during cycle "N-1"and its predecessors.
5. A method as recited in claim 4 wherein step ii) comprises the further step of:
i) defining the data definition points and
i) defining the data definition points and
6. A method as recited in claim 5 wherein step i) comprises the further step of:
i) using data definition points for code generation.
i) using data definition points for code generation.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002497389A CA2497389A1 (en) | 2005-02-28 | 2005-02-28 | Method for development of a software product or family of software products |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002497389A CA2497389A1 (en) | 2005-02-28 | 2005-02-28 | Method for development of a software product or family of software products |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2497389A1 true CA2497389A1 (en) | 2006-08-28 |
Family
ID=36938911
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002497389A Abandoned CA2497389A1 (en) | 2005-02-28 | 2005-02-28 | Method for development of a software product or family of software products |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2497389A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103345386A (en) * | 2013-05-31 | 2013-10-09 | 电子科技大学 | Software production method, device and operation system |
| US9916228B1 (en) | 2016-04-01 | 2018-03-13 | Amdocs Development Limited | Apparatus, method, and computer program for software development testing utilizing one or more minimal testing features |
| CN110096265A (en) * | 2019-05-09 | 2019-08-06 | 趋新科技(北京)有限公司 | A kind of software design approach based on data flow and element, software design tool and software running platform |
-
2005
- 2005-02-28 CA CA002497389A patent/CA2497389A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103345386A (en) * | 2013-05-31 | 2013-10-09 | 电子科技大学 | Software production method, device and operation system |
| US9916228B1 (en) | 2016-04-01 | 2018-03-13 | Amdocs Development Limited | Apparatus, method, and computer program for software development testing utilizing one or more minimal testing features |
| CN110096265A (en) * | 2019-05-09 | 2019-08-06 | 趋新科技(北京)有限公司 | A kind of software design approach based on data flow and element, software design tool and software running platform |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7403901B1 (en) | Error and load summary reporting in a health care solution environment | |
| US6701345B1 (en) | Providing a notification when a plurality of users are altering similar data in a health care solution environment | |
| US6405364B1 (en) | Building techniques in a development architecture framework | |
| US6370573B1 (en) | System, method and article of manufacture for managing an environment of a development architecture framework | |
| US6662357B1 (en) | Managing information in an integrated development architecture framework | |
| US6256773B1 (en) | System, method and article of manufacture for configuration management in a development architecture framework | |
| US7139999B2 (en) | Development architecture framework | |
| US6324647B1 (en) | System, method and article of manufacture for security management in a development architecture framework | |
| US8645326B2 (en) | System to plan, execute, store and query automation tests | |
| Bass et al. | Architecture-Based Development. | |
| Eertink et al. | A business process design language | |
| Kazman et al. | Toward a discipline of scenario‐based architectural engineering | |
| JP2004530191A (en) | Internet hosting business application development system composed of web services | |
| JP2007535723A (en) | A test tool including an automatic multidimensional traceability matrix for implementing and verifying a composite software system | |
| O'Brien et al. | Software architecture reconstruction: Practice needs and current approaches | |
| US7657542B2 (en) | Software life cycle availability over the internet | |
| Bergner et al. | A componentware development methodology based on process patterns | |
| US20080183514A1 (en) | System and Methods for Using Solution Building Blocks | |
| CN114879939A (en) | Method, system, electronic device and storage medium for generating microservices | |
| AU2001253522B2 (en) | Method for a health care solution framework | |
| Stoermer et al. | Practice patterns for architecture reconstruction | |
| AU2001253522A1 (en) | Method for a health care solution framework | |
| CA2497389A1 (en) | Method for development of a software product or family of software products | |
| Eide | Quantification and traceability of requirements | |
| Richter | Performance Impact of the Command Query Responsibility Segregation (CQRS) Pattern in C# Web APIs |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |