Chapter - 1

Software life cycle models

 Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software.
 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.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

 Requirement Analysis is the most important and necessary 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.

Stage 2: Defining Requirements

 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.
 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.

Stage 3: Designing the Product Architecture

 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.

https://onlinecollegenotes.com
Stage 4: Developing the project

 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.

Stage 5: Testing

 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.

Stage 6: Deployment in the Market and Maintenance

 Once the software is certified, and no bugs or errors are stated, then it is deployed.
 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.

Software Development Paradigm

 The software development paradigm helps a developer to select a strategy to develop the software.
 A software development paradigm has its own set of tools, methods, and procedures, which are
expressed clearly and defines software development life cycle.

1. Waterfall Model
 Waterfall model is the simplest model of software development paradigm.
 All the phases of SDLC will function one after another in linear manner. That is, when the first
phase is finished then only the second phase will start and so on.
 This model assumes that everything is carried out and taken place perfectly as planned in the
previous stage and there is no need to think about the past issues that may arise in the next
phase.
 This model does not work smoothly if there are some issues left at the previous step.
 The sequential nature of model does not allow us to go back and undo or redo our actions.
 This model is best suited when developers already have designed and developed similar software
in the past and are aware of all its domains.

https://onlinecollegenotes.com
2. Iterative Model
 This model leads the software development process in iterations.
 It projects the process of development in cyclic manner repeating every step after every cycle of
SDLC process.
 The software is first developed on very small scale and all the steps are followed which are taken
into consideration.
 Then, on every next iteration, more features and modules are designed, coded, tested, and added
to the software.
 Every cycle produces a software, which is complete in itself and has more features and
capabilities than that of the previous one.
 After each iteration, the management team can do work on risk management and prepare for the
next iteration.
 Because a cycle includes small portion of whole software process, it is easier to manage the
development process but it consumes more resources.

https://onlinecollegenotes.com
3. Spiral Model
 Spiral model is a combination of both, iterative model and one of the SDLC model. It can be seen
as if you choose one SDLC model and combined it with cyclic process (iterative model).
 This model considers risk, which often goes un-noticed by most other models.
 The model starts with determining objectives and constraints of the software at the start of one
iteration. Next phase is of prototyping the software. This includes risk analysis.
 Then one standard SDLC model is used to build the software. In the fourth phase of the plan of
next iteration is prepared.

4. V – model
 The major drawback of waterfall model is we move to the next stage only when the previous one
is finished and there was no chance to go back if something is found wrong in later stages.
 V-Model provides means of testing of software at each stage in reverse manner.
 At every stage, test plans and test cases are created to verify and validate the product according
to the requirement of that stage. For example, in requirement gathering stage the test team
prepares all the test cases in correspondence to the requirements.
 Later, when the product is developed and is ready for testing, test cases of this stage verify the
software against its validity towards requirements at this stage.
 This makes both verification and validation go in parallel. This model is also known as verification
and validation model.

https://onlinecollegenotes.com
5. Big Bang Model
 This model is the simplest model in its form.
 It requires little planning, lots of programming and lots of funds.
 This model is conceptualized around the big bang of universe.
 As scientists say that after big bang lots of galaxies, planets, and stars evolved just as an event.
Likewise, if we put together lots of programming and funds, you may achieve the best software
product.
 For this model, very small amount of planning is required.
 It does not follow any process, or at times the customer is not sure about the requirements and
future needs. So the input requirements are arbitrary.
 This model is not suitable for large software projects but good one for learning and experimenting.

https://onlinecollegenotes.com
Requirement analysis and specification

 Requirement analysis and specification is a crucial phase in the software development life cycle.
 It involves gathering and defining the needs and constraints of a software system that is to be
developed or modified.
 This phase lays the foundation for the entire development process.
 It is a document that completely describes what the proposed software should do without describing
how software will do it.
 The basic goal of the requirement phase is to produce the complete behavior of the proposed
software.
 It is also helping the clients to understand their own needs.
 Effective requirement analysis and specification are critical to the success of a software project.
 Clear and well-documented requirements serve as a blueprint for developers and testers, ensuring
that the final product meets the needs and expectations of the stakeholders.
 Additionally, they provide a basis for change control and project management throughout the
development process.

Advantages

 Software SRS establishes the basic for agreement between the client and the supplier on what the
software product will do.
1. A SRS provides a reference for validation of the final product.
2. A high-quality SRS is a prerequisite to high-quality software.
3. A high-quality SRS reduces the development cost.

Characteristics of good SRS (Software Requirements Specification)

1. Complete:
 A complete requirements specification must precisely define all the real world situations that will
be encountered and the capability’s responses to them.
 It must not include situations that will not be encountered or unnecessary capability features.

2. Consistent:
 System functions and performance level must be compatible and the required quality features
(reliability, safety, security, etc.) must not contradict the utility of the system.
 For example, the only aircraft that is totally safe is one that cannot be started, contains no fuel or
other liquids, and is securely tied down.

3. Correct:
 The specification must define the desired capability’s real world operational environment, its
interface to that environment and its interaction with that environment.

https://onlinecollegenotes.com
  It is the real world aspect of requirements that is the major source of difficulty in achieving
specification correctness.
 The real world environment is not well known for new applications and for mature applications the
real world keeps changing.
 The Y2K problem with the transition from the year 1999 to the year 2000 is an example of the real
world moving beyond an application’s specified requirements.

4. Modifiable:
 Related concerns must be grouped together and unrelated concerns must be separated.
 Requirements document must have a logical structure to be modifiable.

5. Ranked:
 Ranking specification statements according to stability and/or importance is established in the
requirements document’s organization and structure.
 The larger and more complex the problem addressed by the requirements specification, the more
difficult the task is to design a document that aids rather than inhibits understanding.

6. Testable:
 A requirement specification must be stated in such as manner that one can test it against pass/fail
or quantitative assessment criteria, all derived from the specification itself and/or referenced
information.
 Requiring that a system must be “easy” to use is subjective and therefore is not testable.

7. Traceable:
 Each requirement stated within the SRS document must be uniquely identified to achieve
traceability.
 Uniqueness is facilitated by the use of a consistent and logical scheme for assigning identification
to each specification statement within the requirements document.

8. Unambiguous:
 A statement of a requirement is unambiguous if it can only be interpreted one way.
 This perhaps, is the most difficult attribute to achieve using natural language.
 The use of weak phrases or poor sentences structure will open the specification statement to
misunderstandings.

9. Valid:
 To validate a requirements specification all the project participants, managers, engineers and
customer representatives, must be able to understand, analyze and accept or approve it.
 This is the primary reason that most specifications are expressed in natural language.

10. Verifiable:
 In order to be verifiable, requirement specifications at one level of abstraction must be consistent
with those at another level of abstraction.

https://onlinecollegenotes.com
  Most, if not all, of these attributes are subjective and a conclusive assessment of the quality of a
requirements specification requires review and analysis by technical and operational experts in
the domain addressed by the requirements.

Steps of requirement analysis and specification

1. Elicitation:
 This is the process of gathering requirements from various stakeholders including clients, end-
users, subject matter experts, and other relevant parties.
 Techniques such as interviews, surveys, workshops, and observations are used to collect
information.

2. Documentation:
 The gathered information is documented in a structured manner. This documentation can include
functional requirements (what the system should do), non-functional requirements (constraints
and quality attributes), and any other relevant information.

3. Analysis:
 During this phase, the gathered requirements are analyzed to identify inconsistencies,
ambiguities, and conflicts.
 It's important to ensure that the requirements are clear, complete, and feasible.

4. Prioritization:
 Not all requirements are equally important. Prioritization helps in identifying and focusing on the
most critical features or functionalities.
 This is essential for resource allocation and project planning.

5. Modeling:
 Various techniques and tools, including UML diagrams, data models, and flowcharts, are used to
visually represent the requirements.
 These models help in better understanding and communication of the system's functionality.

6. Validation:
 This involves confirming that the gathered requirements accurately represent the needs of the
stakeholders.
 It may involve reviews, walkthroughs, or even prototyping to demonstrate the system capabilities.

7. Verification:
 Verification ensures that the requirements are consistent, complete, and meet the specified
criteria.
 This is often done through inspections, reviews, and other validation techniques.

https://onlinecollegenotes.com
8. Traceability:
 Traceability is the ability to track and verify the relationships between requirements.
 It ensures that each requirement can be traced back to its source and that it's addressed in the
design, development, and testing phases.

9. Change Management:
 As the project progresses, requirements may change due to evolving business needs or new
insights.
 It's important to have a process in place to handle and document these changes.

10. Formal Specification:

 In some cases, particularly in safety-critical systems, formal methods are used to mathematically
specify system requirements.
 This involves using formal languages and tools to provide a precise and unambiguous description
of the system.

11. Documentation Maintenance:

 Throughout the project, the requirement documents need to be kept up-to-date to reflect any
changes or additions.
 This ensures that all stakeholders have access to the latest information.

12. Sign-off:
 Once all stakeholders are satisfied with the requirements, they are typically formally approved or
signed off.
 This signifies that they are the agreed-upon basis for the development process.

Object-oriented software development (OOSD)

 Object-oriented software development (OOSD) is a programming paradigm that organizes software

around the concept of "objects", which can contain data and code.
 These objects can be thought of as instances of classes, which are templates that define the
structure and behavior of the objects.
 Object-oriented software development is widely used in the industry because it provides a structured
way to approach software design and development.
 It helps in creating modular, maintainable, and extensible code, making it easier to manage and
update complex software systems over time.

Here are some key principles and concepts of Object-Oriented Software Development:

1. Classes and Objects: Classes are blueprints for creating objects. They define the structure
(attributes or properties) and behavior (methods or functions) that objects of that class will have.

https://onlinecollegenotes.com
2. Encapsulation: Encapsulation is the concept of bundling the data (attributes) and methods
(functions) that operate on the data within a single unit, i.e., the class. This helps in hiding the internal
state and behavior of an object and only exposing the necessary interfaces.

3. Inheritance: Inheritance allows one class (the subclass) to inherit the properties and behaviors of
another class (the superclass). This promotes code reuse and helps in creating a hierarchy of
classes.

4. Polymorphism: Polymorphism allows objects to take on multiple forms. It allows a method to have
different implementations in different classes, but it can be called in a uniform way.

5. Abstraction: Abstraction involves representing the essential features of an object without showing
the details. This can be achieved by defining interfaces or abstract classes that specify the expected
behavior without providing the implementation.

6. Association: Association defines a relationship between two or more objects. For example, in a
library system, a Book object might be associated with an Author object.

7. Aggregation and Composition: Aggregation and composition are forms of association where one
object contains or is composed of other objects. Composition implies a stronger relationship, where
the contained objects are part of the whole and cannot exist independently.

8. Design Patterns: These are reusable solutions to common problems in software design. They
provide proven development paradigms that can speed up the development process and improve
code maintainability.

9. SOLID Principles: These are a set of five design principles that help in writing maintainable, flexible,
and scalable software. The acronym stands for Single Responsibility, Open/Closed, Liskov
Substitution, Interface Segregation, and Dependency Inversion.

10. Testing and Test-Driven Development (TDD): OOSD encourages practices like TDD, where tests
are written before the code. This helps ensure that the code meets the requirements and is more
robust.

11. UML (Unified Modeling Language): UML is a standardized modeling language used to visualize,
specify, construct, and document the artifacts of a software system. It includes diagrams like class
diagrams, use case diagrams, and sequence diagrams.

https://onlinecollegenotes.com