Most of us don’t know what is a baseline actually? So let us first clear up what does it actually means?
Generally a baseline is defined as a line that forms the base for any construction or for measurement, comparisons or calculations. In the context of engineering and science it refers to the point of reference. Other tests like load tests, stress tests, resilience tests; baseline tests also form a very essential and important part of the performance testing.
It’s a very crucial part of a good software system or application.
Baseline testing is very famous for improving the overall performance of the software system. It has been found that the baseline testing identifies nearly 85 percent of the software system or application issues.
Baseline testing also helps a great deal in solving most of the problems that are discovered. A majority of the issues are solved through baseline testing.
The whole implementation and idea of how the baseline testing should be performed should be clear in the mind of the software tester. He should know that why the baseline testing is being done?
Some questions ?
- What is the baseline testing referring to in the software system or application?
- How the baseline testing is to be carried out or what is the test plan?
- How the baseline tests are to be executed?
- How this baseline testing differs from performance testing?
Advantages of Baseline Testing
- The main advantage here is that a large amount of time is saved by baseline testing.
- Actually it saves the time overhead.
- If we look at the whole scenario, the performance testing is the most time consuming process and complex also. Often the software testers or developers are not able to spare that much time for carrying out the performance testing very efficiently. So usually what some testers do is that they reduce the number of baseline tests. But the fact is that the baseline testing only saves much of the time.
- Reducing the number of baseline tests causes potential errors and bugs which in turn consume more time later in getting identified and corrected.
- Baseline testing is where most of the time can be saved.
- A performance testing plan must compulsorily include baseline testing and load testing. If more time is there endurance testing, volume testing and stress testing should also be included.
The testers or the developers should have a clear and good understanding of the testing that is to be performed.
- Baseline is usually performed for each script with 1, 2, 5, 10, 20, 30 and at the most 50 users to check the baselines.
- This is done typically for determining the response times. Generally baseline tests are carried out for each individual script that is a part of the load testing and any identified problem is immediately isolated.
- To get good and useful results the baseline tests should be executed at least for 20- 30 minutes.
- In baseline testing the test data is not lost when a test run fails and the data can be prepared for the next test quickly.
- Baseline testing reduces the time consumption of load testing also.
- Baseline testing should be properly monitored. Improper monitoring requires repetition of tests which is again wastage of time.
- Expecting meaningful results without proper monitoring is meaning less. Time over time baseline testing has proved itself to be a very important part of performance testing.
- Baseline testing shows the improvement of the software system or application when the problems and errors are fixed.
- Baseline testing should be done carefully without adhering to any shortcuts. By the time you begin the load testing, your software system will already be performing well.
Monday, December 26, 2011
What are different characteristics of baseline testing?
Posted by
Sunflower
at
12/26/2011 01:45:00 PM
0
comments
Labels: Advantages, Application, Architectural design, Baseline testing, Baselines, Developers, Issues, Performance, Performance testing, Point of refernece, Problems, Software Systems, Test Plan, Tests
![]() | Subscribe by Email |
|
Monday, July 25, 2011
How to assess alternative architectural designs?
There are many architectural alternatives that need to be assessed. There are different ways to assess the design:
Trade off Analysis Method
It establishes an iterative evaluation process for software architectures. It involves six steps:
- All the scenarios are collected.
- Requirements, constraints and environment description are elicited.
- Architectural styles or patterns chosen to address scenarios and requirements are described.
- Quality attributes are evaluated.
- The sensitivity of quality attributes to architectural attributes are identified.
- Critique candidate architectures using sensitivity analysis.
Architectural Complexity
In architectural complexity, the dependencies between the components are assessed within the architecture. Dependencies can be divided into:
- Sharing dependencies represent dependence relationship among consumers or producers.
- Flow dependencies represent dependence relationships between producers and consumers of resources.
- Constrained dependencies represent constraints on the flow of control among set of activities.
Architectural Description Languages
Architectural description language provides a semantic and syntax for describing a software architecture. It is a set of tools and notation that allows the design to be represented in an unambiguous and understandable fashion.
Posted by
Sunflower
at
7/25/2011 02:47:00 PM
0
comments
Labels: Architectural, Architectural Description Language, Architectural design, Assessment, Complexity, Dependency, Design, Languages, Relationships, Semantics, Software, Syntax, Trade off analysis
![]() | Subscribe by Email |
|
Thursday, July 14, 2011
What are the principles of Design Modeling?
Design models provide a concrete specification for the construction of the software. It represents the characteristics of the software that help the practitioners to construct it effectively. Design modeling represents the dummy model of the thing that is to be built. In software systems, the design model provides different views of the system.
A set of design principles when applied creates a design that exhibits both internal and external quality factors. A high quality design can be achieved.
- The work of analysis model is to describe the information domain of problem, user functions, analysis classes with methods. The work of design model is to translate information from analysis model into an architecture. The design model should be traceable to analysis model.
- A data design simplifies program flow, design and implementation of software components easier. It is as important as designing of processing functions.
- In design modeling, the interfaces should be designed properly. It will make integration much easier and increase efficiency.
- Design should always start considering the architecture of the system that is to be built.
- End user plays an important role in developing a software system. User Interface is the visible reflection of the software. User Interface should be in terms of the end-user.
- Component functionality should focus on one and only one function or sub-function.
- In design modeling, the coupling among components should be as low as is needed and reasonable.
- Design models should be able to give information developers, testers and people who will maintain the software. In other words, it should be easily understandable.
- Design models should be iterative in nature. With each iteration, the design should move towards simplicity.
Posted by
Sunflower
at
7/14/2011 11:52:00 AM
0
comments
Labels: Architectural design, Attributes, Customer, Data, Design Modeling, Domain, Functions, Internal, Models, Principles, Representation, Requirements, Software
![]() | Subscribe by Email |
|
Tuesday, March 15, 2011
How do we map data flow into a software architecture?
In architectural design, the mapping method uses data flow characteristics to derive a commonly used architectural style. A data flow diagram is mapped into program structure using one of the two mapping approaches:
- Transform Mapping
- Transaction Mapping
Structured design is often characterized as a data flow oriented design method because it provides a convenient transition from a data flow diagram. This type of information flow is the driver for the mapping approach.
Transform Flow: The overall flow of data occurs in a sequential manner and follows one, or only a few straight line paths. When a segment of a data flow diagram exhibits these characteristics, transform flow is present.
Transaction Flow: Information flow which is characterized by single data item called a transaction that triggers other data flow along one of many paths. When a data flow diagram takes this kind of form then transaction flow is present.
TRANSFORM MAPPING
It is a set of design steps that allows a data flow diagram with transform flow characteristics to be mapped into a specific architectural style.
- Review the fundamental system model.
- Review and refine data flow diagrams for the software.
- Determine whether the data flow diagram has transform or transaction flow characteristics.
- Isolate the transform center by specifying incoming and outgoing flow boundaries.
- Perform first level factoring.
- Perform second level factoring.
- Refine the first iteration architecture using design heuristics for improved software quality.
TRANSACTION MAPPING
In transaction mapping, information flow along two of the three action paths accommodates additional incoming flow. Each action path flows into a single transform, display messages and status. The design steps for transaction mapping is similar with a major difference lies in mapping of data flow diagram to software structure.
- Review the fundamental system model.
- Review and refine data flow diagrams for the software.
- Determine whether the data flow diagram has transform or transaction flow characteristics.
- Identify the transaction center and the flow characteristics along each of the action paths.
- Map the data flow diagram in a program structure amenable to transaction processing.
- Factor and refine the transaction structure and the structure of each action path.
- Refine the first iteration architecture using design heuristics for improved software quality.
Once an architecture has been derived, it is elaborated and then analyzed against quality criteria.
Posted by
Sunflower
at
3/15/2011 01:07:00 PM
0
comments
Labels: Architectural, Architectural design, Characteristics, Data Flow Diagram, DFD, Information, Mapping, Methods, Paths, Segments, Software, Steps, Transaction Mapping, Transform Mapping
![]() | Subscribe by Email |
|
Monday, March 14, 2011
Architectural Design - Refining the Architecture into Components and Describing Instantiations of the System
Refining the Architecture into Components
As the software architecture is refined into components, structure of the system begins to emerge. Components of the software architecture are derived from three sources:
- the application domain
- the infrastructure domain
- the interface domain
Because analysis modeling does not address infrastructure, one should allocate sufficient design time to consider it carefully.
In order to find the components that are most suitable for refining the software architecture, you need to start by using the classes which were described in the analysis model. The analysis classes in turn are representations of business entities that architecture is trying to describe. You could also base these components on an infrastructure model rather than the business model. If you went purely by the business model, you would not be able to depict many of those infrastructure components such as database components, components used for communication etc.
Whatever interfaces are described in the architecture context diagram imply one or more specialized components that process the data that flow across the interface.
Describing Instantiations of the System
The context of the system has been represented, the archetypes indicating important abstractions are defined, the overall structure of system apparent and major software components are identified, however further refinement is necessary which is accomplished by developing an actual instantiation of architecture. The architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.
Posted by
Sunflower
at
3/14/2011 10:17:00 PM
0
comments
Labels: Analysis Classes, Archetypes, Architectural, Architectural design, Classes, Define, Design, Domain, Entity, Infrastructure, Models, Refining, Representation, Software, Software Architectue, Structure
![]() | Subscribe by Email |
|
Architectural Design - Representing the System in Context and Defining Archetypes
As architectural design begins, the design should define the external entities that the software interacts with and nature of the interaction. Once the context is modeled and all external interfaces are described, the structure of the system is specified by the designer. It is done by defining and refining software components that implement the architecture.
REPRESENTING THE SYSTEM IN CONTEXT
Architectural context represents how the software interacts with entities external to its boundaries. A system context diagram accomplishes this requirement by representing the flow of information into and out of the system. At the architectural design level, a software architect uses an architectural context diagram to model the manner in which software interacts with entities external to its boundaries.
How do systems inter-operate with the target system?
Superordinate Systems
These systems use the target system as part of some higher level processing scheme.
Subordinate Systems
These systems are used by the target system and provide data or processing that are necessary to complete target system.
Peer-level Systems
These systems interact on a peer-to-peer basis.
Actors
These entities interact with the target system by producing or consuming information necessary for requisite processing.
Each of these external entities communicates with target systems through an interface.
DEFINING ARCHETYPES
Archetypes are the abstract building blocks of an architectural design. It is a class or pattern that represents a core abstraction that is critical to design of an architecture for the target system. Archetypes can be derived by examining analysis classes defined as part of analysis model.Target system architecture is composed of these archetypes which represent stable elements of the architecture. Some kind of archetypes are:
- Nodes
- Detector
- Indicator
- Controller
Posted by
Sunflower
at
3/14/2011 07:38:00 PM
0
comments
Labels: Archetypes, Architectural, Architectural design, Components, Context, Define, Design, Diagram, Entity, Information, Interactions, Patterns, Structure, Styles, Target
![]() | Subscribe by Email |
|
Wednesday, March 9, 2011
How is data designed at architectural and component level?
Data Design at Architectural Level
Data design translates data objects defined during analysis model into data structures at the software component level and, when necessary,a database architecture at the application level.
There are small and large businesses that contains lot of data. There are dozens of databases that serve many applications comprising of lots of data. The aim is to extract useful information from data environment especially when the information desired is cross functional.
Techniques like data mining is used to extract useful information from raw data. However, data mining becomes difficult because f some factors:
- Existence of multiple databases.
- Different structures.
- Degree of detail contained with databases.Alternative solution is concept of data warehousing which adds an additional layer to data architecture. Data warehouse encompasses all data used by a business. A data warehouse is a large, independent database that serve the set of applications required by a business. Data warehouse is a separate data environment.
Data Design at Component Level
It focuses on representation of data structures that are directly accessed by one or more software components. Set of principles applicable to data design are:
- Systematic analysis principles applied to function and behavior should also be applied to data.
- All data structures and operations to be performed on each should be identified.
- The content of each data object should be defined through a mechanism that should be established.
- Low level data design decisions should be deferred until late in design process.
- A library of data structures and operations that are applied to them should be developed.
- The representation of data structure should only be known to those modules that can directly use the data contained within the structure.
- Software design and programming language should support the specification and realization of abstract data types.
Posted by
Sunflower
at
3/09/2011 05:45:00 PM
0
comments
Labels: Analysis Model, Application, Architectural, Architectural design, Component Level Design, Data, Data Design, Data structure, data warehousing, Databases, Design, Levels, Structures
![]() | Subscribe by Email |
|
Thursday, March 3, 2011
How do we create an architectural design....an overview
Design is an activity concerned with making major decisions, often of a structural nature. It is a multi-step process in which representations of data and program structure, interface characteristics, and procedural detail are synthesized from information requirements.
Architectural design represents the structure of data and program components that are required to build a computer based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system. A software engineer can design both data and architecture, the job is often allocated to specialists when large, complex systems are to be built. A database or data warehouse designer creates the data architecture for a system. The system architect selects an appropriate architectural style for the requirements derived during system engineering and software requirements analysis.
Architectural design provides with the big picture and ensures that you have got it right in a same manner as before building a house, you need a blueprint. Architectural design begins with data design and then proceeds to the derivation of one one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analyzed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.
An architecture model encompassing data architecture and program structure is created during architectural design. In addition, component properties and relationships are also described. At each stage, software design work products are reviewed for clarity, correctness, completeness, and consistency with requirements and with one another.
Posted by
Sunflower
at
3/03/2011 08:21:00 PM
0
comments
Labels: Architectural design, Architecture, Completeness, Components, Correctness, Design, Design models, Models, Patterns, Process Requirements, Representation, Steps, Structure, Work Products
![]() | Subscribe by Email |
|