SE Notes
SE Notes
UNIT 1
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.
2. Design Phase:
This phase aims to transform the requirements gathered in the SRS into a suitable form which permits
further coding in a programming language. It defines the overall software architecture together with high level and
detailed design. All this work is documented as a Software Design Document (SDD).
Some Circumstances where the use of the Waterfall model is most suited are:
When the requirements are constant and not changed regularly.
A project is short
The situation is calm
Where the tools and technology used is consistent and is not changing
When resources are well prepared and are available to use.
This model is simple to implement also the number of resources that are required for it is minimal.
The requirements are simple and explicitly declared; they remain unchanged during the entire project development.
The start and end points for each phase is fixed, which makes it easy to cover progress.
The release date for the complete product, as well as its final cost, can be determined before development.
It gives easy to control and clarity for the customer due to a strict reporting system.
In this model, the risk factor is higher, so this model is not suitable for more significant and complex projects.
This model cannot accept the changes in requirements during development.
It becomes tough to go back to the phase. For example, if the application has now shifted to the coding phase, and
there is a change in requirement, It becomes tough to go back and change it.
Since the testing done at a later stage, it does not allow identifying the challenges and risks in the earlier phase, so
the risk reduction strategy is difficult to prepare
Incremental Model :-
Incremental Model is a process of software development where requirements divided into multiple standalone modules
of the software development cycle. In this model, each module goes through the requirements, design, implementation
and testing phases. Every subsequent release of the module adds function to the previous release. The process continues
until the complete system achieved.
The various phases of incremental model are as follows:-
1. Requirement analysis: In the first phase of the incremental model, the product analysis expertise identifies the
requirements. And the system functional requirements are understood by the requirement analysis team. To develop the
software under the incremental model, this phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design of the system functionality and the
development method are finished with success. When software develops new practicality, the incremental model uses
style and development phase.
3. Testing: In the incremental model, the testing phase checks the performance of each existing function as well as
additional functionality. In the testing phase, the various methods are used to test the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the development system. It involves the final
coding that design in the designing and development phase and tests the functionality in the testing phase. After
completion of this phase, the number of the product working is enhanced and upgraded up to the final system product
Spiral Model :-
The spiral model, initially proposed by Boehm, is an evolutionary software process model that couples the iterative
feature of prototyping with the controlled and systematic aspects of the linear sequential model. It implements the
potential for rapid development of new versions of the software. Using the spiral model, the software is developed in a
series of incremental releases. During the early iterations, the additional release may be a paper model or prototype.
During later iterations, more and more complete versions of the engineered system are produced.
1. Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the various alternatives
that are possible for achieving the targets, and the constraints that exists.
2. Risk Assessment and reduction: The next phase in the cycle is to calculate these various alternatives based on the goals
and constraints. The focus of evaluation in this stage is located on the risk perception for the project.
3. Development and validation: The next phase is to develop strategies that resolve uncertainties and risks. This process
may include activities such as benchmarking, simulation, and prototyping.
4. Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to continue with a
further period of the spiral. If it is determined to keep, plans are drawn up for the next step of the project.
In other words, a life cycle model maps the various activities performed on a software product from its inception to
retirement. Different life cycle models may plan the necessary development activities to phases in different ways. Thus, no
element which life cycle model is followed, the essential activities are contained in all life cycle models though the action
may be carried out in distinct orders in different life cycle models. During any life cycle stage, more than one activity may
also be carried out.
Need of SDLC
The development team must determine a suitable life cycle model for a particular plan and then observe to it.
Without using an exact life cycle model, the development of a software product would not be in a systematic and
disciplined manner. When a team is developing a software product, there must be a clear understanding among team
representative about when and what to do. Otherwise, it would point to chaos and project failure. This problem can be
defined by using an example. Suppose a software development issue is divided into various parts and the parts are
assigned to the team members. From then on, suppose the team representative is allowed the freedom to develop the
roles assigned to them in whatever way they like. It is possible that one representative might start writing the code for his
part, another might choose to prepare the test documents first, and some other engineer might begin with the design
phase of the roles assigned to him. This would be one of the perfect methods for project failure.
8.6M
97
Apple Discontinues Last Remaining iPod Model
A software life cycle model describes entry and exit criteria for each phase. A phase can begin only if its stage-entry
criteria have been fulfilled. So without a software life cycle model, the entry and exit criteria for a stage cannot be
recognized. Without software life cycle models, it becomes tough for software project managers to monitor the progress
of the project.
SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes the following steps:
The senior members of the team perform it with inputs from all the stakeholders and domain experts or SMEs in the
industry.
Planning for the quality assurance requirements and identifications of the risks associated with the projects is also done at
this stage.
Business analyst and Project organizer set up a meeting with the client to gather all the data like what the customer wants
to build, who will be the end user, what is the objective of the product. Before creating a product, a core understanding or
knowledge of the product is very necessary.
For Example, A client wants to have an application which concerns money transactions. In this method, the requirement
has to be precise like what kind of operations will be done, how it will be done, in which currency it will be done, etc.
Once the required function is done, an analysis is complete with auditing the feasibility of the growth of a product. In case
of any ambiguity, a signal is set up for further discussion.
Once the requirement is understood, the SRS (Software Requirement Specification) document is created. The developers
should thoroughly follow this document and also should be reviewed by the customer for future reference.
Once the requirement analysis is done, the next stage is to certainly represent and document the software requirements
and get them accepted from the project stakeholders.
This is accomplished through "SRS"- Software Requirement Specification document which contains all the product
requirements to be constructed and developed during the project life cycle.
The next phase is about to bring down all the knowledge of requirements, analysis, and design of the software project.
This phase is the product of the last two, like inputs from the customer and requirement gathering.
In this phase of SDLC, the actual development begins, and the programming is built. The implementation of design begins
concerning writing code. Developers have to follow the coding guidelines described by their management and
programming tools like compilers, interpreters, debuggers, etc. are used to develop and implement the code.
Stage5: Testing
After the code is generated, it is tested against the requirements to make sure that the products are solving the needs
addressed and gathered during the requirements stage.
During this stage, unit testing, integration testing, system testing, acceptance testing are done.
Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is deployed.
Then based on the assessment, the software may be released as it is or with suggested enhancement in the object
segment.
Stage7: Maintenance
Once when the client starts using the developed systems, then the real issues come up and requirements to be solved
from time to time.
This procedure where the care is taken for the developed product is known as maintenance.
Verification:
Verification is the process of checking that a software achieves its goal without any bugs. It is the process to ensure
whether the product that is developed is right or not. It verifies whether the developed product fulfills the
requirements that we have.
Verification is Static Testing.
1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking
Validation:
Validation is the process of checking whether the software product is up to the mark or in other words product has high
level requirements. It is the process of checking the validation of product i.e. it checks what we are developing is the
right product. it is validation of actual and expected product.
Validation is the Dynamic Testing.
Activities involved in validation:
Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high
quality softwares. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations,
reaches completion within times and cost estimates.
SDLC is the acronym of Software Development Life Cycle.
It is also called as Software Development Process.
SDLC is a framework defining tasks performed at each step in the software development process.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines
all the tasks required for developing and maintaining software.
What is SDLC?
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.
The following figure is a graphical representation of the various stages of a typical SDLC.
UNIT 2
Functional Requirements
Functional requirements define a function that a system or system element must be qualified to perform and must be
documented in different forms. The functional requirements describe the behavior of the system as it correlates to the
system's functionality.
Functional requirements should be written in a simple language, so that it is easily understandable. The examples of
functional requirements are authentication, business rules, audit tracking, certification requirements, transaction
corrections, etc.
These requirements allow us to verify whether the application provides all functionalities mentioned in the application's
functional requirements. They support tasks, activities, user goals for easier project management.
There are a number of ways to prepare functional requirements. The most common way is that they are documented in
the text form. Other formats of preparing the functional requirements are use cases, models, prototypes, user stories, and
diagrams.
Non-functional requirements
Non-functional requirements are not related to the software's functional aspect. They can be the necessities that specify
the criteria that can be used to decide the operation instead of specific behaviors of the system. Basic non-functional
requirements are - usability, reliability, security, storage, cost, flexibility, configuration, performance, legal or regulatory
requirements, etc.
Functional requirements help to understand the functions of They help to understand the system's performance.
the system.
They describe what the product does. They describe the working of product.
It concentrates on the user's requirement. It concentrates on the expectation and experience
of the user.
It helps us to verify the software's functionality. It helps us to verify the software's performance.
These requirements are specified by the user. These requirements are specified by the software
developers, architects, and technical persons.
There is functional testing such as API testing, system, There is non-functional testing such as usability,
integration, etc. performance, stress, security, etc.
Examples of the functional requirements are - Examples of the non-functional requirements are -
Authentication of a user on trying to log in to the system. The background color of the screens should be light
blue.
These requirements are important to system operation. These are not always the important requirements,
they may be desirable.
Completion of Functional requirements allows the system to While system will not work only with non-
perform, irrespective of meeting the non-functional functional requirements.
requirements.
Feasibility Study :-
Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or system. Feasibility
study is one of stage among important four stages of Software Project Management Process. As name suggests
feasibility study is the feasibility analysis or it is a measure of the software product in terms of how much beneficial
product development will be for the organization in a practical point of view. Feasibility study is carried out based on
many purposes to analyze whether software product will be right in terms of development, implantation, contribution
of project to the organization etc.
The feasibility study mainly concentrates on below five mentioned areas. Among these Economic Feasibility Study is
most important part of the feasibility analysis and Legal Feasibility Study is less considered feasibility analysis.
1. Technical Feasibility –
2. Operational Feasibility
3. Economic Feasibility
4. Legal Feasibility
5. Schedule Feasibility
The Software Prototyping refers to building software application prototypes which displays the functionality of the
product under development, but may not actually hold the exact logic of the original software.
Software prototyping is becoming very popular as a software development model, as it enables to understand customer
requirements at an early stage of development. It helps get valuable feedback from the customer and helps software
designers and developers understand about what exactly is expected from the product under development.
Prototype is a working model of software with some limited functionality. The prototype does not always hold the exact
logic used in the actual software application and is an extra effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. It also helps
understand the requirements which are user specific and may not have been considered by the developer during product
design.
This step involves understanding the very basics product requirements especially in terms of user interface. The more
intricate details of the internal design and external aspects like performance and security can be ignored at this stage.
The initial Prototype is developed in this stage, where the very basic requirements are showcased and user interfaces are
provided. These features may not exactly work in the same manner internally in the actual software developed. While, the
workarounds are used to give the same look and feel to the customer in the prototype developed.
The prototype developed is then presented to the customer and the other important stakeholders in the project. The
feedback is collected in an organized manner and used for further enhancements in the product under development.
The feedback and the review comments are discussed during this stage and some negotiations happen with the customer
based on factors like – time and budget constraints and technical feasibility of the actual implementation. The changes
accepted are again incorporated in the new Prototype developed and the cycle repeats until the customer expectations
are met.
Prototypes can have horizontal or vertical dimensions. A Horizontal prototype displays the user interface for the product
and gives a broader view of the entire system, without concentrating on internal functions. A Vertical prototype on the
other side is a detailed elaboration of a specific function or a sub system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are used to get more information
on the user interface level and the business requirements. It can even be presented in the sales demos to get business in
the market. Vertical prototypes are technical in nature and are used to get details of the exact functioning of the sub
systems. For example, database requirements, interaction and data processing loads in a given sub system.
Software Prototyping - Types
There are different types of software prototypes used in the industry. Following are the major software prototyping types
used widely −
1. Throwaway/Rapid Prototyping
Throwaway prototyping is also called as rapid or close ended prototyping. This type of prototyping uses very little efforts
with minimum requirement analysis to build a prototype. Once the actual requirements are understood, the prototype is
discarded and the actual system is developed with a much clear understanding of user requirements.
User interface is the front-end application view to which user interacts in order to use the software. The software
becomes more popular if its user interface is:
Attractive
Simple to use
Responsive in short time
Clear to understand
Consistent on all interface screens
Software documentation :-
Software documentation is a written piece of text that is often accompanied with a software program.
This makes the life of all the members associated with the project more easy. It may contain anything from API
documentation, build notes or just help content. It is a very critical process in software development. It’s
primarily an integral part of any computer code development method. Moreover, the computer code
practitioners are a unit typically concerned with the worth, degree of usage and quality of the actual
documentation throughout development and its maintenance throughout the total method. Motivated by the
requirements of Novatel opposition, a world leading company developing package in support of worldwide
navigation satellite system, and based mostly on the results of a former systematic mapping studies area unit
aimed of the higher understanding of the usage and therefore the quality of a varied technical documents
throughout computer code development and there maintenance.
For example before development of any software product requirements are documented which is called as Software
Requirement Specification (SRS). Requirement gathering is considered as an stage of Software Development Life Cycle
(SDLC).
Another example can be a user manual that a user refer for installing, using, and providing maintenance to the software
application/product.
1. Requirement Documentation :
It is the description of how the software shall perform and which environment setup would be
appropriate to have the best out of it. These are generated while the software is under development and is
supplied to the tester groups too.
2. Architectural Documentation :
Architecture documentation is a special type of documentation that concerns the design. It contains
very little code and is more focused on the components of the system, their roles and working. It also shows the
data flows throughout the system.
3. Technical Documentation :
These contain the technical aspects of the software like API, algorithms etc. It is prepared mostly for
the software devs.
4. End-user Documentation :
As the name suggests these are made for the end user. It contains support resources for the end user.
Functional model :-
According to Dennis et al. (2002) “Functional models describe business processes and the interaction of an information
system with its environment.” Business processes are sequential steps that a business follows to deliver a service, i.g.,
fulfilling an order or verifying users. Functional modeling describes the business processes in simple terms to provide a
high-level overview of the system’s requirements.
Functional modeling takes place after the system’s requirement definitions have been identified by using the various
requirement gathering techniques available. Requirement gathering is the first step in system analysis and design and is
used to understand what the system is supposed to do.
The functional model uses the requirements definitions to create use-cases and activity diagrams to create a uses-case
description for each use-case. The result of functional modeling is that it shows the flow of events, and the use-cases
break the requirements definitions into high-level processes.
The last step in functional modeling is to verify that all use cases, activity diagrams, and use-case descriptions align
without contradiction. After verifying the functional model, the next step is structural modeling.
Behavioral model :-
Behavioral modeling describes how the identified objects in structural modeling interact and communicate to fulfill the
uses cases that make up the business processes. Behavioral modeling allows the analyst to understand the behavior of
objects, such as adding user objects, editing, or deleting a comment in a blog post. In the development stage, the
objects’ behaviors are implemented as methods.
Behavioral modeling describes how the identified objects in structural modeling interact and communicate to fulfill the
uses cases that make up the business processes.
Before behavioral modeling is applied, the analyst must first understand the functional and structural models of the
system Dennis et al. (2002). In some instances, the analyst will make changes to the functional and structural models as
a result of gaining new insight during the behavioral stage. That is an example of how the functional, structural, and
behavior models work together to describe a system.
The methods used to describe behavior modeling are interaction diagrams, behavioral state machines, and CRUDE
matrix (create, read, update, delete, execute).
Just like functional and structural modeling, behavioral modeling also needs to be verified by checking the consistency
in sequence diagrams, communication diagrams, behavioral state machines, and CRUDE.
Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical
way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing system and
develop a new system specification which can be easily understandable by user.
During Structured Analysis, various tools and techniques are used for system development. They are −
Data Dictionary:-
A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all DFD data
elements that is, details and definitions of data flows, data stores, data stored in data stores, and the processes.
A data dictionary improves the communication between the analyst and the user. It plays an important role in building a
database. Most DBMSs have a data dictionary as a standard feature. For example, refer the following table −