SE Notes
SE Notes
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.
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.
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.
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.
2. Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
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.
1. Complex: The Spiral Model is much more complex than other SDLC models.
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.
As the name suggests, LOC counts the total number of lines of source code in a project. The units of
LOC are:
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:
6. Simple to use.
Disadvantages:
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.
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:
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.
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:
External Inputs 3 4 6
External Output 4 5 7
Function type Simple Average Complex
External Inquiries 3 4 6
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.
Advantages:
3. It can be used to compare different projects even if they use different technologies(database,
language, etc).
Disadvantages:
2. Many cost estimation models like COCOMO use LOC and hence FPC must be converted to
LOC.
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.