CSC/ECE 517 Fall 2011/ch6 6e zj

From Expertiza_Wiki
Jump to navigation Jump to search

Introduction

The concept of heavier-weight methodology

Heavyweight development methodology(Traditional methodology) is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment. Heavyweight development methodology mainly focuses detailed documentation, inclusive planning, and extroverted design. Following are the most popular Heavyweight development methodologies.[cite 1 ]

The concept of agile methodology

Agile methodology(Lightweight Methodology) is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints.

Compare with the heavier-weight methodology and agile methodology

Heavier-weight methodology

Heavyweight methodology:

  • A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly.
  • Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time.
  • Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail.
  • This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules.
  • But this works well only until things start changing; therefore, project managers who use heavyweight methodologies will resist change.
  • The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment.
  • An example of a “heavyweight” process is the Rational Unified Process.
  • Project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology
  • Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.

Advantage of heavier-weight methodology

  • It is very easy yet powerful method of software development. The phases are arranged so that it helps even the new developers to understand the “big picture” of how to go about developing the software through the software development life cycle.
  • It calls for a disciplined approach to save on project time and cost as well effort. Otherwise the implementation team may develop a code only to realize later that it was not at all required. This happens much more than one might realize and it cause issues both in development and testing.
  • The project management stakeholders are forced to correctly define the business requirements documentation (BRD) and the project management requirements. At the same time the developers are forced to understand these thoroughly before they start writing the software requirements specification (SRS), high level design and code.
  • It essentially requires documentation at every stage. This gives better understanding of the requirements, the logic of the codes and tests that were conducted on the software.

Disadvantage of heavier-weight methodology

The traditional project methodologies that many top corporations use, such as the SDLC approach, are considered to be bureaucratic or “predictive” in nature, and they’ve resulted in many unsuccessful projects. These “heavyweight” methodologies are becoming increasingly unpopular. They can be so laborious that the whole pace of design, development, and deployment actually slows down.
Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time. Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail. This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules. But this works well only until things start changing; therefore, I believe project managers who use heavyweight methodologies will resist change.
The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment, whereas lightweight methodologies propose executing the project steps in parallel. For example, the manager of a project that is based on the heavyweight methodology won’t agree to build the IT solution until the full requirements have been determined, and so it continues for each project phase. Still, any project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology. Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.

Agile methodology

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.

Advantage of agile methodology

It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?

  • Agile methodology has an adaptive team which is able to respond to the changing requirements.
  • The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed.
  • Face to face communication and continuous inputs from customer representative leaves no spaces for guesswork.
  • The documentation is crisp and to the point to save time.
  • The end result is the high quality software in least possible time duration and satisfied custormer.


In a nutshell this means that you can get development started fast, but with the caveat that the project scope statement is “flexible” and not fully defined. Hence this can be one of the major causes of scope creed if not managed properly.

Disadvantage of agile methodology

  • In case of some software deliverables, especially the large ones, it is difficult to access the effort required at the beginning of the software development life cycle.
  • There is lack of emphasis on necessary designing and documentation.
  • The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
  • Only senior programmers are capable of taking the kind of decisions required during the development processes. Hence it has no place for newbie programmers, unless combined with experienced recourses.
  • Such development methodologies have also been criticized for their lack of strong planning and problems with applying them to the creation of larger software systems, especially in comparison to older, heavier weight methods like the spiral model.

Heavier-weight Methodology VS Agile Methodology

The Difference Between Heavier-weight Methodology and Agile Methodology

Differences Agile Methodology Heavier-weight Methodology
Customers Committed,knowledgeable,collocated,collaborative,representative,empowered Access to knowledgeable,collaborative,representative,empowered customers
Requirements Mainly emergent,rapid change. Knowable early, largely stable.
Architecture Designed for current requirements Designed for current and foreseeable requirements
Size Smaller Team and Products Larger Team and Products
Primary objective Rapid value High assurance
Developers Knowledgeable,collocated,collaborative Plan-driven,adequate skills,access to external knowledge.
Release cycle In phases (multiple cycles) Big bang (all functionality at once)

The Issue of Heavier-weight Methodology and Agile Methodology

Issue Agile Methodology Heavier-weight Methodology
Development life cycle Linear or incremental Incremental
Style of development Adaptive Anticipatory
Requirements Emergent–Discovered during the project. Clearly defined and documented
Documentation Light(replaced by face to face communication) Heavy/detailed Explicit knowledge
Team members Co-location of generalist senior technical staff Distributed teams of specialists
Client Involvement Onsite and considered as a team member Active/proactive Low involvement
Market Dynamic/Early market Mature/Main Street market
Measure of success Business value delivered Conformance to plan

Example

Heavier-weight methodology

Rational Unified Process

Indroduction of RUP

The Rational Unified Process (RUP), originated by Rational Software and later by IBM, is a heavy iterative approach that takes into account the need to accommodate change and adaptability during the development process. In RUP: a software product is designed and built in a succession of incremental iterations. Each iteration includes some, or most, of the development disciplines like requirements, analysis, design, and implementation and testing. It provides a disciplined approach to assign tasks and responsibilities with a software development organization for the successful development of software.

The Main Goal of RUP

The main goal of RUP is to ensure the production of high-quality software by meeting the needs of its end-users within a predictable schedule and budget. The Rational Unifies Model provides guidelines. templates and tool mentors to software engineering team to take full advantage of among others. Following are the guidelines for best pratices:

  • Develop software iteratively
  • Manage requirements
  • Use component-based architectures
  • Visual model software
  • Verify software quality
  • Control changes to software
The Phases of RUP
The Phases of RUP
The Phases of RUP

RUP has a series of phases as follows:

  • Inception: (Understand what to build) In this phase project’s scope, estimated costs, risks, business case, environment and architecture are identified.
  • Elaboration: (Understand how to build it) In this phase requirements are specified in detail, architecture is validated, the project environment is further defined and the project team is configured.
  • Construction: (Build the Product) In this phase software is built and tested and supporting documentation is produced.
  • Transition: (Transition the Product to its Users) In this phase software is system tested, user tested, reworked and deployed.


Usage of RUP Model
  • Distributed systems
  • Very large or complex systems
  • Systems combining several business areas
  • Systems reusing other systems
  • Distributed development of a system

Spiral Model

Indroduction of Spiral Model

Spiral Model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.This model is also known as Boehm's model, using his model, process is represented as a spiral rather than as a sequence of activities with backtracking.

Processes in Spiral Model
Spiral model
Spiral model

There are four processes in spiral model:

  • Objective setting: Specific objectives for the project phase are identified.
  • Risk assessment and reduction: Key risks are identified, analyzed and information is obtained to reduce these risks. The aim is that all risks are resolved.
  • Development and Validation: Once all possible risks have been identified the development of the software can begin, an appropriate model is chosen for the next phase of development.
  • Planning: The project is reviewed.


Usage of Spiral Model

Following are the usage of Spiral model:

  • Large and high budget projects.
  • When risk assessment is very critical.
  • Requirements are not very clearly defined and

complex.

  • When costs and risk evaluation is important
  • For medium to high-risk projects.
  • Long-term project commitment unwise because of potential changes to economic priorities.

Agile methodology

Extreme Programming(XP)

Indroduction of Extreme Programming(XP)

Extreme Programming(XP) is a lightweight design method developed by Kent Beck, Ward Cunningham, and others, XP has evolved from the problems caused by the long development cycles of traditional development models. The XP process can be characterized by short development cycles, incremental planning, continuous feedback, reliance on communication, and evolutionary design. With all the above qualities, XP programmers respond to changing environment with much more courage.

XP Terms and Practices
Life cycle of
Life cycle of

A summary of XP terms and practices is listed below:

  • The Planning Process:The desired features of the software, which are communicated by the customer, are combined with cost estimates provided by the programmers to determine what the most important factors of the software are. This stage is sometimes called the Planning Game.
  • Small Releases:The software is developed in small stages that are updated frequently, typically every two weeks.
  • Metaphor:All members on an XP team use common names and descriptions to guide development and communicate on common terms.
  • Simple Design:The software should include only the code that is necessary to achieve the desired results communicated by the customer at each stage in the process. The emphasis is not on building for future versions of the product.
  • Testing:Testing is done consistently throughout the process. Programmers design the tests first and then write the software to fulfill the requirements of the test. The customer also provides acceptance tests at each stage to ensure the desired results are achieved.
  • Refactoring:XP programmers improve the design of the software through every stage of development instead of waiting until the end of the development and going back to correct flaws.
  • Pair Programming:All code is written by a pair of programmers working at the same machine.
  • Collective Ownership:Every line of code belongs to every programmer working on the project, so there are no issues of proprietary authorship to slow the project down. Code is changed when it needs to be changed without delay.
  • Continuous Integration:The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.
  • 40-Hour Week:The XP team does not work excessive overtime to ensure that the team remains well-rested, alert and effective.
  • On-Site Customer:The XP project is directed by the customer who is available all the time to answer questions, set priorities and determine requirements of the project.
  • Coding Standard:The programmers all write code in the same way. This allows them to work in pairs and to share ownership of the code.


Crystal

Indroduction of Crystal

Crystal Methodologies is a family of methodologies((Crystal Clear, Crystal Yellow, Crystal Orange, etc.)developed by Alistair Cockburn. The word “Crystal” refers to the degree of hardness and the different colors of the methodology in much the same way that a crystal can have various degrees of hardness and variety of colors. The degree of hardness pertains to the use of rigor and ceremony i.e. as the hardness increases the amount of required documentation, processes and procedures increases.

Features and Restrictions of Crystal
Crystal
Crystal

Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.
Crystal methods are denoted by colors. The color of the methods as follows: Clear, Yellow, Orange, Orange Web, Red, Magenta, and Blue. Only three of the methods – Crystal Clear, Orange and Orange Web - have been constructed and actually used on projects.
One of the restrictions of the Crystal methods is that they only address collocated teams. Thus, the Crystal methods would not apply to distributed or offshore teams for which Cockburn offers no recommendation other than to locate the team together at one location.

Rules that are common to all the Crystal Methods
  • The project must use incremental development with increments of four months or less with a string preference of one to three months
  • The team must hold both pre- and post- reflection with a strong preference for mid-project reflection workshops

How to choose methodology?

What the best model is varies from project to project, but the creation of new models for software development that can strike a balance between extremes is an open question. The essential points you’ll need to consider when selecting a methodology are:

  • Budget
  • Team size
  • Project criticality
  • Technology used
  • Documentation
  • Training
  • Best practices/lesions learned
  • Tools and techniques
  • Existing processes
  • Software

When to Avoid the Agile Methodology

Some situations should avoid Agile Methodology if...

  • You have to formally document the requirements, design, code, and testing cases during each phase of the software life cycle.

This is usually the case when building an infrastructure application, rather than an application that supports a changeable business process. Infrastructure applications support an entire business unit over a long ROI period, with repeated updates and enhancements expected. These applications are likely to be managed by successive generations of application owners, who will need to inherit documentation from their predecessors, maintain it, and pass it on their successors.

  • Deliverables must pass through a chain of approvals and tollgates

Approvals and tollgates are mini-bottlenecks that can slow the momentum of a project, momentum that agile methods are supposed to support. Applications that require phase-end reviews or reviews of major deliverables by senior management, by a PMO, or even an Audit Committee may or may not be candidates for agile methods. Of course, the flip side to this is that agile methods can also help recover momentum lost to approvals and tollgates.

  • You have tools to create the software models but not to translate them to the low end software code.

Model-driven development tools that can generate code are proliferating, but the skills necessary to use them effectively are still relatively scarce. Unless you have both the tools AND the skills available, agile methods that depend on such tools need to be approached with caution.

  • You need to follow traditional Software management processes and Procedures.

"Traditional" usually means "comfortable". If the business sponsor and users are uncomfortable with anything but traditional ways of developing software, and remain unmoved by the value proposition for agile methods, don't bother.

  • Application users are NOT always accessible to you.

Agile management depends on an effective, day-to-day working partnership between the development team, the sponsor, and empowered users. If this partnership does not exist, or is likely to be weak, an agile project will face much higher risks than it should.

Conclusion

Agile methods demand that the customer is involved throughout; the customer is part of the team. It makes sense for the customer to want to be deeply involved in the product you are making them, however, there are a myriad of real world reasons why it might not be possible. With any process you deploy to solve a problem customer buy in is critical… The customer must understand what is required of them and be committed to deliver on that requirement. This cannot be forced and any attempts to make a customer buy into agile will result in difficulty. Sometimes, upfront analysis might just have to do...
It is possible to run an agile project on a fixed priced or time and materials basis. However, in both cases for the project to be agile the scope must be flexible. If the project is fixed scope, there is no benefit from using agile methods. If it’s fixed scope then more than likely the requirements will form part of the contract and thus be well defined (through upfront analysis). The point of agile is to allow change such that the developers are delivering software that will be used by the customer, essentially reduce the scary waste of 45% of functionality not being used!
Heavyweight methodologies sometimes that can be a better choice,for example that you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.Since heavyweight methodologies require documentation at every stage this will help better understanding of the requirements the project. So we conclude that no one model is necessarily better or worse than another. As always the selection of a particular model is correct only in the context of the organization or the product under development. Correct selection is to a great degree dependant on having a clear understanding of the groups and types of development models. This is of further importance given that it's highly unlikely that any organization will follow a model strictly. Most organizations will opt to use a hybrid form that fits the capabilities of their staff and meets the needs of their business.

References



Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch6_6e_zj&oldid=56000"