Abstract: This invention is related with the Software Engineering Branch of Computer Science, ft is a new Software Development Process Model (SDPM) that describes novel set of rules and process guide to develop software related (web and desktop) applications with the benefit of early working model, freezed requirements. Reliable design and flawless implementation with reduced complexity. To make the development fast and with less cost, open source tools are also put remarkable impact.
Background information and prior art
There are so many software processing models are in use today. As most of these are built decades ago and the customer and market demand is changing very frequently. So lets have a lokk to the earlier available famous deveopment models and techniques, their disadvantages . these disadvantages are actual motivating force to invent this new model.
Waterfall Model
In Royce's original waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction
4. Integration
5. Testing and debugging
6. Installation
7. Maintenance
Refer Figure 1: Different Phases in Waterfall Model Disadvantages:
• Rigid design and inflexible procedure.
• Restricts Development of software by blocking movement back to a prior stage, that is, it restricts looping back to prior stages even if new changes surface which need to be accommodated.
• The requirement stage constituted gathering concrete specifications including both vague and some critical requirements collected together. As the requirements were frozen before moving to the design phase, using the incomplete set of requirement, a complete design was worked on. So, was the case with the code phase. Such an approach worked normally well for a small project requiring average amendments. In case of a large project, completing a phase and then moving back to reconstruct the same phase, incurred a large overhead. Use of frozen requirements was a worst approach as compared to the prototype approach giving the user immediate "look and feel" of the system in development. It could not be used for the interactive end user applications. Analysis & Design are the kind of Phases whose completion from different dimensions is not possible; hence we can never really say when we are done with these phases.
• It emphasizes on the use of fully elaborated documents for completion criteria of requirements and design phases. It is unnecessary to write elaborated specification for a product before implementation.
• Waterfall Model faced "inflexible point solutions" which meant that even small amendments in the design were difficult to incorporate late in design phase.
• Once a phase is done, it is not repeated again that is movement is from one phase to the next and the opposite is not supported. Deadlines are difficult to meet in case of large projects.
Prototype
The steps taken in the Prototype model:
1. Identify basic requirements -Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
2. Develop Initial Prototype - The initial prototype is developed that includes only user interfaces.
3. Review - The customers, including end-users, examine the prototype and provide feedback on additions or changes.
4. Revise and Enhance the Prototype - Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed.
Refer Figure 3: Prototype Model
Disadvantages:
1. It is difficult to map requirements directly to different increments. Include excessive user involvement. Poorly defined scope as scope of the product may varyincrement to increment.
2. After every iteration, the user gets a "look & feel "of the system. An overhead in the model is rapid context switching between various activities. Evaluation after each iteration involving user involvement consumes alot of time.
3. Identify key issues starting from the early iterations, not waiting for later iterations.
Focus appropriately starting from the first iteration to the upcoming ones. Use results of
the early iterations to manage the risks of the project.
Spiral Model
Ref Figure 4: Spiral Model
The steps in the spiral model iteration can be generalized as follows:-
1. The system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies to use them are decided. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
• evaluating the first prototype in terms of its strengths, weaknesses, and risks.
• defining the requirements of the second prototype.
• planning and designing the second prototype.
• constructing and testing the second prototype.
The following disadvantages are identified in this model:
1. The Spiral Model performance depends on the risk assessment expertise of the involved software team. If risk analysis is poor the end product will surely suffer.
2. Great care is taken by software developers to identify and manage resources of the project identifying aptly all possible risks making the spiral model people dependent. Another difficulty of the spiral model is adjustment of contract deadlines using the spiral model.
3. A number of risks, constraints, alternatives, models etc. need to be analyzed but never are these risks or objectives listed and no specific risk analysis technique is mentioned. Software developers begin with the vague idea of risk analysis according to their expertise.
4. For large projects expert software developers can produce efficient software products but in case of a complex large project absence of specific risk analysis techniques and presence of varying expertise can create a chaos. The model also demands considerable risk expertise.
Rapid Application Development
Rapid application development (RAD) refers to a type of software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.
Disadvantages:
1. -Reduction in scalability is because an application developed by following RAD begins as a prototype and evolves into a finished application.
2. Reduction in features occurs due to time boxing, where features are given to later versions to finish a release in a small amount of time.
3. For large projects, RAD requires a sufficient number of human resources to create a right team. Also RAD is not suitable for all types of application development. Ifthe system cannot be modularized properly building the components for RAD will be problematic.
V-Model
Refer Figure 2: V Model
The steps associated are:
Verification piiases:
1. Requirement analysis
2. Design
3. Coding
Validation phase:
1. User Acceptance testing
2. System testing
3. Integration testing
4. Unit testing
It has the following drawbacks;
• It addresses software development within a project rather than a whole organization.
• The V-Model is not complete as it argues to be, as it covers all activities at too abstracts level.
Observed Failures of others models
Spiral
This model purposed first time the concept of risk analysis. It was explained by Bary W Boehm in a detailed manner. It was not easy to implement. Its complex structure is found suitable for large scale projects only. But unfortunately it couldn't do well for large projects as well. For example:
The US military had adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003-2009), it had a two year iteration (spiral). The FCS should have resulted in three consecutive prototypes (one prototype per spiral— every two years). It was canceled in May 2009. The spiral model thus may suit small (up to $3 million) software applications and not a complicated ($3 billion) distributed, interoperable, system of systems.
Waterfall model
Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them. For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design
must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.
Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a design based on faulty predictions, and that does not account for the newly discovered problems.
Prototype Model
In general, it can be expected that individual prototype costs will be substantially greater than the final production costs due to inefficiencies in materials and processes. Prototypes are also used to revise the design for the purposes of reducing costs through optimization and refinement.
It is possible to use prototype testing to reduce the risk that a design may not perform acceptably, however prototypes generally cannot eliminate all risk. There are pragmatic and practical limitations to the ability of a prototype to match the intended final performance of the product and some allowances and engineering judgement are often required before moving forward with a production design.
V Model
The following aspects are not covered by the V-Model, they must be regulated in addition, or the V-Model must be adapted accordingly:
• The placing of contracts for services is not regulated.
• The organization and execution of operation, maintenance, repair and disposal of the system are not covered by the V-Model. However, planning and preparation of a concept for these tasks are regulated in the V-Model.
• The V-Model addresses software development within a project rather than a whole organization.
RAD- Rapid Application Development
Since rapid application development is an iterative and incremental process, it can lead to a succession of prototypes that never culminate in a satisfactory production application. Such failures may be avoided if the application development tools are robust, flexible, and put to proper use. This is addressed in methods such as the 2080 Development method or other post-agile variants.
When organizations adopt rapid development methodologies, care must be taken to avoid role and responsibility confusion and communication breakdown within a development team, and between team and client. In addition, especially in cases where the client is absent or not able to participate with authority in the development process, the system analyst should be endowed with this authority on behalf of the client to ensure appropriate
prioritization of non-functional requirements. Furtiiermore, no increment of the system should be developed without a thorough and formally documented design phase.
Dependence on strong cohesive teams and individual commitment to the project. Decision making relies on the feature functionality team and a communal decision-making process with lesser degree of centralized PM and engineering authority.
The client may create an unrealistic product vision and request extensive gold-plating, leading a team to over- or under-develop functionality
Programmers must work in pairs, which is difficult for some people. No up-front "detailed design" occurs, which can result in more redesign effort in the long term. The business champion attached to the project full time can potentially become a single point of failure for the project and a major source of stress for a team.
Agile
Short iteration may add too little functionality, leading to significant delays in final iterations. Since Agile emphasizes real-time communication (preferably face-to-face), using it is problematic for large multi-team distributed system development. Agile methods produce very little written documentation and require a significant amount of post-project documentation.
Claims
What is claimed:
1. Effective H model is a software development process model of software engineering to develop the software products/projects and software related applications. It is based on the two pillars of H shaped model. One believes in the delivery of early working build of software with the traditional way. Second pillar works on the concept of a sound and reliable software within the specified time with lowest cost and omits the essential drawback found in the other development process models.
2. The method of claim 1, further comprising reliable software by applying the concept of both QA (Quality Assurance) and QC (Quality Control) at different stages during the development of software products/projects.
3. The method of claim 1, further comprising development within specified time by introducing automation tools of various tasks as requirement, designing UMLs, ER diagrams, refactoring, code generators in various languages, cyclomatic complexity calculators, bug tracking tools.
4. The method of claim 1, further comprising to keep the cost lowest, for this Effective H model uses only the open source tools to accomplish the objective.
Title Effective H Model: A Software Development Process Model
Technical field
This invention is related with the Software Engineering Branch of Computer Science, ft is a new Software Development Process Model (SDPM) that describes novel set of rules and process guide to develop software related (web and desktop) applications with the benefit of early working model, freezed requirements. Reliable design and flawless implementation with reduced complexity. To make the development fast and with less cost, open source tools are also put remarkable impact.
Description of how invention addresses a teclinical problem (Summary)
The concept of H model is being represented in the figure 5. As whether the project is small or large today's client wants the full proof working solution as soon as possible. So in Effective H model we are giving the product as soon as we can(represented by the first pillar of Effective H model) but we cannot compromise today's technical challenges, business constraints, law enforcement changes, user friendly environment so we will deliver the final product in the next cycle (second pillar of Effective model) The following tasks/sequences will be present:
1. The early working H model is very simple. It starts quickly and sequentially as Requirements, Design, Coding, Implementation (Covered by the first pillar of Effective H model).
2. After the feasibility study. Starting phase is the requirements gathering. As we know that practically requirements are not fixed. So one copy of requirements will go for the system design phase and another copy will be send to second pillar of H model for freezed requirements after Risk Analysis, System Testing, Requirements Ambiguity check, Duplicacy, Business constraints and proper validation.
3. Here the working product is formed with classical approach by coding and implementation. Hence after 1^' pillar of Effective H model Ref FIG 5, we are having a working model that can be given to client to have hands on experience on that.
4. Verified design will be made from the freezed requirements and from the Design phase after Risk Analysis, Cohesion, Coupling Issues, Integration Testing, Database flaws of pillar I.
5. Effective code will be generated from the verified design and from the Unit Testing, Modularity, Cyclomatic Complexity, minimize code. Risk Control Exception handling of pillar I of Effective H model.
6. Most Reliable Implementation will be done by Risk Analysis, Production Server Issues Compatibility Testing-Hardware & Software.
Ofcourse the beauty of the Effective H model is in the second pillar of the model which includes Freezed Requirements, Verified Design, Effective Code and Most Reliable Implementation. The backwordarrows in the second pillars shows the cost effective roll back to correct the errors from the earlier phases, also see figure 6. These have been represented by small circles in the diagram and also cost effective rollback as if we correct the errors in the immediate next phase the cost will be less. However roll back to the previous phases are also allowed although very less necessity seems due to the effective work done during the construction of all the phases.
Differences from other models or edge over the other models:
Edge over Waterfall Model
Ref FIG.1 and FIG 5, Edge over waterfall model is due to phase rollback facility, early worable product, risk coverage and parallel testing.
Edge over Spiral Model
Ref FIG. 4 and FIG. 5, Edge over the spiral model is due to providing early workable model, easy to understand and implement alongwith the efficient risk coverage.
Edge over Prototype Model:
Ref FIG. 4 and FIG. 5, It gives early workable model (after implementation of 1*' pillar of H model) like in prototype models but it is different in terms of Risk Analysis and Phasewise testing, that is permitted in Effective H model only.
Edge over V Model:
Ref FIG. 2 and FIG. 5, It is different and effective from V model as It also allows phasewise and parallel testing. Edge over V model is due to providing early workable product and roll back facilities.
For detailed comparision refer to the figure 7. As Fig 7 makes the following points clear:
In Effective H Model it is easy to understand requirements, Risk Analysis at different Stages, Provides Early workable model. Possible to roll back to previous phases/cycles, Easy to understand, suitable for large Projectsand testing at each level provideseffective QA(Quality Asssurance) alongwith QC (Quality Control)whereas other models are lacking in many ways.
List of figures
7. FIG. 1 shows the steps associated with the Waterfall model.
8. FIG 2. Displays the working of V Process Model.
9. FIG 3. Shows the steps associated with Prototype Model.
10. FIG 4. Shows diagrammatically the concept of Spiral Model.
11. FIG 5. Represents the working of Effective H Model.
12. FIG 6. Show the cost of rollback from any development phase/cycle.
13. FIG 7. Shows the comparison among Effective H Model vs other famous Models.
Detailed description of the invention
The concept of H model is being represented in the figure 5. As whether the project is small or large today's client wants the full proof working solution as soon as possible. So in Effective H model we are giving the product as soon as we can(represented by the first pillar of Effective H model) but we cannot compromise today's technical challenges, business constraints, law enforcement changes, user friendly environment so we will deliver the final product in the next cycle (second pillar of Effective model) The following tasks/sequences will be present:
As we know that feasibility study is the very first step to start a project or to solve a problem. When we earn the information that the automated solution of a problem or manual work is feasible on the basis of system and business study related with that project. Our very next move is to set the unambiguous, traceable, complete and mainly freezed requirements. But we know that practically it is not feasible to havefreezed requirements. As projects lasts for years and requirements for the specific business changes over time or over availability of new hardware and software a component. Also in most of the time even clientsare not completely aware of their own elaborated needs from the project. So we need to give assistance of Business Analysts to let the client understand his own requirements. There are so many techniques to do so; one technique is to show the competitors working models or similar web based application. This can be done in Effective H model by let the client play with his own dummy code.After this requirement phase says the requirements gathering. As we know that practically requirements are not fixed. So one copy of requirements will go for the system design phase of 1^' pillar of Effective H Model and another copy will be send to the requirement phase of second pillar of H model.
Hence project can be started with the just known requirements and to deliver the final product in time, we will have freezed requirements in the 2nd Pillar of Effective H Model; refer FIG. 5.
Also defect prevention and quality assurance is a must do part of requirement phase of 2"'' pillar of Effective H Model. Risks associated with the uncertain concerns of requirements, extra features, business and law constraint are some very essential things will be covered. As we know it is requirements decides which type of system is needed as a working entity, so here at this stage we need to perform System Testing. BugzillaTestopia is a free test management tool that can help in to track of execution test cases and report to the bugziila (a bug tracking tool) internally.
To overcome the difficulty with change of requirements over time open source automated tools are used as to keep the requirements traceable any of the following tools can be used
■ Arbiter- An open source requirements gathering tool
and ARM (Automated Requirement Measurement).
• DorsGen - Diagram Oriented Requirement
Specification Generator.
Design Phase in Effect H model
The objective of the design phase is to plan a resolution of the problem specified through thesoftware requirement specifications. This phase is the very first step where wetransforming a problem domain to the solution domain. The design of a system is indeed the most precarious factor that the quality of the software, and also has a major imprint on the later phases, specially testing and maintenance the project. Design document is the output of this phase. This document is a blue print for the solution.
The design activity is divided into two sub phases-system design and detailed design. In system design the motivation is to identifying which modules and components are needed, during detailed design the internal logic how the components can be implemented of every module is specified. During this phase further details of the data structures and algorithmic design of all the modules is defined. The logic of a module is generallystated in a highlevel design description language. This is independent of the target language in which the software will be coded.
In the design phase, two distinct documents are produced. One for the system design and one for the detailed design. Together both of thisdocumentation provides the design of the system.
Problem partitioning and abstraction are key aspects in Effective H model Design. Partition a complex and large system into smaller sub systems. When partitioning is used while designing; the activities focus on a part of the system at one time. As one part being designed interacts with various parts of the system, a clear understanding of the interaction is essential for properly designing the part. For this, abstraction is used. Abstraction is a concept associated to problem partitioning. An abstraction of a system defines the behaviour of the system at an abstract level without giving the internal details.
Like every other phase, in Effective H Model the design phase ends with verification of the design. The verification has to be done by evaluating the design documents. At least two design reviews are held, one for the system design and one for the detailed design.
Ref FIG. 5, the design phase in 2nd pillar of Effective H model will be accomplished on two bases:
i) By utilizing the designs available with the first pillar and reuse the already done work.
ii) Adding the new DFDs, ER diagrams, UML's by taking concern with the Requirements of 2"'' pillar of effective H Model. To speed up the development and at the same time to keep the cost low, here we use the open source tools to assist design phase as described below:
+ D'zine - An open source tool to create DFDs and ER diagrams
• Star UML- An open source tool to assist drawing UMLs
FlameRobin - An open source database design tool.
■ Star UML- is an open source project to develop fast, flexible,
extensible, featureful, and freely-available for drawing UML.
• FlameRobin database design tool
DBDesigner 4 - DBDesigner 4 is a visual database design
system that integrates database design, modeling, creation and maintenance into a single,
seamless environment.
■ Edraw Max- enables to create flowcharts, UML diagrams,
database diagrams and more.
Further, to keep the cohesion (interaction within the module) high within the module and to keep coupling (interaction among different modules) as minimum; it is much time consuming to refactor the modules manually. So here also we can be benefited from the free open source Refactoring tools to manage the code reliably along with minimum complexity.
Refactoring Tools-
• RefactorlTis a comprehensive refactoring tool targeted at the needs of corporate developers.
EFFECTIVE CODING
Effective coding supported by 2"^ pillar of effective H model is basically inspired from 1^' pillar of H model coding and from the added modules or requirements depicted by the design of Z"'' pillar of Effective H Model, refer FIG. 5.To deliver the product in time; 2""^ pillar of effective H model use open source tools to generate effective code speedly. Any of the following open source tools are approachable in this respect:
a) Cog Python Active Inline Any code Java C# C++ C Perl Python Ruby TCL Javascript Fortran Lisp Scheme Cobol XSLT JSP PHP Yacc SQL XML System Configuration Files
b) Velocity apache- to generate cross-platform Java code.
c) OpenMDX - to generate cross-platform Java code.
d) MOLGENIS Morris Swertz- to generate cross-platform Java code.
e) AcceleoObeo - To generate cross-platform Java code.
f) CodeGenerator360- To generate C#.Net and ASP.NET Pages.
In coding phase to keep the project complexity low and to build a project that is further easy to test and maintain; cyclomatic complexity concept is must to apply.
To Check and monitor the code cyclomatic complexity, it is a tedious task to draw control flow graphs and calculate manually complexities for different modules of an entire project. So we are here going to use any of the following open source tool to count and maintain the complexity of a code. As we know generally project is maintained by different teams or persons thanthose who have developed it. Hence it is easy to understand for others than the persons developed it and hence feasible to manage the project during maintance phases in a neat and clear way.
a) Source Monito
b) EclipseMetrics Plugin
c) CCMTool
In this phase unit testing is another task need to be accomplished. Unit Testing: It is the very first testing done under QC (Quality Control) and done by the developer of the project/ product. Here is a list of few open source tools to provide assistance for this. As per the requirement of the project, Effective H Model uses any or many among thesedepends up which language code you need to test.
■ C Unit Test System: CUT is a simple, OS independent to-the-point unit testing system. It's different from other unit test packages in that it follows the KISS principle. It is designed for C testing.
■ CU: CU is simple and portable unit testing framework for UNIX to hand automated tests in C. CU features a simple interface for defining unit tests and perform regression tests.
• Splint: Splint is a tool for statically checking C programs for coding errors and security vulnerabilities. If effort is invested adding annotations to programs. Splint can perform stronger checking than is possible with traditional lints.
• Cobertura: Cobertura is a free OS independent Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage.
■ Fest: FEST is an open source library released under
the Apache 2.0 license, provides a powerful, yet easy to use API that makes the creation
(and maintenance) of functional tests for Swing GUIs simple.
Findbugs: It is a static analysis tool to find bugs in Java programs.
« Sonar: Sonar is an open source quality management
platform for Java, dedicated to continuously analyze and measure source code quality, from the project portfolio to the class method. Sonar leverages existing best of breed tools like Checkstyle, PMD, Findbugs, Clover, Cobertura and transparently orchestrate all those tools.
Nester: Nester is a tool for mutation analysis of your source code in order to assess the adequacy of your tests. It involves modification of programs to see if existing tests can distinguish the original program from the modified program.
« NUnit is a unit-testing framework for all .Net
languages. Initially ported from JUnit, the current version, 2.0 is the second major release
of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.
Testing & Implementationin Effective H Model
Although till this phase we have already applied so many techniques to preventour Build (Executable file/ copy of the project) from defects, faults by applying Quality Assurance as we have Verified and Validated requirements, executed test cases of Acceptance Testing, cross check the aspects of cohesion and coupling during the design phase and , executed test cases for Integration Testing , unit testing and cyclomatic complexity in coding phase. But still there are a few left that can be done after having the project/ product build. Here are mainly:
a) Functional Testing
b) Security Testing
c) Load Testing
d) Volume Testing
e) Stress Testing
jFunctional Testing: It is a black box testing technique. It is performed to check the various functionalities of a product or project. In actual the size of a project is very large. It is very time consuming to test all the project windows to test on unlimited choice of input values. After taking a look on the priorities of functionality to test, Effective H Model choices an automation tool to cover the functional testing criteria with in the given time frame. Here are the list of toolsthat might be used in Effective H Model for this purpose:
Selenium.'Selenium is a portable software testing framework for web applications. Selenium provides a record/playback tool for authoring tests without learning a test scripting language (Selenium IDE). It also provides a test domain-specific language (Selenese) to write tests in anumber of popular programming languages, including C#, Java, Groovy, Perl, PHP, Python and Ruby. The tests can then be run against most modem web browsers. Selenium deploys on Windows, Linux, and Macintosh platforms.
Performance Testing in Effective H Model:
a. j-hawk: j-hawk is a Java based open source framework which can be incorporated in your application for performance testing. The idea is you have to define *module and its tasks (means method) inside your application and register the same with j-Hawk. j-Hawk executes the modules and generates a graphical performance report which can be analyzed to find performance bottleneck of your application.
b. Multi-Mechanize: Multi-Mechanize is an open source framework for web performance
and load testing. It allows you to run simultaneous pj^hon scripts to generate load
(synthetic transactions) against a web site or web service.
c. p-unit: An open source framework for unit test and performance benchmark, which was
initiated by Andrew Zhang, under GPL license, p-unit supports to run the same tests with
single thread or multi-threads, tracks memory and time consumption, and generates the
result in the form of plain text, image or pdf file.
d. Pylot: Pylot is a free open source tool for testing performance and scalability of web
services. It runs HTTP load tests, which are useful for capacity planning, benchmarking,
analysis, and system tuning. Pylot generates concurrent load (HTTP Requests), verifies
server responses, and produces reports with metrics. Tests suites are executed and
monitored from a GUI.
e. stressdriver: It is a General-purpose stress test tool.
f FWPTT :fwptt is an open source Web application testing program for load testing web applications. It can record normal and AJAX requests. It has been tested on ASP.Net applications, but it should work with JSP, PHP or other.
g. J Meter: It is used to test your web service, database, FTP- or web server? Both performance and functional testing? Have a look at JMeter. It is free, very intuitive and has all the possibilities you need to automate your work. Another big advantage of JMeter: open source.
For SecurityTesting in Effective H Model
A) Nikto- is an Open Source (GPL) web server scanner which performs comprehensive
tests against web servers for multiple items, including over 6400 potentially dangerous
files/CGIs, checks for outdated versions of over 1000 servers, and version specific problems
on over 270 servers.
B) BFBTester- is great for doing quick, proactive, security checks of binary programs.
BFBTester will perform checks for single and multiple argument command line overflows
and environment variable overflows4. Netsparker - detect SQL Injection + cross-site
scripting issues.
Open Source Bugtracking Tools used for Effective H Model
Bugzilla/jira/Mantis : These are open source bug tracking tools that keep complete track of issues, proposed enhancements, bugs along with the project version, severity & Priority of bugs, OS and browsers where found bug can be reproduce. Actions taken to resolve these bugs. Also provide current status of found bugs. Hence testing and maintenance of the project can be done in more systematic way.
Hence due to its working, applied constraints, use of open source tools it is feasible for Effective H Model to deliver the desired product/ project within the time frame and with the lowest cost.
Of course the beauty of the Effective H model is in the second pillar of the model ref FIG. 5 which includes Freezed Requirements, Verified Design, Effective Code and Most Reliable Implementation. The backwardarrow in the second pillars shows the cost effective roll back to correct the errors from the earlier phases, also see figure 7. These have been represented by small circles in the diagram and also cost effective rollback ref FIG. 6 as if we correct the errors in the immediate next phase the cost will be less. However roll back to the previous phases are also allowed although very less necessity seems due to the effective work done during the construction of all the phases.
Claims
What is claimed:
1. Effective H model is a software development process model of software engineering to develop the software products/projects and software related applications. It is based on the two pillars of H shaped model. One believes in the delivery of early working build of software with the traditional way. Second pillar works on the concept of a sound and reliable software within the specified time with lowest cost and omits the essential drawback found in the other development process models.
2. The method of claim 1, further comprising reliable software by applying the concept of both QA (Quality Assurance) and QC (Quality Control) at different stages during the development of software products/projects.
3. The method of claim 1, further comprising development within specified time by introducing automation tools of various tasks as requirement, designing UMLs, ER diagrams, refactoring, code generators in various languages, cyclomatic complexity calculators, bug tracking tools.
4. The method of claim 1, further comprising to keep the cost lowest, for this Effective H model uses only the open source tools to accomplish the objective.
| # | Name | Date |
|---|---|---|
| 1 | 1241-DEL-2012-AbandonedLetter.pdf | 2019-10-30 |
| 1 | 1241-del-2012-Form-5.pdf | 2013-02-25 |
| 2 | 1241-DEL-2012-FER.pdf | 2018-06-19 |
| 2 | 1241-del-2012-Form-3.pdf | 2013-02-25 |
| 3 | 1241-del-2012-Claims.pdf | 2013-02-25 |
| 3 | 1241-del-2012-Form-2.pdf | 2013-02-25 |
| 4 | 1241-del-2012-Description (Complete).pdf | 2013-02-25 |
| 4 | 1241-del-2012-Form-18.pdf | 2013-02-25 |
| 5 | 1241-del-2012-Form-1.pdf | 2013-02-25 |
| 5 | 1241-del-2012-Drawings.pdf | 2013-02-25 |
| 6 | 1241-del-2012-Drawings.pdf | 2013-02-25 |
| 6 | 1241-del-2012-Form-1.pdf | 2013-02-25 |
| 7 | 1241-del-2012-Description (Complete).pdf | 2013-02-25 |
| 7 | 1241-del-2012-Form-18.pdf | 2013-02-25 |
| 8 | 1241-del-2012-Claims.pdf | 2013-02-25 |
| 8 | 1241-del-2012-Form-2.pdf | 2013-02-25 |
| 9 | 1241-DEL-2012-FER.pdf | 2018-06-19 |
| 9 | 1241-del-2012-Form-3.pdf | 2013-02-25 |
| 10 | 1241-del-2012-Form-5.pdf | 2013-02-25 |
| 10 | 1241-DEL-2012-AbandonedLetter.pdf | 2019-10-30 |
| 1 | SEARCH_STRATEGY_1241DEL2012_19-06-2018.pdf |