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.

Active Directory

Active Directory (AD) is a directory service

Created by Microsoft for Windows domain networks

It is included in most Windows Server operating systems

Server computers that run Active Directory are called domain controllers

An AD domain controller authenticates and authorizes all users and computers in a Windows domain type network

—Assigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user.

Active Directory makes use of Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Kerberos and DNS.

The Lightweight Directory Access Protocol (LDAP; pron.: /ˈɛldæp/) is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.

Directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

Project Management - Basics

Data Architecture

Models, policies, rules, or standards that govern which data is collected, and how it is stored, arranged, and put to use in a database system, and/or in an organization.

Data architecture is one of the pillars of Enterprise Architecture. The other pillars are the Application Architecture, Business Architecture and Integration Architecture. The Data Architecture pillar is the definition or blueprint of the data design which will be used in achieving the implementation of a physical database.

The data architecture can be compared to a house design where all the descriptions of the house structure to be built – from the choice of materials, sizes and style of the rooms and roofing, lay out of the plumbing and electrical structures – are described in the blueprint.

MindTools

Project Management Framework - Project Management Phases and Processes, Log frames and the Logical Framework Approach, Theory of Change for evaluation, Project Initiation Documents, The RFP, also referred to as Invitation to Tender (ITT) or Request for Information (RFI), forms the cornerstone of this bidding process. Risk Impact/Probability Chart.

     

Scheduling - Gantt Charts, Gap Analysis, Critical Path Analysis and PERT Charts

PERT (Program Evaluation and Review Technique)

PERT is a variation on Critical Path Analysis that takes a slightly more skeptical view of time estimates made for each project stage. To use it, estimate the shortest possible time each activity will take, the most likely length of time, and the longest time that might be taken if the activity takes longer than expected.

Use the formula below to calculate the time to use for each project stage:

Shortest time + 4 x likely time + longest time

-----------------------------------------------------------

6

This helps to bias time estimates away from the unrealistically short time-scales normally assumed.

Scope Management - Business Requirements Analysis

Building Support for Your Projects –

               

The RACI Matrix

A RACI matrix is a very important tool that can help in the implementation and correct functioning of a process. The RACI matrix is mostly used to align the human elements in the process. Usually there are many different people involved in any process and they have differing responsibilities. A RACI matrix makes an explicit documentation of this and keeps as a ready reference to be used at different stages in the process. Here is how the RACI matrix can be utilized. Responsible: This is the class of people who are ultimately responsible for getting the work done. This may refer to the individual workers that perform the given task or it could refer to the system in case the task is automated. Accountable: This is the class of people that are accountable to oversee that the work gets done. This usually means the immediate manager overseeing the work. Consulted: These may be subject matter exerts who need to be consulted at the time of an exception. There is a possibility that am unanticipated scenario arises in a process. These are the people who will do the thinking and suggest any deviations from the Standard Operating Procedure (SOP).

Informed: This is the class of people who have some interest in the performance of a given task. This may be a manager trying to control the execution of the task at hand. Also this could be an input signal to the other process.

Rules for using RACI Matrix

• Only One Responsible and Accountable Person: It is essential that only person be assigned the R/A roles. Having more than one person responsible for the same task increases ambiguity and the chances of the work not being performed. It could also lead to duplication of work and wastage of efforts and costs.

Having more than one accountable person means again leads to the same problem. However, having only person accountable also leads to a problem. If the assigned person is incompetent the whole process may go for a toss. It is for this reason that there is often a hierarch of accountable people in place.

• Responsible-Accountable Is Mandatory: The consult or inform roles are not mandatory for every activity. It is possible that some activities may not require them at all. But the responsible accountable roles must be assigned. Even if the system is performing the tasks automatically, someone must be made accountable to see that it does get done.
• Communication with the Consultant: There must be a two way channel of communication with the consultant. This communication is itself a task and must be explicitly listed having its own responsible accountable persons. The important aspect is that the communication be two-way. Hence one has to ensure that adequate follow up is done and minimum time lag is required to complete this communication.
• Inform the Required Stakeholders: This is a one way channel of communication. It is usually meant to be a signal for some other process to begin or as a control metric to ensure smooth functioning of the same process. Usually this is automated but needs accountability like other automated tasks.

Influence maps are a natural extension of Stakeholder Analysis. Your project's success can depend on identifying its key stakeholders and then managing the various relationships between them. Stakeholders have the power to help or hurt your initiatives, so stakeholder management is an important aspect of project management.

Communication - Project Milestone Reporting, Dashboards

Change Management

Project Improvement and Review

LINQ

Innovation introduced in Visual Studio 2008 and .NET Framework version 3.5

Language-Integrated Query (LINQ) is a set of features that extends powerful query capabilities to the language syntax of C# and Visual Basic.

DLinq (also referred to as LINQ to SQL) is specifically the version of LINQ that focuses on querying data from relational data sources. XLinq (LINQ to XML) is that aspect of LINQ that is geared towards querying XML data.

In addition, the query functionality is not just restricted to SQL or XML data; you can apply LINQ to query any class as long as that class implements IEnumerable class.

WPF, XAML

Introduction to Windows Presentation Foundation - WPF (http://www.wpftutorial.net/WPFIntroduction.html)

WPF Layout (http://www.wpftutorial.net/LayoutProperties.html)

Introduction to XAML (http://www.wpftutorial.net/XAML.html)