Professional Documents
Culture Documents
Software Engeenering Unit-I Notes
Software Engeenering Unit-I Notes
Software Engeenering Unit-I Notes
Components of Software:
There are three components of the software: These are : Program, Documentation, and
Operating Procedures.
1. Program –
A computer program is a list of instructions that tell a computer what to do.
2. Documentation –
Source information about the product contained in design documents, detailed code
comments, etc.
3. Operating Procedures –
Set of step-by-step instructions compiled by an organization to help workers carry out
complex routine operations.
4. Code: the instructions that a computer executes in order to perform a specific task or set
of tasks.
6. User interface: the means by which the user interacts with the software, such as buttons,
menus, and text fields.
7. Libraries: pre-written code that can be reused by the software to perform common
tasks.
8. Documentation: information that explains how to use and maintain the software, such
as user manuals and technical guides.
9. Test cases: a set of inputs, execution conditions, and expected outputs that are used to
test the software for correctness and reliability.
10. Configuration files: files that contain settings and parameters that are used to configure
the software to run in a specific environment.
11. Build and deployment scripts: scripts or tools that are used to build, package, and
deploy the software to different environments.
12. Metadata: information about the software, such as version numbers, authors, and
copyright information.
Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a quality product
does precisely what the users want it to do. For software products, the fitness of use is
generally explained in terms of satisfaction of the requirements laid down in the SRS
document. Although "fitness of purpose" is a satisfactory interpretation of quality for many
devices such as a car, a table fan, a grinding machine, etc.for software products, "fitness of
purpose" is not a wholly satisfactory definition of quality.
Example: Consider a functionally correct software product. That is, it performs all tasks as
specified in the SRS document. But, has an almost unusable user interface. Even though it
may be functionally right, we cannot consider it to be a quality product.
1. Functionality: The software meets the requirements and specifications that it was
designed for, and it behaves as expected when it is used in its intended environment.
2. Usability: The software is easy to use and understand, and it provides a positive user
experience.
3. Reliability: The software is free of defects and it performs consistently and accurately
under different conditions and scenarios.
4. Performance: The software runs efficiently and quickly, and it can handle large
amounts of data or traffic.
5. Security: The software is protected against unauthorized access and it keeps the data
and functions safe from malicious attacks.
6. Maintainability: The software is easy to change and update, and it is well-documented,
so that it can be understood and modified by other developers.
7. Reusability: The software can be reused in other projects or applications, and it is
designed in a way that promotes code reuse.
8. Scalability: The software can handle an increasing workload and it can be easily
extended to meet the changing requirements.
9. Testability: The software is designed in a way that makes it easy to test and validate,
and it has comprehensive test coverage.
More knowledgeable and demanding than ever before, today's consumers require software
that is not only appropriate for the task at hand but also user-friendly, dependable, and
expandable. In order to deliver these features within the specified timeframe, software
development teams must rapidly comprehend customer needs, translate them into features
that can be implemented, and do all of this within a short period of time. With careful
preparation, transparent communication, and an emphasis on quality, the challenge may be
addressed.
The majority of software projects have hundreds, if not thousands, of bugs, according to a
Microsoft study. Therefore, one of the main difficulties in creating quality software is making
sure it is bug-free. Even worse, at times when a defect is fixed, additional bugs are created.
How therefore can we make sure the software is error-free?
Utilizing static analysis tools is the solution. A software program's source code is examined
using static analysis software to check for any problems. Static analysis tools help us detect
and solve flaws before they become a problem, and they also help us reduce the number of
new bugs that are added when old ones are fixed.
Budget and time restrictions might provide a significant obstacle when it comes to creating
excellent software. On the one hand, you want to move swiftly and deliver new features
frequently, but on the other hand, you need to be careful not to spend too much money or
make unnecessary concessions in order to stay under budget. Finding a balance between these
two conflicting goals is crucial. Setting priorities and allocating resources appropriately is
one approach to do this.
For instance, you might want to prioritize important features first and worry about less
important features afterward. Alternatively, you might have to pick between many sellers
based on both price and quality. The key is to have a clear plan. These actions can help you
create excellent software without spending a fortune.
Establishing security protocols to safeguard your data is essential while creating software for
your company or client. The security of your program must be ensured against unwanted
access. Additionally, no unauthorized parties can access your data. This can be done in a
number of ways. The most effective approach for you will depend on the kind of software
you're developing and the data you need to safeguard. But regardless of the specifics, it's
critical to keep in mind that online security is continuously changing, so you need to be
informed about the most recent dangers and effective defenses. By taking precautions to
safeguard your data now, you may contribute to the long-term security of your software.
It's crucial to have a system that can be quickly scaled as your organization expands. Long-
term, this will save you both time and money. So you won't need to redesign your system
each time your firm grows. There are a few considerations to make while creating a scalable
system, though. Prior to anything further, check that your code is orderly and modular. As
your firm grows, this will make it simpler to add additional features and functions. Second,
whenever you can, use common libraries and frameworks. You will need to create less
custom code as a result of this. Lastly, utilize cloud services when you can. This will make it
simple and inexpensive for you to extend your system. These pointers can help you create a
system that is simple to scale as your business grows.
(vi)The right software development team selection
Finally, finding the proper software development team is just as important as having a
brilliant idea. They will help you realize your vision. Though, it can be challenging to start
when there are so many possibilities.
2. It is a rapidly evolving field, and new tools and technologies are constantly being
developed to improve the software development process.
6. Software Engineering ensures that the software that has to be built should be
consistent, correct, also on budget, on time, and within the required requirements.
2. Efficiency: The software should not make wasteful use of computing devices such as
memory, processor cycles, etc.
4. Reusability: A software product has good reusability if the different modules of the
product can easily be reused to develop new products.
5. Testability: Here software facilitates both the establishment of test criteria and the
evaluation of the software with respect to those criteria.
7. Portability: In this case, the software can be transferred from one computer system or
environment to another.
8. Adaptability: In this case, the software allows differing system constraints and the user
needs to be satisfied by making changes to the software.
There are several advantages to using a systematic and disciplined approach to software
development, such as:
2. Increased Productivity: Using modern tools and methodologies can streamline the
development process, allowing developers to be more productive and complete projects
faster.
3. Better Maintainability: Software that is designed and developed using sound software
engineering practices is easier to maintain and update over time.
8. Better Security: By following the Software Development Life Cycle (SDLC) and
performing security testing, software engineering can help to prevent security breaches
and protect sensitive data.
Basic Principles of Good Software Engineering approach
1. One of the basic software Engineering principles is Better Requirement analysis which
gives a clear vision of the project. At last, a good understanding of user requirements
provides value to its users by delivering a good software product that meets users’
requirements.
2. All designs and implementations should be as simple as possible mean the KISS (Keep
it Simple, Stupid) principle should be followed. It makes code so simple as a result
debugging and further maintenance become simple.
3. Maintaining the vision of the project is the most important thing throughout complete
development process for the success of a software project. A clear vision of the project
leads to the development of the project in the right way.
6. Think then Act is a must-required principle for software engineering means before
starting developing functionality first it requires to think about application architecture,
as good planning on the flow of project development produces better results.
7. Sometimes developer adds up all functionalities together but later find no use of that. So
following the Never add extra principle is important as it implements what actually
needed and later implements what are required which saves effort and time.
8. When other developers work with another’s code they should not be surprised and
should not waste their time in getting code. So providing better Documentation at
required steps is a good way of developing software projects.
11. Principle of Consistency is important in coding style and designing GUI (Graphical
User Interface) as consistent coding style gives an easier reading of code and
consistency in GUI makes user learning easier in dealing with interface and in using the
software.
12. Never waste time if anything is required and that already exists at that time take the
help of Open source and fix it in your own way as per requirement.
13. Performing continuous validation helps in checking software system meets requirement
specifications and fulfills its intended purpose which helps in better software quality
control.
14. To exit in current technology market trends Using modern programming practices is
important to meet users’ requirements in the latest and advanced way.
To manage the cost: Software engineering programmers plan everything and reduce all
those things that are not required.
To decrease time: It will save a lot of time if you are developing software using a
software engineering technique.
Effectiveness: Effectiveness results from things being created in accordance with the
standards.
Reduces complexity: Large challenges are broken down into smaller ones and solved
one at a time in software engineering. Individual solutions are found for each of these
issues.
Productivity: Because it contains testing systems at every level, proper care is done to
maintain software productivity.
Software Crisis – Software Engineering
Software Crisis is a term used in computer science for the difficulty of writing useful and
efficient computer programs in the required time. The software crisis was due to using the
same workforce, same methods, and same tools even though rapidly increasing software
demand, the complexity of software, and software challenges. With the increase in software
complexity, many software problems arise because existing methods were insufficient.
If we use the same workforce, same methods, and same tools after the fast increase in
software demand, software complexity, and software challenges, then there arise some
issues like software budget problems, software efficiency problems, software
quality problems, software management, and delivery problems, etc. This condition is
called a Software Crisis.
The cost of owning and maintaining software was as expensive as developing the
software.
There is no single solution to the crisis. One possible solution to a software crisis
is Software Engineering because software engineering is a systematic, disciplined, and
quantifiable approach. For preventing software crises, there are some guidelines:
SDLC is a process followed for a software project, within a software organization. It consists
of a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
Requirement analysis is the most important and fundamental stage in SDLC. It is performed
by the senior members of the team with inputs from the customer, the sales department,
market surveys and domain experts in the industry. This information is then used to plan the
basic project approach and to conduct product feasibility study in the economical, operational
and technical areas.
Planning for the quality assurance requirements and identification of the risks associated with
the project is also done in the planning stage. The outcome of the technical feasibility study is
to define the various technical approaches that can be followed to implement the project
successfully with minimum risks.
Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This
is done through an SRS (Software Requirement Specification) document which consists of
all the product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.
This DDS is reviewed by all the important stakeholders and based on various parameters as
risk assessment, product robustness, design modularity, budget and time constraints, the best
design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if
any). The internal design of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.
In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate the code.
Different high level programming languages such as C, C++, Pascal, Java and PHP are used
for coding. The programming language is chosen with respect to the type of software being
developed.
This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the
testing only stage of the product where product defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the SRS.
Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of that
organization. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market, its
maintenance is done for the existing customer base.
Software Process Model
A software process model is an abstraction of the actual process, which is being described.
It can also be defined as a simplified representation of a software process. Each model
represents a process from a specific perspective.
Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and
do not overlap. The developer must complete every phase before the next phase begins. This
model is named "Waterfall Model", because its diagrammatic representation resembles a
cascade of waterfalls.
3. Design
The goal of this phase is to convert the requirements acquired in the SRS into a format that
can be coded in a programming language. It includes high-level and detailed design as well
as the overall software architecture. A Software Design Document is used to document all
of this effort (SDD).
Alpha testing: Alpha testing is the system testing performed by the development team.
Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
Acceptance testing: After the software has been delivered, the customer performed
acceptance testing to determine whether to accept the delivered software or reject it.
6. Maintenance
Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is 60% of the total effort spent to develop a full software. There are basically
three types of maintenance.
Corrective Maintenance: This type of maintenance is carried out to correct errors that
were not discovered during the product development phase.
Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as working on a new computer platform or
with a new operating system.
The classical waterfall model is an idealistic model for software development. It is very
simple, so it can be considered the basis for other software development life cycle models.
Below are some of the major advantages of this SDLC model.
Easy to Understand: Classical Waterfall Model is very simple and easy to understand.
Individual Processing: Phases in the Classical Waterfall model are processed one at a
time.
Properly Defined: In the classical waterfall model, each stage in the model is clearly
defined.
Clear Milestones: Classical Waterfall model has very clear and well-understood
milestones.
Properly Documented: Processes, actions, and results are very well documented.
Reinforces Good Habits: Classical Waterfall Model reinforces good habits like define-
before-design and design-before-code.
Working: Classical Waterfall Model works well for smaller projects and projects
where requirements are well understood.
The Classical Waterfall Model suffers from various shortcomings, basically, we can’t use it
in real projects, but we use other software development lifecycle models which are based
on the classical waterfall model. Below are some major drawbacks of this model.
No Feedback Path: In the classical waterfall model evolution of software from one
phase to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for
error correction.
Difficult to accommodate Change Requests: This model assumes that all the
customer requirements can be completely and correctly defined at the beginning of the
project, but actually customer’s requirements keep on changing with time. It is difficult
to accommodate any change requests after the requirements specification phase is
complete.
No Overlapping of Phases: This model recommends that a new phase can start only
after the completion of the previous phase. But in real projects, this can’t be maintained.
To increase efficiency and reduce cost, phases may overlap.
Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or
uncertain requirements. Once a phase has been completed, it is difficult to make
changes or go back to a previous phase.
Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential
approach, which means that stakeholders are typically involved in the early phases of
the project (requirements gathering and analysis) but may not be involved in the later
phases (implementation, testing, and deployment).
Late Defect Detection: In the Waterfall Model, testing is typically done toward the end
of the development process. This means that defects may not be discovered until late in
the development process, which can be expensive and time-consuming to fix.
Lengthy Development Cycle: The Waterfall Model can result in a lengthy
development cycle, as each phase must be completed before moving on to the next. This
can result in delays and increased costs if requirements change or new issues arise.
Not Suitable for Complex Projects: The Waterfall Model is not well-suited for
complex projects, as the linear and sequential nature of the model can make it difficult
to manage multiple dependencies and interrelated components.
In practice, it is not possible to strictly follow the classical waterfall model for software
development work. In this context, we can view the iterative waterfall model as making
necessary changes to the classical waterfall model so that it becomes applicable to practical
software development projects.
In Iterative waterfall model, the feedback paths are provided from every phase to its
preceding phase as shown in Figure.
The feedback paths allow for correction of the errors committed during a phase, as and when
these are detected in a later phase.
For example, if during a testing a design error is identified, then the feedback path allows the
design to be reworked and the changes to be reflected in the design documents. However,
observe that there is no feedback path to the feasibility stage. This means that the feasibility
study errors cannot be corrected.
The iterative waterfall model is the most widely used software development model evolved
so far.
Build and fix model is an approach and model used for building a software product,
consisting of only two phases.
o The Build Phase.
o The Fix Phase.
The Build & Fix model does not contains the specification and requirement analysis
phase which causes multiple time modifications the software product according to the
need of the user.
In this model, the build phase constitutes of code generation. Developers tries to
develop the code for the software product without any requirement specification
document, flowchart or design blue print. The development is done directly.
Once developed, it is handed over to the client without any testing possibilities. The
client checks the software functions, features and behavior. Upon which if any feature
or function does not performs properly, the developer needs to make the changes
again.
This process goes on and on until the client is completely satisfied with the developed
software product. But with repeated changes the software, it might become impossible
to make changes in the code causing more problems.
Hence, it is not advisable to use Build & Fix model for project of larger sizes as
maintenance is not possible if this model is used.
Prototype Model
The prototype model requires that before carrying out the development of actual software, a
working prototype of the system should be built. A prototype is a toy implementation of the
system. A prototype usually turns out to be a very crude version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient performance as
compared to actual software. In many instances, 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.
Iterative Model
In the iterative model first, we take the initial requirements then we enhance the product
over multiple iterations until the final product gets ready. In every iteration, some design
modifications were made and some changes in functional requirements is added. The main
idea behind this approach is to build the final product through multiple iterations that result
in the final product being almost the same as the user wants with fewer errors and the
performance, and quality would be high.
Incremental Model
In the incremental model, we first build the project with basic features and then evolve the
project in every iteration , it is mainly used for large projects. The first step is to gather the
requirements and then perform analysis, design, code, and test and this process goes the
same over and over again until our final project is ready.
Spiral Model
The spiral model is a combination of waterfall and iterative models and in this, we focused
on risk handling along with developing the project with the incremental and iterative
approach, producing the output quickly as well as it is good for big projects. The software
is created through multiple iterations using a spiral approach. Later on, after successive
development the final product will develop, and the customer interaction is there so the
chances of error get reduced.
Advantages of the Evolutionary Process Model
1. During the development phase, the customer gives feedback regularly because the
customer’s requirement gets clearly specified.
2. After every iteration risk gets analyzed.
3. Suitable for big complex projects.
4. The first build gets delivered quickly as it used an iterative and incremental approach.
5. Enhanced Flexibility: The iterative nature of the model allows for continuous changes
and refinements to be made, accommodating changing requirements effectively.
6. Risk Reduction: The model’s emphasis on risk analysis during each iteration helps in
identifying and mitigating potential issues early in the development process.
7. Adaptable to Changes: Since changes can be incorporated at the beginning of each
iteration, it is well-suited for projects with evolving or uncertain requirements.
8. Customer Collaboration: Regular customer feedback throughout the development
process ensures that the end product aligns more closely with the customer’s needs and
expectations.