Genetibase - Software for your Scientific Success

Genetibase, Inc. feasibility studies are a preliminary study undertaken before the real work of a project starts to ascertain the likelihood of any project’s success. It is an analysis of possible solutions to a problem and a recommendation on the best solution to use. It involves evaluating how the solution will fit into your corporation. It, for example, can decide whether an order processing be carried out by a new system more efficiently than the previous one.

Main analysis reasoning is:

• The current system may no longer suit its purpose.

• Technological advancement may have rendered the current system obsolete.

• The business is expanding, not allowing it to cope with extra work load.

• Customers are complaining about the speed and quality of work the business provides.

• You are not winning a big enough market share due to an ineffective integration of a computerized system.

Within a feasibility study, we review four main areas, including those of Economic, Technical, Schedule and Organizational.

• Economic Feasibility:

o This involves questions such as whether you can afford to build the system, whether its benefits should substantially exceed its costs, and whether the project has higher priority than other projects that might use the same resources.

• Technical Feasibility:

o This involves questions such as whether the technology needed for the system exists, how difficult it will be to build, and whether the firm has enough experience using that technology.

• Schedule Feasibility:

o This involves questions such as how much time is available to build the new system, when it can be built (i.e. during holidays), interference with normal business operation, etc.

• Organizational Feasibility:

o This involves questions such as whether the system has enough support to be implemented successfully, whether it brings an excessive amount of change, and whether the organization is changing too rapidly to absorb it.

During the detailed-design phase, our development team will extend the architecture defined in preliminary design down to the unit level. Using successive refinement techniques, we will produce specifications for the programming. All formalisms for the project will be produced, including the following:

• Functional or object-oriented design
• Descriptions of all user input, system output (for example, screen, printer, and plotter), and input/output files
• Operational procedures
• Functional and procedural descriptions of each unit
• Descriptions of all internal interfaces between pages and functions

Our team documents these design specifications in the detailed-design document, which forms the basis for implementation. At the design review that concludes this phase, we will determine whether levels of detail and completeness are sufficient for coding to begin.

The process of prototyping involves the following steps:

• Identify basic requirements:

o Determine basic requirements including the input and output information desired. Details, such as security, can typically be deferred.

• Develop Initial Prototype:

o The initial prototype is developed that includes only user interfaces.

• Review:

o The customers, including end-users, examine the prototype and provide feedback on additions or changes.

• Revise and Enhancing the Prototype:

o 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.

We are a reliable provider of software development services. We offer professional software solutions to solve complex, mission-critical business problems. We supply our clients with cutting-edge and cost effective solutions which meet all their business needs. We have outstanding experience in custom application development, as well as various custom software components and web programming. Our primary goal is to meet all of our clients’ needs and requirements professionally and effectively.

We also believe that our high quality software development services provide a solid basis for a successful customer relationship. We employ continuous integration testing within the project, for which we believe is the most important parts of the development process and we strive to exclude any errors before the product is deployed.

Software engineering in general is a relatively young discipline, and is still developing. The methods for which we derive our discipline include:

• Aspects

o Aspects help programmers deal with utilities by providing tools to add or remove boilerplate code from many areas in the source code. Aspects describe how all objects or functions should behave in particular circumstances. For example, aspects can add debugging, logging, or locking control into all objects of particular types. Researchers are currently working to understand how to use aspects to design general-purpose code. Related concepts include generative programming and templates.

• Agile

o Agile software development guides software development projects that evolve rapidly with changing expectations and competitive markets. Proponents of agile software development believe that heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in importance. Some people believe that companies and agencies export many of the jobs that can be guided by heavy-weight processes. Related concepts include extreme programming and lean software development.

• Experimental

o Experimental software engineering is a branch of software engineering interested in devising experiments on software, in collecting data from these experiments, and in devising laws and theories from this data. Proponents of experimental software engineering advocate that the nature of software is such that we can advance the knowledge on software through experiments only.

• Software Product Lines

o Software Product Lines is a systematic way of producing families of software systems, instead of creating a succession of completely individual products. The Software Product Lines approach is an attempt to industrialize the software development process.

Our testing and evaluation services follow a predefined rigid process, typically incorporating: Test Documentation. (IEEE) Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report.

As well our Software Testing documentation, or Test Deliverables, usually consists of the following documents:
 
• Master Test Plan (sometimes it is possible to write separate documents for test planning: Unit test plan, Integration test plan, System test plan and Acceptance test plan)

We first define the Definition of the Test Plan. This is a high-level document that defines the software testing project, so that it can be properly measured and controlled. It defines the test strategy and organized elements of the test life cycle, including resource requirements, project schedule, and test requirements. Testing criteria is typically defined as follows:

• Test case design:

o Definition of Test Case. A set of test inputs, executions, and expected results developed for a particular objective.

• Test procedures:

o Definition of Test Procedure. A document, providing detailed instructions for the [manual] execution of one or more test cases. Often called - a manual test script.

• Test logs:

o Definition of Test Log. A chronological record of all relevant details about the execution of a test.[IEEE]

• Test data:

o Definition of Test data. The actual (set of) values used in the test or that are necessary to execute the test.

• As well as:

o Test summary report

o Automated test scripts

o Incident reports

o Incident log

A sample of a Master Software Test Plan document contents:

• Introduction
• Purpose
• Background
• Scope
• Project Identification
• Software Structure
• Software Risk Issues
• Test Requirements
• Features Not to Test
• Metrics
• Test Strategy
• Test Cycles
• Planning Risks and Contingencies
• Testing Types
• Functional Testing
• User Interface Testing
• Configuration Testing
• Installation Testing
• Volume Testing
• Performance Testing
• Tools
• Resources
• Staffing
• Training Needs
• Project Milestones
• Deliverables
• Test Assets
• Exit criteria
• Test Logs and Defect Reporting
• References

The increasing demand for complex software coupled with stiff competition for experienced software engineers has put many companies in the uncomfortable position of having to trade off Quality against Time to Market.

By defining and providing your organization with proven Software Verification & Validation techniques, Genetibase, Inc. can help you improve Quality and meet aggressive Time to Market goals.
 

Areas and techniques addressed:

• Economic Justification for Software V&V

• Overview of Software Development Lifecycle Models

• Overview of Software Verification Techniques

• Peer Review Process

• Practice Peer Review

• Overview of Software Validation Techniques

• Testing Levels, Methods, and Types

• Test Planning

• Concurrent Development Model

• Testing Measures

• Root Cause Analysis

• Triage

• Post-Mortems

• Common Testing Problems

• Action Plan

Our design specifications typically involve analysis for:

• Classification:

o The kind of component/application, such as a subsystem, module, class, package, function, files, etc….

• Definition:

o The specific purpose and semantic meaning of the component/application. This may need to refer back to the requirements specification.

• Responsibilities:

o The primary responsibilities and/or behavior of this component/application. What does this component/application accomplish? What roles does it play? What kinds of services does it provide to its clients? For some components/applications, this may need to refer back to the requirements specification.

• Constraints:

o Any relevant assumptions, limitations, or constraints for this component/application. This should include constraints on timing, storage, or component/application state, and might include rules for interacting with this component/application (encompassing preconditions, postconditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.)

• Composition:

o A description of the use and meaning of the subcomponents that are a part of this component/application.

• Uses/Interactions:

o A description of these components/applications collaborations with other components/applications. What other components/applications is this entity used by? What other components/applications do the entities use (this would include any side-effects this entity might have on other parts of the system)? This concerns the method of interaction as well as the interaction itself. Object-oriented designs will include a description of any known or anticipated subclasses, superclasses, and metaclasses.

• Resources:

o A description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a software library. This should include a discussion of any possible race conditions and/or deadlock situations, and how they might be resolved.

• Processing:

o A description of precisely how these components/applications go about performing the duties necessary to fulfill their responsibilities. This should encompass a description of any algorithms used; changes of state; relevant time or space complexity; concurrency; methods of creation, initialization, and cleanup; and handling of exceptional conditions.

• Interface/Exports:

o The set of services (resources, data, types, constants, subroutines, and exceptions) that are provided by this component/application. The precise definition or declaration of each such element should be present, along with comments or annotations describing the meanings of values, parameters, etc…. For each service element described, include (or provide a reference) in its discussion a description of its important software component attributes (Classification, Definition, Responsibilities, Constraints, Composition, Uses, Resources, Processing, and Interface).

Genetibase, Inc. employs the SEI’s Architecture Tradeoff Analysis Method® (ATAM®). This is the leading method in the area of software architecture evaluation. An evaluation using the ATAM method typically results in:

• Clarified quality attribute requirements
• Improved architecture documentation
• Documented basis for architectural decisions
• Identified risks early in the life-cycle
• Increased communication among stakeholders

Business drivers and the software architecture are elicited from project decision-makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver.

The most important results are improved architectures. The output of an ATAM is an out-brief presentation and/or a written report that includes the major findings of the evaluation. These are typically:

• The architectural styles identified
• A “utility tree” - a hierarchic model of the driving architectural requirements
• The set of scenarios generated and the subset that were mapped onto the architecture
• A set of quality-attribute specific questions that were applied to the architecture and the responses to these questions
• A set of identified risks
• A set of identified non-risks

The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation. Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage. After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation. The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back.

Prototypes are mock-ups of the screens of an application which allow users to visualize the application that is not yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. When they were first introduced the initial results were considered amazing. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably.

Genetibase, Inc follows a predefined rigid process for Database Design, typically consisting of the following in order:
   
• Determine the purpose of your system
• Determine the tables that you need in your system
• Determine the fields that you need in the tables
• Identify fields with unique values
• Determine the relationships between tables
• Refine the design
• Add data (populate tables) and create other system objects

Some of the listed steps (determining tables, data fields and relationships) may cross and be repeated a few times when designing a relational database.
Building a database is a process of examining the data that is necessary and useful for an application, then breaking it down into a relatively simple row and column format.

The most basic reason for a software company to localize its software products is to increase revenue and net income. The logic is very simple: Higher total revenue compensates larger costs on research and development, and product marketing costs. Larger budgets allow creating better products and better chances of dominating the market’s niche.

Typical software localization follows these steps:

• Extracting the user interface elements:

o We analyze the program source to locate all translatable elements and prepare them for translation. A typical application includes many types of text elements —strings, menus, command, and dialog boxes— but also bitmaps, icons, and even sound or video clips. During the analysis, we also verify that there is no “hard coding” left, that all the interface elements have been separated from the code, and that any concatenation is clearly marked.

• Rebuilding the original interface:

o During the analysis, we rebuild the entire user interface to verify that all the elements are available. We also verify that the installation module and all other on-line elements have been considered (demo versions, on-line samples and tutorials).

• Building pseudo-translated application:

o Software localization usually takes place during the last stage of the development, when the original product is undergoing final revisions. To verify that all internationalization guidelines have been followed, we can quickly produce a pseudo-translated version of the user interface. This version is tested by the QA division to locate potential problems and address them before they affect the localization process.

• Preparing the translation kit:

o Each element of the user interface is prepared according to the tools that will be used by the translators. Translation memories are applied to the text elements to leverage existing translations and increase the consistency between different products from the same family.

• Translating the user interface:

o Our software translators use industry-standard terminology and client specific glossaries to achieve a high level of acceptance within the target market. During the translation process, they work with the engineering team to ensure that the locale conventions are followed.

• Resizing the dialogs and other UI elements:

o After translation, a localization engineer resizes the dialog boxes and verifies that all elements of the new user interface display correctly.

• Building and testing the localized application:

o When all the resources have been resized, the application is compiled and a team of language testers verify that the translated interface is accurate and displays correctly on the localized version of the operating environment.

• Delivering the localized application:

o When the localized interface has been tested and all the last minute changes incorporated, the localized resources are delivered to the client. Our entire team stays “on call” and fully available to ensure a smooth product release.

• Analysis of existing code and/or architecture (scope definition)

• Evaluation of available tool options (e.g. conversion libraries, emulators)

• Design work for UI/functional changes

• Implementation work for UI/functional changes

• Build the software for the target platform

• Debug on the target platform

• Perform final test and Quality Assurance (QA) functions on the target platform

• Integration of source patches back into the main build tree for archiving and revision control

• Upgrade of documentation relative to the new platform