CRC DATA Technologies

CRC DATA - using Scrum Methodology

Mon, 04 Aug 2014 05:03:15 GMT

For many developers in the software industry, the agile methodology is nothing new. Most folks know that agile was a direct response to the dominant project management paradigm, waterfall, and borrows many principles from lean manufacturing. In 2001, as this new management paradigm began to pick up momentum, agile was formalized when 17 pioneers of the agile methodology met at the Snowbird Ski Resort in Utah and issued the Agile Manifesto. Their manifesto is now considered the foundational text for agile practices and principles. Most importantly, the manifesto spelled out the philosophy behind agile, which places a new emphasis on communication and collaboration; functioning software; and the flexibility to adapt to emerging business realities.

But for all of the strides the Agile Manifesto made in revising a philosophical approach to software development, it didn’t provide the concrete processes that development teams depend on when deadlines — and stakeholders — start applying pressure. As a result, when it comes to the nuts and bolts of running a team with agile every day, organizations turn to particular subsets of the agile methodology. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. At my organization, we use Scrum and I’ve found it to be an incredibly effective management methodology for everyone involved, including developers and stakeholders. If you’re interested in learning about the other agile methodologies, there are plenty of resources out there. This blog is designed to provide some essential background for those who are new to Scrum.

What’s Unique about Scrum?

Scrum emphasizes the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.

This emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers. But what allows Scrum to work is a simple set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.

The Roles of Scrum

Scrum has three roles: Product Owner, ScrumMaster, and team member.

The Example ScrumMaster’s Checklist

Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. The Product Owner is the single individual who must face the music when a project goes awry.

The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

ScrumMaster: The ScrumMaster acts as a facilitator for the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.

Learn More

Online Scrum Master training is available in the Scrum Training Series, a free collection of entertaining e-learning modules covering an Introduction to Scrum, the Backlog Grooming Meeting, the Sprint Planning Meeting, the Daily Scrum Meeting, the Sprint Review Meeting, and the Sprint Retrospective Meeting. You can download the 6-page Scrum Reference Card or learn what the Scrum Master does. In person Certified Scrum Master training, typically using group immersion activities and case studies, is also available all over the world.

Software Development Life Cycle AGILE vs Traditional Approaches

Mon, 04 Aug 2014 03:38:37 GMT

Software Development Life Cycle AGILE vs Traditional Approaches

2012 International Conference on Information and Network Technology (ICINT 2012)

IPCSIT vol. 37 (2012) © (2012) IACSIT Press, Singapore

Abstract. Software development life cycle is the most important element in software development. It

depicts the necessary phases in software development. This paper reviews the modern SDLC which are

traditional methods and agile methods and explains the advantages and disadvantages of both methodologies.

It also suggests improvements for current agile development so that this lightweight SDLC could be adopted

more in practice for organizational project management.

Keywords: SDLC, agile, traditional methods, ROI.

1. Introduction

Software Development Life Cycle (SDLC) is a process of building or maintaining software systems[7].

Typically, it includes various phases from preliminary development analysis to post-development software

testing and evaluation. It also consists of the models and methodologies that development teams use to

develop the software systems, which the methodologies form the framework for planning and controlling the

entire development process.

A software application or an information system is designed to perform a particular set of tasks. Often,

this set of tasks that the system will perform provides well-defined results, which involve complex

computation and processing. It is therefore a harsh and tedious job to govern the entire development process

to ensure that the end-product comprises of high degree of integrity and robustness, as well as user

acceptance. Thus, a systematic development process which is able to emphasize on the understanding of the

scope and complexity of the total development process is essential to achieve the said ¬characteristics of a

successful system.

Currently, there are two SDLC methodologies which are utilized by most system developers, namely the

traditional development and agile development which explained in next session. In section 4 we compare and

contrast these two methodologies in detail and suggested some improvements in following section. Finally,

the conclusion is presented.

2. Traditional Software Development

Software methodologies like Waterfall method, V-Model and RUP are called traditional software

development methodologies and these are classified into the heavyweight methodologies [1]. These

methodologies are based on a sequential series of steps like requirements definition, solution building,

testing and deployment. Traditional software development methodologies require defining and documenting

a stable set of requirements at the beginning of a project.

There are four phases which are characteristic of traditional software development method. The first step

is to set up the requirements for the project and determine the length of time it will take to implement the

various phases of development while trying to predict any problems that may arise in the project. Once the

requirements are laid out, the next step moves into the design and architectural planning phase where a

technical infrastructure is produced in the form of diagrams or models. These bring to the surface potential

issues that the project may face as it progresses and provide a workable road map for the developers to

implement.

Once the team is satisfied with the architectural and design plan, the project moves into the development

phase where code is produced until the specific goals are reached. Development is often broken down into

smaller tasks that are distributed among various teams based on skill. The testing phase often overlaps with

the development phase to ensure issues are addressed early on. Once the project nears completion and the

developers are close to meeting the project requirements, the customer will become part of the testing and

feedback cycle and the project was delivered after the customer satisfy with it.

The traditional software development methods are dependent on a set of predetermined processes and

on-going documentation which is written as the work progresses and guides further development [1]. The

success of a project which is approached in this way relies on knowing all of the requirements before

development begin and means that implementing change during the development lifecycle can be somewhat

problematic. However, it also makes it easier to determine the costs of the project, set a schedule and allocate

resources accordingly [2].

3. AGILE Software Development

Agile development is based on the idea of incremental and iterative development, in which the phases

within a development life cycle are revisited over and over again. It iteratively improves software by using

customer feedback to converge on solutions[5].

In agile development, rather than a single large process model that implemented in conventional SDLC,

the development life cycle is divided into smaller parts, called “increments” or “iterations”, in which each of

these increments touches on each of the conventional phases of development. According to Agile Manifesto,

the major factors of agile factors include the following four:

1. Early customer involvement

2. Iterative development

3. Self-organizing teams

4. Adaptation to change

There are currently six methods that are identified as agile development methods, which are Crystal

methodologies, dynamic software development method, feature-driven development, lean software

development, scrum, and extreme programming[8].

4. Discussion

One major difference between agile development and conventional development methods is that the

former methodology possesses the ability to successfully deliver result quickly and inexpensively on

complex projects with ill-defined requirements. Agile methods emphasize on teams, working software,

customer collaboration, and responding to change; while the conventional methods stress on contracts, plans,

processes, documents, and tools.

Agile development methods take business Return of Investment (ROI) as its utmost priority[11]. In

traditional development life cycle, the development teams usually hold a meeting with the stakeholders and

obtain every detailed requirement during early phases of development process. Then the development teams

would start the design phase, followed by the actual coding phase. The testing phase will only start when the

entire coding process is completed. Then only will the end-product be presented to stakeholders after there is

no issue arises in the testing phase. The shortcoming of this traditional methodology is that the development

teams build the system in “one-shot” fashion. Assume that an issue arises during the testing phase, the worst

case scenario would be the entire module would have to be reverted to rectify the issue. Another problem

with the traditional SDLC is that in most cases, stakeholders will not know what they really want to

implement in the system, therefore the requirement model engineered at the earlier phases might not

necessarily be the actual features that need to be implemented. Users’ or stakeholders’ change requests might

flow in after the end-product is presented and released on the market. This would further speed up the

deterioration of the software as multiple change requests from different parties that implemented into the

system would cause various compatibility and software integrity issues. These problems are even more

apparent in larger system. Hence, from a business perspective, the traditional SDLC is not an adequately

efficient methodology.

In contrast to traditional SDLC, the Agile SDLC avoids ‘up-front’ requirement gathering as stakeholders

often could not provide all requirements in sufficient details for implementation to occur at the beginning of

a project[13]. It is a common phenomenon that customers could not decide the features to be included in the

system. Therefore, the frequent demonstration and release of software in common agile practices allow

customers to acquire sufficient details on the current release of the system upon actual interaction with

system and thus providing feedback to refine the requirements provided earlier before the current release.

The iterative approach in agile practices also allows customers to delay decisions, where decisions may be

delayed to some future iteration when better information or technology is available to optimize the choice. It

is also the one of the advantages that agile SDLC triumphs traditional SDLC by the fact that in agile SDLC,

development can begin even before all the requirements are known.

Taking the fact that customers’ requirements are acquired iteratively as context, agile development is

able to deliver an end-product that better meets customer needs. For every short run of iteration, completed

modules are presented to customers for review. These modules are by no means integrated as a full system

and thus any rework or additional features would not marginally increase the development cost. Taking this

advantage developers are always ready to include any features that customer desire, and the system

integration will only occur when customers have no further additional requirements. Apparently, this

approach could greatly satisfy customers with a complete system containing all desired functions.

It is also highly possible for stakeholders to maximize their business return on investment by practicing

agile methods in system development. The direction of the development is always readily changeable and the

cost of change is low, as the stakeholders are given the opportunity to revise the business factors at the

beginning of each iteration to include additional features into the system according to business ROI[11].

However, it is also the responsibilities of the development team to inform the stakeholders of the technical

risk of the change. This attribute of agile methodology is known as modular and lean which allows mobility

of particular features or components in the system or process depending on specific needs of stakeholders.

Although Agile methodologies triumph traditional methodologies in many aspects, there exist several

difficulties in putting it into practice. One among these is that agile methods significantly reduce the amount

of documentation, and even claim that the code itself should act as a document[14]. This causes developers

who are accustomed to agile methods have a tendency to place more comments in the code as explanation

and clarification. However, it is difficult for novice developers or new team members to complete tasks when

they could not adequately comprehend the project. They thus pose numerous questions for the experienced

developers and this could cause the delivery of iteration to be delayed, which in turn may cause an increase

in development cost. Traditional methods on the other hand, stress on the importance of documentation in

providing guidelines and clarification on the project for development team, thus has no relevant concern of

developers not being knowledgeable of the project detail or the availability of a knowledgeable developer.

Agile methodologies are well-known for emphasizing in communication and customer involvement[9].

For every deliverable iteration, the development team and customers will hold a meeting, where the team

members will communicate and summarize their work done in this iteration; whereas customers will provide

feedback on the delivered software to refine current features or include additional features in the system.

Most of the time, developers will find the regular meetings, mostly on weekly basis, are tedious and tiring as

they would have to present to other members and customers of their responsible modules repeatedly, and

upon each iteration, various changes to the modules will most likely to happen due to change in requirements.

Furthermore, the time frame allocated for each iteration is typically short, which usually in the range of

weeks. Developers would often find that the schedule is tight for them to develop each of the modules, this is

even more so if the particular module involves complicated processing algorithms. This draws the delivery

of each iteration behind the schedule and thus an efficient communication between the team members and

with the customers could not be established. On the other hand, traditional methodologies have a well defined

requirement model before the implementation and coding process starts, in which this model would

act as a reference for development team during the coding process. Customers are not likely to participate in

this phase of development life cycle, while development team will do the coding according to the

documentation provided by business analysts until the entire system is completed and integrated, then only

will the integrated system be presented to customers as end-product. In this case, developers will not have to

concern about the frequent iteration meetings and could be allowed a wider time frame to complete the

system, thus allowing them to provide a better result.

As mentioned previously, agile development focuses on communication and customer involvement, in

which by this premise it implies that interpersonal and social skills are crucial for the entire development

team so that during each iteration, the completed modules can be efficiently delivered to customers and

enlighten them of the current progress of the development and, if there is any, issues that developers

encountered during implementation and coding phase. It is also important for the development team to be

fully understand about the requirements and changes proposed by customers, where this ultimately require

effective communication skills. It is however, not every developer would possess good social skills.

Whenever a developer within the team has poor social skill, relevant parties will have difficulties obtaining

information on the particular module progress, where this in turn causes customers to be unable to provide

accurate requirement for subsequent iteration. While developers could not understand what exactly is

required by customers, it is very likely that the completed module contains unwanted features. Thus this

further increases the cost of development by reworking the module, and the increased reliance on social

skills of developers would increases the instability of the development process.

The fact that agile development open to incremental requirement changes has gave rise to two

dependency issues in design, which are namely rigidity and mobility. Rigidity refers to a change in the

system implies a cascade of changes in other modules; while mobility refers to inability of the system to

encapsulate components that can be reused, because it implies too much effort or risk. If these issues are all

over the system, high-level restructuring is required to remove unwanted dependencies[15]. One immediate

consequence of these dependency issues is the violation of the Interface Segregation Principle [16],

explaining most of the difficulties in the deployment stage. Table 1 depicts the differences of AGILE and

traditional approaches in several aspects.

Table. 1: Comparison of Agile and Traditional Approaches

5. Improvement

Agile software development methods were developed to provide more customer satisfaction, to shorten

the development life cycle, to reduce bug rates, and to accommodate changing business requirement during

the development process[13]. It is a very useful methodology to be adopted in the modern software

development process to replace the traditional heavyweight development life cycle. However, it is still not

perfected yet and faces several barriers in putting it into practices.

AGILE TRADITIONAL

User requirement Iterative acquisition Detailed user requirements are well defined before coding/implementation

Rework cost low high

Development direction Readily changeable Fixed

Testing On every iteration After coding phase completed

Customer involvement high low

Extra quality required for developers

Interpersonal skills & basic business knowledge

Nothing in particular

Suitable Project scale low to medium-scaled Large-scaled

From previous discussion it is revealed that agile methods promote communication over documentation,

and this attribute of agile development reduces comprehension of the system. There is no guarantee that the

code can serve as documentation if the system was originally developed using different methods. Therefore

it is crucial to make the system comprehensive in order to improve its feasibility. This could be done by

introducing automated code inspection, where source codes are checked for compliance with a predefined set

of rules or best practices, by means of software tools. With this, code defects could be detected before the

testing process begins, thus saving time and cost. It also provides complete code coverage and is able to

identify defects that testing process might have missed, as well as the root cause of the defect. In addition,

refactoring to untangle crosscutting concerns will also improve the comprehensibility as they help to

distinguish code for various business segments and separate business and platform code. In order to improve

the modifiability and deploy ability of the system, developers should always do an analysis of the module

dependencies and specific refactoring to further improve these two interfaces.

Another important parameter in promoting the agile development in practice is the social skills of

developers. Developers who engaged in an agile project development should have good social and

interpersonal skills instill in them. This could be achieved by either training provided by company, or

developers themselves should be well-aware of the importance of this quality and always be motivated to

polish their interpersonal skills, by means of frequent communication and socialization with people around.

By communicating more with different people, one can grasp the technique to express themselves more

effectively and in better understanding what are other people trying to express.

Developers should as well equipped with basic business knowledge in order to speak with customers on

equal basis. A team without business knowledge most likely will not able to deliver the product which is

valuable to customers, thus causing customers to lose faith in the development team. Hence, it is important

for developers not only excel in computer science knowledge, but also have basic understanding in business

rules. This can be done by short training provided by company or by inviting domain expert to lift team

members’ knowledge to an upper level of understanding.

A few points should also be noted for developers to practice agile development. First of all, they should

make incremental change to the requirement, project plan system, and the resulting artifacts to enable agility.

They should also strive for feedback to ensure the project meets the needs of all participants and stakeholders.

In addition, only those tasks that add value to business processes supported by the system should be

performed and lastly, processes and artifacts that do not add enduring value to the working software system

should be discarded.[12]

6. Conclusion

Software Development Life Cycle is a methodology that depicts the entire development process, in

which a software development organization ought to utilize to ensure a successful software development.

While modern SDLC are divided into two main categories, which are traditional SDLC and agile SDLC.

As discussed earlier, agile SDLC excels traditional SDLC. However, agile SDLC also has its

disadvantages. While agile SDLC is more suitable for small-medium project development, it is still better to

adopt traditional SDLC for large-scale project. Therefore, it is important that development team select a

SDLC that best suits the project.

There are some criteria that development teams could use to identify the desired SDLC, these include the size of

team, geographical situation, size and complexity of software, type of project, business strategy, engineering

capability, and others where it may be found appropriate. It is also crucial for the team to study the

differences, advantages, and disadvantages of each SDLC before hammer down the decision. In addition, the

team must study the business context, industry requirements, and business strategy to be able to assess the

candidate SDLC against the selection criteria.

A SDLC selection and adoption process is crucial that it ensures the organization to maximize their

chance to deliver their software successfully, therefore selecting and adopting the right SDLC is a

management decision with long term implications.

7. References

[1] Nikiforova, O., Nikulsins, V., Sukovskis, U.: Integration of MDA Framework into the Model of Traditional

Software Development. In: Frontiers in Artificial Intelligence and Applications, Databases and Information Systems

V, vol. 187, pp. 229–239. IOS Press, Amsterdam (2009)

[2] IBM: Rational Unified Process: Best practices for software development teams (2003),

http://www.ibm.com/developerworks/rational/library/253.html

[3] Fowler M. The New Methodology, 2005

[5] Szalvay, Victor. An Introduction to Agile Software Development. Danube Technologies Inc. 2004.

[6] Cohen, S. A Software System Development Life Cycle Model for Improved Stakeholders’ Communication and

Collaboration. Int. J. of Computers, Communications & Control. Vol. V, No. 1, pp. 20-4. 2010.

[7] Systems Development Lifecycle: Objectives and Requirements. Bender RPT Inc. 2003.

[8] Dyba, Tore. Empirical studies of agile software development: A systematic review. 24 January 2008.

[9] Peterson, Kai. A Comparison of Issues and Advantages in Agile and Incremental Development between State of the

Art and an Industrial Case. Journal of System and Software. 2009.

[10] Abrahamsson, Pekka. Agile Software Development Methods: Review and Analysis. Julkaisua-Utgivare-Publisher.

2002.

[11] Rico, David F. What is the ROI of agile vs. traditional Methods. 2008.

[12] Carayannis, E.G. Agile Project Management for IT Project. Greenwood Press / Quorum Books. 2002

[13] Cho, Juyun. Issues and Challenges of agile software development with SCRUM. Issues in Information System.

VOL IX, No. 2. 2008.

[14] Vijayasarathy, Leo R. Agile Software Development: A survey of early adopters. Journal of Information Technology

Management Volume XIX, Number 2. 2008.

[15] Henssen, Geir K. Maintenance and Agile Development: Challenges, Opportunities and Future Directions. 2009.

[16] Martin, R.C., Agile Software Development, Principles, Patterns and Practice. Prentice Hall. 2002.

CRC DATA - Business Intelligence and Analytics

Tue, 17 Jun 2014 19:31:00 GMT

Business Intelligence and Analytics

Changing data into useful information.

All Companies from small to Large Enterprises generate stored data. Data alone cannot provide answers to the most important questions like:

product costs from manufacture to market sales
CRC DATA will convert your raw data into business information. We have the expertise and experience in implementing Business Intelligence and Analytics solutions that will help you fully utilize your Enterprise data. Our Business Intelligence and Analytics capabilities include:

Enhanced Reporting
Superior Query and Analysis
KPI Dashboards
Performance Scorecards
Business Performance Management tools
Advanced Statistical analysis
Expertise in multiple BI and BA tools

While CRC DATA provides your company with our Technical Expertise for your BI and BA needs; CRC DATA will also give you access to our Frameworks and Toolkits that we have developed over the last 25 years.

CRC DATA - MVC (Model View Controller)

Mon, 02 Jun 2014 01:48:57 GMT

Jan 7 2012 7:20 PM

What is MVC (Model View Controller)

Before taking you into the programming side of asp.net MVC let’s first make you understand what MVC is. Is MVC something that was developed as a part of .net programming by Microsoft, or was it developed as a part of Java programming by Sun. We need to get and handle on MVC in general, what it is and what is its importance.

MVC – An architectural pattern

MVC stands for Model View Controller. Is it a programming technique ? or is it a framework work ? Neither is it a programming technique and nor is it a framework. Then what is it ?

Many put MVC under the design pattern category. But it’s not a design pattern, rather its an architectural pattern. Let’s first understand the difference between a design pattern and an architectural pattern:

Design pattern – According to Wikipedia “a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.”

Architectural pattern – According to Wikipedia “Architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering. It gives description of the elements and relation type together with a set of constraints on how they may be used. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale. ”

Now that we are clear with what a design pattern is and what an architectural pattern is, let’s try and understand why MVC is an architectural pattern and not a design pattern. We use MVC for shaping complete applications and not small parts of an application. It’s an end to end solution for the whole application. It helps you design an application in a way that we can separate the Data, Logic and Presentation in a clean manner. Thus we put MVC under the architectural pattern category. Now that we understand that MVC is an architectural pattern, we need to understand how we use it.

MVC is not something that is particular to asp.net. Any language with enough ability to support advanced level of programming can be used to implement MVC pattern and code an application. Thus you can have MVC pattern implemented using PHP, JAVA or any other present day language. Now let’s understand what MVC and how does it help us in designing an application. Below is an pictorial representation of the MVC pattern:

In the figure above we can clearly see a Model , View and a Controller. Lets now define all these three and understand their role in an application.

Model:
A model is responsible for holding the data on which the application works. It may be raw data that is being fetched from a database or processed data. Any operations of the data that are being performed by the application are done by a Model.

View:
This is the presentation layer. This is the layer which is presented to the user for interaction. There can be multiple views for a given Model. The major responsibility of the View is to present the data to the user. No data base operations or data manipulation operation should be carried on inside the View.

Controller:
This is the glue layer between a Model and a View. A controller is responsible for receiving the input from the user when he / she interacts with the view and initiating the response cycle for the input.

The asp.net MVC 4.0 framework that we installed on our host provides us with required classes for creating the Models, Views and Controllers. We do not have to write the MVC framework of our own. All that we have to do is to use this MVC framework provided by asp.net and create our own applications. In fact Orchard provides a Comand Line Code-Generator which builds a complete Module or Theme structure simply by giving it a new name...

Engines:
In 2010 MSN introduced a new View Engine called Razor within it's release of ASP.NET MVC 3 Framework and the Web Forms view engine. Both view engines are part of the MVC 3 framework. By default, the view engine in the MVC framework uses Razor .cshtml and .vbhtml, Web Forms .aspx pages to design the layout of the user interface pages onto which the data is composed.

Razor is an ASP.NET programming syntax used to create dynamic web pages with the C# or Visual Basic .NET programming languages. Razor was in development in June 2010^[1] and was released for Microsoft Visual Studio 2010 in January 2011.^[2] Razor is a simple-syntax view engine and was released as part of ASP.NET MVC 3 and the Microsoft WebMatrix tool set.

CRC DATA - Summary of Qualifications

Mon, 02 Jun 2014 01:46:17 GMT

Sep 15 2011 7:58 PM

SUMMARY OF QUALIFICATIONS

Expert experience in accomplishing new research and development projects utilizing multi-tier client-server technologies
Over twenty years proven track record in lead developmental and programming positions within the Healthcare Industry
Expert experience in database administration, setup, maintenance, backups and tuning with MSSQL 2000-2008 and mySQL
Expert working knowledge of SQL Server Management Studio, Visual Studio, Reporting Services, and SDLC data modeling
Expert design, programming, testing, and documentation for converting Classic ASP applications into ASP.net MVC applications

CRC DATA - Programming experience

Mon, 02 Jun 2014 01:42:00 GMT

Sep 15 2011 7:57 PM

Programming experience include:

Project Analysis, research, design, scheduling, documentation, programming, testing, and implementation, and the maintenance of full scale 2-3 Tier Client/Server Applications and company legacy systems.

Recent website conversions from Classic ASP into ASP.NET using Webmatrix, Visual Studio, Orchard CMS, Visual Basic and C# (CSharp) programming models with Silverlight 4.0, WCF RIA, and WCP.

Administrator design, setup, programming, and maintenance of hosted web services including IIS, users, files, permissions, ftp, data connections, system internals, dashboards, XML portals, asp, .net, frameworks, and the install and setup of various third party software products.

Database programming implementations using ODBC, TCP/IP connections with SQL databases, and Object Oriented GUI front-ends or middle-tier within COM, DCOM, and ActiveX.

Administrator set-up, testing, and maintenance of operating systems including WIN/NT/XP and Business 2005-2008 servers, UNIX/LINUX/APPACHE servers, company wide networks, work stations, MS-SQL 2005-2008, and mySQL databases.

Programming skills with Perl.5, C, C++, C#, embedded SQL, ASSMB, Inprise Delphi 4.0 by Borland, PowerBuilder 4.0, Visual Basic 6, MS Access, Informix 7.0 Forms, Fourgen, Oracle 8.0 Forms and Report Writer, Crystal Reports.

Other hands on skills including MS-SQL, mySQL, ASP, ADO, COM, RPC, DCOM, CORBA, ODBC, ADODB, CDO, CDONTS, TCP/IP and internet protocols SMTP, MIME, POP3, FTP, SNMP, and XML (DTD, WAP, WMLScript, RSS, SOAP, WSDL, SMS), XHTML (AJAX, DOM, JavaScript, VBScript, CSS), Visual Studio, Flash, PCAnywhere, ultraVNC, and Remote Desktop.

CRC DATA - Database Technologies

Mon, 02 Jun 2014 01:40:19 GMT

Sep 15 2011 7:54 PM

Database experience include: SQL Server, mySQL, Oracle, Informix

The Setup, Design, and Administration of Internals, System Tuning, Data Conversion, Backup Strategies, and Web Page connectivity solutions.

SQL design, programming, and the implementation of 2-3 tier business rules and procedures within the database using the SQL stored procedures, functions, triggers, constraints, indexes, views.

Setup and maintenance of MS Reporting Services, data clustering, data transformation, job scheduling, data conversion, transactional updates, and several data verification methods including records hashing and data encryption.

Design and programming with Visual Studio, Visual Web Developer, Web Forms 4.5, Webmatrix, ASP.NET, Frameworks 4.0, Linc, Forms, Report Writer, Crystal Reports, other reporting services