Software Development Process

Software Development Process
By: Amira Elsayed Ismail

Agenda
Introduction
Adaptive vs. Predictive software development
Traditional Software development process
Waterfall model
Iterative Incremental Model
Spiral Model
Agile Software development process
Extreme Programming Model
SCRUM Model
Conclusion

Introduction
Software Development process (lifecycle)
Is a structure imposed on the development of a software product

Introduction (cont’d)

Adaptive vs. Predictive
Adaptive methods focus on adapting quickly to change
When the project requirement change the adapted team also change
An adaptive team can not report exactly what tasks are being done next week
An Example of adaptive methods is Agile

Adaptive vs. Predictive (cont’d)
Predictive method focus on planning the future in details
Predictive team can report exactly what features and tasks are planned for the entire length of the development process
Predictive team have difficulty changing direction, the plan is typically optimized for the original destination and changing direction can require completed work to be started over

Traditional software development Methods
Waterfall
Clean Room
DSDM (Dynamic System Development Method)
Iterative Incremental
RAD (Rapid Application Development)
RUP (Rational Unified Process)
Spiral
V-Model
FDD (Feature Driven Development)

Waterfall Model
Is a sequential design process, often used in software development processes
Originates in the manufacturing and construction industries; highly structured physical environments
The Idea behind the waterfall model is
“Measure Twice, Cut once”

Waterfal Model (cont’d)
Waterfall Model Phases :

Waterfall Model (cont’d)

Why Waterfall
Provides a structured approach, it progress linearly, easily, understandable and explainable
Provides easily markable milestones in the development process
Suites the stable, unchanging requirements

Why not Waterfall
Many people think that waterfall model is a bad idea in practice
It is impossible for any project to finish a phase of a software products lifecycle perfectly before moving to the next phase
Client may not know exactly what requirements he need and he will need to change his requirements at any time

Why not Waterfall
Designers may not be aware of future Implementation

Why not Waterfall
Stockholders may not be fully aware of the capabilities of the technology being implemented

Iterative & Incremental development
Developed in response to the weaknesses of the waterfall model
Starts with initial planning and ends with deployment with the cycle interactions in between
Iterative & incremental development is essential parts of the extreme programming & generally the Agile Development
The project is delivered through cross discipline work from the requirement to the deployment

Iterative & Incremental development (cont’d)
Initial Planning
Deployment

The basic idea is to develop a system through repeated cycles (Iterative) and in smaller portions at a time (Incremental)
Allowing developers to take advantage of what was learned during the development of earlier portions
Start with simple implementation of a subset of the software requirements and iteratively enhance the evolving version until the full system is implemented
At each iteration, design modifications are made and new functional capabilities are added

Implementation Guidelines
Any difficulty in design, coding & testing means the need of redesign and modification
Modifications should fit easily isolated and easy to find modules
The existing implementation should be analyzed frequently to determine how well it measures up to project goals

Spiral Model (cont’d)
The spiral model was defined by Barry Boehm
This model was not the first model to discuss iteration, but it was the first model to explain why the iteration matters
aims at risk reduction by any means in any phase. The spiral model is often referred to as a risk-driven model
Introducing prototyping in a Software Process aims at risk reduction at the requirements level
There is always an element of risk involved in the other phases of development

Quadrant 1
Determining objectives of that phase, alternatives and constraints
This is a way to define a strategy for achieving the goals of this iteration
Quadrant 2
The strategy is analyzed form the viewpoint of risk, and solutions to minimize these risks are investigated

Quadrant 3
A solution is put into practice to produce the artifacts necessary to reach the goals identified in quadrant 1
Quadrant 4
The results of the risk-reduction strategies are assessed, and if all risks are resolved, the next phase is planned and started
If some risks are left unsolved, another iteration can be made to continue to work

Advantages
Emphasis on alternatives and constraints supports the reuse of existing solutions.
Targets testing by treating it as a risk, which has to be addressed.
Maintenance is just another phase of the spiral model. It is treated in the same way as development.
Estimates (budget and schedule) get more realistic as work progresses, because important issues are discovered earlier.

Disadvantages
Only intended for internal projects (inside a company), because risk is assessed as the project is developed.
In case of external software development, all risk analysis must be performed by both client and developers before the contract is signed
Spiral model is risk driven. Therefore it requires knowledgeable staff.
Suitable for only large scale software development.

Agile software development
Group of software development methodologies based on iterative and incremental development
Requirements and solutions evolve through collaboration between self organizing, cross functional teams
Introduced in 2001
It’s a light weight as a reaction against the heavy weight methods

Agile software development Methods
SCRUM (1995)
Crystal clear
Extreme Programming (1996)
Adaptive software development
Feature driven development
Dynamic system development method (1995)
Open source software development

Agile software development Methods (cont’d)
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping other to do
Agile Values
Individuals & interactions over process & tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile Principles
Customer satisfaction by rapid delivery of useful software

Agile Principles
Welcome changing requirements even late in development

Agile Principles
Working software is the principal measure of progress

Agile Principles
Daily cooperation between business people & developers

Agile Principles
Face to Face conversation is the best form of communication

Agile Principles
Self-organized team that have motivated and trusted individuals

Characteristics
Break tasks into small increments with minimal planning
Iteration are short time frames from (1  4) weeks
Each iteration involves a team working through a full software development cycle
By the end of the iteration a demo will be represented to stack holders
One iteration may not add enough feature to market release but the goal is to have a release with minimal bugs

Characteristics
Team is usually cross functional and self organizing
Team member take the responsibility of the task
Face-to-face conversation for team in the same location and video for different locations that produce less written documents
All team working in an open office called (bullpen)
Small team size from (5  9) person

Characteristics
Each team have a customer representative to answer mid iteration problems
By the end of the iteration stockholders view demo and re evaluate the priorities of features
Formal daily face to face communications to answer three questions (what they did the previous day? What they intend to do today? What their road blocks?)

Techniques to improve the quality and agility of project like:
Unit test
Pair programming
Test driven Development
Domain Driven Design
Code refactoring

SCRUM Model
Its one of the agile development methods
It’s the skeleton that includes a set of practices and predefined roles

SCRUM Model (cont’d)

Pig role
The ones committed to the project in the scrum process
Chicken role
Not a part of the scrum process but must be taken into account

Product Owner
Represent the voice of the customer
Ensure that the scrum teams works with the write things from a business perspective
Write user stories, prioritize them and add them to product backlog

SCRUM Master
Help the team to deliver the sprint goal
Is not the leader of the team but he is self organizer
Ensure that the SCRUM process is used as intended
He is the enforcer of rules

Team
Deliver the project
Made up of (5  9) people with cross functional to do the actual work (Developers, Designers, Testers)

Users
The users of the product, and his participation is very important for feedback to review and plan sprint
Stockholders
The people who enable the project and the are important in sprint review
Managers
People who will set up the environment for the product

Requirements
User
Product
Owner
Product
backlog
Meeting
Sprint
backlog
Team

Sprint
(2  4) week period and it is decided by team
In the sprint the team create an increment of usable software
During the sprint no one can change the sprint backlog

Product Backlog
High level document of the entire project that include a broad description of all required features and wish list items
Prioritized by business value of each feature
Editable by anyone
Contains rough estimates of both business value (product owner )and development effort (team members)

Burn down
The burn down chart is publically showing remaining work in the sprint backlog
Updated every day
Give a simple view of the sprint progress

Sprint Backlog
Features are broken down into tasks
Best practice that tasks are normally estimated between 4h and 16h
The whole team understand exactly the business logic of each task
Any one them can pick task from task list, tasks in the task list are never assigned

Daily SCRUM Meeting
Project status meeting
Starts precisely on time. And there is a punishment for late
All are welcomed but only pig may speak
The meeting is between (15 - 20) minutes
All attendees should stand to make it short
Happen in the same time, same location every day

Daily SCRUM Meeting
Every one should answer three questions
What have you done since yesterday?
What are you planning to do today?
Do you have any problem preventing you from accomplish your goal?

Sprint Planning Meeting
Hold at the beginning of each sprint
Decide what work is to be done
Prepare the sprint backlog
8 hour limits

Sprint review meeting
Hold at the end of the sprint
Review the complete and incomplete work
Present the completed work to stockholders
4 hour limits

Sprint Retrospective meeting
All team members reflects on the past sprint
Every member should answer
What went well during the sprint?
What could be improved in the next sprint

Extereme Programming
Intended to improve software quality and responsiveness to changing customer requirements
Intended to improve productivity and introduce checkpoints where new customer requirements can be adopted
Programming in pairs or doing extensive code review
Unit testing of all code (End of day testing)
Avoiding programming of features until they are actually needed
Simplicity and clarity in code
Expecting changes in the customer's requirements
Frequent communication with the customer and among programmers

ExteremeProgramming (cont’d)

Concepts
Organizes people to produce higher quality software more productively
Attempts to reduce the cost of change by having multiple short development cycles, rather than one long one
Introduces a number of basic values, principles and practices on top of the agile programming framework

Coding
Software instructions a computer can interpret. Without code, there is no working product
Coding can also be used to figure out the most suitable solution
Coding can also help to communicate thoughts about programming problems
Code must be always clear and concise and cannot be interpreted in more than one way
Other programmers can give feedback on this code by also coding their thoughts

Testing
if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws
Unit tests
determine whether a given feature works as intended.
writes as many automated tests as they can think of that might "break" the code
if all tests run successfully, then the coding is complete.
Acceptance tests
verify that the requirements as understood by the programmers satisfy the customer's actual requirements.

Designing
The system becomes too complex and the dependencies within the system cease to be clear
Avoid this by creating a design structure that organizes the logic in the system
Good design will avoid lots of dependencies within a system

Listening
Programmers must listen to what the customers need the system to do
They must understand business logic needs well enough to give the customer feedback about the technical aspects of how the problem might be solved

Communication
This task is accomplished through documentation
The goal is to give all developers a shared view of the system which matches the view held by the users of the system
extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback

Simplicity
Encourages starting with the simplest solution
the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month
This is sometimes summed up as the "you aren't gonna need it" (YAGNI) approach
Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed
A simple design with very simple code could be easily understood by most programmers in the team

Feedback
Feedback from the system: by writing unit tests or running periodic integration tests
Feedback from the customer: The functional tests (acceptance tests) are written by the customer and the testers
Feedback from the team: When customers come up with new requirements the team directly gives an estimation of the time that it will take to implement

Courage
Courage enables developers to feel comfortable with refactoring their code when necessary
This means reviewing the existing system and modifying it so that future changes can be implemented more easily
courage to remove source code that is obsolete, no matter how much effort was used to create that source code

Respect
The respect value includes respect for others as well as self-respect
Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers
Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring

Rules
Business people and developers do joint work
Our highest priority is customer satisfaction
Deliver working software frequently
Working software
Global awareness
The team must act as an effective social network

http://a-elsayed2010.blogspot.com	82
http://a-elsayed2010.blogspot.in	5
http://a-elsayed2010.blogspot.com.ar	1
http://a-elsayed2010.blogspot.com.es	1

Software Development Process

by Amira Ismail

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 89

Statistics

Software Development Process Presentation Transcript