What are Six Best Practices in Rational Unified Process?

The IBM Rational Unified Process is a means of commercial deployment of the approaches and practices which have been proven for the development of the software systems and applications. It is based up on the following six best practices:

1. Iterative development of the software systems and applications
2. Management of the requirements
3. Use of architecture based up on the components.
4. Visual modeling of the software system
5. Verification of the software system.
6. Controlling the changes to the software system or application.

The above mentioned practices are called the best practices not because their value can be precisely quantified but because they are quite common in the software industry by most of the organizations which are successful and reputable.

In the rational unified process each and every member of the team gets templates, guidelines as well as the tools which are found necessary for the whole of the team in order to reap the full advantage.

Basic Practices In Rational Unified Process in Detail

Iterative development of the software systems or applications:  

- Software systems and applications are quite sophisticated and therefore they make it impossible to define the problem first in sequence.

- By sequence we mean, first defining the whole problem, designing a solution of the problem, building the software system or application and then finally testing the software system. 

- In order to deal with such software systems and applications there is a requirement of an iterative approach so that an increase in the understanding of the problem can be made in a series of successive refinements. 

- This also helps in developing an effective solution in increments done over multiple iterations.

Management of the Requirements: 

The rational unified process gives a description:

- On how the elicitation, organization and documentation of the constraints as well as the functionality is to be done, 

- how the trade-offs and decisions have to be tracked and documented and 

- how the business requirements are to be captured and communicated.

Use of architecture based up on the components: 

- The focus of the development process is on the base-lining and early development of an architecture that is robust and executable as well. 

- It gives a description of how a resilient architecture can be built with more flexibility that can accommodate the changes easily, can be easily understood and effectively promotes the reuse of the existing software artifacts. 

- The rational unified process provides a great support to the component based development. 

- By components we mean, the sub systems and non – trivial elements for a clear function.

Visual modeling of the software system: 

- The rational unified shows you exactly how a software system or application can be visually modeled and can be used for capturing the behavior and structure of its architectural components. 

- This further enables you to hide the details and develop the code with the help of the graphical building blocks. 

- With such visual abstractions, communication can be established between the different aspects of the software system or application.

Verification of the software system: 

- Poor reliability dramatically cuts down the chances of a software system or application from being accepted.

- Therefore it is important to review the quality concerning the factors namely functionality, reliability, system performance and application performance etc.

Controlling the changes to the software system or application: 

- The management and ability to track the changes are critical to the success of any software system or application. 

- However, the rational unified process helps you to cope with these issues also.

What are the characteristics of the unified process?

- Unified process is one of the most popular software development frame works based on the iterative and incremental approach.

- Unified process is a frame work that is extensible according to the needs of the software development project or according to the needs of the specific organizations. 

- The unified process signifies the generic processes that include elements that have been declared common for most of the refinements. 

- The unified process was first discussed in detail in a book called “the unified software development process” in the year of 1999. 

- Every process has got some characteristics and so does the unified process.

Characteristics of Unified Process

1. Iterative and Incremental Process: 

- There is no doubt believing that the unified process is an iterative and incremental one. 

- This is evident from the fact that the all the below mentioned 4 phases of the whole process are divided in to a set of time boxed iterations:

(a)  Inception

(b)  Elaboration

(c)  Construction and

(d)  Transition

- Depending up on the complexity and the size of the project, the inception phase may also be further divided in to a large number of small iterations to keep the over all development process as simple as possible. 

- The increments are the result of the individual iterations that are performed during the whole development process.

- These increments can be defined as a system containing improved and added functionalities that extend over those that were present in the previous version of the same software system or application.

- Mostly the iterations take care of the following aspects of the software:

       (a)  Requirements

       (b)  Testing

       (c)  Design implementation and so on.

2. Use case driven: 

- The unified process is rightly called the use case driven software development methodology since it is driven by the use cases that are quite effective in capturing the contents of the iterations and the functional requirements.

- Each iteration involves a number of use cases as well as scenarios for the proper identification of the requirements, their implementation, testing and deployment.

3. Risk Focused: 

- The unified process requires that the most critical risks in the whole development cycle are focused up on in the early stages of the life cycle of the process. 

- For addressing the factors with the highest risk rating, the deliverable of all the iterations especially in the second phase of the life cycle i.e., the elaboration phase are selected in a pre-defined order.

4. Architecture Centric: 

- It is obvious that the success of any software development process is greatly dependent on what kind of architecture is being used in it. 

- Architecture seems to work the very best at the heart of any software development process. - With the right architecture in the process, the efforts of the teams can shape the software system or application the way they want. 

- One problem is encountered here which is that only one model never suffices in providing coverage in a unified process, several models have to be conjoined and used. 

- It is one of the attractive features of the unified process that it supports multiple architectural views and models. 

- The elaboration phase witnesses the creation of an executable architecture baseline which can be called as an important deliverable. 

What is a Unified Process? What are key practices and guidelines for unified process?

What is Unified Process?
- Unified process is actually the short name for the USDP or the unified software development process.
- This software development process has recently emerged as a very popular incremental and iterative software development process frame work. 
- There are some methodologies defined under the category of the unified process and the one that is most commonly implemented and extensively documented in the rational unified process known as RUP in the abbreviated form. 
- The concept of the unified process is very vast and it cannot be merely called as only a process! Rather it can be thought of as an extensible frame work which is customizable according to the needs of the software project or the specific organizations. 
- Concluding from this, the rational unified process can also be called a customizable frame work. 


However the name “unified process” in quite opposing to the rational unified process generally marks the generic processes that include the elements that hold common for most of the refinements. 
In addition to this this name also avoids the potential issues of the trade mark infringement that arise since the RUP and the rational unified process are the trademarks of the IBM. 
The unified process was first mentioned and described in detail in a book by Ivar Jacobson, James Rumbaugh and Grady Booch called “the unified software development process” in the year of 1999.

Six Practices of Unified Process

The unified process deploys the following 6 key practices of software development:

1. Development of the software in iterations: Increases understanding of the problem through successive refinements. An effective solution is achieved over several increments.
2. Management of requirements: Involves elicitation, organization and documentation of the required constraints and functionalities, trade offs and so on.
3. Implementation of component based architectures: A robust executable architecture is subjected to baselining first and then resources are deployed for full scale development. Promotes resiliency of the architecture.
4. Visual modelling of the software: This practice helps capture the behaviour of the architectural components of the software system.
5. Verification of the software quality: Poor reliability and poor performance are the factors that weigh down the quality of the software system or application. This practice reviews the software quality.  
6. Controlling changes that are to be made in the software: This practice ensures that the changes to be incorporated are acceptable and won’t hamper the performance. 

Developers often want the answer for the question, "how do I know if I’m implementing the unified process properly?" There is no certain answer for this question but there are certain guidelines which if followed properly can keep the process on track:

1. Figure out the major risks early and regularly or they will hamper the performance of your software system.
2. Ensure the value that you are going to deliver to your customer.

What is a Unified Process? What are key characteristics and guidelines for unified process?

If you might have heard even a little about the unified process, you must be having a clue that it has something to do with the development of software system or methodologies. Yes! Certainly it has to do not a little but all with the software development, after all it is one of the most sought after software development frame work.

Well! This article is all about the unified process. Unified process is actually the short name for the USDP or the unified software development process.

What is a Unified Process?

- This software development process has recently emerged as a very popular incremental and iterative software development process frame work. 

- There are some methodologies defined under the category of the unified process and the one that is most commonly implemented and extensively documented is the rational unified process known as RUP in the abbreviated form.

- The concept of the unified process is so very vast that it cannot be merely called as only a process! Rather it can be thought of as an extensible frame work which is customizable according to the needs of the software project or the specific organizations. 

- Concluding from this, the rational unified process can also be called a customizable frame work.  

- However, the name “unified process” is quite opposing to the rational unified process which generally marks the generic processes that include the elements that hold common for most of the refinements. 

- In addition, this name also avoids the potential issues of the trade mark infringement that arise since the unified process and the rational unified process are the trademarks of the IBM. 

- The unified process was first mentioned and described in detail in a book by Ivar Jacobson, James Rumbaugh and Grady Booch called “the unified software development process” in the year of 1999. 

Characteristics of Unified Process

This process is marked by some special characteristics that we have discussed below:

1. Iterative and incremental process: All the 4 phases of the unified process namely:

(a)    Inception

(b)   Elaboration

(c)   Construction and

(d)   Transition have been divided in to a frames or sets of time boxed iterations.

The inception phase is quite large and may be further divided into small iterations for large projects. Increments are the results of the iterations which in turn are responsible for improving the functionality of the software system or application as compared to what it had in the previous release. The emphasis and the effort of the iterations changes in due course during the development process though most of the process disciplines are focused like those mentioned below are focused on requirements, design, implementation and testing.

   2. Use case driven: The whole process is driven by the use cases whose work is to capture functional requirements and the definitions of the content of all the iterations.

    3. Architecture Centric: Architecture lies at the heart of the whole unified process and shapes the development of the whole system. Till now no such model has been developed that will cover all the aspects of the system and so multiple architectural models are implemented.

    4. Risk Focused: The unified process does not leave out any critical risks and they are discovered early in the development cycle. 

How is test driven development and documentation linked?

As we all know that the test driven development or TDD is another process in the list of the most of the popular software development processes. The topic of the test driven development is in the league of this article. 

About Test Driven Development

- The test driven development took its root from the idea of the repetition of a very short development cycles. 

- The first of all a failing automated test case is written or created by the software developer or tester which is meant to serve the purpose of defining a new function or a desired improvement. 

- Secondly a code to pass the above created test is also written by the developer. 

- This newly written code is then subjected to refactoring in order to make it meet the acceptable standards. 

- The test driven development has always been looked up as an encouragement for the simple designs and also as an inspiration for boosting up the confidence levels.

- The test driven development has always been known to be related to the concepts of the extreme programming or XP. 

- But, eventually it came to be known as a standalone process having its own ways and rights.

- The concepts of the test driven development are used by the programmers and developers as a measure for debugging the legacy code and improving it further. 

- The test driven development is usually driven by a series of automated unit tests that are written by the developer to provide definition for the requirements of the code and then the code is automatically produced. 

- These tests are constituted of the assertions of their own.

- If a test is successfully passed, the developer is confirmed of the correctness of the code and that it can be further evolved and refactored. 

The documentation forms a very important part of any development or testing and so does of the test driven development. This article has taken up the question: “how is test driven development and documentation linked?”. 

About Importance of Documentation In TDD

Now coming to the importance of documentation in the test driven development, it includes the following documents:

1. Feasibility report
2. Technical documentation
3. Operational documentation
4. Log book and so on.

- The documentation in test driven development is another source of support to the developers as well as the users.

- It provides all the crucial information required to set up a uniform environment in which the software system or application is to be operated. 

- In case of a break down when the person in charge is not available, the users experience down time and most of their resources are wasted. In such situations, there is only one thing that can save one’s precious time and efforts and that thing is nothing but the documentation. 

- It provides all the information and guidelines that are required to fix an issue. 

- The format of the documentation does not matter much as much as it content matters.

- Documentation is vital to any software development process and not particularly to the test driven development.

- Documentation is an effective mean for streamlining the test driven development process. 

- Apart from all this, documentation has got an important role to play in the business.

- Document is needed in the test driven development since it helps in codifying the procedure for the development of the software system or application. 

- The documentation provides effective protection during the audits to the test driven development.

- It is important that the documentation is developed alongside the development of software system or application. 

- Documentation will be effective if it is considered to be a part of the work and not a hindrance to it. 

What are different design specifications while drawing a test plan?

When a development team is working on a project, how do they ensure that the functionality is being coded correctly? Design specification documentation serves this purpose.

What are Design Specifications?

- A design specification document must be free of any ambiguities and should be complete, since an incomplete design specification document full of ambiguities can have you reaching for the costly rewrites.

- A good design specification follows a pyramidal approach i.e., from the top it provides a complete and broad overview of the software system or application and its components and at the lower levels it provides a detailed overview of the primary components of the application.

- The details should be as much required by the development team.

- Most of the software developers tend to work with design specifications documents which include detailed description of every function, sample screen shots, layouts of the data base as well as reports.

- Many a times it happens so that the client does not provides sufficient detail; in such a case the developer responds in writing asking as many questions required getting a detailed overview of the project.

- These questions are supposed to enquire in depth regarding the design specifications of the application under development.

- Writing an effective and a self sufficient design specification document is an art in itself.

- If you find it difficult to write a design specification document, you can first write a basic outline and then fill it up based up on the needs of the client as well as the skills of the developers.

- Coming up with a document that fits the requirements and needs of both the client and the developer is quite a difficult and requires a lot of struggle.

- There is no need to show the entire specification document to the client or the customer since they won’t understand it.

- Some organizations even take up the extraneous effort for creating two design specifications documents.

- One contains only a broad overview of the application for the customers and clients while the other one consists of detailed description of the application and its primary components meant for the developers.

- There are some artistic developers who themselves like to fill up the details for the design specifications after knowing what functions are to be performed by the application.

- To make it easier, you can start off with a high level description of the design specifications followed by signing off by the client.

- Then you can go for writing second file with more detailed descriptions.

- Keep the design specification document updated as regularly as possible.

- IEEE has come forward to help in this regard and it has laid down “IEEE 1016- 1998 standard” for specifying a structure for the SDD or software design description.

What should a design specification include?

According to IEEE standard, the design specifications must include at least the following:

1. Introduction: It includes
(a) overview of the design and
(b) Requirements traceability matrix

2. System architectural design: It includes (a) discussion regarding the alternative designs
(b) Chosen system architecture
(c) System interface description

3. Detailed description of the application components

4. User interface design: It includes
(a) description of the interface
(b) Objects and events (actions)
(c) Screen image

5. Additional information

After completing writing down the design specifications, you should compulsorily have it signed off by the client or the customer so as to have a proof that they abide by everything that is there in the specifications document.

This also provides coverage to your bases and enforces that the customer reads the whole specifications document. The design specifications should also be reviewed by the quality assurance people since a good design specification helps in creating better test cases.

What are different functional specifications while drawing a test plan?

The successful completion of the software testing cycle depends entirely up on the quality of its test plan. Any test plan is composed of certain specifications which are not to be missed if you want your plan to be effective. Specifications are of two types namely:

1. Functional specifications and
2. Design specifications.

What are functional specifications?

- Functional specifications which are nothing but a formal document that is created for the purpose of describing a detailed overview of the software system’s or application’s intended functions and capabilities.

- It describes in detail the appearance of the software application as well as how it is to interact with the users.

- The functional specifications can be thought of as guidelines or references by the program developers and programmers while the development of the software is in progress.

- The functional specifications for the software system or application that are equipped with some windows and dialogs are aimed at showing the visual appearance of its user interface and also to give a detailed description of all the possible inputs from the users and the reactions of the application to them.

- A functional specification may or may not include a formal description of the dependency of the application on other programs or applications, usability criteria and user tasks.

- To define a functional specification formally we can say that it is to describe the solution technically and is also used as a representation of the contract between a client and project development team.

- It forms the basis for building any application.

What are different functional specifications while drawing a test plan?

- While drawing the test plan, the program manager baselines the functional specifications which are placed under the change control since it sustains all the information that is needed to design the solution.

- Functional specifications seek to incorporate logical, physical and conceptual designs in to the solution for making it more efficient.

- All the high level design decisions regarding the network configurations and server management should also be included under the functional specifications.

What aspects should a functional specification include?

A typical functional specification describes the following aspects:

1. Summary of the project scope (as agreed up on the by both parties in a business context).

2. Any additional requirements

3. The design of the solution

4. Specifications of the components that form a part of the solution

5. Features:
Documentation of all the planned features along with their quantitative specifications such as performance metrics, concurrent user capacity, and data base capacity and so on.

6. Security requirements:
Specifications regarding the strength of security concerning the functions that involve working with sensitive data like transactions. The encryption standards that have been implemented in the security mechanism should also be mentioned along with the location and type of the security mechanisms.

7. Legal requirements:
These must be clearly stated along with the custom codes to me business policy, custom user scenario or a governmental requirement etc.

8. Risk assessment:
This documentation must include the descriptive details about:
- potential vulnerabilities,
- mitigation strategies and
- the impact of the above strategies and vulnerabilities on the application.

There should be no ambiguity in the description of the above stated aspects and the quantitative measurements should be used wherever possible.

What aspects should a functional specification should not include?

Now we list the aspects that should not be included in the functional specifications:
1. Detailed data base schema
2. Details of the software architecture
3. Details about the programming language

Data base details suffice the purpose of the functional specifications and save the development team from extraneous efforts.
The functional specifications are changed only with the due permission of the client. Functional specifications are the living documents i.e., they are continuously updated throughout the development cycle and show how a solution can be deployed in a timely and cost effective manner.

What is the difference between conventional and unconventional testing?

Conventional testing and unconventional testing are a less heard testing methodology. Before we discuss about these two methods, let's discuss about the “quality management system” or QMS as it is called in its short form.

QUALITY MANAGEMENT SYSTEM
- Quality management system can be thought of as an organizational structure which states and manages the processes, procedures and resources to be implemented for better quality management.
- Earlier random sampling and simple statistics were used for predicting the output of a test in production line.
- But eventually by the end of the 19th century the entering the data manually for these test cases was considered to be a costly method.
- Later in the 21st century the quality management system succeeded in overcoming this problem.
- It came with a new transparent and sustainable technology which gradually achieved a wide customer satisfaction.

CONVENTIONAL AND UNCONVENTIONAL TESTING
- Conventional testing is nothing but a similar initiative of quality management system.
- Conventional testing is entirely based up on the standards and conventions of the testing as defined by the quality management system.
- It is a way of maintaining the testing standards.
- Since the conventional testing is guided by some conventions, hence it was named so.
- Unconventional testing, we can say just by looking at the name that it doesn’t follow any conventions.

DIFFERENCES BETWEEN CONVENTIONAL & UNCONVENTIONAL TESTING

DIFFERENCE #1:
- In conventional testing, only features and functionality of a software system or application are tested by the engineer in charge of the testing cycle.
- In unconventional testing, only the documentation is verified on the basis of the quality assurance principles.

DIFFERENCE #2:
- In unconventional testing, the documentation is tested from the starting phase of SDLC (systems development life cycle) by the testers of quality assurance.
- Conventional testing comes into play only during the testing phase of the systems development life cycle.

DIFFERENCE #3:
- In conventional testing, the developed components of the application are checked by the tester for whether they are working according to the expectations of the consumers or not.
- A typical unconventional testing starts from the coding phase of the systems development life cycle.

DIFFERENCE #4:
- Unconventional testing keeps a track of the whole software development process on the basis of the quality assurance principles i.e. whether or not the software has been developed according to the guidelines and specifications provided by the client company.
- The conventional testing is focused more up on the functionality of the software system or application.

USES & LIMITATIONS OF CONVENTIONAL TESTING
- Conventional testing is being used in migration projects these days.
- It sometimes happens that the testers performing the conventional testing have a very little knowledge about that particular application software which they are testing. In that the comparison testing is employed.
- This is preferred because here it is not required that the tester should know what will be the outcome.
- This problem can be solved also if the development team has already prepared the test scripts for the tester.
- Conventional testing is a bit expensive as it requires a lot of time to test, verify and validate each and every test script.
- There will be a certain number of errors in a program that is of course obvious and depends up on the degree of complexity of the program
- Errors also depend on the kind of migration process being followed in the project.
- The aspects of the software system or application failing these tests have to be corrected and retested accordingly.

What are different concepts of Certified Software Quality Analyst (CSQA)?

Certified software quality analyst or CSQA as it is known in short form, is the certification that checks the software quality analysing capabilities and skills of an individual who applies for it.

Certified software quality analyst certification is gaining fast popularity in the field of software testing these days. Number of CSQA aspirants is growing day by day. More and more skilled individuals are now seeking to get this certification.

The certified software quality analysts use the principles of quality analysing in assessing the quality of the software. CSQA plays a great role in building up the reputation of an organization since it helps in improving the quality of the software products that it manufactures.

CSQA certification provides three main benefits.They have been mentioned below:

- It gives an acknowledgement about the skills and competency of the certified individual or professional.
- It proves to be a great factor in helping the deserving individual in getting job, promotion and good hike in salary.
- He/ she can continue his/ her education after fulfilling the re-certification requirements.

The duration of exam is 4 hours but it if you get qualified you will have great benefits. There are certain things that you need to fulfil before appearing for the examination.

These include:

- The candidate needs to fulfil all the prerequisites as laid down by the CSQA certification norms.
- The applicant needs to abide by the guidelines stated by the code of ethics and stick to them while discharging their duties.
- The applicant needs to submit a document for character reference along with the exam form.

An individual or professional can hold CSQA certification only for 3 years at a time and after that he/ she need to get re-certification for the same. This can be done by the following procedure:

- The applicant needs to submit a recertification journal which gives an account on the qualified educational activities by the professionals.
- The applicant may appear for a recertification exam.

What does this certification do?
- This certification tests the principles and practices that an individual or a professional follows regarding the management of good quality.

- CBOK only helps with understanding of concepts but does not provide any practical knowledge and experience.

- CSQA aims to test the ability of an individual to face the real world challenges.

- Most of the aspirants don’t know how to approach CSQA exam. It is just like a regular exam but with a more need of practical knowledge and awareness.

Try to understand the concepts listed in CBOK properly. You can also prepare questions for testing your preparation. While studying a concept, you need to relate those concepts to the real world challenge as to how you will use them in solving real world problems.

The candidate needs to meet any one of the following condition:

- A bachelor’s degree from a reputed and accredited institution along with an experience of 2 years.
- An associate degree along an experience of 4 years.
- If the applicant is not having any degree, he/ she must have an experience of 6 years minimum.

The aspirants must learn to adhere to the code of ethics. It is very important not abide by the code of ethics as it defines the behaviour that is expected from a professional. Depending up on your compliance, you may require submitting your education and employment documents. If you fail to submit, then you may be disqualified. To abide by the code of ethics is extremely important as one can even be subjected to decertification if his/her conduct is not good.

What are different guidelines for smoke test?

In the field of software testing, smoke testing is defined as a preliminary test for the further testing of the software program or the application.

- The smoke is basically intended to reveal the simple failures but big enough to get prospective and deserving software rejected for release.

- The “smoke” in the term smoke testing is taken to be metaphorical.

- Typically in a smoke testing, a sub set of the test cases (includes all the test cases that have been selected to be performed on the software system or application) are selected and run on the software system or application.

- All the selected test cases cover all the most important functionalities of the components of the software system or application.

- This is done in order to ascertain that whether the most crucial functions of a software system or application are working properly or not?

To make it easy to understand let’s say that the smoke testing involves enquiring about the following questions:

- Whether the program runs or not?
- Whether it opens a window or not?
- Whether clicking on the main button triggers any action or not?

And so on!

- The main aim is to determine the status of the software system or application i.e., whether or not the software system or application is in such a bad or broken state that it requires further testing.

According to the book “lessons learned in software testing” the " smoke testing covers all the features of the software product in a broad manner and also in limited time".

- It also states that if the key features of the software system or application are not working or if the major bugs have not been fixed, then the software developers and testers won’t have to waste their time further by installing the application or testing it.

- A smoke test that is being performed on a particular build is commonly known as a build verification test.

- Performing a daily smoke and build test is now being considered as one of the best practices in the industry of software testing.

- These days the testers now prefer to perform smoke testing before accepting a build for further testing of the software system or application.

- The software giant Microsoft once claimed after the code reviews that the smoke testing can be effectively stated as the most cost effective method for identifying the major bugs and fixing them in software program.

- In the case of Microsoft, a smoke test is usually seen as a process of validating the changes made to the code before they are set in to the source control.

- Smoke testing can be performed either manually or it can be made automated by using an automated tool.

- When an automated tool is used the initiation of the test cases takes place automatically by the same process that is responsible for generation of the build itself.

Smoke tests are categorized in to two major categories namely:
- Functional tests
- Unit tests

The functional tests are responsible for exercising the complete software system or application with various forms of inputs whereas the unit tests are responsible for exercising the individual functions, object methods and sub routines.

The functional tests as well as unit tests behave as a third party products that do not form a part of the whole compiler suite.

Functional tests are usually a scripted series of program inputs whereas unit tests are separate functions embedded within the code or the driver layer itself that links to the source code without making an alteration to the code that is under test.

What are different characteristics of Compliance testing?

Compliance testing perhaps sounds a very rare kind of testing, less often heard about. It can be defined as the audit of a software system or application which is carried out against well known criteria.

There are many kinds of compliance testing and some are even developed as per the requests of the customers or the clients. Basically the compliance tests are of the following types:

Systems in Development
It refers to the compliance testing in which the verification of the fact that the intended software system or application under development meets the lock down standards, configurations and specifications as requested by the client or the customer is done.

Operating systems and applications
- It refers to the compliance testing in which the verification of the fact that an operating system and software system or applications have been configured and designed appropriately and properly as per the requirements, specifications and lock down standards given by the clients and the customers is done.

- Thus, this kind of compliance testing provides robust, adequate and efficient controls to ensure the availability, integrity and confidentiality of the software system or application is not affected during its normal usage and is maintained throughout the whole working process.

Management of IT and enterprise architecture
- It refers to the compliance testing in which the verification of the fact that the all the in-place IT management infrastructure aspects of the software system or the application have been put in their appropriate place is done.

- This is generally done to ensure that the audit, change in controls, security procedures and business continuity have been documented, formulated and put in their proper place and remain effective.

Inter- connection Policy
It refers to the compliance testing in which the verification of fact that the business continuity controls and adequate security measures that govern the connection of the software system with other systems like the systems for tele- communication, extranets, intranets, internet and so on, have been put in their appropriate place, have been cross checked with the specifications and requirements stated by the clients and the customers and have been fully documented is carried out.

These were some standard compliance tests.
Apart from these there are some normal compliance tests which encompass either a few or all of the compliance tests mentioned above.
- Some lockdown policies are applied to the underlying applications or software systems and operating systems.
- Some of these policies are passed by the clients or the customers and some by the concerned parties.
- These policies can be referred and can be used as a guidelines as and when required by the customers or clients when the software testers or developers have already performed a compliance test.
- They can also be referred after the penetration testing and vulnerability assessment of the software system or application so that more security measures can be applied to the system’s enterprise in order to improve its security.

The national security agency or NSA as it is often abbreviated has provided a number of lock down policies and guidelines to increase the awareness of the security affairs that are affecting our operating systems, software systems and applications etc.
The policies cover the following:

- Database servers
(a) oracle 10g
(b) oracle 9i
(c) Microsoft SQL server

- Operating systems
(a) Apple server operating systems
(b) Apple Mac OS
(c) Microsoft Windows NT
(d) Microsoft windows XP
(e) Microsoft windows 2000
(f) Sun Solaris 8
(g) Sun Solaris 9
(h) Microsoft windows server 2003


- Routers
- Switches
- Web servers and browsers
- IP and VoIP telephony
- SQL Server 2000
- BIND
- Novell eDirectory

WebApp Interface Design - Interface Control Mechanisms and Interface Design Workflow

INTERFACE CONTROL MECHANISM
The objectives of Web application interface are:
- establishing a consistent window into content and functionality provided by interface.
- guiding the users through interactions with web application.
- organizing the content and navigation options.

A metaphor is drawn that guides the user interaction and enables the user to gain understanding of the interface. Some interaction mechanisms available to web application designers are
- navigation menus that list key content and or functionality.
- graphic icons that enable user to select some property or specify a design.
- graphic images that implements a link to content object or the functionality of web application.

INTERFACE DESIGN WORKFLOW
It includes the following tasks:
- The information contained in analysis model is reviewed and refined.
- A rough sketch of web application interface layout is developed.
- The user objectives are mapped to specific interface actions.
- Set of user tasks associated with each action are defined.
- For each interface action, storyboard screen images are developed.
- Input from aesthetic design can be used to refine interface layout.
- User interface objects required to implement interface are identified.
- A procedural representation of user's interaction is developed.
- A behavioral representation is developed.
- Interface layout is described.
- Interface design model is refined and reviewed.

What is meant by Relationship-Navigation Analysis (RNA)?

Relationship navigation analysis (RNA) is a series of analysis steps to identify relationships among the elements that are left uncovered during the creation of the analysis model. There are five steps that constitutes the RNA approach:
- Stakeholder analysis establishes stakeholder hierarchy and identifies various user categories.
- Element analysis identifies content objects and functional elements that are in interest to end uses.
- Relationship analysis identifies the relationship among web application elements.
- Navigation analysis identifies the accessibility of elements by users.
- Evaluation analysis identifies the cost and benefit included.

RELATIONSHIP ANALYSIS
To assess analysis model elements to understand relationships among them, some guidelines are:
- the attributes identified for element.
- whether description about element exists and where?
- is element composed of other smaller elements?
- is element a member of larger collection of elements?
- does analysis class describe the element?
- in using the element, what are the pre and post conditions.
- is the element used in specific ordering of other elements?
- does the element appear in the same place?

The answers to above questions helps the web engineer to position the element in question within the web application and to establish relationships among elements.

NAVIGATION ANALYSIS
After relationship are identified among elements, the web engineer defines how the user category navigates from one element to another. The questions that would clear the navigation requirements are:
- how are navigation errors handled?
- should certain elements be easier to reach?
- should group element navigation be given priority over specific element navigation?
- should links be used for navigation?
- should there be a navigation log for users?
- should a navigation map or menu be established?
- for which user category an optimal navigation be designed?

What are the guidelines to be remembered if In House Web Engineering strategy is chosen for web application development?

Due to the increasing complexity, the web application project becomes like a software engineering project management. It is important to recognize that the guidelines recommended for small and moderately sized WebE projects can be performed quickly. In no case, should WebE planning for projects of this size take more than 5 percent of overall project effort :

- One should understand the scope, the dimensions of change, and project constraints. For an effective WebApp planning, requirements gathering and customer communication are essential precursors.
- An incremental project strategy should be developed so that evolution is not uncontrolled and chaotic.
- Risk analysis should be performed. All risk management tasks are performed for web engineering projects but the approach is abbreviated. Schedule and technology risk is the most important concern for most web engineers.
- The overall project estimate should be developed which focuses on macroscopic rather than microscopic issues.
- A set of web engineering tasks is selected which is appropriate for characteristics of problem, product, project, people on web engineering team.
- A schedule is established in which web engineering tasks are distributed along project timeline for increment to be developed.
- Regardless of project size, it is important to establish project milestones so that progress can be assessed.
- A change management is facilitated by incremental development strategy recommended for web applications. There is a possibility to delay change until next increment which in turn reduces the delay effects that are associated with changes.

What are the guidelines to be remembered if outsourcing strategy is chosen for web application development?

Web applications are outsourced to vendors who specialize in web development. There are some guidelines to be followed while considering outsourcing strategy for the web development:

PROJECT INITIATION :
Before searching for an outsourcing vendor, some tasks needs to be done :
- Analysis tasks should be performed internally.
- Web application audience are identified.
- Overall goals and objectives are defined.
- A rough design of the web application should be developed internally.
- A rough project schedule including delivery dates, milestones dates should be developed.
- Responsibilities for internal organization and outsourcing vendor is created.
- Degree of interaction and oversight with contracting organization is identified.

SELECTING OUTSOURCING VENDORS :
- Interview clients to determine the vendor's professionalism, ability to meet schedule.
- Determining the name of the vendor's chief web engineer.
- Examine work samples of vendor.

ASSESS THE VALIDITY OF PRICE QUOTES AND RELIABILITY OF ESTIMATES:
- Does the quoted cost provide direct or in direct return on investment.
- doe the vendor providing the quote has the professionalism and experience.

UNDERSTANDING THE DEGREE OF PROJECT MANAGEMENT YOU CAN EXPECT:
- It depends on size, cost and complexity of the web application.
- Plans are developed for mitigating, monitoring and managing risks.
- Quality assurance and change control mechanisms are defined.
- Effective communication between contractor and vendor should be established.

THE DEVELOPMENT SCHEDULE SHOULD BE ASSESSED:
- The development schedule should have a fine granularity.
- Tasks and minor milestones should be scheduled on daily timeline.

MANAGE SCOPE:
- Scope changes as web application project moves forward.
- To manage scope, the work to be performed within an increment is frozen.
- Changes are deployed until the next web application increment.

Flow oriented Modeling - Creating a Control Flow Diagram and The Control Specification

Flow models focus on the flow of data objects as they are transformed by processing functions. There are applications which are driven by events rather than data and produce information that is controlled and process information keeping in mind the time and performance. In such situations, control flow diagrams comes into picture along with data flow modeling.

There are some guidelines to select potential events for a control flow diagram:
- all sensors that are read by the software are listed.
- all interrupt conditions are listed.
- all switches actuated by operator are listed.
- all data conditions are listed.
- all control items are reviewed.
- all states that describe the behavior of a system are listed.
- all transitions between states are defined.
- all possible omissions should be kept in focus.

The Control Specification contains a state diagram which is sequential specification of behavior. It contains a program activation table which is a combinatorial specification of behavior. Control specification does not give any information about the inner working of the processes activated as a result of this behavior.

Eliciting Requirements - what are basic guidelines for conducting collaborative requirements gathering meeting? PART 1

For collaborative requirements gathering, stakeholders and developers work together to identify the problem, propose a solution and negotiate approaches. The basic guidelines include:
- software engineers and customers attend meetings.
- rules for preparation and participation are established.
- agenda that covers important points and encourage free flow of ideas.
- meeting is controlled by a facilitator who can be a customer, developer or an outsider.
- worksheets, wall stickers, chat room etc. are used.
- goal is to identify the problem, propose a solution and negotiate approaches.

If a system or product will serve many users, one should be certain that requirements are elicited from representative cross-section of users. If only one user defines all requirements, acceptance risk is high. As requirements gathering meeting begins, the first point of discussion is need and justification of the new product. Once agreement is established, each participant presents his lists for discussion in one particular area. After this, combined list is prepared by group after which facilitator coordinates discussion.
Avoid the impulse to shoot down a customer's idea as "too costly" or impractical. The idea is to negotiate a list that is acceptable to all.

Once the lists are completed, team is divided into sub teams and each works to develop mini specifications. Additions, deletions and elaborations are made. After this, each attendee makes a list of validation criteria and finally one or more participant is assigned the task of writing a complete draft specification.