Compare Test Driven Development and Traditional Testing?

Till many years the traditional testing was in use until there was a rise of another software development strategy or process called the test driven development. These two development processes are in great contrast to each other. 

This article is focussed entirely up on the differences between the two types of development i.e., the traditional testing and the test driven development. So let us begin by describing the test driven development. 

About Test Driven Development

- The test driven development process is comprised of the repetition of very short development cycles.

- By short here we mean the development cycles in the test driven development are shorter than the usual normal cycles. 

- These development cycles comprise of the following tests:

1. Production of code: This step involves the creation of some code implementing which the code can only pass the test and does not incorporates any new functionality.
2. Execution of the automated tests and observing their success.
3. Re-factoring of code: This step involves the cleaning up of the code.
4. Repetition: The whole cycle is repeated for the improvement of the functionalities. 

- The test driven development was considered to be somewhat related to the test- first programming concepts of the extreme programming long since. 

- After that it came to be as an individual software development process. 

- The test driven development has prove to be quite effective for developing ad improving the legacy code that has been developed using the older development techniques. 

- So many development styles for the test driven development have been identified like those mentioned below:

1. Fake it till you make it
2. Keep it simple stupid or KISS
3. You ain’t gonna need it or YAGNI

- In the test driven development the primary focus is on writing the code which is necessary only to pass the tests to keep the design clean and clear of the fuzz.

About Traditional Testing

 Now coming to the traditional development methodologies or approaches, they are commonly called as the engineering approaches and they were defined at the very beginning of the software sciences. 

- Traditional development methodologies were developed to control the software development processes via a disciplined approach whose build and the stages were predictable.

- In the traditional software development methods, the stages of analysis and design precede the stage at which the software is build. 

- Unlike the test driven development process, these traditional development process are well documented .

- Their main disadvantage is that they are quite difficult to apply because of their complexity.

- Another disadvantage being that the traditional development methodologies are bureaucratic.

- In practical, these traditional development processes often cause a high level of complexity in the software system or application. 

- In traditional approaches there are two main stages namely:

1.      Stage of analysis and

2.      Stage of design

-The foundation of the whole project depends up on these two stages, therefore it is necessary that adequate focus is on these two stages and more and more efforts should be put on these stages. 

- For the project to be successful it is important that the traditional method is applied in the right way.

- Designing is considered to be a highly creative activity. 

- It becomes very difficult to plan and predict these complex methodologies as the level of their creativity increases. 

- The main feature of the traditional development processes is the detailed planning and designing phase. 

- Traditional development holds good when it comes to undertaking very large projects involving higher risk. 

- One more commonly observed thing is that the projects development with the traditional methodologies last longer. 

What are different aspects of Crystal Methods?

Crystal methods together constitute a family of methods called the “crystal family” and were introduced by the Alistair Cockburn around the year of 1990. Cockburn developed these methods after carrying out some interviews of the development teams and observed that some of the teams even though did not made use of the formal methodologies of software development were successful in delivering successful software projects and products. 

The crystal family he introduced can be thought of as a catalogue that includes their methodologies for delivering the successful projects and products. These crystal methods have been categorised under the category of the light weight methodologies. The term “crystal” in the context of the software engineering implies a view on the underlying core of values and principles and the faces are the means representing the standards, roles, tools and techniques.

Cockburn differentiated the methodologies, techniques and policies as:

1. Methodologies: set of elements like tools and practices.
2. Techniques: include skill areas like development of use cases.
3. Policies: statements dictating the must haves of the organizations.

Aspects on which Crystal Methods are Focused

- Below mentioned are the aspects up on which the crystal methods are focused:

1. Interaction
2. People
3. Skills
4. Community
5. Communications
6. Talents and so on.

- Cockburn stated that the above mentioned aspects are much important than the process which should be the secondary focus. 

- Crystal methods are based up on the idea of having variant talented and skilled individuals in the development team so that process element does not pose up a major factor. 

What makes the crystal methods the easiest agile software development method? 

- Crystal methods are very much tolerant to the issue that the teams can complete a task in several different ways.

- Crystal methods over the time have proven to be very effective in avoiding the rigid and strict processes (that were typical of the older development methodologies) and that is why they are very flexible. 

- Cockburn eventually developed may types of crystal methods for each and every type and kind of development team which are required to solve diverse problems. 

- These crystal methods are categorized by different color label denoting the weight of the methodology to be used. 

What are seven crystal methods?

- The crystal family of methodologies consist of seven crystal methods:

1. Crystal clear
2. Crystal yellow
3. Crystal orange
4. Crystal orange web
5. Crystal red
6. Crystal maroon
7. Crystal diamond
8. Crystal sapphire

- Depending up on the size of the project, the colour darkens from left to right. 

- The crystal methods have been scaled to the international standards based up on the size and criticality of the teams.

Properties of Crystal Methods

For all the seven crystal methods, some common properties have been defined as mentioned below:

1. Reflective improvement which involves taking breaks from the regular development routine and think and come up with ways of improving the process.
2. Personal safety involves free speaking within a group.
3. Easy access to expert users.
4. Frequent delivery is the measure of the ability of the method to frequently deliver the iterations of the software product or project. The features to be included in the iterations are decided up on by the developers and the designers.
5. Osmotic or close communication involves flow of information among the teams in a room.
6. Focus involves focusing up on direction in which the project development is taking place and individual task.
7. Technical environment inclusive of the automated tests, frequent integration and configuration management.  

What we can do to avoid browser incompatibility?

Malfunctioning of the web sites across various browsers has become a topic of utter annoyance.

Why it happens so that your web site functions perfectly well on one browser and at the same time fails to perform well in some other browser?
Why it appears to be missing some thing while it appears as proper on other browsers?

The root cause of all such errors and differences is the browser incompatibility.

WHAT IS BROWSER INCOMPATIBILITY & TOOLS FOR DETECTING BROWSER INCOMPATIBILITY

- There are various tools that can help you across detecting the browser incompatibility.

- Such tools check for the browser incompatibility by comparing the various snap shots of the web site operating under various web browsers.

- Different browsers and different browser versions all add up to the browser incompatibility.

- Browser incompatibility though cannot be eradicated fully; it can be at least reduced to a certain extent.

- Though the browser is only to be blamed for its incompatibility, the measures to reduce or avoid it can be taken from both sides.

- It can be done by improving either the standards of the browser or by taking care of the web site.

- If the web site in its design and code is good, incompatibility will be noticed less.

WHY INCOMPATIBILITY ARISES?

- It arises either because of the incompatibility of the web browser or because of the problems in the web site itself.

- So you need to focus on the design an implementation of your web site rather than bogging up yourself with the browser issues.

- Employing cutting edge HTML can also run you in to the incompatibility problems as the HTML standards usually are a way step ahead of what is supported by the web browsers.

- Till now, no such browser has been developed that will take in to consideration 100 percent HTML.

- No doubt there are certain browsers that are a bit close to this value than the others.

- Using latest versions and standards of the HTML is always not a good choice. So be wise when you choose the version of HTML for designing up your web site.

- Another fact to be kept in mind is that not all the web browsers are equally efficient in translating the HTML code in to formatted web sites.

- There are some browsers that may leave certain parts of the HTML code because they are not able to execute it and again you will have trouble with your browser compatibility.

- Also all the web browsers do not translate a web page in the same manner and don’t give the same results.

- Before you start building up your web site, check out the compatibility of the different browsers so that you will have an idea what all formats and standards they support and you can build your site according and simultaneously avoiding a bug deal of incompatibility.

- After you have finished developing your web site, have your pages validated. If you are getting errors in your web site try out the trail and error debugging method.

Though the World Wide Web consortium has specified the standards for using HTML, you can very well invent your own and design your web site accordingly. But this has a disadvantage that the browser may reject the parts that cannot be executed and the appearance and functioning of your web site will be affected.

The basic difference between the two versions of a browser lies in the support they provide for the HTML. But on top of all it would be better if you pay attention to the browser compatibility while designing your web site. This will prevent you from running in to future issues regarding the incompatibility of the browser.

What are different rules of thumb to write good test cases?

Writing good and effective test cases requires great skills since after all effective testing is achieved by effective test cases only!

Writing such test cases is a great skill in itself and can only be achieved by in depth knowledge of the software system or application on which the tests are being carried out and it also requires some experience.

Here I’m going to share some rules of thumb to write effective test cases, basic test cases definition and test case procedures.

What is a test case actually?
A typical test case is comprised of components that are meant to describe an action or event, input and an expected outcome in order to determine whether the software system or application is working as it is meant to or not.

Before writing a test case you should know the 4 levels or categories of the test cases to avoid their duplication.
The levels have been discussed below:

Level 1:
This level involves writing of basic test cases using the available specifications and requirements and documentation provided by the client.

Level 2:
This level is the practical stage and it involves writing of test cases based on the actual system flow and functional routines of the software system or application.

Level 3:
This level involves grouping of some particular test cases. Some test cases are grouped together and a test procedure is written. A test procedure can have maximum up to 10 test cases.

Level 4:
This level involves the automation of the project. This leads to minimization of the human’s interaction with software system or application. This is done basically to maximize the focus upon the currently updated functionality to be tested rather than focusing on regression testing.

Following this whole pattern you can have an automated testing suite from no testable item, i.e., you can observe a systematic growth.
- The tester should know the objective of each and every particular test case.
- The basic objective of all the test cases is to validate the testing coverage of the software system or application.
- You need to strictly follow test cases standards. Writing test cases reduces the chances of following an ad- hoc approach.

Below given is a basic test case format:
- Test case id
- Units to be tested
- Assumptions
- Input /test data
- Execution steps
- Expected outcome
- Actual outcome
- Success or failure
- Observation
- Comments

You need to write a test case statement also. So here’s the basic format:

- Verify:
This is the first word of the test case statement.
- Using tool names, tag names, dialogues etc: this is basically to identify what is being tested.
- Verification with conditions.
- Verification to result.

For any kind of testing:

- You will cover all types of tests like functional test cases, negative value test cases and boundary value test cases.
- Be careful while writing the test cases.
- Keep it simple and easy to understand.
- Don’t write test case statements with the length of an essay.
- Keep it brief and to the point.
- Follow the test cases and test case statements formats stated above.
- Generally spreadsheets are used to write test cases which make them more presentable and easy to understand.
- You can use tools like “test director” when you want to automate the test cases.
- Writing clear and concise test cases forms an important part of software quality assurance.
- Also be careful that a good number of test cases cover functional testing which means that the primary focus is on how the feature works.

What are different aspects of stress testing?

Stress testing can be defined as a form of testing that is carried out to determine the stability and the stress handling capacity of a software system or module. Stress testing is all about testing the software system or application beyond the normal operational capacities. It is the testing of software system or application to its breaking or fatal point. This is done in order to observe the results.

Stress testing has a much broader meaning. What is basically understood by a stress test?
- It is referred to a test that mainly focuses upon the availability, error handling and robustness of a software system or application.
- In stress testing the software system or application is subjected heavy loads of tasks.
- It is not about considering the proper behavior under the normal operational conditions or user environment.

Typically the goal of stress testing is to test whether or not the software system or application crashes or fails in the case of catastrophic problems like unavailability of sufficient computing resources. These computational resources may include disk space or memory. It is also done to determine if the system crashes or fails under the situation of denial of service attacks and unusually high concurrency.

Stress testing, load testing, volume testing all seem like much similar kinds of testing.

A look at the following examples of stress testing will clear up the confusions regarding stress testing:


- Stress testing for web server:
A web server can be subjected to stress testing using bots, scripts and several denial of service tools to determine its performance and behavior during the peak data and tasks load.

- Stress testing can be studied in contrast with load testing.
Load testing is basically carried out to examine the entire testing environment and the huge database. It is also carried out to determine the response time of the software system or application whereas the stress testing exclusively focuses upon identifying the transactions and pushing them to a level at which a break occurs in the execution of the transaction software system.

Another point is that during the stress testing if the transactions are duly stressed, then the chance is that the database may not experience a huge data load. However if the transactions are not stressed, the data base may experience a heavy work load.

SOME IMPORTANT POINTS:
- Stress testing is another word for system stress testing.
- It can be defined as the loading of the concurrent users beyond and over the level that can be handled by the system.
- This leads to the breakage of the weakest link in the whole software system or application.
- While carrying out the stress testing the software engineers, developers or testers need to test the whole software system or application under the desired expected stress as well as under the accelerated stress.
- The goal here is to determine the working life of the software system.
- It is also aimed at determining the modes of failure for the software system or application.
- For the hardware counterpart of a complete system, the stress testing can be defined as the subjecting of the concerned hardware to the exaggerated levels of stress.
- This is basically done to determine the stability of the hardware system when used in a normal environment rather than a testing environment.
- Before modifying the CPU parameters during the processes of over clocking, over volting, under volting and under clocking, it is necessary to verify whether or not the new CPU parameters like frequency and core voltage are suitable for taking the heavy CPU loads.
- Stress testing for such parameters is usually carried out by executing a CPU intensive program for a prolonged significant period of time. It is observed if the system crashes or hangs.

What are different aspects of localization?

Localization is just the opposite of internationalization. The process of localization involves the acceptance of an internationalized software system to a particular locale or region with its specific standards and languages.

- Localization testing also forms a part of testing and typically focuses up on localization and internationalization aspects of the software products or applications.
- To localize a software system or application one needs to have the knowledge about the sets of characters which are employed in the development of today’s software product and applications.
- It also involves the basic understanding of the risks associated with the employed sets of characters.
- Localization is carried out to determine how well the build of the software product has been interpreted with a particular desired target language.
- More often and mainly localization testing helps to know that how well a particular target language has been analyzed by the build.
- For localization testing there should be a functional support within that particular locale which has already been validated because the test is founded only on the results of the globalized validation.
- The product must be globalised to a high extent and if it is not so then it will not support a given language, you will not try to give preference to that language first. But still the person has to check that the report or application which you are delivering is in a working condition or not.

Process of localizing a software product
- The process of localizing a software product or application involves the full translation of a particular application of graphical user interface and accommodate graphics for a locale.

- It also includes translation of that application program into that particular native language in the same way as the localization of business can result in a big task because the main intention for the localization of business is to implement correct business processes and practices for a locale.

- There are so many differences in how a locale conducts business. The user interface and content files are the two basic things which are mainly edited during the process of localization.

- A checklist is referred side by side during localization so as to keep a track of the process. The localization testing checklist includes the following:
1. Rules for sorting
2. Conversions in upper case
3. Conversions in lower case
4. Rules to check spelling mistakes
5. Printers
6. Operating systems
7. Size of papers
8. Text flters
9. Key boards
10. Mouse
11. Date formats
12. Hot keys
13. Available memory
14. Measurements
15. Rulers for measurement

Localization process can be initiated on a system which consists of only a few number of translators, desk top publishers or DTPs, engineers and linguists.

But the localization process is done only when certain defined conditions are there i.e., to say if there is a combination of the following aspects:

1. Independent contractors.
2. In house resources.
3. Full scope services of the localization firm.
4. Since the localization process mainly involves the translation of all the native languages in to a particular aimed string and customization of the GUI or graphical user interface, it is appropriate for the targeted market.

The software products which are offered to the international market often have to suffer a lot of domestic or in house competition which results in the blending of the localized product into a particular native language.

After the translation of the language and the updating of the graphical user interface, localization testing is needed to ensure that the software product is working well and without any problem and it also ensures that the software product is well migrated to the international market.

What is meant by analysis for web applications?

Web sites are complex and dynamic in nature. Web application analysis concentrates on three important criteria:
- information or content that is presented.
- functions that are to be performed for end user.
- behaviors of web applications.

Analysis of web applications is mainly done by web engineers, non technical content developers and stakeholders. Analysis modeling is important because it enables a web engineering team to develop a concrete model of web application requirements. It helps to define fundamental aspects of problem. There are four important aspects that analysis modeling focus:
- Content analysis identifies content classed and collaborations.
- Interaction analysis describes user interaction, navigation and system behaviors occurring as a consequence.
- Function analysis defines web application functions performed for user and sequence of processing.
- Configuration analysis identifies the operational environment in which a web application resides.

Analysis modeling should be done by web applications when the following conditions are met:
- web application is large or complex.
- number of stakeholder is large.
- number of web engineers is large.
- goals and objectives for web application will effect the business.
- success of web application will have strong affect on the success of business.

Introduction to Validation testing? What is the validation criteria?

Validation tries to uncover errors, but the focus is at the requirements level, i.e. on the things that will be immediately apparent to the end user. It begins at the end of integration testing, when all individual modules are packaged and interface errors are uncovered and corrected. In validation testing phase, testing focuses on user visible actions and output that is user recognizable. The criteria of software entering into validation phase is that it functions in a manner that is reasonably expected by the customer.

In software requirements specification, there is a section called validation test criteria. Test plan lists out the tests to be conducted and a test procedure defines test cases. These plan and procedure are designed to ensure that all the functional requirements are satisfied, behavioral characteristics are achieved, performance requirements are attained, usability is met and documentation is done.

Configuration review ensures that all elements of software configuration are properly developed, cataloged and every necessary detail is given. It is also known as audit.

Alpha testing is done at developer's site. It does not happen at usual workplace. The real users are simulated by using these techniques and carrying out tasks and operations that a typical user might perform.

Beta testing is done at end user sites. The developer is not present. It is the live application of software in an environment that is not controlled by the developer. The end user records all the problems that he faces and reports to the developer.

What is Adaptive Software Development (ASD)? What are three phases of ASD?

Adpative Software Development (ASD) is a method for the creation and development of software systems. It focuses on rapid creation and evolution of software systems. ASD is a pat of rapid application development.

Adaptive software development life cycle is mission focused, feature based, iterative, time-boxed, risk driven, and change tolerant. In adaptive software development, the developer has a basic idea in mind and they g to work. The focus is in the computer code.

In ASD, there are no pre-planned steps. The software is made very quickly. New versions can come out very quickly as the development cycle is very short. The structure of adpative software development and rapid application development are similar, difference lies in the fact that:
- adaptive software development does not allow the time when the project is finished, rapid application development does.
- adaptive software development does not have a real end point whereas rapid applicatio development allows the end of project.

Adaptive Software Development life cycle comprises of three phases:
- Speculation
- Collaboration
- Learning

In speculation, user requirements are understood and an adaptive cycle planning is conducted. It depends on bug and user reports.
Effective collaboration with customer is very important. Communication, teamwork, individual creativity are a part of effective collaboration. The individual developers combine their portions of work.
Learning cycles are based on the short iterations with design, build and testing. ASD teams can learn through focus groups, formal technical reviews and postmortems.

What are the important elements in search engine optimization Part I?

SEO web design is one of the most appropriate strategies to keep the competition.
A successful search engine optimization has few important elements includes a well targeted keyword focus, strong page element optimization and good quality content.

Keywords are most important element for search engines. These keywords are what search strings are matched against.The most crucial step is to find the correct keyword that can be used to optimize.

- Choosing the right keyword to optimize. It is best to focus on less competitive and highly specific keywords. The keyword should have the property of describing what is the purpose of your website. Also, check whether these keywords are relevant to your website or not.

- The website should be rich in keywords and have good keyword density. It is a measure to judge how relevant is the page.Keeping 5 to 10 keywords is termed as OK keyword density. Keyword stuffing should not be practiced.

- Quality of keywords and their position on the seb page is also very important. Keywords that appear in the heading, title are more effective than the keywords that are placed at the bottom.

- A balance has to be there between url keywords and site usability.
- The contents of page title tag are displayed during search so this is the special place where keywords can be given.

- From an SEO point of view, it is good to have as many headings with good keywords in it. The headings should not be very long as readability becomes difficult.

Explain Black box and White box testing? What are their advantages and disadvantages?

For complete testing of a software product both black and white box testing are necessary.

Black-box testing
This testing looks at the available inputs for an application and the expected outputs that should result from each input. It does not have any relation with the inner workings of the application, the process undertaken or any other internal aspect of the application. Search engine is a very good example of a black box system. We enter the text that we want to search, by pressing “search” we get the results. Here we are not aware of the actual process that has been implemented to get the results. We simply provide the input and get the results.

White-box testing
This testing looks into the complex inner working of the application; it tests the processes undertaken and other internal aspects of the application. While black box testing is mainly concerned with the inputs and outputs of the application, white box testing help us to see beyond i.e. inside the application. White-box testing requires a degree of sophistication which is not the case with the black-box testing, as the tester is required to interact with the objects that are used to develop an application rather than having easy access to the user interface. In-circuit testing is a good example of a white-box system testing where the tester is looking at the interconnections between different components of the application and verifying the proper functioning of each internal connection. We can also consider the example of an auto-mechanic who takes care of the inner workings of a vehicle to ensure that all the components are working correctly to ensure the proper functioning of the vehicle.

The basic difference between black-box and white-box testing is the areas of focus which they choose. We can simply say that black-box testing is focused on results. Where if an action is performed and the desired result is obtained then the process that has actually been used is irrelevant. White-box testing, on the other hand focuses on the internal working of an application and it is considered to be complete only when all the components are tested for proper functioning.

Advantages of Black-box testing
- Since tester does not have to focus on the inner working of an application, creating test cases is easier.
- Test case development is faster as tester need not to spend time on identifying the inner processes; his only focus is on the various paths that a user may take through GUI.
- It is simple to use as it focuses only on valid and invalid inputs and ensures that correct outputs are obtained.

Drawbacks of Black-box testing
Constantly changing GUI makes script maintenance difficult as the input may also be changing. Interacting with GUI may result in making the test script fragile and it may not properly execute consistently.

Advantages of White-box testing
- Since the focus is on the inner working the tester can identify objects pro grammatically. This can be useful when the GUI is frequently changing.
- It can improve stability and re usability of test cases provided the object of an application remains the same.
- By testing each path completely it is possible for a tester to achieve thoroughness.

Drawbacks of White-box testing
Developing test cases for white-box testing involves high degree of complexity therefore it requires highly skilled people to develop the test cases. Although to a great extent fragility is overcome in white-box testing BUT change in the objects name may lead to breaking of the test script.

The System Engineering Hierarchy - System Modeling

Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy.
System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

System modeling is an important element of system engineering process. System engineering model accomplishes the following:
- define processes.
- represent behavior of the process.
- define both exogenous and endogenous input to model.
- represent all linkages.

Some restraining factors that are considered to construct a system model are:
- Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications that enable the model to be created in a timely manner.
- Limitations that help to bound the system.
- Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences that indicate the preferred architecture for all data, functions , and technology.
The resultant system model may call for a completely automated or semi automated or a non automated solution.

Flow Oriented Modeling - Creating a Data Flow Model

Flow models focus on the flow of data objects as they are transformed by processing functions. Derived from structured analysis,flow models use the data flow diagram, a modeling notation that depicts how input is transformed into output as data objects move through the system. Each software function that transforms data is described by a process specification or narrative. In addition to data flow, this modeling element also depicts control flow.

Data flow oriented modeling is the most widely used analysis notation. Flow oriented modeling focuses on structured analysis and design, follows a top to down methodology and uses a graphical technique depicting information flows and the transformations that are applied as data moves from input to output.

The modeling tools that are used to build a data flow oriented model include context diagrams, data flow diagrams, entity relationship diagram, control flow diagram, state transition diagram, data dictionary, process specification and control specification.

Steps to create a data flow model
- Diagram 0: develop a context diagram.
- Decompose the Process into high level processes.
- In parallel to this, develop data flow diagrams, entity relationship diagrams and state transition diagrams.
- Define data stores which includes normalization.
- Develop data dictionary.
- Finalize data flow diagrams, entity relationship diagram and state transition diagrams.
- Develop process specifications which includes PDL, decision tables or trees.
- Perform transformational analysis which includes developing structure charts.
Information flow continuity must be maintained as each data flow diagram level is refined. This means that input and output at one level must be the same as input and output at a refined level.

User Interface Testing - The Golden Rules

User interface design creates an effective communication medium between a human and a computer. User interface is designed by a software engineer. Interface design focuses on three areas:
- design of interfaces between software components.
- design of interfaces between software and other non-human producers and consumers of information.
- design of interface between a human and computer.

Rules Forming the Basis For A Set of User Interface Design Principles

Place the User in Control: Some design principles that allow the user to maintain control are:
- Define the current state of the interface in a way that does not force a user in to unnecessary or undesired actions.
- Flexible interaction should be provided because different users have different interaction preferences.
- It allows the user interaction to be interruptible and un-doable.
- The user should not be aware of the technical internals like operating system, file management functions etc. The user interface should move the user into virtual world of the application.
- It is good to design a macro mechanism that enables an user to customize the interface to facilitate interaction.
- The interface should be designed in a manner in which user will have direct interaction with objects that appear on screen.

Reduce the User's Memory Load
Some design principles enabling an interface to reduce user's memory load:
- Interface should be designed to reduce the requirement to remember past actions and results. This can be done by providing visual cues that enables a user to recognize past actions rather than to recall them.
- Establish meaningful defaults.
- Shortcuts should be defined that are intuitive in nature.
- The visual layout of the interface should be based on real world metaphor.
- Interface should be organized in a hierarchical manner. The information should be disclosed in a progressive fashion.

Make the Interface Consistent
Consistency means that all visual information is organized according to a design standard, input mechanisms are constrained to limited set used consistently throughout the application and mechanisms for navigating from task to task.Some design principles that helps in making interface consistent are:
- Allow the user to put the current task into meaningful context.
- Consistency should be maintained across a family of applications.
- Do not make changes in past interactive models that have created user expectations unless there is some solid reason to change.

The Risk Mitigation, Monitoring and Management (RMMM) Plan

The Risk Mitigation, Monitoring and Management, RMMM, plan documents all work performed as part of risk analysis and is used by the project manager as part of overall project plan.
The goal of the risk mitigation, monitoring and management plan is to identify as
many potential risks as possible.It is the organization’s responsibility to perform risk mitigation, monitoring, and management in order to produce a quality product.
Every phase of this plan is of equal importance. More focus is maintained in the initial phases i.e. the identification and assessment of possible risks.
Once RMMM has been documented and project has begun, risk mitigation and monitoring steps commence.
Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.
The measurement of effectiveness of these mitigation / contingency plans should be well carried. It must ensure that after the execution of such plans the risk exposure is reduced or preferably eliminated.

- Risk Mitigation covers efforts taken to reduce either the probability or consequences of a threat.
- Risk monitoring and control is the process of identifying, analyzing, and planning for newly discovered risks and managing identified risks.
- Risk management is the identification, assessment, and prioritization of risks.

Model Driven Architecture (MDA) - Advantages and MDA Process

The MDA is a new way of writing specifications, based on a platform-independent
model.

Why should we use Model Driven Architecture

- Portability
- Interoperability
- Domain facilities provide much wider interoperability.
- MDA allows to model the functionality and behavior only once, therefore saves a lot of time.
- Requirements are always changing.
- New technology is arising.
- Require to integrate old system with new system, and any other system in future.
- MDA makes it easier to integrate applications and facilities across middle-ware boundaries.

Model Driven Architecture Process

THE BASIC PROCESS
- To construct a MDA application, the first step is to create a computation independent model(CIM) by a business analyst.
- The CIM is transformed into platform independent model(PIM) by enterprise architect.
- The resulting PIM has to be targeted to a platform to complete the build process.
- The transformation of a PIM to a PSM will be done by a platform specialist.

THE COMPLEX PROCESS
The process from computation independent model to platform specific model can be a bit more complex.
- Between the models, there can be some gaps present which makes transformation difficult.
- As a result, you can have interrelated models having different layers of abstraction.
- One consequence is that a single layer of abstraction can have horizontal transformations. Consider the example where a PIM is converted multiple times into more detailed PIMs. And there are vertical transformations in addition to vertical transformation of models.

Model Driven Architecture (MDA) - Characteristics and Viewpoints

OMG was formed as a standards organization to help reduce complexity, lower costs, and hasten the introduction of new software applications.
- The Object Management Group (OMG) adopted the Model Driven Architecture as an approach for using models in software development.
- Its three primary goals are portability, interoperability and reusability through architectural separation of concerns.

Characteristics of Model Driven Architecture(MDA)

- MDA enables development of new specifications.
- MDA provides a comprehensive, structured solution for application interoperability and portability into the future.
- MDA consists of services specified by OMG. It also includes directory services, event handling, persistence, transactions, and security.
- MDA enables the creation of standardized domain models for some vertical industries.
- MDA separates the operation of the system from the way it uses its capabilities of its platform.
- MDA enables converting platform-independent models to produce platform-specific models using mappings.

What are different viewpoints of Model Driven Architecture

- The first viewpoint is called Computation Independent Viewpoint which focuses on environment and requirements of the system rather than the details of system's structure and processing.
- The second viewpoint is called Platform Independent Viewpoint which focuses on how the system operates. It hides the details necessary for a particular platform. The part of complete specification does not change when the platform changes.
- The third viewpoint is called Platform Specific Viewpoint which focus on the detail of the use of a specific platform in addition to platform independent viewpoint.

Rapid Application Development (RAD) - Advantages and Disadvantages

The main objective of Rapid Application Development is to avoid extensive pre-planning, generally allowing software to be written much faster and making it easier to change requirements.
Rapid Application Development Model (RAD Model) is a linear sequence of the software development process model where we focus a very short development cycle by using a component based construction approach.

When organizations adopt rapid development methodologies, care must be taken to avoid role and responsibility confusion and communication breakdown within the development team, and between the team and the client.

To facilitate rapid development, strong emphasis was placed on the idea of software re-use. The notion of software components began to be nurtured.

ADVANTAGES OF RAPID APPLICATION DEVELOPMENT(RAD)

- It increases speed of developing software. It can be achieved using methods like rapid prototyping, virtualization of system related routines, the use of CASE tools and other techniques.
- Re-usability of components help to speed up development.
- It increases the quality.
- Some systems also deliver advantages of interoperability, extensibility, and portability.
- It incorporates short development cycles.
- Promotes strong collaborative atmosphere and dynamic gathering of requirements.

DISADVANTAGES OF RAPID APPLICATION DEVELOPMENT(RAD)

- Unknown cost of product.
- Difficult to commit the time required for success of the RAD process.
- Short iteration may not add enough functionality, leading to significant delays in final iterations.
- Early RAD systems faces reduced scalability occurs because a RAD developed application starts as a prototype and evolves into a finished application.
- Early RAD systems have reduced features that occur due to time boxing, where features are pushed to later versions in order to finish a release in a short amount of time.
- Dependency on strong cohesive teams and individual commitment to the project.

Rapid Application Development (RAD) - Characteristics and Phases

Rapid Application Development is a software development methodology that focuses to decrease the time that is needed to design the software through gathering requirements using workshops or focus groups, prototyping and early, reiterative user testing of designs, the re-use of software components, a rigidly paced schedule that defers design improvements to the next product version, less formality in reviews and other team communication.

Characteristics of Rapid Application Development(RAD)

- It involves techniques like iterative development and software prototyping.
- Focused scope where the business objectives are well defined and narrow is well suited for RAD.
- Project data suitable for RAD is the data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
- Decisions can be made by a small number of people who are available and preferably co-located are suitable for RAD.
- A small project team (preferably six people or less) is suitable for RAD.
- In RAD, the technical architecture is defined and clear and the key technology components are in place and tested.

Phases of Rapid Application Development

RAD has a step by step process.
- Planning of Requirements: Developers meet with the project coordinator or manager to create specific objectives from the desired program. Strategies for development and tools for development are also laid out in a specific project.
- RAD Design Workshop: Using the agreed tools and interfaces, developers will start to create different programs based on the business need.
- Implementation Phase: Even though it has gone through hundreds or even thousands of testing and critique, the stage wherein the software is implemented in a larger scale is different hence new suggestions and bugs should be expected from different users.

How does stress test execute?

A stress test starts with a load test, and then additional activity is gradually increased until something breaks. An alternative type of stress test is a load test with sudden bursts of additional activity. The sudden bursts of activity generate substantial activity as sessions and connections are established, where as a gradual ramp-up in activity pushes various values past fixed system limitations.
Ideally, stress tests should incorporate two runs, one with burst type activity and the other with gradual ramp-up to ensure that the system under test will not fail catastrophically under excessive load. System reliability under severe load should not be negotiable and stress testing will identify reliability issues that arise under severe levels of load.
An alternative, or supplemental stress test is commonly referred to as a spike test, where a single short burst of concurrent activity is applied to a system. Such tests are typical of simulating extreme activity where a count down situation exists. For example, a system that will not take orders for a new product until a particular date and time. If demand is very strong, then many users will be poised to use the system the moment the count down ends, creating a spike of concurrent requests and load.