An Agile Process

LECTURE 2

History – the Agile Manifesto

2001 – Kent Beck and 16 other noted software developers, writers and consultants (referred to as “Agile Alliance”) signed the “Manifesto for Agile Software Development.”

Agile methods –developed to overcome perceived and actual weaknesses in conventional software engineering.

It can provide important benefits, but is not applicable to all projects, product, people, and situations.

 

Manifesto Defined

 

MANIFESTO. A solemn declaration, by the constituted authorities of a nation, which contains the reasons for its public acts towards another.

-Dictionary.net

 

  Manifesto for Agile Software Development

 

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on the right, we value the items on the left more

What is Agility?

 

Agility has become today’s buzzword when describing a modern software process. An agile team is a team able to appropriately respond to changes.

Changes:

• Software being built
• Team members
• New technology

All kinds that have an impact on the product built, or project that creates the product.

 12 Principles for those who want to achieve agility

 

What is an Agile Software Process?

Characterized by 3 Key Assumptions about the majority of software projects:

It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as project proceeds.

For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.

Analysis, design, construction and testing are not as predictable (from a planning point of view) as we might like.

How do we create a process that can manage unpredictability?

Process adaptability (to rapidly changing project and technical conditions)

An Agile process must be adaptable.

 It must adapt incrementally.

• Requires feedback – incremental development strategy should be instituted
• Software increments must be delivered in short time periods for adaptation to keep pace with change.
• This iterative approach enables the customer to

                          evaluate the software increment regularly, provide necessary feedback to the software team and influence the process adaptations that are made to accommodate the feedback.

Human Factors Needed in Agile Process

• Competence
• Common Focus
• Collaboration
• Decision-making ability
• Fuzzy problem-solving ability
• Mutual trust and respect
• Self-organization

Competence

Innate talent, specific software related skills & overall knowledge of the process that the team has chosen to apply.

Skills and knowledge of the process can and should be taught to all member of the team

Common Focus

Members of the team should be focused on one goal even if they are performing different tasks and bringing different skills to the project.

Goal: To deliver a working software increment to the customer within the time promised

Collaboration

 

Team members must collaborate with one another, with the customer and with business managers

Decision-making Ability

The team is given autonomy –decision-making authority for both technical and project issues.

Fuzzy Problem-Solving Ability

Agile team will continually have to deal with ambiguity and change

They have to accept that the problem they are solving today may not be the problem that needs to be solved tomorrow.

Mutual Trust and Respect
 
Should exhibit trust and respect that are necessary to make them “so strongly knit that the whole is greater than the sum of the parts” - DeMarco
 

Self-Organization
 
Implies three things:  

1. Organizes itself for the work to be done.
2. Organizes the process to best accommodate it local environment
3. Organizes the work schedule to best achieve delivery of the software increment.

Videos on Waterfall and Spiral Model

Waterfall Model

Spiral Model

Software Engineering Fundamentals

What is Software Engineering?

• is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

Engineering

• is the science, discipline, art and profession of acquiring and applying technical, scientific and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or inventions.

Software Engineering’s Focus

• To solve problems

2 Parts

1. Analysis – breaking it into pieces that we can understand and try to deal with.
2. Synthesis – putting together of a large structure from small building blocks.

Analysis and Synthesis

Software Engineering Layers

• Layers according to Roger Pressman

• Process layer is the foundation
• Methods provide the technical “how-to’s” for building software
• Tools provide automated or semi automated support for the process and methods.

Relationship between Computer Science and Software Engineering

Generic Process Framework

Used as a basis for process models and is applicable to the vast majority of software projects:

• Communication -collaboration with customer & other stakeholders
• Planning- description of the tasks to be conducted, risks, resources required, work products to be produced.
• Modeling –creation of models
• Construction – code generation and testing
• Deployment – delivered to the customer

What is a Process Model?

• Originally proposed to bring order to the chaos of software development
• Useful to software engineering work and an effective roadmap for software teams
• Define a distinct set of activities, actions, tasks, milestones and work products that are required to engineer high-quality software.

Problems with Waterfall Model

1. Real projects rarely follow the sequential flow that the model proposes.
2. It is difficult for the customer to state all requirements explicitly.
3. Working version of the program will not be available until late in the project time-span.

Problems with Incremental Model

• Each additional build has to be incorporated into the existing structure without degrading the quality of what has been build to date.
• The incremental models can easily degenerate into the build and fix approach.
• Design errors become part of the system and are hard to remove.
• Clients see possibilities and want to change requirements.

Rapid Application Development (RAD) Model

• An incremental process model that emphasizes short development cycle
• “High-speed” adaptation of the waterfall model.

Drawbacks of RAD

1. For large projects, RAD requires sufficient human resources to create the right number of RAD teams.
2. If developers & customers are not committed to rapid-fire activities, RAD projects will fail.
3. If the system cannot be properly modularized, building the components will be problematic
4. If high-performance is an issue, RAD may not work.
5. RAD may be inappropriate when technical risks are high.

Prototyping Model

• Assists the software engineer and the customer to better understand what is to be built when requirements are fuzzy.

Drawback of Prototyping Model

Customer sees what appears to be a working version of the software and presumes that it is the final thing.

The developer often makes implementation compromises in order to get a prototype working quickly.

Spiral Model

• It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.
• Proposed by Boehm

Drawbacks of the Spiral Model

• It may be difficult to convince customers that the evolutionary approach is controllable.
• It demands risk assessment expertise and relies on this expertise for success.
• If a major risk is uncovered and managed, problems will occur.

Top 3 Answers in "A Failed Project" question

 For those who attempted to answer the given question, thank you very much for your effort.

Here are the Best Answers, in sequential order:

1. 061308 Syeda Mehnoor Rafaie
2. 061306 Sahar Qureshi
3. 071319 Syed Mehdi

Congratulations and keep it up!

A Failed Project

Tacoma Narrows Bridge collapse in 1940. It is one of the classic civil engineering project failure: there were aerodynamic problems, and there were structural problems due to the size of the supports, and there were other problems that combined to cause a distinctive resonance which gave the bridge its distinctive “gallop.”

But one of the most important lessons we took away from the bridge collapse isn’t technical. It has to do with the designer.

According to Eldridge, “eastern consulting engineers” petitioned the PWA and the Reconstruction Finance Corporation (RFC) to build the bridge for less, about which Eldridge meant the renowned New York bridge engineer Leon Moisseiff, designer and consultant engineer of the Golden Gate Bridge. Moisseiff proposed shallower supports—girders 8 feet (2.4 m) deep. His approach meant a slimmer, more elegant design and reduced construction costs compared to the Highway Department design. Moisseiff’s design won out, inasmuch as the other proposal was considered to be too expensive. On June 23, 1938, the PWA approved nearly $6 million for the Tacoma Narrows Bridge. Another $1.6 million was to be collected from tolls to cover the total $8 million cost.

There was plenty of warning from many people in the civil engineering community who didn’t think this design would work. But these warnings were dismissed. After all, this was designed by the guy who designed the Golden Gate Bridge! With credentials like that, how could he possibly be wrong? And who are you, without those credentials, to question him? The pointy-haired bosses and bean counters won out. Predictably, their victory was temporary. Incidentally, some people refer to this as one kind of halo effect: a person’s past accomplishments give others undue confidence in his performance at a different job, whether or not he’s actually doing it well. It’s a nasty little problem, and it’s a really common root cause of project failure, especially on software projects.

Lesson to learn from this disaster:

When you look at the various root causes—problematic design, cocky designer, improper materials—one thing is pretty clear. The Tacoma Narrows Bridge was a failure before the first yard of concrete was poured. Failure was designed into the blueprints and materials, and even the most perfect construction would fail if it used them.

QUESTION: What lessons have you learned from this disaster that you can apply in Software Engineering? (post your answer as comment in this page before September 18, 2009)

source: http://www.stellman-greene.com/2009/07/24/taking-stock-of-a-failed-project/