0% found this document useful (0 votes)
67 views11 pages

SE Notes

SE notes

Uploaded by

Sateesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
67 views11 pages

SE Notes

SE notes

Uploaded by

Sateesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 11

Agile Development Model

 In earlier days, the Iterative Waterfall Model was very popular for completing a project.
 But nowadays, developers face various problems while using it to develop software.
 The main difficulties included handling customer change requests during project
development and the high cost and time required to incorporate these changes.
 To overcome these drawbacks of the Waterfall Model, in the mid-1990s the Agile Software
Development model was proposed.
 The Agile Model was primarily designed to help a project adapt quickly to change requests.
So, the main aim of the Agile model is to facilitate quick project completion.
 To accomplish this task, agility is required. Agility is achieved by fitting the process to the
project and removing activities that may not be essential for a specific project.
 Also, anything that is a waste of time and effort is avoided.
 The Agile Model refers to a group of development processes.

Agile SDLC Models/Methods


 Crystal Agile methodology: The Crystal Agile Software Development Methodology places
a strong emphasis on fostering effective communication and collaboration among team
members, as well as taking into account the human elements that are crucial for a successful
development process. This methodology is particularly beneficial for projects with a high
degree of uncertainty, where requirements tend to change frequently.
 Dynamic Systems Development Method (DSDM): DSDSM methodology is tailored for
projects with moderate to high uncertainty where requirements are prone to change
frequently. Its clear-cut roles and responsibilities focus on delivering working software in
short time frames. Governance practices set it apart and make it an effective approach for
teams and projects.
 Feature-driven development (FDD): FDD approach is implemented by utilizing a series
of techniques, like creating feature lists, conducting model evaluations, and implementing a
design-by-feature method, to meet its goal. This methodology is particularly effective in
ensuring that the end product is delivered on time and that it aligns with the requirements of
the customer.
 Scrum: Scrum methodology serves as a framework for tackling complex projects and
ensuring their successful completion. It is led by a Scrum Master, who oversees the process,
and a Product Owner, who establishes the priorities. The Development Team, accountable
for delivering the software, is another key player.
 Extreme Programming (XP): Extreme Programming uses specific practices like pair
programming, continuous integration, and test-driven development to achieve these goals.
Extreme programming is ideal for projects that have high levels of uncertainty and require
frequent changes, as it allows for quick adaptation to new requirements and feedback.
 Lean Development: Lean Development is rooted in the principles of lean manufacturing
and aims to streamline the process by identifying and removing unnecessary steps and
activities. This is achieved through practices such as continuous improvement, visual
management, and value stream mapping, which helps in identifying areas of improvement
and implementing changes accordingly.
 Unified Process: Unified Process is a methodology that can be tailored to the specific
needs of any given project. It combines elements of both waterfall and Agile
methodologies, allowing for an iterative and incremental approach to development. This
means that the UP is characterized by a series of iterations, each of which results in a
working product increment, allowing for continuous improvement and the delivery of value
to the customer.

Steps in the Agile Model


The agile model is a combination of iterative and incremental process models. The steps involve in
agile SDLC models are:

 Requirement gathering
 Design the Requirements
 Construction / Iteration
 Testing / Quality Assurance
 Deployment
 Feedback

1. Requirement Gathering:- In this step, the development team must gather the
requirements, by interaction with the customer. development team should plan the time and
effort needed to build the project. Based on this information you can evaluate technical and
economical feasibility.
2. Design the Requirements:- In this step, the development team will use user-flow-diagram
or high-level UML diagrams to show the working of the new features and show how they
will apply to the existing software. Wireframing and designing user interfaces are done in
this phase.
3. Construction / Iteration:- In this step, development team members start working on their
project, which aims to deploy a working product.
4. Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing ,
and System Testing. A brief introduction of these three tests is as follows:
 Unit Testing:- Unit testing is the process of checking small pieces of code to
ensure that the individual parts of a program work properly on their own. Unit
testing is used to test individual blocks (units) of code.
 Integration Testing:- Integration testing is used to identify and resolve any issues
that may arise when different units of the software are combined.
 System Testing:- Goal is to ensure that the software meets the requirements of the
users and that it works correctly in all possible scenarios.
5. Deployment:- In this step, the development team will deploy the working project to end
users.
6. Feedback:- This is the last step of the Agile Model. In this, the team receives feedback
about the product and works on correcting bugs based on feedback provided by the
customer.

Principles of the Agile Model


 To establish close contact with the customer during development and to gain a clear
understanding of various requirements, each Agile project usually includes a customer
representative on the team. At the end of each iteration stakeholders and the customer
representative review, the progress made and re-evaluate the requirements.
 The agile model relies on working software deployment rather than comprehensive
documentation.
 Frequent delivery of incremental versions of the software to the customer representative in
intervals of a few weeks.
 Requirement change requests from the customer are encouraged and efficiently
incorporated.
 It emphasizes having efficient team members and enhancing communications among them
is given more importance. It is realized that improved communication among the
development team members can be achieved through face-to-face communication rather
than through the exchange of formal documents.
 It is recommended that the development team size should be kept small (5 to 9 people) to
help the team members meaningfully engage in face-to-face communication and have a
collaborative work environment.
 The agile development process usually deploys Pair Programming . In Pair programming,
two programmers work together at one workstation. One does coding while the other
reviews the code as it is typed in. The two programmers switch their roles every hour or so.

Characteristics of the Agile Process


 Agile processes must be adaptable to technical and environmental changes. That means if
any technological changes occur, then the agile process must accommodate them.
 The development of agile processes must be incremental. That means, in each development,
the increment should contain some functionality that can be tested and verified by the
customer.
 The customer feedback must be used to create the next increment of the process.
 The software increment must be delivered in a short span of time.
 It must be iterative so that each increment can be evaluated regularly.

When To Use the Agile Model?


 When frequent modifications need to be made, this method is implemented.
 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with the team all the time.
 when the project needs to be delivered quickly.
 Projects with few regulatory requirements or not certain requirements.
 projects utilizing a less-than-strict current methodology
 Those undertakings where the product proprietor is easily reachable
 Flexible project schedules and budgets.
Advantages of the Agile Model
 Working through Pair programming produces well-written compact programs which have
fewer errors as compared to programmers working alone.
 It reduces the total development time of the whole project.
 Agile development emphasizes face-to-face communication among team members, leading
to better collaboration and understanding of project goals.
 Customer representatives get the idea of updated software products after each iteration. So,
it is easy for him to change any requirement if needed.
 Agile development puts the customer at the center of the development process, ensuring
that the end product meets their needs.
Disadvantages of the Agile Model
 The lack of formal documents creates confusion and important decisions taken during
different phases can be misinterpreted at any time by different team members.
 It is not suitable for handling complex dependencies.
 The agile model depends highly on customer interactions so if the customer is not clear,
then the development team can be driven in the wrong direction.
 Agile development models often involve working in short sprints, which can make it
difficult to plan and forecast project timelines and deliverables. This can lead to delays in
the project and can make it difficult to accurately estimate the costs and resources needed
for the project.
 Agile development models require a high degree of expertise from team members, as they
need to be able to adapt to changing requirements and work in an iterative environment.
This can be challenging for teams that are not experienced in agile development practices
and can lead to delays and difficulties in the project.
 Due to the absence of proper documentation, when the project completes and the developers
are assigned to another project, maintenance of the developed project can become a
problem.

Spiral Model
 The Spiral Model is one of the most important Software Development Life Cycle models.
The Spiral Model is a combination of the waterfall model and the iterative model.
 It provides support for Risk Handling.
 The Spiral Model was first proposed by Barry Boehm.
 In its diagrammatic representation, looks like a spiral with many loops.
 The exact number of loops of the spiral is unknown and can vary from project to project.
 Each loop of the spiral is called a phase of the software development process.
Some Key Points regarding the phase of a Spiral Model:
 The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks.
 As the project manager dynamically determines the number of phases, the project manager
has an important role in developing a product using the spiral model.
 It is based on the idea of a spiral, with each iteration of the spiral representing a complete
software development cycle, from requirements gathering and analysis to design,
implementation, testing, and maintenance.
Phases of the Spiral Model
The Spiral Model is a risk-driven model, meaning that the focus is on managing risk through
multiple iterations of the software development process. It consists of the following phases:

1. Objectives Defined: In first phase of the spiral model we clarify what the project aims to
achieve, including functional and non-functional requirements.

2. Risk Analysis: In the risk analysis phase, the risks associated with the project are identified
and evaluated.

3. Engineering: In the engineering phase, the software is developed based on the


requirements gathered in the previous iteration.

4. Evaluation: In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.

5. Planning: The next iteration of the spiral begins with a new planning phase, based on the
results of the evaluation.
1. Objectives determination and identify alternative solutions: Requirements are gathered
from the customers and the objectives are identified, elaborated, and analyzed at the start of
every phase. Then alternative solutions possible for the phase are proposed in this quadrant.

2. Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution
are identified and the risks are resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.

3. Develop the next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.

4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-
far developed version of the software. In the end, planning for the next phase is started.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.


1. Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the risk
analysis and risk handling at every phase.

2. Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.

3. Flexibility in Requirements: Change requests in the Requirements at a later phase can be


incorporated accurately by using this model.

4. Customer Satisfaction: Customers can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.

5. Iterative and Incremental Approach: The Spiral Model provides an iterative and incremental
approach to software development, allowing for flexibility and adaptability in response to
changing requirements or unexpected events.

6. Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the software
development process.

7. Improved Communication: The Spiral Model provides for regular evaluations and reviews,
which can improve communication between the customer and the development team.

8. Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability.

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.

1. Complex: The Spiral Model is much more complex than other SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as it is expensive.

3. Too much dependability on Risk Analysis: The successful completion of the project is very
much dependent on Risk Analysis. Without very highly experienced experts, it is going to be
a failure to develop a project using this model.

4. Difficulty in time management: As the number of phases is unknown at the start of the
project, time estimation is very difficult.

5. Complexity: The Spiral Model can be complex, as it involves multiple iterations of the
software development process.

6. Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple


evaluations and reviews.

7. Resource Intensive: The Spiral Model can be resource-intensive, as it requires a significant


investment in planning, risk analysis, and evaluations.
Metrics for software project size estimation
 Accurate estimation of the problem size is fundamental to satisfactory estimation of effort,
time duration and cost of a software project.
 In order to be able to accurately estimate the project size, some important metrics should be
defined in terms of which the project size can be expressed.
 The project size is a measure of the problem complexity in terms of the effort and time
required to develop the product.
 Currently two metrics are popularly being used widely to estimate size:
1- lines of code (LOC)
2- 2- function point (FP)

1. Lines of Code (LOC)

As the name suggests, LOC counts the total number of lines of source code in a project. The units of
LOC are:

1. KLOC: Thousand lines of code

2. NLOC: Non-comment lines of code

3. KDSI: Thousands of delivered source instruction

 The size is estimated by comparing it with the existing systems of the same kind. The experts
use it to predict the required size of various components of software and then add them to
get the total size.

 It’s tough to estimate LOC by analyzing the problem definition. Only after the whole code has
been developed can accurate LOC be estimated. This statistic is of little utility to project
managers because project planning must be completed before development activity can
begin.

 Two separate source files having a similar number of lines may not require the same effort. A
file with complicated logic would take longer to create than one with simple logic. Proper
estimation may not be attainable based on LOC.

 The length of time it takes to solve an issue is measured in LOC. This statistic will differ
greatly from one programmer to the next. A seasoned programmer can write the same logic
in fewer lines than a newbie coder.

Advantages:

1. Universally accepted and is used in many models like COCOMO.

2. Estimation is closer to the developer’s perspective.

3. Both people throughout the world utilize and accept it.

4. At project completion, LOC is easily quantified.

5. It has a specific connection to the result.

6. Simple to use.
Disadvantages:

1. Different programming languages contain a different number of lines.

2. No proper industry standard exists for this technique.

3. It is difficult to estimate the size using this technique in the early stages of the project.

4. When platforms and languages are different, LOC cannot be used to normalize.

4. Function Point Analysis

In this method, the number and type of functions supported by the software are utilized to find
FPC(function point count). The steps in function point analysis are:

1. Count the number of functions of each proposed type.

2. Compute the Unadjusted Function Points(UFP).

3. Find the Total Degree of Influence(TDI).

4. Compute Value Adjustment Factor(VAF).

5. Find the Function Point Count(FPC).

The explanation of the above points is given below:

1. Count the number of functions of each proposed type:

Find the number of functions belonging to the following types:

 External Inputs: Functions related to data entering the system.

 External outputs: Functions related to data exiting the system.

 External Inquiries: They lead to data retrieval from the system but don’t change the system.

 Internal Files: Logical files maintained within the system. Log files are not included here.

 External interface Files: These are logical files for other applications which are used by our
system.

2. Compute the Unadjusted Function Points(UFP):

Categorize each of the five function types as simple, average, or complex based on their complexity.
Multiply the count of each function type with its weighting factor and find the weighted sum. The
weighting factors for each type based on their complexity are as follows:

Function type Simple Average Complex

External Inputs 3 4 6

External Output 4 5 7
Function type Simple Average Complex

External Inquiries 3 4 6

Internal Logical Files 7 10 15

External Interface Files 5 7 10

3. Find the Total Degree of Influence:

Use the ’14 general characteristics of a system to find the degree of influence of each of them. The
sum of all 14 degrees of influence will give the TDI. The range of TDI is 0 to 70. The 14 general
characteristics are: Data Communications, Distributed Data Processing, Performance, Heavily Used
Configuration, Transaction Rate, On-Line Data Entry, End-user Efficiency, Online Update, Complex
Processing Reusability, Installation Ease, Operational Ease, Multiple Sites and Facilitate Change.
Each of the above characteristics is evaluated on a scale of 0-5.

4. Compute Value Adjustment Factor(VAF):

Use the following formula to calculate VAF:

VAF = (TDI * 0.01) + 0.65

5. Find the Function Point Count:

Use the following formula to calculate FPC:

FPC = UFP * VAF

Advantages:

1. It can be easily used in the early stages of project planning.

2. It is independent of the programming language.

3. It can be used to compare different projects even if they use different technologies(database,
language, etc).

Disadvantages:

1. It is not good for real-time systems and embedded systems.

2. Many cost estimation models like COCOMO use LOC and hence FPC must be converted to
LOC.

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of


files)*10 + (Number of interfaces)*10

Number of inputs: Each data item input by the user is counted. Data inputs should be distinguished
from user inquiries. Inquiries are user commands such as print-account-balance. Inquiries are
counted separately. It must be noted that individual data items input by the user are not considered
in the calculation of the number of inputs, but a group of related inputs are considered as a single
input.

For example, while entering the data concerning an employee to an employee pay roll software; the
data items name, age, sex, address, phone number, etc. are together considered as a single input. All
these data items can be considered to be related, since they pertain to a single employee.

Number of outputs: The outputs considered refer to reports printed, screen outputs, error messages
produced, etc. While outputting the number of outputs the individual data items within a report are
not considered, but a set of related data items is counted as one input.

Number of inquiries: Number of inquiries is the number of distinct interactive queries which can be
made by the users. These inquiries are the user commands which require specific action by the
system.

Number of files: Each logical file is counted. A logical file means groups of logically related data.
Thus, logical files can be data structures or physical files.

Number of interfaces: Here the interfaces considered are the interfaces used to exchange
information with other systems.

Examples of such interfaces are data files on tapes, disks, communication links with other systems
etc.

You might also like