BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Module-03

Chapter:-1 - AGILE DEVELOPMENT

What is Agility?

1. Definition of Agility:
o Agility refers to the ability of a software team to quickly and
effectively respond to changes.
2. Nature of Software Development:
o Software development is inherently about change—changes in the
product, team members, technology, and other factors.
3. Built-in Support for Change:
o Support for change should be embedded in all aspects of software
development, as it is fundamental to the process.
4. Team Dynamics:
o Successful software development relies on the skills and collaboration
of individuals within teams.
5. Response to Change:
o Software engineers need to be agile to accommodate rapid changes in
various aspects of the project.
6. Agility Beyond Change Management:
o Agility also includes adopting the philosophy of the Agile Manifesto,
which emphasizes:
 Improved communication among team members, technologists,
business people, and managers.
 Rapid delivery of functional software.

Prof. S Vinutha, RNSIT CSE-DS Page 1

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 De-emphasis on intermediate work products, though this can

sometimes be detrimental.
 Inclusion of the customer as part of the development team to
eliminate the "us vs. them" mentality.
 Recognition of the limits of planning in an uncertain
environment, requiring flexible project plans.
7. Application to Software Processes:
o Agility can be incorporated into any software process by:
 Allowing project teams to adapt and streamline tasks.
 Conducting planning that accommodates the fluid nature of
agile development.
 Eliminating non-essential work products and keeping necessary
ones lean.
 Emphasizing incremental delivery to get working software to
customers quickly, suited to the product type and operational
environment.

These points highlight the essence of agility in software engineering as described

by Ivar Jacobson.

Agility and the cost of change

1. Conventional Wisdom:
o The cost of change increases nonlinearly as a project progresses.
o Early changes (e.g., during requirements gathering) are inexpensive
and quick to implement.
o Late changes (e.g., during validation testing) are costly and time-
consuming due to extensive modifications required.

Prof. S Vinutha, RNSIT CSE-DS Page 2

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

2. Example of Cost Increase:

o Early changes: Modifying a usage scenario, extending a function list,
or editing a written specification has minimal costs and negligible
impact on the project timeline.
o Late changes: Introducing a major functional change during validation
testing necessitates modifications to the architecture, multiple
components, and testing, resulting in significant cost and time
increases.
3. Agility's Impact on Cost Curve:
o Proponents of agility argue that a well-designed agile process flattens
the cost of change curve.
o Agile practices such as incremental delivery, continuous unit testing,
and pair programming help reduce the impact of changes made late in
the project.
4. Flattening the Cost Curve:
o Agile practices aim to make changes more manageable and less
costly, even late in the development process.
o Incremental delivery ensures continuous progress and feedback,
allowing for adjustments without major overhauls.
o Continuous unit testing and pair programming catch issues early,
preventing expensive fixes later.
5. Ongoing Debate and Evidence:
o While the extent to which the cost curve flattens is debated, evidence
suggests significant cost reduction is achievable through agile
practices.

Prof. S Vinutha, RNSIT CSE-DS Page 3

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

These points highlight the conventional wisdom and the agile approach regarding
the cost of change in software development.

Agile Software Process:

Agile software processes are designed to manage the unpredictability inherent in

software projects by being flexible and adaptive. The following key assumptions
and principles guide agile methodologies:

Key Assumptions [Fow02]:

1. Unpredictable Requirements and Customer Priorities:

o It is difficult to predict which software requirements will remain
stable and which will evolve.
o Customer priorities may change as the project progresses.
2. Interleaved Design and Construction:

Prof. S Vinutha, RNSIT CSE-DS Page 4

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Design and construction should be performed together to validate

design models as they are created.
o The extent of necessary design work cannot be fully predicted before
construction begins.
3. Unpredictability in Planning:
o Analysis, design, construction, and testing are not always predictable
from a planning perspective.

Addressing Unpredictability:

To manage unpredictability, an agile process must be adaptable and incremental.

Key elements include:

1. Adaptability:
o The process must adapt to rapidly changing project and technical
conditions.
o Adaptation should occur incrementally to ensure continuous progress.
2. Customer Feedback:
o Regular feedback from customers is crucial for guiding necessary
adaptations.
o Feedback is facilitated by delivering operational prototypes or
portions of the system.
3. Incremental Development:
o Software is developed and delivered in small, functional increments.
o Each increment is a working piece of software, allowing for frequent
evaluations and feedback loops.
4. Iterative Approach:

Prof. S Vinutha, RNSIT CSE-DS Page 5

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o The process follows an iterative cycle of planning, development,

testing, and feedback.
o This enables the customer to evaluate software increments regularly
and influence adaptations.

Agility Principles:

The Agile Alliance defines 12 principles for achieving agility [Agi03], [Fow01]:

1. Customer Satisfaction:
o Satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome Change:
o Embrace changing requirements, even late in development, for the
customer's competitive advantage.
3. Frequent Delivery:
o Deliver working software frequently, with a preference for shorter
timescales (e.g., every few weeks).
4. Collaboration:
o Business people and developers must work together daily throughout
the project.
5. Motivated Individuals:
o Build projects around motivated individuals, providing them with the
environment and support they need.
6. Face-to-Face Communication:
o The most efficient and effective method of conveying information
within a development team is face-to-face conversation.
7. Working Software:

Prof. S Vinutha, RNSIT CSE-DS Page 6

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Working software is the primary measure of progress.

8. Sustainable Development:
o Promote sustainable development, maintaining a constant pace
indefinitely.
9. Technical Excellence and Good Design:
o Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity:

 Maximize the amount of work not done—focus on simplicity.

11. Self-Organizing Teams:

 The best architectures, requirements, and designs emerge from self-

organizing teams.

12. Regular Reflection:

 At regular intervals, the team reflects on how to become more effective and
adjusts its behavior accordingly.

The Politics of Agile Development:

There is considerable debate about the benefits and applicability of agile software
development versus traditional software engineering processes. Key points include:

1. Pro-Agility View:
o Agilists view traditional methodologies as overly rigid and
documentation-heavy, hindering the delivery of working systems.
2. Traditional View:

Prof. S Vinutha, RNSIT CSE-DS Page 7

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Traditionalists view agile methodologies as undisciplined and risky,

especially when scaling up to enterprise-wide software.
3. Rational Thought vs. Beliefs:
o The debate often risks becoming a "religious war," with beliefs rather
than facts guiding decision-making.
4. Balanced Approach:
o There is value in considering the best aspects of both agile and
traditional approaches rather than denigrating either.

Human Factors in Agile Development:

Agile methodologies emphasize the importance of "people factors," including:

1. Competence:
o Competence includes innate talent, specific skills, and knowledge of
the chosen process. Training should be provided to all team members.
2. Common Focus:
o Team members should focus on delivering a working software
increment within the promised time, continually adapting the process
to fit team needs.
3. Collaboration:
o Effective collaboration within the team and with stakeholders is
essential for success.
4. Decision-Making Ability:
o Teams should have the autonomy to make decisions about both
technical and project issues.
5. Fuzzy Problem-Solving Ability:

Prof. S Vinutha, RNSIT CSE-DS Page 8

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Teams must be able to handle ambiguity and change, learning from all
problem-solving activities.
6. Mutual Trust and Respect:
o Teams should develop trust and respect, creating a cohesive unit
where the whole is greater than the sum of its parts.
7. Self-Organization:
o Teams should self-organize for the work, process, and schedule to
achieve delivery of software increments. This improves collaboration
and boosts morale.

Extreme Programming (XP)

 By adhering to these principles and practices, agile processes aim to create

flexible, adaptive, and efficient software development teams that can
respond effectively to change and deliver valuable software to customers.
 Extreme Programming (XP) is one of the most widely used approaches to
agile software development.
 Developed by Kent Beck, XP focuses on improving software quality and
responsiveness to changing customer requirements.
 A variant of XP, called Industrial XP (IXP), has been proposed to address
the needs of large organizations. Here's an overview of XP and its key
practices, values, and processes:

XP Values

Kent Beck defines five core values for XP: communication, simplicity, feedback,
courage, and respect. These values drive specific activities, actions, and tasks
within the XP framework.

Prof. S Vinutha, RNSIT CSE-DS Page 9

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

1. Communication: Effective communication is crucial in XP, emphasizing

informal, verbal collaboration between customers and developers,
continuous feedback, and minimal documentation.
2. Simplicity: XP advocates for designing only for immediate needs, avoiding
unnecessary complexity.
3. Feedback: Derived from the software, customers, and team members,
feedback is crucial for continuous improvement. Unit tests are a primary tool
for feedback.
4. Courage: XP requires the discipline to focus on current requirements and be
ready to refactor as needed.
5. Respect: Adhering to these values fosters respect among team members,
stakeholders, and for the process itself.

The XP Process

XP uses an object-oriented approach and encompasses four framework activities:

planning, design, coding, and testing.

1. Planning: Begins with requirements gathering and creating user stories.

Stories are prioritized, estimated, and grouped into releases. Project velocity
is used to estimate delivery dates and schedule future releases.
2. Design: Follows the KIS (keep it simple) principle. Design work is minimal
and often uses CRC cards. Refactoring is encouraged to improve the design
continuously.
3. Coding: Unit tests are written before coding begins. Pair programming is a
key practice, ensuring real-time problem solving and quality assurance.
Continuous integration helps uncover errors early.

Prof. S Vinutha, RNSIT CSE-DS Page 10

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

4. Testing: Unit tests should be automated to enable frequent regression

testing. Acceptance tests focus on overall system features and functionality,
as specified by the customer.

Industrial XP (IXP)

IXP extends XP for large organizations, incorporating new practices and

modifying existing ones:

1. Readiness Assessment: Evaluates whether the organization can support

IXP.
2. Project Community: Expands the team concept to include all relevant
stakeholders.
3. Project Chartering: Assesses the business justification and alignment with
organizational goals.
4. Test-Driven Management: Establishes measurable criteria for project
progress.

Prof. S Vinutha, RNSIT CSE-DS Page 11

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. Retrospectives: Reviews to improve the IXP process based on past

experiences.
6. Continuous Learning: Encourages team members to learn new methods
and techniques.

IXP also introduces practices like story-driven development and domain-driven

design, extends pair programming to include managers and other stakeholders, and
promotes iterative usability design.

The XP Debate

XP has spurred discussion and debate, with critics pointing out potential issues:

1. Requirements Volatility: Informal requirements changes can lead to scope

creep.
2. Conflicting Customer Needs: Multiple customers with different needs can
create challenges.
3. Informal Requirements: Critics argue for more formal models or
specifications to prevent omissions and errors.
4. Lack of Formal Design: XP's informal design approach may not suit
complex systems.

Proponents argue that XP's iterative and adaptive nature addresses these issues
effectively.

In summary, XP and its variant IXP offer a flexible, customer-centric approach to

software development, focusing on continuous improvement and responsiveness to
change. Each organization should adapt the process to meet its specific needs and
address potential weaknesses.

Prof. S Vinutha, RNSIT CSE-DS Page 12

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Other Agile Process Models

 The history of software engineering is filled with numerous methodologies,

notations, tools, and technologies, many of which have been replaced by
newer and allegedly superior alternatives.
 The agile movement, with its wide array of process models vying for
acceptance, is following this same path.
 Among these, Extreme Programming (XP) is the most widely used, but
several other agile process models have been proposed and are currently in
use across the industry.
 These include Adaptive Software Development (ASD), Scrum, Dynamic
Systems Development Method (DSDM), Crystal, Feature Driven
Development (FDD), Lean Software Development (LSD), Agile Modeling
(AM), and Agile Unified Process (AUP).

Adaptive Software Development (ASD)

 Adaptive Software Development (ASD), proposed by Jim Highsmith,

focuses on human collaboration and team self-organization.
 It is based on the belief that adaptive development through collaboration
provides order in complex interactions just as much as discipline and
engineering.
 ASD follows a life cycle comprising three phases: speculation,
collaboration, and learning.
 During speculation, the project is initiated, and adaptive cycle planning is
conducted.
 This phase uses project initiation information such as the customer’s mission
statement and basic requirements to define release cycles.

Prof. S Vinutha, RNSIT CSE-DS Page 13

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 Collaboration within motivated teams multiplies their talent and creative

output, though it requires trust among team members.
 The learning phase emphasizes improving the team's understanding of the
technology, process, and project.
 ASD teams learn through focus groups, technical reviews, and project
postmortems.

Scrum

 Scrum, developed by Jeff Sutherland and his team in the early 1990s, is an
agile method that follows principles consistent with the agile manifesto.
 It comprises framework activities such as requirements, analysis, design,
evolution, and delivery. Work tasks within these activities occur in sprints,
which are short, predefined time-boxes.
 Key elements of Scrum include the backlog (a prioritized list of
requirements), sprints (work units within a time-box), daily Scrum meetings

Prof. S Vinutha, RNSIT CSE-DS Page 14

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

(short meetings to discuss progress and obstacles), and demos (presentations

of software increments to customers). Scrum assumes chaos and uses
process patterns to manage it effectively.

Dynamic Systems Development Method (DSDM)

 DSDM is an agile approach that uses incremental prototyping within a

controlled project environment. Based on the Pareto principle, it aims to
deliver 80% of an application in 20% of the time required for the complete
application.
 The DSDM life cycle includes feasibility study, business study, functional
model iteration, design and build iteration, and implementation. DSDM can
be combined with XP to provide a comprehensive approach to software
development.

Prof. S Vinutha, RNSIT CSE-DS Page 15

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Crystal

The Crystal family of agile methods, created by Alistair Cockburn and Jim
Highsmith, emphasizes maneuverability and adaptability in software development.
Crystal methodologies have core elements common to all and specific elements
unique to each. They are designed to be selected based on the specific needs of a
project and its environment.

Feature Driven Development (FDD)

 FDD, conceived by Peter Coad and extended by Stephen Palmer and John
Felsing, is an agile process for object-oriented software engineering. It
emphasizes collaboration, feature-based decomposition, and communication.
 A feature is a client-valued function that can be implemented in two weeks
or less. FDD focuses on quality assurance through design and code
inspections, audits, metrics, and the use of patterns.
 It provides a structured approach to project management with six milestones
for each feature: design walkthrough, design, design inspection, code, code
inspection, and promote to build.

Prof. S Vinutha, RNSIT CSE-DS Page 16

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Lean Software Development (LSD)

 LSD adapts principles from lean manufacturing to software engineering,

including eliminating waste, building quality in, creating knowledge,
deferring commitment, delivering fast, respecting people, and optimizing the
whole.
 Waste elimination in software projects involves avoiding extraneous
features, assessing the impact of new requirements, removing unnecessary
process steps, and streamlining information transmission.

Agile Modeling (AM)

 Agile Modeling (AM) is a practice-based methodology for effective

modeling and documentation of software systems.
 It emphasizes creating models with a specific purpose, using multiple
models to provide different perspectives, keeping only necessary models,
and ensuring content is more important than representation.
 AM integrates with the Unified Modeling Language (UML) and the Unified
Process (UP) to provide a simplified and effective approach to modeling.

Agile Unified Process (AUP)

 The Agile Unified Process (AUP) follows a "serial in the large" and
"iterative in the small" approach.
 It includes classic UP activities (inception, elaboration, construction, and
transition) and iterates within these activities to deliver software increments
rapidly.

Prof. S Vinutha, RNSIT CSE-DS Page 17

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

 AUP activities include modeling, implementation, testing, deployment,

configuration and project management, and environment management.
 It integrates UML modeling with agile principles for effective software
development.
 In summary, while the agile movement has introduced numerous process
models, each has unique elements and adheres to the principles of the Agile
Manifesto.
 The choice of model often depends on the specific needs and context of the
project.

A tool set for Agile process

Automated Software Tools in Agile:

 Some proponents argue that automated tools should be seen as minor

supplements.
 Alistair Cockburn suggests that tools can benefit agile teams by facilitating
rapid understanding.

Types of Tools in Agile Teams:

 Social Tools:
o Starting from the hiring stage to assess the "fit" of a prospective team
member, such as pair programming sessions.
 Technological Tools:
o Help distributed teams simulate physical presence.
 Physical Tools:
o Used in workshops to manipulate information and coordinate
activities.

Prof. S Vinutha, RNSIT CSE-DS Page 18

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Key Elements of Agile Process Models:

 Acquiring the right people (hiring).

 Team collaboration.
 Stakeholder communication.
 Indirect management.

Importance of Tools in Agile:

 Cockburn argues that tools addressing hiring, collaboration, communication,

and management are critical for agility.

Examples of Tools:

 Hiring Tool: Pair programming sessions with prospective team members.

 Collaborative and Communication Tools:
o Low-tech mechanisms such as whiteboards, poster sheets, index
cards, and sticky notes.
o Active communication through team dynamics (e.g., pair
programming).
o Passive communication through "information radiators" (e.g., status
displays).
 Project Management Tools:
o Deemphasize Gantt charts in favor of earned value charts and test
graphs.
o Optimize team environment, enhance team culture, and improve
processes (e.g., efficient meeting areas, electronic whiteboards,
collocated teams, pair programming, and time-boxing).

Prof. S Vinutha, RNSIT CSE-DS Page 19

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Definition of Tools in Agile:

 Tools are defined as anything that facilitates the work performed by an agile
team member and enhances the quality of the end product.

Prof. S Vinutha, RNSIT CSE-DS Page 20

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

Chapter:-2 - Principles that guide practice

Software Engineering Knowledge

Steve McConnell's editorial highlights the distinction between technology-specific
knowledge and enduring software engineering principles.

1. Technology-Specific Knowledge:

o Software practitioners often focus on knowledge of specific

technologies (e.g., Java, Perl, C++, Linux).

o This knowledge is necessary for performing specific programming

tasks.

o Technology-related knowledge tends to have a short half-life (about 3

years), meaning it can become obsolete quickly.

2. Enduring Software Engineering Principles:

o McConnell argues that there is another type of knowledge, which he

calls "software engineering principles."

o These principles do not have a short half-life and are likely to be

useful throughout a programmer's career.

o They form a stable core of knowledge essential for developing

complex systems.

3. Stable Core of Knowledge:

o By the year 2000, McConnell estimated that about 75 percent of the
knowledge needed to develop a complex system resided within this
stable core.

o This core consists of fundamental principles that guide software

engineers in their work.

Prof. S Vinutha, RNSIT CSE-DS Page 21

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

4. Application and Evaluation:

o The core principles provide a foundation from which software
engineering models, methods, and tools can be applied and evaluated.

In essence, McConnell emphasizes the importance of focusing not only on

transient technological skills but also on enduring software engineering principles
that form the stable foundation of the discipline.

Core principles

The core principles of software engineering are essential for both the process and
practice levels, providing a foundation and guiding values for effective
development.

Principles That Guide Process

1. Be Agile:
o Emphasize simplicity and economy of action.
o Keep work products concise and make local decisions when possible.
2. Focus on Quality at Every Step:
o Ensure every activity and task produces high-quality work products.
3. Be Ready to Adapt:
o Adapt approaches based on constraints from the problem, people, and
project.
4. Build an Effective Team:
o Focus on building a self-organizing team with mutual trust and
respect.
5. Establish Mechanisms for Communication and Coordination:
o Address management issues to ensure critical information is shared
and coordinated effectively.

Prof. S Vinutha, RNSIT CSE-DS Page 22

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

6. Manage Change:
o Establish formal or informal mechanisms to manage change requests,
assessments, approvals, and implementations.
7. Assess Risk:
o Identify potential issues and establish contingency plans.
8. Create Work Products That Provide Value for Others:
o Produce only those work products that are necessary and valuable for
subsequent process activities.

Principles That Guide Practice

1. Divide and Conquer:

o Emphasize separation of concerns to simplify solving large problems.
2. Understand the Use of Abstraction:
o Use abstractions to simplify complex elements, starting with high-
level models and refining to lower levels.
3. Strive for Consistency:
o Maintain consistency in requirements models, designs, source codes,
and test cases for ease of use and understanding.
4. Focus on the Transfer of Information:
o Pay attention to the analysis, design, construction, and testing of
interfaces to ensure clear and accurate information flow.
5. Build Software That Exhibits Effective Modularity:
o Ensure modules are cohesive in function, have low coupling, and are
interconnected simply.
6. Look for Patterns:
o Utilize patterns to resolve recurring problems and create a shared
language for solutions and good architectural practices.

Prof. S Vinutha, RNSIT CSE-DS Page 23

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

7. Represent the Problem and Its Solution from Different Perspectives:

o Examine problems and solutions from multiple viewpoints (e.g., data-
oriented, function-oriented, behavioral) for greater insight and error
detection.
8. Remember That Someone Will Maintain the Software:
o Apply solid software engineering practices to facilitate future
maintenance activities such as corrections, adaptations, and
enhancements.

These principles establish a robust foundation for every software engineering

method and guide the development of high-quality, operational software that meets
stakeholders' needs.

Principles that guide each framework activity

Communication Principles

Effective communication is crucial in software projects, particularly when

gathering customer requirements. These principles apply to all forms of
communication within a project but are especially important for customer
interactions:

1. Listen: Focus on the speaker’s words and ask for clarification without
constant interruptions.
2. Prepare Before You Communicate: Understand the problem and prepare
an agenda if you’re conducting a meeting.
3. Facilitate the Activity: Ensure meetings have a leader to keep discussions
productive and mediate conflicts.

Prof. S Vinutha, RNSIT CSE-DS Page 24

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

4. Face-to-Face Communication Is Best: Use additional representations, like

drawings or documents, to aid discussions.
5. Take Notes and Document Decisions: Record all important points and
decisions to avoid losing information.
6. Strive for Collaboration: Build trust and common goals through
collaboration and consensus among team members.
7. Stay Focused; Modularize Your Discussion: Keep discussions focused on
one topic at a time to avoid bouncing between topics.
8. If Something Is Unclear, Draw a Picture: Use sketches or drawings to
clarify verbal communication.
9. Move On When Necessary: If you agree, move on; if you can’t agree,
move on; if something is unclear, move on.
10.Negotiation Is Not a Contest: Aim for win-win negotiations, compromising
as needed to achieve common goals.

Planning Principles

Effective planning provides guidance to the software team and helps manage the
project's progression:

1. Understand the Scope of the Project: Know the project’s destination to use
a road map effectively.
2. Involve Stakeholders in the Planning Activity: Engage stakeholders to
define priorities and establish constraints.
3. Recognize That Planning Is Iterative: Adjust the plan as work progresses
and new information emerges.
4. Estimate Based on What You Know: Provide estimates based on the
current understanding of the work.

Prof. S Vinutha, RNSIT CSE-DS Page 25

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. Consider Risk as You Define the Plan: Adjust the project plan to
accommodate high-impact, high-probability risks.
6. Be Realistic: Account for human factors, communication noise, and the
likelihood of changes and mistakes.
7. Adjust Granularity as You Define the Plan: Plan in detail for the short
term and broadly for the long term, adjusting as needed.
8. Define How You Intend to Ensure Quality: Identify and schedule quality
assurance activities like technical reviews and pair programming.
9. Describe How You Intend to Accommodate Change: Define how changes
will be requested, assessed, and implemented.
10.Track the Plan Frequently and Make Adjustments as Required: Monitor
progress daily and adjust the plan to address slippages.

Modeling Principles

Models help in understanding and building the software. There are two types of
models: requirements models (analysis models) and design models. Agile
modeling principles, although intended for agile processes, apply to all software
engineering:

1. The Primary Goal Is to Build Software, Not Create Models: Create

models that facilitate getting software to the customer quickly.
2. Travel Light: Create only necessary models to avoid wasting time on
upkeep and construction delays.
3. Produce the Simplest Model: Keep models simple to ensure the software is
simple, easier to integrate, test, and maintain.
4. Build Models That Are Amenable to Change: Create models that can be
easily updated as requirements change.

Prof. S Vinutha, RNSIT CSE-DS Page 26

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

5. State an Explicit Purpose for Each Model: Justify the creation of each
model; if not justified, don’t create it.
6. Adapt Models to the System at Hand: Tailor model notation or rules to the
specific application.
7. Forget About Building Perfect Models: Aim for useful models rather than
perfect ones; avoid diminishing returns.
8. Don’t Be Dogmatic About Model Syntax: Focus on successful
communication of content rather than strict adherence to syntax.
9. Trust Your Instincts: Experienced software engineers should trust their
instincts about models, even if they seem fine on paper.
10.Get Feedback Quickly: Review models with the team to correct mistakes,
address misinterpretations, and add missing features.

These principles collectively guide software engineering efforts, ensuring that

processes and practices are effective, efficient, and adaptable to changing
requirements and circumstances.

Requirements Modeling Principles

Requirements modeling methods have evolved significantly, addressing various

analysis problems through unique modeling notations and heuristics. However,
they share common operational principles:

1. Representation and Understanding of Information Domain:

o Encompasses data flow into the system, data flow out, and data stores.
o Ensures a comprehensive understanding of the data involved.
2. Definition of Software Functions:
o Involves specifying functions that provide user-visible benefits and
internal support.

Prof. S Vinutha, RNSIT CSE-DS Page 27

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Functions transform data, control processing, or interact with external

elements.
3. Representation of Software Behavior:
o Software behavior is driven by interactions with external
environments.
o Input from users, external systems, or networks triggers specific
behaviors.
4. Hierarchical Partitioning of Models:
o Models depicting information, function, and behavior should be
layered.
o This divide-and-conquer strategy simplifies complex problems into
manageable subproblems.
5. Movement from Essential Information to Implementation Detail:
o Starts with a user perspective, describing the problem without
implementation details.
o Gradually includes implementation specifics, considering user
interaction methods.

Design Modeling Principles

Design modeling translates requirements into detailed plans, providing multiple

views of the system. Key principles include:

1. Traceability to Requirements Model:

o Design elements should directly correlate with requirements.
2. Architectural Consideration:
o Focus on the overall system architecture before delving into
component details.

Prof. S Vinutha, RNSIT CSE-DS Page 28

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

3. Data Design Importance:

o Data structures should be well-designed to simplify program flow and
component design.
4. Careful Interface Design:
o Both internal and external interfaces must be designed for efficiency,
error reduction, and simplicity.
5. User Interface Design:
o Should cater to user needs, prioritizing ease of use.
6. Functional Independence of Components:
o Components should be cohesive, focusing on a single function or
subfunction.
7. Loose Coupling of Components:
o Minimize interdependence to reduce error propagation and improve
maintainability.
8. Understandable Design Representations:
o Design models should be clear and communicable.
9. Iterative Development:
o Design should evolve iteratively, aiming for simplicity with each
iteration.

Construction Principles

The construction phase involves coding and testing tasks leading to operational
software:

Coding Principles

1. Preparation Principles:

Prof. S Vinutha, RNSIT CSE-DS Page 29

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

o Understand the problem and design principles.

o Choose appropriate programming languages and environments.
o Create unit tests for components.
2. Programming Principles:
o Follow structured programming practices.
o Use meaningful variable names and self-documenting code.
o Design interfaces consistent with the architecture.
3. Validation Principles:
o Conduct code walkthroughs and unit tests.
o Refactor code as necessary.

Testing Principles

1. Traceability to Requirements:
o Tests should map directly to customer requirements.
2. Early Test Planning:
o Plan tests early, ideally as soon as requirements and design models are
solidified.
3. Pareto Principle in Testing:
o Focus on the 20% of components likely to contain 80% of errors.
4. Progressive Testing:
o Start with small components and progress to integrated system testing.
5. Impossibility of Exhaustive Testing:
o Focus on adequate coverage rather than exhaustive path testing.

Deployment Principles

Deployment involves delivery, support, and feedback:

Prof. S Vinutha, RNSIT CSE-DS Page 30

 BCS501 | SOFTWARE ENGINEERING & PROJECT MANAGEMENT

1. Managing Customer Expectations:

o Communicate clearly to avoid overpromising and under-delivering.
2. Complete Delivery Package:
o Include all necessary executable software, support files, and
documents.
3. Establish Support Regime:
o Ensure responsive and accurate support for users.
4. Provide Instructional Materials:
o Include training aids, troubleshooting guidelines, and updates on new
increments.
5. Fix Bugs Before Delivery:
o Ensure high-quality releases, as users remember issues caused by low-
quality software.

Prof. S Vinutha, RNSIT CSE-DS Page 31