Guardware Systems Ltd. was founded in 1999 by an international group of investors. By retaining the technological achievements and innovations from former Hungarian development firms, a new biometric company with six years of experience was born. Today, Guardware boasts a young and flexible organization with more than a decade of expertise in the field of web security and a track record of satisfied customers worldwide.
Guardware creates exceptional customer value through secure, flexible and reliable biometric access management systems, in the form of off-the-shelf as well as customized products and solutions. We are focusing on high-end markets of personal authentication requiring maximum security. Guardware is committed to developing industry-leading technology and products in order to provide customers with security solutions of superior integrity and reliability, above and beyond their expectations.
Software designers and programmers will often describe a project in terms of particular tools. “This is a Visual Basic project,” or “We want to be on the cutting edge, so we are using Java.” Business Analysts and Project Managers often describe their approach entirely in terms of a “brand-name” methodology. “This is a Booch project,” or “We debated using the Rational Unified Process, but we decided to go with Extreme Programming’s (XP) approach all the way.”
What these developers are forgetting is that they have an underlying set of assumptions and ways of doing things that dictates how they implement a technology or method. These underlying principles can be called “Best Practices.” Most organizations have a set of Best Practices but they are rarely articulated (conversely, most organizations also have an unspoken set of Worst Practices)
The term “best practices” is roughly equivalent to the collection of guidelines and advice that a seasoned professional would give a novice about how to develop good, reliable software. Anthropologists writing an ethnography would discover Best Practices by visiting a software development team in its natural environment: observing behavior, documenting practices, and identifying which practices have been observed to produce good results (e.g., higher levels of quality).
Best practices are continually evolving as business needs change and as technology changes. The approaches that worked well for mainframe applications may well be the worst possible approach for today’s GUI-oriented, client-server projects. Best practices are concerned with invention and creation rather then being edicts set in stone.
Within the software industry there are differing opinions on what constitutes best practice. ArchWing has chosen to adopt the Best Practices published by the Rational Corporation ™ because of the extensive research Rational has done in the area.
The Rational Corporation sets forth the following six practices as those needed to predictably and effectively build reliable software:
1. Develop Software Iteratively
1) Define the entire problem
2) Design the entire solution
3) Build all the software needed
4) Testing the product at the end
2. Manage Requirements
How to elicit, organize, and document required functionality and constraints is always a challenge in software development. Creating agreement on what the software needs to accomplish and then communicating that to a wide variety of audiences (end user, programmers, managers, etc) is essential if a project is to be successful.
3. Use Component-Based Architectures
4. Visually Model Software
See how the elements of the system fit together
Make sure that the code maintains consistency between the design and its implementation
Promotes unambiguous communication
5. Verify Software Quality
Build quality assessment into the development process
Test at all stages of development
Involve all stakeholders in testing
Use objective measurements and criteria
Not treat testing as an afterthought or a separate activity performed by a separate group
6. Control Changes to Software
Another approach to identifying what does and doesn’t work in developing software, is to create a “Worst Practices” list. The Airlie Software Council (Foot Note 1)
Don’t use schedule compression to justify usage of new technology on any time critical project
Don’t specify implementation technology in the RFP
Don’t advocate use of unproven “Silver Bullet” approaches.
Don’t expect to recover from any substantial schedule slip (10% or more) without making more than corresponding reductions in functionality to be delivered
Don’t put items out of project control on the critical path
Don’t expect to achieve large positive improvements (10% or more) over past observed performance
Don’t bury all project complexity in the software (as opposed to the hardware).
Don’t conduct the critical system engineering tasks (particularly the hardware/software partitioning) without sufficient software expertise
Don’t believe that formal reviews provide an accurate picture of the project. Expect usefulness of formal reviews to be inversely proportional to the number of people attending beyond five <
1. The Airlie Software Council was commissioned by the Under Secretary of Defense for Acquisition and Technology, and the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence as part of the DOD-wide Software Acquisition Best Practices initiative. The Council was charged with identifying fundamental processes and proven solutions that are essential to successfully managing large-scale software development and maintenance projects. The Council was comprised of highly successful managers of large-scale software projects, internationally recognized authors, prominent consultants, and executives responsible for software development at major companies.
The Concept of Software Best Practices. Copyright 1996 by Computerworld. Originally published in the September 1996 issue of Computerworld Italia.
Rational Unified Process: Best Practices for Software Development Teams (White Paper ), Copyright © 2000 Rational Software Corporation.