software engineering and project management 3rd module ppt presenetation

Module-3
Chapter-1
AGILE DEVELOPMENT

 1. WHAT IS AGILITY?
 Modern software development process.
 Agility means effective (rapid and adaptive) response
 to change by having effective communication among all stockholders.
 Iterative and incremental approach.
 Agile team respond to changes in the software development.
 delivering a working product quickly and frequently.
 It involves close collaboration between the development team and the
customer to ensure that the product meets their needs and expectations.

2. AGILITY AND THE COST OF CHANGE
 Easy to accommodate a change when a team is gathering requirements
early in a project.
 Costs of doing this work for the changes are minimal.
 Agile process may “flatten” the cost of change curve by coupling
Incremental delivery with agile practices such as continuous unit testing
and pair programming.

3. WHAT IS AN AGILE PROCESS
 Agility principles
 The Politics of Agile Development
 Human Factors
AGILE PROCESS
 "Agile Process Model" refers to a software development approach based on
iterative development.
 Agile methods break tasks into smaller iterations, or parts do not directly
involve long term planning.

Agility principles
The Agile Alliance defines 12 agility principles for those who want to achieve
agility:
1. Highest priority is to satisfy the customer.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals.
6. The most efficient and effective method of conveying information.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity
11. The best architectures, requirements, and designs emerge from self–
organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

THE POLITICS OF AGILE DEVELOPMENT
 There is consider able debate about the benefits and
applicability of agile software development as opposed to
more conventional software engineering process.
 Traditional methodologists are a bunch of stick-in-the- mud s
who’d rather produce flawless documentation than a working
system that meets business needs.

HUMAN FACTORS
 Competence: Individuals skills included in work.
 Common focus: commitment toward goal.
 Collaboration: working together.
 Decision-making ability: making timely decisions.
 Fuzzy problem-solving ability: capability to handle complex and
different problems.
 Mutual trust and respect: valuing each others contribution.
 Self-organization: ability of managing themselves in the work.

EXTREME PROGRAMMING (XP)
 XP Values
 XP Process
 Industrial XP(IXP)
 The XP Debate
 The most widely used agile process.
 proposed by Kent Beck.
 XP is lightweight, efficient, low-risk, flexible way to develop the software.
 Used by small and medium sized teams that work under rapidly changing
requirements.
 A variant of XP, called Industrial XP (IXP)

XP VALUES
A set of five values that establish a foundation for all work performed as part
of XP.
 Communication: clear and constant
 Simplicity: simplest solution.
 Feedback: frequent feedback.
 Courage: to make necessary changes.
 Respect: each others work.

XP PROCESS
Four framework activities: planning, design, coding, and testing.

XP Planning:
 Begins with the creation of “user stories”
 Agile team assesses each story and assigns a cost.
 Stories are grouped to for a deliverable increment.
 A commitment is made on delivery date.
 After the first increment “project velocity” is used to help define
subsequent delivery dates for other increments.
XP Design:
 Follows the KIS(Keep it simple) principle.
 Encourage the use of CRC cards (class responsibility collaborator).
 For difficult design problems, suggests the creation of “spike solutions”,a
design prototype

XP Coding:
 Recommends the construction of a unit test for a store before coding
commences.
 Encourages “pair programming”.
 Pair Programming: Two people work together at one computer workstation
to create code for a story.
 Encourages “refactoring”—an iterative refinement of the internal program
design
 Refactoring : Improves the internal structure of the code but external
behavior not affected.
XP Testing:
 All unit tests are executed daily.
 “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality.

INDUSTRIAL XP
 It is a expanded role for customers, and upgraded technical practices.”
 IXP incorporates six new practices that are designed to help ensure that an XP
project works successfully for significant projects within a large organization.
1. Readiness assessment: Before starting project evaluate team skill,
organizational support and project complexity.
2. Retrospectives: Regular checking to find out the improvement.
3. Continuous learning: Encouraging learning for improvement.
4. Project community : Built stakeholders community for strong connection.
5. Project chartering: Establishing clear vision, goals and constrains.
6. Test-driven management : To improve code quality

THE XP DEBATE
Among the issues that continue to trouble some critics of XP are:
 Requirements volatility: frequent changes in requirement disrupt the
development process.
 Conflicting customer need: due to different stakeholders requirements it is
difficult to prioritize.
 Requirements are expressed informally: through conversation instead of
formal documentation.
 Lack of formal design: lead to poor architecture and maintainability.

5. OTHER AGILE PROCESS MODELS
1. Adaptive Software Development (ASD)
2. Scrum
3. Dynamic Systems Development Method (DSDM)
4. Crystal
5. Feature Drive Development (FDD)
6. Lean Software Development (LSD)
7. Agile Modeling (AM)
8. Agile Unified Process (AUP)

ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
 Technique for building complex software and systems.
 ASD focus on human collaboration and team self- organization.
ASD features:
 Mission-driven planning: work on customer mission.
 Component-based focus: modularity approach.
 Uses “time-boxing”: fixing the time.
 Explicit consideration of risks: identifying and managing risk.
 Emphasizes collaboration for requirements gathering: involve all
stakeholders to refine requirements.
 Emphasizes “learning” throughout the process: continuous learning and
feedback to improve process and product.

ASD “life cycle” incorporates three phase:
 Speculation
 Collaboration
 Learning

Speculation :
 Here the project is initiated plan is conducted.
 planning uses project initiation information:
 the customer’s mission statement,
 project constraints (e.g., delivery dates or user descriptions),
 and basic requirements.
Collaboration:
It encompasses communication and teamwork,
it also emphasizes individualism, because individual creativity plays an
important role in collaborative thinking. It is, a matter of trust.
People working together must trust one another to
 criticize without disliking it,
 assist without offence,
 work as hard as or harder than they do,
 have the skill set to contribute to the work at hand, and
 communicate problems or concerns in a way that leads to effective action.

Learning:
 It will help team members to improve their level of real
understanding.
 ASD teams learn in three ways: focus groups, technical
reviews and project analyses.

SCRUM
 Scrum features
 Popular method.
 Development work is partitioned into “packets”.
 Lightweight, incremental and iterative.
 Testing and documentation are on-going as the product is constructed.
 Work occurs in “sprints” and is derived from a “backlog” of existing
requirements.
 Meetings are very short and sometimes conducted without chairs.
 “demos” are delivered to the customer with the time-box allocated.
It incorporates the following framework activities:
 Requirements
 Analysis
 Design
 Evolution
 Delivery.

Roles:
The Scrum Team consists of three roles, namely
 A Scrum Master,
 A Product Owner, and
 The Team.
The Product : Manages the Product Backlog and ensure team will work on it.
Scrum Master:
 He/she is responsible for making the process run smoothly,
 removing obstacles that impact productivity,
 organizing and facilitating the critical meetings.
Team:the team comprises of analysts, designers, developers, testers, etc.
as appropriate and as relevant to the project. Size of the team should be 5-9
members.

The vital events of scrum are:
 The Sprint: Time limit.
 Sprint planning: work to be performed.
 Daily Scrum Meetings: 15-minute time-boxed event for the Scrum Team to
synchronize the activities and create a plan for that day
 Questions to be answered by team members during meeting.
 What did you do since the last team meeting?
 What obstacles are you encountering?
 What do you plan to accomplish by the next team meeting?
 The Sprint Review: to inspect the Increment and make changes to the Product
Backlog, if needed.
 The Sprint Retrospective: occurs after the Sprint Review and prior to the next Sprint
Planning.
 the Scrum Team is to inspect itself and create a plan for improvements to be enacted
during the subsequent Sprint.

TERMINOLOGIES
Sprint: Within each framework activity, work tasks occur within a process
pattern called a sprint.
Backlog: a prioritized list of project.
Product Backlog: entire requirement list.
Sprint Backlog: The Sprint Backlog is the set of Product Backlog items
selected for the Sprint.
Demos: deliver the software increment to the customer so that functionality
that has been implemented can be demonstrated and evaluated by the
customer.

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)/ATERN
 It is an Agile software development approach.
 “Provides a framework for building and maintaining systems which meet
tight time constraints through the use of incremental prototyping in a
controlled project environment”
 The DSDM philosophy is borrowed from a modified version of the Pareto
principle: 80 percent of an application can be delivered in 20 percent of the
time it would take to deliver the complete (100 percent) application.
 Effort=20% and result= 80%
 Mainly focus on 80% of work.

GUIDING PRINCIPLES OF DSDM
 Active user involvement is imperative. DSDM teams must be empowered
to make decisions.
 The focus is on frequent delivery of products.
 Fitness for business purpose is the essential criterion for acceptance of
deliverables.
 Iterative and incremental development is necessary to converge on an
accurate business solution.
 All changes during development are reversible.
 Requirements are baseline at a high level.

DSDM life cycle that defines three different iterative cycles, preceded by
two additional life cycle activities:
 Feasibility study: establishing basic requirements and constraints.
 Business study: Identifies functional and non-functional requirements.
 Functional Model Iteration: producing incremental prototypes and
demonstrating to customer.
 Design and build iteration: Revisit prototypes built during the functional
model iteration to ensure incorporation.
 Implementation: place latest software increment into operation.

 CRYSTAL
 Proposed by Cockburn and Highsmith
 Crystal used for distinguishing features.
 It is resource-limited, cooperative game of invention and communication,
means working together creatively and sharing ideas while dealing with
limited resources.
 Face-to-face communication is emphasized
 Suggests the use of “reflection workshops” to review the work habits of the
team : look back to work progress

 It places focus on people over processes rather than strictly adhering to
predefined processes and tools.
 Crystal recognizes that different teams will perform differently depending on
team size, criticality and priority of the project and encourages users to adapt
the framework for their individual situation.
 Crystal is actually comprised of a family of agile methodologies such as Crystal
Clear, Crystal Yellow, Crystal Orange and others.
 These are categorized by color, according to the number of people in the
project;
 Crystal Clear - Teams with less than 8 people
 Crystal Yellow - Teams with between 10 and 20 people
 Crystal Orange - Teams with between 20-50 people
 Crystal Red - Teams with between 50-100 people

Crystal Clear - Teams with less than 8 people
 Lightweight and simple,
 Face to face communication,
 Frequent deliveries, regular workshop and min documentation.
Crystal Yellow - Teams with between 10 and 20 people
 More structured than crystal clear,
 Daily standups, code reviews and testing,
 More documentation,
 Formal communication channel.
Crystal Orange - Teams with between 20-50 people
 More defined processes and roles,
 Inter-team communication and coordination,
 Regular delivery,
 Risk management,
 Comprehensive documentation.
Crystal Red - Teams with between 50-100 people
 High structured process with rigorous documentation,
 Quality assurance,
 Strong emphasis on risk management,
 Detailed project planning,
 frequent integration and testing.

Key Principles of the Crystal Framework:
 Frequent Delivery: delivering the code frequently.
 Reflective Improvement: Look back on what you've done, how you've
done it and why to improve future.
 Osmotic Communication: co-location (having teams in the same physical
space) is critical.
 Personal Safety: Team members should feel safe to discuss ideas openly,
without fear . There are no wrong answers or bad suggestions in a Crystal
team.
 Focus on Work: Team members should know what to work on next and
be able to do it.
 Access to Subject Matter Experts and Users: Team members should be
able to get feedback from real users and experts when required.
 Technical Tooling: Teams should have access to tooling's like continuous
deployment, automated testing and configuration management.

FEATURE DRIVEN DEVELOPMENT
Originally proposed by Peter Coad is a model for object oriented software
engineering.
FDD adopts a philosophy that:
 Emphasizes collaboration among people on an FDD team.
 Manages problem and project complexity using feature-based decomposition
followed by the integration of software increments.
 Communication of technical detail using verbal, graphical, and text-based means.
 FDD used for distinguishing the features.
 A feature “is a client-valued function that can be implemented in two weeks or
less.”
 Uses a feature template
 <action>the <result>
Examples of features for an e-commerce application might be:
Making a product sale is a feature.
Then the feature set would include:
 Add the product to shopping cart
 Display the technical-specifications of the product
 Store the shipping-information for the customer

Breaking down the project into a list of features
Example
 User registration
 User login
 Browse products by category
 Search products
 Add products to cart
 View cart
 Remove product
 Checkout
 Payment
 Order confirmation
 Order tracking.

LEAN SOFTWARE DEVELOPMENT (LSD)
Lean Software Development (LSD) is an agile framework based on:
 optimizing development time and resources,
 eliminating waste,
 and ultimately delivering only what the product needs.
Goal
Is to delivering valuable features and products as quickly and effectively as
possible.
LSD process can be summarized as:
 eliminate waste,
 build quality in,
 create knowledge,
 Stay for commitment,
 deliver fast,
 respect people, and optimize the whole.

Example of Eliminate waste:
 adding no extraneous features or functions,
 assessing the cost and schedule impact of any newly requested requirement,
 removing any superfluous process steps,
 establishing mechanisms to improve the way team members find
information,
 ensuring the testing finds as many errors as possible,
 reducing the time required to request and get a decision that affects the
software or the process that is applied to create it, and
 streamlining the manner in which information is transmitted to all
stakeholders involved in the process.

AGILE MODELING (AM)
 Agile Modeling (AM) is a practice-based methodology
 for effective modeling and documentation
 It is a collection of values, principles, and practices for modeling software
that can be applied on a software development project in an effective and light-
weight manner.
AM suggests a wide array of “core” and “supplementary” modeling
principles:
 Model with a purpose: A developer who uses AM should have a specific goal
before creating the model
 Use multiple models: when multiple models used it should provide value to
their intended audience should be used.
 Travel light: keeping only those models that will provide long-term value and
discard the rest.
 Content is more important than representation: Modeling should impart
information to its intended audience.
 Know the models and the tools you use to create them: Understand the
strengths and weaknesses of each model and the tools that are used to create it.
 Adapt locally: The modeling approach should be adapted to the needs of the
agile team.

AGILE UNIFIED PROCESS (AUP)
 AUP adopts a “serial in the large” and “iterative in the
small” philosophy for building computer-based systems.
 Classic UP phased activities are inception, elaboration,
construction, and transition.
 AUP provides a serial overlay i.e., a linear sequence of
software engineering activities.
 It enables a team to visualize the overall process flow for a
software project.

Each AUP iteration addresses the following activities :
 Modeling: UML representations of the business and problem
domains. It should be “just barely good enough”.
 Implementation: Models are translated into source code.
 Testing: Series of tests to uncover errors and to ensure that
the source code meets its requirements.
 Deployment: software delivery and feedback.
 Configuration and project management: controlling the
work products that are produced by the team.
 Project management tracks and controls the progress of the
team and coordinates team activities.
 Environment management : It coordinates a process
infrastructure that includes standards, tools, and other support
technology available to the team.

A TOOL SET FOR THE AGILE PROCESS
 There are many different types of Agile tools out there.
 Some are free, some are paid.
 Some tools that support end-to-end flow of software
development life cycle including requirements
management, test management, defect tracking.
Different tools:
 Social tools: starting even at the hiring stage. e.g.,
linkedln
 Technological tools: teams simulate being physically
present. e.g.., virtual meetings.
 Physical tools: allowing people to manipulate them
directly for better interaction. e.g., sticky notes.

CHAPTER-2
PRINCIPLES THAT GUIDE PRACTICE
1. SOFTWARE ENGINEERING KNOWLEDGE
 Many software practitioners often think software engineering knowledge is
just about knowing specific technologies like Java, Perl, HTML, C, and
Linux.
 People often say that software development knowledge has a "three-year
half-life," meaning that half of what you know today will be outdated in
three years.
 This is true for technology-related knowledge, where new tools and
languages quickly replace old ones.
 However, there's another type of software development knowledge called
"software engineering principles" that does not become outdated so
quickly.
 These principles can help a professional programmer throughout their
entire career.

2. CORE PRINCIPLES
General principles that span software engineering process and practice:
1. Provide value to end users,
2. Keep it simple,
3. Maintain the vision (of the product and the project),
4. Recognize that others consume (and must understand) what you produce,
5. Be open to the future,
6. Plan ahead for reuse, and
7. Think!

 Set of core principles can be applied to the framework, and by
extension, to every software process:
 Principle 1: Be agile. Improve software incrementally.
 Principle 2: Focus on quality at every step. Proper testing & ensure it
meet requirements.
 Principle 3: Be ready to adapt. Open to new tools.
 Principle 4: Build an effective team. To enhance productivity.
 Principle 5: Establish mechanisms for communication and
coordination. Clear communication and coordination.
 Principle 6: Manage Change. Handling changes smoothly
 Principle 7: Assess risk. Identify and evaluate risk.
 Principle 8: Create work products that provide value for others.

3. PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY.
 Communication Principles [10]
 Planning Principles [10]
 Modeling Principles [10]
 a) Requirements Modeling Principles [5]
 b) Design Modeling Principles [5]
 Construction Principles
 a) Preparation Principles [5]
 b) Programming Principles [9]
 c) Validation Principles [3]
 Testing Principles [5]
 Deployment Principles [5]

1. Communication Principles
Principle1. Listen.
Principle2. Prepare before you communicate. Spend the time to understand
the problem.
Principle3. Someone should facilitate the activity. E.g. leader for
communication.
Principle4. Face-to-face communication is best.
Principle5. Take notes and document decisions.
Principle6. Strive for collaboration. Team formation
Principle7. Stay focused, modularize your discussion. If more people for
communication, topic may bounce.
Principle8. If something is unclear, draw a picture.
Principle9.
a. Once you agree to something, move on;
b. If you can’t agree to something, move on;
c. If a feature or function is unclear and cannot be clarified at the
moment, move on.
Principle10. Negotiation is not a contest or a game. It works best when
both parties win.

2.Planning Principles
Principle1: Understand the scope of the project. Provides
destination.
Principle 2: Involve the customer in the planning activity.
Principle 3: Recognize that planning is iterative. Since work begins,
it very likely that things will change.
Principle 4: Estimate based on what you know: effort, cost, and task
duration.
Principle5. Consider risk as you define the plan. Level of risk.
Principle6: Be realistic. People don’t work 100 percent of every day.
Principle 7: Adjust granularity as you define the plan. Granularity
refers to the level of detail that is introduced as a project plan is
developed.
Principle 8:.Define how you intend to ensure quality. aim
Principle 9:Describe how you intend to accommodate change. Even
the best planning can be obviated by uncontrolled change.
Principle 10:Track the plan frequently and make adjustments as
required. Software projects fall behind schedule one day at a time.

3. Modeling Principles
Principle1. The primary goal of the software team is to build software, not
create models.
Principle2. Travel light, don’t create more models than you need.
Principle3. Strive to produce the simplest model that will describe the
problem or the software.
Principle 4. Build models in a way that makes them amenable to change.
Principle5. Be able to state an explicit purpose for each model that is created
Principle6. Adapt the models you develop to the system at hand.
Principle7. Try to build useful models, but forget about building perfect
models.
Principle8. Don’t become rigid about the syntax of the model. If it
communicates content successfully, representation is secondary.
Principle9. If your instincts tell you a model isn’t right even though it seems
okay on paper, you probably have reason to be concerned.
Principle10. Get feedback as soon as you can.

REQUIREMENTS MODELING PRINCIPLES
Principle1: The information domain of a problem must be represented and
understood.
Principle2: The functions that the software performs must be defined.
Principle3:The behavior of the software must be represented.
Principle 4:The models that depict information, function, and behavior Must
be partitioned in a manner that uncovers detail in a layered (or hierarchical)
fashion.
Principle5:The analysis task should move from essential information Toward
implementation detail.

DESIGN MODELING PRINCIPLES
Principle1: Design should be traceable to the requirements model.
Principle2: Always consider the architecture of the system to be built.
Principle3: Design of data is as important as design of processing functions.
Principle4: Interfaces (both internal and external ) must be designed with
care.
Principle5.User interface design should be tuned to the needs of the end-user.
However in every case, it should stress ease of use.

CONSTRUCTION PRINCIPLES
 The construction activity encompasses a set of coding and testing tasks
that lead to operational software that is ready for delivery to the customer
or end-user.
 Coding principles and concepts are closely aligned programming style,
programming languages, and programming methods.
 Testing principles and concepts lead to the design of tests that
systematically uncover different classes of errors and to do so with a
minimum amount of time and effort.

PREPARATION PRINCIPLES:
 Before you write one line of code, be sure you:
 Understand of the problem you’re trying to solve.
 Understand basic design principles and concepts.
 Pick a programming language that meets the needs of the software to be
built and the environment in which it will operate.
 Select a programming environment that provides tools that will make
your work easier.
 Create a set of unit tests that will be applied once the component you code
is completed.

PROGRAMMING PRINCIPLES
 As you begin writing code, be sure you:
 Constrain your algorithms by following structured programming practice.
 Consider the use of pair programming.
 Select data structures that will meet the needs of the design.
 Understand the software architecture and create interfaces that are
consistent with it.
 Keep conditional logic as simple as possible.
 Create nested loops in a way that makes them easily testable.
 Select meaningful variable names and follow other local coding
standards. Write code that is self-documenting.
 Create a visual layout that aids understanding

VALIDATION PRINCIPLES
After you’ve completed your first coding Pass ,be sure you
 Conduct a code walkthrough when appropriate.
 Perform unit tests and correct errors you’ve uncovered.
 Refactor the code.

TESTING PRINCIPLES
Principle1: All tests should be traceable to customer requirements.
Principle2: Tests should be planned long before testing begins.
Principle3: The Pareto[80% outcome from 20% cause] principle applies to
software testing.
Principle4: Testing should begin “in the small” and progress toward testing
“in the large.”
Principle5. Exhaustive testing is not possible.

DEPLOYMENT PRINCIPLES
Principle1: Customer expectations for the software must be managed.
Principle2: A complete delivery package should be assembled and tested.
Principle3: A support system must be established before the software is
delivered.
Principle4: Appropriate instructional materials must be provided to end-
users. Principle5: Buggy software should be fixed first, delivered later

software engineering and project management 3rd module ppt presenetation

More Related Content

What's hot

Similar to software engineering and project management 3rd module ppt presenetation

Recently uploaded

software engineering and project management 3rd module ppt presenetation