Project Charter

A project charter (PC) is a document that states a project exists and provides the project manager with written authority to begin work.

The document helps the project manager to communicate his authority and explain to project participants and stakeholders why the project is needed, who it involves, how long the project will take to complete, how much it will cost, what resources are needed and how successful completion of the project will help the organization. Once created, the document is rarely (if ever) amended.

Depending on a company's culture and management style, a charter may serve the same purpose as a business case.  In a large corporation, the charter may be a multi-page document written up by mid-level management after a business case has been approved but before the project scope has been defined.  In a small startup company, however, the charter might just be a few paragraphs with bulleted items and the company president’s signature.

Project charter templates often include the following components:

Project goal - documents the reasons for undertaking the project in clear, concise language.
Project participants - identifies what people need to be involved in the project and clearly states their roles.
Stakeholders - identifies other people who will be directly affected by the project and need to know about the project's progress.
Requirements - identifies what resources are required for the project's objectives to be achieved.
Constraints - documents potential roadblocks or bottlenecks.
Milestones - identifies start date and completion dates as well as dates for other important checkpoints.
Communication - specifies how the project manager will communicate with project owners, participants and stakeholders through the project.
Deliverables - documents what specific products, processes or services the project will provide upon completion.

Prerequisites for Developing Business Requirement Specification

§  Project Charter – The first prerequisite for the Business Requirements Specifications is the Project Charter. The Business Requirements Specification allows you to review the Project Charter and ensure that its objective, goals, scope, team, and approvers are correct.

§  Current Environment Assessment – The second prerequisite is a current environment assessment. This includes a process map of the current environment highlighting areas that will be changed during the project.

IT Jargon

Cloud computing

This is a classic example of an IT term that very few people can explain. Even company directors whose entire business model depends on cloud computing would struggle.

It becomes even more confusing when we refer to 'the cloud' as if it is some magical place in the sky. The cloud is basically a metaphor for the internet, so why not call it that?

That would essentially make cloud computing internet computing. Put it that way, and it may be easier to explain how it all works and prevent people from gazing expectantly at the heavens. 

XaaS

The term XaaS is used to describe something that is provided as a service over the internet. A cloud-based service, to use the jargon referred to above.

We have SaaS (Software as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service) and many more, and each acronym basically describes something that has traditionally been provided locally that is now provided via the web on a subscription or pay-per-use basis.

So it's cloud computing, right? Or internet computing as we've established? Well, yes, when you think about it. So perhaps we could just use the term internet-based services instead of adding all the a's and S's.

Big data

When we say big data, we essentially mean lots of data. In fact, it's a vast amount of structured and unstructured data that is coming from a huge array of different sources.

It's called big data, not because there's anything inherently new or different about it, but because it is now much more available to us, it's much more varied than ever before, and because we now have the technical capabilities to store it and to analyse it effectively.

In this sense, all data is big data. So why don't we just call it data? Of course it's not just the term big data itself that causes confusion, but the huge amount of jargon that's been invented around it, from NoSQL databases to acid tests and massively parallel processing. Now we're really confused.

Gamification

This is one we're hearing a lot at the moment, and it is used to describe the use of game elements in non-gaming applications to make them more engaging to users. It's about breaking things down into simple steps with rewards at the completion of each one, like a game.

It's become something of a buzz word - one of those that makes you sound really intelligent if you can throw it into a conversation. But it essentially means turning something that can be pretty boring into something fun.

Of course, the word gamification is used in other industries, but it crops up frequently in the IT sector because, let's face it, there's a lot about IT applications that is less than thrilling to those who don't have an innate passion for technology.

Digital disruptors

Who are these people? They sound like villains out to destroy our world. Well, this is and is not true. If you're a business owner, then perhaps they are, but if you're a consumer then the opposite is true. The digital disruptors can be the heroes, using technology to make everyone's lives that bit easier.

They are simply individuals or companies who employ technology to create better products and services than the non-digital versions that have come before. An example? The makers of the diet and fitness apps that are slowly eating away at subscriptions to traditional weight loss clubs.

In this sense, they are in fact disrupting traditional business models. But we live in a digital age, so of course technology is going to challenge what has come before. It's called moving with the times. If we didn't, we'd still be sending telegrams. So let's just call them rivals, shall we?

Cognos vs Informatica

Cognos and Informatica are not same tool that does the same work.

Informatica is a ETL tool.  It extracts data from various sources (Oracle, db2, Sybase, etc) transforms it and loads data into the warehouse.

Cognos is a reporting tool.  It is used for business purpose to generate some reports (may be pictorial or statistical representation).   It uses the datawarehouse information to generate a report.
Oracle business intelligence is another reporting tool which is becoming famous today.

Software Development Framework

.NET Framework (pronounced dot net) is a software framework developed by Microsoft that runs primarily on Microsoft Windows. It includes a large class library known as Framework Class Library (FCL) and provides language interoperability (each language can use code written in other languages) across several programming languages. Programs written for .NET Framework execute in a software environment (as contrasted to hardware environment), known as Common Language Runtime (CLR), an application virtual machine that provides services such as security, memory management, and exception handling. FCL and CLR together constitute .NET Framework.

FCL provides user interface, data access, database connectivity, cryptography, web application development, numeric algorithms, and network communications. Programmers produce software by combining their own source code with .NET Framework and other libraries. .NET Framework is intended to be used by most new applications created for Windows platform. Microsoft also produces an integrated development environment largely for .NET software called Visual Studio.

Grails is an Open Source, full stack, web application framework for the JVM. Grails is an open source web application framework that uses the Groovy programming language (which is in turn based on the Java platform). It is intended to be a high-productivity framework by following the "coding by convention" paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer.[citation needed]

Grails was previously known as 'Groovy on Rails'; in March 2006 that name was dropped in response to a request by David Heinemeier Hansson, founder of the Ruby on Rails framework.[1] Work began in July 2005, with the 0.1 release on March 29, 2006 and the 1.0 release announced on February 18, 2008.

G2One - The Groovy Grails Company - was acquired by SpringSource in November, 2008,[2] and it was later acquired by VMware.[3]

A JDK is required in your Grails development environment. A JRE is not sufficient.

Grails was developed to address a number of goals:

Provide a web framework for the Java platform.

Re-use existing Java technologies such as Hibernate and Spring under a single interface

Offer a consistent development framework.

Offer documentation for key portions of the framework:

The Persistence framework.

Templates using GSP (Groovy Server Pages).

Dynamic tag libraries for creating web page components.

Customizable and extensible Ajax support.

Provide sample applications that demonstrate the framework.

Provide a complete development mode, including a web server and automatic reload of resources.

Kind of Testing

• Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
• White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
• unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
• incremental integration testing - continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
• integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
• functional testing - black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
• system testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
• end-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
• sanity testing or smoke testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
• regression testing - re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing approaches can be especially useful for this type of testing.
• acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
• load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
• stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
• performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
• usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
• install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
• recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
• failover testing - typically used interchangeably with 'recovery testing'
• security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
• compatibility testing - testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
• exploratory testing - often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
• ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
• context-driven testing - testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
• user acceptance testing - determining if software is satisfactory to an end-user or customer.
• comparison testing - comparing software weaknesses and strengths to competing products.
• alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
• beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
• mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

UAT

What is User Acceptance Testing?
User Acceptance Testing (UAT) - also called beta testing, application testing, and/or end user testing - is a phase of software development in which the software is tested in the "real world" by the intended audience or a business representative. Whilst the technical testing of IT systems is a highly professional and exhaustive process, testing of business functionality is an entirely different proposition.

Tasks of User Acceptance Testing

When performing UAT, there are seven (7) basic steps to ensure the system is tested thoroughly and meets the business needs.
1 – Analyze Business Requirements
2 – Identify UAT Scenarios
3 – Define the UAT Test Plan
4 – Create UAT Test Cases
5 – Run the Tests
6 – Record the Results
7 – Confirm Business Objectives are met


Documents Used by the Business Analyst

One of the most important activities performed by the Business Analyst is to identify and develop UAT test scenarios. These scenarios are derived by analyzing the documents that were previously developed during the early phases of the project.  These documents include:

- Business Use Case
- Business Process Flows
- Project Charter
- Context Diagram
- Business Requirements Document (BRD)
- System Requirements Specification (SRS)
- Testing Guidelines and Techniques
- Other Vendor’s Deliverables

Documents Created by the Business Analyst

Once UAT Test Scenarios are identified, the Business Process Unit will create three deliverables:
- UAT Test Plan
- UAT Test Cases
- After running the tests, a Defect Log captures problems

UAT Test Plan
The UAT Test Plan documents the strategy that will be used to verify and ensure an application meets its requirements to the business. The UAT Test Plan is a document which outlines the plan for user acceptance testing of the project deliverables. This document is a high level guide, and will refer to test cases that will be developed and used to record the results of user testing.

UAT Test Cases
The User Acceptance Test Cases help the test execution team to test the application thoroughly. This also helps ensure that the UA testing provides sufficient coverage of all the UAT scenarios. The Use Cases created during the Requirements definition phase may be used as inputs for creating test cases.

The User Acceptance Test Case describes in a simple language the precise steps to be taken to test something

UAT Defect Log
The UAT Defect Logis a document for capturing and reporting defects identified during UAT. Defects are documented so that they can be evaluated and resolved.

Information included in the Defect Log is:

-          Severity (e.g., High, Med, Low)
-          Status (e.g., Open, Closed, Deferred)
-          Date Reported/Fixed
-          Problem Description

Payment Gateway

Payment gateway connects your website or business application to the banking infrastructure.

A payment gateway facilitates the transfer of information between a payment portal (such as a website, mobile phone or interactive voice response service) and the Front End Processor or acquiring bank.

It is usually a third-party service that is actually a system of computer processes that process, verify, and accept or decline credit card transactions on behalf of the merchant through secure Internet connections. The payment gateway is the infrastructure that allows a merchant to accept credit card and other forms of electronic payment.

HTTP Methods GET and POST

GET requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause.

and

POST submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.

So essentially GET is used to retrieve remote data, and POST is used to insert/update remote data.