CHAPTER 1

.
Software Development Process

1
1.1 Software
• Software is a collection of programs.
• These programs are developed by Software Engineers.
• Various programming languages like C++, Java, Python ,etc are used

• IEEE) defines software as "programs, procedures, rules, and data that direct the
operations of a computer system, defining the computer's function and enabling
users to accomplish specific tasks."

2
Software Engineering
• Software Engineering is a sub-domain of Engineering in which we develop,
design, test, and maintain a software using a systematic approach.
• Engineering involves using scientific and mathematical principles to design, build,
and maintain structures, systems, and processes for practical purposes, solving
real-world challenges efficiently.
• Software is a collection of programs.

3
Software Engineering as a Layered Approach
• Software engineering is a fully layered technology,.
• To develop software we need to go from one layer to another. All the
layers are connected and each layer demands the fulfillment of the
previous layer.
1. quality focus: It defines the continuous process improvement principles of software. It
provides integrity that means providing security to the software so that data can be
accessed by only an authorized person, no outsider can access the data. It also focuses
on maintainability and usability.

2. Process: It is the foundation or base layer of software engineering. It is key that binds
all the layers together which enables the development of software before the deadline
or on time. Process defines a framework that must be established for the effective
delivery of software engineering technology. The software process covers all the
activities, actions, and tasks required to be carried out for software development. 4
Software Engineering as a Layered Approach

Diagram: Software Engineering as a Layered Approach

5
.
Process activities are listed below:
Communication: It is the first and foremost thing for the development of software. Communication is
necessary to know the actual demand of the client.
Planning: It basically means drawing a map for reduced the complication of development.
Modeling: In this process, a model is created according to the client for better understanding.
Construction: It includes the coding and testing of the problem.
Deployment: It includes the delivery of software to the client for evaluation and feedback.

3. Method: During the process of software development the answers to all “how-to-do”
questions are given by method. It has the information of all the tasks which includes
communication, requirement analysis, design modeling, program construction, testing, and
support.

4. Tools: Software engineering tools provide a self-operating system for processes and methods.
Tools are integrated which means information created by one tool can be used by another.
6
Software Characteristics
 Software is developed not manufactured
 Software does not wear out
 Most software is custom built
• Software is developed not manufactured: Unlike physical products, software is created through
coding and design rather than assembly lines, emphasizing creativity and problem-solving over
mass production.
• Software does not wear out: Unlike physical goods that degrade over time, software typically
remains functional indefinitely, with any issues typically being related to bugs or compatibility
rather than wear and tear.
• Most software is custom built: Due to the diverse needs of businesses and users, the majority of
software is tailored to specific requirements rather than being mass-produced for general use.

7
Types of Software
• System software
• Application software
• Embedded software
• Real time software
• Product-line software
• Engineering/scientific software
• Web based software
• AI Artificial Intelligence software
• Personal Computer software

8
Types of Software
• System software: Manages computer hardware and provides a platform for running application
software. Eg. An OS (Operating system)
• Application software: Performs specific tasks for users, such as word processing or gaming. Eg.
Microsoft Word, a Game –eg Need for Speed.
• Embedded software: Controls dedicated devices like appliances eg. washing machines.
• Real-time software: Responds to events instantly, often used in critical systems eg. like air traffic
control.
• Product-line software: Customizable software designed for various clients or markets.
• Engineering/scientific software: Used for simulations, calculations, and analysis in technical
fields.
• Web-based software: Accessible via web browsers, like online shopping or social media
platforms.
• AI (Artificial Intelligence) software: Utilizes algorithms to mimic human intelligence, enabling
tasks like speech recognition or image processing.
• Personal computer software: Programs installed on personal computers for various purposes.
9
1.2 Software development framework

10
1.2 Software development framework
• Software process: It is a step-by-step approach to building software, guiding how
work is planned, executed, and monitored.
• Process framework: It is a Structure outlining key components and interactions
within a software development process.
• Umbrella activities: High-level tasks that encompass and coordinate various
processes throughout the software development lifecycle.
eg risk management, quality assurance, and documentation

• Action: A single step or activity taken to achieve a specific goal or outcome.

• Task sets: Groups of related tasks organized together to accomplish a particular
objective or function efficiently.
Milestones: Significant points or achievements in a project timeline.
• SQA points: Quality checkpoints or criteria to ensure software quality.
11
1.3 Software Process framework
• A Framework is a standardized way to build and deploy application

• Software Framework is the basis of a complete software engineering

process

• Generally a process Framework contains the following activities:

• Communication
• Planning
• Modelling
• Construction
• Deployment
12
• Communication- communication between customers and stakeholders(people /
involved and concerned with the project example software developers,
managers, etc.) regarding the actual requirements of the product for the product.

• Planning- Here we decide and plan various technical tasks to be performed.

Scheduling various activities and task related to our project takes place .
Analyzing various risks involved, resources required.

• Modelling- A model is created to understand the requirement and design in a

better way.

• Construction- Here actual implementation is done. It involves to activities coding

and testing.

• Deployment- complete project or partially completed project is given to customer.

The customer then gives a feedback.
This feedback is then used to evaluate our project performance and make the
necessary changes required by customer.

13
Umbrella activities: /

• Risk management: Identifying potential issues or obstacles in a project and

planning ways to mitigate or address them.
• Software Quality Assurance: Checking that the software meets quality standards
and functions correctly before it's released.
• Software Configuration Management (SCM): Keeping track of changes made to
software, controlling versions, and ensuring consistency across different
environments.

14
Process models
Perspective process models
Waterfall model
• Introduced by Winston Royce in 1970.
• It is the first ever SDLC (Software development lifecycle model)
• The waterfall model is also called as 'Linear sequential model' or 'Classic life
cycle model'.
• This model is called waterfall model because its diagrammatic representation
looks like a waterfall.
• Each phase must be completed before starting of the next phase. The
previous phase serves as an input to the next phase.

Waterfall model is suitable when,

• requirements do not change
• Project is small and simple
• The resources tools and Technology etc are available
15
Waterfall model

Diagram: Waterfall model 16

Phases of waterfall model

Requirement analysis
• In this phase exact requirement of the customer are understood and
documented.
• This includes detailed information about functions, interface etc. of the
software. This detailed information is documented into SRS (software
requirements specification)
• SRS also serves as a contract between the software development team and
the customer or client.

17
Design phase
• In the design phase the requirement gathered from previous
phase
• are converted into design.
• These design include Algorithms, flowcharts ,rough designs,
designs about user interface , etc.

Development phase
• In this phase Coding is done, based on the design.
• In this phase Unit testing is also performed to ensure every unit is
performing as expected.
18
Testing phase
• In this phase software is tested as a whole to ensure that the
software is working properly and meet customer requirements.
• Test cases and Test reports are generated.

Deployment phase
• In the phase the software is finally deployed/ installed on user/
client machine or released into the market.
• Customer / client feedback is received and analyzed in order to
learn about any lacking features or vulnerability in the product.

19
Maintenance phase
• This phase involves fixing any issues that arise after the software
has been deployed.
• Ensuring that changes have been made according to the feedback
to meet customer requirements/ market requirements.

20
Advantages of waterfall model
• simple and easy to understand, implement, and use.
• Works well for smaller projects
• All requirements are well understood
• Results are well documented
• Next phase starts only after completion of the previous phase.
• All the requirements are known at the beginning of the project,
hence it is easy to manage.

21
.

Disadvantages of waterfall model

• The amount of risk is high.
• It is a poor model for long projects.
• This model is not good for complex and object oriented projects.
• Customer/ client feedback is not included in the ongoing
development phases
• The problems with this model are uncovered, until the software
testing.

22
Incremental model
• The model is based on the idea “develop an initial implementation,
release it to the user, receive feedback from user and evolve it (the
software) through several versions till an acceptable system has been
developed.
• In the incremental model the whole, divided into various builds.
• Multiple development cycles take place here, making it a "multi-
waterfall" cycle.
• Cycles are divided into smaller more easily managed modules.
• Each module passes through requirements , design ,implementation
and testing phase.

23
• A working version of software is produced during the first model, so
you have working software early on during the software life cycle.
• Each release of a module adds new functions to the previous release.
• This process continues to the complete system is achieved.

• Incremental model is suitable when,

• Customer demands quick release of the product
• Requirements at theory under student specified
• The requirements are prioritized, requirement can be released according to
its priority

24
Incremental model

Diagram: Incremental model

25
.
Advantages of Incremental model
• Generates working software quickly and early (an iteration)
• Easier to test and debug (as we are not creating the entire software at once, it
is developed in various iterations)
• Customer can respond to each build and provide their valuable feedback.
• Easy to manage risk due to handling them in various iterations.

Disadvantages of Incremental model

• Needs good planning and design since there are various iterations
• Needs clear understanding of the whole system before the work can be
broken down into various iterations
• cost is higher then Waterfall model
• Every iteration phase is rigid And does not overlap with each other

26
.
RAD model

• RAD (Rapid Application Development) focuses on developing software

products faster.
• A software project can be implemented using the model if the project can be
broken down into small modules ,where each model can be assigned
independent separate teams.
• Finally , these modules can be combined to form the final product.
• For eg. In the diagram,
 module 1 can be assigned to Team A
 module 2 can be assigned to Team B
 module 3can be assigned to Team C

27
.
Phases of RAD Model

Requirement planning
• It in was various requirement elicitation techniques such as brainstorming,
FAST , etc.
• It also consists of the entire structured plan describing the critical data,
methods to obtain it, and then processing it to form a final model.

User Description
• Taking user feedback and building the prototype using developer tools.
• It includes re-examination and validation of the data collected in the first
phase.

28
.
Phases of RAD Model

Construction
• Refinement of the prototype and delivery takes place.
• It includes the actual use of powerful automated tools to transform processes
and data models into the final working product.
• All the required modifications and enhancements are done.

Cutover
• All the interfaces between the independent modules developed by separate
teams have to be tested properly.
• Then there is acceptance testing by the user.

29
. RAD model

Diagram: RAD Rapid Action Development model

30
Business Modeling: involves understanding and representing how a business
.
operates, including its processes, goals, stakeholders, and requirements.

Data Modeling: involves defining the structure of data within a database system.
Includes specifying data entities, their attributes, relationships, and constraints, to
ensure data integrity and support efficient data management.

Process Modeling: involves visually representing the steps, activities, and interactions
involved in a system.
It helps in understanding, analyzing, and improving workflows, identifying issues , and
optimizing efficiency.

Application Generation: refers to the automated or semi-automated creation of

software applications based on predefined specifications or models
Involves using tools or frameworks to generate code, user interfaces, and other
components of an application.

Testing and Turnover: evaluating a software system to identify defects, errors ensuring
that it meets quality standards and user requirements.
31
.
Advantages of RAD Model
• This model is flexible for change.
• In this model, changes are adoptable.
• Each phase in RAD brings highest priority functionality to the customer.
• It reduced development time.
• It increases the reusability of features.

Disadvantages of RAD Model

• It required highly skilled designers.
• All application are not compatible with RAD.
• For smaller projects, we cannot use the RAD model.
• On the high technical risk, it's not suitable.
• Requires user involvement.
32
.Specialized models
Spiral model
• Develop by Barry Boehm in 1986 along
• This model focuses on "risk management"
• It is a combination of multiple models.
• It is also known as meta model

• Spiral model is suitable when,

 The software news constant risk evaluation
 Project is large or complex
 Budget is high

33
Spiral model
.
Specialized
models

Diagram: RAD Rapid Action Development model

34
. Phases
Planning
of spiral model
Communication between development team and customer or client takes place
Requirement gathering from Customers.
Project Schedule, required resources, costs are analyzed.

Risk analysis
Identification and mitigation of potential risks.
A prototype is developed.

Engineering and execution

Design , coding ,Testing will be performed and then deployed or released to the
customer/ client environment

Evaluation
If feedback from customer/ client ,if customer wants some changes move to the next
spiral iteration.
35
.
Advantages of spiral model
• useful in large and complex projects
• strong emphasis on risk management
• risk analysis and risk handling at every phase.
• iterative and incremental approach allows flexibility and
adaptability in response to changing requirements
• multiple iterations which can result in improved software quality
and reliability.
• Always space for customer feedback
• Changing requirements can be accommodated.
• Fast development
36
.

Disadvantages of spiral model

• Time consuming
• Not suitable for small projects
• Costly as compared to other models
• Very complex as compared to other models
• Risk analysis require high level of expertise

37
.
Prototyping model

38
.
Prototyping model

Many times the client only has a general view of what is expected from the
software product.
In such a scenario where there is an absence of detailed information regarding
the input to the system, the processing needs, and the output requirement, the
prototyping model may be employed.
A prototype is a toy implementation of the system.

39
.
• Steps of Prototype Model
• Requirement Gathering and Analysis involving Communication between the
software development team and customer
• Quick Decision: here design is made and customer decides if he/she is thinks
the Design is taking the project in the right direction.
• Building a Prototype: where prototype is build
• Assessment or User Evaluation :where user evaluates the current prototype
• Prototype Refinement: make changes to the prototype based on customer
feedback
• Engineered Product: involving design, coding ,testing, deploying and
maintainence

• The whole process is repeated till Customer is satisfied with a prototype.

40
.
Advantages of Prototyping model
• Good where requirement are changing/uncommitted
• Errors can be detected much earlier as the system is made side by side.
• Prototypes can be changed and discarded
• facilitates communication and collaboration among team members and
stakeholders
• Flexibility in design.
• developed prototype can be reused by the developer for more complicated
projects in the future.
• customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort

41
.
Disadvantages of Prototyping model
• Require extensive customer collaboration
• Needs committed customer
• Difficult to finish if customer withdraws
• Difficult to know how long the project will take to complete.
• Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback.
• Prototyping tools are expensive.
• Special tools & techniques are required to build a prototype.
• time-consuming
• Expensive for Customer

42
1.4 Agile Software development
• Agile software development is an iterative approach, it focuses on adaptability
and collaboration among cross-functional teams.
• It emphasizes delivering functional software in short, frequent cycles, with quick
feedback and continuous improvement.

• Cross-functional teams are composed of individuals with diverse skills, expertise, and roles necessary to accomplish a
common goal or project.
43
Agile Process and its importance
• The Agile process is a flexible and iterative approach to software development,
emphasizing collaboration, adaptability, and customer feedback. Its importance
lies in its ability to:
• Foster rapid adaptation: Agile enables teams to respond quickly to changes in
requirements, market conditions, or customer feedback, ensuring that the product
remains relevant and valuable.
• Enhance customer satisfaction: By delivering working software in short iterations and
taking customer feedback throughout the development process, Agile ensures that the
final product meets the customer's needs and expectations.
• Promote transparency and collaboration: It encourage close collaboration among team
members, stakeholders, and customers, fostering open communication, understanding,
and collective ownership of project goals, which ultimately leads to more successful
outcomes.
44
Extreme Programming (XP)
• Extreme Programming (XP) is an Agile software development methodology that
focuses on delivering high-quality software through frequent and continuous
feedback, collaboration, and adaptation.
• XP focuses a close working relationship between the development team,
customer, and stakeholders.
• It Focuses on rapid, iterative development and deployment.
• XP is based on the frequent iteration through which the developers implement User Stories.
User stories are simple and informal statements of the customer about the functionalities
needed.
• A User Story is a conventional description by the user of a feature of the required system.
• It does not mention finer details such as the different scenarios that can occur. Based on User
stories, the project team proposes Metaphors.
• Metaphors are a common vision of how the system would work.
• The development team may decide to build a Spike for some features. A Spike is a very
simple program that is constructed to explore the suitability of a solution being proposed. It
can be considered similar to a prototype.
45
Extreme Programming (XP)

Diagram: Extreme Programming (XP)

46
• Basic principles of Extreme programming: .
• The basic activities that are followed during software development by using the
XP model
• Coding: The concept of coding which is used in the XP model is slightly different from traditional
coding. Here, the coding activity includes drawing diagrams (modeling) that will be transformed
into code, scripting a web-based system, and choosing among several alternative solutions.
• Testing: The XP model gives high importance to testing and considers it to be the primary factor in
developing fault-free software.
• Listening: developers need to carefully listen to the customers if they have to develop good
quality software. Sometimes programmers may not have the depth knowledge of the system to
be developed. So, the programmers should understand properly the functionality of the system
and they have to listen to the customers.
• Designing: Without a proper design, a system implementation becomes too complex, and very
difficult to understand the solution, thus making maintenance expensive. A good design results
elimination of complex dependencies within a system. So, effective use of suitable design is
important.
• Feedback: to gain feedback to understand the exact customer needs. Frequent contact with the
customer makes the development effective.

47
• Simplicity: to develop a simple system that will work efficiently in the present time, .
rather than trying to build something that would take time and may never be used. It
focuses on some specific features that are immediately needed, rather than engaging
time and effort on speculations of future requirements.
• Pair Programming: two developers work together at the same workstation. This
approach helps in knowledge sharing, reduces errors, and improves code quality.
• Continuous Integration: developers integrate(COMBINE) their code into a shared
repository several times a day. This helps to detect and resolve integration issues early
on in the development process.
• Refactoring: it is the process of restructuring existing code to make it more efficient and
maintainable.
• Collective Code Ownership: In XP, there is no individual ownership of code. Instead, the
entire team is responsible for the codebase.
• Planning Game: XP follows a planning game, where the customer and the development
team collaborate to prioritize and plan development tasks. This approach helps to ensure
that the team is working on the most important features and delivers value to the
customer.
• On-site Customer: XP requires an on-site customer who works closely with the
development team throughout the project. This approach helps to ensure that the
customer’s needs are understood and met, and also facilitates communication and
feedback.
• A workstation typically refers to a specialized computer designed for technical or scientific applications, such
as engineering, design, or software development
48
Advantages of Extreme Programming (XP)

• Slipped schedules: Timely delivery is ensured through slipping timetables and doable development
cycles.
• Misunderstanding the business and/or domain − Constant contact and explanations are ensured by
including the client on the team.
• Canceled projects: Focusing on ongoing customer engagement guarantees open communication with
the consumer and prompt problem-solving.
• Staff turnover: Teamwork that is focused on cooperation provides excitement and goodwill. Team spirit
is fostered by multidisciplinary cohesion.
• Costs incurred in changes: Extensive and continuing testing ensures that the modifications do not
impair the functioning of the system. A functioning system always guarantees that there is enough
time to accommodate changes without impairing ongoing operations.
• Business changes: Changes are accepted at any moment since they are seen to be inevitable.
• Production and post-delivery defects: the unit tests to find and repair bugs as soon as possible.

49
Adaptive software development
• It is a method to build complex software systems.
• ASD focuses on human collaboration and self-organization.
• Lifecycle of ASD
1.Speculation
2.Collaboration
3.Learning

50
Adaptive software development
1. Speculation
During this phase project is initiated and planning is conducted. The project plan uses
project initiation information like project requirements, user needs, customer mission
statement, etc, to define set of release cycles that the project wants.

2. Collaboration
It is the difficult part of ASD as it needs the workers to be motivated. It collaborates
communication and teamwork but emphasizes individualism as individual creativity
plays a major role in creative thinking. People working together must trust each others
to :
• Work as hard as possible
• Possession of skill set
• Assist without resentment
• Criticize without animosity
• Communicate problems to find effective solution

51
Adaptive software development
3. Learning:
• Learning helps the workers to increase their level of understanding of the
project.
• The learning cycles, challenging all the stakeholders are based on short
iterations with design, build and testing.

• Learning process is of 3 ways:

1. Focus groups
2. Technical reviews
3. Project postmortem

ASD’s overall emphasis on the dynamics of self-organizing teams, interpersonal

collaboration, and individual and team learning yield software project teams
that have a much higher likelihood of success.

52
Scrum

• Scrum is a type of Agile framework.

• It is a framework within which people can address complex adaptive problems
while productivity and creativity of delivering product is at highest possible
values.
• Scrum uses Iterative process.

53
Scrum
Sprints
• Sprints in Scrum are time-boxed iterations, typically lasting 2-4 weeks, where a set of work is
completed.
• They enable teams to deliver a potentially shippable product increment at the end of each sprint.
Sprints provide a pattern for feedback, adaptation, and continuous improvement within the
Scrum framework.

Retrospective
• A retrospective in Scrum is a meeting held at the end of each sprint where the
Scrum Team reflects on their recent work.
• It focuses on what went well, what could be improved, and actions to enhance
future sprints. Retrospectives encourage team collaboration, learning, and
adaptation, contributing to continuous improvement.

54
Scrum
• Product backlog
The product backlog in Scrum is a prioritized list of all desired work on a project,
managed by the Product Owner.
It contains features, bug fixes, and other tasks, with items at the top being more
detailed and ready for implementation in upcoming sprints.
The backlog evolves based on feedback, priorities, and requirements.

55
Scrum
• .

Diagram: Scrum
56
Scrum
Working of Scrum
Product Backlog Creation: The Product Owner collaborates with stakeholders to create and
prioritize a backlog of features, enhancements, and fixes known as the Product Backlog.
Sprint Planning: At the start of each Sprint, the Scrum Team (including the Product Owner, Scrum
Master, and Development Team) meets to select items from the Product Backlog to work on during
the Sprint. They define the Sprint Goal and create a Sprint Backlog, a list of tasks needed to
accomplish the selected items.
Sprint Execution: Throughout the Sprint, the Development Team works on the tasks identified in
the Sprint Backlog. They hold daily stand-up meetings to discuss progress, challenges, and plans for
the next 24 hours. The Scrum Master facilitates these meetings to ensure they stay focused and
productive.
Incremental Development: The Development Team delivers a potentially shippable product
increment at the end of each Sprint. This increment should meet the Definition of Done, a set of
criteria agreed upon by the team that defines what "done" means for the product.

57
Scrum
Sprint Review: At the end of the Sprint, the Scrum Team holds a Sprint Review
meeting with stakeholders to demonstrate the completed work and gather
feedback. Based on this feedback, the Product Backlog may be adjusted and
reprioritized.
Sprint Retrospective: Immediately following the Sprint Review, the Scrum Team
conducts a Sprint Retrospective meeting to reflect on the Sprint process. They
discuss what went well, what could be improved, and action items for the next
Sprint. The goal is to continuously improve the team's effectiveness and efficiency.
Repeat: The Scrum process is iterative, with Sprints occurring one after another.
The cycle repeats, with the Scrum Team continually refining the product backlog,
planning and executing Sprints, and reflecting on their process to deliver high-
quality software incrementally.

58
Scrum

• Roles in Scrum:
1. Product owner
2. Scrum master
3. Scrum team

Product owner
• creates a product backlog ( a wishlist of tasks that need to be prioritized in a project)
• Decides product’s release date
• Prioritize features according to market value
• Accept/ Reject work results.

59
Scrum

Scrum master:
• Scrum master conducts daily meetings
• Ensures that the team is fully functional and productive
• Responsible for management of the project

Scrum team:
• It consists of 5-10 people
• Teams are cross-functional and self-organizing
• Determines which items and in what order they will be executed

60
Scrum

Advantages of Scrum
• Time saving
• Budget friendly
• Team gets clear visibility through Scrum meetings
• Large projects are broken down into small projects
• Customers are involved, so best results are ensured
• Developments are coded & tested during Sprint review

61
Scrum

Disadvantages of Scrum
• Requires strong commitment from all team members
• Once decided, the sprint backlog items cannot be changed
• If any team member leaves in the middle of the the project,it can have a huge negative impact
on the project
• Quality is hard is hard to implement, until the team goes through aggressive testing process

62
Dynamic Systems Development Method (DSDM)

• Dynamic Systems Development Method (DSDM) is an Agile project delivery

framework that focuses on delivering projects incrementally within a fixed time
and budget. It emphasizes collaboration, frequent delivery, and active user
involvement throughout the project lifecycle.
• Prioritize requirements based on business value,
• active involvement of users and stakeholders throughout the development
process.
• close collaboration between the development team and business
representatives.
• DSDM promotes a focus on delivering high-quality, fit-for-purpose solutions that
meet the evolving needs of the business.

63
Dynamic Systems Development Method (DSDM)

• Phases of DSDM
• Pre-project: Assess project feasibility and define scope.
• Feasibility study: Analyze project viability and identify major risks.
• Foundations: Establish project team, roles, and governance.
• Evolutionary development: Iteratively build and deliver solution in timeboxed
iterations.
• Deployment: Transition solution into live environment with user training and
acceptance testing.
• Post-project: Evaluate outcomes, capture lessons learned, and improve
project delivery capabilities.

64
Advantages of DSDM

• Allows for early and frequent delivery of working software, increasing stakeholder
satisfaction.
• Ensures that the delivered product meets user needs and expectations, reducing the risk of
rework and improving overall product quality.
• Supports changing requirements and priorities, enabling teams to respond quickly to market
changes and customer feedback.
• Promotes close collaboration between stakeholders and the development team, fostering a
shared understanding of project goals and priorities.
• Identifies and addresses risks early in the project lifecycle through continuous feedback and
adaptation.

65
.

Disadvantages of DSDM
• Requires active involvement from users throughout the development process, which may be
challenging to maintain, particularly in organizations with limited user availability.
• Managing multiple iterations and evolving requirements can introduce complexity and
overhead, requiring skilled project management and coordination.
• Successful implementation of DSDM requires a skilled and experienced team to manage
complex projects in a dynamic environment, which may be challenging for some
organizations.
• DSDM may face resistance in organizations with rigid cultures, as it requires more
collaborative and flexible ways of working.

66
Crystal

• Crystal is an Agile methodology emphasizes flexibility and adapting to the unique

characteristics of each project.
• Its core principles revolve around communication, teamwork, simplicity, and
reflection.
• Crystal methods vary based on project size, criticality, and team dynamics, with
each variation (such as Crystal Clear, Crystal Orange, etc.) tailored to suit specific
contexts.
• Where the numbers below the crystal blocks represent the team size.(number of
team members)

67
 Crystal

Diagram : Crystal
68
Crystal

Working
• Crystal focuses on frequent communication, early delivery, and continuous
improvement.
• Teams prioritize collaboration and trust, utilizing lightweight processes and tools
tailored to fit the project's needs.
• Regular reflection through retrospectives helps teams adapt and refine their
approach.

69
Advantages
. of Crystal
• Crystal methodologies are highly adaptable, allowing teams to tailor their
approach to the unique characteristics of each project.
• By prioritizing communication and teamwork, Crystal fosters a supportive
environment that encourages creativity and innovation.
• Focus is on simplicity so as to avoid unnecessary overhead. Promotes
efficiency and agility.

Disadvantages of Crystal
• The flexibility of Crystal methodologies can sometimes lead to ambiguity or
uncertainty, particularly for teams unfamiliar with Agile practices.
• Without clear guidelines, there's a risk of processes becoming too informal
or chaotic, impacting productivity and project success.
• some teams may struggle to strike the right balance between flexibility and
structure, leading to challenges in project management and coordination.
70
1.5 Selection criteria for software process model
• Selection criteria for software process models are important for ensuring the success of a
project.
• We can consider the following criteria for selecting a process model for our project
1.Project Type and Associated Risks:
• Different project types (e.g., web development, embedded systems, enterprise software) come
with varying degrees of complexity and uncertainty.
• High-risk projects, where requirements are likely to change or are not well-understood upfront,
may benefit from iterative and flexible models like Agile.
• Low-risk projects with well-defined and stable requirements may be better suited for sequential
models like Waterfall.
2.Requirements of the Project:
• The software process model should align with the project's specific requirements, such as time
constraints, budget limitations, quality expectations, and regulatory compliance needs.
• For projects with evolving requirements, Agile methodologies provide flexibility through iterative
development and frequent feedback loops.
• Projects with strict regulatory or documentation requirements may lean towards more structured
models like Waterfall or V-model.
71
1.5 Selection criteria for software process model

3.Users:
• Consideration of end-users is essential in selecting a software process model.
• Models that emphasize early and continuous user involvement, such as Agile,
are beneficial when user feedback is critical for the success of the project.
• For projects where user requirements are well-understood upfront and
changes are costly, a sequential model like Waterfall might be sufficient.

72