Software Engineering & Project Management
Module 2
Software Engineering & Project Management
BCS501 (3:0:0)
Software Engineering: A Practitioners Approach – Roger S. Pressman, 7th Edition, McGraw-Hill
2010
COs Course Outcomes Bloom’s level
Describe the fundamentals of Software Engineering Process and Process
CO1 Understand
Models.
CO2 Discuss requirement engineering tasks. Understand
CO3 Prepare quality software system using design principles. Apply
CO4 Use software testing techniques to perform system validations. Apply
Apply an effective software project estimation model for developing software
CO5 Apply
product.
Overview
➢Agile View of Process:
➢Agility,
➢Agile Process,
➢Agile Process Model
➢Requirement Engineering
➢Requirement Engineering Tasks
➢Initiating Requirement Engineering Process
➢Developing USE-CASE
Agility & Agile Development
What is Agility
• In 2001, Kent Beck and 16 other noted An agile team is a nimble team able to appropriately
software developers, writers, and respond to changes. Change is what software
consultants [Bec01a] (referred to as the development is very much about. Changes in the
“Agile Alliance”) signed the “Manifesto software being built, changes to the team members,
for Agile Software Development.” It
stated: changes because of new technology, changes of all
kinds that may have an impact on the product they
• We are uncovering better ways of build or the project that creates the product
developing software by doing it and
helping others do it. Through this work 1. In Jacobson’s view, the pervasiveness of change is
we have come to value: the primary driver for agility. Software engineers
1. Individuals and interactions over must be quick on their feet if they are to
processes and tools accommodate the rapid changes
2. Working software over comprehensive 2. Agility means effective (rapid and adaptive)
documentation response to change, effective communication
among all stakekholder.
3. Customer collaboration over contract
negotiation 3. Drawing the customer onto team and organizing a
team so that it is in control of work performed
4. Responding to change over following a
plan
AGILITY AND THE COST OF CHANGE
Figure 1: Change costs as a function of time in development
What is an Agile process
• Any agile software process is characterized in a Given these three assumptions, an
manner that addresses a number of key important question arises.
1. How do we create a process that
assumptions [Fow02] about the majority of software can manage unpredictability? The
projects: answer is process adaptability.
I. It is difficult to predict in advance which software 2. But continual adaptation without
requirements will persist and which will change. It is forward progress accomplishes
equally difficult to predict how customer priorities will little. Therefore, an agile software
process must adapt incrementally.
change as the project proceeds.
To accomplish incremental
II. For many types of software, design and construction adaptation, an agile team requires
are interleaved. That is, both activities should be customer feedback.
performed in tandem so that design models are proven 3. An effective catalyst for customer
as they are created. It is difficult to predict how much feedback is an operational
design is necessary before construction is used to prototype or a portion of an
prove the design. operational system. Hence, an
III. Analysis, design, construction, and testing are not as incremental development strategy
should be instituted.
predictable (from a planning point of view) as we might
like.
What is an Agile process continued
• Agility Principles
The Agile Alliance (see [Agi03], [Fow01]) defines 12 agility 9. Continuous attention to technical excellence and
principles for those who want to achieve agility: good design enhances agility.
1. Our highest priority is to satisfy the customer through early 10. Simplicity—the art of maximizing the amount of
and continuous delivery of valuable software. work not done—is essential.
2. Welcome changing requirements, even late in development. 11. The best architectures, requirements, and
Agile processes harness change for the customer’s competitive designs emerge from self– organizing teams.
advantage.
12. At regular intervals, the team reflects on how to
3. Deliver working software frequently, from a couple of weeks to become more effective, then tunes and adjusts
a couple of months, with a preference to the shorter
timescale. its behavior accordingly
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
What is an Agile process continued
• Human Factors: Proponents of agile software development take great pains
to emphasize the importance of “people factors.” As Cockburn and
Highsmith [Coc01a] state, “Agile development focuses on the talents and
skills of individuals, molding the process to specific people and teams.” The
key point in this statement is that the process molds to the needs of the
people and team, not the other way around.
1. Competence
2. Common focus.
3. Collaboration
4. Decision-making ability.
5. Fuzzy problem-solving ability
6. Mutual trust and respect.
7. Self-organization.
Agile software process model
Extreme Programming (XP):the most widely used approach to agile software
development.
• XP Values:Beck [Bec04a] defines a set of five values that establish a foundation for all work
performed as part of XP—communication, simplicity, feedback, courage, and respect. Each
of these values is used as a driver for specific XP activities, actions, and tasks.
1. Communication: XP emphasizes close, yet informal (verbal) collaboration between
customers and developers, the establishment of effective metaphors3 for
communicating important concepts, continuous feedback, and the avoidance of
voluminous documentation as a communication medium.
2. Simplicity: XP restricts developers to design only for immediate needs, rather than
consider future needs
3. Feedback: Feedback is derived from three sources: the implemented software itself, the
customer, and other software team members
4. Courage: Beck [Bec04a] argues that strict adherence to certain XP practices demands
courage. A better word might be discipline
5. Respect: By following each of these values, the agile team inculcates respect among it
members, between other stakeholders and team members, and indirectly, for the
software itself
Agile software process model Continued
The XP Process:Extreme Programming uses an object-oriented
approach (Appendix 2) as its preferred development paradigm
and encompasses a set of rules and practices that occur within
the context of four framework activities: planning, design,
coding, and testing.
1. Planning: The planning activity (also called the planning
game) begins with listening—a requirements gathering
activity that enables the technical members of the XP team
to understand the business context for the software and to
get a broad feel for required output and major features and
functionality.
2. Design:XP design rigorously follows the KIS (keep it simple)
principle. A simple design is always preferred over a more
complex representation.-spike solution(Operational
Prototype)
3. Coding: After stories are developed and preliminary design
work is done, the team does not move to code, but rather
develops a series of unit tests that will exercise each of the
stories that is to be included in the current release.
4. Testing. I have already noted that the creation of unit
tests before coding commences is a key element of the
XP approach. The unit tests that are created should be Figure 2: The Extreme Programming process
implemented using a framework that enables them to
be automated
Agile software process model Continued
Industrial XP:Joshua Kerievsky [Ker05] describes Industrial Extreme
Programming (IXP) in the following manner.
1. Readiness assessment.
2. Project community.
3. Project chartering
4. Test-driven management
5. Retrospectives(Technical Review)
6. Continuous learning.
Other Agile Process Models
The most widely used of all agile process model is Extreme Programming
(XP). But many other agile process models have been proposed and are in
use across the industry. Among the most common are:
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)
