Architecture and Development

Architecture and Development

UMS delivers high quality and innovative ICT solutions which optimize the mission critical business processes of the clients we service. We provide a wide range of highly skilled development resources expending from Oracle, Java to Siebel. We are uniquely positioned to deliver world class and sustainable ICT solutions in almost any industry.

UMS offers development and architecture services to address wide ranging client requirements using the following methodologies:
  • Agile Software Development
  • Crystal Methods
  • Dynamic Systems Development Model (DSDM)
  • Extreme Programming (XP)
  • Feature Driven Development (FDD)
  • Joint Application Development (JAD)
  • Lean Development (LD)

Architecture and Development Methodologies

A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.

UMS uses the following methodologies:

Agile Software Development Methodology

Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies e.g. Crystal Methods, Dynamic Systems Development Model (DSDM), and Scrum.

Most agile methods attempt to minimize risk by developing software in short time-boxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the UMS team re-evaluates project priorities.

Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish the software. At a minimum, this includes programmers and the people who define the product such as product managers, business analysts, or actual customers. The bullpen may also include testers, interface designers, technical writers, and management.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods.

Dynamic Systems Development Model Methodology

The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. It is the evolution of rapid application development (RAD) practices. DSDM boasts the best-supported training and documentation of any of the agile software development techniques, at least in Europe. DSDM favours the philosophy that nothing is built perfectly the first time and looks to software development as an exploratory endeavour.

Dynamic Systems Development Model Methodology

The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. It is the evolution of rapid application development (RAD) practices. DSDM boasts the best-supported training and documentation of any of the agile software development techniques, at least in Europe. DSDM favours the philosophy that nothing is built perfectly the first time and looks to software development as an exploratory endeavour.

Joint Application Development (JAD) Methodology

JAD is a requirements-definition and user-interface design methodology in which end-users, executives, and developers attend intense off-site meetings to work out a system's details. So the Joint Application Development (JAD) methodology aims to involve the client in the design and development of an application. This is accomplished through a series of collaborative workshops called JAD sessions. Two employees of IBM, Chuck Morris and Tony Crawford, developed the JAD methodology in the late 1970s and began teaching the approach in to the 1980s.

JAD focuses on the business problem rather than technical details. It is most applicable to the development of business systems, but it can be used successfully for systems software. It produces its savings by shortening the elapsed time required to gather a system's requirements and by gathering requirements better, thus reducing the number of costly, downstream requirements changes. Its success depends on effective leadership of the JAD sessions; on participation by key end-users, executives, and developers; and on achieving group synergy during JAD sessions.

In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client satisfaction, both of which stem from the constant involvement of the client throughout the development process. On the other hand, with the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews.

Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through strategies that include fewer formal methodologies and reusing software components.
agaile-software

Lean Development (LD) Methodology

Lean Development focuses on the creation of change-tolerant software. This methodology embodies the notion of dynamic stability which can be thought of as similar to how Scrum embraces controlled chaos. Bob Charette, the originator, writes that the measurable goal of LD is to build software with one-third the human effort, one-third the development hours and one-third the investment as compared to what SEI (Software Engineering Institute) CMM Level 3 organization would achieve.

There are 12 principles of Lean Development

  1. Satisfying the customer is the highest priority
  2. Always provide the best value for the money
  3. Success depends on active customer participation
  4. Every LD project is a team effort
  5. Everything is changeable
  6. Domain, not point, solutions
  7. Complete, don't construct
  8. An 80 percent solution today instead of 100 percent solution tomorrow
  9. Minimalism is essential
  10. Needs determine technology
  11. Product growth is feature growth, not size growth
  12. Never push LD beyond its limits


Rapid Application Development (RAD) Methodology

“Rapid-development language” is a general term that refers to any programming language that offers speedier implementation than do traditional third-generation languages such as C/C++, Pascal, or Fortran. Rapid-Development Languages (RDLs) produce their savings by reducing the amount of construction needed to build a product. Although the savings are realized during construction, the ability to shorten the construction cycle has project wide implications: shorter construction cycles make incremental lifecycles such as Evolutionary Prototyping practical. Because RDLs often lack first-rate performance, constrain flexibility, and are limited to specific kinds of problems, they are usually better suited to the development of in-house business software and limited-distribution custom software than systems software.
RAD (rapid application development) proposes that products can be developed faster and of higher quality by:

  • Using workshops or focus groups to gather requirements
  • Prototyping and user testing of designs
  • Re-using software components
  • Following a schedule that defers design improvements to the next product version
  • Keeping review meetings and other team communication informal


There are commercial products that include requirements gathering tools, prototyping tools, software development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use.
The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.
rapid

Rational Unified Process (RUP) Methodology

The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix.



By contrast, RUP represents an iterative approach that is superior for a number of reasons:

  • It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project
  • Integration is not one “big bang” at the end; instead, elements are integrated progressively
  • Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier
  • Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology
  • Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning
  • When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery
  • Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on
  • The development process itself can be improved and refined along the way. The assessment at the end of iteration not only looks at the status of the project from a product or schedule perspective, but also analyses what should be changed in the organization and in the process to make it perform better in the next iteration

Scrum Methodology

Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in teams previously paralyzed by heavier, process-laden methodologies.

Scrum is characterized by:

  • A living backlog of prioritized work to be done
  • Completion of a largely fixed set of backlog items in a series of short iterations or sprints
  • A brief daily meeting (called a scrum), at which progress is explained, upcoming work is described, and obstacles are raised
  • A brief planning session in which the backlog items for the sprint will be defined
  • A brief heartbeat retrospective, at which all team members reflect about the past sprint
  • Scrum is facilitated by a scrum master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The scrum master is not the leader of the team (as they are self-organizing) but acts as a productivity buffer between the team and any destabilizing influences
Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional “process control” manner. As such, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to respond in an agile manner to emerging challenges.

Systems Development Life Cycle (SDLC) Methodology

Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in teams previously paralyzed by heavier, process-laden methodologies.

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize.

Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.

In general, an SDLC methodology follows these steps:

  1. If there is an existing system, its deficiencies are identified. This is accomplished by interviewing users and consulting with support personnel
  2. The new system requirements are defined including addressing any deficiencies in the existing system with specific proposals for improvement
  3. The proposed system is designed. Plans are created detailing the hardware, operating systems, programming, and security issues
  4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage
  5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once
  6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures

Waterfall (Traditional) Methodology

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is rigid and linear. Waterfall development has distinct goals for each phase of development where each phase is completed for the next one is started and there is no turning back.

The perceived advantages of the waterfall process are that it allows for departmentalization and managerial control. A schedule is typically set with deadlines for each stage of development and a product can proceed through the development process. In theory, this process leads to the project being delivered on time because each phase has been planned in detail.

In practice, waterfall development often falls short of expectations as it does not embrace the inevitable changes and revisions that become necessary with most projects. Once an application is in the testing stage, it is very difficult to go back and change something that was not thought of in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), sync and stabilize, build and fix, and the spiral model.

The nine principles of DSDM are:

  1. Active user involvement
  2. Empowered teams that the authority to can make decisions
  3. A focus on frequent delivery of products
  4. Using fitness for business purpose as the essential criterion for acceptance of deliverables
  5. Iterative and incremental development to ensure convergence on an accurate business Solution
  6. Reversible changes during development
  7. Requirements that are base lined at a high level
  8. Integrated testing throughout the life cycle
  9. Collaboration and cooperation between all stakeholders

Tools