iREM AND AGILE IMPLEMENTATION

| 1 comments

iREM is an iterative approach of SaaS RE for the agile implementation. It facilitates the discovery of services by mapping business process to services for the agile implementation in small iterations:

A business process (BP) is identified as an input (e.g. marked in bold and red color in Figure 2) from a pool or repository of business processes that need to be implemented in terms of software services in the agile iteration X (depending on situational circumstances, a large business process may span multiple iterations or a small number of business processes may fit in one iteration).

The identified business process (BP) is linked or mapped to a single or set of business use cases (BUC), which are identified and stored in the business use case backlog for the iteration X.

Each identified business use case (BUC) is linked or mapped to a single or set of system use cases (SUC), which are identified and stored in the system use case backlog for the iteration X.

Each identified system use case (SUC) is linked or mapped to a single or set of test cases (TC), which are identified and stored in the test case backlog for the iteration X. At this stage, the system use case backlog integrated with the test case backlog is released for the iteration X implementation by using agile practices.

Each identified system use case (SUC) is linked or mapped to a single or set of agile practices (within their overall generic process lifecycle), which is called integrated system requirement or system use case (please see Section above for details).

Each integrated system use case is linked or mapped to a software service (integrated SaaS requirements, which are stored in the product service backlog (e.g. marked in bold and green color in Figure 2) for the iteration X.

The business analyst and quality analyst start the next iteration X + 1 for identifying the BP and attached BUC, SUC and TC. The development team starts working on the implementation of services listed in the product service backlog for the iteration X as per their priority. If the requirements are changed during the iteration X implementation then those changes (if minor) can be considered in the current iteration X or next iteration X+n (where n= 1, 2, 3…). In the end of an iteration X, the iteration X retrospective is conducted to review the agile process (e.g. which services have been implemented by using which agile practices), and identify any issues (e.g. missed requirements, less than 50% unit test coverage) and their root-causes (e.g. continuous integration was not performed for SUC of service 1, code view review and user viewing sessions were not conducted) and then finally, the iteration X is released for further integration and user acceptance testing. Here, at this stage, the system use case backlog integrated with test case backlog for the next iteration X+1 may be released to development team by the business and quality analysts for implementation. The development team starts a work on the Iteration X+1 and also provides support for fixing any defects in the previous iteration X.

Here, we may observe how iREM supports the iterative discovery of SaaS requirements and their agile implementation. It can also be observed that there can be one or more active iterations at a given point of time (business and quality analyst working on the iteration X+1 while the development team is working on iteration X).

Using Pareto’s Law

Working effectively means deciding the relative priorities of different tasks. Obvious perhaps, and of course you may say some things are clearly more important than others. But it is very easy to underestimate just how much this concept influences what you need to do, indeed just how much it influences your inherent effectiveness.

Many years ago, the Italian economist Vilfredo Pareto recognized the truism that carries his name and that is now more commonly called the 80/20 rule. It links cause and effect in a ratio and, although this is not represented absolutely accurately in real life, an approximate 80/20 ratio is consistently found in many business activities, sometimes with a precision that is considerable. This means that for instance:

- 20 percent of a company’s customers are likely to produce 80 percent of its revenue.

- 20 percent of factory errors are likely to cause 80 percent of quality rejects.

And it applies specifically in terms of issues relating directly to time:

- 20 percent of meeting time results in about 80 percent of decisions made.

- 20 percent of items to read that pass across your desk produce 80 percent of the information you need in your work.

SUCCESSFUL MANAGEMENT is dependent on A Time-Aware Team

Agile Promise

| 0 comments

The principles behind the Agile Manifesto documents well the initial promise the agile proponents were giving.

- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

- Business people and developers must work together daily throughout the project.

- Build projects around motivated individuals.

- Give them the environment and support they need, and trust them to get the job done.

- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

- Working software is the primary measure of progress.

- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

- Continuous attention to technical excellence and good design enhances agility.

- Simplicity--the art of maximizing the amount of work not done--is essential.

- The best architectures, requirements, and designs emerge from self-organizing teams.

- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As can be seen in these principles the agile approach is focused in building a co-located team and in seeing the benefits though the eyes of the team. Much of the project management tasks can be reduced to minimum due the co-location, and remaining tasks can be integrated seamlessly to the development work. Agreeing the tasks, reviewing the results, setting and striving for the task goals, solving the rising issues and other such tasks become a part of the teamwork. Similarly, external parties become an integral part or contributors of the team.

It is more difficult to achieve similar benefits in larger organizations (Kettunen, 2009) where the number of people leads to the existence of many teams and the distance between people grow bigger, even global in many occasions. Inevitably the external parties will become more distanced as well. So the agile benefits for larger organizations cannot be expected to be the same or on the same level as for small organizations. Yet the expectations are that an agile organization is responsive to the customer needs, even when the customer has difficulties in deciding on his/her own needs and changes his/her opinion frequently. In large organizations this kind of changes often have the "whip effect", similar to that in a supply chain (Lee, Padmanabhan & Whang, 1997). It creates variance and bottlenecks throughout the development and the delivery process. Keeping focus in tasks that are delivering value to the customer in the customer satisfying manner and removing the rest becomes a major challenge.

The promise of better quality is to be deemed as well (Abbas, 2009). Thought the quality in a team level means improving in a team level that does not build linearly up to better quality in larger organizations. On the contrary, the local quality optimization may lead to deterioration of overall quality due to different understanding of the optimum and conflicting implementations of the quality related practices. Having a large number of people allows the development of larger software, but requires also growing attention to the non-functional characteristics, like reliability, usability, maintainability, and other "ilities". The traditional means for the quality control, like a separate quality organization or quality gates in the process can easily lead to additional effort that may not add value to the customer.

Parallel to obtaining the customer value and the quality benefits there are business stakeholders, like owners, partners, and top management of the organization to be satisfied as well (Power, 2010). In a larger organization their distance grows to customers and also to satisfying the customer needs. Each group defines and focuses on their own interests. It becomes a challenge to achieve the customer-supplier win-win in practice. The effectiveness of an organization from its stakeholder point of view compromises the pure customer value creating interests. Particularly for the product development organizations where the product manager is "a proxy customer" distance to the customer grows bigger than what is stated in the initial agile principles.

The third interest group to satisfy is the developers and the development organization in general (Cockburn & Highsmith, 2001; Melnik & Mauer, 2006). In a large organization they easily drift away from the customers but from the business stakeholders alike. It becomes challenging to foster the customer and business knowledge, the technical and development competence, and the large-scale teamwork in a partial isolation. Consequently the demand for customer co-operation, productive self-organizing teams, growth of essential competences, and the like agile promises are not fulfilled. Yet these are the essential characteristics of an agile software development organization.\

In short, the expectations have grown that the agile approach can be transformed from a team level methodology to the working and management practice of a larger organization and still retain the agile benefits. So the model of a small, co-located self-organizing team, consisting of skilled and apt people, working closely together with a customer fulfilling customer changing needs can be mapped to large organization that provides (Highsmith, 2007; Schwaber, 2007):

- Increased customer satisfaction

- Reduced time-to-market (better "time-to-benefit")

- Increased quality

- Improved project portfolio and product management (project types, features)

- Improved product development investment management (control and flexibility)

- Reduced "waste" (increased efficiency, productivity, development cost)

- Better predictability (visibility)

- Better risk management (risk reduction)

- Better workforce morale (developer satisfaction, well-being)

The two main strategies for expansion are inside-out and outside-in. The inside-out strategy means not just expanding from the team level to the management structure but also adjusting to and with the surrounding practices, that is, expanding the agile and agile compliant principles to cover more areas of the software development life cycle as well as to the managing of the software development organization. The outside-in strategy means amalgamating the agile development with the traditional software development and the organization management sustaining both as much as possible.

TOP TEN LEADERSHIP TECHNIQUES FOR BUILDING HIGH-PERFORMING TEAMS

Building High-Performing Teams

1. Define a very clear picture of the future - a vision for the team. This is crucial, because teams search desperately for specific targets. Consider the old expression: "If you don't know where you are going, any road will get you there." Journeys without a clear destination leave groups feeling flat and lost. Keeping teams informed on where they're headed and how best to get there means leaders must be prepared to acknowledge and adapt to changes in operational conditions and even objectives. Leaders cannot sit back and watch, but instead must create and recreate the vision and team spirit that stops people losing heart and becoming lost.


2. Be genuine, even if it means lowering your guard. Leaders who create 'click' have an uncanny sense about how and when to express their inner selves. They will even reveal their own vulnerabilities at the right time to gain the respect of those around them. They are not so concerned about projecting a perfect image: they know that high-impact leaders get results by laughing at their own flaws. They don't play make-believe, knowing it's more important 'to be' than to 'seem to be'.


3. Ask good questions. They use enquiry and advocacy in such a way as to keep them abreast of what is really going on. They seem to use a simple formula of the 70-20-10 rule in conversations: 70 per cent listening, 20 per cent enquiring with just the right amount of advocacy, and 10 per cent tracking (i.e., summarizing and synthesizing information, and providing possible courses of action).


4. Talk about things - even the hard things. A leader who gets their team to click is not afraid to talk about the tough stuff. They find ways to have the difficult conversations in the knowledge that burying problems doesn't make them go away. They also know that if they, as leader, don't talk about things, no-one will and, pretty soon, a culture will develop in which too many things are left unsaid. (I can always tell when teams are dysfunctional by measuring the amount of stuff not talked about, or what I call the "let's not go there" issues.)


5. Follow through on commitments. Leaders of high-performing teams find ways to build trust and maintain it, especially by making teams hold to their commitments and keeping the team's view of its goals clear. However, they also know how to distinguish professional trust from blind loyalty.


6. Let others speak first. In high-performing teams, members see themselves as equal in terms of communication. Leaders should therefore encourage this by putting the other person's need to express their agenda ahead of their own.


7. Listen. High-performing teams comprise people who have mastered the art of listening without fear, of allowing others to speak without reacting strongly or negatively to what is being said, or what they anticipate will be said. The leader fosters and honors this attribute within the team by quickly putting a stop to bad conversational behavior that cuts other people off and implies that their ideas are not valued. The leader knows that achieving higher levels of innovation requires team members to be unafraid to express unusual ideas and advocate experimental processes. They emphasize this by publicly thanking those who take risks - and by making sure that sharp-shooters put their guns away.


8. Face up to non-performing players. This brings us to a very important characteristic of high-performing teams, which is that their leaders do not tolerate players who pull the team apart. Interestingly, experienced leaders frequently maintain unity and discipline through third parties in the form of people we call 'passionate champions'. A leader may surround his or herself with several passionate champions, who have established an understanding and close working relationship with one another, and who are totally focused on, and committed to, the team's objectives. They are capable of getting the job done - and not afraid to remove people who are failing to help them do so.


9. Have fun, but never at others' expense. High-impact leaders steer clear of sarcasm: they always take the high road. If they do make fun of someone, it's usually themselves. They have learned the lesson that reckless humor can be misinterpreted and backfire. They know that critics of the organization can turn inappropriate remarks back on a leader who makes them.


10. Be confident and dependable. Somehow, over and above the daily struggle, leaders who get teams to click project confidence. They do this by preparing their conversations and not backing away from, or skimming over, real issues and problems, even difficult or confronting ones. They always address 'What's up?' and 'What's so?' in the organization. They don't try to be spin doctors because they know that, ultimately, this doesn't work. Rather, they are known as straight shooters - people who play hard, fight fair, and never, never give up. At the end of the day, team members know that, whatever happens, their leader will be left standing. This gives them confidence that they will be standing, too. They also know that, should things get really bad, their leader will not desert them or try to shift the blame, but seek to protect them, even if it means standing in the line of fire.

Source of Information : PhilHarkins 10 Leadership Techniques for Building High Performing Teams

Using Windows Internet Name Service

WINS is a service that resolves computer names to IP addresses. Using WINS, the computer name COMPUTER84, for example, can be resolved to an IP address that enables computers on a Microsoft network to find one another and transfer information. WINS is needed to support pre–Windows 2000 systems and older applications that use NetBIOS over TCP/IP, such as the .NET command-line utilities. If you don’t have pre–Windows 2000 systems or applications on the network, you don’t need to use WINS.

WINS works best in client/server environments in which WINS clients send single-label (host) name queries to WINS servers for name resolution and WINS servers resolve the query and respond. When all your DNS servers are running Windows Server 2008 or later, deploying a Global Names zone creates static, global records with single-label names without relying on WINS. This allows users to access hosts using single-label names rather than FQDNs and removes the dependency on WINS. To transmit WINS queries and other information, computers use NetBIOS. NetBIOS provides an application programming interface (API) that allows computers on a network to communicate. NetBIOS applications rely on WINS or the local LMHOSTS file to resolve computer names to IP addresses. On pre–Windows 2000 networks, WINS is the primary name resolution service available. On Windows 2000 and later networks, DNS is the primary name resolution service and WINS has a different function. This function is to allow pre–Windows 2000 systems to browse lists of resources on the network and to allow Windows 2000 and later systems to locate NetBIOS resources.

To enable WINS name resolution on a network, you need to configure WINS clients and servers. When you configure WINS clients, you tell the clients the IP addresses for WINS servers on the network. Using the IP addresses, clients can communicate with WINS servers anywhere on the network, even if the servers are on different subnets. WINS clients can also communicate by using a broadcast method through which clients broadcast messages to other computers on the local network segment requesting their IP addresses. Because messages are broadcast, the WINS server isn’t used. Any non-WINS clients that support this type of message broadcasting can also use this method to resolve computer names to IP addresses.

When clients communicate with WINS servers, they establish sessions that have the following three key parts:

» Name registration. During name registration, the client gives the server its computer name and its IP address and asks to be added to the WINS database. If the specified computer name and IP address aren’t already in use on the network, the WINS server accepts the request and registers the client in the WINS database.

» Name renewal. Name registration isn’t permanent. Instead, the client can use the name for a specified period known as a lease. The client is also given a time period within which the lease must be renewed, which is known as the renewal interval. The client must reregister with the WINS server during the renewal interval.
» Name release. If the client can’t renew the lease, the name registration is released, allowing another system on the network to use the computer name, IP address, or both. The names are also released when you shut down a WINS client.

After a client establishes a session with a WINS server, the client can request name resolution services. The method used to resolve computer names to IP addresses depends on how the network is configured. The following four name-resolution methods are available:

» B-node (broadcast). Uses broadcast messages to resolve computer names to IP addresses. Computers that need to resolve a name broadcast a message to every host on the local network, requesting the IP address for a computer name. On a large network with hundreds or thousands of computers, these broadcast messages can use up valuable network bandwidth.

» P-node (peer-to-peer). Uses WINS servers to resolve computer names to IP addresses. As explained earlier, client sessions have three parts: name registration, name renewal, and name release. In this mode, when a client needs to resolve a computer name to an IP address, the client sends a query message to the server and the server responds with an answer.

» M-node (mixed). Combines b-node and p-node. With m-node, a WINS client first tries to use b-node for name resolution. If the attempt fails, the client then tries to use p-node. Because b-node is used first, this method has the same problems with network bandwidth usage as b-node.

» H-node (hybrid). Also combines b-node and p-node. With h-node, a WINS client first tries to use p-node for peer-to-peer name resolution. If the attempt fails, the client then tries to use broadcast messages with b-node. Because peer-to-peer is the primary method, h-node offers the best perfor¬mance on most networks. H-node is also the default method for WINS name resolution.

If WINS servers are available on the network, Windows clients use the p-node method for name resolution. If no WINS servers are available on the network, Windows clients use the b-node method for name resolution. Windows computers can also use DNS and the local files LMHOSTS and HOSTS to resolve network names.

When you use DHCP to assign IP addresses dynamically, you should set the name resolution method for DHCP clients. To do this, you need to set DHCP scope options for the 046 WINS/NBT Node Type as specified in “Setting Scope Options”. The best method to use is h-node. You’ll get the best performance and have reduced traffic on the network.


Source of Information : Windows Server 2012 Pocket Consultant 2012

Windows Server 2012 - Using Domain Name System

DNS is a name-resolution service that resolves computer names to IP addresses. Using DNS, the fully qualified host name computer84.cpandl.com, for example, can be resolved to an IP address, which allows it and other computers to find one another. DNS operates over the TCP/IP protocol stack and can be integrated with WINS, Dynamic Host Configuration Protocol (DHCP), and Active Directory Domain Services.
DNS organizes groups of computers into domains. These domains are organized into a hierarchical structure, which can be defined on an Internet-wide basis for public networks or on an enterprise-wide basis for private networks (also known as intranets and extranets). The various levels within the hierarchy identify individual computers, organizational domains, and top-level domains. For the fully qualified host name computer84.cpandl.com, computer84 represents the host name for an individual computer, cpandl is the organizational domain, and com is the top-level domain.

Top-level domains are at the root of the DNS hierarchy; they are also called root domains. These domains are organized geographically, by organization type, and by function. Normal domains, such as cpandl.com, are also referred to as parent domains. They’re called parent domains because they’re the parents of an organizational structure. Parent domains can be divided into subdomains that can be used for groups or departments within an organization.

Subdomains are often referred to as child domains. For example, the fully qualified domain name (FQDN) for a computer within a human resources group could be jacob.hr.cpandl.com. Here, jacob is the host name, hr is the child domain, and cpandl.com is the parent domain.

Active Directory domains use DNS to implement their naming structure and hierarchy. Active Directory and DNS are tightly integrated, so much so that you should install DNS on the network before you can install domain controllers using Active Directory. During installation of the first domain controller on an Active Directory network, you’re given the opportunity to install DNS automatically if a DNS server can’t be found on the network. You are also able to specify whether DNS and Active Directory should be fully integrated. In most cases, you should respond affirmatively to both requests. With full integration, DNS information is stored directly in Active Directory. This allows you to take advantage of Active Directory’s capabilities. The difference between partial integration and full integration is very important:

» Partial integration With partial integration, the domain uses standard file storage. DNS information is stored in text-based files that end with the .dns extension, and the default location of these files is %SystemRoot%\System32\Dns. Updates to DNS are handled through a single authoritative DNS server. This server is designated as the primary DNS server for the particular domain or an area within a domain called a zone. Clients that use dynamic DNS updates through DHCP must be configured to use the primary DNS server in the zone. If they aren’t, their DNS information won’t be updated. Likewise, dynamic updates through DHCP can’t be made if the primary DNS server is offline.

» Full integration With full integration, the domain uses directory-integrated storage. DNS information is stored directly in Active Directory and is available through the container for the dns Zone object. Because the information is part of Active Directory, any domain controller can access the data and a multimaster approach can be used for dynamic updates through DHCP. This allows any domain controller running the DNS Server service to handle dynamic updates. Furthermore, clients that use dynamic DNS updates through DHCP can use any DNS server within the zone. An added benefit of directory integration is the ability to use directory security to control access to DNS information.

If you look at the way DNS information is replicated throughout the network, you can see more advantages to full integration with Active Directory. With partial integration, DNS information is stored and replicated separately from Active Direc¬tory. Having two separate structures reduces the effectiveness of both DNS and Ac¬tive Directory and makes administration more complex. Because DNS is less efficient than Active Directory at replicating changes, you might also increase network traffic and the amount of time it takes to replicate DNS changes throughout the network.

To enable DNS on the network, you need to configure DNS clients and servers. When you configure DNS clients, you tell the clients the IP addresses of DNS servers on the network. Using these addresses, clients can communicate with DNS servers anywhere on the network, even if the servers are on different subnets.

When you install the DNS Server service on an RODC, the RODC is able to pull a read only replica of all application directory partitions that are used by DNS, includ¬ing ForestDNSZones and DomainDNSZones. Clients can then query the RODC for name resolution as they would query any other DNS server. However, as with direc¬tory updates, the DNS server on an RODC does not support direct updates. This means that the RODC does not register name server (NS) resource records for any Active Directory–integrated zone that it hosts. When a client attempts to update its DNS records against an RODC, the server returns a referral to a DNS server that the client can use for the update. The DNS server on the RODC should receive the updated record from the DNS server that receives details about the update using a special replicate-single-object request that runs as a background process.

Windows 7 and later releases add support for DNS Security Extensions (DNSSEC). The DNS client running on these operating systems can send queries that indicate support for DNSSEC, process related records, and determine whether a DNS server has validated records on its behalf. On Windows servers, this allows your DNS serv¬ers to securely sign zones and to host DNSSEC-signed zones. It also allows DNS serv¬ers to process related records and perform both validation and authentication.

Source of Information : Windows Server 2012 Pocket Consultant 2012

Subscribe to Computing Tech

Enter your email address:

Delivered by FeedBurner

Alltop, all the top stories
BlogMalaysia.com
All Malaysian Bloggers Project
Add to Technorati Favorites Top Blogs
Computer Blogs - BlogCatalog Blog Directory blogarama - the blog directory Top Computers blogs Software TopOfBlogs Information Technology, SEO Technology