CLASS:

class is a blueprint or template or set of instructions to build a specific type of object. Every
object is built from a class. Each class should be designed and programmed to accomplish
one, and only one, thing. (You'll learn more about the Single Responsibility Principle
in OOP concepts, Because each class is designed to have only a single responsibility, many
classes are used to build an entire application.

An instance is a specific object built from a specific class. It is assigned to a reference

variable that is used to access all of the instance's properties and methods. When you make
a new instance the process is called instantiation and is typically done using
the new keyword.

public var myFirstObject:Sprite;

Then you create the new object—using the keyword new—and assign it to the reference
variable.

myFirstObject = new Sprite();

You can either declare a reference variable and assign a newly instantiated object into it in
separate statements:

public var anotherObject:Sprite;

…
anotherObject = new Sprite();

or in the same statement:

public var myFirstObject:Sprite = new Sprite();

It’s simple to instantiate the same class numerous times. The code below creates four
instances of the Sprite class. Each instance is assigned to its own reference variable.

public var firstSprite:Sprite = new Sprite();

public var secondSprite:Sprite = new Sprite();
public var thirdSprite:Sprite = new Sprite();
public var fourthSprite:Sprite = new Sprite();
Objects

In programming terms, an object is a self-contained component that contains properties

and methods needed to make a certain type of data useful. An object’s properties are what
it knows and its methods are what it can do. The project management application
mentioned above had a status object, a cost object, and a client object, among others. One
property of the status object would be the current status of the project. The status object
would have a method that could update that status. The client object’s properties would
include all of the important details about the client and its methods would be able to
change them. The cost object would have methods necessary to calculate the project’s cost
based on hours worked, hourly rate, materials cost, and fees.

In addition to providing the functionality of the application, methods ensure that an

object’s data is used appropriately by running checks for the specific type of data being
used. They also allow for the actual implementation of tasks to be hidden and for
particular operations to be standardized across different types of objects. You will learn
more about these important capabilities in OOP concepts.Encapsulation
Objects are the fundamental building blocks of applications from an object-oriented
perspective. You will use many objects of many different types in any application you
develop. Each different type of object comes from a specific class of that type.

Data abstraction:

Abstraction is a basic OOP concept which focuses on just the relevant data of an object and
hides all the irrelevant details which may or may not be for generic or specialized behavior.
It hides the background details and emphasizes on the essential points to reduce complexity
and increase efficiency. Basically, abstraction is a programming tool to manage complexity.
Abstraction focuses on ideas rather than events. It hides the details on the design level by
providing functionality to the users. The resulting object can also be called an abstraction.
The programmer makes sure the named entity will have all the essential aspects included
and none of the irrelevant ones.

Let’s take a real-world example of abstraction. Let’s consider the case of a vehicle, which
in this case is your vehicle. A mechanic tries to repair your car or let’s say a specific part of
your car. Here, you are the user and you don’t want to get into the specifics of your car or
what part actually broke. You don’t actually care about those things; you just want your
vehicle back in its original condition without worrying about the details. So, you actually
told the mechanic what you want by segregating the implementation part. This is
abstraction. You focused on the most essential thing, which is getting your car fixed, rather
than focusing on the specifics.

Data encapsulation:

Encapsulation is yet another OOP concept which binds data and functions into a single

component while restricting access to some components. It’s one of the main fundamental

concepts of OOP which wraps data and information under a single unit. In technical terms,

encapsulation means hiding attributes to shield variables from outside access so that

change in one part of an application won’t affect the other parts. On the contrary, by

making the information more open you’ll risk misuse of data. It provides basic integrity to

the data by protecting it from the outside world. In simple terms, it hides the extra details

from the outside world.

Let’s take an example of a Bluetooth mouse. You only need to know about the device’s

behavior without worrying about the implementation details like what kind of sensors the

mouse has, is it wireless or not, etc. Every single detail describes the mouse but regardless

of the details, it’s just a mouse. You just need an interface to use the mouse, which in this

case is the mouse pointer. This is encapsulation.

Differnece between data abstraction and data encapsulation:

 Differences in “ Definition” of Abstraction and Encapsulation –

Abstraction is a fundamental OOP concept which emphasizes on all the essential aspects of
an object by hiding the irrelevant details to increase efficiency and eliminate complexity.
Encapsulation, on the other hand, is a data hiding mechanism which wraps the data and
information in a capsule to restrict access from outside world.

Differences in “Functionality” of Abstraction and Encapsulation–

Abstraction is a data hiding mechanism which highlights only the essential features to
make complex programs simpler, while encapsulation, on the other hand, is a method of
binding data and codes into a single entity. The idea is to shield the implementation details
from external access.

Differences in “Implementation” of Abstraction and Encapsulation –

Abstraction is implemented using abstract class and interface, while encapsulation is

implemented using access modifiers. Five types of modifiers are used to encapsulate data:
Private, Public, Internal, Protected, and Protected Internal.

Differences in “Concept” of Abstraction and Encapsulation–

The idea behind abstraction is to focus on what rather than how. Encapsulation hides the
internal mechanics of how. For example, when you drive a car, you know exactly what the
brake pedal does but you may not know the whole mechanism behind it because the data is
encapsulated.

Differences in “Example” of Abstraction and Encapsulation – Let’s take an example of

a smartphone. You know what it does but you may not know how it does what it does. You

only care about the display screen and keypad buttons rather than worrying about its

inner circuitry. Here, smartphone is an abstract where the inner implementation details

are encapsulated.
Agile

AGILE methodology is a practice that promotes continuous iteration of development and

testing throughout the software development lifecycle of the project. Both development and
testing activities are concurrent unlike the Waterfall model

The agile software development emphasizes on four core values.

1. Individual and team interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agile has been the buzzword in project management for about a decade, and with
good reason. Agile is actually an umbrella term over several project management
approaches that are characterized by their ability to allow project teams to respond
to changing requirements and priorities by using incremental work packages. While
all agile methods have common characteristics, each agile method has unique
processes that set it apart. Let's look at how each method is used with Charlie's
team, who is developing a new software game.

Agile types:

1: Scrum

SCRUM is an agile development method which concentrates specifically on how to manage

tasks within a team-based development environment. Basically, Scrum is derived from
activity that occurs during a rugby match. Scrum believes in empowering the development
team and advocates working in small teams (say- 7 to 9 members). It consists of three roles,
and their responsibilities are explained as follows:

 Scrum Master
o Master is responsible for setting up the team, sprint meeting and removes
obstacles to progress
 Product owner
o The Product Owner creates product backlog, prioritizes the backlog and is
responsible for the delivery of the functionality at each iteration
 Scrum Team
o Team manages its own work and organizes the work to complete the sprint
or cycle
Product Backlog

This is a repository where requirements are tracked with details on the no of requirements
to be completed for each release. It should be maintained and prioritized by Product
Owner, and it should be distributed to the scrum team. Team can also request for a new
requirement addition or modification or deletion

Scrum Practices

Practices are described in detailed:

Process flow of Scrum Methodologies:

Process flow of scrum testing is as follows:

 Each iteration of a scrum is known as Sprint

 Product backlog is a list where all details are entered to get end product
 During each Sprint, top items of Product backlog are selected and turned into
Sprint backlog
 Team works on the defined sprint backlog
 Team checks for the daily work
 At the end of the sprint, team delivers product functionality

2: eXtreme Programming (XP)

Extreme Programming technique is very helpful when there is constantly changing

demands or requirements from the customers or when they are not sure about the
functionality of the system. It advocates frequent "releases" of the product in short
development cycles, which inherently improves the productivity of the system and also
introduces a checkpoint where any customer requirements can be easily implemented. The
XP develops software keeping customer in the target. Business requirements are gathered
in terms of stories. All those stories are stored in a place called the parking lot.

In this type of methodology, releases are based on the shorter cycles called Iterations with
span of 14 days time period. Each iteration includes phases like coding, unit testing and
system testing where at each phase some minor or major functionality will be built in the
application.

Phases of eXtreme programming:

There are 6 phases available in Agile XP method, and those are explained as follows:
Planning

 Identification of stakeholders and sponsors

 Infrastructure Requirements

Analysis

 Capturing of Stories in Parking lot

 Prioritize stories in Parking lot
 Define Iteration SPAN(Time)

Design

 Break down of tasks

 Test Scenario preparation for each task
 Regression Automation Framework

Execution

 Coding
 Unit Testing
 Execution of Manual test scenarios
 Defect Report generation
 Conversion of Manual to Automation regression test cases

Wrapping

 Small Releases
 Regression Testing
 Demos and reviews

Closure

 Pilot Launch
 Training
 Production Launch
 SLA Guarantee assurance

3: Crystal Methodologies
Crystal Methodology is based on three concepts

1. Chartering: Various activities involved in this phase are creating a development

team, performing a preliminary feasibility analysis, developing an initial plan and
fine-tuning the development methodology
2. Cyclic delivery: The main development phase consists of two or more delivery
cycles, during which the
1. Team updates and refines the release plan
2. Implements a subset of the requirements through one or more program test
integrate iterations
3. Integrated product is delivered to real users
4. Review of the project plan and adopted development methodology
3. Wrap Up: The activities performed in this phase are deployment into the user
environment, post- deployment reviews and reflections are performed.

Dynamic Software Development Method (DSDM)

DSDM is a Rapid Application Development (RAD) approach to software development and

provides an agile project delivery framework. The important aspect of DSDM is that the
users are required to be involved actively, and the teams are given the power to make
decisions. Frequent delivery of product becomes the active focus with DSDM. The
techniques used in DSDM are

1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project consists of 7 phases

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

SDLC
Software is a complex product that is developed and delivered through a series of
steps. That is the one thing all the various methods have in common: one way or
another, software, like all products, starts as an idea. The idea then becomes a
document, or perhaps a prototype, depending on the method in use.

Whether a document, diagram, or working software, the artifact created in one

step becomes the input to the next step. Eventually, the software is delivered to
the customer. The sequence of steps used by these methods is commonly referred
to as the Software Development Lifecycle (SDLC.)

How does the SDLC work?

The process of software development is a never-ending cycle. The first release of

a software application is rarely “finished.” There are almost always additional
features and bug fixes waiting to be designed, developed, and deployed.

Reports from error monitoring software about usability and bugs feed back into
the process of software development, and become new feature requests and
improvements to existing features. This is why the Software Development Life
Cycle is the most general term for software development methods. The steps of
the process and their order vary by method. Regardless of method, they typically
run in cycles, starting over with each iteration.

PHASES OD SDLC:

1. Planning

The planning phase involves aspects of project and product management. This
may include:

Resource allocation (both human and materials)

Capacity planning

Project scheduling

Cost estimation

Provisioning
The outputs of the planning phase include: project plans, schedules, cost
estimations, and procurement requirements. Ideally, Project Managers and
Development staff collaborate with Operations and Security teams to ensure all
perspectives are represented.

2. Requirements

The business must communicate with IT teams to convey their requirements for
new development and enhancement. The requirements phase gathers these
requirements from business stakeholders and Subject Matter Experts (SMEs.)

Architects, Development teams, and Product Managers work with the SMEs to
document the business processes that need to be automated through software.
The output of this phase in a Waterfall project is usually a document that lists
these requirements. Agile methods, by contrast, may produce a backlog of tasks
to be performed.

3. Design and prototyping

Once the requirements are understood, software architects and developers can
begin to design the software. The design process uses established patterns for
application architecture and software development. Architects may use an
architecture framework such as TOGAF to compose an application from existing
components, promoting reuse and standardization.

Developers use proven Design Patterns to solve algorithmic problems in a

consistent way. This phase may also include some rapid prototyping, also known
as a spike, to compare solutions to find the best fit. The output of this phase
includes:

Design documents that list the patterns and components selected for the project

Code produced by spikes, used as a starting point for development

4. Software development
This phase produces the software under development. Depending on the
methodology, this phase may be conducted in time-boxed “sprints,” (Agile) or
may proceed as a single block of effort (Waterfall.) Regardless of methodology,
development teams should produce working software as quickly as possible.
Business stakeholders should be engaged regularly, to ensure that their
expectations are being met. The output of this phase is testable, functional
software.

5. Testing

The testing phase of the SDLC is arguably one of the most important. It is
impossible to deliver quality software without testing. There is a wide variety of
testing necessary to measure quality:

Code quality

Unit testing (functional tests)

Integration testing

Performance testing

Security testing

The best way to ensure that tests are run regularly, and never skipped for
expediency, is to automate them. Tests can be automated using Continuous
Integration tools, like Codeship, for example. The output of the testing phase is
functional software, ready for deployment to a production environment.

6. Deployment

The deployment phase is, ideally, a highly automated phase. In high-maturity

enterprises, this phase is almost invisible; software is deployed the instant it is
ready. Enterprises with lower maturity, or in some highly regulated industries,
the process involves some manual approvals. However, even in those cases it is
best for the deployment itself to be fully automated in a continuous deployment
model. Application Release Automation (ARA) tools are used in medium and
large-size enterprises to automate the deployment of applications to Production
environments. ARA systems are usually integrated with Continuous Integration
tools. The output of this phase is the release to Production of working software.
7. Operations and maintenance

The operations and maintenance phase is the “end of the beginning,” so to speak.
The Software Development Life Cycle doesn’t end here. Software must be
monitored constantly to ensure proper operation. Bugs and defects discovered in
Production must be reported and responded to, which often feeds work back into
the process. Bug fixes may not flow through the entire cycle, however, at least an
abbreviated process is necessary to ensure that the fix does not introduce other
problems (known as a regression.)