Tag: Uncategorized

Java programming language was originally developed by Sun Microsystems which was initiated by James Gosling and released in 1995 as core component of Sun Microsystems’ Java platform (Java 1.0 [J2SE]).
The latest release of the Java Standard Edition is Java SE 8. With the advancement of Java and its widespread popularity, multiple configurations were built to suit various types of platforms. For example: J2EE for Enterprise Applications, J2ME for Mobile Applications.
The new J2 versions were renamed as Java SE, Java EE, and Java ME respectively. Java is guaranteed to be Write Once, Run Anywhere.

Characteristics of JAVA

•   Object Oriented: In Java, everything is an Object. Java can be easily extended since it is based on the Object model.
•  Platform Independent: Unlike many other programming languages including C and C++, when Java is compiled, it is not compiled into platform specific machine, rather into platform independent byte code. This byte code is distributed over the web and interpreted by the Virtual Machine (JVM) on whichever platform it is being run on.
• Simple: Java is designed to be easy to learn. If you understand the basic concept of OOP Java, it would be easy to master.
•  Secure: With Java’s secure feature it enables to develop virus-free, tamper-free systems. Authentication techniques are based on public-key encryption.
•  Architecture-neutral: Java compiler generates an architecture-neutral object file format, which makes the compiled code executable on many processors, with the presence of Java runtime system.
•  Portable: Being architecture-neutral and having no implementation dependent aspects of the specification makes Java portable. Compiler in Java is written in ANSI C with a clean portability boundary, which is a POSIX subset.
• Robust: Java makes an effort to eliminate error prone situations by emphasizing mainly on compile time error checking and runtime checking.
• Multithreaded: With Java’s multithreaded feature it is possible to write programs that can perform many tasks simultaneously. This design feature allows the developers to construct interactive applications that can run smoothly.
• Interpreted: Java byte code is translated on the fly to native machine instructions and is not stored anywhere. The development process is more rapid and analytical since the linking is an incremental and light-weight process.
• High Performance: With the use of Just-In-Time compilers, Java enables high performance.
•  Distributed: Java is designed for the distributed environment of the internet.
•  Dynamic: Java is considered to be more dynamic than C or C++ since it is designed to adapt to an evolving environment. Java programs can carry extensive amount of run-time information that can be used to verify and resolve accesses to objects on run-time.

Scrum is an iterative and incremental Agile software development framework for managing product development. It defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal. Scrum is an agile way to manage a project, usually software development. In the Scrum world, instead of providing complete detailed descriptions about how everything is to be done on a project, much of it is left up to the software development team. This is because the team will know better how to solve the problem they are presented with.
Scrum relies on a self-organizing, cross-functional team. The Scrum team is self-organizing in that there are no overall team leaders who decide which person will be doing which task and how the problem will be solved. Those are issues that are decided by the team as a whole.
Scrum was conceived by Ken Schwaber and Jeff Sutherland in the early 1990s, who published a paper to describe the process. The term “scrum” is borrowed from the game of rugby to stress the importance of teams, and illustrates some analogies between team sports like rugby, and being successful in the game of new product development.
The research described in their paper showed that outstanding performance in the development of new, complex products is achieved when teams (small, self-organizing groups of people) are fed with objectives, not with tasks. The best teams are those that are given direction within which they have room to devise their own tactics on how to best move towards their shared objective.
Teams require autonomy to achieve excellence. The Scrum framework for software development implements these principles for developing and sustaining complex software projects. In February of 2001, Jeff and Ken were among 17 software development leaders who created a manifesto for Agile software development.
In 2002, Ken Schwaber founded the Scrum Alliance with Mike Cohn and Esther Derby, with Ken chairing the organization. In the years to follow, the highly successful, certified Scrum Master programs and its derivatives were created and launched In 2006. Jeff Sutherland created his own company, Scrum Inc., while continuing to offer and teach certified Scrum courses. Ken left the Scrum Alliance in the fall of 2009 and founded scrum.org to further improve the quality and effectiveness of Scrum, mainly through the Professional Scrum series. With the first publication of the Scrum Guide in 2010, and its incremental updates in 2011 and 2013, Jeff and Ken established a globally recognized body of knowledge.

Code must be formatted to agree to coding standards. It’s these coding standards that keep the code consistent and easy for the entire team to read and refactor. Code that looks the same also helps to encourage collective code ownership. It used to be quite common for a team to have a coding standards document that defined how the code should look, including the team’s best practices for styling and formatting. The problem with this is that people rarely read them, let alone follow them. These days, it’s much more common to use a developer productivity tool to automatically guide the user in best practices.

Popular tools in use today, certainly from a .NET perspective, are ReSharper from JetBrains, CodeRush from Dev Express, and JustCode from Telerik. These are all paid-for solutions, though. If you want to use a free alternative, then you can look at StyleCop for the .NET platform. Visual Studio also has its own versions of some of these tools built in, but it’s quite common to supplement Visual Studio with an additional add-on.
Other development platforms will have their own variants of these tools, either as separate additions to their environments, or built in to their IDEs. These tools are so unbelievably powerful that it really makes it frictionless to write code that conforms to a set of coding standards.
When you create a unit test before writing out your code, you’ll find it much easier and faster to create the code. The combined time it takes to create a unit test, and then create some code to make it pass that test, is about the same as just coding it out straightaway. Creating unit tests helps the developer to really consider what needs to be done, and then the system’s requirements are firmly nailed down by the tests. There can be no misunderstanding the specification written in the form of executable code, and you have immediate feedback while you work.
It’s often not clear when a developer has finished all the necessary functionality, and scope creep can occur as extensions and error conditions are considered, but if you create your unit tests first, then you know when you are done.

A common way of working while pairing with another developer is to have one developer write a failing test, and then the other developer to write just enough code to make that test pass. Then, the second developer writes the next failing test, and the first programmer writes just enough code to make that test pass. It almost feels like a game when you work in this way. I worked this way for quite a while when I was working for an internet bank, and once you get a good pace with your programming pair, you can become really productive really quickly.
Under XP, all code to be sent to production should be created by two people working together at a single computer. Pair programming increases software quality without impacting delivery time. It can feel counter-intuitive at first, but two people working at a single computer will add as much functionality as two people working separately, except that it will be much higher in quality, and with increased code quality comes big savings later on. The best way to pair programming is just to sit side-by-side in front of the monitor, and slide the keyboard back and forth between the two. Both programmers concentrate on the code being written.
Pair programming is a social skill that takes time to learn when you’re striving for a cooperative way to work that includes give and take from both partners, regardless of corporate status.
Without force-controlling the integration of code, developers test their code and integrate on their machines, believing all is well. But because of parallel integration with other programming pairs, there’s a combination of source code that has not been tested together, which means integration problems can happen without detection. If there are problems, and there is no clear-cut, latest version of the entire source tree, this applies not only to the source code, but to the unit test suite, which must verify the source code’s correctness.

If you cannot get your hands on a complete, correct, and consistent test suite, you’ll be chasing bugs that do not exist and overlooking bugs that do. It is now common practice to use some form of continuous integration system integrated with your source control repository. When a developer checks in some code, the code is integrated with the main source code tree and built, and the tests are executed. If any part of this process fails, the development team will be notified immediately so that the issue can be resolved.
It’s also common to have a source control system fail at check-in if the compile and test run fails. In Team Foundation Server, for example, this is called a gated build. Once you submit your code to the repository, the code is compiled on a build server and the tests are executed. If this process fails for any reason, the developer would not be able to check-in their code. This process helps to ensure your code base is in a continual working state, and of high quality. Developers should be integrating and committing code into the source code repository at least every few hours, or when they have written enough code to make their whole unit test pass. In any case, you should never hold onto changes for more than a day.
Continuous integration often avoids diverging or fragmented development methods, where developers are not communicating with each other about what can be reused or can be shared. Everyone needs to work with the latest version, and changes should not be made to obsolete code, which causes integration headaches. Each development pair is responsible for integrating their own code whenever a reasonable break presents itself.
A single machine dedicated to sequential releases works really well when the development team is co-located. Generally, this will be a build server that is controlled by checking commits from a source control repository like Team Foundation Server. This machine acts as a physical token to control releasing, and also serves as an objective last word on what the common build contains. The latest combined unit test suite can be run before releasing, when the code is integrated on the build machine, and because a single machine is used, the test suite is always up-to-date. If unit tests pass 100 percent, the changes are committed. If they fail for any reason, then the check-in is rejected, and the developers have to fix the problem.
Collective code ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs, or refactor. No one person becomes a bottleneck for changes. This can seem hard to understand at first, and it can feel inconceivable that an entire team can be responsible for systems design, but it really makes sense not to have developers partitioned their own particular silos. For starters, if you have developers who only own their part of the system, what happens if that developer decides to leave the company? You have a situation where you have to try and cram a transfer of a lot of knowledge into a short space of time, which in my experience never works out too well, as the developers taking over are not building up a good level of experience in the new area.
By spreading knowledge throughout the team, regularly swapping pairs, and encouraging developers to work on different parts of the system, you minimize risks associated with staff member unavailability.

Extreme Programming is a software development methodology that is intended to improve software quality and responsiveness to changing customer requirements. As a type of Agile software development, it advocates frequent releases and shorter development cycles, which are intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of XP include programming in pairs or doing extensive code reviews, unit testing all of the code and avoiding programming of features until they are actually needed. XP has a flat management structure with simplicity and clarity in code, and a general expectation that customer requirements will change as time passes. The problem domain will not be understood until a later point, and frequent communication with the customer will be required at all times.
Extreme Programming takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels. As an example, code reviews are considered a beneficial practice. Taken to the extreme, code can be reviewed continuously with the practice of pair programming.
XP was created by Kent Beck during his work at the struggling Chrysler Comprehensive Compensation System payroll project, or C3, as it was known. In 1996, Chrysler called in Kent Beck as an external consultant to help with its struggling C3 project. The project was designed to aggregate a number of disparate payroll systems into a single application.
Initially, Chrysler attempted to implement a solution, but it failed because of the complexity surrounding the rules and integration. From this point of crisis, Kent Beck and his team took over, effectively starting the project from scratch. The classic Waterfall development approach had failed, so something drastic was required. In Kent Beck’s own words, he just made the whole thing up in two weeks with a marker in his hand and a white board. Fundamentally, the C3 team focused on the business value the customer wanted, and discarded anything that did not work towards that goal. Extreme Programming was created by developers for developers.
34
The XP team at Chrysler was able to deliver its first working system within a year. In 1997, the first 10,000 employees were paid from the new C3 system. Development continued over the next year, with new functionality being added through smaller releases. Eventually, the project was cancelled because the prime contractor changed, and the focus of Chrysler shifted away from C3. When the dust settled, the eight-member development team had built a system with 2,000 classes and 30,000 methods. Refined and tested, XP was now ready for the wider development community.

There have been many attempts to try and improve software development practices over the years, and many of these have looked at working in a more iterative way. These new practices didn’t go far enough when trying to deal with changing requirements of customers.
In the 1990s, a group of industry software thought leaders met at a ski resort in Utah to try and define a better way of developing software. The term “Agile software development” emerged from this gathering. The term was first used in this manner and published in the now-famous
Agile Manifesto. The Agile Manifesto was designed to promote the ideas of delivering regular business value to your customers through the work of a collaborative, cross-functional team.

The Agile Manifesto Core Values

The Agile Manifesto is built upon four core values:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Individuals and interactions over processes and tools

Software systems are built by people, and they all need to work together and have good communications between all parties. This isn’t just about software developers, but includes QA, business analysts, project managers, business sponsors, senior leadership, and anyone else involved in the project at your organization. Processes and tools are important, but are irrelevant if the people working on the project can’t work together effectively and communicate well.

Working software over comprehensive documentation

Let’s face it—who reads hundred-page collections of product specs? I certainly don’t. Your business users would much prefer to have small pieces of functionality delivered quickly so they can then provide feedback. These pieces of functionality may even be enough to deployto production to gain benefit from them early. Not all documentation is bad, though. When myteams work on a project, they use Visio or a similar tools to produce diagrams of employment environments, database schemas, software layers, and use-case diagrams (and this is not an
exhaustive list). We normally print these out on an A3 printer and put them up on the wall so they are visible to everyone. Small, useful pieces of documentation like this are invaluable.

Hundred-page product specs are not. Nine times out of 10, large items of documentation are invalid and out-of-date before you even finish writing them. Remember, the primary goal is to develop software that gives the business benefit—not extensive documentation.

Customer collaboration over contract negotiation

All the software that you develop should be written with your customer’s involvement. To be successful at software development, you really need to work with them daily. This means inviting them to your stand-ups, demoing to them regularly, and inviting them to any design meetings. At the end of the day, only the customer can tell you what they really want. They may not be able to give you all the technical details, but that is what your team is there for: to
collaborate with your customers, understand their requirements, and to deliver on them.

Responding to change over following a plan

Your customer or business sponsor may change their minds about what is being built. This may be because you’ve given them new ideas from the software you delivered in a previous iteration. It may be because the company’s priorities have changed or new regulatory changes come into force. The key thing here is that you should embrace it. Yes, some code might get thrown away and some time may be lost, but if you’re working in short iterations, then the time lost is minimized. Change is a reality of software development, a reality that your software process must reflect. There’s nothing wrong with having a project plan; in fact, I’d be worried about any project that didn’t have one. However, a project plan must be flexible enough to be changed. There must be room to change it as your situation changes; otherwise, your plan quickly becomes irrelevant.

Agile is a group of software development processes that promote evolutionary design with selforganizing teams. Agile development inspires adaptive planning, evolutionary development, and early delivery of value to your customers.

The word “agile” was first associated with software development back in 2001 when the Agile Manifesto was written by a group of visionary software developers and leaders. You choose to become a signatory on the Agile Manifesto website, which stamps your intention to follow the principles.
Unlike traditional development practices like Waterfall, Agile methodologies such as Scrum and Extreme Programming are focused around self-organizing, cross-discipline teams that practice continuous planning and implementation to deliver value to their customers.

The main goal of Agile development is to frequently deliver working software that gives value. Each of these methods emphasize ongoing alignment between technology and the business. Agile methodologies are considered lightweight in that they strive to impose a minimum process and overhead within the development lifecycle.

Agile methodologies are adaptive, which means they embrace and manage changes in requirements and business priorities throughout the entire development process. These changes in requirements are to be expected and welcomed. With any Agile development project, there is also a considerable emphasis on empowering teams with collaborative decision-making. In the previous chapter, I talked about how the Waterfall-based development process follows a set series of stages, which results in a “big bang” deployment of software at the end of the process.

One of the key ideas behind Agile is that instead of delivering a “big bang” at the end of the project, you deliver multiple releases of working code to your business stakeholders. This allows you to prioritize features that will deliver the most value to the business sooner, so that your organization can start to realize an early return on your investment. The number of deliveries depends on how long and complex a project is, but ideally you would deliver working software at the end of each sprint or iteration.

      Agile versus Waterfall

Another good way to visualize the premise of Agile is with the above diagram . What this diagram shows is that with Agile, you deliver incrementally instead of all at once.

We’ll take a look at a number of pros and cons of the Waterfall model. But before we do, I first want to cover some of the main high-level advantages and disadvantages to this development process.
The first advantage is that by splitting your project deliveries into different stages, it is easier to maintain control over the development process. This makes it much easier for schedules to be planned out in advance, making the project manager’s life much easier. It’s for this reason I’ve found that experienced project managers tend to favor the Waterfall process. By splitting a project down into the various phases of the Waterfall process, you can easily
departmentalize the delivery of your project, meaning that you can assign different roles to different departments and give them a clear list of deliverables and time scales. If any of these departments can’t deliver on time for various reasons, it’s easier for a project manager to adjust the overall plan.

Unfortunately, in reality I’ve seen a plan adjusted where the implementation phase gets squeezed more and more, which means the development team has less time to deliver a working solution. Shortcuts tend to be taken, and the quality can suffer as a result. It’s normally code-base unit integration testing that gets affected first. The testing teams in the test phase get a solution that contains more problems, which makes their lives very hard. So while
departmentalization is seen as an advantage, it can easily become a disadvantage if another team is late delivering their part of the project.

Now, let’s take a look at some of the high-level disadvantages. The Waterfall model doesn’t allow any time for reflection or revision to a design. Once the requirements are signed off on, they’re not supposed to change. This should mean that the development team has a fixed design that they’re going to work towards. In reality, this does not happen, and changes in requirements can often result in chaos as the design documents need updating and re-signing off on by stakeholders.

By the time the development team starts its work, team members are pretty much expected to get it right the first time, and they’re not allowed much time to pause for flaws and reflection on the code that they have implemented. By the time you get to the point where you think a change of technical direction is required, it’s normally too late to do anything about it unless you want to affect the delivery dates. This can be quite de-motivating for a development team, as they have to proceed with technical implementations that are full of compromises and technical
debts. Once a product has entered the testing stage, change is virtually impossible—whether to the overall design or the actual implementation.

Now we’ve seen some of the high-level advantages and disadvantages. Let’s take a deeper look at more of the benefits of the Waterfall model. Waterfall is a simple process to understand, and on paper it looks like a good idea for running a project. Waterfall is also easier to manage for a project manager, as everything is delivered in stages that can be scheduled and planned in advance. Phases are completed one at a time, where the output from one phase is fed into the input of the next phase. Waterfall generally works well for smaller projects where the risk of changing requirements and scope is lower. Each stage in Waterfall is very clearly defined. This makes it easier to assign clear roles to teams and departments who have to feed into the project. Because each stage is clearly defined, it makes a milestone set up by the project manager easier to understand. If you’re working on a stage like Requirements

Analysis, you should clearly understand what you need to deliver to the next phase, and by when.
Under Waterfall, the process and results of each stage are well documented. Each stage has clear deliverables that are documented and approved by key project stakeholders. And finally, tasks in a Waterfall project are easy to arrange and plan for a project manager. The Waterfall model fits very neatly into a Gantt chart, so a project manager is generally happiest when they can plan everything out and view a project timeline in an application like Microsoft Project.

The biggest disadvantage of the Waterfall model is you don’t get any working software until late in the process. This means that your end users don’t get to see their vision come to life until it’s too late to change anything. It can be very hard for non-technical people to be really clear about how they want an application to operate, and it isn’t normally until they can visualize an application that they can really give good feedback. You can mitigate this a bit by doing some prototyping in the system design phase to help users visualize their system, but there is nothing like giving them actual working code to try out.

The Waterfall model can introduce a high level of risk and uncertainty for anything but a small project. Just because a set of requirements and a design has been approved does not mean that the requirements won’t change. Waterfall is all about getting the requirements, design, and implementation right the first time. This is a grand idea, but in the real world it is very rarely the case, and this is a big risk to a project. We have talked about how Waterfall is better for small projects, but it is possible to have a small, but very complex project. The more complexity that is involved, the more likely it is that change will be needed further down the line. Complexity in the system is also very hard to implement and test, and can often cause delays in the later stages of the Waterfall software development lifecycle.
If you’re working on a project where change is expected, then Waterfall is not the right model for you. I’ve worked on projects for a financial services company where changes in the law were causing compliance regulations to change.

Unfortunately, these rules are very open to interpretation, which meant the legal team was involved at a very early stage. This meant that the interpretation changed a few times during the course of the project. If this had been a
Waterfall project, we would have been in big trouble, as projects normally come with very hard
and fixed set of deadlines.

This project was a perfect fit for an Agile project. If you are working on a large project and the scope changes, the impact can be so expensive and costly that the original business benefit for the project can evaporate, and then the project is cancelled. I’ve seen this happen a couple of times, and it’s a real shame, as projects that show promise are stopped due to restrictions in the process.

Finally, the integration and delivery of a project is done as a “big bang” on a Waterfall project. This means you’re introducing huge amounts of change all at once. This can very easily overwhelm testing teams and your operational teams.

Brief History of Waterfall software development process

The Waterfall software development process was introduced by computer scientist Winston Royce in 1970. Royce first wrote about Waterfall in an article called, Managing the Development of Large Software Systems. Although Royce didn’t directly refer to his model as Waterfall, the article was actually about a process that was flawed for software development. Royce’s model allowed for more repetition between stages of the model, which Waterfall doesn’t allow you to do.
Royce’s actual model was more iterative in how it worked and allowed more room to maneuver between stages. We will discuss a more iterative way of working when we discuss Agile later on in the blog. Although Royce didn’t refer to his model as the Waterfall model directly, he is credited with the first description of what we refer to as the Waterfall model.
Royce’s original article consists of the following stages, which we’ll go into more detail on in a moment. Those stages are:
 Requirements Specification
 Detail Design
 Construction, where developers start crafting code
 Integration, where all the code is brought together and compiled into a run-able solution
 Testing and Debugging, where your testing will try to find defects that the developers
will fix
 Installation, where you deploy your system so that it can be used by your end users.
 Maintenance, where you fix any issues that are raised by the users.

How waterfall Process Works

The Waterfall process is split into separate stages, where the outcome of one stage is the input for the next stage. In the first stage, Requirements Specification, all possible requirements for the system to be developed are captured and documented in a requirement specification document. This document normally requires sign-off by key project and business stakeholders.
This part of the Waterfall model is typically organized by the business analysts, but depending on the size of your project, team, or organization, other members of your development team may be involved. This stage is about teasing out the requirements of the system from your stakeholders. This would include the required functionality, documentation of business rules and processes, and capturing any regulatory and compliance requirements that will affect the overall system

The next stage is System Design. The requirement specifications from the first stage are inspected, and the system design is put together. This design helps in specifying the system design requirements, and also helps with designing the overall system’s architecture. It is this stage where architects, solution designers, and developers will work together to decide how the overall system will be constructed. This is from a code perspective, and also a technology
choice and infrastructure perspective.

The next phase is Implementation. This is the phase where the developers take the design and start producing code to turn the design into a reality. The developers may also write automated unit and integration tests at this stage.
After the Implementation phase, we have the Integration and Testing phase. This is where all the deliverables from the implementation phase are brought together and tested as a whole.
The testing team should be working to a defined test plan. Once the system has been tested and signed off by the test team, the next stage is deploying the solution to your end users. Your end users may be internal customers within your organization, or customers.

Once the solution has been deployed, it goes into the Maintenance phase, where any issues that are reported will need fixing and re-deploying. This would generally be in the form of release patch fixes to your system. You may also perform small enhancements to the system at this phase. If an enhancement is quite large in scope, then you might start the Waterfall process again and start capturing further requirements.
All of these phases are cascaded, where progress is seen as flowing steadily downwards like a waterfall. The next phase is started only after a pre-defined set of goals are achieved from the previous phase. In this model, the phases do not overlap.

Though the term statistical learning is fairly new, many of the concepts that underlie the field were developed long ago. At the beginning of the nineteenth century, Legendre and Gauss published papers on the method
of least squares, which implemented the earliest form of what is now known as linear regression. The approach was first successfully applied to problems in astronomy.

Linear regression is used for predicting quantitative values, such as an individual’s salary. In order to predict qualitative values, such as whether a patient survives or dies, or whether the stock market increases
or decreases, Fisher proposed linear discriminant analysis in 1936. In the 1940s, various authors put forth an alternative approach, logistic regression.

In the early 1970s, Nelder and Wedderburn coined the term generalized linear models for an entire class of statistical learning methods that include both linear and logistic regression as special cases.
By the end of the 1970s, many more techniques for learning from data were available. However, they were almost exclusively linear methods, because fitting non-linear relationships was computationally infeasible at the
time. By the 1980s, computing technology had finally improved sufficiently that non-linear methods were no longer computationally prohibitive. In mid 1980s Breiman, Friedman, Olshen and Stone introduced classification and
regression trees, and were among the first to demonstrate the power of a detailed practical implementation of a method, including cross-validation for model selection. Hastie and Tibshirani coined the term generalized additive
models in 1986 for a class of non-linear extensions to generalized linear models, and also provided a practical software implementation.
Since that time, inspired by the advent of machine learning and other disciplines, statistical learning has emerged as a new subfield in statistics, focused on supervised and unsupervised modeling and prediction. In recent
years, progress in statistical learning has been marked by the increasing availability of powerful and relatively user-friendly software, such as the popular and freely available R system. This has the potential to continue
the transformation of the field from a set of techniques used and developed by statisticians and computer scientists to an essential toolkit for a much broader community